Skip to content
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

FIX: avoid overflow on overflow check for Mac M1 #945

Open
wants to merge 4 commits into
base: develop
Choose a base branch
from

Conversation

mckib2
Copy link
Contributor

@mckib2 mckib2 commented Feb 5, 2023

@mckib2
Copy link
Contributor Author

mckib2 commented Feb 5, 2023

@mborland @jzmaddock Didn't realize the changes would be similar for all issues at the start, so consolidating all these small PRs into a single one

@@ -647,7 +652,9 @@ namespace detail {
}
else if (result > max)
{
T diff = ((fabs(max) < 1) && (fabs(result) > 1) && (tools::max_value<T>() / fabs(result) < fabs(max))) ? T(1000) : T(result / max);
const T amax = fabs(max);
volatile const T aresult = fabs(result); // volatile: force compiler to honor data-dependency in chained bool exprs below
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You should really only need const volatile in a shared memory environment. Do you still get overflow errors with just const?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I tried all the variations I could think of. What also worked was predclaring the amax and aresult and switching around tools::max_value<T>() / fabs(result) < fabs(max) to tools::max_value<T>() / amax < aresult, but I that was only suppressing it in this case for a specific relationship between result and max, so the volatile in my mind makes it a little more generic

@mckib2
Copy link
Contributor Author

mckib2 commented Feb 5, 2023

I believe SciPy is using this image and seeing the errors. It's about 9 months old and I wonder if updating to the latest may avoid these (compiler?) issues/bugs

@mborland
Copy link
Member

mborland commented Feb 5, 2023

I believe SciPy is using this image and seeing the errors. It's about 9 months old and I wonder if updating to the latest may avoid these (compiler?) issues/bugs

Might be worth updating. I am using macOS Ventura with Clang 14.0.0 on an M1 MacBook Pro and see none of the errors. Anyone on Ventura won't even have the option for the Clang 13 series.

@jzmaddock
Copy link
Collaborator

I confess I'm liking this less and less: the code appears to be correct, something somewhere is generating incorrect code if spurious overflow is happening on a code branch that should never be taken. Plus volatile plays absolute havoc with compiler optimizers. I don't as it happens mind at all if this is the full extent of the issue, but I have a hunch that we're about to take a deep dive through a very deep rabbit hole, as the library is choc full of logic like this.

So I guess the questions are:

  • is this fixed in the latest release as Matt suggests?
  • If not, how come Matt and I are unable to reproduce? There still appears to be something critical missing.
  • What's the Apple/Clang take on this? Is it a known issue upstream?

@mckib2
Copy link
Contributor Author

mckib2 commented Feb 12, 2023

is this fixed in the latest release as Matt suggests?

Testing this out now

If not, how come Matt and I are unable to reproduce? There still appears to be something critical missing.

Sounds like neither of you have tried on this specific version of MacOS? I also notice it only shows up when -O2 or -O3 optimizations are enabled.

What's the Apple/Clang take on this? Is it a known issue upstream?

I wasn't able to find anything upstream, I'll submit an issue

@mborland
Copy link
Member

What's the Apple/Clang take on this? Is it a known issue upstream?

I wasn't able to find anything upstream, I'll submit an issue

If you are able to make an extremely minimal reproducer like the GCC Bugzilla requires @NAThompson can route it to the right people at Apple.

@mckib2
Copy link
Contributor Author

mckib2 commented Feb 13, 2023

What's the Apple/Clang take on this? Is it a known issue upstream?

I wasn't able to find anything upstream, I'll submit an issue

If you are able to make an extremely minimal reproducer like the GCC Bugzilla requires @NAThompson can route it to the right people at Apple.

Minimal reproducer (not sure how it compares to GCC Bugzilla) is in the upstream llvm-project issue: llvm/llvm-project#60695 (comment)

@mckib2
Copy link
Contributor Author

mckib2 commented Feb 15, 2023

If you are able to make an extremely minimal reproducer like the GCC Bugzilla requires @NAThompson can route it to the right people at Apple.

@mborland The issue was rejected by Clang maintainers, I'll try looking up my Apple ID and submitting an issue there

@mborland
Copy link
Member

Since the issue seems to be fixed in newer macOS I wouldn't be surprised if they don't investigate the bug either.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants