Compiling software with different compiler than cc or clang results in unusable output

[Ian Smith]

In freebsd-questions Digest, Vol 327, Issue 11, Message: 4
On Sat, 11 Sep 2010 "O. Hartmann" <ohartman at mail.zedat.fu-berlin.de> wrote:
 > On 09/11/10 11:43, Andrew Brampton wrote:
 > > On 11 September 2010 10:28, O. Hartmann
 > > <ohartman at mail.zedat.fu-berlin.de>  wrote:
 > >>
 > >> you see me a kind of desperate. I wrote my own a small piece of  software in
 > >> C, calculating the orbit and position of astronomical objects, astroids, in
 > >> a heliocentric coordinate system from Keplerian orbital elements. So far.

Don't expect too much accuracy from Keplerian orbits anywhere vaguely 
near Jupiter or Saturn - but yes they're a great place to start from.

 > >> The software calculates the set of points of an ellipse based upon
 > >> ephemeridal datas taken from the Minor Planet Cataloge. Again, so far,
 > >> everything all right. The set of points of an orbit is all right and
 > >> correct. But when it comes to positions at a specific time, then I loose
 > >> hair!

The program mentioned below can generate accurate results for as often 
as every few hours; handy at least for comparing your results over time.

 > >> Compiling this piece of software with FreeBSD's gcc (V4.2) and clang (clang
 > >> devel) on my private and lab's FreeBSD boxes (both most recent FreeBSD
 > >> 8.1/amd64), this program does well, the calculated orbital positions are
 > >> very close to professional applications or observational checks. But when
 > >> compiling the sources with gcc44 or gcc45 (same source, same CFLAG setting,
 > >> mostly no CFLAGS set), then there is a great discrepancy. Sometimes when
 > >> plotting positions, the results plotted seconds before differs from the most
 > >> recent. The ellipses are allways correct, but the position of a single point
 > >> at a specific time isn't correct.

Know the feeling; it took Kepler 20 years to get ellipses down pat :)

 > >> I use the GNU autotools to build the package.
 > >>
 > >> I suspekt miscompilations in memory alloction or in some time- or
 > >> mathematical functions like sin, cos.
 > >>
 > >> before I digg deeper I'd like to ask the community for some hints how to
 > >> hunt down such a problem.
 > >>
 > >> regards,
 > >> Oliver
 > >
 > > Sounds a cool project. I suspect you are miss-using a feature of C or
 > > are using uninitialised memory, and with gcc44/45's more aggressive
 > > optimisations it is getting it wrong. I have three suggestions
 > >
 > > 1) Use valgrind to check if it finds anything wrong when running your
 > > program. Check both the good and the bad builds.
 > >
 > > 2) If your program is made up of multiple C files, then try compiling
 > > all of the C files with gcc42, but just one at a time with gcc44. This
 > > way will help you track down exactly which C file has "the bug".
 > >
 > > 3) Finally do some printf debugging to find the first line of code
 > > that is generating the wrong value.
 > >
 > > I hope these suggestions help.
 > > Andrew
 > 
 > Hello Andrew.
 > 
 > Thanks for your comments, they are worth trying out. I will do so ...
 > 
 > item 2) oh, yes, a very good idea ...
 > 
 > item 3) I did already, the whole software is built up by those printf's.
 > 
 > The problem boiled down to be some problem in the UNIX time routines. I 
 > use localtime(3), time(3) and a strftime(3) and strptime(3).
 > 
 > I use a 'wikipedia'-algorithm converting the actual time string into an 
 > 'epoch' used in astronomical calculations. Compiling this routine with 
 > gcc42 and clang everything is all right, compiling it with gcc44 or 
 > gcc45 it returns 10 times higher values. I use very 'primitive' cutoffs 
 > for casting a double value into an int - I need the integrale value, not 
 > the remainings after the decimal point. I will check this again and look 
 > forward for a cleaner solution. But isn't this a 'bug'?
 > 
 > I'll try the BETA of the new FreeBSD PathScale compiler if I get some.
 > 
 > Well, I'll report ...

Please do.  Well I can't help at all about the compilers, but I suggest 
having a close look over Steve Moshier's 'Numerical Integration of Sun, 
Moon and Planets' at http://www.moshier.net/ssystem.html

I compiled the contents of http://www.moshier.net/de118i-2.zip as-is on 
a FreeBSD 5.5 system four years ago and it just ran, reproducing closely 
my late '90s results from the then DOS version SSYSTEM.EXE; there are 
#defines for using doubles or long doubles, major asteroids on not, even 
including 'your' asteroid's elements, and test results for comparison.

You could check how your different compilers treat those sources?  Apart 
from that it's very readable code and there's just about every maths and 
trig function imaginable, including quadrant-correct arctans and such.  
And also, of course, Julian Ephemeris Date handling routines .. not to 
mention close-to-JPL positions and velocities over many centuries :)

Good luck.  I'm hoping to revive and extend from my '90s Pascal astro 
programs in FPC soon to chew on 100s of years of ssystem ephemerides. 

HTH, Ian