[Bug fortran/34136] New: [g77 regression] Add entry point and symbol for linker

[Bug fortran/34136] New: [g77 regression] Add entry point and symbol for linker

[burnus at gcc dot gnu dot org]

As reported by Jack Howarth
http://gcc.gnu.org/ml/fortran/2007-11/msg00122.html

Analysis by Walter Spector:

a) http://gcc.gnu.org/ml/fortran/2007-11/msg00131.html

Ah - the old "put block data in a library, and use EXTERNAL to make sure
it gets linked in" trick.  Many compilers have gotten this wrong over
the years, because it is kinda on the edge of being required by the
Standard (any of them).

On my cygwin system, g77 and g95 get it right and gfortran gets it wrong.
See below.

While F90 modules fixed this problem by obsoleting BLOCK DATA and
COMMON, quite a number of older library packages depend on this working.

Walter


$ cat testsub.f
      SUBROUTINE TESTSUB
      EXTERNAL BDTEST
      COMMON/TEST/WK
      INTEGER WK
      PRINT *,'TESTSUB: WK = ',WK, '...it should be 20'
      RETURN
      END

$ g77 -c testsub.f
$ nm testsub.o
00000000 b .bss
00000000 d .data
00000000 r .rdata
00000000 t .text
00000004 d ___g77_cilist_0.1
00000000 d ___g77_forceload_0.0
         U _bdtest_               <<<< This references the BLOCK DATA
         U _do_lio
         U _e_wsle
         U _s_wsle
00000010 C _test_
00000000 T _testsub_

$ gfortran -c testsub.f
$ nm testsub.o
00000000 b .bss
00000000 d .data
00000000 r .rdata
00000000 t .text                 <<<< Missing a reference to _bdtest_ here
         U __gfortran_st_write
         U __gfortran_st_write_done
         U __gfortran_transfer_character
         U __gfortran_transfer_integer
00000010 C _test_
00000000 T _testsub_

***************************************************************++

b) http://gcc.gnu.org/ml/fortran/2007-11/msg00132.html

The other half of this issue is on the BLOCK DATA side.  There has to be
an entry point that the linker can find:

$ cat testbd.f
      BLOCKDATA BDTEST
      COMMON/TEST/WK
      INTEGER WK
      DATA WK/20/
      END
$ gfortran testbd.f -c
$ nm testbd.o
00000000 b .bss
00000000 d .data
00000000 t .text
00000000 B _bdtest_    <<<< gfortran creates a BSS section
00000000 D _test_
$ g77 -c testbd.f
$ nm testbd.o
00000000 b .bss
00000000 d .data
00000000 t .text
00000000 T _bdtest_    <<<< g77 creates a TEXT entry (even though no code
exists)
00000000 D _test_
$

Again, while there used to be debates about whether the Standard required
this to work, many older packages depend on it.


-- 
           Summary: [g77 regression] Add entry point and symbol for linker
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Keywords: wrong-code
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: burnus at gcc dot gnu dot org


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

[Bug fortran/34136] [g77 regression] Add entry point and symbol for linker

[w6ws at earthlink dot net]

------- Comment #1 from w6ws at earthlink dot net  2007-11-17 15:34 -------
First, the problem is described, and a full test case available, at:

    http://www.ncl.ucar.edu/Download/build_from_src.shtml#CompilersNeeded

Second, I am not sure if part b (changing the name from BSS to TEXT) is
strictly needed.  On my cygwin system, if I compile the block data with
gfortran (getting the BSS version), and the remainder of the test case with
g77, everything works fine.  However I can well imagine that linkers on other
architectures may work differently.


-- 

w6ws at earthlink dot net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |w6ws at earthlink dot net


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

[Bug fortran/34136] [regression against g77] Add entry point and symbol for linker

[howarth at nitro dot med dot uc dot edu]

------- Comment #2 from howarth at nitro dot med dot uc dot edu  2007-11-22 18:42 -------
Created an attachment (id=14610)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14610&action=view)
assembly file generated from testsub.f on i686-apple-darwin9


-- 


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

[Bug fortran/34136] [regression against g77] Add entry point and symbol for linker

[howarth at nitro dot med dot uc dot edu]

------- Comment #3 from howarth at nitro dot med dot uc dot edu  2007-11-22 18:45 -------
Created an attachment (id=14611)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14611&action=view)
assembly file generated from testsub.f on i386-redhat-linux (Fedora 8)


