------------------------------------------------------------------------
r372038 | jcai19 | 2019-09-16 14:47:47 -0700 (Mon, 16 Sep 2019) | 15 lines

[compiler-rt][crt]  make test case nontrivial in check_cxx_section_exists

Summary:
.init_array gets optimized away when building with -O2 and as a result,
check_cxx_section_exists failed to pass -DCOMPILER_RT_HAS_INITFINI_ARRAY
when building crtbegin.o and crtend.o, which causes binaries linked with
them encounter segmentation fault. See https://crbug.com/855759 for
details. This change prevents .init_array section to be optimized away
even with -O2 or higher optimization level.

Subscribers: dberris, mgorny, #sanitizers, llvm-commits

Tags: #sanitizers, #llvm

Differential Revision: https://reviews.llvm.org/D67628
------------------------------------------------------------------------

------------------------------------------------------------------------
r374598 | atanasyan | 2019-10-11 14:51:33 -0700 (Fri, 11 Oct 2019) | 12 lines

[mips] Store 64-bit `li.d' operand as a single 8-byte value

Now assembler generates two consecutive `.4byte` directives to store
64-bit `li.d' operand. The first directive stores high 4-byte of the
value. The second directive stores low 4-byte of the value. But on
64-bit system we load this value at once and get wrong result if the
system is little-endian.

