Commit Graph

2597 Commits

Author SHA1 Message Date
Nathan James
b091af790f
[ASTMatchers] Made isExpandedFromMacro Polymorphic
Made the isExpandedFromMacro matcher work on Stmt's, TypeLocs and Decls in line with the other macro expansion matchers.
Also tweaked it to take a `std::string` instead of a `StringRef`.
This prevents potential use-after-free bugs if the matcher is created with a string thats destroyed before the matcher finishes matching.

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D90303
2020-11-03 14:36:51 +00:00
Fangrui Song
0d4e1729e3 [docs] Fix clang/docs/UsersManual.rst after D87528 & D88446 2020-11-02 21:07:15 -08:00
Serge Pavlov
6021cbea4d Add option 'exceptions' to pragma clang fp
Pragma 'clang fp' is extended to support a new option, 'exceptions'. It
allows to specify floating point exception behavior more flexibly.

Differential Revision: https://reviews.llvm.org/D89849
2020-10-31 17:36:12 +07:00
Liu, Chen3
756f597841 [X86] Support Intel avxvnni
This patch mainly made the following changes:

1. Support AVX-VNNI instructions;
2. Introduce ExplicitVEXPrefix flag so that vpdpbusd/vpdpbusds/vpdpbusds/vpdpbusds instructions only use vex-encoding when user explicity add {vex} prefix.

Differential Revision: https://reviews.llvm.org/D89105
2020-10-31 12:39:51 +08:00
Peter Collingbourne
c9b1a2b41d AArch64: Use SBFX instead of UBFX to extract address granule in outlined HWASan checks.
In a kernel (or in general in environments where bit 55 of the address
is set) the shadow base needs to point to the end of the shadow region,
not the beginning. Bit 55 needs to be sign extended into bits 52-63
of the shadow base offset, otherwise we end up loading from an invalid
address. We can do this by using SBFX instead of UBFX.

Using SBFX should have no effect in the userspace case where bit 55
of the address is clear so we do so unconditionally. I don't think
we need a ABI version bump for this (but one will come anyway when
we switch to x20 for the shadow base register).

Differential Revision: https://reviews.llvm.org/D90424
2020-10-30 12:53:15 -07:00
Peter Collingbourne
3859fc653f AArch64: Switch to x20 as the shadow base register for outlined HWASan checks.
From a code size perspective it turns out to be better to use a
callee-saved register to pass the shadow base. For non-leaf functions
it avoids the need to reload the shadow base into x9 after each
function call, at the cost of an additional stack slot to save the
caller's x20. But with x9 there is also a stack size cost, either
as a result of copying x9 to a callee-saved register across calls or
by spilling it to stack, so for the non-leaf functions the change to
stack usage is largely neutral.

It is also code size (and stack size) neutral for many leaf functions.
Although they now need to save/restore x20 this can typically be
combined via LDP/STP into the x30 save/restore. In the case where
the function needs callee-saved registers or stack spills we end up
needing, on average, 8 more bytes of stack and 1 more instruction
but given the improvements to other functions this seems like the
right tradeoff.

Unfortunately we cannot change the register for the v1 (non short
granules) check because the runtime assumes that the shadow base
register is stored in x9, so the v1 check still uses x9.

Aside from that there is no change to the ABI because the choice
of shadow base register is a contract between the caller and the
outlined check function, both of which are compiler generated. We do
need to rename the v2 check functions though because the functions
are deduplicated based on their names, not on their contents, and we
need to make sure that when object files from old and new compilers
are linked together we don't end up with a function that uses x9
calling an outlined check that uses x20 or vice versa.

