public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/58192] G++ emits incorrect code when passing enum classes as function parameters Date: Mon, 19 Aug 2013 18:09:00 -0000 [thread overview] Message-ID: <bug-58192-4-lawspsNUpX@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-58192-4@http.gcc.gnu.org/bugzilla/> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58192 Jakub Jelinek <jakub at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jakub at gcc dot gnu.org, | |rth at gcc dot gnu.org --- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> --- The difference is that in the S1::<anon struct>::set(Foo) case setup_incoming_promotions in combine.c says that the argument has non-zero mask of 0xff, because the function is local to the TU, while for S2 all caller's aren't guaranteed local and thus it isn't optimized. The argument type is Foo (QImode) passed in SImode register, guess combine.c expects that caller zero-extends in this case, but it doesn't (in neither case). enum class Foo : unsigned char { FOO }; struct S1 { struct { unsigned int i; void __attribute__((noinline)) set (Foo foo) { i = static_cast<unsigned int> (foo); } } x; }; struct S2 { struct X { unsigned int i; void __attribute__((noinline)) set (Foo foo) { i = static_cast<unsigned int> (foo); } }; X x; }; struct T { unsigned short i; Foo f; unsigned char c; }; __attribute__((noinline)) void baz (unsigned int x) { if (x != 0) __builtin_abort (); } void bar (T t) { S1 s1; s1.x.set(t.f); baz (s1.x.i); S2 s2; s2.x.set(t.f); baz (s2.x.i); } int main() { T t = { 0xabcd, Foo::FOO, 0xef}; bar (t); } For: unsigned int v1, v2; __attribute__((noinline, noclone)) static void foo (unsigned char a) { v1 = a; } __attribute__((noinline, noclone)) void bar (unsigned char a) { v2 = a; } void baz (unsigned int a) { foo (a); bar (a); } the situation is similar for foo/bar (foo optimizes and doesn't zero extend from 8 to 32 bits, bar doesn't), but the caller in this case always zero extends.
next prev parent reply other threads:[~2013-08-19 18:09 UTC|newest] Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-08-19 6:27 [Bug c++/58192] New: " temporal at gmail dot com 2013-08-19 6:29 ` [Bug c++/58192] " temporal at gmail dot com 2013-08-19 6:38 ` temporal at gmail dot com 2013-08-19 16:49 ` temporal at gmail dot com 2013-08-19 16:59 ` paolo.carlini at oracle dot com 2013-08-19 18:09 ` jakub at gcc dot gnu.org [this message] 2014-09-18 9:20 ` paolo.carlini at oracle dot com 2014-09-18 10:01 ` jakub at gcc dot gnu.org 2014-09-19 12:10 ` ubizjak at gmail dot com 2014-09-19 13:07 ` ubizjak at gmail dot com 2014-09-19 14:10 ` jakub at gcc dot gnu.org 2014-12-15 14:30 ` ubizjak at gmail dot com 2014-12-15 14:55 ` hjl.tools at gmail dot com 2014-12-15 16:01 ` hjl.tools at gmail dot com
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-58192-4-lawspsNUpX@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).