[SCEV] Clang format most of the SCEV header; NFC

The indentation for the declared classes was not as per LLVM coding
style.

llvm-svn: 282362

[X86] Remove what appears to be leftover MMX code involving (v1i64 scalar_to_vector).

llvm-svn: 282361

[X86] Remove patterns for scalar_to_vector from FR32/FR64 to 256-bit vectors. Lowering explicitly avoids creating this pattern.

llvm-svn: 282360

[AVX-512] Replace get512BitSuperRegister with calls to TargetRegisterInfo::getMatchingSuperReg.

llvm-svn: 282359

[AVX-512] Fix some patterns predicates to properly enforce priority for various versions of CVTDQ2PD instruction.

llvm-svn: 282358

[AVX-512] Add rounding versions of instructions to hasUndefRegUpdate.

llvm-svn: 282357

[AVX-512] Add the scalar unsigned integer to fp conversion instructions to hasUndefRegUpdate.

llvm-svn: 282356

[AVX-512] Remove duplicate instructions for converting integer to scalar floating point. We can use patterns to point to the other instructions instead.

llvm-svn: 282355

Update -verify test to use new static assert message

llvm-svn: 282352

www: add new code coverage link to Polly website

llvm-svn: 282351

Add a comment on StringRef::contains(char)

llvm-svn: 282350

Fix missing _LIBCPP_INLINE_VISIBILITY macro on C++03 specific __hash_table function

llvm-svn: 282349

Fix signed / unsigned comparison.

llvm-svn: 282348

[libc++] Remove various C++03 feature test macros

Summary:
Libc++ still uses per-feature configuration macros when configuring for C++11. However libc++ requires a feature-complete C++11 compiler so there is no reason to check individual features. This patch starts the process of removing the feature specific macros and replacing their usage with `_LIBCPP_CXX03_LANG`.

This patch removes the __config macros:

* _LIBCPP_HAS_NO_TRAILING_RETURN
* _LIBCPP_HAS_NO_TEMPLATE_ALIASES
* _LIBCPP_HAS_NO_ADVANCED_SFINAE
* _LIBCPP_HAS_NO_DEFAULT_FUNCTION_TEMPLATE_ARGS
* _LIBCPP_HAS_NO_STATIC_ASSERT

As a drive I also changed our C++03 static_assert to use _Static_assert if available.

I plan to commit this without review if nobody voices an objection.

Reviewers: mclow.lists

Subscribers: cfe-commits

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

llvm-svn: 282347

Add some predicated searching functions to StringRef.

This adds 4 new functions to StringRef, which can be used to
take or drop characters while a certain condition is met, or
until a certain condition is met.  They are:

take_while - Return characters until a condition is not met.
take_until - Return characters until a condition is met.
drop_while - Remove characters until a condition is not met.
drop_until - Remove characters until a condition is met.

Internally, all of these functions delegate to two additional
helper functions which can be used to search for the position
of a character meeting or not meeting a condition, which are:

find_if - Find the first character matching a predicate.
find_if_not - Find the first character not matching a predicate.

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

llvm-svn: 282346

Use __attribute__((internal_linkage)) when available.

Summary:
This patch has been a long time coming (Thanks @eugenis). It changes `_LIBCPP_INLINE_VISIBILITY` to use `__attribute__((internal_linkage))` instead of `__attribute__((visibility("hidden"), always_inline))`.

The point of `_LIBCPP_INLINE_VISIBILITY` is to prevent inline functions from being exported from both the libc++ library and from user libraries. This helps libc++ better manage it's ABI.
Previously this was done by forcing inlining and modifying the symbols visibility. However inlining isn't guaranteed and symbol visibility only affects shared libraries making this an imperfect solution.  `internal_linkage` improves this situation by making all symbols local to the TU they are emitted in, regardless of inlining or visibility. IIRC the effect of applying `__attribute__((internal_linkage))` to an inline function is the same as applying `static`.

For more information about the attribute see: http://lists.llvm.org/pipermail/cfe-dev/2015-October/045580.html

Most of the work for this patch was done by @eugenis.

Reviewers: mclow.lists, eugenis

Subscribers: eugenis, cfe-commits

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

llvm-svn: 282345

