[Bug fortran/42568] New: BLOCKDATA referenced in EXTERNAL not loading from library

[Bug fortran/42568] New: BLOCKDATA referenced in EXTERNAL not loading from library

[urbanjost at comcast dot net]

Even though the BLOCKDATA is referenced with an EXTERNAL statement, it is
not initializing the COMMON; this worked in previous versions of gfortran,
and g95, g77, ifort, and vendor compilers (Cray, HP-UX, IRIX64, SunOS, Solaris,
...) as long as the EXTERNAL statement was present.


#!/bin/sh
echo trouble loading a blockdata from a library
set -x
cat >missingBlockData.f <<\EOF
      program missingBlockData
      external juinit2
      character chars(5)*(20)
      common /qindex2/chars 
      save /qindex2/
      write(*,*)'chars=',chars
      if(chars(5).ne.'abcdefghijklmnopqrst')then
         write(*,*)'*missingBlockData* E-R-R-O-R: bad load'
      else
         write(*,*)'*missingBlockData* loaded common block'
      endif
      end
EOF
cat >juinit2.f <<\EOF
!______________________________________________________________________-
      blockdata juinit2
      character chars(5)*(20)
      common /qindex2/chars 
      save /qindex2/
      data chars/5*'abcdefghijklmnopqrst'/
      end
!______________________________________________________________________-
EOF
(
exec 2>&1
set -x
: __________________________________________________________
export F90
F90='gfortran -Wall'
: "compile with $F90"
: __________________________________________________________
: Make libex.a library
$F90  -c  juinit2.f 
nm juinit2.o
: I thought JUINIT2 would be a T, not a B ??
ar rv libex.a juinit2.o
rm juinit2.o
: __________________________________________________________
: run loading from library
rm -f missingBlockData
$F90 missingBlockData.f -L. -lex -o missingBlockData
./missingBlockData
: __________________________________________________________
: run not loading from library
rm -f missingBlockData
$F90 missingBlockData.f juinit2.f -o missingBlockData
./missingBlockData
: __________________________________________________________
: version
date
uname -a
$F90 -v missingBlockData.f juinit2.f -o missingBlockData
: __________________________________________________________
: cleanup
rm -f missingBlockData libex.a juinit2.f missingBlockData.f
) >> $0
exit 


***************
***************
RESULTS OF RUN:
***************
***************

+ set -x
+ : __________________________________________________________
+ export F90
+ F90=gfortran -Wall
+ : compile with gfortran -Wall
+ : __________________________________________________________
+ : Make libex.a library
+ gfortran -Wall -c juinit2.f
+ nm juinit2.o
00000000 b .bss
00000000 d .data
00000000 t .text
00000000 B _juinit2_
00000000 D _qindex2_
+ : I thought JUINIT2 would be a T, not a B ??
+ ar rv libex.a juinit2.o
ar: creating libex.a
a - juinit2.o
+ rm juinit2.o
+ : __________________________________________________________
+ : run loading from library
+ rm -f missingBlockData
+ gfortran -Wall missingBlockData.f -L. -lex -o missingBlockData
+ ./missingBlockData
 chars=
missingBlockData* E-R-R-O-R: bad load
+ : __________________________________________________________
+ : run not loading from library
+ rm -f missingBlockData
+ gfortran -Wall missingBlockData.f juinit2.f -o missingBlockData
+ ./missingBlockData

chars=abcdefghijklmnopqrstabcdefghijklmnopqrstabcdefghijklmnopqrstabcdefghijklmnopqrstabcdefghijklmnopqrst
 *missingBlockData* loaded common block
+ : __________________________________________________________
+ : version
+ date
Thu Dec 31 17:39:18 EST 2009
+ uname -a
CYGWIN_NT-6.0 urbanjs-PC 1.7.1(0.218/5/3) 2009-12-07 11:48 i686 Cygwin
+ gfortran -Wall -v missingBlockData.f juinit2.f -o missingBlockData
Driving: gfortran -Wall -v missingBlockData.f juinit2.f -o missingBlockData
-lgfortran
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/cygdrive/c/cygwin_install_files/gfortran/bin/../libexec/gcc/i686-pc-cygwin/4.5.0/lto-wrapper.exe
Target: i686-pc-cygwin
Configured with: ../trunk/configure --prefix=/usr/local/gfortran
--enable-languages=c,c++,fortran --disable-bootstrap --enable-threads=posix
--enable-sjlj-exceptions --enable-version-specific-runtime-libs --enable-nls
--disable-libmudflap --disable-shared --disable-win32-registry
--with-system-zlib --enable-checking=release --enable-werror
--without-included-gettext --without-x --enable-libgomp
Thread model: posix
gcc version 4.5.0 20091119 (experimental) [trunk revision 152402] (GCC) 
COLLECT_GCC_OPTIONS='-Wall' '-v' '-o' 'missingBlockData.exe' '-mtune=generic'

