Re: [PATCH] Fix ACATS failures in GCC 3.4

["Zack Weinberg" <zack at codesourcery dot com>]

Laurent GUERBY <laurent@guerby.net> writes:

> On Wed, 2004-02-25 at 12:50, Eric Botcazou wrote:
>> This patch fixes all the ACATS (Ada testsuite in the FSF tree) failures in 
>> GCC 3.4 on x86.  They had been introduced by this patch:
>
> Hi Eric, thanks for catching this, we now get a clean ACATS run on HEAD
> at least on x86-linux :).
>
> If I change testsuite/ada/acats/run_all.sh variable gccflags to "-O3"
> I get 10 failures:
>
> c24211a	c94008c	cc70a01	cxg2006	cxg2007
> cxg2008	cxg2018	cxg2019	cxg2020	cxg2021
>
> c24211a and cc70a01 are unexpected run time exceptions,
> the cxg are various floating point "accuracy" problems,
> might be trickier to investigate, I'll try reducing
> this weekend.
>
> If I use "-O3 -funroll-all-loops" I get 6 additional
> failures (total 16), all backend ICEs:
>
> cxa5011	cxg2003	cxg2004	cxg2011	cxg2014
> cxh1001

This is why the c-torture testsuite cycles through a bunch of
different optimization options.

> Since failures at high optimization seem to be a superset of
> failures at no optimization (it has always been the case for my past
> year testing), may be it makes sense to choose "-O3" as the new
> ACATS default after we've confirmed that these are real bugs (and
> not ACATS bugs - these happens :).

Failures exclusively at -O0 and at -O1 do occur - they usually come
from backend bugs handling constructs that are normally optimized
out.  The most recent example I can think of was 

(set (reg:TF 15) (reg:TF 14))

on ia64 - those are actually overlapping pairs of registers.  The
construct gets split to a pair of DImode moves after reload, and they
must be done in the proper order.  With optimization the move is
eliminated so no one notices.

zw