| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
| |
This was previously only used when explicitly requested with a command line
option because it had to work with some old versions of the linker when it
was first introduced. That is ancient history now, and it should be safe to
use the correct option even when using the IPHONEOS_DEPLOYMENT_TARGET
environment variable to specify that the target is the iOS simulator.
Besides updating the test for this, I also added a few more tests for the
iOS linker options.
llvm-svn: 219527
|
|
|
|
|
|
|
|
| |
It turns out that this was never used. Instead we just use the
IPHONEOS_DEPLOYMENT_TARGET variable for both iOS devices and simulator.
rdar://problem/18596744
llvm-svn: 219467
|
|
|
|
|
|
|
|
|
| |
Looks like llvm::sys::path::filename() was canonicalizing my paths
before emitting them for FileCheck to stumble over.
Fix a style nit with r219460 while I'm at it.
llvm-svn: 219464
|
|
|
|
|
|
|
|
| |
When building with coverage, -no-integrated-as, and -c, the driver was
emitting -cc1 -coverage-file pointing at a file in /tmp. Ensure the
coverage file is emitted in the same directory as the output file.
llvm-svn: 219460
|
|
|
|
| |
llvm-svn: 219426
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This change adds an experimental flag -fsanitize-address-field-padding=N (0, 1, 2)
to clang and driver. With this flag ASAN will be able to detect some cases of
intra-object-overflow bugs,
see https://code.google.com/p/address-sanitizer/wiki/IntraObjectOverflow
There is no actual functionality here yet, just the flag parsing.
The functionality is being reviewed at http://reviews.llvm.org/D5687
Test Plan: Build and run SPEC, LLVM Bootstrap, Chrome with this flag.
Reviewers: samsonov
Reviewed By: samsonov
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D5676
llvm-svn: 219417
|
|
|
|
|
|
| |
Patch by: Charlie Turner <charlie.turner@arm.com>
llvm-svn: 219211
|
|
|
|
| |
llvm-svn: 219132
|
|
|
|
|
|
|
|
| |
ppc64le.
Reviewed by Hal Finkel and Bill Schmidt.
llvm-svn: 219129
|
|
|
|
|
|
|
|
| |
single threaded systems
http://reviews.llvm.org/D4985
llvm-svn: 219027
|
|
|
|
|
|
|
|
|
| |
Summary: The changes introduced in the above two commits are giving
a rough time to one of the build bots. Reverting the changes for the
moment so that the bot can go green again.
Change-Id: Id19f6cb2a8bc292631fac2262268927563d820c2
llvm-svn: 218970
|
|
|
|
|
|
|
|
| |
There's probably never a good reason to iterate over unique_ptrs. This
lets us use range-for and say Job.foo instead of (*it)->foo in a few
places.
llvm-svn: 218938
|
|
|
|
|
|
|
|
|
| |
Summary: This patch implements warnings/downgradable errors for
invalid -mfpu, -mfloat-abi option combinations (e.g. -mfpu=none
-mfloat-abi=hard).
Change-Id: I94fa664e1bc0b5855ad835abd7a50a3e0395632d
llvm-svn: 218863
|
|
|
|
|
|
| |
These were uncoveredby my yet undelivered patch.
llvm-svn: 218774
|
|
|
|
|
|
|
|
|
| |
The Cortex-M7 has 3 options for its FPU: none, FPv5-SP-D16 and
FPv5-DP-D16. FPv5 has the same instructions as FP-ARMv8, so it can be
modeled using the same target feature, and all double-precision
operations are already disabled by the fp-only-sp target features.
llvm-svn: 218748
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
being on by default. -fno-cxx-modules can still be used to enable C modules but
not C++ modules, but C++ modules is not significantly less stable than C
modules any more.
Also remove some of the scare words from the modules documentation. We're
certainly not going to remove modules support (though we might change the
interface), and it works well enough to bootstrap and build lots of
non-trivial code.
Note that this does not represent a commitment to the current interface nor
implementation, and we still intend to follow whatever direction the C and C++
committees take regarding modules support.
llvm-svn: 218717
|
|
|
|
| |
llvm-svn: 218630
|
|
|
|
|
|
|
|
|
|
|
| |
It makes no sense to link in sanitizer runtimes in this case: the user
probably doesn't want to see any system/toolchain libs in his link if he
provides these flags, and the link will most likely fail anyway - as sanitizer
runtimes depend on libpthread, libdl, libc etc.
Also, see discussion in https://code.google.com/p/address-sanitizer/issues/detail?id=344
llvm-svn: 218541
|
|
|
|
|
|
|
|
|
|
|
| |
Translate -lfoo to -lfoo.lib while making sure that -lfoo.lib stays as
-lfoo.lib. Also, these arguments were being passed twice: once
explicitly via AddAllArgs, and again implicitly as linker inputs. Now
they are passed once.
Fixes PR20868.
llvm-svn: 217895
|
|
|
|
|
|
| |
Use a couple more range based for loops. NFC.
llvm-svn: 217857
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Change 1: we used to add static sanitizer runtimes at the
very beginning of the linker invocation, even before crtbegin.o, which
is gross and not correct in general. Fix this: now addSanitizerRuntimes()
adds all sanitizer-related link flags to the end of the linker invocation
being constructed. It means, that we should call this function in the
correct place, namely, before AddLinkerInputs() to make sure sanitizer
versions of library functions will be preferred.
Change 2: Put system libraries sanitizer libraries depend on at the
end of the linker invocation, where all the rest system libraries are
located. Respect --nodefaultlibs and --nostdlib flags. This is another way
to fix PR15823. Original fix landed in r215940 put "-lpthread" and friends
immediately after static ASan runtime, before the user linker inputs.
This caused significant slowdown in dynamic linker for large binaries
linked against thousands of shared objects. Instead, to mark system
libraries as DT_NEEDED we prepend them with "--no-as-needed" flag,
discarding the "-Wl,--as-needed" flag that could be provided by the user.
Otherwise, this change is a code cleanup. Instead of having a special method
for each sanitizer, we introduce a function collectSanitizerRuntimes() that
analyzes -fsanitize= flags and returns the set of static and shared
libraries that needs to be linked.
llvm-svn: 217817
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Patch by Rafael Auler!
This patch addresses PR15171 and teaches Clang how to call other tools
with response files, when the command line exceeds system limits. This
is a problem for Windows systems, whose maximum command-line length is
32kb.
I introduce the concept of "response file support" for each Tool object.
A given Tool may have full support for response files (e.g. MSVC's
link.exe) or only support file names inside response files, but no flags
(e.g. Apple's ld64, as commented in PR15171), or no support at all (the
default case). Therefore, if you implement a toolchain in the clang
driver and you want clang to be able to use response files in your
tools, you must override a method (getReponseFileSupport()) to tell so.
I designed it to support different kinds of tools and
internationalisation needs:
- VS response files ( UTF-16 )
- GNU tools ( uses system's current code page, windows' legacy intl.
support, with escaped backslashes. On unix, fallback to UTF-8 )
- Clang itself ( UTF-16 on windows, UTF-8 on unix )
- ld64 response files ( only a limited file list, UTF-8 on unix )
With this design, I was able to test input file names with spaces and
international characters for Windows. When the linker input is large
enough, it creates a response file with the correct encoding. On a Mac,
to test ld64, I temporarily changed Clang's behavior to always use
response files regardless of the command size limit (avoiding using huge
command line inputs). I tested clang with the LLVM test suite (compiling
benchmarks) and it did fine.
Test Plan: A LIT test that tests proper response files support. This is
tricky, since, for Unix systems, we need a 2MB response file, otherwise
Clang will simply use regular arguments instead of a response file. To
do this, my LIT test generate the file on the fly by cloning many -DTEST
parameters until we have a 2MB file. I found out that processing 2MB of
arguments is pretty slow, it takes 1 minute using my notebook in a debug
build, or 10s in a Release build. Therefore, I also added "REQUIRES:
long_tests", so it will only run when the user wants to run long tests.
In the full discussion in
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130408/171463.html,
Rafael Espindola discusses a proper way to test
llvm::sys::argumentsFitWithinSystemLimits(), and, there, Chandler
suggests to use 10 times the current system limit (20MB resp file), so
we guarantee that the system will always use response file, even if a
new linux comes up that can handle a few more bytes of arguments.
However, by testing with a 20MB resp file, the test takes long 8 minutes
just to perform a silly check to see if the driver will use a response
file. I found it to be unreasonable. Thus, I discarded this approach and
uses a 2MB response file, which should be enough.
Reviewers: asl, rafael, silvas
Reviewed By: silvas
Subscribers: silvas, rnk, thakis, cfe-commits
Differential Revision: http://reviews.llvm.org/D4897
llvm-svn: 217792
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds a flag called -fseh-exceptions that uses the native Windows
.pdata and .xdata unwind mechanism to throw exceptions. The other EH
possibilities are DWARF and SJLJ exceptions.
Patch by Martell Malone!
Reviewed By: asl, rnk
Differential Revision: http://reviews.llvm.org/D3419
llvm-svn: 217790
|
|
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: The patch includes a test case.
Reviewers: hansw
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D5338
llvm-svn: 217710
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
specified.
Summary: This fixes http://llvm.org/PR20923.
Test Plan: This patch includes an automated test.
Reviewers: hansw
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D5334
llvm-svn: 217699
|
|
|
|
| |
llvm-svn: 217679
|
|
|
|
|
|
|
|
| |
It turned out that we have to bridge more stuff between the executable
and the ASan RTL DLL than just __asan_option_detect_stack_use_after_return.
See PR20918 for more details.
llvm-svn: 217673
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
preprocessor output
Summary:
cl.exe recognizes /o as a deprecated and undocumented option similar to
/Fe. This patch adds support for this option to clang-cl for /Fe, /Fo
and /Fi. It also ensures that the last option among /o and /F* wins,
if both specified.
This is required at least for building autoconf based software, since
autoconf uses -o to specify the executable output.
This fixes http://llvm.org/PR20894.
Test Plan: The patch includes automated tests.
Reviewers: rnk
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D5308
llvm-svn: 217615
|
|
|
|
|
|
|
| |
In all these cases it looks like the intention was to handle error in a similar
way to the file not existing.
llvm-svn: 217614
|
|
|
|
|
|
| |
No functionality change.
llvm-svn: 217586
|
|
|
|
|
|
|
|
| |
actually different. Fixes a surprising link error with nodejs on rpi,
where armv6-netbsd-eabihf turned into armv5e-netbsd-eabihf, which
doesn't lacks the necessary VFP support.
llvm-svn: 217546
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Currently, this is done implicitly in Driver::BuildInputs by considering
any invalid input type as linker input.
Test Plan: I don't think this behavior is observable for the reason stated above.
Reviewers: hansw
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D5294
llvm-svn: 217522
|
|
|
|
|
|
|
| |
Now that LLVM emits correct .pdata and .xdata for inline functions, we
can reenable this.
llvm-svn: 217178
|
|
|
|
| |
llvm-svn: 217168
|
|
|
|
|
|
|
|
| |
r216662 changed the default ABI for 32-bit ARM targets to be "aapcs"
when no environment is given in the triple, however NetBSD requires it
to be "apcs-gnu".
llvm-svn: 217141
|
|
|
|
| |
llvm-svn: 216876
|
|
|
|
|
|
| |
const from some other StringRefs since its implicitly const already.
llvm-svn: 216825
|
|
|
|
|
|
|
|
|
|
|
|
| |
It hits a limit when we reach ActionList, which is used for dynamic
conditional ownership, so we lose type safety there.
This did expose at least one caller "lying" about ownership (passing
ownership to an Action, then updating the Action to specify that it
doesn't actually own the thing that was passed) - changing this to
unique_ptr just makes that oddity more obvious.
llvm-svn: 216713
|
|
|
|
|
|
|
|
|
|
| |
With this patch we call external tools for powerpc-darwin with "-arch ppc"
instead of "-arch powerpc", so as to be compatible with the cctools assembler
and ld64 linker.
Patch by Stephen Drake!
llvm-svn: 216687
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The current default abi when no environment is given is "apcs-gnu",
which is obsolete. This patch changes the default to "aapcs". "aapcs" has both
hard- and soft-float variants, so the -mhard-float, -msoft-float and
-mfloat-abi= options now all behave as expected when no environment is
specified in the triple.
While writing this I also noticed that a preprocessor test claims to be
checking darwin, but is actually checking the defaults, which are
different for darwin.
llvm-svn: 216662
|
|
|
|
|
|
|
| |
Trivial fix, and I've made the gentoo tests more representative. With
the changes, they would have caught this failure.
llvm-svn: 216572
|
|
|
|
|
|
|
|
|
|
|
| |
ACLE 2.0 allows __fp16 to be used as a function argument or return
type. This enables this for AArch64.
This also fixes an existing bug that causes clang to not allow
homogeneous floating-point aggregates with a base type of __fp16. This
is valid for AAPCS64, but not for AAPCS-VFP.
llvm-svn: 216558
|
|
|
|
|
|
|
|
|
|
| |
There is no reason to have different library names for shared and static
cases on linux. It also breaks Android where we install the shared asan-rt
library into the system and should keep the old name.
This change reverts most of r216380 limiting it to win32 targets only.
llvm-svn: 216533
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
modern Debian-based distributions) due to on-going multiarch madness.
It appears that when the multiarch heeader search support went into the
clang driver, it went in in a quite bad state. The order of includes
completely failed to match the order exhibited by GCC, and in a specific
case -- when the GCC triple and the multiarch triple don't match as with
i686-linux-gnu and i386-linux-gnu -- we would absolutely fail to find
the libstdc++ target-specific header files.
I assume that folks who have been using Clang on Ubuntu 32-bit systems
have been applying weird patches to hack around this. I can't imagine
how else it could have worked. This was originally reported by a 64-bit
operating system user who had a 32-bit crosscompiler installed. We tried
to use that rather than the bi-arch support of the 64-bit compiler, but
failed due to the triple differences.
I've corrected all the wrong orderings in the existing tests and added
a specific test for the multiarch triple strings that are different in
a significant way. This should significantly improve the usability of
Clang when checked out vanilla from upstream onto Ubuntu machines with
an i686 GCC installation for whatever reason.
llvm-svn: 216531
|
|
|
|
|
|
| |
flag.
llvm-svn: 216472
|
|
|
|
|
|
|
| |
With this patch, "check-asan" passes all the tests with both MT and MD ASan RTL if you set COMPILER_RT_BUILD_SHARED_ASAN to ON
(PR20214)
llvm-svn: 216447
|
|
|
|
| |
llvm-svn: 216397
|
|
|
|
|
|
| |
Reviewed at http://reviews.llvm.org/D5026
llvm-svn: 216380
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch aims at fixing PR17239.
This bug happens because the /link (clang-cl.exe argument) is marked as
"consume all remaining arguments". However, when inside a response file,
/link should only consume all remaining arguments inside the response
file where it is located, not the entire command line after expansion.
The LLVM side of the patch will change the semantics of the
RemainingArgsClass kind to always consume only until the end of the
response file when the option originally came from a response file.
There are only two options in this class: dash dash (--) and /link.
This is the Clang side of the patch in http://reviews.llvm.org/D4899
Reviewered By: rafael, rnk
Differential Revision: http://reviews.llvm.org/D4900
Patch by Rafael Auler!
llvm-svn: 216281
|
|
|
|
| |
llvm-svn: 216029
|