[COMMITTED] Fix GCC6 build errors due to unused statics

  > Joseph Myers wrote:
> 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.

OK, I've reverted the private.h change and changed timezone/Makefile instead
(see below).

> 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.

I'd like to ensure GLIBC remains buildable with up to date GCC versions -
otherwise it becomes hard to run automated builds and tests on trunk.
Even just building/testing GLIBC is becoming problematic due to the large
number of spurious errors one encounters after updating GLIC and GCC
(which after all one is forced to do when checking in changes...).

If it hasn't been decided which warnings to enable in GCC6 (sorry I haven't
followed all the discussions...) then maybe we should not use -Werror at all
when building GLIBC with trunk GCC and only print warnings until all this has
been decided and any issues fixed.

Wilco

    2015-09-18  Wilco Dijkstra  <wdijkstr@arm.com>
    
            * timezone/Makefile: Ignore unused variable errors due to private.h
            (time_t_min) and (time_t_max).
            * timezone/private.h (time_t_min): Revert removal.  (time_t_max):
            Likewise.
  

On Fri, 18 Sep 2015, Wilco Dijkstra wrote:

> OK, I've reverted the private.h change and changed timezone/Makefile instead
> (see below).

I take it you made sure the -Wno-error= options work with GCC versions 
that don't have the new warning option?

> I'd like to ensure GLIBC remains buildable with up to date GCC versions -

That doesn't affect anything I said.  In the GNU Project we need to work 
out the appropriate place to fix things involving more than one project 
rather than jumping to conclusions about which place to change.  And in 
glibc changes need consensus - the fact that something fixes a warning 
with new GCC does not make it (in general - unused variables in 
glibc-local code are a reasonable exception) an obvious fix that can 
bypass the process of obtaining consensus (which includes considering 
whether the warning should actually be in -Wall at all, and which of 
possibly several approaches to a fix in glibc makes the most sense if 
fixing in glibc).

glibc releases should be buildable with GCC releases.  It's expected that 
there will often be breakage with GCC development versions that will take 
time to reach consensus on a fix.

> If it hasn't been decided which warnings to enable in GCC6 (sorry I haven't
> followed all the discussions...) then maybe we should not use -Werror at all
> when building GLIBC with trunk GCC and only print warnings until all this has
> been decided and any issues fixed.

If you want to detect glibc regressions, you should be building glibc with 
stable binutils and GCC versions.  If you want to detect regressions in 
GCC, upgrade GCC while keeping the versions of the other projects fixed.  
If you find such a regression in GCC (new GCC no longer builds a glibc 
version older GCC built) then you get to seek consensus about the right 
fix.  Upgrading more than one component at a time means it may be less 
clear which component a regression is in.
  

On Fri, 18 Sep 2015, Wilco Dijkstra wrote:

>     2015-09-18  Wilco Dijkstra  <wdijkstr@arm.com>
>     
>             * timezone/Makefile: Ignore unused variable errors due to private.h
>             (time_t_min) and (time_t_max).

I've reverted this timezone/Makefile change since it broke the build for 
all released versions of GCC, which is more important than the build with 
GCC 6 (where we have several months before a release to work out what 
warnings should be there at all).

Please recalibrate your notion of obviousness so you are much more wary of 
committing patches that haven't been reviewed.  See the list of obvious 
types of changes at <https://sourceware.org/glibc/wiki/Consensus>.

Someone indicating a general direction without having seen a patch is 
*not* approval for some arbitrary future patch following that direction, 
unless they specifically say e.g. "OK with that change".