On 25/09/15 21:16, Eric Botcazou wrote:
First, a belated follow-up to https://gcc.gnu.org/PR66512 . The bug is
asking why attribute-const appears to have a weaker effect in C++, compared
to C. The answer in that bug is that GCC assumes that attribute-const
function can terminate by throwing an exception.
FWIW there is an equivalent semantics in Ada: the "const" functions can throw
and the language explicitly allows them to be CSEd in this case, etc.
i think a throwing interface that may be moved around
by the compiler makes reasoning about exception safety
hard.. (i.e. the spec cannot be hand-wavy about the
allowed optimizations).
i guess the inconsistency stems from c++ making extern
c apis throw by default (causing some amount of misery:
in c one cannot throw nor declare something nothrow,
so c api is pessimized in c++).
That doesn't actually seem reasonable. Consider that C counterpart to
throwing is longjmp; it seems to me that GCC should behave consistently:
either assume that attribute-const may both longjmp and throw (I guess
nobody wants that), or that it may not longjmp nor throw. Intuitively, if
"const" means "free of side effects so that calls can be moved
speculatively or duplicated", then non-local control flow transfer via
throwing should be disallowed as well.
This would pessimize a lot languages where exceptions are pervasive.
i think if the language tends to allow catching invalid
input to pure computation as an exception (e.g. division
by zero) then throwing is preferred.
if bad input is treated as undefined behavior then
nothrow is preferred.
In any case, it would be nice the intended compiler behavior could be
explicitely stated in the manual.
Agreed.
+1
