Commit Graph

20 Commits

Author SHA1 Message Date
Akira Hatanaka 8e57b07f66 Distinguish `__block` variables that are captured by escaping blocks
from those that aren't.

This patch changes the way __block variables that aren't captured by
escaping blocks are handled:

- Since non-escaping blocks on the stack never get copied to the heap
  (see https://reviews.llvm.org/D49303), Sema shouldn't error out when
  the type of a non-escaping __block variable doesn't have an accessible
  copy constructor.

- IRGen doesn't have to use the specialized byref structure (see
  https://clang.llvm.org/docs/Block-ABI-Apple.html#id8) for a
  non-escaping __block variable anymore. Instead IRGen can emit the
  variable as a normal variable and copy the reference to the block
  literal. Byref copy/dispose helpers aren't needed either.

This reapplies r343518 after fixing a use-after-free bug in function
Sema::ActOnBlockStmtExpr where the BlockScopeInfo was dereferenced after
it was popped and deleted.

rdar://problem/39352313

Differential Revision: https://reviews.llvm.org/D51564

llvm-svn: 343542
2018-10-01 21:51:28 +00:00
Akira Hatanaka 3197484701 Revert r343518.
Bots are still failing.

http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/24420
http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win/builds/12958

llvm-svn: 343531
2018-10-01 20:29:34 +00:00
Akira Hatanaka 2bf09ccfd5 Distinguish `__block` variables that are captured by escaping blocks
from those that aren't.

This patch changes the way __block variables that aren't captured by
escaping blocks are handled:

- Since non-escaping blocks on the stack never get copied to the heap
  (see https://reviews.llvm.org/D49303), Sema shouldn't error out when
  the type of a non-escaping __block variable doesn't have an accessible
  copy constructor.

- IRGen doesn't have to use the specialized byref structure (see
  https://clang.llvm.org/docs/Block-ABI-Apple.html#id8) for a
  non-escaping __block variable anymore. Instead IRGen can emit the
  variable as a normal variable and copy the reference to the block
  literal. Byref copy/dispose helpers aren't needed either.

This reapplies r341754, which was reverted in r341757 because it broke a
couple of bots. r341754 was calling markEscapingByrefs after the call to
PopFunctionScopeInfo, which caused the popped function scope to be
cleared out when the following code was compiled, for example:

$ cat test.m
struct A {
  id data[10];
};

void foo() {
  __block A v;
  ^{ (void)v; };
}

This commit calls markEscapingByrefs before calling PopFunctionScopeInfo
to prevent that from happening.

rdar://problem/39352313

Differential Revision: https://reviews.llvm.org/D51564

llvm-svn: 343518
2018-10-01 18:50:14 +00:00
Akira Hatanaka 9bd2452708 Revert r341754.
The commit broke a couple of bots:

http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win/builds/12347
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap/builds/7310

llvm-svn: 341757
2018-09-09 05:22:49 +00:00
Akira Hatanaka 2e00b98027 Distinguish `__block` variables that are captured by escaping blocks
from those that aren't.

This patch changes the way __block variables that aren't captured by
escaping blocks are handled:

- Since non-escaping blocks on the stack never get copied to the heap
  (see https://reviews.llvm.org/D49303), Sema shouldn't error out when
  the type of a non-escaping __block variable doesn't have an accessible
  copy constructor.

- IRGen doesn't have to use the specialized byref structure (see
  https://clang.llvm.org/docs/Block-ABI-Apple.html#id8) for a
  non-escaping __block variable anymore. Instead IRGen can emit the
  variable as a normal variable and copy the reference to the block
  literal. Byref copy/dispose helpers aren't needed either.

rdar://problem/39352313

Differential Revision: https://reviews.llvm.org/D51564

llvm-svn: 341754
2018-09-08 20:03:00 +00:00
Chandler Carruth 93786da2cb Make '-disable-llvm-optzns' an alias for '-disable-llvm-passes'.
Much to my surprise, '-disable-llvm-optzns' which I thought was the
magical flag I wanted to get at the raw LLVM IR coming out of Clang
deosn't do that. It still runs some passes over the IR. I don't want
that, I really want the *raw* IR coming out of Clang and I strongly
suspect everyone else using it is in the same camp.

There is actually a flag that does what I want that I didn't know about
called '-disable-llvm-passes'. I suspect many others don't know about it
either. It both does what I want and is much simpler.

This removes the confusing version and makes that spelling of the flag
an alias for '-disable-llvm-passes'. I've also moved everything in Clang
to use the 'passes' spelling as it seems both more accurate (*all* LLVM
passes are disabled, not just optimizations) and much easier to remember
and spell correctly.

This is part of simplifying how Clang drives LLVM to make it cleaner to
wire up to the new pass manager.

Differential Revision: https://reviews.llvm.org/D28047

llvm-svn: 290392
2016-12-23 00:23:01 +00:00
Ben Langmuir f5416740fc Fix predefine for __NSConstantString struct type
Per review feedback the name was wrong and it can be used outside
Objective-C.

Unfortunately, making the internal struct visible broke some ASTMatchers
tests that assumed that the first record decl would be from user code,
rather than a builtin type.  I'm worried that this will also affect
users' code.  So this patch adds a typedef to wrap the internal struct
and only makes the typedef visible to namelookup.  This is sufficient to
allow the ASTReader to merge the decls we need without making the struct
itself visible.

rdar://problem/24425801

llvm-svn: 259734
2016-02-04 00:55:24 +00:00
Quentin Colombet 043406b87f Reapply r259624, it is likely not the commit causing the bot failures.
Original message:
Make CF constant string decl visible to name lookup to fix module errors

The return type of the __builtin___*StringMakeConstantString functions
is a pointer to a struct, so we need that struct to be visible to name
lookup so that we will correctly merge multiple declarations of that
type if they come from different modules.

Incidentally, to make this visible to name lookup we need to rename the
type to __NSConstantString, since the real NSConstantString is an
Objective-C interface type.  This shouldn't affect anyone outside the
compiler since users of the constant string builtins cast the result
immediately to CFStringRef.

Since this struct type is otherwise implicitly created by the AST
context and cannot access namelookup, we make this a predefined type
and initialize it in Sema.

Note: this issue of builtins that refer to types not visible to name
lookup technically also affects other builtins (e.g. objc_msgSendSuper),
but in all other cases the builtin is a library builtin and the issue
goes away if you include the library that defines the types it uses,
unlike for these constant string builtins.

rdar://problem/24425801

llvm-svn: 259721
2016-02-03 22:41:00 +00:00
Quentin Colombet 0cdb86bd38 Revert r259624 - Make CF constant string decl visible to name lookup to fix module errors.
This breaks some internal bots in stage2: clang seg fault.
Looking with Ben to see what is going on.

llvm-svn: 259715
2016-02-03 22:14:53 +00:00
Ben Langmuir 6a34e10514 Make CF constant string decl visible to name lookup to fix module errors
The return type of the __builtin___*StringMakeConstantString functions
is a pointer to a struct, so we need that struct to be visible to name
lookup so that we will correctly merge multiple declarations of that
type if they come from different modules.

Incidentally, to make this visible to name lookup we need to rename the
type to __NSConstantString, since the real NSConstantString is an
Objective-C interface type.  This shouldn't affect anyone outside the
compiler since users of the constant string builtins cast the result
immediately to CFStringRef.

Since this struct type is otherwise implicitly created by the AST
context and cannot access namelookup, we make this a predefined type
and initialize it in Sema.

Note: this issue of builtins that refer to types not visible to name
lookup technically also affects other builtins (e.g. objc_msgSendSuper),
but in all other cases the builtin is a library builtin and the issue
goes away if you include the library that defines the types it uses,
unlike for these constant string builtins.

rdar://problem/24425801

llvm-svn: 259624
2016-02-03 03:26:19 +00:00
David Blaikie cb6b6f7e20 [opaque pointer type] Update test cases now that the type for an invoke is just a function type, not a pointer-to-function type
llvm-svn: 235756
2015-04-24 19:33:25 +00:00
Rafael Espindola ff7cea8c1a Don't pass -O0 to clang_cc1, it is the default.
llvm-svn: 189910
2013-09-04 04:12:25 +00:00
Stephen Lin 4362261b00 CHECK-LABEL-ify some code gen tests to improve diagnostic experience when tests fail.
llvm-svn: 188447
2013-08-15 06:47:53 +00:00
Bill Wendling 19457e282e Update tests so that we don't test for function-only attributes on call sites.
llvm-svn: 175921
2013-02-22 21:12:51 +00:00
Bill Wendling e1c4a1babd Update to use references to attribute groups instead of listing the attributes on the call/invoke instructions.
llvm-svn: 175878
2013-02-22 09:10:20 +00:00
Bill Wendling 985d1c5d15 Add the 'target-cpu' and 'target-features' attributes to functions.
The back-end will use these values to reconfigure code generation for different
features.

llvm-svn: 175308
2013-02-15 21:30:01 +00:00
Dan Gohman 7537838499 Fix this test to work with and without Asserts mode.
llvm-svn: 150713
2012-02-16 18:51:05 +00:00
NAKAMURA Takumi 59b1bc16eb test/CodeGenObjC/arc-no-arc-exceptions.m: Disable it at -Asserts for now.
llvm-svn: 150666
2012-02-16 08:12:12 +00:00
Chad Rosier ffbf9f1406 Fix test for r150648.
llvm-svn: 150650
2012-02-16 01:56:55 +00:00
Dan Gohman 515a60daff Teach clang to add metadata tags to calls and invokes in ObjC with
-fno-objc-arc-exceptions. This will allow the optimizer to perform
optimizations which are only safe under that flag.

This is a part of rdar://10803830.

llvm-svn: 150644
2012-02-16 00:57:37 +00:00