This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug target/47197] ICE in gimplify_expr, at gimplify.c:7153 on AltiVec code (vec_dst)
- From: "wschmidt at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Wed, 18 Apr 2012 23:52:41 +0000
- Subject: [Bug target/47197] ICE in gimplify_expr, at gimplify.c:7153 on AltiVec code (vec_dst)
- Auto-submitted: auto-generated
- References: <bug-47197-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47197
William J. Schmidt <wschmidt at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2012-04-18
CC| |jsm28 at gcc dot gnu.org,
| |wschmidt at gcc dot gnu.org
Ever Confirmed|0 |1
--- Comment #1 from William J. Schmidt <wschmidt at gcc dot gnu.org> 2012-04-18 23:52:41 UTC ---
Confirmed. The ICE occurs when an unexpected tree code (C_MAYBE_CONST_EXPR) is
encountered during gimplification. From what I can tell, this should have been
scrubbed out during parsing but wasn't. The offending call to gimplify_expr ()
has the following in *expr_p:
<c_maybe_const_expr 0xfffb5e99420
type <integer_type 0xfffb5d40690 unsigned int public unsigned SI
size <integer_cst 0xfffb5c52660 constant 32>
unit size <integer_cst 0xfffb5c52680 constant 4>
align 32 symtab 0 alias set -1 canonical type 0xfffb5d40690 precision
32 min <integer_cst 0xfffb5c526a0 0> max <integer_cst 0xfffb5c52640 4294967295>
pointer_to_this <pointer_type 0xfffb5d43bb8>>
arg 1 <parm_decl 0xfffb5c804c8 len type <integer_type 0xfffb5d40690
unsigned int>
used unsigned SI file pr47197.c line 3 col 40 size <integer_cst
0xfffb5c52660 32> unit size <integer_cst 0xfffb5c52680 4>
align 32 context <function_decl 0xfffb5e39d00 func> arg-type
<integer_type 0xfffb5d40690 unsigned int>>>
The problem disappears if I change the call to __builtin_vec_dst into a normal
function call, or if I pre-compute the cond-expr rather than computing it
within the argument list.
Joseph, could you please take a look? Or let me know if you think it's not a
front end problem.
Thanks,
Bill