Granularize the `<filesystem>` header

Reviewed By: Quuxplusone, ldionne, #libc

Spies: libcxx-commits, mgorny

Differential Revision: https://reviews.llvm.org/D115578

Eliminate a bogus operator== overload.
Also, check more intermediate steps in the logic we're checking here.
Some of this simplification is possible only now that we've implemented
more of <ranges>.

Differential Revision: https://reviews.llvm.org/D116002

See also: https://reviews.llvm.org/D111157

Move the handling of brace wrapping after => from unwrapped line
parser to token annotator and clean up the parser.

Differential Revision: https://reviews.llvm.org/D115967

Extracted from D99484. My new plan is to start from the outside and work
inward.

Reviewed By: compnerd

Differential Revision: https://reviews.llvm.org/D115570

Reland integrates build fixes & further review suggestions.

Thanks to @zturner for the initial S_OBJNAME patch!

Differential Revision: https://reviews.llvm.org/D43002

Also revert all subsequent fixes:
- abd1cbf5 [Clang] Disable debug-info-objname.cpp test on Unix until I sort out the issue.
- 00ec4412 [Clang] debug-info-objname.cpp test: explictly encode a x86 target when using %clang_cl to avoid falling back to a native CPU triple.
- cd407f6e [Clang] Fix build by restricting debug-info-objname.cpp test to x86.

If %{exec} sets "--env PATH=single-dir", the directory containing
bash and related shell utils is omitted from the path, which means
that most shell scripts would fail.

(Setting PATH is needed for DLL builds on Windows; PATH fills the same
role as e.g. LD_LIBRARY_PATH on Linux.)

This condition is missed in the current test, because the executor
run.py first resolves the executable to run using the original path,
then invokes that executable with an environment with a restricted
path. Thus the executor is able to run bash, but that bash is then
unable to run further shell commands (other than bash builtins).

Extend the test from "bash --version" to "bash -c 'bash --version'".
This correctly identifies the executor-has-no-bash condition in the
current Windows CI configs, allowing removing 6 cases of
LIBCXX-WINDOWS-FIXME.

Another longterm fix would be to extend run.py with an option like
"--env-prepend PATH=dir", to allow keeping the current path while
adding a directory to it.

Differential Revision: https://reviews.llvm.org/D116117

This is similar to the existing setting LIBCXX_ABI_DEFINES, with
the difference that this also allows setting other defines than
ones that start with "_LIBCPP_ABI_", and allows setting defines
to a specific value.

This allows avoiding using LIBCXX_TEST_COMPILER_FLAGS in two
CI configurations.

Differential Revision: https://reviews.llvm.org/D116109

This allows cross-testing (by setting LIBCXX_EXECUTOR to point
to ssh.py) without making an entirely new test config file.

Implicitly, this also fixes quoting of the python executable name
(which is quoted in test/CMakeLists.txt).

Differential Revision: https://reviews.llvm.org/D115398

Fixes PR52704 : https://github.com/llvm/llvm-project/issues/52704

Differential Revision: https://reviews.llvm.org/D116011

This moves the macro definitions back to __config, but keeps the
improved documentation. 346ef5e5 had broken the MinGW build.

Making callbacks hidden will remove PLT calls.

Reviewed By: vitalybuka

Differential Revision: https://reviews.llvm.org/D116121

In commit 1674d9b6,
I missed adding the updates to existing test cases.
This should bring the bots back to green.

Also, move the setting of the macro closer to its point of use, which
also has the benefit of uncluttering `__config`.

The current code makes the assumption that equality
comparison can be performed with a word comparison
instruction. While this is true if the entire 64-bit
results are used, it does not generally work. It is
possible that the low order words and high order
words produce different results and a user of only
one will get the wrong result.

This patch adds an and of the result words so that
each word has the result of the comparison of the
entire doubleword that contains it.

Differential revision: https://reviews.llvm.org/D115678