/cygdrive/c/cygwin_install_files/gfortran/bin/../libexec/gcc/i686-pc-cygwin/4.5.0/f951.exe
missingBlockData.f -ffixed-form -quiet -dumpbase missingBlockData.f
-mtune=generic -auxbase missingBlockData -Wall -version
-fintrinsic-modules-path
/cygdrive/c/cygwin_install_files/gfortran/bin/../lib/gcc/i686-pc-cygwin/4.5.0/finclude
-o /cygdrive/c/Users/urbanjs/AppData/Local/Temp/ccWoGlsE.s
GNU Fortran (GCC) version 4.5.0 20091119 (experimental) [trunk revision 152402]
(i686-pc-cygwin)
        compiled by GNU C version 4.3.4 20090804 (release) 1, GMP version
4.3.1, MPFR version 2.4.1-p5, MPC version 0.8
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU Fortran (GCC) version 4.5.0 20091119 (experimental) [trunk revision 152402]
(i686-pc-cygwin)
        compiled by GNU C version 4.3.4 20090804 (release) 1, GMP version
4.3.1, MPFR version 2.4.1-p5, MPC version 0.8
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
COLLECT_GCC_OPTIONS='-Wall' '-v' '-o' 'missingBlockData.exe' '-mtune=generic'
 as -o /cygdrive/c/Users/urbanjs/AppData/Local/Temp/cc83xpoo.o
/cygdrive/c/Users/urbanjs/AppData/Local/Temp/ccWoGlsE.s
COLLECT_GCC_OPTIONS='-Wall' '-v' '-o' 'missingBlockData.exe' '-mtune=generic'

/cygdrive/c/cygwin_install_files/gfortran/bin/../libexec/gcc/i686-pc-cygwin/4.5.0/f951.exe
juinit2.f -ffixed-form -quiet -dumpbase juinit2.f -mtune=generic -auxbase
juinit2 -Wall -version -fintrinsic-modules-path
/cygdrive/c/cygwin_install_files/gfortran/bin/../lib/gcc/i686-pc-cygwin/4.5.0/finclude
-o /cygdrive/c/Users/urbanjs/AppData/Local/Temp/ccWoGlsE.s
GNU Fortran (GCC) version 4.5.0 20091119 (experimental) [trunk revision 152402]
(i686-pc-cygwin)
        compiled by GNU C version 4.3.4 20090804 (release) 1, GMP version
4.3.1, MPFR version 2.4.1-p5, MPC version 0.8
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU Fortran (GCC) version 4.5.0 20091119 (experimental) [trunk revision 152402]
(i686-pc-cygwin)
        compiled by GNU C version 4.3.4 20090804 (release) 1, GMP version
4.3.1, MPFR version 2.4.1-p5, MPC version 0.8
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
COLLECT_GCC_OPTIONS='-Wall' '-v' '-o' 'missingBlockData.exe' '-mtune=generic'
 as -o /cygdrive/c/Users/urbanjs/AppData/Local/Temp/cc06kxQY.o
/cygdrive/c/Users/urbanjs/AppData/Local/Temp/ccWoGlsE.s
COMPILER_PATH=/cygdrive/c/cygwin_install_files/gfortran/bin/../libexec/gcc/i686-pc-cygwin/4.5.0/:/cygdrive/c/cygwin_install_files/gfortran/bin/../libexec/gcc/
LIBRARY_PATH=/cygdrive/c/cygwin_install_files/gfortran/bin/../lib/gcc/i686-pc-cygwin/4.5.0/:/cygdrive/c/cygwin_install_files/gfortran/bin/../lib/gcc/:/cygdrive/c/cygwin_install_files/gfortran/bin/../lib/gcc/i686-pc-cygwin/4.5.0/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-Wall' '-v' '-o' 'missingBlockData.exe' '-mtune=generic'

