Re: Lilypond miscompiled on Fedora 17

[David Kastrup]

Pavel Roskin <address@hidden> writes:

> Quoting David Kastrup <address@hidden>:
>
>> Pavel Roskin <address@hidden> writes:
>>
>>> Quoting David Kastrup <address@hidden>:
>>>
>>>> That would have been my most likely guess.  Probably the "min" function
>>>> call.
>>>
>>> You are absolultely right!  I was able to work around the gcc bug by
>>> making a separate function for Moment comparison and using it instead
>>> of min():
>>>
>>> Moment
>>> min_moment (Moment m1, Moment m2)
>>> {
>>>   return min (m1, m2);
>>> }
>>
>> What happens if you declare this
>>
>> (Moment const &m1, Moment const &m2)
>
> The bug is present ("moving back in time")
>
> I tried all combinations:
>
> (Moment m1, Moment m2) - OK
> (Moment m1, Moment const &m2) - OK
> (Moment const &m1, Moment m2) - Bad
> (Moment const &m1, Moment const &m2) - Bad

It would seem like a lifetime problem: maybe GCC gives up on the
existence of the first Moment underlying the reference parameter once it
has done the comparison.  I don't think that's a valid optimization.
And the generated code certainly makes no sense.

> Maybe the produced code is not interested in the result because the
> original value of next is infinite and gcc think that the comparison
> only happens once per call?  But then it would not call the compare
> method.
>
> Let me try to find the exact optimization flag responsible for the
> breakage.

-- 
David Kastrup