On Tuesday, 30 August 2022 at 11:48:26 UTC, Tejas wrote:
> How do `assert`s convert reproducible bugs into heisenbugs?

I pity the fool who uses -release.

On Tuesday, 30 August 2022 at 11:55:29 UTC, Adam D Ruppe wrote:
> On Tuesday, 30 August 2022 at 11:48:26 UTC, Tejas wrote:
>> How do `assert`s convert reproducible bugs into heisenbugs?
>
> I pity the fool who uses -release.

Is this true for asserts w/o side effects?

On Tuesday, 30 August 2022 at 11:55:29 UTC, Adam D Ruppe wrote:
> On Tuesday, 30 August 2022 at 11:48:26 UTC, Tejas wrote:
>> How do `assert`s convert reproducible bugs into heisenbugs?
>
> I pity the fool who uses -release.

Arguably the only thing -release should ever have done is removing debug statements. Nothing more, nothing less.

On Tuesday, 30 August 2022 at 12:07:52 UTC, wjoe wrote:
> Is this true for asserts w/o side effects?

Yes. -release should seriously *never* be used for a lot of reasons, but read this part of the spec:

https://dlang.org/spec/expression.html#assert_expressions

> 1. The first AssignExpression must evaluate to true. If it does not, an Assert Failure has occurred and the program enters an Invalid State.

Notice that it doesn't say "must evaluate to true if actually evaluated", it just says must evaluate to true. If it would have failed, even if not actually compiled in, the program has *still* entered the Invalid State.

> 8. Undefined Behavior: Once in an Invalid State the behavior of the continuing execution of the program is undefined.

> Implementation Defined: Whether the first AssertExpression is evaluated or not at runtime is typically set with a compiler switch.

This combines to mean an optimizer is free to assume the asserts were all true as it moves forward which can get pretty random if it was never actually tested.


I'm not sure if this is what Timon had in mind but it is its own thing to watch out for.

On Tuesday, 30 August 2022 at 12:17:36 UTC, Adam D Ruppe wrote:
> On Tuesday, 30 August 2022 at 12:07:52 UTC, wjoe wrote:
>> [...]
>
> Yes. -release should seriously *never* be used for a lot of reasons, but read this part of the spec:
>
> https://dlang.org/spec/expression.html#assert_expressions
>
>> [...]
>
> Notice that it doesn't say "must evaluate to true if actually evaluated", it just says must evaluate to true. If it would have failed, even if not actually compiled in, the program has *still* entered the Invalid State.
>
>> [...]
>
>> [...]
>
> This combines to mean an optimizer is free to assume the asserts were all true as it moves forward which can get pretty random if it was never actually tested.
>
>
> I'm not sure if this is what Timon had in mind but it is its own thing to watch out for.

That would make for a nice note in the spec :) Thanks for pointing this out.

On 8/29/2022 5:27 PM, Timon Gehr wrote:
> Clearly you should throw away your computer after a failed assert.

Absolutely. My basement is full of junked computers that dared to fail.


> Which is why asserts can introduce new _undefined behavior_?

DMD has a switch to insert a halt instruction upon assertion failures.

On 8/30/2022 4:55 AM, Adam D Ruppe wrote:
> I pity the fool who uses -release.

-release is for people who do speed benchmarks.

I speak from decades of experience.

On 8/26/2022 9:22 AM, Steven Schveighoffer wrote:
> I'm not asking for this, I'm saying without having some sort of "fail upon use" mechanism (be it a signal or an exception), it's just not effective at finding initialization problems. What it has going for it over 0 is that it's definitively a problem *if you happen to see it*. But you have to look for it, and finding the source can be long gone by the time you see it.

If you don't look for errors in the output, you are even less likely to find it with 0 initialization.

I've also written here that there are legitimate uses of NaN where quitting upon use is undesirable.

It's analogous to the "Replacement Char" in Unicode. We have experience with throwing an exception on seeing an invalid code point. It's the wrong answer. It's so wrong it's one of the motivators for Phobos version 2.

On 30/08/2022 10:23 PM, Guillaume Piolat wrote:
> Do you even need it for performance? Not sure, as just working on your vectorization, be it automatic or explicit, will leads to way better results. At least, that's my experience using the LLVM backend.

I've talked about this quite a bit with Bruce.

Our conclusion has been that explicit vectorization is usually the wrong path to take. It eats up developer time and provides very little benefit in majority of cases. If you feel like you need to reach for it, you probably haven't communicated to the backend enough information _to vectorize_.

One bit of information that both LLVM and GCC can take advantage of ``assert(arg1 !is arg2);`` such a simple assert! Yet very valuable aliasing information in it. I love asserts.