Re: Lilypond miscompiled on Fedora 17

[David Kastrup]

Pavel Roskin <address@hidden> writes:

> Quoting David Kastrup <address@hidden>:
>
>> Now we just need to figure out which of the gazillion optimization
>> options (listed in the assembly file) from O2 as compared to O1 makes
>> the compilation go bad, and then we can add appropriate compiler
>> options.
>>
>> We had to do this sort of $&!# already for gcc 4.6, so our configure
>> tests are straightforward to fix once we know the option to switch off.
>
> That's it:
>
> `-ftree-vrp'
>       Perform Value Range Propagation on trees.  This is similar to the
>       constant propagation pass, but instead of values, ranges of values
>       are propagated.  This allows the optimizers to remove unnecessary
>       range checks like array bound checks and null pointer checks.
>       This is enabled by default at `-O2' and higher.  Null pointer check
>       elimination is only done if `-fdelete-null-pointer-checks' is
>       enabled.
>
> -fno-tree-vrp disables the optimization.

That's _very_ ugh.  I had the suspicion that this was related to the
lifetime of temporaries (though that does not make all too much sense),
but this is an option that should not be related.  It _is_ likely
related to lifetime (or changing to references should not make a
difference), but not intentionally so.

> Here's the preliminary patch.  I'll submit it as an issue if you don't
> mind.

You mean as a GCC issue?  That is very likely a P1 regression (the worst
possible), and likely with a quite higher impact than the last GCC bug
we were able to track down, at least in C++.

> Add -fno-tree-vrp to CXXFLAGS for gcc 4.7.0
>
> That optimization breaks min() call in simultaneous-music-iterator.cc
> leading to bogus barcheck errors and incorrect output.
> ---
>   stepmake/aclocal.m4 |    8 ++++++--
>   1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/stepmake/aclocal.m4 b/stepmake/aclocal.m4
> index 8be2cab..42c65a5 100644
> --- a/stepmake/aclocal.m4
> +++ b/stepmake/aclocal.m4
> @@ -287,12 +287,16 @@ AC_DEFUN(STEPMAKE_CXXTEMPLATE, [
>   ])
>
>   AC_DEFUN(STEPMAKE_GXXCODEGENBUG, [
> -    AC_MSG_CHECKING([options for known g++ tail call bug])
> +    AC_MSG_CHECKING([options for known g++ bugs])
>       case "$GXX:$CXX_VERSION" in
>       yes:400600?)

We can probably use yes:400600[0-2]) here: 4.6.3 is supposed to contain
the fix.

<URL:http://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=4.6.3>
(our bug is #2 on the list, and only because severity is not used for sorting)

I have not checked this though.

> -         AC_MSG_RESULT([-fno-optimize-sibling-calls])
> +         AC_MSG_RESULT([-fno-optimize-sibling-calls (tail call bug)])
>           CXXFLAGS="$CXXFLAGS -fno-optimize-sibling-calls"
>           ;;
> +     yes:400700?)
> +         AC_MSG_RESULT([-fno-tree-vrp (comparison bug)])
> +         CXXFLAGS="$CXXFLAGS -fno-tree-vrp"
> +         ;;
>       *) AC_MSG_RESULT([none])
>       esac
>       AC_SUBST(CXXFLAGS)

Well, ugh.  Let's hope that we can change that ? to 0 at some point of
time.

-- 
David Kastrup