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.
Related
As I read on Intel's website:
Intel compiler uses /fp-model fast=1 as defaults. This optimization
favors speed over standards compliance. You may use compiler option
-mieee-fp to get compliant code.
My understanding of the fp-model option in ICC is that (correct me if I'm wrong):
precise corresponds to default settings in GCC and Clang,
fast=2 is similar to -ffast-math,
fast=1 is somewhere between.
What options in GCC or Clang would make floating point math most similar to Intel's default -fp-model fast=1?
As it follows from GCC's set_fast_math_flags function, ffast-math option (at least in GCC 5.2) is equivalent to
(1) unsafe opts group:
-fno-trapping-math
-fassociative_math
-fno-signed-zeros
-freciprocal-math
(2) other guys:
-ffinite-math-only
-fno-errno-math
-fno-signaling-nans
-fno-rounding-math
-fcx-limited-range
First group is abbreviated with the option -funsafe-math-optimizations.
You should figure out what comes in ICC and try to combine those flags to make desired effect.
The GCC docs at http://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html say (under -ffreestanding) that a freestanding environment implies -fno-builtin. I might be misunderstanding exactly what a freestanding environment is or how it works, but it seems to me that, since the builtins usually emit inline code instead of calling the library function, this is ideal for a freestanding environment where the standard library may be missing functionality or even missing entirely.
So why would we not want to use the biltins with a freestanding environment?
In freestanding mode the compiler can not rely on semantical considerations.
Most builtins in GCC work silently -- for instance the compiler sees that you are using strcpy() and in hosted mode it may guess that, when you are using strcpy(), you are intending exactly to copy a string. Then it may replace strcpy with an extensionally equivalent builtin, which is better for the given target to copy a string.
In freestanding mode, using strcpy() function means ANYTHING. The idea is just not the standard library absence in linkage. The idea of freestanding mode is that there is no standard library even on definition level, except float.h, iso646.h, limits.h, stdarg.h, stdbool.h, stddef.h, stdint.h (C99 standard 4.6). You may in freestanding mode decide to format your hard drive with strcpy, and this is perfectly legal for the C language. The compiler thus don't know how to use builtins, and it declines to use them at all.
Is there a site listing the various platforms and their support for GCC's atomic built-ins, for the various GCC versions?
EDIT:
To be more clear:
GCC adds _sync... as intrinsics on platforms it contains support for. On all other platforms it keeps those as normal functions declarations but does not supply an implementation. This must be done by some framework.
So the question is: For which platforms does GCC supply which intrinsics without need to add a function implementation?
I'm not aware if there's such a list, however http://gcc.gnu.org/projects/cxx0x.html says atomics are supported since GCC 4.4.
GCC libstdc++ implements <atomic> on top of the builtin functions `__sync_fetch_and_add' and friends ( http://gcc.gnu.org/onlinedocs/gcc-4.6.1/gcc/Atomic-Builtins.html ).
These functions are expanded either using machine specific expanders in the machine description of the target (usually in a file named `sync.md') or, lacking such expanders, using a CAS loop. If the presense of `sync.md' file is any indication for a proper atomics support, then you can count in MIPS, i386, ARM, BlackFin, Alpha, PowerPC, IA64 and Sparc.
[Though this is an old question, I thought I should update and complete the answer]
I am not aware of a per-architecture-version and per-gcc-version table, describing supported built-ins.
The __sync built-in functions of gcc exist since version 4.1 (see, e.g., gcc 4.1.2 manual. As stated there:
Not all operations are supported by all target processors. If a particular operation cannot be implemented on the target processor, a warning will be generated and a call an external function will be generated. The external function will carry the same name as the builtin, with an additional suffix `_n' where n is the size of the data type.
So, when there is not an implementation for a specific architecture, a compilation warning will appear and, I guess, a link-time error, unless you provide the required function with the appropriate name.
After gcc 4.7 there are also __atomic built-ins and __sync built-ins are deprecated.
For example, see how Fedora uses gcc __sync and __atomic here
The Intel compiler appears to accept the -fno-strict-aliasing flag verbatim, but I have not seen that behavior documented anywhere, and the flag may be ignored. Flags such as -no-ansi-alias look related, but I want to be sure I specify exactly the right behavior.
ICC accepts most gcc switches and does the right thing with them. If you want to use the ICC-specific switch though then I think this is probably the one:
-[no-]ansi-alias
enable/disable(DEFAULT) use of ANSI aliasing rules optimizations;
user asserts that the program adheres to these rules
When these replies were posted, Intel compilers did in fact default to -fno-ansi-alias, but it has since changed (at least for linux).
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