fyi: gcc33-hammer crashes when compiling kvm emulate.c

fyi: gcc33-hammer crashes when compiling kvm emulate.c

[Andi Kleen]

Hi,

While doing a test run with the minimum supported compiler
I found:

An old gcc 3.3-hammer segfaults when compiling the current KVM
emulate.c (or rather in x86_emulate_insns) on x86-64.

The compiler goes into an endless recursion in validate_rtx and then
eventually overflows the stack and dies.

I minimized a test case, but didn't find a workaround
(minimized test case http://halobates.de/emulate-min.i)

My guess it's related to some of the inline assembler uses.

This might be an excuse to bump the minimum compiler version again.

-andi

-- 
ak@linux.intel.com -- Speaking for myself only.

Re: fyi: gcc33-hammer crashes when compiling kvm emulate.c

[H. Peter Anvin]

On 10/26/2010 05:38 AM, Andi Kleen wrote:
> Hi,
> 
> While doing a test run with the minimum supported compiler
> I found:
> 
> An old gcc 3.3-hammer segfaults when compiling the current KVM
> emulate.c (or rather in x86_emulate_insns) on x86-64.
> 
> The compiler goes into an endless recursion in validate_rtx and then
> eventually overflows the stack and dies.
> 
> I minimized a test case, but didn't find a workaround
> (minimized test case http://halobates.de/emulate-min.i)
> 
> My guess it's related to some of the inline assembler uses.
> 
> This might be an excuse to bump the minimum compiler version again.
> 

We have said 3.4 minimum for x86 for a long time now, and have an RFC
out to bump to 4.1.  Unfortunately there isn't a good repo of
arch-specific version requirements in the kernel source code; in fact, I
just talked to Tony Luck yesterday about the need for that.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Re: fyi: gcc33-hammer crashes when compiling kvm emulate.c

[Andi Kleen]

> We have said 3.4 minimum for x86 for a long time now, and have an RFC

Ok makes sense. I thought it was still at 3.3. I should retire
this 3.3 fossil anyways, it's really only for old compat testing.

I don't remember seeing a warning -- aren't there supposed to be warnings
for unsupported compilers?

-Andi
-- 
ak@linux.intel.com -- Speaking for myself only.

Re: fyi: gcc33-hammer crashes when compiling kvm emulate.c

[H. Peter Anvin]

On 10/26/2010 09:37 AM, Andi Kleen wrote:
>> We have said 3.4 minimum for x86 for a long time now, and have an RFC
> 
> Ok makes sense. I thought it was still at 3.3. I should retire
> this 3.3 fossil anyways, it's really only for old compat testing.
> 
> I don't remember seeing a warning -- aren't there supposed to be warnings
> for unsupported compilers?
> 

Not unless they are actively known to break.  People get huffy about it
because even if it is known to have problems it doesn't break *their*
particular configuration.  I'm getting to be of the opinion that people
who compile modern kernels with ancient compilers and expect it to work
are suffering from some particular kind of insanity -- it's nothing the
distros do.  The only exception are embedded people who compile with the
latest 3.4 gcc; they have explained they do so because newer gccs have
too many dependencies (the actual compiler, not the generated code) and
for speed.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Re: fyi: gcc33-hammer crashes when compiling kvm emulate.c

[Andi Kleen]

> Not unless they are actively known to break.  People get huffy about it

Well they do -- i just found out.

> because even if it is known to have problems it doesn't break *their*
> particular configuration.  I'm getting to be of the opinion that people
> who compile modern kernels with ancient compilers and expect it to work
> are suffering from some particular kind of insanity -- it's nothing the
> distros do.  The only exception are embedded people who compile with the
> latest 3.4 gcc; they have explained they do so because newer gccs have
> too many dependencies (the actual compiler, not the generated code) and
> for speed.

At least in the old days the main reason for gcc 3 was build speed.
AKPM and some others used to be fond of that.

3.x is apparently much faster than 4.x

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only.

Re: fyi: gcc33-hammer crashes when compiling kvm emulate.c

[H. Peter Anvin]

On 10/26/2010 10:01 AM, Andi Kleen wrote:
>> Not unless they are actively known to break.  People get huffy about it
> 
> Well they do -- i just found out.

Sounds like a good reason to put in a warning or error.

>> because even if it is known to have problems it doesn't break *their*
>> particular configuration.  I'm getting to be of the opinion that people
>> who compile modern kernels with ancient compilers and expect it to work
>> are suffering from some particular kind of insanity -- it's nothing the
>> distros do.  The only exception are embedded people who compile with the
>> latest 3.4 gcc; they have explained they do so because newer gccs have
>> too many dependencies (the actual compiler, not the generated code) and
>> for speed.
> 
> At least in the old days the main reason for gcc 3 was build speed.
> AKPM and some others used to be fond of that.
> 
> 3.x is apparently much faster than 4.x

That is an issue too, as 3.x does a lot fewer optimizations than 4.x.

	-hpa

Re: fyi: gcc33-hammer crashes when compiling kvm emulate.c

[Andi Kleen]

> That is an issue too, as 3.x does a lot fewer optimizations than 4.x.

Well to be fair the default -Os build disables most of the fancy stuff
(and the resulting code is often terrible) 

I guess it doesn't matter too much, at least not with the 
CONFIG_CC_OPTIMIZE_SIZE default.

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only.

Re: fyi: gcc33-hammer crashes when compiling kvm emulate.c

[H. Peter Anvin]

On 10/26/2010 01:27 PM, Andi Kleen wrote:
>> That is an issue too, as 3.x does a lot fewer optimizations than 4.x.
> 
> Well to be fair the default -Os build disables most of the fancy stuff
> (and the resulting code is often terrible) 
> 
> I guess it doesn't matter too much, at least not with the 
> CONFIG_CC_OPTIMIZE_SIZE default.
> 

Yes, it would be nice to have a setting which is "optimize but don't
bloat excessively."

	-hpa

Re: fyi: gcc33-hammer crashes when compiling kvm emulate.c

[Avi Kivity]

  On 10/26/2010 10:37 PM, H. Peter Anvin wrote:
> On 10/26/2010 01:27 PM, Andi Kleen wrote:
> >>  That is an issue too, as 3.x does a lot fewer optimizations than 4.x.
> >
> >  Well to be fair the default -Os build disables most of the fancy stuff
> >  (and the resulting code is often terrible)
> >
> >  I guess it doesn't matter too much, at least not with the
> >  CONFIG_CC_OPTIMIZE_SIZE default.
> >
>
> Yes, it would be nice to have a setting which is "optimize but don't
> bloat excessively."
>

Would be good to have __fastpath and __slowpath function attributes.

__fastpath would always be optimized for speed, __slowpath always for 
size, and everything else would use the default (determined by 
CONFIG_CC_OPTIMIZE_FOR_SIZE).

Looks like gcc has support for this, with __attribute__((hot)), 
__attribute__((cold)), and __attribute__((optimize)).

-- 
error compiling committee.c: too many arguments to function

Re: fyi: gcc33-hammer crashes when compiling kvm emulate.c

[Andi Kleen]

> Would be good to have __fastpath and __slowpath function attributes.
> 
> __fastpath would always be optimized for speed, __slowpath always
> for size, and everything else would use the default (determined by
> CONFIG_CC_OPTIMIZE_FOR_SIZE).

> 
> Looks like gcc has support for this, with __attribute__((hot)),
> __attribute__((cold)), and __attribute__((optimize)).

I had patches for a long time, but last time I tried it didn't help too much.
(basically make __init hot/cold and mark a few functions) 
Similar things can be also done with unrolling. The Optimize attribute
is currently quite broken in gcc and shouldn't be used.

The main reason I didn't post them is that I didn't want another
likely/unlikely with people sprinkling them randomly and never
looking at profile logs. I am to blame for likely()/unlikely() originally
 and it got abused so much that I regretted it alot. So I don't
think just exposing that is a good idea right now.

I think there are some other ways to do that better, but they
will need more work.

-Andi
-- 
ak@linux.intel.com -- Speaking for myself only.