/cygdrive/c/cygwin_install_files/gfortran/bin/../libexec/gcc/i686-pc-cygwin/4.5.0/collect2.exe
-Bdynamic --dll-search-prefix=cyg -tsaware -o missingBlockData.exe /lib/crt0.o
/cygdrive/c/cygwin_install_files/gfortran/bin/../lib/gcc/i686-pc-cygwin/4.5.0/crtbegin.o
-L/cygdrive/c/cygwin_install_files/gfortran/bin/../lib/gcc/i686-pc-cygwin/4.5.0
-L/cygdrive/c/cygwin_install_files/gfortran/bin/../lib/gcc
-L/cygdrive/c/cygwin_install_files/gfortran/bin/../lib/gcc/i686-pc-cygwin/4.5.0/../../..
/cygdrive/c/Users/urbanjs/AppData/Local/Temp/cc83xpoo.o
/cygdrive/c/Users/urbanjs/AppData/Local/Temp/cc06kxQY.o -lgfortran -lgcc
-lcygwin -luser32 -lkernel32 -ladvapi32 -lshell32 -lgcc
/cygdrive/c/cygwin_install_files/gfortran/bin/../lib/gcc/i686-pc-cygwin/4.5.0/crtend.o
+ : __________________________________________________________
+ : cleanup
+ rm -f missingBlockData libex.a juinit2.f missingBlockData.f


-- 
           Summary: BLOCKDATA referenced in EXTERNAL not loading from
                    library
           Product: gcc
           Version: 4.5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: urbanjost at comcast dot net


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568

[Bug fortran/42568] BLOCKDATA referenced in EXTERNAL not loading from library

[kargl at gcc dot gnu dot org]

------- Comment #1 from kargl at gcc dot gnu dot org  2010-01-01 00:46 -------
Can you please read how to submit a bug report?  I can't
find anywhere were it states that a Bourne shell script
should be submitted.  It simply makes it almost impossible
to read the actual bug report.  In fact, all the crap with 
nm and ar is just unneeded cluttered.

% gfc4x -c a2.f90
% ar -cur libex.a a2.o
% gfc4x -o z a1.f90 -L. -lex
% ./z
 chars=abcdefghijklmnopqrst<remainder deleted>
 *missingBlockData* loaded common block
% gfc4x -c a2.f90 a1.f90
% ./z
 chars=abcdefghijklmnopqrst<remainder deleted>
 *missingBlockData* loaded common block
% gfortran44 -c a2.f90
% ar -cur libex.a a2.o
% gfortran44 -o z a1.f90 -L. -lex
% ./z
 chars=abcdefghijklmnopqrst<remainder deleted>
 *missingBlockData* loaded common block
% gfortran44 -o z a1.f90 a2.f90
% ./z
 chars=abcdefghijklmnopqrst<remainder deleted>
 *missingBlockData* loaded common block

Appears to work for me.  Where did you get your copy of 
gfortran?


-- 

kargl at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568

[Bug fortran/42568] BLOCKDATA referenced in EXTERNAL not loading from library

[urbanjost at comcast dot net]

------- Comment #2 from urbanjost at comcast dot net  2010-01-01 01:57 -------
Subject: Re:  BLOCKDATA referenced in EXTERNAL not loading from library

I just got it from the gfortran Wiki because of problems with the previous 
version I had:
http://gcc.gnu.org/wiki/GFortranBinaries
 then the "CygWin" version, which appears to point to
http://quatramaran.ens.fr/~coudert/gfortran/gfortran-4.5-Cygwin-i686.tar.bz2
today, anyway.

 I guess tastes vary.
We preferred shell scripts when I worked at Cray, HP, SGI, Compaq, and 
Digital;
as you otherwise don't know which compiler switches, system level, and so on 
were
used..

It works for me on several Linux boxes as well, just not CygWin. What 
platform are you on? I'm curious
if you do a nm on your libex.a file if juinit2 is type T or B;  I haven't 
used a non-Unix/GNU
machine for so many years (except for CygWin) I guess it didn't occur to me 
a shell script
would be harder, not easier, to use. Some examples in the Wiki of "ideal" 
bug reports would
be useful.

Note I just upgraded my CygWin a few days ago, to version 1.7; as X11 
windows were not working.
I have built the program I extracted the problem from many times in the past 
with older GFORTRAN
versions
(and G77 and G95) on CygWin; but a recent Vista upgrade broke CygWin (the 
X11 windows
were a bit fragile on Vista anyway). It still builds with G95, and an older 
version still builds with G77.

PS: I found it surprising that if I just compiled the main program I didn't 
get a warning about
unsatisified external JUINIT2; I did with every other compiler I tried.  It 
was also odd that
if I put a no-op subroutine in the same file as the BLOCKDATA file and then 
called it from the main
program that the BLOCKDATA was then initialized properly.

