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.
Daniel Dunbar [Sun, 3 May 2009 23:04:40 +0000 (23:04 +0000)]
Fix an infinite loop in diagnostic printing.
- The diagnostic is still poor, however. Doug, can you investigate?
- Improved the test case to not depend on the file name, now it can
be extended to actually check the formatting of the diagnostics
(I'm hoping grep -A is portable here).
Douglas Gregor [Sun, 3 May 2009 15:24:25 +0000 (15:24 +0000)]
Fix crash in source-line truncation code for diagnostic
printing. Also, when we only need to truncate the line at the end,
make sure there is room for the ellipsis.
Daniel Dunbar [Sun, 3 May 2009 13:15:50 +0000 (13:15 +0000)]
Use ASTRecordLayout for computing ivar offsets instead of shadow
struct.
- We still need to do more lookup than necessary because ivars don't
live in a reasonable DeclContext.
- The only remaining client of the interface shadow struct is the
ivar layout bitmap.
Daniel Dunbar [Sun, 3 May 2009 12:57:56 +0000 (12:57 +0000)]
Add a ComputeIvarBaseOffset overload taking an implementation
decl. Only this routine will be suitable for computing the offset of a
synthesized ivar.
- No functionality change.
Daniel Dunbar [Sun, 3 May 2009 11:16:44 +0000 (11:16 +0000)]
Implement the interface/implementation layout distinction.
- These routines should now be independent of the Sema state.
- This is nearly zero functionality change, the distinction only
matters in the non-fragile ABI, and the consumers that care about
this distinction should be using getASTObjCImplementationLayout.
Daniel Dunbar [Sun, 3 May 2009 10:38:35 +0000 (10:38 +0000)]
Split out getASTObjCImplementationLayout
- The difference from getASTObjCInterfaceLayout is that the computes
the layout including synthesized ivars.
- No functionality change, they currently both compute the same thing
-- whether that includes synthesized ivars or not depends on when
they get called!!!
Daniel Dunbar [Sun, 3 May 2009 10:04:17 +0000 (10:04 +0000)]
PR4063, with feeling: Chain PP callbacks by default.
- This is somewhat cleaner and also fixes PR4063 for real, I had the
order wrong so we were just creating an empty dependency file.
Chris Lattner [Sun, 3 May 2009 07:53:25 +0000 (07:53 +0000)]
implement support for asm outputs targetting non-simple lvalue destinations
like bitfields. incidentally llvm-gcc crashes on this sort of thing also. :)
Chris Lattner [Sun, 3 May 2009 07:04:21 +0000 (07:04 +0000)]
If we have mismatched integer tied operands, but the operand
number is not mentioned in the asm string, let it past sema.
Right now these are currently rejected by the llvm code generator
but this will be fixed next.
Chris Lattner [Sun, 3 May 2009 06:50:40 +0000 (06:50 +0000)]
avoid a crash when we encounter a implicit cast of the paren expr due to
promotions. This should be fixed by not modeling asm operands (which
require the ()'s according to the grammar) as not being paren exprs.
Eli Friedman [Sun, 3 May 2009 04:46:36 +0000 (04:46 +0000)]
Add Sema support for __builtin_setjmp/__builtin_longjmp. The primary
reason for adding these is to error out in CodeGen when trying to generate
them instead of silently emitting a call to a non-existent function.
(Note that it is not valid to lower these to setjmp/longjmp; in addition
to that lowering being different from the intent, setjmp and longjmp
require a larger buffer.)
Daniel Dunbar [Sat, 2 May 2009 22:09:19 +0000 (22:09 +0000)]
Driver: Treat -m32 and -m64 as "driver-only" arguments.
- In particular, don't forward them to gcc; these participate in the
selection of the tool chain, which should know how to talk to gcc
and be fixed if it doesn't.
Chris Lattner [Sat, 2 May 2009 19:34:21 +0000 (19:34 +0000)]
when creating custom warning diagnostics, do not attempt to map
them with -Werror. Custom diags cannot be mapped, and this makes
-Werror cause a determinstic crash for the checker and other
clients of the custom diagnostics machinery. rdar://6816191
projects / clang / log