On i386, a certain slightly convoluted combination of variables and asm blocks provokes an ICE from gcc under "-O -fomit-frame-pointer". Release: 3.0.4 (Debian testing/unstable) Environment: System: Linux blah 2.2.15 #1 Tue Apr 25 17:13:48 EST 2000 i586 unknown Architecture: i586 <machine, os, target, libraries (multiple lines)> host: i386-pc-linux-gnu build: i386-pc-linux-gnu target: i386-pc-linux-gnu configured with: ../src/configure -v --enable-languages=c,c++,java,f77,proto,objc --prefix=/usr --infodir=/share/info --mandir=/share/man --enable-shared --with-gnu-as --with-gnu-ld --with-system-zlib --enable-long-long --enable-nls --without-included-gettext --disable-checking --enable-threads=posix --enable-java-gc=boehm --with-cpp-install-dir=bin --enable-objc-gc i386-linux How-To-Repeat: The file foo.c below (which has been through the preprocessor already), compiled with gcc-3.0 -O -fomit-frame-pointer -c foo.c produces foo.c: In function `__gmpn_divrem_1': foo.c:219: Unrecognizable insn: (insn 399 662 401 (parallel[ (set (reg/v:SI 6 ebp [89]) (asm_operands:SI ("addl %5,%1 adcl %3,%0") ("=r") 0[ (mem:SI (plus:SI (reg/f:SI 7 esp) (const_int 48 [0x30])) 0) (reg/v:SI 6 ebp [93]) (reg/v:SI 2 ecx [90]) (reg/v:SI 4 esi [78]) ] [ (asm_input:SI ("%0")) (asm_input:SI ("g")) (asm_input:SI ("%1")) (asm_input:SI ("g")) ] ("foo.c") 172)) (set (reg/v:SI 2 ecx [90]) (asm_operands:SI ("addl %5,%1 adcl %3,%0") ("=&r") 1[ (mem:SI (plus:SI (reg/f:SI 7 esp) (const_int 48 [0x30])) 0) (reg/v:SI 6 ebp [93]) (reg/v:SI 2 ecx [90]) (reg/v:SI 4 esi [78]) ] [ (asm_input:SI ("%0")) (asm_input:SI ("g")) (asm_input:SI ("%1")) (asm_input:SI ("g")) ] ("foo.c") 172)) (clobber (reg:QI 19 dirflag)) (clobber (reg:QI 18 fpsr)) (clobber (reg:QI 17 flags)) ] ) -1 (insn_list 390 (insn_list 390 (nil))) (nil)) foo.c:219: Internal compiler error in reload_cse_simplify_operands, at reload1.c:8364 For what it's worth, this was an experimental GMP division routine, but only a work-in-progress version, so the code isn't supposed to work or do anything useful, but I think it's syntactically correct (since it seems to compile fine if either of -O or -fomit-frame-pointer is omitted).
From: Kevin Ryde <user42@zip.com.au> To: gcc-gnats@gcc.gnu.org Cc: Subject: Re: optimization/6162: gcc 3.0.4: certain i386 asm reloader ice Date: Sat, 03 Aug 2002 08:57:10 +1000 --=-=-= I struck another reloader ice, which to my untrained eye looks the same as the one in this bug I submitted before, but with the advantage of happening on a much smaller and simpler input. --=-=-= Content-Type: text/x-csrc Content-Disposition: attachment; filename=bar.c void foo (unsigned *wp, unsigned *xp, unsigned *yp, long size) { unsigned w3, w2, w1, w0, hi, z; __asm__ ("mull %3" : "=a" (w2), "=d" (w3) : "%0" (xp[1]), "rm" (yp[1])); __asm__ ("mull %3" : "=a" (w1), "=d" (hi) : "%0" (xp[0]), "rm" (yp[1])); __asm__ ("addl %5,%1\n" "adcl %3,%0" : "=r" (z), "=&r" (w0) : "%0" (w2), "g" (hi), "%1" (w1), "g" (0)); w3 += (z < w2); wp[2] = z; wp[3] = w3; } --=-=-= Content-Disposition: attachment; filename=bar.out gcc-3.1 -O -c bar.c bar.c: In function `foo': bar.c:26: unrecognizable insn: (insn 25 23 27 (parallel[ (set (reg/v:SI 1 edx [67]) (asm_operands:SI ("addl %5,%1 adcl %3,%0") ("=r") 0[ (reg/v:SI 2 ecx [63]) (reg/v:SI 1 edx [66]) (reg/v:SI 0 eax [64]) (const_int 0 [0x0]) ] [ (asm_input:SI ("%0")) (asm_input:SI ("g")) (asm_input:SI ("%1")) (asm_input:SI ("g")) ] ("bar.c") 14)) (set (reg/v:SI 0 eax [65]) (asm_operands:SI ("addl %5,%1 adcl %3,%0") ("=&r") 1[ (reg/v:SI 2 ecx [63]) (reg/v:SI 1 edx [66]) (reg/v:SI 0 eax [64]) (const_int 0 [0x0]) ] [ (asm_input:SI ("%0")) (asm_input:SI ("g")) (asm_input:SI ("%1")) (asm_input:SI ("g")) ] ("bar.c") 14)) (clobber (reg:QI 19 dirflag)) (clobber (reg:QI 18 fpsr)) (clobber (reg:QI 17 flags)) ] ) -1 (insn_list 19 (insn_list 23 (insn_list 23 (nil)))) (nil)) bar.c:26: Internal compiler error in reload_cse_simplify_operands, at reload1.c:8369 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions. m: *** [bar.o] Error 1 --=-=-=--
State-Changed-From-To: open->closed State-Changed-Why: hubicka@kampanus:/aux/hubicka/3.2/egcs/build/gcc$ ./xgcc -B ./ -O ~/foo.c -c hubicka@kampanus:/aux/hubicka/3.2/egcs/build/gcc$ (today CVS version)
State-Changed-From-To: closed->open State-Changed-Why: The problem still exists with both: gcc version 3.2.1 20021024 (prerelease) gcc version 3.3 20021023 (experimental) when using: gcc -O -fomit-frame-pointer -c foo.c
From: Andreas Jaeger <aj@suse.de> To: Kevin Ryde <user42@zip.com.au> Cc: hubicka@gcc.gnu.org, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org, nobody@gcc.gnu.org, gcc-gnats@gcc.gnu.org Subject: Re: optimization/6162: gcc 3.0.4: certain i386 asm reloader ice Date: Fri, 25 Oct 2002 07:36:43 +0200 Kevin Ryde <user42@zip.com.au> writes: > hubicka@gcc.gnu.org writes: >> >> State-Changed-From-To: open->closed >> State-Changed-Why: >> hubicka@kampanus:/aux/hubicka/3.2/egcs/build/gcc$ ./xgcc -B ./ -O ~/foo.c -c > > Umm, no, that foo.c requires -fomit-frame-pointer in addition to -O to > show the problem. With that option it still occurs for me, using a > build of today's cvs on my debian system. Also occurs for me - I reopen it, Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj
From: Kevin Ryde <user42@zip.com.au> To: hubicka@gcc.gnu.org Cc: gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org, nobody@gcc.gnu.org, gcc-gnats@gcc.gnu.org Subject: Re: optimization/6162: gcc 3.0.4: certain i386 asm reloader ice Date: Fri, 25 Oct 2002 10:02:47 +1000 hubicka@gcc.gnu.org writes: > > State-Changed-From-To: open->closed > State-Changed-Why: > hubicka@kampanus:/aux/hubicka/3.2/egcs/build/gcc$ ./xgcc -B ./ -O ~/foo.c -c Umm, no, that foo.c requires -fomit-frame-pointer in addition to -O to show the problem. With that option it still occurs for me, using a build of today's cvs on my debian system. It also still occurs with the simpler bar.c I appended to the report (just "gcc -O -c bar.c" in that case).
From: Nathanael Nerode <neroden@twcny.rr.com> To: user42@zip.com.au, gcc-gnats@gcc.gnu.org, gcc-prs@gcc.gnu.org, gcc-bugs@gcc.gnu.org, gcc@gcc.gnu.org Cc: Subject: Re: optimization/6162: gcc 3.0.4: certain i386 asm reloader ice Date: Wed, 30 Oct 2002 15:29:20 -0500 I know this is a regression, but: * it's a subtle and difficult bug in reload, which may take a long time and a lot of work to find * reload is intended to go away for 3.4 * it only occurs using inline assembly * it only occurs with --fomit-frame-pointer I don't think it's reasonable to hold up 3.2.1 or 3.3 for this bug. http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=6162
From: Michael Matz <matz@suse.de> To: Nathanael Nerode <neroden@twcny.rr.com>, Kevin Ryde <user42@zip.com.au> Cc: <gcc-gnats@gcc.gnu.org>, <gcc-prs@gcc.gnu.org>, <gcc-bugs@gcc.gnu.org>, <gcc@gcc.gnu.org> Subject: Re: optimization/6162: gcc 3.0.4: certain i386 asm reloader ice Date: Wed, 30 Oct 2002 23:09:20 +0100 (CET) Hi, On Wed, 30 Oct 2002, Nathanael Nerode wrote: > I know this is a regression, but: > * it's a subtle and difficult bug in reload, which may take a long time > and a lot of work to find Well, to find it is quite easy. reload is inherently incapable of handling more than one commutative operand, but there are two of them in the asm. If you are unlucky both of them would need to be swapped to make the insn valid, and this is what breaks reload, as it only can swap the last pair. I don't know why this constraint isn't documented, but anyway, that's the reason. To fix this indeed would be quite involved, as we would need to handle then all permutations of swappings (of which there are 4 with two pairs). Well, _I_ would fix this bug by documenting that behaviour. Note, that also, if we get rid of reload, the functionality will likely not change in that respect. > * reload is intended to go away for 3.4 On Thu, 31 Oct 2002, Kevin Ryde wrote: > The second (simpler) example I posted does it without that. > > > I don't think it's reasonable to hold up 3.2.1 or 3.3 for this bug. > > As far as I can tell you have to be pretty lucky, or unlucky, to > actually strike it. I've only had it two (or maybe three) times, and > not on finished code. Simply don't use more than one commutative pair, and you are safe (except if you really hit a bug of course ;-) ) Ciao, Michael.
From: Michael Matz <matz@suse.de> To: Kevin Ryde <user42@zip.com.au> Cc: Nathanael Nerode <neroden@twcny.rr.com>, <gcc-gnats@gcc.gnu.org>, <gcc-bugs@gcc.gnu.org>, <gcc@gcc.gnu.org>, =?iso-8859-1?q?Torbj=F6rn?= Granlund <tege@swox.com> Subject: Re: optimization/6162: gcc 3.0.4: certain i386 asm reloader ice Date: Wed, 30 Oct 2002 23:38:45 +0100 (CET) Hi, On Thu, 31 Oct 2002, Kevin Ryde wrote: > > Well, to find it is quite easy. reload is inherently incapable of > > handling more than one commutative operand, but there are two of them in > > the asm. If you are unlucky both of them would need to be swapped to make > > the insn valid, and this is what breaks reload, as it only can swap the > > last pair. I don't know why this constraint isn't documented, but anyway, > > that's the reason. > > The stuff in question is from longlong.h actually (shared by GMP and > GCC). All the add_ssaaaa's (or it looks like all) have two > commutatives. Wow. Indeed. Some of them even have such funny things like: __asm__ ("{a%I4|add%I4c} %1,%3,%4\n\t{ame|addme} %0,%2" \ : "=r" ((USItype) (sh)), \ "=&r" ((USItype) (sl)) \ : "%r" ((USItype) (ah)), \ "%r" ((USItype) (al)), \ "rI" ((USItype) (bl))); which obviously is broken, or __asm__ ("addu.co %1,%r4,%r5\n\taddu.ci %0,%r2,%r3" \ : "=r" ((USItype) (sh)), \ "=&r" ((USItype) (sl)) \ : "%rJ" ((USItype) (ah)), \ "rJ" ((USItype) (bh)), \ "%rJ" ((USItype) (al)), \ "rJ" ((USItype) (bl))) which is useless (they have the same constraints, so commutativity doesn't matter at all). Some of them probably are just lucky, like: __asm__ ("add.f %1, %4, %5\n\tadc %0, %2, %3" \ : "=r" ((USItype) (sh)), \ "=&r" ((USItype) (sl)) \ : "%r" ((USItype) (ah)), \ "rIJ" ((USItype) (bh)), \ "%r" ((USItype) (al)), \ "rIJ" ((USItype) (bl))) If called with only variables, or constants already in the right operands, the swapping also doesn't take place. But if then also operand matching comes into play (like some asms in longlong and also your example) the chance of getting unlucky is even higher. Anyway given that longlong.h uses it I again looked into reload, and no, it simply can't handle correctly more than one pair which needs swapping. It keeps track of only one operand which is commutative (the 'commutative' variable), and it only tries each alternative twice at most (once normally and once with the last pair swapped). Therefore I think longlong.h is broken, but I wonder why this never popped up. Ciao, Michael.
From: Torbjorn Granlund <tege@swox.com> To: Michael Matz <matz@suse.de> Cc: Kevin Ryde <user42@zip.com.au>, Nathanael Nerode <neroden@twcny.rr.com>, <gcc-gnats@gcc.gnu.org>, <gcc-bugs@gcc.gnu.org>, <gcc@gcc.gnu.org> Subject: Re: optimization/6162: gcc 3.0.4: certain i386 asm reloader ice Date: 30 Oct 2002 23:55:08 +0100 Michael Matz <matz@suse.de> writes: Wow. Indeed. Some of them even have such funny things like: __asm__ ("{a%I4|add%I4c} %1,%3,%4\n\t{ame|addme} %0,%2" \ : "=r" ((USItype) (sh)), \ "=&r" ((USItype) (sl)) \ : "%r" ((USItype) (ah)), \ "%r" ((USItype) (al)), \ "rI" ((USItype) (bl))); which obviously is broken, or Fixed in gmp's longlong.h: 2002-01-21 Torbjorn Granlund <tege@swox.com> * longlong.h (32-bit powerpc add_ssaaaa): Remove spurious commutative declaration. __asm__ ("addu.co %1,%r4,%r5\n\taddu.ci %0,%r2,%r3" \ : "=r" ((USItype) (sh)), \ "=&r" ((USItype) (sl)) \ : "%rJ" ((USItype) (ah)), \ "rJ" ((USItype) (bh)), \ "%rJ" ((USItype) (al)), \ "rJ" ((USItype) (bl))) which is useless (they have the same constraints, so commutativity doesn't matter at all). Well, we put commutativity declarations where they apply for consistency. Some of them probably are just lucky, like: __asm__ ("add.f %1, %4, %5\n\tadc %0, %2, %3" \ : "=r" ((USItype) (sh)), \ "=&r" ((USItype) (sl)) \ : "%r" ((USItype) (ah)), \ "rIJ" ((USItype) (bh)), \ "%r" ((USItype) (al)), \ "rIJ" ((USItype) (bl))) If called with only variables, or constants already in the right operands, the swapping also doesn't take place. But if then also operand matching comes into play (like some asms in longlong and also your example) the chance of getting unlucky is even higher. Anyway given that longlong.h uses it I again looked into reload, and no, it simply can't handle correctly more than one pair which needs swapping. It keeps track of only one operand which is commutative (the 'commutative' variable), and it only tries each alternative twice at most (once normally and once with the last pair swapped). Therefore I think longlong.h is broken, but I wonder why this never popped up. In GCC, I doubt immediate values will be used for add_ssaaaa. In GMP immediates are used, but by conventions they are used for the 2nd operand. There are a couple of other packages that use longlong.h as well, but they don't use immediates. I suggest that we don't touch longlong.h, since it is not really a problem. Who knows, one day GCC might get this right. -- Torbjörn
From: Michael Matz <matz@suse.de> To: Torbjorn Granlund <tege@swox.com> Cc: Kevin Ryde <user42@zip.com.au>, Nathanael Nerode <neroden@twcny.rr.com>, <gcc-gnats@gcc.gnu.org>, <gcc-bugs@gcc.gnu.org>, <gcc@gcc.gnu.org> Subject: Re: optimization/6162: gcc 3.0.4: certain i386 asm reloader ice Date: Thu, 31 Oct 2002 00:02:24 +0100 (CET) Hi, On 30 Oct 2002, Torbjorn Granlund wrote: > In GCC, I doubt immediate values will be used for add_ssaaaa. In GMP > immediates are used, but by conventions they are used for the 2nd > operand. > > There are a couple of other packages that use longlong.h as well, but > they don't use immediates. > > I suggest that we don't touch longlong.h, since it is not really a > problem. Well, GNATS 6162 indicates otherwise ;-) But I have no hard feelings either way, we'll get reload aborts if it turns out to be used in unlucky situations. > Who knows, one day GCC might get this right. Hopefully, somewhen, yes ;-) Ciao, Michael.
From: Nathanael Nerode <neroden@twcny.rr.com> To: user42@zip.com.au, gcc-gnats@gcc.gnu.org, gcc-patches@gcc.gnu.org, gcc-bugs@gcc.gnu.org, nobody@gcc.gnu.org Cc: Subject: PATCH: Re: optimization/6162: gcc 3.0.4: certain i386 asm reloader ice Date: Thu, 31 Oct 2002 00:14:20 -0500 Here's a documentation fix. I suspect this is enough to allow the PR to be closed, given that * this asm syntax is a gcc extension, I believe, and as such we can specify it to behave however we like. * the behavior isn't going to change any time in the near future. * in general the problem can be worked around if people are aware of it. http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=6162 PR optimization/6162 * md.texi: Document restriction on commutative operand specification. Index: md.texi =================================================================== RCS file: /cvs/gcc/gcc/gcc/doc/md.texi,v retrieving revision 1.51 diff -u -r1.51 md.texi --- md.texi 15 Sep 2002 22:48:05 -0000 1.51 +++ md.texi 31 Oct 2002 05:09:57 -0000 @@ -1256,6 +1256,8 @@ @dots{}) @end smallexample @end ifset +GCC can only handle one commutative pair in an asm; if you use more, +the compiler may fail. @cindex @samp{#} in constraint @item #
From: Kevin Ryde <user42@zip.com.au> To: Nathanael Nerode <neroden@twcny.rr.com> Cc: gcc-gnats@gcc.gnu.org, gcc-prs@gcc.gnu.org, gcc-bugs@gcc.gnu.org, gcc@gcc.gnu.org Subject: Re: optimization/6162: gcc 3.0.4: certain i386 asm reloader ice Date: Thu, 31 Oct 2002 07:34:55 +1000 Nathanael Nerode <neroden@twcny.rr.com> writes: > > * it only occurs with --fomit-frame-pointer The second (simpler) example I posted does it without that. > I don't think it's reasonable to hold up 3.2.1 or 3.3 for this bug. As far as I can tell you have to be pretty lucky, or unlucky, to actually strike it. I've only had it two (or maybe three) times, and not on finished code.
From: Kevin Ryde <user42@zip.com.au> To: Michael Matz <matz@suse.de> Cc: Nathanael Nerode <neroden@twcny.rr.com>, <gcc-gnats@gcc.gnu.org>, <gcc-prs@gcc.gnu.org>, <gcc-bugs@gcc.gnu.org>, <gcc@gcc.gnu.org>, =?iso-8859-1?q?Torbj=F6rn?= Granlund <tege@swox.com> Subject: Re: optimization/6162: gcc 3.0.4: certain i386 asm reloader ice Date: Thu, 31 Oct 2002 08:20:03 +1000 Michael Matz <matz@suse.de> writes: > > Well, to find it is quite easy. reload is inherently incapable of > handling more than one commutative operand, but there are two of them in > the asm. If you are unlucky both of them would need to be swapped to make > the insn valid, and this is what breaks reload, as it only can swap the > last pair. I don't know why this constraint isn't documented, but anyway, > that's the reason. The stuff in question is from longlong.h actually (shared by GMP and GCC). All the add_ssaaaa's (or it looks like all) have two commutatives.
From: Joe Buck <jbuck@synopsys.com> To: user42@zip.com.au, gcc-gnats@gcc.gnu.org, neroden@twcny.rr.com, gcc-bugs@gcc.gnu.org Cc: Subject: Re: optimization/6162: gcc 3.0.4: certain i386 asm reloader ice Date: Thu, 31 Oct 2002 10:17:02 -0800 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=6162 I don't think that this PR should be closed, because it is an ICE. However, with the documentation fix it should no longer be considered release-blocking. I'll add an item in the release notes and downgrade the priority to "medium".
From: neroden@gcc.gnu.org To: gcc-gnats@gcc.gnu.org Cc: Subject: optimization/6162 Date: 1 Nov 2002 07:05:58 -0000 CVSROOT: /cvs/gcc Module name: gcc Changes by: neroden@gcc.gnu.org 2002-10-31 23:05:58 Modified files: gcc : ChangeLog gcc/doc : md.texi Log message: PR optimization/6162 * md.texi: Document restriction on commutative operand specification. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=1.15832&r2=1.15833 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/doc/md.texi.diff?cvsroot=gcc&r1=1.52&r2=1.53
From: Kevin Ryde <user42@zip.com.au> To: Michael Matz <matz@suse.de> Cc: Nathanael Nerode <neroden@twcny.rr.com>, <gcc-gnats@gcc.gnu.org>, <gcc-prs@gcc.gnu.org>, <gcc-bugs@gcc.gnu.org>, <gcc@gcc.gnu.org>, =?iso-8859-1?q?Torbj=F6rn?= Granlund <tege@swox.com> Subject: Re: optimization/6162: gcc 3.0.4: certain i386 asm reloader ice Date: Sat, 02 Nov 2002 07:40:40 +1000 Michael Matz <matz@suse.de> writes: > > To fix this indeed would be quite involved, as we would need to handle > then all permutations of swappings (of which there are 4 with two pairs). As a suggestion in the interim, perhaps internally all but the last commutative could be quietly dropped. If only the last is acted on now anyway then it'd be no loss, and it'd let applications give full information, if that might be useful in the future.
State-Changed-From-To: open->analyzed State-Changed-Why: Re-confirmed. This had already been marked as "high" before 3.2.1, but had then be downgraded to not hold up the release. It still happens. I change the synopsis of the report to indicate that it is a regression, and re-set it to "high" to force a reevaluation.
From: Dara Hazeghi <dhazeghi@yahoo.com> To: gcc-gnats@gcc.gnu.org Cc: Subject: Re: inline-asm/6162: [3.3/3.4 regression] i386 asm reloader ice in reload_cse_simplify_operands Date: Sat, 10 May 2003 14:16:26 -0700 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit- trail&database=gcc&pr=6162 Hello, I can confirm that this bug is still present in gcc 3.2.3, 3.3 branch and mainline (20030509). Dara
Confirmed with gcc 3.3 branch and mainline (20030604).
This has been downgraded once for 3.2 and then ignored for 3.3, will this bug get fixed or will it be ignored for another major release?
Looks like this was fixed at one point and now is broken again: From Phil's regression hunter: : Search converges between 2003-06-04-trunk (#211) and 2003-06-05-trunk (#212)
This bug has a long history! The solution where only one commutative marker is obeyed makes sense, but it's not worth holding up 3.3.1 for that. So this bug is once again postponed -- until GCC 3.3.2.
And postponed again -- until GCC 3.4.
The date I quoted is the date it was semi fixed as the tree-ssa produced the same ICE untill 2003-11-14. So most likely the bug is still there but the testcase no longer produces an ICE :) (Pushing it to 3.5 as the removal of reload did not make the cut for 3.4 and it no longer ICE's).
The code is indeed invalid now. Moving back the milestone to 3.4.0 since it's still an ICE.
Here is a patch: http://gcc.gnu.org/ml/gcc-patches/2004-01/msg03214.html
Subject: Bug 6162 CVSROOT: /cvs/gcc Module name: gcc Changes by: ian@gcc.gnu.org 2004-01-29 18:40:02 Modified files: gcc : ChangeLog reload.c Log message: PR inline-asm/6162 * reload.c (find_reloads): Only support one pair of commutative operands. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.2553&r2=2.2554 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/reload.c.diff?cvsroot=gcc&r1=1.230&r2=1.231
Changed summary--I checked in a patch so this is no longer a 3.5 regression.
Subject: Bug 6162 CVSROOT: /cvs/gcc Module name: gcc Branch: gcc-3_4-branch Changes by: ian@gcc.gnu.org 2004-02-12 16:07:44 Modified files: gcc : ChangeLog reload.c Log message: PR inline-asm/6162 * reload.c (find_reloads): Only support one pair of commutative operands. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=2.2326.2.185&r2=2.2326.2.186 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/reload.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.229.4.3&r2=1.229.4.4
Fixed for 3.4--changed summary to indicate only 3.3 regression, changed target milestone from 3.4.0 to 3.3.4.
(In reply to comment #28) > Changed summary--I checked in a patch so this is no longer a 3.5 regression. Ian -- You fixed this too in gcc-3.5.x and gcc-3.4.x. I would think the patch would be a good candidate for gcc-3.3.4. Do you concur? -- gaby
Subject: Re: [3.3 regression] i386 asm reloader ice in reload_cse_simplify_operands "gdr at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes: > You fixed this too in gcc-3.5.x and gcc-3.4.x. I would think the patch would > be a good candidate for gcc-3.3.4. Do you concur? Yes. This could be done in a particularly safe manner by not omitting the else if (!this_insn_is_asm) abort (); That is just a sanity check on the gcc sources, and it did trip one case in the MIPS backend. It is not required for correct operation. I'll submit this too. Ian
Subject: Bug 6162 CVSROOT: /cvs/gcc Module name: gcc Branch: gcc-3_3-branch Changes by: ian@gcc.gnu.org 2004-03-05 17:09:47 Modified files: gcc : ChangeLog reload.c Log message: PR inline-asm/6162 * reload.c (find_reloads): Only support one pair of commutative operands. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.16114.2.918&r2=1.16114.2.919 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/reload.c.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.199.2.12&r2=1.199.2.13
Bug is now fixed on 3.3 branch, on 3.4 branch, and on mainline.
Subject: Bug 6162 CVSROOT: /cvs/gcc Module name: gcc Branch: hammer-3_3-branch Changes by: matz@gcc.gnu.org 2004-03-08 10:17:40 Modified files: gcc : ChangeLog.hammer flow.c reload.c Log message: 2004-03-05 Ian Lance Taylor <ian@wasabisystems.com> PR inline-asm/6162 * reload.c (find_reloads): Only support one pair of commutative operands. 2004-02-27 Ian Lance Taylor <ian@wasabisystems.com> PR optimization/7871 * flow.c (mark_set_1): Don't add LOG_LINKS for global registers from or to call insns. 2004-02-27 Eric Botcazou <ebotcazou@libertysurf.fr> PR optimization/7871 * flow.c (propagate_one_insn): Interpret calls as setting global registers, not merely clobbering them. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.hammer.diff?cvsroot=gcc&only_with_tag=hammer-3_3-branch&r1=1.1.2.368&r2=1.1.2.369 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/flow.c.diff?cvsroot=gcc&only_with_tag=hammer-3_3-branch&r1=1.540.2.9&r2=1.540.2.10 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/reload.c.diff?cvsroot=gcc&only_with_tag=hammer-3_3-branch&r1=1.197.2.13&r2=1.197.2.14