[Bug fortran/50149] loader error with source containing common blocks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50149 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #5 from Dominique d'Humieres --- Closing as WORKSFORME.
[Bug fortran/50149] loader error with source containing common blocks
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50149
--- Comment #3 from Behzad Salimi 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
wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50149
>
> Tobias Burnus changed:
>
> What |Removed |Added
>
> CC| |burnus at gcc dot gnu.org
>
> --- Comment #1 from Tobias Burnus 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:
> 0008 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50149 --- Comment #2 from Dominique d'Humieres 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50149
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #1 from Tobias Burnus 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:
0008 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
