gcc-3.0.1 and 2.4.7-ac1
Quoted 9 lines · Alan Cox
Quoted 5 lines
following is patch which was needed for compiling 2.4.7-ac1
on box equipped with 'gcc version 3.0.1 20010721 (Debian prerelease)'. As I did not see such complaint yet - here it is.
If you think that gcc is too lazy on inlining (I think so...),
tell me and I'll complain to gcc team instead of here.Fix gcc. We use extern inline to say 'must be inlined' and that was the semantic it used to have. Some of our inlines will not work if the compiler uninlines them.
Just adding '-finline-limit=150' fixes all of them (critical limit is somewhere between 120 and 150 on my kernel). As '-finline-limit' is documented as being 10000 by default, it looks like that someone changed default value to some really unreasonable value (probably 100).
Best regards,
Petr Vandrovec [email protected]
Quoted 4 lines · Petr Vandrovec
Just adding '-finline-limit=150' fixes all of them (critical limit is somewhere between 120 and 150 on my kernel). As '-finline-limit' is documented as being 10000 by default, it looks like that someone changed default value to some really unreasonable value (probably 100).
Yes. The higher value resulted in much compile-time lossage on heavily templated c++ code, as it proceeded to inline everything in sight.
While we may not use 100 in the final 3.0.1, it will definitely be much lower than 10000. More intelligent heuristics will have to wait for 3.1 or something.
r~
In article <[email protected]>,
Quoted 9 lines · Richard Henderson
Quoted 4 lines · Petr Vandrovec
Just adding '-finline-limit=150' fixes all of them (critical limit is somewhere between 120 and 150 on my kernel). As '-finline-limit' is documented as being 10000 by default, it looks like that someone changed default value to some really unreasonable value (probably 100).
Yes. The higher value resulted in much compile-time lossage on heavily templated c++ code, as it proceeded to inline everything in sight.
Having seen the discussion on the gcc lists, I can only heartily approve.
I did some repmacement of "extern" into "static" in 2.4.8-pre1, but I don't have gcc-3.0.x on my machines (too many headaches, too little time).
Linus
Quoted 3 lines · you
I did some repmacement of "extern" into "static" in 2.4.8-pre1, but I don't have gcc-3.0.x on my machines (too many headaches, too little time).
For gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-85), I had to change the "static"s in include/linux/parport_pc.h back to "extern"s to get drivers/parport/parport_pc.c to compile (as a module).
Cheers, Wayne
Quoted 1 line · Petr Vandrovec
Just adding '-finline-limit=150' fixes all of them
This is not a fix, this is a workaround which is suitable for some specific GCC release(s). The optimization decisions surrounding inlining are likely to change again, so this will break almost certainly in the future.
At least one GCC frontend has got a pragma called Always_Inline. This seems the way to go. For the C frontend, you would use a function attribute, of course.
Signature · 3 lines
Florian Weimer [email protected] University of Stuttgart http://cert.uni-stuttgart.de/ RUS-CERT +49-711-685-5973/fax +49-711-685-5898