Otherwise this propagates all the way to CMake and results in an error
during configuration. We check and handle the result and report warning
separately so this is not changing the behavior.

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

llvm-svn: 353784

The new shared pointer was assigning to the temporary instead of the
member (m_curr_frames_sp).

llvm-svn: 353783

[libFuzzer] replace slow std::mt19937 with a much faster std::minstd_rand; second attempt after failed r352732, this time with a fix for cmake

llvm-svn: 353782

llvm-svn: 353781

Summary:
This test instruments the following code with coverage, runs the fuzzer
once, and asserts that there are uncovered PCs. The ARM64 backend
optimizes this code using the `csel` (Conditional select) instruction,
which removes all branching from the resulting machine code. The test
then fails because we do not have any uncovered PCs. The easiest
solution for now is to turn off optimization for the DSOs used in this
test.

```
int DSO1(int a) {
  if (a < 123456)
    return 0;
  return 1;
}
```

rdar://47646400

Reviewers: kcc

Tags: #sanitizers, #llvm

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

llvm-svn: 353780

The code checked that the first root was an appropriate distance from
the base value, but skipped checking the other roots. This could lead to
rerolling a loop that can't be legally rerolled (at least, not without
rewriting the loop in a non-trivial way).

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

llvm-svn: 353779

Apparently there are multiple places where MSVC complains about
instantiations with extended aligment. I think it's better to define
`_ENABLE_EXTENDED_ALIGNED_STORAGE` as suggested by the error message.

I don't have access to a Windows machine so this is all speculative.

llvm-svn: 353778

llvm-svn: 353777

llvm-svn: 353776

[libFuzzer] extend the -fork=1 functionality. Still not fully usable, but good enough for the first unit test

llvm-svn: 353775

libc still provides function declarations, and these declarations
conflict with libc++'s

llvm-svn: 353774

llvm-svn: 353773

In particular when working with static libraries and libstdc++.

llvm-svn: 353772

This configuration (due to r349207) was intended not to emit any DWO CU,
but a degenerate CU was still being emitted - containing a header and a
DW_TAG_compile_unit with no attributes.

