From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4848 invoked by alias); 29 Apr 2013 12:40:55 -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 4802 invoked by uid 48); 29 Apr 2013 12:40:52 -0000 From: "burnus at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/39290] Subroutine/function ambiguity in generics Date: Mon, 29 Apr 2013 12:40: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-Keywords: accepts-invalid 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" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-SW-Source: 2013-04/txt/msg02333.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D39290 --- Comment #9 from Tobias Burnus 2013-04-29 12= :40:50 UTC --- (In reply to comment #8) > There are a quite a few problems it seems: > 1. we rely on s1->attr.function _and_ s2->attr.function being set, which= is > obviously not the case with implicit typing. I think the simplest fix is to do the following: If (dummy->attr.function && actual_argument->attr.external && !actual_argument->attr.subroutine) Implicitly-type-the-actual-argument; The Fortran standard requires that all external procedures which are used as actual argument have the "external" attribute. (To distinguish them from variables.) And "12.4.3.4.5 Restrictions on generic declarations" ensures that either a subroutine or a function but never both is used for a given argument: "Two dummy arguments are distinguishable if *=0F one is a procedure and the other is a data object, *=0F they are both data objects or known to be functions, and neither is TKR compatible with the other, * one is a function with nonzero rank and the other is not known to be a function. [...]" One just has to ensure that external :: sub call foo(sub) doesn't get the function attribute and typed when first checking "one" for a possible match: interface foo subrouine one(f,y) real, external :: f integer :: y end subroutine two(s) external :: s end end interface BTW: When updating this, one can also implement the new Fortran 2008 featur= e: "ALLOCATABLE and POINTER attributes are used in generic resolution. Procedureness of a dummy argument is used in generic resolution." (I think = the first one is already implemented.) -> F2008, 12.4.3.4.5 >>From gcc-bugs-return-421189-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Apr 29 12:44:34 2013 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 7169 invoked by alias); 29 Apr 2013 12:44:34 -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 Delivered-To: mailing list gcc-bugs@gcc.gnu.org Received: (qmail 7133 invoked by uid 48); 29 Apr 2013 12:44:31 -0000 From: "glisse at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/57112] New: -march=x86-64 not documented Date: Mon, 29 Apr 2013 12:44:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Keywords: documentation X-Bugzilla-Severity: normal X-Bugzilla-Who: glisse at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 X-SW-Source: 2013-04/txt/msg02334.txt.bz2 Content-length: 776 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57112 Bug #: 57112 Summary: -march=x86-64 not documented Classification: Unclassified Product: gcc Version: 4.9.0 Status: UNCONFIRMED Keywords: documentation Severity: normal Priority: P3 Component: target AssignedTo: unassigned@gcc.gnu.org ReportedBy: glisse@gcc.gnu.org Target: x86_64-linux-gnu Hello, for people who have a gcc that was configured with some non-default --with-arch but who want to build a generic binary, an option like -march=generic would be useful. It seems that the right spelling is -march=x86-64, but I couldn't find that documented in invoke.texi.