This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Rant and proposal about bitfield semantics in our IL and the C/C++ Frontend


On Jan 14, 2008, Richard Guenther <rguenther@suse.de> wrote:

> The question arises when computing the value of say long : 33 i;
> i << 16 >> 16.  Is the shift performed in long : 33 type?  Is an
> out-of-range value truncated?

If truncation makes any difference, then there must have been
overflow, which invokes undefined behavior, which means we don't need
to worry about reducing the bitfield regardless of promotion.

If you make it 'unsigned long i:33', then promotion becomes relevant.
It might still be the case that the shift is performed on the
full-width unsigned long, and then converted back to the narrower
bitfield type for the assignment.

>   i.0 = (<unnamed-unsigned:24>) i;

This triggers precisely the error described in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33887#c18

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member         http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]