[COMMITTED] Fix GCC6 build errors due to unused statics
Joseph Myers
joseph@codesourcery.com
Fri Sep 18 20:11:00 GMT 2015
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
More information about the Libc-alpha
mailing list