From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18942 invoked by alias); 8 Sep 2014 22:13:11 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 18905 invoked by uid 89); 8 Sep 2014 22:13:07 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KAM_STOCKGEN,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=no version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: mail-lb0-f170.google.com Received: from mail-lb0-f170.google.com (HELO mail-lb0-f170.google.com) (209.85.217.170) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Mon, 08 Sep 2014 22:13:05 +0000 Received: by mail-lb0-f170.google.com with SMTP id u10so1290973lbd.29 for ; Mon, 08 Sep 2014 15:13:01 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.112.172.38 with SMTP id az6mr29834574lbc.53.1410214381271; Mon, 08 Sep 2014 15:13:01 -0700 (PDT) Received: by 10.112.181.138 with HTTP; Mon, 8 Sep 2014 15:13:01 -0700 (PDT) In-Reply-To: <540E2489.2030403@net-b.de> References: <540E2489.2030403@net-b.de> Date: Mon, 08 Sep 2014 22:13:00 -0000 Message-ID: Subject: Re: [PATCH, Fortran] From: Alessandro Fanfarillo To: Tobias Burnus Cc: gcc-patches , gfortran Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2014-09/txt/msg00644.txt.bz2 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 : > 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 =3D this_image() > call atomic_define(atom[1],0) > sync all > call ATOMIC_ADD (atom[1], me) > if(me =3D=3D 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=3D4) value.3; > > value.3 =3D (integer(kind=3D4)) &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 =3D 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 =E2=80=93 as it shouldn't trigger when bot= h 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 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > *** 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 =3D integer_zero_node; > > - if (TREE_TYPE (TREE_TYPE (atom)) !=3D TREE_TYPE (TREE_TYPE (value= ))) > - { > - tmp =3D gfc_create_var (TREE_TYPE (TREE_TYPE (atom)), "value"); > - gfc_add_modify (&block, tmp, fold_convert (TREE_TYPE (tmp), value)); > - value =3D gfc_build_addr_expr (NULL_TREE, tmp); > - } > - > gfc_get_caf_token_offset (&token, &offset, caf_decl, atom, > atom_expr); > > if (code->resolved_isym->id =3D=3D GFC_ISYM_ATOMIC_DEF) > --- 8396,8401 ----