[AVX-512] Don't use two opcodes for INTR_TYPE_SCALAR_MASK_RM. The handling was such that if the second opcode was present the first was ingored, so we can just have one opcode.

llvm-svn: 282344

Fix a few static_asserts that need extra parens on -03

llvm-svn: 282343

Implement proposed resolution for LWG#2758. Reviewed as D24446. Normally, I would wait for these to be voted upon at a committee meeting (November), but the current draft standard is broken, and this should fix it. (And if it doesn't, we want to know about it soonest)

llvm-svn: 282342

[X86] Teach combineShuffle to avoid creating floating point operations with integer types and integer operations with floating point types. Seems isOperationLegal lies for mismatched types and operations.

Fixes PR30511.

llvm-svn: 282341

[AVX-512] Split scalar version of X86ISD::SELECT into a separate opcode because isel is not robust with multiple type profiles for the same opcode.

llvm-svn: 282340

[AVX-512] Remove the patterns for selecting scalar VCOMI/VUCOMI instructions with SAE as there is no way to create the pattern.

llvm-svn: 282339

ObjCARC: Don't look at users of ConstantData

Stop looking at users of UndefValue and ConstantPointerNull in the
objective C ARC optimizers.  The other users aren't actually
interesting, since they're not pointing at a particular object.  I
imagine these calls could be optimized through -instcombine... maybe
they already are?

These early returns will be required at some point in the future, with a
WIP patch that asserts when someone accesses a use-list on ConstantData.

llvm-svn: 282338

Analysis: Return early for UndefValue in computeKnownBits

There is no benefit in looking through assumptions on UndefValue to
guess known bits.  Return early to avoid walking their use-lists, and
assert that all instances of ConstantData are handled here for similar
reasons (UndefValue was the only integer/pointer holdout).

llvm-svn: 282337

[x86] don't try to create a vector integer inst for an SSE1 target (PR30512)

This bug was introduced with:
http://reviews.llvm.org/rL272511

We need to restrict the lowering to v4f32 comparisons because that's all SSE1 can handle.

This should fix:
https://llvm.org/bugs/show_bug.cgi?id=28044

llvm-svn: 282336

[LTO] Add a test for invalid alias analysis pipelines.

I found out this wasn't tested when looking at Vedant's coverage bot
numbers, so, thanks to him. While I'm here, switch the error message
to be lld-compliant (first letter lowercase).

llvm-svn: 282335

Scalar: Ignore ConstantData in processAssumption

Assumptions on UndefValue and ConstantPointerNull aren't relevant to
other users.  Ignore them entirely to avoid wasting cycles walking
through their (possibly extremely extensive (cross-module)) use-lists.

It wasn't clear how to add a specific test for this, and it'll be
covered anyway by an eventual patch that asserts when trying to access
the use-list of an instance of ConstantData.

llvm-svn: 282334

Analysis: Return early in isKnownNonNullAt for ConstantData

Check and return early for ConstantPointerNull and UndefValue
specifically in isKnownNonNullAt, and assert that ConstantData never
make it to isKnownNonNullFromDominatingCondition.

This confirms that isKnownNonNullFromDominatingCondition never walks
through the use-list of an instance of ConstantData.  Given that such
use-lists cross module boundaries, it never really made sense to do so,
and was potentially very expensive.

llvm-svn: 282333

Fix incorrect include in is_error_code_enum.pass.cpp

llvm-svn: 282332

Implement is_error_code_v and is_error_condition_v for c++17. Rework the tests for is_error_code and is_error_condition, since they were really lacking. Thanks to Alisdair for the heads-up that we were missing these.

llvm-svn: 282331

[clang-tidy] fix for NOLINT after macro expansion

Summary:
When having
``` c++
    #define MACRO code-with-warning
    MACRO; // NOLINT
```
clang-tidy would still show the warning, because
it searched for "NOLINT" only in the first line,
not on the second.
This caused e.g. https://llvm.org/bugs/show_bug.cgi?id=29089
(where the macro was defined in a system header). See also
the added test cases.
Now clang-tidy looks at the line of macro invocation and every line
of macro definition for a NOLINT comment.

Reviewers: alexfh, aaron.ballman, hokein

Subscribers: cfe-commits

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

llvm-svn: 282330

[AVR] Update signature of AVRTargetObjectFile::SelectSectionForGlobal

