Re: can/should we use gcc 3.1 to compile kernels

Re: can/should we use gcc 3.1 to compile kernels

[Kaoru Fukui]

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/

Re: can/should we use gcc 3.1 to compile kernels

[Tom Rini]

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/

Re: can/should we use gcc 3.1 to compile kernels

[Kevin B. Hendricks]

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:
> > 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/

Re: can/should we use gcc 3.1 to compile kernels

[Tom Rini]

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/

Re: can/should we use gcc 3.1 to compile kernels

[Franz Sirl]

At 22:19 07.06.2002, Tom Rini wrote:

>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..

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

> > 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.

> > 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/

Re: can/should we use gcc 3.1 to compile kernels

[Kevin B. Hendricks]

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:
> > 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.


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

Re: can/should we use gcc 3.1 to compile kernels

[Tom Rini]

On Fri, Jun 07, 2002 at 10:36:46PM +0200, Franz Sirl wrote:
> At 22:19 07.06.2002, Tom Rini wrote:
>
> >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..
>
> The warning is correct, pasting "token1" (CNTRL_REG) with "token2" (->)
> makes no sense, usually it's just a ## to much somewhere.
>
> >> 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? :)

> >> 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/

Re: can/should we use gcc 3.1 to compile kernels

[Franz Sirl]

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/

Re: can/should we use gcc 3.1 to compile kernels

[Franz Sirl]

At 22:45 07.06.2002, Tom Rini wrote:
>On Fri, Jun 07, 2002 at 10:36:46PM +0200, Franz Sirl wrote:
> > At 22:19 07.06.2002, Tom Rini wrote:
> >
> > >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..
> >
> > The warning is correct, pasting "token1" (CNTRL_REG) with "token2" (->)
> > makes no sense, usually it's just a ## to much somewhere.
> >
> > >> 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? :)

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



> > >> 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?

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/

Re: can/should we use gcc 3.1 to compile kernels

[Kevin B. Hendricks]

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:
> >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/

More GCC 3.1 Qs

[Conn Clark]

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/

Re: can/should we use gcc 3.1 to compile kernels

[Kaoru Fukui]

On  7 Jun, Franz Sirl wrote:
>
> 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.

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/

Re: can/should we use gcc 3.1 to compile kernels

[Kevin B. Hendricks]

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


> > > 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/

Re: can/should we use gcc 3.1 to compile kernels

[Tom Rini]

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/

can/should we use gcc 3.1 to compile kernels

[Kevin B. Hendricks]

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/