This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: gcc-4.8 + tree-loop-distribute-patterns breaks glibc-2.18
- From: Andreas Jaeger <aj at suse dot com>
- To: Adhemerval Zanella <azanella at linux dot vnet dot ibm dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Tue, 21 May 2013 10:52:24 +0200
- Subject: Re: gcc-4.8 + tree-loop-distribute-patterns breaks glibc-2.18
- References: <20130520120304 dot GA10899 at winnix> <519A19D4 dot 6000001 at linux dot vnet dot ibm dot com>
On 05/20/2013 02:40 PM, Adhemerval Zanella wrote:
Hi,
Thanks for reporting it, I saw it too when building glibc with gcc-trunk.
Carlos O'Donell already reported it could be an issue to glibc at
http://sourceware.org/ml/libc-alpha/2013-02/msg00299.html and I also noted
it causes PTL issues too at http://sourceware.org/ml/libc-alpha/2013-04/msg00124.html
I have proposed a patch http://sourceware.org/ml/libc-alpha/2013-04/msg00196.html
so configure can check if compiler transform loops into libc functions calls, but
Andreas Jaeger and Roland McGrath didn't approve the approach.
Although, the problem persist and I think we need to figure out how to proceed
before 2.18 release. Based on the loader memset recursion call you observe I do
suggest to use my approach and add '-fno-tree-loop-distribute-patterns' on
rtld-memset.os object.
Any comments?
Roland and myself made some suggestions and I suggest to followup on
these. Yes, we should fix this - and I've added a note to
http://sourceware.org/glibc/wiki/Release/2.18
Let me cite what I wrote and add some clarification for that:
I thought we had two issues:
1) Compiling without -ftree-loop-distribute patterns on files so that
memcpy does not get replaced with a compiler call to it - Roland
suggested to use __attribute__ ((optimize ("no-tree-loop-distribute-
patterns"))) in this case and using a configure check. It seems that this
is not needed at all.
2) The issue were just the redefinition helps so that a call to internal
functions is issued.
For this case I do not see the need for a configure check, IMO it would
be enough to add the include together with a comment on why it's
included so that the include does not get accidentially removed. This is
far less maintenance burden than adding a configure test.
My suggestion was to simplify your patch: remove all the configure parts
and unconditionally include <string.h> (together with a comment) where
needed (as in your patch).
Wouldn't that work?
Andreas
--
Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126