-- 


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

[Bug fortran/34136] [regression against g77] Add entry point and symbol for linker

[howarth at nitro dot med dot uc dot edu]

------- Comment #4 from howarth at nitro dot med dot uc dot edu  2007-11-22 18:47 -------
As requested by Mike Stump, i've uploaded the assembly files generated with -S
for the testsub.f source file of blockdata_test for both i686-apple-darwin9
(which fails to pass) and i386-redhat-linux (which passes the block data
tests).


-- 


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

[Bug fortran/34136] [regression against g77] Add entry point and symbol for linker

[howarth at nitro dot med dot uc dot edu]

------- Comment #5 from howarth at nitro dot med dot uc dot edu  2007-11-22 18:53 -------
Created an attachment (id=14613)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14613&action=view)
assembly file generated from testbd.f on i686-apple-darwin9


-- 


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

[Bug fortran/34136] [regression against g77] Add entry point and symbol for linker

[howarth at nitro dot med dot uc dot edu]

------- Comment #6 from howarth at nitro dot med dot uc dot edu  2007-11-22 18:54 -------
Created an attachment (id=14614)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14614&action=view)
assembly file generated from testbd.f on i386-redhat-linux (Fedora 8)


-- 


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

[Bug fortran/34136] [regression against g77] Add entry point and symbol for linker

[howarth at nitro dot med dot uc dot edu]

------- Comment #7 from howarth at nitro dot med dot uc dot edu  2007-11-22 18:55 -------
Added assembly files from testbd.f for i386-redhat-linux and
i686-apple-darwin9.


-- 


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

[Bug fortran/34136] [regression against g77] Add entry point and symbol for linker

[mrs at apple dot com]

------- Comment #8 from mrs at apple dot com  2007-11-26 20:58 -------
Apparently there are two distinct ways to make this work, either, output a
reference to bdtest, or ensure that the linker tries to resolve commons from
libraries.  Linux uses the later approach.  To be portable, gfortran needs to
generate the reference to bdtest on those platforms that need it.  Darwin would
be one such system.

I've filed

  radr://5613343 need to search for definitions for common symbols

so we won't need such help at some point.


-- 


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

[Bug fortran/34136] [regression against g77] Add entry point and symbol for linker

[howarth at nitro dot med dot uc dot edu]

------- Comment #9 from howarth at nitro dot med dot uc dot edu  2007-11-27 02:18 -------
Created an attachment (id=14644)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14644&action=view)
assembly file generated from testbd.f from g95 on i386-darwin9


-- 


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

[Bug fortran/34136] [regression against g77] Add entry point and symbol for linker

[howarth at nitro dot med dot uc dot edu]

------- Comment #10 from howarth at nitro dot med dot uc dot edu  2007-11-27 02:18 -------
Created an attachment (id=14645)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14645&action=view)
assembly file generated from testsub.f from g95 on i386-darwin9


-- 


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

[Bug fortran/34136] [regression against g77] Add entry point and symbol for linker

[howarth at nitro dot med dot uc dot edu]

------- Comment #11 from howarth at nitro dot med dot uc dot edu  2007-11-27 02:23 -------
In case this helps prove Mike's hypothesis of the alternate fix to this problem
(outside of the patching the darwin linker), I've uploaded the assembly files
for testbd.f and testsub.f generated on i386-apple-darwin9 with g95 0.90
compiled against a patched gcc 4.0.3. The blockdata_test all pass with g95 on
darwin. I should note that on Macintel we get warnings of the form...

g95 -o main.init main.o libtestinit.a
ld: warning for symbol _test_ tentative definition of size 16 from
libtestinit.a(testsub.o) is being replaced by a real definition of size 4 from
libtestinit.a(testbd.o)

and

g95 -o main.bad main.o libtest.a
ld: warning for symbol _test_ tentative definition of size 16 from
libtest.a(testsub.o) is being replaced by a real definition of size 4 from
libtest.a(testbd.o)

which I believe are due to intel darwin specific changes that were never
backported out of gcc 4.2 to gcc 4.0.x branch. However, I think these warnings
are non-critical.


-- 


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

[Bug fortran/34136] [regression against g77] Add entry point and symbol for linker

[mrs at apple dot com]

------- Comment #12 from mrs at apple dot com  2007-11-27 02:42 -------
Yes, the second set contains:

_U0.457:
        .long   _bdtest_

which is the part the makes the whole thing work on systems like darwin.


-- 


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

[Bug fortran/34136] [regression against g77] Add entry point and symbol for linker

[burnus at gcc dot gnu dot org]

------- Comment #13 from burnus at gcc dot gnu dot org  2007-11-27 09:48 -------
For testsub.f, g95 creates (for "EXTERNAL BDTEST"):
    static void * U0 = bdtest_;
which shows up as:
                 U bdtest_
same for ifort. While sunf95 and openf95 have bdtest_ in the dump.

And for the BLOCK DATA g95 creates:

bdtest_ ()
{
  static int4 wk;
}

whereas gfortran does not create any dumpable tree. The .o file of gfortran
contains:
0000000000000000 B bdtest_
whereas g95, ifort, sunf95, openf95 have:
0000000000000000 T bdtest_


-- 


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

[Bug fortran/34136] [regression against g77] Add entry point and symbol for linker

[howarth at nitro dot med dot uc dot edu]

------- Comment #14 from howarth at nitro dot med dot uc dot edu  2007-11-27 14:22 -------
Does anyone have access to other platforms to see if blocktest_data breaks when
compiled with gfortran on anything other than Darwin and Cywin?


-- 


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

[Bug fortran/34136] [regression against g77] Add entry point and symbol for linker

[burnus at gcc dot gnu dot org]

------- Comment #15 from burnus at gcc dot gnu dot org  2007-11-27 17:36 -------
(In reply to comment #13)
> For testsub.f, g95 creates (for "EXTERNAL BDTEST"):
>     static void * U0 = bdtest_;
> which shows up as:
>                  U bdtest_
> same for ifort. While sunf95 and openf95 have bdtest_ in the dump.

I meant: While sunf95 and openf95 do not have "bdtest_" in "nm *.o" at all.


-- 


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

[Bug fortran/34136] [regression against g77] Add entry point and symbol for linker

[howarth at nitro dot med dot uc dot edu]

------- Comment #16 from howarth at nitro dot med dot uc dot edu  2007-11-29 04:34 -------
It appears that the Darwin9 linker will be modified to handle this issue as the
linux linker does in the next Developer Tools update. However it is very
unlikely Darwin8's cctools will ever see such a fix. With that in mind, I would
be more than happy to test in any proposed patch for gcc trunk which would
cause the entry point for the common block to be emitted for testsub.f and
testbd.f so that Darwin8 can have the same effective functionality as Darwin9.


-- 


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

[Bug fortran/34136] Add entry point and symbol for linker

[jvdelisle at gcc dot gnu dot org]

------- Comment #17 from jvdelisle at gcc dot gnu dot org  2008-11-01 12:21 -------
Jack, did this problem go away on Darwin?


-- 

jvdelisle at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |howarth at nitro dot med dot
                   |                            |uc dot edu
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2008-11-01 12:21:11
               date|                            |


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

[Bug fortran/34136] Add entry point and symbol for linker

[dominiq at lps dot ens dot fr]

------- Comment #18 from dominiq at lps dot ens dot fr  2008-11-01 12:32 -------
I have run the tests in comment #1 and main.bad main.init still fail on
i686-apple-darwin9.


-- 


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

[Bug fortran/34136] Add entry point and symbol for linker

[dominiq at lps dot ens dot fr]

------- Comment #19 from dominiq at lps dot ens dot fr  2010-01-05 18:15 -------
pr42568 looks like a duplicate of this one.

Note that the issue seems fixed on darwin10.


-- 


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

[Bug fortran/34136] Add entry point and symbol for linker

[howarth at nitro dot med dot uc dot edu]

------- Comment #20 from howarth at nitro dot med dot uc dot edu  2010-01-05 18:27 -------
(In reply to comment #19)
> pr42568 looks like a duplicate of this one.
> 
> Note that the issue seems fixed on darwin10.
> 

This issue was radr://5613343 and has been fixed for darwin10 and later.


-- 


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

[Bug fortran/34136] Add entry point and symbol for linker

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

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

--- Comment #21 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> This issue was radr://5613343 and has been fixed for darwin10 and later.

Confirmed and it seems that it is also fixed by the latest version of Xcode for
darwin9. So I am closing this PR as FIXED leaving pr42568 open (WAITING) for
CYGWIN.