GCC internal error

[FlorianDeconinck]

Describe the bug
Code generated by the CPU backend of DaCe can (infrequently) lead to GCC dying of internal failure.

/home/runner/work/dace/dace/pace/.gt_cache_FV3_A/dacecache/pace_fv3core_stencils_remapping_LagrangianToEulerian___call__/src/cpu/pace_fv3core_stencils_remapping_LagrangianToEulerian___call__.cpp:653:52: internal compiler error: in convert_like_internal, at cp/call.c:7952
  653 |                 const double* const &pe1__ = &pe1[0];
      |                                                    ^
0xe34ddb internal_error(char const*, ...)
	???:0
0xe2b903 fancy_abort(char const*, int, char const*)
	???:0
0xfe340e cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
	???:0
0x14a51e3 c_parse_file()
	???:0
0x149493e c_common_parse_file()
	???:0
Please submit a full bug report,

The above pattern const double* const &X = &Y[0] is indeed the culprit. Removing it by hand saves GCC from dying.

This happens from gcc 10 to 13 included.

Can we get rid of the const &, which arguably is correct but seems to make GCC sad?

To Reproduce

git clone https://github.com/GEOS-ESM/pace.git
cd pace
python -m pip install --upgrade pip wheel setuptools
pip -m venv .venv
source .venv/bin/activate
pip install -r requirements_dev.txt
mkdir -p test_data
cd test_data
wget https://portal.nccs.nasa.gov/datashare/astg/smt/pace-regression-data/8.1.3_c12_6_ranks_standard.Remapping.tar.gz
tar -xzvf 8.1.3_c12_6_ranks_standard.Remapping.tar.gz
cd ../../
export FV3_DACEMODE=BuildAndRun
export PACE_CONSTANTS=GFS
pytest -v -s --data_path=./test_data/8.1.3/c12_6ranks_standard/dycore \
    --backend=dace:cpu --which_modules=Remapping --which_rank=0 \
    --threshold_overrides_file=./fv3core/tests/savepoint/translate/overrides/standard.yaml \
    ./fv3core/tests/savepoint

[alexnick83]

Is it the const & or the combination with const * that creates the issue? I suspect that it is the latter. Could you write here the relevant SDFG information (Memlet expression and data container information; if one of the data is a view then please also write the data connected to it)?

[FlorianDeconinck]

It's the combination. We are running under a separate branch on my fork where I generate the above as const* x = &y[0] and it's working fine.

The issue is that since it's an internal GCC failure the pattern doesn't fail all the time, I'll endeavor to get the smallest SDFG failing I can

[FlorianDeconinck]

Here's the smallest SDFG that triggers it, albeit a big one I am afraid. A load/compile shows it: remapping.sdfgz.zip. As usual with github I appended .zip but it's a straight .sdfgz

[FlorianDeconinck]

The original python code is here: https://github.com/GEOS-ESM/pace/blob/c50b7af37d6de68620095747f09ad9ea39af4a83/fv3core/pace/fv3core/stencils/map_single.py#L21

[FlorianDeconinck]

Up this issue.

It's still very much present with latest DaCe on main. At the moment, we have to run our own fork of DaCe which is far form ideal. How can we proceed forward?

[alexnick83]

Can you please check whether #1522 fixes the issue?

[FlorianDeconinck]

#1522 fixes it.