Unexpected behavior with Enzo plug-in for gcc releases after 10.4

[anchwr]

I am using MUSIC2 to generate initial conditions for cosmological zoom-in simulations with Enzo and have encountered unexpected behavior with recent versions of gcc when I generate the level 1 ICs. When MUSIC2 is built and run with older versions of gcc, the RefinementMask files that are generated are what I expect: primarily -1s, with some 0s in RefinementMask.1 and 0s with some 1s in RefinementMask.0. However, when MUSIC2 is built and run with newer versions of gcc, the RefinementMask.1 file is entirely -1s and the RefinementMask.0 file is entirely 0s. Enzo reads RefinementMask.1 in order to determine which particles should be designated "must refine", so this issue limits my ability to run zooms. Based on the contents of the RefinementMask files, I'm guessing something is going wrong with my build in either is_refined or is_in_mask.

Versions of gcc from before August 2022 that I've been able to test (10.3, 8.5, 11.2, 11.3, 10.4) produce the expected behavior while later versions that I've been able to test (12.2, 10.5, 14.2) do not.

I would be grateful for any help with debugging!

[anchwr]

Update: I discovered that I could not achieve the expected behavior in any MUSIC2 commit that I had built with cmake, even when the makefile for the same commit produced the expected set of RefinementMask files. The culprit here appears to be cmake's use of -march=native, rather than -mtune=native. Substituting the latter for the former in cmake produces the expected behavior (including for the most recent commit). The gcc version dependence remains, however. I'm unsure whether or not the two are connected.

[ohahn]

Sounds like a tough one. I am not currently using ENZO myself, can you propose a minimal test case to see the failure?