Hello All,

I'd appreciate any insight anyone can give.  I'm trying to convert some
VERY old f77 code to work on a newer Sun System in which f90 is my only
available compiler.  The code seems to run fine up until a given exp()
function -- which should be in the fortran common libraries.  At that
point I get a SIGILL with a bad opcode notice.

The only 'special' option I'm using is -xtypemap=real:64,integer:64
with f77 which is being invoked as f90 -f77 -ftrap=%none.  I've tried
turning off optimizations to no avail.

Any ideas?

- Bryan

OS: SunOS 5.8
Compiler: f90 shipped with Sun Studio 8

[ Post a follow-up to this message ]

<Bryan.Berns@gmail.com> wrote in message
news:1120707760.502002.81140@g14g2000cwa.googlegroups.com...
> Hello All,
>
> I'd appreciate any insight anyone can give.  I'm trying to convert some
> VERY old f77 code to work on a newer Sun System in which f90 is my only
> available compiler.  The code seems to run fine up until a given exp()
> function -- which should be in the fortran common libraries.  At that
> point I get a SIGILL with a bad opcode notice.

Please show us an extract from the code. The exp function is common to F77
and f90, so should usually cause no problem.

Regards,

Mike Metcalf

[ Post a follow-up to this message ]

Bryan.Berns@gmail.com wrote:

> I'd appreciate any insight anyone can give.  I'm trying to convert some
> VERY old f77 code to work on a newer Sun System in which f90 is my only
> available compiler.  The code seems to run fine up until a given exp()
> function -- which should be in the fortran common libraries.  At that
> point I get a SIGILL with a bad opcode notice.

> The only 'special' option I'm using is -xtypemap=real:64,integer:64
> with f77 which is being invoked as f90 -f77 -ftrap=%none.  I've tried
> turning off optimizations to no avail.

> OS: SunOS 5.8
> Compiler: f90 shipped with Sun Studio 8

I presume you mean Solaris/SPARC but it could be Solaris/x86 which would
be completely different.

I would probably start with a debugger to find which illegal instruction
is being executed.

Your xtypemap is making all real variables 64 bit, but Fortran 77
doesn't have generic functions so maybe it needs DEXP, though I don't
see that that would cause SIGILL, anyway.

I presume you are not getting link errors for missing math library
routines.   Can you find the smallest program which causes this error,
such as a single EXP() call with those options?

-- glen

[ Post a follow-up to this message ]

"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
news:WNqdnXDs1t7iRlHfRVn-og@comcast.com...
>
> Your xtypemap is making all real variables 64 bit, but Fortran 77 doesn't
> have generic functions so maybe it needs DEXP,

Sure F77 had generic names for specific functions!

Regards,

Mike Metcalf

[ Post a follow-up to this message ]

Michael Metcalf wrote:
> "glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
> news:WNqdnXDs1t7iRlHfRVn-og@comcast.com...
 
[vbcol=seagreen]
> Sure F77 had generic names for specific functions!

www.fortran.com seems to be down now.  I thought they didn't come
until later, though it doesn't seem like a very good explanation,
anyway.   Calling a function with the wrong type normally won't
get SIGILL, but then you never really know until you try it.

-- glen

[ Post a follow-up to this message ]

I have come to some level of resolution.  I debugged the program and
found the number being fed into exp() were fairly large.  Sure enough,
a 3-line fortran program doing the exp operation with a similiar input
caused an exception.  Somehow the exception turned into a SIGILL
(ILLEGAL OPCODE) when compiled all this other code around it.

Unfortunately that doesn't solve my problem of why the code compiled on
Solaris 2.6 with f77 doesn't work with f90 on Solaris 2.8 with
'equivalent' switches.  If anyone has a good set of switches that make
f90 do the EXACT same thing as f77 would do with using the -r8 switch.
So far I've tried f90 -f77 -ftrap=%none -fsimple=0
-xtypemap:real:64,integer:64 -dbl_align_all=yes -aligncommon=8.   This
code was originally developed on a cray and uses 1000's of equivalences
on variables.  Ugly ugly ugly.

