User Details
- User Since
- Mar 27 2015, 11:23 AM (315 w, 2 d)
Fri, Apr 9
The OpenJDK bug was UB in the OpenJDK code: https://bugs.openjdk.java.net/browse/JDK-8229258 already fixed in JDK14. (But not backported to JDK 11 LTS, which is the version Brooks found an error in above.)
It seems like there's a bug with vtable thunks getting the wrong information. This appears to be a pre-existing bug, but this change has caused it to start actively breaking code.
Thu, Apr 8
Tue, Apr 6
Mon, Apr 5
Mon, Mar 29
In general, I think it's extremely unfortunate that Clang and LLVM have different copies of the same information. It's a problem for way more than just this one situation. So, I really don't like choice 1 -- I think it's moving in the wrong direction.
Mar 12 2021
Mar 11 2021
Use natural alignment for _Interlocked* intrinsics.
Or, if you have suggestions on how to make it easier to review, I'd be open to that.
Mar 4 2021
Version where tests actually pass: I forgot to merge a fixup commit before uploading.
The idea here is not to "ignore type alignment". EmitPointerWithAlignment will sometimes return an alignment for a pointer that's less than the alignment of the pointee type, e.g. because you're taking the address of a packed struct field. The critical question is whether the atomic builtins ought to make an effort to honor that reduced alignment, even if it leads to terrible code, or if we should treat the use of the builtin as a user promise that the pointer is actually more aligned than you might think from the information statically available.
Address review comments.
Feb 26 2021
Feb 25 2021
Sorry for never looking at this before now. :(
IIUC, the requirement is:
Feb 24 2021
Please reduce the test case per MaskRay's comment, then lg.
Feb 23 2021
I can imagine there being some cases where these could theoretically be useful.
This change also modifies (breaks!) the 32-bit NOP set, definitely shouldn't do that. (But I think all that can be reverted, in any case).
Feb 22 2021
Ping.
Ping.
Ping.
Feb 12 2021
I ended up reverting the changes I made to llvm/lib/IR/AutoUpgrade.cpp as the file was including llvm/Analysis/ObjCARCUtil.h, which was violating layering.
Feb 11 2021
This seems to have fallen off everyone's radar -- sorry about that!
This seems to have fallen off everyone's radar -- sorry about that!
Feb 10 2021
Feb 5 2021
Feb 4 2021
Feb 3 2021
Please prefix the title of the commit with "[lld-macho]" so that it's easier to understand what bundle_loader is being implemented in.
Feb 2 2021
My concern is that this is treating a backend _bug_ as if it were just an optional feature. But it's not the case that it might be reasonable to either implement or not implement this in a backend -- it should be implemented, and those that don't are buggy.
Feb 1 2021
I still have the same fundamental objection as before to the parts of this patch for prohibiting FP add/sub on some targets.
Jan 31 2021
Jan 27 2021
Add neglected clang-abi-compat.cpp change.
Jan 26 2021
OK, I've posted two follow-up changes now.
Minor updates.
Jan 21 2021
Address comments.
Jan 20 2021
Was the "group" libc++abi accept intended to be an accept for the whole revision? Or should still ping for review from rsmith or someone else?
Jan 14 2021
This doesn't get at the root cause though. Are those labels doing anything in the debug build? Why are they emitted? Can they be reasonably removed?
Looks totally reasonable to me.
Jan 13 2021
Right, there's no fundamental reason why moving a label has to be forbidden -- but it'd be extremely complex if we allowed moving a label which could cause the re-layout of a fragment we thought we'd already finalized the offsets for. This would happen if the label offset required relaxation of some instruction/data referencing it. That, then, might require undoing the padding from an instruction we've already padded out, due to less alignment-padding being required overall.
Jan 9 2021
Agreed w.r.t. timing -- I would like to get all of these changes landed soon after the LLVM 12 branch-cut, to allow plenty time to stew on the main branch before they make it into a release to try to identify any issues.
Jan 8 2021
OK thanks -- abandoning this patch.
Jan 7 2021
Jan 6 2021
Fix and test.
I've finally got back to moving this patch forward -- PTAL, thanks!
Dec 29 2020
Dec 28 2020
Dec 10 2020
I don't think we should change the meaning of __attribute__((const)) to exclude depending on thread-id.
Dec 9 2020
Dec 1 2020
Oh -- if it's not too late, can you fix the commit message before pushing -- it could probably do with a little more explanation.