Key signature from 1.3 score not imported

I can't reproduce with Nightly 2ef217d under Windows 8.
However, I can 100% reproduce by using a DEBUG build of the same revision. When I use the RELEASE build I see everything as expected (i.e. I see the key signature).
The same happens for the attached file (created in 1.3, in 1.3 it displays as shown in keys-1.3.png). All key signature at the beginning of every line (staff) are not present when opened with a DEBUG build (keys-2.0debug-1.png). The Nightly RELEASE build displays all the key signatures without problems.

Oooh, I wonder if this is related to why the keysig automated tests in the "compat" folder fail but only on Windows?

It seems indeed that between debug and release modes the "custom" and "invalid" properties read by the union change (at least in my environment).
In the debug build this makes needKeysig equal to 0 in libmscore\layout.cpp:784 inside the addSystemHeader function. The key signature is therefore deleted (since seen as invalid).
In the release build these two properties are read as 0, thus no problem.

In particular:
oneflat.mscz
RELEASE:
accidentalType: -1 ; naturalType: 0 ; customType: 0 ; custom: 0 ; invalid: 0
needKeysig = 1
DEBUG:
accidentalType: -1 ; naturalType: 0 ; customType: 0 ; custom: 1 ; invalid: 1
needKeysig = 0

And similarly for the keys.mscx file.

It is interesting to notice that I already stumbled upon a difference in behavior between release and debug versions in aeolus playback ( http://musescore.org/en/node/16625 comment #13) and indeed also in aeolus\rankwave.cpp the union is used for reading and writing information.

For the record, the places where union is used are:
MuseScore\aeolus\rankwave.cpp (2 hits)
MuseScore\aeolus\sparm_p.h (1 hit)
MuseScore\awl\fastlog.h (1 hit)
MuseScore\fluid\sfont.h (2 hits)
MuseScore\libmscore\bsp.h (1 hit)
MuseScore\libmscore\image.h (1 hit)
MuseScore\libmscore\key.cpp (1 hit)
MuseScore\libmscore\style.h (1 hit)
MuseScore\mscore\seq.h (1 hit)
MuseScore\thirdparty\portmidi\pm_mac\readbinaryplist.h (1 hit)
MuseScore\thirdparty\portmidi\pm_win\pmwinmm.c (1 hit)
MuseScore\zerberus\voice.h (1 hit)

I can't reproduce either.

Using MuseScore 2.0 Nightly Build (d5997be) - Mac 10.7.5.

I can sort of reproduce in the test case.
If I add just after the last printf line printf("_invalid %d\n" , a._invalid); (i.e. as the last instruction) the following line:
int ytest = 15;
It gives _invalid=1 also in the normal compilation (i.e. without the "-std=gnu++0x -g").

Don't know enough about C++, but in plain C (up to and including C99) the result of accessing a value from a Union other than the last one strored into is unspecified (see Annex J of the C99 standard)

I found where the problem lies: it is the default behavior in MinGW of gcc 4.7 onwards.
Indeed, the -mms-bitfields flag is enabled by default:
http://mingw.5.n7.nabble.com/MinGW-GCC-4-7-0-released-td21925.html
http://gcc.gnu.org/gcc-4.7/changes.html
(a Google search will show up all the problems this default behavior change introduced for others as well).
The strange behavior seen for this bug report is reproducible under Linux with the test case if -mms-bitfields or -mms-bitfields -O2 are used for compilation: what makes the difference between MuseScore debug and release compilation is the use of -O2 in our case (which probably does not really solve the problem, but simply masks it).
To solve the behavior we can add the -mno-ms-bitfields flag in both debug and release Windows build, so that it becomes equal to the behavior under Linux.
(Another possiblity could be to set the gcc_struct attribute for the struct, but this attribute is probably not understood by Mac compiler)

Fixed in b030a325a9

Automatically closed -- issue fixed for 2 weeks with no activity.