LLVM isn't an acronym anymore.

llvm-svn: 148985

Always break upon finding a vreg operand (in Release as well as +Asserts). Remove assertion which can no longer trigger.

llvm-svn: 148984

If timestamps are enabled when logging GDB remote packets ("log enable -T -f /tmp/packets.log gdb-remote logs") then get the amount of time spent executing each packet and summarize at the end of a dump. Sample timing output looks like:

----------------------------------------------------------------------
Packet timing summary:
----------------------------------------------------------------------
Packet                 Time       %
---------------------- -------- ------
       qThreadStopInfo 0.363844  35.35
                     m 0.281967  27.39
                     s 0.147160  14.30
          qfThreadInfo 0.070865   6.88
          qsThreadInfo 0.061608   5.99
                     z 0.036796   3.57
                     Z 0.036271   3.52
                     c 0.018410   1.79
                     H 0.012418   1.21
---------------------- -------- ------
                 Total 1.029339 100.00

llvm-svn: 148983

llvm-svn: 148982

inside a 64-bit freebsd machine with the 32-bit compatibility layer
installed. The FreeBSD image always has the /usr/lib32 directory, so
test for the more concrete existence of crt1.o. Also enhance the tests
for freebsd to clarify what these trees look like and exercise the new
code.

Thanks to all the FreeBSD folks for helping me understand what caused
the failure and how we might fix it. =] That helps a lot. Also, yay
build bots.

llvm-svn: 148981

This suppresses typo correction for auto-generated call expressions such
as to 'begin' or 'end' within a C++0x for-range statement.

llvm-svn: 148979

Linux toolchain selection -- sorry folks. =] This should fix the Hexagon
toolchain.

However, I would point out that I see why my testing didn't catch this
-- we have no tests for Hexagon. ;]

llvm-svn: 148977

llvm-svn: 148974

Pass a typo correction callback object from ParseCastExpr to
Sema::ActOnIdExpression to be a bit more selective about what kinds of
corrections will be allowed for unknown identifiers.

llvm-svn: 148973

llvm-svn: 148972

llvm-svn: 148971

llvm-svn: 148970

"Although a Thumb2 instruction, the IT mnemonic shall be permitted in
ARM mode, and the condition verified to match the condition code(s)
on the following instruction(s)."

PR11853

llvm-svn: 148969

These commits are intended to be temporary in nature and are to facilitate the testing of libc++abi.dylib at this point in time.

llvm-svn: 148967

llvm-svn: 148966

cxa_guard.cpp didn't quite make it on the last commit:  Restricted headers to cxa_guard.cpp and abort_messsage.h, and added a comment regarding reentrancy brought up by John McCall.  Thanks John.

llvm-svn: 148965

llvm-svn: 148964

Restricted headers to cxa_guard.cpp and abort_messsage.h, and added a comment regarding reentrancy brought up by John McCall.  Thanks John.

llvm-svn: 148963

The new callback, in addition to limiting which keywords to include in
the pool of typo correction candidates, also filters out non-keyword
candidates that don't refer to (template) functions that accept the
number of arguments that are present for the call being recovered.

llvm-svn: 148962

