Yay for more comments like this one.

Don 2010-12-06 11:53:27 PST
--
Bearophile -- That's an interesting [automatic fuzzy testing]link. Currently,
DMD back-end bugs are
being found at the rate of about 3 per year. So yes, fuzzy testing of DMC could
probably flush out some backend bugs a bit faster.
-------------------

Here's what's happening. First, in this code:

    for (int i = 0; i < 10; i++) {
        foo(i * 5 - 6);
    }
it sees that i and 10 are always >=0, so the signed comparison "i < 10" is
replaced with an unsigned one. (This happens in the backend in constprop() ).
Then, while dealing with loop invariants, it rewrites the loop into:

for (int _i2 = -6; _i2 < 10*5 - 6; _i2 += 5)
{
  foo(_i2);
}

Fine. Except that it had changed the comparison into an unsigned one!
Particularly interesting is the case where the call is foo(i*5-50);
Then, the loop becomes:
for (int _i2 = -50; _i2 < 0; _i2 += 5)

Since an unsigned value is NEVER less than zero, it just drops the loop completely!

Nasty.
--
http://d.puremagic.com/issues/show_bug.cgi?id=5294

On 07.12.2010 06:57, %u wrote:
> Yay for more comments like this one.
>
> Don 2010-12-06 11:53:27 PST
> --
> Bearophile -- That's an interesting [automatic fuzzy testing]link. Currently,
> DMD back-end bugs are
> being found at the rate of about 3 per year. So yes, fuzzy testing of DMC could
> probably flush out some backend bugs a bit faster.
> -------------------
>
> Here's what's happening. First, in this code:
>
>      for (int i = 0; i<  10; i++) {
>          foo(i * 5 - 6);
>      }
> it sees that i and 10 are always>=0, so the signed comparison "i<  10" is
> replaced with an unsigned one. (This happens in the backend in constprop() ).
> Then, while dealing with loop invariants, it rewrites the loop into:
>
> for (int _i2 = -6; _i2<  10*5 - 6; _i2 += 5)
> {
>    foo(_i2);
> }
>
> Fine. Except that it had changed the comparison into an unsigned one!
> Particularly interesting is the case where the call is foo(i*5-50);
> Then, the loop becomes:
> for (int _i2 = -50; _i2<  0; _i2 += 5)
>
> Since an unsigned value is NEVER less than zero, it just drops the loop
> completely!
>
> Nasty.
> --
> http://d.puremagic.com/issues/show_bug.cgi?id=5294

What i think is more disturbing is Walters response:

> I'm not sure how to fix that one yet, but it has been there for 25 years
> now, so I am not sure it is urgent!

I often ran into this strange behaviour when using -O optimization without knowing where it came from and it is so disturbing when i think of people newly getting interested in D making the experience when trying to compare it with C/C++ and then finding out the optimization makes strange things. I think out of a image perspective such bugs must be high priority, ESPECIALLY if it lies there for 25years already.

Regards,
Stephan

Stephan wrote:
> I often ran into this strange behaviour when using -O optimization without knowing where it came from and it is so disturbing when i think of people newly getting interested in D making the experience when trying to compare it with C/C++ and then finding out the optimization makes strange things. I think out of a image perspective such bugs must be high priority, ESPECIALLY if it lies there for 25years already.

I've had probably 10,000 bug reports over the years and this has never appeared as one before now. Thank you for reporting it.

On 07.12.2010 11:52, Walter Bright wrote:
> Stephan wrote:
>> I often ran into this strange behaviour when using -O optimization
>> without knowing where it came from and it is so disturbing when i
>> think of people newly getting interested in D making the experience
>> when trying to compare it with C/C++ and then finding out the
>> optimization makes strange things. I think out of a image perspective
>> such bugs must be high priority, ESPECIALLY if it lies there for
>> 25years already.
>
> I've had probably 10,000 bug reports over the years and this has never
> appeared as one before now. Thank you for reporting it.

Possibly because it was so hard to nail down and reproduce in a simple testcase. Slightly changing the code made it disappear every now and then again.

