This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: GCC 4.8 and -ftree-loop-distribute-patterns.
- From: Roland McGrath <roland at hack dot frob dot com>
- To: Adhemerval Zanella <azanella at linux dot vnet dot ibm dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Mon, 8 Apr 2013 13:33:39 -0700 (PDT)
- Subject: Re: GCC 4.8 and -ftree-loop-distribute-patterns.
- References: <511D4F82 dot 3080604 at redhat dot com> <515F4565 dot 6030301 at linux dot vnet dot ibm dot com> <20130405223023 dot 0DEB62C096 at topped-with-meat dot com> <51601F98 dot 5000606 at linux dot vnet dot ibm dot com>
> But I believe a simpler solution instead of add '-fno-tree-loop-distribute-patterns'
> on Makefile or function attribute is to just add an '#include <string.h>'
> on such sources.
Regardless of simplicity per se, -fno-tree-loop-distribute-patterns is
not the desireable change because it's perturbing an optimization choice
that the compiler should be free to make.
> The following patch fixed the localplt issue I was observing on PowerPC64:
This is not really what we want either. Those source files don't use
any <string.h> functions, so it shouldn't be their responsibility to do
the include.
Instead, we should have a global solution to the problem of unwanted PLT
calls in compiler-chosen implicit calls. This could happen anywhere,
not just in cases that -ftree-loop-distribute-patterns is newly causing.
For example, any large struct copying might generate a memcpy call; if
that were done in some file that doesn't happen to #include <string.h>
for any reason, then we would already be seeing the problem.
I think the only way we can really do that is to have the appropriate
declarations somewhere that every compilation sees, i.e. libc-symbols.h
or something else we get via -include. IMHO it would certainly be far
better if the compiler gave us some way other than such source-visible
declarations to change the names it uses in its implicit calls--the
compiler's use of memcpy or memset as an aid to code generation ought to
be wholly unrelated to the source program's use or declaration of
functions with those same names. Perhaps someone would like to look
into such a compiler change. (The first obvious idea is just a switch
to set a prefix on the symbol names used in such calls.) As things
stand today, if we fix this problem by ensuring declarations that might
be necessary are always in scope, then this will implicitly silence any
warnings we'd get now for source files that explicitly use memset,
memcpy, etc., without a proper #include for their declarations. That's
undesireable and a clear indication that the compiler's way of dealing
with this issue is quite wrong-headed, but it won't cause us much
trouble in practice.
Thanks,
Roland