[OpaquePtrs][Clang] Add -no-opaque-pointers to tests (NFC)

This adds -no-opaque-pointers to clang tests whose output will
change when opaque pointers are enabled by default. This is
intended to be p

[OpaquePtrs][Clang] Add -no-opaque-pointers to tests (NFC)

This adds -no-opaque-pointers to clang tests whose output will
change when opaque pointers are enabled by default. This is
intended to be part of the migration approach described in
https://discourse.llvm.org/t/enabling-opaque-pointers-by-default/61322/9.

The patch has been produced by replacing %clang_cc1 with
%clang_cc1 -no-opaque-pointers for tests that fail with opaque
pointers enabled. Worth noting that this doesn't cover all tests,
there's a remaining ~40 tests not using %clang_cc1 that will need
a followup change.

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

show more ...

Use functions with prototypes when appropriate; NFC

A significant number of our tests in C accidentally use functions
without prototypes. This patch converts the function signatures to have
a protot

Use functions with prototypes when appropriate; NFC

A significant number of our tests in C accidentally use functions
without prototypes. This patch converts the function signatures to have
a prototype for the situations where the test is not specific to K&R C
declarations. e.g.,

void func();

becomes

void func(void);

This is the twelfth batch of tests being updated (the end may be in
sight soon though).

show more ...

[test] Add {{.*}} to make tests immune to dso_local/dso_preemptable/(none) differences

For a definition (of most linkage types), dso_local is set for ELF -fno-pic/-fpie
and COFF, but not for Mach-O.

[test] Add {{.*}} to make tests immune to dso_local/dso_preemptable/(none) differences

For a definition (of most linkage types), dso_local is set for ELF -fno-pic/-fpie
and COFF, but not for Mach-O. This nuance causes unneeded binary format differences.

This patch replaces (function) `define ` with `define{{.*}} `,
(variable/constant/alias) `= ` with `={{.*}} `, or inserts appropriate `{{.*}} `
if there is an explicit linkage.

* Clang will set dso_local for Mach-O, which is currently implied by TargetMachine.cpp. This will make COFF/Mach-O and executable ELF similar.
* Eventually I hope we can make dso_local the textual LLVM IR default (write explicit "dso_preemptable" when applicable) and -fpic ELF will be similar to everything else. This patch helps move toward that goal.

show more ...

[ObjC] Fix encoding of ObjC pointer types that are pointers to typedefs

clang was encoding pointers to typedefs as if they were pointers to
structs because that is apparently what gcc is doing.

For

[ObjC] Fix encoding of ObjC pointer types that are pointers to typedefs

clang was encoding pointers to typedefs as if they were pointers to
structs because that is apparently what gcc is doing.

For example:

```
@class Class1;

typedef NSArray<Class1 *> MyArray;

void foo1(void) {
const char *s0 = @encode(MyArray *); // "^{NSArray=#}"
const char *s1 = @encode(NSArray<Class1 *> *); // "@"
}
```

This commit removes the code that was there to make clang compatible
with gcc and make clang emit the correct encoding for ObjC pointers,
which is "@".

rdar://problem/50563529

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

llvm-svn: 362034

show more ...

[Sema] Make string literal init an rvalue.

This allows substantially simplifying the expression evaluation code,
because we don't have to special-case lvalues which are actually string
literal initi

[Sema] Make string literal init an rvalue.

This allows substantially simplifying the expression evaluation code,
because we don't have to special-case lvalues which are actually string
literal initialization.

This currently throws away an optimization where we would avoid creating
an array APValue for string literal initialization. If we really want
to optimize this case, we should fix APValue so it can store simple
arrays more efficiently, like llvm::ConstantDataArray. This shouldn't
affect the memory usage for other string literals. (Not sure if this is
a blocker; I don't think string literal init is common enough for this
to be a serious issue, but I could be wrong.)

The change to test/CodeGenObjC/encode-test.m is a weird side-effect of
these changes: we currently don't constant-evaluate arrays in C, so the
strlen call shouldn't be folded, but lvalue string init managed to get
around that check. I this this is fine.

Fixes https://bugs.llvm.org/show_bug.cgi?id=40430 .

llvm-svn: 353569

show more ...

Handle ObjCEncodeExpr in extractStringLiteralCharacter.

This fixes an assertion failure that occurs later in the function when
an ObjCEncodeExpr is cast to StringLiteral.

rdar://problem/30111207

l

Handle ObjCEncodeExpr in extractStringLiteralCharacter.

This fixes an assertion failure that occurs later in the function when
an ObjCEncodeExpr is cast to StringLiteral.

rdar://problem/30111207

llvm-svn: 293596

show more ...

Switch CGObjCMac to use ConstantInitBuilder. Whew.

Not strictly NFC because I did change the order of emission of
some global constants, but it shouldn't make any difference.

llvm-svn: 288229

CodeGen: mark ObjC cstring literals as unnamed_addr

These are all emitted into a section with a cstring_literal attribute. The
attribute permits the linker to coalesce the string contents. The add

CodeGen: mark ObjC cstring literals as unnamed_addr

These are all emitted into a section with a cstring_literal attribute. The
attribute permits the linker to coalesce the string contents. The address of
the strings are not important.