- Bryan

[ Post a follow-up to this message ]

Bryan.Berns@gmail.com wrote:

> I have come to some level of resolution.  I debugged the program and
> found the number being fed into exp() were fairly large.  Sure enough,
> a 3-line fortran program doing the exp operation with a similiar input
> caused an exception.  Somehow the exception turned into a SIGILL
> (ILLEGAL OPCODE) when compiled all this other code around it.

While intel doesn't recommend it many compilers generate these functions
with inline code.  That is, with no tests to see that the argument is
within the allowable range.

I think you can use adb to find the instruction that causes
the exception and the register contents at that time.

> Unfortunately that doesn't solve my problem of why the code compiled on
> Solaris 2.6 with f77 doesn't work with f90 on Solaris 2.8 with
> 'equivalent' switches.  If anyone has a good set of switches that make
> f90 do the EXACT same thing as f77 would do with using the -r8 switch.
> So far I've tried f90 -f77 -ftrap=%none -fsimple=0
> -xtypemap:real:64,integer:64 -dbl_align_all=yes -aligncommon=8.   This
> code was originally developed on a cray and uses 1000's of equivalences
> on variables.  Ugly ugly ugly.

You might try turning off inlining transcendental functions, if there
is an option for that.  It might help, anyway.

-- glen

[ Post a follow-up to this message ]

Sun f90/f95 cannot be made to do exactly the same thing as Sun f77.
The two products were based on different code bases (the Craysoft
compiler and the AT&T compiler).   A lot of work was done to improve
the compatibility of the two products, but there are still many
differences.

I argued for maintaining both Sun f77 and Sun f90/f95, but when the
economy suddenly turned sour, I lost the argument.

One difference between -r8 and what you have specified is that
-r8 implies -xtypemap=real:64,double:128,integer:32.

I would be interested in seeing a small example that shows overflow
turning
into a SIGILL.  The usual cause of a SIGILL is calling a structure
returning
function which has been declared to return a scalar type.

Bob Corbett

[ Post a follow-up to this message ]

In article <yYadnThGScA3l1DfRVn-oQ@comcast.com>,
glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

> Michael Metcalf wrote: 
> 
> 
>
> I thought they didn't come until later,

You are probably thinking of user-defined generics, which were new in
f90. The intrinsics were generic in f77. In fact, only a few intrinsics
in f77 even have specific names (namely, the ones inherited from f66).

There really has been almost no good reason to use specific names for
intrinsics for a *LONG* time. (Yes, you need to use a specific name to
pass an intrinsic as an actual argument, but that so seldom comes up,
for the few cases where it is allowed, that it counts as "almost no good
reason".)

--
Richard Maine                       |  Good judgment comes from experience;
email: my first.last at org.domain  |  experience comes from bad judgment.
org: nasa, domain: gov              |        -- Mark Twain

[ Post a follow-up to this message ]

This is an old topic, but since you actually took the time to notice
the discrepancy, maybe you'll have some input:

Yes, -r8 mathematically implies:
 xtypemap=3Dreal:64,double:128,i=ADnteger
:32.

But allocation wise it implies:
 xtypemap=3Dreal:64,double:128,i=ADnteger
:64

And that is pretty much my dillema.  There are alot of variable in
common that depend on allocations being 8 bytes wide.  I thought
-aligncommon=3D8 would fix that but I'm thinking that it will only 8-byte
align if I have an uneven boundary (like 32 + 16 + 32 + 32 would even
up being allocated as 64 [32 + 16] + 64 [32 + 32].

I know there was xtypemap=3Dinteger:mixed but I have no idea what that
does and it's be obseleted in the latest compiler.

[ Post a follow-up to this message ]