First Last Prev Next    No search results available      Search page      Enter new bug
Bug#: 28376
Product:  
Component:  
Status: RESOLVED
Resolution: FIXED
Assigned To: Not yet assigned to anyone <unassigned@gcc.gnu.org>
Host:
Reported against  
Priority:  
Severity:  
Target Milestone:  
 
 
Target:
Reporter: Mike Frysinger <vapier@gentoo.org>
Add CC:
CC:
Remove selected CCs
Build:
URL:
Summary:
Keywords:
Known to work:
Known to fail:

Attachment Description Type Created Size Actions
PR28376.ii PR28376.ii text/plain 2006-07-14 02:42 163 bytes Edit
Create a New Attachment (proposed patch, testcase, etc.) View All

Bug 28376 depends on: 13031 Show dependency tree
Show dependency graph
Bug 28376 blocks:

Additional Comments:






View Bug Activity   |   Format For Printing   |   Clone This Bug

Description:   Last confirmed: Opened: 2006-07-14 02:41 
when building opensp with gcc-4.1.1 and -O3 on alpha, gcc ICEs:

ice.ii: In function 'void __static_initialization_and_destruction_0(int, int)':
ice.ii:13: error: unrecognizable insn:
(insn 23 22 24 2 (set (reg:DI 84)
        (leu:DI (const_int 0 [0x0])
            (const_int 4 [0x4]))) -1 (nil)
    (nil))
ice.ii:13: internal compiler error: in extract_insn, at recog.c:2084

verified on Gentoo and Debian that 4.0.3 works, 4.1.1 fails, 4.2 works

------- Comment #1 From Mike Frysinger 2006-07-14 02:42 ------- 
Created an attachment (id=11887) [edit]
PR28376.ii

------- Comment #2 From Andrew Pinski 2006-07-14 03:45 ------- 
(In reply to comment #0)
> ice.ii:13: error: unrecognizable insn:
> (insn 23 22 24 2 (set (reg:DI 84)
>         (leu:DI (const_int 0 [0x0])
>             (const_int 4 [0x4]))) -1 (nil)
>     (nil))

This should never have showed up as that is a constant.  I wonder how much
related to PR13031 this really is.

------- Comment #3 From Falk Hueffner 2006-07-14 08:08 ------- 
This simplified test case ICEs already at -O:

static const long unsigned sizes[] = { 4, 8 };
static long unsigned maxSize(const long unsigned *v) {
        unsigned long max = 0;
        unsigned long i = 0;
        for (; i < 2; i++)
                if (v[i] > max)
                        max = v[i];
        return max;
}
unsigned long a = maxSize(sizes);

00.expand already contains the unfolded leu. I suppose this is not valid RTL?

4.2 does not exhibit this bug.

------- Comment #4 From Andrew Pinski 2006-07-14 08:20 ------- 
(In reply to comment #3)
> This simplified test case ICEs already at -O:
> 
> 00.expand already contains the unfolded leu. I suppose this is not valid RTL?

I think this is a case where we unroll the loop but don't do store-CCP after
the unroller so we can get expand looks into sizes for the value but then we
don't call simplify-rtx before emitting (which seems wrong).

------- Comment #5 From Joseph S. Myers 2008-07-04 15:41 ------- 
Closing 4.1 branch.
First Last Prev Next    No search results available      Search page      Enter new bug