Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.
Sign upbpo-28015: Support LTO build with clang #9908
Conversation
.o generated by clang in LTO mode actually are LLVM bitcode files, which leads to a few errors during configure/build step: - add lto flags to the BASECFLAGS instead of CFLAGS, as CFLAGS are used to build autoconf test case, and some are not compatible with clang LTO (they assume binary in the .o, not bitcode) - force llvm-ar instead of ar, as ar is not aware of .o files generated by clang -flto
This comment has been minimized.
This comment has been minimized.
the-knights-who-say-ni
commented
Oct 16, 2018
Hello, and thanks for your contribution! I'm a bot set up to make sure that the project can legally accept your contribution by verifying you have signed the PSF contributor agreement (CLA). Unfortunately we couldn't find an account corresponding to your GitHub username on bugs.python.org (b.p.o) to verify you have signed the CLA (this might be simply due to a missing "GitHub Name" entry in your b.p.o account settings). This is necessary for legal reasons before we can look at your contribution. Please follow the steps outlined in the CPython devguide to rectify this issue. You can check yourself to see if the CLA has been received. Thanks again for your contribution, we look forward to reviewing it! |
This comment has been minimized.
This comment has been minimized.
CLA just signed, that should be ok now. I did not commit the |
Python source code includes configure for practical reasons, you must run autoconf and include the modified configure in your PR. |
This comment has been minimized.
This comment has been minimized.
bedevere-bot
commented
Oct 16, 2018
A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated. Once you have made the requested changes, please leave a comment on this pull request containing the phrase |
It would be convenient if configure fails with an error and an explanation how to fix it if llvm-ar is missing:
|
This comment has been minimized.
This comment has been minimized.
I tested the 3rd version. It seems like -flto is passed during the compilation of object files and to the final linker step:
|
LGTM. It works as expected (see my comment above) and it fix an obvious bug https://bugs.python.org/issue28015#msg327817 |
This comment has been minimized.
This comment has been minimized.
You may add a NEWS entry using the tool "blurb". @serge-sans-paille signed the CLA, but I have to wait until someone review his signature. |
This comment has been minimized.
This comment has been minimized.
I will remove the "CLA not signed" label once "Contrib Form Received" will become Yes on https://bugs.python.org/user22883 |
This comment has been minimized.
This comment has been minimized.
miss-islington
commented
Oct 25, 2018
Thanks @serge-sans-paille for the PR, and @vstinner for merging it |
This comment has been minimized.
This comment has been minimized.
bedevere-bot
commented
Oct 25, 2018
GH-10089 is a backport of this pull request to the 3.7 branch. |
.o generated by clang in LTO mode actually are LLVM bitcode files, which leads to a few errors during configure/build step: - add lto flags to the BASECFLAGS instead of CFLAGS, as CFLAGS are used to build autoconf test case, and some are not compatible with clang LTO (they assume binary in the .o, not bitcode) - force llvm-ar instead of ar, as ar is not aware of .o files generated by clang -flto (cherry picked from commit 5ad36f9) Co-authored-by: serge-sans-paille <serge.guelton@telecom-bretagne.eu>
This comment has been minimized.
This comment has been minimized.
@serge-sans-paille: The backport to 3.7 was straighfoward and could be automated, but backport to 3.6 creates a conflict on configure.ac. Do you want to try the backport? I'm not sure if it's worth it to backport the change up to 3.6. It's up to you. |
.o generated by clang in LTO mode actually are LLVM bitcode files, which leads to a few errors during configure/build step: - add lto flags to the BASECFLAGS instead of CFLAGS, as CFLAGS are used to build autoconf test case, and some are not compatible with clang LTO (they assume binary in the .o, not bitcode) - force llvm-ar instead of ar, as ar is not aware of .o files generated by clang -flto (cherry picked from commit 5ad36f9) Co-authored-by: serge-sans-paille <serge.guelton@telecom-bretagne.eu>
This comment has been minimized.
This comment has been minimized.
@vstinner I think I have the 3.6 patch, should I create a new PR on the 3.6 branch? |
This comment has been minimized.
This comment has been minimized.
Finally, there a re many complex interactions with RANLIB and AR, dropping the backport. |
This comment has been minimized.
This comment has been minimized.
The Python 3.6 backport? It's too complex? It's ok to only fix Python 3.7 and newer. (I just need your confirmation to close the issue.) |
This comment has been minimized.
This comment has been minimized.
Yeah, the 3.6 backport would require some more thoughts, better drop it
and close the issue. Thanks!
|
.o generated by clang in LTO mode actually are LLVM bitcode files, which leads to a few errors during configure/build step: - add lto flags to the BASECFLAGS instead of CFLAGS, as CFLAGS are used to build autoconf test case, and some are not compatible with clang LTO (they assume binary in the .o, not bitcode) - force llvm-ar instead of ar, as ar is not aware of .o files generated by clang -flto (cherry picked from commit 5ad36f9) Co-authored-by: serge-sans-paille <serge.guelton@telecom-bretagne.eu>
.o generated by clang in LTO mode actually are LLVM bitcode files, which leads to a few errors during configure/build step: - add lto flags to the BASECFLAGS instead of CFLAGS, as CFLAGS are used to build autoconf test case, and some are not compatible with clang LTO (they assume binary in the .o, not bitcode) - force llvm-ar instead of ar, as ar is not aware of .o files generated by clang -flto
This comment has been minimized.
This comment has been minimized.
The 3.6 backport works fine if https://bugs.python.org/issue31625 is applied for 3.6 as well. |
.o generated by clang in LTO mode actually are LLVM bitcode files, which leads to a few errors during configure/build step: - add lto flags to the BASECFLAGS instead of CFLAGS, as CFLAGS are used to build autoconf test case, and some are not compatible with clang LTO (they assume binary in the .o, not bitcode) - force llvm-ar instead of ar, as ar is not aware of .o files generated by clang -flto
.o generated by clang in LTO mode actually are LLVM bitcode files, which leads to a few errors during configure/build step: - add lto flags to the BASECFLAGS instead of CFLAGS, as CFLAGS are used to build autoconf test case, and some are not compatible with clang LTO (they assume binary in the .o, not bitcode) - force llvm-ar instead of ar, as ar is not aware of .o files generated by clang -flto (cherry picked from commit 5ad36f9) Co-authored-by: serge-sans-paille <serge.guelton@telecom-bretagne.eu>
.o generated by clang in LTO mode actually are LLVM bitcode files, which leads to a few errors during configure/build step: - add lto flags to the BASECFLAGS instead of CFLAGS, as CFLAGS are used to build autoconf test case, and some are not compatible with clang LTO (they assume binary in the .o, not bitcode) - force llvm-ar instead of ar, as ar is not aware of .o files generated by clang -flto (cherry picked from commit 5ad36f9) Co-authored-by: serge-sans-paille <serge.guelton@telecom-bretagne.eu>
serge-sans-paille commentedOct 16, 2018
•
edited by bedevere-bot
.o generated by clang in LTO mode actually are LLVM bitcode files, which
leads to a few errors during configure/build step:
to build autoconf test case, and some are not compatible with clang LTO
(they assume binary in the .o, not bitcode)
by clang -flto
https://bugs.python.org/issue28015