Date: Sat, 11 Sep 2010 15:59:18 +0200 From: "O. Hartmann" <ohartman@mail.zedat.fu-berlin.de> To: Andrew Brampton <brampton+freebsd@gmail.com> Cc: freebsd-questions@freebsd.org Subject: Re: Compiling software with different compiler than cc or clang results in unusable output Message-ID: <4C8B8B36.9040601@mail.zedat.fu-berlin.de> In-Reply-To: <AANLkTinymkQeeLhdbWYP=eEHEtViWVRscJ0-dVPJBX6u@mail.gmail.com> References: <4C8B4BC0.1000900@mail.zedat.fu-berlin.de> <AANLkTinymkQeeLhdbWYP=eEHEtViWVRscJ0-dVPJBX6u@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 09/11/10 11:43, Andrew Brampton wrote: > On 11 September 2010 10:28, O. Hartmann > <ohartman@mail.zedat.fu-berlin.de> wrote: >> >> Dear Sirs, >> >> you see me a kind of desperate. I wrote my own a small piece of =C2 so= ftware in >> C, calculating the orbit and position of astronomical objects, astroid= s, in >> a heliocentric coordinate system from Keplerian orbital elements. So f= ar. >> 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 loo= se >> hair! >> >> 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 a= re >> very close to professional applications or observational checks. But w= hen >> compiling the sources with gcc44 or gcc45 (same source, same CFLAG set= ting, >> mostly no CFLAGS set), then there is a great discrepancy. Sometimes wh= en >> plotting positions, the results plotted seconds before differs from th= e most >> recent. The ellipses are allways correct, but the position of a single= point >> at a specific time isn't correct. >> >> 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=20 use localtime(3), time(3) and a strftime(3) and strptime(3). I use a 'wikipedia'-algorithm converting the actual time string into an=20 'epoch' used in astronomical calculations. Compiling this routine with=20 gcc42 and clang everything is all right, compiling it with gcc44 or=20 gcc45 it returns 10 times higher values. I use very 'primitive' cutoffs=20 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 ... Oliver
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4C8B8B36.9040601>