Commit Graph

964 Commits

Author SHA1 Message Date
Richard Smith bab6df86ae Rework how UuidAttr, CXXUuidofExpr, and GUID template arguments and constants are represented.
Summary:
Previously, we treated CXXUuidofExpr as quite a special case: it was the
only kind of expression that could be a canonical template argument, it
could be a constant lvalue base object, and so on. In addition, we
represented the UUID value as a string, whose source form we did not
preserve faithfully, and that we partially parsed in multiple different
places.

With this patch, we create an MSGuidDecl object to represent the
implicit object of type 'struct _GUID' created by a UuidAttr. Each
UuidAttr holds a pointer to its 'struct _GUID' and its original
(as-written) UUID string. A non-value-dependent CXXUuidofExpr behaves
like a DeclRefExpr denoting that MSGuidDecl object. We cache an APValue
representation of the GUID on the MSGuidDecl and use it from constant
evaluation where needed.

This allows removing a lot of the special-case logic to handle these
expressions. Unfortunately, many parts of Clang assume there are only
a couple of interesting kinds of ValueDecl, so the total amount of
special-case logic is not really reduced very much.

This fixes a few bugs and issues:
 * PR38490: we now support reading from GUID objects returned from
   __uuidof during constant evaluation.
 * Our Itanium mangling for a non-instantiation-dependent template
   argument involving __uuidof no longer depends on which CXXUuidofExpr
   template argument we happened to see first.
 * We now predeclare ::_GUID, and permit use of __uuidof without
   any header inclusion, better matching MSVC's behavior. We do not
   predefine ::__s_GUID, though; that seems like a step too far.
 * Our IR representation for GUID constants now uses the correct IR type
   wherever possible. We will still fall back to using the
      {i32, i16, i16, [8 x i8]}
   layout if a definition of struct _GUID is not available. This is not
   ideal: in principle the two layouts could have different padding.

Reviewers: rnk, jdoerfert

Subscribers: arphaman, cfe-commits, aeubanks

Tags: #clang

Differential Revision: https://reviews.llvm.org/D78171
2020-04-15 12:20:42 -07:00
Richard Smith 9bd6b77ac6 Don't print `&` as part of reference template arguments.
In passing, also generalize the mechanism used to allow Decl's printName
functions to override qualified name printing.
2020-04-15 00:07:12 -07:00
Reid Kleckner c915cb957d Avoid including Module.h from ExternalASTSource.h
Module.h takes 86ms to parse, mostly parsing the class itself. Avoid it
if possible. ASTContext.h depends on ExternalASTSource.h.

A few NFC changes were needed to make this possible:

- Move ASTSourceDescriptor to Module.h. This needs Module to be
  complete, and seems more related to modules and AST files than
  external AST sources.
- Move "import complete" bit from Module* pointer int pair to
  NextLocalImport pointer. Required because PointerIntPair<Module*,...>
  requires Module to be complete, and now it may not be.

Reviewed By: aaron.ballman, hans

Differential Revision: https://reviews.llvm.org/D75784
2020-03-11 13:37:41 -07:00
Mikhail Maltsev 47edf5bafb [ARM,CDE] Generalize MVE intrinsics infrastructure to support CDE
Summary:
This patch generalizes the existing code to support CDE intrinsics
which will share some properties with existing MVE intrinsics
(some of the intrinsics will be polymorphic and accept/return values
of MVE vector types).
Specifically the patch:
* Adds new tablegen backends -gen-arm-cde-builtin-def,
  -gen-arm-cde-builtin-codegen, -gen-arm-cde-builtin-sema,
  -gen-arm-cde-builtin-aliases, -gen-arm-cde-builtin-header based on
  existing MVE backends.
* Renames the '__clang_arm_mve_alias' attribute into
  '__clang_arm_builtin_alias' (it will be used with CDE intrinsics as
  well as MVE intrinsics)
* Implements semantic checks for the coprocessor argument of the CDE
  intrinsics as well as the existing coprocessor intrinsics.
* Adds one CDE intrinsic __arm_cx1 to test the above changes

Reviewers: simon_tatham, MarkMurrayARM, ostannard, dmgreen

Reviewed By: simon_tatham

Subscribers: sdesmalen, mgorny, kristof.beyls, danielkiss, cfe-commits, llvm-commits

Tags: #clang, #llvm

Differential Revision: https://reviews.llvm.org/D75850
2020-03-10 14:03:16 +00:00
Roman Lebedev 3dd5a298bf
[clang] Annotating C++'s `operator new` with more attributes
Summary:
Right now we annotate C++'s `operator new` with `noalias` attribute,
which very much is healthy for optimizations.

