Just out of a need to know things :)
What compiler do Alan Cox and Linus use to create the 2.4 series
kernels?
I am currently using RedHat's compiler gcc-2.96-85 and have been told
not to do so because it "breaks things" .
So far it has not broken anything, but then again i am compiling kernels
for use on my RedHat Distributions.
The question would be .. how hard is it going to be for me to upgrade to
gcc 3 + and will i get any benefit from it? WillI loose any
advantages that i currently do have?
Or can i still get what i need from compiling 2.4.12 or 2.4.13 with the
compiler I have now?
Thank you
Madhav Diwan
Note: The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Wagner Weber & Williams
On Thu, Oct 25, 2001 at 10:31:08AM -0400, Frontgate Lab wrote:
> Just out of a need to know things :)
>
> What compiler do Alan Cox and Linus use to create the 2.4 series
> kernels?
>
> I am currently using RedHat's compiler gcc-2.96-85 and have been told
> not to do so because it "breaks things" .
This is likely due to the fact that some people are still living with
the misconception that all gcc-2.96 releases are buggy. They are not;
only early versions are.
gcc-2.95.[34] and gcc-2.96-(newer versions) are viable choices if you
want a working kernel. Some other versions might work, but then again,
they might not :-)
> So far it has not broken anything, but then again i am compiling kernels
> for use on my RedHat Distributions.
>
> The question would be .. how hard is it going to be for me to upgrade to
> gcc 3 + and will i get any benefit from it? WillI loose any
> advantages that i currently do have?
At the moment, gcc3 doesn't work too well with the kernel, and you won't
get any large benefit.
> Or can i still get what i need from compiling 2.4.12 or 2.4.13 with the
> compiler I have now?
Yes.
/David Weinehall
_ _
// David Weinehall <[email protected]> /> Northern lights wander \\
// Project MCA Linux hacker // Dance across the winter sky //
\> http://www.acc.umu.se/~tao/ </ Full colour fire </
> What compiler do Alan Cox and Linus use to create the 2.4 series
> kernels?
Im using Red Hat 2.96-85
> I am currently using RedHat's compiler gcc-2.96-85 and have been told
> not to do so because it "breaks things" .
Generally ignore that story: 2.96-54 has problems, but not the later ones
> The question would be .. how hard is it going to be for me to upgrade to
> gcc 3 + and will i get any benefit from it? WillI loose any
> advantages that i currently do have?
Gcc 3.0 doesn't always build correct kernels. Its very much a .0 release -
new infrastructure, the core to do far better thinga than gcc 2.* but not
yet the actual results as the bugs all get kicked out
> Or can i still get what i need from compiling 2.4.12 or 2.4.13 with the
> compiler I have now?
Yeah
David Weinehall wrote:
>
> On Thu, Oct 25, 2001 at 10:31:08AM -0400, Frontgate Lab wrote:
> > Just out of a need to know things :)
> >
> > What compiler do Alan Cox and Linus use to create the 2.4 series
> > kernels?
> >
> > I am currently using RedHat's compiler gcc-2.96-85 and have been told
> > not to do so because it "breaks things" .
>
> This is likely due to the fact that some people are still living with
> the misconception that all gcc-2.96 releases are buggy. They are not;
> only early versions are.
>
> gcc-2.95.[34] and gcc-2.96-(newer versions) are viable choices if you
> want a working kernel. Some other versions might work, but then again,
>
> At the moment, gcc3 doesn't work too well with the kernel, and you won't
> get any large benefit.
>
I use gcc3 to compile anything and everything I need. With the
exception of "multi-line literal complaints", my kernel compiles fine.
Is there anything that I should know?
Alan Cox wrote:
> > What compiler do Alan Cox and Linus use to create the 2.4 series
> > kernels?
>
> Im using Red Hat 2.96-85
>
> > I am currently using RedHat's compiler gcc-2.96-85 and have been told
> > not to do so because it "breaks things" .
>
> Generally ignore that story: 2.96-54 has problems, but not the later ones
>
> > The question would be .. how hard is it going to be for me to upgrade to
> > gcc 3 + and will i get any benefit from it? WillI loose any
> > advantages that i currently do have?
>
> Gcc 3.0 doesn't always build correct kernels. Its very much a .0 release -
> new infrastructure, the core to do far better thinga than gcc 2.* but not
> yet the actual results as the bugs all get kicked out
>
> > Or can i still get what i need from compiling 2.4.12 or 2.4.13 with the
> > compiler I have now?
>
> Yeah
> -
Just for information, none of the Redhat compilers (the 2.96 leg) build
all of XFS correctly, see this bug for info:
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=54571
Steve
Hi,
> I use gcc3 to compile anything and everything I need. With the
> exception of "multi-line literal complaints", my kernel compiles fine.
What exact version of gcc do you use. All attempts to use gcc3+ have
caused compiler failures or kernel panics for me.
Axel
> > At the moment, gcc3 doesn't work too well with the kernel, and you won't
> > get any large benefit.
>
> I use gcc3 to compile anything and everything I need. With the
> exception of "multi-line literal complaints", my kernel compiles fine.
>
> Is there anything that I should know?
Mostly that gcc 3.0 generally produces slower code. I've had a couple of
noticed glitches with -ac but those have workarounds in the tree now
On Thu, Oct 25, 2001 at 10:27:18AM -0500, Steve Lord wrote:
> Just for information, none of the Redhat compilers (the 2.96 leg) build
> all of XFS correctly, see this bug for info:
>
> http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=54571
Yeah, but it is a longstanding reload bug you can get bitten on other code
in 2.95.x, 3.0.x or 3.1 too, you just have to stress the compiler hard and
have bad luck.
Jakub
> On Thu, Oct 25, 2001 at 10:27:18AM -0500, Steve Lord wrote:
> > Just for information, none of the Redhat compilers (the 2.96 leg) build
> > all of XFS correctly, see this bug for info:
> >
> > http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=54571
>
> Yeah, but it is a longstanding reload bug you can get bitten on other code
> in 2.95.x, 3.0.x or 3.1 too, you just have to stress the compiler hard and
> have bad luck.
>
> Jakub
OK thanks, good to know we are stressing the compilers ;-)
Fortunately it appears to be rare enough in XFS that most
people never get bitten by it.
Steve
GCC 3.0 Produces slower code, eh? I was of the understanding that it
contained many more optimizations than previous versions...???
Any way, I've been able to run my system based entirely on a fairly
recent GCC CVS-3.02 snapshot, including kernels, and everything EXCEPT
for glibc which is specifically incompatible according to the GNU folks.
By way of information however, neither of the GCC 3.0 releases (3.0.0 or
3.0.1) work at all on my system, and I cannot get a kernel to function
at better than -O2 (not that I could get that to work in 2.95.* or
2.96.* either).
--Lost Logic (Brandon Low)
Alan Cox wrote:
>>>At the moment, gcc3 doesn't work too well with the kernel, and you won't
>>>get any large benefit.
>>>
>>I use gcc3 to compile anything and everything I need. With the
>>exception of "multi-line literal complaints", my kernel compiles fine.
>>
>>Is there anything that I should know?
>>
>
>Mostly that gcc 3.0 generally produces slower code. I've had a couple of
>noticed glitches with -ac but those have workarounds in the tree now
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
>
> GCC 3.0 Produces slower code, eh? I was of the understanding that it
> contained many more optimizations than previous versions...???
It does - but the end result right now is typically slower. it has the
infrastructure and optimisation code to create faster code than 2.x ever
could but it isnt yet at the point it has been refined to do so
On 20011025 Alan Cox wrote:
>> GCC 3.0 Produces slower code, eh? I was of the understanding that it
>> contained many more optimizations than previous versions...???
>
>It does - but the end result right now is typically slower. it has the
>infrastructure and optimisation code to create faster code than 2.x ever
>could but it isnt yet at the point it has been refined to do so
>-
3.0.2 is out. Time to check it.
What I sure have seen is that code is much bigger than with 2.96. About 40k
for an 800k kernel.
Wil try with 14-pre1.
--
J.A. Magallon # Let the source be with you...
mailto:[email protected]
Mandrake Linux release 8.2 (Cooker) for i586
Linux werewolf 2.4.14-pre1-beo #1 SMP Thu Oct 25 16:19:19 CEST 2001 i686
On 20011025 Lost Logic wrote:
>GCC 3.0 Produces slower code, eh? I was of the understanding that it
>contained many more optimizations than previous versions...???
>
>Any way, I've been able to run my system based entirely on a fairly
>recent GCC CVS-3.02 snapshot, including kernels, and everything EXCEPT
>for glibc which is specifically incompatible according to the GNU folks.
>
>By way of information however, neither of the GCC 3.0 releases (3.0.0 or
>3.0.1) work at all on my system, and I cannot get a kernel to function
>at better than -O2 (not that I could get that to work in 2.95.* or
>2.96.* either).
>
-O3 activates -finline-functions:
`-finline-functions'
Integrate all simple functions into their callers. The compiler
heuristically decides which functions are simple enough to be worth
integrating in this way.
If all calls to a given function are integrated, and the function
is declared `static', then the function is normally not output as
assembler code in its own right.
Last paragraph is the key. Perhaps previous gcc'd did not all his work
as the manual says (ie, did not kill the non-inline version, bug),
but people has got used to the bug, and see it as a feature.
--
J.A. Magallon # Let the source be with you...
mailto:[email protected]
Mandrake Linux release 8.2 (Cooker) for i586
Linux werewolf 2.4.14-pre1-beo #1 SMP Thu Oct 25 16:19:19 CEST 2001 i686
On Friday 26 October 2001 00:13, J . A . Magallon wrote:
> On 20011025 Lost Logic wrote:
> >GCC 3.0 Produces slower code, eh? I was of the understanding that it
> >contained many more optimizations than previous versions...???
> >
> >Any way, I've been able to run my system based entirely on a fairly
> >recent GCC CVS-3.02 snapshot, including kernels, and everything EXCEPT
> >for glibc which is specifically incompatible according to the GNU folks.
> >
> >By way of information however, neither of the GCC 3.0 releases (3.0.0 or
> >3.0.1) work at all on my system, and I cannot get a kernel to function
> >at better than -O2 (not that I could get that to work in 2.95.* or
> >2.96.* either).
>
> -O3 activates -finline-functions:
> `-finline-functions'
> Integrate all simple functions into their callers. The compiler
> heuristically decides which functions are simple enough to be worth
> integrating in this way.
>
> If all calls to a given function are integrated, and the function
> is declared `static', then the function is normally not output as
> assembler code in its own right.
>
> Last paragraph is the key. Perhaps previous gcc'd did not all his work
> as the manual says (ie, did not kill the non-inline version, bug),
> but people has got used to the bug, and see it as a feature.
I believe '-fkeep-inline-functions' is your friend in this case. I haven't
tested it though on the kernel.
regards
`Allan
On Fri, Oct 26, 2001 at 11:18:46AM +0200, Allan Sandfeld wrote:
> > Last paragraph is the key. Perhaps previous gcc'd did not all his work
> > as the manual says (ie, did not kill the non-inline version, bug),
> > but people has got used to the bug, and see it as a feature.
>
> I believe '-fkeep-inline-functions' is your friend in this case. I haven't
> tested it though on the kernel.
Definitely not. -fkeep-inline-functions will not only prevent in compiler
eyes unused static functions from beeing optimized away, but you'll get tons
of code you really don't need.
__attribute__((used)) is what you can use in current gcc trunk to just say
the compiler that it should not optimize away a particular function even if
it seems to be unused at -O3 (e.g. it might be referenced from inline assembly,
whatever).
No matter what, using -O3 for kernel builds is a bad idea, in vast majority
functions which make sense to be inlined are in the kernel marked so with
inline keyword, and the rest does not. With -O3 for kernel you just get
bigger code with no gains (if there are some gains somewhere, then it should
be considered to be marked inline on a case by case basis).
Jakub