- User Since
- Dec 9 2012, 11:41 PM (280 w, 6 h)
Thu, Apr 19
Some cleanup suggestions included, but I like the change overall.
Mon, Apr 16
Sat, Apr 14
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.
Fri, Apr 13
Thu, Apr 12
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?
Wed, Apr 11
Thu, Apr 5
Wed, Apr 4
Mon, Apr 2
Wed, Mar 28
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.
Yeah, this is still an indirect return. I can see your point about the representation, nfortunately, I think that change is way out of scope for this. That would be a pretty large and invasive change to wire that through.
Feb 27 2018
Feb 26 2018
If its easy enough to wire that through to the frontend as a proper diagnostic, that would be better with a test. Otherwise, this is good to continue to make progress.
Feb 24 2018
Feb 21 2018
Feb 20 2018
Yeah, I think I would feel safer with this being limited to targets where we know that we have an explicit contract for __int128_t. Can you please limit this to the RISCV architecture for the time being?
Please clang-format the conditional (we keep the operator on the previous line).
Feb 19 2018
Is there a need for this given the changes for 6.0?
Feb 17 2018
Feb 12 2018
Feb 10 2018
Feb 9 2018
Feb 8 2018
Feb 7 2018
@rjmccall, I've updated the approach and no longer abuse the existing decoration styles. This uses a custom namespace with artificial types to differentiate the types. I've also ensured that the parameter types do not encode the type information.
Address comments from @rjmccall
I think we should first clarify that currently the only Windows on ARM support is Windows ARM NT (Windows ARM CE still does have both modes of execution). The important thing to note here is that although the CPU supports both modes of execution, the Windows ARM NT kernel does not guarantee the current mode will be preserved (that is, if you trap into the kernel in ARM mode, you are probably going to come out in Thumb mode and fault). I agree that we should try to fix this generally rather than hardcode this to Windows ARM.
Feb 6 2018
@aaron.ballman, yeah, I believe that the warning is working as intended, it just so happens that at runtime things just happened to work out.
Update to what Microsoft has communicated offline
address design changes
Add additional test, update docs
@jhenderson I believe that the first one is what this is implementing. I believe that adding the last two as a patch following this one is preferable as that is specific to the needs for PS4, but, both of those should be possible to accommodate. I would love to see a single unified approach here, so Im happy to help get that implemented.
I believe that the commit message needs to be updated for the change. This is a pretty distasteful patch IMO, but, I don't see a better solution here :-(.
Feb 5 2018
@jhenderson I believe that you are correct with the analysis of the behavior of binutils' objcopy. Definitely should have a test case for this.