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: unassig...@gcc.gnu.org
ReportedBy: daniel.krueg...@googlemail.com
CC: ja...@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.
