Bug 1263817
Summary: | glibc fails to build with incorrect -Werror=array-bounds failure. | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Carlos O'Donell <codonell> | ||||||||
Component: | gcc | Assignee: | Jakub Jelinek <jakub> | ||||||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||
Severity: | unspecified | Docs Contact: | |||||||||
Priority: | unspecified | ||||||||||
Version: | 24 | CC: | davejohansen, jakub, jwakely, law, mpolacek, pbrobinson | ||||||||
Target Milestone: | --- | ||||||||||
Target Release: | --- | ||||||||||
Hardware: | Unspecified | ||||||||||
OS: | Unspecified | ||||||||||
Whiteboard: | |||||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||||
Doc Text: | Story Points: | --- | |||||||||
Clone Of: | Environment: | ||||||||||
Last Closed: | 2016-03-10 15:20:04 UTC | Type: | Bug | ||||||||
Regression: | --- | Mount Type: | --- | ||||||||
Documentation: | --- | CRM: | |||||||||
Verified Versions: | Category: | --- | |||||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||
Embargoed: | |||||||||||
Bug Depends On: | |||||||||||
Bug Blocks: | 245418 | ||||||||||
Attachments: |
|
Description
Carlos O'Donell
2015-09-16 19:17:47 UTC
I'll attach preprocessed source shortly. gcc version 5.1.1 20150618 (Red Hat 5.1.1-4) (GCC): gcc ld-ctype.i -c -std=gnu99 -fgnu89-inline -O3 -Wall -Wundef -Wwrite-strings -fasynchronous-unwind-tables -fmerge-all-constants -frounding-math -g -mtune=generic -Wstrict-prototypes programs/ld-ctype.c: In function ‘ctype_read’: programs/ld-ctype.c:2842:552: warning: array subscript is above array bounds [-Warray-bounds] Created attachment 1074178 [details]
ld-ctype.i
Note: I had to inline `-include include/libc-symbols.h` otherwise it's a pain to get usable pre-processed source from glibc. Therefore the file is not exactly the same as it was, but contains a top line `#include <libc-symbols.h>` such that `-save-temps` gets all the information it needs into the *.i file. gcc dns-host.i -c -std=gnu99 -fgnu89-inline -O3 -Wall -Wundef -Wwrite-strings -fasynchronous-unwind-tables -fmerge-all-constants -frounding-math -g -mtune=generic -Wno-strict-prototypes -Wno-write-strings -Wstrict-prototypes -fPIC nss_dns/dns-host.c: In function ‘getanswer_r’: nss_dns/dns-host.c:567:25: warning: array subscript is above array bounds [-Warray-bounds] if (_res.sort_list[j].addr.s_addr == ^ nss_dns/dns-host.c:568:61: warning: array subscript is above array bounds [-Warray-bounds] (((struct in_addr *)(*p))->s_addr & _res.sort_list[j].mask)) ^ Created attachment 1074180 [details]
dns-host.i
(In reply to Carlos O'Donell from comment #2) > gcc version 5.1.1 20150618 (Red Hat 5.1.1-4) (GCC): > > gcc ld-ctype.i -c -std=gnu99 -fgnu89-inline -O3 -Wall -Wundef > -Wwrite-strings -fasynchronous-unwind-tables -fmerge-all-constants > -frounding-math -g -mtune=generic -Wstrict-prototypes > > programs/ld-ctype.c: In function ‘ctype_read’: > programs/ld-ctype.c:2842:552: warning: array subscript is above array bounds > [-Warray-bounds] Sorry, I just noticed the compiler adds yet another previously not reported array bounds error after I mark the first two, thus I need a new fix. So this will look like this when run: programs/ld-ctype.c: In function ‘ctype_read’: programs/ld-ctype.c:2539:549: warning: array subscript is above array bounds [-Warray-bounds] programs/ld-ctype.c:2822:552: warning: array subscript is above array bounds [-Warray-bounds] Created attachment 1074182 [details]
ld-ctype.i
With the new ld-ctype patch looking like this. Index: glibc-2.22-193-g315267a/locale/programs/ld-ctype.c =================================================================== --- glibc-2.22-193-g315267a.orig/locale/programs/ld-ctype.c +++ glibc-2.22-193-g315267a/locale/programs/ld-ctype.c @@ -2534,9 +2534,19 @@ with character code range values one mus { size_t cnt; + DIAG_PUSH_NEEDS_COMMENT +#if __GNUC_PREREQ (5, 0) + /* GCC 5.0 warns about array subscript being above array bounds, + but that's not possible since ctype_map_new prevents + map_collection_nr from being greater than MAX_NR_CHARMP which + is the size of mapnames. This is likely PR/59124 which is still + not fixed. */ + DIAG_IGNORE_NEEDS_COMMENT (5.0, "-Warray-bounds") +#endif for (cnt = 2; cnt < ctype->map_collection_nr; ++cnt) if (strcmp (now->val.str.startmb, ctype->mapnames[cnt]) == 0) break; + DIAG_POP_NEEDS_COMMENT if (cnt < ctype->map_collection_nr) free (now->val.str.startmb); @@ -2807,9 +2817,19 @@ previous definition was here"))); /* This could mean one of several things. First test whether it's a character class name. */ + DIAG_PUSH_NEEDS_COMMENT +#if __GNUC_PREREQ (5, 0) + /* GCC 5.0 warns about array subscript being above array bounds, + but that's not possible since ctype_class_new prevents + nr_charclass from being greater than MAX_NR_CHARCLASS which + is the size of classnames. This is likely PR/59124 which is still + not fixed. */ + DIAG_IGNORE_NEEDS_COMMENT (5.0, "-Warray-bounds") +#endif for (cnt = 0; cnt < ctype->nr_charclass; ++cnt) if (strcmp (now->val.str.startmb, ctype->classnames[cnt]) == 0) break; + DIAG_POP_NEEDS_COMMENT if (cnt < ctype->nr_charclass) { class_bit = _ISwbit (cnt); @@ -2817,9 +2837,19 @@ previous definition was here"))); free (now->val.str.startmb); goto read_charclass; } + DIAG_PUSH_NEEDS_COMMENT +#if __GNUC_PREREQ (5, 0) + /* GCC 5.0 warns about array subscript being above array bounds, + but that's not possible since ctype_map_new prevents + map_collection_nr from being greater than MAX_NR_CHARMP which + is the size of mapnames. This is likely PR/59124 which is still + not fixed. */ + DIAG_IGNORE_NEEDS_COMMENT (5.0, "-Warray-bounds") +#endif for (cnt = 0; cnt < ctype->map_collection_nr; ++cnt) if (strcmp (now->val.str.startmb, ctype->mapnames[cnt]) == 0) break; + DIAG_POP_NEEDS_COMMENT if (cnt < ctype->map_collection_nr) { mapidx = cnt; --- And for clarity: --- /* The macros to control diagnostics are structured like this, rather than a single macro that both pushes and pops diagnostic state and takes the affected code as an argument, because the GCC pragmas work by disabling the diagnostic for a range of source locations and do not work when all the pragmas and the affected code are in a single macro expansion. */ /* Push diagnostic state. */ #define DIAG_PUSH_NEEDS_COMMENT _Pragma ("GCC diagnostic push") /* Pop diagnostic state. */ #define DIAG_POP_NEEDS_COMMENT _Pragma ("GCC diagnostic pop") #define _DIAG_STR1(s) #s #define _DIAG_STR(s) _DIAG_STR1(s) /* Ignore the diagnostic OPTION. VERSION is the most recent GCC version for which the diagnostic has been confirmed to appear in the absence of the pragma (in the form MAJOR.MINOR for GCC 4.x, just MAJOR for GCC 5 and later). Uses of this pragma should be reviewed when the GCC version given is no longer supported for building glibc; the version number should always be on the same source line as the macro name, so such uses can be found with grep. Uses should come with a comment giving more details of the diagnostic, and an architecture on which it is seen if possibly optimization-related and not in architecture-specific code. This macro should only be used if the diagnostic seems hard to fix (for example, optimization-related false positives). */ #define DIAG_IGNORE_NEEDS_COMMENT(version, option) \ _Pragma (_DIAG_STR (GCC diagnostic ignored option)) --- I could reproduce this with gcc-5.1.1-4.fc22.x86_64, but not with any upstream version or with gcc built from latest redhat/gcc-5-branch. I think this has been fixed in PR66422. This fix isn't in gcc-5.1.1-4.fc22, but is in gcc-5.1.1-5.fc22, so I hope this annoying issue will be resolved when Fedora lets us upgrade to a newer version of gcc. I'll try to check though. (In reply to Marek Polacek from comment #11) > I could reproduce this with gcc-5.1.1-4.fc22.x86_64, but not with any > upstream version or with gcc built from latest redhat/gcc-5-branch. > > I think this has been fixed in PR66422. This fix isn't in gcc-5.1.1-4.fc22, > but is in gcc-5.1.1-5.fc22, so I hope this annoying issue will be resolved > when Fedora lets us upgrade to a newer version of gcc. I'll try to check > though. Awesome, thanks for verifying. I'd like to see this fixed in Rawhide, but there is no time pressure since I'm working around the new warnings. It's just annoying :-( Fixing it in rawhide is problematic, because the arm builders are too slow (they need more than 24 hours to build gcc) and there is a 24 hour timeout for the builds. So, the last few builds of gcc in rawhide or f23 just failed. I've verified in mock that with gcc-5.1.1-5.fc22 we don't issue any -Warray-bounds warnings on neither ld-ctype.i nor dns-host.i. (In reply to Jakub Jelinek from comment #13) > Fixing it in rawhide is problematic, because the arm builders are too slow > (they need more than 24 hours to build gcc) and there is a 24 hour timeout > for the builds. So, the last few builds of gcc in rawhide or f23 just > failed. I've spoken with Peter Robinson and he's looking into some ways in which we might look at either why this is slow (did hardening make it slow? %global _hardened_build 0) or how to speed it up (use SSDs). No promises though, but I think we can make this build faster. This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle. Changing version to '24'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase This ought to be fixed since gcc-5.1.1-5.fc23. And the rawhide GCC appears to be fixed as well. Closing out thus. |