It was changed recently, and was breaking compilation of the backend.

llvm-svn: 282329

[libc++] Remove math_win32.h

Visual Studio 2013 and onward have all the required functions in their
CRT headers, and we don't support older versions anymore.

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

llvm-svn: 282328

[RegisterBankInfo] Constify the member of the XXXMapping maps.

This makes it obvious that items in those maps behave like statically
created objects.

llvm-svn: 282327

[RegisterBankInfo] Document the design choice for the BreakDown.

This adds a comment explaining why we will duplicate PartialMapping to
represent the breakdown for complex mappings (mappings with more than
one partial mapping), instead of using an array of pointer.

NFC

llvm-svn: 282326

[RegisterBankInfo] Add statistics for dynamic value mappings.

Like partial mappings, as we move toward TableGen'ed information, the
number should reach zero eventually.

llvm-svn: 282325

[RegisterBankInfo] Uniquely generate ValueMapping.

This is a step toward statically allocate ValueMapping. Like the
previous few commits, the goal is to move toward a TableGen'ed like
structure with no dynamic allocation at all.

llvm-svn: 282324

[RegisterBankInfo] Keep valid pointers for PartialMappings.

Previously we were using the address of the unique instance of a partial
mapping in the related map to access this instance. However, when the
map grows, the whole set of instances may be moved elsewhere and the
previous addresses are not valid anymore.

Instead, keep the address of the unique heap allocated instance of a
partial mapping.

Note: I did not see any actual bugs for that problem as the number of
partial mappings dynamically allocated is small (<= 4).

llvm-svn: 282323

Remove excessive padding from RedeclarableResult

This diff reorders the fields of the class RedeclarableResult
to remove excessive padding.

Test plan: make -j8 check-clang

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

llvm-svn: 282322

[libFuzzer] add a standalone build script

llvm-svn: 282321

GlobalStatus: Don't walk use-lists of ConstantData

Return early from llvm::isSafeToDestroyConstant() whenever the value
`isa<ConstantData>()`.  These constants are shared across the
LLVMContext.  We never really want to delete them here, and walking
their use-lists can be very expensive.

(This is motivated by an eventual goal of removing use-lists entirely
from ConstantData.)

llvm-svn: 282320

[clang-tidy] Cleaning up language options.

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

llvm-svn: 282319

Remove excessive padding from ObjCCategoriesVisitor

This diff reorders the fields of ObjCCategoriesVisitor
to remove excessive padding.

Test plan: make -j8 check-clang

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

llvm-svn: 282318

[analyzer][scan-build-py] subprocess output handling reviewed in clang module

llvm-svn: 282317

[libFuzzer] simplify HandleTrace again, start re-running interesting units and collecting their features.

llvm-svn: 282316

[msan] Disable flaky fork.cc on PPC64.

This test is very flaky on PPC64 (both BE and LE), but not on other platforms.

llvm-svn: 282315

[CMake] Generate LLDB_REVISION at build time

Summary:
This alters the generation of LLDB_REVISION to be heavily based on how clang generates its version header. There are two benefits of this aproach.

(1) The LLDB_REVISION is generated at build time, so it will be updated after an SCM pull/update even if CMake doesn't re-run
(2) This works on Windows

As noted this code is a simplified implementation of the code from clang.

Reviewers: tfiala, zturner

Subscribers: beanz, mgorny, lldb-commits

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

llvm-svn: 282314

Add qualification to fix MSVC build.

llvm-svn: 282313

[x86] fix FCOPYSIGN lowering to create constants instead of ConstantPool loads

This is similar to:
https://reviews.llvm.org/rL279958

By not prematurely lowering to loads, we should be able to more easily eliminate
the 'or' with zero instructions seen in copysign-constant-magnitude.ll.

We should also be able to extend this code to handle vectors.

llvm-svn: 282312

Mutatis mutandis for char * -> StringRef.

llvm-svn: 282311

Add an accessor to get the value of RC_PLATFORM_NAME at build time

llvm-svn: 282310

Fix build on Ubuntu.

This was in some code that was #ifdef'd out on Windows, so I
didn't see it.

llvm-svn: 282309

Use llvm::to_string instead of std::to_string to fix bot

This should fix the android build in this bot:
http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-buildserver/builds/11143

