This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug fortran/51529] [OOP] gfortran.dg/class_to_type_1.f03 is miscompiled: Uninitialized variable used
- From: "paul.richard.thomas at gmail dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Wed, 14 Dec 2011 08:55:08 +0000
- Subject: [Bug fortran/51529] [OOP] gfortran.dg/class_to_type_1.f03 is miscompiled: Uninitialized variable used
- Auto-submitted: auto-generated
- References: <bug-51529-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51529
--- Comment #3 from paul.richard.thomas at gmail dot com <paul.richard.thomas at gmail dot com> 2011-12-14 08:55:08 UTC ---
Dear Tobias,
> However, I do now understand why one needs for SOURCE= to memset the source to
> NULL - at least as long _copy not only copies the data but also frees it. The
> latter could be also left to _free. - Actually, I am in favour of separating
> _copy and _free. As this issue shows, there are cases where one does not want
> to combine them, leading to work around actions (memset). I think only for
> polymorphic assignment, one needs _free + _copy, for allocate with SOURCE= a
> _copy should be enough.
The memset came about for similar reasons with class objects with
allocatable components. I had missed this wrinkle with the testcase.
My inclination is to restire the memset and keep the PR open.
I am am trying to clear up some issues of functionality, starting with
the failure of a%disp() to scalarize properly in class_array_3.f03.
Then I have mind to understand the failure of vector indexing in
gfc_trans_call and finally to deal with class array components and
class array subreferences. After the tidy up :-)
Cheers
Paul