[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: gcc-4.4 ICE



On Sun, 24 Oct 2010, Thorsten Glaser wrote:

> Andreas Schwab dixit:
> 
> >Thorsten Glaser <tg@mirbsd.de> writes:
> >
> >> jdsample.c:140: internal compiler error: in 
> >> reload_cse_simplify_operands, at postreload.c:396
> >
> >http://gcc.gnu.org/PR37053
> 
> Thanks, that’s fast. I’m glad so many people who work in, for example, 
> gcc, participate on this list. So, Comment 19 backport?

I tested it, and yes, the PR37053 patch is sufficient to fix this. Maxim 
Kuvyrkov regression tested it:
http://gcc.gnu.org/ml/gcc-patches/2009-08/msg00375.html

Despite that, there may be complications (?)

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41064#c8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40414#c15

It would appear that we could safely apply the PR37053 fix for m68k only, 
but if it is applied unconditionally then we may see a regression on cris, 
unless we also cherry-pick the fix from PR41064 ... but I could be 
completely wrong, as I'm having a hard time figuring out what is going on 
in these bug reports and whether perhaps they are not related at all!

The PR37053 fix also fixed PR40414 in my test, which contradicts the 
contradiction in PR41064:

> Hans-Peter Nilsson 2010-05-11 17:06:25 UTC (In reply to comment #6)
> > Causes PR40414 on GCC 4.4.x, reopening to make the other PR depend on 
> > this.
> 
> Looks like the above statement is wrong: the committed patch for this PR 
> is just (one of the two) required for PR40414.  I'm closing this as 
> there's no reason to hold *this* PR open regardless of the state of 
> PR40414.

Since this makes no sense to me, I'd ask Matthias to apply the fix but 
keep it to m68k only (unless someone can run regression tests on other 
architectures...)

Finn

Reply to: