- Oct 03, 2011
-
-
Eric Christopher authored
llvm-svn: 141004
-
Howard Hinnant authored
llvm-svn: 141003
-
Rafael Espindola authored
llvm-svn: 141002
-
Rafael Espindola authored
llvm-svn: 141001
-
Chandler Carruth authored
configuration, although the test still stubs out more directories than are necessary or common in order to exercise all of the lookup paths observed with upstream GCC. This finishes testing the distribution-independent and GCC-installation-independent parts of the library path search logic. More testing is still needed for the triple detection, GCC-installation detection, and handling distributions with unusual configurations. llvm-svn: 141000
-
Chandler Carruth authored
enabled for debian hosts, which is quite odd. I think all restriction on when Clang attempts to use a multilib installation should go away. Clang is fundamentally a cross compiler. It behaves more like GCC when built as a cross compiler, and so it should just use multilib installs when they are present on the system. However, there is a very specific exemption for Exherbo, which I can't test on, so I'm leaving that in place. With this, check in a generic test tree for multilib on a 32-bit host. This stubs out many directories that most distributions don't use but that uptsream GCC supports. This is intended to be an agnostic test that the driver behaves properly compared with the GCC driver it aims for compatibility with. Also, fix a bug in the driver that this testing exposed (see!) where it was incorrectly testing the target architecture rather than the host architecture. If anyone is having trouble with the tree-structure stubs I'm creating to test this, let me know and I can revisit the design. I chose this over (for example) a tar-ball in order to make tests run faster at the small, hopefully amortized VCS cost. llvm-svn: 140999
-
Chandler Carruth authored
include *any* path on crtbegin.o unless we actually find such a file via one of the search paths. We still strictly check the search paths right after this, so we'll catch any issues there. The reason for this is that the driver does some normalization of the path on the actual object file, and this changes the textual format of the string on Windows. It no longer matches the textual format of the sysroot flag. llvm-svn: 140998
-
Craig Topper authored
Treat VEX.vvvv as a 3-bit field outside of 64-bit mode. Prevents access to registers xmm8-xmm15 outside 64-bit mode. llvm-svn: 140997
-
Chandler Carruth authored
any distros that use this, building a multilib GCC from mainline will install linker scripts here. llvm-svn: 140996
-
Chandler Carruth authored
This requires fixing a latent bug -- if we used the default host triple instead of an autodetected triple to locate GCC's installation, we didn't go back and fix the GCC triple. Correct that with a pile of hacks. This entire routine needs a major refactoring which I'm saving for a subsequent commit. Essentially, the detection of the GCC triple should be hoisted into the same routine as we locate the GCC installation: the first is intrinsically tied to the latter. Then the routine will just return the triple and base directory. Also start to bring the rest of the library search path logic under test, including locating crtbegin.o. Still need to test the multilib and other behaviors, but there are also bugs in the way of that. llvm-svn: 140995
-
Craig Topper authored
llvm-svn: 140994
-
Craig Topper authored
llvm-svn: 140993
-
Nick Lewycky authored
logic by David Meyer revealed this bug. llvm-svn: 140992
-
Torok Edwin authored
llvm-svn: 140991
-
Chandler Carruth authored
This is still very much a WIP, but sysroot was completely broken before this so we are moving closer to correctness. The crux of this is that 'ld' (on Linux, the only place I'm touching here) doesn't apply the sysroot to any flags given to it. Instead, the driver must translate all the paths it adds to the link step with the system root. This is easily observed by building a GCC that supports sysroot, and checking its driver output. This patch just fixes the non-multilib library search paths. We should also use this in many other places, but first things first. This also allows us to make the Linux 'ld' test independent of the host system. This in turn will allow me to check in test tree configurations based on various different distro's configuration. Again, WIP. llvm-svn: 140990
-
Argyrios Kyrtzidis authored
Instead of always storing all source locations for the selector identifiers we check whether all the identifiers are in a "standard" position; "standard" position is -Immediately before the arguments: -(id)first:(int)x second:(int)y; -With a space between the arguments: -(id)first: (int)x second: (int)y; -For nullary selectors, immediately before ';': -(void)release; In such cases we infer the locations instead of storing them. llvm-svn: 140989
-
Argyrios Kyrtzidis authored
llvm-svn: 140988
-
Argyrios Kyrtzidis authored
Instead of always storing all source locations for the selector identifiers we check whether all the identifiers are in a "standard" position; "standard" position is -Immediately before the arguments: [foo first:1 second:2] -With a space between the arguments: [foo first: 1 second: 2] -For nullary selectors, immediately before ']': [foo release] In such cases we infer the locations instead of storing them. llvm-svn: 140987
-
Argyrios Kyrtzidis authored
llvm-svn: 140986
-
Argyrios Kyrtzidis authored
llvm-svn: 140985
-
Argyrios Kyrtzidis authored
objc method decls. They are not stored in the AST yet. llvm-svn: 140984
-
Argyrios Kyrtzidis authored
llvm-svn: 140983
-
Argyrios Kyrtzidis authored
They are not kept in the AST yet. llvm-svn: 140982
-
Chandler Carruth authored
precisely match the pattern and logic used by the GCC driver on Linux as of a recent SVN checkout. This happens to follow a *much* more principled approach. There is a strict hierarchy of paths examined, first with multilib-suffixing, second without such suffixing. Any and all of these directories which exist will be added to the library search path when using GCC. There were many places where Clang followed different paths, omitted critical entries, and worst of all (in terms of challenges to debugging) got the entries in a subtly wrong order. If this breaks Clang on a distro you use, please let me know, and I'll work with you to figure out what is needed to work on that distro. I've checked the behavior of the latest release of Ubuntu, OpenSUSE, Fedora, and Gentoo. I'll be testing it on those as well as Debian stable and unstable and ArchLinux. I may even dig out a Slackware install. No real regression tests yet, those will follow once I add enough support for sysroot to simulate various distro layouts in the testsuite. llvm-svn: 140981
-
Nick Lewycky authored
llvm-svn: 140980
-
Nick Lewycky authored
llvm-svn: 140979
-
Peter Collingbourne authored
llvm-svn: 140978
-
Peter Collingbourne authored
llvm-svn: 140977
-
Peter Collingbourne authored
llvm-svn: 140976
-
Peter Collingbourne authored
llvm-svn: 140975
-
- Oct 02, 2011
-
-
Craig Topper authored
Fix some Intel syntax disassembly issues with instructions that implicitly use AL/AX/EAX/RAX such as ADD/SUB/ADC/SUBB/XOR/OR/AND/CMP/MOV/TEST. llvm-svn: 140974
-
John McCall authored
support both a fragile and non-fragile ABI, and it can be selected at runtime. That driver option also works on Darwin (although obviously the code is not necessarily usable if the system runtime is fragile) so just do that. llvm-svn: 140973
-
Craig Topper authored
Special case disassembler handling of REX.B prefix on NOP instruction to decode as XCHG R8D, EAX instead. Fixes PR10344. llvm-svn: 140971
-
John McCall authored
otherwise these tests would fail on hosts that happen to default to that, since that affects whether default synthesis can happen. llvm-svn: 140970
-
Nick Lewycky authored
r140966. llvm-svn: 140969
-
Chandler Carruth authored
can look at it. llvm-svn: 140968
-
Nick Lewycky authored
but not load instructions. Noticed by inspection. llvm-svn: 140966
-
Chandler Carruth authored
llvm-svn: 140965
-
Chandler Carruth authored
llvm-svn: 140964
-
Craig Topper authored
llvm-svn: 140962
-