gcc-4.1-20050709: ICE in loop_givs_rescan, at loop.c:5517

gcc-4.1-20050709: ICE in loop_givs_rescan, at loop.c:5517

[Dan Kegel]

I can't build gcc-4.1-20050709 for target arm; it fails with

gcc-4.1-20050709/libiberty/cp-demangle.c: In function 'd_print_comp':
gcc-4.1-20050709/libiberty/cp-demangle.c:3342: internal compiler error: in loop_givs_rescan, at loop.c:5517

Compiling the same version of gcc for i686 manages
to avoid that error somehow, but it pops up later
building the Linux kernel:

mm/page_alloc.c: In function 'setup_per_zone_lowmem_reserve':
mm/page_alloc.c:1940: internal compiler error: in loop_givs_rescan, at loop.c:5517

Likewise, compiling that version of gcc for alpha
dies while building the linux kernel, but for a different reason:

{standard input}:496: Error: macro requires $at register while noat in effect
make[1]: *** [arch/alpha/kernel/core_cia.o] Error 1

Sigh.  I'll file bugs with preprocessed source tomorrow.
Stage 3 is certainly starting with a bang.
- Dan

-- 
Trying to get a job as a c++ developer?  See http://kegel.com/academy/getting-hired.html

Re: gcc-4.1-20050709: ICE in loop_givs_rescan, at loop.c:5517

[Joseph S. Myers]

On Sat, 9 Jul 2005, Dan Kegel wrote:

> I can't build gcc-4.1-20050709 for target arm; it fails with
> 
> gcc-4.1-20050709/libiberty/cp-demangle.c: In function 'd_print_comp':
> gcc-4.1-20050709/libiberty/cp-demangle.c:3342: internal compiler error: in
> loop_givs_rescan, at loop.c:5517

Kazu already filed bug 22384 for this issue.

-- 
Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
    jsm@polyomino.org.uk (personal mail)
    joseph@codesourcery.com (CodeSourcery mail)
    jsm28@gcc.gnu.org (Bugzilla assignments and CCs)

Re: gcc-4.1-20050709: ICE in loop_givs_rescan, at loop.c:5517

[Falk Hueffner]

Dan Kegel <dank@kegel.com> writes:

> Likewise, compiling that version of gcc for alpha
> dies while building the linux kernel, but for a different reason:
>
> {standard input}:496: Error: macro requires $at register while noat in effect
> make[1]: *** [arch/alpha/kernel/core_cia.o] Error 1

This doesn't really sound like a gcc bug, rather like an invalid asm,
or bad options passed to as. But it's impossible to tell without a
test case.

-- 
	Falk

Re: gcc-4.1-20050709: ICE in loop_givs_rescan, at loop.c:5517

[Dan Kegel]

Falk Hueffner wrote:
> Dan Kegel <dank@kegel.com> writes:
> 
> 
>>Likewise, compiling that version of gcc for alpha
>>dies while building the linux kernel, but for a different reason:
>>
>>{standard input}:496: Error: macro requires $at register while noat in effect
>>make[1]: *** [arch/alpha/kernel/core_cia.o] Error 1
> 
> 
> This doesn't really sound like a gcc bug, rather like an invalid asm,
> or bad options passed to as. But it's impossible to tell without a
> test case.

I'll try to post one today for that and for the sparc ICE below.

For those trying to keep score, here are all the ICEs I run into with 4.1-20050709.
Three have PRs already, and one appears to be new:

No PR yet?:
sparc-gcc-4.1-20050709-glibc-2.3.2:
   arch/sparc/kernel/process.c:204: internal compiler error: in compare_values, at tree-vrp.c:445

http://gcc.gnu.org/PR22384 :
arm-gcc-4.1-20050709-glibc-2.3.2
arm-xscale-gcc-4.1-20050709-glibc-2.3.2
arm9tdmi-gcc-4.1-20050709-glibc-2.3.2:
   gcc-4.1-20050709/libiberty/cp-demangle.c:3342: internal compiler error: in loop_givs_rescan, at loop.c:5517
i686-gcc-4.1-20050709-glibc-2.3.2
   mm/page_alloc.c:1940: internal compiler error: in loop_givs_rescan, at loop.c:5517

http://gcc.gnu.org/PR22379 :
mips-gcc-4.1-20050709-glibc-2.3.2
mipsel-gcc-4.1-20050709-glibc-2.3.2
powerpc-405-gcc-4.1-20050709-glibc-2.3.2
powerpc-750-gcc-4.1-20050709-glibc-2.3.2
powerpc-860-gcc-4.1-20050709-glibc-2.3.2
powerpc-970-gcc-4.1-20050709-glibc-2.3.2
x86_64-gcc-4.1-20050709-glibc-2.3.2:
   drivers/char/random.c:1813: internal compiler error: in cgraph_early_inlining, at ipa-inline.c:990

