This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c/48685] [4.5/4.6/4.7 regression] ICE in gimplify_expr, at gimplify.c:7034
- From: "jakub at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Wed, 20 Apr 2011 08:09:12 +0000
- Subject: [Bug c/48685] [4.5/4.6/4.7 regression] ICE in gimplify_expr, at gimplify.c:7034
- Auto-submitted: auto-generated
- References: <bug-48685-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48685
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org,
| |jsm28 at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-04-20 08:08:27 UTC ---
int
main ()
{
int v = 1;
(void) (1 == 2 ? (void) 0 : (v = 0));
return v;
}
I believe normally c_fully_fold_internal drops NON_LVALUE_EXPRs in
STRIP_TYPE_NOPS at the end, but in this case the void type COND_EXPR is folded
into int type MODIFY_EXPR (and even a fold_convert wouldn't fix that up,
for MODIFY_EXPR it is just fold_ignored_result and still stays at the original
type) and thus the void type NON_LVALUE_EXPR is kept.
I wonder whether we should be creating NON_LVALUE_EXPRs with void type at all
(aren't void values never lvalues?), or when handling NON_LVALUE_EXPR in
c_fully_fold_internal we should drop them if they are void type.