[libc++] Cleanup and enable multiple warnings.

Too many warnings are being disabled too quickly. Warnings are
important to keeping libc++ correct. This patch re-enables two
warnings: -Wconstant-evaluated and -Wdeprecated-copy.

In future, all warnings disabled for the test suite should require an
attached bug. The bug should state the plan for re-enabling that
warning, or a strong case why it should remain disabled.

[PowerPC] Only use PLT annotations if using PIC relocation model

Summary:
The default static (non-PIC, non-PIE) model for 32-bit powerpc does
not use @PLT annotations and relocations in GCC.  LLVM shouldn't use
@PLT annotations either, because it breaks secure-PLT linking with
(some versions of?) GNU LD.

Update the available-externally.ll test to reflect that default mode
should be the same as the static relocation, by using the same check
prefix.

Reviewed by:    sfertile
Differential Revision: https://reviews.llvm.org/D70570

[X86] Add X87 FCMOV support to X86FlagsCopyLowering.

Fixes PR44396

[X86] Fix typo in getCMovOpcode.

The 64-bit HasMemoryOperand line was using CMOV32rm instead of
CMOV64rm. Not sure how to test this. We have no test coverage that
passes true for HasMemoryOperand.

[RISCV] Fix evaluation of %pcrel_lo

The following testcase

  function:
  .Lpcrel_label1:
        auipc   a0, %pcrel_hi(other_function)
        addi    a1, a0, %pcrel_lo(.Lpcrel_label1)
        .p2align        2          # Causes a new fragment to be emitted

        .type   other_function,@function
  other_function:
        ret

exposes an odd behaviour in which only the %pcrel_hi relocation is
evaluated but not the %pcrel_lo.

  $ llvm-mc -triple riscv64 -filetype obj t.s | llvm-objdump  -d -r -

  <stdin>:      file format ELF64-riscv

  Disassembly of section .text:
  0000000000000000 function:
         0:     17 05 00 00     auipc   a0, 0
         4:     93 05 05 00     mv      a1, a0
                0000000000000004:  R_RISCV_PCREL_LO12_I other_function+4

  0000000000000008 other_function:
         8:     67 80 00 00     ret

The reason seems to be that in RISCVAsmBackend::shouldForceRelocation
we only consider the fragment but in RISCVMCExpr::evaluatePCRelLo we
consider the section. This usually works but there are cases where
the section may still be the same but the fragment may be another
one. In that case we end forcing a %pcrel_lo relocation without any
%pcrel_hi.

This patch makes RISCVAsmBackend::shouldForceRelocation use the
section, if any, to determine if the relocation must be forced or
not.

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

[RISCV] Don't force Local Exec TLS for non-PIC

Summary:

