Add a comment explaining that I have a better plan for implementing the
GCC installation search that requires fewer filesystem operations.
Planning to implement that next as the current approcah while thorough
(and so far looks correct) does a very unfortunate number of filesystem
operations.
I'm motivated to fix this in no small part because I would like to
support a much larger space of triples and GCC versions, which would
explode the current algorithm.
Invert the loop for detecting installed GCC trees. This make the loop
find the newest GCC available, among other goodness. It makes the entire
system much less prone to error from prefixes and/or system roots
pruning early the set of triples and GCC versions available.
Also, improve some comments and simplify the forms of some of the loops.
This causes the driver to stat directories more often than is strictly
necessary, but the alternatives which I looked at that still
accomplished this goal needed quite a bit more code and were likely not
much faster.
Test cases for this, now that our behavior here is significantly more
principled and predictable, should come tomorrow as I walk back through
VMs looking for edge cases that are missed after this.
Fuse the two halves of the GCC installation detection. This is
significantly cleaner (IMO) and more principled. We now walk down each
layer of the directory hierarchy searching for the GCC install. This
change does in fact introduce a significant behavior change in theory,
although in practice I don't know of any distro that will be impacted by
it negatively, and Debian may (untested) get slightly better through it.
Specifically, the logic now looks exhaustively for patterns such as:
/usr/lib/<triple>/gcc/<triple>
Previously, this would only be selected if there was *also*
a '/usr/lib/gcc/<triple>' directory, or if '<triple>' were the excat
DefaultHostTriple in the driver.
There is a 4-deep nested loop here, but it doesn't do terribly many
filesystem operations, as we skip at each layer of that layer's
directory doesn't exist.
There remains a significant FIXME in this logic: it would be much better
to first build up a set of candidate components for each of the four
layers with a bottom-up pruning such as this, but then select the final
installation using a top-down algorithm in order to find the newest GCC
installation available, regardless of which particular path leads to it.
-Add the location of the class name to all objc container decls, not just ObjCInterfaceDecl.
-Make objc decls consistent with the rest of the NamedDecls and have getLocation() point to the
class name, not the location of '@'.
Factor the data apart from the logic of locating various GCC
installations. This first selects a set of prefixes and a set of
compatible triples for the current architecture. Once selected, we drive
the search with a single piece of code.
This code isn't particularly efficient as it stands, but its only
executed once. I'm hoping as I clean up the users of this information,
it will also slowly become both cleaner and more efficient.
This also changes the behavior slightly. Previously, we had an ad-hoc
list of prefixes and triples, and we only looked for some triples
beneath specific prefixes and vice versa. This has led to lots of
one-off patches to support triple X, or support lib dir Y. Even without
going to a fully universal driver, we can do better here. This patch
makes us always look first in either 'lib32' or 'lib64' on 32- or 64-bit
hosts (resp.). However, we *always* look in 'lib'.
Currently I have one lingering problem with this strategy. We might find
a newer or better GCC version under a different (but equally compatible)
triple. Fundamentally, this loop needs to be fused with the one below.
That's my next patch.
Chad Rosier [Tue, 4 Oct 2011 01:53:36 +0000 (01:53 +0000)]
[driver] Improve r141053 by only emitting the warning if the original input
was assembly. Otherwise, something like -save-temps causes the integrated
assembler to warn.
Douglas Gregor [Tue, 4 Oct 2011 00:21:21 +0000 (00:21 +0000)]
When build a module on demand, run the module-building job on a
separate thread with the "suitably large" stack, so we don't blow the
stack when building modules recursively.
Anna Zaks [Mon, 3 Oct 2011 21:55:56 +0000 (21:55 +0000)]
[analyzer] In UndefBranchChecker, use a node generator which does not create an edge/branching. (ExprEngine should be in charge of generating edges. The checkers should examine the condition and generate PostCondition node if needed.)
Anna Zaks [Mon, 3 Oct 2011 21:16:32 +0000 (21:16 +0000)]
[analyzer] Cleanup in UndefBranchChecker:
- Remove unused FindUndefExpr::ProgramStateManager.
- The Condition parameter of the callback is the terminator of the block, no need to retrieve it again.
Refactor the detection of a GCC installation into a helper class. This
is designed to allow the detection to record more rich information about
the installation than just a single path.
Mostly, the functionality remains the same. This is primarily
a factoring change. However, the new factoring immediately fixes one
issue where on ubuntu we didn't walk up enough layers to reach the
parent lib path. I'll have a test tree for that once I finish making the
Ubuntu tree work reasonably.
Test a multilib setup on a 64-bit host. This is the far more common
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.
Enable generic multilib support on 32bit hosts. Previously this was only
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.
Relax an assertion here a bit. This doesn't really matter, as we won't
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.
Test that we include a GCC-triple-prefixed tree. While I don't know of
any distros that use this, building a multilib GCC from mainline will
install linker scripts here.
Teach the logic for locating an installed GCC about the system root.
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.
Add initial support for applying the sysroot to library search paths.
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.
Allow getting all source locations of selector identifiers in a ObjCMethodDecl.
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.
Allow getting all source locations of selector identifiers in a ObjCMessageExpr.
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.
Rework the selection of builtin library search paths on Linux to
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.
John McCall [Sun, 2 Oct 2011 20:27:18 +0000 (20:27 +0000)]
Sorry, I misunderstood the interaction here; the GNU runtime does
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.
John McCall [Sun, 2 Oct 2011 11:28:21 +0000 (11:28 +0000)]
Use -fgnu-runtime to force the use of the non-fragile ABI;
otherwise these tests would fail on hosts that happen to default
to that, since that affects whether default synthesis can happen.
Ted Kremenek [Sun, 2 Oct 2011 01:45:37 +0000 (01:45 +0000)]
Fix another major performance regression in LiveVariables by not canonicalizing the underlying ImmutableSets on every analyzed statement (just at merges). Fixes <rdar://problem/10087538>.
John McCall [Sun, 2 Oct 2011 01:16:38 +0000 (01:16 +0000)]
Make -fobjc-nonfragile-abi the -cc1 default, since it's the
increasingly prevailing case to the point that new features
like ARC don't even support the fragile ABI anymore.
This required a little bit of reshuffling with exceptions
because a check was assuming that ObjCNonFragileABI was
only being set in ObjC mode, and that's actually a bit
obnoxious to do.
Most, though, it involved a perl script to translate a ton
of test cases.
Mostly no functionality change for driver users, although
there are corner cases with disabling language-specific
exceptions that we should handle more correctly now.
John McCall [Sat, 1 Oct 2011 10:32:24 +0000 (10:32 +0000)]
When performing an @throw in ARC, retain + autorelease
the pointer, being sure to do so before running cleanups
associated with that full-expression. rdar://10042689
As I suspected, completely non-multilib machines just get no suffix.
Make the suffixes optional everywhere, and just make sure they have the
right value. The suffixes aren't the interesting part of this test
anyways.
Sorry for the churn as I let the bots try out various patterns.
Richard Smith [Sat, 1 Oct 2011 02:31:28 +0000 (02:31 +0000)]
constexpr: semantic checking for constexpr functions and constructors. Based in
part on patches by Peter Collingbourne.
We diverge from the C++11 standard in a few areas, mostly related to checking
constexpr function declarations, and not just definitions. See WG21 paper
N3308=11-0078 for details.
Function invocation substitution is not available in this patch; constexpr
functions cannot yet be used from within constant expressions.
Allow for both 'lib' and 'lib32', as both seem to be in evidence. I've
left a FIXME to go track down more distros and see if 'lib' is ever the
64-bit half.
John McCall [Sat, 1 Oct 2011 01:01:08 +0000 (01:01 +0000)]
Allow the results of cf_returns_not_retained function
calls, or calls to audited functions without an explicit
return attribute, to be casted without a bridge cast.
Tie this mechanism in with the existing exceptions to
the cast restrictions. State those restrictions more
correctly and generalize.
John McCall [Sat, 1 Oct 2011 00:48:56 +0000 (00:48 +0000)]
Tweak the interface for analyzing the CF conventions for a name
to take a FunctionDecl* instead of an llvm::StringRef. Eventually
we might push more logic in there, like using slightly different
conventions for C++ methods.
Also, fix a bug where 'copy' and 'create' were being caught in
non-camel-cased strings. We want copyFoo and CopyFoo and XCopy
but not Xcopy or xcopy.
Revert r140604: "Let -B work for ld paths on Linux."
This patch may do what it describes, it may not. It's hard to tell as
its completely unclear what this is supposed to do. There are also no
test cases. More importantly, this seems to have broken lots of linker
invocations on multilib Linux systems.
The manual pages for 'ld' on Linux mention translating a '=' at the
beginning of the path into a *configure time* sysroot prefix (this is,
I believe, distinct from the --sysroot flag which 'ld' also can
support). I tested this with a normal binutils 'ld', a binutils 'ld'
with the sysroot flag enabled, and gold with the sysroot flag enabled,
and all of them try to open the path '=/lib/../lib32', No translation
occurs.
I think at the very least inserting an '=' needs to be conditioned on
some indication that it is supported and desired. I'm also curious to
see what toolchain and whan environment cause it to actually make
a difference.
I'm going to add a test case for basic sanity of Linux 'ld' invocations
from Clang in a follow-up commit that would have caught this.
objc arc: allow objc_returns_inner_pointer on methods that return
a reference type, since inner reference is much like an inner pointer.
// rdar://10139365
David Chisnall [Fri, 30 Sep 2011 13:32:35 +0000 (13:32 +0000)]
Remove the conditional that avoided passing the Objective-C runtime specification flags to cc1. This fixes PR10369 (__builtin_NSStringMakeConstantString() selecting the wrong runtime in C / C++ code and crashing, although it doesn't fix the problem that instantiating the Mac runtime for non-Darwin targets was crashing.)
Sebastian Redl [Fri, 30 Sep 2011 08:32:17 +0000 (08:32 +0000)]
Fix a bug in the token caching for inline constructors in C++11, and improve error recovery in both dialects. This should fix the GCC test suite failures as well.
John McCall [Fri, 30 Sep 2011 05:12:12 +0000 (05:12 +0000)]
Add explicit attributes to mark functions as having had their
CoreFoundation object-transfer properties audited, and add a #pragma
to cause them to be automatically applied to functions in a particular
span of code. This has to be implemented largely in the preprocessor
because of the requirement that the region be entirely contained in
a single file; that's hard to impose from the parser without registering
for a ton of callbacks.
Anna Zaks [Fri, 30 Sep 2011 02:19:19 +0000 (02:19 +0000)]
[analyzer] Fix a bug in RetainReleaseChecker diagnostics. It gives more precise error message on the modified test case (and prevents duplicate diagnostics when we purge at block granularity).
Anna Zaks [Fri, 30 Sep 2011 02:03:00 +0000 (02:03 +0000)]
[analyzer] Add -analyzer-purge option which can take on multiple values, remove -analyzer-purge=none. (Small refactor as well: move the work of constructing AnalysisManager from the callers to the class itself.)
Eli Friedman [Fri, 30 Sep 2011 01:13:51 +0000 (01:13 +0000)]
Some fixes for MS-style asm parsing: specifically, add some error checking, and handle asm comments using semicolons correctly. (The comments are actually surprisingly tricky.)
Richard Smith [Thu, 29 Sep 2011 23:18:34 +0000 (23:18 +0000)]
Mark the ExtWarn for in-class initialization of static const float members as a GNU extension. Don't extend the scope of this extension to all literal types in C++0x mode.
Richard Smith [Thu, 29 Sep 2011 19:11:37 +0000 (19:11 +0000)]
constexpr: semantic checking for constexpr variables.
We had an extension which allowed const static class members of floating-point type to have in-class initializers, 'as a C++0x extension'. However, C++0x does not allow this. The extension has been kept, and extended to all literal types in C++0x mode (with a fixit to add the 'constexpr' specifier).
Add support for alignment-specifiers in C1X and C++11, remove
support for the C++0x draft [[align]] attribute and add the C1X
standard header file stdalign.h
projects / clang / log