[Bug fortran/50149] New: loader error with source containing common blocks

[Bug fortran/50149] New: loader error with source containing common blocks

[riddle00 at gmail dot com]

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

             Bug #: 50149
           Summary: loader error with source containing common blocks
    Classification: Unclassified
           Product: gcc
           Version: 4.6.1
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: riddle00@gmail.com


Computer: MacBook Pro
 System Version:    Mac OS X 10.6.8 (10K549)
  Kernel Version:    Darwin 10.8.0

gcc/gfortran version 4.6.1

compiler options used when compiling:
-c -Wall -fbacktrace  -static-libgfortran -fcheck-array-temporaries \
 -finit-local-zero -fno-automatic -fbounds-check -pg -fpic -fpie

Error encountered: all modules compile as expected; however, if any two source
routines contain COMMON statement, I encounter the following error immediately
at load time:

ld: duplicate symbol ___BLNK__ in obj/trajectory.o and obj/integral.o
collect2: ld returned 1 exit status

removing COMMON statements from sources will eliminate this error and all is
good!

I would appreciate a reply if/when this problem is fixed and a new version is
available.  Thanks very much.

[Bug fortran/50149] loader error with source containing common blocks

[burnus at gcc dot gnu.org]

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

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |burnus at gcc dot gnu.org

--- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-08-22 13:38:45 UTC ---
(In reply to comment #0)
>  System Version: Mac OS X 10.6.8 (10K549), Kernel Version: Darwin 10.8.0
> gcc/gfortran version 4.6.1
> 
> ld: duplicate symbol ___BLNK__ in obj/trajectory.o and obj/integral.o
> collect2: ld returned 1 exit status

As written, I cannot reproduce the problem on Linux. Can you create a minimal
example which reproduces this error and attach it, stating exactly the
command-line options you used?


For instance, the following example works for me on Linux with no special
options and with the options you used.

As expected, I get in the object files the blank common ("common // ..."),
namely "nm" shows the __BLNK__ symbol in both files:
  0000000000000008 C __BLNK__
However, as the "C" indicates, the data is in common and thus should not
produce any error message if it exists in multiple object files.

What do you get if you run "nm obj/trajectory.o |grep __BLNK__" and "nm
obj/integral.o |grep __BLNK__"?


! --------- file1.f90 ---------
subroutine foo
  integer :: i
  common // i
end subroutine foo

! --------- file2.f90 ---------
subroutine bar
  integer :: j
  common // j
end subroutine bar

call foo()
call bar()
end

[Bug fortran/50149] loader error with source containing common blocks

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2011-08-22 13:51:46 UTC ---
> For instance, the following example works for me on Linux with no special
> options and with the options you used.

It works also for me on x86_64-apple-darwin10.8.0 with 4.4.6, 4.5.3, 4.6.1, and
4.7.0 (trunk),
and Xcode Version: 3.2.6-1.

[Bug fortran/50149] loader error with source containing common blocks

[riddle00 at gmail dot com]

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

--- Comment #3 from Behzad Salimi <riddle00 at gmail dot com> 2011-09-02 22:34:27 UTC ---
Hello,

Thank you very much for your reply and help.

Your  example pointed me to the clue to find the error in my source:
evidently, a /name/ block is required even when the "name" is empty,
i.e., "common // ...", my source had "common i, j, k, ..." this is not
allowed!

What is surprising is that no compiler error or warning was generated
while the loader complained! I had expected to get a compiler error if
the "common /name/ ..." format is strictly required. Perhaps you could
make a note to cause a compiler error in your future distributions.

Problem is solved and I thank you very much for your assistance. You
can delete my original bug report as resolved and perhaps mark it as a
remark for a future compiler improvement.

Take care,
Behzad.

On Mon, Aug 22, 2011 at 6:38 AM, burnus at gcc dot gnu.org
<gcc-bugzilla@gcc.gnu.org> wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50149
>
> Tobias Burnus <burnus at gcc dot gnu.org> changed:
>
>           What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                 CC|                            |burnus at gcc dot gnu.org
>
> --- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-08-22 13:38:45 UTC ---
> (In reply to comment #0)
>>  System Version: Mac OS X 10.6.8 (10K549), Kernel Version: Darwin 10.8.0
>> gcc/gfortran version 4.6.1
>>
>> ld: duplicate symbol ___BLNK__ in obj/trajectory.o and obj/integral.o
>> collect2: ld returned 1 exit status
>
> As written, I cannot reproduce the problem on Linux. Can you create a minimal
> example which reproduces this error and attach it, stating exactly the
> command-line options you used?
>
>
> For instance, the following example works for me on Linux with no special
> options and with the options you used.
>
> As expected, I get in the object files the blank common ("common // ..."),
> namely "nm" shows the __BLNK__ symbol in both files:
>  0000000000000008 C __BLNK__
> However, as the "C" indicates, the data is in common and thus should not
> produce any error message if it exists in multiple object files.
>
> What do you get if you run "nm obj/trajectory.o |grep __BLNK__" and "nm
> obj/integral.o |grep __BLNK__"?
>
>
> ! --------- file1.f90 ---------
> subroutine foo
>  integer :: i
>  common // i
> end subroutine foo
>
> ! --------- file2.f90 ---------
> subroutine bar
>  integer :: j
>  common // j
> end subroutine bar
>
> call foo()
> call bar()
> end
>
> --
> Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You reported the bug.
>

[Bug fortran/50149] loader error with source containing common blocks

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kargl at gcc dot gnu.org
           Severity|major                       |normal

--- Comment #4 from kargl at gcc dot gnu.org 2011-09-02 23:00:54 UTC ---
(In reply to comment #3)
> Hello,
> 
> Thank you very much for your reply and help.
> 
> Your  example pointed me to the clue to find the error in my source:
> evidently, a /name/ block is required even when the "name" is empty,
> i.e., "common // ...", my source had "common i, j, k, ..." this is not
> allowed!

No, a /name/ block *IS NOT* required even when the name is empty.

troutmask:sgk[218] cat a.f90 b.f90 c.f90

! a.f90
subroutine foo
   common i
   i = 2
end subroutine foo

! b.f90
subroutine bar
   common j
   j = 1
end subroutine bar

! c.f90
program c
  common k
  call foo
  call bar
  print *, k
end program c

This compiles with gfortran 4.7.0 with all of the options
you specify.


> What is surprising is that no compiler error or warning was generated
> while the loader complained! I had expected to get a compiler error if
> the "common /name/ ..." format is strictly required. Perhaps you could
> make a note to cause a compiler error in your future distributions.

It's not required.  You have a broken loader, which is not
a gfortran problem.

[Bug fortran/50149] loader error with source containing common blocks

[dominiq at lps dot ens.fr]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |WORKSFORME

--- Comment #5 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Closing as WORKSFORME.