[LLVMdev] LTO "bug" and Clang warnings

David Blaikie dblaikie at gmail.com
Tue Jan 8 10:41:51 PST 2013

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

More information about the llvm-dev mailing list