2002-08-13 06:03:02

by Andrew Morton

[permalink] [raw]
Subject: [patch] __func__ -> __FUNCTION__


It is a requirement of the SPARC port that Linux be compilable
by egcs-1.1.2, aka gcc-2.91.66.

That compiler does not support __func__.

--- linux-2.5.31/include/linux/kernel.h Wed Jul 24 14:31:31 2002
+++ 25/include/linux/kernel.h Mon Aug 12 23:09:31 2002
@@ -13,6 +13,8 @@
#include <linux/types.h>
#include <linux/compiler.h>

+#define __func__ __FUNCTION__ /* For old gcc's */
+
/* Optimization barrier */
/* The "volatile" is due to gcc bugs */
#define barrier() __asm__ __volatile__("": : :"memory")


2002-08-13 06:45:51

by H. Peter Anvin

[permalink] [raw]
Subject: Re: [patch] __func__ -> __FUNCTION__

Followup to: <[email protected]>
By author: Andrew Morton <[email protected]>
In newsgroup: linux.dev.kernel

> --- linux-2.5.31/include/linux/kernel.h Wed Jul 24 14:31:31 2002
> +++ 25/include/linux/kernel.h Mon Aug 12 23:09:31 2002
> @@ -13,6 +13,8 @@
> #include <linux/types.h>
> #include <linux/compiler.h>
>
> +#define __func__ __FUNCTION__ /* For old gcc's */
> +
> /* Optimization barrier */
> /* The "volatile" is due to gcc bugs */
> #define barrier() __asm__ __volatile__("": : :"memory")

Shouldn't this be conditional on the version?
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <[email protected]>

2002-08-13 07:59:02

by Andrew Morton

[permalink] [raw]
Subject: Re: [patch] __func__ -> __FUNCTION__

"H. Peter Anvin" wrote:
>
> Followup to: <[email protected]>
> By author: Andrew Morton <[email protected]>
> In newsgroup: linux.dev.kernel
>
> > --- linux-2.5.31/include/linux/kernel.h Wed Jul 24 14:31:31 2002
> > +++ 25/include/linux/kernel.h Mon Aug 12 23:09:31 2002
> > @@ -13,6 +13,8 @@
> > #include <linux/types.h>
> > #include <linux/compiler.h>
> >
> > +#define __func__ __FUNCTION__ /* For old gcc's */
> > +
> > /* Optimization barrier */
> > /* The "volatile" is due to gcc bugs */
> > #define barrier() __asm__ __volatile__("": : :"memory")
>
> Shouldn't this be conditional on the version?

Could be. But I don't know what version to use.

2002-08-13 08:01:12

by Muli Ben-Yehuda

[permalink] [raw]
Subject: Re: [patch] __func__ -> __FUNCTION__

On Tue, Aug 13, 2002 at 01:13:04AM -0700, Andrew Morton wrote:
> "H. Peter Anvin" wrote:
> >
> > Followup to: <[email protected]>
> > By author: Andrew Morton <[email protected]>
> > In newsgroup: linux.dev.kernel
> >
> > > --- linux-2.5.31/include/linux/kernel.h Wed Jul 24 14:31:31 2002
> > > +++ 25/include/linux/kernel.h Mon Aug 12 23:09:31 2002
> > > @@ -13,6 +13,8 @@
> > > #include <linux/types.h>
> > > #include <linux/compiler.h>
> > >
> > > +#define __func__ __FUNCTION__ /* For old gcc's */
> > > +
> > > /* Optimization barrier */
> > > /* The "volatile" is due to gcc bugs */
> > > #define barrier() __asm__ __volatile__("": : :"memory")
> >
> > Shouldn't this be conditional on the version?
>
> Could be. But I don't know what version to use.

How about:

/* early gcc compilers lose on __func__ */
#ifndef __func__
#define __func__ __FUNCTION__
#endif /* !defined __func__ */
--
"Hmm.. Cache shrink failed - time to kill something?
Mhwahahhaha! This is the part I really like. Giggle."
-- linux/mm/vmscan.c
http://vipe.technion.ac.il/~mulix/ http://syscalltrack.sf.net


Attachments:
(No filename) (1.10 kB)
(No filename) (189.00 B)
Download all attachments

2002-08-13 08:06:19

by H. Peter Anvin

[permalink] [raw]
Subject: Re: [patch] __func__ -> __FUNCTION__

