| Age | Commit message (Collapse) | Author |
|---|
|
As in http://llvm.org/docs/ProgrammersManual.html#Statistic
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@151570 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
crash. This can speedup the process of generating a delta reduced test case.
rdar://10905465
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@151109 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
configure's --with-gcc-toolchain. The configure option is now just a default
value for the command line one.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150898 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This option was added in r129614 and doesn't have any use case that I'm aware
of. It's possible that external tools are using these names - and if that's
the case we can certainly reassess the functionality, but for now it lets us
shave out a few unneeded bits from clang.
Move the "StaticDiagNameIndex" table into the only remaining consumer, diagtool.
This removes the actual diagnostic name strings from clang entirely.
Reviewed by Chris Lattner & Ted Kremenek.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150612 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
When creating the MCSubtargetInfo, the assembler driver uses the CPU and
feature string to construct a more accurate model of what instructions
are and are not legal.
rdar://10840476
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150273 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
unused and wasted space for nothing.
- per PR11952.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150199 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
want to provide "po"-like functionality which
treats the result of an expression implicitly as
"id" (if it is not otherwise known) and prints
it as an Objective-C object.
This has in the past been gated by the
"DebuggerSupport" language option, but that is
too general. Debuggers also provide other commands
like "print" that do not make any assumptions
about whether the object is an Objective-C object.
This patch makes the assumption conditional on a
new language option: DebuggerCastResultToId. I
have also made corresponding modifications to the
testsuite.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149735 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
That llvm change removed the -trap-func backend option, so that using
-ftrap-function with clang would cause the backend to complain. Fix it
by adding the trap function name to the CodeGenOptions and passing it through
to the TargetOptions.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149679 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149645 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
dependencies and outputs them in GraphViz format.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149575 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
driver based on discussions with Doug Gregor. There are several issues:
1) The patch was not reviewed prior to commit and there were review comments.
2) The design of the functionality (triple-prefixed tool invocation)
isn't the design we want for Clang going forward: it focuses on the
"user triple" rather than on the "toolchain triple", and forces that
bit of state into the API of every single toolchain instead of
handling it automatically in the common base classes.
3) The tests provided are not stable. They fail on a few Linux variants
(Gentoo among them) and on mingw32 and some other environments.
I *am* interested in the Clang driver being able to invoke
triple-prefixed tools, but we need to design that feature the right way.
This patch just extends the previous hack without fixing the underlying
problems with it. I'm working on a new design for this that I will mail
for review by tomorrow.
I am aware that this removes functionality that NetBSD relies on, but
this is ToT, not a release. This functionality hasn't been properly
designed, implemented, and tested yet. We can't "regress" until we get
something that really works, both with the immediate use cases and with
long term maintenance of the Clang driver.
For reference, the original commit log:
Keep track of the original target the user specified before
normalization. This used to be captured in DefaultTargetTriple and is
used for the (optional) $triple-$tool lookup for cross-compilation.
Do this properly by making it an attribute of the toolchain and use it
in combination with the computed triple as index for the toolchain
lookup.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149337 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
'-target'. The original flag was part of a flag group that marked it as
driver-only. The new flag didn't ever get equivalent treatment. This
caused the '-target' flag to get passed down to any raw GCC invocation.
Marking it as a driver option fixes this and PR11875.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149244 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
normalization. This used to be captured in DefaultTargetTriple and is
used for the (optional) $triple-$tool lookup for cross-compilation.
Do this properly by making it an attribute of the toolchain and use it
in combination with the computed triple as index for the toolchain
lookup.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149083 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
provide the layout of records, rather than letting Clang compute
the layout itself. LLDB provides the motivation for this feature:
because various layout-altering attributes (packed, aligned, etc.)
don't get reliably get placed into DWARF, the record layouts computed
by LLDB from the reconstructed records differ from the actual layouts,
and badness occurs. This interface lets the DWARF data drive layout,
so we don't need the attributes preserved to get the answer write.
The testing methodology for this change is fun. I've introduced a
variant of -fdump-record-layouts called -fdump-record-layouts-simple
that always has the simple C format and provides size/alignment/field
offsets. There is also a -cc1 option -foverride-record-layout=<file>
to take the output of -fdump-record-layouts-simple and parse it to
produce a set of overridden layouts, which is introduced into the AST
via a testing-only ExternalASTSource (called
LayoutOverrideSource). Each test contains a number of records to lay
out, which use various layout-changing attributes, and then dumps the
layouts. We then run the test again, using the preprocessor to
eliminate the layout-changing attributes entirely (which would give us
different layouts for the records), but supplying the
previously-computed record layouts. Finally, we diff the layouts
produced from the two runs to be sure that they are identical.
Note that this code makes the assumption that we don't *have* to
provide the offsets of bases or virtual bases to get the layout right,
because the alignment attributes don't affect it. I believe this
assumption holds, but if it does not, we can extend
LayoutOverrideSource to also provide base offset information.
Fixes the Clang side of <rdar://problem/10169539>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149055 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
I'm not adding a testcase because -ccc-host-triple is slated to be removed,
but clang crashes if you try to use -ccc-host-triple without this fix.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149048 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
-fixit-recompile
applies fixits and recompiles the result
-fixit-to-temporary
applies fixits to temporary files
-fix-only-warnings">,
applies fixits for warnings only, not errors
Combining "-fixit-recompile -fixit-to-temporary" allows testing the result of fixits
without touching the original sources.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149027 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
unused yet.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149001 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
continue until cleanliness improves.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@148951 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
did anything. The two big pieces of functionality it tried to provide
was to cache the ToolChain objects for each target, and to figure out
the exact target based on the flag set coming in to an invocation.
However, it had a lot of flaws even with those goals:
- Neither of these have anything to do with the host, or its info.
- The HostInfo class was setup as a full blown class *hierarchy* with
a separate implementation for each "host" OS. This required
dispatching just to create the objects in the first place.
- The hierarchy claimed to represent the host, when in fact it was
based on the target OS.
- Each leaf in the hierarchy was responsible for implementing the flag
processing and caching, resulting in a *lot* of copy-paste code and
quite a few bugs.
- The caching was consistently done based on architecture alone, even
though *any* aspect of the targeted triple might change the behavior
of the configured toolchain.
- Flag processing was already being done in the Driver proper,
separating the flag handling even more than it already is.
Instead of this, we can simply have the dispatch logic in the Driver
which previously created a HostInfo object create the ToolChain objects.
Adding caching in the Driver layer is a tiny amount of code. Finally,
pulling the flag processing into the Driver puts it where it belongs and
consolidates it in one location.
The result is that two functions, and maybe 100 lines of new code
replace over 10 classes and 800 lines of code. Woot.
This also paves the way to introduce more detailed ToolChain objects for
various OSes without threading through a new HostInfo type as well, and
the accompanying boiler plate. That, of course, was the yak I started to
shave that began this entire refactoring escapade. Wheee!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@148950 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
a HostInfo reference. Nothing about the HostInfo was used by any
toolchain except digging out the driver from it. This just makes that
a lot more direct. The change was accomplished entirely mechanically.
It's one step closer to removing the shim full of buggy copy/paste code
that is HostInfo.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@148945 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
helped stage the refactoring of things a bit, but really isn't the right
place for it. The driver may be responsible for compilations with many
different targets. In those cases, having a target triple in the driver
is actively misleading because for many of those compilations that is
not actually the triple being targeted.
This moves the last remaining users of the Driver's target triple to
instead use the ToolChain's target triple. The toolchain has a single,
concrete target it operates over, making this a more stable and natural
home for it.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@148942 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
specific to migrator. Use its first option to
warn migrating from GC to arc when
NSAllocateCollectable/NSReallocateCollectable is used.
// rdar://10532541
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@148887 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
inside the innards of the Driver implementation, and only ever
implemented to return 'true' for the Darwin OSes. Instead use a more
direct query on the target triple and a comment to document why the
target matters here.
If anyone is worried about this predicate getting wider use or improper
use, I can make it a local or private predicate in the driver.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@148797 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The Driver has a fixed target, whether we like it or not, the
DefaultTargetTriple is not a default. This at least makes things more
honest. I'll eventually get rid of most (if not all) of
DefaultTargetTriple with this proper triple object. Bit of a WIP.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@148796 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
X86 backend in LLVM.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@148689 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@148582 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
also needs -fcxx-modules to enable modules for C++/Objective-C++.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@148393 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@148141 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Patch from Jyotsna Verma:
I have made the changes to remove assertions in the Hexagon backend
specific clang driver. Instead of asserting on invalid arch name, it has
been modified to use the default value.
I have changed the implementation of the CPU flag validation for the
Hexagon backend. Earlier, the clang driver performed the check and
asserted on invalid inputs. In the new implementation, the driver passes
the last CPU flag (or sets to "v4" if not specified) to the compiler (and
also to the assembler and linker which perform their own check) instead of
asserting on incorrect values. This patch changes the setCPU function for
the Hexagon backend in clang/lib/Basic/Targets.cpp which causes the
compiler to error out on incorrect CPU flag values.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@148139 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@148138 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@148137 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
rdar://10630328
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147591 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
default anyway).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147449 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
module imports from -fauto-module-import to -fmodules. The new name
will eventually be used to enable modules, and the #include/#import
mapping is a crucial part of the feature.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147447 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Clang driver. This involves a bunch of silly option parsing code to try
to carefully emulate GCC's options. Currently, this takes a conservative
approach, and unless all of the unsafe optimizations are enabled, none
of them are. The fine grained control doesn't seem particularly useful.
If it ever becomes useful, we can add that to LLVM first, and then
expose it here.
This also fixes a few tiny bugs in the flag management around
-fhonor-infinities and -fhonor-nans; the flags now form proper sets both
for enabling and disabling, with the last flag winning.
I've also implemented a moderately terrifying GCC feature where
a language change is also provided by the '-ffast-math' flag by defining
the __FAST_MATH__ preprocessor macro. This feature is tracked and
serialized in the frontend but it isn't used yet. A subsequent patch
will add the preprocessor macro and tests for it.
I've manually tested that codegen appears to respect this, but I've not
dug in enough to see if there is an easy way to test codegen options w/o
relying on the particulars of LLVM's optimizations.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147434 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
imply sse3. Matches gcc behavior.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147370 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
enabled, but can be disabled separately. Move popcnt intrinsics to popcntintrin.h to match gcc.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147340 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147262 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147224 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
the clang driver to enable this when assembling a .s file. rdar://9275556
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147167 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
http://llvm.org/docs/CodingStandards.html#ll_virtual_anch
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146959 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
especially nice as the Windows toolchain needs the windows header files,
and has lots of platform specific hooks in it.
To facilitate the split, hoist a bunch of file-level static helpers into
class-level static helpers. Spiff up their doxygen comments while there
as they're now more likely to be looked up via docs.
Hopefully, this will be followed by further breaking apart of the
toolchain definitions. Most of the large and complex ones should likely
live on their own. I'm looking at you Darwin. ;]
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146840 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
type.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146835 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
fails within a call to a constexpr function. Add -fconstexpr-backtrace-limit
argument to driver and frontend, to control the maximum number of notes so
produced (default 10). Fix APValue printing to be able to pretty-print all
APValue types, and move the testing for this functionality from a unittest to
a -verify test now that it's visible in clang's output.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146749 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
free function.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146530 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146441 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146413 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
-ffinite-math-only.
- No test case yet, I don't know how to construct a situation where this
matters.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146297 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
dual support for compiler-rt on Linux, during bringup.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146094 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
realignment, even with locals with alignment exceeding the ABI guarantee.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@145909 91177308-0d34-0410-b5e6-96231b3b80d8
|
