Am 13.11.2016 um 23:16 schrieb David Kastrup: > Bernhard Kleine <[email protected]> writes: > >> Am 13.11.2016 um 22:51 schrieb Simon Albrecht: >>> On 13.11.2016 22:49, Noeck wrote: >>>> Both >>>> >>>> \relative c { >>>> <f ces' es>1~-- | >>>> <f ces' des> | >>>> } >>>> >>>> and >>>> >>>> \relative { >>>> <cis' e>1~-- | >>>> <cis d> | >>>> } >>>> >>>> are compiled without problems here (2.19.49, Ubuntu 16.10, 64bit). >>> OK, so it’s a bug already fixed. >>> >>> Best, Simon >> But withour knowing it! > I wouldn't say that. This is > > commit 93f3d637efbc038b837cf64fae0872e873e4f039 > Author: David Kastrup <[email protected]> > Date: Fri Sep 2 23:11:53 2016 +0200 > > Issue 4965: Create and use Grob::parent_relative > > This function checks for the existence of a Grob parent before > calculating a coordinate relative to it. This should hopefully > clean up the most relevant problems caused by issue 4814 > and the original GCC 6 optimization causing it. > > fixed in 2.19.48. > > > Conversely, issue 4814 was addressed in 2.19.46 by > > commit b0dce76daf27721ba157cd2ac5d7662d4c8d75f8 > Author: Guido Aulisi <[email protected]> > Date: Fri Jul 22 15:26:29 2016 +0200 > > Issue 4814: grob.cc segfaults with gcc6 > > From the release notes of GCC 6: > > Optimizations remove null pointer checks for this > > When optimizing, GCC now assumes the this pointer can never be null, > which is guaranteed by the language rules. Invalid programs which > assume it is OK to invoke a member function through a null > pointer (possibly relying on checks like this != NULL) may crash or > otherwise fail at run time if null pointer checks are optimized > away. With the -Wnull-dereference option the compiler tries to warn > when it detects such invalid code. > > If the program cannot be fixed to remove the undefined behavior then > the option -fno-delete-null-pointer-checks can be used to disable > this optimization. That option also disables other optimizations > involving pointers, not only those involving this. > > As a consequence, we cannot call a member function on a prospective null > pointer (which actually is a bad idea for a number of other reasons, > like when anything tries accessing the vtable) and then try sorting out > the condition in the routine itself. > > This problem was first observed with Fedora 24. The Ubuntu GCC6 > prerelease does not show this problem; presumably the respective > optimization has been disabled in the Ubuntu/Debian packaging because of > affecting other programs. > > Commit-message-by: David Kastrup <[email protected]> > Signed-off-by: David Kastrup <[email protected]> > > > and the fix was relying on incomplete analysis, making it responsible > for the damage reported here. I am very glad that the reason has been found and I was solely ignorant. Sorry. Kind regards and many thanks for a beautiful program.
Bernhard -- spitzhalde9 D-79853 lenzkirch [email protected] www.b-kleine.com, www.urseetal.net - thunderbird mit enigmail GPG schlüssel: D5257409 fingerprint: 08 B7 F8 70 22 7A FC C1 15 49 CA A6 C7 6F A0 2E D5 25 74 09
signature.asc
Description: OpenPGP digital signature
_______________________________________________ lilypond-user mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-user
