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

[Jean-Michel Campin]

Constantinos,

Right. I tried -fPIC and it fixes the problem.
Just a little bit curious that this was not necessary before (with 
TAF 2.0.0).

Thanks,
Jean-Michel

On Thu, Oct 14, 2010 at 06:06:49PM -0400, Constantinos Evangelinos wrote:
> 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
>