|
From: Chris A. <ch...@at...> - 2004-03-26 16:28:48
Attachments:
bitfieldtest.tar.bz2
|
Hi, I've finally managed to make a small enough test case to post to the mailing list. I get this output when a "make test" is done: test.i686 test.i686 ==27996== Conditional jump or move depends on uninitialised value(s) ==27996== at 0x80483A0: main (test.c:26) ==27996== ==27996== Conditional jump or move depends on uninitialised value(s) ==27996== at 0x80483A2: main (test.c:26) test.i386 test.i686calloc test.i686nobit test.i686noassign The confusing thing is that valgrind reports the error on line 26, which is clearly using an intialized value. I believe that the problem is caused on line 23, where myInstance->myVal is assigned. The assembly code looks good to me, so I'm not sure what valgrind thinks is going wrong. This problem occurs when using gcc-2.95, gcc-3.2, and gcc-3.3 from debian unstable, but not when using gcc-2.96 from redhat 7.2. I am using valgrind-2.1.1 with linux 2.6.4 and libc-2.3.2 Cheers, Chris -- Chris AtLee <ch...@at...> |
|
From: Tom H. <th...@cy...> - 2004-03-26 17:15:16
|
In message <1080318522.20340.26.camel@antigua>
Chris AtLee <ch...@at...> wrote:
> The confusing thing is that valgrind reports the error on line 26, which
> is clearly using an intialized value. I believe that the problem is
> caused on line 23, where myInstance->myVal is assigned. The assembly
> code looks good to me, so I'm not sure what valgrind thinks is going
> wrong.
The bug is exactly where valgrind says it is, and it has nothing
whatsoever to do with the bitfield. It is in fact a bug in valgrind
when a floating point comparison is done using fucomip and the other
related instructions which store the results in eflags.
Basically valgrind is failing to set the validity of the relevant bits
in eflags for those instructions which means it then considers the
result of the comparison to be undefined. When compiling for i386 gcc
is choosing to use fucompp instead, which stores it's result in the
floating point flags and that works fine.
Can you raise a bug for this please...
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Chris A. <ch...@at...> - 2004-03-26 19:34:54
|
On Fri, 2004-03-26 at 12:14, Tom Hughes wrote: > In message <1080318522.20340.26.camel@antigua> > Chris AtLee <ch...@at...> wrote: > > > The confusing thing is that valgrind reports the error on line 26, which > > is clearly using an intialized value. I believe that the problem is > > caused on line 23, where myInstance->myVal is assigned. The assembly > > code looks good to me, so I'm not sure what valgrind thinks is going > > wrong. > > The bug is exactly where valgrind says it is, and it has nothing > whatsoever to do with the bitfield. It is in fact a bug in valgrind > when a floating point comparison is done using fucomip and the other > related instructions which store the results in eflags. Why does changing myVal to a regular unsigned fix the problem then? Or commenting out line 23? > Basically valgrind is failing to set the validity of the relevant bits > in eflags for those instructions which means it then considers the > result of the comparison to be undefined. When compiling for i386 gcc > is choosing to use fucompp instead, which stores it's result in the > floating point flags and that works fine. > > Can you raise a bug for this please... Sure, it's submitted as bug #78514 Cheers, Chris |
|
From: Tom H. <th...@cy...> - 2004-03-26 22:51:36
|
In message <1080329690.20340.43.camel@antigua>
Chris AtLee <ch...@at...> wrote:
> On Fri, 2004-03-26 at 12:14, Tom Hughes wrote:
> > In message <1080318522.20340.26.camel@antigua>
> > Chris AtLee <ch...@at...> wrote:
> >
> > > The confusing thing is that valgrind reports the error on line 26, which
> > > is clearly using an intialized value. I believe that the problem is
> > > caused on line 23, where myInstance->myVal is assigned. The assembly
> > > code looks good to me, so I'm not sure what valgrind thinks is going
> > > wrong.
> >
> > The bug is exactly where valgrind says it is, and it has nothing
> > whatsoever to do with the bitfield. It is in fact a bug in valgrind
> > when a floating point comparison is done using fucomip and the other
> > related instructions which store the results in eflags.
>
> Why does changing myVal to a regular unsigned fix the problem then? Or
> commenting out line 23?
It probably has some subtle effect on gcc's code generation. If it
has to use a different instruction there then knock on scheduling
effects may make it decide to use a different instruction for the
floating point comparison or something.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|