On Wed, 15 Jun 2016, Jakub Jelinek wrote:
> The only thing I'm unsure about is what to do with bitfield types.
> For __builtin_{add,sub,mul}_overflow it is not an issue, as one can't take
> address of a bitfield. For __builtin_{add,sub,mul}_overflow_p right now,
> the C FE doesn't promote the last argument in any way, therefore for C
> the builtin-arith-overflow-p-19.c testcase tests the behavior of bitfield
> overflows. The C++ FE even for type-generic builtins promotes the argument
> to the underlying type (as part of decay_conversion), therefore for C++
> overflow to bit-fields doesn't work. Is that acceptable that because the
> bitfields in the two languages behave generally slightly differently it is
> ok that it differs even here, or should the C FE promote bitfields to the
> underlying type for the last argument of __builtin_{add,sub,mul}_overflow_p,
> or should the C++ FE special case __builtin_{add,sub,mul}_overflow_p and
> not decay_conversion on the last argument to these, something else?
If the idea of the built-ins it to tell whether the result of arithmetic
could be stored in a particular object, then it would seem natural not to
promote bit-fields in either language, and so enable telling whether the
result of arithmetic could be stored in a bit-field. Except that of
course the last argument is an rvalue not an lvalue, and when it's a
question of whether the result could be stored in a particular type rather
than a particular object, it's less clear that C++ shouldn't promote.
--
Joseph S. Myers
jos...@codesourcery.com
