MacOSX Builds using -02 due to test failures since 4.9.3

[akrherz]

Comment:

Whilst thrashing on #207 to build netcdf 4.9.3, I found that -O3 was leading to test failures on MacOSX.

 *** testing nc_redef ...
  1386 good comparisons.
        FAILURE at line 1074 of $SRC_DIR/nc_test/util.c: Var d [0] value read -80 not that expected 255
  33 good comparisons.
  1386 good comparisons.
        FAILURE at line 1074 of $SRC_DIR/nc_test/util.c: Var d [0] value read -80 not that expected 255
  33 good comparisons.
 *** testing nc_sync ...
        FAILURE at line 1074 of $SRC_DIR/nc_test/util.c: Var d [0] value read 32 not that expected 255
  33 good comparisons.
  1386 good comparisons.
 
        ### 1 FAILURES TESTING nc_sync! ###
 *** testing nc_abort ...
  1386 good comparisons.
        FAILURE at line 1074 of $SRC_DIR/nc_test/util.c: Var d [0] value read -32 not that expected 255
  33 good comparisons.
 
        ### 1 FAILURES TESTING nc_abort! ###
 *** testing nc_copy_att ...
        FAILURE at line 1074 of $SRC_DIR/nc_test/util.c: Var d [0] value read -48 not that expected 255
  33 good comparisons.
 
        ### 1 FAILURES TESTING nc_copy_att! ###
 *** testing nc_rename_att ...
        FAILURE at line 1875 of $SRC_DIR/build-shared/nc_test/test_write.c: get_att_text: unexpected value
 
        ### 1 FAILURES TESTING nc_rename_att! ###

So an elegant hack was arrived at to force MacOSX to use -O2. I think this was a similar situation to what was found with #164

[WardF]

This looks like an issue we've previously squashed, which is not to say it hasn't found its way back in. My naive attempts to recreate this issue in my own MacOS (on Apple M4 hardware) have met with failure. A couple clarifying questions:

1. Can you tell me how exactly you're building netCDF when you see this issue? The cmake command, etc? I'd like to recreate this exactly, since simply building and testing with -03 is not causing an issue for me.
2. The name of this issue says 'since 4.9.3'; are you seeing this in the current main branch? If not, that might actually be good, as I've only tested against main in the last few minutes. If this was fixed between 4.9.3 and current main, we can hopefully isolate the fix via git bisect. Thanks!

[akrherz]

Hi @WardF , this happening within this repo on conda-forge, so all the build configurations and scripts are stored here. See #205 for the reproducer and CI build logs.

[xylar]

@WardF, it's worth noting that we can't test arm64 (so what you are presumably running on your M4 hardware) on conda-forge CI. We're still stuck with x86-64 and that's where we're seeing these errors. Just mentioning that in case it makes the different.

We're definitely running with the 4.9.3 release, not main so it would be worth checking to see if you can reproduce the error with release. If not, though, there may be a number of differences between our builds here and what you're testing.