From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-434171-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 11427 invoked by alias); 10 Nov 2013 18:23:02 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Received: (qmail 11323 invoked by uid 48); 10 Nov 2013 18:22:59 -0000
From: "Joost.VandeVondele at mat dot ethz.ch" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/38318] moving the allocation of temps out of loops.
Date: Sun, 10 Nov 2013 18:23:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 4.4.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: Joost.VandeVondele at mat dot ethz.ch
X-Bugzilla-Status: NEW
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:
Message-ID: <bug-38318-4-LaRlOAkzuN@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-38318-4@http.gcc.gnu.org/bugzilla/>
References: <bug-38318-4@http.gcc.gnu.org/bugzilla/>
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: 2013-11/txt/msg00948.txt.bz2

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38318

--- Comment #10 from Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> ---
(In reply to Marc Glisse from comment #9)

> 
> Ok. If you used __builtin_abort instead of _gfortran_os_error, I think my
> current patch would handle it. It is hard for gcc to guess that
> _gfortran_os_error is safe. 

For the Fortran FE people (not me, I'm a user), but  _gfortran_os_error should
have an attribute like 'abort' or 'noreturn'. However, the compiler should also
be able to figure out this can never be called (if B is 'allocated on the
stack') in this subroutine.

> Er, no, I missed the call to s2. I would also need some attribute on s2 so
> the compiler knows that s2 doesn't do anything too weird. 

Actually, in Fortran, S2 can't do anything 'weird' with B, in the sense that
your optimization should certainly apply. Not so sure about the correct terms
here, but in approximate C-speak, B 'as a pointer' is guaranteed to be pointing
to exactly the same address, nothing has happened to its target, and no pointer
can be pointing to whatever B was pointing to....