wasm2c: run tests with -O2 on non-Windows

[keithw]

(This PR is stacked behind #1814, #1877, #1887, and #1930, but if there is interest in landing it sooner, it could be rebased on top of the current ToT.)

Enable optimization when compiling the wasm2c output on non-Windows platforms (effectively GCC and clang). This required:

• Preventing load instructions from being optimized away if their value is unused (using inline assembly with an input operand and empty code). This is necessary to force an OOB trap on platforms that use mprotect and the signal handler to detect OOB.
• Disabling tail-call optimization in the compiler, to make sure that infinite recursion traps. (This required bumping the version of macOS in GitHub Actions to get a new-enough AppleClang. We should revert this back to 'macos-latest' as soon as that becomes the default.)
• Using NaN-quieting versions of a bunch of FP ops that were previously only used on Windows, and adding floor/ceil and promotion/demotion.
• Using the '-frounding-math' and '-fsignaling-nans' compiler flags to tell GCC and clang not to fold certain FP ops (e.g. subtracting zero, multiplying by 1).

Fixes #1925.

[sbc100]

I think it would be great if this and all the other changes in the stack could be rebased to avoid #1814.. then we could land them without being blocked on the instancing discussions.

Could you arrange to have the instancing at the other end of the chain, or do that others somehow depend deeply on it?

[keithw]

#1877 (bulk memory) and #1887 (reference types) unfortunately depend on #1814 in a way that would be a bit annoying to rebase (more details here about why: #1877 (comment)).

The other two would be much easier to rebase (#1930 (exceptions) and #1939 (tests pass with optimization)), and I'm happy to do it if it would help get things moving.

But, instancing is important to us (and I imagine other users) and it would be our hope to actually have that discussion and reach alignment (especially now that we've been building on top of this code for five months in our local fork and have ticked the boxes at #1853 (comment)). How can we help get things moving again there?

[keithw]

(Rebased on current main branch.)

[sbc100]

#1877 (bulk memory) and #1887 (reference types) unfortunately depend on #1814 in a way that would be a bit annoying to rebase (more details here about why: #1877 (comment)).

The other two would be much easier to rebase (#1930 (exceptions) and #1939 (tests pass with optimization)), and I'm happy to do it if it would help get things moving.

But, instancing is important to us (and I imagine other users) and it would be our hope to actually have that discussion and reach alignment (especially now that we've been building on top of this code for five months in our local fork and have ticked the boxes at #1853 (comment)). How can we help get things moving again there?

My apologies for dragging my feet on that. Perhaps we could have a meeting discuss it next week?

[keithw]

Happy to -- I'll send email, but in general July 6 looks pretty good on our end and we're happy to come up to SF.

[sbc100]

lgtm.. did we decide that we don't need to give folks an opt-out for these these things are don't relate directly to sandbox security? (but are there for spec compliance).

I think I'm OK wither way..

[keithw]

I think that was our tentative conclusion, but we're okay either way too. I guess my mild preference is to wait until somebody wants it and avoid the added complexity if we can, but no strong preference.

(Are you able to change the repo configuration to accept a "macos-12" status check instead of "macos-latest"? GitHub has suggested they will update "macos-latest" by August so hopefully it's temporary...)

[sbc100]

I think that was our tentative conclusion, but we're okay either way too. I guess my mild preference is to wait until somebody wants it and avoid the added complexity if we can, but no strong preference.

(Are you able to change the repo configuration to accept a "macos-12" status check instead of "macos-latest"? GitHub has suggested they will update "macos-latest" by August so hopefully it's temporary...)

Do I have to do something to enable that? I thought it was all driven by the yaml file?

[keithw]

Do I have to do something to enable that? I thought it was all driven by the yaml file?

I think the list of "required" status checks is only in the GitHub "Settings" > "Branches" > Branch Protection Rules for main > "Edit" > Status Checks that Are Required. I think it needs to have "build (macos-12)" added and remove "build (macos-latest)" before this can be merged afaik, at least without an override.