This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH, Fortran]
- From: Alessandro Fanfarillo <fanfarillo dot gcc at gmail dot com>
- To: Tobias Burnus <burnus at net-b dot de>
- Cc: gcc-patches <gcc-patches at gcc dot gnu dot org>, gfortran <fortran at gcc dot gnu dot org>
- Date: Mon, 8 Sep 2014 16:13:01 -0600
- Subject: Re: [PATCH, Fortran]
- Authentication-results: sourceware.org; auth=none
- References: <CAHqFgjWSY72Dy6mQVj=Ni7ng560xNc+UyDt-b4d9cdyAi9XEKA at mail dot gmail dot com> <540E2489 dot 2030403 at net-b dot de>
Thanks, your suggestion fixes the problem.
I just noticed that I missed the subject description; I'll send the
new patch in a different email.
2014-09-08 15:50 GMT-06:00 Tobias Burnus <burnus@net-b.de>:
> Alessandro Fanfarillo wrote:
>
> the following code produces a wrong invocation to libcaf for
> caf_atomic_op (atomic_add):
>
> program atomic
> use iso_fortran_env
> implicit none
>
> integer :: me
> integer(atomic_int_kind) :: atom[*]
> me = this_image()
> call atomic_define(atom[1],0)
> sync all
> call ATOMIC_ADD (atom[1], me)
> if(me == 1) call atomic_ref(me,atom[1])
> sync all
> write(*,*) me
>
> end program
>
> The compiler translates the caf_atomic_op call (related with atomic_add) as:
>
> integer(kind=4) value.3;
>
> value.3 = (integer(kind=4)) &me;
> _gfortran_caf_atomic_op (1, caf_token.0, 0, 1, &value.3, 0B, 0B, 1, 4);
>
> The attached patch seems to fix the problem.
>
>
> But I think it doesn't do the right thing if the kind is different.
>
> Suggestions?
>
>
> I think you want to do something like inserting
>
> if (POINTER_TYPE_P (TREE_TYPE (value))
> value = build_fold_indirect_ref_loc (input_location, value);
>
> before the assignment:
>
> gfc_add_modify (&block, tmp, fold_convert (TREE_TYPE (tmp), value));
>
> otherwise you risk that you access invalid memory, e.g. for passing a
> integer(1) variable to an integer(4) atomic. On the other hand, there is
> something wrong with the check â as it shouldn't trigger when both atom and
> value have the same kind. Thus, the modified patch might work, is probably
> not completely clean either.
>
> Tobias
>
> Index: gcc/fortran/trans-intrinsic.c
> ===================================================================
> *** gcc/fortran/trans-intrinsic.c (revision 215016)
> --- gcc/fortran/trans-intrinsic.c (working copy)
> *************** conv_intrinsic_atomic_op (gfc_code *code
> *** 8396,8408 ****
> else
> image_index = integer_zero_node;
>
> - if (TREE_TYPE (TREE_TYPE (atom)) != TREE_TYPE (TREE_TYPE (value)))
> - {
> - tmp = gfc_create_var (TREE_TYPE (TREE_TYPE (atom)), "value");
> - gfc_add_modify (&block, tmp, fold_convert (TREE_TYPE (tmp), value));
> - value = gfc_build_addr_expr (NULL_TREE, tmp);
> - }
> -
> gfc_get_caf_token_offset (&token, &offset, caf_decl, atom,
> atom_expr);
>
> if (code->resolved_isym->id == GFC_ISYM_ATOMIC_DEF)
> --- 8396,8401 ----