This is GCC Bugzilla
This is GCC Bugzilla Version 2.20+
View Bug Activity | Format For Printing | Clone This Bug
/* Demonstrates a gcc optimizatoin bug on a HP/Compaq/DEC alpha under OSF1. % uname -a OSF1 peano V5.1 1885 alpha % gcc -v Reading specs from /home/bluenet/bfkelly/public/gcc-3.2/OSF1/lib/\ gcc-lib/alphaev67-dec-osf51./3.2/specs Configured with: ../gcc-3.2/cponfigure --enable-languages=c \ --prefix=/home/bluenet/bfkelly/public/gcc-3.2/OSF1 Thread model: single gcc version 3.2 % % gcc -O2 -o foo foo.c % foo i= 0 r[0] = 1 r[0] = 0 % % gcc -O0 -o foo foo.c % foo i= 0 r[0]= 1 r[0]= 1 % */ #include <stdio.h> #include <stdlib.h> int car(x,y) int x; int y; { return x+y; } void bar(a, n) int a; int n; { int i; int g; int *r; g = 10; r = (int *) malloc(5 * sizeof(int)); for (i = 0; i < n; i++) { if (i < 0) { r[i] = 1; } else { if (i == 0) { r[i] = 1; printf("i= %d r[%d]= %d\n", i, i, r[i]); } else { g = car(g, a); r[i] = 2; } } } printf("r[0] = %d\n", r[0]); } int main() { bar(5,1); } Release: gcc-3.2 Environment: % uname -a OSF1 peano V5.1 1885 alpha % gcc -v Reading specs from /home/bluenet/bfkelly/public/gcc-3.2/OSF1/lib/\ gcc-lib/alphaev67-dec-osf51./3.2/specs Configured with: ../gcc-3.2/cponfigure --enable-languages=c \ --prefix=/home/bluenet/bfkelly/public/gcc-3.2/OSF1 Thread model: single gcc version 3.2 % How-To-Repeat: % gcc -O2 -o foo foo.c % foo i= 0 r[0] = 1 r[0] = 0 % % gcc -O0 -o foo foo.c % foo i= 0 r[0]= 1 r[0]= 1 %
From: Falk Hueffner <falk.hueffner@student.uni-tuebingen.de> To: gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org, bfkelly@nsa.gov Cc: Subject: Re: optimization/7702: gcc-3.2 optimization problem on a DEC alpha under OSF1 Date: 27 Jan 2003 21:12:27 +0100 Hi, I cannot reproduce this problem with gcc 3.2.2 (Debian prerelease) on Alpha Linux. I guess it it fixed meanwhile (or it only ocurrs on OSF1, but that seems unlikely to me). -- Falk
From: Falk Hueffner <falk.hueffner@student.uni-tuebingen.de> To: Blair Kelly III <bfkelly@afterlife.ncsc.mil> Cc: gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org Subject: Re: optimization/7702: gcc-3.2 optimization problem on a DEC alpha under OSF1 Date: 27 Jan 2003 23:24:14 +0100 Blair Kelly III <bfkelly@afterlife.ncsc.mil> writes: > > I cannot reproduce this problem with gcc 3.2.2 (Debian prerelease) > > on Alpha Linux. I guess it it fixed meanwhile (or it only ocurrs > > on OSF1, but that seems unlikely to me). > > I know (because I just tested) that the problem occurs using > gcc-3.2.1 under OSF1. I do not know about gcc-3.2.2. If you tell > me where I can get source for a prerelease of gcc-3.2.2, I might be > able to test. I just noticed it is *not* fixed in the gcc 3.2.2 prerelease; I didn't notice because it is triggered by -mcpu=ev67 (which is implicit for you, since you built on an ev67). However, I can't reproduce it with CVS head (gcc version 3.4 20030116 (experimental)). I'll try to investigate it a bit, maybe I can find out whether it was fixed or is just hidden. -- Falk
From: Falk Hueffner <falk.hueffner@student.uni-tuebingen.de> To: Blair Kelly III <bfkelly@afterlife.ncsc.mil> Cc: gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org Subject: Re: optimization/7702: gcc-3.2 optimization problem on a DEC alpha under OSF1 Date: 28 Jan 2003 01:09:40 +0100 Falk Hueffner <falk.hueffner@student.uni-tuebingen.de> writes: > Blair Kelly III <bfkelly@afterlife.ncsc.mil> writes: > > > > I cannot reproduce this problem with gcc 3.2.2 (Debian prerelease) > > > on Alpha Linux. I guess it it fixed meanwhile (or it only ocurrs > > > on OSF1, but that seems unlikely to me). > > > > I know (because I just tested) that the problem occurs using > > gcc-3.2.1 under OSF1. I do not know about gcc-3.2.2. If you tell > > me where I can get source for a prerelease of gcc-3.2.2, I might be > > able to test. > > I just noticed it is *not* fixed in the gcc 3.2.2 prerelease; I didn't > notice because it is triggered by -mcpu=ev67 (which is implicit for > you, since you built on an ev67). > > However, I can't reproduce it with CVS head (gcc version 3.4 20030116 > (experimental)). I'll try to investigate it a bit, maybe I can find > out whether it was fixed or is just hidden. Here's some analysis. I used this slightly stripped source: void bar(int n) { int i; int *r = malloc(5 * sizeof(int)); r[0] = 100; r[1] = 101; for (i = 0; i < n; i++) { if (i < 0) { puts("?"); r[i] = 23; } else { if (i == 0) { r[i] = 23; printf("r[%d] = %d\n", i, r[i]); } else { r[i] = 42; } } } fprintf(stdout, "r[0] = %d\n", r[0]); fprintf(stdout, "r[1] = %d\n", r[1]); } gcc decides to load the two 23s into FP registers: 21.greg: (insn 189 231 232 (set (reg:SI 35 $f3 [81]) (mem/u/f:SI (reg:DI 1 $1) [3 S4 A32])) 229 {*movsi_fix} (nil) (expr_list:REG_EQUIV (const_int 23 [0x17]) (nil))) [...] (insn 192 233 195 (set (reg:SI 34 $f2 [85]) (mem/u/f:SI (reg:DI 1 $1) [3 S4 A32])) 229 {*movsi_fix} (nil) (expr_list:REG_EQUIV (const_int 23 [0x17]) (nil))) [...] (insn 74 163 91 (set (mem:SI (reg/v/f:DI 11 $11 [71]) [3 S4 A32]) (reg:SI 34 $f2 [85])) 229 {*movsi_fix} (insn_list:REG_DEP_ANTI 64 (insn_list:REG_DEP_ANTI 41 (nil))) (nil)) Then, in 22.postreload, it decides to sign extend one from the other: (insn 192 233 195 (set (reg:DI 34 $f2 [85]) (sign_extend:DI (reg:SI 35 $f3 [81]))) 1 {*extendsidi2_fix} (nil) (expr_list:REG_EQUIV (const_int 23 [0x17]) (nil))) but the store remains SI: (insn 74 163 91 (set (mem:SI (reg/v/f:DI 11 $11 [71]) [3 S4 A32]) (reg:SI 34 $f2 [85])) 229 {*movsi_fix} (insn_list:REG_DEP_ANTI 64 (insn_list:REG_DEP_ANTI 41 (nil))) (nil)) That doesn't work with FP registers. The sign extension will generate cvtlq, which is a repositioning of 32 bits of the operand (with sign extension). Storing it in SImode will then write 0. I have no clue what to do about this. I hope somebody more knowledgeable will look at it... -- Falk
From: Falk Hueffner <falk.hueffner@student.uni-tuebingen.de> To: gcc-patches@gcc.gnu.org Cc: gcc-gnats@gcc.gnu.org, bfkelly@nsa.gov Subject: optimization/7702: [PATCH] Make reload-cse honor CANNOT_CHANGE_MODE_CLASS Date: 14 Feb 2003 10:25:54 +0100 --=-=-= Hi, This fixes PR 7702 and a miscompilation of openssh on Alpha ev6 (sshd wouldn't accept ssh2 connections). The CSE in reload wants to merge registers with equal content and widen them to word_mode while at it, but doesn't honor CANNOT_CHANGE_MODE_CLASS. When the register allocator is foolish enough to put two identical integer constants into floating point registers, this fails. Because of this dependency on the register allocator, the problem is very hard to isolate, both test cases work with mainline. However, doing an equivalent patch for 3.2 fixes the problem. Because of the ssh miscompilation, it would be nice if it could also be included on older branches. 2003-02-14 Falk Hueffner <falk.hueffner@student.uni-tuebingen.de> PR optimization/7702 * reload1.c (reload_cse_simplify_set): Honor CANNOT_CHANGE_MODE_CLASS. -- Falk --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=reload1.patch Index: reload1.c =================================================================== RCS file: /cvs/gcc/gcc/gcc/reload1.c,v retrieving revision 1.378 diff -u -r1.378 reload1.c --- reload1.c 11 Feb 2003 03:52:28 -0000 1.378 +++ reload1.c 13 Feb 2003 21:39:16 -0000 @@ -8282,7 +8282,13 @@ { #ifdef LOAD_EXTEND_OP if (GET_MODE_BITSIZE (GET_MODE (SET_DEST (set))) < BITS_PER_WORD - && extend_op != NIL) + && extend_op != NIL +#ifdef CANNOT_CHANGE_MODE_CLASS + && !CANNOT_CHANGE_MODE_CLASS (GET_MODE (SET_DEST (set)), + word_mode, + REGNO_REG_CLASS (REGNO (SET_DEST (set)))) +#endif + ) { rtx wide_dest = gen_rtx_REG (word_mode, REGNO (SET_DEST (set))); ORIGINAL_REGNO (wide_dest) = ORIGINAL_REGNO (SET_DEST (set)); --=-=-=--
From: Richard Henderson <rth@redhat.com> To: Falk Hueffner <falk.hueffner@student.uni-tuebingen.de> Cc: gcc-patches@gcc.gnu.org, gcc-gnats@gcc.gnu.org, bfkelly@nsa.gov Subject: Re: optimization/7702: [PATCH] Make reload-cse honor CANNOT_CHANGE_MODE_CLASS Date: Fri, 14 Feb 2003 14:26:52 -0800 On Fri, Feb 14, 2003 at 10:25:54AM +0100, Falk Hueffner wrote: > * reload1.c (reload_cse_simplify_set): Honor > CANNOT_CHANGE_MODE_CLASS. Applied to mainline. I'm fairly certain that the exact form of this macro was different in both 3.3 and 3.2. Would you generate and test patches for these branches? r~
From: rth@gcc.gnu.org To: gcc-gnats@gcc.gnu.org Cc: Subject: optimization/7702 Date: 14 Feb 2003 22:23:50 -0000 CVSROOT: /cvs/gcc Module name: gcc Changes by: rth@gcc.gnu.org 2003-02-14 22:23:50 Modified files: gcc : ChangeLog reload1.c Log message: PR optimization/7702 * reload1.c (reload_cse_simplify_set): Honor CANNOT_CHANGE_MODE_CLASS. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=1.16740&r2=1.16741 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/reload1.c.diff?cvsroot=gcc&r1=1.378&r2=1.379
From: rth@gcc.gnu.org To: gcc-gnats@gcc.gnu.org Cc: Subject: optimization/7702 Date: 14 Feb 2003 23:29:54 -0000 CVSROOT: /cvs/gcc Module name: gcc Branch: gcc-3_2-branch Changes by: rth@gcc.gnu.org 2003-02-14 23:29:54 Modified files: gcc : ChangeLog reload1.c Log message: PR optimization/7702 * reload1.c (reload_cse_simplify_set): Honor CLASS_CANNOT_CHANGE_MODE_P. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_2-branch&r1=1.13152.2.657.2.226&r2=1.13152.2.657.2.227 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/reload1.c.diff?cvsroot=gcc&only_with_tag=gcc-3_2-branch&r1=1.325.2.8.2.3&r2=1.325.2.8.2.4
From: Falk Hueffner <falk.hueffner@student.uni-tuebingen.de> To: Richard Henderson <rth@redhat.com> Cc: gcc-patches@gcc.gnu.org, gcc-gnats@gcc.gnu.org, bfkelly@nsa.gov Subject: Re: optimization/7702: [PATCH] Make reload-cse honor CANNOT_CHANGE_MODE_CLASS Date: 14 Feb 2003 23:31:11 +0100 --=-=-= Richard Henderson <rth@redhat.com> writes: > On Fri, Feb 14, 2003 at 10:25:54AM +0100, Falk Hueffner wrote: > > * reload1.c (reload_cse_simplify_set): Honor > > CANNOT_CHANGE_MODE_CLASS. > > Applied to mainline. Thanks. > I'm fairly certain that the exact form of this macro was different > in both 3.3 and 3.2. Would you generate and test patches for these > branches? I have this patch for 3.2. I'll check out 3.3. -- Falk --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=reload-cse-3.2.2.patch --- reload1.c.orig 2003-02-14 22:34:42.000000000 +0100 +++ reload1.c 2003-02-14 22:31:14.000000000 +0100 @@ -8277,7 +8277,14 @@ { #ifdef LOAD_EXTEND_OP if (GET_MODE_BITSIZE (GET_MODE (SET_DEST (set))) < BITS_PER_WORD - && extend_op != NIL) + && extend_op != NIL +#ifdef CLASS_CANNOT_CHANGE_MODE + && !(REGNO_REG_CLASS (REGNO (SET_DEST (set))) + == CLASS_CANNOT_CHANGE_MODE + && CLASS_CANNOT_CHANGE_MODE_P (GET_MODE (SET_DEST (set)), + word_mode)) +#endif + ) { rtx wide_dest = gen_rtx_REG (word_mode, REGNO (SET_DEST (set))); ORIGINAL_REGNO (wide_dest) = ORIGINAL_REGNO (SET_DEST (set)); --=-=-=--
From: rth@gcc.gnu.org To: gcc-gnats@gcc.gnu.org Cc: Subject: optimization/7702 Date: 14 Feb 2003 23:31:54 -0000 CVSROOT: /cvs/gcc Module name: gcc Branch: gcc-3_2-rhl8-branch Changes by: rth@gcc.gnu.org 2003-02-14 23:31:54 Modified files: gcc : ChangeLog reload1.c Log message: PR optimization/7702 * reload1.c (reload_cse_simplify_set): Honor CLASS_CANNOT_CHANGE_MODE_P. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_2-rhl8-branch&r1=1.13152.2.657.2.27.2.68&r2=1.13152.2.657.2.27.2.69 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/reload1.c.diff?cvsroot=gcc&only_with_tag=gcc-3_2-rhl8-branch&r1=1.325.2.8.4.4&r2=1.325.2.8.4.5
From: Falk Hueffner <falk.hueffner@student.uni-tuebingen.de> To: Richard Henderson <rth@redhat.com> Cc: gcc-patches@gcc.gnu.org, gcc-gnats@gcc.gnu.org Subject: Re: optimization/7702: [PATCH] Make reload-cse honor CANNOT_CHANGE_MODE_CLASS Date: 15 Feb 2003 23:30:31 +0100 --=-=-= Falk Hueffner <falk.hueffner@student.uni-tuebingen.de> writes: > Richard Henderson <rth@redhat.com> writes: > > I'm fairly certain that the exact form of this macro was different > > in both 3.3 and 3.2. Would you generate and test patches for these > > branches? > > I have this patch for 3.2. I'll check out 3.3. It needs the same patch as 3.4. I've attached it. -- Falk --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=reload-cse-3.3.patch --- reload1.c~ 2003-02-15 23:27:30.000000000 +0100 +++ reload1.c 2003-02-15 23:26:29.000000000 +0100 @@ -8275,7 +8275,13 @@ { #ifdef LOAD_EXTEND_OP if (GET_MODE_BITSIZE (GET_MODE (SET_DEST (set))) < BITS_PER_WORD - && extend_op != NIL) + && extend_op != NIL +#ifdef CANNOT_CHANGE_MODE_CLASS + && !CANNOT_CHANGE_MODE_CLASS (GET_MODE (SET_DEST (set)), + word_mode, + REGNO_REG_CLASS (REGNO (SET_DEST (set)))) +#endif + ) { rtx wide_dest = gen_rtx_REG (word_mode, REGNO (SET_DEST (set))); ORIGINAL_REGNO (wide_dest) = ORIGINAL_REGNO (SET_DEST (set)); --=-=-=--
From: rth@gcc.gnu.org To: gcc-gnats@gcc.gnu.org Cc: Subject: optimization/7702 Date: 15 Feb 2003 23:35:46 -0000 CVSROOT: /cvs/gcc Module name: gcc Branch: gcc-3_3-branch Changes by: rth@gcc.gnu.org 2003-02-15 23:35:46 Modified files: gcc : ChangeLog reload1.c Log message: PR optimization/7702 * reload1.c (reload_cse_simplify_set): Honor CANNOT_CHANGE_MODE_CLASS. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.16114.2.190&r2=1.16114.2.191 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/reload1.c.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.366.2.2&r2=1.366.2.3
State-Changed-From-To: open->closed State-Changed-Why: Fixed.