#3539 Type issues in codegen (make regtests on 32-bit big-endian host fail)

[Philipp Klaus Krause]

As can be seen from the large number of regression test failures on the macOS PPC machine, many regression tests now fail on 32-bit big-endian hosts. Erik tracked this down to using the wrong type in emit functions in codegen (i.e. !constbyte, !immedbyte, !constword and !immedword) all expect an unsigned int argument.

[Philipp Klaus Krause]

[r13797] has a first round of fixes.

[Philipp Klaus Krause]

Looks like these fixes brought the number of failures per affected port down to about a 100 from about a 1000 before.

[Philipp Klaus Krause]

I've dug out my old mac mini G4 with OpenBSD on it, and have now reproduced the issues. I hope to have them fixed by the end of the week.

[Erik Petrich]

If it helps, the remaining problems are symptomatic of a literal value being assigned to v_longlong or v_ulonglong, but then read out through v_long or v_ulong. On little endian this is nondestructive (assuming the value only needs the lower half of the bits), but on big endian you get the upper all 0 bits instead. This is what I originally thought the problem fixed last week was going to be, but it turned out the code generators were getting the correct non-zero values and accidentally converting them to 0 while generating the assembly. In these remaining failures that I've looked at so far, the code generators are now getting 0 from non-zero literals.

[Philipp Klaus Krause]

It looks like bytes are swapped somewhere in the value:

My debug printfs show that valVastLiteral is called with a correct 0x30 when the value is created, but by the time codegen makes an aop, the value in v_ulonglong has become 0x30000000000000. For the regression test bug-3410.c.in.

[Philipp Klaus Krause]

This bit should be fixed in [r13818], which helped bring down the number of failures on stm8.

[Philipp Klaus Krause]

Looks like this actually did it.There is a small number of remaining failures (0 to1 per port) I see on my iMac mini G4 running OpenBSD, but I don't think they're related to this issue.