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
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 compiler
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
John Regehr reg...@cs.utah.edu 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
On Tue, 2009-12-15 at 11:24 +0100, Andi Kleen wrote:
John Regehr reg...@cs.utah.edu 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
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
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
John Regehr reg...@cs.utah.edu 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
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.
John Regehr
John Regehr reg...@cs.utah.edu 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
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
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 5:30 PM, John Regehr reg...@cs.utah.edu 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
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,
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
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
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 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
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,
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
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
21 matches
Mail list logo
