RE: [COMMITTED] Fix GCC6 build errors due to unused statics

[Joseph Myers <joseph at codesourcery dot com>]

On Fri, 18 Sep 2015, Wilco Dijkstra wrote:

> > Joseph Myers wrote:
> > On Fri, 18 Sep 2015, Wilco Dijkstra wrote:
> > 
> > > 	* timezone/private.h (time_t_min): Likewise.  (time_t_max):
> > > 	Likewise.
> > 
> > The timezone/ code is imported verbatim from upstream tzcode releases and
> > should not be changed locally.  Please revert this change and work with
> > Paul on getting a fix into upstream tzcode.  When there's a new tzcode
> > release, you can then import it into glibc.  (Some Makefile changes will
> > be needed as part of the import of new code; see
> > <https://sourceware.org/ml/libc-alpha/2015-05/msg00553.html>.  Do not try
> > to combine this with importing a new version of tzdata.)
> 
> Would it be OK to change the Makefile instead to ignore this error?

That (specific to the timezone/ directory, of course) would be a 
reasonable temporary fix until a new tzcode release is out, if it takes a 
while to get a fixed release out.

In general: when you see a build failure resulting from a new GCC warning, 
the first reaction should *not* be to check in a glibc change as fast as 
possible.  First, you should consider whether the warning is in fact 
desirable for glibc - and whether it belongs in -Wall / enabled-by-default 
warnings at all, or whether the warnings seen building glibc are typical 
of widespread usage and provide evidence that the coding style constraint 
implied is inappropriate for -Wall.  Then provide the evidence in the 
gcc-patches discussion, and engage with the discussion there to help reach 
a conclusion on the appropriateness of the warning.

In this case, (a) the gcc-patches discussion has people saying they think 
inclusion in -Wall is a bad idea, and (b) I specifically said in that 
discussion not to change timezone/private.h locally in glibc 
<https://gcc.gnu.org/ml/gcc-patches/2015-09/msg01127.html>.

Now, removing unused variables seems a reasonable cleanup in glibc, 
independent of the warning's inclusion in -Wall - *provided* that all the 
other constraints regarding generated files, files imported from other 
sources etc. are met.  But in general for new warnings fixing them in 
glibc may not be the right thing at all, if it seems plausible the warning 
might be removed from -Wall, and so you need to wait for the gcc-patches 
discussion to reach consensus before making changes that can't be 
justified independently of the warning.

-- 
Joseph S. Myers
joseph@codesourcery.com