From: coypu@sdf.org
To: gcc@gcc.gnu.org, port-vax@netbsd.org
Subject: Re: syncing the GCC vax port, atomic issue
Date: Fri, 20 Sep 2019 21:04:00 -0000 [thread overview]
Message-ID: <20190920210434.GA13838@SDF.ORG> (raw)
In-Reply-To: <20190920111532.GB15685@SDF.ORG>
On Fri, Sep 20, 2019 at 11:15:32AM +0000, coypu@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.
next prev parent reply other threads:[~2019-09-20 21:04 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-30 9:03 syncing the GCC vax port coypu
2019-03-31 17:26 ` Paul Koning
2019-03-31 17:41 ` coypu
2019-04-01 15:33 ` Jeff Law
2019-04-29 20:08 ` Jeff Law
2019-09-20 11:15 ` coypu
2019-09-20 21:04 ` coypu [this message]
2019-09-20 21:45 ` syncing the GCC vax port, atomic issue Jeff Law
2019-09-20 22:08 ` coypu
2019-09-21 1:18 ` coypu
2019-09-21 18:27 ` Paul Koning
2019-10-01 19:44 ` Jeff Law
2019-10-01 19:43 ` Jeff Law
2019-10-02 9:39 ` Richard Earnshaw (lists)
2019-10-02 17:17 ` Segher Boessenkool
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190920210434.GA13838@SDF.ORG \
--to=coypu@sdf.org \
--cc=gcc@gcc.gnu.org \
--cc=port-vax@netbsd.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).