[Bug c++/49136] New: [C++0x][constexpr] Incorrect constexpr c'tor evaluation with bitfields

[daniel.kruegler at googlemail dot com]

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

           Summary: [C++0x][constexpr] Incorrect constexpr c'tor
                    evaluation with bitfields
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: daniel.kruegler@googlemail.com
                CC: jason@redhat.com


gcc 4.7.0 20110521 (experimental) in C++0x mode fires a static assertion at the
line marked with #:

//----
struct day {
  unsigned d : 5;
  unsigned n : 3;
  constexpr explicit day(int dd) : d(dd), n(7) {}
};

struct date {
  int d;
  constexpr date(day dd) : d((dd.n != 7) ? 7 : dd.d) {}
};

constexpr day d(0);
constexpr date dt(d);
static_assert(dt.d == 0, "Error"); // #
//----

Further testing shows, that dt.d has the value 7 instead of 0. The error only
occurs, if the day object d is defined as constexpr variable. E.g. given the
above shown types day and date the following program

//---
extern "C" int printf(const char*, ...);

int main()
{
  constexpr day d(0);
  date dt(d);
  printf("%d\n", d.d);  // Prints 0
  printf("%d", dt.d);   // Prints 7
}
//---

still produces the calculation error. If we remove the constexpr specifier of
the local object d (or if we replace it by a const specifier), the calculation
is correct, the output is 

0
0

as expected. Interestingly, the internal value of the object d itself is always
correct. The defect seems to happen if a constexpr day object is used in
another constexpr constructor. It seems that the type date itself is required
as well, I could not replace the constexpr date constructor call by a constexpr
function like this

constexpr int date_func(day dd) { return (dd.n != 7) ? 7 : dd.d; }

to produce the same error. While trying to simplify the test case I found that
the struct day must contain at least two such bitfields.

Let me add that this problem occurred while trying to "constexpressify" an
existing date library of Howard Hinnant, so this is not just a theoretical
case.