Summary: | [4.5 Regression]: cris-elf gcc.dg/torture/builtin-math-3.c -O1 and -Os sincos one | ||
---|---|---|---|
Product: | gcc | Reporter: | Hans-Peter Nilsson <hp> |
Component: | tree-optimization | Assignee: | Richard Biener <rguenth> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | gcc-bugs, rguenth |
Priority: | P3 | Keywords: | missed-optimization |
Version: | 4.5.0 | ||
Target Milestone: | 4.5.0 | ||
Host: | x86_64-unknown-linux-gnu | Target: | cris-axis-elf |
Build: | Known to work: | ||
Known to fail: | Last reconfirmed: | 2009-04-06 11:14:36 | |
Attachments: | Reduced gcc.dg/torture/builtin-math-3.c |
Description
Hans-Peter Nilsson
2009-04-04 22:59:43 UTC
Subject: Re: New: [4.5 Regression]: cris-elf
gcc.dg/torture/builtin-math-3.c -O1 and -Os sincos one
On Sat, 4 Apr 2009, hp at gcc dot gnu dot org wrote:
> With revision 145488 this test passed.
> From revision 145495 and on, this test has failed as follows:
> ...
> Running /tmp/hpautotest-gcc1/gcc/gcc/testsuite/gcc.dg/torture/dg-torture.exp
> ...
> FAIL: gcc.dg/torture/builtin-math-3.c -O1 (test for excess errors)
> FAIL: gcc.dg/torture/builtin-math-3.c -Os (test for excess errors)
> ...
>
> With the message in gcc.log being:
> builtin-math-3.c:(.text+0x88): undefined reference to `_link_error'
> builtin-math-3.c:(.text+0xfe): undefined reference to `_link_error'
> builtin-math-3.c:(.text+0x174): undefined reference to `_link_error'
> builtin-math-3.c:(.text+0x1aa): undefined reference to `_link_error'
> builtin-math-3.c:(.text+0x220): undefined reference to `_link_error'
> /tmp/ccKBGOIU.o:builtin-math-3.c:(.text+0x296): more undefined references to
> `_link_error' follow
>
> The lack of line-numbers is of course unhelpful, but with "-g" added, the link
> error becomes, for both -O1 and -Os:
>
> builtin-math-3.o: In function `main':
> /tmp/hpautotest-gcc1/gcc/gcc/testsuite/gcc.dg/torture/builtin-math-3.c:176:
> undefined reference to `_link_error'
> /tmp/hpautotest-gcc1/gcc/gcc/testsuite/gcc.dg/torture/builtin-math-3.c:176:
> undefined reference to `_link_error'
> /tmp/hpautotest-gcc1/gcc/gcc/testsuite/gcc.dg/torture/builtin-math-3.c:177:
> undefined reference to `_link_error'
> /tmp/hpautotest-gcc1/gcc/gcc/testsuite/gcc.dg/torture/builtin-math-3.c:177:
> undefined reference to `_link_error'
>
> Author of patches in suspect revision range CC:ed.
Can you 1) reduce the testcase and attach preprocessed source that
works with a cross-compiler, 2) identify what goes wrong so we don't
have to analyze cris assembler?
Thanks,
Richard.
(In reply to comment #1) > Can you 1) reduce the testcase and attach preprocessed source that > works with a cross-compiler, The test-case was already self-contained and had little context-sensitiveness due to the line-oriented nature, so I didn't expect you to need this. > 2) identify what goes wrong so we don't > have to analyze cris assembler? This is a bit worrying. Surely you didn't think this would ever be needed, for a test-case where the nature of the failure is that it emits a subroutine call to link_error()? Again, the regression is a missing optimization of sincos for a soft-float target, as already mentioned in the summary and description. Anyway, one reduced test-case coming up. Created attachment 17591 [details]
Reduced gcc.dg/torture/builtin-math-3.c
The two lines causing link_error() to be called as in the linker error messages are cut out and the condition is reduced such that the emitted assembly-code is still identical. Compile with e.g. -O1. Observe libcalls for "<=" and ">=" being called for constants, while in the pre-regression code, everything is optimized out to the effect of "return 0;"
Ok, I can see at least one missed CCP optimization when looking at what the x86_64 target produces. Now building a cross to see why for cris the second CCP pass together with either FRE or DOM or the third CCP pass do not fix this. For cris-axis-elf we do not fold one_1 = 1.0e+0; oneL_2 = 1.0e+0; __builtin_sincos (1.0e+0, &s, &c); to a constant because __builtin_sincos did not get transformed to __builtin_cexpi. We fold it later via the fold-all-builtins pass but nothing promotes memory to registers after that pass with -O1. I have a patch that should fix this. Fixed. Subject: Bug 39643 Author: rguenth Date: Mon Apr 6 14:16:15 2009 New Revision: 145604 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145604 Log: 2009-04-06 Richard Guenther <rguenther@suse.de> PR tree-optimization/39643 * tree-ssa-ccp.c (ccp_fold): Fold REALPART_EXPRs and IMAGPART_EXPRs of complex constants. (execute_fold_all_builtins): If we folded a call queue TODO_update_address_taken. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-ccp.c |