[PATCH 1/1] c++/106423: Fix pragma suppression of -Wc++20-compat diagnostics.

2022-07-23 Thread Tom Honermann via Gcc-patches
Gcc's '#pragma GCC diagnostic' directives are processed in "early mode"
(see handle_pragma_diagnostic_early) for the C++ frontend and, as such,
require that the target diagnostic option be enabled for the preprocessor
(see c_option_is_from_cpp_diagnostics).  This change modifies the
-Wc++20-compat option definition to register it as a preprocessor option
so that its associated diagnostics can be suppressed.  The changes also
implicitly disable the option in C++20 and later modes.  These changes
are consistent with the definition of the -Wc++11-compat option.

This support is motivated by the need to suppress the following diagnostic
otherwise issued in C++17 and earlier modes due to the char8_t typedef
present in the uchar.h header file in glibc 2.36.
  warning: identifier ‘char8_t’ is a keyword in C++20 [-Wc++20-compat]

Tests are added to validate suppression of both -Wc++11-compat and
-Wc++20-compat related diagnostics (fixes were only needed for the C++20
case).

Fixes https://gcc.gnu.org/PR106423.

gcc/c-family/ChangeLog:
* c-opts.cc (c_common_post_options): Disable -Wc++20-compat diagnostics
in C++20 and later.
* c.opt (Wc++20-compat): Enable hooks for the preprocessor.

gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/keywords2.C: New test.
* g++.dg/cpp2a/keywords2.C: New test.

libcpp/ChangeLog:
* include/cpplib.h (cpp_warning_reason): Add CPP_W_CXX20_COMPAT.
* init.cc (cpp_create_reader): Add cpp_warn_cxx20_compat.
---
 gcc/c-family/c-opts.cc |  7 +++
 gcc/c-family/c.opt |  2 +-
 gcc/testsuite/g++.dg/cpp0x/keywords2.C | 16 
 gcc/testsuite/g++.dg/cpp2a/keywords2.C | 13 +
 libcpp/include/cpplib.h|  4 
 libcpp/init.cc |  1 +
 6 files changed, 42 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/keywords2.C
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/keywords2.C

diff --git a/gcc/c-family/c-opts.cc b/gcc/c-family/c-opts.cc
index b9f01a65ed7..1ea37ba9742 100644
--- a/gcc/c-family/c-opts.cc
+++ b/gcc/c-family/c-opts.cc
@@ -1046,6 +1046,13 @@ c_common_post_options (const char **pfilename)
   else if (warn_narrowing == -1)
 warn_narrowing = 0;
 
