Mike,
I managed to suppress the linker warnings which occur with -m64 -g with
COMMON blocks
by applying the following patch...
--- gcc-4.2-20060822/gcc/testsuite/lib/prune.exp.org2006-08-23
18:33:56.0 -0400
+++ gcc-4.2-20060822/gcc/testsuite/lib/prune.exp2006-08-23
On Aug 23, 2006, at 4:57 PM, Jack Howarth wrote:
...which is quite nice since it is the same number of failures as
with -m32 with three additional unexpected passes.
Excellent. Nice to hear.
What I found was that I could set a breakpoint at assign.f90:1 but
when I tried to run the program
Mike,
As I mentioned before, the simple test case of...
program test
integer i
end
shows the following change in its .s file when the common i
is added...
--- assign.s.nocommon 2006-08-19 10:45:59.0 -0400
+++ assign.s2006-08-19 10:46:19.0 -0400
@@
On Aug 21, 2006, at 6:34 AM, Jack Howarth wrote:
I just wanted to be clear that you believe only the line...
+ .stabs i:G(0,3),32,0,4,0
in that .s file is incorrect
I never said that, let me refer you to my previous email for what I
said. I did say that it was causing the problem.
Mike,
Actually, while building tonight's svn pull, I noticed that the linker
warnings have actually been present during the linkage of libgfortran.dylib
for the -m64 part of the multilib build...
/bin/sh ./libtool --mode=link
On Aug 19, 2006, at 7:50 AM, Jack Howarth wrote:
I don't believe that this warning with -O3 -m64 -g is
due to the fortran compiler optimizing away the storage.
DId you read my previous emails on this topic? If not, please see
it, if you have, please read it again. I think there is a
On Aug 19, 2006, at 7:58 AM, Jack Howarth wrote:
...so even if i were being optimized away only ld64 seems to care.
Yes.
The ld 32-bit linker remains silent on the issue.
Yes.
Mike,
I don't believe that this warning with -O3 -m64 -g is
due to the fortran compiler optimizing away the storage.
If I compile...
program test
integer i,j
common i
do j = 1,100
i=i+1
end do
end
I still see the warning can't find atom for N_GSYM
Mike,
One other observation. The only differences in the .s
output for compiling...
program test
integer i
common i
end
...with -m32 and -m64 is...
--- assign_m32.s2006-08-19 10:53:33.0 -0400
+++ assign_m64.s2006-08-19 10:53:59.0 -0400
The bug hits about 38 other test in gfortran. These include...
FAIL: gfortran.dg/actual_array_constructor_1.f90 -O3 -g (test for excess
errors)
FAIL: gfortran.dg/assign.f90 -O3 -g (test for excess errors)
[...SNIP...]
Just in case, you can detect any sort of pattern from that set of
FX,
That was spot on. If I reduce the test case down to...
! { dg-do run }
! Program to test ASSIGNing a label to common variable. PR18827.
program test
integer i
common i
end
I still get the linkage error...
gfortran -O3 -g -m64 assign.f90
can't find atom for N_GSYM
On Aug 17, 2006, at 4:26 PM, Jack Howarth wrote:
I assume the linker is choking on the line...
.stabs i:G(0,3),32,0,4,0
...right?
Yes. The linker is complaining that there is no _i in the program.
If you add one, it would have worked. I'm asking our linker and
debugger people
On Aug 17, 2006, at 5:43 PM, Mike Stump wrote:
On Aug 17, 2006, at 4:26 PM, Jack Howarth wrote:
I assume the linker is choking on the line...
.stabs i:G(0,3),32,0,4,0
...right?
Yes. The linker is complaining that there is no _i in the program.
If you add one, it would have
14 matches
Mail list logo
