This revision is a part of a series of patches extending AddressSanitizer C++ container overflow detection capabilities by adding annotations, similar to those existing in std::vector, to std::string and std::deque collections. These changes allow ASan to detect cases when the instrumented program accesses memory which is internally allocated by the collection but is still not in-use (accesses before or after the stored elements for std::deque, or between the size and capacity bounds for std::string).

The motivation for the research and those changes was a bug, found by Trail of Bits, in a real code where an out-of-bounds read could happen as two strings were compared via a std::equals function that took iter1_begin, iter1_end, iter2_begin iterators (with a custom comparison function). When object iter1 was longer than iter2, read out-of-bounds on iter2 could happen. Container sanitization would detect it.

This revision extends a compiler-rt ASan sanitization API function sanitizer_annotate_contiguous_container used to sanitize/annotate containers like std::vector to support different allocators and situations when granules are shared between objects. Those changes are necessary to support annotating objects' self memory (in contrast to annotating memory allocated by an object) like short std::basic_string (with short string optimization). That also allows use of non-standard memory allocators, as alignment requirement is no longer necessary.

This also updates an API function to verify if a double ended contiguous container is correctly annotated (__sanitizer_verify_contiguous_container).

If you have any questions, please email:
advenam.tacet@trailofbits.com
disconnect3d@trailofbits.com

Reviewed By: #sanitizers, vitalybuka

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

Disable the test case: 06-dwarf-full-logical-view.test

It produces incorrect data on ARM:

  https://lab.llvm.org/buildbot/#/builders/182/builds/4232
  https://lab.llvm.org/buildbot/#/builders/187/builds/9483

Expected:
   189 (100.00%) : [0x000000000b][001]    {CompileUnit}
   110 ( 58.20%) : [0x000000002a][002] 2    {Function}
    27 ( 14.29%) : [0x0000000071][003]        {Block}

Generated:
  3432 (  0.00%) : [0x000000000b][001]    {CompileUnit}
  3351 (  0.00%) : [0x000000002a][002] 2    {Function}
  3234 (  0.00%) : [0x0000000071][003]        {Block}

Skip template ctors in modernize-use-equals-default,
such constructors may be enabled/disabled via SFINAE,
it is not safe to make them "= default".

Test plan: ninja check-all

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

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

There is a memory leak.
See comments in https://reviews.llvm.org/D125783

Need both add_custom_command to resolve file-level dependency and add_custom_target to resolve target-level dependency.
From CMake add_custom_command doc:
Do not list the output in more than one independent target that may build in parallel or the two instances of the rule may conflict (instead use the add_custom_target() command to drive the command and make the other targets depend on that one).

${CMAKE_CURRENT_BINARY_DIR}/${bclib_name} is used by multiple targets and thus requires a custom target to avoid racing.

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

For more details about these instructions, please refer to the latest ISE document: https://www.intel.com/content/www/us/en/develop/download/intel-architecture-instruction-set-extensions-programming-reference.html

Reviewed By: pengfei, skan

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

Use Printable to enhance syntax, remove duplication, unify.

Reviewed By: arsenm, rampitec

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

I cannot repro this with CMake, but on Bazel this is failing with
```
error: incomplete result type 'mlir::spirv::TargetEnvAttr' in function definition
[...]
note: in instantiation of member function 'std::function<mlir::spirv::TargetEnvAttr (mlir::spirv::ModuleOp)>::function' requested here
createUnifyAliasedResourcePass(GetTargetEnvFn getTargetEnv = nullptr);
```

Reviewed By: antiagainst

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

For more details about these instructions, please refer to the latest ISE document: https://www.intel.com/content/www/us/en/develop/download/intel-architecture-instruction-set-extensions-programming-reference.html

Reviewed By: pengfei, skan

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

Strict WQM does not require a WQM transistion if it occurs within
an existing WQM section.
This occurs heavily in GFX11 pixel shaders with LDS_PARAM_LOAD.
Which leads to unnecessary EXEC mask manipulation.

