[Bug target/27006] [4.1/4.2 Regression] Invalid altivec constant loading code
--- Comment #12 from dje at watson dot ibm dot com 2006-04-14 14:32 --- Subject: Re: [4.1/4.2 Regression] Invalid altivec constant loading code One can produce a few more values fairly easily, but having GCC know the optimal sequence for all constants could be rather bulky. http://www.informatik.uni-bremen.de/~hobold/av/AltiVecConstants.asc http://www.informatik.uni-bremen.de/~hobold/AltiVec.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27006
[Bug target/27282] [4.2 regression] ICE in final_scan_insn, at final.c:2448 - could not split insn
--- Comment #7 from dje at watson dot ibm dot com 2006-04-25 15:21 --- Subject: Re: [4.2 regression] ICE in final_scan_insn, at final.c:2448 - could not split insn The patch may be necessary, but does not fix the testcase. The testcase needs the patch that Andrew originally tested: Index: combine.c === --- combine.c (revision 113239) +++ combine.c (working copy) @@ -8210,7 +8209,8 @@ simplify_and_const_int (rtx x, enum mach return tem; if (!x) -x = simplify_gen_binary (AND, GET_MODE (varop), varop, GEN_INT (constop)); +x = simplify_gen_binary (AND, GET_MODE (varop), varop, +gen_int_mode (constop, mode)); if (GET_MODE (x) != mode) x = gen_lowpart (mode, x); return x; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27282
[Bug target/27287] [4.1/4.2 Regression] returning constant double
--- Comment #10 from dje at watson dot ibm dot com 2006-07-13 16:31 --- Subject: Re: [4.1/4.2 Regression] returning constant double >>>>> edmar at freescale dot com writes: edmar> I tried the patch on comment 7 on gcc main line from yesterday. It did not work edmar> for me: Tried the patch with what specific example? I have mainline built with the patch and tested the testcases from both PR 27287 and PR 27875. Both succeed. Are you absolutely sure that you applied the patch and rebuilt the compiler? Are you absolutely sure that you tested the compiler you just built and did not accidentally test another installed compiler? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27287
[Bug target/27287] [4.1/4.2 Regression] returning constant double
--- Comment #12 from dje at watson dot ibm dot com 2006-07-13 19:58 --- Subject: Re: [4.1/4.2 Regression] returning constant double >>>>> edmar at freescale dot com writes: edmar> And to kill the last shread of doubt, here I am using the xgcc present on the edmar> very same build directoty: edmar> /local/gnu_toolchain/build_area/obj_gcc-trunk_e500v2/gcc/xgcc -O2 -c foo.c edmar> Did I miss anything ? Yes, you missed "-B./" or "-B/local/gnu_toolchain/build_area/obj_gcc-trunk_e500v2/gcc/" You are using the newly built driver "xgcc", but invoking a previously installed cc1 compiler. You are not testing the newly built compiler containing the patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27287
[Bug target/27287] [4.1/4.2 Regression] returning constant double
--- Comment #14 from dje at watson dot ibm dot com 2006-07-13 20:36 ---
Subject: Re: [4.1/4.2 Regression] returning constant double
What, exactly, is your testcase foo.c? The example at the top of
PR 28287?
$ cat foo.c
double f (void) { return 0; }
$ ./xgcc -B./ -O2 -S foo.c
$ ./xgcc -B./ -v
Reading specs from ./specs
Target: powerpc-unknown-linux-gnuspe
Configured with: /farm/dje/src/src/configure
--target=powerpc-unknown-linux-gnuspe --enable-e500_double --enable-languages=c
Thread model: posix
gcc version 4.2.0 20060713 (experimental)
$ cat foo.s
.file "foo.c"
.section".text"
.align 2
.globl f
.type f, @function
f:
lis 9,[EMAIL PROTECTED]
la 9,[EMAIL PROTECTED](9)
lwz 3,0(9)
lwz 4,4(9)
blr
.size f, .-f
.section.rodata
.align 3
.set.LANCHOR0,. + 0
.LC0:
.4byte 0
.4byte 0
.ident "GCC: (GNU) 4.2.0 20060713 (experimental)"
.section.note.GNU-stack,"",@progbits
$ cd ...src...
$ svn diff spe.md
Index: spe.md
===
--- spe.md (revision 115408)
+++ spe.md (working copy)
@@ -2211,11 +2211,13 @@
[(set_attr "length" "8")])
(define_insn "*frob_di_df_2"
- [(set (subreg:DF (match_operand:DI 0 "register_operand" "=&r") 0)
- (match_operand:DF 1 "register_operand" "r"))]
+ [(set (subreg:DF (match_operand:DI 0 "register_operand" "=&r,r") 0)
+ (match_operand:DF 1 "input_operand" "r,m"))]
"TARGET_E500_DOUBLE"
- "evmergehi %H0,%1,%1\;evmergelo %L0,%1,%1"
- [(set_attr "length" "8")])
+ "@
+ evmergehi %H0,%1,%1\;evmergelo %L0,%1,%1
+ evldd%X1 %0,%y1"
+ [(set_attr "length" "8,*")])
(define_insn "*mov_sidf_e500_subreg0"
[(set (subreg:SI (match_operand:DF 0 "register_operand" "+r") 0)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27287
[Bug tree-optimization/18048] [4.0/4.1 Regression] mgrid loop performance regression with ivopts (register pressure)
--- Comment #21 from dje at watson dot ibm dot com 2005-11-14 01:58 --- Subject: Re: [4.0/4.1 Regression] mgrid loop performance regression with ivopts (register pressure) And mesa has taken a performance dive... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18048
[Bug target/24779] [4.0 Regression] Python miscompilation - TOC reload
--- Comment #5 from dje at watson dot ibm dot com 2005-11-16 17:45 ---
Subject: Re: Python miscompilation - TOC reload
Appended is a proposed patch to backport the easy_fp_constant
change to 4.0. Can you check if this fixes the problem? This patch may
hurt performance because the float extend functionality is not in 4.0.
PR target/24779
* config/rs6000/rs6000.c (easy_fp_constant): SFmode constant
0.0f is easy. Return 0 for SFmode and DFmode before reload when
flag_unsafe_math_optimizations not enabled.
* config/rs6000/rs6000.md (movdf splitter): Use
const_double_operand predicate for TARGET_POWERPC64.
Index: rs6000.c
===
*** rs6000.c(revision 106255)
--- rs6000.c(working copy)
*** easy_fp_constant (rtx op, enum machine_m
*** 2277,2283
long k[2];
REAL_VALUE_TYPE rv;
! if (TARGET_E500_DOUBLE)
return 0;
REAL_VALUE_FROM_CONST_DOUBLE (rv, op);
--- 2277,2290
long k[2];
REAL_VALUE_TYPE rv;
! /* Force constants to memory before reload to utilize
!compress_float_constant.
!Avoid this when flag_unsafe_math_optimizations is enabled
!because RDIV division to reciprocal optimization is not able
!to regenerate the division. */
! if (TARGET_E500_DOUBLE
! || (!reload_in_progress && !reload_completed
! && !flag_unsafe_math_optimizations))
return 0;
REAL_VALUE_FROM_CONST_DOUBLE (rv, op);
*** easy_fp_constant (rtx op, enum machine_m
*** 2291,2296
--- 2298,2316
{
long l;
REAL_VALUE_TYPE rv;
+
+ /* The constant 0.f is easy. */
+ if (op == CONST0_RTX (SFmode))
+ return 1;
+
+ /* Force constants to memory before reload to utilize
+compress_float_constant.
+Avoid this when flag_unsafe_math_optimizations is enabled
+because RDIV division to reciprocal optimization is not able
+to regenerate the division. */
+ if (!reload_in_progress && !reload_completed
+ && !flag_unsafe_math_optimizations)
+ return 0;
REAL_VALUE_FROM_CONST_DOUBLE (rv, op);
REAL_VALUE_TO_TARGET_SINGLE (rv, l);
Index: rs6000.md
===
*** rs6000.md (revision 106255)
--- rs6000.md (working copy)
***
*** 8043,8049
(define_split
[(set (match_operand:DF 0 "gpc_reg_operand" "")
! (match_operand:DF 1 "easy_fp_constant" ""))]
"TARGET_POWERPC64 && reload_completed
&& ((GET_CODE (operands[0]) == REG && REGNO (operands[0]) <= 31)
|| (GET_CODE (operands[0]) == SUBREG
--- 8043,8049
(define_split
[(set (match_operand:DF 0 "gpc_reg_operand" "")
! (match_operand:DF 1 "const_double_operand" ""))]
"TARGET_POWERPC64 && reload_completed
&& ((GET_CODE (operands[0]) == REG && REGNO (operands[0]) <= 31)
|| (GET_CODE (operands[0]) == SUBREG
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24779
[Bug target/24779] [4.0 Regression] Python miscompilation - TOC reload
--- Comment #9 from dje at watson dot ibm dot com 2005-11-17 15:17 --- Subject: Re: [4.0 Regression] Python miscompilation - TOC reload "Reliably" is the wrong word. The patch will fix the problem reliably for the default case; it will not fix it for a particular set of options. The remaining problem is seeing constants through TOC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24779
[Bug target/25180] [4.1 Regression] ICE during kernel build.
--- Comment #14 from dje at watson dot ibm dot com 2005-12-19 15:32 --- Subject: Re: [4.1 Regression] ICE during kernel build. Okay. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25180
[Bug target/27287] [4.1 Regression] returning constant double
--- Comment #22 from dje at watson dot ibm dot com 2006-08-29 19:26 --- Subject: Re: [4.1 Regression] returning constant double One of the patterns probably needs a r->m case as well, but we need a testcase to figure out which one. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27287
[Bug target/27287] [4.1/4.2 Regression] returning constant double
--- Comment #29 from dje at watson dot ibm dot com 2006-08-30 18:08 --- Subject: Re: [4.1/4.2 Regression] returning constant double Yes, I was testing out the same change as your second patch. That looks reasonable if it works. By the way, the use of "%H" in the frob patterns is completely wrong and should be removed. %H does not mean high register. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27287
[Bug target/27287] [4.1/4.2 Regression] returning constant double
--- Comment #30 from dje at watson dot ibm dot com 2006-08-30 18:42 --- Subject: Re: [4.1/4.2 Regression] returning constant double In other words, should the lwz actually be evlwwsplat? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27287
[Bug target/27287] [4.1/4.2 Regression] returning constant double
--- Comment #34 from dje at watson dot ibm dot com 2006-08-31 13:50 --- Subject: Re: [4.1/4.2 Regression] returning constant double >>>>> guenter at roeck-us dot net writes: guenter> Hmm ... what would be the point ? evlwwsplat copies 32 bit memory content into guenter> the upper and lower 32 bits of the target register. The upper part is not guenter> needed in the given case, so moving data into it would not provide any benefit. guenter> Am I missing something ? Because the pattern is emitting evmergelo/evmergehi for the r->r case, which is the equivalent data transfer and duplication, for no apparent reason. guenter> Would using evlwwsplat make subsequent optimizations more difficult ? That guenter> might be an argument against it. Other than that, I don't really care which guenter> opcodes to use, as long as the resulting code works. The choice of emitting mnemonics is performed as the very last stage, so the compiler does not have any knowledge of this if the RTL description does not express this. David -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27287
[Bug target/27287] [4.1/4.2 Regression] returning constant double
--- Comment #35 from dje at watson dot ibm dot com 2006-08-31 14:23 --- Subject: Re: [4.1/4.2 Regression] returning constant double >>>>> guenter at roeck-us dot net writes: guenter> Hmm ... what would be the point ? evlwwsplat copies 32 bit memory content into guenter> the upper and lower 32 bits of the target register. The upper part is not guenter> needed in the given case, so moving data into it would not provide any benefit. guenter> Am I missing something ? Because the pattern is emitting evmergelo/evmergehi for the r->r case, which is the equivalent data transfer and duplication, for no apparent reason. guenter> Would using evlwwsplat make subsequent optimizations more difficult ? That guenter> might be an argument against it. Other than that, I don't really care which guenter> opcodes to use, as long as the resulting code works. The choice of emitting mnemonics is performed as the very last stage, so the compiler does not have any knowledge of this if the RTL description does not express this. David -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27287
[Bug target/27287] [4.1/4.2 Regression] returning constant double
--- Comment #36 from dje at watson dot ibm dot com 2006-09-01 19:56 --- Subject: Re: [4.1/4.2 Regression] returning constant double What is confusing to me is that the r->r case is using evmergehi and evmergelo. This is placing the value in both halves of the SIMD register. It seems like this could have been done with two "mr". It is ambiguous whether the pattern is trying to load the full 64 bit register or not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27287
[Bug middle-end/28690] [4.2 Regression] Performace problem with indexed load/stores on powerpc
--- Comment #22 from dje at watson dot ibm dot com 2006-10-03 18:09 --- Subject: Re: [4.2 Regression] Performace problem with indexed load/stores on powerpc I am not suggesting that the problem has to be solved in swap_commutative_operands, etc. I would think that GCC should be able to create commutative addresses where they are formed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28690
[Bug tree-optimization/32865] [4.3 Regression] glibc ICE's gcc-4.3.0 SSA corruption
--- Comment #5 from dje at watson dot ibm dot com 2007-07-23 18:05 --- Subject: Re: [4.3 Regression] glibc ICE's gcc-4.3.0 SSA corruption >>>>> michelin60 at gmail dot com writes: michelin60> Doing a search of PR's filed I came up, surprise, with no remotely equivalent michelin60> report and I chose people that matched what I reported. As the author of the michelin60> report I think that I have the right to choose peple that match as provided by michelin60> the MAINTAINER's list No, you do not. You submitted the bug. Let the GCC developers decide how best to triage and analyse the bug. David -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32865
[Bug regression/32582] Bootstrap with vectorization enabled fails with ICE on PPC
--- Comment #10 from dje at watson dot ibm dot com 2007-07-28 19:40 --- Subject: Re: Bootstrap with vectorization enabled fails with ICE on PPC Should this test be using -mabi=altivec or is there a general assumption of -mabi=altivec when using autovec? That conditionally sets the call clobbered registers correctly. I don't think the MD should change for -maltivec. David -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32582
[Bug regression/32582] Bootstrap with vectorization enabled fails with ICE on PPC
--- Comment #12 from dje at watson dot ibm dot com 2007-07-28 19:48 ---
Subject: Re: Bootstrap with vectorization enabled fails with ICE on PPC
And we default to ALTIVEC ABI for powerpc-linux:
/* Set Altivec ABI as default for powerpc64 linux. */
if (TARGET_ELF && TARGET_64BIT)
{
rs6000_altivec_abi = 1;
TARGET_ALTIVEC_VRSAVE = 1;
}
So something else is wrong.
David
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32582
[Bug regression/32582] Bootstrap with vectorization enabled fails with ICE on PPC
--- Comment #15 from dje at watson dot ibm dot com 2007-07-28 21:48 --- Subject: Re: Bootstrap with vectorization enabled fails with ICE on PPC >>>>> rakdver at kam dot mff dot cuni dot cz writes: rakdver> Probably the problem is that -maltivec does not rakdver> imply -mabi=altivec, or some similar omission. -maltivec does not imply -mabi=altivec, which is intended. The Bugzilla PR says the target is powerpc64-linux, which implicitly should enable -mabi=altivec. If this is some other target, then the BOOT_CFLAGS should include -mabi=altivec. Either something is wrong with GCC enabling ALTIVEC_ABI or this is cockpit error in the options used to bootstrap GCC that has been hidden until now. David -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32582
[Bug regression/32582] Bootstrap with vectorization enabled fails with ICE on PPC
--- Comment #18 from dje at watson dot ibm dot com 2007-07-29 11:57 --- Subject: Re: Bootstrap with vectorization enabled fails with ICE on PPC >>>>> rakdver at kam dot mff dot cuni dot cz writes: >> it's on ppc-linux. rakdver> I mean, I did the testing on ppc-linux; it is possible that there is rakdver> another misscompilation on ppc64-linux, though. The target in the PR says powerpc64-linux, which is what confused Andrew and me. There is a valid mode of Altivec programming using builtins and asms that does not require the Altivec ABI. That is what -maltivec supports. I suspect that -ftree-vectorize should enable -mabi=altivec by default on PowerPC. David -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32582
[Bug regression/32582] Bootstrap with vectorization enabled fails with ICE on PPC
--- Comment #28 from dje at watson dot ibm dot com 2007-08-13 15:17 --- Subject: Re: Bootstrap with vectorization enabled fails with ICE on PPC Most everyone else bootstraps GCC on PPC64 with --with-cpu=default32. Are you missing some packages on SUSE? This really isn't a GCC bug any more, it is some problem with the way that you are configuring and building GCC on your system. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32582
[Bug fortran/33271] nint_2.f90 abort compiled with -O0
--- Comment #11 from dje at watson dot ibm dot com 2007-09-05 17:13 ---
Subject: Re: nint_2.f90 abort compiled with -O0
>>>>> fxcoudert at gcc dot gnu dot org writes:
FX> look into ${builddir}/${target_triplet}/libgfortran/config.h to
FX> see what value have the HAVE_LROUND{F,,L} and HAVE_LLROUND{F,,L} macros?
/* libm includes llround */
#define HAVE_LLROUND 1
/* libm includes llroundf */
#define HAVE_LLROUNDF 1
/* libm includes llroundl */
#define HAVE_LLROUNDL 1
/* libm includes lround */
#define HAVE_LROUND 1
/* libm includes lroundf */
#define HAVE_LROUNDF 1
/* libm includes lroundl */
#define HAVE_LROUNDL 1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33271
[Bug fortran/33271] nint_2.f90 abort compiled with -O0
--- Comment #12 from dje at watson dot ibm dot com 2007-09-05 17:19 --- Subject: Re: nint_2.f90 abort compiled with -O0 >>>>> fxcoudert at gcc dot gnu dot org writes: FX> David, could you test my C program in comment #4 $ ./xgcc -B./ -W -Wall -O1 fx.c fx.c: In function 'main': fx.c:46: warning: integer constant is too large for 'long' type fx.c:47: warning: integer constant is too large for 'long' type fx.c:51: warning: integer constant is too large for 'long' type fx.c:52: warning: integer constant is too large for 'long' type $ ./a.out 4 4 8 $ ./xgcc -B./ -W -Wall -O0 fx.c fx.c: In function 'main': fx.c:46: warning: integer constant is too large for 'long' type fx.c:47: warning: integer constant is too large for 'long' type fx.c:51: warning: integer constant is too large for 'long' type fx.c:52: warning: integer constant is too large for 'long' type ld: 0711-317 ERROR: Undefined symbol: .lround ld: 0711-317 ERROR: Undefined symbol: .lroundf ld: 0711-317 ERROR: Undefined symbol: .llround $ ./xgcc -B./ -W -Wall -O0 fx.c -lm fx.c: In function 'main': fx.c:46: warning: integer constant is too large for 'long' type fx.c:47: warning: integer constant is too large for 'long' type fx.c:51: warning: integer constant is too large for 'long' type fx.c:52: warning: integer constant is too large for 'long' type $ ./a.out 4 4 8 Abort 1 $ ./xgcc -B./ -maix64 -W -Wall -O1 fx.c $ ./a.out 4 8 8 $ ./xgcc -B./ -maix64 -W -Wall -O0 fx.c -lm $ ./a.out 4 8 8 Abort 1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33271
[Bug target/20814] ICE in extract_insn for test vmx/varargs-1.c
--- Additional Comments From dje at watson dot ibm dot com 2005-04-07 22:09 --- Subject: Re: New: ICE in extract_insn for test vmx/varargs-1.c Let me know if the appended patch fixes the ICE. The definition of the "and" predicates was ignoring CONST_INT that matched predicate logical_operand. David Index: predicates.md === RCS file: /cvs/gcc/gcc/gcc/config/rs6000/predicates.md,v retrieving revision 1.10 diff -c -p -r1.10 predicates.md *** predicates.md 2 Apr 2005 10:46:03 - 1.10 --- predicates.md 7 Apr 2005 22:07:33 - *** *** 531,559 ;; Return 1 if the operand is either a non-special register or a constant ;; that can be used as the operand of a PowerPC64 logical AND insn. (define_predicate "and64_operand" ! (if_then_else (match_code "const_int") ! (match_operand 0 "mask64_operand") ! (if_then_else (match_test "fixed_regs[CR0_REGNO]") ! (match_operand 0 "gpc_reg_operand") ! (match_operand 0 "logical_operand" ;; Like and64_operand, but also match constants that can be implemented ;; with two rldicl or rldicr insns. (define_predicate "and64_2_operand" ! (if_then_else (match_code "const_int") ! (match_test "mask64_1or2_operand (op, mode, true)") ! (if_then_else (match_test "fixed_regs[CR0_REGNO]") ! (match_operand 0 "gpc_reg_operand") ! (match_operand 0 "logical_operand" ;; Return 1 if the operand is either a non-special register or a ;; constant that can be used as the operand of a logical AND. (define_predicate "and_operand" ! (if_then_else (match_code "const_int") ! (match_operand 0 "mask_operand") ! (if_then_else (match_test "fixed_regs[CR0_REGNO]") ! (match_operand 0 "gpc_reg_operand") ! (match_operand 0 "logical_operand" ;; Return 1 if the operand is a general non-special register or memory operand. (define_predicate "reg_or_mem_operand" --- 531,557 ;; Return 1 if the operand is either a non-special register or a constant ;; that can be used as the operand of a PowerPC64 logical AND insn. (define_predicate "and64_operand" ! (ior (match_operand 0 "mask64_operand") !(if_then_else (match_test "fixed_regs[CR0_REGNO]") !(match_operand 0 "gpc_reg_operand") !(match_operand 0 "logical_operand" ;; Like and64_operand, but also match constants that can be implemented ;; with two rldicl or rldicr insns. (define_predicate "and64_2_operand" ! (ior (and (match_code "const_int") ! (match_test "mask64_1or2_operand (op, mode, true)")) !(if_then_else (match_test "fixed_regs[CR0_REGNO]") !(match_operand 0 "gpc_reg_operand") !(match_operand 0 "logical_operand" ;; Return 1 if the operand is either a non-special register or a ;; constant that can be used as the operand of a logical AND. (define_predicate "and_operand" ! (ior (match_operand 0 "mask_operand") !(if_then_else (match_test "fixed_regs[CR0_REGNO]") !(match_operand 0 "gpc_reg_operand") !(match_operand 0 "logical_operand" ;; Return 1 if the operand is a general non-special register or memory operand. (define_predicate "reg_or_mem_operand" -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20814
[Bug target/20814] [4.1 Regression] ICE in extract_insn for test vmx/varargs-1.c
--- Additional Comments From dje at watson dot ibm dot com 2005-04-08 18:57 --- Subject: Re: New: ICE in extract_insn for test vmx/varargs-1.c In addition to the previous change, altivec_register_operand needs to accept SUBREG. David Index: predicates.md === RCS file: /cvs/gcc/gcc/gcc/config/rs6000/predicates.md,v retrieving revision 1.10 diff -c -p -r1.10 predicates.md *** predicates.md 2 Apr 2005 10:46:03 - 1.10 --- predicates.md 7 Apr 2005 22:07:33 - *** *** 34,42 ;; Return 1 if op is an Altivec register. (define_predicate "altivec_register_operand" ! (and (match_code "reg") !(match_test "ALTIVEC_REGNO_P (REGNO (op)) ! || REGNO (op) > LAST_VIRTUAL_REGISTER"))) ;; Return 1 if op is XER register. (define_predicate "xer_operand" --- 34,44 ;; Return 1 if op is an Altivec register. (define_predicate "altivec_register_operand" ! (and (match_code "reg,subreg") !(and (match_operand 0 "register_operand") ! (match_test "GET_CODE (op) != REG !|| ALTIVEC_REGNO_P (REGNO (op)) !|| REGNO (op) > LAST_VIRTUAL_REGISTER" ;; Return 1 if op is XER register. (define_predicate "xer_operand" *** *** 531,559 ;; Return 1 if the operand is either a non-special register or a constant ;; that can be used as the operand of a PowerPC64 logical AND insn. (define_predicate "and64_operand" ! (if_then_else (match_code "const_int") ! (match_operand 0 "mask64_operand") ! (if_then_else (match_test "fixed_regs[CR0_REGNO]") ! (match_operand 0 "gpc_reg_operand") ! (match_operand 0 "logical_operand" ;; Like and64_operand, but also match constants that can be implemented ;; with two rldicl or rldicr insns. (define_predicate "and64_2_operand" ! (if_then_else (match_code "const_int") ! (match_test "mask64_1or2_operand (op, mode, true)") ! (if_then_else (match_test "fixed_regs[CR0_REGNO]") ! (match_operand 0 "gpc_reg_operand") ! (match_operand 0 "logical_operand" ;; Return 1 if the operand is either a non-special register or a ;; constant that can be used as the operand of a logical AND. (define_predicate "and_operand" ! (if_then_else (match_code "const_int") ! (match_operand 0 "mask_operand") ! (if_then_else (match_test "fixed_regs[CR0_REGNO]") ! (match_operand 0 "gpc_reg_operand") ! (match_operand 0 "logical_operand" ;; Return 1 if the operand is a general non-special register or memory operand. (define_predicate "reg_or_mem_operand" --- 533,559 ;; Return 1 if the operand is either a non-special register or a constant ;; that can be used as the operand of a PowerPC64 logical AND insn. (define_predicate "and64_operand" ! (ior (match_operand 0 "mask64_operand") !(if_then_else (match_test "fixed_regs[CR0_REGNO]") !(match_operand 0 "gpc_reg_operand") !(match_operand 0 "logical_operand" ;; Like and64_operand, but also match constants that can be implemented ;; with two rldicl or rldicr insns. (define_predicate "and64_2_operand" ! (ior (and (match_code "const_int") ! (match_test "mask64_1or2_operand (op, mode, true)")) !(if_then_else (match_test "fixed_regs[CR0_REGNO]") !(match_operand 0 "gpc_reg_operand") !(match_operand 0 "logical_operand" ;; Return 1 if the operand is either a non-special register or a ;; constant that can be used as the operand of a logical AND. (define_predicate "and_operand" ! (ior (match_operand 0 "mask_operand") !(if_then_else (match_test "fixed_regs[CR0_REGNO]") !(match_operand 0 "gpc_reg_operand") !(match_operand 0 "logical_operand" ;; Return 1 if the operand is a general non-special register or memory operand. (define_predicate "reg_or_mem_operand" -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20814
[Bug target/32347] ICE on gcc/testsuite/gcc-dg/vmx/ops.c
--- Comment #16 from dje at watson dot ibm dot com 2007-06-22 16:44 --- Subject: Re: ICE on gcc/testsuite/gcc-dg/vmx/ops.c There are much more constructive ways in which to interact with the GCC community, GCC developers, and port maintainers than you have chosen to pursue. I am sorry that we are not addressing your particular bug as quickly as you would like. Insisting on action after one week and making personal attacks are not appropriate. David -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32347
[Bug libstdc++/22554] [4.1 Regression] pb_assoc header build and install overflows exec
--- Additional Comments From dje at watson dot ibm dot com 2005-09-15 18:38 --- Subject: Re: [4.1 Regression] pb_assoc header build and install overflows exec >>>>> bkoz at gcc dot gnu dot org writes: Ben> This looks fixed now. Can I close this? Yes, the latest version appears to be working well. Thanks, David -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22554
[Bug target/24119] gcc-4.x fails to build on AIX 5.2.0.0-ML04
--- Comment #7 from dje at watson dot ibm dot com 2005-10-04 15:00 --- Subject: Re: gcc-4.x fails to build on AIX 5.2.0.0-ML04 >>>>> h dot m dot brand at xs4all dot nl writes: h> Next step is to upgrade vac-6.0.0.11 to vac-7.0.0.3 You said that you are bootstrapping with GCC-4.0 snapshot. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24119
[Bug target/24119] gcc-4.x fails to build on AIX 5.2.0.0-ML04
--- Comment #9 from dje at watson dot ibm dot com 2005-10-04 19:24 --- Subject: Re: gcc-4.x fails to build on AIX 5.2.0.0-ML04 I bootstrap GCC every day without seeing this problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24119
[Bug target/24119] gcc-4.x fails to build on AIX 5.2.0.0-ML04
--- Comment #13 from dje at watson dot ibm dot com 2005-10-06 13:30 --- Subject: Re: gcc-4.x fails to build on AIX 5.2.0.0-ML04 > That worked. But I still saw the -B added to all the lines, but now that > that folder is not there, all goes smooth > As you can see: *I* did not put any -B options in there, so it must either be > the Makefiles or configure that puts them in because of my --prefix and/or > --with-local-prefix The -B still is added, because you did not clear the CC environment variable in the shell where you did the previous configures. GCC does not automatically add -B. David -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24119
[Bug target/24119] gcc-4.x fails to build on AIX 5.2.0.0-ML04
--- Comment #15 from dje at watson dot ibm dot com 2005-10-06 14:07 --- Subject: Re: gcc-4.x fails to build on AIX 5.2.0.0-ML04 The -Wl,-bbigtoc fix has been committed to GCC 4.1 sources. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24119
[Bug fortran/21730] Character length incorrect.
--- Additional Comments From dje at watson dot ibm dot com 2005-07-13
18:23 ---
Subject: Re: Character length incorrect.
> What about the testcase, David?
I was focussing on the patch itself. Here's a testcase:
! PR fortran/21730
! {do-do run}
character*2 a
character*4 b
character*6 c
parameter (a="12")
parameter (b = a)
write (c,'("#",A,"#")') b
if (c .ne. '#12 #') call abort
end
David
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21730
[Bug fortran/21730] Character length incorrect.
--- Additional Comments From dje at watson dot ibm dot com 2005-07-14 03:37 --- Subject: Re: Character length incorrect. >>>>> fengwang at gcc dot gnu dot org writes: fengwang> IMHO, your patch only handles the scalar character and is not entire, though a fengwang> different bug is revealed by the above examples. I cannot tell if your response is an objection to my patch or not. Yes, gfortran has additional bugs in this area, but, as you mention, those are different bugs -- they exist prior to my patch. gfortran needs more work in this area, but we need to start somewhere. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21730
[Bug fortran/21730] Character length incorrect.
--- Additional Comments From dje at watson dot ibm dot com 2005-07-14 03:49 --- Subject: Re: Character length incorrect. >>>>> fengwang at gcc dot gnu dot org writes: Feng> Having a good start, why not fix entirely? If somebody agrees to fix step by Feng> step, I have no objection. Because developers are volunteers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21730
[Bug libstdc++/22554] [4.1 Regression] pb_assoc header build and install overflows exec
--- Additional Comments From dje at watson dot ibm dot com 2005-07-20 14:26 --- Subject: Re: [4.1 Regression] pb_assoc header build and install overflows exec > Please for completeness sake put in the generated command that kills AIX, and > the AIX output. make[1]: Entering directory `/tmp/powerpc-ibm-aix5.2.0.0-20050720/powerpc-ibm-aix5.2.0.0/libstdc++-v3' make "AR_FLAGS=rc" "CC_FOR_BUILD=gcc" "CC_FOR_TARGET=/tmp/powerpc-ibm-aix5.2.0.0-20050720/./gcc/xgcc -B/tmp/powerpc-ibm-aix5.2.0.0-20050720/./gcc/ -B/farm/dje/install/powerpc-ibm-aix5.2.0.0-20050720/powerpc-ibm-aix5.2.0.0/bin/ -B/farm/dje/install/powerpc-ibm-aix5.2.0.0-20050720/powerpc-ibm-aix5.2.0.0/lib/ -isystem /farm/dje/install/powerpc-ibm-aix5.2.0.0-20050720/powerpc-ibm-aix5.2.0.0/include -isystem /farm/dje/install/powerpc-ibm-aix5.2.0.0-20050720/powerpc-ibm-aix5.2.0.0/sys-include" "CFLAGS=-O2 -g -O2" "CXXFLAGS=-g -O2" "CFLAGS_FOR_BUILD=-g -O2" "CFLAGS_FOR_TARGET=-O2 -g -O2" "INSTALL=/farm/dje/src/src/install-sh -c" "INSTALL_DATA=/farm/dje/src/src/install-sh -c -m 644" "INSTALL_PROGRAM=/farm/dje/src/src/install-sh -c" "INSTALL_SCRIPT=/farm/dje/src/src/install-sh -c" "LDFLAGS=" "LIBCFLAGS=-O2 -g -O2" "LIBCFLAGS_FOR_TARGET=-O2 -g -O2" "MAKE=make" "MAKEINFO=makeinfo --split-size=500 " "PICFLAG=" "PICFLAG_FOR_TARGET=" "SHELL=/bin/sh" "RUNTESTFLAGS=" "exec_prefix=/farm/d! je/install/powerpc-ibm-aix5.2.0.0-20050720" "infodir=/farm/dje/install/powerpc-ibm-aix5.2.0.0-20050720/info" "libdir=/farm/dje/install/powerpc-ibm-aix5.2.0.0-20050720/lib" "includedir=/farm/dje/install/powerpc-ibm-aix5.2.0.0-20050720/include" "prefix=/farm/dje/install/powerpc-ibm-aix5.2.0.0-20050720" "tooldir=/farm/dje/install/powerpc-ibm-aix5.2.0.0-20050720/powerpc-ibm-aix5.2.0.0" "gxx_include_dir=/farm/dje/install/powerpc-ibm-aix5.2.0.0-20050720/include/c++/4.1.0" "AR=ar -X32_64" "AS=/tmp/powerpc-ibm-aix5.2.0.0-20050720/./gcc/as" "LD=ld" "RANLIB=ranlib" "NM=/tmp/powerpc-ibm-aix5.2.0.0-20050720/./gcc/nm -B -X32_64" "NM_FOR_BUILD=" "NM_FOR_TARGET=/tmp/powerpc-ibm-aix5.2.0.0-20050720/./gcc/nm -B -X32_64" "DESTDIR=" "WERROR=" all-recursive make[2]: Entering directory `/tmp/powerpc-ibm-aix5.2.0.0-20050720/powerpc-ibm-aix5.2.0.0/libstdc++-v3' Making all in include /tmp/powerpc-ibm-aix5.2.0.0-20050720/powerpc-ibm-aix5.2.0.0/libstdc++-v3/include make[3]: Entering directory `/tmp/powerpc-ibm-aix5.2.0.0-20050720/powerpc-ibm-aix5.2.0.0/libstdc++-v3/include' cd ./ext/pb_assoc && for h in /farm/dje/src/src/libstdc++-v3/include/ext/pb_assoc/detail/tree_assoc_cntnr/constructor_destructor_fn_imps.hpp /farm/dje/src/src/libstdc++-v3/include/ext/pb_assoc/detail/type_utils.hpp /farm/dje/src/src/libstdc++-v3/include/ext/pb_assoc/detail/order_statistics_imp.hpp /farm/dje/src/src/libstdc++-v3/include/ext/pb_assoc/detail/basic_assoc_cntnr/d_find_fn_imps.hpp /farm/dje/src/src/libstdc++-v3/include/ext/pb_assoc/detail/basic_assoc_cntnr/d_insert_fn_imps.hpp /farm/dje/src/src/libstdc++-v3/include/ext/pb_assoc/detail/basic_assoc_cntnr/extract_key.hpp /farm/dje/src/src/libstdc++-v3/include/ext/pb_assoc/detail/basic_assoc_cntnr/erase_fn_imps.hpp /farm/dje/src/src/libstdc++-v3/include/ext/pb_assoc/detail/basic_assoc_cntnr/insert_fn_imps.hpp /farm/dje/src/src/libstdc++-v3/include/ext/pb_assoc/detail/basic_assoc_cntnr/constructor_destructor_fn_imps.hpp /farm/dje/src/src/libstdc++-v3/include/ext/pb_assoc/detail/basic_assoc_cntnr/info_fn_imps.hpp /farm/! dje/src/src/libstdc++-v3/include/ext/pb_assoc/detail/basic_assoc_cntnr/iterators_fn_imps.hpp /farm/dje/src/src/libstdc++-v3/include/ext/pb_assoc/detail/basic_assoc_cntnr/d_extract_key.hpp /farm/dje/src/src/libstdc++-v3/include/ext/pb_assoc/detail/basic_assoc_cntnr/constructors_destructor_fn_imps.hpp /farm/dje/src/src/libstdc++-v3/include/ext/pb_assoc/detail/splay_tree_/erase_fn_imps.hpp /farm/dje/src/src/libstdc++-v3/include/ext/pb_assoc/detail/splay_tree_/splay_tree_.hpp /farm/dje/src/src/libstdc++-v3/include/ext/pb_assoc/detail/splay_tree_/node.hpp /farm/dje/src/src/libstdc++-v3/include/ext/pb_assoc/detail/splay_tree_/insert_fn_imps.hpp /farm/dje/src/src/libstdc++-v3/include/ext/pb_assoc/detail/splay_tree_/find_fn_imps.hpp /farm/dje/src/src/libstdc++-v3/include/ext/pb_assoc/detail/splay_tree_/splay_fn_imps.hpp /farm/dje/src/src/libstdc++-v3/include/ext/pb_assoc/detail/splay_tree_/split_join_fn_imps.hpp /farm/dje/src/src/libstdc++-v3/include/ext/pb_assoc/detail/splay_tree_! /info_fn_imps.hpp /farm/dje/src/src/libstdc++-v3/include/ext/p! b_assoc/ detail/splay_tree_/debug_fn_imps.hpp /farm/dje
[Bug target/23071] Darwin alignment ignores "attribute packed" for first 'double' element of a struct
--- Additional Comments From dje at watson dot ibm dot com 2005-07-26 16:58 --- Subject: Re: Darwin alignment ignores "attribute packed" for first 'double' element of a struct If Chris and Apple want to change the behavior for Darwin, be my guest. David -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23071
[Bug target/20366] AIX g++ -D_LARGE_FILES fails to compile #include
--- Comment #10 from dje at watson dot ibm dot com 2007-12-21 14:58 --- Subject: Re: AIX g++ -D_LARGE_FILES fails to compile #include > Why is this? -D_LARGE_FILES simply enables LFS. xlC works with and without > -D_LARGE_FILES. Shouldn't G++ work as effectively as xlC? You are mixing multiple questions and issues. -D_LARGE_FILES redefines all I/O functions to use the 64-bit versions. xlC has its own system header files. G++ needs to use the AIX system header files with changes from fixincludes, combined with libstdc++ header files that perform their own redefinitions. "Shouldn't G++ work as effectively..." is a business question, not a technical question. Many major AIX customers use GCC, but none have told IBM that they will not buy a system unless GCC works better. That sets investment priorities. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20366
[Bug target/20366] AIX g++ -D_LARGE_FILES fails to compile #include
--- Comment #15 from dje at watson dot ibm dot com 2007-12-22 20:52 --- Subject: Re: AIX g++ -D_LARGE_FILES fails to compile #include >>>>> tcoleman at autowares dot com writes: Tom> Does G++ really have to be either one way or the other? Can't it also include Tom> conditional code to check for _LARGE_FILES? Maybe I'm missing something here. GNU libc does not use _LARGE_FILE to distinguish large offsets in 32-bit file I/O. Why would the GCC libstdc++ community be interested in complicating its header files with AIX-specific checks? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20366
[Bug target/21616] [3.4 only] ICE: unable to find a register to spill in class `FLOAT_REGS'
--- Comment #11 from dje at watson dot ibm dot com 2006-02-28 15:19 --- Subject: Re: [3.4 only] ICE: unable to find a register to spill in class `FLOAT_REGS' If Alan and Gaby want the patch backported to GCC 3.4 branch, it's okay with me. The patch is fine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21616
[Bug tree-optimization/21048] [4.1 Regression] use of poisoned ggc memory causes cpu2000 build failures
--- Additional Comments From dje at watson dot ibm dot com 2005-04-25 19:20 --- Subject: Re: [4.1 Regression] use of poisoned ggc memory causes cpu2000 build failures The patch fixes the testcase for me on AIX. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21048
[Bug target/19645] PPC64 64-bit build failure
--- Additional Comments From dje at watson dot ibm dot com 2005-01-27 19:09 --- Subject: Re: PPC64 64-bit build failure I configured with: --build=powerpc64-linux --host=powerpc64-linux --target=powerpc64-linux --with-cpu=default32 --enable-threads=posix --enable-shared --enable-__cxa_atexit --with-gcc-version-trigger=/home/dje/src/src/gcc/version.c --enable-languages=c,c++ I am building everything with -m64. Are you also adding -mcpu=G5? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19645
[Bug target/19645] PPC64 64-bit build failure
--- Additional Comments From dje at watson dot ibm dot com 2005-01-27 21:20 --- Subject: Re: PPC64 64-bit build failure --with-cpu=default32 builds 32bit by default IIRC. You obviously replied without reading my message. I said, "I am building everything with -m64". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19645
[Bug target/15286] ICE cause by reload
--- Additional Comments From dje at watson dot ibm dot com 2004-10-18 01:50 --- Subject: Re: ICE cause by reload (subreg:SI (reg:DI)) normally isn't a problem, except when reg:DI is assigned to an FPR. If reg:DI was assigned to an FPR, CLASS probably is NON_SPECIAL_REGS (encompassing both GPRs and FPRs), which would make the result from CANNOT_CHANGE_MODE_CLASS correct. I'm not sure what problems would be created if one redefined CANNOT_CHANGE_MODE_CLASS to return false for that super-class. The problem is that the pseudo was assigned to an FPR, which is valid for the CLASS, but not for the instruction. One way of looking at it is that regclass should not have widened the CLASS to include a sub-class for which CANNOT_CHANGE_MODE_CLASS is true. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15286
[Bug target/15286] ICE cause by reload
--- Additional Comments From dje at watson dot ibm dot com 2004-10-25 16:47 --- Subject: Re: ICE cause by reload >>>>> uweigand at gcc dot gnu dot org writes: Ulrich> Does this patch help? It changes the error, but I'm not sure if it helps. pr15286.c: In function 'GMRESSolver': pr15286.c:72: error: unrecognizable insn: (insn 512 183 397 0 (set (subreg:DI (mem:SI (plus:SI (reg/f:SI 1 r1) (const_int 204 [0xcc])) [15 clock_start+0 S4 A8]) 0) (reg:DI 32 f0)) -1 (nil) (nil)) pr15286.c:72: internal compiler error: in extract_insn, at recog.c:2034 It is storing to (SUBREG:DI (mem:SI)) instead of (mem:DI). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15286
[Bug target/15286] ICE cause by reload
--- Additional Comments From dje at watson dot ibm dot com 2004-10-25 18:04 --- Subject: Re: ICE cause by reload With both patches, the testcase works. This probably is a correct fix for reload. The code is a little messy and is cleaned up by implementing fixuns_truncdfsi, which also fixes the testcase. David -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15286
[Bug target/15286] ICE cause by reload
--- Additional Comments From dje at watson dot ibm dot com 2004-10-25 19:07 --- Subject: Re: ICE cause by reload > I applied the last two patch, but it didn;t help: The simplify-rtx.c patch is not *two* patches. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15286
[Bug target/15286] ICE cause by reload
--- Additional Comments From dje at watson dot ibm dot com 2004-10-25 21:11 --- Subject: Re: ICE cause by reload With the earlier *two* patches from Ulrich, the compiler no longer ICE. The latest patch to alter_subreg() (with the missing GET_MODEs) does not fix the subreg offset problem for me. bl L_clock$stub std r3,168(r1) lfd f0,168(r1) fcfid f0,f0 stfd f0,224(r1) fctidz f0,f0 stfd f0,204(r1) <--- ... bl L_clock$stub lwz r0,204(r1)<--- std r3,168(r1) std r0,176(r1) lfd f13,168(r1) lfd f0,176(r1) fcfid f12,f0 fcfid f0,f13 fsub f0,f0,f12 fctiwz f13,f0 stfd f13,184(r1) lwz r3,188(r1) The code continues to access the wrong word. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15286
[Bug target/15286] ICE cause by reload
--- Additional Comments From dje at watson dot ibm dot com 2004-10-25 23:43 --- Subject: Re: ICE cause by reload Try again with what patch? I have all patches applied and I consistently get the output I emailed earlier with a native Mac OS X compiler. David -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15286
[Bug target/15286] ICE cause by reload
--- Additional Comments From dje at watson dot ibm dot com 2004-10-26 00:13 --- Subject: Re: ICE cause by reload There is a reduced testcase attached to the Bugzilla PR. Please do not confuse discussion with other examples. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15286
[Bug target/15286] ICE cause by reload
--- Additional Comments From dje at watson dot ibm dot com 2004-10-26 04:28 --- Subject: Re: ICE cause by reload I found a typo in my sourcebase introduced when applying one of the patches. Fixing that typo (matching the complete patch attached to the PR) produces the correct offset. I think the patch is the correct change to get reload to behave correctly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15286
[Bug target/16800] PowerPC - Unnecessary rldicl
--- Additional Comments From dje at watson dot ibm dot com 2004-11-24 15:21 --- Subject: Re: PowerPC - Unnecessary rldicl The test for mode == Pmode is present because most of the fast scc patterns depend on carry. PowerPC carry depends on the mode of the processor. If the mode of the comparison is not the mode of the processor (Pmode), the scc patterns cannot be applied and the modified cost should not be applied. Similarly, only EQ, GTU, and LTU costs are handled because those are the fast scc patterns active for PowerPC. I did not include the costs for the original POWER architecture. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16800
[Bug middle-end/18641] [4.0 Regression] Another ICE caused by reload of a psuedo reg into f0 for a DImode expr
--- Additional Comments From dje at watson dot ibm dot com 2004-12-06 17:16 --- Subject: Re: [4.0 Regression] Another ICE caused by reload of a psuedo reg into f0 for a DImode expr The following patch implements the two suggestions. It fixes the ICE on AIX, but continues to produce an ICE on Mac OS X. Also, the CONST_INT case only should be relevant in 64-bit mode. Index: rs6000.h === RCS file: /cvs/gcc/gcc/gcc/config/rs6000/rs6000.h,v retrieving revision 1.348 diff -c -p -r1.348 rs6000.h *** rs6000.h27 Nov 2004 22:45:24 - 1.348 --- rs6000.h6 Dec 2004 17:14:18 - *** enum reg_class *** 1397,1404 */ #define PREFERRED_RELOAD_CLASS(X,CLASS) \ ! (((GET_CODE (X) == CONST_DOUBLE \ ! && GET_MODE_CLASS (GET_MODE (X)) == MODE_FLOAT) \ ? NO_REGS \ : (GET_MODE_CLASS (GET_MODE (X)) == MODE_INT \ && (CLASS) == NON_SPECIAL_REGS)\ --- 1397,1404 */ #define PREFERRED_RELOAD_CLASS(X,CLASS) \ ! (((CONSTANT_P (X) \ ! && reg_classes_intersect_p ((CLASS), FLOAT_REGS))\ ? NO_REGS \ : (GET_MODE_CLASS (GET_MODE (X)) == MODE_INT \ && (CLASS) == NON_SPECIAL_REGS)\ Index: rs6000.md === RCS file: /cvs/gcc/gcc/gcc/config/rs6000/rs6000.md,v retrieving revision 1.336 diff -c -p -r1.336 rs6000.md *** rs6000.md 1 Dec 2004 17:18:38 - 1.336 --- rs6000.md 6 Dec 2004 17:14:18 - *** *** 8496,8502 ; List r->r after r->"o<>", otherwise reload will try to reload a ; non-offsettable address by using r->r which won't make progress. (define_insn "*movdi_internal32" ! [(set (match_operand:DI 0 "nonimmediate_operand" "=o<>,r,r,f,f,m,r") (match_operand:DI 1 "input_operand" "r,r,m,f,m,f,IJKnGHF"))] "! TARGET_POWERPC64 && (gpc_reg_operand (operands[0], DImode) --- 8496,8502 ; List r->r after r->"o<>", otherwise reload will try to reload a ; non-offsettable address by using r->r which won't make progress. (define_insn "*movdi_internal32" ! [(set (match_operand:DI 0 "nonimmediate_operand" "=o<>,r,r,!*f,!*f,m,r") (match_operand:DI 1 "input_operand" "r,r,m,f,m,f,IJKnGHF"))] "! TARGET_POWERPC64 && (gpc_reg_operand (operands[0], DImode) *** *** 8567,8573 }") (define_insn "*movdi_internal64" ! [(set (match_operand:DI 0 "nonimmediate_operand" "=r,r,m,r,r,r,r,??f,f,m,r,*h,*h") (match_operand:DI 1 "input_operand" "r,m,r,I,L,nF,R,f,m,f,*h,r,0"))] "TARGET_POWERPC64 && (gpc_reg_operand (operands[0], DImode) --- 8567,8573 }") (define_insn "*movdi_internal64" ! [(set (match_operand:DI 0 "nonimmediate_operand" "=r,r,m,r,r,r,r,!*f,!*f,m,r,*h,*h") (match_operand:DI 1 "input_operand" "r,m,r,I,L,nF,R,f,m,f,*h,r,0"))] "TARGET_POWERPC64 && (gpc_reg_operand (operands[0], DImode) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18641
[Bug middle-end/18641] [4.0 Regression] Another ICE caused by reload of a psuedo reg into f0 for a DImode expr
--- Additional Comments From dje at watson dot ibm dot com 2004-12-07 03:10 --- Subject: Re: [4.0 Regression] Another ICE caused by reload of a psuedo reg into f0 for a DImode expr There are two open questions: 1) Do we want to change the register preferencing? 2) Should we need to return NO_REGS for FLOAT_MODE constant loaded into GPRs? David -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18641
