From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2554 invoked by alias); 20 Aug 2009 22:34:54 -0000 Received: (qmail 2543 invoked by uid 22791); 20 Aug 2009 22:34:53 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail-ew0-f226.google.com (HELO mail-ew0-f226.google.com) (209.85.219.226) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 20 Aug 2009 22:34:46 +0000 Received: by ewy26 with SMTP id 26so271817ewy.29 for ; Thu, 20 Aug 2009 15:34:43 -0700 (PDT) Received: by 10.211.200.7 with SMTP id c7mr663347ebq.54.1250807682898; Thu, 20 Aug 2009 15:34:42 -0700 (PDT) Received: from Paullaptop (203-206-7-21.dyn.iinet.net.au [203.206.7.21]) by mx.google.com with ESMTPS id 5sm878226eyf.18.2009.08.20.15.34.37 (version=SSLv3 cipher=RC4-MD5); Thu, 20 Aug 2009 15:34:40 -0700 (PDT) Message-ID: <330DD244C65240E79CEC30F479932A39@Paullaptop> From: "Paul Edwards" To: "Ulrich Weigand" Cc: References: <200908201651.n7KGpZa4012304@d12av02.megacenter.de.ibm.com> In-Reply-To: <200908201651.n7KGpZa4012304@d12av02.megacenter.de.ibm.com> Subject: Re: i370 port Date: Fri, 21 Aug 2009 02:37:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original 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-08/txt/msg00379.txt.bz2 >> > Hmm, it seems 3.2.x would *always* operate on a function-by-function >> > basis. The unit-at-a-time mode was only introduced with 3.4 (I don't >> > recall if it was already present in 3.3). I don't think there is any >> > way in 3.2.3 to check whether there is a "main" function in the file >> > before it is processed ... >> >> Does that mean I could take advantage of this behaviour? > > I don't think this would be a good idea. You're right. With your new change, I was able to see the difference, and I can see that the static functions sometimes get numbers assigned in a different order (I think first one called), and in that case, with my method the name ends up wrong, but yours works. * S-func dump_new_line prologue @@3 PDPPRLG CINDEX=4,FRAME=104,BASER=12,ENTRY=NO * Function dump_new_line code * Function dump_new_line epilogue PDPEPIL * Function dump_new_line literal pool DS 0F LTORG * Function dump_new_line page table DS 0F * S-func dump_maybe_newline prologue (!!!! your new technique) @@2 PDPPRLG CINDEX=5,FRAME=104,BASER=12,ENTRY=NO B FEN5 L 10,=A(PGT5) * Function dump_new_line code (!!!!!! wrong name) >> /* Store in OUTPUT a string (made with alloca) containing an >> assembler-name for a local static variable named NAME. >> LABELNO is an integer which is different for each call. */ >> >> #ifdef TARGET_PDPMAC >> #define ASM_FORMAT_PRIVATE_NAME(OUTPUT, NAME, LABELNO) \ >> { \ >> (OUTPUT) = (char *) alloca (strlen ((NAME)) + 10); \ >> sprintf ((OUTPUT), "__%d", (LABELNO)); \ >> } > > How does this work? ASM_FORMAT_PRIVATE_NAME is not supposed > to completely ignore the NAME argument, the function may well > be called with the same LABELNO but different NAME strings, > and this must not result in conflicting symbols ... I have compiled the entire GCC and not come up with any duplicate static function names, so I think the number is always unique. >> static void >> i370_output_function_prologue (f, l) >> FILE *f; >> HOST_WIDE_INT l; >> { >> /* Don't print stack and args in PDPMAC as it makes the >> comment too long */ >> #ifdef TARGET_PDPMAC >> fprintf (f, "* %c-func %s prologue\n", >> mvs_need_entry ? 'X' : 'S', >> mvs_function_name); >> #else > > At this point, you may refer to "current_function_decl" to > retrieve information about the function currently being output. > In particular, you can retrieve the original source-level name > associated with the routine via DECL_NAME (current_function_decl). Thanks a lot! I couldn't use that directly, but this: c:\devel\gcc\gcc\config\i370>cvs diff -r 1.37 i370.c Index: i370.c =================================================================== RCS file: c:\cvsroot/gcc/gcc/config/i370/i370.c,v retrieving revision 1.37 retrieving revision 1.38 diff -r1.37 -r1.38 1457c1457 < mvs_function_name); --- > fname_as_string(0)); 1599c1599 < fprintf (f, "* Function %s code\n", mvs_function_name); --- > fprintf (f, "* Function %s code\n", fname_as_string(0)); 1786c1786 < fprintf (file, "* Function %s epilogue\n", mvs_function_name); --- > fprintf (file, "* Function %s epilogue\n", fname_as_string(0)); 1817c1817 < fprintf (file, "* Function %s literal pool\n", mvs_function_name); --- > fprintf (file, "* Function %s literal pool\n", fname_as_string(0)); 1820c1820 < fprintf (file, "* Function %s page table\n", mvs_function_name); --- > fprintf (file, "* Function %s page table\n", fname_as_string(0)); seems to do the trick! BFN. Paul.