DataFlowSanitizer is a generalised dynamic data flow analysis.
Unlike other Sanitizer tools, this tool is not designed to detect a
specific class of bugs on its own. Instead, it provides a generic
dynamic data flow analysis framework to be used by clients to help
detect application-specific issues within their own code.
Differential Revision: http://llvm-reviews.chandlerc.com/D966
llvm-svn: 187925
> This adds a bunch of options to clang-cl. Notably, this includes
> all the options that get passed when doing a default build of a
> command-line project with msbuild.exe in Debug and Release modes,
> and I believe all flags from Reid's original patch.
The original commit was reverted in r187640 after it broke the Mac build.
This should now be fixed, by Clang r187668, LLVM r187675, and putting
a -- before %s in the test.
llvm-svn: 187679
It broke the "phase1 - sanity" buildbot. Reverting until
we can figure out what's going on.
And Eric says it broke all current Mac builds actually.
llvm-svn: 187640
This adds a bunch of options to clang-cl. Notably, this includes
all the options that get passed when doing a default build of a
command-line project with msbuild.exe in Debug and Release modes,
and I believe all flags from Reid's original patch.
Differential Revision: http://llvm-reviews.chandlerc.com/D1264
llvm-svn: 187637
Patch by Ana Pazos
- Completed implementation of instruction formats:
AdvSIMD three same
AdvSIMD modified immediate
AdvSIMD scalar pairwise
- Completed implementation of instruction classes
(some of the instructions in these classes
belong to yet unfinished instruction formats):
Vector Arithmetic
Vector Immediate
Vector Pairwise Arithmetic
- Initial implementation of instruction formats:
AdvSIMD scalar two-reg misc
AdvSIMD scalar three same
- Intial implementation of instruction class:
Scalar Arithmetic
- Initial clang changes to support arm v8 intrinsics.
Note: no clang changes for scalar intrinsics function name mangling yet.
- Comprehensive test cases for added instructions
To verify auto codegen, encoding, decoding, diagnosis, intrinsics.
llvm-svn: 187568
This patch provides basic support for powerpc64le as an LLVM target.
However, use of this target will not actually generate little-endian
code. Instead, use of the target will cause the correct little-endian
built-in defines to be generated, so that code that tests for
__LITTLE_ENDIAN__, for example, will be correctly parsed for
syntax-only testing. Code generation will otherwise be the same as
powerpc64 (big-endian), for now.
The patch leaves open the possibility of creating a little-endian
PowerPC64 back end, but there is no immediate intent to create such a
thing.
The new test case variant ensures that correct built-in defines for
little-endian code are generated.
llvm-svn: 187180
They seemed to have the same implications, and this makes for one
less flag to worry about.
Differential Revision: http://llvm-reviews.chandlerc.com/D1219
llvm-svn: 187168
Use the same filtering for assembly arguments to -cc1as as we do for
-cc1, this allows a consistent (& more useful) diagnostic experience for
users (rather than getting an error from -cc1as (which a user shouldn't
really be thinking about) about --foo, they get an error from clang
about --foo in -Wa,)
I'm sort of surprised by the separation of -cc1as & the separate
argument handling, etc, but at least this removes a little bit of the
duplication.
llvm-svn: 187156
and add a new option --driver-mode= to control it explicitly.
The CCCIsCXX and CCCIsCPP flags were non-overlapping, i.e. there
are currently really three modes that Clang can run in: gcc, g++
or cpp, so it makes sense to represent them as an enum.
Having a command line flag to control it helps testing.
llvm-svn: 186605
When the -maltivec flag is present, altivec.h is auto-included for the
compilation. This is not appropriate when the job action is to
preprocess a file containing assembly code. So don't do that.
I was unable to convert the test in the bug report into a regression
test. The original symptom was exposed with:
% touch x.S
% ./bin/clang -target powerpc64-unknown-linux-gnu -maltivec -S -o - x.S
I tried this test (and numerous variants) on a PPC64 system:
----------------------------------------------------------------------------
// RUN: touch %t
// RUN: %clang -maltivec -S %t -o - | FileCheck %s
// Verify that assembling an empty file does not auto-include altivec.h.
// CHECK-NOT: static vector
----------------------------------------------------------------------------
However, this test passes for some reason even on a clang built
without the fix. I'd be happy to add a test case but at this point
I'm not able to figure one out, and I don't want to hold up the patch
unnecessarily. Please let me know if you have ideas.
Thanks,
Bill
llvm-svn: 185544
Darwin systems currently do not support dwarf version 3 or above. When we are
ready, we can bump the default to gdwarf-4 for Darwin.
For other systems, the default is dwarf version 3, if everything goes smoothly,
we can bump the version to 4.
rdar://13591116
llvm-svn: 185483
when specifying --coverage (or related) flags.
The system for doing this was based on the old LLVM-hosted profile_rt
library, and hadn't been updated for Linux to use the new compiler-rt
library. Also, it couldn't possibly work on multiarch or biarch systems
in many cases. The whole thing now works much the same as the sanitizer
libraries that are built and used out of the compiler-rt repo.
Note that other target OSes haven't been updated because I don't know if
they're doing anything special with the installation path of profile_rt.
I suspect however that *all* of these are wrong and would encourage
maintainers of each target to take a hard look at how compiler-rt
runtime libraries are linked on their platforms.
llvm-svn: 184666
gcc's inputs are already added by the InputInfoList passed to
Action::ConstructJob.
Fixes a regression from r183989. This was manifesting when targetting
mingw as an extra input argument to gcc when assembling. It presumably
affects other situations where clang calls gcc.
Prior to r183989, forwardToGCC() was returning false because the INPUT
option defined in OptParser.td had the DriverOption flag set on it.
LLVM's Option library does not set this flag for INPUT.
Reviewers: espindola
Differential Revision: http://llvm-reviews.chandlerc.com/D999
llvm-svn: 184308
These options will add a module flag with name "Dwarf Version".
The behavior flag is currently set to Warning, so when two values disagree,
a warning will be emitted.
llvm-svn: 184276
The big changes are:
- Deleting Driver/(Arg|Opt)*
- Rewriting includes to llvm/Option/ and re-sorting
- 'using namespace llvm::opt' in clang::driver
- Fixing the autoconf build by adding option everywhere
As discussed in the review, this change includes using directives in
header files. I'll make follow up changes to remove those in favor of
name specifiers.
Reviewers: espindola
Differential Revision: http://llvm-reviews.chandlerc.com/D975
llvm-svn: 183989
When choosing a default CPU, clang used to pick ARM7TDMI (which has Thumb) even
when the more restrictive armv4 triple was specified. This should fix that.
Patch by Jeroen Hofstee.
llvm-svn: 183905
integrated assembler then go ahead and still split the dwarf anyhow.
Add two tests, one to exercise existing behavior of not splitting
when we're just emitting assembly files and the other to test
that we split when we're not in integrated as mode.
llvm-svn: 183355
This option is used to select a dynamic loader prefix to be used
at runtime. Currently this is implemented for the Linux toolchain.
Differential Revision: http://llvm-reviews.chandlerc.com/D851
llvm-svn: 182744
If -fsanitize=leak is specified, link the program with the
LeakSanitizer runtime. Ignore this option when -fsanitize=address is specified,
because AddressSanitizer has this functionality built in.
llvm-svn: 182729
Sanitizer runtime intercepts functions from librt. Not doing this will fail
if the librt dependency is not present at program startup (ex. comes from a
dlopen()ed library).
llvm-svn: 182645
