The point is that LAPACK uses characters as control arguments in multiple places
and we don't write the LAPACK Fortran routines. It has long been known that
general character strings was a portability issue but many (not just R people)
have thought that length-one character were safe to pass as char* pointers. So
"avoid" is not really an option if we want to use LAPACK functionality
at all.
Workarounds/solutions include:
- disable certain optimizations -- works for now, but doesn't remove the
root cause so seems generally fragile
- "onion-skin" all LAPACK routines to call via a Fortran routine that
converts integer arguments to the required character -- possible, but it adds
overhead and there are hundreds of routines (and it would be kind of ugly!).
- modify LAPACK itself similarly -- requires naming change of routines as per
the license, and there are still hundreds of routines; avoids overhead, but
creates maintenance nightmare to keep up with changes in LAPACK
- change all prototypes and calls to follow gfortran calling conventions --
still a lot of work since each char* arguments need to be supplemented by a
length going at the end of the arglist. If gfortran was the only compiler
around, I'd say this would be the least painful route, but still no fun
since it requires changes to a lot of user code (in packages too). It is not
clear if this approach works with other Fortrans.
- figure out Fortran2003 specification for C/Fortran interoperability -- this
_sounds_ like the right solution, but I don't think many understand how to
use it and what is implied (in particular, will it require making changes to
LAPACK itself?)
- move towards the LAPACKE C interface -- but that also adds onionskin overhead
and ultimately calls Fortran in essentially the same way as R does, so
doesn't really solve anything at all (unless we can shift responsibility for
sorting things out onto the LAPACK team, but I kind of expect that they do not
want it.)
- twist the arms of the gfortran team to do something that keeps old code
working. Compiler engineers understandably hate that sort of thing, but I seem
to recall some precedent (pointer alignment, back in the dark ages?).
-pd
> On 4 May 2019, at 16:49 , Berend Hasselman <bhh at xs4all.nl> wrote:
>
> Hi, Thomas, Tomas,
>
> Doesn't this issue demonstrate the warning and advice given in the
last paragraph of section 6.6
> of the "Writing R Extensions" manual:
>
> <ref>
> Passing character strings from C to Fortran or vice versa is not portable
(and to Fortran 90 or later is even less so). We have found that it helps to
ensure that a C string to be passed is followed by several nuls (and not just
the one needed as a C terminator). But for maximal portability character strings
in Fortran should be avoided.
> </ref>
>
> Avoid.
>
> Berend
>
>> On 3 May 2019, at 19:25, Thomas K?nig <tk at tkoenig.net> wrote:
>>
>> Hi Tomas,
>>
>> thanks a lot for your analysis. I have created
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
>> for this, and put you in CC (if your e-mail address
>> for GCC bugzilla is still current).
>>
>> Regards
>>
>> Thomas
>>
>> ______________________________________________
>> R-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd.mes at cbs.dk Priv: PDalgd at gmail.com