llvm-svn: 282308

Combine two StringSwitch::Cases because Cases now can take 6 parameters.

llvm-svn: 282307

Change FileAction::GetPath() to return a StringRef.

llvm-svn: 282306

Add StringSwitch::Cases functions that takes 6 to 10 arguments.

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

llvm-svn: 282305

Revert "[profile] Hide lprofCurFilename"

This reverts commit r282294. It breaks a Linux bot:

  http://lab.llvm.org:8011/builders/clang-cmake-aarch64-42vma/builds/12180

It looks like the test checks that __llvm_profile_set_filename() alters the raw
profile filename in both the dylib and the main program. Now that
lprofCurFilename is hidden, this can't work, and we get two profiles (one for
the call to "main" and one for "func").

Back this change out so that we don't affect external users.

llvm-svn: 282304

[MC] Support .ds directives in assembler parser

These directives are already supported by GNU assembler.

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

llvm-svn: 282303

llc: Add -start-before/-stop-before options

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

llvm-svn: 282302

Update clang for r282299.

llvm-svn: 282301

annotate more function visibility

These data and text symbols were missing annotations for building with hidden
visibility.  As we do not currently enable hidden visibility by default, this is
a NFC for the buildbots.

llvm-svn: 282300

LTO: Simplify caching interface.

The NativeObjectOutput class has a design problem: it mixes up the caching
policy with the interface for output streams, which makes the client-side
code hard to follow and would for example make it harder to replace the
cache implementation in an arbitrary client.

This change separates the two aspects by moving the caching policy
to a separate field in Config, replacing NativeObjectOutput with a
NativeObjectStream class which only deals with streams and does not need to
be overridden by most clients and introducing an AddFile callback for adding
files (e.g. from the cache) to the link.

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

llvm-svn: 282299

Allow for tests to be disabled at runtime

Summary:
The current implementation of the test suite allows the user to run
a certain subset of tests using '-p', but does not allow the inverse,
where a user wants to run all but some number of known failing tests.
Implement this functionality.

Reviewers: labath, zturner, tfiala

Subscribers: jingham, sas, lldb-commits

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

llvm-svn: 282298

Install only the manpage and only in the proper location

llvm-svn: 282297

[AMDGPU] Fix for bz30427: wrong MTBUF encoding on VI

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

llvm-svn: 282296

Warn if we can't find the entry symbol.

Fixes pr30465.

llvm-svn: 282295

[profile] Hide lprofCurFilename

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

llvm-svn: 282294

[analyzer] Fix crash in RetainCountChecker::checkEndFunction

The class BodyFarm creates bodies for
OSAtomicCompareAndSwap*, objc_atomicCompareAndSwap*, dispatch_sync*, dispatch_once*
and for them the flag isBodyAutosynthesized is set to true.

This diff
1. makes AnalysisConsumer::HandleCode skip the autosynthesized code
2. replaces assert(LCtx->getParent()) in RetainCountChecker::checkEndFunction
by assert(!LCtx->inTopFrame()) (minor cleanup)

Test plan: make -j8 check-clang-analysis

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

llvm-svn: 282293

[libFuzzer] first steps in adding a proper automated test suite based on real-life code: add a script to build RE2 at a revision that has known bugs

llvm-svn: 282292

[LTO] Add -flto-jobs=N to control backend parallelism

Summary:
Currently, a linker option must be used to control the backend
parallelism of ThinLTO. The linker option varies depending on the
linker (e.g. gold vs ld64). Add a new clang option -flto-jobs=N
to control this.

I've added in the wiring to pass this to the gold plugin. I also
added in the logic to pass this down in the form I understand that
ld64 uses on MacOS, for the darwin target.

Reviewers: mehdi_amini, dexonsmith

Subscribers: mehdi_amini, cfe-commits

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

llvm-svn: 282291

[gold] Split plugin options controlling ThinLTO and codegen parallelism.

Summary:
As suggested in D24826, use different options for ThinLTO backend
parallelism from the option controlling regular LTO code gen
parallelism. They are already split in the LTO API, and this enables
controlling them with different clang options.

Reviewers: pcc, mehdi_amini

Subscribers: dexonsmith, llvm-commits, mehdi_amini

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

llvm-svn: 282290

