Revert "[asan] Add support for disable_sanitizer_instrumentation attribute"

This reverts commit dd145f953db3dafbc019f1d3783bb4f09a28af92.

https://reviews.llvm.org/D119726, like https://reviews.llvm

Revert "[asan] Add support for disable_sanitizer_instrumentation attribute"

This reverts commit dd145f953db3dafbc019f1d3783bb4f09a28af92.

https://reviews.llvm.org/D119726, like https://reviews.llvm.org/D114421,
still causes TSan to fail, see https://lab.llvm.org/buildbot/#/builders/70/builds/18020

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

show more ...

[asan] Add support for disable_sanitizer_instrumentation attribute

For ASan this will effectively serve as a synonym for
__attribute__((no_sanitize("address")))

This is a reland of https://reviews.

[asan] Add support for disable_sanitizer_instrumentation attribute

For ASan this will effectively serve as a synonym for
__attribute__((no_sanitize("address")))

This is a reland of https://reviews.llvm.org/D114421

Reviewed By: melver, eugenis

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

show more ...

[X86] Implement -fzero-call-used-regs option

The "-fzero-call-used-regs" option tells the compiler to zero out
certain registers before the function returns. It's also available as a
function attrib

[X86] Implement -fzero-call-used-regs option

The "-fzero-call-used-regs" option tells the compiler to zero out
certain registers before the function returns. It's also available as a
function attribute: zero_call_used_regs.

The two upper categories are:

- "used": Zero out used registers.
- "all": Zero out all registers, whether used or not.

The individual options are:

- "skip": Don't zero out any registers. This is the default.
- "used": Zero out all used registers.
- "used-arg": Zero out used registers that are used for arguments.
- "used-gpr": Zero out used registers that are GPRs.
- "used-gpr-arg": Zero out used GPRs that are used as arguments.
- "all": Zero out all registers.
- "all-arg": Zero out all registers used for arguments.
- "all-gpr": Zero out all GPRs.
- "all-gpr-arg": Zero out all GPRs used for arguments.

This is used to help mitigate Return-Oriented Programming exploits.

Reviewed By: nickdesaulniers

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

show more ...

[clang-cl] Support the /HOTPATCH flag

This patch adds support for the MSVC /HOTPATCH flag: https://docs.microsoft.com/sv-se/cpp/build/reference/hotpatch-create-hotpatchable-image?view=msvc-170&viewF

[clang-cl] Support the /HOTPATCH flag

This patch adds support for the MSVC /HOTPATCH flag: https://docs.microsoft.com/sv-se/cpp/build/reference/hotpatch-create-hotpatchable-image?view=msvc-170&viewFallbackFrom=vs-2019

The flag is translated to a new -fms-hotpatch flag, which in turn adds a 'patchable-function' attribute for each function in the TU. This is then picked up by the PatchableFunction pass which would generate a TargetOpcode::PATCHABLE_OP of minsize = 2 (which means the target instruction must resolve to at least two bytes). TargetOpcode::PATCHABLE_OP is only implemented for x86/x64. When targetting ARM/ARM64, /HOTPATCH isn't required (instructions are always 2/4 bytes and suitable for hotpatching).

Additionally, when using /Z7, we generate a 'hot patchable' flag in the CodeView debug stream, in the S_COMPILE3 record. This flag is then picked up by LLD (or link.exe) and is used in conjunction with the linker /FUNCTIONPADMIN flag to generate extra space before each function, to accommodate for live patching long jumps. Please see: https://github.com/llvm/llvm-project/blob/d703b922961e0d02a5effdd4bfbb23ad50a3cc9f/lld/COFF/Writer.cpp#L1298

The outcome is that we can finally use Live++ or Recode along with clang-cl.

NOTE: It seems that MSVC cl.exe always enables /HOTPATCH on x64 by default, although if we did the same I thought we might generate sub-optimal code (if this flag was active by default). Additionally, MSVC always generates a .debug$S section and a S_COMPILE3 record, which Clang doesn't do without /Z7. Therefore, the following MSVC command-line "cl /c file.cpp" would have to be written with Clang such as "clang-cl /c file.cpp /HOTPATCH /Z7" in order to obtain the same result.

Depends on D43002, D80833 and D81301 for the full feature.

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

show more ...

[clang][CodeGen][UBSan] VLA size checking for unsigned integer parameter

The code generation for the UBSan VLA size check was qualified by a con-
dition that the parameter must be a signed integer,

[clang][CodeGen][UBSan] VLA size checking for unsigned integer parameter

The code generation for the UBSan VLA size check was qualified by a con-
dition that the parameter must be a signed integer, however the C spec
does not make any distinction that only signed integer parameters can be
used to declare a VLA, only qualifying that it must be greater than zero
if it is not a constant.

Reviewed By: rjmccall

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

show more ...

[CodeGen] Avoid deprecated Address constructor

