Re: [patch] Fix PR tree-optimization/51624

2012-01-09 Thread Richard Guenther
On Mon, Jan 9, 2012 at 12:45 PM, Eric Botcazou wrote: >> Hmm, it seems to be because we do not value-number loads that >> satisfy stmt_could_throw_p (for whatever reason ...).  Seems to date >> back to rev. 131610, the fix for PR34648.  Looking at that bug it >> seems that we could at least allow

Re: [patch] Fix PR tree-optimization/51624

2012-01-09 Thread Eric Botcazou
> Hmm, it seems to be because we do not value-number loads that > satisfy stmt_could_throw_p (for whatever reason ...). Seems to date > back to rev. 131610, the fix for PR34648. Looking at that bug it > seems that we could at least allow stmts that only throw externally > (but generally CSE shoul

Re: [patch] Fix PR tree-optimization/51624

2012-01-09 Thread Richard Guenther
On Mon, Jan 9, 2012 at 11:33 AM, Eric Botcazou wrote: >> Can you get me a testcase that I can compile?  This should be fixed in FRE. > > This is gnat.dg/pack9.ad[sb].  You need a bare cross-compiler to s390x-linux: > configure, build with make CFLAGS=-g, when the build fails, do gcc/ada then > mak

Re: [patch] Fix PR tree-optimization/51624

2012-01-09 Thread Eric Botcazou
> Can you get me a testcase that I can compile? This should be fixed in FRE. This is gnat.dg/pack9.ad[sb]. You need a bare cross-compiler to s390x-linux: configure, build with make CFLAGS=-g, when the build fails, do gcc/ada then make gnatlib. Go back to the build dir, copy gnat.dg/pack9.ad[s

Re: [patch] Fix PR tree-optimization/51624

2012-01-09 Thread Richard Guenther
On Fri, Jan 6, 2012 at 7:17 PM, Eric Botcazou wrote: >> > OK, I see.  Then the only way out I can think of is to stop going up the >> > chain of COMPONENT_REFs as soon as the offset becomes negative. >> >> Yeah, that sounds like a better solution. > > PR ada/51775 shows that this pessimizes though

Re: [patch] Fix PR tree-optimization/51624

2012-01-06 Thread Eric Botcazou
> > OK, I see.  Then the only way out I can think of is to stop going up the > > chain of COMPONENT_REFs as soon as the offset becomes negative. > > Yeah, that sounds like a better solution. PR ada/51775 shows that this pessimizes though because if you have an enclosing sub-component at offset 0

Re: [patch] Fix PR tree-optimization/51624

2012-01-04 Thread Richard Guenther
On Wed, Jan 4, 2012 at 1:27 PM, Eric Botcazou wrote: >> > OK, I see.  Then the only way out I can think of is to stop going up the >> > chain of COMPONENT_REFs as soon as the offset becomes negative. >> >> Yeah, that sounds like a better solution. > > Bootstrapped on MIPS/IRIX and regtested on {i5

Re: [patch] Fix PR tree-optimization/51624

2012-01-04 Thread Eric Botcazou
> > OK, I see.  Then the only way out I can think of is to stop going up the > > chain of COMPONENT_REFs as soon as the offset becomes negative. > > Yeah, that sounds like a better solution. Bootstrapped on MIPS/IRIX and regtested on {i586,x86_64}-suse-linux. OK after a full testing cycle? 2012

Re: [patch] Fix PR tree-optimization/51624

2012-01-03 Thread Richard Guenther
On Tue, Jan 3, 2012 at 11:16 AM, Eric Botcazou wrote: >> If you have nested structure types that are TYPE_STRUCTURAL_EQUALITY >> then they have TYPE_CANONICAL == NULL_TREE and types_compatible_p >> will return false (it ICEd in previous releases I believe) and thus you >> won't stop attaching COMP

Re: [patch] Fix PR tree-optimization/51624

2012-01-03 Thread Eric Botcazou
> If you have nested structure types that are TYPE_STRUCTURAL_EQUALITY > then they have TYPE_CANONICAL == NULL_TREE and types_compatible_p > will return false (it ICEd in previous releases I believe) and thus you > won't stop attaching COMPONENT_REFs. > > So the fix isn't complete. OK, I see. The

Re: [patch] Fix PR tree-optimization/51624

2012-01-02 Thread Richard Guenther
On Mon, Jan 2, 2012 at 1:06 PM, Eric Botcazou wrote: >> Note that you'll get ICEs whenever TYPE_CANONICAL of some >> aggregate type is NULL (thus, TYPE_STRUCTURAL_EQUALITY), so this >> seems inherently fragile (similar to using TYPE_CANONICAL == TYPE_CANONICAL >> here, we'd break the TYPE_STRUCTUR

Re: [patch] Fix PR tree-optimization/51624

2012-01-02 Thread Eric Botcazou
> Note that you'll get ICEs whenever TYPE_CANONICAL of some > aggregate type is NULL (thus, TYPE_STRUCTURAL_EQUALITY), so this > seems inherently fragile (similar to using TYPE_CANONICAL == TYPE_CANONICAL > here, we'd break the TYPE_STRUCTURAL_EQUALITY case again). Could you elaborate? The patch

Re: [patch] Fix PR tree-optimization/51624

2012-01-02 Thread Richard Guenther
On Sat, Dec 31, 2011 at 12:33 AM, Eric Botcazou wrote: > This is the bootstrap failure of the Ada compiler on MIPS/IRIX, a recent > regression present on mainline and 4.6 branch.  The stage 2 compiler > miscompiles the stage 3 compiler (sem_type.adb:Disambiguate) because of an > oversight in the f

[patch] Fix PR tree-optimization/51624

2011-12-30 Thread Eric Botcazou
This is the bootstrap failure of the Ada compiler on MIPS/IRIX, a recent regression present on mainline and 4.6 branch. The stage 2 compiler miscompiles the stage 3 compiler (sem_type.adb:Disambiguate) because of an oversight in the fix for PR tree-opt/50569 which changed build_ref_for_model to