get a function parameter pack (but don't due to weird substitutions),
complain. Fixes the last bit of PR11848.

llvm-svn: 148960

to suit the FreeBSD folks. Take them back to something closer to the old
behavior. We test whether the /usr/lib32 directory exists (within the
SysRoot), and use it if so, otherwise use /usr/lib.

FreeBSD folks, let me know if this causes any problems, or if you have
further tweaks.

llvm-svn: 148953

gross hack to provide it from my previous patch removing HostInfo. This
was enshrining (and hiding from my searches) the concept of storing and
diff-ing the host and target triples. We don't have the host triple
reliably available, so we need to merely inspect the target system. I've
changed the logic in selecting library search paths for NetBSD to match
what I provided for FreeBSD -- we include both search paths, but put the
32-bit-on-64-bit-host path first so it trumps.

NetBSD maintainers, you may want to tweak this, or feel free to ask me
to tweak it. I've left a FIXME here about the challeng I see in fixing
this properly.

llvm-svn: 148952

continue until cleanliness improves.

llvm-svn: 148951

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!

llvm-svn: 148950

freebsd test so that it's behavior isn't dependent on the filesystem of
the host running the tests. This should revive the build bots at least.
The tests and the trees still need a lot of love to make them as useful
and easy to maintain as linux-ld.c.

llvm-svn: 148949

llvm-svn: 148948

Thanks to Eli for noticing.

llvm-svn: 148947

llvm-svn: 148946

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.

llvm-svn: 148945

llvm-svn: 148944

llvm-svn: 148943

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.

llvm-svn: 148942

savings from a pointer argument becoming an alloca. Sometimes callees will even
compare a pointer to null and then branch to an otherwise unreachable block!
Detect these cases and compute the number of saved instructions, instead of
bailing out and reporting no savings.

llvm-svn: 148941

adding search paths. Add them only when they exist, and prefix the paths
with the sysroot. This will allow targeting a FreeBSD sysroot on
a non-FreeBSD host machine, and perhaps more importantly should allow
testing the FreeBSD driver's behavior similarly to the Linux tests with
a fake tree of files in the regression test suite.

I don't have FreeBSD systems handy to build up the list of files that
should be used here, but this is the basic functionality and I'm hoping
Roman or someone from the community can contribute the actual test
cases.

llvm-svn: 148940

search paths for 32-bit targets. This avoids having to detect which is
expected for the target system, and the linker should DTRT, and take the
32-bit libraries from the first one when applicable. Thanks to Roman
Divacky for sanity checking this.

llvm-svn: 148939

the GCC installation's multiarch suffix now that it is exposed.

llvm-svn: 148938

to 64-bits, and added a new attribute in bit #32. Specifically, remove
this new attribute from the enum used in the C API. It's not yet clear
what the best approach is for exposing these new attributes in the
C API, and several different proposals are on the table. Until then, we
can simply not expose this bit in the API at all.

Also, I've reverted a somewhat unrelated change in the same revision
which switched from "1 << 31" to "1U << 31" for the top enum. While "1
<< 31" is technically undefined behavior, implementations DTRT here.
However, MS and -pedantic mode warn about non-'int' type enumerator
values. If folks feel strongly about this I can put the 'U' back in, but
it seemed best to wait for the proper solution.

llvm-svn: 148937

llvm-svn: 148936

The fundamental shift here is to stop making *any* assumptions about the
*host* triple. Where these assumptions you ask? Why, they were in one of
the two target triples referenced of course. This was the single biggest
place where the previously named "host triple" was actually used as
such. ;] The reason we were reasoning about the host is in order to
detect the use of '-m32' or '-m64' flags to change the target. These
flags shift the default target only slightly, which typically means
a slight deviation from the host. When using these flags, the GCC
installation is under a different triple from the one actually targeted
in the compilation, and we used the host triple to find it.

Too bad that wasn't even correct. Consider an x86 Linux host which has
a PPC64 cross-compiling GCC toolchain installed. This toolchain is also
configured for multiarch compiling and can target PPC32 with eth '-m32'
flag. When targeting 'powerpc-linux-gnu' or some other PPC32 triple, we
have to look for the PPC64 variant of the triple to find the GCC
install, and that triple is neither the host nor target.

The new logic computes the multiarch's alternate triple from the target
triple, and looks under both sides. It also looks more aggressively for
the correct subdirectory of the GCC installation, and exposes the
subdirectory in a nice programmatic way. This '/32' or '/64' suffix is
something we can reuse in many other parts of the toolchain.

An important note -- while this likely fixes a large category of
cross-compile use cases, that's not my primary goal, and I've not done
testing (or added test cases) for scenarios that may now work. If
someone else wants to try more interesting PPC cross compiles, I'd love
to have reports. But my focus is on factoring away the references to the
"host" triple. The refactoring is my goal, and so I'm mostly relying on
the existing (pretty good) test coverage we have here.

Future patches will leverage this new functionality to factor out more
and more of the toolchain's triple manipulation.

llvm-svn: 148935

llvm-svn: 148934