Hi Yehezkel, Please do not cross post to GCC and GCC-Patches. > My problem is that sometime there is specific warning that can't be resolve, > so I want to ignore it. GCC does not, currently, provide the #pragma facility you are looking for. Do not lose hope! There are viable alternatives. The first best way to fix the code so it no longer emits the warning. Alas, you've stated you cannot do this. :-( NOTE: Have warnings turned up as verbose as your team can tolerate! [see below] The next best way to ignore the undesired warning is to post-process the output of GCC to a script (such as a Perl script) that strips out the specific, exact warning you want to ignore. The next way to ignore the undesired warning is to disable the warning for that translation unit. -Wno-foozle-mcgoogle, just for that particular translation unit. That's a mighty big hammer, though. And if the warning is in a header file, it may be pervasive throughout your entire project -- to which I'd direct you to the post-processing script solution (assuming you are disallowed from fixing the code). HTH, --Eljay PS: here are the warnings I personally use in my g++ wrapper script w++ (notable absences -- I do not enable -Wunreachable-code nor -pedantic in my wrapper script): >cat ~/bin/w++ /usr/bin/g++ \ -ansi \ -Wno-long-long \ -Wall \ -Wextra \ -Weffc++ \ -Wredundant-decls \ -Wstrict-null-sentinel \ -W#warnings \ -Wfloat-equal \ -Wmissing-format-attribute \ -Wmissing-noreturn \ -Wpacked \ -Wshadow \ -Wunused-macros \ -Wcast-align \ -Wcast-qual \ -Wconversion \ -Wctor-dtor-privacy \ -Wdeprecated \ -Wdeprecated-declarations \ -Wendif-labels \ -Wextra \ -Wformat-extra-args \ -Winline \ -Winvalid-offsetof \ -Wmissing-field-initializers \ -Wnon-lvalue-assign \ -Wnon-virtual-dtor \ -Woverloaded-virtual \ -Wpmf-conversions \ -Wpointer-arith \ -Wshorten-64-to-32 \ -Wsign-compare \ -Wsign-promo \ -Wundef \ -Wwrite-strings \ -Wold-style-cast \ -Wno-unreachable-code \ -fdollars-in-identifiers \ "$@" You may wonder "Why -fdollars-in-identifiers?" (Note: -pedantic warns about even with the flag.) I use these kinds of macros: #define DEBUG$($1, $2, $3) $1 << "Debug: " << $2 << $3 << std::endl #define $FOO 77 // Avoid! prefer: int const kFoo = 77; #define $Foo_Bar_h // Header guard. I try to avoid macros (macro constants and macro functions) like the plague. They do not honor namespaces. Their heavy black jackboots walk all over your code. They can ruin your day. Having a $ in their names helps keep the hot side hot, and the code side code. I do use them without reservation for header guards and to include/exclude platform specific code segments, for assertions, debug droppings, and a few other more questionable practices. The use of the $ character is a DEC VMS-ism I've never quite shaken out of my system.
