[LLVMdev] [cfe-dev] LTO "bug" and Clang warnings

[Matthieu Monrocq]

On Tue, Jan 8, 2013 at 7:29 PM, Renato Golin <renato.golin at linaro.org>wrote:

> On 8 January 2013 16:53, David Blaikie <dblaikie at gmail.com> wrote:
>
>> I'm not sure what you mean by "fix user's stupidity" here - could you
>> clarify?
>>
>
> Buffer overrun on foo[20] and relying on it for bar[20].
>
> It might not even be an error to access foo[50] even though foo only has
> 20 elements (via pointer indirection rules), but it's user error to do so,
> and if the standard allows that (I'm yet to find the paragraph), then the
> compiler has no right to "fix" it. If it's undefined, than LTO is
> completely right and nothing should be done.
>
>
I do believe it's undefined.

§5.2.1 Subscripting [expr.sub]

1/ A postfix expression followed by an expression in square brackets is a
postfix expression. One of the expressions
shall have the type “pointer to T” and the other shall have unscoped
enumeration or integral type.
The result is an lvalue of type “T.” The type “T” shall be a
completely-defined object type.62 The expression
E1[E2] is identical (by definition) to *((E1)+(E2))


§5.7 Additive operators [expr.add]

5/ When an expression that has integral type is added to or subtracted from
a pointer, the result has the type
of the pointer operand. If the pointer operand points to an element of an
array object, ***and the array is
large enough***, the result points to an element offset from the original
element such that the difference of
the subscripts of the resulting and original array elements equals the
integral expression. [...]


There is later (in §8.3.4 Arrays) a special case access out of bounds
within a multi-dimensional array; however that is not our concern here.


Obviously, a warning, if possible, could be nice; but in general I am
afraid this is more the domain of static analysis as it requires "guessing"
the bounds of the loop. It might have been caught with ubsan though (I
think there is an out-of-bounds checker).

-- Matthieu

The "stupidity" part is to rely on undefined behaviour. Mind you, the
> stupidity in this case was mine. I removed functions from Livermore that I
> though were harmless, and added a few arrays to be initialized by others
> and haven't checked that the ranges were dynamic.
>
> cheers,
> --renato
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130108/a6d70397/attachment.html>