Page MenuHomePhabricator

Ericson2314 (John Ericson)
User

Projects

User does not belong to any projects.

User Details

User Since
Mar 16 2018, 2:30 PM (90 w, 4 d)

Recent Activity

Nov 8 2019

Ericson2314 abandoned D69769: [Driver] Don't pun -fuse-ld=lld as -fuse-ld=lld-link with msvc.

OK abandoning this too. Thanks for the extra info.

Nov 8 2019, 2:15 PM · Restricted Project
Ericson2314 abandoned D69768: [MinGW] Support --allow-multiple-definition.

OK I'll close both backports.

Nov 8 2019, 2:15 PM · Restricted Project
Ericson2314 reclaimed D69760: [Clang][Driver] Don't pun -fuse-ld=lld as -fuse-ld=lld-link with msvc.
Nov 8 2019, 2:15 PM · Restricted Project, Restricted Project
Ericson2314 abandoned D69760: [Clang][Driver] Don't pun -fuse-ld=lld as -fuse-ld=lld-link with msvc.
Nov 8 2019, 2:15 PM · Restricted Project, Restricted Project
Ericson2314 added a comment to D69766: [Clang][MSVC] Use GetLinkerPath like the other toolchains for consistency.

Reading https://llvm.org/docs/DeveloperPolicy.html it looks like I need to submit an patch email? Is that true, or can/will someone with perms see the approval and eventually merge it from phabricator?

Nov 8 2019, 10:17 AM · Restricted Project
Ericson2314 added a comment to D69760: [Clang][Driver] Don't pun -fuse-ld=lld as -fuse-ld=lld-link with msvc.

While I am fine making -fuse-ld=lld mean "use that lld driver most appropriate for the clang driver", in principle the clang driver and lld driver choices are orthogonal, and I'd want to expose that with something like -fuse-ld=ld.lld to compliment -fuse-ld=lld-link. How does that sound? Should we support -fuse-ld=ld.bfd and -fuse-ld=ld64.lld too?

Nov 8 2019, 10:08 AM · Restricted Project, Restricted Project

Nov 4 2019

Ericson2314 added a comment to D69763: [Clang][Test]: Remaining "lld-link2" -> "lld-link".

I am curious, how did this work since there is no longer an lld-link2? Were these tests failing or not being run?

Nov 4 2019, 4:51 PM · Restricted Project

Nov 3 2019

Ericson2314 retitled D69769: [Driver] Don't pun -fuse-ld=lld as -fuse-ld=lld-link with msvc from [Clang][Driver] Don't pun -fuse-ld=lld as -fuse-ld=lld-link with msvc to [Driver] Don't pun -fuse-ld=lld as -fuse-ld=lld-link with msvc.
Nov 3 2019, 2:45 PM · Restricted Project
Ericson2314 created D69769: [Driver] Don't pun -fuse-ld=lld as -fuse-ld=lld-link with msvc.
Nov 3 2019, 11:34 AM · Restricted Project
Ericson2314 updated the summary of D69768: [MinGW] Support --allow-multiple-definition.
Nov 3 2019, 10:52 AM · Restricted Project
Ericson2314 created D69768: [MinGW] Support --allow-multiple-definition.
Nov 3 2019, 10:48 AM · Restricted Project
Ericson2314 added a child revision for D69767: [LLD][MinGW] Support --allow-multiple-definition: D69760: [Clang][Driver] Don't pun -fuse-ld=lld as -fuse-ld=lld-link with msvc.
Nov 3 2019, 9:22 AM · Restricted Project
Ericson2314 added a parent revision for D69760: [Clang][Driver] Don't pun -fuse-ld=lld as -fuse-ld=lld-link with msvc: D69767: [LLD][MinGW] Support --allow-multiple-definition.
Nov 3 2019, 9:22 AM · Restricted Project, Restricted Project
Ericson2314 retitled D69760: [Clang][Driver] Don't pun -fuse-ld=lld as -fuse-ld=lld-link with msvc from Clang][Driver] Don't pun -fuse-ld=lld as -fuse-ld=lld-link with msvc to [Clang][Driver] Don't pun -fuse-ld=lld as -fuse-ld=lld-link with msvc.
Nov 3 2019, 9:16 AM · Restricted Project, Restricted Project
Ericson2314 updated the diff for D69760: [Clang][Driver] Don't pun -fuse-ld=lld as -fuse-ld=lld-link with msvc.

