On Tuesday, 29 July 2014 at 09:40:27 UTC, Marc Schütz wrote:
On Monday, 28 July 2014 at 15:52:23 UTC, John Colvin wrote:
On Monday, 28 July 2014 at 15:20:44 UTC, Ola Fosheim Grøstad
wrote:
If asserts were used as optimization constraints
all available code is fair game as optimisation constraints.
What you are asking for is a special case for `assert` such
that the optimiser is blind to it.
bool foo(int a)
{
//let's handwrite a simple assert
if(a >= 0)
{
exit(EXIT_FAILURE);
}
//and then do something.
return a < 0;
}
Of course the compiler is free to rewrite that as
bool foo(int a)
{
if(a >= 0)
{
exit(EXIT_FAILURE);
}
return true;
}
Why should the situation be different if I use the builtin
`assert` instead?
The problem is that in release mode, the asserts are removed.
It would then be a very big mistake to still take them into
account for optimizations, as if they were actually there.
To take your code:
assert(a >= 0);
return a < 0;
is equivalent to
assert(a >= 0);
return true;
but only in non-release mode. In release mode, this effectively
becomes
return a < 0;
which is _not_ equivalent to
return true;
I believe this is was Ola is protesting about, and I agree with
him. Such optimizations must only happen if the check stays.
you mean assert(a < 0) or assert(!(a >= 0)) right?
In a correct program (a necessary but not sufficient condition
for which is to not violate it's asserts) it is the same.
The program is in error if a > 0, whether the assert is compiled
in or not. Running in debug mode can simply mean "check my
assumptions".
