Hi Andre,
I am reasonably familiar with the mess that is gfc_conv_procedure_call :-)
So in spite of you having a hard time explaining things today, I see your
patch as verging on 'obvious' and is certainly the best that can be done
without refactoring the whole thing.
OK fo mainline.
Thanks for the patch
Paul
On Thu, 20 Mar 2025 at 16:36, Andre Vehreschild <ve...@gmx.de> wrote:
> Hi all,
>
> attached patch fixes a 15-regression where an element of an actual
> temporary array, i.e., elemental([ e1, e2...]) passed to the formal
> polymorphic
> dummy leads to a double free of the derived types components. This patch
> prevents this by preventing the deallocation of the array constructors
> temporary, when the formal is polymorphic. ...
>
> Folks its so hard to explain this in prose. I rewrote above paragraph the
> third
> time now. And I still don't understand on re-reading. So here is some
> pseudo
> code:
>
> struct derived {
> char *c; // This is the component suffering from double-free
> };
>
> derived[2] atmp = [ derived(""), derived("")]
>
> forall a in atmp
> derived t_a = a; // <- Copy of a, but no deep copy, i.e. t_a.c == a.c
> class_temp = class_derived(a); // set _vtype left out for brevity
> call elemental_function(class_temp);
> if (class_temp._data.c != NULL)
> free(class_temp._data.c); // and set it to NULL
> if (t_a.c != NULL)
> free(t_a.c); // BOOM, this is freeing the same c
> end
>
> Generating the last if-block and the free is what this patch prevents for
> polymorphic dummys that stem from an array construction. And only for
> those.
>
> Sorry, I am having a hard time explaining things today. So I hope the code
> above will do.
>
> Regtested ok on x86_64-pc-linux-gnu / F41. Ok for mainline?
>
> Regards,
> Andre
> --
> Andre Vehreschild * Email: vehre ad gmx dot de
>