To avoid these transitions, detect WQM -> Strict WQM -> WQM
and substitute new ENTER_PSEUDO_WM/EXIT_PSEUDO_WM markers instead.
These are treat similarly by WWM register pre-allocation pass,
but do not manipulate EXEC or use registers to save EXEC state.

Reviewed By: piotr

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

Add the atomic subroutine, atomic_fetch_xor, to the list of
intrinsic subroutines, add its last dummy argument to a check
for coindexed-object, and update test.

Reviewed By: PeteSteinfeld

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

There are conditionalized calls to an SPI in HostInfoMacOSX.mm
to test if lldb is being built against a pre-macOS 10.12 SDK,
or being run on a pre-macOS 10.12 system.  macOS 10.12 was released
six years ago, and I don't know of any active users of this system
so let's remove the checks.

Differential Revision: https://reviews.llvm.org/D136900
rdar://101652340

Fixes 1st issue of https://github.com/llvm/llvm-project/issues/58061

Reviewed By: dmgreen, efriedma
Differential Revision: https://reviews.llvm.org/D136244

Fix the problem that it was treating member functions as non-member functions
when trying to get the parameter size. This causes some non-parameter variables
showing up in function signature. Suprisingly,
`cantFail(TypeDeserializer::deserializeAs<ProcedureRecord>(...))` just sliently
parse it without error and gave the wrong result.

It's hard to test it. This only causes problem when `params_remaining`
is larger than the real parameter size. If it's smaller, we also check
individual local variable's attribute to see it's a parameter. When I trying to
come up with a test, the parameter size is always 0 if we parse LF_MFUNCTION as
LF_PROCEDURE.

Reviewed By: labath

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

Should improve compile time for analysis and vectorization.

Metric: SLP.NumVectorInstructions

Program                                                                                       SLP.NumVectorInstructions
test-suite :: External/SPEC/CINT2017speed/623.xalancbmk_s/623.xalancbmk_s.test  6380.00                   6378.00 -0.0%
test-suite :: External/SPEC/CINT2017rate/523.xalancbmk_r/523.xalancbmk_r.test   6380.00                   6378.00 -0.0%
test-suite :: External/SPEC/CINT2006/483.xalancbmk/483.xalancbmk.test           2023.00                   2022.00 -0.0%
test-suite :: External/SPEC/CINT2006/471.omnetpp/471.omnetpp.test               148.00                    146.00 -1.4%

Generated more vector instructions.

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

Removes __promote when it's just the identity.

Reviewed By: ldionne, #libc

Spies: libcxx-commits, michaelplatings

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

This patch introduces the lowering for xfer ops masked with `vector.mask`.
Vector reductions are not lowered yet because new LLVM intrinsics are needed
in the LLVM dialect.

Reviewed By: nicolasvasilache

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

This MaskingOpInterface provides masking cababilitites to those
operations that implement it. For only is only implemented by the `vector.mask`
operation and it's used to break the dependency between the Vector
dialect (where the `vector.mask` op lives) and operations implementing
the MaskableOpInterface.

Reviewed By: nicolasvasilache

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

Previously, ODS interface generator was placing implementations of the
interface's internal "Model" class template immediately after the class
definitions in the header. This doesn't allow this implementation, and
consequently the interface itself, to return an instance of another
interface if its class definition is emitted below. This creates
undesired ordering effects and makes it impossible for two or more
interfaces to return instances of each other. Change the interface
generator to place the implementations of these methods after all
interface classes.

Reviewed By: dcaballe

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

Update docs to reflect the fact that this flag is on by default now.

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

This reverts commit dad64448 to fix
a crash in https://lab.llvm.org/buildbot/#/builders/74/builds/14584

In some occasions, SBValue::GetError can invalidate its cached
`m_summary_str` member. This in turn invalidates any StringRef variables
pointing to it.

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

