2001-12-19 19:07:26

by Martin Devera

[permalink] [raw]
Subject: gcc 3.0.2/kernel details (-O issue)

Hello,
just another crash report. But interesting one IMHO.
When I compile 2.3.16/SMP with gcc 3.0.2 then it works.
But when I changed -O2 to -O (compile speed reasons)
the compilation succeeded but kernel crashed during
boot (in sys_sigreturn).

devik



2001-12-19 19:33:31

by Chris Meadors

[permalink] [raw]
Subject: Re: gcc 3.0.2/kernel details (-O issue)

On Wed, 19 Dec 2001, devik wrote:

> Hello,
> just another crash report. But interesting one IMHO.
> When I compile 2.3.16/SMP with gcc 3.0.2 then it works.
> But when I changed -O2 to -O (compile speed reasons)
> the compilation succeeded but kernel crashed during
> boot (in sys_sigreturn).

The kernel relies on features turned on by -O2 and will not function
properly with just -O of any version of gcc.

-Chris
--
Two penguins were walking on an iceberg. The first penguin said to the
second, "you look like you are wearing a tuxedo." The second penguin
said, "I might be..." --David Lynch, Twin Peaks

2001-12-19 19:39:42

by Martin Devera

[permalink] [raw]
Subject: Re: gcc 3.0.2/kernel details (-O issue)

It is interesting that 2.2 can be done with -O. Also I'd expect
errors during compilation and not silent crash...
devik

> The kernel relies on features turned on by -O2 and will not function
> properly with just -O of any version of gcc.

2001-12-19 20:03:59

by Robert Love

[permalink] [raw]
Subject: Re: gcc 3.0.2/kernel details (-O issue)

On Wed, 2001-12-19 at 14:39, Martin Devera wrote:
> It is interesting that 2.2 can be done with -O. Also I'd expect
> errors during compilation and not silent crash...

Well, you certainly won't get errors, because compiler optimizations
shouldn't change expected syntax.

-O2 is the standard optimization level for the kernel; everything is
compiled via it. When developers test their code, nuances that the
optimization introduce are accepted. Removing the optimization may
break those expectations. Thus the kernel requires it.

Robert Love

2001-12-20 00:10:37

by Erik Mouw

[permalink] [raw]
Subject: Re: gcc 3.0.2/kernel details (-O issue)

On Wed, Dec 19, 2001 at 03:03:30PM -0500, Robert Love wrote:
> On Wed, 2001-12-19 at 14:39, Martin Devera wrote:
> > It is interesting that 2.2 can be done with -O. Also I'd expect
> > errors during compilation and not silent crash...
>
> Well, you certainly won't get errors, because compiler optimizations
> shouldn't change expected syntax.

It doesn't change syntax, but anything lower than -O1 simply doesn't
inline functions with an "inline" attribute. The result is that the
inline functions in header files won't get inlined and the compiler
will complain about missing functions at link time (or module insert
time).

I'm actually surprised that 2.2 can be compiled with -O, AFAIK
linux-2.2 also has a lot of inline functions in headers. I know from
experience that -Os works for 2.4 kernels on ARM, I haven't tested it
with 2.2 or x86.


Erik

--
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Faculty
of Information Technology and Systems, Delft University of Technology,
PO BOX 5031, 2600 GA Delft, The Netherlands Phone: +31-15-2783635
Fax: +31-15-2781843 Email: [email protected]
WWW: http://www-ict.its.tudelft.nl/~erik/

2001-12-20 03:39:55

by H. Peter Anvin

[permalink] [raw]
Subject: Re: gcc 3.0.2/kernel details (-O issue)

Followup to: <[email protected]>
By author: Erik Mouw <[email protected]>
In newsgroup: linux.dev.kernel
>
> It doesn't change syntax, but anything lower than -O1 simply doesn't
> inline functions with an "inline" attribute. The result is that the
> inline functions in header files won't get inlined and the compiler
> will complain about missing functions at link time (or module insert
> time).
>
> I'm actually surprised that 2.2 can be compiled with -O, AFAIK
> linux-2.2 also has a lot of inline functions in headers. I know from
> experience that -Os works for 2.4 kernels on ARM, I haven't tested it
> with 2.2 or x86.
>

-O is -O1. If you turn on the optimizer at all you get inlining.

-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <[email protected]>

2001-12-20 09:21:24

by J.A. Magallon

[permalink] [raw]
Subject: Re: gcc 3.0.2/kernel details (-O issue)


On 20011220 H. Peter Anvin wrote:
>Followup to: <[email protected]>
>By author: Erik Mouw <[email protected]>
>In newsgroup: linux.dev.kernel
>>
>> It doesn't change syntax, but anything lower than -O1 simply doesn't
>> inline functions with an "inline" attribute. The result is that the
>> inline functions in header files won't get inlined and the compiler
>> will complain about missing functions at link time (or module insert
>> time).
>>
>> I'm actually surprised that 2.2 can be compiled with -O, AFAIK
>> linux-2.2 also has a lot of inline functions in headers. I know from
>> experience that -Os works for 2.4 kernels on ARM, I haven't tested it
>> with 2.2 or x86.
>>
>
>-O is -O1. If you turn on the optimizer at all you get inlining.
>

