This piece of code:
Int32 status;
printf("status: %x", status)
gives me the following warning:
jpegthread.c:157: warning: format '%x' expects type 'unsigned int', but argument 3 has type 'Int32'
I know I can get rid of it by casting the type, but is it possible with a GCC compiler flag to get rid of that particular type of warning, and still use -Wall?
If you need that code to work portable then you should cast the argument to unsigned int, as the int type may have a different size than Int32 on some platforms.
To answer your question about disabling specific warnings in GCC, you can enable specific warnings in GCC with -Wxxxx and disable them with -Wno-xxxx.
From the GCC Warning Options:
You can request many specific warnings with options beginning -W, for example -Wimplicit to request warnings on implicit declarations. Each of these specific warning options also has a negative form beginning -Wno- to turn off warnings; for example, -Wno-implicit. This manual lists only one of the two forms, whichever is not the default.
For your case the warning in question is -Wformat
-Wformat
Check calls to printf and scanf, etc., to make sure that the arguments supplied have types appropriate to the format string specified, and that the conversions specified in the format string make sense. This includes standard functions, and others specified by format attributes (see Function Attributes), in the printf, scanf, strftime and strfmon (an X/Open extension, not in the C standard) families (or other target-specific families). Which functions are checked without format attributes having been specified depends on the standard version selected, and such checks of functions without the attribute specified are disabled by -ffreestanding or -fno-builtin.
The formats are checked against the format features supported by GNU libc version 2.2. These include all ISO C90 and C99 features, as well as features from the Single Unix Specification and some BSD and GNU extensions. Other library implementations may not support all these features; GCC does not support warning about features that go beyond a particular library's limitations. However, if -pedantic is used with -Wformat, warnings will be given about format features not in the selected standard version (but not for strfmon formats, since those are not in any version of the C standard). See Options Controlling C Dialect.
It looks like the GCC manual does provide a way to do this with a #pragma, actually (contrary to what Aiden Bell says):
6.62.13 Diagnostic Pragmas
E.g., for the -Wuninitialized warning, you can do...
#pragma GCC diagnostic ignored "-Wuninitialized"
... to suppress the warning, or...
#pragma GCC diagnostic warning "-Wuninitialized"
... to treat it as a warning (not an error) even if you're building with -Werror.
I used the following CFLAGS:
-Wall -Wformat=0
I presume you are looking for the
#ifdef WIN32
#pragma warning (disable: #num of the warning)
#endif
Equivalent in GCC...
You can search for options such as -Wno-conversion -Wno-format-security that do the job in 3.8 Options to Request or Suppress Warnings.
But in terms of the #pragma directive:
I quote from the GCC mailing list from Google:
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).
So currently no, there is no #pragma directive to disable specific warnings. Rather than using -Wall you could turn on as many warnings as you can minus specific ones.
http://www.network-theory.co.uk/docs/gccintro/gccintro_31.html
Or fix the code
Related
/Oi allows the VC++ compiler to use intrinsics. What is the equivalent in gcc 9 or 10?
Would gcc -O3 compiler option enable the use of intrinsics?
What you are searching is Built-in Functions.
https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/Other-Builtins.html
Builtins are enabled by default :
-fno-builtin
-fno-builtin-function
Don’t recognize built-in functions that do not begin with ‘__builtin_’ as prefix. See Other built-in functions provided by GCC, for details of the functions affected, including those which are not built-in functions when -ansi or -std options for strict ISO C conformance are used because they do not have an ISO standard meaning.
GCC normally generates special code to handle certain built-in functions more efficiently; for instance, calls to alloca may become single instructions which adjust the stack directly, and calls to memcpy may become inline copy loops. The resulting code is often both smaller and faster, but since the function calls no longer appear as such, you cannot set a breakpoint on those calls, nor can you change the behavior of the functions by linking with a different library. In addition, when a function is recognized as a built-in function, GCC may use information about that function to warn about problems with calls to that function, or to generate more efficient code, even if the resulting code still contains calls to that function. For example, warnings are given with -Wformat for bad calls to printf when printf is built in and strlen is known not to modify global memory.
With the -fno-builtin-function option only the built-in function function is disabled. function must not begin with ‘__builtin_’. If a function is named that is not built-in in this version of GCC, this option is ignored. There is no corresponding -fbuiltin-function option; if you wish to enable built-in functions selectively when using -fno-builtin or -ffreestanding, you may define macros such as:
#define abs(n) __builtin_abs ((n))
#define strcpy(d, s) __builtin_strcpy ((d), (s))
https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html#C-Dialect-Options
When you see the optimisations which turn on with O3, there is no mention of builtin. https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html
I'm looking for a simple way to localize certain g++ (g++-4.9 to be specific) compile options to certain lines of code or at least targeted functions. I'm interested generally speaking, but also specifically to the -fast-math, -ffinite-math-only and -fno-signed-zeros options.
I presume that localization at the *.cpp file level is possible with make utility, but I'm hoping there is a way to enable it in the code itself, through #pragma or __attribute__ or something. I want to do this not only to minimize dependencies to external files (i.e. risk of incorrect makefile) but also to hopefully hyperlocalize certain FP behavior to specific equations within a function.
Alternatively, if localization of FP behavior by inline directives is NOT possible, what can I do to at least trigger a compile time error if desired compiler directive is NOT enabled in project build (e.g. makefile is lost or inappropriately modified).
I would presume that such inline optimization might be compiler specific, g++ in this case, but that is a compromise I'm willing to take.
In gcc you can use function attribute optimize:
void f () __attribute__ ((optimize("fast-math"), optimize("finite-math-only"), optimize("no-signed-zeros")));
I'm not sure that you are using the "localize" word correctly. Localization is related to adapting software to users of different human languages (French, Russian, Chinese...)
Perhaps you want to ask the compiler to optimize some functions with other optimization flags.
This is possible using #pragma GCC optimize etc... or using some function attributes
You might be able to turn on some bits of this with the fpmath option in a function attribute, but this was not clear to me from the docs. In light of that, I will focus on detection instead:
-fast-math already turns on -ffinite-math-only, so you don't need to worry about that. The docs for -fast-math say:
This option causes the preprocessor macro FAST_MATH to be
defined.
Which means it can be detected via
#ifndef __FAST_MATH__
#error "The -fast-math compiler option is required"
#endif
I have not yet found a compile-time way to detect the presence of -fno-signed-zeros
MingGW's gcc (4.8.1) reports the following error (and more to come) when I try to compile Expstack.c:
parser.h:168:20: error: field '__p__environ' declared as a function
struct term *environ;
where 'environ' is declared inside 'struct term{ ... }'. In unistd.h you find
char **environ
but nowhere a '__p__environ'.
Some other fields are declared likewise, but are accepted. Subsequent errors related to environ are reported as follows
Expstack.c:1170:38: error: expected identifier before '(' token
case Term_src: return e->item.src->environ;
^
Cygwin's gcc (4.8.3) accepts these constructs and has done so over various versions since
2006 at least, and gcc with various versions of Linux before that.
The source text uses CRLF despite my attempts to convert to DOS, and this is my only guess for an explanation.
I'll appreciate clues or ideas to fix the problem, but renaming the field is not especially attractive and ought to be totally irrelevant.
This is very unlikely to have to do with CR/LF.
The name ought to be irrelevant but it isn't: this one relates to the Windows integration that MinGW does and Cygwin does not, as alluded to in http://sourceforge.net/p/mingw/mailman/message/14901207/ (that person is trying to use an extern environ that it expects to be defined by the system. Clearly, the fashion in which MinGW developers have made this variable available breaks the use of the name as a struct member).
You should report this as a MinGW bug. Unpleasant as it may be, in the interim, renaming the member is the simplest workaround. It is possible that a well-placed #undef environ might help, but no guarantees.
I installed gcc4.9 using the steps mentioned in the SO post here. I was using the latest feature std::exchange() utility function which is introduced in C++14.
#include<list>
#include<utility>
int main() {
std::list<int> lin{5,6,7,8,9};
auto lout = std::exchange(lin, {1,2,3,4});
return 0;
}
I performed following steps to compile the above sample program and got the following compilation error. After sometime I realized that (as there is no warning/hint by compiler message) this feature has been added in the C++14 standard so I need to use -std=c++1y here.
$g++ -std=c++11 main.cpp
main.cpp: In function ‘int main()’:
main.cpp:5:14: error: ‘exchange’ is not a member of ‘std’
auto lout = std::exchange(lin, {1,2,3,4});
^
If we use the C++11 standard feature and does not provide -std=c++11, then GCC gives warning message/hint that your program is using the feature which is introduced in the C++11 as below:
main.cpp:4:21: warning: extended initializer lists only available with
-std=c++11 or -std=gnu++11
std::list<int> lin{5,6,7,8,9};
This message is great and lets the user distinguish between the actual compilation error message and not including -std=c++11 option.
However while using gcc4.9 for C++1y feature under -std=c++11, there is no such warning message/hint? I wanted to know what could be the possible reason for this?.
The error/warning about "extended initializer lists" is emitted by the C++ parser. The C++
parser apparently knows how to parse that syntactic construct, understands it and can
provide a sensible error/warning message.
With the function, the situation is a little bit different. The GCC proper does not
contain knowledge about each and every standard function. For some functions it does, but
for most functions it doesn't.
From the compiler proper point of view, std::exchange is just an unknown identifier, the compiler does not contain special knowledge about the standard function std::exchange, and, hence, treats it as any other unknown identifier.
Instead of going through a list of of possible standards seeing which doesn't give errors, is there just a simple gcc option I can use (just checked, not likely) or a config file or info file in the system that says?
Use the -std option to control the language standard used. Values of either c89 (which is the same as using -ansi for C code) or c99 are likely what you want, but there are GNU dialects of both, plus others listed in the manpage.
-std=gnu89 is the default for C, which is "GNU dialect of ISO C90 (including some C99 features)." (ISO's 1990 C standard is ANSI's 1989 standard, known as C89.)
Maybe i'm missing something, but there is the -std= option, documented here.