public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "mrestelli at gmail dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/61527] New: class/extends, multiple generic assignment, accept invalid Date: Mon, 16 Jun 2014 16:06:00 -0000 [thread overview] Message-ID: <bug-61527-4@http.gcc.gnu.org/bugzilla/> (raw) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61527 Bug ID: 61527 Summary: class/extends, multiple generic assignment, accept invalid Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: mrestelli at gmail dot com Hi, I see that gfortran accepts the following code (even with strict debug flags) which is ambiguous in the resolution of the generic. The code is correctly rejected if disp2 uses CLASS(t2) instead of TYPE(t2), while with TYPE(T2) the code compiles and DISP2 is called, which I think should not be allowed. $ gfortran --version GNU Fortran (GCC) 4.10.0 20140613 (experimental) module m implicit none private public :: t1, t2, disp type :: t1 integer :: i = 1 end type t1 type, extends(t1) :: t2 real :: r = 2.0 end type t2 interface disp module procedure disp1, disp2 end interface contains subroutine disp1(x) class(t1), intent(in) :: x write(*,*) "Disp 1: ",x%i end subroutine disp1 subroutine disp2(x) type(t2), intent(in) :: x ! <- accepted !class(t2), intent(in) :: x ! <- rejected write(*,*) "Disp 2: ",x%r end subroutine disp2 end module m program p use m implicit none type(t1) :: a type(t2) :: b call disp(a) call disp(b) end program p
next reply other threads:[~2014-06-16 16:06 UTC|newest] Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-06-16 16:06 mrestelli at gmail dot com [this message] 2014-06-16 16:19 ` [Bug fortran/61527] " dominiq at lps dot ens.fr 2014-06-16 16:38 ` mrestelli at gmail dot com 2014-07-12 21:33 ` [Bug fortran/61527] [4.9/4.10 Regression] " burnus at gcc dot gnu.org 2014-07-12 22:05 ` dominiq at lps dot ens.fr 2014-10-30 10:40 ` [Bug fortran/61527] [4.9/5 " jakub at gcc dot gnu.org 2014-11-24 16:45 ` rguenth at gcc dot gnu.org 2015-01-16 17:16 ` janus at gcc dot gnu.org 2015-01-16 17:43 ` janus at gcc dot gnu.org 2015-06-26 20:01 ` [Bug fortran/61527] [4.9/5/6 " jakub at gcc dot gnu.org 2015-06-26 20:31 ` jakub at gcc dot gnu.org 2021-05-14 9:47 ` [Bug fortran/61527] [9/10/11/12 Regression] [OOP] " jakub at gcc dot gnu.org 2021-06-01 8:06 ` rguenth at gcc dot gnu.org 2022-05-27 9:35 ` [Bug fortran/61527] [10/11/12/13 " rguenth at gcc dot gnu.org 2022-06-28 10:30 ` jakub at gcc dot gnu.org 2023-07-07 10:30 ` [Bug fortran/61527] [11/12/13/14 " rguenth at gcc dot gnu.org 2024-04-26 10:06 ` pault 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-61527-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).