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: Bug in bitfield handling?


On Sep 7, 2012, at 2:02 PM, Andrew Pinski wrote:

> On Fri, Sep 7, 2012 at 10:57 AM,  <Paul_Koning@dell.com> wrote:
>> This seems to be a bug:
>> 
>> struct bug
>> {
>>    int f1:1;
>>    unsigned long long f2:31;
>> };
>> 
>> struct bug test = { 1, 0x8000ULL };
>> 
>> int main (int c, char **v)
>> {
>>    unsigned long long tf2;
>> 
>>    tf2 = test.f2 << 16;
>>    if (tf2 == 0x80000000ULL)
>>        return 0;
>>    return 1;
>> }
>> 
>> Since the underlying type of field f2 is unsigned long long, I would not expect the expression "test.f2 << 16" to do sign extending of a 32 bit intermediate result.  But that is in fact what GCC produces, for x86_64-linux (gcc 4.7.0).
>> 
>> If I explicitly cast test.f2 to unsigned long long before the shift, the expected result appears.  But I shouldn't have to do that cast, given that the type of f2 is already unsigned long long, correct?
> 
> The type of  "test.f2" is a 31 bit unsigned integer (the declared type
> is used for alignment) and that fits in a 32bit signed integer so when
> doing test.f2 << 16, it is promoted to only an 32bit signed integer.
> 
> Thanks,
> Andrew

Ok, thanks.

GDB doesn't do things this way, so I guess I have to tell them. 

	paul


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