Tue, Jun 4
As trivial as it may seem, this is missing tests, even if it's for a few flags. Also please try to include context with your patches as it makes them much easier to review. If you have some sort of plan for actually bringing Mach-O LLD closer to ld64 feature-wise, I think llvm-dev may be a good place to actually outline your plan for this, which will give everyone a more clear picture of what future changes you have planned in mind.
Experienced the same, updated my test build configuration to always force CLANG_ENABLE_STATIC_ANALYZER to On when building with tests. Maybe it's worth adding a warning about when Clang tests are being built?
Tue, May 28
Would it make sense to also add a test explicitly using llvm::hash_combine
Using llvm::hash_combine on what, exactly?
as well as a negative test where hash code comparison fails for a literal and the same literal in a StringRef every time
You mean something like ASSERT_NE(SymName1.data(), SymName2.data());?
Sat, May 25
I have a question about qsort.. If we provide own implementation of qsort and replace calls to libc's qsort to our qsort, we could fully inline cmp function then. Ideas?
Seems good. Would it make sense to also add a test explicitly using llvm::hash_combine, as well as a negative test where hash code comparison fails for a literal and the same literal in a StringRef every time (if it's possible to do reliably)? Just a random suggestion, probably overly paranoid.
May 16 2019
My bad, I didn't check well enough, it seems an unrelated patch made certain tests crash due to asserts. Thanks to @craig.topper for pointing that out.
This seems to be causing multiple performance regressions across several bots in compile time and execution time tests.
Revised to use llvm::sys::path::filename to avoid issues on Windows hosts.
May 15 2019
Reverted in rL360842 as Windows bots were failing.
Landing this as discussed on IRC, will try to push it forward with WG14.
May 10 2019
Need @rsmith to bless this as it's introducing a nonstandard extension, however small it may be. The original diff did have a consensus on it, so I didn't really put up a formal RFC on cfe-dev.
Actually I got it wrong, the path is normalized to use regular slashes at that point, so there is no point in handling backslashes in paths at all even with Microsoft extensions.
May 9 2019
Fix style, remove unnecessary braces, add missing newline.
Superseded by D61756
May 8 2019
Sorry, forgot about this, will make a new diff with just the macro for review later tonight.
Apr 9 2019
Apr 5 2019
Mar 12 2019
I did, there are no references to any PassManager related material in the first three chapters.
Please make sure to specify Differential Revision: https://reviews.llvm.org/D59243 with Dxxxxx being the differential number in the URL when committing (on a separate line in the commit message) which will autmatically close the differential and link it to the commit which makes sure there are no stray/stale differentials. Alternatively manually link the diff to the commit (you can do that by simply quoting the commit as rL<SVN Rev> and then closing the differential manually.
Mar 11 2019
Mar 3 2019
Feb 28 2019
If the author is still missing at the end of next week, any objections to me resubmitting a similar patch that just implements __FILE_NAME__ or __BASE_NAME__ (Need a few more opinions here I guess, personally I think __FILE_NAME__ makes more sense)?
Feb 27 2019
Gentle ping for author, has this landed or still in the backlog? (If it's landed can you attach the commit and close it, please? Just trying to to avoid diffs on Phab going stale.)
What about using /*/ at the ignore pattern? This allows top-level files, and makes only new top-level *directories* require an ignore update. To my mind, that seems a bit more narrowly scoped and might be a bit less surprising. Thoughts?
Feb 26 2019
Feb 25 2019
@RalfJung Do you need someone to commit this? I can do it if you'd like.
Please make sure you have llvm-commits added as a subscriber when creating patches in the future (I'm not sure why Herald sometimes doesn't do it). The patch that changed this was rL322965, and I fixed one of the related regressions, and was meaning to update the docs but never did, so LGTM and I'm happy signing off on this.
Feb 24 2019
Feb 16 2019
I still don't like it...It's different, unusual, and IMO surprising to have such a wildcard ignore.
We haven't tended to have lots of random accidental file additions before, and while someone may surely mess up again, I don't think it likely to be a common occurrence.
I'd much prefer simply the targeted ignore of "/build*", at least for starters.
I'm in favor of this and I agree with @pcc's points and reasoning behind this.
Feb 15 2019
I actually like the D57400 approach more, it's much easier to keep a list of known top level projects as a whitelist. There are many names people could give to such a build directory (out or build or b) not to mention any other cruft one may have there. (ie. I build a libc as part of toolchain build).
Feb 6 2019
The patch itself looks sound. However given that you have a specific use case in mind (TableGen files) could you provide supplementary coverage for that specific use case (unit tests for formatting td syntax using format::getLLVMStyle(format::FormatStyle::LK_TableGen)? I'm not entirely sure how useful this particular change is given that there's no linked patches related to your use case, I think adding those would help as well (possibly as a separate dependent patchset).
Jan 29 2019
FWIW, this also broke my bootstraps of mingw-w64 environments/toolchains. After building compiler-rt builtins, before having any libunwind/libcxx built, I previously regarded my toolchain as complete for building and testing C apps and libraries, but that fails now.
Would it be possible to add a third alternative, --unwindlib=none, to signal that while I'm using --rtlib=compiler-rt, I don't want to link to any unwinder? (In my case, I'm injecting libunwind in libc++.a so it only gets added when linking C++ code.) Or at least make it possible to only add this linker flag when linking C++? Alternatively I'll need to provide a dummy libunwind.a until the real one has been built.
Jan 28 2019
One more thing, shouldn't libunwind be only included for C++ (since it's the internal dependency of libc++abi)? There shouldn't be any need to include it for C.
Jan 20 2019
Revised, landing it without split stack stuff, should autoupdate the revision here.
Jan 19 2019
Jan 18 2019
Jan 17 2019
LGTM if GAS does allow multiple uses of .set to change the value. One nit on the test, can you add a case where you don't have an .if directive like:
Jan 14 2019
Going to test and land it as requested by @lebedev.ri on IRC.
Jan 13 2019
Currently actual tests would require using libgcc, as compiler-rt does not support split stack yet. If libgcc is required for tests then I don't think I can accurately make one. So if you require a test for this, it's likely that I'll have to mark this as "Changes Planned" for now until compiler-rt is sufficient to link this, unfortunately. Up to you really, though in my opinion even without tests this is better than it failing to compile. And the reasons for avoiding libgcc are fairly complicated, my intentions currently are to stay as far away from GNU runtime components as possible.
FWIW, I completely support landing this. I think the opposition is essentially "it would be better to not design a libc in that way" which is certainly a valid opinion, but given the existence of such libc designs widely deployed and widely used, it seems very good to lay groundwork for LLVM to support them.
I also think we should *not* be pointing at GNU or any other project here, and instead simply state that these exist to support using LLVM in conjunction with systems whose libc chooses this particular design pattern.
I don't think LLVM should be in the business of trying to cast some kind of "you should feel bad" judgement on such systems. If someone in the LLVM community wants to develop a libc as part of LLVM (which I would quite like to see), then that is the place to debate libc design decisions, and not anywhere else.
So, that said, does anyone have comments on the code itself? If no one is up to commenting on the code and giving Petr direct feedback there, I'll just LGTM this because I think it is long (looooooong) overdue.
Lastly, to address specific questions here:
That's fine, it's just not the state of the world and we should support compiling appropriately.
I don't want to pick a fight, but there can be used exactly same argument to defend pulling libgcc here.
That doesn't make sense to me -- the LLVM project has lots of reasons why it doesn't pull GPL-ed code into its tree.
But yes, we are going to be in the business of being 100% and fully compatible with libgcc in order to effectively support platforms based on libcs that follow the design pattern of glibc, certainly including platforms that use glibc. Is that work? Yes. Should the project do it? Absolutely yes. Just like we work hard to be compatible with the gcc commandline and other layers of compatibility, we should work to support these platforms well.
Jan 12 2019
Changes to runtime.go address the regression caused by rL322965.
Jan 10 2019
Addressed all comments, will wait for feedback and then do the final draft, and if people are happy with that, I'll lint the whole file and then commit it.