Zhongxing Xu [Wed, 6 May 2009 11:51:48 +0000 (11:51 +0000)]
Improve RegionStoreManager::getSizeInElements()
- add a static function getTypeWidth(), which computes the width of a type
with the help of TargetInfo.
- no-outofbounds.c now passes for region store.
Chris Lattner [Wed, 6 May 2009 04:33:31 +0000 (04:33 +0000)]
Fix rdar://6860124 - invalid input constraint 'J' in asm
This recognizes all the target-independent constant constraints
that have target-specific meanings.
Daniel Dunbar [Wed, 6 May 2009 03:16:41 +0000 (03:16 +0000)]
Improve handling of (X86) target features.
- This is a WIP...
- This adds -march= handling to the driver, and fixes the defaulting
of -mcpu on Darwin (which was using the wrong test).
Instead of handling -m{sse, ...} in the driver, pass them to clang-cc as
-target-feature [+-]name
In clang-cc, communicate with the (clang) target to discover the legal
features of a target, and the features which are enabled based on
-mcpu. This is currently hardcoded just enough to not be a feature
regression, we need to get this information from the backend's
TableGen information somehow.
This is used to construct the full list of features which are being
used, which is in turn used to initialize the predefines.
Daniel Dunbar [Wed, 6 May 2009 02:12:32 +0000 (02:12 +0000)]
Add --analyze-auto.
- Currently just an alias for --analyze, eventually we want to refit
--analyze so that it is less automatic (i.e., does not force plist
output and does not hard code the list of checks).
Ted Kremenek [Tue, 5 May 2009 22:19:17 +0000 (22:19 +0000)]
BugReporter (extensive diagnostics): Fix getEnclosingStmtLocation to reason
about Exprs that are not consumed and fix where the loop iteration diagnostic
goes.
The "instantiated from" messages coming from the caret diagnostics system are
basically walking the macro expansion tree, emitting each level as it goes. However, it was
skipping certain leaves in the tree by skipping up the entire instantiation arm every time
it went up one spelling arm. This caused it to miss some things. For example, in this
testcase:
#define M1(x) x
#define M2 1;
void foo() {
M1(M2)
}
we now print:
/Users/sabre/Desktop/clang-unused-value-macro.c:6:2: warning: expression result unused
Previously we didn't print the last line, so we never emitted the caret pointing to the 1!
Incidentally, the spaces between the lines is really noisy, I think we should reconsider
this heuristic (which adds them when the printed code starts too close to the start of the
line).
The regression test can't use -verify, because -verify doesn't catch notes for macro
instantiation history.
Chris Lattner [Tue, 5 May 2009 17:48:42 +0000 (17:48 +0000)]
remove some incorrect and unimplemented atomic builtins (e.g.
__sync_umin_and_fetch), add some missing atomic builtins (e.g.
__sync_fetch_and_nand) and reorder the list to match the GCC
documentation. The builtins still need work and codegen
implementation, more patches coming.
Chris Lattner [Tue, 5 May 2009 06:16:31 +0000 (06:16 +0000)]
When defining a function whose type has no prototype, make an effort
to go back and clean up existing uses of the bitcasted function. This
is not just an optimization: it is required for correctness to get
always inline functions to work, see testcases in function-attributes.c.
Chris Lattner [Tue, 5 May 2009 05:16:17 +0000 (05:16 +0000)]
fix some more cases where we'd emit a file with a line of 0 for implicit
types. In this case, it was objc_selector and objc_class. This fixes
rdar://6852754 - clang sometimes generates incorrect/unknown file/line info for DW_TAG__structure_type dies
Chris Lattner [Tue, 5 May 2009 05:05:36 +0000 (05:05 +0000)]
Do not generate bogus location info for DW_TAG_inheritance
DIEs. We were generating a loc with line of 0 and a file.
These tags do not need locations at all, just remove it.
this fixes rdar://6852792 - Clang generates incorrect (and unnecessary) file and line info for DW_TAG_inheritance dies
Chris Lattner [Tue, 5 May 2009 04:57:08 +0000 (04:57 +0000)]
Fix generated debug info for decls with no location (which include self/_cmd
in ObjC) to not emit file/line location information. Previously
we would output a file with bogus line information. This fixes:
rdar://6852814 - Clang generates incorrect file & line info for automatic/understood formal parameters for objc-programs
Douglas Gregor [Tue, 5 May 2009 04:50:50 +0000 (04:50 +0000)]
Turns out that Sebastian already implemented the logic to compute the
composite pointer type, and his is better! Updated relational- and
equality-operator checking accordingly.
Daniel Dunbar [Mon, 4 May 2009 23:23:09 +0000 (23:23 +0000)]
Fix the field count in interface record layout (it was incorrectly
compensating for super classes). This was making the reported class
sizes for empty classes very, very wrong.
- Also, we now report the size info for an empty class like gcc (as
the offset of the start, not as 0, 0).
- Add a few more test cases we were mishandling before (padding bit
field at end of struct, for example).
Chris Lattner [Mon, 4 May 2009 18:27:04 +0000 (18:27 +0000)]
"Fix" a problem with debug info in the presence of always_inline
function calls. For a program like this:
#include <stdio.h>
static __inline__ __attribute__((always_inline))
int bar(int x) { return 4; }
int main() {
int X = bar(4);
printf("%d\n", X);
}
clang was not outputing any debug info for the body of main(). This is
because the backend is getting confused by the region_start/end that clang
is emitting for block scopes. For now, just disable these (matching llvm-gcc),
this stuff is in progress of rework anyway.
Ted Kremenek [Mon, 4 May 2009 17:53:11 +0000 (17:53 +0000)]
Fix false positive null dereference by unifying code paths in GRSimpleVals for
'==' and '!=' (some code in the '!=' was not replicated in the '==' code,
causing some constraints to get lost).
Motivation: Core Foundation objects can be used in isolation from Objective-C,
and this forces users to reason about the separate semantics of CF objects. More
Sema support pending.
Ted Kremenek [Mon, 4 May 2009 17:04:30 +0000 (17:04 +0000)]
Remove support for ObjCMethodDecl attributes that appear between the
return type and the selector. This is inconsistent with C functions
(where such attributes would be placed on the return type, not the the
FunctionDecl), and is inconsistent with what people are use to seeing.
Chris Lattner [Mon, 4 May 2009 16:56:33 +0000 (16:56 +0000)]
"The attached diff fixes the //FIXME in message send to super. This should now be faster, and works in the presence of class posing. This is now the same approach as used in GCC (the earlier code was a quick hack to get something working)."
Daniel Dunbar [Mon, 4 May 2009 15:31:17 +0000 (15:31 +0000)]
Patch from David Chisnall:
The attached diff fixes the //FIXME in message send to super. This
should now be faster, and works in the presence of class posing. This
is now the same approach as used in GCC (the earlier code was a quick
hack to get something working).
Ted Kremenek [Mon, 4 May 2009 14:31:19 +0000 (14:31 +0000)]
Rename no-outofbounds.c to xfail-no-outofbounds.c and split off that
test into a separate file to monitor the fact that BasicStoreManager
passes the test.
Zhongxing Xu [Mon, 4 May 2009 08:52:47 +0000 (08:52 +0000)]
array indexes are unsigned integers of the same width as pointer.
no-outofbounds.c still fails. Previously it passed because the array index
is mistakenly a loc::ConcreteInt.
Douglas Gregor [Mon, 4 May 2009 06:45:38 +0000 (06:45 +0000)]
Simplify the interesting-region code by assimmilating blocks of non-whitespace text with each expansion step. It's easier and seems to have better results.
Ted Kremenek [Mon, 4 May 2009 06:35:49 +0000 (06:35 +0000)]
Handle 'long x = 0; char *y = (char *) x;' by layering an
'ElementRegion' on top of the VarRegion for 'x'. This causes the test
case xfail_wine_crash.c to now pass for BasicStoreManager. It doesn't
crash for RegionStoreManager either, but reports a bogus unintialized
value warning.
Douglas Gregor [Mon, 4 May 2009 06:27:32 +0000 (06:27 +0000)]
Tweak the extraction of the "interesting" part of a source range in two ways:
1) First of all, we treat _ as part of an identifier and not as
punctuation (oops).
2) Second of all, always make sure that the token that the ^ is
pointing at is fully within the "interesting" part of the range.
Ted Kremenek [Mon, 4 May 2009 06:18:28 +0000 (06:18 +0000)]
Per conversations with Zhongxing, add an 'element type' to
ElementRegion. I also removed 'ElementRegion::getArrayRegion',
although we may need to add this back.
This breaks a few test cases with RegionStore:
- 'array-struct.c' triggers an infinite recursion in RegionStoreManager. Need to investigate.
- misc-ps.m triggers a failure with RegionStoreManager as we now get the diagnostic:
'Line 159: Uninitialized or undefined return value returned to caller.'
There were a bunch of places that needed to be edit
RegionStoreManager, and we may not be passing all the correct 'element
types' down from GRExprEngine.
Zhongxing: When you get a chance, could you review this? I could have
easily screwed up something basic in RegionStoreManager.
Douglas Gregor [Mon, 4 May 2009 06:07:12 +0000 (06:07 +0000)]
Implement support for comparing pointers with <, >, <=, >=, ==, and !=
in C++, taking into account conversions to the "composite pointer
type" so that we can compare, e.g., a pointer to a derived class to a
pointer to a base class.
Also, upgrade the "comparing distinct pointer types" from a warning to
an error for C++, since this is clearly an error. Turns out that we
hadn't gone through and audited this code for C++, ever.
Daniel Dunbar [Mon, 4 May 2009 05:16:21 +0000 (05:16 +0000)]
Add -fobjc-tight-layout.
- This implements gcc style Objective-C interface layout (I
think). Currently it is always off, there is no functionality
change unless this is passed.
For the curious, the deal is that gcc lays out the fields of a
subclass as if they were part of the superclass. That is, the
subclass fields immediately follow the super class fields instead
of being padded to the alignment of the superclass structure.
- Currently gcc uses the tight layout in 32-bit and 64-bit modes, and
llvm-gcc uses it in 32-bit only, for reasons which aren't clear
yet. We probably want to switch to matching gcc, once this makes it
through testing... my hope is that we can also fix llvm-gcc in
order to maintain compatibility between the compilers.
Ted Kremenek [Mon, 4 May 2009 04:57:00 +0000 (04:57 +0000)]
retain checker: RetainSummaryManager now has a 'DefaultSummary' object
which is returned instead of a null pointer. This helps centralize
the logic concerning "default effects".
Ted Kremenek [Mon, 4 May 2009 04:30:18 +0000 (04:30 +0000)]
retain checker: Don't bother using a FoldingSet to unique summaries.
We never compare summaries by their pointers, and we create only a
handful of them when analyzing a given function.
Daniel Dunbar [Mon, 4 May 2009 04:10:48 +0000 (04:10 +0000)]
Don't allow clients to traverse into superclass synthesized properties
via CollectObjCIvars.
- In places where we need them, we should have the implementation and
access the properties through it.
This is a fairly substantial functionality change:
1. @encode no longer encodes synthesized ivars, ever.
2. The ivar layout bitmap no longer encodes information for
synthesized ivars in superclasses. Well, actually I had already
broken that, but it is intentional now.
We are now differing substantially from llvm-gcc and gcc
here. However, in my opinion this fundamentally *must* work if
non-fragile classes are to work. Without this change, the result of
@encode and the ivar layout depend on the order that the
implementation is seen in a file (if it is in the same file with its
superclass). Since both scenarios should work the same, our behavior
is now consistent with gcc behavior as if an implementation is never
seen following an implementation of its superclass.
Note that #2 is only a functionality change when (A) an
implementation appears in the same translation unit with the
implementation of its superclass, and (B) the superclass has
synthesized ivars. My belief is that this situation does not occur in
practice.
I am not yet sure of the role/semantics of @encode when synthesized
ivars are present... it's use is fairly unsound in a non-fragile world.
projects / clang / log