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]
Other format: [Raw text]

Re: [PATCH][RFC] -Wno-... option to suppress builtin macro redefined warnings


Simon Baldwin wrote:
Tom Tromey wrote:
"Simon" == Simon Baldwin <simonb@google.com> writes:

... However, it seems to me that we would want to allow redefinition of some macros (__TIME__ et al) but not others (e.g., __LINE__).

So, how about splitting builtin_array into two pieces (and just FYI,
there's a comment above referring to "two tables" that should be
changed) and then unconditionally setting NODE_WARN for one table but
not the other? Or, just adding a special case in the builtin
definition loop for the BT_* constants we care to allow.

Thank you for the note.


I guess that in general it just seems more, um, seamless to either allow or disallow any builtin macro to be redefined. It means that there's no "is it redefinable or not?" decision to be made when new builtins are added. It also neatly sidesteps the issue of then having to document which builtins are redefinable and which aren't (also no update to this doc should new builtins be added), or having to deal with requests to move builtins between redefinable/fixed groups. In other words, the lowest impact on future code maintainers consistent with low impact on current code.

Granted, somebody could well redefine __LINE__ or similar and make a mess of compilation, but there are of course plenty of other ways to make a mess of compilation with other gcc flags. -Wno-builtin-macro-redefined is aimed at the control-freak automated build system rather than the casual user, so it seemed okay, to me anyway, for it to bear closer resemblance to a chainsaw than to a scalpel.

That said, I'm not wildly opposed to creating two "classes" of builtin. It just seems like doing so might sow slightly more confusion than it prevents.

Tom, any further thoughts on this?


It's certainly not hard to split built-in macros into two tiers, those where redefinition warning can be suppressed by providing -Wno-builtin-macro-redefined, and those where it can't. However, since it's all just about suppressing a warning, it may be that one policy to cover all of them will suffice, and be simpler to manage and maintain.

Thanks.


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