Yes, I realized that after I stepped away from the computer... I had ported the 2 changes from ~April 6th, and after thinking about it don't remember anything in the changesets that actually used the new macros.
I'll take a closer look and see if I can do a proper job this time around.
Bill
On Wed, 23 May 2012, Henrik Grubbström (Lysator) @ Pike (-) developers forum wrote:
I tried porting the fix, but it doesn't seem to make any difference. It's possible I've made an error in my port (the cherry-pick generated a merge conflict so I did it by hand). I'll try it again tomorrow.
The fix involves more than one commit. You will eg need commit 4555f37d5b014dd680cf86b735fb20b659f296d3 which adds a function to interpret.c that was needed by the amd64 code-generator, and then by the new x86 code-generator.
The easiest approach is probably to first backport the amd64 code-generator, and then the new x86 code-generator.
As a side note, on Darwin, the problem with machine code on ia32 (and perhaps 64-bit as well,) is that the assembly generated isn't PIC, so it fails to compile with errors about registers being clobbered.
Bill
/grubba