This is the mail archive of the
mailing list for the GCC project.
Re: the floating point carnage
- From: Zack Weinberg <zack at codesourcery dot com>
- To: Stephen L Moshier <steve at moshier dot net>
- Cc: rth at redhat dot com, mark at codesourcery dot com, gcc at gcc dot gnu dot org
- Date: Sun, 26 May 2002 10:54:32 -0700
- Subject: Re: the floating point carnage
- References: <Pine.LNX.firstname.lastname@example.org>
On Sat, May 25, 2002 at 06:11:23PM -0400, Stephen L Moshier wrote:
> This is a train wreck. It will take _years_ to discover and repair the
> damage from these careless changes to things that were not broken.
> You have not added any new feature. You have not fixed anything, you
> have only broken things. I think you need to revert all those fp
> patches -- real.h, varasm.c, fold-const.c, etc. All of it. Everything.
> If you want to make true improvements, develop a thoughtful
> plan and get some people with appropriate knowledge to work on it,
> instead of this reckless, lunatic ransacking.
I must beg to differ. The changes I made, brought consistency between
native compilers and cross compilers; they simplified important areas
of machine-independent code, which formerly had to be concerned about
multiple possible representations of REAL_VALUE_TYPE; and as far as I
am aware they broke nothing that was not already broken.
Of the issues you have brought up, there are only two that are
substantive enough that I can look for the problems. You pointed out
that some targets had custom definitions of ASM_OUTPUT_DOUBLE which
are now being ignored. However, I did not make the change to ignore
that macro, nor do I know who did. Moreover I think it will be
easier to fix the problems with those platforms, with my changes in
You also pointed out that REAL_VALUE_TO_DECIMAL may output "Infinity"
or similar without any concern for whether the target assembler
accepts that and translates it to an appropriate bit representation.
However, all the calls to RVTD that I added replaced calls to the
system printf, which could just as well do the same thing. Again, it
should be easier to fix the problem now; we control what RVTD prints,
we do not control the system printf.
If you see other problems, please state in detail what they are,
rather than spouting vague accusations of train wrecks.