One reason why "keep it even if unreferenced" may be the default even when optimizations are enabled is that these tools (binutils, gcc) are primarily used in environments that have far more capabilities, and couldn't care less if a few extra kilobytes are present in the image. If you work in Linux with dynamic libraries, which is the common case, it's easy to use dlopen to resolve symbols at runtime that are not referenced at link time, and invoke "unreachable" code that way.
The simplest perspective is "user provided it, so leave it alone". The user's supposed to know best; I don't want the software to be overly helpful unless I explicitly give it permission. Peter On Wed, Jun 23, 2010 at 10:07 AM, JMGross <[email protected]> wrote: > > >> Since 1) is the default, binary files may be unnecessary large by > >> default. > > > Yes. > > And that's what I don't understand: why is the special case (keep it > even if not referenced and therefore unreachable) is the default and the > default case (keep only what's used) requires extra treatment. > Anyway, now that I know that it is so, I can live with it. > > So while I'm sorry alarming you unnecessarily, I'm quite happy that > I did, as I gained some valuable insights from this discussion. > And maybe others did too. > > After all this is a compiler users mailing list and not a > compiler programmers list. :) > > JMGross > > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > Mspgcc-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/mspgcc-users >
