[PATCH] nvptx: Fix and use BI mode logic instructions (e.g. and.pred).

2022-01-16 Thread Roger Sayle 

This patch adds support for nvptx's BImode and.pred, or.pred and
xor.pred instructions.  Technically, nvptx.md previously defined
andbi3, iorbi3 and xorbi3 instructions, but the assembly language
mnemonic output for these was incorrect (e.g. and.b1) and would be
rejected by the ptxas assembler.  The most significant part of this
patch is the new define_split which teaches the compiler to actually
use these instructions when appropriate (exposing the latent bug above).

After https://gcc.gnu.org/pipermail/gcc-patches/2022-January/587999.html
(still awaiting review/approval), the function:

int foo(int x, int y) { return (x==21) && (y==69); }

when compiled with -O2 produces:

mov.u32 %r26, %ar0;
mov.u32 %r27, %ar1;
setp.eq.u32 %r31, %r26, 21;
setp.eq.u32 %r34, %r27, 69;
selp.u32%r37, 1, 0, %r31;
selp.u32%r38, 1, 0, %r34;
and.b32 %value, %r37, %r38;

with this patch we now save an extra instruction and generate:

mov.u32 %r26, %ar0;
mov.u32 %r27, %ar1;
setp.eq.u32 %r31, %r26, 21;
setp.eq.u32 %r34, %r27, 69;
and.pred%r39, %r34, %r31;
selp.u32%value, 1, 0, %r39;

This patch has been tested (on top of the patch mentioned above) on
nvptx-none hosted on x86_64-pc-linux-gnu (including newlib) with a
make and make -k check with no new failures.  Ok for mainline?


2022-01-16  Roger Sayle  

gcc/ChangeLog
* config/nvptx/nvptx.md (any_logic): Move code iterator earlier
in machine description.
(logic): Move code attribute earlier in machine description.
(ilogic): New code attribute, like logic but "ior" for IOR.
(and3, ior3, xor3): Delete. Replace with...
(3): New define_insn for HSDIM logic operations.
(bi3): New define_insn for BI mode logic operations.
(define_split): Lower logic operations from integer modes to
BI mode predicate operations.

gcc/testsuite/ChangeLog
* gcc.target/nvptx/bool-2.c: New test case for and.pred.
* gcc.target/nvptx/bool-3.c: New test case for or.pred.
* gcc.target/nvptx/bool-4.c: New test case for xor.pred.


Many thanks in advance.

Roger
--

diff --git a/gcc/config/nvptx/nvptx.md b/gcc/config/nvptx/nvptx.md
index ce74672..0349c32 100644
--- a/gcc/config/nvptx/nvptx.md
+++ b/gcc/config/nvptx/nvptx.md
@@ -740,26 +740,38 @@
 
 ;; Logical operations
 
-(define_insn "and3"
-  [(set (match_operand:BHSDIM 0 "nvptx_register_operand" "=R")
-   (and:BHSDIM (match_operand:BHSDIM 1 "nvptx_register_operand" "R")
-   (match_operand:BHSDIM 2 "nvptx_nonmemory_operand" "Ri")))]
-  ""
-  "%.\\tand.b%T0\\t%0, %1, %2;")
+(define_code_iterator any_logic [and ior xor])
+(define_code_attr logic [(and "and") (ior "or") (xor "xor")])
+(define_code_attr ilogic [(and "and") (ior "ior") (xor "xor")])
 
-(define_insn "ior3"
-  [(set (match_operand:BHSDIM 0 "nvptx_register_operand" "=R")
-   (ior:BHSDIM (match_operand:BHSDIM 1 "nvptx_register_operand" "R")
-   (match_operand:BHSDIM 2 "nvptx_nonmemory_operand" "Ri")))]
+(define_insn "3"
+  [(set (match_operand:HSDIM 0 "nvptx_register_operand" "=R")
+   (any_logic:HSDIM
+ (match_operand:HSDIM 1 "nvptx_register_operand" "R")
+ (match_operand:HSDIM 2 "nvptx_nonmemory_operand" "Ri")))]
   ""
-  "%.\\tor.b%T0\\t%0, %1, %2;")
+  "%.\\t.b%T0\\t%0, %1, %2;")
 
