[PATCH] RISC-V: Canonicalize --with-arch

[Kito Cheng]

 - We would like to canonicalize the arch string for --with-arch for
   easier handling multilib, so split canonicalization part to a stand
   along script to shared the logic.

gcc/ChangeLog:

* config/riscv/multilib-generator (arch_canonicalize): Move
code to arch-canonicalize, and call that script to canonicalize arch
string.
(canonical_order): Move code to arch-canonicalize.
(LONG_EXT_PREFIXES): Ditto.
(IMPLIED_EXT): Ditto.
* config/riscv/arch-canonicalize: New.
* config.gcc (riscv*-*-*): Canonicalize --with-arch.
---
 gcc/config.gcc  |   1 +
 gcc/config/riscv/arch-canonicalize  | 102 
 gcc/config/riscv/multilib-generator |  83 +++---
 3 files changed, 111 insertions(+), 75 deletions(-)
 create mode 100755 gcc/config/riscv/arch-canonicalize

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 4808b698f3a..c348596b1ac 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -4615,6 +4615,7 @@ case "${target}" in
exit 1
;;
esac
+   with_arch=`${srcdir}/config/riscv/arch-canonicalize 
${with_arch}`
tm_defines="${tm_defines} 
TARGET_RISCV_DEFAULT_ARCH=${with_arch}"
 
# Make sure --with-abi is valid.  If it was not specified,
diff --git a/gcc/config/riscv/arch-canonicalize 
b/gcc/config/riscv/arch-canonicalize
new file mode 100755
index 000..2b4289e320d
--- /dev/null
+++ b/gcc/config/riscv/arch-canonicalize
@@ -0,0 +1,102 @@
+#!/usr/bin/env python
+
+# Tool for canonical RISC-V architecture string.
+# Copyright (C) 2011-2020 Free Software Foundation, Inc.
+# Contributed by Andrew Waterman (and...@sifive.com).
+#
+# This file is part of GCC.
+#
+# GCC is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3, or (at your option)
+# any later version.
+#
+# GCC is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with GCC; see the file COPYING3.  If not see
+# .
+
+
+from __future__ import print_function
+import sys
+import collections
+import itertools
+from functools import reduce
+
+
+CANONICAL_ORDER = "mafdgqlcbjtpvn"
+LONG_EXT_PREFIXES = ['z', 's', 'h', 'x']
+
+#
+# IMPLIED_EXT(ext) -> implied extension list.
+#
+IMPLIED_EXT = {
+  "d" : ["f"],
+}
+
+def arch_canonicalize(arch):
+  # TODO: Support extension version.
+  new_arch = ""
+  if arch[:5] in ['rv32e', 'rv32i', 'rv32g', 'rv64i', 'rv64g']:
+# TODO: We should expand g to imad_zifencei once we support newer spec.
+new_arch = arch[:5].replace("g", "imafd")
+  else:
+raise Exception("Unexpected arch: `%s`" % arch[:5])
+
+  # Find any Z, S, H or X
+  long_ext_prefixes_idx = map(lambda x: arch.find(x), LONG_EXT_PREFIXES)
+
+  # Filter out any non-existent index.
+  long_ext_prefixes_idx = list(filter(lambda x: x != -1, 
long_ext_prefixes_idx))
+  if long_ext_prefixes_idx:
+first_long_ext_idx = min(long_ext_prefixes_idx)
+long_exts = arch[first_long_ext_idx:].split("_")
+std_exts = list(arch[5:first_long_ext_idx])
+  else:
+long_exts = []
+std_exts = list(arch[5:])
+
+  #
+  # Handle implied extensions.
+  #
+  for ext in std_exts + long_exts:
+if ext in IMPLIED_EXT:
+  implied_exts = IMPLIED_EXT[ext]
+  for implied_ext in implied_exts:
+if implied_ext not in std_exts + long_exts:
+  long_exts.append(implied_ext)
+
+  # Single letter extension might appear in the long_exts list,
+  # becasue we just append extensions list to the arch string.
+  std_exts += list(filter(lambda x:len(x) == 1, long_exts))
+
+  # Multi-letter extension must be in lexicographic order.
+  long_exts = list(sorted(filter(lambda x:len(x) != 1, long_exts)))
+
+  # Put extensions in canonical order.
+  for ext in CANONICAL_ORDER:
+if ext in std_exts:
+  new_arch += ext
+
+  # Check every extension is processed.
+  for ext in std_exts:
+if ext == '_':
+  continue
+if ext not in CANONICAL_ORDER:
+  raise Exception("Unsupported extension `%s`" % ext)
+
+  # Concat rest of the multi-char extensions.
+  if long_exts:
+new_arch += "_" + "_".join(long_exts)
+  return new_arch
+
+if len(sys.argv) < 2:
+  print ("Usage: %s  [*]" % sys.argv)
+  sys.exit(1)
+
+for arg in sys.argv[1:]:
+  print (arch_canonicalize(arg))
diff --git a/gcc/config/riscv/multilib-generator 
b/gcc/config/riscv/multilib-generator
index 0d9ebcb321f..53c51dfa53f 100755
--- a/gcc/config/riscv/multilib-generator
+++ b/gcc/config/riscv/multilib-generator
@@ -35,9 +35,11 @@
 
 from __future__ import print

[PATCH] loop-invariant: JUMP_INSNs aren't loop invariant [PR97954]

[Jakub Jelinek via Gcc-patches]

Hi!

The following testcase ICEs because loop invariant motion moves asm goto
with a single output as invariant.
Normally, jumps aren't really moved, because if they are single set,
they have their SET_DEST (pc) and pc_rtx has VOIDmode on which one of the
functions find_invariant_insn calls bails out.  The code already punts on
insns that can throw or trap.  And for asm goto without outputs, it isn't
single set, or asm goto with two or more outputs it isn't single set either.

Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?

2020-12-01  Jakub Jelinek  

PR rtl-optimization/97954
* loop-invariant.c (find_invariant_insn): Punt on JUMP_P insns.

* gcc.dg/pr97954.c: New test.

--- gcc/loop-invariant.c.jj 2020-01-12 11:54:36.0 +0100
+++ gcc/loop-invariant.c2020-11-30 09:56:37.022696142 +0100
@@ -1099,6 +1099,10 @@ find_invariant_insn (rtx_insn *insn, boo
   if (HAVE_cc0 && sets_cc0_p (insn))
 return;
 
+  /* Jumps have control flow side-effects.  */
+  if (JUMP_P (insn))
+return;
+
   set = single_set (insn);
   if (!set)
 return;
--- gcc/testsuite/gcc.dg/pr97954.c.jj   2020-11-30 10:31:54.870891248 +0100
+++ gcc/testsuite/gcc.dg/pr97954.c  2020-11-30 10:31:08.875407984 +0100
@@ -0,0 +1,12 @@
+/* PR rtl-optimization/97954 */
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+
+int
+foo (void)
+{
+  int x;
+ lab:
+  asm goto ("": "=r" (x) : : : lab);
+  return x;
+}

Jakub

[PATCH] x86_64: Fix up -fpic -mcmodel=large -fno-plt [PR98063]

[Jakub Jelinek via Gcc-patches]

Hi!

On the following testcase with -fpic -mcmodel=large -fno-plt we emit
call puts@GOTPCREL(%rip)
but that is not really appropriate for CM_LARGE_PIC, the .text can be larger
than 2GB in that case and the .got slot further away from %rip than what can
fit into the signed 32-bit immediate.

The following patch computes the address of the .got slot the way it is
computed for that model for function pointer loads, and calls that.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2020-12-01  Jakub Jelinek  

PR target/98063
* config/i386/i386-expand.c (ix86_expand_call): Handle non-plt
CM_LARGE_PIC calls.

* gcc.target/i386/pr98063.c: New test.

--- gcc/config/i386/i386-expand.c.jj2020-11-26 16:22:29.091353066 +0100
+++ gcc/config/i386/i386-expand.c   2020-11-30 12:55:52.936300739 +0100
@@ -8063,7 +8063,17 @@ ix86_expand_call (rtx retval, rtx fnaddr
}
  else if (!TARGET_PECOFF && !TARGET_MACHO)
{
- if (TARGET_64BIT)
+ if (TARGET_64BIT
+ && ix86_cmodel == CM_LARGE_PIC
+ && DEFAULT_ABI != MS_ABI)
+   {
+ fnaddr = gen_rtx_UNSPEC (Pmode, gen_rtvec (1, addr),
+  UNSPEC_GOT);
+ fnaddr = gen_rtx_CONST (Pmode, fnaddr);
+ fnaddr = force_reg (Pmode, fnaddr);
+ fnaddr = gen_rtx_PLUS (Pmode, pic_offset_table_rtx, fnaddr);
+   }
+ else if (TARGET_64BIT)
{
  fnaddr = gen_rtx_UNSPEC (Pmode,
   gen_rtvec (1, addr),
--- gcc/testsuite/gcc.target/i386/pr98063.c.jj  2020-11-30 13:00:31.699214198 
+0100
+++ gcc/testsuite/gcc.target/i386/pr98063.c 2020-11-30 13:24:05.352485291 
+0100
@@ -0,0 +1,13 @@
+/* PR target/98063 */
+/* { dg-do run { target { i?86-*-linux* x86_64-*-linux* } } } */
+/* { dg-require-effective-target lp64 } */
+/* { dg-require-effective-target fpic } */
+/* { dg-options "-O2 -fpic -mcmodel=large -fno-plt -save-temps" } */
+/* { dg-final { scan-assembler-not "puts@GOTPCREL" } } */
+
+int
+main ()
+{
+  __builtin_puts ("Hello, world!");
+  return 0;
+}

Jakub

[PATCH] c++: Implement LWG3396 Clarify point of reference for source_location::current() [PR80780, PR93093]

[Jakub Jelinek via Gcc-patches]

Hi!

While std::source_location::current () is static consteval source_location
current() noexcept; in the standard, it also says with LWG3396:
"Any call to current that appears as a default member initializer
([class.mem]), or as a subexpression thereof, should correspond to the
location of the constructor definition or aggregate initialization that uses
the default member initializer.  Any call to current that appears as a
default argument ([dcl.fct.default]), or as a subexpression thereof, should
correspond to the location of the invocation of the function that uses the
default argument ([expr.call])."
so it must work as compiler magic rather than normal immediate functions,
in particular we need to defer its evaluation when parsing default arguments
or nsdmis.

The following patch implements that.

Bootstrapped/regtested on x86_64-linux and i686-linux.

Jon, does it fix all the library testcases you and JeanHeyd had?

2020-12-01  Jakub Jelinek  

LWG3396 Clarify point of reference for source_location::current()
PR c++/80780
PR c++/93093
* cp-tree.h (source_location_current_p): Declare.
* tree.c (source_location_current_p): New function.
(bot_manip): Resolve deferred calls to immediate function
std::source_location::current ().
* call.c (build_over_call): Don't evaluate calls to immediate
function std::source_location::current () in default arguments
or when parsing nsdmi.

* g++.dg/cpp2a/srcloc15.C: New test.
* g++.dg/cpp2a/srcloc16.C: New test.

--- gcc/cp/cp-tree.h.jj 2020-11-26 16:22:24.252407018 +0100
+++ gcc/cp/cp-tree.h2020-11-30 19:45:36.784286305 +0100
@@ -7413,6 +7413,7 @@ extern tree bind_template_template_parm
 extern tree array_type_nelts_total (tree);
 extern tree array_type_nelts_top   (tree);
 extern bool array_of_unknown_bound_p   (const_tree);
+extern bool source_location_current_p  (tree);
 extern tree break_out_target_exprs (tree, bool = false);
 extern tree build_ctor_subob_ref   (tree, tree, tree);
 extern tree replace_placeholders   (tree, tree, bool * = NULL);
--- gcc/cp/tree.c.jj2020-11-26 16:22:24.264406884 +0100
+++ gcc/cp/tree.c   2020-11-30 19:53:58.034686074 +0100
@@ -2968,6 +2968,37 @@ array_type_nelts_total (tree type)
   return sz;
 }
 
+/* Return true if FNDECL is std::source_location::current () method.  */
+
+bool
+source_location_current_p (tree fndecl)
+{
+  gcc_checking_assert (TREE_CODE (fndecl) == FUNCTION_DECL
+  && DECL_IMMEDIATE_FUNCTION_P (fndecl));
+  if (DECL_NAME (fndecl) == NULL_TREE
+  || TREE_CODE (TREE_TYPE (fndecl)) != FUNCTION_TYPE
+  || TREE_CODE (TREE_TYPE (TREE_TYPE (fndecl))) != RECORD_TYPE
+  || DECL_CONTEXT (fndecl) != TREE_TYPE (TREE_TYPE (fndecl)))
+return false;
+
+  if (strcmp (IDENTIFIER_POINTER (DECL_NAME (fndecl)), "current") != 0)
+return false;
+
+  tree source_location = DECL_CONTEXT (fndecl);
+  if (TYPE_NAME (source_location) == NULL_TREE
+  || TREE_CODE (TYPE_NAME (source_location)) != TYPE_DECL
+  || DECL_NAME (TYPE_NAME (source_location)) == NULL_TREE
+  || strcmp (IDENTIFIER_POINTER (DECL_NAME (TYPE_NAME (source_location))),
+"source_location") != 0)
+return false;
+
+  tree decl
+= lookup_qualified_name (std_node,
+DECL_NAME (TYPE_NAME (source_location)),
+LOOK_want::TYPE, tf_none);
+  return TYPE_NAME (source_location) == decl;
+}
+
 struct bot_data
 {
   splay_tree target_remap;
@@ -3064,6 +3095,38 @@ bot_manip (tree* tp, int* walk_subtrees,
   set_flags_from_callee (*tp);
   if (data.clear_location && EXPR_HAS_LOCATION (*tp))
 SET_EXPR_LOCATION (*tp, input_location);
+  if (TREE_CODE (*tp) == CALL_EXPR
+  && !processing_template_decl
+  && (current_function_decl == NULL_TREE
+ || !DECL_IMMEDIATE_FUNCTION_P (current_function_decl)))
+if (tree fndecl = cp_get_callee_fndecl_nofold (*tp))
+  if (DECL_IMMEDIATE_FUNCTION_P (fndecl)
+ && source_location_current_p (fndecl))
+   {
+ bool ok = call_expr_nargs (*tp) == 0;
+ if (call_expr_nargs (*tp) == 1
+ && TREE_CODE (CALL_EXPR_ARG (*tp, 0)) == CALL_EXPR)
+   if (tree fndecl2
+   = cp_get_callee_fndecl_nofold (CALL_EXPR_ARG (*tp, 0)))
+ if (fndecl_built_in_p (fndecl2, CP_BUILT_IN_SOURCE_LOCATION,
+BUILT_IN_FRONTEND))
+   ok = true;
+ if (!ok)
+   {
+ error_at (EXPR_LOCATION (*tp),
+   "%qD called with arguments", fndecl);
+ *tp = build_constructor (TREE_TYPE (TREE_TYPE (fndecl)),
+  NULL);
+   }
+ else
+   {
+ vec *args = NULL;
+ push_deferring_access_checks (dk_no_check);
+ 

[PATCH 1/2] Add TARGET_COMPUTE_MULTILIB hook to override multi-lib result.

[Kito Cheng]

Create a new hook to let target could override the multi-lib result,
the motivation is RISC-V might have very complicated multi-lib re-use
rule*, which is hard to maintain and use current multi-lib scripts,
we even hit the "argument list too long" error when we tried to add more
multi-lib reuse rule.

So I think it would be great to have a target specific way to determine
the multi-lib re-use rule, then we could write those rule in C, instead
of expand every possible case in MULTILIB_REUSE.

* Here is an example for RISC-V multi-lib rules:
https://gist.github.com/kito-cheng/0289cd42d9a756382e5afeb77b42b73b

gcc/ChangeLog:

* common/common-target.def (compute_multilib): New.
* common/common-targhooks.c (default_compute_multilib): New.
* doc/tm.texi.in (TARGET_COMPUTE_MULTILIB): New.
* doc/tm.texi: Regen.
* gcc.c: Include common/common-target.h.
(set_multilib_dir) Call targetm_common.compute_multilib.
(SWITCH_LIVE): Move to opts.h.
(SWITCH_FALSE): Ditto.
(SWITCH_IGNORE): Ditto.
(SWITCH_IGNORE_PERMANENTLY): Ditto.
(SWITCH_KEEP_FOR_GCC): Ditto.
(struct switchstr): Ditto.
* opts.h (SWITCH_LIVE): Move from gcc.c.
(SWITCH_FALSE): Ditto.
(SWITCH_IGNORE): Ditto.
(SWITCH_IGNORE_PERMANENTLY): Ditto.
(SWITCH_KEEP_FOR_GCC): Ditto.
(struct switchstr): Ditto.
---
 gcc/common/common-target.def  | 25 ++
 gcc/common/common-targhooks.c | 15 +++
 gcc/doc/tm.texi   |  5 
 gcc/doc/tm.texi.in|  3 +++
 gcc/gcc.c | 48 +--
 gcc/opts.h| 36 ++
 6 files changed, 96 insertions(+), 36 deletions(-)

diff --git a/gcc/common/common-target.def b/gcc/common/common-target.def
index 2f64ebe55de..296de01177d 100644
--- a/gcc/common/common-target.def
+++ b/gcc/common/common-target.def
@@ -84,6 +84,31 @@ DEFHOOK
  vec, (int option_code, const char *prefix),
  default_get_valid_option_values)
 
+DEFHOOK
+(compute_multilib,
+ "Some target like RISC-V might have complicated multilib reuse rule which is\
+  hard to implemented on current multilib scheme, this hook allow target to\
+  override the result from built-in multilib mechanism.\
+  @var{switches} is the raw option list with @var{n_switches} items;\
+  @var{multilib_dir} is the multi-lib result which compute by the built-in\
+  multi-lib mechanism;\
+  @var{multilib_defaults} is the default options list for multi-lib; \
+  @var{multilib_select} is the string contain the list of supported multi-lib, 
\
+  and the option checking list. \
+  @var{multilib_matches}, @var{multilib_exclusions}, and @var{multilib_reuse} \
+  are corresponding to @var{MULTILIB_MATCHES}, @var{MULTILIB_EXCLUSIONS} \
+  @var{MULTILIB_REUSE}. \
+  The default definition does nothing but return @var{multilib_dir} directly.",
+ const char *, (const struct switchstr *switches,
+   int n_switches,
+   const char *multilib_dir,
+   const char *multilib_defaults,
+   const char *multilib_select,
+   const char *multilib_matches,
+   const char *multilib_exclusions,
+   const char *multilib_reuse),
+ default_compute_multilib)
+
 /* Leave the boolean fields at the end.  */
 
 /* True if unwinding tables should be generated by default.  */
diff --git a/gcc/common/common-targhooks.c b/gcc/common/common-targhooks.c
index 554ed36c3d2..16a1a35e141 100644
--- a/gcc/common/common-targhooks.c
+++ b/gcc/common/common-targhooks.c
@@ -90,3 +90,18 @@ const struct default_options empty_optimization_table[] =
   {
 { OPT_LEVELS_NONE, 0, NULL, 0 }
   };
+
+/* Default version of TARGET_COMPUTE_MULTILIB.  */
+const char *
+default_compute_multilib(
+  const struct switchstr *,
+  int,
+  const char *multilib,
+  const char *,
+  const char *,
+  const char *,
+  const char *,
+  const char *)
+{
+  return multilib;
+}
diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
index 9f700b1c774..5d3015cb930 100644
--- a/gcc/doc/tm.texi
+++ b/gcc/doc/tm.texi
@@ -758,6 +758,11 @@ options are changed via @code{#pragma GCC optimize} or by 
using the
 Set target-dependent initial values of fields in @var{opts}.
 @end deftypefn
 
+@deftypefn {Common Target Hook} {const char *} TARGET_COMPUTE_MULTILIB (const 
struct switchstr *@var{switches}, int @var{n_switches}, const char 
*@var{multilib_dir}, const char *@var{multilib_defaults}, const char 
*@var{multilib_select}, const char *@var{multilib_matches}, const char 
*@var{multilib_exclusions}, const char *@var{multilib_reuse})
+Some target like RISC-V might have complicated multilib reuse rule which is  
hard to implemented on current multilib scheme, this hook allow target to  
override the result from built-in multilib mechanism.  @var{switches} is the 
raw option list with @var{n_switches} items;  @var{multilib_dir} is the 
multi-lib result

[PATCH 2/2] RISC-V: Implement TARGET_COMPUTE_MULTILIB

[Kito Cheng]

Use TARGET_COMPUTE_MULTILIB to search the multi-lib reuse for riscv*-*-elf*,
according following rules:

 1. Check ABI is same.
 2. Check both has atomic extension or both don't have atomic extension.
- Because mix soft and hard atomic operation doesn't make sense and
  won't work as expect.
 3. Check current arch is superset of the target multi-lib arch.
- It might result slower performance or larger code size, but it
  safe to run.
 4. Pick most match multi-lib set if more than one multi-lib are pass
the above checking.

Example for how to select multi-lib:
  We build code with -march=rv32imaf and -mabi=ilp32, and we have
  following 5 multi-lib set:

1. rv32ia/ilp32
2. rv32ima/ilp32
3. rv32imf/ilp32
4. rv32imaf/ilp32f
5. rv32imafd/ilp32

  The first and second multi-lib is safe to like, 3rd multi-lib can't
  re-use becasue it don't have atomic extension, which is mismatch according
  rule 2, and the 4th multi-lib can't re-use too due to the ABI mismatch,
  the last multi-lib can't use since current arch is not superset of the
  arch of multi-lib.

And emit error if not found suitable multi-lib set, the error message
only emit when link with standard libraries.

Example for when error will be emitted:

  $ riscv64-unknown-elf-gcc -print-multi-lib
  .;
  rv32i/ilp32;@march=rv32i@mabi=ilp32
  rv32im/ilp32;@march=rv32im@mabi=ilp32
  rv32iac/ilp32;@march=rv32iac@mabi=ilp32
  rv32imac/ilp32;@march=rv32imac@mabi=ilp32
  rv32imafc/ilp32f;@march=rv32imafc@mabi=ilp32f
  rv64imac/lp64;@march=rv64imac@mabi=lp64

  // No actual linking, so no error emitted.
  $ riscv64-unknown-elf-gcc -print-multi-directory -march=rv32ia -mabi=ilp32
  .

  // Link to default libc and libgcc, so check the multi-lib, and emit
  // error because not found suitable multilib.
  $ riscv64-unknown-elf-gcc -march=rv32ia -mabi=ilp32 ~/hello.c
  riscv64-unknown-elf-gcc: fatal error: can't found suitable multilib set for 
'-march=rv32ia'/'-mabi=ilp32'
  compilation terminated.

  // No error emitted, because not link to stdlib.
  $ riscv64-unknown-elf-gcc -march=rv32ia -mabi=ilp32 ~/hello.c -nostdlib

  // No error emitted, because compile only.
  $ riscv64-unknown-elf-gcc -march=rv32ia -mabi=ilp32 ~/hello.c -c

gcc/ChangeLog:

* common/config/riscv/riscv-common.c (riscv_subset_list::match_score):
New.
(find_last_appear_switch): Ditto.
(struct multi_lib_info_t): Ditto.
(riscv_no_matched_multi_lib): Ditto.
(riscv_current_arch_str): Ditto.
(riscv_current_abi_str): Ditto.
(riscv_compute_multilib): Ditto.
(TARGET_COMPUTE_MULTILIB): Defined.
* config/riscv/elf.h (LIB_SPEC): Call riscv_multi_lib_check if
doing link.
(RISCV_USE_CUSTOMISED_MULTI_LIB): New.
* config/riscv/riscv.h (riscv_multi_lib_check): New.
(EXTRA_SPEC_FUNCTIONS): Add riscv_multi_lib_check.
---
 gcc/common/config/riscv/riscv-common.c | 253 +
 gcc/config/riscv/elf.h |   6 +-
 gcc/config/riscv/riscv.h   |   4 +-
 3 files changed, 261 insertions(+), 2 deletions(-)

diff --git a/gcc/common/config/riscv/riscv-common.c 
b/gcc/common/config/riscv/riscv-common.c
index 5e3ddcf3f81..481f0be9944 100644
--- a/gcc/common/config/riscv/riscv-common.c
+++ b/gcc/common/config/riscv/riscv-common.c
@@ -30,6 +30,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "flags.h"
 #include "diagnostic-core.h"
 #include "config/riscv/riscv-protos.h"
+#include 
 
 #define RISCV_DONT_CARE_VERSION -1
 
@@ -171,12 +172,31 @@ public:
 
   static riscv_subset_list *parse (const char *, location_t);
 
+  int match_score (riscv_subset_list *) const;
 };
 
 static const char *riscv_supported_std_ext (void);
 
 static riscv_subset_list *current_subset_list = NULL;
 
+/* struct for recording multi-lib info.  */
+struct riscv_multi_lib_info_t {
+  std::string path;
+  std::string arch_str;
+  std::string abi_str;
+  riscv_subset_list *subset_list;
+
+  static bool parse (struct riscv_multi_lib_info_t *,
+const std::string &);
+};
+
+/* Flag for checking if there is no suitable multi-lib found.  */
+static bool riscv_no_matched_multi_lib;
+
+/* Used for record value of -march and -mabi.  */
+static std::string riscv_current_arch_str;
+static std::string riscv_current_abi_str;
+
 riscv_subset_t::riscv_subset_t ()
   : name (), major_version (0), minor_version (0), next (NULL),
 explicit_version_p (false), implied_p (false)
@@ -202,6 +222,42 @@ riscv_subset_list::~riscv_subset_list ()
 }
 }
 
+/* Compute the match score of two arch string, return 0 if incompatible.  */
+int
+riscv_subset_list::match_score (riscv_subset_list *list) const
+{
+  riscv_subset_t *s;
+  int score = 0;
+  bool has_a_ext, list_has_a_ext;
+
+  /* Impossible to match if XLEN is different.  */
+  if (list->m_xlen != this->m_xlen)
+return 0;
+
+  /* There is different code gen in libstdc++ and libatomic betwe

Re: [committed] Fix hppa64-hpux11 build to remove source paths from embedded path.

[Iain Sandoe]

Hi Dave,

John David Anglin  wrote:


Fix hppa64-hpux11 build to remove source build paths from embedded path.

This change adds the +nodefaultrpath ld option to remove all library  
paths that were specified
with the -L option from the embedded path.  Without this options, the  
emebedded path for installed
shared libraries contains paths from the source build.  The same option  
is used on ia64-hpux.


I didn't update libgo since go is not currently supported and it is more  
or less separately maintained.


The libtool.m4 change was submitted to the libtool project three months  
ago.


I went to apply another configure change in gcc/ and notice unrelated  
changes from your libtool one.


It seems that you didn’t apply (or generate?) the gcc/configure change from  
the libtool one.


Happy to do that before applying mine - but thought you might want to check  
first,

thanks
Iain

Re: [PATCH] x86_64: Fix up -fpic -mcmodel=large -fno-plt [PR98063]

[Uros Bizjak via Gcc-patches]

On Tue, Dec 1, 2020 at 9:53 AM Jakub Jelinek  wrote:
>
> Hi!
>
> On the following testcase with -fpic -mcmodel=large -fno-plt we emit
> call puts@GOTPCREL(%rip)
> but that is not really appropriate for CM_LARGE_PIC, the .text can be larger
> than 2GB in that case and the .got slot further away from %rip than what can
> fit into the signed 32-bit immediate.
>
> The following patch computes the address of the .got slot the way it is
> computed for that model for function pointer loads, and calls that.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2020-12-01  Jakub Jelinek  
>
> PR target/98063
> * config/i386/i386-expand.c (ix86_expand_call): Handle non-plt
> CM_LARGE_PIC calls.
>
> * gcc.target/i386/pr98063.c: New test.

OK.

Thanks,
Uros.

>
> --- gcc/config/i386/i386-expand.c.jj2020-11-26 16:22:29.091353066 +0100
> +++ gcc/config/i386/i386-expand.c   2020-11-30 12:55:52.936300739 +0100
> @@ -8063,7 +8063,17 @@ ix86_expand_call (rtx retval, rtx fnaddr
> }
>   else if (!TARGET_PECOFF && !TARGET_MACHO)
> {
> - if (TARGET_64BIT)
> + if (TARGET_64BIT
> + && ix86_cmodel == CM_LARGE_PIC
> + && DEFAULT_ABI != MS_ABI)
> +   {
> + fnaddr = gen_rtx_UNSPEC (Pmode, gen_rtvec (1, addr),
> +  UNSPEC_GOT);
> + fnaddr = gen_rtx_CONST (Pmode, fnaddr);
> + fnaddr = force_reg (Pmode, fnaddr);
> + fnaddr = gen_rtx_PLUS (Pmode, pic_offset_table_rtx, fnaddr);
> +   }
> + else if (TARGET_64BIT)
> {
>   fnaddr = gen_rtx_UNSPEC (Pmode,
>gen_rtvec (1, addr),
> --- gcc/testsuite/gcc.target/i386/pr98063.c.jj  2020-11-30 13:00:31.699214198 
> +0100
> +++ gcc/testsuite/gcc.target/i386/pr98063.c 2020-11-30 13:24:05.352485291 
> +0100
> @@ -0,0 +1,13 @@
> +/* PR target/98063 */
> +/* { dg-do run { target { i?86-*-linux* x86_64-*-linux* } } } */
> +/* { dg-require-effective-target lp64 } */
> +/* { dg-require-effective-target fpic } */
> +/* { dg-options "-O2 -fpic -mcmodel=large -fno-plt -save-temps" } */
> +/* { dg-final { scan-assembler-not "puts@GOTPCREL" } } */
> +
> +int
> +main ()
> +{
> +  __builtin_puts ("Hello, world!");
> +  return 0;
> +}
>
> Jakub
>

[PATCH] middle-end/98070 - fix realloc builtin fnspec

[Richard Biener]

realloc clobbers errno, note that.

Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.

2020-12-01  Richard Biener  

PR middle-end/98070
* builtins.c (builtin_fnspec): realloc is ".Cw ".
---
 gcc/builtins.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/builtins.c b/gcc/builtins.c
index 83b0c1c8fd6..e37732fbc8c 100644
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@ -13583,7 +13583,7 @@ builtin_fnspec (tree callee)
return ".cO ";
   /* Realloc serves both as allocation point and deallocation point.  */
   case BUILT_IN_REALLOC:
-   return ".cw ";
+   return ".Cw ";
   case BUILT_IN_GAMMA_R:
   case BUILT_IN_GAMMAF_R:
   case BUILT_IN_GAMMAL_R:
-- 
2.26.2

Re: [RFC] Decrease default timeout for libstdc++ tests to 6 minutes

[Christophe Lyon via Gcc-patches]

On Mon, 30 Nov 2020 at 15:58, Jonathan Wakely  wrote:
>
> On 27/11/20 21:17 +0100, Christophe Lyon via Libstdc++ wrote:
> >On Fri, 27 Nov 2020 at 17:13, Jonathan Wakely via Gcc-patches
> > wrote:
> >>
> >> The default for the GCC testsuite is 300, i.e. 5 minutes, which is the
> >> same as the DejaGnu default.
> >>
> >> Libstdc++ overrides this to 600, i.e. 10 minutes.
> >>
> >> This seems ridiculously long. If any test takes that long on modern
> >> hardware, something is wrong. We've seen this a lot recently with
> >> buggy tests, and waiting for them to FAIL is tedious.
> >>
> >> I've already made libstdc++.exp respect the user's setting in
> >> ~/.dejagnurc or the global site.exp file. This means anybody testing
> >> on slow simulators or old hardware can choose their own timeout.
> >>
> >> I've added dg-timeout-factor to the slowest std::regex tests and have
> >> a patch to do it for the PSTL tests, which both take far too long to
> >> compile. That means you can choose a sensible timeout appropriate for
> >> most tests (e.g. 60 seconds) and not get spurious failures from the
> >> few dozen tests which are just very slow.
> >>
> >> I'd like to change the default to 6 minutes. If that goes well, I'd
> >> like to lower it even further.
> >>
> >> The main benefit of this will be that buggy tests which hang will get
> >> killed sooner, so we waste less time waiting for the inevitable
> >> timeout.
> >>
> >
> >I think that's a good idea, I did have problems sometimes when
> >many tests timed out, causing the whole 'make check' to be
> >killed before completion by our compute farm management system.
>
> Thanks for the feedback. I've pushed this patch now.
>
> It's been tested on powercp64le-linux, x86_64-linux, aarch64-linux,
> sparc-solaris and powerpc-aix. They were all fine with much lower
> defaults (e.g. 120 seconds). Let's see how this goes for people
> testing on older or less powerful hardware.
>

FTR, I've seen two occurrences of a random timeout:
WARNING: program timed out.
27_io/basic_istream/get/wchar_t/lwg3464.cc execution test (reason: NONE)
FAIL: 27_io/basic_istream/get/wchar_t/lwg3464.cc execution test

when testing for aarch64-none-elf with -mabi=ilp32 using Arm's
Foundation Model as simulator (an old release).

Christophe

Re: [PATCH] loop-invariant: JUMP_INSNs aren't loop invariant [PR97954]

[Richard Biener]

On Tue, 1 Dec 2020, Jakub Jelinek wrote:

> Hi!
> 
> The following testcase ICEs because loop invariant motion moves asm goto
> with a single output as invariant.
> Normally, jumps aren't really moved, because if they are single set,
> they have their SET_DEST (pc) and pc_rtx has VOIDmode on which one of the
> functions find_invariant_insn calls bails out.  The code already punts on
> insns that can throw or trap.  And for asm goto without outputs, it isn't
> single set, or asm goto with two or more outputs it isn't single set either.
> 
> Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
> trunk?

OK.

Thanks,
Richard.

> 2020-12-01  Jakub Jelinek  
> 
>   PR rtl-optimization/97954
>   * loop-invariant.c (find_invariant_insn): Punt on JUMP_P insns.
> 
>   * gcc.dg/pr97954.c: New test.
> 
> --- gcc/loop-invariant.c.jj   2020-01-12 11:54:36.0 +0100
> +++ gcc/loop-invariant.c  2020-11-30 09:56:37.022696142 +0100
> @@ -1099,6 +1099,10 @@ find_invariant_insn (rtx_insn *insn, boo
>if (HAVE_cc0 && sets_cc0_p (insn))
>  return;
>  
> +  /* Jumps have control flow side-effects.  */
> +  if (JUMP_P (insn))
> +return;
> +
>set = single_set (insn);
>if (!set)
>  return;
> --- gcc/testsuite/gcc.dg/pr97954.c.jj 2020-11-30 10:31:54.870891248 +0100
> +++ gcc/testsuite/gcc.dg/pr97954.c2020-11-30 10:31:08.875407984 +0100
> @@ -0,0 +1,12 @@
> +/* PR rtl-optimization/97954 */
> +/* { dg-do compile } */
> +/* { dg-options "-O2" } */
> +
> +int
> +foo (void)
> +{
> +  int x;
> + lab:
> +  asm goto ("": "=r" (x) : : : lab);
> +  return x;
> +}
> 
>   Jakub
> 
> 

-- 
Richard Biener 
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)

[PATCH V2] arm: [testsuite] fix lob tests for -mfloat-abi=hard

[Andrea Corallo via Gcc-patches]

Hi all,

second version of this patch here fixing lob[2-5].c tests for hard float
abi targets implementing Kyrill's suggestions.

Okay for trunk?

  Andrea

>From f7f36b243c82a5dd49540cc48ceb8ce636872d5a Mon Sep 17 00:00:00 2001
From: Andrea Corallo 
Date: Thu, 26 Nov 2020 12:33:18 +0100
Subject: [PATCH] arm: [testsuite] fix lob tests for -mfloat-abi=hard

2020-11-26  Andrea Corallo  

* gcc.target/arm/lob2.c: Use '-march=armv8.1-m.main+fp'.
* gcc.target/arm/lob3.c: Skip with '-mfloat-abi=hard'.
* gcc.target/arm/lob4.c: Likewise.
* gcc.target/arm/lob5.c: Use '-march=armv8.1-m.main+fp'.
---
 gcc/testsuite/gcc.target/arm/lob2.c | 2 +-
 gcc/testsuite/gcc.target/arm/lob3.c | 2 +-
 gcc/testsuite/gcc.target/arm/lob4.c | 2 +-
 gcc/testsuite/gcc.target/arm/lob5.c | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/gcc/testsuite/gcc.target/arm/lob2.c 
b/gcc/testsuite/gcc.target/arm/lob2.c
index fdeb2686f51..d174857b926 100644
--- a/gcc/testsuite/gcc.target/arm/lob2.c
+++ b/gcc/testsuite/gcc.target/arm/lob2.c
@@ -2,7 +2,7 @@
if a non-inlineable function call takes place inside the loop.  */
 /* { dg-do compile } */
 /* { dg-skip-if "avoid conflicting multilib options" { *-*-* } { "-marm" 
"-mcpu=*" } } */
-/* { dg-options "-march=armv8.1-m.main -mthumb -O3 --save-temps" } */
+/* { dg-options "-march=armv8.1-m.main+fp -mthumb -O3 --save-temps" } */
 #include 
 #include "lob.h"
 
diff --git a/gcc/testsuite/gcc.target/arm/lob3.c 
b/gcc/testsuite/gcc.target/arm/lob3.c
index 70314ea84b3..f5290063f28 100644
--- a/gcc/testsuite/gcc.target/arm/lob3.c
+++ b/gcc/testsuite/gcc.target/arm/lob3.c
@@ -1,7 +1,7 @@
 /* Check that GCC does not generate Armv8.1-M low over head loop instructions
if causes VFP emulation library calls to happen inside the loop.  */
 /* { dg-do compile } */
-/* { dg-skip-if "avoid conflicting multilib options" { *-*-* } { "-marm" 
"-mcpu=*" } } */
+/* { dg-skip-if "avoid conflicting multilib options" { *-*-* } { "-marm" 
"-mcpu=*" "-mfloat-abi=hard" } } */
 /* { dg-options "-march=armv8.1-m.main -mthumb -O3 --save-temps 
-mfloat-abi=soft" } */
 /* { dg-require-effective-target arm_softfloat } */
 #include 
diff --git a/gcc/testsuite/gcc.target/arm/lob4.c 
b/gcc/testsuite/gcc.target/arm/lob4.c
index 792f352d682..86c774e1b57 100644
--- a/gcc/testsuite/gcc.target/arm/lob4.c
+++ b/gcc/testsuite/gcc.target/arm/lob4.c
@@ -1,7 +1,7 @@
 /* Check that GCC does not generate Armv8.1-M low over head loop instructions
if LR is modified within the loop.  */
 /* { dg-do compile } */
-/* { dg-skip-if "avoid conflicting multilib options" { *-*-* } { "-marm" 
"-mcpu=*" } } */
+/* { dg-skip-if "avoid conflicting multilib options" { *-*-* } { "-marm" 
"-mcpu=*" "-mfloat-abi=hard" } } */
 /* { dg-options "-march=armv8.1-m.main -mthumb -O3 --save-temps 
-mfloat-abi=soft" } */
 /* { dg-require-effective-target arm_softfloat } */
 #include 
diff --git a/gcc/testsuite/gcc.target/arm/lob5.c 
b/gcc/testsuite/gcc.target/arm/lob5.c
index 1a6adf1e28e..df5383b4a26 100644
--- a/gcc/testsuite/gcc.target/arm/lob5.c
+++ b/gcc/testsuite/gcc.target/arm/lob5.c
@@ -3,7 +3,7 @@
therefore is not optimizable.  Outer loops are not optimized.  */
 /* { dg-do compile } */
 /* { dg-skip-if "avoid conflicting multilib options" { *-*-* } { "-marm" 
"-mcpu=*" } } */
-/* { dg-options "-march=armv8.1-m.main -mthumb -O3 --save-temps" } */
+/* { dg-options "-march=armv8.1-m.main+fp -mthumb -O3 --save-temps" } */
 #include 
 #include "lob.h"
 
-- 
2.20.1

Re: [00/23] Make fwprop use an on-the-side RTL SSA representation

[Richard Sandiford via Gcc-patches]

Michael Matz  writes:
> Hello,
>
> On Mon, 30 Nov 2020, Jeff Law wrote:
>
>> >> So, then let's start with one of 
>> >> the prime examples of SSA deconstruction problems, the lost swap, and how 
>> >> it comes to be: we start with a swap:
>> >>
>> >>   x = ..., y = ...
>> >>   if (cond)
>> >> tmp=x, x=y, y=tmp
>> >>
>> >> (1) into SSA:
>> >>
>> >>   x0 = ..., y0 = ...
>> >>   if (cond)
>> >> tmp = x0, x1=y0, y1=tmp;
>> >>   x2 = PHI(x0,x1),  y2 = PHI(y0,y1)
>> >>
>> >> (2) copy-prop:
>> >>
>> >>   x0 = ..., y0 = ...
>> >>   if (cond)
>> >> ;
>> >>   x2 = PHI(x0,y0),  y2 = PHI(y0,x0)
>> > So the point is that this isn't what the RTL would look like even
>> > when using RTL SSA.  Putting y0 in x2 PHI and x0 in the y2 PHI is
>> > representationally invalid.
>> >
>> > Like I say, this isn't a “native” SSA form: it's just using SSA
>> > constructs to represent dataflow in normal RTL.
>> It appears that the PHI arguments have to be different instances of the
>> result.  So the case above can't happen, which helps, but I'm not sure
>> it's necessarily sufficient to avoid all the problems in this space.
>> IIRC you can get into a similar scenario by transformations that result
>> in overlapping lifetimes for different instances of the same object. 
>> They didn't necessarily overlap when the SSA form was created, but may
>> after things like CSE or copy propagation.
>
> I think the reasoning why this can't (or should not) happen is the 
> following: if different instances of the same objects (say, one before, 
> one after a modification) exist, they must necessarily be stored in 
> different pseudos (otherwise the RTL transformation itself was already 
> invalid), and that causes them to be invalid operands of the same PHI 
> node.  Ala:
>
> input:
>
>regA =  /1
>use1(regA)  /2
>regA += ... /3
>use2(regA)  /4
>
> let's try creating different instances of regA (from point 2 and 4) that 
> overlap, e.g. by swapping insns 2 and 3.  We _have_ to rename regA from 
> insn 3 into a new pseudo, otherwise the uses of 2 and 4 can't be 
> differentiated anymore, so:
>
>regA  =  /1
>regA' = regA
>regA' += /3'
>use1(regA)   /2
>use2(regA')  /4'
>
> So if Richards model constrains the pseudo PHI nodes such that regA and 
> regA' can't be operands of one, that might solve the issue, as both the 
> lost copy and the swap problem need overlaps of different values to occur.

Right.  This isn't conceptually different from the way that virtual
operands work in gimple.  It's just that rather than having one vop
for memory (as in gimple), we have one vop for memory, one vop
for each individual hard register, and one vop for each individual
pseudo register.

FWIW, there's also a routine (rtl_ssa::restrict_movement) that takes
the changes that a pass wants to make to an instruction and finds a
range of locations that satisfy all the constraints.

Thanks,
Richard

Re: [PATCH 1/2] IBM Z: Configure excess precision for float at compile-time

[Andreas Krebbel via Gcc-patches]

On 11/25/20 6:06 PM, Marius Hillenbrand wrote:
> Historically, float_t has been defined as double on s390 and gcc would
> emit double precision insns for evaluating float expressions when in
> standard-compliant mode. Configure that behavior at compile-time as prep
> for changes in glibc: When glibc ties float_t to double, keep the old
> behavior; when glibc derives float_t from FLT_EVAL_METHOD (as on most
> other archs), revert to the default behavior (i.e.,
> FLT_EVAL_METHOD_PROMOTE_TO_FLOAT). Provide a configure option
> --enable-s390-excess-float-precision to override the check.
> 
> gcc/ChangeLog:
> 
> 2020-11-25  Marius Hillenbrand  
> 
>   * configure.ac: Add configure option
>   --enable-s390-excess-float-precision and check to derive default
>   from glibc.
>   * config/s390/s390.c: Guard s390_excess_precision with an ifdef
>   for ENABLE_S390_EXCESS_FLOAT_PRECISION.
>   * doc/install.texi: Document --enable-s390-excess-float-precision.
>   * configure: Regenerate.
>   * config.in: Regenerate.

Ok. Applied to mainline.

Thanks!

Andreas

Re: [PATCH 2/2] gcc/testsuite/s390: Add test cases for float_t

[Andreas Krebbel via Gcc-patches]

On 11/25/20 6:06 PM, Marius Hillenbrand wrote:
> Add two test cases that check for acceptable combinations of float_t and
> FLT_EVAL_METHOD on s390x.
> 
> Tested against an as-is glibc and one modified so that it derives
> float_t from FLT_EVAL_METHOD.
> 
> gcc/testsuite/ChangeLog:
> 
> 2020-11-25  Marius Hillenbrand  
> 
>   * gcc.target/s390/float_t-1.c: New test.
>   * gcc.target/s390/float_t-2.c: New test.

Ok. Applied to mainline.

Thanks!

Andreas

Re: [PATCH v2] Add if-chain to switch conversion pass.

[Richard Biener via Gcc-patches]

On Fri, Nov 27, 2020 at 4:07 PM Martin Liška  wrote:
>
> On 11/20/20 3:37 PM, Richard Biener wrote:
> > On Fri, Nov 20, 2020 at 9:57 AM Martin Liška  wrote:
> >>
> >> On 11/19/20 3:46 PM, Richard Biener wrote:
> >>> OK, so can you send an updated patch?
> >
> > +  tree pos_one = build_int_cst (type, 1);
> > +  if (!left->m_has_forward_bb
> > + && !right->m_has_forward_bb
> > + && left->m_case_bb == right->m_case_bb)
> > +   {
> > + tree next = int_const_binop (PLUS_EXPR, left->get_high (), 
> > pos_one);
> > + if (tree_int_cst_equal (next, right->get_low ()))
> >
> > can you please avoid tree arithmetic here and use wide_ints?
> >
> >if (wi::eq (wi::to_wide (right->get_low) - wi::to_wide
> > (left->get_high), wi::one (TYPE_PRECISION (type))
> >
> > ?
> >
> > +  info.record_phi_mapping (info.m_true_edge,
> > +  &info.m_true_edge_phi_mapping);
> > +  info.record_phi_mapping (info.m_false_edge,
> > +  &info.m_false_edge_phi_mapping);
> >
> > you still have this edge mapping stuff, can't you recover the actual
> > PHI arguments from the PHIs during code generation?  I see you removed
> > the restriction for all-same values, good.
> >
> > +unsigned int
> > +pass_if_to_switch::execute (function *fun)
> > +{
> > +  auto_vec all_candidates;
> > +  hash_map conditions_in_bbs;
> > +
> > +  basic_block bb;
> > +  FOR_EACH_BB_FN (bb, fun)
> > +find_conditions (bb, &conditions_in_bbs);
> > +
> >
> > if we didn't find any suitable conditions we can early out
> >
> > +  free_dominance_info (CDI_DOMINATORS);
> > +
> > +  if (!all_candidates.is_empty ())
> > +mark_virtual_operands_for_renaming (fun);
> >
> > please do not free dominator info when you did nothing
> > (all_candidates.is_empty ()).
> >
> > + gcond *cond = chain->m_entries[0]->m_cond;
> > + expanded_location loc = expand_location (gimple_location 
> > (cond));
> > + if (dump_file)
> > +   {
> > + fprintf (dump_file, "Condition chain (at %s:%d) with %d 
> > BBs "
> > +  "transformed into a switch statement.\n",
> > +  loc.file, loc.line,
> > +  chain->m_entries.length ());
> > +   }
> >
> > if you use dump_enabled_p () and dump_printf_loc you can
> > use 'cond' as location itself.
> >
> > Otherwise looks OK.
>
> Hello.
>
> I fixed all the notes except the PHI mapping map. It's really not simple
> to reconstruct PHI nodes during code-gen. Once a BB is removed in transform 
> phase,
> I would need to investigate which PHIs have "holes" (missing PHI argument).
>
> Moreover, I do the very similar thing in 
> gcc/tree-switch-conversion.c::record_phi_operand_mapping.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> And I run SPEC2006 benchmarks, it has done 413 transformations.

OK.

Thanks,
Richard.

> Martin
>
> >
> > Thanks,
> > Richard.
> >
> >> Sure.
> >>
> >> Martin
>

Re: [PATCH] Introduce can_vec_cmp_compare_p

[Richard Biener via Gcc-patches]

On Thu, Nov 26, 2020 at 8:27 PM Ilya Leoshkevich via Gcc-patches
 wrote:
>
> Bootstrapped and regtested on x86_64-redhat-linux and
> s390x-redhat-linux.  Ok for master?

OK/

Thanks,
Richard.

>
>
> This is the same as dcd2ca63ec5c ("Introduce can_vcond_compare_p
> function"), but for vec_cmp.  The reason it's needed is that since
> 5d9ade39b872 ("IBM Z: Fix PR97326: Enable fp compares in vec_cmp")
> and 4acba4859013 ("IBM Z: Restrict vec_cmp on z13") s390's vec_cmp
> expander advertises that it supports floating point comparisons except
> signaling ones on z13, but the common code ignores the latter
> restriction.
>
> gcc/ChangeLog:
>
> 2020-11-25  Ilya Leoshkevich  
>
> * optabs-tree.c (vec_cmp_icode_p): New function.
> (vec_cmp_eq_icode_p): New function.
> (expand_vec_cmp_expr_p): Use vec_cmp_icode_p and
> vec_cmp_eq_icode_p.
> (vcond_icode_p): Use get_rtx_code_1, just to be uniform with
> vec_cmp_icode_p.
> * optabs.c (unsigned_optab_p): New function.
> (insn_predicate_matches_p): New function.
> (can_vec_cmp_compare_p): New function.
> (can_vcond_compare_p): Use unsigned_optab_p and
> insn_predicate_matches_p.
> (get_rtx_code): Use get_rtx_code_1.
> (get_rtx_code_1): Version of get_rtx_code that returns UNKNOWN
> instead of asserting.
> * optabs.h (can_vec_cmp_compare_p): New function.
> (get_rtx_code_1): New function.
> ---
>  gcc/optabs-tree.c | 47 ++--
>  gcc/optabs.c  | 78 ++-
>  gcc/optabs.h  | 12 ++--
>  3 files changed, 109 insertions(+), 28 deletions(-)
>
> diff --git a/gcc/optabs-tree.c b/gcc/optabs-tree.c
> index b797d018c84..a8968f3dd1a 100644
> --- a/gcc/optabs-tree.c
> +++ b/gcc/optabs-tree.c
> @@ -337,6 +337,35 @@ supportable_convert_operation (enum tree_code code,
>return false;
>  }
>
> +/* Return true iff vec_cmp_optab/vec_cmpu_optab can handle a vector 
> comparison
> +   for code CODE, comparing operands of type VALUE_TYPE and producing a 
> result
> +   of type MASK_TYPE.  */
> +
> +static bool
> +vec_cmp_icode_p (tree value_type, tree mask_type, enum tree_code code)
> +{
> +  enum rtx_code rcode = get_rtx_code_1 (code, TYPE_UNSIGNED (value_type));
> +  if (rcode == UNKNOWN)
> +return false;
> +
> +  return can_vec_cmp_compare_p (rcode, TYPE_MODE (value_type),
> +   TYPE_MODE (mask_type));
> +}
> +
> +/* Return true iff vec_cmpeq_optab can handle a vector comparison for code
> +   CODE, comparing operands of type VALUE_TYPE and producing a result of type
> +   MASK_TYPE.  */
> +
> +static bool
> +vec_cmp_eq_icode_p (tree value_type, tree mask_type, enum tree_code code)
> +{
> +  if (code != EQ_EXPR && code != NE_EXPR)
> +return false;
> +
> +  return get_vec_cmp_eq_icode (TYPE_MODE (value_type), TYPE_MODE (mask_type))
> +!= CODE_FOR_nothing;
> +}
> +
>  /* Return TRUE if appropriate vector insn is available
> for vector comparison expr with vector type VALUE_TYPE
> and resulting mask with MASK_TYPE.  */
> @@ -344,14 +373,8 @@ supportable_convert_operation (enum tree_code code,
>  bool
>  expand_vec_cmp_expr_p (tree value_type, tree mask_type, enum tree_code code)
>  {
> -  if (get_vec_cmp_icode (TYPE_MODE (value_type), TYPE_MODE (mask_type),
> -TYPE_UNSIGNED (value_type)) != CODE_FOR_nothing)
> -return true;
> -  if ((code == EQ_EXPR || code == NE_EXPR)
> -  && (get_vec_cmp_eq_icode (TYPE_MODE (value_type), TYPE_MODE 
> (mask_type))
> - != CODE_FOR_nothing))
> -return true;
> -  return false;
> +  return vec_cmp_icode_p (value_type, mask_type, code)
> +|| vec_cmp_eq_icode_p (value_type, mask_type, code);
>  }
>
>  /* Return true iff vcond_optab/vcondu_optab can handle a vector
> @@ -361,8 +384,12 @@ expand_vec_cmp_expr_p (tree value_type, tree mask_type, 
> enum tree_code code)
>  static bool
>  vcond_icode_p (tree value_type, tree cmp_op_type, enum tree_code code)
>  {
> -  return can_vcond_compare_p (get_rtx_code (code, TYPE_UNSIGNED 
> (cmp_op_type)),
> - TYPE_MODE (value_type), TYPE_MODE 
> (cmp_op_type));
> +  enum rtx_code rcode = get_rtx_code_1 (code, TYPE_UNSIGNED (cmp_op_type));
> +  if (rcode == UNKNOWN)
> +return false;
> +
> +  return can_vcond_compare_p (rcode, TYPE_MODE (value_type),
> + TYPE_MODE (cmp_op_type));
>  }
>
>  /* Return true iff vcondeq_optab can handle a vector comparison for code 
> CODE,
> diff --git a/gcc/optabs.c b/gcc/optabs.c
> index 1820b91877a..76045596980 100644
> --- a/gcc/optabs.c
> +++ b/gcc/optabs.c
> @@ -3834,23 +3834,59 @@ can_compare_p (enum rtx_code code, machine_mode mode,
>return 0;
>  }
>
> -/* Return whether the backend can emit a vector comparison for code CODE,
> -   comparing operands of mode CMP_OP_MODE and producing a result with
> -   VALUE_MODE.  */
> +/

[PATCH] dwarf: Add -gdwarf{32,64} options

[Jakub Jelinek via Gcc-patches]

Hi!

The following patch makes the choice between 32-bit and 64-bit DWARF formats
selectable by command line switch, rather than being hardcoded through
DWARF_OFFSET_SIZE macro.

The options themselves don't turn on debug info themselves, so one needs
to use -g -gdwarf64 or similar.

Ok for trunk if it passes bootstrap/regtest?

I've tried it on a few smaller and larger testcases and readelf -wi was
happy about the output.

2020-12-01  Jakub Jelinek  

* common.opt (-gdwarf32, -gdwarf64): New options.
* config/rs6000/rs6000.c (rs6000_option_override_internal): Default
dwarf_offset_size to 8 if not overridden from the command line.
* dwarf2out.c: Change all occurrences of DWARF_OFFSET_SIZE to
dwarf_offset_size.
* doc/invoke.texi (-gdwarf32, -gdwarf64): Document.

--- gcc/common.opt.jj   2020-11-26 01:14:47.444082913 +0100
+++ gcc/common.opt  2020-12-01 11:07:33.088093473 +0100
@@ -3178,6 +3178,14 @@ gdwarf-
 Common Driver Joined UInteger Var(dwarf_version) Init(4) Negative(gstabs)
 Generate debug information in DWARF v2 (or later) format.
 
+gdwarf32
+Common Driver Var(dwarf_offset_size,4) Init(4) RejectNegative
+Use 32-bit DWARF format when emitting DWARF debug information.
+
+gdwarf64
+Common Driver Var(dwarf_offset_size,8) RejectNegative
+Use 64-bit DWARF format when emitting DWARF debug information.
+
 ggdb
 Common Driver JoinedOrMissing
 Generate debug information in default extended format.
--- gcc/config/rs6000/rs6000.c.jj   2020-11-27 11:20:53.484334843 +0100
+++ gcc/config/rs6000/rs6000.c  2020-12-01 11:12:31.618731395 +0100
@@ -3863,6 +3863,12 @@ rs6000_option_override_internal (bool gl
   if (TARGET_DEBUG_REG || TARGET_DEBUG_TARGET)
 rs6000_print_isa_options (stderr, 0, "before defaults", rs6000_isa_flags);
 
+#ifdef XCOFF_DEBUGGING_INFO
+  /* For AIX default to 64-bit DWARF.  */
+  if (!global_options_set.x_dwarf_offset_size)
+dwarf_offset_size = 8;
+#endif
+
   /* Handle explicit -mno-{altivec,vsx,power8-vector,power9-vector} and turn
  off all of the options that depend on those flags.  */
   ignore_masks = rs6000_disable_incompatible_switches ();
--- gcc/dwarf2out.c.jj  2020-12-01 09:41:07.223490914 +0100
+++ gcc/dwarf2out.c 2020-12-01 11:03:04.692115667 +0100
@@ -182,14 +182,14 @@ static GTY(()) section *debug_frame_sect
bytes.
 
However, the SGI/MIPS ABI uses an initial length which is equal to
-   DWARF_OFFSET_SIZE.  It is defined (elsewhere) accordingly.  */
+   dwarf_offset_size.  It is defined (elsewhere) accordingly.  */
 
 #ifndef DWARF_INITIAL_LENGTH_SIZE
-#define DWARF_INITIAL_LENGTH_SIZE (DWARF_OFFSET_SIZE == 4 ? 4 : 12)
+#define DWARF_INITIAL_LENGTH_SIZE (dwarf_offset_size == 4 ? 4 : 12)
 #endif
 
 #ifndef DWARF_INITIAL_LENGTH_SIZE_STR
-#define DWARF_INITIAL_LENGTH_SIZE_STR (DWARF_OFFSET_SIZE == 4 ? "-4" : "-12")
+#define DWARF_INITIAL_LENGTH_SIZE_STR (dwarf_offset_size == 4 ? "-4" : "-12")
 #endif
 
 /* Round SIZE up to the nearest BOUNDARY.  */
@@ -199,7 +199,7 @@ static GTY(()) section *debug_frame_sect
 /* CIE identifier.  */
 #if HOST_BITS_PER_WIDE_INT >= 64
 #define DWARF_CIE_ID \
-  (unsigned HOST_WIDE_INT) (DWARF_OFFSET_SIZE == 4 ? DW_CIE_ID : DW64_CIE_ID)
+  (unsigned HOST_WIDE_INT) (dwarf_offset_size == 4 ? DW_CIE_ID : DW64_CIE_ID)
 #else
 #define DWARF_CIE_ID DW_CIE_ID
 #endif
@@ -287,8 +287,8 @@ static GTY(()) bool do_eh_frame = false;
 static unsigned int rnglist_idx;
 
 /* Data and reference forms for relocatable data.  */
-#define DW_FORM_data (DWARF_OFFSET_SIZE == 8 ? DW_FORM_data8 : DW_FORM_data4)
-#define DW_FORM_ref (DWARF_OFFSET_SIZE == 8 ? DW_FORM_ref8 : DW_FORM_ref4)
+#define DW_FORM_data (dwarf_offset_size == 8 ? DW_FORM_data8 : DW_FORM_data4)
+#define DW_FORM_ref (dwarf_offset_size == 8 ? DW_FORM_ref8 : DW_FORM_ref4)
 
 #ifndef DEBUG_FRAME_SECTION
 #define DEBUG_FRAME_SECTION".debug_frame"
@@ -602,10 +602,10 @@ output_fde (dw_fde_ref fde, bool for_eh,
   ASM_GENERATE_INTERNAL_LABEL (l2, FDE_END_LABEL, for_eh + j);
   if (!XCOFF_DEBUGGING_INFO || for_eh)
 {
-  if (DWARF_INITIAL_LENGTH_SIZE - DWARF_OFFSET_SIZE == 4 && !for_eh)
+  if (DWARF_INITIAL_LENGTH_SIZE - dwarf_offset_size == 4 && !for_eh)
dw2_asm_output_data (4, 0x, "Initial length escape value"
 " indicating 64-bit DWARF extension");
-  dw2_asm_output_delta (for_eh ? 4 : DWARF_OFFSET_SIZE, l2, l1,
+  dw2_asm_output_delta (for_eh ? 4 : dwarf_offset_size, l2, l1,
"FDE Length");
 }
   ASM_OUTPUT_LABEL (asm_out_file, l1);
@@ -613,7 +613,7 @@ output_fde (dw_fde_ref fde, bool for_eh,
   if (for_eh)
 dw2_asm_output_delta (4, l1, section_start_label, "FDE CIE offset");
   else
-dw2_asm_output_offset (DWARF_OFFSET_SIZE, section_start_label,
+dw2_asm_output_offset (dwarf_offset_size, section_start_label,
   debug_frame_section, "FDE CIE offset");
 
   begin = second ? fde->dw_fde_second_begin : fde-

[committed] libstdc++: Link test with libatomic if needed [PR 98003]

[Jonathan Wakely via Gcc-patches]

libstdc++-v3/ChangeLog:

PR libstdc++/98003
* testsuite/27_io/basic_syncbuf/sync_ops/1.cc: Add options for
libatomic.

Tested x86_64-linux. Committed to trunk.

commit 58f71a34c68711c4432b45086bfcccb78be7ace5
Author: Jonathan Wakely 
Date:   Tue Dec 1 10:36:09 2020

libstdc++: Link test with libatomic if needed [PR 98003]

libstdc++-v3/ChangeLog:

PR libstdc++/98003
* testsuite/27_io/basic_syncbuf/sync_ops/1.cc: Add options for
libatomic.

diff --git a/libstdc++-v3/testsuite/27_io/basic_syncbuf/sync_ops/1.cc 
b/libstdc++-v3/testsuite/27_io/basic_syncbuf/sync_ops/1.cc
index 90d20f1a6071..a224e0c02228 100644
--- a/libstdc++-v3/testsuite/27_io/basic_syncbuf/sync_ops/1.cc
+++ b/libstdc++-v3/testsuite/27_io/basic_syncbuf/sync_ops/1.cc
@@ -15,11 +15,12 @@
 // with this library; see the file COPYING3.  If not see
 // .
 
-// { dg-options "-std=gnu++2a -pthread" }
+// { dg-options "-std=gnu++2a" }
 // { dg-do run { target c++2a } }
-// { dg-require-effective-target pthread }
 // { dg-require-effective-target cxx11-abi }
 // { dg-require-gthreads "" }
+// { dg-add-options libatomic }
+// { dg-additional-options "-pthread" { target pthread } }
 
 #include 
 #include 

Re: [PATCH] dwarf: Add -gdwarf{32,64} options

[Richard Biener]

On Tue, 1 Dec 2020, Jakub Jelinek wrote:

> Hi!
> 
> The following patch makes the choice between 32-bit and 64-bit DWARF formats
> selectable by command line switch, rather than being hardcoded through
> DWARF_OFFSET_SIZE macro.
> 
> The options themselves don't turn on debug info themselves, so one needs
> to use -g -gdwarf64 or similar.
> 
> Ok for trunk if it passes bootstrap/regtest?

OK.  Note there's

/* Various DIE's use offsets relative to the beginning of the
   .debug_info section to refer to each other.  */

typedef long int dw_offset;

which on L32 hosts means we might not support dwarf64 generation
for CUs that do not fit in 31bits?  Should we change that to
int64_t?  Or should we sorry() for -gdwarf64 on 32bit hosts?

There's also

  unsigned long die_abbrev;

and other uses of '[unsigned] long' in dwarf2out.c.

> I've tried it on a few smaller and larger testcases and readelf -wi was
> happy about the output.

Do dwarf32 and dwarf64 objects inter-operate just fine (as long as
the linker can resolve all relocations w/o truncating)?

Richard.

> 2020-12-01  Jakub Jelinek  
> 
>   * common.opt (-gdwarf32, -gdwarf64): New options.
>   * config/rs6000/rs6000.c (rs6000_option_override_internal): Default
>   dwarf_offset_size to 8 if not overridden from the command line.
>   * dwarf2out.c: Change all occurrences of DWARF_OFFSET_SIZE to
>   dwarf_offset_size.
>   * doc/invoke.texi (-gdwarf32, -gdwarf64): Document.
> 
> --- gcc/common.opt.jj 2020-11-26 01:14:47.444082913 +0100
> +++ gcc/common.opt2020-12-01 11:07:33.088093473 +0100
> @@ -3178,6 +3178,14 @@ gdwarf-
>  Common Driver Joined UInteger Var(dwarf_version) Init(4) Negative(gstabs)
>  Generate debug information in DWARF v2 (or later) format.
>  
> +gdwarf32
> +Common Driver Var(dwarf_offset_size,4) Init(4) RejectNegative
> +Use 32-bit DWARF format when emitting DWARF debug information.
> +
> +gdwarf64
> +Common Driver Var(dwarf_offset_size,8) RejectNegative
> +Use 64-bit DWARF format when emitting DWARF debug information.
> +
>  ggdb
>  Common Driver JoinedOrMissing
>  Generate debug information in default extended format.
> --- gcc/config/rs6000/rs6000.c.jj 2020-11-27 11:20:53.484334843 +0100
> +++ gcc/config/rs6000/rs6000.c2020-12-01 11:12:31.618731395 +0100
> @@ -3863,6 +3863,12 @@ rs6000_option_override_internal (bool gl
>if (TARGET_DEBUG_REG || TARGET_DEBUG_TARGET)
>  rs6000_print_isa_options (stderr, 0, "before defaults", 
> rs6000_isa_flags);
>  
> +#ifdef XCOFF_DEBUGGING_INFO
> +  /* For AIX default to 64-bit DWARF.  */
> +  if (!global_options_set.x_dwarf_offset_size)
> +dwarf_offset_size = 8;
> +#endif
> +
>/* Handle explicit -mno-{altivec,vsx,power8-vector,power9-vector} and turn
>   off all of the options that depend on those flags.  */
>ignore_masks = rs6000_disable_incompatible_switches ();
> --- gcc/dwarf2out.c.jj2020-12-01 09:41:07.223490914 +0100
> +++ gcc/dwarf2out.c   2020-12-01 11:03:04.692115667 +0100
> @@ -182,14 +182,14 @@ static GTY(()) section *debug_frame_sect
> bytes.
>  
> However, the SGI/MIPS ABI uses an initial length which is equal to
> -   DWARF_OFFSET_SIZE.  It is defined (elsewhere) accordingly.  */
> +   dwarf_offset_size.  It is defined (elsewhere) accordingly.  */
>  
>  #ifndef DWARF_INITIAL_LENGTH_SIZE
> -#define DWARF_INITIAL_LENGTH_SIZE (DWARF_OFFSET_SIZE == 4 ? 4 : 12)
> +#define DWARF_INITIAL_LENGTH_SIZE (dwarf_offset_size == 4 ? 4 : 12)
>  #endif
>  
>  #ifndef DWARF_INITIAL_LENGTH_SIZE_STR
> -#define DWARF_INITIAL_LENGTH_SIZE_STR (DWARF_OFFSET_SIZE == 4 ? "-4" : "-12")
> +#define DWARF_INITIAL_LENGTH_SIZE_STR (dwarf_offset_size == 4 ? "-4" : "-12")
>  #endif
>  
>  /* Round SIZE up to the nearest BOUNDARY.  */
> @@ -199,7 +199,7 @@ static GTY(()) section *debug_frame_sect
>  /* CIE identifier.  */
>  #if HOST_BITS_PER_WIDE_INT >= 64
>  #define DWARF_CIE_ID \
> -  (unsigned HOST_WIDE_INT) (DWARF_OFFSET_SIZE == 4 ? DW_CIE_ID : DW64_CIE_ID)
> +  (unsigned HOST_WIDE_INT) (dwarf_offset_size == 4 ? DW_CIE_ID : DW64_CIE_ID)
>  #else
>  #define DWARF_CIE_ID DW_CIE_ID
>  #endif
> @@ -287,8 +287,8 @@ static GTY(()) bool do_eh_frame = false;
>  static unsigned int rnglist_idx;
>  
>  /* Data and reference forms for relocatable data.  */
> -#define DW_FORM_data (DWARF_OFFSET_SIZE == 8 ? DW_FORM_data8 : DW_FORM_data4)
> -#define DW_FORM_ref (DWARF_OFFSET_SIZE == 8 ? DW_FORM_ref8 : DW_FORM_ref4)
> +#define DW_FORM_data (dwarf_offset_size == 8 ? DW_FORM_data8 : DW_FORM_data4)
> +#define DW_FORM_ref (dwarf_offset_size == 8 ? DW_FORM_ref8 : DW_FORM_ref4)
>  
>  #ifndef DEBUG_FRAME_SECTION
>  #define DEBUG_FRAME_SECTION  ".debug_frame"
> @@ -602,10 +602,10 @@ output_fde (dw_fde_ref fde, bool for_eh,
>ASM_GENERATE_INTERNAL_LABEL (l2, FDE_END_LABEL, for_eh + j);
>if (!XCOFF_DEBUGGING_INFO || for_eh)
>  {
> -  if (DWARF_INITIAL_LENGTH_SIZE - DWARF_OFFSET_SIZE == 4 && !for_eh)
> +  if (DWARF_INITIAL_LENGTH_SIZE - dwarf_

Re: [RFC] Decrease default timeout for libstdc++ tests to 6 minutes

[Jonathan Wakely via Gcc-patches]

On 01/12/20 10:45 +0100, Christophe Lyon wrote:

On Mon, 30 Nov 2020 at 15:58, Jonathan Wakely  wrote:


On 27/11/20 21:17 +0100, Christophe Lyon via Libstdc++ wrote:
>On Fri, 27 Nov 2020 at 17:13, Jonathan Wakely via Gcc-patches
> wrote:
>>
>> The default for the GCC testsuite is 300, i.e. 5 minutes, which is the
>> same as the DejaGnu default.
>>
>> Libstdc++ overrides this to 600, i.e. 10 minutes.
>>
>> This seems ridiculously long. If any test takes that long on modern
>> hardware, something is wrong. We've seen this a lot recently with
>> buggy tests, and waiting for them to FAIL is tedious.
>>
>> I've already made libstdc++.exp respect the user's setting in
>> ~/.dejagnurc or the global site.exp file. This means anybody testing
>> on slow simulators or old hardware can choose their own timeout.
>>
>> I've added dg-timeout-factor to the slowest std::regex tests and have
>> a patch to do it for the PSTL tests, which both take far too long to
>> compile. That means you can choose a sensible timeout appropriate for
>> most tests (e.g. 60 seconds) and not get spurious failures from the
>> few dozen tests which are just very slow.
>>
>> I'd like to change the default to 6 minutes. If that goes well, I'd
>> like to lower it even further.
>>
>> The main benefit of this will be that buggy tests which hang will get
>> killed sooner, so we waste less time waiting for the inevitable
>> timeout.
>>
>
>I think that's a good idea, I did have problems sometimes when
>many tests timed out, causing the whole 'make check' to be
>killed before completion by our compute farm management system.

Thanks for the feedback. I've pushed this patch now.

It's been tested on powercp64le-linux, x86_64-linux, aarch64-linux,
sparc-solaris and powerpc-aix. They were all fine with much lower
defaults (e.g. 120 seconds). Let's see how this goes for people
testing on older or less powerful hardware.



FTR, I've seen two occurrences of a random timeout:
WARNING: program timed out.
27_io/basic_istream/get/wchar_t/lwg3464.cc execution test (reason: NONE)
FAIL: 27_io/basic_istream/get/wchar_t/lwg3464.cc execution test

when testing for aarch64-none-elf with -mabi=ilp32 using Arm's
Foundation Model as simulator (an old release).


Yes, that test only runs for target { ! lp64 } and does quite a lot of
work. It should compile quite quickly, but takes a long time to run
compared to most tests.

I've add dg-timeout-factor to it and its narrow char counterpart.

Tested x86_64-linux, pushed to trunk.



commit 0fb378761f2c5eb906bf0a9698112dd65d4dc73b
Author: Jonathan Wakely 
Date:   Tue Dec 1 10:51:25 2020

libstdc++: Use longer timeout for slow running tests

libstdc++-v3/ChangeLog:

* testsuite/27_io/basic_istream/get/char/lwg3464.cc: Add
dg-timeout-factor directive.
* testsuite/27_io/basic_istream/get/wchar_t/lwg3464.cc:
Likewise.

diff --git a/libstdc++-v3/testsuite/27_io/basic_istream/get/char/lwg3464.cc b/libstdc++-v3/testsuite/27_io/basic_istream/get/char/lwg3464.cc
index 6123ca5b713..85d7fc0ebd0 100644
--- a/libstdc++-v3/testsuite/27_io/basic_istream/get/char/lwg3464.cc
+++ b/libstdc++-v3/testsuite/27_io/basic_istream/get/char/lwg3464.cc
@@ -16,6 +16,7 @@
 // .
 
 // { dg-do run { target { ! lp64 } } }
+// { dg-timeout-factor 2 }
 
 #include 
 #include 
diff --git a/libstdc++-v3/testsuite/27_io/basic_istream/get/wchar_t/lwg3464.cc b/libstdc++-v3/testsuite/27_io/basic_istream/get/wchar_t/lwg3464.cc
index 6df244cc32d..1d8411c267a 100644
--- a/libstdc++-v3/testsuite/27_io/basic_istream/get/wchar_t/lwg3464.cc
+++ b/libstdc++-v3/testsuite/27_io/basic_istream/get/wchar_t/lwg3464.cc
@@ -16,6 +16,7 @@
 // .
 
 // { dg-do run { target { ! lp64 } } }
+// { dg-timeout-factor 2 }
 
 #include 
 #include 

Re: [PATCH] testsuite: Correct check_effective_target_hwaddress_exec

[Christophe Lyon via Gcc-patches]

On Fri, 27 Nov 2020 at 19:46, Matthew Malcomson
 wrote:
>
> Hello,
>
> -
>
> This test should ensure that we can compile with hwasan, that such a compiled
> binary runs as expected, *and* that we're running on a kernel which implements
> the capability to ignore the top bytes of pointers in syscalls.
>
> It was expected that a basic test of `int main(void) { return 0; }` would 
> check
> this, since there is a check called during `__hwasan_init` in libhwasan to
> ensure that the kernel we're running on provides a `prctl` to request the
> relaxed ABI.
>
> Unfortunately, the check in libhwasan has a bug in it, and does not correctly
> fail when the kernel feature is not around.  This means that check is not
> automatically provided by the runtime.
>
> The sanitizer runtime will be fixed but would like to install this fix here in
> case fixing the library is not quick enough for the release (and so that 
> people
> running the testsuite do not see spurious errors in the meantime).
>
> Tested by running testsuite on an AArch64 machine with and without the 
> required
> kernel.
> Observed that the test does indeed fail when the kernel feature is unavailable
> and pass when the feature is available.
>
> Note that this test is directly targetting AArch64 by using `prctl` numbers
> specific to it.  That's unfortunate, but once the runtime fix has gone in we
> will be able to remove that requirement.
>
> Ok for trunk?
>
> gcc/testsuite/ChangeLog:
>
> * lib/hwasan-dg.exp (check_effective_target_hwaddress_exec): Fix
> check for correct kernel version.
>

Hi Matthew,

Thanks for the patch: I could test it in my validation environment and it makes
the offending tests unsupported, which will prevent spurious regression reports.

Thanks

Christophe

>
>
> ### Attachment also inlined for ease of reply
> ###
>
>
> diff --git a/gcc/testsuite/lib/hwasan-dg.exp b/gcc/testsuite/lib/hwasan-dg.exp
> index 
> 892f2bab43325e830b5d9243377c70e074cdfe40..bd2a011947f9d3384ee32ffa9996a49429256af2
>  100644
> --- a/gcc/testsuite/lib/hwasan-dg.exp
> +++ b/gcc/testsuite/lib/hwasan-dg.exp
> @@ -41,7 +41,24 @@ proc check_effective_target_fsanitize_hwaddress {} {
>
>  proc check_effective_target_hwaddress_exec {} {
>  if ![check_runtime hwaddress_exec {
> -   int main (void) { return 0; }
> +   #ifdef __cplusplus
> +   extern "C" {
> +   #endif
> +   extern int prctl(int, unsigned long, unsigned long, unsigned long, 
> unsigned long);
> +   #ifdef __cplusplus
> +   }
> +   #endif
> +   int main (void) {
> +   #define PR_SET_TAGGED_ADDR_CTRL 55
> +   #define PR_GET_TAGGED_ADDR_CTRL 56
> +   #define PR_TAGGED_ADDR_ENABLE (1UL << 0)
> + if (prctl (PR_GET_TAGGED_ADDR_CTRL, 0, 0, 0, 0) == -1)
> +   return 1;
> + if (prctl(PR_SET_TAGGED_ADDR_CTRL, PR_TAGGED_ADDR_ENABLE, 0, 0, 0) 
> == -1
> + || !prctl(PR_GET_TAGGED_ADDR_CTRL, 0, 0, 0, 0))
> +   return 1;
> + return 0;
> +   }
>  }] {
> return 0;
>  }
>

Re: [PATCH] dwarf: Add -gdwarf{32,64} options

[Jakub Jelinek via Gcc-patches]

On Tue, Dec 01, 2020 at 11:49:43AM +0100, Richard Biener wrote:
> On Tue, 1 Dec 2020, Jakub Jelinek wrote:
> 
> > Hi!
> > 
> > The following patch makes the choice between 32-bit and 64-bit DWARF formats
> > selectable by command line switch, rather than being hardcoded through
> > DWARF_OFFSET_SIZE macro.
> > 
> > The options themselves don't turn on debug info themselves, so one needs
> > to use -g -gdwarf64 or similar.
> > 
> > Ok for trunk if it passes bootstrap/regtest?
> 
> OK.  Note there's
> 
> /* Various DIE's use offsets relative to the beginning of the
>.debug_info section to refer to each other.  */
> 
> typedef long int dw_offset;
> 
> which on L32 hosts means we might not support dwarf64 generation
> for CUs that do not fit in 31bits?  Should we change that to
> int64_t?  Or should we sorry() for -gdwarf64 on 32bit hosts?
> 
> There's also
> 
>   unsigned long die_abbrev;
> 
> and other uses of '[unsigned] long' in dwarf2out.c.

One thing is 32-bit hosts vs. 64-bit targets, and we maybe should indeed use
HOST_WIDE_INT for dw_offset; not sure about die_abbrev, if the .debug_abbrev
section is over 4GiB in one TU, then that would be already massive amounts of 
debug
info (.debug_info is typically 10-100x times larger than .debug_abbrev).
Even the HOST_WIDE_INT dw_offset might not be immediately necessary, if a
32-bit host needs to emit 4GiB of .debug_info for one TU, then I'm pretty
sure we need at least 4 times that much of compile memory if not much more,
our in memory DIE representation isn't exactly compact.
The advantage of DWARF 64-bit is not (at least for the time being) a single
TU exceeding the limits, but when linking a shared library with tons of TUs
where we exceed those limits then (for some large libraries we are already
close to those limits or over them now).

Another thing is 32-bit targets.  For them the limitations of the object
file format (e.g. 32-bit ELF) will not allow > 2GiB debug info anyway,
and as I've just tested, e.g. on x86_64 with -m32 -gdwarf64 will not work
even on tiny testcases:
as: pr64716.o: unsupported relocation type: 0x1
pr64716.s: Assembler messages:
pr64716.s:6013: Error: cannot represent relocation type BFD_RELOC_64
as: pr64716.o: unsupported relocation type: 0x1
pr64716.s:6015: Error: cannot represent relocation type BFD_RELOC_64
as: pr64716.o: unsupported relocation type: 0x1
pr64716.s:6017: Error: cannot represent relocation type BFD_RELOC_64
So yes, we can either do a sorry, error, or could just avoid 64-bit
relocations (depending on endianity instead of emitting
.quad expression_that_needs_relocation
emit
.long expression_that_needs_relocation, 0
or
.long 0, expression_that_needs_relocation
So, which way do we want to go?

> Do dwarf32 and dwarf64 objects inter-operate just fine (as long as
> the linker can resolve all relocations w/o truncating)?

I think it should, but whether all debug info consumers and other tools
will be able to cope with it remains to be seen.  If they have bugs, those
should be fixed.  By adding the -gdwarf{32,64} switches we allow them to try
that.

Jakub

Re: [PATCH] dwarf: Add -gdwarf{32,64} options

[Richard Biener]

On Tue, 1 Dec 2020, Jakub Jelinek wrote:

> On Tue, Dec 01, 2020 at 11:49:43AM +0100, Richard Biener wrote:
> > On Tue, 1 Dec 2020, Jakub Jelinek wrote:
> > 
> > > Hi!
> > > 
> > > The following patch makes the choice between 32-bit and 64-bit DWARF 
> > > formats
> > > selectable by command line switch, rather than being hardcoded through
> > > DWARF_OFFSET_SIZE macro.
> > > 
> > > The options themselves don't turn on debug info themselves, so one needs
> > > to use -g -gdwarf64 or similar.
> > > 
> > > Ok for trunk if it passes bootstrap/regtest?
> > 
> > OK.  Note there's
> > 
> > /* Various DIE's use offsets relative to the beginning of the
> >.debug_info section to refer to each other.  */
> > 
> > typedef long int dw_offset;
> > 
> > which on L32 hosts means we might not support dwarf64 generation
> > for CUs that do not fit in 31bits?  Should we change that to
> > int64_t?  Or should we sorry() for -gdwarf64 on 32bit hosts?
> > 
> > There's also
> > 
> >   unsigned long die_abbrev;
> > 
> > and other uses of '[unsigned] long' in dwarf2out.c.
> 
> One thing is 32-bit hosts vs. 64-bit targets, and we maybe should indeed use
> HOST_WIDE_INT for dw_offset; not sure about die_abbrev, if the .debug_abbrev
> section is over 4GiB in one TU, then that would be already massive amounts of 
> debug
> info (.debug_info is typically 10-100x times larger than .debug_abbrev).
> Even the HOST_WIDE_INT dw_offset might not be immediately necessary, if a
> 32-bit host needs to emit 4GiB of .debug_info for one TU, then I'm pretty
> sure we need at least 4 times that much of compile memory if not much more,
> our in memory DIE representation isn't exactly compact.
> The advantage of DWARF 64-bit is not (at least for the time being) a single
> TU exceeding the limits, but when linking a shared library with tons of TUs
> where we exceed those limits then (for some large libraries we are already
> close to those limits or over them now).
> 
> Another thing is 32-bit targets.  For them the limitations of the object
> file format (e.g. 32-bit ELF) will not allow > 2GiB debug info anyway,
> and as I've just tested, e.g. on x86_64 with -m32 -gdwarf64 will not work
> even on tiny testcases:
> as: pr64716.o: unsupported relocation type: 0x1
> pr64716.s: Assembler messages:
> pr64716.s:6013: Error: cannot represent relocation type BFD_RELOC_64
> as: pr64716.o: unsupported relocation type: 0x1
> pr64716.s:6015: Error: cannot represent relocation type BFD_RELOC_64
> as: pr64716.o: unsupported relocation type: 0x1
> pr64716.s:6017: Error: cannot represent relocation type BFD_RELOC_64
> So yes, we can either do a sorry, error, or could just avoid 64-bit
> relocations (depending on endianity instead of emitting
> .quad expression_that_needs_relocation
> emit
> .long expression_that_needs_relocation, 0
> or
> .long 0, expression_that_needs_relocation
> So, which way do we want to go?

64bit relocs are not required here?  That is, can one with
dwarf64 choose 32bit forms for select offsets (like could
dwz exploit this?)?

If so the above might be OK, otherwise I guess a sorry()
would be more to the point.

> > Do dwarf32 and dwarf64 objects inter-operate just fine (as long as
> > the linker can resolve all relocations w/o truncating)?
> 
> I think it should, but whether all debug info consumers and other tools
> will be able to cope with it remains to be seen.  If they have bugs, those
> should be fixed.  By adding the -gdwarf{32,64} switches we allow them to try
> that.
> 
>   Jakub
> 
> 

-- 
Richard Biener 
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)

Re: [PATCH] dwarf: Add -gdwarf{32,64} options

[Jakub Jelinek via Gcc-patches]

On Tue, Dec 01, 2020 at 01:03:07PM +0100, Richard Biener wrote:
> > So yes, we can either do a sorry, error, or could just avoid 64-bit
> > relocations (depending on endianity instead of emitting
> > .quad expression_that_needs_relocation
> > emit
> > .long expression_that_needs_relocation, 0
> > or
> > .long 0, expression_that_needs_relocation
> > So, which way do we want to go?
> 
> 64bit relocs are not required here?  That is, can one with
> dwarf64 choose 32bit forms for select offsets (like could
> dwz exploit this?)?

I guess it depends on whether for 32-bit target and -gdwarf64, when
calling dw2_assemble_integer with non-CONST_INT argument we only
need positive values or might need negative ones too.
Because positive ones can be easily emulated through that
.long expression, 0
or
.long 0, expression
depending on endianity, but I'm afraid there is no way to emit
0 or -1 depending on the sign of expression, when it needs relocations.
Looking through dw2_asm_output_delta calls, at least the vast majority
of the calls seem to guarantee being positive, not 100% sure about
one case in .debug_line views, but I'd hope it is ok too.
In most cases, the deltas are between two labels where the first one
in the arguments is later in the same section than the other one,
or where the second argument is the start of a section or another section
base.

This patch implements that, dunno if we need also configure tests for that
or not, maybe some 32-bit targets use 64-bit ELF and can handle such
relocations.

2020-12-01  Jakub Jelinek  

* dwarf2asm.c (dw2_assemble_integer): Handle size twice as large
as DWARF2_ADDR_SIZE if x is not a scalar int by emitting it as
two halves, one with x and the other with const0_rtx, ordered
depending on endianity.

--- gcc/dwarf2asm.c.jj  2020-01-12 11:54:36.558411221 +0100
+++ gcc/dwarf2asm.c 2020-12-01 13:42:38.347298352 +0100
@@ -46,6 +46,52 @@ along with GCC; see the file COPYING3.
 void
 dw2_assemble_integer (int size, rtx x)
 {
+  if (size == 2 * DWARF2_ADDR_SIZE && !CONST_SCALAR_INT_P (x))
+{
+  /* On 32-bit targets with -gdwarf64, DImode values with
+relocations usually result in assembler errors.  Assume
+all such values are positive and emit the relocation only
+in the least significant half.  */
+  const char *op = integer_asm_op (DWARF2_ADDR_SIZE, FALSE);
+  if (BYTES_BIG_ENDIAN)
+   {
+ if (op)
+   {
+ fputs (op, asm_out_file);
+ fprint_whex (asm_out_file, 0);
+ fputs (", ", asm_out_file);
+ output_addr_const (asm_out_file, x);
+   }
+ else
+   {
+ assemble_integer (const0_rtx, DWARF2_ADDR_SIZE,
+   BITS_PER_UNIT, 1);
+ putc ('\n', asm_out_file);
+ assemble_integer (x, DWARF2_ADDR_SIZE,
+   BITS_PER_UNIT, 1);
+   }
+   }
+  else
+   {
+ if (op)
+   {
+ fputs (op, asm_out_file);
+ output_addr_const (asm_out_file, x);
+ fputs (", ", asm_out_file);
+ fprint_whex (asm_out_file, 0);
+   }
+ else
+   {
+ assemble_integer (x, DWARF2_ADDR_SIZE,
+   BITS_PER_UNIT, 1);
+ putc ('\n', asm_out_file);
+ assemble_integer (const0_rtx, DWARF2_ADDR_SIZE,
+   BITS_PER_UNIT, 1);
+   }
+   }
+  return;
+}
+
   const char *op = integer_asm_op (size, FALSE);
 
   if (op)


Jakub

Re: [PATCH] c++: Implement LWG3396 Clarify point of reference for source_location::current() [PR80780, PR93093]

[Jonathan Wakely via Gcc-patches]

On 01/12/20 09:59 +0100, Jakub Jelinek wrote:

Hi!

While std::source_location::current () is static consteval source_location
current() noexcept; in the standard, it also says with LWG3396:
"Any call to current that appears as a default member initializer
([class.mem]), or as a subexpression thereof, should correspond to the
location of the constructor definition or aggregate initialization that uses
the default member initializer.  Any call to current that appears as a
default argument ([dcl.fct.default]), or as a subexpression thereof, should
correspond to the location of the invocation of the function that uses the
default argument ([expr.call])."
so it must work as compiler magic rather than normal immediate functions,
in particular we need to defer its evaluation when parsing default arguments
or nsdmis.

The following patch implements that.


Nice.


Bootstrapped/regtested on x86_64-linux and i686-linux.

Jon, does it fix all the library testcases you and JeanHeyd had?


Most of them pass now, but this case fails:

using namespace std;

struct S {
  const char* func;
  unsigned line = 0;
  source_location loc = source_location::current();

  S(int l, source_location loc = source_location::current())
  : func(__FUNCTION__), line(l), loc(loc) // values of loc will be from 
call-site
  {}

  S(void*)
  : func(__FUNCTION__), line(__LINE__) // values of loc should be hereabouts
  {}
};

int main()
{
  S s0(__LINE__);
  assert( s0.loc.line() == s0.line );
  assert( !__builtin_strcmp(s0.loc.file_name(), __FILE__) );
  assert( !__builtin_strcmp(s0.loc.function_name(), __FUNCTION__) );
}

The location is the constructor parameter list, but it should be in
main() where the default argument is evaluated.

JeanHeyd's test also verify that the function_name() for the NSDMI
cases is "s::s" but that fails because __FUNCTION__ is only "s".

I mentioned in PR 80780 that a __builtin__PRETTY_FUNCTION would have
been nice, because __FUNCTION__ isn't very useful for C++, because of
overloading and namespace/class scopes. There are an unlimited number
of functions that have __FUNCTION__ == "s", e.g. "ns::s(int)" and
"ns::s()" and "another_scope::s::s(T...)" etc.

Since __builtin_source_location() can do whatever it wants (without
needing to add __builtin__PRETTY_FUNCTION) it might be nice to use the
__PRETTY_FUNCTION__ string. JeanHeyd's tests would still need changes,
because the name would be "s::s(void*)" not "s::s" but that still
seems better for users.

Re: [committed] Fix hppa64-hpux11 build to remove source paths from embedded path.

[John David Anglin]

On 2020-12-01 4:29 a.m., Iain Sandoe wrote:
> It seems that you didn’t apply (or generate?) the gcc/configure change from 
> the libtool one.
>
> Happy to do that before applying mine - but thought you might want to check 
> first,
> thanks
Yes please.  It should have been regenerated.

Thanks,
Dave

-- 
John David Anglin  dave.ang...@bell.net

[PATCH] arm: Improve documentation for effective target 'arm_softfloat'

[Andrea Corallo via Gcc-patches]

Hi all,

I'd like to submit the following patch to better specify the meaning
of the 'arm_softfloat' effective target.

As I've recently discovered we can have cases where '-mfloat-abi=hard'
is used and the compiler correctly defines '__SOFTFP__'.

Effectively 'arm_softfloat' is checking if the target requires floating
point emulation but not what ABI is used, so I think would be nice to
specify that in the documentation.

Okay for trunk?

Thanks

  Andrea
  
>From 67e74689e4332d33c3f27119dc21a7722bb6125b Mon Sep 17 00:00:00 2001
From: Andrea Corallo 
Date: Tue, 1 Dec 2020 11:21:33 +0100
Subject: [PATCH] arm: Improve documentation for effective target
 'arm_softfloat'

gcc/ChangeLog

2020-12-01  Andrea Corallo  

* doc/sourcebuild.texi (arm_softfloat): Improve documentation.

gcc/testsuite/ChangeLog

2020-12-01  Andrea Corallo  

* lib/target-supports.exp (check_effective_target_arm_softfloat):
Improve documentation.
---
 gcc/doc/sourcebuild.texi  | 3 +--
 gcc/testsuite/lib/target-supports.exp | 4 ++--
 2 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi
index 852eaa2e676..72b83748318 100644
--- a/gcc/doc/sourcebuild.texi
+++ b/gcc/doc/sourcebuild.texi
@@ -1799,8 +1799,7 @@ variant of the ABI for the ARM Architecture (as selected 
with
 @code{-mfloat-abi=hard}).
 
 @item arm_softfloat
-ARM target uses the soft-float ABI with no floating-point instructions
-used whatsoever (as selected with @code{-mfloat-abi=soft}).
+ARM target uses emulated floating point operations.
 
 @item arm_hard_vfp_ok
 ARM target supports @code{-mfpu=vfp -mfloat-abi=hard}.
diff --git a/gcc/testsuite/lib/target-supports.exp 
b/gcc/testsuite/lib/target-supports.exp
index ff6bc5f4b92..24ff9fa0476 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -5658,8 +5658,8 @@ proc check_effective_target_arm_hf_eabi { } {
 }]
 }
 
-# Return 1 if this is an ARM target that uses the soft float ABI
-# with no floating-point instructions at all (e.g. -mfloat-abi=soft).
+# Return 1 if this is an ARM target uses emulated floating point
+# operations.
 
 proc check_effective_target_arm_softfloat { } {
 return [check_no_compiler_messages arm_softfloat object {
-- 
2.20.1

[PATCH] if-to-switch: Support chain with 2 BBs.

[Martin Liška]

Hello.

The following patch is a small tweak than enables more opportunities.
It fixes bug in PR88702 and I see 54 transformations to happen in SPEC 2006.
Apart from that, I fixed a minor issues which I spotted during bootstrap.

Patch can bootstrap on x86_64-linux-gnu and survives regression tests.

Ready to be installed?
Thanks,
Martin
>From a27dca2d5ef87b493d1ab50da68d0b24dc9fdd93 Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Tue, 1 Dec 2020 12:18:46 +0100
Subject: [PATCH] if-to-switch: Support chain with 2 BBs.

As seen in the test-case, even 2 BBs can handle interesting
cases covered by a jump table or a bit-test.

gcc/ChangeLog:

	PR tree-optimization/88702
	* gimple-if-to-switch.cc (pass_if_to_switch::execute):
	Require at least 2 BBs.
	* gimple-if-to-switch.cc (find_conditions): Require
	equal precision for low and high of a range.

gcc/testsuite/ChangeLog:

	PR tree-optimization/88702
	* gcc.dg/tree-ssa/if-to-switch-9.c: New test.
---
 gcc/gimple-if-to-switch.cc |  6 --
 gcc/testsuite/gcc.dg/tree-ssa/if-to-switch-9.c | 11 +++
 2 files changed, 15 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/if-to-switch-9.c

diff --git a/gcc/gimple-if-to-switch.cc b/gcc/gimple-if-to-switch.cc
index d132064fb9b..19ec6318229 100644
--- a/gcc/gimple-if-to-switch.cc
+++ b/gcc/gimple-if-to-switch.cc
@@ -430,7 +430,9 @@ find_conditions (basic_block bb,
   for (unsigned i = 0; i < info.m_ranges.length (); ++i)
 	if (info.m_ranges[i].exp == NULL_TREE
 	|| info.m_ranges[i].low == NULL_TREE
-	|| info.m_ranges[i].high == NULL_TREE)
+	|| info.m_ranges[i].high == NULL_TREE
+	|| (TYPE_PRECISION (TREE_TYPE (info.m_ranges[i].low))
+		!= TYPE_PRECISION (TREE_TYPE (info.m_ranges[i].high
 	  return;
 
   for (unsigned i = 1; i < info.m_ranges.length (); ++i)
@@ -525,7 +527,7 @@ pass_if_to_switch::execute (function *fun)
 	}
 
 	  chain->m_entries.reverse ();
-	  if (chain->m_entries.length () >= 3
+	  if (chain->m_entries.length () >= 2
 	  && chain->check_non_overlapping_cases ()
 	  && chain->is_beneficial ())
 	{
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/if-to-switch-9.c b/gcc/testsuite/gcc.dg/tree-ssa/if-to-switch-9.c
new file mode 100644
index 000..d0e9df75f55
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/if-to-switch-9.c
@@ -0,0 +1,11 @@
+/* PR tree-optimization/88702 */
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-iftoswitch-optimized" } */
+
+int IsHTMLWhitespace(int aChar) { 
+  return aChar == 0x0009 || aChar == 0x000A ||  
+ aChar == 0x000C || aChar == 0x000D ||  
+ aChar == 0x0020; 
+}
+
+/* { dg-final { scan-tree-dump "Condition chain with 2 BBs transformed into a switch statement." "iftoswitch" } } */
-- 
2.29.2

[committed] libstdc++: Simplify detection of built-in functions

[Jonathan Wakely via Gcc-patches]

This fixes a regression affecting the Intel compiler. Because that
compiler defines __GNUC__ to match whatever version of GCC it finds on
the host system, it might claim to be a brand new GCC despite not
actually supporting all the built-ins that the latest GCC supports. This
means the config checks for __GNUC__ don't work. Most recently this
broke when r11-3569-g73ae6eb572515ad627b575a7fbdfdd47a4368e1c switched
us from using __is_same_as to __is_same when __GNUC__ >= 11.

Because __has_builtin is supported by all of GCC, Clang, and Intel we can
use that to reliably detect whether a given built-in is supported,
instead of hardcoding anything based on __GNUC__. The big caveat is
that for versions of Clang <= 9.0.0 and for (as far as I can tell) all
released versions of Intel icc, __has_builtin only evaluates to true for
built-ins with a name starting "__builtin_". For __is_aggregate,
__is_same, and __has_unique_object_representations it's necessary to use
__is_identifier to check if it's a valid identifeir token instead.

The solution used in this patch is to define _GLIBCXX_HAS_BUILTIN and
use that instead of using __has_builtin directly. For compilers that
define __is_identifier as well as __has_builtin we use both, so that if
__has_builtin evaluates to false we try again using !__is_identifier.

libstdc++-v3/ChangeLog:

* include/bits/c++config (_GLIBCXX_HAS_BUILTIN): Define macro to
work around different implementations of __has_builtin.
(_GLIBCXX_HAVE_BUILTIN_HAS_UNIQ_OBJ_REP)
(_GLIBCXX_HAVE_BUILTIN_IS_AGGREGATE)
(_GLIBCXX_HAVE_BUILTIN_IS_CONSTANT_EVALUATED)
(_GLIBCXX_HAVE_BUILTIN_IS_SAME, _GLIBCXX_HAVE_BUILTIN_LAUNDER):
Define using _GLIBCXX_HAS_BUILTIN.

Tested powerpc64le-linux. Committed to trunk.

commit 6aa12274007bccbae2691a9d336c37fe167bb535
Author: Jonathan Wakely 
Date:   Tue Dec 1 14:14:18 2020

libstdc++: Simplify detection of built-in functions

This fixes a regression affecting the Intel compiler. Because that
compiler defines __GNUC__ to match whatever version of GCC it finds on
the host system, it might claim to be a brand new GCC despite not
actually supporting all the built-ins that the latest GCC supports. This
means the config checks for __GNUC__ don't work. Most recently this
broke when r11-3569-g73ae6eb572515ad627b575a7fbdfdd47a4368e1c switched
us from using __is_same_as to __is_same when __GNUC__ >= 11.

Because __has_builtin is supported by all of GCC, Clang, and Intel we can
use that to reliably detect whether a given built-in is supported,
instead of hardcoding anything based on __GNUC__. The big caveat is
that for versions of Clang <= 9.0.0 and for (as far as I can tell) all
released versions of Intel icc, __has_builtin only evaluates to true for
built-ins with a name starting "__builtin_". For __is_aggregate,
__is_same, and __has_unique_object_representations it's necessary to use
__is_identifier to check if it's a valid identifeir token instead.

The solution used in this patch is to define _GLIBCXX_HAS_BUILTIN and
use that instead of using __has_builtin directly. For compilers that
define __is_identifier as well as __has_builtin we use both, so that if
__has_builtin evaluates to false we try again using !__is_identifier.

libstdc++-v3/ChangeLog:

* include/bits/c++config (_GLIBCXX_HAS_BUILTIN): Define macro to
work around different implementations of __has_builtin.
(_GLIBCXX_HAVE_BUILTIN_HAS_UNIQ_OBJ_REP)
(_GLIBCXX_HAVE_BUILTIN_IS_AGGREGATE)
(_GLIBCXX_HAVE_BUILTIN_IS_CONSTANT_EVALUATED)
(_GLIBCXX_HAVE_BUILTIN_IS_SAME, _GLIBCXX_HAVE_BUILTIN_LAUNDER):
Define using _GLIBCXX_HAS_BUILTIN.

diff --git a/libstdc++-v3/include/bits/c++config 
b/libstdc++-v3/include/bits/c++config
index 2e6c880ad95..27302ed392e 100644
--- a/libstdc++-v3/include/bits/c++config
+++ b/libstdc++-v3/include/bits/c++config
@@ -653,35 +653,36 @@ namespace std
 #define _GLIBCXX_USE_FLOAT128
 #endif
 
-#if __GNUC__ >= 7
-// Assume these are available if the compiler claims to be a recent GCC:
+#ifdef __has_builtin
+# ifdef __is_identifier
+// Intel and older Clang require !__is_identifier for some built-ins:
+#  define _GLIBCXX_HAS_BUILTIN(B) __has_builtin(B) || ! __is_identifier(B)
+# else
+#  define _GLIBCXX_HAS_BUILTIN(B) __has_builtin(B)
+# endif
+#endif
+
+#if _GLIBCXX_HAS_BUILTIN(__has_unique_object_representations)
 # define _GLIBCXX_HAVE_BUILTIN_HAS_UNIQ_OBJ_REP 1
+#endif
+
+#if _GLIBCXX_HAS_BUILTIN(__is_aggregate)
 # define _GLIBCXX_HAVE_BUILTIN_IS_AGGREGATE 1
+#endif
+
+#if _GLIBCXX_HAS_BUILTIN(__builtin_is_constant_evaluated)
+#  define _GLIBCXX_HAVE_BUILTIN_IS_CONSTANT_EVALUATED 1
+#endif
+
+#if _GLIBCXX_HAS_BUILTIN(__is_same)
+#  define _GLIBCXX_HAVE_BUILTIN_IS_SAME 1
+#endif
+
+#if _GLIBCXX_HAS_BUILTIN(__builtin_launder)
 # define _GLIBCXX_HAVE_BUILTIN_LA

Re: [PATCH] Add feature test macro for atomic::wait

[Jonathan Wakely via Gcc-patches]

On 30/11/20 10:17 -0800, Thomas Rodgers wrote:

From: Thomas Rodgers 

Adds __cpp_lib_atomic_wait feature test macro which was overlooked in
the initial commit of this feature. Replaces uses of
_GLIBCXX_HAVE_ATOMIC_WAIT.

libstdc++-v3/ChangeLog:

* include/bits/atomic_base.h: Replace usage of
_GLIBCXX_HAVE_ATOMIC_WAIT with __cpp_lib_atomic_wait.
* include/bits/atomic_timed_wait.h: Likewise.
* include/bits/atomic_wait.h: Define __cpp_lib_atomic_wait
feature test macro.
* include/bits/semaphore_base: Replace usage of
_GLIBCXX_HAVE_ATOMIC_WAIT with __cpp_lib_atomic_wait.
* include/std/atomic: Likewise.
* include/std/latch: Likewise.
* include/std/semaphore: Likewise.
* include/std/version: Define __cpp_lib_atomic wait
feature test macro and replace usage of
_GLIBCXX_HAVE_ATOMIC_WAIT.
* testsuite/29_atomics/atomic/wait_notify/1.cc: New test.
* testsuite/29_atomics/atomic/wait_notify/2.cc: Likewise.

---
libstdc++-v3/include/bits/atomic_base.h   | 36 +--
libstdc++-v3/include/bits/atomic_timed_wait.h |  5 +--
libstdc++-v3/include/bits/atomic_wait.h   |  3 +-
libstdc++-v3/include/bits/semaphore_base.h|  4 +--
libstdc++-v3/include/std/atomic   | 16 -
libstdc++-v3/include/std/latch|  4 +--
libstdc++-v3/include/std/semaphore|  4 +--
libstdc++-v3/include/std/version  |  7 ++--
.../29_atomics/atomic/wait_notify/1.cc| 28 +++
.../29_atomics/atomic/wait_notify/2.cc| 29 +++
10 files changed, 98 insertions(+), 38 deletions(-)
create mode 100644 libstdc++-v3/testsuite/29_atomics/atomic/wait_notify/1.cc
create mode 100644 libstdc++-v3/testsuite/29_atomics/atomic/wait_notify/2.cc

diff --git a/libstdc++-v3/include/bits/atomic_base.h 
b/libstdc++-v3/include/bits/atomic_base.h
index d0d962d3047..ad4e24b4d20 100644
--- a/libstdc++-v3/include/bits/atomic_base.h
+++ b/libstdc++-v3/include/bits/atomic_base.h
@@ -230,7 +230,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
  return __v == __GCC_ATOMIC_TEST_AND_SET_TRUEVAL;
}

-#ifdef _GLIBCXX_HAVE_ATOMIC_WAIT
+#ifdef __cpp_lib_atomic_wait


I've not always been consistent about using #if or #ifdef for
__cpp_lib macros, but let's not make that worse in a single patch. I
think we should just use #if for __cpp_lib macros. That affects
several places in the patch.


_GLIBCXX_ALWAYS_INLINE void
wait(bool __old,
memory_order __m = memory_order_seq_cst) const noexcept
@@ -253,7 +253,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
{ std::__atomic_notify(&_M_i, true); }

// TODO add const volatile overload
-#endif // HAVE_ATOMIC_WAIT
+#endif // __cpp_lib_atomic_wait
#endif // C++20

_GLIBCXX_ALWAYS_INLINE void
@@ -604,7 +604,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   __cmpexch_failure_order(__m));
  }

-#if __cplusplus > 201703L && defined _GLIBCXX_HAVE_ATOMIC_WAIT
+#if __cpp_lib_atomic_wait
  _GLIBCXX_ALWAYS_INLINE void
  wait(__int_type __old,
  memory_order __m = memory_order_seq_cst) const noexcept
@@ -627,7 +627,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
  { std::__atomic_notify(&_M_i, true); }

  // TODO add const volatile overload
-#endif // C++20 && HAVE_ATOMIC_WAIT
+#endif // __cpp_lib_atomic_wait

  _GLIBCXX_ALWAYS_INLINE __int_type
  fetch_add(__int_type __i,
@@ -898,7 +898,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   int(__m1), int(__m2));
  }

-#if __cplusplus > 201703L && defined _GLIBCXX_HAVE_ATOMIC_WAIT
+#if __cpp_lib_atomic_wait
  _GLIBCXX_ALWAYS_INLINE void
  wait(__pointer_type __old,
   memory_order __m = memory_order_seq_cst) noexcept
@@ -921,7 +921,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
  { std::__atomic_notify(&_M_p, true); }

  // TODO add const volatile overload
-#endif // C++20 && HAVE_ATOMIC_WAIT
+#endif // __cpp_lib_atomic_wait

  _GLIBCXX_ALWAYS_INLINE __pointer_type
  fetch_add(ptrdiff_t __d,
@@ -1011,7 +1011,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 int(__success), int(__failure));
  }

-#if __cplusplus > 201703L && defined _GLIBCXX_HAVE_ATOMIC_WAIT
+#if __cpp_lib_atomic_wait
template
  _GLIBCXX_ALWAYS_INLINE void
  wait(const _Tp* __ptr, _Val<_Tp> __old,
@@ -1036,7 +1036,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
  { std::__atomic_notify(__ptr, true); }

  // TODO add const volatile overload
-#endif // C++20 && HAVE_ATOMIC_WAIT
+#endif // __cpp_lib_atomic_wait

template
  _GLIBCXX_ALWAYS_INLINE _Tp
@@ -1291,7 +1291,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   __cmpexch_failure_order(__order));
  }

-#ifdef _GLIBCXX_HAVE_ATOMIC_WAIT
+#ifdef __cpp_lib_atomic_wait
  _GLIBCXX_ALWAYS_INLINE void
  wait(_Fp __old, memory_order __m = memory_order_seq_cst) const noexcept

Re: [PATCH] c++: Implement LWG3396 Clarify point of reference for source_location::current() [PR80780, PR93093]

[Jakub Jelinek via Gcc-patches]

On Tue, Dec 01, 2020 at 01:03:52PM +, Jonathan Wakely wrote:
> Most of them pass now, but this case fails:
> 
> using namespace std;
> 
> struct S {
>   const char* func;
>   unsigned line = 0;
>   source_location loc = source_location::current();
> 
>   S(int l, source_location loc = source_location::current())
>   : func(__FUNCTION__), line(l), loc(loc) // values of loc will be from 
> call-site
>   {}
> 
>   S(void*)
>   : func(__FUNCTION__), line(__LINE__) // values of loc should be hereabouts
>   {}
> };
> 
> int main()
> {
>   S s0(__LINE__);
>// ...
> }

Ah, I see what is going on here.

using namespace std;

struct S {
  const char *func;
  unsigned line = 0;
  source_location loc = source_location::current ();

  S (int l, source_location);

  S (void *)
  : func(__FUNCTION__), line(__LINE__) // values of loc should be hereabouts
  {}
};

S::S (int l, source_location loc = source_location::current ())
: func(__FUNCTION__), line(l), loc(loc) // values of loc will be from call-site
{}

int
main ()
{
  S s0(__LINE__);
///...
}

would work fine.

We have (since this patch, but before that it was already mostly like that
too):
  && DECL_IMMEDIATE_FUNCTION_P (fndecl)
  && cp_unevaluated_operand == 0
  && (current_function_decl == NULL_TREE
  || !DECL_IMMEDIATE_FUNCTION_P (current_function_decl))
  && (current_binding_level->kind != sk_function_parms
  || (!current_binding_level->immediate_fn_ctx_p
  && !source_location_current_p (fndecl)))
  && (!parsing_nsdmi () || !source_location_current_p (fndecl)))
as the condition whether to evaluate an immediate function right away or
not.
The intent is do not evaluate it in default arguments of immediate functions
(will be done at constant expression evaluation time instead), and (newly)
for std::source_location::current () not evaluated in nsdmis and in default
arguments.

The problem is that with your/JeanHeyd's testcase above, the default
argument parsing is deferred until the whole class is parsed and then
cp_parser_late_parsing_default_args performs that deferred parsing.
Except at this point nothing creates the sk_function_params scope.

So, I think we need some way for the build_over_call code to know if
it is called from within cp_parser_late_parsing_default_args and whether
for an immediate function or not, and take that into account too.

I see cp_parser_late_parsing_default_args calls push_defarg_context,
so perhaps it could check default_arg_context vector, except that
convert_default_arg calls that too around calling break_out_target_exprs
which in the patch is used to perform the late evaluation of the
std::source_location::current() calls.  So it might need to temporarily
pop_defarg_context before break_out_target_exprs and push it again?

Jason, any thoughts on that?

And guess we need some tests if it works as expected also in templates;
I bet we create scope for the default params in that case, but I could be
wrong.

Thanks

Jakub

Re: [PATCH] libstdc++: Add C++ runtime support for new 128-bit long double format

[Jonathan Wakely via Gcc-patches]

On 30/11/20 17:29 -0600, Segher Boessenkool wrote:

Hi!

Thank you for all this.

On Wed, Nov 11, 2020 at 09:50:01PM +, Jonathan Wakely wrote:

This adds support for the new __ieee128 long double format on
powerpc64le targets.



* testsuite/27_numerics/complex/abi_tag.cc: Add u9___ieee128 to
regex matching expected symbols.


One less underscore.


Thanks. There was also a misnamed test in the changelog which I've
also fixed.


libstdc++-v3/ChangeLog:

* Makefile.in:
* config.h.in:


(etc.)  Something missing here?


It's just an empty changelog template added by my prepare-commit-msg.
The complete changelog was present above it already. I've removed the
duplication, thanks.

Updated patch coming shortly ...

Re: [PATCH] libstdc++: Add C++ runtime support for new 128-bit long double format

[Jonathan Wakely via Gcc-patches]

On 30/11/20 16:30 -0500, Michael Meissner via Libstdc++ wrote:

Jonathan, could you send a fresh set of patches (or at least replacements)?  I
tried installing the patches on a master branch I checked out this morning, and
I got two rejects:


I don't understand why those chunks failed, but I'll rebase and send a
new patch ASAP.

Re: Add pretty-printing support for __is_nothrow_{assignable, constructible}. [PR98054]

[Jason Merrill via Gcc-patches]

On 11/30/20 8:50 AM, Marek Polacek wrote:

On Mon, Nov 30, 2020 at 01:19:32PM +0200, Ville Voutilainen via Gcc-patches 
wrote:

OK for trunk if full testsuite passes? Should we consider having some sort
of test that catches such omissions?


IMHO this doesn't require a test.


2020-11-30  Ville Voutilainen  

 gcc/

>>

 PR c++/98054
 * cp/cxx-pretty-print.c (pp_cxx_trait_expression):
 Add support for __is_nothrow_{assignable,constructible}.


No "cp/" please.


And change the gcc/ above to gcc/cp/.  OK with that change.


diff --git a/gcc/cp/cxx-pretty-print.c b/gcc/cp/cxx-pretty-print.c
index 058b9c2f4fc..1cdf0772a6b 100644
--- a/gcc/cp/cxx-pretty-print.c
+++ b/gcc/cp/cxx-pretty-print.c
@@ -2666,6 +2666,12 @@ pp_cxx_trait_expression (cxx_pretty_printer *pp, tree t)
  case CPTK_IS_CONSTRUCTIBLE:
pp_cxx_ws_string (pp, "__is_constructible");
break;
+case CPTK_IS_NOTHROW_ASSIGNABLE:
+  pp_cxx_ws_string (pp, "__is_nothrow_assignable");
+  break;
+case CPTK_IS_NOTHROW_CONSTRUCTIBLE:
+  pp_cxx_ws_string (pp, "__is_nothrow_constructible");
+  break;
  
  default:

gcc_unreachable ();


Looks fine, thanks.

Marek

Re: [PATCH] libstdc++: Add C++ runtime support for new 128-bit long double format

[Jonathan Wakely via Gcc-patches]

On 01/12/20 15:10 +, Jonathan Wakely wrote:

On 30/11/20 16:30 -0500, Michael Meissner via Libstdc++ wrote:

Jonathan, could you send a fresh set of patches (or at least replacements)?  I
tried installing the patches on a master branch I checked out this morning, and
I got two rejects:


I don't understand why those chunks failed, but I'll rebase and send a
new patch ASAP.


Here's the rebased patch, with regenerated autoconf files and a fix
for the  header. I'd changed it since sending
the previous patch, and broke the "there's more than one long double"
case (i.e. the _GLIBCXX_LONG_DOUBLE_ALT128_COMPAT case).



commit 8739b6c0223fa38592b93e706c6e532fe027e3da
Author: Jonathan Wakely 
Date:   Mon Nov 12 10:47:41 2018

libstdc++: Add C++ runtime support for new 128-bit long double format

This adds support for the new __ieee128 long double format on
powerpc64le targets.

Most of the complexity comes from wanting a single libstdc++.so library
that contains the symbols needed by code compiled with both
-mabi=ibmlongdouble and -mabi=ieeelongdouble (and not forgetting
-mlong-double-64 as well!)

In a few places this just requires an extra overload, for example
std::from_chars has to be overloaded for both forms of long double.
That can be done in a single translation unit that defines overloads
for 'long double' and also '__ieee128', so that user code including
 will be able to link to a definition for either type of long
double. Those are the easy cases.

The difficult parts are (as for the std::string ABI transition) the I/O
and locale facets. In order to be able to write either form of long
double to an ostream such as std::cout we need the locale to contain a
std::num_put facet that can handle both forms. The same approach is
taken as was already done for supporting 64-bit long double and 128-bit
long double: adding extra overloads of do_put to the facet class. On
targets where the new long double code is enabled, the facets that are
registered in the locale at program startup have additional overloads so
that they can work with any long double type. Where this fails to work
is if user code installs its own facet, which will probably not have the
additional overloads and so will only be able to output one or the other
type. In practice the number of users expecting to be able to use their
own locale facets in code using a mix of -mabi=ibmlongdouble and
-mabi=ieeelongdouble is probably close to zero.

libstdc++-v3/ChangeLog:

* Makefile.in: Regenerate.
* config.h.in: Regenerate.
* config/abi/pre/gnu.ver: Make patterns less greedy.
* config/os/gnu-linux/ldbl-ieee128-extra.ver: New file with patterns
for IEEE128 long double symbols.
* configure: Regenerate.
* configure.ac: Enable alternative 128-bit long double format on
powerpc64*-*-linux*.
* doc/Makefile.in: Regenerate.
* fragment.am: Regenerate.
* include/Makefile.am: Set _GLIBCXX_LONG_DOUBLE_ALT128_COMPAT.
* include/Makefile.in: Regenerate.
* include/bits/c++config: Define inline namespace for new long
double symbols. Don't define _GLIBCXX_USE_FLOAT128 when it's the
same type as long double.
* include/bits/locale_classes.h [_GLIBCXX_LONG_DOUBLE_ALT128_COMPAT]
(locale::_Impl::_M_init_extra_ldbl128): Declare new member function.
* include/bits/locale_facets.h (_GLIBCXX_NUM_FACETS): Simplify by
only counting narrow character facets.
(_GLIBCXX_NUM_CXX11_FACETS): Likewise.
(_GLIBCXX_NUM_LBDL_ALT128_FACETS): New.
[_GLIBCXX_LONG_DOUBLE_ALT128_COMPAT] (num_get::__do_get): Define
vtable placeholder for __ibm128 long double type.
[_GLIBCXX_LONG_DOUBLE_ALT128_COMPAT && __LONG_DOUBLE_IEEE128__]
(num_get::__do_get): Declare vtable placeholder for __ibm128 long
double type.
[_GLIBCXX_LONG_DOUBLE_ALT128_COMPAT && __LONG_DOUBLE_IEEE128__]
(num_put::__do_put): Likewise.
* include/bits/locale_facets.tcc
[_GLIBCXX_LONG_DOUBLE_ALT128_COMPAT && __LONG_DOUBLE_IEEE128__]
(num_get::__do_get, num_put::__do_put): Define.
* include/bits/locale_facets_nonio.h
[_GLIBCXX_LONG_DOUBLE_ALT128_COMPAT && __LONG_DOUBLE_IEEE128__]
(money_get::__do_get): Declare vtable placeholder for __ibm128 long
double type.
[_GLIBCXX_LONG_DOUBLE_ALT128_COMPAT && __LONG_DOUBLE_IEEE128__]
(money_put::__do_put): Likewise.
* include/bits/locale_facets_nonio.tcc
[_GLIBCXX_LONG_DOUBLE_ALT128_COMPAT && __LONG_DOUBLE_IEEE128__]
(money_get::__do_get, money_put::__do_put): Define.
* include/ext

[PATCH] diagnostics: ignore -fmax-errors for ICE

[Martin Liška]

Right now I see:

./xgcc -B. ~/Programming/testcases/json.i -c -O2 -fmax-errors=1
/home/marxin/Programming/testcases/json.i: In function ‘json_variant_type’:
/home/marxin/Programming/testcases/json.i:22:1: error: non-integral type switch 
statement
   22 | }
  | ^
int *
switch (v_2(D))  [INV], case 0B:  [INV], case 5B:  [INV], case 6B: 
 [INV], case 7B:  [INV], case 8B:  [INV]>
compilation terminated due to -fmax-errors=1.

with the patch I get:

./xgcc -B. ~/Programming/testcases/json.i -c -O2 -fmax-errors=1 -c
/home/marxin/Programming/testcases/json.i: In function ‘json_variant_type’:
/home/marxin/Programming/testcases/json.i:22:1: error: non-integral type switch 
statement
   22 | }
  | ^
int *
switch (v_2(D))  [INV], case 0B:  [INV], case 5B:  [INV], case 6B: 
 [INV], case 7B:  [INV], case 8B:  [INV]>
during GIMPLE pass: iftoswitch
/home/marxin/Programming/testcases/json.i:22:1: internal compiler error: 
verify_gimple failed
0xe4478c verify_gimple_in_cfg(function*, bool)
/home/marxin/Programming/gcc/gcc/tree-cfg.c:5467
0xd201cf execute_function_todo
/home/marxin/Programming/gcc/gcc/passes.c:2042
0xd2101c do_per_function
/home/marxin/Programming/gcc/gcc/passes.c:1687
0xd2101c execute_todo
/home/marxin/Programming/gcc/gcc/passes.c:2096
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

gcc/ChangeLog:

* diagnostic.c (diagnostic_report_diagnostic): ICE causes to
terminate compiler immediately, so I guess it should be printed
always.
---
 gcc/diagnostic.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/diagnostic.c b/gcc/diagnostic.c
index fe509d88e6d..da20cdb2703 100644
--- a/gcc/diagnostic.c
+++ b/gcc/diagnostic.c
@@ -1172,7 +1172,7 @@ diagnostic_report_diagnostic (diagnostic_context *context,
return false;
 }
 
-  if (diagnostic->kind != DK_NOTE)

+  if (diagnostic->kind != DK_NOTE && diagnostic->kind != DK_ICE)
 diagnostic_check_max_errors (context);
 
   context->lock++;

--
2.29.2

Re: [PATCH v3 1/2] generate EH info for volatile asm statements (PR93981)

[J.W. Jagersma via Gcc-patches]

On 2020-11-30 17:47, J.W. Jagersma wrote:
> On 2020-11-23 09:20, Richard Biener wrote:
>> On Sun, Nov 22, 2020 at 5:38 PM J.W. Jagersma  wrote:
>>>
>>> On 2020-11-21 12:27, J.W. Jagersma wrote:
 ...
 Another idea I had is to introduce a new operand modifier, eg. '-', which
 would signify that the output *must* be considered clobbered on exception,
 and it would be an error if a copy is not possible.  Then the meaning of 
 '+'
 can be extended to say that the output must be valid regardless of whether 
 an
 exception occured or not.  Modifier '=' would mean the same as '+' with the
 additional implication that it is okay to eliminate earlier assignments, so
 that its value on the EH edge would be undefined.
>>>
>>> I've been working on implementing this, but I ran into an issue:
>>>
>>> First of all, in the first version of this patch I had to make sure that
>>> debug stmts were inserted across the fallthrough edge, so that they don't
>>> appear at the end a basic block.  I was surprised to find that this is no
>>> longer necessary.
>>>
>>> Next I discovered that the following test case fails (returns -1):
>>>
>>> int f ()
>>> {
>>>   int i = 0;
>>>   try { asm ("mov %0, 1; ud2" : "+r" (i)); }
>>>   catch (...) { }
>>>   return i - 1;
>>> }
>>>
>>> And this does succeed with a memory operand.
>>>
>>> It seems that something changed in the past few months, and now asm register
>>> outputs are already being assigned via a temporary variable, somewhere.  
>>> Does
>>> anyone know where that might be?
>>
>> It's likely out-of SSA / RTL expansion inserting a bogus copy or doing
>> coalescing on the EH edge.  Semantics of throwing asm stmts need to be
>> honored there.
>>
>> Richard.
> 
> Quick update.  I have a mostly working implementation now, the only case where
> it fails is when an asm clobbers all callee-saved registers.  In this one case
> the output is not available on the exception edge.  However this same case 
> does
> work correctly with an 'asm goto' that throws.
> 
> The problem I think is in lra_process_new_insns (lra.c:1878) where the 
> condition
> to insert new insns across edges is "JUMP_P (insn)", but this should happen 
> for
> throwing asms as well.  I figured "insn == BB_END (BLOCK_FOR_INSN (insn))" 
> would
> make sense but that causes all sorts of trouble (segfaults during bootstrap).
> 
> Would appreciate any advice on what to do here.

Just realized I can make it work by simply expanding throwing asms as jump
insns with no label.  I'm not sure about the specific semantic differences
between regular and jump insns, but this doesn't seem to have any negative
effects so far.

I will submit v4 after I finish running regression tests and writing docs and
changelogs.  Or if this is not an acceptable workaround, please let me know.

Re: [PATCH] detect allocation/deallocation mismatches in user-defined functions (PR94527)

[Martin Sebor via Gcc-patches]

On 11/30/20 3:53 PM, Jeff Law wrote:



On 11/13/20 2:45 PM, Martin Sebor via Gcc-patches wrote:

Bug 94527 is request from the kernel developers for an attribute
to indicate that a user-defined function deallocates an object
allocated by an earlier call to an allocation function.  Their
goal is to detect misuses of such functions and the pointers or
objects returned from them.

The recently submitted patches(*) enable the detection of a subset
of such misuses for standard allocation functions like malloc and
free, but those are just a small fraction of allocation/deallocation
functions used in practice, and only rarely used in the kernel
(mostly in utility programs). The attached patch extends attribute
malloc to enable this detection also for user-defined functions.

The design extends attribute malloc to accept one or two optional
arguments: one naming a deallocation function that deallocates
pointers returned from the malloc-like function, and another to
denote the position of the pointer argument in the deallocation
functions parameter list.  Any number of deallocators can be
associated with any number of allocators.  This makes it possible
to annotate, for example, all the POSIX  functions that
open and close FILE streams and detect mismatches between any
pairs that aren't suitable (in addition to calling free on
a FILE* returned from fopen, for instance).

An association with an allocator results in adding an internal
"*dealloc" attribute to the deallocator so that the former can
be quickly looked up based on a call to the latter.

Tested on x86_64-linux + Glibc & Binutils/GDB (no instances
of the new warnings).

Martin

[*] Prerequisite patch
add -Wmismatched-new-delete to middle end (PR 90629)
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/557987.html

PS In pr94527 Jonathan notes that failing to properly match pairs
of calls isn't limited to APIs that return pointers and applies
to other kinds of "handles" including integers (e.g., the POSIX
open/close APIs), and a detection of such mismatches would be
helpful as well.  David submitted a prototype of this for
the analyzer here:
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/44.html
I chose not to implement nonpointer detection for some of the same
reasons as mentioned in comment #8 on the bug (and also because
there's no support for it in the machinery I use).  I also didn't
use the same attribute as David, in part because I think it's better
to provide separate attributes for pointer APIs and for others
(integers), and in part also because the deallocated_by attribute
design as is cannot accommodate my goal of supporting app standard
functions (including the  freopen which "deallocates"
the third argument).

gcc-94527.diff

PR middle-end/94527 - Add an __attribute__ that marks a function as freeing an 
object

gcc/ChangeLog:

PR middle-end/94527
* builtins.c (gimple_call_alloc_p): Handle user-defined functions.
(fndecl_alloc_p): New helper.
(call_dealloc_argno): New helper.
(gimple_call_dealloc_p): Call it.
(call_dealloc_p): Same.
(matching_alloc_calls_p): Handle user-defined functions.
(maybe_emit_free_warning): Same.
* doc/extend.texi (attribute malloc): Update.
* doc/invoke.texi (-Wmismatched-dealloc): Document new option.

gcc/c-family/ChangeLog:

PR middle-end/94527
* c-attribs.c (handle_dealloc_attribute): New function.
(handle_malloc_attribute): Handle argument forms of attribute.
* c.opt (-Wmismatched-dealloc): New option.
(-Wmismatched-new-delete): Update description.

gcc/testsuite/ChangeLog:

PR middle-end/94527
* g++.dg/warn/Wmismatched-dealloc-2.C: New test.
* g++.dg/warn/Wmismatched-dealloc.C: New test.
* gcc.dg/Wmismatched-dealloc.c: New test.
* gcc.dg/attr-malloc.c: New test.

OK once prereq is wrapped up.


Presumably you're referring to this patch:
  https://gcc.gnu.org/pipermail/gcc-patches/2020-November/557987.html
Is there something I need to do to move it forward?  (I'm
assuming you're still reviewing the rest of the patch so
please let me know if you're waiting for me to remove
the objectionable function first.)



I realize the dealloc attribute is currently internal only to make
lookups quick.  Any thoughts on whether or not we might want to make it
a user visible attribute at some point?


I see no problem with exposing both attributes.

Martin

[PATCH] c++: Fix ICE with inline variable in template [PR97975]

[Marek Polacek via Gcc-patches]

In this test, we have

  static inline const int c = b;

in a class template, and we call store_init_value as usual.  There, the
value is

  IMPLICIT_CONV_EXPR(b)

which is is_nondependent_static_init_expression but isn't
is_nondependent_constant_expression (they only differ in STRICT).
We call fold_non_dependent_expr, but that just returns the expression
because it only instantiates is_nondependent_constant_expression
expressions.  Since we're not checking the initializer of a constexpr
variable, we go on to call maybe_constant_init, whereupon we crash
because it tries to evaluate all is_nondependent_static_init_expression
expressions, which our value is, but it still contains a template code.

I think the fix is to call fold_non_dependent_init instead of
maybe_constant_init, and only call fold_non_dependent_expr on the
"this is a constexpr variable" path so as to avoid instantiating twice
in a row.  Outside a template this should also avoid evaluating the
value twice.

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/10?

gcc/cp/ChangeLog:

PR c++/97975
* constexpr.c (fold_non_dependent_init): Add a tree parameter.
Use it.
* cp-tree.h (fold_non_dependent_init): Add a tree parameter with
a default value.
* typeck2.c (store_init_value): Call fold_non_dependent_expr
only when checking the initializer for constexpr variables.
Call fold_non_dependent_init instead of maybe_constant_init.

gcc/testsuite/ChangeLog:

PR c++/97975
* g++.dg/cpp1z/inline-var8.C: New test.
---
 gcc/cp/constexpr.c   |  7 ---
 gcc/cp/cp-tree.h |  2 +-
 gcc/cp/typeck2.c |  7 +--
 gcc/testsuite/g++.dg/cpp1z/inline-var8.C | 17 +
 4 files changed, 27 insertions(+), 6 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp1z/inline-var8.C

diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index 054ee524c7a..9a1a1db1267 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -7271,7 +7271,8 @@ maybe_fold_non_dependent_expr (tree expr,
 tree
 fold_non_dependent_init (tree t,
 tsubst_flags_t complain /*=tf_warning_or_error*/,
-bool manifestly_const_eval /*=false*/)
+bool manifestly_const_eval /*=false*/,
+tree object /* = NULL_TREE */)
 {
   if (t == NULL_TREE)
 return NULL_TREE;
@@ -7279,7 +7280,7 @@ fold_non_dependent_init (tree t,
   if (processing_template_decl)
 {
   t = fold_non_dependent_expr_template (t, complain,
-   manifestly_const_eval, NULL_TREE);
+   manifestly_const_eval, object);
   /* maybe_constant_init does this stripping, so do it here too.  */
   if (TREE_CODE (t) == TARGET_EXPR)
{
@@ -7290,7 +7291,7 @@ fold_non_dependent_init (tree t,
   return t;
 }
 
-  return maybe_constant_init (t, NULL_TREE, manifestly_const_eval);
+  return maybe_constant_init (t, object, manifestly_const_eval);
 }
 
 /* Like maybe_constant_value, but returns a CONSTRUCTOR directly, rather
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 021de76e142..41516deeafa 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -7953,7 +7953,7 @@ extern tree maybe_fold_non_dependent_expr (tree,
 tsubst_flags_t = 
tf_warning_or_error);
 extern tree fold_non_dependent_init(tree,
 tsubst_flags_t = 
tf_warning_or_error,
-bool = false);
+bool = false, tree = 
NULL_TREE);
 extern tree fold_simple(tree);
 extern bool reduced_constant_expression_p   (tree);
 extern bool is_instantiation_of_constexpr   (tree);
diff --git a/gcc/cp/typeck2.c b/gcc/cp/typeck2.c
index 721987e8502..575c609a365 100644
--- a/gcc/cp/typeck2.c
+++ b/gcc/cp/typeck2.c
@@ -744,11 +744,13 @@ store_init_value (tree decl, tree init, vec** cleanups, int flags)
 {
   bool const_init;
   tree oldval = value;
-  value = fold_non_dependent_expr (value, tf_warning_or_error, true, decl);
   if (DECL_DECLARED_CONSTEXPR_P (decl)
  || (DECL_IN_AGGR_P (decl)
  && DECL_INITIALIZED_IN_CLASS_P (decl)))
{
+ value = fold_non_dependent_expr (value, tf_warning_or_error,
+  /*manifestly_const_eval=*/true,
+  decl);
  /* Diagnose a non-constant initializer for constexpr variable or
 non-inline in-class-initialized static data member.  */
  if (!require_constant_expression (value))
@@ -762,7 +764,8 @@ store_init_value (tree decl, tree init, vec** 
cleanups, int flags)
value = cxx_constant_init (value, decl)

[PATCH] c++: Fix tsubst ICE with invalid code [PR97993, PR97187]

[Marek Polacek via Gcc-patches]

I had a strong sense of deja vu when looking into this, and no wonder,
since this is almost identical to c++/95728.

Since r11-423 tsubst_copy_and_build/TREE_LIST uses tsubst_tree_list
instead of open coding it.  While the latter could return an error
node wrapped in a TREE_LIST, the former can return a naked error node.

That broke in tsubst_copy_and_build/NEW_EXPR, because we were accessing
TREE_VALUE of an error node.

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?

gcc/cp/ChangeLog:

PR c++/97187
PR c++/97993
* pt.c (tsubst_copy_and_build) : Return error_mark_node
if init is erroneous.

gcc/testsuite/ChangeLog:

PR c++/97187
PR c++/97993
* g++.dg/eh/crash2.C: New test.
* g++.dg/template/crash132.C: New test.
---
 gcc/cp/pt.c  |  2 ++
 gcc/testsuite/g++.dg/eh/crash2.C | 20 
 gcc/testsuite/g++.dg/template/crash132.C |  6 ++
 3 files changed, 28 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/eh/crash2.C
 create mode 100644 gcc/testsuite/g++.dg/template/crash132.C

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 4fb0bc82c31..72d6cc3ad98 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -19829,6 +19829,8 @@ tsubst_copy_and_build (tree t,
   parameter packs are of length zero.  */
if (init == NULL_TREE && TREE_OPERAND (t, 3) == NULL_TREE)
  init_vec = NULL;
+   else if (init == error_mark_node)
+ RETURN (error_mark_node);
else
  {
init_vec = make_tree_vector ();
diff --git a/gcc/testsuite/g++.dg/eh/crash2.C b/gcc/testsuite/g++.dg/eh/crash2.C
new file mode 100644
index 000..fff8e142fd6
--- /dev/null
+++ b/gcc/testsuite/g++.dg/eh/crash2.C
@@ -0,0 +1,20 @@
+// PR c++/97187
+// { dg-do compile { target c++14 } }
+// { dg-options "-fno-exceptions" }
+
+auto yp = [] { return 0; };
+
+template 
+DI
+zl ()
+{
+  auto au = [] () -> DI { return *new auto (true ? yp : throw); }; // { 
dg-error "exception handling disabled" }
+
+  return au ();
+}
+
+auto
+vd ()
+{
+  return zl  ();
+}
diff --git a/gcc/testsuite/g++.dg/template/crash132.C 
b/gcc/testsuite/g++.dg/template/crash132.C
new file mode 100644
index 000..f6f4863e937
--- /dev/null
+++ b/gcc/testsuite/g++.dg/template/crash132.C
@@ -0,0 +1,6 @@
+// PR c++/97993
+// { dg-do compile { target c++14 } }
+
+template  T a;
+template  auto foo ();
+struct S decltype (foo ); // { dg-error "" }

base-commit: b46314c78061a5156bac44a317c87d32b00d4295
-- 
2.28.0

Re: [PATCH] Avoid atomic for guard acquire when that is expensive

[Bernd Edlinger]

On 11/24/20 11:10 PM, Jason Merrill wrote:
> On 11/22/20 3:05 AM, Bernd Edlinger wrote:
>> Hi,
>>
>> this avoids the need to use -fno-threadsafe-statics on
>> arm-none-eabi or working around that problem by supplying
>> a dummy __sync_synchronize function which might
>> just lead to silent code failure of the worst kind
>> (non-reproducable, racy) at runtime, as was pointed out
>> on previous discussions here.
>>
>> When the atomic access involves a call to __sync_synchronize
>> it is better to call __cxa_guard_acquire unconditionally,
>> since it handles the atomics too, or is a non-threaded
>> implementation when there is no gthread support for this target.
>>
>> This fixes also a bug for the ARM EABI big-endian target,
>> that is, previously the wrong bit was checked.
> 
> Instead of a new target macro, can't you follow 
> fold_builtin_atomic_always_lock_free/can_atomic_load_p?
> 

Yes, thanks, that should work too.
Would you like this better?


Thanks
Bernd.
From 863b023786f7e8321979bcdb33c027d37d5e155b Mon Sep 17 00:00:00 2001
From: Bernd Edlinger 
Date: Tue, 1 Dec 2020 18:54:48 +0100
Subject: [PATCH] Avoid atomic for guard acquire when that is expensive

When the atomic access involves a call to __sync_synchronize
it is better to call __cxa_guard_acquire unconditionally,
since it handles the atomics too, or is a non-threaded
implementation when there is no gthread support for this target.

This fixes also a bug for the ARM EABI big-endian target,
that is, previously the wrong bit was checked.

2020-11-22  Bernd Edlinger  

	* decl2.c: (is_atomic_expensive_p): New helper function.
	(build_atomic_load_byte): Rename to...
	(build_atomic_load_type): ... and add new parameter type.
	(get_guard_cond): Skip the atomic here if that is expensive.
	Use the correct type for the atomic load on certain targets.
---
 gcc/cp/decl2.c | 33 +
 1 file changed, 29 insertions(+), 4 deletions(-)

diff --git a/gcc/cp/decl2.c b/gcc/cp/decl2.c
index 1bc7b7e..5001e8f 100644
--- a/gcc/cp/decl2.c
+++ b/gcc/cp/decl2.c
@@ -48,6 +48,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "intl.h"
 #include "c-family/c-ada-spec.h"
 #include "asan.h"
+#include "optabs-query.h"
 
 /* Id for dumping the raw trees.  */
 int raw_dump_id;
@@ -3297,18 +3298,34 @@ get_guard (tree decl)
   return guard;
 }
 
+/* Returns true if accessing the GUARD atomic is expensive,
+   i.e. involves a call to __sync_synchronize or similar.
+   In this case let __cxa_guard_acquire handle the atomics.  */
+
+static bool
+is_atomic_expensive_p (machine_mode mode)
+{
+  if (!flag_inline_atomics)
+return false;
+
+  if (!can_compare_and_swap_p (mode, false) || !can_atomic_load_p (mode))
+return false;
+
+  return true;
+}
+
 /* Return an atomic load of src with the appropriate memory model.  */
 
 static tree
-build_atomic_load_byte (tree src, HOST_WIDE_INT model)
+build_atomic_load_type (tree src, HOST_WIDE_INT model, tree type)
 {
-  tree ptr_type = build_pointer_type (char_type_node);
+  tree ptr_type = build_pointer_type (type);
   tree mem_model = build_int_cst (integer_type_node, model);
   tree t, addr, val;
   unsigned int size;
   int fncode;
 
-  size = tree_to_uhwi (TYPE_SIZE_UNIT (char_type_node));
+  size = tree_to_uhwi (TYPE_SIZE_UNIT (type));
 
   fncode = BUILT_IN_ATOMIC_LOAD_N + exact_log2 (size) + 1;
   t = builtin_decl_implicit ((enum built_in_function) fncode);
@@ -3351,7 +3368,15 @@ get_guard_cond (tree guard, bool thread_safe)
   if (!thread_safe)
 guard = get_guard_bits (guard);
   else
-guard = build_atomic_load_byte (guard, MEMMODEL_ACQUIRE);
+{
+  tree type = targetm.cxx.guard_mask_bit ()
+		  ? TREE_TYPE (guard) : char_type_node;
+
+  if (is_atomic_expensive_p (TYPE_MODE (type)))
+	guard = integer_zero_node;
+  else
+	guard = build_atomic_load_type (guard, MEMMODEL_ACQUIRE, type);
+}
 
   /* Mask off all but the low bit.  */
   if (targetm.cxx.guard_mask_bit ())
-- 
1.9.1

C++ Module options

[Nathan Sidwell]

This adds the C++ module options, and wires them into lang-specs.  The
options are not connected to any machinery.  The options! They do
nothing!

Since posting the earlier patch, I added 
-flang-info-include-translate-not, to warn about header files that are 
being treated textually.


gcc/c-family/
* c-opts.c (c_common_init_options): Ask for module dependencies.
(c_common_handle_option): Handle -Mmodules -Mno-modules.
* c-pch.c (c_common_valid_pch): ... does not play with C++
modules.
* c.opt (Mmodules, Mno-modules): New preprocessor dependency
options.
(fmodules-ts, fmodule-header, fmodule-implicit-inline)
(fmodule-only, fmodule-mapper, fmodule-lazy)
(fmodule-version-ignore, Winvalid-imported-macros)
(flang-info-include-translate, flang-info-include-translate-not):
New options
gcc/cp/
* lang-spec.h: Add module-related options.

pushing to trunk

nathan

--
Nathan Sidwell
diff --git c/gcc/c-family/c-opts.c w/gcc/c-family/c-opts.c
index 77844d7daf1..59cabd12407 100644
--- c/gcc/c-family/c-opts.c
+++ w/gcc/c-family/c-opts.c
@@ -234,6 +234,7 @@ c_common_init_options (unsigned int decoded_options_count,
   cpp_opts = cpp_get_options (parse_in);
   cpp_opts->dollars_in_ident = DOLLARS_IN_IDENTIFIERS;
   cpp_opts->objc = c_dialect_objc ();
+  cpp_opts->deps.modules = true;
 
   /* Reset to avoid warnings on internal definitions.  We set it just
  before passing on command-line options to cpplib.  */
@@ -367,6 +368,18 @@ c_common_handle_option (size_t scode, const char *arg, HOST_WIDE_INT value,
   cpp_opts->deps.phony_targets = true;
   break;
 
+case OPT_Mmodules:
+  /* Do not set deps_seen, so the user can unconditionally turn
+	 this on or off.  */
+  cpp_opts->deps.modules = true;
+  break;
+
+case OPT_Mno_modules:
+  /* Do not set deps_seen, so the user can unconditionally turn
+	 this on or off.  */
+  cpp_opts->deps.modules = false;
+  break;
+
 case OPT_MQ:
 case OPT_MT:
   deps_seen = true;
diff --git c/gcc/c-family/c-pch.c w/gcc/c-family/c-pch.c
index 9c0bd0b631d..fdeb860c0e6 100644
--- c/gcc/c-family/c-pch.c
+++ w/gcc/c-family/c-pch.c
@@ -206,6 +206,10 @@ c_common_valid_pch (cpp_reader *pfile, const char *name, int fd)
   /* Perform a quick test of whether this is a valid
  precompiled header for the current language.  */
 
+  /* C++ modules and PCH don't play together.  */
+  if (flag_modules)
+return 2;
+
   sizeread = read (fd, ident, IDENT_LENGTH + 16);
   if (sizeread == -1)
 fatal_error (input_location, "cannot read %s: %m", name);
diff --git c/gcc/c-family/c.opt w/gcc/c-family/c.opt
index 0532cb70ffc..059f6c38a40 100644
--- c/gcc/c-family/c.opt
+++ w/gcc/c-family/c.opt
@@ -236,6 +236,14 @@ MMD
 C ObjC C++ ObjC++ NoDriverArg Separate MissingArgError(missing filename after %qs)
 Like -MD but ignore system header files.
 
+Mmodules
+C++
+Generate C++ Module dependency information.
+
+Mno-modules
+C++
+; undocumented
+
 MP
 C ObjC C++ ObjC++
 Generate phony targets for all headers.
@@ -1683,6 +1691,57 @@ flax-vector-conversions
 C ObjC C++ ObjC++ Var(flag_lax_vector_conversions)
 Allow implicit conversions between vectors with differing numbers of subparts and/or differing element types.
 
+fmodules-ts
+C++ ObjC++ Var(flag_modules) Integer Init(0)
+Enable C++ modules-ts (experimental).
+
+fno-modules
+C++ ObjC++ Undocumented RejectNegative Var(flag_modules,0) Integer
+;; undocumented
+
+fmodule-header
+C++ ObjC RejectNegative Var(flag_header_unit,0) Integer
+Enable C++ header module (experimental).
+
+fmodule-header=
+C++ ObjC++ Joined RejectNegative Undocumented
+
+fmodule-implicit-inline
+C++ ObjC++ Var(flag_module_implicit_inline,0) Integer
+Member functions defined within their class are inline in module purview.
+
+fmodule-only
+C++ ObjC RejectNegative Var(flag_module_only) Integer
+Only emit Compiled Module Interface.
+
+fmodule-mapper=
+C++ ObjC++ Joined RejectNegative MissingArgError(missing mapper)
+Mapper for module to CMI files.
+
+fmodule-lazy
+C++ ObjC++ Var(flag_module_lazy) Init(1)
+Enable lazy module importing.
+
+fmodule-version-ignore
+C++ ObjC Var(flag_module_version_ignore) Integer
+; undocumented, Very dangerous, but occasionally useful
+
+Winvalid-imported-macros
+C++ ObjC++ Var(warn_imported_macros)
+Warn about macros that have conflicting header units definitions.
+
+flang-info-include-translate
+C++ Var(note_include_translate_yes)
+Note #include directives translated to import declarations.
+
+flang-info-include-translate-not
+C++ Var(note_include_translate_no)
+Note #include directives not translated to import declarations, and not known to be textual.
+
+flang-info-include-translate=
+C++ Joined RejectNegative MissingArgError(missing header name)
+Note a #include translation of a specific header.
+
 fmax-include-depth=
 C ObjC C++ ObjC++ Joined RejectNegative UInteger
 fmax-include-depth= Set

Re: [PATCH] libstdc++: Add C++ runtime support for new 128-bit long double format

[Michael Meissner via Gcc-patches]

On Tue, Dec 01, 2020 at 04:04:30PM +, Jonathan Wakely wrote:
> On 01/12/20 15:10 +, Jonathan Wakely wrote:
> >On 30/11/20 16:30 -0500, Michael Meissner via Libstdc++ wrote:
> >>Jonathan, could you send a fresh set of patches (or at least replacements)? 
> >> I
> >>tried installing the patches on a master branch I checked out this morning, 
> >>and
> >>I got two rejects:
> >
> >I don't understand why those chunks failed, but I'll rebase and send a
> >new patch ASAP.
> 
> Here's the rebased patch, with regenerated autoconf files and a fix
> for the  header. I'd changed it since sending
> the previous patch, and broke the "there's more than one long double"
> case (i.e. the _GLIBCXX_LONG_DOUBLE_ALT128_COMPAT case).

Unfortunately this patch DOES NOT work at all.

If I build a compiler with the configure option:
--with-long-double-format=ieee

And I compile this simple program:

#include 

int main(int argc, char *argv[], char *envp[])
{
  std::cout << "Hello World!\n";
  return 0;
}

I get all of these errors:

/home3/meissner/fsf-install-ppc64le/binutils-gdb/bin/ld: 
/home/meissner/fsf-install-ppc64le/work029-kf/lib/../lib64/libstdc++.so: 
undefined reference to `std::ostreambuf_iterator > 
std::num_put > 
>::_M_insert_int(std::ostreambuf_iterator >, 
std::ios_base&, char, long) const'
/home3/meissner/fsf-install-ppc64le/binutils-gdb/bin/ld: 
/home/meissner/fsf-install-ppc64le/work029-kf/lib/../lib64/libstdc++.so: 
undefined reference to `std::istreambuf_iterator > std::money_get > 
>::_M_extract(std::istreambuf_iterator >, std::istreambuf_iterator >, std::ios_base&, std::_Ios_Iostate&, std::string&) 
const'
/home3/meissner/fsf-install-ppc64le/binutils-gdb/bin/ld: 
/home/meissner/fsf-install-ppc64le/work029-kf/lib/../lib64/libstdc++.so: 
undefined reference to `std::ostreambuf_iterator > 
std::money_put > 
>::_M_insert(std::ostreambuf_iterator >, 
std::ios_base&, char, std::string const&) const'
/home3/meissner/fsf-install-ppc64le/binutils-gdb/bin/ld: 
/home/meissner/fsf-install-ppc64le/work029-kf/lib/../lib64/libstdc++.so: 
undefined reference to `std::istreambuf_iterator > std::num_get > 
>::_M_extract_int(std::istreambuf_iterator >, std::istreambuf_iterator >, std::ios_base&, std::_Ios_Iostate&, unsigned long 
long&) const'
/home3/meissner/fsf-install-ppc64le/binutils-gdb/bin/ld: 
/home/meissner/fsf-install-ppc64le/work029-kf/lib/../lib64/libstdc++.so: 
undefined reference to `std::istreambuf_iterator > std::num_get > 
>::_M_extract_int(std::istreambuf_iterator >, std::istreambuf_iterator >, std::ios_base&, std::_Ios_Iostate&, long long&) 
const'
/home3/meissner/fsf-install-ppc64le/binutils-gdb/bin/ld: 
/home/meissner/fsf-install-ppc64le/work029-kf/lib/../lib64/libstdc++.so: 
undefined reference to `std::istreambuf_iterator > std::money_get > 
>::_M_extract(std::istreambuf_iterator 
>, std::istreambuf_iterator >, 
std::ios_base&, std::_Ios_Iostate&, std::string&) const'
/home3/meissner/fsf-install-ppc64le/binutils-gdb/bin/ld: 
/home/meissner/fsf-install-ppc64le/work029-kf/lib/../lib64/libstdc++.so: 
undefined reference to `std::istreambuf_iterator > std::num_get > 
>::_M_extract_int(std::istreambuf_iterator >, std::istreambuf_iterator >, std::ios_base&, std::_Ios_Iostate&, unsigned int&) 
const'
/home3/meissner/fsf-install-ppc64le/binutils-gdb/bin/ld: 
/home/meissner/fsf-install-ppc64le/work029-kf/lib/../lib64/libstdc++.so: 
undefined reference to `std::istreambuf_iterator > std::num_get > 
>::_M_extract_int(std::istreambuf_iterator >, std::istreambuf_iterator >, std::ios_base&, std::_Ios_Iostate&, unsigned 
long&) const'
/home3/meissner/fsf-install-ppc64le/binutils-gdb/bin/ld: 
/home/meissner/fsf-install-ppc64le/work029-kf/lib/../lib64/libstdc++.so: 
undefined reference to `std::istreambuf_iterator > 
std::num_get > 
>::_M_extract_int(std::istreambuf_iterator >, std::istreambuf_iterator 
>, std::ios_base&, std::_Ios_Iostate&, unsigned int&) const'
/home3/meissner/fsf-install-ppc64le/binutils-gdb/bin/ld: 
/home/meissner/fsf-install-ppc64le/work029-kf/lib/../lib64/libstdc++.so: 
undefined reference to `std::istreambuf_iterator > 
std::money_get > 
>::_M_extract(std::istreambuf_iterator >, 
std::istreambuf_iterator >, std::ios_base&, 
std::_Ios_Iostate&, std::string&) const'
/home3/meissner/fsf-install-ppc64le/binutils-gdb/bin/ld: 
/home/meissner/fsf-install-ppc64le/work029-kf/lib/../lib64/libstdc++.so: 
undefined reference to `std::ostreambuf_iterator > std::num_put > 
>::_M_insert_float(std::ostreambuf_iterator >, std::ios_base&, wchar_t, char, long double) const'
/home3/meissner/fsf-install-ppc64le/binutils-gdb/bin/ld: 
/home/meissner/fsf-install-ppc64le/work029-kf/lib/../lib64/libstdc++.so: 
undefined reference to `std::ostreambuf_iterator > 
std::num_put > 
>::_M_insert_int(std::ostreambuf_iterator >, std::ios_base&, char, unsigned long) const'
/home3/meissner/fsf-install-ppc64le/binutils-gdb/bin/ld: 
/home/meissner/fsf-install-ppc64le/wor

[PATCH] Remove misleading debug line entries

[Bernd Edlinger]

Hi!


This removes gimple_debug stmts without block info after a
NULL INLINE_ENTRY.

The line numbers from these stmts are from the inline function,
but since the inline function is completely optimized away,
there will be no DW_TAG_inlined_subroutine so the debugger has
no callstack available at this point, and therefore those
line table entries are not helpful to the user.

2020-11-20  Bernd Edlinger  

* cfgexpand.c (expand_gimple_basic_block): Remove debug_begin_stmts
following a removed debug_inline_entry.


Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?


Thanks
Bernd.
From 464867ca9b4cc6270fb6d41dc5346dc55395efb0 Mon Sep 17 00:00:00 2001
From: Bernd Edlinger 
Date: Fri, 13 Nov 2020 16:26:28 +0100
Subject: [PATCH] Remove misleading debug line entries

This removes gimple_debug stmts without block info after a
NULL INLINE_ENTRY.

The line numbers from these stmts are from the inline function,
but since the inline function is completely optimized away,
there will be no DW_TAG_inlined_subroutine so the debugger has
no callstack available at this point, and therefore those
line table entries are not helpful to the user.

2020-11-20  Bernd Edlinger  

	* cfgexpand.c (expand_gimple_basic_block): Remove debug_begin_stmts
	following a removed debug_inline_entry.
---
 gcc/cfgexpand.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/gcc/cfgexpand.c b/gcc/cfgexpand.c
index 1df6f4b..6bd38ac 100644
--- a/gcc/cfgexpand.c
+++ b/gcc/cfgexpand.c
@@ -5785,6 +5785,7 @@ expand_gimple_basic_block (basic_block bb, bool disable_tail_calls)
 	  tree value = NULL_TREE;
 	  rtx val = NULL_RTX;
 	  machine_mode mode;
+	  bool skip_inline_loc = false;
 
 	  if (!gimple_debug_nonbind_marker_p (stmt))
 		{
@@ -5837,7 +5838,10 @@ expand_gimple_basic_block (basic_block bb, bool disable_tail_calls)
 		  if (block)
 		val = GEN_RTX_DEBUG_MARKER_INLINE_ENTRY_PAT ();
 		  else
-		goto delink_debug_stmt;
+		{
+		  skip_inline_loc = true;
+		  goto delink_debug_stmt;
+		}
 		}
 	  else
 		gcc_unreachable ();
@@ -5877,6 +5881,8 @@ expand_gimple_basic_block (basic_block bb, bool disable_tail_calls)
 	  stmt = gsi_stmt (nsi);
 	  if (!is_gimple_debug (stmt))
 		break;
+	  if (skip_inline_loc && !gimple_block (stmt))
+		goto delink_debug_stmt;
 	}
 
 	  set_curr_insn_location (sloc);
-- 
1.9.1

[PATCH] if-to-switch: consider only integral types

[Martin Liška]

It fixes ICE seen in the PR which is about gswitch statements
where an index type should be only an integral type.

Patch can bootstrap on x86_64-linux-gnu and survives regression tests.

Ready to be installed?
Thanks,
Martin

gcc/ChangeLog:

PR tree-optimization/98084
* gimple-if-to-switch.cc (find_conditions): Consider only
integral types.

gcc/testsuite/ChangeLog:

PR tree-optimization/98084
* gcc.dg/tree-ssa/pr98084.c: New test.
---
 gcc/gimple-if-to-switch.cc  |  1 +
 gcc/testsuite/gcc.dg/tree-ssa/pr98084.c | 26 +
 2 files changed, 27 insertions(+)
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/pr98084.c

diff --git a/gcc/gimple-if-to-switch.cc b/gcc/gimple-if-to-switch.cc
index d132064fb9b..0aa1b0e4e7e 100644
--- a/gcc/gimple-if-to-switch.cc
+++ b/gcc/gimple-if-to-switch.cc
@@ -429,6 +429,7 @@ find_conditions (basic_block bb,
 
   for (unsigned i = 0; i < info.m_ranges.length (); ++i)

if (info.m_ranges[i].exp == NULL_TREE
+   || !INTEGRAL_TYPE_P (TREE_TYPE (info.m_ranges[i].exp))
|| info.m_ranges[i].low == NULL_TREE
|| info.m_ranges[i].high == NULL_TREE)
  return;
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr98084.c 
b/gcc/testsuite/gcc.dg/tree-ssa/pr98084.c
new file mode 100644
index 000..637962481d1
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr98084.c
@@ -0,0 +1,26 @@
+/* PR tree-optimization/98084 */
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+
+enum {
+  JSON_VARIANT_STRING,
+  JSON_VARIANT_UNSIGNED,
+  JSON_VARIANT_REAL,
+  JSON_VARIANT_ARRAY,
+  _JSON_VARIANT_TYPE_INVALID,
+  _JSON_VARIANT_MAGIC_ZERO_UNSIGNED,
+  _JSON_VARIANT_MAGIC_ZERO_REAL,
+  _JSON_VARIANT_MAGIC_EMPTY_STRING,
+  _JSON_VARIANT_MAGIC_EMPTY_ARRAY
+} json_variant_type(int *v) {
+  if (!v)
+return _JSON_VARIANT_TYPE_INVALID;
+  if (v == (int *)_JSON_VARIANT_MAGIC_ZERO_UNSIGNED)
+return JSON_VARIANT_UNSIGNED;
+  if (v == (int *)_JSON_VARIANT_MAGIC_ZERO_REAL)
+return JSON_VARIANT_REAL;
+  if (v == (int *)_JSON_VARIANT_MAGIC_EMPTY_STRING)
+return JSON_VARIANT_STRING;
+  if (v == (int *)_JSON_VARIANT_MAGIC_EMPTY_ARRAY)
+return JSON_VARIANT_ARRAY;
+}
--
2.29.2

C++ Module parameters & timers

[Nathan Sidwell]

Here is the new parameter and instrumentation timers for modules.

gcc/
* params.opt (lazy-modules): New.
* timevar.def (TV_MODULE_IMPORT, TV_MODULE_EXPORT)
(TV_MODULE_MAPPER): New.


pushing to trunk
--
Nathan Sidwell
diff --git c/gcc/params.opt w/gcc/params.opt
index 7bac39a9d58..0366584f94e 100644
--- c/gcc/params.opt
+++ w/gcc/params.opt
@@ -349,6 +349,10 @@ Maximal stack frame growth due to inlining (in percent).
 Common Joined UInteger Var(param_large_unit_insns) Optimization Init(1) Param
 The size of translation unit to be considered large.
 
+-param=lazy-modules=
+C++ Joined UInteger Var(param_lazy_modules) Init(32768) Param
+Maximum number of concurrently open C++ module files when lazy loading.
+
 -param=lim-expensive=
 Common Joined UInteger Var(param_lim_expensive) Init(20) Param Optimization
 The minimum cost of an expensive expression in the loop invariant motion.
diff --git c/gcc/timevar.def w/gcc/timevar.def
index 08c21c04009..f2bd58f0f58 100644
--- c/gcc/timevar.def
+++ w/gcc/timevar.def
@@ -145,6 +145,9 @@ DEFTIMEVAR (TV_CONSTEXPR	 , "constant expression evaluation")
 DEFTIMEVAR (TV_CONSTRAINT_NORM	 , "constraint normalization")
 DEFTIMEVAR (TV_CONSTRAINT_SAT	 , "constraint satisfaction")
 DEFTIMEVAR (TV_CONSTRAINT_SUB	 , "constraint subsumption")
+DEFTIMEVAR (TV_MODULE_IMPORT	 , "module import")
+DEFTIMEVAR (TV_MODULE_EXPORT	 , "module export")
+DEFTIMEVAR (TV_MODULE_MAPPER , "module mapper")
 DEFTIMEVAR (TV_FLATTEN_INLINING  , "flatten inlining")
 DEFTIMEVAR (TV_EARLY_INLINING, "early inlining heuristics")
 DEFTIMEVAR (TV_INLINE_PARAMETERS , "inline parameters")

C++ Module keywords

[Nathan Sidwell]

This adds the module keywords.  These are special internal tokens
generated by the preprocessor's module-control-line token peeking
logic.  Spelling them with a space means that they turn back into
regular tokens in preprocessor output (but do skew the column
numbering :()

gcc/c-family/
* c-common.c (module, import, export): New internal tokens (with
trailing space).
* c-common.h (RID__MODULE, RID__IMPORT & RID__EXPORT): Enumerate
them.
(D_CXX_MODULES, D_CXX_MODULES_FLAGS): Enable them.
* c-cppbuiltins.c (c_cpp_builtins): Feature macro.
gcc/cp/
* lex.c (init_reswords): Maybe enable module keywords.

pushing to trunk

--
Nathan Sidwell
diff --git i/gcc/c-family/c-common.c w/gcc/c-family/c-common.c
index 5d1e4ef289c..cae883b5309 100644
--- i/gcc/c-family/c-common.c
+++ w/gcc/c-family/c-common.c
@@ -540,6 +540,12 @@ const struct c_common_resword c_common_reswords[] =
   { "concept",		RID_CONCEPT,	D_CXX_CONCEPTS_FLAGS | D_CXXWARN },
   { "requires", 	RID_REQUIRES,	D_CXX_CONCEPTS_FLAGS | D_CXXWARN },
 
+  /* Modules-related keywords, these are internal unspellable tokens,
+ created by the preprocessor.  */
+  { "module ",		RID__MODULE,	D_CXX_MODULES_FLAGS | D_CXXWARN },
+  { "import ",		RID__IMPORT,	D_CXX_MODULES_FLAGS | D_CXXWARN },
+  { "export ",		RID__EXPORT,	D_CXX_MODULES_FLAGS | D_CXXWARN },
+
   /* Coroutines-related keywords */
   { "co_await",		RID_CO_AWAIT,	D_CXX_COROUTINES_FLAGS | D_CXXWARN },
   { "co_yield",		RID_CO_YIELD,	D_CXX_COROUTINES_FLAGS | D_CXXWARN },
diff --git i/gcc/c-family/c-common.h w/gcc/c-family/c-common.h
index f413e8773f5..8c17067e63c 100644
--- i/gcc/c-family/c-common.h
+++ w/gcc/c-family/c-common.h
@@ -195,6 +195,9 @@ enum rid
   /* C++ concepts */
   RID_CONCEPT, RID_REQUIRES,
 
+  /* C++ modules.  */
+  RID__MODULE, RID__IMPORT, RID__EXPORT, /* Internal tokens.  */
+
   /* C++ coroutines */
   RID_CO_AWAIT, RID_CO_YIELD, RID_CO_RETURN,
 
@@ -449,9 +452,11 @@ extern machine_mode c_default_pointer_mode;
 #define D_CXX_CHAR8_T	0X1000	/* In C++, only with -fchar8_t.  */
 #define D_CXX20		0x2000  /* In C++, C++20 only.  */
 #define D_CXX_COROUTINES 0x4000  /* In C++, only with coroutines.  */
+#define D_CXX_MODULES	0x8000  /* In C++, only with modules.  */
 
 #define D_CXX_CONCEPTS_FLAGS D_CXXONLY | D_CXX_CONCEPTS
 #define D_CXX_CHAR8_T_FLAGS D_CXXONLY | D_CXX_CHAR8_T
+#define D_CXX_MODULES_FLAGS (D_CXXONLY | D_CXX_MODULES)
 #define D_CXX_COROUTINES_FLAGS (D_CXXONLY | D_CXX_COROUTINES)
 
 /* The reserved keyword table.  */
diff --git i/gcc/c-family/c-cppbuiltin.c w/gcc/c-family/c-cppbuiltin.c
index d35b087bdcc..41914f64874 100644
--- i/gcc/c-family/c-cppbuiltin.c
+++ w/gcc/c-family/c-cppbuiltin.c
@@ -1025,6 +1025,10 @@ c_cpp_builtins (cpp_reader *pfile)
   else
 cpp_define (pfile, "__cpp_concepts=201507L");
 }
+  if (flag_modules)
+	/* The std-defined value is 201907L, but I don't think we can
+	   claim victory yet.  201810 is the p1103 date. */
+	cpp_define (pfile, "__cpp_modules=201810L");
   if (flag_coroutines)
 	cpp_define (pfile, "__cpp_impl_coroutine=201902L"); /* n4861, DIS */
   if (flag_tm)
diff --git i/gcc/cp/lex.c w/gcc/cp/lex.c
index 8a69bc4f170..21e33d69c08 100644
--- i/gcc/cp/lex.c
+++ w/gcc/cp/lex.c
@@ -235,6 +235,8 @@ init_reswords (void)
 mask |= D_CXX_CONCEPTS;
   if (!flag_coroutines)
 mask |= D_CXX_COROUTINES;
+  if (!flag_modules)
+mask |= D_CXX_MODULES;
   if (!flag_tm)
 mask |= D_TRANSMEM;
   if (!flag_char8_t)

Re: How to traverse all the local variables that declared in the current routine?

[Qing Zhao via Gcc-patches]

Hi, Richard, 

Could you please comment on the following approach:

Instead of adding the zero-initializer quite late at the pass “pass_expand”, we 
can add it as early as during gimplification. 
However, we will mark these new added zero-initializers as “artificial”. And 
passing this “artificial” information to 
“pass_early_warn_uninitialized” and “pass_late_warn_uninitialized”, in these 
two uninitialized variable analysis passes, 
(i.e., in tree-sea-uninit.c) We will update the checking on 
“ssa_undefined_value_p”  to consider “artificial” zero-initializers. 
(i.e, if the def_stmt is marked with “artificial”, then it’s a undefined 
value). 

With such approach, we should be able to address all those conflicts. 

Do you see any obvious issue with this approach?

Thanks a lot for your help.

Qing


> On Nov 25, 2020, at 3:11 AM, Richard Biener  
> wrote:
>> 
>> 
>> I am planing to add a new phase immediately after 
>> “pass_late_warn_uninitialized” to initialize all auto-variables that are
>> not explicitly initialized in the declaration, the basic idea is following:
>> 
>> ** The proposal:
>> 
>> A. add a new GCC option: (same name and meaning as CLANG)
>> -ftrivial-auto-var-init=[pattern|zero], similar pattern init as CLANG;
>> 
>> B. add a new attribute for variable:
>> __attribute((uninitialized)
>> the marked variable is uninitialized intentionaly for performance purpose.
>> 
>> C. The implementation needs to keep the current static warning on 
>> uninitialized
>> variables untouched in order to avoid "forking the language".
>> 
>> 
>> ** The implementation:
>> 
>> There are two major requirements for the implementation:
>> 
>> 1. all auto-variables that do not have an explicit initializer should be 
>> initialized to
>> zero by this option.  (Same behavior as CLANG)
>> 
>> 2. keep the current static warning on uninitialized variables untouched.
>> 
>> In order to satisfy 1, we should check whether an auto-variable has 
>> initializer
>> or not;
>> In order to satisfy 2, we should add this new transformation after
>> "pass_late_warn_uninitialized".
>> 
>> So, we should be able to check whether an auto-variable has initializer or 
>> not after “pass_late_warn_uninitialized”,
>> If Not, then insert an initialization for it.
>> 
>> For this purpose, I guess that “FOR_EACH_LOCAL_DECL” might be better?
>> 
>> 
>> I think both as long as they are source-level auto-variables. Then which one 
>> is better?
>> 
>> 
>> Another issue is, in order to check whether an auto-variable has 
>> initializer, I plan to add a new bit in “decl_common” as:
>> /* In a VAR_DECL, this is DECL_IS_INITIALIZED.  */
>> unsigned decl_is_initialized :1;
>> 
>> /* IN VAR_DECL, set when the decl is initialized at the declaration.  */
>> #define DECL_IS_INITIALIZED(NODE) \
>> (DECL_COMMON_CHECK (NODE)->decl_common.decl_is_initialized)
>> 
>> set this bit when setting DECL_INITIAL for the variables in FE. then keep it
>> even though DECL_INITIAL might be NULLed.
>> 
>> 
>> For locals it would be more reliable to set this flag-Wmaybe-uninitialized.
>> 
>> 
>> You mean I can set the flag “DECL_IS_INITIALIZED (decl)”  inside the routine 
>> “gimpley_decl_expr” (gimplify.c) as following:
>> 
>>  if (VAR_P (decl) && !DECL_EXTERNAL (decl))
>>{
>>  tree init = DECL_INITIAL (decl);
>> ...
>>  if (init && init != error_mark_node)
>>{
>>  if (!TREE_STATIC (decl))
>>{
>>  DECL_IS_INITIALIZED(decl) = 1;
>>}
>> 
>> Is this enough for all Frontends? Are there other places that I need to 
>> maintain this bit?
>> 
>> 
>> 
>> Do you have any comment and suggestions?
>> 
>> 
>> As said above - do you want to cover registers as well as locals?
>> 
>> 
>> All the locals from the source-code point of view should be covered.   (From 
>> my study so far,  looks like that Clang adds that phase in FE).
>> If GCC adds this phase in FE, then the following design requirement
>> 
>> C. The implementation needs to keep the current static warning on 
>> uninitialized
>> variables untouched in order to avoid "forking the language”.
>> 
>> cannot be satisfied.  Since gcc’s uninitialized variables analysis is 
>> applied quite late.
>> 
>> So, we have to add this new phase after “pass_late_warn_uninitialized”.
>> 
>> I'd do
>> the actual zeroing during RTL expansion instead since otherwise you
>> have to figure youself whether a local is actually used (see 
>> expand_stack_vars)
>> 
>> 
>> Adding  this new transformation during RTL expansion is okay.  I will check 
>> on this in more details to see how to add it to RTL expansion phase.
>> 
>> 
>> Note that optimization will already made have use of "uninitialized" state
>> of locals so depending on what the actual goal is here "late" may be too 
>> late.
>> 
>> 
>> This is a really good point…
>> 
>> In order to avoid optimization  to use the “uninitialized” state of locals, 
>> we should add the zeroing phase as early as possible (adding it in FE might 
>> be best
>> for this 

[PATCH][pushed] if-to-switch: Fix test-suite patterns.

[Martin Liška]

On ppc64le some conditions in BBs are not merged so we merge
a different number of BBs.

Pushed as obvious. Tested on x86_64-linux-gnu and ppc64le-linux-gnu.

gcc/testsuite/ChangeLog:

PR testsuite/98085
* g++.dg/tree-ssa/if-to-switch-1.C: Do not expect precise number
of BBs.
* gcc.dg/tree-ssa/if-to-switch-1.c: Likewise.
* gcc.dg/tree-ssa/if-to-switch-2.c: Likewise. Find better name
for the function.
* gcc.dg/tree-ssa/if-to-switch-3.c: Likewise. Find better name
for the function.
* gcc.dg/tree-ssa/if-to-switch-5.c: Likewise.
---
 gcc/testsuite/g++.dg/tree-ssa/if-to-switch-1.C | 2 +-
 gcc/testsuite/gcc.dg/tree-ssa/if-to-switch-1.c | 2 +-
 gcc/testsuite/gcc.dg/tree-ssa/if-to-switch-2.c | 4 ++--
 gcc/testsuite/gcc.dg/tree-ssa/if-to-switch-3.c | 4 ++--
 gcc/testsuite/gcc.dg/tree-ssa/if-to-switch-5.c | 2 +-
 5 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/gcc/testsuite/g++.dg/tree-ssa/if-to-switch-1.C 
b/gcc/testsuite/g++.dg/tree-ssa/if-to-switch-1.C
index 88505e8869f..96c4d577064 100644
--- a/gcc/testsuite/g++.dg/tree-ssa/if-to-switch-1.C
+++ b/gcc/testsuite/g++.dg/tree-ssa/if-to-switch-1.C
@@ -22,4 +22,4 @@ void tree_node() {
   int g = 0;
 }
 
-/* { dg-final { scan-tree-dump "Condition chain with 3 BBs transformed into a switch statement." "iftoswitch" } } */

+/* { dg-final { scan-tree-dump "Condition chain with .* BBs transformed into a switch 
statement." "iftoswitch" } } */
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/if-to-switch-1.c 
b/gcc/testsuite/gcc.dg/tree-ssa/if-to-switch-1.c
index 92df4e93bfa..52f92ae145d 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/if-to-switch-1.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/if-to-switch-1.c
@@ -32,4 +32,4 @@ int main(int argc, char **argv)
   return 0;
 }
 
-/* { dg-final { scan-tree-dump "Condition chain with 5 BBs transformed into a switch statement." "iftoswitch" } } */

+/* { dg-final { scan-tree-dump "Condition chain with .* BBs transformed into a switch 
statement." "iftoswitch" } } */
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/if-to-switch-2.c 
b/gcc/testsuite/gcc.dg/tree-ssa/if-to-switch-2.c
index 36e62ae5be1..c229614a3d8 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/if-to-switch-2.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/if-to-switch-2.c
@@ -1,11 +1,11 @@
 /* { dg-do compile } */
 /* { dg-options "-O2 -fdump-tree-iftoswitch-optimized" } */
 
-int IsHTMLWhitespaceNoRange(int aChar)

+int isMyRandomCharacter(int aChar)
 {
   return aChar == 0x0001 || aChar == 0x000A ||
  aChar == 0x000C || aChar == 0x000E ||
  aChar == 0x0020;
 }
 
-/* { dg-final { scan-tree-dump "Condition chain with 3 BBs transformed into a switch statement." "iftoswitch" } } */

+/* { dg-final { scan-tree-dump "Condition chain with .* BBs transformed into a switch 
statement." "iftoswitch" } } */
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/if-to-switch-3.c 
b/gcc/testsuite/gcc.dg/tree-ssa/if-to-switch-3.c
index 9a4ce160238..4c7253ce212 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/if-to-switch-3.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/if-to-switch-3.c
@@ -1,11 +1,11 @@
 /* { dg-do compile } */
 /* { dg-options "-O2 -fdump-tree-iftoswitch-optimized" } */
 
-int IsHTMLWhitespace(int aChar)

+int IsMySuperRandomChar(int aChar)
 {
   return aChar == 0x0009 || aChar == 0x000A ||
  aChar == 0x000C || aChar == 0x000D ||
  aChar == 0x0020 || aChar == 0x0030;
 }
 
-/* { dg-final { scan-tree-dump "Condition chain with 3 BBs transformed into a switch statement." "iftoswitch" } } */

+/* { dg-final { scan-tree-dump "Condition chain with .* BBs transformed into a switch 
statement." "iftoswitch" } } */
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/if-to-switch-5.c 
b/gcc/testsuite/gcc.dg/tree-ssa/if-to-switch-5.c
index 7734a58500b..43b0f31b2ff 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/if-to-switch-5.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/if-to-switch-5.c
@@ -9,4 +9,4 @@ int crud (unsigned char c)
   || (int) c == 39) != 0);
 }
 
-/* { dg-final { scan-tree-dump "Condition chain with 5 BBs transformed into a switch statement." "iftoswitch" } } */

+/* { dg-final { scan-tree-dump "Condition chain with .* BBs transformed into a switch 
statement." "iftoswitch" } } */
--
2.29.2

Re: [PATCH][pushed] if-to-switch: Fix test-suite patterns.

[Jakub Jelinek via Gcc-patches]

On Tue, Dec 01, 2020 at 08:52:45PM +0100, Martin Liška wrote:
> -/* { dg-final { scan-tree-dump "Condition chain with 3 BBs transformed into 
> a switch statement." "iftoswitch" } } */
> +/* { dg-final { scan-tree-dump "Condition chain with .* BBs transformed into 
> a switch statement." "iftoswitch" } } */

Would be better to use \[^\n\r]\* instead of .*, with .* you can match parts
even from completely different parts of the dump file.

Jakub

Re: [PATCH][pushed] if-to-switch: Fix test-suite patterns.

[Martin Liška]

On 12/1/20 8:57 PM, Jakub Jelinek wrote:

Would be better to use \[^\n\r]\* instead of .*, with .* you can match parts
even from completely different parts of the dump file.


Thank you Jakub! I've just pushed a patch with that.

Martin

[pushed] Darwin, D : Adjust the X spec to cater for duplicate use.

[Iain Sandoe]

Hi

For Darwin, the '-X' flag is an obsolete spelling for a command to tell
the linker to 'strip local symbols'.  This has been the default action
for a long time - but, as per the usual GCC approach, although the
flag is retired, we have not removed it; rather, we just delete it
in the driver self-spec.

The D language adds this flag as a front end option (to emit json)
which means that deleting it in the driver disables that function
in D.

This patch works around the duplication by removing the unused flag
in the link_spec instead of the driver self-spec.

this workaround tested on x86_64-darwin (where gdc tests now pass)
applied to master
thanks
Iain



Joseph; I don’t know if you have any advice on a ‘better’ long-term
solution; in some ways I am surprised that the compiler built with
duplicate specifications for a flag - perhaps the uses merged in some
way.  Since the use of ‘X’ in D is an upstream decision and the use of
‘X’ in Darwin is a historical fact (albeit luckily obsolete) it seems the
only recourse is eventually to delete one useage?



gcc/ChangeLog:

* config/darwin.h: Remove unused 'X' specs in the link spec
rather than driver self-specs.
---
 gcc/config/darwin.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/config/darwin.h b/gcc/config/darwin.h
index 5a766319cb0..da40a08443e 100644
--- a/gcc/config/darwin.h
+++ b/gcc/config/darwin.h
@@ -135,7 +135,7 @@ extern GTY(()) int darwin_ms_struct;
 "%{shared:-Zdynamiclib} %

[SPARC] Make -fzero-call-used-regs work

[Eric Botcazou]

This contains both a generic fixlet for targets implementing the leaf register 
optimization (SPARC and Xtensa) and the implementation of the target hook 
TARGET_ZERO_CALL_USED_REGS, which is needed to make this work on the SPARC.

Tested on SPARC/Solaris and SPARC64/Linux, applied on the mainline.


2020-12-01  Eric Botcazou  

* function.c (gen_call_used_regs_seq): In a function subject to the
leaf register optimization, skip registers that are not present.
* config/sparc/sparc.c (TARGET_ZERO_CALL_USED_REGS): Define to...
(sparc_zero_call_used_regs): ...this.  New function.

-- 
Eric Botcazoudiff --git a/gcc/config/sparc/sparc.c b/gcc/config/sparc/sparc.c
index 02138c5d478..ec0921b7ef5 100644
--- a/gcc/config/sparc/sparc.c
+++ b/gcc/config/sparc/sparc.c
@@ -708,6 +708,7 @@ static HOST_WIDE_INT sparc_constant_alignment (const_tree, HOST_WIDE_INT);
 static bool sparc_vectorize_vec_perm_const (machine_mode, rtx, rtx, rtx,
 	const vec_perm_indices &);
 static bool sparc_can_follow_jump (const rtx_insn *, const rtx_insn *);
+static HARD_REG_SET sparc_zero_call_used_regs (HARD_REG_SET);
 
 #ifdef SUBTARGET_ATTRIBUTE_TABLE
 /* Table of valid machine attributes.  */
@@ -959,6 +960,9 @@ char sparc_hard_reg_printed[8];
 #undef TARGET_CAN_FOLLOW_JUMP
 #define TARGET_CAN_FOLLOW_JUMP sparc_can_follow_jump
 
+#undef TARGET_ZERO_CALL_USED_REGS
+#define TARGET_ZERO_CALL_USED_REGS sparc_zero_call_used_regs
+
 struct gcc_target targetm = TARGET_INITIALIZER;
 
 /* Return the memory reference contained in X if any, zero otherwise.  */
@@ -13810,4 +13814,50 @@ sparc_constant_alignment (const_tree exp, HOST_WIDE_INT align)
   return align;
 }
 
+/* Implement TARGET_ZERO_CALL_USED_REGS.
+
+   Generate a sequence of instructions that zero registers specified by
+   NEED_ZEROED_HARDREGS.  Return the ZEROED_HARDREGS that are actually
+   zeroed.  */
+
+static HARD_REG_SET
+sparc_zero_call_used_regs (HARD_REG_SET need_zeroed_hardregs)
+{
+  for (unsigned int regno = 0; regno < FIRST_PSEUDO_REGISTER; regno++)
+if (TEST_HARD_REG_BIT (need_zeroed_hardregs, regno))
+  {
+	/* Do not touch the CC registers or the FP registers if no VIS.  */
+	if (regno >= SPARC_FCC_REG
+	|| (regno >= SPARC_FIRST_FP_REG && !TARGET_VIS))
+	  CLEAR_HARD_REG_BIT (need_zeroed_hardregs, regno);
+
+	/* Do not access the odd upper FP registers individually.  */
+	else if (regno >= SPARC_FIRST_V9_FP_REG && (regno & 1))
+	  ;
+
+	/* Use the most natural mode for the registers, which is not given by
+	   regno_reg_rtx/reg_raw_mode for the FP registers on the SPARC.  */
+	else
+	  {
+	machine_mode mode;
+	rtx reg;
+
+	if (regno < SPARC_FIRST_FP_REG)
+	  {
+		reg = regno_reg_rtx[regno];
+		mode = GET_MODE (reg);
+	  }
+	else
+	  {
+		mode = regno < SPARC_FIRST_V9_FP_REG ? SFmode : DFmode;
+		reg = gen_raw_REG (mode, regno);
+	  }
+
+	emit_move_insn (reg, CONST0_RTX (mode));
+	  }
+  }
+
+  return need_zeroed_hardregs;
+}
+
 #include "gt-sparc.h"
diff --git a/gcc/function.c b/gcc/function.c
index 004fa389207..59fd72b0e82 100644
--- a/gcc/function.c
+++ b/gcc/function.c
@@ -5880,6 +5880,10 @@ gen_call_used_regs_seq (rtx_insn *ret, unsigned int zero_regs_type)
 	continue;
   if (only_arg && !FUNCTION_ARG_REGNO_P (regno))
 	continue;
+#ifdef LEAF_REG_REMAP
+  if (crtl->uses_only_leaf_regs && LEAF_REG_REMAP (regno) < 0)
+	continue;
+#endif
 
   /* Now this is a register that we might want to zero.  */
   SET_HARD_REG_BIT (selected_hardregs, regno);

Re: [PATCH] Objective-C++ : Allow prefix attrs on linkage specs.

[Jason Merrill via Gcc-patches]

On 11/28/20 4:53 AM, Iain Sandoe wrote:

(resending - this didn’t seem to reach gcc-patches@)

Jason Merrill  wrote:


On Mon, Nov 23, 2020 at 8:52 AM Iain Sandoe  wrote:
Jason Merrill  wrote:



(NOTE: likewise,   ^~~ starting indent is below ‘int’ for a fixed spacing
font)

===

I’m inclined to think that the second is more useful,
but have patches for both,
which (or something else) do you prefer?

I agree that the second is preferable, thanks.  But let's not 
underline all of "int" there, just the caret is sufficient.  I'd also 
drop the mention of Obj-C++.


t.C:2:1: warning: attributes are not permitted in this position 
[-Wattributes]

    2 | __attribute__(())
  | ^
t.C:3:11: note: attributes may be inserted here
    3 | extern "C" int foo (void);
  |   ^

(the caret _is_ below the space)

(cool, I got to find out how to make a diagnostic point to the space 
between two tokens)


OK?
thanks
Iain


OK, thanks.


[PATCH] C++ : Adjust warning for misplaced attributes.

This removes the reference to Objective-C++ for the warning that
attributes may not be placed before linkage specifications.  It also
adds a note that they may be placed after that.

gcc/cp/ChangeLog:

 * parser.c (cp_parser_declaration): Add a not about where
 attributes may be placed.
---
gcc/cp/parser.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 7a83bf4a2a7..fe1dffc391f 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -13567,9 +13567,12 @@ cp_parser_declaration (cp_parser* parser, tree 
prefix_attrs)

   /* We might have already been here.  */
   if (!c_dialect_objc ())
     {
+  location_t where = get_finish (t2->location);
   warning_at (token1->location, OPT_Wattributes, "attributes are"
-  " only permitted in this position for Objective-C++,"
-  " ignored");
+  " not permitted in this position");
+  where = linemap_position_for_loc_and_offset (line_table,
+   where, 1);
+  inform (where, "attributes may be inserted here");
   attributes = NULL_TREE;
     }
   token1 = t1;

[committed] openmp: Avoid ICE on depend clause on depobj OpenMP construct [PR98072]

[Jakub Jelinek via Gcc-patches]

Hi!

Since r11-5430 we ICE on the following testcase.  When parsing the depobj
directive we don't really use cp_parser_omp_all_clauses routine which ATM
disables generation of location wrappers and the newly added assertion
that there are no location wrappers thus triggers.

Fixed by adding the location wrappers suppression sentinel.

Longer term, we should handle location wrappers inside of OpenMP clauses.

Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk,
queued for backporting.

2020-12-01  Jakub Jelinek  

PR c++/98072
* parser.c (cp_parser_omp_depobj): Suppress location wrappers when
parsing depend clause.

* c-c++-common/gomp/depobj-2.c: New test.

--- gcc/cp/parser.c.jj  2020-11-26 16:22:24.258406951 +0100
+++ gcc/cp/parser.c 2020-12-01 10:37:02.611703012 +0100
@@ -38784,6 +38784,8 @@ cp_parser_omp_depobj (cp_parser *parser,
   cp_lexer_consume_token (parser->lexer);
   if (!strcmp ("depend", p))
{
+ /* Don't create location wrapper nodes within the depend clause.  */
+ auto_suppress_location_wrappers sentinel;
  clause = cp_parser_omp_clause_depend (parser, NULL_TREE, c_loc);
  if (clause)
clause = finish_omp_clauses (clause, C_ORT_OMP);
--- gcc/testsuite/c-c++-common/gomp/depobj-2.c.jj   2020-12-01 
10:37:50.873159687 +0100
+++ gcc/testsuite/c-c++-common/gomp/depobj-2.c  2020-12-01 10:38:14.018899116 
+0100
@@ -0,0 +1,11 @@
+/* PR c++/98072 */
+
+typedef struct __attribute__((__aligned__ (sizeof (void * omp_depend_t {
+  char __omp_depend_t__[2 * sizeof (void *)];
+} omp_depend_t;
+
+void
+foo (int *x, omp_depend_t *y, int z)
+{
+  #pragma omp depobj (*y) depend (in: x[z])
+}


Jakub

Re: [PATCH] cache compute_objsize results in strlen/sprintf (PR 97373)

[Martin Sebor via Gcc-patches]

On 11/23/20 2:04 PM, Jeff Law wrote:



On 11/4/20 5:58 PM, Martin Sebor via Gcc-patches wrote:

To determine the target of a pointer expression and the offset into
it, the increasingly widely used compute_objsize function traverses
the IL following the DEF statements of pointer variables, aggregating
offsets from POINTER_PLUS assignments along the way.  It does that
for many statements that involve pointers, including calls to
built-in functions and (so far only) accesses to char arrays.  When
a function has many such statements with pointers to the same objects
but with different offsets, the traversal ends up visiting the same
pointer assignments repeatedly and unnecessarily.

To avoid this repeated traversal, the attached patch adds the ability
to cache results obtained in prior calls to the function.  The cache
is optional and only used when enabled.

To exercise the cache I have enabled it for the strlen pass (which
is probably the heaviest compute_objsize user).  That happens to
resolve PR 97373 which tracks the pass' failure to detect sprintf
overflowing allocated buffers at a non-constant offset.  I thought
about making this a separate patch but the sprintf/strlen changes
are completely mechanical so it didn't seem worth the effort.

In the benchmarking I've done the cache isn't a huge win there but
it does have a measurable difference in the project I'm wrapping up
where most pointer assignments need to be examined.  The space used
for the cache is negligible on average: fewer than 20 entries per
Glibc function and about 6 for GCC.  The worst case in Glibc is
6 thousand entries and 10k in GCC.  Since the entries are sizable
(216 bytes each) the worst case memory consumption can be reduced
by adding a level of indirection.  A further savings can be obtained
by replacing some of the offset_int members of the entries with
HOST_WIDE_INT.

The efficiency benefits of the cache should increase further as more
of the access checking code is integrated into the same pass.  This
should eventually include the checking currently done in the built-in
expanders.

Tested on x86_64-linux, along with Glibc and Binutils/GDB.

Martin

PS The patch add the new pointer_query class (loosely modeled on
range_query) to builtins.{h,c}.  This should be only temporary,
until the access checking code is moved into a file (and ultimately
a pass) of its own.

gcc-97373.diff

PR middle-end/97373 - missing warning on sprintf into allocated destination

gcc/ChangeLog:

PR middle-end/97373
* builtins.c (compute_objsize): Rename...
(compute_objsize_r): to this.  Change order and types of arguments.
Use new argument.  Adjust calls to self.
(access_ref::get_ref): New member function.
(pointer_query::pointer_query): New member function.
(pointer_query::get_ref): Same.
(pointer_query::put_ref): Same.
(handle_min_max_size): Change order and types of arguments.
(maybe_emit_free_warning): Add a test.
* builtins.h (class pointer_query): New class.
(compute_objsize): Declare an overload.
* gimple-ssa-sprintf.c (get_destination_size):
(handle_printf_call):
* tree-ssa-strlen.c (adjust_last_stmt): Add an argument and use it.
(maybe_warn_overflow): Same.
(handle_builtin_strcpy): Same.
(maybe_diag_stxncpy_trunc): Same.
(handle_builtin_memcpy): Change argument type.  Adjust calls.
(handle_builtin_strcat): Same.
(handle_builtin_memset): Same.
(handle_store): Same.
(strlen_check_and_optimize_call): Same.
(check_and_optimize_stmt): Same.
(strlen_dom_walker): Add new data members.
(strlen_dom_walker::before_dom_children): Use new member.
(printf_strlen_execute): Dump cache performance counters.
* tree-ssa-strlen.h (maybe_diag_stxncpy_trunc): Add argument.
(handle_printf_call): Change argument type.

gcc/testsuite/ChangeLog:

PR middle-end/97373
* gcc.dg/warn-strnlen-no-nul.c:
* g++.dg/warn/Wmismatched-new-delete-2.C: New test.
* gcc.dg/tree-ssa/builtin-sprintf-warn-25.c: New test.

I'm going to hesitatingly ACK this.


Besides rebasing the changes on top the latest trunk I've also
adjusted them to avoid the "inefficient hacks" I mentioned in
the subsequent patch(*).  They were not only inefficient but
also would have caused the function to return incorrect results
in some cases.  After retesting with Binutils/GDB and Glibc
I committed the attached patch in r11-5622.

Martin

[*] https://gcc.gnu.org/pipermail/gcc-patches/2020-November/558775.html



The reason I saw hesitatingly is because I suspect that we're going to
see more cases where caching would be useful and I'd like to have a
general way to do that.  We've already got a ton of caching code in
Ranger and I fully expect more as we continue to write analysis code
that wants to walk backwards.  I don't want to see multiple
implementat

[PATCH] expansion: Further improve double-word modulo, division and divmod [PR97459]

[Jakub Jelinek via Gcc-patches]

Hi!

The following patch implements what Thomas wrote about, in particular
that we can handle also double-word divison by the constants for which
the earlier patch optimized modulo (if it would be otherwise a library
call) and that we can also easily handle such constants shifted to the left.
Unfortunately, seems CSE isn't able to optimize away the two almost
identical sequences (one to compute remainder, one to compute quotient),
probably because of the ADD_OVERFLOW introduced jumps, so the patch also
adjusts expand_DIVMOD.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2020-12-01  Jakub Jelinek  

PR rtl-optimization/97459
* optabs.h (expand_doubleword_divmod): Declare.
* optabs.c (expand_doubleword_divmod): New function.
(expand_binop): Use it.
* internal-fn.c (expand_DIVMOD): Likewise.

* gcc.target/i386/pr97282.c (foo): Use 123456 divisor instead of
10.
* gcc.dg/pr97459-1.c (TESTS): Add tests for 10, 12 and
6144.
* gcc.dg/pr97459-2.c (TESTS): Likewise.
* gcc.dg/pr97459-3.c: New test.
* gcc.dg/pr97459-4.c: New test.
* gcc.dg/pr97459-5.c: New test.
* gcc.dg/pr97459-6.c: New test.

--- gcc/optabs.h.jj 2020-12-01 13:19:12.831127718 +0100
+++ gcc/optabs.h2020-12-01 17:40:08.783137431 +0100
@@ -183,6 +183,8 @@ extern bool force_expand_binop (machine_
enum optab_methods);
 extern rtx expand_vector_broadcast (machine_mode, rtx);
 
+extern rtx expand_doubleword_divmod (machine_mode, rtx, rtx, rtx *, bool);
+
 /* Generate code for a simple binary or unary operation.  "Simple" in
this case means "can be unambiguously described by a (mode, code)
pair and mapped to a single optab."  */
--- gcc/optabs.c.jj 2020-12-01 16:25:01.56773 +0100
+++ gcc/optabs.c2020-12-01 18:11:12.878230572 +0100
@@ -1118,6 +1118,99 @@ expand_doubleword_mod (machine_mode mode
 }
   return NULL_RTX;
 }
+
+/* Similarly to the above function, but compute both quotient and remainder.
+   Quotient can be computed from the remainder as:
+   rem = op0 % op1;  // Handled using expand_doubleword_mod
+   quot = (op0 - rem) * inv; // inv is multiplicative inverse of op1 modulo
+// 2 * BITS_PER_WORD
+
+   We can also handle cases where op1 is a multiple of power of two constant
+   and constant handled by expand_doubleword_mod.
+   op11 = 1 << __builtin_ctz (op1);
+   op12 = op1 / op11;
+   rem1 = op0 % op12;  // Handled using expand_doubleword_mod
+   quot1 = (op0 - rem1) * inv; // inv is multiplicative inverse of op12 modulo
+  // 2 * BITS_PER_WORD
+   rem = (quot1 % op11) * op12 + rem1;
+   quot = quot1 / op11;  */
+
+rtx
+expand_doubleword_divmod (machine_mode mode, rtx op0, rtx op1, rtx *rem,
+ bool unsignedp)
+{
+  *rem = NULL_RTX;
+
+  /* Negative dividend should have been optimized into positive,
+ similarly modulo by 1 and modulo by power of two is optimized
+ differently too.  */
+  if (INTVAL (op1) <= 1 || pow2p_hwi (INTVAL (op1)))
+return NULL_RTX;
+
+  rtx op11 = const1_rtx;
+  rtx op12 = op1;
+  if ((INTVAL (op1) & 1) == 0)
+{
+  int bit = ctz_hwi (INTVAL (op1));
+  op11 = GEN_INT (HOST_WIDE_INT_1 << bit);
+  op12 = GEN_INT (INTVAL (op1) >> bit);
+}
+
+  rtx rem1 = expand_doubleword_mod (mode, op0, op12, unsignedp);
+  if (rem1 == NULL_RTX)
+return NULL_RTX;
+
+  int prec = 2 * BITS_PER_WORD;
+  wide_int a = wide_int::from (INTVAL (op12), prec + 1, UNSIGNED);
+  wide_int b = wi::shifted_mask (prec, 1, false, prec + 1);
+  wide_int m = wide_int::from (wi::mod_inv (a, b), prec, UNSIGNED);
+  rtx inv = immed_wide_int_const (m, mode);
+
+  rtx_insn *last = get_last_insn ();
+  rtx quot1 = expand_simple_binop (mode, MINUS, op0, rem1,
+  NULL_RTX, unsignedp, OPTAB_DIRECT);
+  if (quot1 == NULL_RTX)
+return NULL_RTX;
+
+  quot1 = expand_simple_binop (mode, MULT, quot1, inv,
+  NULL_RTX, unsignedp, OPTAB_DIRECT);
+  if (quot1 == NULL_RTX)
+return NULL_RTX;
+
+  if (op11 != const1_rtx)
+{
+  rtx rem2 = expand_divmod (1, TRUNC_MOD_EXPR, mode, quot1, op11,
+   NULL_RTX, unsignedp);
+  if (rem2 == NULL_RTX)
+   return NULL_RTX;
+
+  rem2 = expand_simple_binop (mode, MULT, rem2, op12, NULL_RTX,
+ unsignedp, OPTAB_DIRECT);
+  if (rem2 == NULL_RTX)
+   return NULL_RTX;
+
+  rem2 = expand_simple_binop (mode, PLUS, rem2, rem1, NULL_RTX,
+ unsignedp, OPTAB_DIRECT);
+  if (rem2 == NULL_RTX)
+   return NULL_RTX;
+
+  rtx quot2 = expand_divmod (0, TRUNC_DIV_EXPR, mode, quot1, op11,
+NULL_RTX, unsignedp);
+  if (quot2 == NULL_RTX)
+   return NULL_RTX;
+
+  rem1 = rem2;
+  quot1 = quot2;
+}

Re: [PATCH] c++: Implement LWG3396 Clarify point of reference for source_location::current() [PR80780, PR93093]

[Jason Merrill via Gcc-patches]

On 12/1/20 3:59 AM, Jakub Jelinek wrote:

Hi!

While std::source_location::current () is static consteval source_location
current() noexcept; in the standard, it also says with LWG3396:
"Any call to current that appears as a default member initializer
([class.mem]), or as a subexpression thereof, should correspond to the
location of the constructor definition or aggregate initialization that uses
the default member initializer.  Any call to current that appears as a
default argument ([dcl.fct.default]), or as a subexpression thereof, should
correspond to the location of the invocation of the function that uses the
default argument ([expr.call])."
so it must work as compiler magic rather than normal immediate functions,
in particular we need to defer its evaluation when parsing default arguments
or nsdmis.





The problem is that with your/JeanHeyd's testcase above, the default
argument parsing is deferred until the whole class is parsed and then
cp_parser_late_parsing_default_args performs that deferred parsing.
Except at this point nothing creates the sk_function_params scope.

So, I think we need some way for the build_over_call code to know if
it is called from within cp_parser_late_parsing_default_args and whether
for an immediate function or not, and take that into account too.

I see cp_parser_late_parsing_default_args calls push_defarg_context,
so perhaps it could check default_arg_context vector, except that
convert_default_arg calls that too around calling break_out_target_exprs
which in the patch is used to perform the late evaluation of the
std::source_location::current() calls.  So it might need to temporarily
pop_defarg_context before break_out_target_exprs and push it again?


How about forcing the constant evaluation in bot_manip?

Or simpler might be to always defer immediate evaluation of 
source_location::current() until genericize time.



And guess we need some tests if it works as expected also in templates;


Please.


2020-12-01  Jakub Jelinek  

LWG3396 Clarify point of reference for source_location::current()
PR c++/80780
PR c++/93093
* cp-tree.h (source_location_current_p): Declare.
* tree.c (source_location_current_p): New function.
(bot_manip): Resolve deferred calls to immediate function
std::source_location::current ().
* call.c (build_over_call): Don't evaluate calls to immediate
function std::source_location::current () in default arguments
or when parsing nsdmi.

* g++.dg/cpp2a/srcloc15.C: New test.
* g++.dg/cpp2a/srcloc16.C: New test.

--- gcc/cp/cp-tree.h.jj 2020-11-26 16:22:24.252407018 +0100
+++ gcc/cp/cp-tree.h2020-11-30 19:45:36.784286305 +0100
@@ -7413,6 +7413,7 @@ extern tree bind_template_template_parm
  extern tree array_type_nelts_total(tree);
  extern tree array_type_nelts_top  (tree);
  extern bool array_of_unknown_bound_p  (const_tree);
+extern bool source_location_current_p  (tree);
  extern tree break_out_target_exprs(tree, bool = false);
  extern tree build_ctor_subob_ref  (tree, tree, tree);
  extern tree replace_placeholders  (tree, tree, bool * = NULL);
--- gcc/cp/tree.c.jj2020-11-26 16:22:24.264406884 +0100
+++ gcc/cp/tree.c   2020-11-30 19:53:58.034686074 +0100
@@ -2968,6 +2968,37 @@ array_type_nelts_total (tree type)
return sz;
  }
  
+/* Return true if FNDECL is std::source_location::current () method.  */

+
+bool
+source_location_current_p (tree fndecl)
+{
+  gcc_checking_assert (TREE_CODE (fndecl) == FUNCTION_DECL
+  && DECL_IMMEDIATE_FUNCTION_P (fndecl));
+  if (DECL_NAME (fndecl) == NULL_TREE
+  || TREE_CODE (TREE_TYPE (fndecl)) != FUNCTION_TYPE
+  || TREE_CODE (TREE_TYPE (TREE_TYPE (fndecl))) != RECORD_TYPE
+  || DECL_CONTEXT (fndecl) != TREE_TYPE (TREE_TYPE (fndecl)))
+return false;
+
+  if (strcmp (IDENTIFIER_POINTER (DECL_NAME (fndecl)), "current") != 0)


You can use id_equal for comparing identifiers to strings.


+return false;
+
+  tree source_location = DECL_CONTEXT (fndecl);
+  if (TYPE_NAME (source_location) == NULL_TREE
+  || TREE_CODE (TYPE_NAME (source_location)) != TYPE_DECL
+  || DECL_NAME (TYPE_NAME (source_location)) == NULL_TREE
+  || strcmp (IDENTIFIER_POINTER (DECL_NAME (TYPE_NAME (source_location))),
+"source_location") != 0)


TYPE_IDENTIFIER would make this shorter.


+return false;
+
+  tree decl
+= lookup_qualified_name (std_node,
+DECL_NAME (TYPE_NAME (source_location)),
+LOOK_want::TYPE, tf_none);
+  return TYPE_NAME (source_location) == decl;


Why not TYPE_CONTEXT (source_location) == std_node?  I don't think we 
need to do name lookup here.



+}
+
  struct bot_data
  {
splay_tree target_remap;
@@ -3064,6 +3095,38 @@ bot_manip (tree* tp, int* walk_subtrees,
set_flags_from_callee (*tp

[PATCH] expansion: FIx up infinite recusion due to double-word modulo optimization

[Jakub Jelinek via Gcc-patches]

Hi!

Jeff has reported that my earlier patch broke rl78-elf, e.g. with
unsigned short foo (unsigned short x) { return x % 7; }
when compiled with -O2 -mg14.  The problem is that rl78 is a BITS_PER_WORD
== 8 target which doesn't have 8-bit modulo or divmod optab, but has instead
16-bit divmod, so my patch attempted to optimize it, then called
expand_divmod to do 8-bit modulo and that in turn tried to do 16-bit modulo
again.

The following patch fixes it in two ways.
One is to not perform the optimization when we have {u,s}divmod_optab
handler for the double-word mode, in that case it is IMHO better to just
do whatever we used to do before.  This alone should fix the infinite
recursion.  But I'd be afraid some other target might have similar problem
and might not have a divmod pattern, but only say a library call.
So the patch also introduces a methods argument to expand_divmod such that
normally we allow everything that was allowed before (using libcalls and
widening), but when called from these expand_doubleword*mod routines we
restrict it to no widening and no libcalls.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2020-12-01  Jakub Jelinek  

* expmed.h (expand_divmod): Only declare if GCC_OPTABS_H is defined.
Add enum optabs_method argument defaulted to OPTAB_LIB_WIDEN.
* expmed.c: Include expmed.h after optabs.h.
(expand_divmod): Add methods argument, if it is not OPTAB_{,LIB_}WIDEN,
don't choose a wider mode, and pass it to other calls instead of
hardcoded OPTAB_LIB_WIDEN.  Avoid emitting libcalls if not
OPTAB_LIB or OPTAB_LIB_WIDEN.
* optabs.c: Include expmed.h after optabs.h.
(expand_doubleword_mod, expand_doubleword_divmod): Pass OPTAB_DIRECT
as last argument to expand_divmod.
(expand_binop): Punt if {s,u}divmod_optab has handler for double-word
int_mode.
* expr.c: Include expmed.h after optabs.h.
* explow.c: Include expmed.h after optabs.h.

--- gcc/expmed.h.jj 2020-01-12 11:54:36.56545 +0100
+++ gcc/expmed.h2020-12-01 19:25:55.117128688 +0100
@@ -716,8 +716,10 @@ extern rtx expand_variable_shift (enum t
  rtx, tree, rtx, int);
 extern rtx expand_shift (enum tree_code, machine_mode, rtx, poly_int64, rtx,
 int);
+#ifdef GCC_OPTABS_H
 extern rtx expand_divmod (int, enum tree_code, machine_mode, rtx, rtx,
- rtx, int);
+ rtx, int, enum optab_methods = OPTAB_LIB_WIDEN);
+#endif
 #endif
 
 extern void store_bit_field (rtx, poly_uint64, poly_uint64,
--- gcc/expmed.c.jj 2020-08-10 10:44:20.659560695 +0200
+++ gcc/expmed.c2020-12-01 19:30:40.993941266 +0100
@@ -31,8 +31,8 @@ along with GCC; see the file COPYING3.
 #include "predict.h"
 #include "memmodel.h"
 #include "tm_p.h"
-#include "expmed.h"
 #include "optabs.h"
+#include "expmed.h"
 #include "regs.h"
 #include "emit-rtl.h"
 #include "diagnostic-core.h"
@@ -4193,7 +4193,8 @@ expand_sdiv_pow2 (scalar_int_mode mode,
 
 rtx
 expand_divmod (int rem_flag, enum tree_code code, machine_mode mode,
-  rtx op0, rtx op1, rtx target, int unsignedp)
+  rtx op0, rtx op1, rtx target, int unsignedp,
+  enum optab_methods methods)
 {
   machine_mode compute_mode;
   rtx tquotient;
@@ -4299,17 +4300,22 @@ expand_divmod (int rem_flag, enum tree_c
   optab2 = (op1_is_pow2 ? optab1
: (unsignedp ? udivmod_optab : sdivmod_optab));
 
-  FOR_EACH_MODE_FROM (compute_mode, mode)
-if (optab_handler (optab1, compute_mode) != CODE_FOR_nothing
-   || optab_handler (optab2, compute_mode) != CODE_FOR_nothing)
-  break;
-
-  if (compute_mode == VOIDmode)
-FOR_EACH_MODE_FROM (compute_mode, mode)
-  if (optab_libfunc (optab1, compute_mode)
- || optab_libfunc (optab2, compute_mode))
+  if (methods == OPTAB_WIDEN || methods == OPTAB_LIB_WIDEN)
+{
+  FOR_EACH_MODE_FROM (compute_mode, mode)
+  if (optab_handler (optab1, compute_mode) != CODE_FOR_nothing
+ || optab_handler (optab2, compute_mode) != CODE_FOR_nothing)
break;
 
+  if (compute_mode == VOIDmode && methods == OPTAB_LIB_WIDEN)
+   FOR_EACH_MODE_FROM (compute_mode, mode)
+ if (optab_libfunc (optab1, compute_mode)
+ || optab_libfunc (optab2, compute_mode))
+   break;
+}
+  else
+compute_mode = mode;
+
   /* If we still couldn't find a mode, use MODE, but expand_binop will
  probably die.  */
   if (compute_mode == VOIDmode)
@@ -4412,8 +4418,7 @@ expand_divmod (int rem_flag, enum tree_c
remainder
  = expand_binop (int_mode, and_optab, op0,
  gen_int_mode (mask, int_mode),
- remainder, 1,
- OPTAB_LIB_WIDEN);
+ remainde

Re: [PATCH v2] C-family : Add attribute 'unavailable'.

[Iain Sandoe]

Hi Martin,

Martin Sebor  wrote:


On 11/29/20 6:56 PM, Iain Sandoe wrote:



Martin Sebor via Gcc-patches  wrote:

On 11/10/20 12:38 PM, Iain Sandoe wrote:

—— commit message.
If an interface is marked 'deprecated' then, presumably, at some point  
it

will be withdrawn and no longer available.  The 'unavailable' attribute
makes it possible to mark up interfaces to indicate this status.

Making an interface unavailable isn't the intent of deprecation in
standards like C, C++, or POSIX.  Rather, the intended next stage
after deprecation is to make the interface available for other uses,
either by the standards themselves, or by implementations, or by
programs (if its name is not in the reserved namespace).  So unless
you have other kinds of deprecation in mind this doesn't seem like
a fitting use case.

coming at things from the standards perspective .. perhaps.
.. however, in the first set of cases above, one never needs to indicate
  unavailability  since the entity never becomes unavailable, it changes
  meaning.
In practice, we don’t have markup of keywords etc. to indicate this (such
deprecation has been handled specifically in the FEs).
The practical (and actual) use of these attributes is in describing the  
lifecycle

of system APIs.
In that context, one could see it being used to describe APIs withdrawn  
in, say,
a Posix standard (as implemented by a given system or according to  
specific

compile-time flags).


Just for the sake of clarity, to make sure we are both talking about
the same thing, the term POSIX uses for "withdrawn" when referring
to APIs is removed.  Withdrawn is a term that ISO tends to apply to
whole standards.  For example, ISO 9945:2003 AKA SUSv3 is a withdrawn
revision of POSIX (likewise, C99 and C11 are withdrawn revisions of
C).

With that, the APIs that have been removed in recent POSIX versions
would not be appropriately described by the attribute, either on
paper, in the POSIX spec (if the hypothetical case when the attribute
was specified the C standard), or in implementations.  The APIs simply
don't exist and so are open to use by programs (unless they are in
the reserved namespace), or by implementations as extensions.
The latter typically means that the APIs are defined (i.e., can
continue to be linked to by legacy applications) but not declared
in the system's header so they can be defined by programs.  Declaring
removed APIs with the unavailable attribute would prevent that and so
would not be conforming.

An example from C (not yet POSIX) is the gets() function that was
removed in C11 (it's still SUSv4).  It's only declared in 
when targeting older versions of C and C++.  Because in more recent
versions of the standards gets is not a reserved name it's valid
for programs to declare symbols named gets (of any kind).  So
declaring gets in  with attribute unavailable would be
nonconforming.

My point here is not necessarily to object to the idea behind
the attribute but to draw attention to the fact that it's not
suitable for standard APIs.


I understand (and have no disagreement with) that this is not a facility
that could be used as an enforcement of standard’s compliance.



However, imagine that you are a system integrator, and you have a
system which supports the API of SUSv3 and some of the additions of
later systems; let’s say you want to help your users avoid use of APIs
which would be unavailable on a SUSv3 system

You could mark up your implementation’s headers such that when presented
with some compile flags, it made the toolchain emit an error if the user
attempted to use APIs that are not present in SUSv3.

This is not actually a completely inane goal - despite that SUSv3 is  
retired -

in reality (AFAICS) there is only one system that’s qualified to UNIX7.


It is used
quite extensively in some codebases where a single set of headers can  
be used

to permit code generation for multiple system versions.


This sounds like a different use case than the next stage after
deprecation.  I haven't come across it but I imagine its purpose
is to foster portability between variants or flavors (rather
than versions) of APSs?  Say one set of APIs for a feature-rich
desktop variant of an OS versus a subset of the same APIs for
an embedded, more limited variant of the same OS.
In the case of Darwin, the compilers are capable of targeting multiple  
versions
of the system (one doesn’t need a separate GCC or clang to target each  
version,
there is a -mmacosx-version-min= flag that allows the target version to  
be specified

on the command line).
Rather than install many versions of headers (and libraries) for all the  
system
versions, the designers elected to have one copy with markup that  
describes the

availability of APIs.
the lifecycle is typically:
introduced from version P.Q (ergo, unavailable before that)
perhaps deprecated at version R.S (ergo the user should be warned)
withdrawn at version X.Y (and unavailable thereafter).
The headers contain mac

Re: [PATCH] libstdc++: Add C++ runtime support for new 128-bit long double format

[Jonathan Wakely via Gcc-patches]

On Tue, 1 Dec 2020 at 19:13, Michael Meissner via Libstdc++
 wrote:
>
> On Tue, Dec 01, 2020 at 04:04:30PM +, Jonathan Wakely wrote:
> > On 01/12/20 15:10 +, Jonathan Wakely wrote:
> > >On 30/11/20 16:30 -0500, Michael Meissner via Libstdc++ wrote:
> > >>Jonathan, could you send a fresh set of patches (or at least 
> > >>replacements)?  I
> > >>tried installing the patches on a master branch I checked out this 
> > >>morning, and
> > >>I got two rejects:
> > >
> > >I don't understand why those chunks failed, but I'll rebase and send a
> > >new patch ASAP.
> >
> > Here's the rebased patch, with regenerated autoconf files and a fix
> > for the  header. I'd changed it since sending
> > the previous patch, and broke the "there's more than one long double"
> > case (i.e. the _GLIBCXX_LONG_DOUBLE_ALT128_COMPAT case).
>
> Unfortunately this patch DOES NOT work at all.
>
> If I build a compiler with the configure option:
> --with-long-double-format=ieee
>
> And I compile this simple program:
>
> #include 
>
> int main(int argc, char *argv[], char *envp[])
> {
>   std::cout << "Hello World!\n";
>   return 0;
> }
>
> I get all of these errors:

It works fine for me (see below). I think your symptoms are due to
using a glibc that doesn't support the new long double, and so
libstdc++ support for it is also disabled. You need at least glibc
2.32 for the libstdc++ changes to be enabled.

[test@ibm-p9b-30 build-ieee128]$ rpm -q glibc
glibc-2.32-2.fc33.ppc64le
[test@ibm-p9b-30 tmp]$ cat hello.C
#include 

int main(int argc, char *argv[], char *envp[])
{
  std::cout << "Hello World!\n";
  return 0;
}

[test@ibm-p9b-30 tmp]$ ~/gcc/ieee128/bin/g++ hello.C
-Wl,-rpath,$HOME/gcc/ieee128/lib64  -v
Using built-in specs.
COLLECT_GCC=/home/test/gcc/ieee128/bin/g++
COLLECT_LTO_WRAPPER=/home/test/gcc/ieee128/libexec/gcc/powerpc64le-unknown-linux-gnu/11.0.0/lto-wrapper
Target: powerpc64le-unknown-linux-gnu
Configured with: ../gcc/configure --prefix=/home/test/gcc/ieee128/
--enable-libstdcxx-debug --disable-bootstrap --disable-multilib
--disable-libvtv --with-system-zlib --without-isl
--with-long-double-format=ieee --enable-languages=c,c++ :
(reconfigured) ../gcc/configure --prefix=/home/test/gcc/ieee128/
--enable-libstdcxx-debug --disable-bootstrap --disable-multilib
--disable-libvtv --with-system-zlib --without-isl
--with-long-double-format=ieee --enable-languages=c,c++ :
(reconfigured) ../gcc/configure --prefix=/home/test/gcc/ieee128/
--enable-libstdcxx-debug --disable-bootstrap --disable-multilib
--disable-libvtv --with-system-zlib --without-isl
--with-long-double-format=ieee --enable-languages=c,c++,lto
--no-create --no-recursion
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.0.0 20201201 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-dumpdir' 'a-'
/home/test/gcc/ieee128/libexec/gcc/powerpc64le-unknown-linux-gnu/11.0.0/cc1plus
-quiet -v -D_GNU_SOURCE hello.C -quiet -dumpdir a- -dumpbase hello.C
-dumpbase-ext .C -version -o /tmp/cc1OWZTT.s
GNU C++17 (GCC) version 11.0.0 20201201 (experimental)
(powerpc64le-unknown-linux-gnu)
   compiled by GNU C version 10.2.1 20201016 (Red Hat 10.2.1-6),
GMP version 6.2.0, MPFR version 4.1.0, MPC version 1.1.0, isl version
none
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
ignoring nonexistent directory
"/home/test/gcc/ieee128/lib/gcc/powerpc64le-unknown-linux-gnu/11.0.0/../../../../powerpc64le-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/home/test/gcc/ieee128/lib/gcc/powerpc64le-unknown-linux-gnu/11.0.0/../../../../include/c++/11.0.0
/home/test/gcc/ieee128/lib/gcc/powerpc64le-unknown-linux-gnu/11.0.0/../../../../include/c++/11.0.0/powerpc64le-unknown-linux-gnu
/home/test/gcc/ieee128/lib/gcc/powerpc64le-unknown-linux-gnu/11.0.0/../../../../include/c++/11.0.0/backward
/home/test/gcc/ieee128/lib/gcc/powerpc64le-unknown-linux-gnu/11.0.0/include
/usr/local/include
/home/test/gcc/ieee128/include
/home/test/gcc/ieee128/lib/gcc/powerpc64le-unknown-linux-gnu/11.0.0/include-fixed
/usr/include
End of search list.
GNU C++17 (GCC) version 11.0.0 20201201 (experimental)
(powerpc64le-unknown-linux-gnu)
   compiled by GNU C version 10.2.1 20201016 (Red Hat 10.2.1-6),
GMP version 6.2.0, MPFR version 4.1.0, MPC version 1.1.0, isl version
none
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 868967e3eb6523a59f0ddd7cc415f672
COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-dumpdir' 'a-'
as -v -a64 -mpowe

Re: [PATCH] c++: Implement LWG3396 Clarify point of reference for source_location::current() [PR80780, PR93093]

[Jakub Jelinek via Gcc-patches]

On Tue, Dec 01, 2020 at 04:05:22PM -0500, Jason Merrill wrote:
> > I see cp_parser_late_parsing_default_args calls push_defarg_context,
> > so perhaps it could check default_arg_context vector, except that
> > convert_default_arg calls that too around calling break_out_target_exprs
> > which in the patch is used to perform the late evaluation of the
> > std::source_location::current() calls.  So it might need to temporarily
> > pop_defarg_context before break_out_target_exprs and push it again?
> 
> How about forcing the constant evaluation in bot_manip?

That is probably a good idea anyway.

> Or simpler might be to always defer immediate evaluation of
> source_location::current() until genericize time.

Will try this too.

Though, I still wonder if it will be ok that we'll evaluate immediate
functions other than std::source_location::current() during the late
parsing of default arguments.

Testcase could be something like:
consteval bool foo (bool x) { if (x) throw 1; return false; }
consteval bool bar (bool x = foo (true)) { return true; }
struct S
{
  consteval static bool baz (bool x = foo (true)) { return true; }
};
constexpr bool a = bar (true);
constexpr bool b = S::baz (true);

We accept now bar, but reject baz.
I think the foo (true) expressions are in both cases in
immediate function context and therefore foo (true) calls are there
not immediate invocations (sure, if one calls bar () or S::baz () 
then it will be invalid anyway).

Jakub

Re: [PATCH] cache compute_objsize results in strlen/sprintf (PR 97373)

[Martin Sebor via Gcc-patches]

On 12/1/20 1:57 PM, Martin Sebor wrote:

On 11/23/20 2:04 PM, Jeff Law wrote:



On 11/4/20 5:58 PM, Martin Sebor via Gcc-patches wrote:

To determine the target of a pointer expression and the offset into
it, the increasingly widely used compute_objsize function traverses
the IL following the DEF statements of pointer variables, aggregating
offsets from POINTER_PLUS assignments along the way.  It does that
for many statements that involve pointers, including calls to
built-in functions and (so far only) accesses to char arrays.  When
a function has many such statements with pointers to the same objects
but with different offsets, the traversal ends up visiting the same
pointer assignments repeatedly and unnecessarily.

To avoid this repeated traversal, the attached patch adds the ability
to cache results obtained in prior calls to the function.  The cache
is optional and only used when enabled.

To exercise the cache I have enabled it for the strlen pass (which
is probably the heaviest compute_objsize user).  That happens to
resolve PR 97373 which tracks the pass' failure to detect sprintf
overflowing allocated buffers at a non-constant offset.  I thought
about making this a separate patch but the sprintf/strlen changes
are completely mechanical so it didn't seem worth the effort.

In the benchmarking I've done the cache isn't a huge win there but
it does have a measurable difference in the project I'm wrapping up
where most pointer assignments need to be examined.  The space used
for the cache is negligible on average: fewer than 20 entries per
Glibc function and about 6 for GCC.  The worst case in Glibc is
6 thousand entries and 10k in GCC.  Since the entries are sizable
(216 bytes each) the worst case memory consumption can be reduced
by adding a level of indirection.  A further savings can be obtained
by replacing some of the offset_int members of the entries with
HOST_WIDE_INT.

The efficiency benefits of the cache should increase further as more
of the access checking code is integrated into the same pass.  This
should eventually include the checking currently done in the built-in
expanders.

Tested on x86_64-linux, along with Glibc and Binutils/GDB.

Martin

PS The patch add the new pointer_query class (loosely modeled on
range_query) to builtins.{h,c}.  This should be only temporary,
until the access checking code is moved into a file (and ultimately
a pass) of its own.

gcc-97373.diff

PR middle-end/97373 - missing warning on sprintf into allocated 
destination


gcc/ChangeLog:

PR middle-end/97373
* builtins.c (compute_objsize): Rename...
(compute_objsize_r): to this.  Change order and types of arguments.
Use new argument.  Adjust calls to self.
(access_ref::get_ref): New member function.
(pointer_query::pointer_query): New member function.
(pointer_query::get_ref): Same.
(pointer_query::put_ref): Same.
(handle_min_max_size): Change order and types of arguments.
(maybe_emit_free_warning): Add a test.
* builtins.h (class pointer_query): New class.
(compute_objsize): Declare an overload.
* gimple-ssa-sprintf.c (get_destination_size):
(handle_printf_call):
* tree-ssa-strlen.c (adjust_last_stmt): Add an argument and use it.
(maybe_warn_overflow): Same.
(handle_builtin_strcpy): Same.
(maybe_diag_stxncpy_trunc): Same.
(handle_builtin_memcpy): Change argument type.  Adjust calls.
(handle_builtin_strcat): Same.
(handle_builtin_memset): Same.
(handle_store): Same.
(strlen_check_and_optimize_call): Same.
(check_and_optimize_stmt): Same.
(strlen_dom_walker): Add new data members.
(strlen_dom_walker::before_dom_children): Use new member.
(printf_strlen_execute): Dump cache performance counters.
* tree-ssa-strlen.h (maybe_diag_stxncpy_trunc): Add argument.
(handle_printf_call): Change argument type.

gcc/testsuite/ChangeLog:

PR middle-end/97373
* gcc.dg/warn-strnlen-no-nul.c:
* g++.dg/warn/Wmismatched-new-delete-2.C: New test.
* gcc.dg/tree-ssa/builtin-sprintf-warn-25.c: New test.

I'm going to hesitatingly ACK this.


Besides rebasing the changes on top the latest trunk I've also
adjusted them to avoid the "inefficient hacks" I mentioned in
the subsequent patch(*).  They were not only inefficient but
also would have caused the function to return incorrect results
in some cases.  After retesting with Binutils/GDB and Glibc
I committed the attached patch in r11-5622.

Martin

[*] https://gcc.gnu.org/pipermail/gcc-patches/2020-November/558775.html



The reason I saw hesitatingly is because I suspect that we're going to
see more cases where caching would be useful and I'd like to have a
general way to do that.  We've already got a ton of caching code in
Ranger and I fully expect more as we continue to write analysis code
that wants to walk backwards.  I don't want to see multiple
implementations of simple caching code.


I neglected to respond to this: if/when a general caching 

[committed] Minor testsuite fixes after recent switch statement improvements

[Jeff Law via Gcc-patches]

Martin L's recent switch table improvements are compromising
gcc.dg/pr46309-2.c on a variety of targets.  They turn the series of if
statements into a switch, then convert that into a relatively simple
overflow test.  The net result is there's nothing interesting left for
tree-ssa-reassoc which is what the test is supposed to be verifying.

The right thing to do here is avoid the conversions which in turn leaves
the IL in the proper state for checking tree-ssa-reassoc's behavior.

I've pushed this to the trunk.

Jeff
commit 968666a011b904f70d12e52180d361faaedfd3a2
Author: Jeff Law 
Date:   Tue Dec 1 14:27:38 2020 -0700

Fix compromised tests after recent switch table improvements

gcc/testsuite
* gcc.dg/pr46309-2.c: Add -fno-bit-tests and -fno-jump-tables
to avoid compromising the test.

diff --git a/gcc/testsuite/gcc.dg/pr46309-2.c b/gcc/testsuite/gcc.dg/pr46309-2.c
index f56df42935c..2903fff225a 100644
--- a/gcc/testsuite/gcc.dg/pr46309-2.c
+++ b/gcc/testsuite/gcc.dg/pr46309-2.c
@@ -1,6 +1,6 @@
 /* PR tree-optimization/46309 */
 /* { dg-do compile } */
-/* { dg-options "-O2 -fno-ipa-icf -fdump-tree-reassoc-details" } */
+/* { dg-options "-O2 -fno-ipa-icf -fno-jump-tables -fno-bit-tests 
-fdump-tree-reassoc-details" } */
 
 int foo (void);
 

Re: [PING] [PATCH] libstdc++: Pretty printers for std::_Bit_reference, std::_Bit_iterator and std::_Bit_const_iterator

[Jonathan Wakely via Gcc-patches]

On 27/11/20 16:33 +, Jonathan Wakely wrote:

On 25/11/20 15:05 +0100, Michael Weghorn via Libstdc++ wrote:

I'd like to ping for this patch:
https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553870.html


Thanks, I'll take another look next week.


I've applied the patch now, thanks.

I adjusted it slightly, to add a test for const_iterator to the C++98
test, simple.cc, consistent with the C++11 one, simple11.cc

Tested powerpc64le-linux, committed to trunk.

Thanks again for the patch, and your patience.



Michael

On 11/10/2020 19.22, Michael Weghorn via Gcc-patches wrote:

On 22/09/2020 12.04, Jonathan Wakely wrote:

On 14/09/20 16:49 +0200, Michael Weghorn via Libstdc++ wrote:

Hi,

the attached patch implements pretty printers relevant for iteration
over std::vector, thus handling the TODO
added in commit 36d0dada6773d7fd7c5ace64c90e723930a3b81e
("Have std::vector printer's iterator return bool for vector",
2019-06-19):

   TODO add printer for vector's _Bit_iterator and
_Bit_const_iterator

Tested on x86_64-pc-linux-gnu (Debian testing).

I haven't filed any copyright assignment for GCC yet, but I'm happy to
do so when pointed to the right place.


Thanks for the patch! I'll send you the form to start the copyuright
assignment process.




Thanks! The copyright assignment is done now. Is there anything else to
do from my side at the moment?



commit 39836f8324d819459cb21198e95b993588c6a2b1
Author: Michael Weghorn 
Date:   Tue Dec 1 21:19:20 2020

libstdc++: Pretty printers for _Bit_reference and _Bit_iterator

'std::_Bit_iterator' and 'std::_Bit_const_iterator' are the iterators
used by 'std::vector'.
'std::_Bit_reference' is e.g. used in range-based for loops over
'std::vector'  like

std::vector vb {true, false, false};
for (auto b : vb) {
// b is of type std::_Bit_reference here
// ...
}

Like iterators of vectors for other types, the actual value is printed.

libstdc++-v3/ChangeLog:

* python/libstdcxx/v6/printers.py (StdBitIteratorPrinter)
(StdBitReferencePrinter): Add pretty-printers for
_Bit_reference, _Bit_iterator and _Bit_const_iterator.
* testsuite/libstdc++-prettyprinters/simple.cc: Test
std::_Bit_reference, std::_Bit_iterator and
std::_Bit_const_iterator.
* testsuite/libstdc++-prettyprinters/simple11.cc: Likewise.

diff --git a/libstdc++-v3/python/libstdcxx/v6/printers.py b/libstdc++-v3/python/libstdcxx/v6/printers.py
index c0f061f79c1..478e44eefdf 100644
--- a/libstdc++-v3/python/libstdcxx/v6/printers.py
+++ b/libstdc++-v3/python/libstdcxx/v6/printers.py
@@ -479,7 +479,27 @@ class StdVectorIteratorPrinter:
 return 'non-dereferenceable iterator for std::vector'
 return str(self.val['_M_current'].dereference())
 
-# TODO add printer for vector's _Bit_iterator and _Bit_const_iterator
+class StdBitIteratorPrinter:
+"Print std::vector's _Bit_iterator and _Bit_const_iterator"
+
+def __init__(self, typename, val):
+self.val = val
+
+def to_string(self):
+if not self.val['_M_p']:
+return 'non-dereferenceable iterator for std::vector'
+return bool(self.val['_M_p'].dereference() & (1 << self.val['_M_offset']))
+
+class StdBitReferencePrinter:
+"Print std::_Bit_reference"
+
+def __init__(self, typename, val):
+self.val = val
+
+def to_string(self):
+if not self.val['_M_p']:
+return 'invalid std::_Bit_reference'
+return bool(self.val['_M_p'].dereference() & (self.val['_M_mask']))
 
 class StdTuplePrinter:
 "Print a std::tuple"
@@ -1965,6 +1985,12 @@ def build_libstdcxx_dictionary ():
 StdDequeIteratorPrinter)
 libstdcxx_printer.add_version('__gnu_cxx::', '__normal_iterator',
   StdVectorIteratorPrinter)
+libstdcxx_printer.add_version('std::', '_Bit_iterator',
+  StdBitIteratorPrinter)
+libstdcxx_printer.add_version('std::', '_Bit_const_iterator',
+  StdBitIteratorPrinter)
+libstdcxx_printer.add_version('std::', '_Bit_reference',
+  StdBitReferencePrinter)
 libstdcxx_printer.add_version('__gnu_cxx::', '_Slist_iterator',
   StdSlistIteratorPrinter)
 libstdcxx_printer.add_container('std::', '_Fwd_list_iterator',
diff --git a/libstdc++-v3/testsuite/libstdc++-prettyprinters/simple.cc b/libstdc++-v3/testsuite/libstdc++-prettyprinters/simple.cc
index 4b44be594f5..9821d1805cf 100644
--- a/libstdc++-v3/testsuite/libstdc++-prettyprinters/simple.cc
+++ b/libstdc++-v3/testsuite/libstdc++-prettyprinters/simple.cc
@@ -127,6 +127,37 @@ main()
   vb.erase(vb.begin());
 // { dg-final { regexp-test vb {std::(__debug::)?vector of length 5, capa

Re: [PATCH] libstdc++: Add C++ runtime support for new 128-bit long double format

[Jonathan Wakely via Gcc-patches]

On Tue, 1 Dec 2020 at 21:10, Jonathan Wakely  wrote:
>
> On Tue, 1 Dec 2020 at 19:13, Michael Meissner via Libstdc++
>  wrote:
> >
> > On Tue, Dec 01, 2020 at 04:04:30PM +, Jonathan Wakely wrote:
> > > On 01/12/20 15:10 +, Jonathan Wakely wrote:
> > > >On 30/11/20 16:30 -0500, Michael Meissner via Libstdc++ wrote:
> > > >>Jonathan, could you send a fresh set of patches (or at least 
> > > >>replacements)?  I
> > > >>tried installing the patches on a master branch I checked out this 
> > > >>morning, and
> > > >>I got two rejects:
> > > >
> > > >I don't understand why those chunks failed, but I'll rebase and send a
> > > >new patch ASAP.
> > >
> > > Here's the rebased patch, with regenerated autoconf files and a fix
> > > for the  header. I'd changed it since sending
> > > the previous patch, and broke the "there's more than one long double"
> > > case (i.e. the _GLIBCXX_LONG_DOUBLE_ALT128_COMPAT case).
> >
> > Unfortunately this patch DOES NOT work at all.
> >
> > If I build a compiler with the configure option:
> > --with-long-double-format=ieee
> >
> > And I compile this simple program:
> >
> > #include 
> >
> > int main(int argc, char *argv[], char *envp[])
> > {
> >   std::cout << "Hello World!\n";
> >   return 0;
> > }
> >
> > I get all of these errors:
>
> It works fine for me (see below). I think your symptoms are due to
> using a glibc that doesn't support the new long double, and so
> libstdc++ support for it is also disabled. You need at least glibc
> 2.32 for the libstdc++ changes to be enabled.

I should improve the failure mode (maybe refuse to compile anything
using the C++ library headers if __LONG_DOUBLE_IEEE128__ is defined
and __ieee128 support was disabled due to the missing glibc
dependency) but that hasn't been a priority. Making the C++ library
support __ieee128 on a machine that doesn't even have libc support for
it isn't possible, so I didn't spend time on that use case. It doesn't
work, and it's not going to work.

Re: [ Preprocessor ] [ Common ] Feature: Macros for identifying the wide and narrow execution string literal encoding

[Jeff Law via Gcc-patches]

On 11/23/20 1:40 PM, JeanHeyd Meneide wrote:
> Dear Jeff,
>
> On Mon, Nov 23, 2020 at 3:02 PM Jeff Law  wrote:
>> You use a getter function to retrieve the value of ret.to, which is
>> fine.  Is there a specific reason why you're not using a setter function
>> to save the value?
>  I did this because I have access to ret.to in the libcpp
> functions! Outside, the structure of that type is unknown and only a
> pointer, so it needs the getter function.
Thanks.  I've fixed up the ChangeLog entry and pushed the patch to the
trunk.

Jeff

Re: [wwwdocs] Document libstdc++ header dependency changes

[Gerald Pfeifer]

On Thu, 26 Nov 2020, Jonathan Wakely via Gcc-patches wrote:
>> Also explain how to replace dynamic exception specifications.
> And a small correction.

Ah, I was going to point that out. :-)

Let's see how many ports/packages the header cleanup is going to break 
this time.  Updating the default version of GCC in FreeBSD has proven a 
painful endeavour the last few times (though the GCC 10 update is mostly 
delayed due to stricter behavior on the Fortran side).

Cheers,
Gerald

Re: [PATCH] detect allocation/deallocation mismatches in user-defined functions (PR94527)

[Jeff Law via Gcc-patches]

On 12/1/20 10:14 AM, Martin Sebor wrote:
> On 11/30/20 3:53 PM, Jeff Law wrote:
>>
>>
>> On 11/13/20 2:45 PM, Martin Sebor via Gcc-patches wrote:
>>> Bug 94527 is request from the kernel developers for an attribute
>>> to indicate that a user-defined function deallocates an object
>>> allocated by an earlier call to an allocation function.  Their
>>> goal is to detect misuses of such functions and the pointers or
>>> objects returned from them.
>>>
>>> The recently submitted patches(*) enable the detection of a subset
>>> of such misuses for standard allocation functions like malloc and
>>> free, but those are just a small fraction of allocation/deallocation
>>> functions used in practice, and only rarely used in the kernel
>>> (mostly in utility programs). The attached patch extends attribute
>>> malloc to enable this detection also for user-defined functions.
>>>
>>> The design extends attribute malloc to accept one or two optional
>>> arguments: one naming a deallocation function that deallocates
>>> pointers returned from the malloc-like function, and another to
>>> denote the position of the pointer argument in the deallocation
>>> functions parameter list.  Any number of deallocators can be
>>> associated with any number of allocators.  This makes it possible
>>> to annotate, for example, all the POSIX  functions that
>>> open and close FILE streams and detect mismatches between any
>>> pairs that aren't suitable (in addition to calling free on
>>> a FILE* returned from fopen, for instance).
>>>
>>> An association with an allocator results in adding an internal
>>> "*dealloc" attribute to the deallocator so that the former can
>>> be quickly looked up based on a call to the latter.
>>>
>>> Tested on x86_64-linux + Glibc & Binutils/GDB (no instances
>>> of the new warnings).
>>>
>>> Martin
>>>
>>> [*] Prerequisite patch
>>> add -Wmismatched-new-delete to middle end (PR 90629)
>>> https://gcc.gnu.org/pipermail/gcc-patches/2020-November/557987.html
>>>
>>> PS In pr94527 Jonathan notes that failing to properly match pairs
>>> of calls isn't limited to APIs that return pointers and applies
>>> to other kinds of "handles" including integers (e.g., the POSIX
>>> open/close APIs), and a detection of such mismatches would be
>>> helpful as well.  David submitted a prototype of this for
>>> the analyzer here:
>>> https://gcc.gnu.org/pipermail/gcc-patches/2020-October/44.html
>>> I chose not to implement nonpointer detection for some of the same
>>> reasons as mentioned in comment #8 on the bug (and also because
>>> there's no support for it in the machinery I use).  I also didn't
>>> use the same attribute as David, in part because I think it's better
>>> to provide separate attributes for pointer APIs and for others
>>> (integers), and in part also because the deallocated_by attribute
>>> design as is cannot accommodate my goal of supporting app standard
>>> functions (including the  freopen which "deallocates"
>>> the third argument).
>>>
>>> gcc-94527.diff
>>>
>>> PR middle-end/94527 - Add an __attribute__ that marks a function as
>>> freeing an object
>>>
>>> gcc/ChangeLog:
>>>
>>> PR middle-end/94527
>>> * builtins.c (gimple_call_alloc_p): Handle user-defined functions.
>>> (fndecl_alloc_p): New helper.
>>> (call_dealloc_argno): New helper.
>>> (gimple_call_dealloc_p): Call it.
>>> (call_dealloc_p): Same.
>>> (matching_alloc_calls_p): Handle user-defined functions.
>>> (maybe_emit_free_warning): Same.
>>> * doc/extend.texi (attribute malloc): Update.
>>> * doc/invoke.texi (-Wmismatched-dealloc): Document new option.
>>>
>>> gcc/c-family/ChangeLog:
>>>
>>> PR middle-end/94527
>>> * c-attribs.c (handle_dealloc_attribute): New function.
>>> (handle_malloc_attribute): Handle argument forms of attribute.
>>> * c.opt (-Wmismatched-dealloc): New option.
>>> (-Wmismatched-new-delete): Update description.
>>>
>>> gcc/testsuite/ChangeLog:
>>>
>>> PR middle-end/94527
>>> * g++.dg/warn/Wmismatched-dealloc-2.C: New test.
>>> * g++.dg/warn/Wmismatched-dealloc.C: New test.
>>> * gcc.dg/Wmismatched-dealloc.c: New test.
>>> * gcc.dg/attr-malloc.c: New test.
>> OK once prereq is wrapped up.
>
> Presumably you're referring to this patch:
>   https://gcc.gnu.org/pipermail/gcc-patches/2020-November/557987.html
> Is there something I need to do to move it forward?  (I'm
> assuming you're still reviewing the rest of the patch so
> please let me know if you're waiting for me to remove
> the objectionable function first.)
Yes, that's the one.  I'm hoping to get to your reply today...

jeff

[committed] wwwdocs: Spell front end that way

[Gerald Pfeifer]

According to our coding conventions we use "front end" for the
noun.  I changed this in the GCC 11 release notes and on the way
noticed GCC 8 also has an instance.

Pushed.

Gerald
---
 htdocs/gcc-11/changes.html | 2 +-
 htdocs/gcc-8/changes.html  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/htdocs/gcc-11/changes.html b/htdocs/gcc-11/changes.html
index 20f29677..cd6e28c1 100644
--- a/htdocs/gcc-11/changes.html
+++ b/htdocs/gcc-11/changes.html
@@ -249,7 +249,7 @@ a work-in-progress.
   
https://gcc.gnu.org/onlinedocs/jit/topics/expressions.html#c.gcc_jit_global_set_initializer";>gcc_jit_global_set_initializer
   
-  9 entrypoints for https://gcc.gnu.org/onlinedocs/jit/topics/asm.html";>directly embedding 
asm statements into a compile, analogous to inline asm in the 
C frontend
+  9 entrypoints for https://gcc.gnu.org/onlinedocs/jit/topics/asm.html";>directly embedding 
asm statements into a compile, analogous to inline asm in the 
C front end
 
   
 
diff --git a/htdocs/gcc-8/changes.html b/htdocs/gcc-8/changes.html
index 83e57db1..638782e8 100644
--- a/htdocs/gcc-8/changes.html
+++ b/htdocs/gcc-8/changes.html
@@ -867,7 +867,7 @@ $ gcc templates-2.cc -fdiagnostics-show-template-tree 
-fno-elide-type
 stored in the heap are scanned precisely.
 
   Escape analysis is fully implemented and enabled by default in
-the Go frontend.  This significantly reduces the number of heap
+the Go front end.  This significantly reduces the number of heap
 allocations by allocating values on the stack instead.
 
 
-- 
2.29.2

Re: [PATCH] gcc-11/changes: Document new configure flag --enable-s390-excess-float-precision

[Gerald Pfeifer]

On Thu, 26 Nov 2020, Marius Hillenbrand via Gcc-patches wrote:
> To document the new behavior around FLT_EVAL_METHOD and configure flag 
> --enable-s390-excess-float-precision on s390, I propose this update to 
> the Release Notes. Please commit to git-wwwdocs if you agree.

Thank you, Marius, and thank you Jeff for committing this.

I applied the follow up below since when refering to the project,
as opposed to just the C compiler, we use GCC (as opposed to gcc).

Gerald


commit aaf1c5103a16fba11e8c89766931be50df8a1ec9
Author: Gerald Pfeifer 
Date:   Tue Dec 1 23:03:04 2020 +0100

Refer to our project as GCC

diff --git a/htdocs/gcc-11/changes.html b/htdocs/gcc-11/changes.html
index cd6e28c1..ed289744 100644
--- a/htdocs/gcc-11/changes.html
+++ b/htdocs/gcc-11/changes.html
@@ -345,11 +345,11 @@ a work-in-progress.
   The behavior when compiling with -fexcess-precision=standard
   (e.g., implied by -std=c99) on s390(x) targets can now be
   controlled at configure time with the flag
-  --enable-s390-excess-float-precision. When enabled, gcc will
+  --enable-s390-excess-float-precision. When enabled, GCC will
   maintain previous behavior and evaluate float expressions in double
   precision, which aligns with the definition of float_t as
-  double. With the flag disabled, gcc will always evaluate
-  float expressions in single precision. In native builds, gcc will by
+  double. With the flag disabled, GCC will always evaluate
+  float expressions in single precision. In native builds, GCC will by
   default match the definition of float_t in the installed
   glibc.
   

Re: [wwwdocs] Document libstdc++ header dependency changes

[Jeff Law via Gcc-patches]

On 12/1/20 2:58 PM, Gerald Pfeifer wrote:
> On Thu, 26 Nov 2020, Jonathan Wakely via Gcc-patches wrote:
>>> Also explain how to replace dynamic exception specifications.
>> And a small correction.
> Ah, I was going to point that out. :-)
>
> Let's see how many ports/packages the header cleanup is going to break 
> this time.  Updating the default version of GCC in FreeBSD has proven a 
> painful endeavour the last few times (though the GCC 10 update is mostly 
> delayed due to stricter behavior on the Fortran side).
I've already fixed ~100 in Fedora...  Those fixes are slowly trickling
to the appropriate upstreams.

Jeff

[committed] Fix more minor testsuite fallout from improved switch optimization

[Jeff Law via Gcc-patches]

pr96480 regressed on nds32le-elf after the recent switch table
improvements.  Options for this test were tweaked as part of those
changes, but they're insufficient to keep it from regressing on
nds32le-elf.  This patch disables jump table optimization on that test
which resolves the regression.

Pushing to the trunk.

jeff
commit cebf2847271b65159e4e687e38a3a64e148084f9
Author: Jeff Law 
Date:   Tue Dec 1 15:06:48 2020 -0700

Fix more minor testsuite fallout from improved switch optimization

gcc/testsuite
* tree-ssa/pr96480.c: Disable jump table optimization

diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr96480.c 
b/gcc/testsuite/gcc.dg/tree-ssa/pr96480.c
index cc04721c1df..fc2103dc172 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/pr96480.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr96480.c
@@ -1,6 +1,6 @@
 /* PR tree-optimization/96480 */
 /* { dg-do compile } */
-/* { dg-options "-O2 -fdump-tree-optimized -fno-bit-tests" } */
+/* { dg-options "-O2 -fdump-tree-optimized -fno-bit-tests -fno-jump-tables" } 
*/
 /* { dg-final { scan-tree-dump " = _\[0-9]* <= 3;" "optimized" } } */
 
 int v[4];

Re: [PATCH] use TYPE_SIZE instead of DECL_SIZE for classes (PR 97595)

[Martin Sebor via Gcc-patches]

On 11/24/20 1:09 PM, Jason Merrill wrote:

On 11/23/20 7:06 PM, Martin Sebor wrote:

On 11/16/20 11:54 PM, Jason Merrill wrote:

On 11/16/20 9:41 PM, Martin Sebor wrote:

The result of DECL_SIZE_UNIT doesn't always reflect the size
of data members of virtual classes.  This can lead to objects
of such types appearing smaller than they are to warnings like
-Warray-bounds or -Wstringop-overflow, causing false positives.

To avoid these false positives, the attached replaces the use
of DECL_SIZE_UNIT in component_ref_size in the middle end with
TYPE_SIZE_UNIT.


Unfortunately, that's not enough; the offset between the intermediate 
base and the virtual base could be greater than the TYPE_SIZE of the 
intermediate base:


extern "C" int printf (const char *, ...);

struct A { char ar1[24]; };
struct B: virtual A { };
struct C { char ar2[42]; };
struct D: B, C { };

int main()
{
   D d;
   printf ("size %d, offset %d\n", sizeof (B), d.ar1 - (char*)(B*)&d);
}

Here base C is allocated between base B and its virtual base A, so 
the offset between them is 50, while the size of B is only 32.


The difference between TYPE_SIZE and DECL_SIZE could be a way to 
recognize the case of bases with virtual bases, and then either hunt 
down all the virtual bases or just use the bounds of the enclosing 
most-derived object.


An advanced analysis of classes with virtual bases is beyond what
I have cycles to tackle at this point (it seems it would also need
to be done in the C++ front end?)  It will have to wait until I have
more time or the next stage 1.

So for now, I've changed component_ref_size to fail when DECL_SIZE
isn't equal TYPE_SIZE.


OK.


+    /* DECL_SIZE may be less than TYPE_SIZE in C++ when referring
+   to the type of a virtual base class which doesn't reflect
+   the size of the virtual's members (see pr97595).  */


The problem isn't with the virtual base class itself (A), but with 
the intermediate base class subobject (B), for which DECL_SIZE 
doesn't include the size of the virtual base A, because the A base 
subobject is allocated separately.


I've also adjusted the comments above the _SIZE macros in tree.h
to more closely reflect what happens there.  My main goal isn't
to describe when they don't match with perfect accuracy, just to
point that they may be unequal and (roughly) when.


Sure, but why not be precise?  e.g.

May be less than TYPE_SIZE for a C++ FIELD_DECL representing a base 
class subobject with its own virtual base classes (which are laid out 
separately).


I have committed the patch with the adjusted comment in r11-5628.

Martin

Re: [PATCH] if-to-switch: Support chain with 2 BBs.

[Jeff Law via Gcc-patches]

On 12/1/20 6:57 AM, Martin Liška wrote:
> Hello.
>
> The following patch is a small tweak than enables more opportunities.
> It fixes bug in PR88702 and I see 54 transformations to happen in SPEC
> 2006.
> Apart from that, I fixed a minor issues which I spotted during bootstrap.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
> Thanks,
> Martin
>
> 0001-if-to-switch-Support-chain-with-2-BBs.patch
>
> From a27dca2d5ef87b493d1ab50da68d0b24dc9fdd93 Mon Sep 17 00:00:00 2001
> From: Martin Liska 
> Date: Tue, 1 Dec 2020 12:18:46 +0100
> Subject: [PATCH] if-to-switch: Support chain with 2 BBs.
>
> As seen in the test-case, even 2 BBs can handle interesting
> cases covered by a jump table or a bit-test.
>
> gcc/ChangeLog:
>
>   PR tree-optimization/88702
>   * gimple-if-to-switch.cc (pass_if_to_switch::execute):
>   Require at least 2 BBs.
>   * gimple-if-to-switch.cc (find_conditions): Require
>   equal precision for low and high of a range.
>
> gcc/testsuite/ChangeLog:
>
>   PR tree-optimization/88702
>   * gcc.dg/tree-ssa/if-to-switch-9.c: New test.
OK
jeff

Re: [PATCH] introduce --param max-object-size

[Jeff Law via Gcc-patches]

On 11/30/20 3:21 PM, Martin Sebor wrote:
> On 11/30/20 1:29 PM, Jeff Law wrote:
>>
>>
>> On 11/17/20 7:09 PM, Martin Sebor wrote:
>>> On 11/16/20 4:54 PM, Jeff Law wrote:

 On 11/16/20 2:04 AM, Richard Biener via Gcc-patches wrote:
> On Sun, Nov 15, 2020 at 1:46 AM Martin Sebor via Gcc-patches
>  wrote:
>> GCC considers PTRDIFF_MAX - 1 to be the size of the largest object
>> so that the difference between a pointer to the byte just past its
>> end and the first one is no more than PTRDIFF_MAX.  This is too
>> liberal in LP64 on most systems because the size of the address
>> space is constrained to much less than that, both by the width
>> of the address bus for physical memory and by the practical
>> limitations of disk sizes for swap files.
> Shouldn't this be a target hook like MAX_OFILE_ALIGNMENT then?

 I think one could argue either way.  Yes, the absolutes are a function
 of the underlying hardware and it can change over the lifetime of a
 processor family which likey differs from MAX_OFILE_ALIGNMENT.


 A PARAM gives the developer  a way to specify the limit which is more
 flexible.


 What I'm not really not sure of is whether is really matters in
 practice
 for end users.
>>>
>>> I'd like to do two things with this change: 1) make it easier
>>> (and encourage users) to detect as early as possible more bugs
>>> due to excessive sizes in various function calls (malloc, memcpy,
>>> etc.), and 2) verify that GCC code uses the limit consistently
>>> and correctly.
>>>
>>> I envision the first would appeal to security-minded distros
>>> and other organizations that use GCC as their system compiler.
>>> For those, a target hook would be more convenient than a --param.
>>> But I also expect individual projects wanting to impose stricter
>>> limits than distros select.  For those, a --param is the only
>>> choice (aside from individual -Wlarger-than- options(*)).
>>>
>>> With this in mind, I think providing both a target hook and
>>> a --param has the best chance of achieving these goals.
>>>
>>> The attached patch does that.
>>>
>>> Martin
>>>
>>> [*] To enforce more realistic object size limits than PTRDIFF_MAX,
>>> GCC users today have to set no fewer than five (or six if we count
>>> -Wstack-usage) options: -Walloca-larger-than,
>>> -Walloc-size-larger-than, -Wframe-larger-than, -Wlarger-than, and
>>> -Wvla-larger-than.  The limits are all independent of one another.
>>> I expect providing a single configurable baseline value for all
>>> these options to use and refine to be helpful to these users.
>>>
>>> gcc-max-objsize.diff
>>>
>> The more I think about this, the more I think it's not really useful in
>> practice.
>>
>> I don't see distros using this flag as there's likely no good values a
>> distro could use that would likely catch bogus code without needlessly
>> flagging valid code.
>
> Red Hat documents 128TB of maximum x86_64 per-process virtual address
> space:
>
>   https://access.redhat.com/articles/rhel-limits
>
> My understanding is that no x86_64 implementation exists that supports
> objects larger than 2^48 bytes.  AFAIK, other 64-bit architectures and
> operating system have similar limits.  The Red Hat page mentions limits
> for all our supported architectures.
And are there any real world cases where lowering from PTRDIFF_MAX to
one of these limits actually matters in our ability to detect bogus
code?   I strongly suspect the answer is no.

>
>>
>> I don't see individual projects using this code either -- for the most
>> part I would not expect a project developer to be able to accurately
>> predict the maximum size of allocations they potentially perform and
>> then bake that into their build system.  There are exceptions (kernel &
>> embedded systems come immediately to mind).
>
> They can refer to documentation like the RHEL link above to figure
> that out.  But even with 64-bit addresses, the size of the virtual
> address space is limited by the amount of physical memory and
> the size of the swap file (limited by the size of the disk), and
> for practical purposes, by the transfer rate of the disk.  So with
> some math, those who care about these things can easily come up
> with a more realistic limit for their application than PTRDIFF_MAX.
Yes, they can, but I strongly suspect they won't.

>
>>
>> And finally, I'm really not a fan of --params for end-user needs.  Those
>> feel much more like options that we as GCC developers use to help
>> ourselves rather than something we encourage others to use.
>
> I don't insist on it to be a parameter.  Whatever other knob will
> work as well.  I just thought this is what parameters were for(*).
>
> Will you approve the patch with the parameter changed to an option?
> Say -fmax-object-size, or would I be wasting my time?
Like the other thread (I believe around loop unrolling heuristics) a
-f= option is just as bad as a param IMHO.

I won

Re: [PATCH v2] tree-ssa-threadbackward.c (profitable_jump_thread_path): Do not allow __builtin_constant_p () before IPA.

[Jeff Law via Gcc-patches]

On 11/23/20 7:36 AM, Ilya Leoshkevich wrote:
> On Fri, 2020-11-20 at 12:14 -0700, Jeff Law wrote:
>> On 6/30/20 12:46 PM, Ilya Leoshkevich wrote:
>>> v1: https://gcc.gnu.org/pipermail/gcc-patches/2020-June/547236.html
>>>
>>> This is the implementation of Jakub's suggestion: allow
>>> __builtin_constant_p () after IPA, but fold it into 0.  Smoke test
>>> passed on s390x-redhat-linux, full regtest and bootstrap are
>>> running on
>>> x86_64-redhat-linux.
>>>
>>> ---
>>>
>>> Linux Kernel (specifically, drivers/leds/trigger/ledtrig-cpu.c)
>>> build
>>> with GCC 10 fails on s390 with "impossible constraint".
>>>
>>> The problem is that jump threading makes __builtin_constant_p ()
>>> lie
>>> when it splits a path containing a non-constant expression in a way
>>> that on each of the resulting paths this expression is constant.
>>>
>>> Fix by disallowing __builtin_constant_p () on threading paths
>>> before
>>> IPA and fold it into 0 after IPA.
>>>
>>> gcc/ChangeLog:
>>>
>>> 2020-06-30  Ilya Leoshkevich  
>>>
>>> * tree-ssa-threadbackward.c (thread_jumps::m_allow_bcp_p): New
>>> member.
>>> (thread_jumps::profitable_jump_thread_path): Do not allow
>>> __builtin_constant_p () on threading paths unless m_allow_bcp_p
>>> is set.
>>> (thread_jumps::find_jump_threads_backwards): Set m_allow_bcp_p.
>>> (pass_thread_jumps::execute): Allow __builtin_constant_p () on
>>> threading paths after IPA.
>>> (pass_early_thread_jumps::execute): Do not allow
>>> __builtin_constant_p () on threading paths before IPA.
>>> * tree-ssa-threadupdate.c (duplicate_thread_path): Fold
>>> __builtin_constant_p () on threading paths into 0.
>>>
>>> gcc/testsuite/ChangeLog:
>>>
>>> 2020-06-30  Ilya Leoshkevich  
>>>
>>> * gcc.target/s390/builtin-constant-p-threading.c: New test.
>> So I'm finally getting back to this.  Thanks for your patience.
>>
>> It's a nasty little problem, and I suspect there's actually some
>> deeper
>> issues here.  While I'd like to claim its a bad use of b_c_p, I don't
>> think I can reasonably make that argument.
>>
>> So what we have is a b_c_p at the start of an if-else chain. 
>> Subsequent
>> tests on the "true" arm of the the b_c_p test may throw us off the
>> constant path (because the constants are out of range).  Once all the
>> tests are passed (it's constant and the constant is in range) the
>> true
>> arm's terminal block has a special asm that requires a constant
>> argument.   In the case where we get to the terminal block on the
>> true
>> arm, the argument to the b_c_p is used as the constant argument to
>> the
>> special asm.
>>
>> At first glace jump threading seems to be doing the right thing. 
>> Except
>> that we end up with two paths to that terminal block with the special
>> asm, one for each of the two constant arguments to the b_c_p call. 
>> Naturally since that same value is used in the asm, we have to
>> introduce
>> a PHI to select between them at the head of the terminal block.   Now
>> the argument in the asm is no longer constant and boom we fail.
>>
>> I briefly pondered if we should only throttle when the argument to
>> the
>> b_c_p is not used elsewhere.  But I think that just hides the problem
>> and with a little work I could probably extend the testcase to still
>> fail in that scenario.
>>
>> I also briefly pondered if we should isolate the terminal block as
>> well
>> (essentially creating one for each unique PHI argument).  We'd likely
>> only need to do that when there's an ASM in the terminal block, but
>> that
>> likely just papers over the problem as well since the ASM could be in
>> a
>> successor of the terminal block.
>>
>> I haven't thought real deeply about it, but I wouldn't be surprised
>> if
>> there's other passes that can trigger similar problems.  Aggressive
>> cross-jumping would be the most obvious, but some of the
>> hosting/sinking
>> of operations past PHIs would seem potentially problematical as well.
>>
>> Jakub suggestion might be the best one in this space.   I don't have
>> anything better right now.  The deeper questions about other passes
>> setting up similar scenarios can probably be punted, I'd expect
>> threading to be far and above the most common way for this to happen
>> and
>> I'd be comfortable faulting in investigation of other cases if/when
>> they
>> happen.
>>
>> So I retract my initial objections.  Let's go with the V2 patch.
>>
>>
>> jeff
> Hi Jeff,
>
> Thanks for having another look!
>
> I did x86_64 builds of SPEC and vmlinux, and it seems that in practice
> v2 does not have any benefit over v1.
>
> What do you think about going with the v1, which is less complex?
No strong opinions.  I think whichever is less invasive in terms of code
quality is probably the way to go.  What we want to avoid is suppressing
threading unnecessarily as that often leads to false positives from
middle-end based warnings.  Suppressing threading can also lead to build
failures in the kernel due to the

Re: [PATCH] libstdc++: Add C++ runtime support for new 128-bit long double format

[Jonathan Wakely via Gcc-patches]

On Tue, 1 Dec 2020 at 22:25, Michael Meissner  wrote:
>
> On Tue, Dec 01, 2020 at 09:10:30PM +, Jonathan Wakely wrote:
> > On Tue, 1 Dec 2020 at 19:13, Michael Meissner via Libstdc++
> >  wrote:
> > >
> > > On Tue, Dec 01, 2020 at 04:04:30PM +, Jonathan Wakely wrote:
> > > > On 01/12/20 15:10 +, Jonathan Wakely wrote:
> > > > >On 30/11/20 16:30 -0500, Michael Meissner via Libstdc++ wrote:
> > > > >>Jonathan, could you send a fresh set of patches (or at least 
> > > > >>replacements)?  I
> > > > >>tried installing the patches on a master branch I checked out this 
> > > > >>morning, and
> > > > >>I got two rejects:
> > > > >
> > > > >I don't understand why those chunks failed, but I'll rebase and send a
> > > > >new patch ASAP.
> > > >
> > > > Here's the rebased patch, with regenerated autoconf files and a fix
> > > > for the  header. I'd changed it since sending
> > > > the previous patch, and broke the "there's more than one long double"
> > > > case (i.e. the _GLIBCXX_LONG_DOUBLE_ALT128_COMPAT case).
> > >
> > > Unfortunately this patch DOES NOT work at all.
> > >
> > > If I build a compiler with the configure option:
> > > --with-long-double-format=ieee
> > >
> > > And I compile this simple program:
> > >
> > > #include 
> > >
> > > int main(int argc, char *argv[], char *envp[])
> > > {
> > >   std::cout << "Hello World!\n";
> > >   return 0;
> > > }
> > >
> > > I get all of these errors:
> >
> > It works fine for me (see below). I think your symptoms are due to
> > using a glibc that doesn't support the new long double, and so
> > libstdc++ support for it is also disabled. You need at least glibc
> > 2.32 for the libstdc++ changes to be enabled.
>
> I am using the Advance Toolchain which includes GLIBC 2.32, which has the
> necessary support.  I will include the config.log as an attachment.

I see the problem. The patch I sent doesn't include the regenerated
files, as is normal for patches posted to the mailing lists.

You need to run autoconf-2.69's autoreconf in the libstdc++-v3 source
tree to regenerate configure, Makefile.in etc. Without doing that
you're just running the same configure script as is on current trunk,
and that doesn't even try looking for IEEE128 support in glibc, and so
the new code in libstdc++ doesn't get enabled.

I've attached a complete patch including those generated files, and
I've also pushed the branch to refs/users/redi/heads/ieee128-squash in
the gcc.gnu.org Git repo. That branch includes your patch for PR
libgcc/97543 which is required for some of the libstdc++ changes to
work properly.


patch.txt.bz2
Description: application/bzip

Re: [PATCH] expansion: FIx up infinite recusion due to double-word modulo optimization

[Jeff Law via Gcc-patches]

On 12/1/20 2:07 PM, Jakub Jelinek wrote:
> Hi!
>
> Jeff has reported that my earlier patch broke rl78-elf, e.g. with
> unsigned short foo (unsigned short x) { return x % 7; }
> when compiled with -O2 -mg14.  The problem is that rl78 is a BITS_PER_WORD
> == 8 target which doesn't have 8-bit modulo or divmod optab, but has instead
> 16-bit divmod, so my patch attempted to optimize it, then called
> expand_divmod to do 8-bit modulo and that in turn tried to do 16-bit modulo
> again.
>
> The following patch fixes it in two ways.
> One is to not perform the optimization when we have {u,s}divmod_optab
> handler for the double-word mode, in that case it is IMHO better to just
> do whatever we used to do before.  This alone should fix the infinite
> recursion.  But I'd be afraid some other target might have similar problem
> and might not have a divmod pattern, but only say a library call.
> So the patch also introduces a methods argument to expand_divmod such that
> normally we allow everything that was allowed before (using libcalls and
> widening), but when called from these expand_doubleword*mod routines we
> restrict it to no widening and no libcalls.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2020-12-01  Jakub Jelinek  
>
>   * expmed.h (expand_divmod): Only declare if GCC_OPTABS_H is defined.
>   Add enum optabs_method argument defaulted to OPTAB_LIB_WIDEN.
>   * expmed.c: Include expmed.h after optabs.h.
>   (expand_divmod): Add methods argument, if it is not OPTAB_{,LIB_}WIDEN,
>   don't choose a wider mode, and pass it to other calls instead of
>   hardcoded OPTAB_LIB_WIDEN.  Avoid emitting libcalls if not
>   OPTAB_LIB or OPTAB_LIB_WIDEN.
>   * optabs.c: Include expmed.h after optabs.h.
>   (expand_doubleword_mod, expand_doubleword_divmod): Pass OPTAB_DIRECT
>   as last argument to expand_divmod.
>   (expand_binop): Punt if {s,u}divmod_optab has handler for double-word
>   int_mode.
>   * expr.c: Include expmed.h after optabs.h.
>   * explow.c: Include expmed.h after optabs.h.
OK.

jeff

Re: [PATCH] if-to-switch: consider only integral types

[Jeff Law via Gcc-patches]

On 12/1/20 12:35 PM, Martin Liška wrote:
> It fixes ICE seen in the PR which is about gswitch statements
> where an index type should be only an integral type.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
> Thanks,
> Martin
>
> gcc/ChangeLog:
>
>     PR tree-optimization/98084
>     * gimple-if-to-switch.cc (find_conditions): Consider only
>     integral types.
>
> gcc/testsuite/ChangeLog:
>
>     PR tree-optimization/98084
>     * gcc.dg/tree-ssa/pr98084.c: New test.
OK
jeff

Re: [pushed] Darwin, D : Adjust the X spec to cater for duplicate use.

[Joseph Myers]

On Tue, 1 Dec 2020, Iain Sandoe wrote:

> Joseph; I don’t know if you have any advice on a ‘better’ long-term
> solution; in some ways I am surprised that the compiler built with
> duplicate specifications for a flag - perhaps the uses merged in some
> way.  Since the use of ‘X’ in D is an upstream decision and the use of

It's fine to have an option supported by multiple languages (here Driver 
counts as a language) as long as the syntax in each language (regarding 
any option arguments etc.) is compatible.  There are several options that 
are language-specific options for C-family languages and for Fortran, but 
not for other languages, for example.

-- 
Joseph S. Myers
jos...@codesourcery.com

[PATCH v4] generate EH info for asm statements (PR93981)

[J.W. Jagersma via Gcc-patches]

The following patch extends the generation of exception handling
information, so that it is possible to catch exceptions thrown from
asm statements, when -fnon-call-exceptions is enabled.  Parts of the
gcc code already suggested this should be possible, but it was never
fully implemented.  Both volatile and non-volatile asms, including
asm goto, are now considered potentially throwing.

A new '-' constraint modifier is introduced, that allows users to
specify which asm outputs must be clobbered in case an exception is
thrown.  This also applies to the jump path for asm goto.

Three new test cases are added.  The target-dependent test should pass
on platforms where throwing from a signal handler is allowed.  The only
platform I am aware of where that is the case is *-linux-gnu, so it is
set to XFAIL on all others.

gcc/
2020-12-01  Jan W. Jagersma  

PR inline-asm/93981
* cfgexpand.c (expand_asm_stmt): Expand throwing asms into jump
insns.  Emit move insns across edges.
* gimplify.c (gimplify_asm_expr): Assign '-' constrained
outputs via a temporary.  Warn for other constraint modifiers
if a copy must be made.
* stmt.c (parse_output_constraint): Accept '-' modifier.
(parse_input_constraint): Don't accept '-' modifier.
* tree-cfg.c (make_edges_bb): Make EH edges for GIMPLE_ASM.
* tree-eh.c (lower_eh_constructs_2): Add case for GIMPLE_ASM.
(tree_could_trap_p): Return true for case ASM_EXPR.
(stmt_could_throw_p): Likewise, for GIMPLE_ASM.
* rtlanal.c (may_trap_p_1): Likewise, for ASM_OPERANDS.
* doc/extend.texi: Document the effects of constraint modifiers
on output semantics for throwing/jumping asms.
* doc/md.texi: Document new '-' constraint modifier.

gcc/testsuite/
2020-12-01  Jan W. Jagersma  

PR inline-asm/93981
* g++.target/i386/pr93981.C: New test.
* g++.dg/eh/pr93981-1.C: New test.
* g++.dg/eh/pr93981-2.C: New test.
---
 gcc/cfgexpand.c |  12 +-
 gcc/doc/extend.texi |   9 ++
 gcc/doc/md.texi |  26 +++-
 gcc/gimplify.c  |  41 ++-
 gcc/rtlanal.c   |   4 +-
 gcc/stmt.c  |  16 +--
 gcc/testsuite/g++.dg/eh/pr93981-1.C |  18 +++
 gcc/testsuite/g++.dg/eh/pr93981-2.C |  29 +
 gcc/testsuite/g++.target/i386/pr93981.C | 151 
 gcc/tree-cfg.c  |   2 +
 gcc/tree-eh.c   |   7 +-
 11 files changed, 291 insertions(+), 24 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/eh/pr93981-1.C
 create mode 100644 gcc/testsuite/g++.dg/eh/pr93981-2.C
 create mode 100644 gcc/testsuite/g++.target/i386/pr93981.C

diff --git a/gcc/cfgexpand.c b/gcc/cfgexpand.c
index 7e0bdd58e85..a32e3637601 100644
--- a/gcc/cfgexpand.c
+++ b/gcc/cfgexpand.c
@@ -3496,7 +3496,7 @@ expand_asm_stmt (gasm *stmt)
   if (noutputs == 0 && nclobbers == 0)
 {
   /* No output operands: put in a raw ASM_OPERANDS rtx.  */
-  if (nlabels > 0)
+  if (stmt_ends_bb_p (stmt))
emit_jump_insn (body);
   else
emit_insn (body);
@@ -3504,7 +3504,7 @@ expand_asm_stmt (gasm *stmt)
   else if (noutputs == 1 && nclobbers == 0)
 {
   ASM_OPERANDS_OUTPUT_CONSTRAINT (body) = constraints[0];
-  if (nlabels > 0)
+  if (stmt_ends_bb_p (stmt))
emit_jump_insn (gen_rtx_SET (output_rvec[0], body));
   else 
emit_insn (gen_rtx_SET (output_rvec[0], body));
@@ -3570,7 +3570,7 @@ expand_asm_stmt (gasm *stmt)
  XVECEXP (body, 0, i++) = gen_rtx_CLOBBER (VOIDmode, clobbered_reg);
}
 
-  if (nlabels > 0)
+  if (stmt_ends_bb_p (stmt))
emit_jump_insn (body);
   else
emit_insn (body);
@@ -3585,9 +3585,7 @@ expand_asm_stmt (gasm *stmt)
 emit_insn (after_md_seq);
   if (after_rtl_seq)
 {
-  if (nlabels == 0)
-   emit_insn (after_rtl_seq);
-  else
+  if (stmt_ends_bb_p (stmt))
{
  edge e;
  edge_iterator ei;
@@ -3604,6 +3602,8 @@ expand_asm_stmt (gasm *stmt)
  insert_insn_on_edge (copy, e);
}
}
+  else
+   emit_insn (after_rtl_seq);
 }
 
   free_temp_slots ();
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 23ede966bae..4e1da68a85e 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -10009,6 +10009,15 @@ ensures that modifying @var{a} does not affect the 
address referenced by
 @var{b}. Otherwise, the location of @var{b} 
 is undefined if @var{a} is modified before using @var{b}.
 
+If the @code{asm} throws an exception (which is possible when
+@option{-fnon-call-exceptions} are enabled) or jumps to a goto label, the
+operand's validity is determined by the constraint modifier used.  For example,
+the @samp{-} modifier may be used to specify that the output must be considered
+clobb

[committed] Fix mcore multilib specification

[Jeff Law via Gcc-patches]

Kito's recent change to multilib handling seems to have exposed a latent
mcore bug.

The mcore 210 does not support little endian.  Yet we try to build a
mcore-210 little-endian multilibs.

I don't know why this wasn't failing before, but clearly it's not
supposed to work.  This patch adjusts the multilib set to not generate
that particular library configuration.  The net result is mcore's libgcc
builds again, as does newlib.

Committing to the trunk,
Jeff


commit db365b61c53136fd6ccc1a9d4f3fc5c020c28bc3
Author: Jeff Law 
Date:   Tue Dec 1 16:23:05 2020 -0700

Fix mcore multilib specification

gcc
* config/mcore/t-mcore (MULTILIB_EXCEPTIONS): Define.

diff --git a/gcc/config/mcore/t-mcore b/gcc/config/mcore/t-mcore
index 0c8763a2739..638a2e0872f 100644
--- a/gcc/config/mcore/t-mcore
+++ b/gcc/config/mcore/t-mcore
@@ -23,7 +23,7 @@
 # MULTILIB_DIRNAMES= align8 align4
 # MULTILIB_MATCHES = 
 # MULTILIB_EXTRA_OPTS  = 
-# MULTILIB_EXCEPTIONS  =
 
+MULTILIB_EXCEPTIONS  = mlittle-endian/m210
 MULTILIB_OPTIONS = mbig-endian/mlittle-endian m210/m340
 MULTILIB_DIRNAMES= big little m210 m340

Re: [PATCH] libstdc++: Add C++ runtime support for new 128-bit long double format

[Michael Meissner via Gcc-patches]

On Tue, Dec 01, 2020 at 10:36:10PM +, Jonathan Wakely wrote:
> You need to run autoconf-2.69's autoreconf in the libstdc++-v3 source
> tree to regenerate configure, Makefile.in etc. Without doing that
> you're just running the same configure script as is on current trunk,
> and that doesn't even try looking for IEEE128 support in glibc, and so
> the new code in libstdc++ doesn't get enabled.
> 
> I've attached a complete patch including those generated files, and
> I've also pushed the branch to refs/users/redi/heads/ieee128-squash in
> the gcc.gnu.org Git repo. That branch includes your patch for PR
> libgcc/97543 which is required for some of the libstdc++ changes to
> work properly.

Sorry, I should have realized about needing to do autoconf.  Any way the new
patch builds the iostream version of hello world.  And it is going through the
rest of the build:

   1) Build 3 compilers with different long double formats;
   2) Build non-bootstrap compilers with the compilers in step 1;
   3) Build bootstrap compilers with the compilers in step 2;
   4) Build spec for the 2 128-bit long double types.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

Re: [PATCH] [tree-optimization] Optimize max/min pattern with comparison

[Jeff Law via Gcc-patches]

On 11/30/20 7:00 PM, Eugene Rozenfeld wrote:
> Thank you for the review Jeff.
>
> I don't need to look at the opcode to know the result. The pattern will be 
> matched only in these 4 cases:
>
> X <= MAX(X, Y) -> true
> X > MAX(X, Y) -> false
> X >= MIN(X, Y) -> true
> X < MIN(X, Y) -> false
>
> So, the result will be true for GE_EXPR and LE_EXPR and false otherwise.
>
> I added two test files: one for positive cases and one for negative cases. 
> The updated patch is attached.
Thanks.  Installed.

jeff

Re: [PATCH] libstdc++: Add C++ runtime support for new 128-bit long double format

[Michael Meissner via Gcc-patches]

Note this is just to keep the gcc-patches archive up to date.  I originally
posted this reply but the attached config.log file was too big.  It was also
sent directly to Jonathan, and he replied.  So I canceled the gcc-patches post,
and I'm sending out this one with a bzip2's config.log:

On Tue, Dec 01, 2020 at 09:10:30PM +, Jonathan Wakely wrote:
> On Tue, 1 Dec 2020 at 19:13, Michael Meissner via Libstdc++
>  wrote:
> >
> > On Tue, Dec 01, 2020 at 04:04:30PM +, Jonathan Wakely wrote:
> > > On 01/12/20 15:10 +, Jonathan Wakely wrote:
> > > >On 30/11/20 16:30 -0500, Michael Meissner via Libstdc++ wrote:
> > > >>Jonathan, could you send a fresh set of patches (or at least 
> > > >>replacements)?  I
> > > >>tried installing the patches on a master branch I checked out this 
> > > >>morning, and
> > > >>I got two rejects:
> > > >
> > > >I don't understand why those chunks failed, but I'll rebase and send a
> > > >new patch ASAP.
> > >
> > > Here's the rebased patch, with regenerated autoconf files and a fix
> > > for the  header. I'd changed it since sending
> > > the previous patch, and broke the "there's more than one long double"
> > > case (i.e. the _GLIBCXX_LONG_DOUBLE_ALT128_COMPAT case).
> >
> > Unfortunately this patch DOES NOT work at all.
> >
> > If I build a compiler with the configure option:
> > --with-long-double-format=ieee
> >
> > And I compile this simple program:
> >
> > #include 
> >
> > int main(int argc, char *argv[], char *envp[])
> > {
> >   std::cout << "Hello World!\n";
> >   return 0;
> > }
> >
> > I get all of these errors:
> 
> It works fine for me (see below). I think your symptoms are due to
> using a glibc that doesn't support the new long double, and so
> libstdc++ support for it is also disabled. You need at least glibc
> 2.32 for the libstdc++ changes to be enabled.

I am using the Advance Toolchain which includes GLIBC 2.32, which has the
necessary support.  I will include the config.log as an attachment.

Note, I am also using the patches I submitted around November 19th.

In particular, there is the patch that maps long double built-in names if long
double is IEEE 128-bit:
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559659.html

I used the patch that tries to fix some problems with gnu attributes:
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559657.html

I used the patch that fixes up the gnu attributes use in libgcc:
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559660.html

I used the patch that adds float128 <-> Decimal conversions:
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559661.html

I used the patch that allows -mabi={ieee,ibm}longdouble to override the default
configuration for long double == 64 bits, without having to use the
-mlong-double-64 option as well:
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559660.html

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797


libstdc++-v3-config.log.bz2
Description: BZip2 compressed data

Re: [PATCH] cache compute_objsize results in strlen/sprintf (PR 97373)

[Jeff Law via Gcc-patches]

On 12/1/20 2:21 PM, Martin Sebor wrote:
> On 12/1/20 1:57 PM, Martin Sebor wrote:
>> On 11/23/20 2:04 PM, Jeff Law wrote:
>>>
>>>
>>> On 11/4/20 5:58 PM, Martin Sebor via Gcc-patches wrote:
 To determine the target of a pointer expression and the offset into
 it, the increasingly widely used compute_objsize function traverses
 the IL following the DEF statements of pointer variables, aggregating
 offsets from POINTER_PLUS assignments along the way.  It does that
 for many statements that involve pointers, including calls to
 built-in functions and (so far only) accesses to char arrays.  When
 a function has many such statements with pointers to the same objects
 but with different offsets, the traversal ends up visiting the same
 pointer assignments repeatedly and unnecessarily.

 To avoid this repeated traversal, the attached patch adds the ability
 to cache results obtained in prior calls to the function.  The cache
 is optional and only used when enabled.

 To exercise the cache I have enabled it for the strlen pass (which
 is probably the heaviest compute_objsize user).  That happens to
 resolve PR 97373 which tracks the pass' failure to detect sprintf
 overflowing allocated buffers at a non-constant offset.  I thought
 about making this a separate patch but the sprintf/strlen changes
 are completely mechanical so it didn't seem worth the effort.

 In the benchmarking I've done the cache isn't a huge win there but
 it does have a measurable difference in the project I'm wrapping up
 where most pointer assignments need to be examined.  The space used
 for the cache is negligible on average: fewer than 20 entries per
 Glibc function and about 6 for GCC.  The worst case in Glibc is
 6 thousand entries and 10k in GCC.  Since the entries are sizable
 (216 bytes each) the worst case memory consumption can be reduced
 by adding a level of indirection.  A further savings can be obtained
 by replacing some of the offset_int members of the entries with
 HOST_WIDE_INT.

 The efficiency benefits of the cache should increase further as more
 of the access checking code is integrated into the same pass.  This
 should eventually include the checking currently done in the built-in
 expanders.

 Tested on x86_64-linux, along with Glibc and Binutils/GDB.

 Martin

 PS The patch add the new pointer_query class (loosely modeled on
 range_query) to builtins.{h,c}.  This should be only temporary,
 until the access checking code is moved into a file (and ultimately
 a pass) of its own.

 gcc-97373.diff

 PR middle-end/97373 - missing warning on sprintf into allocated
 destination

 gcc/ChangeLog:

 PR middle-end/97373
 * builtins.c (compute_objsize): Rename...
 (compute_objsize_r): to this.  Change order and types of
 arguments.
 Use new argument.  Adjust calls to self.
 (access_ref::get_ref): New member function.
 (pointer_query::pointer_query): New member function.
 (pointer_query::get_ref): Same.
 (pointer_query::put_ref): Same.
 (handle_min_max_size): Change order and types of arguments.
 (maybe_emit_free_warning): Add a test.
 * builtins.h (class pointer_query): New class.
 (compute_objsize): Declare an overload.
 * gimple-ssa-sprintf.c (get_destination_size):
 (handle_printf_call):
 * tree-ssa-strlen.c (adjust_last_stmt): Add an argument and use
 it.
 (maybe_warn_overflow): Same.
 (handle_builtin_strcpy): Same.
 (maybe_diag_stxncpy_trunc): Same.
 (handle_builtin_memcpy): Change argument type.  Adjust calls.
 (handle_builtin_strcat): Same.
 (handle_builtin_memset): Same.
 (handle_store): Same.
 (strlen_check_and_optimize_call): Same.
 (check_and_optimize_stmt): Same.
 (strlen_dom_walker): Add new data members.
 (strlen_dom_walker::before_dom_children): Use new member.
 (printf_strlen_execute): Dump cache performance counters.
 * tree-ssa-strlen.h (maybe_diag_stxncpy_trunc): Add argument.
 (handle_printf_call): Change argument type.

 gcc/testsuite/ChangeLog:

 PR middle-end/97373
 * gcc.dg/warn-strnlen-no-nul.c:
 * g++.dg/warn/Wmismatched-new-delete-2.C: New test.
 * gcc.dg/tree-ssa/builtin-sprintf-warn-25.c: New test.
>>> I'm going to hesitatingly ACK this.
>>
>> Besides rebasing the changes on top the latest trunk I've also
>> adjusted them to avoid the "inefficient hacks" I mentioned in
>> the subsequent patch(*).  They were not only inefficient but
>> also would have caused the function to return incorrect results
>> in some cases.  After retesting with Binutils/GDB and Glibc
>> I committed the attached patch in r11-5622.
>>
>

Re: [PATCH] expansion: Further improve double-word modulo, division and divmod [PR97459]

[Jeff Law via Gcc-patches]

On 12/1/20 2:00 PM, Jakub Jelinek wrote:
> Hi!
>
> The following patch implements what Thomas wrote about, in particular
> that we can handle also double-word divison by the constants for which
> the earlier patch optimized modulo (if it would be otherwise a library
> call) and that we can also easily handle such constants shifted to the left.
> Unfortunately, seems CSE isn't able to optimize away the two almost
> identical sequences (one to compute remainder, one to compute quotient),
> probably because of the ADD_OVERFLOW introduced jumps, so the patch also
> adjusts expand_DIVMOD.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2020-12-01  Jakub Jelinek  
>
>   PR rtl-optimization/97459
>   * optabs.h (expand_doubleword_divmod): Declare.
>   * optabs.c (expand_doubleword_divmod): New function.
>   (expand_binop): Use it.
>   * internal-fn.c (expand_DIVMOD): Likewise.
>
>   * gcc.target/i386/pr97282.c (foo): Use 123456 divisor instead of
>   10.
>   * gcc.dg/pr97459-1.c (TESTS): Add tests for 10, 12 and
>   6144.
>   * gcc.dg/pr97459-2.c (TESTS): Likewise.
>   * gcc.dg/pr97459-3.c: New test.
>   * gcc.dg/pr97459-4.c: New test.
>   * gcc.dg/pr97459-5.c: New test.
>   * gcc.dg/pr97459-6.c: New test.
OK
jeff

Re: [PATCH] Add feature test macro for atomic::wait

[Thomas Rodgers via Gcc-patches]

Tested x86_64-pc-linux-gnu, committed to trunk.

Jonathan Wakely writes:

> On 30/11/20 10:17 -0800, Thomas Rodgers wrote:
>>From: Thomas Rodgers 
>>
>>Adds __cpp_lib_atomic_wait feature test macro which was overlooked in
>>the initial commit of this feature. Replaces uses of
>>_GLIBCXX_HAVE_ATOMIC_WAIT.
>>
>>libstdc++-v3/ChangeLog:
>>
>>  * include/bits/atomic_base.h: Replace usage of
>>  _GLIBCXX_HAVE_ATOMIC_WAIT with __cpp_lib_atomic_wait.
>>  * include/bits/atomic_timed_wait.h: Likewise.
>>  * include/bits/atomic_wait.h: Define __cpp_lib_atomic_wait
>>  feature test macro.
>>  * include/bits/semaphore_base: Replace usage of
>>  _GLIBCXX_HAVE_ATOMIC_WAIT with __cpp_lib_atomic_wait.
>>  * include/std/atomic: Likewise.
>>  * include/std/latch: Likewise.
>>  * include/std/semaphore: Likewise.
>>  * include/std/version: Define __cpp_lib_atomic wait
>>  feature test macro and replace usage of
>>  _GLIBCXX_HAVE_ATOMIC_WAIT.
>>  * testsuite/29_atomics/atomic/wait_notify/1.cc: New test.
>>  * testsuite/29_atomics/atomic/wait_notify/2.cc: Likewise.
>>
>>---
>> libstdc++-v3/include/bits/atomic_base.h   | 36 +--
>> libstdc++-v3/include/bits/atomic_timed_wait.h |  5 +--
>> libstdc++-v3/include/bits/atomic_wait.h   |  3 +-
>> libstdc++-v3/include/bits/semaphore_base.h|  4 +--
>> libstdc++-v3/include/std/atomic   | 16 -
>> libstdc++-v3/include/std/latch|  4 +--
>> libstdc++-v3/include/std/semaphore|  4 +--
>> libstdc++-v3/include/std/version  |  7 ++--
>> .../29_atomics/atomic/wait_notify/1.cc| 28 +++
>> .../29_atomics/atomic/wait_notify/2.cc| 29 +++
>> 10 files changed, 98 insertions(+), 38 deletions(-)
>> create mode 100644 libstdc++-v3/testsuite/29_atomics/atomic/wait_notify/1.cc
>> create mode 100644 libstdc++-v3/testsuite/29_atomics/atomic/wait_notify/2.cc
>>
>>diff --git a/libstdc++-v3/include/bits/atomic_base.h 
>>b/libstdc++-v3/include/bits/atomic_base.h
>>index d0d962d3047..ad4e24b4d20 100644
>>--- a/libstdc++-v3/include/bits/atomic_base.h
>>+++ b/libstdc++-v3/include/bits/atomic_base.h
>>@@ -230,7 +230,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>>   return __v == __GCC_ATOMIC_TEST_AND_SET_TRUEVAL;
>> }
>>
>>-#ifdef _GLIBCXX_HAVE_ATOMIC_WAIT
>>+#ifdef __cpp_lib_atomic_wait
>
> I've not always been consistent about using #if or #ifdef for
> __cpp_lib macros, but let's not make that worse in a single patch. I
> think we should just use #if for __cpp_lib macros. That affects
> several places in the patch.
>
>> _GLIBCXX_ALWAYS_INLINE void
>> wait(bool __old,
>>  memory_order __m = memory_order_seq_cst) const noexcept
>>@@ -253,7 +253,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>> { std::__atomic_notify(&_M_i, true); }
>>
>> // TODO add const volatile overload
>>-#endif // HAVE_ATOMIC_WAIT
>>+#endif // __cpp_lib_atomic_wait
>> #endif // C++20
>>
>> _GLIBCXX_ALWAYS_INLINE void
>>@@ -604,7 +604,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>> __cmpexch_failure_order(__m));
>>   }
>>
>>-#if __cplusplus > 201703L && defined _GLIBCXX_HAVE_ATOMIC_WAIT
>>+#if __cpp_lib_atomic_wait
>>   _GLIBCXX_ALWAYS_INLINE void
>>   wait(__int_type __old,
>>memory_order __m = memory_order_seq_cst) const noexcept
>>@@ -627,7 +627,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>>   { std::__atomic_notify(&_M_i, true); }
>>
>>   // TODO add const volatile overload
>>-#endif // C++20 && HAVE_ATOMIC_WAIT
>>+#endif // __cpp_lib_atomic_wait
>>
>>   _GLIBCXX_ALWAYS_INLINE __int_type
>>   fetch_add(__int_type __i,
>>@@ -898,7 +898,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>> int(__m1), int(__m2));
>>   }
>>
>>-#if __cplusplus > 201703L && defined _GLIBCXX_HAVE_ATOMIC_WAIT
>>+#if __cpp_lib_atomic_wait
>>   _GLIBCXX_ALWAYS_INLINE void
>>   wait(__pointer_type __old,
>> memory_order __m = memory_order_seq_cst) noexcept
>>@@ -921,7 +921,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>>   { std::__atomic_notify(&_M_p, true); }
>>
>>   // TODO add const volatile overload
>>-#endif // C++20 && HAVE_ATOMIC_WAIT
>>+#endif // __cpp_lib_atomic_wait
>>
>>   _GLIBCXX_ALWAYS_INLINE __pointer_type
>>   fetch_add(ptrdiff_t __d,
>>@@ -1011,7 +1011,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>>   int(__success), int(__failure));
>>   }
>>
>>-#if __cplusplus > 201703L && defined _GLIBCXX_HAVE_ATOMIC_WAIT
>>+#if __cpp_lib_atomic_wait
>> template
>>   _GLIBCXX_ALWAYS_INLINE void
>>   wait(const _Tp* __ptr, _Val<_Tp> __old,
>>@@ -1036,7 +1036,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>>   { std::__atomic_notify(__ptr, true); }
>>
>>   // TODO add const volatile overload
>>-#endif // C++20 && HAVE_ATOMIC_WAIT
>>+#endif // __cpp_lib_atomic_wait
>>
>> template
>>   _GLIBCXX_ALWAYS_INLINE _T

Re: [PATCH v2] rs6000, vector integer multiply/divide/modulo instructions

[Carl Love via Gcc-patches]

Segher, Pat:

I have updated the patch to address the comments below.

On Wed, 2020-11-25 at 20:30 -0600, Segher Boessenkool wrote:
> On Tue, Nov 24, 2020 at 08:34:51PM -0600, Pat Haugen wrote:
> > On 11/24/20 8:17 PM, Pat Haugen via Gcc-patches wrote:
> > > On 11/24/20 12:59 PM, Carl Love via Gcc-patches wrote:
> > > > +(define_insn "modu_"
> > > > +  [(set (match_operand:VIlong 0 "vsx_register_operand" "=v")
> > > > +   (umod:VIlong (match_operand:VIlong 1
> > > > "vsx_register_operand" "v")
> > > > +(match_operand:VIlong 2
> > > > "vsx_register_operand" "v")))]
> > > > +  "TARGET_POWER10"
> > > > +  "vmodu %0,%1,%2"
> > > > +  [(set_attr "type" "vecdiv")
> > > > +   (set_attr "size" "128")])
> > > 
> > > We should only be setting "size" "128" for instructions that
> > > operate on scalar 128-bit data items (i.e. 'vdivesq' etc). Since
> > > the above insns are either V2DI/V4SI (ala VIlong mode_iterator),
> > > they shouldn't be marked as size 128. If you want to set the size
> > > based on mode, (set_attr "size" "") should do the trick I
> > > believe.
> > 
> > Well, after you update "(define_mode_attr bits" in rs6000.md for
> > V2DI/V4SI.
> 
> So far,  was only used for scalars.  I agree that for vectors
> it
> makes most sense to do the element size (because the vector size
> always
> is 128 bits, and for scheduling the element size can matter).  But,
> the
> definitions of  and  now say
> 
> ;; What data size does this instruction work on?
> ;; This is used for insert, mul and others as necessary.
> (define_attr "size" "8,16,32,64,128" (const_string "32"))
> 
> and
> 
> ;; How many bits in this mode?
> (define_mode_attr bits [(QI "8") (HI "16") (SI "32") (DI "64")
>(SF "32") (DF "64")])
> so those need a bit of update as well then :-)

I set the size based on the vector element size, extendeing the
define_mode_attr bits definition.  Please take a look at the updated
patch.  Hopefully I have this all correct.  Thanks.

Note, I retested the updated patch on 

  powerpc64le-unknown-linux-gnu (Power 9 LE)
  powerpc64le-unknown-linux-gnu (Power 10 LE)

Thanks for the help.

 Carl 

---
rs6000, vector integer multiply/divide/modulo instructions

2020-12-01  Carl Love  

gcc/
* config/rs6000/altivec.h (vec_mulh, vec_div, vec_dive, vec_mod): New
defines.
* config/rs6000/altivec.md (VIlong): Move define to file vsx.md.
* config/rs6000/rs6000-builtin.def (DIVES_V4SI, DIVES_V2DI,
DIVEU_V4SI, DIVEU_V2DI, DIVS_V4SI, DIVS_V2DI, DIVU_V4SI,
DIVU_V2DI, MODS_V2DI, MODS_V4SI, MODU_V2DI, MODU_V4SI,
MULHS_V2DI, MULHS_V4SI, MULHU_V2DI, MULHU_V4SI, MULLD_V2DI):
Add builtin define.
(MULH, DIVE, MOD):  Add new BU_P10_OVERLOAD_2 definitions.
* config/rs6000/rs6000-call.c (VSX_BUILTIN_VEC_DIV,
P10_BUILTIN_VEC_VDIVE, P10_BUILTIN_VEC_VMOD, P10_BUILTIN_VEC_VMULH):
New overloaded definitions.
(builtin_function_type) [P10V_BUILTIN_DIVEU_V4SI,
P10V_BUILTIN_DIVEU_V2DI, P10V_BUILTIN_DIVU_V4SI,
P10V_BUILTIN_DIVU_V2DI, P10V_BUILTIN_MODU_V2DI,
P10V_BUILTIN_MODU_V4SI, P10V_BUILTIN_MULHU_V2DI,
P10V_BUILTIN_MULHU_V4SI, P10V_BUILTIN_MULLD_V2DI]: Add case
statement for builtins.
* config/rs6000/vsx.md (VIlong_char): Add define_mod_attribute.
(UNSPEC_VDIVES, UNSPEC_VDIVEU): Add enum for UNSPECs.
(vsx_mul_v2di, vsx_udiv_v2di): Add if TARGET_POWER10 statement.
(dives_, diveu_, div3, uvdiv3,
mods_, modu_, mulhs_, mulhu_, mulv2di3):
Add define_insn, mode is VIlong.
* doc/extend.texi (vec_mulh, vec_mul, vec_div, vec_dive, vec_mod): Add
builtin descriptions.

gcc/testsuite/
* gcc.target/powerpc/builtins-1-p10-runnable.c: New test file.
---
 gcc/config/rs6000/altivec.h   |   5 +
 gcc/config/rs6000/altivec.md  |   2 -
 gcc/config/rs6000/rs6000-builtin.def  |  22 +
 gcc/config/rs6000/rs6000-call.c   |  49 +++
 gcc/config/rs6000/rs6000.md   |   3 +-
 gcc/config/rs6000/vsx.md  | 213 +++---
 gcc/doc/extend.texi   | 120 ++
 .../powerpc/builtins-1-p10-runnable.c | 398 ++
 8 files changed, 759 insertions(+), 53 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/powerpc/builtins-1-p10-runnable.c

diff --git a/gcc/config/rs6000/altivec.h b/gcc/config/rs6000/altivec.h
index e1884f51bd8..12ccbd2fc2f 100644
--- a/gcc/config/rs6000/altivec.h
+++ b/gcc/config/rs6000/altivec.h
@@ -750,6 +750,11 @@ __altivec_scalar_pred(vec_any_nle,
 #define vec_strir_p(a) __builtin_vec_strir_p (a)
 #define vec_stril_p(a) __builtin_vec_stril_p (a)
 
+#define vec_mulh(a, b) __builtin_vec_mulh ((a), (b))
+#define vec_div(a, b) __builtin_vec_div ((a), (b))
+#define vec_dive(

Re: [PATCH] handle conditionals in -Wstringop-overflow et al. (PR 92936)

[Jeff Law via Gcc-patches]

On 11/30/20 5:58 PM, Martin Sebor wrote:
>
> What I meant was that the recursion in compute_objsize has been
> there in various forms since at least GCC 8 (it's still in other
> parts of GCC today), and it hasn't been a source of reported
> problems.
Understood.  Could be due to a variety of factors.  Having the clamps is
still useful.

>
> I also never did understand how following a use-def chain of
> SSA_NAMEs could have any but linear complexity.  For everything
> except PHIs the traversal is strictly linear; for PHIs, setting
> and testing the visited bitmap breaks cycles, again guaranteeing
> linear complexity.  For reference, here are the numbers I put
> together last year (this was for get_range_strlen_dynamic, not
> compute_objsize):
> https://gcc.gnu.org/pipermail/gcc-patches/2019-July/525000.html
The worst of these cases tend to be when each block has thousands of
PHIs, each of which have thousands of arguments.   This kind of scenario
happens with computed gotos, setjmp/longjmp, EH and similar
mechansisms.  We've gone to great lengths to try and factor the gotos,
landing pads, etc to keep the complexity of the CFG (and indirectly the
complexity of the PHIs) to a minimum.   Bugzilla is riddled with all
kinds of these issues.  If you were to start wandering through them
you'd see the name Brad Lucier show up often ;-)  His codes were often
the motivating case for various clamps.

So the walk up the use-def chains isn't usually too bad, though in
extreme cases, even the linear walk gets expensive.

>
> Anyway, whether it's actually needed or not, the limit's there
> now (in compute_objsize), and the caching should only make
> reaching it that much less likely.
>
Thanks.

jeff

Re: [PATCH] x86: Add -mneeded for GNU_PROPERTY_X86_ISA_1_V[234] marker

[Jeff Law via Gcc-patches]

On 11/16/20 6:44 PM, H.J. Lu wrote:
> On Mon, Nov 16, 2020 at 4:58 PM Jeff Law  wrote:
>>
>> On 11/9/20 11:57 AM, H.J. Lu via Gcc-patches wrote:
>>> GCC 11 supports -march=x86-64-v[234] to enable x86 micro-architecture ISA
>>> levels:
>>>
>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97250
>>>
>>> Binutils has been updated to support GNU_PROPERTY_X86_ISA_1_V[234] marker:
>>>
>>> https://gitlab.com/x86-psABIs/x86-64-ABI/-/merge_requests/13
>>>
>>> with
>>>
>>> commit b0ab06937385e0ae25cebf1991787d64f439bf12
>>> Author: H.J. Lu 
>>> Date:   Fri Oct 30 06:49:57 2020 -0700
>>>
>>> x86: Support GNU_PROPERTY_X86_ISA_1_BASELINE marker
>>>
>>> and
>>>
>>> commit 32930e4edbc06bc6f10c435dbcc63131715df678
>>> Author: H.J. Lu 
>>> Date:   Fri Oct 9 05:05:57 2020 -0700
>>>
>>> x86: Support GNU_PROPERTY_X86_ISA_1_V[234] marker
>>>
>>> in x86 ELF binaries.
>>>
>>> Add -mneeded to emit GNU_PROPERTY_X86_ISA_1_NEEDED property to indicate
>>> the micro-architecture ISA level required to execute the binary.
>>>
>>> gcc/
>>>
>>>   * config.gcc: Replace cet.o with gnu-property.o.  Replace
>>>   i386/t-cet with i386/t-gnu-property.
>>>   * config/i386/cet.c: Renamed to ...
>>>   * config/i386/gnu-property.c: This.
>>>   (emit_gnu_property): New function.
>>>   (file_end_indicate_exec_stack_and_cet): Renamed to ...
>>>   (file_end_indicate_exec_stack_and_gnu_property): This.  Call
>>>   emit_gnu_property to generate GNU_PROPERTY_X86_FEATURE_1_AND and
>>>   GNU_PROPERTY_X86_ISA_1_NEEDED properties.
>>>   * config/i386/i386.opt (mneeded): New.
>>>   * config/i386/linux-common.h (file_end_indicate_exec_stack_and_cet):
>>>   Renamed to ...
>>>   (file_end_indicate_exec_stack_and_gnu_property): This.
>>>   (TARGET_ASM_FILE_END): Updated.
>>>   * config/i386/t-cet: Renamed to ...
>>>   * config/i386/t-gnu-property: This.
>>>   (cet.o): Renamed to ...
>>>   (gnu-property.o): This.
>>>   * doc/invoke.texi: Document -mneeded.
>>>
>>> gcc/testsuite/
>>>
>>>   * gcc.target/i386/x86-needed-1.c: New test.
>>>   * gcc.target/i386/x86-needed-2.c: Likewise.
>>>   * gcc.target/i386/x86-needed-3.c: Likewise.
>> Would it make sense to have -mneeded on by default if we detect a
>> suitable assembler?  The goal being that on the distro level we'd have
>> the appropriate markup for everything in the distro without having to
>> worry about injecting the -mneeded flag into every build.
> It is OK to set the file level USED ISA bits.  But the file level NEEDED
> ISA bits should be set by developers.   Otherwise, function multiversioning
> with AVX512 will lead to output marked with ISA v4 needed which isn't
> true.
True.  Function multi-versioning does turn a lot of traditional thinking
in this space on its side.

OK for the trunk.

jeff

Re: V2 [PATCH] Use SHF_GNU_RETAIN to preserve symbol definitions

[Jeff Law via Gcc-patches]

On 11/17/20 6:20 AM, H.J. Lu via Gcc-patches wrote:
> On Mon, Nov 16, 2020 at 7:59 PM Hans-Peter Nilsson  wrote:
>> On Fri, 13 Nov 2020, H.J. Lu via Gcc-patches wrote:
>>> Done.  Here is the updated patch.
>> Hi.  I see a test-case for this kind of construct:
>>
>>  int foo __attribute__((__used__, __section__ (".bar"))) = 42;
>>
>> and IIUC that it's handled as I'd hope (setting "R" on the named
>> section, not another derived section), good.
>>
>> Could you also add a test-case that the same construct
>> *without* a specific initializer is handled the same way?
>> I.e.:
>>  int foo __attribute__((__used__, __section__ (".bar")));
>>
> Done.  The only changes are
>
> /* { dg-final { scan-assembler ".data.used_bar_sec,\"awR\"" } } */
> ...
> int __attribute__((used,section(".data.used_bar_sec"))) used_bar;
>
> and 2 additional tests for -fcommon.
>
> Thanks.
>
>
> 0001-Use-SHF_GNU_RETAIN-to-preserve-symbol-definitions.patch
>
> From d19f2e2ec7f0f47121a2a4c05ffe20af8972c1bb Mon Sep 17 00:00:00 2001
> From: "H.J. Lu" 
> Date: Mon, 3 Feb 2020 11:55:43 -0800
> Subject: [PATCH] Use SHF_GNU_RETAIN to preserve symbol definitions
>
> In assemly code, the section flag 'R' sets the SHF_GNU_RETAIN flag to
> indicate that the section must be preserved by the linker.
>
> Add SECTION_RETAIN to indicate a section should be retained by the linker
> and set SECTION_RETAIN on section for the preserved symbol if assembler
> supports SHF_GNU_RETAIN.  All retained symbols are placed in separate
> sections with
>
>   .section .data.rel.local.preserved_symbol,"awR"
> preserved_symbol:
> ...
>   .section .data.rel.local,"aw"
> not_preserved_symbol:
> ...
>
> to avoid
>
>   .section .data.rel.local,"awR"
> preserved_symbol:
> ...
> not_preserved_symbol:
> ...
>
> which places not_preserved_symbol definition in the SHF_GNU_RETAIN
> section.
>
> gcc/
>
> 2020-11-XX  H.J. Lu  
>
>   * configure.ac (HAVE_GAS_SHF_GNU_RETAIN): New.  Define 1 if
>   the assembler supports marking sections with SHF_GNU_RETAIN flag.
>   * output.h (SECTION_RETAIN): New.  Defined as 0x400.
>   (SECTION_MACH_DEP): Changed from 0x400 to 0x800.
>   (default_unique_section): Add a bool argument.
>   * varasm.c (get_section): Set SECTION_RETAIN for the preserved
>   symbol with HAVE_GAS_SHF_GNU_RETAIN.
>   (resolve_unique_section): Used named section for the preserved
>   symbol if assembler supports SHF_GNU_RETAIN.
>   (get_variable_section): Handle the preserved common symbol with
>   HAVE_GAS_SHF_GNU_RETAIN.
>   (default_elf_asm_named_section): Require the full declaration and
>   use the 'R' flag for SECTION_RETAIN.
>   * config.in: Regenerated.
>   * configure: Likewise.
>
> gcc/testsuite/
>
> 2020-11-XX  H.J. Lu  
>   Jozef Lawrynowicz  
>
>   * c-c++-common/attr-used.c: Check the 'R' flag.
>   * c-c++-common/attr-used-2.c: Likewise.
>   * c-c++-common/attr-used-3.c: New test.
>   * c-c++-common/attr-used-4.c: Likewise.
>   * gcc.c-torture/compile/attr-used-retain-1.c: Likewise.
>   * gcc.c-torture/compile/attr-used-retain-2.c: Likewise.
>   * gcc.c-torture/compile/attr-used-retain-3.c: Likewise.
>   * gcc.c-torture/compile/attr-used-retain-4.c: Likewise.
>   * lib/target-supports.exp
>   (check_effective_target_R_flag_in_section): New proc.
Can we try to avoid the #if stuff, particulary in varasm.c.  We worked
pretty hard to reduce the amount of conditionally compiled code through
the years and we should try to avoid adding new instances.

HAVE_GAS_SHF_GNU_RETAIN is going to be a compile-time constant, so it
should be just as efficient to do things like

if (HAVE_GAS_SHF_GNU_RETAIN)
   ... whatever ...

This has the advantage that the same code is presented to the
front-ends, so we're at lot less likely to stumble over set-but-not-used
warnings and the like that were so problematical a few years back.  In
fact, you use that style elsewhere in varasm.c :-)


I think you need to document the new effective target check in
doc/sourcebuild.texi

With those changes this should be fine.

jeff

Re: [PATCH] add -Wmismatched-new-delete to middle end (PR 90629)

[Jeff Law via Gcc-patches]

On 11/17/20 11:02 AM, Martin Sebor wrote:
>
>>
>> If you're interested
>> torsion.usersys.redhat.com:/opt/notnfs/law/WARNINGS contains all the
>> lines with "warning:" from all the Fedora test builds. Warning (pun
>> intended), it's big...  10G, so don't try to download it :-)  But it
>> is faster than find | xargs zgrep across all the build logs :-)
>
> There are quite a few (411 instances of -Wmismatched-new-delete to
> be exact) but without more context (at least the informational notes)
> they're hard to analyze.  I looked at just the first one and it points
> to this bug:
>
> ./gengetopt/builds/80/log.gz:gengetopt.cc:581:12: warning: 'free'
> called on pointer returned from a mismatched allocation function
> [-Wmismatched-new-delete]
>
> gengetopt_create_option (gengetopt_option *&n, const char * long_opt,
> char short_opt,
>   const char * desc,
>   int type, int flagstat, int required,
>   const char * default_value,
>   const char * group_value,
>   const char * mode_value,
>   const char * type_str,
>   const AcceptedValues *acceptedvalues,
>   int multiple,
>   int argoptional)
> {
>   if ((long_opt == NULL) ||
>   (long_opt[0] == 0) ||
>   (desc == NULL))
>     return FOUND_BUG;
>
>   n = new gengetopt_option; <<< allocate by new
>   if (n == NULL)
>     return NOT_ENOUGH_MEMORY;
>
>   // here we will set required anyway
>   n->required_set = true;
>
>   n->long_opt = strdup (long_opt);
>   if (n->long_opt == NULL)
>     {
>   free (n); <<< deallocate by free
>   return NOT_ENOUGH_MEMORY;
>     }
>
> Based on what others have said about what some static analyzers
> report I expect this to be a common bug (the "operator delete"
> message accounts for 336 instances out of the 411).
Yea, I suspect there's a lot of these lying around and probably will
continue to do so as long as folks aren't using -Werror.  Hence my
desire to have an opt-in mechanism in Fedora that turns on -Werror
within redhat-rpm-config for opted-in packages.

>
>>> diff --git a/gcc/builtins.c b/gcc/builtins.c
>>> index 5d60eab6ba2..1b8a5b82dac 100644
>>> --- a/gcc/builtins.c
>>> +++ b/gcc/builtins.c
>>> @@ -12589,30 +12594,336 @@ maybe_emit_sprintf_chk_warning (tree exp,
>>> enum built_in_function fcode)
>>>   access_write_only);
>>>   }
>>>   -/* Emit warning if a free is called with address of a variable.  */
>>> +/* Return the location of the assignment STMT if it has one, or
>>> another
>>> +   assignment on the chain that has one.  Used to improve the location
>>> +   of informational notes.  */
>>>   -static void
>>> +static location_t
>>> +find_assignment_location (tree var)
>>> +{
>>> +  gimple *stmt = SSA_NAME_DEF_STMT (var);
>>> +
>>> +  for (gimple *asgn = stmt; ; )
>>> +    {
>>> +  if (gimple_has_location (asgn))
>>> +    return gimple_location (asgn);
>>> +
>>> +  if (!is_gimple_assign (asgn))
>>> +    break;
>>> +
>>> +  tree rhs = gimple_assign_rhs1 (asgn);
>>> +  if (TREE_CODE (rhs) != SSA_NAME)
>>> +    break;
>>> +
>>> +  asgn = SSA_NAME_DEF_STMT (rhs);
>>> +    }
>>
>> What is this code for ^^^
>>
>>
>> Under what conditions does the assignment not have a location?
>> Perhaps if it's a default definition?
>
> I've seen all sorts of assignments with no location, including
> ASSERT_EXPRs, BIT_AND_EXPRs, as well as MIN/MAX_EXPs, clobber
> statements and others.  I didn't try to understand the pattern
> behind them.
I'd rather not include that hunk and instead xfail any tests affected by
the missing locations until such time as we fix them rather than just
papering over the problem.  Fixing locations helps diagnostics, our
ability to suppress them via pragmas, etc.    So it's in our best
interest to fix these issues.

>
>> All the nonsense walking up the use-def chain seems unnecessary and
>> probably misleading when we actually issue the diagnostic. Why are
>> you going through the trouble to do that?
>
> The "nonsense" is me doing my best to provide at least some context
> for warnings that might otherwise not have any and be harder to track
> down to the root cause.  A message like:
>
>   warning: ‘free’ called on pointer ‘’ with nonzero offset
>
> with nothing else for a function hundreds of lines long makes it
> harder to track down the cause of the problem than with a note
> pointing to at least a location of the closest assignment to
> the unknown pointer.
>
> That said, in this patch the function is only used for constants
> and AFAICS, doesn't get exercised by any tests so it can probably
> be removed with no adverse effect.  I do expect it to need to come
> back in some form because of the missing location problem.  (It
> comes from a bigger patch in progress where it's used more
> extensively.)
ACK.  So let's avoid it for now and try to tackle the mis

Re: [PATCH/RFC v2] Add -fdiagnostics-path-format=html [v2]

[Jeff Law via Gcc-patches]

On 11/10/20 9:08 AM, David Malcolm via Gcc-patches wrote:
> Here's an updated version of the HTML output idea from:
>   https://gcc.gnu.org/pipermail/gcc-patches/2020-October/556848.html
>
> I reworked the HTML path output to show stack frames as well as just
> runs of events, using drop-shadows to give a 3D look.  The idea is to try
> to highlight the stack of frames as if it were an actual stack of
> overlapping cards.
>
> Updated HTML for the example from the earlier patch can be seen here:
>   
> https://dmalcolm.fedorapeople.org/gcc/2020-11-05/html-examples/test.c.path-1.html
> As before, other examples can be seen in that directory, such as:
>   Signal handler issue:
> 
> https://dmalcolm.fedorapeople.org/gcc/2020-11-05/html-examples/signal-1.c.path-1.html
>   Leak due to longjmp past a "free":
> 
> https://dmalcolm.fedorapeople.org/gcc/2020-11-05/html-examples/setjmp-7.c.path-1.html
>
> Other changes in v2:
> * switched j and k in keyboard navigation so that j is "next event"
> and k is "previous event"
> * fixed event element IDs, fixing a bug where it assumed they were in
>   ascending order
> * moved HTML printing code out of path_summary and event_range
> * more selftest coverage
>
> As before, this approach merely emits the path information; it doesn't
> capture the associated diagnostic.  I'm working on an alternate approach
> for v3 of the patch that does that; doing that requires reworking
> pretty_printer.
>
> I'm not sure on exactly the correct approach here; for v3 I'm
> experimenting with an "html" option for -fdiagnostics-format= which
> when selected would supplement the existing text output, by additionally
> writing out an HTML file for each diagnostic group, with path
> information captured there.  Doing it per group means that the classic
> "warning"/"note" pairs would be grouped together in that output.
>
> I'm not sure what that ought to do with paths though; part of the point
> of doing it is to have less verbose output on stderr whilst capturing
> the pertinent information "on the side" in the HTML file.
>
> Thoughts?
>
> Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu, FWIW.
>
> gcc/ChangeLog:
>   * common.opt (diagnostic_path_format): Add DPF_HTML.
>   * diagnostic-format-json.cc: Include "selftest.h".
>   * diagnostic-show-locus.c (colorizer::m_context): Replace with...
>   (colorizer::m_pp): ...this new field.
>   (layout::m_context): Make const.
>   (layout::m_is_html): New field.
>   (layout::m_html_label_writer): New field.
>   (colorizer::colorizer): Update for use of pp rather than context.
>   (colorizer::begin_state): Likewise.
>   (colorizer::finish_state): Likewise.
>   (colorizer::get_color_by_name): Likewise.
>   (layout::layout): Make "context" param const.  Add "pp", "is_html"
>   and "label_writer" params, with defaults.  Use them to initialize
>   new fields.  Update for change to m_colorizer.
>   (layout::print_source_line): Add HTML support.
>   (layout::start_annotation_line): Likewise.
>   (layout::print_annotation_line): Likewise.
>   (line_label::line_label): Make context const.  Add
>   "original_range_idx" param and use it to initialize...
>   (line_label::m_original_range_idx): ...this new field.
>   (layout::print_any_labels): Pass original index of range to
>   line_label ctor.  Add HTML support.
>   (get_affected_range): Make context const.
>   (get_printed_columns): Likewise.
>   (line_corrections::line_corrections): Likewise.
>   (line_corrections::m_context): Likewise.
>   (layout::print_line): Don't print fix-it hints for HTML support.
>   (diagnostic_show_locus_as_html): New.
>   (selftest::assert_html_eq): New.
>   (ASSERT_HTML_EQ): New.
>   (selftest::test_one_liner_simple_caret): Verify the HTML output.
>   (selftest::test_diagnostic_show_locus_fixit_lines): Likewise.
>   (selftest::test_html): New.
>   (selftest::diagnostic_show_locus_c_tests): Call it.
>   * diagnostic.c (diagnostic_show_any_path): Pass the location to
>   the print_path callback.
>   * diagnostic.h (enum diagnostic_path_format): Add DPF_HTML.
>   (diagnostic_context::num_html_paths): New field.
>   (diagnostic_context::print_path): Add location_t param.
>   (class html_label_writer): New.
>   (diagnostic_show_locus_as_html): New decl.
>   * doc/invoke.texi (Diagnostic Message Formatting Options): Add
>   "html" to -fdiagnostics-path-format=.
>   (-fdiagnostics-path-format=): Add html.
>   * pretty-print.c (pp_write_text_as_html_to_stream): New.
>   * pretty-print.h (pp_write_text_as_html_to_stream): New decl.
>   * selftest-diagnostic.c (selftest::html_printer::html_printer):
>   New ctor.
>   (selftest::html_printer::get_html_output): New.
>   * selftest-diagnostic.h (class selftest::html_printer): New.
>   * tree-diagnostic-path.cc: Define GCC

Re: [patch][rtl-optimization][i386][pr97777] Fix a reg-stack df maintenance bug triggered by zero-call-used-regs pass.

[Jeff Law via Gcc-patches]

On 11/30/20 1:50 PM, Qing Zhao wrote:
> Hi, Jeff,
>
> Sorry for the late reply due to thanksgiving long weekend. 
>
>> On Nov 25, 2020, at 1:37 PM, Jeff Law > > wrote:
>>
>>
>>
>> On 11/19/20 8:59 AM, Qing Zhao via Gcc-patches wrote:
>>> Hi, 
>>>
>>> PR9 - ICE: in df_refs_verify, at df-scan.c:3991 with -O
>>> -ffinite-math-only -fzero-call-used-regs=all
>>>
>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9
>>> 
>>>
>>> Is a bug triggered by the new pass zero-call-used-regs, however,
>>> it’s an old bug in the pass “reg-stack”.
>>> This pass does not correctly maintain the df information after
>>> transformation. 
>>>
>>> Since the transformation is reg-stack pass is quite complicate,
>>> involving both instruction changes and control
>>> Flow changes, I called “df_insn_rescan_all” after the transformation
>>> is done.
>>>
>>> The patch has been tested with bootstrap with
>>> --enable-checking=yes,rtl,df,extra, no regression. 
>>>
>>> Okay for commit?
>>>
>>> Qing
>>>
>>> From c2573c6c8552b7b4c2eedb0684ce48b5c11436ec Mon Sep 17 00:00:00 2001
>>> From: qing zhao 
>>> Date: Thu, 19 Nov 2020 16:46:50 +0100
>>> Subject: [PATCH] rtl-optimization: Fix data flow maintenance bug in
>>> reg-stack.c [pr9]
>>>
>>> reg-stack pass does not maintain the data flow information correctly.
>>> call df_insn_rescan_all after the transformation is done.
>>>
>>>    gcc/
>>> PR rtl-optimization/9
>>> * reg-stack.c (rest_of_handle_stack_regs): call
>>> df_insn_rescan_all if reg_to_stack return true.
>>>
>>> gcc/testsuite/
>>> PR rtl-optimization/9
>>> * gcc.target/i386/pr9.c: New test.
>> I'd like to see more analysis here.
>>
>> ie, precisely what data is out of date and why?
>
> For the simple testing case, what happened is, for the insn #6:
>
> (gdb) call debug_rtx(insn)
> (insn 6 26 7 2 (set (reg:XF 8 st [84])
>         (reg:XF 9 st(1) [85])) "t.c":4:10 134 {*movxf_internal}
>      (expr_list:REG_EQUAL (const_double:XF 0.0 [0x0.0p+0])
>         (nil)))
>
> After the following statement in reg-stack.c:
>    3080           control_flow_insn_deleted |= subst_stack_regs (insn,
> ®stack);
>
> This insn # 6 becomes:
> (gdb) call debug_rtx(insn)
> (insn 6 26 7 2 (set (reg:XF 8 st)
>         (reg:XF 8 st)) "t.c":4:10 134 {*movxf_internal}
>      (expr_list:REG_EQUAL (const_double:XF 0.0 [0x0.0p+0])
>         (nil)))
>
> However, there is no any df maintenance routine (for example,
> df_insn_rescan, etc) is called for this changed insn.
So we are clearing the x87 registers with that option.  Hence the change
in reg-stack behavior.  I'm a bit surprised by this as I don't see
clearing the x87 registers as particularly helpful from a security
standpoint.  But I haven't followed that discussion closely.


>
> As I checked, the transformation for this pass “stack” is quite
> complicated. In addition to the above register replacement,
> New insns might be inserted, and control flow might be changed, but
> for most of the transformations applied in this pass,
> There is no corresponding df maintenance routine is added for deferred
> df rescanning.
But this has been the case essentially for ever with reg-stack.  So
what's unclear to me is why it's suddenly a problem now.

Jeff

Re: [00/23] Make fwprop use an on-the-side RTL SSA representation

[Jeff Law via Gcc-patches]

On 11/30/20 5:03 PM, Michael Matz wrote:
> Hello,
>
> On Mon, 30 Nov 2020, Jeff Law wrote:
>
 So, then let's start with one of 
 the prime examples of SSA deconstruction problems, the lost swap, and how 
 it comes to be: we start with a swap:

   x = ..., y = ...
   if (cond)
 tmp=x, x=y, y=tmp

 (1) into SSA:

   x0 = ..., y0 = ...
   if (cond)
 tmp = x0, x1=y0, y1=tmp;
   x2 = PHI(x0,x1),  y2 = PHI(y0,y1)

 (2) copy-prop:

   x0 = ..., y0 = ...
   if (cond)
 ;
   x2 = PHI(x0,y0),  y2 = PHI(y0,x0)
>>> So the point is that this isn't what the RTL would look like even
>>> when using RTL SSA.  Putting y0 in x2 PHI and x0 in the y2 PHI is
>>> representationally invalid.
>>>
>>> Like I say, this isn't a “native” SSA form: it's just using SSA
>>> constructs to represent dataflow in normal RTL.
>> It appears that the PHI arguments have to be different instances of the
>> result.  So the case above can't happen, which helps, but I'm not sure
>> it's necessarily sufficient to avoid all the problems in this space.
>> IIRC you can get into a similar scenario by transformations that result
>> in overlapping lifetimes for different instances of the same object. 
>> They didn't necessarily overlap when the SSA form was created, but may
>> after things like CSE or copy propagation.
> I think the reasoning why this can't (or should not) happen is the 
> following: if different instances of the same objects (say, one before, 
> one after a modification) exist, they must necessarily be stored in 
> different pseudos (otherwise the RTL transformation itself was already 
> invalid), and that causes them to be invalid operands of the same PHI 
> node.  Ala:
>
> input:
>
>regA =  /1
>use1(regA)  /2
>regA += ... /3
>use2(regA)  /4
>
> let's try creating different instances of regA (from point 2 and 4) that 
> overlap, e.g. by swapping insns 2 and 3.  We _have_ to rename regA from 
> insn 3 into a new pseudo, otherwise the uses of 2 and 4 can't be 
> differentiated anymore, so:
>
>regA  =  /1
>regA' = regA
>regA' += /3'
>use1(regA)   /2
>use2(regA')  /4'
>
> So if Richards model constrains the pseudo PHI nodes such that regA and 
> regA' can't be operands of one, that might solve the issue, as both the 
> lost copy and the swap problem need overlaps of different values to occur.
Right.  I was thinking about cases where something like CSE on this form
transforms the RHS of some operation into an instance of a pseudo.  That
insn is now a copy and we propagate the RHS into the uses of the LHS. 
That extends the lifetime of the pseudo's instance.  The question is
whether or not those actions either create a lost copy/swap problem or
not within the on-the-side SSA representation and whether or not there
could be implications if that happens.

>
>> The fact that passes don't directly manipulate the PHIs definitely helps
>> as well.  But I've still got some reading to do in this space to refresh
>> my memory of the issues.
> AFAIU Richards approach is more comparable to factored def-use chains than 
> to real SSA, which might indeed have no issues, though I then think the 
> problem moves into keeping _those_ consistent with the real instruction 
> stream as it changes.
To some degree, the change in model moves where we have to tackle these
issues.  Instead of tackling them in the out-of-ssa phase, we instead
have to think more about them in the analysis/optimization phases.  We
already do that to some degree in the gimple SSA representation (for
things like SSA_NAMEs associated with abnormal edges).

jeff

Re: [PATCH] diagnostics: ignore -fmax-errors for ICE

[Jeff Law via Gcc-patches]

On 12/1/20 9:35 AM, Martin Liška wrote:
> Right now I see:
>
> ./xgcc -B. ~/Programming/testcases/json.i -c -O2 -fmax-errors=1
> /home/marxin/Programming/testcases/json.i: In function
> ‘json_variant_type’:
> /home/marxin/Programming/testcases/json.i:22:1: error: non-integral
> type switch statement
>    22 | }
>   | ^
> int *
> switch (v_2(D))  [INV], case 0B:  [INV], case 5B:
>  [INV], case 6B:  [INV], case 7B:  [INV], case 8B:
>  [INV]>
> compilation terminated due to -fmax-errors=1.
>
> with the patch I get:
>
> ./xgcc -B. ~/Programming/testcases/json.i -c -O2 -fmax-errors=1 -c
> /home/marxin/Programming/testcases/json.i: In function
> ‘json_variant_type’:
> /home/marxin/Programming/testcases/json.i:22:1: error: non-integral
> type switch statement
>    22 | }
>   | ^
> int *
> switch (v_2(D))  [INV], case 0B:  [INV], case 5B:
>  [INV], case 6B:  [INV], case 7B:  [INV], case 8B:
>  [INV]>
> during GIMPLE pass: iftoswitch
> /home/marxin/Programming/testcases/json.i:22:1: internal compiler
> error: verify_gimple failed
> 0xe4478c verify_gimple_in_cfg(function*, bool)
> /home/marxin/Programming/gcc/gcc/tree-cfg.c:5467
> 0xd201cf execute_function_todo
> /home/marxin/Programming/gcc/gcc/passes.c:2042
> 0xd2101c do_per_function
> /home/marxin/Programming/gcc/gcc/passes.c:1687
> 0xd2101c execute_todo
> /home/marxin/Programming/gcc/gcc/passes.c:2096
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See  for instructions.
>
> gcc/ChangeLog:
>
> * diagnostic.c (diagnostic_report_diagnostic): ICE causes to
> terminate compiler immediately, so I guess it should be printed
> always.
OK
jeff

Re: [PATCH] [Refactor] [AVX512] Combine VI12_AVX512VL with VI48_AVX512VL into VI_AVX512VLBW

[Jeff Law via Gcc-patches]

On 11/30/20 10:17 PM, Hongtao Liu via Gcc-patches wrote:
> Hi:
> There're many pairs of define_insn/define_expand that are very similar
> to each other except mode iterator and condition. For these patterns
> VI12_AVX512VL are used under condition TARGET_AVX512BW, and
> VI48_AVX512VL are used under condition TARGET_AVX512F.
>
> This patch is about to introduce a new iterator VI_AVX512VLBW to
> combine a pair of those patterns into one.
>
> There are no functional changes, just code refactoring.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> gcc/ChangeLog
>
> * config/i386/sse.md (VI_AVX512VLBW): New mode iterator.
> (_ucmp3): Combine
> two patterns with mode iterator VI12_AVX512VL and VI48_AVX512VL
> into one pattern with mode iterator VI_AVX512VLBW.
> (vec_cmpu): Ditto.
> (_cvt2mask): Ditto.
> (_cvtmask2): Ditto.
> (*_cvtmask2): Ditto.
> (3_mask): Ditto.
> (*3_mask): Ditto.
> (_eq3): Ditto.
> (_eq3_1): Ditto.
> (_gt3): Ditto.
> (_andnot3_mask): Ditto.
> (abs2_mask): Ditto.
> (*_3): Combine from ...
> (*avx512f_3)
> and (3).
I'd suggest deferring to gcc-12 unless there is a strong need for this
cleanup to make fixing a bug easier.

jeff