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. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130108/85eec297/attachment.html>
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>
On Tue, Jan 8, 2013 at 10:29 AM, 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.Hmm, OK - just in case this is a useful observation to make: What the compiler does with undefined behavior (let's, for the sake of discussion, assume that this is undefined and that the compiler knows this (the former seems likely, though Duncan seems to indicate that the latter might not actually bet the case)) is not "fix" it. The compiler simply assumes that UB can never happen. It's not deliberately trying to fix the code - it's just optimizing the code based on the semantic model/guarantees it has. One of those guarantees (again, hypothetically) is that writes to 'foo' cannot write to 'bar' - so if 'foo' is never accessed, simply optimize away writes to 'foo' to save time. This isn't intended to "fix" anything - simply to make faster code.> If it's undefined, than LTO is completely > right and nothing should be done. > > 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
On 8 January 2013 18:41, David Blaikie <dblaikie at gmail.com> wrote:> This isn't intended to "fix" anything - simply to make faster code. >I agree, and take back the wrong wording. I didn't mean it as an intentional fix. cheers, --renato -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130108/61dcd0e3/attachment.html>
On 8 January 2013 18:40, Matthieu Monrocq <matthieu.monrocq at gmail.com>wrote:> I do believe it's undefined. > > §5.2.1 Subscripting [expr.sub] > ... > §5.7 Additive operators [expr.add] > ... >Still, doesn't explicitly say it's undefined. I agree this gives the freedom of implementers to extend naturally, but it's at least arguable. I have the 2011 draft and couldn't find anything, nor in the current open issues. 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). >Is the static analyser in clang-extra-tools? cheers, --renato -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130108/ecd34b66/attachment.html>