> I think that's less clear as the transform basically duplicates the call
> on both branches and removes the one that is not necessary.
Yes, IMO that one is allowed under the as-if rule.
> I think GCC does both though (if it throws only externally, for
> internally throwing ones the transforms w
On Fri, Oct 2, 2015 at 1:40 AM, Geert Bosch wrote:
>
>> On Oct 1, 2015, at 11:34 AM, Alexander Monakov wrote:
>>
>> Can you expand on the "etc." a bit, i.e., may the compiler ...
>>
>> - move a call to a "const" function above a conditional branch,
>>causing a conditional throw to happen unc
> On Oct 1, 2015, at 11:34 AM, Alexander Monakov wrote:
>
> Can you expand on the "etc." a bit, i.e., may the compiler ...
>
> - move a call to a "const" function above a conditional branch,
>causing a conditional throw to happen unconditionally?
No, calls may only be omitted, not moved.
> Can you expand on the "etc." a bit, i.e., may the compiler ...
>
> - move a call to a "const" function above a conditional branch,
> causing a conditional throw to happen unconditionally?
>
> - move a call to a "const" function below a conditional branch,
> causing an unconditional
On Fri, 25 Sep 2015, 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
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 ex
> 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 equival
Hello,
I'd like to ask for community input regarding __attribute__((const)) (and
"pure", where applicable). My main goal is to clarify unclear cases and
improve existing documentation, if possible.
First, a belated follow-up to https://gcc.gnu.org/PR66512 . The bug is asking
why attribute-const
