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 to eliminate DECL_FIELD_SIZE


    The problem I have with comments asking someone to coordinate the two
    places is that it relies on human vigilance, which is sporadic.  Even
    if the gcc programmer is vigilant, it also relies on error prone
    visual inspection of the two places.  Its easy to have a missing entry
    and then all the strings following that entry are off by one.

True, but if one if making a *change*, it's not so bad since you basically
make the change in two places.

    I see your point about .def files being "heavy", especially for
    `built_in_class_names' which only has four elements.  

Well, I wasn't even thinking about doing *that one* at all!

    But I don't know if I'd consider `built_in_names' in that category.

I was thinking of the number of *uses*: we just have the enum table
and the name.  Note that in the config files there are *plenty* of
cases like this with register classes and register numbers, so this
is hardly a unique issue within GCC, though I'd be the first to say
that that doesn't argue in favor of adding another one.

    So anyway, another approach might be to use the enums themselves to
    index the initialization of the string array.  E.g.

     > built_in_names[BUILT_IN_ALLOCA] = "BUILT_IN_ALLOCA";

That's an idea, but is run-time and so would have to be put in
some function that's called, which adds complexity.

Perhaps the right approach is indeed to do the .def file, but also use
them for parameter types.  Let me look into that.

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