Clarifying attribute-const

[Szabolcs Nagy]

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