Hi!
> > (2) Make the architecture a configuration variable (!)
>
> Why?
>
> You still need to have all the damn cross-compilers etc. At which point
> being a configuration variable is the _least_ of your worries. You're
> better off with just a new tree.
Crosscompilers are easy: take
Hi!
(2) Make the architecture a configuration variable (!)
Why?
You still need to have all the damn cross-compilers etc. At which point
being a configuration variable is the _least_ of your worries. You're
better off with just a new tree.
Crosscompilers are easy: take pre-compiled
Martin Dalecki <[EMAIL PROTECTED]> writes:
> There is some facility allowing to implement this kind of things
> in the C++ part of the most recent EGCS version which makes implementing
> such things "relatively" easy - basiclly there is the provision to dump
> the parser trees as easy to process
On Thu, 7 Sep 2000 19:14:26 -0500,
Michael Elizabeth Chastain <[EMAIL PROTECTED]> wrote:
>> Yeah. Long transition, plus user education (which never works, dontcha
>> know), plus probably a helper tool akin to checkconfig.
>
>I think it would help to have a well documented "module writers kit".
> Yeah. Long transition, plus user education (which never works, dontcha
> know), plus probably a helper tool akin to checkconfig.
I think it would help to have a well documented "module writers kit".
(Maybe there is one and I'm not aware of it).
mec> I'm all in favor of 'if ( CONFIG_BAR )',
[mec]
> In the .config file, the problem is that the Makefiles source .config
> and then do a lot of "ifdef CONFIG_FOO" tests. There are about 300
> instances of this in 2.4.0-test-7.
Separate issue. We're not talking about emitting n symbols to .config,
or at least I'm not. In this thread.
In the .config file, the problem is that the Makefiles source .config and
then do a lot of "ifdef CONFIG_FOO" tests. There are about 300 instances
of this in 2.4.0-test-7.
In include/linux/autoconf.h, the problem is in the *.c (and *.h and *.S)
files that do a lot of "#ifdef CONFIG_BAR" and
If you want to look at an existing source-code analyzer that works
hand-in-glove with compilers, to skim for good or bad ideas, take a look
at the LSE/SCA combo from the DECset tools. (Dunno if DECset is even
still available; I lost track of what went where as they were dicing up
the company.)
David Woodhouse wrote:
> But how much work would it require to do so? If your theoretical vendor of
> closed-source compiler backends were to believe that a shared lib of the
> GCC frontend would be legal, surely they'd just make it shared themselves,
> then use it as such? It's hardly a
[viro]
> The _real_ problem is preprocessor abuse. BTW, could we schedule for
> 2.5 the following?
> * things like CONFIG_FOO are _always_ defined. As 0 or 1, that is.
> * #ifdef CONFIG_FOO => if (CONFIG_FOO) in *.c. gcc will kill the unused
> branches just fine.
[viro]
> > making the internal API frozen by exposure to library users.
[Gooch]
> An exercise in decent API design. BFD.
^^^
Nah, that's the *de*compilation library.
(Sorry, couldn't resist.)
Peter
-
To unsubscribe from this list: send the line
[EMAIL PROTECTED] said:
> Shared library linkage brings you into the same grey area that binary
> only kernel modules fall into, this means it's risky and this is
> almost certainly how the GCC team views this situation.
But how much work would it require to do so? If your theoretical vendor
Michael Elizabeth Chastain <[EMAIL PROTECTED]> wrote:
> We could use some more infrastructure here.
> (1) A 'make randomconfig' tool that generates a random configuration.
mconfig -m random, it's even written by you ;)
my current mconfig working version is on
Michael Elizabeth Chastain wrote:
> (c) With separate source and build trees, which I've implemented,
> it becomes a lot more feaasible to manage kernel builds for
> multiple platforms.
Is this released? I build most of my kernels for both x86 and PowerPC,
plus I build several
Michael Elizabeth Chastain [EMAIL PROTECTED] wrote:
We could use some more infrastructure here.
(1) A 'make randomconfig' tool that generates a random configuration.
mconfig -m random, it's even written by you ;)
my current mconfig working version is on
[viro]
making the internal API frozen by exposure to library users.
[Gooch]
An exercise in decent API design. BFD.
^^^
Nah, that's the *de*compilation library.
(Sorry, couldn't resist.)
Peter
-
To unsubscribe from this list: send the line "unsubscribe
[viro]
The _real_ problem is preprocessor abuse. BTW, could we schedule for
2.5 the following?
* things like CONFIG_FOO are _always_ defined. As 0 or 1, that is.
* #ifdef CONFIG_FOO = if (CONFIG_FOO) in *.c. gcc will kill the unused
branches just fine.
Notwithstanding the
If you want to look at an existing source-code analyzer that works
hand-in-glove with compilers, to skim for good or bad ideas, take a look
at the LSE/SCA combo from the DECset tools. (Dunno if DECset is even
still available; I lost track of what went where as they were dicing up
the company.)
In the .config file, the problem is that the Makefiles source .config and
then do a lot of "ifdef CONFIG_FOO" tests. There are about 300 instances
of this in 2.4.0-test-7.
In include/linux/autoconf.h, the problem is in the *.c (and *.h and *.S)
files that do a lot of "#ifdef CONFIG_BAR" and
Yeah. Long transition, plus user education (which never works, dontcha
know), plus probably a helper tool akin to checkconfig.
I think it would help to have a well documented "module writers kit".
(Maybe there is one and I'm not aware of it).
mec I'm all in favor of 'if ( CONFIG_BAR )', but
On Thu, 7 Sep 2000 19:14:26 -0500,
Michael Elizabeth Chastain [EMAIL PROTECTED] wrote:
Yeah. Long transition, plus user education (which never works, dontcha
know), plus probably a helper tool akin to checkconfig.
I think it would help to have a well documented "module writers kit".
(Maybe
David Woodhouse wrote:
But how much work would it require to do so? If your theoretical vendor of
closed-source compiler backends were to believe that a shared lib of the
GCC frontend would be legal, surely they'd just make it shared themselves,
then use it as such? It's hardly a effective
Date: Wed, 6 Sep 2000 14:42:17 -0700 (PDT)
From: Jonathan Walther <[EMAIL PROTECTED]>
If the shared library is under GPL (not LGPL) that isn't a
problem. No?
Shared library linkage brings you into the same grey area that binary
only kernel modules fall into, this means it's risky
Date:Wed, 6 Sep 2000 08:59:56 -0600
From: Richard Gooch <[EMAIL PROTECTED]>
Jamie Lokier writes:
> Sorry, there's a GCC policy decision against putting it into a
> shared library.
Why?
Because this allows proprietary software vendor X to write
closed-source compiler
Alexander Viro wrote:
>
> On Wed, 6 Sep 2000, Martin Dalecki wrote:
>
> >
> > So may I just suggest to repleace the usage of cpp at all with something
> > more
> > suitable for the task at hand and with a much more regular/stringent
> > syntax
> > better fitting into the syntax of the pure C
On Wed, 6 Sep 2000, Alexander Viro wrote:
>
> Add "and that broken code gets fixed in utterly bogus ways 20 versions
> down the road, when nobody remembers WTF had happened". Repeat several
> times (and rarely-used parts _will_ accumulate such crap) and you've got
> Lovecraftian beasts lurking
On Wed, 6 Sep 2000, Martin Dalecki wrote:
>
> So may I just suggest to repleace the usage of cpp at all with something
> more
> suitable for the task at hand and with a much more regular/stringent
> syntax
> better fitting into the syntax of the pure C language like m4 for
> example?
>
No.
On Wed, 6 Sep 2000, Alexander Viro wrote:
>
>
> On 6 Sep 2000, Linus Torvalds wrote:
>
> > However, what I think Al Viro dislikes about this is that it does tend
> > to leave code that won't compile, just because some of the accesses are
> > in places that the compiler doesn't see due to
Alexander Viro wrote:
>
> On Wed, 6 Sep 2000, Michael Elizabeth Chastain wrote:
>
> > We could use some more infrastructure here.
> >
> > (1) A 'make randomconfig' tool that generates a random configuration.
> >
> > (2) Make the architecture a configuration variable (!)
> >
> > (3) A collection
Linus writes ...
mec> (2) Make the architecture a configuration variable (!)
linus> Why?
The real reason is that it's the right thing to do. Part of a
configuration is "what machine it's for".
Here are some benefits:
(a) Arjan's testing machinery would catch problems in all architectures,
r
> (0) knowledge that CONFIG.FOO15 doesn't affect anything other than set of
> source files being compiled.
The Makefiles already know this. Specifically, mkdep.c analyzes which
C files depend on which options. Look at some of your .depend files.
Michael
-
To unsubscribe from this list: send
On 6 Sep 2000, Linus Torvalds wrote:
> However, what I think Al Viro dislikes about this is that it does tend
> to leave code that won't compile, just because some of the accesses are
> in places that the compiler doesn't see due to the pre-processor (or due
> to other build-rules: like in
On Wed, 6 Sep 2000, Michael Elizabeth Chastain wrote:
>
> We could use some more infrastructure here.
>
> (1) A 'make randomconfig' tool that generates a random configuration.
There already are people that do this.
The problem is that developers are lazy. All good programmers are lazy.
They
On Wed, 6 Sep 2000, Michael Elizabeth Chastain wrote:
> We could use some more infrastructure here.
>
> (1) A 'make randomconfig' tool that generates a random configuration.
>
> (2) Make the architecture a configuration variable (!)
>
> (3) A collection of RPM's so that people can download
On 6 Sep 2000, Linus Torvalds wrote:
> At the same time, there is no question that true #ifdef's have
> advantages, even outside the issue of gcc's inability to forget literal
> strings. They are often required for data structures in general: C does
> not have "conditional data structures".
We could use some more infrastructure here.
(1) A 'make randomconfig' tool that generates a random configuration.
(2) Make the architecture a configuration variable (!)
(3) A collection of RPM's so that people can download and install
all the cross tools easily.
With this stuff available,
In article <8p5u21$r0$[EMAIL PROTECTED]> you wrote:
> However, what I think Al Viro dislikes about this is that it does tend
> to leave code that won't compile, just because some of the accesses are
> in places that the compiler doesn't see due to the pre-processor (or due
> to other
In article <[EMAIL PROTECTED]>,
Jamie Lokier <[EMAIL PROTECTED]> wrote:
>Linus Torvalds wrote:
>> And I'm saying that if people really want to do this, then use the
>> computer to do it for you, having more than just "grep", and making your
>> tools aware of it.
>
>I'd just like to add, for the
In article <[EMAIL PROTECTED]>,
Andrew Morton <[EMAIL PROTECTED]> wrote:
>
>But still, doing the conditional compilation at compile-time rather than
>preprocessing-time is so *nice* that if you don't have too many literal
>strings floating about it may be justifiable.
>
>In cs89x0.c you reduce
Alexander Viro writes:
>
>
>
> On Wed, 6 Sep 2000, Richard Gooch wrote:
>
> > Jamie Lokier writes:
> > > Chris Wedgwood wrote:
> > > > I think would be really cool if all this 'magic' in gcc (whatever
> > > > part of gcc is irrelevant right now) would be exported into a library
> > > > or
On Wed, 6 Sep 2000, Richard Gooch wrote:
> Jamie Lokier writes:
> > Chris Wedgwood wrote:
> > > I think would be really cool if all this 'magic' in gcc (whatever
> > > part of gcc is irrelevant right now) would be exported into a library
> > > or shared object which editors could then load
On Wed, 6 Sep 2000, Alan Cox wrote:
> > As readability - it's definitely at least as readable as
> > #if[def]. It also provides more consistent syntax. And when you are
> > using ifdef to violate scoping - your code is in need of rewrite anyway.
>
> You still need the #ifdef stuff as
Jamie Lokier writes:
> Chris Wedgwood wrote:
> > I think would be really cool if all this 'magic' in gcc (whatever
> > part of gcc is irrelevant right now) would be exported into a library
> > or shared object which editors could then load and use... dynamically
> > perhaps.
>
> Sorry, there's a
Chris Wedgwood wrote:
> I think would be really cool if all this 'magic' in gcc (whatever
> part of gcc is irrelevant right now) would be exported into a library
> or shared object which editors could then load and use... dynamically
> perhaps.
Sorry, there's a GCC policy decision against
Linus Torvalds wrote:
> And I'm saying that if people really want to do this, then use the
> computer to do it for you, having more than just "grep", and making your
> tools aware of it.
I'd just like to add, for the benefit of onlookers, that this is
quite easy.
Temporarily change name of
Chris Wedgwood wrote:
[Gcc not eliminating trivial dead code...
did you compile without optimisation?]
Gcc 2.96 does remove the unreached code in your example,
but it still emits string constants.
int func()
{
if (1)
a = "foo";
else
a = "bar";
}
.LC0:
.string "foo"
.LC1:
> As readability - it's definitely at least as readable as
> #if[def]. It also provides more consistent syntax. And when you are
> using ifdef to violate scoping - your code is in need of rewrite anyway.
You still need the #ifdef stuff as well for half of it so I dont see what
it buys you
[EMAIL PROTECTED] (Martin Dalecki) wrote on 06.09.00 in
<[EMAIL PROTECTED]>:
> Alexander Viro wrote:
> >
> > On Wed, 6 Sep 2000, Martin Dalecki wrote:
> >
> > > Easy - the same way you do for cross compilation. Basically just:
> > >
> > > export CC=g++ --some-magic-long-option-i-dont-remember;
[EMAIL PROTECTED] (Martin Dalecki) wrote on 06.09.00 in
[EMAIL PROTECTED]:
Alexander Viro wrote:
On Wed, 6 Sep 2000, Martin Dalecki wrote:
Easy - the same way you do for cross compilation. Basically just:
export CC=g++ --some-magic-long-option-i-dont-remember; make
... and
As readability - it's definitely at least as readable as
#if[def]. It also provides more consistent syntax. And when you are
using ifdef to violate scoping - your code is in need of rewrite anyway.
You still need the #ifdef stuff as well for half of it so I dont see what
it buys you
-
Jamie Lokier writes:
Chris Wedgwood wrote:
I think would be really cool if all this 'magic' in gcc (whatever
part of gcc is irrelevant right now) would be exported into a library
or shared object which editors could then load and use... dynamically
perhaps.
Sorry, there's a GCC policy
On Wed, 6 Sep 2000, Alan Cox wrote:
As readability - it's definitely at least as readable as
#if[def]. It also provides more consistent syntax. And when you are
using ifdef to violate scoping - your code is in need of rewrite anyway.
You still need the #ifdef stuff as well for
On Wed, 6 Sep 2000, Richard Gooch wrote:
Jamie Lokier writes:
Chris Wedgwood wrote:
I think would be really cool if all this 'magic' in gcc (whatever
part of gcc is irrelevant right now) would be exported into a library
or shared object which editors could then load and use...
Alexander Viro writes:
On Wed, 6 Sep 2000, Richard Gooch wrote:
Jamie Lokier writes:
Chris Wedgwood wrote:
I think would be really cool if all this 'magic' in gcc (whatever
part of gcc is irrelevant right now) would be exported into a library
or shared object which
In article [EMAIL PROTECTED],
Jamie Lokier [EMAIL PROTECTED] wrote:
Linus Torvalds wrote:
And I'm saying that if people really want to do this, then use the
computer to do it for you, having more than just "grep", and making your
tools aware of it.
I'd just like to add, for the benefit of
In article 8p5u21$r0$[EMAIL PROTECTED] you wrote:
However, what I think Al Viro dislikes about this is that it does tend
to leave code that won't compile, just because some of the accesses are
in places that the compiler doesn't see due to the pre-processor (or due
to other build-rules: like
We could use some more infrastructure here.
(1) A 'make randomconfig' tool that generates a random configuration.
(2) Make the architecture a configuration variable (!)
(3) A collection of RPM's so that people can download and install
all the cross tools easily.
With this stuff available,
On 6 Sep 2000, Linus Torvalds wrote:
At the same time, there is no question that true #ifdef's have
advantages, even outside the issue of gcc's inability to forget literal
strings. They are often required for data structures in general: C does
not have "conditional data structures".
On Wed, 6 Sep 2000, Michael Elizabeth Chastain wrote:
We could use some more infrastructure here.
(1) A 'make randomconfig' tool that generates a random configuration.
(2) Make the architecture a configuration variable (!)
(3) A collection of RPM's so that people can download and
On Wed, 6 Sep 2000, Michael Elizabeth Chastain wrote:
We could use some more infrastructure here.
(1) A 'make randomconfig' tool that generates a random configuration.
There already are people that do this.
The problem is that developers are lazy. All good programmers are lazy.
They want
Linus writes ...
mec (2) Make the architecture a configuration variable (!)
linus Why?
The real reason is that it's the right thing to do. Part of a
configuration is "what machine it's for".
Here are some benefits:
(a) Arjan's testing machinery would catch problems in all architectures,
Alexander Viro wrote:
On Wed, 6 Sep 2000, Michael Elizabeth Chastain wrote:
We could use some more infrastructure here.
(1) A 'make randomconfig' tool that generates a random configuration.
(2) Make the architecture a configuration variable (!)
(3) A collection of RPM's so that
On Wed, 6 Sep 2000, Alexander Viro wrote:
On 6 Sep 2000, Linus Torvalds wrote:
However, what I think Al Viro dislikes about this is that it does tend
to leave code that won't compile, just because some of the accesses are
in places that the compiler doesn't see due to the
On Wed, 6 Sep 2000, Martin Dalecki wrote:
IRONY ON
So may I just suggest to repleace the usage of cpp at all with something
more
suitable for the task at hand and with a much more regular/stringent
syntax
better fitting into the syntax of the pure C language like m4 for
example?
/IRONY
On Wed, 6 Sep 2000, Alexander Viro wrote:
Add "and that broken code gets fixed in utterly bogus ways 20 versions
down the road, when nobody remembers WTF had happened". Repeat several
times (and rarely-used parts _will_ accumulate such crap) and you've got
Lovecraftian beasts lurking in
Alexander Viro wrote:
On Wed, 6 Sep 2000, Martin Dalecki wrote:
IRONY ON
So may I just suggest to repleace the usage of cpp at all with something
more
suitable for the task at hand and with a much more regular/stringent
syntax
better fitting into the syntax of the pure C language
Date:Wed, 6 Sep 2000 08:59:56 -0600
From: Richard Gooch [EMAIL PROTECTED]
Jamie Lokier writes:
Sorry, there's a GCC policy decision against putting it into a
shared library.
Why?
Because this allows proprietary software vendor X to write
closed-source compiler
Richard Gooch wrote:
>
> It will probably take about 5 years after a new version of GCC which
> has this fix before we can trust it to produce correct code for the
> kernel.
I don't think it's that bad, Richard. As davem points out, the dead
code elimination works OK. Chris has a
On Wed, 6 Sep 2000, Martin Dalecki wrote:
>Basically I will just guess: The next maybe non free version of
>source navigator will use the mechanism I have just described above.
>So maybe there is already someone at RedHat doing exactly this work
>already ;-).
Source Navigator is GPL open source
Alexander Viro writes:
>
>
>
> On Wed, 6 Sep 2000, Andrew Morton wrote:
>
> > > cat t.c
> > foo()
> > {
> > if (0)
> > bar("hhh");
> > }
> > > gcc -O2 -c t.c
> > > strings t.o | grep hhh
> > hhh
Nasty, eh?
> Eww... Do they _ever_ remove dead code?
I guess
Date:Tue, 5 Sep 2000 21:32:45 -0400 (EDT)
From: Alexander Viro <[EMAIL PROTECTED]>
On Wed, 6 Sep 2000, Andrew Morton wrote:
> > gcc -O2 -c t.c
> > strings t.o | grep hhh
> hhh
Eww... Do they _ever_ remove dead code?
They remove the code, they just forget to
On Wed, 6 Sep 2000, Andrew Morton wrote:
> > cat t.c
> foo()
> {
> if (0)
> bar("hhh");
> }
> > gcc -O2 -c t.c
> > strings t.o | grep hhh
> hhh
Eww... Do they _ever_ remove dead code?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
Alexander Viro wrote:
>
>
> if (CONFIG_FOO) {
>
> } else {
>
> }
There are a zillion reasons why this technique is superior
to using `#ifdef CONFIG_FOO'. But, alas, gcc fumbles
the ball:
> cat t.c
foo()
{
if (0)
On Wed, 6 Sep 2000, Chris Wedgwood wrote:
> Oh, yes there is.
>
> if (CONFIG_FOO) {
>
> } else {
>
> }
>
> gcc can optimize that away and parser will see the whole thing.
>
> I'm not sure I like this construct either.
On Wed, 6 Sep 2000, Martin Dalecki wrote:
> Alexander Viro wrote:
> >
> > On Wed, 6 Sep 2000, Martin Dalecki wrote:
> >
> > > Easy - the same way you do for cross compilation. Basically just:
> > >
> > > export CC=g++ --some-magic-long-option-i-dont-remember; make
> >
> > ... and you still
Alexander Viro wrote:
>
> On Wed, 6 Sep 2000, Martin Dalecki wrote:
>
> > Easy - the same way you do for cross compilation. Basically just:
> >
> > export CC=g++ --some-magic-long-option-i-dont-remember; make
>
> ... and you still have only a subset of the tree, simply because it is fed
>
On Wed, 6 Sep 2000, Martin Dalecki wrote:
> Easy - the same way you do for cross compilation. Basically just:
>
> export CC=g++ --some-magic-long-option-i-dont-remember; make
... and you still have only a subset of the tree, simply because it is fed
through cpp before it reaches the parser.
On Tue, Sep 05, 2000 at 07:19:11PM -0400, Peter Rival wrote:
> Linus Torvalds wrote:
>
> > On Wed, 6 Sep 2000, Chris Wedgwood wrote:
> > >
> > > There are several other structures that have the same problem; very
> > > generic sounding members. I wonder would a patch changing struct page
> > >
Linus Torvalds wrote:
>
> On Tue, 5 Sep 2000, Alexander Viro wrote:
> > >
> > > What would be acceptable is something that understands C, and that can be
> > > used to follow these things. Like "tags".
> >
> > I don't like hungarian notation too, but tags is out of question,
> >
On Wed, 6 Sep 2000, Chris Wedgwood wrote:
>
> There are several other structures that have the same problem; very
> generic sounding members. I wonder would a patch changing struct page
> to something like this be acceptable?
No.
What would be acceptable is something that understands C, and
On Tue, 5 Sep 2000, Linus Torvalds wrote:
>
>
> On Wed, 6 Sep 2000, Chris Wedgwood wrote:
> >
> > There are several other structures that have the same problem; very
> > generic sounding members. I wonder would a patch changing struct page
> > to something like this be acceptable?
>
> No.
On Wed, 6 Sep 2000, Chris Wedgwood wrote:
> On Tue, Sep 05, 2000 at 04:15:29PM -0400, Alexander Viro wrote:
>
> 2.5 the following?
> * things like CONFIG_FOO are _always_ defined. As 0 or 1, that is.
> * #ifdef CONFIG_FOO => if (CONFIG_FOO) in *.c. gcc will kill the unused
>
On Wed, 6 Sep 2000, Chris Wedgwood wrote:
There are several other structures that have the same problem; very
generic sounding members. I wonder would a patch changing struct page
to something like this be acceptable?
No.
What would be acceptable is something that understands C, and that
Linus Torvalds wrote:
On Tue, 5 Sep 2000, Alexander Viro wrote:
What would be acceptable is something that understands C, and that can be
used to follow these things. Like "tags".
I don't like hungarian notation too, but tags is out of question,
unfortunately. Too much
On Tue, Sep 05, 2000 at 07:19:11PM -0400, Peter Rival wrote:
Linus Torvalds wrote:
On Wed, 6 Sep 2000, Chris Wedgwood wrote:
There are several other structures that have the same problem; very
generic sounding members. I wonder would a patch changing struct page
to something like
On Wed, 6 Sep 2000, Martin Dalecki wrote:
Easy - the same way you do for cross compilation. Basically just:
export CC=g++ --some-magic-long-option-i-dont-remember; make
... and you still have only a subset of the tree, simply because it is fed
through cpp before it reaches the parser.
Alexander Viro wrote:
On Wed, 6 Sep 2000, Martin Dalecki wrote:
Easy - the same way you do for cross compilation. Basically just:
export CC=g++ --some-magic-long-option-i-dont-remember; make
... and you still have only a subset of the tree, simply because it is fed
through cpp
On Wed, 6 Sep 2000, Chris Wedgwood wrote:
Oh, yes there is.
if (CONFIG_FOO) {
} else {
}
gcc can optimize that away and parser will see the whole thing.
I'm not sure I like this construct either.
Yes,
Alexander Viro wrote:
if (CONFIG_FOO) {
} else {
}
There are a zillion reasons why this technique is superior
to using `#ifdef CONFIG_FOO'. But, alas, gcc fumbles
the ball:
cat t.c
foo()
{
if (0)
On Wed, 6 Sep 2000, Andrew Morton wrote:
cat t.c
foo()
{
if (0)
bar("hhh");
}
gcc -O2 -c t.c
strings t.o | grep hhh
hhh
Eww... Do they _ever_ remove dead code?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
Alexander Viro writes:
On Wed, 6 Sep 2000, Andrew Morton wrote:
cat t.c
foo()
{
if (0)
bar("hhh");
}
gcc -O2 -c t.c
strings t.o | grep hhh
hhh
Nasty, eh?
Eww... Do they _ever_ remove dead code?
I guess not. Also, even if we get the
On Wed, 6 Sep 2000, Martin Dalecki wrote:
Basically I will just guess: The next maybe non free version of
source navigator will use the mechanism I have just described above.
So maybe there is already someone at RedHat doing exactly this work
already ;-).
Source Navigator is GPL open source
Richard Gooch wrote:
It will probably take about 5 years after a new version of GCC which
has this fix before we can trust it to produce correct code for the
kernel.
I don't think it's that bad, Richard. As davem points out, the dead
code elimination works OK. Chris has a counter-example
Date:Tue, 5 Sep 2000 21:32:45 -0400 (EDT)
From: Alexander Viro [EMAIL PROTECTED]
On Wed, 6 Sep 2000, Andrew Morton wrote:
gcc -O2 -c t.c
strings t.o | grep hhh
hhh
Eww... Do they _ever_ remove dead code?
They remove the code, they just forget to mark the
Arjan van de Ven wrote:
>
> In article <[EMAIL PROTECTED]> you
>wrote:
>
> > Well, the bug seems to exactly using the page after a "free_page()". Which
> > is always a bug, but at least should be easy to fix.
>
> > I've considered making "free_page()" a macro something like
>
> >
Arjan van de Ven wrote:
In article [EMAIL PROTECTED] you
wrote:
Well, the bug seems to exactly using the page after a "free_page()". Which
is always a bug, but at least should be easy to fix.
I've considered making "free_page()" a macro something like
__free_page(x);
On Mon, 4 Sep 2000, Jamie Lokier wrote:
> Alexander Viro wrote:
> > > *((unsigned long *)()) = NULL;
> >
> > free_page(foo()) and we've got problems...
>
> Alan really meant
>
> *((unsigned long *)&(x)) = NULL;
>
> and screw you if it's not an lvalue.
There's a lot of places that
Alexander Viro wrote:
> > *((unsigned long *)()) = NULL;
>
> free_page(foo()) and we've got problems...
Alan really meant
*((unsigned long *)&(x)) = NULL;
and screw you if it's not an lvalue.
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
On Sun, 3 Sep 2000, Alan Cox wrote:
> > I've considered making "free_page()" a macro something like
> >
> > __free_pge(x);
> > x = NULL;
> >
> > but that works only for lvalues, of course, and not all users are
> > lvalue-users, so it's hard to do. But that would have caught this.
>
> I've considered making "free_page()" a macro something like
>
> __free_pge(x);
> x = NULL;
>
> but that works only for lvalues, of course, and not all users are
> lvalue-users, so it's hard to do. But that would have caught this.
Not that hard. (barf buckets at the ready)
1 - 100 of 109 matches
Mail list logo
