This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Patch, fortran] PR69834 - Collision in derived type hashes


Dear Jerry,

I have been distracted by other matters and will not be able to do
anything about this for a couple of weeks. I will try to get over the
problem with submodules with the alternative patch, which uses the
pointer to the vtable as a type identifier. It must be possible to do
this and would be much neater, since the comparison in select type and
same_type_as would be a long integer, rather than a long string!

Please send me the Metcalfe testcase. I already have it somewhere but
don't seem able to lay hands on it.

Best regards

Paul

On 3 March 2016 at 21:31, Jerry DeLisle <jvdelisle@charter.net> wrote:
> On 03/03/2016 07:59 AM, Paul Richard Thomas wrote:
>> Dear All,
>>
>> What started out as a provisional kludge, when first working on OOP,
>> has come back to bite us after 7 years. A collision in derived type
>> has values has been reported on clf. In principle, as pointed out in
>> the clf thread, this could mean that existing code might be quietly
>> confusing dynamic types. Fortunately, this is unlikely because the
>> error in SELECT TYPE that flagged up this problem might appear or
>> incorrect fields might be accessed, giving rise to runtime errors.
>>
>> The fix uses a new vtable field, '_name' that is loaded with the
>> value, "typename_scopename", which is used for the cases in SELECT
>> TYPE and for comparison in SAME_TYPE_AS. I have retained the '_hash'
>> field for compatibility with existing libraries. It could easily be
>> removed, if that is preferred, but would require a publicity campaign
>> to ensure that users recompile their code.
>>
>> The changes are sufficiently well described in the ChangeLogs and the
>> comments in the patch to not warrant further comment.
>>
>> I have to confess to not knowing quite what to propose here. My gut
>> feeling is that we should bite the bullet and the patch should be
>> applied to trunk and 5-branch. However, I am open, on the grounds
>> above, to wait until 7.0.0. It does bootstrap and regtest on trunk
>> with FC23/x86_64.
>>
>> Thanks to Dominique for testing an early version of the test and to
>> Thomas for picking up on the clf thread.
>>
>
> In my very humble opinion, I think you should commit the patch now before
> release. As I have said before, people know major releases are bleeding edge,
> bugs if any will be flushed out and can be fixed at 6.2 or 6.3.  It is the open
> nature of our software and the user feedback that makes this all work. (also we
> know Fortran is not release critical)
>
> I tested with my own OOP code which is an adaptation of Metcalf's linked anylist
> and it works fine.  Thats the best I can do and it is fairly complex code.  I
> can send it to you if you would like to have it in your test pile.
>
> Regards,
>
> Jerry



-- 
The difference between genius and stupidity is; genius has its limits.

Albert Einstein


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]