| Message ID | AANLkTinty78SSUAn_x=Ds4cO0DQJB3Ym57sFW_dhkXT+@mail.gmail.com |
|---|---|
| State | New |
| Headers | show |
Hi Janus, > One simple alternative that just came to my mind: The whole problem > would go away if the __copy_ routine would undergo the same name > mangling as all standard module procedures, i.e. getting a prefix like > "__m1_" or "__m2_". When looking for the reason, I came up with the > attached two-line patch, which seems to fix the issue for both the > single-file as well as multi-file setup, and is much simpler than the > previous approach (not regtested yet). this approach looks very good. OK if it passes regtesting. Thanks for the patch! Thomas
>> One simple alternative that just came to my mind: The whole problem >> would go away if the __copy_ routine would undergo the same name >> mangling as all standard module procedures, i.e. getting a prefix like >> "__m1_" or "__m2_". When looking for the reason, I came up with the >> attached two-line patch, which seems to fix the issue for both the >> single-file as well as multi-file setup, and is much simpler than the >> previous approach (not regtested yet). > > this approach looks very good. > > OK if it passes regtesting. Thanks for the review, Thomas. Regtest passed without failures. I will wait for feedback from Salvatore (who promised to try the patch on his code) before committing. Cheers, Janus
>>> One simple alternative that just came to my mind: The whole problem >>> would go away if the __copy_ routine would undergo the same name >>> mangling as all standard module procedures, i.e. getting a prefix like >>> "__m1_" or "__m2_". When looking for the reason, I came up with the >>> attached two-line patch, which seems to fix the issue for both the >>> single-file as well as multi-file setup, and is much simpler than the >>> previous approach (not regtested yet). >> >> this approach looks very good. >> >> OK if it passes regtesting. > > Thanks for the review, Thomas. Regtest passed without failures. > > I will wait for feedback from Salvatore (who promised to try the patch > on his code) before committing. As this was apparently successful, I just committed the patch as r168464. As a consequence, the OOP regression count has basically dropped to zero (expect for one, which is not a real regression*). Cheers, Janus * PR46262: Technically it *is* a regression, since it gives an ICE which was not there for 4.5. However, 4.5 generated wrong code for the test case, which means it was never *really* working.
On 01/04/2011 05:12 AM, Janus Weil wrote: >>>> One simple alternative that just came to my mind: The whole problem >>>> would go away if the __copy_ routine would undergo the same name >>>> mangling as all standard module procedures, i.e. getting a prefix like >>>> "__m1_" or "__m2_". When looking for the reason, I came up with the >>>> attached two-line patch, which seems to fix the issue for both the >>>> single-file as well as multi-file setup, and is much simpler than the >>>> previous approach (not regtested yet). >>> >>> this approach looks very good. >>> >>> OK if it passes regtesting. >> >> Thanks for the review, Thomas. Regtest passed without failures. >> >> I will wait for feedback from Salvatore (who promised to try the patch >> on his code) before committing. > > As this was apparently successful, I just committed the patch as r168464. > > As a consequence, the OOP regression count has basically dropped to > zero (expect for one, which is not a real regression*). > Thanks Janus! Keep up the good work! Thanks to everyone for keeping at it! Jerry
Index: gcc/fortran/class.c =================================================================== --- gcc/fortran/class.c (revision 168424) +++ gcc/fortran/class.c (working copy) @@ -528,6 +528,8 @@ gfc_find_derived_vtab (gfc_symbol *derived) sub_ns->proc_name = copy; copy->attr.flavor = FL_PROCEDURE; copy->attr.if_source = IFSRC_DECL; + if (ns->proc_name->attr.flavor == FL_MODULE) + copy->module = ns->proc_name->name; gfc_set_sym_referenced (copy); /* Set up formal arguments. */ gfc_get_symbol ("src", sub_ns, &src);