[Lilypond-auto] [LilyIssues-auto] [testlilyissues:issues] #4943 Manual p

Some findings by Arnold can be found at:
http://lilypond.1069038.n5.nabble.com/Issue-4934-analysis-indicates-new-issue-td224851.html
regrettable there is a typo: 4934 <-> 4943 in his post.

I'll quote it here entirely:

Hello,
as I got this assertion failure on multiple scores on Win7 (on scores which
I created in sequence) I did tried to analyse this problem.

All my effected scores had one system per page. On the last page the
system is compressed.
If I apply tiny changes to the global-staff-size, there is a chance of 50 %
the lilypond run will succeed or it will terminate with assertion from
function
Page_breaking::min_page_count() in file lily/page-breaking.cc.
This problem does occur on Windows (mingw compilation), but not on
Linux compilations (executed in a LILYDEV VM on my Windows computer).

Tracing this function ‘Page_breaking::min_page_count()’ by additional
text output in the LILYDEV VM did show, the critical code must be in
line 1178. The comparison there is sensitive to rounding errors between
80 bit floating point and 64 bit floating point variables, a typical code
problem in IA32 compilations for Windows, where function return values
are passed back in the 80 bit floating point register of the X87 arithmetic
coprocessor.
If the last page contains a single compressed system, the stored (double)
value ‘cur_rod_height’ and the function return value (in X87 register in
IA32 architecture) from ‘cached_line_details_.back().full_height()’ were
equal in the Linux version.

Together with ‘harm6’ at the German Lilypond Forum it got a MINGW
compilation for Windows with tracing text output. It did prove what I
expected:

(1) The assertion is thrown, because the function return value of
‘cached_line_details_.back().full_height()’ is ‘more exact’ (longer
mantissa)
than the double value stored in cur_rod_height. The function return value
is a 80 bit floating point value, and not rounded to the mantissa length
of the 64 bit floating point value it’s going to be compared with.

(2) The check in line 1178 of lily/page-breaking.cc, which is:
&& cur_rod_height > cached_line_details_.back ().full_height ())
can be replaced with:
&& page_starter + 1 != cached_line_details_.size())
which does not compare (inexact) floating point numbers anymore to
check if there is only one system on the last page, to solve issue 4934.

Beside that, I found:

(3) In the past, rounding to 64 bit floating point numbers in the
MINGW compilation was forced by _FPU_SETCW() in function
configure_fpu() from file lily\main.cc.
In this MINGW test compilation this code was not reached!
As this can cause many other peculiar problems, not so simple to
detect as this issue 3934, a new issue should be opened:

/++++++++++++++++++
Repair the broken support of configure_fpu() in the
mingw installation of GUB
/++++++++++++++++++

For a more easy check during GUB compilation I suggest to add
a conditional compile time error (or warning if you prefer) into
lily/main.cc to the empty dummy function configure_fpu():

... starting at line 202 of lily/main.cc ...

 #include <fpu_control.h>
 static void
 configure_fpu ()
 {
   fpu_control_t fpu_control = 0x027f;
   _FPU_SETCW (fpu_control);
 }

 #else

 static void
 configure_fpu ()
 {
+/* throw compilation error if MINGW 32bit with x87 */
+#if defined (__MINGW32__) && defined (__code_model_32__) &&
!defined(__SSE2_MATH__)
+#pragma GCC error "No FPU CONTROL in MINGW compilation required, but NOT
found"
+#endif
 }

 #endif /* defined(__x86__) || defined(__i386__) */

Furthermore, there are also command line options reported for MINGW
to set the floating point precision.
But notice, ‘-mpc64’ did not help for a simple test program on my MINGW
compilation in the LILYDEV VM. That might be the same origin as support
of configure_fpu() is broken in the GUB.
Instead ‘-march=pentium4 -mfpmath=sse -msse2' did work, but this
drops support for older CPU types.

ArnoldTheresius

[issues:#4943] Manual page breaking causing assertion failure

Status: Accepted
Created: Sat Jul 23, 2016 10:51 AM UTC by pkx166h
Last Updated: Thu Jan 10, 2019 01:27 PM UTC
Owner: nobody
Attachments:

AssertionFailing.ly (1.1 kB; text/x-lilypond)

On Sat, 9 Jan 2016 at 09:55 Chris Yate address@hidden wrote:

So, it turns out this was easy to minimise the code. File is attached.
It's still ~70 bars but only one voice, which is the dynamics staff of a
piano score (without anything else), so it's only silent music.

"AutoPageBreaksOff" in the score block causes the exception failure.

I note some "insane spring distance" warnings.These don't happen in the
real thing.

Chris

Note: According to Phil H's own tests: "This started in 2.19.21. 2.19.20 is OK."

Update: an instance of this affects also non-Windows systems, see comment below.

Sent from sourceforge.net because address@hidden is subscribed to https://sourceforge.net/p/testlilyissues/issues/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/testlilyissues/admin/issues/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.

From:	Auto mailings of changes to Lily Issues via Testlilyissues-auto
Subject:	[Lilypond-auto] [LilyIssues-auto] [testlilyissues:issues] #4943 Manual page breaking causing assertion failure
Date:	Fri, 13 Dec 2019 22:30:50 -0000