- User Since
- Feb 9 2017, 1:53 PM (226 w, 1 d)
Wed, Jun 9
Fri, Jun 4
What is the status of this patch? It fixes a blocking bug for the 12.0.1 release.
Thu, May 27
Wed, May 26
I think this could be simplified by using object libraries like this patch: https://reviews.llvm.org/D95727 does for libLLVM.so
D103154 seems to be making a lot of the same changes as this patch.
Fri, May 21
Are you still seeing failures in the main branch? I thought I had fixed this with Revision: https://reviews.llvm.org/D96367.
Thu, May 13
May 12 2021
May 11 2021
FWIW, I was originally against adding LLVM_EXTERNAL_VISIBILITY to the class, because I thought it was just working around a fundamental flaw in -fvisiblity=hidden, but based on the discussion here, I've fine with the proposed solution.
How long do these tests take to run? Could you add this to the list of release builders too?
I was originally skeptical of this change, because of some negative feedback about these flags in the past on the Fedora development list. However, the people I've talked to more recently seem to be in favor of this change, so no objection from me.
I saw this fix was backported to the release/12.x branch, was there a bug for this?
May 10 2021
I'm fine with the concept of having an option for generating a snapshot tarball. I understand that it may not be useful to everyone, but we already ship tarballs as part of our releases and if we were to do official snapshots for the project, we would want to generate the tarballs in the same way. I do agree with Hans that it would be nice if there was some way to uniquely identify the tarball (e.g. with the git hash) otherwise if you do multiple tarballs a day, they would all have the same name.
May 7 2021
Does this change mean that LD_PRELOAD will no longer work? Are there any other downsides to adding these flags?
May 6 2021
@rnk Even if we were to commit this patch, do you think we would still need to fix/remove llvm:Any?
@rnk I agree with
Adding @rnk, who reviewed the original patch for awareness...
Can you file a bug for this?
Apr 26 2021
Can you file a bug for this?
Apr 15 2021
Apr 14 2021
Apr 8 2021
Apr 7 2021
Apr 6 2021
Updated patch with fixes for z3 and libffi build failures
Apr 5 2021
It's helpful for the release managers to have at least have a target date for creating the release branch and also to know how much time to wait between -rc1 and -rc2. I think we should have this information at a minimum, but I agree after -rc2 the release schedule does become unpredictable. I'll try to rework this, so it is less specific.
Apr 1 2021
Address review comments.
Mar 30 2021
@delcypher Ok, thanks. So my question for for @phosek is what if we replaced the usage of llvm-config with find_package(LLVM) would that change also enable the clean ups you are talking about? Or does relying on any kind of out-of-tree files make the build more complicated?
We still build compiler-rt in non-monorepo configuration for Fedora. Which files from the llvm directory (or other directories in the monorepo) does compiler-rt depend on?
Mar 29 2021
I have this uncommitted change: D95727 which updates libLLVM.so to use object libraries, would you be able to also use object libraries to avoid adding this python script?
Feb 25 2021
Feb 23 2021
I've merged this.
You can go ahead and push it directly to the branch.
Feb 17 2021
This seems OK to backport, can you file a bug for it?
Feb 12 2021
Can you file a bug for the backport request?
Feb 11 2021
Feb 10 2021
I get concerned when I see us having to disable optimizations to fix bugs. Is there any kind of long-term plan to make the kernel verifier able to accept what LLVM produces or will we always be chasing after failures like this?
Is the fma.cl file mostly copied from another file that is already in the tree?
Feb 9 2021
Feb 8 2021
Sorry, it's too late for 11.1.0.
Can you file a bug for this and mark it as a blocker for release-12.0.0?
Feb 5 2021
You can push this directly to the release/12.x branch when it's ready.
Feb 4 2021
The goal here is for distributions to be able to build libc++ one way and then have it work with clang without requiring that users add additional linker flags besides -static or -stdlib=libc++. Is there a combination of CMake arguments we can use when building libc++ to make all static and shared linking with libc++ work out of the box?
Please go ahead and merge this to the release/12.x branch.
Yes, go ahead and push this.
Feb 2 2021
Is this something we want to try to pull into the release/12.x branch?
Jan 29 2021
Jan 28 2021
Jan 26 2021
Jan 25 2021
Jan 22 2021
Jan 21 2021
Thanks for the updates. I think this proposal is ready to send to Chris (Step 4).
@andreisfr I don't seen any major issues being raised with this backend. It would be great if there was a public official ISA document, but I don't think the lack of one is a blocker. Please make a last check of the reviews in phabricato to see if there are any outstanding issues. Then, I would recommend you take a look at the documentation @tonic posted. Specifically the 5 bullet points under the "The basic rules for a back-end to be upstreamed in experimental mode are:" header. If you think you meet those requirements, please re-send the RFC to the list, so we can discuss getting this added.
Jan 20 2021
Fix shared object symlinks.