Stephan wrote:
> On 07.12.2010 11:52, Walter Bright wrote:
>> Stephan wrote:
>>> I often ran into this strange behaviour when using -O optimization
>>> without knowing where it came from and it is so disturbing when i
>>> think of people newly getting interested in D making the experience
>>> when trying to compare it with C/C++ and then finding out the
>>> optimization makes strange things. I think out of a image perspective
>>> such bugs must be high priority, ESPECIALLY if it lies there for
>>> 25years already.
>>
>> I've had probably 10,000 bug reports over the years and this has never
>> appeared as one before now. Thank you for reporting it.
> 
> Possibly because it was so hard to nail down and reproduce in a simple testcase. Slightly changing the code made it disappear every now and then again.

I do appreciate the small test case, too.

Stephan wrote:
> On 07.12.2010 06:57, %u wrote:
>> Yay for more comments like this one.
>>
>> Don 2010-12-06 11:53:27 PST
>> -- 
>> Bearophile -- That's an interesting [automatic fuzzy testing]link. Currently,
>> DMD back-end bugs are
>> being found at the rate of about 3 per year. So yes, fuzzy testing of DMC could
>> probably flush out some backend bugs a bit faster.
>> -------------------
>>
>> Here's what's happening. First, in this code:
>>
>>      for (int i = 0; i<  10; i++) {
>>          foo(i * 5 - 6);
>>      }
>> it sees that i and 10 are always>=0, so the signed comparison "i<  10" is
>> replaced with an unsigned one. (This happens in the backend in constprop() ).
>> Then, while dealing with loop invariants, it rewrites the loop into:
>>
>> for (int _i2 = -6; _i2<  10*5 - 6; _i2 += 5)
>> {
>>    foo(_i2);
>> }
>>
>> Fine. Except that it had changed the comparison into an unsigned one!
>> Particularly interesting is the case where the call is foo(i*5-50);
>> Then, the loop becomes:
>> for (int _i2 = -50; _i2<  0; _i2 += 5)
>>
>> Since an unsigned value is NEVER less than zero, it just drops the loop
>> completely!
>>
>> Nasty.
>> -- 
>> http://d.puremagic.com/issues/show_bug.cgi?id=5294
> 
> What i think is more disturbing is Walters response:
> 
>> I'm not sure how to fix that one yet, but it has been there for 25 years
>> now, so I am not sure it is urgent!
> 
> I often ran into this strange behaviour when using -O optimization without knowing where it came from and it is so disturbing when i think of people newly getting interested in D making the experience when trying to compare it with C/C++ and then finding out the optimization makes strange things. I think out of a image perspective such bugs must be high priority, ESPECIALLY if it lies there for 25years already.

Yes, such bugs are given maximum priority. The only question is, should we delay the next release until this one is fixed?

BTW, I said there are about 3 of these bugs per year.
Here's the ones from the past two years, together with the time elapsed between reporting and fix:
2697 [6 months]
3521 [3 weeks]
3558 [10 weeks]
3633 [1 week]
3736 [2 weeks]
4443 [3 weeks]

Other wrong-code bugs were in the front end, or the glue layer. True back-end bugs are very rare, and are always very serious (largely because when you encounter them, they are almost impossible to recognize).

On 07.12.2010 12:49, Walter Bright wrote:
> Stephan wrote:
>> On 07.12.2010 11:52, Walter Bright wrote:
>>> Stephan wrote:
>>>> I often ran into this strange behaviour when using -O optimization
>>>> without knowing where it came from and it is so disturbing when i
>>>> think of people newly getting interested in D making the experience
>>>> when trying to compare it with C/C++ and then finding out the
>>>> optimization makes strange things. I think out of a image perspective
>>>> such bugs must be high priority, ESPECIALLY if it lies there for
>>>> 25years already.
>>>
>>> I've had probably 10,000 bug reports over the years and this has never
>>> appeared as one before now. Thank you for reporting it.
>>
>> Possibly because it was so hard to nail down and reproduce in a simple
>> testcase. Slightly changing the code made it disappear every now and
>> then again.
>
> I do appreciate the small test case, too.

Its fixed! Thanks a lot! That will hopefully make D perform better in a benchmark vs. C that i make.