http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55137
--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-11-08 20:16:54 UTC --- (In reply to comment #10) > (In reply to comment #3) > > If it is valid, the series of foldings that result into the overflow are > > first > > folding sizeof (int) - 1UL into sizeof (int) + 18446744073709551615UL and > > later > > on conversion of -1 + (int) (sizeof (int) + 18446744073709551615UL) to > > -1 + (int) sizeof (int) + (int) 18446744073709551615UL. > > Under C++ semantics, this folding introduces implementation-defined behavior, > not undefined behavior, so it's still a constant-expression; conversion to a > signed integer is different from overflow in the language. I have been > working > around this difference between back end and language semantics in > cxx_eval_constant_expression by unsetting TREE_OVERFLOW after folding > NOP_EXPR, > but that doesn't help this example. > > The semantics of overflow and conversion to signed integer are different in C > as well; the only difference from C++ is that C allows the implementation to > trap *or* produce an implementation-defined value. Perhaps we could > distinguish them in the compiler as well... In this case I think it is really a bug in fold-const.c, as can be seen on the miscompiled testcase there (provided it is valid C resp. C++). See http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00636.html
