Brian,

We submitted a bug report this morning to Portland Group.
I provided them with a stripped-down piece of code that
duplicated the problem.  They replied that they just released
a new version of the compiler (4.0) and that the code
compiles properly with that version.  Apparently this is the
"patch" to fix the problem with version 3.3.

In the meantime, if lines 763 - 765 are replaced by a loop
in which domain%list() is indexed explicitly from 0 to ndivs-1,
the compiler accepts the code, i.e.,

      do ndiv = 0, ndivs - 1
         domain%list(ndiv)%data%begin = domain%list(ndiv)%data%begin - halosz
         domain%list(ndiv)%data%end   = domain%list(ndiv)%data%end   + halosz
         domain%list(ndiv)%data%size  = &
             domain%list(ndiv)%data%end - domain%list(ndiv)%data%begin + 1
      enddo

I'm not real up to speed with F90 pointers, but it looks to me that
this duplicates the function of the original code.  If not, please let
me know.  With this change, the "solo" code compiles and links cleanly.

Thanks,

Norm


On 20 May., Norm Wood wrote:
> Brian,
> 
> Make that 3.3-3.  Anyway, I ran pgf90 over the remaining code for
> the atmos_solo version and no other problems popped up (as long
> as I used the -r8 flag, as is done in the mkmf template for pgi).
> 
> I isolated the cause to lines 763 and 764 in mpp_domains.F90.
> 
> 763       domain%list(:)%data%begin = domain%list(:)%data%begin - halosz
> 764       domain%list(:)%data%end = domain%list(:)%data%end   + halosz
> 765       domain%list(:)%data%size  = domain%list(:)%data%end - 
>domain%list(:)%data%begin + 1
> 
> Apparently, pgf90 doesn't like the terms domain%list(:)%data%begin
> and domain%list(:)%data%end on the _right_hand_side_ of these
> two lines.  Which is confusing, because it doesn't mind line 765
> at all.  I'll see if I can put together a short piece of code
> that duplicates the problem.
> 
> Norm
> 
> On 20 May., Norm Wood wrote:
> > Brian,
> > 
> > Ouch, "significant trouble" sounds a little ominous.  Yes, we're using
> > 3.3-2.  We just upgraded several weeks ago after we'd run into
> > some problems with 3.2's handling of pointers used to pass array
> > sections into subroutines.
> > 
> > I'll try running the compiler over the remaining source to see what other
> > snags might pop up with this particular version.
> > 
> > Thanks,
> > 
> > Norm
> > 
> > On 20 May., Brian Gross wrote:
> > > Norm, what version of the PGF compiler are you using? We're using 3.2-4a at
> > > GFDL, with which all our codes compile cleanly here, but a user had "significant
> > > trouble" compiling one of our FMS-based ocean models (MOM4-beta) with version
> > > 3.3-2.
> > > 
> > > Thanks!
> > > 
> > > Brian
> > > 
> > > Norm Wood wrote:
> > > > 
> > > > All,
> > > > 
> > > > I thought I'd post a quick note to see if anyone else had yet
> > > > run into this particular error.
> > > > 
> > > > While compiling shared/mpp/mpp_domains.F90, pgf90 gives the messages
> > > > shown below (I've wrapped the lines).  The code's been updated
> > > > with the files Brian provided for Portland Group, although
> > > > this particular file wasn't affected.
> > > > 
> > > > Lowering Error: unknown source type for conversion to integer
> > > >     [ast=6956,asttype=10,datatype=582]
> > > > Lowering Error: unknown source type for conversion to integer
> > > >     [ast=6968,asttype=10,datatype=582]
> > > > PGF90-F-0000-Internal compiler error. Errors in Lowering
> > > >    2 (/home/norm/Working/GFDL_FMS/FMS_solo/fms_src/shared/
> > > >        mpp/mpp_domains.F90: 779)
> > > > 
> > > > Line 779 is the "contains" statement in subroutine
> > > > mpp_define_domains1D().
> > > > 
> > > > This occurred with just the basic preproc/compile flags from
> > > > mkmf.template.pgi, i.e.,
> > > > 
> > > > pgf90 -Duse_netCDF -Duse_libMPI -c -Ifms_src/shared/mpp
> > > >    fms_src/shared/mpp/mpp_domains.F90
> > > > 
> > > > I wish pgf90 would provide some more details, using the
> > > > "-Minform,inform" flag didn't provide any additional details
> > > > on this particular problem.  Is the error the result of an
> > > > attempt to convert a user-defined type to an int?  Any
> > > > pointers would be appreciated.
> 
> _______________________________________________________________
> 
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
> 
> _______________________________________________
> Fms-users mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/fms-users

-- 
Norm Wood

     Department of Atmospheric Science
     Colorado State University
     [EMAIL PROTECTED]
     phone:  970-491-3334

_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

_______________________________________________
Fms-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fms-users

Reply via email to