- User Since
- Dec 9 2012, 11:41 PM (254 w, 9 h)
Sat, Oct 21
Thanks for cleaning this up. IIRC, I have similar behavior in compiler-rt for HIDDEN_SYMBOL.
Fri, Oct 20
The name is a bad idea, because you could get an expression or a value which is not a region name. I think that you should test that as well.
Thu, Oct 19
Tue, Oct 17
@frutiger you have commit rights now right?
Mon, Oct 16
Sun, Oct 15
BTW, I think that this is sufficient to show the behavior in MSVC:
You should be able to just do an IR level check for this. You can ensure that both get placed into a COMDAT section.
Sat, Oct 14
Fri, Oct 13
Wed, Oct 11
Don't you need a change to the intrinsics to actually map the builtin?
Mon, Oct 9
I think that the problem is that we are using the generic register name, but we need to use the target specific register name. On x86, EIP/ESP are swapped. We should also have a test case for this. I had reduced this down to a simpler test case of:
Fri, Oct 6
Split the defaulting back to all the various targets.
Id like to keep the bit about "please don't use these" ... we do support zero cost exceptions nearly everywhere now.
Thu, Oct 5
Moves the logic back into Basic. The flags are now optional, but controlled by the driver. The test adjustments are to map the old -fshort-wchar to -fwchar-type=short -fno-signed-wchar for the most part, there is one case where we were checking that we were passing -fshort-wchar through to the frontend, which we no longer do.
Tue, Oct 3
Why do we expect the tests to fail without vcruntime headers?
Please adjust the comments.
@ruiu I'm not sure that I understand the first question. Might be easier to discuss this on IRC or at the social.
Thanks for finding and fixing the performance regression on the older targets!
Mon, Oct 2
Please make sure that you do a build for watchOS before committing this, but this looks like it should accommodate that too.
Sun, Oct 1
I believe that SVN r314632 should address the issue more thorougly.
Actually, Ill go ahead and make the more invasive change and that will provide this properly.
Thu, Sep 28
Ugh, I was mixing up _Unwind_SjLj_Register with this function.
With an explanation of the gcc_s vs gcc, I think this LG.
I really wish that there was a way to handle this in the build system instead.
LGTM with the comment adjustments.
Wed, Sep 27
If I'm not mistaken, the change just means that the python bindings need a "newer" libclang, libclang's interfaces don't really change. I think that is acceptable.
These functions would only really compile down to an additional branch. I can understand the desire to micro-optimize away the additional branch. However, I think that I would rather that the following pattern is used:
Tue, Sep 26
Um, doesn't that clobber a register which is unexpected?
Ugh, this is not particularly helpful. I think that in the case that we can detect the failure, it would be nice. OTOH, I agree that these functions are special (effectively to be treated as if the compiler had emitted them inline). I think that having a guarded way to actually keep the abort is nice ... maybe an assert(start_reg == 0 && "syscall failed"); instead. That would just get pulled out in the case of a _NDEBUG build.
@t.p.northover should absolutely look at this. The problem here is that the MCAsmInfo is sometimes not set up early enough which results in the exception model not being correct. We need to wire this up better so that the information is not pulled from MCAsmInfo but passed through properly.
I have a complete implementation for this which is known to work on Windows at least. The only thing that __thread requires is a working linker (which does not include binutils -- I do have a local patch to make that work though). Are these two the only ones that are missing? At the very least, the implementation of SetTopOfFunctionStack is incorrect.
Mon, Sep 25
Sep 22 2017
Sure, Ill get this merged shortly.
Sep 21 2017
Moving the __APPLE__ case up to the top of the file would be nice, although, it does move a compatibility implementation too. I suppose that it isn't too terrible though.
Sep 20 2017
This is pretty awesome. I assume that you will do a corresponding change in clang to remove the single use of that function?
@bsdjhb shouldn't link.h be includable in a C++ header without worrying about the namespacing? But, moving the declarations is certainly reasonable.
@peter.smith the reason that the complexity exists currently is interoperability with gcc. If the triple is not hf, libgcc does not use AAPCS_VFP_CC. This is the source of the problem. Your mapping is correct though: