NetBSD Problem Report #53039

From www@NetBSD.org  Mon Feb 19 17:11:58 2018
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 2147C7A182
	for <gnats-bugs@gnats.NetBSD.org>; Mon, 19 Feb 2018 17:11:58 +0000 (UTC)
Message-Id: <20180219171156.747C97A1BC@mollari.NetBSD.org>
Date: Mon, 19 Feb 2018 17:11:56 +0000 (UTC)
From: coypu@sdf.org
Reply-To: coypu@sdf.org
To: gnats-bugs@NetBSD.org
Subject: VAX with GCC 6.4.0 hits internal compiler error
X-Send-Pr-Version: www-1.0

>Number:         53039
>Category:       port-vax
>Synopsis:       VAX with GCC 6.4.0 hits internal compiler error
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    port-vax-maintainer
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Feb 19 17:15:00 +0000 2018
>Closed-Date:    Mon Apr 02 19:23:52 +0000 2018
>Last-Modified:  Mon Apr 02 19:23:52 +0000 2018
>Originator:     coypu
>Release:        NetBSD 8.99.12
>Organization:
>Environment:
NetBSD planets 8.99.12 NetBSD 8.99.12 (GENERIC) #0: Thu Feb  8 00:38:03 IST 2018  fly@planets:/usr/src/sys/arch/amd64/compile/GENERIC amd64

>Description:
Attempting to update vax over to GCC 6.4.0 hits an internal compiler error building libstdc++.
I've made a smaller version that doesn't require building much of userland to reach the ICE.



/* vax--netbsdelf-c++ -c -std=gnu++11 test.cc */
#include <atomic>

namespace std
{
  namespace a
  {
    struct atomic_flag : public __atomic_flag_base
    {
     bool
     test_and_set(memory_order);
    };

    bool
    atomic_flag::test_and_set(memory_order)
    {
	return false;
    }
  }
  bool
  atomic_flag_test_and_set_explicit(__atomic_flag_base* __a, memory_order __m)
  {
    atomic_flag* d = static_cast<atomic_flag*>(__a);
    return d->test_and_set(__m);
  }
}



It hits the following internal compiler error. running GCC with GDB wrapper and many debug flags (HOST_CXXFLAGS=-O0 -g -ggdb3), I get:

/home/fly/vax4/tooldir.NetBSD-8.99.12-amd64/bin/vax--netbsdelf-c++ -wrapper gdb,--args -c -std=gnu++11 test.cc
(gdb) b patch_jump_insn
Breakpoint 1 at 0x939bd3: file /usr/src/tools/gcc/../../external/gpl3/gcc/dist/gcc/cfgrtl.c, line 1177.
(gdb) r
Starting program: /home/fly/vax4/tooldir.NetBSD-8.99.12-amd64/libexec/gcc/vax--netbsdelf/6.4.0/cc1plus -quiet test.cc -fPIC -quiet -dumpbase test.cc -auxbase test -std=gnu++11 -fPIC -o /var/tmp//ccrvj6Eb.s

Breakpoint 1, patch_jump_insn (insn=0x7762a6524b88, old_label=0x7762a652e700, new_bb=0x7762a6b1d9c0) at /usr/src/tools/gcc/../../external/gpl3/gcc/dist/gcc/cfgrtl.c:1177
1177	  if (tablejump_p (insn, NULL, &table))




(gdb) call debug_insn_slim(insn)
   12: {pc={(zero_extract([r23:SI],0x1,0x1)!=0)?L14:pc};zero_extract([r23:SI],0x1,0x1)=0x1;}




(gdb) c
Continuing.
test.cc: In function 'bool std::atomic_flag_test_and_set_explicit(std::__atomic_flag_base*, std::memory_order)':
test.cc:25:3: internal compiler error: in patch_jump_insn, at cfgrtl.c:1271
   }
   ^
0x93a06b patch_jump_insn
	/usr/src/tools/gcc/../../external/gpl3/gcc/dist/gcc/cfgrtl.c:1271
0x93a11d redirect_branch_edge
	/usr/src/tools/gcc/../../external/gpl3/gcc/dist/gcc/cfgrtl.c:1297
0x93a5c4 rtl_redirect_edge_and_branch
	/usr/src/tools/gcc/../../external/gpl3/gcc/dist/gcc/cfgrtl.c:1431
0x92a114 redirect_edge_and_branch(edge_def*, basic_block_def*)
	/usr/src/tools/gcc/../../external/gpl3/gcc/dist/gcc/cfghooks.c:356
0x10e0ce8 try_forward_edges
	/usr/src/tools/gcc/../../external/gpl3/gcc/dist/gcc/cfgcleanup.c:573
0x10e669f try_optimize_cfg
	/usr/src/tools/gcc/../../external/gpl3/gcc/dist/gcc/cfgcleanup.c:2817
0x10e6bd1 cleanup_cfg(int)
	/usr/src/tools/gcc/../../external/gpl3/gcc/dist/gcc/cfgcleanup.c:3028
