[RFC] Constructor patch

[Damian Rouson]

Thanks for copying me on this.  I'm excited to see the progress. A
test case is attached to this e-mail.

Damian

On Wed, Oct 27, 2010 at 9:03 AM, Tobias Burnus <burnus@net-b.de> wrote:
> 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: metcalf_modified.F90
Type: application/octet-stream
Size: 949 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20101027/e7fcf3f0/attachment.obj>