Commit 150681f2 increases
cost of producing MMA types (vector pair and quad).
However, it increases the cost for getUserCost() which is
used in unrolling. As a result, loops that contain these
types already (from the user code) cannot be unrolled
(even with the user's unroll pragma). This was an unintended
sideeffect. Reverting that portion of the commit to allow
unrolling such loops.

Differential revision: https://reviews.llvm.org/D115424

Run performance tests in denormal and normal ranges separately and show more detailed results.

Reviewed By: sivachandra

Differential Revision: https://reviews.llvm.org/D116112

They are unused in the new tsan runtime.

Depends on D112604.

Reviewed By: vitalybuka, melver

Differential Revision: https://reviews.llvm.org/D112605

It's unused in the new tsan runtime.

Depends on D112603.

Reviewed By: vitalybuka, melver

Differential Revision: https://reviews.llvm.org/D112604

The new tsan runtime has 2x more compact shadow.
Adjust shadow ranges accordingly.

Depends on D112603.

Reviewed By: vitalybuka, melver

Differential Revision: https://reviews.llvm.org/D113751

Depends on D113983.

Reviewed By: melver

Differential Revision: https://reviews.llvm.org/D113984

If there are multiple processes, it's hard to understand
what output comes from what process.
VReport prepends pid to the output. Use it.

Depends on D113982.

Reviewed By: melver

Differential Revision: https://reviews.llvm.org/D113983

Update now after long operations so that we don't use
stale value in subsequent computations.

Depends on D113981.

Reviewed By: melver

Differential Revision: https://reviews.llvm.org/D113982

Older Go cmd/link used SHT_PROGBITS for .init_array .
Work around the lack of https://golang.org/cl/373734 for a while.
It does not generate .fini_array or .preinit_array

In regular LTO, analyze IR and discard unreachable functions when finding virtual call targets.

Differential Revision: https://reviews.llvm.org/D116056

When linking a 1.2G output (nearly no debug info, 2846621 dynamic relocations) using `--threads=8`, I measured

```
9.131462 Total ExecuteLinker
1.449913 Total Write output file
1.445784 Total Write sections
0.657152 Write sections {"detail":".rela.dyn"}
```

This change decreases the .rela.dyn time to 0.25, leading to 4% speed up in the total time.

* The parallelSort is slow because of expensive r_sym/r_offset computation. Cache the values.
* The iteration is slow. Move r_sym/r_addend computation ahead of time and parallelize it.

With the change, the new encodeDynamicReloc is cheap (0.05s). So no need to parallelize it.

Reviewed By: ikudrin

Differential Revision: https://reviews.llvm.org/D115993

We can't just memoize _supportsVerify in place in format.py, as it
previously was executed in each of the individual processes.

Instead use hasCompileFlag() and add a feature flag for it instead,
which can be used both by tests (that already have such a flag,
locally for one set of tests) and for the testing framework itself.

By using hasCompileFlag(), this also implicitly fixes two other issues:
Previously, _supportsVerify called subprocess.call() directly, which can
interpret command line quoting differently than lit.TestRunner.

(In particular, TestRunner handles arguments quoted by a single quote,
while launching Windows processes with subprocess.call() only supports
double quotes. This allows using shlex.quote(), which uses single quotes,
everywhere - as all commands now go through TestRunner. This should make
41d79093 redundant.)

Secondly, the old _supportsVerify method didn't include %{flags) or
%{compile_flags}.

Differential Revision: https://reviews.llvm.org/D116010

This change allows us to infer access attributes (readnone, readonly) on arguments passed to vararg functions. Since there isn't a formal argument corresponding to the parameter, they'll never be considered part of the speculative SCC, but they can still benefit from attributes on the call site or the callee function.

The main motivation here is just to simplify the code, and remove some special casing. Previously, an indirect vararg call could return more precise results than an direct vararg call which is just weird.

Differential Revision: https://reviews.llvm.org/D115964

This fixes a bug where we would infer readnone/readonly for a function which passed a value to a function which could capture it. With the value captured in memory, the function could reload the value from memory after the call, and write to it. Inferring the argument as readnone or readonly is unsound.

@jdoerfert apparently noticed this about two years ago, and tests were checked in with 76467c4d, but the issue appears to have never gotten fixed.

Since this seems like this issue should break everything, let me explain why the case is actually fairly narrow. The main inference loop over the argument SCCs only analyzes nocapture arguments. As such, we can only hit this when construction the partial SCCs. Due to that restriction, we can only hit this when we have either a) a function declaration with a manually annotated argument, or b) an immediately self recursive call.

It's also worth highlighting that we do have cases we can infer readonly/readnone on a capturing argument validly. The easiest example is a function which simply returns its argument without ever accessing it.

Differential Revision: https://reviews.llvm.org/D115961

1) remove verbose information (function linkage types, alignment, TBAA) 2) remove unused element or replace irrelevant element with null (as placeholders) in virtual table, remove unused definitions of deleted elements accordingly.

Differential Revision: https://reviews.llvm.org/D116071

See: https://lab.llvm.org/buildbot/#/builders/188/builds/7188

[Clang] debug-info-objname.cpp test: explictly encode a x86 target when using %clang_cl to avoid falling back to a native CPU triple.

Converts concat_vectors((trunc (lshr)), (trunc (lshr))) to UZP2
when the shift amount is half the width of the vector element.

Differential Revision: https://reviews.llvm.org/D116021