Commit Graph

45 Commits

Author SHA1 Message Date
Fangrui Song dbc96b518b Revert "[CodeGenModule] Assume dso_local for -fpic -fno-semantic-interposition"
This reverts commit 789a46f2d7.

Accidentally committed.
2020-02-03 10:09:39 -08:00
Fangrui Song 789a46f2d7 [CodeGenModule] Assume dso_local for -fpic -fno-semantic-interposition
Summary:
Clang -fpic defaults to -fno-semantic-interposition (GCC -fpic defaults
to -fsemantic-interposition).
Users need to specify -fsemantic-interposition to get semantic
interposition behavior.

Semantic interposition is currently a best-effort feature. There may
still be some cases where it is not handled well.

Reviewers: peter.smith, rnk, serge-sans-paille, sfertile, jfb, jdoerfert

Subscribers: dschuff, jyknight, dylanmckay, nemanjai, jvesely, kbarton, fedor.sergeev, asb, rbar, johnrusso, simoncook, sabuasal, niosHD, jrtc27, zzheng, edward-jones, atanasyan, rogfer01, MartinMosbeck, brucehoult, the_o, arphaman, PkmX, jocewei, jsji, Jim, lenary, s.egerton, pzheng, sameer.abuasal, apazos, luismarques, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D73865
2020-02-03 09:52:48 -08:00
Martin Storsjo 71decf841c [clang] [AST] Treat "inline gnu_inline" the same way as "extern inline gnu_inline" in C++ mode
This matches how GCC handles it, see e.g. https://gcc.godbolt.org/z/HPplnl.
GCC documents the gnu_inline attribute with "In C++, this attribute does
not depend on extern in any way, but it still requires the inline keyword
to enable its special behavior."

The previous behaviour of gnu_inline in C++, without the extern
keyword, can be traced back to the original commit that added
support for gnu_inline, SVN r69045.

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

llvm-svn: 373078
2019-09-27 12:25:19 +00:00
Rafael Espindola 922f2aa9b2 Bring r325915 back.
The tests that failed on a windows host have been fixed.

Original message:

Start setting dso_local for COFF.

With this there are still some GVs where we don't set dso_local
because setGVProperties is never called. I intend to fix that in
followup commits. This is just the bare minimum to teach
shouldAssumeDSOLocal what it should do for COFF.

llvm-svn: 325940
2018-02-23 19:30:48 +00:00
Rafael Espindola 43ce3a3a4d Revert "Start setting dso_local for COFF."
This reverts commit r325915.

It will take some time to fix the failures on a windows host.

llvm-svn: 325929
2018-02-23 18:09:29 +00:00
Rafael Espindola 004d240b6a Start setting dso_local for COFF.
With this there are still some GVs where we don't set dso_local
because setGVProperties is never called. I intend to fix that in
followup commits. This is just the bare minimum to teach
shouldAssumeDSOLocal what it should do for COFF.

llvm-svn: 325915
2018-02-23 15:32:32 +00:00
Chandler Carruth 88c4ffb4e0 [PM] The new pass manager requires a registered target for these, and
given that they hard code specific triples that seems reasonable so add
the REQUIRES.

llvm-svn: 290560
2016-12-27 00:31:34 +00:00
Chandler Carruth 6d1b83ef87 [PH] Teach the new PM code path to support -disable-llvm-passes.
This is kind of funny because I specifically did work to make this easy
and then it didn't actually get implemented.

I've also ported a set of tests that rely on this functionality to run
with the new PM as well as the old PM so that we don't mess this up in
the future.

llvm-svn: 290558
2016-12-27 00:13:09 +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
David Majnemer 3f02150d31 [MSVC Compat] Enable ABI impacting non-conforming behavior independently of -fms-compatibility
No ABI for C++ currently makes it possible to implement the standard
100% perfectly.  We wrongly hid some of our compatible behavior behind
-fms-compatibility instead of tying it to the compiler ABI.

llvm-svn: 249656
2015-10-08 04:53:31 +00:00
David Majnemer c0c42f3dea [MS ABI] Don't generates code for unreferenced inline definitions of library builtins
We should only consider declarations which were written, implicit
declarations shouldn't be considered.

This fixes PR24084.

llvm-svn: 241941
2015-07-10 20:55:38 +00:00
Peter Collingbourne 470d94247d Make GNUInline consistent with whether we use traditional GNU inline semantics.
Previously we were setting LangOptions::GNUInline (which controls whether we
use traditional GNU inline semantics) if the language did not have the C99
feature flag set. The trouble with this is that C++ family languages also
do not have that flag set, so we ended up setting this flag in C++ modes
(and working around it in a few places downstream by also checking CPlusPlus).

The fix is to check whether the C89 flag is set for the target language,
rather than whether the C99 flag is cleared. This also lets us remove most
CPlusPlus checks. We continue to test CPlusPlus when deciding whether to
pre-define the __GNUC_GNU_INLINE__ macro for consistency with GCC.

