Re: [fortran] Different FUNC_DECLS with the same DECL_NAME - MAIN__ and named PROGRAM main functions [was Re: gcc-4.5-20090528 is now available]

[Dave Korn <dave dot korn dot cygwin at googlemail dot com>]

Dave Korn wrote:
> Dave Korn wrote:
>> Tobias Burnus wrote:
> 
>>> I agree that for "main" the call to "__main()" should happend and thus
>>> expand_main_function should be called. I'm not sure in about the exact
>>> assumptions of the middle end. In principle, it would be OK if the
>>> MAIN__ function would show up as MAIN__ in gimple/-fdump-tree-original.
>>> The only potential inconvenience I see, is the mentioned reference to
>>> MAIN__ instead of <program name> in middle-end warnings, which can
>>> confuse users.

  Is it legitimate to have a space in an IDENTIFIER_NODE?  I have a cheeky idea:

$ svn diff
Index: trans-decl.c
===================================================================
--- trans-decl.c        (revision 147949)
+++ trans-decl.c        (working copy)
@@ -3859,7 +3859,8 @@
   tmp =  build_function_type_list (integer_type_node, integer_type_node,
                                   build_pointer_type (pchar_type_node),
                                   NULL_TREE);
-  ftn_main = build_decl (FUNCTION_DECL, get_identifier ("main"), tmp);
+  main_identifier_node = get_identifier ("main");
+  ftn_main = build_decl (FUNCTION_DECL, main_identifier_node, tmp);
   DECL_EXTERNAL (ftn_main) = 0;
   TREE_PUBLIC (ftn_main) = 1;
   TREE_STATIC (ftn_main) = 1;
Index: parse.c
===================================================================
--- parse.c     (revision 147949)
+++ parse.c     (working copy)
@@ -1424,8 +1424,10 @@
 {
   gfc_symbol *main_program;
   symbol_attribute attr;
+  const char *identifier;

-  gfc_get_symbol (name, ns, &main_program);
+  identifier = gfc_get_string ("PROGRAM %s", name);
+  gfc_get_symbol (identifier, ns, &main_program);
   gfc_clear_attr (&attr);
   attr.flavor = FL_PROGRAM;
   attr.proc = PROC_UNKNOWN;

DKAdmin@ubik /gnu/gcc/gcc-patched/gcc/fortran
$

  That should give reasonable warnings from the middle end, no?  I don't know
what it might do to debugging though.

    cheers,
      DaveK