Re: Compilation error

[David Car <david dot car7 at gmail dot com>]

Hi Janus,

Thanks for the clarification.  I just wanted to make sure that the
symbols weren't supposed to be some other name.  I've built some other
cases where there is no symbol for an extended derived type in the
object code, so I wasn't clear on what I should see.

The code is not that large, but I have to write some stub routines for
certain library calls that it links too in order for it to be
externally built.  I will do as you say and start removing pieces
until it builds with no errors.  I welcome the help in the reduction
after I write the stubs and give it a crack.  I'll keep you posted.
Thanks.

Regards,

David



On Fri, Jun 4, 2010 at 12:36 PM, Janus Weil <janus@gcc.gnu.org> wrote:
> 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
>>>
>>
>