Simple code produces ICE in gcc-3.2.1

Simple code produces ICE in gcc-3.2.1

[Steve Kargl]

The code fragment below causes an ICE if
k = 1.  No ICE occurs if k = 0 or the 
optimization level is -O0 or -O1.

troutmask:kargl[205] gcc -O2 -c c.c
c.c: In function `ice':
c.c:11: unrecognizable insn:
(insn 179 170 188 (set (reg:SI 85)
        (ashift:SI (reg/v:SI 62)
            (const_int 1 [0x1]))) -1 (nil)
    (nil))
c.c:11: Internal compiler error in extract_insn, at recog.c:2150
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.


kargl[203] gcc -v
Using built-in specs.
Configured with: FreeBSD/i386 system compiler
Thread model: posix
gcc version 3.2.1 [FreeBSD] 20021009 (prerelease)

-- 
Steve

void ice(int m, int n, double *f) {

	int i, j, k;

    /* k = 0;  No ICE */
    k = 1;  /* ICE */

    for (j = 0; j < n; j++) {
        for (i = k; i < m; i++) {
            f[i] = (double) (i * j);
            f[i + j] = (double) ((i + 1) * j);
        }
    }
}

Re: Simple code produces ICE in gcc-3.2.1

[Andrew Pinski]

This also happens on a i686-pc-linux-gnu gcc 3.3,
but does not happen on a i686-pc-linux-gnu gcc 3.1.1
so it is a regression report it to the bug system, please.

3.3's version:
gcc version 3.3 20021023 (experimental)



Thanks,
Andrew Pinski

On Wednesday, Oct 23, 2002, at 22:01 US/Pacific, Steve Kargl wrote:

> The code fragment below causes an ICE if
> k = 1.  No ICE occurs if k = 0 or the
> optimization level is -O0 or -O1.
>
> troutmask:kargl[205] gcc -O2 -c c.c
> c.c: In function `ice':
> c.c:11: unrecognizable insn:
> (insn 179 170 188 (set (reg:SI 85)
>         (ashift:SI (reg/v:SI 62)
>             (const_int 1 [0x1]))) -1 (nil)
>     (nil))
> c.c:11: Internal compiler error in extract_insn, at recog.c:2150
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.
>
>
> kargl[203] gcc -v
> Using built-in specs.
> Configured with: FreeBSD/i386 system compiler
> Thread model: posix
> gcc version 3.2.1 [FreeBSD] 20021009 (prerelease)
>
> -- 
> Steve
>
> void ice(int m, int n, double *f) {
>
> 	int i, j, k;
>
>     /* k = 0;  No ICE */
>     k = 1;  /* ICE */
>
>     for (j = 0; j < n; j++) {
>         for (i = k; i < m; i++) {
>             f[i] = (double) (i * j);
>             f[i + j] = (double) ((i + 1) * j);
>         }
>     }
> }
>
>

Re: Simple code produces ICE in gcc-3.2.1

[Steve Kargl]

On Wed, Oct 23, 2002 at 10:15:22PM -0700, Andrew Pinski wrote:
> This also happens on a i686-pc-linux-gnu gcc 3.3,
> but does not happen on a i686-pc-linux-gnu gcc 3.1.1
> so it is a regression report it to the bug system, please.
> 
> 3.3's version:
> gcc version 3.3 20021023 (experimental)
> 
> 

I did.  I sent email to gcc-bugs@gcc.gnu.org
with a much more complicated test case.  It
took me several hours to distill the simple
code and I just sent email to gcc@gcc.gnu.org.

David O'Brien and Alexander Kabaev (sp?) have
done a marvelous job of looking after gcc.  
With FreeBSD 5.0 scheduled for released in 
the next month (or so) and with my simple
test case, I'm hoping that David or Alexander
can use the info to help fix the problem.  My
spelunking in the bowels of gcc have been
less than fruitful.

-- 
Steve

Re: Simple code produces ICE in gcc-3.2.1

[Andreas Jaeger]

Steve Kargl <sgk@troutmask.apl.washington.edu> writes:

> On Wed, Oct 23, 2002 at 10:15:22PM -0700, Andrew Pinski wrote:
>> This also happens on a i686-pc-linux-gnu gcc 3.3,
>> but does not happen on a i686-pc-linux-gnu gcc 3.1.1
>> so it is a regression report it to the bug system, please.
>> 
>> 3.3's version:
>> gcc version 3.3 20021023 (experimental)
>> 
>> 
>
> I did.  I sent email to gcc-bugs@gcc.gnu.org

Did you file it with gnats to our bug database?  An email sent to
gcc-bugs will be lost, it really needs to be in the database.  Use
gccbug or the web interface to gnats to file the report,

Thanks,
Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: Simple code produces ICE in gcc-3.2.1

[Steve Kargl]

