The idea behind WindowsSupport.h is that it's in the source directory so
that windows.h'isms don't leak out into the larger LLVM project. To that
end, any symbol that references a symbol from windows.h must be in this
private header, and not in a public header.
However, we had some useful utility functions in WindowsSupport.h which
have no dependency on the Windows API, but still only make sense on
Windows. Those functions should be usable outside of Support since there
is no risk of causing a windows.h leak. Although this introduces some
preprocessor logic in some header files, It's not too egregious and it's
better than the alternative of duplicating a ton of code.
Differential Revision: https://reviews.llvm.org/D47662
llvm-svn: 333798
This isn't encountered anywhere inside LLVM, so I wrote a test case to expose the issue and verify that it is fixed.
The basic problem is that the macho_load_command union contains all load comamnd structs. Load command structs in 32-bit macho files can be 32-bit aligned instead of 64-bit aligned.
There are some strange circumstances in which this can be exposed in a 64-bit macho if the load commands are invalid or if a 32-bit aligned load command is used. In the past we've worked around this type of problem with changes like r264232.
llvm-svn: 333797
Summary:
This allows to build and link the code with e.g.
-fsanitize=dataflow -fsanitize-coverage=trace-pc-guard,pc-table,func,trace-cmp
w/o providing (all) the definitions of trace-cmp hooks.
This is similar to dummy hooks provided by asan/ubsan/msan for the same purpose,
except that some of the hooks need to have the __dfsw_ prefix
since we need dfsan to replace them.
Reviewers: pcc
Reviewed By: pcc
Subscribers: delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D47605
llvm-svn: 333796
The avx512f intrinsic tests were in the avx512vl file. We were also missing some combinations of masking.
This does show that we fail to use the zero masking form of expand loads when the passthru is zero. I'll try to get that fixed shortly.
llvm-svn: 333795
Clang passes --plugin /path/to/LLVMgold.so to the linker when -flto is
passed. After r333607 we only ignore --plugin as a joined argument,
which means that the following argument (/path/to/LLVMgold.so) is
interpreted as an input file. This means that either every LTO'd
program ends up being linked with the gold plugin or we error out
if the plugin does not exist. The fix is to use Eq to ignore both
--plugin=foo and --plugin foo as before.
Differential Revision: https://reviews.llvm.org/D47657
llvm-svn: 333793
This fixes two major problems:
- We were not capping vector alignment as desired on 32-bit ARM.
- We were using different alignments based on the AVX settings on
Intel, so we did not have a consistent ABI.
This is an ABI break, but we think we can get away with it because
vectors tend to be used mostly in inline code (which is why not having
a consistent ABI has not proven disastrous on Intel).
Intel's AVX types are specified as having 32-byte / 64-byte alignment,
so align them explicitly instead of relying on the base ABI rule.
Note that this sort of attribute is stripped from template arguments
in template substitution, so there's a possibility that code templated
over vectors will produce inadequately-aligned objects. The right
long-term solution for this is for alignment attributes to be
interpreted as true qualifiers and thus preserved in the canonical type.
llvm-svn: 333791
Summary: One of the tests is failing to build because it needs GS-, the second test does not correctly match all the expected function names because newer DIA SDKs annotate the function names with their return type and inputs (e.g. "static long `anonymous namespace'::StaticFunction(int)")
Reviewers: asmith, zturner
Reviewed By: zturner
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D47653
llvm-svn: 333790
Summary: Skip the new break-insert test on Windows because it hangs and so the test suite never completes. All other lldb-mi tests in the test suite are also skipped on windows
Reviewers: asmith, aprantl, polyakov.alex
Reviewed By: aprantl
Subscribers: ki.stfu, llvm-commits
Differential Revision: https://reviews.llvm.org/D47651
llvm-svn: 333789
In r331719, I changed Module::FindTypes not to limit the amount
of types returned by the Symbol provider, because we want all
possible matches to be able to filter them. In one code path,
the filtering was applied to the TypeList without changing the
number of types that gets returned. This is turn could cause
consumers to access beyond the end of the TypeList.
This patch fixes this case and also adds an assertion to
TypeList::GetTypeAtIndex to catch those obvious programming
mistakes.
Triggering the condition in which we performed the incorrect
access was not easy. It happened a lot in mixed Swift/ObjectiveC
code, but I was able to trigger it in pure Objective C++ although
in a contrieved way.
rdar://problem/40254997
llvm-svn: 333786
It's been pointed out in https://reviews.llvm.org/D47646 that lldb-test
fails to create a usable process on Windows when running this test.
llvm-svn: 333785
Myriad only uses the platform interceptors for memory allocation
routines. Configure them properly.
Also add a missing guard around aligned alloc interceptor.
Differential Revision: https://reviews.llvm.org/D47641
llvm-svn: 333784
Summary:
Getelementptr returns a vector of pointers, instead of a single address,
when one or more of its arguments is a vector. In such case it is not
possible to simplify the expression by inserting a bitcast of operand(0)
into the destination type, as it will create a bitcast between different
sizes.
Reviewers: majnemer, mkuper, mssimpso, spatel
Reviewed By: spatel
Subscribers: lebedev.ri, llvm-commits
Differential Revision: https://reviews.llvm.org/D46379
llvm-svn: 333783
This bug:
https://bugs.llvm.org/show_bug.cgi?id=37648
...was created with the enhancement to this transform with rL332479.
The urem test shows the disaster potential: any undef divisor lane makes
the whole op undef.
The test diffs show that vector demanded elements turns some of the potential,
but not all, unused binop operands back into undef already.
llvm-svn: 333782
Summary:
Occasionally, when launching a process in lldb (especially on windows, but not limited to), lldb will hang before the process is launched and it will never recover. This happens because the timing of the processing of the state changes can be slightly different. The state changes that are issued are:
1) SetPublicState(eStateLaunching)
2) SetPrivateState(eStateLaunching)
3) SetPublicState(eStateStopped)
4) SetPrivateState(eStateStopped)
What we expect to see is:
public state: launching -> launching -> stopped
private state: launching -> stopped
What we see is:
public state: launching -> stopped -> launching
private state: launching -> stopped
The second launching change to the public state is issued when WaitForProcessStopPrivate calls HandlePrivateEvent on the event which was created when the private state was set to launching. HandlePrivateEvent has logic to determine whether to broadcase the event and a launching event is *always* broadcast. At the same time, when the stopped event is processed by WaitForProcessStopPrivate next, the function exists and that event is never broadcast, so the public state remains as launching.
HandlePrivateEvent does two things: determine whether there's a next action as well as determine whether to broadcast the event that was processed. There's only ever a next action set if we are trying to attach to a process, but WaitForProcessStopPrivate is only ever called when we are launching a process or connecting remotely, so the first part of HandlePrivateEvent (handling the next action) is irrelevant for WaitForProcessStopPrivate. As far as broadcasting the event is concerned, since we are handling state changes that already occurred to the public state (and are now duplicated in the private state), I believe the broadcast step is unnecessary also (and in fact, it causes the hang).
This change removes the call to HandlePrivateEvent from inside WaitForProcessStopPrivate.
Incidentally, there was also a bug filed recently that is the same issue: https://bugs.llvm.org/show_bug.cgi?id=37496
Reviewers: asmith, labath, zturner, jingham
Reviewed By: zturner, jingham
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D47609
llvm-svn: 333781
This is more consistent with all of our other avx512 macro intrinsics.
It also fixes a bad cast where an argument was casted to mmask8 when it should have been a mmask16.
llvm-svn: 333778
Summary:
The LLDB.framework generated when building with CMake + Ninja/Make is
completely missing the clang headers. Although the code to copy them exists, we
don't even generate them unless we're building LLDB standalone.
Reviewers: clayborg, labath, sas
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D47612
llvm-svn: 333777
Summary:
C++11 onwards specs the non-member functions atomic_load and atomic_load_explicit as taking the atomic<T> by const (potentially volatile) pointer. C11, in its infinite wisdom, decided to drop the const, and C17 will fix this with DR459 (the current draft forgot to fix B.16, but that’s not the normative part).
This patch fixes the libc++ version of the __c11_atomic_load builtins defined for GCC's compatibility sake.
D47618 takes care of the clang side.
Discussion: http://lists.llvm.org/pipermail/cfe-dev/2018-May/058129.html
<rdar://problem/27426936>
Reviewers: EricWF, mclow.lists
Subscribers: christof, cfe-commits
Differential Revision: https://reviews.llvm.org/D47613
llvm-svn: 333776
The `MipsAsmParser::loadImmediate` can load immediates of various sizes
into a register. Idea of this change is to use `loadImmediate` in the
`MipsAsmParser::expandMemInst` method to load offset into a register and
then call required load/store instruction.
The patch removes separate `expandLoadInst` and `expandStoreInst`
methods and does everything in the `expandMemInst` method to escape code
duplication.
Differential Revision: https://reviews.llvm.org/D47316
llvm-svn: 333774
Supporting GOT and TLS related relocations by the `.reloc` directive is
useful for purpose of testing various tools like a linker, for example.
llvm-svn: 333773
This fixes the bug where strip-all option was
leading to a malformed outputted ELF file.
Differential Revision: https://reviews.llvm.org/D47414
llvm-svn: 333772
Summary:
Emit summaries for bitcode modules that are only destined for the
regular LTO portion of the build so they can participate in
summary-based dead stripping.
This change reduces the size of a nacl_helper build with cfi-icall
enabled by 7%, removing the majority of the overhead due to enabling
cfi-icall. The cfi-icall size increase was caused by compiling in lots
of unused code and cfi-icall generating jumptable references to unused
symbols that could no longer be removed by -Wl,-gc-sections. Increasing
the visibility of summary-based dead stripping prevented jumptable
entries being created for unused symbols from the regular LTO portion
of the build.
Reviewers: pcc
Reviewed By: pcc
Subscribers: dschuff, mehdi_amini, inglorion, eraman, llvm-commits, kcc
Differential Revision: https://reviews.llvm.org/D47594
llvm-svn: 333768
-no-canonical-prefixes is a weird flag: In gcc, it controls whether realpath()
is called on the path of the driver binary. It's needed to support some
usecases where gcc is symlinked to, see
https://gcc.gnu.org/ml/gcc/2011-01/msg00429.html for some background.
In clang, the resource dir is found relative to the compiler binary, and
without -no-canonical-prefixes that's an absolute path. For clang, the main use
case for -no-canonical-prefixes is to make the -resource-dir path added by the
driver relative instead of absolute. Making it relative seems like the better
default, but since neither clang not gcc have -canonical-prefixes without no-
which makes changing the default tricky, and since some symlink behaviors do
depend on the realpath() call at least for gcc, just expose
-no-canonical-prefixes in clang-cl mode.
Alternatively we could default to no-canonical-prefix-mode for clang-cl since
it's less likely to be used in symlinked scenarios, but since you already need
to about -no-canonical-prefixes for the non-clang-cl bits of your build, not
hooking this of driver mode seems better to me.
https://reviews.llvm.org/D47480
llvm-svn: 333761
Clang calls "nvlink" for linking multiple object files with OpenMP
target functions, so correct this information when printing errors.
llvm-svn: 333757
Vedant Kumar