John Regehr writes:
>> I would only be worried for cases where no warning is issued *and*
>> unitialized accesses are eliminated.
>
> Yeah, it would be excellent if GCC maintained the invariant that for all
> uses of uninitialized storage, either the compiler or else valgrind will
> issue a warni
Also, we're not running LTO in any compiler and we removed all "static"
declarations from the code to keep compilers from making closed-world
assumptions.
John Regehr
> I am not a valgrind expert so, take the following with a grain of salt
> but I think that the above statement is wrong: valgrind reliably detects
> use of uninitialized variables if you define 'use' as meaning 'affects
> control flow of your program' in valgrind.
It works in some cases for the s
On Tue, 2009-12-15 at 11:24 +0100, Andi Kleen wrote:
> John Regehr writes:
>
> >> I would only be worried for cases where no warning is issued *and*
> >> unitialized accesses are eliminated.
> >
> > Yeah, it would be excellent if GCC maintained the invariant that for
> > all uses of uninitialized
John Regehr writes:
>> I would only be worried for cases where no warning is issued *and*
>> unitialized accesses are eliminated.
>
> Yeah, it would be excellent if GCC maintained the invariant that for
> all uses of uninitialized storage, either the compiler or else
> valgrind will issue a warni
I also wonder if you have something like LTO enabled.
No, he doesn't enable LLVM LTO. Even if it did, LTO wouldn't touch
the 'CC1000SendReceiveP*' definitions because they are not static
(unless he explicitly built with an export map).
Interesting.
I haven't analyzed what is going on in t
On Dec 15, 2009, at 12:28 AM, Paolo Bonzini wrote:
> On 12/14/2009 09:31 PM, John Regehr wrote:
>> Ok, thanks for the feedback Andi. Incidentally, the LLVM folks seem to
>> agree with both of your suggestions. I'll re-run everything w/o frame
>> pointers and ignoring testcases where some compile
On 12/14/2009 09:31 PM, John Regehr wrote:
Ok, thanks for the feedback Andi. Incidentally, the LLVM folks seem to
agree with both of your suggestions. I'll re-run everything w/o frame
pointers and ignoring testcases where some compiler warns about use of
uninitialized local. I hate the way these
John Regehr wrote:
I would only be worried for cases where no warning is issued *and*
unitialized accesses are eliminated.
Yeah, it would be excellent if GCC maintained the invariant that for all
uses of uninitialized storage, either the compiler or else valgrind will
issue a warning.
I fin
John Regehr wrote:
Optimizations based on uninitialized variables make me very nervous.
If uninitialized memory reads are transformed into don't-cares, then
checking tools like valgrind will no longer see the UMR (assuming that
the lack of initialization is a bug).
Well that's the way things ar
John Regehr wrote:
I wonder if the original program was already broken or was this
something your conversion introduced?
Not sure about this specific case but I'm sure there's some of each.
I also noticed these testcases but decided to leave them in for now.
Obviously the code is useless, but
I would only be worried for cases where no warning is issued *and*
unitialized accesses are eliminated.
Yeah, it would be excellent if GCC maintained the invariant that for all
uses of uninitialized storage, either the compiler or else valgrind will
issue a warning.
We could test for violati
On Mon, Dec 14, 2009 at 01:53:30PM -0800, John Regehr wrote:
> > Optimizations based on uninitialized variables make me very nervous.
> > If uninitialized memory reads are transformed into don't-cares, then
> > checking tools like valgrind will no longer see the UMR (assuming that
> > the lack of i
Optimizations based on uninitialized variables make me very nervous.
If uninitialized memory reads are transformed into don't-cares, then
checking tools like valgrind will no longer see the UMR (assuming that
the lack of initialization is a bug).
Did I understand that icc does this? It seems lik
On Mon, Dec 14, 2009 at 12:36:00PM -0800, John Regehr wrote:
> My opinion is that code containing undefined behaviors is definitely
> interesting, but probably it is interesting in a different way than
> functions that are more meaningful.
Optimizations based on uninitialized variables make me v
My opinion is that code containing undefined behaviors is definitely
interesting, but probably it is interesting in a different way than
functions that are more meaningful.
If I have time I'll just separate out the testcases into two groups: one
containing functions that are more or less sensi
Ok, thanks for the feedback Andi. Incidentally, the LLVM folks seem to
agree with both of your suggestions. I'll re-run everything w/o frame
pointers and ignoring testcases where some compiler warns about use of
uninitialized local. I hate the way these warnings are not totally
reliable, but
On Mon, Dec 14, 2009 at 5:30 PM, John Regehr wrote:
>> I wonder if the original program was already broken or was this
>> something your conversion introduced?
>
> Not sure about this specific case but I'm sure there's some of each.
>
> I also noticed these testcases but decided to leave them in f
On Mon, Dec 14, 2009 at 06:17:45PM +0100, Andi Kleen wrote:
> I personally feel that test cases that get optimized away are not
> very interesting.
Actually, I think they're very interesting - especially if they are
valid code, and one compiler optimizes them away, but the other
doesn't. You may
On Mon, Dec 14, 2009 at 09:30:57AM -0700, John Regehr wrote:
> I also noticed these testcases but decided to leave them in for now.
> Obviously the code is useless, but it can still be interpreted according to
> the C standard, and code can be generated. Once you start going down the
> road of
I wonder if the original program was already broken or was this
something your conversion introduced?
Not sure about this specific case but I'm sure there's some of each.
I also noticed these testcases but decided to leave them in for now.
Obviously the code is useless, but it can still be int
John Regehr writes:
> See here:
>
> http://embed.cs.utah.edu/embarrassing/
>
> There is a lot of data there. Please excuse bugs and other
> problems. Feedback would be appreciated.
>
I was a bit surprised by the icc results, because traditionally icc doesn't
have a good reputation for good co
22 matches
Mail list logo
