This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Clean up diagnostics for static ctors/dtors
- To: chip at valinux dot com
- Subject: Re: [PATCH] Clean up diagnostics for static ctors/dtors
- From: Mark Mitchell <mark at codesourcery dot com>
- Date: Fri, 25 Feb 2000 02:06:37 -0800
- Cc: gcc-patches at gcc dot gnu dot org
- Organization: CodeSourcery, LLC
- References: <20000223203918.F471@perlsupport.com>
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