This is the mail archive of the gcc-bugs@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]

[Bug bootstrap/85921] /gcc/c-family/c-warn.c fails to build


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85921

Martin Sebor <msebor at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |msebor at gcc dot gnu.org

--- Comment #15 from Martin Sebor <msebor at gcc dot gnu.org> ---
I introduced the noinline variable in r255469 to avoid having to repeatedly
spell it out and quote it in warning mnessages (it was not quoted before then
even hough it should have been).  Besides reducing the number of uses of the
"noinline" string from eight to just one it also reduced the number of warning
messages printed by the function to (I think) just one so whether the word is
quoted inline or as a variable matters less than it may have.  It seems to me
that if the name of the variable is causing a problem the easiest solution is
to rename it to something innocuous.

Beyond that, #defining macros that match known attributes to something else
seems like asking for trouble.  It even came up at the last WG14 meeting in the
context of the newly proposed C [[attributes]]: is something like

  #define deprecated "foobar"
  #include <stdio.h>

a valid C (or C++) program?  (Should it be?)

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