Page MenuHomePhabricator
Feed Advanced Search

Yesterday

hvdijk updated the diff for D102509: [lld][X86] Restore gotEntrySize..

Removed the shared object testing.

Sat, May 15, 5:04 AM · Restricted Project, lld
hvdijk added a comment to D102509: [lld][X86] Restore gotEntrySize..

Is x86-x32-plt.s NFC for now and you'll create another patch to fix x32?

Sat, May 15, 1:13 AM · Restricted Project, lld

Fri, May 14

hvdijk updated the diff for D102509: [lld][X86] Restore gotEntrySize..

I'm assuming you meant don't base the test on the old x86-64-plt.s, but the new is fine. Done now, and removed gotPltEntrySize.

Fri, May 14, 2:43 PM · Restricted Project, lld
hvdijk added a comment to D102509: [lld][X86] Restore gotEntrySize..

We shouldn't need both GotEntrySize and GotPltEntrySize. One is sufficient.

Fri, May 14, 10:05 AM · Restricted Project, lld
hvdijk requested review of D102509: [lld][X86] Restore gotEntrySize..
Fri, May 14, 9:45 AM · Restricted Project, lld
hvdijk added a reverting change for D62727: [ELF] Delete GotEntrySize and GotPltEntrySize: D102509: [lld][X86] Restore gotEntrySize..
Fri, May 14, 9:45 AM · Restricted Project
hvdijk updated the diff for D102359: [libc++] [test] Fix a few tests for 32-bit x86.

This diff is identical to the previous diff, but hopefully a reupload will redo the CI.

Fri, May 14, 1:31 AM · Restricted Project

Wed, May 12

hvdijk requested review of D102359: [libc++] [test] Fix a few tests for 32-bit x86.
Wed, May 12, 12:51 PM · Restricted Project

Mon, May 10

hvdijk committed rGb0ef2070bc7d: [X86] Fix position-independent TType encoding (authored by hvdijk).
[X86] Fix position-independent TType encoding
Mon, May 10, 9:05 AM
hvdijk closed D102132: [X86] Fix position-independent TType encoding.
Mon, May 10, 9:05 AM · Restricted Project

Sun, May 9

hvdijk added inline comments to D98574: [Sparc] Define the same macros for -mcpu=v9 as GCC on Linux and the BSDs.
Sun, May 9, 11:24 AM · Restricted Project
hvdijk added inline comments to D102132: [X86] Fix position-independent TType encoding.
Sun, May 9, 8:56 AM · Restricted Project
hvdijk updated the diff for D102132: [X86] Fix position-independent TType encoding.

Added gnux32 to test.

Sun, May 9, 8:54 AM · Restricted Project
hvdijk added inline comments to D50490: Restore correct x86_64 EH encodings in kernel code model.
Sun, May 9, 7:08 AM · Restricted Project
hvdijk requested review of D102132: [X86] Fix position-independent TType encoding.
Sun, May 9, 7:02 AM · Restricted Project

Thu, May 6

hvdijk added a comment to D100625: [clang-tools-extra] Do not use `LLVM_EXTERNAL_CLANG_TOOLS_EXTRA_SOURCE_DIR`.

Apparently Phabricator detected the presence of "revert D100625" in my alternative D101851's description and marked that as reverting this one. Of course, as this hadn't been committed, it cannot have been reverted either. Could you confirm that things work for you now, @Abpostelnicu?

Thu, May 6, 12:46 AM · Restricted Project

Wed, May 5

hvdijk committed rG7907c46fe619: Make clangd CompletionModel not depend on directory layout. (authored by hvdijk).
Make clangd CompletionModel not depend on directory layout.
Wed, May 5, 11:26 AM
hvdijk added a reverting change for D100625: [clang-tools-extra] Do not use `LLVM_EXTERNAL_CLANG_TOOLS_EXTRA_SOURCE_DIR`: rG7907c46fe619: Make clangd CompletionModel not depend on directory layout..
Wed, May 5, 11:26 AM · Restricted Project
hvdijk closed D101851: Make clangd CompletionModel not depend on directory layout..
Wed, May 5, 11:26 AM · Restricted Project

Tue, May 4