Problem is killing inlined functions. Current kernel relies in the
real version of the funtion staying there even all its uses have been
inlined. GCC's before 3 do not do what they are supposed to and do not
kill the real function. GCC3 kills it in certain cases and build
crashes. So kernel builds ok with old gcc's because they do not do
what they are supposed. Hence all the 'extern inline' mesh...
(plz, correct me if I'm wrong).

By

--
J.A. Magallon # Let the source be with you...
mailto:[email protected]
Mandrake Linux release 8.2 (Cooker) for i586
Linux werewolf 2.4.17-rc2-beo #2 SMP Wed Dec 19 22:24:29 CET 2001 i686

2001-12-20 10:34:33

by Martin Devera

[permalink] [raw]
Subject: Re: gcc 3.0.2/kernel details (-O issue)

> Well, you certainly won't get errors, because compiler optimizations
> shouldn't change expected syntax.

not always true, inb() doesn't compile without -O for example.

> -O2 is the standard optimization level for the kernel; everything is
> compiled via it. When developers test their code, nuances that the
> optimization introduce are accepted. Removing the optimization may
> break those expectations. Thus the kernel requires it.

I'm quite comfortable with the requirement, only I can't imagine
code which depends on -O and -O2 difference. Inline assembly is
handled by compiler so it should not break things ..
Maybe externaly linked assembly code ? But optimization level should
not change register usage in calling convention ..
Please can you give me example which kind of code breaks those
expectations ?

Thanks, Martin

2001-12-20 12:04:29

by H. Peter Anvin

[permalink] [raw]
Subject: Re: gcc 3.0.2/kernel details (-O issue)

J.A. Magallon wrote:

>
> Problem is killing inlined functions. Current kernel relies in the
> real version of the funtion staying there even all its uses have been
> inlined. GCC's before 3 do not do what they are supposed to and do not
> kill the real function. GCC3 kills it in certain cases and build
> crashes. So kernel builds ok with old gcc's because they do not do
> what they are supposed. Hence all the 'extern inline' mesh...
> (plz, correct me if I'm wrong).
>


You're wrong. The thing is the kernel does NOT include any noninline
functions, which breaks if you *don't* inline (like gcc doesn't if the
optimizer isn't turned on...)

-hpa


2001-12-22 22:30:48

by Pavel Machek

[permalink] [raw]
Subject: Re: gcc 3.0.2/kernel details (-O issue)

Hi!

> > It is interesting that 2.2 can be done with -O. Also I'd expect
> > errors during compilation and not silent crash...
>
> Well, you certainly won't get errors, because compiler optimizations
> shouldn't change expected syntax.
>
> -O2 is the standard optimization level for the kernel; everything is
> compiled via it. When developers test their code, nuances that the
> optimization introduce are accepted. Removing the optimization may
> break those expectations. Thus the kernel requires it.

Huh? Those expectations are *bugs*.

Kernel will not link without optimalizations because it *needs*
inlining. Any else dependency is a *bug*.
Pavel

--
(about SSSCA) "I don't say this lightly. However, I really think that the U.S.
no longer is classifiable as a democracy, but rather as a plutocracy." --hpa

2001-12-22 23:52:51

by J.A. Magallon

[permalink] [raw]
Subject: Re: gcc 3.0.2/kernel details (-O issue)


On 20011222 Pavel Machek wrote:
>Hi!
>
>> > It is interesting that 2.2 can be done with -O. Also I'd expect
>> > errors during compilation and not silent crash...
>>
>> Well, you certainly won't get errors, because compiler optimizations
>> shouldn't change expected syntax.
>>
>> -O2 is the standard optimization level for the kernel; everything is
>> compiled via it. When developers test their code, nuances that the
>> optimization introduce are accepted. Removing the optimization may
>> break those expectations. Thus the kernel requires it.
>
>Huh? Those expectations are *bugs*.
>
>Kernel will not link without optimalizations because it *needs*
>inlining. Any else dependency is a *bug*.
> Pavel

Wouldn't it be better to mark such places with something like
#pragma inline, if gcc allows it, than relaying on gcc guesses about
inlining, or options activated in O2 ?

--
J.A. Magallon # Let the source be with you...
mailto:[email protected]
Mandrake Linux release 8.2 (Cooker) for i586
Linux werewolf 2.4.17-beo #1 SMP Fri Dec 21 21:39:36 CET 2001 i686

2001-12-23 13:28:05

by Martin Devera

[permalink] [raw]
Subject: Re: gcc 3.0.2/kernel details (-O issue)

> > optimization introduce are accepted. Removing the optimization may
> > break those expectations. Thus the kernel requires it.
>
> Huh? Those expectations are *bugs*.
>
> Kernel will not link without optimalizations because it *needs*
> inlining. Any else dependency is a *bug*.

Pavel, thanks for your reply. I already started to be afraid that
kernel code makes such strange expectations.
Inlining. Yes it explains a lot. It is the difference between -O
and -O2.
BTW the kernel compiles and links without inlining (with -O). It
just doesn't work ;-) Interestingly enough I have had the bad habit
of using -O as compile speed up factor for pretty long time while
working on 2.2.x ..

devik