[cfe-dev] patch for Bug 1889

[Chris Goller]

This patch fixes a portion of case 1889 in Bugzilla.  This patch causes the
compiler to report an error when a constant array is declared with an
integer literal size that is too big.

I'm new to the code base, so, I'm not sure if I did everything correctly.
For example, what is the best way to get the number of bytes of each
allocated per element of an array?
Here is the way I'm doing it...
        unsigned SizeTypeBits =
static_cast<unsigned>(Context.getTypeSize(Context.getSizeType()));
        llvm::APSInt EltBytes(SizeTypeBits); EltBytes =
Context.getTypeSize(T) / Context.Target.getCharWidth();
If this is right, maybe it could be added to ArrayType?

Also, what is the max address of an array? I can't find anything in the c or
c++ standard about that. I ended up checking a few compilers, google, etc.
on this and it seems to be LONG_MAX.
Is this always the case meaning is it different on different targets?

If it is different based on the platform I think it needs to be in the
TargetInfo (i.e. llvm::APSInt TargetInfo::MaxStackAddress() const or
something).

Additionally, are there different rules about how large an array can be
allocated if it is static?

Sadly, this patch doesn't help with the specific problem for the case in
Bugzilla.  That case involved an expression that evaluated to larger than
maxlong, for example char BigArray[0x7fffffff + 1].
The expression is evaluated in bool Expr::isIntegerConstantExpr and that
function has a few FIXME comments:

/// FIXME: Pass up a reason why! Invalid operation in i-c-e, division by
zero,
/// comma, etc
///
/// FIXME: This should ext-warn on overflow during evaluation!  ISO C does
not
/// permit this.  This includes things like (int)1e1000
///
/// FIXME: Handle offsetof.  Two things to do:  Handle GCC's
__builtin_offsetof
/// to support gcc 4.0+  and handle the idiom GCC recognizes with a null
pointer
/// cast+dereference.

So, to patch this problem correctly, I'll need to know if overflow occurred
as opposed to simply an expression that ended up less than zero.  I'm going
to work on returning various
error codes from the isIntegerConstantExpr, but a change to that method will
affect a bunch of different areas, so, I'm sure I'll need some help!  Does
anyone have any ideas about how
to handle overflow during the evaluation of expressions?

Regards,

Chris

-- 
"Like a poet has to write poetry, I wake up in the morning and I have to
write a computer program." -- Knuth
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20081218/86bb2254/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bug1889.patch
Type: application/octet-stream
Size: 3888 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20081218/86bb2254/attachment.obj>