[Bug fortran/39427] F2003: Procedures with same name as types/type constructors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39427 --- Comment #29 from Tobias Burnus burnus at gcc dot gnu.org 2011-11-16 21:37:48 UTC --- Author: burnus Date: Wed Nov 16 21:37:43 2011 New Revision: 181425 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=181425 Log: gcc/fortran 2011-11-16 Tobias Burnus bur...@net-b.de PR fortran/39427 PR fortran/37829 * decl.c (match_data_constant, match_data_constant, * variable_decl, gfc_match_decl_type_spec, access_attr_decl, check_extended_derived_type, gfc_match_derived_decl, gfc_match_derived_decl, gfc_match_derived_decl) Modified to deal with DT constructors. * gfortran.h (gfc_find_dt_in_generic, gfc_convert_to_structure_constructor): New function prototypes. * interface.c (check_interface0, check_interface1, gfc_search_interface): Ignore DT constructors in generic list. * match.h (gfc_match_structure_constructor): Update prototype. * match.c (match_derived_type_spec): Ensure that one uses the DT not the generic function. * module.c (MOD_VERSION): Bump. (dt_lower_string, dt_upper_string): New functions. (find_use_name_n, find_use_operator, compare_true_names, find_true_name, add_true_name, fix_mio_expr, load_needed, read_module, write_dt_extensions, write_symbol): Changes to deal with different symtree vs. sym names. (create_derived_type): Create also generic procedure. * parse.c (gfc_fixup_sibling_symbols): Don't regard DT and * generic function as the same. * primary.c (gfc_convert_to_structure_constructor): New * function. (gfc_match_structure_constructor): Restructured; calls gfc_convert_to_structure_constructor. (build_actual_constructor, gfc_match_rvalue): Update for DT generic functions. * resolve.c (resolve_formal_arglist, resolve_structure_cons, is_illegal_recursion, resolve_generic_f, resolve_variable, resolve_fl_variable_derived, resolve_fl_derived0, resolve_symbol): Handle DT and DT generic constructors. * symbol.c (gfc_use_derived, gfc_undo_symbols, gen_special_c_interop_ptr, gen_cptr_param, generate_isocbinding_symbol, gfc_get_derived_super_type): Handle derived-types, which are hidden in the generic type. (gfc_find_dt_in_generic): New function * trans-array.c (gfc_conv_array_initializer): Replace * FL_PARAMETER expr by actual value. * trans-decl.c (gfc_get_module_backend_decl, * gfc_trans_use_stmts): Ensure that we use the DT and not the generic function. * trans-types.c (gfc_get_derived_type): Ensure that we use the * DT and not the generic procedure. gcc/testsuite/ 2011-11-16 Tobias Burnus bur...@net-b.de PR fortran/39427 PR fortran/37829 * gfortran.dg/constructor_1.f90: New. * gfortran.dg/constructor_2.f90: New. * gfortran.dg/constructor_3.f90: New. * gfortran.dg/constructor_4.f90: New. * gfortran.dg/constructor_5.f90: New. * gfortran.dg/constructor_6.f90: New. * gfortran.dg/use_only_5.f90: New. * gfortran.dg/c_ptr_tests_17.f90: New. * gfortran.dg/c_ptr_tests_18.f90: New. * gfortran.dg/used_types_25.f90: New. * gfortran.dg/used_types_26.f90: New * gfortran.dg/type_decl_3.f90: New. * gfortran.dg/function_types_3.f90: Update dg-error. * gfortran.dg/result_1.f90: Ditto. * gfortran.dg/structure_constructor_3.f03: Ditto. * gfortran.dg/structure_constructor_4.f03: Ditto. Added: trunk/gcc/testsuite/gfortran.dg/c_ptr_tests_17.f90 trunk/gcc/testsuite/gfortran.dg/c_ptr_tests_18.f90 trunk/gcc/testsuite/gfortran.dg/constructor_1.f90 trunk/gcc/testsuite/gfortran.dg/constructor_2.f90 trunk/gcc/testsuite/gfortran.dg/constructor_3.f90 trunk/gcc/testsuite/gfortran.dg/constructor_4.f90 trunk/gcc/testsuite/gfortran.dg/constructor_5.f90 trunk/gcc/testsuite/gfortran.dg/constructor_6.f90 trunk/gcc/testsuite/gfortran.dg/type_decl_3.f90 trunk/gcc/testsuite/gfortran.dg/use_only_5.f90 trunk/gcc/testsuite/gfortran.dg/used_types_25.f90 trunk/gcc/testsuite/gfortran.dg/used_types_26.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/interface.c trunk/gcc/fortran/match.c trunk/gcc/fortran/match.h trunk/gcc/fortran/module.c trunk/gcc/fortran/parse.c trunk/gcc/fortran/primary.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/symbol.c trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-decl.c trunk/gcc/fortran/trans-types.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/function_types_3.f90 trunk/gcc/testsuite/gfortran.dg/result_1.f90
[Bug fortran/39427] F2003: Procedures with same name as types/type constructors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39427 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #30 from Tobias Burnus burnus at gcc dot gnu.org 2011-11-16 21:54:10 UTC --- FIXED on the 4.7 trunk.
[Bug fortran/39427] F2003: Procedures with same name as types/type constructors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39427 --- Comment #31 from Damian Rouson damian at rouson dot net 2011-11-17 01:43:38 UTC --- This is awesome news! :D On Wed, Nov 16, 2011 at 1:54 PM, burnus at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39427 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #30 from Tobias Burnus burnus at gcc dot gnu.org 2011-11-16 21:54:10 UTC --- FIXED on the 4.7 trunk. -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You reported the bug.
[Bug fortran/39427] F2003: Procedures with same name as types/type constructors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39427 --- Comment #28 from Tobias Burnus burnus at gcc dot gnu.org 2011-11-09 13:51:52 UTC --- Submitted patch (review is pending): http://gcc.gnu.org/ml/fortran/2011-11/msg00061.html
[Bug fortran/39427] F2003: Procedures with same name as types/type constructors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39427 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |burnus at gcc dot gnu.org |gnu.org | --- Comment #27 from Tobias Burnus burnus at gcc dot gnu.org 2011-10-11 16:16:44 UTC --- Mine (again after 1.5 years). This time, I plan to finish the patch and make it read for inclusion in 4.7. The patch is essentially the one linked in comment 22 but with a couple of regressions fixed. (Current status: 15 GCC test-suite failures and one real-world failure [due to seemingly about 10 separate issues].) Draft patch and current status: https://userpage.physik.fu-berlin.de/~tburnus/tmp/constructor.diff
[Bug fortran/39427] F2003: Procedures with same name as types/type constructors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39427 janus at gcc dot gnu.org changed: What|Removed |Added CC||townsend at astro dot ||wisc.edu --- Comment #26 from janus at gcc dot gnu.org 2011-03-16 11:23:17 UTC --- *** Bug 48145 has been marked as a duplicate of this bug. ***
[Bug fortran/39427] F2003: Procedures with same name as types/type constructors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39427 --- Comment #25 from janus at gcc dot gnu.org 2011-01-09 21:42:04 UTC --- A loosely related bug is PR 42418, which demands that generic interfaces can have the same name as specific procedures. When fixing this bug, one should ideally find a solution which also fixes that issue (e.g. one could have a separate symtree for generics in a namespace).
[Bug fortran/39427] F2003: Procedures with same name as types/type constructors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39427 --- Comment #24 from Daniel Franke dfranke at gcc dot gnu.org 2010-12-28 21:49:39 UTC --- *** Bug 40824 has been marked as a duplicate of this bug. ***
[Bug fortran/39427] F2003: Procedures with same name as types/type constructors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39427 --- Comment #23 from Tobias Burnus burnus at gcc dot gnu.org 2010-12-08 13:11:02 UTC --- Using the last draft patch: With the attachment 22685 to bug 46849, one gets an error as fun_qag is regarded as FL_PROCEDURE and not as DERIVED; the issue seems to be unrelated to the other PR and should be checked/fixed in the constructor patch.
[Bug fortran/39427] F2003: Procedures with same name as types/type constructors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39427 --- Comment #22 from Tobias Burnus burnus at gcc dot gnu.org 2010-11-03 09:14:59 UTC --- Last draft patch: http://gcc.gnu.org/ml/fortran/2010-10/msg00274.html
[Bug fortran/39427] F2003: Procedures with same name as types/type constructors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39427 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #20 from Tobias Burnus burnus at gcc dot gnu.org 2010-09-30 15:49:37 UTC --- (In reply to comment #19) Could someone please comment on the relevance (or lack thereof) of the component being public in the example I submitted? This issue was solved off list/PR. The question was how to interpret the following, where [F2008's] R455 defines a structure-constructor: C496 (R455) If derived-type-spec is a type name that is the same as a generic name, the component-spec-list shall not be a valid actual-arg-spec-list for a function reference that is resolvable as a generic reference to that name (12.5.5.2). My interpretation is that this only disallows structure constructors, i.e., that generic functions have a higher precedence than structure constructors. Thus, one can always override a constructor by a generic function. (And I do not see how private components could alter the interpretation of C496 - even if one reads it differently.) F2008 also has the following note, which supports the overriding interpretation: NOTE 4.58 The form 'name(...)' is interpreted as a generic function-reference if possible; it is interpreted as a structure-constructor only if it cannot be interpreted as a generic function-reference.
[Bug fortran/39427] F2003: Procedures with same name as types/type constructors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39427 --- Comment #19 from Damian Rouson damian at rouson dot net 2010-09-28 18:38:12 UTC --- Could someone please comment on the relevance (or lack thereof) of the component being public in the example I submitted? My real goal is to have all data components private, but I left that out in the test case I submitted. The question of whether the code would still be valid appears to be a sticking point in getting one vendor to support the requested feature.
[Bug fortran/39427] F2003: Procedures with same name as types/type constructors
--- Comment #18 from burnus at gcc dot gnu dot org 2010-08-01 07:25 --- *** Bug 45155 has been marked as a duplicate of this bug. *** -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||clerman at fuse dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39427
[Bug fortran/39427] F2003: Procedures with same name as types/type constructors
--- Comment #16 from burnus at gcc dot gnu dot org 2010-07-30 09:03 --- Remove assignment. I think I won't work on this in the next weeks and New is better in allowing others to pick it up. If not, I will look at it again later. The patch of attachment 20714 plus the fix in comment 15 (plus the test cases at the bottom of attachment 20696) mostly work OK - except for a handful regressions. The implementation was using DT-name as generic function and created the derived type gfc_symbol using the suffix @. It was suggested to do the following - which might be cleaner: - Create the dt name as generic function (as before) - Use ns-derived_types to save the derived types (instead of generating another symbol) I think one can mostly recycle the resolve.c part of the patch - and the gfc_convert_to_structure_constructor's part in primary.c (one can probably get rid of gfc_match_structure_constructor after some modifications). However, all the rest has to be adapted. -- burnus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|burnus at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39427
[Bug fortran/39427] F2003: Procedures with same name as types/type constructors
--- Comment #17 from damian at rouson dot net 2010-07-31 02:30 --- Tobias, Thanks for your continued efforts on this. It will ultimately have a huge impact on the usability of gfortran for my purposes. I look forward to hearing more when you get back to it or when others do. Since there are regressions, I assume I won't get access to your patch just by doing an update using macports (my preferred method for building), but I look forward to trying it out once it's available. Damian (In reply to comment #16) Remove assignment. I think I won't work on this in the next weeks and New is better in allowing others to pick it up. If not, I will look at it again later. The patch of attachment 20714 [edit] plus the fix in comment 15 (plus the test cases at the bottom of attachment 20696 [edit]) mostly work OK - except for a handful regressions. The implementation was using DT-name as generic function and created the derived type gfc_symbol using the suffix @. It was suggested to do the following - which might be cleaner: - Create the dt name as generic function (as before) - Use ns-derived_types to save the derived types (instead of generating another symbol) I think one can mostly recycle the resolve.c part of the patch - and the gfc_convert_to_structure_constructor's part in primary.c (one can probably get rid of gfc_match_structure_constructor after some modifications). However, all the rest has to be adapted. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39427
[Bug fortran/39427] F2003: Procedures with same name as types/type constructors
--- Comment #15 from burnus at gcc dot gnu dot org 2010-05-25 19:55 --- (In reply to comment #14) Created an attachment (id=20714) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20714action=view) [edit] In module.c's import_iso_c_binding_module, one needs to replace: local_name = gfc_get_string (%s@, u-local_name); by local_name = (u-local_name[0] != '\0') ? gfc_get_string (%s@, u-local_name) : NULL; I now will try the other approach of using ns-derived_types to see whether the code will be cleaner. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39427
[Bug fortran/39427] F2003: Procedures with same name as types/type constructors
--- Comment #14 from burnus at gcc dot gnu dot org 2010-05-20 21:13 --- Created an attachment (id=20714) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20714action=view) Updated draft Use Bugzilla as backup to make sure the patch does not get lost. Mostly regtests now (353 FAILS with 73 tests), though there are still some issues, e.g., the DWARF name should be without @ (for (gdb) pt). Some clean up is needed, cf. also comment #13. Test cases: See bottom of attachment 20567 and attachment 20599. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Attachment #20696|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39427
[Bug fortran/39427] F2003: Procedures with same name as types/type constructors
--- Comment #13 from burnus at gcc dot gnu dot org 2010-05-18 21:51 --- Created an attachment (id=20696) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20696action=view) Fifth draft patch - with test case New approach. The attached patch now also works with twisted modules (cf. test case in the attachment). However, it needs still some clean up as there are test suite failures. Additional tasks: (a) Check whether one can get rid of gfc_match_structure_constructor. (b) Add check to ensure that the generic name only contains functions and that the type name does not exist as specific function name. (c) Do general clean up, bug fixing, and add test cases. Regarding C489 [F2003] and C496 [F2008], see also: http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/b3580ffd988330d7 -- burnus at gcc dot gnu dot org changed: What|Removed |Added Attachment #20599|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39427
[Bug fortran/39427] F2003: Procedures with same name as types/type constructors
--- Comment #10 from burnus at gcc dot gnu dot org 2010-05-07 09:16 --- Created an attachment (id=20592) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20592action=view) Third draft patch Updated patch: Support structure constructor if no generic function matches, function constraint. Thus: All valid programs should work. TODO: Clean up and maybe extend test cases. Error print fix (likely to be deferred to PR 39695) -- burnus at gcc dot gnu dot org changed: What|Removed |Added Attachment #20567|0 |1 is obsolete|| AssignedTo|unassigned at gcc dot gnu |burnus at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39427
[Bug fortran/39427] F2003: Procedures with same name as types/type constructors
--- Comment #11 from burnus at gcc dot gnu dot org 2010-05-07 09:20 --- (In reply to comment #10) Created an attachment (id=20592) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20592action=view) [edit] Third draft patch To continue the tradition: There is again something wrong with the patch: It accidentally also contains the patch for PR 43945 (resolve.c, cf. http://gcc.gnu.org/ml/fortran/2010-05/msg00037.html). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39427
[Bug fortran/39427] F2003: Procedures with same name as types/type constructors
--- Comment #12 from burnus at gcc dot gnu dot org 2010-05-07 16:37 --- Created an attachment (id=20599) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20599action=view) Fourth version of the draft patch And fourth version. I have just realized that the patch is too simplistic and that I might need go back to the drawing board. The following is currently not handled: a) Constraint check (cf. comment 3 [F03: C489, F08: C496]): the component-spec-list has to be different from the interface of any of the generic procedures (i.e. an actual-arg-spec-list matching the component-spec-list shall not match any of the generic functions). Note: This included handling default initializers as they act as optional arguments. b) The algorithm does not handle: Define function in one module,* define type in a different module, and use associate them [including constraint checking, cf. (a)]. Currently, the renaming is only handled if either the generic interface or the derived type is available before the other type is declared. (* That's possible because the functions do not need to return the derived type - even though that's the most common case.) I probably solve this by renaming derived types to name@ and automatically generating an associated generic function with the specific name name@ and a dummy arg list [including DT parents (plural)]. One needs to modify gfc_typename to print the type without @ and then one has also no problem with the trailing @ sign. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Attachment #20592|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39427
[Bug fortran/39427] F2003: Procedures with same name as types/type constructors
--- Comment #8 from burnus at gcc dot gnu dot org 2010-05-05 18:09 --- Created an attachment (id=20567) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20567action=view) Second draft patch (In reply to comment #6) First draft patch Updated patch: Fixes the reversed order, fixes .mod read, and has a test case included. TODO: Call structure constructor if no generic function matches; function constraint; error print fix. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Attachment #20557|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39427
[Bug fortran/39427] F2003: Procedures with same name as types/type constructors
--- Comment #9 from burnus at gcc dot gnu dot org 2010-05-05 18:14 ---
(In reply to comment #8)
Created an attachment (id=20567)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20567action=view) [edit]
Second draft patch
And another omission:
--- a/gcc/fortran/module.c
+++ b/gcc/fortran/module.c
@@ -3781,7 +3787,7 @@ static void
load_generic_interfaces (void)
{
const char *p;
- char name[GFC_MAX_SYMBOL_LEN + 1], module[GFC_MAX_SYMBOL_LEN + 1];
+ char name[GFC_MAX_SYMBOL_LEN + 3], module[GFC_MAX_SYMBOL_LEN + 1];
gfc_symbol *sym;
gfc_interface *generic = NULL, *gen = NULL;
int n, i, renamed;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39427
[Bug fortran/39427] F2003: Procedures with same name as types/type constructors
--- Comment #4 from steven at gcc dot gnu dot org 2010-05-04 12:09 --- What a horrible rule... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39427
[Bug fortran/39427] F2003: Procedures with same name as types/type constructors
--- Comment #5 from damian at rouson dot net 2010-05-04 14:25 --- (In reply to comment #4) What a horrible rule... I'm not sure why you don't like it, but the reason for the rule is to have the ability to overload the intrinsic structure constructors. The intrinsic structure constructors are virtually useless for object-oriented programming (OOP) because they can't be used if the type has private data (required by the information-hiding philosophy of OOP) unless all components have default initializations (which only helps in trivial cases). It's standard in C++ (and I'd guess in most other OOP languages) for constructors to have the same name as the type. What could be more clear to the reader than type(vector) :: f f = vector(1.0,2.0) Once one adopts this approach, it touches every type you develop, so a compiler that doesn't support it becomes useless unless you're willing to change every constructor name to suit that particular compiler. It's already supported by IBM XL Fortran (my primary development platform), by Cray, by NAG (I think), and Intel has promised to support it in its next release. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39427
[Bug fortran/39427] F2003: Procedures with same name as types/type constructors
--- Comment #6 from burnus at gcc dot gnu dot org 2010-05-04 16:10 --- Created an attachment (id=20557) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20557action=view) First draft patch (In reply to comment #5) (In reply to comment #4) What a horrible rule... What do you mean? Allowing name() as (generic) constructor (function)? Why not? That matches the natural use. If you mean the constraint in comment 3: That just ensures that one cannot have use a structure constructor and generic function simultaneously. Intel has promised to support it in its next release. Well, I can also promise that _one_ of the next releases will have it :P At least there are plans to improve OOP and there is also a Summer of Code projects for OOP, cf. http://gcc.gnu.org/wiki/SummerOfCode * * * Attached is a draft patch which should work in simple cases. TODO: * Call structure constructor if no generic function matches; that means: Converting the actual arguments into a constructor and do the checking (cf. FIXME in resolve.c) * Add a is-function check: A generic name may be the same as a derived-type name, in which case all of the procedures in the interface block shall be functions. (Note: That's not a constraint thus one does not need to catch all cases.) * Fix the case of first defining the generic name and then the type: interface t procedure t2 end interface t type t end type t * Add a new %X (X = some letter) to finally solve the @ printing problem in error messages for PPC and for constructors (this PR): gfc_error should then simply strip the @... from the message for arguments to %X while for %s no extra stripping is done as it is currently done. One then only needs to change all relevant %s to %X and one is done. (using a more-intuitive different latter than %X would be helpful; maybe %S = Symbol String?.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39427
[Bug fortran/39427] F2003: Procedures with same name as types/type constructors
--- Comment #7 from burnus at gcc dot gnu dot org 2010-05-04 16:13 --- (In reply to comment #6) Created an attachment (id=20557) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20557action=view) [edit] First draft patch if (type != current_interface.type - || strcmp (current_interface.sym-name, name) != 0) + strcmp (current_interface.sym-name, name) != 0) And that change is of course wrong. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39427
[Bug fortran/39427] F2003: Procedures with same name as types/type constructors
--- Comment #3 from janus at gcc dot gnu dot org 2010-01-23 17:25 --- Another related quote from the F2003 standard: C489 (R457) If derived-type-spec is a type name that is the same as a generic name, the component-spec-list shall not be a valid actual-arg-spec-list for a function reference that is resolvable as a generic reference (12.4.4.1). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39427
[Bug fortran/39427] F2003: Procedures with same name as types/type constructors
--- Comment #2 from burnus at gcc dot gnu dot org 2009-12-03 21:02 --- Quote from the standard: 12.3.2 Specification of the procedure interface [...] A generic name may be the same as a derived-type name, in which case all of the procedures in the interface block shall be functions. Currently, one gets the message: Error: DERIVED attribute of 'foo' conflicts with PROCEDURE attribute at (1) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39427
[Bug fortran/39427] F2003: Procedures with same name as types/type constructors
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||20585 nThis|| Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39427
[Bug fortran/39427] F2003: Procedures with same name as types/type constructors
--- Comment #1 from burnus at gcc dot gnu dot org 2009-03-11 22:41 --- Confirm; this F2003 feature is not yet implemented. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-03-11 22:41:58 date|| Summary|Error on generic name |F2003: Procedures with same |equivalent to type name in |name as types/type |same module |constructors http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39427