This patch fixes the bug. It stores the `li.d' operand as a single
8-byte value.

Differential Revision: https://reviews.llvm.org/D68778
------------------------------------------------------------------------

------------------------------------------------------------------------
r375077 | sbc | 2019-10-16 20:21:02 -0700 (Wed, 16 Oct 2019) | 10 lines

[lld][WebAssembly] Fix for weak references to data symbols in archives

Fix a bug where were not handling relocations against weakly undefined
data symbol.  Add a test for this case.  Also ensure that the weak
references to data symbols are not pulled in from archive files by
default (but are if `-u <name>` is added to the command line).

Fixes: PR43696

Differential Revision: https://reviews.llvm.org/D69073
------------------------------------------------------------------------

------------------------------------------------------------------------
r374544 | atanasyan | 2019-10-11 05:33:12 -0700 (Fri, 11 Oct 2019) | 12 lines

[mips] Fix loading "double" immediate into a GPR and FPR

If a "double" (64-bit) value has zero low 32-bits, it's possible to load
such value into a GP/FP registers as an instruction immediate. But now
assembler loads only high 32-bits of the value.

For example, if a target register is GPR the `li.d $4, 1.0` instruction
converts into the `lui $4, 16368` one. As a result, we get `0x3FF00000`
in the register. While a correct representation of the `1.0` value is
`0x3FF0000000000000`. The patch fixes that.

Differential Revision: https://reviews.llvm.org/D68776
------------------------------------------------------------------------

------------------------------------------------------------------------
r374548 | atanasyan | 2019-10-11 05:58:37 -0700 (Fri, 11 Oct 2019) | 1 line

[mips] Follow-up to r374544. Fix test case.
------------------------------------------------------------------------

------------------------------------------------------------------------
r374165 | atanasyan | 2019-10-09 06:12:27 -0700 (Wed, 09 Oct 2019) | 1 line

[mips] Rename local variable. NFC
------------------------------------------------------------------------

------------------------------------------------------------------------
r374164 | atanasyan | 2019-10-09 06:12:21 -0700 (Wed, 09 Oct 2019) | 8 lines

[mips] Split expandLoadImmReal into multiple methods. NFC

The `expandLoadImmReal` handles four different and almost non-overlapping
cases: loading a "single" float immediate into a GPR, loading a "single"
float immediate into a FPR, and the same couple for a "double" float
immediate.

It's better to move each `else if` branch into separate methods.
------------------------------------------------------------------------

This works around a bug in Debian's patchset for glibc. The bug is
described in detail in the upstream debian bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943798, but the short
version of it is that glibc on any Debian based distro don't load
libraries unless it has a .ARM.attribute section.

Reviewed by: jhenderson, rupprecht, MaskRay, jakehehrlich

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

Patch by Tobias Hieta.

(cherry picked from commit fb4a5501)

------------------------------------------------------------------------
r375265 | kerbowa | 2019-10-18 11:20:30 -0700 (Fri, 18 Oct 2019) | 13 lines

AMDGPU: Fix SMEM WAR hazard for gfx10 readlane

Summary: Hazard recognizer fails to see hazard with V_READLANE_B32_gfx10.

Reviewers: rampitec

Reviewed By: rampitec

Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D69172
------------------------------------------------------------------------

------------------------------------------------------------------------
r368310 | sbc | 2019-08-08 09:58:36 -0700 (Thu, 08 Aug 2019) | 11 lines

[lld][WebAssembly] Add optional symbols after input file handling

This allows undefined references in input files be resolved by the
optional symbols.  Previously we were doing this before input file
reading which means it was working only for command line symbols
references (i.e. -u or --export).

Also use addOptionalDataSymbol for __dso_handle and make all optional
symbols hidden by default.

Differential Revision: https://reviews.llvm.org/D65920
------------------------------------------------------------------------

Summary:
This is an alternate approach to D63396

Currently funclets reuse the same stack slots that are used in the
parent function for saving callee-saved xmm registers. If the parent
function modifies a callee-saved xmm register before an excpetion is
thrown, the catch handler will overwrite the original saved value.

This patch allocates space in funclets stack for saving callee-saved xmm
registers and uses RSP instead RBP to access memory.

Signed-off-by: Pengfei Wang <pengfei.wang@intel.com>

Reviewers: rnk, RKSimon, craig.topper, annita.zhang, LuoYuanke, andrew.w.kaylor

Subscribers: hiraditya, llvm-commits

Tags: #llvm

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



Signed-off-by: Pengfei Wang <pengfei.wang@intel.com>
llvm-svn: 370005
(cherry picked from commit 564fb58a)

Constexpr data member conversions work by starting with the class that
originally introduced the field, and converting from there to the type
that the user desires. Before this change, Clang was using the
inheritance model from the final destination class type instead of the
model from the class that originally introduced the field. To fix this,
find the relevant FieldDecl and take its parent class instead of using
the member pointer type the user provided.

Indirect field decls require some special handling to find the parent
class.

Fixes PR43803

(cherry picked from commit 07ee46d6)

Summary:
In the long run we should come up with another mechanism for marking
call instructions as heap allocation sites, and remove this workaround.
For now, we've had two bug reports about this, so let's apply this
workaround. SLH (the other client of instruction labels) probably has
the same bug, but the solution there is more likely to be to mark the
call instruction as not duplicatable, which doesn't work for debug info.

Reviewers: akhuang

Subscribers: aprantl, hiraditya, aganea, chandlerc, llvm-commits

Tags: #llvm

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

llvm-svn: 375137
(cherry picked from commit fc69ad09)

------------------------------------------------------------------------
r372188 | meinersbur | 2019-09-17 15:59:43 -0700 (Tue, 17 Sep 2019) | 13 lines

[CodeGen] Handle outlining of CopyStmts.

Since the removal of extensions nodes from schedule trees in r362257 it
is possible to emit parallel code for SCoPs containing
matrix-multiplications. However, the code looking for references used in
outlined statement was not prepared to handle CopyStmts introduced by
the matrix-matrix multiplication detection.

In this case, CopyStmts do not introduce references in addition to the
ones captured by MemoryAccesses, i.e. we change the assertion to accept
CopyStmts and add a regression test for this case.

This fixes llvm.org/PR43164
------------------------------------------------------------------------

llvm-svn: 374861

------------------------------------------------------------------------
r372020 | rnk | 2019-09-16 11:49:09 -0700 (Mon, 16 Sep 2019) | 30 lines

[PGO] Use linkonce_odr linkage for __profd_ variables in comdat groups

This fixes relocations against __profd_ symbols in discarded sections,
which is PR41380.

In general, instrumentation happens very early, and optimization and
inlining happens afterwards. The counters for a function are calculated
early, and after inlining, counters for an inlined function may be
widely referenced by other functions.

For C++ inline functions of all kinds (linkonce_odr &
available_externally mainly), instr profiling wants to deduplicate these
__profc_ and __profd_ globals. Otherwise the binary would be quite
large.

I made __profd_ and __profc_ comdat in r355044, but I chose to make
__profd_ internal. At the time, I was only dealing with coverage, and in
that case, none of the instrumentation needs to reference __profd_.
However, if you use PGO, then instrumentation passes add calls to
__llvm_profile_instrument_range which reference __profd_ globals. The
solution is to make these globals externally visible by using
linkonce_odr linkage for data as was done for counters.

This is safe because PGO adds a CFG hash to the names of the data and
counter globals, so if different TUs have different globals, they will
get different data and counter arrays.

Reviewers: xur, hans

Differential Revision: https://reviews.llvm.org/D67579
------------------------------------------------------------------------

------------------------------------------------------------------------
r372182 | rnk | 2019-09-17 14:10:49 -0700 (Tue, 17 Sep 2019) | 12 lines

[PGO] Don't use comdat groups for counters & data on COFF

For COFF, a comdat group is really a symbol marked
IMAGE_COMDAT_SELECT_ANY and zero or more other symbols marked
IMAGE_COMDAT_SELECT_ASSOCIATIVE. Typically the associative symbols in
the group are not external and are not referenced by other TUs, they are
things like debug info, C++ dynamic initializers, or other section
registration schemes. The Visual C++ linker reports a duplicate symbol
error for symbols marked IMAGE_COMDAT_SELECT_ASSOCIATIVE even if they
would be discarded after handling the leader symbol.

Fixes coverage-inline.cpp in check-profile after r372020.
------------------------------------------------------------------------

llvm-svn: 374858

------------------------------------------------------------------------
r372606 | spatel | 2019-09-23 06:30:23 -0700 (Mon, 23 Sep 2019) | 3 lines

[x86] fix assert with horizontal math + broadcast of vector (PR43402)

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

llvm-svn: 374633

------------------------------------------------------------------------
r373275 | tstellar | 2019-09-30 16:42:17 -0700 (Mon, 30 Sep 2019) | 9 lines

Fix Driver/modules.cpp test to work when build directory name contains '.s'

Reviewers: dyung, rsmith, hansw

Subscribers: mati865, mgorny, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D66176
------------------------------------------------------------------------

llvm-svn: 374605

Fixes PR43229.

Patch By:  Joseph Tremoulet

llvm-svn: 374511

Summary:
Patch for 9.0.1.

Simplified version of r372186/r372187: fix the meaning of the "vfpv2" and "vfpv2sp" features, but keep around the useless "vfp2d16" and "vfp2d16sp" features, to reduce the risk on the release branch.

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

Reviewers: t.p.northover, tstellar

Reviewed By: t.p.northover

Subscribers: kristof.beyls, hiraditya, kristina, llvm-commits

Tags: #llvm

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

llvm-svn: 374433

llvm-svn: 374286

llvm-svn: 374218

llvm-svn: 374193

llvm-svn: 373512

LDC, the LLVM-based D compiler, is already ready for LLVM 9.0.0.

llvm-svn: 372167

------------------------------------------------------------------------
r371969 | karka | 2019-09-16 11:52:23 +0200 (Mon, 16 Sep 2019) | 13 lines

Change signature of __builtin_rotateright64 back to unsigned

The signature of __builtin_rotateright64 was by misstake changed from
unsigned to signed in r360863, this patch will change it back to
unsigned as intended.

This fixes pr43309

Reviewers: efriedma, hans

Reviewed By: hans

Differential Revision: https://reviews.llvm.org/D67606
------------------------------------------------------------------------

llvm-svn: 372100

llvm-svn: 371964

------------------------------------------------------------------------
r371766 | nickdesaulniers | 2019-09-12 21:53:35 +0200 (Thu, 12 Sep 2019) | 29 lines

[Clang][CodeGen] support alias attribute w/ gnu_inline

Summary:
r369705 did not consider the addition of gnu_inline on function
declarations of alias attributed functions. This resulted in a reported
regression in the clang-9-rc4 release from the Zig developers building
glibc, which was observable as a failed assertion:

llvm-project/clang/lib/AST/Decl.cpp:3336: bool
clang::FunctionDecl::isInlineDefinitionExternallyVisible() const:
Assertion `(doesThisDeclarationHaveABody() || willHaveBody()) && "Must
be a function definition"' failed.

