From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 80A263857011; Mon, 12 Sep 2022 07:01:34 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 80A263857011 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1662966094; bh=LX4TzN3LDTwiHdzuQL4HWDoV1OXoa4p8HSGsR3j9DCA=; h=From:To:Subject:Date:In-Reply-To:References:From; b=WiF3iRpn9ahEyRYQzv4JM1rcFT5ipX1v6XrSIMz2baGjFIZNmqr6LzYECkk+E29np juJc9EPbXos0arJi5SBQpiJUN0qAphe5WnjATHvnca9pyxkwgqU0VDyR2KjES7j6UN HSQzWdS6c5Pdb5qdOO7o1zWV9wv8CiVEgTw60/2g= From: "rguenth 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 07:01:33 +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: rguenth 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 Richard Biener changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fweimer at redhat dot com --- Comment #20 from Richard Biener --- (In reply to Brendan Dolan-Gavitt from comment #19) > I read through the crtfastmath.c implementations for the other affected > targets and confirmed that they do all set flush-to-zero in this thread: >=20 > https://threadreaderapp.com/thread/1567612053363347461.html >=20 > I agree that there should be a way for a shared library to link > crtfastmath.o if it wants that behavior. But is there a reason > -l:crtfastmath.o isn't sufficient in that case? Why does it need to be > enabled automatically when -Ofast/-ffast-math/-funsafe-math optimizations > are turned on? The reasons for most of the "globbing" into -ffast-math/-Ofast are the rules for SPEC CPU 2006 base flags which IIRC limited the number of flags allowed (that's no longer a requirement for SPEC CPU 2017). And of course that users will not know of the flags but are likely not interested in denormals when using -ffast-math. > The other note I would add is that in multi-threaded applications, > crtfastmath.o is already not behaving as intended: FTZ/DAZ will only be s= et > in the CPU state of the thread that loaded the shared library; it's hard = to > imagine a case where a user wants individual threads to have different > FTZ/DAZ (unless they explicitly manage that by hand). Example: [...] Yeah. Not sure how often dynamic objects are opened from within threads though. 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. The other way around would eventually be to make the CTOR __tls, that should eventually force all threads to change their FP state(?).=