Revert "set the underlying value of “#pragma STDC FP_CONTRACT” on by default"

This reverts commit r282259, as it broke the AArch64 test-suite bots.

llvm-svn: 282289

[Coverage] Clarify a function contract (NFC)

llvm-svn: 282287

[llvm-cov] Factor out logic to remove unmapped inputs (NFC)

llvm-svn: 282286

Avoid counting sections twice.

We were counting the size of the bss section holding common symbols twice:

    Dot += CurOutSec->getSize();
    flush();

The new code is also simpler as now flush is the only function that
inserts in AlreadyOutputOS, which makes sense since the set hold fully
output sections.

llvm-svn: 282285

[libFuzzer] reset Counters (trace-pc-guard) before every run

llvm-svn: 282284

[MC] Support .dcb directives in assembler parser

These directives are already supported by GNU assembler.

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

llvm-svn: 282283

[llvm-cov] Filter away source files that aren't in the coverage mapping

... so that they don't show up in the index. This came up because polly
contains a .git directory and some other unmapped input in its source
dir.

llvm-svn: 282282

[llvm-cov] Get rid of all invalid filename references

We used to append filenames into a vector of std::string, and then
append a reference to each string into a separate vector. This made it
easier to work with the getUniqueSourceFiles API. But it's buggy.

std::string has a small-string optimization, so you can't expect to
capture a reference to one if you're copying it into a growing vector.
Add a test that triggers this invalid reference to std::string scenario,
and kill the issue with fire by just using ArrayRef<std::string>
everywhere.

llvm-svn: 282281

[llvm-cov] Minor cleanup. NFC.

llvm-svn: 282280

[ELF] Resolve weak undefined TLS symbols when no phdr is available.

If we pass --gc-sections to lld and .tbss is not referenced,
the section is reclaimed and lld doesn't create a TLS program header.
R_TLS tries to access the program header -> lld crashes.
Mimic what bfd/gold do in this case and resolve a weak undefined
TLS symbol to the base of the TLS block, i.e. give it a value of zero.

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

llvm-svn: 282279

[TLI] isdigit / isascii / toascii param type should match return type (PR30484)

We crash in LibCallSimplifier if we don't check the validity of the function signature properly.

llvm-svn: 282278

Change Module::RemapPath to use StringRef.

llvm-svn: 282277

[ResetMachineFunction] Populate the comments in the header of the file.

NFC

llvm-svn: 282276

[ResetMachineFunction] Add statistic on the number of reset functions.

As the development of GlobalISel move forward, this statistic should
strictly decrease until it reaches zero. At this point, it would mean
GlobalISel can replace SDISel (at least on the tested inputs :P).

llvm-svn: 282275

[RegisterBankInfo] Add statistics for dynamic partial mappings.

Collect statistics about the number of partial mappings dynamically
allocated and accessed. Ultimately, when the whole TableGen
infrastructure is set, those numbers should be zero.

llvm-svn: 282274

ScheduleDAG: Match enum names when printing sdep kinds

It is less confusing to have the same names in the debug print as the
enum members.

llvm-svn: 282273

BitcodeReader: Deduplicate code. NFC.

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

llvm-svn: 282272

Try again to match the logic of the code before re-writing.

llvm-svn: 282271

Try to fix failing TestDataFormatterSkipSummary test case.

llvm-svn: 282270

Update the prompt related functions to use StringRefs.

llvm-svn: 282269

Simplify. NFC.

llvm-svn: 282268

[RegBankSelect] Use DEBUG_TYPE instead of repeating the name of the pass

NFC

llvm-svn: 282267

[RegisterBank] Mark the dump method with LLVM_DUMP_METHOD.

NFC

llvm-svn: 282266

Update OptionGroup::SetValue to take StringRef.

Then deal with all the fallout.

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

llvm-svn: 282265

Fix the following tests when running under cross-compilation:

 Profile-aarch64 :: Linux/comdat_rename.test
 Profile-aarch64 :: Linux/extern_template.test
 Profile-aarch64 :: Linux/instrprof-comdat.test
 Profile-aarch64 :: Linux/instrprof-cs.c

The issue is that the created (aarch64) binaries were attempting to run natively
instead of running through %run, which guarantees running in the proper
environment if the compilation was configured correctly.