Alias function declarations do not have bodies, so allow us to proceed
if we have the alias function attribute but no body/definition, and add
a test case.  The emitted symbols and their linkage matches GCC for the
added test case.

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

Reviewers: aaron.ballman, rsmith, erichkeane, andrewrk

Reviewed By: andrewrk

Subscribers: cfe-commits, andrewrk, hans, srhines

Tags: #clang

Differential Revision: https://reviews.llvm.org/D67455
------------------------------------------------------------------------

llvm-svn: 371821

------------------------------------------------------------------------
r371434 | efriedma | 2019-09-09 20:29:27 +0200 (Mon, 09 Sep 2019) | 15 lines

[IfConversion] Correctly handle cases where analyzeBranch fails.

If analyzeBranch fails, on some targets, the out parameters point to
some blocks in the function. But we can't use that information, so make
sure to clear it out.  (In some places in IfConversion, we assume that
any block with a TrueBB is analyzable.)

The change to the testcase makes it trigger a bug on builds without this
fix: IfConvertDiamond tries to perform a followup "merge" operation,
which isn't legal, and we somehow end up with a branch to a deleted MBB.
I'm not sure how this doesn't crash the compiler.

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


------------------------------------------------------------------------

llvm-svn: 371490

------------------------------------------------------------------------
r370592 | rksimon | 2019-08-31 18:21:31 +0200 (Sat, 31 Aug 2019) | 3 lines

