On Dec 6, 2005, at 5:25 PM, Andreas Killaitis wrote:
Obviously I've been expressing me not very clear. I don't care for code size (well, at least not soo much), speed is what counts, and speed is what I get. I was just wondering why the code size has increased with the new gcc version. An increase of 1% or so I'd been ignoring, but 10% with the same compiler settings attracted my attendence.
gcc-help is a better place to ask such questions, but, for example, as we enhance the compiler to be able to inline more often, it isn't uncommon for the compiler to inline more often, and with that usually comes code size increases. If you're curious, you can compare the code generated by the compiler and see how it differs. Just give it -S.
Also, libstdc++ also can grow, and with growth in it, the application can grow, further, libgcc.a can grow, and with it, the application can grow. If you compare object file sizes as reported with size, then you can discount these sorts of issues.
So, the answer is, yes, it can be a regression, no, it might not be a regression, yes, it might be a feature, no, it might be a bug, the exact answer depends upon what exactly the circumstance is. If you want a vague answer, no, probably not a bug. If you want a good answer, we'd need a whole lot more information from you. Source codes, OS information, how the compiler was built and so on. I'd imagine that people would rather help you to help yourself figure out how it changed. For size *.o for all .o files, select the largest growth one, re-compile it with -save-temps, then, run diff old.s new.s, and then examine the resulting code to see how it changed. What is found there will suggest different ways to investigate further. If all else fails, one can binary search the compiler sources for the codegen changes in question and then ask specifically about that testcase and that compiler change. Tracking these things down can be a lot of work.