http://gcc.gnu.org/PR22258
sh4-gcc-4.1-20050709-glibc-2.3.2:
   libstdc++-v3/include/ext/bitmap_allocator.h:1085: internal compiler error: in spill_failure, at reload1.c:1889





-- 
Trying to get a job as a c++ developer?  See http://kegel.com/academy/getting-hired.html

Re: gcc-4.1-20050709: alpha: "macro requires $at register while noat in effect" while compiling Linux kernel

[Dan Kegel]

Falk Hueffner wrote:
> Dan Kegel <dank@kegel.com> writes:
> 
> 
>>Likewise, compiling that version of gcc for alpha
>>dies while building the linux kernel, but for a different reason:
>>
>>{standard input}:496: Error: macro requires $at register while noat in effect
>>make[1]: *** [arch/alpha/kernel/core_cia.o] Error 1
> 
> 
> This doesn't really sound like a gcc bug, rather like an invalid asm,
> or bad options passed to as. But it's impossible to tell without a
> test case.

OK, I extracted a minimal test case.  This is from compiling
arch/alpha/kernel/core_cia.c from linux-2.6.11.3 for alpha.
Works fine with gcc-4.0.1.  Can somebody familiar with
inline assembly guess whether the source or the compiler are wrong here?

--- snip ---
inline unsigned int
cia_bwx_ioread8(void *a)
{
  return ({ unsigned char __kir; __asm__("ldbu %0,%1" : "=r"(__kir) : "m"(*(volatile unsigned char *)a)); __kir; });
}
--- snip ---

$ alpha-unknown-linux-gnu-gcc -fno-common -ffreestanding -O2 \
-mno-fp-regs -ffixed-8 -msmall-data -mcpu=ev5 -Wa,-mev6 -c core_cia.i

/tmp/ccmvyEzr.s: Assembler messages:
/tmp/ccmvyEzr.s:16: Error: macro requires $at register while noat in effect

-- 
Trying to get a job as a c++ developer?  See http://kegel.com/academy/getting-hired.html

gcc-4.1-20050709: ICE in compare_values, at tree-vrp.c:445 (was: Re: gcc-4.1-20050709: ICE in loop_givs_rescan, at loop.c:5517)

[Dan Kegel]

Dan Kegel wrote:
> sparc-gcc-4.1-20050709-glibc-2.3.2:
>   arch/sparc/kernel/process.c:204: internal compiler error: in 
> compare_values, at tree-vrp.c:445

Filed as
http://gcc.gnu.org/PR22398

-- 
Trying to get a job as a c++ developer?  See http://kegel.com/academy/getting-hired.html

Re: gcc-4.1-20050709: alpha: "macro requires $at register while noat in effect" while compiling Linux kernel

[Falk Hueffner]

Dan Kegel <dank@kegel.com> writes:

> Can somebody familiar with inline assembly guess whether the source
> or the compiler are wrong here?
>
> --- snip ---
> inline unsigned int
> cia_bwx_ioread8(void *a)
> {
>   return ({ unsigned char __kir; __asm__("ldbu %0,%1" : "=r"(__kir) : "m"(*(volatile unsigned char *)a)); __kir; });
> }
> --- snip ---
>
> $ alpha-unknown-linux-gnu-gcc -fno-common -ffreestanding -O2 \
> -mno-fp-regs -ffixed-8 -msmall-data -mcpu=ev5 -Wa,-mev6 -c core_cia.i
>
> /tmp/ccmvyEzr.s: Assembler messages:
> /tmp/ccmvyEzr.s:16: Error: macro requires $at register while noat in effect

The "ldbu" instruction is only available on ev56 and above, however,
gcc4.1 emits ".arch ev5" because of "-mcpu=ev5", which overrides as's
"-mev6". This used to work because 4.0 didn't output ".arch ev5"
because it doesn't actually do anything important.

I don't see any fault on gcc's side here. You could argue that the
command line option for as should override the ".arch", but I think
it's been like this forever. So you should probably just add ".arch
ev6" inside the asm (annoyingly, gas doesn't seem to have ".arch any"
or similar).

-- 
	Falk

Re: gcc-4.1-20050709: alpha: "macro requires $at register while noat in effect" while compiling Linux kernel

[Paul Koning]

