Re: optimization/6162: gcc 3.0.4: certain i386 asm reloader ice

Re: optimization/6162: gcc 3.0.4: certain i386 asm reloader ice

[Kevin Ryde]

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
 
 --=-=-=--

Re: optimization/6162: gcc 3.0.4: certain i386 asm reloader ice

[Kevin Ryde]

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.

Re: optimization/6162: gcc 3.0.4: certain i386 asm reloader ice

[Joe Buck]

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".
 

Re: optimization/6162: gcc 3.0.4: certain i386 asm reloader ice

[Michael Matz]

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.
 

Re: optimization/6162: gcc 3.0.4: certain i386 asm reloader ice

[Torbjorn Granlund]

[-- 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

Re: optimization/6162: gcc 3.0.4: certain i386 asm reloader ice

[Michael Matz]

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.
 

Re: optimization/6162: gcc 3.0.4: certain i386 asm reloader ice

[Kevin Ryde]

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.

Re: optimization/6162: gcc 3.0.4: certain i386 asm reloader ice

[Michael Matz]

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.
 

Re: optimization/6162: gcc 3.0.4: certain i386 asm reloader ice

[Kevin Ryde]

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.

Re: optimization/6162: gcc 3.0.4: certain i386 asm reloader ice

[Nathanael Nerode]

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
 

Re: optimization/6162: gcc 3.0.4: certain i386 asm reloader ice

[Andreas Jaeger]

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

Re: optimization/6162: gcc 3.0.4: certain i386 asm reloader ice

[aj]

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

Re: optimization/6162: gcc 3.0.4: certain i386 asm reloader ice

[Kevin Ryde]

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).

Re: optimization/6162: gcc 3.0.4: certain i386 asm reloader ice

[hubicka]

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

optimization/6162: gcc 3.0.4: certain i386 asm reloader ice

[Kevin Ryde]

>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:
 --=-=-=