math: remove ieee_arithmetic import#920
Merged
VincentVanlaer merged 1 commit intomainfrom Feb 17, 2026
Merged
Conversation
Importing any of the ieee modules has a somewhat unexpected effect. Each procedure that has an ieee module in scope will (1) save the FPU state at the start and (2) restore it at the end, adding any flags that were raised by the procedure. Since the `use ieee_arithmetic` is included in the main math module directly, everything that imports math will be effectively be importing an ieee module. This has a large impact on performance (for example, the `low_z` test case runs in 2/3 the time with this patch).
Contributor
|
I’m thinking more about Vincent’s interpretation here:
"Each procedure that has an ieee module in scope will (1) save the FPU state at the start and (2) restore it at the end, adding any flags that were raised by the procedure. Since the use ieee_arithmetic is included in the main math module directly, everything that imports math will be effectively be importing an ieee module. This has a large impact on performance (for example, the low_z test case runs in 2/3 the time with this patch).”
But none of the IEEE functions are made public from the math module, so surely importing the math module should not mean that the IEEE module is in scope?
… On Feb 17, 2026, at 8:18 AM, Vincent Vanlaer ***@***.***> wrote:
Merged #920 into main.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because your review was requested.Message ID: ***@***.***>
--
Rich Townsend • Professor of Astronomy
Astronomy Department • University of Wisconsin-Madison
Phone: 608-262-1752 • E-mail: ***@***.***
|
Member
Author
gfortran seems to think otherwise. I tracked down where in the code it was adding the save/restore functions, and from what I can tell it just checks whether any symbols from any ieee modules are in scope (for whatever definition of scope is used within gfortran). Perhaps worthy of a bug report, but that might take a while to go through the pipeline. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Importing any of the ieee modules has a somewhat unexpected effect. Each procedure that has an ieee module in scope will (1) save the FPU state at the start and (2) restore it at the end, adding any flags that were raised by the procedure. Since the
use ieee_arithmeticis included in the main math module directly, everything that imports math will be effectively be importing an ieee module. This has a large impact on performance (for example, thelow_ztest case runs in 2/3 the time with this patch).