Re: [Patch, Fortran] PR 42353: [OOP] Bogus Error: Name 'vtype$...' at (1) is an ambiguous reference ...

[Janus Weil <janus at gcc dot gnu dot org>]

> Have you tried this yet on fortran-dev? ?I suspect that it will go
> pear shaped with libraries.

Indeed: As reported by Daniel, the patch introduces several
regressions on fortran-dev.

Here is a patch for fortran-dev, which reverts the PRIVATE attributes,
and instead fixes the bug by adding special cases for vtabs and vtypes
in the ambiguity checking. This removes all testsuite failures on
fortran-dev. [Note that this patch won't apply to trunk, as the
'vtype' attribute is missing there.]

Paul, do you think this version of the patch is ok?

Harald, is it possible for you to try out the fortran-dev branch with
this patch? If yes, it would be good to know if it works on your
codes.

Cheers,
Janus



> On Tue, Dec 29, 2009 at 12:15 AM, Janus Weil <janus@gcc.gnu.org> wrote:
>>> Ok, I think I got it. Basically, one just has to do the same thing one
>>> does to the vtypes also to the vtabs, i.e. making both of them PRIVATE
>>> makes all errors in the PR vanish. The attached patch has been
>>> regtested successfully. I will commit it once Harald confirms that he
>>> sees no further problems (and provided no one else protests).
>>
>> Committed as r155494. Thanks to Harald for reporting this bug.
>>
>> Cheers,
>> Janus
>>
>>
>>
>>>>>> 2009/12/17 Janus Weil <janus@gcc.gnu.org>:
>>>>>>>> the attached patch fixes a small OOP problem, where under certain
>>>>>>>> circumstances one would get 'ambiguous reference' errors for the
>>>>>>>> vtypes. The easiest thing I could think of to fix this is to make the
>>>>>>>> vtypes private, which means that each module which uses a vtype will
>>>>>>>> have its own private copy (which in principle should not be a problem,
>>>>>>>> should it?).
>>>>>>>
>>>>>>> In contrast to the patch I sent earlier, the version attached here
>>>>>>> also fixes the second error in the PR, which I almost forgot about
>>>>>>> ("Error: The element in the derived type constructor at (1), for
>>>>>>> pointer component '$extends', is DERIVED but should be DERIVED").
>>>>>>>
>>>>>>> Although the patch obviously works, I'm not sure if it may have any
>>>>>>> negative consequences and if it's the best thing to do. At least it
>>>>>>> fixes the test case and regtests cleanly.
>>>>>>>
>>>>>>> Comments? Suggestions? Ok for trunk?
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Janus
>>>>
>>>
>>
>
>
>
> --
> The knack of flying is learning how to throw yourself at the ground and miss.
> ? ? ? --Hitchhikers Guide to the Galaxy
>

Attachment: pr42353_fortran_dev.diff
Description: Binary data