Reviewed By: chapuni

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

Reviewed By: rriddle

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

Summary:
The existing implementation of the personality for legacy IBM xlclang++ compiler generated code passes the address of exception object in r14 for the landing pad to retrieve with a call to __xlc_exception_handle(). This clobbers the content of r14 in user code (and potentially, when running cleanup actions, the address of another exception object being passed). This patch changes to use the stack slot reserved for compilers to pass the address. It has been confirmed that xlclang++-generated code does not use this slot.

This is a follow-on of the origibal patch below with a change in comments.
   https://reviews.llvm.org/rGa499051f10a2d0150b60c14493558476039f701a

Reviewed by: hubert.reinterpretcast, cebowleratibm

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

To address unresolved comments in D136185

Reviewed By: aartbik

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

This reverts commit 3d0e9edd.

Breaking HWASAN buildbot:
https://lab.llvm.org/buildbot/#/builders/236/builds/786

Shown by targetted builds breaking at this patch:
Built at this patch: https://lab.llvm.org/buildbot/#/builders/236/builds/803
Built at prior patch: https://lab.llvm.org/buildbot/#/builders/236/builds/804

Reviewed By: wrengr, Peiming

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

Follow-up to 7846d590

Seen here:
https://github.com/gcc-mirror/gcc/blob/16e2427f50c208dfe07d07f18009969502c25dc8/include/dwarf2.def#L805-L806

Currently pseudo probe encoding for a function is like:
	- For the first probe, a relocation from it to its physical position in the code body
	- For subsequent probes, an incremental offset from the current probe to the previous probe

The relocation could potentially cause relocation overflow during link time. I'm now replacing it with an offset from the first probe to the function start address.

A source function could be lowered into multiple binary functions due to outlining (e.g, coro-split). Since those binary function have independent link-time layout, to really avoid relocations from .pseudo_probe sections to .text sections, the offset to replace with should really be the offset from the probe's enclosing binary function, rather than from the entry of the source function. This requires some changes to previous section-based emission scheme which now switches to be function-based. The assembly form of pseudo probe directive is also changed correspondingly, i.e, reflecting the binary function name.

Most of the source functions end up with only one binary function. For those don't, a sentinel probe is emitted for each of the binary functions with a different name from the source. The sentinel probe indicates the binary function name to differentiate subsequent probes from the ones from a different binary function. For examples, given source function

```
Foo() {
  …
  Probe 1
  …
  Probe 2
}
```

If it is transformed into two binary functions:

```
Foo:
   …

Foo.outlined:
   …
```

The encoding for the two binary functions will be separate:

```

GUID of Foo
  Probe 1

GUID of Foo
  Sentinel probe of Foo.outlined
  Probe 2
```

Then probe1 will be decoded against binary `Foo`'s address, and Probe 2 will be decoded against `Foo.outlined`. The sentinel probe of `Foo.outlined` makes sure there's not accidental relocation from `Foo.outlined`'s probes to `Foo`'s entry address.

On the BOLT side, to be minimal intrusive, the pseudo probe re-encoding sticks with the old encoding format. This is fine since unlike linker, Bolt processes the pseudo probe section as a whole and it is free from relocation overflow issues.

The change is downwards compatible as long as there's no mixed use of the old encoding and the new encoding.

Reviewed By: wenlei, maksfb

Differential Revision: https://reviews.llvm.org/D135912
Differential Revision: https://reviews.llvm.org/D135914
Differential Revision: https://reviews.llvm.org/D136394

The path in vimrc was old, replace it with <path-to-this-file> to be
consistent with above.

debugserver parses the Mach-O header & load commands of
binaries; if it does this with a binary whose LC_BUILD
platform enum it does not recognize, it will currently crash.
This patch changes MachProcss::GetPlatformString to return
an optional platform string, and updates the callers to
do the right thing when this optional could not be
provided.

Differential Revision: https://reviews.llvm.org/D136719
rdar://100452994