with this compiler: [lucier@lambda-head lib]$ /pkgs/gcc-mainline/bin/gcc -v Using built-in specs. Target: powerpc64-unknown-linux-gnu Configured with: ../../mainline/configure --prefix=/pkgs/gcc-mainline --enable-languages=c,c++ --enable-stage1-languages=c,c++ --with-cpu=default64 Thread model: posix gcc version 4.5.0 20090825 (experimental) [trunk revision 151108] (GCC) and this command line /pkgs/gcc-mainline/libexec/gcc/powerpc64-unknown-linux-gnu/4.5.0/cc1 -fpreprocessed thread.i -quiet -mcpu=970 -m64 -O1 -Wno-unused -version -fschedule-insns -fno-math-errno -fschedule-insns2 -fno-trapping-math -fno-strict-aliasing -fwrapv -fomit-frame-pointer -fPIC -fno-common I get the following error: thread.i: In function ‘___H_make_2d_thread’: thread.i:719:1: error: insn does not satisfy its constraints: (insn 625 411 219 26 thread.i:625 (set (reg:DF 19 19) (mem:DF (plus:DI (reg:DI 22 22 [orig:197 D.3836 ] [197]) (const_int 23 [0x17])) [0 S8 A64])) 357 {*movdf_hardfloat64} (nil)) thread.i:719:1: internal compiler error: in reload_cse_simplify_operands, at postreload.c:396 I apologize in advance for the size of the test case, which I will post next.
Created attachment 18431 [details] preprocessed source file I'm not having much luck cutting this down more, sorry.
I thought Vlad's scheduling/register allocation patch here http://gcc.gnu.org/ml/gcc-patches/2009-09/msg00003.html which solves PR24319, might fix this problem, but it does not.
Can you check if this problem is a regression from 4.2+? Although ICEs are not welcomed, regression status would put more weight on the PR.
There is no ICE when compiling thread.i with gcc-4.2.4: [lucier@lambda-head ~/Desktop]$ /pkgs/gcc-4.2.4/libexec/gcc/powerpc64-unknown-linux-gnu/4.2.4/cc1 -fpreprocessed thread.i -quiet -mcpu=970 -m64 -O1 -Wno-unused -version -fschedule-insns -fno-math-errno -fschedule-insns2 -fno-trapping-math -fno-strict-aliasing -fwrapv -fomit-frame-pointer -fPIC -fno-common GNU C version 4.2.4 (powerpc64-unknown-linux-gnu) compiled by GNU C version 4.2.4. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 833ac11fd00fa57fe0c37f258e543a62 [lucier@lambda-head ~/Desktop]$ /pkgs/gcc-4.2.4/bin/gcc -v Using built-in specs. Target: powerpc64-unknown-linux-gnu Configured with: ../../gcc-4.2.4/configure --enable-languages=c --prefix=/pkgs/gcc-4.2.4 --enable-checking=release Thread model: posix gcc version 4.2.4
No ICE with 4.3.3, either, but there is an ICE with Target: ppc64-redhat-linux gcc version 4.4.1 20090725 (Red Hat 4.4.1-2) (GCC)
Confirmed, regression.
Created attachment 18748 [details] pr41176.i Smaller testcase for 4.4 branch. ICEs with -m64 -O1 -fschedule-insns -fwrapv.
This is on (set (reg:DF X) (mem:DF ((plus:DI (reg:DI Y) (const_int 3)))). When X is still a pseudo, this is considered valid, as lfd accept any offset, but when RA chooses to assign X to a GPR register, the address doesn't match the Y constraint in movdf_hardfloat64. Is this a bug in reload that it doesn't attempt to force the address into a register, or in target description that it should tell reload to do so somehow? Or does the backend need to be able to handle these, perhaps by forcing splitting of it? ld X,disp(Y) for (disp & 3) != 0 could be splitted into addi X,Y,disp;ld X,0(X), for std X,disp(Y), (disp & 3) != 0 if X != Y perhaps addi Y,Y,disp;std X,0(Y);adddi Y,Y,-disp but for std X,disp(Y) I have no idea if there are no scratch regs available.
(In reply to comment #8) > This is on (set (reg:DF X) (mem:DF ((plus:DI (reg:DI Y) (const_int 3)))). > When X is still a pseudo, this is considered valid, as lfd accept any offset, > but when RA chooses to assign X to a GPR register, the address doesn't match > the Y constraint in movdf_hardfloat64. Is this a bug in reload that it doesn't > attempt to force the address into a register, or in target description that it > should tell reload to do so somehow? Or does the backend need to be able to > handle these, perhaps by forcing splitting of it? If reload were fixing up this insn, it would indeed have to make sure that the Y -> r constraints are respected, e.g. by reloading the address. However, this whole insn is *generated* by reload, in order to load a value into a reload register. Unfortunately, for such reload insns (which are simple moves), reload will simply assume they must be supported by the target, unless there is a secondary reload for this case. To fix this, I guess the rs6000 backend either has to accept the insn and implement it via splitting, or else register a secondary reload for this case (which is also able to request scratch registers).
The original testcase still ICEs, just not the reduced testcase. On the trunk, the original testcase has: (insn 218 217 219 26 t.c:624 (set (reg/v:DF 203 [ ___F64V2 ]) (mem:DF (plus:DI (reg:DI 197 [ D.2974 ]) (const_int 39 [0x27])) [0 S8 A64])) 345 {*movdf_hardfloat64} (nil)) Before ra. After reload we have: (insn 624 217 218 26 t.c:624 (set (reg:DF 21 21) (mem:DF (plus:DI (reg:DI 22 22 [orig:197 D.2974 ] [197]) (const_int 39 [0x27])) [0 S8 A64])) 345 {*movdf_hardfloat64} (nil)) I don't see where reload is creating the whole instruction; maybe I am misunderstanding that statement.
(In reply to comment #10) > I don't see where reload is creating the whole instruction; maybe I am > misunderstanding that statement. Well, after reload you have insn 624, which presumably didn't exist before. This was inserted by reload before the (original) insn 218 -- you didn't show the fixed-up version of insn 218 after reload, but I'm assuming it's probably a register-to-register (or -to-memory) move from the reload register (reg:DF 21) into whatever the register allocator has chosen to hold (reg/v:DF 203). The new insn 624 is not in any way a "fixed up" version of insn 218. Instead, it is a reload insn that was generated by reload to load some value (in this case the (mem:DF ...)) into some reload register. (That this happens to look similar to insn 218 before reload is just a coincidence.) As I mentioned, reload by default assumes that any move of any legitimate operand into any register is always valid and can by performed by a simple set.
4.4 branch is being closed, moving to 4.5.4 target.
The 4.5 branch is being closed, adjusting target milestone.
Cannot reproduce with the test case of comment #0, with trunk r194705. Brad, do you still see this failure?
I can't build today's mainline: libtool: compile: /homes/lucier/programs/gcc/objdirs/mainline/./gcc/xgcc -shared-libgcc -B/homes/lucier/programs/gcc/objdirs/mainline/./gcc -nostdinc++ -L/homes/lucier/programs/gcc/objdirs/mainline/powerpc-apple-darwin9.8.0/libstdc++-v3/src -L/homes/lucier/programs/gcc/objdirs/mainline/powerpc-apple-darwin9.8.0/libstdc++-v3/src/.libs -B/homes/lucier/pkgs/gcc-mainline/powerpc-apple-darwin9.8.0/bin/ -B/homes/lucier/pkgs/gcc-mainline/powerpc-apple-darwin9.8.0/lib/ -isystem /homes/lucier/pkgs/gcc-mainline/powerpc-apple-darwin9.8.0/include -isystem /homes/lucier/pkgs/gcc-mainline/powerpc-apple-darwin9.8.0/sys-include -I/homes/lucier/programs/gcc/mainline/libstdc++-v3/../libgcc -I/homes/lucier/programs/gcc/objdirs/mainline/powerpc-apple-darwin9.8.0/libstdc++-v3/include/powerpc-apple-darwin9.8.0 -I/homes/lucier/programs/gcc/objdirs/mainline/powerpc-apple-darwin9.8.0/libstdc++-v3/include -I/homes/lucier/programs/gcc/mainline/libstdc++-v3/libsupc++ -D_GLIBCXX_SHARED -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=array_type_info.lo -g -O2 -c ../../../../../mainline/libstdc++-v3/libsupc++/array_type_info.cc -fno-common -DPIC -D_GLIBCXX_SHARED -o array_type_info.o ../../../../../mainline/libstdc++-v3/libsupc++/array_type_info.cc: In destructor 'virtual __cxxabiv1::__array_type_info::~__array_type_info()': ../../../../../mainline/libstdc++-v3/libsupc++/array_type_info.cc:33:1: internal compiler error: Bus error } ^ Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. make[5]: *** [array_type_info.lo] Error 1 make[4]: *** [all-recursive] Error 1 make[3]: *** [all] Error 2 make[2]: *** [all-stage1-target-libstdc++-v3] Error 2 make[1]: *** [stage1-bubble] Error 2 make: *** [bootstrap] Error 2 godel-214% uname -a Darwin godel.math.purdue.edu 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:57:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_PPC Power Macintosh godel-215% gcc -v Using built-in specs. Target: powerpc-apple-darwin9 Configured with: /var/tmp/gcc/gcc-5465~16/src/configure --disable-checking -enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib --build=i686-apple-darwin9 --program-prefix= --host=powerpc-apple-darwin9 --target=powerpc-apple-darwin9 Thread model: posix gcc version 4.0.1 (Apple Inc. build 5465) Configured with ../../mainline/configure --enable-languages=c,c++ I forget how to find out what the svn revision is, but this is the last entry in the Changelog: 2013-01-07 Georg-Johann Lay <avr@gjlay.de> PR target/55897 * doc/extend.texi (AVR Named Address Spaces): __memx goes into .progmemx.data now. I seem to have limited ability to change the status of this bug report from WAITING to something reasonable. Brad
GCC 4.6.4 has been released and the branch has been closed.
I tried both testcases with the trunk using the options in the initial report as well as c#7. I'm going to assume this was ultimately fixed in one way or another.