This is the mail archive of the
mailing list for the GCC project.
Re: real.c on unicosmk
- From: Stephen L Moshier <steve at moshier dot net>
- To: Zack Weinberg <zack at codesourcery dot com>
- Cc: Joe Buck <Joe dot Buck at synopsys dot com>, Roman Lechtchinsky <rl at cs dot tu-berlin dot de>, <gcc at gcc dot gnu dot org>
- Date: Fri, 24 May 2002 07:07:39 -0400 (EDT)
- Subject: Re: real.c on unicosmk
On Wed, 22 May 2002, Zack Weinberg wrote:
> On Wed, May 22, 2002 at 09:40:40PM -0400, Stephen L Moshier wrote:
> > > > ns32k and fr30 assume that a REAL_VALUE_TYPE has the same
> > > > data structure as the host computer's native double type.
> > > >
> > > > d30v assumes the host and target computer have the same native
> > > > float data structure.
> > >
> > > I believe I corrected all the places that made these assumptions in
> > > 3.2. Did I miss something?
> > Yes.
> > What I noticed is the same in 3.1 and current cvs.
> Well, don't just keep me in suspense, man! What was the problem?
Sorry, I don't get paid anything for this and do not have very much
time available at the moment. It is just a hobby project.
Without knowing how the target arithmetic works and without being able to
testing the changes aftwerward, I would refuse to touch that floating
point support, and would not encourage anyone to touch it.
Our REAL_VALUE_TO_DECIMAL function will cheerfully write the words
"NaN' and "Infinity" and will generate strings for denormal values and
out of range values. Similarly REAL_VALUE_TO_TARGET_xxx will generate
the corresponding binary bit patterns that might not be compatible.
The arithmetic may be buggy and the assembler may be buggy. The
target computer's printf will tend to be bug-compatible with the
system's other bugs, and that may obscure the problems. Any of these
factors could result in crashing the target's assembler or setting the
computer on fire. Until you know how to deal with such cases, you
cannot safely turn on REAL_ARITHMETIC. Finding that out entails a
research project for each machine, each precision of the arithmetic,
and each variant like soft-float. We have actually gone through all
that in excruciating detail for all of the major supported targets.
We don't presently know these answers for the targets that haven't
been fixed, and the people who wrote those ports probably don't know