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


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