Summary:
Make the comment alignment respect sections of line comments originally alinged
with the next token. Until now the decision how to break a continuous sequence
of line comments into sections was taken without reference to the next token.
source:
```
class A {
public: // comment about public
// comment about a
int a;
}
```
format before:
```
class A {
public: // comment about public
// comment about a
int a;
}
```
format after:
```
class A {
public: // comment about public
// comment about a
int a;
}
```
Reviewers: djasper, klimek
Reviewed By: klimek
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D29626
llvm-svn: 294435
There are about 3 underlying bugs causing the tests to fail.
On top of that, some tests just we're 'generic' enough. i.e. 32-bit
registers.
llvm-svn: 294434
Summary:
Enables source location in diagnostic messages from the backend. This
is after parsing, during finalization. This requires the SourceMgr, the
inline assembly string buffer, and DiagInfo to still be alive after
EmitInlineAsm returns.
This patch creates a single SourceMgr for inline assembly inside the
AsmPrinter. MCContext gets a pointer to this SourceMgr. Using one
SourceMgr per call to EmitInlineAsm would make it difficult for
MCContext to figure out in which SourceMgr the SMLoc is located, while a
single SourceMgr can figure it out if it has multiple buffers.
The Str argument to EmitInlineAsm is copied into a buffer and owned by
the inline asm SourceMgr. This ensures that DiagHandlers won't print
garbage. (Clang emits a "note: instantiated into assembly here", which
refers to this string.)
The AsmParser gets destroyed before finalization, which means that the
DiagHandlers the AsmParser installs into the SourceMgr will be stale.
Restore the saved DiagHandlers.
Since now we're using just one SourceMgr for multiple inline asm
strings, we need to tell the AsmParser which buffer it needs to parse
currently. Hand a buffer id -- returned from SourceMgr::
AddNewSourceBuffer -- to the AsmParser.
Reviewers: rnk, grosbach, compnerd, rengolin, rovka, anemet
Reviewed By: rnk
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D29441
llvm-svn: 294433
OUTPUT_ARCH command can contain architecture values separated with ":", like:
OUTPUT_ARCH(i386:x86-64)
We did not support that, because got 3 lexer tokens here after recent changes.
This trivial patch fixes the issue, now whole expression inside
OUTPUT_ARCH is just ignored.
Differential revision: https://reviews.llvm.org/D29640
llvm-svn: 294432
Filesystems are not required to maintain a hard link count consistent
with number of subdirectories. For example, on btrfs all directories
have nlink==1. Account for that in the test.
Differential Revision: https://reviews.llvm.org/D29706
llvm-svn: 294431
Disassembly currently begins from addresses obtained from the objects
symbol table. For ELF, add the dynamic symbols to the list if no
static symbols are available so that we can more successfully
disassemble stripped binaries.
Differential Revision: https://reviews.llvm.org/D29632
llvm-svn: 294430
This test is under 'ArgumentPromotion' but there are no arguments that
get promoted in the test case, so there seems to be no point. Also,
there are no assertions about the output at all, so this seems like
something we should just delete given the low value.
llvm-svn: 294428
renaming things to at least have somewhat spelled out names, and even
have meaningful names where I could guess at what they should be.
Also add FileCheck assertions that we're actually doing what we set out
to do for some of the tests, for example not promoting a type that would
result in infinite promotion.
llvm-svn: 294426
This feature flag indicates that the processor has support for removing certain instructions from user mode software. But the feature flag by itself doesn't indicate if the support is enabled in the OS. The affected instructions aren't even instructions the compiler would emit. So I don't think think this feature flag should be in the compiler.
llvm-svn: 294414
Add support for weak hooks on Windows, as we do on Linux and Darwin.
As we use the macro: `SANITIZER_INTERFACE_WEAK_DEF()` it was not necessary to
modify the header file: `sanitizer_common_interceptors.h`.
After this diff, many tests were fixed for libFuzzer.
Differential Revision: https://reviews.llvm.org/D29562
llvm-svn: 294409
Summary:
This teaches clang how to parse and lower the 'interrupt' and 'naked'
attributes.
This allows interrupt signal handlers to be written.
Reviewers: aaron.ballman
Subscribers: malcolm.parsons, cfe-commits
Differential Revision: https://reviews.llvm.org/D28451
llvm-svn: 294402
Add a warning for shadowed variables across records. Referencing a
shadow'ed variable may not give the desired variable. Add an optional
warning for the shadowing.
Patch by James Sun!
llvm-svn: 294401
Summary:
The Mips target is the only user of mnemonicIsValid. This patch
moves this method from AsmMatcherEmitter.cpp to MipsAsmParser.cpp,
getting rid of the method in all other targets where it generated
warnings about an unused function.
Patch by Gonsolo.
Reviewers: craig.topper
Reviewed By: craig.topper
Subscribers: sdardis
Differential Revision: https://reviews.llvm.org/D28748
llvm-svn: 294400
Summary:
After the DFS order change for LVI, i have a few testcases that now
take forever.
The TL;DR - This is mainly due to the overdefined cache, but that
requires predicateinfo to fix[1]
In order to maximize reuse of the LVI cache for now, change the order
we iterate in.
This reduces my testcase from 5 minutes to 4 seconds.
I have verified cases like gmic do not get slower.
I am playing with whether the order should be postorder or idf.
[1] In practice, overdefined anywhere should be overdefined
everywhere, so this cache should be global. That also fixes this bug.
The problem, however, is that LVI relies on this cache being filled in
per-block because it wants different values in different blocks due to
precisely the naming issue that predicateinfo fixes. With
predicateinfo, making the cache global works fine on individual
passes, and also resolves this issue.
Reviewers: davide, sanjoy, chandlerc
Subscribers: llvm-commits, djasper
Differential Revision: https://reviews.llvm.org/D29679
llvm-svn: 294398
We should always use unsigned long long to ensure 64 bits. On Windows, unsigned
long is 4 bytes. This was the reason why value-profile-cmp4.test was failing on
Windows.
Differential Revision: https://reviews.llvm.org/D29617
llvm-svn: 294390
Update cmake to use a custom target TestBinaries instead of a list of targets.
This simplifies cmake, and fix some errors. This way, we don't have to propagate
the values into parents directories. We only need to use add_dependencies.
Differential Revision: https://reviews.llvm.org/D29593
llvm-svn: 294389
For Windows, sanitizers work with Handles, not with posix file descriptors,
because they use the windows-specific API. So we need to convert the fds to
handles before passing them to the sanitizer library.
After this change, close_fd_mask is fixed for Windows (this fix some tests too).
Differential Revision: https://reviews.llvm.org/D29548
llvm-svn: 294388
On Windows, executables with the word "uninst" included in their names are
associated with administrator privileges.
Differential Revision: https://reviews.llvm.org/D29549
llvm-svn: 294387
Dylan McKay