Hi,

I discovered a bug in DMD whereby, during optimisation, the loop index variable is removed, despite being used afterwards. I reproduced the bug in this issue.

Using run.dlang.io, I tried to find a regression, but all supported DMD versions (2.060 and newer) are printing the same incorrect output (Exception: i = 0; n = 1). My experiment can be found here. This seems to be a backend issue, as both LDC and LDC-beta are working fine.

However, when analysing the CI outputs from the PR which made me come across this bug, I noticed that all 3 of DMD, LDC and GDC are failing the same test, which I've also been able to reproduce myself:

• LDC: https://cirrus-ci.com/task/6291197929979904?logs=test_druntime#L1449
• DMD: https://cirrus-ci.com/task/5728247976558592?logs=test_druntime#L1390
• GDC: https://cirrus-ci.com/task/4883823046426624?logs=test_druntime#L1411

The failure of this test is caused by the issue I mentioned above and the code with which I reproduced the bug is based on it.

I am unsure what to make of this, since the logs seem to contradict my experiment with LDC. Has anyone else encountered this? How did you proceed?

Thanks,
Teodor

On Saturday, 9 October 2021 at 21:09:19 UTC, Teodor Dutu wrote:

Just to clarify, those are all DMD. The difference in those pipelines is who built DMD.

On Saturday, 9 October 2021 at 21:09:19 UTC, Teodor Dutu wrote:

It is about optimization, it's about loop so a good candidate to check is dmd.backend.gloop.d.

you have several optim functions there:

• elimbasivs(ref loop l)
• elimfrivivs(ref loop l)
• elimopeqs(ref loop l)
• elimspec(ref loop l)

enable the logging functions and recompile dmd.

It appears that the bug occurs in elimbasivs, for example if you only enable this printf

then dmd, during compilation of the test case, outputs

this is confirmed because if you recompile DMD with an early return added in elimbasivs then the program does not contain the bug.

Now to fix the bug, it's another piece of cake. At first glance I'd say that there's a missing condition to continue (e.g skip the optim) in the code before line 2966.

(I've used a slightly modifed test case btw, 1. to bisect using digger more easily, 2. to be sure that the message was not for another loop as i is a common name)

On Saturday, 9 October 2021 at 22:05:15 UTC, Iain Buclaw wrote:

Oh I see. Thanks for pointing it out.

On Sunday, 10 October 2021 at 02:41:55 UTC, Basile.B wrote:

Yup, I was also dissecting gloop last night