llvm dev - Mar 2016 - LLVM 3.8 apt repository for Debian

Yes, thought of UBSan. But in our case, the target program runs on 
baremetal. It has very tight code size restriction and it has no stderr.
Since LLVM already caught the behavior during compilation, it should 
notify users about it.

On 2016-03-16 18:29, Mehdi Amini wrote:
>> On Mar 16, 2016, at 6:16 PM, Zhao, Weiming via llvm-dev 
>> <llvm-dev at lists.llvm.org> wrote:
>> 
>> Hi,
>> 
>> There are cases where LLVM is able to detect some UB but clang is not.
>> 
>> For example,
>> 
>> unsigned int foo(unsigned int x) {
>> 
>>  int ret = 0;
>>  for(int i = 0; i <= 32; ++i)
>>    ret += x >> i;
>>  return ret;
>> 
>> }
>> 
>> When the loop is unrolled, LLVM InstructionSimplify will catch it and
>> return a UNDEF value.
>> How can we let LLVM report some warning message to help developers
>> correct the error?
>> Or should we use similar behavior as GCC (e.g. x >> 32 returns
0)?
>> 
>> This can also saves compiler engineer's effort: users complain that
>> it's
>> a compiler bug because their code works with GCC or older version of
>> LLVM (because the loop is not unrolled). And it's really hard to
debug
>> such UB in some large code base.
> 
> Isn't it catched by UBSAN?
> 
> --
> Mehdi
> 
> 
>> 
>> Thanks,
>> Weiming
>> 
>> --
>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
>> hosted by The Linux Foundation
>> 
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

On 16 March 2016 at 21:42, via llvm-dev <llvm-dev at lists.llvm.org>
wrote:
> Yes, thought of UBSan. But in our case, the target program runs on
> baremetal. It has very tight code size restriction and it has no stderr.
> Since LLVM already caught the behavior during compilation, it should notify
> users about it.
It's not that simple.

First, without debug info all LLVM could realistically say is "there
might be undefined behaviour somewhere in this program". Even with
debug info, that location may or may not be accurate.

Second, there could be legitimate cases for an shl 32 to exist in a
program. As long as it's not actually executed it's fine. The usual
example is a template instantiation: they fairly often have generic
code that would be UB in some cases, but is guarded by checks to never
execute at runtime. There's no realistic way for LLVM to determine
this locally.

Third, we don't want the diagnostics Clang produces to depend on
optimization level.

If you want this kind of diagnostic at compile-time, it's probably a
job for the static analyzer. It doesn't currently catch this case
though, and I don't know enough about its inner workings to say how
feasible that would be.

Cheers.

Tim.

What the title says, so far it was uploaded for Debian Jessie but not
for Debian unstable (which probably works for testing too).

I was looking at: http://llvm.org/apt/ (which says that it has not been
updated since Feb but still).

Is this still maintained or do you recommend any other source for
getting Debian packages?

Thanks,
C

> On Mar 16, 2016, at 10:08 PM, Tim Northover <t.p.northover at
gmail.com> wrote:
> 
> On 16 March 2016 at 21:42, via llvm-dev <llvm-dev at lists.llvm.org>
wrote:
>> Yes, thought of UBSan. But in our case, the target program runs on
>> baremetal. It has very tight code size restriction and it has no
stderr.
>> Since LLVM already caught the behavior during compilation, it should
notify
>> users about it.
> 
> It's not that simple.
> 
> First, without debug info all LLVM could realistically say is "there
> might be undefined behaviour somewhere in this program". Even with
> debug info, that location may or may not be accurate.
> 
> Second, there could be legitimate cases for an shl 32 to exist in a
> program. As long as it's not actually executed it's fine. The usual
> example is a template instantiation: they fairly often have generic
> code that would be UB in some cases, but is guarded by checks to never
> execute at runtime. There's no realistic way for LLVM to determine
> this locally.
> 
> Third, we don't want the diagnostics Clang produces to depend on
> optimization level.
> 
> If you want this kind of diagnostic at compile-time, it's probably a
> job for the static analyzer. It doesn't currently catch this case
> though, and I don't know enough about its inner workings to say how
> feasible that would be.
I'll add that there is a great reading on the llvm blog on this topic:
http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html

Best,

-- 
Mehdi