This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: RFA: Making attribute values avaliable for options
Quoting "Joseph S. Myers" <joseph@codesourcery.com>:
On Tue, 5 Jul 2011, Joern Rennecke wrote:
This patch splits out a new generator genattr-enum from genattr, and it
generates insn-attr-enum.h, which just makes the enum declarations.
This new header file is then included by options.c and insn-attr.h .
Is there a particular reason for making this separate from the existing
genattr-common that I created recently?
I don't see any technical reason why it would to build failures, short
of a name clash (although name clashes are not that far-fetched - one
of the
reasons insn-attr.h can't be included by option.h is that genautomata.c
has a name clash on state_t).
It's just that AFAICS the opts.c has no need to know about these enum values.
You'll have to tolerate every enum constant of every target in the namespace
of opts.c
If we decide that insn-attr-common.h is open for anything that doesn't
require another header to be included, and name clashes should be avoided /
resolved as appropriate, that's fine with me.
Like opts.c, options.c is a file
shared by both the driver and the core compiler that can't include the
full insn-attr.h for the same reason.
Well, FWIW, at the moment, I can actually build both cc1 and xgcc when
I hand-edit options.c to include inns-attr.h . It just doesn't seem like a
good idea, with all these masses of dependencies that are implied.