Bug 11897 - internal compiler error: in gen_nop_type, at config/ia64/ia64.c:6929
Summary: internal compiler error: in gen_nop_type, at config/ia64/ia64.c:6929
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 3.3
: P2 normal
Target Milestone: 3.3.1
Assignee: Not yet assigned to anyone
URL:
Keywords: ice-on-valid-code
Depends on:
Blocks:
 
Reported: 2003-08-12 19:12 UTC by Stephane Eranian
Modified: 2005-07-23 22:49 UTC (History)
1 user (show)

See Also:
Host: ia64-linux
Target: ia64-linux
Build: gcc version 3.3 20030415 (Debian prerelease)
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Stephane Eranian 2003-08-12 19:12:46 UTC
Gcc-3.3 and gcc-3.2 get a fatal error compiling the certain versions
of the linux-2.4.21 kernel for the arch/ia64/m/init.c file.

The compiler error message is:
internal compiler error: in gen_nop_type, at config/ia64/ia64.c:6929

The compiler is invoked as follows:
$ gcc-3.3 -D__KERNEL__ -I/data2/eranian/suse/build.2421-perfmon/include -Wall
-Wstrict-prototypes -Wno-trigraphs -O3 -fno-strict-aliasing -fno-common
-fomit-frame-pointer -pipe -ffixed-r13 -mfixed-range=f10-f15,f32-f127
-falign-functions=32 -frename-registers --param max-inline-insns=5000
-mconstant-gp -nostdinc -iwithprefix include -DKBUILD_BASENAME=init
-DEXPORT_SYMTAB -c t.c

Dropping the optimization level to -O1 fixes the problem for both gcc3.2 and 3.3.

The small test programs is as follows:

// -- cut here
typedef unsigned long __u64;
typedef struct { unsigned long pte; } pte_t;
typedef struct { unsigned long pgprot; } pgprot_t;

typedef union ia64_va {
        struct {
                unsigned long off : 61;
                unsigned long reg : 3;
        } f;
        unsigned long l;
        void *p;
} ia64_va;

extern void panic(const char * fmt, ...);


static inline void
ia64_set_rr (__u64 reg_bits, __u64 rr_val)
{
        asm volatile ("mov rr[%0]=%1" :: "r"(reg_bits), "r"(rr_val) : "memory");
}

static inline void
ia64_itr (__u64 target_mask, __u64 tr_num,
          __u64 vmaddr, __u64 pte,
          __u64 log_page_size)
{
        asm volatile ("mov cr.itir=%0" :: "r"(log_page_size << 2) : "memory");
        asm volatile ("mov cr.ifa=%0;;" :: "r"(vmaddr) : "memory");
        if (target_mask & 0x1)
                asm volatile ("itr.i itr[%0]=%1"
                                      :: "r"(tr_num), "r"(pte) : "memory");
        if (target_mask & 0x2)
                asm volatile (";;itr.d dtr[%0]=%1"
                                      :: "r"(tr_num), "r"(pte) : "memory");
}

static inline void
ia64_srlz_i (void)
{
        asm volatile (";; srlz.i ;;" ::: "memory");
}

void __attribute__ ((__section__ (".text.init")))
ia64_mmu_init (void *my_cpu_data)
{
        unsigned long rid, impl_va_bits = 0;


        rid = (((0) << 3) | (0xc000000000000000 >> 61));
        ia64_set_rr(0xc000000000000000, (rid << 8) | (24 << 2));

        rid = (((0) << 3) | ((0xa000000000000000 + 3*(1UL << 14)) >> 61));
        ia64_set_rr((0xa000000000000000 + 3*(1UL << 14)), (rid << 8) | (14 << 2)
| 1);

	ia64_srlz_i();

        ia64_itr(0x2, 1, (0xa000000000000000 + 2*(1UL << 14)),
                 ((({ pte_t __pte; ((__pte).pte) = ({ia64_va _v; asm("tpa %0=%1"
: "=r"(_v.l) : "r"(my_cpu_data)); _v.l;}) + ((((pgprot_t) { ((((unsigned
long)(1)) << 52) | (1 << 5) | (1 << 0) | (1 << 6) | (0x0 << 2) | (0 << 7) | (3
<< 9)) } )).pgprot); __pte; })).pte), 14);

        if (impl_va_bits < 51 || impl_va_bits > 61)
                panic("CPU has bogus IMPL_VA_MSB value of %lu!\n", impl_va_bits
- 1);

}
Comment 1 Andrew Pinski 2003-08-12 20:16:23 UTC
I think this is a dup of bug 11693 which is fixed for 3.3.2.
Can you try this patch <http://gcc.gnu.org/ml/gcc-patches/2003-08/msg00621.html> and see if 
that fixes it?
Comment 2 Andrew Pinski 2003-08-17 20:11:23 UTC
This made it to my mailbox:
Thanks for your answer, I will try the 3.3.2 tree, compile and try it 
on the test program.
Comment 3 Andrew Pinski 2003-08-20 00:47:42 UTC
From my private mailbox, this is fixed already for 3.3.1:
Hi,

I got a chance to try gcc-3.3.1 and it does not exhibit the problem when 
compiling the same test case at -O2 -O3. So something must have changed
in that area between 3.3 and 3.3.1.

Thanks.