There is a change in semantics in two other places
where we weren't checking both CPlusPlus and GNUInline
(FunctionDecl::doesDeclarationForceExternallyVisibleDefinition and
FunctionDecl::isInlineDefinitionExternallyVisible), but this change seems to
put us back into line with GCC's semantics (test case: test/CodeGen/inline.c).

While at it, forbid -fgnu89-inline in C++ modes, as GCC doesn't support it,
it didn't have any effect before, and supporting it just makes things more
complicated.

Differential Revision: http://reviews.llvm.org/D9333

llvm-svn: 237299
2015-05-13 22:07:22 +00:00
Rafael Espindola e5df59ff78 Emit DeferredDeclsToEmit in a DFS order.
Currently we emit DeferredDeclsToEmit in reverse order. This patch changes that.

The advantages of the change are that

* The output order is a bit closer to the source order. The change to
test/CodeGenCXX/pod-member-memcpys.cpp is a good example.

* If we decide to deffer more, it will not cause as large changes in the
estcases as it would without this patch.

llvm-svn: 226751
2015-01-22 00:24:57 +00:00
David Majnemer 54e3ba5ace CodeGen: Emit some functions as weak_odr under -fms-compatibility
Summary:
MSVC always emits inline functions marked with the extern storage class
specifier.  The result is something similar to the opposite of
__attribute__((gnu_inline)).

This extension is also available in C.

This fixes PR19264.

Reviewers: rnk, rsmith

CC: cfe-commits

Differential Revision: http://llvm-reviews.chandlerc.com/D3207

llvm-svn: 205485
2014-04-02 23:17:29 +00:00
Rafael Espindola d120b89a77 Disable llvm optimizations, but keep -O1 to test available_externally.
llvm-svn: 189918
2013-09-04 04:55:03 +00:00
Rafael Espindola 01caeb80cd Use %clang_cc1.
llvm-svn: 189917
2013-09-04 04:51:39 +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
David Majnemer 62f0ffd733 AST: Treat inline function declarations in -fms-compatibility as if it were in C++ when in C mode
This essentially fixes PR16766.

llvm-svn: 187586
2013-08-01 17:26:42 +00:00
David Blaikie a234c65613 FileCheck-ize test/CodeGen/inline.c.
A rather egregious example of the grep-style checking of old that I randomly
came across.

llvm-svn: 171631
2013-01-05 18:22:42 +00:00
Ulrich Weigand 35668cc401 A number of test cases assume that an "int" parameter or return value
will be represented in the IR as a plain "i32" type.  This causes the
tests to spuriously fail on platforms where int is not a 32-bit type,
or where the ABI requires attributes like "signext" or "zeroext" to
be used.

This patch adds -triple or -target parameters to force those tests
to use the i386-unknown-unknown target.

llvm-svn: 166551
2012-10-24 12:22:56 +00:00
Eli Friedman 1b125c3e31 Make FunctionDecl::doesDeclarationForceExternallyVisibleDefinition use the same logic as FunctionDecl::isInlineDefinitionExternallyVisible to figure out whether to emit a definition. Based on work by Anton Yartsev.
llvm-svn: 149963
2012-02-07 03:50:18 +00:00
Anton Yartsev 79de4d49a6 r149587 reverted
llvm-svn: 149594
2012-02-02 06:06:34 +00:00
Anton Yartsev 3da212585e Fix for PR10657 (http://llvm.org/bugs/show_bug.cgi?id=10657)
extern inline case considered

llvm-svn: 149587
2012-02-02 05:13:59 +00:00
Eli Friedman 94ab9308d7 PR11062: Make C99 inlining work properly for names with associated builtin libcalls.
llvm-svn: 141723
2011-10-11 22:09:24 +00:00
Nick Lewycky ba4cc01a1f Don't crash when codegen'ing an empty redecl of a function in C99 mode, when
neither was inline. Fixes bug introduced in r135377.

llvm-svn: 135380
2011-07-18 07:11:55 +00:00
Nick Lewycky 26da4ddfa6 In C99, emit an inline function when encountering an extern redeclaration.
Fixes PR10233!

llvm-svn: 135377
2011-07-18 05:26:13 +00:00
Cameron Zwarich be652e6a24 r134634 causes a failure on MultiSource/Benchmarks/Olden/bh with TEST=nightly,
so roll it out.

llvm-svn: 134638
2011-07-07 21:03:28 +00:00
Nick Lewycky d755e6ac48 A redeclaration of an inline method in C99 mode should trigger emission of that
function. Fixes PR10233!

llvm-svn: 134634
2011-07-07 20:25:10 +00:00
Chad Rosier f897d3b88b Fixed test case asserts due to checkin of r130710.
llvm-svn: 130720
2011-05-02 20:39:21 +00:00
Douglas Gregor a700f68828 Reinstate the optimization suppressing available_externally functions
at -O0. The only change from the previous patch is that we don't try
to generate virtual method thunks for an available_externally
function.

llvm-svn: 108230
2010-07-13 06:02:28 +00:00
Douglas Gregor 553f3a9b30 Speculatively revert r108156; it appears to be breaking self-host.
llvm-svn: 108194
2010-07-12 21:08:32 +00:00
Douglas Gregor dbb2806a7b Do not generate LLVM IR for available_externally function bodies at
-O0, since we won't be using the definitions for anything anyway. For
lib/System/Path.o when built in Debug+Asserts mode, this leads to a 4%
improvement in compile time (and suppresses 440 function bodies).

<rdar://problem/7987644>

llvm-svn: 108156
2010-07-12 17:24:55 +00:00
Daniel Dunbar 5618e98f33 Update tests to use %clang instead of 'clang', and forcibly disable use of '
clang ' or ' clang -cc1 ' or ' clang-cc ' in test lines (by substituting them to
garbage).