llvm-svn: 282264

[compiler-rt] Fix a broken asan 64-bit test using ld_preload

Summary:
The 'asan_preload_test-1.cc' is not working with the i686 architecture.
To repro the error, run on a linux 64-bit:
```
ninja check-asan-dynamic
```

The following error occurs:
```
--
Exit Code: 1

Command Output (stderr):
--
/home/llvm/llvm/projects/compiler-rt/test/asan/TestCases/Linux/asan_preload_test-1.cc:18:12: error: expected string not found in input
 // CHECK: AddressSanitizer: heap-buffer-overflow
           ^
<stdin>:1:1: note: scanning from here
ERROR: ld.so: object 'libclang_rt.asan-i686.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
^
<stdin>:2:10: note: possible intended match here
==25982==AddressSanitizer CHECK failed: /home/llvm/llvm/projects/compiler-rt/lib/asan/asan_interceptors.cc:736 "((__interception::real_memcpy)) != (0)" (0x0, 0x0)
```

The unittest is running (where %shared_libasan is replaced by libclang_rt.asan-i686.so):
```
// RUN: env LD_PRELOAD=%shared_libasan not %run %t 2>&1 | FileCheck %s
```

But the executable also has a dependancy on libclang_rt.asan-i386.so (added by the clang driver):
```
linux-gate.so.1 =>  (0xf77cc000)
libclang_rt.asan-i386.so => not found
libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xf76ba000)
libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xf7673000)
libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xf7656000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf74a7000)
```

By looking to the clang driver (tools.cpp) we can see that every x86 architecture are mapped to 'i386'.
```
 StringRef MyArch;
    switch (getToolChain().getArch()) {
    case llvm::Triple::arm:
      MyArch = "arm";
      break;
    case llvm::Triple::x86:
      MyArch = "i386";
      break;
    case llvm::Triple::x86_64:
      MyArch = "amd64";
      break;
    default:
      llvm_unreachable("Unsupported architecture");
    }
```

This patch is implementing the same mapping but in the compiler-rt unittest.

Reviewers: rnk, vitalybuka

Subscribers: aemerson, kubabrecka, dberris, llvm-commits, chrisha

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

llvm-svn: 282263

Enhance calcColdCallHeuristics for InvokeInst

Summary: When identifying cold blocks, consider only the edge to the normal destination if the terminator is InvokeInst and let calcInvokeHeuristics() decide edge weights for the InvokeInst.

Reviewers: mcrosier, hfinkel, davidxl

Subscribers: mcrosier, llvm-commits

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

llvm-svn: 282262

[asan] Stop appending -lm, -pthread and other linker options on Darwin for ASan unit tests

On Darwin, -lm, -pthread and others are implied. -pthread currently produces a warning (compiler option unused).

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

llvm-svn: 282260

set the underlying value of “#pragma STDC FP_CONTRACT” on by default

Clang has the default FP contraction setting of “-ffp-contract=on”, which
doesn't really mean “on” in the conventional sense of the word, but rather
really means “according to the per-statement effective value of the relevant
pragma”.

Before this patch, Clang has that pragma defaulting to “off”. Since the
“-ffp-contract=on” mode is really an AND of two booleans and the second of them
defaults to “off”, the whole thing effectively defaults to “off”. This patch
changes the default value of the pragma to “on”, thus making the default pair of
booleans (on, on) rather than (on, off). This makes FP optimization slightly
more aggressive than before when not using either “-Ofast”, “-ffast-math”, or
“-ffp-contract=fast”. Even with this patch the compiler still respects
“-ffp-contract=off”.

As per a suggestion by Steve Canon, the added code does _not_ require “-O3” or
higher. This is so as to try our best to preserve identical floating-point
results for unchanged source code compiling for an unchanged target when only
changing from any optimization level in the set (“-O0”, “-O1”, “-O2”, “-O3”) to
any other optimization level in that set. “-Os” and “-Oz” seem to be behaving
identically, i.e. should probably be considered a part of the aforementioned
set, but I have not reviewed this rigorously. “-Ofast” is explicitly _not_ a
member of that set.

Patch authored by Abe Skolnik [a.skolnik@samsung.com] and Stephen Canon [scanon@apple.com].

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

llvm-svn: 282259