From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15590 invoked by alias); 30 May 2009 17:58:27 -0000 Received: (qmail 15572 invoked by uid 22791); 30 May 2009 17:58:26 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_51 X-Spam-Check-By: sourceware.org Received: from outpost1.zedat.fu-berlin.de (HELO outpost1.zedat.fu-berlin.de) (130.133.4.66) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 30 May 2009 17:58:20 +0000 Received: from relay1.zedat.fu-berlin.de ([130.133.4.67]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1MASoz-0008WQ-3j>; Sat, 30 May 2009 19:58:17 +0200 Received: from smart.physik.fu-berlin.de ([160.45.66.6] helo=[127.0.0.1]) by relay1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1MASoy-0005Lt-UJ>; Sat, 30 May 2009 19:58:17 +0200 Message-ID: <4A2173B7.6040206@net-b.de> Date: Sat, 30 May 2009 18:45:00 -0000 From: Tobias Burnus User-Agent: Thunderbird 2.0.0.21 (X11/20090310) MIME-Version: 1.0 To: Dave Korn CC: Angelo Graziosi , Fortran , "gcc@gcc.gnu.org" Subject: 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] References: <4A20F778.9010705@alice.it> <4A214191.1050206@gmail.com> <4A2143EA.2050904@gmail.com> <4A214B46.7040405@gmail.com> <4A216AA3.1070000@gmail.com> In-Reply-To: <4A216AA3.1070000@gmail.com> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2009-05/txt/msg00703.txt.bz2 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 in middle-end warnings, which can confuse users. Tobias