Re: Compiling software with different compiler than cc or clang results in unusable output
- From: Ian Smith <smithi@xxxxxxxxxxxxx>
- Date: Mon, 13 Sep 2010 01:17:37 +1000 (EST)
In freebsd-questions Digest, Vol 327, Issue 11, Message: 4
On Sat, 11 Sep 2010 "O. Hartmann" <ohartman@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
On 09/11/10 11:43, Andrew Brampton wrote:
On 11 September 2010 10:28, O. Hartmann
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
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.
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.
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.
freebsd-questions@xxxxxxxxxxx mailing list
To unsubscribe, send any mail to "freebsd-questions-unsubscribe@xxxxxxxxxxx"
- Prev by Date: Re: Upgrading packages - portupgrade confusion
- Next by Date: Re: Upgrading packages - portupgrade confusion
- Previous by thread: Re: Compiling software with different compiler than cc or clang results in unusable output
- Next by thread: gjournal+geli