[Bug rtl-optimization/39196] New: ICE in copyprop_hardreg_forward_1, at regrename.c:1603 during libjava compile
This appeared during compile of the last weekly 4.4.0 snapshot in libjava
compilation:
libtool: compile:
/var/tmp/portage/sys-devel/gcc-4.4.0_alpha20090215/work/build/./gcc/xgcc
-B/var/tmp/portage/sys-devel/gcc-4.4.0_alpha20090215/work/build/./gcc/
-B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem
/usr/x86_64-pc-linux-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include
-DHAVE_CONFIG_H -I.
-I/var/tmp/portage/sys-devel/gcc-4.4.0_alpha20090215/work/gcc-4.4-20090215/libjava/classpath/native/fdlibm
-I../../include -fexceptions -fasynchronous-unwind-tables -g -O2 -march=nocona
-pipe -MT dtoa.lo -MD -MP -MF .deps/dtoa.Tpo -c
/var/tmp/portage/sys-devel/gcc-4.4.0_alpha20090215/work/gcc-4.4-20090215/libjava/classpath/native/fdlibm/dtoa.c
-fPIC -DPIC -o .libs/dtoa.o
/var/tmp/portage/sys-devel/gcc-4.4.0_alpha20090215/work/gcc-4.4-20090215/libjava/classpath/native/fdlibm/dtoa.c:
In function _Jv_dtoa_r:
/var/tmp/portage/sys-devel/gcc-4.4.0_alpha20090215/work/gcc-4.4-20090215/libjava/classpath/native/fdlibm/dtoa.c:885:
error: insn does not satisfy its constraints:
(insn 2428 2427 687 103
/var/tmp/portage/sys-devel/gcc-4.4.0_alpha20090215/work/gcc-4.4-20090215/libjava/classpath/native/fdlibm/dtoa.c:536
(set (reg:DF 26 xmm5 [orig:233 D.3242 ] [233])
(mult:DF (reg:DF 26 xmm5 [orig:233 D.3242 ] [233])
(reg:DF 0 ax))) 722 {*fop_df_comm_sse} (nil))
/var/tmp/portage/sys-devel/gcc-4.4.0_alpha20090215/work/gcc-4.4-20090215/libjava/classpath/native/fdlibm/dtoa.c:885:
internal compiler error: in copyprop_hardreg_forward_1, at regrename.c:1603
Please submit a full bug report,
with preprocessed source if appropriate.
Reproducible on the preprocessed source using:
/var/tmp/portage/sys-devel/gcc-4.4.0_alpha20090215/work/build/./gcc/xgcc
-B/var/tmp/portage/sys-devel/gcc-4.4.0_alpha20090215/work/build/./gcc/ -o
dtoa.o dtoa.i -O2 -march=nocona
--
Summary: ICE in copyprop_hardreg_forward_1, at regrename.c:1603
during libjava compile
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: christophe at saout dot de
GCC build triplet: x86_64-pc-linux-gnu
GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39196
[Bug rtl-optimization/39196] ICE in copyprop_hardreg_forward_1, at regrename.c:1603 during libjava compile
--- Comment #1 from christophe at saout dot de 2009-02-15 17:17 --- Created an attachment (id=17303) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17303action=view) preprocessed code (unused stuff cut out) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39196
[Bug tree-optimization/37101] [4.2/4.3 Regression] wrong code: tree vectorizer omits bogus movq/movlps construct
--- Comment #3 from christophe at saout dot de 2008-08-13 16:14 --- Ok, tried that... Now xorg-server doesn't segfault, but hang in an infinite loop. Adding printouts after the loop shows that the upper and lower parts of the register are inverted: (contents of the tails array): 0 0x28e1c98 1 0x28e1c90 2 0x28e1ca8 3 0x28e1ca0 4 0x28e1cb8 ... So, the movlps is correct to fill the lower half of the register without touching the upper half, but the movd %rax, %xmm1 should fill the upper half instead. I tried changing it into a movhps, but that won't take the %rax as source register. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37101
[Bug tree-optimization/37101] [4.2/4.3 Regression] wrong code: tree vectorizer omits bogus movq/movlps construct
--- Comment #4 from christophe at saout dot de 2008-08-13 22:15 ---
Ok, I'm completely not in my game here, but after staring at rtl dumps and gcc
code for about two hours straight, things slowly start to make a litte sense...
(please tell me to shut up and forget about it if I am totally wrong about
this)
In my opinion the issue comes from here:
(define_insn *vec_concatv2di_rex
[(set (match_operand:V2DI 0 register_operand =Y2,Yi,!Y2,Y2,x,x,x)
(vec_concat:V2DI
(match_operand:DI 1 nonimmediate_operand m,r ,*y ,0 ,0,0,m)
(match_operand:DI 2 vector_move_operandC,C ,C ,Y2,x,m,0)))]
TARGET_64BIT
@
movq\t{%1, %0|%0, %1}
movq\t{%1, %0|%0, %1}
movq2dq\t{%1, %0|%0, %1}
punpcklqdq\t{%2, %0|%0, %2}
movlhps\t{%2, %0|%0, %2}
movhps\t{%2, %0|%0, %2}
movlps\t{%1, %0|%0, %1}
[(set_attr type ssemov,ssemov,ssemov,sselog,ssemov,ssemov,ssemov)
(set_attr mode TI,TI,TI,TI,V4SF,V2SF,V2SF)])
As far as I understand it, looking at the instruction and operand matches,
this rule is used to combined two 64 bit values into one 128 bit xmm register.
The relevant part in the RTL dump seems to be:
(insn 401 108 109 (set (reg:DI 22 xmm1)
(reg/f:DI 0 ax [124])) 89 {*movdi_1_rex64} (expr_list:REG_DEAD
(reg/f:DI 0 ax [124])
(nil)))
(insn:HI 109 401 402 (set (reg:V2DI 22 xmm1)
(vec_concat:V2DI (mem/c:DI (plus:DI (reg/f:DI 7 sp)
(const_int 56 [0x38])) [52 D.11729+0 S8 A8])
(reg:DI 22 xmm1))) 1301 {*vec_concatv2di_rex} (nil))
The first instruction tells it to move %rax to %xmm1 (which contains the 64
bits of %xmm1 that should end up in the upper half of %xmm1), which just had 8
added to it in the previous step (add $0x8,%rax after %rax being loaded from
rptr).
The second instruction now is supposed to take %xmm1 and a memory operand (the
rptr value without 8 added) and combine the two into %xmm1.
As far as I understand the RTL template syntax, this definition handles seven
cases at once, which the last one matching here, operands 0 to 2 being x, m
and 0, which I guess means xmm register, memory and same as 0th
operand.
So this is supposed to take the memory operand, %xmm1 and combine the two, i.e.
taking the memory operand as lower half and the contents of %xmm1 as upper half
and putting the result in %xmm1 again.
Which is exactly what is supposed to happen here. For the second-to-last
instruction (with the role flipped, i.e. the memory operand to land in the
upper half), this would yield in a movhps, which is ok.
But for movlps it is not, since the lower half of %xmm1 is not moved to the
upper half, which leads to the problem I see.
My assumption would be that the seventh combination leading to emission of
movlps is badly formulated. The 0 in the constraints seems to be
interpreted by gcc that it's ok if the contents are in the lower half of the
input register, whereas it seems that the constrain is should at least tell gcc
that the contents of operand 2 should already be in the upper half.
However, I have no idea how to tell gcc that. I could try and remove that 7th
combination altogether to force gcc to find an alternative solution (?).
Is it worth testing that? (i.e. going to build gcc and experiment...)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37101
[Bug tree-optimization/37101] [4.2/4.3 Regression] wrong code: tree vectorizer omits bogus movq/movlps construct
--- Comment #5 from christophe at saout dot de 2008-08-14 00:08 --- Created an attachment (id=16068) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16068action=view) Remove broken alternatives using movlps for vec_concatv2di(_rex) insn causes gcc to emit the following valid sequence instead (which is the sequence it always produced when I tried to build a standalone test case): movq56(%rsp), %rax addq$8, %rax movq56(%rsp), %xmm1 movd%rax, %xmm2 punpcklqdq %xmm2, %xmm1 movdqa %xmm1, %xmm0 BTW: that last move seems redundant... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37101
[Bug tree-optimization/37101] New: [4.2/4.3 Regression] wrong code: tree vectorizer omits bogus movq/movlps construct
this bug was already present in 4.2, haven't tested any other versions myself. -- Summary: [4.2/4.3 Regression] wrong code: tree vectorizer omits bogus movq/movlps construct Product: gcc Version: 4.3.1 Status: UNCONFIRMED Severity: critical Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: christophe at saout dot de GCC build triplet: x86_64-pc-linux-gnu GCC host triplet: x86_64-pc-linux-gnu GCC target triplet: x86_64-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37101
[Bug tree-optimization/37101] [4.2/4.3 Regression] wrong code: tree vectorizer omits bogus movq/movlps construct
--- Comment #1 from christophe at saout dot de 2008-08-12 23:17 --- Created an attachment (id=16061) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16061action=view) preprocessed source file to be compiled to see the wrong generated code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37101
[Bug middle-end/34329] New: ICE/segfault with -O2 -msse -ftree-vectorize on very simple code
gcc -O2 -msse -ftree-vectorize -c broken.c -o broken.o
on the code snippet below gives a broken.c:4: internal compiler error:
Segmentation fault.
extern int array[2][7][6];
void test(int type, int *eq, int idx)
{
int i;
int v = type ? 0 : 1;
for (i = 0; i 6; i++)
eq[i] = array[v][idx][i];
}
--
Summary: ICE/segfault with -O2 -msse -ftree-vectorize on very
simple code
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: christophe at saout dot de
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34329
[Bug target/34312] spill failure with -O2 -fPIC -march=pentium-m on i386
--- Comment #1 from christophe at saout dot de 2007-12-01 23:19 --- Created an attachment (id=14679) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14679action=view) preprocessed source file gunzip breaks.i.gz; g++ -o breaks.o -c breaks.i -O2 -march=pentium-m -fPIC -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34312
[Bug target/34312] New: spill failure with -O2 -fPIC -march=pentium-m on i386
I get this with the gcc 4.3 snapshot from 20071130 when compiling thunderbird:
leto:/home/chtephan LANG=C g++ -o breaks.o -c breaks.i -O2 -march=pentium-m
-fPIC
nsUnicodeToJamoTTF.cpp: In function const JamoNormMap*
JamoClusterSearch(JamoNormMap, const JamoNormMap*, PRInt16):
nsUnicodeToJamoTTF.cpp:811: error: unable to find a register to spill in class
Q_REGS
nsUnicodeToJamoTTF.cpp:811: error: this is the insn:
(insn:HI 209 207 211 2 nsUnicodeToJamoTTF.cpp:783 (parallel [
(set (subreg:SI (reg:QI 134) 0)
(lshiftrt:SI (reg:SI 4 si [136])
(const_int 8 [0x8])))
(clobber (reg:CC 17 flags))
]) 358 {*lshrsi3_1} (expr_list:REG_DEAD (reg:SI 4 si [136])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil
--
Summary: spill failure with -O2 -fPIC -march=pentium-m on i386
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: christophe at saout dot de
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34312
[Bug middle-end/29726] [4.2/4.3 regression] invalid folding of ((X C1) C2) != 0 or M-x is undefined in emacs
--- Comment #1 from christophe at saout dot de 2006-11-07 11:23 ---
The function test (even compiled with -O0, on i386 BTW) assumes that the
condition can never occur, as the complete if condition is completely optimized
away and the function always returns 1.
#include stdlib.h
int test(int x)
{
if (((unsigned int)x 3) 0x0800)
return 0;
return 1;
}
int main(void)
{
if (test(-1))
abort();
return 0;
}
--
christophe at saout dot de changed:
What|Removed |Added
CC||christophe at saout dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29726
[Bug tree-optimization/29415] New: [4.2] bad code reordering around inline asm block
Using gcc 4.2 snapshot 20061007 on x86, the compiler is miscompiling glibc 2.5
(see http://sourceware.org/bugzilla/show_bug.cgi?id=3328)
What is happening is that a test of a variable after an inline asm block is
moved around so that the load of the struct member is moved above the asm block
even though it should not do that.
The miscompilation only seems to appear in that particular constellation, all
tries to reproduce the problem using a simpler hand-made test case have failed.
So I've attached the whole preprocessed source file.
Compiler simply called with gcc -O2 -o test.o -c pthread_mutex_lock.c.
The problem appears in the function __pthread_mutex_lock. There's a switch
statement with some common stuff in the different cases which the compiler
seems to optimize. The case in question (the most common one):
switch (__builtin_expect (mutex-__data.__kind, PTHREAD_MUTEX_TIMED_NP)) {
...
case PTHREAD_MUTEX_TIMED_NP:
simple:
/* Normal mutex. */
LLL_MUTEX_LOCK (mutex-__data.__lock);
assert (mutex-__data.__owner == 0);
break;
...
}
The LLL_MUTEX_LOCK is a macro with an inline assembler statement (cmpxchg and a
conditional jump to another section) that is annotated to tell the compiler
that it clobbers memory, so gcc should never move loads around the inline asm
block. But in this case the load from mutex-__data.__owner (for the assertion)
is executed above LLL_MUTEX_LOCK and the register content is tested below
LLL_MUTEX_LOCK. The content will have changed, but the old value in the
register is wrong and the assertion triggers.
The broken generated code looks like (note that the jump to _L_mutex_lock_78
is just an out-of-line call to another function that can wait for some time,
modify the mutex-__data.__owner = 0x8(%ebx) here, and then jump back):
loading mutex-__data.__owner (into %edx):
2f: 8b 53 08mov0x8(%ebx),%edx
lll_mutex_lock:
32: 31 c0 xor%eax,%eax
34: b9 01 00 00 00 mov$0x1,%ecx
39: f0 0f b1 0b lock cmpxchg %ecx,(%ebx)
3d: 0f 85 f3 05 00 00 jne636 _L_mutex_lock_78
testing mutex-__data.__owner (%edx from above!):
43: 85 d2 test %edx,%edx
45: 0f 85 7f 04 00 00 jne4ca __pthread_mutex_lock+0x4ca
- __assert_fail
In constrast, gcc 4.1.1 generated the following correct piece of code:
acquiring mutex (lll_mutex_lock):
3d: 31 c0 xor%eax,%eax
3f: b9 01 00 00 00 mov$0x1,%ecx
44: f0 0f b1 0b lock cmpxchg %ecx,(%ebx)
48: 0f 85 ed 05 00 00 jne63b _L_mutex_lock_86
loading and testing owner:
4e: 8b 43 08mov0x8(%ebx),%eax
51: 85 c0 test %eax,%eax
53: 0f 85 71 05 00 00 jne5ca __pthread_mutex_lock+0x5ca
- __assert_fail
--
Summary: [4.2] bad code reordering around inline asm block
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: christophe at saout dot de
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29415
[Bug tree-optimization/29415] [4.2] bad code reordering around inline asm block
--- Comment #1 from christophe at saout dot de 2006-10-10 15:40 --- Created an attachment (id=12404) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12404action=view) preprocessed pthread_mutex_lock.c causing the miscompiled code Call with gcc -O2 -o test.o -c pthread_mutex_lock.c on i686 and look at the beginning of the generated __pthread_mutex_lock function, around the first cmpxchg call. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29415
[Bug translation/21364] New: [translation] %J in translation instead of %H causes ICE in de.po
[de.po] #: tree-ssa.c:1379 msgid %H%qD is used uninitialized in this function msgstr %J%qD wird in dieser Funktion uninitialisiert verwendet The %J causes gcc to segfault. Changing it to %H fixes everything, obviously. Besides, the `q' modifier in %qD doesn't seem to be honoured in the translated string (same for % and % which are only interpreted in the original english string). I fixed up tons of lines some days ago myself, I found a bunch of entries where the fuzzy selector picked a wrong translation and I've probably overlooked some. If someone is interested...? I don't know to do exactly (so please don't shoot me), it seems someone has written some sort of script to check that the dynamic parameters are the same in both message strings. -- Summary: [translation] %J in translation instead of %H causes ICE in de.po Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: translation AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: christophe at saout dot de CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: *-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21364
[Bug translation/21364] [translation] %J in translation instead of %H causes ICE in de.po
--- Additional Comments From christophe at saout dot de 2005-05-03 18:46 --- Ok, forget that last part, I'm an idiot. (I added lots of debug to trace down the problem, in the actual warning, the quotes appear correctly) Only the %J - %H problem then. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21364
