diff options
author | Joseph Myers <joseph@codesourcery.com> | 2018-03-05 21:46:55 +0000 |
---|---|---|
committer | Joseph Myers <joseph@codesourcery.com> | 2018-03-05 21:46:55 +0000 |
commit | 6900d2ca74cd569d32167701a50cc7dc0d5ba4e2 (patch) | |
tree | d4317e6f9b9389a510ac142a14595faa3d74eb4e /string/test-stpcpy.c | |
parent | 5226a81f5517bcbc892679cca792006a6bafc53f (diff) | |
download | glibc-6900d2ca74cd569d32167701a50cc7dc0d5ba4e2.tar.gz glibc-6900d2ca74cd569d32167701a50cc7dc0d5ba4e2.tar.xz glibc-6900d2ca74cd569d32167701a50cc7dc0d5ba4e2.zip |
Fix s390 -Os iconv build.
Building glibc for s390 with -Os (32-bit only, with GCC 7) fails with: In file included from ../sysdeps/s390/multiarch/8bit-generic.c:370:0, from ebcdic-at-de.c:28: ../iconv/loop.c: In function '__to_generic_vx': ../iconv/loop.c:264:22: error: 'ch' may be used uninitialized in this function [-Werror=maybe-uninitialized] if (((Character) >> 7) == (0xe0000 >> 7)) \ ^~ In file included from ebcdic-at-de.c:28:0: ../sysdeps/s390/multiarch/8bit-generic.c:340:15: note: 'ch' was declared here uint32_t ch; \ ^ ../iconv/loop.c:325:7: note: in expansion of macro 'BODY' BODY ^~~~ It's fairly easy to see, looking at the (long) expansion of the BODY macro, that this is a false positive and the relevant variable 'ch' is always initialized before use, in one of two possible places. As such, disabling the warning for -Os with the DIAG_* macros is the natural approach to fix this build failure. However, because of the location at which the warning is reported, the disabling needs to go in iconv/loop.c, around the definition of UNICODE_TAG_HANDLER (not inside the definition), as that macro definition is where the uninitialized use is reported, whereas the code that needs to be reasoned about to see that the warning is a false positive is in the definition of BODY elsewhere. Thus, the patch adds such disabling in iconv/loop.c, with a comment pointing to the s390-specific code and a comment in the s390-specific code pointing to the generic file to alert people to the possible need to update one place when changing the other. It would be possible if desired to use #ifdef __s390__ around the disabling, though in general we try to avoid that sort of thing in generic files. (Or some extremely specialized macros for "disable -Wmaybe-uninitialized in this particular place" could be specified, defined to 0 in a lot of different files that include iconv/loop.c and to 1 in that particular s390 file.) Tested that this fixed -Os compilation for s390-linux-gnu with build-many-glibcs.py. * iconv/loop.c (UNICODE_TAG_HANDLER): Disable -Wmaybe-uninitialized for -Os. * sysdeps/s390/multiarch/8bit-generic.c (BODY): Add comment about this disabling.
Diffstat (limited to 'string/test-stpcpy.c')
0 files changed, 0 insertions, 0 deletions