From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9439 invoked by alias); 3 Jul 2011 16:29:50 -0000 Received: (qmail 9430 invoked by uid 22791); 3 Jul 2011 16:29:49 -0000 X-SWARE-Spam-Status: No, hits=-2.7 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 03 Jul 2011 16:29:36 +0000 From: "burnus at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/40054] [F08] Pointer functions as lvalue X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: fortran X-Bugzilla-Keywords: rejects-valid X-Bugzilla-Severity: normal X-Bugzilla-Who: burnus at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Date: Sun, 03 Jul 2011 16:29:00 -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 X-SW-Source: 2011-07/txt/msg00142.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40054 --- Comment #10 from Tobias Burnus 2011-07-03 16:29:01 UTC --- (In reply to comment #7) > I think it will be very hard (if not impossible) to implement this, while > maintaining support for statement functions at the same time. In particular, > how is one supposed to interpret a statement like: > f (x) = x + 1 That depends on the context. The function "f(x)" is only a variable if "f" returns a pointer - and those functions are required to have an explicit interface (cf. "12.4.2.2 Explicit interface"). Thus, the ambiguity can only occur if one host-associates an explicit interface of "f". But the following makes clear how to interpret the program in that case (from "12.6.4 Statement function"): "The definition of a statement function with the same name as an accessible entity from the host shall be preceded by the declaration of its type in a type declaration statement." > In any case, statement functions are obsolescent since F95, so would it be an > option to not support them with -std=f2008? No. They are just obsolescent - not deleted: "Better methods existed in Fortran 90 and Fortran 95 for each obsolescent feature. It is recommended that programmers use these better methods in new programs and convert existing code to these methods. [...] A future revision of this part of ISO/IEC 1539 might delete an obsolescent feature if its use has become insignificant." (From "1.7.3 Nature of obsolescent features") Besides, with -std=gnu, we want to support both old and Fortran 2008 conform programs ...