This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GCC 4.8 and -ftree-loop-distribute-patterns.


> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]