From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10075 invoked by alias); 21 Jul 2010 16:58:23 -0000 Received: (qmail 9801 invoked by uid 48); 21 Jul 2010 16:57:47 -0000 Date: Wed, 21 Jul 2010 16:58:00 -0000 Message-ID: <20100721165747.9800.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug fortran/45019] Aliasing of TARGET dummy argument not detected correctly In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "burnus at gcc dot gnu dot org" 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 X-SW-Source: 2010-07/txt/msg02237.txt.bz2 ------- Comment #4 from burnus at gcc dot gnu dot org 2010-07-21 16:57 ------- (In reply to comment #3) > Actually, I wonder whether this is really testable: > "the actual argument is a target" > thus, one probably needs to use: The other question is how to deal with the "restrict" middle-end attribute - currently "arr" is restrict, i.e. the middle end might do certain optimizations. I do not see how one can prevent this. Thus: Is the program in comment 3 indeed valid? If yes, do we need to do something in terms of "restrict" - and what? For instance: arr(1) = 5 arg(1) = 6 if (arg(1) /= 6) call abort() In this case, the middle end could optimize the condition way as "arr" is a restricted pointer and thus it cannot alias with "arg" (which is not restricted). Thus, I would like to declare the program as invalid. Is there anything in the standard which makes this invalid? On place to look for is the "CALL bar(arr)" as here "arr" is not yet a target; the question is whether this propagates through to foobar, making the program invalid. Maybe that's indeed a question for either the j3 mailing list or for c.l.f. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45019