If a header file was processed for the second time, we could end up with a
wrong conditional stack and skipped ranges:
In the particular example, if the header guard is evaluated the second time and
it is decided to skip the conditional block, the corresponding "#endif" is
never seen since the preamble does not include it and we end up in the
Tok.is(tok::eof) case with a wrong conditional stack.
Detect the circular inclusion, emit a diagnostic and stop processing the
inclusion.
llvm-svn: 360418
Remove C4800 : ''type' : forcing value to bool 'true' or 'false' (performance warning)' from the list of forced disabled warnings.
I'm not seeing any regressions in VS2017/VS2019 llvm/clang builds from removing this.
Differential Revision: https://reviews.llvm.org/D61730
llvm-svn: 360417
In certain circumstances, optimizations pick line numbers from debug
intrinsic instructions as the new location for altered instructions. This
is problematic because the line number of a debugging intrinsic is
meaningless (it doesn't produce any machine instruction), only the scope
information is valid. The result can be the line number of a variable
declaration "leaking" into real code from debugging intrinsics, making the
line table un-necessarily jumpy, and potentially different with / without
variable locations.
Fix this by using zero line numbers when promoting dbg.declare intrinsics
into dbg.values: this is safe for debug intrinsics as their line numbers
are meaningless, and reduces the scope for damage / misleading stepping
when optimizations pick locations from the wrong place.
Differential Revision: https://reviews.llvm.org/D59272
llvm-svn: 360415
Remove C4355 : ''this' : used in base member initializer list' from the list of forced disabled warnings.
I'm not seeing any regressions in VS2017/VS2019 llvm/clang builds from removing this.
Differential Revision: https://reviews.llvm.org/D61757
llvm-svn: 360413
Summary:
Top-level "package" and "import" statements should generally be kept on
one line, for all languages.
----
This reverts commit rL356912.
The regression from rL356835 was fixed via rC358275.
Reviewers: krasimir, sammccall, MyDeveloperDay, xinz, dchai, klimek
Reviewed By: krasimir, xinz, dchai
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D60661
llvm-svn: 360411
Summary:
some unwind formats are specific to a single symbol file and so it does
not make sense for their parsing code live in the general Symbol library
(as is the case with eh_frame for instance). This is the case for the
unwind information in breakpad files, but the same will probably be true
for PDB unwind info (once we are able to parse that).
This patch adds the ability to fetch an unwind plan provided by a symbol
file plugin, as discussed in the RFC at
<http://lists.llvm.org/pipermail/lldb-dev/2019-February/014703.html>.
I've kept the set of changes to a minimum, as there is no way to test
them until we have a symbol file which implements this API -- that is
comming in a follow-up patch, which will also implicitly test this
change.
The interesting part here is the introduction of the
"RegisterInfoResolver" interface. The reason for this is that breakpad
needs to be able to resolve register names (which are present as strings
in the file) into register enums so that it can construct the unwind
plan. This is normally done via the RegisterContext class, handing this
over to the SymbolFile plugin would mean that it has full access to the
debugged process, which is not something we want it to have. So instead,
I create a facade, which only provides the ability to query register
names, and hide the RegisterContext behind the facade.
Also note that this only adds the ability to dump the unwind plan
created by the symbol file plugin -- the plan is not used for unwinding
yet -- this will be added in a third patch, which will add additional
tests which makes sure the unwinding works as a whole.
Reviewers: jasonmolenda, clayborg
Subscribers: markmentovai, amccarth, lldb-commits
Differential Revision: https://reviews.llvm.org/D61732
llvm-svn: 360409
While this fixed the windows bot failures, it also broke all other bots.
Upon closer inspection, it turns out that the windows bots were "broken"
because two tests were unexpectedly passing -- i.e., the original patch
(r360375) actually improved our stepping support on windows.
So instead, I remove the relevant XFAILs.
This reverts commit r360397.
llvm-svn: 360407
Suggested by Sean Fertile and Peter Smith.
Thunk section spacing decrease the total number of thunks. I measured a
decrease of 1% or less in some large programs, with no perceivable
slowdown in link time. Override getThunkSectionSpacing() to enable it.
0x2000000 is the farthest point R_PPC64_REL24 can reach. I tried several
numbers and found 0x2000000 works the best. Numbers near 0x2000000 work
as well but let's just use the simpler number.
As demonstrated by the updated tests, this essentially changes placement
of most thunks to the end of the output section. We leverage this
property to fix PR40740 reported by Alfredo Dal'Ava Júnior:
The output section .init consists of input sections from several object
files (crti.o crtbegin.o crtend.o crtn.o). Sections other than the last
one do not have a terminator. With this patch, we create the thunk after
the last .init input section and thus fix the issue. This is not
foolproof but works quite well for such sections (with no terminator) in
practice.
Reviewed By: ruiu, sfertile
Differential Revision: https://reviews.llvm.org/D61720
llvm-svn: 360405
Darwin if the version of libc++abi isn't new enough to include the fix
in r319123
This patch resurrects r264998, which was committed to work around a bug
in libc++abi that was causing _cxa_allocate_exception to return a memory
that wasn't double-word aligned.
http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20160328/154332.html
In addition, this patch makes clang issue a warning if the type of the
thrown object requires an alignment that is larger than the minimum
guaranteed by the target C++ runtime.
rdar://problem/49864414
Differential Revision: https://reviews.llvm.org/D61667
llvm-svn: 360404
Since July 15, 2015 (binutils-gdb commit
19a7fe52ae3d0971e67a134bcb1648899e21ae1c, included in 2.26), gas
--compress-debug-sections=zlib (gcc -gz) means zlib-gabi:
SHF_COMPRESSED. Before that it meant zlib-gnu (.zdebug).
clang's -gz was introduced in rC306115 (Jun 2017) to indicate zlib-gnu. It
is 2019 now and it is not unreasonable to assume users of the new
feature to have new linkers (ld.bfd/gold >= 2.26, lld >= rLLD273661).
Change clang's default accordingly to improve standard conformance.
zlib-gnu becomes out of fashion and gets poorer toolchain support.
Its mangled names confuse tools and are more likely to cause problems.
Reviewed By: compnerd
Differential Revision: https://reviews.llvm.org/D61689
llvm-svn: 360403
The current PIC model for WebAssembly is more like ELF in that it
allows symbol interposition.
This means that more functions end up being addressed via the GOT
and fewer directly added to the wasm table.
One effect is a reduction in the number of wasm table entries similar
to the previous attempt in https://reviews.llvm.org/D61539 which was
reverted.
Differential Revision: https://reviews.llvm.org/D61772
llvm-svn: 360402
This also allows three op patterns to use increased constant bus
limit of GFX10.
Differential Revision: https://reviews.llvm.org/D61763
llvm-svn: 360395
The current lowering uses an mfence. mfences are substaintially higher latency than the locked operations originally requested, but we do want to avoid contention on the original cache line. As such, use a locked instruction on a cache line assumed to be thread local.
Differential Revision: https://reviews.llvm.org/D58632
llvm-svn: 360393
Subtractor relocation addends are signed, so we need to read them via signed
int pointers. Accidentally treating 32-bit addends as unsigned leads to
out-of-range errors when we try to add very large (>INT32_MAX) bogus addends.
llvm-svn: 360392
If we have a large module which is mostly intrinsics, we hammer the lib call lookup path from CodeGenPrepare. Adding a fastpath reduces compile by 15% for one such example.
The problem is really more general than intrinsics - a module with lots of non-intrinsics non-libcall calls has the same problem - but we might as well avoid an easy case quickly.
llvm-svn: 360391
Re-enable test that was disabled because it deadlocks when running on
the bot, but was never enabled again. Can't reproduce deadlock locally
so trying to investigate by re-enabling test.
llvm-svn: 360388
Adds full edge details (rather than just edge targets) when out-of-range errors
are generated. Also fixes a bug where debugging output accessed an invalidated
DenseMap iterator by moving the debugging output above the invalidation point.
llvm-svn: 360383
Summary:
The ".dword" directive is a synonym for ".xword" and is used used
by klibc, a minimalistic libc subset for initramfs.
Reviewers: t.p.northover, nickdesaulniers
Reviewed By: nickdesaulniers
Subscribers: nickdesaulniers, javed.absar, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D61719
llvm-svn: 360381
Add check for, and parsing of, .dwo files to Statistics.cpp; create a new getNon
SkeletonUnitDie function for DWARFUnit.h
Reviewers: dblaikie
Differential Revision: https://review.llvm.org/D61755
llvm-svn: 360380
Summary:
This allows libFuzzer to unpoison parameter shadow before calling
LLVMFuzzerTestOneInput to eliminate the false positives described
in https://github.com/google/oss-fuzz/issues/2369.
Reviewers: eugenis
Reviewed By: eugenis
Subscribers: llvm-commits, metzman, kcc
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D61751
llvm-svn: 360379
Summary:
Prior to this change, every implementation of writeTo would add
OutputSectionOff to the output section buffer start before writing data.
Instead, do this math in the caller, so that it can be written once
instead of many times.
The output section offset is always equivalent to the difference between
the chunk RVA and the output section RVA, so we can replace the one
remaining usage of OutputSectionOff with that subtraction.
This doesn't change the size of SectionChunk because of alignment
requirements, but I will rearrange the fields in a follow-up change to
accomplish that.
Reviewers: ruiu, aganea
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D61696
llvm-svn: 360376
Currently when we single step over a source line, we run and stop at every branch in the source line range. We can reduce the number of times we stop when stepping over by figuring out if any of these branches are function calls, and if so, ignore these branches. Since we are stepping over we can safely ignore these calls since they will return to the next instruction. Currently the step logic would stop at those branches (1st stop), single step into the branch (2nd stop), and then set a breakpoint at the return address (3rd stop), and then continue.
Differential Revision: https://reviews.llvm.org/D58678
llvm-svn: 360375
The test 'test/Driver/XRay/xray-instrument-os.c' is supposed to XFAIL on -darwin triples.
However, LLVM can be configured to be built with a -macos triple instead, which is equivalent
to -darwin. This commit updates the XFAIL condition to also XFAIL with a -macos host triple.
llvm-svn: 360374
The test is failing sometimes because the debugger is failing to attach for lack of permissions. The fix is to call lldb_enable_attach inside the inferior main function
llvm-svn: 360371
Simon Pilgrim