With this change code size of /system/lib64/*.so in an Android build
with HWASan goes from 200066976 bytes to 194085912 bytes, or a 3%
decrease.

Differential Revision: https://reviews.llvm.org/D90422
2020-10-30 12:51:30 -07:00
Tony
661797bd76 [AMDGPU] Update AMD GPU documentation
- AMDGPUUsage.rst: Correct AMD GPU DWARF address space table address
  sizes which are in bits and not bytes.

- clang/.../Options.td: Improve description of AMD GPU options.

- Re-generate ClangComamndLineReference.rst from clang/.../Options.td .

Differential Revision: https://reviews.llvm.org/D90364
2020-10-29 20:12:47 +00:00
Melanie Blower
2e204e2391 [clang] Enable support for #pragma STDC FENV_ACCESS
Reviewers: rjmccall, rsmith, sepavloff

Differential Revision: https://reviews.llvm.org/D87528
2020-10-25 06:46:25 -07:00
Benjamin Kramer
39a0d6889d [X86] Add a stub for Intel's alderlake.
No scheduling, no autodetection.
2020-10-24 19:01:22 +02:00
Tianqing Wang
be39a6fe6f [X86] Add User Interrupts(UINTR) instructions
For more details about these instructions, please refer to the latest
ISE document:
https://software.intel.com/en-us/download/intel-architecture-instruction-set-extensions-programming-reference.

Reviewed By: craig.topper

Differential Revision: https://reviews.llvm.org/D89301
2020-10-22 17:33:07 +08:00
Wang, Pengfei
e32036b973 [X86] Add clang release notes for HRESET and minor change for llvm release notes. (NFC) 2020-10-21 15:59:42 +08:00
Alex Richardson
9e27f38354 [clang-format] Add a SpaceAroundPointerQualifiers style option
Some projects (e.g. FreeBSD) align pointers to the right but expect a
space between the '*' and any pointer qualifiers such as const. To handle
these cases this patch adds a new config option SpaceAroundPointerQualifiers
that can be used to configure whether spaces need to be added before/after
pointer qualifiers.

PointerAlignment = Right
SpaceAroundPointerQualifiers = Default/After:
void *const *x = NULL;
SpaceAroundPointerQualifiers = Before/Both
void * const *x = NULL;

PointerAlignment = Left
SpaceAroundPointerQualifiers = Default/Before:
void* const* x = NULL;
SpaceAroundPointerQualifiers = After/Both
void* const * x = NULL;

PointerAlignment = Middle
SpaceAroundPointerQualifiers = Default/Before/After/Both:
void * const * x = NULL;

Reviewed By: MyDeveloperDay

Differential Revision: https://reviews.llvm.org/D88227
2020-10-18 18:17:50 +01:00
Mark de Wever
2bcda6bb28 [Sema, CodeGen] Implement [[likely]] and [[unlikely]] in SwitchStmt
This implements the likelihood attribute for the switch statement. Based on the
discussion in D85091 and D86559 it only handles the attribute when placed on
the case labels or the default labels.

It also marks the likelihood attribute as feature complete. There are more QoI
patches in the pipeline.

Differential Revision: https://reviews.llvm.org/D89210
2020-10-18 13:48:42 +02:00
Richard Smith
552c6c2328 PR44406: Follow behavior of array bound constant folding in more recent versions of GCC.
Old GCC used to aggressively fold VLAs to constant-bound arrays at block
scope in GNU mode. That's non-conforming, and more modern versions of
GCC only do this at file scope. Update Clang to do the same.

Also promote the warning for this from off-by-default to on-by-default
in all cases; more recent versions of GCC likewise warn on this by
default.

This is still slightly more permissive than GCC, as pointed out in
PR44406, as we still fold VLAs to constant arrays in structs, but that
seems justifiable given that we don't support VLA-in-struct (and don't
intend to ever support it), but GCC does.

Differential Revision: https://reviews.llvm.org/D89523
2020-10-16 14:34:35 -07:00
Richard Smith
dd4e8a54b2 [docs] Fix some out-of-date / inaccurate text and missing formatting in the User's Manual. 2020-10-16 12:00:13 -07:00
Konstantin Zhuravlyov
3fdf3b1539 AMDGPU: Update AMDHSA code object version handling
Differential Revision: https://reviews.llvm.org/D89076
2020-10-14 13:04:27 -04:00
Konstantin Zhuravlyov
e2eaa91451 AMDGPU: Remove -mamdgpu-debugger-abi option
It has been unsupported for few years now.

Differential Revision: https://reviews.llvm.org/D89125
2020-10-13 12:20:28 -04:00
Alexandre Ganea
1dbf05f5b4 [ThinLTO][Documentation] Mention possible values for concurrency flags
Differential Revision: https://reviews.llvm.org/D89309
2020-10-13 09:57:58 -04:00
Wang, Pengfei
412cdcf2ed [X86] Add HRESET instruction.
For more details about these instructions, please refer to the latest ISE document: https://software.intel.com/en-us/download/intel-architecture-instruction-set-extensions-programming-reference.

Reviewed By: craig.topper

Differential Revision: https://reviews.llvm.org/D89102
2020-10-13 08:47:26 +08:00
Fangrui Song
012dd42e02 [X86] Support -march=x86-64-v[234]
PR47686. These micro-architecture levels are defined in the x86-64 psABI:

https://gitlab.com/x86-psABIs/x86-64-ABI/-/commit/77566eb03bc6a326811cb7e9

GCC 11 will support these levels.

Note, -mtune=x86-64-v[234] are invalid and __builtin_cpu_is cannot be
used on them.

Reviewed By: craig.topper, RKSimon

Differential Revision: https://reviews.llvm.org/D89197
2020-10-12 10:29:46 -07:00
John McCall
cec49a5836 Revert "[SYCL] Implement __builtin_unique_stable_name."
This reverts commit b5a034e771.

This feature was added without following the proper process.
2020-10-12 01:10:09 -04:00
Zinovy Nis
32d565b461 [clang-tidy] Fix crash in readability-function-cognitive-complexity on weak refs
Fix for https://bugs.llvm.org/show_bug.cgi?id=47779

Differential Revision: https://reviews.llvm.org/D89194
2020-10-11 18:52:38 +03:00
Konstantin Zhuravlyov
b581c5a42f Regenerate ClangCommandLineReference.rst
Differential Revision: https://reviews.llvm.org/D89091
2020-10-09 08:29:53 -04:00
diggerlin
92bca12843 [AIX] add new option -mignore-xcoff-visibility
SUMMARY:

In IBM compiler xlclang , there is an option -fnovisibility which suppresses visibility. For more details see: https://www.ibm.com/support/knowledgecenter/SSGH3R_16.1.0/com.ibm.xlcpp161.aix.doc/compiler_ref/opt_visibility.html.

We need to add the option -mignore-xcoff-visibility for compatibility with the IBM AIX OS (as the option is enabled by default in AIX). With this option llvm does not emit any visibility attribute to ASM or XCOFF object file.

The option only work on the AIX OS, for other non-AIX OS using the option will report an unsupported options error.

In AIX OS:

1.1  the option -mignore-xcoff-visibility is enabled by default , if there is not -fvisibility=* and -mignore-xcoff-visibility explicitly in the clang command .

1.2 if there is -fvisibility=* explicitly but not -mignore-xcoff-visibility  explicitly in the clang command.  it will generate visibility attributes.

1.3 if there are  both  -fvisibility=* and  -mignore-xcoff-visibility  explicitly in the clang command. The option  "-mignore-xcoff-visibility" wins , it do not emit the visibility attribute.

The option -mignore-xcoff-visibility has no effect on visibility attribute when compile with -emit-llvm option to generated LLVM IR.

Reviewer: daltenty,Jason Liu

Differential Revision: https://reviews.llvm.org/D87451
2020-10-08 09:34:58 -04:00
Saleem Abdulrasool
85d5064000 docs: add documentation describing API Notes
API Notes are a feature which allows annotation of headers by an
auxiliary file that contains metadata for declarations pertaining to the
associated module.  This enables adding attributes to declarations
without requiring modification of the headers, enabling finer grained
control for library headers for consumers without having to modify
external headers.

Differential Revision: https://reviews.llvm.org/D88446
Reviewed By: Richard Smith, Marcel Hlopko
2020-10-05 18:29:13 +00:00
Evgenii Stepanov
66cf68ed46 [docs] Update ControlFlowIntegrity.rst.
Expand the list of targets that support cfi-icall.
Add ThinLTO everywhere LTO is mentioned. AFAIK all CFI features are
supported with ThinLTO.

Differential Revision: https://reviews.llvm.org/D87717
2020-10-02 12:01:05 -07:00
Fangrui Song
3681be876f Add -fprofile-update={atomic,prefer-atomic,single}
GCC 7 introduced -fprofile-update={atomic,prefer-atomic} (prefer-atomic is for
best efforts (some targets do not support atomics)) to increment counters
atomically, which is exactly what we have done with -fprofile-instr-generate
(D50867) and -fprofile-arcs (b5ef137c11).
This patch adds the option to clang to surface the internal options at driver level.

GCC 7 also turned on -fprofile-update=prefer-atomic when -pthread is specified,
but it has performance regression
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89307). So we don't follow suit.

Differential Revision: https://reviews.llvm.org/D87737
2020-09-29 10:43:23 -07:00
Russell Yanofsky
f702a6fa7c Thread safety analysis: Improve documentation for ASSERT_CAPABILITY
Previous description didn't actually state the effect the attribute has on
thread safety analysis (causing analysis to assume the capability is held).

Previous description was also ambiguous about (or slightly overstated) the
noreturn assumption made by thread safety analysis, implying the assumption had
to be true about the function's behavior in general, and not just its behavior
in places where it's used. Stating the assumption specifically should avoid a
perceived need to disable thread safety analysis in places where only asserting
that a specific capability is held would be better.

Reviewed By: aaronpuchert, vasild

Differential Revision: https://reviews.llvm.org/D87629
2020-09-26 22:16:50 +02:00
Vedant Kumar
62c372770d [profile] Add %t LLVM_PROFILE_FILE option to substitute $TMPDIR
Add support for expanding the %t filename specifier in LLVM_PROFILE_FILE
to the TMPDIR environment variable. This is supported on all platforms.

On Darwin, TMPDIR is used to specify a temporary application-specific
scratch directory. When testing apps on remote devices, it can be
challenging for the host device to determine the correct TMPDIR, so it's
helpful to have the runtime do this work.

rdar://68524185

Differential Revision: https://reviews.llvm.org/D87332
2020-09-25 09:39:40 -07:00
Jonas Toth
4e53490047 [NFC][Docs] fix clang-docs compilation 2020-09-24 13:13:38 +02:00
YangZhihui
1d1c382ed2 Fix typos in ASTMatchers.h; NFC 2020-09-23 09:09:11 -04:00
Jan Korous
8a64689e26 [Analyzer][WebKit] UncountedLocalVarsChecker
Differential Review: https://reviews.llvm.org/D83259
2020-09-22 11:05:04 -07:00
Joachim Meyer
f64903fd81 Add -Wno-error=unknown flag to clang-format.
Currently newer clang-format options cannot be included in .clang-format files, if not all users can be forced to use an updated version.
This patch tries to solve this by adding an option to clang-format, enabling to ignore unknown (newer) options.

Differential Revision: https://reviews.llvm.org/D86137
2020-09-19 10:17:57 +02:00
mydeveloperday
2e7add812e [clang-format] Add a option for the position of Java static import
Some Java style guides and IDEs group Java static imports after
 non-static imports. This patch allows clang-format to control
 the location of static imports.

Patch by: @bc-lee

Reviewed By: MyDeveloperDay, JakeMerdichAMD

Differential Revision: https://reviews.llvm.org/D87201
2020-09-18 18:12:21 +01:00
Jessica Clarke
788c7d2ec1 [clang][docs] Fix documentation of -O
D79916 changed the behaviour from -O2 to -O1 but the documentation was
not updated to reflect this.
2020-09-17 13:44:01 +01:00
mydeveloperday
4dd9c709ef [clang-format] [NFC] Fix spelling mistake in the documentation
Ensure ClangFormatStyleOptions.rst can be regenerated from Format.h

Patch By: YangZhihui

Reviewed By: MyDeveloperDay

Differential Revision: https://reviews.llvm.org/D87352
2020-09-16 13:46:34 +01:00
Jonas Toth
69f98311ca [ASTMatchers] extract public matchers from const-analysis into own patch
The analysis for const-ness of local variables required a view generally useful
matchers that are extracted into its own patch.

They are decompositionDecl and forEachArgumentWithParamType, that works
for calls through function pointers as well.

This is a reupload of https://reviews.llvm.org/D72505, that already landed,
but had to be reverted due to a GCC crash on powerpc
(https://reviews.llvm.org/rG4c48ea68e491cb42f1b5d43ffba89f6a7f0dadc4)

Because this took a long time to adress, i decided to redo this patch and
have a clean workflow.
I try to coordinate with someone that has a PPC to apply this patch and
test for the crash. If everything is fine, I intend to just commit.
If the crash is still happening, i hope to at least find the cause.

Differential Revision: https://reviews.llvm.org/D87588
2020-09-15 21:07:30 +02:00
Kristóf Umann
dd1d5488e4 [analyzer][Liveness][NFC] Get rid of statement liveness, because such a thing doesn't exist
The summary and very short discussion in D82122 summarizes whats happening here.

In short, liveness talks about variables, or expressions, anything that
has a value. Well, statements just simply don't have a one.

Differential Revision: https://reviews.llvm.org/D82598
2020-09-15 17:43:02 +02:00
Kristóf Umann
7c6f5b7fbf [analyzer] Add documentation for alpha.fuchsia.Lock and alpha.core.C11Lock
Differential Revision: https://reviews.llvm.org/D86532
2020-09-15 16:55:44 +02:00
Rahman Lavaee
7841e21c98 Let -basic-block-sections=labels emit basicblock metadata in a new .bb_addr_map section, instead of emitting special unary-encoded symbols.
This patch introduces the new .bb_addr_map section feature which allows us to emit the bits needed for mapping binary profiles to basic blocks into a separate section.
The format of the emitted data is represented as follows. It includes a header for every function:

|  Address of the function                      |  -> 8 bytes (pointer size)
|  Number of basic blocks in this function (>0) |  -> ULEB128

The header is followed by a BB record for every basic block. These records are ordered in the same order as MachineBasicBlocks are placed in the function. Each BB Info is structured as follows:

|  Offset of the basic block relative to function begin |  -> ULEB128
|  Binary size of the basic block                       |  -> ULEB128
|  BB metadata                                          |  -> ULEB128  [ MBB.isReturn() OR MBB.hasTailCall() << 1  OR  MBB.isEHPad() << 2 ]

The new feature will replace the existing "BB labels" functionality with -basic-block-sections=labels.
The .bb_addr_map section scrubs the specially-encoded BB symbols from the binary and makes it friendly to profilers and debuggers.
Furthermore, the new feature reduces the binary size overhead from 70% bloat to only 12%.

For more information and results please refer to the RFC: https://lists.llvm.org/pipermail/llvm-dev/2020-July/143512.html

Reviewed By: MaskRay, snehasish

Differential Revision: https://reviews.llvm.org/D85408
2020-09-14 10:16:44 -07:00
Travis Finkenauer
0fb2203cd6 [Docs] Fix --print-supported-cpus option rendering
Adds link/code sample to avoid rendering two dashes as non-ASCII "en dash".
Also make wording a complete sentence.

Reviewed By: nickdesaulniers, tmfink

Differential Revision: https://reviews.llvm.org/D85596
2020-09-13 05:26:18 +00:00
Guillaume Chatelet
b8ea47a380
Uncapitalize word in LanguageExtensions.rst 2020-09-11 10:08:02 +02:00
Guillaume Chatelet
e38be7091e [Clang] Clarify __builtin_memcpy_inline documentation
This patch updates the documentation about `__builtin_memcpy_inline` and reorders the sections so it is more consitent and understandable.

Differential Revision: https://reviews.llvm.org/D87458
2020-09-11 07:20:39 +00:00
Guillaume Chatelet
05d02e5a4e Fix invalid link format in Clang LanguageExtension 2020-09-10 12:27:50 +00:00
Alex Richardson
e7bd058c7e [clang-format] Allow configuring list of macros that map to attributes
This adds a `AttributeMacros` configuration option that causes certain
identifiers to be parsed like a __attribute__((foo)) annotation.
This is motivated by our CHERI C/C++ fork which adds a __capability
qualifier for pointer/reference. Without this change clang-format parses
many type declarations as multiplications/bitwise-and instead.
I initially considered adding "__capability" as a new clang-format keyword,
but having a list of macros that should be treated as attributes is more
flexible since it can be used e.g. for static analyzer annotations or other language
extensions.

Example: std::vector<foo * __capability> -> std::vector<foo *__capability>

Depends on D86775 (to apply cleanly)

Reviewed By: MyDeveloperDay, jrtc27

Differential Revision: https://reviews.llvm.org/D86782
2020-09-07 10:09:17 +01:00
Aaron Puchert
bbb3baf620 Thread safety analysis: Improve documentation for scoped capabilities
They are for more powerful than the current documentation implies, this
adds

* adopting a lock,
* deferring a lock,
* manually unlocking the scoped capability,
* relocking the scoped capability, possibly in a different mode,
* try-relocking the scoped capability.

Also there is now a generic explanation how attributes on scoped
capabilities work. There has been confusion in the past about how to
annotate them (see e.g. PR33504), hopefully this clears things up.

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D87066
2020-09-06 20:37:42 +02:00
Aaron Puchert
cc6713a2c3 Thread safety analysis: Test and document release_generic_capability
The old locking attributes had a generic release, but as it turns out
the capability-based attributes have it as well.

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D87064
2020-09-06 20:37:41 +02:00
Aaron Puchert
8544defdcb Thread safety analysis: Document how try-acquire is handled
I don't think this is obvious, since try-acquire seemingly contradicts
our usual requirements of "no conditional locking".

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D87065
2020-09-05 14:26:43 +02:00
Akira Hatanaka
64bb582f4a Fix the type of the invoke function in the block ABI documentation
rdar://problem/67892794
2020-09-04 10:29:09 -07:00
Jan Korous
c9239b2bf5 [Analyzer][docs][NFC] Fix typo in code example 2020-09-03 09:28:34 -07:00