Otherwise, we may set IsPreemptible (e.g. --dynamic-list) then clear it
(in replaceCommonSymbols()).
Reviewed By: ruiu
Differential Revision: https://reviews.llvm.org/D62107
llvm-svn: 361122
Summary:
This adds a new error for missing parentheses around lambdas in delete operators.
```
int main() {
delete []() { return new int(); }();
}
```
This will result in:
```
test.cpp:2:3: error: '[]' after delete interpreted as 'delete[]'
delete []() { return new int(); }();
^~~~~~~~~
test.cpp:2:9: note: add parentheses around the lambda
delete []() { return new int(); }();
^
( )
```
Reviewers: rsmith
Reviewed By: rsmith
Subscribers: riccibruno, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D36357
llvm-svn: 361119
This is the sibling transform for rL360899 (D61691):
maxnum(X, GreaterC) == C --> false
maxnum(X, GreaterC) <= C --> false
maxnum(X, GreaterC) < C --> false
maxnum(X, GreaterC) >= C --> true
maxnum(X, GreaterC) > C --> true
maxnum(X, GreaterC) != C --> true
llvm-svn: 361118
Summary:
This patch modifies the AVR toolchain so that if avr-gcc and avr-libc
are detected during compilation, the CRT, libgcc, libm, and libc anre
linked.
This matches avr-gcc's default behaviour, and the expected behaviour of
all C compilers - including the C runtime.
avr-gcc also needs a -mmcu specified in order to link runtime libraries.
The difference betwen this patch and avr-gcc is that this patch will
warn users whenever they compile without a runtime, as opposed to GCC,
which silently trims the runtime libs from the linker arguments when no
-mmcu is specified.
Reviewers: aaron.ballman, kparzysz, asb, hfinkel, brucehoult, TimNN
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D54334
llvm-svn: 361116
LocalLLDBInit.test requires Python module loading support.
CommandScriptImmediateOutput tests are specific to running scripts.
Disable all of them when Python support is disabled.
llvm-svn: 361115
This is needed when using compiler wrappers such as ccache or distcc
and should address the failure on clang-x86_64-debian-fast bot.
Differential Revision: https://reviews.llvm.org/D62104
llvm-svn: 361111
This is a follow-up refactoring patch after the introduction of usable TreeEntry pointers in D61706.
The EdgeInfo struct can now use a TreeEntry pointer instead of an index in VectorizableTree.
Committed on behalf of @vporpo (Vasileios Porpodas)
Differential Revision: https://reviews.llvm.org/D61795
llvm-svn: 361110
Summary:
Reduce size of Option class from 184 bytes to 136 bytes by
placing more member variables in Bit Field (16 bytes), and
reducing the initial sizes of Categories and Subs to 1 (32 bytes).
Saves about 48k for bin/opt.
Reviewed By: beanz
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D62091
llvm-svn: 361107
Summary:
Was looking into supporting `(srl (shl x, c1), c2)` with c1 != c2 in dagcombiner,
this test changes, but makes `update_llc_test_checks.py` unhappy.
**Many** AMDGPU tests specify `-march`, not `-mtriple`, which results in `update_llc_test_checks.py`
defaulting to x86 asm function detection heuristics, which don't work here.
I propose to fix this by adding an infrastructure to map from `-march` to `-mtriple`,
in the UpdateTestChecks tooling.
Reviewers: RKSimon, MaskRay, arsenm
Reviewed By: arsenm
Subscribers: kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D62099
llvm-svn: 361101
Summary:
Was looking into supporting `(srl (shl x, c1), c2)` with c1 != c2 in dagcombiner,
this test changes, but makes `update_llc_test_checks.py` unhappy
Reviewers: RKSimon
Reviewed By: RKSimon
Subscribers: javed.absar, kristof.beyls, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D62097
llvm-svn: 361100
Summary:
Previously llvm-nm relied on a positional parameter to read two values
into the SegSect list. This worked, but required the "-s" paramater and
its arguments to be the last elements on the command-line.
The CommandLine library now supports mutli-var parameters, so it can
naturally deal with "-s" expecting two arguments, and now the input file
can appear anywhere (within reason) in the command line invocation. E.g.
llvm-nm -s __TEXT __text /bin/ls
llvm-nm /bin/ls -s __TEXT __text
rdar://27284011
Reviewers: lhames, pete
Reviewed By: pete
Subscribers: rupprecht, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D62070
llvm-svn: 361091
This reverts D53906.
D53906 increased p_align of PT_TLS on ARM/AArch64 to 32/64 to make the
static TLS layout compatible with Android Bionic's ELF TLS. However,
this may cause glibc ARM/AArch64 programs to crash (see PR41527).
The faulty PT_TLS in the executable satisfies p_vaddr%p_align != 0. The
remainder is normally 0 but may be non-zero with the hack in place. The
problem is that we increase PT_TLS's p_align after OutputSections'
addresses are fixed (assignAddress()). It is possible that
p_vaddr%old_p_align = 0 while p_vaddr%new_p_align != 0.
For a thread local variable defined in the executable, lld computed TLS
offset (local exec) is different from glibc computed TLS offset from
another module (initial exec/generic dynamic). Note: PR41527 said the
bug affects initial exec but actually generic dynamic is affected as
well.
(glibc is correct in that it compute offsets that satisfy
`offset%p_align == p_vaddr%p_align`, which is a basic ELF requirement.
This hack appears to work on FreeBSD rtld, musl<=1.1.22, and Bionic, but
that is just because they (and lld) incorrectly compute offsets that
satisfy `offset%p_align = 0` instead.)
Android developers are fine to revert this patch, carry this patch in
their tree before figuring out a long-term solution (e.g. a dummy .tdata
with sh_addralign=64 sh_size={0,1} in crtbegin*.o files. The overhead is
now insignificant after D62059).
Reviewed By: rprichard, srhines
Differential Revision: https://reviews.llvm.org/D62055
llvm-svn: 361090
After D62059, we don't align p_memsz of PT_TLS to p_align. The
getRelocTargetVA formula should align it instead.
It becomes clear that R_NEG_TLS and R_TLS are opposite from each other.
In i386-tls-le-align.s, I put ret after call ___tls_get_addr@plt as
otherwise ld.bfd would reject the relaxation:
TLS transition from R_386_TLS_GD to R_386_TLS_LE_32 against `a' at 0x3 in section `.text' failed
llvm-svn: 361088
This reverts commit c28f81797084b8416ff5be4f9e79000a9741ca6a.
This reverts commit 7e79b64642486f510f7872174eb831df68d65b84.
Looks like there is more work to be done on this patch. I've spoken to
the author and for the time being we will revert to keep the buildbots
green.
llvm-svn: 361086
As Ryan Prichard pointed out, after D62059, the TP offset is incorrect.
Add x86-64-tls-le-align.s to check this. Better formulae for both
variants should take p_vaddr%p_align into account (offset%p_align =
p_vaddr%p_align is a basic ELF requirement), but I can't find a way to
test the behavior.
llvm-svn: 361084
This is ported from the custom AMDGPU DAG implementation. I think this
is a better default expansion than what the DAG currently uses, at
least if the target has CTLZ.
This implements the signed version in terms of the unsigned
conversion, which is implemented with bit operations. SelectionDAG has
several other implementations that should eventually be ported
depending on what instructions are legal.
llvm-svn: 361081
I was looking at the current implementation of SourceInitFile and there
were a few things that made this function hard to read:
* The code to find the ~/.lldbinit file is duplicated across the cwd
and non-cwd branch.
* The ./.lldbinit is once computed by resolving .lldbinit and once by
resolving ./.lldbinit.
* It wasn't clear to me what happened when you're sourcing the
.lldbinit file in the current working directory. Apparently we do
nothing when we property to control that is set to warn (makes sense)
and we don't care when the property is set to true (debatable).
* There were at least two branches where the status of the
CommandReturnObject were not set.
This patch attempts to simplify that code.
Differential revision: https://reviews.llvm.org/D61994
llvm-svn: 361080
This is a general fix for the ConnectionFileDescriptor class but my main
motivation was to make lldb-server working with IPv6.
The connect URI can use square brackets ([]) to wrap the interface part
of the URI (e.g.: <scheme>://[<interface>]:<port>). For IPv6 addresses
this is a must since its ip can include colons and it will overlap with
the port colon otherwise. The URIParser class parses the square brackets
correctly but the ConnectionFileDescriptor doesn't generate them for
IPv6 addresses making it impossible to connect to the gdb server when
using this protocol.
How to reproduce the issue:
$ lldb-server p --server --listen [::1]:8080
...
$ lldb
(lldb) platform select remote-macosx
(lldb) platform connect connect://[::1]:8080
(lldb) platform process -p <pid>
error: unable to launch a GDB server on 'computer'
The server was actually launched we were just not able to connect to it.
With this fix lldb will correctly connect. I fixed this by wrapping the
ip portion with [].
Differential Revision: https://reviews.llvm.org/D61833
Patch by António Afonso <antonio.afonso@gmail.com>
llvm-svn: 361079
Get*AtIndex() can return nullptr. This only happens in the swift
REPL support, so it's hard to test upstream.
<rdar://problem/50875178>
llvm-svn: 361078
The `using namespace std;` opens us up to ambiguity
when any of the std:: names are also present in the global namespace.
Instead we should properly qualify names we use from std::.
llvm-svn: 361074
Fangrui Song