-
-
Notifications
You must be signed in to change notification settings - Fork 11k
BUG, DIST: fix normalize IBMZ features flags #20588
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
Conversation
The normal behavior is to erase any flag that starts with `-m[a-z0-9\-\.]` when flag `-march` or `-mcpu` specified. for example: cc_normalize_flags([ '-msse', '-msse2', '-msse3', '-mssse3', '-march=core-avx2' ]) should be normalized to: ['-march=core-avx2'] but in the case of `s390x`, on GCC flag `-march=arch[0-9]` doesn't implies flag `-mzvector` which is required to enable zvector api. for example: cc_normalize_flags([ '-mzvector', '-march=arch11', '-march=arch12', '-march=arch13'] ) should be normalized to: ['-mzvector', '-march=arch13'] instead of: ['-march=arch13']
reword the commit |
08a27ad
to
3e81230
Compare
While this does seem like the correct fix for the problem, this whole dance seems fragile. How did we get into the situation where we need to remove compiler flags: who is adding them in the first place? Perhaps it would be better to raise an error if we detect wrong flags rather than trying to fix them? |
A natural reaction to the chaos of compilers, the stage is stable compilers don't usually change their cli options.
The answer is the implied features. This issue occurred when more than one feature implies one another and each one of them has a flag override the other or conflict with another or requires arch concatenation
there are no wrong flags, as I said above issue occurred when we combine the flags of multiple features. distutils/tests/test_ccompiler_opt.py covers all these cases. |
Thanks @seiko2plus |
Could we hold some kind of state, and only turn them into compiler flags when all the detection is finished? Then we could manage the state in a more straight-forward fashion. |
we don't know what kind of combination of features are going to be enabled through dispatch-able sources or through the build options. in the case of zsystem maybe yes, since we only deal with only three features and one kind of compiler. so instead of normalization, we will add three conditions, for example: if cpu-baseline eq "vx" then flags = "-mzvector -march=arch11"
if cpu-baseline eq "vx vxe" then flags = "-mzvector -march=arch12"
if cpu-baseline eq "vx vxe vxe2" then flags = "-mzvector -march=arch13" but what about the other arches/features? for more information check the following functions: numpy/numpy/distutils/ccompiler_opt.py Lines 1059 to 1081 in 06e37a3
numpy/numpy/distutils/ccompiler_opt.py Lines 1470 to 1475 in 06e37a3
|
Thanks @seiko2plus ! |
The normal behavior is to erase any flag that starts with
-m[a-z0-9\-\.]
when flag-march
or-mcpu
specified. for example:should be normalized to:
['-march=core-avx2']
but in the case of
s390x
, on GCC flag-march=arch[0-9]
doesn't implies flag-mzvector
which is required to enable zvector api. for example:should be normalized to:
instead of:
['-march=arch13']
The test unit didn't detect this bug because of a single-letter typo(my bad).
Build error:
relates #20552