From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16907 invoked by alias); 23 Mar 2015 12:44:05 -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 16888 invoked by uid 89); 23 Mar 2015 12:44:05 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: mout.gmx.net Received: from mout.gmx.net (HELO mout.gmx.net) (212.227.15.18) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Mon, 23 Mar 2015 12:44:03 +0000 Received: from vepi2 ([88.75.104.20]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0M5tU1-1ZP7832qs5-00xqPG; Mon, 23 Mar 2015 13:43:58 +0100 Date: Mon, 23 Mar 2015 12:44:00 -0000 From: Andre Vehreschild To: Mikael Morin Cc: GCC-Fortran-ML , GCC-Patches-ML , Antony Lewis Subject: Re: [Patch 1/2, Fortran, pr60322] [OOP] Incorrect bounds on polymorphic dummy array Message-ID: <20150323134357.6af740d1@vepi2> In-Reply-To: <551006FF.1080704@sfr.fr> References: <20150226181717.480e282c@vepi2> <551006FF.1080704@sfr.fr> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="MP_/VSkfCdMY6tCmIf6vyURKUA=" X-UI-Out-Filterresults: notjunk:1; X-SW-Source: 2015-03/txt/msg01180.txt.bz2 --MP_/VSkfCdMY6tCmIf6vyURKUA= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-length: 3145 Hi Mikael, thanks for looking at the patch. Please note, that Paul has sent an addendu= m to the patches for 60322, which I deliberately have attached. > 26/02/2015 18:17, Andre Vehreschild a =C3=A9crit : > > This first patch is only preparatory and does not change any of the > > semantics of gfortran at all. > Sure? With the counterexample you found below, this of course is a wrong statemen= t. =20 > > diff --git a/gcc/fortran/expr.c b/gcc/fortran/expr.c > > index ab6f7a5..d28cf77 100644 > > --- a/gcc/fortran/expr.c > > +++ b/gcc/fortran/expr.c > > @@ -4059,10 +4060,10 @@ gfc_lval_expr_from_sym (gfc_symbol *sym) > > lval->symtree =3D gfc_find_symtree (sym->ns->sym_root, sym->name); > >=20=20 > > /* It will always be a full array. */ > > - lval->rank =3D sym->as ? sym->as->rank : 0; > > + as =3D sym->as; > > + lval->rank =3D as ? as->rank : 0; > > if (lval->rank) > > - gfc_add_full_array_ref (lval, sym->ts.type =3D=3D BT_CLASS ? > > - CLASS_DATA (sym)->as : sym->as); > > + gfc_add_full_array_ref (lval, as); >=20 > This is a change of semantics. Or do you know that sym->ts.type !=3D > BT_CLASS? You are completely right. I have made a mistake here. I have to tell the tr= uth, I never ran a regtest with only part 1 of the patches applied. The second p= art of the patch will correct this, by setting the variable as depending on whe= ther type =3D=3D BT_CLASS or not. Sorry for the mistake. > > diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c > > index 3664824..e571a17 100644 > > --- a/gcc/fortran/trans-decl.c > > +++ b/gcc/fortran/trans-decl.c > > @@ -1013,16 +1017,24 @@ gfc_build_dummy_array_decl (gfc_symbol * sym, t= ree > > dummy) tree decl; > > tree type; > > gfc_array_spec *as; > > + symbol_attribute *array_attr; > > char *name; > > gfc_packed packed; > > int n; > > bool known_size; > >=20=20 > > - if (sym->attr.pointer || sym->attr.allocatable > > - || (sym->as && sym->as->type =3D=3D AS_ASSUMED_RANK)) > > + /* Use the array as and attr. */ > > + as =3D sym->as; > > + array_attr =3D &sym->attr; > > + > > + /* The pointer attribute is always set on a _data component, therefo= re > > check > > + the sym's attribute only. */ > > + if (sym->attr.pointer || array_attr->allocatable > > + || (as && as->type =3D=3D AS_ASSUMED_RANK)) > > return dummy; > >=20=20 > Any reason to sometimes use array_attr, sometimes not, like here? > By the way, the comment is misleading: for classes, there is the > class_pointer attribute (and it is a pain, I know). Yes, and a good one. Array_attr is sometimes sym->attr and sometimes CLASS_DATA(sym)->attr aka sym->ts.u.derived->components->attr. In the later case .pointer is always set to 1 in the _data component's attr. I.e., the a= bove if, would always yield true for a class_array, which is not intended, but r= ather destructive. I know about the class_pointer attribute, but I figured, that = it is not relevant here. Any idea how to formulate the comment better, to refl= ect what I just explained? Regards, Andre --=20 Andre Vehreschild * Email: vehre ad gmx dot de=20 --MP_/VSkfCdMY6tCmIf6vyURKUA= Content-Type: message/rfc822 Content-Transfer-Encoding: binary Content-Disposition: inline Content-length: 6533 X-Bogosity: Ham, spamicity=0.176106 Return-Path: paul.richard.thomas@gmail.com Received: from mail-wi0-f169.google.com ([209.85.212.169]) by mx-ha.gmx.net (mxgmx007) with ESMTPS (Nemesis) id 0Lgd6b-1ZKuyZ2dsL-00nvVW for ; Sun, 22 Mar 2015 21:25:50 +0100 Received: by mail-wi0-f169.google.com with SMTP id w10so23493434wix.0 for ; Sun, 22 Mar 2015 13:25:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=YiVsQfAxjj73IkMH5EQfWHyt+B+7XTT6uU+1d9Du608=; b=B3/mKhLXxqyKKcZPYIMRLQfPZIYiQcN0Tx+oy1e9M0IfG4fyne/N3IJescw4NiQk73 7I37wjukSOE7ijm6vSUPenbMoMJPVQH5ZMUQ6cnFJJtLsPQGgj0BxM1UQ7GtlW0UlhRi /FnsJ0Bsq+nWLOm6Wh0/OV+nCNhv3ZbHWQzjopodL7dp5yFpoGosB6QUBP0FQVb4HXyM F6jmiLqar29sOdAukJpPh6OiOc/DdMxhn5T5UdVMp15j4HrfQUJRiT77yqPMUVsfyKZP h1xuwxW5XpFPGFy/EgL1ISIuDAu9NFUjUChJzkd6H9cQP/8lZif7hwePMmBWkGqaJCVC 44ig== MIME-Version: 1.0 X-Received: by 10.180.126.69 with SMTP id mw5mr14007150wib.12.1427055620823; Sun, 22 Mar 2015 13:20:20 -0700 (PDT) Received: by 10.180.77.5 with HTTP; Sun, 22 Mar 2015 13:20:20 -0700 (PDT) Date: Sun, 22 Mar 2015 21:20:20 +0100 Message-ID: Subject: Bug in intrinsic LOC for scalar class objects From: Paul Richard Thomas To: Andre Vehreschild , Dominique Dhumieres Content-Type: multipart/mixed; boundary=e89a8f839f1b5ad20e0511e647e4 Envelope-To: X-GMX-Antispam: 0 (Mail was not recognized as spam); Detail=V3; X-GMX-Antivirus: 0 (no virus found) X-UI-Filterresults: notjunk:1;V01:K0:B5hSbShn4Bg=:MZQlz/WNl3Kr0Mn1rrLzauDOfG Sv0UBC1i55X46rQCJZpB3S7evyBi4FJWTPHYc7gE1KiGKU/K+/79sLrjfx1xQTzB9ekLIIBe5 vuif/40lheCNzRFAkYSgJOU4B3UDEO6tSjMqD9+7pLn4CKsb61GQP2N3SXPozERkUzDV7kjI8 WE/IQQqozA6ktM3XjEzmaxUiWSebYN+HOnn6v/1f9fhtld8xNtvcuBl+u8lU5BnY3LAIKrtwL Ao7OxVLUvtcZm2Y0NOuRAXkom819csSsvMqOmpehrAf/1Tim3g3WclUA533peQXC8Ku1Z9aS9 THiWkOFw/7apL9JP7CEnYN4jNBS0G8tunu26pZKC05SyEZeAK0EgUt5w0rQoqBFye/AturWWn lROUxEzAsDCG21Gfi3uPTrFbvBNNUjSnLnL2Pvfxi6f9/u3Gmv7JgUOSE8kRYLRduMFieKgBi qgzHqTNeUDKu0Ae/9qqjlKSVncuO0KYoD+1mBkyNH1ih6fFWhcx1E8Bus8Snm3bI4mOj3XXtb jXirrEORfG0Pv5dEUFVf8ccNloTrBtxsNUlZhHrAd/K+PmjNzlo14pZLdSK+ejUllpaFj1fs3 PcRT25xv2NtOYEkCuA/Agp5fC+gUwfJGASZKYa9o92L6ricUASER6luroVsRPKlqJmRYVAUHC ereWjUE4bsCyiQADeUI6DOsdIeKo3KNuG/eHoq6+Kd+04B5GPCH8RVNb00K53R6L9QhAbP8aa HaQ7tyWvl0b2pJOLlVQY5628w57T4kOdCP0tlCug97KWKngktAbhdh//BVbm4e38gkjW5sle5 u72YnHQSSSEJ8gyqBtA8MWRGKViqTVYZRIjrraUu0U+fLmP06yqZ2S/HfPxEyEEmIFL4xn60i 9+H6EEv+it8JLggAaQ37AOPqEh6QeantSghT8By7CyX7xz2Em+pkYVBme2NZ/WU7EtN5V5cwS LAsQmTfJssGPxMwtdaT/feIlDpgsvBCesVX8eR8uXsDxajd4IlGzt14XxtbtNKj9xS2XulG3y LRqhbrIOtkyeBSl3ckp7oedjnZ/qcCOGpOk46F5yRhEJJaZFZtiSeUh+Lk8O0YSj9rcHZq7k7 ByJy95LNXoKlZ9hHrGzksFxoxod/acWyjlN0KwS+eGctOs0Eymshxs09te4Vo89yC0lwo7LxK gnHCHgJ9k/AkmsR0EiasMHHvETvO3/2oW1sLhyn+f7eCQcyWNBGFw6Qy7sUUJzsdfxJaLaCJ0 E7uJIxFQnRUeFHqNmdO5FdRk/j2BBGQGqdUlNdR5gkxRaYkJDataYHcI= --e89a8f839f1b5ad20e0511e647e4 Content-Type: text/plain; charset=ISO-8859-1 Content-length: 1632 Dear Andre and Dominique, I have found that LOC is returning the address of the class container rather than the _data component for class scalars. See the source below, which you will recognise! A fix is attached. Note that the scalar allocate fails with MOLD= and so I substituted SOURCE=. Cheers Paul class(*), allocatable :: a(:), e ! Change 'e' to an array and second memcpy works correctly ! Problem is with loc(e), which returns the address of the ! class container. allocate (e, source = 99.0) allocate (a(2), source = [1.0, 2.0]) call add_element_poly (a,e) select type (a) type is (real) print *, a end select contains subroutine add_element_poly(a,e) use iso_c_binding class(*),allocatable,intent(inout),target :: a(:) class(*),intent(in),target :: e class(*),allocatable,target :: tmp(:) type(c_ptr) :: dummy interface function memcpy(dest,src,n) bind(C,name="memcpy") result(res) import type(c_ptr) :: res integer(c_intptr_t),value :: dest integer(c_intptr_t),value :: src integer(c_size_t),value :: n end function end interface if (.not.allocated(a)) then allocate(a(1), source=e) else allocate(tmp(size(a)),source=a) deallocate(a) allocate(a(size(tmp)+1),source=e) ! mold gives a segfault dummy = memcpy(loc(a(1)),loc(tmp),sizeof(tmp)) dummy = memcpy(loc(a(size(tmp)+1)),loc(e),sizeof(e)) end if end subroutine end --e89a8f839f1b5ad20e0511e647e4 Content-Type: text/plain; charset=US-ASCII; name="loc_patch.diff" Content-Disposition: attachment; filename="loc_patch.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_i7kw2fof0 Content-length: 1416 SW5kZXg6IGdjYy9mb3J0cmFuL3RyYW5zLWludHJpbnNpYy5jCj09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT0KKioqIGdjYy9mb3J0cmFuL3RyYW5zLWludHJpbnNp Yy5jCShyZXZpc2lvbiAyMjE1MDApCi0tLSBnY2MvZm9ydHJhbi90cmFucy1p bnRyaW5zaWMuYwkod29ya2luZyBjb3B5KQoqKioqKioqKioqKioqKiogZ2Zj X2NvbnZfaW50cmluc2ljX2xvYyAoZ2ZjX3NlICogc2UsIGdmYwoqKiogNzA4 MCw3MDg2ICoqKioKCiAgICBhcmdfZXhwciA9IGV4cHItPnZhbHVlLmZ1bmN0 aW9uLmFjdHVhbC0+ZXhwcjsKICAgIGlmIChhcmdfZXhwci0+cmFuayA9PSAw KQohICAgICBnZmNfY29udl9leHByX3JlZmVyZW5jZSAoc2UsIGFyZ19leHBy KTsKICAgIGVsc2UKICAgICAgZ2ZjX2NvbnZfYXJyYXlfcGFyYW1ldGVyIChz ZSwgYXJnX2V4cHIsIHRydWUsIE5VTEwsIE5VTEwsIE5VTEwpOwogICAgc2Ut PmV4cHIgPSBjb252ZXJ0IChnZmNfZ2V0X2ludF90eXBlIChnZmNfaW5kZXhf aW50ZWdlcl9raW5kKSwgc2UtPmV4cHIpOwotLS0gNzA4MCw3MDkxIC0tLS0K CiAgICBhcmdfZXhwciA9IGV4cHItPnZhbHVlLmZ1bmN0aW9uLmFjdHVhbC0+ ZXhwcjsKICAgIGlmIChhcmdfZXhwci0+cmFuayA9PSAwKQohICAgICB7CiEg ICAgICAgaWYgKGFyZ19leHByLT5zeW10cmVlLT5uLnN5bS0+dHMudHlwZSA9 PSBCVF9DTEFTUwohIAkgICYmICFDTEFTU19EQVRBIChhcmdfZXhwci0+c3lt dHJlZS0+bi5zeW0pLT5hcykKISAJZ2ZjX2FkZF9jb21wb25lbnRfcmVmIChh cmdfZXhwciwgIl9kYXRhIik7CiEgICAgICAgZ2ZjX2NvbnZfZXhwcl9yZWZl cmVuY2UgKHNlLCBhcmdfZXhwcik7CiEgICAgIH0KICAgIGVsc2UKICAgICAg Z2ZjX2NvbnZfYXJyYXlfcGFyYW1ldGVyIChzZSwgYXJnX2V4cHIsIHRydWUs IE5VTEwsIE5VTEwsIE5VTEwpOwogICAgc2UtPmV4cHIgPSBjb252ZXJ0IChn ZmNfZ2V0X2ludF90eXBlIChnZmNfaW5kZXhfaW50ZWdlcl9raW5kKSwgc2Ut PmV4cHIpOwo= --e89a8f839f1b5ad20e0511e647e4-- --MP_/VSkfCdMY6tCmIf6vyURKUA=--