I was reported that with commit:
https://github.com/llvm/llvm-project/commit/d3963051c490

gcc-9.2 is giving the warning below.
This should help (I have no gcc 9.2 to test).

[ 57%] Building CXX object tools/obj2yaml/CMakeFiles/obj2yaml.dir/elf2yaml.cpp.o
/llvm/tools/obj2yaml/elf2yaml.cpp: In instantiation of ‘llvm::Expected<llvm::ELFYAML::Object*>
{anonymous}::ELFDumper<ELFT>::dump() [with ELFT = llvm::object::ELFType<llvm::support::little, false>]’:
/llvm/tools/obj2yaml/elf2yaml.cpp:1218:31:   required from ‘llvm::Error elf2yaml(llvm::raw_ostream&,
const llvm::object::ELFFile<ELFT>&) [with ELFT = llvm::object::ELFType<llvm::support::little, false>]’
/llvm/tools/obj2yaml/elf2yaml.cpp:1231:47:   required from here
/llvm/tools/obj2yaml/elf2yaml.cpp:207:41: warning: comparison of integer expressions of different
signedness: ‘llvm::support::detail::packed_endian_specific_integral<unsigned int, llvm::support::little, 1>::value_type’ {aka ‘unsigned int’} and ‘int’ [-Wsign-compare]
  207 |     if (!SymTab || SymTabShndx->sh_link != SymTab - Sections.begin())
/llvm/tools/obj2yaml/elf2yaml.cpp: In instantiation of ‘llvm::Expected<llvm::ELFYAML::Object*>
{anonymous}::ELFDumper<ELFT>::dump() [with ELFT = llvm::object::ELFType<llvm::support::big, false>]’:
...

As noted on D74621, the bswap intrinsic has a self imposed limitation that the type's bitwidth must be divisible by 16, but there's no reason that APInt::byteSwap must have the same limitation, given that it can already handle any byte width.

This commit fixes the broken tests after
commit b6a9fe20
on the expensive check builder:
http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-ubuntu/builds/2884

We can just byteSwap the entire uint64_t VAL and then shift down into place like we do for the multi-word case.

rGf0181cc7 added specific tests up to i64, this adds a general loop to test some basic byte moves for larger APInts.

This hopefully fixes up the expensive checks bot.

Summary:
This patch is extracted from D74308.

It patches all usages of WithColor::error() and WithColor::warning
in DebugInfoDWARF library.

Depends on D74481

Reviewers: jhenderson, dblaikie, probinson, aprantl, JDevlieghere

Reviewed By: JDevlieghere

Subscribers: hiraditya, llvm-commits

Tags: #llvm

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

deduction.

As suggested in https://github.com/llvm/llvm-project/issues/120, don't try to
generate the extension file from clang, only do the linking step.

Fixes the regression introduced in D74464 when running cmake inside the clang
directory.

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

Summary:
this review is extracted from D74308.

It creates two error handlers which allow to redefine error
reporting routine and should be used for all places
where errors are reported:

  std::function<void(Error)> RecoverableErrorHandler = defaultErrorHandler;
  std::function<void(Error)> WarningHandler = defaultWarningHandler;

It also creates accessors to above handlers which should be used to
report errors.

  function_ref<void(Error)> getRecoverableErrorHandler() {
    return RecoverableErrorHandler;
  }

  function_ref<void(Error)> getWarningHandler() { return WarningHandler; }

It patches all error reporting places inside DWARFContext and DWARLinker.

Reviewers: jhenderson, dblaikie, probinson, aprantl, JDevlieghere

Reviewed By: jhenderson, JDevlieghere

Subscribers: hiraditya, llvm-commits

Tags: #llvm, #debug-info

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

In addition to a single bit per memory locations, e.g., globals and
arguments, we now collect more information about the actual accesses,
e.g., what instruction caused it, was it a read/write/read+write, and
what the underlying base pointer was. Follow up patches will make
explicit use of this.

Reviewed By: uenoku

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

In b91c2673 I accidentally introduced fixes that were not necessary
after 1a93285c. All but the `llvm_unreachable` are reverted again.

Add support for Master and Critical directive in the OMPIRBuilder. Both make use of a new common interface for emitting inlined OMP regions called `emitInlinedRegion` which was added in this patch as well.

Also this patch modifies clang to use the new directives when  `-fopenmp-enable-irbuilder` commandline option is passed.

Reviewed By: jdoerfert

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

Summary: - add ArrayAttr::operator[](unsigned idx)

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

This swaps out the OpenMPDefaultClauseKind enum with a
llvm::omp::DefaultKind enum which is stored in OMPConstants.h.

This should not change any functionality.

Reviewed By: jdoerfert

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

Follow-up for D74006.

Follow-up for D74006.

Summary:
When using strict fp, it is required to update the
chain when performing integer type promotion of a
operand to a integer to floating point conversion.

Reviewers: craig.topper, john.brawn

Reviewed By: craig.topper

Subscribers: kristof.beyls, hiraditya, llvm-commits

Tags: #llvm

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

Follow-up for D74006.

When the integrated assembler is used, we use SHF_LINK_ORDER.  The
linked-to symbol is part of ELFSectionKey, thus we can omit the unique
ID.

https://bugs.llvm.org/show_bug.cgi?id=44775

This rule has been implemented by GNU as https://sourceware.org/ml/binutils/2020-02/msg00028.html (binutils >= 2.35)

It allows us to simplify

```
.section .foo,"o",foo,unique,0
.section .foo,"o",bar,unique,1  # different section
```

to

```
.section .foo,"o",foo
.section .foo,"o",bar  # different section
```

We consider the two `.foo` different even if the linked-to symbols foo and bar
are defined in the same section.  This is a deliberate choice so that we don't
need to know the section where foo and bar are defined beforehand.

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

While the function return updateImpl did only look at call sites the
manifest method looked at return values. If we don't do this during the
updateImpl we might create new abstract attributes during manifest. This
is a problem when it comes to liveness information.

If we simplify a function return value we have to modify the return
instructions.

If we see an undef we cannot assume it's the same as "no value". For now
we just collapse it to 0.

If we know a call was not needed we might have ended up deleting it even
if it was in a different SCC. This prevents us from doing so.

We can strip casts in AANoAlias but that might cause us to end up with a
non-pointer type. We do properly handle that case now.

This caused an error when passes iterated over cached assumptions in the
tracker and assumed them to be `null` or an instruction. I failed to
create a test case so far.