The symbol-aware stack hint combines the checker-provided message
with the information about how the symbol was passed to the callee: as
a parameter or a return value.
For malloc, the generated messages look like this :
"Returning from 'foo'; released memory via 1st parameter"
"Returning from 'foo'; allocated memory via 1st parameter"
"Returning from 'foo'; allocated memory returned"
"Returning from 'foo'; reallocation of 1st parameter failed"
(We are yet to handle cases when the symbol is a field in a struct or
an array element.)
llvm-svn: 152962
fast-isel before emitting code. If the program bails after code was emitted,
then it could lead to the stack being adjusted more than once (two
CALLSEQ_BEGINs emitted) but being adjuste back only once after the call. This
leads to general badness and gnashing of teeth.
<rdar://problem/11050630>
llvm-svn: 152959
% is a common character in IR so we'd crash on almost any malformed IR. The
diagnostic formatter expects a formatting directive when it sees an unescaped %.
llvm-svn: 152956
store to 1. This allows code-gen to select a more appropriate alignment. If left
to zero, an alignment greater than the alignment of the pointer may be selected,
causing code-gen to use instructions which require an alignment greater than the
pointer guarantees.
<rdar://problem/11043589>
llvm-svn: 152951
It's not a good style idea, as the registers will be laid down in memory in
numerical order, not the order they're in the list, but it's legal. vldm/vstm
are stricter.
rdar://11064740
llvm-svn: 152943
GetSupportFileAtIndex(), GetNumSupportFiles(), FindSupportFileIndex():
Add API support for getting the list of files in a compilation unit.
GetNumCompileUnits(), GetCompileUnitAtIndex():
Add API support for retrieving the compilation units in a module.
llvm-svn: 152942
For "int i = NULL;" we would produce:
null.cpp:5:11: warning: implicit conversion of NULL constant to integer [-Wconversion]
int i = NULL;
~ ^~~~
null.cpp:1:14: note: expanded from macro 'NULL'
\#define NULL __null
^~~~~~
But we really shouldn't trace that macro expansion back into the header, yet we
still want macro back traces for code like this:
\#define FOO NULL
int i = FOO;
or
\#define FOO int i = NULL;
FOO
While providing appropriate tagging at different levels of the expansion, etc.
The included test case exercises these cases & does some basic validation (to
ensure we don't have macro expansion notes where we shouldn't, and do where we
should) - but doesn't go as far as to validate the source location/ranges
used in those notes and warnings.
llvm-svn: 152940
For boolean flags in Polly there is no problem if they are given more than once.
Hence, we can allow it to not fail for build systems that (acciently) add flags
several times.
This fixes: PR12278
Reported by: Sebastian Pop <sebpop@gmail.com>
llvm-svn: 152933
We currently do not support pointer types in affine expressions. Hence, we
disallow in the SCoP detection. Later we may decide to add support for them.
This fixes PR12277
Reported-By: Sebastian Pop <sebpop@gmail.com>
llvm-svn: 152928
In previous case,
RUN: foo -o %t
RUN: FileCheck < %t
RUN: bar -o %t
2nd read handle might prevent manipulation of 3rd %t in bar, to remove and rename.
llvm-svn: 152916
Enable incremental parsing by the Preprocessor,
where more code can be provided after an EOF.
It mainly prevents the tearing down of the topmost lexer.
To be used like this:
PP.enableIncrementalProcessing();
while (getMoreSource()) {
while (Parser.ParseTopLevelDecl(ADecl)) {...}
}
PP.enableIncrementalProcessing(false);
llvm-svn: 152914
Ted Kremenek