|
Home > Archive > Unix Programming > July 2005 > SIGILL on running exp() with f90 compiled code
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
SIGILL on running exp() with f90 compiled code
|
|
| Bryan.Berns@gmail.com 2005-07-07, 2:48 am |
| 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
| |
| Michael Metcalf 2005-07-07, 2:48 am |
|
<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
| |
| glen herrmannsfeldt 2005-07-07, 2:48 am |
| 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
| |
| Michael Metcalf 2005-07-07, 2:48 am |
|
"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
| |
| glen herrmannsfeldt 2005-07-07, 7:55 am |
| 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
| |
| Bryan.Berns@gmail.com 2005-07-07, 8:49 pm |
| 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
| |
| glen herrmannsfeldt 2005-07-07, 8:49 pm |
| 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
| |
| robert.corbett@sun.com 2005-07-13, 2:48 am |
| 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
| |
| Richard E Maine 2005-07-21, 6:02 pm |
| 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
| |
| Bryan.Berns@gmail.com 2005-07-23, 5:50 pm |
| 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.
| |
| Bryan.Berns@gmail.com 2005-07-23, 5:50 pm |
| 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.
| |
| glen herrmannsfeldt 2005-07-23, 9:06 pm |
| Bryan.Berns@gmail.com wrote:
> 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=real:64,double:128,i_nteger:32.
> But allocation wise it implies:
> xtypemap=real:64,double:128,i_nteger:64[
/vbcol]
Yes, Fortran tends to require that the default INTEGER and default REAL
have the same size as far as allocation. You will quickly notice if
you EQUIVALENCE between REAL and INTEGER arrays.
[vbcol=seagreen]
> 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=8 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].
The alignment, however it is done, should be consistent as long as all
routines are compiled with the same options. x86 processors don't
require alignment but often are faster with aligned data. The
tradition of COMMON was that no alignment padding was allowed. The best
way to help with alignment is to put all variables with more strict
alignment requirements before those with less strict requirements.
> I know there was xtypemap=integer:mixed but I have no idea what that
> does and it's be obseleted in the latest compiler.
I don't know what it would do, either, but it doesn't sound good
in any case.
-- glen
| |
| Tim Prince 2005-07-23, 9:06 pm |
| Bryan.Berns@gmail.com wrote:
> 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=real:64,double:128,i_nteger:32.
>
> But allocation wise it implies:
> xtypemap=real:64,double:128,i_nteger: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=8 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=integer:mixed but I have no idea what that
> does and it's be obseleted in the latest compiler.
>
I've long lost sight of which compiler you have in mind, if you ever did
specify which compiler is "the" compiler for you. Most f90 compilers
have options to widen default integer, if that is what you are looking
for.
|
|
|
|
|