[PATCH] Remove NOTHROW from {,v}{,f}{print,scan}f, {,f}printf_unlocked and __{,v}{,f}printf_chk builtins

Mark Mitchell mark@codesourcery.com
Tue Sep 4 17:07:00 GMT 2007


Jakub Jelinek wrote:
> On Tue, Sep 04, 2007 at 09:30:09AM -0700, Mark Mitchell wrote:
>>> In glibc the following functions aren't throw(), because they are
>>> possible cancellation points (when a thread doing say a write within
>>> fprintf is cancelled, we need forced unwinding to work).
>> Can we conditionalize this in some way?  On a system without threads, or
>> if the user is explicitly writing single-threaded code, these functions
>> are in fact nothrow.  On an embedded C++ system, we don't want to pay
>> the overhead for thinking that every call to these functions might throw
>> an exception.
> 
> Conditionalizing on what?  Requiring to use a new switch for all
> compilations that might be used in threaded programs would be a nightmare.

There's always the opposite option: -fno-threads.  That might be on by
default for some bare-metal configurations, and could be used on
GNU/Linux systems for people who want that.

> What we could do is when we see a prototype, update the NOTHROW state
> not only of the DECL_ANTICIPATED builtin, but also its __builtin_* variant.

That seems like it might be an improvement.  I guess the problem is if
__builtin_printf decides to go call "puts", and "puts" is declared to
throw exceptions, even though "printf" is not.  So, presumably we don't
set the bit on the builtin because we can't be sure it's safe.

> BTW, several other functions are already not NOTHROW for years:
> http://gcc.gnu.org/ml/gcc-patches/2004-09/msg02897.html
> it is just that the NOTHROW for the *printf has been not explicit
> in builtins.def and therefore missed in the above patch.

Yes, I understand.  It might mean that we should do your patch, just to
get everything into a consistent state -- but we still have a
longer-term problem: how to avoid pessimizing code on all systems
because, on some systems, thread cancellation is implemented as an
exception.  I'd like to at least have a strategy here, unless it's the
case that the builtins being nothrow doesn't offer us any advantage.

Thanks,

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713



More information about the Gcc-patches mailing list