public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/39290] New: Subroutine/function ambiguity in generics
@ 2009-02-24 14:35 burnus at gcc dot gnu dot org
2009-02-26 12:27 ` [Bug fortran/39290] " pault at gcc dot gnu dot org
0 siblings, 1 reply; 12+ messages in thread
From: burnus at gcc dot gnu dot org @ 2009-02-24 14:35 UTC (permalink / raw)
To: gcc-bugs
http://www.j3-fortran.org/doc/year/09/09-155.txt
NUMBER: F03/0071
DEFECT TYPE: Erratum
STATUS: Passed by J3 meeting
(Note: no final J3/WG5 voting yet)
The following program is accepted by gfortran, but the conclusion of the J3
meeting was "The program fragment is not conforming."
-------------------
interface q
subroutine qr(f)
implicit real(f)
external f
end subroutine
subroutine qc(f)
implicit complex(f)
external f
end subroutine
end interface q
-------------------
--
Summary: Subroutine/function ambiguity in generics
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39290
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug fortran/39290] Subroutine/function ambiguity in generics
2009-02-24 14:35 [Bug fortran/39290] New: Subroutine/function ambiguity in generics burnus at gcc dot gnu dot org
@ 2009-02-26 12:27 ` pault at gcc dot gnu dot org
0 siblings, 0 replies; 12+ messages in thread
From: pault at gcc dot gnu dot org @ 2009-02-26 12:27 UTC (permalink / raw)
To: gcc-bugs
------- Comment #1 from pault at gcc dot gnu dot org 2009-02-26 12:27 -------
This is the same as PR20896, isn't it? Maybe I should pick that up once
more....
Paul
--
pault at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|0000-00-00 00:00:00 |2009-02-26 12:27:19
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39290
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug fortran/39290] Subroutine/function ambiguity in generics
[not found] <bug-39290-4@http.gcc.gnu.org/bugzilla/>
` (8 preceding siblings ...)
2013-04-29 14:53 ` janus at gcc dot gnu.org
@ 2013-07-16 6:17 ` burnus at gcc dot gnu.org
9 siblings, 0 replies; 12+ messages in thread
From: burnus at gcc dot gnu.org @ 2013-07-16 6:17 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39290
--- Comment #11 from Tobias Burnus <burnus at gcc dot gnu.org> ---
See also PR 20896 - and the test case at
http://gcc.gnu.org/ml/fortran/2013-07/msg00017.html
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug fortran/39290] Subroutine/function ambiguity in generics
[not found] <bug-39290-4@http.gcc.gnu.org/bugzilla/>
` (7 preceding siblings ...)
2013-04-29 12:40 ` burnus at gcc dot gnu.org
@ 2013-04-29 14:53 ` janus at gcc dot gnu.org
2013-07-16 6:17 ` burnus at gcc dot gnu.org
9 siblings, 0 replies; 12+ messages in thread
From: janus at gcc dot gnu.org @ 2013-04-29 14:53 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39290
--- Comment #10 from janus at gcc dot gnu.org 2013-04-29 14:53:03 UTC ---
(In reply to comment #9)
> BTW: When updating this, one can also implement the new Fortran 2008 feature:
> "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
cf. PR 45521
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug fortran/39290] Subroutine/function ambiguity in generics
[not found] <bug-39290-4@http.gcc.gnu.org/bugzilla/>
` (6 preceding siblings ...)
2013-04-29 10:59 ` mikael at gcc dot gnu.org
@ 2013-04-29 12:40 ` burnus at gcc dot gnu.org
2013-04-29 14:53 ` janus at gcc dot gnu.org
2013-07-16 6:17 ` burnus at gcc dot gnu.org
9 siblings, 0 replies; 12+ messages in thread
From: burnus at gcc dot gnu.org @ 2013-04-29 12:40 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39290
--- Comment #9 from Tobias Burnus <burnus at gcc dot gnu.org> 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
*\x0f one is a procedure and the other is a data object,
*\x0f 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 feature:
"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: <gcc-bugs-return-421189-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
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: <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
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" <gcc-bugzilla@gcc.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: <bug-57112-4@http.gcc.gnu.org/bugzilla/>
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?idW112
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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug fortran/39290] Subroutine/function ambiguity in generics
[not found] <bug-39290-4@http.gcc.gnu.org/bugzilla/>
` (5 preceding siblings ...)
2013-04-29 9:31 ` burnus at gcc dot gnu.org
@ 2013-04-29 10:59 ` mikael at gcc dot gnu.org
2013-04-29 12:40 ` burnus at gcc dot gnu.org
` (2 subsequent siblings)
9 siblings, 0 replies; 12+ messages in thread
From: mikael at gcc dot gnu.org @ 2013-04-29 10:59 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39290
--- Comment #8 from Mikael Morin <mikael at gcc dot gnu.org> 2013-04-29 10:59:51 UTC ---
The following excerpt from gfc_compare_interfaces(interface.c) seems to be the
cause of 'qc' being called:
if (s1->attr.function && s2->attr.function)
{
/* If both are functions, check result characteristics. */
if (!check_result_characteristics (s1, s2, errmsg, err_len))
return 0;
}
s2 is 'ff', and s2->attr.function is false, so we don't check function results,
and the 'qc' interface matches.
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.
2. check_result_characteristics will call gfc_compare_types, so it needs
properly set types (no BT_UNKNOWN).
3. gfc_search_interface returns the first match, so it doesn't detect multiple
matches (which would reject this case and avoid generating wrong code here).
4. Implicit typing depends on how the symbol is used, so basically on the
available interfaces, but that itself needs implicit typing being resolved (see
1. and 2.)
Good luck to whoever wants to fix this.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug fortran/39290] Subroutine/function ambiguity in generics
[not found] <bug-39290-4@http.gcc.gnu.org/bugzilla/>
` (4 preceding siblings ...)
2013-04-28 18:35 ` janus at gcc dot gnu.org
@ 2013-04-29 9:31 ` burnus at gcc dot gnu.org
2013-04-29 10:59 ` mikael at gcc dot gnu.org
` (3 subsequent siblings)
9 siblings, 0 replies; 12+ messages in thread
From: burnus at gcc dot gnu.org @ 2013-04-29 9:31 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39290
Tobias Burnus <burnus at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |burnus at gcc dot gnu.org
--- Comment #7 from Tobias Burnus <burnus at gcc dot gnu.org> 2013-04-29 09:31:53 UTC ---
(In reply to comment #6)
> external ff, cc
> call q(ff)
>
> I absolutely *never* use implicit declarations, therefore I'm not sure: Is an
> "external ff" declaration supposed to get implicitly typed as real in comment
> 4?
The program is *valid*; as "ff" is referenced as function, it has to be
implicitly typed, which is "real" according to the implicit typing rules.
I concur that the standard does not very explicitly state this. But the
question (and example of comment 4) exactly matches the interpretation request
F03/0071 (cf. comment 0). J3/WG5 answered it
http://www.j3-fortran.org/doc/standing/links/016.txt - to quote from the answer
to Q2:
"2. The main program program unit is conforming, although the program
would not be if the external procedure FF were not in fact a real
function. If the reference had been to QR instead of Q, it would
be clear that FF has to be a real function, from the point of view
of the main program scoping unit. At the call site, the reference
to Q is known to be a reference either to QR or QC (the interface
block for Q is not defective), both of which require a function
actual argument. FF is known to be either a subroutine or a
function, since it explicitly has the EXTERNAL attribute, and if
it is a function it is known by implicit typing rules to be real.
Because neither specific in the generic allows a subroutine as an
argument, FF must therefore be a function. Since FF is real, QR
is called. (The generic cannot have a specific that accepts a
subroutine as an argument, as that would violate the requirements
in 16.2.3.)"
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug fortran/39290] Subroutine/function ambiguity in generics
[not found] <bug-39290-4@http.gcc.gnu.org/bugzilla/>
` (3 preceding siblings ...)
2012-08-18 22:00 ` mikael at gcc dot gnu.org
@ 2013-04-28 18:35 ` janus at gcc dot gnu.org
2013-04-29 9:31 ` burnus at gcc dot gnu.org
` (4 subsequent siblings)
9 siblings, 0 replies; 12+ messages in thread
From: janus at gcc dot gnu.org @ 2013-04-28 18:35 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39290
janus at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |janus at gcc dot gnu.org
--- Comment #6 from janus at gcc dot gnu.org 2013-04-28 18:35:43 UTC ---
(In reply to comment #4)
> Actually, the valid test doesn't work as `qc' instead of `qr' is called in the
> first call.
It *does* work if one explicitly declares 'ff' as real (and fixes the
implementation of 'cc' to be complex):
function ff()
ff = 4
end function ff
complex function cc()
cc = (5,6)
end function cc
subroutine qr(f)
real, external :: f
complex c
common /a/ r, c
r = f()
end subroutine
subroutine qc(f)
complex, external :: f
complex c
common /a/ r, c
c = f()
end subroutine
module m
interface q
subroutine qr(f)
real, external :: f
end subroutine
subroutine qc(f)
complex, external :: f
end subroutine
end interface q
end module m
program main
use m
external ff, cc
complex cc, c
real ff
common /a/ r, c
r = 1
c = (2, 3)
call q(ff)
!print *, r, c
if (r /= 4 ) call abort
!print *, c
if (c /= (2,3)) call abort
call q(cc)
!print *, r
if (r /= 4 ) call abort
!print *, c
if (c /= (5,6)) call abort
end
I absolutely *never* use implicit declarations, therefore I'm not sure: Is an
"external ff" declaration supposed to get implicitly typed as real in comment
4? If yes, then it's apparently a bug that we don't do this ...
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug fortran/39290] Subroutine/function ambiguity in generics
[not found] <bug-39290-4@http.gcc.gnu.org/bugzilla/>
` (2 preceding siblings ...)
2012-08-18 21:56 ` mikael at gcc dot gnu.org
@ 2012-08-18 22:00 ` mikael at gcc dot gnu.org
2013-04-28 18:35 ` janus at gcc dot gnu.org
` (5 subsequent siblings)
9 siblings, 0 replies; 12+ messages in thread
From: mikael at gcc dot gnu.org @ 2012-08-18 22:00 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39290
--- Comment #5 from Mikael Morin <mikael at gcc dot gnu.org> 2012-08-18 22:00:20 UTC ---
Author: mikael
Date: Sat Aug 18 22:00:10 2012
New Revision: 190504
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190504
Log:
Add the working testcase from PR fortran/39290.
testsuite/
PR fortran/39290
* gfortran.dg/interface_37.f90: New test.
Added:
trunk/gcc/testsuite/gfortran.dg/interface_37.f90
Modified:
trunk/gcc/testsuite/ChangeLog
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug fortran/39290] Subroutine/function ambiguity in generics
[not found] <bug-39290-4@http.gcc.gnu.org/bugzilla/>
2012-08-12 11:27 ` mikael at gcc dot gnu.org
2012-08-12 13:01 ` burnus at gcc dot gnu.org
@ 2012-08-18 21:56 ` mikael at gcc dot gnu.org
2012-08-18 22:00 ` mikael at gcc dot gnu.org
` (6 subsequent siblings)
9 siblings, 0 replies; 12+ messages in thread
From: mikael at gcc dot gnu.org @ 2012-08-18 21:56 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39290
--- Comment #4 from Mikael Morin <mikael at gcc dot gnu.org> 2012-08-18 21:56:02 UTC ---
(In reply to comment #3)
> Thus, I concur that it seems to be fixed. However, one could consider to
> include the two test cases of the IR in the testsuite - besides the invalid one
> of comment 0, the valid one of question 2 (see IR).
Actually, the valid test doesn't work as `qc' instead of `qr' is called in the
first call. Testcase:
! { dg-do run }
!
! PR fortran/39290
! Subroutine/function ambiguity in generics.
!
function ff()
ff = 4
end function ff
function cc()
cc = (5,6)
end function cc
subroutine qr(f)
real, external :: f
complex c
common /a/ r, c
r = f()
end subroutine
subroutine qc(f)
complex, external :: f
complex c
common /a/ r, c
c = f()
end subroutine
module m
interface q
subroutine qr(f)
real, external :: f
end subroutine
subroutine qc(f)
complex, external :: f
end subroutine
end interface q
end module m
program main
use m
external ff, cc
complex cc, c
common /a/ r, c
r = 1
c = (2, 3)
call q(ff)
!print *, r
if (r /= 4 ) call abort
!print *, c
if (c /= (2,3)) call abort
call q(cc)
!print *, r
if (r /= 4 ) call abort
!print *, c
if (c /= (5,6)) call abort
end
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug fortran/39290] Subroutine/function ambiguity in generics
[not found] <bug-39290-4@http.gcc.gnu.org/bugzilla/>
2012-08-12 11:27 ` mikael at gcc dot gnu.org
@ 2012-08-12 13:01 ` burnus at gcc dot gnu.org
2012-08-18 21:56 ` mikael at gcc dot gnu.org
` (7 subsequent siblings)
9 siblings, 0 replies; 12+ messages in thread
From: burnus at gcc dot gnu.org @ 2012-08-12 13:01 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39290
Tobias Burnus <burnus at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |burnus at gcc dot gnu.org
--- Comment #3 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-08-12 13:01:06 UTC ---
F03/0071 passed the WG5 voting (N1806). The latest version (pre WG5 voting) of
the IR F03/0071 can be found at
ftp://ftp.nag.co.uk/sc22wg5/N1801-N1850/N1805.txt
Thus, I concur that it seems to be fixed. However, one could consider to
include the two test cases of the IR in the testsuite - besides the invalid one
of comment 0, the valid one of question 2 (see IR).
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug fortran/39290] Subroutine/function ambiguity in generics
[not found] <bug-39290-4@http.gcc.gnu.org/bugzilla/>
@ 2012-08-12 11:27 ` mikael at gcc dot gnu.org
2012-08-12 13:01 ` burnus at gcc dot gnu.org
` (8 subsequent siblings)
9 siblings, 0 replies; 12+ messages in thread
From: mikael at gcc dot gnu.org @ 2012-08-12 11:27 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39290
Mikael Morin <mikael at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mikael at gcc dot gnu.org
--- Comment #2 from Mikael Morin <mikael at gcc dot gnu.org> 2012-08-12 11:27:07 UTC ---
It is now rejected with:
comment_0.f90:9.21:
end subroutine
1
Error: Ambiguous interfaces 'qc' and 'qr' in generic interface 'q' at (1)
FIXED?
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2013-07-16 6:17 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-02-24 14:35 [Bug fortran/39290] New: Subroutine/function ambiguity in generics burnus at gcc dot gnu dot org
2009-02-26 12:27 ` [Bug fortran/39290] " pault at gcc dot gnu dot org
[not found] <bug-39290-4@http.gcc.gnu.org/bugzilla/>
2012-08-12 11:27 ` mikael at gcc dot gnu.org
2012-08-12 13:01 ` burnus at gcc dot gnu.org
2012-08-18 21:56 ` mikael at gcc dot gnu.org
2012-08-18 22:00 ` mikael at gcc dot gnu.org
2013-04-28 18:35 ` janus at gcc dot gnu.org
2013-04-29 9:31 ` burnus at gcc dot gnu.org
2013-04-29 10:59 ` mikael at gcc dot gnu.org
2013-04-29 12:40 ` burnus at gcc dot gnu.org
2013-04-29 14:53 ` janus at gcc dot gnu.org
2013-07-16 6:17 ` burnus at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).