From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-patches-return-229267-listarch-gcc-patches=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 31533 invoked by alias); 21 Oct 2008 17:37:19 -0000
Received: (qmail 31522 invoked by uid 22791); 21 Oct 2008 17:37:18 -0000
X-Spam-Check-By: sourceware.org
Received: from ug-out-1314.google.com (HELO ug-out-1314.google.com) (66.249.92.169)     by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 21 Oct 2008 17:36:43 +0000
Received: by ug-out-1314.google.com with SMTP id t39so1022403ugd.10         for <gcc-patches@gcc.gnu.org>; Tue, 21 Oct 2008 10:36:39 -0700 (PDT)
Received: by 10.86.52.6 with SMTP id z6mr8230230fgz.18.1224610598837;         Tue, 21 Oct 2008 10:36:38 -0700 (PDT)
Received: by 10.86.94.6 with HTTP; Tue, 21 Oct 2008 10:36:38 -0700 (PDT)
Message-ID: <303e1d290810211036j2e403cd0wb563ce286f84216b@mail.gmail.com>
Date: Tue, 21 Oct 2008 18:42:00 -0000
From: "David Edelsohn" <dje.gcc@gmail.com>
To: "GCC Patches" <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] Clean global object source of file function name (PR target/35485)
In-Reply-To: <48FD1776.9060405@codesourcery.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <303e1d290810151905u74b1dea8vb479cca462ceee62@mail.gmail.com> 	 <303e1d290810170627n26152fabm8fb2f4ea60a99b6a@mail.gmail.com> 	 <48FD1776.9060405@codesourcery.com>
Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-patches.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-help@gcc.gnu.org>
Sender: gcc-patches-owner@gcc.gnu.org
X-SW-Source: 2008-10/txt/msg00889.txt.bz2

On Mon, Oct 20, 2008 at 7:42 PM, Mark Mitchell <mark@codesourcery.com> wrote:
> David Edelsohn wrote:
>
>>         PR target/35485
>>         * tree.c (get_file_function_name): Clean first_global_object_name.
>
> This is OK, but I think it would be slightly cleaner to move the
> clean_symbol_name call out of the three if/else cases and put it right
> before the alloca call.  That would make obvious that we always clean
> the name before allocating the final symbol.  If that makes sense to
> you, that change is pre-approved.

This is what I checked in:

Index: tree.c
===================================================================
--- tree.c      (revision 141258)
+++ tree.c      (working copy)
@@ -6923,7 +6923,7 @@

   /* If we already have a name we know to be unique, just use that.  */
   if (first_global_object_name)
-    p = first_global_object_name;
+    p = q = ASTRDUP (first_global_object_name);
   /* If the target is handling the constructors/destructors, they
      will be local to this file and the name is only necessary for
      debugging purposes.  */
@@ -6940,7 +6940,6 @@
       else
        p = file;
       p = q = ASTRDUP (p);
-      clean_symbol_name (q);
     }
   else
     {
@@ -6959,7 +6958,6 @@
       len = strlen (file);
       q = (char *) alloca (9 * 2 + len + 1);
       memcpy (q, file, len + 1);
-      clean_symbol_name (q);

       sprintf (q + len, "_%08X_%08X", crc32_string (0, name),
               crc32_string (0, get_random_seed (false)));
@@ -6967,6 +6965,7 @@
       p = q;
     }

+  clean_symbol_name (q);
   buf = (char *) alloca (sizeof (FILE_FUNCTION_FORMAT) + strlen (p)
                         + strlen (type));