Re: [ublas] numeric-bindings: current issues on 64-bit platforms

Subject: Re: [ublas] numeric-bindings: current issues on 64-bit platforms
From: Thomas Klimpel (Thomas.Klimpel_at_[hidden])
Date: 2008-12-11 06:33:42

Rutger ter Borg wrote:
> > Thomas Klimpel wrote:
> >> Good to hear. So I should probably try to do something about gbsv
and
> >> gels*. When this is done, I would like to change the type used to
bind
> >> against fortran integer from "int" to a typedef like "integer_t",
because
> >> "int" is not always the correct type on 64 platforms.
>
> Sorry for not being up-to-date around this issue. What width does the
> correct type have? Is this something where <cstdint>'s family of
int32_t,
> int64_t, etc. can be of help?

It's up to the user which "width" he prefers. The default with g77 and
gfortran is 32-bit on linux64, but the default for clapack is 64-bit on
linux64. When the user compiles lapack himself with gfortran, the option
-fdefault-integer-8 allows him to use 64-bit, and a simple change to
clapack also allows to use 32-bit with clapack. When the MKL is used,
linking against or mkl_intel_lp64 leads to 32-bit and linking against or
mkl_intel_ilp64 provides 64-bit.

Conclusion:
On 64-bit systems, the user should have the possibility to specify
whether he wants to use 32-bit or 64-bit integers. The proposed way to
specify this is the macro BIND_FORTRAN_INTEGER_8.
On 32-bit systems, the only "width" that makes sense is 32-bit. So the
macro BIND_FORTRAN_INTEGER_8 will probably have no "real" effect then.

Thomas Klimpel wrote:
> I will use the same strategy for the 64-bit modification. I proposed a
> solution in
> http://lists.boost.org/MailArchives/ublas/2008/11/3109.php
> and as long as no objection are raised, I assume that the proposed
> solution is accepted.

Even if I will now use the proposed macros BIND_FORTRAN_INTEGER_8 and
BIND_FORTRAN_F2C_RETURN_CONVENTIONS, it's quite possible to change or
rename them later, if objections occur. I only pointed out that I assume
no feedback is positive feedback, and go on based on this assumption.
This doesn't imply that the selected solution will be the last word.

Regards,
Thomas