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

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

Quoted 1 line

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.

Quoted 1 line

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

Well they do -- i just found out.

Quoted 8 lines

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.

Quoted 1 line

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.

Quoted 5 lines · Andi Kleen

Quoted 1 line

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)

Quoted 3 lines

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)).