Fix C++ portability issue with using CMPLX #24211
Merged
Conversation
This file contains 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
Though compiling PR chapel-lang#24184 with a back-end C++ compiler worked on my laptop and chapcs11, it caused problems with other C++ compilers, like g++ (SUSE Linux) 7.5.0 on [redacted] and some of our other nightly configurations. At present, it's somewhat circumstantial that we compile this code with a C++ compiler: It only happens when compiling our qio re2 shim code, and that code doesn't rely on these tuple-to-complex conversion routines anyway. As a result, what I've done here is to beef up my #ifndef to skip over the new preferred path of code when we're compiling for C++ to be safe, and on the assumption that it doesn't really matter anyway (won't be called); and even if that changes in the future, the fallback paths from chapel-lang#24184 ought to work... --- Signed-off-by: Brad Chamberlain <bradcray@users.noreply.github.com>
mppf
reviewed
Jan 19, 2024
| // test environments, so dodge it to be safe; Currently, we only compile | ||
| // this header using a C++ compiler when compiling our re2 stubs, which | ||
| // don't seem to use this routine anyway. | ||
| #if defined(CMPLX) && !defined(__cplusplus) |
There was a problem hiding this comment.
Did you intend to have this checking for CMPLXF ?
There was a problem hiding this comment.
Yes, thank you. Opposite of usual: Remembered to update the comment, but not the code.
1 task
bradcray
added a commit
to bradcray/chapel
that referenced
this pull request
Jan 19, 2024
--- Signed-off-by: Brad Chamberlain <bradcray@users.noreply.github.com>
bradcray
added a commit
that referenced
this pull request
Jan 19, 2024
mppf
added a commit
that referenced
this pull request
Jan 25, 2024
Follow-up to PR #24127. After #24127, the new `sqrtparams` test started to fail on Mac OS X system. Upon investigating, I identified that the difference in behavior from what the test expects is due to differences in how `std::sqrt` is implemented for complex numbers in libc++ vs stdlibc++. Also, I noticed that the issue is limited to the C++ implementation of the complex square root. This PR changes the implementation to use a C implementation of complex square root since it appears to have more reliable precision. Note that this C implementation required some workarounds for `CMPLX` not being available on all systems (as with PR #24184 and #24211). In particular, `CMPLX` does not seem to be available when using `clang` on Ubuntu 23.10, even though it is available with `gcc` on that system. I filed an issue against libc++ about the problem, but in discussion there it sounds like complex `sqrt` isn't required to have any particular precision. * llvm/llvm-project#78738 Reviewed by @DanilaFe - thanks! - [x] full comm=none testing
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.
Though compiling PR #24184 with a back-end C++ compiler worked on my laptop and [redacted], it caused problems with other C++ compilers, like g++ (SUSE Linux) 7.5.0 on [redacted] and some of our other nightly testing configurations.
At present, it's somewhat circumstantial that we compile this code with a C++ compiler at all: It only happens when compiling our qio re2 shim code, and that code doesn't rely on these tuple-to-complex conversion routines anyway. As a result, what I've done here is to beef up my #ifndef to skip over the new preferred path of code when we're compiling for C++ to be safe, and on the assumption that it doesn't really matter anyway (won't be called); and even if that changes in the future, the fallback paths from #24184 ought to work...
(As potentiall future work, we could also refactor our header files so that the re2 shim only gets definitions that it truly needs, which probably would involve forking some portions of chpltypes.h out of it and into another header. I started into this as part of #24184 before deciding it was overkill for that PR).