:> cc -Wall x.c -c -O2
:> x.c: In function 'fubar2':
:> x.c:16: warning: 'error' is used uninitialized in this function
:>
:> (edit so *valuep is set to 0)
:>
:> cc -Wall x.c -c -O2
:> (no warning reported)
:
:So you need to go -O2? -O alone doesn't work? Maybe we shoul
On Wed, Jul 16, 2008 at 12:35:38AM +0100, Simon 'corecode' Schubert wrote:
> Matthew Dillon wrote:
>>One interesting thing I've found on GCC-4 is that the callgraph
>> analyzer
>>will cross procedure boundaries for all procedures in that particular
>>source file. It can actually detec
Matthew Dillon wrote:
One interesting thing I've found on GCC-4 is that the callgraph analyzer
will cross procedure boundaries for all procedures in that particular
source file. It can actually detect that error is left uninitialized
in this situation:
cc -Wall x.c -c -O2
x.
On Tue, Jul 15, 2008 at 10:43:29PM +0200, Joerg Sonnenberger wrote:
> On Tue, Jul 15, 2008 at 03:22:34PM -0500, Vincent Stemen wrote:
> > Compiling with "gcc -o query -g -Wall main.c" produced no warnings at
> > all. But when I added #include "query.c" to the main code module after
> > it was work
On Tue, Jul 15, 2008 at 02:40:42PM -0700, Matthew Dillon wrote:
>One interesting thing I've found on GCC-4 is that the callgraph analyzer
>will cross procedure boundaries for all procedures in that particular
>source file. It can actually detect that error is left uninitialized
>in
:> This is depending a lot on the call graph analyser and without
:> optimising it simply isn't done.
:
:Ah nice! Compiling with -O2 revealed another one:
Ach. It sure did. hammer_btree_iterate_reverse() is almost identical
to hammer_btree_iterate(). It was exactly the same bug... a mi
Joerg Sonnenberger <[EMAIL PROTECTED]> wrote:
> On Tue, Jul 15, 2008 at 03:22:34PM -0500, Vincent Stemen wrote:
>> Compiling with "gcc -o query -g -Wall main.c" produced no warnings at
>> all. But when I added #include "query.c" to the main code module after
>> it was working stand alone, I got a
One interesting thing I've found on GCC-4 is that the callgraph analyzer
will cross procedure boundaries for all procedures in that particular
source file. It can actually detect that error is left uninitialized
in this situation:
cc -Wall x.c -c -O2
x.c: In function 'fubar2':
On Tue, Jul 15, 2008 at 03:22:34PM -0500, Vincent Stemen wrote:
> Compiling with "gcc -o query -g -Wall main.c" produced no warnings at
> all. But when I added #include "query.c" to the main code module after
> it was working stand alone, I got a number of compiler warnings about
> possible use o
On Tue, Jul 15, 2008 at 07:34:10PM +0100, Simon 'corecode' Schubert wrote:
> Matthew Dillon wrote:
>> :..
>> :> :
>> :> :>That is very odd. Maybe there's a 64-bit arithmatic problem
>> somewhere
>> :>w/ gcc-34.
>> :
>> :Hi Matt,
>> :
>> :the following patch fixes the problem for me. Not s
:How the heck can a compiler "miss" this? I thought whenever there
:existed a possible execution path which would not initialize the
:variable, it would complain.
:
:cheers
: simon
Meh. It isn't really GCC's fault. Frankly up until a few years ago
compilers generally didn't even tr
Matthew Dillon wrote:
:..
:> :
:>
:>That is very odd. Maybe there's a 64-bit arithmatic problem somewhere
:>w/ gcc-34.
:
:Hi Matt,
:
:the following patch fixes the problem for me. Not sure whether it is the
:correct solution though.
:
:Cheers,
:Johannes
:
:Index: hammer_btree.c
:+
:..
:> :
:>
:>That is very odd. Maybe there's a 64-bit arithmatic problem somewhere
:>w/ gcc-34.
:
:Hi Matt,
:
:the following patch fixes the problem for me. Not sure whether it is the
:correct solution though.
:
:Cheers,
:Johannes
:
:Index: hammer_btree.c
:+ int error = 0;
:
Matthew Dillon <[EMAIL PROTECTED]> wrote:
>
> :Yes it's weird. It's reproducible with gcc34 compiled vkernels btw.
> :
> :Cheers,
> :Johannes
> :
>
>That is very odd. Maybe there's a 64-bit arithmatic problem somewhere
>w/ gcc-34.
Hi Matt,
the following patch fixes the problem for me.
14 matches
Mail list logo
