[MITgcm-devel] problem with TAF latest version (2.0.2)

[Constantinos Evangelinos]

As I just explained to Jean-Michel this is fixable by compiling with -fPIC (or 
-mcmodel=medium but in that case all libraries have to have been built with -
fPIC or -mcmodel=medium). The question is what is TAF doing that generates 
objects so large for the named symbols below that the 2GB mark is exceeded? 
And why wasn't it doing it before?

Constantinos
-- 
Dr. Constantinos Evangelinos
Department of Earth, Atmospheric and Planetary Sciences
Massachusetts Institute of Technology

On Thursday, October 14, 2010 02:05:57 pm Jean-Michel Campin wrote:
>  Hi,
>  
>  we have a problem with the latest version of TAF (2.0.2)
>  which was turned on early this morning.
>  The verification experiment tutorial_global_oce_optim did not
>  
>  run on faulks (compiled with gfortran):
>  > faulks{run}% mitgcmuv_ad > std_outp
>  > Killed
>  
>  and on my laptop, with gfortran, I am getting errors at the link stage:
>  > In function `adautodiff_restore':
>  > /home/jmc/mitgcm/gcm_gnu/verification/tutorial_global_oce_optim/bld_ad/a
>  > d_taf_output.f:530: relocation truncated to fit: R_X86_64_32S against
>  > symbol `addynvars_r_2_' defined in COMMON section in ad_taf_output.o
>  > /home/jmc/mitgcm/gcm_gnu/verification/tutorial_global_oce_optim/bld_ad/
>  > ad_taf_output.f:531: relocation truncated to fit: R_X86_64_32S against
>  > symbol `addynvars_r_2_' defined in COMMON section in ad_taf_output.o
>  > ad_taf_output.o: In function `adautodiff_store':
>  > /home/jmc/mitgcm/gcm_gnu/verification/tutorial_global_oce_optim/bld_ad/a
>  > d_taf_output.f:791: relocation truncated to fit: R_X86_64_32S against
>  > symbol `addynvars_r_2_' defined in COMMON section in ad_taf_output.o
>  
>  the TAF option (from taf_ad.log) that I use are:
>  > taf -outdir . -v1 -reverse -admark ad -i4 -r4 -l taf_ad.log -flow
>  > taf_ad_flow.log -toplevel the_main_loop -input
>  > xx_theta_dummy,xx_salt_dummy,xx_hflux_dummy,xx_sflux_dummy,xx_tauu_dumm
>  > y,xx_tauv_dummy,xx_atemp_dummy,xx_aqh_dummy,xx_uwind_dummy,xx_vwind_dumm
>  > y,xx_diffkr_dummy,xx_kapgm_dummy,xx_efluxp_dummy,xx_hfluxm_dummy -output
>  > fc ad_input_code.f
>  
>  I went back to version 2.0.0 with exactly the same source code and
>  things were OK (compile and run).
>  
>  I attach the source code (ad_input_code.f) and the 2 output from TAF,
>  generated with version 2.0.0 (ad_input_code_ad.f.old) and
>  with version 2.0.2 (ad_input_code_ad.f.new).
>  
>  I don't see any obvious reason why we have this problem,
>  and going to try other compilers and other test experiments.
>  
>  Thanks,
>  Jean-Michel