This is the mail archive of the
mailing list for the GCC project.
Re: Clarifying attribute-const
- From: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- To: Eric Botcazou <ebotcazou at adacore dot com>, Alexander Monakov <amonakov at ispras dot ru>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Tue, 29 Sep 2015 10:31:00 +0100
- Subject: Re: Clarifying attribute-const
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot LNX dot 2 dot 20 dot 1509251933001 dot 23590 at monopod dot intra dot ispras dot ru> <1449338 dot uM7p4ILj71 at polaris>
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
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.