------- Comment #2 from vz-gcc at zeitlins dot org 2010-03-31 22:04 -------
I'm sorry but is this really all you have to say about this? Granted, VS does
follow the same rule but the size of object files produced by it was twice
less than that of object files produced by gcc _before_ this change and it
would seem to me that keeping the size of object files reasonable should have
higher precedence than implementing the same behaviour that the Microsoft
compiler implements. I don't know how does VS manage to avoid this exponential
growth of object files but it demonstrably does while gcc does not.
Once again, it's a serious problem for many developers that the size of object
files is now 500MB instead of 50MB. Linking a module from 500MB of object
files requires a lot of RAM and takes a long time. And, to top it all, the
change resulting in this regression (because from the point of view of any gcc
user this is how it will look) doesn't bring any tangible benefits --
compatibility with VS notwithstanding. While generating inline methods in
DLL might be desirable (although the patch also only speaks about ARM ABI
so it doesn't seem like this is really _required_ under x86/x64), it seems
strange to completely disregard practical consequences of this lofty idea.
Please reconsider your decision, IMO at least an option restoring the old
behaviour (with a prominent mention in release notes/changelog) is badly
needed.
P.S. Personally, I'd also love to understand why exactly was this change
considered so desirable at all. But this is just out of my personal
curiosity. What really matters is that plenty of people will be simply
unable to compile projects which they had no trouble compiling with
gcc 4.4. This will result in massive amounts of pain all around.
--
vz-gcc at zeitlins dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |UNCONFIRMED
Resolution|WONTFIX |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601