Under that situation, emit nothing to the .dwo file. (since this is a
dynamic property of the input the .dwo file is still emitted, just with
nothing in it (so a valid, but empty, ELF file) - if some other CU
didn't satisfy this criteria, its DWO CU would still go there, etc)

llvm-svn: 353771

llvm-svn: 353770

This caused a rather interesting error message on MSVC: error C2338 and
I'm not sure how to properly fix it.

llvm-svn: 353769

Addresses Tatyana Krasnukha's feedback from D57990.

llvm-svn: 353768

Summary:
Some implementations of fenv.h use macros to define the functions they provide. This can cause problems when `std::fegetround()` is spelled in source.

This patch adds a `fenv.h` header to libc++ for the sole purpose of turning those macros into real functions.

Reviewers: rsmith, mclow.lists, ldionne

Reviewed By: rsmith

Subscribers: mgorny, christof, libcxx-commits

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

llvm-svn: 353767

Background: As described in https://reviews.llvm.org/D57601, I'm working towards separating volatile and atomic in the MMO uses for atomic instructions.

In https://reviews.llvm.org/D57593, I fixed a bug where isUnordered was returning the wrong result, but didn't account for the fact I was getting slightly ahead of myself. While both uses of isUnordered are correct (as far as I can tell), we don't have tests to demonstrate this and being aggressive gets in the way of having the removal of volatile truly be non-functional. Once D57601 lands, I will return to these call sites, revert this patch, and add the appropriate tests to show the expected behaviour.

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

llvm-svn: 353766

This attribute applies to declarations of C stdlib functions
(sprintf, memcpy...) that have known fortified variants
(__sprintf_chk, __memcpy_chk, ...). When applied, clang will emit
calls to the fortified variant functions instead of calls to the
defaults.

In GCC, this is done by adding gnu_inline-style wrapper functions,
but that doesn't work for us for variadic functions because we don't
support __builtin_va_arg_pack (and have no intention to).

This attribute takes two arguments, the first is 'type' argument
passed through to __builtin_object_size, and the second is a flag
argument that gets passed through to the variadic checking variants.

rdar://47905754

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

llvm-svn: 353765

Unlike std::make_unique, which is only available since C++14,
std::make_shared is available since C++11. Not only is std::make_shared
a lot more readable compared to ::reset(new), it also performs a single
heap allocation for the object and control block.

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

llvm-svn: 353764

This patch adds a -time-regions option to tablegen that can enable timers
(currently only one) that assess the performance of tablegen itself. This
can be useful for identifying scaling problems with tablegen backends.

This particular timer has allowed me to ignore time that is not attributed
the GISel combiner pass. It's useful by itself but it is particularly
useful in combination with https://reviews.llvm.org/D52954 which causes
this period of time to be annotated within Xcode Instruments which in turn
allows profile samples and recorded allocations attributed to reading
instructions to be filtered out.

llvm-svn: 353763

Basically the same issue as string init, except it didn't really have
any visible consequences before I removed the implicit lvalue-to-rvalue
conversion from CodeGen.

While I'm here, a couple minor drive-by cleanups: IgnoreParens never
returns a ConstantExpr, and there was a potential crash with string init
involving a ChooseExpr.

The analyzer test change maybe indicates we could simplify the analyzer
code a little with this fix?  Apparently a hack was added to support
lvalues in initializers in r315750, but I'm not really familiar with the
relevant code.

Fixes regression reported in the kernel build at
https://bugs.llvm.org/show_bug.cgi?id=40430#c6 .

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

llvm-svn: 353762

Summary:
There have been three options related to threads and users had to set
all three of them separately to get the correct compilation results.
This makes sure the relationship between the options makes sense and
sets necessary options for users if only part of the necessary options
are specified. This does:

- Remove `-matomics`; this option alone does not enable anything, so
  removed it to not confuse users.
- `-mthread-model posix` sets `-target-feature +atomics`
- `-pthread` sets both `-target-feature +atomics` and
  `-mthread-model posix`
Also errors out when explicitly given options don't match, such as
`-pthread` is given with `-mthread-model single`.

Reviewers: dschuff, sbc100, tlively, sunfish

Subscribers: jgravelle-google, jfb, cfe-commits

Tags: #clang

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

llvm-svn: 353761

Avoid this warning:

llvm/clang-tools-extra/clangd/ClangdServer.cpp:365:23: warning: lambda
capture 'this' is not used [-Wunused-lambda-capture]

  auto Action = [Sel, this](decltype(CB) CB, std::string File,
                    ~~^~~~
1 warning generated.

llvm-svn: 353760

llvm-svn: 353759

It seems that, since VC19, the `float` C99 math functions are supported for all
targets, unlike the C89 ones.

According to the discussion at https://reviews.llvm.org/D57625.

llvm-svn: 353758

Summary:
Except for custom floating point types x86_fp80 and ppc_fp128,
expand Y = FNEG(X) to Y = X ^ sign mask to avoid library call.
 Using bitwise operation can improve code size and performance.

Reviewers: efriedma

Reviewed By: efriedma

Subscribers: efriedma, kpn, arsenm, eli.friedman, javed.absar, rbar, johnrusso, simoncook, sabuasal, niosHD, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, PkmX, jocewei, asb, llvm-commits

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

llvm-svn: 353757

gold accepts quoted strings. binutils requires quoted strings for some
kinds of symbols, e.g.:

  it accepts quoted symbols with @ in name:

  $ echo 'EXTERN("__libc_start_main@@GLIBC_2.2.5")' > a.script
  $ g++ a.script
  /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/crt1.o: In function `_start':
  (.text+0x20): undefined reference to `main'
  collect2: error: ld returned 1 exit status

  but rejects them if unquoted:

  $ echo 'EXTERN(__libc_start_main@@GLIBC_2.2.5)' > a.script
  $ g++ a.script
  a.script: file not recognized: File format not recognized
  collect2: error: ld returned 1 exit status

To maintain compatibility with existing linker scripts support quoted
strings in lld as well.

Patch by Lucian Adrian Grijincu.

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

llvm-svn: 353756

Currently there is no way to lazy-load an in-memory IR module without
first writing it to disk. This patch just exposes the existing
implementation of getLazyIRModule.

This is effectively a revert of rL212364

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

llvm-svn: 353755

llvm-svn: 353754

llvm-svn: 353753

The comment for this declaration causes a warning with -Wdocumentation:
Invalid @return in documentation comment SetCollectingStats() in
SBTarget.h.

llvm-svn: 353752

llvm-svn: 353751

llvm-svn: 353750

llvm-svn: 353748

The thread-limit-var and omp_get_thread_limit API was not perfectly handled for
teams construct. Now, when modified by thread_limit clause, omp_get_thread_limit
reports the correct value. In addition, the value is restored when leaving the
teams construct to what it was in the encountering context.

This is done partly by creating the notion of a Contention Group root (CG root)
that keeps track of the thread at the root of each separate CG, the
thread-limit-var associated with the CG, and associated counter of active
threads within the contention group.

thread-limits are passed from master to worker threads via an entry in the ICV
data structure. When a "contention group switch" occurs, a new CG root record is
made and passed from master to worker. A thread could potentially have several
CG root records if it encounters multiple nested teams constructs (but at the
moment the spec doesn't allow for nested teams, so the most one could have
currently is 2). The master of the teams masters gets the thread-limit clause
value stored to its local ICV structure, and the other teams masters copy it
from the master. The thread-limit is set from that ICV copy and restored to the
ICV copy when entering and leaving the teams construct.

This change also fixes a bug when the top-level teams construct team gets
reused, and OMP_DYNAMIC was true, which can cause the expected size of this team
to be smaller than what was actually allocated. The fix updates the size of the
team after its threads were reserved.

Patch by Terry Wilmarth

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

llvm-svn: 353747

The API indicates that the MI is about to be erased rather than it has been erased.

llvm-svn: 353746

We were using DstTy, but that represents the integer type we are converting to which is i64 in this
case. The FLD is part of an intermediate step to get from the SSE registers to the x87 registers.
If the floating point type is f32, the memory operand should reflect a 4 byte access not an 8 byte
access. The store we used to get from SSE to the stack is using the corect size.

While there, consistenly use TheVT in place of Op.getOperand(0).getValueType() throughout the function.

llvm-svn: 353745

Found by `git grep '\/\/ CHECK-[^: ]* ' clang/test/ | grep -v RUN:`.

Also tweak CodeGenCXX/arm-swiftcall.cpp to still pass now that it checks more.

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

llvm-svn: 353744