Re: beware of dead string constants

Re: beware of dead string constants

[Bernd Eckenfels]

In article <14874.25691.629724.306563@wire.cadcamlab.org> you wrote:
> This is mostly a heads-up to say that in this regard gcc is not ready
> for prime time, so we really can't get away with using if() as an ifdef
> yet, at least not without penalty.

Humm.. whats the Advantage of this?

Greetings
Bernd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: beware of dead string constants

[Jeff Garzik]

Bernd Eckenfels wrote:
> 
> In article <14874.25691.629724.306563@wire.cadcamlab.org> you wrote:
> > This is mostly a heads-up to say that in this regard gcc is not ready
> > for prime time, so we really can't get away with using if() as an ifdef
> > yet, at least not without penalty.
> 
> Humm.. whats the Advantage of this?

Advantage of what?

If you mean preferring 'if ()' over 'ifdef'... Linus.  :)  And I agree
with him:  code looks -much- more clean without ifdefs.  And the
compiler should be smart enough to completely eliminate code inside an
'if (0)' code block.

	Jeff


-- 
Jeff Garzik             |
Building 1024           | The chief enemy of creativity is "good" sense
MandrakeSoft            |          -- Picasso
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: beware of dead string constants

[Peter Samuelson]

[Jeff Garzik]
> If you mean preferring 'if ()' over 'ifdef'... Linus.  :) And I agree
> with him: code looks -much- more clean without ifdefs.  And the
> compiler should be smart enough to completely eliminate code inside
> an 'if (0)' code block.

Plus the advantage/disadvantage of making the compiler parse almost
everything, which should eliminate syntax errors, variable name
misspellings, etc in little-used config options.  The disadvantage is
that compilation speed goes down.

Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: beware of dead string constants

[Chris Wedgwood]

On Thu, Nov 23, 2000 at 06:39:25PM -0500, Jeff Garzik wrote:

    Advantage of what?
    
    If you mean preferring 'if ()' over 'ifdef'... Linus.  :)  And I agree
    with him:  code looks -much- more clean without ifdefs.  And the
    compiler should be smart enough to completely eliminate code inside an
    'if (0)' code block.

Not only that; we should move to code where the compiler engine can
sanitize the code; the preprocessor alternative is obviously more
limited here.

The same can also be said for some of the many macro's that are
#defined; some would surely be better as inline functions is we could
ensure they would always be in-lined.



  --cw
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: beware of dead string constants

[Bernd Eckenfels]

In article <3A1DAAAD.28786302@mandrakesoft.com> you wrote:
> If you mean preferring 'if ()' over 'ifdef'... Linus.  :)  And I agree
> with him:  code looks -much- more clean without ifdefs.  And the
> compiler should be smart enough to completely eliminate code inside an
> 'if (0)' code block.

Oh I see. Well... hmmm... I think I have no Oppionion about that :)

Greetings
Bernd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: beware of dead string constants

[Michael Elizabeth Chastain]

> Jakub Jelinek claims to have fixed this particular bug in the last week
> or so, although I have not downloaded and compiled recent CVS to verify
> this.

I have a compiler from gcc.gnu.org's CVS tree that's only a few days old,
so I can verify Jakub's claim.

It Works For Me (tm).

There is a considerable amount of engineering and testing and releasology
and distribution between "CVS compiler" and "production compiler for
kernel builds" though.

> and according to Jeff Law, this case is *not* fixed yet.

My compiler behaves as Jeff says.

Michael Elizabeth Chastain
<mailto:mec@shout.net>
"love without fear"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: beware of dead string constants

[Werner Almesberger]

Michael Elizabeth Chastain wrote:
> I have a compiler from gcc.gnu.org's CVS tree that's only a few days old,
> so I can verify Jakub's claim.

BTW, do you have any estimate of how much dead string space it actually
removed ? (I.e. did the .data segment size change significantly, or was
is lost in the normal inter-gcc-version noise ?)

Just curious,
- Werner

-- 
  _________________________________________________________________________
 / Werner Almesberger, ICA, EPFL, CH           Werner.Almesberger@epfl.ch /
/_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

beware of dead string constants

[Peter Samuelson]

While trying to clean up some code recently (CONFIG_MCA, hi Jeff), I
discovered that gcc 2.95.2 (i386) does not remove dead string
constants:

  void foo (void)
  {
    if (0)
      printk(KERN_INFO "bar");
  }

Annoyingly, gcc forgets to drop the "<6>bar\0".  It shows up in the
object file, needlessly clogging your cachelines.

