[Bug fortran/115265] Generic function for constructor not invoked for same-name derived type with procedure pointer component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115265 --- Comment #11 from Jerry DeLisle --- (In reply to Matthew Krupcale from comment #10) > Thanks Jerry! I think you may also have to backport the fix [1] for PR118640 > to avoid regression on the 14 branch as well. > > [1] > https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git; > h=3600b1ff14a459e84bb40bdfea7cd8d2ffd73d8d Thanks for pointing that out. I overlooked it. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118640#c7
[Bug fortran/115265] Generic function for constructor not invoked for same-name derived type with procedure pointer component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115265 --- Comment #10 from Matthew Krupcale --- Thanks Jerry! I think you may also have to backport the fix [1] for PR118640 to avoid regression on the 14 branch as well. [1] https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=3600b1ff14a459e84bb40bdfea7cd8d2ffd73d8d
[Bug fortran/115265] Generic function for constructor not invoked for same-name derived type with procedure pointer component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115265 Jerry DeLisle changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Jerry DeLisle --- After regression testing and confirming this bug is fixed by 14.. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109066#c8 Closing this one.
[Bug fortran/115265] Generic function for constructor not invoked for same-name derived type with procedure pointer component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115265 --- Comment #8 from Jerry DeLisle --- I have backported cleanly and regression tested on 14 branch. Will push shortly.
[Bug fortran/115265] Generic function for constructor not invoked for same-name derived type with procedure pointer component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115265 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #7 from Jerry DeLisle --- (In reply to Matthew Krupcale from comment #6) > (In reply to Paul Thomas from comment #5) > --- snip --- > > It looks like Andre Vehreschild suggested [4] on the fortran mailing list to: > > 1. Add the testcase if it adds a new way. > 2. Apply the backport if it applies simply and not to do so if it caused > major issues. > > There were no other responses back then in February, but I suppose you > disagree with his stance? Or did you observe major issues with the backport? > In any case, I can certainly try appealing to the mailing list again. > Several of us have had some other burnng issues to deal with. I will take a look at it this afternoon and if I can, I will backport it.
[Bug fortran/115265] Generic function for constructor not invoked for same-name derived type with procedure pointer component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115265 --- Comment #6 from Matthew Krupcale --- (In reply to Paul Thomas from comment #5) > Neither PR is a regression and defined assignment is so fundamentally > incorrect, where defined assignment of components is concerned, that > sticking plaster patches do not warrant a backport. I understand that PR115265 and PR109066 may not be a regression (unless the regression happened prior to version 5.5), but the segfault certainly is undesired behavior in what seems to be valid Fortran that is accepted and runs without segfault by other compilers, and the patches [1,2] which fix it seem quite simple to backport, even if component defined assignment is so poorly implemented that it will require reworking in v16 [3]. > You could try appealing > to the gfortran mailing list. If it is OK'd there, I would be happy to > backport to 14-branch. It looks like Andre Vehreschild suggested [4] on the fortran mailing list to: 1. Add the testcase if it adds a new way. 2. Apply the backport if it applies simply and not to do so if it caused major issues. There were no other responses back then in February, but I suppose you disagree with his stance? Or did you observe major issues with the backport? In any case, I can certainly try appealing to the mailing list again. Best, Matthew [1] https://gcc.gnu.org/git/?p=gcc.git;a=blobdiff;f=gcc/fortran/resolve.cc;h=e8f780d1ef96413c0cd197ab36ddb1fd0fea866c;hp=b8c908b51e92c848b0ca4280d66d276c078d5a83;hb=27ff8049bbdb0a001ba46835cd6a334c4ac76573;hpb=4a4bd60fa08b9e1079ebead6cb8c3ce82c7f9ef6 [2] https://gcc.gnu.org/git/?p=gcc.git;a=blobdiff;f=gcc/fortran/resolve.cc;h=7f73d53e31ef11b8822974bf83e6c9fbd39fcb9f;hp=124f4ac4edcdca5406fd6b0e0e24cde95c4e5485;hb=3600b1ff14a459e84bb40bdfea7cd8d2ffd73d8d;hpb=92a5c5100c25190622ca86b63586a598952546bf [3] https://gcc.gnu.org/pipermail/fortran/2025-February/061688.html [4] https://gcc.gnu.org/pipermail/fortran/2025-February/061689.htm
[Bug fortran/115265] Generic function for constructor not invoked for same-name derived type with procedure pointer component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115265 --- Comment #5 from Paul Thomas --- > > Great, thanks for adding this testcase. Is there any change the fix in > > PR109066 will be applied to older branches, e.g. 13 and 14? Neither PR is a regression and defined assignment is so fundamentally incorrect, where defined assignment of components is concerned, that sticking plaster patches do not warrant a backport. You could try appealing to the gfortran mailing list. If it is OK'd there, I would be happy to backport to 14-branch. For the same reasons, I decided not to add the testcase after all. Best regards Paul
[Bug fortran/115265] Generic function for constructor not invoked for same-name derived type with procedure pointer component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115265 --- Comment #4 from Paul Thomas --- (In reply to Matthew Krupcale from comment #3) > Hey Paul, > > Great, thanks for adding this testcase. Is there any change the fix in > PR109066 will be applied to older branches, e.g. 13 and 14? > > Matthew Sorry for the slow response - I have just spent a week chilling out (literally and spritually!) in Cornwall. My inclination is to say that it shouldn't be backported, partly because neither PR is a regression and partly because the treatment of component defined assignment is just plain wrong and I am reluctant to patch it up further. That said, I will put the question to the list. Regards Paul
[Bug fortran/115265] Generic function for constructor not invoked for same-name derived type with procedure pointer component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115265 --- Comment #3 from Matthew Krupcale --- Hey Paul, Great, thanks for adding this testcase. Is there any change the fix in PR109066 will be applied to older branches, e.g. 13 and 14? Matthew
[Bug fortran/115265] Generic function for constructor not invoked for same-name derived type with procedure pointer component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115265 Paul Thomas changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #2 from Paul Thomas --- Created attachment 60289 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60289&action=edit Testcase for mainline Here it is. Paul
[Bug fortran/115265] Generic function for constructor not invoked for same-name derived type with procedure pointer component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115265 Paul Thomas changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2025-01-27 Status|UNCONFIRMED |NEW CC||pault at gcc dot gnu.org --- Comment #1 from Paul Thomas --- Hi Matthew, As you said, this PR was indeed fixed by the patch for PR109066. Thanks pointing it out. I have prepared a deja-gnuified verion of your testcase, which I will push to 15-branch at the end of play today. Best regards Paul
