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.
next 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: linkBe 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).