Muli Ben-Yehuda wrote:
>
> How about:
>
> /* early gcc compilers lose on __func__ */
> #ifndef __func__
> #define __func__ __FUNCTION__
> #endif /* !defined __func__ */

__func__ isn't a macro; it's a compiler token.

-hpa

2002-08-13 08:15:39

by H. Peter Anvin

[permalink] [raw]
Subject: Re: [patch] __func__ -> __FUNCTION__

Muli Ben-Yehuda wrote:
> On Tue, Aug 13, 2002 at 01:09:39AM -0700, H. Peter Anvin wrote:
>
>>Muli Ben-Yehuda wrote:
>>
>>>How about:
>>>
>>>/* early gcc compilers lose on __func__ */
>>>#ifndef __func__
>>>#define __func__ __FUNCTION__
>>>#endif /* !defined __func__ */
>>
>>__func__ isn't a macro; it's a compiler token.
>
>
> Works for me(TM).
>

But it won't work on a compiler that actually *supports* __func__...

I think that is gcc 3.1 or higher, but I'm not the authority...

> ObCompleteyUnrelatedQuestions: where can I find klibc?

ftp://ftp.kernel.org/pub/linux/libs/klibc/

-hpa


2002-08-13 08:12:00

by Muli Ben-Yehuda

[permalink] [raw]
Subject: Re: [patch] __func__ -> __FUNCTION__

On Tue, Aug 13, 2002 at 01:09:39AM -0700, H. Peter Anvin wrote:
> Muli Ben-Yehuda wrote:
> >
> >How about:
> >
> >/* early gcc compilers lose on __func__ */
> >#ifndef __func__
> >#define __func__ __FUNCTION__
> >#endif /* !defined __func__ */
>
> __func__ isn't a macro; it's a compiler token.

Works for me(TM).

mulix@alhambra:~/tmp$ cat foo.c
#include <stdio.h>

#if DEF_FUNC
#ifndef __func__
#define __func__ __FUNCTION__
#endif /* !defined __func__ */
#endif /* DEF_FUNC */

int main()
{
printf("%s\n", __func__);
return 0;
}
mulix@alhambra:~/tmp$ /usr/bin/gcc -v
Reading specs from
/usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/specs
gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)
mulix@alhambra:~/tmp$ /usr/bin/gcc foo.c -DDEF_FUNC=0 -o foo
foo.c: In function `main':
foo.c:11: `__func__' undeclared (first use in this function)
foo.c:11: (Each undeclared identifier is reported only once
foo.c:11: for each function it appears in.)
mulix@alhambra:~/tmp$ /usr/bin/gcc foo.c -DDEF_FUNC=1 -o foo
mulix@alhambra:~/tmp$ ./foo

ObCompleteyUnrelatedQuestions: where can I find klibc?
--
"Hmm.. Cache shrink failed - time to kill something?
Mhwahahhaha! This is the part I really like. Giggle."
-- linux/mm/vmscan.c
http://vipe.technion.ac.il/~mulix/ http://syscalltrack.sf.net


Attachments:
(No filename) (1.28 kB)
(No filename) (189.00 B)
Download all attachments

2002-08-13 08:16:54

by Christoph Hellwig

[permalink] [raw]
Subject: Re: [patch] __func__ -> __FUNCTION__

On Mon, Aug 12, 2002 at 11:17:03PM -0700, Andrew Morton wrote:
>
> It is a requirement of the SPARC port that Linux be compilable
> by egcs-1.1.2, aka gcc-2.91.66.
>
> That compiler does not support __func__.

Is there any reason to not use __FUNCTION__? According to the gcc folks
that there is no plan to retire it, and as long as all known-good kernel
compilers support it a gccism is a lot better than a standard feature that
is not supported by most of the kernel compilers.

2002-08-13 08:21:14

by Muli Ben-Yehuda

[permalink] [raw]
Subject: Re: [patch] __func__ -> __FUNCTION__

On Tue, Aug 13, 2002 at 01:19:07AM -0700, H. Peter Anvin wrote:
>
> But it won't work on a compiler that actually *supports* __func__...
>
> I think that is gcc 3.1 or higher, but I'm not the authority...

Again, works for me.

http://home.tiscalinet.ch/t_wolf/tw/c/c9x_changes.html (search for
__func__) would seem to imply that you are correct, though. Perhaphs
someone more knowledgable about gcc could shed some light?

