A few weeks ago the lto branch of gcc was merged to trunk, and was subsequently released in gcc 4.5. Why was I not notified?? What's wrong with you /prog/, sleeping on the job?
Also doesn't LTO support in almost all mainstream compilers sort of make the 'inline' keyword obsolete? Why would I bother inlining anything ever?
>>1
Now if GCC produced worthwhile/quality code, that might actually mean something. Unfortunately, I doubt this has changed.
Name:
Anonymous2009-11-10 22:23
The "inline" keyword has been more or less a joke for the past few years. There is one benefit: functions in C99 defined "static inline" don't generate warnings if they aren't used, but "static" functions do. There should usually be no difference in performance between the two.
Name:
Anonymous2009-11-10 22:27
Sure, it's kinda cool, but you could already do the same thing with -combine -fwhole-program (with a few caveats). Only funrolling ricers cared then and only they care now.
Yes, declaring functions inline is just as useless as declaring variables register.
If a header named in a #include directive is not found, the compiler exits immediately.
Now that's a significant change that will save people some time.
Name:
Anonymous2009-11-11 0:09
>>5 Now if GCC produced worthwhile/quality code, that might actually mean something. Unfortunately, I doubt this has changed.
The point is more that most major compilers support this now, so I can write a library without manually inlining shit and not worry about the performance issues on any major platform. I can write accessors/mutators for C structs where the definition is actually hidden in the C file, and there's no performance penalty. I don't have to worry about the visibility of anything anymore; header files are back to the way they should be, just public function listings and that's it. No more hacks for performance just to cater to those who used GCC.
>>7 you could already do the same thing with -combine -fwhole-program (with a few caveats)
Those caveats are pretty important. You certainly couldn't compile anything large with this method; the memory requirements were too high. -whopr solves this. It was also extremely slow, and you couldn't do incremental builds this way.
Cool story, finally the last horse finishes the race. I'm hardly impressed.
I can write a library without manually inlining shit and not worry about the performance issues on any major platform
This is what people who buy the whole "intrinsics" thing actually believe, amongst other ludicrous stuff. This whole LTO thing means a slight step down on the scale of suckiness, but automatic code generation (specially GCC's) is still a very bad joke.
BTW GCC always had a bad tendency to ignore the inline keyword anyway, so if you're serious and you know what are you doing (protip: you don't) you have to use either macros or some sort of force_inline crap.
All in all, I'm happy about this thread because 'L' and 'T' have kerning in the font I'm using and the characters overlap quite a bit. I had my doubts it was working (like GCC), but this puts them to rest (unlike GCC).