[X86] EltsFromConsecutiveLoads - Don't confuse elt count with vector element count (PR43170)

EltsFromConsecutiveLoads was assuming that the number of input elts was the same as the number of elements in the output vector type when creating a zeroing shuffle, causing an assert when subvectors were being combined instead of just scalars.
------------------------------------------------------------------------

llvm-svn: 371382

------------------------------------------------------------------------
r371221 | spatel | 2019-09-06 18:10:18 +0200 (Fri, 06 Sep 2019) | 3 lines

[SimplifyLibCalls] handle pow(x,-0.0) before it can assert (PR43233)

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

------------------------------------------------------------------------
r371224 | jfb | 2019-09-06 18:26:59 +0200 (Fri, 06 Sep 2019) | 39 lines

[InstCombine] pow(x, +/- 0.0) -> 1.0

Summary:
This isn't an important optimization at all... We're already doing:
  pow(x, 0.0) -> 1.0
My patch merely teaches instcombine that -0.0 does the same.

However, doing this fixes an AMAZING bug! Compile this program:

  extern "C" double pow(double, double);
  double boom(double base) {
    return pow(base, -0.0);
  }

With:
  clang++ ~/Desktop/fast-math.cpp -ffast-math -O2 -S

And clang will crash with a signal. Wow, fast math is so fast it ICEs the
compiler! Arguably, the generated math is infinitely fast.

What's actually happening is that we recurse infinitely in getPow. In debug we
hit its assertion:
  assert(Exp != 0 && "Incorrect exponent 0 not handled");

We avoid this entire mess if we instead recognize that an exponent of positive
and negative zero yield 1.0.

A separate commit, r371221, fixed the same problem. This only contains the added
tests.

<rdar://problem/54598300>

Reviewers: scanon

Subscribers: hiraditya, jkorous, dexonsmith, ributzka, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D67248
------------------------------------------------------------------------

llvm-svn: 371381

------------------------------------------------------------------------
r371305 | nikic | 2019-09-07 14:03:48 +0200 (Sat, 07 Sep 2019) | 1 line

[X86] Add test for PR43230; NFC
------------------------------------------------------------------------

------------------------------------------------------------------------
r371307 | nikic | 2019-09-07 14:13:44 +0200 (Sat, 07 Sep 2019) | 9 lines

[X86] Fix pshuflw formation from repeated shuffle mask (PR43230)

Fix for https://bugs.llvm.org/show_bug.cgi?id=43230.

When creating PSHUFLW from a repeated shuffle mask, we have to apply
the checks to the repeated mask, not the original one. For the test
case from PR43230 the inspected part of the original mask is all undef.

Differential Revision: https://reviews.llvm.org/D67314
------------------------------------------------------------------------

llvm-svn: 371378

------------------------------------------------------------------------
r371111 | efriedma | 2019-09-05 22:02:38 +0200 (Thu, 05 Sep 2019) | 17 lines

[IfConversion] Fix diamond conversion with unanalyzable branches.

The code was incorrectly counting the number of identical instructions,
and therefore tried to predicate an instruction which should not have
been predicated.  This could have various effects: a compiler crash,
an assembler failure, a miscompile, or just generating an extra,
unnecessary instruction.

Instead of depending on TargetInstrInfo::removeBranch, which only
works on analyzable branches, just remove all branch instructions.

Fixes https://bugs.llvm.org/show_bug.cgi?id=43121 and
https://bugs.llvm.org/show_bug.cgi?id=41121 .

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


------------------------------------------------------------------------

llvm-svn: 371377

------------------------------------------------------------------------
r371262 | nickdesaulniers | 2019-09-06 23:50:11 +0200 (Fri, 06 Sep 2019) | 45 lines

[IR] CallBrInst: scan+update arg list when indirect dest list changes

