From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2288 invoked by alias); 30 May 2009 19:07:43 -0000 Received: (qmail 2272 invoked by uid 22791); 30 May 2009 19:07:42 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,BAYES_00 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 19:07:34 +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 <1MATty-0006Vf-Ab>; Sat, 30 May 2009 21:07:30 +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 <1MATty-0000xy-5O>; Sat, 30 May 2009 21:07:30 +0200 Message-ID: <4A2183EF.20004@net-b.de> Date: Sun, 31 May 2009 22:44:00 -0000 From: Tobias Burnus User-Agent: Thunderbird 2.0.0.21 (X11/20090310) MIME-Version: 1.0 Newsgroups: gmane.comp.gcc.devel,gmane.comp.gcc.fortran 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> <4A2173B7.6040206@net-b.de> <4A217895.9060708@gmail.com> <4A217D12.9000801@gmail.com> <4A2180C2.2010500@gmail.com> In-Reply-To: <4A2180C2.2010500@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/msg00708.txt.bz2 Dave Korn wrote: > 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 in middle-end warnings, which can >>>> confuse users. > > Is it legitimate to have a space in an IDENTIFIER_NODE? I have a cheeky idea: > - gfc_get_symbol (name, ns, &main_program); > + identifier = gfc_get_string ("PROGRAM %s", name); > That should give reasonable warnings from the middle end, no? I don't know > what it might do to debugging though. Currently one can use "b MAIN__" and "b helloworld" in the debugger: (gdb) b helloworld Breakpoint 1 at 0x400737: file test.f90, line 3. (gdb) b MAIN__ Note: breakpoint 1 also set at pc 0x400737. Breakpoint 2 at 0x400737: file test.f90, line 3. (gdb) b main Breakpoint 3 at 0x4007b9: file test.f90, line 9. I have another idea: Just handle "PROGRAM main" specially by using the name "MAIN__". It should be still quite readable in the middle-end diagnostics. Furthermore, it matches the assembler name and using "b main" one still get something useful - and it is less confusing for everyone (middle end, users of -fdump-tree-original etc.) if there is only a single "main". Tobias Index: gcc/fortran/trans-decl.c =================================================================== --- gcc/fortran/trans-decl.c (Revision 148004) +++ gcc/fortran/trans-decl.c (Arbeitskopie) @@ -289,7 +289,10 @@ gfc_get_label_decl (gfc_st_label * lp) static tree gfc_sym_identifier (gfc_symbol * sym) { - return (get_identifier (sym->name)); + if (sym->attr.is_main_program && strcmp (sym->name, "main") == 0) + return (get_identifier ("MAIN__")); + else + return (get_identifier (sym->name)); } @@ -3874,6 +3877,8 @@ create_main_function (tree fndecl) tmp = build_function_type_list (integer_type_node, integer_type_node, build_pointer_type (pchar_type_node), NULL_TREE); + main_identifier_node = get_identifier ("main"); + ftn_main = build_decl (FUNCTION_DECL, main_identifier_node, tmp); ftn_main = build_decl (FUNCTION_DECL, get_identifier ("main"), tmp); DECL_EXTERNAL (ftn_main) = 0; TREE_PUBLIC (ftn_main) = 1;