[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: structure alignment problem ?



On Sat, Sep 08, 2001 at 06:42:43AM +0200, JM Bourdaret wrote:

Sorry that this reply is very late.
Hopefully you've now solved this for yourself, and haven't been wasting loads
of time over the past 2 weeks

> Hello
> 
> 
> in short:
> Is there an issue with long double functions and/or math long double functions of glibc and 
> the ARM ?

Not sure. I suspect it's a glibc bug, as I found that modfl wasn't prototyped
on arm.

> in long:
> 
> I've a package that can't pass the autobuilder (thanks to Phil for the bugreport!)
> i've read the Brian Bray FAQ on structure alignment, and 
> it is the only clue i have.
> 
> i would like your advice on that. the package is mainly a
> calculator, with math functions and all. the compilation
> fails after displaying several warning " Implicit declaration of" 
> about _almost all and only_ the long double math functions (asinl, powl sinhl, atanhl ...).
> strangely, no warning are raised upon fabsl and sqrtl.
> needless to say that the includes seems good to me (math.h and -lm for linkage) and 
> those errors does not show on x86
> 
> <...>
> kcalc_core.cpp: In method `void QtCalculator::ComputeSin()':
> kcalc_core.cpp:761: implicit declaration of function `int sinhl(...)'
> kcalc_core.cpp:764: implicit declaration of function `int asinhl(...)'  
> <...>
>  i really can't think about a libc headers error
> 
> note that it passed the autoconf tests "check for long double..yes" without problems before the compil. and configure uses fabsl().
> the program claims to use long double as its base type. so it may very well be a bad assumption made by the author somewhere.
> 
> Thanks for any pointer or tip
> 
> jean marc
> casi@debian.org
> 
> On another hand, it is easy to put that on the shoulder of the structure alignment pb :)

It will all be going wrong because the implicitly declared maths functions
are assumed to be returning int. When compiling your program the compiler
will then convert the return value (whatever integer is in r0) into a long
double (if that's what's needed by the context) silently according to the
usual C rules of promotion.
However the functions are actually returning long doubles (not sure how
that is done in the procedure call standard) so r0 will have garbage, hence
your the program won't work.

Nicholas Clark



Reply to: