| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
| |
The actual logic is to keep the output section if the output section
would have been ro/rw.
This is both simpler and more practical, as the intention is linker
scripts is to always keep of of a pair of ONLY_IF_RO/ONLY_IF_RW.
llvm-svn: 282099
|
|
|
|
| |
llvm-svn: 282098
|
|
|
|
| |
llvm-svn: 282097
|
|
|
|
|
|
| |
sanitizer-windows bot
llvm-svn: 282096
|
|
|
|
|
|
| |
The sanitizer-windows bot is currently red because this test unexpectedly passes.
llvm-svn: 282095
|
|
|
|
| |
llvm-svn: 282092
|
|
|
|
| |
llvm-svn: 282091
|
|
|
|
|
|
|
|
|
|
|
| |
r282079 converted the regular expression interface to accept
and return StringRefs instead of char pointers. In one case
a null pointer check was converted to an empty string check,
but this was an incorrect conversion because an empty string
is a valid regular expression. Removing this check should
fix the test failures.
llvm-svn: 282090
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Add some user facing documentation on ThinLTO and how to use it.
Reviewers: mehdi_amini
Subscribers: mehdi_amini, cfe-commits
Differential Revision: https://reviews.llvm.org/D24806
llvm-svn: 282089
|
|
|
|
|
|
|
|
|
| |
ISel does not handle them correctly yet i.e we crash trying to emit tail call
code.
radar://28407842
llvm-svn: 282088
|
|
|
|
|
|
|
|
|
|
|
|
| |
If we identify an instruction as uniform after vectorization, we know that we
should only use the value corresponding to the first vector lane of each unroll
iteration. However, when scalarizing such instructions, we still produce values
for the other vector lanes. This patch prevents us from generating the unused
scalars.
Differential Revision: https://reviews.llvm.org/D24275
llvm-svn: 282087
|
|
|
|
|
|
|
|
|
| |
Lit tests added.
Resolves https://github.com/RadeonOpenCompute/hcc/issues/122.
Differential Revision: https://reviews.llvm.org/D24765
llvm-svn: 282086
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The dynamic shadow code is not detected correctly on Android.
The android shadow seems to start at address zero.
The bug is introduced here:
https://reviews.llvm.org/D23363
Started here: https://build.chromium.org/p/chromium.fyi/builders/ClangToTAndroidASan/builds/4029
Likely due to an asan runtime change, filed https://llvm.org/bugs/show_bug.cgi?id=30462
From asan_mapping.h:
```
#if SANITIZER_WORDSIZE == 32
# if SANITIZER_ANDROID
# define SHADOW_OFFSET (0) <<---- HERE
# elif defined(__mips__)
```
Shadow address on android is 0.
From asan_rtl.c:
```
if (shadow_start == 0) {
[...]
shadow_start = FindAvailableMemoryRange(space_size, alignment, granularity);
}
```
We assumed that 0 is dynamic address.
On windows, the address was determined with:
```
# elif SANITIZER_WINDOWS64
# define SHADOW_OFFSET __asan_shadow_memory_dynamic_address
# else
```
and __asan_shadow_memory_dynamic_address is initially zero.
Reviewers: rnk, eugenis, vitalybuka
Subscribers: kcc, tberghammer, danalbert, kubabrecka, dberris, llvm-commits, chrisha
Differential Revision: https://reviews.llvm.org/D24768
llvm-svn: 282085
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
voting.
Summary: Now that we have more precise debug info, we should change back to use maximum to get basic block weight.
Reviewers: dnovillo
Subscribers: andreadb, llvm-commits
Differential Revision: https://reviews.llvm.org/D24788
llvm-svn: 282084
|
|
|
|
| |
llvm-svn: 282083
|
|
|
|
|
|
|
|
|
|
|
|
| |
The return types on the AVX512 __builtin_ia32_gather3XivXdi builtins are incorrect. The return type should match the type of the pass through vector.
Differential Revision: https://reviews.llvm.org/D24785
-This line, and those below, will be ignored--
M include/clang/Basic/BuiltinsX86.def
llvm-svn: 282082
|
|
|
|
|
|
|
|
| |
The return type should match the pass through vector type.
Differential Revision: https://reviews.llvm.org/D24744
llvm-svn: 282081
|
|
|
|
|
|
|
| |
Since the original object was already an llvm::SmallString<>
there's no point calling c_str() first.
llvm-svn: 282080
|
|
|
|
|
|
|
|
|
|
| |
This updates getters and setters to use StringRef instead of
const char *. I tested the build on Linux, Windows, and OSX
and saw no build or test failures. I cannot test any BSD
or Android variants, however I expect the required changes
to be minimal or non-existant.
llvm-svn: 282079
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is PR30442.
Previously we were failed to parce complex expressions like:
foo : { *(SORT_BY_NAME(bar) zed) }
Main idea of patch that globs and excludes can be wrapped in a SORT.
There is a difference in semanics of ld/gold:
ld likes:
*(SORT(EXCLUDE_FILE (*file1.o) .foo.1))
gold likes:
*(EXCLUDE_FILE (*file1.o) SORT(.foo.1))
Patch implements ld grammar, complex expressions like
next is not a problem anymore:
.abc : { *(SORT(.foo.* EXCLUDE_FILE (*file1.o) .bar.*) .bar.*) }
Differential revision: https://reviews.llvm.org/D24758
llvm-svn: 282078
|
|
|
|
|
|
|
|
|
|
| |
-mem2reg"
(And follow-up r281964.)
It caused PR30468.
llvm-svn: 282077
|
|
|
|
| |
llvm-svn: 282076
|
|
|
|
|
|
|
|
| |
Replacing swifterror arguments with undef creates invalid IR.
rdar://28300490
llvm-svn: 282075
|
|
|
|
| |
llvm-svn: 282074
|
|
|
|
|
|
|
|
|
|
|
|
| |
NestedNameSpecifier.
Reviewers: hokein
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D24784
llvm-svn: 282073
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch refactors the way the XState type is checked and, in order to
simplify the code, it removes the usage of the 'cpuid' instruction: just checking
if the ptrace calls done throuhg ReadFPR is enough to verify both if there is
HW support and if there is kernel support. Also the XCR0 bits are enough to check if
there is both HW and kernel support for AVX and MPX.
Differential Revision: https://reviews.llvm.org/D24764
llvm-svn: 282072
|
|
|
|
| |
llvm-svn: 282071
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch introduces a new tool which moves a specific class definition
from files (.h, .cc) to new files (.h, .cc), which mostly acts like
"Extract class defintion". In the long term, this tool should be
merged in to clang-refactoring as a subtool.
clang-move not only moves class definition, but also moves all the
forward declarations, functions defined in anonymous namespace and #include
headers to new files, to make sure the new files are compliable as much
as possible.
To move `Foo` from old.[h/cc] to new.[h/cc], use:
```
clang-move -name=Foo -old_header=old.h -old_cc=old.cc -new_header=new.h
-new_cc=new.cc old.cc
```
To move `Foo` from old.h to new.h, use:
```
clang-move -name=Foo -old_header=old.h -new_header=new.h old.cc
```
Reviewers: klimek, djasper, ioeric
Subscribers: mgorny, beanz, Eugene.Zelenko, bkramer, omtcyfz, cfe-commits
Differential Revision: https://reviews.llvm.org/D24243
llvm-svn: 282070
|
|
|
|
|
|
|
|
| |
We still don't really have an equivalent of "AssertXExt" in DAG, so we don't
exploit the guarantees on the receiving side yet, but this should produce
conservatively correct code on iOS ABIs.
llvm-svn: 282069
|
|
|
|
|
|
|
|
| |
The only implementation that exists immediately looks it up anyway, and the
information is needed to handle various parameter attributes (stored on the
function itself).
llvm-svn: 282068
|
|
|
|
|
|
|
|
| |
When final image has several .bss sections, lld fails
because second .bss always has zero VA. This causes
link error "Not enough space for ELF and program headers"
llvm-svn: 282067
|
|
|
|
|
|
|
| |
`ClangASTSource::FindExternalVisibleDecls` has void return type, so the
previous docstring was misleading.
llvm-svn: 282066
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: It is replaced by AMDGPUELFObjectWriter
Reviewers: tstellarAMD, vpykhtin, artem.tamazov
Subscribers: arsenm, kzhuravl, wdng, nhaehnle, yaxunl
Differential Revision: https://reviews.llvm.org/D24654
llvm-svn: 282065
|
|
|
|
|
|
| |
This reverts commit r282061 because it broke the clang-cuda-build bot.
llvm-svn: 282064
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The postRA scheduler performs alias analysis to determine if stores and loads
can moved past each other. When a function has more arguments than argument
registers for the calling convention used, excess arguments are spilled onto the
stack. LLVM by default assumes that argument slots are immutable, unless the
function contains a tail call. Without the knowledge of that a function contains
a tail call site, stores and loads to fixed stack slots may be re-ordered
causing the out-going arguments to clobber the incoming arguments before the
incoming arguments are supposed to be dead.
Reviewers: vkalintiris
Differential Review: https://reviews.llvm.org/D24077
llvm-svn: 282063
|
|
|
|
|
|
|
| |
Align the naming / use of the macro LIBCXXABI_HAS_NO_THREADS to follow what we
have in libcxx. NFC.
llvm-svn: 282062
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
One of the tests relying on sem_t's layout gets the wrong value for versions of
glibc newer than 2.21 on platforms that don't have 64-bit atomics (e.g. ARM).
This commit fixes the test to work with:
* versions of glibc >= 2.21 on platforms with 64-bit atomics: unchanged
* versions of glibc >= 2.21 on platforms without 64-bit atomics: the semaphore
value is shifted by SEM_VALUE_SHIFT (which is set to 1 in glibc's internal
headers)
* versions of glibc < 2.21: unchanged
See the glibc 2.23 sources:
* sysdeps/nptl/internaltypes.h (struct new_sem for glibc >= 2.21 and
struct old_sem for glibc < 2.21)
* nptl/sem_getvalue.c
This was uncovered on one of the new buildbots that we are trying to move to
production.
Differential Revision: https://reviews.llvm.org/D24766
llvm-svn: 282061
|
|
|
|
|
|
|
|
|
|
|
| |
It is not only a bit more straightforward now, but also next 2 issues are solved:
* It just crashed on ".foo : { *(EXCLUDE_FILE (*file1.o)) }" before.
* It accepted multiple EXCLUDE_FILEs in a row.
Differential revision: https://reviews.llvm.org/D24726
llvm-svn: 282060
|
|
|
|
| |
llvm-svn: 282059
|
|
|
|
|
|
|
| |
This reverts commit r282057 because it broke the buildbots - see e.g.
http://lab.llvm.org:8011/builders/clang-cmake-aarch64-42vma/builds/12063
llvm-svn: 282058
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: AArch64 LLVM assembler emits add instruction without shift bit to calculate the higher 12-bit address of TLS variables in local exec model. This generates wrong code sequence to access TLS variables with thread offset larger than 0x1000.
Reviewers: t.p.northover, peter.smith, rovka
Subscribers: salim.nasser, aemerson, llvm-commits, rengolin
Differential Revision: https://reviews.llvm.org/D24702
llvm-svn: 282057
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: @returns is incorrect code, the standard is @return. However wrapping it can still confuse users.
Reviewers: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D24767
llvm-svn: 282056
|
|
|
|
|
|
|
|
|
|
|
|
| |
different opcodes.
It turns out isel is really not robust against having different type profiles for the same opcode. It turns out that if you put an illegal rounding mode(i.e. not CUR_DIRECTION or NO_EXC) on a comiss intrinsic we would generate the FSETCC form with the rounding mode added, but then pattern match to an instruction with ROUND_CUR_DIRECTION.
We can probably get away with just one FSETCCM opcode that always contains the rounding mode and explicitly put ROUND_CUR_DIRECTION in the pattern, but I'll leave that for future work.
With this change the clang tests for the comiss intrinsics that used an incorrect rounding mode of 3 properly fail isel instead of silently doing the wrong thing. Those clang tests will be fixed in a follow up commit and I also plan to add rounding mode checking to clang.
llvm-svn: 282055
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was changed in rL276151 and causes problems if the C++ compiler does not
support the same arches as the C compiler.
For the builtins, only the C compiler is tested in try_compile_only.
Additionally, -fno-exceptions is passed in (if available) to work around
the case where no libunwind is available.
Differential Revision: https://reviews.llvm.org/D23654
llvm-svn: 282054
|
|
|
|
|
|
| |
LLVM ERROR: Cannot select: 0x3607bf0: i32 = ExternalSymbol'__powidf2'
llvm-svn: 282053
|
|
|
|
|
|
|
|
|
|
| |
vcvtps2ph intrinsic lowering.
There was no way to control its value so it was always FROUND_CURRENT making it unnecessary. The true rounding mode is encoded in the immediate operand of the instruction.
This also removes the pattern from the rb form of the instructions since there is no way to specify the FROUND_NO_EXC rounding mode it required.
llvm-svn: 282052
|
|
|
|
|
|
|
|
| |
the second opcode since its never used. This makes it consistent with INTR_TYPE_2OP_MASK_RM and INTR_TYPE_3OP_MASK_RM.
And even if it was used we were passing the same operands to both so it wouldn't make sense to have two opcodes.
llvm-svn: 282051
|
|
|
|
| |
llvm-svn: 282050
|
|
|
|
|
|
|
|
|
|
| |
This surfaced again with Rust. As per bug 30435, rustc creates a
mergeable section with a sh_entsize zero. It bit us before, too.
I think we should relax the input check rather than being too picky.
Differential Revision: https://reviews.llvm.org/D24789
llvm-svn: 282049
|
|
|
|
|
|
|
|
| |
loop's
This can occur for example if some optimization drops the debug location.
llvm-svn: 282048
|