This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: [PATCH] Clean up diagnostics for static ctors/dtors



Chip --
  
  Thanks for your patch.  One question:

+	      p = file_function_name_type (DECL_NAME (current_function_decl));
+	      if (p)
+		{
+		  fmt = "In %s:\n";
+		  switch (*p)
+		    {
+		    case 'I':
+		      p = "static initialization";
+		      break;
+		    case 'D':
+		      p = "static destruction";
+		      break;
+		    default:
+		      p = NULL;	/* don't print confusing names */
+		      break;
+		    }

  That looks like to me we'll end up with `fmt' equal to `In %s:\n'
and `p' equal to `NULL' for the newly renamed SSDF functions.  Then,
we try to do:

+		  if (doing_line_wrapping ())
+		    output_printf (&buffer, fmt, p);
+		  else
+		    notice (fmt, p);

which is bad: we're passing a NULL string for the `%s' format
specifier.  At best, this will yield a confusing error message.  But,
I like the basic idea.

As for this question:

  But I'll
  bet there's a good reason that static init code is (sometimes?) in a
  function that's not labelled as a static initializer....  ?

Yup.  Sometimes we only want to put out initializers that are needed,
in the sense that the GCC back-end is going to emit a reference to
them.  But, we don't know that until its generated assembly code for
the function, unfortunately.  So, we have to keep generating these
dinky little functions.  This is sort-of a design bug in the way the
back-end/front-end interaction works.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]