The previous logic to find default entry name or subsystem does not
seem correct (i.e. was not compatible with MSVC linker). Previously,
default entry name was inferred from CRT functions and user-defined
entry functions. Subsystem was inferred from CRT functions.
Default entry name and subsystem are now inferred based on the
following table. Note that we no longer use CRT functions to infer
them.
Entry name Subsystem
main mainCRTStartup console
wmain wmainCRTStartup console
WinMain WinMainCRTStartup windows
wWinMain wWinMainCRTStartup windows
llvm-svn: 240922
We had two separate paths for member pointer conversion: one which
takes a constant and another which takes an arbitrary value. In the
latter case, we are permitted to construct arbitrary instructions.
It turns out that the bulk of the member pointer conversion is sharable
if we construct an artificial IRBuilder.
llvm-svn: 240921
Usually dllexported symbols are defined with 'extern "C"',
so identifying them is easy. We can just do hash table lookup
to look up exported symbols.
However, C++ non-member functions are also allowed to be exported,
and they can be specified with unmangled name. So, if /export:foo
is given, we need to look up not only "foo" but also its all
mangled names. In MSVC mangling scheme, that means that we need to
look up any symbol which starts with "?foo@@Y".
In this patch, we scan the entire symbol table to search for
a mangled symbol. The symbol table is a DenseMap, and that doesn't
support table lookup by string prefix. This is of course very
inefficient. But that should be probably OK because the user
should always add 'extern "C"' to dllexported symbols.
llvm-svn: 240919
This option is to ignore remaining undefined symbols and force
the linker to create an output file anyways.
The existing code assumes that there's no undefined symbol after
reportRemainingUndefines(). That assumption is legitimate.
I also don't want to mess up the existing code for this minor feature.
In order to keep it as is, remaining undefined symbols are replaced
with dummy defined symbols.
llvm-svn: 240913
When comparing two COMDAT sections, we need to take section values
and associative sections into account. This patch fixes that bug.
It fixes a crash bug of llvm-tblgen when linked with /opt:lldicf.
One thing I don't understand yet is that this logic seems to be
too strict. MSVC linker is able to create more compact executables
(which of course work correctly). With this ICF algorithm, LLD is
able to make executable smaller, but the outputs are larger than
MSVC's. There must be something I'm missing here.
llvm-svn: 240897
Format @autoreleasepool properly for the Attach brace style
by recognizing @autoreleasepool as a block introducer.
Patch from Strager Neds!
http://reviews.llvm.org/D10372
llvm-svn: 240896
We had a hack in SDAGBuilder in place to work around this but now we
can avoid that. Call BuildExactSDIV from BuildSDIV so DAGCombiner can
perform this trick automatically.
The added check in DAGCombiner is necessary to prevent exact sdiv by pow2
from regressing as the target-specific pow2 lowering is not aware of
exact bits yet.
This is mostly covered by existing tests. One side effect is that we
get the better lowering for exact vector sdivs now too :)
llvm-svn: 240891
the DW_AT_bit_offset computation, the byte offset is in fact also
endian-dependent as it needs to point to the storage unit containing the
most-significant bit of the the bitfield.
I'm so looking forward to emitting the endian-agnostic DWARF 3 version
instead.
llvm-svn: 240890
Summary:
Previously it (incorrectly) used GPR's.
Patch by Simon Dardis. A couple small corrections by myself.
Reviewers: dsanders
Reviewed By: dsanders
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D10567
llvm-svn: 240883
ctypes 0.3 and earlier contains an interface-definig bug:
its ptr_of_raw_address accepts Int64 and not Nativeint. ctypes 0.4
was not released during the 3.6 cycle, and because of that, LLVM 3.6
was released with ctypes 0.3 as a dependency, which now breaks
the build on modern ctypes.
Unbreak.
llvm-svn: 240882
Summary:
On PPC64, half the msan tests fail with an infinite recursion through
GetStackTrace like this:
#0 __msan::GetStackTrace
#1 __msan_memcpy
#2 ?? () from /lib64/libgcc_s.so.1
#3 ?? () from /lib64/libgcc_s.so.1
#4 _Unwind_Backtrace
#5 __sanitizer::BufferedStackTrace::SlowUnwindStack
#6 __sanitizer::BufferedStackTrace::Unwind
#7 __msan::GetStackTrace
#8 __interceptor_calloc
#9 _dl_allocate_tls
#10 pthread_create@@GLIBC_2.17
#11 __interceptor_pthread_create
#12 main
The problem is that we call _Unwind_Backtrace to get a stack trace; but
_Unwind_Backtrace calls memcpy, which we intercept and try to get
another stack trace.
This patch fixes it in __msan_memcpy by skipping the stack trace if
IsInSymbolizer(). This works because GetStackTrace already creates a
SymbolizerScope to "block reports from our interceptors during
_Unwind_Backtrace".
Reviewers: samsonov, wschmidt, eugenis
Reviewed By: eugenis
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D10762
llvm-svn: 240878
If we are dealing with a pointer induction variable, isInductionPHI
gives back a step value of Stride / size of pointer. However, we might
be indexing with a legal type wider than the pointer width.
Handle this by inserting casts where appropriate instead of crashing.
This fixes PR23954.
llvm-svn: 240877
The PruneEH pass tries to annotate functions as 'noreturn' if it doesn't
see a ReturnInst. However, a naked function containing inline assembly
can contain control flow leaving the function.
This fixes PR23971.
llvm-svn: 240876
This case had been failing on testers that didn't have x86 support. Rather
than XFAIL it on testers without x86 support, I've just assembled it and used
the raw object as the test input.
llvm-svn: 240875
This function is actually *very* hot. It is hard to see currently
because the call graph is very recursive, but I'm working to remove that
and when I do this function becomes significantly higher on the profile
(up to 5%!) and so worth avoiding the call overhead.
No specific perf gain I can measure yet (below the noise), but likely to
have more impact as we stop cluttering the call graph.
Differential Revision: http://reviews.llvm.org/D10788
llvm-svn: 240873
Igor Breger