Re: gcc-4.8 + tree-loop-distribute-patterns breaks glibc-2.18

[Andreas Jaeger <aj at suse 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