[Bug target/47312] [4.6 Regression] ICE: in expand_ternary_op, at optabs.c:656 with -flto -mno-sse -mxop and __builtin_fmaf()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47312
--- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2011-02-03
10:53:21 UTC ---
Author: jakub
Date: Thu Feb 3 10:53:19 2011
New Revision: 169786
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=169786
Log:
PR target/47312
* expr.c (expand_expr_real_2) case FMA_EXPR: If target doesn't expand
fma, expand FMA_EXPR as fma{,f,l} call.
* gcc.target/i386/pr47312.c: New test.
Added:
trunk/gcc/testsuite/gcc.target/i386/pr47312.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/expr.c
trunk/gcc/testsuite/ChangeLog
[Bug target/47312] [4.6 Regression] ICE: in expand_ternary_op, at optabs.c:656 with -flto -mno-sse -mxop and __builtin_fmaf()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47312 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2011-02-03 11:00:11 UTC --- Fixed.
[Bug target/47312] [4.6 Regression] ICE: in expand_ternary_op, at optabs.c:656 with -flto -mno-sse -mxop and __builtin_fmaf()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47312 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-02-02 15:24:25 UTC --- One possibility would be to only fold __builtin_fma* into FMA_EXPR after IPA passes.
[Bug target/47312] [4.6 Regression] ICE: in expand_ternary_op, at optabs.c:656 with -flto -mno-sse -mxop and __builtin_fmaf()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47312 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-02-02 15:30:51 UTC --- (In reply to comment #2) One possibility would be to only fold __builtin_fma* into FMA_EXPR after IPA passes. Expanding FMA_EXPR as __builtin_fma (thus, a libcall) as fallback sounds safe. We probably have similar issues for other builtins (consider the generic vector lowering code for example). Thus, in expr.c only dispatch to expand_ternary_op if there is an optab available, else emit a libcall. Folding back to __builtin_fma* sounds ugly.
[Bug target/47312] [4.6 Regression] ICE: in expand_ternary_op, at optabs.c:656 with -flto -mno-sse -mxop and __builtin_fmaf()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47312
--- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2011-02-02
15:39:00 UTC ---
FMA_EXPR is created though not only just for __builtin_fma{,l,f} in the code,
but also for x * y + z when contracting. Can expansion rely that this is
happening only after IPA passes? Otherwise we could be creating fma,f,l} calls
in freestanding environments, or try create it say for __float128 where there
is no such builtin, etc.
[Bug target/47312] [4.6 Regression] ICE: in expand_ternary_op, at optabs.c:656 with -flto -mno-sse -mxop and __builtin_fmaf()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47312 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2
[Bug target/47312] [4.6 Regression] ICE: in expand_ternary_op, at optabs.c:656 with -flto -mno-sse -mxop and __builtin_fmaf()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47312 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.01.17 13:29:34 Target Milestone|--- |4.6.0 Ever Confirmed|0 |1
[Bug target/47312] [4.6 Regression] ICE: in expand_ternary_op, at optabs.c:656 with -flto -mno-sse -mxop and __builtin_fmaf()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47312 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-17 15:46:52 UTC --- With LTO, relying on FMA_EXPR being present in the IL only iff target supports it is IMHO wrong, because using slightly different options between cc1 and lto1 can result in optab_handler (fma_optab, mode) == CODE_FOR_nothing even when FMA_EXPR is present in the IL. I'd say we should expand FMA_EXPR as __builtin_fma in that case. Richi, do you agree?
