https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100181
--- Comment #9 from Tobias Burnus <burnus at gcc dot gnu.org> --- (In reply to Thomas Schwinge from comment #8) > (In reply to Tobias Burnus from comment #7) > > (I could not reproduce the LLVM 9 issue in PR94278 back then.) > > Hmm, but didn't you say in the LLVM issue > <https://bugs.llvm.org/show_bug.cgi?id=45887> that you _did_ reproduce this > back then? I partially mixed it up - I could not reproduce it with a self-build LLVM but could do so with the distro LLVM ones. Our/my LLVM bug 45887 is similar to https://bugs.llvm.org/show_bug.cgi?id=41914, which was fixed by https://reviews.llvm.org/D79943 and the latter adds the check which causes the error message: "undefined label '.L33'" However, the other bug (41914) and the the testcase in the fix (D79943) were about a label which was truly missing as opposed to one which is just in a differently named .section. * * * Obviously, with D79943 at place (LLVM 11, 12, ...), I can reproduce the issue with -O2 (with < -O0 there is only .text) as then 's_branch .L33' is in .section .text but '.L33:' is in '.section .text.unlikely'. Whether it is intended that cross-.section s_branch are no longer permitted or whether it happened by chance by this patch or on purpose, I don't know. Sections themselves are supported – and the LVM testsuite for GCN has testcases with '.section' (under llvm/test/MC/AMDGPU/*.s) – but in the testsuite one at a time. GCC guards the .text.unlikely generation by (→ varasm.c's default_function_section) by if (!flag_reorder_functions || !targetm_common.have_named_sections) return NULL; while the patch in PR 94278 comment 3 uses flag_reorder_blocks_and_partition = 0
