[LLVMbugs] [Bug 2267] New: llvm-gcc no longer accepts some assembly: Invalid or unsupported inline assembly!
bugzilla-daemon at cs.uiuc.edu
bugzilla-daemon at cs.uiuc.edu
Wed Apr 30 12:07:10 PDT 2008
http://llvm.org/bugs/show_bug.cgi?id=2267
Summary: llvm-gcc no longer accepts some assembly: Invalid or
unsupported inline assembly!
Product: new-bugs
Version: unspecified
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: new bugs
AssignedTo: unassignedbugs at nondot.org
ReportedBy: edwintorok at gmail.com
CC: llvmbugs at cs.uiuc.edu
I tried to build glibc with llvm-gcc4.2, and I get lots of there errors:
abort.c: In function ‘abort’:
abort.c:86: error: Invalid or unsupported inline assembly!
This errors is shown many times, I picked the error from abort.c:
$ grep "unsupported inline assembly" ../../i386-libc/log|wc -l
1043
The reduced testcase shows it is a libc asm low-level lock function that is not
accepted by llvm-gcc. A while ago (I don't remember which revision) I was able
to compile glibc without these errors.
To reproduce:
$ gcc testcase-min.i -fsyntax-only
$ llvm-gcc testcase-min.i -fsyntax-only
testcase-min.i: In function ‘abort’:
testcase-min.i:10: error: Invalid or unsupported inline assembly!
$ uname -a
Linux thunder 2.6.25-rc6-00268-gd2532dd-dirty #23 SMP PREEMPT Sun Mar 23
18:34:55 EET 2008 i686 GNU/Linux
testcase-min.i:
typedef struct {
int lock;
int cnt;
}
__libc_lock_recursive_t;
static int stage;
static __libc_lock_recursive_t lock;
void abort (void) {
if (stage == 2) {
do { if (--(lock).cnt == 0) { (void) ({ int
ignore; if (__builtin_constant_p (0) && (0) == 0) __asm __volatile ("cmpl
$0, %%gs:%P3\n\t" "je 0f\n\t" "lock\n" "0:\tsubl $1,%0\n\t" "jne
_L_unlock_%=\n\t" ".subsection 1\n\t" ".type _L_unlock_%=, at function\n"
"_L_unlock_%=:\n" "1:\tleal %0, %%eax\n" "2:\tcall __lll_unlock_wake_private\n"
"3:\tjmp 18f\n" "4:\t.size _L_unlock_%=, 4b-1b\n\t" ".previous\n" ".section
.eh_frame,\"a\", at progbits\n" "5:\t" ".long 7f-6f # Length of Common
Information Entry\n" "6:\t" ".long 0x0 # CIE Identifier Tag\n\t" ".byte
0x1 # CIE Version\n\t" ".ascii \"zR\\0\" # CIE Augmentation\n\t"
".uleb128 0x1 # CIE Code Alignment Factor\n\t" ".sleb128 -4 # CIE Data
Alignment Factor\n\t" ".byte 0x8 # CIE RA Column\n\t" ".uleb128 0x1 #
Augmentation size\n\t" ".byte 0x1b # FDE Encoding (pcrel sdata4)\n\t" ".byte
0xc # DW_CFA_def_cfa\n\t" ".uleb128 0x4\n\t" ".uleb128 0x0\n\t"
".align 4\n" "7:\t" ".long 17f-8f # FDE Length\n" "8:\t" ".long 8b-5b #
FDE CIE offset\n\t" ".long 1b-.# FDE initial location\n\t" ".long 4b-1b #
FDE address range\n\t" ".uleb128 0x0 # Augmentation size\n\t" ".byte 0x16 #
DW_CFA_val_expression\n\t" ".uleb128 0x8\n\t" ".uleb128 10f-9f\n" "9:\t" ".byte
0x78 # DW_OP_breg8\n\t" ".sleb128 3b-1b\n" "10:\t" ".byte 0x40 +
(2b-1b) # DW_CFA_advance_loc\n\t" ".byte 0x16 # DW_CFA_val_expression\n\t"
".uleb128 0x8\n\t" ".uleb128 12f-11f\n" "11:\t" ".byte 0x78 #
DW_OP_breg8\n\t" ".sleb128 3b-2b\n" "12:\t" ".byte 0x40 + (3b-2b-1) #
DW_CFA_advance_loc\n\t" ".byte 0x16 # DW_CFA_val_expression\n\t"
".uleb128 0x8\n\t" ".uleb128 16f-13f\n" "13:\t" ".byte 0x78 #
DW_OP_breg8\n\t" ".sleb128 15f-14f\n\t" ".byte 0x0d #
DW_OP_const4s\n" "14:\t" ".4byte 3b-.\n\t" ".byte 0x1c #
DW_OP_minus\n\t" ".byte 0x0d # DW_OP_const4s\n" "15:\t" ".4byte
18f-.\n\t" ".byte 0x22 # DW_OP_plus\n" "16:\t" ".align 4\n" "17:\t"
".previous\n" "18:" : "=m" ((lock).lock), "=&a" (ignore) : "m" ((lock).lock),
"i" (12) : "memory"); } ); } }
while (0);
}
while (1) asm ("hlt");
}
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
More information about the llvm-bugs
mailing list