This is the mail archive of the
mailing list for the GCC project.
[Bug middle-end/24947] -Os should maximize inlining --param values.
- From: "msharov at hotmail dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 21 Nov 2005 16:25:42 -0000
- Subject: [Bug middle-end/24947] -Os should maximize inlining --param values.
- References: <firstname.lastname@example.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #9 from msharov at hotmail dot com 2005-11-21 16:25 -------
(In reply to comment #8)
> Depends on which C++ developers and if they have really thought about all their
> uses of inline (most have not even though they say they want functions declared
> as inline to be inlined)?
Since when does developer ignorance require workarounds in the compiler? If I
"don't really think" about how I write my iterator loops, I fully deserve to
have buffer overflows (although, if the compiler can be smart enough to
generate a warning, that would be great!). Likewise, if I declare all my
functions inline, then I deserve to get an incredibly bloated compiled
executable. That's the spirit of C - do what I say, not what you think is good
for me. If I wanted the latter, I'd be using Java.
> Also there are examples of where respecting inline will just cause the compiler
> to use so much memory/compile time is not funny. An example is PR 8361.
Looking at that gave me the shivers :) Whoever wrote that code definitely
didn't think about what should be inlined and what shouldn't be. They have
inline functions a hundred lines long! I would say they got exactly what they
deserved - slow compilation and a lot of bloat. If you write bad code, the bad
code should be fixed, not the compiler, which is even in this case doing just
what it is told to do.