----- Original Message ----- 
From: "kargl at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org>
To: <urbanjost@comcast.net>
Sent: Thursday, December 31, 2009 7:46 PM
Subject: [Bug fortran/42568] BLOCKDATA referenced in EXTERNAL not loading 
from library


>
>
> ------- Comment #1 from kargl at gcc dot gnu dot org  2010-01-01 
> 00:46 -------
> Can you please read how to submit a bug report?  I can't
> find anywhere were it states that a Bourne shell script
> should be submitted.  It simply makes it almost impossible
> to read the actual bug report.  In fact, all the crap with
> nm and ar is just unneeded cluttered.
>
> % gfc4x -c a2.f90
> % ar -cur libex.a a2.o
> % gfc4x -o z a1.f90 -L. -lex
> % ./z
> chars=abcdefghijklmnopqrst<remainder deleted>
> *missingBlockData* loaded common block
> % gfc4x -c a2.f90 a1.f90
> % ./z
> chars=abcdefghijklmnopqrst<remainder deleted>
> *missingBlockData* loaded common block
> % gfortran44 -c a2.f90
> % ar -cur libex.a a2.o
> % gfortran44 -o z a1.f90 -L. -lex
> % ./z
> chars=abcdefghijklmnopqrst<remainder deleted>
> *missingBlockData* loaded common block
> % gfortran44 -o z a1.f90 a2.f90
> % ./z
> chars=abcdefghijklmnopqrst<remainder deleted>
> *missingBlockData* loaded common block
>
> Appears to work for me.  Where did you get your copy of
> gfortran?
>
>
> -- 
>
> kargl at gcc dot gnu dot org changed:
>
>           What    |Removed                     |Added
> ----------------------------------------------------------------------------
>             Status|UNCONFIRMED                 |WAITING
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568
>
> ------- You are receiving this mail because: -------
> You reported the bug, or are watching the reporter. 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568

[Bug fortran/42568] BLOCKDATA referenced in EXTERNAL not loading from library

[kargl at gcc dot gnu dot org]

