public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jeff Law <law@redhat.com>
To: coypu@sdf.org, gcc@gcc.gnu.org, port-vax@netbsd.org
Subject: Re: syncing the GCC vax port, atomic issue
Date: Fri, 20 Sep 2019 21:45:00 -0000	[thread overview]
Message-ID: <010f52a3-98ed-47f9-38af-2560193b6a52@redhat.com> (raw)
In-Reply-To: <20190920210434.GA13838@SDF.ORG>

On 9/20/19 3:04 PM, coypu@sdf.org wrote:
> 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.
Conditional branching patterns must support the label_ref and pc
operands in either position.  Everything else I've seen on this thread
is just working around that broken aspect of the builtins.md file.


(define_insn "jbbssiqi"
  [(parallel
    [(set (pc)
	  (if_then_else
	    (ne (zero_extract:SI (match_operand:QI 0 "memory_operand" "g")
				 (const_int 1)
				 (match_operand:SI 1 "general_operand" "nrm"))
		(const_int 0))
	    (label_ref (match_operand 2 "" ""))
	    (pc)))
     (set (zero_extract:SI (match_operand:QI 3 "memory_operand" "+0")
			   (const_int 1)
			   (match_dup 1))
	  (const_int 1))])]
  ""
  "jbssi %1,%0,%l2")

Note the position of the (label_ref ...) and (pc) operand.  You have to
have a pattern where they are reversed as well.

As an example look at the branch and branch_reversed patterns in vax.md

jeff

> 

  reply	other threads:[~2019-09-20 21:45 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     ` syncing the GCC vax port, atomic issue coypu
2019-09-20 21:45       ` Jeff Law [this message]
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=010f52a3-98ed-47f9-38af-2560193b6a52@redhat.com \
    --to=law@redhat.com \
    --cc=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).