A new check was added in 3b93dc68, which seems to not be possible to get
working correctly on windows systems:
The test first "captures" the install directory of the clang toolchain
running the test as follows:
// CHECK-AARCH64-NO-HOST-INC: InstalledDir: [[INSTALLEDDIR:.+]]
Then, in a check line a bit later, it uses this to check if a particular
directory in the toolchain installation directory is included when
targeting aarch64-none-elf:
// CHECK-AARCH64-NO-HOST-INC-SAME: "-internal-isystem" "[[INSTALLEDDIR]]{{[/\\]+}}..{{[/\\]+}}lib{{[/\\]+}}clang-runtimes{{[/\\]+}}aarch64-none-elf{{[/\\]+}}include{{[/\\]+}}c++{{[/\\]+}}v1"
Even though the test aims to take into account forward vs backward slash
differences between Windows and Unix paths, it still fails on Windows.
It seems that on Windows (this is based on the output log from a Windows
bot), the INSTALLEDDIR variable has the following value:
note: with "INSTALLEDDIR" equal to "c:\\\\b\\\\slave\\\\clang-x64-windows-msvc\\\\build\\\\stage1\\\\bin"
However the actual "InstalledDir:" output produced by the clang
toolchain on that Windows bot was:
InstalledDir: c:\b\slave\clang-x64-windows-msvc\build\stage1\bin
It is unclear where the explosion of backslashes happens. Maybe this is
a bug in FileCheck somewhere?
Anyway, marking this test as not supported on Windows to make the bots
green again.
Prior to this, the solver was only able to verify whether two symbols
are equal/unequal, only when constants were involved. This patch allows
the solver to work over ranges as well.
Reviewed By: steakhal, martong
Differential Revision: https://reviews.llvm.org/D106102
Patch by: @manas (Manas Gupta)
Summary:
`a % b != 0` implies that `a != 0` for any `a` and `b`. This patch
extends the ConstraintAssignor to do just that. In fact, we could do
something similar with division and in case of multiplications we could
have some other inferences, but I'd like to keep these for future
patches.
Fixes https://bugs.llvm.org/show_bug.cgi?id=51940
Reviewers: noq, vsavchenko, steakhal, szelethus, asdenyspetrov
Subscribers:
Differential Revision: https://reviews.llvm.org/D110357
In this patch we store a reference to `RangedConstraintManager` in the
`ConstraintAssignor`. This way it is possible to call back and reuse some
functions of it. This patch is exclusively needed for its child patches,
it is not intended to be a standalone patch.
Differential Revision: https://reviews.llvm.org/D111640
In this patch we simply move the definition of RangeConstraintManager before
the definition of ConstraintAssignor. This patch is exclusively needed for it's
child patch, so in the child the diff would be clean and the review would be
easier.
Differential Revision: https://reviews.llvm.org/D110387
Fix for importing functions where the TypeSourceInfo is set and the
exception specification information contains reference to the function
declaration itself.
Reviewed By: martong, steakhal
Differential Revision: https://reviews.llvm.org/D112013
Zvamo is not part of the 1.0 V spec. Remove the intrinsics
for now. This helps reduce clang binary size and lit test time.
Reviewed By: HsiangKai
Differential Revision: https://reviews.llvm.org/D111692
Does anyone still use these? I want to make some changes to the sphinx
html generation and I don't want to have to implement the changes in
two places.
Reviewed By: sylvestre.ledru, #libc, ldionne
Differential Revision: https://reviews.llvm.org/D112030
We keep using the first encountered definition and need to take into
account visibility from subsequent definitions. For example, if the
first definition is hidden and the second is visible, we need to make
the first one visible too.
rdar://82263843
Differential Revision: https://reviews.llvm.org/D110453
It isn't really pulling its weight and I think splitting it out from
-Wweak-vtables was the wrong call: I think it was just a bug in the
original warning, which was trying to not diagnose template
instantiations, implicit or explicit.
With the old approach we were updating `ObjCInterfaceType.Decl` to the
last encountered definition. But during loading modules
`ASTDeclReader::VisitObjCInterfaceDecl` keeps the *first* encountered
definition. So with multiple definitions imported there would be a
disagreement between expected definition in `ObjCInterfaceType.Decl` and
actual definition `ObjCInterfaceDecl::getDefinition` which can lead to
incorrect diagnostic.
Fix by not tracking definition in `ObjCInterfaceType` explicitly but by
getting it from redeclaration chain.
Partially reverted 919fc50034 keeping the
modified test case as the correct behavior is achieved in a different
way.
Differential Revision: https://reviews.llvm.org/D110452
Based on post-commit review discussion on
2bd8493847 with Richard Smith.
Other uses of forcing HasEmptyPlaceHolder to false seem OK to me -
they're all around pointer/reference types where the pointer/reference
token will appear at the rightmost side of the left side of the type
name, so they make nested types (eg: the "int" in "int *") behave as
though there is a non-empty placeholder (because the "*" is essentially
the placeholder as far as the "int" is concerned).
This was originally committed in 277623f4d5
Reverted in f9ad1d1c77 due to breakages
outside of clang - lldb seems to have some strange/strong dependence on
"char [N]" versus "char[N]" when printing strings (not due to that name
appearing in DWARF, but probably due to using clang to stringify type
names) that'll need to be addressed, plus a few other odds and ends in
other subprojects (clang-tools-extra, compiler-rt, etc).
Downstream users may have Clang plugins. By default these plugins run
after the main action if they are specified on the command line.
Since these plugins are ASTConsumers, presumably they inspect the AST.
So we shouldn't clear it if any plugins run after the main action.
Reviewed By: dblaikie, hans
Differential Revision: https://reviews.llvm.org/D112190
Reapply 5692ed0cce, but with the ORC runtime disabled explicitly on
CrossWinToARMLinux to match the other compiler-rt runtime libraries.
Differential Revision: https://reviews.llvm.org/D112229
---
Enable building the ORC runtime for 64-bit and 32-bit ARM architectures,
and for all Darwin embedded platforms (iOS, tvOS, and watchOS). This
covers building the cross-platform code, but does not add TLV runtime
support for the new architectures, which can be added independently.
Incidentally, stop building the Mach-O TLS support file unnecessarily on
other platforms.
Differential Revision: https://reviews.llvm.org/D112111
Previously, btf_del_tag attribute supports record, field, global variable,
function and function parameter ([1], [2]). This patch added support for typedef.
The main reason is for typedef of an anonymous struct/union, we can only apply
btf_decl_tag attribute to the anonymous struct/union like below:
typedef struct { ... } __btf_decl_tag target_type
In this case, the __btf_decl_tag attribute applies to anonymous struct,
which increases downstream implementation complexity. But if
typedef with btf_decl_tag attribute is supported, we can have
typedef struct { ... } target_type __btf_decl_tag
which applies __btf_decl_tag to typedef "target_type" which make it
easier to directly associate btf_decl_tag with a named type.
This patch permitted btf_decl_tag with typedef types with this reason.
[1] https://reviews.llvm.org/D106614
[2] https://reviews.llvm.org/D111588
Differential Revision: https://reviews.llvm.org/D110127
Fixes a compiler assert on passing a compile time integer to atomic builtins.
Assert introduced in D61522
Function changed from ->bool to ->Optional in D76646
Simplifies call sites to getIntegerConstantExpr to elide the now-redundant
isValueDependent checks.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D112159
The `clang-scan-deps` CLI tool invokes the compiler with `-print-resource-dir` in case the `-resource-dir` argument is missing from the compilation command line. This is to enable running the tool on compilation databases that use compiler from a different toolchain than `clang-scan-deps` itself. While this doesn't make sense when scanning modular builds (due to the `-cc1` arguments the tool generates), the tool can can be used to efficiently scan for file dependencies of non-modular builds too.
This patch stops deducing the resource directory by invoking the compiler by default. This mode can still be enabled by invoking `clang-scan-deps` with `--resource-dir-recipe invoke-compiler`. The new default is `--resource-dir-recipe modify-compiler-path` which relies on the resource directory deduction taking place in `Driver::Driver` which is based on the compiler path. This makes the default more aligned with the intended usage of the tool while still allowing it to serve other use-cases.
Note that this functionality was also influenced by D108979, where the dependency scanner stopped going through `ClangTool::run`. The function tried to deduce the resource directory based on the current executable path, which might not be what the users expect when invoked from within a shared library.
Depends on D108979.
Reviewed By: dexonsmith
Differential Revision: https://reviews.llvm.org/D108366
The dependency scanner works with multiple instances of `Compiler{Instance,Invocation}`. From names of the variables/members, their purpose is not obvious.
This patch gives descriptive name to the generated `CompilerInvocation` that can be used to derive the command-line to build a modular dependency.
Depends on D111725.
Reviewed By: dexonsmith
Differential Revision: https://reviews.llvm.org/D111728
The dependency scanner works with multiple instances of `Compiler{Instance,Invocation}`. From names of the variables/members, their purpose is not obvious.
This patch gives a distinct name to the `CompilerInstance` that's used to run the implicit build during dependency scan.
Depends on D111724.
Reviewed By: dexonsmith
Differential Revision: https://reviews.llvm.org/D111725
The `ModuleDepCollectorPP` class holds a reference to `ModuleDepCollector` as well as `ModuleDepCollector`'s `CompilerInstance`. The fact that these refer to the same object is non-obvious.
This patch removes the `CompilerInvocation` reference from `ModuleDepCollectorPP` and accesses it through `ModuleDepCollector` instead.
Reviewed By: dexonsmith
Differential Revision: https://reviews.llvm.org/D111724
One of main goals of the dependency scanner is to be strict about module compatibility. This is achieved through strict context hash. This patch ensures that strict context hash is enabled not only during the scan itself (and its minimized implicit build), but also when actually reporting the dependency.
Reviewed By: dexonsmith
Differential Revision: https://reviews.llvm.org/D111720
This reverts commit 121b2252de.
The following code causes a crash in some circumstances:
struct k {
~k() __attribute__((annotate(""))) {}
};
void m() { k(); }
While working on https://reviews.llvm.org/D110280 I've tried to merge
decl contexts as it seems to be correct and matching our handling of
decl contexts from different modules. It's not required for the fix in
https://reviews.llvm.org/D110280 but it revealed a missing diagnostic,
so separating this change into a separate commit.
Renamed some variables to distinguish diagnostic like "declaration of
'x' does not match" for different cases.
Differential Revision: https://reviews.llvm.org/D110287
Originally I thought that I needed to do a #include to trick the
compiler into letting me use typeid I believe, but Aaron explained that
it was just looking for the type_info type. I had to give it some
public/private members to make it emit the same as before, but this
ought to be a 'perfect' replacement.
My downstream noticed that the test failed on windows-32 bit machines
since the types have __attribute__((thiscall)) on them in a few places.
This patch just adds a wildcard to handle that, since it isn't
particularly important to the test.
We already disallow mixing SEH and C++ exceptions, and
mixing SEH and Objective-C exceptions seems to not work (see PR52233).
Emitting an error is friendlier than crashing.
Differential Revision: https://reviews.llvm.org/D112157
isSpecifierType
There is no reason to have this here, (since all tests pass) and it
isn't even a specifier anyway. We can just treat it as a pointer
instead.
Differential Revision: https://reviews.llvm.org/D110068
As discussed in:
* https://reviews.llvm.org/D94166
* https://lists.llvm.org/pipermail/llvm-dev/2020-September/145031.html
The GlobalIndirectSymbol class lost most of its meaning in
https://reviews.llvm.org/D109792, which disambiguated getBaseObject
(now getAliaseeObject) between GlobalIFunc and everything else.
In addition, as long as GlobalIFunc is not a GlobalObject and
getAliaseeObject returns GlobalObjects, a GlobalAlias whose aliasee
is a GlobalIFunc cannot currently be modeled properly. Creating
aliases for GlobalIFuncs does happen in the wild (e.g. glibc). In addition,
calling getAliaseeObject on a GlobalIFunc will currently return nullptr,
which is undesirable because it should return the object itself for
non-aliases.
This patch refactors the GlobalIFunc class to inherit directly from
GlobalObject, and removes GlobalIndirectSymbol (while inlining the
relevant parts into GlobalAlias and GlobalIFunc). This allows for
calling getAliaseeObject() on a GlobalIFunc to return the GlobalIFunc
itself, making getAliaseeObject() more consistent and enabling
alias-to-ifunc to be properly modeled in the IR.
I exercised some judgement in the API clients of GlobalIndirectSymbol:
some were 'monomorphized' for GlobalAlias and GlobalIFunc, and
some remained shared (with the type adapted to become GlobalValue).
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D108872
Add relaxed. f32x4.min, f32x4.max, f64x2.min, f64x2.max. These are only
exposed as builtins, and require user opt-in.
Differential Revision: https://reviews.llvm.org/D112146
Currently we have a way to run a plugin if specified on the command line
after the main action, and ways to unconditionally run the plugin before
or after the main action, but no way to run a plugin if specified on the
command line before the main action.
This introduces the missing option.
This is helpful because -clear-ast-before-backend clears the AST before
codegen, while some plugins may want access to the AST.
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D112096
Previously we used builtin_alias for overloaded intrinsics, but
macros for the non-overloaded version. This patch changes the
non-overloaded versions to also use builtin_alias, but without
the overloadable attribute.
Reviewed By: khchen, HsiangKai
Differential Revision: https://reviews.llvm.org/D112020
It turns out llvm::isa<> is variadic, and we could have used this at a
lot of places.
The following patterns:
x && isa<T1>(x) || isa<T2>(x) ...
Will be replaced by:
isa_and_non_null<T1, T2, ...>(x)
Sometimes it caused further simplifications, when it would cause even
more code smell.
Aside from this, keep in mind that within `assert()` or any macro
functions, we need to wrap the isa<> expression within a parenthesis,
due to the parsing of the comma.
Reviewed By: martong
Differential Revision: https://reviews.llvm.org/D111982
When we added support for if consteval, we accidentally formed a discarded
statement evaluation context for the branch-not-taken. However, a discarded
statement is a property of an if constexpr statement, not an if consteval
statement (https://eel.is/c++draft/stmt.if#2.sentence-2). This turned out to
cause issues when deducing the return type from a function with a consteval if
statement -- we wouldn't consider the branch-not-taken when deducing the return
type.
This fixes PR52206.
Note, there is additional work left to be done. We need to track discarded
statement and immediate evaluation contexts separately rather than as being
mutually exclusive.
Sylvestre Ledru