This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: A possible bug in parsing floating point numbers.


'Zack Weinberg' wrote:
> 
> On Thu, Apr 04, 2002 at 02:39:46PM -0800, tm wrote:
> ...
> > If you look closely, the value 1.0f has been encoded twice in TWO
> > different ways.
> >
> > The first one is the static initialization of b which is encoded as
> > 1065353218. In hexadecimal this value is 0x3f800002 which is incorrect.
> >
> > The second value is one of the arguments passed to ___ltsf2. This value
> > is 106535217 which is hexadecimal 0x3f800001 which is also incorrect.
> 
> I apologize for the delay in returning to this bug.  I was tied down
> with other work.  Your further analysis of the problem -- buffer
> overflow due to blindly calling etoe53 in PUT_REAL -- was correct.
> 

This seems to fix my testcase. We should wait for Kazu to test the patch
before
declaring the problem fixed, however.

My only objection to these patches is they make GCC more difficult to
maintain
and debug because the floating-point values are no longer easily
readable in
the assembly output.

Is it feasible to implement a feature whereby the compiler will emit a
comment
containing human-readable string for the floating-point value when the
option
"-fverbose-asm" is specified?

Toshi


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]