https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122976
--- Comment #12 from Martin Jambor <jamborm at gcc dot gnu.org> --- (In reply to Jacek Sieka from comment #11) > Thanks for looking into this. Based on the fix, can you think of a > (reasonable) workaround that we can introduce to make things work with the > versions of GCC that exhibit the bug? > As my small testcase shows, the bug is in tree-sra and there is no way how to 100% avoid it other than disabling the pass altogether with -fno-tree-sra. This can however be easily bad for performance. On the other hand, in your particular testcase, I found out that the reason why the variable nextRef_1 which is of type tyObject_Rlp__dNpAlq42D2iOFkwuW8WMyQ is accessed via type tyTuple__hnCuDR9cLe2lA3YIkwKIyuA (which is the thing that confuses the pass) is because IPA-ICF (Identical code folding) merges functions _ZN4sets11eqwasMoved_E3varI5tupleI3int3seqI5uInt8EEE and _ZN3rlp11eqwasMoved_E3varIN3rlp3RlpEE and as far I can tell(!), such access is not present in the source. So you should be able to avoid the issue by compiling at least @psets.nim.c.i or @[email protected] with -fno-ipa-icf. That can lead to some code-size growth but hopefully nothing dramatic.