------- Comment #3 from kargl at gcc dot gnu dot org  2010-01-01 02:49 -------
(In reply to comment #2)
> Subject: Re:  BLOCKDATA referenced in EXTERNAL not loading from library
> 
> I just got it from the gfortran Wiki because of problems with the previous 
> version I had:
> http://gcc.gnu.org/wiki/GFortranBinaries
>  then the "CygWin" version, which appears to point to
> http://quatramaran.ens.fr/~coudert/gfortran/gfortran-4.5-Cygwin-i686.tar.bz2
> today, anyway.
> 
>  I guess tastes vary.
> We preferred shell scripts when I worked at Cray, HP, SGI, Compaq, and 
> Digital;
> as you otherwise don't know which compiler switches, system level, and so on 
> were used..

Then please attach the script to the bug report.  The web interface
to bugzilla and cut-n-paste plays havoc with whitespace, long lines,
etc.

> It works for me on several Linux boxes as well, just not CygWin. What 
> platform are you on?

FreeBSD on i686 and x86_64.

> I'm curious
> if you do a nm on your libex.a file if juinit2 is type T or B;

% nm libex.a

a2.o:
00000000 B juinit2_
00000000 D qindex2_

> I haven't  used a non-Unix/GNU
> machine for so many years (except for CygWin) I guess it didn't occur to me 
> a shell script
> would be harder, not easier, to use. Some examples in the Wiki of "ideal" 
> bug reports would
> be useful.

The ideal bug report is the shortest source code example that 
exhibits the problem, which you gave us.

The simplest command line used to compile the code that 
exhibits the problem.

If a data file or input is needed, the shortest such data
is desirable.

If the problem is an internal compiler error or segfault of
the compiler, include the last several lines that appear
on the terminal.

If it's a runtime problem, either give the abort message
or error message, or tell us what the expected output
should have been.

> Note I just upgraded my CygWin a few days ago, to version 1.7;

This is my suspicion.  There's a problem with the new cygwin.

> (and G77 and G95) on CygWin; but a recent Vista upgrade broke CygWin (the 
> X11 windows
> were a bit fragile on Vista anyway). It still builds with G95, and an older 
> version still builds with G77.
> 
> PS: I found it surprising that if I just compiled the main program I didn't 
> get a warning about >unsatisified external JUINIT2; I did with every other
> compiler I tried.

I don't know much about how BLOCK DATA and COMMON are implemented.
But, it looks like the compiler is simply eliminating the symbol
as dead code.

% gfc4x -o z a1.f
% nm z | grep -i juin
% nm a1.o
00000000 t MAIN__
         U _gfortran_compare_string
         U _gfortran_set_args
         U _gfortran_set_options
         U _gfortran_st_write
         U _gfortran_st_write_done
         U _gfortran_transfer_array
         U _gfortran_transfer_character
00000197 T main
00000060 r options.4.1509
00000019 C qindex2_

AFAIK, there is no constraint in the Standard that something
marked by EXTERNAL must be referenced.

> It was also odd that
> if I put a no-op subroutine in the same file as the BLOCKDATA file and then 
> called it from the main
> program that the BLOCKDATA was then initialized properly.

That is strange.  It seems to be a linker problem.  I suspect that
you may need to ping the cygwin guys.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568

[Bug fortran/42568] BLOCKDATA referenced in EXTERNAL not loading from library

[jvdelisle at gcc dot gnu dot org]

------- Comment #4 from jvdelisle at gcc dot gnu dot org  2010-01-01 06:22 -------
I tried the test case with Cygwin running on WinNT-4.0 and it works fine with
both 4.3.4 and 4.5.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568

[Bug fortran/42568] BLOCKDATA referenced in EXTERNAL not loading from library

[jvdelisle at gcc dot gnu dot org]

------- Comment #5 from jvdelisle at gcc dot gnu dot org  2010-01-01 06:35 -------
I forgot to mention I am using Cygwin 1.7, so this is beginning to look like
some sort of installation issue.  The gfortran version 4.5 I downloaded and
installed per the gfortran wiki.

The other possibility to consider is what version of Windows you are using.  I
notice some reports on the Cygwin list of Vista and Windows 7 bugs.  However,
these bugs are being actively worked.

Try using Cygwin setup.exe and select the reinstall option for gcc core and
gfortran.  Also install all updates that are coming in daily almost on cygwin
as the bugs are getting cleared.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568

[Bug fortran/42568] BLOCKDATA referenced in EXTERNAL not loading from library

[urbanjost at comcast dot net]

------- Comment #6 from urbanjost at comcast dot net  2010-01-02 07:50 -------
Subject: Re:  BLOCKDATA referenced in EXTERNAL not loading from library

I am using Vista. I reinstalled. No luck.

 I updated CygWin 1.7 again and did a reinstall on the developer package
and the base package; got the same result, so I used the "dummy procedure" 
kludge as a stop-gap so I  could test the rest of the code. It's about 
70,000
lines, mixes C and Fortran, uses the X11 library, has an interpreter built 
into it  ... so it's not trivial and it seems to be running fine otherwise 
(there is
a basic four-hour suite of tests and it passed).  I was pleasantly surprised 
by this.  By the way, I found several mentions of similar problems on Mac OS 
and
other places dating mostly around 2007 on the Web. Since no one else can 
reproduce this so far, and it works fine on Linux platforms and there are
many work-arounds possible I can understand this being dropped for now if 
you see fit to do so.

If anyone else can reproduce this or has any tests they want me to run on my 
platform let me know. I attached something very similar to the original
test code. If I add a dummy routine in the "blockdata" file; and a "call 
dummy()" everything loads properly. Otherwise, it runs with g77 and g95, but
fails with 4.5.0 and 4.4.3 (which it used to work with) so it seems more and 
more like something is wrong with the loader, not gfortran per-se.

Does anyone know off the bat why G77 and G95 would work and GFORTRAN would 
not?

----- Original Message ----- 
From: "jvdelisle at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org>
To: <urbanjost@comcast.net>
Sent: Friday, January 01, 2010 1:35 AM
Subject: [Bug fortran/42568] BLOCKDATA referenced in EXTERNAL not loading 
from library


>
>
> ------- Comment #5 from jvdelisle at gcc dot gnu dot org  2010-01-01 
> 06:35 -------
> I forgot to mention I am using Cygwin 1.7, so this is beginning to look 
> like
> some sort of installation issue.  The gfortran version 4.5 I downloaded 
> and
> installed per the gfortran wiki.
>
> The other possibility to consider is what version of Windows you are 
> using.  I
> notice some reports on the Cygwin list of Vista and Windows 7 bugs. 
> However,
> these bugs are being actively worked.
>
> Try using Cygwin setup.exe and select the reinstall option for gcc core 
> and
> gfortran.  Also install all updates that are coming in daily almost on 
> cygwin
> as the bugs are getting cleared.
>
>
> -- 
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568
>
> ------- You are receiving this mail because: -------
> You reported the bug, or are watching the reporter. 


------- Comment #7 from urbanjost at comcast dot net  2010-01-02 07:50 -------
Created an attachment (id=19444)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19444&action=view)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568

