[Bug treelang/47197] New: ICE in gimplify_expr, at gimplify.c:7153 on AltiVec code (vec_dst)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47197
Summary: ICE in gimplify_expr, at gimplify.c:7153 on AltiVec
code (vec_dst)
Product: gcc
Version: 4.5.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: treelang
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: kaffeemons...@googlemail.com
$ cat alti_crash.c
#include
void func(unsigned char *buf, unsigned len)
{
vec_dst(buf, (len >= 256 ? 0 : len) | 512, 2);
}
$ powerpc-linux-gnu-gcc -maltivec -c alti_crash.c
alti_crash.c: In function 'func':
alti_crash.c:5:20: internal compiler error: in gimplify_expr, at
gimplify.c:7153
Please submit a full bug report,
with preprocessed source if appropriate.
See
[Bug target/52323] New: i386: gcse runs amok with pic-addresses
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52323 Bug #: 52323 Summary: i386: gcse runs amok with pic-addresses Classification: Unclassified Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: kaffeemons...@googlemail.com I have here some very bad interaction between gcse and pic addresses on i386. The attached testcase (yes, i know, it's not a beauty, could prop. be reduces some more) compiled by: gcc-4.6.2 -Wall -O1 -fpic -S gcse_amok.c -o gcse_amok.s creates roughly this code: to_base32_BMI2: .LFB1: .cfi_startproc pushl%ebp .cfi_def_cfa_offset 8 .cfi_offset 5, -8 pushl%edi .cfi_def_cfa_offset 12 .cfi_offset 7, -12 pushl%esi .cfi_def_cfa_offset 16 .cfi_offset 6, -16 pushl%ebx .cfi_def_cfa_offset 20 .cfi_offset 3, -20 call__i686.get_pc_thunk.bx addl$_GLOBAL_OFFSET_TABLE_, %ebx movl20(%esp), %eax movl24(%esp), %edx movl28(%esp), %ecx cmpl$4, %ecx jbe.L2 .L4: movl(%edx), %esi bswap%esi movl%esi, %edi shrl$12, %edi #APP # 19 "gcse_amok.c" 1 pdep 64+vals@GOTOFF(%ebx), %edi, %edi # 0 "" 2 #NO_APP movzbl4(%edx), %ebp sall$8, %esi orl%ebp, %esi #APP # 20 "gcse_amok.c" 1 pdep 64+vals@GOTOFF(%ebx), %esi, %esi # 0 "" 2 #NO_APP bswap%edi bswap%esi #APP # 25 "gcse_amok.c" 1 movd%edi, %xmm0 pinsrd$1, %esi, %xmm0 paddb80+vals@GOTOFF(%ebx), %xmm0 movdqa%xmm0, %xmm1 pcmpgtb96+vals@GOTOFF(%ebx), %xmm1 pand112+vals@GOTOFF(%ebx), %xmm1 psubb%xmm1, %xmm0 movq%xmm0, (%eax) # 0 "" 2 #NO_APP addl$8, %eax addl$5, %edx subl$5, %ecx cmpl$4, %ecx ja.L4 ... If -fgcse (like in -O2) gets added to the command line, things get ugly: gcc-4.6.2 -Wall -O1 -fpic -fgcse -S gcse_amok.c -o gcse_amok.s results in: to_base32_BMI2: .LFB1: .cfi_startproc pushl%ebp .cfi_def_cfa_offset 8 .cfi_offset 5, -8 pushl%edi .cfi_def_cfa_offset 12 .cfi_offset 7, -12 pushl%esi .cfi_def_cfa_offset 16 .cfi_offset 6, -16 pushl%ebx .cfi_def_cfa_offset 20 .cfi_offset 3, -20 subl$36, %esp .cfi_def_cfa_offset 56 call__i686.get_pc_thunk.bx addl$_GLOBAL_OFFSET_TABLE_, %ebx movl56(%esp), %eax movl60(%esp), %edx movl64(%esp), %ecx cmpl$4, %ecx jbe.L2 leal64+vals@GOTOFF, %edi leal80+vals@GOTOFF, %esi movl%esi, 32(%esp) leal96+vals@GOTOFF, %ebp movl%ebp, 28(%esp) leal112+vals@GOTOFF, %esi movl%esi, 24(%esp) movl%eax, 8(%esp) movl%edx, (%esp) movl%ecx, 4(%esp) movl%edi, 12(%esp) .L3: movl(%esp), %edi movl(%edi), %esi bswap%esi movl%esi, %edi shrl$12, %edi movl12(%esp), %eax #APP # 19 "gcse_amok.c" 1 pdep (%eax,%ebx), %edi, %edi # 0 "" 2 #NO_APP movl(%esp), %edx movzbl4(%edx), %eax sall$8, %esi orl%eax, %esi movl12(%esp), %ecx #APP # 20 "gcse_amok.c" 1 pdep (%ecx,%ebx), %esi, %esi # 0 "" 2 #NO_APP bswap%edi bswap%esi movl8(%esp), %eax movl32(%esp), %edx movl28(%esp), %ecx movl24(%esp), %ebp #APP # 25 "gcse_amok.c" 1 movd%edi, %xmm0 pinsrd$1, %esi, %xmm0 paddb(%edx,%ebx), %xmm0 movdqa%xmm0, %xmm1 pcmpgtb(%ecx,%ebx), %xmm1 pand0(%ebp,%ebx), %xmm1 psubb%xmm1, %xmm0 movq%xmm0, (%eax) # 0 "" 2 #NO_APP addl$8, %eax movl%eax, 8(%esp) addl$5, (%esp) subl$5, 4(%esp) cmpl$4, 4(%esp) ja.L3 ... Later passes (-O2, -O3) only make things worse or can not recover from this. For some reason gcse tries to hoist the constant address-offsets out the loop. this needs a bunch of register, which i386 does not have, and so the spilling begins... GCC 4.5.3 does not even compile it $ gcc-4.5.3 -Wall -O1 -fpic -fgcse -S -o gcse_amok.s gcse_amok.c gcse_amok.c: In function 'to_base32_BMI2': gcse_amok.c:25:2: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm' gcse_amok.c:19:2: error: 'asm' operand has impossible constraints gcse_amok.c:20:2: error: 'asm' operand has impossible constraints gcse_amok.c:25:2: error: 'asm' operand has impossible constraints without gcse, no problem: $ gcc -Wall -O1 -fpic -S -o gcse_amok.s gcse_amok.c $ echo $? 0 I do not really know which component this is, but i guess it is a target problem, the low costs for "more complicated addressing modes" on x86 (so the compil
[Bug target/52323] i386: gcse runs amok with pic-addresses
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52323 --- Comment #1 from Jan Seiffert 2012-02-21 08:15:19 UTC --- Created attachment 26709 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26709 Testcase exposing gcse hyperactivity with pic on i386 the testcase *mumbel mumbel* that the description field is mandatory could be made more visible...
[Bug target/52323] i386: gcse runs amok with pic-addresses
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52323 --- Comment #3 from Jan Seiffert 2012-02-22 00:03:53 UTC --- My use case are not large floating point math funcs. While intrinsics are nice (the new Tile ports rock! Every spec. instruction as intrinsic from day 1, that's how it should be for a VLIW arch, can't say the same for IA64...), for x86 they are generally not on my radar. x86 being the primary architecture today for my use case, if things are only mediocre on PPC/ARM or whatever, i can live with it, but not for x86. And on x86 intrinsics simply do not work good enough. Intrinsics have one "deadly" limitation: You can only use them if -march= is set right. And x86 has one gazillion ISA extensions, every 2 years a new one. This way you can not wright code which dynamically dispatches at runtime. User which get code by some general build (Distro, package from website) are the majority for x86. You can expect from an PPC user or ARM user or Alpha user to set his march right, he will be compiling it by himself anyway, but not for x86. Also distros "hate it" when you do not obey the CFLAGS they set during build and muck around with these CFLAGS (for good reasons). BMI2 is an ISA extention where the CPUs will only get released. If there are intrinsics in GCC for it, it's prop. somewhere in CVS. GCCs in use out there are generally not bleeding edge new. Another problem is what GCC (but also other compiler) does when he is "one or two" register short (very common on i386). Stackframe, foo, bar, often not the perfect spill (to but it in a positive light). This is the point where a human can either: a) find a better spill (more cold) b) squeeze and push and shove to make it fit. But you can't flip a switch on a compiler: "please be 20% smarter now". And so why write it as inline asm instead of a stand alone .s? Let the compiler do the leg work, that's his job. Calling conventions, debug info, sections, .gnu-note-stack, pic/non-pic, etc. I only need to write the kernel and can do as much or few as i like to, without wasting any thought on the ASM boiler plate stuff. I could write it with intrinsics for this testcase (but then the problem would prop. vanish?), i generally do not for x86 and this is a snipped from a larger code body. (the alpha version uses __builtin_zapnot and __builtin_cmpbge, the NEON version uses the stuff from neon.h, but for other instruction sets, there are not enough intrinsics or they work poorly (ex. ARM iWMMXt, MIPS Loongson)...)
[Bug middle-end/47602] Permit inline asm to clobber PIC register
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47602
Jan Seiffert changed:
What|Removed |Added
CC||kaffeemonster at googlemail
||dot com
--- Comment #15 from Jan Seiffert
2011-12-24 15:54:23 UTC ---
As a heavy inline asm user myself, i can understand the pain to handle PIC
yourself, but there is no way around that.
You can "accidentally" use the PIC register by a memory operand ("m"). Then the
compiler can not save it for you.
Greetings
Jan
