public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/49136] New: [C++0x][constexpr] Incorrect constexpr c'tor evaluation with bitfields
@ 2011-05-24  8:35 daniel.kruegler at googlemail dot com
  2011-05-24 11:39 ` [Bug c++/49136] " jakub at gcc dot gnu.org
                   ` (7 more replies)
  0 siblings, 8 replies; 9+ messages in thread
From: daniel.kruegler at googlemail dot com @ 2011-05-24  8:35 UTC (permalink / raw)
  To: gcc-bugs

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.


^ permalink raw reply	[flat|nested] 9+ messages in thread
end of thread, other threads:[~2011-05-25  7:33 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-05-24  8:35 [Bug c++/49136] New: [C++0x][constexpr] Incorrect constexpr c'tor evaluation with bitfields daniel.kruegler at googlemail dot com
2011-05-24 11:39 ` [Bug c++/49136] " jakub at gcc dot gnu.org
2011-05-24 11:52 ` jakub at gcc dot gnu.org
2011-05-24 13:28 ` jakub at gcc dot gnu.org
2011-05-24 17:39 ` jakub at gcc dot gnu.org
2011-05-24 21:04 ` jason at gcc dot gnu.org
2011-05-25  7:30 ` jakub at gcc dot gnu.org
2011-05-25  7:33 ` jakub at gcc dot gnu.org
2011-05-25  8:09 ` jakub at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).