- User Since
- Dec 9 2012, 11:41 PM (292 w, 1 d)
Fri, Jul 6
The install- target is created by add_llvm_install_targets, not by the component. The component is part of CMake itself, and is controlled by the CMAKE_INSTALL_DEFAULT_COMPONENT_NAME.
Thu, Jul 5
This seems reasonable if you need the support in the assembler. However, please add a test to ensure that the paths are mapped when invoking the assembler rather than the compiler.
Mon, Jun 25
Nice! I like the changes to the objdump, but, would it be possible to roundtrip the object files being added through obj2yaml and yaml2obj rather than checking in binaries?
Wed, Jun 20
Thanks for the changes!
Tue, Jun 19
Jun 14 2018
It really is unfortunate that linkers can spell version differently :-(. It would be really nice to be able to unify the linker version detection.
Jun 13 2018
I assume that there is/will be a different change to the frontend to enable this for users?
Jun 12 2018
x86-Linux-only test is good. LG with the discussed changes.
Nice cleanup! Thanks for doing this
Jun 11 2018
This makes much more sense. Thanks @joerg
Jun 7 2018
This should be functionally identical and is much cleaner. Thanks!
Jun 3 2018
May 29 2018
It would be nice if we had a test case added for this, but, seems correct to me.
@rnk - Id say something more stronger than on board for this change. I think that this is a great cleanup, makes everything much clearer and generally simplifies the model that you have to work with. I didn't look at the changes to the test very carefully (they should be mechanical in nature). The rest LGTM.
May 23 2018
May 22 2018
May 21 2018
May 20 2018
May 11 2018
May 10 2018
May 2 2018
May 1 2018
Apr 27 2018
Do you have commit access or do you need someone to commit this on your behalf?
Apr 26 2018
I'm torn on this. The other -print options will perform the validation implicitly at the higher level before calling the inner functions. It is certainly reasonable to support that, but, for the common path, this check seems unnecessary (and this function is used elsewhere in clang). There is a similar problem that exists with -print-file-name=. We should probably fix both at the same time. Can you also please add a test case for this?
Apr 22 2018
Apr 19 2018
Some cleanup suggestions included, but I like the change overall.
Apr 16 2018
Apr 14 2018
I'm not sure I understand this. The proper location for libc++ on the darwin layout is in the SDK, not relative to the driver. The default behaviour is similar to cross-compiling, and with a (derived) SDK. This definitely needs to be reviewed by @dexonsmith
Snipping bits from va_defs.h:
I definitely like the clean up. Not sure I understand the motivation for the __libcpp_relaxed_store, but I suppose thats because its a copy from libc++ where it may be more useful.
Sorry for the delay, didn't see the changes earlier.
Apr 13 2018
Apr 12 2018
I know that the Windows SDK definitely declares the __va_start function. Did you try building something like swift against the Windows SDK with this change?
Apr 11 2018
Apr 5 2018
Apr 4 2018
Apr 2 2018
Mar 28 2018
I really don't like this approach. I think that we should introduce a different entry point for this behavior rather than saying that we go through the existing interface. Having a reference to the .eh_frame_hdr seems better, as it would be better to make use of that optimization and we already have handling for that in libunwind.
Mar 22 2018
Mar 21 2018
I may be a bit biased but I agree with @bob.wilson and @steven_wu. The current names are better from the user’s perspective. GCC’s build is a very bad example as it has runtime components built as part of it (libgcc). When building any code, even in a Canadian cross-compile, the target will always be what you are running on. The preprocessor macros are part of the code that you are building for a given target. The association with the command line option makes it more obvious what it is going to use to determine the value. Having a pithy name should also be considered a design goal. Recreating new terminology only muddles the problem.
Mar 20 2018
I want to get Duncan's input on this. I don't think that this is a supported configuration for macOS.
Mar 19 2018
LGTM, I'd give @majnemer a day or so before committing.
What happens in the case that you have a variadic in C code marked with __forceinline? Does that also cause a warning with MSVC?
Mar 12 2018
SVN r327336. Addressed comments in SVN r327351, because I forgot to incorporate them in the first try.
Mar 9 2018
Use the BB colorizer to detect the token. Fortunately, there is no BB removal/splitting happening here, so there is no state to maintain.
Mar 8 2018
add more context
Mar 7 2018
@rnk, I like the idea of pushing the mapping behavior to the single use in llvm-pdbutil and removing this overload.
Mar 1 2018
Awesome, thanks, this makes me feel much more comfortable.
Feb 28 2018
Ugh, really not a fan of this change.