Return to BSD News archive
Xref: sserve comp.os.386bsd.questions:7809 comp.os.386bsd.bugs:2005
Newsgroups: comp.os.386bsd.questions,comp.os.386bsd.bugs
Path: sserve!newshost.anu.edu.au!munnari.oz.au!cs.mu.OZ.AU!summer
From: summer@ee.mu.OZ.AU (Mark Summerfield)
Subject: gcc optimization probs. with FPU
Message-ID: <9401009.4365@mulga.cs.mu.OZ.AU>
Sender: news@cs.mu.OZ.AU
Organization: Dept of Electrical & Electronic Engineering, University of Melbourne
Date: Sun, 9 Jan 1994 22:45:34 GMT
Lines: 62
Environment: NetBSD 0.8, gcc/g++ 2.4.5, using Glen Geers' alternative
math library with all available patches (to my knowledge)
applied.
I have asked for help before regarding floating exceptions that have turned
up in programs using the alternative maths library -- those who kindly
offered assistance may remember. It turns out that, in the current program
at least, these exceptions only occur when optimization is enabled with
either -O or -O2, and even then only in one particular piece of code.
If I enable a number of optimizations manually ( -fthread-jumps
-fstrength-reduce -fcse-follow-jumps -fcse-skip-blocks -frerun-cse-after-loop
-fexpensive-optimizations), the exceptions do not occur! How do I find
out which -foptions the -O and -O2 flags enable? Do they perform other
optimizations which are not individually accessible? Whatever the problem,
it is somehow related to the alternative maths library, but does not
seem to occur within calls to it! This is really mystifying me -- any
suggestions as to what might be going on would be most appreciated.
As an example, here's some code in which the problem occurs. Unfortunately,
it doesn't seem to generate an exception when run outside the context
of my application, and it's in C++
double wtemp = sin(0.5*theta);
Complex wp(-2.0 * wtemp * wtemp, sin(theta));
Complex w = wp + 1.0;
for (int i = 1; i < n/2; i++) {
int i2 = n - i;
Complex datai = data[i];
Complex datai2 = data[i2];
Complex t2c = conj(data[i2]);
Complex h1 = 0.5 * (data[i] + t2c);
Complex h2 = c * (data[i] - t2c);
data[i] = h1 + w * h2;
data[i2] = conj(h1 - w * h2);
w = wp * w + w;
}
(theta is a double, c is Complex, data[] is an array of Complex). Those
who know C++ will appreciate how much more complicated the code generated
by the list of declarations and assignments is than it appears to be!! The
exception occurs during the calculation of h2 in the first, but not any
subsequent, pass of the loop. Since it is only the calls to sin() prior to
the loop which use the maths library, they must be somehow involved. The
fact that the exception does not occur on later passes of the loop seems to
support this. The exception which occurs is an "Illegal Operation". I can
only assume that some optimization is eliminating intermediate steps in the
calculations, but it's a guess.
Is it possible that this problem is somehow related to the floating
point stack -- perhaps something the maths library does wrong, or that
the compiler doesn't know about?
Thankyou to anyone who's taken the time to read this! More thanks will
be forthcoming if you can help.
Mark.
--------------------------------------------------------
Mark Summerfield, Photonics Research Laboratory
Department of Electrical and Electronic Engineering, University of Melbourne
ACSnet[AARN/Internet]: summer@ee.mu.oz[.au]
--------------------------------------------------------