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 target/99234] [10/11 regression] wrong result for 1.0/3.0 with -O2 -fno-omit-frame-pointer -frounding-math Date: Fri, 26 Feb 2021 10:18:39 +0000 [thread overview] Message-ID: <bug-99234-4-Vy4VI3r8X3@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-99234-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99234 --- Comment #17 from Jakub Jelinek <jakub at gcc dot gnu.org> --- (In reply to Liu Hao from comment #15) > Thanks. The 'Final fix' looks good to me. > > I applied it locally and built GCC. With a debugger, I verified that after > the try-catch statement, all non-volatile XMM registers (6-15) had been > restored properly. > > > > ``` > // x86_64-w64-mingw32-g++ -O2 -fno-omit-frame-pointer test.cc > > __attribute__((__noinline__)) void clobber_xmm6() > { > __asm__ volatile ("xorpd %%xmm6, %%xmm6" ::: "xmm6"); > throw 42; // remove this to get expected result > } > > int main() > { > static const double xmm5 = 5.123456; > static const double xmm6 = 6.123456; > static const double xmm7 = 7.123456; > static const double xmm8 = 8.123456; > static const double xmm9 = 9.123456; > static const double xmm10 = 10.123456; > static const double xmm11 = 11.123456; > static const double xmm12 = 12.123456; > static const double xmm13 = 13.123456; > static const double xmm14 = 14.123456; > static const double xmm15 = 15.123456; > __asm__ volatile ("movsd %0, %%xmm5 " :: "m"(xmm5 )); That would certainly need : "xmm5" in clobbers (etc.). And isn't really portable anyway, the compiler can choose to put anything into %xmm6 in between that and the asm before printf. But, loading the value from memory into some double temporary (with "=x" for many of them) in an asm and then e.g. just "+x" them in empty asms and then comparing values will likely reproduce it too. > __asm__ volatile ("movsd %0, %%xmm6 " :: "m"(xmm6 )); > __asm__ volatile ("movsd %0, %%xmm7 " :: "m"(xmm7 )); > __asm__ volatile ("movsd %0, %%xmm8 " :: "m"(xmm8 )); > __asm__ volatile ("movsd %0, %%xmm9 " :: "m"(xmm9 )); > __asm__ volatile ("movsd %0, %%xmm10" :: "m"(xmm10)); > __asm__ volatile ("movsd %0, %%xmm11" :: "m"(xmm11)); > __asm__ volatile ("movsd %0, %%xmm12" :: "m"(xmm12)); > __asm__ volatile ("movsd %0, %%xmm13" :: "m"(xmm13)); > __asm__ volatile ("movsd %0, %%xmm14" :: "m"(xmm14)); > __asm__ volatile ("movsd %0, %%xmm15" :: "m"(xmm15)); > > try { > clobber_xmm6(); > } > catch(...) { } > > double value; > __asm__ volatile ("movsd %%xmm6, %0" : "=x"(value)); > __builtin_printf("value = %g\n", value); // expect `123.456` You mean 6.123456 ? And in any case, I'd suggest whatever.625 or other constants which won't suffer from rounding etc.
next prev parent reply other threads:[~2021-02-26 10:18 UTC|newest] Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-02-24 1:07 [Bug c++/99234] New: Regression: wrong result for 1.0/3.0 when -fno-omit-frame-pointer -frounding-math used together vz-gcc at zeitlins dot org 2021-02-24 15:54 ` [Bug target/99234] " jakub at gcc dot gnu.org 2021-02-24 16:19 ` vz-gcc at zeitlins dot org 2021-02-24 16:19 ` vz-gcc at zeitlins dot org 2021-02-24 16:23 ` vz-gcc at zeitlins dot org 2021-02-24 16:25 ` vz-gcc at zeitlins dot org 2021-02-25 8:56 ` jakub at gcc dot gnu.org 2021-02-25 9:34 ` ebotcazou at gcc dot gnu.org 2021-02-25 9:36 ` [Bug target/99234] [10/11 regression] wrong result for 1.0/3.0 with -O2 -fno-omit-frame-pointer -frounding-math ebotcazou at gcc dot gnu.org 2021-02-25 9:36 ` ebotcazou at gcc dot gnu.org 2021-02-25 12:07 ` jyong at gcc dot gnu.org 2021-02-25 12:35 ` ebotcazou at gcc dot gnu.org 2021-02-25 14:25 ` lh_mouse at 126 dot com 2021-02-25 18:18 ` ebotcazou at gcc dot gnu.org 2021-02-26 0:36 ` ebotcazou at gcc dot gnu.org 2021-02-26 6:00 ` lh_mouse at 126 dot com 2021-02-26 8:27 ` lh_mouse at 126 dot com 2021-02-26 9:17 ` ebotcazou at gcc dot gnu.org 2021-02-26 10:18 ` jakub at gcc dot gnu.org [this message] 2021-02-26 11:04 ` lh_mouse at 126 dot com 2021-03-01 6:59 ` cvs-commit at gcc dot gnu.org 2021-03-01 7:00 ` cvs-commit at gcc dot gnu.org 2021-03-01 7:12 ` cvs-commit at gcc dot gnu.org 2021-03-01 7:13 ` ebotcazou at gcc dot gnu.org 2021-03-01 11:49 ` vz-gcc at zeitlins dot org 2021-03-03 11:30 ` cvs-commit at gcc dot gnu.org 2021-03-03 11:31 ` cvs-commit at gcc dot gnu.org 2021-03-03 11:34 ` cvs-commit at gcc dot gnu.org 2021-05-05 20:55 ` cvs-commit at gcc dot gnu.org 2021-05-05 20:56 ` cvs-commit at gcc dot gnu.org 2021-05-05 20:58 ` cvs-commit at gcc dot gnu.org 2021-05-05 21:01 ` cvs-commit 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-99234-4-Vy4VI3r8X3@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).