Re: middle-end/7018: bitfield of type long long treated as int in shift

Re: middle-end/7018: bitfield of type long long treated as int in shift

[bangerth]

Old Synopsis: incorrect bitfield handling
New Synopsis: bitfield of type long long treated as int in shift

State-Changed-From-To: open->analyzed
State-Changed-By: bangerth
State-Changed-When: Sat Mar 15 03:24:37 2003
State-Changed-Why:
    Seems like a justified case. Behavior still persists with
    present mainline.
    
    W.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=7018

Re: middle-end/7018: bitfield of type long long treated as int in shift

[Andreas Schwab]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1802 bytes --]

The following reply was made to PR middle-end/7018; it has been noted by GNATS.

From: Andreas Schwab <schwab@suse.de>
To: "Christian Ehrhardt" <ehrhardt@mathematik.uni-ulm.de>
Cc: gcc-gnats@gcc.gnu.org, jbeulich@novell.com, gcc-bugs@gcc.gnu.org,
	nobody@gcc.gnu.org, gcc-prs@gcc.gnu.org
Subject: Re: middle-end/7018: bitfield of type long long treated as int in
 shift
Date: Thu, 10 Apr 2003 16:44:20 +0200

 "Christian Ehrhardt" <ehrhardt@mathematik.uni-ulm.de> writes:
 
 |> http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=7018
 |> 
 |> This PR is about this piece of code and it complains that the bitfield
 |> is promoted to int instead of unsigned long long in the return statement:
 |> 
 |> struct s {                                               
 |> 	unsigned long long uf:1;
 |> };                                                         
 |> 
 |> unsigned long long utest(const struct s*ps) {
 |> 	    return ps->uf << 32;
 |> }
 |> 
 |> IMHO this is behaviour is correct but the standard is somewhat vague
 |> wrt. bit-fields of other types than _Bool, char and int, so I need a
 |> language lawyer to make the final decision.
 |> 
 |> The standard does state quite clearly that an unsigned int bitfield
 |> with a width less than that of int has to be promoted to int and not to
 |> unsigend int, i.e. there is no implicit conversion of the bitfield to
 |> its "container type".
 
 IMHO the integer conversion rank of this bitfield type (which has
 precision 1) is less than the rank of int, thus it is promoted to int.
 
 Andreas.
 
 -- 
 Andreas Schwab, SuSE Labs, schwab@suse.de
 SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
 Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
 "And now for something completely different."

Re: middle-end/7018: bitfield of type long long treated as int in shift

[Christian Ehrhardt]

The following reply was made to PR middle-end/7018; it has been noted by GNATS.

From: "Christian Ehrhardt" <ehrhardt@mathematik.uni-ulm.de>
To: gcc-gnats@gcc.gnu.org, jbeulich@novell.com, gcc-bugs@gcc.gnu.org,
  nobody@gcc.gnu.org, gcc-prs@gcc.gnu.org
Cc:  
Subject: Re: middle-end/7018: bitfield of type long long treated as int in shift
Date: Thu, 10 Apr 2003 16:09:28 +0200

 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=7018
 
 This PR is about this piece of code and it complains that the bitfield
 is promoted to int instead of unsigned long long in the return statement:
 
 struct s {                                               
 	unsigned long long uf:1;
 };                                                         
 
 unsigned long long utest(const struct s*ps) {
 	    return ps->uf << 32;
 }
 
 IMHO this is behaviour is correct but the standard is somewhat vague
 wrt. bit-fields of other types than _Bool, char and int, so I need a
 language lawyer to make the final decision.
 
 The standard does state quite clearly that an unsigned int bitfield
 with a width less than that of int has to be promoted to int and not to
 unsigend int, i.e. there is no implicit conversion of the bitfield to
 its "container type".
 
    regards  Christian
 
 -- 
 THAT'S ALL FOLKS!