This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug c/48685] [4.5/4.6/4.7 regression] ICE in gimplify_expr, at gimplify.c:7034


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]