-
Notifications
You must be signed in to change notification settings - Fork 151
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
Avoid redefinition of _bit_scan_{forward,reverse} macros #248
Conversation
Vc/common/bitscanintrinsics.h
Outdated
@@ -32,7 +32,7 @@ SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. | |||
# if Vc_GCC >= 0x40500 | |||
// GCC 4.5.0 introduced _bit_scan_forward / _bit_scan_reverse | |||
# include <x86intrin.h> | |||
# else | |||
# elif !defined(_bit_scan_forward) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Apple clang has /Library/Developer/CommandLineTools//usr/lib/clang/11.0.0/include/x86intrin.h
. Shouldn't we use that instead of entering the #elif
branch here? I.e. is #if Vc_GCC >= 0x40500
really correct, or should it be #if Vc_GCC >= 0x40500 || defined(Vc_CLANG) || defined(Vc_APPLECLANG)
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought about this, it's the other option. I just don't know which versions of clang have or don't have the macro. Maybe generically defining it if it's not defined is better than both?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The point is that even if the header exists, sometimes the macro is not defined. So we can include the header and if the macro is not defined, we define it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, but what happens if x86intrin.h
defines the macro but wasn't included yet? This header would still define the macro and a subsequent #include <x86intrin.h>
leads to an error?
I think the right fix is to unconditionally include x86intrin.h
for GCC, Clang and AppleClang before testing !defined(_bit_scan_forward)
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I agree. I will update the change. There were a couple of failures in Travis probably due to that. BTW, do you plan to make a new patch release of 1.4 anytime soon?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for the PR! See my comment inline
Vc/common/bitscanintrinsics.h
Outdated
@@ -32,7 +32,7 @@ SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. | |||
# if Vc_GCC >= 0x40500 | |||
// GCC 4.5.0 introduced _bit_scan_forward / _bit_scan_reverse | |||
# include <x86intrin.h> | |||
# else | |||
# elif !defined(_bit_scan_forward) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, but what happens if x86intrin.h
defines the macro but wasn't included yet? This header would still define the macro and a subsequent #include <x86intrin.h>
leads to an error?
I think the right fix is to unconditionally include x86intrin.h
for GCC, Clang and AppleClang before testing !defined(_bit_scan_forward)
.
How's this version? I tried to run tests, but ran into
which I don't know how to fix. What's providing this header? I guess it's an external dependency, but CMake configured without errors, so I'm confused. |
Hi @mattkretz, I cannot see what the error was, so I don't know if it's related to my changes. Can you please let me know? |
Ping, @mattkretz please! :-) |
@amadio Google says it's https://github.com/mattkretz/virtest - could you try with that, please? |
The header comes from a After doing this, I was able to run the tests and all pass with this change (GCC 8.3.1 and Clang 9.0.1 from CentOS 8) while making the build with Clang free of warnings. Can we merge this one? @mattkretz |
Can we merge this now? |
Looking at it now. Probably yes. :-) |
Can we use C++20? 😜 |
Fixes #247.