On 06/15/2016 06:16 AM, Joseph Myers wrote:
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.
I like the idea of being able to use the built-ins for this, but I think it would be confusing for them to follow subtly different rules for C than for C++. Since the value of the last argument is ignored, how about using it to specify the precision of the destination argument? (With zero meaning the type's precision, and perhaps (Type)-1 meaning the default for each language. That way the built-ins could be used both portably and also to figure out if the result would overflow a bit-field.) Martin