>>>>> "Falk" == Falk Hueffner <falk@debian.org> writes:

 >> $ alpha-unknown-linux-gnu-gcc -fno-common -ffreestanding -O2 \
 >> -mno-fp-regs -ffixed-8 -msmall-data -mcpu=ev5 -Wa,-mev6 -c
 >> core_cia.i

 Falk> I don't see any fault on gcc's side here. You could argue that
 Falk> the command line option for as should override the ".arch", but
 Falk> I think it's been like this forever. So you should probably
 Falk> just add ".arch ev6" inside the asm (annoyingly, gas doesn't
 Falk> seem to have ".arch any" or similar).

More appropriate would be to make the command line consistent with the
code.  If there's inline assembly that requires ev6, then -mcpu=ev6 is
appropriate.  Conversely, if the code really is supposed to run on an
ev5, then -Wa,mev5 is the right fix and the inline assembly should
stick to instructions that exist on that machine.

      paul

Re: gcc-4.1-20050709: alpha: "macro requires $at register while noat in effect" while compiling Linux kernel

[Dan Kegel]

Paul Koning wrote:
>>>>>>"Falk" == Falk Hueffner <falk@debian.org> writes:
> 
> 
>  >> $ alpha-unknown-linux-gnu-gcc -fno-common -ffreestanding -O2 \
>  >> -mno-fp-regs -ffixed-8 -msmall-data -mcpu=ev5 -Wa,-mev6 -c
>  >> core_cia.i
> 
>  Falk> I don't see any fault on gcc's side here. You could argue that
>  Falk> the command line option for as should override the ".arch", but
>  Falk> I think it's been like this forever. So you should probably
>  Falk> just add ".arch ev6" inside the asm (annoyingly, gas doesn't
>  Falk> seem to have ".arch any" or similar).
> 
> More appropriate would be to make the command line consistent with the
> code.  If there's inline assembly that requires ev6, then -mcpu=ev6 is
> appropriate.  Conversely, if the code really is supposed to run on an
> ev5, then -Wa,mev5 is the right fix and the inline assembly should
> stick to instructions that exist on that machine.

The code is in linux-2.6.*/asm-alpha/compiler.h.
Inspection shows that the code really is supposed to run on an ev5;
it uses the LDBU in inline assembly and expects the
assembler to expand that to something that can run on ev4,
which should work according to
http://msdn.microsoft.com/library/en-us/aralpha98/html/load_byte_unsigned_ldbu.asp
The problem is then the -Wa,-mev6.  And voila, linux-2.6.*/arch/alpha/Makefile
seems to add that unconditionally:

# For TSUNAMI, we must have the assembler not emulate our instructions.
# The same is true for IRONGATE, POLARIS, PYXIS.
# BWX is most important, but we don't really want any emulation ever.
CFLAGS += $(cflags-y) -Wa,-mev6

I'll punt this to the alpha linux kernel folks.

Thanks for the help!
- Dan

-- 
Trying to get a job as a c++ developer?  See http://kegel.com/academy/getting-hired.html

Re: gcc-4.1-20050709: alpha: "macro requires $at register while noat in effect" while compiling Linux kernel

[Richard Henderson]

On Mon, Jul 11, 2005 at 08:54:34AM -0400, Paul Koning wrote:
> More appropriate would be to make the command line consistent with the
> code.  If there's inline assembly that requires ev6, then -mcpu=ev6 is
> appropriate.

No, this code is protected by various system checks.

We want -mcpu=ev5 such that the kernel as a whole will run everywhere,
but we require these specific instructions on specific ev56/ev6 systems
for i/o.


r~

Re: gcc-4.1-20050709: alpha: "macro requires $at register while noat in effect" while compiling Linux kernel

[Richard Henderson]

On Mon, Jul 11, 2005 at 08:57:58AM +0200, Falk Hueffner wrote:
> The "ldbu" instruction is only available on ev56 and above, however,
> gcc4.1 emits ".arch ev5" because of "-mcpu=ev5", which overrides as's
> "-mev6". This used to work because 4.0 didn't output ".arch ev5"
> because it doesn't actually do anything important.
> 
> I don't see any fault on gcc's side here. You could argue that the
> command line option for as should override the ".arch", but I think
> it's been like this forever. So you should probably just add ".arch
> ev6" inside the asm (annoyingly, gas doesn't seem to have ".arch any"
> or similar).

It'd probably be easier to go back to suppressing the .arch 
in this case.


r~

Re: gcc-4.1-20050709: alpha: "macro requires $at register while noat in effect" while compiling Linux kernel

[Dan Kegel]

Richard Henderson wrote:
> On Mon, Jul 11, 2005 at 08:54:34AM -0400, Paul Koning wrote:
> 
>>More appropriate would be to make the command line consistent with the
>>code.  If there's inline assembly that requires ev6, then -mcpu=ev6 is
>>appropriate.
> 
> 
> No, this code is protected by various system checks.
> 
> We want -mcpu=ev5 such that the kernel as a whole will run everywhere,
> but we require these specific instructions on specific ev56/ev6 systems
> for i/o.

