[Bug fortran/39290] Subroutine/function ambiguity in generics

[Bug fortran/39290] Subroutine/function ambiguity in generics

[mikael at gcc dot gnu.org]

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?

[Bug fortran/39290] Subroutine/function ambiguity in generics

[burnus at gcc dot gnu.org]

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).

[Bug fortran/39290] Subroutine/function ambiguity in generics

[mikael at gcc dot gnu.org]

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

[Bug fortran/39290] Subroutine/function ambiguity in generics

[mikael at gcc dot gnu.org]

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

[Bug fortran/39290] Subroutine/function ambiguity in generics

[janus at gcc dot gnu.org]

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 ...

[Bug fortran/39290] Subroutine/function ambiguity in generics

[burnus at gcc dot gnu.org]

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.)"

[Bug fortran/39290] Subroutine/function ambiguity in generics

[mikael at gcc dot gnu.org]

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.

[Bug fortran/39290] Subroutine/function ambiguity in generics

[burnus at gcc dot gnu.org]

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.

[Bug fortran/39290] Subroutine/function ambiguity in generics

[janus at gcc dot gnu.org]

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

[Bug fortran/39290] Subroutine/function ambiguity in generics

[burnus at gcc dot gnu.org]

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

[Bug fortran/39290] Subroutine/function ambiguity in generics

[pault at gcc dot gnu dot org]

------- 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