Anna Zaks [Tue, 8 Nov 2011 19:56:35 +0000 (19:56 +0000)]
[analyzer] Remove redundant check from DivZeroChecker
Analysis by Ted:
"
if (stateZero && !stateNotZero) {
is checking to see if:
(A) "it is possible for the value to be zero" (stateZero)
AND
(B) "it is not possible for the value to be non-zero" (!stateNotZero)
That said, the only way for both B to be true AND A to be false is if the path is completely infeasible by the time we reach the divide-by-zero check. For the most part (all cases?), such cases should automatically get pruned out at branches (i.e., an infeasible path gets dropped), which is the case in our tests. So the question is whether or not such an infeasible path might not get dropped earlier? I can't envision any right now.
Indeed, the rest of the checker assumes that if the bug condition didn't fire then 'stateNotZero' is non-NULL:
Douglas Gregor [Tue, 8 Nov 2011 19:45:38 +0000 (19:45 +0000)]
Mark the overloaded atomic builtins as having custom type checking,
which they do. This avoids all of the default argument promotions that
we (1) don't want, and (2) undo during that custom type checking, and
makes sure that we don't run into trouble during template
instantiation. Fixes PR11320.
Add a default system include of '/include'. This isn't particularly
useful when using Clang as a system-compiler, but its harmless. When
using Clang as a cross-compiler, this can be very handy as quite a few
toolchains ship their libc headers here rather than under
'/usr/include'.
For reference, this is the beginning of my work to also make the Clang
driver more suitable as a cross-compiler.
Bob Wilson [Tue, 8 Nov 2011 05:04:11 +0000 (05:04 +0000)]
Check pointer types for arguments of Neon load/store macros. rdar://9958031
The Neon load/store intrinsics need to be implemented as macros to avoid
hiding alignment attributes on the pointer arguments, and the macros can
only evaluate those pointer arguments once (in case they have side effects),
so it has been hard to get the right type checking for those pointers.
I tried various alternatives in the arm_neon.h header, but it's much more
straightforward to just check directly in Sema.
DeclPrinter: print the declaration's storage class specifier as
written, instead of the resolved storage class, which might not be
legal to specify on the declaration (such as out-of-line definitions
of static class members in C++, and __local variables in OpenCL).
Initial patch by Richard Membarth.
[arcmt] When we already removed a __weak, don't try to change it to __unsafe_unretained
later on, or we will end up with a redundant '__unsafe_unretained'.
Richard Smith [Tue, 8 Nov 2011 01:31:09 +0000 (01:31 +0000)]
Fix a cluster of related issues involving value-dependence and constant
expression evaluation:
- When folding a non-value-dependent expression, we may try to use the
initializer of a value-dependent variable. If that happens, give up.
- In C++98, actually check that a const, non-volatile DeclRefExpr inside an ICE
is of integral or enumeration type (a reference isn't OK!)
- In C++11, DeclRefExprs for objects of const literal type initialized with
value-dependent expressions are themselves value-dependent.
- So are references initialized with value-dependent expressions (though this
case is missing from the C++11 standard, along with many others).
Bob Wilson [Tue, 8 Nov 2011 01:16:11 +0000 (01:16 +0000)]
Clean up type flags for overloaded Neon builtins. No functional change.
This patch just adds a simple NeonTypeFlags class to replace the various
hardcoded constants that had been used until now. Unfortunately I couldn't
figure out a good way to avoid duplicating that class between clang and
TableGen, but since it's small and rarely changes, that's not so bad.
John McCall [Mon, 7 Nov 2011 22:49:50 +0000 (22:49 +0000)]
There are some crazy cases that LookupMethodInReceiverType
doesn't duplicate, but they all surface as implicit
properties. It's also a useful optimization to not
duplicate the implicit getter lookup. So, trust the
getter lookup that was already done in these cases.
Anna Zaks [Mon, 7 Nov 2011 22:38:10 +0000 (22:38 +0000)]
[analyzer] Make sure scan-build catches all clang failures.
scan-build ignores clang failures in some cases, which might lead to
silent failure suppression. For example, if clang command line
argument is wrong. (Addresses radar://10406598)
Richard Smith [Mon, 7 Nov 2011 22:16:17 +0000 (22:16 +0000)]
constexpr: static data members declared constexpr are required to have an
initializer; all other constexpr variables are merely required to be
initialized. In particular, a user-provided constexpr default constructor can be
used for such initialization.
Douglas Gregor [Mon, 7 Nov 2011 20:56:01 +0000 (20:56 +0000)]
When we notice that a member function is defined with "= delete" or "=
default", make a note of which is used when creating the
initial declaration. Previously, we would wait until later to handle
default/delete as a definition, but this is too late: when adding the
declaration, we already treated the declaration as "user-provided"
when in fact it was merely "user-declared".
Fixes PR10861 and PR10442, along with a bunch of FIXMEs.
-Move __strong/__weak added to a property type to the property attribute,
e.g. "@property (assign) __weak Foo *prop;" --> "@property (weak) Foo *prop;"
-Remove (assign) in a property so that it becomes strong-by-default in ARC.
Richard Trieu [Mon, 7 Nov 2011 18:40:31 +0000 (18:40 +0000)]
Add support for printing integer literals of type short, unsigned short,
__int128_t and __uint128_t. Short and unsigned short integer literals support
is only to work around a crasher as reported in PR11179 and will be removed
once Clang no longer builds short integer literals.
When applying ARC __weak to a non-objc pointer, do not give error that
__weak is unsupported by the deployment target, since it is going to be
ignored anyway.
Makes it easier for incremental migration from GC.
Douglas Gregor [Mon, 7 Nov 2011 17:43:18 +0000 (17:43 +0000)]
Drastically simplify the mapping from the declaration corresponding to
the injected-class-name of a class (or class template) to the
declaration that results from substituting the given template
arguments. Previously, we would actually perform a substitution into
the injected-class-name type and then retrieve the resulting
declaration. However, in certain, rare circumstances involving
deeply-nested member templates, we would get the wrong substitution
arguments.
This new approach just matches up the declaration with a declaration
that's part of the current context (or one of its parents), which will
either be an instantiation (during template instantiation) or the
declaration itself (during the definition of the template). This is
both more efficient (we're avoiding a substitution) and more correct
(we can't get the template arguments wrong in the member-template
case).
Rip out one of the features I added for the driver-include-management.
We don't actually need a separate flag for non-sysrooted paths as the
driver has to manage the sysroot anyways. The driver is not infrequently
adding paths to the header search based on their existence on the
filesystem. For that, it has to add the sysroot anyways, we should pass
it on down to CC1 already joined. More importantly, the driver cannot in
all cases distinguish between sysrooted paths and paths that are
relative to the Clang binary's installation directory. Essentially, we
always need to ignore the system root for these internal header search
options. It turns out in most of the places we were already providing
the system root in the driver, and then another one in CC1 so this fixes
several bugs.
David Blaikie [Mon, 7 Nov 2011 06:28:33 +0000 (06:28 +0000)]
Colorize. (this is consistent with the coloring in diagnostics.html, but perhaps that's a bit out of date because it doesn't look like current clang behavior)
Richard Smith [Mon, 7 Nov 2011 03:22:51 +0000 (03:22 +0000)]
Allow constexpr variables' initializers to be folded in C++11 mode. This
partially undoes the revert in r143491, but does not introduce any new instances
of the underlying issue (which is not yet fixed) in code which does not use
the 'constexpr' keyword.
Move the GCC installation detection logic down into the Generic_GCC
toolchain. The logic is mostly generic already, and where possible
should be made more generic. Also, it has no impact other than to expose
a set of methods which each toolchain can then query to setup their
desired configuration. These should be available to toolchains beyond
just Linux.
Remove the HasMultilib check. It was essentially useless. The driver now
looks for evidence of a multilib installation, and adds the appropriate
bits to the search paths.
Throw the switch and move all Linux header search over to the GCC
detection system that is providing the library paths and crt object
files.
This, modulo any bugs that need to be shaken out, resolves numerous bugs
with how we handle header paths. Here are a few that I know of:
- We no longer need to enumerate all GCC versions searched.
- OpenSUSE searched GCC versions in the wrong order.
- There were typos when selecting various patterns, etc.
- We aren't stating quite some many directories now.
- SysRoot didn't always work in a reasonable way.
I'm working on tests for this, but the tests are making me and Lit sad.
The real testing for this type of driver change is to try it out on
various distributions. I'll hit the common ones right away, and start
more thorough testing tomorrow after some sleep.
Lift the GCCVersion type into the header file and start persisting it in
the detected GCC installation. This allows us to expose another aspect
of what we detected: the GCC version. This will be used shortly.
John McCall [Sun, 6 Nov 2011 09:01:30 +0000 (09:01 +0000)]
Change the AST representation of operations on Objective-C
property references to use a new PseudoObjectExpr
expression which pairs a syntactic form of the expression
with a set of semantic expressions implementing it.
This should significantly reduce the complexity required
elsewhere in the compiler to deal with these kinds of
expressions (e.g. IR generation's special l-value kind,
the static analyzer's Message abstraction), at the lower
cost of specifically dealing with the odd AST structure
of these expressions. It should also greatly simplify
efforts to implement similar language features in the
future, most notably Managed C++'s properties and indexed
properties.
Most of the effort here is in dealing with the various
clients of the AST. I've gone ahead and simplified the
ObjC rewriter's use of properties; other clients, like
IR-gen and the static analyzer, have all the old
complexity *and* all the new complexity, at least
temporarily. Many thanks to Ted for writing and advising
on the necessary changes to the static analyzer.
I've xfailed a small diagnostics regression in the static
analyzer at Ted's request.
Take a better approach to detecting and selecting multiarch include
directories. This way we stop at the first multiarch directory found on
the system. This achieves the real intended result of pruning
non-existent directories.
Revert r143864, as the problem I was actually looking at can be solved
a better way. The more I think about it the more worried I am that this
hammer is simply too large. We should only be reaching out to the
filesystem when doing interesting "detection" things, not gratuitously.
Original commit message:
Start pruning down the set of flags passed to CC1 for header search.
This cleans up the CC1 invocations, and reduces the overhead there.
We're still hammering the filesystem looking for the C++ standard
libraries though.
The only reservation I have about this policy is the case of virtualized
files inside of CC1, but it's not clear what the best way to solve that
is. The Driver consistently queries the actual filesystem to make its
decisions. Changing that would be a very large undertaking. It might be
worthwhile, but it's not an immediate goal.
Start pruning down the set of flags passed to CC1 for header search.
This cleans up the CC1 invocations, and reduces the overhead there.
We're still hammering the filesystem looking for the C++ standard
libraries though.
The only reservation I have about this policy is the case of virtualized
files inside of CC1, but it's not clear what the best way to solve that
is. The Driver consistently queries the actual filesystem to make its
decisions. Changing that would be a very large undertaking. It might be
worthwhile, but it's not an immediate goal.
This test was assuming that /usr/include was in the system header search
path. That assumption should never have been true, but it was until
I fixed it. Now that its fixed, add a triple here to get correct
behavior even on Windows.
Switch Lit to directly query the driver for the builtin inclue path.
Thanks to Peter for pointing out how easy this is to do. I'm now much
happier with this solution.
Enhance the GCC version parsing and comparison logic to handle some more
edge cases and have better behavior. Specifically, we should actually
prefer the general '4.6' version string over the '4.6.1' string, as
'4.6.2' should be able to replace it without breaking rpaths or any
other place that these paths have been embedded. Debian-based
distributions are already using a path structure with symlinks to
achieve in-place upgrades for patch versions. Now our parsing reflects
this and we select the shorter paths instead of the longer paths.
A separate issue was that we would not parse a leading patch version
number even in the presence of a suffix. The above change makes this
more problematic as it would cause a suffix being added to make us treat
the entire thing as patch-version-agnostic, which it isn't. This changes
the logic to distinguish between '4.4.x' and 4.4.1-x', and retain that
the latter has *some* patch number information. Currently, we always
bias toward the shorter and more canonical version strings. If it
becomes important we can add more Debian like rules to produce sequences
such as '4.4.1b' > '4.4.1' > '4.4.1-rc3' > '4.4.1-rc2' > '4.4.1-pre5',
but I'm very doubtful this will ever matter or be desirable.
I've made the tests for this logic a bit more interesting, and added
some specific tests for logic that is now different.
Remove a pointless member. I have no idea why I made this not a local
variable to begin with... As I'm planning to add include root
information to this object, this would have caused confusion. It didn't
even *actually* hold the include root by the time we were done with it.
Move the GCC installation detection helper a member of the Linux
toolchain instead of merely using it in the constructor. This will allow
us to query it when building include paths as well as the file search
paths built in the constructor. I've lifted as little of it as I could
into the header file.
Eventually this will likely sink down into some of the Generic
toolchains and be used on more platforms, but I'm starting on Linux so
I can work out all the APIs needed there, where it is easiest to test
and we have the most pressing need.
Remove support for Gentoo subversion-ebuild installed llvm-gcc libstdc++
headers. As llvm-gcc is dead, and I have no idea if this ever really
worked, I think it's time for it to go. More importantly, it makes it
harder to generalize the include search logic. If someone really wants
these to work, they can set the CPLUS_INCLUDE_PATH environment variable.
Teach lit to ask the Clang it is running what version string to use
rather than presuming that it is 3.0. This is extra important as the
version should be 3.1, but CMake hasn't caught up with the times.
That'll be fixed in a separate commit.
Move the Linux header searching from the Frontend to the Driver. This is
the first (and diff-noisiest) step to making Linux header searching
tremendously more principled and less brittle. Note that this step
should have essentially no functional impact. We still search the exact
same set of paths in the exact same order. The only change here is where
the code implementing such a search lives.
This has one obvious negative impact -- we now pass a ludicrous number
of flags to the CC1 layer. That should go away as I re-base this logic
on the logic to detect a GCC installation. I want to do this in two
phases so the bots can tell me if this step alone breaks something, and
so that the diffs of the refactoring make more sense.
projects / clang / log