This is the mail archive of the gcc@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]

Re: Re: What is acceptable for -ffast-math? (Was: associative law in combine)



dewar@gnat.com wrote:
> >

But if you look at real Fortran codes, they are full of parentheses to
stop
the compiler from messing around, and in fact most Fortran compilers
do only
very limited mucking even when no parens are present. I would be shocked
to find a FOrtraqn compiler that changed

a*c + b*c

into

(a+b)*c

a totally diffrerent expression!

I would have written the second expression if I had wanted that effect.

_____________________________________
This replacement is mentioned in the Fortran standard as one which is
permitted.  I agree that it is one which might be expected to appear
in the original source, if it were intended by the programmer, and
that it is not commonly done by Fortran compilers.  Unfortunately, for
at least as long as the Fortran standard has specified which
associations were valid, there have been compilers which violate the
standard, at least when normal optimizations are invoked.

When I provoked this thread, the topic was gcc and g77 and the
treatment of division optimizations recently introduced into gcc-3.1.
I pointed out that it should be possible to shut off separately those
optimizations where gcc can't guarantee to observe parentheses present
in the source, as well as the strength reduction of division by
pre-inversion.  Both of these treatments remain inextricable from the
optimizations packages of certain current commercial compilers.

  The main question to be settled, I think, is whether these
optimizations should be included in -ffast-math by default, but be
capable of being shut off, or be invoked only when specifically
requested.  The latter option is contrary to conformance with the SPEC
criteria which are driving most commercial compilers, but gcc should
not be driven by SPEC if SPEC drives in the wrong direction.

Tim
tprince@computer.org


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