This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GCC 3.3 release criteria


At 11:13 25.02.2003, Richard Earnshaw wrote:

> > For functions marked with the "inline" keyword, as opposed to C++
> > inline class methods, can anyone give me a reason why we don't treat
> > the inline keyword as an always_inline attribute?
>
> I wholeheartedly second that. If I write "inline" in C I expect that to happen
> as soon as the optimizer is turned on. If there is room for even more
> inlining after that, fine.
> So, for C "inline" should be mapped to "always_inline".


I think the inline keyword should be treated exactly in the same terms as
the register keyword.  That is, as a hint to the compiler.  As time goes
by the inline keyword will become increasingly meaningless, since the
compiler will be able to do a better job.  Forcing the compiler to respect
inline regardless of the consequences is a mistake.

If you want to change the inline behaviour, you need first to deprecate with a warning the currently documented behaviour (in 3.2/3.3) and then change inline to a hint in 3.4.


But the current behaviour violates the documentation (where size isn't a criteria for non-inlining) and thus is a bug. Note that even -Winline doesn't work as documented, it doesn't give a reason.

Franz.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]