[clang] Use true/false instead of 1/0 (NFC)

Identified with modernize-use-bool-literals.

[clang] Use nullptr instead of 0 or NULL (NFC)

Identified with modernize-use-nullptr.

[CodeGen] Avoid pointer element type access when creating LValue

This required fixing two places that were passing the pointer type
rather than the expected pointee type to the method.

[CodeGen] Avoid some pointer element type accesses

This avoids some pointer element type accesses when compiling
C++ code.

Reland "[AST] Add UsingType: a sugar type for types found via UsingDecl"

This reverts commit cc56c66f27e131b914082d3bd21180646e842e9a.
Fixed a bad assertion, the target of a UsingShadowDecl must not

Reland "[AST] Add UsingType: a sugar type for types found via UsingDecl"

This reverts commit cc56c66f27e131b914082d3bd21180646e842e9a.
Fixed a bad assertion, the target of a UsingShadowDecl must not have
*local* qualifiers, but it can be a typedef whose underlying type is qualified.

show more ...

Revert "[AST] Add UsingType: a sugar type for types found via UsingDecl"

This reverts commit e1600db19d6303f84b995acb9340459694e06ea9.

Breaks sanitizer tests, at least on windows:
https://lab.llvm.

Revert "[AST] Add UsingType: a sugar type for types found via UsingDecl"

This reverts commit e1600db19d6303f84b995acb9340459694e06ea9.

Breaks sanitizer tests, at least on windows:
https://lab.llvm.org/buildbot/#/builders/127/builds/21592/steps/4/logs/stdio

show more ...

[AST] Add UsingType: a sugar type for types found via UsingDecl

