public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* Re: optimization/6162: gcc 3.0.4: certain i386 asm reloader ice
@ 2002-10-24 17:06 Kevin Ryde
0 siblings, 0 replies; 15+ messages in thread
From: Kevin Ryde @ 2002-10-24 17:06 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR optimization/6162; it has been noted by GNATS.
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).
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: optimization/6162: gcc 3.0.4: certain i386 asm reloader ice
@ 2002-11-01 13:46 Kevin Ryde
0 siblings, 0 replies; 15+ messages in thread
From: Kevin Ryde @ 2002-11-01 13:46 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR optimization/6162; it has been noted by GNATS.
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.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: optimization/6162: gcc 3.0.4: certain i386 asm reloader ice
@ 2002-10-31 10:26 Joe Buck
0 siblings, 0 replies; 15+ messages in thread
From: Joe Buck @ 2002-10-31 10:26 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR optimization/6162; it has been noted by GNATS.
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".
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: optimization/6162: gcc 3.0.4: certain i386 asm reloader ice
@ 2002-10-30 15:06 Michael Matz
0 siblings, 0 replies; 15+ messages in thread
From: Michael Matz @ 2002-10-30 15:06 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR optimization/6162; it has been noted by GNATS.
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.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: optimization/6162: gcc 3.0.4: certain i386 asm reloader ice
@ 2002-10-30 14:56 Torbjorn Granlund
0 siblings, 0 replies; 15+ messages in thread
From: Torbjorn Granlund @ 2002-10-30 14:56 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3497 bytes --]
The following reply was made to PR optimization/6162; it has been noted by GNATS.
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: optimization/6162: gcc 3.0.4: certain i386 asm reloader ice
@ 2002-10-30 14:46 Michael Matz
0 siblings, 0 replies; 15+ messages in thread
From: Michael Matz @ 2002-10-30 14:46 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR optimization/6162; it has been noted by GNATS.
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.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: optimization/6162: gcc 3.0.4: certain i386 asm reloader ice
@ 2002-10-30 14:26 Kevin Ryde
0 siblings, 0 replies; 15+ messages in thread
From: Kevin Ryde @ 2002-10-30 14:26 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR optimization/6162; it has been noted by GNATS.
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.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: optimization/6162: gcc 3.0.4: certain i386 asm reloader ice
@ 2002-10-30 14:16 Michael Matz
0 siblings, 0 replies; 15+ messages in thread
From: Michael Matz @ 2002-10-30 14:16 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR optimization/6162; it has been noted by GNATS.
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.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: optimization/6162: gcc 3.0.4: certain i386 asm reloader ice
@ 2002-10-30 13:36 Kevin Ryde
0 siblings, 0 replies; 15+ messages in thread
From: Kevin Ryde @ 2002-10-30 13:36 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR optimization/6162; it has been noted by GNATS.
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.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: optimization/6162: gcc 3.0.4: certain i386 asm reloader ice
@ 2002-10-30 12:36 Nathanael Nerode
0 siblings, 0 replies; 15+ messages in thread
From: Nathanael Nerode @ 2002-10-30 12:36 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR optimization/6162; it has been noted by GNATS.
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: optimization/6162: gcc 3.0.4: certain i386 asm reloader ice
@ 2002-10-24 22:46 Andreas Jaeger
0 siblings, 0 replies; 15+ messages in thread
From: Andreas Jaeger @ 2002-10-24 22:46 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR optimization/6162; it has been noted by GNATS.
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: optimization/6162: gcc 3.0.4: certain i386 asm reloader ice
@ 2002-10-24 22:39 aj
0 siblings, 0 replies; 15+ messages in thread
From: aj @ 2002-10-24 22:39 UTC (permalink / raw)
To: gcc-bugs, gcc-prs, nobody, user42
Synopsis: gcc 3.0.4: certain i386 asm reloader ice
State-Changed-From-To: closed->open
State-Changed-By: aj
State-Changed-When: Thu Oct 24 22:39:42 2002
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
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=6162
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: optimization/6162: gcc 3.0.4: certain i386 asm reloader ice
@ 2002-10-10 11:06 hubicka
0 siblings, 0 replies; 15+ messages in thread
From: hubicka @ 2002-10-10 11:06 UTC (permalink / raw)
To: gcc-bugs, gcc-prs, nobody, user42
Synopsis: gcc 3.0.4: certain i386 asm reloader ice
State-Changed-From-To: open->closed
State-Changed-By: hubicka
State-Changed-When: Thu Oct 10 11:06:39 2002
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)
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=6162
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: optimization/6162: gcc 3.0.4: certain i386 asm reloader ice
@ 2002-08-02 16:06 Kevin Ryde
0 siblings, 0 replies; 15+ messages in thread
From: Kevin Ryde @ 2002-08-02 16:06 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR optimization/6162; it has been noted by GNATS.
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
--=-=-=--
^ permalink raw reply [flat|nested] 15+ messages in thread
* optimization/6162: gcc 3.0.4: certain i386 asm reloader ice
@ 2002-04-03 16:26 Kevin Ryde
0 siblings, 0 replies; 15+ messages in thread
From: Kevin Ryde @ 2002-04-03 16:26 UTC (permalink / raw)
To: gcc-gnats
>Number: 6162
>Category: optimization
>Synopsis: gcc 3.0.4: certain i386 asm reloader ice
>Confidential: no
>Severity: serious
>Priority: low
>Responsible: unassigned
>State: open
>Class: ice-on-legal-code
>Submitter-Id: net
>Arrival-Date: Wed Apr 03 16:26:00 PST 2002
>Closed-Date:
>Last-Modified:
>Originator:
>Release: 3.0.4 (Debian testing/unstable)
>Organization:
>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
>Description:
On i386, a certain slightly convoluted combination of variables and
asm blocks provokes an ICE from gcc under "-O -fomit-frame-pointer".
>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).
--=-=-=
Content-Type: text/x-csrc
Content-Disposition: attachment; filename=foo.c
typedef unsigned * mp_ptr;
typedef const unsigned * mp_srcptr;
void __gmpn_tdiv_qr (mp_ptr, mp_ptr, long, mp_srcptr, long, mp_srcptr, long);
void __gmp_assert_fail (const char *filename, int linenum, const char *expr)
__attribute__ ((noreturn));
unsigned
__gmpn_divrem_1 (mp_ptr qp, long xsize,
mp_srcptr ap, long size, unsigned d)
{
long total_size;
long i;
unsigned dinvh, dinvl;
unsigned r;
do {
if (!(xsize >= 0))
__gmp_assert_fail ("divrem_1_two_ice.c", 179, "xsize >= 0");
} while (0);
do {
if (!(size >= 0))
__gmp_assert_fail ("divrem_1_two_ice.c", 180, "size >= 0");
} while (0);
do {
if (!(d != 0))
__gmp_assert_fail ("divrem_1_two_ice.c", 181, "d != 0");
} while (0);
do {
if (!(((qp+xsize) == (ap) || ! ((qp+xsize) + (size) > (ap) && (ap) + (size) > (qp+xsize)))))
__gmp_assert_fail ("divrem_1_two_ice.c", 183, "((qp+xsize) == (ap) || ! ((qp+xsize) + (size) > (ap) && (ap) + (size) > (qp+xsize)))");
} while (0);
total_size = size + xsize;
if (total_size == 0)
return 0;
qp += (total_size - 1);
if ((d & ((~ (unsigned) 0) ^ ((~ (unsigned) 0) >> 1))) != 0)
{
do {
unsigned a[4];
unsigned q[3];
unsigned d_array[2];
unsigned r_dummy[2];
do {
if (!(((d) & ((~ (unsigned) 0) ^ ((~ (unsigned) 0) >> 1))) != 0))
__gmp_assert_fail ("divrem_1_two_ice.c", 193, "((d) & ((~ (unsigned) 0) ^ ((~ (unsigned) 0) >> 1))) != 0");
} while (0);
a[0] = (~ (unsigned) 0);
a[1] = (~ (unsigned) 0);
a[2] = (~ (unsigned) 0);
a[3] = (~ (unsigned) 0);
d_array[0] = 0L;
d_array[1] = d;
__gmpn_tdiv_qr (q, r_dummy, (long) 0, a, (long) 4, d_array, (long) 2);
do {
if (!(q[2] == 1))
__gmp_assert_fail ("divrem_1_two_ice.c", 193, "q[2] == 1");
} while (0);
dinvl = q[0];
dinvh = q[1];
} while (0);
i = size-1;
r = 0;
if (i > 0)
{
r = ap[i];
if (r < d)
i--;
}
while (i >= 1)
{
do {
unsigned _n2h = (r);
unsigned _n2l = (ap[i]);
unsigned _n10h = (ap[i-1]);
unsigned _d = (d);
unsigned _n1, _nadjh, _sumh, _suml, _q1h, _q1l, _mask, _r;
unsigned _x3, _x2, _x1, _x0;
_n1 = _n10h >> ((8*4) - 1);
_nadjh = _n10h + (-_n1 & _d);
__asm__ ("subl %5,%1\n\tsbbl %3,%0"
: "=r" ((unsigned)(_sumh)), "=&r" ((unsigned)(_suml))
: "0" ((unsigned)(_n2h)), "g" ((unsigned)(0)),
"1" ((unsigned)(_n2l)), "g" ((unsigned)(_n1)));
do {
unsigned _xh = (dinvh);
unsigned _xl = (dinvl);
unsigned _yh = (_sumh);
unsigned _yl = (_suml);
unsigned _mh, _ml;
__asm__ ("mull %3"
: "=a" (_x0), "=d" (_x1)
: "%0" ((unsigned)(_xl)),
"rm" ((unsigned)(_yl)));
__asm__ ("mull %3"
: "=a" (_x2), "=d" (_x3)
: "%0" ((unsigned)(_xh)), "rm" ((unsigned)(_yh)));
__asm__ ("mull %3"
: "=a" (_ml), "=d" (_mh)
: "%0" ((unsigned)(_xh)), "rm" ((unsigned)(_yl)));
do {
unsigned _c1, _s0;
__asm__ ("addl %5,%1\n\tadcl %3,%0"
: "=r" ((unsigned)(_c1)), "=&r" ((unsigned)(_s0))
: "%0" ((unsigned)(0)), "g" ((unsigned)(0)),
"%1" ((unsigned)(_x1)), "g" ((unsigned)(_ml)));
__asm__ ("addl %5,%1\n\tadcl %3,%0"
: "=r" ((unsigned)(_x3)), "=&r" ((unsigned)(_x2))
: "%0" ((unsigned)(_x3)), "g" ((unsigned)(0)),
"%1" ((unsigned)(_x2)), "g" ((unsigned)(_mh)));
__asm__ ("addl %5,%1\n\tadcl %3,%0"
: "=r" ((unsigned)(_x3)), "=&r" ((unsigned)(_x2))
: "%0" ((unsigned)(_x3)), "g" ((unsigned)(0)),
"%1" ((unsigned)(_x2)), "g" ((unsigned)(_c1)));
(_x1) = _s0;
} while (0);
__asm__ ("mull %3"
: "=a" (_ml), "=d" (_mh)
: "%0" ((unsigned)(_xl)), "rm" ((unsigned)(_yh)));
do {
unsigned _c1, _s0;
__asm__ ("addl %5,%1\n\tadcl %3,%0"
: "=r" ((unsigned)(_c1)), "=&r" ((unsigned)(_s0))
: "%0" ((unsigned)(0)), "g" ((unsigned)(0)),
"%1" ((unsigned)(_x1)), "g" ((unsigned)(_ml)));
__asm__ ("addl %5,%1\n\tadcl %3,%0"
: "=r" ((unsigned)(_x3)), "=&r" ((unsigned)(_x2))
: "%0" ((unsigned)(_x3)), "g" ((unsigned)(0)),
"%1" ((unsigned)(_x2)), "g" ((unsigned)(_mh)));
__asm__ ("addl %5,%1\n\tadcl %3,%0"
: "=r" ((unsigned)(_x3)), "=&r" ((unsigned)(_x2))
: "%0" ((unsigned)(_x3)), "g" ((unsigned)(0)),
"%1" ((unsigned)(_x2)), "g" ((unsigned)(_c1)));
(_x1) = _s0;
} while (0);
} while (0);
__asm__ ("addl %5,%1\n\tadcl %3,%0"
: "=r" ((unsigned) (_q1h)),
"=&r" ((unsigned) (_q1l))
: "%0" ((unsigned) (_n2h)),
"g" ((unsigned) (_x3)),
"%1" ((unsigned) (_n2l)),
"g" ((unsigned) (_x2)));
__asm__ ("addl %5,%1\n\tadcl %3,%0"
: "=r" ((unsigned)(_q1h)), "=&r" ((unsigned)(_q1l))
: "%0" ((unsigned)(_q1h)), "g" ((unsigned)(0)),
"%1" ((unsigned)(_q1l)), "g" ((unsigned)(1)));
__asm__ ("mull %3"
: "=a" (_x1), "=d" (_x2)
: "%0" ((unsigned)(_q1l)), "rm" ((unsigned)(_d)));
_x2 += _q1h * _d;
__asm__ ("subl %5,%1\n\tsbbl %3,%0"
: "=r" ((unsigned)(_mask)), "=&r" ((unsigned)(_r))
: "0" ((unsigned)(_n2l)), "g" ((unsigned)(_x2)),
"1" ((unsigned)(_n10h)), "g" ((unsigned)(_x1)));
do {
if (!(_mask == 0 || _mask == (~ (unsigned) 0)))
__gmp_assert_fail ("divrem_1_two_ice.c", 243, "_mask == 0 || _mask == (~ (unsigned) 0)");
} while (0);
(r) = _r + (_mask & _d);
__asm__ ("subl %5,%1\n\tsbbl %3,%0"
: "=r" ((unsigned)(qp[0])), "=&r" ((unsigned)(qp[-1]))
: "0" ((unsigned)(_q1h)), "g" ((unsigned)(0)),
"1" ((unsigned)(_q1l)), "g" ((unsigned)(-_mask)));
} while (0);
qp -= 2;
i -= 2;
}
}
else
{
r = 0;
}
return r;
}
--=-=-=--
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted:
--=-=-=
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2002-11-01 21:46 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-10-24 17:06 optimization/6162: gcc 3.0.4: certain i386 asm reloader ice Kevin Ryde
-- strict thread matches above, loose matches on Subject: below --
2002-11-01 13:46 Kevin Ryde
2002-10-31 10:26 Joe Buck
2002-10-30 15:06 Michael Matz
2002-10-30 14:56 Torbjorn Granlund
2002-10-30 14:46 Michael Matz
2002-10-30 14:26 Kevin Ryde
2002-10-30 14:16 Michael Matz
2002-10-30 13:36 Kevin Ryde
2002-10-30 12:36 Nathanael Nerode
2002-10-24 22:46 Andreas Jaeger
2002-10-24 22:39 aj
2002-10-10 11:06 hubicka
2002-08-02 16:06 Kevin Ryde
2002-04-03 16:26 Kevin Ryde
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).