Forcing Local Exec TLS requires the use of copy relocations. Copy
relocations need special handling in the runtime linker when being
used against TLS symbols, which is present in glibc, but not in
FreeBSD nor musl, and so cannot be relied upon. Moreover, copy
relocations are a hack that embed the size of an object in the ABI
when it otherwise wouldn't be, and break protected symbols (which are
expected to be DSO local), whilst also wasting space, thus they
should be avoided whenever possible. As discussed in D70398, RISC-V
should move away from forcing Local Exec, and instead use Initial
Exec like other targets, with possible linker relaxation to follow.
The RISC-V GCC maintainers also intend to adopt this
more-conventional behaviour (see
https://github.com/riscv/riscv-elf-psabi-doc/issues/122).

Reviewers: asb, MaskRay

Reviewed By: MaskRay

Subscribers: emaste, krytarowski, hiraditya, rbar, johnrusso,
simoncook, sabuasal, niosHD, kito-cheng, shiva0217, zzheng,
edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe,
PkmX, jocewei, psnobl, benna, Jim, lenary, s.egerton, pzheng,
sameer.abuasal, apazos, llvm-commits, bsdjhb

Tags: #llvm

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

[RISCV] Fix wrong CFI directives

Summary: Removes CFI CFA directives that could incorrectly propagate
beyond the basic block they were inteded for. Specifically it removes
the epilogue CFI directives. See the branch_and_tail_call test for an
example of the issue. Should fix the stack unwinding issues caused by
the incorrect directives.

Reviewers: asb, lenary, shiva0217
Reviewed By: lenary
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D69723

[RISCV] Handle fcopysign(f32, f64) and fcopysign(f64, f32)

Summary: Adds tablegen patterns to explicitly handle fcopysign where
the magnitude and sign arguments have different types, due to the
sign value casts being removed the by DAGCombiner. Support for RV32IF
follows in a separate commit. Adds tests for all relevant scenarios
except RV32IF.

Reviewers: lenary
Reviewed By: lenary
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D70678

[lld][RISCV] Use an e_flags of 0 if there are only binary input files.

Summary:
If none of the input files are ELF object files (for example, when
generating an object file from a single binary input file via "-b
binary"), use a fallback value for the ELF header flags instead of
crashing with an assertion failure.

Reviewers: MaskRay, ruiu, espindola

Reviewed By: MaskRay, ruiu

Subscribers: kevans, grimar, emaste, arichardson, asb, rbar,
johnrusso, simoncook, sabuasal, niosHD, kito-cheng, shiva0217,
zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o,
rkruppe, PkmX, jocewei, psnobl, benna, Jim, lenary, s.egerton,
pzheng, sameer.abuasal, apazos, luismarques, llvm-commits, jrtc27

Tags: #llvm

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

[mips] Use less registers to load address of TargetExternalSymbol

There is no pattern matched `add hi, (MipsLo texternalsym)`. As a
result, loading an address of 32-bit symbol requires two registers
and one more additional instruction:
```
addiu $1, $zero, %lo(foo)
lui   $2, %hi(foo)
addu  $25, $2, $1
```

This patch adds the missed pattern and enables generation more
effective set of instructions:
```
lui   $1, %hi(foo)
addiu $25, $1, %lo(foo)
```

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

llvm-svn: 370196

  [mips] Fix 64-bit address loading in case of applying 32-bit mask to
  the result

  If result of 64-bit address loading combines with 32-bit mask, LLVM
  tries to optimize the code and remove "redundant" loading of upper
  32-bits of the address. It leads to incorrect code on MIPS64 targets.

  MIPS backend creates the following chain of commands to load 64-bit
  address in the `MipsTargetLowering::getAddrNonPICSym64` method:
  ```
  (add (shl (add (shl (add %highest(sym), %higher(sym)),
		      16),
		 %hi(sym)),
	    16),
       %lo(%sym))
  ```

  If the mask presents, LLVM decides to optimize the chain of commands.
  It really does not make sense to load upper 32-bits because the
  0x0fffffff mask anyway clears them. After removing redundant commands
  we get this chain:
  ```
  (add (shl (%hi(sym), 16), %lo(%sym))
  ```

  There is no patterns matched `(MipsHi (i64 symbol))`. Due a bug in
  `SYM_32` predicate definition, backend incorrectly selects a pattern
  for a 32-bit symbols and uses the `lui` instruction for loading
  `%hi(sym)`.

  As a result we get incorrect set of instructions with unnecessary
  16-bit left shifting:
  ```
  lui     at,0x0
      R_MIPS_HI16     foo
  dsll    at,at,0x10
  daddiu  at,at,0
      R_MIPS_LO16     foo
  ```

  This patch resolves two problems:
  - Fix `SYM_32/SYM_64` predicates to prevent selection of patterns
    dedicated to 32-bit symbols in case of using N64 ABI.
  - Add missed patterns for 64-bit symbols for `%hi/%lo`.

  Fix PR42736.

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

  llvm-svn: 370268

[MIPS][ELF] Use PC-relative relocations in .eh_frame when possible

When compiling position-independent executables, we now use
DW_EH_PE_pcrel | DW_EH_PE_sdata4. However, the MIPS ABI does not define a
64-bit PC-relative ELF relocation so we cannot use sdata8 for the large
code model case. When using the large code model, we fall back to the
previous behaviour of generating absolute relocations.

With this change clang-generated .o files can be linked by LLD without
having to pass -Wl,-z,notext (which creates text relocations).
This is simpler than the approach used by ld.bfd, which rewrites the
.eh_frame section to convert absolute relocations into relative references.

I saw in D13104 that apparently ld.bfd did not accept pc-relative relocations
for MIPS ouput at some point. However, I also checked that recent ld.bfd
can process the clang-generated .o files so this no longer seems true.

Reviewed By: atanasyan
Differential Revision: https://reviews.llvm.org/D72228

[MIPS] Don't emit R_(MICRO)MIPS_JALR relocations against data symbols

The R_(MICRO)MIPS_JALR optimization only works when used against functions.
Using the relocation against a data symbol (e.g. function pointer) will
cause some linkers that don't ignore the hint in this case (e.g. LLD prior
to commit 5bab291) to generate a relative branch to the data symbol
which crashes at run time. Before this patch, LLVM was erroneously emitting
these relocations against local-dynamic TLS function pointers and global
function pointers with internal visibility.

Reviewers: atanasyan, jrtc27, vstefanovic
Reviewed By: atanasyan
Differential Revision: https://reviews.llvm.org/D72571

Add 8548 CPU definition and attributes

8548 CPU is GCC's name for the e500v2, so accept this in clang.  The
e500v2 doesn't support lwsync, so define __NO_LWSYNC__ for this as
well, as GCC does.

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

[PowerPC]: Add powerpcspe target triple subarch component

Summary:
This allows the use of '-target powerpcspe-unknown-linux-gnu' or
'powerpcspe-unknown-freebsd' to be used, instead of '-target
powerpc-unknown-linux-gnu -mspe'.

Reviewed By: dim
Differential Revision: https://reviews.llvm.org/D72014

[Driver][PowerPC] Move powerpcspe logic from cc1 to Driver

Follow-up of D72014. It is more appropriate to use a target feature
instead of a SubTypeArch to express the difference.

Reviewed By: #powerpc, jhibbits

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

[PowerPC] Fix powerpcspe subtarget enablement in llvm backend

Summary:

As currently written, -target powerpcspe will enable SPE regardless
of disabling the feature later on in the command line.  Instead,
change this to just set a default CPU to 'e500' instead of a generic
CPU.

As part of this, add FeatureSPE to the e500 definition.

Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D72673

Reland r374450 with Richard Smith's comments and test fixed.

The behavior from the original patch has changed, since we're no
longer allowing LLVM to just ignore the alignment.  Instead, we're
just assuming the maximum possible alignment.

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

llvm-svn: 374562

^                           ~~~~~~~~~~