can/should we use gcc 3.1 to compile kernels

Hi,

Has anyone successfully used gcc 3.1 or gcc 3.1.1-pre to build actual
working kernels and tested them?

Does it work?

Thanks,

Kevin


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

On  8 Jun, Kevin B. Hendricks wrote:

Hi,

Has anyone successfully used gcc 3.1 or gcc 3.1.1-pre to build actual
working kernels and tested them?

Does it work?

 ftp://ppc.linux.or.jp/pub/users/fukui/
Yes,gcc-3.1.1 and kernel-2.4.19pre10 are in the site.
But recently gcc-3.2 is not able to compile linux kernel.


Kaoru


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

On Sat, Jun 08, 2002 at 01:41:12PM -0400, Kevin B. Hendricks wrote:

Has anyone successfully used gcc 3.1 or gcc 3.1.1-pre to build actual
working kernels and tested them?

Does it work?

There's at least a few people who've done it.  Personally I'll be using
2.95.3 (or 2.95 from CVS) until forced to do otherwise, just because
it's the most well-tested compiler.

That said, if you do use 3.1, you'll get a bunch more warnings which I
don't think you can turn off, which has kind of annoyed some developers.

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Hi,

Not too bad warnings-wize excpet for the controlfb.c where it constanly
gave a funny warning about "pasting ->".

It did this for every occurence of the macro CNTRL_REG which I must admit
has two ## which I think gcc was misinterpreting somehow.


Other than that just the occaissioanal wanring about unused variables and
things like that.

I should have saved the build.log

I hate mixing compilers.  I have moved my system to gcc 3.1 from Franz but
I would like to keep gcc 2.95.4 in /usr/local/ or some other place just in
case I ever need it for things like glibc and the kernel.

Thanks,

Kevin

On June 7, 2002 03:38, Tom Rini wrote:

On Sat, Jun 08, 2002 at 01:41:12PM -0400, Kevin B. Hendricks wrote:

quoted

Has anyone successfully used gcc 3.1 or gcc 3.1.1-pre to build actual
working kernels and tested them?

Does it work?

There's at least a few people who've done it.  Personally I'll be using
2.95.3 (or 2.95 from CVS) until forced to do otherwise, just because
it's the most well-tested compiler.

That said, if you do use 3.1, you'll get a bunch more warnings which I
don't think you can turn off, which has kind of annoyed some developers.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

On Fri, Jun 07, 2002 at 03:44:56PM -0400, Kevin B. Hendricks wrote:

Not too bad warnings-wize excpet for the controlfb.c where it constanly
gave a funny warning about "pasting ->".

Sounds right.  I think there was a few other things too..

It did this for every occurence of the macro CNTRL_REG which I must admit
has two ## which I think gcc was misinterpreting somehow.

Well, isn't:
#define x(foo) a_## foo ##_b
A semi-common thing, like we do in indirect_pci.c ?  Or was it something
different?

Other than that just the occaissioanal wanring about unused variables and
things like that.

Lots of the USB stuff uses __FUNCTION__ which gcc-3.1 isn't happy
about.

I should have saved the build.log

S'alright.

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

At 22:19 07.06.2002, Tom Rini wrote:

On Fri, Jun 07, 2002 at 03:44:56PM -0400, Kevin B. Hendricks wrote:

quoted

Not too bad warnings-wize excpet for the controlfb.c where it constanly
gave a funny warning about "pasting ->".

Sounds right.  I think there was a few other things too..

The warning is correct, pasting "token1" (CNTRL_REG) with "token2" (->)
makes no sense, usually it's just a ## to much somewhere.

quoted

It did this for every occurence of the macro CNTRL_REG which I must admit
has two ## which I think gcc was misinterpreting somehow.

Well, isn't:
#define x(foo) a_## foo ##_b
A semi-common thing, like we do in indirect_pci.c ?  Or was it something
different?

Think about preprocessing tokens! If foo is "->" the ## make no sense at
all, cause "a_", "->" and "_b" are 3 separate preprocessing tokens, no need
to paste them together.

quoted

Other than that just the occaissioanal wanring about unused variables and
things like that.

Lots of the USB stuff uses __FUNCTION__ which gcc-3.1 isn't happy
about.

It's not __FUNCTION__ per se that gcc is unhappy about, but string
concatenation with it. So instead of printk ( __FUNCTION__ "text %d",
value) use printk (" %s, text %d", __FUNCTION__, value). No big deal.

I think current 3.2 already refuses to compile that.

Franz.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Hi,


#define CNTRL_REG(INFO,REG) (&(((INFO)->control_regs-> ## REG).r))

Invoked via something like:

out_le32(CNTRL_REG(p,start_addr),
                 par->yoffset * par->pitch + (par->xoffset << par->cmode));

But control_regs looks like:

struct control_regs {
...
           struct preg start_addr; /* start address: 5 lsbs zero */
...
}

and preg looks like:

struct preg {                   /* padded register */
        unsigned r;
        char pad[12];
};

struct fb_info_control {
...
        struct control_regs     *control_regs;
...
}

So assuming p is a pointer to a fb_info_control_structure

then CNTL_REG(p,start_addr) must turn out to be:

(&((p->control_regs-> start_addr).r))

Is that correct?

It seems to need parentheses to me to help see what goes with what...

 It is funny to have a stucture given the exact same name as a field of
another structure, perhaps that is what is confusing gcc 3.1?  (and ME!)

Thanks,

Kevin


On June 7, 2002 04:19, Tom Rini wrote:

On Fri, Jun 07, 2002 at 03:44:56PM -0400, Kevin B. Hendricks wrote:

quoted

Not too bad warnings-wize excpet for the controlfb.c where it
constanly gave a funny warning about "pasting ->".

Sounds right.  I think there was a few other things too..

quoted

It did this for every occurence of the macro CNTRL_REG which I must
admit has two ## which I think gcc was misinterpreting somehow.

Well, isn't:
#define x(foo) a_## foo ##_b
A semi-common thing, like we do in indirect_pci.c ?  Or was it something
different?

quoted

Other than that just the occaissioanal wanring about unused variables
and things like that.

Lots of the USB stuff uses __FUNCTION__ which gcc-3.1 isn't happy
about.

quoted

I should have saved the build.log

S'alright.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

On Fri, Jun 07, 2002 at 10:36:46PM +0200, Franz Sirl wrote:

At 22:19 07.06.2002, Tom Rini wrote:

quoted

On Fri, Jun 07, 2002 at 03:44:56PM -0400, Kevin B. Hendricks wrote:

quoted

Not too bad warnings-wize excpet for the controlfb.c where it constanly
gave a funny warning about "pasting ->".

Sounds right.  I think there was a few other things too..

The warning is correct, pasting "token1" (CNTRL_REG) with "token2" (->)
makes no sense, usually it's just a ## to much somewhere.

quoted

quoted

It did this for every occurence of the macro CNTRL_REG which I must admit
has two ## which I think gcc was misinterpreting somehow.

Well, isn't:
#define x(foo) a_## foo ##_b
A semi-common thing, like we do in indirect_pci.c ?  Or was it something
different?

Think about preprocessing tokens! If foo is "->" the ## make no sense at
all, cause "a_", "->" and "_b" are 3 separate preprocessing tokens, no need
to paste them together.

Ah.  Got a patch? :)

quoted

quoted

Other than that just the occaissioanal wanring about unused variables and
things like that.

Lots of the USB stuff uses __FUNCTION__ which gcc-3.1 isn't happy
about.

It's not __FUNCTION__ per se that gcc is unhappy about, but string
concatenation with it. So instead of printk ( __FUNCTION__ "text %d",
value) use printk (" %s, text %d", __FUNCTION__, value). No big deal.

I think current 3.2 already refuses to compile that.

I thought it was 3.1 that gave a big warning about __FUNCTION__ being
depreciated entirely and 3.2 which just removed __FUNCTION__ at all.  Or
have things been changed abit?

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

At 22:44 07.06.2002, Kevin B. Hendricks wrote:

Hi,


#define CNTRL_REG(INFO,REG) (&(((INFO)->control_regs-> ## REG).r))

                                                        ^^^^
                                                      superflous

Just remove that and you'll be fine.

Franz.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

At 22:45 07.06.2002, Tom Rini wrote:

On Fri, Jun 07, 2002 at 10:36:46PM +0200, Franz Sirl wrote:

quoted

At 22:19 07.06.2002, Tom Rini wrote:

quoted

On Fri, Jun 07, 2002 at 03:44:56PM -0400, Kevin B. Hendricks wrote:

quoted

Not too bad warnings-wize excpet for the controlfb.c where it constanly
gave a funny warning about "pasting ->".

Sounds right.  I think there was a few other things too..

The warning is correct, pasting "token1" (CNTRL_REG) with "token2" (->)
makes no sense, usually it's just a ## to much somewhere.

quoted

quoted

It did this for every occurence of the macro CNTRL_REG which I must

admit

quoted

quoted

quoted

has two ## which I think gcc was misinterpreting somehow.

Well, isn't:
#define x(foo) a_## foo ##_b
A semi-common thing, like we do in indirect_pci.c ?  Or was it something
different?