llvm-svn: 91460
2009-12-15 22:01:24 +00:00
Daniel Dunbar 8b57697954 Eliminate &&s in tests.
- 'for i in $(find . -type f); do sed -e 's#\(RUN:.*[^ ]\) *&& *$#\1#g' $i | FileUpdate $i; done', for the curious.

llvm-svn: 86430
2009-11-08 01:45:36 +00:00
Douglas Gregor 299d76e901 Rework the way we determine whether an externally visible symbol is
generated for an inline function definition, taking into account C99
and GNU inline/extern inline semantics. This solution is simpler,
cleaner, and fixes PR4536.

llvm-svn: 81670
2009-09-13 07:46:26 +00:00
Mike Stump 5e7869f63e Prep for new warning.
llvm-svn: 76638
2009-07-21 20:52:43 +00:00
Douglas Gregor 76fe50c654 Improve compatibility with GCC regarding inline semantics in GNU89
mode and in the presence of __gnu_inline__ attributes. This should fix
both PR3989 and PR4069.

As part of this, we now keep track of all of the attributes attached
to each declaration even after we've performed declaration
merging. This fixes PR3264.

llvm-svn: 70292
2009-04-28 06:37:30 +00:00
Eli Friedman 2b680b43e9 Simplify the scheme used for keywords, and change the classification
scheme to be more useful.

The new scheme introduces a set of categories that should be more 
readable, and also reflects what we want to consider as an extension 
more accurately.  Specifically, it makes the "what is a keyword" 
determination accurately reflect whether the keyword is a GNU or 
Microsoft extension.

I also introduced separate flags for keyword aliases; this is useful 
because the classification of the aliases is mostly unrelated to the 
classification of the original keyword.

This patch treats anything that's in the implementation 
namespace (prefixed with "__", or "_X" where "X" is any upper-case 
letter) as a keyword without marking it as an extension.  This is 
consistent with the standards in that an implementation is allowed to define 
arbitrary extensions in the implementation namespace without violating 
the standard. This gets rid of all the nasty "extension used" warnings 
for stuff like __attribute__ in -pedantic mode.  We still warn for 
extensions outside of the the implementation namespace, like typeof.
If someone wants to implement -Wextensions or something like that, we 
could add additional information to the keyword table.

This also removes processing for the unused "Boolean" language option; 
such an extension isn't supported on any other C implementation, so I 
don't see any point to adding it.

The changes to test/CodeGen/inline.c are required because previously, we 
weren't actually disabling the "inline" keyword in -std=c89 mode.

I'll remove Boolean and NoExtensions from LangOptions in a follow-up 
commit.

llvm-svn: 70281
2009-04-28 03:13:54 +00:00
Douglas Gregor 89c8e000cf Fix handling of C99 "extern inline" semantics when dealing with
multiple declarations of the function. Should fix PR3989 and
<rdar://problem/6818429>.

llvm-svn: 69905
2009-04-23 18:22:55 +00:00
Chris Lattner f8dc07369a Fix some mishandling of the attr(gnu_inline) mode when used with
extern.  Previously we would warn about it and ignore the attribute.
This is incorrect, it should be handled as a c89 "extern inline" 
function.  Many thanks to Matthieu Castet for pointing this out and
beating me over the head until I got it.

PR3988: extern inline function are not externally visible
llvm-svn: 69756
2009-04-22 00:03:30 +00:00
Chris Lattner ddf6ca0355 the __gnuc_inline__ attribute is actually named __gnu_inline__,
PR4023

llvm-svn: 69618
2009-04-20 19:12:28 +00:00
Chris Lattner bae0e68930 Fix PR3988: extern inline functions get strong symbol definitions in
C99 mode.  This is a regression from an earlier patch of mine.

This also simplifies the linkage enums a bit.

llvm-svn: 69069
2009-04-14 20:25:53 +00:00
Chris Lattner 02e987f3e8 implement codegen support for __attribute((__gnuc_inline__)),
pulling some attribute munging stuff into GetLinkageForFunction.

This should fix PR3986

llvm-svn: 69045
2009-04-14 16:44:36 +00:00
Chris Lattner 92028dad66 defer emission of always_inline, extern_inline, and inline functions (when
not in c89 mode).

llvm-svn: 69032
2009-04-14 06:44:48 +00:00
Chris Lattner 256c9507c8 set the linkage of an inline function according to its language rules.
llvm-svn: 69030
2009-04-14 06:27:57 +00:00