Red Hat 7.0, i686, gcc-20001027 (Yes, I know. Just to flush out bugs on
both sides).
abs() is used at least in:
arch/i386/kernel/time.c
drivers/md/raid1.c
drivers/sound/sb_ess.c
gcc warns about use of a non-declared function each time.
No definition for the function is to be found (grep over all include/ comes
up clean, except for extern definitions in asm-{mips,ppc}; ditto for lib/).
Presumably gcc is using a builtin (it doesn't show up in System.map). Is
this the desired state of affairs? Should a include/linux/stdlib.h be
added, containing (for now, to be expanded later as needed, like
include/linux/stddef.h):
#ifndef _LINUX_STDLIB_H
#define _LINUX_STDLIB_H
extern int abs(int);
#endif
--
Horst von Brand [email protected]
Casilla 9G, Vin~a del Mar, Chile +56 32 672616
Horst von Brand wrote:
>
> Red Hat 7.0, i686, gcc-20001027 (Yes, I know. Just to flush out bugs on
> both sides).
>
> abs() is used at least in:
>
> arch/i386/kernel/time.c
> drivers/md/raid1.c
> drivers/sound/sb_ess.c
>
> gcc warns about use of a non-declared function each time.
>
> No definition for the function is to be found (grep over all include/ comes
> up clean, except for extern definitions in asm-{mips,ppc}; ditto for lib/).
> Presumably gcc is using a builtin (it doesn't show up in System.map). Is
> this the desired state of affairs? Should a include/linux/stdlib.h be
Yes abs will be transformed into an internal function, which will be
fully
unrolled due to -O2.
On Mon, Oct 30, 2000 at 03:01:16PM +0100, Martin Dalecki wrote:
> Horst von Brand wrote:
> >
> > Red Hat 7.0, i686, gcc-20001027 (Yes, I know. Just to flush out bugs on
> > both sides).
> >
> > abs() is used at least in:
> >
> > arch/i386/kernel/time.c
> > drivers/md/raid1.c
> > drivers/sound/sb_ess.c
> >
> > gcc warns about use of a non-declared function each time.
> >
> > No definition for the function is to be found (grep over all include/ comes
> > up clean, except for extern definitions in asm-{mips,ppc}; ditto for lib/).
> > Presumably gcc is using a builtin (it doesn't show up in System.map). Is
> > this the desired state of affairs? Should a include/linux/stdlib.h be
>
> Yes abs will be transformed into an internal function, which will be
> fully
> unrolled due to -O2.
No matter what it should be prototyped in some header. And all uses should
be checked, because abs is
int abs (int) __attribute__ ((__const__));
and sometimes people use it on `long' instead (such a bug has been fixed in
the kernel some months ago).
Jakub
Jakub Jelinek wrote:
>
> On Mon, Oct 30, 2000 at 03:01:16PM +0100, Martin Dalecki wrote:
> > Horst von Brand wrote:
> > >
> > > Red Hat 7.0, i686, gcc-20001027 (Yes, I know. Just to flush out bugs on
> > > both sides).
> > >
> > > abs() is used at least in:
> > >
> > > arch/i386/kernel/time.c
> > > drivers/md/raid1.c
> > > drivers/sound/sb_ess.c
> > >
> > > gcc warns about use of a non-declared function each time.
> > >
> > > No definition for the function is to be found (grep over all include/ comes
> > > up clean, except for extern definitions in asm-{mips,ppc}; ditto for lib/).
> > > Presumably gcc is using a builtin (it doesn't show up in System.map). Is
> > > this the desired state of affairs? Should a include/linux/stdlib.h be
> >
> > Yes abs will be transformed into an internal function, which will be
> > fully
> > unrolled due to -O2.
>
> No matter what it should be prototyped in some header. And all uses should
> be checked, because abs is
> int abs (int) __attribute__ ((__const__));
> and sometimes people use it on `long' instead (such a bug has been fixed in
> the kernel some months ago).
Of corse right! BTW. There are tons of places where log2 is calculated
explicitly in kernel which should be replaced with the corresponding
built
in functions as well (/dev/random code does it). And then If I remember
correctly
there is an attribute which is telling about internal functions
in declarations explicitly as well?
On Mon, Oct 30, 2000 at 05:14:34PM +0100, Martin Dalecki wrote:
> Of corse right! BTW. There are tons of places where log2 is calculated
> explicitly in kernel which should be replaced with the corresponding
> built
> in functions as well (/dev/random code does it). And then If I remember
> correctly
> there is an attribute which is telling about internal functions
> in declarations explicitly as well?
What versions of gcc produce the built-in functions? And does it do
so for *all* platforms? (i.e., PPC, Alpha, IA64, etc., etc., etc.)
- Ted
On Wed, Nov 01, 2000 at 09:46:19AM -0500, [email protected] wrote:
> What versions of gcc produce the built-in functions?
2.95 and previous. In 2.96 somewhere we fixed a bug that
automatically prototypes these builtin functions for you;
ie with current code you get an undeclared function warning.
> And does it do so for *all* platforms? (i.e., PPC, Alpha,
> IA64, etc., etc., etc.)
Yes. The thing about abs, though, is that it's "int abs(int)"
which does naughty things with longs on 64-bit targets. You're
much better off writing (x < 0 ? -x : x) directly.
r~
Date: Wed, 1 Nov 2000 09:46:19 -0500
From: [email protected]
On Mon, Oct 30, 2000 at 05:14:34PM +0100, Martin Dalecki wrote:
> Of corse right! BTW. There are tons of places where log2 is calculated
> explicitly in kernel which should be replaced with the corresponding
> built
> in functions as well (/dev/random code does it). And then If I remember
> correctly
> there is an attribute which is telling about internal functions
> in declarations explicitly as well?
And in the case of /dev/random, since we know something about what the
possible inputs can be, I'm fairly certain that the "int_ln_12bits" used
by /dev/random is probably far better than the general purpose code
which GCC no doubt has to emit....
- Ted
Richard Henderson wrote:
>
> On Wed, Nov 01, 2000 at 09:46:19AM -0500, [email protected] wrote:
> > What versions of gcc produce the built-in functions?
>
> 2.95 and previous. In 2.96 somewhere we fixed a bug that
> automatically prototypes these builtin functions for you;
> ie with current code you get an undeclared function warning.
>
> > And does it do so for *all* platforms? (i.e., PPC, Alpha,
> > IA64, etc., etc., etc.)
>
> Yes. The thing about abs, though, is that it's "int abs(int)"
> which does naughty things with longs on 64-bit targets. You're
> much better off writing (x < 0 ? -x : x) directly.
Thank's for answering it... I was already looking up the GCC source for
an exact answer ;-). However what's the difference in respect of
optimization between unrolling the abs function by hand and
relying on the built in?
On Thu, Nov 02, 2000 at 01:14:49PM +0100, Martin Dalecki wrote:
> However what's the difference in respect of optimization between
> unrolling the abs function by hand and relying on the built in?
Should be nothing. The expanded source expression should get
folded immediately to an ABS_EXPR node, at which point you are
at exactly the same point as the builtin would have gotten you.
r~