Clang was incorrectly finding the start of the exponent in a fixed point
hex literal. It would unconditionally find the first `e/E/p/P` in a
constant regardless of if it were hex or not and parser the remaining
digits as an APInt. In a debug build, this would be caught by an
assertion, but in a release build, the assertion is removed and we'd end
up in an infinite loop.
Fixes#83050
Similar to d39b4ce3ce
Using "eabi" or "gnueabi" for aarch64 targets is a common mistake and
warned by Clang Driver. We want to avoid them elsewhere as well. Just
use the common "aarch64" without other triple components.
Updated the error message to use the proper prefix when
no expected directives are found by changing the hard coded expected in
the message to a dynamic value in two error messages.
Fixes#58290
Followup for https://github.com/llvm/llvm-project/pull/75373
1. Make this feature not just available for android, but everyone.
2. Correct some target triples.
3. Add opencl to the environment type list.
Add some primitive syntax highlighting to our code snippet output.
This adds "checkpoints" to the Preprocessor, which we can use to start lexing from. When printing a code snippet, we lex from the nearest checkpoint and highlight the tokens based on their token type.
Prior to this commit, it was impossible to use the simple string
matching directives to look for any content that contains unbalanced
`{{` `}}` pairs, such as:
```
// expected-note {{my_struct{{1}, 2}}}
```
Which would parse like so:
```
"nested" brace v
// expected-note {{my_struct{{1}, 2}}}
closes the nested brace ^ |
trailing }
```
And the frontend would complain 'cannot find end ('}}') of expected'.
At this snapshot, VerifyDiagnosticConsumer's parser now counts the
opening braces and looks for a matching length of closing sigils,
allowing the above to be written as:
```
// expected-note {{{my_struct{{1}, 2}}}}
opening brace |-| |-|
closing brace is '}}}', found here ^
```
This came about as a result of this discussion:
https://github.com/llvm/llvm-project/pull/74852#discussion_r1443117644
cc @erichkeane
Since Knight Landing and Knight Mill microarchitectures are EOL, we
would like to remove intrinsic supports for its specific ISA in LLVM 19.
In LLVM 18, we will first emit a warning for the usage.
`-arch` is a Darwin-specific option that is ignored for other targets
and not known by GCC.
```
% clang -arch arm64 -c a.c
clang: warning: argument unused during compilation: '-arch arm64' [-Wunused-command-line-argument]
```
We are utilizing TargetSpecific (from https://reviews.llvm.org/D151590)
to make more options lead to errors for unsupported targets.
Prior to this, clang would always report
```
compile with '-ffixed-point' to enable fixed point types
```
whenever it sees `_Accum`, `_Fract`, or `_Sat` when fixed point
arithmetic is not enabled. This can break existing code that uses these
as variable names and doesn't use fixed point arithmetic like in some
microsoft headers
(https://github.com/llvm/llvm-project/pull/67750#issuecomment-1775264907).
Fixed point should not raise this error for these cases, so this removes
the error altogether and defaults to the usual error clang gives where
it can see these keywords as either unknown types or regular variables.
This reverts commit 86bfeb906e.
This is a long time coming re-application that was originally reverted due to
regressions, unrelated to the actual inlining change. These regressions have since
been fixed due to another long-in-the-making change of a66051c6 landing.
Original commit message for reference:
---
We have several situations where it's beneficial for code size to ensure that every
call to always-inline functions are inlined before normal inlining decisions are
made. While the normal inliner runs in a "MandatoryOnly" mode to try to do this,
it only does it on a per-SCC basis, rather than the whole module. Ensuring that
all mandatory inlinings are done before any heuristic based decisions are made
just makes sense.
Despite being referred to the "legacy" AlwaysInliner pass, it's already necessary
for -O0 because the CGSCC inliner is too expensive in compile time to run at -O0.
This also fixes an exponential compile time blow up in
https://github.com/llvm/llvm-project/issues/59126
Differential Revision: https://reviews.llvm.org/D143624
---
The `-include "file"` option implicitly adds a leading #include
to the main source; however, there's no explicit #include, which
left -frewrite-includes emitting an unmatched #endif at the end
of the included text.
This corrects a bug in 4a16b51f.
This option will cause -E to preserve the #include directives
for system headers, rather than expanding them into the output.
This can greatly reduce the volume of preprocessed source text
in a test case, making test case reduction simpler.
Note that -fkeep-system-includes is not always appropriate. For
example, if the problem you want to reproduce is induced by a
system header file, it's better to expand those headers fully.
If your source defines symbols that influence the content of a
system header (e.g., _POSIX_SOURCE) then -E will eliminate the
definition, potentially changing the meaning of the preprocessed
source. If you use -isystem to point to non-system headers, for
example to suppress warnings in third-party software, those will
not be expanded and might make the preprocessed source less useful
as a test case.
The #if now has a conditional expression, so a user can add
`-D__CLANG_REWRITTEN_SYSTEM_INCLUDES` to include the system headers
instead of using the expanded content, or
`-D__CLANG_REWRITTEN_INCLUDES` to include all headers.
Also added the filename to the comments it emits, to help identify where
included text ends, making it easier to identify and remove the content of
individual headers.
After this D108637 and with FreeBSD -current and now 14 dropping support for
CloudABI I think it is time to consider deleting the CloudABI support.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D158920
We have a new policy in place making links to private resources
something we try to avoid in source and test files. Normally, we'd
organically switch to the new policy rather than make a sweeping change
across a project. However, Clang is in a somewhat special circumstance
currently: recently, I've had several new contributors run into rdar
links around test code which their patch was changing the behavior of.
This turns out to be a surprisingly bad experience, especially for
newer folks, for a handful of reasons: not understanding what the link
is and feeling intimidated by it, wondering whether their changes are
actually breaking something important to a downstream in some way,
having to hunt down strangers not involved with the patch to impose on
them for help, accidental pressure from asking for potentially private
IP to be made public, etc. Because folks run into these links entirely
by chance (through fixing bugs or working on new features), there's not
really a set of problematic links to focus on -- all of the links have
basically the same potential for causing these problems. As a result,
this is an omnibus patch to remove all such links.
This was not a mechanical change; it was done by manually searching for
rdar, radar, radr, and other variants to find all the various
problematic links. From there, I tried to retain or reword the
surrounding comments so that we would lose as little context as
possible. However, because most links were just a plain link with no
supporting context, the majority of the changes are simple removals.
Differential Review: https://reviews.llvm.org/D158071
As far as I can tell, there's nothing Windows-specific about the
test and it passes fine on other platforms.
I found this test when running
rg clang_cl clang/test | rg '%s' | rg -v -- ' -- ' | rg -v not
after 547ee1c81f to see if other tests were missing `--`
before `%s` in `%clang_cl` invocations. This was the only one.
Since it used to run only on Windows, it wasn't needed, but as far
as I can tell there's no reason to run it only on Windows.
Differential Revision: https://reviews.llvm.org/D158279
In code object 5 (https://llvm.org/docs/AMDGPUUsage.html#code-object-v5-metadata) the AMDGPU backend added the .uses_dynamic_stack bit to the kernel meta data to identity kernels which have compile time indeterminable stack usage (indirect function calls and recursion mainly). This patch adds this information to the output of the kernel-resource-usage remarks.
Reviewed By: arsenm
Differential Revision: https://reviews.llvm.org/D156040
Author: Corbin Robeck <corbin.robeck@amd.com>
When asking for -fdiagnostics-hotness-threshold, we currently require
-fdiagnostics-show-hotness otherwise we silently display nothing.
I don't see a scenario where that makes sense, so have one option impy
the other.
Differential Revision: https://reviews.llvm.org/D153746
A common user mistake is specifying a target of aarch64-none-eabi or
arm-none-elf whereas the correct names are aarch64-none-elf &
arm-none-eabi. Currently if a target of aarch64-none-eabi is specified
then the Generic_ELF toolchain is used, unlike aarch64-none-elf which
will use the BareMetal toolchain. This is unlikely to be intended by the
user so issue a warning that the target is invalid.
The target parser is liberal in what input it accepts so invalid triples
may yield behaviour that's sufficiently close to what the user intended.
Therefore invalid triples were used in many tests. This change updates
those tests to use valid triples.
One test (gnu-mcount.c) relies on the Generic_ELF toolchain behaviour so
change it to explicitly specify aarch64-unknown-none-gnu as the target.
Reviewed By: peter.smith, DavidSpickett
Differential Revision: https://reviews.llvm.org/D153430
`-H` displays a tree of included header files, but that tree is supposed
to omit two categories of header files:
1. Any header files pulled in via `-include`, which the code refers to
as the "predefines".
2. Any header files whose inclusion was skipped because they'd already
been included (assuming header guards or `#pragma once`).
`-fshow-skipped-includes` was intended to make `-H` display the second
category of files. It wasn't checking for the first category, however,
so you could end up with only the middle of the `-include` hierarchy
displayed, e.g. the added test would previously output:
```
... /data/users/smeenai/llvm-project/clang/test/Frontend/Inputs/test2.h
. /data/users/smeenai/llvm-project/clang/test/Frontend/Inputs/test.h
```
This diff adds a check to prevent that and correctly omit headers from
`-include` even when `-fshow-skipped-includes` is passed. While I'm
here, add tests for the interaction between `-fshow-skipped-includes`
and `-sys-header-deps` as well.
Reviewed By: hans
Differential Revision: https://reviews.llvm.org/D153175
This commit fixes "TextDiagnostic::emitIncludeLocation" when compiling
with "-fdiagnostics-absolute-paths" flag enabled by emitting the absolute
path of the included file.
Fixes#63026
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D151833
Show line numbers to the left of diagnostic code snippets and increase
the numbers of lines shown from 1 to 16.
Differential Revision: https://reviews.llvm.org/D147875
This is an ongoing series of commits that are reformatting our
Python code.
Reformatting is done with `black`.
If you end up having problems merging this commit because you
have made changes to a python file, the best way to handle that
is to run git checkout --ours <yourfile> and then reformat it
with black.
If you run into any problems, post to discourse about it and
we will try to help.
RFC Thread below:
https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style
Reviewed By: MatzeB
Differential Revision: https://reviews.llvm.org/D150761
Show line numbers to the left of diagnostic code snippets and increase
the numbers of lines shown from 1 to 16.
Differential Revision: https://reviews.llvm.org/D147875
We can now target the NVPTX architecture directly via
`--target=nvptx64-nvidia-cuda`. This currently does not define the
`__CUDA_ARCH__` macro with is used to allow code to target different
codes based on support. This patch simply adds this support.
Reviewed By: tra, jdoerfert
Differential Revision: https://reviews.llvm.org/D146975
ASMPrinter was relying on feature bits to setup extra SGRPs in the knerel
descriptor for the xnack_mask. This was broken for the dynamic XNACK "any" TID
setting which could cause user SGPRs to be clobbered if the number of SGPRs
reserved was near a granulated block boundary.
When XNACK was enabled this worked correctly in the ASMParser which meant some
kernels were only failing without "-save-temps".
Fixes: SWDEV-382764
Reviewed By: kzhuravl
Differential Revision: https://reviews.llvm.org/D145401
When using attributes by plugins (both in clang and clang-tidy) the
preprocessor functions `__has_attribute`, `__has_c_attribute`,
`__has_cpp_attribute` still returned 0.
That problem is fixed by having the "hasAttribute" function also check
if any of the plugins provide that attribute.
This also adds C2x spelling to the example plugin for attributes so that
`__has_c_attribute` can be tested.
Differential Revision: https://reviews.llvm.org/D144405
This seems to cause large regressions in existing code, as much as 75% slower
(4x the time taken). Small always inline functions seem to be used a lot in the
cmsis-dsp library.
I would add a phase ordering test to show the problems, but one already exists!
The llvm/test/Transforms/PhaseOrdering/ARM/arm_mult_q15.ll was just changed by
removing alwaysinline to hide the problems that existed.
This reverts commit cae033dcf2.
This reverts commit 8e33c41e72.
We have several situations where it's beneficial for code size to ensure that every
call to always-inline functions are inlined before normal inlining decisions are
made. While the normal inliner runs in a "MandatoryOnly" mode to try to do this,
it only does it on a per-SCC basis, rather than the whole module. Ensuring that
all mandatory inlinings are done before any heuristic based decisions are made
just makes sense.
Despite being referred to the "legacy" AlwaysInliner pass, it's already necessary
for -O0 because the CGSCC inliner is too expensive in compile time to run at -O0.
This also fixes an exponential compile time blow up in
https://github.com/llvm/llvm-project/issues/59126
Differential Revision: https://reviews.llvm.org/D143624
The test currently expects to be run in a directory named 'clang' but
that's not valid for our release tarballs. We don't actually care what
base directory the test is run from, so this removes the path component
entirely.
Issue #58168 describes the difficulty diagnosing stack size issues
identified by -Wframe-larger-than. For simple code, its easy to
understand the stack layout and where space is being allocated, but in
more complex programs, where code may be heavily inlined, unrolled, and
have duplicated code paths, it is no longer easy to manually inspect the
source program and understand where stack space can be attributed.
This patch implements a machine function pass that emits remarks with a
textual representation of stack slots, and also outputs any available
debug information to map source variables to those slots.
The new behavior can be used by adding `-Rpass-analysis=stack-frame-layout`
to the compiler invocation. Like other remarks the diagnostic
information can be saved to a file in a machine readable format by
adding -fsave-optimzation-record.
Fixes: #58168
Reviewed By: nickdesaulniers, thegameg
Differential Revision: https://reviews.llvm.org/D135488
Issue #58168 describes the difficulty diagnosing stack size issues
identified by -Wframe-larger-than. For simple code, its easy to
understand the stack layout and where space is being allocated, but in
more complex programs, where code may be heavily inlined, unrolled, and
have duplicated code paths, it is no longer easy to manually inspect the
source program and understand where stack space can be attributed.
This patch implements a machine function pass that emits remarks with a
textual representation of stack slots, and also outputs any available
debug information to map source variables to those slots.
The new behavior can be used by adding `-Rpass-analysis=stack-frame-layout`
to the compiler invocation. Like other remarks the diagnostic
information can be saved to a file in a machine readable format by
adding -fsave-optimzation-record.
Fixes: #58168
Reviewed By: nickdesaulniers, thegameg
Differential Revision: https://reviews.llvm.org/D135488
Previously, if a header file and a source file used different end of line
(EOL) forms, preprocessed output generated with the -frewrite-includes option
would, in some cases, generate line control directives with the wrong line
number due to an error in how source file lines were counted.
Fixes https://github.com/llvm/llvm-project/issues/59736
Reviewed By: cor3ntin
Differential Revision: https://reviews.llvm.org/D140984