hvdijk added inline comments to D101851: Make clangd CompletionModel not depend on directory layout..
Tue, May 4, 3:18 PM · Restricted Project
hvdijk updated the diff for D101851: Make clangd CompletionModel not depend on directory layout..
Tue, May 4, 3:15 PM · Restricted Project
hvdijk requested review of D101851: Make clangd CompletionModel not depend on directory layout..
Tue, May 4, 1:12 PM · Restricted Project
hvdijk added a reverting change for D100625: [clang-tools-extra] Do not use `LLVM_EXTERNAL_CLANG_TOOLS_EXTRA_SOURCE_DIR`: D101851: Make clangd CompletionModel not depend on directory layout..
Tue, May 4, 1:12 PM · Restricted Project
hvdijk added a comment to D86310: [X86] Align i128 to 16 bytes in x86-64 datalayout.

There is a risk of bitcode incompatibilities with this change, but we already have that the code we generate now is incompatible with GCC and results in crashes that way too, I don't think there's a perfect fix, I'd like it if we could merge this. I came up with roughly the same patch today, based on current sources, to fix bug #50198 before finding this one.

Tue, May 4, 12:52 PM · Restricted Project

Sun, May 2

hvdijk added a comment to D63423: [Diagnostics] Diagnose misused xor as pow.

Perhaps that should warn even if the RHS is in hex form

It would be kinda strange, since in one clang release we ask users to silence warning with hex form and newer release would warn anyway. Not a fan of this decision.

Sun, May 2, 11:00 AM · Restricted Project, Restricted Project
hvdijk added a comment to D63423: [Diagnostics] Diagnose misused xor as pow.

No, we want to preserve warning for 2 ^ MACRO or 10 ^ MACRO.

Sun, May 2, 10:33 AM · Restricted Project, Restricted Project
hvdijk added a comment to D63423: [Diagnostics] Diagnose misused xor as pow.

I remember that was interest to support macros too :) tbh I cant remember now such real world case where “macro ^ cst” was an issue but.. it was a long time ago ;)

If you are want, you can send patch to to avoid warning in this case, we can discuss it.

Sun, May 2, 10:14 AM · Restricted Project, Restricted Project
hvdijk added a comment to D63423: [Diagnostics] Diagnose misused xor as pow.

It's bad enough that this warns for

#define A 2
int f() { return A ^ 1; }

where as far as the users of A are concerned...

I see how this warning is arguably overzealous in the very special case of "raising" to the constant 1 (since nobody would ever write that by accident). However, if the user of A wants to indicate that they understand this is bitwise-xor, they can simply change the body of their f to return A ^ 0x1; — hex notation suppresses the warning. (Changing the definition of A as well is perhaps a good idea but not technically required.) IMO this is good enough and we should leave it. (What do you think, having seen the A ^ 0x1 workaround? Does that sufficiently address your needs?)

Sun, May 2, 9:50 AM · Restricted Project, Restricted Project
hvdijk added a comment to D63423: [Diagnostics] Diagnose misused xor as pow.

It's bad enough that this warns for

Sun, May 2, 9:26 AM · Restricted Project, Restricted Project

Sat, May 1

hvdijk committed rGf30500632b29: [X32][CET] Fix size and alignment of .note.gnu.property section (authored by hvdijk).
[X32][CET] Fix size and alignment of .note.gnu.property section
Sat, May 1, 2:17 PM
hvdijk closed D101689: [X32][CET] Fix size and alignment of .note.gnu.property section.
Sat, May 1, 2:17 PM · Restricted Project
hvdijk added inline comments to D101689: [X32][CET] Fix size and alignment of .note.gnu.property section.
Sat, May 1, 2:11 PM · Restricted Project
hvdijk updated the diff for D101689: [X32][CET] Fix size and alignment of .note.gnu.property section.

It wasn't just the alignment that was wrong, the section contains its own size as a field, which had an incorrect value as a result of the alignment.

Sat, May 1, 2:10 PM · Restricted Project
hvdijk requested review of D101689: [X32][CET] Fix size and alignment of .note.gnu.property section.
Sat, May 1, 5:33 AM · Restricted Project

Thu, Apr 29

hvdijk committed rG1b788607f549: [X32][CET] Fix handling of indirect branches (authored by hvdijk).
[X32][CET] Fix handling of indirect branches
Thu, Apr 29, 12:34 AM
hvdijk closed D101499: [X32][CET] Fix handling of indirect branches.
Thu, Apr 29, 12:34 AM · Restricted Project

