* [Bug fortran/50149] loader error with source containing common blocks
2011-08-22 6:58 [Bug fortran/50149] New: loader error with source containing common blocks riddle00 at gmail dot com
@ 2011-08-22 13:52 ` burnus at gcc dot gnu.org
2011-08-22 14:07 ` dominiq at lps dot ens.fr
` (3 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: burnus at gcc dot gnu.org @ 2011-08-22 13:52 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 6+ messages in thread* [Bug fortran/50149] loader error with source containing common blocks
2011-08-22 6:58 [Bug fortran/50149] New: loader error with source containing common blocks riddle00 at gmail dot com
2011-08-22 13:52 ` [Bug fortran/50149] " burnus at gcc dot gnu.org
@ 2011-08-22 14:07 ` dominiq at lps dot ens.fr
2011-09-02 22:35 ` riddle00 at gmail dot com
` (2 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: dominiq at lps dot ens.fr @ 2011-08-22 14:07 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 6+ messages in thread* [Bug fortran/50149] loader error with source containing common blocks
2011-08-22 6:58 [Bug fortran/50149] New: loader error with source containing common blocks riddle00 at gmail dot com
2011-08-22 13:52 ` [Bug fortran/50149] " burnus at gcc dot gnu.org
2011-08-22 14:07 ` dominiq at lps dot ens.fr
@ 2011-09-02 22:35 ` riddle00 at gmail dot com
2011-09-02 23:01 ` kargl at gcc dot gnu.org
2013-06-29 21:32 ` dominiq at lps dot ens.fr
4 siblings, 0 replies; 6+ messages in thread
From: riddle00 at gmail dot com @ 2011-09-02 22:35 UTC (permalink / raw)
To: gcc-bugs
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.
>
^ permalink raw reply [flat|nested] 6+ messages in thread* [Bug fortran/50149] loader error with source containing common blocks
2011-08-22 6:58 [Bug fortran/50149] New: loader error with source containing common blocks riddle00 at gmail dot com
` (2 preceding siblings ...)
2011-09-02 22:35 ` riddle00 at gmail dot com
@ 2011-09-02 23:01 ` kargl at gcc dot gnu.org
2013-06-29 21:32 ` dominiq at lps dot ens.fr
4 siblings, 0 replies; 6+ messages in thread
From: kargl at gcc dot gnu.org @ 2011-09-02 23:01 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 6+ messages in thread* [Bug fortran/50149] loader error with source containing common blocks
2011-08-22 6:58 [Bug fortran/50149] New: loader error with source containing common blocks riddle00 at gmail dot com
` (3 preceding siblings ...)
2011-09-02 23:01 ` kargl at gcc dot gnu.org
@ 2013-06-29 21:32 ` dominiq at lps dot ens.fr
4 siblings, 0 replies; 6+ messages in thread
From: dominiq at lps dot ens.fr @ 2013-06-29 21:32 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 6+ messages in thread