Please really check that reverting only the change in `lily/simple-spacer.cc`
is sufficient for removing the problem. Because if it is, we have a far larger
problem either involving a fundamental Guile bug or a GCC compiler bug: the
change in `simple-spacer.cc` is just
diff --git a/lily/simple-spacer.cc b/lily/simple-spacer.cc
index d17fa1e..ada1659 100644
--- a/lily/simple-spacer.cc
+++ b/lily/simple-spacer.cc
@@ -528,7 +528,7 @@ get_line_configuration (vector<Grob *> const &columns,
for (vsize i = 1; i + 1 < ret.cols_.size (); i++)
{
SCM p = ret.cols_[i]->get_property ("line-break-permission");
- if (p == ly_symbol2scm ("force"))
+ if (scm_is_eq (p, ly_symbol2scm ("force")))
ret.satisfies_constraints_ = false;
}
And the respective definitions in Guile 1.8 are:
#elif (SCM_DEBUG_TYPING_STRICTNESS == 1)
/* This is the default, which provides an intermediate level of compile time
* type checking while still resulting in very efficient code.
*/
typedef struct scm_unused_struct * SCM;
/*
The 0?: constructions makes sure that the code is never executed,
and that there is no performance hit. However, the alternative is
compiled, and does generate a warning when used with the wrong
pointer type.
The Tru64 and ia64-hp-hpux11.23 compilers fail on `case (0?0=0:x)`
statements, so for them type-checking is disabled.
*/
#if defined __DECC || defined __HP_cc
# define SCM_UNPACK(x) ((scm_t_bits) (x))
#else
# define SCM_UNPACK(x) ((scm_t_bits) (0? (*(SCM*)0=(x)): x))
#endif
followed by
#define scm_is_eq(x, y) (SCM_UNPACK (x) == SCM_UNPACK (y))
and also
/* For dealing with the bit level representation of scheme objects we define
* scm_t_bits:
*/
/* On Solaris 7 and 8, /usr/include/sys/int_limits.h defines
INTPTR_MAX and UINTPTR_MAX to empty, INTPTR_MIN is not defined.
To avoid uintptr_t and intptr_t in this case we require
UINTPTR_MAX-0 != 0 etc. */
#if SCM_SIZEOF_INTPTR_T != 0 && defined(INTPTR_MAX) && defined(INTPTR_MIN) \
&& INTPTR_MAX-0 != 0 && INTPTR_MIN-0 != 0 \
&& SCM_SIZEOF_UINTPTR_T != 0 && defined(UINTPTR_MAX) && UINTPTR_MAX-0 != 0
typedef intptr_t scm_t_signed_bits;
#define SCM_T_SIGNED_BITS_MAX INTPTR_MAX
#define SCM_T_SIGNED_BITS_MIN INTPTR_MIN
typedef uintptr_t scm_t_bits;
#define SIZEOF_SCM_T_BITS SCM_SIZEOF_UINTPTR_T
#define SCM_T_BITS_MAX UINTPTR_MAX
#else
typedef signed long scm_t_signed_bits;
#define SCM_T_SIGNED_BITS_MAX LONG_MAX
#define SCM_T_SIGNED_BITS_MIN LONG_MIN
typedef unsigned long scm_t_bits;
#define SIZEOF_SCM_T_BITS SCM_SIZEOF_UNSIGNED_LONG
#define SCM_T_BITS_MAX ULONG_MAX
#endif
Either scm_t_bits is defined as an unsigned long (of length 32 bit) unable to
actually hold a pointer value, in which case Guile will be broken. Or we have
a compiler error during code generation. Either will affect a lot more code
than just this.
So we better make quite sure that this change is responsible. And if it is,
I'll need to look at the output of autoconf on the cross compilation of Guile,
and then I'll likely need to check the generated assembly code.
---
** [issues:#4975] [Windows] Grace notes cause staff to protrude into the
margin**
**Status:** Started
**Created:** Sun Sep 18, 2016 11:07 PM UTC by Simon Albrecht
**Last Updated:** Wed Sep 28, 2016 09:07 AM UTC
**Owner:** Phil Holmes
http://lilypond.1069038.n5.nabble.com/Grace-notes-and-staff-miss-alignment-tp181529p188186.html
As reported by Karol and confirmed by Pierre, this code
~~~~
:::TeX
\version "2.19.48"
\transpose c c' {
\repeat unfold 16 { e'8 a }
R1*8
}
\transpose c c' {
\repeat unfold 16 { \grace dis'8 e' \grace gis8 a }
R1*8
}
~~~~
under Windows (at least 7 and 8) causes lots of `programming error:
mis-predicted force` and has the last staff flow into the margin.
Output at <http://lilypond.1069038.n5.nabble.com/file/n188186/ttttttt.pdf>
The first bad version is 2.19.19.
---
Sent from sourceforge.net because testlilyissues-a...@lists.sourceforge.net 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.------------------------------------------------------------------------------
_______________________________________________
Testlilyissues-auto mailing list
testlilyissues-a...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/testlilyissues-auto
