http://lilypond.1069038.n5.nabble.com/Grace-notes-and-staff-miss-alignment-tp181529p188186.html
As reported by Karol and confirmed by Pierre, this code
\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.
Later versions throw an assertion pointing to simple-spanner.cc. This file was edited in commit
http://git.savannah.gnu.org/cgit/lilypond.git/commit/lily/simple-spacer.cc?id=e0af94bb8939bc6f4998db6294010baa77139092
which looks far more likely to the culprit. Can anyone who understands this stuff (paging David really) make a comment?
OK - I've spent quite a lot of the last week tracking this down. Short summary: commit e0af94bb8939bc6f4998db6294010baa77139092 (Replace C++ (in)equality checks with proper SCM syntax) is definitely the culprit. I've proven this by taking Gub back to its 2.19.18 state (with a few bugfix cherry picks to make it work on my system) and using 2.19.18 source on dev/philh. This produces a good output. Moving forward to 2.19.19 produces bad output. Moving back to commit "Issue 4343: quoteDuring music should be sent to midi file" produces good output. Moving forward one commit to the one identifed above produces bad output. I am therefore in no doubt that this is the issue. I've no idea why it only affect Windows, and only apparently with this issue. I think we have 2 options: revert the commit, or revert its use in simple-spacer.cc. I've not checked that the latter would work, but it seems likely, and if this looks the way forward I can burn some more CPU time and check with a further build that it works.
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 insimple-spacer.cc
is justAnd 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;
followed by
and also
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.
OK - I've compiled a windows binary with just the single line "if (p == ly_symbol2scm ("force"))" restored (see the git branch dev/philh) and this does not fix the grace note/line length bug. So there is something deeper at work with that commit.
Well, I am sort-of relieved. I'll review the whole commit now for something more suspicious. But platform-specific bugs tend to be tricky to find.
Ok, so I reviewed all of the commit. There are few changes which are not strictly equivalent (but should be functionally equivalent), and If I remember correctly, most of them were likely proposed by me during review. Cough cough.
However, pretty much all of them should not be in code triggered by the example input. So the only other suggestion I can come up with is trying to revert the changes in
lily/include/lily-guile-macros.hh
and see whether that makes a difference.I also have found a bug in
stencil-traverse
instencil-integral.cc
(comparing to an empty string withscm_is_eq
) but that bug again should be independent from the commit. So while it warrants fixing, it should not be related to this issue here.And I'd like the
config.log
(and probablyconfig.hh
) from the Windows cross compilation.Thanks for all the work you put in here.
The bug still exists with lily-guile-macros.hh manually reverted to its previous state. The config.log and config.hh are attached - please let me know if this doesn't work for downloading them and I'll email them over.
Ugh. This is pure 32bit, with pointers and long being 32bit types. So not likely a typing problem. I'll dial back my compilation environment to 32bit and see whether I have better luck at reproducing the problem.
Nope. But my compiler is 6.2.0, the one in the compilation is 4.9.2 (and a few Windows-specific API options but I don't think they are responsible).
Is that what we have in Gub also for Linux? Or should we try updating the Windows version?
If I understand correctly, it is not a compiler problem.
First, I've tried some other environment on Windows 10 64bit.
lilypond-2.19.46-1.mingw.exe (from lilypond.org):
Reproduced.
Cygwin 64 bit + lilypond-2.19.42 (from cygwin package):
No problem.
Cygwin 32 bit + lilypond-2.19.42 (from cygwin package):
No problem.
lilypond-2.19.47 (built by my 64 bit GUB environment):
Reproduced.
Then, I've tried to upgrade GUB's gcc to gcc-5.4.0.
I've failed to build mingw installer.
But, I've succeeded to build Windows exe files.
I've replaced three files (lilypond.exe, lilypond-windows.exe, libstdc++-6.dll) in installed lilypond folder.
Unfortunately, reproduced even if gcc-5.4.0 is used.
From what I understand, we do know which commit is the culprit but we don't know which files from this commit are responsible for the issue (i.e. reverting which files fixes the issue). There are 140 files changed in this commit, so reverting them one by one would be a time consuming process. But maybe you (Phil) could start with reverting a bunch of files that are least likely to be the cause and then you could check whether the bug still exists. If so, you could revert another bunch of files and so on...
Another example reported by Ralph: