Dave,
Dave Korn wrote:
> I see there are two places in fortran/parse.c
Side remark: You know that the actual middle-end TREE is only generated
in trans*.c? Thus, all things which happen before like parse.c can be
still remodeled in trans*c.
> that call
> main_program_symbol(): either as a result of a PROGRAM statement
> ... or if the code starts with a nameless block:
>
The reason is one can write a Fortran main program either as:
---------------------------
print *, 'Hello World'
end
---------------------------
or as
---------------------------
program HelloWorld
print *, 'Hello World'
end program HelloWorld
---------------------------
And both denotes a Fortran main program, which should end up under the
(assembler) name "MAIN__" in the .s file.
> One thing I don't understand is why there is a function
> gfc_sym_mangled_function_id() in trans-decl.c that has this code:
> /* Main program is mangled into MAIN__. */
> if (sym->attr.is_main_program)
> return get_identifier ("MAIN__");
>
As for debugging messages etc. the name to the front end is, e.g.,
"HelloWorld", one needs to convert it into MAIN__ (which is for historic
reasons the assembler name of the Fortran main program in code generated
by several compilers, be it g77, g95, gfortran, ifort or sunf95).
> It appears that this or something else is causing both functions to have the
> same DECL_NAME when they are passed to gimple_expand_cfg() in cfgexpand.c, so
> they both get identified as the main function and potentially have static ctor
> calls to __main() inserted. This is because the testcase I'm looking at uses
> a "program main" directive. The two function decls have different underlying
> sym_refs - "MAIN__" vs. "main" - but they both point to the same
> IDENTIFIER_NODE, for "main" in their DECL_NAME fields.
>
Hmm, that should not be the case that the middle end gets confused. I
think there is some merit in printing also the name, e.g., HelloWorld
rather than MAIN__ in middle end warnings ("unused variable foo in
HelloWorld"), but otherwise the name given to the program in gimple
shouldn't matter as long as the assembler name is MAIN__.
Seemingly there are some issues; however, they do not seem to be new.
MAIN__ was before generated and the main() was linked from the library.
The library's main (in fmain.c / libgfortranbegin.a) should already have
called __main(). Thus if gimple_expand_cfg() automatically adds __main()
calls for "main" then this must have happened before.
> I think this is probably an invalid way for the front-end to drive the
> mid-end - it's ok when the two functions are semantically the same, as when
> C++ clones constructors, but these are actually two entirely different
> functions, and in particular, only one of them should cause
> expand_main_function to be called. I'd like that to be the real "main"
> function, which is where the fortran runtime init gets called, rather than
> "MAIN__", which is the user-level main function, because the runtime init
> itself might need to use st_printf and that won't work until __main() is
> called, but I'm not sure how to disetangle the two now.
>
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.
Tobias