0x928b97 execute
	/usr/src/tools/gcc/../../external/gpl3/gcc/dist/gcc/cfgexpand.c:6469
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://www.NetBSD.org/Misc/send-pr.html> for instructions.
[Inferior 1 (process 12464) exited with code 04]


...


Looking at the relevant code near the assert:

	  /* If the substitution doesn't succeed, die.  This can happen
	     if the back end emitted unrecognizable instructions or if
	     target is exit block on some arches.  */
	  if (!redirect_jump (as_a <rtx_jump_insn *> (insn),
			      block_label (new_bb), 0))
	    {
	      gcc_assert (new_bb == EXIT_BLOCK_PTR_FOR_FN (cfun));
	      return false;
	    }

>How-To-Repeat:

>Fix:
It appears the following code, in gcc/config/vax/builtins.md is the offending code. Removing this chunk in gcc/config/vax/builtins.md avoids the ICE.

This code needs to be inspected by someone with a stronger GCC clue, but I will keep on trying.


(define_expand "sync_lock_test_and_set<mode>"
  [(set (match_operand:VAXint 0 "nonimmediate_operand" "=&g")
	(unspec:VAXint [(match_operand:VAXint 1 "memory_operand" "+m")
		    (match_operand:VAXint 2 "const_int_operand" "n")
		   ] VUNSPEC_LOCK))]
  ""
  "
{
  rtx label;

  if (operands[2] != const1_rtx)
    FAIL;

  label = gen_label_rtx ();
  emit_move_insn (operands[0], const1_rtx);
  emit_jump_insn (gen_jbbssi<mode> (operands[1], const0_rtx, label, operands[1]));
  emit_move_insn (operands[0], const0_rtx);
  emit_label (label);
  DONE;
}")

(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")

(define_insn "jbbssihi"
  [(parallel
    [(set (pc)
	  (if_then_else
	    (ne (zero_extract:SI (match_operand:HI 0 "memory_operand" "Q")
				 (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:HI 3 "memory_operand" "+0")
			   (const_int 1)
			   (match_dup 1))
	  (const_int 1))])]
  ""
  "jbssi %1,%0,%l2")

(define_insn "jbbssisi"
  [(parallel
    [(set (pc)
	  (if_then_else
	    (ne (zero_extract:SI (match_operand:SI 0 "memory_operand" "Q")
				 (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:SI 3 "memory_operand" "+0")
			   (const_int 1)
			   (match_dup 1))
	  (const_int 1))])]
  ""
  "jbssi %1,%0,%l2")


>Release-Note:

>Audit-Trail:
From: coypu@sdf.org
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: port-vax/53039: VAX with GCC 6.4.0 hits internal compiler error
Date: Mon, 19 Mar 2018 20:55:02 +0000

 krister mentions that inserting a useless move after the label also
 avoids the problem:

 --- a/external/gpl3/gcc/dist/gcc/config/vax/builtins.md
 +++ b/external/gpl3/gcc/dist/gcc/config/vax/builtins.md
 @@ -70,6 +70,7 @@
    emit_jump_insn (gen_jbbssi<mode> (operands[1], const0_rtx, label,
 operands[1]));
    emit_move_insn (operands[0], const0_rtx);
    emit_label (label);
 +  emit_move_insn (operands[0], operands[0]);
    DONE;
  }")

 And that it's related to an optimization from the label being the last
 thing in the function

From: "Maya Rashish" <maya@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/53039 CVS commit: src/external/gpl3/gcc/dist/gcc/config/vax
Date: Mon, 2 Apr 2018 17:45:23 +0000

 Module Name:	src
 Committed By:	maya
 Date:		Mon Apr  2 17:45:23 UTC 2018

 Modified Files:
 	src/external/gpl3/gcc/dist/gcc/config/vax: builtins.md predicates.md

 Log Message:
 Add new predicate volatile_mem_operand and use it for jbbssi<mode>

 Fixes PR port-vax/53039: GCC/VAX hits ICE building libstdc++

 GCC wants to change the label and then doesn't recognise the
 new insn, it believes it doesn't satisfy the memory_operand
 predicate.

 It appears the memory_operand predicate doesn't accept volatile
 memory accesses during the RTL generation phase.

 The predicate is from rs6000 code.

 from krister


 To generate a diff of this commit:
 cvs rdiff -u -r1.7 -r1.8 \
     src/external/gpl3/gcc/dist/gcc/config/vax/builtins.md
 cvs rdiff -u -r1.1.1.4 -r1.2 \
     src/external/gpl3/gcc/dist/gcc/config/vax/predicates.md

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

State-Changed-From-To: open->closed
State-Changed-By: maya@NetBSD.org
State-Changed-When: Mon, 02 Apr 2018 19:23:52 +0000
State-Changed-Why:
Fixed by krister.


>Unformatted:

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.43 2018/01/16 07:36:43 maya Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2017 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.