However as per [[ http://eel.is/c++draft/basic.stc.dynamic.allocation | `[basic.stc.dynamic.allocation]` ]],
there are more promises on global `operator new`, namely:
* non-`std::nothrow_t` `operator new` *never* returns `nullptr`
* If `std::align_val_t align` parameter is taken, the pointer will also be `align`-aligned
* ~~global `operator new`-returned pointer is `__STDCPP_DEFAULT_NEW_ALIGNMENT__`-aligned ~~ It's more caveated than that.

Supplying this information may not cause immediate landslide effects
on any specific benchmarks, but it for sure will be healthy for optimizer
in the sense that the IR will better reflect the guarantees provided in the source code.

The caveat is `-fno-assume-sane-operator-new`, which currently prevents emitting `noalias`
attribute, and is automatically passed by Sanitizers ([[ https://bugs.llvm.org/show_bug.cgi?id=16386 | PR16386 ]]) - should it also cover these attributes?
The problem is that the flag is back-end-specific, as seen in `test/Modules/explicit-build-flags.cpp`.
But while it is okay to add `noalias` metadata in backend, we really should be adding at least
the alignment metadata to the AST, since that allows us to perform sema checks on it.

Reviewers: erichkeane, rjmccall, jdoerfert, eugenis, rsmith

Reviewed By: rsmith

Subscribers: xbolva00, jrtc27, atanasyan, nlopes, cfe-commits

Tags: #llvm, #clang

Differential Revision: https://reviews.llvm.org/D73380
2020-02-26 01:37:17 +03:00
Michael Liao 2926917f43 [clang] Fix linkage of nested lambdas.
patch from Philippe Daouadi <blastrock@free.fr>

This is an attempt to fix
[PR#44368](https://bugs.llvm.org/show_bug.cgi?id=44368)

This effectively reverts [D1783](https://reviews.llvm.org/D1783). It
doesn't break the current tests and fixes the test that this commit
adds.

We now decide of a lambda linkage only depending on the visibility of
its parent context.

Differential Revision: https://reviews.llvm.org/D73701
2020-02-07 13:24:21 -05:00
serge-sans-paille d437fba8ef Reapply Allow system header to provide their own implementation of some builtin
This reverts commit 3d210ed3d1.

See https://reviews.llvm.org/D71082 for the patch and discussion that make it
possible to reapply this patch.
2020-01-17 09:58:32 +01:00
Amy Huang 3d210ed3d1 Revert "Allow system header to provide their own implementation of some builtin"
This reverts commit 921f871ac4 because it
causes libc++ code to trigger __warn_memset_zero_len.

See https://reviews.llvm.org/D71082.
2020-01-15 15:03:45 -08:00
serge-sans-paille 921f871ac4 Allow system header to provide their own implementation of some builtin
If a system header provides an (inline) implementation of some of their
function, clang still matches on the function name and generate the appropriate
llvm builtin, e.g. memcpy. This behavior is in line with glibc recommendation «
users may not provide their own version of symbols » but doesn't account for the
fact that glibc itself can provide inline version of some functions.

It is the case for the memcpy function when -D_FORTIFY_SOURCE=1 is on. In that
case an inline version of memcpy calls __memcpy_chk, a function that performs
extra runtime checks. Clang currently ignores the inline version and thus
provides no runtime check.

This code fixes the issue by detecting functions whose name is a builtin name
but also have an inline implementation.

Differential Revision: https://reviews.llvm.org/D71082
2020-01-10 09:44:20 +01:00
serge-sans-paille cee4a1c957 Improve support of GNU mempcpy
- Lower to the memcpy intrinsic
- Raise warnings when size/bounds are known

Differential Revision: https://reviews.llvm.org/D71374
2020-01-09 17:31:00 +01:00
Saar Raz b65b1f322b [Concepts] Function trailing requires clauses
Function trailing requires clauses now parsed, supported in overload resolution and when calling, referencing and taking the address of functions or function templates.

Differential Revision: https://reviews.llvm.org/D43357
2020-01-09 15:07:51 +02:00
Mark de Wever f022a5a792 Adds fixit hints to the -Wrange-loop-analysis
Differential Revision: https://reviews.llvm.org/D68913
2020-01-01 20:02:00 +01:00
Richard Smith 848934c67d [c++20] Fix handling of unqualified lookups from a defaulted comparison
function.

We need to perform unqualified lookups from the context of a defaulted
comparison, but not until we implicitly define the function, at which
point we can't do those lookups any more. So perform the lookup from the
end of the class containing the =default declaration and store the
lookup results on the defaulted function until we synthesize the body.
2019-12-09 17:40:36 -08:00
Reid Kleckner 60573ae6fe Remove Expr.h include from ASTContext.h, NFC
ASTContext.h is popular, prune its includes. Expr.h brings in Attr.h,
which is also expensive.

Move BlockVarCopyInit to Expr.h to accomplish this.
2019-12-06 15:30:49 -08:00
Saar Raz fdf80e86a5 [Concepts] Constraint Enforcement & Diagnostics
Part of the C++20 concepts implementation effort.
- Associated constraints (requires clauses, currently) are now enforced when instantiating/specializing templates and when considering partial specializations and function overloads.
- Elaborated diagnostics give helpful insight as to why the constraints were not satisfied.
Phabricator: D41569

Re-commit, after fixing some memory bugs.
2019-12-06 01:34:20 +02:00
Melanie Blower 7f9b513847 Reapply af57dbf12e "Add support for options -frounding-math, ftrapping-math, -ffp-model=, and -ffp-exception-behavior="
Patch was reverted because https://bugs.llvm.org/show_bug.cgi?id=44048
        The original patch is modified to set the strictfp IR attribute
        explicitly in CodeGen instead of as a side effect of IRBuilder.
        In the 2nd attempt to reapply there was a windows lit test fail, the
        tests were fixed to use wildcard matching.

        Differential Revision: https://reviews.llvm.org/D62731
2019-12-05 03:48:04 -08:00
Melanie Blower 5412913631 Revert " Reapply af57dbf12e "Add support for options -frounding-math, ftrapping-math, -ffp-model=, and -ffp-exception-behavior=""
This reverts commit cdbed2dd85.
Build break on Windows (lit fail)
2019-12-04 12:21:23 -08:00
Melanie Blower cdbed2dd85 Reapply af57dbf12e "Add support for options -frounding-math, ftrapping-math, -ffp-model=, and -ffp-exception-behavior="
Patch was reverted because https://bugs.llvm.org/show_bug.cgi?id=44048
        The original patch is modified to set the strictfp IR attribute
        explicitly in CodeGen instead of as a side effect of IRBuilder

        Differential Revision: https://reviews.llvm.org/D62731
2019-12-04 11:32:33 -08:00
Nicolas Manichon cc3c935da2 Add FunctionDecl::getParameterSourceRange()
This source range covers the list of parameters of the function declaration,
including the ellipsis for a variadic function.
2019-12-03 08:21:55 -05:00
Alexey Bataev bbc328c624 [OPENMP]Fix PR41826: symbols visibility in device code.
Summary:
Currently, we ignore all locality attributes/info when building for
the device and thus all symblos are externally visible and can be
preemted at the runtime. It may lead to incorrect results. We need to
follow the same logic, compiler uses for static/pie builds. But in some
cases changing of dso locality may lead to problems with codegen, so
instead mark external symbols as hidden instead in the device code.

Reviewers: jdoerfert

Subscribers: guansong, caomhin, kkwli0, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D70549
2019-11-25 15:01:28 -05:00
Vlad Tsyrklevich 38839d08b8 Revert "[Concepts] Constraint Enforcement & Diagnostics"
This reverts commit ffa214ef22, it was
causing ASAN test failures on sanitizer-x86_64-linux-bootstrap.
2019-10-28 15:00:40 -07:00
Saar Raz ffa214ef22 [Concepts] Constraint Enforcement & Diagnostics
Part of the C++20 concepts implementation effort.
- Associated constraints (requires clauses, currently) are now enforced when instantiating/specializing templates and when considering partial specializations and function overloads.
- Elaborated diagnostics give helpful insight as to why the constraints were not satisfied.
Phabricator: D41569
2019-10-25 00:19:51 +03:00
Simon Tatham 7c11da0cfd [clang] New __attribute__((__clang_arm_mve_alias)).
This allows you to declare a function with a name of your choice (say
`foo`), but have clang treat it as if it were a builtin function (say
`__builtin_foo`), by writing

  static __inline__ __attribute__((__clang_arm_mve_alias(__builtin_foo)))
  int foo(args);

I'm intending to use this for the ACLE intrinsics for MVE, which have
to be polymorphic on their argument types and also need to be
implemented by builtins. To avoid having to implement the polymorphism
with several layers of nested _Generic and make error reporting
hideous, I want to make all the user-facing intrinsics correspond
directly to clang builtins, so that after clang resolves
__attribute__((overloadable)) polymorphism it's already holding the
right BuiltinID for the intrinsic it selected.

However, this commit itself just introduces the new attribute, and
doesn't use it for anything.

To avoid unanticipated side effects if this attribute is used to make
aliases to other builtins, there's a restriction mechanism: only
(BuiltinID, alias) pairs that are approved by the function
ArmMveAliasValid() will be permitted. At present, that function
doesn't permit anything, because the Tablegen that will generate its
list of valid pairs isn't yet implemented. So the only test of this
facility is one that checks that an unapproved builtin _can't_ be
aliased.

Reviewers: dmgreen, miyuki, ostannard

Subscribers: cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D67159
2019-10-24 16:33:13 +01:00
Richard Smith d052a578de [c++2a] Allow comparison functions to be explicitly defaulted.
This adds some initial syntactic checking that only the appropriate
function signatures can be defaulted. No implicit definitions are
generated yet.
2019-10-22 18:16:17 -07:00
Michael Liao 243ebfba17 [hip][cuda] Fix the extended lambda name mangling issue.
Summary:
- HIP/CUDA host side needs to use device kernel symbol name to match the
  device side binaries. Without a consistent naming between host- and
  device-side compilations, it's risky that wrong device binaries are
  executed. Consistent naming is usually not an issue until unnamed
  types are used, especially the lambda. In this patch, the consistent
  name mangling is addressed for the extended lambdas, i.e. the lambdas
  annotated with `__device__`.
- In [Itanium C++ ABI][1], the mangling of the lambda is generally
  unspecified unless, in certain cases, ODR rule is required to ensure
  consisent naming cross TUs. The extended lambda is such a case as its
  name may be part of a device kernel function, e.g., the extended
  lambda is used as a template argument and etc. Thus, we need to force
  ODR for extended lambdas as they are referenced in both device- and
  host-side TUs. Furthermore, if a extended lambda is nested in other
  (extended or not) lambdas, those lambdas are required to follow ODR
  naming as well. This patch revises the current lambda mangle numbering
  to force ODR from an extended lambda to all its parent lambdas.
- On the other side, the aforementioned ODR naming should not change
  those lambdas' original linkages, i.e., we cannot replace the original
  `internal` with `linkonce_odr`; otherwise, we may violate ODR in
  general. This patch introduces a new field `HasKnownInternalLinkage`
  in lambda data to decouple the current linkage calculation based on
  mangling number assigned.

[1]: https://itanium-cxx-abi.github.io/cxx-abi/abi.html

Reviewers: tra, rsmith, yaxunl, martong, shafik

Subscribers: cfe-commits

Tags: #clang

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

llvm-svn: 375309
2019-10-19 00:15:19 +00:00
Richard Smith 2b4fa5348e For P0784R7: compute whether a variable has constant destruction if it
has a constexpr destructor.

For constexpr variables, reject if the variable does not have constant
destruction. In all cases, do not emit runtime calls to the destructor
for variables with constant destruction.

llvm-svn: 373159
2019-09-29 05:08:46 +00: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
Richard Smith 62a95568ef For P0784R7: add support for new (std::nothrow).
llvm-svn: 373037
2019-09-27 01:26:49 +00:00
Ilya Biryukov 6648223faf Re-land r372863: [AST] Extract Decl::printNestedNameSpecifier helper from Decl::printQualifiedName
Reverted in r372880 due to the test failure.
Also contains a fix that adjusts printQualifiedName to return the same results as before in
case of anonymous function locals and parameters.

llvm-svn: 372889
2019-09-25 15:46:04 +00:00
Ilya Biryukov 71472a3eec Revert r372863: [AST] Extract Decl::printNestedNameSpecifier helper from Decl::printQualifiedName
Reason: causes a test failure, will investigate and re-land with a fix.
llvm-svn: 372880
2019-09-25 14:50:12 +00:00
Ilya Biryukov 1e36ed7fbc [AST] Extract Decl::printNestedNameSpecifier helper from Decl::printQualifiedName
Summary:
To be used in clangd, e.g. in D66647.
Currently the alternative to this function is doing string manipulation on results of `printQualifiedName`, which is
hard-to-impossible to get right in presence of template arguments.

Reviewers: kadircet, aaron.ballman

Reviewed By: kadircet, aaron.ballman

Subscribers: aaron.ballman, usaxena95, cfe-commits

Tags: #clang

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

llvm-svn: 372863
2019-09-25 13:09:10 +00:00
Nick Desaulniers 5806022904 [Clang][CodeGen] support alias attribute w/ gnu_inline
Summary:
r369705 did not consider the addition of gnu_inline on function
declarations of alias attributed functions. This resulted in a reported
regression in the clang-9-rc4 release from the Zig developers building
glibc, which was observable as a failed assertion:

llvm-project/clang/lib/AST/Decl.cpp:3336: bool
clang::FunctionDecl::isInlineDefinitionExternallyVisible() const:
Assertion `(doesThisDeclarationHaveABody() || willHaveBody()) && "Must
be a function definition"' failed.

Alias function declarations do not have bodies, so allow us to proceed
if we have the alias function attribute but no body/definition, and add
a test case.  The emitted symbols and their linkage matches GCC for the
added test case.

Link: https://bugs.llvm.org/show_bug.cgi?id=43268

Reviewers: aaron.ballman, rsmith, erichkeane, andrewrk

Reviewed By: andrewrk

Subscribers: cfe-commits, andrewrk, hans, srhines

Tags: #clang

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

llvm-svn: 371766
2019-09-12 19:53:35 +00:00
Akira Hatanaka 090510608d [Sema] Diagnose default-initialization, destruction, and copying of
non-trivial C union types

This recommits r365985, which was reverted because it broke a few
projects using unions containing non-trivial ObjC pointer fields in
system headers. We now have a patch to fix the problem (see
https://reviews.llvm.org/D65256).

Original commit message:

This patch diagnoses uses of non-trivial C unions and structs/unions
containing non-trivial C unions in the following contexts, which require
default-initialization, destruction, or copying of the union objects,
instead of disallowing fields of non-trivial types in C unions, which is
what we currently do:

- function parameters.
- function returns.
- assignments.
- compound literals.
- block captures except capturing of `__block` variables by non-escaping blocks.
- local and global variable definitions.
- lvalue-to-rvalue conversions of volatile types.

See the discussion in https://reviews.llvm.org/D62988 for more background.

rdar://problem/50679094

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

llvm-svn: 371275
2019-09-07 00:34:43 +00:00
Richard Smith a6e8b685e1 [c++20] P1143R2: Add support for the C++20 'constinit' keyword.
This is mostly the same as the
[[clang::require_constant_initialization]] attribute, but has a couple
of additional syntactic and semantic restrictions.

In passing, I added a warning for the attribute form being added after
we have already seen the initialization of the variable (but before we
see the definition); that case previously slipped between the cracks and
the attribute was silently ignored.

llvm-svn: 370972
2019-09-04 20:30:37 +00:00
Akira Hatanaka 6f6156b9fc Revert "[Sema] Diagnose default-initialization, destruction, and copying of"
This reverts commit r365985.

Prior to r365985, clang used to mark C union fields that have
non-trivial ObjC ownership qualifiers as unavailable if the union was
declared in a system header. r365985 stopped doing so, which caused the
swift compiler to crash when it tried to import a non-trivial union.

I have a patch that fixes the crash (https://reviews.llvm.org/D65256),
but I'm temporarily reverting the original patch until we can decide on
whether it's taking the right approach.

llvm-svn: 367076
2019-07-26 00:02:17 +00:00
Akira Hatanaka 118ee5f2e0 Initialize the non-trivial C union bits I added to RecordDeclBitfields
in r365985

These bits weren't being initialized in the RecordDecl's constructor,
which probably caused test/Modules/stress1.cpp to fail on a couple of
bots.

llvm-svn: 365989
2019-07-13 03:59:55 +00:00
Richard Smith 78b239ea67 P0840R2: support for [[no_unique_address]] attribute
Summary:
Add support for the C++2a [[no_unique_address]] attribute for targets using the Itanium C++ ABI.

This depends on D63371.

Reviewers: rjmccall, aaron.ballman

Subscribers: dschuff, aheejin, cfe-commits

Tags: #clang

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

llvm-svn: 363976
2019-06-20 20:44:45 +00:00
Richard Smith 94bc88ebf4 Fix crash when checking a dependently-typed reference that is
initialized from a non-value-dependent initializer.

llvm-svn: 363622
2019-06-17 21:46:17 +00:00
Gauthier Harnisch 796ed03b84 [C++20] add Basic consteval specifier
Summary:
this revision adds Lexing, Parsing and Basic Semantic for the consteval specifier as specified by http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1073r3.html

with this patch, the consteval specifier is treated as constexpr but can only be applied to function declaration.

Changes:
 - add the consteval keyword.
 - add parsing of consteval specifier for normal declarations and lambdas expressions.
 - add the whether a declaration is constexpr is now represented by and enum everywhere except for variable because they can't be consteval.
 - adapt diagnostic about constexpr to print constexpr or consteval depending on the case.
 - add tests for basic semantic.

Reviewers: rsmith, martong, shafik

Reviewed By: rsmith

Subscribers: eraman, efriedma, rnkovacs, cfe-commits

Tags: #clang

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

llvm-svn: 363362
2019-06-14 08:56:20 +00:00
Richard Smith 715f7a1bd0 For DR712: store on a DeclRefExpr whether it constitutes an odr-use.
Begin restructuring to support the forms of non-odr-use reference
permitted by DR712.

llvm-svn: 363086
2019-06-11 17:50:32 +00:00
Richard Smith e637cbe4e4 Refactor: split Uninitialized state on APValue into an "Absent" state
representing no such object, and an "Indeterminate" state representing
an uninitialized object. The latter is not yet used, but soon will be.

llvm-svn: 361328
2019-05-21 23:15:18 +00:00
Richard Smith b2997f579a [c++20] P0780R2: Support pack-expansion of init-captures.
This permits an init-capture to introduce a new pack:

  template<typename ...T> auto x = [...a = T()] { /* a is a pack */ };

To support this, the mechanism for allowing ParmVarDecls to be packs has
been extended to support arbitrary local VarDecls.

llvm-svn: 361300
2019-05-21 20:10:50 +00:00
Hans Wennborg b0dbc9612f Revert r360637 "PR41817: Fix regression in r359260 that caused the MS compatibility"
> extension allowing a "static" declaration to follow an "extern"
> declaration to stop working.

It introduced asserts for some "static-following-extern" cases, breaking the
Chromium build. See the cfe-commits thread for reproducer.

llvm-svn: 360657
2019-05-14 10:11:33 +00:00
Richard Smith 3bde7bf3e0 PR41817: Fix regression in r359260 that caused the MS compatibility
extension allowing a "static" declaration to follow an "extern"
declaration to stop working.

llvm-svn: 360637
2019-05-14 00:27:16 +00:00
Richard Smith 76b9027f35 [c++20] Add support for explicit(bool), as described in P0892R2.
Patch by Tyker!

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

llvm-svn: 360311
2019-05-09 03:59:21 +00:00
Anastasia Stulova d6865b7d71 [OpenCL] Prevent mangling kernel functions.
Kernel function names have to be preserved as in the original
source to be able to access them from the host API side. 

This commit also adds restriction to kernels that prevents them
from being used in overloading, templates, etc.

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

llvm-svn: 360152
2019-05-07 14:22:34 +00:00
Hans Wennborg d2b9fc88c8 Revert r359949 "[clang] adding explicit(bool) from c++2a"
This caused Clang to start erroring on the following:

  struct S {
    template <typename = int> explicit S();
  };

  struct T : S {};

  struct U : T {
    U();
  };
  U::U() {}

  $ clang -c /tmp/x.cc
  /tmp/x.cc:10:4: error: call to implicitly-deleted default constructor of 'T'
  U::U() {}
     ^
  /tmp/x.cc:5:12: note: default constructor of 'T' is implicitly deleted
    because base class 'S' has no default constructor
  struct T : S {};
             ^
  1 error generated.

See discussion on the cfe-commits email thread.

This also reverts the follow-ups r359966 and r359968.

> this patch adds support for the explicit bool specifier.
>
> Changes:
> - The parsing for the explicit(bool) specifier was added in ParseDecl.cpp.
> - The storage of the explicit specifier was changed. the explicit specifier was stored as a boolean value in the FunctionDeclBitfields and in the DeclSpec class. now it is stored as a PointerIntPair<Expr*, 2> with a flag and a potential expression in CXXConstructorDecl, CXXDeductionGuideDecl, CXXConversionDecl and in the DeclSpec class.
> - Following the AST change, Serialization, ASTMatchers, ASTComparator and ASTPrinter were adapted.
> - Template instantiation was adapted to instantiate the potential expressions of the explicit(bool) specifier When instantiating their associated declaration.
> - The Add*Candidate functions were adapted, they now take a Boolean indicating if the context allowing explicit constructor or conversion function and this boolean is used to remove invalid overloads that required template instantiation to be detected.
> - Test for Semantic and Serialization were added.
>
> This patch is not yet complete. I still need to check that interaction with CTAD and deduction guides is correct. and add more tests for AST operations. But I wanted first feedback.
> Perhaps this patch should be spited in smaller patches, but making each patch testable as a standalone may be tricky.
>
> Patch by Tyker
>
> Differential Revision: https://reviews.llvm.org/D60934

llvm-svn: 360024
2019-05-06 09:51:10 +00:00
Nicolas Lesser 5fe2ddbdf4 [clang] adding explicit(bool) from c++2a
this patch adds support for the explicit bool specifier.

Changes:
- The parsing for the explicit(bool) specifier was added in ParseDecl.cpp.
- The storage of the explicit specifier was changed. the explicit specifier was stored as a boolean value in the FunctionDeclBitfields and in the DeclSpec class. now it is stored as a PointerIntPair<Expr*, 2> with a flag and a potential expression in CXXConstructorDecl, CXXDeductionGuideDecl, CXXConversionDecl and in the DeclSpec class.
- Following the AST change, Serialization, ASTMatchers, ASTComparator and ASTPrinter were adapted.
- Template instantiation was adapted to instantiate the potential expressions of the explicit(bool) specifier When instantiating their associated declaration.
- The Add*Candidate functions were adapted, they now take a Boolean indicating if the context allowing explicit constructor or conversion function and this boolean is used to remove invalid overloads that required template instantiation to be detected.
- Test for Semantic and Serialization were added.

This patch is not yet complete. I still need to check that interaction with CTAD and deduction guides is correct. and add more tests for AST operations. But I wanted first feedback.
Perhaps this patch should be spited in smaller patches, but making each patch testable as a standalone may be tricky.

Patch by Tyker

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

llvm-svn: 359949
2019-05-04 00:09:00 +00:00
Richard Smith a6b41d7c52 CWG issue 727: Fix numerous bugs in support for class-scope explicit
specializations for variable templates.

llvm-svn: 359947
2019-05-03 23:51:38 +00:00
Richard Smith f19a8b0517 Replace ad-hoc tracking of pattern for an instantiated class-scope
explicit function specialization with the MemberSpecializationInfo used
everywhere else.

Not NFC: the ad-hoc pattern tracking was not being serialized /
deserialized properly. That's fixed here.

llvm-svn: 359747
2019-05-02 00:49:14 +00:00
Richard Smith bb750689d5 C++ DR2387: a variable template declared wtih (or instantiated with) a
const-qualified type is not implicitly given internal linkage. But a
variable template declared 'static' is.

This reinstates part of r359048, reverted in r359076.

llvm-svn: 359260
2019-04-26 01:51:08 +00:00
Ilya Biryukov b8292c955c Revert r359048: C++ DR2387: a variable template declared wthi
The change breaks libc++ with the follwing error:

In file included from valarray:4:
.../include/c++/v1/valarray:1062:60: error: explicit instantiation declaration of 'valarray<_Tp>' with internal linkage
_LIBCPP_EXTERN_TEMPLATE(_LIBCPP_FUNC_VIS valarray<size_t>::valarray(size_t))
                                                           ^
.../include/c++/v1/valarray:1063:60: error: explicit instantiation declaration of '~valarray<_Tp>' with internal linkage
_LIBCPP_EXTERN_TEMPLATE(_LIBCPP_FUNC_VIS valarray<size_t>::~valarray())

llvm-svn: 359076
2019-04-24 08:50:24 +00:00
Richard Smith eeab4518e1 C++ DR2387: a variable template declared wtih (or instantiated with) a
const-qualified type is not implicitly given internal linkage. But a
variable template declared 'static' is.

llvm-svn: 359048
2019-04-23 23:48:00 +00:00
Richard Smith 96451e3a2c Fix overly-long line after r358731.
llvm-svn: 358733
2019-04-19 02:46:50 +00:00
Ali Tamur b6a8a6caa8 Fix typo in function name [NFC]
llvm-svn: 358731
2019-04-19 02:15:57 +00:00
Richard Smith a5bbbfef15 [c++2a] Add semantic support for private module fragments.
llvm-svn: 358713
2019-04-18 21:12:54 +00:00
David Goldman 19d21854e9 Special case ObjCPropertyDecl for printing
ObjCPropertyDecl should use the category interface as a context similar to what is done for methods.

Previously category methods would be printed as `::property`; now they are printed as `Class::property`.

llvm-svn: 357720
2019-04-04 20:13:22 +00:00
Erik Pilkington b6e16ea006 [Sema] Add some compile time _FORTIFY_SOURCE diagnostics
These diagnose overflowing calls to subset of fortifiable functions. Some
functions, like sprintf or strcpy aren't supported right not, but we should
probably support these in the future. We previously supported this kind of
functionality with -Wbuiltin-memcpy-chk-size, but that diagnostic doesn't work
with _FORTIFY implementations that use wrapper functions. Also unlike that
diagnostic, we emit these warnings regardless of whether _FORTIFY_SOURCE is
actually enabled, which is nice for programs that don't enable the runtime
checks.

Why not just use diagnose_if, like Bionic does? We can get better diagnostics in
the compiler (i.e. mention the sizes), and we have the potential to diagnose
sprintf and strcpy which is impossible with diagnose_if (at least, in languages
that don't support C++14 constexpr). This approach also saves standard libraries
from having to add diagnose_if.

rdar://48006655

Differential revision: https://reviews.llvm.org/D58797

llvm-svn: 356397
2019-03-18 19:23:45 +00:00
Akira Hatanaka c5792aa90f Avoid needlessly copying a block to the heap when a block literal
initializes a local auto variable or is assigned to a local auto
variable that is declared in the scope that introduced the block
literal.

rdar://problem/13289333

https://reviews.llvm.org/D58514

llvm-svn: 355012
2019-02-27 18:17:16 +00:00
Clement Courbet 8c3343dfd5 [Builtins] Treat `bcmp` as a builtin.
Summary:
This makes it consistent with `memcmp` and `__builtin_bcmp`.

Also see the discussion in https://reviews.llvm.org/D56593.

Reviewers: jyknight

Subscribers: kristina, cfe-commits

Tags: #clang

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

llvm-svn: 354023
2019-02-14 12:00:34 +00:00
Chandler Carruth 2946cd7010 Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636
2019-01-19 08:50:56 +00:00
Aaron Ballman d23e9bc5af Diagnose an unused result from a call through a function pointer whose return type is marked [[nodiscard]].
When a function returns a type and that type was declared [[nodiscard]], we diagnose any unused results from that call as though the function were marked nodiscard. The same behavior should apply to calls through a function pointer.

This addresses PR31526.

llvm-svn: 350317
2019-01-03 14:24:31 +00:00
Richard Trieu 0f25c747a3 Fix up diagnostics.
Move some diagnostics around between Diagnostic*Kinds.td files.  Diagnostics
used in multiple places were moved to DiagnosticCommonKinds.td.  Diagnostics
listed in the wrong place (ie, Sema diagnostics listed in
DiagnosticsParseKinds.td) were moved to the correct places.  One diagnostic
split into two so that the diagnostic string is in the .td file instead of in
code.  Cleaned up the diagnostic includes after all the changes.

llvm-svn: 349125
2018-12-14 03:35:10 +00:00
Bruno Ricci 0b639da54e [AST] Fix an uninitialized bug in the bits of FunctionDecl
FunctionDeclBits.IsCopyDeductionCandidate was not initialized.
This caused a warning with valgrind.

llvm-svn: 348131
2018-12-03 13:04:10 +00:00
Erich Keane 5c0d1925e3 [NFC] Move MultIversioning::Type into Decl so that it can be used in
CodeGen

Change-Id: I32b14edca3501277e0e65672eafe3eea38c6f9ae
llvm-svn: 347791
2018-11-28 18:34:14 +00:00
Jonas Devlieghere 64a2630825 Pass the function type instead of the return type to FunctionDecl::Create
Fix places where the return type of a FunctionDecl was being used in
place of the function type

FunctionDecl::Create() takes as its T parameter the type of function
that should be created, not the return type. Passing in the return type
looks to have been copypasta'd around a bit, but the number of correct
usages outweighs the incorrect ones so I've opted for keeping what T is
the same and fixing up the call sites instead.

This fixes a crash in Clang when attempting to compile the following
snippet of code with -fblocks -fsanitize=function -x objective-c++ (my
original repro case):

  void g(void(^)());
  void f()
  {
      __block int a = 0;
        g(^(){ a++; });
  }

as well as the following which only requires -fsanitize=function -x c++:

  void f(char * buf)
  {
      __builtin_os_log_format(buf, "");
  }

Patch by: Ben (bobsayshilol)

Differential revision: https://reviews.llvm.org/D53263

llvm-svn: 346601
2018-11-11 00:56:15 +00:00
Bill Wendling 7c44da279e Create ConstantExpr class
A ConstantExpr class represents a full expression that's in a context where a
constant expression is required. This class reflects the path the evaluator
took to reach the expression rather than the syntactic context in which the
expression occurs.

In the future, the class will be expanded to cache the result of the evaluated
expression so that it's not needlessly re-evaluated

Reviewed By: rsmith

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

llvm-svn: 345692
2018-10-31 03:48:47 +00:00
Erich Keane 19a8adc9bd Implement Function Multiversioning for Non-ELF Systems.
Similar to how ICC handles CPU-Dispatch on Windows, this patch uses the
resolver function directly to forward the call to the proper function.
This is not nearly as efficient as IFuncs of course, but is still quite
useful for large functions specifically developed for certain
processors.

This is unfortunately still limited to x86, since it depends on
__builtin_cpu_supports and __builtin_cpu_is, which are x86 builtins.

The naming for the resolver/forwarding function for cpu-dispatch was
taken from ICC's implementation, which uses the unmodified name for this
(no mangling additions).  This is possible, since cpu-dispatch uses '.A'
for the 'default' version.

In 'target' multiversioning, this function keeps the '.resolver'
extension in order to keep the default function keeping the default
mangling.

Change-Id: I4731555a39be26c7ad59a2d8fda6fa1a50f73284

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

llvm-svn: 345298
2018-10-25 18:57:19 +00:00
Reid Kleckner a52d151f9d [AST] Use -fvisibility value when ignoring -fv-i-h* inline static locals
Summary:
In r340386 we added code to give static locals in inline functions
default visibility. Instead, we should use the "default" visibility
passed on the command line, which could be hidden or protected, as GCC
does.

Some code bases use both -fvisibility=hidden and
-fvisibility-inlines-hidden to hide inline functions of classes that are
explicitly marked with default visibility.

Fixes PR39236

Reviewers: hans, thakis

Subscribers: eraman, llvm-commits

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

llvm-svn: 344190
2018-10-10 21:59:56 +00:00
Yaxun Liu 9767089d00 [HIP] Support early finalization of device code for -fno-gpu-rdc
This patch renames -f{no-}cuda-rdc to -f{no-}gpu-rdc and keeps the original
options as aliases. When -fgpu-rdc is off,
clang will assume the device code in each translation unit does not call
external functions except those in the device library, therefore it is possible
to compile the device code in each translation unit to self-contained kernels
and embed them in the host object, so that the host object behaves like
usual host object which can be linked by lld.

The benefits of this feature is: 1. allow users to create static libraries which
can be linked by host linker; 2. amortized device code linking time.

This patch modifies HIP action builder to insert actions for linking device
code and generating HIP fatbin, and pass HIP fatbin to host backend action.
It extracts code for constructing command for generating HIP fatbin as
a function so that it can be reused by early finalization. It also modifies
codegen of HIP host constructor functions to embed the device fatbin
when it is available.

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

llvm-svn: 343611
2018-10-02 17:48:54 +00:00
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
Hiroshi Inoue 03ff37ddab [AST] correct the behavior of -fvisibility-inlines-hidden option (don't make static local variables hidden)
The command line option -fvisibility-inlines-hidden makes inlined method hidden, but it is expected not to affect the visibility of static local variables in the function.
However, Clang makes the static local variables in the function also hidden as reported in PR37595. This problem causes LLVM bootstarp failure on Fedora 28 if configured with -DBUILD_SHARED_LIBS=ON.

This patch makes the behavior of -fvisibility-inlines-hidden option to be consistent with that of gcc; the option does not change the visibility of the static local variables if the containing function does not associated with explicit visibility attribute and becomes hidden due to this option.

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

llvm-svn: 340386
2018-08-22 05:43:27 +00:00
Erik Pilkington 5a559e64a9 Add a new flag and attributes to control static destructor registration
This commit adds the flag -fno-c++-static-destructors and the attributes
[[clang::no_destroy]] and [[clang::always_destroy]]. no_destroy specifies that a
specific static or thread duration variable shouldn't have it's destructor
registered, and is the default in -fno-c++-static-destructors mode.
always_destroy is the opposite, and is the default in -fc++-static-destructors
mode.

A variable whose destructor is disabled (either because of
-fno-c++-static-destructors or [[clang::no_destroy]]) doesn't count as a use of
the destructor, so we don't do any access checking or mark it referenced. We
also don't emit -Wexit-time-destructors for these variables.

rdar://21734598

Differential revision: https://reviews.llvm.org/D50994

llvm-svn: 340306
2018-08-21 17:24:06 +00:00
Stephen Kelly 1c301dcbc4 Port getLocEnd -> getEndLoc
Reviewers: teemperor!

Subscribers: cfe-commits

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

llvm-svn: 339386
2018-08-09 21:09:38 +00:00
Stephen Kelly f2ceec4811 Port getLocStart -> getBeginLoc
Reviewers: teemperor!

Subscribers: jholewinski, whisperity, jfb, cfe-commits

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

llvm-svn: 339385
2018-08-09 21:08:08 +00:00
Erich Keane c9d2990b91 [AST][3/4] Move the bit-fields from BlockDecl, LinkageSpecDecl and OMPDeclareReductionDecl into DeclContext
This patch follows https://reviews.llvm.org/D49729
and https://reviews.llvm.org/D49732, and is
followed by https://reviews.llvm.org/D49734.

Move the bits from BlockDecl, LinkageSpecDecl and
OMPDeclareReductionDecl into DeclContext.

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

Patch By: bricci

llvm-svn: 338639
2018-08-01 21:16:54 +00:00
Erich Keane 9c66506604 [AST][2/4] Move the bit-fields from FunctionDecl and CXXConstructorDecl into DeclContext
This patch follows https://reviews.llvm.org/D49729
and is followed by https://reviews.llvm.org/D49733
and https://reviews.llvm.org/D49734.

Move the bits from FunctionDecl and CXXConstructorDecl
into DeclContext.

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

Patch By: bricci

llvm-svn: 338636
2018-08-01 21:02:40 +00:00
Erich Keane f92f31c6a8 [AST][1/4] Move the bit-fields from TagDecl, EnumDecl and RecordDecl into DeclContext
DeclContext has a little less than 8 bytes free due to the alignment
requirements on 64 bits archs. This set of patches moves the
bit-fields from classes deriving from DeclContext into DeclContext.

On 32 bits archs this increases the size of DeclContext by 4 bytes
but this is balanced by an equal or larger reduction in the size
of the classes deriving from it.

On 64 bits archs the size of DeclContext stays the same but
most of the classes deriving from it shrink by 8/16 bytes.
(-print-stats diff here https://reviews.llvm.org/D49728)
When doing an -fsyntax-only on all of Boost this result
in a 3.6% reduction in the size of all Decls and
a 1% reduction in the run time due to the lower cache
miss rate.

For now CXXRecordDecl is not touched but there is
an easy 6 (if I count correctly) bytes gain available there
by moving some bits from DefinitionData into the free
space of DeclContext. This will be the subject of another patch.

This patch sequence also enable the possibility of refactoring
FunctionDecl: To save space some bits from classes deriving from
FunctionDecl were moved to FunctionDecl. This resulted in a
lot of stuff in FunctionDecl which do not belong logically to it.
After this set of patches however it is just a simple matter of
adding a SomethingDeclBitfields in DeclContext and moving the
bits to it from FunctionDecl.

This first patch introduces the anonymous union in DeclContext
and all the *DeclBitfields classes holding the bit-fields, and moves
the bits from TagDecl, EnumDecl and RecordDecl into DeclContext.

This patch is followed by https://reviews.llvm.org/D49732,
https://reviews.llvm.org/D49733 and https://reviews.llvm.org/D49734.

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

Patch By: bricci

llvm-svn: 338630
2018-08-01 20:48:16 +00:00
Fangrui Song 6907ce2f8f Remove trailing space
sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h}

llvm-svn: 338291
2018-07-30 19:24:48 +00:00
George Karpenkov 39e5137f43 [AST] Add a convenient getter from QualType to RecordDecl
Differential Revision: https://reviews.llvm.org/D49951

llvm-svn: 338187
2018-07-28 02:16:13 +00:00
Richard Trieu ab4d730f14 [ODRHash] Support hashing enums.
llvm-svn: 337978
2018-07-25 22:52:05 +00:00
Erich Keane 3efe00206f Implement cpu_dispatch/cpu_specific Multiversioning
As documented here: https://software.intel.com/en-us/node/682969 and
https://software.intel.com/en-us/node/523346. cpu_dispatch multiversioning
is an ICC feature that provides for function multiversioning.

This feature is implemented with two attributes: First, cpu_specific,
which specifies the individual function versions. Second, cpu_dispatch,
which specifies the location of the resolver function and the list of
resolvable functions.

This is valuable since it provides a mechanism where the resolver's TU
can be specified in one location, and the individual implementions
each in their own translation units.

The goal of this patch is to be source-compatible with ICC, so this
implementation diverges from the ICC implementation in a few ways:
1- Linux x86/64 only: This implementation uses ifuncs in order to
properly dispatch functions. This is is a valuable performance benefit
over the ICC implementation. A future patch will be provided to enable
this feature on Windows, but it will obviously more closely fit ICC's
implementation.
2- CPU Identification functions: ICC uses a set of custom functions to identify
the feature list of the host processor. This patch uses the cpu_supports
functionality in order to better align with 'target' multiversioning.
1- cpu_dispatch function def/decl: ICC's cpu_dispatch requires that the function
marked cpu_dispatch be an empty definition. This patch supports that as well,
however declarations are also permitted, since the linker will solve the
issue of multiple emissions.

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

llvm-svn: 337552
2018-07-20 14:13:28 +00:00
Richard Trieu 27c1b1a638 [ODRHash] Merge the two function hashes into one.
Functions that are a sub-Decl of a record were hashed differently than other
functions.  This change keeps the AddFunctionDecl function and the hash of
records now calls this function.  In addition, AddFunctionDecl has an option
to perform a hash as if the body was absent, which is required for some
checks after loading modules.  Additional logic prevents multiple error
message from being printed.

llvm-svn: 336632
2018-07-10 01:40:50 +00:00
Justin Lebar 5489f85fda [CUDA] Allow "extern __shared__ Foo foo[]" within anon. namespaces.
Summary:
Previously this triggered a -Wundefined-internal warning.  But it's not
an undefined variable -- any variable of this form is a pointer to the
base of GPU core's shared memory.

Reviewers: tra

Subscribers: sanjoy, rsmith

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

llvm-svn: 332621
2018-05-17 16:15:07 +00:00
Adrian Prantl 9fc8faf9e6 Remove \brief commands from doxygen comments.
This is similar to the LLVM change https://reviews.llvm.org/D46290.

We've been running doxygen with the autobrief option for a couple of
years now. This makes the \brief markers into our comments
redundant. Since they are a visual distraction and we don't want to
encourage more \brief markers in new code either, this patch removes
them all.

Patch produced by

for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done
for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done

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

llvm-svn: 331834
2018-05-09 01:00:01 +00:00
Steven Wu 79cbd1163a [CXX] Templates specialization visibility can be wrong
Summary:
Under some conditions, LinkageComputer can get the visibility for
ClassTemplateSpecializationDecl wrong because it failed to find the Decl
that has the explicit visibility.

This fixes:
llvm.org/bugs/pr36810
rdar://problem/38080953

Reviewers: rsmith, arphaman, doug.gregor

Reviewed By: doug.gregor

Subscribers: doug.gregor, cfe-commits

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

llvm-svn: 330338
2018-04-19 15:46:43 +00:00
Akira Hatanaka e6313ace66 [ObjC++] Never pass structs that transitively contain __weak fields in
registers.

This patch fixes a bug in r328731 that caused structs transitively
containing __weak fields to be passed in registers. The patch replaces
the flag RecordDecl::CanPassInRegisters with a 2-bit enum that indicates
whether the struct or structs containing the struct are forced to be
passed indirectly.

This reapplies r329617. r329617 didn't specify the underlying type for
enum ArgPassingKind, which caused regression tests to fail on a windows
bot.

rdar://problem/39194693

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

llvm-svn: 329635
2018-04-09 22:48:22 +00:00
Akira Hatanaka d236a34ddb Revert "[ObjC++] Never pass structs that transitively contain __weak fields in"
This reverts commit r329617. It broke a windows bot.

http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/16372/steps/test/logs/stdio

llvm-svn: 329627
2018-04-09 21:47:58 +00:00
Akira Hatanaka f15d29ccc7 [ObjC++] Never pass structs that transitively contain __weak fields in
registers.

This patch fixes a bug in r328731 that caused structs transitively
containing __weak fields to be passed in registers. The patch replaces
the flag RecordDecl::CanPassInRegisters with a 2-bit enum that indicates
whether the struct or structs containing the struct are forced to be
passed indirectly.

rdar://problem/39194693

llvm-svn: 329617
2018-04-09 20:39:47 +00:00
Richard Smith 866dee4ea0 Add helper to determine if a field is a zero-length bitfield.
llvm-svn: 328999
2018-04-02 18:29:43 +00:00
Akira Hatanaka fcbe17c6be [ObjC++] Make parameter passing and function return compatible with ObjC
ObjC and ObjC++ pass non-trivial structs in a way that is incompatible
with each other. For example:
    
typedef struct {
  id f0;
  __weak id f1;
} S;
    
// this code is compiled in c++.
extern "C" {
  void foo(S s);
}
    
void caller() {
  // the caller passes the parameter indirectly and destructs it.
  foo(S());
}
    
// this function is compiled in c.
// 'a' is passed directly and is destructed in the callee.
void foo(S a) {
}
    
This patch fixes the incompatibility by passing and returning structs
with __strong or weak fields using the C ABI in C++ mode. __strong and
__weak fields in a struct do not cause the struct to be destructed in
the caller and __strong fields do not cause the struct to be passed
indirectly.
    
Also, this patch fixes the microsoft ABI bug mentioned here:
    
https://reviews.llvm.org/D41039?id=128767#inline-364710
    
rdar://problem/38887866
    
Differential Revision: https://reviews.llvm.org/D44908

llvm-svn: 328731
2018-03-28 21:13:14 +00:00
Jordan Rose 1e879d8be6 Sink PrettyDeclStackTrace down to the AST library
...and add some very basic stack trace entries for module building.
This would have helped track down rdar://problem/38434694 sooner.

llvm-svn: 328276
2018-03-23 00:07:18 +00:00
Akira Hatanaka d791e92b5f [ObjC] Allow declaring __weak pointer fields in C structs in ARC.
This patch uses the infrastructure added in r326307 for enabling
non-trivial fields to be declared in C structs to allow __weak fields in
C structs in ARC.

This recommits r327206, which was reverted because it caused
module-enabled builders to fail. I discovered that the
CXXRecordDecl::CanPassInRegisters flag wasn't being set correctly in
some cases after I moved it to RecordDecl.

Thanks to Eric Liu for helping me investigate the bug.

rdar://problem/33599681

https://reviews.llvm.org/D44095

llvm-svn: 327870
2018-03-19 17:38:40 +00:00
Akira Hatanaka be7daa3d50 Revert "[ObjC] Allow declaring __weak pointer fields in C structs in
ARC."

This reverts commit r327206 as there were test failures caused by this
patch.

http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20180312/221427.html

llvm-svn: 327294
2018-03-12 17:05:06 +00:00
Akira Hatanaka c181b127c0 [ObjC] Allow declaring __weak pointer fields in C structs in ARC.
This patch uses the infrastructure added in r326307 for enabling
non-trivial fields to be declared in C structs to allow __weak fields in
C structs in ARC.

rdar://problem/33599681

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

llvm-svn: 327206
2018-03-10 06:36:08 +00:00
George Burgess IV 00f70bd933 Remove redundant casts. NFC
So I wrote a clang-tidy check to lint out redundant `isa`, `cast`, and
`dyn_cast`s for fun. This is a portion of what it found for clang; I
plan to do similar cleanups in LLVM and other subprojects when I find
time.

Because of the volume of changes, I explicitly avoided making any change
that wasn't highly local and obviously correct to me (e.g. we still have
a number of foo(cast<Bar>(baz)) that I didn't touch, since overloading
is a thing and the cast<Bar> did actually change the type -- just up the
class hierarchy).

I also tried to leave the types we were cast<>ing to somewhere nearby,
in cases where it wasn't locally obvious what we were dealing with
before.

llvm-svn: 326416
2018-03-01 05:43:23 +00:00