Wed, Apr 28

hvdijk requested review of D101499: [X32][CET] Fix handling of indirect branches.
Wed, Apr 28, 4:59 PM · Restricted Project

Tue, Apr 27

Herald added a project to D50490: Restore correct x86_64 EH encodings in kernel code model: Restricted Project.
Tue, Apr 27, 3:42 PM · Restricted Project

Apr 14 2021

hvdijk added a reverting change for rG4d9ccb18f508: Title: [RISCV] Add missing part of instruction vmsge {u}. VX Review By: craig.: rGe1e2c9d40460: Revert "Title: [RISCV] Add missing part of instruction vmsge {u}. VX Review By….
Apr 14 2021, 12:05 AM
hvdijk committed rGe1e2c9d40460: Revert "Title: [RISCV] Add missing part of instruction vmsge {u}. VX Review By… (authored by hvdijk).
Revert "Title: [RISCV] Add missing part of instruction vmsge {u}. VX Review By…
Apr 14 2021, 12:05 AM

Apr 12 2021

hvdijk added a comment to D100148: [Driver] Fix compiler-rt lookup for x32.

Understood. However, I'm not really sure what else we need. Do we just take the architecture definition from here to pass the proper flags to the compiler or do we also need to add
some x32-specific code?

Apr 12 2021, 11:12 AM · Restricted Project
hvdijk added a comment to D100148: [Driver] Fix compiler-rt lookup for x32.

Hi! Can we get this patch merged as-is or do we need anything else?

Apr 12 2021, 10:53 AM · Restricted Project

Apr 9 2021

hvdijk added inline comments to D100148: [Driver] Fix compiler-rt lookup for x32.
Apr 9 2021, 3:38 AM · Restricted Project

Apr 8 2021

hvdijk requested review of D100148: [Driver] Fix compiler-rt lookup for x32.
Apr 8 2021, 3:46 PM · Restricted Project
hvdijk added a comment to D99988: [compiler-rt] Add platform detection support for x32.

Ah, that looks at first glance like not a compiler-rt problem but a clang problem, it will need to be taught the correct target name for x32 as well. If I'm right, that should be easy to fix, I can take a look later today or tomorrow.

Apr 8 2021, 9:23 AM · Restricted Project

Apr 6 2021

hvdijk added a comment to D99988: [compiler-rt] Add platform detection support for x32.

I think x32 is not really supported by compiler-rt.

Apr 6 2021, 3:10 PM · Restricted Project
hvdijk added a comment to D99988: [compiler-rt] Add platform detection support for x32.

Does this change mean the various *_SUPPORTED_ARCH need updating to list x32 as supported too, or are those handled separately?

Apr 6 2021, 2:52 PM · Restricted Project

Apr 1 2021

hvdijk added a comment to D52050: [Driver] Fix architecture triplets and search paths for Linux x32.

I think, however, we should bump the rest of the paths to 10.2.0 if possible.

Apr 1 2021, 1:58 AM · Restricted Project
hvdijk committed rG1d463c2a3860: [Driver] Fix architecture triplets and search paths for Linux x32 (authored by hvdijk).
[Driver] Fix architecture triplets and search paths for Linux x32
Apr 1 2021, 1:50 AM
hvdijk closed D52050: [Driver] Fix architecture triplets and search paths for Linux x32.
Apr 1 2021, 1:50 AM · Restricted Project

Mar 31 2021

hvdijk updated the diff for D52050: [Driver] Fix architecture triplets and search paths for Linux x32.

I have also updated the summary to provide a more complete explanation of the changes, and hope the revised summary will answer @MaskRay's questions.

Mar 31 2021, 4:27 PM · Restricted Project
hvdijk added a comment to D52050: [Driver] Fix architecture triplets and search paths for Linux x32.

Since I am a big fan of consistency, I would rather leave it as is (4.6) and then bump to 10.2.0 in a follow-up commit.

Mar 31 2021, 4:22 PM · Restricted Project
hvdijk added a comment to D52050: [Driver] Fix architecture triplets and search paths for Linux x32.

Mostly looks good.

clang/test/Driver/Inputs/basic_cross_linux_tree/usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/x32/crtbegin.o