[Bug fortran/42568] BLOCKDATA referenced in EXTERNAL not loading from library

[jvdelisle at gcc dot gnu dot org]

------- Comment #8 from jvdelisle at gcc dot gnu dot org  2010-01-04 03:25 -------
OK, I could not get the script to run for some reason.

However, I manually performed the steps in the script:

   gfortran-4 -c juinit2.f 
   ar -r libex.a juinit2.o
   gfortran-4 bug.f -L. -lex -o bug
   ./bug

and I get the bad result.  Doing this with g77 works fine.  The issue seems
related to trying to use juinit2.o from the created library libex.a

Sorry this took me a while to see what this was about.  I resproduced this
problem on Cygwin.  I have not tried on Linux yet.


-- 

jvdelisle at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|0000-00-00 00:00:00         |2010-01-04 03:25:21
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568

[Bug fortran/42568] BLOCKDATA referenced in EXTERNAL not loading from library

[jvdelisle at gcc dot gnu dot org]

------- Comment #9 from jvdelisle at gcc dot gnu dot org  2010-01-04 03:40 -------
With Linux:

$ ./bug1.sh 
ar: creating libex.a
COMPILER g77
 GOOD LOAD ix2(4)=abcdefghijklmnopqrst
ar: creating libex.a
COMPILER g95
 GOOD LOAD ix2(4)=abcdefghijklmnopqrst
ar: creating libex.a
COMPILER gfortran
 GOOD LOAD ix2(4)=abcdefghijklmnopqrst
ar: creating libex.a
COMPILER gfc
 GOOD LOAD ix2(4)=abcdefghijklmnopqrst

gfc is gfortran-4.5.0 experimental
gfortran is gfortran-4.4.1

The problem appears to be target specific, Cygwin


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568

[Bug fortran/42568] BLOCKDATA referenced in EXTERNAL not loading from library

[jvdelisle at gcc dot gnu dot org]

------- Comment #10 from jvdelisle at gcc dot gnu dot org  2010-01-04 03:52 -------
Fixed the script on Cygwin:

$ ./bug1.sh
ar: creating libex.a
COMPILER gfortran-4
 BAD LOAD ix2(4)=
ar: creating libex.a
COMPILER gfc
 BAD LOAD ix2(4)=
ar: creating libex.a
COMPILER g77
 GOOD LOAD ix2(4)=abcdefghijklmnopqrst


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568

[Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library

[burnus at gcc dot gnu dot org]

------- Comment #11 from burnus at gcc dot gnu dot org  2010-01-04 09:44 -------
Mark as new as Jerry has confirmed it. Jerry, do you see whether this is a
regression? From comment 0: "this worked in previous versions of gfortran"

It would be useful to know in which version it still worked. Does MinGW work?

Christopher, Dave: Do you have an idea what goes wrong?


-- 

burnus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |davek at gcc dot gnu dot
                   |                            |org, cgf at gcc dot gnu dot
                   |                            |org
             Status|WAITING                     |NEW
     Ever Confirmed|0                           |1
           Keywords|                            |wrong-code
   Last reconfirmed|2010-01-04 03:25:21         |2010-01-04 09:44:03
               date|                            |
            Summary|BLOCKDATA referenced in     |[Cygwin] BLOCKDATA
                   |EXTERNAL not loading from   |referenced in EXTERNAL not
                   |library                     |loading from library


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568

[Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library

[davek at gcc dot gnu dot org]

------- Comment #12 from davek at gcc dot gnu dot org  2010-01-04 15:42 -------
COMMON symbols don't cause members to be pulled in from library archives.  You
can omit "-L. -lex" from the final link altogether and get the same result:
it's unused.  So the reference from bug.o to _jindx2 doesn't cause the library
archive member to be drawn into the final link.

With g77, there's this additional undefined symbol _juinit2_ in bug.o, which is
not common, and hence causes the libex.a(juinit2.o) member to be drawn into the
final link, at which time the explicit definition of _jindx2 overrides the
common definition.  gfortran doesn't generate any reference to _juinit2_ when
it is used to compile bug.f, so there is nothing left to pull the archive
member into the final link.

The reference to _juinit2_ that g77 generates while compiling bug.f but
gfortran does not generate has a label associated with it that suggests very
strongly that g77 was aware of the problem that common symbols don't pull in
lib archive members and uses this reference to an associated non-common symbol
deliberately to solve the problem:

        .file   "bug.f"
        .data
        .align 4
___g77_forceload_0.0:
        .long   _juinit2_

The "forceload" bit seems highly suggestive.  Does gfortran need to adopt this
part of g77's mechanism?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568

[Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library

[dominiq at lps dot ens dot fr]

------- Comment #13 from dominiq at lps dot ens dot fr  2010-01-04 16:05 -------
The test fails also on *-apple-darwin9, but not on x86_64-apple-darwin10.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568

[Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library

[kargl at gcc dot gnu dot org]

------- Comment #14 from kargl at gcc dot gnu dot org  2010-01-04 16:13 -------
(In reply to comment #12)
> COMMON symbols don't cause members to be pulled in from library archives.  You
> can omit "-L. -lex" from the final link altogether and get the same result:
> it's unused.  So the reference from bug.o to _jindx2 doesn't cause the library
> archive member to be drawn into the final link.
> 

Comment #1 seems to contradict your assertion here.  To repeat, 

laptop:kargl[207] gfc4x -c a2.f
laptop:kargl[208] ar -cru libex.a a2.o
laptop:kargl[209] gfc4x -o z a1.f -L. -lex
laptop:kargl[210] ./z
 chars=abcdeabcdeabcdeabcdeabcde
 *missingBlockData* loaded common block


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568

[Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library

[davek at gcc dot gnu dot org]

------- Comment #15 from davek at gcc dot gnu dot org  2010-01-04 16:36 -------
(In reply to comment #14)
> (In reply to comment #12)
> > COMMON symbols don't cause members to be pulled in from library archives.  You
> > can omit "-L. -lex" from the final link altogether and get the same result:
> > it's unused.  So the reference from bug.o to _jindx2 doesn't cause the library
> > archive member to be drawn into the final link.
> > 
> 
> Comment #1 seems to contradict your assertion here.  To repeat, 
> 
> laptop:kargl[207] gfc4x -c a2.f
> laptop:kargl[208] ar -cru libex.a a2.o
> laptop:kargl[209] gfc4x -o z a1.f -L. -lex
> laptop:kargl[210] ./z
>  chars=abcdeabcdeabcdeabcdeabcde
>  *missingBlockData* loaded common block

I can't tell anything from that.  What is gfc4x, and what are a1.f and a2.f?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568

[Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library

[kargl at gcc dot gnu dot org]

------- Comment #16 from kargl at gcc dot gnu dot org  2010-01-04 17:13 -------
(In reply to comment #15)
> (In reply to comment #14)
> > (In reply to comment #12)
> > > COMMON symbols don't cause members to be pulled in from library archives.  You
> > > can omit "-L. -lex" from the final link altogether and get the same result:
> > > it's unused.  So the reference from bug.o to _jindx2 doesn't cause the library
> > > archive member to be drawn into the final link.
> > > 
> > 
> > Comment #1 seems to contradict your assertion here.  To repeat, 
> > 
> > laptop:kargl[207] gfc4x -c a2.f
> > laptop:kargl[208] ar -cru libex.a a2.o
> > laptop:kargl[209] gfc4x -o z a1.f -L. -lex
> > laptop:kargl[210] ./z
> >  chars=abcdeabcdeabcdeabcdeabcde
> >  *missingBlockData* loaded common block
> 
> I can't tell anything from that.  What is gfc4x, and what are a1.f and a2.f?

gfc4x is gfortran 4.5.

a1.f is OP's main program with the character(len=20)
replaced by character(len=5) to prevent screen wrap
on output.

a2.f is OP's block data file.

laptop:kargl[205] cat a1.f a2.f
      !
      ! File a1.f
      !
      program missingBlockData
      external juinit2
      character chars(5)*(5)
      common /qindex2/chars 
      save /qindex2/
      write(*,*)'chars=',chars
      if(chars(5).ne.'abcde')then
         write(*,*)'*missingBlockData* E-R-R-O-R: bad load'
      else
         write(*,*)'*missingBlockData* loaded common block'
      endif
      end
      !
      ! File a2.f
      !
      block data juinit2
      character chars(5)*(5)
      common /qindex2/chars 
      save /qindex2/
      data chars/5*'abcde'/
      end

You made an unmerited assertion that "COMMON symbols don't cause
members to be pulled in from library archives."  I've shown the 
counter example.  This appears to be linker issue on cygwin.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568

[Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library

[davek at gcc dot gnu dot org]

------- Comment #17 from davek at gcc dot gnu dot org  2010-01-04 18:05 -------
(In reply to comment #16)

> You made an unmerited assertion that "COMMON symbols don't cause
> members to be pulled in from library archives."  I've shown the 
> counter example.  

  On what platform?

> This appears to be linker issue on cygwin.

It appears to be the entirely correct behaviour of the linker on PE-COFF
platforms; I don't know about ELF platforms, which may well behave differently.
 Why do you supposed the "forceload" mechanism existed in g77 if not to allow
the compiler to generate code that worked regardless of the target object
format?

See here: http://www.airs.com/blog/archives/48 

>"In general the linker will not include archives if they provide a definition for a common symbol."

Isn't that what's going on here?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568

[Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library

[davek at gcc dot gnu dot org]

------- Comment #18 from davek at gcc dot gnu dot org  2010-01-04 18:06 -------
http://sources.redhat.com/bugzilla/show_bug.cgi?id=1811 also looks pertinent.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568

[Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library

[kargl at gcc dot gnu dot org]

------- Comment #19 from kargl at gcc dot gnu dot org  2010-01-04 18:56 -------
(In reply to comment #17)
> (In reply to comment #16)
> 
> > You made an unmerited assertion that "COMMON symbols don't cause
> > members to be pulled in from library archives."  I've shown the 
> > counter example.  
> 
>   On what platform?

FreeBSD.  Yes, it's an ELF platform.  For the record, the behavior
as I've shown occurs with GNU ld.

% ld --version
GNU ld version 2.15 [FreeBSD] 2004-05-23


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568

[Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library

[jvdelisle at gcc dot gnu dot org]

------- Comment #20 from jvdelisle at gcc dot gnu dot org  2010-01-05 03:01 -------
I have read through the links given by Dave.  My take is that we have some
implementation dependent, non portable, behaviour in linkers.  Now that we know
we have this inconsistency, the question is do we want to fix this with a work
around in gfortran?

>From my read, there are situations where this is not desired behaviour. 
Obviously linux/Gnu is doing it. If so, exactly how is this done?  Should it be
handled by Cygwin? (by the linker?)

Dave, do you know how to emit the forceload and just exactly what is this?

What to do? and who?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568

[Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library

[burnus at gcc dot gnu dot org]

------- Comment #21 from burnus at gcc dot gnu dot org  2010-01-05 14:46 -------
(In reply to comment #20)
> Dave, do you know how to emit the forceload and just exactly what is this?

g77 does it as shown in
http://gcc.gnu.org/viewcvs/branches/gcc-3_4-branch/gcc/f/com.c?view=markup


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568

[Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library

[ian at airs dot com]

------- Comment #22 from ian at airs dot com  2010-01-05 16:09 -------
For ELF, when the GNU linker has seen a common symbol, and then sees that
symbol in the archive map, it will look in the object to see whether the object
defines the symbol (rather than simply providing another common definition). 
If the object does define the symbol, then it is pulled into the link.  See
http://sourceware.org/ml/binutils/1999-12/msg00015.html .  This was done for
compatibility with the SunOS and HP/UX linkers, but in retrospect I think it
may have been a mistake.

For the PE target used on cygwin, the GNU linker does not do this.  It follows
the simpler rule.  For that matter, the gold linker also does not do this.

So, yes, the linkers behave differently.  If you need to provide a common
definition, and you also need to force that common definition to pull in a
definition from an archive, then the compiler should arrange for that to
happen.  The easy way is: whenever you have a definition, also define some
other symbol.  Whenever you have a common symbol, also include an undefined
reference to that definition.


-- 

ian at airs dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ian at airs dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568

[Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library

[dominiq at lps dot ens dot fr]

------- Comment #23 from dominiq at lps dot ens dot fr  2010-01-05 18:12 -------
This looks like a duplicate of pr34136.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568

[Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library

[kargl at gcc dot gnu dot org]

------- Comment #24 from kargl at gcc dot gnu dot org  2010-01-16 23:18 -------
Fixed in trunk.


-- 

kargl at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568

[Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library

[kargl at gcc dot gnu dot org]

------- Comment #25 from kargl at gcc dot gnu dot org  2010-01-16 23:47 -------
Re-open.  Sorry guys, wrong PR.


-- 

kargl at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WONTFIX                     |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568