On Fri, Nov 03, 2023 at 07:56:20PM +0100, Harald Anlauf wrote:
> Dear all,
>
> this is a rather weird bug with a very simple fix. If a procedure pointer
> is referenced in a CALL, a symbol was created shadowing the original
> declaration if it was host-associated. Funnily, this affected only
> r
Dear all,
this is a rather weird bug with a very simple fix. If a procedure pointer
is referenced in a CALL, a symbol was created shadowing the original
declaration if it was host-associated. Funnily, this affected only
references of the procedure pointer after the first CALL.
Regtested on x86_
Hi!
On 2019-06-07T15:39:36+0100, Andrew Stubbs wrote:
> This patch creates a new gthread model for AMD GCN devices.
>
> For now, there's just enough support for libgfortran to use mutexes in
> its I/O routines. The rest can be added at a later time, if at all.
Hmm, interestingly we don't have th
On 03.11.23 13:54, Martin Jambor wrote:
when developing an otherwise unrelated patch I've discovered that the
fnspec for the Fortran library function generate_error is wrong. It is
currently ". R . R " where the first R describes the first parameter
and means that it "is only read and does not es
Hi,
when developing an otherwise unrelated patch I've discovered that the
fnspec for the Fortran library function generate_error is wrong. It is
currently ". R . R " where the first R describes the first parameter
and means that it "is only read and does not escape." The function
itself, however,
Hi Harald,
This looks good to me. OK for mainline.
Thanks for the patch.
Paul
On Wed, 1 Nov 2023 at 22:10, Harald Anlauf wrote:
> Dear all,
>
> I've dusted off and cleaned up a previous attempt to fix the handling
> of allocatable or pointer actual arguments to OPTIONAL+VALUE dummies.
> The
