[C++ PATCH] P0258R2 - add __has_unique_object_representations

Jason Merrill jason@redhat.com
Thu Oct 6 12:46:00 GMT 2016

On Thu, Oct 6, 2016 at 6:54 AM, Jonathan Wakely <jwakely@redhat.com> wrote:
> On 06/10/16 12:15 +0200, Jakub Jelinek wrote:
>> On Thu, Oct 06, 2016 at 11:05:19AM +0100, Jonathan Wakely wrote:
>>> >I would think that we want the same answer for bool and enums: Either
>>> >the whole type size participates in the value representation, but only
>>> >certain values have defined behavior (so we should return true), or
>>> >only certain bits participate in the value representation (so we
>>> >should return false).  This is a question for the committee, but I'm
>>> >inclined to use the INTEGER_TYPE code for BOOLEAN_TYPE and
>>> >ENUMERAL_TYPE as well, since we don't mask off the other bits when
>>> >loading one of these types.
>>> Yes, my new, slightly improved understanding is that if the front-end
>>> always did a mask operation when accessing enumeration types and bool
>>> then the bits outside its valid range of values would be padding. They
>>> would not contribute to its value if set to non-zero values e.g.  by
>>> memset. But since we just load those values without masking, and rely
>>> on a well-defined program not to set bits outside the valid range, we
>>> should return true for those types.
>> And if bool is always implemented as load of byte and comparison against 0,
>> then the other bits wouldn't be padding, they would participate in the
>> value, but it would mean the representation of true is not unique.
>> But as we do sometimes comparison, sometimes masking and sometimes neither,
>> the behavior with values other than 0/1 is really not well defined, they
>> just shouldn't appear in valid programs.
>> So, shall I just return true for INTEGER_TYPE/BOOLEAN_TYPE/ENUMERAL_TYPE
>> as well as POINTER_TYPE/REFERENCE_TYPE, and if some target needs something
>> different, add (later on if the need arises or right away?) a target hook
>> where target can override.
> That makes sense to me.

And to me.


More information about the Gcc-patches mailing list