On Fri, 23 Oct 2009, Eric Botcazou wrote:
> > I didn't find (or could construct) a single C or C++ testcase that
> > wasn't fine with the new default, so I switched it (IIRC the default
> > is disambiguating the most cases).
>
> Yes, the default is the optimistic answer and a few tests rely on it
> I didn't find (or could construct) a single C or C++ testcase that
> wasn't fine with the new default, so I switched it (IIRC the default
> is disambiguating the most cases).
Yes, the default is the optimistic answer and a few tests rely on it:
FAIL: gcc.dg/tree-ssa/alias-18.c scan-tree-dump fr
> I changed this default to false somewhen in the past. There was a
> big fat comment there on the alias-improvements branch (where I
> wondered if returning false would be a safe thing to do).
>
> I didn't find (or could construct) a single C or C++ testcase that
> wasn't fine with the new defaul
On Fri, 23 Oct 2009, Eric Botcazou wrote:
> Hi Richard,
>
> I just (re-)discovered that the new TBAA machinery is quite aggressive and
> breaks cases that used to work in Ada (-O2 testcase for SPARC64 attached).
>
> The problem boils down to this:
>
> D.1416_1 = (struct p__rec &) &r.F;
> r
Hi Richard,
I just (re-)discovered that the new TBAA machinery is quite aggressive and
breaks cases that used to work in Ada (-O2 testcase for SPARC64 attached).
The problem boils down to this:
D.1416_1 = (struct p__rec &) &r.F;
r.F = ...
... = D.1416_1->d;
DSE computes that the store to
