This reverts commit 02cc8d698c because it
caused buildbot failures. The issue appears to be simply that we need to
only enable debuginfod when the HTTPClient has been initialized by the
running tool, since InitLLVM does not do the initialization step anymore.
This can be unsigned long or unsigned long long depending on where it's
compiled. Use the ugly portable way.
PlatformWindows.cpp:397:63: warning: format specifies type 'unsigned long long' but the argument has type 'uint64_t' (aka 'unsigned long')
This commit improves the fix-its of modernize-pass-by-value by
no longer proposing partial fixes. In the presence of using/typedef,
we failed to rewrite the function signature but still adjusted the
function body. This led to incorrect, partial fix-its. Instead, the
check now simply doesn't offer any fixes at all in such a situation.
Use `= delete` for member functions that are marked with `// = delete;`
Reviewed By: ldionne, Quuxplusone, #libc
Spies: jloser, libcxx-commits
Differential Revision: https://reviews.llvm.org/D115291
Adds a fallback to use the debuginfod client library (386655) in `findDebugBinary`.
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D113717
D114072 allows filtering out the warnings for headers behind `// IWYU pragma:
keep`. This is the first step towards more useful IWYU pragmas support and
fine-grained control over the IncludeCleaner warnings.
Reviewed By: kadircet
Differential Revision: https://reviews.llvm.org/D115345
There is a pointer to the DataLayout in SelectionDAGBuilder called
'DL' that is hardly ever used. In most cases the code seems to just
use `DAG.getDataLayout()` instead. Given that DL is also often used
as a shadowed variable for the debug location it seems sensible to
just kill off the few remaining uses and be consistent with the rest
of the code.
Differential Revision: https://reviews.llvm.org/D114451
Prior to the introduction of the FLUSH statement in Fortran 2003,
implementations provided a FLUSH subroutine.
We can't yet put Fortran code into the runtime, so this subroutine
is in C++ with a Fortran-mangled entry point name.
Differential Revision: https://reviews.llvm.org/D115289
This can be viewed as recognizing that multiply-by-power-of-2 doesn't
have a carry into the top bit of an M-bit * N-bit number.
Enhancing canonicalization of mul -> select might also handle some of
these if we were ok with increasing instruction count with casts in
some cases.
This doesn't help https://llvm.org/PR49055 , but it's a simpler
pattern that we miss.
Note: "-sccp" already gets these examples using a constant
range analysis.
Differential Revision: https://reviews.llvm.org/D114962
There's a lot of history behind this, so here's a summary:
1. I stopped forcing -fPIC when building the runtimes in 30f305efe2,
before the LLVM 9 release back in 2019.
2. Someone complained that libc++.a couldn't be used in shared libraries
built without -fPIC (http://llvm.org/PR43604) since the LLVM 9 release.
This had been caused by my removal of -fPIC when building libc++.a in (1).
3. I suggested two ways of fixing the issue, the first being to force
-fPIC back unconditionally (http://llvm.org/D104328), and the second
being to specify that option explicitly when building the LLVM release
(http://llvm.org/D104327). We converged on the first solution.
4. I landed D104328, which forced building the runtimes with -fPIC.
This was included in the LLVM 13.0 release.
5. People complained about that and requested that we be able to
customize this setting (basically we should have done the second
solution).
This patch makes it such that the LLVM release script will specifically
ask for building with -fPIC using CMAKE_POSITION_INDEPENDENT_CODE,
however by default the runtimes will not force that option onto users.
This patch has the unintended effect that Clang and the LLVM libraries
(not only the runtime ones like libc++) will also be built with -fPIC
in the release. It would be better if we could specify that -fPIC is to
be used only when building the runtimes, however this is left as a
future improvement. The release should probably be using a bootstrapping
build and passing those options to the stage that builds the runtimes
only, see https://reviews.llvm.org/D112748 for that change.
Differential Revision: https://reviews.llvm.org/D110261
This patch introduces a bunch of builder functions
to create function calls to runtime ragged arrays functions.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D114535
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
These tests doesn't currently make use of any fast math flag other than
contract. This will change in D109525 when a dependency on nsz will be
introduced where negation is involved.
Regardless that specification requires thread_limit to be positive,
it is better to warn user instead of crash in case the value is negative.
Differential Revision: https://reviews.llvm.org/D115340
These tests were spuriously failing on Windows due to path separators getting
flipped from `/` to `\\` in various parts of dexter:
test_add_breakpoint_with_source_root_dir
test_get_step_info
test_get_step_info_no_source_root_dir
Tested on Windows and Linux.
Patch written by @TWeaver.
Reviewed By: jmorse
Differential Revision: https://reviews.llvm.org/D115338
We can be in situations where And 1 zext nodes will not have been yet,
preventing us from detecting removable cmpz/csinc patterns. This peeks
through those nodes allowing us to simplify more code.
Differential Revision: https://reviews.llvm.org/D115176
We avoid this fold in the more general cases where we use FoldOpIntoSelect.
That's because -- unlike most binary opcodes -- 'div' can't usually be
speculated with a variable divisor since it can have immediate UB. But in
the case where both arms of the select are constants, we can safely evaluate
both sides and eliminate 'div' completely.
This is a follow-up to the equivalent fold for 'rem' opcodes:
D115173 / f65be726ab
Clang doesn't offer these fixes I guess for a couple of reasons:
- where to insert includes is a formatting concern, and clang shouldn't
depend on clang-format
- the way clang prints diagnostics, we'd show a bunch of basically irrelevant
context of "this is where we'd want to insert the include"
Maybe it's possible to hack around 1, but 2 is still a concern.
Meanwhile, bolting this onto include-fixer gets the job done.
Fixes https://github.com/clangd/clangd/issues/355
Fixes https://github.com/clangd/clangd/issues/937
Differential Revision: https://reviews.llvm.org/D114667
This patch removes the white space and trailing bracket to make the checks consistent and verbose direct/indirect string agnostic for AIX compatibility.
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D115287
In the isDependence function the code does not try hard enough
to determine the dependence between types. If the types are
different it simply gives up, whereas in fact what we really
care about are the type sizes. I've changed the code to compare
sizes instead of types.
Reviewed By: fhahn, sdesmalen
Differential Revision: https://reviews.llvm.org/D108763
The test for this functionality was failing on the darwin bot, because
the entries came out in opposite order. While this does not impact
functionality, and the algorithm that produces it is technically
deterministic (the nondeterminism comes from the contents of the host
environment), it seems like it would be more user-friendly if the
entries came out in a more predictible order.
Therefore I am adding the sort call to the actual code instead of
relaxing test expectations.
This will allow the IncludeCleaner to suppress warnings on the lines with "IWYU
pragma: keep".
Clang APIs are not very convinient, so the code has to navigate around it.
Reviewed By: kadircet
Differential Revision: https://reviews.llvm.org/D114072
This adds a new option `dialectFilter` to BufferizationOptions. Only ops from dialects that are allow-listed in the filter are bufferized. Other ops are left unbufferized. Note: This option requires `allowUnknownOps = true`.
To make use of `dialectFilter`, BufferizationOptions or BufferizationState must be passed to various helper functions.
The purpose of this change is to provide a better infrastructure for partial bufferization, which will be fully activated in a subsequent change.
Differential Revision: https://reviews.llvm.org/D114691
Summary:
The Colours array is apparently the source of TSAN errors. It is
unnecessary and was there to ease readability of the code. Remove it to
clean up the TSAN errors.
Author: Jamie Schmeiser <schmeise@ca.ibm.com>
Reviewed By: aeubanks (Arthur Eubanks)
Differential Revision: https://reviews.llvm.org/D115175
The `default_triple` requirement is redundant if the test specifies the triple, so this patch removes it.
Reviewed By: hubert.reinterpretcast
Differential Revision: https://reviews.llvm.org/D115048
See D114666 for proposed code change to instsimplify.
The difference between the CHECK result of these 2 tests
highlights missed folds in instsimplify
(e.g. (icmp eq (xor X, true), false) -> X) that are
already being handled by instcombine.
The tests are based on:
llvm/test/Transforms/InstSimplify/icmp-bool-constant.ll
Differential Revision: https://reviews.llvm.org/D115209
In addition to being more consistent with our approach for helpers, this
solves an actual issue where <cmath> was using numeric_limits but never
including the <limits> header directly. In a normal setup, this is not
an issue because the <math.h> header included by <cmath> does include
<limits>. However, I did stumble upon some code where that didn't work,
most likely because they were placing their own <math.h> header in front
of ours. I didn't bother investigating further.
Differential Revision: https://reviews.llvm.org/D115282
Test is using "next" commands to make progress in the process. D115137
added an additional statement to the program, without adding a command
to step over it. This only seemed to matter for the libc++ flavour of
the test, possibly because libstdc++ list is "empty" in its
uninitialized state.
Since moving with step commands is a treacherous, this patch adds a
run-to-breakpoint command to the test. It only does this for the
affected step, but one may consider doing it elsewhere too.
This patch translates HIP kernels to SPIR-V kernels when the HIP
compilation mode is targeting SPIR-S. This involves:
* Setting Cuda calling convention to CC_OpenCLKernel (which maps to
SPIR_KERNEL in LLVM IR later on).
* Coercing pointer arguments with default address space (AS) qualifier
to CrossWorkGroup AS (__global in OpenCL). HIPSPV's device code is
ultimately SPIR-V for OpenCL execution environment (as
starter/default) where Generic or Function (OpenCL's private) is not
supported as storage class for kernel pointer types. This leaves the
CrossWorkGroup to be the only reasonable choice for HIP buffers.
Reviewed By: yaxunl
Differential Revision: https://reviews.llvm.org/D109818
Qemu normally forwards its (host) environment variables to the emulated
process. While this works fine for most variables, there are some (few, but
fairly important) variables where this is not possible. LD_LIBRARY_PATH
is the probably the most important of those -- we don't want the library
search path for the emulated libraries to interfere with the libraries
that the emulator itself needs.
For this reason, qemu provides a mechanism (QEMU_SET_ENV,
QEMU_UNSET_ENV) to set variables only for the emulated process. This
patch makes use of that functionality to pass any user-provided
variables to the emulated process. Since we're piggy-backing on the
normal lldb environment-handling mechanism, all the usual mechanism to
provide environment (target.env-vars setting, SBLaunchInfo, etc.) work
out-of-the-box, and the only thing we need to do is to properly
construct the qemu environment variables.
This patch also adds a new setting -- target-env-vars, which represents
environment variables which are added (on top of the host environment)
to the default launch environments of all (qemu) targets. The reason for
its existence is to enable the configuration (e.g., from a startup
script) of the default launch environment, before any target is created.
The idea is that this would contain the variables (like the
aforementioned LD_LIBRARY_PATH) common to all targets being debugged on
the given system. The user is, of course, free to customize the
environment for a particular target in the usual manner.
The reason I do not want to use/recommend the "global" version of the
target.env-vars setting for this purpose is that the setting would apply
to all targets, whereas the settings (their values) I have mentioned
would be specific to the given platform.
Differential Revision: https://reviews.llvm.org/D115246
Change to use Ctx.reportError() instead of llvm_unreachable for
better error handling. Also correct evaluateAsRelocatableImpl().
Reviewed By: simoll
Differential Revision: https://reviews.llvm.org/D115251
Also add tests to check that we print the warning in the right
circumstances.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D114877
This patch extends the "is all active predicate" check to cover
cases where the predicate is casted but in a way that doesn't
change its "all active" status.
Differential Revision: https://reviews.llvm.org/D115047
Butygin