This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: middle-end/7018: bitfield of type long long treated as int inshift
- From: Andreas Schwab <schwab at suse dot de>
- To: "Christian Ehrhardt" <ehrhardt at mathematik dot uni-ulm dot de>
- Cc: gcc-gnats at gcc dot gnu dot org, jbeulich at novell dot com, gcc-bugs at gcc dot gnu dot org,nobody at gcc dot gnu dot org, gcc-prs at gcc dot gnu dot org
- Date: Thu, 10 Apr 2003 16:44:20 +0200
- Subject: Re: middle-end/7018: bitfield of type long long treated as int inshift
- References: <20030410140928.27494.qmail@theseus.mathematik.uni-ulm.de>
"Christian Ehrhardt" <ehrhardt at mathematik dot uni-ulm dot 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 at suse dot 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."