public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "burnus at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/48786] New: [OOP] Generic ambiguity check too strict for polymorphic dummies
Date: Wed, 27 Apr 2011 07:40:00 -0000	[thread overview]
Message-ID: <bug-48786-4@http.gcc.gnu.org/bugzilla/> (raw)

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48786

           Summary: [OOP] Generic ambiguity check too strict for
                    polymorphic dummies
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Keywords: rejects-valid
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: burnus@gcc.gnu.org
                CC: janus@gcc.gnu.org


Created attachment 24110
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24110
Example program

Reported at c.l.f by Arjen Markus
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/4a4e885f68b660bd

I have not really thought about the issue, but I believe gfortran wrongly
rejects the program.


One has:
  type point2d
with
  generic, public :: operator(+) => add_vector
and
  type, extends(point2d) :: point3d
with
  generic, public :: operator(+) => add_vector_3dversion

As one can pass any "point3d" data type to either add_vector_3dversion or
add_vector, gfortran complains:
  Error: 'add_vector_3d' and 'add_vector_2d' for GENERIC '+' at (1) are
ambiguous

However, the TKI is different, and thus I believe the error message is wrong -
in calls, add_vector_3d should be preferred and only if not available, one
should fall back to add_vector_2d.

"A dummy argument is type, kind, and rank compatible, or TKR compatible, with
another dummy argument if the first is type compatible with the second, the
kind type parameters of the first have the same values as the corresponding
kind type parameters of the second, and both have the same rank." (F2008,
12.4.3.4.5)

-> I believe the arguments have a different (declared) type.

It should also be somewhat compatible with: "12.5.5.2 Resolving procedure
references to names established to be generic" - but there it does not tell
which function one should call. Admittedly, I am a bit lost.


             reply	other threads:[~2011-04-27  7:40 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-27  7:40 burnus at gcc dot gnu.org [this message]
2011-04-27 14:34 ` [Bug fortran/48786] [4.6/4.7 Regression][OOP] " burnus at gcc dot gnu.org
2011-04-28  8:07 ` burnus at gcc dot gnu.org
2011-04-29  9:27 ` burnus at gcc dot gnu.org
2011-04-29 14:02 ` jakub at gcc dot gnu.org
2011-04-29 16:13 ` burnus at gcc dot gnu.org
2011-04-30 10:11 ` burnus at gcc dot gnu.org
2011-05-11 13:58 ` burnus at gcc dot gnu.org
2011-05-11 15:22 ` [Bug fortran/48786] [OOP] " burnus at gcc dot gnu.org
2013-07-02  9:13 ` dominiq at lps dot ens.fr
2013-08-21  8:48 ` janus at gcc dot gnu.org
2013-08-21 10:25 ` janus at gcc dot gnu.org
2013-08-21 12:19 ` dominiq at lps dot ens.fr
2013-08-21 14:43 ` janus at gcc dot gnu.org
2013-08-21 14:48 ` janus at gcc dot gnu.org
2021-01-24 17:55 ` tkoenig at gcc dot gnu.org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-48786-4@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).