From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 112570 invoked by alias); 28 Dec 2017 14:20:32 -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 112546 invoked by uid 89); 28 Dec 2017 14:20:31 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=3.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,KAM_NUMSUBJECT,KAM_SHORT,RCVD_IN_DNSWL_LOW,SPAM_BODY,SPF_PASS autolearn=no version=3.3.2 spammy=H*f:sk:90955e7, vehreschild, Vehreschild, referencing X-Spam-User: qpsmtpd, 2 recipients X-HELO: mout.gmx.net Received: from mout.gmx.net (HELO mout.gmx.net) (212.227.17.22) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 28 Dec 2017 14:20:30 +0000 Received: from vepi2 ([92.76.207.44]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0Lm7MT-1f3tmb2Hon-00Zh4f; Thu, 28 Dec 2017 15:19:36 +0100 Date: Thu, 28 Dec 2017 14:20:00 -0000 From: Andre Vehreschild To: Paul Richard Thomas Cc: Damian Rouson , Thomas Koenig , Dominique =?UTF-8?B?ZCdIdW1pw6hyZXM=?= , gfortran , gcc-patches , Izaak Zaak Beekman Subject: Re: [Patch, fortran] PR83076 - [8 Regression] ICE in gfc_deallocate_scalar_with_status, at fortran/trans.c:1598 Message-ID: <20171228151934.59df3a6a@vepi2> In-Reply-To: References: <2DA8CC84-7A96-4219-A0F1-E8C3C227D15E@lps.ens.fr> <90955e7a-f7f4-0bb6-d3b0-cc4f1f9a876b@netcologne.de> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-UI-Out-Filterresults: notjunk:1;V01:K0:kf313Rs3DlU=:7wfPu9dq3YMV6jMjmxbw/R uHzv8A+2RqqWNIziXjPEprzXrIdEfTI5OxZ4/qpGb2Uh+QtX/s+2lXWx0snmHz0ibePCUPha+ wwjAFqakg0u7qg+J+8vnhThPKLgNF7bGGyAcOJf/rhABfmzE1K844K0YN/CltXtbYOiR6A7Yz 3/w33jvei7cqQV6WCcTLQK6ulE93Q6KhYwcTh2oDP5IKOQ7fENaqH5YtutzVhIyO24p/I7y8S aZUtEyBMeh0WZo2gKs+gLT9TtfXima1V1JeqW9WQRolm1zZSCIjtarbQTMIfodVP7mCqivm9U INXAd9Vr/b3PFYIaAHGDGXl5j60q4j7ZxE6HZjZOceJasDb6eVBQWlZcnbILlVti7GwRazFIU oFKowF5Kw6Nfs/ObeRA5qCiqUdtK30EJrmGnWtmKsQwxPgwoqCXJI4d8VCb9p36250iQ4tEda 8AzlbeR5aBn8AtblaOD6XJYiz7Wa2ky63cyyi2uWY8PV8gnEmiNVe+1ls6Cq0UhNQ0mniIcfs VGwCMeEAmbHGDRfHygR6akZYKq+0I4kSQK4g85Cp0ZPpwOGEowi/0hXvI6msnMTVABcwTWTO+ UIWYqHzIOiImyFpKWWM6hD1w2rqbOHxycREC2abSOdIfiBmCocNjcXuYGZ7RM5ciQzL4fhRFl mwHTls5/87N7bWea/UQ9WhImUuWNstFwpTF326MVDzWUL9wK3BoInhsmrP0u/CgcaB1DG+4kn jWaesNDVt638OpTfz+ZjzxNdR2A41WDWM2Vp8/r8rISHwfbZ9hb3mQpFPhWjKp53z7Q0AxDWG sZgM6BgN0fi6p22xseCNvXKSXOirUWe3XYJIsSSPvuMemrCefE= X-SW-Source: 2017-12/txt/msg01561.txt.bz2 Hi all, as long as the computation where the token can be found is adapted in the s= ame way, i.e. the token's offset in the derived type monitors the changed posit= ion, 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 +0000 Paul Richard Thomas wrote: > Hi All, >=20 > OK - I'll hold back until I hear from Damian & Zaak. >=20 > Cheers >=20 > Paul >=20 > On 27 December 2017 at 21:06, Damian Rouson > wrote: > > > > Thanks for the additional information Thomas. It sounds like I should t= est > > Paul=E2=80=99s patch. I should be able to do so today and will post the= results by > > tomorrow. I=E2=80=99m 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 > > (tkoenig@netcologne.de(mailto:tkoenig@netcologne.de)) wrote:=20 > >> Hi Damian, > >>=20=20 > >> > Does breaking binary compatibility simply mean that CAF codes will n= eed > >> > to be recompiled (which is fine)=20=20 > >> > >> 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. > >>=20=20 > >> > or does it mean that there will need to be work done on OpenCoarrays= =20=20 > >> to support the changes > >> > >> This, I don't know, never having looked at the OpenCoarrays source. > >> > >> Regards > >> > >> Thomas=20=20 >=20 >=20 >=20 --=20 Andre Vehreschild * Email: vehre ad gmx dot de=20