- User Since
- May 29 2017, 8:02 AM (190 w, 6 d)
Fri, Jan 22
Thu, Jan 7
Fixed spelling mistake in comment.
Wed, Jan 6
Updated some of the test cases for the 32 bit compilation.
Added the todo comment in the TD file.
Tue, Jan 5
Added comment for function.
Fixed variable name.
Added test case for 32 bit target.
Since D92959 is now in I am going to abandon this patch.
Forgot to delete the old lines in the TD file.
Dec 17 2020
I do not have any more questions.
Thank you for refactoring this. It looks a lot cleaner.
I just had some minor comments. I think it makes sense overall.
Tested this on some actual legacy compiled code and it does what we want.
Only one minor question. Otherwise, LGTM.
Dec 15 2020
Dec 14 2020
Dec 11 2020
Dec 10 2020
Thank you for the explanations!
I'm fine with keeping the if conditions looking similar and avoiding too many test changes.
Thank you for your help!
Rebased on top of D92089
Dec 9 2020
Thank you for pointing me to this patch.
Merged if statement and did a bit of cleanup according to comments.
Merged two test cases.
Dec 8 2020
I'm sorry to bug you but I still don't understand what you are looking for.
Dec 7 2020
Added CHECK-NEXT that was missed.
Dec 4 2020
Changed the multiclass into class.
Dec 3 2020
A few of the lines in the TD file were too long so I fixed that.
Updated the test case to use a multiclass and added a comment to each pattern.
Also added different types to one of the patterns.
Dec 1 2020
Since the scope of the patch has changed two of the tests were no longer
required so I have removed them.
Added a warning for the case where TLS relaxation is disabled due to a missing
Updated test cases according to review.
Nov 30 2020
Completely changed the way that the patch works.
Nov 25 2020
I have done some testing with gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0 and GNU ld (GNU Binutils for Ubuntu) 2.30.
Nov 23 2020
Nov 20 2020
Nov 18 2020
Nov 17 2020
Nov 13 2020
Oct 23 2020
Sorry... can you pause on this for a second. I want to talk to the glibc guys about this first.
Would you like me to just revert this change? Do you want to see something on Phabricator for it?
Updated comment in test case.
Oct 22 2020
This is still causing a buildbot failure on a Power PC sanitizer bot:
Oct 20 2020
Fixed the LLVM_FALLTHROUGH
Added split-file and -soname to the test file.
Oct 15 2020
Fixed a couple of comments.
Moved the R_PPC64_DTPREL34 case first and adjusted the dynamic thread offset
there before falling through to the common case.
Oct 13 2020
Fixed the issue where the 0x8000 offset was not being considered.
Oct 9 2020
Oct 8 2020
Added the missing header file.
Added the license comment.
Oct 6 2020
Related to this please see Nemanja's comment on https://reviews.llvm.org/D82485.
Oct 2 2020
I can confirm that this changeset is causing the timeout on the clang-ppc64be-linux buildbot.
The following was run on a Big Endian Power PC machine.
All of the dependencies of this patch have now been committed.
Rebased to top of trunk.
Fixed a couple of comments.
Removed some lines that are not required form the test.
Oct 1 2020
Ok, thank you MaskRay.
Sorry, in my head I didn't put the error together with what you had said previously.
Looks like .rela.dyn is located in different places depending on the machine.
From two different bots:
# GDTOIE-RELOC: Relocation section '.rela.dyn' at offset 0x10118 contains 2 entries: ^ <stdin>:2:1: note: scanning from here Relocation section '.rela.dyn' at offset 0x10128 contains 2 entries:
# GDTOIE-RELOC: Relocation section '.rela.dyn' at offset 0x10118 contains 2 entries: ^ <stdin>:2:1: note: scanning from here Relocation section '.rela.dyn' at offset 0x10148 contains 2 entries:
Reopening this to see why the test failed.
Updated the comment.
Sep 30 2020
Further reduced the test case.
Removed the last function from the test assembly file.