public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "daniel.kruegler at googlemail dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/49136] New: [C++0x][constexpr] Incorrect constexpr c'tor evaluation with bitfields Date: Tue, 24 May 2011 08:35:00 -0000 [thread overview] Message-ID: <bug-49136-4@http.gcc.gnu.org/bugzilla/> (raw) 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.
next reply other threads:[~2011-05-24 7:59 UTC|newest] Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top 2011-05-24 8:35 daniel.kruegler at googlemail dot com [this message] 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
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-49136-4@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
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).