/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
Related
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).
For an embedded project (bare-metal) I need to use memc** functions.Though I haven't
disable the builtin functions I always get a linker error; e.g:
undefined reference to `memcmp'
no matter if I use: memcmp or __builtin_memcmp!
Is there anything I missed to enable the builtins?
My compile options are: -g -Wall -mcpu=cortex-a9
__builtin is a bit of a lie. It will optionally use a built-in implementation, if it exists. Otherwise it will call the library functions. You will need to provide implementations of these functions, either in your own code or in a C library. Note that "a C library" doesn't mean a full OS libc, there are plenty of bare metal C libraries that don't include OS-dependent functions.
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
I don't know how feasible it is and how sensible is this question here.
Is there any changes that we can make in makefile to recommend GCC inline all the function although the functions are not inlined during the declaration or nowhere in the source file.
There are a few ways you can make gcc inline functions. One of them is the option -finline-functions, which will make gcc inline "simple" functions. The compiler uses some heuristics to determine whether the function is small enough to be inlined. However, the user has some control over this algorithm through -finline-limit. Read the gcc manual to find the actual values you need.
When inlining functions you should remember that obviously not all functions can be inlined (the simplest example being recursive functions) and the compiler can inline only functions defined within the same translation unit. Also, it is worth mentioning that -finline-functions is on by default at -O3, so just -O3 may sometimes be your solution.
In the makefile you will have to add the right options to all calls to gcc. In a well written makefile you'll easily spot variables with other gcc options, where you can simply place your own.
The gcc -finline_functions option sounds like it might do what you want. Here is some documentation. If your makefile defines a CFLAGS variable, that would be the place to put it.