Aaron,
I don't know whether this is relevant or not but amongst the settings
from the sysdefs.p file for various platforms, (overriding the defaults
defined in mcdata.p), the machine access setting DOUBLE_ALIGN_BITS has
the following values:
SPARC/Solaris 64 ( the default comes from mcdata.p)
x86/Solaris 32
x86/Linux 8
My limited understanding of this is that these values relate to the
underlying processor architecture, so I would expect the x86 values to
be the same in both. It could, of course, be dependent upon the
compiler's ability to pack and unpack data into words, and hence have
nothing to do with the CPU.
There is a related identifier, STRUCT_DOUBLE_ALIGN_BITS that defines
filed alignment within structures. In Linux, this alignment is set to 32
and I suspect the x86/Solaris definition was supposed to set this
identifier.
To reiterate. My knowledge of how this all fits together is scanty and I
am not sure what, if any, relationship this may have to returning single
floats from an external Fortran function, but it is the first apparent
anomaly I have encountered since starting to investigate the issue.
Regards,
Jeff
In message <cqnf22$2aoj$1@soapbox.cs.bham.ac.uk>, A.Sloman@cs.bham.ac.uk
writes
>Are there any fortran users who have used pop11 to invoke a fortran
>procedure that returns a single float result?
>
>I have been trying out some of the new algebraic and array procedures
>made available in the latest version of David Young's popvision library.
>They were developed and tested in poplog on a sun, so I wanted to make
>sure they work in linux poplog.
>
>Since the latest fix for dealing with external libraries in linux poplog
>everything seems to work perectly except for the procedures that invoke
>fortran libraries and return a single float result. Procedures that
>return integers, double floats, or complex results, or which return no
>result but transform an input array all work as expected. But procedures
>that return a single float always produce the wrong result.
>
>E.g.
> uses popvision
> uses lapack
>
> vars x = newsfloatarray([1 5], identfn);
> xDOT(x,[],false, x,[],false) =>
> ** 0.0
>
>The dot product of the array with itself should produce the result
> ** 55.0
>
>But it gives the right result for an array of double floats:
> vars y = newdfloatarray([1 5], identfn);
> xDOT(y,[],false, y,[],false) =>
> ** 55.0
>
>Similarly this procedure to add up the elements in an array gets the
>wrong result for single float array:
>
> xASUM(x, [], 1) =>
> ** 0.0
>
>and the right result for a double float array
>
> xASUM(y, [], 1) =>
> ** 15.0
>
>Does anyone know of any difference between fortran on Solaris and
>fortran on linux that might explain why these procedures work on Solaris
>and not on linux?
>
>There is a portion of REF EXTERNAL which sounds as if it may be
>relevant, but I have not been able to make use of it to track down the
>problem. It states, in
> 5.8 External Function Results
>
> Direct results from external functions can only be integer,
> floating-point, or pointer values. For example, you cannot call C
> functions which return structures by-value (nor indeed can you call C
> routines that take by-value structure arguments).
>
> One result type requiring special mention is single-length
> floating-point. In some pre-ANSI C compilers (e.g. Suns, but not HP
> Bobcat or VAX VMS), a C function declared as returning a float result
> actually returns a double-float (as if it were declared double); on the
> other hand, this is not so for a real*4 FORTRAN function on any system.
> To allow for this, the result type float is provided: this assumes a
> C-style result as appropriate to the host system, as opposed to the
> standard sfloat type which always assumes a single (in all other
> contexts, float and sfloat are identical as types).
>
> Thus the exload declaration
>
> foo(x) :sfloat
>
> is appropriate for FORTRAN, but not for C (at least, not on all Poplog
> hosts); for C, always use
>
> foo(x) :float
>
> In the case of double-float results,
>
> foo(x) :dfloat
>
> is appropriate for all languages.
>
>But there is nothing to suggest that the behaviour might differ
>between solaris and linux.
>
>Any ideas?
>
>Aaron
>
>
>
>
--
|