Summary:
There's an unspoken invariant of callbr that the list of BlockAddress
Constants in the "function args" list match the BasicBlocks in the
"other labels" list. (This invariant is being added to the LangRef in
https://reviews.llvm.org/D67196).

When modifying the any of the indirect destinations of a callbr
instruction (possible jump targets), we need to update the function
arguments if the argument is a BlockAddress whose BasicBlock refers to
the indirect destination BasicBlock being replaced.  Otherwise, many
transforms that modify successors will end up violating that invariant.
A recent change to the arm64 Linux kernel exposed this bug, which
prevents the kernel from booting.

I considered maintaining a mapping from indirect destination BasicBlock
to argument operand BlockAddress, but this ends up being a one to
potentially many (though usually one) mapping.  Also, the list of
arguments to a function (or more typically inline assembly) ends up
being less than 10.  The implementation is significantly simpler to just
rescan the full list of arguments. Because of the one to potentially
many relationship, the full arg list must be scanned (we can't stop at
the first instance).

Thanks to the following folks that reported the issue and helped debug
it:
* Nathan Chancellor
* Will Deacon
* Andrew Murray
* Craig Topper

Link: https://bugs.llvm.org/show_bug.cgi?id=43222
Link: https://github.com/ClangBuiltLinux/linux/issues/649
Link: https://lists.infradead.org/pipermail/linux-arm-kernel/2019-September/678330.html

Reviewers: craig.topper, chandlerc

Reviewed By: craig.topper

Subscribers: void, javed.absar, kristof.beyls, hiraditya, llvm-commits, nathanchance, srhines

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D67252
------------------------------------------------------------------------

llvm-svn: 371376

------------------------------------------------------------------------
r369705 | nickdesaulniers | 2019-08-22 22:47:12 +0200 (Thu, 22 Aug 2019) | 23 lines

[Clang][CodeGen] set alias linkage on QualType

Summary:
It seems that CodeGen was always using ExternalLinkage when emitting a
GlobalDecl with __attribute__((alias)). This leads to symbol
redefinitions (ODR) that cause failures at link time for static aliases.
This is readily attempting to link an ARM (32b) allyesconfig Linux
kernel built with Clang.

Reported-by: nathanchance
Suggested-by: ihalip
Link: https://bugs.llvm.org/show_bug.cgi?id=42377
Link: https://github.com/ClangBuiltLinux/linux/issues/631

Reviewers: rsmith, aaron.ballman, erichkeane

Reviewed By: aaron.ballman

Subscribers: javed.absar, kristof.beyls, cfe-commits, srhines, ihalip, nathanchance

Tags: #clang

Differential Revision: https://reviews.llvm.org/D66492
------------------------------------------------------------------------

------------------------------------------------------------------------
r369713 | nickdesaulniers | 2019-08-23 01:18:46 +0200 (Fri, 23 Aug 2019) | 17 lines

[Bugfix] fix r369705 unit test

Summary:
Aliases aren't supported on OSX.  Add a GNU target triple.

Reported-by: leonardchan
Reported-by: erik.pilkington

Reviewers: leonardchan, erik.pilkington

Reviewed By: leonardchan, erik.pilkington

Subscribers: dexonsmith, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D66622
------------------------------------------------------------------------

llvm-svn: 371372

No --wrap or --emit-relocs options have been added there (only in
the ELF linker).

llvm-svn: 371301

------------------------------------------------------------------------
r371013 | ruiu | 2019-09-05 07:30:24 +0200 (Thu, 05 Sep 2019) | 13 lines

Align output segments correctly

Previously, segments were aligned according to their first section's
alignment requirements. That was not correct, but segments are also
aligned to a page boundary, and a page boundary is usually much larger
than a section alignment requirement, so no one noticed this bug before.

Now, lld has --nmagic option which sets maxPageSize to 1 to effectively
disable page alignment, which reveals the issue.

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

Differential Revision: https://reviews.llvm.org/D67152
------------------------------------------------------------------------

llvm-svn: 371197

------------------------------------------------------------------------
r369828 | maskray | 2019-08-24 02:41:15 +0200 (Sat, 24 Aug 2019) | 18 lines

[ELF] Align the first section of a PT_LOAD even if its type is SHT_NOBITS

Reported at https://reviews.llvm.org/D64930#1642223

If the only section of a PT_LOAD is a SHT_NOBITS section (e.g. .bss), we
may not align its sh_offset. p_offset of the PT_LOAD will be set to
sh_offset, and we will get p_offset!=p_vaddr (mod p_align).  If such
executable is mapped by the Linux kernel, it will segfault.

After D64906, this may happen the non-linker script case.

The linker script case has had this issue for a long time.
This was fixed by rL321657 (but the test linkerscript/nobits-offset.s
failed to test a SHT_NOBITS section), but broken by rL345154.

Reviewed By: peter.smith

Differential Revision: https://reviews.llvm.org/D66658
------------------------------------------------------------------------

llvm-svn: 371196

------------------------------------------------------------------------
r371088 | spatel | 2019-09-05 18:58:18 +0200 (Thu, 05 Sep 2019) | 1 line

[x86] add test for horizontal math bug (PR43225); NFC
------------------------------------------------------------------------

------------------------------------------------------------------------
r371095 | spatel | 2019-09-05 19:28:17 +0200 (Thu, 05 Sep 2019) | 3 lines

[x86] fix horizontal math bug exposed by improved demanded elements analysis (PR43225)

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

llvm-svn: 371178

------------------------------------------------------------------------
r371027 | hans | 2019-09-05 10:43:00 +0200 (Thu, 05 Sep 2019) | 20 lines

Revert r361885 "[Driver] Fix -working-directory issues"

This made clang unable to open files using relative paths on network shares on
Windows (PR43204). On the bug it was pointed out that createPhysicalFileSystem()
is not terribly mature, and using it is risky. Reverting for now until there's
a clear way forward.

> Currently the `-working-directory` option does not actually impact the working
> directory for all of the clang driver, it only impacts how files are looked up
> to make sure they exist.  This means that that clang passes the wrong paths
> to -fdebug-compilation-dir and -coverage-notes-file.
>
> This patch fixes that by changing all the places in the driver where we convert
> to absolute paths to use the VFS, and then calling setCurrentWorkingDirectory on
> the VFS.  This also changes the default VFS for `Driver` to use a virtualized
> working directory, instead of changing the process's working directory.
>
> Differential Revision: https://reviews.llvm.org/D62271

This also revertes the part of r369938 which checked that -working-directory works.
------------------------------------------------------------------------

llvm-svn: 371060

------------------------------------------------------------------------
r370426 | maskray | 2019-08-30 04:20:49 +0200 (Fri, 30 Aug 2019) | 26 lines

[PPC32] Emit R_PPC_GOT_TPREL16 instead R_PPC_GOT_TPREL16_LO

Unlike ppc64, which has ADDISgotTprelHA+LDgotTprelL pairs,
ppc32 just uses LDgotTprelL32, so it does not make lots of sense to use
_LO without a paired _HA.

Emit R_PPC_GOT_TPREL16 instead R_PPC_GOT_TPREL16_LO to match GCC, and
get better linker relocation check. Note, R_PPC_GOT_TPREL16_{HA,LO}
don't have good linker support:

(a) lld does not support R_PPC_GOT_TPREL16_{HA,LO}.
(b) Top of tree ld.bfd does not support R_PPC_GOT_REL16_HA Initial-Exec -> Local-Exec relaxation:

  // a.o
  addis 3, 3, tsd_tls@got@tprel@ha
  lwz 3, tsd_tls@got@tprel@l(3)
  add 3, 3, tsd_tls@tls
  // b.o
  .section .tdata,"awT"; .globl tsd_tls; tsd_tls:

  // ld/ld-new a.o b.o
  internal error, aborting at ../../bfd/elf32-ppc.c:7952 in ppc_elf_relocate_section

Reviewed By: adalava

Differential Revision: https://reviews.llvm.org/D66925
------------------------------------------------------------------------

llvm-svn: 371059

------------------------------------------------------------------------
r369760 | szelethus | 2019-08-23 16:21:13 +0200 (Fri, 23 Aug 2019) | 13 lines

[analyzer] Avoid unnecessary enum range check on LValueToRValue casts

Summary: EnumCastOutOfRangeChecker should not perform enum range checks on LValueToRValue casts, since this type of cast does not actually change the underlying type.   Performing the unnecessary check actually triggered an assertion failure deeper in EnumCastOutOfRange for certain input (which is captured in the accompanying test code).

Reviewers: #clang, Szelethus, gamesh411, NoQ

Reviewed By: Szelethus, gamesh411, NoQ

Subscribers: NoQ, gamesh411, xazax.hun, baloghadamsoftware, szepet, a.sidorin, mikhail.ramalho, donat.nagy, dkrupp, Charusso, bjope, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D66014
------------------------------------------------------------------------

llvm-svn: 371058