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;
dkad...@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
