Re: [PATCH] Fortran: fix issue with multiple references of a procedure pointer [PR97245]
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 > references of the procedure pointer after the first CALL. > > Regtested on x86_64-pc-linux-gnu. OK for mainline? > > Would it be OK to backport this fix to 13-branch? > OK, and yes, you can backport if you want. -- Steve
[PATCH] Fortran: fix issue with multiple references of a procedure pointer [PR97245]
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_64-pc-linux-gnu. OK for mainline?
Would it be OK to backport this fix to 13-branch?
Thanks,
Harald
From 1ca323b8d58846d0890a8595ba9fc7bc7eee8fdd Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Fri, 3 Nov 2023 19:41:54 +0100
Subject: [PATCH] Fortran: fix issue with multiple references of a procedure
pointer [PR97245]
gcc/fortran/ChangeLog:
PR fortran/97245
* match.cc (gfc_match_call): If a procedure pointer has already been
resolved, do not create a new symbol in a procedure reference of
the same name shadowing the first one if it is host-associated.
gcc/testsuite/ChangeLog:
PR fortran/97245
* gfortran.dg/proc_ptr_53.f90: New test.
---
gcc/fortran/match.cc | 1 +
gcc/testsuite/gfortran.dg/proc_ptr_53.f90 | 35 +++
2 files changed, 36 insertions(+)
create mode 100644 gcc/testsuite/gfortran.dg/proc_ptr_53.f90
diff --git a/gcc/fortran/match.cc b/gcc/fortran/match.cc
index f848e52be4c..9e3571d3dbe 100644
--- a/gcc/fortran/match.cc
+++ b/gcc/fortran/match.cc
@@ -5064,6 +5064,7 @@ gfc_match_call (void)
right association is made. They are thrown out in resolution.)
... */
if (!sym->attr.generic
+ && !sym->attr.proc_pointer
&& !sym->attr.subroutine
&& !sym->attr.function)
{
diff --git a/gcc/testsuite/gfortran.dg/proc_ptr_53.f90 b/gcc/testsuite/gfortran.dg/proc_ptr_53.f90
new file mode 100644
index 000..29dd08d9f75
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/proc_ptr_53.f90
@@ -0,0 +1,35 @@
+! { dg-do compile }
+! PR fortran/97245 - ASSOCIATED intrinsic did not recognize a
+!pointer variable the second time it is used
+
+MODULE formulaciones
+ IMPLICIT NONE
+
+ ABSTRACT INTERFACE
+ SUBROUTINE proc_void()
+ END SUBROUTINE proc_void
+ end INTERFACE
+
+ PROCEDURE(proc_void), POINTER :: pADJSensib => NULL()
+
+CONTAINS
+
+ subroutine calculo()
+PROCEDURE(proc_void), POINTER :: otherprocptr => NULL()
+
+IF (associated(pADJSensib)) THEN
+ CALL pADJSensib ()
+ENDIF
+IF (associated(pADJSensib)) THEN! this was erroneously rejected
+ CALL pADJSensib ()
+END IF
+
+IF (associated(otherprocptr)) THEN
+ CALL otherprocptr ()
+ENDIF
+IF (associated(otherprocptr)) THEN
+ CALL otherprocptr ()
+END IF
+ end subroutine calculo
+
+END MODULE formulaciones
--
2.35.3
GCN: Address undeclared 'NULL' usage in 'libgcc/config/gcn/gthr-gcn.h:__gthread_getspecific' (was: [PATCH 1/3] Create GCN-specific gthreads)
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 that for nvptx -- and I didn't run into
the need when early this year I was working on Fortran I/O support for
nvptx corresponding to that of GCN. (That's the pending
"nvptx, libgfortran: Switch out of "minimal" mode" and prerequisite
patches.)
Anyway, not resolving that mystery today, but just a simple technicality:
pushed to master branch commit 5926f30a8dcee9142360fdae445ebfdee4a528f9
"GCN: Address undeclared 'NULL' usage in
'libgcc/config/gcn/gthr-gcn.h:__gthread_getspecific'",
see attached.
Grüße
Thomas
> Notes:
>
> * GCN GPUs do not support dynamic creation and deletion of threads, so
> there can be no implementation for those functions. (There may be
> many threads, of course, but they are hardware managed and must be
> launched all at once.)
>
> * It would be possible to implement support for EMUTLS, but I have no
> wish to do so at this time, and it isn't likely to be needed by
> OpenMP or OpenACC offload kernels, so those functions are also stub
> implementations.
>
> OK to commit?
>
> --
> Andrew Stubbs
> Mentor Graphics / CodeSourcery
> Create GCN-specific gthreads
>
> 2019-06-05 Kwok Cheung Yeung
> Andrew Stubbs
>
> gcc/
> * config.gcc (thread_file): Set to gcn for AMD GCN.
> * config/gcn/gcn.c (gcn_emutls_var_init): New function.
> (TARGET_EMUTLS_VAR_INIT): New hook.
>
> config/
> * gthr.m4 (GCC_AC_THREAD_HEADER): Add case for gcn.
>
> libgcc/
> * configure: Regenerate.
> * config/gcn/gthr-gcn.h: New.
>
> diff --git a/config/gthr.m4 b/config/gthr.m4
> index 7b29f1f3327..4b937306ad0 100644
> --- a/config/gthr.m4
> +++ b/config/gthr.m4
> @@ -13,6 +13,7 @@ AC_DEFUN([GCC_AC_THREAD_HEADER],
> case $1 in
> aix) thread_header=config/rs6000/gthr-aix.h ;;
> dce) thread_header=config/pa/gthr-dce.h ;;
> +gcn) thread_header=config/gcn/gthr-gcn.h ;;
> lynx)thread_header=config/gthr-lynx.h ;;
> mipssde) thread_header=config/mips/gthr-mipssde.h ;;
> posix) thread_header=gthr-posix.h ;;
> diff --git a/gcc/config.gcc b/gcc/config.gcc
> index 6b00c387247..b450098aa09 100644
> --- a/gcc/config.gcc
> +++ b/gcc/config.gcc
> @@ -1428,6 +1428,7 @@ amdgcn-*-amdhsa)
> fi
> # Force .init_array support.
> gcc_cv_initfini_array=yes
> + thread_file=gcn
> ;;
> moxie-*-elf)
> gas=yes
> diff --git a/gcc/config/gcn/gcn.c b/gcc/config/gcn/gcn.c
> index 71f4b4ce35a..e528b649cce 100644
> --- a/gcc/config/gcn/gcn.c
> +++ b/gcc/config/gcn/gcn.c
> @@ -3163,6 +3163,16 @@ gcn_valid_cvt_p (machine_mode from, machine_mode to,
> enum gcn_cvt_t op)
> || (to == DFmode && (from == SImode || from == SFmode)));
> }
>
> +/* Implement TARGET_EMUTLS_VAR_INIT.
> +
> + Disable emutls (gthr-gcn.h does not support it, yet). */
> +
> +tree
> +gcn_emutls_var_init (tree, tree decl, tree)
> +{
> + sorry_at (DECL_SOURCE_LOCATION (decl), "TLS is not implemented for GCN.");
> +}
> +
> /* }}} */
> /* {{{ Costs. */
>
> @@ -6007,6 +6017,8 @@ print_operand (FILE *file, rtx x, int code)
> #define TARGET_CONSTANT_ALIGNMENT gcn_constant_alignment
> #undef TARGET_DEBUG_UNWIND_INFO
> #define TARGET_DEBUG_UNWIND_INFO gcn_debug_unwind_info
> +#undef TARGET_EMUTLS_VAR_INIT
> +#define TARGET_EMUTLS_VAR_INIT gcn_emutls_var_init
> #undef TARGET_EXPAND_BUILTIN
> #define TARGET_EXPAND_BUILTIN gcn_expand_builtin
> #undef TARGET_FUNCTION_ARG
> diff --git a/libgcc/config/gcn/gthr-gcn.h b/libgcc/config/gcn/gthr-gcn.h
> new file mode 100644
> index 000..4227b515f01
> --- /dev/null
> +++ b/libgcc/config/gcn/gthr-gcn.h
> @@ -0,0 +1,163 @@
> +/* Threads compatibility routines for libgcc2 and libobjc. */
> +/* Compile this one with gcc. */
> +/* Copyright (C) 2019 Free Software Foundation, Inc.
> +
> +This file is part of GCC.
> +
> +GCC is free software; you can redistribute it and/or modify it under
> +the terms of the GNU General Public License as published by the Free
> +Software Foundation; either version 3, or (at your option) any later
> +version.
> +
> +GCC is distributed in the hope that it will be useful, but WITHOUT ANY
> +WARRANTY; without even the implied warranty of MERCHANTABILITY or
> +FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
> +for more details.
> +
> +Under Section 7 of GPL version 3, you are granted additional
> +permissions described in the GCC Runtime Library Exception, version
> +3.1, as published by the Free Software Foundation.
> +
> +You should have received a copy of the GNU General Public License and
> +a copy of the GCC Runtime Library Exception along with this program;
> +see the files COPYING3 and
Re: [PATCH] Fortran: Fix generate_error library function fnspec
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 escape." The function
itself, however, with signature:
bool
generate_error_common (st_parameter_common *cmp, int family, const char
*message)
contains the following:
/* Report status back to the compiler. */
cmp->flags &= ~IOPARM_LIBRETURN_MASK;
which does not correspond to the fnspec and breaks testcase
gfortran.dg/large_unit_2.f90 when my patch is applied, since it tries
to re-use the flags from before the call.
This patch replaces the "R" with "W" which stands for "specifies that
the memory pointed to by the parameter does not escape."
Bootstrapped and tested on x86_64-linux. OK for master?
LGTM - thanks for the fix!
Tobias
2023-11-02 Martin Jambor
* trans-decl.cc (gfc_build_builtin_function_decls): Fix fnspec of
generate_error.
---
gcc/fortran/trans-decl.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/fortran/trans-decl.cc b/gcc/fortran/trans-decl.cc
index a3f037bd07b..b86cfec7d49 100644
--- a/gcc/fortran/trans-decl.cc
+++ b/gcc/fortran/trans-decl.cc
@@ -3821,7 +3821,7 @@ gfc_build_builtin_function_decls (void)
void_type_node, -2, pchar_type_node, pchar_type_node);
gfor_fndecl_generate_error = gfc_build_library_function_decl_with_spec (
- get_identifier (PREFIX("generate_error")), ". R . R ",
+ get_identifier (PREFIX("generate_error")), ". W . R ",
void_type_node, 3, pvoid_type_node, integer_type_node,
pchar_type_node);
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht
München, HRB 106955
[PATCH] Fortran: Fix generate_error library function fnspec
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, with signature:
bool
generate_error_common (st_parameter_common *cmp, int family, const char
*message)
contains the following:
/* Report status back to the compiler. */
cmp->flags &= ~IOPARM_LIBRETURN_MASK;
which does not correspond to the fnspec and breaks testcase
gfortran.dg/large_unit_2.f90 when my patch is applied, since it tries
to re-use the flags from before the call.
This patch replaces the "R" with "W" which stands for "specifies that
the memory pointed to by the parameter does not escape."
Bootstrapped and tested on x86_64-linux. OK for master?
2023-11-02 Martin Jambor
* trans-decl.cc (gfc_build_builtin_function_decls): Fix fnspec of
generate_error.
---
gcc/fortran/trans-decl.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/fortran/trans-decl.cc b/gcc/fortran/trans-decl.cc
index a3f037bd07b..b86cfec7d49 100644
--- a/gcc/fortran/trans-decl.cc
+++ b/gcc/fortran/trans-decl.cc
@@ -3821,7 +3821,7 @@ gfc_build_builtin_function_decls (void)
void_type_node, -2, pchar_type_node, pchar_type_node);
gfor_fndecl_generate_error = gfc_build_library_function_decl_with_spec (
- get_identifier (PREFIX("generate_error")), ". R . R ",
+ get_identifier (PREFIX("generate_error")), ". W . R ",
void_type_node, 3, pvoid_type_node, integer_type_node,
pchar_type_node);
--
2.42.0
Re: [PATCH] Fortran: passing of allocatable/pointer arguments to OPTIONAL+VALUE [PR92887]
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 standard says that a non-allocated / non-associated actual argument > in that case shall be treated as non-present. > > However, gfortran's calling conventions demand that the presence status > for OPTIONAL+VALUE is passed as a hidden argument, while we need to > pass something on the stack which has the right type. The solution > is to conditionally create a temporary when needed. > > Testcase checked with NAG. > > Regtested on x86_64-pc-linux-gnu. OK for mainline? > > Thanks, > Harald > >
[Patch, fortran] PR112316 - [13 Regression] Fix for PR87477 rejects valid code with a bogus error...
Hi All,
I have pushed as 'obvious' a fix for this regression to both 13-branch and
mainline. The patch itself looks substantial but it consists entirely of
the removal of a condition and repagination of the corresponding block.
Please see below for part of my first comment on the PR for an explanation.
Paul
A temporary work around is to invert the order of the contained procedures.
The problem is caused by a stupid (on my part :-( ) oversight:
diff --git a/gcc/fortran/parse.cc b/gcc/fortran/parse.cc
index e103ebee557..f88f9be3be8 100644
--- a/gcc/fortran/parse.cc
+++ b/gcc/fortran/parse.cc
@@ -5196,7 +5196,7 @@ parse_associate (void)
}
}
- if (target->rank)
+ if (1)
{
int rank = 0;
rank = target->rank;
fixes the problem and regtests OK.