Split out some changes into other diffs. 1 we are stacked on, the other 2 are independent and not stacked on,

Nov 3 2019, 9:16 AM · Restricted Project, Restricted Project
Ericson2314 created D69767: [LLD][MinGW] Support --allow-multiple-definition.
Nov 3 2019, 9:04 AM · Restricted Project
Ericson2314 created D69766: [Clang][MSVC] Use GetLinkerPath like the other toolchains for consistency.
Nov 3 2019, 8:59 AM · Restricted Project
Ericson2314 created D69763: [Clang][Test]: Remaining "lld-link2" -> "lld-link".
Nov 3 2019, 7:37 AM · Restricted Project
Ericson2314 retitled D69760: [Clang][Driver] Don't pun -fuse-ld=lld as -fuse-ld=lld-link with msvc from [LLD][MinGW] Support --allow-multiple-definition to Better clang cross windows with gnu-style flags.
Nov 3 2019, 1:26 AM · Restricted Project, Restricted Project
Ericson2314 created D69760: [Clang][Driver] Don't pun -fuse-ld=lld as -fuse-ld=lld-link with msvc.
Nov 3 2019, 1:07 AM · Restricted Project, Restricted Project

Apr 17 2019

Ericson2314 added inline comments to D60812: Don't error on CMAKE_SYSTEM_NAME=Wasi.
Apr 17 2019, 8:47 AM · Restricted Project

Mar 23 2018

Ericson2314 added a comment to D44753: [Preprocessor] Rename __is_{target -> host}_* function-like builtin macros.

Bummer, I didn't realize this had already shipped.

Mar 23 2018, 8:36 AM

Mar 22 2018

Ericson2314 added a comment to D44753: [Preprocessor] Rename __is_{target -> host}_* function-like builtin macros.

OK I'll happily admit that Autoconf's choices of names is terrible, and that, yes, the names can be defined from two differing perspectives. And, I actually do believe the GCC build system is far inferior, too. But on other points I think we're all talking past each other.

Mar 22 2018, 10:29 AM

Mar 21 2018

Ericson2314 added a comment to D44753: [Preprocessor] Rename __is_{target -> host}_* function-like builtin macros.

@steven_wu Maybe there is something outside of "build" "host" or "target" that won't suffer from these problems of vantage point? __will_be_built_for_* for a very lengthy example, but hopefully something shorter too?

Mar 21 2018, 4:37 PM
Ericson2314 added a comment to D44753: [Preprocessor] Rename __is_{target -> host}_* function-like builtin macros.

I'm sure I could fine a GCC example

Mar 21 2018, 3:10 PM
Ericson2314 added a comment to D44753: [Preprocessor] Rename __is_{target -> host}_* function-like builtin macros.

@steven_wu but what you say is directly contradicted by the GHC example. I'm sure I could fine a GCC example too where some macro with "target" is in the name affects the target of the compiler being built. In the vast majority of programs, no more than one platform need affect preprocessing, but when multiple platforms affect preprocessing, they are *always* named from the perspective of the being-built tool being run.

Mar 21 2018, 2:46 PM
Ericson2314 added a comment to D44753: [Preprocessor] Rename __is_{target -> host}_* function-like builtin macros.

One that that might make my position clearer is to substitute the name "build", "host", and "target" for "build", "run", and "emit". [A colleague of mine proposed these alternative names and I do think they are vastly more human friendly.]

Mar 21 2018, 2:38 PM
Ericson2314 added a comment to D44753: [Preprocessor] Rename __is_{target -> host}_* function-like builtin macros.

Sorry that I missed your earlier comment about this. The confusion could only arise in the context of a tool (like a compiler) that is being used for cross-compilation. That is a small fraction of the audience for Clang, and we should design this in a way that makes the most sense for the majority of users. If there's a naming scheme that is better for both, then we should do that, but I don't think this is it.

Mar 21 2018, 2:11 PM
Ericson2314 created D44753: [Preprocessor] Rename __is_{target -> host}_* function-like builtin macros.
Mar 21 2018, 1:01 PM