rth, can you eyeball the summary I posted at http://marc.theaimsgroup.com/?l=linux-kernel&m=112109202911699&w=2 ?
My limited understanding is that gcc is fine, no need to revert anything,
but the linux kernel configury needs to stop doing
   -mcpu=ev5 -Wa,-mev6
for CONFIG_ALPHA_EV5/CONFIG_ALPHA_GENERIC, since those specific instructions
really aren't there on real ev5 machines, and passing
-Wa,-mev6 keeps it from substituting
a macro.  (Or are there no pure ev5 machines in the world?)
- Dan

-- 
Trying to get a job as a c++ developer?  See http://kegel.com/academy/getting-hired.html

Re: gcc-4.1-20050709: alpha: "macro requires $at register while noat in effect" while compiling Linux kernel

[Richard Henderson]

On Mon, Jul 11, 2005 at 09:52:22AM -0700, Dan Kegel wrote:
> >No, this code is protected by various system checks.
> >
> >We want -mcpu=ev5 such that the kernel as a whole will run everywhere,
> >but we require these specific instructions on specific ev56/ev6 systems
> >for i/o.
> 
> rth, can you eyeball the summary I posted at 
> http://marc.theaimsgroup.com/?l=linux-kernel&m=112109202911699&w=2 ?
> My limited understanding is that gcc is fine, no need to revert anything,
> but the linux kernel configury needs to stop doing
>   -mcpu=ev5 -Wa,-mev6
> for CONFIG_ALPHA_EV5/CONFIG_ALPHA_GENERIC, since those specific instructions
> really aren't there on real ev5 machines, and passing
> -Wa,-mev6 keeps it from substituting a macro.

Absolutely not.  While one can argue about which in the gcc+binutils
pair is buggy, the kernel is *not* buggy.

Please re-read my problem description above, and recall that this is
for a GENERIC kernel, that runs on ALL alpha systems.


r~

Re: gcc-4.1-20050709: alpha: "macro requires $at register while noat in effect" while compiling Linux kernel

[Dan Kegel]

Richard Henderson wrote:
> On Mon, Jul 11, 2005 at 09:52:22AM -0700, Dan Kegel wrote:
> 
>>>No, this code is protected by various system checks.
>>>
>>>We want -mcpu=ev5 such that the kernel as a whole will run everywhere,
>>>but we require these specific instructions on specific ev56/ev6 systems
>>>for i/o.
>>
>>rth, can you eyeball the summary I posted at 
>>http://marc.theaimsgroup.com/?l=linux-kernel&m=112109202911699&w=2 ?
>>My limited understanding is that gcc is fine, no need to revert anything,
>>but the linux kernel configury needs to stop doing
>>  -mcpu=ev5 -Wa,-mev6
>>for CONFIG_ALPHA_EV5/CONFIG_ALPHA_GENERIC, since those specific instructions
>>really aren't there on real ev5 machines, and passing
>>-Wa,-mev6 keeps it from substituting a macro.
> 
> 
> Absolutely not.  While one can argue about which in the gcc+binutils
> pair is buggy, the kernel is *not* buggy.
> 
> Please re-read my problem description above, and recall that this is
> for a GENERIC kernel, that runs on ALL alpha systems.

Maybe I'm missing something.  include/asm-alpha/compiler.h says:

#if defined(__alpha_bwx__)
#define __kernel_ldbu(mem)      (mem)
...
#else
#define __kernel_ldbu(mem)                              \
    ({ unsigned char __kir;                               \
       __asm__("ldbu %0,%1" : "=r"(__kir) : "m"(mem));    \
       __kir; })

For -mcpu=ev5, the #else branch is taken, and the ldbu instruction
is given to the assembler, right?
And since arch/alpha/Makefile does
   CFLAGS += $(cflags-y) -Wa,-mev6
unconditionally, real ldbu instructions are used instead of
the emulation.  And that means that __kernel_ldbu(mem) won't
work on pure ev5 machines.  Are you saying that __kernel_ldbu(mem)
is never called on pure ev5 machines, then?

Thanks,
Dan

-- 
Trying to get a job as a c++ developer?  See http://kegel.com/academy/getting-hired.html

Re: gcc-4.1-20050709: alpha: "macro requires $at register while noat in effect" while compiling Linux kernel

[Richard Henderson]

On Mon, Jul 11, 2005 at 10:20:08AM -0700, Dan Kegel wrote:
> Are you saying that __kernel_ldbu(mem)
> is never called on pure ev5 machines, then?

Yes, that is what I am saying.


r~