This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Early inlining with early optimization and passmanagerization of the inliner
Jan Hubicka wrote:
What happens is that we are now able to inline:
operator<< (D.30480_3, endl);
and propagate the hook operand (endl) into direct call and subsequently
inline endl which was originally resulting in library call. (Hope that
Paolo will like this trick:)
Yes ;)
and since it iscoming from alien non-mudflapized code, we get error on
it. I believe either mudflap needs to deal with such an internals of
libstdc++ same way as it does with stdin and others, or libstdc++ must
limit inlining of this kind.
Sorry, Honza, but I can provide only very limited feedback, right now
(to be sure, I'm adding Frank explicitely in CC), hope I can do better
in one day or so. Anyway, as far as the library is concerned, I think
endl is straightforward, I'm reproducing it here for the convenience of
the list:
template<typename _CharT, typename _Traits>
inline basic_ostream<_CharT, _Traits>&
endl(basic_ostream<_CharT, _Traits>& __os)
{ return flush(__os.put(__os.widen('\n'))); }
in short, we have an *absolutely* direct implementation of C++03
27.6.2.7/1. I don't think we should artificially limit inlining, no real
work is happening, everything is delegated to widen, put, and flush.
Since our implementation apparently does nothing outside the letter of
the standard, either we have a bug somewhere in the library (no idea
where?!?) or mudflap should be adjusted somehow to cope with this type
of conforming code. This is my first impression, anyway.
Thanks,
Paolo.