cast PredefinedExpr such as `__func__` to const char* should be accpetted.

Reviewed By: PiotrZSL

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

Thread sanitizer reports a data race in Process.cpp in the usage of
m_process_input_reader. Fix this data race by introducing a mutex
guarding the access to this variable.

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

ThreadSanitizer reports the following issue:

```
  Write of size 8 at 0x00010a70abb0 by thread T3 (mutexes: write M0):
    #0 lldb_private::ThreadList::Update(lldb_private::ThreadList&) ThreadList.cpp:741 (liblldb.18.0.0git.dylib:arm64+0x5dedf4) (BuildId: 9bced2aafa373580ae9d750d9cf79a8f32000000200000000100000000000e00)
    #1 lldb_private::Process::UpdateThreadListIfNeeded() Process.cpp:1212 (liblldb.18.0.0git.dylib:arm64+0x53bbec) (BuildId: 9bced2aafa373580ae9d750d9cf79a8f32000000200000000100000000000e00)

  Previous read of size 8 at 0x00010a70abb0 by main thread (mutexes: write M1):
    #0 lldb_private::ThreadList::GetMutex() const ThreadList.cpp:785 (liblldb.18.0.0git.dylib:arm64+0x5df138) (BuildId: 9bced2aafa373580ae9d750d9cf79a8f32000000200000000100000000000e00)
    #1 lldb_private::ThreadList::DidResume() ThreadList.cpp:656 (liblldb.18.0.0git.dylib:arm64+0x5de5c0) (BuildId: 9bced2aafa373580ae9d750d9cf79a8f32000000200000000100000000000e00)
    #2 lldb_private::Process::PrivateResume() Process.cpp:3130 (liblldb.18.0.0git.dylib:arm64+0x53cd7c) (BuildId: 9bced2aafa373580ae9d750d9cf79a8f32000000200000000100000000000e00)
```

Fix this by only using the mutex in ThreadList and removing the one in
process entirely.

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

AAIndirectCallInfo will collect information and specialize indirect call
sites. It is similar to our IndirectCallPromotion but runs as part of
the Attributor (so with assumed callee information). It also expands
more calls and let's the rest of the pipeline figure out what is UB, for
now. We use existing call promotion logic to improve the result,
otherwise we rely on the (implicit) function pointer cast.

This effectively "fixes" #60327 as it will undo the type punning early
enough for the inliner to work with the (now specialized, thus direct)
call.

Fixes: https://github.com/llvm/llvm-project/issues/60327

To work around an address sanitizer issue on macOS where
environment_check prints a spurious stderr msg when executing,

environment_check(41292,0x113e7a600) malloc: nano zone abandoned due to inability to preallocate reserved vm space.

And TestClient::Continue() which intends to continue to exit
instead sees the stderr output streamed, and doesn't handle that
unexpected output.  Easiest to disable stdin/stdout for this
one test case to avoid this corner case issue with this TestClient.cpp
way of expecting a stop reply packet after continuing.

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

Reviewed By: mehdi_amini

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

Obsoleted by target=

Similar to e6e43629

This changes the definition if isSectionBitcode to only be valid for the
.llvm.lto section, since this API is only called from LTO, and the
.llvmbc section was not intended to be used for LTO. This allows the
gold plugin to keep its existing behavior without introducing any
significant changes.

Reviewed By: MaskRay, nikic

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

This patch adds support to lld for --fat-lto-objects. We add a new
--fat-lto-objects option to LLD, and slightly change how it chooses input
files in the driver when the option is set.

Fat LTO objects contain both LTO compatible IR, as well as generated object
code. This allows users to defer the choice of whether to use LTO or not to
link-time. This is a feature available in GCC for some time, and makes the
existing -ffat-lto-objects option functional in the same way as GCC's.

If the --fat-lto-objects option is passed to LLD and the input files are fat
object files, then the linker will chose the LTO compatible bitcode sections
embedded within the fat object and link them together using LTO. Otherwise,
standard object file linking is done using the assembly section in the object
files.

