On Fri, Sep 20, 2019 at 11:15:32AM +0000, co...@sdf.org wrote: > Removed from the diff. Unfortunately this introduces an ICE during the > build of GCC...
I took another look at the VAX atomic pattern issue. (http://gnats.netbsd.org/53039) It is a compiler crash to do with the added atomic builtins. The original suggestion was to introduce a reversed pattern, with label / pc swapped. It did not work, unfortunately. The crash backtrace is (gcc-trunk line numbers): during RTL pass: expand /home/fly/gcc/libatomic/flag.c: In function 'atomic_flag_test_and_set': /home/fly/gcc/libatomic/flag.c:36:1: internal compiler error: in patch_jump_insn, at cfgrtl.c:1291 36 | } | ^ 0x718c22 patch_jump_insn /home/fly/gcc/gcc/cfgrtl.c:1290 0x718d2f redirect_branch_edge /home/fly/gcc/gcc/cfgrtl.c:1317 0x71b8c2 rtl_redirect_edge_and_branch /home/fly/gcc/gcc/cfgrtl.c:1450 0x703909 redirect_edge_and_branch(edge_def*, basic_block_def*) /home/fly/gcc/gcc/cfghooks.c:373 0x119ec6e try_forward_edges /home/fly/gcc/gcc/cfgcleanup.c:558 0x11a26ca try_optimize_cfg /home/fly/gcc/gcc/cfgcleanup.c:2961 0x11a26ca cleanup_cfg(int) /home/fly/gcc/gcc/cfgcleanup.c:3175 0x700a41 execute /home/fly/gcc/gcc/cfgexpand.c:6683 This seems to be where GCC has some logic specific to optimizing jumps. Since this isn't a normal jump possible to eliminate by being clever, but rather our only way of doing atomics, my gut feeling is that I should avoid this jump optimizing code entirely. Not telling GCC it's a jump worth optimizing seems to avoid the crash, i.e.: - emit_jump_insn (gen_jbbssi<mode> (operands[1], const0_rtx, label, operands[1])); + emit_insn (gen_jbbssi<mode> (operands[1], const0_rtx, label, operands[1])); + LABEL_NUSES (label)++; GCC builds, but when building netbsd I get an undefined reference in libstdc++: libstdc++.so: undefined reference to `.L72' libstdc++.so: undefined reference to `.L75' I wonder whether this is a right approach with a slightly off method.
