Commit Graph

6 Commits

Author SHA1 Message Date
Fangrui Song 74742147ee [test] Change cc1 -fvisibility to -fvisibility= 2022-09-02 12:36:44 -07:00
Nikita Popov 532dc62b90 [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
2022-04-07 12:09:47 +02:00
Fangrui Song 6b3351792c [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.
2020-12-30 20:52:01 -08:00
Ahmed Bougacha 5d0199a218 [CodeGen] Compute the objc EH vtable address point using inbounds GEP.
The object is provided by the objc runtime and is never visible in the
module itself, but even so, the address point we compute points into it,
and "+16" is guaranteed not to overflow.

This matches the c++ vtable IRGen.

Note that I'm not entirely convinced the 'i8*' type is correct here: at
the IR level, we're accessing memory that's outside the global object.
But we don't control the allocation, so it's not obviously wrong either.
But either way, this is only in a global initializer, so I don't think
it's going to be mucked with.  Filed PR35352 to discuss that.

llvm-svn: 318545
2017-11-17 19:46:47 +00:00
David Blaikie bdf40a62a7 Test case updates for explicit type parameter to the gep operator
llvm-svn: 232187
2015-03-13 18:21:46 +00:00
John McCall a496098bb8 Use the actual class visibility for the ObjC EHTYPE global,
not the global visibility mode.

Noticed by inspection.

llvm-svn: 175479
2013-02-19 01:57:29 +00:00