Dear Paul,
mostly looks good. Apart from a regression with optional arguments reported as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90093
all other test cases I have now execute correctly.
Cheers
Reinhold
> -Ursprüngliche Nachricht-
> Von: Paul Richard Thomas
> Gesendet: Sonntag,
Dear All,
Please find attached the updated patch, which fixes the problem with
-m32 in PR90022, eliminates the temporary creation for INTENT(IN)
dummies and fixes PR89846.
While it looks like it should be intrusive because of its size, I
believe that the patch is still safe for trunk since it is
Gilles & Reinhold,
Following the discussion, I have decided to remove the copy-in for
intent(in). Dominique and I have located the problem with -m32 for
PR90022 and I am working on PR89846 right now.
I will be resubmitting a bit later on.
Cheers
Paul
On Fri, 12 Apr 2019 at 01:25, Gilles
: [Patch, fortran] PRs 89843 and 90022 - C Fortran Interop
fixes.
Reinhold,
Thanks for the insights !
That means there is currently an other issue since copy-in is performed even
if the argument is declared as ASYNCHRONOUS.
I gave the copy-in mechanism some more thoughts, and as a library
Dear Gilles,
> -Ursprüngliche Nachricht-
> Von: Gilles Gouaillardet
> Gesendet: Freitag, 12. April 2019 02:25
> An: Bader, Reinhold ; Paul Richard Thomas
> ; fort...@gcc.gnu.org; gcc-patches patc...@gcc.gnu.org>
> Betreff: Re: AW: [Patch, fortran] PRs 89843
Reinhold,
Thanks for the insights !
That means there is currently an other issue since copy-in is performed
even if the argument is declared as ASYNCHRONOUS.
I gave the copy-in mechanism some more thoughts, and as a library
developers, I can clearly see a need *not* to do that
on a
Hi Gilles,
>
> I also found an other potential issue with copy-in.
>
> If in Fortran, we
>
> call foo(buf(0,0))
>
> then the C subroutine can only access buf(0,0), and other elements such
> as buf(1025,1025) cannot be accessed.
>
> Such elements are valid in buf, but out of bounds in the copy
