[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