Worth bumping the version. 4.6 is quite old and as a host compiler llvm-project has stopped supporting it. The distributions having 4.6 are all end-of-life.
Using a new version (matching your reality) can give impression that the user who contributed the original code may still need it for a while (say 5 years).

Mar 31 2021, 2:18 PM · Restricted Project
hvdijk updated the diff for D52050: [Driver] Fix architecture triplets and search paths for Linux x32.

Tests now updated differently, avoiding the need to explicitly list libx32 as an allowed libdir. In clang/test/Preprocessor/iwithprefix.c's case, for the purposes of the test, it is not necessary to look at what appears before /clang/. In the other tests, it is possible to capture the -resource-dir string and use that.

Mar 31 2021, 12:02 PM · Restricted Project
hvdijk added inline comments to D52050: [Driver] Fix architecture triplets and search paths for Linux x32.
Mar 31 2021, 1:31 AM · Restricted Project
hvdijk added inline comments to D52050: [Driver] Fix architecture triplets and search paths for Linux x32.
Mar 31 2021, 1:04 AM · Restricted Project
hvdijk added inline comments to D52050: [Driver] Fix architecture triplets and search paths for Linux x32.
Mar 31 2021, 12:38 AM · Restricted Project
hvdijk added inline comments to D52050: [Driver] Fix architecture triplets and search paths for Linux x32.
Mar 31 2021, 12:34 AM · Restricted Project
hvdijk updated the diff for D52050: [Driver] Fix architecture triplets and search paths for Linux x32.

This updates the diff as described, plus includes test suite changes needed to make check-clang pass. The changes to clang/test/Driver/Inputs/basic_cross_linux_tree/usr are because we now correctly detect that a x86_64 GCC directory that does not include x32 files cannot be used to target x32.

Mar 31 2021, 12:21 AM · Restricted Project
hvdijk commandeered D52050: [Driver] Fix architecture triplets and search paths for Linux x32.

Feel free to update the diff here with your suggested patch.

Mar 31 2021, 12:19 AM · Restricted Project

Mar 30 2021

hvdijk added a comment to D99625: llvm/cmake/config.guess: update to current version.

If that were the reason, why are we not using the last GPLv2 version of config.guess, rather than the one that we happened to use back when we had an autoconf build system?

Mar 30 2021, 11:38 PM · Restricted Project
hvdijk added a comment to D52050: [Driver] Fix architecture triplets and search paths for Linux x32.

