[DebugInfo] Add another level to DebugInfoKind called Constructor

The option will limit debug info by only emitting complete class
type information when its constructor is emitted.
This patch change

[DebugInfo] Add another level to DebugInfoKind called Constructor

The option will limit debug info by only emitting complete class
type information when its constructor is emitted.
This patch changes comparisons with LimitedDebugInfo to use the new
level instead.

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

show more ...

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

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

show more ...

[Sema][X86] Consider target attribute into the checks in validateOutputSize and validateInputSize.

The validateOutputSize and validateInputSize need to check whether
AVX or AVX512 are enabled. But t

[Sema][X86] Consider target attribute into the checks in validateOutputSize and validateInputSize.

The validateOutputSize and validateInputSize need to check whether
AVX or AVX512 are enabled. But this can be affected by the
target attribute so we need to factor that in.

This patch moves some of the code from CodeGen to create an
appropriate feature map that we can pass to the function.

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

show more ...

reland "[DebugInfo] Support to emit debugInfo for extern variables"

Commit d77ae1552fc21a9f3877f3ed7e13d631f517c825
("[DebugInfo] Support to emit debugInfo for extern variables")
added deebugInfo fo

reland "[DebugInfo] Support to emit debugInfo for extern variables"

Commit d77ae1552fc21a9f3877f3ed7e13d631f517c825
("[DebugInfo] Support to emit debugInfo for extern variables")
added deebugInfo for extern variables for BPF target.
The commit is reverted by 891e25b02d760d0de18c7d46947913b3166047e7
as the committed tests using %clang instead of %clang_cc1 causing
test failed in certain scenarios as reported by Reid Kleckner.

This patch fixed the tests by using %clang_cc1.

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

show more ...

Revert "[DebugInfo] Support to emit debugInfo for extern variables"

This reverts commit d77ae1552fc21a9f3877f3ed7e13d631f517c825.

The tests committed along with this change do not pass, and should

Revert "[DebugInfo] Support to emit debugInfo for extern variables"

This reverts commit d77ae1552fc21a9f3877f3ed7e13d631f517c825.

The tests committed along with this change do not pass, and should be
changed to use %clang_cc1.

show more ...

[OpenMP] Use the OpenMP-IR-Builder

This is a follow up patch to use the OpenMP-IR-Builder, as discussed on
the mailing list ([1] and later) and at the US Dev Meeting'19.

[1] http://lists.flang-comp

[OpenMP] Use the OpenMP-IR-Builder

This is a follow up patch to use the OpenMP-IR-Builder, as discussed on
the mailing list ([1] and later) and at the US Dev Meeting'19.

[1] http://lists.flang-compiler.org/pipermail/flang-dev_lists.flang-compiler.org/2019-May/000197.html

Reviewers: kiranchandramohan, ABataev, RaviNarayanaswamy, gtbercea, grokos, sdmitriev, JonChesterfield, hfinkel, fghanim

Subscribers: ppenzin, penzn, llvm-commits, cfe-commits, jfb, guansong, bollu, hiraditya, mgorny

Tags: #clang

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

show more ...

CodeGen: Allow annotations on globals in non-zero address space

Summary:
Attribute annotations are recorded in a special global composite variable
that points to annotation strings and the annotated

CodeGen: Allow annotations on globals in non-zero address space

Summary:
Attribute annotations are recorded in a special global composite variable
that points to annotation strings and the annotated objects.

As a restriction of the LLVM IR type system, those pointers are all
pointers to address space 0, so let's insert an addrspacecast when the
annotated global is in a non-0 address space.

Since this addrspacecast is only reachable from the global annotations
object, this should allow us to represent annotations on all globals
regardless of which addrspacecasts are usually legal for the target.

Reviewers: rjmccall

Subscribers: cfe-commits

Tags: #clang

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

show more ...

[DebugInfo] Support to emit debugInfo for extern variables

Extern variable usage in BPF is different from traditional
pure user space application. Recent discussion in linux bpf
mailing list has two

[DebugInfo] Support to emit debugInfo for extern variables

Extern variable usage in BPF is different from traditional
pure user space application. Recent discussion in linux bpf
mailing list has two use cases where debug info types are
required to use extern variables:
- extern types are required to have a suitable interface
in libbpf (bpf loader) to provide kernel config parameters
to bpf programs.
https://lore.kernel.org/bpf/CAEf4BzYCNo5GeVGMhp3fhysQ=_axAf=23PtwaZs-yAyafmXC9g@mail.gmail.com/T/#t
- extern types are required so kernel bpf verifier can
verify program which uses external functions more precisely.
This will make later link with actual external function no
need to reverify.
https://lore.kernel.org/bpf/87eez4odqp.fsf@toke.dk/T/#m8d5c3e87ffe7f2764e02d722cb0d8cbc136880ed

This patch added clang support to emit debuginfo for extern variables
with a TargetInfo hook to enable it. The debuginfo for the
extern variable is emitted only if that extern variable is
referenced in the current compilation unit.

