-------------- Original message ----------------------
From: Jouni Lerssi <[log in to unmask]>
> Malcolm & others,
>
> problem solved OK,
> only by using -dusty flag in compiling....
> I did'nt realize that it would ha ve that effect :)..
> I'm trying NAGWare f95 now and have had some success of
> compiling and running geophysical modelling programs,,,
> Although I got guite o alot of errors like:
>
> *** Arithmetic exception: Floating divide by zero - aborting
> In HSMD_KER, line 4218 of Airbeo_m.f90
> Called by HSMD_HNK, line 4113 of Airbeo_m.f90
> Called by HSMD_FD, line 4045 of Airbeo_m.f90
> Called by HSBOSS_FD, line 3949 of Airbeo_m.f90
> Called by GET_FWD_MODL, line 3765 of Airbeo_m.f90
> Called by FORJAC, line 3711 of Airbeo_m.f90
> Called by NLSQ2, line 4591 of Airbeo_m.f90
> Called by AIRBEO, line 2218 of Airbeo_m.f90
> Called by MAIN, line 1884 of Airbeo_m.f90
> Abort
> [gefmac1:~/amira/Airbeo] jlerssi% f95 -O0 -g -gline -dusty Airbeo_m.f90
>
> Programs should be "well checked" standard fortran90 -code.
Yeah, that's what they all say ;).
In general, problems like this with one compiler and not with others
are due to some sort of programming error. The most obvious choices
are a subscript out of bounds or failure to initialize some variable.
Different compilers do memory layout in different orders, so a "harmless"
subscript problem with one compiler will be catastrophic with another.
Many compilers preset at least some memory to zero at program start-up.
Others don't, or don't preset the same memory. Perhaps the Nag compiler
statically assigns a subroutine variable in memory (doing an implicit
save) and the other compiler puts it on the stack (doing an implicit
randomization of the value) and that changes the way IF statements
go.
These kinds of things are particularily common in programs that
require the "dusty" options to work. People and compilers were
less careful in the good old days about the way things worked
and the distinctions between bug and extension were blurred.
Try turning on as many of the run-time checks as you can. Lahey
used to have a very good uninitialized variable checker. I don't
know if they still do, or if Nag also has one. But it's worth looking
for. Also check array bounds and argument matching.
Finally, try putting a PRINT statement just before line 4218 and
see what the values are.
Dick Hendrickson
> And they are known to behave well when compiled by Lahey and/or digital
> -fortran90 compilers in PC.
> Is Nagware compiler more sensitive to that kind of exceptions or am I
> again missing some flag ?
> or is it somehow platform specific?
> Is there any MAnual of Nagware -compiler?
> all I got is man page in html mode...
>
> 17.12.2004 kello 04:45, Malcolm Cohen kirjoitti:
>
> Richard E Maine said:
> >> But allow me to point you to the NAG compiler's -dusty switch. If you
> >> have
> >
> > Yes, that is the right solution.
> >
> >> a fairly recent version of the compiler, -dusty allows the above
> >> equivalences. I think this was new to version 5.x.
> >
> > No. It has been present for a long time.
> >
> >> most compilers accept it - NAG's was probably in the minority in not
> >> having a way to accept it (until v5.x).
> >
> > Actually, we accepted it in release 2.0b, back in 1993.
> > So we have had it for over a decade ...
> >
> > Cheers,
> > --
> > ...........................Malcolm Cohen, NAG Ltd., Oxford, U.K.
> > ([log in to unmask])
> >
> > _______________________________________________________________________
> > _
> > This e-mail has been scanned for all viruses by Star. The
> > service is powered by MessageLabs. For more information on a proactive
> > anti-virus service working around the clock, around the globe, visit:
> > http://www.star.net.uk
> > _______________________________________________________________________
> > _
> >
|