[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Error code -1073741819 with tie and tenuto
From: |
David Kastrup |
Subject: |
Re: Error code -1073741819 with tie and tenuto |
Date: |
Sun, 13 Nov 2016 23:16:40 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) |
Bernhard Kleine <address@hidden> 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 <address@hidden>
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 <address@hidden>
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 <address@hidden>
Signed-off-by: David Kastrup <address@hidden>
and the fix was relying on incomplete analysis, making it responsible
for the damage reported here.
--
David Kastrup