Currently, only BPF target enables to generate debug info for
extern variables. The emission of such debuginfo is disabled for C++
at this moment since BPF only supports a subset of C language.
Emission with C++ can be enabled later if an appropriate use case
is identified.

-fstandalone-debug permits us to see more debuginfo with the cost
of bloated binary size. This patch did not add emission of extern
variable debug info with -fstandalone-debug. This can be
re-evaluated if there is a real need.

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

show more ...

[Attr] Move ParsedTargetAttr out of the TargetAttr class

Need to forward declare it in ASTContext.h for D68627, so it can't be a nested struct.

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

Revert "[Sema][X86] Consider target attribute into the checks in validateOutputSize and validateInputSize."

This reverts commit e1578fd2b79fe5af5f80c0c166a8abd0f816c022.

It introduces a dependency

Revert "[Sema][X86] Consider target attribute into the checks in validateOutputSize and validateInputSize."

This reverts commit e1578fd2b79fe5af5f80c0c166a8abd0f816c022.

It introduces a dependency on Attr.h which I am removing from
ASTContext.h.

show more ...

[Sema][X86] Consider target attribute into the checks in validateOutputSize and validateInputSize.

The validateOutputSize and validateInputSize need to check whether
AVX or AVX512 are enabled. But t

[Sema][X86] Consider target attribute into the checks in validateOutputSize and validateInputSize.

The validateOutputSize and validateInputSize need to check whether
AVX or AVX512 are enabled. But this can be affected by the
target attribute so we need to factor that in.

This patch copies some of the code from CodeGen to create an
appropriate feature map that we can pass to the function. Probably
need some refactoring here to share more code with Codegen. Is
there a good place to do that? Also need to support the cpu_specific
attribute as well.

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

show more ...

[Clang] Define Fuchsia C++ABI

Currently, it is a modified version of the Itanium ABI, with the only
change being that constructors and destructors return 'this'.

Differential Revision: https://revi

[Clang] Define Fuchsia C++ABI

Currently, it is a modified version of the Itanium ABI, with the only
change being that constructors and destructors return 'this'.

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

show more ...

