[patch] __func__ -> __FUNCTION__

[patch] __func__ -> __FUNCTION__

[Andrew Morton]

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")

Re: [patch] __func__ -> __FUNCTION__

[H. Peter Anvin]

Followup to:  <3D58A45F.A7F5BDD@zip.com.au>
By author:    Andrew Morton <akpm@zip.com.au>
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?
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<amsp@zytor.com>

Re: [patch] __func__ -> __FUNCTION__

[Muli Ben-Yehuda]

[-- Attachment #1: Type: text/plain, Size: 1165 bytes --]

On Tue, Aug 13, 2002 at 01:13:04AM -0700, Andrew Morton wrote:
> "H. Peter Anvin" wrote:
> > 
> > Followup to:  <3D58A45F.A7F5BDD@zip.com.au>
> > By author:    Andrew Morton <akpm@zip.com.au>
> > 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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [patch] __func__ -> __FUNCTION__

[H. Peter Anvin]

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

Re: [patch] __func__ -> __FUNCTION__

[Muli Ben-Yehuda]

[-- Attachment #1: Type: text/plain, Size: 1361 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [patch] __func__ -> __FUNCTION__

[Andrew Morton]

"H. Peter Anvin" wrote:
> 
> Followup to:  <3D58A45F.A7F5BDD@zip.com.au>
> By author:    Andrew Morton <akpm@zip.com.au>
> 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.

Re: [patch] __func__ -> __FUNCTION__

[H. Peter Anvin]

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

Re: [patch] __func__ -> __FUNCTION__

[Muli Ben-Yehuda]

[-- Attachment #1: Type: text/plain, Size: 1401 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [patch] __func__ -> __FUNCTION__

[Christoph Hellwig]

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.

Re: [patch] __func__ -> __FUNCTION__

[Andrew Morton]

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

Re: [patch] __func__ -> __FUNCTION__

[Maksim (Max) Krasnyanskiy]

At 01:13 AM 8/13/2002 -0700, Andrew Morton wrote:
>"H. Peter Anvin" wrote:
> >
> > Followup to:  <3D58A45F.A7F5BDD@zip.com.au>
> > By author:    Andrew Morton <akpm@zip.com.au>
> > 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