This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: Compilation error
- From: Janus Weil <janus at gcc dot gnu dot org>
- To: David Car <david dot car7 at gmail dot com>
- Cc: fortran at gcc dot gnu dot org
- Date: Fri, 4 Jun 2010 12:36:40 -0400
- Subject: Re: Compilation error
- References: <AANLkTinThx2sI9lv26GDhCB7DrIevhRywUK8Cpco55F8@mail.gmail.com> <AANLkTin5wBs2Du6NSIS4ykkjbsnz1c7lC3w_RzSCtTDj@mail.gmail.com> <AANLkTikFm-oxH83D5yNNoowuRJx-trgg2A47tYUN8PfG@mail.gmail.com> <AANLkTimL9QlZZaZJ893Bmo2lU_1BTo_VXkJhLwohj0Ly@mail.gmail.com>
Hi David,
> What I was asking with the below thread and simple example was whether
> I should see any "vtab$" type symbols in the resultant object code?
yes, you should. These 'vtab' thingies are inserted by gfortran. They
are used internally to implement polymorphism. So, yes, you should see
them in the object code, but once you start getting errors about them,
that clearly is a gfortran bug.
> The simple example compiled and worked, but I was really curious about
> that question which will atleast point me in a direction when trying
> to build a simple test case which reveals the bug. ?Thanks.
The most simple-minded strategy for reducing a test case is just to
remove pieces of the code, and see if the error still is there. Of
course you need to do this removal in such a way that the code still
makes sense (at least it should still be a valid Fortran program).
Remove as much as possible while keeping the error message and you
have your minimal test case.
If your code is not too big, I can try to help you with the reduction
process (if you don't want to post your code on a public mailing list,
you can just send it to me in private).
Cheers,
Janus
> On Thu, May 20, 2010 at 8:48 PM, David Car <david.car7@gmail.com> wrote:
>> Hi Janus,
>>
>> Thanks so much for the info (and thank you to the other postings too).
>>
>>> help you, but hopefully we will get this nasty bug fixed soon. If you
>>> want to help, it might be useful if you could isolate this bug in your
>>> code and construct a minimal test case. We already have a test case in
>>> PR 44064/65, but having another one might help us nail down the
>>> specific conditions under which this occurs.
>>
>> Definitely would like to help. ?I've tried to construct a minimal test
>> case that duplicates the build error but was unsuccessful. ?Listed
>> below is the case I tried that basically implements the same pattern:
>>
>> !====================================================
>> module test1
>> ?implicit none
>>
>> ?type foo
>> ? ? integer :: i1
>> ? ? integer :: i2
>> ?end type foo
>>
>> contains
>>
>> ?subroutine caller( this, callback )
>> ? ?class (foo) :: this
>> ? ?interface
>> ? ? ? subroutine callback( this )
>> ? ? ? ? import foo
>> ? ? ? ? class (foo) :: this
>> ? ? ? end subroutine callback
>> ? ?end interface
>>
>> ? ?print *, this % i1
>> ? ?call callback( this )
>> ? ?print *, this % i2
>> ? ?this % i1 = 77
>>
>> ?end subroutine caller
>>
>> end module test1
>>
>> !=========================================================
>> module test2
>> ?use test1
>> ?implicit none
>>
>> ?type, extends( foo ) :: foo2
>> ? ?real :: r1
>> ? ?real :: r2
>> ?end type foo2
>>
>> contains
>>
>> ?subroutine callback( this )
>> ? ?class (foo) :: this
>>
>> ? ?print *, 'In callback'
>>
>> ? ?select type( this )
>> ? ?type is ( foo2 )
>> ? ? ? print *, this % r1
>> ? ? ? this % i2 = 50
>> ? ? ? this % r2 = 76.
>> ? ?end select
>>
>> ?end subroutine callback
>>
>> end module test2
>>
>> !=============================================
>> program main
>> ?use test1
>> ?use test2
>>
>> ?type (foo2) :: this
>>
>> ?this % r1 = 55.
>> ?call caller( this, callback )
>> ?print *, this % i1
>> ?print *, this % i2
>> ?print *, this % r1
>>
>> end program main
>> !=============================
>> When I build this, the resultant symbols in the object code are:
>>
>> 000001ec t MAIN__
>> 00000000 T __test1_MOD_caller
>> 00000000 D __test1_MOD_vtab$foo
>> 000000ea T __test2_MOD_callback
>> ? ? ? ? U _gfortran_set_args
>> ? ? ? ? U _gfortran_set_options
>> ? ? ? ? U _gfortran_st_write
>> ? ? ? ? U _gfortran_st_write_done
>> ? ? ? ? U _gfortran_transfer_character
>> ? ? ? ? U _gfortran_transfer_integer
>> ? ? ? ? U _gfortran_transfer_real
>> 000003ad T main
>> 00000020 r options.9.1576
>> 00000018 d vtab$foo.1565
>> 0000000c d vtab$foo2.1564
>>
>> Both 'vtab$foo' and 'vtab$foo2' show up in a data section. ?Is that
>> correct? ?This code compiles though and works just fine. ?I could tar
>> up the code that is not compiling with a makefile and attach it. ?It's
>> not to terribly much. ?Let me know if you want me to do that.
>>
>>> Do you have any "use, only: ..." clauses in your code? If yes, does
>>> removing the "only" help? This might be a possible workaround ...
>>
>> No. ?The code that does not compile has no 'use, only:' clauses at
>> all. ?Let me know if there is anything that you would like me try.
>> I'd love to help you track this down. ?Thanks again.
>>
>> Regards,
>>
>> David
>>
>