In article <[EMAIL PROTECTED]> 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... h
[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 co
Bernd Eckenfels wrote:
>
> In article <[EMAIL PROTECTED]> 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
In article <[EMAIL PROTECTED]> 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 fr
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
> 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 c
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, alt
[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 yoursel
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 (
[Jakub Jelinek <[EMAIL PROTECTED]>]
> 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 l
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");
> }
>
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, need
12 matches
Mail list logo
