[Bug middle-end/18548] [4.0 Regression] Miscompiles code generated by Gambit-C Scheme-C compiler
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-18 13:54 --- Here's the RTL we generate for this on AMD64: ;; a = MAX_EXPR b, *(long int *) (a + 1) (insn 19 17 20 (set (reg/v:DI 66 [ a ]) (reg/v:DI 67 [ b ])) -1 (nil) (nil)) (insn 20 19 21 (set (reg:CCGC 17 flags) (compare:CCGC (reg/v:DI 66 [ a ]) (mem:DI (plus:DI (reg/v:DI 66 [ a ]) (const_int 1 [0x1])) [0 S8 A64]))) -1 (nil) (nil)) (jump_insn 21 20 22 (set (pc) (if_then_else (ge (reg:CCGC 17 flags) (const_int 0 [0x0])) (label_ref 23) (pc))) -1 (nil) (nil)) (insn 22 21 23 (set (reg/v:DI 66 [ a ]) (mem:DI (plus:DI (reg/v:DI 66 [ a ]) (const_int 1 [0x1])) [0 S8 A64])) -1 (nil) (nil)) (code_label 23 22 0 2 [0 uses]) Note that this is pretty dreadful with the common subexpression and all. And indeed, it is also buggy :-) -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18548
[Bug middle-end/18548] [4.0 Regression] Miscompiles code generated by Gambit-C Scheme-C compiler
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-18 14:03 --- Right... so this is miscompiled: ;; a = MAX_EXPR b, *(long int *) (a + 1) but this is not: ;; a = MAX_EXPR *(long int *) (a + 1), b Tricky to have a stable test case for this. I suppose we should just force both options of the MAX_EXPR into a reg. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18548
[Bug middle-end/18548] [4.0 Regression] Miscompiles code generated by Gambit-C Scheme-C compiler
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-18 14:38 --- Subject: Bug 18548 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-12-18 14:38:44 Modified files: gcc: ChangeLog expr.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.dg: max-1.c Log message: PR middle-end/18548 * expr.c (expand_expr_real_1) MAX_EXPR: Ensure that target, op0 and op1 are all registers (or constants) before expanding the RTL comparison sequence [to avoid reg_overlap_mentioned (target, op1)]. * gcc.dg/max-1.c: New test case. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.6873r2=2.6874 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/expr.c.diff?cvsroot=gccr1=1.760r2=1.761 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.4780r2=1.4781 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/max-1.c.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18548
[Bug middle-end/18548] [4.0 Regression] Miscompiles code generated by Gambit-C Scheme-C compiler
--- Additional Comments From roger at eyesopen dot com 2004-12-18 14:50 --- My apologies to Steven. I've only just noticed that between me agreeing to investigate the problem on IRC and preparing a patch last night, and committing the fix this morning, that you'd/he'd assigned this PR to himself. Please forgive me, next time I should re-check the PR in bugzilla after comparing the regression test output, and before posting/committing a patch. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18548
[Bug middle-end/18548] [4.0 Regression] Miscompiles code generated by Gambit-C Scheme-C compiler
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-18 15:07 --- Roger, this was a catch-all bug reports, there may still be other problems open. Brad, can you try and see if you have any more problems? -- What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18548
[Bug middle-end/18548] [4.0 Regression] Miscompiles code generated by Gambit-C Scheme-C compiler
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-18 15:08 --- Waiting for Brad to check if there are more problems. -- What|Removed |Added Status|REOPENED|WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18548
[Bug middle-end/18548] [4.0 Regression] Miscompiles code generated by Gambit-C Scheme-C compiler
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-18 15:08 --- May or may not look at any remaining issues... -- What|Removed |Added AssignedTo|steven at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|WAITING |NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18548
[Bug middle-end/18548] [4.0 Regression] Miscompiles code generated by Gambit-C Scheme-C compiler
--- Additional Comments From belyshev at lubercy dot com 2004-12-18 15:28 --- Original testcase now fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18548
[Bug middle-end/18548] [4.0 Regression] Miscompiles code generated by Gambit-C Scheme-C compiler
--- Additional Comments From lucier at math dot purdue dot edu 2004-12-18 20:23 --- Subject: Re: [4.0 Regression] Miscompiles code generated by Gambit-C Scheme-C compiler I can find no other problems at the moment. Thank you all for investigating and fixing this. Brad -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18548
[Bug middle-end/18548] [4.0 Regression] Miscompiles code generated by Gambit-C Scheme-C compiler
--- Additional Comments From belyshev at lubercy dot com 2004-12-17 23:28 --- We expanding this: ___r2.303 = MAX_EXPR ___r3.316, *((int *) ___r2.303 + 1B); into this: (insn 12778 12777 12779 1127 (set (reg/v:SI 1280 [ ___r2.303 ]) (reg/v:SI 1273 [ ___r3.316 ])) -1 (nil) (nil)) (insn 12779 12778 12780 1127 (set (reg:CCGC 17 flags) (compare:CCGC (reg/v:SI 1280 [ ___r2.303 ]) (mem:SI (plus:SI (reg/v:SI 1280 [ ___r2.303 ]) (const_int 1 [0x1])) [0 S4 A32]))) -1 (nil) (nil)) ... which is wrong. So the problem is with expander, unless i am mistaken. -- What|Removed |Added Component|tree-optimization |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18548
[Bug middle-end/18548] [4.0 Regression] Miscompiles code generated by Gambit-C Scheme-C compiler
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-17
23:50 ---
(In reply to comment #3)
We expanding this:
Yes it is, here is an small example of where we produce wrong code, I have to
think of a full working
testcase which we can run:
int *fff;
int f(int a, int b)
{
int crcc = b;
int d = *((int*)(a+1));
int i;
a = d = b? d:b;
for(i=0;ia;i++)
fff[i] = a;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18548
[Bug middle-end/18548] [4.0 Regression] Miscompiles code generated by Gambit-C Scheme-C compiler
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-18
00:02 ---
Here is at least a testcase for the MAX_EXPR problem:
Compile with -O0, works, compiling with -O2 -fno-tree-lrs does not.
long fff[10];
long f(long a, long b)
{
long crcc = b;
long d = *((int*)(a+1));
int i;
a = d = b? d:b;
for(i=0;i10;i++)
fff[i] = a;
}
int main(void)
{
int i;
long a = 10;
f((long)(a)-1,0);
for(i = 0;i10;i++)
if (fff[i]!=10)
abort ();
}
-fno-tree-lrs is needed so we don't split the live range of a which we need to
do so we hit the bug.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00 |2004-12-18 00:02:55
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18548
[Bug middle-end/18548] [4.0 Regression] Miscompiles code generated by Gambit-C Scheme-C compiler
--- Additional Comments From giovannibajo at libero dot it 2004-12-18 00:33 --- Andrew, your testcase is invalid. You cannot access a variable of long type through a pointer to int. I know the original code disables strict aliasing, but I did not test if your testcase also aborts with -fno-strict-aliasing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18548
[Bug middle-end/18548] [4.0 Regression] Miscompiles code generated by Gambit-C Scheme-C compiler
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-18
00:38 ---
(In reply to comment #6)
Andrew, your testcase is invalid. You cannot access a variable of long type
through a pointer to int. I know the original code disables strict aliasing,
but I did not test if your testcase also aborts with -fno-strict-aliasing.
Oops, here is one which is just changes the cast to long* instead of int*,
it is still broken at -O1 -fno-tree-lrs also:
long fff[10];
long f(long a, long b)
{
long crcc = b;
long d = *((long*)(a+1));
int i;
a = d = b? d:b;
for(i=0;i10;i++)
fff[i] = a;
}
int main(void)
{
int i;
long a = 10;
f((long)(a)-1,0);
for(i = 0;i10;i++)
if (fff[i]!=10)
abort ();
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18548
