Pavel Roskin <pro...@gnu.org> writes:
> Quoting David Kastrup <d...@gnu.org>:
>
>> Pavel Roskin <pro...@gnu.org> writes:
>>
>>> Quoting David Kastrup <d...@gnu.org>:
>>>
>>>> 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
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