On Thu, Oct 24, 2002 at 08:11:09AM +0200, Andreas Jaeger wrote:
> Steve Kargl <sgk@troutmask.apl.washington.edu> writes:
> 
> > On Wed, Oct 23, 2002 at 10:15:22PM -0700, Andrew Pinski wrote:
> >> This also happens on a i686-pc-linux-gnu gcc 3.3,
> >> but does not happen on a i686-pc-linux-gnu gcc 3.1.1
> >> so it is a regression report it to the bug system, please.
> >> 
> >> 3.3's version:
> >> gcc version 3.3 20021023 (experimental)
> >> 
> >> 
> >
> > I did.  I sent email to gcc-bugs@gcc.gnu.org
> 
> Did you file it with gnats to our bug database?  An email sent to
> gcc-bugs will be lost, it really needs to be in the database.  Use
> gccbug or the web interface to gnats to file the report,
> 

Man, the gnatsweb interface real sucks.  After 6 hours
of reducing a rather complex chuck of code to 10 lines.
I had to try 4 times to get a report filed.

Why offer a priority field of "high" if it can't be
set?  Why have a submitter-id field when only a 
single choice is validate?  Why ask for the release
info when you also ask for the output of gcc -v?

Look for a PR with the same subject line.  The
GNATS system hasn't registered my PR, yet.

-- 
Steve

Re: Simple code produces ICE in gcc-3.2.1

[Richard Henderson]

On Wed, Oct 23, 2002 at 11:52:15PM -0700, Steve Kargl wrote:
> Why offer a priority field of "high" if it can't be set?

Because the maintainers can set it, but you can't.

> Why have a submitter-id field when only a single choice is validate?

No idea.

> Why ask for the release info when you also ask for the output of gcc -v?

So that one can quickly scan to see what release the PR applies to.


r~

Re: Simple code produces ICE in gcc-3.2.1

[Steve Kargl]

On Thu, Oct 24, 2002 at 03:31:33PM -0700, Richard Henderson wrote:
> On Wed, Oct 23, 2002 at 11:52:15PM -0700, Steve Kargl wrote:
> > Why offer a priority field of "high" if it can't be set?
> 
> Because the maintainers can set it, but you can't.
> 
> > Why have a submitter-id field when only a single choice is validate?
> 
> No idea.
> 
> > Why ask for the release info when you also ask for the output of gcc -v?
> 
> So that one can quickly scan to see what release the PR applies to.
> 
> 

I've determined that the change that is causing the
ICE went into the gcc-3.2 branch between the 8th
of Octber and the 10th.  In another 2 hours or
so, I'll I know what is the actual cause.

-- 
Steve

Re: Simple code produces ICE in gcc-3.2.1

[Eric Botcazou]

> I've determined that the change that is causing the
> ICE went into the gcc-3.2 branch between the 8th
> of Octber and the 10th.  In another 2 hours or
> so, I'll I know what is the actual cause.

My patch for PR c/7411. The problem was detected by Andreas about one week
ago, and Jan Hubicka quickly proposed a fix, that Richard Henderson
suggested to improve. As it seems there has been no activity since then, I'm
going to test the fix.
http://gcc.gnu.org/ml/gcc-patches/2002-10/msg01098.html

--
Eric Botcazou

Re: Simple code produces ICE in gcc-3.2.1

[Steve Kargl]

On Fri, Oct 25, 2002 at 10:16:39AM +0200, Eric Botcazou wrote:
> > I've determined that the change that is causing the
> > ICE went into the gcc-3.2 branch between the 8th
> > of Octber and the 10th.  In another 2 hours or
> > so, I'll I know what is the actual cause.
> 
> My patch for PR c/7411. The problem was detected by Andreas about one week
> ago, and Jan Hubicka quickly proposed a fix, that Richard Henderson
> suggested to improve. As it seems there has been no activity since then, I'm
> going to test the fix.
> http://gcc.gnu.org/ml/gcc-patches/2002-10/msg01098.html
> 

Thanks.  I misread one of my cvs chechkouts and
I should have given the range of the 6th to the
10th of October.  Hopefully, I didn't send you
on a wild goose chase.

-- 
Steve

Re: Simple code produces ICE in gcc-3.2.1

[Phil Edwards]

On Thu, Oct 24, 2002 at 03:31:33PM -0700, Richard Henderson wrote:
> On Wed, Oct 23, 2002 at 11:52:15PM -0700, Steve Kargl wrote:
> 
> > Why have a submitter-id field when only a single choice is validate?
> 
> No idea.

Just a holdover from GNATS.  (Well, the original GNATS submit programs would
use this field; the frontend that we have now just fills in one value.)

-- 
I would therefore like to posit that computing's central challenge, viz. "How
not to make a mess of it," has /not/ been met.
                                                 - Edsger Dijkstra, 1930-2002

Re: Simple code produces ICE in gcc-3.2.1

[Ben Elliston]

>>>>> "Phil" == Phil Edwards <phil@jaj.com> writes:

  Phil> Just a holdover from GNATS.  (Well, the original GNATS submit
  Phil> programs would use this field; the frontend that we have now
  Phil> just fills in one value.)

If I recall correctly, this field was used in PRMS/GNATS to store a
pre-determined identifier for a customer or site.  Since we don't know
who the submitters on the net are in advance, it only makes sense to
have one value for this field.

Ben