Re: [PATCH] tree-optimization/111779 - Handle some BIT_FIELD_REFs in SRA
; > +__builtin_abort ();
> > +}
> > +
> > +int
> > +main ()
> > +{
> > + struct A x[100];
> > + int i;
> > +
> > + check_vect ();
> > +
> > + __builtin_memset (x, -1, sizeof (x));
> > +#pragma GCC novect
> > + for (i = 0; i < 100; i++)
> > +{
> > + x[i].b1 = false;
> > + x[i].b2 = false;
> > + x[i].b3 = false;
> > + x[i].b4.f = false;
> > +}
> > + foo (x, 100);
> > + return 0;
> > +}
> > +
> > +/* { dg-final { scan-tree-dump "LOOP VECTORIZED" "vect" { target vect_int
> > } } } */ diff --git a/gcc/tree-sra.cc b/gcc/tree-sra.cc
> > index 56a8ba26135..24d0c20da6a 100644
> > --- a/gcc/tree-sra.cc
> > +++ b/gcc/tree-sra.cc
> > @@ -1113,6 +1113,21 @@ disqualify_base_of_expr (tree t, const char *reason)
> > disqualify_candidate (t, reason);
> > }
> >
> > +/* Return true if the BIT_FIELD_REF read EXPR is handled by SRA. */
> > +
> > +static bool
> > +sra_handled_bf_read_p (tree expr)
> > +{
> > + uint64_t size, offset;
> > + if (bit_field_size (expr).is_constant ()
> > + && bit_field_offset (expr).is_constant ()
> > + && size % BITS_PER_UNIT == 0
> > + && offset % BITS_PER_UNIT == 0
> > + && pow2p_hwi (size))
> > +return true;
> > + return false;
> > +}
> > +
> > /* Scan expression EXPR and create access structures for all accesses to
> > candidates for scalarization. Return the created access or NULL if
> > none is created. */
> > @@ -1123,7 +1138,8 @@ build_access_from_expr_1 (tree expr, gimple *stmt,
> > bool write) struct access *ret = NULL;
> >bool partial_ref;
> >
> > - if (TREE_CODE (expr) == BIT_FIELD_REF
> > + if ((TREE_CODE (expr) == BIT_FIELD_REF
> > + && (write || !sra_handled_bf_read_p (expr)))
> >|| TREE_CODE (expr) == IMAGPART_EXPR
> >|| TREE_CODE (expr) == REALPART_EXPR)
> > {
> > @@ -1170,6 +1186,7 @@ build_access_from_expr_1 (tree expr, gimple *stmt,
> > bool write) case COMPONENT_REF:
> > case ARRAY_REF:
> > case ARRAY_RANGE_REF:
> > +case BIT_FIELD_REF:
> >ret = create_access (expr, stmt, write);
> >break;
> >
> > @@ -1549,6 +1566,7 @@ make_fancy_name_1 (tree expr)
> >obstack_grow (_obstack, buffer, strlen (buffer));
> >break;
> >
> > +case BIT_FIELD_REF:
> > case ADDR_EXPR:
> >make_fancy_name_1 (TREE_OPERAND (expr, 0));
> >break;
> > @@ -1564,7 +1582,6 @@ make_fancy_name_1 (tree expr)
> > }
> >break;
> >
> > -case BIT_FIELD_REF:
> > case REALPART_EXPR:
> > case IMAGPART_EXPR:
> >gcc_unreachable (); /* we treat these as scalars. */
> > @@ -3769,7 +3786,8 @@ sra_modify_expr (tree *expr, gimple_stmt_iterator
> > *gsi, bool write) tree type, bfr, orig_expr;
> >bool partial_cplx_access = false;
> >
> > - if (TREE_CODE (*expr) == BIT_FIELD_REF)
> > + if (TREE_CODE (*expr) == BIT_FIELD_REF
> > + && (write || !sra_handled_bf_read_p (*expr)))
> > {
> >bfr = *expr;
> >expr = _OPERAND (*expr, 0);
> >
>
--
Andre Vehreschild * Email: vehre ad gmx dot de
Re: [Fortran, Patch, Coarray, PR 37336] Fix crash in finalizer when derived type coarray is already freed.
Hi all, back porting to gcc-13 unfortunately caused a regression due to gfc_deallocate_with_status() having a different parameter count. This is fixed as obvious by 874b895fffd921659b37dc05bc94eea48e9a0157. Sorry for breaking gfortran-13. I still don't know why it checkout fine on my system in the beginning. I must have done something wrong. Please accept my apologies and regards, Andre On Fri, 29 Sep 2023 15:13:56 +0200 Andre Vehreschild via Fortran wrote: > Hi Paul, > > thanks. Commit to trunk as a680274616ec6b26ccfdcee400ed7f54e341d40c > and backported to gcc-13 as d9b3269bdccac2db9200303494c4e82f2aeb7bbc > > Thanks for the fast review. > > Regards, > Andre > > On Fri, 29 Sep 2023 13:38:57 +0100 > Paul Richard Thomas wrote: > > > Hi Andre, > > > > Yes indeed - it's fine for trunk and, I would suggest, 13-branch. > > > > Cheers > > > > Paul > > > > On Fri, 29 Sept 2023 at 11:01, Andre Vehreschild wrote: > > > > > > Hi Paul, > > > > > > thanks for the quick review. I've added a testcase with a module and a > > > finalizer in the derived type. This also is no problem. > > > > > > Regtests ok on x86_64_linux_gnu/f37. Ok for trunk? > > > > > > Regards, > > > Andre > > > > > > On Thu, 28 Sep 2023 19:21:12 +0100 > > > Paul Richard Thomas wrote: > > > > > > > Hi Andre, > > > > > > > > The patch looks fine to me. Since you mention it in the comment, is it > > > > worth declaring the derived type 'foo' in a module and giving it a > > > > final routine? > > > > > > > > Thanks for the patch. > > > > > > > > Paul > > > > > > > > On Thu, 28 Sept 2023 at 13:45, Andre Vehreschild via Fortran > > > > wrote: > > > > > > > > > > Hi all, > > > > > > > > > > attached patch fixes a crash in coarray programs when an allocatable > > > > > derived typed coarray was freed explicitly. The generated cleanup code > > > > > did not take into account, that the coarray may have been deallocated > > > > > already. The patch fixes this by moving the statements accessing > > > > > components inside the derived type into the block guard by its > > > > > allocated check. > > > > > > > > > > Regtested ok on f37/x86_64. Ok for master? > > > > > > > > > > Regards, > > > > > Andre > > > > > -- > > > > > Andre Vehreschild * Email: vehre ad gmx dot de > > > > > > > > > -- > > > Andre Vehreschild * Email: vehre ad gmx dot de > > > -- > Andre Vehreschild * Email: vehre ad gmx dot de -- Andre Vehreschild * Email: vehre ad gmx dot de
Re: [Fortran, Patch, Coarray, PR 37336] Fix crash in finalizer when derived type coarray is already freed.
Hi Paul, thanks. Commit to trunk as a680274616ec6b26ccfdcee400ed7f54e341d40c and backported to gcc-13 as d9b3269bdccac2db9200303494c4e82f2aeb7bbc Thanks for the fast review. Regards, Andre On Fri, 29 Sep 2023 13:38:57 +0100 Paul Richard Thomas wrote: > Hi Andre, > > Yes indeed - it's fine for trunk and, I would suggest, 13-branch. > > Cheers > > Paul > > On Fri, 29 Sept 2023 at 11:01, Andre Vehreschild wrote: > > > > Hi Paul, > > > > thanks for the quick review. I've added a testcase with a module and a > > finalizer in the derived type. This also is no problem. > > > > Regtests ok on x86_64_linux_gnu/f37. Ok for trunk? > > > > Regards, > > Andre > > > > On Thu, 28 Sep 2023 19:21:12 +0100 > > Paul Richard Thomas wrote: > > > > > Hi Andre, > > > > > > The patch looks fine to me. Since you mention it in the comment, is it > > > worth declaring the derived type 'foo' in a module and giving it a > > > final routine? > > > > > > Thanks for the patch. > > > > > > Paul > > > > > > On Thu, 28 Sept 2023 at 13:45, Andre Vehreschild via Fortran > > > wrote: > > > > > > > > Hi all, > > > > > > > > attached patch fixes a crash in coarray programs when an allocatable > > > > derived typed coarray was freed explicitly. The generated cleanup code > > > > did not take into account, that the coarray may have been deallocated > > > > already. The patch fixes this by moving the statements accessing > > > > components inside the derived type into the block guard by its > > > > allocated check. > > > > > > > > Regtested ok on f37/x86_64. Ok for master? > > > > > > > > Regards, > > > > Andre > > > > -- > > > > Andre Vehreschild * Email: vehre ad gmx dot de > > > > > > -- > > Andre Vehreschild * Email: vehre ad gmx dot de -- Andre Vehreschild * Email: vehre ad gmx dot de
Re: [Fortran, Patch, Coarray, PR 37336] Fix crash in finalizer when derived type coarray is already freed.
Hi Paul,
thanks for the quick review. I've added a testcase with a module and a
finalizer in the derived type. This also is no problem.
Regtests ok on x86_64_linux_gnu/f37. Ok for trunk?
Regards,
Andre
On Thu, 28 Sep 2023 19:21:12 +0100
Paul Richard Thomas wrote:
> Hi Andre,
>
> The patch looks fine to me. Since you mention it in the comment, is it
> worth declaring the derived type 'foo' in a module and giving it a
> final routine?
>
> Thanks for the patch.
>
> Paul
>
> On Thu, 28 Sept 2023 at 13:45, Andre Vehreschild via Fortran
> wrote:
> >
> > Hi all,
> >
> > attached patch fixes a crash in coarray programs when an allocatable derived
> > typed coarray was freed explicitly. The generated cleanup code did not take
> > into account, that the coarray may have been deallocated already. The patch
> > fixes this by moving the statements accessing components inside the derived
> > type into the block guard by its allocated check.
> >
> > Regtested ok on f37/x86_64. Ok for master?
> >
> > Regards,
> > Andre
> > --
> > Andre Vehreschild * Email: vehre ad gmx dot de
--
Andre Vehreschild * Email: vehre ad gmx dot de
diff --git a/gcc/fortran/trans-array.cc b/gcc/fortran/trans-array.cc
index e0fc8ebc46b..8e94a9a469f 100644
--- a/gcc/fortran/trans-array.cc
+++ b/gcc/fortran/trans-array.cc
@@ -9320,6 +9320,12 @@ structure_alloc_comps (gfc_symbol * der_type, tree decl, tree dest,
gfc_add_expr_to_block (, tmp);
}
+ /* Still having a descriptor array of rank == 0 here, indicates an
+ allocatable coarrays. Dereference it correctly. */
+ if (GFC_DESCRIPTOR_TYPE_P (decl_type))
+{
+ decl = build_fold_indirect_ref (gfc_conv_array_data (decl));
+}
/* Otherwise, act on the components or recursively call self to
act on a chain of components. */
for (c = der_type->components; c; c = c->next)
@@ -11507,7 +11513,11 @@ gfc_trans_deferred_array (gfc_symbol * sym, gfc_wrapped_block * block)
{
int rank;
rank = sym->as ? sym->as->rank : 0;
- tmp = gfc_deallocate_alloc_comp (sym->ts.u.derived, descriptor, rank);
+ tmp = gfc_deallocate_alloc_comp (sym->ts.u.derived, descriptor, rank,
+ (sym->attr.codimension
+ && flag_coarray == GFC_FCOARRAY_LIB)
+ ? GFC_STRUCTURE_CAF_MODE_IN_COARRAY
+ : 0);
gfc_add_expr_to_block (, tmp);
}
@@ -11521,9 +11531,11 @@ gfc_trans_deferred_array (gfc_symbol * sym, gfc_wrapped_block * block)
NULL_TREE, NULL_TREE, true, e,
sym->attr.codimension
? GFC_CAF_COARRAY_DEREGISTER
- : GFC_CAF_COARRAY_NOCOARRAY);
+ : GFC_CAF_COARRAY_NOCOARRAY,
+ NULL_TREE, gfc_finish_block ());
if (e)
gfc_free_expr (e);
+ gfc_init_block ();
gfc_add_expr_to_block (, tmp);
}
diff --git a/gcc/testsuite/gfortran.dg/coarray/alloc_comp_6.f90 b/gcc/testsuite/gfortran.dg/coarray/alloc_comp_6.f90
new file mode 100644
index 000..e8a74db2c18
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/coarray/alloc_comp_6.f90
@@ -0,0 +1,29 @@
+! { dg-do run }
+
+program alloc_comp_6
+
+ implicit none
+
+ type :: foo
+real :: x
+integer, allocatable :: y(:)
+ end type
+
+ call check()
+
+contains
+
+ subroutine check()
+block
+ type(foo), allocatable :: example[:] ! needs to be a coarray
+
+ allocate(example[*])
+ allocate(example%y(10))
+ example%x = 3.4
+ example%y = 4
+
+ deallocate(example)
+end block ! example%y shall not be accessed here by the finalizer,
+ ! because example is already deallocated
+ end subroutine check
+end program alloc_comp_6
diff --git a/gcc/testsuite/gfortran.dg/coarray/alloc_comp_7.f90 b/gcc/testsuite/gfortran.dg/coarray/alloc_comp_7.f90
new file mode 100644
index 000..5ebd31f3df7
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/coarray/alloc_comp_7.f90
@@ -0,0 +1,49 @@
+! { dg-do run }
+
+module alloc_comp_module_7
+
+ public :: check
+
+ type :: foo
+real :: x
+integer, allocatable :: y(:)
+ contains
+final :: foo_final
+ end type
+
+contains
+
+ subroutine foo_final(f)
+type(foo), intent(inout) :: f
+
+if (allocated(f%y)) then
+ f%y = -1
+end if
+ end subroutine foo_final
+
+ subroutine check()
+block
+ type(foo), allocatable :: example[:] ! needs to be a coarray
+
+ allocate(example[*])
+ allocate(example%y(10))
+ example%x = 3.4
+ example%y = 4
+
+ deallocate(example%y)
+ deallocate(example)
+end block ! example%y shall not be accessed here by the finalizer,
+ ! because example is already deallocated
+ end subroutine check
+end module alloc_comp_module_7
+
+program alloc_comp_7
+
+ use alloc_comp_module_7, only: check
+
+ implicit none
+
+ call check()
+
+end program alloc_comp_7
+
For
[Fortran, Patch, Coarray, PR 37336] Fix crash in finalizer when derived type coarray is already freed.
Hi all,
attached patch fixes a crash in coarray programs when an allocatable derived
typed coarray was freed explicitly. The generated cleanup code did not take
into account, that the coarray may have been deallocated already. The patch
fixes this by moving the statements accessing components inside the derived type
into the block guard by its allocated check.
Regtested ok on f37/x86_64. Ok for master?
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
diff --git a/gcc/fortran/trans-array.cc b/gcc/fortran/trans-array.cc
index e0fc8ebc46b..8e94a9a469f 100644
--- a/gcc/fortran/trans-array.cc
+++ b/gcc/fortran/trans-array.cc
@@ -9320,6 +9320,12 @@ structure_alloc_comps (gfc_symbol * der_type, tree decl, tree dest,
gfc_add_expr_to_block (, tmp);
}
+ /* Still having a descriptor array of rank == 0 here, indicates an
+ allocatable coarrays. Dereference it correctly. */
+ if (GFC_DESCRIPTOR_TYPE_P (decl_type))
+{
+ decl = build_fold_indirect_ref (gfc_conv_array_data (decl));
+}
/* Otherwise, act on the components or recursively call self to
act on a chain of components. */
for (c = der_type->components; c; c = c->next)
@@ -11507,7 +11513,11 @@ gfc_trans_deferred_array (gfc_symbol * sym, gfc_wrapped_block * block)
{
int rank;
rank = sym->as ? sym->as->rank : 0;
- tmp = gfc_deallocate_alloc_comp (sym->ts.u.derived, descriptor, rank);
+ tmp = gfc_deallocate_alloc_comp (sym->ts.u.derived, descriptor, rank,
+ (sym->attr.codimension
+ && flag_coarray == GFC_FCOARRAY_LIB)
+ ? GFC_STRUCTURE_CAF_MODE_IN_COARRAY
+ : 0);
gfc_add_expr_to_block (, tmp);
}
@@ -11521,9 +11531,11 @@ gfc_trans_deferred_array (gfc_symbol * sym, gfc_wrapped_block * block)
NULL_TREE, NULL_TREE, true, e,
sym->attr.codimension
? GFC_CAF_COARRAY_DEREGISTER
- : GFC_CAF_COARRAY_NOCOARRAY);
+ : GFC_CAF_COARRAY_NOCOARRAY,
+ NULL_TREE, gfc_finish_block ());
if (e)
gfc_free_expr (e);
+ gfc_init_block ();
gfc_add_expr_to_block (, tmp);
}
diff --git a/gcc/testsuite/gfortran.dg/coarray/alloc_comp_6.f90 b/gcc/testsuite/gfortran.dg/coarray/alloc_comp_6.f90
new file mode 100644
index 000..e8a74db2c18
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/coarray/alloc_comp_6.f90
@@ -0,0 +1,29 @@
+! { dg-do run }
+
+program alloc_comp_6
+
+ implicit none
+
+ type :: foo
+real :: x
+integer, allocatable :: y(:)
+ end type
+
+ call check()
+
+contains
+
+ subroutine check()
+block
+ type(foo), allocatable :: example[:] ! needs to be a coarray
+
+ allocate(example[*])
+ allocate(example%y(10))
+ example%x = 3.4
+ example%y = 4
+
+ deallocate(example)
+end block ! example%y shall not be accessed here by the finalizer,
+ ! because example is already deallocated
+ end subroutine check
+end program alloc_comp_6
Fortran: Free alloc. comp. in allocated coarrays only.
When freeing allocatable components of an allocatable coarray, add
a check that the coarray is still allocated, before accessing the
components.
This patch adds to PR fortran/37336, but does not fix it completely.
gcc/fortran/ChangeLog:
PR fortran/37336
* trans-array.cc (structure_alloc_comps): Deref coarray.
(gfc_trans_deferred_array): Add freeing of components after
check for allocated coarray.
gcc/testsuite/ChangeLog:
PR fortran/37336
* gfortran.dg/coarray/alloc_comp_6.f90: New test.
Re: [Patch, Fortran, committed] Allow ref'ing PDT's len() in parameter-initializer [PR102003]
Hi all, hi Harald,
thanks for the review. I choose to use gfc_replace_expr() and retested.
Everything went fine now.
Also thank you clarifying the pdt as a component in a derived type and that
that is still a bug and I didn't do it wrong.
I have pushed the attached patch seconds ago.
Thanks for your help,
Andre
On Tue, 11 Jul 2023 22:24:37 +0200
Harald Anlauf wrote:
> Hi Andre,
>
> this looks much better now!
>
> This looks mostly good to me, except for a typo in the testcase:
>
> + if (p% ci% len /= 42) stop 4
>
> There is no component "ci", only "c". The testsuite would fail.
>
> Regarding the memleak: replacing
>
>// TODO: Fix leaking expr tmp, when simplify is done twice.
>tmp = gfc_copy_expr (*newp);
>
> by
>
>if (inquiry->next)
> {
> gfc_free_expr (tmp);
> tmp = gfc_copy_expr (*newp);
> }
>
> or rather
>
>if (inquiry->next)
> gfc_replace_expr (tmp, *newp);
>
> at least shrinks the leak a bit. (Untested otherwise).
>
> OK with one of the above changes (provided it survives regtesting).
>
> Thanks for the patch!
>
> Harald
>
>
> Am 11.07.23 um 18:23 schrieb Andre Vehreschild via Gcc-patches:
> > Hi Harald,
> >
> > attached is a new version of the patch. This now also respects inquiry-LEN.
> > Btw, there is a potential memory leak in the simplify for inquiry
> > functions. I have added a note into the code.
> >
> > I tried to use a pdt within a derived type as a component. Is that not
> > allowed by the standard? I know, I could hunt in the standard for it, but
> > when someone knows out of his head, he could greatly help me out.
> >
> > Regtests ok on x86_64-linux-gnu/F37.
> >
> > Regards,
> > Andre
> >
> > On Mon, 10 Jul 2023 20:55:29 +0200
> > Harald Anlauf wrote:
> >
> >> Hi Andre,
> >>
> >> thanks for looking into this!
> >>
> >> While it fixes the original PR, here is a minor extension of the
> >> testcase that ICEs here with your patch:
> >>
> >> program pr102003
> >> type pdt(n)
> >>integer, len :: n = 8
> >>character(len=n) :: c
> >> end type pdt
> >> type(pdt(42)) :: p
> >> integer, parameter :: m = len (p% c)
> >> integer, parameter :: n = p% c% len
> >>
> >> if (m /= 42) stop 1
> >> if (len (p% c) /= 42) stop 2
> >> print *, p% c% len ! OK
> >> if (p% c% len /= 42) stop 3 ! OK
> >> print *, n ! ICE
> >> end
> >>
> >> I get:
> >>
> >> pdt_33.f03:14:27:
> >>
> >> 14 | integer, parameter :: n = p% c% len
> >> | 1
> >> Error: non-constant initialization expression at (1)
> >> pdt_33.f03:20:31:
> >>
> >> 20 | print *, n ! ICE
> >> | 1
> >> internal compiler error: tree check: expected record_type or union_type
> >> or qual_union_type, have integer_type in gfc_conv_component_ref, at
> >> fortran/trans-expr.cc:2757
> >> 0x84286c tree_check_failed(tree_node const*, char const*, int, char
> >> const*, ...)
> >> ../../gcc-trunk/gcc/tree.cc:8899
> >> 0xa6d6fb tree_check3(tree_node*, char const*, int, char const*,
> >> tree_code, tree_code, tree_code)
> >> ../../gcc-trunk/gcc/tree.h:3617
> >> 0xa90847 gfc_conv_component_ref(gfc_se*, gfc_ref*)
> >> ../../gcc-trunk/gcc/fortran/trans-expr.cc:2757
> >> 0xa91bbc gfc_conv_variable
> >> ../../gcc-trunk/gcc/fortran/trans-expr.cc:3137
> >> 0xaa8e9c gfc_conv_expr(gfc_se*, gfc_expr*)
> >> ../../gcc-trunk/gcc/fortran/trans-expr.cc:9594
> >> 0xaa92ae gfc_conv_expr_reference(gfc_se*, gfc_expr*)
> >> ../../gcc-trunk/gcc/fortran/trans-expr.cc:9713
> >> 0xad67f6 gfc_trans_transfer(gfc_code*)
> >> ../../gcc-trunk/gcc/fortran/trans-io.cc:2607
> >> 0xa43cb7 trans_code
> >> ../../gcc-trunk/gcc/fortran/trans.cc:2449
> >> 0xad37c6 build_dt
> >> ../../gcc-trunk/gcc/fortran/trans-io.cc:2051
> >> 0xa43cd7 trans_code
> >> ../../gcc-trunk/gcc/fortran/trans.cc:2421
> >> 0xa84711 gfc_generate_function_code(gfc_namespace*)
> >> ../../gcc-trunk/gcc/fortran/trans-decl.cc:7762
> >> 0x9d9ca7 translate_all_pro
Re: [Patch, Fortran] Allow ref'ing PDT's len() in parameter-initializer [PR102003]
Hi Harald, attached is a new version of the patch. This now also respects inquiry-LEN. Btw, there is a potential memory leak in the simplify for inquiry functions. I have added a note into the code. I tried to use a pdt within a derived type as a component. Is that not allowed by the standard? I know, I could hunt in the standard for it, but when someone knows out of his head, he could greatly help me out. Regtests ok on x86_64-linux-gnu/F37. Regards, Andre On Mon, 10 Jul 2023 20:55:29 +0200 Harald Anlauf wrote: > Hi Andre, > > thanks for looking into this! > > While it fixes the original PR, here is a minor extension of the > testcase that ICEs here with your patch: > > program pr102003 >type pdt(n) > integer, len :: n = 8 > character(len=n) :: c >end type pdt >type(pdt(42)) :: p >integer, parameter :: m = len (p% c) >integer, parameter :: n = p% c% len > >if (m /= 42) stop 1 >if (len (p% c) /= 42) stop 2 >print *, p% c% len ! OK >if (p% c% len /= 42) stop 3 ! OK >print *, n ! ICE > end > > I get: > > pdt_33.f03:14:27: > > 14 | integer, parameter :: n = p% c% len >| 1 > Error: non-constant initialization expression at (1) > pdt_33.f03:20:31: > > 20 | print *, n ! ICE >| 1 > internal compiler error: tree check: expected record_type or union_type > or qual_union_type, have integer_type in gfc_conv_component_ref, at > fortran/trans-expr.cc:2757 > 0x84286c tree_check_failed(tree_node const*, char const*, int, char > const*, ...) > ../../gcc-trunk/gcc/tree.cc:8899 > 0xa6d6fb tree_check3(tree_node*, char const*, int, char const*, > tree_code, tree_code, tree_code) > ../../gcc-trunk/gcc/tree.h:3617 > 0xa90847 gfc_conv_component_ref(gfc_se*, gfc_ref*) > ../../gcc-trunk/gcc/fortran/trans-expr.cc:2757 > 0xa91bbc gfc_conv_variable > ../../gcc-trunk/gcc/fortran/trans-expr.cc:3137 > 0xaa8e9c gfc_conv_expr(gfc_se*, gfc_expr*) > ../../gcc-trunk/gcc/fortran/trans-expr.cc:9594 > 0xaa92ae gfc_conv_expr_reference(gfc_se*, gfc_expr*) > ../../gcc-trunk/gcc/fortran/trans-expr.cc:9713 > 0xad67f6 gfc_trans_transfer(gfc_code*) > ../../gcc-trunk/gcc/fortran/trans-io.cc:2607 > 0xa43cb7 trans_code > ../../gcc-trunk/gcc/fortran/trans.cc:2449 > 0xad37c6 build_dt > ../../gcc-trunk/gcc/fortran/trans-io.cc:2051 > 0xa43cd7 trans_code > ../../gcc-trunk/gcc/fortran/trans.cc:2421 > 0xa84711 gfc_generate_function_code(gfc_namespace*) > ../../gcc-trunk/gcc/fortran/trans-decl.cc:7762 > 0x9d9ca7 translate_all_program_units > ../../gcc-trunk/gcc/fortran/parse.cc:6929 > 0x9d9ca7 gfc_parse_file() > ../../gcc-trunk/gcc/fortran/parse.cc:7235 > 0xa40a1f gfc_be_parse_file > ../../gcc-trunk/gcc/fortran/f95-lang.cc:229 > > The fortran-dump confirms that n is not simplified to a constant. > So while you're at it, do you also see a solution to this variant? > > Harald > > > Am 10.07.23 um 17:48 schrieb Andre Vehreschild via Gcc-patches: > > Hi all, > > > > while browsing the pdt meta-bug I came across 102003 and thought to myself: > > Well, that one is easy. How foolish of me... > > > > Anyway, the solution attached prevents a pdt_len (or pdt_kind) expression > > in a function call (e.g. len() or kind()) to mark the whole expression as a > > pdt one. The second part of the patch in simplify.cc then takes care of > > either generating the correct component ref or when a constant expression > > (i.e. gfc_init_expr_flag is set) is required to look this up from the > > actual symbol (not from the type, because there the default value is > > stored). > > > > Regtested ok on x86_64-linux-gnu/Fedora 37. > > > > Regards, > > Andre > > -- > > Andre Vehreschild * Email: vehre ad gmx dot de > -- Andre Vehreschild * Email: vehre ad gmx dot de gcc/fortran/ChangeLog: * expr.cc (find_inquiry_ref): Replace len of pdt_string by constant. (gfc_match_init_expr): Prevent PDT analysis for function calls. (gfc_pdt_find_component_copy_initializer): Get the initializer value for given component. * gfortran.h (gfc_pdt_find_component_copy_initializer): New function. * simplify.cc (gfc_simplify_len): Replace len() of PDT with pdt component ref or constant. gcc/testsuite/ChangeLog: * gfortran.dg/pdt_33.f03: New test. diff --git a/gcc/fortran/expr.cc b/gcc/fortran/expr.cc index e418f1f3301..23324517ff2 100644 --- a/gcc/fortran/expr.
Re: [Patch, Fortran] Allow ref'ing PDT's len() in parameter-initializer [PR102003]
Hi Harald, I do get why this happens. I still don't get why I have to do this 'optimization' manually. I mean, this rewriting of expressions is needed in more than one location and most probably already present somewhere. So who can point me in the right direction? Regards, Andre Andre Vehreschild
[Patch, Fortran] Allow ref'ing PDT's len() in parameter-initializer [PR102003]
Hi all,
while browsing the pdt meta-bug I came across 102003 and thought to myself:
Well, that one is easy. How foolish of me...
Anyway, the solution attached prevents a pdt_len (or pdt_kind) expression in a
function call (e.g. len() or kind()) to mark the whole expression as a pdt one.
The second part of the patch in simplify.cc then takes care of either generating
the correct component ref or when a constant expression (i.e.
gfc_init_expr_flag is set) is required to look this up from the actual symbol
(not from the type, because there the default value is stored).
Regtested ok on x86_64-linux-gnu/Fedora 37.
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
gcc/fortran/ChangeLog:
* expr.cc (gfc_match_init_expr): Prevent PDT analysis for function
calls.
* simplify.cc (gfc_simplify_len): Replace len() of PDT with pdt
component ref or constant.
gcc/testsuite/ChangeLog:
* gfortran.dg/pdt_33.f03: New test.
diff --git a/gcc/fortran/expr.cc b/gcc/fortran/expr.cc
index e418f1f3301..fb6eb76cda7 100644
--- a/gcc/fortran/expr.cc
+++ b/gcc/fortran/expr.cc
@@ -3229,7 +3229,7 @@ gfc_match_init_expr (gfc_expr **result)
return m;
}
- if (gfc_derived_parameter_expr (expr))
+ if (expr->expr_type != EXPR_FUNCTION && gfc_derived_parameter_expr (expr))
{
*result = expr;
gfc_init_expr_flag = false;
diff --git a/gcc/fortran/simplify.cc b/gcc/fortran/simplify.cc
index 81680117f70..8fb453d0a54 100644
--- a/gcc/fortran/simplify.cc
+++ b/gcc/fortran/simplify.cc
@@ -4580,19 +4580,54 @@ gfc_simplify_len (gfc_expr *e, gfc_expr *kind)
return range_check (result, "LEN");
}
else if (e->expr_type == EXPR_VARIABLE && e->ts.type == BT_CHARACTER
- && e->symtree->n.sym
- && e->symtree->n.sym->ts.type != BT_DERIVED
- && e->symtree->n.sym->assoc && e->symtree->n.sym->assoc->target
- && e->symtree->n.sym->assoc->target->ts.type == BT_DERIVED
- && e->symtree->n.sym->assoc->target->symtree->n.sym
- && UNLIMITED_POLY (e->symtree->n.sym->assoc->target->symtree->n.sym))
-
-/* The expression in assoc->target points to a ref to the _data component
- of the unlimited polymorphic entity. To get the _len component the last
- _data ref needs to be stripped and a ref to the _len component added. */
-return gfc_get_len_component (e->symtree->n.sym->assoc->target, k);
- else
-return NULL;
+ && e->symtree->n.sym)
+{
+ if (e->symtree->n.sym->ts.type != BT_DERIVED
+ && e->symtree->n.sym->assoc && e->symtree->n.sym->assoc->target
+ && e->symtree->n.sym->assoc->target->ts.type == BT_DERIVED
+ && e->symtree->n.sym->assoc->target->symtree->n.sym
+ && UNLIMITED_POLY (e->symtree->n.sym->assoc->target->symtree
+->n.sym))
+ /* The expression in assoc->target points to a ref to the _data
+ component of the unlimited polymorphic entity. To get the _len
+ component the last _data ref needs to be stripped and a ref to the
+ _len component added. */
+ return gfc_get_len_component (e->symtree->n.sym->assoc->target, k);
+ else if (e->symtree->n.sym->ts.type == BT_DERIVED
+ && e->ref && e->ref->type == REF_COMPONENT
+ && e->ref->u.c.component->attr.pdt_string
+ && e->ref->u.c.component->ts.type == BT_CHARACTER
+ && e->ref->u.c.component->ts.u.cl->length)
+ {
+ if (gfc_init_expr_flag)
+ {
+ /* The actual length of a pdt is in its components. In the
+ initializer of the current ref is only the default value.
+ Therefore traverse the chain of components and pick the correct
+ one's initializer expressions. */
+ for (gfc_component *comp = e->symtree->n.sym->ts.u.derived
+ ->components; comp != NULL; comp = comp->next)
+ {
+ if (!strcmp (comp->name, e->ref->u.c.component->ts.u.cl
+ ->length->symtree->name))
+ return gfc_copy_expr (comp->initializer);
+ }
+ }
+ else
+ {
+ gfc_expr *len_expr = gfc_copy_expr (e);
+ gfc_free_ref_list (len_expr->ref);
+ len_expr->ref = NULL;
+ gfc_find_component (len_expr->symtree->n.sym->ts.u.derived, e->ref
+ ->u.c.component->ts.u.cl->length->symtree
+ ->name,
+ false, true, _expr->ref);
+ len_expr->ts = len_expr->ref->u.c.component->ts;
+ return len_expr;
+ }
+ }
+}
+ return NULL;
}
diff --git a/gcc/testsuite/gfortran.dg/pdt_33.f03 b/gcc/testsuite/gfortran.dg/pdt_33.f03
new file mode 100644
index 000..c12bd9b411c
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pdt_33.f03
@@ -0,0 +1,18 @@
+! { dg-do run }
+!
+! Test the fix for PR102003, where len parameters where not returned as constants.
+!
+! Contributed by Harald Anlauf
+!
+program pr102003
+ type pdt(n)
+ integer, len :: n = 8
+ character(len=n) :: c
+ end type pdt
+ type(pdt(42)) :: p
+ integer, parameter :: m = len (p% c)
+
+ if (m /= 42) stop 1
+ if (len (p% c) /= 42) stop 2
+end
+
Re: [Backport gcc-11, Patch, Fortran] PR100337 Should be able to pass non-present optional arguments to CO_BROADCAST
Hi everyone, sorry for missing out on the gcc-11 backport, but better late than never. Committed backport as ae57aae60d1. Regards, Andre On Wed, 23 Jun 2021 11:21:45 +0200 Tobias Burnus wrote: > On 23.06.21 10:23, Andre Vehreschild wrote: > > > Will wait two weeks for any errors introduced by this patch before > > backporting to gcc-11, ok? > > Fine with me. > > Thanks again for the patch. > > Tobias > > - > Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München > Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Frank > Thürauf -- Andre Vehreschild * Email: vehre ad gmx dot de
Re: [Backport, committed, PR103970, Fortran, Coarray] Multi-image co_broadcast of derived type with allocatable components fails^
Hi all, two weeks have passed with no complains about the patch for PR103970. Therefore backported and pushed to gcc-11 as 680ee9c3332. Regards, Andre On Fri, 28 Jan 2022 12:39:17 +0100 Andre Vehreschild wrote: > Hi Tobias, > > I don't know why that bootstrapped initially. I fixed the patch (naming a > ``` > else > /* Prevent warning. */ > cdesc = NULL_TREE; > ``` > obvious) and rerun bootstrap making sure to purge everything beforehand. It > did not break bootstrap on x86_64-linux/f35. Hope it doesn't elsewhere with > submit 26e237fb5b8. > > Thanks for pointing this out. > > Regards, > Andre > > On Fri, 28 Jan 2022 10:36:23 +0100 > Andre Vehreschild via Fortran wrote: > > > Hi Tobias, > > > > ups, sorry, reverted immediately. > > > > Regards, > > Andre > > > > On Fri, 28 Jan 2022 10:27:26 +0100 > > Tobias Burnus wrote: > > > > > Hi Andre, > > > > > > your patch breaks bootstrapping: > > > > > > ../../repos/gcc/gcc/fortran/trans-array.cc: In function ‘tree_node* > > > structure_alloc_comps(gfc_symbol*, tree, tree, int, int, int, > > > gfc_co_subroutines_args*)’: > > > ../../repos/gcc/gcc/fortran/trans-array.cc:9200:42: error: ‘cdesc’ may be > > > used uninitialized [-Werror=maybe-uninitialized] 9200 | > > > gfc_conv_descriptor_data_set (, cdesc, comp); | > > > ~^~~~ > > > ../../repos/gcc/gcc/fortran/trans-array.cc:9082:16: note: ‘cdesc’ was > > > declared here 9082 | tree cdesc; |^ cc1plus: > > > all warnings being treated as errors make[3]: *** [Makefile:1143: > > > fortran/trans-array.o] Error 1 > > > > > > Tobias > > > > > > On 28.01.22 10:07, Andre Vehreschild via Fortran wrote: > > > > Hi Harald, > > > > > > > > thanks for the fast review. I have submitted as c9c48ab7bad. > > > > > > > > Will wait for two weeks (reminder set :-)) before backporting to gcc-11. > > > > > > > > Thank you and regards, > > > > Andre > > > > > > > > On Tue, 25 Jan 2022 22:30:22 +0100 > > > > Harald Anlauf via Fortran wrote: > > > > > > > >> Hi Andre', > > > >> > > > >> Am 25.01.22 um 17:32 schrieb Andre Vehreschild via Fortran: > > > >>> Hi all, > > > >>> > > > >>> attached patch fixes wrong code generation when broadcasting a derived > > > >>> type containing allocatable and non-allocatable scalars. Furthermore > > > >>> does it prevent broadcasting of coarray-tokens, which are always local > > > >>> this_image. Thus having them on a different image makes no sense. > > > >>> > > > >>> Bootstrapped and regtested ok on x86_64-linux/F35. > > > >>> > > > >>> Ok, for trunk and backport to 12 and 11-branch after decent time? > > > >>> > > > >>> I perceived that 12 is closed for this kind of bugfix, therefore > > > >>> asking ok for 13. > > > >> I do not think that 12 is closed for bugfixing, especially not for > > > >> fortran. And if my cursory reading of the patch is not misleading, > > > >> the impact of the patch is really limited to coarrays. > > > >> > > > >> You may want to wait for another 1-2 days for additional comments. > > > >> If not, it is OK from my side. > > > >> > > > >> Thanks for the patch! > > > >> > > > >> Harald > > > >> > > > >>> Regards, > > > >>> Andre > > > >>> -- > > > >>> Andre Vehreschild * Email: vehre ad gmx dot de > > > >> > > > > > > > > -- > > > > Andre Vehreschild * Email: vehre ad gmx dot de > > > - > > > 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 > > > > > > -- Andre Vehreschild * Email: vehre ad gmx dot de
Re: [Submitted, PR103970, Fortran, Coarray] Multi-image co_broadcast of derived type with allocatable components fails^
Hi Tobias, I don't know why that bootstrapped initially. I fixed the patch (naming a ``` else /* Prevent warning. */ cdesc = NULL_TREE; ``` obvious) and rerun bootstrap making sure to purge everything beforehand. It did not break bootstrap on x86_64-linux/f35. Hope it doesn't elsewhere with submit 26e237fb5b8. Thanks for pointing this out. Regards, Andre On Fri, 28 Jan 2022 10:36:23 +0100 Andre Vehreschild via Fortran wrote: > Hi Tobias, > > ups, sorry, reverted immediately. > > Regards, > Andre > > On Fri, 28 Jan 2022 10:27:26 +0100 > Tobias Burnus wrote: > > > Hi Andre, > > > > your patch breaks bootstrapping: > > > > ../../repos/gcc/gcc/fortran/trans-array.cc: In function ‘tree_node* > > structure_alloc_comps(gfc_symbol*, tree, tree, int, int, int, > > gfc_co_subroutines_args*)’: > > ../../repos/gcc/gcc/fortran/trans-array.cc:9200:42: error: ‘cdesc’ may be > > used uninitialized [-Werror=maybe-uninitialized] 9200 | > > gfc_conv_descriptor_data_set (, cdesc, comp); | > > ~^~~~ > > ../../repos/gcc/gcc/fortran/trans-array.cc:9082:16: note: ‘cdesc’ was > > declared here 9082 | tree cdesc; |^ cc1plus: > > all warnings being treated as errors make[3]: *** [Makefile:1143: > > fortran/trans-array.o] Error 1 > > > > Tobias > > > > On 28.01.22 10:07, Andre Vehreschild via Fortran wrote: > > > Hi Harald, > > > > > > thanks for the fast review. I have submitted as c9c48ab7bad. > > > > > > Will wait for two weeks (reminder set :-)) before backporting to gcc-11. > > > > > > Thank you and regards, > > > Andre > > > > > > On Tue, 25 Jan 2022 22:30:22 +0100 > > > Harald Anlauf via Fortran wrote: > > > > > >> Hi Andre', > > >> > > >> Am 25.01.22 um 17:32 schrieb Andre Vehreschild via Fortran: > > >>> Hi all, > > >>> > > >>> attached patch fixes wrong code generation when broadcasting a derived > > >>> type containing allocatable and non-allocatable scalars. Furthermore > > >>> does it prevent broadcasting of coarray-tokens, which are always local > > >>> this_image. Thus having them on a different image makes no sense. > > >>> > > >>> Bootstrapped and regtested ok on x86_64-linux/F35. > > >>> > > >>> Ok, for trunk and backport to 12 and 11-branch after decent time? > > >>> > > >>> I perceived that 12 is closed for this kind of bugfix, therefore asking > > >>> ok for 13. > > >> I do not think that 12 is closed for bugfixing, especially not for > > >> fortran. And if my cursory reading of the patch is not misleading, > > >> the impact of the patch is really limited to coarrays. > > >> > > >> You may want to wait for another 1-2 days for additional comments. > > >> If not, it is OK from my side. > > >> > > >> Thanks for the patch! > > >> > > >> Harald > > >> > > >>> Regards, > > >>> Andre > > >>> -- > > >>> Andre Vehreschild * Email: vehre ad gmx dot de > > >> > > > > > > -- > > > Andre Vehreschild * Email: vehre ad gmx dot de > > - > > 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 > > -- Andre Vehreschild * Email: vehre ad gmx dot de
Re: [Submitted, PR103970, Fortran, Coarray] Multi-image co_broadcast of derived type with allocatable components fails^
Hi Tobias, ups, sorry, reverted immediately. Regards, Andre On Fri, 28 Jan 2022 10:27:26 +0100 Tobias Burnus wrote: > Hi Andre, > > your patch breaks bootstrapping: > > ../../repos/gcc/gcc/fortran/trans-array.cc: In function ‘tree_node* > structure_alloc_comps(gfc_symbol*, tree, tree, int, int, int, > gfc_co_subroutines_args*)’: > ../../repos/gcc/gcc/fortran/trans-array.cc:9200:42: error: ‘cdesc’ may be > used uninitialized [-Werror=maybe-uninitialized] 9200 | > gfc_conv_descriptor_data_set (, cdesc, comp); | > ~^~~~ > ../../repos/gcc/gcc/fortran/trans-array.cc:9082:16: note: ‘cdesc’ was > declared here 9082 | tree cdesc; |^ cc1plus: > all warnings being treated as errors make[3]: *** [Makefile:1143: > fortran/trans-array.o] Error 1 > > Tobias > > On 28.01.22 10:07, Andre Vehreschild via Fortran wrote: > > Hi Harald, > > > > thanks for the fast review. I have submitted as c9c48ab7bad. > > > > Will wait for two weeks (reminder set :-)) before backporting to gcc-11. > > > > Thank you and regards, > > Andre > > > > On Tue, 25 Jan 2022 22:30:22 +0100 > > Harald Anlauf via Fortran wrote: > > > >> Hi Andre', > >> > >> Am 25.01.22 um 17:32 schrieb Andre Vehreschild via Fortran: > >>> Hi all, > >>> > >>> attached patch fixes wrong code generation when broadcasting a derived > >>> type containing allocatable and non-allocatable scalars. Furthermore does > >>> it prevent broadcasting of coarray-tokens, which are always local > >>> this_image. Thus having them on a different image makes no sense. > >>> > >>> Bootstrapped and regtested ok on x86_64-linux/F35. > >>> > >>> Ok, for trunk and backport to 12 and 11-branch after decent time? > >>> > >>> I perceived that 12 is closed for this kind of bugfix, therefore asking ok > >>> for 13. > >> I do not think that 12 is closed for bugfixing, especially not for > >> fortran. And if my cursory reading of the patch is not misleading, > >> the impact of the patch is really limited to coarrays. > >> > >> You may want to wait for another 1-2 days for additional comments. > >> If not, it is OK from my side. > >> > >> Thanks for the patch! > >> > >> Harald > >> > >>> Regards, > >>> Andre > >>> -- > >>> Andre Vehreschild * Email: vehre ad gmx dot de > >> > > > > -- > > Andre Vehreschild * Email: vehre ad gmx dot de > - > 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 -- Andre Vehreschild * Email: vehre ad gmx dot de
[Submitted, PR103970, Fortran, Coarray] Multi-image co_broadcast of derived type with allocatable components fails^
Hi Harald, thanks for the fast review. I have submitted as c9c48ab7bad. Will wait for two weeks (reminder set :-)) before backporting to gcc-11. Thank you and regards, Andre On Tue, 25 Jan 2022 22:30:22 +0100 Harald Anlauf via Fortran wrote: > Hi Andre', > > Am 25.01.22 um 17:32 schrieb Andre Vehreschild via Fortran: > > Hi all, > > > > attached patch fixes wrong code generation when broadcasting a derived type > > containing allocatable and non-allocatable scalars. Furthermore does it > > prevent broadcasting of coarray-tokens, which are always local this_image. > > Thus having them on a different image makes no sense. > > > > Bootstrapped and regtested ok on x86_64-linux/F35. > > > > Ok, for trunk and backport to 12 and 11-branch after decent time? > > > > I perceived that 12 is closed for this kind of bugfix, therefore asking ok > > for 13. > > I do not think that 12 is closed for bugfixing, especially not for > fortran. And if my cursory reading of the patch is not misleading, > the impact of the patch is really limited to coarrays. > > You may want to wait for another 1-2 days for additional comments. > If not, it is OK from my side. > > Thanks for the patch! > > Harald > > > Regards, > > Andre > > -- > > Andre Vehreschild * Email: vehre ad gmx dot de > > -- Andre Vehreschild * Email: vehre ad gmx dot de
[PR103970, Fortran, Coarray] Multi-image co_broadcast of derived type with allocatable components fails^
Hi all,
attached patch fixes wrong code generation when broadcasting a derived type
containing allocatable and non-allocatable scalars. Furthermore does it prevent
broadcasting of coarray-tokens, which are always local this_image. Thus having
them on a different image makes no sense.
Bootstrapped and regtested ok on x86_64-linux/F35.
Ok, for trunk and backport to 12 and 11-branch after decent time?
I perceived that 12 is closed for this kind of bugfix, therefore asking ok for
13.
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
gcc/fortran/ChangeLog:
2022-01-24 Andre Vehreschild
PR fortran/103790
* trans-array.cc (structure_alloc_comps): Prevent descriptor
stacking for non-array data; do not broadcast caf-tokens.
* trans-intrinsic.cc (conv_co_collective): Prevent generation
of unused descriptor.
gcc/testsuite/ChangeLog:
2022-01-24 Andre Vehreschild
PR fortran/103790
* gfortran.dg/coarray_collectives_18.f90: New test.
diff --git a/gcc/fortran/trans-array.cc b/gcc/fortran/trans-array.cc
index 2f0c8a4d412..1234932aaff 100644
--- a/gcc/fortran/trans-array.cc
+++ b/gcc/fortran/trans-array.cc
@@ -9102,6 +9102,10 @@ structure_alloc_comps (gfc_symbol * der_type, tree decl,
continue;
}
+ /* Do not broadcast a caf_token. These are local to the image. */
+ if (attr->caf_token)
+ continue;
+
add_when_allocated = NULL_TREE;
if (cmp_has_alloc_comps
&& !c->attr.pointer && !c->attr.proc_pointer)
@@ -9134,10 +9138,13 @@ structure_alloc_comps (gfc_symbol * der_type, tree decl,
if (attr->dimension)
{
tmp = gfc_get_element_type (TREE_TYPE (comp));
- ubound = gfc_full_array_size (, comp,
- c->ts.type == BT_CLASS
- ? CLASS_DATA (c)->as->rank
- : c->as->rank);
+ if (!GFC_DESCRIPTOR_TYPE_P (TREE_TYPE (comp)))
+ ubound = GFC_TYPE_ARRAY_SIZE (TREE_TYPE (comp));
+ else
+ ubound = gfc_full_array_size (, comp,
+ c->ts.type == BT_CLASS
+ ? CLASS_DATA (c)->as->rank
+ : c->as->rank);
}
else
{
@@ -9145,26 +9152,36 @@ structure_alloc_comps (gfc_symbol * der_type, tree decl,
ubound = build_int_cst (gfc_array_index_type, 1);
}
- cdesc = gfc_get_array_type_bounds (tmp, 1, 0, _index_one_node,
-, 1,
-GFC_ARRAY_ALLOCATABLE, false);
+ /* Treat strings like arrays. Or the other way around, do not
+ * generate an additional array layer for scalar components. */
+ if (attr->dimension || c->ts.type == BT_CHARACTER)
+ {
+ cdesc = gfc_get_array_type_bounds (tmp, 1, 0, _index_one_node,
+, 1,
+GFC_ARRAY_ALLOCATABLE, false);
- cdesc = gfc_create_var (cdesc, "cdesc");
- DECL_ARTIFICIAL (cdesc) = 1;
+ cdesc = gfc_create_var (cdesc, "cdesc");
+ DECL_ARTIFICIAL (cdesc) = 1;
- gfc_add_modify (, gfc_conv_descriptor_dtype (cdesc),
- gfc_get_dtype_rank_type (1, tmp));
- gfc_conv_descriptor_lbound_set (, cdesc,
- gfc_index_zero_node,
- gfc_index_one_node);
- gfc_conv_descriptor_stride_set (, cdesc,
- gfc_index_zero_node,
- gfc_index_one_node);
- gfc_conv_descriptor_ubound_set (, cdesc,
- gfc_index_zero_node, ubound);
+ gfc_add_modify (, gfc_conv_descriptor_dtype (cdesc),
+ gfc_get_dtype_rank_type (1, tmp));
+ gfc_conv_descriptor_lbound_set (, cdesc,
+ gfc_index_zero_node,
+ gfc_index_one_node);
+ gfc_conv_descriptor_stride_set (, cdesc,
+ gfc_index_zero_node,
+ gfc_index_one_node);
+ gfc_conv_descriptor_ubound_set (, cdesc,
+ gfc_index_zero_node, ubound);
+ }
if (attr->dimension)
- comp = gfc_conv_descriptor_data_get (comp);
+ {
+ if (GFC_DESCRIPTOR_TYPE_P (TREE_TYPE (comp)))
+ comp = gfc_conv_descriptor_data_get (comp);
+ else
+
Re: [Ping^2, Patch, Fortran] PR100337 Should be able to pass non-present optional arguments to CO_BROADCAST
Hi all, the fix for PR100337 was submitted as da13e4ebebb07a47d5fb50eab8893f8fe38683df. Thanks for the review Tobias. @Tobias: You are right, caf_single does not get much testing. But this part (not providing a stat) is tested multiple times, because of the laziness. Nearly none of the tests in the testsuite provides a variable for stat. Will wait two weeks for any errors introduced by this patch before backporting to gcc-11, ok? Regards, Andre On Tue, 22 Jun 2021 10:37:27 +0200 Tobias Burnus wrote: > Hi Andre, > > On 22.06.21 09:40, Andre Vehreschild via Fortran wrote: > > To the questions: > > - I added a test only for -fcoarray=single because in the library case the > >optional stat is just propagated to the library, which is already tested > > a lot of times and which needs to handle the optional stat in any case. So > > an error there would have been detected in one of the earlier tests. I did > > not want to add unnecessary test overhead given that the tests already run > > for a long time. > Fair point. > > - I did not add tests for the other CO_* routines, i.e. CO_MIN, CO_MAX, > >CO_REDUCE or CO_SUM, that are also handled by this routine, because I > > believe that showing that the fix works for CO_BROADCAST shows that the > > others work, too. Because the four others do not have any special handling > > in their implementation in trans_intrinsic. Or do you mean other > > coarray-routines besides the five handled by conv_co_collective()? > Well, that relates more to the first point – for -fcoarray=lib, it > likely makes a difference. For -fcoarray=single not. If the former is > skipped, it is much less relevant for the second. > > If it is ok for you, I would apply the patch as is, or do you see a reason > > to add more tests? > > OK. > > Although, I am not that sure that libcaf_single gets that much testing. > On the other hand, -fcoarray=lib with -lcaf_single is also not that > relevant in the real world, either. > > Tobias > > - > Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München > Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Frank > Thürauf -- Andre Vehreschild * Email: vehre ad gmx dot de
Re: [Ping^2, Patch, Fortran] PR100337 Should be able to pass non-present optional arguments to CO_BROADCAST
Hi Tobias, thanks for the review. To the questions: - I added a test only for -fcoarray=single because in the library case the optional stat is just propagated to the library, which is already tested a lot of times and which needs to handle the optional stat in any case. So an error there would have been detected in one of the earlier tests. I did not want to add unnecessary test overhead given that the tests already run for a long time. - I did not add tests for the other CO_* routines, i.e. CO_MIN, CO_MAX, CO_REDUCE or CO_SUM, that are also handled by this routine, because I believe that showing that the fix works for CO_BROADCAST shows that the others work, too. Because the four others do not have any special handling in their implementation in trans_intrinsic. Or do you mean other coarray-routines besides the five handled by conv_co_collective()? If it is ok for you, I would apply the patch as is, or do you see a reason to add more tests? Regards, Andre On Mon, 21 Jun 2021 14:30:21 +0200 Tobias Burnus wrote: > Any reason that you did not put it under >gfortran.dg/coarray/ > such that it is also run with -fcoarray=lib (-lcaf_single)? > I know that the issue only exists for single, but it also makes > sense to check that libcaf_single works > > In that sense, I wonder whether also the other CO_* should be > checked in the testsuite as they are handled differently in > libcaf_... (but identical with -fcoarray=single). > > Except for those two nits, it LGTM. Thanks! > > Tobias > > PS: The function is used by > case GFC_ISYM_CO_BROADCAST: > case GFC_ISYM_CO_MIN: > case GFC_ISYM_CO_MAX: > case GFC_ISYM_CO_REDUCE: > case GFC_ISYM_CO_SUM: > and, with -fcoarray=single, errmsg is not touched > as stat is (unconditionally) 0 (success).. > > > On 19.06.21 13:23, Andre Vehreschild via Fortran wrote: > > PING! > > > > On Fri, 4 Jun 2021 18:05:18 +0200 > > Andre Vehreschild wrote: > > > >> Ping! > >> > >> On Fri, 21 May 2021 15:33:11 +0200 > >> Andre Vehreschild wrote: > >> > >>> Hi, > >>> > >>> the attached patch fixes an issue when calling CO_BROADCAST in > >>> -fcoarray=single mode, where the optional but non-present (in the calling > >>> scope) stat variable was assigned to before checking for it being not > >>> present. > >>> > >>> Regtests fine on x86-64-linux/f33. Ok for trunk? > >>> > >>> Regards, > >>> Andre > >> > > > > -- > > Andre Vehreschild * Email: vehre ad gmx dot de > - > Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München > Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Frank > Thürauf -- Andre Vehreschild * Email: vehre ad gmx dot de
Re: [Ping^2, Patch, Fortran] PR100337 Should be able to pass non-present optional arguments to CO_BROADCAST
PING!
On Fri, 4 Jun 2021 18:05:18 +0200
Andre Vehreschild wrote:
> Ping!
>
> On Fri, 21 May 2021 15:33:11 +0200
> Andre Vehreschild wrote:
>
> > Hi,
> >
> > the attached patch fixes an issue when calling CO_BROADCAST in
> > -fcoarray=single mode, where the optional but non-present (in the calling
> > scope) stat variable was assigned to before checking for it being not
> > present.
> >
> > Regtests fine on x86-64-linux/f33. Ok for trunk?
> >
> > Regards,
> > Andre
>
>
--
Andre Vehreschild * Email: vehre ad gmx dot de
gcc/fortran/ChangeLog:
PR fortran/100337
* trans-intrinsic.c (conv_co_collective): Check stat for null ptr
before dereferrencing.
gcc/testsuite/ChangeLog:
PR fortran/100337
* gfortran.dg/coarray_collectives_17.f90: New test.
diff --git a/gcc/fortran/trans-intrinsic.c b/gcc/fortran/trans-intrinsic.c
index 4d7451479d3..03a38090051 100644
--- a/gcc/fortran/trans-intrinsic.c
+++ b/gcc/fortran/trans-intrinsic.c
@@ -11232,8 +11232,28 @@ conv_co_collective (gfc_code *code)
if (flag_coarray == GFC_FCOARRAY_SINGLE)
{
if (stat != NULL_TREE)
- gfc_add_modify (, stat,
- fold_convert (TREE_TYPE (stat), integer_zero_node));
+ {
+ /* For optional stats, check the pointer is valid before zero'ing. */
+ if (gfc_expr_attr (stat_expr).optional)
+ {
+ tree tmp;
+ stmtblock_t ass_block;
+ gfc_start_block (_block);
+ gfc_add_modify (_block, stat,
+ fold_convert (TREE_TYPE (stat),
+ integer_zero_node));
+ tmp = fold_build2 (NE_EXPR, logical_type_node,
+ gfc_build_addr_expr (NULL_TREE, stat),
+ null_pointer_node);
+ tmp = fold_build3 (COND_EXPR, void_type_node, tmp,
+ gfc_finish_block (_block),
+ build_empty_stmt (input_location));
+ gfc_add_expr_to_block (, tmp);
+ }
+ else
+ gfc_add_modify (, stat,
+ fold_convert (TREE_TYPE (stat), integer_zero_node));
+ }
return gfc_finish_block ();
}
diff --git a/gcc/testsuite/gfortran.dg/coarray_collectives_17.f90 b/gcc/testsuite/gfortran.dg/coarray_collectives_17.f90
new file mode 100644
index 000..84a6645865e
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/coarray_collectives_17.f90
@@ -0,0 +1,42 @@
+! { dg-do run }
+! { dg-options "-fcoarray=single" }
+!
+! PR 100337
+! Test case inspired by code submitted by Brad Richardson
+
+program main
+implicit none
+
+integer, parameter :: MESSAGE = 42
+integer :: result
+
+call myco_broadcast(MESSAGE, result, 1)
+
+if (result /= MESSAGE) error stop 1
+contains
+subroutine myco_broadcast(m, r, source_image, stat, errmsg)
+integer, intent(in) :: m
+integer, intent(out) :: r
+integer, intent(in) :: source_image
+integer, intent(out), optional :: stat
+character(len=*), intent(inout), optional :: errmsg
+
+integer :: data_length
+
+data_length = 1
+
+call co_broadcast(data_length, source_image, stat, errmsg)
+
+if (present(stat)) then
+if (stat /= 0) return
+end if
+
+if (this_image() == source_image) then
+r = m
+end if
+
+call co_broadcast(r, source_image, stat, errmsg)
+end subroutine
+
+end program
+
Re: [COMITTED, Patch, Fortran, backport 2 gcc-11] PR98301 Re: RANDOM_INIT() and coarray Fortran
Hi Steve, hi all, the patch for pr98301 has been backported to gcc-11 as 002745ca3668fc5e87c22acc81caaeaaadf9c47a Regards, Andre On Sat, 5 Jun 2021 09:27:16 -0700 Steve Kargl wrote: > On Sat, Jun 05, 2021 at 04:04:51PM +0200, Andre Vehreschild wrote: > > > > I was asked to backport the patch for pr98301 to gcc-11. The patches have > > been in mainline for two weeks without any defect reports I could fined. The > > patch for mainline applied with a bit of shift cleanly. > > > > Regstested fine on x86_64/f33. Ok for backport gcc-11? > > > > I think the backport is fine. > -- Andre Vehreschild * Email: vehre ad gmx dot de
[Patch, Fortran, backport 2 gcc-11] PR98301 Re: RANDOM_INIT() and coarray Fortran
Hi all,
I was asked to backport the patch for pr98301 to gcc-11. The patches have
been in mainline for two weeks without any defect reports I could fined. The
patch for mainline applied with a bit of shift cleanly.
Regstested fine on x86_64/f33. Ok for backport gcc-11?
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
Steve Kargl
PR fortran/98301 - random_init() is broken
Correct implementation of random_init() when -fcoarray=lib is given.
Backport from mainline.
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.
diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c
index 7cded0a3ede..4fa39f71a21 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,7 @@ 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. */
static void
gfc_add_decl_to_parent_function (tree decl)
@@ -3516,6 +3517,8 @@ 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.
+
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);
@@ -4081,6 +4084,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 68090d4defc..2c094f326e6 100644
--- a/gcc/fortran/trans-intrinsic.c
+++ b/gcc/fortran/trans-intrinsic.c
@@ -3837,38 +3837,43 @@ 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 ();
gfc_init_se (, NULL);
- /* Convert REPEATABLE to a LOGICAL(4) entity. */
+ /* Convert REPEATABLE to the desired LOGICAL entity. */
gfc_conv_expr (, code->ext.actual->expr);
gfc_add_block_to_block (, );
- arg1 = fold_convert (logical4_type_node, gfc_evaluate_now (se.expr, ));
+ arg1 = fold_convert (used_bool_type_node, gfc_evaluate_now (se.expr, ));
gfc_add_block_to_block (, );
- /* Convert IMAGE_DISTINCT to a LOGICAL(4) entity. */
+ /* Convert IMAGE_DISTINCT to the desired LOGICAL entity. */
gfc_conv_expr (, code->ext.actual->next->expr);
gfc_add_block_to_block (, );
- arg2 = fold_convert (logical4_type_node, gfc_evaluate_now (se.expr, ));
+ arg2 = fold_convert (used_bool_type_node, gfc_evaluate_now (se.expr, ));
gfc_add_block_to_block (, );
- /* Create the hidden argument. For non-coarray codes and -fcoarray=single,
- simply set this to 0. For -fcoarray=lib, generate a call to
- THIS_IMAGE() without arguments. */
- arg3 = build_int_cst (gfc_get_int_type (4), 0);
if (flag_coarray == GFC_FCOARRAY_LIB)
{
- arg3 = build_call_expr_loc (input_location, gfor_fndecl_caf_this_image,
- 1, arg3);
- se.expr = fold_convert (gfc_get_int_type (4), arg3);
+ tmp = build_call_expr_loc (input_location, gfor_fndecl_caf_random_init,
+ 2, arg1, arg2);
+}
+ else
+{
+ /* The ABI for libgfortran needs to be maintained, so a hidden
+ argument must be include if code is compiled with -fcoarray=single
+ or without the option. Set to 0. */
+ tree arg3 = build_int_cst (gfc_get_int_type (4), 0);
+ tmp = build_call_expr_loc (input_location, gfor_fndecl_random_init,
+ 3, arg1, arg2, arg3);
}
- tmp
[Ping, Patch, Fortran] PR100337 Should be able to pass non-present optional arguments to CO_BROADCAST
Ping!
On Fri, 21 May 2021 15:33:11 +0200
Andre Vehreschild wrote:
> Hi,
>
> the attached patch fixes an issue when calling CO_BROADCAST in
> -fcoarray=single mode, where the optional but non-present (in the calling
> scope) stat variable was assigned to before checking for it being not present.
>
> Regtests fine on x86-64-linux/f33. Ok for trunk?
>
> Regards,
> Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
gcc/fortran/ChangeLog:
PR fortran/100337
* trans-intrinsic.c (conv_co_collective): Check stat for null ptr
before dereferrencing.
gcc/testsuite/ChangeLog:
PR fortran/100337
* gfortran.dg/coarray_collectives_17.f90: New test.
diff --git a/gcc/fortran/trans-intrinsic.c b/gcc/fortran/trans-intrinsic.c
index 4d7451479d3..03a38090051 100644
--- a/gcc/fortran/trans-intrinsic.c
+++ b/gcc/fortran/trans-intrinsic.c
@@ -11232,8 +11232,28 @@ conv_co_collective (gfc_code *code)
if (flag_coarray == GFC_FCOARRAY_SINGLE)
{
if (stat != NULL_TREE)
- gfc_add_modify (, stat,
- fold_convert (TREE_TYPE (stat), integer_zero_node));
+ {
+ /* For optional stats, check the pointer is valid before zero'ing. */
+ if (gfc_expr_attr (stat_expr).optional)
+ {
+ tree tmp;
+ stmtblock_t ass_block;
+ gfc_start_block (_block);
+ gfc_add_modify (_block, stat,
+ fold_convert (TREE_TYPE (stat),
+ integer_zero_node));
+ tmp = fold_build2 (NE_EXPR, logical_type_node,
+ gfc_build_addr_expr (NULL_TREE, stat),
+ null_pointer_node);
+ tmp = fold_build3 (COND_EXPR, void_type_node, tmp,
+ gfc_finish_block (_block),
+ build_empty_stmt (input_location));
+ gfc_add_expr_to_block (, tmp);
+ }
+ else
+ gfc_add_modify (, stat,
+ fold_convert (TREE_TYPE (stat), integer_zero_node));
+ }
return gfc_finish_block ();
}
diff --git a/gcc/testsuite/gfortran.dg/coarray_collectives_17.f90 b/gcc/testsuite/gfortran.dg/coarray_collectives_17.f90
new file mode 100644
index 000..84a6645865e
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/coarray_collectives_17.f90
@@ -0,0 +1,42 @@
+! { dg-do run }
+! { dg-options "-fcoarray=single" }
+!
+! PR 100337
+! Test case inspired by code submitted by Brad Richardson
+
+program main
+implicit none
+
+integer, parameter :: MESSAGE = 42
+integer :: result
+
+call myco_broadcast(MESSAGE, result, 1)
+
+if (result /= MESSAGE) error stop 1
+contains
+subroutine myco_broadcast(m, r, source_image, stat, errmsg)
+integer, intent(in) :: m
+integer, intent(out) :: r
+integer, intent(in) :: source_image
+integer, intent(out), optional :: stat
+character(len=*), intent(inout), optional :: errmsg
+
+integer :: data_length
+
+data_length = 1
+
+call co_broadcast(data_length, source_image, stat, errmsg)
+
+if (present(stat)) then
+if (stat /= 0) return
+end if
+
+if (this_image() == source_image) then
+r = m
+end if
+
+call co_broadcast(r, source_image, stat, errmsg)
+end subroutine
+
+end program
+
Re: [Ping^2, Patch, Fortran] PR98301 Re: RANDOM_INIT() and coarray Fortran
Hi Martin, thanks for pointing that out. I haven't committed for quite some time now and could not find on the webpage how this works nowadays. I was thinking that the special gcc-git-command should have added the Changelog entries automagically and immediately. That they are added by a daily bump is new to me. Thanks for giving me more insight. So do I need to revert the commit c4771b3438a8cd9afcef1762957b763f8df3fa6e to fix the Changelogs or how do we proceed from here? Is there a webpage which describes the current state-of-art of committing to gcc for folks that do not follow every discussion on the mailing lists? Thanks for your help, Andre On Sat, 22 May 2021 19:58:57 +0200 Martin Liška wrote: > On 5/22/21 1:39 PM, Andre Vehreschild via Gcc-patches wrote: > > Hi Steve and Jerry, > > > > thanks for the ok'ing. > > > > Committed as https://gcc.gnu.org/g:26ca6dbda23bc6dfab96ce07afa70ebacedfaf9c > > and https://gcc.gnu.org/g:c4771b3438a8cd9afcef1762957b763f8df3fa6e (for the > > missing changelog entries). > > Hello. > > About the missing changelog entries. The will be added automatically by Daily > bump. You can check it with: > ./contrib/gcc-changelog/git_check_commit.py > 26ca6dbda23bc6dfab96ce07afa70ebacedfaf9c -p > > What's missing for you so that you pushed > c4771b3438a8cd9afcef1762957b763f8df3fa6e? > > Thanks, > Martin > > > > > - Andre > > > > On Fri, 21 May 2021 19:38:00 -0700 > > Jerry D wrote: > > > >> yes, please commit > >> > >> On 5/21/21 8:08 AM, Steve Kargl via Fortran wrote: > >>> On Fri, May 21, 2021 at 10:09:02AM +0200, Andre Vehreschild wrote: > >>>> Ping, ping! > >>>> > >>>> Please find attached a rebased version of the patch for the RANDOM_INIT > >>>> issue with coarray Fortran. Nothing changed to the previous version, just > >>>> rebased to current master. > >>>> > >>>> Regtested fine on x86_64-linux/f33. Ok for trunk? > >>>> > >>> I think you've down your due diligence with 2 pings. > >>> I would commit. > >>> > >> > > > > > > -- > > Andre Vehreschild * Email: vehre ad gmx dot de > > > -- Andre Vehreschild * Email: vehre ad gmx dot de
Re: [Ping^2, Patch, Fortran] PR98301 Re: RANDOM_INIT() and coarray Fortran
Hi Steve and Jerry, thanks for the ok'ing. Committed as https://gcc.gnu.org/g:26ca6dbda23bc6dfab96ce07afa70ebacedfaf9c and https://gcc.gnu.org/g:c4771b3438a8cd9afcef1762957b763f8df3fa6e (for the missing changelog entries). - Andre On Fri, 21 May 2021 19:38:00 -0700 Jerry D wrote: > yes, please commit > > On 5/21/21 8:08 AM, Steve Kargl via Fortran wrote: > > On Fri, May 21, 2021 at 10:09:02AM +0200, Andre Vehreschild wrote: > >> Ping, ping! > >> > >> Please find attached a rebased version of the patch for the RANDOM_INIT > >> issue with coarray Fortran. Nothing changed to the previous version, just > >> rebased to current master. > >> > >> Regtested fine on x86_64-linux/f33. Ok for trunk? > >> > > I think you've down your due diligence with 2 pings. > > I would commit. > > > -- Andre Vehreschild * Email: vehre ad gmx dot de
[Patch, Fortran] PR100337 Should be able to pass non-present optional arguments to CO_BROADCAST
Hi,
the attached patch fixes an issue when calling CO_BROADCAST in -fcoarray=single
mode, where the optional but non-present (in the calling scope) stat variable
was assigned to before checking for it being not present.
Regtests fine on x86-64-linux/f33. Ok for trunk?
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
gcc/fortran/ChangeLog:
PR fortran/100337
* trans-intrinsic.c (conv_co_collective): Check stat for null ptr
before dereferrencing.
gcc/testsuite/ChangeLog:
PR fortran/100337
* gfortran.dg/coarray_collectives_17.f90: New test.
diff --git a/gcc/fortran/trans-intrinsic.c b/gcc/fortran/trans-intrinsic.c
index 4d7451479d3..03a38090051 100644
--- a/gcc/fortran/trans-intrinsic.c
+++ b/gcc/fortran/trans-intrinsic.c
@@ -11232,8 +11232,28 @@ conv_co_collective (gfc_code *code)
if (flag_coarray == GFC_FCOARRAY_SINGLE)
{
if (stat != NULL_TREE)
- gfc_add_modify (, stat,
- fold_convert (TREE_TYPE (stat), integer_zero_node));
+ {
+ /* For optional stats, check the pointer is valid before zero'ing. */
+ if (gfc_expr_attr (stat_expr).optional)
+ {
+ tree tmp;
+ stmtblock_t ass_block;
+ gfc_start_block (_block);
+ gfc_add_modify (_block, stat,
+ fold_convert (TREE_TYPE (stat),
+ integer_zero_node));
+ tmp = fold_build2 (NE_EXPR, logical_type_node,
+ gfc_build_addr_expr (NULL_TREE, stat),
+ null_pointer_node);
+ tmp = fold_build3 (COND_EXPR, void_type_node, tmp,
+ gfc_finish_block (_block),
+ build_empty_stmt (input_location));
+ gfc_add_expr_to_block (, tmp);
+ }
+ else
+ gfc_add_modify (, stat,
+ fold_convert (TREE_TYPE (stat), integer_zero_node));
+ }
return gfc_finish_block ();
}
diff --git a/gcc/testsuite/gfortran.dg/coarray_collectives_17.f90 b/gcc/testsuite/gfortran.dg/coarray_collectives_17.f90
new file mode 100644
index 000..84a6645865e
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/coarray_collectives_17.f90
@@ -0,0 +1,42 @@
+! { dg-do run }
+! { dg-options "-fcoarray=single" }
+!
+! PR 100337
+! Test case inspired by code submitted by Brad Richardson
+
+program main
+implicit none
+
+integer, parameter :: MESSAGE = 42
+integer :: result
+
+call myco_broadcast(MESSAGE, result, 1)
+
+if (result /= MESSAGE) error stop 1
+contains
+subroutine myco_broadcast(m, r, source_image, stat, errmsg)
+integer, intent(in) :: m
+integer, intent(out) :: r
+integer, intent(in) :: source_image
+integer, intent(out), optional :: stat
+character(len=*), intent(inout), optional :: errmsg
+
+integer :: data_length
+
+data_length = 1
+
+call co_broadcast(data_length, source_image, stat, errmsg)
+
+if (present(stat)) then
+if (stat /= 0) return
+end if
+
+if (this_image() == source_image) then
+r = m
+end if
+
+call co_broadcast(r, source_image, stat, errmsg)
+end subroutine
+
+end program
+
Re: [Ping^2, Patch, Fortran] PR98301 Re: RANDOM_INIT() and coarray Fortran
Ping, ping!
Please find attached a rebased version of the patch for the RANDOM_INIT issue
with coarray Fortran. Nothing changed to the previous version, just rebased to
current master.
Regtested fine on x86_64-linux/f33. Ok for trunk?
- Andre
On Mon, 3 May 2021 08:20:36 -0700
Steve Kargl wrote:
> On Mon, May 03, 2021 at 11:21:10AM +0200, Andre Vehreschild wrote:
> > Ping!
> >
> > Ok for trunk?
> >
> > I have looked at other patches, but none was patching any location I have
> > worked on previously. Therefore I can't return the favor of reviewing any
> > currently open patches and have to ask for volunteers here.
> >
> > - Andre
> >
>
> I doubt I'm allowed to approve a patch, where I wrote a portion
> of it. However, if no one else steps forward in the next day
> or two, then I think you should commit.
>
--
Andre Vehreschild * Email: vehre ad gmx dot de
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.
diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c
index 406b4aeb1d4..c32bd05bb1b 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,7 @@ 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. */
static void
gfc_add_decl_to_parent_function (tree decl)
@@ -3516,6 +3517,8 @@ 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.
+
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);
@@ -4081,6 +4084,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 4d7451479d3..db9248c0043 100644
--- a/gcc/fortran/trans-intrinsic.c
+++ b/gcc/fortran/trans-intrinsic.c
@@ -3827,38 +3827,43 @@ 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 ();
gfc_init_se (, NULL);
- /* Convert REPEATABLE to a LOGICAL(4) entity. */
+ /* Convert REPEATABLE to the desired LOGICAL entity. */
gfc_conv_expr (, code->ext.actual->expr);
gfc_add_block_to_block (, );
- arg1 = fold_convert (logical4_type_node, gfc_evaluate_now (se.expr, ));
+ arg1 = fold_convert (used_bool_type_node, gfc_evaluate_now (se.expr, ));
gfc_add_block_to_block (, );
- /* Convert IMAGE_DISTINCT to a LOGICAL(4) entity. */
+ /* Convert IMAGE_DISTINCT to the desired LOGICAL entity. */
gfc_conv_expr (, code->ext.actual->next->expr);
gfc_add_block_to_block (, );
- arg2 = fold_convert (logical4_type_node, gfc_evaluate_now (se.expr, ));
+ arg2 = fold_convert (used_bool_type_node, gfc_evaluate_now (se.expr, ));
gfc_add_block_to_block (, );
- /* Create the hidden argument. For non-coarray codes and -fcoarray=single,
- simply set this to 0. For -fcoarray=lib, generate a call to
- THIS_IMAGE() without arguments. */
- arg3 = build_int_cst (gfc_get_int_type (4), 0);
if (flag_coarray == GFC_FCOARRAY_LIB)
{
- arg3 = build_call_expr_loc (input_location, gfor_fndec
Re: [Patch, fortran] PRs 46691 and 99819: Assumed and explicit size class arrays
Hi Paul, this and the Changelog LGTM at least for 12. Give it a consolidation time before applying to 11. Having had some issues in the vicinity of the code you addressed I am quite happy to see how easy the fix looks. Any chances you can take a look at https://gcc.gnu.org/pipermail/fortran/2021-April/055990.html ? Regards, Andre On Thu, 6 May 2021 07:57:05 +0100 Paul Richard Thomas via Fortran wrote: > Hi All, > > Although I had undertaken to concentrate on PDTs, PR99819 so intrigued me > that I became locked into it :-( After extensive, fruitless rummaging > through decl.c and trans-decl.c, I realised that the problem was far > simpler than it seemed and that it lay in class.c. After that PR was fixed, > PR46691 was a trivial follow up. > > The comments in the patch explain the fixes. I left a TODO for the extent > checking of assumed size class arrays. I will try to fix it before pushing. > > Regtested on FC33/x86_64 and checked against the 'other brand'. OK for > 12-branch and, perhaps, 11-branch? > > Regards > > Paul > > Fortran: Assumed and explicit size class arrays [PR46691/99819]. > > 2021-05-06 Paul Thomas > > gcc/fortran/ChangeLog > > PR fortran/46691 > PR fortran/99819 > * class.c (gfc_build_class_symbol): Class array types that are > not deferred shape or assumed rank are given a unique name and > placed in the procedure namespace. > * trans-array.c (gfc_trans_g77_array): Obtain the data pointer > for class arrays. > (gfc_trans_dummy_array_bias): Suppress the runtime error for > extent violations in explicit shape class arrays because it > always fails. > * trans-expr.c (gfc_conv_procedure_call): Handle assumed size > class actual arguments passed to non-descriptor formal args by > using the data pointer, stored as the symbol's backend decl. > > gcc/testsuite/ChangeLog > > PR fortran/46691 > PR fortran/99819 > * gfortran.dg/class_dummy_6.f90: New test. > * gfortran.dg/class_dummy_6.f90: New test. -- Andre Vehreschild * Email: vehre ad gmx dot de
Re: [Ping, Patch, Fortran, Update 2] PR98301 Re: RANDOM_INIT() and coarray Fortran
Ping! Ok for trunk? I have looked at other patches, but none was patching any location I have worked on previously. Therefore I can't return the favor of reviewing any currently open patches and have to ask for volunteers here. - Andre On Mon, 26 Apr 2021 12:36:36 +0200 Andre Vehreschild via Fortran wrote: > Hi Steve, hi all, > > I agree. The cas-things have been removed (I will put the patch for them into > the pr98301 ticket, so safe them), streamlining the patch a bit more. > > Bootstraped and regtested ok on x86_64-linux/f33. Ok for trunk? > > Regards, > Andre > > 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/98302 > * 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 Sun, 25 Apr 2021 13:03:34 -0700 > Steve Kargl wrote: > > > Andre, > > > > The patch looks fine to me. I wonder, however, if we should > > comment out all of the shared memory stuff, i.e., the _cas_ > > stuff. I don't know when Thomas/Nicolas will merge their > > work-in-progress. > > > > > -- > Andre Vehreschild * Email: vehre ad gmx dot de -- Andre Vehreschild * Email: vehre ad gmx dot de
Re: [patch, shared coarrays, committed] Make header use more consistent
Hi Nicolas, Thomas, are you planing to also rename the directory and library name from "nca" to "shared_caf" or the like? Regards, Andre On Tue, 27 Oct 2020 17:18:21 -0400 David Edelsohn via Fortran wrote: > The current COARRAYS branch correctly bootstraps on AIX. Thanks for > correcting the contents and ordering of the header files. > > Thanks, David > > On Tue, Oct 27, 2020 at 1:31 PM Thomas Koenig wrote: > > > > I just committed > > > > https://gcc.gnu.org/g:0c261d5b5c931d9e9214d06531bdc7e9e16aeaab > > > > to hopefully fix the header issue on the native_coarray branch. > > > > If anybody wants to give this a spin, please go right ahead. > > > > I've also discussed with Nicolas on how best to proceed. The > > best way forward is probably to merge the branch into trunk at > > the end of stage 1 and follow Richard's suggestion to use configure.tgt > > to only compile the shared coarray library for systems where it is > > known to at least compile. As people test more systems, we can then > > add these to configure.tgt. > > > > Best regards > > > > Thomas > > > > Always include libgfortran.h first; sanitize header dependencies. > > > > libgfortran/ChangeLog: > > > > * nca/coarraynative.c: Do not include util.h. Remove commented > > include for stdlib.h.. > > * nca/collective_subroutine.c: Move #include after > > other #include statement. > > * nca/hashmap.c: Include shared_memory.h and allocator.h > > * nca/hashmap.h: Remove includess. > > * nca/libcoarraynative.h: Include only those headers which > > are needed. > > * nca/shared_memory.c: Do not include util.h > > * nca/shared_memory.h: Do not include other headers. > > * nca/sync.c: Move include of string.h after other headers. > > * nca/sync.h: Remove include of shared_memory.h and alloc.h. > > * nca/util.h: Do not include stdint.h and stddef.h; include > > limits.h and assert.h. > > * nca/wrapper.c: Remove include for sync.h, util.h and > > collective_subroutine.h. Move include of string.h after other > > headers. > > -- Andre Vehreschild * Email: vehre ad gmx dot de
Re: New modref/ipa_modref optimization passes
On Fri, 23 Oct 2020 11:54:08 +0200 Bernhard Reutner-Fischer via Fortran wrote: > On 16 October 2020 11:20:23 CEST, Richard Biener wrote: > > >IMHO the cleanest way would be to swap the CAF token field and > >the dim[] field (which is an ABI change for -fcoarray) > > I think coarrays are new anyway so I suppose an ABI break is fine? Coarrays are in the standard since Fortran 2008. So what I'd rather not call them new being there for more than 10 years... The descriptor is used in the opencoarrays library, too. And has to be kept in sync. So when the ABI break is reasonable it's fine. -- Andre Vehreschild * Email: vehre ad gmx dot de
Re: libgfortran caf API help needed: Fixing fnspec strings in trans-decl
Hi Honza,
attached is the patch to fix the fnspec-strings for the caf-api. I have tested
it and got no regressions with gcc-testsuite and with the opencoarray's
testsuite. So that seems fine. Hope this helps and again thank you for your
instant support on IRC.
Regards,
Andre
On Wed, 7 Oct 2020 13:28:56 +0200
Tobias Burnus wrote:
> Hi Andre,
>
> On 10/7/20 12:21 PM, Andre Vehreschild wrote:
> > I am confused. Given that on 2. Oct. 2020 you committed changes to the
> > caf-fn_spec strings means: you don't need anymore help on this?
>
> Do you mean the change by the patch "Perforate fnspec attribute strings"?
> (https://gcc.gnu.org/g:762cca0023c9bdbd762c44f33a954845bbccd568)
> That one just added spaces for the updated fnspec format.
>
> Otherwise:
> See gcc/attr-fnspec.h for a description.
>
> I suggest also to have a look at the commit log at
> https://gcc.gnu.org/g:2595f25cdaf4f16d04a1078a487b2ecc126cae29
> and at the PR https://gcc.gnu.org/PR92123 for gotchas.
>
> Tobias
>
> -
> Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
> Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung,
> Alexander Walter
--
Andre Vehreschild * Email: vehre ad gmx dot de
diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c
index 5940a1fd10c..fca1622edd1 100644
--- a/gcc/fortran/trans-decl.c
+++ b/gcc/fortran/trans-decl.c
@@ -3832,9 +3832,9 @@ gfc_build_builtin_function_decls (void)
pppchar_type
= build_pointer_type (build_pointer_type (pchar_type_node));
- gfor_fndecl_caf_init = gfc_build_library_function_decl (
- get_identifier (PREFIX("caf_init")), void_type_node,
- 2, pint_type, pppchar_type);
+ gfor_fndecl_caf_init = gfc_build_library_function_decl_with_spec (
+ get_identifier (PREFIX("caf_init")), ". W W ",
+ void_type_node, 2, pint_type, pppchar_type);
gfor_fndecl_caf_finalize = gfc_build_library_function_decl (
get_identifier (PREFIX("caf_finalize")), void_type_node, 0);
@@ -3848,47 +3848,47 @@ gfc_build_builtin_function_decls (void)
2, integer_type_node, integer_type_node);
gfor_fndecl_caf_register = gfc_build_library_function_decl_with_spec (
- get_identifier (PREFIX("caf_register")), "R R W W W W R ",
+ get_identifier (PREFIX("caf_register")), ". . . W w w w . ",
void_type_node, 7,
size_type_node, integer_type_node, ppvoid_type_node, pvoid_type_node,
pint_type, pchar_type_node, size_type_node);
gfor_fndecl_caf_deregister = gfc_build_library_function_decl_with_spec (
- get_identifier (PREFIX("caf_deregister")), "W R W W R ",
+ get_identifier (PREFIX("caf_deregister")), ". W . w w . ",
void_type_node, 5,
ppvoid_type_node, integer_type_node, pint_type, pchar_type_node,
size_type_node);
gfor_fndecl_caf_get = gfc_build_library_function_decl_with_spec (
- get_identifier (PREFIX("caf_get")), ". R . R R W R R R W ",
+ get_identifier (PREFIX("caf_get")), ". r . . r r w . . . w ",
void_type_node, 10,
pvoid_type_node, size_type_node, integer_type_node, pvoid_type_node,
pvoid_type_node, pvoid_type_node, integer_type_node, integer_type_node,
boolean_type_node, pint_type);
gfor_fndecl_caf_send = gfc_build_library_function_decl_with_spec (
- get_identifier (PREFIX("caf_send")), ". R . R R R R R R W R ",
+ get_identifier (PREFIX("caf_send")), ". r . . w r r . . . w ",
void_type_node, 11,
pvoid_type_node, size_type_node, integer_type_node, pvoid_type_node,
pvoid_type_node, pvoid_type_node, integer_type_node, integer_type_node,
boolean_type_node, pint_type, pvoid_type_node);
gfor_fndecl_caf_sendget = gfc_build_library_function_decl_with_spec (
- get_identifier (PREFIX("caf_sendget")), ". R . R R R R . R R R R R R ",
+ get_identifier (PREFIX("caf_sendget")), ". r . . w r r . . r r . . . w ",
void_type_node, 14, pvoid_type_node, size_type_node, integer_type_node,
pvoid_type_node, pvoid_type_node, pvoid_type_node, size_type_node,
integer_type_node, pvoid_type_node, pvoid_type_node, integer_type_node,
integer_type_node, boolean_type_node, integer_type_node);
gfor_fndecl_caf_get_by_ref = gfc_build_library_function_decl_with_spec (
- get_identifier (PREFIX("caf_get_by_ref")), ". R W R R R R R W R ",
+ get_identifier (PREFIX("caf_get_by_ref")), ". r . w r . . . . w . ",
void_type_node,
10, pvoid_type_node, integer_type_node, pvoid_type_node,
pvoid_type_node, integer_type_node, integer_type_node,
boolean_type_node, boolean_type_node, pint_type, integer_type_node);
gfor_fndecl_caf_send_by_ref = gfc_build_library_function_decl_with_spec
Re: libgfortran caf API help needed: Fixing fnspec strings in trans-decl
..WW",
> + get_identifier (PREFIX("caf_unlock")), ".R..WW.",
> void_type_node, 6, pvoid_type_node, size_type_node,
> integer_type_node, pint_type, pchar_type_node, size_type_node);
>
>gfor_fndecl_caf_event_post = gfc_build_library_function_decl_with_spec
> (
> - get_identifier (PREFIX("caf_event_post")), "R..WW",
> + get_identifier (PREFIX("caf_event_post")), ".R..WW.",
> void_type_node, 6, pvoid_type_node, size_type_node,
> integer_type_node, pint_type, pchar_type_node, size_type_node);
>
>gfor_fndecl_caf_event_wait = gfc_build_library_function_decl_with_spec
> (
> - get_identifier (PREFIX("caf_event_wait")), "R..WW",
> + get_identifier (PREFIX("caf_event_wait")), ".R..WW.",
> void_type_node, 6, pvoid_type_node, size_type_node,
> integer_type_node, pint_type, pchar_type_node, size_type_node);
>
>gfor_fndecl_caf_event_query =
> gfc_build_library_function_decl_with_spec (
> - get_identifier (PREFIX("caf_event_query")), "R..WW",
> + get_identifier (PREFIX("caf_event_query")), ".R..WW",
> void_type_node, 5, pvoid_type_node, size_type_node,
> integer_type_node, pint_type, pint_type);
>
> @@ -3982,19 +3982,19 @@ gfc_build_builtin_function_decls (void)
>
>gfor_fndecl_caf_failed_images
> = gfc_build_library_function_decl_with_spec (
> - get_identifier (PREFIX("caf_failed_images")), "WRR",
> + get_identifier (PREFIX("caf_failed_images")), ".WR.",
> void_type_node, 3, pvoid_type_node, ppvoid_type_node,
> integer_type_node);
>
>gfor_fndecl_caf_form_team
> = gfc_build_library_function_decl_with_spec (
> - get_identifier (PREFIX("caf_form_team")), "RWR",
> + get_identifier (PREFIX("caf_form_team")), ".RW.",
> void_type_node, 3, integer_type_node, ppvoid_type_node,
> integer_type_node);
>
>gfor_fndecl_caf_change_team
> = gfc_build_library_function_decl_with_spec (
> - get_identifier (PREFIX("caf_change_team")), "RR",
> + get_identifier (PREFIX("caf_change_team")), ".R.",
> void_type_node, 2, ppvoid_type_node,
> integer_type_node);
>
> @@ -4009,43 +4009,43 @@ gfc_build_builtin_function_decls (void)
>
>gfor_fndecl_caf_sync_team
> = gfc_build_library_function_decl_with_spec (
> - get_identifier (PREFIX("caf_sync_team")), "RR",
> + get_identifier (PREFIX("caf_sync_team")), ".R.",
> void_type_node, 2, ppvoid_type_node,
> integer_type_node);
>
>gfor_fndecl_caf_team_number
> - = gfc_build_library_function_decl_with_spec (
> - get_identifier (PREFIX("caf_team_number")), "R",
> - integer_type_node, 1, integer_type_node);
> + = gfc_build_library_function_decl (
> + get_identifier (PREFIX("caf_team_number")),
> + integer_type_node, 1, integer_type_node);
>
>gfor_fndecl_caf_image_status
> = gfc_build_library_function_decl_with_spec (
> - get_identifier (PREFIX("caf_image_status")), "RR",
> + get_identifier (PREFIX("caf_image_status")), "..R",
> integer_type_node, 2, integer_type_node, ppvoid_type_node);
>
>gfor_fndecl_caf_stopped_images
> = gfc_build_library_function_decl_with_spec (
> - get_identifier (PREFIX("caf_stopped_images")), "WRR",
> + get_identifier (PREFIX("caf_stopped_images")), ".WR.",
> void_type_node, 3, pvoid_type_node, ppvoid_type_node,
> integer_type_node);
>
>gfor_fndecl_co_broadcast = gfc_build_library_function_decl_with_spec (
> - get_identifier (PREFIX("caf_co_broadcast")), "W.WW",
> + get_identifier (PREFIX("caf_co_broadcast")), ".W.WW.",
> void_type_node, 5, pvoid_type_node, integer_type_node,
> pint_type, pchar_type_node, size_type_node);
>
>gfor_fndecl_co_max = gfc_build_library_function_decl_with_spec (
> - get_identifier (PREFIX("caf_co_max")), "W.WW",
> + get_identifier (PREFIX("caf_co_max")), ".W.WW..",
> void_type_node, 6, pvoid_type_node, integer_type_node,
> pint_type, pchar_type_node, integer_type_node, size_type_node);
>
>gfor_fndecl_co_min = gfc_build_library_function_decl_with_spec (
> - get_identifier (PREFIX("caf_co_min")), "W.WW",
> + get_identifier (PREFIX("caf_co_min")), ".W.WW..",
> void_type_node, 6, pvoid_type_node, integer_type_node,
> pint_type, pchar_type_node, integer_type_node, size_type_node);
>
>gfor_fndecl_co_reduce = gfc_build_library_function_decl_with_spec (
> - get_identifier (PREFIX("caf_co_reduce")), "W.R.WW",
> + get_identifier (PREFIX("caf_co_reduce")), ".W.R.WW..",
> void_type_node, 8, pvoid_type_node,
> build_pointer_type (build_varargs_function_type_list (void_type_node,
> NULL_TREE)),
> @@ -4053,12 +4053,12 @@ gfc_build_builtin_function_decls (void)
> integer_type_node, size_type_node);
>
>gfor_fndecl_co_sum = gfc_build_library_function_decl_with_spec (
> - get_identifier (PREFIX("caf_co_sum")), "W.WW",
> + get_identifier (PREFIX("caf_co_sum")), ".W.WW.",
> void_type_node, 5, pvoid_type_node, integer_type_node,
> pint_type, pchar_type_node, size_type_node);
>
>gfor_fndecl_caf_is_present = gfc_build_library_function_decl_with_spec
> (
> - get_identifier (PREFIX("caf_is_present")), "RRR",
> + get_identifier (PREFIX("caf_is_present")), ".R.R",
> integer_type_node, 3, pvoid_type_node, integer_type_node,
> pvoid_type_node);
> }
--
Andre Vehreschild * Email: vehre ad gmx dot de
Re: libgfortran caf API help needed: Fixing fnspec strings in trans-decl
Hi Honza, Tobias,
Yes, I am willing to help and will do so as soon as my small vacation ends
on Monday.
Regards,
Andre
Andre Vehreschild * ve...@gmx.de
Am 30. September 2020 19:12:48 schrieb Tobias Burnus :
Hi Honza,
On 9/30/20 6:12 PM, Jan Hubicka wrote:
_gfortran_caf_co_sum (gfc_descriptor_t *a __attribute__ ((unused)),
Should have fnspec
".XXWXX"
First dot represents return value, then X is for unused parameters
'X' is definitely wrong. In GCC there is only a stub implementation for
gfortran's coarray (Fortran) implemented. The full version needs
a communication library – such as MPI (Message Passing Interface)
or GASNet or OpenShMem ... Hence, that library is separate. The main point
of this stub library is to provide some means for testing.
See http://www.opencoarrays.org/ and
https://github.com/sourceryinstitute/opencoarrays/
for a (or rather: the) version which actually implements those
library functions.
I would apprechiate help from someone who knows the API to correct the
strings.
@Andre? How about you? ;-)
- gfor_fndecl_sr_kind = gfc_build_library_function_decl_with_spec (
- get_identifier (PREFIX("selected_real_kind2008")), ".RR",
+ gfor_fndecl_sr_kind = gfc_build_library_function_decl (
+ get_identifier (PREFIX("selected_real_kind2008")),
(This one is outside CAF.)
@Honza: I want to note that also for user functions, 'fn spec' are
generated, cf. create_fn_spec in trans-types.c – hopefully this one is fine.
Tobias
-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung,
Alexander Walter
Re: [Patch] Fortran: Avoid double-free with parse error (PR96041, PR93423)
Hi Tobias, I see. Then OK for trunk by me. - Andre On Wed, 16 Sep 2020 10:35:53 +0200 Tobias Burnus wrote: > Hi Andre, > > On 9/16/20 9:58 AM, Andre Vehreschild wrote: > > + st->n.sym = NULL; > > > > Don't we need free or unlink the st node from the symtree, too? > > I did not see a way to simply remove a single symtree; as this > is the error case, I left the item in the symtree. > > The symtree itself is removed when the 'contains' is > processed by calling: >gfc_free_namespace (...) > which calls >free_sym_tree (ns->sym_root) > and that function is: >if (sym_tree == NULL) > return; >free_sym_tree (sym_tree->left); >free_sym_tree (sym_tree->right); >gfc_release_symbol (sym_tree->n.sym); >free (sym_tree); > > This "gfc_release_symbol" was actually the call which > handled our "bp" symbol – deleting n.sym->formal. > > The parent namespace was still present and called > resolve_formal – which den caused the ICE as its > n.sym->formal was before deleted in "our" namespace. > > Tobias > > - > Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany > Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, > Alexander Walter -- Andre Vehreschild * Email: vehre ad gmx dot de
Re: [Patch] Fortran: Avoid double-free with parse error (PR96041, PR93423)
Hi Tobias,
diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index c612b492f3e..326e6f5db7a 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -9819,6 +9819,15 @@ gfc_match_submod_proc (void)
if (gfc_match_eos () != MATCH_YES)
{
+ /* Unset st->n.sym. Note: in reject_statement (), the symbol
changes are
+undone, such that the st->n.sym->formal points to the
original symbol;
+if now this namespace is finalized, the formal namespace is
freed,
+but it might be still needed in the parent namespace. */
+ gfc_symtree *st = gfc_find_symtree (gfc_current_ns->sym_root,
sym->name);
+ st->n.sym = NULL;
Don't we need free or unlink the st node from the symtree, too?
+ gfc_free_symbol (sym->tlink);
+ sym->tlink = NULL;
+ sym->refs--;
gfc_syntax_error (ST_MODULE_PROC);
return MATCH_ERROR;
}
Regards,
Andre
On Sat, 12 Sep 2020 23:00:12 +0200
Tobias Burnus wrote:
> The testcase for PR93423 did a double free, which caused
> an ICE. That's reported in PR96041.
>
> Slightly frustrated by the FAIL in the testsuite,
> I decided to debug and, hopefully, fix this.
>
> The problem is related to putting the symtree
> into a sub namespace of the symbol's ns. That's fixed up
> by copying things around – except in the error case where
> all those fixups are undone. Thus, when the symbol tree
> is deleted, the parent's sym->formal->sym is also deleted,
> causing an ICE in resolve_formal_arguments.
>
> Hopefully, I got this all right...
> I see still one memory leak for a symbol in module.c
> according to valgrind, but I don't know whether it is
> related to those symbols. (There are a lot of other leaks,
> mostly related to polymorphism (vtab etc.).)
>
> OK for the trunk?
>
> Tobias
>
--
Andre Vehreschild * Kreuzherrenstr. 8 * 52062 Aachen
Tel.: +49 178 3837536 * ve...@gmx.de
Re: [PATCH] Fortran : Two further previously missed ICEs PR53298
Hi Mark,
a few remarks:
[...]
> [PATCH] Fortran : Two further previously missed ICEs PR53298
>
> There were 3 ICEs with different call stacks in the comments of this
> PR. A previous commit fixed only one of those ICEs.
>
> The ICEs fixed here are in trans-array.c and trans-expr.c.
>
> The first ICE occurred when the array reference is not AR_ELEMENT
> gfc_conv_scalarized_array_ref is called with se and ar, if se->ss is
> NULL the ICE occurs. If se->ss is NULL there is nothing to do before
> the return.
>
> The second ICE occurs in code that did not match its comments. Fixing
> the code to match the comments fixes the ICE. A side affect is that
> the in the tree dumps for finalize_35.f90 and finalize_36.f90 contain
^^^
Spurious "the" found.
[...]
diff --git a/gcc/fortran/trans-array.c b/gcc/fortran/trans-array.c
index 6566c47d4ae..06268739515 100644
--- a/gcc/fortran/trans-array.c
+++ b/gcc/fortran/trans-array.c
@@ -3638,8 +3638,11 @@ gfc_conv_array_ref (gfc_se * se, gfc_array_ref *
ar, gfc_expr *expr, /* Handle scalarized references separately. */
if (ar->type != AR_ELEMENT)
{
- gfc_conv_scalarized_array_ref (se, ar);
- gfc_advance_se_ss_chain (se);
+ if (se->ss)
+ {
+ gfc_conv_scalarized_array_ref (se, ar);
+ gfc_advance_se_ss_chain (se);
+ }
Why is this only in element ref needed and not every else? When I tried
to fix ICEs this way, I was usually asked if was fixing symptom and not
the error.
return;
}
diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
index 36ff9b5cbc6..193553ace0b 100644
--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -2474,8 +2474,8 @@ gfc_conv_component_ref (gfc_se * se, gfc_ref *
ref) RECORD_TYPE within a UNION_TYPE) always use the given FIELD_DECL.
*/
if (context != TREE_TYPE (decl)
- && !( TREE_CODE (TREE_TYPE (field)) == UNION_TYPE /* Field is
union */
- || TREE_CODE (context) == UNION_TYPE)) /* Field is
map */
+ && ( TREE_CODE (context) == UNION_TYPE /* Field is union */
+ || TREE_CODE (context) == MAP_TYPE)) /* Field is map */
{
tree f2 = c->norestrict_decl;
if (!f2 || DECL_FIELD_CONTEXT (f2) != TREE_TYPE (decl))
(Sorry for the line breaks).
I can't help it, but the old code looked so dubious that I wonder why
it worked in the first place. Have you tried with a mapped type?
Regards,
Andre
--
Andre Vehreschild * ve...@gmx.de
Re: [PATCH] Fortran : ICE in build_field PR95614
Hi Marc, the patch looks reasonable and ok to me. Ok for trunk. Thanks for the patch. Regards, Andre On Fri, 4 Sep 2020 08:35:59 +0100 Mark Eggleston wrote: > Please find attached a fix for PR95614. The original patch was by Steve > Kargl. > > The original patch resulted in name clashes between global identifiers > naming common blocks and local identifiers. According to the 2018 > standard 19.3.1 Classes of local identifiers, item 2, a local identifier > shall not be the same as a global identifier, however, there is an > exception where the global identifier is a common block name. > > The change to the patch is: > > if (gsym && gsym->type != GSYM_UNKNOWN && gsym->type != GSYM_COMMON) > > instead of: > > if (gsym && gsym->type != GSYM_UNKNOWN) > > Tested on x86_64 using make -j 8 check-fortran. > > OK to commit? > > [PATCH] Fortran : ICE in build_field PR95614 > > Local identifiers can not be the same as a module name. Original > patch by Steve Kargl resulted in name clashes between common block > names and local identifiers. A local identifier can be the same as > a global identier if that identifier represents a common. The patch > was modified to allow global identifiers that represent a common > block. > > 2020-09-04 Steven G. Kargl > Mark Eggleston > > gcc/fortran/ > > PR fortran/95614 > * decl.c (gfc_get_common): Use gfc_match_common_name instead > of match_common_name. > * decl.c (gfc_bind_idents): Use gfc_match_common_name instead > of match_common_name. > * match.c : Rename match_common_name to gfc_match_common_name. > * match.c (gfc_match_common): Use gfc_match_common_name instead > of match_common_name. > * match.h : Rename match_common_name to gfc_match_common_name. > * resolve.c (resolve_common_vars): Check each symbol in a > common block has a global symbol. If there is a global symbol > issue an error if the symbol type is known as is not a common > block name. > > 2020-09-04 Mark Eggleston > > gcc/testsuite/ > > PR fortran/95614 > * gfortran.dg/pr95614_1.f90: New test. > * gfortran.dg/pr95614_2.f90: New test. > > -- Andre Vehreschild * Email: vehre ad gmx dot de
Re: [Patch] OpenMP/Fortran: Handle polymorphic scalars in data-sharing FIRSTPRIVATE (PR86470)
Hi Tobias,
in (look for ^^^):
diff --git a/gcc/fortran/trans-openmp.c b/gcc/fortran/trans-openmp.c
index 063d4c145e2..705cdc7749f 100644
--- a/gcc/fortran/trans-openmp.c
+++ b/gcc/fortran/trans-openmp.c
@@ -355,6 +355,51 @@ gfc_has_alloc_comps (tree type, tree decl)
return false;
}
+/* Return true if TYPE is polymorphic but not with pointer attribute. */
+
+static bool
+gfc_is_polymorphic_nonptr (tree type)
+{
+ if (POINTER_TYPE_P (type))
+type = TREE_TYPE (type);
+ if (TREE_CODE (type) != RECORD_TYPE)
+return false;
+
+ tree field = TYPE_FIELDS (type);
+ if (!field || 0 != strcmp ("_data", IDENTIFIER_POINTER (DECL_NAME (field
^^^ here you are comparing the field - name
+return false;
+ field = DECL_CHAIN (field);
+ if (!field || 0 != strcmp ("_vptr", IDENTIFIER_POINTER (DECL_NAME (field
+return false;
+
+ return true;
+}
+
+/* Return true if TYPE is unlimited polymorphic but not with pointer attribute;
+ unlimited means also intrinsic types are handled and _len is used. */
+
+static bool
+gfc_is_unlimited_polymorphic_nonptr (tree type)
+{
+ if (POINTER_TYPE_P (type))
+type = TREE_TYPE (type);
+ if (TREE_CODE (type) != RECORD_TYPE)
+return false;
+
+ tree field = TYPE_FIELDS (type); /* _data */
+ if (!field)
^^^ here you don't . So theoretically this routine could match a type which
has a _len as its third field, but that is not a unlim-poly class. Maybe factor
out the test from the above routine and unify with this one to reuse the test
for a BT_CLASS?!
+return false;
+ field = DECL_CHAIN (field); /* _vptr */
+ if (!field)
+return false;
+ field = DECL_CHAIN (field);
+ if (!field || 0 != strcmp ("_len", IDENTIFIER_POINTER (DECL_NAME (field
+return false;
+
+ return true;
+}
+
+
---
Btw, I believe the first routine can be better replaced by:
static bool
gfc_is_polymorphic_nonptr (tree type)
{
if (POINTER_TYPE_P (type))
type = TREE_TYPE (type);
return GFC_CLASS_TYPE_P (type);
}
I have no better solution for learning whether a tree's type is unlimited poly
yet.
@@ -740,6 +785,87 @@ gfc_omp_clause_copy_ctor (tree clause, tree dest, tree src)
gcc_assert (OMP_CLAUSE_CODE (clause) == OMP_CLAUSE_FIRSTPRIVATE
|| OMP_CLAUSE_CODE (clause) == OMP_CLAUSE_LINEAR);
+ /* TODO: implement support for polymorphic arrays; reject for now. */
+ /* Void arrays appear as var.0 = var._data.data. A bit hackish to
+ distinguish from 'type(c_ptr) :: var(5)' by scanning for '.';
+ this assumes that ASM_FORMAT_PRIVATE_NAME uses a '.', which most
+ systems do. */
+ if (TREE_CODE (type) == ARRAY_TYPE
+ && TREE_TYPE (type) == pvoid_type_node
+ && TREE_CODE (dest) == MEM_REF
+ && strchr (IDENTIFIER_POINTER (DECL_NAME (TREE_OPERAND (dest, 0))), '.'))
+fatal_error (input_location,
+"Sorry, polymorphic arrays not yet supported for "
+"firstprivate");
I totally agree that this is hackish and I don't like for that. But I can't
come up with a better solution at the moment.
The remainder looks ok to me.
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
Re: [Patch, fortran] PR96495 - [gfortran] Composition of user-defined operators does not copy ALLOCATABLE property of derived type
Hi Paul, your patch looks fine to me. Ok for trunk. Thanks for the patch. Regards, Andre On Sat, 29 Aug 2020 12:50:20 +0100 Paul Richard Thomas via Fortran wrote: > This patch detects a scalar function result that has allocatable components > and is being used inside a scalarization loop. Before this patch, the > components would be deallocated and nullified within the scalarization loop > and so would cause a segfault on the second cycle of the loop. > > The stored result has to be found by identifying the expression in the loop > ss chain. This is then used for the deallocation of the allocatable > components in the loop post block, which keeps gimple happy and prevents > the segfault. > > Regtests on FC31/x86_64 - OK for master? > > Paul > > This patch fixes PR96495 - frees result components outside loop. > > 2020-29-08 Paul Thomas > > gcc/fortran > PR fortran/96495 > * trans-expr.c (gfc_conv_procedure_call): Take the deallocation > of allocatable result components of a scalar result outside the > scalarization loop. Find and use the stored result. > > gcc/testsuite/ > PR fortran/96495 > * gfortran.dg/alloc_comp_result_2.f90 : New test. -- Andre Vehreschild * Email: vehre ad gmx dot de
Re: [Patch] Fortran: Fix absent-optional handling for nondescriptor arrays (PR94672)
Hi Tobias, the patch looks ok to me. Thanks for the patch. Regards, Andre On Wed, 26 Aug 2020 18:29:40 +0200 Tobias Burnus wrote: > This fixes an issue caused by the patch for PR 94672, which > affects both GCC 10 and GCC 11. > > Only 'sVal' of 'subroutine foo' was affected, the rest is > only a crosscheck that it worked for those code paths. > > (I did check against the dump – which looks fine. I could > add dump tests as well. The 'foo' test was failing with > 'stop 5' (absent argument) at runtime before the patch; > the report was for the 'stop 4' case, which is probably > harder to trigger as run-time fail as the stack memory > is likely zero-initialized. → -fdump-tree-original scan > test useful?) > > OK for mainline and GCC 10? > > Tobias > > - > Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany > Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, > Alexander Walter -- Andre Vehreschild * Email: vehre ad gmx dot de
[Patch, Fortran, Coarray] PR fortran/96418: Fix ICE on test when compiled with coarray=single
Hi,
attached patch fixes PR96418 where the code in the testsuite when compiled with
-fcoarray=single lead to an ICE. The reason was that the coarray object was
derefed as an array, but it was no array. Introducing the test for the
descriptor removes the ICE.
Regtests ok on x86_64-linux/FC31. Ok for trunk?
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
commit feb00c16ba50473e32a0c4adda470a0111603aed
Author: Andre Vehreschild
Date: Fri Aug 28 11:48:31 2020 +0200
Fix ICE when compiling with -fcoarray=single, when derefing a non-array.
gcc/fortran/ChangeLog:
PR fortran/96418
* trans.c (gfc_deallocate_with_status): Check that object to deref
is an array, before applying array deref.
gcc/testsuite/ChangeLog:
PR fortran/96418
* gfortran.dg/coarray_alloc_comp_3.f08: Moved to...
* gfortran.dg/coarray/alloc_comp_6.f08: ...here.
Should be tested for both -fcoarray=single and lib, resp.
* gfortran.dg/coarray_alloc_comp_4.f08: Fix program name.
diff --git a/gcc/fortran/trans.c b/gcc/fortran/trans.c
index ed054261452..1c23cdf8a0e 100644
--- a/gcc/fortran/trans.c
+++ b/gcc/fortran/trans.c
@@ -1374,7 +1374,8 @@ gfc_deallocate_with_status (tree pointer, tree status, tree errmsg,
else
caf_dereg_type = (enum gfc_coarray_deregtype) coarray_dealloc_mode;
}
- else if (flag_coarray == GFC_FCOARRAY_SINGLE)
+ else if (flag_coarray == GFC_FCOARRAY_SINGLE
+ && GFC_DESCRIPTOR_TYPE_P (TREE_TYPE (pointer)))
pointer = gfc_conv_descriptor_data_get (pointer);
}
else if (GFC_DESCRIPTOR_TYPE_P (TREE_TYPE (pointer)))
diff --git a/gcc/testsuite/gfortran.dg/coarray_alloc_comp_3.f08 b/gcc/testsuite/gfortran.dg/coarray/alloc_comp_6.f08
similarity index 95%
rename from gcc/testsuite/gfortran.dg/coarray_alloc_comp_3.f08
rename to gcc/testsuite/gfortran.dg/coarray/alloc_comp_6.f08
index e2037aa5809..8b153925129 100644
--- a/gcc/testsuite/gfortran.dg/coarray_alloc_comp_3.f08
+++ b/gcc/testsuite/gfortran.dg/coarray/alloc_comp_6.f08
@@ -1,12 +1,11 @@
! { dg-do run }
-! { dg-options "-fcoarray=lib -lcaf_single" }
! { dg-additional-options "-latomic" { target libatomic_available } }
!
! Contributed by Andre Vehreschild
! Check that manually freeing components does not lead to a runtime crash,
! when the auto-deallocation is taking care.
-program coarray_alloc_comp_3
+program alloc_comp_6
implicit none
type dt
diff --git a/gcc/testsuite/gfortran.dg/coarray_alloc_comp_4.f08 b/gcc/testsuite/gfortran.dg/coarray_alloc_comp_4.f08
index 6586ec651dd..4c71a90af8f 100644
--- a/gcc/testsuite/gfortran.dg/coarray_alloc_comp_4.f08
+++ b/gcc/testsuite/gfortran.dg/coarray_alloc_comp_4.f08
@@ -5,7 +5,7 @@
! Contributed by Andre Vehreschild
! Check that sub-components are caf_deregistered and not freed.
-program coarray_alloc_comp_3
+program coarray_alloc_comp_4
implicit none
type dt
Re: [Patch] Fortran: Add 'device_type' clause to OpenMP's declare target
Hi Tobias, to me this looks OK now. Regards, Andre On Thu, 20 Aug 2020 11:51:50 +0200 Tobias Burnus wrote: > Updated patch – taking Andre's suggestions into account + > extending the testcase, which now catches the previous (NO)HOST > module issue. > > OK? > > Tobias > > On 8/19/20 2:51 PM, Tobias Burnus wrote: > > Am 18.08.20 um 19:33 schrieb Andre Vehreschild: > >> +case OMP_DEVICE_TYPE_HOST: > >> + MIO_NAME (ab_attribute) (AB_OMP_DEVICE_TYPE_NOHOST, attr_bits); > >> Why also NOHOST here? > > Copy and paste error. > ... > >> + tree clauses = NULL_TREE; > >> Would you mind using "omp_clauses" or the like here? > Done now. > - > Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany > Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, > Alexander Walter -- Andre Vehreschild * Email: vehre ad gmx dot de
Re: [Patch, fortran, coarray] Fix obvious typo in co_broadcast's argument assembly
Hi,
commited with the input by Tobias applied. The full commit message now is:
Fix obvious typo were errmsg_len was assigned to errmsg.
gcc/fortran/ChangeLog:
2020-08-20 Andre Vehreschild
PR fortran/94958
* trans-array.c (gfc_bcast_alloc_comp): Use the correct variable.
Regards,
Andre
On Tue, 18 Aug 2020 19:27:50 +0200
Andre Vehreschild wrote:
> Hi Tobias,
>
> On Tue, 18 Aug 2020 19:14:30 +0200
> Tobias Burnus wrote:
>
> > On 8/18/20 7:04 PM, Andre Vehreschild wrote:
> >
> > > attached patch fixes an obvious typo in the routine gathering arguments
> > > for co_broadcast(). See pr94958 for a detailed analysis, please.
> >
> > LGTM – except that I do not like the ChangeLog entry.
> >
> > It sounds like a mispelling in terms of a comment or
> > error message. How about "Using the correct variable."
> > – or something like that?
>
> That's a good idea. Will use that.
>
> > You could also consider adding a libcaf_single test case,
> > given that you wrote one (see PR)...
>
> Well, the test case in the PR does not test the issue, only with additional
> modifications of trans-array one may see an impact in the pseudo code.
> Alternatively one has to do a lot more of code generation aggregating the
> results of the broadcasts of the different components. Given this is not
> defined in the standard, I am not sure what to do here. And therefore just
> wanted to correct the "miss-assignment" allowing future correct code
> generation.
>
> Regards,
> Andre
> >
> > Thanks for the patch!
> >
> > Tobias
> >
> > > gcc/fortran/ChangeLog:
> > >
> > > 2020-08-18 Andre Vehreschild
> > >
> > > PR fortran/94958
> > > * trans-array.c (gfc_bcast_alloc_comp): Fix typo.
> > >
> > >
> > > pr94958.patch
> > >
> > > diff --git a/gcc/fortran/trans-array.c b/gcc/fortran/trans-array.c
> > > index 7a1b2fc74c9..73a45cd2dcf 100644
> > > --- a/gcc/fortran/trans-array.c
> > > +++ b/gcc/fortran/trans-array.c
> > > @@ -9732,7 +9732,7 @@ gfc_bcast_alloc_comp (gfc_symbol *derived, gfc_expr
> > > *expr, int rank, args.image_index = image_index;
> > > args.stat = stat;
> > > args.errmsg = errmsg;
> > > - args.errmsg = errmsg_len;
> > > + args.errmsg_len = errmsg_len;
> > >
> > > if (rank == 0)
> > > {
> > -
> > Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München /
> > Germany Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung,
> > Alexander Walter
>
>
--
Andre Vehreschild * Email: vehre ad gmx dot de
Re: [Patch] Fortran: Add 'device_type' clause to OpenMP's declare target
Hi Tobias,
I am not deep in OMP dev, i.e., not at all, but this does not make sense to me:
@@ -2397,6 +2401,22 @@ mio_symbol_attribute (symbol_attribute *attr)
== OMP_REQ_ATOMIC_MEM_ORDER_RELAXED)
MIO_NAME (ab_attribute) (AB_OMP_REQ_MEM_ORDER_RELAXED, attr_bits);
}
+ switch (attr->omp_device_type)
+ {
+ case OMP_DEVICE_TYPE_UNSET:
+ break;
+ case OMP_DEVICE_TYPE_HOST:
+ MIO_NAME (ab_attribute) (AB_OMP_DEVICE_TYPE_NOHOST, attr_bits);
^
Why also NOHOST here? If this intentional please comment.
+ break;
+ case OMP_DEVICE_TYPE_NOHOST:
+ MIO_NAME (ab_attribute) (AB_OMP_DEVICE_TYPE_NOHOST, attr_bits);
+ break;
diff --git a/gcc/fortran/trans-common.c b/gcc/fortran/trans-common.c
index c6383fc2352..1be5e51b67d 100644
--- a/gcc/fortran/trans-common.c
+++ b/gcc/fortran/trans-common.c
@@ -426,6 +426,8 @@ build_common_decl (gfc_common_head *com, tree union_type,
bool is_init) /* If there is no backend_decl for the common block, build it. */
if (decl == NULL_TREE)
{
+ tree clauses = NULL_TREE;
Would you mind using "omp_clauses" or the like here?
The reminder looks good to my omp-unexperienced eye.
Regards,
Andre
On Fri, 7 Aug 2020 17:03:34 +0200
Tobias Burnus wrote:
> This patch adds the device_type(any|nohost|host)
> clause for 'omp declare target' to Fortran.
>
> In OpenMP 5.0, it has no effect on variables but
> only on procedures – in TR8 (and later), it also
> affects variables.
>
> This patch adds this clause to either – except that
> the middle end does not seem to like 'target link'
> with that clause – for normal variables, common
> blocks are accepted. (In line with OpenMP 5, the
> middle end ignores the clause for variables.)
>
> OK?
>
> Tobias
>
> -
> Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
> Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung,
> Alexander Walter
--
Andre Vehreschild * Email: vehre ad gmx dot de
Re: [Patch, fortran, coarray] Fix obvious typo in co_broadcast's argument assembly
Hi Tobias,
On Tue, 18 Aug 2020 19:14:30 +0200
Tobias Burnus wrote:
> On 8/18/20 7:04 PM, Andre Vehreschild wrote:
>
> > attached patch fixes an obvious typo in the routine gathering arguments for
> > co_broadcast(). See pr94958 for a detailed analysis, please.
>
> LGTM – except that I do not like the ChangeLog entry.
>
> It sounds like a mispelling in terms of a comment or
> error message. How about "Using the correct variable."
> – or something like that?
That's a good idea. Will use that.
> You could also consider adding a libcaf_single test case,
> given that you wrote one (see PR)...
Well, the test case in the PR does not test the issue, only with additional
modifications of trans-array one may see an impact in the pseudo code.
Alternatively one has to do a lot more of code generation aggregating the
results of the broadcasts of the different components. Given this is not
defined in the standard, I am not sure what to do here. And therefore just
wanted to correct the "miss-assignment" allowing future correct code generation.
Regards,
Andre
>
> Thanks for the patch!
>
> Tobias
>
> > gcc/fortran/ChangeLog:
> >
> > 2020-08-18 Andre Vehreschild
> >
> > PR fortran/94958
> > * trans-array.c (gfc_bcast_alloc_comp): Fix typo.
> >
> >
> > pr94958.patch
> >
> > diff --git a/gcc/fortran/trans-array.c b/gcc/fortran/trans-array.c
> > index 7a1b2fc74c9..73a45cd2dcf 100644
> > --- a/gcc/fortran/trans-array.c
> > +++ b/gcc/fortran/trans-array.c
> > @@ -9732,7 +9732,7 @@ gfc_bcast_alloc_comp (gfc_symbol *derived, gfc_expr
> > *expr, int rank, args.image_index = image_index;
> > args.stat = stat;
> > args.errmsg = errmsg;
> > - args.errmsg = errmsg_len;
> > + args.errmsg_len = errmsg_len;
> >
> > if (rank == 0)
> > {
> -
> Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
> Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung,
> Alexander Walter
--
Andre Vehreschild * Email: vehre ad gmx dot de
[Patch, fortran, coarray] Fix obvious typo in co_broadcast's argument assembly
Hi all,
attached patch fixes an obvious typo in the routine gathering arguments for
co_broadcast(). See pr94958 for a detailed analysis, please.
Regtests ok on FC31/x86_64. Will commit as obvious on Thursday, if no one
objects.
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
gcc/fortran/ChangeLog:
2020-08-18 Andre Vehreschild
PR fortran/94958
* trans-array.c (gfc_bcast_alloc_comp): Fix typo.
diff --git a/gcc/fortran/trans-array.c b/gcc/fortran/trans-array.c
index 7a1b2fc74c9..73a45cd2dcf 100644
--- a/gcc/fortran/trans-array.c
+++ b/gcc/fortran/trans-array.c
@@ -9732,7 +9732,7 @@ gfc_bcast_alloc_comp (gfc_symbol *derived, gfc_expr *expr, int rank,
args.image_index = image_index;
args.stat = stat;
args.errmsg = errmsg;
- args.errmsg = errmsg_len;
+ args.errmsg_len = errmsg_len;
if (rank == 0)
{
Re: [Patch, fortran] PRs 96100 and 96101 - Problems with string lengths of array constructors
Hi Paul, > The fix for PR9601 is rather trivial and is the last chunk of the patch. > Finding the fix for PR96100 took a silly amount of time but it now looks > rather obvious. Trying to evaluate the string length by calling > gfc_conv_expr_descriptor, when this function is already failing to find it > is kind of doomed to failure :-) Therefore, gfc_conv_expr is used with > tse.descriptor_only set. This has the effect of ignoring trailing array > references and making use of gfc_conv_component_ref's being able to extract > the hidden string length for deferred length components. Finally, the > string length of the first element in the array constructor is set if this > is a deferred length component. The patch seems to be effective. Albeit I don't understand why, when it is a parenthesis op, you deduce that this has to be the string length? The explanation for the second fix left me completely lost. > Regtests OK on FC31/x86_64 - OK for master? Tests ok with no regression. Therefore ok by me. Regards, Andre > > Paul > > This patch fixes PR96100 and PR96101 by making some minor changes to > the evaluation of string lengths for gfc_conv_expr_descriptor. > > 2020-08-13 Paul Thomas > > gcc/fortran > PR fortran/96100 > PR fortran/96101 > * trans-array.c (get_array_charlen): Tidy up the evaluation of > the string length for array constructors. Avoid trailing array > references. Ensure string lengths of deferred length components > are set. For parentheses operator apply string length to both > the primary expression and the enclosed expression. > > gcc/testsuite/ > PR fortran/96100 > PR fortran/96101 > * gfortran.dg/char_length_23.f90: New test. -- Andre Vehreschild * Email: vehre ad gmx dot de
Re: [Patch, fortran] PR93671 - gfortran 8-10 ICE on intrinsic assignment to allocatable derived-type component of coarray
Hi Thomas, thanks for the review. Committed to trunk. That's what I am here for: to fix some issues with coarrays. Regards, Andre On Wed, 12 Aug 2020 18:58:01 +0200 Thomas Koenig wrote: > Hi Andre, > > > Regtests ok on FC31.x86_64. Ok for trunk? > > Good thing you're back! Any help with bugfixing is > highly appreciated, and Coarrays certainly can use > some work. > > The patch is OK for trunk. > > Best regards > > Thomas -- Andre Vehreschild * Email: vehre ad gmx dot de
[Patch, fortran] PR93671 - gfortran 8-10 ICE on intrinsic assignment to allocatable derived-type component of coarray
Hi folks,
long time, no see. I was asked by Damian to do some Coarray stuff in gfortran
so here is the first step on fixing a bug. The issue at hand is, that the
coarray handling is not propagated correctly and later on the coarray-token
not generated/retrieved from the correct position leading to coarray programs to
crash/hang. This patch fixes at least the misbehavior reported in the PR. More
to come.
Regtests ok on FC31.x86_64. Ok for trunk?
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
gcc/fortran/ChangeLog:
2020-08-10 Andre Vehreschild
PR fortran/93671
* trans-array.c (structure_alloc_comps): Keep caf-mode when applying to
components; get the caf_token correctly for allocated scalar components.
gcc/testsuite/ChangeLog:
2020-08-10 Andre Vehreschild
PR fortran/93671
* gfortran.dg/coarray/pr93671.f90: New test.
diff --git a/gcc/fortran/trans-array.c b/gcc/fortran/trans-array.c
index 8f93b43bafb..7a1b2fc74c9 100644
--- a/gcc/fortran/trans-array.c
+++ b/gcc/fortran/trans-array.c
@@ -8627,14 +8627,13 @@ structure_alloc_comps (gfc_symbol * der_type, tree decl,
vref = gfc_build_array_ref (var, index, NULL);
- if ((purpose == COPY_ALLOC_COMP || purpose == COPY_ONLY_ALLOC_COMP)
- && !caf_enabled (caf_mode))
+ if (purpose == COPY_ALLOC_COMP || purpose == COPY_ONLY_ALLOC_COMP)
{
tmp = build_fold_indirect_ref_loc (input_location,
gfc_conv_array_data (dest));
dref = gfc_build_array_ref (tmp, index, NULL);
tmp = structure_alloc_comps (der_type, vref, dref, rank,
- COPY_ALLOC_COMP, 0, args);
+ COPY_ALLOC_COMP, caf_mode, args);
}
else
tmp = structure_alloc_comps (der_type, vref, NULL_TREE, rank, purpose,
@@ -9375,12 +9374,21 @@ structure_alloc_comps (gfc_symbol * der_type, tree decl,
else if (flag_coarray == GFC_FCOARRAY_LIB
&& caf_in_coarray (caf_mode))
{
- tree dst_tok = c->as ? gfc_conv_descriptor_token (dcmp)
- : fold_build3_loc (input_location,
- COMPONENT_REF,
- pvoid_type_node, dest,
- c->caf_token,
- NULL_TREE);
+ tree dst_tok;
+ if (c->as)
+ dst_tok = gfc_conv_descriptor_token (dcmp);
+ else
+ {
+ /* For a scalar allocatable component the caf_token is
+ the next component. */
+ if (!c->caf_token)
+ c->caf_token = c->next->backend_decl;
+ dst_tok = fold_build3_loc (input_location,
+ COMPONENT_REF,
+ pvoid_type_node, dest,
+ c->caf_token,
+ NULL_TREE);
+ }
tmp = duplicate_allocatable_coarray (dcmp, dst_tok, comp,
ctype, rank);
}
diff --git a/gcc/testsuite/gfortran.dg/coarray/pr93671.f90 b/gcc/testsuite/gfortran.dg/coarray/pr93671.f90
new file mode 100644
index 000..8d26ff88753
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/coarray/pr93671.f90
@@ -0,0 +1,24 @@
+! { dg-do run }
+
+! PR/fortran 93671 - ICE on intrinsic assignment to allocatable derived-type
+!component of coarray
+
+ type flux_planes
+integer, allocatable :: normals
+ end type
+
+ type package
+type(flux_planes) surface_fluxes(1)
+ end type
+
+ type(package) mail[*], halo_data
+
+ halo_data%surface_fluxes(1)%normals = 1
+ mail = halo_data
+
+ if (any(size(mail%surface_fluxes) /= [1]) .OR. &
+ mail%surface_fluxes(1)%normals /= 1) then
+stop 1
+ end if
+end
+
Re: [PATCH] Fortran cleanup patch
On Thu, 10 May 2018 16:08:17 -0700 Steve Kargl <s...@troutmask.apl.washington.edu> wrote: > The attached patch removed an unused function. > OK to commit? Removing unused code, can only make things easier. Ok to commit IMHO. - Andre > > 2018-05-10 Steven G. Kargl <ka...@gcc.gnu.org> > >* gfortran.h: Remove prototype. >* symbol.c (gfc_new_undo_checkpoint): Remove unused function. > -- Andre Vehreschild * Email: vehre ad gmx dot de
Re: [PATCH] PR fortran/85521 -- Zero length substrings in array aconstructors
Hi, sorry, I didn't get, that this is standard conforming. So go for it: Ok for trunk and thanks for the patch. - Andre On Thu, 10 May 2018 08:41:21 -0700 Steve Kargl <s...@troutmask.apl.washington.edu> wrote: > It is certainly possible to give a warning, but it > would be odd (to me) to warn about technically > standard conforming code. gfortran doesn't warn > for zero-sized array references or zero-length > substrings in other context. > > program foo >real a(4) >character(len=10) s >s = '12345' >a = 1 >print *, size(a(2:1)), len(s(3:2)) > end program foo > % gfc -o z a.f90 > % ./z >0 0 > -- Andre Vehreschild * Email: vehre ad gmx dot de
Re: Document PR 84073 change in /gcc-8/porting_to.html
Hi Thomas, looks ok to me. - Andre On Thu, 10 May 2018 17:19:39 +0200 Thomas König <t...@tkoenig.net> wrote: > Am 10.05.2018 um 14:20 schrieb Thomas Koenig: > > Am 10.05.2018 um 12:33 schrieb Jonathan Wakely: > >> Should the fix for PR 84073 be documented, so that users whose code is > >> now rejected understand why, and how to fix it? > >> > >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84073 > >> https://gcc.gnu.org/gcc-8/porting_to.html#fortran > > > > Sounds like a good idea. > > > > Since I introduced this, I'll do it within a few days (unless, of > > course, somebody beats me to it, which I won't mind :-) > > OK, not a few days, but a few hours :-) > > Here is the diff. OK to commit to gcc-docs? > > Regards > > Thomas > > -- Andre Vehreschild * Email: vehre ad gmx dot de
Re: [PATCH] PR fortran/70870 -- Reject data object with default initialization
Hi Steve, ok for trunk. - Andre On Wed, 9 May 2018 15:32:10 -0700 Steve Kargl <s...@troutmask.apl.washington.edu> wrote: > I plan to commit the attach patch on Saturday unless someone objects. > > 2018-05-09 Steven G. Kargl <ka...@gcc.gnu.org> > > PR fortran/70870 > * data.c (gfc_assign_data_value): Check that a data object does > not also have default initialization. > > 2018-05-09 Steven G. Kargl <ka...@gcc.gnu.org> > > PR fortran/70870 > * gfortran.dg/pr70870_1.f90: New test. > -- Andre Vehreschild * Email: vehre ad gmx dot de
Re: [PATCH] PR fortran/85521 -- Zero length substrings in array aconstructors
Hi Steve,
the patch looks OK to me. Is it possible to give a warning there, at least with
some higher warning-level? Or is there already one? I haven't tested it.
Regards,
Andre
On Thu, 10 May 2018 07:15:21 -0700
Steve Kargl <s...@troutmask.apl.washington.edu> wrote:
> On Thu, May 10, 2018 at 11:48:24AM +0200, Dominique d'Humières wrote:
> > Hi Steve,
> >
> > AFAICT the patch is missing.
> >
> > Thanks for working on these PRs.
> >
>
> Whoops. Looks like attached the log instead of diff.
>
> Index: gcc/fortran/array.c
> ===
> --- gcc/fortran/array.c (revision 259945)
> +++ gcc/fortran/array.c (working copy)
> @@ -2046,7 +2046,8 @@ got_charlen:
> else
> return true;
>
> - gcc_assert (current_length != -1);
> + if (current_length < 0)
> + current_length = 0;
>
> if (found_length == -1)
> found_length = current_length;
> Index: gcc/testsuite/gfortran.dg/pr85521_1.f90
> ===
> --- gcc/testsuite/gfortran.dg/pr85521_1.f90 (nonexistent)
> +++ gcc/testsuite/gfortran.dg/pr85521_1.f90 (working copy)
> @@ -0,0 +1,8 @@
> +! { dg-do compile }
> +! PR fortran/85521
> +program p
> + character(3) :: c = 'abc'
> + character(3) :: z(1)
> + z = [ c(:-1) ]
> + print *, z
> +end
> Index: gcc/testsuite/gfortran.dg/pr85521_2.f90
> ===
> --- gcc/testsuite/gfortran.dg/pr85521_2.f90 (nonexistent)
> +++ gcc/testsuite/gfortran.dg/pr85521_2.f90 (working copy)
> @@ -0,0 +1,8 @@
> +! { dg-do compile }
> +! PR fortran/85521
> +program p
> + character(3) :: c = 'abc'
> + character(3) :: z(1)
> + z = [ c(:-2) ]
> + print *, z
> +end
>
--
Andre Vehreschild * Email: vehre ad gmx dot de
Re: [Patch, Fortran, pr85507, v1] Modell variable dependencies in coarray expression correctly.
Hi Jerry,
thanks for the review. Applied to
trunk as r259974
gcc-8 as r259979
gcc-7 as r259977, and
gcc-6 as r259978.
The diffs for trunk to gcc-7 are merely the same and given as submit.diff only.
The diff for gcc-6 has some small adaptions in a testcase and is therefore
attached separately.
Regards,
Andre
On Sat, 5 May 2018 09:38:08 -0700
Jerry DeLisle <jvdeli...@charter.net> wrote:
> On 04/30/2018 01:52 AM, Andre Vehreschild wrote:
> > Hi all,
> >
> > attached patch partially reverts r259385 preventing an ICE. At the same time
> > the check_dependency routine is parameterized correctly so that variable
> > dependencies in coarray expressions are determined more precisely.
> >
> > Bootstrapped and regtested ok on x86_64-linux-gnu/f27. Ok for trunk,
> > gcc-8/-7/-6?
> >
> > Regards,
> > Andre
> >
>
> Yes, OK, assuming also all OpenCoarrays test cases also pass.
>
> Jerry
--
Andre Vehreschild * Email: vehre ad gmx dot de
Index: gcc/testsuite/gfortran.dg/coarray_lib_comm_1.f90
===
--- gcc/testsuite/gfortran.dg/coarray_lib_comm_1.f90 (Revision 259973)
+++ gcc/testsuite/gfortran.dg/coarray_lib_comm_1.f90 (Arbeitskopie)
@@ -38,9 +38,8 @@
if (any (A-B /= 0)) STOP 4
end
-! { dg-final { scan-tree-dump-times "_gfortran_caf_get \\\(caf_token.0, \\\(integer\\\(kind=\[48\]\\\)\\\) parm.\[0-9\]+.data - \\\(integer\\\(kind=\[48\]\\\)\\\) a, 1, \[0-9\]+, 0B, \[0-9\]+, 4, 4, 0, 0B\\\);" 1 "original" } }
-! { dg-final { scan-tree-dump-times "_gfortran_caf_get \\\(caf_token.0, \\\(integer\\\(kind=\[48\]\\\)\\\) parm.\[0-9\]+.data - \\\(integer\\\(kind=\[48\]\\\)\\\) a, 1, \[0-9\]+, 0B, \[0-9\]+, 4, 4, 1, 0B\\\);" 1 "original" } }
+! { dg-final { scan-tree-dump-times "_gfortran_caf_get \\\(caf_token.0, \\\(integer\\\(kind=\[48\]\\\)\\\) parm.\[0-9\]+.data - \\\(integer\\\(kind=\[48\]\\\)\\\) a, 1, \[0-9\]+, 0B, \[0-9\]+, 4, 4, 1, 0B\\\);" 2 "original" } }
! { dg-final { scan-tree-dump-times "_gfortran_caf_get \\\(caf_token.0, \\\(integer\\\(kind=\[48\]\\\)\\\) parm.\[0-9\]+.data - \\\(integer\\\(kind=\[48\]\\\)\\\) a, 1, \[0-9\]+, 0B, , 4, 4, 1, 0B\\\);" 1 "original" } }
! { dg-final { scan-tree-dump-times "_gfortran_caf_get \\\(caf_token.1, \\\(integer\\\(kind=\[48\]\\\)\\\) parm.\[0-9\]+.data - \\\(integer\\\(kind=\[48\]\\\)\\\) b, 1, \[0-9\]+, 0B, , 4, 4, 0, 0B\\\);" 1 "original" } }
-! { dg-final { scan-tree-dump-times "_gfortran_caf_sendget \\\(caf_token.0, \\\(integer\\\(kind=\[48\]\\\)\\\) parm.\[0-9\]+.data - \\\(integer\\\(kind=\[48\]\\\)\\\) a, 1, \[0-9\]+, 0B, caf_token.0, \\\(integer\\\(kind=\[48\]\\\)\\\) parm.\[0-9\]+.data - \\\(integer\\\(kind=\[48\]\\\)\\\) a, 1, \[0-9\]+, 0B, 4, 4, 0, 0B\\\);" 1 "original" } }
+! { dg-final { scan-tree-dump-times "_gfortran_caf_sendget \\\(caf_token.0, \\\(integer\\\(kind=\[48\]\\\)\\\) parm.\[0-9\]+.data - \\\(integer\\\(kind=\[48\]\\\)\\\) a, 1, \[0-9\]+, 0B, caf_token.0, \\\(integer\\\(kind=\[48\]\\\)\\\) parm.\[0-9\]+.data - \\\(integer\\\(kind=\[48\]\\\)\\\) a, 1, \[0-9\]+, 0B, 4, 4, 1, 0B\\\);" 1 "original" } }
Index: gcc/testsuite/gfortran.dg/coarray_dependency_1.f90
===
--- gcc/testsuite/gfortran.dg/coarray_dependency_1.f90 (nicht existent)
+++ gcc/testsuite/gfortran.dg/coarray_dependency_1.f90 (Revision 259974)
@@ -0,0 +1,11 @@
+! { dg-do compile }
+! { dg-options "-fcoarray=lib -lcaf_single" }
+!
+! Check that reffing x on both sides of a coarray send does not ICE.
+! PR 85507
+
+program check_dependency
+ integer :: x[*]
+ x[42] = x
+end program check_dependency
+
Index: gcc/testsuite/ChangeLog
===
--- gcc/testsuite/ChangeLog (Revision 259973)
+++ gcc/testsuite/ChangeLog (Arbeitskopie)
@@ -1,3 +1,9 @@
+2018-05-06 Andre Vehreschild <ve...@gcc.gnu.org>
+
+ PR fortran/85507
+ * gfortran.dg/coarray_dependency_1.f90: New test.
+ * gfortran.dg/coarray_lib_comm_1.f90: Fix counting caf-expressions.
+
2018-05-04 Pekka Jääskeläinen <pekka.jaaskelai...@parmance.com>
* testsuite/brig.dg/test/gimple/smoke_test.hsail: Fix the test
Index: gcc/fortran/dependency.c
===
--- gcc/fortran/dependency.c (Revision 259973)
+++ gcc/fortran/dependency.c (Arbeitskopie)
@@ -2238,9 +2238,8 @@
break;
/* Exactly matching and forward overlapping ranges don't cause a
- dependency, when they are not part of a coarray ref. */
- if (fin_dep < GFC_DEP_BACKWARD
- && lref->u.ar.codimen == 0 && rref->u.ar.codimen == 0)
+ dependency. */
+ if (fin_dep < GFC_DEP_BACKWARD)
retur
[Patch, Fortran, pr85507, v1] Modell variable dependencies in coarray expression correctly.
Hi all,
attached patch partially reverts r259385 preventing an ICE. At the same time
the check_dependency routine is parameterized correctly so that variable
dependencies in coarray expressions are determined more precisely.
Bootstrapped and regtested ok on x86_64-linux-gnu/f27. Ok for trunk,
gcc-8/-7/-6?
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
gcc/fortran/ChangeLog:
2018-04-30 Andre Vehreschild <ve...@gcc.gnu.org>
PR fortran/85507
* dependency.c (gfc_dep_resolver): Revert looking at coarray dimension
introduced by r259385.
* trans-intrinsic.c (conv_caf_send): Always report a dependency for
same variables in coarray assignments.
gcc/testsuite/ChangeLog:
2018-04-30 Andre Vehreschild <ve...@gcc.gnu.org>
PR fortran/85507
* gfortran.dg/coarray_dependency_1.f90: New test.
* gfortran.dg/coarray_lib_comm_1.f90: Fix counting caf-expressions.
diff --git a/gcc/fortran/dependency.c b/gcc/fortran/dependency.c
index 3e14ddc25d8..a0bbd584947 100644
--- a/gcc/fortran/dependency.c
+++ b/gcc/fortran/dependency.c
@@ -2238,9 +2238,8 @@ gfc_dep_resolver (gfc_ref *lref, gfc_ref *rref, gfc_reverse *reverse)
break;
/* Exactly matching and forward overlapping ranges don't cause a
- dependency, when they are not part of a coarray ref. */
- if (fin_dep < GFC_DEP_BACKWARD
- && lref->u.ar.codimen == 0 && rref->u.ar.codimen == 0)
+ dependency. */
+ if (fin_dep < GFC_DEP_BACKWARD)
return 0;
/* Keep checking. We only have a dependency if
diff --git a/gcc/fortran/trans-intrinsic.c b/gcc/fortran/trans-intrinsic.c
index 00edd447bb2..87b3ca72c05 100644
--- a/gcc/fortran/trans-intrinsic.c
+++ b/gcc/fortran/trans-intrinsic.c
@@ -1860,7 +1860,7 @@ conv_caf_send (gfc_code *code) {
lhs_expr = code->ext.actual->expr;
rhs_expr = code->ext.actual->next->expr;
- may_require_tmp = gfc_check_dependency (lhs_expr, rhs_expr, false) == 0
+ may_require_tmp = gfc_check_dependency (lhs_expr, rhs_expr, true) == 0
? boolean_false_node : boolean_true_node;
gfc_init_block ();
diff --git a/gcc/testsuite/gfortran.dg/coarray_dependency_1.f90 b/gcc/testsuite/gfortran.dg/coarray_dependency_1.f90
new file mode 100644
index 000..dc4cbacba1e
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/coarray_dependency_1.f90
@@ -0,0 +1,11 @@
+! { dg-do compile }
+! { dg-options "-fcoarray=lib -lcaf_single" }
+!
+! Check that reffing x on both sides of a coarray send does not ICE.
+! PR 85507
+
+program check_dependency
+ integer :: x[*]
+ x[42] = x
+end program check_dependency
+
diff --git a/gcc/testsuite/gfortran.dg/coarray_lib_comm_1.f90 b/gcc/testsuite/gfortran.dg/coarray_lib_comm_1.f90
index a7567af7b8f..171a27bd4c3 100644
--- a/gcc/testsuite/gfortran.dg/coarray_lib_comm_1.f90
+++ b/gcc/testsuite/gfortran.dg/coarray_lib_comm_1.f90
@@ -38,9 +38,8 @@ B(1:5) = B(3:7)
if (any (A-B /= 0)) STOP 4
end
-! { dg-final { scan-tree-dump-times "_gfortran_caf_get \\\(caf_token.0, \\\(integer\\\(kind=\[48\]\\\)\\\) parm.\[0-9\]+.data - \\\(integer\\\(kind=\[48\]\\\)\\\) a, 1, \[0-9\]+, 0B, \[0-9\]+, 4, 4, 0, 0B\\\);" 1 "original" } }
-! { dg-final { scan-tree-dump-times "_gfortran_caf_get \\\(caf_token.0, \\\(integer\\\(kind=\[48\]\\\)\\\) parm.\[0-9\]+.data - \\\(integer\\\(kind=\[48\]\\\)\\\) a, 1, \[0-9\]+, 0B, \[0-9\]+, 4, 4, 1, 0B\\\);" 1 "original" } }
+! { dg-final { scan-tree-dump-times "_gfortran_caf_get \\\(caf_token.0, \\\(integer\\\(kind=\[48\]\\\)\\\) parm.\[0-9\]+.data - \\\(integer\\\(kind=\[48\]\\\)\\\) a, 1, \[0-9\]+, 0B, \[0-9\]+, 4, 4, 1, 0B\\\);" 2 "original" } }
! { dg-final { scan-tree-dump-times "_gfortran_caf_get \\\(caf_token.0, \\\(integer\\\(kind=\[48\]\\\)\\\) parm.\[0-9\]+.data - \\\(integer\\\(kind=\[48\]\\\)\\\) a, 1, \[0-9\]+, 0B, , 4, 4, 1, 0B\\\);" 1 "original" } }
! { dg-final { scan-tree-dump-times "_gfortran_caf_get \\\(caf_token.1, \\\(integer\\\(kind=\[48\]\\\)\\\) parm.\[0-9\]+.data - \\\(integer\\\(kind=\[48\]\\\)\\\) b, 1, \[0-9\]+, 0B, , 4, 4, 0, 0B\\\);" 1 "original" } }
-! { dg-final { scan-tree-dump-times "_gfortran_caf_sendget \\\(caf_token.0, \\\(integer\\\(kind=\[48\]\\\)\\\) parm.\[0-9\]+.data - \\\(integer\\\(kind=\[48\]\\\)\\\) a, 1, \[0-9\]+, 0B, caf_token.0, \\\(integer\\\(kind=\[48\]\\\)\\\) parm.\[0-9\]+.data - \\\(integer\\\(kind=\[48\]\\\)\\\) a, 1, \[0-9\]+, 0B, 4, 4, 0, 0B\\\);" 1 "original" } }
+! { dg-final { scan-tree-dump-times "_gfortran_caf_sendget \\\(caf_token.0, \\\(integer\\\(kind=\[48\]\\\)\\\) parm.\[0-9\]+.data - \\\(integer\\\(kind=\[48\]\\\)\\\) a, 1, \[0-9\]+, 0B, caf_token.0, \\\(integer\\\(kind=\[48\]\\\)\\\) parm.\[0-9\]+.data - \\\(integer\\\(kind=\[48\]\\\)\\\) a, 1, \[0-9\]+, 0B, 4, 4, 1, 0B\\\);" 1 "original" } }
Re: [Ping, Fortran, Patch, PR81773, PR83606, coarray, v1] Fix coarray get to array with vector indexing
Hi all,
because pr81773 is a 6-/7-/8-regression I have backported it to gcc-6 as r259741
and gcc-7 as r259742.
Regards,
Andre
On Sat, 14 Apr 2018 16:46:53 +0200
Andre Vehreschild <ve...@gmx.de> wrote:
> Hi Paul,
>
> thank you for the review. Committed as r259385.
>
> Regards,
> Andre
>
> On Sat, 14 Apr 2018 11:53:44 +0100
> Paul Richard Thomas <paul.richard.tho...@gmail.com> wrote:
>
> > Hi Andre,
> >
> > This is OK for trunk.
> >
> > Thanks for the patch
> >
> > Paul
> >
> >
> > On 13 April 2018 at 08:34, Andre Vehreschild <ve...@gmx.de> wrote:
> > > Ping
> > >
> > > On Sun, 8 Apr 2018 14:25:50 +0200
> > > Andre Vehreschild <ve...@gmx.de> wrote:
> > >
> > >> Hi all,
> > >>
> > >> attached patch fixes (to my knowledge) the two PRs 81773 and 83606 where
> > >> the result of a coarray get() operation is assigned to an array using a
> > >> vector as index. It took me quite long to get it right, because I had to
> > >> use the scalarizer which I haven't use directly before. So reviewers with
> > >> expertise on using the scalarizer are especially welcome.
> > >>
> > >> Bootstrapped and regtested on x86_64-linux/f27.
> > >>
> > >> Ok for trunk? Backports?
> > >>
> > >> Regards,
> > >> Andre
> > >
> > >
> > > --
> > > Andre Vehreschild * Email: vehre ad gmx dot de
> >
> >
> >
>
>
--
Andre Vehreschild * Email: vehre ad gmx dot de
Index: gcc/fortran/ChangeLog
===
--- gcc/fortran/ChangeLog (Revision 259739)
+++ gcc/fortran/ChangeLog (Arbeitskopie)
@@ -1,3 +1,16 @@
+2018-04-28 Andre Vehreschild <ve...@gcc.gnu.org>
+
+ PR fortran/81773
+ PR fortran/83606
+ Backport from trunk.
+ * dependency.c (gfc_dep_resolver): Coarray indexes are to be ignored
+ during dependency computation. They define no data dependency.
+ * trans-array.c (conv_array_index_offset): The stride can not be set
+ here, prevent fail.
+ * trans-intrinsic.c (conv_caf_send): Add creation of temporary array
+ for caf_get's result and copying to the array with vectorial
+ indexing.
+
2018-04-24 Steven G. Kargl <ka...@gcc.gnu.org>
PR fortran/85520
Index: gcc/fortran/dependency.c
===
--- gcc/fortran/dependency.c (Revision 259739)
+++ gcc/fortran/dependency.c (Arbeitskopie)
@@ -2239,8 +2239,9 @@
break;
/* Exactly matching and forward overlapping ranges don't cause a
- dependency. */
- if (fin_dep < GFC_DEP_BACKWARD)
+ dependency, when they are not part of a coarray ref. */
+ if (fin_dep < GFC_DEP_BACKWARD
+ && lref->u.ar.codimen == 0 && rref->u.ar.codimen == 0)
return 0;
/* Keep checking. We only have a dependency if
Index: gcc/fortran/trans-array.c
===
--- gcc/fortran/trans-array.c (Revision 259739)
+++ gcc/fortran/trans-array.c (Arbeitskopie)
@@ -3022,7 +3022,7 @@
}
/* Multiply by the stride. */
- if (!integer_onep (stride))
+ if (stride != NULL && !integer_onep (stride))
index = fold_build2_loc (input_location, MULT_EXPR, gfc_array_index_type,
index, stride);
Index: gcc/fortran/trans-intrinsic.c
===
--- gcc/fortran/trans-intrinsic.c (Revision 259739)
+++ gcc/fortran/trans-intrinsic.c (Arbeitskopie)
@@ -1266,34 +1266,124 @@
}
else
{
- /* If has_vector, pass descriptor for whole array and the
- vector bounds separately. */
- gfc_array_ref *ar, ar2;
- bool has_vector = false;
+ bool has_vector = gfc_has_vector_subscript (lhs_expr);
- if (gfc_is_coindexed (lhs_expr) && gfc_has_vector_subscript (lhs_expr))
+ if (gfc_is_coindexed (lhs_expr) || !has_vector)
{
- has_vector = true;
- ar = gfc_find_array_ref (lhs_expr);
- ar2 = *ar;
- memset (ar, '\0', sizeof (*ar));
- ar->as = ar2.as;
- ar->type = AR_FULL;
+ /* If has_vector, pass descriptor for whole array and the
+ vector bounds separately. */
+ gfc_array_ref *ar, ar2;
+ bool has_tmp_lhs_array = false;
+ if (has_vector)
+ {
+ has_tmp_lhs_array = true;
+ ar = gfc_find_array_ref (lhs_expr);
+ ar2 = *ar;
+ memset (ar, '\0', sizeof (*ar));
+ ar->as = ar2.as;
+ ar->type = AR_FULL;
+ }
+ lhs_se.want_pointer = 1;
+ gfc_conv_expr_descriptor (_se, lhs_expr);
+ /* Using gfc_conv_expr_descriptor, we only get the descriptor, but
+ t
Re: [Ping, Fortran, Patch, PR81773, PR83606, coarray, v1] Fix coarray get to array with vector indexing
Hi Paul,
thank you for the review. Committed as r259385.
Regards,
Andre
On Sat, 14 Apr 2018 11:53:44 +0100
Paul Richard Thomas <paul.richard.tho...@gmail.com> wrote:
> Hi Andre,
>
> This is OK for trunk.
>
> Thanks for the patch
>
> Paul
>
>
> On 13 April 2018 at 08:34, Andre Vehreschild <ve...@gmx.de> wrote:
> > Ping
> >
> > On Sun, 8 Apr 2018 14:25:50 +0200
> > Andre Vehreschild <ve...@gmx.de> wrote:
> >
> >> Hi all,
> >>
> >> attached patch fixes (to my knowledge) the two PRs 81773 and 83606 where
> >> the result of a coarray get() operation is assigned to an array using a
> >> vector as index. It took me quite long to get it right, because I had to
> >> use the scalarizer which I haven't use directly before. So reviewers with
> >> expertise on using the scalarizer are especially welcome.
> >>
> >> Bootstrapped and regtested on x86_64-linux/f27.
> >>
> >> Ok for trunk? Backports?
> >>
> >> Regards,
> >> Andre
> >
> >
> > --
> > Andre Vehreschild * Email: vehre ad gmx dot de
>
>
>
--
Andre Vehreschild * Email: vehre ad gmx dot de
Index: gcc/fortran/ChangeLog
===
--- gcc/fortran/ChangeLog (Revision 259384)
+++ gcc/fortran/ChangeLog (Arbeitskopie)
@@ -1,3 +1,15 @@
+2018-04-14 Andre Vehreschild <ve...@gcc.gnu.org>
+
+ PR fortran/81773
+ PR fortran/83606
+ * dependency.c (gfc_dep_resolver): Coarray indexes are to be ignored
+ during dependency computation. They define no data dependency.
+ * trans-array.c (conv_array_index_offset): The stride can not be set
+ here, prevent fail.
+ * trans-intrinsic.c (conv_caf_send): Add creation of temporary array
+ for caf_get's result and copying to the array with vectorial
+ indexing.
+
2018-04-14 Thomas Koenig <tkoe...@gcc.gnu.org>
PR fortran/85387
Index: gcc/fortran/dependency.c
===
--- gcc/fortran/dependency.c (Revision 259384)
+++ gcc/fortran/dependency.c (Arbeitskopie)
@@ -2238,8 +2238,9 @@
break;
/* Exactly matching and forward overlapping ranges don't cause a
- dependency. */
- if (fin_dep < GFC_DEP_BACKWARD)
+ dependency, when they are not part of a coarray ref. */
+ if (fin_dep < GFC_DEP_BACKWARD
+ && lref->u.ar.codimen == 0 && rref->u.ar.codimen == 0)
return 0;
/* Keep checking. We only have a dependency if
Index: gcc/fortran/trans-array.c
===
--- gcc/fortran/trans-array.c (Revision 259384)
+++ gcc/fortran/trans-array.c (Arbeitskopie)
@@ -3215,7 +3215,7 @@
}
/* Multiply by the stride. */
- if (!integer_onep (stride))
+ if (stride != NULL && !integer_onep (stride))
index = fold_build2_loc (input_location, MULT_EXPR, gfc_array_index_type,
index, stride);
Index: gcc/fortran/trans-intrinsic.c
===
--- gcc/fortran/trans-intrinsic.c (Revision 259384)
+++ gcc/fortran/trans-intrinsic.c (Arbeitskopie)
@@ -1907,34 +1907,124 @@
}
else
{
- /* If has_vector, pass descriptor for whole array and the
- vector bounds separately. */
- gfc_array_ref *ar, ar2;
- bool has_vector = false;
+ bool has_vector = gfc_has_vector_subscript (lhs_expr);
- if (gfc_is_coindexed (lhs_expr) && gfc_has_vector_subscript (lhs_expr))
+ if (gfc_is_coindexed (lhs_expr) || !has_vector)
{
- has_vector = true;
- ar = gfc_find_array_ref (lhs_expr);
- ar2 = *ar;
- memset (ar, '\0', sizeof (*ar));
- ar->as = ar2.as;
- ar->type = AR_FULL;
+ /* If has_vector, pass descriptor for whole array and the
+ vector bounds separately. */
+ gfc_array_ref *ar, ar2;
+ bool has_tmp_lhs_array = false;
+ if (has_vector)
+ {
+ has_tmp_lhs_array = true;
+ ar = gfc_find_array_ref (lhs_expr);
+ ar2 = *ar;
+ memset (ar, '\0', sizeof (*ar));
+ ar->as = ar2.as;
+ ar->type = AR_FULL;
+ }
+ lhs_se.want_pointer = 1;
+ gfc_conv_expr_descriptor (_se, lhs_expr);
+ /* Using gfc_conv_expr_descriptor, we only get the descriptor, but
+ that has the wrong type if component references are done. */
+ lhs_type = gfc_typenode_for_spec (_expr->ts);
+ tmp = build_fold_indirect_ref_loc (input_location, lhs_se.expr);
+ gfc_add_modify (_se.pre, gfc_conv_descriptor_dtype (tmp),
+ gfc_get_dtype_rank_type (has_vector ? ar2.dimen
+ : lhs_expr->rank,
+ lhs_type));
+ if (has_tmp_lhs_array)
+ {
+ vec = conv_caf_vector_subscript (, lhs_se.expr, );
+ *ar = ar2;
+ }
}
- lh
Re: [patch, fortran] Fix PR 85387
Hi Thomas, this looks good. Ok for trunk. Thanks for the patch. - Andre On Sat, 14 Apr 2018 13:35:37 +0200 Thomas König <t...@tkoenig.net> wrote: > Hello world, > > the attached patch fixes the PR, an 8 regression caused by > trying to convert a nested implied DO loop to an array > for a case where this was not possible. > > Regression-tested. OK for trunk? > > Regards > > Thomas > > 2018-04-14 Thomas Koenig <tkoe...@gcc.gnu.org> > > PR fortran/85387 > * frontend-passes.c (traverse_io_block): Check for start, end or > stride being defined by an outer implied DO loop. > > 2018-04-14 Thomas Koenig <tkoe...@gcc.gnu.org> > > PR fortran/85387 > * gfortran.dg/implied_do_io_5.f90: New test. -- Andre Vehreschild * Email: vehre ad gmx dot de
Re: [Ping, Fortran, Patch, PR81773, PR83606, coarray, v1] Fix coarray get to array with vector indexing
Ping
On Sun, 8 Apr 2018 14:25:50 +0200
Andre Vehreschild <ve...@gmx.de> wrote:
> Hi all,
>
> attached patch fixes (to my knowledge) the two PRs 81773 and 83606 where the
> result of a coarray get() operation is assigned to an array using a vector as
> index. It took me quite long to get it right, because I had to use the
> scalarizer which I haven't use directly before. So reviewers with expertise on
> using the scalarizer are especially welcome.
>
> Bootstrapped and regtested on x86_64-linux/f27.
>
> Ok for trunk? Backports?
>
> Regards,
> Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
gcc/fortran/ChangeLog:
2018-04-08 Andre Vehreschild <ve...@gcc.gnu.org>
PR fortran/81773
PR fortran/83606
* dependency.c (gfc_dep_resolver): Coarray indexes are to be ignored
during dependency computation. They define no data dependency.
* trans-array.c (conv_array_index_offset): The stride can not be set
here, prevent fail.
* trans-intrinsic.c (conv_caf_send): Add creation of temporary array
for caf_get's result and copying to the array with vectorial
indexing.
gcc/testsuite/ChangeLog:
2018-04-08 Andre Vehreschild <ve...@gcc.gnu.org>
PR fortran/81773
PR fortran/83606
* gfortran.dg/coarray/get_to_indexed_array_1.f90: New test.
* gfortran.dg/coarray/get_to_indirect_array.f90: New test.
diff --git a/gcc/fortran/dependency.c b/gcc/fortran/dependency.c
index a0bbd584947..3e14ddc25d8 100644
--- a/gcc/fortran/dependency.c
+++ b/gcc/fortran/dependency.c
@@ -2238,8 +2238,9 @@ gfc_dep_resolver (gfc_ref *lref, gfc_ref *rref, gfc_reverse *reverse)
break;
/* Exactly matching and forward overlapping ranges don't cause a
- dependency. */
- if (fin_dep < GFC_DEP_BACKWARD)
+ dependency, when they are not part of a coarray ref. */
+ if (fin_dep < GFC_DEP_BACKWARD
+ && lref->u.ar.codimen == 0 && rref->u.ar.codimen == 0)
return 0;
/* Keep checking. We only have a dependency if
diff --git a/gcc/fortran/trans-array.c b/gcc/fortran/trans-array.c
index bd731689031..b68e77d5281 100644
--- a/gcc/fortran/trans-array.c
+++ b/gcc/fortran/trans-array.c
@@ -3215,7 +3215,7 @@ conv_array_index_offset (gfc_se * se, gfc_ss * ss, int dim, int i,
}
/* Multiply by the stride. */
- if (!integer_onep (stride))
+ if (stride != NULL && !integer_onep (stride))
index = fold_build2_loc (input_location, MULT_EXPR, gfc_array_index_type,
index, stride);
diff --git a/gcc/fortran/trans-intrinsic.c b/gcc/fortran/trans-intrinsic.c
index a45aec708fb..00edd447bb2 100644
--- a/gcc/fortran/trans-intrinsic.c
+++ b/gcc/fortran/trans-intrinsic.c
@@ -1907,34 +1907,124 @@ conv_caf_send (gfc_code *code) {
}
else
{
- /* If has_vector, pass descriptor for whole array and the
- vector bounds separately. */
- gfc_array_ref *ar, ar2;
- bool has_vector = false;
+ bool has_vector = gfc_has_vector_subscript (lhs_expr);
- if (gfc_is_coindexed (lhs_expr) && gfc_has_vector_subscript (lhs_expr))
+ if (gfc_is_coindexed (lhs_expr) || !has_vector)
{
- has_vector = true;
- ar = gfc_find_array_ref (lhs_expr);
- ar2 = *ar;
- memset (ar, '\0', sizeof (*ar));
- ar->as = ar2.as;
- ar->type = AR_FULL;
+ /* If has_vector, pass descriptor for whole array and the
+ vector bounds separately. */
+ gfc_array_ref *ar, ar2;
+ bool has_tmp_lhs_array = false;
+ if (has_vector)
+ {
+ has_tmp_lhs_array = true;
+ ar = gfc_find_array_ref (lhs_expr);
+ ar2 = *ar;
+ memset (ar, '\0', sizeof (*ar));
+ ar->as = ar2.as;
+ ar->type = AR_FULL;
+ }
+ lhs_se.want_pointer = 1;
+ gfc_conv_expr_descriptor (_se, lhs_expr);
+ /* Using gfc_conv_expr_descriptor, we only get the descriptor, but
+ that has the wrong type if component references are done. */
+ lhs_type = gfc_typenode_for_spec (_expr->ts);
+ tmp = build_fold_indirect_ref_loc (input_location, lhs_se.expr);
+ gfc_add_modify (_se.pre, gfc_conv_descriptor_dtype (tmp),
+ gfc_get_dtype_rank_type (has_vector ? ar2.dimen
+ : lhs_expr->rank,
+ lhs_type));
+ if (has_tmp_lhs_array)
+ {
+ vec = conv_caf_vector_subscript (, lhs_se.expr, );
+ *ar = ar2;
+ }
}
- lhs_se.want_pointer = 1;
- gfc_conv_expr_descriptor (_se, lhs_expr);
- /* Using gfc_conv_expr_descriptor, we only get the descriptor, but that
- has the wrong type if component references are done. */
- lhs_type = gfc_typenode_for_spec (_expr->ts);
- tmp = build_fold_indirect_ref_loc (input_location, lhs_se.expr);
- gfc_add_modify (_se.pre, gfc_conv_descriptor_dtype (tmp),
- gfc_get_dtype_rank_type (has_vector ? ar2.dime
Re: [Fortran, PATCH, coarray, v1] Extend caf_*_by_ref () API by a type specifier
Whoops, hi Damian, sorry for my late reply. I just saw your mail. I am still hanging ~2000 Fortran-Mailinglist mails back and because you copied the mailing list, your mail got filtered to the mailing list folder and I didn't see it in the vast number or unread mails. > Thanks for your latest work on CAF features. Could you let us know whether > this commit should be tested against the OpenCoarrays master branch or > another branch? With the master branch, I get one test failure (not counting > two known teams failures that are actually false negatives that I need to > fix): > > lib_caf_mpi::sendget_by_ref(): Warning ! sendget_by_ref() is mostly > unfunctional due to a design error. Split up your statement with coarray refs > on both sides of the assignment when the datatype transfered is non > 4-byte-integer compatible. libcaf_mpi RUNTIME ERROR: Cannot convert type 1 > kind 4 to type 0 kind 4 > > Is the above expected? Also, because the message comes from sendget, does > that mean it only affects lines that involve three images such as the > following: > > if (this_image()==1) x[2] = x[3] You may test this patch against OpenCoarrays, but without having OC patched it will not benefit from it. I prepared the gfortran patch to fix exactly the above error, but haven't had the time to fix Opencoarrays, too. I'd rather get a better gfortran-8 up and therefore am trying to get pr81773 and 83606 fixed and get them merged into gfortran-8. I follow this strategy, because gcc release cycles are less flexible then OCs. So as soon as I get 81773 and 83606 fixed, I will come back to OC fixing the type issues. Sorry for the delayed response. My time is very limited and this last gfortran fix involved the scalarizer which is a very complicated concept in the gfortran and I haven't worked with before, therefore a steep learning curve. I hope to be on track more often soon. - Andre > > > Damian > > On February 19, 2018 at 9:32:06 AM, Andre Vehreschild (ve...@gmx.de) wrote: > > Hi all, > > no objections received therefore committed as r257813. Thanks for fast > review Jerry. > > - Andre > > On Sun, 18 Feb 2018 18:33:07 +0100 > Andre Vehreschild <ve...@gmx.de> wrote: > > > Well, after discussing on IRC whether RM should be bothered, I was asked > > to simplify release managers lives and propose, that if no one objects > > within one day, I will merge the patch. So any objections? > > > > - Andre > > > > On Sun, 18 Feb 2018 18:07:28 +0100 > > Andre Vehreschild <ve...@gmx.de> wrote: > > > > > Dear release managers, > > > > > > this patch (for reference > > > https://gcc.gnu.org/ml/fortran/2018-02/msg00124.html) fixes a regression > > > in the coarray api by extending three relatively new functions with one > > > or two arguments, respectively. The patch has been approved by gfortran > > > devs. Asking your approval to merge it: Ok to merge to trunk? > > > > > > Regards, > > > Andre > > > > > > On Sun, 18 Feb 2018 08:53:41 -0800 > > > Jerry DeLisle <jvdeli...@charter.net> wrote: > > > > > > > On 02/18/2018 07:39 AM, Andre Vehreschild wrote: > > > > > Hi all, > > > > > > > > > > attached patch fixes an issue with the coarray API. When a component > > > > > of a derived type coarray was referenced using a caf_*_by_ref () > > > > > function and that component was not an array with a descriptor, then > > > > > the type of the component was not known. Which additionally meant, > > > > > that type conversion was not applied as required. This patch fixes > > > > > that issue by adding type specifiers to the three caf_*_by_ref-calls > > > > > and implements the functionality for libcaf_single. This is harmless > > > > > because other coarray libraries that do not expect this argument just > > > > > ignore it. Additionally does this patch also provide the first > > > > > working version of caf_sendget_by_ref in libcaf_single, which > > > > > previously only lead to a stack corruption and was not usable since > > > > > the array descriptor rework (nice job, btw). > > > > > > > > > > I would like to have this patch in trunk knowing that I am somewhat > > > > > late, but it would be quite necessary, because as it is now, the > > > > > coarray feature for derived types is hardly usable. Furthermore do > > > > > some people name this a regression, because the caf_*_by_re
[Fortran, Patch, PR81773, PR83606, coarray, v1] Fix coarray get to array with vector indexing
Hi all,
attached patch fixes (to my knowledge) the two PRs 81773 and 83606 where the
result of a coarray get() operation is assigned to an array using a vector as
index. It took me quite long to get it right, because I had to use the
scalarizer which I haven't use directly before. So reviewers with expertise on
using the scalarizer are especially welcome.
Bootstrapped and regtested on x86_64-linux/f27.
Ok for trunk? Backports?
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
gcc/fortran/ChangeLog:
2018-04-08 Andre Vehreschild <ve...@gcc.gnu.org>
PR fortran/81773
PR fortran/83606
* dependency.c (gfc_dep_resolver): Coarray indexes are to be ignored
during dependency computation. They define no data dependency.
* trans-array.c (conv_array_index_offset): The stride can not be set
here, prevent fail.
* trans-intrinsic.c (conv_caf_send): Add creation of temporary array
for caf_get's result and copying to the array with vectorial
indexing.
gcc/testsuite/ChangeLog:
2018-04-08 Andre Vehreschild <ve...@gcc.gnu.org>
PR fortran/81773
PR fortran/83606
* gfortran.dg/coarray/get_to_indexed_array_1.f90: New test.
* gfortran.dg/coarray/get_to_indirect_array.f90: New test.
diff --git a/gcc/fortran/dependency.c b/gcc/fortran/dependency.c
index a0bbd584947..3e14ddc25d8 100644
--- a/gcc/fortran/dependency.c
+++ b/gcc/fortran/dependency.c
@@ -2238,8 +2238,9 @@ gfc_dep_resolver (gfc_ref *lref, gfc_ref *rref, gfc_reverse *reverse)
break;
/* Exactly matching and forward overlapping ranges don't cause a
- dependency. */
- if (fin_dep < GFC_DEP_BACKWARD)
+ dependency, when they are not part of a coarray ref. */
+ if (fin_dep < GFC_DEP_BACKWARD
+ && lref->u.ar.codimen == 0 && rref->u.ar.codimen == 0)
return 0;
/* Keep checking. We only have a dependency if
diff --git a/gcc/fortran/trans-array.c b/gcc/fortran/trans-array.c
index bd731689031..b68e77d5281 100644
--- a/gcc/fortran/trans-array.c
+++ b/gcc/fortran/trans-array.c
@@ -3215,7 +3215,7 @@ conv_array_index_offset (gfc_se * se, gfc_ss * ss, int dim, int i,
}
/* Multiply by the stride. */
- if (!integer_onep (stride))
+ if (stride != NULL && !integer_onep (stride))
index = fold_build2_loc (input_location, MULT_EXPR, gfc_array_index_type,
index, stride);
diff --git a/gcc/fortran/trans-intrinsic.c b/gcc/fortran/trans-intrinsic.c
index a45aec708fb..00edd447bb2 100644
--- a/gcc/fortran/trans-intrinsic.c
+++ b/gcc/fortran/trans-intrinsic.c
@@ -1907,34 +1907,124 @@ conv_caf_send (gfc_code *code) {
}
else
{
- /* If has_vector, pass descriptor for whole array and the
- vector bounds separately. */
- gfc_array_ref *ar, ar2;
- bool has_vector = false;
+ bool has_vector = gfc_has_vector_subscript (lhs_expr);
- if (gfc_is_coindexed (lhs_expr) && gfc_has_vector_subscript (lhs_expr))
+ if (gfc_is_coindexed (lhs_expr) || !has_vector)
{
- has_vector = true;
- ar = gfc_find_array_ref (lhs_expr);
- ar2 = *ar;
- memset (ar, '\0', sizeof (*ar));
- ar->as = ar2.as;
- ar->type = AR_FULL;
+ /* If has_vector, pass descriptor for whole array and the
+ vector bounds separately. */
+ gfc_array_ref *ar, ar2;
+ bool has_tmp_lhs_array = false;
+ if (has_vector)
+ {
+ has_tmp_lhs_array = true;
+ ar = gfc_find_array_ref (lhs_expr);
+ ar2 = *ar;
+ memset (ar, '\0', sizeof (*ar));
+ ar->as = ar2.as;
+ ar->type = AR_FULL;
+ }
+ lhs_se.want_pointer = 1;
+ gfc_conv_expr_descriptor (_se, lhs_expr);
+ /* Using gfc_conv_expr_descriptor, we only get the descriptor, but
+ that has the wrong type if component references are done. */
+ lhs_type = gfc_typenode_for_spec (_expr->ts);
+ tmp = build_fold_indirect_ref_loc (input_location, lhs_se.expr);
+ gfc_add_modify (_se.pre, gfc_conv_descriptor_dtype (tmp),
+ gfc_get_dtype_rank_type (has_vector ? ar2.dimen
+ : lhs_expr->rank,
+ lhs_type));
+ if (has_tmp_lhs_array)
+ {
+ vec = conv_caf_vector_subscript (, lhs_se.expr, );
+ *ar = ar2;
+ }
}
- lhs_se.want_pointer = 1;
- gfc_conv_expr_descriptor (_se, lhs_expr);
- /* Using gfc_conv_expr_descriptor, we only get the descriptor, but that
- has the wrong type if component references are done. */
- lhs_type = gfc_typenode_for_spec (_expr->ts);
- tmp = build_fold_indirect_ref_loc (input_location, lhs_se.expr);
- gfc_add_modify (_se.pre, gfc_conv_descriptor_dtype (tmp),
- gfc_get_dtype_rank_type (has_vector ? ar2.dimen
- : lhs_expr->rank,
- lhs_type));
- if (has_vector)
+ else
{
- vec = conv_caf_vector_subscript (, lhs_se.expr, );
- *ar = ar2;
+
Re: [Fortran, PATCH, coarray, v1] Extend caf_*_by_ref () API by a type specifier
Hi all,
no objections received therefore committed as r257813. Thanks for fast review
Jerry.
- Andre
On Sun, 18 Feb 2018 18:33:07 +0100
Andre Vehreschild <ve...@gmx.de> wrote:
> Well, after discussing on IRC whether RM should be bothered, I was asked to
> simplify release managers lives and propose, that if no one objects within one
> day, I will merge the patch. So any objections?
>
> - Andre
>
> On Sun, 18 Feb 2018 18:07:28 +0100
> Andre Vehreschild <ve...@gmx.de> wrote:
>
> > Dear release managers,
> >
> > this patch (for reference
> > https://gcc.gnu.org/ml/fortran/2018-02/msg00124.html) fixes a regression in
> > the coarray api by extending three relatively new functions with one or two
> > arguments, respectively. The patch has been approved by gfortran devs.
> > Asking your approval to merge it: Ok to merge to trunk?
> >
> > Regards,
> > Andre
> >
> > On Sun, 18 Feb 2018 08:53:41 -0800
> > Jerry DeLisle <jvdeli...@charter.net> wrote:
> >
> > > On 02/18/2018 07:39 AM, Andre Vehreschild wrote:
> > > > Hi all,
> > > >
> > > > attached patch fixes an issue with the coarray API. When a component of
> > > > a derived type coarray was referenced using a caf_*_by_ref () function
> > > > and that component was not an array with a descriptor, then the type of
> > > > the component was not known. Which additionally meant, that type
> > > > conversion was not applied as required. This patch fixes that issue by
> > > > adding type specifiers to the three caf_*_by_ref-calls and implements
> > > > the functionality for libcaf_single. This is harmless because other
> > > > coarray libraries that do not expect this argument just ignore it.
> > > > Additionally does this patch also provide the first working version of
> > > > caf_sendget_by_ref in libcaf_single, which previously only lead to a
> > > > stack corruption and was not usable since the array descriptor rework
> > > > (nice job, btw).
> > > >
> > > > I would like to have this patch in trunk knowing that I am somewhat
> > > > late, but it would be quite necessary, because as it is now, the
> > > > coarray feature for derived types is hardly usable. Furthermore do some
> > > > people name this a regression, because the caf_*_by_ref are also used
> > > > when the lhs of a caf_get_by_ref() is allocatable which now does not
> > > > work as expected anymore but before gcc-6 using caf_get() (w/o
> > > > reallocation) did.
> > > >
> > > > Bootstrapped and regtested ok on x86_64-linux/f27. Ok for trunk?
> > > >
> > > > - Andre
> > > >
> > >
> > > This is OK from the Fortranners perspective. Should touch base with
> > > release manager. It looks harmless though it changes coarray API, which
> > > is hidden behind -fcoarray=
> > >
> > > Regards,
> > >
> > > Jerry
> >
> >
>
>
--
Andre Vehreschild * Email: vehre ad gmx dot de
Index: gcc/fortran/ChangeLog
===
--- gcc/fortran/ChangeLog (Revision 257812)
+++ gcc/fortran/ChangeLog (Arbeitskopie)
@@ -1,3 +1,13 @@
+2018-02-19 Andre Vehreschild <ve...@gcc.gnu.org>
+
+ * gfortran.texi: Document additional src/dst_type. Fix some typos.
+ * trans-decl.c (gfc_build_builtin_function_decls): Declare the new
+ argument of _caf_*_by_ref () with * e { get, send, sendget }.
+ * trans-intrinsic.c (gfc_conv_intrinsic_caf_get): Add the type of the
+ data referenced when generating a call to caf_get_by_ref ().
+ (conv_caf_send): Same but for caf_send_by_ref () and
+ caf_sendget_by_ref ().
+
2018-02-18 Jerry DeLisle <jvdeli...@gcc.gnu.org>
PR fortran/84389
Index: gcc/fortran/gfortran.texi
===
--- gcc/fortran/gfortran.texi (Revision 257812)
+++ gcc/fortran/gfortran.texi (Arbeitskopie)
@@ -4750,7 +4750,7 @@
@item @emph{Syntax}:
@code{void _gfortran_caf_send_by_ref (caf_token_t token, int image_index,
gfc_descriptor_t *src, caf_reference_t *refs, int dst_kind, int src_kind,
-bool may_require_tmp, bool dst_reallocatable, int *stat)}
+bool may_require_tmp, bool dst_reallocatable, int *stat, int dst_type)}
@item @emph{Arguments}:
@multitable @columnfractions .15 .70
@@ -4774,6 +4774,9 @@
@item @var{stat} @tab intent(out) When non-@code{NULL} give the result of the
operation, i.e., zero on success and non-zero on error. When @code{NULL} and
an error occurs, then an error message is pr
Re: [Fortran, PATCH, coarray, v1] Extend caf_*_by_ref () API by a type specifier
Well, after discussing on IRC whether RM should be bothered, I was asked to simplify release managers lives and propose, that if no one objects within one day, I will merge the patch. So any objections? - Andre On Sun, 18 Feb 2018 18:07:28 +0100 Andre Vehreschild <ve...@gmx.de> wrote: > Dear release managers, > > this patch (for reference > https://gcc.gnu.org/ml/fortran/2018-02/msg00124.html) fixes a regression in > the coarray api by extending three relatively new functions with one or two > arguments, respectively. The patch has been approved by gfortran devs. Asking > your approval to merge it: Ok to merge to trunk? > > Regards, > Andre > > On Sun, 18 Feb 2018 08:53:41 -0800 > Jerry DeLisle <jvdeli...@charter.net> wrote: > > > On 02/18/2018 07:39 AM, Andre Vehreschild wrote: > > > Hi all, > > > > > > attached patch fixes an issue with the coarray API. When a component of a > > > derived type coarray was referenced using a caf_*_by_ref () function and > > > that component was not an array with a descriptor, then the type of the > > > component was not known. Which additionally meant, that type conversion > > > was not applied as required. This patch fixes that issue by adding type > > > specifiers to the three caf_*_by_ref-calls and implements the > > > functionality for libcaf_single. This is harmless because other coarray > > > libraries that do not expect this argument just ignore it. > > > Additionally does this patch also provide the first working version of > > > caf_sendget_by_ref in libcaf_single, which previously only lead to a stack > > > corruption and was not usable since the array descriptor rework (nice job, > > > btw). > > > > > > I would like to have this patch in trunk knowing that I am somewhat late, > > > but it would be quite necessary, because as it is now, the coarray feature > > > for derived types is hardly usable. Furthermore do some people name this a > > > regression, because the caf_*_by_ref are also used when the lhs of a > > > caf_get_by_ref() is allocatable which now does not work as expected > > > anymore but before gcc-6 using caf_get() (w/o reallocation) did. > > > > > > Bootstrapped and regtested ok on x86_64-linux/f27. Ok for trunk? > > > > > > - Andre > > > > > > > This is OK from the Fortranners perspective. Should touch base with > > release manager. It looks harmless though it changes coarray API, which > > is hidden behind -fcoarray= > > > > Regards, > > > > Jerry > > -- Andre Vehreschild * Email: vehre ad gmx dot de
Re: [Fortran, PATCH, coarray, v1] Extend caf_*_by_ref () API by a type specifier
Dear release managers, this patch (for reference https://gcc.gnu.org/ml/fortran/2018-02/msg00124.html) fixes a regression in the coarray api by extending three relatively new functions with one or two arguments, respectively. The patch has been approved by gfortran devs. Asking your approval to merge it: Ok to merge to trunk? Regards, Andre On Sun, 18 Feb 2018 08:53:41 -0800 Jerry DeLisle <jvdeli...@charter.net> wrote: > On 02/18/2018 07:39 AM, Andre Vehreschild wrote: > > Hi all, > > > > attached patch fixes an issue with the coarray API. When a component of a > > derived type coarray was referenced using a caf_*_by_ref () function and > > that component was not an array with a descriptor, then the type of the > > component was not known. Which additionally meant, that type conversion was > > not applied as required. This patch fixes that issue by adding type > > specifiers to the three caf_*_by_ref-calls and implements the functionality > > for libcaf_single. This is harmless because other coarray libraries that do > > not expect this argument just ignore it. > > Additionally does this patch also provide the first working version of > > caf_sendget_by_ref in libcaf_single, which previously only lead to a stack > > corruption and was not usable since the array descriptor rework (nice job, > > btw). > > > > I would like to have this patch in trunk knowing that I am somewhat late, > > but it would be quite necessary, because as it is now, the coarray feature > > for derived types is hardly usable. Furthermore do some people name this a > > regression, because the caf_*_by_ref are also used when the lhs of a > > caf_get_by_ref() is allocatable which now does not work as expected anymore > > but before gcc-6 using caf_get() (w/o reallocation) did. > > > > Bootstrapped and regtested ok on x86_64-linux/f27. Ok for trunk? > > > > - Andre > > > > This is OK from the Fortranners perspective. Should touch base with > release manager. It looks harmless though it changes coarray API, which > is hidden behind -fcoarray= > > Regards, > > Jerry -- Andre Vehreschild * Email: vehre ad gmx dot de
[Fortran, PATCH, coarray, v1] Extend caf_*_by_ref () API by a type specifier
Hi all,
attached patch fixes an issue with the coarray API. When a component of a
derived type coarray was referenced using a caf_*_by_ref () function and that
component was not an array with a descriptor, then the type of the component was
not known. Which additionally meant, that type conversion was not applied as
required. This patch fixes that issue by adding type specifiers to the three
caf_*_by_ref-calls and implements the functionality for libcaf_single. This is
harmless because other coarray libraries that do not expect this argument just
ignore it.
Additionally does this patch also provide the first working version of
caf_sendget_by_ref in libcaf_single, which previously only lead to a stack
corruption and was not usable since the array descriptor rework (nice job, btw).
I would like to have this patch in trunk knowing that I am somewhat late, but
it would be quite necessary, because as it is now, the coarray feature for
derived types is hardly usable. Furthermore do some people name this a
regression, because the caf_*_by_ref are also used when the lhs of a
caf_get_by_ref() is allocatable which now does not work as expected anymore but
before gcc-6 using caf_get() (w/o reallocation) did.
Bootstrapped and regtested ok on x86_64-linux/f27. Ok for trunk?
- Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
gcc/fortran/ChangeLog:
2018-02-18 Andre Vehreschild <ve...@gcc.gnu.org>
* gfortran.texi: Document additional src/dst_type. Fix some typos.
* trans-decl.c (gfc_build_builtin_function_decls): Declare the new
argument of _caf_*_by_ref () with * e { get, send, sendget }.
* trans-intrinsic.c (gfc_conv_intrinsic_caf_get): Add the type of the
data referenced when generating a call to caf_get_by_ref ().
(conv_caf_send): Same but for caf_send_by_ref () and
caf_sendget_by_ref ().
gcc/testsuite/ChangeLog:
2018-02-18 Andre Vehreschild <ve...@gcc.gnu.org>
* gfortran.dg/coarray_alloc_comp_6.f08: New test.
* gfortran.dg/coarray_alloc_comp_7.f08: New test.
* gfortran.dg/coarray_alloc_comp_8.f08: New test.
libgfortran/ChangeLog:
2018-02-18 Andre Vehreschild <ve...@gcc.gnu.org>
* caf/libcaf.h: Add type parameters to the caf_*_by_ref prototypes.
* caf/single.c (get_for_ref): Simplifications and now respecting
the type argument.
(_gfortran_caf_get_by_ref): Added source type handing to get_for_ref().
(send_by_ref): Simplifications and respecting the dst_type now.
(_gfortran_caf_send_by_ref): Added destination type hand over to
send_by_ref().
(_gfortran_caf_sendget_by_ref): Added general support and fixed stack
corruption. The function is now really usable.
diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi
index 9ffe6ade661..db48a713661 100644
--- a/gcc/fortran/gfortran.texi
+++ b/gcc/fortran/gfortran.texi
@@ -4750,7 +4750,7 @@ remote image identified by the @var{image_index}.
@item @emph{Syntax}:
@code{void _gfortran_caf_send_by_ref (caf_token_t token, int image_index,
gfc_descriptor_t *src, caf_reference_t *refs, int dst_kind, int src_kind,
-bool may_require_tmp, bool dst_reallocatable, int *stat)}
+bool may_require_tmp, bool dst_reallocatable, int *stat, int dst_type)}
@item @emph{Arguments}:
@multitable @columnfractions .15 .70
@@ -4774,6 +4774,9 @@ is a full array or component ref.
@item @var{stat} @tab intent(out) When non-@code{NULL} give the result of the
operation, i.e., zero on success and non-zero on error. When @code{NULL} and
an error occurs, then an error message is printed and the program is terminated.
+@item @var{dst_type} @tab intent(in) Give the type of the destination. When
+the destination is not an array, than the precise type, e.g. of a component in
+a derived type, is not known, but provided here.
@end multitable
@item @emph{NOTES}
@@ -4808,7 +4811,7 @@ identified by the @var{image_index}.
@item @emph{Syntax}:
@code{void _gfortran_caf_get_by_ref (caf_token_t token, int image_index,
caf_reference_t *refs, gfc_descriptor_t *dst, int dst_kind, int src_kind,
-bool may_require_tmp, bool dst_reallocatable, int *stat)}
+bool may_require_tmp, bool dst_reallocatable, int *stat, int src_type)}
@item @emph{Arguments}:
@multitable @columnfractions .15 .70
@@ -4833,6 +4836,9 @@ array or a component is referenced.
@item @var{stat} @tab intent(out) When non-@code{NULL} give the result of the
operation, i.e., zero on success and non-zero on error. When @code{NULL} and an
error occurs, then an error message is printed and the program is terminated.
+@item @var{src_type} @tab intent(in) Give the type of the source. When the
+source is not an array, than the precise type, e.g. of a component in a
+derived type, is not known, but provided here.
@end multitable
@item @emph{NOTES}
@@ -4868,7 +4874,8 @@ identified by the @var{src_image_index} to a remote image identified
Re: [Fortran, patch, coarray, v1] Fix a coarray issue and some documentation
Er, the revision is 257567. Sorry pressed to quickly. - Andre On Sun, 11 Feb 2018 20:00:05 +0100 Andre Vehreschild <ve...@gmx.de> wrote: > Hi all, > > approved on IRC by Kargl. Thanks for the quick review. Committed as r > > Regards, > Andre > > On Sun, 11 Feb 2018 18:13:35 +0100 > Andre Vehreschild <ve...@gmx.de> wrote: > > > Hi all, > > > > attached patch fixes a small coarray issue on ultimate component coarrays. > > The coarray was registered with the caf-library as if it were an allocatable > > component in a derived type coarray, which is just wasting resources. An > > ultimate component coarray has to be treated like a regular coarray. The > > second chunk of the patch fixes that. > > > > The first chunk of the attached patch just fixes some typos and style I > > found while reading the help text for caf_register(). Those are so small > > that I did not want to add another patch for this, given that both parts of > > the patch are somehow related. > > > > Bootstrapped and regtested on x86_64-linux-gnu/f27. Ok for trunk? > > > > Regards, > > Andre > > -- Andre Vehreschild * Email: vehre ad gmx dot de
Re: [Fortran, patch, coarray, v1] Fix a coarray issue and some documentation
Hi all,
approved on IRC by Kargl. Thanks for the quick review. Committed as r
Regards,
Andre
On Sun, 11 Feb 2018 18:13:35 +0100
Andre Vehreschild <ve...@gmx.de> wrote:
> Hi all,
>
> attached patch fixes a small coarray issue on ultimate component coarrays. The
> coarray was registered with the caf-library as if it were an allocatable
> component in a derived type coarray, which is just wasting resources. An
> ultimate component coarray has to be treated like a regular coarray. The
> second chunk of the patch fixes that.
>
> The first chunk of the attached patch just fixes some typos and style I found
> while reading the help text for caf_register(). Those are so small that I did
> not want to add another patch for this, given that both parts of the patch are
> somehow related.
>
> Bootstrapped and regtested on x86_64-linux-gnu/f27. Ok for trunk?
>
> Regards,
> Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
Index: gcc/fortran/ChangeLog
===
--- gcc/fortran/ChangeLog (Revision 257566)
+++ gcc/fortran/ChangeLog (Arbeitskopie)
@@ -1,3 +1,9 @@
+2018-02-11 Andre Vehreschild <ve...@gcc.gnu.org>
+
+ * gfortran.texi: Fix typos in documentation of caf_register ().
+ * trans-array.c (structure_alloc_comps): Only register a component of
+ a derived typed corray, not of an ultimate component coarray.
+
2018-02-11 Steven G. Kargl <ka...@gcc.gnu.org>
PR fortran/54223
Index: gcc/fortran/gfortran.texi
===
--- gcc/fortran/gfortran.texi (Revision 257566)
+++ gcc/fortran/gfortran.texi (Arbeitskopie)
@@ -4453,8 +4453,8 @@
@code{CAF_REGTYPE_COARRAY_ALLOC_ALLOCATE_ONLY} is specified, then the
@var{token} needs to be registered by a previous call with regtype
@code{CAF_REGTYPE_COARRAY_ALLOC_REGISTER_ONLY} and either the memory specified
-in the @var{desc}'s data-ptr is registered or allocate when the data-ptr is
-NULL.
+in the @var{DESC}'s data-ptr is registered or allocate when the data-ptr is
+@code{NULL}.
@item @emph{Syntax}:
@code{void caf_register (size_t size, caf_register_t type, caf_token_t *token,
@@ -4468,24 +4468,24 @@
@item @var{token} @tab intent(out) An opaque pointer identifying the coarray.
@item @var{desc} @tab intent(inout) The (pseudo) array descriptor.
@item @var{stat} @tab intent(out) For allocatable coarrays, stores the STAT=;
-may be NULL
+may be @code{NULL}
@item @var{errmsg} @tab intent(out) When an error occurs, this will be set to
-an error message; may be NULL
+an error message; may be @code{NULL}
@item @var{errmsg_len} @tab the buffer size of errmsg.
@end multitable
@item @emph{NOTES}
-Nonalloatable coarrays have to be registered prior use from remote images.
+Nonallocatable coarrays have to be registered prior use from remote images.
In order to guarantee this, they have to be registered before the main
program. This can be achieved by creating constructor functions. That is what
-GCC does such that also nonallocatable coarrays the memory is allocated and no
-static memory is used. The token permits to identify the coarray; to the
+GCC does such that also for nonallocatable coarrays the memory is allocated and
+no static memory is used. The token permits to identify the coarray; to the
processor, the token is a nonaliasing pointer. The library can, for instance,
store the base address of the coarray in the token, some handle or a more
complicated struct. The library may also store the array descriptor
@var{DESC} when its rank is non-zero.
-For lock types, the value shall only used for checking the allocation
+For lock types, the value shall only be used for checking the allocation
status. Note that for critical blocks, the locking is only required on one
image; in the locking statement, the processor shall always pass an
image index of one for critical-block lock variables
Index: gcc/fortran/trans-array.c
===
--- gcc/fortran/trans-array.c (Revision 257566)
+++ gcc/fortran/trans-array.c (Arbeitskopie)
@@ -8747,15 +8747,17 @@
cmp_has_alloc_comps = false;
}
- if (flag_coarray == GFC_FCOARRAY_LIB
- && (caf_in_coarray (caf_mode) || c->attr.codimension))
+ if (flag_coarray == GFC_FCOARRAY_LIB && caf_in_coarray (caf_mode))
{
- /* Register the component with the coarray library. */
+ /* Register a component of a derived type coarray with the
+ coarray library. Do not register ultimate component
+ coarrays here. They are treated like regular coarrays and
+ are either allocated on all images or on none. */
tree token;
comp = fold_build3_loc (input_location, COMPONENT_REF, ctype,
decl, cdecl, NULL_TREE);
- if (c->attr.dimension || c->attr.codimension)
+ if (c->a
[Fortran, patch, coarray, v1] Fix a coarray issue and some documentation
Hi all,
attached patch fixes a small coarray issue on ultimate component coarrays. The
coarray was registered with the caf-library as if it were an allocatable
component in a derived type coarray, which is just wasting resources. An
ultimate component coarray has to be treated like a regular coarray. The second
chunk of the patch fixes that.
The first chunk of the attached patch just fixes some typos and style I found
while reading the help text for caf_register(). Those are so small that I did
not want to add another patch for this, given that both parts of the patch are
somehow related.
Bootstrapped and regtested on x86_64-linux-gnu/f27. Ok for trunk?
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
caf_nullify_and_doc_fix_v1.clog
Description: Binary data
diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi
index 11246696e18..9ffe6ade661 100644
--- a/gcc/fortran/gfortran.texi
+++ b/gcc/fortran/gfortran.texi
@@ -4453,8 +4453,8 @@ is not used then. On the contrary when
@code{CAF_REGTYPE_COARRAY_ALLOC_ALLOCATE_ONLY} is specified, then the
@var{token} needs to be registered by a previous call with regtype
@code{CAF_REGTYPE_COARRAY_ALLOC_REGISTER_ONLY} and either the memory specified
-in the @var{desc}'s data-ptr is registered or allocate when the data-ptr is
-NULL.
+in the @var{DESC}'s data-ptr is registered or allocate when the data-ptr is
+@code{NULL}.
@item @emph{Syntax}:
@code{void caf_register (size_t size, caf_register_t type, caf_token_t *token,
@@ -4468,24 +4468,24 @@ allocated; for lock types and event types, the number of elements.
@item @var{token} @tab intent(out) An opaque pointer identifying the coarray.
@item @var{desc} @tab intent(inout) The (pseudo) array descriptor.
@item @var{stat} @tab intent(out) For allocatable coarrays, stores the STAT=;
-may be NULL
+may be @code{NULL}
@item @var{errmsg} @tab intent(out) When an error occurs, this will be set to
-an error message; may be NULL
+an error message; may be @code{NULL}
@item @var{errmsg_len} @tab the buffer size of errmsg.
@end multitable
@item @emph{NOTES}
-Nonalloatable coarrays have to be registered prior use from remote images.
+Nonallocatable coarrays have to be registered prior use from remote images.
In order to guarantee this, they have to be registered before the main
program. This can be achieved by creating constructor functions. That is what
-GCC does such that also nonallocatable coarrays the memory is allocated and no
-static memory is used. The token permits to identify the coarray; to the
+GCC does such that also for nonallocatable coarrays the memory is allocated and
+no static memory is used. The token permits to identify the coarray; to the
processor, the token is a nonaliasing pointer. The library can, for instance,
store the base address of the coarray in the token, some handle or a more
complicated struct. The library may also store the array descriptor
@var{DESC} when its rank is non-zero.
-For lock types, the value shall only used for checking the allocation
+For lock types, the value shall only be used for checking the allocation
status. Note that for critical blocks, the locking is only required on one
image; in the locking statement, the processor shall always pass an
image index of one for critical-block lock variables
diff --git a/gcc/fortran/trans-array.c b/gcc/fortran/trans-array.c
index d8b4381251e..4ffda26ca7d 100644
--- a/gcc/fortran/trans-array.c
+++ b/gcc/fortran/trans-array.c
@@ -8747,15 +8747,17 @@ structure_alloc_comps (gfc_symbol * der_type, tree decl,
cmp_has_alloc_comps = false;
}
- if (flag_coarray == GFC_FCOARRAY_LIB
- && (caf_in_coarray (caf_mode) || c->attr.codimension))
+ if (flag_coarray == GFC_FCOARRAY_LIB && caf_in_coarray (caf_mode))
{
- /* Register the component with the coarray library. */
+ /* Register a component of a derived type coarray with the
+ coarray library. Do not register ultimate component
+ coarrays here. They are treated like regular coarrays and
+ are either allocated on all images or on none. */
tree token;
comp = fold_build3_loc (input_location, COMPONENT_REF, ctype,
decl, cdecl, NULL_TREE);
- if (c->attr.dimension || c->attr.codimension)
+ if (c->attr.dimension)
{
/* Set the dtype, because caf_register needs it. */
gfc_add_modify (, gfc_conv_descriptor_dtype (comp),
Re: [Patch, fortran] PR83076 - [8 Regression] ICE in gfc_deallocate_scalar_with_status, at fortran/trans.c:1598
Hi all, as long as the computation where the token can be found is adapted in the same way, i.e. the token's offset in the derived type monitors the changed position, everything is fine. When I remember correctly, then this is done automatically by the routines setting up the caf_ref-chain for referencing into coarrays of derived type's (trans-intrinsic.c:~1239 for example). So if everything works, ok for trunk and gcc-7. Regards, Andre On Thu, 28 Dec 2017 11:37:00 + Paul Richard Thomas <paul.richard.tho...@gmail.com> wrote: > Hi All, > > OK - I'll hold back until I hear from Damian & Zaak. > > Cheers > > Paul > > On 27 December 2017 at 21:06, Damian Rouson > <dam...@sourceryinstitute.org> wrote: > > > > Thanks for the additional information Thomas. It sounds like I should test > > Paul’s patch. I should be able to do so today and will post the results by > > tomorrow. I’m adding OpenCoarrays developer Zaak Beekman to the cc and > > attaching the patch again in case he wants to try it as well. > > > > Zaak, the full thread is at https://gcc.gnu.org/ml/fortran/ and starts with > > a message from Paul on November 29. > > > > Damian > > > > On December 27, 2017 at 11:09:29 AM, Thomas Koenig > > (tkoe...@netcologne.de(mailto:tkoe...@netcologne.de)) wrote: > >> Hi Damian, > >> > >> > Does breaking binary compatibility simply mean that CAF codes will need > >> > to be recompiled (which is fine) > >> > >> Well... not really. We are not supposed to break binary compatibility > >> in a release. For gcc-8, we have greater freedom because we had to > >> do it anyway. > >> > >> Now, the interesting question is the impact. If we break binary > >> compatibilty for something that never worked anyway or was useless, or > >> something that was broken by a gcc-7 regression, I think we're fine. > >> > >> If not, well... one possible decision would be to wait for gcc-8 to > >> fix this. > >> > >> > or does it mean that there will need to be work done on OpenCoarrays > >> to support the changes > >> > >> This, I don't know, never having looked at the OpenCoarrays source. > >> > >> Regards > >> > >> Thomas > > > -- Andre Vehreschild * Email: vehre ad gmx dot de
Re: [Patch, fortran] PR81447 - [7/8] gfortran fails to recognize the exact dynamic type of a polymorphic entity that was allocated in a external procedure
Hi Paul,
On Thu, 2 Nov 2017 20:11:29 +
Paul Richard Thomas <paul.richard.tho...@gmail.com> wrote:
> *** resolve_fl_derived (gfc_symbol *sym)
> *** 14075,14080
> --- 14078,14097
> if (!resolve_typebound_procedures (sym))
> return false;
>
> + /* Generate module vtables subject to their accessibility and their not
> + being vtables or pdt templates. If this is not done class declarations
> + in external procedures wind up with their own version and so SELECT
> TYPE
> + fails because the vptrs do not have the same address. */
> + if (gfc_option.allow_std & GFC_STD_F2003
Shouldn't that better be
if ((gfc_option.allow_std & GFC_STD_F2003) > 0
? I regularly fall on my nose because of the compiler binding this not as
expected.
> + && sym->ns->proc_name
> + && sym->ns->proc_name->attr.flavor == FL_MODULE
> + && sym->attr.access != ACCESS_PRIVATE
> + && !(sym->attr.use_assoc || sym->attr.vtype ||
> sym->attr.pdt_template))
> + {
> + gfc_symbol *vtab = gfc_find_derived_vtab (sym);
> + gfc_set_sym_referenced (vtab);
> + }
> +
> return true;
> }
Besides that I think this is OK.
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
Re: [Committed, Fortran, Patch, v1] Three small patches for character arrays
Hi Paul,
thanks for the review. Committed as r254407 to trunk and r254408 to gcc-7.
Regards,
Andre
On Sat, 4 Nov 2017 12:06:15 +
Paul Richard Thomas <paul.richard.tho...@gmail.com> wrote:
> Hi Andre,
>
> These patches look fine to me. Thanks for taking account of the array
> descriptor change between trunk and 7-branch :-)
>
> OK for trunk and 7-branch.
>
> Thanks
>
> Paul
>
>
> On 4 November 2017 at 10:27, Andre Vehreschild <ve...@gmx.de> wrote:
> > Ping!
> >
> > On Wed, 1 Nov 2017 12:27:11 +0100
> > Andre Vehreschild <ve...@gmx.de> wrote:
> >
> >> Hi all,
> >>
> >> during development on OpenCoarrays I found these three issues in gfortran:
> >>
> >> - caf_send: Did not treat char arrays as arrays when calling caf_send.
> >> - gfc_trans_assignment_1: Conversion of character kind creates a loop
> >> variant temporary which must not be put before the loop body, but within.
> >> - get_array_span: When doing pointer arithmetic on char arrays the
> >> character kind was not applied.
> >>
> >> The attached patch fixes all of these issues for trunk and gcc-7.
> >> Bootstrapped and regtested on x86_64-linux-gnu/f25. Ok for trunk and gcc-7?
> >>
> >> Regards,
> >> Andre
> >
> >
> > --
> > Andre Vehreschild * Email: vehre ad gmx dot de
>
>
>
--
Andre Vehreschild * Email: vehre ad gmx dot de
Index: gcc/fortran/ChangeLog
===
--- gcc/fortran/ChangeLog (Revision 254406)
+++ gcc/fortran/ChangeLog (Arbeitskopie)
@@ -1,3 +1,12 @@
+2017-11-04 Andre Vehreschild <ve...@gcc.gnu.org>
+
+ * trans-expr.c (gfc_trans_assignment_1): Character kind conversion may
+ create a loop variant temporary, too.
+ * trans-intrinsic.c (conv_caf_send): Treat char arrays as arrays and
+ not as scalars.
+ * trans.c (get_array_span): Take the character kind into account when
+ doing pointer arithmetic.
+
2017-11-04 Thomas Koenig <tkoe...@gcc.gnu.org>
PR fortran/29600
Index: gcc/fortran/trans-expr.c
===
--- gcc/fortran/trans-expr.c (Revision 254406)
+++ gcc/fortran/trans-expr.c (Arbeitskopie)
@@ -10084,12 +10084,16 @@
NOTE: This relies on having the exact dependence of the length type
parameter available to the caller; gfortran saves it in the .mod files.
NOTE ALSO: The concatenation operation generates a temporary pointer,
- whose allocation must go to the innermost loop. */
+ whose allocation must go to the innermost loop.
+ NOTE ALSO (2): A character conversion may generate a temporary, too. */
if (flag_realloc_lhs
&& expr2->ts.type == BT_CHARACTER && expr1->ts.deferred
&& !(lss != gfc_ss_terminator
- && expr2->expr_type == EXPR_OP
- && expr2->value.op.op == INTRINSIC_CONCAT))
+ && ((expr2->expr_type == EXPR_OP
+ && expr2->value.op.op == INTRINSIC_CONCAT)
+ || (expr2->expr_type == EXPR_FUNCTION
+ && expr2->value.function.isym != NULL
+ && expr2->value.function.isym->id == GFC_ISYM_CONVERSION
gfc_add_block_to_block (, );
/* Nullify the allocatable components corresponding to those of the lhs
Index: gcc/fortran/trans-intrinsic.c
===
--- gcc/fortran/trans-intrinsic.c (Revision 254406)
+++ gcc/fortran/trans-intrinsic.c (Arbeitskopie)
@@ -1871,12 +1871,21 @@
gfc_init_se (_se, NULL);
if (lhs_expr->rank == 0)
{
- symbol_attribute attr;
- gfc_clear_attr ();
- gfc_conv_expr (_se, lhs_expr);
- lhs_type = TREE_TYPE (lhs_se.expr);
- lhs_se.expr = gfc_conv_scalar_to_descriptor (_se, lhs_se.expr, attr);
- lhs_se.expr = gfc_build_addr_expr (NULL_TREE, lhs_se.expr);
+ if (lhs_expr->ts.type == BT_CHARACTER && lhs_expr->ts.deferred)
+ {
+ lhs_se.expr = gfc_get_tree_for_caf_expr (lhs_expr);
+ lhs_se.expr = gfc_build_addr_expr (NULL_TREE, lhs_se.expr);
+ }
+ else
+ {
+ symbol_attribute attr;
+ gfc_clear_attr ();
+ gfc_conv_expr (_se, lhs_expr);
+ lhs_type = TREE_TYPE (lhs_se.expr);
+ lhs_se.expr = gfc_conv_scalar_to_descriptor (_se, lhs_se.expr,
+ attr);
+ lhs_se.expr = gfc_build_addr_expr (NULL_TREE, lhs_se.expr);
+ }
}
else if ((lhs_caf_attr.alloc_comp || lhs_caf_attr.pointer_comp)
&& lhs_caf_attr.codimension)
Index: gcc/fortran/trans.c
===
--- gcc/fortran/trans.c (Revision 254406)
+++ gcc/fortran/trans.c (Arbeitskopie)
@@ -320,8 +320,12 @@
|| DECL_CONTEXT (TYPE_MAX_VALUE (TYPE_DOMAIN (type)))
Re: [Ping, Fortran, Patch, v1] Three small patches for character arrays
Ping!
On Wed, 1 Nov 2017 12:27:11 +0100
Andre Vehreschild <ve...@gmx.de> wrote:
> Hi all,
>
> during development on OpenCoarrays I found these three issues in gfortran:
>
> - caf_send: Did not treat char arrays as arrays when calling caf_send.
> - gfc_trans_assignment_1: Conversion of character kind creates a loop variant
> temporary which must not be put before the loop body, but within.
> - get_array_span: When doing pointer arithmetic on char arrays the character
> kind was not applied.
>
> The attached patch fixes all of these issues for trunk and gcc-7. Bootstrapped
> and regtested on x86_64-linux-gnu/f25. Ok for trunk and gcc-7?
>
> Regards,
> Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
gcc/fortran/ChangeLog:
2017-11-01 Andre Vehreschild <ve...@gcc.gnu.org>
* trans-expr.c (gfc_trans_assignment_1): Character kind conversion may
create a loop variant temporary, too.
* trans-intrinsic.c (conv_caf_send): Treat char arrays as arrays and
not as scalars.
* trans.c (get_array_span): Take the character kind into account when
doing pointer arithmetic.
gcc/testsuite/ChangeLog:
2017-11-01 Andre Vehreschild <ve...@gcc.gnu.org>
* gfortran.dg/coarray/send_char_array_1.f90: New test.
diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
index 1a3e3d4..57b62a6 100644
--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -10084,12 +10084,16 @@ gfc_trans_assignment_1 (gfc_expr * expr1, gfc_expr * expr2, bool init_flag,
NOTE: This relies on having the exact dependence of the length type
parameter available to the caller; gfortran saves it in the .mod files.
NOTE ALSO: The concatenation operation generates a temporary pointer,
- whose allocation must go to the innermost loop. */
+ whose allocation must go to the innermost loop.
+ NOTE ALSO (2): A character conversion may generate a temporary, too. */
if (flag_realloc_lhs
&& expr2->ts.type == BT_CHARACTER && expr1->ts.deferred
&& !(lss != gfc_ss_terminator
- && expr2->expr_type == EXPR_OP
- && expr2->value.op.op == INTRINSIC_CONCAT))
+ && ((expr2->expr_type == EXPR_OP
+ && expr2->value.op.op == INTRINSIC_CONCAT)
+ || (expr2->expr_type == EXPR_FUNCTION
+ && expr2->value.function.isym != NULL
+ && expr2->value.function.isym->id == GFC_ISYM_CONVERSION
gfc_add_block_to_block (, );
/* Nullify the allocatable components corresponding to those of the lhs
diff --git a/gcc/fortran/trans-intrinsic.c b/gcc/fortran/trans-intrinsic.c
index 532d3ab..b0f0ab2 100644
--- a/gcc/fortran/trans-intrinsic.c
+++ b/gcc/fortran/trans-intrinsic.c
@@ -1871,12 +1871,21 @@ conv_caf_send (gfc_code *code) {
gfc_init_se (_se, NULL);
if (lhs_expr->rank == 0)
{
- symbol_attribute attr;
- gfc_clear_attr ();
- gfc_conv_expr (_se, lhs_expr);
- lhs_type = TREE_TYPE (lhs_se.expr);
- lhs_se.expr = gfc_conv_scalar_to_descriptor (_se, lhs_se.expr, attr);
- lhs_se.expr = gfc_build_addr_expr (NULL_TREE, lhs_se.expr);
+ if (lhs_expr->ts.type == BT_CHARACTER && lhs_expr->ts.deferred)
+ {
+ lhs_se.expr = gfc_get_tree_for_caf_expr (lhs_expr);
+ lhs_se.expr = gfc_build_addr_expr (NULL_TREE, lhs_se.expr);
+ }
+ else
+ {
+ symbol_attribute attr;
+ gfc_clear_attr ();
+ gfc_conv_expr (_se, lhs_expr);
+ lhs_type = TREE_TYPE (lhs_se.expr);
+ lhs_se.expr = gfc_conv_scalar_to_descriptor (_se, lhs_se.expr,
+ attr);
+ lhs_se.expr = gfc_build_addr_expr (NULL_TREE, lhs_se.expr);
+ }
}
else if ((lhs_caf_attr.alloc_comp || lhs_caf_attr.pointer_comp)
&& lhs_caf_attr.codimension)
diff --git a/gcc/fortran/trans.c b/gcc/fortran/trans.c
index 53bc428..4115308 100644
--- a/gcc/fortran/trans.c
+++ b/gcc/fortran/trans.c
@@ -320,8 +320,12 @@ get_array_span (tree type, tree decl)
|| DECL_CONTEXT (TYPE_MAX_VALUE (TYPE_DOMAIN (type)))
== DECL_CONTEXT (decl)))
{
- span = TYPE_MAX_VALUE (TYPE_DOMAIN (type));
- span = fold_convert (gfc_array_index_type, span);
+ span = fold_convert (gfc_array_index_type,
+ TYPE_MAX_VALUE (TYPE_DOMAIN (type)));
+ span = fold_build2 (MULT_EXPR, gfc_array_index_type,
+ fold_convert (gfc_array_index_type,
+ TYPE_SIZE_UNIT (TREE_TYPE (type))),
+ span);
}
/* Likewise for class array or pointer array references. */
else if (TREE_CODE (decl) == FIELD_DECL
diff --git a/gcc/testsuite/gfortran.dg/coarray/send_char_array_1.f90 b/gcc/testsuite/gfortran.dg/coarray/send_char_array_1.f90
new file mode 100644
index 000..800a8ac
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/coarray/send_char_array_1.f90
@@ -0,0 +1,54 @@
+!{ dg-do run }
+
+program send_convert_char_array
+
[Fortran, Patch, v1] Three small patches for character arrays
Hi all,
during development on OpenCoarrays I found these three issues in gfortran:
- caf_send: Did not treat char arrays as arrays when calling caf_send.
- gfc_trans_assignment_1: Conversion of character kind creates a loop variant
temporary which must not be put before the loop body, but within.
- get_array_span: When doing pointer arithmetic on char arrays the character
kind was not applied.
The attached patch fixes all of these issues for trunk and gcc-7. Bootstrapped
and regtested on x86_64-linux-gnu/f25. Ok for trunk and gcc-7?
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
gcc/fortran/ChangeLog:
2017-11-01 Andre Vehreschild <ve...@gcc.gnu.org>
* trans-expr.c (gfc_trans_assignment_1): Character kind conversion may
create a loop variant temporary, too.
* trans-intrinsic.c (conv_caf_send): Treat char arrays as arrays and
not as scalars.
* trans.c (get_array_span): Take the character kind into account when
doing pointer arithmetic.
gcc/testsuite/ChangeLog:
2017-11-01 Andre Vehreschild <ve...@gcc.gnu.org>
* gfortran.dg/coarray/send_char_array_1.f90: New test.
diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
index 1a3e3d4..57b62a6 100644
--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -10084,12 +10084,16 @@ gfc_trans_assignment_1 (gfc_expr * expr1, gfc_expr * expr2, bool init_flag,
NOTE: This relies on having the exact dependence of the length type
parameter available to the caller; gfortran saves it in the .mod files.
NOTE ALSO: The concatenation operation generates a temporary pointer,
- whose allocation must go to the innermost loop. */
+ whose allocation must go to the innermost loop.
+ NOTE ALSO (2): A character conversion may generate a temporary, too. */
if (flag_realloc_lhs
&& expr2->ts.type == BT_CHARACTER && expr1->ts.deferred
&& !(lss != gfc_ss_terminator
- && expr2->expr_type == EXPR_OP
- && expr2->value.op.op == INTRINSIC_CONCAT))
+ && ((expr2->expr_type == EXPR_OP
+ && expr2->value.op.op == INTRINSIC_CONCAT)
+ || (expr2->expr_type == EXPR_FUNCTION
+ && expr2->value.function.isym != NULL
+ && expr2->value.function.isym->id == GFC_ISYM_CONVERSION
gfc_add_block_to_block (, );
/* Nullify the allocatable components corresponding to those of the lhs
diff --git a/gcc/fortran/trans-intrinsic.c b/gcc/fortran/trans-intrinsic.c
index 532d3ab..b0f0ab2 100644
--- a/gcc/fortran/trans-intrinsic.c
+++ b/gcc/fortran/trans-intrinsic.c
@@ -1871,12 +1871,21 @@ conv_caf_send (gfc_code *code) {
gfc_init_se (_se, NULL);
if (lhs_expr->rank == 0)
{
- symbol_attribute attr;
- gfc_clear_attr ();
- gfc_conv_expr (_se, lhs_expr);
- lhs_type = TREE_TYPE (lhs_se.expr);
- lhs_se.expr = gfc_conv_scalar_to_descriptor (_se, lhs_se.expr, attr);
- lhs_se.expr = gfc_build_addr_expr (NULL_TREE, lhs_se.expr);
+ if (lhs_expr->ts.type == BT_CHARACTER && lhs_expr->ts.deferred)
+ {
+ lhs_se.expr = gfc_get_tree_for_caf_expr (lhs_expr);
+ lhs_se.expr = gfc_build_addr_expr (NULL_TREE, lhs_se.expr);
+ }
+ else
+ {
+ symbol_attribute attr;
+ gfc_clear_attr ();
+ gfc_conv_expr (_se, lhs_expr);
+ lhs_type = TREE_TYPE (lhs_se.expr);
+ lhs_se.expr = gfc_conv_scalar_to_descriptor (_se, lhs_se.expr,
+ attr);
+ lhs_se.expr = gfc_build_addr_expr (NULL_TREE, lhs_se.expr);
+ }
}
else if ((lhs_caf_attr.alloc_comp || lhs_caf_attr.pointer_comp)
&& lhs_caf_attr.codimension)
diff --git a/gcc/fortran/trans.c b/gcc/fortran/trans.c
index 53bc428..4115308 100644
--- a/gcc/fortran/trans.c
+++ b/gcc/fortran/trans.c
@@ -320,8 +320,12 @@ get_array_span (tree type, tree decl)
|| DECL_CONTEXT (TYPE_MAX_VALUE (TYPE_DOMAIN (type)))
== DECL_CONTEXT (decl)))
{
- span = TYPE_MAX_VALUE (TYPE_DOMAIN (type));
- span = fold_convert (gfc_array_index_type, span);
+ span = fold_convert (gfc_array_index_type,
+ TYPE_MAX_VALUE (TYPE_DOMAIN (type)));
+ span = fold_build2 (MULT_EXPR, gfc_array_index_type,
+ fold_convert (gfc_array_index_type,
+ TYPE_SIZE_UNIT (TREE_TYPE (type))),
+ span);
}
/* Likewise for class array or pointer array references. */
else if (TREE_CODE (decl) == FIELD_DECL
diff --git a/gcc/testsuite/gfortran.dg/coarray/send_char_array_1.f90 b/gcc/testsuite/gfortran.dg/coarray/send_char_array_1.f90
new file mode 100644
index 000..800a8ac
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/coarray/send_char_array_1.f90
@@ -0,0 +1,54 @@
+!{ dg-do run }
+
+program send_convert_char_array
+
+ implicit none
+
+ character(kind=1, len=:), allocatable, codimension[:] :: co_str_k1_scal
+ character(kind=1, len=:), allocatable :: str_k1_scal
+ character(kind=
Re: [Patch, fortran] PR80850 - Sourced allocate() fails to allocate a pointer
Hi Paul, whoopsie, I remember that I inserted the check for _len > 0 in allocate(). So it was me causing the bug. Thanks that you found it. The patch looks good to me. Thanks for the work. - Andre On Mon, 30 Oct 2017 12:20:20 + Paul Richard Thomas <paul.richard.tho...@gmail.com> wrote: > Dear All, > > This bug took a silly amount of effort to diagnose but once done, the > fix was obvious. > > The bug is triggered in this function from the reporter's source file > gfc_graph.F90: > > function GraphIterAppendVertex(this,vertex) result(ierr) > !Appends a new vertex to the graph. > implicit none > integer(INTD):: ierr !out: error code > class(graph_iter_t), intent(inout):: this !inout: > graph iterator > class(graph_vertex_t), intent(in), target:: vertex !in: new vertex > type(vert_link_refs_t):: vlr > > ierr=this%vert_it%append(vertex) !<= right here! > snip > return > end function GraphIterAppendVertex > > 'vertex' is being passed to a class(*) dummy. As you will see from the > attached patch and the ChangeLog, 'vertex' was being cast as unlimited > polymorphic and assigned to the passed actual argument. This left the > _len field indeterminate since it is not present in normal (limited?) > polymorphic objects. > > Further down the way, in stsubs.F90(clone_object) an allocation is > being made using the unlimited version of 'vertex as a source. Since > the size passed to malloc for an unlimited source is, for _len > 0, > the value of the _len multiplied by the vtable _size, the amount of > memory is also indeterminate and causes the operating system to flag a > failed allocation, pretty much at random. > > The ChangeLog and the patch describe the fix sufficiently well as not > to require further explanation. I will write a testcase that tests the > tree dump for the _len field before committing the patch. > > Bootstraps and regtests on FC23/x86_64 - OK for 7- and 8-branches? > > If I do not receive any contrary comments, I will commit tonight. > > Regards > > Paul > > 2017-10-30 Paul Thomas <pa...@gcc.gnu.org> > > PR fortran/80850 > * trans_expr.c (gfc_conv_procedure_call): When passing a class > argument to an unlimited polymorphic dummy, it is wrong to cast > the passed expression as unlimited, unless it is unlimited. The > correct way is to assign to each of the fields and set the _len > field to zero. -- Andre Vehreschild * Email: vehre ad gmx dot de
Re: [PATCH, Fortran, v1] Clarify error message of co_reduce
Hi all,
I got no direct objections therefore committed as r254197 to trunk and r254198
to gcc-7.
@Steve, I will take a look at what you pointed.
- Andre
On Fri, 27 Oct 2017 12:19:02 +0200
Andre Vehreschild <ve...@gmx.de> wrote:
> Hi all,
>
> as noted on IRC is one of the error message in check.c co_reduce misleading.
> The attached patch fixes this. The intention of the error message is to tell
> that the type of the argument bound to parameter A is of wrong type and not
> that an unspecific argument has a wrong type.
>
> If no one objects within 24 h I am planning to commit this patch as obvious to
> trunk gcc-7. Bootstrapped and regtested on x86_64-linux-gnu/f25.
>
> Regards,
> Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
Index: gcc/fortran/ChangeLog
===
--- gcc/fortran/ChangeLog (Revision 254196)
+++ gcc/fortran/ChangeLog (Arbeitskopie)
@@ -1,3 +1,7 @@
+2017-10-28 Andre Vehreschild <ve...@gcc.gnu.org>
+
+ * check.c (gfc_check_co_reduce): Clarify error message.
+
2017-10-28 Paul Thomas <pa...@gcc.gnu.org>
PR fortran/81758
Index: gcc/fortran/check.c
===
--- gcc/fortran/check.c (Revision 254196)
+++ gcc/fortran/check.c (Arbeitskopie)
@@ -1731,7 +1731,7 @@
if (!gfc_compare_types (>ts, >result->ts))
{
- gfc_error ("A argument at %L has type %s but the function passed as "
+ gfc_error ("The A argument at %L has type %s but the function passed as "
"OPERATOR at %L returns %s",
>where, gfc_typename (>ts), >where,
gfc_typename (>result->ts));
Index: gcc/fortran/ChangeLog
===
--- gcc/fortran/ChangeLog (Revision 254197)
+++ gcc/fortran/ChangeLog (Arbeitskopie)
@@ -1,3 +1,7 @@
+2017-10-28 Andre Vehreschild <ve...@gcc.gnu.org>
+
+ * check.c (gfc_check_co_reduce): Clarify error message.
+
2017-10-28 Paul Thomas <pa...@gcc.gnu.org>
Backported from trunk
Index: gcc/fortran/check.c
===
--- gcc/fortran/check.c (Revision 254197)
+++ gcc/fortran/check.c (Arbeitskopie)
@@ -1731,7 +1731,7 @@
if (!gfc_compare_types (>ts, >result->ts))
{
- gfc_error ("A argument at %L has type %s but the function passed as "
+ gfc_error ("The A argument at %L has type %s but the function passed as "
"OPERATOR at %L returns %s",
>where, gfc_typename (>ts), >where,
gfc_typename (>result->ts));
[PATCH, Fortran, v1] Clarify error message of co_reduce
Hi all,
as noted on IRC is one of the error message in check.c co_reduce misleading.
The attached patch fixes this. The intention of the error message is to tell
that the type of the argument bound to parameter A is of wrong type and not
that an unspecific argument has a wrong type.
If no one objects within 24 h I am planning to commit this patch as obvious to
trunk gcc-7. Bootstrapped and regtested on x86_64-linux-gnu/f25.
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
gcc/fortran/ChangeLog:
2017-10-27 Andre Vehreschild <ve...@gcc.gnu.org>
* check.c (gfc_check_co_reduce): Clarify error message.
diff --git a/gcc/fortran/check.c b/gcc/fortran/check.c
index 681950e..759c15a 100644
--- a/gcc/fortran/check.c
+++ b/gcc/fortran/check.c
@@ -1731,7 +1731,7 @@ gfc_check_co_reduce (gfc_expr *a, gfc_expr *op, gfc_expr *result_image,
if (!gfc_compare_types (>ts, >result->ts))
{
- gfc_error ("A argument at %L has type %s but the function passed as "
+ gfc_error ("The A argument at %L has type %s but the function passed as "
"OPERATOR at %L returns %s",
>where, gfc_typename (>ts), >where,
gfc_typename (>result->ts));
Re: [Patch, fortran] PR81758 - [7/8 Regression] [OOP] Broken vtab
Hi Paul, Without having tested the patch, it looks reasonable to me. So ok from my side. - Andre Am 26. Oktober 2017 21:12:45 MESZ schrieb Paul Richard Thomas <paul.richard.tho...@gmail.com>: >Dear All, > >Thanks to Dimitry Liakh for both reporting the problem and doing a lot >of the diagnostic work. Once the offending line in a very complicated >code was located, the fix was trivial. Generating a reduced testcase >took rather longer :-) > >The comment in the testcase tells the story. The fix is a one-liner >that follows immediately from the explanation. > >Bootstrapped and regtested on FC23/x86_64 - OK for trunk and 7-branch. > >Cheers > >Paul > >2017-10-26 Paul Thomas <pa...@gcc.gnu.org> > >PR fortran/81758 >* trans-expr.c (trans_class_vptr_len_assignment): 'vptr_expr' >must only be set if the right hand side expression is of class >type. > >2017-10-26 Paul Thomas <pa...@gcc.gnu.org> > >PR fortran/81758 >* gfortran.dg/class_63.f90: New test. -- Andre Vehreschild * Kreuzherrenstr. 8 * 52062 Aachen Tel.: +49 241 929 10 18 * ve...@gmx.de
Re: New prerequisites to support multi image COARRAY in gfortran
Hi FX, we don't really do. You can use other MPI implementation as well, albeit not all features are implemented in all the others. For failed images support we needed the fault tolerance support for MPI, which I see only in mpich from 3.2 on. The other MPI implementations publicy available do not support ft at the moment. So as soon as they do in their stable versions, we might give the user more choice. - Andre On Tue, 4 Apr 2017 19:44:06 +0200 FX <fxcoud...@gmail.com> wrote: > > We choose mpich as a default only because it is very stable. > > Why are why tying ourselves to one MPI implementation? > > FX -- Andre Vehreschild * Email: vehre ad gmx dot de
Re: [PATCH, Fortran, Coarray, v1] Add support for failed images
Hi Christophe, The testcase is not expected to output anything. So only the exit code should be set to zero. I called libgfortrans exit-function to quit the program. I am not aware that I need to do more. Happy for any insight what goes wrong. There are also issues on hpux, but I think they have a different cause. - Andre Am 10. März 2017 07:48:12 MEZ schrieb Christophe Lyon <christophe.l...@linaro.org>: >On 9 March 2017 at 09:45, Andre Vehreschild <ve...@gmx.de> wrote: >> Hi Christophe, >> >> you are right, that error message does not help a bit. Can you >manually compile >> and execute the testcase? Does it print "ERROR STOP: This statement >should not >> be reached."? >> >> If not what does >> >> fail_image_2 && echo "yes" || echo "no" >> >> print? It should be "yes" >> > >I restarted the build manually, and the program exits without printing >anything, and the return code is 0. > >What is missing in gfortran.log is the "EXIT code 0" string. >It looks like an unexpected interaction between qemu and >the way the program exists, meaning that the exit code >is not properly detected by dejagnu. >I'll try to debug that, it looks like a setting is missing in >my validation environment. > >Thanks, > >Christophe > >> - Andre >> >> On Wed, 8 Mar 2017 23:58:10 +0100 >> Christophe Lyon <christophe.l...@linaro.org> wrote: >> >>> Hi, >>> >>> On 5 March 2017 at 12:41, Andre Vehreschild <ve...@gmx.de> wrote: >>> > Hi Jerry, >>> > >>> > thanks for seconding my read of the standard and reviewing so >quickly. >>> > Committed as r245900. >>> > >>> >>> I've noticed that the new test: >>> gfortran.dg/coarray/fail_image_2.f08 -fcoarray=single -O2 -latomic >>> execution test >>> fails on arm and aarch64. >>> I'm using qemu if it matters, and my gfortran.log has: >>> spawn /XXX/qemu-wrapper.sh ./fail_image_2.exe >>> FAIL: gfortran.dg/coarray/fail_image_2.f08 -fcoarray=single -O2 >>> -latomic execution test >>> >>> that is, no obvious error message :-( >>> >>> Am I the only one seeing this? >>> >>> Thanks, >>> >>> Christophe >>> >>> > Regards, >>> > Andre >>> > >>> > On Sat, 4 Mar 2017 15:06:25 -0800 >>> > Jerry DeLisle <jvdeli...@charter.net> wrote: >>> > >>> >> On 03/04/2017 09:58 AM, Andre Vehreschild wrote: >>> >> > Hi all, >>> >> > >>> >> > attached patch polishes the one begun by Alessandro. It adds >>> >> > documentation and fixes the style issues. Furthermore did I try >to >>> >> > interpret the standard according to the FAIL IMAGE statement. >IMHO >>> >> > should it just quit the executable without any error code. The >>> >> > caf_single library emits "FAIL IMAGE" to stderr, while in >coarray=single >>> >> > mode it just quits. What do you think? >>> >> > >>> >> > Bootstraps and regtests ok on x86_64-linux/f25. Ok for trunk? >(May be >>> >> > later). >>> >> > >>> >> > Gruß, >>> >> > Andre >>> >> > >>> >> >>> >> From my read: >>> >> >>> >> "A failed image is usually associated with a hardware failure of >the >>> >> processor, memory system, or interconnection network" >>> >> >>> >> Since the FAIL IMAGE statement is intended to simulate such >failure, I >>> >> agree with your interpretation as well, it just stops execution. >>> >> >>> >> Yes OK for trunk now. >>> >> >>> >> Jerry >>> > >>> > >>> > -- >>> > Andre Vehreschild * Email: vehre ad gmx dot de >> >> >> -- >> Andre Vehreschild * Email: vehre ad gmx dot de -- Andre Vehreschild * Kreuzherrenstr. 8 * 52062 Aachen Tel.: +49 241 929 10 18 * ve...@gmx.de
Re: [PATCH, Fortran, Coarray, v1] Add support for failed images
Hi Christophe, you are right, that error message does not help a bit. Can you manually compile and execute the testcase? Does it print "ERROR STOP: This statement should not be reached."? If not what does fail_image_2 && echo "yes" || echo "no" print? It should be "yes" - Andre On Wed, 8 Mar 2017 23:58:10 +0100 Christophe Lyon <christophe.l...@linaro.org> wrote: > Hi, > > On 5 March 2017 at 12:41, Andre Vehreschild <ve...@gmx.de> wrote: > > Hi Jerry, > > > > thanks for seconding my read of the standard and reviewing so quickly. > > Committed as r245900. > > > > I've noticed that the new test: > gfortran.dg/coarray/fail_image_2.f08 -fcoarray=single -O2 -latomic > execution test > fails on arm and aarch64. > I'm using qemu if it matters, and my gfortran.log has: > spawn /XXX/qemu-wrapper.sh ./fail_image_2.exe > FAIL: gfortran.dg/coarray/fail_image_2.f08 -fcoarray=single -O2 > -latomic execution test > > that is, no obvious error message :-( > > Am I the only one seeing this? > > Thanks, > > Christophe > > > Regards, > > Andre > > > > On Sat, 4 Mar 2017 15:06:25 -0800 > > Jerry DeLisle <jvdeli...@charter.net> wrote: > > > >> On 03/04/2017 09:58 AM, Andre Vehreschild wrote: > >> > Hi all, > >> > > >> > attached patch polishes the one begun by Alessandro. It adds > >> > documentation and fixes the style issues. Furthermore did I try to > >> > interpret the standard according to the FAIL IMAGE statement. IMHO > >> > should it just quit the executable without any error code. The > >> > caf_single library emits "FAIL IMAGE" to stderr, while in coarray=single > >> > mode it just quits. What do you think? > >> > > >> > Bootstraps and regtests ok on x86_64-linux/f25. Ok for trunk? (May be > >> > later). > >> > > >> > Gruß, > >> > Andre > >> > > >> > >> From my read: > >> > >> "A failed image is usually associated with a hardware failure of the > >> processor, memory system, or interconnection network" > >> > >> Since the FAIL IMAGE statement is intended to simulate such failure, I > >> agree with your interpretation as well, it just stops execution. > >> > >> Yes OK for trunk now. > >> > >> Jerry > > > > > > -- > > Andre Vehreschild * Email: vehre ad gmx dot de -- Andre Vehreschild * Email: vehre ad gmx dot de
Re: [PATCH, Fortran, Coarray, v1] Add support for failed images
Hi Jerry,
thanks for seconding my read of the standard and reviewing so quickly.
Committed as r245900.
Regards,
Andre
On Sat, 4 Mar 2017 15:06:25 -0800
Jerry DeLisle <jvdeli...@charter.net> wrote:
> On 03/04/2017 09:58 AM, Andre Vehreschild wrote:
> > Hi all,
> >
> > attached patch polishes the one begun by Alessandro. It adds documentation
> > and fixes the style issues. Furthermore did I try to interpret the standard
> > according to the FAIL IMAGE statement. IMHO should it just quit the
> > executable without any error code. The caf_single library emits "FAIL
> > IMAGE" to stderr, while in coarray=single mode it just quits. What do you
> > think?
> >
> > Bootstraps and regtests ok on x86_64-linux/f25. Ok for trunk? (May be
> > later).
> >
> > Gruß,
> > Andre
> >
>
> From my read:
>
> "A failed image is usually associated with a hardware failure of the
> processor, memory system, or interconnection network"
>
> Since the FAIL IMAGE statement is intended to simulate such failure, I agree
> with your interpretation as well, it just stops execution.
>
> Yes OK for trunk now.
>
> Jerry
--
Andre Vehreschild * Email: vehre ad gmx dot de
Index: gcc/fortran/ChangeLog
=======
--- gcc/fortran/ChangeLog (Revision 245899)
+++ gcc/fortran/ChangeLog (Arbeitskopie)
@@ -1,3 +1,51 @@
+2017-03-05 Andre Vehreschild <ve...@gcc.gnu.org>,
+ Alessandro Fanfarillo <fanfarillo@gmail.com>
+
+ * check.c (positive_check): Add new function checking constant for
+ being greater then zero.
+ (gfc_check_image_status): Add checking of image_status arguments.
+ (gfc_check_failed_or_stopped_images): Same but for failed_- and
+ stopped_images function.
+ * dump-parse-tree.c (show_code_node): Added output of FAIL IMAGE.
+ * gfortran.h (enum gfc_statement): Added FAIL_IMAGE_ST.
+ (enum gfc_isym_id): Added new intrinsic symbols.
+ (enum gfc_exec_op): Added EXEC_FAIL_IMAGE.
+ * gfortran.texi: Added description for the new API functions. Updated
+ coverage of gfortran of TS18508.
+ * intrinsic.c (add_functions): Added symbols to resolve new intrinsic
+ functions.
+ * intrinsic.h: Added prototypes.
+ * iresolve.c (gfc_resolve_failed_images): Resolve the failed_images
+ intrinsic.
+ (gfc_resolve_image_status): Same for image_status.
+ (gfc_resolve_stopped_images): Same for stopped_images.
+ * libgfortran.h: Added prototypes.
+ * match.c (gfc_match_if): Added matching of FAIL IMAGE statement.
+ (gfc_match_fail_image): Match a FAIL IMAGE statement.
+ * match.h: Added prototype.
+ * parse.c (decode_statement): Added matching for FAIL IMAGE.
+ (next_statement): Same.
+ (gfc_ascii_statement): Same.
+ * resolve.c: Same.
+ * simplify.c (gfc_simplify_failed_or_stopped_images): For COARRAY=
+ single a constant result can be returne.d
+ (gfc_simplify_image_status): For COARRAY=single the result is constant.
+ * st.c (gfc_free_statement): Added FAIL_IMAGE handling.
+ * trans-decl.c (gfc_build_builtin_function_decls): Added decls of the
+ new intrinsics.
+ * trans-expr.c (gfc_conv_procedure_call): This is first time all
+ arguments of a function are optional, which is now handled here
+ correctly.
+ * trans-intrinsic.c (conv_intrinsic_image_status): Translate
+ image_status.
+ (gfc_conv_intrinsic_function): Add support for image_status.
+ (gfc_is_intrinsic_libcall): Add support for the remaining new
+ intrinsics.
+ * trans-stmt.c (gfc_trans_fail_image): Trans a fail image.
+ * trans-stmt.h: Add the prototype for the above.
+ * trans.c (trans_code): Dispatch for fail_image.
+ * trans.h: Add the trees for the new intrinsics.
+
2017-03-03 Jerry DeLisle <jvdeli...@gcc.gnu.org>
PR fortran/79841
Index: gcc/fortran/check.c
===
--- gcc/fortran/check.c (Revision 245899)
+++ gcc/fortran/check.c (Arbeitskopie)
@@ -295,6 +295,29 @@
}
+/* If expr is a constant, then check to ensure that it is greater than zero. */
+
+static bool
+positive_check (int n, gfc_expr *expr)
+{
+ int i;
+
+ if (expr->expr_type == EXPR_CONSTANT)
+{
+ gfc_extract_int (expr, );
+ if (i <= 0)
+ {
+ gfc_error ("%qs argument of %qs intrinsic at %L must be positive",
+ gfc_current_intrinsic_arg[n]->name, gfc_current_intrinsic,
+ >where);
+ return false;
+ }
+}
+
+ return true;
+}
+
+
/* If expr2 is constant, then check that the value is less than
(less than or equal to, if 'or_equal' is true) bit_size(expr1). */
@@ -1138,6 +1161,60 @@
bool
+gfc_check_image_status (gfc_expr *image, gfc_expr *team)
+{
+ /* IMAGE has to be a positive, scalar integer. */
+ if (!type_check (image, 0, BT_INTEGER) || !scalar_check (image, 0)
+ || !positive_check (0, image))
+return fals
Re: [PATCH, Fortran, Coarray, v1] Add support for failed images
Hi Alessandro, Yes of course. I planned to. Sorry that I forgot. - Andre Am 4. März 2017 20:51:58 MEZ schrieb Alessandro Fanfarillo <fanfarillo@gmail.com>: >Hi Andre, >thanks for your work on the patch. I agree with you about exit(0) >statement in libcaf_single. >Could you please add my name and contact (Alessandro Fanfarillo ><fanfarillo@gmail.com>) below yours in the changelog? > >Thanks, >Alessandro > > >2017-03-04 10:58 GMT-07:00 Andre Vehreschild <ve...@gmx.de>: >> Hi all, >> >> attached patch polishes the one begun by Alessandro. It adds >documentation and >> fixes the style issues. Furthermore did I try to interpret the >standard >> according to the FAIL IMAGE statement. IMHO should it just quit the >executable >> without any error code. The caf_single library emits "FAIL IMAGE" to >stderr, >> while in coarray=single mode it just quits. What do you think? >> >> Bootstraps and regtests ok on x86_64-linux/f25. Ok for trunk? (May be >later). >> >> Gruß, >> Andre >> -- >> Andre Vehreschild * Email: vehre ad gmx dot de -- Andre Vehreschild * Kreuzherrenstr. 8 * 52062 Aachen Tel.: +49 241 929 10 18 * ve...@gmx.de
[PATCH, Fortran, Coarray, v1] Add support for failed images
Hi all,
attached patch polishes the one begun by Alessandro. It adds documentation and
fixes the style issues. Furthermore did I try to interpret the standard
according to the FAIL IMAGE statement. IMHO should it just quit the executable
without any error code. The caf_single library emits "FAIL IMAGE" to stderr,
while in coarray=single mode it just quits. What do you think?
Bootstraps and regtests ok on x86_64-linux/f25. Ok for trunk? (May be later).
Gruß,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
gcc/fortran/ChangeLog:
2017-03-04 Andre Vehreschild <ve...@gcc.gnu.org>
* check.c (positive_check): Add new function checking constant for
being greater then zero.
(gfc_check_image_status): Add checking of image_status arguments.
(gfc_check_failed_or_stopped_images): Same but for failed_- and
stopped_images function.
* dump-parse-tree.c (show_code_node): Added output of FAIL IMAGE.
* gfortran.h (enum gfc_statement): Added FAIL_IMAGE_ST.
(enum gfc_isym_id): Added new intrinsic symbols.
(enum gfc_exec_op): Added EXEC_FAIL_IMAGE.
* gfortran.texi: Added description for the new API functions. Updated
coverage of gfortran of TS18508.
* intrinsic.c (add_functions): Added symbols to resolve new intrinsic
functions.
* intrinsic.h: Added prototypes.
* iresolve.c (gfc_resolve_failed_images): Resolve the failed_images
intrinsic.
(gfc_resolve_image_status): Same for image_status.
(gfc_resolve_stopped_images): Same for stopped_images.
* libgfortran.h: Added prototypes.
* match.c (gfc_match_if): Added matching of FAIL IMAGE statement.
(gfc_match_fail_image): Match a FAIL IMAGE statement.
* match.h: Added prototype.
* parse.c (decode_statement): Added matching for FAIL IMAGE.
(next_statement): Same.
(gfc_ascii_statement): Same.
* resolve.c: Same.
* simplify.c (gfc_simplify_failed_or_stopped_images): For COARRAY=
single a constant result can be returne.d
(gfc_simplify_image_status): For COARRAY=single the result is constant.
* st.c (gfc_free_statement): Added FAIL_IMAGE handling.
* trans-decl.c (gfc_build_builtin_function_decls): Added decls of the
new intrinsics.
* trans-expr.c (gfc_conv_procedure_call): This is first time all
arguments of a function are optional, which is now handled here
correctly.
* trans-intrinsic.c (conv_intrinsic_image_status): Translate
image_status.
(gfc_conv_intrinsic_function): Add support for image_status.
(gfc_is_intrinsic_libcall): Add support for the remaining new
intrinsics.
* trans-stmt.c (gfc_trans_fail_image): Trans a fail image.
* trans-stmt.h: Add the prototype for the above.
* trans.c (trans_code): Dispatch for fail_image.
* trans.h: Add the trees for the new intrinsics.
libgfortran/ChangeLog:
2017-03-04 Andre Vehreschild <ve...@gcc.gnu.org>
* caf/libcaf.h: Added prototypes and stat codes for failed and stopped
images.
* caf/single.c (void _gfortran_caf_fail_image): Add the routine.
(int _gfortran_caf_image_status): Same.
(_gfortran_caf_failed_images): Same.
(_gfortran_caf_stopped_images): Same.
gcc/testsuite/ChangeLog:
2017-03-04 Andre Vehreschild <ve...@gcc.gnu.org>
* gfortran.dg/coarray/fail_image_1.f08: New test.
* gfortran.dg/coarray/fail_image_2.f08: New test.
* gfortran.dg/coarray/failed_images_1.f08: New test.
* gfortran.dg/coarray/failed_images_2.f08: New test.
* gfortran.dg/coarray/image_status_1.f08: New test.
* gfortran.dg/coarray/image_status_2.f08: New test.
* gfortran.dg/coarray/stopped_images_1.f08: New test.
* gfortran.dg/coarray/stopped_images_2.f08: New test.
* gfortran.dg/coarray_fail_st.f90: New test.
* gfortran.dg/coarray_failed_images_1.f08: New test.
* gfortran.dg/coarray_image_status_1.f08: New test.
* gfortran.dg/coarray_stopped_images_1.f08: New test.
diff --git a/gcc/fortran/check.c b/gcc/fortran/check.c
index c22bfa9..45bc68e 100644
--- a/gcc/fortran/check.c
+++ b/gcc/fortran/check.c
@@ -295,6 +295,29 @@ nonnegative_check (const char *arg, gfc_expr *expr)
}
+/* If expr is a constant, then check to ensure that it is greater than zero. */
+
+static bool
+positive_check (int n, gfc_expr *expr)
+{
+ int i;
+
+ if (expr->expr_type == EXPR_CONSTANT)
+{
+ gfc_extract_int (expr, );
+ if (i <= 0)
+ {
+ gfc_error ("%qs argument of %qs intrinsic at %L must be positive",
+ gfc_current_intrinsic_arg[n]->name, gfc_current_intrinsic,
+ >where);
+ return false;
+ }
+}
+
+ return true;
+}
+
+
/* If expr2 is constant, then check that the value is less than
Re: [Ping, PATCH, Fortran, 79229, v1] [7 Regression] ICE in gfc_trans_assignment_1 with -fcheck=mem
Hi Jerry, hi all,
thanks for the review. Committed as r245581.
Regards,
Andre
On Sun, 19 Feb 2017 08:58:46 -0800
Jerry DeLisle <jvdeli...@charter.net> wrote:
> On 02/19/2017 08:42 AM, Andre Vehreschild wrote:
> > Ping!
> >
> > this time with correct PR number: 79229.
> >
> > On Tue, 7 Feb 2017 08:31:22 +0100
> > Andre Vehreschild <ve...@gmx.de> wrote:
> >
> >> Hi all,
> >>
> >> attached patch fixes the issue of 79229 (which is not a regression).
> >> The issue was that the code generating the checking was expecting a
> >> pointer type, but got an indirect ref to it. This is fixed now.
> >>
> >> Bootstraps and regtests ok on x86_64-linux/f25. Ok for trunk?
> >>
> >> Regards,
> >>Andre
> >
> >
>
> This is OK,
>
> Jerry
--
Andre Vehreschild * Email: vehre ad gmx dot de
Index: gcc/fortran/ChangeLog
=======
--- gcc/fortran/ChangeLog (Revision 245580)
+++ gcc/fortran/ChangeLog (Arbeitskopie)
@@ -7,6 +7,12 @@
2017-02-19 Andre Vehreschild <ve...@gcc.gnu.org>
+ PR fortran/79229
+ * trans-expr.c (gfc_trans_assignment_1): Deref indirect refs when
+ compiling with -fcheck=mem to check the pointer and not the data.
+
+2017-02-19 Andre Vehreschild <ve...@gcc.gnu.org>
+
PR fortran/79335
* trans-array.c (duplicate_allocatable_coarray): Ensure attributes
passed are properly initialized.
Index: gcc/fortran/trans-expr.c
===
--- gcc/fortran/trans-expr.c (Revision 245580)
+++ gcc/fortran/trans-expr.c (Arbeitskopie)
@@ -9961,13 +9961,16 @@
tree cond;
const char* msg;
+ tmp = INDIRECT_REF_P (lse.expr)
+ ? gfc_build_addr_expr (NULL_TREE, lse.expr) : lse.expr;
+
/* We should only get array references here. */
- gcc_assert (TREE_CODE (lse.expr) == POINTER_PLUS_EXPR
- || TREE_CODE (lse.expr) == ARRAY_REF);
+ gcc_assert (TREE_CODE (tmp) == POINTER_PLUS_EXPR
+ || TREE_CODE (tmp) == ARRAY_REF);
/* 'tmp' is either the pointer to the array(POINTER_PLUS_EXPR)
or the array itself(ARRAY_REF). */
- tmp = TREE_OPERAND (lse.expr, 0);
+ tmp = TREE_OPERAND (tmp, 0);
/* Provide the address of the array. */
if (TREE_CODE (lse.expr) == ARRAY_REF)
Index: gcc/testsuite/ChangeLog
===========
--- gcc/testsuite/ChangeLog (Revision 245580)
+++ gcc/testsuite/ChangeLog (Arbeitskopie)
@@ -1,3 +1,8 @@
+2017-02-19 Andre Vehreschild <ve...@gcc.gnu.org>
+
+ PR fortran/79229
+ * gfortran.dg/class_allocate_24.f90: New test.
+
2017-02-19 Paul Thomas <pa...@gcc.gnu.org>
PR fortran/79402
Index: gcc/testsuite/gfortran.dg/class_allocate_24.f90
===
--- gcc/testsuite/gfortran.dg/class_allocate_24.f90 (nicht existent)
+++ gcc/testsuite/gfortran.dg/class_allocate_24.f90 (Arbeitskopie)
@@ -0,0 +1,16 @@
+! { dg-do compile }
+! { dg-options "-fcheck=mem" }
+!
+! Compile time check only, to test that the ICE is fixed in the assignment of the
+! default initializer of the class to sf.
+
+implicit none
+
+type :: t
+ integer, pointer :: data => null ()
+end type
+
+class(t), dimension(:), allocatable :: sf
+allocate (t :: sf (1))
+end
+
Re: [Ping, PATCH, Fortran, 79229, v1] [7 Regression] ICE in gfc_trans_assignment_1 with -fcheck=mem
Ping!
this time with correct PR number: 79229.
On Tue, 7 Feb 2017 08:31:22 +0100
Andre Vehreschild <ve...@gmx.de> wrote:
> Hi all,
>
> attached patch fixes the issue of 79229 (which is not a regression).
> The issue was that the code generating the checking was expecting a
> pointer type, but got an indirect ref to it. This is fixed now.
>
> Bootstraps and regtests ok on x86_64-linux/f25. Ok for trunk?
>
> Regards,
> Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
gcc/testsuite/ChangeLog:
2017-02-07 Andre Vehreschild <ve...@gcc.gnu.org>
PR fortran/79229
* gfortran.dg/class_allocate_24.f90: New test.
gcc/fortran/ChangeLog:
2017-02-07 Andre Vehreschild <ve...@gcc.gnu.org>
PR fortran/79229
* trans-expr.c (gfc_trans_assignment_1): Deref indirect refs when
compiling with -fcheck=mem to check the pointer and not the data.
diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
index 138af56..fcd6f16 100644
--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -9959,13 +9959,16 @@ gfc_trans_assignment_1 (gfc_expr * expr1, gfc_expr * expr2, bool init_flag,
tree cond;
const char* msg;
+ tmp = INDIRECT_REF_P (lse.expr)
+ ? gfc_build_addr_expr (NULL_TREE, lse.expr) : lse.expr;
+
/* We should only get array references here. */
- gcc_assert (TREE_CODE (lse.expr) == POINTER_PLUS_EXPR
- || TREE_CODE (lse.expr) == ARRAY_REF);
+ gcc_assert (TREE_CODE (tmp) == POINTER_PLUS_EXPR
+ || TREE_CODE (tmp) == ARRAY_REF);
/* 'tmp' is either the pointer to the array(POINTER_PLUS_EXPR)
or the array itself(ARRAY_REF). */
- tmp = TREE_OPERAND (lse.expr, 0);
+ tmp = TREE_OPERAND (tmp, 0);
/* Provide the address of the array. */
if (TREE_CODE (lse.expr) == ARRAY_REF)
diff --git a/gcc/testsuite/gfortran.dg/class_allocate_24.f90 b/gcc/testsuite/gfortran.dg/class_allocate_24.f90
new file mode 100644
index 000..883247d
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/class_allocate_24.f90
@@ -0,0 +1,16 @@
+! { dg-do compile }
+! { dg-options "-fcheck=mem" }
+!
+! Compile time check only, to test that the ICE is fixed in the assignment of the
+! default initializer of the class to sf.
+
+implicit none
+
+type :: t
+ integer, pointer :: data => null ()
+end type
+
+class(t), dimension(:), allocatable :: sf
+allocate (t :: sf (1))
+end
+
[PATCH, Fortran, pr79335, v2] [7 Regression] Conditional jump or move depends on uninitialised in value get_scalar_to_descriptor_type(tree_node*, symbol_attribute) (trans-expr.c:53)
Hi all,
attached patch fixes (hopefully) all occurrences of uninitialized
symbol_attributes used for getting a descriptor for a scalar as reported in the
reopended pr79335.
Bootstraps and regtests ok on x86_64-linux/f25. Ok for trunk?
Regards,
Andre
On Tue, 14 Feb 2017 08:32:59 +
"marxin at gcc dot gnu.org" <gcc-bugzi...@gcc.gnu.org> wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79335
>
> Martin Liška changed:
>
>What|Removed |Added
>
> Status|WAITING |REOPENED
>
> --- Comment #8 from Martin Liška ---
> Thanks for fix, however there are still some issues:
>
> $ valgrind --leak-check=yes --trace-children=yes ./xgcc -B.
> /home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/coarray_lib_alloc_4.f90
> -fcoarray=lib -lcaf_single
>
> ==15334== Conditional jump or move depends on uninitialised value(s)
> ==15334==at 0x95EE91: get_scalar_to_descriptor_type(tree_node*,
> symbol_attribute) (trans-expr.c:53)
> ==15334==by 0x95EFF0: gfc_conv_scalar_to_descriptor(gfc_se*, tree_node*,
> symbol_attribute) (trans-expr.c:71)
> ==15334==by 0x977D9C: gfc_trans_structure_assign(tree_node*, gfc_expr*,
> bool, bool) (trans-expr.c:7552)
> ==15334==by 0x97830F: gfc_conv_structure(gfc_se*, gfc_expr*, int)
> (trans-expr.c:7646)
> ==15334==by 0x978AD9: gfc_conv_expr(gfc_se*, gfc_expr*)
> (trans-expr.c:7813) ==15334==by 0x97F5EC:
> gfc_trans_assignment_1(gfc_expr*, gfc_expr*, bool, bool, bool, bool)
> (trans-expr.c:9923) ==15334==by 0x9804A5: gfc_trans_assignment(gfc_expr*,
> gfc_expr*, bool, bool, bool, bool) (trans-expr.c:10231)
> ==15334==by 0x9804E1: gfc_trans_init_assign(gfc_code*)
> (trans-expr.c:10237) ==15334==by 0x9D2655: gfc_trans_allocate(gfc_code*)
> (trans-stmt.c:6328) ==15334==by 0x92077B: trans_code(gfc_code*,
> tree_node*) (trans.c:1965) ==15334==by 0x9209F6:
> gfc_trans_code(gfc_code*) (trans.c:2124) ==15334==by 0x95B503:
> gfc_generate_function_code(gfc_namespace*) (trans-decl.c:6306)
> ...
>
--
Andre Vehreschild * Email: vehre ad gmx dot de
gcc/fortran/ChangeLog:
2017-02-15 Andre Vehreschild <ve...@gcc.gnu.org>
PR fortran/79335
* trans-array.c (duplicate_allocatable_coarray): Ensure attributes
passed are properly initialized.
(structure_alloc_comps): Same.
* trans-expr.c (gfc_trans_structure_assign): Same.
diff --git a/gcc/fortran/trans-array.c b/gcc/fortran/trans-array.c
index d0dfc26..47e8c09 100644
--- a/gcc/fortran/trans-array.c
+++ b/gcc/fortran/trans-array.c
@@ -7950,6 +7950,8 @@ duplicate_allocatable_coarray (tree dest, tree dest_tok, tree src,
tree dummy_desc;
gfc_init_se (, NULL);
+ gfc_clear_attr ();
+ attr.allocatable = 1;
dummy_desc = gfc_conv_scalar_to_descriptor (, dest, attr);
gfc_add_block_to_block (, );
size = TYPE_SIZE_UNIT (TREE_TYPE (type));
@@ -8518,14 +8520,15 @@ structure_alloc_comps (gfc_symbol * der_type, tree decl,
else
{
gfc_se se;
- symbol_attribute attr;
gfc_init_se (, NULL);
- gfc_clear_attr ();
token = fold_build3_loc (input_location, COMPONENT_REF,
pvoid_type_node, decl, c->caf_token,
NULL_TREE);
- comp = gfc_conv_scalar_to_descriptor (, comp, attr);
+ comp = gfc_conv_scalar_to_descriptor (, comp,
+ c->ts.type == BT_CLASS
+ ? CLASS_DATA (c)->attr
+ : c->attr);
gfc_add_block_to_block (, );
}
diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
index 87bf069..cc41fe3 100644
--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -7516,7 +7516,6 @@ gfc_trans_structure_assign (tree dest, gfc_expr * expr, bool init, bool coarray)
&& (!c->expr || c->expr->expr_type == EXPR_NULL))
{
tree token, desc, size;
- symbol_attribute attr;
bool is_array = cm->ts.type == BT_CLASS
? CLASS_DATA (cm)->attr.dimension : cm->attr.dimension;
@@ -7549,7 +7548,10 @@ gfc_trans_structure_assign (tree dest, gfc_expr * expr, bool init, bool coarray)
}
else
{
- desc = gfc_conv_scalar_to_descriptor (, field, attr);
+ desc = gfc_conv_scalar_to_descriptor (, field,
+ cm->ts.type == BT_CLASS
+ ? CLASS_DATA (cm)->attr
+ : cm->attr);
size = TYPE_SIZE_UNIT (TREE_TYPE (field));
}
gfc_add_block_to_block (, );
Re: [Fortran, Patch, CAF] Failed Images patch (TS 18508)
t;> https://gcc.gnu.org/ml/fortran/2017-01/msg00054.html. > >>> > >>> Suggestions on how to fix potential issues are more than welcome. > >>> > >>> Regards, > >>> Alessandro > >>> > >> > >> On the failed images test: > >> > >> program test_image_status > >> + implicit none > >> + > >> + write(*,*) image_status(1) > >> + > >> > >> Write to a string and test the results. > >> > >> I assume you have regression tested this again as stated in the earlier > >> discussion. > >> > >> I think this is OK to go in. > >> > >> Jerry > >> > >> -- Andre Vehreschild * Email: vehre ad gmx dot de
[PATCH, Fortran, 29229, v1] [7 Regression] ICE in gfc_trans_assignment_1 with -fcheck=mem
Hi all,
attached patch fixes the issue of 79229 (which is not a regression).
The issue was that the code generating the checking was expecting a
pointer type, but got an indirect ref to it. This is fixed now.
Bootstraps and regtests ok on x86_64-linux/f25. Ok for trunk?
Regards,
Andre
--
Andre Vehreschild * Kreuzherrenstr. 8 * 52062 Aachen
Tel.: +49 241 9291018 * Email: ve...@gmx.de
gcc/testsuite/ChangeLog:
2017-02-07 Andre Vehreschild <ve...@gcc.gnu.org>
PR fortran/79229
* gfortran.dg/class_allocate_24.f90: New test.
gcc/fortran/ChangeLog:
2017-02-07 Andre Vehreschild <ve...@gcc.gnu.org>
PR fortran/79229
* trans-expr.c (gfc_trans_assignment_1): Deref indirect refs when
compiling with -fcheck=mem to check the pointer and not the data.
diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
index 138af56..fcd6f16 100644
--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -9959,13 +9959,16 @@ gfc_trans_assignment_1 (gfc_expr * expr1, gfc_expr * expr2, bool init_flag,
tree cond;
const char* msg;
+ tmp = INDIRECT_REF_P (lse.expr)
+ ? gfc_build_addr_expr (NULL_TREE, lse.expr) : lse.expr;
+
/* We should only get array references here. */
- gcc_assert (TREE_CODE (lse.expr) == POINTER_PLUS_EXPR
- || TREE_CODE (lse.expr) == ARRAY_REF);
+ gcc_assert (TREE_CODE (tmp) == POINTER_PLUS_EXPR
+ || TREE_CODE (tmp) == ARRAY_REF);
/* 'tmp' is either the pointer to the array(POINTER_PLUS_EXPR)
or the array itself(ARRAY_REF). */
- tmp = TREE_OPERAND (lse.expr, 0);
+ tmp = TREE_OPERAND (tmp, 0);
/* Provide the address of the array. */
if (TREE_CODE (lse.expr) == ARRAY_REF)
diff --git a/gcc/testsuite/gfortran.dg/class_allocate_24.f90 b/gcc/testsuite/gfortran.dg/class_allocate_24.f90
new file mode 100644
index 000..883247d
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/class_allocate_24.f90
@@ -0,0 +1,16 @@
+! { dg-do compile }
+! { dg-options "-fcheck=mem" }
+!
+! Compile time check only, to test that the ICE is fixed in the assignment of the
+! default initializer of the class to sf.
+
+implicit none
+
+type :: t
+ integer, pointer :: data => null ()
+end type
+
+class(t), dimension(:), allocatable :: sf
+allocate (t :: sf (1))
+end
+
Re: [PATCH, Fortran, pr79344, v1] [7 Regression] segmentation faults and run-time errors
Hi Mikael,
thanks for the fast review. Committed as r245193.
Regards,
Andre
On Sun, 5 Feb 2017 15:32:25 +0100
Mikael Morin <morin-mik...@orange.fr> wrote:
> Le 04/02/2017 à 19:43, Andre Vehreschild a écrit :
> > Hi all,
> >
> > attached patch fixes the issue of losing the data in the SOURCE= expression
> > of an ALLOCATE() when the source-expression is just a simple variable. The
> > issue was that internally a temporary variable was created, whose
> > components were freed afterwards. Now the components are only freed on
> > temporary objects, i.e., when the source-expression is not an
> > EXPR_VARIABLE, e.g. an EXPR_STRUCTURE or EXPR_FUNCTION.
> >
> > Bootstraps and regtests ok on x86_64-linux/f25. Ok for trunk?
> >
> Hello,
>
> this looks good to me.
> Thanks
>
> Mikael
>
--
Andre Vehreschild * Email: vehre ad gmx dot de
Index: gcc/testsuite/ChangeLog
===
--- gcc/testsuite/ChangeLog (Revision 245193)
+++ gcc/testsuite/ChangeLog (Arbeitskopie)
@@ -1,5 +1,10 @@
2017-02-05 Andre Vehreschild <ve...@gcc.gnu.org>
+ PR fortran/79344
+ * gfortran.dg/allocate_with_source_24.f90: New test.
+
+2017-02-05 Andre Vehreschild <ve...@gcc.gnu.org>
+
PR fortran/79230
* gfortran.dg/der_ptr_component_2.f90: New test.
Index: gcc/testsuite/gfortran.dg/allocate_with_source_24.f90
===
--- gcc/testsuite/gfortran.dg/allocate_with_source_24.f90 (nicht existent)
+++ gcc/testsuite/gfortran.dg/allocate_with_source_24.f90 (Revision 245194)
@@ -0,0 +1,134 @@
+! { dg-do run }
+!
+! Test that the temporary in a sourced-ALLOCATE is not freeed.
+! PR fortran/79344
+! Contributed by Juergen Reuter
+
+module iso_varying_string
+ implicit none
+
+ type, public :: varying_string
+ private
+ character(LEN=1), dimension(:), allocatable :: chars
+ end type varying_string
+
+ interface assignment(=)
+ module procedure op_assign_VS_CH
+ end interface assignment(=)
+
+ interface operator(/=)
+ module procedure op_not_equal_VS_CA
+ end interface operator(/=)
+
+ interface len
+ module procedure len_
+ end interface len
+
+ interface var_str
+ module procedure var_str_
+ end interface var_str
+
+ public :: assignment(=)
+ public :: operator(/=)
+ public :: len
+
+ private :: op_assign_VS_CH
+ private :: op_not_equal_VS_CA
+ private :: char_auto
+ private :: len_
+ private :: var_str_
+
+contains
+
+ elemental function len_ (string) result (length)
+type(varying_string), intent(in) :: string
+integer :: length
+if(ALLOCATED(string%chars)) then
+ length = SIZE(string%chars)
+else
+ length = 0
+endif
+ end function len_
+
+ elemental subroutine op_assign_VS_CH (var, exp)
+type(varying_string), intent(out) :: var
+character(LEN=*), intent(in) :: exp
+var = var_str(exp)
+ end subroutine op_assign_VS_CH
+
+ pure function op_not_equal_VS_CA (var, exp) result(res)
+type(varying_string), intent(in) :: var
+character(LEN=*), intent(in) :: exp
+logical :: res
+integer :: i
+res = .true.
+if (len(exp) /= size(var%chars)) return
+do i = 1, size(var%chars)
+ if (var%chars(i) /= exp(i:i)) return
+end do
+res = .false.
+ end function op_not_equal_VS_CA
+
+ pure function char_auto (string) result (char_string)
+type(varying_string), intent(in) :: string
+character(LEN=len(string)) :: char_string
+integer :: i_char
+forall(i_char = 1:len(string))
+ char_string(i_char:i_char) = string%chars(i_char)
+end forall
+ end function char_auto
+
+ elemental function var_str_ (char) result (string)
+character(LEN=*), intent(in) :: char
+type(varying_string) :: string
+integer :: length
+integer :: i_char
+length = LEN(char)
+ALLOCATE(string%chars(length))
+forall(i_char = 1:length)
+ string%chars(i_char) = char(i_char:i_char)
+end forall
+ end function var_str_
+
+end module iso_varying_string
+
+!
+
+program test_pr79344
+
+ use iso_varying_string, string_t => varying_string
+
+ implicit none
+
+ type :: field_data_t
+ type(string_t), dimension(:), allocatable :: name
+ end type field_data_t
+
+ type(field_data_t) :: model, model2
+ allocate(model%name(2))
+ model%name(1) = "foo"
+ model%name(2) = "bar"
+ call copy(model, model2)
+contains
+
+ subroutine copy(prt, prt_src)
+implicit none
+type(field_data_t), intent(inout) :: prt
+type(field_data_t), intent(in) :: prt_src
+integer :: i
+if (allocated (prt_src%name)) then
+ if (prt_src%name(1) /= "foo") call abort()
+ if (prt_src%name(2) /= "bar") call abort()
Re: [PATCH, Fortran, pr79335, v1] [7 Regression] Conditional jump or move depends on uninitialised in value get_scalar_to_descriptor_type(tree_node*, symbol_attribute) (trans-expr.c:53)
Hi Paul,
and the last one committed as r245193. Thanks again for the reviews.
Regards,
Andre
On Sat, 4 Feb 2017 17:16:56 +
Paul Richard Thomas <paul.richard.tho...@gmail.com> wrote:
> Hi Andre,
>
> This is getting to be a bit monotonous :-) OK for trunk.
>
> Thanks for the three patches.
>
> Paul
>
> PS Are you in a position to have a stab at PR79344? This would go a
> long way to sorting out Juergen's test suite. Also, this must be the
> third time that I have been involved in breaking iso_varying_string
> and I think that others have too :-( We must start running the
> testsuite on a regular basis. Unfortunately, it lacks a harness to run
> all the tests automatically.
>
> PPS I am some days away yet from recovering from my move from France
> to the UK and so would defer to you if you can come up with a fix.
>
> On 4 February 2017 at 13:39, Andre Vehreschild <ve...@gmx.de> wrote:
> > Hi all,
> >
> > attached patch fixes the access of uninitialized data. Thanks Martin for
> > analyzing this so far. The symbol_attributes on the stack was used
> > without initializing it from the symbol's attributes.
> >
> > Bootstraps and regstests ok on x86_64-linux-gnu/f25. Ok for trunk?
> >
> > Regards,
> > Andre
> > --
> > Andre Vehreschild * Email: vehre ad gmx dot de
>
>
>
--
Andre Vehreschild * Email: vehre ad gmx dot de
Index: gcc/fortran/ChangeLog
=======
--- gcc/fortran/ChangeLog (Revision 245192)
+++ gcc/fortran/ChangeLog (Arbeitskopie)
@@ -1,5 +1,11 @@
2017-02-05 Andre Vehreschild <ve...@gcc.gnu.org>
+ PR fortran/79335
+ * trans-decl.c (generate_coarray_sym_init): Retrieve the symbol's
+ attributes before using them.
+
+2017-02-05 Andre Vehreschild <ve...@gcc.gnu.org>
+
PR fortran/78958
* trans-stmt.c (gfc_trans_allocate): Add the multiplying the _len
component of unlimited polymorphic objects when source-allocating.
Index: gcc/fortran/trans-decl.c
===
--- gcc/fortran/trans-decl.c (Revision 245191)
+++ gcc/fortran/trans-decl.c (Arbeitskopie)
@@ -5128,6 +5128,16 @@
else
reg_type = GFC_CAF_COARRAY_STATIC;
+ /* Compile the symbol attribute. */
+ if (sym->ts.type == BT_CLASS)
+{
+ attr = CLASS_DATA (sym)->attr;
+ /* The pointer attribute is always set on classes, overwrite it with the
+ class_pointer attribute, which denotes the pointer for classes. */
+ attr.pointer = attr.class_pointer;
+}
+ else
+attr = sym->attr;
gfc_init_se (, NULL);
desc = gfc_conv_scalar_to_descriptor (, decl, attr);
gfc_add_block_to_block (_init_block, );
Re: [PATCH, Fortran, pr78958, v1] Unallocated memory access after SOURCE-ALLOCATEing unlimited polymorphic object
Hi Paul,
thanks for the review. Committed as r245192.
Regards,
Andre
On Sat, 4 Feb 2017 17:07:13 +
Paul Richard Thomas <paul.richard.tho...@gmail.com> wrote:
> Hi Andre,
>
> This looks to be OK for trunk.
>
> Thanks for the patch.
>
> Paul
>
> On 4 February 2017 at 13:11, Andre Vehreschild <ve...@gmx.de> wrote:
> > Hi all,
> >
> > attached patch takes the _len-component of unlimited polymorphic objects
> > into account, when source-ALLOCATEing an unlimited polymorphic object. The
> > testcase for this gcc/testsuite/gfortran.dg/alloc_comp_class_5.f03 with
> > valgrind/sanitizer. I therefore added no additional testcase.
> >
> > Bootstraps and regtests ok on x86_64-linux/f25 and as reported in the PR on
> > 32bit-hpux. Ok for trunk (when?)?
> >
> > Regards,
> > Andre
> > --
> > Andre Vehreschild * Email: vehre ad gmx dot de
>
>
>
--
Andre Vehreschild * Email: vehre ad gmx dot de
Index: gcc/fortran/ChangeLog
=======
--- gcc/fortran/ChangeLog (Revision 245191)
+++ gcc/fortran/ChangeLog (Arbeitskopie)
@@ -1,5 +1,11 @@
2017-02-05 Andre Vehreschild <ve...@gcc.gnu.org>
+ PR fortran/78958
+ * trans-stmt.c (gfc_trans_allocate): Add the multiplying the _len
+ component of unlimited polymorphic objects when source-allocating.
+
+2017-02-05 Andre Vehreschild <ve...@gcc.gnu.org>
+
PR fortran/79230
* trans-array.c (structure_alloc_comps): Ignore pointer components when
freeing structures.
Index: gcc/fortran/trans-stmt.c
===
--- gcc/fortran/trans-stmt.c (Revision 245191)
+++ gcc/fortran/trans-stmt.c (Arbeitskopie)
@@ -6009,14 +6009,21 @@
needs to be provided, which is done most of the time by the
pre-evaluation step. */
nelems = NULL_TREE;
- if (expr3_len && code->expr3->ts.type == BT_CHARACTER)
- /* When al is an array, then the element size for each element
- in the array is needed, which is the product of the len and
- esize for char arrays. */
- tmp = fold_build2_loc (input_location, MULT_EXPR,
- TREE_TYPE (expr3_esize), expr3_esize,
- fold_convert (TREE_TYPE (expr3_esize),
- expr3_len));
+ if (expr3_len && (code->expr3->ts.type == BT_CHARACTER
+ || code->expr3->ts.type == BT_CLASS))
+ {
+ /* When al is an array, then the element size for each element
+ in the array is needed, which is the product of the len and
+ esize for char arrays. For unlimited polymorphics len can be
+ zero, therefore take the maximum of len and one. */
+ tmp = fold_build2_loc (input_location, MAX_EXPR,
+ TREE_TYPE (expr3_len),
+ expr3_len, fold_convert (TREE_TYPE (expr3_len),
+ integer_one_node));
+ tmp = fold_build2_loc (input_location, MULT_EXPR,
+ TREE_TYPE (expr3_esize), expr3_esize,
+ fold_convert (TREE_TYPE (expr3_esize), tmp));
+ }
else
tmp = expr3_esize;
if (!gfc_array_allocate (, expr, stat, errmsg, errlen,
Re: [PATCH, Fortran, pr79230, v1] [7 Regression] [OOP] Run time error: double free or corruption
Hi Paul,
thanks for the review. Committed as r245191.
Regards,
Andre
On Sat, 4 Feb 2017 17:03:25 +
Paul Richard Thomas <paul.richard.tho...@gmail.com> wrote:
> Hi Andre,
>
> This looks fine to me - OK for trunk.
>
> Thanks
>
> Paul
>
> On 4 February 2017 at 11:59, Andre Vehreschild <ve...@gmx.de> wrote:
> > Hi all,
> >
> > attached patch fixes a regression when a polymorphic pointer component was
> > present. The results was a double free. The attached patch fixes this, by
> > not caring about freeing pointer components as part of gfortran's memory
> > management, i.e., the programmer has to take care about
> > freeing/disassociating the pointer using a finalizer, as is IMO the
> > intention of the Fortran standard.
> >
> > Bootstrapped and regtested ok on x86_64-linux/f25. Ok for trunk (current or
> > next, haven't monitored whether commits are still allowed)?
> >
> > Regards,
> > Andre
> > --
> > Andre Vehreschild * Email: vehre ad gmx dot de
>
>
>
--
Andre Vehreschild * Email: vehre ad gmx dot de
Index: gcc/fortran/ChangeLog
=======
--- gcc/fortran/ChangeLog (Revision 245190)
+++ gcc/fortran/ChangeLog (Arbeitskopie)
@@ -1,3 +1,9 @@
+2017-02-05 Andre Vehreschild <ve...@gcc.gnu.org>
+
+ PR fortran/79230
+ * trans-array.c (structure_alloc_comps): Ignore pointer components when
+ freeing structures.
+
2017-01-25 Maxim Ostapenko <m.ostape...@samsung.com>
PR lto/79061
Index: gcc/fortran/trans-array.c
===
--- gcc/fortran/trans-array.c (Revision 245190)
+++ gcc/fortran/trans-array.c (Arbeitskopie)
@@ -8220,9 +8220,17 @@
/* Shortcut to get the attributes of the component. */
if (c->ts.type == BT_CLASS)
- attr = _DATA (c)->attr;
+ {
+ attr = _DATA (c)->attr;
+ if (attr->class_pointer)
+ continue;
+ }
else
- attr = >attr;
+ {
+ attr = >attr;
+ if (attr->pointer)
+ continue;
+ }
if ((c->ts.type == BT_DERIVED && !c->attr.pointer)
|| (c->ts.type == BT_CLASS && !CLASS_DATA (c)->attr.class_pointer))
Index: gcc/testsuite/ChangeLog
===
--- gcc/testsuite/ChangeLog (Revision 245190)
+++ gcc/testsuite/ChangeLog (Arbeitskopie)
@@ -1,3 +1,8 @@
+2017-02-05 Andre Vehreschild <ve...@gcc.gnu.org>
+
+ PR fortran/79230
+ * gfortran.dg/der_ptr_component_2.f90: New test.
+
2017-02-05 Eric Botcazou <ebotca...@adacore.com>
* gcc.target/sparc/20170205-1.c: New test.
Index: gcc/testsuite/gfortran.dg/der_ptr_component_2.f90
===
--- gcc/testsuite/gfortran.dg/der_ptr_component_2.f90 (nicht existent)
+++ gcc/testsuite/gfortran.dg/der_ptr_component_2.f90 (Arbeitskopie)
@@ -0,0 +1,30 @@
+! { dg-do run }
+!
+! Freeing the width_data lead to double free. This testcase tests that
+! pr79230 is fixed now.
+
+program main_ut
+ implicit none
+
+ type :: data_t
+ character, allocatable :: c1
+ end type
+
+ type :: t1_t
+ character, allocatable :: c2
+ class(data_t), pointer :: width_data
+ end type
+
+ call evaluator
+
+contains
+
+ subroutine evaluator
+type(data_t), target :: par_real
+type(t1_t) :: field
+field%width_data => par_real
+ end subroutine
+
+end
+
+
[PATCH, Fortran, pr79344, v1] [7 Regression] segmentation faults and run-time errors
Hi all,
attached patch fixes the issue of losing the data in the SOURCE= expression of
an ALLOCATE() when the source-expression is just a simple variable. The issue
was that internally a temporary variable was created, whose components were
freed afterwards. Now the components are only freed on temporary objects, i.e.,
when the source-expression is not an EXPR_VARIABLE, e.g. an EXPR_STRUCTURE or
EXPR_FUNCTION.
Bootstraps and regtests ok on x86_64-linux/f25. Ok for trunk?
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
gcc/fortran/ChangeLog:
2017-02-04 Andre Vehreschild <ve...@gcc.gnu.org>
PR fortran/79344
* trans-stmt.c (gfc_trans_allocate): Only deallocate the components of
the temporary, when a new object was created for the temporary. Not
when it is just an alias to an existing object.
gcc/testsuite/ChangeLog:
2017-02-04 Andre Vehreschild <ve...@gcc.gnu.org>
* gfortran.dg/allocate_with_source_24.f90: New test.
diff --git a/gcc/fortran/trans-stmt.c b/gcc/fortran/trans-stmt.c
index 61e597f..773ca70 100644
--- a/gcc/fortran/trans-stmt.c
+++ b/gcc/fortran/trans-stmt.c
@@ -5572,7 +5572,8 @@ gfc_trans_allocate (gfc_code * code)
expression. */
if (code->expr3)
{
- bool vtab_needed = false, temp_var_needed = false;
+ bool vtab_needed = false, temp_var_needed = false,
+ temp_obj_created = false;
is_coarray = gfc_is_coarray (code->expr3);
@@ -5645,7 +5646,7 @@ gfc_trans_allocate (gfc_code * code)
code->expr3->ts,
false, true,
false, false);
- temp_var_needed = !VAR_P (se.expr);
+ temp_obj_created = temp_var_needed = !VAR_P (se.expr);
}
gfc_add_block_to_block (, );
gfc_add_block_to_block (, );
@@ -5714,11 +5715,12 @@ gfc_trans_allocate (gfc_code * code)
}
/* Deallocate any allocatable components in expressions that use a
- temporary, i.e. are not of expr-type EXPR_VARIABLE or force the
- use of a temporary, after the assignment of expr3 is completed. */
+ temporary object, i.e. are not a simple alias of to an EXPR_VARIABLE.
+ E.g. temporaries of a function call need freeing of their components
+ here. */
if ((code->expr3->ts.type == BT_DERIVED
|| code->expr3->ts.type == BT_CLASS)
- && (code->expr3->expr_type != EXPR_VARIABLE || temp_var_needed)
+ && (code->expr3->expr_type != EXPR_VARIABLE || temp_obj_created)
&& code->expr3->ts.u.derived->attr.alloc_comp)
{
tmp = gfc_deallocate_alloc_comp (code->expr3->ts.u.derived,
diff --git a/gcc/testsuite/gfortran.dg/allocate_with_source_24.f90 b/gcc/testsuite/gfortran.dg/allocate_with_source_24.f90
new file mode 100644
index 000..ec11d7a
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/allocate_with_source_24.f90
@@ -0,0 +1,134 @@
+! { dg-do run }
+!
+! Test that the temporary in a sourced-ALLOCATE is not freeed.
+! PR fortran/79344
+! Contributed by Juergen Reuter
+
+module iso_varying_string
+ implicit none
+
+ type, public :: varying_string
+ private
+ character(LEN=1), dimension(:), allocatable :: chars
+ end type varying_string
+
+ interface assignment(=)
+ module procedure op_assign_VS_CH
+ end interface assignment(=)
+
+ interface operator(/=)
+ module procedure op_not_equal_VS_CA
+ end interface operator(/=)
+
+ interface len
+ module procedure len_
+ end interface len
+
+ interface var_str
+ module procedure var_str_
+ end interface var_str
+
+ public :: assignment(=)
+ public :: operator(/=)
+ public :: len
+
+ private :: op_assign_VS_CH
+ private :: op_not_equal_VS_CA
+ private :: char_auto
+ private :: len_
+ private :: var_str_
+
+contains
+
+ elemental function len_ (string) result (length)
+type(varying_string), intent(in) :: string
+integer :: length
+if(ALLOCATED(string%chars)) then
+ length = SIZE(string%chars)
+else
+ length = 0
+endif
+ end function len_
+
+ elemental subroutine op_assign_VS_CH (var, exp)
+type(varying_string), intent(out) :: var
+character(LEN=*), intent(in) :: exp
+var = var_str(exp)
+ end subroutine op_assign_VS_CH
+
+ pure function op_not_equal_VS_CA (var, exp) result(res)
+type(varying_string), intent(in) :: var
+character(LEN=*), intent(in) :: exp
+logical :: res
+integer :: i
+res = .true.
+if (len(exp) /= size(var%chars)) return
+do i = 1, size(var%chars)
+ if (var%chars(i) /= exp(i:i)) return
+end do
+res = .false.
+ end function op_not_equal_VS_CA
+
+ pure function char_auto (string) result (char_string)
+type(varying_string), intent(in) :: string
+character(LEN=len(string)) :: char_string
+integer :: i_char
+forall(i_char = 1:len(string))
+ char_string(i_char:i_char) = string%chars(i_char)
+end
Re: [PATCH, Fortran, pr79335, v1] [7 Regression] Conditional jump or move depends on uninitialised in value get_scalar_to_descriptor_type(tree_node*, symbol_attribute) (trans-expr.c:53)
Hi Paul, > PS Are you in a position to have a stab at PR79344? This would go a > long way to sorting out Juergen's test suite. Also, this must be the > third time that I have been involved in breaking iso_varying_string > and I think that others have too :-( We must start running the > testsuite on a regular basis. Unfortunately, it lacks a harness to run > all the tests automatically. Currently executing the testsuite with a patched compiler. > PPS I am some days away yet from recovering from my move from France > to the UK and so would defer to you if you can come up with a fix. Fix present, waiting for testsuite to pass. - Andre > > On 4 February 2017 at 13:39, Andre Vehreschild <ve...@gmx.de> wrote: > > Hi all, > > > > attached patch fixes the access of uninitialized data. Thanks Martin for > > analyzing this so far. The symbol_attributes on the stack was used > > without initializing it from the symbol's attributes. > > > > Bootstraps and regstests ok on x86_64-linux-gnu/f25. Ok for trunk? > > > > Regards, > > Andre > > -- > > Andre Vehreschild * Email: vehre ad gmx dot de > > > -- Andre Vehreschild * Kreuzherrenstr. 8 * 52062 Aachen Tel.: +49 241 9291018 * Email: ve...@gmx.de
[PATCH, Fortran, pr79335, v1] [7 Regression] Conditional jump or move depends on uninitialised in value get_scalar_to_descriptor_type(tree_node*, symbol_attribute) (trans-expr.c:53)
Hi all,
attached patch fixes the access of uninitialized data. Thanks Martin for
analyzing this so far. The symbol_attributes on the stack was used
without initializing it from the symbol's attributes.
Bootstraps and regstests ok on x86_64-linux-gnu/f25. Ok for trunk?
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
gcc/fortran/ChangeLog:
2017-02-04 Andre Vehreschild <ve...@gcc.gnu.org>
PR fortran/79335
* trans-decl.c (generate_coarray_sym_init): Retrieve the symbol's
attributes before using them.
diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c
index 3e54e80..41b36a5 100644
--- a/gcc/fortran/trans-decl.c
+++ b/gcc/fortran/trans-decl.c
@@ -5128,6 +5128,16 @@ generate_coarray_sym_init (gfc_symbol *sym)
else
reg_type = GFC_CAF_COARRAY_STATIC;
+ /* Compile the symbol attribute. */
+ if (sym->ts.type == BT_CLASS)
+{
+ attr = CLASS_DATA (sym)->attr;
+ /* The pointer attribute is always set on classes, overwrite it with the
+ class_pointer attribute, which denotes the pointer for classes. */
+ attr.pointer = attr.class_pointer;
+}
+ else
+attr = sym->attr;
gfc_init_se (, NULL);
desc = gfc_conv_scalar_to_descriptor (, decl, attr);
gfc_add_block_to_block (_init_block, );
[PATCH, Fortran, pr78958, v1] Unallocated memory access after SOURCE-ALLOCATEing unlimited polymorphic object
Hi all,
attached patch takes the _len-component of unlimited polymorphic objects into
account, when source-ALLOCATEing an unlimited polymorphic object. The testcase
for this gcc/testsuite/gfortran.dg/alloc_comp_class_5.f03 with
valgrind/sanitizer. I therefore added no additional testcase.
Bootstraps and regtests ok on x86_64-linux/f25 and as reported in the PR on
32bit-hpux. Ok for trunk (when?)?
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
gcc/fortran/ChangeLog:
2017-02-04 Andre Vehreschild <ve...@gcc.gnu.org>
PR fortran/78958
* trans-stmt.c (gfc_trans_allocate): Add the multiplying the _len
component of unlimited polymorphic objects when source-allocating.
diff --git a/gcc/fortran/trans-stmt.c b/gcc/fortran/trans-stmt.c
index ad4b737..61e597f 100644
--- a/gcc/fortran/trans-stmt.c
+++ b/gcc/fortran/trans-stmt.c
@@ -6009,14 +6009,21 @@ gfc_trans_allocate (gfc_code * code)
needs to be provided, which is done most of the time by the
pre-evaluation step. */
nelems = NULL_TREE;
- if (expr3_len && code->expr3->ts.type == BT_CHARACTER)
- /* When al is an array, then the element size for each element
- in the array is needed, which is the product of the len and
- esize for char arrays. */
- tmp = fold_build2_loc (input_location, MULT_EXPR,
- TREE_TYPE (expr3_esize), expr3_esize,
- fold_convert (TREE_TYPE (expr3_esize),
- expr3_len));
+ if (expr3_len && (code->expr3->ts.type == BT_CHARACTER
+ || code->expr3->ts.type == BT_CLASS))
+ {
+ /* When al is an array, then the element size for each element
+ in the array is needed, which is the product of the len and
+ esize for char arrays. For unlimited polymorphics len can be
+ zero, therefore take the maximum of len and one. */
+ tmp = fold_build2_loc (input_location, MAX_EXPR,
+ TREE_TYPE (expr3_len),
+ expr3_len, fold_convert (TREE_TYPE (expr3_len),
+ integer_one_node));
+ tmp = fold_build2_loc (input_location, MULT_EXPR,
+ TREE_TYPE (expr3_esize), expr3_esize,
+ fold_convert (TREE_TYPE (expr3_esize), tmp));
+ }
else
tmp = expr3_esize;
if (!gfc_array_allocate (, expr, stat, errmsg, errlen,
[PATCH, Fortran, pr79230, v1] [7 Regression] [OOP] Run time error: double free or corruption
Hi all,
attached patch fixes a regression when a polymorphic pointer component was
present. The results was a double free. The attached patch fixes this, by not
caring about freeing pointer components as part of gfortran's memory management,
i.e., the programmer has to take care about freeing/disassociating the pointer
using a finalizer, as is IMO the intention of the Fortran standard.
Bootstrapped and regtested ok on x86_64-linux/f25. Ok for trunk (current or
next, haven't monitored whether commits are still allowed)?
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
gcc/fortran/ChangeLog:
2017-02-04 Andre Vehreschild <ve...@gcc.gnu.org>
PR fortran/79230
* trans-array.c (structure_alloc_comps): Ignore pointer components when
freeing structures.
gcc/testsuite/ChangeLog:
2017-02-04 Andre Vehreschild <ve...@gcc.gnu.org>
PR fortran/79230
* gfortran.dg/der_ptr_component_2.f90: New test.
diff --git a/gcc/fortran/trans-array.c b/gcc/fortran/trans-array.c
index a3aab8e..d0dfc26 100644
--- a/gcc/fortran/trans-array.c
+++ b/gcc/fortran/trans-array.c
@@ -8220,9 +8220,17 @@ structure_alloc_comps (gfc_symbol * der_type, tree decl,
/* Shortcut to get the attributes of the component. */
if (c->ts.type == BT_CLASS)
- attr = _DATA (c)->attr;
+ {
+ attr = _DATA (c)->attr;
+ if (attr->class_pointer)
+ continue;
+ }
else
- attr = >attr;
+ {
+ attr = >attr;
+ if (attr->pointer)
+ continue;
+ }
if ((c->ts.type == BT_DERIVED && !c->attr.pointer)
|| (c->ts.type == BT_CLASS && !CLASS_DATA (c)->attr.class_pointer))
diff --git a/gcc/testsuite/gfortran.dg/der_ptr_component_2.f90 b/gcc/testsuite/gfortran.dg/der_ptr_component_2.f90
new file mode 100644
index 000..4eb0869
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/der_ptr_component_2.f90
@@ -0,0 +1,30 @@
+! { dg-do run }
+!
+! Freeing the width_data lead to double free. This testcase tests that
+! pr79230 is fixed now.
+
+program main_ut
+ implicit none
+
+ type :: data_t
+ character, allocatable :: c1
+ end type
+
+ type :: t1_t
+ character, allocatable :: c2
+ class(data_t), pointer :: width_data
+ end type
+
+ call evaluator
+
+contains
+
+ subroutine evaluator
+type(data_t), target :: par_real
+type(t1_t) :: field
+field%width_data => par_real
+ end subroutine
+
+end
+
+
Re: [PATCH, Fortran, pr70696/68887, gcc-6, v1] Forgot to commit runtime part
Hi all, during the backport of pr70696 I forgot to backport the runtime part in libgfortran/caf/single.c. This is fixed by commit r245016. Sorry for the noise, regards, Andre On Sun, 29 Jan 2017 14:51:03 +0100 Andre Vehreschild <ve...@gmx.de> wrote: > Hi all, > > just applied the backport to gcc-6 as promised as r245014. > > Regards, > Andre > > On Thu, 19 Jan 2017 16:53:14 +0100 > Andre Vehreschild <ve...@gmx.de> wrote: > > > Hi Steve, > > > > thanks for the review. Committed as r244637. > > > > Regards, > > Andre > > > > On Thu, 19 Jan 2017 06:51:19 -0800 > > Steve Kargl <s...@troutmask.apl.washington.edu> wrote: > > > > > On Thu, Jan 19, 2017 at 01:07:50PM +0100, Andre Vehreschild wrote: > > > > Hi all, > > > > > > > > unfortunately triggered this patch a regression in the opencoarray's > > > > testsuite, which also occurs outside of opencoarray, when a caf-function > > > > is used in a block in the main-program. This patch fixes the error and > > > > adds a testcase. > > > > > > > > Bootstrapped and regtested ok on x86_64-linux/f25. Ok for trunk? > > > > > > > > > > Yes. > > > > > > > > > -- Andre Vehreschild * Email: vehre ad gmx dot de Index: libgfortran/caf/single.c === --- libgfortran/caf/single.c (Revision 245015) +++ libgfortran/caf/single.c (Arbeitskopie) @@ -101,9 +101,12 @@ void *local; if (type == CAF_REGTYPE_LOCK_STATIC || type == CAF_REGTYPE_LOCK_ALLOC - || type == CAF_REGTYPE_CRITICAL || type == CAF_REGTYPE_EVENT_STATIC - || type == CAF_REGTYPE_EVENT_ALLOC) -local = calloc (size, sizeof (bool)); + || type == CAF_REGTYPE_CRITICAL) + local = calloc (size, sizeof (bool)); + else if (type == CAF_REGTYPE_EVENT_STATIC || type == CAF_REGTYPE_EVENT_ALLOC) +/* In the event_(wait|post) function the counter for events is a uint32, + so better allocate enough memory here. */ +local = calloc (size, sizeof (uint32_t)); else local = malloc (size); *token = malloc (sizeof (single_token_t));
Re: [PATCH, Fortran, pr70697, v1] [Coarray] ICE on EVENT WAIT with array element UNTIL_COUNT argument
Hi all,
and here's the backport committed as r245015.
Regards,
Andre
On Fri, 13 Jan 2017 11:40:44 +0100
Andre Vehreschild <ve...@gmx.de> wrote:
> Hi Jerry,
>
> thanks again for the fast review. Committed as r244413.
>
> Will backport to gcc-6 in about a week.
>
> Regards,
> Andre
>
> On Thu, 12 Jan 2017 10:12:24 -0800
> Jerry DeLisle <jvdeli...@charter.net> wrote:
>
> > On 01/12/2017 05:43 AM, Andre Vehreschild wrote:
> > > Hi all,
> > >
> > > *** this is no duplicate, but +1 in the PR#! ***
> > >
> > > attached patch fixes the ICE by resolving the expression in UNTIL_COUNT
> > > correctly. The ICE was caused by the array-specification in UNTIL_COUNT
> > > not correctly set.
> > >
> > > Bootstraps and regtests ok on x86_64-linux/F25. Ok for trunk and gcc-6?
> > >
> > > - Andre
> > >
> >
> > OK and thanks,
> >
> > Jerry
>
>
--
Andre Vehreschild * Email: vehre ad gmx dot de
Index: gcc/fortran/ChangeLog
===
--- gcc/fortran/ChangeLog (Revision 245014)
+++ gcc/fortran/ChangeLog (Arbeitskopie)
@@ -1,5 +1,14 @@
2017-01-29 Andre Vehreschild <ve...@gcc.gnu.org>
+ Backported from trunk
+ 2017-01-13 Andre Vehreschild <ve...@gcc.gnu.org>
+
+ PR fortran/70697
+ * resolve.c (resolve_lock_unlock_event): Resolve the expression for
+ event's until_count.
+
+2017-01-29 Andre Vehreschild <ve...@gcc.gnu.org>
+
Backport from trunk
PR fortran/70696
* trans-expr.c (gfc_get_tree_for_caf_expr): Ensure the backend_decl
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (Revision 245014)
+++ gcc/fortran/resolve.c (Arbeitskopie)
@@ -8840,10 +8840,13 @@
return;
/* Check for EVENT WAIT the UNTIL_COUNT. */
- if (code->op == EXEC_EVENT_WAIT && code->expr4
- && (code->expr4->ts.type != BT_INTEGER || code->expr4->rank != 0))
-gfc_error ("UNTIL_COUNT= argument at %L must be a scalar INTEGER "
- "expression", >expr4->where);
+ if (code->op == EXEC_EVENT_WAIT && code->expr4)
+{
+ if (!gfc_resolve_expr (code->expr4) || code->expr4->ts.type != BT_INTEGER
+ || code->expr4->rank != 0)
+ gfc_error ("UNTIL_COUNT= argument at %L must be a scalar INTEGER "
+ "expression", >expr4->where);
+}
}
Index: gcc/testsuite/ChangeLog
===
--- gcc/testsuite/ChangeLog (Revision 245014)
+++ gcc/testsuite/ChangeLog (Arbeitskopie)
@@ -1,6 +1,14 @@
2017-01-29 Andre Vehreschild <ve...@gcc.gnu.org>
Backport from trunk
+ 2017-01-13 Andre Vehreschild <ve...@gcc.gnu.org>
+
+ PR fortran/70697
+ * gfortran.dg/coarray/event_4.f08: New test.
+
+2017-01-29 Andre Vehreschild <ve...@gcc.gnu.org>
+
+ Backport from trunk
2017-01-19 Andre Vehreschild <ve...@gcc.gnu.org>
PR fortran/70696
Index: gcc/testsuite/gfortran.dg/coarray/event_4.f08
===
--- gcc/testsuite/gfortran.dg/coarray/event_4.f08 (nicht existent)
+++ gcc/testsuite/gfortran.dg/coarray/event_4.f08 (Arbeitskopie)
@@ -0,0 +1,12 @@
+! { dg-do run }
+!
+! Check that pr 70697 is fixed.
+
+program event_4
+ use iso_fortran_env
+ integer :: nc(1)
+ type(event_type) done[*]
+ nc(1) = 1
+ event post(done[1])
+ event wait(done,until_count=nc(1))
+end
Re: [PATCH, Fortran, pr70696, gcc-6, v1-3] [Coarray] ICE on EVENT POST of host-associated EVENT_TYPE coarray
Hi all,
just applied the backport to gcc-6 as promised as r245014.
Regards,
Andre
On Thu, 19 Jan 2017 16:53:14 +0100
Andre Vehreschild <ve...@gmx.de> wrote:
> Hi Steve,
>
> thanks for the review. Committed as r244637.
>
> Regards,
> Andre
>
> On Thu, 19 Jan 2017 06:51:19 -0800
> Steve Kargl <s...@troutmask.apl.washington.edu> wrote:
>
> > On Thu, Jan 19, 2017 at 01:07:50PM +0100, Andre Vehreschild wrote:
> > > Hi all,
> > >
> > > unfortunately triggered this patch a regression in the opencoarray's
> > > testsuite, which also occurs outside of opencoarray, when a caf-function
> > > is used in a block in the main-program. This patch fixes the error and
> > > adds a testcase.
> > >
> > > Bootstrapped and regtested ok on x86_64-linux/f25. Ok for trunk?
> > >
> >
> > Yes.
> >
>
>
--
Andre Vehreschild * Email: vehre ad gmx dot de
Index: gcc/fortran/ChangeLog
=======
--- gcc/fortran/ChangeLog (Revision 245013)
+++ gcc/fortran/ChangeLog (Arbeitskopie)
@@ -1,3 +1,13 @@
+2017-01-29 Andre Vehreschild <ve...@gcc.gnu.org>
+
+ Backport from trunk
+ PR fortran/70696
+ * trans-expr.c (gfc_get_tree_for_caf_expr): Ensure the backend_decl
+ is valid before accessing it. Remove unnecessary assert.
+ * trans-decl.c (gfc_build_qualified_array): Add static tokens to the
+ parent function's scope only, when the decl-context is not the
+ translation unit.
+
2017-01-17 Jakub Jelinek <ja...@redhat.com>
Backported from mainline
Index: gcc/fortran/trans-decl.c
===
--- gcc/fortran/trans-decl.c (Revision 245013)
+++ gcc/fortran/trans-decl.c (Arbeitskopie)
@@ -887,6 +887,10 @@
DECL_CONTEXT (token) = sym->ns->proc_name->backend_decl;
gfc_module_add_decl (cur_module, token);
}
+ else if (sym->attr.host_assoc
+ && TREE_CODE (DECL_CONTEXT (current_function_decl))
+ != TRANSLATION_UNIT_DECL)
+ gfc_add_decl_to_parent_function (token);
else
gfc_add_decl_to_function (token);
}
Index: gcc/fortran/trans-expr.c
===
--- gcc/fortran/trans-expr.c (Revision 245013)
+++ gcc/fortran/trans-expr.c (Arbeitskopie)
@@ -1898,8 +1898,11 @@
>where);
}
- caf_decl = expr->symtree->n.sym->backend_decl;
- gcc_assert (caf_decl);
+ /* Make sure the backend_decl is present before accessing it. */
+ caf_decl = expr->symtree->n.sym->backend_decl == NULL_TREE
+ ? gfc_get_symbol_decl (expr->symtree->n.sym)
+ : expr->symtree->n.sym->backend_decl;
+
if (expr->symtree->n.sym->ts.type == BT_CLASS)
caf_decl = gfc_class_data_get (caf_decl);
if (expr->symtree->n.sym->attr.codimension)
Index: gcc/testsuite/ChangeLog
=======
--- gcc/testsuite/ChangeLog (Revision 245013)
+++ gcc/testsuite/ChangeLog (Arbeitskopie)
@@ -1,3 +1,21 @@
+2017-01-29 Andre Vehreschild <ve...@gcc.gnu.org>
+
+ Backport from trunk
+ 2017-01-19 Andre Vehreschild <ve...@gcc.gnu.org>
+
+ PR fortran/70696
+ * gfortran.dg/coarray_43.f90: New test.
+
+ 2017-01-18 Andre Vehreschild <ve...@gcc.gnu.org>
+
+ PR fortran/70696
+ * gfortran.dg/coarray_event_1.f08: New test.
+
+ 2017-01-13 Andre Vehreschild <ve...@gcc.gnu.org>
+
+ PR fortran/70696
+ * gfortran.dg/coarray/event_3.f08: New test.
+
2017-01-28 John David Anglin <dang...@gcc.gnu.org>
PR testsuite/70583
Index: gcc/testsuite/gfortran.dg/coarray/event_3.f08
===
--- gcc/testsuite/gfortran.dg/coarray/event_3.f08 (nicht existent)
+++ gcc/testsuite/gfortran.dg/coarray/event_3.f08 (Arbeitskopie)
@@ -0,0 +1,20 @@
+! { dg-do run }
+!
+! Check PR fortran/70696 is fixed.
+
+program global_event
+ use iso_fortran_env , only : event_type
+ implicit none
+ type(event_type) :: x[*]
+
+ call exchange
+ contains
+subroutine exchange
+ integer :: cnt
+ event post(x[1])
+ event post(x[1])
+ call event_query(x, cnt)
+ if (cnt /= 2) error stop 1
+ event wait(x, until_count=2)
+end subroutine
+end
Index: gcc/testsuite/gfortran.dg/coarray_43.f90
===
--- gcc/testsuite/gfortran.dg/coarray_43.f90 (nicht existent)
+++ gcc/testsuite/gfortran.dg/coarray_43.f90 (Arbeitskopie)
@@ -0,0 +1,13 @@
+! { dg-do link }
+! { dg-options "-fcoarray=lib -lcaf_single" }
+
+program coarray_43
+ implicit none
+ integer, parameter :: STR_LEN = 50
+ character(len=STR_LEN) :: str[*]
+ integer :: pos
+ write(str,"(2(a,i2))") "Greetings from image &qu
