This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: syncing the GCC vax port, atomic issue

On Fri, Sep 20, 2019 at 11:15:32AM +0000, 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.
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
0x718d2f redirect_branch_edge
0x71b8c2 rtl_redirect_edge_and_branch
0x703909 redirect_edge_and_branch(edge_def*, basic_block_def*)
0x119ec6e try_forward_edges
0x11a26ca try_optimize_cfg
0x11a26ca cleanup_cfg(int)
0x700a41 execute

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,

-  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++: undefined reference to `.L72' undefined reference to `.L75'

I wonder whether this is a right approach with a slightly off method.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]