2.5.7 build breakage around blkpg.c
What hit me?
Thanks,
Bill
VERSION = 2
PATCHLEVEL = 5
SUBLEVEL = 7
EXTRAVERSION =
$ gcc --version 2.95.4
$ as --version GNU assembler 2.11.93.0.2 20020207 Debian/GNU Linux ...
gcc -D__KERNEL__ -I/home/wli/src/linus/linux-2.5/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2 -march=i386 -DKBUILD_BASENAME=blkpg -c -o blkpg.o blkpg.cblkpg.c: In function `blk_ioctl':
blkpg.c:311: Internal compiler error:
blkpg.c:311: internal error--unrecognizable insn:
(insn 898 1478 907 (set (reg/v:SI 3 %ebx)
(asm_operands/v ("1: movl %%eax,0(%2)2: movl %%edx,4(%2)
3:
.section .fixup,"ax"
4: movl %3,%0
jmp 3b
.previous
.section __ex_table,"a"
.align 4
.long 1b,4b
.long 2b,4b
.previous") ("=r") 0[
(reg:DI 1 %edx)
(reg/v:SI 4 %esi)
(const_int -14 [0xfffffff2])
(reg/v:SI 3 %ebx)
]
[
(asm_input:DI ("A"))
(asm_input:SI ("r"))
(asm_input:SI ("i"))
(asm_input:SI ("0"))
] ("blkpg.c") 268)) -1 (insn_list 873 (insn_list 897 (nil)))
(nil))Hi!
Quoted 1 line
What hit me?
gcc bug hit you. Workaround by adding volatile's to all local variables in affected function.
Pavel
Quoted 5 lines
gcc -D__KERNEL__ -I/home/wli/src/linus/linux-2.5/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2 -march=i386 -DKBUILD_BASENAME=blkpg -c -o blkpg.o
blkpg.cblkpg.c: In function `blk_ioctl':
blkpg.c:311: Internal compiler error:
blkpg.c:311: internal error--unrecognizable insn:
(insn 898 1478 907 (set (reg/v:SI 3 %ebx)
Signature · 2 lines
(about SSSCA) "I don't say this lightly. However, I really think that the U.S. no longer is classifiable as a democracy, but rather as a plutocracy." --hpa
Quoted 1 line · At some point in the past, I wrote:
Quoted 1 line
What hit me?
Quoted 4 lines · Pavel Machek
gcc bug hit you. Workaround by adding volatile's to all local variables in affected function.
From some other responses I got it was made clear to me that this
seems to do with generating an illegal instruction in response to high register pressure around inline assembly.
Cheers,
Bill