[MITgcm-devel] gfortran 4.0.0 an ptracers_readparms

Sun Mar 12 02:00:52 EST 2006

Hi Ed,
I now have gfortran 4.2.0 on my Apple PowerBook and the code compiles  
and runs (although compiling with gfortran is really slow).
However, I don't seem to be able to use the netcdf libraries that  
work with g77. Do you know anything about that. I have tried to have  
a look at the name mangling with "nm", but it seems that  the  
underscores are at the right places (if I could only interpret the  
output of nm (o:)

Martin
PS. I include an example:
> csysm3::bin> nm ini_parms.o
>          U __gfortran_compare_string
>          U __gfortran_st_close
>          U __gfortran_st_open
>          U __gfortran_st_read
>          U __gfortran_st_read_done
>          U __gfortran_st_rewind
>          U __gfortran_st_set_nml_var
>          U __gfortran_st_set_nml_var_dim
>          U __gfortran_st_write
>          U __gfortran_st_write_done
>          U __gfortran_stop_string
>          U __gfortran_transfer_character
>          U __gfortran_transfer_integer
>          U _barrier_
> 000002c0 C _eeparams_i_
> 0000001c C _eeparams_l_
> 000040a0 C _grid_i_
> 0057e278 C _grid_r_
>          U _ilnblnk_
> 00000000 T _ini_parms_
>          U _modeldata_example_
>          U _nml_set_terminator_
> 00000010 C _parm_a_
> 00000038 C _parm_atm_
> 00003a1a C _parm_c_
> 00000148 C _parm_eos_jmd95_
> 00000018 C _parm_eos_lin_
> 000000c8 C _parm_eos_mdjwf_
> 00000600 C _parm_eos_nl_
> 0000005c C _parm_i_
> 00000168 C _parm_l_
> 00000078 C _parm_packages_
> 00000c58 C _parm_r_
>          U _print_error_
>          U _print_message_
>          U _set_defaults_
>          U dyld_stub_binding_helper

And for the netcdf library

> csysm3::bin> nm /sw/lib/libnetcdf.a | head -30
>
> /sw/lib/libnetcdf.a(attr.o):
> 000004b8 t _NC_attrarray0
>          U _NC_check_id
>          U _NC_check_name
> 000004f8 T _NC_findattr
> 000005a8 t _NC_lookupattr
>          U _NC_sync
> 000001c8 t _dup_NC_attr
> 000002dc T _dup_NC_attrarrayV
> 0000048c T _elem_NC_attrarray
>          U _free
> 00000000 T _free_NC_attr
> 00000290 T _free_NC_attrarrayV
> 00000224 T _free_NC_attrarrayV0
>          U _free_NC_string
> 000003c8 t _incr_NC_attrarray
>          U _malloc
>          U _memcpy
>          U _memset
>          U _nc_cktype
> 0000098c T _nc_copy_att
> 00000b64 T _nc_del_att
> 00002824 T _nc_get_att
> 00002734 T _nc_get_att_double
> 00002498 T _nc_get_att_float
> 00001f60 T _nc_get_att_int
> 000021fc T _nc_get_att_long
> 0000178c T _nc_get_att_schar
> 00001cc4 T _nc_get_att_short

On Mar 10, 2006, at 5:32 PM, Ed Hill wrote:

> On Fri, 2006-03-10 at 10:17 +0100, Martin Losch wrote:
>> Hi,
>> I have tried to use gfortran (gcc version 4.0.0) on my Apple
>> PowerBook with the MITgcm and I could not compile the model because
>>> ptracers_readparms.f:1936: internal compiler error: in
>>> gfc_conv_string_parameter, at fortran/trans-expr.c:1986
>>> Please submit a full bug report,
>>> with preprocessed source if appropriate.
>>> See <URL:http://gcc.gnu.org/bugs.html> for instructions.
>>
>> Before I submit this report, I would like to know if there is any
>> experience with gfortran and the MITgcm. I saw that for Fedora there
>> are opt files.
>>
>> gFortran cannot handle the following character arrays in the namelist
>> PTRACERS_PARMS01:
>> PTRACERS_initialFile(PTRACERS_num)
>> PTRACERS_names(PTRACERS_num)
>> PTRACERS_long_names(PTRACERS_num)
>> PTRACERS_units(PTRACERS_num)
>>
>> Is there a more recent version around that can do this?
>
> Hi Martin,
>
> Yes, I've been testing MITgcm with gfortran for nearly a year and here
> is what I know to date:
>
>  1) Officially, the gfortran front end in GCC 4.0.x is a
>     "technology preview" and is not expected to work with
>     all codes that g77 can compile.  The gfortran in newer
>     GCC versions (4.1.x and later) includes *many* Fortran-
>     related bug fixes and is approaching a "recommended
>     for general use" state.  It works for me on a number of
>     MITgcm verification tests (at least it did a few months
>     ago) on x86 hardware.
>
>  2) There is a name-list problem (not technically a bug, but
>     an inability to parse "de facto standard" rather than
>     "actual ISO standard" namelist syntax) in gfortran.  I've
>     submitted a bug to the GCC maintainers and hopefully the
>     feature will get added at some point in the future:
>
>       http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24459
>
>     In the mean time, there is a somewhat inconvenient work-
>     around that we can do and it is to explicitly specify
>     the number of strings within the namelists such as (this
>     is ISO-standard Fortran90 syntax):
>
>       astring(1:3,1) = 'name1  ', 'name2  ', 'name3  '
>
>     instead of the older ("de facto" F77 syntax):
>
>       astring(1,1) = 'name1  ', 'name2  ', 'name3  '
>
>  3) Please upgrade to the latest gfortran that you can find
>     for your hardware.  The 4.0.x version you have is known
>     to be buggy and more recent stuff may be appreciably
>     better.
>
> I'll add gfortran to our daily testing soon (when FC5 is released in a
> couple of weeks).
>
> Ed
>
> -- 
> Edward H. Hill III, PhD
> office:  MIT Dept. of EAPS;  Rm 54-1424;  77 Massachusetts Ave.
>              Cambridge, MA 02139-4307
> emails:  eh3 at mit.edu                ed at eh3.com
> URLs:    http://web.mit.edu/eh3/    http://eh3.com/
> phone:   617-253-0098
> fax:     617-253-4464
>
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel