Fix s390 -Os iconv build

[Stefan Liebler]

On 03/02/2018 06:56 PM, Joseph Myers wrote:
> 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.
> 
Build locally on s390 / s390x with -Os / -O3.
This patch suppresses the Werror in all these mentioned cases.
 From s390 perspective, this patch is okay.

Thanks.
Stefan