[RFC] Constructor patch
Tobias Burnus
burnus@net-b.de
Wed Oct 27 18:00:00 GMT 2010
On 10/27/2010 04:54 PM, Janus Weil wrote:
> Could you say a few words on the general idea of your implementation?
Well, the basic idea has not changed much. For a derived type
TYPE myType
END TYPE myType
A generic function symbol "mytype" is generated. Additionally, a derived
type "Mytype" (with captial "M") is generated; hereby "Mytype" is the
symtree name while the symbol has "mytype". That avoids most of the
naming issues in error messages, but one needs to take care here and
there that it works as advertised. For instance, the undo_symbol
mechanism uses the symbol name to find the symtree, which would delete
the wrong symtree. -- The generic-name symbol stores the derived-type
symbol as item in the linked list of specific symbols belonging to that
generic function.
When "myTYPE()" is encountered, it is regarded at parsing time as
generic procedure; at resolving time, first the normal matching is done
before one falls back to the structure constructor, which means that one
needs to convert the actual argument list into a structure constructor.
The gotchas are less in getting the new features to work but to fix the
fall out of the change. For instance, if one does:
use m, only: dt2 => dt
that needs to rename both the symbol pointing to the generic name but
also the (hidden) derived-type symbol. (I think that is the reason for
some of the remaining failures.)
> Also, I remember that Damian was extremely keen to see this feature
> implemented. I'm sure he has some test cases and might want to try out
> the patch ...
I think the new feature should work pretty well. The problem is rather
to get all old code working ...
> What's the order of magnitude of the failures?
110 failures in the previously posted patch. In my current version
(attached) 51 test-suite failures (Counting multiple failures for the
same file as one failure.) I think several of them are of the same kind.
(And no: I do not expect that fixing the remaining bugs will be as quick
as fixing the 50
Fortunately, most bugs are of the kind rejects-valid or the compiler
segfaults. However, I have already found one test case where wrong code
is generated* :-(
My hope is that the patch still can go into 4.6 (which is one reason for
posting it here). Thus, I would be happy for review comments or a
helping hand. I am not sure I am already interested in failing test
cases, but if you have one involving the new feature (or one not covered
by the test suite), please tell me.
Tobias
* That's the reason for the dg-do compile->run change in the patch ...
PS: Currently failing are the following test cases:
gfortran.dg/array_constructor_32.f90
gfortran.dg/binding_label_tests_3.f03
gfortran.dg/class_10.f03
gfortran.dg/class_11.f03
gfortran.dg/class_12.f03
gfortran.dg/class_17.f03
gfortran.dg/class_2.f03
gfortran.dg/class_8.f03
gfortran.dg/class_allocate_4.f03
gfortran.dg/class_defined_operator_1.f03
gfortran.dg/c_ptr_tests_11.f03
gfortran.dg/c_ptr_tests_8.f03
gfortran.dg/dummy_procedure_4.f90
gfortran.dg/dynamic_dispatch_10.f03
gfortran.dg/dynamic_dispatch_6.f03
gfortran.dg/elemental_subroutine_2.f90
gfortran.dg/extends_10.f03
gfortran.dg/extends_2.f03
gfortran.dg/func_derived_3.f90
gfortran.dg/implicit_14.f90
gfortran.dg/implicit_15.f90
gfortran.dg/implicit_17.f90
gfortran.dg/implicit_18.f90
gfortran.dg/import4.f90
gfortran.dg/import5.f90
gfortran.dg/import6.f90
gfortran.dg/import7.f90
gfortran.dg/import.f90
gfortran.dg/interface_16.f90
gfortran.dg/interface_32.f90
gfortran.dg/iso_c_binding_only.f03
gfortran.dg/nested_modules_3.f90
gfortran.dg/pr32801.f03
gfortran.dg/private_type_2.f90
gfortran.dg/private_type_4.f90
gfortran.dg/proc_ptr_30.f90
gfortran.dg/proc_ptr_comp_4.f90
gfortran.dg/proc_ptr_comp_pass_3.f90
gfortran.dg/result_1.f90
gfortran.dg/select_type_16.f03
gfortran.dg/select_type_18.f03
gfortran.dg/structure_constructor_3.f03
gfortran.dg/structure_constructor_4.f03
gfortran.dg/structure_constructor_8.f03
gfortran.dg/structure_constructor_9.f90
gfortran.dg/typebound_call_17.f03
gfortran.dg/typebound_call_18.f03
gfortran.dg/used_types_12.f90
gfortran.dg/used_types_3.f90
gfortran.dg/where_operator_assign_1.f90
gfortran.dg/whole_file_27.f90
-------------- next part --------------
A non-text attachment was scrubbed...
Name: constr-1.diff
Type: text/x-patch
Size: 28578 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20101027/2e0aff87/attachment.bin>
More information about the Fortran
mailing list