[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

[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

show more ...

DebugInfo: Flag Dwarf Version metadata for merging during LTO

When the Dwarf Version metadata was initially added (r184276) there was
no support for Module::Max - though the comment suggested that w

DebugInfo: Flag Dwarf Version metadata for merging during LTO

When the Dwarf Version metadata was initially added (r184276) there was
no support for Module::Max - though the comment suggested that was the
desired behavior. The original behavior was Module::Warn which would
warn and then pick whichever version came first - which is pretty
arbitrary/luck-based if the consumer has some need for one version or
the other.

Now that the functionality's been added (r303590) this change updates
the implementation to match the desired goal.

The general logic here is - if you compile /some/ of your program with a
more recent DWARF version, you must have a consumer that can handle it,
so might as well use it for /everything/.

The only place where this might fall down is if you have a need to use
an old tool (supporting only the older DWARF version) for some subset of
your program. In which case now it'll all be the higher version. That
seems pretty narrow (& the inverse could happen too - you specifically
/need/ the higher DWARF version for some extra expressivity, etc, in
some part of the program)

show more ...

[DeclCXX] Remove unknown external linkage specifications

Partial revert of r372681 "Support for DWARF-5 C++ language tags".

The change introduced new external linkage languages ("C++11" and
"C++14"

[DeclCXX] Remove unknown external linkage specifications

Partial revert of r372681 "Support for DWARF-5 C++ language tags".

The change introduced new external linkage languages ("C++11" and
"C++14") which not supported in C++.

It also changed the definition of the existing enum to use the DWARF
constants. The problem is that "LinkageSpecDeclBits.Language" (the field
that reserves this enum) is actually defined as 3 bits length
(bitfield), which cannot contain the new DWARF constants. Defining the
enum as integer literals is more appropriate for maintaining valid
values.

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

show more ...

[NFC] Refactor representation of materialized temporaries

Summary:
this patch refactor representation of materialized temporaries to prevent an issue raised by rsmith in https://reviews.llvm.org/D63

[NFC] Refactor representation of materialized temporaries

Summary:
this patch refactor representation of materialized temporaries to prevent an issue raised by rsmith in https://reviews.llvm.org/D63640#inline-612718

Reviewers: rsmith, martong, shafik

Reviewed By: rsmith

Subscribers: thakis, sammccall, ilya-biryukov, rnkovacs, arphaman, cfe-commits

Tags: #clang

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

show more ...

Revert "[NFC] Refactor representation of materialized temporaries"

This reverts commit 08ea1ee2db5f9d6460fef1d79d0d1d1a5eb78982.
It broke ./ClangdTests/FindExplicitReferencesTest.All
on the bots, se

Revert "[NFC] Refactor representation of materialized temporaries"

This reverts commit 08ea1ee2db5f9d6460fef1d79d0d1d1a5eb78982.
It broke ./ClangdTests/FindExplicitReferencesTest.All
on the bots, see comments on https://reviews.llvm.org/D69360

show more ...

[NFC] Refactor representation of materialized temporaries

Summary:
this patch refactor representation of materialized temporaries to prevent an issue raised by rsmith in https://reviews.llvm.org/D63

[NFC] Refactor representation of materialized temporaries

Summary:
this patch refactor representation of materialized temporaries to prevent an issue raised by rsmith in https://reviews.llvm.org/D63640#inline-612718

Reviewers: rsmith, martong, shafik

Reviewed By: rsmith

Subscribers: rnkovacs, arphaman, cfe-commits

Tags: #clang

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

show more ...

Don't add optnone or noinline if the function is already marked as
always_inline.

The assertion in SetLLVMFunctionAttributesForDefinition used to fail
when there was attribute OptimizeNone on the AS

Don't add optnone or noinline if the function is already marked as
always_inline.

The assertion in SetLLVMFunctionAttributesForDefinition used to fail
when there was attribute OptimizeNone on the AST function and attribute
always_inline on the IR function. This happens because base destructors
are annotated with always_inline when the code is compiled with
-fapple-kext (see r124757).

rdar://problem/57169694

show more ...

Add missing includes needed to prune LLVMContext.h include, NFC

These are a pre-requisite to removing #include "llvm/Support/Options.h"
from LLVMContext.h: https://reviews.llvm.org/D70280

Redeclare Objective-C property accessors inside the ObjCImplDecl in which they are synthesized.

This patch is motivated by (and factored out from)
https://reviews.llvm.org/D66121 which is a debug in

Redeclare Objective-C property accessors inside the ObjCImplDecl in which they are synthesized.

This patch is motivated by (and factored out from)
https://reviews.llvm.org/D66121 which is a debug info bugfix. Starting
with DWARF 5 all Objective-C methods are nested inside their
containing type, and that patch implements this for synthesized
Objective-C properties.

1. SemaObjCProperty populates a list of synthesized accessors that may
need to inserted into an ObjCImplDecl.

2. SemaDeclObjC::ActOnEnd inserts forward-declarations for all
accessors for which no override was provided into their
ObjCImplDecl. This patch does *not* synthesize AST function
*bodies*. Moving that code from the static analyzer into Sema may
be a good idea though.

3. Places that expect all methods to have bodies have been updated.

I did not update the static analyzer's inliner for synthesized
properties to point back to the property declaration (see
test/Analysis/Inputs/expected-plists/nullability-notes.m.plist), which
I believed to be more bug than a feature.

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

rdar://problem/53782400

show more ...

[HIP] Fix visibility for 'extern' device variables.

Summary:
- Fix a bug which misses the change for a variable to be set with
target-specific attributes.

Reviewers: yaxunl

Subscribers: jvesely,

[HIP] Fix visibility for 'extern' device variables.

Summary:
- Fix a bug which misses the change for a variable to be set with
target-specific attributes.

Reviewers: yaxunl

Subscribers: jvesely, nhaehnle, cfe-commits

Tags: #clang

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

show more ...

[CodeGen] Fix invalid llvm.linker.options about pragma detect_mismatch

When a target does not support pragma detect_mismatch, an llvm.linker.options
metadata with an empty entry is created, which ca

[CodeGen] Fix invalid llvm.linker.options about pragma detect_mismatch

When a target does not support pragma detect_mismatch, an llvm.linker.options
metadata with an empty entry is created, which causes diagnostic in backend
since backend expects name/value pair in llvm.linker.options entries.

This patch fixes that.

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

show more ...

Add Windows Control Flow Guard checks (/guard:cf).

Summary:
A new function pass (Transforms/CFGuard/CFGuard.cpp) inserts CFGuard checks on
indirect function calls, using either the check mechanism (

Add Windows Control Flow Guard checks (/guard:cf).

Summary:
A new function pass (Transforms/CFGuard/CFGuard.cpp) inserts CFGuard checks on
indirect function calls, using either the check mechanism (X86, ARM, AArch64) or
or the dispatch mechanism (X86-64). The check mechanism requires a new calling
convention for the supported targets. The dispatch mechanism adds the target as
an operand bundle, which is processed by SelectionDAG. Another pass
(CodeGen/CFGuardLongjmp.cpp) identifies and emits valid longjmp targets, as
required by /guard:cf. This feature is enabled using the `cfguard` CC1 option.

Reviewers: thakis, rnk, theraven, pcc

Subscribers: ychen, hans, metalcanine, dmajor, tomrittervg, alex, mehdi_amini, mgorny, javed.absar, kristof.beyls, hiraditya, steven_wu, dexonsmith, cfe-commits, llvm-commits

Tags: #clang, #llvm

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

show more ...

OpenMP: Add helper function for convergent runtime calls

Most of the functions emitted here should probably be convergent, but
only barriers are currently marked. Introduce this helper before
adding

OpenMP: Add helper function for convergent runtime calls

Most of the functions emitted here should probably be convergent, but
only barriers are currently marked. Introduce this helper before
adding convergent to more functions.

show more ...