Re: Still crashes due to aliasing violation (Re: [RFC, PATCH] Split pool_allocator and create a new object_allocator)

[Richard Biener <richard.guenther@gmail.com>]

On July 17, 2015 11:28:28 PM GMT+02:00, Ulrich Weigand <uweigand@de.ibm.com> wrote:
>On July 17, 2015 6:54:32 PM GMT+02:00, Ulrich Weigand
><uweigand@de.ibm.com> wrote:
>> >So do we now consider host compilers < 4.3 (4?) unsupported for
>> >building
>> >mainline GCC, or should we try to work around the issue (e.g. by
>moving
>> >the allocator out-of-line or using some other aliasing barrier)?
>> 
>> Why is this an issue for stage1 which runs w/o optimization?
>
>Well, this is the SPU compiler on a Cell system, which is technically
>a cross compiler from PowerPC (even though the resulting binaries run
>natively on the machine).
>
>> For cross compiling we already suggest using known good compilers.
>
>The documentation says:
>
>  To build a cross compiler, we recommend first building and installing
>  a native compiler. You can then use the native GCC compiler to build
>  the cross compiler. The installed native compiler needs to be GCC
>  version 2.95 or later. 

I think that needs updating anyway since even for crosses we now require a C++04 conforming host compiler.

>So building with a native GCC 4.1 seems to have been officially
>supported until now as far as I can tell (unless you're building Ada).
>
>
>Now, I could certainly live with a statement that cross compilers can
>only be build with a native GCC 4.3 or newer; but that should be IMO
>a deliberate decision and be widely announced (maybe even verified
>by a configure check?), so that others don't run into the problem;
>the nature of its symptoms make the problem difficult to diagnose.

The requirement is to have a bug-free host compiler or use flags that make it appear bug-free.  Which is why we use -O0 when bootstrapping...

Yes, we could detect appropriate host gcc versions at configure time and apply a workaround (use -fno-strict-aliasing) for too old GCC.

Richard.

>
>Bye,
>Ulrich