Think about preprocessing tokens! If foo is "->" the ## make no sense at
all, cause "a_", "->" and "_b" are 3 separate preprocessing tokens, no

need

quoted

to paste them together.

Ah.  Got a patch? :)

Nope, not even worth a patch :-)), see the message to Kevin.

quoted

quoted

quoted

Other than that just the occaissioanal wanring about unused

variables and

quoted

quoted

quoted

things like that.

Lots of the USB stuff uses __FUNCTION__ which gcc-3.1 isn't happy
about.

It's not __FUNCTION__ per se that gcc is unhappy about, but string
concatenation with it. So instead of printk ( __FUNCTION__ "text %d",
value) use printk (" %s, text %d", __FUNCTION__, value). No big deal.

I think current 3.2 already refuses to compile that.

I thought it was 3.1 that gave a big warning about __FUNCTION__ being
depreciated entirely and 3.2 which just removed __FUNCTION__ at all.  Or
have things been changed abit?

No, but the warning was always about "string concatenation":
[fsirl@entropy:~]$ cat FUNCTION.c
#include <stdio.h>
int main (void)
{
   printf (__FUNCTION__ " text %d", 5);
   printf ("%s text %d", __FUNCTION__, 5);
   return 0;
}
[fsirl@entropy:~]$ gcc -O2 FUNCTION.c
FUNCTION.c: In function `main':
FUNCTION.c:5: warning: concatenation of string literals with __FUNCTION__
is deprecated

So, only one warning is issued.

Franz.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Hi Franz,

Thanks,

BTW under my mailer font (proportional) the remove this part fell right
under the word INFO which confused the hell out of me until I converted it
to a square font and found you wanted me to remove the ##.

:-)

Thanks,

Kevin

On June 7, 2002 04:50, Franz Sirl wrote:

quoted

Hi,


#define CNTRL_REG(INFO,REG) (&(((INFO)->control_regs-> ## REG).r))

                                                        ^^^^
                                                      superflous

Just remove that and you'll be fine.

Franz.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Hello All

	Has anybody done any benchmarks on a ppc kernel compiled on
GCC 3.1 and compared them to the same kernel compiled on GCC 2.95.3?
(preferably for 8xx processor)


How does the code density compare?


Thanks

	Conn
--

*****************************************************************
  If you live at home long enough, your parents will move out.
*****************************************************************

Conn Clark
Engineering Stooge				clark@esteem.com
Electronic Systems Technology Inc.		www.esteem.com

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

On  7 Jun, Franz Sirl wrote:

At 22:44 07.06.2002, Kevin B. Hendricks wrote:

quoted

Hi,


#define CNTRL_REG(INFO,REG) (&(((INFO)->control_regs-> ## REG).r))

                                                        ^^^^
                                                      superflous

Just remove that and you'll be fine.

Franz.

Thanks.
gcc-3.2 gave me error with this problem (not warning).

I will try this.

Kaoru


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Hi,

FYI: I counted 1175 occurences of warnings like the following:

inode.c:2462: warning: concatenation of string literals with __FUNCTION__
is deprecated

So I hope someone has a nice sed or awk script to fix all of these in some
automatic way.

Kevin

quoted

quoted

It's not __FUNCTION__ per se that gcc is unhappy about, but string
concatenation with it. So instead of printk ( __FUNCTION__ "text
%d", value) use printk (" %s, text %d", __FUNCTION__, value). No big
deal.

I think current 3.2 already refuses to compile that.

I thought it was 3.1 that gave a big warning about __FUNCTION__ being
depreciated entirely and 3.2 which just removed __FUNCTION__ at all.
Or have things been changed abit?

No, but the warning was always about "string concatenation":
[fsirl@entropy:~]$ cat FUNCTION.c
#include <stdio.h>
int main (void)
{
   printf (__FUNCTION__ " text %d", 5);
   printf ("%s text %d", __FUNCTION__, 5);
   return 0;
}
[fsirl@entropy:~]$ gcc -O2 FUNCTION.c
FUNCTION.c: In function `main':
FUNCTION.c:5: warning: concatenation of string literals with
__FUNCTION__ is deprecated

So, only one warning is issued.

Franz.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

On Fri, Jun 07, 2002 at 07:39:44PM -0400, Kevin B. Hendricks wrote:

Hi,

FYI: I counted 1175 occurences of warnings like the following:

inode.c:2462: warning: concatenation of string literals with __FUNCTION__
is deprecated

So I hope someone has a nice sed or awk script to fix all of these in some
automatic way.

There are/were rumblings of doing some standard debug macros for 2.5,
so...

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/