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

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>

On Tue, Jan 8, 2013 at 11:11 AM, Renato Golin <renato.golin at linaro.org>
wrote:
> 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.
That's the fun of it - all the things that aren't defined are
undefined. (but, yes, some things are more explicitly undefined than
others)
> 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?
No, it's built into clang itself, actually. clang -analysis or
somesuch, I've not run it myself, actually.
http://clang-analyzer.llvm.org/ should have some details.

On 8 January 2013 19:15, David Blaikie <dblaikie at gmail.com> wrote:
> That's the fun of it - all the things that aren't defined are
> undefined. (but, yes, some things are more explicitly undefined than
> others)
>
This is Java is much better, there's no standard, just Oracle's
implementation! :D


No, it's built into clang itself, actually. clang -analysis
or
> somesuch, I've not run it myself, actually.
> http://clang-analyzer.llvm.org/ should have some details.
>
Not much comes out of it when I pass it over lto-test.c:

<plist version="1.0">
<dict>
 <key>clang_version</key>
<string>clang version 3.3 </string>
 <key>files</key>
 <array>
 </array>
 <key>diagnostics</key>
 <array>
 </array>
</dict>

cheers,
--renato
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130108/d6c779ab/attachment.html>

On 1/8/2013 1:11 PM, Renato Golin wrote:
  >
> 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.
It does, actually:

C++ 2003 [5.7.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. In 
other words, if the expression P points to the i-th element of an array 
object, the expressions (P)+N (equivalently, N+(P)) and (P)-N (where N 
has the value n) point to, respectively, the i+n-th and i–n-th elements 
of the array object, provided they exist. Moreover, if the expression P 
points to the last element of an array object, the expression (P)+1 
points one past the last element of the array object, and if the 
expression Q points one past the last element of an array object, the 
expression (Q)-1 points to the last element of the array object. If both 
the pointer operand and the result point to elements of the same array 
object, or one past the last element of the array object, the evaluation 
shall not produce an overflow; otherwise, the behavior is undefined.

-Krzysztof


-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
hosted by The Linux Foundation

On 8 January 2013 19:38, Krzysztof Parzyszek <kparzysz at
codeaurora.org>wrote:
> It does, actually:
>
> C++ 2003 [5.7.5]
>
Just found on the C standard, too: 6.5.6-8.

I need to get used reading those standards again...

cheers,
--renato
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130108/2eb747e4/attachment.html>