This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Still crashes due to aliasing violation (Re: [RFC, PATCH] Split pool_allocator and create a new object_allocator)
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Ulrich Weigand <uweigand at de dot ibm dot com>
- Cc: mliska at suse dot cz,gcc-patches at gcc dot gnu dot org
- Date: Sat, 18 Jul 2015 11:13:48 +0200
- Subject: Re: Still crashes due to aliasing violation (Re: [RFC, PATCH] Split pool_allocator and create a new object_allocator)
- Authentication-results: sourceware.org; auth=none
- References: <20150717212828 dot 870233CC3 at oc7340732750 dot ibm dot 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