-(define_insn "xor3"
-  [(set (match_operand:BHSDIM 0 "nvptx_register_operand" "=R")
-   (xor:BHSDIM (match_operand:BHSDIM 1 "nvptx_register_operand" "R")
-   (match_operand:BHSDIM 2 "nvptx_nonmemory_operand" "Ri")))]
+(define_insn "bi3"
+  [(set (match_operand:BI 0 "nvptx_register_operand" "=R")
+   (any_logic:BI (match_operand:BI 1 "nvptx_register_operand" "R")
+ (match_operand:BI 2 "nvptx_register_operand" "R")))]
   ""
-  "%.\\txor.b%T0\\t%0, %1, %2;")
+  "%.\\t.pred\\t%0, %1, %2;")
+
+(define_split
+  [(set (match_operand:HSDIM 0 "nvptx_register_operand")
+   (any_logic:HSDIM
+ (ne:HSDIM (match_operand:BI 1 "nvptx_register_operand")
+   (const_int 0))
+ (ne:HSDIM (match_operand:BI 2 "nvptx_register_operand")
+   (const_int 0]
+  "can_create_pseudo_p ()"
+  [(set (match_dup 3) (any_logic:BI (match_dup 1) (match_dup 2)))
+   (set (match_dup 0) (ne:HSDIM (match_dup 3) (const_int 0)))]
+{
+  operands[3] = gen_reg_rtx (BImode);
+})
 
 ;; Comparisons and branches
 
@@ -1845,9 +1857,6 @@
   }
   [(set_attr "atomic" "true")])
 
-(define_code_iterator any_logic [and ior xor])
-(define_code_attr logic [(and "and") (ior "or") (xor "xor")])
-
 (define_insn "atomic_fetch_"
   [(set (match_operand:SDIM 1 "memory_operand" "+m")
(unspec_volatile:SDIM
diff --git a/gcc/testsuite/gcc.target/nvptx/bool-2.c 
b/gcc/testsuite/

Re: [PATCH] Fortran: make IEEE_VALUE produce signaling NaNs

2022-01-16 Thread Mikael Morin 

Hello,

Le 10/01/2022 à 18:32, FX via Fortran a écrit :

Hi,

Second part of a three-patch series to fix PR 82207 
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82207), making gfortran handle 
signaling NaNs. This part fixes the library code implementing IEEE_VALUE. To do 
so, I switched that part of library code from Fortran to C, because in C we 
have access to all GCC built-ins related to NaNs/infinities/etc, which is super 
useful for generating the right bit patterns (instead of using roundabout ways, 
like the previous Fortran implementation, for which I am guilty).

I needed to add to kinds.h the value of TINY for each floating-point (which is 
used to produce denormals, by halving TINY).

The patch comes with a testcase, which is still conditional on issignaling 
support at this stage (and therefore will run on glibc targets only).

I had to amend the gfortran.dg/ieee/ieee_10.f90 testcase, which produces 
signaling NaNs while -ffpe-trap=invalid is set. It passed before, but only by 
accident, because we were not actually generating signaling NaNs. I’m not sure 
what is the expected behaviour, but the patch does not affect the real 
behaviour.

Bootstrapped and regtested on x86_64-pc-gnu-linux. OK to commit?


This looks good to me. Thanks.

amdgcn: Tune default OpenMP/OpenACC GPU utilization

2022-01-16 Thread Thomas Schwinge 
Hi!

On 2020-07-15T21:49:11+0100, Andrew Stubbs  wrote:
> This patch tunes the default GPU thread count for OpenMP and OpenACC on
> AMD GCN devices. It chooses a sensible default if no attributes are
> given at all, increases the number of OpenACC gangs if only one worker
> per gang is specified, and increases the number of workers otherwise.
> The tuning is still a work in progress as we fix issues that limit
> occupancy.

Pushed to in commit a78b1ab1df9ca44acc5638e8f9d0ae2e62bd65ed
"amdgcn: Tune default OpenMP/OpenACC GPU utilization", see attached.


Tobias, this should've unblocked your
"[wwwdocs] gcc-12/changes.html (GCN): >1 workers per gang"; see
.


Grüße
 Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From a78b1ab1df9ca44acc5638e8f9d0ae2e62bd65ed Mon Sep 17 00:00:00 2001
From: Kwok Cheung Yeung 
Date: Thu, 29 Aug 2019 10:16:42 -0700
Subject: [PATCH] amdgcn: Tune default OpenMP/OpenACC GPU utilization

	libgomp/
	* plugin/plugin-gcn.c (parse_target_attributes): Automatically set
	the number of teams and threads if necessary.
	(gcn_exec): Automatically set the number of gangs and workers if
	necessary.

Co-Authored-By: Andrew Stubbs  
---
 libgomp/plugin/plugin-gcn.c | 82 ++---
 1 file changed, 67 insertions(+), 15 deletions(-)

diff --git a/libgomp/plugin/plugin-gcn.c b/libgomp/plugin/plugin-gcn.c
index d0f05b28bf3..f305d726874 100644
--- a/libgomp/plugin/plugin-gcn.c
+++ b/libgomp/plugin/plugin-gcn.c
@@ -1219,24 +1219,55 @@ parse_target_attributes (void **input,
 
   if (gcn_dims_found)
 {
+  bool gfx900_workaround_p = false;
+
   if (agent->device_isa == EF_AMDGPU_MACH_AMDGCN_GFX900
 	  && gcn_threads == 0 && override_z_dim == 0)
 	{
-	  gcn_threads = 4;
+	  gfx900_workaround_p = true;
 	  GCN_WARNING ("VEGA BUG WORKAROUND: reducing default number of "
-		   "threads to 4 per team.\n");
+		   "threads to at most 4 per team.\n");
 	  GCN_WARNING (" - If this is not a Vega 10 device, please use "
 		   "GCN_NUM_THREADS=16\n");
 	}
 
+  /* Ideally, when a dimension isn't explicitly specified, we should
+	 tune it to run 40 (or 32?) threads per CU with no threads getting queued.
+	 In practice, we tune for peak performance on BabelStream, which
+	 for OpenACC is currently 32 threads per CU.  */
   def->ndim = 3;
-  /* Fiji has 64 CUs, but Vega20 has 60.  */
-  def->gdims[0] = (gcn_teams > 0) ? gcn_teams : get_cu_count (agent);
-  /* Each thread is 64 work items wide.  */
-  def->gdims[1] = 64;
-  /* A work group can have 16 wavefronts.  */
-  def->gdims[2] = (gcn_threads > 0) ? gcn_threads : 16;
-  def->wdims[0] = 1; /* Single team per work-group.  */
+  if (gcn_teams <= 0 && gcn_threads <= 0)
+	{
+	  /* Set up a reasonable number of teams and threads.  */
+	  gcn_threads = gfx900_workaround_p ? 4 : 16; // 8;
+	  def->gdims[0] = get_cu_count (agent); // * (40 / gcn_threads);
+	  def->gdims[2] = gcn_threads;
+	}
+  else if (gcn_teams <= 0 && gcn_threads > 0)
+	{
+	  /* Auto-scale the number of teams with the number of threads.  */
+	  def->gdims[0] = get_cu_count (agent); // * (40 / gcn_threads);
+	  def->gdims[2] = gcn_threads;
+	}
+  else if (gcn_teams > 0 && gcn_threads <= 0)
+	{
+	  int max_threads = gfx900_workaround_p ? 4 : 16;
+
+	  /* Auto-scale the number of threads with the number of teams.  */
+	  def->gdims[0] = gcn_teams;
+	  def->gdims[2] = 16; // get_cu_count (agent) * 40 / gcn_teams;
+	  if (def->gdims[2] == 0)
+	def->gdims[2] = 1;
+	  else if (def->gdims[2] > max_threads)
+	def->gdims[2] = max_threads;
+	}
+  else
+	{
+	  def->gdims[0] = gcn_teams;
+	  def->gdims[2] = gcn_threads;
+	}
+  def->gdims[1] = 64; /* Each thread is 64 work items wide.  */
+  def->wdims[0] = 1;  /* Single team per work-group.  */
   def->wdims[1] = 64;
   def->wdims[2] = 16;
   *result = def;
@@ -3031,13 +3062,34 @@ gcn_exec (struct kernel_info *kernel, size_t mapnum, void **hostaddrs,
   if (hsa_kernel_desc->oacc_dims[2] > 0)
 dims[2] = hsa_kernel_desc->oacc_dims[2];
 
-  /* If any of the OpenACC dimensions remain 0 then we get to pick a number.
- There isn't really a correct answer for this without a clue about the
- problem size, so let's do a reasonable number of single-worker gangs.
- 64 gangs matches a typical Fiji device.  */
+  /* Ideally, when a dimension isn't explicitly specified, we should
+ tune it to run 40 (or 32?) threads per CU with no threads getting queued.
+ In practice, we tune for peak performance on BabelStream, which
+ for OpenACC is currently 32 threads per CU.  */
+  if (dims[0] == 0 && dims[1] == 0)
+{
+  /* If any of the O

[PATCH 1/6 v2] libstdc++: Directly implement hexfloat std::from_chars for binary32/64

2022-01-16 Thread Patrick Palka via Gcc-patches 
Series tested on x86_64, i686, ppc64, ppc64le, aarch64, does it look OK for
trunk?

libstdc++-v3/ChangeLog:

* src/c++17/floating_from_chars.cc: Include .
(ascii_to_hexit, starts_with_ci): Define.
(__floating_from_chars_hex): Define.
(from_chars): Conditionally call __floating_from_chars_hex.
(testsuite/20_util/from_chars/7.cc): New test.
---
 libstdc++-v3/src/c++17/floating_from_chars.cc | 376 ++
 .../testsuite/20_util/from_chars/7.cc | 151 +++
 2 files changed, 527 insertions(+)
 create mode 100644 libstdc++-v3/testsuite/20_util/from_chars/7.cc

diff --git a/libstdc++-v3/src/c++17/floating_from_chars.cc 
b/libstdc++-v3/src/c++17/floating_from_chars.cc
index 479e042bb5f..b186da9a955 100644
--- a/libstdc++-v3/src/c++17/floating_from_chars.cc
+++ b/libstdc++-v3/src/c++17/floating_from_chars.cc
@@ -31,6 +31,7 @@
 #define _GLIBCXX_USE_CXX11_ABI 1
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -396,6 +397,371 @@ namespace
   }
 #endif
 
+#if _GLIBCXX_FLOAT_IS_IEEE_BINARY32 && _GLIBCXX_DOUBLE_IS_IEEE_BINARY64
+  // If the given ASCII character represents a hexit, return that hexit.
+  // Otherwise return -1.
+  int
+  ascii_to_hexit(char ch)
+  {
+if (ch >= '0' && ch <= '9')
+  return ch - '0';
+if (ch >= 'a' && ch <= 'f')
+  return ch - 'a' + 10;
+if (ch >= 'A' && ch <= 'F')
+  return ch - 'A' + 10;
+return -1;
+  }
+
+  // Return true iff [FIRST,LAST) begins with PREFIX, ignoring case.
+  bool
+  starts_with_ci(const char* first, const char* last, string_view prefix)
+  {
+__glibcxx_requires_valid_range(first, last);
+
+for (char ch : prefix)
+  {
+   __glibcxx_assert(ch >= 'a' && ch <= 'z');
+   if (first == last || (*first != ch && *first != ch - 32))
+ return false;
+   ++first;
+  }
+
+return true;
+  }
+
+  // An implementation of hexadecimal float parsing for binary32/64.
+  template
+  from_chars_result
+  __floating_from_chars_hex(const char* first, const char* last, T& value)
+  {
+static_assert(is_same_v || is_same_v);
+
+using uint_t = conditional_t, uint32_t, uint64_t>;
+constexpr int mantissa_width = is_same_v ? 23 : 52;
+constexpr int exponent_width = is_same_v ? 8 : 11;
+constexpr int exponent_bias = (1 << (exponent_width - 1)) - 1;
+
+__glibcxx_requires_valid_range(first, last);
+if (first == last)
+  return {first, errc::invalid_argument};
+
+// Consume the sign bit.
+const char* const orig_first = first;
+bool sign_bit = false;
+if (*first == '-')
+  {
+   sign_bit = true;
+   ++first;
+  }
+
+// Handle "inf", "infinity", "NaN" and variants thereof.
+if (first != last)
+  if (*first == 'i' || *first == 'I' || *first == 'n' || *first == 'N') 
[[unlikely]]
+   {
+ if (starts_with_ci(first, last, "inf"sv))
+   {
+ first += 3;
+ if (starts_with_ci(first, last, "inity"sv))
+   first += 5;
+
+ uint_t result = 0;
+ result |= sign_bit;
+ result <<= exponent_width;
+ result |= (1ull << exponent_width) - 1;
+ result <<= mantissa_width;
+ memcpy(&value, &result, sizeof(result));
+
+ return {first, errc{}};
+   }
+ else if (starts_with_ci(first, last, "nan"))
+   {
+ first += 3;
+
+ if (first != last && *first == '(')
+   {
+ // Tentatively consume the '(' as we look for an optional
+ // n-char-sequence followed by a ')'.
+ const char* const fallback_first = first;
+ for (;;)
+   {
+ ++first;
+ if (first == last)
+   {
+ first = fallback_first;
+ break;
+   }
+
+ char ch = *first;
+ if (ch == ')')
+   {
+ ++first;
+ break;
+   }
+ else if ((ch >= '0' && ch <= '9')
+  || (ch >= 'a' && ch <= 'z')
+  || (ch >= 'A' && ch <= 'Z')
+  || ch == '_')
+   continue;
+ else
+   {
+ first = fallback_first;
+ break;
+   }
+   }
+   }
+
+ // We make the implementation-defined decision of ignoring the
+ // sign bit and the n-char-sequence when assembling the NaN.
+ uint_t result = 0;
+ result <<= exponent_width;
+ result |= (1ull << exponent_width) - 1;
+ result <<= mantissa_width;
+ result |= (1ull << (mantissa_width - 1)) | 1;
+

[PATCH 3/6] libstdc++: Apply modifications to our local copy of fast_float

2022-01-16 Thread Patrick Palka via Gcc-patches 
This performs the following modifications to our local copy of fast_float
in order to make it more readily usable in our std::from_chars
implementation:

  * Remove system #includes
  * Replace stray call to assert
  * Use the standard chars_format and from_chars_result types

libstdc++-v3/ChangeLog:

* src/c++17/fast_float/LOCAL_PATCHES: Update.
* src/c++17/fast_float/fast_float.h: Apply local modifications.
---
 .../src/c++17/fast_float/LOCAL_PATCHES|  1 +
 .../src/c++17/fast_float/fast_float.h | 62 ++-
 2 files changed, 7 insertions(+), 56 deletions(-)

diff --git a/libstdc++-v3/src/c++17/fast_float/LOCAL_PATCHES 
b/libstdc++-v3/src/c++17/fast_float/LOCAL_PATCHES
index e69de29bb2d..e9d7bba6195 100644
--- a/libstdc++-v3/src/c++17/fast_float/LOCAL_PATCHES
+++ b/libstdc++-v3/src/c++17/fast_float/LOCAL_PATCHES
@@ -0,0 +1 @@
+r12-
diff --git a/libstdc++-v3/src/c++17/fast_float/fast_float.h 
b/libstdc++-v3/src/c++17/fast_float/fast_float.h
index 8a45ebca8a8..c908719ec3a 100644
--- a/libstdc++-v3/src/c++17/fast_float/fast_float.h
+++ b/libstdc++-v3/src/c++17/fast_float/fast_float.h
@@ -42,21 +42,10 @@
 #ifndef FASTFLOAT_FAST_FLOAT_H
 #define FASTFLOAT_FAST_FLOAT_H
 
-#include 
-
 namespace fast_float {
-enum chars_format {
-scientific = 1<<0,
-fixed = 1<<2,
-hex = 1<<3,
-general = fixed | scientific
-};
 
-
-struct from_chars_result {
-  const char *ptr;
-  std::errc ec;
-};
+using std::chars_format;
+using std::from_chars_result;
 
 struct parse_options {
   constexpr explicit parse_options(chars_format fmt = chars_format::general,
@@ -105,11 +94,6 @@ from_chars_result from_chars_advanced(const char *first, 
const char *last,
 #ifndef FASTFLOAT_FLOAT_COMMON_H
 #define FASTFLOAT_FLOAT_COMMON_H
 
-#include 
-#include 
-#include 
-#include 
-
 #if (defined(__x86_64) || defined(__x86_64__) || defined(_M_X64)   \
|| defined(__amd64) || defined(__aarch64__) || defined(_M_ARM64) \
|| defined(__MINGW64__)  \
@@ -233,7 +217,7 @@ struct value128 {
 
 /* result might be undefined when input_num is zero */
 fastfloat_really_inline int leading_zeroes(uint64_t input_num) {
-  assert(input_num > 0);
+  FASTFLOAT_DEBUG_ASSERT(input_num > 0);
 #ifdef FASTFLOAT_VISUAL_STUDIO
   #if defined(_M_X64) || defined(_M_ARM64)
   unsigned long leading_zero = 0;
@@ -468,11 +452,6 @@ fastfloat_really_inline void to_float(bool negative, 
adjusted_mantissa am, T &va
 #ifndef FASTFLOAT_ASCII_NUMBER_H
 #define FASTFLOAT_ASCII_NUMBER_H
 
-#include 
-#include 
-#include 
-#include 
-
 
 namespace fast_float {
 
@@ -610,7 +589,7 @@ parsed_number_string parse_number_string(const char *p, 
const char *pend, parse_
 return answer;
   }
   int64_t exp_number = 0;// explicit exponential part
-  if ((fmt & chars_format::scientific) && (p != pend) && (('e' == *p) || ('E' 
== *p))) {
+  if (bool(fmt & chars_format::scientific) && (p != pend) && (('e' == *p) || 
('E' == *p))) {
 const char * location_of_e = p;
 ++p;
 bool neg_exp = false;
@@ -621,7 +600,7 @@ parsed_number_string parse_number_string(const char *p, 
const char *pend, parse_
   ++p;
 }
 if ((p == pend) || !is_integer(*p)) {
-  if(!(fmt & chars_format::fixed)) {
+  if(!bool(fmt & chars_format::fixed)) {
 // We are in error.
 return answer;
   }
@@ -640,7 +619,7 @@ parsed_number_string parse_number_string(const char *p, 
const char *pend, parse_
 }
   } else {
 // If it scientific and not fixed, we have to bail out.
-if((fmt & chars_format::scientific) && !(fmt & chars_format::fixed)) { 
return answer; }
+if(bool(fmt & chars_format::scientific) && !bool(fmt & 
chars_format::fixed)) { return answer; }
   }
   answer.lastmatch = p;
   answer.valid = true;
@@ -699,8 +678,6 @@ parsed_number_string parse_number_string(const char *p, 
const char *pend, parse_
 #ifndef FASTFLOAT_FAST_TABLE_H
 #define FASTFLOAT_FAST_TABLE_H
 
-#include 
-
 namespace fast_float {
 
 /**
@@ -1399,13 +1376,6 @@ using powers = powers_template<>;
 #ifndef FASTFLOAT_DECIMAL_TO_BINARY_H
 #define FASTFLOAT_DECIMAL_TO_BINARY_H
 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
 namespace fast_float {
 
 // This will compute or rather approximate w * 5**q and return a pair of 
64-bit words approximating
@@ -1592,11 +1562,6 @@ adjusted_mantissa compute_float(int64_t q, uint64_t w)  
noexcept  {
 #ifndef FASTFLOAT_BIGINT_H
 #define FASTFLOAT_BIGINT_H
 
-#include 
-#include 
-#include 
-#include 
-
 
 namespace fast_float {
 
@@ -2182,11 +2147,6 @@ struct bigint {
 #ifndef FASTFLOAT_ASCII_NUMBER_H
 #define FASTFLOAT_ASCII_NUMBER_H
 
-#include 
-#include 
-#include 
-#include 
-
 
 namespace fast_float {
 
@@ -2413,11 +2373,6 @@ parsed_number_string parse_number_string(const char *p, 
const char *pend, parse_
 #ifndef FASTFLOAT_DIGIT_COMPARISON_H
 #define FASTFLOAT_DIGIT_COMPARISON_H
 
-#include 
-#include

[PATCH 5/6] libstdc++: Use fast_float in std::from_chars for binary32/64

2022-01-16 Thread Patrick Palka via Gcc-patches 
This makes our std::from_chars implementation use fast_float for parsing
chars_format::scientific/fixed/general parsing into binary32/64 values.
For other floating-point formats we still use the fallback implementation
that goes through the strtod family of functions.

libstdc++-v3/ChangeLog:

* src/c++17/floating_from_chars.cc: (USE_LIB_FAST_FLOAT):
Conditionally define, and use it to conditionally include
fast_float.
(from_chars): Use fast_float for float and double when
USE_LIB_FAST_FLOAT.
---
 libstdc++-v3/src/c++17/floating_from_chars.cc | 31 ---
 1 file changed, 27 insertions(+), 4 deletions(-)

diff --git a/libstdc++-v3/src/c++17/floating_from_chars.cc 
b/libstdc++-v3/src/c++17/floating_from_chars.cc
index b186da9a955..c340eb18ea8 100644
--- a/libstdc++-v3/src/c++17/floating_from_chars.cc
+++ b/libstdc++-v3/src/c++17/floating_from_chars.cc
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -53,6 +54,18 @@
 extern "C" __ieee128 __strtoieee128(const char*, char**);
 #endif
 
+#if _GLIBCXX_FLOAT_IS_IEEE_BINARY32 && _GLIBCXX_DOUBLE_IS_IEEE_BINARY64
+# define USE_LIB_FAST_FLOAT 1
+#endif
+
+#if USE_LIB_FAST_FLOAT
+# define FASTFLOAT_DEBUG_ASSERT __glibcxx_assert
+namespace
+{
+# include "fast_float/fast_float.h"
+} // anon namespace
+#endif
+
 #if _GLIBCXX_HAVE_USELOCALE
 namespace std _GLIBCXX_VISIBILITY(default)
 {
@@ -775,8 +788,12 @@ from_chars(const char* first, const char* last, float& 
value,
 #if _GLIBCXX_FLOAT_IS_IEEE_BINARY32 && _GLIBCXX_DOUBLE_IS_IEEE_BINARY64
   if (fmt == chars_format::hex)
 return __floating_from_chars_hex(first, last, value);
-#endif
-
+  else
+{
+  static_assert(USE_LIB_FAST_FLOAT);
+  return fast_float::from_chars(first, last, value, fmt);
+}
+#else
   errc ec = errc::invalid_argument;
 #if _GLIBCXX_USE_CXX11_ABI
   buffer_resource mr;
@@ -797,6 +814,7 @@ from_chars(const char* first, const char* last, float& 
value,
   fmt = chars_format{};
 }
   return make_result(first, len, fmt, ec);
+#endif
 }
 
 from_chars_result
@@ -806,8 +824,12 @@ from_chars(const char* first, const char* last, double& 
value,
 #if _GLIBCXX_FLOAT_IS_IEEE_BINARY32 && _GLIBCXX_DOUBLE_IS_IEEE_BINARY64
   if (fmt == chars_format::hex)
 return __floating_from_chars_hex(first, last, value);
-#endif
-
+  else
+{
+  static_assert(USE_LIB_FAST_FLOAT);
+  return fast_float::from_chars(first, last, value, fmt);
+}
+#else
   errc ec = errc::invalid_argument;
 #if _GLIBCXX_USE_CXX11_ABI
   buffer_resource mr;
@@ -828,6 +850,7 @@ from_chars(const char* first, const char* last, double& 
value,
   fmt = chars_format{};
 }
   return make_result(first, len, fmt, ec);
+#endif
 }
 
 from_chars_result
-- 
2.35.0.rc1

[PATCH 4/6] libstdc++: Adjust fast_float's over/underflow behavior for conformnace

2022-01-16 Thread Patrick Palka via Gcc-patches 
This makes fast_float handle the situation where std::from_chars is
specified to return result_out_of_range, i.e. when the parsed value
is outside the representable range of the floating-point type.

This adjusts fast_float's behavior in case of over/underflow: instead of
returning errc{} and setting value to +-0 or +-infinity, return
result_out_of_range and don't modify value, as per [charconv.from.chars]/1.

libstdc++-v3/ChangeLog:

* src/c++17/fast_float/LOCAL_PATCHES: Update.
* src/c++17/fast_float/fast_float.h (from_chars_advanced): In
case of over/underflow, return errc::result_out_of_range and don't
modify 'value'.
---
 libstdc++-v3/src/c++17/fast_float/LOCAL_PATCHES | 1 +
 libstdc++-v3/src/c++17/fast_float/fast_float.h  | 9 +
 2 files changed, 10 insertions(+)

diff --git a/libstdc++-v3/src/c++17/fast_float/LOCAL_PATCHES 
b/libstdc++-v3/src/c++17/fast_float/LOCAL_PATCHES
index e9d7bba6195..1f90f9d1d85 100644
--- a/libstdc++-v3/src/c++17/fast_float/LOCAL_PATCHES
+++ b/libstdc++-v3/src/c++17/fast_float/LOCAL_PATCHES
@@ -1 +1,2 @@
 r12-
+r12-
diff --git a/libstdc++-v3/src/c++17/fast_float/fast_float.h 
b/libstdc++-v3/src/c++17/fast_float/fast_float.h
index c908719ec3a..97d28940944 100644
--- a/libstdc++-v3/src/c++17/fast_float/fast_float.h
+++ b/libstdc++-v3/src/c++17/fast_float/fast_float.h
@@ -2884,6 +2884,15 @@ from_chars_result from_chars_advanced(const char *first, 
const char *last,
   // If we called compute_float>(pns.exponent, pns.mantissa) 
and we have an invalid power (am.power2 < 0),
   // then we need to go the long way around again. This is very uncommon.
   if(am.power2 < 0) { am = digit_comp(pns, am); }
+
+  if((pns.mantissa != 0 && am.mantissa == 0 && am.power2 == 0) || am.power2 == 
binary_format::infinite_power()) {
+// In case of over/underflow, return result_out_of_range and don't modify 
value,
+// as per [charconv.from.chars]/1.  Note that LWG 3081 wants to modify 
value in
+// this case too.
+answer.ec = std::errc::result_out_of_range;
+return answer;
+  }
+
   to_float(pns.negative, am, value);
   return answer;
 }
-- 
2.35.0.rc1

[PATCH 2/6] libstdc++: Import the fast_float library

2022-01-16 Thread Patrick Palka via Gcc-patches 
We're going to use the fast_float library in our (compiled-in)
floating-point std::from_chars implementation for faster and more
portable parsing of binary32/64 decimal strings.

The single file fast_float.h is an amalgamation of the entire library,
which can be (re)generated with the command

  python3 ./script/amalgamate.py --license=MIT \
> $GCC_SRC/libstdc++-v3/c++17/fast_float/fast_float.h

[1]: https://github.com/fastfloat/fast_float

libstdc++-v3/ChangeLog:

* src/c++17/fast_float/LOCAL_PATCHES: New file.
* src/c++17/fast_float/MERGE: New file.
* src/c++17/fast_float/README.fd: New file, copied from the
fast_float library sources.
* src/c++17/fast_float/fast_float.h: New file, an amalgamation
of the fast_float library.

Signed-off-by: Patrick Palka 
---
 .../src/c++17/fast_float/LOCAL_PATCHES|0
 libstdc++-v3/src/c++17/fast_float/MERGE   |4 +
 libstdc++-v3/src/c++17/fast_float/README.md   |  218 ++
 .../src/c++17/fast_float/fast_float.h | 2944 +
 4 files changed, 3166 insertions(+)
 create mode 100644 libstdc++-v3/src/c++17/fast_float/LOCAL_PATCHES
 create mode 100644 libstdc++-v3/src/c++17/fast_float/MERGE
 create mode 100644 libstdc++-v3/src/c++17/fast_float/README.md
 create mode 100644 libstdc++-v3/src/c++17/fast_float/fast_float.h

diff --git a/libstdc++-v3/src/c++17/fast_float/LOCAL_PATCHES 
b/libstdc++-v3/src/c++17/fast_float/LOCAL_PATCHES
new file mode 100644
index 000..e69de29bb2d
diff --git a/libstdc++-v3/src/c++17/fast_float/MERGE 
b/libstdc++-v3/src/c++17/fast_float/MERGE
new file mode 100644
index 000..43bdc3981c8
--- /dev/null
+++ b/libstdc++-v3/src/c++17/fast_float/MERGE
@@ -0,0 +1,4 @@
+d35368cae610b4edeec61cd41e4d2367a4d33f58
+
+The first line of this file holds the git revision number of the
+last merge done from the master library sources.
diff --git a/libstdc++-v3/src/c++17/fast_float/README.md 
b/libstdc++-v3/src/c++17/fast_float/README.md
new file mode 100644
index 000..1e1c06d0a3e
--- /dev/null
+++ b/libstdc++-v3/src/c++17/fast_float/README.md
@@ -0,0 +1,218 @@
+## fast_float number parsing library: 4x faster than strtod
+
+![Ubuntu 20.04 CI (GCC 
9)](https://github.com/lemire/fast_float/workflows/Ubuntu%2020.04%20CI%20(GCC%209)/badge.svg)
+![Ubuntu 18.04 CI (GCC 
7)](https://github.com/lemire/fast_float/workflows/Ubuntu%2018.04%20CI%20(GCC%207)/badge.svg)
+![Alpine 
Linux](https://github.com/lemire/fast_float/workflows/Alpine%20Linux/badge.svg)
+![MSYS2-CI](https://github.com/lemire/fast_float/workflows/MSYS2-CI/badge.svg)
+![VS16-CLANG-CI](https://github.com/lemire/fast_float/workflows/VS16-CLANG-CI/badge.svg)
+[![VS16-CI](https://github.com/fastfloat/fast_float/actions/workflows/vs16-ci.yml/badge.svg)](https://github.com/fastfloat/fast_float/actions/workflows/vs16-ci.yml)
+
+The fast_float library provides fast header-only implementations for the C++ 
from_chars
+functions for `float` and `double` types.  These functions convert ASCII 
strings representing
+decimal values (e.g., `1.3e10`) into binary types. We provide exact rounding 
(including
+round to even). In our experience, these `fast_float` functions many times 
faster than comparable number-parsing functions from existing C++ standard 
libraries.
+
+Specifically, `fast_float` provides the following two functions with a 
C++17-like syntax (the library itself only requires C++11):
+
+```C++
+from_chars_result from_chars(const char* first, const char* last, float& 
value, ...);
+from_chars_result from_chars(const char* first, const char* last, double& 
value, ...);
+```
+
+The return type (`from_chars_result`) is defined as the struct:
+```C++
+struct from_chars_result {
+const char* ptr;
+std::errc ec;
+};
+```
+
+It parses the character sequence [first,last) for a number. It parses 
floating-point numbers expecting
+a locale-independent format equivalent to the C++17 from_chars function. 
+The resulting floating-point value is the closest floating-point values (using 
either float or double), 
+using the "round to even" convention for values that would otherwise fall 
right in-between two values.
+That is, we provide exact parsing according to the IEEE standard.
+
+
+Given a successful parse, the pointer (`ptr`) in the returned value is set to 
point right after the
+parsed number, and the `value` referenced is set to the parsed value. In case 
of error, the returned
+`ec` contains a representative error, otherwise the default (`std::errc()`) 
value is stored.
+
+The implementation does not throw and does not allocate memory (e.g., with 
`new` or `malloc`).
+
+It will parse infinity and nan values.
+
+Example:
+
+``` C++
+#include "fast_float/fast_float.h"
+#include 
+ 
+int main() {
+const std::string input =  "3.1416 xyz ";
+double result;
+auto answer = fast_float::from_chars(input.data(), 
input.data()+input.size(), result);
+if(answer.ec != std::errc()) { std::cerr << "p

[pushed] fortan testsuite: Enrich tests with variants failing on the branch.

2022-01-16 Thread Mikael Morin 

Hello,

I have just pushed the attached patch after testing the impacted tests 
individually.


MikaelFrom 15630e6e9eb019477d1fc5c0966b43979e18ae18 Mon Sep 17 00:00:00 2001
From: Mikael Morin 
Date: Sun, 16 Jan 2022 18:33:36 +0100
Subject: [PATCH] testsuite: Enrich tests with variants failing on the branch.

Backporting the fix for pr103789 on the 11 branch revealed a lack of test
coverage for the tests provided with that fix.  Indeed, the tests use the KIND
argument of the respective intrinsics only with keyword arguments.
This adds variants with non-keyword arguments.

The tests enriched this way fail on the branch if the fix is cherry-picked
straightforwardly.  The fix will have to be tweaked slightly there.

	PR fortran/103789
	PR fortran/87711
	PR fortran/97896

gcc/testsuite/ChangeLog:

	* gfortran.dg/index_5.f90: Enrich test with usages of INDEX with
	a non-keyword KIND argument.
	* gfortran.dg/len_trim.f90: Same for LEN_TRIM.
	* gfortran.dg/maskl_1.f90: Same for MASKL.
	* gfortran.dg/maskr_1.f90: Same for MASKR.
	* gfortran.dg/scan_3.f90: Same for SCAN.
	* gfortran.dg/verify_3.f90: Same for VERIFY.
---
 gcc/testsuite/gfortran.dg/index_5.f90  | 2 ++
 gcc/testsuite/gfortran.dg/len_trim.f90 | 6 ++
 gcc/testsuite/gfortran.dg/maskl_1.f90  | 3 ++-
 gcc/testsuite/gfortran.dg/maskr_1.f90  | 3 ++-
 gcc/testsuite/gfortran.dg/scan_3.f90   | 5 -
 gcc/testsuite/gfortran.dg/verify_3.f90 | 5 -
 6 files changed, 20 insertions(+), 4 deletions(-)

diff --git a/gcc/testsuite/gfortran.dg/index_5.f90 b/gcc/testsuite/gfortran.dg/index_5.f90
index e039455d175..4dc2ce4c0a1 100644
--- a/gcc/testsuite/gfortran.dg/index_5.f90
+++ b/gcc/testsuite/gfortran.dg/index_5.f90
@@ -19,5 +19,7 @@ program p
   d = index ('xyxyz','yx', back=a, kind=8)
   b = index ('xyxyz','yx', back=a, kind=8)
   d = index ('xyxyz','yx', back=a, kind=4)
+  b = index ('xyxyz','yx',  a,  4)
+  d = index ('xyxyz','yx',  a,  8)
 end
 
diff --git a/gcc/testsuite/gfortran.dg/len_trim.f90 b/gcc/testsuite/gfortran.dg/len_trim.f90
index 2252b81f084..77e3d30c669 100644
--- a/gcc/testsuite/gfortran.dg/len_trim.f90
+++ b/gcc/testsuite/gfortran.dg/len_trim.f90
@@ -17,11 +17,17 @@ program main
   kk = len_trim (a)
   mm = len_trim (a, kind=4)
   nn = len_trim (a, kind=8)
+  mm = len_trim (a,  4)
+  nn = len_trim (a,  8)
   kk = len_trim ([b])
   mm = len_trim ([b],kind=4)
   nn = len_trim ([b],kind=8)
+  mm = len_trim ([b], 4)
+  nn = len_trim ([b], 8)
   kk = len_trim (c)
   mm = len_trim (c, kind=4)
   nn = len_trim (c, kind=8)
+  mm = len_trim (c,  4)
+  nn = len_trim (c,  8)
   if (any (l4 /= 2_4) .or. any (l8 /= 2_8)) stop 1
 end program main
diff --git a/gcc/testsuite/gfortran.dg/maskl_1.f90 b/gcc/testsuite/gfortran.dg/maskl_1.f90
index 9e25c2c9cdc..56350e269da 100644
--- a/gcc/testsuite/gfortran.dg/maskl_1.f90
+++ b/gcc/testsuite/gfortran.dg/maskl_1.f90
@@ -4,7 +4,8 @@
 ! Check the absence of ICE when generating calls to MASKL with a KIND argument.
 
 program p
-   integer :: z(2), y(2)
+   integer :: z(2), y(2), x(2)
y = [1, 13]
z = maskl(y, kind=4) + 1
+   x = maskl(y,  4) + 1
 end program p
diff --git a/gcc/testsuite/gfortran.dg/maskr_1.f90 b/gcc/testsuite/gfortran.dg/maskr_1.f90
index ebfd3dbba33..f8ccdd11ab3 100644
--- a/gcc/testsuite/gfortran.dg/maskr_1.f90
+++ b/gcc/testsuite/gfortran.dg/maskr_1.f90
@@ -4,7 +4,8 @@
 ! Check the absence of ICE when generating calls to MASKR with a KIND argument.
 
 program p
-   integer :: z(2), y(2)
+   integer :: z(2), y(2), x(2)
y = [1, 13]
z = maskr(y, kind=4) + 1
+   x = maskr(y,  4) + 1
 end program p
diff --git a/gcc/testsuite/gfortran.dg/scan_3.f90 b/gcc/testsuite/gfortran.dg/scan_3.f90
index 80262ae2167..2a9ed080957 100644
--- a/gcc/testsuite/gfortran.dg/scan_3.f90
+++ b/gcc/testsuite/gfortran.dg/scan_3.f90
@@ -5,7 +5,10 @@
 
 program p
character(len=10) :: y(2)
-   integer :: z(2)
+   integer :: z(2), x(2), w(2), v(2)
y = ['abc', 'def']
z = scan(y, 'e', kind=4) + 1
+   x = scan(y, 'e', back=.false., kind=4) + 1
+   w = scan(y, 'e',  .false., kind=4) + 1
+   v = scan(y, 'e',  .false.,  4) + 1
 end program p
diff --git a/gcc/testsuite/gfortran.dg/verify_3.f90 b/gcc/testsuite/gfortran.dg/verify_3.f90
index f01e24e199e..c8b26b70614 100644
--- a/gcc/testsuite/gfortran.dg/verify_3.f90
+++ b/gcc/testsuite/gfortran.dg/verify_3.f90
@@ -5,7 +5,10 @@
 
 program p
character(len=10) :: y(2)
-   integer :: z(2)
+   integer :: z(2), x(2), w(2), v(2)
y = ['abc', 'def']
z = verify(y, 'e', kind=4) + 1
+   x = verify(y, 'e', back=.false., kind=4) + 1
+   w = verify(y, 'e',  .false., kind=4) + 1
+   x = verify(y, 'e',  .false.,  4) + 1
 end program p
-- 
2.34.1

Re: [PATCH] Strengthen memory memory order for atomic::wait/notify

2022-01-16 Thread Jonathan Wakely via Gcc-patches 
On Sun, 16 Jan 2022 at 01:48, Thomas Rodgers via Libstdc++ <
libstd...@gcc.gnu.org> wrote:

> This patch updates the memory order of atomic accesses to the waiter's
> count to match libc++'s usage. It should be backported to GCC11.
>

The commit subject line says "memory memory order", OK for trunk and gcc-11
with that fixed.


> Tested x86_64-pc-linux-gnu.
>

Re: [PATCH] libstdc++: Add attribute to features deprecated in C++17 [PR91260]

2022-01-16 Thread Jonathan Wakely via Gcc-patches 
On Fri, 14 Jan 2022 at 11:32, Jonathan Wakely  wrote:

>
>
> On Wed, 12 Jan 2022 at 09:34, Jonathan Wakely via Libstdc++ <
> libstd...@gcc.gnu.org> wrote:
>
>> This passes testing (with -std=gnu++98/11/17/20) but is quite a large
>> patch for this late in stage 3. Does anybody object to doing this now?
>> The bugs it fixes were closed as INVALID because we're not actually
>> *required* to remove these or deprecate them. But users are right to
>> complain about us silently accepting use of things like std::bind1st in
>> C++20 mode. Probably WONTFIX would have been better, and in fact we can
>> fix them (as this patch does). If we don't do this, users will keep
>> reporting bugs about it, but it could wait for stage 1 if needed.
>>
>
> Pushed to trunk.
>
>
And this fix for the g++ tests.

Tested powerpc64le-linux, pushed to trunk.
commit bca1c431affee41ecadb7f29d8d65142a73e0ebf
Author: Jonathan Wakely 
Date:   Fri Jan 14 22:08:16 2022

libstdc++: Ignore deprecated warnings [PR104037]

The std::pointer_to_binary_function utility was deprecated in C++11 and
removed in C++17. Libstdc++ has started to warn about using it, so
suppress the warnings for this test.

gcc/testsuite/ChangeLog:

PR testsuite/104037
* g++.old-deja/g++.robertl/eb43.C: Ad -Wno-deprecated.

diff --git a/gcc/testsuite/g++.old-deja/g++.robertl/eb43.C 
b/gcc/testsuite/g++.old-deja/g++.robertl/eb43.C
index 90afbe4f190..c54050c3c7a 100644
--- a/gcc/testsuite/g++.old-deja/g++.robertl/eb43.C
+++ b/gcc/testsuite/g++.old-deja/g++.robertl/eb43.C
@@ -5,6 +5,7 @@
 // to pointer_to_binary_function, which has an `explicit' constructor.
 
 // { dg-prune-output "note" }
+// { dg-options "-Wno-deprecated" }
 
 #include 
 #include

PING^3: [PATCH] Add --enable-first-stage-cross configure option

2022-01-16 Thread Serge Belyshev via Gcc-patches 
Final ping before stage3 ends:

[PATCH] Add --enable-first-stage-cross configure option
https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575318.html

[pushed 0/3][gcc11] fortran: Backpoprt KIND arg of intrinsics fix [PR103789]

2022-01-16 Thread Mikael Morin via Gcc-patches 
Hello,

I noticed a bug while backporting the fix for PR103789 on the 11 branch.
It makes the cherry-pick not exactly straightforward.
The bug is fixed in the first patch, the backport comes in the second, and
additional test coverage (pushed earlier today on master) is added in
the third.

Tested on x86_64-linux on the 11 branch, pushed.


Mikael Morin (3):
  Fortran: Fix KIND argument index for LEN_TRIM.
  Fortran: Ignore KIND argument of a few more intrinsics. [PR103789]
  testsuite: Enrich tests with variants failing on the branch.

 gcc/fortran/trans-array.c  | 45 --
 gcc/testsuite/gfortran.dg/index_5.f90  |  2 ++
 gcc/testsuite/gfortran.dg/len_trim.f90 |  6 
 gcc/testsuite/gfortran.dg/maskl_1.f90  | 11 +++
 gcc/testsuite/gfortran.dg/maskr_1.f90  | 11 +++
 gcc/testsuite/gfortran.dg/scan_3.f90   | 14 
 gcc/testsuite/gfortran.dg/verify_3.f90 | 14 
 7 files changed, 93 insertions(+), 10 deletions(-)
 create mode 100644 gcc/testsuite/gfortran.dg/maskl_1.f90
 create mode 100644 gcc/testsuite/gfortran.dg/maskr_1.f90
 create mode 100644 gcc/testsuite/gfortran.dg/scan_3.f90
 create mode 100644 gcc/testsuite/gfortran.dg/verify_3.f90

-- 
2.34.1

[pushed 1/3] Fortran: Fix KIND argument index for LEN_TRIM.

2022-01-16 Thread Mikael Morin via Gcc-patches 

The mainline code to check whether an argument has to be included in
scalarization uses only the name of a dummy argument object to recognize a
specific argument of an intrinsic procedure.  On the 11 branch, the dummy
argument object is not available and the code uses a mix of check for
argument name (for keyword arguments) and argument index (for non-keyword ones).
This makes backports non-straightforward in this area, as the argument indexes
depend on the intrinsics.

This change fixes a bogus backport for LEN_TRIM, whose KIND argument index
should be different from that of INDEX.

PR fortran/87711
PR fortran/97896

gcc/fortran/ChangeLog:

* trans-array.c (arg_evaluated_for_scalarization): Handle keyword and
non-keyword arguments separatedly.  Adapt the expected argument index
for KIND to each intrinsic in the non-keyword case.

gcc/testsuite/ChangeLog:

* gfortran.dg/index_5.f90: Enrich test with usages of INDEX with
a non-keyword KIND argument.
* gfortran.dg/len_trim.f90: Same for LEN_TRIM.

(tests cherry picked from commit 15630e6e9eb019477d1fc5c0966b43979e18ae18)
---
 gcc/fortran/trans-array.c  | 41 +++---
 gcc/testsuite/gfortran.dg/index_5.f90  |  2 ++
 gcc/testsuite/gfortran.dg/len_trim.f90 |  6 
 3 files changed, 39 insertions(+), 10 deletions(-)

diff --git a/gcc/fortran/trans-array.c b/gcc/fortran/trans-array.c
index db14daca459..e187a08f8f0 100644
--- a/gcc/fortran/trans-array.c
+++ b/gcc/fortran/trans-array.c
@@ -11220,18 +11220,39 @@ arg_evaluated_for_scalarization (gfc_intrinsic_sym *function,
 {
   if (function != NULL)
 {
-  switch (function->id)
+  if (actual_arg.name == NULL)
 	{
-	  case GFC_ISYM_INDEX:
-	  case GFC_ISYM_LEN_TRIM:
-	if ((actual_arg.name == NULL && arg_num == 3)
-		|| (actual_arg.name != NULL
-		&& strcmp ("kind", actual_arg.name) == 0))
-	  return false;
-	  /* Fallthrough.  */
+	  switch (function->id)
+	{
+	  case GFC_ISYM_INDEX:
+		if (arg_num == 3)
+		  return false;
+		break;
 
-	  default:
-	break;
+	  case GFC_ISYM_LEN_TRIM:
+		if (arg_num == 1)
+		  return false;
+
+	  /* Fallthrough.  */
+
+	  default:
+		break;
+	}
+	}
+  else
+	{
+	  switch (function->id)
+	{
+	  case GFC_ISYM_INDEX:
+	  case GFC_ISYM_LEN_TRIM:
+		if (strcmp ("kind", actual_arg.name) == 0)
+		  return false;
+
+	  /* Fallthrough.  */
+
+	  default:
+		break;
+	}
 	}
 }
 
diff --git a/gcc/testsuite/gfortran.dg/index_5.f90 b/gcc/testsuite/gfortran.dg/index_5.f90
index e039455d175..4dc2ce4c0a1 100644
--- a/gcc/testsuite/gfortran.dg/index_5.f90
+++ b/gcc/testsuite/gfortran.dg/index_5.f90
@@ -19,5 +19,7 @@ program p
   d = index ('xyxyz','yx', back=a, kind=8)
   b = index ('xyxyz','yx', back=a, kind=8)
   d = index ('xyxyz','yx', back=a, kind=4)
+  b = index ('xyxyz','yx',  a,  4)
+  d = index ('xyxyz','yx',  a,  8)
 end
 
diff --git a/gcc/testsuite/gfortran.dg/len_trim.f90 b/gcc/testsuite/gfortran.dg/len_trim.f90
index 2252b81f084..77e3d30c669 100644
--- a/gcc/testsuite/gfortran.dg/len_trim.f90
+++ b/gcc/testsuite/gfortran.dg/len_trim.f90
@@ -17,11 +17,17 @@ program main
   kk = len_trim (a)
   mm = len_trim (a, kind=4)
   nn = len_trim (a, kind=8)
+  mm = len_trim (a,  4)
+  nn = len_trim (a,  8)
   kk = len_trim ([b])
   mm = len_trim ([b],kind=4)
   nn = len_trim ([b],kind=8)
+  mm = len_trim ([b], 4)
+  nn = len_trim ([b], 8)
   kk = len_trim (c)
   mm = len_trim (c, kind=4)
   nn = len_trim (c, kind=8)
+  mm = len_trim (c,  4)
+  nn = len_trim (c,  8)
   if (any (l4 /= 2_4) .or. any (l8 /= 2_8)) stop 1
 end program main

[pushed 2/3] Fortran: Ignore KIND argument of a few more intrinsics. [PR103789]

2022-01-16 Thread Mikael Morin via Gcc-patches 

After PR97896 for which some code was added to ignore the KIND argument
of the INDEX intrinsics, and PR87711 for which that was extended to LEN_TRIM
as well, this propagates it further to MASKL, MASKR, SCAN and VERIFY.

PR fortran/103789

gcc/fortran/ChangeLog:

* trans-array.c (arg_evaluated_for_scalarization): Add MASKL, MASKR,
SCAN and VERIFY to the list of intrinsics whose KIND argument is to be
ignored.

gcc/testsuite/ChangeLog:

* gfortran.dg/maskl_1.f90: New test.
* gfortran.dg/maskr_1.f90: New test.
* gfortran.dg/scan_3.f90: New test.
* gfortran.dg/verify_3.f90: New test.

(cherry picked from commit c1c17a43e172ebc28f2cd247f6e83c5fdbc6219f)
---
 gcc/fortran/trans-array.c  |  4 
 gcc/testsuite/gfortran.dg/maskl_1.f90  | 10 ++
 gcc/testsuite/gfortran.dg/maskr_1.f90  | 10 ++
 gcc/testsuite/gfortran.dg/scan_3.f90   | 11 +++
 gcc/testsuite/gfortran.dg/verify_3.f90 | 11 +++
 5 files changed, 46 insertions(+)
 create mode 100644 gcc/testsuite/gfortran.dg/maskl_1.f90
 create mode 100644 gcc/testsuite/gfortran.dg/maskr_1.f90
 create mode 100644 gcc/testsuite/gfortran.dg/scan_3.f90
 create mode 100644 gcc/testsuite/gfortran.dg/verify_3.f90

diff --git a/gcc/fortran/trans-array.c b/gcc/fortran/trans-array.c
index e187a08f8f0..308213c57e3 100644
--- a/gcc/fortran/trans-array.c
+++ b/gcc/fortran/trans-array.c
@@ -11225,11 +11225,15 @@ arg_evaluated_for_scalarization (gfc_intrinsic_sym *function,
 	  switch (function->id)
 	{
 	  case GFC_ISYM_INDEX:
+	  case GFC_ISYM_SCAN:
+	  case GFC_ISYM_VERIFY:
 		if (arg_num == 3)
 		  return false;
 		break;
 
 	  case GFC_ISYM_LEN_TRIM:
+	  case GFC_ISYM_MASKL:
+	  case GFC_ISYM_MASKR:
 		if (arg_num == 1)
 		  return false;
 
diff --git a/gcc/testsuite/gfortran.dg/maskl_1.f90 b/gcc/testsuite/gfortran.dg/maskl_1.f90
new file mode 100644
index 000..9e25c2c9cdc
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/maskl_1.f90
@@ -0,0 +1,10 @@
+! { dg-do compile }
+!
+! PR fortran/103789
+! Check the absence of ICE when generating calls to MASKL with a KIND argument.
+
+program p
+   integer :: z(2), y(2)
+   y = [1, 13]
+   z = maskl(y, kind=4) + 1
+end program p
diff --git a/gcc/testsuite/gfortran.dg/maskr_1.f90 b/gcc/testsuite/gfortran.dg/maskr_1.f90
new file mode 100644
index 000..ebfd3dbba33
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/maskr_1.f90
@@ -0,0 +1,10 @@
+! { dg-do compile }
+!
+! PR fortran/103789
+! Check the absence of ICE when generating calls to MASKR with a KIND argument.
+
+program p
+   integer :: z(2), y(2)
+   y = [1, 13]
+   z = maskr(y, kind=4) + 1
+end program p
diff --git a/gcc/testsuite/gfortran.dg/scan_3.f90 b/gcc/testsuite/gfortran.dg/scan_3.f90
new file mode 100644
index 000..80262ae2167
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/scan_3.f90
@@ -0,0 +1,11 @@
+! { dg-do compile }
+!
+! PR fortran/103789
+! Check the absence of ICE when generating calls to SCAN with a KIND argument.
+
+program p
+   character(len=10) :: y(2)
+   integer :: z(2)
+   y = ['abc', 'def']
+   z = scan(y, 'e', kind=4) + 1
+end program p
diff --git a/gcc/testsuite/gfortran.dg/verify_3.f90 b/gcc/testsuite/gfortran.dg/verify_3.f90
new file mode 100644
index 000..f01e24e199e
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/verify_3.f90
@@ -0,0 +1,11 @@
+! { dg-do compile }
+!
+! PR fortran/103789
+! Check the absence of ICE when generating calls to VERIFY with a KIND argument.
+
+program p
+   character(len=10) :: y(2)
+   integer :: z(2)
+   y = ['abc', 'def']
+   z = verify(y, 'e', kind=4) + 1
+end program p

[pushed 3/3] testsuite: Enrich tests with variants failing on the branch.

2022-01-16 Thread Mikael Morin via Gcc-patches 

Backporting the fix for pr103789 on the 11 branch revealed a lack of test
coverage for the tests provided with that fix.  Indeed, the tests use the KIND
argument of the respective intrinsics only with keyword arguments.
This adds variants with non-keyword arguments.

The tests enriched this way fail on the branch if the fix is cherry-picked
straightforwardly.  The fix will have to be tweaked slightly there.

PR fortran/103789
PR fortran/87711
PR fortran/97896

gcc/testsuite/ChangeLog:

* gfortran.dg/maskl_1.f90: Enrich test with usages of MASKL with
a non-keyword KIND argument.
* gfortran.dg/maskr_1.f90: Same for MASKR.
* gfortran.dg/scan_3.f90: Same for SCAN.
* gfortran.dg/verify_3.f90: Same for VERIFY.

(cherry picked from commit 15630e6e9eb019477d1fc5c0966b43979e18ae18)
---
 gcc/testsuite/gfortran.dg/maskl_1.f90  | 3 ++-
 gcc/testsuite/gfortran.dg/maskr_1.f90  | 3 ++-
 gcc/testsuite/gfortran.dg/scan_3.f90   | 5 -
 gcc/testsuite/gfortran.dg/verify_3.f90 | 5 -
 4 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/gcc/testsuite/gfortran.dg/maskl_1.f90 b/gcc/testsuite/gfortran.dg/maskl_1.f90
index 9e25c2c9cdc..56350e269da 100644
--- a/gcc/testsuite/gfortran.dg/maskl_1.f90
+++ b/gcc/testsuite/gfortran.dg/maskl_1.f90
@@ -4,7 +4,8 @@
 ! Check the absence of ICE when generating calls to MASKL with a KIND argument.
 
 program p
-   integer :: z(2), y(2)
+   integer :: z(2), y(2), x(2)
y = [1, 13]
z = maskl(y, kind=4) + 1
+   x = maskl(y,  4) + 1
 end program p
diff --git a/gcc/testsuite/gfortran.dg/maskr_1.f90 b/gcc/testsuite/gfortran.dg/maskr_1.f90
index ebfd3dbba33..f8ccdd11ab3 100644
--- a/gcc/testsuite/gfortran.dg/maskr_1.f90
+++ b/gcc/testsuite/gfortran.dg/maskr_1.f90
@@ -4,7 +4,8 @@
 ! Check the absence of ICE when generating calls to MASKR with a KIND argument.
 
 program p
-   integer :: z(2), y(2)
+   integer :: z(2), y(2), x(2)
y = [1, 13]
z = maskr(y, kind=4) + 1
+   x = maskr(y,  4) + 1
 end program p
diff --git a/gcc/testsuite/gfortran.dg/scan_3.f90 b/gcc/testsuite/gfortran.dg/scan_3.f90
index 80262ae2167..2a9ed080957 100644
--- a/gcc/testsuite/gfortran.dg/scan_3.f90
+++ b/gcc/testsuite/gfortran.dg/scan_3.f90
@@ -5,7 +5,10 @@
 
 program p
character(len=10) :: y(2)
-   integer :: z(2)
+   integer :: z(2), x(2), w(2), v(2)
y = ['abc', 'def']
z = scan(y, 'e', kind=4) + 1
+   x = scan(y, 'e', back=.false., kind=4) + 1
+   w = scan(y, 'e',  .false., kind=4) + 1
+   v = scan(y, 'e',  .false.,  4) + 1
 end program p
diff --git a/gcc/testsuite/gfortran.dg/verify_3.f90 b/gcc/testsuite/gfortran.dg/verify_3.f90
index f01e24e199e..c8b26b70614 100644
--- a/gcc/testsuite/gfortran.dg/verify_3.f90
+++ b/gcc/testsuite/gfortran.dg/verify_3.f90
@@ -5,7 +5,10 @@
 
 program p
character(len=10) :: y(2)
-   integer :: z(2)
+   integer :: z(2), x(2), w(2), v(2)
y = ['abc', 'def']
z = verify(y, 'e', kind=4) + 1
+   x = verify(y, 'e', back=.false., kind=4) + 1
+   w = verify(y, 'e',  .false., kind=4) + 1
+   x = verify(y, 'e',  .false.,  4) + 1
 end program p

Re: [PATCH] Fortran: make IEEE_VALUE produce signaling NaNs

2022-01-16 Thread FX via Gcc-patches 
Thanks Mikael,

> This looks good to me. Thanks.

Thanks. Pushed: 
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=90045c5df5b3c8853e7740fb72a11aead1c489bb

FX

Re: [pushed 3/3] testsuite: Enrich tests with variants failing on the branch.

2022-01-16 Thread Thomas Koenig via Gcc-patches 



Hi Mikael,


Backporting the fix for pr103789 on the 11 branch revealed a lack of test
coverage for the tests provided with that fix.  Indeed, the tests use the KIND
argument of the respective intrinsics only with keyword arguments.
This adds variants with non-keyword arguments.

The tests enriched this way fail on the branch if the fix is cherry-picked
straightforwardly.  The fix will have to be tweaked slightly there.


As a general principle, we should not add or amend test cases unless
it is wrong code that we need to remove

The reason is that changing a test case makes regression testing,
especially the automated version, harder - if a test starts failing,
is it due to a change in the test case or a change in the compiler
or library?

I don't think there is a need to revert this patch, but please
add separate test cases if you have new things to test in
the future.

Best regards

Thomas

Re: [PATCH] Fortran: make IEEE_VALUE produce signaling NaNs

2022-01-16 Thread FX via Gcc-patches 
Hi Mikael, team,

> Thanks. Pushed: 
> https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=90045c5df5b3c8853e7740fb72a11aead1c489bb

Pushed a further commit to XFAIL the testcases on x87:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=86e3b476d5defaa79c94d40b76cbeec21cd02e5f

There the ABI does not allow us to meaningfully pass signaling NaNs in float 
and double types, sadly.

FX

[PATCH] Fortran: detect signaling NaNs on targets without issignaling macro in libc

2022-01-16 Thread FX via Gcc-patches 
This patch is the third in my “signaling NaN” series. For targets with IEEE 
support but without the issignaling macro in libc (i.e., everywhere except 
glibc), this allows us to provide a fallback implementation. In order to keep 
the code in ieee_helper.c relatively readable, I’ve put that new implementation 
in a separate file, issignaling_fallback.h.

The logic is borrowed from different routines in glibc, but gathered into a 
single file and much simpler than the glibc implementation, because we do not 
need to cover all the cases they have (comments with details are available in 
issignaling_fallback.h).

I can’t test this on all the targets I’d like to, obviously. But it was tested 
on x86_64-pc-linux-gnu (where it doesn’t do anything), on x86_64-pc-linux-gnu 
by mimicking the lack of a issignaling macro, and on x86_64-apple-darwin (which 
does not have issignaling).

OK to push?



issignaling.diff
Description: Binary data

Re: [PATCH 11/11] libstdc++: Fix ODR issues with different -m flags

2022-01-16 Thread Jonathan Wakely via Gcc-patches 
On Fri, 14 Jan 2022 at 21:30, Jonathan Wakely  wrote:

>
>
> On Mon, 15 Nov 2021 at 08:57, Matthias Kretz  wrote:
>
>> ping. OK to push?
>>
>
> Sorry for the delay - this is OK for trunk.
>

I see a new failure on powerpc64le-linux (gcc112 in the cfarm) after this
commit:

FAIL: experimental/simd/standard_abi_usable_2.cc -maltivec -mpower8-vector
-O2 -Wno-psabi (test for excess errors)

Re: [PATCH] libstdc++: Implement C++20 atomic and atomic

2022-01-16 Thread Jonathan Wakely via Gcc-patches 
On Fri, 14 Jan 2022 at 22:40, Jonathan Wakely  wrote:

>
>
> On Sat, 18 Sept 2021 at 05:12, Thomas Rodgers 
> wrote:
>
>> From: Thomas Rodgers 
>>
>> Let's try this one instead.
>>
>> Signed-off-by: Thomas Rodgers 
>>
>
> If you're doing DCO "Signed-off-by" commits you don't need FSF copyright
> notices in the new tests.
>
> I no longer put any copyright notices in the tests, because it's largely
> pointless. They're usually not interesting and don't do anything that
> anybody is going to want to steal to incorporate into non-GPL code. Your
> new 20_util/shared_ptr/atomic/atomic_shared_ptr.cc is non-trivial, and
> maybe interesting, but the two that just check feature test macros are not
> worth putting licence headers and copyright notices on.
>
>
>
>> libstdc++-v3/ChangeLog:
>> * acinclude.m4: Update ABI version.
>> * config/abi/pre/gnu.ver (GLIBCXX_3.4.21): Do not match new
>> _Sp_locker
>> constructor.
>> (GLIBCXX_3.4.30): Export _Sp_locker::_M_wait/_M_notify and new
>> constructor.
>> * include/bits/shared_ptr_atomic.h: define
>> __cpp_lib_atomic_shared_ptr
>> feature test macro.
>> (_Sp_locker::_Sp_locker(const void*, bool): New constructor.
>> (_Sp_locker::_M_wait()), _Sp_locker::_M_notify()): New methods.
>> (_Sp_impl): New type.
>> (atomic>): New partial template specialization.
>> (atomic>): New partial template specialization.
>> * include/std/version: define __cpp_lib_atomic_shared_ptr feature
>> test macro.
>> * doc/xml/manual/abi.xml: New ABI version.
>> * src/c++11/Makefile.am: Compile src/c++11/shared_ptr.cc
>> -std=gnu++20.
>> * src/c++11/Makefile.in: Regenerate.
>> * src/c++11/shared_ptr.cc (_Sp_locker::_Sp_locker(const void*,
>> bool),
>> _Sp_locker::_M_wait(), _Sp_locker::_M_notify(): Implement.
>> * testsuite/20_util/shared_ptr/atomic/4.cc: New test.
>> * testsuite/20_util/shared_ptr/atomic/5.cc: Likewise.
>> * testsuite/20_util/shared_ptr/atomic/atomic_shared_ptr.cc:
>> Likewise.
>> * testuite/util/testsuite_abi.cc: New ABI version.
>> ---
>>  libstdc++-v3/acinclude.m4 |   2 +-
>>  libstdc++-v3/config/abi/pre/gnu.ver   |  12 +-
>>  libstdc++-v3/configure|   2 +-
>>  libstdc++-v3/doc/xml/manual/abi.xml   |   1 +
>>  libstdc++-v3/include/bits/shared_ptr_atomic.h | 309 ++
>>  libstdc++-v3/include/std/version  |   1 +
>>  libstdc++-v3/src/c++11/Makefile.am|   6 +
>>  libstdc++-v3/src/c++11/Makefile.in|   6 +
>>  libstdc++-v3/src/c++11/shared_ptr.cc  |  86 -
>>  .../testsuite/20_util/shared_ptr/atomic/4.cc  |  28 ++
>>  .../testsuite/20_util/shared_ptr/atomic/5.cc  |  28 ++
>>  .../shared_ptr/atomic/atomic_shared_ptr.cc| 159 +
>>  libstdc++-v3/testsuite/util/testsuite_abi.cc  |   3 +-
>>  13 files changed, 637 insertions(+), 6 deletions(-)
>>  create mode 100644 libstdc++-v3/testsuite/20_util/shared_ptr/atomic/4.cc
>>  create mode 100644 libstdc++-v3/testsuite/20_util/shared_ptr/atomic/5.cc
>>  create mode 100644
>> libstdc++-v3/testsuite/20_util/shared_ptr/atomic/atomic_shared_ptr.cc
>>
>>
> [...]
>
>
>> +  void
>> +  store(value_type __r, memory_order __o = memory_order_seq_cst)
>> noexcept
>> +  { _M_impl._M_store(move(__r), __o); }
>>
>
> Every move(x) needs to be qualified as std::move(x) to avoid ADL.
>
>
>
>>
>> +
>> +// { dg-options "-std=gnu++2a" }
>> +// { dg-do run { target c++2a } }
>>
>
> gnu++20 and c++20 has been OK for a while, there's no need to use the 2a
> forms.
>
> Other than that, the patch looks OK, but I have a modified version based
> on your patch just using atomic ops, no mutexes, which I'll post shortly.
>

Here's the finished version of that patch, which is all inline in the
header, and performs faster too.

Tested powerpc64le-linux and x86_64-linux.
Pushed to trunk.
commit 2ac0649d7bf3eacbf92add1ec2b54045c401a4c2
Author: Jonathan Wakely 
Date:   Sun Jan 16 20:47:09 2022

libstdc++: Implement C++20 atomic and atomic

This adds another piece of C++20, the std::atomic specializations for
std::shared_ptr and std::weak_ptr.

The new _Sp_atomic type mimics the structure of shared_ptr and
weak_ptr, holding a T* pointer (the one returned by get() on a
shared_ptr/weak ptr) and a _Sp_counted_base<>* pointer to the
ref-counted control block. For _Sp_atomic the low bit of the control
block pointer is used as a lock bit, to ensure only one thread will
access the object at a time.  The pointer is actually stored as a
uintptr_t to avoid accidental dereferences of the pointer when unlocked
(which would be a race) or when locked (which would dereference the
wrong pointer value due to the low bit being set). To get a raw pointer
to the control block, the lock must be acquired. Converti

[committed] libstdc++: Update C++20 status table

2022-01-16 Thread Jonathan Wakely via Gcc-patches 
libstdc++-v3/ChangeLog:

   * doc/xml/manual/status_cxx2020.xml: Update.
   * doc/html/manual/status.html: Regenerate.

Pushed to trunk.
commit a326934886f606b4a4a60254917f58c825d7c94b
Author: Jonathan Wakely 
Date:   Thu Jan 13 22:18:13 2022

libstdc++: Update C++20 status table

libstdc++-v3/ChangeLog:

* doc/xml/manual/status_cxx2020.xml: Update.
* doc/html/manual/status.html: Regenerate.

diff --git a/libstdc++-v3/doc/xml/manual/status_cxx2020.xml 
b/libstdc++-v3/doc/xml/manual/status_cxx2020.xml
index 26c882907f3..cebe36a8d5e 100644
--- a/libstdc++-v3/doc/xml/manual/status_cxx2020.xml
+++ b/libstdc++-v3/doc/xml/manual/status_cxx2020.xml
@@ -114,24 +114,22 @@ or any notes about the implementation.
 
 
 
-  
 Making std::string constexpr 
   
 http://www.w3.org/1999/xlink"; 
xlink:href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0980r1.pdf";>
 P0980R1 
   
-  
+   12 
__cpp_lib_constexpr_string >= 201907L 
 
 
 
-  
 Making std::vector constexpr 
   
 http://www.w3.org/1999/xlink"; 
xlink:href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1004r2.pdf";>
 P1004R2 
   
-  
+   12 
__cpp_lib_constexpr_vector >= 201907L 
 
 
@@ -397,13 +395,12 @@ or any notes about the implementation.
 
 
 
-  
 Atomic shared_ptr 
   
 http://www.w3.org/1999/xlink"; 
xlink:href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0718r2.html";>
 P0718R2 
   
-   
+   12 
 __cpp_lib_atomic_shared_ptr >= 201711L 
 
 
@@ -893,13 +890,12 @@ or any notes about the implementation.
 
 
 
-  
 Extending make_shared to Support Arrays 
   
 http://www.w3.org/1999/xlink"; 
xlink:href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0674r1.html";>
 P0674R1 
   
-   
+   12 
__cpp_lib_shared_ptr_arrays >= 201707L 
 
 
@@ -936,13 +932,12 @@ or any notes about the implementation.
 
 
 
-  
 Smart pointer creation with default initialization 
   
 http://www.w3.org/1999/xlink"; 
xlink:href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1020r1.html";>
 P1020R1 
   
-   
+   12 
__cpp_lib_smart_ptr_for_overwrite >= 201811L 

 
 
@@ -1079,13 +1074,12 @@ or any notes about the implementation.
 
 
 
-  
 Reviewing Deprecated Facilities of C++17 for C++20 
   
 http://www.w3.org/1999/xlink"; 
xlink:href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0619r4.html";>
 P0619R4 
   
-   
+   12

Re: [PATCH v2 RFA] diagnostic: avoid repeating include path

2022-01-16 Thread David Malcolm via Gcc-patches 
On Fri, 2022-01-14 at 23:01 -0500, Jason Merrill wrote:
> On 1/13/22 17:30, David Malcolm wrote:
> > On Thu, 2022-01-13 at 17:08 -0500, Jason Merrill wrote:
> > > When a sequence of diagnostic messages bounces back and forth
> > > repeatedly
> > > between two includes, as with
> > > 
> > >   #include 
> > >   std::map m ("123", "456");
> > > 
> > > The output is quite a bit longer than necessary because we dump
> > > the
> > > include
> > > path each time it changes.  I'd think we could print the include
> > > path
> > > once
> > > for each header file, and then expect that the user can look
> > > earlier
> > > in the
> > > output if they're wondering.
> > > 
> > > Tested x86_64-pc-linux-gnu, OK for trunk?
> > > 
> > > gcc/ChangeLog:
> > > 
> > >  * diagnostic.c (includes_seen): New.
> > >  (diagnostic_report_current_module): Use it.
> > > ---
> > >   gcc/diagnostic.c | 12 +++-
> > >   1 file changed, 11 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/gcc/diagnostic.c b/gcc/diagnostic.c
> > > index 58139427d01..e56441a2dbf 100644
> > > --- a/gcc/diagnostic.c
> > > +++ b/gcc/diagnostic.c
> > > @@ -700,6 +700,16 @@ set_last_module (diagnostic_context
> > > *context,
> > > const line_map_ordinary *map)
> > >     context->last_module = map;
> > >   }
> > >   
> > > +/* Only dump the "In file included from..." stack once for each
> > > file.  */
> > > +
> > > +static bool
> > > +includes_seen (const line_map_ordinary *map)
> > > +{
> > > +  using hset = hash_set;
> > > +  static hset *set = new hset;
> > > +  return set->add (map);
> > > +}
> > 
> > Overall, I like the idea, but...
> > 
> > - the patch works at the level of line_map_ordinary instances,
> > rather
> > than header files.  There are various ways in which a single header
> > file can have multiple line maps e.g. due to very long lines, or
> > including another file, etc.  I think it makes sense to do it at
> > the
> > per-file level, assuming we aren't in a horrible situation where a
> > header is being included repeatedly, with different effects.  So
> > maybe
> > this ought to look at what include directive led to this map, i.e.
> > looking at the ord_map->included_from field, and having a
> > hash_set ?
> 
> Done.  This version doesn't affect printing of the module import path
> yet, pending more consideration of whether we always want to identify
> the module it comes from or just the file/line is enough.

Seems like a good choice given that everyone's going to be much less
familiar with modules than with include files, for some time.

> 
> > - there's no test coverage, but it's probably not feasible to write
> > DejaGnu tests for this, given the way prune.exp's prune_gcc_output
> > strips these strings.  Maybe a dg directive to selectively disable
> > the
> > pertinent pruning operations in prune_gcc_output???  Gah...
> > 
> > - global state is a pet peeve of mine; can the above state be put
> > inside the diagnostic_context instead?   (perhaps via a pointer to
> > a
> > wrapper class to avoid requiring all users of diagnostic.h to
> > include
> > hash-set.h?).
> 
> It seems that using hash_set directly doesn't break any users.

Thanks.  The updated patch looks good to me.

Dave

[r12-6615 Regression] FAIL: gfortran.dg/ieee/signaling_2.f90 -Os execution test on Linux/x86_64

2022-01-16 Thread sunil.k.pandey via Gcc-patches 
On Linux/x86_64,

90045c5df5b3c8853e7740fb72a11aead1c489bb is the first bad commit
commit 90045c5df5b3c8853e7740fb72a11aead1c489bb
Author: Francois-Xavier Coudert 
Date:   Mon Jan 10 17:04:34 2022 +0100

Fortran: allow IEEE_VALUE to correctly return signaling NaNs

caused

FAIL: gfortran.dg/ieee/signaling_2.f90   -O0  execution test
FAIL: gfortran.dg/ieee/signaling_2.f90   -O1  execution test
FAIL: gfortran.dg/ieee/signaling_2.f90   -O2  execution test
FAIL: gfortran.dg/ieee/signaling_2.f90   -O3 -fomit-frame-pointer 
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
FAIL: gfortran.dg/ieee/signaling_2.f90   -O3 -g  execution test
FAIL: gfortran.dg/ieee/signaling_2.f90   -Os  execution test

with GCC configured with

../../gcc/configure 
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r12-6615/usr 
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld 
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl 
--enable-libmpx x86_64-linux --disable-bootstrap

To reproduce:

$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="ieee.exp=gfortran.dg/ieee/signaling_2.f90 
--target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="ieee.exp=gfortran.dg/ieee/signaling_2.f90 
--target_board='unix{-m32\ -march=cascadelake}'"

(Please do not reply to this email, for question about this report, contact me 
at skpgkp2 at gmail dot com)

Ping Re: [PATCH] middle-end: move initialization of stack_limit_rtx [PR103163]

2022-01-16 Thread Sandra Loosemore 

On 1/8/22 9:24 PM, Sandra Loosemore wrote:
This patch fixes the ICE I reported in PR103163.  We were initializing 
stack_limit_rtx before the register properties it depends on were 
getting set.  I moved it to the same function where stack_pointer_rtx, 
frame_pointer_rtx, etc are being initialized.


Besides nios2 where I observed it, this bug was also reported to affect 
powerpc.  Anybody want to check it there?  Otherwise, OK to check in?


Ping?

https://gcc.gnu.org/pipermail/gcc-patches/2022-January/587958.html

-Sandra

[r12-6616 Regression] FAIL: gfortran.dg/ieee/signaling_3.f90 -Os execution test on Linux/x86_64

2022-01-16 Thread sunil.k.pandey via Gcc-patches 
On Linux/x86_64,

86e3b476d5defaa79c94d40b76cbeec21cd02e5f is the first bad commit
commit 86e3b476d5defaa79c94d40b76cbeec21cd02e5f
Author: Francois-Xavier Coudert 
Date:   Mon Jan 17 00:00:18 2022 +0100

Fortran: xfail signaling NaN testcases on x87

caused

FAIL: gfortran.dg/ieee/signaling_3.f90   -O0  execution test
FAIL: gfortran.dg/ieee/signaling_3.f90   -O1  execution test
FAIL: gfortran.dg/ieee/signaling_3.f90   -O2  execution test
FAIL: gfortran.dg/ieee/signaling_3.f90   -O3 -fomit-frame-pointer 
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
FAIL: gfortran.dg/ieee/signaling_3.f90   -O3 -g  execution test
FAIL: gfortran.dg/ieee/signaling_3.f90   -Os  execution test

with GCC configured with

../../gcc/configure 
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r12-6616/usr 
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld 
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl 
--enable-libmpx x86_64-linux --disable-bootstrap

To reproduce:

$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="ieee.exp=gfortran.dg/ieee/signaling_3.f90 
--target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="ieee.exp=gfortran.dg/ieee/signaling_3.f90 
--target_board='unix{-m32\ -march=cascadelake}'"

(Please do not reply to this email, for question about this report, contact me 
at skpgkp2 at gmail dot com)

Re: [PATCH] rs6000: Use known constant for GET_MODE_NUNITS and similar

2022-01-16 Thread Kewen.Lin via Gcc-patches 
on 2022/1/14 下午9:53, David Edelsohn wrote:
> On Fri, Jan 14, 2022 at 5:42 AM Kewen.Lin  wrote:
>>
>> on 2022/1/13 下午11:15, David Edelsohn wrote:
>>> On Thu, Jan 13, 2022 at 7:40 AM Kewen.Lin  wrote:

 Hi David,

 on 2022/1/13 上午11:12, David Edelsohn wrote:
> On Wed, Jan 12, 2022 at 8:56 PM Kewen.Lin  wrote:
>>
>> Hi,
>>
>> This patch is to clean up some codes with GET_MODE_UNIT_SIZE or
>> GET_MODE_NUNITS, which can use known constant instead.
>
> I'll let Segher decide, but often the additional code is useful
> self-documentation instead of magic constants.  Or at least the change
> requires comments documenting the derivation of the constants
> currently described by the code itself.
>

 Thanks for the comments, I added some comments as suggested, also removed
 the whole "altivec_vreveti2" since I noticed it's useless, it's not used
 by any built-in functions and even unused in the commit db042e1603db50573.

 The updated version has been tested as before.
>>>
>>> As we have discussed offline, the comments need to be clarified and 
>>> expanded.
>>>
>>> And the removal of altivec_vreveti2 should be confirmed with Carl
>>> Love, who added the pattern less than a year ago. There may be another
>>> patch planning to use it.
>>>
>>
>> Thanks for the suggestions David!  The comments have been updated, and Carl
>> also helped to confirm the altivec_vreveti2 pattern is not planned for any
>> future work and looks reasonable to remove.
>>
>> Does this updated version look good to you?
> 
> The revised patch is okay.

Thanks!  Committed as r12-6621.

BR,
Kewen

Re: [patch, libgfortran, power-ieee128] Add multiple defaults for GFORTRAN_CONVERT_UNIT

2022-01-16 Thread Thomas Koenig via Gcc-patches 

On 13.01.22 22:58, Thomas Koenig via Fortran wrote:

with this patch, it is now possible to specify both the
endianness and the REAL(KIND=16) format using the
environment variable GFORTRAN_CONVERT_UNIT.


I have now pushed this to trunk.

Best regards

Thomas

Re: [PATCH 1/3] tree-ssa-sink: do not sink to in front of setjmp

2022-01-16 Thread Richard Biener via Gcc-patches 
On Fri, Jan 14, 2022 at 7:21 PM Alexander Monakov  wrote:
>
> gcc/ChangeLog:
>
> * tree-ssa-sink.c (select_best_block): Punt if selected block
> has incoming abnormal edges.

OK.

> gcc/testsuite/ChangeLog:
>
> * gcc.dg/setjmp-7.c: New test.
> ---
>  gcc/testsuite/gcc.dg/setjmp-7.c | 13 +
>  gcc/tree-ssa-sink.c |  6 ++
>  2 files changed, 19 insertions(+)
>  create mode 100644 gcc/testsuite/gcc.dg/setjmp-7.c
>
> diff --git a/gcc/testsuite/gcc.dg/setjmp-7.c b/gcc/testsuite/gcc.dg/setjmp-7.c
> new file mode 100644
> index 0..44b5bcbfa
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/setjmp-7.c
> @@ -0,0 +1,13 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -fno-guess-branch-probability -w" } */
> +/* { dg-require-effective-target indirect_jumps } */
> +
> +struct __jmp_buf_tag { };
> +typedef struct __jmp_buf_tag jmp_buf[1];
> +struct globals { jmp_buf listingbuf; };
> +extern struct globals *const ptr_to_globals;
> +void foo()
> +{
> +if ( _setjmp ( ((*ptr_to_globals).listingbuf )))
> +   ;
> +}
> diff --git a/gcc/tree-ssa-sink.c b/gcc/tree-ssa-sink.c
> index 66d7ae89e..016ecbaec 100644
> --- a/gcc/tree-ssa-sink.c
> +++ b/gcc/tree-ssa-sink.c
> @@ -208,6 +208,12 @@ select_best_block (basic_block early_bb,
>temp_bb = get_immediate_dominator (CDI_DOMINATORS, temp_bb);
>  }
>
> +  /* Placing a statement before a setjmp-like function would be invalid
> + (it cannot be reevaluated when execution follows an abnormal edge).
> + If we selected a block with abnormal predecessors, just punt.  */
> +  if (bb_has_abnormal_pred (best_bb))
> +return early_bb;
> +
>/* If we found a shallower loop nest, then we always consider that
>   a win.  This will always give us the most control dependent block
>   within that loop nest.  */
> --
> 2.33.1
>

Re: [arm] MVE: Relax addressing modes for full loads and stores

2022-01-16 Thread Christophe Lyon via Gcc-patches 
Hi André,

On Fri, Jan 14, 2022 at 6:03 PM Andre Vieira (lists) via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:

> Hi Christophe,
>
> This patch relaxes the addressing modes for the mve full load and stores
> (by full loads and stores I mean non-widening or narrowing loads and
> stores resp). The code before was requiring a LO_REGNUM for these, where
> this is only a requirement if the load is widening or the store narrowing.
>
> So with this your patch should not be necessary.
>
> Regression tested on arm-none-eabi-gcc.  Can you please confirm this
> fixes the issue you were seeing too?
>

Yes, I confirm this fixes the problem I was fixing with my patch #15 in my
MVE/VCMP/VCOND series.
I'll drop it.

Thanks!

Christophe


>
> gcc/ChangeLog:
>
>  * config/arm/arm.h (MVE_STN_LDW_MODE): New MACRO.
>  * config/arm/arm.c (mve_vector_mem_operand): Relax constraint on
>  base register for non widening loads or narrowing stores.
>
>
> Kind Regards,
> Andre Vieira