[PATCH] D50144: Add Windows support for the GNUstep Objective-C ABI V2.

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai added inline comments.



Comment at: lib/AST/MicrosoftMangle.cpp:1886
   case BuiltinType::ObjCId:
-mangleArtificalTagType(TTK_Struct, "objc_object");
+mangleArtificalTagType(TTK_Struct, ".objc_object");
 break;

theraven wrote:
> compnerd wrote:
> > DHowett-MSFT wrote:
> > > I'm interested in @smeenai's take on this, as well.
> > Hmm, doesn't this break ObjC/ObjC++ interoperability?  I don't think that 
> > we should be changing the decoration here for the MS ABI case.
> No, this fixes ObjC++ interop.  Throwing an exception from a `@throw` and 
> catching it with `catch` now works and we avoid the problem that a C++ 
> compilation unit declares a `struct` that happens to have the same name as an 
> Objective-C class (which is very common for wrapper code) may catch things of 
> the wrong type.
I've seen a lot of code which does something like this in a header

```lang=cpp
#ifdef __OBJC__
@class I;
#else
struct I;
#endif

void f(I *);
```

You want `f` to be mangled consistently across C++ and Objective-C++, otherwise 
you'll get link errors if `f` is e.g. defined in a C++ TU and referenced in an 
Objective-C++ TU. This was the case before your change and isn't the case after 
your change, which is what @compnerd was pointing out. They are mangled 
consistently in the Itanium ABI, and we want them to be mangled consistently in 
the MS ABI as well.

Not wanting the catch mix-up is completely reasonable, of course, but it can be 
done in a more targeted way. I'll put up a patch that undoes this part of the 
change while still preventing incorrect catching.


Repository:
  rC Clang

https://reviews.llvm.org/D50144



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D50144: Add Windows support for the GNUstep Objective-C ABI V2.

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai added a subscriber: rnk.
smeenai added a comment.

Sorry for the belated response; I was on vacation.

