From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 50637 invoked by alias); 20 Nov 2019 22:19:56 -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 50623 invoked by uid 89); 20 Nov 2019 22:19:56 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 spammy=H*MI:sk:4e68f25, HContent-Transfer-Encoding:8bit X-HELO: mx-relay06-hz2.antispameurope.com Received: from mx-relay06-hz2.antispameurope.com (HELO mx-relay06-hz2.antispameurope.com) (83.246.65.92) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 20 Nov 2019 22:19:54 +0000 Return-Path: Received: from s041.bre.qsc.de ([195.90.7.81]) by mx-relay06-hz2.antispameurope.com; Wed, 20 Nov 2019 23:19:51 +0100 Received: from localhost.localdomain (port-92-195-226-14.dynamic.qsc.de [92.195.226.14]) by s041.bre.qsc.de (Postfix) with ESMTPSA id 9CABF2C005A; Wed, 20 Nov 2019 23:19:50 +0100 (CET) Subject: Re: [patch, fortran] Load scalar intent-in variables at the beginning of procedures To: =?UTF-8?Q?Thomas_K=c3=b6nig?= , Janne Blomqvist , Thomas Koenig Cc: Tobias Burnus , "fortran@gcc.gnu.org" , gcc-patches References: <48286910-ebbb-10e4-488b-8c96e505375c@tkoenig.net> <43b9fcf0-f457-90a7-c807-4aebc65cb045@tkoenig.net> <2981fd67-007e-7327-8208-27e8fd18d9db@netcologne.de> <4e68f250-1e41-ac7c-dc64-88f91cdf183e@tkoenig.net> From: Tobias Burnus Message-ID: <94da433a-f9e3-8fb7-ea59-c1f798e4e0fb@net-b.de> Date: Wed, 20 Nov 2019 22:30:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.1 MIME-Version: 1.0 In-Reply-To: <4e68f250-1e41-ac7c-dc64-88f91cdf183e@tkoenig.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-cloud-security-sender:burnus@net-b.de X-cloud-security-recipient:gcc-patches@gcc.gnu.org X-cloud-security-Virusscan:CLEAN X-cloud-security-disclaimer: This E-Mail was scanned by E-Mailservice on mx-relay06-hz2.antispameurope.com with 299F0265720 X-cloud-security-connect: s041.bre.qsc.de[195.90.7.81], TLS=1, IP=195.90.7.81 X-cloud-security:scantime:.1996 X-SW-Source: 2019-11/txt/msg02042.txt.bz2 On 11/20/19 10:35 PM, Thomas König wrote: > I haven't run any actual benchmarks. I think it would be interesting – I think there can be quite some advantages in some cases, while in most cases, it is not really noticable. > Of course, Fortran language rules specify that the call to bar cannot > do anything to n, but apparently we do not tell the gcc middle end > that this is the case, or maybe that there is no way to really specify > this. To my knowledge, the ME does not support the Fortran semantics but assumes that once a pointer escapes in one procedure call, any other procedure might have access to it and modify it as well. This matches (effectively) the Fortran semantics of asynchronous. See also PR 49733. The only thing we can do currently is to specify the intent via 'fn spec' which helps a bit – but not if the pointer has already escaped. Maybe we should think again about handling this properly in the ME. Cheers, Tobias