This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: c/8395: gcc 2.95.4 and 3.2 generate wrong code for double onintel
- From: Bruce Allen <ballen at gravity dot phys dot uwm dot edu>
- To: Marco Bernardo <bernardo at sti dot uniurb dot it>
- Cc: Tim Prince <tprince at computer dot org>, Bruce Allen <ballen at aei dot mpg dot de>, gcc-gnats at gcc dot gnu dot org, gcc-prs at gcc dot gnu dot org, gcc-bugs at gcc dot gnu dot org, nobody at gcc dot gnu dot org
- Date: Sun, 3 Nov 2002 00:19:45 -0600 (CST)
- Subject: Re: c/8395: gcc 2.95.4 and 3.2 generate wrong code for double onintel
Marco, Tim is also completely correct.
Bruce
On Sat, 2 Nov 2002, Tim Prince wrote:
> On Saturday 02 November 2002 07:42, Marco Bernardo wrote:
>
> > Let me conclude by saying that my intention is not to be polemic.
> > My point of view is that of a university professor who wants to teach
> > to his students that there is a great alternative to Microsoft,
> > which is Linux and the free software world.
> > You would then understand that it is very difficult for me to support gcc
> > and to teach my students how to use gcc in the presence of such a strange
> > behavior, which is not justifiable at all on a scientific basis.
> >
> >
> From a professorial point of view, you should be encouraging your students to
> consult expert references on floating point numerics, even if you don't care
> to do so yourself. Before you start arguing about IEEE standards and
> scientific bases, you should be reading up on them, and the technical reasons
> for including the extended precision option.
> If you are teaching at this level of detail, you could show your students how
> to set 53-bit rounding mode in order to duplicate the fpu settings of
> Microsoft compilers, how to use fpu mode settings to test code reliability,
> and how to break the Microsoft compiler by putting the fpu in standard
> default mode. As standard C does not define a function for this purpose, the
> C committee must not have considered it to be as large an issue as you.
> --
> Tim Prince
>