From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 40735 invoked by alias); 11 Aug 2015 09:12:15 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 40676 invoked by uid 48); 11 Aug 2015 09:12:11 -0000 From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/67170] PRE can't hoist out a readonly argument Date: Tue, 11 Aug 2015 09:12:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: fortran X-Bugzilla-Version: 6.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status cf_reconfirmed_on everconfirmed Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-08/txt/msg00693.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67170 Richard Biener changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Last reconfirmed| |2015-08-11 Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- Ah. # USE = nonlocal escaped { D.3438 } # CLB = nonlocal escaped foo (&D.3438); As it clobbers nonlocal it clobbers the incoming argument :/ Because of course as the argument is pointing to possibly global memory it can access it via other means than through the argument - and the function attribute in use (".r") just means accesses through the first argument do not modify the contents pointed to. I think Fortran guarantees that things passed as argument are not modified in other ways (or it makes that undefined). Not sure about called functions though. Now. In principle I think C says that with void foo (int * __restrict p) { ... bar (); ... } bar () can only access *p through the use of p or a derived pointer. So int x; bar() { x = 1; } main() { foo (&x); } would invoke undefined behavior. Of course our restrict implementation isn't able to capture that (calls don't have a clique/base which they would get from the "memory" passed as reference arguments). So - confirmed. But no easy way out :( Old idea about special-casing recursive calls also exists but without clear idea of what would be legal special alias answers here.