[Bug c++/30277] New: bit-filed: wrong overload resolution

[Bug c++/30277] New: bit-filed: wrong overload resolution

[s__nakayama at infoseek dot jp]

test case

#include <iostream>

struct S
{
  signed long l: 32;
};

void foo(long)
{
  std::cout << "NG\n";
}

void foo(int)
{
  std::cout << "OK\n";
}

int main()
{
  S x = {1};
  foo(x.l+0);
  return 0;
}

result
$g++ a.c -o a; ./a
NG

According to ISO/IEC 14882 4.5 p3, type of `x.l+0' becomes int by integral
promotions. (in the case: int and long are 32 bits)
Therefore, foo(int) shall be called.
But GCC calls foo(long).
Revision of BUG 16376 seems incomplete.

GCC version: 4.2 20061212


-- 
           Summary: bit-filed: wrong overload resolution
           Product: gcc
           Version: 4.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: s__nakayama at infoseek dot jp


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30277

[Bug c++/30277] bit-field: wrong overload resolution

[bangerth at dealii dot org]

------- Comment #1 from bangerth at dealii dot org  2007-01-21 05:16 -------
I only have the C99 standard, and there I read in 6.3.1.1 p2 that only
those variables are promoted to int that are of smaller size.

Similarly, in 6.3.1.8, integer promotion rules are specified, and they
specify that types in binary operations are always converted to the type
with the greater range. In your case, this would be signed long. Do
you disagree with this rationale?

Best
  Wolfgang


-- 

bangerth at dealii dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bangerth at dealii dot org
             Status|UNCONFIRMED                 |WAITING


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30277

[Bug c++/30277] bit-field: wrong overload resolution

[joseph at codesourcery dot com]

------- Comment #2 from joseph at codesourcery dot com  2007-01-21 12:28 -------
Subject: Re:  bit-field: wrong overload resolution

On Sun, 21 Jan 2007, bangerth at dealii dot org wrote:

> I only have the C99 standard, and there I read in 6.3.1.1 p2 that only
> those variables are promoted to int that are of smaller size.

C and C++ handle bit-fields differently.  C99 text about bit-fields is 
irrelevant and misleading for C++.

In C++03, integral promotions for bit-fields are specified in 4.5 
[conv.prom] (note these are "can be converted", as part of a conversion 
sequence; the underlying concepts are not those of C), and before any such 
conversion a C++ bit-field has the declared type as per 9.6 [class.bit] 
rather than a special type as in C.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30277

[Bug c++/30277] bit-field: wrong overload resolution

[s__nakayama at infoseek dot jp]

------- Comment #3 from s__nakayama at infoseek dot jp  2007-01-22 18:28 -------
(In reply to comment #1)
> I only have the C99 standard, and there I read in 6.3.1.1 p2 that only
> those variables are promoted to int that are of smaller size.
> 
> Similarly, in 6.3.1.8, integer promotion rules are specified, and they
> specify that types in binary operations are always converted to the type
> with the greater range. In your case, this would be signed long. Do
> you disagree with this rationale?

C++03 4.5 p3
| An rvalue for an integral bit-field (9.6) can be converted
| to an rvalue of type int if int can represent all the values
                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| of the bit-field; otherwise, it can be converted to unsigned
  ^^^^^^^^^^^^^^^^
| int if unsigned int can represent all the values of the
| bit-field. If the bit-field is larger yet, no integral promotion
| applies to it. If the bit-field has an enumerated type, it is 
| treated as any other value of that type for promotion purposes.

32bit bit-fields and int has the same range of value.
The bit-field shall be converted to int, because int can
represent all the values of 32bit bit-fields.


-- 

s__nakayama at infoseek dot jp changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |UNCONFIRMED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30277