mulix@tea:~/tmp$ cat foo.c
#include <stdio.h>

#if DEF_FUNC
#ifndef __func__
#define __func__ __FUNCTION__
#endif /* !defined __func__ */
#endif /* DEF_FUNC */

int main()
{
printf("%s\n", __func__);
return 0;
}
mulix@tea:~/tmp$ gcc3 -v
Reading specs from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.1/specs
Configured with: ../gcc-3.1/configure --enable-threads
--enable-languages=c,c++
Thread model: posix
gcc version 3.1
mulix@tea:~/tmp$ gcc3 foo.c -DDEF_FUNC=1 -o foo
mulix@tea:~/tmp$ ./foo
main
mulix@tea:~/tmp$ gcc3 foo.c -DDEF_FUNC=0 -o foo
mulix@tea:~/tmp$ ./foo
main
mulix@tea:~/tmp$

> >ObCompleteyUnrelatedQuestions: where can I find klibc?
>
> ftp://ftp.kernel.org/pub/linux/libs/klibc/

Much obliged.
--
"Hmm.. Cache shrink failed - time to kill something?
Mhwahahhaha! This is the part I really like. Giggle."
-- linux/mm/vmscan.c
http://vipe.technion.ac.il/~mulix/ http://syscalltrack.sf.net


Attachments:
(No filename) (1.32 kB)
(No filename) (189.00 B)
Download all attachments

2002-08-13 08:35:32

by Andrew Morton

[permalink] [raw]
Subject: Re: [patch] __func__ -> __FUNCTION__

Christoph Hellwig wrote:
>
> On Mon, Aug 12, 2002 at 11:17:03PM -0700, Andrew Morton wrote:
> >
> > It is a requirement of the SPARC port that Linux be compilable
> > by egcs-1.1.2, aka gcc-2.91.66.
> >
> > That compiler does not support __func__.
>
> Is there any reason to not use __FUNCTION__? According to the gcc folks
> that there is no plan to retire it, and as long as all known-good kernel
> compilers support it a gccism is a lot better than a standard feature that
> is not supported by most of the kernel compilers.

Sounds fine to me.

--- linux-2.5.31/include/linux/kernel.h Wed Jul 24 14:31:31 2002
+++ 25/include/linux/kernel.h Tue Aug 13 01:48:36 2002
@@ -13,6 +13,8 @@
#include <linux/types.h>
#include <linux/compiler.h>

+#define __func__ use.__FUNCTION__.not.__func__
+
/* Optimization barrier */
/* The "volatile" is due to gcc bugs */
#define barrier() __asm__ __volatile__("": : :"memory")

It affects

drivers/char/drm/mga_dma.c
drivers/char/drm/mga_drv.h
drivers/char/drm/mga_state.c
drivers/char/drm/r128_cce.c
drivers/char/drm/r128_drv.h
drivers/char/drm/r128_state.c
drivers/char/drm/radeon_cp.c
drivers/char/drm/radeon_drv.h
drivers/char/drm/radeon_state.c
include/net/bluetooth/bluetooth.h

2002-08-14 21:15:31

by Max Krasnyansky

[permalink] [raw]
Subject: Re: [patch] __func__ -> __FUNCTION__

At 01:13 AM 8/13/2002 -0700, Andrew Morton wrote:
>"H. Peter Anvin" wrote:
> >
> > Followup to: <[email protected]>
> > By author: Andrew Morton <[email protected]>
> > In newsgroup: linux.dev.kernel
> >
> > > --- linux-2.5.31/include/linux/kernel.h Wed Jul 24 14:31:31 2002
> > > +++ 25/include/linux/kernel.h Mon Aug 12 23:09:31 2002
> > > @@ -13,6 +13,8 @@
> > > #include <linux/types.h>
> > > #include <linux/compiler.h>
> > >
> > > +#define __func__ __FUNCTION__ /* For old gcc's */
> > > +
> > > /* Optimization barrier */
> > > /* The "volatile" is due to gcc bugs */
> > > #define barrier() __asm__ __volatile__("": : :"memory")
> >
> > Shouldn't this be conditional on the version?
>
>Could be. But I don't know what version to use.

#if __GNUC__ <= 2 && __GNUC_MINOR__ < 95
#define __func__ __FUNCTION__
#endif

Max