| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
| |
when compile for MIPS targets.
llvm-svn: 154195
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
inside of a sysroot targeting a system+sysroot which is "similar" or
"compatible" with the host system. This shows up when trying to build
system images on largely compatible hardware as-if fully cross compiled.
The problem is that previously we *perfectly* mimiced GCC here, and it
turns out GCC has a bug that no one has really stumbled across. GCC will
try to look in thy system prefix ('/usr/local' f.ex.) into which it is
instaled to find libraries installed along side GCC that should be
preferred to the base system libraries ('/usr' f.ex.). This seems not
unreasonable, but it has a very unfortunate consequence when combined
with a '--sysroot' which does *not* contain the GCC installation we're
using to complete the toolchain. That results in some of the host
system's library directories being searched during the link.
Now, it so happens that most folks doing stuff like this use
'--with-sysroot' and '--disable-multilib' when configuring GCC. Even
better, they're usually not cross-compiling to a target that is similar
to the host. As a result, searching the host for libraries doesn't
really matter -- most of the time weird directories get appended that
don't exist (no arm triple lib directory, etc). Even if you're
cross-compiling from 32-bit to 64-bit x86 or vice-versa, disabling
multilib makes it less likely that you'll actually find viable libraries
on the host. But that's just luck. We shouldn't rely on this, and this
patch disables looking in the system prefix containing the GCC
installation if that system prefix is *outside* of the sysroot. For
empty sysroots, this has no effect. Similarly, when using the GCC
*inside* of the sysroot, we still track wherever it is installed within
the sysroot and look there for libraries. But now we can use a cross
compiler GCC installation outside the system root, and only look for the
crtbegin.o in the GCC installation, and look for all the other libraries
inside the system root.
This should fix PR12478, allowing Clang to be used when building
a ChromiumOS image without polluting the image with libraries from the
host system.
llvm-svn: 154176
|
| |
|
|
|
|
| |
Review at http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20120402/055759.html
llvm-svn: 154064
|
| |
|
|
|
|
|
| |
enable neonfp on a CPU that doesn't support NEON.
rdar://11108618
llvm-svn: 154061
|
| |
|
|
| |
llvm-svn: 154056
|
| |
|
|
| |
llvm-svn: 154050
|
| |
|
|
|
|
| |
duplication. No functional change intended.
llvm-svn: 154049
|
| |
|
|
| |
llvm-svn: 154047
|
| |
|
|
|
|
|
|
|
|
|
| |
uses Neon instructions for single-precision FP.
-mfpmath=neon is analogous to passing llc -mattr=+neonfp.
-mfpmath=[vfp|vfp2|vfp3|vfp4] is analogous to passing llc -mattr=-neonfp.
rdar://11108618
llvm-svn: 154046
|
| |
|
|
|
|
|
| |
rewriter specific option to cc1 with -rewrite-objc.
// rdar://11143173
llvm-svn: 154037
|
| |
|
|
| |
llvm-svn: 154035
|
| |
|
|
|
|
|
| |
objective-c's fragile abi, Use -rewrite-objc for translating
objective-c's modern abi. // rdar://11143173
llvm-svn: 153877
|
| |
|
|
|
|
|
|
|
| |
llvm-gcc doesn't handle --serialize-diagnostics so when compiling i386
kernel/kext code with -Werror, you get an error about that option being
unused. Claim the argument to prevent this from breaking builds.
<rdar://problem/11161933>
llvm-svn: 153854
|
| |
|
|
| |
llvm-svn: 153678
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
flag as GCC uses: -fstrict-enums). There is a *lot* of code making
unwarranted assumptions about the underlying type of enums, and it
doesn't seem entirely reasonable to eagerly break all of it.
Much more importantly, the current state of affairs is *very* good at
optimizing based upon this information, which causes failures that are
very distant from the actual enum. Before we push for enabling this by
default, I think we need to implement -fcatch-undefined-behavior support
for instrumenting and trapping whenever we store or load a value outside
of the range. That way we can track down the misbehaving code very
quickly.
I discussed this with Rafael, and currently the only important cases he
is aware of are the bool range-based optimizations which are staying
hard enabled. We've not seen any issue with those either, and they are
much more important for performance.
llvm-svn: 153550
|
| |
|
|
|
|
|
|
|
|
|
|
| |
1. Don't short-circuit conditional statements that are checking flags.
Otherwise, the driver emits warnings about unused arguments.
2. -mkernel and -fapple-kext imply no exceptions, so claim exception related
arguments now to avoid warnings about unused arguments.
rdar://11120518
llvm-svn: 153478
|
| |
|
|
|
|
|
| |
argument warning.
Part of rdar://11120518
llvm-svn: 153470
|
| |
|
|
|
|
|
| |
argument warning.
Part of rdar://11120518
llvm-svn: 153469
|
| |
|
|
|
|
| |
Patch by Simon Atanasyan.
llvm-svn: 153348
|
| |
|
|
|
|
|
|
|
|
| |
The getARMTargetCPU and getLLVMArchSuffixForARM functions exist in both
Toolchain.cpp and Tools.cpp. This stuff needs a thorough overhaul. In the
meantime, this patch at least makes them consistent. One version had been
converted to use StringSwitch, and the other version had new Cortex M-series
processors added.
llvm-svn: 153202
|
| |
|
|
|
|
|
|
|
|
|
|
| |
On Darwin the architecture and the corresponding Mach-O slice is typically
specified with -arch. If not, it defaults to the current host architecture.
Do not use -mcpu to override the -arch value. This is only an issue when
people need to use specialized code for a non-default CPU (hopefully guarded
by run-time checks to detect the current processor). The -mcpu option is
still used for the -target-cpu option to clang, but this patch causes it to
not be used to set the architecture in the target triple.
llvm-svn: 153197
|
| |
|
|
|
|
|
|
| |
separate paths.
This regressed in r152583. Also add a test to make sure it doesn't regress again.
llvm-svn: 153034
|
| |
|
|
|
|
|
| |
the behavior of gcc with respect to the -fno-inline and -fno-inline-functions
flags.
llvm-svn: 152861
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Original commit message:
Provide -Wnull-conversion separately from -Wconversion.
Like GCC, provide a NULL conversion to non-pointer conversion as a separate
flag, on by default. GCC's flag is "conversion-null" which we provide for
cross compatibility, but in the interests of consistency (with
-Wint-conversion, -Wbool-conversion, etc) the canonical Clang flag is called
-Wnull-conversion.
Patch by Lubos Lunak.
Review feedback by myself, Chandler Carruth, and Chad Rosier.
llvm-svn: 152774
|
| |
|
|
|
|
|
| |
Abbreviated commit message:
Provide -Wnull-conversion separately from -Wconversion.
llvm-svn: 152765
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Like GCC, provide a NULL conversion to non-pointer conversion as a separate
flag, on by default. GCC's flag is "conversion-null" which we provide for
cross compatibility, but in the interests of consistency (with
-Wint-conversion, -Wbool-conversion, etc) the canonical Clang flag is called
-Wnull-conversion.
Patch by Lubos Lunak.
Review feedback by myself, Chandler Carruth, and Chad Rosier.
llvm-svn: 152745
|
| |
|
|
|
|
| |
rdar://10963572
llvm-svn: 152684
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, only diagnostics thrown by the cc1 process were
actually honoring the diagnostic options given on the command line,
like -Werror.
Reuse the existing code in Frontend currently used for cc1,
adjusting it to not interpret -Wl, linker flags as warnings.
Also fix a faulty test exposed by this change.
It wasn't actually testing anything, and was giving this warning:
clang-3: warning: argument unused during compilation: '-verify'
Which -Werror didn't turn into an error because it was output
by the driver, not the cc1 process, and diagnostic options
weren't parsed by the driver. And you couldn't see the warning
when running the test suite.
Fixes PR12181.
Patch by Dylan Noblesmith <nobled@dreamwidth.org>.
llvm-svn: 152660
|
| |
|
|
| |
llvm-svn: 152627
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
vcvarsall.bat.
FYI,
On VS10, %INCLUDE% contains;
(VS10)\VC\INCLUDE
(VS10)\VC\ATLMFC\INCLUDE
(SDK70A)\include
On VS11,
(VS11)\VC\INCLUDE
(VS11)\VC\ATLMFC\INCLUDE
(SDK80)\include\shared
(SDK80)\include\um
(SDK80)\include\winrt
FIXME: It may be enabled also on mingw.
llvm-svn: 152589
|
| |
|
|
|
|
|
|
| |
* s/AddDirectoryList/addDirectoryList/
* Move the call to ::getenv into the function.
* FileCheck-ize the testcase.
llvm-svn: 152583
|
| |
|
|
| |
llvm-svn: 152579
|
| |
|
|
|
|
|
|
| |
The LIBRARY_PATH environment variable should be honored by clang. Have the
driver pass the directories to the linker.
<rdar://problem/9743567> and PR10296.
llvm-svn: 152578
|
| |
|
|
|
|
| |
change.
llvm-svn: 152504
|
| |
|
|
| |
llvm-svn: 152441
|
| |
|
|
|
|
|
|
|
| |
- Remove -analyzer-inline-call.
- Add -analyzer-ipa=[none|inlining]
- Add -analyzer-inlining-mode to allow experimentation for
different performance tuning methods.
llvm-svn: 152351
|
| |
|
|
| |
llvm-svn: 152316
|
| |
|
|
|
|
| |
rdar://10993648
llvm-svn: 152180
|
| |
|
|
| |
llvm-svn: 152159
|
| |
|
|
|
|
|
| |
-fno-inline.
Part of rdar://10972766
llvm-svn: 152145
|
| |
|
|
|
|
|
|
|
|
|
| |
the new Objective-C NSArray/NSDictionary/NSNumber literal syntax.
This introduces a new library, libEdit, which provides a new way to support
migration of code that improves on the original ARC migrator. We now believe
that most of its functionality can be refactored into the existing libraries,
and thus this new library may shortly disappear.
llvm-svn: 152141
|
| |
|
|
| |
llvm-svn: 152140
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
NSNumber, and boolean literals. This includes both Sema and Codegen support.
Included is also support for new Objective-C container subscripting.
My apologies for the large patch. It was very difficult to break apart.
The patch introduces changes to the driver as well to cause clang to link
in additional runtime support when needed to support the new language features.
Docs are forthcoming to document the implementation and behavior of these features.
llvm-svn: 152137
|
| |
|
|
|
|
| |
rdar://10972766
llvm-svn: 152130
|
| |
|
|
|
|
| |
Fix a test, which was most likely an unintended recursive call.
llvm-svn: 151848
|
| |
|
|
|
|
|
|
|
|
| |
This flag enables ThreadSanitizer instrumentation committed to llvm as r150423.
The patch includes one test for -fthread-sanitizer and one similar test for -faddress-sanitizer.
This patch does not modify the linker flags (as we do it for -faddress-sanitizer) because the run-time library is not yet
committed and it's structure in compiler-rt is not 100% clear.
The users manual wil be changed in a separate commit.
llvm-svn: 151846
|
| |
|
|
|
|
| |
by actual humans.
llvm-svn: 151726
|
| |
|
|
|
|
| |
rdar://10459258
llvm-svn: 151706
|
| |
|
|
| |
llvm-svn: 151653
|
| |
|
|
|
|
| |
Solaris and we'll ship a __cxa_atexit implementation...
llvm-svn: 151648
|