I'm confused by the funclet-based unwinding support. Do you intend GNUStep to 
be used with windows-msvc triples? If so, how is the runtime throwing 
exceptions? We took the approach of having the Obj-C runtime wrap Obj-C 
exceptions in C++ exceptions and then have vcruntime handle the rest (see 
https://reviews.llvm.org/D47233 and https://reviews.llvm.org/D47988), but I 
don't see any of the associated RTTI emission changes in this patch.

I also don't see any tests added for the codegen changes around `@finally`. I'm 
planning on changing that approach anyway (by pushing 
https://reviews.llvm.org/D47988) through, but it still seems like something 
that was missing from this patch.




Comment at: lib/AST/MicrosoftMangle.cpp:1886
   case BuiltinType::ObjCId:
-mangleArtificalTagType(TTK_Struct, "objc_object");
+mangleArtificalTagType(TTK_Struct, ".objc_object");
 break;

theraven wrote:
> smeenai wrote:
> > theraven wrote:
> > > compnerd wrote:
> > > > DHowett-MSFT wrote:
> > > > > I'm interested in @smeenai's take on this, as well.
> > > > Hmm, doesn't this break ObjC/ObjC++ interoperability?  I don't think 
> > > > that we should be changing the decoration here for the MS ABI case.
> > > No, this fixes ObjC++ interop.  Throwing an exception from a `@throw` and 
> > > catching it with `catch` now works and we avoid the problem that a C++ 
> > > compilation unit declares a `struct` that happens to have the same name 
> > > as an Objective-C class (which is very common for wrapper code) may catch 
> > > things of the wrong type.
> > I've seen a lot of code which does something like this in a header
> > 
> > ```lang=cpp
> > #ifdef __OBJC__
> > @class I;
> > #else
> > struct I;
> > #endif
> > 
> > void f(I *);
> > ```
> > 
> > You want `f` to be mangled consistently across C++ and Objective-C++, 
> > otherwise you'll get link errors if `f` is e.g. defined in a C++ TU and 
> > referenced in an Objective-C++ TU. This was the case before your change and 
> > isn't the case after your change, which is what @compnerd was pointing out. 
> > They are mangled consistently in the Itanium ABI, and we want them to be 
> > mangled consistently in the MS ABI as well.
> > 
> > Not wanting the catch mix-up is completely reasonable, of course, but it 
> > can be done in a more targeted way. I'll put up a patch that undoes this 
> > part of the change while still preventing incorrect catching.
> With a non-fragile ABI, there is not guarantee that `struct I` and `@class I` 
> have the same layout.  This is why `@defs` has gone away.  Any code that does 
> this and treats `struct I` as anything other than an opaque type is broken.  
> No other platform supports throwing an Objective-C object and catching it as 
> a struct, and this is an intentional design decision.  I would be strongly 
> opposed to a change that intentionally supported this, because it is breaking 
> correct code in order to make incorrect code do something that may or may not 
> work.
To be clear, I'm aware of the layout differences. My plan was to revert the 
mangling here to what it was before (which would also be consistent with 
Itanium), and then adjust the RTTI emission for Obj-C exception types (which 
I'm handling in https://reviews.llvm.org/D47233) to differentiate between C++ 
and Obj-C exceptions, which would prevent unintended catches.



Comment at: lib/CodeGen/CGObjCRuntime.cpp:203
+const Stmt *FinallyBlock = Finally->getFinallyBody();
+HelperCGF.startOutlinedSEHHelper(CGF, /*isFilter*/false, FinallyBlock);
+

This is *very* limiting. This outlining doesn't handle capturing self, 
capturing block variables, and lots of other cases that come up in practice. I 
attempted to implement some of the missing cases, before meeting with @compnerd 
and @rnk and deciding that it was better to use CapturedStmt instead. See 
https://reviews.llvm.org/D47564 for more discussion, and 
https://reviews.llvm.org/D47988 implements the associated codegen 
(unfortunately I wasn't able to get that through before going on vacation).


Repository:
  rC Clang

https://reviews.llvm.org/D50144



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D42933: [Sema] Avoid -Wformat warning for NSInteger/NSUInteger 'int' values with %zu/%zi long specifiers

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai added a comment.

In https://reviews.llvm.org/D42933#1091234, @aaron.ballman wrote:

> In https://reviews.llvm.org/D42933#1090268, @jfb wrote:
>
> > I was just looking at this, and I think @arphaman's patch is pretty much 
> > the right approach (with 2 suggested fixes below).
> >
> > I don't think the code we're currently warning on is broken: a user code 
> > has `NSInteger` with `%zd` or `NSUInteger` with `%zu`, and on all platforms 
> > which support those types the implementor has guaranteed that 
> > `(sizeof(size_t) == sizeof(NSInteger)) && (sizeof(ssize_t) == 
> > sizeof(NSUInteger))`.
>
>
> Yes, but is this guaranteed to be the case or does it happen to be the case? 
> I'm worried about the less mainstream uses where you might find ObjC code 
> where this does not hold but -Wformat points out a portability concern.


Also keep in mind that Obj-C might be used on non-Apple platforms, e.g. there's 
an active review going on for GNUstep ABI v2 right now 
(https://reviews.llvm.org/D46052), and WinObjC is also a thing. Those platforms 
might not necessarily provide the same guarantees or consistency that Apple's 
do.

>> I agree that, if we're playing C++ pedant and look at the typedefs, then 
>> it's undefined behavior and the code is broken.
> 
> This is reason alone to diagnose the code, because the optimizer is welcome 
> to use that UB to perform transformations the programmer did not expect. 
> However, I'm not certain our optimizer is currently paying attention to that 
> UB directly, so this may not be an immediate issue (but could be a pitfall 
> for the future) but I'm not certain about other optimizers for which 
> portability would still be a concern.

I would honestly find it a bit surprising (and scary) if the optimizer actually 
took advantage of UB in the case where the size and alignment of the specifier 
and the actual type matches.


Repository:
  rC Clang

https://reviews.llvm.org/D42933



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D46593: Allow copy elision in path concatenation

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai added a comment.

Generating the patch from libc++ is fine (and this patch looks like it has sane 
paths).


https://reviews.llvm.org/D46593



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D42933: [Sema] Avoid -Wformat warning for NSInteger/NSUInteger 'int' values with %zu/%zi long specifiers

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai added a subscriber: rsmith.
smeenai added a comment.

In https://reviews.llvm.org/D42933#1091943, @jyknight wrote:

> In https://reviews.llvm.org/D42933#1091817, @jfb wrote:
>
> > In https://reviews.llvm.org/D42933#1091809, @jyknight wrote:
> >
> > > I also think that special casing these two specifiers doesn't make sense. 
> > > The problem is a general issue -- and one I've often found irritating. 
> > > This exact same situation comes up all the time in non-Darwin contexts 
> > > too.
> >
> >
> > I don't think that's true. In this very specific case the platform 
> > guarantees that `(sizeof(size_t) == sizeof(NSInteger)) && (sizeof(ssize_t) 
> > == sizeof(NSUInteger))` for all architectures this platform supports. This 
> > exact same situation does not come up all the time in other contexts 
> > because the `int` / `long` / `long long` distinction isn't backed by a 
> > portability guarantee. The warning is there to say "this code isn't 
> > portable!", but in the very specific case of `NSInteger` and `NSUInteger` 
> > it is and users rely on it so it cannot be broken. The warning is therefore 
> > spurious, users therefore rightly complain.
>
>
> The printf format specifier warning is not primarily a cross-platform 
> portability checker. And, although in a few limited cases it can act somewhat 
> like one, in general it does not. Take my previous example -- you get no 
> warning on a platform that has int64_t as a typedef for long -- if this 
> feature is to be useful as a portability checker, it should require that you 
> used the PRId64 macro. Or, given `ssize_t x = 0; printf("%ld", x);`, it 
> doesn't tell you to use "%zd" instead if ssize_t is a typedef for long -- 
> although to be portable you ought to.
>
> No, the major usefulness of the printf warning is to tell you that your code 
> is incorrect for the _current_ platform. And //most// importantly when you 
> chose the wrong size for your argument.
>
> Those types which have matched size and alignment are still different types, 
> and so it's technically appropriate to warn about using the wrong specifier 
> there, too. But it's also entirely reasonable to not want to be bothered by 
> such useless trivia, so skipping the warning when there's only a technical 
> and not actual mismatch seems entirely sensible. (I might suggest that it 
> should even be the default behavior for the warning, and if you want the 
> stricter checks you'd ask for them...but I bet I'll get more pushback on 
> that...)


+1 to everything you said; what are other people's opinions on this? @rsmith 
perhaps?


Repository:
  rC Clang

https://reviews.llvm.org/D42933



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D42933: [Sema] Avoid -Wformat warning for NSInteger/NSUInteger 'int' values with %zu/%zi long specifiers

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai added a comment.

In https://reviews.llvm.org/D42933#1092048, @rjmccall wrote:

> I agree that the format-specifier checker is not intended to be a portability 
> checker.
>
> Any attempt to check portability problems has to account for two things:
>
> - Not all code is intended to be portable.  If you're going to warn about 
> portability problems, you need some way to not annoy programmers who might 
> have good reason to say that they only care about their code running on Linux 
> / macOS / 64-bit / 32-bit / whatever.  Generally this means splitting the 
> portability warning out as a separate warning group.
> - There are always established idioms for solving portability problems.  In 
> this case, a certain set of important typedefs from the C standard have been 
> blessed with dedicated format modifiers like "z", but every other typedef in 
> the world has to find some other solution, either by asserting that some 
> existing format is good enough (as NSInteger does) or by introducing a macro 
> that expands to an appropriate format (as some things in POSIX do).  A proper 
> format-portability warning would have to know about all of these conventions 
> (in order to check that e.g. part of the format string came from the right 
> macro), which just seems wildly out-of-scope for a compiler warning.


Apple's current recommendation for using printf with the NSInteger types is 
casting to a long, per 
https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/Strings/Articles/formatSpecifiers.html.
 Are you suggesting that recommendation would change to using `%zd` instead?


Repository:
  rC Clang

https://reviews.llvm.org/D42933



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D42933: [Sema] Avoid -Wformat warning for NSInteger/NSUInteger 'int' values with %zu/%zi long specifiers

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai added a comment.

Yeah, I think we all agree now that a portability warning isn't really 
tractable. Note that even for the warnings that motivated this diff, they 
should have only fired if `size_t` and NSInteger had separate types, so it 
wasn't a portability warning in that sense to begin with (as in, it would only 
warn if there was a mismatch for your current target, not if there was a 
potential mismatch for any target).

We still have two options:

1. Special-case NSInteger/NSUInteger on Apple platforms so that they can always 
be printed using `%z` without any issues.
2. Relax the format specifier warnings (either under a new warning option, e.g. 
`-Wformat-relaxed`, or by relaxing `-Wformat` itself and adding something like 
`-Wformat-pedantic`) so that you don't warn when the specifier and the actual 
type have the same size and alignment, even when the actual type is different 
(which would also cover the case in 1).

I'm personally in favor of 2, and I can start a discussion on cfe-dev if you 
think we should try to achieve a broader consensus. Whichever option we went 
with, we would also have to ensure that the optimizer didn't do anything bad 
(as @aaron.ballman pointed out), both now and in the future.


Repository:
  rC Clang

https://reviews.llvm.org/D42933



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D42933: [Sema] Avoid -Wformat warning for NSInteger/NSUInteger 'int' values with %zu/%zi long specifiers

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai added a comment.

Emailed cfe-dev: http://lists.llvm.org/pipermail/cfe-dev/2018-May/057934.html


Repository:
  rC Clang

https://reviews.llvm.org/D42933



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D47233: [CodeGen] Emit MSVC RTTI for Obj-C EH types

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai created this revision.
smeenai added reviewers: DHowett-MSFT, compnerd, majnemer, rjmccall, rnk.

We're implementing funclet-compatible code generation for Obj-C
exceptions when using the MSVC ABI. The idea is that the Obj-C runtime
will wrap Obj-C exceptions inside C++ exceptions, which allows for
interoperability with C++ exceptions (for Obj-C++) and zero-cost
exceptions. This is the approach taken by e.g. WinObjC, and I believe it
to be the best approach for Obj-C exceptions in the MSVC ABI.

The first step is emitting proper RTTI for Obj-C exception types. Since
we're wrapping Obj-C exceptions in C++ exceptions, the RTTI should be
identical, barring the name of the RTTI variable (OBJC_EHTYPE_$_*).
Since the MSVC ABI does not easily allow for cross-DLL data references
from within other data, we instead emit the RTTI locally wherever
needed, which is also how C++ RTTI works on that ABI.

Follow-up diffs will add code generation support for @try itself, but
I'm splitting it up to get early feedback and make review more
manageable.

Worked on with Saleem Abdulrasool .


Repository:
  rC Clang

https://reviews.llvm.org/D47233

Files:
  lib/CodeGen/CGCXXABI.h
  lib/CodeGen/CGObjCMac.cpp
  lib/CodeGen/MicrosoftCXXABI.cpp
  test/CodeGenObjC/dllstorage.m
  test/CodeGenObjC/exceptions-msvc.m

Index: test/CodeGenObjC/exceptions-msvc.m
===
--- /dev/null
+++ test/CodeGenObjC/exceptions-msvc.m
@@ -0,0 +1,68 @@
+// RUN: %clang_cc1 -triple i686--windows-msvc -fobjc-runtime=ios-6.0 -fdeclspec -fexceptions -fobjc-exceptions -emit-llvm -o - %s | FileCheck -check-prefixes=CHECK,X86 %s
+// RUN: %clang_cc1 -triple i686--windows-msvc -fobjc-runtime=ios-6.0 -fobjc-arc -fdeclspec -fexceptions -fobjc-exceptions -emit-llvm -o - %s | FileCheck -check-prefixes=CHECK,X86 %s
+// RUN: %clang_cc1 -triple x86_64--windows-msvc -fobjc-runtime=ios-6.0 -fdeclspec -fexceptions -fobjc-exceptions -emit-llvm -o - %s | FileCheck -check-prefixes=CHECK,X64 %s
+// RUN: %clang_cc1 -triple x86_64--windows-msvc -fobjc-runtime=ios-6.0 -fobjc-arc -fdeclspec -fexceptions -fobjc-exceptions -emit-llvm -o - %s | FileCheck -check-prefixes=CHECK,X64 %s
+
+// CHECK-DAG: $OBJC_EHTYPE_id = comdat any
+// X86-DAG: @OBJC_EHTYPE_id = linkonce_odr global {{%[^ ]+}} { i8** @"??_7type_info@@6B@", i8* null, [18 x i8] c".PAUobjc_object@@\00" }, comdat
+// X64-DAG: @OBJC_EHTYPE_id = linkonce_odr global {{%[^ ]+}} { i8** @"??_7type_info@@6B@", i8* null, [19 x i8] c".PEAUobjc_object@@\00" }, comdat
+
+// CHECK-DAG: $"OBJC_EHTYPE_$_I" = comdat any
+// X86-DAG: @"OBJC_EHTYPE_$_I" = linkonce_odr global {{%[^ ]+}} { i8** @"??_7type_info@@6B@", i8* null, [8 x i8] c".PAUI@@\00" }, comdat
+// X64-DAG: @"OBJC_EHTYPE_$_I" = linkonce_odr global {{%[^ ]+}} { i8** @"??_7type_info@@6B@", i8* null, [9 x i8] c".PEAUI@@\00" }, comdat
+
+// CHECK-DAG: $"OBJC_EHTYPE_$_J" = comdat any
+// X86-DAG: @"OBJC_EHTYPE_$_J" = linkonce_odr global {{%[^ ]+}} { i8** @"??_7type_info@@6B@", i8* null, [8 x i8] c".PAUJ@@\00" }, comdat
+// X64-DAG: @"OBJC_EHTYPE_$_J" = linkonce_odr global {{%[^ ]+}} { i8** @"??_7type_info@@6B@", i8* null, [9 x i8] c".PEAUJ@@\00" }, comdat
+
+// CHECK-DAG: $"OBJC_EHTYPE_$_K" = comdat any
+// X86-DAG: @"OBJC_EHTYPE_$_K" = linkonce_odr global {{%[^ ]+}} { i8** @"??_7type_info@@6B@", i8* null, [8 x i8] c".PAUK@@\00" }, comdat
+// X64-DAG: @"OBJC_EHTYPE_$_K" = linkonce_odr global {{%[^ ]+}} { i8** @"??_7type_info@@6B@", i8* null, [9 x i8] c".PEAUK@@\00" }, comdat
+
+// CHECK-DAG: $"OBJC_EHTYPE_$_NotL" = comdat any
+// X86-DAG: @"OBJC_EHTYPE_$_NotL" = linkonce_odr global {{%[^ ]+}} { i8** @"??_7type_info@@6B@", i8* null, [8 x i8] c".PAUL@@\00" }, comdat
+// X64-DAG: @"OBJC_EHTYPE_$_NotL" = linkonce_odr global {{%[^ ]+}} { i8** @"??_7type_info@@6B@", i8* null, [9 x i8] c".PEAUL@@\00" }, comdat
+
+// CHECK-DAG: $"OBJC_EHTYPE_$_M" = comdat any
+// X86-DAG: @"OBJC_EHTYPE_$_M" = linkonce_odr global {{%[^ ]+}} { i8** @"??_7type_info@@6B@", i8* null, [8 x i8] c".PAUM@@\00" }, comdat
+// X64-DAG: @"OBJC_EHTYPE_$_M" = linkonce_odr global {{%[^ ]+}} { i8** @"??_7type_info@@6B@", i8* null, [9 x i8] c".PEAUM@@\00" }, comdat
+
+#if __has_feature(objc_arc)
+#define WEAK __weak
+#else
+#define WEAK
+#endif
+
+@class I;
+@class J;
+
+// The EHType shouldn't be exported
+__declspec(dllexport)
+__attribute__((objc_root_class))
+@interface K
+@end
+
+@implementation K
+@end
+
+__attribute__((objc_runtime_name("NotL")))
+@interface L
+@end
+
+@class M;
+
+@protocol P;
+
+void f(void);
+
+void g() {
+  @try {
+f();
+  } @catch (I *) {
+  } @catch (J *) {
+  } @catch (K *) {
+  } @catch (L *) {
+  } @catch (M *WEAK) {
+  } @catch (id) {
+  }
+}
Index: test/CodeGenObjC/dllstorage.m
===
--- test/CodeGenObjC/dllstorage.m
+++ test/CodeGenObjC/dllstorage.m
@@ -1,5 +1,5 @@
 // RUN: %clang_cc1 -triple x86_64-unknown-windows-msvc -fdeclspec -fobjc-runtime=ios -fobjc-exce

[PATCH] D47233: [CodeGen] Emit MSVC RTTI for Obj-C EH types

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai updated this revision to Diff 148133.
smeenai added a comment.

Colocate CHECK lines with declarations


Repository:
  rC Clang

https://reviews.llvm.org/D47233

Files:
  lib/CodeGen/CGCXXABI.h
  lib/CodeGen/CGObjCMac.cpp
  lib/CodeGen/MicrosoftCXXABI.cpp
  test/CodeGenObjC/dllstorage.m
  test/CodeGenObjC/exceptions-msvc.m

Index: test/CodeGenObjC/exceptions-msvc.m
===
--- /dev/null
+++ test/CodeGenObjC/exceptions-msvc.m
@@ -0,0 +1,69 @@
+// RUN: %clang_cc1 -triple i686--windows-msvc -fobjc-runtime=ios-6.0 -fdeclspec -fexceptions -fobjc-exceptions -emit-llvm -o - %s | FileCheck -check-prefixes=CHECK,X86 %s
+// RUN: %clang_cc1 -triple i686--windows-msvc -fobjc-runtime=ios-6.0 -fobjc-arc -fdeclspec -fexceptions -fobjc-exceptions -emit-llvm -o - %s | FileCheck -check-prefixes=CHECK,X86 %s
+// RUN: %clang_cc1 -triple x86_64--windows-msvc -fobjc-runtime=ios-6.0 -fdeclspec -fexceptions -fobjc-exceptions -emit-llvm -o - %s | FileCheck -check-prefixes=CHECK,X64 %s
+// RUN: %clang_cc1 -triple x86_64--windows-msvc -fobjc-runtime=ios-6.0 -fobjc-arc -fdeclspec -fexceptions -fobjc-exceptions -emit-llvm -o - %s | FileCheck -check-prefixes=CHECK,X64 %s
+
+#if __has_feature(objc_arc)
+#define WEAK __weak
+#else
+#define WEAK
+#endif
+
+// CHECK-DAG: $OBJC_EHTYPE_id = comdat any
+// X86-DAG: @OBJC_EHTYPE_id = linkonce_odr global {{%[^ ]+}} { i8** @"??_7type_info@@6B@", i8* null, [18 x i8] c".PAUobjc_object@@\00" }, comdat
+// X64-DAG: @OBJC_EHTYPE_id = linkonce_odr global {{%[^ ]+}} { i8** @"??_7type_info@@6B@", i8* null, [19 x i8] c".PEAUobjc_object@@\00" }, comdat
+
+@class I;
+
+// CHECK-DAG: $"OBJC_EHTYPE_$_I" = comdat any
+// X86-DAG: @"OBJC_EHTYPE_$_I" = linkonce_odr global {{%[^ ]+}} { i8** @"??_7type_info@@6B@", i8* null, [8 x i8] c".PAUI@@\00" }, comdat
+// X64-DAG: @"OBJC_EHTYPE_$_I" = linkonce_odr global {{%[^ ]+}} { i8** @"??_7type_info@@6B@", i8* null, [9 x i8] c".PEAUI@@\00" }, comdat
+
+@class J;
+
+// CHECK-DAG: $"OBJC_EHTYPE_$_J" = comdat any
+// X86-DAG: @"OBJC_EHTYPE_$_J" = linkonce_odr global {{%[^ ]+}} { i8** @"??_7type_info@@6B@", i8* null, [8 x i8] c".PAUJ@@\00" }, comdat
+// X64-DAG: @"OBJC_EHTYPE_$_J" = linkonce_odr global {{%[^ ]+}} { i8** @"??_7type_info@@6B@", i8* null, [9 x i8] c".PEAUJ@@\00" }, comdat
+
+// The EHType shouldn't be exported
+__declspec(dllexport)
+__attribute__((objc_root_class))
+@interface K
+@end
+
+@implementation K
+@end
+
+// CHECK-DAG: $"OBJC_EHTYPE_$_K" = comdat any
+// X86-DAG: @"OBJC_EHTYPE_$_K" = linkonce_odr global {{%[^ ]+}} { i8** @"??_7type_info@@6B@", i8* null, [8 x i8] c".PAUK@@\00" }, comdat
+// X64-DAG: @"OBJC_EHTYPE_$_K" = linkonce_odr global {{%[^ ]+}} { i8** @"??_7type_info@@6B@", i8* null, [9 x i8] c".PEAUK@@\00" }, comdat
+
+__attribute__((objc_runtime_name("NotL")))
+@interface L
+@end
+
+// CHECK-DAG: $"OBJC_EHTYPE_$_NotL" = comdat any
+// X86-DAG: @"OBJC_EHTYPE_$_NotL" = linkonce_odr global {{%[^ ]+}} { i8** @"??_7type_info@@6B@", i8* null, [8 x i8] c".PAUL@@\00" }, comdat
+// X64-DAG: @"OBJC_EHTYPE_$_NotL" = linkonce_odr global {{%[^ ]+}} { i8** @"??_7type_info@@6B@", i8* null, [9 x i8] c".PEAUL@@\00" }, comdat
+
+@class M;
+
+// CHECK-DAG: $"OBJC_EHTYPE_$_M" = comdat any
+// X86-DAG: @"OBJC_EHTYPE_$_M" = linkonce_odr global {{%[^ ]+}} { i8** @"??_7type_info@@6B@", i8* null, [8 x i8] c".PAUM@@\00" }, comdat
+// X64-DAG: @"OBJC_EHTYPE_$_M" = linkonce_odr global {{%[^ ]+}} { i8** @"??_7type_info@@6B@", i8* null, [9 x i8] c".PEAUM@@\00" }, comdat
+
+@protocol P;
+
+void f(void);
+
+void g() {
+  @try {
+f();
+  } @catch (I *) {
+  } @catch (J *) {
+  } @catch (K *) {
+  } @catch (L *) {
+  } @catch (M *WEAK) {
+  } @catch (id) {
+  }
+}
Index: test/CodeGenObjC/dllstorage.m
===
--- test/CodeGenObjC/dllstorage.m
+++ test/CodeGenObjC/dllstorage.m
@@ -1,5 +1,5 @@
 // RUN: %clang_cc1 -triple x86_64-unknown-windows-msvc -fdeclspec -fobjc-runtime=ios -fobjc-exceptions -S -emit-llvm -o - %s | FileCheck -check-prefix CHECK-IR %s
-// RUN: %clang_cc1 -triple i686-windows-itanium -fms-extensions -fobjc-runtime=macosx -fdeclspec -fobjc-exceptions -S -emit-llvm -o - %s | FileCheck -check-prefix CHECK-IR %s
+// RUN: %clang_cc1 -triple i686-windows-itanium -fms-extensions -fobjc-runtime=macosx -fdeclspec -fobjc-exceptions -S -emit-llvm -o - %s | FileCheck -check-prefix CHECK-IR -check-prefix CHECK-ITANIUM %s
 // RUN: %clang_cc1 -triple i686-windows-itanium -fms-extensions -fobjc-runtime=objfw -fdeclspec -fobjc-exceptions -S -emit-llvm -o - %s | FileCheck -check-prefix CHECK-FW %s
 
 // CHECK-IR-DAG: @_objc_empty_cache = external dllimport global %struct._objc_cache
@@ -100,20 +100,20 @@
 @implementation N : I
 @end
 
-// CHECK-IR-DAG: @"OBJC_EHTYPE_$_N" = dso_local dllexport global %struct._objc_typeinfo
+// CHECK-ITANIUM-DAG: @"OBJC_EHTYPE_$_N" = dso_local dllexport global %struct._objc_typeinfo
 
 __declspec(dllimport)
 __attribu

[PATCH] D38522: [libc++] Support Microsoft ABI without vcruntime headers

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai created this revision.
Herald added a subscriber: mgorny.

The vcruntime headers are hairy and clash with both libc++ headers
themselves and other libraries. libc++ normally deals with the clashes
by deferring to the vcruntime headers and silencing its own definitions,
but for clients which don't want to depend on vcruntime headers, it's
desirable to support the opposite, i.e. have libc++ provide its own
definitions.


https://reviews.llvm.org/D38522

Files:
  CMakeLists.txt
  docs/UsingLibcxx.rst
  include/__config_site.in
  include/exception
  include/new
  src/new.cpp
  src/support/runtime/exception_msvc.ipp
  src/support/runtime/exception_pointer_msvc.ipp
  
test/std/language.support/support.dynamic/new.delete/new.delete.array/new_array_nothrow_replace.pass.cpp
  
test/std/language.support/support.dynamic/new.delete/new.delete.array/new_array_replace.pass.cpp
  
test/std/language.support/support.dynamic/new.delete/new.delete.single/new_nothrow_replace.pass.cpp
  utils/libcxx/test/config.py

Index: utils/libcxx/test/config.py
===
--- utils/libcxx/test/config.py
+++ utils/libcxx/test/config.py
@@ -668,6 +668,9 @@
 self.config.available_features.add('libcpp-abi-version-v%s'
 % feature_macros[m])
 continue
+if m == '_LIBCPP_NO_VCRUNTIME':
+self.config.available_features.add('libcpp-no-vcruntime')
+continue
 assert m.startswith('_LIBCPP_HAS_') or m == '_LIBCPP_ABI_UNSTABLE'
 m = m.lower()[1:].replace('_', '-')
 self.config.available_features.add(m)
Index: test/std/language.support/support.dynamic/new.delete/new.delete.single/new_nothrow_replace.pass.cpp
===
--- test/std/language.support/support.dynamic/new.delete/new.delete.single/new_nothrow_replace.pass.cpp
+++ test/std/language.support/support.dynamic/new.delete/new.delete.single/new_nothrow_replace.pass.cpp
@@ -10,6 +10,7 @@
 // test operator new nothrow by replacing only operator new
 
 // UNSUPPORTED: sanitizer-new-delete
+// XFAIL: libcpp-no-vcruntime
 
 #include 
 #include 
Index: test/std/language.support/support.dynamic/new.delete/new.delete.array/new_array_replace.pass.cpp
===
--- test/std/language.support/support.dynamic/new.delete/new.delete.array/new_array_replace.pass.cpp
+++ test/std/language.support/support.dynamic/new.delete/new.delete.array/new_array_replace.pass.cpp
@@ -10,6 +10,7 @@
 // test operator new[] replacement by replacing only operator new
 
 // UNSUPPORTED: sanitizer-new-delete
+// XFAIL: libcpp-no-vcruntime
 
 
 #include 
Index: test/std/language.support/support.dynamic/new.delete/new.delete.array/new_array_nothrow_replace.pass.cpp
===
--- test/std/language.support/support.dynamic/new.delete/new.delete.array/new_array_nothrow_replace.pass.cpp
+++ test/std/language.support/support.dynamic/new.delete/new.delete.array/new_array_nothrow_replace.pass.cpp
@@ -10,6 +10,7 @@
 // test operator new [] nothrow by replacing only operator new
 
 // UNSUPPORTED: sanitizer-new-delete
+// XFAIL: libcpp-no-vcruntime
 
 #include 
 #include 
Index: src/support/runtime/exception_pointer_msvc.ipp
===
--- src/support/runtime/exception_pointer_msvc.ipp
+++ src/support/runtime/exception_pointer_msvc.ipp
@@ -10,7 +10,14 @@
 
 #include 
 #include 
-#include  // for _CRTIMP2_PURE
+
+#if !defined(_CRTIMP2_PURE)
+#define _CRTIMP2_PURE __declspec(dllimport)
+#endif
+
+#if !defined(__CLRCALL_PURE_OR_CDECL)
+#define __CLRCALL_PURE_OR_CDECL __cdecl
+#endif
 
 _CRTIMP2_PURE void __CLRCALL_PURE_OR_CDECL __ExceptionPtrCreate(_Out_ void*);
 _CRTIMP2_PURE void __CLRCALL_PURE_OR_CDECL __ExceptionPtrDestroy(_Inout_ void*);
Index: src/support/runtime/exception_msvc.ipp
===
--- src/support/runtime/exception_msvc.ipp
+++ src/support/runtime/exception_msvc.ipp
@@ -14,12 +14,35 @@
 
 #include 
 #include 
-#include 
-#include 
+
+#if !defined(_ACRTIMP)
+#define _ACRTIMP __declspec(dllimport)
+#endif
+
+#if !defined(_VCRTIMP)
+#define _VCRTIMP __declspec(dllimport)
+#endif
+
+#if !defined(__CRTDECL)
+#define __CRTDECL __cdecl
+#endif
+
+extern "C" {
+typedef void(__CRTDECL* terminate_handler)();
+_ACRTIMP terminate_handler __cdecl set_terminate(
+_In_opt_ terminate_handler _NewTerminateHandler) throw();
+_ACRTIMP terminate_handler __cdecl _get_terminate();
+
+typedef void(__CRTDECL* unexpected_handler)();
+_VCRTIMP unexpected_handler __cdecl set_unexpected(
+_In_opt_ unexpected_handler _NewUnexpectedHandler) throw();
+_VCRTIMP unexpected_handler __cdecl _get_unexpected();
+
+_VCRTIMP int __cdecl __uncaught_exceptions();
+}
 
 namespace std {
 
-// li

[PATCH] D38522: [libc++] Support Microsoft ABI without vcruntime headers

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai updated this revision to Diff 117613.
smeenai added a comment.

Remove SAL annotations as well; they're unneeded and add a header dependency


https://reviews.llvm.org/D38522

Files:
  CMakeLists.txt
  docs/UsingLibcxx.rst
  include/__config_site.in
  include/exception
  include/new
  src/new.cpp
  src/support/runtime/exception_msvc.ipp
  src/support/runtime/exception_pointer_msvc.ipp
  
test/std/language.support/support.dynamic/new.delete/new.delete.array/new_array_nothrow_replace.pass.cpp
  
test/std/language.support/support.dynamic/new.delete/new.delete.array/new_array_replace.pass.cpp
  
test/std/language.support/support.dynamic/new.delete/new.delete.single/new_nothrow_replace.pass.cpp
  utils/libcxx/test/config.py

Index: utils/libcxx/test/config.py
===
--- utils/libcxx/test/config.py
+++ utils/libcxx/test/config.py
@@ -668,6 +668,9 @@
 self.config.available_features.add('libcpp-abi-version-v%s'
 % feature_macros[m])
 continue
+if m == '_LIBCPP_NO_VCRUNTIME':
+self.config.available_features.add('libcpp-no-vcruntime')
+continue
 assert m.startswith('_LIBCPP_HAS_') or m == '_LIBCPP_ABI_UNSTABLE'
 m = m.lower()[1:].replace('_', '-')
 self.config.available_features.add(m)
Index: test/std/language.support/support.dynamic/new.delete/new.delete.single/new_nothrow_replace.pass.cpp
===
--- test/std/language.support/support.dynamic/new.delete/new.delete.single/new_nothrow_replace.pass.cpp
+++ test/std/language.support/support.dynamic/new.delete/new.delete.single/new_nothrow_replace.pass.cpp
@@ -10,6 +10,7 @@
 // test operator new nothrow by replacing only operator new
 
 // UNSUPPORTED: sanitizer-new-delete
+// XFAIL: libcpp-no-vcruntime
 
 #include 
 #include 
Index: test/std/language.support/support.dynamic/new.delete/new.delete.array/new_array_replace.pass.cpp
===
--- test/std/language.support/support.dynamic/new.delete/new.delete.array/new_array_replace.pass.cpp
+++ test/std/language.support/support.dynamic/new.delete/new.delete.array/new_array_replace.pass.cpp
@@ -10,6 +10,7 @@
 // test operator new[] replacement by replacing only operator new
 
 // UNSUPPORTED: sanitizer-new-delete
+// XFAIL: libcpp-no-vcruntime
 
 
 #include 
Index: test/std/language.support/support.dynamic/new.delete/new.delete.array/new_array_nothrow_replace.pass.cpp
===
--- test/std/language.support/support.dynamic/new.delete/new.delete.array/new_array_nothrow_replace.pass.cpp
+++ test/std/language.support/support.dynamic/new.delete/new.delete.array/new_array_nothrow_replace.pass.cpp
@@ -10,6 +10,7 @@
 // test operator new [] nothrow by replacing only operator new
 
 // UNSUPPORTED: sanitizer-new-delete
+// XFAIL: libcpp-no-vcruntime
 
 #include 
 #include 
Index: src/support/runtime/exception_pointer_msvc.ipp
===
--- src/support/runtime/exception_pointer_msvc.ipp
+++ src/support/runtime/exception_pointer_msvc.ipp
@@ -10,26 +10,32 @@
 
 #include 
 #include 
-#include  // for _CRTIMP2_PURE
 
-_CRTIMP2_PURE void __CLRCALL_PURE_OR_CDECL __ExceptionPtrCreate(_Out_ void*);
-_CRTIMP2_PURE void __CLRCALL_PURE_OR_CDECL __ExceptionPtrDestroy(_Inout_ void*);
-_CRTIMP2_PURE void __CLRCALL_PURE_OR_CDECL __ExceptionPtrCopy(_Out_ void*,
-  _In_ const void*);
+#if !defined(_CRTIMP2_PURE)
+#define _CRTIMP2_PURE __declspec(dllimport)
+#endif
+
+#if !defined(__CLRCALL_PURE_OR_CDECL)
+#define __CLRCALL_PURE_OR_CDECL __cdecl
+#endif
+
+_CRTIMP2_PURE void __CLRCALL_PURE_OR_CDECL __ExceptionPtrCreate(void*);
+_CRTIMP2_PURE void __CLRCALL_PURE_OR_CDECL __ExceptionPtrDestroy(void*);
+_CRTIMP2_PURE void __CLRCALL_PURE_OR_CDECL __ExceptionPtrCopy(void*,
+  const void*);
 _CRTIMP2_PURE void __CLRCALL_PURE_OR_CDECL
-__ExceptionPtrAssign(_Inout_ void*, _In_ const void*);
+__ExceptionPtrAssign(void*, const void*);
 _CRTIMP2_PURE bool __CLRCALL_PURE_OR_CDECL
-__ExceptionPtrCompare(_In_ const void*, _In_ const void*);
+__ExceptionPtrCompare(const void*, const void*);
 _CRTIMP2_PURE bool __CLRCALL_PURE_OR_CDECL
-__ExceptionPtrToBool(_In_ const void*);
-_CRTIMP2_PURE void __CLRCALL_PURE_OR_CDECL __ExceptionPtrSwap(_Inout_ void*,
-  _Inout_ void*);
+__ExceptionPtrToBool(const void*);
+_CRTIMP2_PURE void __CLRCALL_PURE_OR_CDECL __ExceptionPtrSwap(void*, void*);
 _CRTIMP2_PURE void __CLRCALL_PURE_OR_CDECL
-__ExceptionPtrCurrentException(_Out_ void*);
+__ExceptionPtrCurrentException(void*);
 [[noreturn]] _CRTIMP2_PURE void __CLRCALL_PURE_OR_CDE

[PATCH] D38522: [libc++] Support Microsoft ABI without vcruntime headers

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai added a comment.

In https://reviews.llvm.org/D38522#887768, @compnerd wrote:

> Why do we expect the tests to fail without vcruntime headers?


msvcrt's implementations of the various new/delete operators call 
`__scrt_throw_std_bad_alloc` and `__scrt_throw_std_bad_array_new_length`, which 
are found in `throw_bad_alloc.obj` inside `msvcrt.lib`. That object file also 
contains the definitions of various exception methods (e.g. 
`std::exception::~exception`) which libc++ will also define for 
`_LIBCPP_NO_VCRUNTIME`, leading to symbol conflicts between libc++ and msvcrt. 
Consequently, `_LIBCPP_NO_VCRUNTIME` must also use libc++'s definitions of the 
new/delete operators rather than msvcrt's.

The failing tests check indirect replacement, e.g. replacing `operator new`, 
calling `operator new[]`, and expecting the replaced `operator new` to be 
called. That would have worked with msvcrt's new/delete operators, since 
they're statically linked into the executable and therefore their `operator 
new[]` can call the replaced `operator new`, but it won't work with libc++'s 
new/delete operators, since libc++'s `operator new[]` is bound to its own 
`operator new`. (It would work as expected if the user replaced `operator 
new[]` in addition to `operator new`.) That's unfortunate, but it's also a 
pretty rare scenario.

On the plus side, the following tests only pass with `_LIBCPP_NO_VCRUNTIME`. I 
believe the change in `src/new.cpp` to include 
`support/runtime/new_handler_fallback.ipp` should actually not be limited to 
`_LIBCPP_NO_VCRUNTIME`; I'll investigate that in a follow-up.

  
std/language.support/support.dynamic/alloc.errors/set.new.handler/get_new_handler.pass.cpp
  
std/language.support/support.dynamic/alloc.errors/set.new.handler/set_new_handler.pass.cpp
  
std/language.support/support.dynamic/new.delete/new.delete.array/new_array.pass.cpp
  
std/language.support/support.dynamic/new.delete/new.delete.array/new_array_nothrow.pass.cpp
  std/language.support/support.dynamic/new.delete/new.delete.single/new.pass.cpp
  
std/language.support/support.dynamic/new.delete/new.delete.single/new_nothrow.pass.cpp




Comment at: src/support/runtime/exception_msvc.ipp:31
+extern "C" {
+typedef void(__CRTDECL* terminate_handler)();
+_ACRTIMP terminate_handler __cdecl set_terminate(

compnerd wrote:
> Really?  clang-format removes the space there?
> 
> typedef void (__CRTDECL * terminate_handler)(void);
> 
> seems so much more readable.
IIRC it's an issue with having a macro in a function pointer (`__CRTDECL`) in 
this case. I'll adjust the spacing manually and file a clang-format bug.


https://reviews.llvm.org/D38522



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D38522: [libc++] Support Microsoft ABI without vcruntime headers

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai added inline comments.



Comment at: src/support/runtime/exception_msvc.ipp:31
+extern "C" {
+typedef void(__CRTDECL* terminate_handler)();
+_ACRTIMP terminate_handler __cdecl set_terminate(

smeenai wrote:
> compnerd wrote:
> > Really?  clang-format removes the space there?
> > 
> > typedef void (__CRTDECL * terminate_handler)(void);
> > 
> > seems so much more readable.
> IIRC it's an issue with having a macro in a function pointer (`__CRTDECL`) in 
> this case. I'll adjust the spacing manually and file a clang-format bug.
https://bugs.llvm.org/show_bug.cgi?id=34823


https://reviews.llvm.org/D38522



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D36713: [libc++] Add a persistent way to disable availability

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai abandoned this revision.
smeenai added a comment.

I ended up handling this differently internally (via a custom site config). If 
someone else ends up needing the same functionality, they can revive it.


https://reviews.llvm.org/D36713



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D36719: [libc++] Add site config option for ABI macros

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai updated this revision to Diff 117757.
smeenai added a comment.

Address comments


https://reviews.llvm.org/D36719

Files:
  CMakeLists.txt
  docs/BuildingLibcxx.rst
  include/__config_site.in
  utils/libcxx/test/config.py


Index: utils/libcxx/test/config.py
===
--- utils/libcxx/test/config.py
+++ utils/libcxx/test/config.py
@@ -668,7 +668,7 @@
 self.config.available_features.add('libcpp-abi-version-v%s'
 % feature_macros[m])
 continue
-assert m.startswith('_LIBCPP_HAS_') or m == '_LIBCPP_ABI_UNSTABLE'
+assert m.startswith('_LIBCPP_HAS_') or m.startswith('_LIBCPP_ABI_')
 m = m.lower()[1:].replace('_', '-')
 self.config.available_features.add(m)
 return feature_macros
Index: include/__config_site.in
===
--- include/__config_site.in
+++ include/__config_site.in
@@ -24,4 +24,6 @@
 #cmakedefine _LIBCPP_HAS_THREAD_LIBRARY_EXTERNAL
 #cmakedefine _LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS
 
+@_LIBCPP_ABI_DEFINES@
+
 #endif // _LIBCPP_CONFIG_SITE
Index: docs/BuildingLibcxx.rst
===
--- docs/BuildingLibcxx.rst
+++ docs/BuildingLibcxx.rst
@@ -347,6 +347,13 @@
   Build the "unstable" ABI version of libc++. Includes all ABI changing 
features
   on top of the current stable version.
 
+.. option:: LIBCXX_ABI_DEFINES:STRING
+
+  **Default**: 
+
+  A semicolon-separated list of ABI macros which are persisted in the site
+  config header. See `include/__config` for the list of ABI macros.
+
 .. _LLVM-specific variables:
 
 LLVM-specific options
Index: CMakeLists.txt
===
--- CMakeLists.txt
+++ CMakeLists.txt
@@ -607,6 +607,19 @@
 config_define_if(LIBCXX_BUILD_EXTERNAL_THREAD_LIBRARY 
_LIBCPP_HAS_THREAD_LIBRARY_EXTERNAL)
 config_define_if(LIBCXX_HAS_MUSL_LIBC _LIBCPP_HAS_MUSL_LIBC)
 
+set(LIBCXX_ABI_DEFINES "" CACHE STRING "A semicolon separated list of ABI 
macros to define in the site config header")
+if (LIBCXX_ABI_DEFINES)
+  set(abi_defines)
+  foreach (abi_define ${LIBCXX_ABI_DEFINES})
+if (NOT abi_define MATCHES "^_LIBCPP_ABI_")
+  message(SEND_ERROR "Invalid ABI macro ${abi_define} in 
LIBCXX_ABI_DEFINES")
+endif()
+list(APPEND abi_defines "#define ${abi_define}")
+  endforeach()
+  string(REPLACE ";" "\n" abi_defines "${abi_defines}")
+  config_define(${abi_defines} _LIBCPP_ABI_DEFINES)
+endif()
+
 # By default libc++ on Windows expects to use a shared library, which requires
 # the headers to use DLL import/export semantics. However when building a
 # static library only we modify the headers to disable DLL import/export.


Index: utils/libcxx/test/config.py
===
--- utils/libcxx/test/config.py
+++ utils/libcxx/test/config.py
@@ -668,7 +668,7 @@
 self.config.available_features.add('libcpp-abi-version-v%s'
 % feature_macros[m])
 continue
-assert m.startswith('_LIBCPP_HAS_') or m == '_LIBCPP_ABI_UNSTABLE'
+assert m.startswith('_LIBCPP_HAS_') or m.startswith('_LIBCPP_ABI_')
 m = m.lower()[1:].replace('_', '-')
 self.config.available_features.add(m)
 return feature_macros
Index: include/__config_site.in
===
--- include/__config_site.in
+++ include/__config_site.in
@@ -24,4 +24,6 @@
 #cmakedefine _LIBCPP_HAS_THREAD_LIBRARY_EXTERNAL
 #cmakedefine _LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS
 
+@_LIBCPP_ABI_DEFINES@
+
 #endif // _LIBCPP_CONFIG_SITE
Index: docs/BuildingLibcxx.rst
===
--- docs/BuildingLibcxx.rst
+++ docs/BuildingLibcxx.rst
@@ -347,6 +347,13 @@
   Build the "unstable" ABI version of libc++. Includes all ABI changing features
   on top of the current stable version.
 
+.. option:: LIBCXX_ABI_DEFINES:STRING
+
+  **Default**: 
+
+  A semicolon-separated list of ABI macros which are persisted in the site
+  config header. See `include/__config` for the list of ABI macros.
+
 .. _LLVM-specific variables:
 
 LLVM-specific options
Index: CMakeLists.txt
===
--- CMakeLists.txt
+++ CMakeLists.txt
@@ -607,6 +607,19 @@
 config_define_if(LIBCXX_BUILD_EXTERNAL_THREAD_LIBRARY _LIBCPP_HAS_THREAD_LIBRARY_EXTERNAL)
 config_define_if(LIBCXX_HAS_MUSL_LIBC _LIBCPP_HAS_MUSL_LIBC)
 
+set(LIBCXX_ABI_DEFINES "" CACHE STRING "A semicolon separated list of ABI macros to define in the site config header")
+if (LIBCXX_ABI_DEFINES)
+  set(abi_defines)
+  foreach (abi_define ${LIBCXX_ABI_DEFINES})
+if (NOT abi_define MATCHES "^_LIBCPP_ABI_")
+  message(SEND_ERROR "Invalid ABI macro ${abi_define

[PATCH] D36719: [libc++] Add site config option for ABI macros

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai updated this revision to Diff 117758.
smeenai added a comment.

Fix RST


https://reviews.llvm.org/D36719

Files:
  CMakeLists.txt
  docs/BuildingLibcxx.rst
  include/__config_site.in
  utils/libcxx/test/config.py


Index: utils/libcxx/test/config.py
===
--- utils/libcxx/test/config.py
+++ utils/libcxx/test/config.py
@@ -668,7 +668,7 @@
 self.config.available_features.add('libcpp-abi-version-v%s'
 % feature_macros[m])
 continue
-assert m.startswith('_LIBCPP_HAS_') or m == '_LIBCPP_ABI_UNSTABLE'
+assert m.startswith('_LIBCPP_HAS_') or m.startswith('_LIBCPP_ABI_')
 m = m.lower()[1:].replace('_', '-')
 self.config.available_features.add(m)
 return feature_macros
Index: include/__config_site.in
===
--- include/__config_site.in
+++ include/__config_site.in
@@ -24,4 +24,6 @@
 #cmakedefine _LIBCPP_HAS_THREAD_LIBRARY_EXTERNAL
 #cmakedefine _LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS
 
+@_LIBCPP_ABI_DEFINES@
+
 #endif // _LIBCPP_CONFIG_SITE
Index: docs/BuildingLibcxx.rst
===
--- docs/BuildingLibcxx.rst
+++ docs/BuildingLibcxx.rst
@@ -347,6 +347,13 @@
   Build the "unstable" ABI version of libc++. Includes all ABI changing 
features
   on top of the current stable version.
 
+.. option:: LIBCXX_ABI_DEFINES:STRING
+
+  **Default**: ``""``
+
+  A semicolon-separated list of ABI macros which are persisted in the site
+  config header. See ``include/__config`` for the list of ABI macros.
+
 .. _LLVM-specific variables:
 
 LLVM-specific options
Index: CMakeLists.txt
===
--- CMakeLists.txt
+++ CMakeLists.txt
@@ -607,6 +607,19 @@
 config_define_if(LIBCXX_BUILD_EXTERNAL_THREAD_LIBRARY 
_LIBCPP_HAS_THREAD_LIBRARY_EXTERNAL)
 config_define_if(LIBCXX_HAS_MUSL_LIBC _LIBCPP_HAS_MUSL_LIBC)
 
+set(LIBCXX_ABI_DEFINES "" CACHE STRING "A semicolon separated list of ABI 
macros to define in the site config header")
+if (LIBCXX_ABI_DEFINES)
+  set(abi_defines)
+  foreach (abi_define ${LIBCXX_ABI_DEFINES})
+if (NOT abi_define MATCHES "^_LIBCPP_ABI_")
+  message(SEND_ERROR "Invalid ABI macro ${abi_define} in 
LIBCXX_ABI_DEFINES")
+endif()
+list(APPEND abi_defines "#define ${abi_define}")
+  endforeach()
+  string(REPLACE ";" "\n" abi_defines "${abi_defines}")
+  config_define(${abi_defines} _LIBCPP_ABI_DEFINES)
+endif()
+
 # By default libc++ on Windows expects to use a shared library, which requires
 # the headers to use DLL import/export semantics. However when building a
 # static library only we modify the headers to disable DLL import/export.


Index: utils/libcxx/test/config.py
===
--- utils/libcxx/test/config.py
+++ utils/libcxx/test/config.py
@@ -668,7 +668,7 @@
 self.config.available_features.add('libcpp-abi-version-v%s'
 % feature_macros[m])
 continue
-assert m.startswith('_LIBCPP_HAS_') or m == '_LIBCPP_ABI_UNSTABLE'
+assert m.startswith('_LIBCPP_HAS_') or m.startswith('_LIBCPP_ABI_')
 m = m.lower()[1:].replace('_', '-')
 self.config.available_features.add(m)
 return feature_macros
Index: include/__config_site.in
===
--- include/__config_site.in
+++ include/__config_site.in
@@ -24,4 +24,6 @@
 #cmakedefine _LIBCPP_HAS_THREAD_LIBRARY_EXTERNAL
 #cmakedefine _LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS
 
+@_LIBCPP_ABI_DEFINES@
+
 #endif // _LIBCPP_CONFIG_SITE
Index: docs/BuildingLibcxx.rst
===
--- docs/BuildingLibcxx.rst
+++ docs/BuildingLibcxx.rst
@@ -347,6 +347,13 @@
   Build the "unstable" ABI version of libc++. Includes all ABI changing features
   on top of the current stable version.
 
+.. option:: LIBCXX_ABI_DEFINES:STRING
+
+  **Default**: ``""``
+
+  A semicolon-separated list of ABI macros which are persisted in the site
+  config header. See ``include/__config`` for the list of ABI macros.
+
 .. _LLVM-specific variables:
 
 LLVM-specific options
Index: CMakeLists.txt
===
--- CMakeLists.txt
+++ CMakeLists.txt
@@ -607,6 +607,19 @@
 config_define_if(LIBCXX_BUILD_EXTERNAL_THREAD_LIBRARY _LIBCPP_HAS_THREAD_LIBRARY_EXTERNAL)
 config_define_if(LIBCXX_HAS_MUSL_LIBC _LIBCPP_HAS_MUSL_LIBC)
 
+set(LIBCXX_ABI_DEFINES "" CACHE STRING "A semicolon separated list of ABI macros to define in the site config header")
+if (LIBCXX_ABI_DEFINES)
+  set(abi_defines)
+  foreach (abi_define ${LIBCXX_ABI_DEFINES})
+if (NOT abi_define MATCHES "^_LIBCPP_ABI_")
+  message(SEND_ERROR "Invalid ABI macro ${abi_define}

[PATCH] D36719: [libc++] Add site config option for ABI macros

[Shoaib Meenai via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL314946: [libc++] Add site config option for ABI macros 
(authored by smeenai).

Changed prior to commit:
  https://reviews.llvm.org/D36719?vs=117758&id=117759#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D36719

Files:
  libcxx/trunk/CMakeLists.txt
  libcxx/trunk/docs/BuildingLibcxx.rst
  libcxx/trunk/include/__config_site.in
  libcxx/trunk/utils/libcxx/test/config.py


Index: libcxx/trunk/CMakeLists.txt
===
--- libcxx/trunk/CMakeLists.txt
+++ libcxx/trunk/CMakeLists.txt
@@ -607,6 +607,19 @@
 config_define_if(LIBCXX_BUILD_EXTERNAL_THREAD_LIBRARY 
_LIBCPP_HAS_THREAD_LIBRARY_EXTERNAL)
 config_define_if(LIBCXX_HAS_MUSL_LIBC _LIBCPP_HAS_MUSL_LIBC)
 
+set(LIBCXX_ABI_DEFINES "" CACHE STRING "A semicolon separated list of ABI 
macros to define in the site config header")
+if (LIBCXX_ABI_DEFINES)
+  set(abi_defines)
+  foreach (abi_define ${LIBCXX_ABI_DEFINES})
+if (NOT abi_define MATCHES "^_LIBCPP_ABI_")
+  message(SEND_ERROR "Invalid ABI macro ${abi_define} in 
LIBCXX_ABI_DEFINES")
+endif()
+list(APPEND abi_defines "#define ${abi_define}")
+  endforeach()
+  string(REPLACE ";" "\n" abi_defines "${abi_defines}")
+  config_define(${abi_defines} _LIBCPP_ABI_DEFINES)
+endif()
+
 # By default libc++ on Windows expects to use a shared library, which requires
 # the headers to use DLL import/export semantics. However when building a
 # static library only we modify the headers to disable DLL import/export.
Index: libcxx/trunk/utils/libcxx/test/config.py
===
--- libcxx/trunk/utils/libcxx/test/config.py
+++ libcxx/trunk/utils/libcxx/test/config.py
@@ -668,7 +668,7 @@
 self.config.available_features.add('libcpp-abi-version-v%s'
 % feature_macros[m])
 continue
-assert m.startswith('_LIBCPP_HAS_') or m == '_LIBCPP_ABI_UNSTABLE'
+assert m.startswith('_LIBCPP_HAS_') or m.startswith('_LIBCPP_ABI_')
 m = m.lower()[1:].replace('_', '-')
 self.config.available_features.add(m)
 return feature_macros
Index: libcxx/trunk/docs/BuildingLibcxx.rst
===
--- libcxx/trunk/docs/BuildingLibcxx.rst
+++ libcxx/trunk/docs/BuildingLibcxx.rst
@@ -347,6 +347,13 @@
   Build the "unstable" ABI version of libc++. Includes all ABI changing 
features
   on top of the current stable version.
 
+.. option:: LIBCXX_ABI_DEFINES:STRING
+
+  **Default**: ``""``
+
+  A semicolon-separated list of ABI macros to persist in the site config 
header.
+  See ``include/__config`` for the list of ABI macros.
+
 .. _LLVM-specific variables:
 
 LLVM-specific options
Index: libcxx/trunk/include/__config_site.in
===
--- libcxx/trunk/include/__config_site.in
+++ libcxx/trunk/include/__config_site.in
@@ -24,4 +24,6 @@
 #cmakedefine _LIBCPP_HAS_THREAD_LIBRARY_EXTERNAL
 #cmakedefine _LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS
 
+@_LIBCPP_ABI_DEFINES@
+
 #endif // _LIBCPP_CONFIG_SITE


Index: libcxx/trunk/CMakeLists.txt
===
--- libcxx/trunk/CMakeLists.txt
+++ libcxx/trunk/CMakeLists.txt
@@ -607,6 +607,19 @@
 config_define_if(LIBCXX_BUILD_EXTERNAL_THREAD_LIBRARY _LIBCPP_HAS_THREAD_LIBRARY_EXTERNAL)
 config_define_if(LIBCXX_HAS_MUSL_LIBC _LIBCPP_HAS_MUSL_LIBC)
 
+set(LIBCXX_ABI_DEFINES "" CACHE STRING "A semicolon separated list of ABI macros to define in the site config header")
+if (LIBCXX_ABI_DEFINES)
+  set(abi_defines)
+  foreach (abi_define ${LIBCXX_ABI_DEFINES})
+if (NOT abi_define MATCHES "^_LIBCPP_ABI_")
+  message(SEND_ERROR "Invalid ABI macro ${abi_define} in LIBCXX_ABI_DEFINES")
+endif()
+list(APPEND abi_defines "#define ${abi_define}")
+  endforeach()
+  string(REPLACE ";" "\n" abi_defines "${abi_defines}")
+  config_define(${abi_defines} _LIBCPP_ABI_DEFINES)
+endif()
+
 # By default libc++ on Windows expects to use a shared library, which requires
 # the headers to use DLL import/export semantics. However when building a
 # static library only we modify the headers to disable DLL import/export.
Index: libcxx/trunk/utils/libcxx/test/config.py
===
--- libcxx/trunk/utils/libcxx/test/config.py
+++ libcxx/trunk/utils/libcxx/test/config.py
@@ -668,7 +668,7 @@
 self.config.available_features.add('libcpp-abi-version-v%s'
 % feature_macros[m])
 continue
-assert m.startswith('_LIBCPP_HAS_') or m == '_LIBCPP_ABI_UNSTABLE'
+assert m.startswith('_LIBCPP_HAS_') or m.startswith('_LIBCPP_ABI_')
 m = m.lower()[1:].replace('_', '-')
 self.config.available_features.add(m)

[PATCH] D31363: [libc++] Remove cmake glob for source files

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai added subscribers: zturner, rjmccall.
smeenai added a comment.

@rjmccall, this adds a libc++ build dependency on LLVM's cmake modules. There 
were some issues when @zturner had added a similar dependency for his work on 
lit. To confirm, Apple still cares about the use case of building libc++ 
without having any LLVM cmake modules available (either from source or from an 
LLVM installation), right?


https://reviews.llvm.org/D31363



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D38599: Remove warnings for dynamic_cast fallback.

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai added a comment.

Does dlopen cause issues even with `RTLD_GLOBAL`?


Repository:
  rL LLVM

https://reviews.llvm.org/D38599



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D38522: [libc++] Support Microsoft ABI without vcruntime headers

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai accepted this revision.
smeenai added a comment.
This revision is now accepted and ready to land.

I spoke to @EricWF on IRC last week and got his approval to commit this without 
review if no one had gotten to it in a couple of days, so I'm going ahead with 
that.


https://reviews.llvm.org/D38522



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D38522: [libc++] Support Microsoft ABI without vcruntime headers

[Shoaib Meenai via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL315234: [libc++] Support Microsoft ABI without vcruntime 
headers (authored by smeenai).

Changed prior to commit:
  https://reviews.llvm.org/D38522?vs=117613&id=118251#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D38522

Files:
  libcxx/trunk/CMakeLists.txt
  libcxx/trunk/docs/UsingLibcxx.rst
  libcxx/trunk/include/__config_site.in
  libcxx/trunk/include/exception
  libcxx/trunk/include/new
  libcxx/trunk/src/new.cpp
  libcxx/trunk/src/support/runtime/exception_msvc.ipp
  libcxx/trunk/src/support/runtime/exception_pointer_msvc.ipp
  
libcxx/trunk/test/std/language.support/support.dynamic/new.delete/new.delete.array/new_array_nothrow_replace.pass.cpp
  
libcxx/trunk/test/std/language.support/support.dynamic/new.delete/new.delete.array/new_array_replace.pass.cpp
  
libcxx/trunk/test/std/language.support/support.dynamic/new.delete/new.delete.single/new_nothrow_replace.pass.cpp
  libcxx/trunk/utils/libcxx/test/config.py

Index: libcxx/trunk/CMakeLists.txt
===
--- libcxx/trunk/CMakeLists.txt
+++ libcxx/trunk/CMakeLists.txt
@@ -615,6 +615,7 @@
 config_define_if(LIBCXX_HAS_EXTERNAL_THREAD_API _LIBCPP_HAS_THREAD_API_EXTERNAL)
 config_define_if(LIBCXX_BUILD_EXTERNAL_THREAD_LIBRARY _LIBCPP_HAS_THREAD_LIBRARY_EXTERNAL)
 config_define_if(LIBCXX_HAS_MUSL_LIBC _LIBCPP_HAS_MUSL_LIBC)
+config_define_if(LIBCXX_NO_VCRUNTIME _LIBCPP_NO_VCRUNTIME)
 
 if (LIBCXX_ABI_DEFINES)
   set(abi_defines)
Index: libcxx/trunk/utils/libcxx/test/config.py
===
--- libcxx/trunk/utils/libcxx/test/config.py
+++ libcxx/trunk/utils/libcxx/test/config.py
@@ -668,6 +668,9 @@
 self.config.available_features.add('libcpp-abi-version-v%s'
 % feature_macros[m])
 continue
+if m == '_LIBCPP_NO_VCRUNTIME':
+self.config.available_features.add('libcpp-no-vcruntime')
+continue
 assert m.startswith('_LIBCPP_HAS_') or m.startswith('_LIBCPP_ABI_')
 m = m.lower()[1:].replace('_', '-')
 self.config.available_features.add(m)
Index: libcxx/trunk/docs/UsingLibcxx.rst
===
--- libcxx/trunk/docs/UsingLibcxx.rst
+++ libcxx/trunk/docs/UsingLibcxx.rst
@@ -185,6 +185,26 @@
 * Giving `set`, `map`, `multiset`, `multimap` a comparator which is not
   const callable.
 
+**_LIBCPP_NO_VCRUNTIME**:
+  Microsoft's C and C++ headers are fairly entangled, and some of their C++
+  headers are fairly hard to avoid. In particular, `vcruntime_new.h` gets pulled
+  in from a lot of other headers and provides definitions which clash with
+  libc++ headers, such as `nothrow_t` (note that `nothrow_t` is a struct, so
+  there's no way for libc++ to provide a compatible definition, since you can't
+  have multiple definitions).
+
+  By default, libc++ solves this problem by deferring to Microsoft's vcruntime
+  headers where needed. However, it may be undesirable to depend on vcruntime
+  headers, since they may not always be available in cross-compilation setups,
+  or they may clash with other headers. The `_LIBCPP_NO_VCRUNTIME` macro
+  prevents libc++ from depending on vcruntime headers. Consequently, it also
+  prevents libc++ headers from being interoperable with vcruntime headers (from
+  the aforementioned clashes), so users of this macro are promising to not
+  attempt to combine libc++ headers with the problematic vcruntime headers. This
+  macro also currently prevents certain `operator new`/`operator delete`
+  replacement scenarios from working, e.g. replacing `operator new` and
+  expecting a non-replaced `operator new[]` to call the replaced `operator new`.
+
 C++17 Specific Configuration Macros
 ---
 **_LIBCPP_ENABLE_CXX17_REMOVED_FEATURES**:
Index: libcxx/trunk/src/support/runtime/exception_pointer_msvc.ipp
===
--- libcxx/trunk/src/support/runtime/exception_pointer_msvc.ipp
+++ libcxx/trunk/src/support/runtime/exception_pointer_msvc.ipp
@@ -10,26 +10,32 @@
 
 #include 
 #include 
-#include  // for _CRTIMP2_PURE
 
-_CRTIMP2_PURE void __CLRCALL_PURE_OR_CDECL __ExceptionPtrCreate(_Out_ void*);
-_CRTIMP2_PURE void __CLRCALL_PURE_OR_CDECL __ExceptionPtrDestroy(_Inout_ void*);
-_CRTIMP2_PURE void __CLRCALL_PURE_OR_CDECL __ExceptionPtrCopy(_Out_ void*,
-  _In_ const void*);
+#if !defined(_CRTIMP2_PURE)
+#define _CRTIMP2_PURE __declspec(dllimport)
+#endif
+
+#if !defined(__CLRCALL_PURE_OR_CDECL)
+#define __CLRCALL_PURE_OR_CDECL __cdecl
+#endif
+
+_CRTIMP2_PURE void __CLRCALL_PURE_OR_CDECL __ExceptionPtrCreate(void*);
+_CRTIMP2_PURE void __CLRCALL_PURE_OR_CDECL __ExceptionPtrDestroy(void*);
+_CRTIMP2_PURE v

[PATCH] D37182: [libcxx] Special visibility macros for the experimental library

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai added a comment.

Sorry, this has been on my queue for a long time, but I haven't gotten the 
chance to get to it yet. I'll try to take a look (at this and your other 
patches) in the next few days.


https://reviews.llvm.org/D37182



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D39149: [libc++] Prevent tautological comparisons

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai created this revision.

Tip-of-tree clang produces `-Wtautological-constant-compare` for
tautological constant comparisons, and these pieces of code will trigger
that diagnostic when `int` and `long` have the same size (for example,
when compiling for a 32-bit target, or for Windows 64-bit).

I personally find the diagnostic to be pretty unhelpful when dealing
with templates, since my change is essentially manually writing out the
code the compiler would have (or at least should have) produced anyway.
An alternative would be to just disable the diagnostic around these
regions instead of manually avoiding the comparisons.


https://reviews.llvm.org/D39149

Files:
  include/istream
  src/string.cpp


Index: src/string.cpp
===
--- src/string.cpp
+++ src/string.cpp
@@ -88,8 +88,10 @@
 {
 // Use long as no Standard string to integer exists.
 long r = as_integer_helper( func, s, idx, base, strtol );
+#if __SIZEOF_INT__ != __SIZEOF_LONG__
 if (r < numeric_limits::min() || numeric_limits::max() < r)
 throw_from_string_out_of_range(func);
+#endif
 return static_cast(r);
 }
 
@@ -133,8 +135,10 @@
 {
 // Use long as no Stantard string to integer exists.
 long r = as_integer_helper( func, s, idx, base, wcstol );
+#if __SIZEOF_INT__ != __SIZEOF_LONG__
 if (r < numeric_limits::min() || numeric_limits::max() < r)
 throw_from_string_out_of_range(func);
+#endif
 return static_cast(r);
 }
 
Index: include/istream
===
--- include/istream
+++ include/istream
@@ -711,6 +711,7 @@
 ios_base::iostate __err = ios_base::goodbit;
 long __temp;
 use_facet<_Fp>(this->getloc()).get(_Ip(*this), _Ip(), *this, 
__err, __temp);
+#if __SIZEOF_INT__ != __SIZEOF_LONG__
 if (__temp < numeric_limits::min())
 {
 __err |= ios_base::failbit;
@@ -723,6 +724,9 @@
 }
 else
 __n = static_cast(__temp);
+#else
+__n = static_cast(__temp);
+#endif
 this->setstate(__err);
 }
 #ifndef _LIBCPP_NO_EXCEPTIONS


Index: src/string.cpp
===
--- src/string.cpp
+++ src/string.cpp
@@ -88,8 +88,10 @@
 {
 // Use long as no Standard string to integer exists.
 long r = as_integer_helper( func, s, idx, base, strtol );
+#if __SIZEOF_INT__ != __SIZEOF_LONG__
 if (r < numeric_limits::min() || numeric_limits::max() < r)
 throw_from_string_out_of_range(func);
+#endif
 return static_cast(r);
 }
 
@@ -133,8 +135,10 @@
 {
 // Use long as no Stantard string to integer exists.
 long r = as_integer_helper( func, s, idx, base, wcstol );
+#if __SIZEOF_INT__ != __SIZEOF_LONG__
 if (r < numeric_limits::min() || numeric_limits::max() < r)
 throw_from_string_out_of_range(func);
+#endif
 return static_cast(r);
 }
 
Index: include/istream
===
--- include/istream
+++ include/istream
@@ -711,6 +711,7 @@
 ios_base::iostate __err = ios_base::goodbit;
 long __temp;
 use_facet<_Fp>(this->getloc()).get(_Ip(*this), _Ip(), *this, __err, __temp);
+#if __SIZEOF_INT__ != __SIZEOF_LONG__
 if (__temp < numeric_limits::min())
 {
 __err |= ios_base::failbit;
@@ -723,6 +724,9 @@
 }
 else
 __n = static_cast(__temp);
+#else
+__n = static_cast(__temp);
+#endif
 this->setstate(__err);
 }
 #ifndef _LIBCPP_NO_EXCEPTIONS
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D38704: [libunwind] Abstract rwlocks into a class, provide a SRW lock implementation for windows

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai added a comment.

BTW LLVM requires a minimum of Windows 7 according to 
https://releases.llvm.org/3.8.0/docs/ReleaseNotes.html, so you can rely on SRW 
locks always being present. If LLVM still has a fallback path for when SRW 
locks are absent, that could be cleaned up.


https://reviews.llvm.org/D38704



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D42933: [Sema] Avoid -Wformat warning for NSInteger/NSUInteger 'int' values with %zu/%zi long specifiers

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai added subscribers: compnerd, smeenai.
smeenai added a comment.

This seems ... suboptimal. It breaks existing code in the sense that their code 
was already broken, and the compiler is just diagnosing it correctly now. Note 
that Apple themselves recommend casting and using a proper printf specifier: 
https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/Strings/Articles/formatSpecifiers.html
 (under Platform Dependencies).


Repository:
  rC Clang

https://reviews.llvm.org/D42933



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D43033: [WinEH] Put funclet bundles on inline asm calls

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai added a comment.

LGTM, but I'd like @majnemer to take a look, since I'm not very familiar with 
this code.


https://reviews.llvm.org/D43033



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D43110: [Sema] Don't mark plain MS enums as fixed

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai added a comment.

We've seen lots of spurious warnings from this. Thanks for the fix!


https://reviews.llvm.org/D43110



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D43184: [WIP] [ItaniunCXXABI] Add an option for loading the type info vtable with dllimport

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai added a comment.

FYI, binutils auto-import actually creates a fake IAT entry rather than using a 
dynamic initializer. I think it's actually a pretty cute trick. 
http://blog.omega-prime.co.uk/2011/07/04/everything-you-never-wanted-to-know-about-dlls/#how-auto-import-works
 has details. That only works when you're referencing an external imported 
symbol directly though, and breaks when you need an offset from the imported 
symbol.


Repository:
  rC Clang

https://reviews.llvm.org/D43184



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D43586: CodeGen: handle blocks correctly when inalloca'ed

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai added a comment.

Patch is missing context.




Comment at: lib/CodeGen/CGDecl.cpp:1851
 // The only implicit argument a block has is its literal.
 // We assume this is always passed directly.
 if (BlockInfo) {

This comment needs to be updated.


Repository:
  rC Clang

https://reviews.llvm.org/D43586



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D43700: Emit proper CodeView even when not using the cl driver.

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai added a comment.

We were affected by this too. Thanks for fixing!

(We're actually using CodeView + DWARF, since we have a bunch of tooling built 
around DWARF. We use the gcc-style driver for legacy reasons.)


https://reviews.llvm.org/D43700



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D43700: Emit proper CodeView even when not using the cl driver.

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai added a comment.

The `-g` meaning `-gcodeview` for MSVC environments change should be a separate 
diff though, right?


https://reviews.llvm.org/D43700



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D33082: Fix Libc++ build with MinGW64

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai accepted this revision.
smeenai added a comment.

LGTM. Thanks for all the revisions!


https://reviews.llvm.org/D33082



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D32109: [Driver] Limit .exe extension addition to Windows hosts

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai abandoned this revision.
smeenai added a comment.

Will just drop the .exe entirely, since that works


https://reviews.llvm.org/D32109



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D33923: [Driver] Don't force .exe suffix for lld

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai created this revision.

When cross-compiling to Windows using lld, we want the driver to invoke
it as lld-link rather than lld-link.exe. On Windows, the LLVM fs
functions take care of adding the .exe suffix where necessary, so we can
just drop the addition in the toolchain entirely.


https://reviews.llvm.org/D33923

Files:
  lib/Driver/ToolChains/MSVC.cpp
  test/Driver/cl-link.c


Index: test/Driver/cl-link.c
===
--- test/Driver/cl-link.c
+++ test/Driver/cl-link.c
@@ -56,4 +56,4 @@
 // NONEXISTENT: nonexistent
 
 // RUN: %clang_cl /Tc%s -fuse-ld=lld -### 2>&1 | FileCheck 
--check-prefix=USE_LLD %s
-// USE_LLD: lld-link.exe
+// USE_LLD: lld-link
Index: lib/Driver/ToolChains/MSVC.cpp
===
--- lib/Driver/ToolChains/MSVC.cpp
+++ lib/Driver/ToolChains/MSVC.cpp
@@ -529,9 +529,7 @@
   SkipSettingEnvironment:;
 #endif
   } else {
-linkPath = Linker;
-llvm::sys::path::replace_extension(linkPath, "exe");
-linkPath = TC.GetProgramPath(linkPath.c_str());
+linkPath = TC.GetProgramPath(Linker.str().c_str());
   }
 
   auto LinkCmd = llvm::make_unique(


Index: test/Driver/cl-link.c
===
--- test/Driver/cl-link.c
+++ test/Driver/cl-link.c
@@ -56,4 +56,4 @@
 // NONEXISTENT: nonexistent
 
 // RUN: %clang_cl /Tc%s -fuse-ld=lld -### 2>&1 | FileCheck --check-prefix=USE_LLD %s
-// USE_LLD: lld-link.exe
+// USE_LLD: lld-link
Index: lib/Driver/ToolChains/MSVC.cpp
===
--- lib/Driver/ToolChains/MSVC.cpp
+++ lib/Driver/ToolChains/MSVC.cpp
@@ -529,9 +529,7 @@
   SkipSettingEnvironment:;
 #endif
   } else {
-linkPath = Linker;
-llvm::sys::path::replace_extension(linkPath, "exe");
-linkPath = TC.GetProgramPath(linkPath.c_str());
+linkPath = TC.GetProgramPath(Linker.str().c_str());
   }
 
   auto LinkCmd = llvm::make_unique(
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D33923: [Driver] Don't force .exe suffix for lld

[Shoaib Meenai via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL304761: [Driver] Don't force .exe suffix for lld (authored 
by smeenai).

Changed prior to commit:
  https://reviews.llvm.org/D33923?vs=101495&id=101502#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D33923

Files:
  cfe/trunk/lib/Driver/ToolChains/MSVC.cpp
  cfe/trunk/test/Driver/cl-link.c


Index: cfe/trunk/test/Driver/cl-link.c
===
--- cfe/trunk/test/Driver/cl-link.c
+++ cfe/trunk/test/Driver/cl-link.c
@@ -56,4 +56,4 @@
 // NONEXISTENT: nonexistent
 
 // RUN: %clang_cl /Tc%s -fuse-ld=lld -### 2>&1 | FileCheck 
--check-prefix=USE_LLD %s
-// USE_LLD: lld-link.exe
+// USE_LLD: lld-link
Index: cfe/trunk/lib/Driver/ToolChains/MSVC.cpp
===
--- cfe/trunk/lib/Driver/ToolChains/MSVC.cpp
+++ cfe/trunk/lib/Driver/ToolChains/MSVC.cpp
@@ -529,9 +529,7 @@
   SkipSettingEnvironment:;
 #endif
   } else {
-linkPath = Linker;
-llvm::sys::path::replace_extension(linkPath, "exe");
-linkPath = TC.GetProgramPath(linkPath.c_str());
+linkPath = TC.GetProgramPath(Linker.str().c_str());
   }
 
   auto LinkCmd = llvm::make_unique(


Index: cfe/trunk/test/Driver/cl-link.c
===
--- cfe/trunk/test/Driver/cl-link.c
+++ cfe/trunk/test/Driver/cl-link.c
@@ -56,4 +56,4 @@
 // NONEXISTENT: nonexistent
 
 // RUN: %clang_cl /Tc%s -fuse-ld=lld -### 2>&1 | FileCheck --check-prefix=USE_LLD %s
-// USE_LLD: lld-link.exe
+// USE_LLD: lld-link
Index: cfe/trunk/lib/Driver/ToolChains/MSVC.cpp
===
--- cfe/trunk/lib/Driver/ToolChains/MSVC.cpp
+++ cfe/trunk/lib/Driver/ToolChains/MSVC.cpp
@@ -529,9 +529,7 @@
   SkipSettingEnvironment:;
 #endif
   } else {
-linkPath = Linker;
-llvm::sys::path::replace_extension(linkPath, "exe");
-linkPath = TC.GetProgramPath(linkPath.c_str());
+linkPath = TC.GetProgramPath(Linker.str().c_str());
   }
 
   auto LinkCmd = llvm::make_unique(
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D34588: Check for _MSC_VER before define _LIBCPP_MSVCRT

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai added reviewers: compnerd, majnemer, rnk.
smeenai added subscribers: majnemer, compnerd.
smeenai added a comment.

This looks sensible to me. I don't know if there are any scenarios in which 
you'd be using the Microsoft CRT without having `_MSC_VER` defined, however. 
Added some people who may have a better idea of that (@compnerd, @majnemer and 
@rnk)




Comment at: include/__config:234-235
+// a MS compatibility version is specified.
 #  ifndef __MINGW32__
-#define _LIBCPP_MSVCRT // Using Microsoft's C Runtime library
+#ifdef _MSC_VER
+#  define _LIBCPP_MSVCRT // Using Microsoft's C Runtime library

You can combine this into just

```
#  if defined(_MSC_VER) && !defined(__MINGW32__)
```

I don't know if `__MINGW32__` and `_MSC_VER` will ever be compiled 
simultaneously. (clang never defines `_MSC_VER` for its MinGW triples, for 
example.)


https://reviews.llvm.org/D34588



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D41368: [libc++] Ignore bogus tautologic comparison warnings

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai created this revision.
smeenai added reviewers: EricWF, mclow.lists.
Herald added a subscriber: cfe-commits.

clang 6 has a new diagnostic -Wtautological-constant-compare, which
fires for the code in question when int and long have the same size (for
example, when compiling for a 32-bit target, or for Windows 64-bit). The
warning is somewhat bogus here, since the code is only tautological on


Repository:
  rCXX libc++

https://reviews.llvm.org/D41368

Files:
  include/istream
  src/string.cpp


Index: src/string.cpp
===
--- src/string.cpp
+++ src/string.cpp
@@ -80,6 +80,11 @@
 V
 as_integer(const string& func, const S& s, size_t* idx, int base);
 
+#if __clang_major__ >= 6
+#pragma clang diagnostic push
+#pragma clang diagnostic ignored "-Wtautological-constant-compare"
+#endif
+
 // string
 template<>
 inline
@@ -93,6 +98,10 @@
 return static_cast(r);
 }
 
+#if __clang_major__ >= 6
+#pragma clang diagnostic pop
+#endif
+
 template<>
 inline
 long
@@ -125,6 +134,11 @@
 return as_integer_helper( func, s, idx, base, strtoull 
);
 }
 
+#if __clang_major__ >= 6
+#pragma clang diagnostic push
+#pragma clang diagnostic ignored "-Wtautological-constant-compare"
+#endif
+
 // wstring
 template<>
 inline
@@ -138,6 +152,10 @@
 return static_cast(r);
 }
 
+#if __clang_major__ >= 6
+#pragma clang diagnostic pop
+#endif
+
 template<>
 inline
 long
Index: include/istream
===
--- include/istream
+++ include/istream
@@ -695,6 +695,11 @@
 return *this;
 }
 
+#if __clang_major__ >= 6
+#pragma clang diagnostic push
+#pragma clang diagnostic ignored "-Wtautological-constant-compare"
+#endif
+
 template 
 basic_istream<_CharT, _Traits>&
 basic_istream<_CharT, _Traits>::operator>>(int& __n)
@@ -735,6 +740,10 @@
 return *this;
 }
 
+#if __clang_major__ >= 6
+#pragma clang diagnostic pop
+#endif // __clang__
+
 template
 basic_istream<_CharT, _Traits>&
 operator>>(basic_istream<_CharT, _Traits>& __is, _CharT* __s)


Index: src/string.cpp
===
--- src/string.cpp
+++ src/string.cpp
@@ -80,6 +80,11 @@
 V
 as_integer(const string& func, const S& s, size_t* idx, int base);
 
+#if __clang_major__ >= 6
+#pragma clang diagnostic push
+#pragma clang diagnostic ignored "-Wtautological-constant-compare"
+#endif
+
 // string
 template<>
 inline
@@ -93,6 +98,10 @@
 return static_cast(r);
 }
 
+#if __clang_major__ >= 6
+#pragma clang diagnostic pop
+#endif
+
 template<>
 inline
 long
@@ -125,6 +134,11 @@
 return as_integer_helper( func, s, idx, base, strtoull );
 }
 
+#if __clang_major__ >= 6
+#pragma clang diagnostic push
+#pragma clang diagnostic ignored "-Wtautological-constant-compare"
+#endif
+
 // wstring
 template<>
 inline
@@ -138,6 +152,10 @@
 return static_cast(r);
 }
 
+#if __clang_major__ >= 6
+#pragma clang diagnostic pop
+#endif
+
 template<>
 inline
 long
Index: include/istream
===
--- include/istream
+++ include/istream
@@ -695,6 +695,11 @@
 return *this;
 }
 
+#if __clang_major__ >= 6
+#pragma clang diagnostic push
+#pragma clang diagnostic ignored "-Wtautological-constant-compare"
+#endif
+
 template 
 basic_istream<_CharT, _Traits>&
 basic_istream<_CharT, _Traits>::operator>>(int& __n)
@@ -735,6 +740,10 @@
 return *this;
 }
 
+#if __clang_major__ >= 6
+#pragma clang diagnostic pop
+#endif // __clang__
+
 template
 basic_istream<_CharT, _Traits>&
 operator>>(basic_istream<_CharT, _Traits>& __is, _CharT* __s)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D41368: [libc++] Ignore bogus tautologic comparison warnings

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai updated this revision to Diff 127416.
smeenai added a comment.

Remove stray comment


Repository:
  rCXX libc++

https://reviews.llvm.org/D41368

Files:
  include/istream
  src/string.cpp


Index: src/string.cpp
===
--- src/string.cpp
+++ src/string.cpp
@@ -80,6 +80,11 @@
 V
 as_integer(const string& func, const S& s, size_t* idx, int base);
 
+#if __clang_major__ >= 6
+#pragma clang diagnostic push
+#pragma clang diagnostic ignored "-Wtautological-constant-compare"
+#endif
+
 // string
 template<>
 inline
@@ -93,6 +98,10 @@
 return static_cast(r);
 }
 
+#if __clang_major__ >= 6
+#pragma clang diagnostic pop
+#endif
+
 template<>
 inline
 long
@@ -125,6 +134,11 @@
 return as_integer_helper( func, s, idx, base, strtoull 
);
 }
 
+#if __clang_major__ >= 6
+#pragma clang diagnostic push
+#pragma clang diagnostic ignored "-Wtautological-constant-compare"
+#endif
+
 // wstring
 template<>
 inline
@@ -138,6 +152,10 @@
 return static_cast(r);
 }
 
+#if __clang_major__ >= 6
+#pragma clang diagnostic pop
+#endif
+
 template<>
 inline
 long
Index: include/istream
===
--- include/istream
+++ include/istream
@@ -695,6 +695,11 @@
 return *this;
 }
 
+#if __clang_major__ >= 6
+#pragma clang diagnostic push
+#pragma clang diagnostic ignored "-Wtautological-constant-compare"
+#endif
+
 template 
 basic_istream<_CharT, _Traits>&
 basic_istream<_CharT, _Traits>::operator>>(int& __n)
@@ -735,6 +740,10 @@
 return *this;
 }
 
+#if __clang_major__ >= 6
+#pragma clang diagnostic pop
+#endif
+
 template
 basic_istream<_CharT, _Traits>&
 operator>>(basic_istream<_CharT, _Traits>& __is, _CharT* __s)


Index: src/string.cpp
===
--- src/string.cpp
+++ src/string.cpp
@@ -80,6 +80,11 @@
 V
 as_integer(const string& func, const S& s, size_t* idx, int base);
 
+#if __clang_major__ >= 6
+#pragma clang diagnostic push
+#pragma clang diagnostic ignored "-Wtautological-constant-compare"
+#endif
+
 // string
 template<>
 inline
@@ -93,6 +98,10 @@
 return static_cast(r);
 }
 
+#if __clang_major__ >= 6
+#pragma clang diagnostic pop
+#endif
+
 template<>
 inline
 long
@@ -125,6 +134,11 @@
 return as_integer_helper( func, s, idx, base, strtoull );
 }
 
+#if __clang_major__ >= 6
+#pragma clang diagnostic push
+#pragma clang diagnostic ignored "-Wtautological-constant-compare"
+#endif
+
 // wstring
 template<>
 inline
@@ -138,6 +152,10 @@
 return static_cast(r);
 }
 
+#if __clang_major__ >= 6
+#pragma clang diagnostic pop
+#endif
+
 template<>
 inline
 long
Index: include/istream
===
--- include/istream
+++ include/istream
@@ -695,6 +695,11 @@
 return *this;
 }
 
+#if __clang_major__ >= 6
+#pragma clang diagnostic push
+#pragma clang diagnostic ignored "-Wtautological-constant-compare"
+#endif
+
 template 
 basic_istream<_CharT, _Traits>&
 basic_istream<_CharT, _Traits>::operator>>(int& __n)
@@ -735,6 +740,10 @@
 return *this;
 }
 
+#if __clang_major__ >= 6
+#pragma clang diagnostic pop
+#endif
+
 template
 basic_istream<_CharT, _Traits>&
 operator>>(basic_istream<_CharT, _Traits>& __is, _CharT* __s)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D39149: [libc++] Prevent tautological comparisons

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai added a comment.

I put up https://reviews.llvm.org/D41368 to just suppress the warnings instead.


https://reviews.llvm.org/D39149



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D41368: [libc++] Ignore bogus tautologic comparison warnings

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai added a comment.

@mclow.lists are you okay with this approach? I'm also fine using a cast to 
silence the warning, as @zturner suggested, but we should suppress the warning 
in some way, otherwise libc++ 6 is gonna have compile warnings with clang 6 out 
of the box, which isn't great.

A third alternative, which is the least invasive, though not complete in some 
sense: we just add `-Wno-tautological-constant-compare` to the compile flags 
for libc++ (in CMake), to suppress the warning during libc++'s compilation. 
There's still an instance of the warning in a header, but all other clients of 
the header should treat it as a system header (in which case warnings will be 
suppressed anyway). It's not targeted at all and could suppress legitimate 
instances of the warning though.


Repository:
  rCXX libc++

https://reviews.llvm.org/D41368



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D41368: [libc++] Ignore bogus tautologic comparison warnings

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai added a comment.

Also FWIW I agree with you that the warning is completely bogus here, but it 
looks like the fix to that warning isn't gonna make it into clang 6, at least, 
so we have to adjust accordingly.


Repository:
  rCXX libc++

https://reviews.llvm.org/D41368



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D39462: [Sema] Implement -Wmaybe-tautological-constant-compare for when the tautologicalness is data model dependent

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai added a comment.

I posted to cfe-dev: 
http://lists.llvm.org/pipermail/cfe-dev/2017-December/056450.html


Repository:
  rL LLVM

https://reviews.llvm.org/D39462



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D41660: [cmake] Add new linux toolchain file

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai added a comment.

Why is this a cache file rather than a toolchain file (but passing itself as a 
toolchain file to CMake under some circumstances?) Aren't toolchain files 
traditionally used for cross-compilation?




Comment at: cmake/caches/linux-toolchain.cmake:20
+# of other sub-projects on the host system, but fail because they
+# don't specify NO_CMAKE_FIND_ROOT_PATH.  The following pathes are
+# reqired to build these projects:

Typo: patches


Repository:
  rC Clang

https://reviews.llvm.org/D41660



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D41660: [cmake] Add new linux toolchain file

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai added a comment.

In https://reviews.llvm.org/D41660#965686, @hintonda wrote:

> In https://reviews.llvm.org/D41660#965656, @smeenai wrote:
>
> >
>
>
> Cache files are preferred since they are only loaded once


Isn't that precisely the behavior needed for cross-compilation though? You want 
all of your CMake configuration checks (which are independent CMake configures) 
to load your toolchain file, which is what you get automatically (and cache 
files don't behave that way).

From what I understand, the if part of the top-level `if(DEFINED SYSROOT)` is 
essentially functioning as a cache file to set up the stage2 build, and the 
else part is used as a toolchain file for that build. I think it would be 
cleaner to separate the two out; other cache files seem to be split out into 
stage1 and stage2 caches, for example (over here it would be stage1 cache and a 
stage2 toolchain, but the concept is similar).




Comment at: cmake/caches/linux-toolchain.cmake:2
+# This file is intended to support cross compiling a linux toolchain
+# on any host system, includind Darwin.
+#

Cross-compilation terminology is kinda weird, and traditionally, the "host" is 
actually the system the built binaries will be run on (Linux in this case), 
whereas the build machine is the "build" (but of course that word is super 
ambiguous). I think LLVM generally sticks to that terminology though, e.g. 
`LLVM_HOST_TRIPLE`.



Comment at: cmake/caches/linux-toolchain.cmake:84
+  else()
+set(BOOTSTRAP_STAGE2_PROJECTS "clang;libcxx;libcxxabi;libunwind" CACHE 
STRING "" FORCE)
+  endif()

Nit: write this out as a list instead of a string with semicolons? (I know 
they're equivalent, but the list reads nicer IMO.)



Comment at: cmake/caches/linux-toolchain.cmake:88
+  # Required on non-elf hosts.
+  set(ADDITIONAL_CLANG_BOOTSTRAP_DEPS "lld;llvm-ar;llvm-ranlib" CACHE STRING 
"")
+

Not exactly related, but I wonder why the LLVM build needs ranlib (rather than 
just invoking ar appropriately).



Comment at: cmake/caches/linux-toolchain.cmake:102
+else()
+  set(CMAKE_SYSTEM_NAME Linux CACHE STRING "" FORCE)
+

The CMake documentation for CMAKE_SYSTEM_NAME says CMAKE_SYSTEM_VERSION should 
also be set when cross-compiling (though I haven't seen any ill effects from 
not doing so). Setting CMAKE_SYSTEM_PROCESSOR probably doesn't hurt either.


Repository:
  rC Clang

https://reviews.llvm.org/D41660



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D41512: [Sema] -Wtautological-constant-compare is too good. Cripple it.

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai added inline comments.



Comment at: include/clang/Basic/DiagnosticGroups.td:440
 def TautologicalUnsignedEnumZeroCompare : 
DiagGroup<"tautological-unsigned-enum-zero-compare">;
+def TautologicalRangeCompare : 
DiagGroup<"tautological-constant-range-compare">;
 def TautologicalOutOfRangeCompare : 
DiagGroup<"tautological-constant-out-of-range-compare">;

aaron.ballman wrote:
> lebedev.ri wrote:
> > rsmith wrote:
> > > "tautological-constant-in-range-compare" would make more sense to me, as 
> > > the complement of "tautological-constant-out-of-range-compare".
> > I did think about it.
> > To me "tautological-constant-in-range-compare" may sound as if the constant 
> > is //somewhere// in the range,
> > while i'd say "tautological-constant-range-compare" better highlights the 
> > fact that the constant *is* the range limit.
> > No?
> I don't have strong opinions on this name, but have a slight preference for 
> "in range" because I'm left wondering how "range compare" relates to "out of 
> range compare".
How about range-limit-compare or range-edge-compare or range-bound-compare or 
something of that nature, that explicitly captures the fact that it's the range 
limit?


Repository:
  rC Clang

https://reviews.llvm.org/D41512



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D41764: [libcxx] [cmake] Add a config option LIBCXX_HAS_WIN32_THREADS for enforcing win32 threads

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai added a comment.

I think `LIBCXX_HAS_WIN32_THREAD_API` would be more consistent with the 
existing configuration define names?




Comment at: CMakeLists.txt:277
   endif()
+  if(LIBCXX_HAS_WIN32_THREADS)
+message(FATAL_ERROR "LIBCXX_HAS_WIN32_THREADS can only be set to ON"

The inconsistent usage of `if(` vs `if (` in this file is annoying me haha. Not 
this diff's fault of course, but still.


Repository:
  rCXX libc++

https://reviews.llvm.org/D41764



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D41764: [libcxx] [cmake] Add a config option LIBCXX_HAS_WIN32_THREADS for enforcing win32 threads

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai accepted this revision.
smeenai added a comment.
This revision is now accepted and ready to land.

Can you add documentation for `_LIBCPP_HAS_THREAD_API_WIN32` to 
`docs/DesignDocs/ThreadingSupportAPI.rst`? It should have been documented 
before, but this seems like a good opportunity to correct that.

LGTM with that and the rename.


Repository:
  rCXX libc++

https://reviews.llvm.org/D41764



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D41368: [libc++] Ignore bogus tautologic comparison warnings

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai abandoned this revision.
smeenai added a comment.

The warning was removed from `-Wall`.


Repository:
  rCXX libc++

https://reviews.llvm.org/D41368



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D39562: [CodeGen][ObjC] Fix an assertion failure caused by copy elision

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai added a comment.

Any updates here? We were hitting a similar error internally, which this patch 
fixed.


https://reviews.llvm.org/D39562



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D43842: CodeGenObjCXX: handle inalloca appropriately for msgSend variant

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai added a comment.

In https://reviews.llvm.org/D43842#1022498, @rjmccall wrote:

> Ugh, I hate `inalloca` *so much*.
>
> It's still an indirect return, right?  It's just that the return-slot pointer 
> has to get stored to the `inalloca` allocation like any other argument?


Correct.


Repository:
  rC Clang

https://reviews.llvm.org/D43842



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D44619: [CodeGen] Add cleanup scope to EmitInlinedInheritingCXXConstructorCall

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai created this revision.
smeenai added reviewers: rnk, rsmith.

EmitInlinedInheritingCXXConstructorCall may result in a CallBaseDtor
cleanup being pushed. That cleanup would then be popped when the CGF's
CurCodeDecl no longer points to the method which triggered the cleanup,
leading to a failed cast. Create a new cleanup scope to ensure that the
cleanup gets popped while the CurCodeDecl still points to the method.
Fixes PR36748.


Repository:
  rC Clang

https://reviews.llvm.org/D44619

Files:
  lib/CodeGen/CGClass.cpp
  test/CodeGenCXX/inheriting-constructor-cleanup.cpp


Index: test/CodeGenCXX/inheriting-constructor-cleanup.cpp
===
--- /dev/null
+++ test/CodeGenCXX/inheriting-constructor-cleanup.cpp
@@ -0,0 +1,22 @@
+// RUN: %clang_cc1 -triple x86_64-linux -fexceptions -emit-llvm -o - %s | 
FileCheck %s
+
+// PR36748
+struct S {
+  ~S() {}
+};
+
+struct T {
+  T(int, ...) {}
+};
+
+struct U : public S, public T {
+  using T::T;
+};
+
+void f() {
+  U(0);
+}
+
+// ~S cleanup should be emitted rather than crashing
+// CHECK-LABEL: define void @_Z1fv
+// CHECK: call void @_ZN1SD2Ev
Index: lib/CodeGen/CGClass.cpp
===
--- lib/CodeGen/CGClass.cpp
+++ lib/CodeGen/CGClass.cpp
@@ -2180,6 +2180,7 @@
   GlobalDecl GD(Ctor, CtorType);
   InlinedInheritingConstructorScope Scope(*this, GD);
   ApplyInlineDebugLocation DebugScope(*this, GD);
+  RunCleanupsScope CleanupScope(*this);
 
   // Save the arguments to be passed to the inherited constructor.
   CXXInheritedCtorInitExprArgs = Args;


Index: test/CodeGenCXX/inheriting-constructor-cleanup.cpp
===
--- /dev/null
+++ test/CodeGenCXX/inheriting-constructor-cleanup.cpp
@@ -0,0 +1,22 @@
+// RUN: %clang_cc1 -triple x86_64-linux -fexceptions -emit-llvm -o - %s | FileCheck %s
+
+// PR36748
+struct S {
+  ~S() {}
+};
+
+struct T {
+  T(int, ...) {}
+};
+
+struct U : public S, public T {
+  using T::T;
+};
+
+void f() {
+  U(0);
+}
+
+// ~S cleanup should be emitted rather than crashing
+// CHECK-LABEL: define void @_Z1fv
+// CHECK: call void @_ZN1SD2Ev
Index: lib/CodeGen/CGClass.cpp
===
--- lib/CodeGen/CGClass.cpp
+++ lib/CodeGen/CGClass.cpp
@@ -2180,6 +2180,7 @@
   GlobalDecl GD(Ctor, CtorType);
   InlinedInheritingConstructorScope Scope(*this, GD);
   ApplyInlineDebugLocation DebugScope(*this, GD);
+  RunCleanupsScope CleanupScope(*this);
 
   // Save the arguments to be passed to the inherited constructor.
   CXXInheritedCtorInitExprArgs = Args;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D44619: [CodeGen] Add cleanup scope to EmitInlinedInheritingCXXConstructorCall

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai added a comment.

Argh, this fixes my test case, but causes failures in some other ones. Back to 
the drawing board, I guess.


Repository:
  rC Clang

https://reviews.llvm.org/D44619



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D44640: [CodeGen] Add funclet token to ARC marker

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai created this revision.
smeenai added reviewers: ahatanak, compnerd, majnemer, rjmccall, rnk.

The inline assembly generated for the ARC autorelease elision marker
must have a funclet token if it's emitted inside a funclet, otherwise
the inline assembly (and all subsequent code in the funclet) will be
marked unreachable. r324689 fixed this issue for regular inline assembly
blocks.

Note that clang only emits the marker at -O0, so this only fixes that
case. The optimizations case (where the marker is emitted by the
backend) will be fixed in a separate change.


Repository:
  rC Clang

https://reviews.llvm.org/D44640

Files:
  lib/CodeGen/CGObjC.cpp
  test/CodeGenObjCXX/arc-marker-funclet.mm


Index: test/CodeGenObjCXX/arc-marker-funclet.mm
===
--- /dev/null
+++ test/CodeGenObjCXX/arc-marker-funclet.mm
@@ -0,0 +1,17 @@
+// RUN: %clang_cc1 -triple i686-unknown-windows-msvc -fobjc-runtime=ios-6.0 
-fobjc-arc \
+// RUN:   -fexceptions -fcxx-exceptions -emit-llvm -o - %s | FileCheck %s
+
+id f();
+void g() {
+  try {
+f();
+  } catch (...) {
+f();
+  }
+}
+
+// CHECK: call i8* @"\01?f@@YAPAUobjc_object@@XZ"() [ "funclet"(token %1) ]
+// CHECK-NEXT: call void asm sideeffect "movl{{.*}}%ebp, %ebp{{.*}}", ""() [ 
"funclet"(token %1) ]
+
+// The corresponding f() call was invoked from the entry basic block.
+// CHECK: call void asm sideeffect "movl{{.*}}%ebp, %ebp{{.*}}", ""(){{$}}
Index: lib/CodeGen/CGObjC.cpp
===
--- lib/CodeGen/CGObjC.cpp
+++ lib/CodeGen/CGObjC.cpp
@@ -2034,7 +2034,7 @@
 
   // Call the marker asm if we made one, which we do only at -O0.
   if (marker)
-CGF.Builder.CreateCall(marker);
+CGF.Builder.CreateCall(marker, None, CGF.getBundlesForFunclet(marker));
 }
 
 /// Retain the given object which is the result of a function call.


Index: test/CodeGenObjCXX/arc-marker-funclet.mm
===
--- /dev/null
+++ test/CodeGenObjCXX/arc-marker-funclet.mm
@@ -0,0 +1,17 @@
+// RUN: %clang_cc1 -triple i686-unknown-windows-msvc -fobjc-runtime=ios-6.0 -fobjc-arc \
+// RUN:   -fexceptions -fcxx-exceptions -emit-llvm -o - %s | FileCheck %s
+
+id f();
+void g() {
+  try {
+f();
+  } catch (...) {
+f();
+  }
+}
+
+// CHECK: call i8* @"\01?f@@YAPAUobjc_object@@XZ"() [ "funclet"(token %1) ]
+// CHECK-NEXT: call void asm sideeffect "movl{{.*}}%ebp, %ebp{{.*}}", ""() [ "funclet"(token %1) ]
+
+// The corresponding f() call was invoked from the entry basic block.
+// CHECK: call void asm sideeffect "movl{{.*}}%ebp, %ebp{{.*}}", ""(){{$}}
Index: lib/CodeGen/CGObjC.cpp
===
--- lib/CodeGen/CGObjC.cpp
+++ lib/CodeGen/CGObjC.cpp
@@ -2034,7 +2034,7 @@
 
   // Call the marker asm if we made one, which we do only at -O0.
   if (marker)
-CGF.Builder.CreateCall(marker);
+CGF.Builder.CreateCall(marker, None, CGF.getBundlesForFunclet(marker));
 }
 
 /// Retain the given object which is the result of a function call.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D44640: [CodeGen] Add funclet token to ARC marker

[Shoaib Meenai via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rC327892: [CodeGen] Add funclet token to ARC marker (authored 
by smeenai, committed by ).

Changed prior to commit:
  https://reviews.llvm.org/D44640?vs=138973&id=138983#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D44640

Files:
  lib/CodeGen/CGObjC.cpp
  test/CodeGenObjCXX/arc-marker-funclet.mm


Index: lib/CodeGen/CGObjC.cpp
===
--- lib/CodeGen/CGObjC.cpp
+++ lib/CodeGen/CGObjC.cpp
@@ -2034,7 +2034,7 @@
 
   // Call the marker asm if we made one, which we do only at -O0.
   if (marker)
-CGF.Builder.CreateCall(marker);
+CGF.Builder.CreateCall(marker, None, CGF.getBundlesForFunclet(marker));
 }
 
 /// Retain the given object which is the result of a function call.
Index: test/CodeGenObjCXX/arc-marker-funclet.mm
===
--- test/CodeGenObjCXX/arc-marker-funclet.mm
+++ test/CodeGenObjCXX/arc-marker-funclet.mm
@@ -0,0 +1,17 @@
+// RUN: %clang_cc1 -triple i686-unknown-windows-msvc -fobjc-runtime=ios-6.0 
-fobjc-arc \
+// RUN:   -fexceptions -fcxx-exceptions -emit-llvm -o - %s | FileCheck %s
+
+id f();
+void g() {
+  try {
+f();
+  } catch (...) {
+f();
+  }
+}
+
+// CHECK: call i8* @"?f@@YAPAUobjc_object@@XZ"() [ "funclet"(token %1) ]
+// CHECK-NEXT: call void asm sideeffect "movl{{.*}}%ebp, %ebp{{.*}}", ""() [ 
"funclet"(token %1) ]
+
+// The corresponding f() call was invoked from the entry basic block.
+// CHECK: call void asm sideeffect "movl{{.*}}%ebp, %ebp{{.*}}", ""(){{$}}


Index: lib/CodeGen/CGObjC.cpp
===
--- lib/CodeGen/CGObjC.cpp
+++ lib/CodeGen/CGObjC.cpp
@@ -2034,7 +2034,7 @@
 
   // Call the marker asm if we made one, which we do only at -O0.
   if (marker)
-CGF.Builder.CreateCall(marker);
+CGF.Builder.CreateCall(marker, None, CGF.getBundlesForFunclet(marker));
 }
 
 /// Retain the given object which is the result of a function call.
Index: test/CodeGenObjCXX/arc-marker-funclet.mm
===
--- test/CodeGenObjCXX/arc-marker-funclet.mm
+++ test/CodeGenObjCXX/arc-marker-funclet.mm
@@ -0,0 +1,17 @@
+// RUN: %clang_cc1 -triple i686-unknown-windows-msvc -fobjc-runtime=ios-6.0 -fobjc-arc \
+// RUN:   -fexceptions -fcxx-exceptions -emit-llvm -o - %s | FileCheck %s
+
+id f();
+void g() {
+  try {
+f();
+  } catch (...) {
+f();
+  }
+}
+
+// CHECK: call i8* @"?f@@YAPAUobjc_object@@XZ"() [ "funclet"(token %1) ]
+// CHECK-NEXT: call void asm sideeffect "movl{{.*}}%ebp, %ebp{{.*}}", ""() [ "funclet"(token %1) ]
+
+// The corresponding f() call was invoked from the entry basic block.
+// CHECK: call void asm sideeffect "movl{{.*}}%ebp, %ebp{{.*}}", ""(){{$}}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D44640: [CodeGen] Add funclet token to ARC marker

[Shoaib Meenai via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL327892: [CodeGen] Add funclet token to ARC marker (authored 
by smeenai, committed by ).
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D44640?vs=138973&id=138984#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D44640

Files:
  cfe/trunk/lib/CodeGen/CGObjC.cpp
  cfe/trunk/test/CodeGenObjCXX/arc-marker-funclet.mm


Index: cfe/trunk/lib/CodeGen/CGObjC.cpp
===
--- cfe/trunk/lib/CodeGen/CGObjC.cpp
+++ cfe/trunk/lib/CodeGen/CGObjC.cpp
@@ -2034,7 +2034,7 @@
 
   // Call the marker asm if we made one, which we do only at -O0.
   if (marker)
-CGF.Builder.CreateCall(marker);
+CGF.Builder.CreateCall(marker, None, CGF.getBundlesForFunclet(marker));
 }
 
 /// Retain the given object which is the result of a function call.
Index: cfe/trunk/test/CodeGenObjCXX/arc-marker-funclet.mm
===
--- cfe/trunk/test/CodeGenObjCXX/arc-marker-funclet.mm
+++ cfe/trunk/test/CodeGenObjCXX/arc-marker-funclet.mm
@@ -0,0 +1,17 @@
+// RUN: %clang_cc1 -triple i686-unknown-windows-msvc -fobjc-runtime=ios-6.0 
-fobjc-arc \
+// RUN:   -fexceptions -fcxx-exceptions -emit-llvm -o - %s | FileCheck %s
+
+id f();
+void g() {
+  try {
+f();
+  } catch (...) {
+f();
+  }
+}
+
+// CHECK: call i8* @"?f@@YAPAUobjc_object@@XZ"() [ "funclet"(token %1) ]
+// CHECK-NEXT: call void asm sideeffect "movl{{.*}}%ebp, %ebp{{.*}}", ""() [ 
"funclet"(token %1) ]
+
+// The corresponding f() call was invoked from the entry basic block.
+// CHECK: call void asm sideeffect "movl{{.*}}%ebp, %ebp{{.*}}", ""(){{$}}


Index: cfe/trunk/lib/CodeGen/CGObjC.cpp
===
--- cfe/trunk/lib/CodeGen/CGObjC.cpp
+++ cfe/trunk/lib/CodeGen/CGObjC.cpp
@@ -2034,7 +2034,7 @@
 
   // Call the marker asm if we made one, which we do only at -O0.
   if (marker)
-CGF.Builder.CreateCall(marker);
+CGF.Builder.CreateCall(marker, None, CGF.getBundlesForFunclet(marker));
 }
 
 /// Retain the given object which is the result of a function call.
Index: cfe/trunk/test/CodeGenObjCXX/arc-marker-funclet.mm
===
--- cfe/trunk/test/CodeGenObjCXX/arc-marker-funclet.mm
+++ cfe/trunk/test/CodeGenObjCXX/arc-marker-funclet.mm
@@ -0,0 +1,17 @@
+// RUN: %clang_cc1 -triple i686-unknown-windows-msvc -fobjc-runtime=ios-6.0 -fobjc-arc \
+// RUN:   -fexceptions -fcxx-exceptions -emit-llvm -o - %s | FileCheck %s
+
+id f();
+void g() {
+  try {
+f();
+  } catch (...) {
+f();
+  }
+}
+
+// CHECK: call i8* @"?f@@YAPAUobjc_object@@XZ"() [ "funclet"(token %1) ]
+// CHECK-NEXT: call void asm sideeffect "movl{{.*}}%ebp, %ebp{{.*}}", ""() [ "funclet"(token %1) ]
+
+// The corresponding f() call was invoked from the entry basic block.
+// CHECK: call void asm sideeffect "movl{{.*}}%ebp, %ebp{{.*}}", ""(){{$}}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D44646: Sema: in msvc compatibility mode, don't allow forceinline on variadics

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai added a reviewer: compnerd.
smeenai added a comment.

@DHowett-MSFT the reviewers look fine to me. Reid is the code owner for clang's 
MSVC compat support. David doesn't work on this stuff directly anymore, I 
think, but he's still pretty active in code reviews for it. I'm adding Saleem, 
who's also pretty active on Windows stuff.




Comment at: lib/Sema/SemaDeclAttr.cpp:3890
+  if (Context.getTargetInfo().getCXXABI().isMicrosoft()
+ && hasFunctionProto(D) && isFunctionOrMethodVariadic(D)) {
+Diag(Range.getBegin(), diag::warn_always_inline_on_variadic) << Ident;

The formatting here looks off (it doesn't look clang-formatted).


Repository:
  rC Clang

https://reviews.llvm.org/D44646



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D44671: [libcxx] Enable static libcxxabi linking on Darwin

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai added a comment.

I would imagine there was a reason this configuration was unsupported on macOS 
– perhaps something to do with libc++/libc++abi being the default system 
libraries on that platform?




Comment at: libcxx/CMakeLists.txt:330
 
 # Check that this option is not enabled on Apple and emit a usage warning.
 if (LIBCXX_ENABLE_STATIC_ABI_LIBRARY)

You should get rid of this comment.


Repository:
  rCXX libc++

https://reviews.llvm.org/D44671



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D47233: [CodeGen] Emit MSVC RTTI for Obj-C EH types

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai added a comment.

In https://reviews.llvm.org/D47233#1115630, @DHowett-MSFT wrote:

> This largely matches what we've done in the WinObjC clang patchset here 
> ,
>  with the critical exception that we've chosen to mangle the EH names as 
> though they were for structs named after their classes.


Thanks for the pointer!

To clarify, when you're talking about mangling the EH names, do you mean the 
names of the typeinfo structures themselves (OBJC_EHTYPE_* in my 
implementation), or the typeinfo name strings inside those structures? The 
latter should be equivalent to structs for us too, i.e. `@catch (I *)` and 
`catch (struct I *)` would produce the same name in the generated type info.


Repository:
  rC Clang

https://reviews.llvm.org/D47233



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D47564: [Parse] Use CapturedStmt for @finally on MSVC

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai created this revision.
smeenai added reviewers: rjmccall, rnk, rsmith.
Herald added a subscriber: cfe-commits.

The body of a @finally needs to be executed on both exceptional and
non-exceptional paths. On landingpad platforms, this is straightforward:
the @finally body is emitted as a normal (non-exceptional) cleanup, and
then a catch-all is emitted which branches to that cleanup (the cleanup
has code to conditionally re-throw based on a flag which is set by the
catch-all).

Unfortunately, we can't use the same approach for MSVC exceptions, where
the catch-all will be emitted as a catchpad. We can't just branch to the
cleanup from within the catchpad, since we can only exit it via a
catchret, at which point the exception is destroyed and we can't
rethrow. We could potentially emit the finally body inside the catchpad
and have the normal cleanup path somehow branch into it, but that would
require some new IR construct that could branch into a catchpad.

Instead, after discussing it with Reid Kleckner, we decided that
frontend outlining was the best approach, similar to how SEH __finally
works today. We decided to use CapturedStmt rather than CaptureFinder
(which is what __finally uses) since the latter doesn't handle a lot of
cases we care about, e.g. self accesses, property accesses, block
captures, etc. Extending CaptureFinder to handle those additional cases
proved unwieldy, whereas CapturedStmt already took care of all of those.
In theory __finally could also be moved over to CapturedStmt, which
would remove some existing limitations (e.g. the inability to capture
this), although CaptureFinder would still be needed for SEH filters.

The one case supported by @finally but not CapturedStmt (or
CaptureFinder for that matter) is arbitrary control flow out of the
@finally, e.g. having a return statement inside a @finally. We can add
that support as a follow-up, but in practice we've found it to be used
very rarely anyway.


Repository:
  rC Clang

https://reviews.llvm.org/D47564

Files:
  include/clang/AST/Stmt.h
  include/clang/Basic/CapturedStmt.h
  include/clang/Sema/ScopeInfo.h
  lib/CodeGen/CGCXXABI.h
  lib/CodeGen/CGObjCMac.cpp
  lib/CodeGen/MicrosoftCXXABI.cpp
  lib/Parse/ParseObjc.cpp
  test/CodeGenObjC/dllstorage.m
  test/CodeGenObjC/exceptions-msvc.m
  test/SemaObjC/finally-msvc.m

Index: test/SemaObjC/finally-msvc.m
===
--- /dev/null
+++ test/SemaObjC/finally-msvc.m
@@ -0,0 +1,14 @@
+// RUN: %clang_cc1 -triple i686--windows-msvc -fexceptions -fobjc-exceptions -ast-dump %s 2>&1 | FileCheck %s
+// RUN: %clang_cc1 -triple x86_64--windows-msvc -fexceptions -fobjc-exceptions -ast-dump %s 2>&1 | FileCheck %s
+
+void f() {
+  @try {
+  } @finally {
+  }
+}
+
+// CHECK:  ObjCAtFinallyStmt
+// CHECK-NEXT:   CapturedStmt
+// CHECK-NEXT: CapturedDecl
+// CHECK-NEXT:   CompoundStmt
+// CHECK-NEXT:   ImplicitParamDecl
Index: test/CodeGenObjC/exceptions-msvc.m
===
--- /dev/null
+++ test/CodeGenObjC/exceptions-msvc.m
@@ -0,0 +1,69 @@
+// RUN: %clang_cc1 -triple i686--windows-msvc -fobjc-runtime=ios-6.0 -fdeclspec -fexceptions -fobjc-exceptions -emit-llvm -o - %s | FileCheck -check-prefixes=CHECK,X86 %s
+// RUN: %clang_cc1 -triple i686--windows-msvc -fobjc-runtime=ios-6.0 -fobjc-arc -fdeclspec -fexceptions -fobjc-exceptions -emit-llvm -o - %s | FileCheck -check-prefixes=CHECK,X86 %s
+// RUN: %clang_cc1 -triple x86_64--windows-msvc -fobjc-runtime=ios-6.0 -fdeclspec -fexceptions -fobjc-exceptions -emit-llvm -o - %s | FileCheck -check-prefixes=CHECK,X64 %s
+// RUN: %clang_cc1 -triple x86_64--windows-msvc -fobjc-runtime=ios-6.0 -fobjc-arc -fdeclspec -fexceptions -fobjc-exceptions -emit-llvm -o - %s | FileCheck -check-prefixes=CHECK,X64 %s
+
+#if __has_feature(objc_arc)
+#define WEAK __weak
+#else
+#define WEAK
+#endif
+
+// CHECK-DAG: $OBJC_EHTYPE_id = comdat any
+// X86-DAG: @OBJC_EHTYPE_id = linkonce_odr global {{%[^ ]+}} { i8** @"??_7type_info@@6B@", i8* null, [18 x i8] c".PAUobjc_object@@\00" }, comdat
+// X64-DAG: @OBJC_EHTYPE_id = linkonce_odr global {{%[^ ]+}} { i8** @"??_7type_info@@6B@", i8* null, [19 x i8] c".PEAUobjc_object@@\00" }, comdat
+
+@class I;
+
+// CHECK-DAG: $"OBJC_EHTYPE_$_I" = comdat any
+// X86-DAG: @"OBJC_EHTYPE_$_I" = linkonce_odr global {{%[^ ]+}} { i8** @"??_7type_info@@6B@", i8* null, [8 x i8] c".PAUI@@\00" }, comdat
+// X64-DAG: @"OBJC_EHTYPE_$_I" = linkonce_odr global {{%[^ ]+}} { i8** @"??_7type_info@@6B@", i8* null, [9 x i8] c".PEAUI@@\00" }, comdat
+
+@class J;
+
+// CHECK-DAG: $"OBJC_EHTYPE_$_J" = comdat any
+// X86-DAG: @"OBJC_EHTYPE_$_J" = linkonce_odr global {{%[^ ]+}} { i8** @"??_7type_info@@6B@", i8* null, [8 x i8] c".PAUJ@@\00" }, comdat
+// X64-DAG: @"OBJC_EHTYPE_$_J" = linkonce_odr global {{%[^ ]+}} { i8** @"??_7type_info@@6B@", i8* null, [9 x i8] c".PEAUJ@@\00" }, comdat
+
+// The EHType shouldn't be exported
+__declspec(d

[PATCH] D47564: [Parse] Use CapturedStmt for @finally on MSVC

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai updated this revision to Diff 149220.
smeenai added a comment.

Proper diff


Repository:
  rC Clang

https://reviews.llvm.org/D47564

Files:
  include/clang/AST/Stmt.h
  include/clang/Basic/CapturedStmt.h
  include/clang/Sema/ScopeInfo.h
  lib/Parse/ParseObjc.cpp
  test/SemaObjC/finally-msvc.m


Index: test/SemaObjC/finally-msvc.m
===
--- /dev/null
+++ test/SemaObjC/finally-msvc.m
@@ -0,0 +1,14 @@
+// RUN: %clang_cc1 -triple i686--windows-msvc -fexceptions -fobjc-exceptions 
-ast-dump %s 2>&1 | FileCheck %s
+// RUN: %clang_cc1 -triple x86_64--windows-msvc -fexceptions -fobjc-exceptions 
-ast-dump %s 2>&1 | FileCheck %s
+
+void f() {
+  @try {
+  } @finally {
+  }
+}
+
+// CHECK:  ObjCAtFinallyStmt
+// CHECK-NEXT:   CapturedStmt
+// CHECK-NEXT: CapturedDecl
+// CHECK-NEXT:   CompoundStmt
+// CHECK-NEXT:   ImplicitParamDecl
Index: lib/Parse/ParseObjc.cpp
===
--- lib/Parse/ParseObjc.cpp
+++ lib/Parse/ParseObjc.cpp
@@ -2585,13 +2585,28 @@
   ParseScope FinallyScope(this,
   Scope::DeclScope | Scope::CompoundStmtScope);
 
+  bool ShouldCapture = Actions.getASTContext()
+   .getTargetInfo()
+   .getTriple()
+   .isWindowsMSVCEnvironment();
+  if (ShouldCapture)
+Actions.ActOnCapturedRegionStart(Tok.getLocation(), getCurScope(),
+ CR_ObjCAtFinally, 1);
+
   StmtResult FinallyBody(true);
   if (Tok.is(tok::l_brace))
 FinallyBody = ParseCompoundStatementBody();
   else
 Diag(Tok, diag::err_expected) << tok::l_brace;
-  if (FinallyBody.isInvalid())
+
+  if (FinallyBody.isInvalid()) {
 FinallyBody = Actions.ActOnNullStmt(Tok.getLocation());
+if (ShouldCapture)
+  Actions.ActOnCapturedRegionError();
+  } else if (ShouldCapture) {
+FinallyBody = Actions.ActOnCapturedRegionEnd(FinallyBody.get());
+  }
+
   FinallyStmt = Actions.ActOnObjCAtFinallyStmt(AtCatchFinallyLoc,
FinallyBody.get());
   catch_or_finally_seen = true;
Index: include/clang/Sema/ScopeInfo.h
===
--- include/clang/Sema/ScopeInfo.h
+++ include/clang/Sema/ScopeInfo.h
@@ -748,6 +748,8 @@
 switch (CapRegionKind) {
 case CR_Default:
   return "default captured statement";
+case CR_ObjCAtFinally:
+  return "Objective-C @finally statement";
 case CR_OpenMP:
   return "OpenMP region";
 }
Index: include/clang/Basic/CapturedStmt.h
===
--- include/clang/Basic/CapturedStmt.h
+++ include/clang/Basic/CapturedStmt.h
@@ -16,6 +16,7 @@
 /// The different kinds of captured statement.
 enum CapturedRegionKind {
   CR_Default,
+  CR_ObjCAtFinally,
   CR_OpenMP
 };
 
Index: include/clang/AST/Stmt.h
===
--- include/clang/AST/Stmt.h
+++ include/clang/AST/Stmt.h
@@ -2133,7 +2133,7 @@
 
   /// The pointer part is the implicit the outlined function and the 
   /// int part is the captured region kind, 'CR_Default' etc.
-  llvm::PointerIntPair CapDeclAndKind;
+  llvm::PointerIntPair CapDeclAndKind;
 
   /// The record for captured variables, a RecordDecl or CXXRecordDecl.
   RecordDecl *TheRecordDecl = nullptr;


Index: test/SemaObjC/finally-msvc.m
===
--- /dev/null
+++ test/SemaObjC/finally-msvc.m
@@ -0,0 +1,14 @@
+// RUN: %clang_cc1 -triple i686--windows-msvc -fexceptions -fobjc-exceptions -ast-dump %s 2>&1 | FileCheck %s
+// RUN: %clang_cc1 -triple x86_64--windows-msvc -fexceptions -fobjc-exceptions -ast-dump %s 2>&1 | FileCheck %s
+
+void f() {
+  @try {
+  } @finally {
+  }
+}
+
+// CHECK:  ObjCAtFinallyStmt
+// CHECK-NEXT:   CapturedStmt
+// CHECK-NEXT: CapturedDecl
+// CHECK-NEXT:   CompoundStmt
+// CHECK-NEXT:   ImplicitParamDecl
Index: lib/Parse/ParseObjc.cpp
===
--- lib/Parse/ParseObjc.cpp
+++ lib/Parse/ParseObjc.cpp
@@ -2585,13 +2585,28 @@
   ParseScope FinallyScope(this,
   Scope::DeclScope | Scope::CompoundStmtScope);
 
+  bool ShouldCapture = Actions.getASTContext()
+   .getTargetInfo()
+   .getTriple()
+   .isWindowsMSVCEnvironment();
+  if (ShouldCapture)
+Actions.ActOnCapturedRegionStart(Tok.getLocation(), getCurScope(),
+ CR_ObjCAtFinally, 1);
+
   StmtResult FinallyBody(true);
   if (Tok.is(tok::l_brace))
 FinallyBody = ParseCompoundStatementBody();
   else
   

[PATCH] D47564: [Parse] Use CapturedStmt for @finally on MSVC

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai updated this revision to Diff 149351.
smeenai edited the summary of this revision.
smeenai added a comment.

@rnk comment


Repository:
  rC Clang

https://reviews.llvm.org/D47564

Files:
  include/clang/AST/Stmt.h
  include/clang/Basic/CapturedStmt.h
  include/clang/Sema/ScopeInfo.h
  lib/Parse/ParseObjc.cpp
  test/SemaObjC/finally-msvc.m


Index: test/SemaObjC/finally-msvc.m
===
--- /dev/null
+++ test/SemaObjC/finally-msvc.m
@@ -0,0 +1,14 @@
+// RUN: %clang_cc1 -triple i686--windows-msvc -fexceptions -fobjc-exceptions 
-ast-dump %s 2>&1 | FileCheck %s
+// RUN: %clang_cc1 -triple x86_64--windows-msvc -fexceptions -fobjc-exceptions 
-ast-dump %s 2>&1 | FileCheck %s
+
+void f() {
+  @try {
+  } @finally {
+  }
+}
+
+// CHECK:  ObjCAtFinallyStmt
+// CHECK-NEXT:   CapturedStmt
+// CHECK-NEXT: CapturedDecl
+// CHECK-NEXT:   CompoundStmt
+// CHECK-NEXT:   ImplicitParamDecl
Index: lib/Parse/ParseObjc.cpp
===
--- lib/Parse/ParseObjc.cpp
+++ lib/Parse/ParseObjc.cpp
@@ -2585,13 +2585,26 @@
   ParseScope FinallyScope(this,
   Scope::DeclScope | Scope::CompoundStmtScope);
 
+  bool ShouldCapture =
+  getTargetInfo().getTriple().isWindowsMSVCEnvironment();
+  if (ShouldCapture)
+Actions.ActOnCapturedRegionStart(Tok.getLocation(), getCurScope(),
+ CR_ObjCAtFinally, 1);
+
   StmtResult FinallyBody(true);
   if (Tok.is(tok::l_brace))
 FinallyBody = ParseCompoundStatementBody();
   else
 Diag(Tok, diag::err_expected) << tok::l_brace;
-  if (FinallyBody.isInvalid())
+
+  if (FinallyBody.isInvalid()) {
 FinallyBody = Actions.ActOnNullStmt(Tok.getLocation());
+if (ShouldCapture)
+  Actions.ActOnCapturedRegionError();
+  } else if (ShouldCapture) {
+FinallyBody = Actions.ActOnCapturedRegionEnd(FinallyBody.get());
+  }
+
   FinallyStmt = Actions.ActOnObjCAtFinallyStmt(AtCatchFinallyLoc,
FinallyBody.get());
   catch_or_finally_seen = true;
Index: include/clang/Sema/ScopeInfo.h
===
--- include/clang/Sema/ScopeInfo.h
+++ include/clang/Sema/ScopeInfo.h
@@ -748,6 +748,8 @@
 switch (CapRegionKind) {
 case CR_Default:
   return "default captured statement";
+case CR_ObjCAtFinally:
+  return "Objective-C @finally statement";
 case CR_OpenMP:
   return "OpenMP region";
 }
Index: include/clang/Basic/CapturedStmt.h
===
--- include/clang/Basic/CapturedStmt.h
+++ include/clang/Basic/CapturedStmt.h
@@ -16,6 +16,7 @@
 /// The different kinds of captured statement.
 enum CapturedRegionKind {
   CR_Default,
+  CR_ObjCAtFinally,
   CR_OpenMP
 };
 
Index: include/clang/AST/Stmt.h
===
--- include/clang/AST/Stmt.h
+++ include/clang/AST/Stmt.h
@@ -2133,7 +2133,7 @@
 
   /// The pointer part is the implicit the outlined function and the 
   /// int part is the captured region kind, 'CR_Default' etc.
-  llvm::PointerIntPair CapDeclAndKind;
+  llvm::PointerIntPair CapDeclAndKind;
 
   /// The record for captured variables, a RecordDecl or CXXRecordDecl.
   RecordDecl *TheRecordDecl = nullptr;


Index: test/SemaObjC/finally-msvc.m
===
--- /dev/null
+++ test/SemaObjC/finally-msvc.m
@@ -0,0 +1,14 @@
+// RUN: %clang_cc1 -triple i686--windows-msvc -fexceptions -fobjc-exceptions -ast-dump %s 2>&1 | FileCheck %s
+// RUN: %clang_cc1 -triple x86_64--windows-msvc -fexceptions -fobjc-exceptions -ast-dump %s 2>&1 | FileCheck %s
+
+void f() {
+  @try {
+  } @finally {
+  }
+}
+
+// CHECK:  ObjCAtFinallyStmt
+// CHECK-NEXT:   CapturedStmt
+// CHECK-NEXT: CapturedDecl
+// CHECK-NEXT:   CompoundStmt
+// CHECK-NEXT:   ImplicitParamDecl
Index: lib/Parse/ParseObjc.cpp
===
--- lib/Parse/ParseObjc.cpp
+++ lib/Parse/ParseObjc.cpp
@@ -2585,13 +2585,26 @@
   ParseScope FinallyScope(this,
   Scope::DeclScope | Scope::CompoundStmtScope);
 
+  bool ShouldCapture =
+  getTargetInfo().getTriple().isWindowsMSVCEnvironment();
+  if (ShouldCapture)
+Actions.ActOnCapturedRegionStart(Tok.getLocation(), getCurScope(),
+ CR_ObjCAtFinally, 1);
+
   StmtResult FinallyBody(true);
   if (Tok.is(tok::l_brace))
 FinallyBody = ParseCompoundStatementBody();
   else
 Diag(Tok, diag::err_expected) << tok::l_brace;
-  if (FinallyBody.isInvalid())
+
+  if (FinallyBody.isInvalid()) {
 FinallyBody = Actions.ActOnNullStmt(Tok.

[PATCH] D47564: [Parse] Use CapturedStmt for @finally on MSVC

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai added a comment.

In https://reviews.llvm.org/D47564#1118381, @rjmccall wrote:

> That's an interesting idea.  I don't see any particular reason not to do it 
> this way if you're willing to accept that it's never going to support the 
> full control-flow possibilities of @finally.  You will need to add 
> JumpDiagnostics logic to prevent branches out of the block, and I don't know 
> how this will interact with attempts to throw an exception out.


There's already some logic in CapturedStmt to prevent branches out of the block:

- Attempting to return will produce "cannot return from Objective-C @finally 
statement"
- Attempting to goto out of the block will result in "use of undeclared label", 
which is a bad diagnostic (and should be improved), but it does error

Are there any other branches you had in mind? I could add tests for them, 
perhaps, though it's also covered by `test/Sema/captured-statements.c`.

It should be possible to add support for returns, at least; the idea we'd 
discussed with @rnk was setting a flag in the captured function to indicate a 
return having been executed, and then reading that flag outside the captured 
function and acting on it appropriately. gotos would be more complicated, but I 
think we could make them work if we really wanted to.

Throwing an exception out should just work, I think; the outlined function will 
just participate normally in exception handling. Did you have a specific case 
you were thinking of?


Repository:
  rC Clang

https://reviews.llvm.org/D47564



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D47669: [cmake] Support LLD for CLANG_ORDER_FILE

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai created this revision.
smeenai added reviewers: beanz, compnerd, phosek.
Herald added a subscriber: mgorny.
smeenai added a subscriber: alexshap.

LLD also supports order files using the `--symbol-ordering-file` option.
As the name would suggest, the order file format is slightly different
from gold; gold's order files specify section names, whereas LLD's
specify symbol names. Assuming you have an order file in the correct
format though, we should support using it with LLD.

Switch the check to actually use LLVM's linker detection rather than
just checking for the presence of the gold executable, since we might
have a gold executable present but be using LLD (or bfd for that matter)
as our linker.


Repository:
  rC Clang

https://reviews.llvm.org/D47669

Files:
  tools/driver/CMakeLists.txt


Index: tools/driver/CMakeLists.txt
===
--- tools/driver/CMakeLists.txt
+++ tools/driver/CMakeLists.txt
@@ -98,13 +98,16 @@
   set(TOOL_INFO_BUILD_VERSION)
 endif()
 
-if(CLANG_ORDER_FILE AND (LD64_EXECUTABLE OR GOLD_EXECUTABLE))
+if(CLANG_ORDER_FILE AND
+   (LD64_EXECUTABLE OR LLVM_LINKER_IS_GOLD OR LLVM_LINKER_IS_LLD))
   include(CheckLinkerFlag)
 
   if (LD64_EXECUTABLE)
 set(LINKER_ORDER_FILE_OPTION "-Wl,-order_file,${CLANG_ORDER_FILE}")
-  elseif (GOLD_EXECUTABLE)
+  elseif (LLVM_LINKER_IS_GOLD)
 set(LINKER_ORDER_FILE_OPTION 
"-Wl,--section-ordering-file,${CLANG_ORDER_FILE}")
+  elseif (LLVM_LINKER_IS_LLD)
+set(LINKER_ORDER_FILE_OPTION 
"-Wl,--symbol-ordering-file,${CLANG_ORDER_FILE}")
   endif()
 
   # This is a test to ensure the actual order file works with the linker.


Index: tools/driver/CMakeLists.txt
===
--- tools/driver/CMakeLists.txt
+++ tools/driver/CMakeLists.txt
@@ -98,13 +98,16 @@
   set(TOOL_INFO_BUILD_VERSION)
 endif()
 
-if(CLANG_ORDER_FILE AND (LD64_EXECUTABLE OR GOLD_EXECUTABLE))
+if(CLANG_ORDER_FILE AND
+   (LD64_EXECUTABLE OR LLVM_LINKER_IS_GOLD OR LLVM_LINKER_IS_LLD))
   include(CheckLinkerFlag)
 
   if (LD64_EXECUTABLE)
 set(LINKER_ORDER_FILE_OPTION "-Wl,-order_file,${CLANG_ORDER_FILE}")
-  elseif (GOLD_EXECUTABLE)
+  elseif (LLVM_LINKER_IS_GOLD)
 set(LINKER_ORDER_FILE_OPTION "-Wl,--section-ordering-file,${CLANG_ORDER_FILE}")
+  elseif (LLVM_LINKER_IS_LLD)
+set(LINKER_ORDER_FILE_OPTION "-Wl,--symbol-ordering-file,${CLANG_ORDER_FILE}")
   endif()
 
   # This is a test to ensure the actual order file works with the linker.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D47669: [cmake] Support LLD for CLANG_ORDER_FILE

[Shoaib Meenai via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL333810: [cmake] Support LLD for CLANG_ORDER_FILE (authored 
by smeenai, committed by ).
Herald added a subscriber: llvm-commits.

Repository:
  rL LLVM

https://reviews.llvm.org/D47669

Files:
  cfe/trunk/tools/driver/CMakeLists.txt


Index: cfe/trunk/tools/driver/CMakeLists.txt
===
--- cfe/trunk/tools/driver/CMakeLists.txt
+++ cfe/trunk/tools/driver/CMakeLists.txt
@@ -98,13 +98,16 @@
   set(TOOL_INFO_BUILD_VERSION)
 endif()
 
-if(CLANG_ORDER_FILE AND (LD64_EXECUTABLE OR GOLD_EXECUTABLE))
+if(CLANG_ORDER_FILE AND
+   (LD64_EXECUTABLE OR LLVM_LINKER_IS_GOLD OR LLVM_LINKER_IS_LLD))
   include(CheckLinkerFlag)
 
   if (LD64_EXECUTABLE)
 set(LINKER_ORDER_FILE_OPTION "-Wl,-order_file,${CLANG_ORDER_FILE}")
-  elseif (GOLD_EXECUTABLE)
+  elseif (LLVM_LINKER_IS_GOLD)
 set(LINKER_ORDER_FILE_OPTION 
"-Wl,--section-ordering-file,${CLANG_ORDER_FILE}")
+  elseif (LLVM_LINKER_IS_LLD)
+set(LINKER_ORDER_FILE_OPTION 
"-Wl,--symbol-ordering-file,${CLANG_ORDER_FILE}")
   endif()
 
   # This is a test to ensure the actual order file works with the linker.


Index: cfe/trunk/tools/driver/CMakeLists.txt
===
--- cfe/trunk/tools/driver/CMakeLists.txt
+++ cfe/trunk/tools/driver/CMakeLists.txt
@@ -98,13 +98,16 @@
   set(TOOL_INFO_BUILD_VERSION)
 endif()
 
-if(CLANG_ORDER_FILE AND (LD64_EXECUTABLE OR GOLD_EXECUTABLE))
+if(CLANG_ORDER_FILE AND
+   (LD64_EXECUTABLE OR LLVM_LINKER_IS_GOLD OR LLVM_LINKER_IS_LLD))
   include(CheckLinkerFlag)
 
   if (LD64_EXECUTABLE)
 set(LINKER_ORDER_FILE_OPTION "-Wl,-order_file,${CLANG_ORDER_FILE}")
-  elseif (GOLD_EXECUTABLE)
+  elseif (LLVM_LINKER_IS_GOLD)
 set(LINKER_ORDER_FILE_OPTION "-Wl,--section-ordering-file,${CLANG_ORDER_FILE}")
+  elseif (LLVM_LINKER_IS_LLD)
+set(LINKER_ORDER_FILE_OPTION "-Wl,--symbol-ordering-file,${CLANG_ORDER_FILE}")
   endif()
 
   # This is a test to ensure the actual order file works with the linker.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D47564: [Parse] Use CapturedStmt for @finally on MSVC

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai added a comment.

In https://reviews.llvm.org/D47564#1118424, @rjmccall wrote:

> In https://reviews.llvm.org/D47564#1118423, @smeenai wrote:
>
> > In https://reviews.llvm.org/D47564#1118381, @rjmccall wrote:
> >
> > > That's an interesting idea.  I don't see any particular reason not to do 
> > > it this way if you're willing to accept that it's never going to support 
> > > the full control-flow possibilities of @finally.  You will need to add 
> > > JumpDiagnostics logic to prevent branches out of the block, and I don't 
> > > know how this will interact with attempts to throw an exception out.
> >
> >
> > There's already some logic in CapturedStmt to prevent branches out of the 
> > block:
> >
> > - Attempting to return will produce "cannot return from Objective-C 
> > @finally statement"
> > - Attempting to goto out of the block will result in "use of undeclared 
> > label", which is a bad diagnostic (and should be improved), but it does 
> > error
>
>
> Alright, that makes sense.
>
> > It should be possible to add support for returns, at least; the idea we'd 
> > discussed with @rnk was setting a flag in the captured function to indicate 
> > a return having been executed, and then reading that flag outside the 
> > captured function and acting on it appropriately. gotos would be more 
> > complicated, but I think we could make them work if we really wanted to.
> > 
> > Throwing an exception out should just work, I think; the outlined function 
> > will just participate normally in exception handling. Did you have a 
> > specific case you were thinking of?
>
> No, it was just a general question.  Have you gotten this to a point where 
> it's testable?


Yup, it's been working fine in my local testing. There's one more patch that I 
need to put up, which actually handles doing proper codegen for 
@try/@catch/@finally; I'm working on cleaning that up right now. The other 
piece of the puzzle is https://reviews.llvm.org/D47233, which emits the proper 
typeinfo required for this.


Repository:
  rC Clang

https://reviews.llvm.org/D47564



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D47564: [Parse] Use CapturedStmt for @finally on MSVC

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai added a comment.

In https://reviews.llvm.org/D47564#1119925, @rjmccall wrote:

> In https://reviews.llvm.org/D47564#1119874, @smeenai wrote:
>
> > In https://reviews.llvm.org/D47564#1118424, @rjmccall wrote:
> >
> > > No, it was just a general question.  Have you gotten this to a point 
> > > where it's testable?
> >
> >
> > Yup, it's been working fine in my local testing. There's one more patch 
> > that I need to put up, which actually handles doing proper codegen for 
> > @try/@catch/@finally; I'm working on cleaning that up right now.
>
>
> Okay.  And simple tests with throwing exceptions out of the `@finally` block 
> seem to work?


Yup, it works fine. It's essentially the same as calling a function inside a 
catch block which throws (since the finally is modeled as a catch-all, and the 
finally body is outlined into a function which gets called by that catch-all).


Repository:
  rC Clang

https://reviews.llvm.org/D47564



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D47850: [Driver] Stop passing -fseh-exceptions for x86_64-windows-msvc

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai created this revision.
smeenai added reviewers: compnerd, mstorsjo, rnk.
Herald added subscribers: JDevlieghere, aprantl.

-fseh-exceptions is only meaningful for MinGW targets, and that driver
already has logic to pass either -fdwarf-exceptiosn or -fseh-exceptions
as appropriate. -fseh-exceptions is just a no-op for MSVC triples, and
passing it to cc1 causes unnecessary confusion.


Repository:
  rC Clang

https://reviews.llvm.org/D47850

Files:
  lib/Driver/ToolChain.cpp
  test/Driver/windows-exceptions.cpp


Index: test/Driver/windows-exceptions.cpp
===
--- /dev/null
+++ test/Driver/windows-exceptions.cpp
@@ -0,0 +1,9 @@
+// RUN: %clang -target i686-windows-msvc -c %s -### 2>&1 | FileCheck 
-check-prefix=MSVC %s
+// RUN: %clang -target x86_64-windows-msvc -c %s -### 2>&1 | FileCheck 
-check-prefix=MSVC %s
+// RUN: %clang -target i686-windows-gnu -c %s -### 2>&1 | FileCheck 
-check-prefix=MINGW-DWARF %s
+// RUN: %clang -target x86_64-windows-gnu -c %s -### 2>&1 | FileCheck 
-check-prefix=MINGW-SEH %s
+
+MSVC-NOT: -fdwarf-exceptions
+MSVC-NOT: -fseh-exceptions
+MINGW-DWARF: -fdwarf-exceptions
+MINGW-SEH: -fseh-exceptions
Index: lib/Driver/ToolChain.cpp
===
--- lib/Driver/ToolChain.cpp
+++ lib/Driver/ToolChain.cpp
@@ -471,8 +471,6 @@
 
 llvm::ExceptionHandling
 ToolChain::GetExceptionModel(const llvm::opt::ArgList &Args) const {
-  if (Triple.isOSWindows() && Triple.getArch() != llvm::Triple::x86)
-return llvm::ExceptionHandling::WinEH;
   return llvm::ExceptionHandling::None;
 }
 


Index: test/Driver/windows-exceptions.cpp
===
--- /dev/null
+++ test/Driver/windows-exceptions.cpp
@@ -0,0 +1,9 @@
+// RUN: %clang -target i686-windows-msvc -c %s -### 2>&1 | FileCheck -check-prefix=MSVC %s
+// RUN: %clang -target x86_64-windows-msvc -c %s -### 2>&1 | FileCheck -check-prefix=MSVC %s
+// RUN: %clang -target i686-windows-gnu -c %s -### 2>&1 | FileCheck -check-prefix=MINGW-DWARF %s
+// RUN: %clang -target x86_64-windows-gnu -c %s -### 2>&1 | FileCheck -check-prefix=MINGW-SEH %s
+
+MSVC-NOT: -fdwarf-exceptions
+MSVC-NOT: -fseh-exceptions
+MINGW-DWARF: -fdwarf-exceptions
+MINGW-SEH: -fseh-exceptions
Index: lib/Driver/ToolChain.cpp
===
--- lib/Driver/ToolChain.cpp
+++ lib/Driver/ToolChain.cpp
@@ -471,8 +471,6 @@
 
 llvm::ExceptionHandling
 ToolChain::GetExceptionModel(const llvm::opt::ArgList &Args) const {
-  if (Triple.isOSWindows() && Triple.getArch() != llvm::Triple::x86)
-return llvm::ExceptionHandling::WinEH;
   return llvm::ExceptionHandling::None;
 }
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D47850: [Driver] Stop passing -fseh-exceptions for x86_64-windows-msvc

[Shoaib Meenai via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL334145: [Driver] Stop passing -fseh-exceptions for 
x86_64-windows-msvc (authored by smeenai, committed by ).
Herald added a subscriber: llvm-commits.

Repository:
  rL LLVM

https://reviews.llvm.org/D47850

Files:
  cfe/trunk/lib/Driver/ToolChain.cpp
  cfe/trunk/test/Driver/windows-exceptions.cpp


Index: cfe/trunk/test/Driver/windows-exceptions.cpp
===
--- cfe/trunk/test/Driver/windows-exceptions.cpp
+++ cfe/trunk/test/Driver/windows-exceptions.cpp
@@ -0,0 +1,9 @@
+// RUN: %clang -target i686-windows-msvc -c %s -### 2>&1 | FileCheck 
-check-prefix=MSVC %s
+// RUN: %clang -target x86_64-windows-msvc -c %s -### 2>&1 | FileCheck 
-check-prefix=MSVC %s
+// RUN: %clang -target i686-windows-gnu -c %s -### 2>&1 | FileCheck 
-check-prefix=MINGW-DWARF %s
+// RUN: %clang -target x86_64-windows-gnu -c %s -### 2>&1 | FileCheck 
-check-prefix=MINGW-SEH %s
+
+MSVC-NOT: -fdwarf-exceptions
+MSVC-NOT: -fseh-exceptions
+MINGW-DWARF: -fdwarf-exceptions
+MINGW-SEH: -fseh-exceptions
Index: cfe/trunk/lib/Driver/ToolChain.cpp
===
--- cfe/trunk/lib/Driver/ToolChain.cpp
+++ cfe/trunk/lib/Driver/ToolChain.cpp
@@ -471,8 +471,6 @@
 
 llvm::ExceptionHandling
 ToolChain::GetExceptionModel(const llvm::opt::ArgList &Args) const {
-  if (Triple.isOSWindows() && Triple.getArch() != llvm::Triple::x86)
-return llvm::ExceptionHandling::WinEH;
   return llvm::ExceptionHandling::None;
 }
 


Index: cfe/trunk/test/Driver/windows-exceptions.cpp
===
--- cfe/trunk/test/Driver/windows-exceptions.cpp
+++ cfe/trunk/test/Driver/windows-exceptions.cpp
@@ -0,0 +1,9 @@
+// RUN: %clang -target i686-windows-msvc -c %s -### 2>&1 | FileCheck -check-prefix=MSVC %s
+// RUN: %clang -target x86_64-windows-msvc -c %s -### 2>&1 | FileCheck -check-prefix=MSVC %s
+// RUN: %clang -target i686-windows-gnu -c %s -### 2>&1 | FileCheck -check-prefix=MINGW-DWARF %s
+// RUN: %clang -target x86_64-windows-gnu -c %s -### 2>&1 | FileCheck -check-prefix=MINGW-SEH %s
+
+MSVC-NOT: -fdwarf-exceptions
+MSVC-NOT: -fseh-exceptions
+MINGW-DWARF: -fdwarf-exceptions
+MINGW-SEH: -fseh-exceptions
Index: cfe/trunk/lib/Driver/ToolChain.cpp
===
--- cfe/trunk/lib/Driver/ToolChain.cpp
+++ cfe/trunk/lib/Driver/ToolChain.cpp
@@ -471,8 +471,6 @@
 
 llvm::ExceptionHandling
 ToolChain::GetExceptionModel(const llvm::opt::ArgList &Args) const {
-  if (Triple.isOSWindows() && Triple.getArch() != llvm::Triple::x86)
-return llvm::ExceptionHandling::WinEH;
   return llvm::ExceptionHandling::None;
 }
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D47853: [Frontend] Disallow non-MSVC exception models for windows-msvc targets

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai created this revision.
smeenai added reviewers: compnerd, mstorsjo, rnk.

The windows-msvc target is used for MSVC ABI compatibility, including
the exceptions model. It doesn't make sense to pair a windows-msvc
target with a non-MSVC exception model. This would previously cause an
assertion failure; explicitly error out for it in the frontend instead.
This also allows us to reduce the matrix of target/exception models a
bit (see the modified tests), and we can possibly simplify some of the
personality code in a follow-up.


Repository:
  rC Clang

https://reviews.llvm.org/D47853

Files:
  include/clang/Basic/DiagnosticFrontendKinds.td
  lib/Frontend/CompilerInvocation.cpp
  test/CodeGen/personality.c
  test/CodeGenCXX/ms-eh-personality.cpp
  test/CodeGenCXX/personality.cpp
  test/CodeGenObjC/personality.m
  test/CodeGenObjCXX/personality.mm
  test/Frontend/windows-exceptions.cpp

Index: test/Frontend/windows-exceptions.cpp
===
--- /dev/null
+++ test/Frontend/windows-exceptions.cpp
@@ -0,0 +1,27 @@
+// RUN: %clang_cc1 -triple i686--windows-msvc -fsyntax-only %s
+// RUN: not %clang_cc1 -triple i686--windows-msvc -fsyntax-only -fdwarf-exceptions %s 2>&1 | FileCheck -check-prefix=MSVC-X86-DWARF %s
+// RUN: not %clang_cc1 -triple i686--windows-msvc -fsyntax-only -fseh-exceptions %s 2>&1 | FileCheck -check-prefix=MSVC-X86-SEH %s
+// RUN: not %clang_cc1 -triple i686--windows-msvc -fsyntax-only -fsjlj-exceptions %s 2>&1 | FileCheck -check-prefix=MSVC-X86-SJLJ %s
+
+// RUN: %clang_cc1 -triple x86_64--windows-msvc -fsyntax-only %s
+// RUN: not %clang_cc1 -triple x86_64--windows-msvc -fsyntax-only -fdwarf-exceptions %s 2>&1 | FileCheck -check-prefix=MSVC-X64-DWARF %s
+// RUN: not %clang_cc1 -triple x86_64--windows-msvc -fsyntax-only -fseh-exceptions %s 2>&1 | FileCheck -check-prefix=MSVC-X64-SEH %s
+// RUN: not %clang_cc1 -triple x86_64--windows-msvc -fsyntax-only -fsjlj-exceptions %s 2>&1 | FileCheck -check-prefix=MSVC-X64-SJLJ %s
+
+// RUN: %clang_cc1 -triple i686--windows-gnu -fsyntax-only %s
+// RUN: %clang_cc1 -triple i686--windows-gnu -fsyntax-only -fdwarf-exceptions %s
+// RUN: %clang_cc1 -triple i686--windows-gnu -fsyntax-only -fseh-exceptions %s
+// RUN: %clang_cc1 -triple i686--windows-gnu -fsyntax-only -fsjlj-exceptions %s
+
+// RUN: %clang_cc1 -triple x86_64--windows-gnu -fsyntax-only %s
+// RUN: %clang_cc1 -triple x86_64--windows-gnu -fsyntax-only -fdwarf-exceptions %s
+// RUN: %clang_cc1 -triple x86_64--windows-gnu -fsyntax-only -fseh-exceptions %s
+// RUN: %clang_cc1 -triple x86_64--windows-gnu -fsyntax-only -fsjlj-exceptions %s
+
+// MSVC-X86-DWARF: error: invalid exception model 'fdwarf-exceptions' for target 'i686--windows-msvc'
+// MSVC-X86-SEH: error: invalid exception model 'fseh-exceptions' for target 'i686--windows-msvc'
+// MSVC-X86-SJLJ: error: invalid exception model 'fsjlj-exceptions' for target 'i686--windows-msvc'
+
+// MSVC-X64-DWARF: error: invalid exception model 'fdwarf-exceptions' for target 'x86_64--windows-msvc'
+// MSVC-X64-SEH: error: invalid exception model 'fseh-exceptions' for target 'x86_64--windows-msvc'
+// MSVC-X64-SJLJ: error: invalid exception model 'fsjlj-exceptions' for target 'x86_64--windows-msvc'
Index: test/CodeGenObjCXX/personality.mm
===
--- test/CodeGenObjCXX/personality.mm
+++ test/CodeGenObjCXX/personality.mm
@@ -26,31 +26,13 @@
 // RUN: %clang_cc1 -triple i686-unknown-linux-gnu -fexceptions -fsjlj-exceptions -fobjc-exceptions -fcxx-exceptions -fobjc-runtime=objfw -S -emit-llvm %s -o - | FileCheck %s -check-prefix CHECK-OBJFW-SJLJ
 
 // RUN: %clang_cc1 -triple i686-unknown-windows-msvc -fexceptions -fobjc-exceptions -fcxx-exceptions -fobjc-runtime=macosx-fragile -S -emit-llvm %s -o - | FileCheck %s -check-prefix CHECK-WIN-MACOSX-FRAGILE
-// RUN: %clang_cc1 -triple i686-unknown-windows-msvc -fexceptions -fdwarf-exceptions -fobjc-exceptions -fcxx-exceptions -fobjc-runtime=macosx-fragile -S -emit-llvm %s -o - | FileCheck %s -check-prefix CHECK-WIN-MACOSX-FRAGILE-DWARF
-// RUN: %clang_cc1 -triple i686-unknown-windows-msvc -fexceptions -fseh-exceptions -fobjc-exceptions -fcxx-exceptions -fobjc-runtime=macosx-fragile -S -emit-llvm %s -o - | FileCheck %s -check-prefix CHECK-WIN-MACOSX-FRAGILE-SEH
-// RUN: %clang_cc1 -triple i686-unknown-windows-msvc -fexceptions -fsjlj-exceptions -fobjc-exceptions -fcxx-exceptions -fobjc-runtime=macosx-fragile -S -emit-llvm %s -o - | FileCheck %s -check-prefix CHECK-WIN-MACOSX-FRAGILE-SJLJ
 // RUN: %clang_cc1 -triple i686-unknown-windows-msvc -fexceptions -fobjc-exceptions -fcxx-exceptions -fobjc-runtime=macosx -S -emit-llvm %s -o - | FileCheck %s -check-prefix CHECK-WIN-NS
-// RUN: %clang_cc1 -triple i686-unknown-windows-msvc -fexceptions -fdwarf-exceptions -fobjc-exceptions -fcxx-exceptions -fobjc-runtime=macosx -S -emit-llvm %s -o - | FileCheck %s -check-prefix CHECK-WIN-NS-DWARF
-// RUN: %clang_c

[PATCH] D47862: [CodeGen] Always use MSVC personality for windows-msvc targets

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai created this revision.
smeenai added reviewers: compnerd, DHowett-MSFT, rnk.

The windows-msvc target is meant to be ABI compatible with MSVC,
including the exception handling. Ensure that a windows-msvc triple
always equates to the MSVC personality being used.

This mostly affects the GNUStep and ObjFW Obj-C runtimes. To the best of
my knowledge, those are normally not used with windows-msvc triples. I
believe WinObjC is based on GNUStep (or it at least uses libobjc2), but
that also takes the approach of wrapping Obj-C exceptions in C++
exceptions, so the MSVC personality function is the right one to use
there as well.


Repository:
  rC Clang

https://reviews.llvm.org/D47862

Files:
  lib/CodeGen/CGException.cpp
  test/CodeGenObjC/personality.m
  test/CodeGenObjCXX/personality.mm

Index: test/CodeGenObjCXX/personality.mm
===
--- test/CodeGenObjCXX/personality.mm
+++ test/CodeGenObjCXX/personality.mm
@@ -25,14 +25,14 @@
 // RUN: %clang_cc1 -triple i686-unknown-linux-gnu -fexceptions -fseh-exceptions -fobjc-exceptions -fcxx-exceptions -fobjc-runtime=objfw -S -emit-llvm %s -o - | FileCheck %s -check-prefix CHECK-OBJFW-SEH
 // RUN: %clang_cc1 -triple i686-unknown-linux-gnu -fexceptions -fsjlj-exceptions -fobjc-exceptions -fcxx-exceptions -fobjc-runtime=objfw -S -emit-llvm %s -o - | FileCheck %s -check-prefix CHECK-OBJFW-SJLJ
 
-// RUN: %clang_cc1 -triple i686-unknown-windows-msvc -fexceptions -fobjc-exceptions -fcxx-exceptions -fobjc-runtime=macosx-fragile -S -emit-llvm %s -o - | FileCheck %s -check-prefix CHECK-WIN-MACOSX-FRAGILE
-// RUN: %clang_cc1 -triple i686-unknown-windows-msvc -fexceptions -fobjc-exceptions -fcxx-exceptions -fobjc-runtime=macosx -S -emit-llvm %s -o - | FileCheck %s -check-prefix CHECK-WIN-NS
-// RUN: %clang_cc1 -triple i686-unknown-windows-msvc -fexceptions -fobjc-exceptions -fcxx-exceptions -fobjc-runtime=ios -S -emit-llvm %s -o - | FileCheck %s -check-prefix CHECK-WIN-NS
-// RUN: %clang_cc1 -triple i686-unknown-windows-msvc -fexceptions -fobjc-exceptions -fcxx-exceptions -fobjc-runtime=watchos -S -emit-llvm %s -o - | FileCheck %s -check-prefix CHECK-WIN-NS
-// RUN: %clang_cc1 -triple i686-unknown-windows-msvc -fexceptions -fobjc-exceptions -fcxx-exceptions -fobjc-runtime=gnustep-1.7 -S -emit-llvm %s -o - | FileCheck %s -check-prefix CHECK-GNUSTEP-1_7
-// RUN: %clang_cc1 -triple i686-unknown-windows-msvc -fexceptions -fobjc-exceptions -fcxx-exceptions -fobjc-runtime=gnustep -S -emit-llvm %s -o - | FileCheck %s -check-prefix CHECK-GNUSTEP
-// RUN: %clang_cc1 -triple i686-unknown-windows-msvc -fexceptions -fobjc-exceptions -fcxx-exceptions -fobjc-runtime=gcc -S -emit-llvm %s -o - | FileCheck %s -check-prefix CHECK-GCC
-// RUN: %clang_cc1 -triple i686-unknown-windows-msvc -fexceptions -fobjc-exceptions -fcxx-exceptions -fobjc-runtime=objfw -S -emit-llvm %s -o - | FileCheck %s -check-prefix CHECK-OBJFW
+// RUN: %clang_cc1 -triple i686-unknown-windows-msvc -fexceptions -fobjc-exceptions -fcxx-exceptions -fobjc-runtime=macosx-fragile -S -emit-llvm %s -o - | FileCheck %s -check-prefix CHECK-WIN-MSVC
+// RUN: %clang_cc1 -triple i686-unknown-windows-msvc -fexceptions -fobjc-exceptions -fcxx-exceptions -fobjc-runtime=macosx -S -emit-llvm %s -o - | FileCheck %s -check-prefix CHECK-WIN-MSVC
+// RUN: %clang_cc1 -triple i686-unknown-windows-msvc -fexceptions -fobjc-exceptions -fcxx-exceptions -fobjc-runtime=ios -S -emit-llvm %s -o - | FileCheck %s -check-prefix CHECK-WIN-MSVC
+// RUN: %clang_cc1 -triple i686-unknown-windows-msvc -fexceptions -fobjc-exceptions -fcxx-exceptions -fobjc-runtime=watchos -S -emit-llvm %s -o - | FileCheck %s -check-prefix CHECK-WIN-MSVC
+// RUN: %clang_cc1 -triple i686-unknown-windows-msvc -fexceptions -fobjc-exceptions -fcxx-exceptions -fobjc-runtime=gnustep-1.7 -S -emit-llvm %s -o - | FileCheck %s -check-prefix CHECK-WIN-MSVC
+// RUN: %clang_cc1 -triple i686-unknown-windows-msvc -fexceptions -fobjc-exceptions -fcxx-exceptions -fobjc-runtime=gnustep -S -emit-llvm %s -o - | FileCheck %s -check-prefix CHECK-WIN-MSVC
+// RUN: %clang_cc1 -triple i686-unknown-windows-msvc -fexceptions -fobjc-exceptions -fcxx-exceptions -fobjc-runtime=gcc -S -emit-llvm %s -o - | FileCheck %s -check-prefix CHECK-WIN-MSVC
+// RUN: %clang_cc1 -triple i686-unknown-windows-msvc -fexceptions -fobjc-exceptions -fcxx-exceptions -fobjc-runtime=objfw -S -emit-llvm %s -o - | FileCheck %s -check-prefix CHECK-WIN-MSVC
 
 // RUN: %clang_cc1 -triple i686-unknown-windows-gnu -fexceptions -fobjc-exceptions -fcxx-exceptions -fobjc-runtime=macosx-fragile -S -emit-llvm %s -o - | FileCheck %s -check-prefix CHECK-MACOSX-FRAGILE
 // RUN: %clang_cc1 -triple i686-unknown-windows-gnu -fexceptions -fdwarf-exceptions -fobjc-exceptions -fcxx-exceptions -fobjc-runtime=macosx-fragile -S -emit-llvm %s -o - | FileCheck %s -check-prefix CHECK-MACOSX-FRAGILE
@@ -80,8 +80,7 @@
 // CHECK-OBJFW-SEH: personality i8* bitcast (i32 (...)* @__gnu_objc_personality_

[PATCH] D47853: [Frontend] Disallow non-MSVC exception models for windows-msvc targets

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai marked 2 inline comments as done.
smeenai added inline comments.



Comment at: test/CodeGen/personality.c:10
-// RUN: %clang_cc1 -triple x86_64-unknown-windows-msvc -D __SEH_EXCEPTIONS__ 
-fms-extensions -fexceptions -fblocks -fseh-exceptions -S -emit-llvm %s -o - | 
FileCheck %s -check-prefix CHECK-WIN-SEH -check-prefix CHECK-WIN-SEH-X64
-// RUN: %clang_cc1 -triple i686-unknown-windows-msvc -fexceptions -fblocks 
-fsjlj-exceptions -S -emit-llvm %s -o - | FileCheck %s -check-prefix 
CHECK-WIN-SJLJ
 

mstorsjo wrote:
> I'd prefer if you didn't remove these tests, but instead retarget them to use 
> a `-gnu` triplet, to keep testing where you can explicitly choose between 
> sjlj/dwarf/seh for mingw setups.
I'll re-add those back; I didnt' realize they weren't already covered. I'm 
gonna drop the __SEH_EXCEPTIONS__ thing for MinGW, since AFAIK SEH 
`__try`/`__finally` doesn't work there.



Comment at: test/CodeGenCXX/personality.cpp:9
-// RUN: %clang_cc1 -triple i686-unknown-windows-msvc -fexceptions 
-fseh-exceptions -fcxx-exceptions -S -emit-llvm %s -o - | FileCheck %s 
-check-prefix CHECK-WIN-SEH
-// %clang_cc1 -triple i686-unknown-windows-msvc -fexceptions -fsjlj-exceptions 
-fcxx-exceptions -S -emit-llvm %s -o - | FileCheck %s -check-prefix 
CHECK-WIN-SJLJ
-// RUN: %clang_cc1 -triple i686-unknown-windows-msvc -D __SEH_EXCEPTIONS__ 
-fms-extensions -fexceptions -fseh-exceptions -fcxx-exceptions -S -emit-llvm %s 
-o - | FileCheck %s -check-prefix CHECK-WIN-SEH-X86

mstorsjo wrote:
> Same here, please keep the existing tests but retarget them to gnu/mingw.
This should all be covered by the group of RUN lines right below this one.


Repository:
  rC Clang

https://reviews.llvm.org/D47853



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D47853: [Frontend] Disallow non-MSVC exception models for windows-msvc targets

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai updated this revision to Diff 150394.
smeenai marked 2 inline comments as done.
smeenai added a comment.

Add back missing MinGW coverage


Repository:
  rC Clang

https://reviews.llvm.org/D47853

Files:
  include/clang/Basic/DiagnosticFrontendKinds.td
  lib/Frontend/CompilerInvocation.cpp
  test/CodeGen/personality.c
  test/CodeGenCXX/ms-eh-personality.cpp
  test/CodeGenCXX/personality.cpp
  test/CodeGenObjC/personality.m
  test/CodeGenObjCXX/personality.mm
  test/Frontend/windows-exceptions.cpp

Index: test/Frontend/windows-exceptions.cpp
===
--- /dev/null
+++ test/Frontend/windows-exceptions.cpp
@@ -0,0 +1,27 @@
+// RUN: %clang_cc1 -triple i686--windows-msvc -fsyntax-only %s
+// RUN: not %clang_cc1 -triple i686--windows-msvc -fsyntax-only -fdwarf-exceptions %s 2>&1 | FileCheck -check-prefix=MSVC-X86-DWARF %s
+// RUN: not %clang_cc1 -triple i686--windows-msvc -fsyntax-only -fseh-exceptions %s 2>&1 | FileCheck -check-prefix=MSVC-X86-SEH %s
+// RUN: not %clang_cc1 -triple i686--windows-msvc -fsyntax-only -fsjlj-exceptions %s 2>&1 | FileCheck -check-prefix=MSVC-X86-SJLJ %s
+
+// RUN: %clang_cc1 -triple x86_64--windows-msvc -fsyntax-only %s
+// RUN: not %clang_cc1 -triple x86_64--windows-msvc -fsyntax-only -fdwarf-exceptions %s 2>&1 | FileCheck -check-prefix=MSVC-X64-DWARF %s
+// RUN: not %clang_cc1 -triple x86_64--windows-msvc -fsyntax-only -fseh-exceptions %s 2>&1 | FileCheck -check-prefix=MSVC-X64-SEH %s
+// RUN: not %clang_cc1 -triple x86_64--windows-msvc -fsyntax-only -fsjlj-exceptions %s 2>&1 | FileCheck -check-prefix=MSVC-X64-SJLJ %s
+
+// RUN: %clang_cc1 -triple i686--windows-gnu -fsyntax-only %s
+// RUN: %clang_cc1 -triple i686--windows-gnu -fsyntax-only -fdwarf-exceptions %s
+// RUN: %clang_cc1 -triple i686--windows-gnu -fsyntax-only -fseh-exceptions %s
+// RUN: %clang_cc1 -triple i686--windows-gnu -fsyntax-only -fsjlj-exceptions %s
+
+// RUN: %clang_cc1 -triple x86_64--windows-gnu -fsyntax-only %s
+// RUN: %clang_cc1 -triple x86_64--windows-gnu -fsyntax-only -fdwarf-exceptions %s
+// RUN: %clang_cc1 -triple x86_64--windows-gnu -fsyntax-only -fseh-exceptions %s
+// RUN: %clang_cc1 -triple x86_64--windows-gnu -fsyntax-only -fsjlj-exceptions %s
+
+// MSVC-X86-DWARF: error: invalid exception model 'fdwarf-exceptions' for target 'i686--windows-msvc'
+// MSVC-X86-SEH: error: invalid exception model 'fseh-exceptions' for target 'i686--windows-msvc'
+// MSVC-X86-SJLJ: error: invalid exception model 'fsjlj-exceptions' for target 'i686--windows-msvc'
+
+// MSVC-X64-DWARF: error: invalid exception model 'fdwarf-exceptions' for target 'x86_64--windows-msvc'
+// MSVC-X64-SEH: error: invalid exception model 'fseh-exceptions' for target 'x86_64--windows-msvc'
+// MSVC-X64-SJLJ: error: invalid exception model 'fsjlj-exceptions' for target 'x86_64--windows-msvc'
Index: test/CodeGenObjCXX/personality.mm
===
--- test/CodeGenObjCXX/personality.mm
+++ test/CodeGenObjCXX/personality.mm
@@ -26,31 +26,13 @@
 // RUN: %clang_cc1 -triple i686-unknown-linux-gnu -fexceptions -fsjlj-exceptions -fobjc-exceptions -fcxx-exceptions -fobjc-runtime=objfw -S -emit-llvm %s -o - | FileCheck %s -check-prefix CHECK-OBJFW-SJLJ
 
 // RUN: %clang_cc1 -triple i686-unknown-windows-msvc -fexceptions -fobjc-exceptions -fcxx-exceptions -fobjc-runtime=macosx-fragile -S -emit-llvm %s -o - | FileCheck %s -check-prefix CHECK-WIN-MACOSX-FRAGILE
-// RUN: %clang_cc1 -triple i686-unknown-windows-msvc -fexceptions -fdwarf-exceptions -fobjc-exceptions -fcxx-exceptions -fobjc-runtime=macosx-fragile -S -emit-llvm %s -o - | FileCheck %s -check-prefix CHECK-WIN-MACOSX-FRAGILE-DWARF
-// RUN: %clang_cc1 -triple i686-unknown-windows-msvc -fexceptions -fseh-exceptions -fobjc-exceptions -fcxx-exceptions -fobjc-runtime=macosx-fragile -S -emit-llvm %s -o - | FileCheck %s -check-prefix CHECK-WIN-MACOSX-FRAGILE-SEH
-// RUN: %clang_cc1 -triple i686-unknown-windows-msvc -fexceptions -fsjlj-exceptions -fobjc-exceptions -fcxx-exceptions -fobjc-runtime=macosx-fragile -S -emit-llvm %s -o - | FileCheck %s -check-prefix CHECK-WIN-MACOSX-FRAGILE-SJLJ
 // RUN: %clang_cc1 -triple i686-unknown-windows-msvc -fexceptions -fobjc-exceptions -fcxx-exceptions -fobjc-runtime=macosx -S -emit-llvm %s -o - | FileCheck %s -check-prefix CHECK-WIN-NS
-// RUN: %clang_cc1 -triple i686-unknown-windows-msvc -fexceptions -fdwarf-exceptions -fobjc-exceptions -fcxx-exceptions -fobjc-runtime=macosx -S -emit-llvm %s -o - | FileCheck %s -check-prefix CHECK-WIN-NS-DWARF
-// RUN: %clang_cc1 -triple i686-unknown-windows-msvc -fexceptions -fseh-exceptions -fobjc-exceptions -fcxx-exceptions -fobjc-runtime=macosx -S -emit-llvm %s -o - | FileCheck %s -check-prefix CHECK-WIN-NS
-// RUN: %clang_cc1 -triple i686-unknown-windows-msvc -fexceptions -fsjlj-exceptions -fobjc-exceptions -fcxx-exceptions -fobjc-runtime=macosx -S -emit-llvm %s -o - | FileCheck %s -check-prefix CHECK-WIN

[PATCH] D47564: [Parse] Use CapturedStmt for @finally on MSVC

[Shoaib Meenai via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL334224: [Parse] Use CapturedStmt for @finally on MSVC 
(authored by smeenai, committed by ).
Herald added a subscriber: llvm-commits.

Repository:
  rL LLVM

https://reviews.llvm.org/D47564

Files:
  cfe/trunk/include/clang/AST/Stmt.h
  cfe/trunk/include/clang/Basic/CapturedStmt.h
  cfe/trunk/include/clang/Sema/ScopeInfo.h
  cfe/trunk/lib/Parse/ParseObjc.cpp
  cfe/trunk/test/SemaObjC/finally-msvc.m


Index: cfe/trunk/test/SemaObjC/finally-msvc.m
===
--- cfe/trunk/test/SemaObjC/finally-msvc.m
+++ cfe/trunk/test/SemaObjC/finally-msvc.m
@@ -0,0 +1,14 @@
+// RUN: %clang_cc1 -triple i686--windows-msvc -fexceptions -fobjc-exceptions 
-ast-dump %s 2>&1 | FileCheck %s
+// RUN: %clang_cc1 -triple x86_64--windows-msvc -fexceptions -fobjc-exceptions 
-ast-dump %s 2>&1 | FileCheck %s
+
+void f() {
+  @try {
+  } @finally {
+  }
+}
+
+// CHECK:  ObjCAtFinallyStmt
+// CHECK-NEXT:   CapturedStmt
+// CHECK-NEXT: CapturedDecl
+// CHECK-NEXT:   CompoundStmt
+// CHECK-NEXT:   ImplicitParamDecl
Index: cfe/trunk/lib/Parse/ParseObjc.cpp
===
--- cfe/trunk/lib/Parse/ParseObjc.cpp
+++ cfe/trunk/lib/Parse/ParseObjc.cpp
@@ -2585,13 +2585,26 @@
   ParseScope FinallyScope(this,
   Scope::DeclScope | Scope::CompoundStmtScope);
 
+  bool ShouldCapture =
+  getTargetInfo().getTriple().isWindowsMSVCEnvironment();
+  if (ShouldCapture)
+Actions.ActOnCapturedRegionStart(Tok.getLocation(), getCurScope(),
+ CR_ObjCAtFinally, 1);
+
   StmtResult FinallyBody(true);
   if (Tok.is(tok::l_brace))
 FinallyBody = ParseCompoundStatementBody();
   else
 Diag(Tok, diag::err_expected) << tok::l_brace;
-  if (FinallyBody.isInvalid())
+
+  if (FinallyBody.isInvalid()) {
 FinallyBody = Actions.ActOnNullStmt(Tok.getLocation());
+if (ShouldCapture)
+  Actions.ActOnCapturedRegionError();
+  } else if (ShouldCapture) {
+FinallyBody = Actions.ActOnCapturedRegionEnd(FinallyBody.get());
+  }
+
   FinallyStmt = Actions.ActOnObjCAtFinallyStmt(AtCatchFinallyLoc,
FinallyBody.get());
   catch_or_finally_seen = true;
Index: cfe/trunk/include/clang/AST/Stmt.h
===
--- cfe/trunk/include/clang/AST/Stmt.h
+++ cfe/trunk/include/clang/AST/Stmt.h
@@ -2133,7 +2133,7 @@
 
   /// The pointer part is the implicit the outlined function and the 
   /// int part is the captured region kind, 'CR_Default' etc.
-  llvm::PointerIntPair CapDeclAndKind;
+  llvm::PointerIntPair CapDeclAndKind;
 
   /// The record for captured variables, a RecordDecl or CXXRecordDecl.
   RecordDecl *TheRecordDecl = nullptr;
Index: cfe/trunk/include/clang/Sema/ScopeInfo.h
===
--- cfe/trunk/include/clang/Sema/ScopeInfo.h
+++ cfe/trunk/include/clang/Sema/ScopeInfo.h
@@ -748,6 +748,8 @@
 switch (CapRegionKind) {
 case CR_Default:
   return "default captured statement";
+case CR_ObjCAtFinally:
+  return "Objective-C @finally statement";
 case CR_OpenMP:
   return "OpenMP region";
 }
Index: cfe/trunk/include/clang/Basic/CapturedStmt.h
===
--- cfe/trunk/include/clang/Basic/CapturedStmt.h
+++ cfe/trunk/include/clang/Basic/CapturedStmt.h
@@ -16,6 +16,7 @@
 /// The different kinds of captured statement.
 enum CapturedRegionKind {
   CR_Default,
+  CR_ObjCAtFinally,
   CR_OpenMP
 };
 


Index: cfe/trunk/test/SemaObjC/finally-msvc.m
===
--- cfe/trunk/test/SemaObjC/finally-msvc.m
+++ cfe/trunk/test/SemaObjC/finally-msvc.m
@@ -0,0 +1,14 @@
+// RUN: %clang_cc1 -triple i686--windows-msvc -fexceptions -fobjc-exceptions -ast-dump %s 2>&1 | FileCheck %s
+// RUN: %clang_cc1 -triple x86_64--windows-msvc -fexceptions -fobjc-exceptions -ast-dump %s 2>&1 | FileCheck %s
+
+void f() {
+  @try {
+  } @finally {
+  }
+}
+
+// CHECK:  ObjCAtFinallyStmt
+// CHECK-NEXT:   CapturedStmt
+// CHECK-NEXT: CapturedDecl
+// CHECK-NEXT:   CompoundStmt
+// CHECK-NEXT:   ImplicitParamDecl
Index: cfe/trunk/lib/Parse/ParseObjc.cpp
===
--- cfe/trunk/lib/Parse/ParseObjc.cpp
+++ cfe/trunk/lib/Parse/ParseObjc.cpp
@@ -2585,13 +2585,26 @@
   ParseScope FinallyScope(this,
   Scope::DeclScope | Scope::CompoundStmtScope);
 
+  bool ShouldCapture =
+  getTargetInfo().getTriple().isWindowsMSVCEnvironment();
+  if (ShouldCapture)
+Actions.ActOnCapturedRegionStart(Tok.getLocation(), getC

[PATCH] D47233: [CodeGen] Emit MSVC RTTI for Obj-C EH types

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai updated this revision to Diff 150399.
smeenai added a comment.

Address objc_exception attribute case


Repository:
  rC Clang

https://reviews.llvm.org/D47233

Files:
  lib/CodeGen/CGCXXABI.h
  lib/CodeGen/CGObjCMac.cpp
  lib/CodeGen/MicrosoftCXXABI.cpp
  test/CodeGenObjC/dllstorage.m
  test/CodeGenObjC/exceptions-msvc.m

Index: test/CodeGenObjC/exceptions-msvc.m
===
--- /dev/null
+++ test/CodeGenObjC/exceptions-msvc.m
@@ -0,0 +1,81 @@
+// RUN: %clang_cc1 -triple i686--windows-msvc -fobjc-runtime=ios-6.0 -fdeclspec -fexceptions -fobjc-exceptions -emit-llvm -o - %s | FileCheck -check-prefixes=CHECK,X86 %s
+// RUN: %clang_cc1 -triple i686--windows-msvc -fobjc-runtime=ios-6.0 -fobjc-arc -fdeclspec -fexceptions -fobjc-exceptions -emit-llvm -o - %s | FileCheck -check-prefixes=CHECK,X86 %s
+// RUN: %clang_cc1 -triple x86_64--windows-msvc -fobjc-runtime=ios-6.0 -fdeclspec -fexceptions -fobjc-exceptions -emit-llvm -o - %s | FileCheck -check-prefixes=CHECK,X64 %s
+// RUN: %clang_cc1 -triple x86_64--windows-msvc -fobjc-runtime=ios-6.0 -fobjc-arc -fdeclspec -fexceptions -fobjc-exceptions -emit-llvm -o - %s | FileCheck -check-prefixes=CHECK,X64 %s
+
+#if __has_feature(objc_arc)
+#define WEAK __weak
+#else
+#define WEAK
+#endif
+
+// CHECK-DAG: $OBJC_EHTYPE_id = comdat any
+// X86-DAG: @OBJC_EHTYPE_id = linkonce_odr global {{%[^ ]+}} { i8** @"??_7type_info@@6B@", i8* null, [18 x i8] c".PAUobjc_object@@\00" }, comdat
+// X64-DAG: @OBJC_EHTYPE_id = linkonce_odr global {{%[^ ]+}} { i8** @"??_7type_info@@6B@", i8* null, [19 x i8] c".PEAUobjc_object@@\00" }, comdat
+
+@class I;
+
+// CHECK-DAG: $"OBJC_EHTYPE_$_I" = comdat any
+// X86-DAG: @"OBJC_EHTYPE_$_I" = linkonce_odr global {{%[^ ]+}} { i8** @"??_7type_info@@6B@", i8* null, [8 x i8] c".PAUI@@\00" }, comdat
+// X64-DAG: @"OBJC_EHTYPE_$_I" = linkonce_odr global {{%[^ ]+}} { i8** @"??_7type_info@@6B@", i8* null, [9 x i8] c".PEAUI@@\00" }, comdat
+
+@class J;
+
+// CHECK-DAG: $"OBJC_EHTYPE_$_J" = comdat any
+// X86-DAG: @"OBJC_EHTYPE_$_J" = linkonce_odr global {{%[^ ]+}} { i8** @"??_7type_info@@6B@", i8* null, [8 x i8] c".PAUJ@@\00" }, comdat
+// X64-DAG: @"OBJC_EHTYPE_$_J" = linkonce_odr global {{%[^ ]+}} { i8** @"??_7type_info@@6B@", i8* null, [9 x i8] c".PEAUJ@@\00" }, comdat
+
+// The EHType shouldn't be exported
+__declspec(dllexport)
+__attribute__((objc_root_class))
+@interface K
+@end
+
+@implementation K
+@end
+
+// CHECK-DAG: $"OBJC_EHTYPE_$_K" = comdat any
+// X86-DAG: @"OBJC_EHTYPE_$_K" = linkonce_odr global {{%[^ ]+}} { i8** @"??_7type_info@@6B@", i8* null, [8 x i8] c".PAUK@@\00" }, comdat
+// X64-DAG: @"OBJC_EHTYPE_$_K" = linkonce_odr global {{%[^ ]+}} { i8** @"??_7type_info@@6B@", i8* null, [9 x i8] c".PEAUK@@\00" }, comdat
+
+__attribute__((objc_root_class))
+__attribute__((objc_runtime_name("NotL")))
+@interface L
+@end
+
+// CHECK-DAG: $"OBJC_EHTYPE_$_NotL" = comdat any
+// X86-DAG: @"OBJC_EHTYPE_$_NotL" = linkonce_odr global {{%[^ ]+}} { i8** @"??_7type_info@@6B@", i8* null, [8 x i8] c".PAUL@@\00" }, comdat
+// X64-DAG: @"OBJC_EHTYPE_$_NotL" = linkonce_odr global {{%[^ ]+}} { i8** @"??_7type_info@@6B@", i8* null, [9 x i8] c".PEAUL@@\00" }, comdat
+
+@class M;
+
+// CHECK-DAG: $"OBJC_EHTYPE_$_M" = comdat any
+// X86-DAG: @"OBJC_EHTYPE_$_M" = linkonce_odr global {{%[^ ]+}} { i8** @"??_7type_info@@6B@", i8* null, [8 x i8] c".PAUM@@\00" }, comdat
+// X64-DAG: @"OBJC_EHTYPE_$_M" = linkonce_odr global {{%[^ ]+}} { i8** @"??_7type_info@@6B@", i8* null, [9 x i8] c".PEAUM@@\00" }, comdat
+
+// The EHType shouldn't be generated for this definition, since it's not referenced.
+__attribute__((objc_root_class))
+__attribute__((objc_exception))
+@interface N
+@end
+
+@implementation N
+@end
+
+// CHECK-NOT: @"OBJC_EHTYPE_$_N"
+
+@protocol P;
+
+void f(void);
+
+void g() {
+  @try {
+f();
+  } @catch (I *) {
+  } @catch (J *) {
+  } @catch (K *) {
+  } @catch (L *) {
+  } @catch (M *WEAK) {
+  } @catch (id) {
+  }
+}
Index: test/CodeGenObjC/dllstorage.m
===
--- test/CodeGenObjC/dllstorage.m
+++ test/CodeGenObjC/dllstorage.m
@@ -1,5 +1,5 @@
 // RUN: %clang_cc1 -triple x86_64-unknown-windows-msvc -fdeclspec -fobjc-runtime=ios -fobjc-exceptions -S -emit-llvm -o - %s | FileCheck -check-prefix CHECK-IR %s
-// RUN: %clang_cc1 -triple i686-windows-itanium -fms-extensions -fobjc-runtime=macosx -fdeclspec -fobjc-exceptions -S -emit-llvm -o - %s | FileCheck -check-prefix CHECK-IR %s
+// RUN: %clang_cc1 -triple i686-windows-itanium -fms-extensions -fobjc-runtime=macosx -fdeclspec -fobjc-exceptions -S -emit-llvm -o - %s | FileCheck -check-prefix CHECK-IR -check-prefix CHECK-ITANIUM %s
 // RUN: %clang_cc1 -triple i686-windows-itanium -fms-extensions -fobjc-runtime=objfw -fdeclspec -fobjc-exceptions -S -emit-llvm -o - %s | FileCheck -check-prefix CHECK-FW %s
 
 // CHECK-IR-DAG: @_objc_empty_cache = external dllimport global %struct._objc_cache

[PATCH] D47233: [CodeGen] Emit MSVC RTTI for Obj-C EH types

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai added a comment.

Ping @rjmccall


Repository:
  rC Clang

https://reviews.llvm.org/D47233



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D47912: [CMake] Consider LLVM_APPEND_VC_REV when generating SVNVersion.inc

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai added a comment.

I believe LLVM_APPEND_VC_REV controls whether the revision is appended to LLVM 
version string (e.g. the output of `llvm-config --version`), whereas the 
SVNRevision.inc file (which is what's causing the relink after amending) is 
used for e.g. the `clang --version` output, so I'm not sure this is the right 
thing to do. I would also love for an option to disable the SVNRevision stuff 
entirely though.


Repository:
  rC Clang

https://reviews.llvm.org/D47912



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D47853: [Frontend] Disallow non-MSVC exception models for windows-msvc targets

[Shoaib Meenai via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL334243: [Frontend] Disallow non-MSVC exception models for 
windows-msvc targets (authored by smeenai, committed by ).
Herald added a subscriber: llvm-commits.

Repository:
  rL LLVM

https://reviews.llvm.org/D47853

Files:
  cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
  cfe/trunk/lib/Frontend/CompilerInvocation.cpp
  cfe/trunk/test/CodeGen/personality.c
  cfe/trunk/test/CodeGenCXX/ms-eh-personality.cpp
  cfe/trunk/test/CodeGenCXX/personality.cpp
  cfe/trunk/test/CodeGenObjC/personality.m
  cfe/trunk/test/CodeGenObjCXX/personality.mm
  cfe/trunk/test/Frontend/windows-exceptions.cpp

Index: cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
===
--- cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
+++ cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
@@ -118,6 +118,8 @@
 "invalid value '%1' in '%0'; alignment must be a power of 2">;
 def err_fe_invalid_wchar_type
 : Error<"invalid wchar_t type '%0'; must be one of 'char', 'short', 'int'">;
+def err_fe_invalid_exception_model
+   : Error<"invalid exception model '%0' for target '%1'">;
 
 def warn_fe_serialized_diag_merge_failure : Warning<
 "unable to merge a subprocess's serialized diagnostics">,
Index: cfe/trunk/test/Frontend/windows-exceptions.cpp
===
--- cfe/trunk/test/Frontend/windows-exceptions.cpp
+++ cfe/trunk/test/Frontend/windows-exceptions.cpp
@@ -0,0 +1,27 @@
+// RUN: %clang_cc1 -triple i686--windows-msvc -fsyntax-only %s
+// RUN: not %clang_cc1 -triple i686--windows-msvc -fsyntax-only -fdwarf-exceptions %s 2>&1 | FileCheck -check-prefix=MSVC-X86-DWARF %s
+// RUN: not %clang_cc1 -triple i686--windows-msvc -fsyntax-only -fseh-exceptions %s 2>&1 | FileCheck -check-prefix=MSVC-X86-SEH %s
+// RUN: not %clang_cc1 -triple i686--windows-msvc -fsyntax-only -fsjlj-exceptions %s 2>&1 | FileCheck -check-prefix=MSVC-X86-SJLJ %s
+
+// RUN: %clang_cc1 -triple x86_64--windows-msvc -fsyntax-only %s
+// RUN: not %clang_cc1 -triple x86_64--windows-msvc -fsyntax-only -fdwarf-exceptions %s 2>&1 | FileCheck -check-prefix=MSVC-X64-DWARF %s
+// RUN: not %clang_cc1 -triple x86_64--windows-msvc -fsyntax-only -fseh-exceptions %s 2>&1 | FileCheck -check-prefix=MSVC-X64-SEH %s
+// RUN: not %clang_cc1 -triple x86_64--windows-msvc -fsyntax-only -fsjlj-exceptions %s 2>&1 | FileCheck -check-prefix=MSVC-X64-SJLJ %s
+
+// RUN: %clang_cc1 -triple i686--windows-gnu -fsyntax-only %s
+// RUN: %clang_cc1 -triple i686--windows-gnu -fsyntax-only -fdwarf-exceptions %s
+// RUN: %clang_cc1 -triple i686--windows-gnu -fsyntax-only -fseh-exceptions %s
+// RUN: %clang_cc1 -triple i686--windows-gnu -fsyntax-only -fsjlj-exceptions %s
+
+// RUN: %clang_cc1 -triple x86_64--windows-gnu -fsyntax-only %s
+// RUN: %clang_cc1 -triple x86_64--windows-gnu -fsyntax-only -fdwarf-exceptions %s
+// RUN: %clang_cc1 -triple x86_64--windows-gnu -fsyntax-only -fseh-exceptions %s
+// RUN: %clang_cc1 -triple x86_64--windows-gnu -fsyntax-only -fsjlj-exceptions %s
+
+// MSVC-X86-DWARF: error: invalid exception model 'fdwarf-exceptions' for target 'i686--windows-msvc'
+// MSVC-X86-SEH: error: invalid exception model 'fseh-exceptions' for target 'i686--windows-msvc'
+// MSVC-X86-SJLJ: error: invalid exception model 'fsjlj-exceptions' for target 'i686--windows-msvc'
+
+// MSVC-X64-DWARF: error: invalid exception model 'fdwarf-exceptions' for target 'x86_64--windows-msvc'
+// MSVC-X64-SEH: error: invalid exception model 'fseh-exceptions' for target 'x86_64--windows-msvc'
+// MSVC-X64-SJLJ: error: invalid exception model 'fsjlj-exceptions' for target 'x86_64--windows-msvc'
Index: cfe/trunk/test/CodeGen/personality.c
===
--- cfe/trunk/test/CodeGen/personality.c
+++ cfe/trunk/test/CodeGen/personality.c
@@ -4,13 +4,13 @@
 // RUN: %clang_cc1 -triple i686-unknown-linux-gnu -fexceptions -fsjlj-exceptions -fblocks -S -emit-llvm %s -o - | FileCheck %s -check-prefix CHECK-SJLJ
 
 // RUN: %clang_cc1 -triple i686-unknown-windows-msvc -fexceptions -fblocks -S -emit-llvm %s -o - | FileCheck %s -check-prefix CHECK-WIN
-// RUN: %clang_cc1 -triple i686-unknown-windows-msvc -fexceptions -fdwarf-exceptions -fblocks -S -emit-llvm %s -o - | FileCheck %s -check-prefix CHECK-WIN-DWARF
-// RUN: %clang_cc1 -triple i686-unknown-windows-msvc -D __SEH_EXCEPTIONS__ -fms-extensions -fexceptions -fblocks -fseh-exceptions -S -emit-llvm %s -o - | FileCheck %s -check-prefix CHECK-WIN-SEH -check-prefix CHECK-WIN-SEH-X86
-// RUN: %clang_cc1 -triple x86_64-unknown-windows-msvc -D __SEH_EXCEPTIONS__ -fms-extensions -fexceptions -fblocks -fseh-exceptions -S -emit-llvm %s -o - | FileCheck %s -check-prefix CHECK-WIN-SEH -check-prefix CHECK-WIN-SEH-X64
-// RUN: %clang_cc1 -triple i686-unknown-windows-msvc -fexceptions -fblocks -fsjlj-exc

[PATCH] D47862: [CodeGen] Always use MSVC personality for windows-msvc targets

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai added inline comments.



Comment at: lib/CodeGen/CGException.cpp:134-135
   const llvm::Triple &T = Target.getTriple();
+  if (T.isWindowsMSVCEnvironment())
+return EHPersonality::MSVC_CxxFrameHandler3;
+

rnk wrote:
> I guess previously we carefully arranged to go to whatever the regular objc 
> personality would be, but we're not doing that now with funclet windows eh.
> Maybe we could drastically simplify this by checking for an msvc environment 
> and seh before checking each language?
I gave this a shot. EHPersonality::get already has code to make SEH functions 
always get the SEH personality (line 223 below), so I added another condition 
below to make an MSVC triple always get the MSVC personality, and then removed 
all those conditionals from the individual get*Personality functions. 
Unfortunately, there's also code below (in SimplifyPersonality) that calls 
getCXXPersonality directly, so we still need to leave the MSVC check in there, 
and having the check in there but not any of the other get*Personality 
functions seems really ugly. The other option is to adjust SimplifyPersonality 
instead, which ends up looking like P8086; do you think that's worth it? Or did 
you mean something else entirely?


Repository:
  rC Clang

https://reviews.llvm.org/D47862



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D47862: [CodeGen] Always use MSVC personality for windows-msvc targets

[Shoaib Meenai via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rC334253: [CodeGen] Always use MSVC personality for 
windows-msvc targets (authored by smeenai, committed by ).

Changed prior to commit:
  https://reviews.llvm.org/D47862?vs=150243&id=150437#toc

Repository:
  rC Clang

https://reviews.llvm.org/D47862

Files:
  lib/CodeGen/CGException.cpp
  test/CodeGenObjC/personality.m
  test/CodeGenObjCXX/personality.mm

Index: test/CodeGenObjC/personality.m
===
--- test/CodeGenObjC/personality.m
+++ test/CodeGenObjC/personality.m
@@ -11,14 +11,14 @@
 // RUN: %clang_cc1 -triple i686-unknown-linux-gnu -fexceptions -fseh-exceptions -fobjc-exceptions -fobjc-runtime=objfw -S -emit-llvm %s -o - | FileCheck %s -check-prefix CHECK-OBJFW-SEH
 // RUN: %clang_cc1 -triple i686-unknown-linux-gnu -fexceptions -fsjlj-exceptions -fobjc-exceptions -fobjc-runtime=objfw -S -emit-llvm %s -o - | FileCheck %s -check-prefix CHECK-OBJFW-SJLJ
 
-// RUN: %clang_cc1 -triple i686-unknown-windows-msvc -fexceptions -fobjc-exceptions -fobjc-runtime=macosx-fragile -S -emit-llvm %s -o - | FileCheck %s -check-prefix CHECK-WIN-MACOSX-FRAGILE
-// RUN: %clang_cc1 -triple i686-unknown-windows-msvc -fexceptions -fobjc-exceptions -fobjc-runtime=ios -S -emit-llvm %s -o - | FileCheck %s -check-prefix CHECK-WIN-NS
-// RUN: %clang_cc1 -triple i686-unknown-windows-msvc -fexceptions -fobjc-exceptions -fobjc-runtime=macosx -S -emit-llvm %s -o - | FileCheck %s -check-prefix CHECK-WIN-NS
-// RUN: %clang_cc1 -triple i686-unknown-windows-msvc -fexceptions -fobjc-exceptions -fobjc-runtime=watchos -S -emit-llvm %s -o - | FileCheck %s -check-prefix CHECK-WIN-NS
-// RUN: %clang_cc1 -triple i686-unknown-windows-msvc -fexceptions -fobjc-exceptions -fobjc-runtime=gnustep-1.7 -S -emit-llvm %s -o - | FileCheck %s -check-prefix CHECK-GNUSTEP-1_7
-// RUN: %clang_cc1 -triple i686-unknown-windows-msvc -fexceptions -fobjc-exceptions -fobjc-runtime=gnustep -S -emit-llvm %s -o - | FileCheck %s -check-prefix CHECK-GNUSTEP
-// RUN: %clang_cc1 -triple i686-unknown-windows-msvc -fexceptions -fobjc-exceptions -fobjc-runtime=gcc -S -emit-llvm %s -o - | FileCheck %s -check-prefix CHECK-GCC
-// RUN: %clang_cc1 -triple i686-unknown-windows-msvc -fexceptions -fobjc-exceptions -fobjc-runtime=objfw -S -emit-llvm %s -o - | FileCheck %s -check-prefix CHECK-OBJFW
+// RUN: %clang_cc1 -triple i686-unknown-windows-msvc -fexceptions -fobjc-exceptions -fobjc-runtime=macosx-fragile -S -emit-llvm %s -o - | FileCheck %s -check-prefix CHECK-WIN-MSVC
+// RUN: %clang_cc1 -triple i686-unknown-windows-msvc -fexceptions -fobjc-exceptions -fobjc-runtime=ios -S -emit-llvm %s -o - | FileCheck %s -check-prefix CHECK-WIN-MSVC
+// RUN: %clang_cc1 -triple i686-unknown-windows-msvc -fexceptions -fobjc-exceptions -fobjc-runtime=macosx -S -emit-llvm %s -o - | FileCheck %s -check-prefix CHECK-WIN-MSVC
+// RUN: %clang_cc1 -triple i686-unknown-windows-msvc -fexceptions -fobjc-exceptions -fobjc-runtime=watchos -S -emit-llvm %s -o - | FileCheck %s -check-prefix CHECK-WIN-MSVC
+// RUN: %clang_cc1 -triple i686-unknown-windows-msvc -fexceptions -fobjc-exceptions -fobjc-runtime=gnustep-1.7 -S -emit-llvm %s -o - | FileCheck %s -check-prefix CHECK-WIN-MSVC
+// RUN: %clang_cc1 -triple i686-unknown-windows-msvc -fexceptions -fobjc-exceptions -fobjc-runtime=gnustep -S -emit-llvm %s -o - | FileCheck %s -check-prefix CHECK-WIN-MSVC
+// RUN: %clang_cc1 -triple i686-unknown-windows-msvc -fexceptions -fobjc-exceptions -fobjc-runtime=gcc -S -emit-llvm %s -o - | FileCheck %s -check-prefix CHECK-WIN-MSVC
+// RUN: %clang_cc1 -triple i686-unknown-windows-msvc -fexceptions -fobjc-exceptions -fobjc-runtime=objfw -S -emit-llvm %s -o - | FileCheck %s -check-prefix CHECK-WIN-MSVC
 
 // RUN: %clang_cc1 -triple i686-unknown-windows-gnu -fexceptions -fobjc-exceptions -fobjc-runtime=macosx-fragile -S -emit-llvm %s -o - | FileCheck %s -check-prefix CHECK-MACOSX-FRAGILE
 // RUN: %clang_cc1 -triple i686-unknown-windows-gnu -fexceptions -fdwarf-exceptions -fobjc-exceptions -fobjc-runtime=macosx-fragile -S -emit-llvm %s -o - | FileCheck %s -check-prefix CHECK-MACOSX-FRAGILE-MINGW-DWARF
@@ -49,8 +49,7 @@
 // CHECK-OBJFW-SEH: personality i8* bitcast (i32 (...)* @__gnu_objc_personality_seh0 to i8*)
 // CHECK-OBJFW-SJLJ: personality i8* bitcast (i32 (...)* @__gnu_objc_personality_sj0 to i8*)
 
-// CHECK-WIN-MACOSX-FRAGILE: personality i8* bitcast (i32 (...)* @__CxxFrameHandler3 to i8*)
-// CHECK-WIN-NS: personality i8* bitcast (i32 (...)* @__CxxFrameHandler3  to i8*)
+// CHECK-WIN-MSVC: personality i8* bitcast (i32 (...)* @__CxxFrameHandler3  to i8*)
 
 // CHECK-MACOSX-FRAGILE-MINGW-DWARF: personality i8* bitcast (i32 (...)* @__gcc_personality_v0 to i8*)
 // CHECK-MACOSX-FRAGILE-MINGW-SEH: personality i8* bitcast (i32 (...)* @__gcc_personality_seh0 to i8*)
Index: test/CodeGenObjCXX/personality.mm
=

[PATCH] D47988: [CodeGen] Emit MSVC funclet IR for Obj-C exceptions

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai created this revision.
smeenai added reviewers: DHowett-MSFT, compnerd, majnemer, rjmccall, rnk.

We're implementing funclet-compatible code generation for Obj-C
exceptions when using the MSVC ABI. The idea is that the Obj-C runtime
will wrap Obj-C exceptions inside C++ exceptions, which allows for
interoperability with C++ exceptions (for Obj-C++) and zero-cost
exceptions. This is the approach taken by e.g. WinObjC, and I believe it
to be the best approach for Obj-C exceptions in the MSVC ABI.

This change implements emitting the actual funclet-compatible IR. The
generic exceptions codegen already takes care of emitting the proper
catch dispatch structures, but we need to ensure proper handling of
catch parameters and scoping (emitting the catchret). Finally blocks are
handled quite differently from Itanium; they're expected to be outlined
by the frontend, which limits some control flow possibilities but also
greatly simplifies their codegen. See r334251 for further discussion of
why frontend outlining is used.

Worked on with Saleem Abdulrasool .


Repository:
  rC Clang

https://reviews.llvm.org/D47988

Files:
  lib/CodeGen/CGCXXABI.h
  lib/CodeGen/CGException.cpp
  lib/CodeGen/CGObjCGNU.cpp
  lib/CodeGen/CGObjCMac.cpp
  lib/CodeGen/CGObjCRuntime.cpp
  lib/CodeGen/CGStmt.cpp
  lib/CodeGen/CodeGenFunction.h
  lib/CodeGen/MicrosoftCXXABI.cpp
  test/CodeGenObjC/catch-lexical-block.m
  test/CodeGenObjC/exceptions-msvc.m

Index: test/CodeGenObjC/exceptions-msvc.m
===
--- test/CodeGenObjC/exceptions-msvc.m
+++ test/CodeGenObjC/exceptions-msvc.m
@@ -1,7 +1,7 @@
-// RUN: %clang_cc1 -triple i686--windows-msvc -fobjc-runtime=ios-6.0 -fdeclspec -fexceptions -fobjc-exceptions -emit-llvm -o - %s | FileCheck -check-prefixes=CHECK,X86 %s
-// RUN: %clang_cc1 -triple i686--windows-msvc -fobjc-runtime=ios-6.0 -fobjc-arc -fdeclspec -fexceptions -fobjc-exceptions -emit-llvm -o - %s | FileCheck -check-prefixes=CHECK,X86 %s
-// RUN: %clang_cc1 -triple x86_64--windows-msvc -fobjc-runtime=ios-6.0 -fdeclspec -fexceptions -fobjc-exceptions -emit-llvm -o - %s | FileCheck -check-prefixes=CHECK,X64 %s
-// RUN: %clang_cc1 -triple x86_64--windows-msvc -fobjc-runtime=ios-6.0 -fobjc-arc -fdeclspec -fexceptions -fobjc-exceptions -emit-llvm -o - %s | FileCheck -check-prefixes=CHECK,X64 %s
+// RUN: %clang_cc1 -triple i686--windows-msvc -fobjc-runtime=ios-6.0 -fdeclspec -fexceptions -fobjc-exceptions -emit-llvm -o - %s | FileCheck -check-prefixes=CHECK,X86 --enable-var-scope %s
+// RUN: %clang_cc1 -triple i686--windows-msvc -fobjc-runtime=ios-6.0 -fobjc-arc -fdeclspec -fexceptions -fobjc-exceptions -emit-llvm -o - %s | FileCheck -check-prefixes=CHECK,X86,ARC --enable-var-scope %s
+// RUN: %clang_cc1 -triple x86_64--windows-msvc -fobjc-runtime=ios-6.0 -fdeclspec -fexceptions -fobjc-exceptions -emit-llvm -o - %s | FileCheck -check-prefixes=CHECK,X64 --enable-var-scope %s
+// RUN: %clang_cc1 -triple x86_64--windows-msvc -fobjc-runtime=ios-6.0 -fobjc-arc -fdeclspec -fexceptions -fobjc-exceptions -emit-llvm -o - %s | FileCheck -check-prefixes=CHECK,X64,ARC --enable-var-scope %s
 
 #if __has_feature(objc_arc)
 #define WEAK __weak
@@ -67,8 +67,9 @@
 @protocol P;
 
 void f(void);
+void __declspec(nothrow) g(void);
 
-void g() {
+void generate_ehtypes() {
   @try {
 f();
   } @catch (I *) {
@@ -79,3 +80,393 @@
   } @catch (id) {
   }
 }
+
+void basic_try_catch_1() {
+  @try {
+f();
+  } @catch (...) {
+g();
+  }
+}
+
+// CHECK-LABEL: define {{.*}}void @basic_try_catch_1(){{.*}} {
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:invoke void @f()
+// CHECK-NEXT:to label %[[INVOKECONT:[^ ]+]] unwind label %[[DISPATCH:[^ ]+]]
+// CHECK:   [[DISPATCH]]:
+// CHECK-NEXT:%[[CATCHSWITCH:[^ ]+]] = catchswitch within none [label %[[CATCH:[^ ]+]]] unwind to caller
+// CHECK:   [[INVOKECONT]]:
+// CHECK-NEXT:br label %[[EHCONT:[^ ]+]]
+// CHECK:   [[EHCONT]]:
+// CHECK-NEXT:ret void
+// CHECK:   [[CATCH]]:
+// CHECK-NEXT:%[[CATCHPAD:[^ ]+]] = catchpad within %[[CATCHSWITCH]] [i8* null, i32 64, i8* null]
+// CHECK-NEXT:call void @g(){{.*}} [ "funclet"(token %[[CATCHPAD]]) ]
+// CHECK-NEXT:catchret from %[[CATCHPAD]] to label %[[CATCHRETDEST:[^ ]+]]
+// CHECK:   [[CATCHRETDEST]]:
+// CHECK-NEXT:br label %[[EHCONT]]
+// CHECK-NEXT:  }
+
+void basic_try_catch_2() {
+  @try {
+f();
+  } @catch (id) {
+g();
+  }
+}
+
+// CHECK-LABEL: define {{.*}}void @basic_try_catch_2(){{.*}} {
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:invoke void @f()
+// CHECK-NEXT:to label %[[INVOKECONT:[^ ]+]] unwind label %[[DISPATCH:[^ ]+]]
+// CHECK:   [[DISPATCH]]:
+// CHECK-NEXT:%[[CATCHSWITCH:[^ ]+]] = catchswitch within none [label %[[CATCH:[^ ]+]]] unwind to caller
+// CHECK:   [[INVOKECONT]]:
+// CHECK-NEXT:br label %[[EHCONT:[^ ]+]]
+// CHECK:   [[EHCONT]]:
+// CHECK-NEXT:ret void
+// CHECK:   [[CATCH

[PATCH] D47988: [CodeGen] Emit MSVC funclet IR for Obj-C exceptions

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai added a comment.

@rnk remember how I was asking you about inlining into catchpads on IRC a few 
days back? It was in relation to this change.

If I have a file `finally1.m`:

  void f(void);
  void g() {
@try {
  f();
} @finally {
  f();
}
  }

and compile it with:

  clang -cc1 -triple i686-windows-msvc -fobjc-runtime=ios-6.0 -fexceptions 
-fobjc-exceptions -Os -emit-llvm -o - finally1.m

the @finally calls out to the captured statement instead of inlining it:

  finally.catchall: ; preds = %catch.dispatch
%1 = catchpad within %0 [i8* null, i32 64, i8* null]
call fastcc void @__captured_stmt() [ "funclet"(token %1) ]
call void @_CxxThrowException(i8* null, %eh.ThrowInfo* null) #3 [ 
"funclet"(token %1) ]
unreachable

If I add an outer try-catch scope, as in `finally2.m`:

  void f(void);
  void g() {
@try {
  @try {
f();
  } @finally {
f();
  }
} @catch (...) {
}
  }

and run the same compilation command:

  clang -cc1 -triple i686-windows-msvc -fobjc-runtime=ios-6.0 -fexceptions 
-fobjc-exceptions -Os -emit-llvm -o - finally2.m

the @finally inlines the captured statement:

  finally.catchall: ; preds = %catch.dispatch
%2 = catchpad within %0 [i8* null, i32 64, i8* null]
invoke void @f() #2 [ "funclet"(token %2) ]
to label %invoke.cont1 unwind label %catch.dispatch4
  
  invoke.cont1: ; preds = %finally.catchall
invoke void @_CxxThrowException(i8* null, %eh.ThrowInfo* null) #3 [ 
"funclet"(token %2) ]
to label %unreachable unwind label %catch.dispatch4

Any idea why we would see inlining in one case and not the other? i686 vs. 
x86-64 doesn't make any difference, and neither does -Os vs. -O1 vs. -O2.


Repository:
  rC Clang

https://reviews.llvm.org/D47988



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D47233: [CodeGen] Emit MSVC RTTI for Obj-C EH types

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai added a comment.

Wrapping an Objective-C exception inside a C++ exception means dynamically 
constructing a C++ exception object and traversing the class hierarchy of the 
thrown Obj-C object to populate the catchable types array of the C++ exception. 
Microsoft's C++ runtime will perform the appropriate catch type comparisons, 
and this patch makes the compiler emit the right typeinfos into the exception 
handling tables for all of that to work. 
https://github.com/Microsoft/libobjc2/blob/f2e4c5ac4b3ac17f413a38bbc7ee1242f9efd0f7/msvc/eh_winobjc.cc#L116
 is how WinObjC does this wrapping, for example.

Essentially, with this patch, `@catch (I *)` in Obj-C ends up generating the 
same exception handling table as `catch (struct I *)` in C++ would. If you're 
throwing an `I *` (or any derived class), the runtime will generate an 
exception object which is catchable by this handler (the catchable types array 
for that exception object will contain the appropriate typeinfo). Successive 
catch clauses don't need any special handling; they work the same way as they 
would in C++. The runtime is generating that exception object based on a 
dynamic traversal of the class hierarchy, so I think Obj-C's dynamic semantics 
should be respected.


Repository:
  rC Clang

https://reviews.llvm.org/D47233



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D47233: [CodeGen] Emit MSVC RTTI for Obj-C EH types

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai added a comment.

In https://reviews.llvm.org/D47233#1129810, @DHowett-MSFT wrote:

> In https://reviews.llvm.org/D47233#1129207, @rjmccall wrote:
>
> > In https://reviews.llvm.org/D47233#1129110, @smeenai wrote:
> >
> > > WinObjC does this wrapping, for example.
> >
> >
> > I see.  The idea of creating the type descriptors and mangled names ad-hoc 
> > for the catchable-types array is clever, and it's nice that the ABI is 
> > defined in a way that makes that work.  (Expensive, but hey, it's the 
> > exceptions path.)
>
>
> We ran into some critical issues with this approach on x64. The pointers in 
> the exception record are supposed to be image-relative instead of absolute, 
> so I tried to make them absolute to libobjc2's load address, but I never 
> quite solved it.
>
> A slightly better-documented and cleaner version of the code you linked is 
> here 
> .


We solved the x64 issue by just calling RaiseException directly and supplying a 
fake ImageBase. It's a bit kludgy, but it works well. (_CxxThrowException's 
source is included with MSVC, so we just looked at how that was calling 
RaiseException and altered it accordingly.)


Repository:
  rC Clang

https://reviews.llvm.org/D47233



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D47233: [CodeGen] Emit MSVC RTTI for Obj-C EH types

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai added a comment.

Ping.


Repository:
  rC Clang

https://reviews.llvm.org/D47233



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D47988: [CodeGen] Emit MSVC funclet IR for Obj-C exceptions

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai added a comment.

Ping.


Repository:
  rC Clang

https://reviews.llvm.org/D47988



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D48356: [libcxx] [CMake] Convert paths to the right form in standalone builds on Windows

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai accepted this revision.
smeenai added a comment.
This revision is now accepted and ready to land.

Looks good with the quotes added.




Comment at: cmake/Modules/HandleCompilerRT.cmake:17
   string(STRIP "${LIBRARY_FILE}" LIBRARY_FILE)
+  file(TO_CMAKE_PATH ${LIBRARY_FILE} LIBRARY_FILE)
   string(REPLACE "builtins" "${name}" LIBRARY_FILE "${LIBRARY_FILE}")

Nit: cmake recommends always putting quotes around the path argument to ensure 
it's treated as a single argument, i.e.

  file(TO_CMAKE_PATH "${LIBRARY_FILE}" LIBRARY_FILE)

That needs to happen in all other uses as well.



Comment at: cmake/Modules/HandleOutOfTreeLLVM.cmake:52
 else()
-  set(LLVM_CMAKE_PATH
-  "${LLVM_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX}/cmake/llvm")
+  file(TO_CMAKE_PATH ${LLVM_BINARY_DIR} LLVM_BINARY_DIR_CMAKE_STYLE)
+  set(LLVM_CMAKE_PATH 
"${LLVM_BINARY_DIR_CMAKE_STYLE}/lib${LLVM_LIBDIR_SUFFIX}/cmake/llvm")

Is there ever a chance LLVM_BINARY_DIR will have backslashes, or are you just 
being extra careful (or going for consistency)?


Repository:
  rCXX libc++

https://reviews.llvm.org/D48356



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D48355: [libcxxabi] [CMake] Convert paths to the right form in standalone builds on Windows

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai accepted this revision.
smeenai added a comment.
This revision is now accepted and ready to land.

LGTM with the same comments as https://reviews.llvm.org/D48356 (add quotes, and 
is the translation for LLVM_BINARY_DIR necessary?)


Repository:
  rCXXA libc++abi

https://reviews.llvm.org/D48355



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D48353: [libunwind] [CMake] Convert paths to the right form in standalone builds on Windows

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai accepted this revision.
smeenai added a comment.
This revision is now accepted and ready to land.

LGTM with the same comments as https://reviews.llvm.org/D48356 (add quotes, and 
is the translation for LLVM_BINARY_DIR necessary?)


Repository:
  rUNW libunwind

https://reviews.llvm.org/D48353



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D48356: [libcxx] [CMake] Convert paths to the right form in standalone builds on Windows

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai added inline comments.



Comment at: cmake/Modules/HandleOutOfTreeLLVM.cmake:52
 else()
-  set(LLVM_CMAKE_PATH
-  "${LLVM_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX}/cmake/llvm")
+  file(TO_CMAKE_PATH ${LLVM_BINARY_DIR} LLVM_BINARY_DIR_CMAKE_STYLE)
+  set(LLVM_CMAKE_PATH 
"${LLVM_BINARY_DIR_CMAKE_STYLE}/lib${LLVM_LIBDIR_SUFFIX}/cmake/llvm")

mstorsjo wrote:
> smeenai wrote:
> > Is there ever a chance LLVM_BINARY_DIR will have backslashes, or are you 
> > just being extra careful (or going for consistency)?
> I'm mostly just going for consistency and copy+paste; this path identically 
> matches a part from compiler-rt/cmake/Modules/CompilerRTUtils.cmake - and 
> that part actually seems to have been added intentionally to fix some case: 
> https://reviews.llvm.org/rL203789
Fair enough; sounds good to me.


Repository:
  rCXX libc++

https://reviews.llvm.org/D48356



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D47988: [CodeGen] Emit MSVC funclet IR for Obj-C exceptions

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai added inline comments.



Comment at: lib/CodeGen/CGCXXABI.h:248
+llvm_unreachable("Only needed for the Microsoft ABI");
+  }
 

rjmccall wrote:
> Should you just generalize the existing method to only take a VarDecl* so it 
> can be used for either kind of catch?
The Itanium version of emitBeginCatch actually uses the statement for location 
info (it calls `getLocStart` on it). I suppose I could generalize the existing 
method to take both a VarDecl* and a SourceLocation though.


Repository:
  rC Clang

https://reviews.llvm.org/D47988



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D47233: [CodeGen] Emit MSVC RTTI for Obj-C EH types

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai added inline comments.



Comment at: lib/CodeGen/CGObjCMac.cpp:7457-7460
 CGObjCNonFragileABIMac::GetEHType(QualType T) {
   // There's a particular fixed type info for 'id'.
   if (T->isObjCIdType() || T->isObjCQualifiedIdType()) {
+if (CGM.getTriple().isWindowsMSVCEnvironment())

rjmccall wrote:
> rnk wrote:
> > @rjmccall how should this be organized in the long run? At this point, the 
> > naming seems totally wrong. Is the non-fragile ABI sort of the canonical 
> > way forward for Obj-C, i.e. it's what a new platform would want to use to 
> > best stay in sync with the future of obj-c?
> For Darwin, yes, absolutely.
> 
> I think this method should probably just completely delegate to the 
> `CGCXXABI` using a new `getAddrOfObjCRTTIDescriptor` method.
To be clear, you'd want the entirety of the EHType emission logic to be shifted 
to CGCXXABI? I think that would make sense, and I can look into it.


Repository:
  rC Clang

https://reviews.llvm.org/D47233



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D52674: [AST] Add Obj-C discriminator to MS ABI RTTI

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai added a comment.

@rjmccall I prototyped the ForRTTI parameter approach in 
https://reviews.llvm.org/D53546. It could definitely be cleaned up a bit, but 
it demonstrates the problems I saw with the added parameter. Namely, 
`mangleType(QualType, SourceRange, QualifierMangleMode)` has a bunch of 
additional logic which is needed for correctness, so we need to thread the 
parameter through the entire chain, and the only way I could think of doing 
that without adding the parameter to every single `mangleType` overload was to 
have an additional switch to dispatch to the overloads with the added ForRTTI 
parameter, which is pretty ugly.

As I see it, there are a few ways to proceed here:

- The approach in https://reviews.llvm.org/D53546 (cleaned up a bit). I think 
it's pretty ugly, but you may have suggestions on how to do it better.
- In the `mangleType` overload for `ObjCObjectPointerType`, skipping the 
generic `mangleType` dispatch and going directly to either the `ObjCObjectType` 
or `ObjCInterfaceType` overloads. That avoids the ugliness in the generic 
`mangleType`, but it also requires us to duplicate some logic from it in the 
`ObjCObjectPointerType` overload, which doesn't seem great either.
- Maintaining `ForRTTI` state in the mangler instead of threading a parameter 
through (I'm generally not a fan of state like that, but it might be cleaner 
than the threading in this case?)
- Just sticking with what I'm doing in this patch.

What do you think?


Repository:
  rC Clang

https://reviews.llvm.org/D52674



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D52674: [AST] Add Obj-C discriminator to MS ABI RTTI

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai added a comment.

Ping @rjmccall. Let me know if the approach in https://reviews.llvm.org/D53546 
is what you'd been envisioning, or if I'm just doing something completely 
brain-dead :)


Repository:
  rC Clang

https://reviews.llvm.org/D52674



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D56816: [ObjC] Follow-up r350768 and allow the use of unavailable methods that are declared in a parent class from within the @implementation context

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai added a comment.

My understanding is that rL349841  
accidentally started producing some spurious warnings/errors, rL350768 
 fixed some instances, and this change fixes 
more instances. Given that the first two changes are already in the 8.0 branch, 
should this be cherry-picked to 8.0 as well once it lands?


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56816/new/

https://reviews.llvm.org/D56816



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D56652: [CMake][Fuchsia] Synchronize first and second stage builds

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai added inline comments.



Comment at: cfe/trunk/cmake/caches/Fuchsia-stage2.cmake:29
 
-set(LLVM_ENABLE_ASSERTIONS ON CACHE BOOL "")
 set(CMAKE_BUILD_TYPE RelWithDebInfo CACHE STRING "")

Out of curiosity, how come you decided to disable assertions? 
https://reviews.llvm.org/D41471 said "Release+Asserts is fast enough. No need 
to let insanity through.", and I do think assertions end up catching a bunch of 
issues, so I was wondering if the build time penalty became too high.


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56652/new/

https://reviews.llvm.org/D56652



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D57330: Adjust documentation for git migration.

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai accepted this revision.
smeenai added a comment.
This revision is now accepted and ready to land.

The amount of duplicated and out-of-date documentation makes me sad, but this 
is an awesome effort to clean that up.




Comment at: 
lldb/packages/Python/lldbsuite/test/functionalities/command_source/TestCommandSource.py:4
-
-See also http://llvm.org/viewvc/llvm-project?view=rev&revision=109673.
 """

Would you want to link to the corresponding GitHub commit?



Comment at: 
lldb/packages/Python/lldbsuite/test/lang/objc/objc-optimized/TestObjcOptimized.py:4
 
-http://llvm.org/viewvc/llvm-project?rev=126973&view=rev
 Fixed a bug in the expression parser where the 'this'

Same here.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D57330/new/

https://reviews.llvm.org/D57330



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D57330: Adjust documentation for git migration.

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai added a comment.

In D57330#1375913 , @mehdi_amini wrote:

> In D57330#1375096 , @labath wrote:
>
> > This is not an full out-of-source build, since the build folder is still a 
> > subfolder of the repo root
>
>
> My definition of what qualify an "out-of-source" build is that the build 
> process won't touch anything outside of the build directory: i.e. the build 
> directory itself is hermetic, self-contained, and can be destroyed without 
> impacting anything else.
>  (I agree with you that polluting `git status` is annoying, and personally I 
> usually have my build directories in parallel with the repo).


You can avoid the `git status` pollution by adding the build directory to 
`.git/info/exclude`.


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D57330/new/

https://reviews.llvm.org/D57330



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D57330: Adjust documentation for git migration.

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai added a comment.

In D57330#1376069 , @mehdi_amini wrote:

> > You can avoid the git status pollution by adding the build directory to 
> > .git/info/exclude.
>
> Good to know! Should we include this in the doc?


I can put that change up fore review. It probably makes most sense to add it to 
www/get_started.html? There's lots of different places which document building, 
but that seems like the canonical one.


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D57330/new/

https://reviews.llvm.org/D57330



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D52674: [AST] Add Obj-C discriminator to MS ABI RTTI

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai added a comment.

In https://reviews.llvm.org/D52674#1281747, @rjmccall wrote:

> In https://reviews.llvm.org/D52674#1271814, @smeenai wrote:
>
> > @rjmccall I prototyped the ForRTTI parameter approach in 
> > https://reviews.llvm.org/D53546. It could definitely be cleaned up a bit, 
> > but it demonstrates the problems I saw with the added parameter. Namely, 
> > `mangleType(QualType, SourceRange, QualifierMangleMode)` has a bunch of 
> > additional logic which is needed for correctness, so we need to thread the 
> > parameter through the entire chain, and the only way I could think of doing 
> > that without adding the parameter to every single `mangleType` overload was 
> > to have an additional switch to dispatch to the overloads with the added 
> > ForRTTI parameter, which is pretty ugly.
> >
> > As I see it, there are a few ways to proceed here:
> >
> > - The approach in https://reviews.llvm.org/D53546 (cleaned up a bit). I 
> > think it's pretty ugly, but you may have suggestions on how to do it better.
> > - In the `mangleType` overload for `ObjCObjectPointerType`, skipping the 
> > generic `mangleType` dispatch and going directly to either the 
> > `ObjCObjectType` or `ObjCInterfaceType` overloads. That avoids the ugliness 
> > in the generic `mangleType`, but it also requires us to duplicate some 
> > logic from it in the `ObjCObjectPointerType` overload, which doesn't seem 
> > great either.
> > - Maintaining `ForRTTI` state in the mangler instead of threading a 
> > parameter through (I'm generally not a fan of state like that, but it might 
> > be cleaner than the threading in this case?)
> > - Just sticking with what I'm doing in this patch.
> >
> >   What do you think?
>
>
> Sorry for the delay.  I think duplicating the dispatch logic for 
> `ObjCObjectPointerType` is probably the best approach; the pointee type will 
> always an `ObjCObjectType` of some sort, and there are only two kinds of 
> those.


To be clear, we would need to duplicate (or factor out into a common function) 
some mangling logic as well, because e.g. adding the `E`

In https://reviews.llvm.org/D52674#1281747, @rjmccall wrote:

> In https://reviews.llvm.org/D52674#1271814, @smeenai wrote:
>
> > @rjmccall I prototyped the ForRTTI parameter approach in 
> > https://reviews.llvm.org/D53546. It could definitely be cleaned up a bit, 
> > but it demonstrates the problems I saw with the added parameter. Namely, 
> > `mangleType(QualType, SourceRange, QualifierMangleMode)` has a bunch of 
> > additional logic which is needed for correctness, so we need to thread the 
> > parameter through the entire chain, and the only way I could think of doing 
> > that without adding the parameter to every single `mangleType` overload was 
> > to have an additional switch to dispatch to the overloads with the added 
> > ForRTTI parameter, which is pretty ugly.
> >
> > As I see it, there are a few ways to proceed here:
> >
> > - The approach in https://reviews.llvm.org/D53546 (cleaned up a bit). I 
> > think it's pretty ugly, but you may have suggestions on how to do it better.
> > - In the `mangleType` overload for `ObjCObjectPointerType`, skipping the 
> > generic `mangleType` dispatch and going directly to either the 
> > `ObjCObjectType` or `ObjCInterfaceType` overloads. That avoids the ugliness 
> > in the generic `mangleType`, but it also requires us to duplicate some 
> > logic from it in the `ObjCObjectPointerType` overload, which doesn't seem 
> > great either.
> > - Maintaining `ForRTTI` state in the mangler instead of threading a 
> > parameter through (I'm generally not a fan of state like that, but it might 
> > be cleaner than the threading in this case?)
> > - Just sticking with what I'm doing in this patch.
> >
> >   What do you think?
>
>
> Sorry for the delay.  I think duplicating the dispatch logic for 
> `ObjCObjectPointerType` is probably the best approach; the pointee type will 
> always an `ObjCObjectType` of some sort, and there are only two kinds of 
> those.


Sorry, I'm still not sure how this will work.

Duplicating the dispatch logic for `ObjCObjectPointerType` ends up looking like 
https://reviews.llvm.org/P8114, which is fine. However, when we're actually 
mangling RTTI or RTTI names, we're still going through the main 
`mangleType(QualType, SourceRange, QualifierMangleMode)` overload, which still 
requires us to thread `ForRTTI` through that function, which still requires us 
to duplicate the switch in that function (to handle the `ForRTTI` case, since 
the other switch is generated via TypeNodes.def and not easily modifiable), 
which is the main ugliness in my opinion. Do you also want me to add special 
dispatching to `mangleCXXRTTI` and `mangleCXXRTTIName` to just call the 
`ObjCObjectPointerType` function directly when they're dealing with that type? 
That's certainly doable, but at that point just keeping some state around in 
the demangler starts to feel cleaner, at least to me.


Repository:
  rC