From: "Chan, Sun C" <sun.c.chan@xxxxxxxxx>
for the following two files:
! cat bm2.f
SUBROUTINE SETFM(IPAR)
IMPLICIT DOUBLE PRECISION(A-H,O-Z)
! IMPLICIT INTEGER(A-H,O-Z)
C
PARAMETER (MEMSIZ= 1750 000)
! PARAMETER (MEMSIZ= 3)
COMMON /FMCOM / X(MEMSIZ)
END
!cat bm1.f
PROGRAM bm
! IMPLICIT DOUBLE PRECISION(A-H,O-Z)
IMPLICIT INTEGER(A-H,O-Z)
COMMON /FMCOM / X(1)
END
on the nue native environment, for the a.out produced, readelf shows:
[25] .sbss NOBITS 6000000000015a00 000f5a00
0000000000d5a040 0000000000000000 WA 0 0 8
clearly the sbss overflowed. But the linker DID NOT report error.
The version of linker is 2.9 (000216)
With a newer linker: version 2.9 (000717)
I got:
ld: a.out: short data segment overflowed (0x5bafb8 >=
0x400000)
depending on the link order, i.e
the order "bm1.f bm2.f" give the above error.
the order "bm2.f bm1.f" does not.
the .s file generated has the following declaration for fmcom:
.common fmcom_#, 14000000, 8
I believe Pro64 is not the culprit here.
This definitely looks like a linker bug, as it is the linker that is
putting the resulting common in .sbss here.
I notice that it doesn't use sbss if both files have the large common size.
SGI folks, is this a known problem?
Not to me, though it may explain some similar weird problems we've
seen with gp overflow.
Also, appreciate any workaround or hints as to when Cygnus is fixing
this?
I suggest you contact cygnus/gcc directly, as they may be most
attentive to problems from Intel.
-- Mike Murphy
-- mpm@xxxxxxx
-- quote of the day:
-- "Compassion is sometimes the fatal capacity for feeling what it is like
-- inside somebody else's skin. It is the knowledge that there can never
-- really be any peace and joy for me until there is peace and joy finally
-- for you too." (Frederick Buechner)
|