-
Notifications
You must be signed in to change notification settings - Fork 10.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Shared library compiled with -ffast-math modifies FPU state #57589
Comments
I wish nobody would ever use -Ofast or -ffast-math (as you say, "friends don't let friends use fast-math"). That said, this issue does seem like even more of a misfeature even than the other issues caused by fast-math. However, currently, Clang will can link against a So, since this behavior is effectively just for GCC compatibility, I think Clang probably ought to follow GCC's lead here -- that is, if any changes are made for GCC's 55522, then implement a parallel change to Clang, otherwise leave it as is. |
The gcc bug is almost 10 years old at this point with no sign of movement, and this particular behavior is continuing to cause problems in projects, many of which don't realize that they're enabling something with global effects. As a harm reduction measure, it would be really great to at least avoid linking in |
Somehow this seems even worse. |
I agree this is an unfortunate behavior. Yet, I think it would also be poor to diverge Clang's behavior from GCC's here. It wouldn't be particularly helpful from a practical standpoint, since I expect these python packages are generally built with GCC when targeting linux anyhow. Note that the implementation in clang, to match GCC's behavior, was explicitly requested by a user in #14396 a decade back. |
If you don't want to remove it, then would it be possible to:
|
I think there are enough safeguards. We can't protect every schlub from incorrect use. Only schlubs vote this post down ;) |
@llvm/issue-subscribers-clang-driver |
This wouldn't be the first case where appealing to GCC's behavior leads to outcome that virtually everyone agrees is problematic. (oh hi We definitely need to at least document this behavior so that people are aware what the consequences of using Actually, the behavior with |
GCC has now changed the behavior in https://gcc.gnu.org/PR55522 to no longer link crtfastmath.o to |
see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522 and llvm/llvm-project#57589 for a summary. the FPU flags which are set as a result of linking with -ffast-math cause ALL denormals to be rounded to zero across the entire program. among other things, this causes java's Double.parseDouble to enter an infinite loop when attempting to parse denormal values (e.g. Ancient Warfare 2 would hang during startup while attempting to call Double.parseDouble with a string value of "1.582162261062063E-308").
see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522 and llvm/llvm-project#57589 for a summary. the FPU flags which are set as a result of linking with -ffast-math cause ALL denormals to be rounded to zero across the entire program. among other things, this causes java's Double.parseDouble to enter an infinite loop when attempting to parse denormal values (e.g. Ancient Warfare 2 would hang during startup while attempting to call Double.parseDouble with a string value of "1.582162261062063E-308"). (cherry picked from commit 29ada41) # Conflicts: # src/main/native/project.mk
This fixes llvm#57589, and aligns Clang with the behavior of current versions of gcc. There is a new option, -mdaz-ftz, to control the linking of the file that sets FTZ/DAZ on startup, and this flag is on by default if -ffast-math is present and -shared isn't.
This fixes #57589, and aligns Clang with the behavior of current versions of gcc. There is a new option, -mdaz-ftz, to control the linking of the file that sets FTZ/DAZ on startup, and this flag is on by default if -ffast-math is present and -shared isn't. This also partially reverts fa7cd54 in that it disables the attempt to set the IR denormal-fp-math attribute based on whether or not -ffast-math is applied as it is insufficiently reliable.
This fixes llvm/llvm-project#57589, and aligns Clang with the behavior of current versions of gcc. There is a new option, -mdaz-ftz, to control the linking of the file that sets FTZ/DAZ on startup, and this flag is on by default if -ffast-math is present and -shared isn't.
On linux x86_64
gives:
This means that any thread which later loads the library will then set the flush subnormals to zero (FTZ) and subnormals are zero (DAZ) flags (even if the executable itself was not compiled with
-ffast-math
).Related discussion
The text was updated successfully, but these errors were encountered: