========================================================================
RIASSUNTO: ORAC viene generalmente compilato con le opzioni di
sicurezza "save" e "zero". In gfortran pero` queste non funzionano
bene insieme, come si rivela nel calcolo del lavoro di Jarzynski fatto
da comp_work.f. Sarebbe auspicabile correggere il codice in modo da
renderlo indipendente dal compilatore e da queste opzioni.
========================================================================

Sto verificando le opzioni di compilazione usate nel Makefile di ORAC
per i vari compilatori.

In particolare ho esaminato le due opzioni di sicurezza "save" e
"zero" cioe` quelle che prevedono di compilare come se ogni subroutine
contenesse, rispettivamente, le istruzioni "SAVE" e "DATA /0./" per
tutte le variabili locali.

Ci sono casi in cui una certa subroutine viene chiamata ripetutamente
dal programma, ed e` previsto che il valore di una variabile x
_locale_ (cioe`, non un dummy argument) sia conservato tra una
chiamata o l'altra, per esempio per accumularci dati. Il modo corretto
di programmare la subroutine e` usare un'istruzione SAVE.
L'inizializzazione (p.es. a zero) della variabile non puo` essere
fatta esplicitamente nella subroutine -altrimenti si riazzera a ogni
chiamata- percio` si deve affiancare al "SAVE x" un "DATA x /0./".

In questi casi, le due opzioni del compilatore curano un'eventuale
(scorretta) omissione delle istruzioni "SAVE" e "DATA /0./". L'aspetto
negativo e` che operano a tappeto su tutte le variabili locali, cosa
che puo` non essere desiderata e comunque aumenta le dimensioni del
programma.

Questa situazione si presenta in "comp_work.f": a quanto ho capito,
gli array DIFFBO, DIFFBE, DIFFTO dovrebbero essere conservati tra una
chiamata e l'altra di comp_work.f (sono utilizzati e poi aggiornati in
steer_print.f), ma dato che essi non sono in SAVE ne' in DATA, in
assenza delle opzioni di compilazione "save"+"zero" il funzionamento
non e` quello giusto.

Ho pero` notato che GFORTRAN NON SI COMPORTA NEL MODO ATTESO. In
particolare nei test di jarzynski seriali se si compila con l'opzione
"zero" (-finit-local-zero) il lavoro calcolato viene la meta` (non
esatta).

Ho fatto un po' di ricerche, e anche dei test con il programma
ORAC/trunk/etc/test_zero_w_save.f, che da` risultati diversi a seconda
che si attivino o no le due opzioni nei vari compilatori:

	   "save"           "zero"  
	   --------    	    ------  
Intel      -save       	    -zero   
*xlf*      -qsave      	    -qinitauto	       
g95        -fstatic    	    -fzero  
gfortran   -fno-automatic   -finit-local-zero(>=4.3)


RISULTATO: In gfortran 4.3 e 4.4 l'opzione "zero" (-finit-local-zero)
riazzera le variabili locali ad ogni chiamata, anche in presenza
dell'opzione "save" (-fno-automatic):

  [http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42267] "when using both
  flags, the variables are initialized on every function call."

Apparentemente, in gfortran l'opzione "save" (-fno-automatic) implica
anche l'opzione "zero" correttamente intesa.


CONCLUSIONI: 

I casi come quello di "test_zero_w_save.f" possono essere resi piu`
solidi inserendo le istruzioni SAVE e DATA nel codice. Comunque, sono
intrinsecamente patologici e andrebbero riscritti in altro modo, ad
esempio mettendo la variabile da serbare come dummy argument con il
programma chiamante, e inizializzandola con un assegnamento in
quest'ultimo.

In "comp_work.f" per prima cosa bisogna chiarire se davvero ci si
aspetta che DIFFBO etc siano conservati anche quando si esce da
comp_work e si torna a mtsmd. Che sia cosi` o no, correggerei il
codice in modo da renderlo meno ambiguo e piu` stabile.

In attesa di questo chiarimento nel Makefile per gfortran resta attiva
la sola opzione "-fno-automatic".

In ogni caso, raccomanderei, quando si scrive nuovo codice, di
provarlo sempre senza le opzioni "save" ne' "zero".









