Re: [Patch, Fortran, Update] PR98301 Re: RANDOM_INIT() and coarray Fortran
Hi Steve, hi all,
thank you for pointing that out, Steve. When I started the work, I told
myself, that I have to remember to add your patch to the submit. Well, that did
not last for more than eight hours and I had forgotten.
So here is now the combination of Steve's and my patch (attached).
Bootstrapped and regtested ok on x86_64/f33.
@Steve: Is this your correct mail address for the changelog or do you prefer a
different one?
Regards,
Andre
Changelog:
Steve Kargl
PR fortran/98301 - random_init() is broken
Correct implementation of random_init() when -fcoarray=lib is given.
gcc/fortran/ChangeLog:
PR fortran/98301
* trans-decl.c (gfc_build_builtin_function_decls): Move decl.
* trans-intrinsic.c (conv_intrinsic_random_init): Use bool for
lib-call of caf_random_init instead of logical (4-byte).
* trans.h: Add tree var for random_init.
libgfortran/ChangeLog:
PR fortran/98301
* caf/libcaf.h (_gfortran_caf_random_init): New function.
* caf/single.c (_gfortran_caf_random_init): New function.
* gfortran.map: Added fndecl.
* intrinsics/random_init.f90: Implement random_init.
On Fri, 23 Apr 2021 10:18:17 -0700
Steve Kargl wrote:
> Andre,
>
> Thanks for taking care of OpenCoarray portion of RANDOM_INIT.
> My last non-coarray aware patch is attached to the PR in bugzilla.
> Since the change over to git, I no longer commit to the source tree.
> I suggest combining your patch with my patch if you intend to
> commit; otherwise, attach your patch to the PR and sit patiently
> until someone can do the combined commit.
>
--
Andre Vehreschild * Email: vehre ad gmx dot de
diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c
index cc9d85543ca..de0e8fb0314 100644
--- a/gcc/fortran/trans-decl.c
+++ b/gcc/fortran/trans-decl.c
@@ -170,6 +170,7 @@ tree gfor_fndecl_co_min;
tree gfor_fndecl_co_reduce;
tree gfor_fndecl_co_sum;
tree gfor_fndecl_caf_is_present;
+tree gfor_fndecl_caf_random_init;
/* Math functions. Many other math functions are handled in
@@ -233,7 +234,8 @@ tree gfor_fndecl_cgemm;
tree gfor_fndecl_zgemm;
/* RANDOM_INIT function. */
-tree gfor_fndecl_random_init;
+tree gfor_fndecl_random_init; /* libgfortran, 1 image only. */
+tree gfor_fndecl_cas_random_init; /* Shared memory coarray. */
static void
gfc_add_decl_to_parent_function (tree decl)
@@ -3515,6 +3517,22 @@ gfc_build_intrinsic_function_decls (void)
void_type_node, 3, gfc_logical4_type_node, gfc_logical4_type_node,
gfc_int4_type_node);
+ // gfor_fndecl_caf_rand_init is defined in the lib-coarray section below.
+
+/* FIXME: This is a temporary workaround until someone that uses coarray
+ Fortran and random_init() can implement the OpenCoarray and/or the
+ shared memory routines. Both require communication between images, so
+ these routines cannot live in libgfortran. */
+#if 1
+ gfor_fndecl_cas_random_init = gfc_build_library_function_decl (
+ get_identifier (PREFIX("random_init_foobar")),
+ void_type_node, 2, gfc_logical4_type_node, gfc_logical4_type_node);
+#else
+ gfor_fndecl_cas_random_init = gfc_build_library_function_decl (
+ get_identifier (PREFIX("cas_random_init")),
+ void_type_node, 2, gfc_logical4_type_node, gfc_logical4_type_node);
+#endif
+
gfor_fndecl_sc_kind = gfc_build_library_function_decl_with_spec (
get_identifier (PREFIX("selected_char_kind")), ". . R ",
gfc_int4_type_node, 2, gfc_charlen_type_node, pchar_type_node);
@@ -4080,6 +4098,10 @@ gfc_build_builtin_function_decls (void)
get_identifier (PREFIX("caf_is_present")), ". r . r ",
integer_type_node, 3, pvoid_type_node, integer_type_node,
pvoid_type_node);
+
+ gfor_fndecl_caf_random_init = gfc_build_library_function_decl (
+ get_identifier (PREFIX("caf_random_init")),
+ void_type_node, 2, logical_type_node, logical_type_node);
}
gfc_build_intrinsic_function_decls ();
diff --git a/gcc/fortran/trans-intrinsic.c b/gcc/fortran/trans-intrinsic.c
index cceef8f34ac..8319e94b893 100644
--- a/gcc/fortran/trans-intrinsic.c
+++ b/gcc/fortran/trans-intrinsic.c
@@ -3827,38 +3827,50 @@ conv_intrinsic_random_init (gfc_code *code)
{
stmtblock_t block;
gfc_se se;
- tree arg1, arg2, arg3, tmp;
- tree logical4_type_node = gfc_get_logical_type (4);
+ tree arg1, arg2, tmp;
+ /* On none coarray == lib compiles use LOGICAL(4) else regular LOGICAL. */
+ tree used_bool_type_node = flag_coarray == GFC_FCOARRAY_LIB
+ ? logical_type_node
+ : gfc_get_logical_type (4);
/* Make the function call. */
gfc_init_block (&block);
gfc_init_se (&se, NULL);
- /* Convert REPEATABLE to a LOGICAL(4) entity. */
+ /* Convert REPEATABLE to the desired LOGICAL entity. */
gfc_conv_expr (&se, code->ext.actual->expr);
gfc_add_block_to_block (&block, &se.pre);
- arg1 = fold_convert (logical4_type_node, gfc_evaluate_now (se.expr, &block));
+ arg1 = fold_convert (used_bool_type_node, gfc_evaluate_now (s
[Patch, fortran] PR fortran/100245 - ICE on automatic reallocation
Hi All!
Proposed patch to:
PR100245 - ICE on automatic reallocation.
Patch tested only on x86_64-pc-linux-gnu.
Add an if clause for handling derived types in the left hand side.
Thank you very much.
Best regards,
José Rui
Fortran: Fix ICE with automatic reallocation [PR100136]
gcc/fortran/ChangeLog:
PR fortran/100245
* trans-expr.c (trans_class_assignment): Add if clause to handle
derived type in the LHS.
gcc/testsuite/ChangeLog:
PR fortran/100245
* gfortran.dg/PR100245.f90: New test.
diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
index 213f32b0a67..faced471918 100644
--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -10995,6 +10995,9 @@ trans_class_assignment (stmtblock_t *block, gfc_expr *lhs, gfc_expr *rhs,
class_han = GFC_CLASS_TYPE_P (TREE_TYPE (lse->expr))
? gfc_class_data_get (lse->expr) : lse->expr;
+ if (!POINTER_TYPE_P (TREE_TYPE (class_han)))
+ class_han = gfc_build_addr_expr (NULL_TREE, class_han);
+
/* Allocate block. */
gfc_init_block (&alloc);
gfc_allocate_using_malloc (&alloc, class_han, size, NULL_TREE);
diff --git a/gcc/testsuite/gfortran.dg/PR100245.f90 b/gcc/testsuite/gfortran.dg/PR100245.f90
new file mode 100644
index 000..1fc372a0d67
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/PR100245.f90
@@ -0,0 +1,29 @@
+! { dg-do run }
+!
+! Test the fix for PR100245
+!
+
+program main_p
+
+ implicit none
+
+ type :: foo_t
+integer :: a
+ end type foo_t
+
+ integer, parameter :: a = 42
+
+ class(foo_t), allocatable :: val
+ class(foo_t), allocatable :: rs1
+ type(foo_t), allocatable :: rs2
+
+ allocate(val, source=foo_t(42))
+ if (val%a/=a) stop 1
+ rs1 = val
+ if (rs1%a/=a) stop 2
+ rs2 = val
+ if (rs2%a/=a) stop 3
+ deallocate(val, rs1, rs2)
+ stop
+
+end program main_p
Re: [Patch, Fortran, Update] PR98301 Re: RANDOM_INIT() and coarray Fortran
On Sat, Apr 24, 2021 at 12:49:45PM +0200, Andre Vehreschild wrote: > > @Steve: Is this your correct mail address for the changelog or do you prefer a > different one? > I still have my ka...@gcc.gnu.org email address. Please use that one. I'll look over the combined patch later today. -- Steve
Re: [Patch, Fortran, Update] PR98301 Re: RANDOM_INIT() and coarray Fortran
Ok, I changed it in the log-file already. - Andre On Sat, 24 Apr 2021 08:44:24 -0700 Steve Kargl wrote: > On Sat, Apr 24, 2021 at 12:49:45PM +0200, Andre Vehreschild wrote: > > > > @Steve: Is this your correct mail address for the changelog or do you > > prefer a different one? > > > > I still have my ka...@gcc.gnu.org email address. Please use that one. > I'll look over the combined patch later today. > -- Dr. Andre Vehreschild Phone: +49 2234 2509627 +49 178 3837536 E-Mail: i...@badgersystems.de ve...@badgersystem.de WWW:www.badgersystems.de Badger Systems GmbH Firmensitz: Lessingstr. 26, 50858 Köln Registergericht: Amtsgericht Köln, HRB 89654 Umsatzsteuer-Identifikationsnummer: DE815667719 Geschäftsführer: Dr. Lexi Pimenidis
Re: [Patch] PR fortran/100154 - [9/10/11/12 Regression] ICE in gfc_conv_procedure_call, at fortran/trans-expr.c:6131
Hi Harald,
It looks good to me! Keep clear of 11-branch until release but OK for the
others.
Thanks
Paul
On Fri, 23 Apr 2021 at 00:18, Harald Anlauf via Fortran
wrote:
> Now with the correct patch attached ...
>
> Sorry for the confusion!
>
> ---
>
> Dear Fortranners,
>
> we need to check the arguments to the affected GNU intrinsic extensions
> properly, and - as pointed out in the PR by Tobias - we need to allow
> function references that have a data pointer result. Also the argument
> names of the character arguments of the subroutine versions needed a
> fix ("c" instead of "count").
>
> Regtested on x86_64-pc-linux-gnu. OK for mainline (12)?
> OK for backports after 11.1 release?
>
> Thanks,
> Harald
>
>
> PR fortran/100154 - ICE in gfc_conv_procedure_call, at
> fortran/trans-expr.c:6131
>
> Add appropriate static checks for the character and status arguments to
> the GNU Fortran intrinsic extensions fget[c], fput[c]. Extend variable
> check to allow a function reference having a data pointer result.
>
> gcc/fortran/ChangeLog:
>
> PR fortran/100154
> * check.c (variable_check): Allow function reference having a data
> pointer result.
> (arg_strlen_is_zero): New function.
> (gfc_check_fgetputc_sub): Add static check of character and status
> arguments.
> (gfc_check_fgetput_sub): Likewise.
> * intrinsic.c (add_subroutines): Fix argument name for the
> character argument to intrinsic subroutines fget[c], fput[c].
>
> gcc/testsuite/ChangeLog:
>
> PR fortran/100154
> * gfortran.dg/pr100154.f90: New test.
>
>
--
"If you can't explain it simply, you don't understand it well enough" -
Albert Einstein
Re: [Patch] PR fortran/100218 - target of pointer from evaluation of function-reference
Hi Harald, Another good one - OK for master but wait a while for 11-branch. I am a bit hesitant about 10-branch because this is not a regression. That said, this is harmless because it is permissive, so I will leave it to you to decide. Is there a test for an error with -std=f2003? If not, you should, perhaps, include one. Thanks Paul On Thu, 22 Apr 2021 at 23:37, Harald Anlauf via Fortran wrote: > Dear Fortranners, > > while analyzing a different PR (PR100154), Tobias pointed out that the > target of a pointer from the evaluation of function-reference is allowed > to be used in a variable definition context and thus as an actual > argument to a function or subroutine. > > This seems to be a more general issue that seems to have been overlooked. > The attached simple patch allows to compile and run the attached example, > which is by the way already yet rejected with -std=f2003. > > Regtested on x86_64-pc-linux-gnu. OK for mainline? > Shall we backport this to (at least) 11? > > Thanks, > Harald > > > Fortran - allow target of pointer from evaluation of function-reference > > Fortran allows the target of a pointer from the evaluation of a > function-reference in a variable definition context (e.g. F2018:R902). > > gcc/fortran/ChangeLog: > > PR fortran/100218 > * expr.c (gfc_check_vardef_context): Extend check to allow pointer > from a function reference. > > gcc/testsuite/ChangeLog: > > PR fortran/100218 > * gfortran.dg/pr100218.f90: New test. > > -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
Re: [Patch] PR fortran/100218 - target of pointer from evaluation of function-reference
Hi Paul, > Is there a test for an error with -std=f2003? If not, you should, perhaps, > include one. after checking for the corresponding error message, I found that ptr-func-2.f90 already covers this case. Considering this, I'll rename the current testcase from pr100218.f90 to ptr-func-4.f90. Thanks for the review! Harald
