- User Since
- Feb 9 2017, 1:53 PM (319 w, 2 d)
Fri, Mar 24
@bd1976llvm Can you file an issue for this: https://llvm.org/docs/GitHub.html#backporting-fixes-to-the-release-branches
Mon, Mar 20
I think the context got mixed up in the patch, so I have a new version here: https://reviews.llvm.org/D145996
Thu, Mar 16
Wed, Mar 15
Better fix for formatting.
Tue, Mar 14
Mon, Mar 13
Fri, Mar 10
From what I can tell the problem is not the JIT'd code, but registering the EHFrames. Maybe the endian differences make libgcc not able to read the EHFrames since they are generated for x86. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108994#c14
Thu, Mar 9
Fix PowerPC tests too.
Should we apply this patch to the release/16.x branch to create a more smooth transition since the option has been removed in main?
-fopenmp-add-rpath has been removed.
We're holding -rc4 until this is merged, so it would be great if we could merge it on Friday.
As a result of this change, the X86 tests are being run on other hosts e.g. SystemZ. Was this intended?
Fri, Mar 3
Tue, Feb 28
We switched to using <arch>-redhat-linux-gnu as the default triple and we patch clang to translate the triple from <arch>-redhat-linux-gnu to <arch>-redhat-linux only when searching for the gcc installation, but not for anything else. Switching clang/llvm to treat <arch>-redhat-linux or <arch>-suse-linux as a gnu environment would be better, but that would also cause a behavior change for anyone using those triples.
Address some more review comments.
@joycebrum Do you need me to commit this for you?
Mon, Feb 27
Add exports to LLVMExports.cmake instead of a separate file.
Would this make more sense in a config file rather than a CMake option? @MaskRay
Feb 22 2023
@JonChesterfield I don't think we should be putting any Fedora specific logic into clang's build system or the driver, if that's what you are suggesting. Fedora can always patch the compiler or install a config file to change the default behavior, even though this is something we try really hard to avoid.
LGTM. I tested this here with our stable branch CI jobs: https://github.com/llvm/llvm-project-release-prs/pull/309
Feb 21 2023
FWIW, I'm in favor of this patch. System directory rpaths (e.g. /usr/lib64) are not allowed in Fedora Linux. The current default makes building packages with clang+openmp more difficult.
Feb 16 2023
Update permissions for the action.
Feb 14 2023
Put setup code into a script and make sure to always do the upload.
Addresss some review feedback and also make sure the correct ref is checked out.
Feb 7 2023
This patch is from @str4d
Rebase on main.
Feb 6 2023
Feb 3 2023
LGTM, Thanks, can you open the backport request for release/16.x ?
Jan 31 2023
LGTM. Thank you for doing this.
Jan 30 2023
Jan 27 2023
Jan 26 2023
Does this mean that clang will no longer search for the ROCM and CUDA library paths for every C compile?
Jan 25 2023
Jan 24 2023
LGTM. Thank you.
@luke You'll need to contact the bot owners so they can update machine. The workers running the publish-sphinx-docs will need to be updated too. @gkistanova should be able to help.
Jan 23 2023
LGTM. I tested and this fixes the build.
This is still the wrong change IMO. I don't know, maybe I'm not being clear, but I don't 'think you ever actually tried my suggestion in D141581 which was to leave the RISCVTargetParserTableGen Depends as is and add the pseudo targets in llvm/cmake/modules/LLVMConfig.cmake.in.