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
> 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
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
> 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
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
> > 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
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
> > 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
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
> 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
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
> 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
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
13 matches
Mail list logo
