public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "pault at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/34545] ICE when compiling Fortran 95 code Date: Tue, 01 Jan 2008 17:11:00 -0000 [thread overview] Message-ID: <20080101171100.AtOHEPV4HVI_UxMncwLVWfwXcwaN3hvMA17u1O1ZxYk@z> (raw) In-Reply-To: <bug-34545-15536@http.gcc.gnu.org/bugzilla/> ------- Comment #11 from pault at gcc dot gnu dot org 2008-01-01 17:11 ------- This is a most peculiar bug, which has nothing to do with allocatability or temporariness. The result variables of the functions 'get_numbr' and 'get_nfirst' are REAL(mp), whereas they are assigned to INTEGER arrays. Changing the results to INTEGER in the original clears the problem and, up to missing input files, the code seems OK. This very much reduced example illustrates the problem: module m1 integer :: numclusters = 2 end module m1 module m2 contains function get_nfirst( ) result(fnres) use m1, only: numclusters real :: fnres(numclusters) ! change to REAL and it works!! end function get_nfirst end module m2 program kmeans_driver use m1 use m2 integer :: nfirst(3) nfirst(1:numclusters) = get_nfirst( ) end program kmeans_driver Alternatively, moving the USE m1 in 'get_nfirst' to be a module specification statement, fixes the problem.....:) I'm thinking about it; the offending version of numclusters is linked to a namespace that has no proc_name. Why this should cause problems when there is a type mismatch, I have no idea. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34545
next prev parent reply other threads:[~2008-01-01 17:11 UTC|newest] Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top 2007-12-21 4:47 [Bug fortran/34545] New: " jon_d_r at msn dot com 2007-12-21 4:50 ` [Bug fortran/34545] " jon_d_r at msn dot com 2007-12-21 4:57 ` jon_d_r at msn dot com 2007-12-21 6:09 ` jv244 at cam dot ac dot uk 2007-12-21 6:14 ` kargl at gcc dot gnu dot org 2007-12-21 7:39 ` burnus at gcc dot gnu dot org 2007-12-21 9:47 ` dfranke at gcc dot gnu dot org 2007-12-21 12:28 ` pinskia at gcc dot gnu dot org 2007-12-26 18:36 ` jon_d_r at msn dot com 2007-12-26 22:07 ` kargl at gcc dot gnu dot org 2007-12-27 10:34 ` jon_d_r at msn dot com 2007-12-29 8:57 ` dfranke at gcc dot gnu dot org 2008-01-01 17:11 ` pault at gcc dot gnu dot org [this message] 2008-01-01 17:24 ` pault at gcc dot gnu dot org 2008-01-01 22:47 ` dominiq at lps dot ens dot fr 2008-01-02 21:57 ` pault at gcc dot gnu dot org 2008-01-06 19:36 ` burnus at gcc dot gnu dot org 2008-01-06 21:37 ` paulthomas2 at wanadoo dot fr 2008-01-06 22:15 ` pault at gcc dot gnu dot org 2008-01-07 10:05 ` pault at gcc dot gnu dot 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=20080101171100.AtOHEPV4HVI_UxMncwLVWfwXcwaN3hvMA17u1O1ZxYk@z \ --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).