The new testcase gcc.c-torture/execute/va-arg-trap-1.c ICEs on powerpc-apple-darwin9 when compiled with -O2 or -Os. The failure is... Executing on host: /sw/src/fink.build/gcc44-4.3.999-20090219/darwin_objdir/gcc/xgcc -B/sw/src/fink.build/gcc44-4.3.999-20090219/darwin_objdir/gcc/ /sw/src/fink.build/gcc44-4.3.999-20090219/gcc-4.4-20090219/gcc/testsuite/gcc.c-torture/execute/va-arg-trap-1.c -w -O2 -lm -o /sw/src/fink.build/gcc44-4.3.999-20090219/darwin_objdir/gcc/testsuite/gcc/va-arg-trap-1.x2 (timeout = 300) /sw/src/fink.build/gcc44-4.3.999-20090219/gcc-4.4-20090219/gcc/testsuite/gcc.c-torture/execute/va-arg-trap-1.c: In function 'bar': /sw/src/fink.build/gcc44-4.3.999-20090219/gcc-4.4-20090219/gcc/testsuite/gcc.c-torture/execute/va-arg-trap-1.c:29: internal compiler error: in move_insn, at haifa-sched.c:1934 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. compiler exited with status 1 output is: /sw/src/fink.build/gcc44-4.3.999-20090219/gcc-4.4-20090219/gcc/testsuite/gcc.c-torture/execute/va-arg-trap-1.c: In function 'bar': /sw/src/fink.build/gcc44-4.3.999-20090219/gcc-4.4-20090219/gcc/testsuite/gcc.c-torture/execute/va-arg-trap-1.c:29: internal compiler error: in move_insn, at haifa-sched.c:1934 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. FAIL: gcc.c-torture/execute/va-arg-trap-1.c compilation, -O2 (internal compiler error) This failure is also occurring on powerpc-ibm-aix5.3.0.0... http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg01950.html
Most likely the __builtin_trap is being turned into a conditional trap which is confusing the scheduler.
Subject: Re: New: gcc.c-torture/execute/va-arg-trap-1.c ICEs on powerpc-apple-darwin9 Does that testcase ICE with a compiler from before the patch that added it? If not, does the builtins.c change I suggested on the gcc list for one possible issue with that patch help?
Yes, from gcc trunk on 20090120, I see... /sw/src/fink.build/gcc44-4.3.999-20090120/darwin_objdir/gcc/xgcc -B/sw/src/fink.build/gcc44-4.3.999-20090120/darwin_objdir/gcc/ ./va-arg-trap-1.c -w -O2 -lm -o ./va-arg-trap-1.x2 ./va-arg-trap-1.c: In function 'bar': ./va-arg-trap-1.c:29: internal compiler error: in move_insn, at haifa-sched.c:1934 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. on powerpc-apple-darwin9.
> Does that testcase ICE with a compiler from before the patch that added it? On powerpc-apple-darwin I see the ICE with gcc at revision 144290 (the test comes in revision 144296).
Subject: Re: gcc.c-torture/execute/va-arg-trap-1.c ICEs on powerpc-apple-darwin9 On Sat, 21 Feb 2009, dominiq at lps dot ens dot fr wrote: > ------- Comment #4 from dominiq at lps dot ens dot fr 2009-02-21 00:59 ------- > > Does that testcase ICE with a compiler from before the patch that added it? > > On powerpc-apple-darwin I see the ICE with gcc at revision 144290 (the test > comes in revision 144296). Thanks. So this isn't a regression from my patch, and I don't have anything to suggest about possible causes or fixes in that case.
On powerpc-apple-darwin9 gcc-4.3.3 gives almost the same ICE: /opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/execute/va-arg-trap-1.c: In function 'bar': /opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/execute/va-arg-trap-1.c:27: warning: 'float' is promoted to 'double' when passed through '...' /opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/execute/va-arg-trap-1.c:27: note: (so you should pass 'double' not 'float' to 'va_arg') /opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/execute/va-arg-trap-1.c:27: note: if this code is reached, the program will abort /opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/execute/va-arg-trap-1.c:29: internal compiler error: in move_insn, at haifa-sched.c:1786 while gcc-4.2.1 (Apple) gives: /opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/execute/va-arg-trap-1.c: In function 'bar': /opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/execute/va-arg-trap-1.c:27: warning: 'float' is promoted to 'double' when passed through '...' /opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/execute/va-arg-trap-1.c:27: warning: (so you should pass 'double' not 'float' to 'va_arg') /opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/execute/va-arg-trap-1.c:27: note: if this code is reached, the program will abort /opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/execute/va-arg-trap-1.c:29: internal compiler error: Bus error
On powerpc-apple-darwin9 the test fails with -m64 as well as -m32 (default).
This also ICEs on powerpc64-linux. The testsuite fail from this is a regression.
comment #6 suggests that it is at least a regression *from 4.2 to 4.3*?
I appears the haifa scheduler doesn't know what to do with the lone use of (symbol_ref "ap") so it ends up clogging the end of a basic block. Mike, as far as I can tell, you originally (in 1997) added the code to rs6000.md which is now in rs6000.c:rs6000_emit_move and emits a USE for SYMBOL_REFS that are the source of a move. (Search for "Emit a USE operation"). What is wrong with deleting constants that are not used?
(In reply to comment #10) > Mike, as far as I can tell, you originally (in 1997) added the code to > rs6000.md which is now in rs6000.c:rs6000_emit_move and emits a USE > for SYMBOL_REFS that are the source of a move. (Search for > "Emit a USE operation"). I have tried to #ifdef 0 this code in rs6000_emit_move, and a regression test on gcc40 (powerpc64-unknown-linux-gnu) shows only two differences, i.e. FAIL: gcc.c-torture/execute/va-arg-trap-1.c compilation, -O2 (internal compile r error) FAIL: gcc.c-torture/execute/va-arg-trap-1.c compilation, -Os (internal compile r error) from the baseline went away. I've used revision 144485 for my baseline, and after determining that a standard bootstrap did not work (probably a 32/64 bit ABI problem, I didn't think it was worth the trouble to hand-bootstrap to 64 bit considering this is probably not the OS we really need testing) I built / tested with: ( make all-gcc all-target-libgcc all-target-libobjc all-target-libstdc++-v3 all-target-libgfortran;make check) > make.out 2>&1 & baseline summaries: === gcc Summary === # of expected passes 52951 # of unexpected failures 23 # of expected failures 204 # of unresolved testcases 2 # of unsupported tests 615 === g++ Summary === # of expected passes 19046 # of expected failures 140 # of unsupported tests 133 === gfortran Summary === # of expected passes 29054 # of expected failures 11 # of unsupported tests 183 === libstdc++ Summary === # of expected passes 5828 # of unexpected failures 1 # of unexpected successes 4 # of expected failures 80 # of unsupported tests 333 Patched summary: === gcc Summary === # of expected passes 52955 # of unexpected failures 21 # of expected failures 204 # of unsupported tests 615 ; identical as baseline above for the other testsuites. I think this should be tested on a power or powerpc AIX target.
I tested this patch, which I assume is what was described in comment #11: Index: gcc/config/rs6000/rs6000.c =================================================================== --- gcc/config/rs6000/rs6000.c (revision 144923) +++ gcc/config/rs6000/rs6000.c (working copy) @@ -5206,15 +5206,6 @@ rs6000_emit_move (rtx dest, rtx source, && ! legitimate_constant_pool_address_p (operands[1]) && ! toc_relative_expr_p (operands[1])) { - /* Emit a USE operation so that the constant isn't deleted if - expensive optimizations are turned on because nobody - references it. This should only be done for operands that - contain SYMBOL_REFs with CONSTANT_POOL_ADDRESS_P set. - This should not be done for operands that contain LABEL_REFs. - For now, we just handle the obvious case. */ - if (GET_CODE (operands[1]) != LABEL_REF) - emit_use (operands[1]); - #if TARGET_MACHO /* Darwin uses a special PIC legitimizer. */ if (DEFAULT_ABI == ABI_DARWIN && MACHOPIC_INDIRECT) I bootstrapped all languages except Ada on powerpc64-unknown-linux-gnu and ran the testsuite with -m32/-m64, and the only change was that test va-arg-trap-1 now passes.
I submitted Joern's patch in http://gcc.gnu.org/ml/gcc-patches/2009-04/msg00198.html but it wasn't reviewed. The test still ICEs on trunk and 4.4 branch.
This patch also fixes the gcc.c-torture/compile/pr34688.c failures. RTL-PRE finds RTL with deep LABEL_REFs. When it creates a move, the emit_use and the REG_NOTE on the move itself share RTL. I suspect we need to apply the patch and deal with the fall-out separately.
The problem was due to USEs of SYMBOL_REFs that were emitted by the target code.
Subject: Bug 39254 Author: amylaar Date: Wed Jun 17 04:27:29 2009 New Revision: 148568 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148568 Log: PR target/39254 * config/rs6000/rs6000.c (rs6000_emit_move): Don't emit a USE for the symbol ref of a constant that is the source of a move - nor for any other not-obvious-label-ref constants. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c
I have applied the patch to the trunk. Should I apply it to the 4.4 release branch as well?
Subject: Re: [4.4 Regression] gcc.c-torture/execute/va-arg-trap-1.c ICEs on powerpc-apple-darwin9 On Wed, 17 Jun 2009, amylaar at gcc dot gnu dot org wrote: > ------- Comment #17 from amylaar at gcc dot gnu dot org 2009-06-17 04:37 ------- > I have applied the patch to the trunk. Should I apply it to the 4.4 release > branch as well? Yes please, if it bootstraps & tests there. Richard.
*** Bug 43470 has been marked as a duplicate of this bug. ***
*** Bug 43500 has been marked as a duplicate of this bug. ***
As noted in duplicate PR43500, I am able to reproduce this error on plain powerpc-unknown-linux-gnu when adding -fPIC. I can run tests for the 4.4. branch but it will take several days to get a baseline result vs a patch one given extra -fPIC runs. If it passes I'll apply the patch to 4.4 per Richard's approval in comment#18.
> As noted in duplicate PR43500, I am able to reproduce this error on plain > powerpc-unknown-linux-gnu when adding -fPIC. I can run tests for the 4.4. > branch but it will take several days to get a baseline result vs a patch one > given extra -fPIC runs. If it passes I'll apply the patch to 4.4 per Richard's > approval in comment#18. I have applied the patch on powerpc-apple-darwin9 gcc-4_4-branch revision 157642. It bootstrapped for languages gcc and fortran. I am currently regtesting.
The result of regression testing for gcc and gfortran with the patch committed on trunk at revision 148568 posted at http://gcc.gnu.org/ml/gcc-testresults/2010-03/msg02071.html.
The result of regression testing for all languages but ADA on powerpc-apple-darwin9 with -m32 and -m64 with the patch committed on trunk at revision 148568 posted at http://gcc.gnu.org/ml/gcc-testresults/2010-03/msg02248.html .
Subject: Bug 39254 Author: ghazi Date: Sat Mar 27 18:56:08 2010 New Revision: 157780 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157780 Log: Backport: 2009-06-16 J"orn Rennecke <joern.rennecke@arc.com> Janis Johnson <janis187@us.ibm.com> PR target/39254 * config/rs6000/rs6000.c (rs6000_emit_move): Don't emit a USE for the symbol ref of a constant that is the source of a move - nor for any other not-obvious-label-ref constants. Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/config/rs6000/rs6000.c
Completed full bootstrap and testsuite on powerpc-unknown-linux-gnu with extra -fpic/-fPIC passes. The only difference was that the testcase va-arg-trap-1.c was fixed. Installed on 4.4 branch.
This fix is causing PR44169 on powerpc-linux-gnuspe, the second TLS load is missing a lwz. The same testcase on powerpc-linux-gnu has no problems. The gnuspe target has (as far as I figured out) just different pre-defines. Switching them off (-mabi=nospe -mno=spe) makes the problem not go away. Changing the CPU does. I reverted this change and I pass the testcase from PR44169.
*** Bug 38886 has been marked as a duplicate of this bug. ***