Currently there's no way to find the UsingDecl that a typeloc found its
underlying type through. Compare to DeclRefExpr::getFoundDecl(

[AST] Add UsingType: a sugar type for types found via UsingDecl

Currently there's no way to find the UsingDecl that a typeloc found its
underlying type through. Compare to DeclRefExpr::getFoundDecl().

Design decisions:
- a sugar type, as there are many contexts this type of use may appear in
- UsingType is a leaf like TypedefType, the underlying type has no TypeLoc
- not unified with UnresolvedUsingType: a single name is appealing,
but being sometimes-sugar is often fiddly.
- not unified with TypedefType: the UsingShadowDecl is not a TypedefNameDecl or
even a TypeDecl, and users think of these differently.
- does not cover other rarer aliases like objc @compatibility_alias,
in order to be have a concrete API that's easy to understand.
- implicitly desugared by the hasDeclaration ASTMatcher, to avoid
breaking existing patterns and following the precedent of ElaboratedType.

Scope:
- This does not cover types associated with template names introduced by
using declarations. A future patch should introduce a sugar TemplateName
variant for this. (CTAD deduced types fall under this)
- There are enough AST matchers to fix the in-tree clang-tidy tests and
probably any other matchers, though more may be useful later.

Caveats:
- This changes a fairly common pattern in the AST people may depend on matching.
Previously, typeLoc(loc(recordType())) matched whether a struct was
referred to by its original scope or introduced via using-decl.
Now, the using-decl case is not matched, and needs a separate matcher.
This is similar to the case of typedefs but nevertheless both adds
complexity and breaks existing code.

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

show more ...

[CodeGen] Fix element type for sret argument

Fix a mistake in 9bf917394eba3ba4df77cc17690c6d04f4e9d57f: sret
arguments use ConvertType, not ConvertTypeForMem, see the handling
in CodeGenTypes::GetFu

[CodeGen] Fix element type for sret argument

Fix a mistake in 9bf917394eba3ba4df77cc17690c6d04f4e9d57f: sret
arguments use ConvertType, not ConvertTypeForMem, see the handling
in CodeGenTypes::GetFunctionType().

This fixes fp-matrix-pragma.c on s390x.

show more ...

[CodeGen] Avoid more pointer element type accesses

[clang] Cleanup unneeded Function nullptr checks [NFC]

Add an assert and avoid unneeded checks of Fn in
CodeGenFunction::GenerateCode.

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

Revert "[asan] Add support for disable_sanitizer_instrumentation attribute"

This reverts commit 2b554920f11c8b763cd9ed9003f4e19b919b8e1f.

This change causes tsan test timeout on x86_64-linux-autoco

Revert "[asan] Add support for disable_sanitizer_instrumentation attribute"

This reverts commit 2b554920f11c8b763cd9ed9003f4e19b919b8e1f.

This change causes tsan test timeout on x86_64-linux-autoconf.

The timeout can be reproduced by:
git clone https://github.com/llvm/llvm-zorg.git
BUILDBOT_CLOBBER= BUILDBOT_REVISION=eef8f3f85679c5b1ae725bade1c23ab7bb6b924f llvm-zorg/zorg/buildbot/builders/sanitizers/buildbot_standard.sh

show more ...

[asan] Add support for disable_sanitizer_instrumentation attribute

For ASan this will effectively serve as a synonym for
__attribute__((no_sanitize("address")))

Differential Revision: https://revie

[asan] Add support for disable_sanitizer_instrumentation attribute

For ASan this will effectively serve as a synonym for
__attribute__((no_sanitize("address")))

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

show more ...

Introduce _BitInt, deprecate _ExtInt

WG14 adopted the _ExtInt feature from Clang for C23, but renamed the
type to be _BitInt. This patch does the vast majority of the work to
rename _ExtInt to _BitI

Introduce _BitInt, deprecate _ExtInt

WG14 adopted the _ExtInt feature from Clang for C23, but renamed the
type to be _BitInt. This patch does the vast majority of the work to
rename _ExtInt to _BitInt, which accounts for most of its size. The new
type is exposed in older C modes and all C++ modes as a conforming
extension. However, there are functional changes worth calling out:

* Deprecates _ExtInt with a fix-it to help users migrate to _BitInt.
* Updates the mangling for the type.
* Updates the documentation and adds a release note to warn users what
is going on.
* Adds new diagnostics for use of _BitInt to call out when it's used as
a Clang extension or as a pre-C23 compatibility concern.
* Adds new tests for the new diagnostic behaviors.

I want to call out the ABI break specifically. We do not believe that
this break will cause a significant imposition for early adopters of
the feature, and so this is being done as a full break. If it turns out
there are critical uses where recompilation is not an option for some
reason, we can consider using ABI tags to ease the transition.

show more ...

[CFE][Codegen] Make sure to maintain the contiguity of all the static allocas

at the start of the entry block, which in turn would aid better code transformation/optimization.

Reviewed By: rnk

Dif

[CFE][Codegen] Make sure to maintain the contiguity of all the static allocas

at the start of the entry block, which in turn would aid better code transformation/optimization.

Reviewed By: rnk

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

show more ...

Fix inline builtin handling in case of redefinition

Basically, inline builtin definition are shadowed by externally visible
redefinition. This matches GCC behavior.

The implementation has to workar

Fix inline builtin handling in case of redefinition

Basically, inline builtin definition are shadowed by externally visible
redefinition. This matches GCC behavior.

The implementation has to workaround the fact that:

1. inline builtin are renamed at callsite during codegen, but
2. they may be shadowed by a later external definition

As a consequence, during codegen, we need to walk redecls and eventually rewrite
some call sites, which is totally inelegant.

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

show more ...

[clang] Use StringRef::contains (NFC)

[CFE][Codegen][In-progress] Remove CodeGenFunction::InitTempAlloca()

CodeGenFunction::InitTempAlloca() inits the static alloca within the
entry block which may *not* necessarily be correct always.

[CFE][Codegen][In-progress] Remove CodeGenFunction::InitTempAlloca()

CodeGenFunction::InitTempAlloca() inits the static alloca within the
entry block which may *not* necessarily be correct always.

For example, the current instruction insertion point (pointed by the
instruction builder) could be a program point which is hit multiple
times during the program execution, and it is expected that the static
alloca is initialized every time the program point is hit.

Hence remove CodeGenFunction::InitTempAlloca(), and initialize the
static alloca where the instruction insertion point is at the moment.

This patch, as a starting attempt, removes the calls to
CodeGenFunction::InitTempAlloca() which do not have any side effect on
the lit tests.

Reviewed By: rjmccall

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

show more ...

Update inline builtin handling to honor gnu inline attribute

Per the GCC info page:

If the function is declared 'extern', then this definition of the
function is used only for inlining. In

Update inline builtin handling to honor gnu inline attribute

Per the GCC info page:

If the function is declared 'extern', then this definition of the
function is used only for inlining. In no case is the function
compiled as a standalone function, not even if you take its address
explicitly. Such an address becomes an external reference, as if
you had only declared the function, and had not defined it.

Respect that behavior for inline builtins: keep the original definition, and
generate a copy of the declaration suffixed by '.inline' that's only referenced
in direct call.

This fixes holes in c3717b6858d32d64514a187ede1a77be8ba4e542.

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

show more ...

Simplify handling of builtin with inline redefinition

(This is a recommit of 3d6f49a56995b845 that should no longer break validation since
bd379915de38a9af3d65e1).

It is a common practice in glibc

Simplify handling of builtin with inline redefinition

(This is a recommit of 3d6f49a56995b845 that should no longer break validation since
bd379915de38a9af3d65e1).

It is a common practice in glibc header to provide an inline redefinition of an
existing function. It is especially the case for fortified function.

Clang currently has an imperfect approach to the problem, using a combination of
trivially recursive function detection and noinline attribute.

Simplify the logic by suffixing these functions by `.inline` during codegen, so
that they are not recognized as builtin by llvm.

After that patch, clang passes all tests from https://github.com/serge-sans-paille/fortify-test-suite

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

show more ...