On Thu, Oct 6, 2016 at 6:54 AM, Jonathan Wakely <jwak...@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. Jason
