public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "fw at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug target/55522] -funsafe-math-optimizations is unexpectedly harmful, especially w/ -shared Date: Mon, 12 Sep 2022 09:47:52 +0000 [thread overview] Message-ID: <bug-55522-4-suy2H6wvjn@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-55522-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522 Florian Weimer <fw at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fw at gcc dot gnu.org --- Comment #21 from Florian Weimer <fw at gcc dot gnu.org> --- (In reply to Richard Biener from comment #20) > Yeah. Not sure how often dynamic objects are opened from within threads > though. We know that some shared objects call pthread_create from ELF constructors, which is enough to potentially expose the issue if the ELF constructors are ordered in certain ways. > That said, a possibility to enforce "consistency" at least would > be to save/restore the FP state around dlopen() so that shared objects > loaded not at program startup would not affect FP state at all? > The same could be done for shared objects loaded at program startup of > course. I think GCC should not automatically link crtfastmath.o with -shared. That will fix this particular issue for new shared objects, where the action-at-a-distance issue is most prominent and least desirable I think. > The other way around would eventually be to make the CTOR __tls, that > should eventually force all threads to change their FP state(?). No, all current TLS constructors run lazily when some language construct is used. There is no way to run TLS constructors at dlopen time. We can in theory change CPU state using glibc's SETXID broadcast, but it will impact legitimate uses of the control register (e.g., changes to the FP control word around a block of code that is executed in a non-default mode). These days, we'd probably use GNU property notes for something like this (although we'd likely not make it a global property in the first place, not for this).
next prev parent reply other threads:[~2022-09-12 9:47 UTC|newest] Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-11-29 0:52 [Bug c++/55522] New: " luto at mit dot edu 2012-11-29 1:49 ` [Bug c++/55522] " luto at mit dot edu 2012-11-29 8:57 ` [Bug target/55522] " rguenth at gcc dot gnu.org 2012-11-30 1:41 ` luto at mit dot edu 2015-04-28 18:23 ` orion at cora dot nwra.com 2021-10-06 1:15 ` ilya.konstantinov at gmail dot com 2022-09-06 22:40 ` foom at fuhm dot net 2022-09-06 22:55 ` pinskia at gcc dot gnu.org 2022-09-06 22:57 ` sam at gentoo dot org 2022-09-07 10:06 ` egallager at gcc dot gnu.org 2022-09-08 17:09 ` luto at kernel dot org 2022-09-09 10:32 ` rguenth at gcc dot gnu.org 2022-09-09 10:50 ` rguenth at gcc dot gnu.org 2022-09-11 15:46 ` brendandg at nyu dot edu 2022-09-12 7:01 ` rguenth at gcc dot gnu.org 2022-09-12 9:47 ` fw at gcc dot gnu.org [this message] 2022-09-14 17:03 ` brendandg at nyu dot edu 2022-10-07 9:27 ` aph at gcc dot gnu.org 2022-10-07 17:00 ` hjl.tools at gmail dot com 2022-10-10 9:17 ` fw at gcc dot gnu.org 2022-10-10 16:45 ` hjl.tools at gmail dot com 2022-10-10 16:46 ` hjl.tools at gmail dot com 2022-10-10 19:33 ` brendandg at nyu dot edu 2022-12-19 10:36 ` cvs-commit at gcc dot gnu.org 2022-12-26 1:12 ` cvs-commit at gcc dot gnu.org 2023-01-12 13:46 ` rguenth at gcc dot gnu.org 2023-01-13 3:35 ` sam at gentoo dot org 2023-01-13 7:47 ` rguenth at gcc dot gnu.org 2023-01-13 11:14 ` cvs-commit at gcc dot gnu.org 2023-01-13 11:14 ` cvs-commit at gcc dot gnu.org 2023-01-16 13:31 ` cvs-commit at gcc dot gnu.org 2023-01-18 2:46 ` cvs-commit at gcc dot gnu.org 2023-01-23 12:34 ` cvs-commit at gcc dot gnu.org 2023-01-27 3:26 ` cvs-commit at gcc dot gnu.org 2023-01-27 14:47 ` cvs-commit at gcc dot gnu.org 2023-01-27 14:47 ` cvs-commit at gcc dot gnu.org 2023-01-27 14:47 ` cvs-commit at gcc dot gnu.org 2023-01-27 14:47 ` cvs-commit at gcc dot gnu.org 2023-01-27 14:47 ` rguenth at gcc dot gnu.org 2023-04-30 3:58 ` arthur200126 at gmail dot com 2023-10-16 15:36 ` o.hlinka at gmail dot com 2023-10-17 7:08 ` rguenth 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-55522-4-suy2H6wvjn@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).