llvm-svn: 281855

show more ...

CodeGen: mark ObjC cstring literals as constant

These strings are constants, mark them as such. This doesn't matter too much in
practice on MachO since the constants are placed into a special secti

CodeGen: mark ObjC cstring literals as constant

These strings are constants, mark them as such. This doesn't matter too much in
practice on MachO since the constants are placed into a special section and not
referred to directly.

llvm-svn: 281854

show more ...

Add test coverage for @encode(SEL); completely untested until now.

llvm-svn: 247717

Changed renaming of local symbols by inserting a dot vefore the numeric suffix
details in http://reviews.llvm.org/D9483
goes with llvm checkin r237150

llvm-svn: 237151

Don't manually insert L prefixes.

Simply marking the symbol private conveys the desire to hide them to LLVM.

llvm-svn: 221451

Use private linkage for globals we already name with \01L and \01l.

In llvm the only semantic difference between internal and private is that llvm
tries to hide private globals my mangling them with

Use private linkage for globals we already name with \01L and \01l.

In llvm the only semantic difference between internal and private is that llvm
tries to hide private globals my mangling them with a private prefix. Since
the globals changed by this patch already had the magic don't mangle marker,
there should be no change in the generated assembly.

A followup patch should then be able to drop the \01L and \01l prefixes and let
llvm mangle as appropriate.

llvm-svn: 202419

show more ...

Objective-C. provide legacy encoding of *id and *Class types
instead of crashing. // rdar://15824769.

llvm-svn: 200338

Objective-C encoding. Fixes up encodeing for
arrays of empty structs. // rdar://14053082
(also pr13062).

llvm-svn: 183234

Robustify the @encode code and add support for _Atomic.

Fixes PR14628.

llvm-svn: 170639

Restructure how the driver communicates information about the
target Objective-C runtime down to the frontend: break this
down into a single target runtime kind and version, and compute
all the rele

Restructure how the driver communicates information about the
target Objective-C runtime down to the frontend: break this
down into a single target runtime kind and version, and compute
all the relevant information from that. This makes it
relatively painless to add support for new runtimes to the
compiler. Make the new -cc1 flag, -fobjc-runtime=blah-x.y.z,
available at the driver level as a better and more general
alternative to -fgnu-runtime and -fnext-runtime. This new
concept of an Objective-C runtime also encompasses what we
were previously separating out as the "Objective-C ABI", so
fragile vs. non-fragile runtimes are now really modelled as
different kinds of runtime, paving the way for better overall
differentiation.

As a sort of special case, continue to accept the -cc1 flag
-fobjc-runtime-has-weak, as a sop to PLCompatibilityWeak.

I won't go so far as to say "no functionality change", even
ignoring the new driver flag, but subtle changes in driver
semantics are almost certainly not intended.

llvm-svn: 158793

show more ...

Make -fobjc-nonfragile-abi the -cc1 default, since it's the
increasingly prevailing case to the point that new features
like ARC don't even support the fragile ABI anymore.

This required a little bi

Make -fobjc-nonfragile-abi the -cc1 default, since it's the
increasingly prevailing case to the point that new features
like ARC don't even support the fragile ABI anymore.

This required a little bit of reshuffling with exceptions
because a check was assuming that ObjCNonFragileABI was
only being set in ObjC mode, and that's actually a bit
obnoxious to do.

Most, though, it involved a perl script to translate a ton
of test cases.

Mostly no functionality change for driver users, although
there are corner cases with disabling language-specific
exceptions that we should handle more correctly now.

llvm-svn: 140957

show more ...

For the purpose of @encode'ing, accept 'void' type
(even though it is incomplete type) because gcc
says so. // rdar://9622422

llvm-svn: 133208

Reapply the commits that r131401 reverted and add a fix for PR9927.

llvm-svn: 131446

Revert 131377, 131369 and 131365.
131365 caused PR9927.

llvm-svn: 131401

Fix generation of obj-c @encoding for members with zero size.
Also follow gcc in that arrays of elements with zero size are encoded as arrays with zero elements.

llvm-svn: 131369

Create proper Objective-C @encoding for C++ classes; fixes rdar://9357400.

Go through and expand the members of bases into the encoding string (and encode the VTable as well).
Unlike gcc which expan

Create proper Objective-C @encoding for C++ classes; fixes rdar://9357400.

Go through and expand the members of bases into the encoding string (and encode the VTable as well).
Unlike gcc which expands virtual bases as many times as they appear in the
hierarchy, clang will only expand them once at the end, to reflect the actual layout.

Note that there doesn't seem to be a way to indicate in the encoding that
packing/alignment of members is different that normal, in which case
the encoding will be out-of-sync with the real layout.
If the runtime switches to just consider the size of types without
taking into account alignment, we could easily make padding explicit in the
encoding (e.g. using arrays of chars). The encoding strings would be
longer then though.

Also encode a flexible array member as array of 0 size, like gcc, not as a pointer.

llvm-svn: 131365

show more ...

IRgen/Obj-C: Fix encoding of "long double".
- The mind boggles.

llvm-svn: 116226

Merge encode-test-1.m into encode-test.m

llvm-svn: 116225