[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gcc-patches
Subject:    Re: [C PATCH] Simple compile-time array bounds checking
From:       "Roger Sayle" <roger () eyesopen ! com>
Date:       2007-01-13 15:48:23
Message-ID: 15826.68.35.10.103.1168703303.squirrel () mail ! eyesopen ! com
[Download RAW message or body]


Hi Dirk,

On Sat, January 13, 2007 5:53 am, Dirk Mueller wrote:
> On Saturday, 13. January 2007 06:36, Roger Sayle wrote:
>> My apologies if this is a frequently contributed patch

Ah, it appears that it is.

> Would you mind commenting on why you think the patch I posted is a bad
> idea or would you mind if I go ahead and commit it after a regtest (just
> started it again, might complete before monday)?

Sorry I was unaware of your previous submission and Richard G's approval.
Please go ahead and commit your version.  My motivation is purely to get
GCC to warn about the dangerous bug in my colleague's code.  The how,
where and who are not important.  I'm perhaps as surprised that this
hasn't been implemented in a 20 year old C compiler (especially one that
intended to obviate a GNU lint), as I am that a appropriate patch has been
submitted, approved and waiting to be committed!

So your patch isn't a "bad idea".  One comment I would like to make is
that it's normally frowned upon for the middle-end to generate diagnostic
warnings which it at all possible should be generated by the front-ends
prior to or during gimplification.  However, for many warnings this just
isn't possible.

One extension of your approach may be also add/re-use your code during
gimplification or the front-ends.  Many of cases you're trying to catch,
including the f() examples listed in PR 8268, don't require VRP to
propagate constants into array indices, and hence can be emitted even with
-O1 or -O0, and perhaps even -fsyntax-only.  You can use the
TREE_NO_WARNING machinery to then avoid generating errors for the same
references again during VRP.  One possible beneficial side-effect of this
is that you won't repeat the error messages caused by inlining a bad array
reference.  This soemwhat tames the middle-end generating warnings aspect,
such that we only generate late warnings for cases that are discovered by
optimization/propagation.

So I hereby withdraw my contribution.  Thanks for addressing this issue.

Roger
--


[prev in list] [next in list] [prev in thread] [next in thread]