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/47399] New: ICE with TBP of a PARAMETER Date: Fri, 21 Jan 2011 15:19:00 -0000 [thread overview] Message-ID: <bug-47399-4@http.gcc.gnu.org/bugzilla/> (raw) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47399 Summary: ICE with TBP of a PARAMETER Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned@gcc.gnu.org ReportedBy: burnus@gcc.gnu.org CC: janus@gcc.gnu.org Found by Wolfgang Kilian, cf http://groups.google.com/group/comp.lang.fortran/msg/e6a865eda59e86db (Whole c.l.f thread: http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/69220fdd4c2715c0 ) The following program ICEs for variant #3, where one uses a TBP of a PARAMETER. The variants #1 and #2 compile with -std=f2003/f2008/gnu and print "13". Variant #1 with the TBP comment out compiles also with -std=f95. The ICE is by definition wrong. I have not checked whether the program is valid or not. My feeling is that variant #1 (with TBP comment) is at least invalid in -std=f95, but I might be wrong. Ifort fails with: "An automatic object is invalid in a main program." If this is not changed and applies here, one should check for it using a subroutine and not a main program. -- If one does so, ifort compiles #1 and #3 but rejects #2. NAG v5.1 does the same for the subroutine version. gfortran behaves identical for program and subroutine. TODO: a) Fix ICE b) Check whether the code is valid Fortran 2008 c) Check whether some diagnostic is needed for Fortran 95/2003/2008 d) Do (b) and (c) for program replaced by subroutine. The ICE is: test.f90:19:0: internal compiler error: in gfc_match_varspec, at fortran/primary.c:1846 module mytypes implicit none private public :: mytype, get_i integer, save :: i_priv = 13 type :: mytype integer :: dummy contains procedure, nopass :: i => get_i end type mytype contains pure function get_i () result (i) integer :: i i = i_priv end function get_i end module mytypes program test use mytypes implicit none type(mytype) :: a type(mytype), parameter :: a_const = mytype (0) ! integer, dimension (get_i()) :: x ! #1 ! integer, dimension (a%i()) :: x ! #2 integer, dimension (a_const%i()) :: x ! #3 print *, size (x) end program test
next reply other threads:[~2011-01-21 15:09 UTC|newest] Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top 2011-01-21 15:19 burnus at gcc dot gnu.org [this message] 2011-01-21 21:36 ` [Bug fortran/47399] " burnus at gcc dot gnu.org 2011-01-22 0:41 ` [Bug fortran/47399] [OOP] " burnus at gcc dot gnu.org 2011-01-22 14:24 ` burnus at gcc dot gnu.org 2011-01-22 21:25 ` burnus at gcc dot gnu.org 2011-12-12 8:10 ` burnus at gcc dot gnu.org 2012-01-28 21:00 ` dominiq at lps dot ens.fr 2013-09-01 14:38 ` dominiq at lps dot ens.fr 2013-12-14 20:17 ` dominiq at lps dot ens.fr
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-47399-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).