The previous version of this patch had a missing `REQUIRES: x86` line in
`fatlto.invalid.s`. Additionally, it was reported that this patch caused
a test failure in `expo...

Shorten "DWARF Extensions supported by LLDB" to just "DWARF Extension".

The mach exception data may not be doubleword aligned when we receive
it.  We use memcpy to align it later in this method when we save
the data, but for printing the value at the top, we need to do the
same or ubsan can trigger when LOG_EXCEPTIONS is enabled in
debugserver.

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

This reverts commit b10c2f84.

Need to add the phabracator line to the message.

The mach exception data may not be doubleword aligned when we receive
it.  We use memcpy to align it later in this method when we save
the data, but for printing the value at the top, we need to do the
same or ubsan can trigger when LOG_EXCEPTIONS is enabled in
debugserver.

This patch fixes TestSaveCrashlog.py failure introduces by eef5eadb

,
which restricts the number of positional argument for the output file to 1.

I expected to get the output file but `argparse` puts the object in a
list (even by constrained to a singled positional argument).

Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>

The linker wrapper runs LTO internally, so it needs to know the
optimization level the user requested, if any. Previously this was only
done in `-foffload-lto` mode as we were assuming that this would enble
LTO. However, AMDGPU always performs LTO, and it's possible to run clang
on object files to link without passing this flag. So we should just
respect it always.

Reviewed By: jdoerfert

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

This patch gets clang-6 building with LLDB. The move from makeArrayRef
to deduction guides in 984b800a is
tripping up clang-6 on Ubuntu 18.04.

Related to issue #64782.

assert is more appropriate here and fixes
`runtime error: execution reached an unreachable program point` in a
-DLLVM_USE_SANITIZER=Undefined build (-fno-sanitize-recover=all causes
llc to exit instead of crash (report_fatal_error)) when testing
MachineVerifier/test_g_assert_[sz]ext.mir.

Fixes #64818.

Make it more obvious that these are project ideas rather than say
ongoing projects.

Move WebAssemblyUtilities from Utils to the CodeGen library. It
primarily deals in MIR layer types, so it really lives in the CodeGen
library.

Move a variety of other things around to try create better separation.

See issue #64166 for more info on layering.

Move llvm/include/CodeGen/WasmAddressSpaces.h back to
llvm/lib/Target/WebAssembly/Utils.

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

The current "Continuous Integration" is pretty scarce. All we really
need is a link to buildbot and GreenDragon. Move this under testing.

Serialize global C++ variable templates and specializations.

Depends on D157076

Reviewed By: dang

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

It improves shuffle instructions estimation and improves vectorization
outcome.

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

When processing multiple architectures in parallel, we need to protect
access to stdio with a mutex. We already have a mutex for that purpose,
but it was only used in the DWARFLinker. This patch protects writes to
stdio in driver.

Add has_template template, DeclarationFragmentBuilder functions, and tests for class templates, specializations/partial specs, and concepts.

Depends on D157007

Reviewed By: dang

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

Tested by llvm/test/MC/ARM/basic-thumb2-instructions.s.
Caught by newer -fsanitize=signed-integer-overflow (D156821).

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

This patch adds operand type counts to the detailed function properties
analysis. This is intended to enable more interesting and detailed
comparisons across different languages on specific metrics (like usage
of inline assembly or global values).

Reviewed By: jdoerfert

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

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

This reverts commit ac9a76d7.

Previously an abstract class has no pure virtual function.  It causes build error on some bots.

Tested by llvm/test/tools/llvm-readobj/ELF/relocations.test

A couple years ago, StructuralHash was created, copying the exact
hashing implementation from FunctionComparator (minus a couple small
details/refactorings). Since then, the hashing implementation has not
diverged, but several other areas, like unit testing, have diverged
significantly, with StructuralHash getting more attention in these
areas. This patch aims to consolidate the two hashing functions into
StructuralHash given they do the exact same thing and having less
divergence in areas like unit testing would be beneficial.

The original aim at creating a separate StructuralHash was to make the
implementation divergent and capture additional details like instruction
operands (which neither hashing implementation does currently). The
MergeFunctions pass doesn't need these detaisl, but verification of pass
return values would benefit from this additional data. Setting an option
to calculate these values would allow for divergent behavior where
appropriate while reducing code duplication with little runtime
overhead.

Reviewed By: aeubanks

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

This brings most of the enable_ifs in libc++ to the same style. It also has the nice side-effect of reducing the size of names of these symbols, since the arguments don't get mangled anymore.

Reviewed By: #libc, Mordante

Spies: Mordante, libcxx-commits

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

This reverts commit 17831857,
which broke the buildbots, starting with when it was first built in https://lab.llvm.org/buildbot/#/builders/85/builds/18390

(N.B. I think the patch is uncovering real bugs; the revert
is simply to keep the tree green and the buildbots useful, because I'm not confident how to
fix-forward all the found bugs.)

When using the `crashlog` command in batch mode, most users only care
about the crashed thread and end up having to scroll past all the
non-crashed threads, which is not a good user experience.

Now that `-c|--crashed-only` is set by default, we should also apply
that behavior for batch mode: Only the crashed thread and "Application
Specific Backtrace" threads will be shown to the user in batch mode.

The user will still have the ability to show all the threads if they use
`--no-crashed-only` which will parse the symbols from the report, or
with `-a|--load-all-images` which will fetch binaries and debug info
from the build record and symbolicate every thread.

rdar://106329893

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



Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>

This patch adds support to the "Last Exception Backtrace" to the
`crashlog` command.

This metadata is homologous to the "Application Specific Backtrace",
however the format is closer to a regular stack frame.

Since the thread that "contains" the "Last Exception Backtrace" doesn't
really exist, this information is displayed when requesting an extended
backtrace of the crashed thread, similarly to the "Application Specific
Backtrace".

To achieve that, this patch includes some refactors and fixes to the
existing "Application Specific Backtrace" handling.

rdar://113046509

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



Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>