…#162740)"
This reverts commit 6010df0402.
This apparently fails some sanitizer test as reported here:
https://github.com/llvm/llvm-project/pull/162740
It isn't really clear where this happens, but reverting as it is a
friday, and I have no idea if I'll be able to repro this anytime soon,
let alone fix it.
This PR introduces a `MathToXeVM` pass, which implements support for the
`afn` fastmath flag for SPIRV/XeVM targets - It takes supported `Math`
Ops with the `afn` flag, and converts them to function calls to OpenCL
`native_` intrinsics.
These intrinsic functions are supported by the SPIRV backend, and are
automatically converted to `OpExtInst` calls to `native_` ops from the
OpenCL SPIRV ext. inst. set when outputting to SPIRV/XeVM.
Note:
- This pass also supports converting `arith.divf` to native equivalents.
There is an option provided in the pass to turn this behavior off.
- This pass preserves fastmath flags, but these flags are currently
ignored by the SPIRV backend. Thus, in order to generate SPIRV that
truly preserves fastmath flags, support needs to be added to the SPIRV
backend.
Add the `analyzeRtStrideCandidate` function. In the future commits we're
going to add the capability to widen strided loads to it. So, in this
commit, we move the size / type checks into it, since it can possibly
change size / type of load.
Still seeing a failure on a CI bot with this test that
I cannot reproduce locally, but luckily this one CI bot is giving
me trace output from the tests. Turn on the unwind log when tracing
is enabled, migth get a better hint what's up with this test fail.
determineFileName was confusing regarding namespaces. The comment and
conditional were both misleading. Now, we just check against a static
global namespace USR to make a file use "index", or just use the name.
Also, ignore the test results since they almost always fail. This allows
us to simplify the build process and skip uploading and downloading the
build and source directories which are huge.
fixes#161754
When the GVN pass calls `PerformLoadPRE` or `processNonLocalLoad` it can
invoke the `SSAUpdater` which adds a phi node for our tokenLike type. If
we check for if the load is on a token like type at the `processLoad` we
can cover both cases. This is because if we don't GVN will use the
SSAUpdater to insert a phi node to reduce duplicate resource.getpointer
calls.
Because in an earlier commit:
01c0a8409a
we made the verifier error with `PHI nodes cannot have token type!`
This test case will fail today if we try to perform this load
optimization
https://godbolt.org/z/xM69fY8zM
This will impact clang aswell because `isTokenLikeTy` also checks for
`isTokenTy` Clang is likely also failing validation with token types but
just doesn't have a test case because the validator would error if it
were in a phi node.
As a followup to the previous AST changes, the next step is to generate
the proper expressions in Sema. This patch does so for +,*,&,|,^ by
modeling them as compound operators.
This also causes the legality of some expressions to change, as these
have to be legal operations, but were previously unchecked, so there are
some test changes.
This does not yet generate any CIR, that will happen in the next patch.
Better test coverage.
The round-tripping test makes sure that if we ever change
`llvm::dwarf::toDW_Lang` or `llvm::dwarf::toDW_LName`, we don't break
the `LanguageDescription` API.
The round-tripping test found an incorrect version check in
`llvm::dwarf::toDW_Lang`, which I corrected as part of this PR (see the
table at the bottom of https://dwarfstd.org/languages-v6.html for
reference).
Lately, I've been using 'getBaseOriginalType' in ArraySectionExpr
incorrectly: it gets the base-ist of element type, when in reality, I
want a single type of indirection. This patch corrects the handful of
uses that I had for it.
Depends on:
* https://github.com/llvm/llvm-project/pull/162050
Since it's a 'Note' diagnostic it would only show up when expression
evaluation actually failed. This helps with expression evaluation
failure reports in mixed language environments where it's not quite
clear what language the expression ran as. It may also reduce confusion
around why the expression evaluator ran an expression in a language it
wasn't asked to run (a softer alternative to what I attempted in
https://github.com/llvm/llvm-project/pull/156648).
Here are some example outputs:
```
# Without target
(lldb) expr blah
note: Falling back to default language. Ran expression as 'Objective C++'.
# Stopped in target
(lldb) expr blah
note: Ran expression as 'C++14'.
(lldb) expr -l objc -- blah
note: Expression evaluation in pure Objective-C not supported. Ran expression as 'Objective C++'.
(lldb) expr -l c -- blah
note: Expression evaluation in pure C not supported. Ran expression as 'ISO C++'.
(lldb) expr -l c++14 -- blah
note: Ran expression as 'C++14'
(lldb) expr -l c++20 -- blah
note: Ran expression as 'C++20'
(lldb) expr -l objective-c++ -- blah
note: Ran expression as 'Objective C++'
(lldb) expr -l D -- blah
note: Expression evaluation in D not supported. Falling back to default language. Ran expression as 'Objective C++'.
```
I didn't put the diagnostic on the same line as the inline diagnostic
for now because of implementation convenience, but if reviewers deem
that a blocker I can take a stab at that again.
Also, other language plugins (namely Swift), won't immediately benefit
from this and will have to emit their own diagnistc. I played around
with having a virtual API on `UserExpression` or `ExpressionParser` that
will be called consistently, but by the time we're about to parse the
expression we are already several frames deep into the plugin. Before
(and at the beginning of) the generic `UserExpression::Parse` call we
don't have enough information to notify which language we're going to
parse in (at least for the C++ plugin).
rdar://160297649
rdar://159669244
API tests in the `libc++` category will try their best to build against
a locally built libc++. If none exists, the `Makefile.rules` currently
fall back to using the system libc++.
The issue with falling back to the system libc++ is that we are now
potentially not testing what we intended to. But we also can't rely on
certain libc++ features being available that the tests are trying to
use. On Apple platforms this is a configuration error (because libc++ is
the only stdlib supported), but we can't make it an error on Linux
because a user might want to run the API tests with libstdc++.
The Ubunutu 22.04 bots on the Apple fork are failing to run following
tests are failing:
* `TestLibcxxInternalsRecognizer.py`
* `TestDataFormatterStdRangesRefView.py` because the system stdlib
doesn't have `std::ranges` support yet. And the tests just fail to
build. Building libc++ on those bots is also not possible because the
system compiler is too old (and the Apple fork builds all the
subprojects standalone, so it requires the system compiler).
This patch marks tests in the `libc++` category as `UNSUPPORTED` if no
local libc++ is available.
The downside is that we will inevitably lose coverage on bots that were
running these tests without a local libc++. Arguably those weren't
really testing the right thing. But for vendors with LLDB forks it might
have been useful to at least know that the tests on the fork don't fail
against the system libc++.
Confirmed that the libc++ pre-merge CI still runs these tests (since it
uses the explicit `--category libc++` dotest flag). Also confirmed that
LLDB pre-merge CI runs the tests (because it builds `libcxx` locally).
**Workaround**
If you do need want to run libc++ tests against the system stdlib, you
can invoke `lldb-dotest` with the `--category libc++` flag:
```
./path/to/build/lldb-dotest --category libc++
OR
./path/to/build/bin/llvm-lit -sv --param dotest-args='--category libc++' "/path/to/monorepo/lldb/test/API
```
rdar://136231390
This paper removes the constraint that a static variable or function
cannot be used within an extern inline function. The diagnostic is still
being produced in earlier language modes for conformance reasons but has
always been accepted as an extension.
The compiler can't defer the conversion of legacy DATA-style
/initializers/ in component declarations to their init() expressions to
the general DATA statement conversion pass, since default component
values must be present during structure constructor analysis. So move
their conversions into name resolution and handle them at the same times
as standard '=' initializers are processed. Avoid any potential problems
with type parameters being used as repetition counts or values by
disallowing legacy DATA-style initializers in PDTs.
Fixes https://github.com/llvm/llvm-project/issues/161989.
When processing the KIND= values of type specifications in parameterized
derived type component declarations, it turns out to be necessary to
analyze their expressions' parse trees rather than to just fold their
typed expression representations. The types of the subexpressions may
depend on the values of KIND parameters.
Further, when checking the values of KIND= actual arguments to type
conversion intrinsic functions (e.g., INT(..., KIND=)) that appear in
KIND specifiers for PDT component declarations, don't emit an error for
the derived type definition, but instead emit them for derived type
instantiations.
Fixes https://github.com/llvm/llvm-project/issues/161961.
Audit the use of std::optional<bool> as a tri-state logical value in
flang, correct a couple cases that need ".value_or()", add some explicit
".has_value()" calls, and document the possible pitfalls.
As a common language extension, this compiler accepts a structure
constructor whose first value has no keyword and whose type matches an
ancestral type as if the constructor had had a keyword whose name was
the ancestral type. For example, given
TYPE PARENT; REAL X; END TYPE
TYPE, EXTENDS(PARENT) :: CHILD; END TYPE
we accept the nonconforming constructor "child(parent(1.))" as if it had
been the conforming "child(1.)" or "child(parent=parent(1.))".
The detection of this case needs to be constrained a bit to avoid a
false positive misinterpretation of conforming code in the case where
the actual first component of the derived type is a POINTER or
ALLOCATABLE whose type and rank would allow it to correspond with the
keywordless first value in the component value list.
Fixes https://github.com/llvm/llvm-project/issues/161887.
Currently AFAICT we don't have a way to get the MCP server socket after
it started. So this change introduces a new `protocol-server` subcommand
that allows us to query the location of a running server:
```
(lldb) protocol-server start MCP listen://localhost:0
MCP server started with connection listeners: connection://[::1]:36051, connection://[127.0.0.1]:36051
(lldb) protocol-server get MCP
MCP server connection listeners: connection://[::1]:36051, connection://[127.0.0.1]:36051
(lldb) protocol-server stop MCP
(lldb) protocol-server get MCP
error: MCP server is not running
```
Making the choice more clear from the API name, otherwise it'd be very easy for one to just "not bother" with the `MDFrom`, especially since it is optional and follows the optional `Name` - but this time we'd have a harder time detecting it's effectivelly dropped metadata.
This PR adds some tests for covering some useful corner cases.
1. more tests for `vector.shape_cast` distribution.
2. testing for `MoveFuncBodyToWarpOp` pattern that was not possible
before.
#140210 added `#include "clang/Frontend/FrontendDiagnostic.h"` to
clang/lib/Sema/SemaAMDGPU.cpp, but Frontend itself has a dependency on
Sema. This creates a layering issue as described in
https://llvm.org/docs/CodingStandards.html#library-layering.
Fortunately, d076608d58 made this easy to
fix, as clang/Frontend/FrontendDiagnostic.h just forwards to
clang/Basic/DiagnosticFrontend.h, so it's trivial to make this depend on
basic instead of frontend.
