Hi,
gfortran trunk and 9-branch now have an option to automatically
generate C prototypes for old-style F77 procedures. I just did
for a in *.f; do gfortran -fsyntax-only -fc-prototypes-external $a >
${a%.f}.h; done
in the src/modules/lapack directory. This generates header
files which cont
On Sat, May 11, 2019 at 05:04:06PM +0200, Thomas Koenig wrote:
>
> gfortran trunk and 9-branch now have an option to automatically
> generate C prototypes for old-style F77 procedures. I just did
>
> for a in *.f; do gfortran -fsyntax-only -fc-prototypes-external $a >
> ${a%.f}.h; done
>
> in
On Mon, May 6, 2019 at 11:55 AM Tomas Kalibera wrote:
>
> On 5/4/19 6:49 PM, Steve Kargl wrote:
> > On Sat, May 04, 2019 at 06:42:47PM +0200, Thomas König wrote:
> >>> - figure out Fortran2003 specification for C/Fortran interoperability
> >>> -- this _sounds_ like the right solution, but I don't
On 5/6/19 12:57 PM, Janne Blomqvist wrote:
> On Mon, May 6, 2019 at 11:55 AM Tomas Kalibera
> wrote:
>> On 5/4/19 6:49 PM, Steve Kargl wrote:
>>> On Sat, May 04, 2019 at 06:42:47PM +0200, Thomas König wrote:
> - figure out Fortran2003 specification for C/Fortran interoperability
> -- this
On 5/4/19 6:49 PM, Steve Kargl wrote:
On Sat, May 04, 2019 at 06:42:47PM +0200, Thomas König wrote:
- 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,
On Sat, May 04, 2019 at 06:42:47PM +0200, Thomas König wrote:
>
> > - 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
On Sat, May 04, 2019 at 06:05:48PM +0200, peter dalgaard wrote:
>
> - 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 chang
Hi Steve,
With the caveat that one may need to use the VALUE attribute to
account for pass-by-value vs pass-by-reference.
LAPACK should be all pass by reference, it is old F77-style
code (except that the odd ALLOCATABLE array has snuck in
in the testing routines).
Hi Peter,
we (the gfortran team) are currently discussing this at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329 . I
invite everybody who has an interest in this topic to
take part in the discussion there.
Workarounds/solutions include:
- disable certain optimizations -- works for now, but
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
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:
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
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@r-project.org maili
Dear Thomas,
thank you for your input. I've debugged one of the packages and I
confirm that the breakage is related to passing of strings from C to
Fortran. Indeed, BLAS and LAPACK define a large number of subroutines
that take one or more explicit single-character strings as arguments.
Other
Hi,
I have tried to pinpoint potential problems which could lead to the
LAPACK issues that are currently seen in R. I built the current R
trunk using
AR=gcc-ar RANLIB=gcc-ranlib ./configure --prefix=$HOME --enable-lto
--enable-BLAS-shlib=no --without-recommended-packages
and used this to fin
14 matches
Mail list logo