This has ramifications for anyone thinking of converting #ifdefs to
if(){}, which is supposed to be the way of the future.  In my situation
I am trying to convert '#ifdef CONFIG_MCA' to 'if (MCA_bus)' where
MCA_bus is #defined to 0 on most architectures.

'static' variables in block scope, same story.

This is mostly a heads-up to say that in this regard gcc is not ready
for prime time, so we really can't get away with using if() as an ifdef
yet, at least not without penalty.

I've just asked gcc-help@gcc.gnu.org about this; if I hear anything
interesting I'll report back.

Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: beware of dead string constants

[Jakub Jelinek]

On Tue, Nov 21, 2000 at 06:02:35AM -0600, Peter Samuelson wrote:
> 
> While trying to clean up some code recently (CONFIG_MCA, hi Jeff), I
> discovered that gcc 2.95.2 (i386) does not remove dead string
> constants:
> 
>   void foo (void)
>   {
>     if (0)
>       printk(KERN_INFO "bar");
>   }
> 
> Annoyingly, gcc forgets to drop the "<6>bar\0".  It shows up in the
> object file, needlessly clogging your cachelines.

gcc was never dropping such strings, I've commited a patch to fix this
a week ago into CVS.

	Jakub
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: beware of dead string constants

[Peter Samuelson]

[Jakub Jelinek <jakub@redhat.com>]
> gcc was never dropping such strings, I've commited a patch to fix
> this a week ago into CVS.

Cool!  What about block-scoped 'static' variables?  Do those get
garbage-collected now as well?

Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: beware of dead string constants

[J . A . Magallon]

On Tue, 21 Nov 2000 13:13:27 Jakub Jelinek wrote:
> On Tue, Nov 21, 2000 at 06:02:35AM -0600, Peter Samuelson wrote:
> > 
> > While trying to clean up some code recently (CONFIG_MCA, hi Jeff), I
> > discovered that gcc 2.95.2 (i386) does not remove dead string
> > constants:
> > 
> >   void foo (void)
> >   {
> >     if (0)
> >       printk(KERN_INFO "bar");
> >   }
> > 

Is it related to opt level ? -O3 does auto-inlining and -O2 does not
(discovered that here, auto inlining in kernel trashes the cache...)

-- 
Juan Antonio Magallon Lacarta                                 #> cd /pub
mailto:jamagallon@able.es                                     #> more beer

Linux 2.2.18-pre22-vm #7 SMP Sun Nov 19 03:29:20 CET 2000 i686 unknown

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: beware of dead string constants

[Peter Samuelson]

    [I wrote]
> > >   void foo (void)
> > >   {
> > >     if (0)
> > >       printk(KERN_INFO "bar");
> > >   }
> > > 

[J . A . Magallon]
> Is it related to opt level ? -O3 does auto-inlining and -O2 does not
> (discovered that here, auto inlining in kernel trashes the cache...)

See for yourself.  'gcc -S' is most helpful.  The above generates a
string constant "bar\0" for all optimization levels.

Jakub Jelinek claims to have fixed this particular bug in the last week
or so, although I have not downloaded and compiled recent CVS to verify
this.  (Didn't someone at some point have a cgi frontend to
CVS-snapshot 'gcc -S'?  I can't find it now.)

There is a similar case of scoped 'static' variables, like 'bar' here:

  extern void baz (int *);
  void foo (void)
  {
    if (0) {
      static int bar[1024];	/* useless 4096-byte hole in bss */
      baz(bar);
    }
  }

and according to Jeff Law, this case is *not* fixed yet.

Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: beware of dead string constants

[Urban Widmark]

On Tue, 21 Nov 2000, Peter Samuelson wrote:

[someone wrote, and I am keeping it :) ]
> > > >   void foo (void)
> > > >   {
> > > >     if (0)
> > > >       printk(KERN_INFO "bar");
> > > >   }
> > > > 

[snip]

> Jakub Jelinek claims to have fixed this particular bug in the last week
> or so, although I have not downloaded and compiled recent CVS to verify
> this.  (Didn't someone at some point have a cgi frontend to
> CVS-snapshot 'gcc -S'?  I can't find it now.)

It is linked from the "Reporting bugs" page on the gcc site.
http://www.codesourcery.com/gcc-compile.shtml

And as far as I can tell the assembly output of compiling "foo" does not
contain the "bar" string (without using any -O at all ...)

GCC: (GNU) 2.97 20001121 (experimental)

/Urban

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/