dealing with built-in functions

dealing with built-in functions

[Florian Gleixner]

Hi,

i try to fugure out what is the "best way". The following code throws a
warning:

#include <stdio.h>
#include <math.h>

int main(void)
{
  double x=1.7;
  printf("%f %f",x,round(x));
}

gcc r.c -lm
r.c: In function 'main':
r.c:9: warning: incompatible implicit declaration of built-in function
'round'

I can avoid this by using the compiler switch -fno-builtin. But as far
as i understand, the built in functions are optimized. So if i use
-fno-builtin, i lose some cycles?
I can also put at line 3:
extern double round(double);
and then i don't need the -fno-builtin. But what does that mean? Which
round() do i use then? Can i avoid the warning if i use other types of
variables - i don't know how the built-in round() is defined.
Other thoughts?

Thank you!

Flo

Re: dealing with built-in functions

[Brian Dessent]

Florian Gleixner wrote:

> gcc r.c -lm
> r.c: In function 'main':
> r.c:9: warning: incompatible implicit declaration of built-in function
> 'round'

I'm assuming that your C library is glibc, i.e. you're using Linux.  It
is always a good idea to state what platform you are using, because gcc
supports many dozens of platforms so don't assume we know what you're
using.

The problem you are seeing is that glibc has a number of feature levels
that it supports.  By default, it only exposes a fraction of available
features (C90) in its headers.  You have to explicitly define the level
of feature support that you want:
<http://www.gnu.org/software/libc/manual/html_node/Feature-Test-Macros.html>. 
Defining _GNU_SOURCE gets you everything and is the most commonly used,
e.g. by adding -D_GNU_SOURCE to CFLAGS.  I think that if you use
autoconf, it takes care of this for you if it detects you're on a glibc
system, but I could be wrong.

double() is a C99 feature, so without any feature defines glibc's math.h
does not declare it.  Thus to avoid the warning and still used the
optimized gcc builtin, you just need to define _GNU_SOURCE (or
_ISOC99_SOURCE).

Brian

Re: dealing with built-in functions

[Andrew Haley]

Florian Gleixner writes:
 > Hi,
 > 
 > i try to fugure out what is the "best way". The following code throws a
 > warning:
 > 
 > #include <stdio.h>
 > #include <math.h>
 > 
 > int main(void)
 > {
 >   double x=1.7;
 >   printf("%f %f",x,round(x));
 > }
 > 
 > gcc r.c -lm
 > r.c: In function 'main':
 > r.c:9: warning: incompatible implicit declaration of built-in function
 > 'round'
 > 
 > I can avoid this by using the compiler switch -fno-builtin. But as far
 > as i understand, the built in functions are optimized. So if i use
 > -fno-builtin, i lose some cycles?
 > I can also put at line 3:
 > extern double round(double);
 > and then i don't need the -fno-builtin. But what does that mean? Which
 > round() do i use then? Can i avoid the warning if i use other types of
 > variables - i don't know how the built-in round() is defined.
 > Other thoughts?

Look at the Fine Man Page:

NAME
       round, roundf, roundl - round to nearest integer, away from zero

SYNOPSIS
       #include <math.h>

       double round(double x);
       float roundf(float x);
       long double roundl(long double x);

       Compile with -std=c99; link with -lm.

Note the last line.

Andrew.

Re: dealing with built-in functions

[flo]

Brian Dessent schrieb:
> Florian Gleixner wrote:
> 
>> gcc r.c -lm
>> r.c: In function 'main':
>> r.c:9: warning: incompatible implicit declaration of built-in function
>> 'round'
> 
> I'm assuming that your C library is glibc, i.e. you're using Linux.  It
> is always a good idea to state what platform you are using, because gcc
> supports many dozens of platforms so don't assume we know what you're
> using.
> 

Good guess. I will be more verbose next time.

> The problem you are seeing is that glibc has a number of feature levels
> that it supports.  By default, it only exposes a fraction of available
> features (C90) in its headers.  You have to explicitly define the level
> of feature support that you want:
> <http://www.gnu.org/software/libc/manual/html_node/Feature-Test-Macros.html>. 
> Defining _GNU_SOURCE gets you everything and is the most commonly used,
> e.g. by adding -D_GNU_SOURCE to CFLAGS.  I think that if you use
> autoconf, it takes care of this for you if it detects you're on a glibc
> system, but I could be wrong.

Autoconf did not help me here automatically. But maybe i have to change
something in configure.ac?
So what is the "right way"? Use -D_GNU_SOURCE while compiling or add a
#define? I decided to add the #define, and it works. Thank you for your
explanation and help!

Flo

Re: dealing with built-in functions

[Brian Dessent]

flo@redflo.de wrote:

> Autoconf did not help me here automatically. But maybe i have to change
> something in configure.ac?
> So what is the "right way"? Use -D_GNU_SOURCE while compiling or add a
> #define? I decided to add the #define, and it works. Thank you for your
> explanation and help!

It looks like you can just add the AC_USE_SYSTEM_EXTENSIONS macro
somewhere early in your configure.ac to get a combined set of related
checks. 
<http://www.gnu.org/software/autoconf/manual/html_node/Posix-Variants.html>.

Alternatively, you could call AC_PROG_CC_C99 which would end up setting
CC to gcc -std=gnu99, which in turn should cause _ISOC99_SOURCE to be
defined.  This may be a bigger hammer than you require, depending on how
much C99 your code requires. 
<http://www.gnu.org/software/autoconf/manual/html_node/C-Compiler.html#index-AC_005fPROG_005fCC_005fC99-750>

Brian

Re: dealing with built-in functions

[Andrew Haley]

flo@redflo.de writes:
 > Brian Dessent schrieb:
 > > Florian Gleixner wrote:
 > > 
 > >> gcc r.c -lm
 > >> r.c: In function 'main':
 > >> r.c:9: warning: incompatible implicit declaration of built-in function
 > >> 'round'
 > > 
 > > I'm assuming that your C library is glibc, i.e. you're using Linux.  It
 > > is always a good idea to state what platform you are using, because gcc
 > > supports many dozens of platforms so don't assume we know what you're
 > > using.
 > > 
 > 
 > Good guess. I will be more verbose next time.
 > 
 > > The problem you are seeing is that glibc has a number of feature levels
 > > that it supports.  By default, it only exposes a fraction of available
 > > features (C90) in its headers.  You have to explicitly define the level
 > > of feature support that you want:
 > > <http://www.gnu.org/software/libc/manual/html_node/Feature-Test-Macros.html>. 
 > > Defining _GNU_SOURCE gets you everything and is the most commonly used,
 > > e.g. by adding -D_GNU_SOURCE to CFLAGS.  I think that if you use
 > > autoconf, it takes care of this for you if it detects you're on a glibc
 > > system, but I could be wrong.
 > 
 > Autoconf did not help me here automatically. But maybe i have to change
 > something in configure.ac?
 > So what is the "right way"? 

It depends on what you want.  If you want to use Standard C (1999
version), use std=c99.  If you want GNU extensions, use GNU_SOURCE.

Andrew.