+  if (cxx_dialect >= cxx20)
+{
+  /* Don't warn about C++20 compatibility changes in C++20 or later.  */
+  warn_cxx20_compat = 0;
+  cpp_opts->cpp_warn_cxx20_compat = 0;
+}
+
   /* C++17 has stricter evaluation order requirements; let's use some of them
  for earlier C++ as well, so chaining works as expected.  */
   if (c_dialect_cxx ()
diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index 44e1a60ce24..dfdebd596ef 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -455,7 +455,7 @@ Wc++2a-compat
 C++ ObjC++ Warning Alias(Wc++20-compat) Undocumented
 
 Wc++20-compat
-C++ ObjC++ Var(warn_cxx20_compat) Warning LangEnabledBy(C++ ObjC++,Wall)
+C++ ObjC++ Var(warn_cxx20_compat) Warning LangEnabledBy(C++ ObjC++,Wall) 
Init(0) CPP(cpp_warn_cxx20_compat) CppReason(CPP_W_CXX20_COMPAT)
 Warn about C++ constructs whose meaning differs between ISO C++ 2017 and ISO 
C++ 2020.
 
 Wc++11-extensions
diff --git a/gcc/testsuite/g++.dg/cpp0x/keywords2.C 
b/gcc/testsuite/g++.dg/cpp0x/keywords2.C
new file mode 100644
index 000..d67d01e31ed
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/keywords2.C
@@ -0,0 +1,16 @@
+// { dg-do compile { target c++98_only } }
+// { dg-options "-Wc++11-compat" }
+
+// Validate suppression of -Wc++11-compat diagnostics.
+#pragma GCC diagnostic ignored "-Wc++11-compat"
+int alignof;
+int alignas;
+int constexpr;
+int decltype;
+int noexcept;
+int nullptr;
+int static_assert;
+int thread_local;
+int _Alignas;
+int _Alignof;
+int _Thread_local;
diff --git a/gcc/testsuite/g++.dg/cpp2a/keywords2.C 
b/gcc/testsuite/g++.dg/cpp2a/keywords2.C
new file mode 100644
index 000..8714a7b26b7
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/keywords2.C
@@ -0,0 +1,13 @@
+// { dg-do compile { target c++17_down } }
+// { dg-options "-Wc++20-compat" }
+
+// Validate suppression of -Wc++20-compat diagnostics.
+#pragma GCC diagnostic ignored "-Wc++20-compat"
+int constinit;
+int consteval;
+int requires;
+int concept;
+int co_await;
+int co_yield;
+int co_return;
+int char8_t;
diff --git a/libcpp/include/cpplib.h b/libcpp/include/cpplib.h
index 3eba6f74b57..9d90c18e4f2 100644
--- a/libcpp/include/cpplib.h
+++ b/libcpp/include/cpplib.h
@@ -547,6 +547,9 @@ struct cpp_options
   /* True if warn about differences between C++98 and C++11.  */
   bool cpp_warn_cxx11_compat;
 
+  /* True if warn about differences between C++17 and C++20.  */
+  bool cpp_warn_cxx20_compat;
+
   /* Nonzero if bidirectional control characters checking is on.  See enum
  cpp_bidirectional_level.  */
   unsigned char cpp_warn_bidirectional;
@@ -655,6 +658,7 @@ enum cpp_warning_reason {
   CPP_W_C90_C99_COMPAT,
   CPP_W_C11_C2X_COMPAT,
   CPP_W_CXX11_COMPAT,
+  

[PATCH 0/1] c++/106423: Fix pragma suppression of -Wc++20-compat diagnostics

2022-07-23 Thread Tom Honermann via Gcc-patches
This change addresses the following issue raised on the libc-alpha mailing list:
  https://sourceware.org/pipermail/libc-alpha/2022-July/140825.html
Glibc 2.36 adds a char8_t typedef in C++ modes that do not enable the char8_t
builtin type (C++17 and earlier by default; subject to _GNU_SOURCE and use of
the -f[no-]char8_t option).  When -Wc++20-compat diagnostics are enabled, the
following warning is issued from the glibc uchar.h header.
  warning: identifier ‘char8_t’ is a keyword in C++20 [-Wc++20-compat]
Such diagnostics are not desired from system headers, so glibc would like to
suppress the diagnostic using '#pragma GCC diagnostic ignored "-Wc++20-compat"',
but attempting to do so currently fails.  This patch corrects that.

Tom Honermann (1):
  c++/106423: Fix pragma suppression of -Wc++20-compat diagnostics.

 gcc/c-family/c-opts.cc |  7 +++
 gcc/c-family/c.opt |  2 +-
 gcc/testsuite/g++.dg/cpp0x/keywords2.C | 16 
 gcc/testsuite/g++.dg/cpp2a/keywords2.C | 13 +
 libcpp/include/cpplib.h|  4 
 libcpp/init.cc |  1 +
 6 files changed, 42 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/keywords2.C
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/keywords2.C

-- 
2.32.0



Re: [PATCH] analyzer: add get_meaning_for_state_change vfunc to fd_diagnostic in sm-fd.cc [PR106286]

2022-07-23 Thread David Malcolm via Gcc-patches
On Sat, 2022-07-23 at 22:08 +0530, Immad Mir wrote:
> This patch adds get_meaning_for_state_change vfunc to
> fd_diagnostic in sm-fd.cc which could be used by SARIF output.
> 
> Lightly tested in x86_64 Linux.
> 
> gcc/analyzer/ChangeLog:
> PR analyzer/106286
> * sm-fd.cc:
> (fd_diagnostic::get_meaning_for_state_change): New.
> 
> Signed-off-by: Immad Mir 
> ---
>  gcc/analyzer/sm-fd.cc | 16 
>  1 file changed, 16 insertions(+)
> 
> diff --git a/gcc/analyzer/sm-fd.cc b/gcc/analyzer/sm-fd.cc
> index c3dac48509e..f77b1f4d3e2 100644
> --- a/gcc/analyzer/sm-fd.cc
> +++ b/gcc/analyzer/sm-fd.cc
> @@ -229,6 +229,22 @@ public:
>  return label_text ();
>    }
>  
> +  diagnostic_event::meaning
> +  get_meaning_for_state_change (
> +  const evdesc::state_change &change) const final override
> +  {
> +    if (change.m_old_state == m_sm.get_start_state ()
> +    && (change.m_new_state == m_sm.m_unchecked_read_write
> +    || change.m_new_state == m_sm.m_unchecked_read_only
> +    || change.m_new_state == m_sm.m_unchecked_write_only))

I think you can simplify this by using:

   m_sm.is_unchecked_fd_p (change.m_new_state)

for the right-hand side of the &&.


[...snip...]

Other than that, patch looks OK, but please add a test case for this
e.g. "fd-meaning.c"; see:

  gcc/testsuite/gcc.dg/analyzer/file-meaning-1.c

for an analogous one for the sm-file.cc (since otherwise it's too easy
for this kind of thing to regress).

Dave



[PATCH] analyzer: add get_meaning_for_state_change vfunc to fd_diagnostic in sm-fd.cc [PR106286]

2022-07-23 Thread Immad Mir via Gcc-patches
This patch adds get_meaning_for_state_change vfunc to
fd_diagnostic in sm-fd.cc which could be used by SARIF output.

Lightly tested in x86_64 Linux.

gcc/analyzer/ChangeLog:
PR analyzer/106286
* sm-fd.cc:
(fd_diagnostic::get_meaning_for_state_change): New.

Signed-off-by: Immad Mir 
---
 gcc/analyzer/sm-fd.cc | 16 
 1 file changed, 16 insertions(+)

diff --git a/gcc/analyzer/sm-fd.cc b/gcc/analyzer/sm-fd.cc
index c3dac48509e..f77b1f4d3e2 100644
--- a/gcc/analyzer/sm-fd.cc
+++ b/gcc/analyzer/sm-fd.cc
@@ -229,6 +229,22 @@ public:
 return label_text ();
   }
 
+  diagnostic_event::meaning
+  get_meaning_for_state_change (
+  const evdesc::state_change &change) const final override
+  {
+if (change.m_old_state == m_sm.get_start_state ()
+&& (change.m_new_state == m_sm.m_unchecked_read_write
+|| change.m_new_state == m_sm.m_unchecked_read_only
+|| change.m_new_state == m_sm.m_unchecked_write_only))
+  return diagnostic_event::meaning (diagnostic_event::VERB_acquire,
+diagnostic_event::NOUN_resource);
+if (change.m_new_state == m_sm.m_closed)
+  return diagnostic_event::meaning (diagnostic_event::VERB_release,
+diagnostic_event::NOUN_resource);
+return diagnostic_event::meaning ();
+  }
+
 protected:
   const fd_state_machine &m_sm;
   tree m_arg;
-- 
2.25.1



[Documentation] Correct RTL documentation: (use (mem ...)) is allowed.

2022-07-23 Thread Roger Sayle

This patch is a one line correction/clarification to GCC's current
RTL documentation that explains a USE of a MEM is permissible.

PR rtl-optimization/99930 is an interesting example on x86_64 where
the backend generates better code when a USE is a (const) MEM than
when it is a REG. In fact the backend relies on CSE to propagate the
MEM (a constant pool reference) into the USE, to enable combine to
merge/simplify instructions.

This change has been tested with a make bootstrap, but as it might
provoke a discussion, I've decided to not consider it "obvious".
Ok for mainline (to document the actual current behavior)?


2022-07-23  Roger Sayle   

gcc/ChangeLog
* doc/rtl.texi (use): Document that the operand may be a MEM.


Roger
--

diff --git a/gcc/doc/rtl.texi b/gcc/doc/rtl.texi
index 43c9ee8..995c8be 100644
--- a/gcc/doc/rtl.texi
+++ b/gcc/doc/rtl.texi
@@ -3283,7 +3283,8 @@ Represents the use of the value of @var{x}.  It indicates 
that the
 value in @var{x} at this point in the program is needed, even though
 it may not be apparent why this is so.  Therefore, the compiler will
 not attempt to delete previous instructions whose only effect is to
-store a value in @var{x}.  @var{x} must be a @code{reg} expression.
+store a value in @var{x}.  @var{x} must be a @code{reg} or a @code{mem}
+expression.
 
 In some situations, it may be tempting to add a @code{use} of a
 register in a @code{parallel} to describe a situation where the value


[x86 PATCH take #3] PR target/91681: zero_extendditi2 pattern for more optimizations.

2022-07-23 Thread Roger Sayle
 

Hi Uros,

This is the next iteration of the zero_extendditi2 patch last reviewed here:

https://gcc.gnu.org/pipermail/gcc-patches/2022-June/596204.html

 

[1] The sse.md changes were split out, reviewed, approved and committed.

[2] The *concat splitters have been moved post-reload matching what we

now do for many/most of the double word functionality.

[3] As you recommend, these *concat splitters now use split_double_mode

to "subreg" operand[0] into parts, via a new helper function that can also

handle overlapping registers, and even use xchg for the rare case that a

double word is constructed from its high and low parts, but the wrong

way around.

 

This patch has been tested on x86_64-pc-linux-gnu with make bootstrap

and make -k check, both with and without -target_board=unix{-m32},

with no new failures.  Ok for mainline?

 

2022-07-23  Roger Sayle  

Uroš Bizjak  

 

gcc/ChangeLog

PR target/91681

* config/i386/i386-expand.cc (split_double_concat): A new helper

function for setting a double word value from two word values.

* config/i386/i386-protos.h (split_double_concat): Prototype here.

* config/i386/i386.md (zero_extendditi2): New define_insn_and_split.

(*add3_doubleword_zext): New define_insn_and_split.

(*sub3_doubleword_zext): New define_insn_and_split.

(*concat3_1): New define_insn_and_split replacing

previous define_split for implementing DST = (HI<<32)|LO as

pair of move instructions, setting lopart and hipart.

(*concat3_2): Likewise.

(*concat3_3): Likewise, where HI is zero_extended.

(*concat3_4): Likewise, where HI is zero_extended.

 

gcc/testsuite/ChangeLog

PR target/91681

* g++.target/i386/pr91681.C: New test case (from the PR).

* gcc.target/i386/pr91681-1.c: New int128 test case.

* gcc.target/i386/pr91681-2.c: Likewise.

* gcc.target/i386/pr91681-3.c: Likewise, but for ia32.

 

 

Thanks in advance,

Roger

--

 

diff --git a/gcc/config/i386/i386-expand.cc b/gcc/config/i386/i386-expand.cc
index 40f821e..66d8f28 100644
--- a/gcc/config/i386/i386-expand.cc
+++ b/gcc/config/i386/i386-expand.cc
@@ -165,6 +165,46 @@ split_double_mode (machine_mode mode, rtx operands[],
 }
 }
 
+/* Emit the double word assignment DST = { LO, HI }.  */
+
+void
+split_double_concat (machine_mode mode, rtx dst, rtx lo, rtx hi)
+{
+  rtx dlo, dhi;
+  int deleted_move_count = 0;
+  split_double_mode (mode, &dst, 1, &dlo, &dhi);
+  if (!rtx_equal_p (dlo, hi))
+{
+  if (!rtx_equal_p (dlo, lo))
+   emit_move_insn (dlo, lo);
+  else
+   deleted_move_count++;
+  if (!rtx_equal_p (dhi, hi))
+   emit_move_insn (dhi, hi);
+  else
+   deleted_move_count++;
+}
+  else if (!rtx_equal_p (lo, dhi))
+{
+  if (!rtx_equal_p (dhi, hi))
+   emit_move_insn (dhi, hi);
+  else
+   deleted_move_count++;
+  if (!rtx_equal_p (dlo, lo))
+   emit_move_insn (dlo, lo);
+  else
+   deleted_move_count++;
+}
+  else if (mode == TImode)
+emit_insn (gen_swapdi (dlo, dhi));
+  else
+emit_insn (gen_swapsi (dlo, dhi));
+
+  if (deleted_move_count == 2)
+emit_note (NOTE_INSN_DELETED);
+}
+
+
 /* Generate either "mov $0, reg" or "xor reg, reg", as appropriate
for the target.  */
 
diff --git a/gcc/config/i386/i386-protos.h b/gcc/config/i386/i386-protos.h
index cf84775..e27c14f 100644
--- a/gcc/config/i386/i386-protos.h
+++ b/gcc/config/i386/i386-protos.h
@@ -85,6 +85,7 @@ extern void print_reg (rtx, int, FILE*);
 extern void ix86_print_operand (FILE *, rtx, int);
 
 extern void split_double_mode (machine_mode, rtx[], int, rtx[], rtx[]);
+extern void split_double_concat (machine_mode, rtx, rtx lo, rtx);
 
 extern const char *output_set_got (rtx, rtx);
 extern const char *output_387_binary_op (rtx_insn *, rtx*);
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index 9aaeb69..4560681 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -4379,6 +4379,16 @@
(set_attr "type" "imovx,mskmov,mskmov")
(set_attr "mode" "SI,QI,QI")])
 
