| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GNU ld has got a number of different flags for adjusting how to
behave around stdcall functions. The --kill-at flag strips the
trailing sdcall suffix from exported functions (which otherwise
is included by default in MinGW setups).
This also strips it from the corresponding import library though.
That makes it hard to link to such an import library from code
that calls the functions - but this matches what GNU ld does with
this flag. Therefore, this flag is probably not sensibly used
together with import libraries, but probably mostly when creating
some sort of plugin, or if creating the import library separately
with dlltool.
Differential Revision: https://reviews.llvm.org/D44292
llvm-svn: 327561
|
|
|
|
| |
llvm-svn: 327560
|
|
|
|
|
|
|
|
|
| |
This tests that LLVM emits the relocations that /guard:cf needs to
identify address taken.
This was PR36624, which was fixed in r327557.
llvm-svn: 327559
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Let's suppose the `-Weverything` is passed.
Given code like
```
void F() {}
;
```
If the code is compiled with `-std=c++03`, it would diagnose that extra sema:
```
<source>:2:1: warning: extra ';' outside of a function is a C++11 extension [-Wc++11-extra-semi]
;
^~
```
If the code is compiled with `-std=c++11`, it also would diagnose that extra sema:
```
<source>:2:1: warning: extra ';' outside of a function is incompatible with C++98 [-Wc++98-compat-pedantic]
;
^~
```
But, let's suppose the C++11 or higher is used, and the used does not care
about `-Wc++98-compat-pedantic`, so he disables that diagnostic.
And that silences the complaint about extra `;` too.
And there is no way to re-enable that particular diagnostic, passing `-Wextra-semi` does nothing...
Now, there is also a related `no newline at end of file` diagnostic, which is also emitted by `-Wc++98-compat-pedantic`
```
<source>:2:2: warning: C++98 requires newline at end of file [-Wc++98-compat-pedantic]
;
^
```
But unlike the previous case, if `-Wno-c++98-compat-pedantic` is passed, that diagnostic stays displayed:
```
<source>:2:2: warning: no newline at end of file [-Wnewline-eof]
;
^
```
This diff refactors the code so `-Wc++98-compat-extra-semi` can be re-enabled, after the `-Wc++98-compat-pedantic` was disabled.
This seems ugly, but there does not seem to be any saner way.
Testing: `$ ninja check-clang`
Reviewers: rsmith, rtrieu, aaron.ballman
Reviewed By: aaron.ballman
Subscribers: jordan_rose, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D43162
llvm-svn: 327558
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
We already emit relocations in this case when the "incremental linker
compatible" flag is set, but it turns out these relocations are also
required for /guard:cf. Now that we have two use cases for this
behavior, let's make it unconditional to try to keep things simple.
We never hit this problem in Clang because it always sets the
"incremental linker compatible" flag when targeting MSVC. However, LLD
LTO doesn't set this flag, so we'd get CFG failures at runtime when
using ThinLTO and /guard:cf. We probably don't want LLD LTO to set the
"incremental linker compatible" assembler flag, since this has nothing
to do with incremental linking, and we don't need to timestamp LTO
temporary objects.
Fixes PR36624.
Reviewers: inglorion, espindola, majnemer
Subscribers: mehdi_amini, llvm-commits, hiraditya
Differential Revision: https://reviews.llvm.org/D44485
llvm-svn: 327557
|
|
|
|
| |
llvm-svn: 327556
|
|
|
|
| |
llvm-svn: 327555
|
|
|
|
|
|
| |
PR26958); NFC
llvm-svn: 327554
|
|
|
|
| |
llvm-svn: 327553
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a first pass at removing some lldb-mi tests which have been
xfailed and unmaintained for a while. We have open PRs for most of these
tests already. I've opened up the following additional PRs:
llvm.org/PR36739 - lldb-mi driver exits properly
llvm.org/PR36740 - lldb-mi -gdb-set and -gdb-show
llvm.org/PR36741 - lldb-mi -symbol-xxx
The motivation here is to address timeout and pexpect-related issues in
the test suite. This was discussed on lldb-dev in the thread: "increase
timeout for tests?".
After this change, the lldb-mi tests seem to be in better health (on
Darwin at least). I consistently get:
$ ./bin/llvm-dotest -p TestMi
===================
Test Result Summary
===================
Test Methods: 101
Reruns: 0
Success: 88
Expected Failure: 0
Failure: 0
Error: 0
Exceptional Exit: 0
Unexpected Success: 0
Skip: 13
Timeout: 0
Expected Timeout: 0
llvm-svn: 327552
|
|
|
|
|
|
|
|
| |
Patch by Ben Clayton
Differential Revision: https://reviews.llvm.org/D44086
llvm-svn: 327551
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
ClangdServer::{codeComplete,signatureHelp} both use the Contents from
the draft manager. Since we want to move the draft manager from
ClangdServer to ClangdLSPServer, this patch changes those methods to
find the file contents from InputsAndPreamble, which contains the source
passed in previously.
Subscribers: klimek, ilya-biryukov, jkorous-apple, ioeric, cfe-commits
Differential Revision: https://reviews.llvm.org/D44484
llvm-svn: 327550
|
|
|
|
|
|
| |
copy.
llvm-svn: 327549
|
|
|
|
| |
llvm-svn: 327548
|
|
|
|
| |
llvm-svn: 327547
|
|
|
|
| |
llvm-svn: 327546
|
|
|
|
| |
llvm-svn: 327545
|
|
|
|
| |
llvm-svn: 327544
|
|
|
|
|
|
|
|
|
|
|
| |
In this particular case it would be possible to just add an else with
CGM.setDSOLocal(GV), but it seems better to have as many callers as
possible just call setGVProperties so that we can centralize the logic
there.
This patch then makes setGVProperties able to handle null Decls.
llvm-svn: 327543
|
|
|
|
|
|
|
|
| |
This "fixes" PR36678 by just producing an error when we find a case
where we would produce an plt entry that used ebx but ebx would not be
set.
llvm-svn: 327542
|
|
|
|
|
|
|
| |
As disscussed in post-commit review of D44421, there is simply
no reason to run instcombine on this testcase.
llvm-svn: 327541
|
|
|
|
|
|
|
|
|
|
| |
I removed this in r316797 because the coverage report showed no coverage and I thought it should have been handled by the auto generated table. I now see that there is code that bypasses the table if the shift amount is out of bounds.
This adds back the code. We'll codegen out of bounds i8 shifts to effectively (amount & 0x1f). The 0x1f is a strange quirk of x86 that shift amounts are always masked to 5-bits(except 64-bits). So if the masked value is still out bounds the result will be 0.
Fixes PR36731.
llvm-svn: 327540
|
|
|
|
| |
llvm-svn: 327539
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: arichardson
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D44400
llvm-svn: 327538
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
It was previously an easy way to concurrently access a mutable vfs,
which is a recipe for disaster.
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: klimek, jkorous-apple, cfe-commits, ioeric
Differential Revision: https://reviews.llvm.org/D44463
llvm-svn: 327537
|
|
|
|
|
|
|
| |
The code for computing the offset of an entry in the plt is simple,
but it was duplicated in quite a few places.
llvm-svn: 327536
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
sign compares (PR36682)
Summary:
This pattern came up in PR36682 / D44390
https://bugs.llvm.org/show_bug.cgi?id=36682
https://reviews.llvm.org/D44390
https://godbolt.org/g/oKvT5H
Looking at the IR pattern in question, as per [[ https://github.com/rutgers-apl/alive-nj | alive-nj ]], for all the type combinations i checked
(input: `i16`, `i32`, `i64`; intermediate: `half`/`i16`, `float`/`i32`, `double`/`i64`)
for the following `icmp` comparisons the `uitofp`+`bitcast`+`icmp` can be evaluated to a boolean:
* `slt 0`
* `sgt -1`
I did not check vectors, but i'm guessing it's the same there.
{F5889242}
Thus all these cases are in the testcase (along with the vector variant with additional `undef` element in the middle).
There are no negative patterns here (unless alive-nj lied/is broken), all of these should be optimized.
Reviewers: spatel, majnemer, efriedma, arsenm
Reviewed By: spatel
Subscribers: wdng, llvm-commits
Differential Revision: https://reviews.llvm.org/D44421
llvm-svn: 327535
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
zero-equality compares (PR36682)
Summary:
This pattern came up in PR36682 / D44390
https://bugs.llvm.org/show_bug.cgi?id=36682
https://reviews.llvm.org/D44390
https://godbolt.org/g/oKvT5H
Looking at the IR pattern in question, as per [[ https://github.com/rutgers-apl/alive-nj | alive-nj ]], for all the type combinations i checked
(input: `i16`, `i32`, `i64`; intermediate: `half`/`i16`, `float`/`i32`, `double`/`i64`)
for the following `icmp` comparisons the `uitofp`+`bitcast` can be dropped:
* `eq 0`
* `ne 0`
I did not check vectors, but i'm guessing it's the same there.
{F5889189}
Thus all these cases are in the testcase (along with the vector variant with additional `undef` element in the middle).
There are no negative patterns here (unless alive-nj lied/is broken), all of these should be optimized.
Generated with
{F5889196}
Reviewers: spatel, majnemer, efriedma, arsenm
Reviewed By: spatel
Subscribers: wdng, llvm-commits
Differential Revision: https://reviews.llvm.org/D44416
llvm-svn: 327534
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Merging:
* $x26, $x25 = frame-setup LDPXi $sp, 0
* $sp = frame-destroy ADDXri $sp, 64, 0
into an LDPXpost should preserve the flags from both instructions as
following:
* frame-setup frame-destroy LDPXpost
Differential Revision: https://reviews.llvm.org/D44446
llvm-svn: 327533
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: To make the removal of DraftMgr from ClangdServer easier (D44408).
Reviewers: sammccall, simark
Reviewed By: sammccall, simark
Subscribers: simark, klimek, jkorous-apple, ioeric, cfe-commits
Differential Revision: https://reviews.llvm.org/D44462
llvm-svn: 327532
|
|
|
|
|
|
| |
with LLVM_ENABLE_EH and LLVM_ENABLE_RTTI.
llvm-svn: 327531
|
|
|
|
|
|
|
|
|
|
|
|
| |
non-demanded bits if it helps created an and mask that can be matched as a zero extend.
I had to modify the bswap recognition to allow unshrunk masks to make this work.
Fixes PR36689.
Differential Revision: https://reviews.llvm.org/D44442
llvm-svn: 327530
|
|
|
|
| |
llvm-svn: 327529
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Windows64.
Summary:
Getting this to work is not particularly obvious, and having it as an example should be helpful.
Portions of this could be placed into LLVM, but as a whole it seems necessary to do this a higher level.
Reviewers: lhames, mehdi_amini
Reviewed By: lhames
Subscribers: mgrang, martell, cfe-commits, mgorny
Differential Revision: https://reviews.llvm.org/D35103
llvm-svn: 327528
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D44150
llvm-svn: 327527
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D44303
llvm-svn: 327526
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Using `getActuallyAllocatedSize` from the Combined resulting in mediocre
compiled code, as the `ClassId != 0` predicament was not propagated there,
resulting in additional branches and dead code. Move the logic in the frontend,
which results in better compiled code. Also I think it makes it slightly easier
to distinguish between the size the user requested, and the size that was
actually allocated by the allocator.
`const` a couple of things as well.
This has no functional impact.
Reviewers: alekseyshl
Reviewed By: alekseyshl
Subscribers: delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D44444
llvm-svn: 327525
|
|
|
|
|
|
|
|
| |
They shouldn't be treated as pure loads.
Found while investigating D44428
llvm-svn: 327524
|
|
|
|
|
|
|
|
|
| |
This reduces the number of lookups to one per COMDAT group, rather than
one per symbol in a COMDAT group.
Differential Revision: https://reviews.llvm.org/D44344
llvm-svn: 327523
|
|
|
|
|
|
|
|
| |
This will enable an optimisation in LLD.
Differential Revision: https://reviews.llvm.org/D44343
llvm-svn: 327522
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
swifterror llvm values model the swifterror register as memory at the
LLVM IR level. ISel will perform adhoc mem-to-reg on them. swifterror
values are constraint in how they can be used. Spilling them to memory
is not allowed.
SjLjEHPrepare tried to lower swifterror values to memory which is
unecessary since the back-end will spill and reload the register as
neccessary (as long as clobbering calls are marked as such which is the
case here) and further leads to invalid IR because swifterror values
can't be stored to memory.
rdar://38164004
llvm-svn: 327521
|
|
|
|
|
|
|
|
| |
Reviewed By: igorb
Differential Revision: https://reviews.llvm.org/D44430
llvm-svn: 327520
|
|
|
|
|
|
|
|
|
|
| |
This renames llvm-dotest to lldb-dotest and makes it a custom target so
you can run `ninja lldb-dotest` to rebuild whatever is necessary before
rerunning the tests.
Differential revision: https://reviews.llvm.org/D44473
llvm-svn: 327519
|
|
|
|
|
|
|
|
|
|
| |
I don't know how to expose this in a test. There are ARM / AArch64
sched classes that include zero latency instructions, but I'm not
seeing sched info printed for those targets. X86 will almost
certainly have these soon (see PR36671), but no model has
'let Latency = 0' currently.
llvm-svn: 327518
|
|
|
|
|
|
| |
This was causing a buildbot failure.
llvm-svn: 327517
|
|
|
|
| |
llvm-svn: 327516
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
r326946
Recent change r326946 (https://reviews.llvm.org/D34367) causes regression in Eigen due to increased
memory footprint of CallArg.
This patch reduces LValue size from 112 to 96 bytes and reduces inline argument count of CallArgList
from 16 to 8.
It has been verified that this will let the added deep AST tree test pass with r326946.
In the long run, CallArg or LValue memory footprint should be further optimized.
Differential Revision: https://reviews.llvm.org/D44445
llvm-svn: 327515
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to DispatchUnit. NFCI
Before this patch, the register file was always updated at instruction creation
time. That means, new read-after-write dependencies, and new temporary registers
were allocated at instruction creation time.
This patch refactors the code in InstrBuilder, and move all the logic that
updates the register file into the dispatch unit. We only want to update the
register file when instructions are effectively dispatched (not before).
This refactoring also helps removing a bad dependency between the InstrBuilder
and the DispatchUnit.
No functional change intended.
llvm-svn: 327514
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch handles the Clang code generation phase for the OpenMP data sharing infrastructure.
TODO: add a more detailed description.
Reviewers: ABataev, carlo.bertolli, caomhin, hfinkel, Hahnfeld
Reviewed By: ABataev
Subscribers: jholewinski, guansong, cfe-commits
Differential Revision: https://reviews.llvm.org/D43660
llvm-svn: 327513
|
|
|
|
|
|
|
|
|
|
| |
Apparently the parser is wrapped inside ifdef's so the logic isn't
available on non-Darwin platforms.
Should fix build bot failure:
http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/20463
llvm-svn: 327512
|