Most of the struct-layout-1 tests started failing on powerpc64-unknown-linux-gnu with this patch: http://gcc.gnu.org/viewcvs?view=rev&rev=146817 r146817 | matz | 2009-04-26 19:35:04 +0000 (Sun, 26 Apr 2009) Here's a minimized testcase that demonstrates the failure: struct S301 { _Decimal32 b[5]; } s301; int checkx301 (struct S301 arg) { return (arg.b[0] != s301.b[0]); } Compiling with default options, including with a powerpc-linux cross cc1, results in: t002.c: In function ‘checkx301’: t002.c:9: internal compiler error: in rs6000_secondary_memory_needed_rtx, at config/rs6000/rs6000.c:11520 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. This could be an existing backend problem exposed by the patch.
I tested powerpc64-linux a few minutes ago (r146824) and it doesn't show these errors. I have Andreas Krebbels patch applied, though, and it might really make a difference. See http://gcc.gnu.org/ml/gcc-patches/2009-04/msg02252.html . Can you check?
The patch from Andreas doesn't make a difference for the struct-layout-1 tests. Here are test results from earlier today: http://gcc.gnu.org/ml/gcc-testresults/2009-04/msg03009.html There are lots of regressions in the last few days but I haven't yet identified the causes of the others. You can see my configure options at the end of the results message.
Michael, did you configure with --enable-decimal-float? I can never remember whether that is enabled by default for powerpc64-linux or not.
I didn't enable it explicitely, but Janis neither (according to the testresults post), so it's probably default. But I did not use some other options, in particular the --with-cpu=default32, so I'm rechecking with Janis' ones.
Pff, I still can't reproduce the testsuite failures, but I can reproduce the ICE on the testcase from the initial comment. rs6000.c needs to handle SSA_NAMEs now. I'm currently regstrapping this: Index: config/rs6000/rs6000.c =================================================================== --- config/rs6000/rs6000.c (revision 146824) +++ config/rs6000/rs6000.c (working copy) @@ -11545,6 +11545,7 @@ rs6000_check_sdmode (tree *tp, int *walk case PARM_DECL: case FIELD_DECL: case RESULT_DECL: + case SSA_NAME: case REAL_CST: case INDIRECT_REF: case ALIGN_INDIRECT_REF:
(In reply to comment #5) > Pff, I still can't reproduce the testsuite failures, but I can reproduce the > ICE on the testcase from the initial comment. rs6000.c needs to handle > SSA_NAMEs now. I'm currently regstrapping this: See PR 39952 on why you didn't see it on Linux.
Decimal float is enabled by default for powerpc*-*-linux*. With the patch in comment #5 the ICE disappears but every struct-layout-1 test fails at execution time. With the patch referenced in comment #5, there are execution failures in the struct-layout-1 tests that aren't there without that patch, and it doesn't affect the ICEs. I didn't do complete testing of either patch, just a few tests that currently fail on trunk. Other tests that started failing on powerpc64*-*-linux* with r146817 and still fail with r146981: gcc.c-torture/execute/20030916-1.c execution, -O[12s] gcc.c-torture/execute/va-arg-22.c execution, -O3 * gcc.target/powerpc/20050603-3.c scan-assembler-not inm (-m32) gcc.target/powerpc/405-dlmzb-strlen-1.c scan-assembler dlmzb\\\\. (-m32) gcc.target/powerpc/440-dlmzb-strlen-1.c scan-assembler dlmzb\\\\. (-m32)
The patch from comment #1 had one peculiar bug, which could explain some miscompilations. I just committed a corrected version as r146982 and for me the struct-layout tests don't fail anymore. OTOH they weren't failing on me before that either, so I'm not sure how significant that is. I do see some of the other FAILs, but not the execution failures. Can you recheck the above svn revision for the testcases in question?
The struct-layout-1 tests all pass on powerpc64-linux (-m32/-m64) with revision 146982 plus the patch from comment #5.
I forgot to mention in the previous comment that on powerpc64-linux (-m32/-m64) with revision 146982 plus the patch from comment #5, the torture tests mentioned in comment #7 now pass but the powerpc tests still fail for -m32.
The compiler I configured on a powerpc64 host with the options you use doesn't exhibit the execute.exp fails from comment #7 for me. Neither with unix/-m32 nor with unix/-m64 . When I configure a compiler for a powerpc host with the same configure options (same machine but in a 32bit changeroot and personality) I also don't get these fails. Do you use some other options for the powerpc host than for the powerpc64 host (I didn't find any powerpc-* testresults posts from you to verify)? I see fails of e.g. 20030916-1.c in other testresults posts that exhibit a powerpc host, but this is always darwin it seems, e.g. http://gcc.gnu.org/ml/gcc-testresults/2009-04/msg03083.html . Do you mean that? I don't have a darwin host unfortunately.
In comment #10 I meant that the tests in gcc.c-torture/execute now pass for powerpc64-linux with -m32 and -m64, and that the 3 tests in gcc.target/powerpc listed in comment #7 still fail for powerpc64-linux with -m32; sorry for the confusion.
Subject: Bug 39955 Author: meissner Date: Thu Apr 30 21:59:49 2009 New Revision: 147021 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147021 Log: fix for PR 39955 Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c
Janis, is this still an issue?
The struct-layout-1 failures were fixed by the patch from Michael Matz, which Michael Meissner checked in as r147021. The new failures in gcc.target/powerpc still exist and, as far as I know, haven't yet been investigated. The struct-layout-1 failures didn't show up with GCC built as a 64-bit executable because of the bug reported in PR39986, which caused dfp tests to be used as compile-only and skipped using decimal float types in the struct-layout-1 compat tests.
I see that in your reports only gcc.target/powerpc/405-dlmzb-strlen-1.c scan-assembler dlmzb\\\\. (-m32) gcc.target/powerpc/440-dlmzb-strlen-1.c scan-assembler dlmzb\\\\. (-m32) are left (and I myself also can't reproduce the former fail in gcc.target/powerpc/20050603-3.c anymore). I've analyzed these now, and opened PR40060 for them. It's a deficiency in the frontend that looses alignment info. That deficiency was worked around in this specific case by TER, but now isn't anymore. I believe the fallout is fixed now on powerpc, as far as the middle end is concerned.
It looks like this bug is fixed. Please re-open if struct-layout-1 tests still fail.