+(define_insn_and_split "zero_extendditi2"
+  [(set (match_operand:TI 0 "nonimmediate_operand" "=r,o")
+   (zero_extend:TI (match_operand:DI 1 "nonimmediate_operand" "rm,r")))]
+  "TARGET_64BIT"
+  "#"
+  "&& reload_completed"
+  [(set (match_dup 3) (match_dup 1))
+   (set (match_dup 4) (const_int 0))]
+  "split_double_mode (TImode, &operands[0], 1, &operands[3], &operands[4]);")
+
 ;; Transform xorl; mov[bw] (set strict_low_part) into movz[bw]l.
 (define_peephole2
   [(parallel [(set (match_operand:SWI48 0 "general_reg_operand")
@@ -6512,6 +6522,31 @@
   [(set_attr "type" "alu")
(set_attr "mode" "QI")])
 
+(define_insn_and_split "*add3_doubleword_zext"
+  [(set (match_operand: 0 "nonimmediate_operand" "=r,o")
+   (plus:
+ (zero_extend:
+   (match_operand:DWIH 2 "nonimmediate_operand

[PATCH] libgccjit.h: Make the macro definition for testing gcc_jit_context_new_bitcast correctly available.

2022-07-23 Thread Vibhav Pant via Gcc-patches
The macro definition for LIBGCCJIT_HAVE_gcc-jit_context_new_bitcast
was earlier located in the documentation comment for
gcc_jit_context_new_bitcast, making it unavailable to code that
consumed libgccjit.h. This patch moves the definition out of the
comment, making it effective.

Thanks,
Vibhav

-- 
Vibhav Pant
vibh...@gmail.com

GPG: 7ED1 D48C 513C A024 BE3A 785F E3FB 28CB 6AB5 9598

From 13f7b010962d57a9a133b657838727486e4241c9 Mon Sep 17 00:00:00 2001
From: Vibhav Pant 
Date: Sat, 23 Jul 2022 13:18:05 +0530
Subject: [[PATCH] libgccjit.h: Make the macro definition for testing gcc_jit_context_new_bitcast correctly available.] 
 Uncomment macro definition for testing gcc_jit_context_new_bitcast support

The macro definition for LIBGCCJIT_HAVE_gcc-jit_context_new_bitcast
was earlier located in the documentation comment for
gcc_jit_context_new_bitcast, making it unavailable to code that
consumed libgccjit.h. This commit moves the definition out of the
comment, making it effective.
---
 gcc/jit/libgccjit.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/jit/libgccjit.h b/gcc/jit/libgccjit.h
index 062f06d691a..b3c389e93f6 100644
--- a/gcc/jit/libgccjit.h
+++ b/gcc/jit/libgccjit.h
@@ -1252,10 +1252,10 @@ gcc_jit_context_new_cast (gcc_jit_context *ctxt,
 			  gcc_jit_rvalue *rvalue,
 			  gcc_jit_type *type);
 
-/* Reinterpret a value as another type.
-
 #define LIBGCCJIT_HAVE_gcc_jit_context_new_bitcast
 
+/* Reinterpret a value as another type.
+
The types must be of the same size.
 
This API entrypoint was added in LIBGCCJIT_ABI_21; you can test for its
-- 
2.37.1



signature.asc
Description: This is a digitally signed message part


[x86 PATCH] PR target/106303: Fix TImode STV related failures.

2022-07-23 Thread Roger Sayle

This patch resolves PR target/106303 (and the related PRs 106347,
106404, 106407) which are ICEs caused by my improvements to x86_64's
128-bit TImode to V1TImode Scalar to Vector (STV) pass.  My apologies
for the breakage.  The issue is that data flow analysis is used to
partition usage of each TImode pseudo into "chains", where each
chain is analyzed and if suitable converted to vector operations.
The problems appears when some chains for a pseudo are converted,
and others aren't as RTL sharing can result in some mode changes
leaking into other instructions that aren't/shouldn't/can't be
converted, which eventually leads to an ICE for mismatched modes.

My first approach to a fix was to unify more of the STV infrastructure,
reasoning that if TImode STV was exhibiting these problems, but DImode
and SImode STV weren't, the issue was likely to be caused/resolved by
these remaining differences.  This appeared to fix some but not all of
the reported PRs.  A better solution was then proposed by H.J. Lu in
Bugzilla (thanks!) that we need to iterate the removal of candidates in the
function timode_remove_non_convertible_regs until there are no further
changes.  As each chain is removed from consideration, it in turn may
affect whether other insns/chains can safely be converted.

This patch has been tested on x86_64-pc-linux-gnu with make bootstrap
and make -k check, both with and without --target_board=unix{-m32},
with no new failures.  Ok for mainline?


2022-07-23  Roger Sayle  
H.J. Lu  

gcc/ChangeLog
PR target/106303
PR target/106347
* config/i386/i386-features.cc (make_vector_copies): Move from
general_scalar_chain to scalar_chain.
(convert_reg): Likewise.
(convert_insn_common): New scalar_chain method split out from
general_scalar_chain convert_insn.
(convert_registers): Move from general_scalar_chain to
scalar_chain.
(scalar_chain::convert): Call convert_insn_common before calling
convert_insn.
(timode_remove_non_convertible_regs): Iterate until there are
no further changes to the candidates.
* config/i386/i386-features.h (scalar_chain::hash_map): Move
from general_scalar_chain.
(scalar_chain::convert_reg): Likewise.
(scalar_chain::convert_insn_common): New shared method.
(scalar_chain::make_vector_copies): Move from general_scalar_chain.
(scalar_chain::convert_registers): Likewise.  No longer virtual.
(general_scalar_chain::hash_map): Delete.  Moved to scalar_chain.
(general_scalar_chain::convert_reg): Likewise.
(general_scalar_chain::make_vector_copies): Likewise.
(general_scalar_chain::convert_registers): Delete virtual method.
(timode_scalar_chain::convert_registers): Likewise.

gcc/testsuite/ChangeLog
PR target/106303
PR target/106347
* gcc.target/i386/pr106303.c: New test case.
* gcc.target/i386/pr106347.c: New test case.


Thanks in advance (and sorry again for the inconvenience),
Roger
--

diff --git a/gcc/config/i386/i386-features.cc b/gcc/config/i386/i386-features.cc
index 813b203..aa5de71 100644
--- a/gcc/config/i386/i386-features.cc
+++ b/gcc/config/i386/i386-features.cc
@@ -708,7 +708,7 @@ gen_gpr_to_xmm_move_src (enum machine_mode vmode, rtx gpr)
and replace its uses in a chain.  */
 
 void
-general_scalar_chain::make_vector_copies (rtx_insn *insn, rtx reg)
+scalar_chain::make_vector_copies (rtx_insn *insn, rtx reg)
 {
   rtx vreg = *defs_map.get (reg);
 
@@ -772,7 +772,7 @@ general_scalar_chain::make_vector_copies (rtx_insn *insn, 
rtx reg)
scalar uses outside of the chain.  */
 
 void
-general_scalar_chain::convert_reg (rtx_insn *insn, rtx dst, rtx src)
+scalar_chain::convert_reg (rtx_insn *insn, rtx dst, rtx src)
 {
   start_sequence ();
   if (!TARGET_INTER_UNIT_MOVES_FROM_VEC)
@@ -973,10 +973,10 @@ scalar_chain::convert_compare (rtx op1, rtx op2, rtx_insn 
*insn)
 UNSPEC_PTEST);
 }
 
-/* Convert INSN to vector mode.  */
+/* Helper function for converting INSN to vector mode.  */
 
 void
-general_scalar_chain::convert_insn (rtx_insn *insn)
+scalar_chain::convert_insn_common (rtx_insn *insn)
 {
   /* Generate copies for out-of-chain uses of defs and adjust debug uses.  */
   for (df_ref ref = DF_INSN_DEFS (insn); ref; ref = DF_REF_NEXT_LOC (ref))
@@ -1037,7 +1037,13 @@ general_scalar_chain::convert_insn (rtx_insn *insn)
XEXP (note, 0) = *vreg;
  *DF_REF_REAL_LOC (ref) = *vreg;
}
+}
+
+/* Convert INSN to vector mode.  */
 
+void
+general_scalar_chain::convert_insn (rtx_insn *insn)
+{
   rtx def_set = single_set (insn);
   rtx src = SET_SRC (def_set);
   rtx dst = SET_DEST (def_set);
@@ -1475,7 +1481,7 @@ timode_scalar_chain::convert_insn (rtx_insn *insn)
Also populates defs_map which is used later by convert_insn.  */
 
 void
-general_scalar_chain::convert_registers ()
+scalar_chain::convert_re