I think the problem is actually the other thing covered before (don't provide un-normalised triples as cmake arguments), though the wrong detection of LLVM_HOST_TRIPLE will cause other issues too. If we would just update config.guess, the default configuration (not specifying either LLVM_HOST_TRIPLE or LLVM_DEFAULT_TARGET_TRIPLE) should work much better; I have created D99625 for that.

Mar 30 2021, 3:37 PM · Restricted Project
hvdijk requested review of D99625: llvm/cmake/config.guess: update to current version.
Mar 30 2021, 3:33 PM · Restricted Project
hvdijk added a comment to D52050: [Driver] Fix architecture triplets and search paths for Linux x32.

I am building with

Mar 30 2021, 1:53 PM · Restricted Project
hvdijk added a comment to D52050: [Driver] Fix architecture triplets and search paths for Linux x32.

I am testing the below, on top of c8e56f394af0b9e32c413d62a0e7aebbba3e6b70, both in a Debian chroot and in my non-Debian system. Initial testing in the Debian chroot suggests that this works for simple cases, clang has no problem finding /usr/lib/gcc/x86_64-linux-gnux32/10, and also picks up the right crt*.o files when using -m32 or -m64. Will do more extensive testing.

--- a/clang/lib/Driver/ToolChains/Gnu.cpp
+++ b/clang/lib/Driver/ToolChains/Gnu.cpp
@@ -2106,7 +2106,10 @@ void Generic_GCC::GCCInstallationDetector::AddDefaultGCCPrefixes(
       "x86_64-manbo-linux-gnu", "x86_64-linux-gnu",
       "x86_64-slackware-linux", "x86_64-unknown-linux",
       "x86_64-amazon-linux",    "x86_64-linux-android"};
-  static const char *const X32LibDirs[] = {"/libx32"};
+  static const char *const X32Triples[] = {
+      "x86_64-linux-gnux32",    "x86_64-unknown-linux-gnux32",
+      "x86_64-pc-linux-gnux32"};
+  static const char *const X32LibDirs[] = {"/libx32", "/lib"};
   static const char *const X86LibDirs[] = {"/lib32", "/lib"};
   static const char *const X86Triples[] = {
       "i586-linux-gnu",     "i686-linux-gnu",
@@ -2337,17 +2340,19 @@ void Generic_GCC::GCCInstallationDetector::AddDefaultGCCPrefixes(
     TripleAliases.append(begin(AVRTriples), end(AVRTriples));
     break;
   case llvm::Triple::x86_64:
-    LibDirs.append(begin(X86_64LibDirs), end(X86_64LibDirs));
-    TripleAliases.append(begin(X86_64Triples), end(X86_64Triples));
-    // x32 is always available when x86_64 is available, so adding it as
-    // secondary arch with x86_64 triples
     if (TargetTriple.getEnvironment() == llvm::Triple::GNUX32) {
-      BiarchLibDirs.append(begin(X32LibDirs), end(X32LibDirs));
+      LibDirs.append(begin(X32LibDirs), end(X32LibDirs));
+      TripleAliases.append(begin(X32Triples), end(X32Triples));
+      BiarchLibDirs.append(begin(X86_64LibDirs), end(X86_64LibDirs));
       BiarchTripleAliases.append(begin(X86_64Triples), end(X86_64Triples));
     } else {
-      BiarchLibDirs.append(begin(X86LibDirs), end(X86LibDirs));
-      BiarchTripleAliases.append(begin(X86Triples), end(X86Triples));
+      LibDirs.append(begin(X86_64LibDirs), end(X86_64LibDirs));
+      TripleAliases.append(begin(X86_64Triples), end(X86_64Triples));
+      BiarchLibDirs.append(begin(X32LibDirs), end(X32LibDirs));
+      BiarchTripleAliases.append(begin(X32Triples), end(X32Triples));
     }
+    BiarchLibDirs.append(begin(X86LibDirs), end(X86LibDirs));
+    BiarchTripleAliases.append(begin(X86Triples), end(X86Triples));
     break;
   case llvm::Triple::x86:
     LibDirs.append(begin(X86LibDirs), end(X86LibDirs));
@@ -2357,6 +2362,8 @@ void Generic_GCC::GCCInstallationDetector::AddDefaultGCCPrefixes(
       TripleAliases.append(begin(X86Triples), end(X86Triples));
       BiarchLibDirs.append(begin(X86_64LibDirs), end(X86_64LibDirs));
       BiarchTripleAliases.append(begin(X86_64Triples), end(X86_64Triples));
+      BiarchLibDirs.append(begin(X32LibDirs), end(X32LibDirs));
+      BiarchTripleAliases.append(begin(X32Triples), end(X32Triples));
     }
     break;
   case llvm::Triple::m68k:
Mar 30 2021, 1:08 PM · Restricted Project
hvdijk added a comment to D52050: [Driver] Fix architecture triplets and search paths for Linux x32.

I may be missing something, but I do not understand the problem. What systems, other than Debian multi-arch, are you looking to also add support for? My own native x32 system uses (/usr)/libx32 for x32 libraries. Debian uses (/usr)/lib/x86_64-linux-gnux32. I can understand if some people might use (/usr)/lib without any x32 suffix, though I am not aware of anyone doing this. Where does lib32 come from, though? What other systems are you trying to account for?

Mar 30 2021, 2:21 AM · Restricted Project

Jan 30 2021

hvdijk committed rGb01b964d3776: [compiler-rt][tests] Define TARGET_FLAGS (authored by hvdijk).
[compiler-rt][tests] Define TARGET_FLAGS
Jan 30 2021, 5:06 AM
hvdijk closed D93634: [compiler-rt][tests] Define TARGET_FLAGS.
Jan 30 2021, 5:06 AM · Restricted Project

Jan 27 2021

hvdijk added a comment to D91913: Suppress non-conforming GNU paste extension in all standard-conforming modes.

If I'm reading git correctly, the change is still present on the 12.x branch. Should it be reverted there too?

Jan 27 2021, 5:00 PM · Restricted Project
hvdijk added a comment to D91913: Suppress non-conforming GNU paste extension in all standard-conforming modes.
In D91913#2526403, @rnk wrote:

Anyway, I apologize for the misunderstanding. I'm doing my best to operate in good faith with LLVM project policies. Hopefully you feel that you have a path forward here.

Jan 27 2021, 2:19 PM · Restricted Project
hvdijk added a comment to D91913: Suppress non-conforming GNU paste extension in all standard-conforming modes.

I think @rnk's observation that __VA_OPT__ isn't actually available in any compilation mode other than C++20 (which I hadn't previously realized) is important here: we'd left longstanding users of this functionality with no path forward, and that is, I think, sufficient motivation for a revert.

Jan 27 2021, 1:51 PM · Restricted Project
hvdijk added a comment to D91913: Suppress non-conforming GNU paste extension in all standard-conforming modes.

@rnk Taking it upon yourself to revert this without approval and without communication on all branches, especially given the earlier suggestion by @rsmith to only revert this on the LLVM 12 branch, is an abuse of your commit privileges as far as I am concerned. This is not a Google project. Google does not get to unilaterally dictate its direction. I do not intend to get into a revert-the-revert war and will not revert your revert myself. I do expect you to do so.

Jan 27 2021, 11:17 AM · Restricted Project

Jan 26 2021

hvdijk added a comment to D91913: Suppress non-conforming GNU paste extension in all standard-conforming modes.

Restoring the old behaviour for clang 12 may or may not help the Chrome/Chromium people: if they also regularly build with clang from git, they would need to handle this change anyway. However, if it does help, then it sounds like a good idea to me.

Jan 26 2021, 2:12 AM · Restricted Project

Jan 25 2021

hvdijk committed rGb43c26d036dc: Restore GNU , ## __VA_ARGS__ behavior in MSVC mode (authored by hvdijk).
Restore GNU , ## __VA_ARGS__ behavior in MSVC mode
Jan 25 2021, 2:35 PM
hvdijk closed D95392: Restore GNU , ## __VA_ARGS__ behavior in MSVC mode.
Jan 25 2021, 2:35 PM · Restricted Project, Restricted Project
hvdijk retitled D95392: Restore GNU , ## __VA_ARGS__ behavior in MSVC mode from Restore GNU , ## __VA_ARGS__ behavior in MSVC mode too to Restore GNU , ## __VA_ARGS__ behavior in MSVC mode.
Jan 25 2021, 1:52 PM · Restricted Project, Restricted Project
hvdijk added a comment to D91913: Suppress non-conforming GNU paste extension in all standard-conforming modes.

We (and every other project out there) needs some incremental rollout plan for this.

Jan 25 2021, 1:51 PM · Restricted Project
hvdijk requested review of D95392: Restore GNU , ## __VA_ARGS__ behavior in MSVC mode.
Jan 25 2021, 1:49 PM · Restricted Project, Restricted Project
hvdijk added a comment to D91913: Suppress non-conforming GNU paste extension in all standard-conforming modes.

This change also breaks many chrome ToT bots(not just windows bot), example build: https://ci.chromium.org/ui/p/chrome/builders/ci/ToTLinuxOfficial/10524/steps?succeeded=true&debug=false

That requires an account to see.

This should be accessible without an account: https://logs.chromium.org/logs/chromium/buildbucket/cr-buildbucket.appspot.com/8857139118288337920/+/steps/compile/0/stdout

Jan 25 2021, 10:32 AM · Restricted Project
hvdijk added a comment to D91913: Suppress non-conforming GNU paste extension in all standard-conforming modes.

This change also breaks many chrome ToT bots(not just windows bot), example build: https://ci.chromium.org/ui/p/chrome/builders/ci/ToTLinuxOfficial/10524/steps?succeeded=true&debug=false

Jan 25 2021, 10:04 AM · Restricted Project
hvdijk added a comment to D91913: Suppress non-conforming GNU paste extension in all standard-conforming modes.

Okay, GCC enables the standards-mandated behaviour with -std=c++17 -fms-extensions as well, but GCC doesn't have any -fms-compatibility option to compare. It makes sense to me for clang -std=c++17 -fms-compatibility to match MSVC, and MSVC supports this GCC extension even in those cases where it conflicts with the standard, so I'll try to submit a patch to restore this, conditional on -fms-compatibility, later today.

Jan 25 2021, 9:33 AM · Restricted Project
hvdijk added a comment to D91913: Suppress non-conforming GNU paste extension in all standard-conforming modes.

We have a downstream build break due to this commit. One of our files has some convoluted arg-counting logic that now returns a different count, which does not match gcc: https://godbolt.org/z/W8caMr (Note: At time of writing, the clang trunk on godbolt doesn't yet have this change.)

Jan 25 2021, 9:16 AM · Restricted Project

Jan 24 2021

hvdijk added a comment to D91913: Suppress non-conforming GNU paste extension in all standard-conforming modes.

Looks like this change matches the behavior of GCC all the way back to at least GCC 4.1.

Jan 24 2021, 4:57 PM · Restricted Project
hvdijk committed rGf4537935dcdb: Suppress non-conforming GNU paste extension in all standard-conforming modes (authored by hvdijk).
Suppress non-conforming GNU paste extension in all standard-conforming modes
Jan 24 2021, 4:57 PM
hvdijk closed D91913: Suppress non-conforming GNU paste extension in all standard-conforming modes.
Jan 24 2021, 4:57 PM · Restricted Project
hvdijk added a comment to D93634: [compiler-rt][tests] Define TARGET_FLAGS.

Ping 2

Jan 24 2021, 3:47 AM · Restricted Project
hvdijk added a comment to D91913: Suppress non-conforming GNU paste extension in all standard-conforming modes.

Ping 4

Jan 24 2021, 3:47 AM · Restricted Project

Jan 11 2021

hvdijk added a comment to D93634: [compiler-rt][tests] Define TARGET_FLAGS.

Ping

Jan 11 2021, 2:02 PM · Restricted Project
hvdijk added a comment to D91913: Suppress non-conforming GNU paste extension in all standard-conforming modes.

Ping 3

Jan 11 2021, 2:02 PM · Restricted Project

Dec 22 2020

hvdijk added a comment to D52050: [Driver] Fix architecture triplets and search paths for Linux x32.

However, that's not the same as whether we're on an x86_64 system or on an x32 system determines which GNU triplet to use and which include and library search paths are our primary ones.

Dec 22 2020, 8:52 AM · Restricted Project

Dec 21 2020

hvdijk added a comment to D91913: Suppress non-conforming GNU paste extension in all standard-conforming modes.

Ping 2

Dec 21 2020, 7:13 AM · Restricted Project
hvdijk requested review of D93634: [compiler-rt][tests] Define TARGET_FLAGS.
Dec 21 2020, 7:12 AM · Restricted Project

Dec 20 2020

hvdijk added inline comments to D93209: [libObject, llvm-readobj] - Reimplement `ELFFile<ELFT>::getEntry`..
Dec 20 2020, 10:26 AM · Restricted Project

Dec 18 2020

hvdijk added inline comments to D93561: [X86] Avoid generating invalid R_X86_64_GOTPCRELX relocations.
Dec 18 2020, 3:40 PM · Restricted Project
hvdijk committed rGadc55b5a5ae4: [X86] Avoid generating invalid R_X86_64_GOTPCRELX relocations (authored by hvdijk).
[X86] Avoid generating invalid R_X86_64_GOTPCRELX relocations
Dec 18 2020, 3:39 PM
hvdijk closed D93561: [X86] Avoid generating invalid R_X86_64_GOTPCRELX relocations.
Dec 18 2020, 3:39 PM · Restricted Project
hvdijk added a comment to D93561: [X86] Avoid generating invalid R_X86_64_GOTPCRELX relocations.

The lld/test/ELF tests need fixing (check-lld-elf)

Dec 18 2020, 2:32 PM · Restricted Project
hvdijk updated the diff for D93561: [X86] Avoid generating invalid R_X86_64_GOTPCRELX relocations.

Merge ELF/got-relaxed-rex.s into X86/gotpcrelx.s, update lld/test/ELF/x86-64-gotpc-relax-nopic.s.

Dec 18 2020, 2:30 PM · Restricted Project
hvdijk requested review of D93561: [X86] Avoid generating invalid R_X86_64_GOTPCRELX relocations.
Dec 18 2020, 12:29 PM · Restricted Project
hvdijk closed D93159: [X86] Add REX prefix for GOTTPOFF/TLSDESC relocs in x32 mode.

I accidentally pushed this with the original commit message as 2aae2136, causing a missing link to/from this review. Manually linking this here now.

Dec 18 2020, 12:20 PM · Restricted Project