Re: Add macros for diagnostic control, use them in locale/weightwc.h

[Joseph Myers <joseph at codesourcery dot com>]

On Tue, 18 Nov 2014, Paul Eggert wrote:

> In that case neither my patch nor Joseph's should be accepted.  If I
> understand Joseph's patch correctly,the maybe-uninitialized warning needs to
> be disabled only when dereferencing'cp'.  For example, in the expression
> 'cp[cnt]', the warning should be disabled only for the load from 'cp[cnt]'; it
> should not be disabled for the load from 'cp' itself, or for the load from
> 'cnt'.  So Joseph's proposed patch doesn't have a tight scope here.  It should
> be possible to tighten itto cover only the places where troublesome
> dereferences actually occur, e.g., by defining a macro
> 'NO_MAYBE_UNINITIALIZED_DEREFERENCE (p)' that suppresses the warning while
> dereferencing the pointer P, by using 'NO_MAYBE_UNINITIALIZED_DEREFERENCE (cp
> + cnt)' in place of 'cp[cnt]', etc.

Since these pragmas work, for middle-end warnings such as these, by 
tracking a range of locations for which a particular diagnostic is handled 
in a particular way, I don't expect such a use in statement expressions 
inside macros to work reliably (and it doesn't work in my tests); the 
smallest granularity I expect to be reliable is that of whole statements 
in source files outside of macros (with the pragma calls on separate 
lines).  (My test:

#define UNINIT(x) \
  ({ \
    __typeof (x) __tmp; \
    _Pragma ("GCC diagnostic push"); \
    _Pragma ("GCC diagnostic ignored \"-Wuninitialized\""); \
    __tmp = (x); \
    _Pragma ("GCC diagnostic pop"); \
    __tmp; \
  })

int
f (void)
{
  int a, b;
  return UNINIT (a) + UNINIT (b);
}

)

> Also, as I understand it the warning should be disabled only on x86-64, and

No, rather, it's known it needs disabling on x86_64, but we don't want to 
cause build failures on all other architectures until their maintainers 
confirm it's needed there.  The reference to x86_64 is simply a hint about 
where to test when GCC 4.9 is no longer a supported compiler for building 
glibc.

> only if optimization is enabled, as we don't know of problems with other
> platforms or when optimization is turned off.

glibc has to be built with optimization.

Disabling for the relevant block of source lines, on all architectures and 
for all GCC versions that support the relevant -W option, is a pragmatic 
choice for how to keep down the number of spurious build failures with 
default -Werror without hiding warnings unduly (basically, the alternative 
is the existing practice of -Wno- options for whole source files) or 
requiring excessive work for architecture maintainers (if we decide it's 
OK to disable a particular warning, this just needs doing once, and then 
that case doesn't need thinking about again until the GCC version with 
which the warning was seen is no longer supported for building glibc).

-- 
Joseph S. Myers
joseph@codesourcery.com