This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Another issue with diagnostic format-checker
> From: "Zack Weinberg" <zack@codesourcery.com>
>
> Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
>
> > (1) format checking is done when we use GCC (modulo versions).
> > (2) the bootstrapping compiler is told (via attributes) what to check.
> > (3) the attraibutes are hardwired in the files.
> >
> > the last point is what is causing the trouble.
> >
> > When the current front-end (which we want to build an executable for)
> > invokes the bootstrapping compiler, it is its responsability to tell
> > what is the set of format specifiers. That set is specified
> > statically via -DGCC_DIAG_STYLE=__gcc_xxx__, not the way it is
> > currently done. But statically.
>
> Okay, I understand this. However, this suggests that you intend to
> compile files shared between front ends more than once, with different
> settings of GCC_DIAG_STYLE. I think this is a bad idea. The actual
> content of the file does not change - the .o file should be identical -
> and, in particular, the format specifiers that are used in that file
> do not change. You are in effect doing an intersection operation on
> the diagnostic styles - far better to perform that intersection once,
> write the result into c-format.c, and then wire the appropriate
> settings into the files themselves. Then you need not compile files
> more than once, and you need not add complexity to the Makefile.
> zw
FWIW, I agree we should only compile c-common.c once. That means we
get to choose and apply exactly one single format style.
Currently the "C set" is a proper subset (i.e. completely contained
within) the "C++ set". Therefore the C-set is also the intersection
and it is okay to enforce this format style in c-common.c (as of
today.)
What I tried to explain to Gaby (and either I failed to explain it
well enough or he understood me and saw it as unimportant) is that the
C-set being the intersection is pure happenstance. There's nothing
inherent in the diagnostic framework to enforce this and it could
cause problems in the future if we add wierd specifiers to the C-set
without also adding them to the C++ set. I find this need for
manually synchronizing them error-prone, so I asked Gaby in my first
message to have the C++ format parser call the C format parser to
slurp those specifiers the C frontend already knows about. This would
ensure that the C-set is always the intersection. I think Gaby agreed
to put this on his "TODO" list.
On the issue of where we set GCC_DIAG_STYLE, I lean towards leaving it
as-is. I.e. have a default in toplev.h, but override it in c-tree.h
and cp-tree.h, and live with the file ordering issue.
Gaby's solution provides no clean way to apply the appropriate -D flag
to exactly the right files without introducing problematic changes to
the Makefiles. (I'm willing to be proven wrong by a clean patch.)
Zack's solution requires us to set GCC_DIAG_STYLE in each and every
C-family frontend file. There are around 50 of these files.
It's true that we might need to add GCC_DIAG_STYLE to one or two
frontend files that don't include the appropriate C tree header right
now, but that's much easier than tweeking every single file.
--Kaveh
--
Kaveh R. Ghazi ghazi@caip.rutgers.edu