Currently, clang does not emit debuginfo for the switch stmt
case value if it is an enum value. For example,
$ cat test.c
enum { AA = 1, BB = 2 };
int func1(int a) {
switch(a) {
case AA: return 10;
case BB: return 11;
default: break;
}
return 0;
}
$ llvm-dwarfdump test.o | grep AA
$
Note that gcc does emit debuginfo for the same test case.
This patch added such a support with similar implementation
to CodeGenFunction::EmitDeclRefExprDbgValue(). With this patch,
$ clang -g -c test.c
$ llvm-dwarfdump test.o | grep AA
DW_AT_name ("AA")
$
Differential Revision: https://reviews.llvm.org/D134705
This amends fd874e5fb1 to correctly set
the bit width of a '!' operator to be the same width as an 'int'. This
fixes a failed assertion about unexpected bit widths that was reported
during post-commit testing.
This implements WG14 N2927 and WG14 N2930, which together define the
feature for typeof and typeof_unqual, which get the type of their
argument as either fully qualified or fully unqualified. The argument
to either operator is either a type name or an expression. If given a
type name, the type information is pulled directly from the given name.
If given an expression, the type information is pulled from the
expression. Recursive use of these operators is allowed and has the
expected behavior (the innermost operator is resolved to a type, and
that's used to resolve the next layer of typeof specifier, until a
fully resolved type is determined.
Note, we already supported typeof in GNU mode as a non-conforming
extension and we are *not* exposing typeof_unqual as a non-conforming
extension in that mode, nor are we exposing typeof or typeof_unqual as
a nonconforming extension in other language modes. The GNU variant of
typeof supports a form where the parentheses are elided from the
operator when given an expression (e.g., typeof 0 i = 12;). When in C2x
mode, we do not support this extension.
Differential Revision: https://reviews.llvm.org/D134286
This patch implements P0634r3 that removes the need for 'typename' in certain contexts.
For example,
```
template <typename T>
using foo = T::type; // ok
```
This is also allowed in previous language versions as an extension, because I think it's pretty useful. :)
Reviewed By: #clang-language-wg, erichkeane
Differential Revision: https://reviews.llvm.org/D53847
This eagerly reports use of undef values when passed to noundef
parameters or returned from noundef functions.
This also decreases binary sizes under msan.
To go back to the previous behavior, pass `-fno-sanitize-memory-param-retval`.
Reviewed By: vitalybuka, MaskRay
Differential Revision: https://reviews.llvm.org/D134669
Although using-enum's grammar is 'using elaborated-enum-specifier',
the lookup for the enum is ordinary lookup (and not the tagged-type
lookup that normally occurs wth an tagged-type specifier). Thus (a)
we can find typedefs and (b) do not find enum tags hidden by a non-tag
name (the struct stat thing).
This reimplements that part of using-enum handling, to address DR2621,
where clang's behaviour does not match std intent (and other
compilers).
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D134283
Functions that implement expansion of response and config files depend
on many options, which are passes as arguments. Extending the expansion
requires new options, it in turn causes changing calls in various places
making them even more bulky.
This change introduces a class ExpansionContext, which represents set of
options that control the expansion. Its methods implements expansion of
responce files including config files. It makes extending the expansion
easier.
No functional changes.
Differential Revision: https://reviews.llvm.org/D132379
After https://reviews.llvm.org/D134461, Clang will diagnose a warning if
trying to deference void pointers in C mode. However, this causes a lot
of noises when compiling a 5.19.11 Linux kernel.
This patch reduces the warning by marking deferencing void pointers in
unevaluated context OK, like `sizeof(*void_ptr)`, `typeof(*void_ptr)`
and etc.
Fixes https://github.com/ClangBuiltLinux/linux/issues/1720
Signed-off-by: Jun Zhang <jun@junz.org>
Differential Revision: https://reviews.llvm.org/D134702
Summary:
clang-format makes multiple passes when #if/#else preprocessor blocks are found. It will make
one pass for normal code and code in the #if block, and then it will make another pass for just
the code in #else blocks. This often results in invalid alignment inside the else blocks because
they do not have any scope or indentAndNestingLevel context from their surrounding tokens/lines.
This patch remedies that by caching any initial indentAndNestingLevel from a second pass and
not breaking/returning early when a scope change is detected.
Fixes#36070
Reviewers: HazardyKnusperkeks, MyDeveloperDay
Tags: clang, clang-format
Differential Revision: https://reviews.llvm.org/D134042
It is data mapping ordering problem.
According omp spec
If one or more map clauses are present, the list item conversions that
are performed for any use_device_ptr or use_device_addr clause occur
after all variables are mapped on entry to the region according to those
map clauses.
The change is to put mapping data for use_device_addr at end of data
mapping array.
Differential Revision: https://reviews.llvm.org/D134556
The following three static functions in `clang/lib/Driver/ToolChains/CommonArgs.cpp`
```
static void renderRpassOptions(...)
static void renderRemarksOptions(...)
static void renderRemarksHotnessOptions(...)
```
use `--plugin-opt` for the plugin option prefix, while the function `tools::addLTOOptions` uses `-plugin-opt`. This patch makes sure that we only use `-plugin-opt` (single dash) everywhere. It is not clear to me that why we decided to use `--plugin-opt` in https://reviews.llvm.org/D85810. If using `--plugin-opt` is intended, I'd love to hear the reason and I will close this patch.
We intend to followup this patch with a few other patches that teach `clang` to pass plugin options to the AIX linker, which uses a different prefix (`-bplugin_opt:`).
Reviewed By: w2yehia
Differential Revision: https://reviews.llvm.org/D134668
The HLSL support in clang is in progress and not fully functioning. As
such we don't want to install the related optional build components by
default (yet), but we do need an option to build and install them
locally for testing and for some key users.
This adds the `CLANG_ENABLE_HLSL` option which is off by default and can
be enabled to install the HLSL clang headers and the clang-dxc symlink.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D134693
As reported in GH #57945, this would crash because the decl context for
the lambda was being loaded via 'getNonClosureContext', which only gets
CODE contexts, so a global lambda was getting 'nullptr' here instead.
This patch does some work to make sure we get a valid/valuable
declcontext here instead.
A given function is compatible with all previous arch versions.
To avoid compering values of the attribute this logic adds all predecessor
architecture values.
Reviewed By: dmgreen, DavidSpickett
Differential Revision: https://reviews.llvm.org/D134353
HIP is able to unbundle archive of bundled bitcode.
However currently there are two bugs:
1. archives passed by -l: are not unbundled.
2. archives passed as input files are not unbundled
The actual file name of an archive passed by -l: should
not be prefixed with lib and appended with '.a',
but the file path is prefixed with paths in '-L' options.
The actual file name of an archive passed as an input file
stays the same, not affected by the '-L' options.
This reverts commit 192d69f7e6.
This fixes the condition to check whether this is a situation where we
are in a recovery-expr'ed concept a little better, so we don't access an
inactive member of a union, which should make the bots happy.
Differential Revision: https://reviews.llvm.org/D134542
This reverts commit e3d14bee23.
There are apparently a large number of crashes in libcxx and some JSON
Parser thing, so clearly this has some sort of serious issue. Reverting
so I can take some time to figure out what is going on.
Discovered by reducing a different problem, we currently assert because
we failed to make the constraint expressions not dependent, since a
RecoveryExpr cannot be transformed.
This patch fixes that, and gets reasonably nice diagnostics by
introducing a concept (hah!) of "ContainsErrors" to the Satisfaction
types, which causes us to treat the candidate as non-viable.
However, just making THAT candidate non-viable would result in choosing
the 'next best' canddiate, which can result in awkward errors, where we
start evaluating a candidate that is not intended to be selected.
Because of this, and to make diagnostics more relevant, we now just
cause the entire lookup to result in a 'no-viable-candidates'.
This means we will only emit the list of candidates, rather than any
cascading failures.
In case when the prvalue is returned from the function (kind is one
of `SimpleReturnedValueKind`, `CXX17ElidedCopyReturnedValueKind`),
then it construction happens in context of the caller.
We pass `BldrCtx` explicitly, as `currBldrCtx` will always refer to callee
context.
In the following example:
```
struct Result {int value; };
Result create() { return Result{10}; }
int accessValue(Result r) { return r.value; }
void test() {
for (int i = 0; i < 2; ++i)
accessValue(create());
}
```
In case when the returned object was constructed directly into the
argument to a function call `accessValue(create())`, this led to
inappropriate value of `blockCount` being used to locate parameter region,
and as a consequence resulting object (from `create()`) was constructed
into a different region, that was later read by inlined invocation of
outer function (`accessValue`).
This manifests itself only in case when calling block is visited more
than once (loop in above example), as otherwise there is no difference
in `blockCount` value between callee and caller context.
This happens only in case when copy elision is disabled (before C++17).
Reviewed By: NoQ
Differential Revision: https://reviews.llvm.org/D132030
This patch adds support for constraints `f`, `l`, `I`, `K` according
to [1]. The remain constraints (`k`, `m`, `ZB`, `ZC`) will be added
later as they are a little more complex than the others.
f: A floating-point register (if available).
l: A signed 16-bit constant.
I: A signed 12-bit constant (for arithmetic instructions).
K: An unsigned 12-bit constant (for logic instructions).
For now, no need to support register alias (e.g. `$a0`) in llvm as
clang will correctly decode the usage of register name aliases into
their official names. And AFAIK, the not yet upstreamed `rustc` for
LoongArch will always use official register names (e.g. `$r4`).
[1] https://gcc.gnu.org/onlinedocs/gccint/Machine-Constraints.html
Differential Revision: https://reviews.llvm.org/D134157
The comment handling the bool case says:
"bool is only allowed if it is directly followed by a paren for a cast"
This change more closely follows this directive by looking ahead for
the paren before consuming the bool keyword itself. Without a following
paren, the bool would be part of something else, such as a return type
for a function declaration
Fixes https://github.com/llvm/llvm-project/issues/57538
Reviewed By: HazardyKnusperkeks, owenpan, MyDeveloperDay
Differential Revision: https://reviews.llvm.org/D134325
`P1169` "static operator()" (https://wg21.link/P1169) is accepted to
C++23 and while clang itself doesn't exactly support it yet,
clang-format could quite easily.
This simply allows the keyword `static` to be a part of lambdas as
specified by the addition to [expr.prim.lambda.general]
While adding this, I noticed `consteval` lambdas also aren't handled,
so that keyword is now allowed to be a part of lambdas as well
Reviewed By: HazardyKnusperkeks, owenpan, MyDeveloperDay
Differential Revision: https://reviews.llvm.org/D134587
Clang with debug builds will crash when run with empty target feature input.
And the warning message is a little bit confusing. This patch adds an empty
check and a new diagnostic to illustrate where goes wrong.
Reviewed By: MaskRay, aaron.ballman
Differential Revision: https://reviews.llvm.org/D133563
Previously we only have an extension that warn void pointer deferencing
in C++, but for C we did nothing.
C2x 6.5.3.2p4 says The unary * operator denotes indirection. If it points
to an object, the result is an lvalue designating the object. However, there
is no way to form an lvalue designating an object of an incomplete type as
6.3.2.1p1 says "an lvalue is an expression (with an object type other than
void)", so the behavior is undefined.
Fixes https://github.com/llvm/llvm-project/issues/53631
Signed-off-by: Jun Zhang <jun@junz.org>
Differential Revision: https://reviews.llvm.org/D134461
This patch adds an additional check for if an options passed to the
Clang driver could've been intended for the clang compiler. This is
primarily done for the times when a user attempts to pass an option like
`-ast-dump` to the driver instead.
Reviewed By: MaskRay, aaron.ballman
Differential Revision: https://reviews.llvm.org/D134550
Apparently TransformDecl in TreeTransform can be called with a nullptr
for a Decl, so my casts were illegal. The fix here is to add an early
exit to my TransformDecl.
This reverts commit 794b7ea960, and
thus restores commit a212d8da94, and
follow on fixes 0cd6763fa9,
e9ff53d42f, and
37c6a25e9a.
Use a hash function (BLAKE3) instead of hash_combine/hash_code which are
not guaranteed to be stable across executions.
Additionally, it adds a "REQUIRES: x86_64-linux" to the tests that have
raw profile inputs to avoid failures on big endian bots.
Reviewers: snehasish, davidxl
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D128142
This allows using --ld-path= to set a custom linker path, while
still informing clang that the binary at that path is an lld built
at the same revision as clang, so that clang can make assumptions
about the flags it supports, its output format, etc.
This currently only has an observable effect on Darwin.
Differential Revision: https://reviews.llvm.org/D134063
By draft of C23 (https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2912.pdf),
the description for isless macro under 7.12.17.3 says,
The isless macro determines whether its first argument is less than its second
argument. The value of isless(x,y) is always equal to (x)< (y); however, unlike
(x) < (y), isless(x,y) does not raise the invalid floating-point exception when
x and y are unordered and neither is a signaling NaN.
isless should trap when encountering signaling NaN.
Reviewed By: jcranmer-intel, efriedma
Differential Revision: https://reviews.llvm.org/D134407
The /Zl flag omits default C runtime library name from obj files.
This patch just adds an equivalent clang driver flag.
Differential Revision: https://reviews.llvm.org/D133959
This reverts commit a212d8da94, and follow
on fixes 0cd6763fa9,
e9ff53d42f, and
37c6a25e9a.
After re-reading the documentation for hash_combine, I don't think this
is the appropriate hash function to use for computing the hash to use as
a stack id in the metadata, since it is not guaranteed to produce stable
values across executions. I have not hit this problem, but plan to
switch to using an MD5 hash. I am hitting an issue with one of the bots
(https://lab.llvm.org/buildbot/#/builders/171/builds/20732)
where the values produced are only the lower 32 bits of the expected
hash values, however, which I assume is related to the implementation of
hash_combine and hash_code.
I believe I fixed all of the other bot failures with the follow on fixes,
which I'll merge into the new version before reapplying.
Translate HLSLNumThreadsAttr into function attribute with name "dx.numthreads" and value format as "x,y,z".
Reviewed By: beanz
Differential Revision: https://reviews.llvm.org/D131799
In `ASTWriter`, input files are sorted based on whether they are system or user. The current implementation used single `std::queue` with `push_back` and `push_front`. This resulted in the user files being reversed.
This patch fixes that by keeping the system/user distinction, but otherwise serializing files in the order they were loaded by the `SourceManager`. This is then used in the dependency scanner to report module map dependencies in the correct order.
Depends on D134224.
Reviewed By: Bigcheese
Differential Revision: https://reviews.llvm.org/D134248
Profile matching and IR annotation for memprof profiles.
See also related RFCs:
RFC: Sanitizer-based Heap Profiler [1]
RFC: A binary serialization format for MemProf [2]
RFC: IR metadata format for MemProf [3]*
* Note that the IR metadata format has changed from the RFC during
implementation, as described in the preceeding patch adding the basic
metadata and verification support.
The matching is performed during the normal PGO annotation phase, to
ensure that the inlines applied in the IR at that point are a subset
of the inlines in the profiled binary and thus reflected in the
profile's call stacks. This is important because the call frames are
associated with functions in the profile based on the inlining in the
symbolized call stacks, and this simplifies locating the subset of
profile data relevant for matching onto each function's IR.
The PGOInstrumentationUse pass is enhanced to perform matching for
whatever combination of memprof and regular PGO profile data exists in
the profile.
Using the utilities introduced in D128854:
The memprof profile data for each context is converted to "cold" or
"notcold" based on parameterized thresholds for size, access count, and
lifetime. The memprof allocation contexts are trimmed to the minimal
amount of context required to uniquely identify whether the context is
cold or not cold. For allocations where all profiled contexts have the
same allocation type, no memprof metadata is attached and instead the
allocation call is directly annotated with an attribute specifying the
alloction type. This is the same attributed that will be applied to
allocation calls once cloned for different contexts, and later used
during LibCall simplification to emit allocation hints [4].
Depends on D128141 and D128854.
[1] https://lists.llvm.org/pipermail/llvm-dev/2020-June/142744.html
[2] https://lists.llvm.org/pipermail/llvm-dev/2021-September/153007.html
[3] https://discourse.llvm.org/t/rfc-ir-metadata-format-for-memprof/59165
[4] ab87cf382d
Differential Revision: https://reviews.llvm.org/D128142
Module map files describing excluded headers do affect compilation. Track them in the compiler, serialize them into the PCM file and report them in the scanner.
Depends on D134222.
Reviewed By: Bigcheese
Differential Revision: https://reviews.llvm.org/D134224
Extend the context-sensitive analysis to handle a call to a method (of the same
class) from within a method. That, is a member-call expression through `this`.
Differential Revision: https://reviews.llvm.org/D134432
This patch fixes compilation failure with explicit modules caused by scanner not reporting the module map describing the module whose implementation is being compiled.
Below is a breakdown of the attached test case. Note the VFS that makes frameworks "A" and "B" share the same header "shared/H.h".
In non-modular build, Clang skips the last import, since the "shared/H.h" header has already been included.
During scan (or implicit build), the compiler handles "tu.m" as follows:
* `@import B` imports module "B", as expected,
* `#import <A/H.h>` is resolved textually (due to `-fmodule-name=A`) to "shared/H.h" (due to the VFS remapping),
* `#import <B/H.h>` is resolved to import module "A_Private", since the header "shared/H.h" is already known to be part of that module, and the import is skipped.
In the end, the only modular dependency of the TU is "B".
In explicit modular build without `-fmodule-name=A`, TU does depend on module "A_Private" properly, not just textually. Clang therefore builds & loads its PCM, and knows to ignore the last import, since "shared/H.h" is known to be part of "A_Private".
But with current scanner behavior and `-fmodule-name=A` present, the last import fails during explicit build. Clang doesn't know about "A_Private" (it's included textually) and tries to import "B_Private" instead, which it doesn't know about either (the scanner correctly didn't report it as dependency). This is fixed by reporting the module map describing "A" and matching the semantics of implicit build.
Reviewed By: Bigcheese
Differential Revision: https://reviews.llvm.org/D134222
The resource binding attribute is to set the virtual registers and logical register spaces resources in HLSL are bound to.
Format is ''register(ID, space)'' like register(t3, space1).
ID must be start with
t – for shader resource views (SRV),
s – for samplers,
u – for unordered access views (UAV),
b – for constant buffer views (CBV).
Register space is default to space0.
The full documentation is available here: https://docs.microsoft.com/en-us/windows/win32/direct3d12/resource-binding-in-hlsl
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D130033
The accessibility level of a typedef or using declaration in a
struct or class was being lost when producing debug information.
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D134339
This reverts commit 95d94a6775.
This implements the deferred concepts instantiation, which should allow
the libstdc++ ranges to properly compile, and for the CRTP to work for
constrained functions.
Since the last attempt, this has fixed the issues from @wlei and
@mordante.
Differential Revision: https://reviews.llvm.org/D126907
Prior to the patch, we didn't build a DeclRefExpr if the Decl being
referred to is invalid, because many clang downstream AST consumers
assume it, violating it will cause many diagnostic regressions.
With this patch, we build a DeclRefExpr enven for an invalid decl (when the
AcceptInvalidDecl is true), and wrap it with a dependent-type
RecoveryExpr (to prevent follow-up semantic analysis, and diagnostic
regressions).
This is a revised version of https://reviews.llvm.org/D76831
Reviewed By: sammccall
Differential Revision: https://reviews.llvm.org/D121599
This fixes a bunch of FIXME within IsTailPaddedMemberArray related code.
As a side effect, this now also triggers a warning when trying to access a
"struct hack" member with an index above address space index range.
Differential Revision: https://reviews.llvm.org/D133108
One must pick the same name as the one referenced in CodeGenFunction when
generating .inline version of an inline builtin, otherwise they are not
correctly replaced.
Differential Revision: https://reviews.llvm.org/D134362
Unicode 15.0 adds 4,489 characters, for a total of 149,186 characters.
These additions include 2 new scripts along with 20 new emoji characters,
and 4,193 CJK ideographs.
This changes modify most existing tables including
- XID_Start/XID_Continue in Clang
- The character name database (used by \N{} in Clang)
- The list of formattable/printable codepoints
- The case folding algorithm (which we had not updated since Unicode 9)
- The list of nonspacing/enclosing marks used by the column width
computation algorithm. The rest of the column width algorithm
is not updated.
Reviewed By: tahonermann
Differential Revision: https://reviews.llvm.org/D133807
showBRParamDiagnostics assumed stores happen only via function parameters while that
can also happen via implicit parameters like 'self' or 'this'.
The regression test caused a failed assert in the original cast to ParmVarDecl.
Differential Revision: https://reviews.llvm.org/D133815
When `objc_direct` methods were implemented, the implicit `_cmd` parameter was left as an argument to the method implementation function, but was unset by callers; if the method body referenced the `_cmd` variable, a selector load would be emitted inside the body. However, this leaves an unused argument in the ABI, and is unnecessary.
This change removes the empty/unset argument, and if `_cmd` is referenced inside an `objc_direct` method it will emit local storage for the implicit variable. From the ABI perspective, `objc_direct` methods will have the implicit `self` parameter, immediately followed by whatever explicit arguments are defined on the method, rather than having one unset/undefined register in the middle.
Differential Revision: https://reviews.llvm.org/D131424
This option specifies a GCC installation directory such as
/usr/lib/gcc/x86_64-linux-gnu/12, /usr/lib/gcc/x86_64-gentoo-linux-musl/11.2.0 .
It is intended to replace --gcc-toolchain=, which specifies a directory where
`lib/gcc{,-cross}` can be found. When --gcc-toolchain= is specified, the
selected `lib/gcc/$triple/$version` installation uses complex logic and the
largest GCC version is picked. There is no way to specify another version in the
presence of multiple GCC versions.
D25661 added gcc-config detection for Gentoo: `ScanGentooConfigs`.
The implementation may be simplified by using --gcc-install-dir=.
Reviewed By: mgorny
Differential Revision: https://reviews.llvm.org/D133329
This code was added in b65b1f322b, but it
was not noticed that the [[fallthrough]] behavior was very wrong. In C
mode, we would set the ParenExprType to CompoundLiteral and then
promptly overwrite that information by falling through.
After some investigation, I convinced myself that it is not possible to
hit this code path in C, only in C++. I've switched it to be an
assertion; I don't expect to hit it, but if we do hit it, that will at
least give us a code example we can use to reason about the intent of
the original code.
`__builtin_arm_crc*` requires the target feature crc which is available on armv8
and above. Calling the fuctions for armv7 leads to a SelectionDAG crash.
```
% clang -c --target=armv7-unknown-linux-gnueabi -c a.c
fatal error: error in backend: Cannot select: intrinsic %llvm.arm.crc32b
PLEASE submit a bug report to ...
```
Add `TARGET_BUILTIN` and define required features for these builtins to
report an error in `CodeGenFunction::checkTargetFeatures`. The problem is quite widespread.
I will add `TARGET_BUILTIN` for more builtins later.
Fix https://github.com/llvm/llvm-project/issues/57802
Differential Revision: https://reviews.llvm.org/D134127
This is first part for support cbuffer/tbuffer.
The format for cbuffer/tbuffer is
BufferType [Name] [: register(b#)] { VariableDeclaration [: packoffset(c#.xyzw)]; ... };
More details at https://docs.microsoft.com/en-us/windows/win32/direct3dhlsl/dx-graphics-hlsl-constants
New keyword 'cbuffer' and 'tbuffer' are added.
New AST node HLSLBufferDecl is added.
Build AST for simple cbuffer/tbuffer without attribute support.
The special thing is variables declared inside cbuffer is exposed into global scope.
So isTransparentContext should return true for HLSLBuffer.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D129883
alignments
In the following code, the first element is aligned on a 16-byte
boundary, but the remaining elements aren't:
```
typedef char int8_a16 __attribute__((aligned(16)));
int8_a16 array[4];
```
Currently clang doesn't reject the code, but it should since it can
cause crashes at runtime. This patch also fixes assertion failures in
CodeGen caused by the changes in https://reviews.llvm.org/D123649.
Differential Revision: https://reviews.llvm.org/D133711
In order to make this easier to track I've filed issues for each of the
HLSL FIXME comments that I can find. I may have missed some, but I want
this to be the new default mode.
This change allows us to represent in the AST some specific
circumstances where we substitute a template parameter type
which is part of the underlying type of a previous substitution.
This presently happens in some circumstances dealing with
substitution of defaulted parameters of template template
parameters, and in some other cases during concepts substitution.
The main motivation for this change is for the future use in the
implementation of template specialization resugaring, as this will
allow us to represent a substitution with sugared types.
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Differential Revision: https://reviews.llvm.org/D132816
Support specifying multiple configuration files via multiple `--config`
options. When multiple files are specified, the options from subsequent
files are appended to the options from the initial file.
While at it, remove the incorrect assertion about CfgFileName being
non-empty. It can be empty if `--config ""` is passed, and it makes
sense to report it as non-existing file rather than crash.
Differential Revision: https://reviews.llvm.org/D134270
This patch add codegen support for the has_device_addr clause. It use
the same logic of is_device_ptr. But passing &var instead pointer to var
to kernal.
Differential Revision: https://reviews.llvm.org/D134268
This extension does not appear to be on its way to ratification.
Out of the unratified bitmanip extensions, this one had the
largest impact on the compiler.
Posting this patch to start a discussion about whether we should
remove these extensions. We'll talk more at the RISC-V sync meeting this
Thursday.
Reviewed By: asb, reames
Differential Revision: https://reviews.llvm.org/D133834
When a framework can be found at a new location, all references to it in
the module cache become outdated. When we try to load such outdated .pcm
file, we shouldn't change any already loaded and processed modules.
If `Module` has `ASTFile`, it means we've read its AST block already and
it is too late to undo that. If `ASTFile` is `None`, there is no value
in setting it to `None` again. So we don't reset `ASTFile` in
`ModuleManager::removeModules` at all.
rdar://97216258
Differential Revision: https://reviews.llvm.org/D134249
Add HLSLExternalSemaSource as ExternalSemaSource instead of ASTContext::ExternalSource when PCH is included.
This allows a different external source to be set for the AST context.
Reviewed By: beanz
Differential Revision: https://reviews.llvm.org/D132421
This flag enables the .debug_aranges section by passing a flag to LLD
and our internal linker. This also adds a new routine that will generate
the correct flag for our internal linker or set of flags for LLD when
given a list of LLVM options. That ensures multiple LLVM codegen options
can be passed to either linker consistently.
Differential Revision: https://reviews.llvm.org/D134296
This change exposes the sqrt library function for HLSL scalar types,
excluding long and long long doubles. Sqrt is supported for all scalar, vector,
and matrix types. This patch only adds a subset of scalar type support.
Long and long long double support is missing in this patch because that type
doesn't exist in HLSL.
The full documentation of the HLSL asin function is available here:
https://docs.microsoft.com/en-us/windows/win32/direct3dhlsl/dx-graphics-hlsl-sqrt
Reviewed By: beanz
Differential Revision: https://reviews.llvm.org/D132711
This can be used to disable vectorization and memcpy/memset
expansion for things like OS kernels. It also disables implicit
uses of scalar FP, but I don't know if we have any of those for
RISC-V.
NOTE: Without this patch you can still do -Xclang -no-implicit-float
Reviewed By: rui.zhang
Differential Revision: https://reviews.llvm.org/D134077
Clang already generates code that doesn't use writeable data in executable
sections so the linker flag is all that is necessary.
-Wl,--no-execute-only can be used to turn this default off.
Differential Revision: https://reviews.llvm.org/D134289
Fix __builtin_assume_aligned incorrect type descriptor
example from @rsmith
struct A { int n; };
struct B { int n; };
struct C : A, B {};
void *f(C *c) {
// Incorrectly returns `c` rather than the address of the B base class.
return __builtin_assume_aligned((B*)c, 8);
}
Differential Revision: https://reviews.llvm.org/D133583
Having the flags only pass through if you're using the dxc-driver means
that the clang driver doesn't work for HLSL, which is undesirable. This
change switches to instead passing flags based on the language mode
similar to how OpenCL does it. This allows the clang driver to be used
for HLSL source files as well.
Reviewed By: python3kgae
Differential Revision: https://reviews.llvm.org/D133958
AArch64 MachO has a compact unwind format where most functions' unwind info can
be represented in just 4 bytes. But this cannot represent any asynchronous CFI
function, so it's essentially disabled when that's used. This is a large
code-size hit that we'd rather not take unless explicitly requested.
Disable transformations (e.g. attempting to replace target architecture)
in the config filename that is passed explicitly via `--config`. This
behavior is surprising and confusing -- if user passes an explicit
config filename, Clang should use it as is. The transformations are
still applied when the name is deduced from filename.
Update the tests accordingly. This primarily ensures that full filename
with .cfg suffix is passed to --config (appending `.cfg` implicitly is
not documented, and would collide with use of filenames with other
suffixes). The config-file2.c suite is removed entirely as it tested
the transformations on the argument to --config. However, the aspects
of that that were not tested as part of config-file3.c are now added
there (based on config filename deduced from executable).
This change streamlines the code in Driver::loadConfigFile(), opening
the possibility of further changes, including support for handling
multiple --config options and refactoring of filename deduction.
Differential Revision: https://reviews.llvm.org/D134208
When passing arguments with `__fastcall` or `__vectorcall` in 32-bit MSVC, the following arguments have chance to be passed by register if the current one failed. `__regcall` from ICC is on the contrary: https://godbolt.org/z/4MPbzhaMG
All the three calling conversions are not supported in GCC.
Fixes: #57737
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D133920
Yonghong Song