Which Intel Fortran compiler flag should I use to be warned about implicit conversions?
In gfortran, it is -Wconversion, which gives warnings like:
"Possible change of value in conversion from REAL(4) to INTEGER(4)"
Intel Fortran doesn't have a warning for that, which in general is behavior specified by the Fortran standard. Certainly that could be useful in some situations to alert you to possible issues. Intel Fortran does have an extension to do free converts between numeric and LOGICAL types, and this will be detected if you enable standards warnings (-std or /stand).
Related
In the GCC built-ins description, it says:
GCC provides built-in versions of the ISO C99 floating-point comparison macros that avoid raising exceptions for unordered operands. They have the same names as the standard macros ( isgreater, isgreaterequal, isless, islessequal, islessgreater, and isunordered) , with _builtin prefixed. We intend for a library implementor to be able to simply #define each standard macro to its built-in equivalent. In the same fashion, GCC provides fpclassify, isfinite, isinf_sign, isnormal and signbit built-ins used with _builtin prefixed. The isinf and isnan built-in functions appear both with and without the _builtin prefix.
So, I'm not quite able to parse this. When should floating-point comparisons raise exceptions? Does the C standard mandate they do? Mandate they don't? Doesn't mandate anything? And - does __builtin_isnan() act differently than isnan() ?
By exception here, the GCC docs refer to IEEE 754 floating point exceptions. If you do something like
a < b
and one of the operands is a NaN, an FP exception (invalid) will be raised. That means a bit in the FPU will remain set until it's explicitly cleared by the programmer. By instead using isgreater/isless/etc. the programmer can avoid triggering the FP exception.
I was told to post compiling questions on stackoverflow so this is the same question I've posted to Ubuntu Ask!:
I'm trying to compile a program that came with a Makefile. The makefile uses f77 and it seems that the programs call several f95 intrinsics. When I try to compile I get:
plotkit.a(userid.o): In function userid_':
fort77-5163-1.c:(.text+0x13e): undefined reference togetgid_' fort77-5163-1.c:(.text+0x234): undefined reference to `getuid_' collect2: error: ld returned 1 exit status
I also get the same error with fdate on another program in this distribution. I've tried to change the makefile to use different compilers such as gfortran) and they all cause MORE errors.
My question is how do I get getgid, getuid, and fdate to work with a f77 program? I'm additionally confused because there are getgid and getuid man pages but no installation on ubuntu?
I have a 64 bit 14.04 LTS installation.
Thanks for any ideas.
By default, gfortran (and other Fortran compilers) mangle procedure names by adding an underscore. When you reference getgid in source, the compiler changes that to getgid_. If the function getgid isn't defined in Fortran source, e.g. in C, then this will cause link errors such as the one you are encountering.
The functions getgid, getuid, etc are not Fortran functions, they are standard C library functions. If the code you are using is from somewhere else, look and see if the provided Makefiles have options listed to disable default underscoring by Fortran. For gfortran, this option is -fno-underscoring. Append this to the compiler flags used for the Fortran compiler in the makefile. For other Fortran compilers, consult their documentation for similar options.
If you aren't restricted to F77 and can make use of modern Fortran features, the other option is to fix this by providing interoperable interfaces for C library functions. e.g.
interface
function getgid() bind(C,name='getgid')
use iso_c_binding
implicit none
integer(c_int32_t) :: getgid
end function getgid
end interface
This will define an explicit interface for the C library function getgid so that you can call it from a modern Fortran implementation. You would define interfaces like this for each of the C library functions you need to call.
* As an aside, while the above interface works and is portable from a modern Fortran perspective, it isn't 100% portable from a C library perspective. The GNU implementation of getgid returns the type gid_t which though a long chain of typedefs is finally related to a true type in the files /usr/include/bits/types.h and /usr/include/bits/typesizes.h as an unsigned 32 bit integer. Fortran doesn't have unsigned types so while the storage sizes will match, if these functions ever return values above around 2 billion, they will be misinterpreted in Fortran as negative values. Also, since the storage type of gid_t is defined in the "bits" C header tree, they are potentially non-portable (not sure if the storage size is specified in POSIX or some other standard or implementation dependent).
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