From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id E35803851143; Mon, 12 Sep 2022 09:47:53 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E35803851143 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1662976073; bh=NEJRjs/naF0PomrjJZwYqnf58/Q5AfZc9cmK/MCC7Qg=; h=From:To:Subject:Date:In-Reply-To:References:From; b=ZF9jZT4tqrzEWLl3jsc1m2TVaFvYw9S+O9zIyNu9lNbLADBVe2M1ZLYp3EsuNWtWz X3rH9buJhWFu+06edIdCPO2dCTeGcqGzEO87Ni4GyQxf+DI55VNMMyiIogMzR2mOGU 6vgc7CWnYFDoK4RyJ2e9Bo8R3OWnNoAFo9QWhi9E= From: "fw at gcc dot 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 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 4.6.3 X-Bugzilla-Keywords: documentation X-Bugzilla-Severity: major X-Bugzilla-Who: fw at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D55522 Florian Weimer changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fw at gcc dot gnu.org --- Comment #21 from Florian Weimer --- (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 the= ory change CPU state using glibc's SETXID broadcast, but it will impact legitim= ate 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).=