On Mar 15, 2005, at 10:32 AM, Zack Weinberg wrote:
Dale Johannesen <[EMAIL PROTECTED]> writes:
Consider the following:
static inline int a() __attribute((always_inline)); static inline int b() __attribute((always_inline));
static inline int b() { a(); } static inline int a() { } int c() { b(); }
This compiles fine at -O2. At -O0 we get the baffling error sorry, unimplemented: inlining failed in call to 'a': function not considered for inlining
It seems undesirable for -O options to affect which programs will compile.
Agreed. Perhaps we should run the inliner at -O0 if we see always_inline attributes, just for those functions?
We do; the problem is that it makes only 1 pass, so tries to inline
"a" before it has seen the body of "a". If you interchange the definitions
of "a" and "b" the inlining is done at all optimization levels.
I think this could be done without turning on -funit-at-a-time, even (the inliner does work in -O2 -fno-unit-at-a-time mode, after all).
That gets the same failure on this example.
The problem is not the effect on compile speed (IIRC Honza had it down to negligible) but the way it breaks assembly hacks such as crtstuff.c. (I would love to see a solution to that.)
I wasn't aware of this problem, can you give me a pointer?
