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

[Uros Bizjak via Gcc-patches]

On Sat, Jul 23, 2022 at 9:32 AM Roger Sayle  wrote:
>
>
> This patch resolves PR target/106303 (and the related PRs 106347,
> 106404, 106407) which are ICEs caused by my improvements to x86_64's
> 128-bit TImode to V1TImode Scalar to Vector (STV) pass.  My apologies
> for the breakage.  The issue is that data flow analysis is used to
> partition usage of each TImode pseudo into "chains", where each
> chain is analyzed and if suitable converted to vector operations.
> The problems appears when some chains for a pseudo are converted,
> and others aren't as RTL sharing can result in some mode changes
> leaking into other instructions that aren't/shouldn't/can't be
> converted, which eventually leads to an ICE for mismatched modes.
>
> My first approach to a fix was to unify more of the STV infrastructure,
> reasoning that if TImode STV was exhibiting these problems, but DImode
> and SImode STV weren't, the issue was likely to be caused/resolved by
> these remaining differences.  This appeared to fix some but not all of
> the reported PRs.  A better solution was then proposed by H.J. Lu in
> Bugzilla (thanks!) that we need to iterate the removal of candidates in the
> function timode_remove_non_convertible_regs until there are no further
> changes.  As each chain is removed from consideration, it in turn may
> affect whether other insns/chains can safely be converted.
>
> This patch has been tested on x86_64-pc-linux-gnu with make bootstrap
> and make -k check, both with and without --target_board=unix{-m32},
> with no new failures.  Ok for mainline?
>
>
> 2022-07-23  Roger Sayle  
> H.J. Lu  
>
> gcc/ChangeLog
> PR target/106303
> PR target/106347
> * config/i386/i386-features.cc (make_vector_copies): Move from
> general_scalar_chain to scalar_chain.
> (convert_reg): Likewise.
> (convert_insn_common): New scalar_chain method split out from
> general_scalar_chain convert_insn.
> (convert_registers): Move from general_scalar_chain to
> scalar_chain.
> (scalar_chain::convert): Call convert_insn_common before calling
> convert_insn.
> (timode_remove_non_convertible_regs): Iterate until there are
> no further changes to the candidates.
> * config/i386/i386-features.h (scalar_chain::hash_map): Move
> from general_scalar_chain.
> (scalar_chain::convert_reg): Likewise.
> (scalar_chain::convert_insn_common): New shared method.
> (scalar_chain::make_vector_copies): Move from general_scalar_chain.
> (scalar_chain::convert_registers): Likewise.  No longer virtual.
> (general_scalar_chain::hash_map): Delete.  Moved to scalar_chain.
> (general_scalar_chain::convert_reg): Likewise.
> (general_scalar_chain::make_vector_copies): Likewise.
> (general_scalar_chain::convert_registers): Delete virtual method.
> (timode_scalar_chain::convert_registers): Likewise.
>
> gcc/testsuite/ChangeLog
> PR target/106303
> PR target/106347
> * gcc.target/i386/pr106303.c: New test case.
> * gcc.target/i386/pr106347.c: New test case.

OK. (git diff -w shows much clearly what was changed).

Thanks,
Uros.

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

[Uros Bizjak via Gcc-patches]

On Sat, Jul 23, 2022 at 10:51 AM Roger Sayle  wrote:
>
>
>
> Hi Uros,
>
> This is the next iteration of the zero_extendditi2 patch last reviewed here:
>
> https://gcc.gnu.org/pipermail/gcc-patches/2022-June/596204.html
>
>
>
> [1] The sse.md changes were split out, reviewed, approved and committed.
>
> [2] The *concat splitters have been moved post-reload matching what we
>
> now do for many/most of the double word functionality.
>
> [3] As you recommend, these *concat splitters now use split_double_mode
>
> to “subreg” operand[0] into parts, via a new helper function that can also
>
> handle overlapping registers, and even use xchg for the rare case that a
>
> double word is constructed from its high and low parts, but the wrong
>
> way around.
>
>
>
> This patch has been tested on x86_64-pc-linux-gnu with make bootstrap
>
> and make -k check, both with and without –target_board=unix{-m32},
>
> with no new failures.  Ok for mainline?
>
>
>
> 2022-07-23  Roger Sayle  
>
> Uroš Bizjak  
>
>
>
> gcc/ChangeLog
>
> PR target/91681
>
> * config/i386/i386-expand.cc (split_double_concat): A new helper
>
> function for setting a double word value from two word values.
>
> * config/i386/i386-protos.h (split_double_concat): Prototype here.
>
> * config/i386/i386.md (zero_extendditi2): New define_insn_and_split.
>
> (*add3_doubleword_zext): New define_insn_and_split.
>
> (*sub3_doubleword_zext): New define_insn_and_split.
>
> (*concat3_1): New define_insn_and_split replacing
>
> previous define_split for implementing DST = (HI<<32)|LO as
>
> pair of move instructions, setting lopart and hipart.
>
> (*concat3_2): Likewise.
>
> (*concat3_3): Likewise, where HI is zero_extended.
>
> (*concat3_4): Likewise, where HI is zero_extended.
>
>
>
> gcc/testsuite/ChangeLog
>
> PR target/91681
>
> * g++.target/i386/pr91681.C: New test case (from the PR).
>
> * gcc.target/i386/pr91681-1.c: New int128 test case.
>
> * gcc.target/i386/pr91681-2.c: Likewise.
>
> * gcc.target/i386/pr91681-3.c: Likewise, but for ia32.

OK with two small adjustments:

+(define_insn_and_split "zero_extendditi2"
+  [(set (match_operand:TI 0 "nonimmediate_operand" "=r,o")
+ (zero_extend:TI (match_operand:DI 1 "nonimmediate_operand" "rm,r")))]

Please put the new pattern above zero_extendsidi2.

+(define_insn_and_split "*add3_doubleword_zext"
+  [(set (match_operand: 0 "nonimmediate_operand" "=r,o")

And this one after *add3_doubleword, to keep all _doubleword
patterns together.

Thanks,
Uros.

[COMMITTED] Allow registering same SSA name relations in oracle.

[Aldy Hernandez via Gcc-patches]

Similarly to what we did for the relation oracle, but for the path
oracle.  This was found while working on frange, where we can test for
x == x while checking for NANness.

Tested on x86-64 Linux.

gcc/ChangeLog:

* value-relation.cc (value_relation::set_relation): Remove assert.
(path_oracle::register_relation): Exit when trying to register
same SSA name relations.
---
 gcc/value-relation.cc | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/gcc/value-relation.cc b/gcc/value-relation.cc
index bd344253af3..a447021214f 100644
--- a/gcc/value-relation.cc
+++ b/gcc/value-relation.cc
@@ -667,8 +667,6 @@ private:
 inline void
 value_relation::set_relation (relation_kind r, tree n1, tree n2)
 {
-  gcc_checking_assert (SSA_NAME_VERSION (n1) != SSA_NAME_VERSION (n2)
-  || r == VREL_EQ);
   related = r;
   name1 = n1;
   name2 = n2;
@@ -1449,6 +1447,11 @@ void
 path_oracle::register_relation (basic_block bb, relation_kind k, tree ssa1,
tree ssa2)
 {
+  // If the 2 ssa_names are the same, do nothing.  An equivalence is implied,
+  // and no other relation makes sense.
+  if (ssa1 == ssa2)
+return;
+
   if (dump_file && (dump_flags & TDF_DETAILS))
 {
   value_relation vr (k, ssa1, ssa2);
-- 
2.36.1

[COMMITTED] Minor fixes to vr_values to not die on non integral types.

[Aldy Hernandez via Gcc-patches]

The legacy code in vr_values mostly works on integral types (with few
exceptions such as some conversions from float).  This patch makes
vr_values::range_of_expr not die when asked for a range of an
unsupported type.  It also keeps the min/max simplification code from
being called on non integrals, similarly to what many of the other
assignment code is doing.

This is all a nop on the current code, but will keep us from
misbehaving when VRP starts working on non-integrals.

Tested on x86-64 Linux.

gcc/ChangeLog:

* value-query.cc (range_query::get_value_range): Add assert.
* vr-values.cc (vr_values::range_of_expr): Make sure we don't ICE
on unsupported types in vr_values.
(simplify_using_ranges::simplify): Same.
---
 gcc/value-query.cc |  1 +
 gcc/vr-values.cc   | 15 ++-
 2 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/gcc/value-query.cc b/gcc/value-query.cc
index 3560d19f1ae..decf5aae1fe 100644
--- a/gcc/value-query.cc
+++ b/gcc/value-query.cc
@@ -167,6 +167,7 @@ range_query::free_value_range_equiv (value_range_equiv *v)
 const class value_range_equiv *
 range_query::get_value_range (const_tree expr, gimple *stmt)
 {
+  gcc_checking_assert (value_range_equiv::supports_p (TREE_TYPE (expr)));
   int_range_max r;
   if (range_of_expr (r, const_cast (expr), stmt))
 return new (equiv_alloc->allocate ()) value_range_equiv (r);
diff --git a/gcc/vr-values.cc b/gcc/vr-values.cc
index 6b9c630fed3..626a9189472 100644
--- a/gcc/vr-values.cc
+++ b/gcc/vr-values.cc
@@ -188,6 +188,17 @@ vr_values::range_of_expr (vrange &r, tree expr, gimple 
*stmt)
r = *vr;
   else
{
+ if (!vr->supports_type_p (TREE_TYPE (expr)))
+   {
+ // vr_values::extract_range_basic() use of ranger's
+ // fold_range() can create a situation where we are
+ // asked for the range of an unsupported legacy type.
+ // Since get_value_range() above will return varying for
+ // such types, avoid copying incompatible range types.
+ gcc_checking_assert (vr->varying_p ());
+ r.set_varying (TREE_TYPE (expr));
+ return true;
+   }
  value_range tmp = *vr;
  tmp.normalize_symbolics ();
  r = tmp;
@@ -4375,7 +4386,9 @@ simplify_using_ranges::simplify (gimple_stmt_iterator 
*gsi)
 
case MIN_EXPR:
case MAX_EXPR:
- return simplify_min_or_max_using_ranges (gsi, stmt);
+ if (INTEGRAL_TYPE_P (TREE_TYPE (rhs1)))
+   return simplify_min_or_max_using_ranges (gsi, stmt);
+ break;
 
case RSHIFT_EXPR:
  {
-- 
2.36.1

[COMMITTED] Tweaks to global ranges.

[Aldy Hernandez via Gcc-patches]

The global get_nonzero_bits was previously returning -1 for
unsupported types.  I dropped this in the conversion to global ranges
and it's causing a problem in the frange work, where CCP is asking for
the nonzero bits of non-integral types.  CCP may require further
tweaks, but for now, restore the original behavior.

Also, I'm removing old checks for precision that no longer hold, now
that we handle various types for global ranges.

Tested on x86-64 Linux.

gcc/ChangeLog:

* tree-ssanames.cc (get_nonzero_bits): Return -1 for unsupported
types.
* value-query.cc (get_ssa_name_range_info): Remove precision check.
---
 gcc/tree-ssanames.cc | 3 +--
 gcc/value-query.cc   | 9 +++--
 2 files changed, 4 insertions(+), 8 deletions(-)

diff --git a/gcc/tree-ssanames.cc b/gcc/tree-ssanames.cc
index 9389454a5a7..5c5d0e346c4 100644
--- a/gcc/tree-ssanames.cc
+++ b/gcc/tree-ssanames.cc
@@ -489,13 +489,12 @@ get_nonzero_bits (const_tree name)
   return wi::shwi (-1, precision);
 }
 
-  if (!range_info_p (name))
+  if (!range_info_p (name) || !irange::supports_p (TREE_TYPE (name)))
 return wi::shwi (-1, precision);
 
   /* Optimization to get at the nonzero bits because we know the
  storage type.  This saves us measurable time compared to going
  through vrange_storage.  */
-  gcc_checking_assert (irange::supports_p (TREE_TYPE (name)));
   irange_storage_slot *ri
 = static_cast  (SSA_NAME_RANGE_INFO (name));
   return ri->get_nonzero_bits ();
diff --git a/gcc/value-query.cc b/gcc/value-query.cc
index 51911bdd1d0..3560d19f1ae 100644
--- a/gcc/value-query.cc
+++ b/gcc/value-query.cc
@@ -280,16 +280,13 @@ get_ssa_name_range_info (vrange &r, const_tree name)
 
   void *ri = SSA_NAME_RANGE_INFO (name);
 
-  // Return VR_VARYING for SSA_NAMEs with NULL RANGE_INFO or SSA_NAMEs
-  // with integral types width > 2 * HOST_BITS_PER_WIDE_INT precision.
-  if (!ri || (GET_MODE_PRECISION (SCALAR_INT_TYPE_MODE (TREE_TYPE (name)))
- > 2 * HOST_BITS_PER_WIDE_INT))
-r.set_varying (type);
-  else
+  if (ri)
 {
   vrange_storage vstore (NULL);
   vstore.get_vrange (ri, r, TREE_TYPE (name));
 }
+  else
+r.set_varying (type);
 }
 
 // Return nonnull attribute of pointer NAME from SSA_NAME_PTR_INFO.
-- 
2.36.1

[COMMITTED] Convert some uses in ranger_cache and DOM to vrange.

[Aldy Hernandez via Gcc-patches]

Here are a few conversions to type agnostic vrange I found while
working on frange.

Tested on x86-64 Linux.

gcc/ChangeLog:

* gimple-range-cache.cc (ranger_cache::edge_range): Convert to vrange.
(ranger_cache::range_from_dom): Same.
* tree-ssa-dom.cc
(dom_opt_dom_walker::set_global_ranges_from_unreachable_edges): Same.
---
 gcc/gimple-range-cache.cc |  7 ---
 gcc/tree-ssa-dom.cc   | 18 ++
 2 files changed, 14 insertions(+), 11 deletions(-)

diff --git a/gcc/gimple-range-cache.cc b/gcc/gimple-range-cache.cc
index f3292fccaee..d9e160c9a2a 100644
--- a/gcc/gimple-range-cache.cc
+++ b/gcc/gimple-range-cache.cc
@@ -960,7 +960,7 @@ ranger_cache::edge_range (vrange &r, edge e, tree name, 
enum rfd_mode mode)
   // If this is not an abnormal edge, check for inferred ranges on exit.
   if ((e->flags & (EDGE_EH | EDGE_ABNORMAL)) == 0)
 m_exit.maybe_adjust_range (r, name, e->src);
-  int_range_max er;
+  Value_Range er (TREE_TYPE (name));
   if (m_gori.outgoing_edge_range_p (er, e, name, *this))
 r.intersect (er);
   return true;
@@ -1364,7 +1364,8 @@ ranger_cache::range_from_dom (vrange &r, tree name, 
basic_block start_bb,
   basic_block prev_bb = start_bb;
 
   // Track any inferred ranges seen.
-  int_range_max infer (TREE_TYPE (name));
+  Value_Range infer (TREE_TYPE (name));
+  infer.set_varying (TREE_TYPE (name));
 
   // Range on entry to the DEF block should not be queried.
   gcc_checking_assert (start_bb != def_bb);
@@ -1431,7 +1432,7 @@ ranger_cache::range_from_dom (vrange &r, tree name, 
basic_block start_bb,
   // Now process any blocks wit incoming edges that nay have adjustemnts.
   while (m_workback.length () > start_limit)
 {
-  int_range_max er;
+  Value_Range er (TREE_TYPE (name));
   prev_bb = m_workback.pop ();
   if (!single_pred_p (prev_bb))
{
diff --git a/gcc/tree-ssa-dom.cc b/gcc/tree-ssa-dom.cc
index f5e8f574997..44dc27b464c 100644
--- a/gcc/tree-ssa-dom.cc
+++ b/gcc/tree-ssa-dom.cc
@@ -1233,20 +1233,22 @@ 
dom_opt_dom_walker::set_global_ranges_from_unreachable_edges (basic_block bb)
 
   gimple *stmt = last_stmt (pred_e->src);
   tree name;
-  int_range_max r;
   if (stmt
   && gimple_code (stmt) == GIMPLE_COND
   && (name = gimple_cond_lhs (stmt))
   && TREE_CODE (name) == SSA_NAME
-  && r.supports_type_p (TREE_TYPE (name))
   && assert_unreachable_fallthru_edge_p (pred_e)
-  && all_uses_feed_or_dominated_by_stmt (name, stmt)
-  && m_ranger->range_on_edge (r, pred_e, name)
-  && !r.varying_p ()
-  && !r.undefined_p ())
+  && all_uses_feed_or_dominated_by_stmt (name, stmt))
 {
-  set_range_info (name, r);
-  maybe_set_nonzero_bits (pred_e, name);
+  Value_Range r (TREE_TYPE (name));
+
+  if (m_ranger->range_on_edge (r, pred_e, name)
+ && !r.varying_p ()
+ && !r.undefined_p ())
+   {
+ set_range_info (name, r);
+ maybe_set_nonzero_bits (pred_e, name);
+   }
 }
 }
 
-- 
2.36.1

[PATCH, rs6000] Add multiply-add expand pattern [PR103109]

[HAO CHEN GUI via Gcc-patches]

Hi,
  This patch adds an expand and several insns for multiply-add with
three 64bit operands.

  Bootstrapped and tested on powerpc64-linux BE and LE with no regressions.
Is this okay for trunk? Any recommendations? Thanks a lot.

ChangeLog
2022-07-22  Haochen Gui  

gcc/
PR target/103109
* config/rs6000/rs6000.md (maddditi4): New pattern for
multiply-add.
(madddi4_lowpart): New.
(madddi4_lowpart_le): New.
(madddi4_highpart): New.
(madddi4_highpart_le): New.

gcc/testsuite/
PR target/103109
* gcc.target/powerpc/pr103109.c: New.

patch.diff
diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md
index c55ee7e171a..4f3b56e103e 100644
--- a/gcc/config/rs6000/rs6000.md
+++ b/gcc/config/rs6000/rs6000.md
@@ -3226,6 +3226,97 @@ (define_insn "*maddld4"
   "maddld %0,%1,%2,%3"
   [(set_attr "type" "mul")])

+(define_expand "maddditi4"
+  [(set (match_operand:TI 0 "gpc_reg_operand")
+   (plus:TI
+ (mult:TI (any_extend:TI
+(match_operand:DI 1 "gpc_reg_operand"))
+  (any_extend:TI
+(match_operand:DI 2 "gpc_reg_operand")))
+ (any_extend:TI
+   (match_operand:DI 3 "gpc_reg_operand"]
+  "TARGET_POWERPC64 && TARGET_MADDLD"
+{
+  rtx op0_lo = gen_rtx_SUBREG (DImode, operands[0], BYTES_BIG_ENDIAN ? 8 : 0);
+  rtx op0_hi = gen_rtx_SUBREG (DImode, operands[0], BYTES_BIG_ENDIAN ? 0 : 8);
+
+  if (BYTES_BIG_ENDIAN)
+{
+  emit_insn (gen_madddi4_lowpart (op0_lo, operands[1], operands[2],
+operands[3]));
+  emit_insn (gen_madddi4_highpart (op0_hi, operands[1], operands[2],
+ operands[3]));
+}
+  else
+{
+  emit_insn (gen_madddi4_lowpart_le (op0_lo, operands[1], operands[2],
+   operands[3]));
+  emit_insn (gen_madddi4_highpart_le (op0_hi, operands[1], operands[2],
+operands[3]));
+}
+  DONE;
+})
+
+(define_insn "madddi4_lowpart"
+  [(set (match_operand:DI 0 "gpc_reg_operand" "=r")
+   (subreg:DI
+ (plus:TI
+   (mult:TI (any_extend:TI
+  (match_operand:DI 1 "gpc_reg_operand" "r"))
+(any_extend:TI
+  (match_operand:DI 2 "gpc_reg_operand" "r")))
+   (any_extend:TI
+ (match_operand:DI 3 "gpc_reg_operand" "r")))
+8))]
+  "TARGET_POWERPC64 && TARGET_MADDLD && BYTES_BIG_ENDIAN"
+  "maddld %0,%1,%2,%3"
+  [(set_attr "type" "mul")])
+
+(define_insn "madddi4_lowpart_le"
+  [(set (match_operand:DI 0 "gpc_reg_operand" "=r")
+   (subreg:DI
+ (plus:TI
+   (mult:TI (any_extend:TI
+  (match_operand:DI 1 "gpc_reg_operand" "r"))
+(any_extend:TI
+  (match_operand:DI 2 "gpc_reg_operand" "r")))
+   (any_extend:TI
+ (match_operand:DI 3 "gpc_reg_operand" "r")))
+0))]
+  "TARGET_POWERPC64 && TARGET_MADDLD && !BYTES_BIG_ENDIAN"
+  "maddld %0,%1,%2,%3"
+  [(set_attr "type" "mul")])
+
+(define_insn "madddi4_highpart"
+  [(set (match_operand:DI 0 "gpc_reg_operand" "=r")
+   (subreg:DI
+ (plus:TI
+   (mult:TI (any_extend:TI
+  (match_operand:DI 1 "gpc_reg_operand" "r"))
+(any_extend:TI
+  (match_operand:DI 2 "gpc_reg_operand" "r")))
+   (any_extend:TI
+ (match_operand:DI 3 "gpc_reg_operand" "r")))
+0))]
+  "TARGET_POWERPC64 && TARGET_MADDLD && BYTES_BIG_ENDIAN"
+  "maddhd %0,%1,%2,%3"
+  [(set_attr "type" "mul")])
+
+(define_insn "madddi4_highpart_le"
+  [(set (match_operand:DI 0 "gpc_reg_operand" "=r")
+   (subreg:DI
+ (plus:TI
+   (mult:TI (any_extend:TI
+  (match_operand:DI 1 "gpc_reg_operand" "r"))
+(any_extend:TI
+  (match_operand:DI 2 "gpc_reg_operand" "r")))
+   (any_extend:TI
+ (match_operand:DI 3 "gpc_reg_operand" "r")))
+8))]
+  "TARGET_POWERPC64 && TARGET_MADDLD && !BYTES_BIG_ENDIAN"
+  "maddhd %0,%1,%2,%3"
+  [(set_attr "type" "mul")])
+
 (define_insn "udiv3"
   [(set (match_operand:GPR 0 "gpc_reg_operand" "=r")
 (udiv:GPR (match_operand:GPR 1 "gpc_reg_operand" "r")
diff --git a/gcc/testsuite/gcc.target/powerpc/pr103109.c 
b/gcc/testsuite/gcc.target/powerpc/pr103109.c
new file mode 100644
index 000..256e05d5677
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/pr103109.c
@@ -0,0 +1,16 @@
+/* { dg-do compile { target { lp64 } } } */
+/* { dg-require-effective-target powerpc_p9modulo_ok } */
+/* { dg-options "-mdejagnu-cpu=power9 -O2" } */
+/* { dg-final { scan-assembler-times {\mmaddld\M} 2 } } */
+/* { dg-final { scan-assembler-times {\mmaddhd\M} 1 } } */
+/* { dg-final { scan-assembler-times {\mmaddhdu\M} 1 } } */
+
+__int128 test (long a, 

Re: [PATCH 1/2] Allow subtarget customization of CC1_SPEC

[Sebastian Huber]

Hallo Jose,

On 22/07/2022 16:02, Jose E. Marchesi wrote:

I find "subtarget" confusing in this context.

If it is about rtems.h, linux.h or sol2.h, wouldn't this be better
called OS_CC1_SPEC or similar?  These files specify configurations that
apply to a set of targets, not to a subset of a target...


Iain Sandoe told me that for the GCC implementation the OSs are 
sub-targets of the architecture:


https://gcc.gnu.org/pipermail/gcc/2022-July/239158.html

--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/

Re: [PATCH 1/2] Allow subtarget customization of CC1_SPEC

[Iain Sandoe via Gcc-patches]

Hi Sebastian,

> On 25 Jul 2022, at 06:59, Sebastian Huber 
>  wrote:

> On 22/07/2022 16:02, Jose E. Marchesi wrote:
>> I find "subtarget" confusing in this context.
>> If it is about rtems.h, linux.h or sol2.h, wouldn't this be better
>> called OS_CC1_SPEC or similar?  These files specify configurations that
>> apply to a set of targets, not to a subset of a target...
> 
> Iain Sandoe told me that for the GCC implementation the OSs are sub-targets 
> of the architecture:
> 
> https://gcc.gnu.org/pipermail/gcc/2022-July/239158.html

There is, however, a precedent for the SUBTARGET_ use, however, I agree with 
Jose that it is somewhat confusing - since (as mentioned before) to the OS the 
arches are the sub-targets, so maybe OS_xxx would be more clear.

Perhaps Joseph (CC-d) would weigh in here.

Iain

Re: [PATCH] rs6000/test: Update some cases with -mdejagnu-tune

[Kewen.Lin via Gcc-patches]

Hi Peter and Segher,

on 2022/7/23 03:28, Peter Bergner wrote:
> On 7/22/22 1:53 PM, Peter Bergner wrote:
>> So I think the way the code above *should* work is:
>>   1) Any -mdejagnu-cpu= usage should filter out all -mcpu= and -mtune= 
>> options.
>>   2) Any -mdejagnu-tune= usage should filter all -mtune= options.
>>  It should not filter out any -mcpu= options.
> 
> Like this:
> 
> diff --git a/gcc/config/rs6000/rs6000.h b/gcc/config/rs6000/rs6000.h
> index 3b8941a8658..26874943795 100644
> --- a/gcc/config/rs6000/rs6000.h
> +++ b/gcc/config/rs6000/rs6000.h
> @@ -86,7 +86,7 @@
> RUNTESTFLAGS override those set in the testcases; with this option,
> the testcase will always win.  Ditto for -mdejagnu-tune=.  */
>  #define DRIVER_SELF_SPECS \
> -  "%{mdejagnu-cpu=*: % +  "%{mdejagnu-cpu=*: %"%{mdejagnu-tune=*: %"%{mdejagnu-*: % SUBTARGET_DRIVER_SELF_SPECS
> 
> 
> Kewen, can you see if the above patch fixes the issues you're seeing?
> 

Thanks for the insightful comments and patch!

I confirmed that this proposed patch can fix those found test issues.

I adjusted the relevant comments and confirmed that it can be bootstrapped and
regtested on powerpc64-linux-gnu P7 and P8 and powerpc64le-linux-gnu P9 and P10.

Segher pre-approved it, I just committed it as r13-1818 as attached.

Will backport it to release branches in a week or so.  Thanks again.

BR,
KewenFrom 75d20d6c84c12bedd65a904e462f02f0b9eb3f77 Mon Sep 17 00:00:00 2001
From: Peter Bergner 
Date: Mon, 25 Jul 2022 00:51:44 -0500
Subject: [PATCH] rs6000: Adjust -mdejagnu-cpu to filter out -mtune [PR106345]

As PR106345 shows, when configuring compiler with an explicit
option --with-tune=, it would cause some test cases to
fail if their test points are sensitive to tune setting, such
as: group_ending_nop, loop align etc.  It doesn't help that
even to specify one explicit -mcpu=.

This patch is to adjust the behavior of -mdejagnu-cpu by
filtering out all -mcpu= and -mtune= options, then test cases
would use  as tune as the one specified by -mdejagnu-cpu.

2022-07-25  Peter Bergner  
Kewen Lin  

PR testsuite/106345

gcc/ChangeLog:

* config/rs6000/rs6000.h (DRIVER_SELF_SPECS): Adjust -mdejagnu-cpu
to filter out all -mtune options.
---
 gcc/config/rs6000/rs6000.h | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/gcc/config/rs6000/rs6000.h b/gcc/config/rs6000/rs6000.h
index 7d04556304a..ad9bf0f7358 100644
--- a/gcc/config/rs6000/rs6000.h
+++ b/gcc/config/rs6000/rs6000.h
@@ -81,12 +81,15 @@
 # define SUBTARGET_DRIVER_SELF_SPECS ""
 #endif
 
-/* Only for use in the testsuite: -mdejagnu-cpu= simply overrides -mcpu=.
+/* Only for use in the testsuite: -mdejagnu-cpu= filters out all
+   -mcpu= as well as -mtune= options then simply adds -mcpu=,
+   while -mdejagnu-tune= filters out all -mtune= options then
+   simply adds -mtune=.
With older versions of Dejagnu the command line arguments you set in
-   RUNTESTFLAGS override those set in the testcases; with this option,
-   the testcase will always win.  Ditto for -mdejagnu-tune=.  */
+   RUNTESTFLAGS override those set in the testcases; with these options,
+   the testcase will always win.  */
 #define DRIVER_SELF_SPECS \
-  "%{mdejagnu-cpu=*: %

[PATCH v2] rs6000/test: Fix empty TU in some cases of effective targets [PR106345]

[Kewen.Lin via Gcc-patches]

Hi,

As the failure of test case gcc.target/powerpc/pr92398.p9-.c in
PR106345 shows, some test sources for some powerpc effective
targets use empty translation unit wrongly.  The test sources
could go with options like "-ansi -pedantic-errors", then those
effective target checkings will fail unexpectedly with the
error messages like:

  error: ISO C forbids an empty translation unit [-Wpedantic]

This patch is to fix empty TUs with one dummy function definition
accordingly.

Excepting for the failures on gcc.target/powerpc/pr92398.p9-.c
fixed, I can see it helps to bring back some testing coverage like:

NA->PASS: gcc.target/powerpc/pr92398.p9+.c
NA->PASS: gcc.target/powerpc/pr93453-1.c

Tested as before.

v1: https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598602.html
v2: Use dummy function instead of dummy int as Segher suggested.

Segher, does this v2 look good to you?

BR,
Kewen
-
PR testsuite/106345

gcc/testsuite/ChangeLog:

* lib/target-supports.exp (check_effective_target_powerpc_sqrt): Add
a function definition to avoid pedwarn about empty translation unit.
(check_effective_target_has_arch_pwr5): Likewise.
(check_effective_target_has_arch_pwr6): Likewise.
(check_effective_target_has_arch_pwr7): Likewise.
(check_effective_target_has_arch_pwr8): Likewise.
(check_effective_target_has_arch_pwr9): Likewise.
(check_effective_target_has_arch_pwr10): Likewise.
(check_effective_target_has_arch_ppc64): Likewise.
(check_effective_target_ppc_float128): Likewise.
(check_effective_target_ppc_float128_insns): Likewise.
(check_effective_target_powerpc_vsx): Likewise.
---
 gcc/testsuite/lib/target-supports.exp | 33 +++
 1 file changed, 33 insertions(+)

diff --git a/gcc/testsuite/lib/target-supports.exp 
b/gcc/testsuite/lib/target-supports.exp
index 4ed7b25b9a4..06484330178 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -6259,9 +6259,12 @@ proc check_effective_target_powerpc_sqrt { } {
 }

 return [check_no_compiler_messages powerpc_sqrt object {
+   void test (void)
+   {
#ifndef _ARCH_PPCSQ
#error _ARCH_PPCSQ is not defined
#endif
+   }
 } {}]
 }

@@ -6369,71 +6372,92 @@ proc check_effective_target_powerpc_p9modulo_ok { } {
 # as provided by the test.
 proc check_effective_target_has_arch_pwr5 { } {
return [check_no_compiler_messages_nocache arch_pwr5 assembly {
+   void test (void)
+   {
#ifndef _ARCH_PWR5
#error does not have power5 support.
#else
/* "has power5 support" */
#endif
+   }
} [current_compiler_flags]]
 }

 proc check_effective_target_has_arch_pwr6 { } {
return [check_no_compiler_messages_nocache arch_pwr6 assembly {
+   void test (void)
+   {
#ifndef _ARCH_PWR6
#error does not have power6 support.
#else
/* "has power6 support" */
#endif
+   }
} [current_compiler_flags]]
 }

 proc check_effective_target_has_arch_pwr7 { } {
return [check_no_compiler_messages_nocache arch_pwr7 assembly {
+   void test (void)
+   {
#ifndef _ARCH_PWR7
#error does not have power7 support.
#else
/* "has power7 support" */
#endif
+   }
} [current_compiler_flags]]
 }

 proc check_effective_target_has_arch_pwr8 { } {
return [check_no_compiler_messages_nocache arch_pwr8 assembly {
+   void test (void)
+   {
#ifndef _ARCH_PWR8
#error does not have power8 support.
#else
/* "has power8 support" */
#endif
+   }
} [current_compiler_flags]]
 }

 proc check_effective_target_has_arch_pwr9 { } {
return [check_no_compiler_messages_nocache arch_pwr9 assembly {
+   void test (void)
+   {
#ifndef _ARCH_PWR9
#error does not have power9 support.
#else
/* "has power9 support" */
#endif
+   }
} [current_compiler_flags]]
 }

 proc check_effective_target_has_arch_pwr10 { } {
return [check_no_compiler_messages_nocache arch_pwr10 assembly {
+   void test (void)
+   {
#ifndef _ARCH_PWR10
#error does not have power10 support.
#else
/* "has power10 support" */
#endif
+   }
} [current_compiler_flags]]
 }

 proc check_effective_target_has_arch_ppc64 { } {
return [check_no_compiler_messages_nocache arch_ppc64 assembly {
+   

[PATCH] analyzer: fix coding style in sm-fd.cc

[Martin Liška]

Hi.

First, thanks Mir for your contribution. The following patch addresses
coding style issues I let you know in:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106003#c3

Most notably, I converted Windows endlines to Unix style, replace 8 spaces with 
tabs
and removed trailing whitespaces.

Please consider using our script that verifies that:
git show f8e6e2c046e1015697356ee7079fb39e0cb6add5 > diff && 
./contrib/check_GNU_style.py diff

Ready to be installed?
Thanks,
Martin


gcc/analyzer/ChangeLog:

* sm-fd.cc: Run dos2unix and fix coding style issues.
---
 gcc/analyzer/sm-fd.cc | 2114 -
 1 file changed, 1057 insertions(+), 1057 deletions(-)

diff --git a/gcc/analyzer/sm-fd.cc b/gcc/analyzer/sm-fd.cc
index c3dac48509e..56b0063ba42 100644
--- a/gcc/analyzer/sm-fd.cc
+++ b/gcc/analyzer/sm-fd.cc
@@ -1,1057 +1,1057 @@
-/* A state machine for detecting misuses of POSIX file descriptor APIs.
-   Copyright (C) 2019-2022 Free Software Foundation, Inc.
-   Contributed by Immad Mir .
-
-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
-.  */
-
-#include "config.h"
-#include "system.h"
-#include "coretypes.h"
-#include "tree.h"
-#include "function.h"
-#include "basic-block.h"
-#include "gimple.h"
-#include "options.h"
-#include "diagnostic-path.h"
-#include "diagnostic-metadata.h"
-#include "function.h"
-#include "json.h"
-#include "analyzer/analyzer.h"
-#include "diagnostic-event-id.h"
-#include "analyzer/analyzer-logging.h"
-#include "analyzer/sm.h"
-#include "analyzer/pending-diagnostic.h"
-#include "analyzer/function-set.h"
-#include "analyzer/analyzer-selftests.h"
-#include "tristate.h"
-#include "selftest.h"
-#include "stringpool.h"
-#include "attribs.h"
-#include "analyzer/call-string.h"
-#include "analyzer/program-point.h"
-#include "analyzer/store.h"
-#include "analyzer/region-model.h"
-#include "bitmap.h"
-
-#if ENABLE_ANALYZER
-
-namespace ana {
-
-namespace {
-
-/* An enum for distinguishing between three different access modes. */
-
-enum access_mode
-{
-  READ_WRITE,
-  READ_ONLY,
-  WRITE_ONLY
-};
-
-enum access_directions
-{
-  DIRS_READ_WRITE,
-  DIRS_READ,
-  DIRS_WRITE
-};
-
-class fd_state_machine : public state_machine
-{
-public:
-  fd_state_machine (logger *logger);
-
-  bool
-  inherited_state_p () const final override
-  {
-return false;
-  }
-
-  state_machine::state_t
-  get_default_state (const svalue *sval) const final override
-  {
-if (tree cst = sval->maybe_get_constant ())
-  {
-if (TREE_CODE (cst) == INTEGER_CST)
-  {
-int val = TREE_INT_CST_LOW (cst);
-if (val >= 0)
-  return m_constant_fd;
-else
-  return m_invalid;
-  }
-  }
-return m_start;
-  }
-
-  bool on_stmt (sm_context *sm_ctxt, const supernode *node,
-const gimple *stmt) const final override;
-
-  void on_condition (sm_context *sm_ctxt, const supernode *node,
- const gimple *stmt, const svalue *lhs, const tree_code op,
- const svalue *rhs) const final override;
-
-  bool can_purge_p (state_t s) const final override;
-  pending_diagnostic *on_leak (tree var) const final override;
-
-  bool is_unchecked_fd_p (state_t s) const;
-  bool is_valid_fd_p (state_t s) const;
-  bool is_closed_fd_p (state_t s) const;
-  bool is_constant_fd_p (state_t s) const;
-  bool is_readonly_fd_p (state_t s) const;
-  bool is_writeonly_fd_p (state_t s) const;
-  enum access_mode get_access_mode_from_flag (int flag) const;
-
-  /* State for a constant file descriptor (>= 0) */
-  state_t m_constant_fd;
-
-  /* States representing a file descriptor that hasn't yet been
-checked for validity after opening, for three different
-access modes.  */
-  state_t m_unchecked_read_write;
-
-  state_t m_unchecked_read_only;
-
-  state_t m_unchecked_write_only;
-
-  /* States for representing a file descriptor that is known to be valid (>=
-0), for three different access modes.*/
-  state_t m_valid_read_write;
-
-  state_t m_valid_read_only;
-
-  state_t m_valid_write_only;
-
-  /* State for a file descriptor that is known to be invalid (< 0). */
-  state_t m_invalid;
-
-  /* State for a file descriptor that has been closed.*/
-  state_t m_closed;
-
-  /* State for a file descriptor that we do not want to track anymore . */
-  state_t m_stop;
-
-private:
-  void on_open (s

[PATCH] analyzer: convert tests with dos2unix

[Martin Liška]

Ready for master?
Thanks,
Martin

gcc/testsuite/ChangeLog:

* gcc.dg/analyzer/fd-2.c: Convert Windows endlines to Unix
style.
* gcc.dg/analyzer/fd-3.c: Likewise.
* gcc.dg/analyzer/fd-4.c: Likewise.
* gcc.dg/analyzer/fd-5.c: Likewise.
* c-c++-common/attr-fd.c: Likewise.
---
 gcc/testsuite/c-c++-common/attr-fd.c |  36 +++---
 gcc/testsuite/gcc.dg/analyzer/fd-2.c |  96 +++
 gcc/testsuite/gcc.dg/analyzer/fd-3.c | 168 +--
 gcc/testsuite/gcc.dg/analyzer/fd-4.c | 142 +++---
 gcc/testsuite/gcc.dg/analyzer/fd-5.c | 104 -
 5 files changed, 273 insertions(+), 273 deletions(-)

diff --git a/gcc/testsuite/c-c++-common/attr-fd.c 
b/gcc/testsuite/c-c++-common/attr-fd.c
index e4bb4ed0374..9f12093c04f 100644
--- a/gcc/testsuite/c-c++-common/attr-fd.c
+++ b/gcc/testsuite/c-c++-common/attr-fd.c
@@ -1,18 +1,18 @@
-
-int not_a_fn __attribute__ ((fd_arg(1))); /* { dg-warning "'fd_arg' attribute 
only applies to function types" } */
-
-void f (char *p) __attribute__ ((fd_arg(1))); /* { dg-warning "'fd_arg' 
attribute argument value '1' refers to parameter type 'char ?\\\*'" } */
-
-
-int not_a_fn_b __attribute__ ((fd_arg_read(1))); /* { dg-warning 
"'fd_arg_read' attribute only applies to function types" } */
-
-void g (char *p) __attribute__ ((fd_arg_read(1))); /* { dg-warning 
"'fd_arg_read' attribute argument value '1' refers to parameter type 'char 
?\\\*'" } */
-
-
-int not_a_fn_c __attribute__ ((fd_arg_write(1))); /* { dg-warning 
"'fd_arg_write' attribute only applies to function types" } */
-
-void f (char *p) __attribute__ ((fd_arg_write(1))); /* { dg-warning 
"'fd_arg_write' attribute argument value '1' refers to parameter type 'char 
?\\\*'" } */
-
-
-void fn_a (int fd) __attribute__ ((fd_arg(0))); /* { dg-warning "'fd_arg' 
attribute argument value '0' does not refer to a function parameter" } */
-void fd_a_1 (int fd) __attribute__ ((fd_arg("notint"))); /* { dg-warning 
"'fd_arg' attribute argument has type ('char\\\[7\\\]'|'const char\\\*')" } */
+
+int not_a_fn __attribute__ ((fd_arg(1))); /* { dg-warning "'fd_arg' attribute 
only applies to function types" } */
+
+void f (char *p) __attribute__ ((fd_arg(1))); /* { dg-warning "'fd_arg' 
attribute argument value '1' refers to parameter type 'char ?\\\*'" } */
+
+
+int not_a_fn_b __attribute__ ((fd_arg_read(1))); /* { dg-warning 
"'fd_arg_read' attribute only applies to function types" } */
+
+void g (char *p) __attribute__ ((fd_arg_read(1))); /* { dg-warning 
"'fd_arg_read' attribute argument value '1' refers to parameter type 'char 
?\\\*'" } */
+
+
+int not_a_fn_c __attribute__ ((fd_arg_write(1))); /* { dg-warning 
"'fd_arg_write' attribute only applies to function types" } */
+
+void f (char *p) __attribute__ ((fd_arg_write(1))); /* { dg-warning 
"'fd_arg_write' attribute argument value '1' refers to parameter type 'char 
?\\\*'" } */
+
+
+void fn_a (int fd) __attribute__ ((fd_arg(0))); /* { dg-warning "'fd_arg' 
attribute argument value '0' does not refer to a function parameter" } */
+void fd_a_1 (int fd) __attribute__ ((fd_arg("notint"))); /* { dg-warning 
"'fd_arg' attribute argument has type ('char\\\[7\\\]'|'const char\\\*')" } */
diff --git a/gcc/testsuite/gcc.dg/analyzer/fd-2.c 
b/gcc/testsuite/gcc.dg/analyzer/fd-2.c
index 96ccf2f7ba8..d794b460a2e 100644
--- a/gcc/testsuite/gcc.dg/analyzer/fd-2.c
+++ b/gcc/testsuite/gcc.dg/analyzer/fd-2.c
@@ -1,49 +1,49 @@
-int open(const char *, int mode);
-void close(int fd);
-#define O_RDONLY 0
-#define O_WRONLY 1
-#define O_RDWR 2
-#define STDIN 0
-
-void 
-test_1 (const char *path)
-{
-int fd = open (path, O_RDWR); /* { dg-message "\\(1\\) opened here" } */
-close (fd); /* { dg-message "\\(2\\) first 'close' here" "event1" } */
-close (fd); /* { dg-warning "double 'close' of file descriptor 'fd' 
\\\[CWE-1341\\\]" "warning" } */
-/* { dg-message "\\(3\\) second 'close' here; first 'close' was at 
\\(2\\)" "event2" { target *-*-* } .-1 } */
-}
-
-void 
-test_2 (const char *path)
-{
-int fd = open (path, O_RDWR); /* { dg-message "\\(1\\) opened here" } */
-if (fd < 0) /* { dg-message "\\(2\\) assuming 'fd' is a valid file 
descriptor \\(>= 0\\)" "event1" } */
-/* { dg-message "\\(3\\) following 'false' branch \\(when 'fd >= 0'\\)..." 
"event2" { target *-*-* } .-1 } */
-return;
-close (fd); /* { dg-message "\\(4\\) ...to here" "event1" } */
-/* { dg-message "\\(5\\) first 'close' here" "event2" { target *-*-* } .-1 
} */
-close (fd); /* { dg-warning "double 'close' of file descriptor 'fd' 
\\\[CWE-1341\\\]" "warning" } */
-/* {dg-message "\\(6\\) second 'close' here; first was at \\(5\\)" "" { 
target *-*-* } .-1 } */
-}
-
-void
-test_3 ()
-{
-/* FD 0 is stdin at the entry to "main" and thus read-only, but we have no
-guarantees here that it hasn't been closed and then reopened for
-writing, so we can't issue a warning */
-
-int fd = 

[COMMITTED] frange class to represent floating point ranges

[Aldy Hernandez via Gcc-patches]

This implements a basic frange class to represent floating point
ranges.  Although it is meant to be a base for further development, it
is enough to handle relations and propagate NAN and other properties.

For ranger clients to become floating point aware, we still need the
range-op entries, which I will submit later this week.  Since those
entries require specialized FP knowledge, I will ask for a review from
the FP experts before committing.

Once range-op entries come live, all ranger clients that have been
converted to the type agnostic vrange API will become FP aware: evrp,
DOM, the threaders, loop-ch, etc.  (Still missing is loop unswitching,
as a lot of the int_range* temporaries should be Value_Range.  I don't
have enough cycles to convert loop unswitching, but could gladly give
guidance.  It should be straightforward for those familiar with the
code ;-)).

Samples things we handle:

* We can set the FP properties (!NAN, !INF, etc) at assignment from
  constants (and propagate them throughout the CFG):

  float z = 0.0;
  if (__builtin_isnan (z))
link_error ();

* The relation oracle works in tandem with the FP ranges:

  if (x > y)
   ;
  else if (!__builtin_isnan (x) && !__builtin_isnan (y))
   {
 // If x and y are not NAN, the x <= y relationship holds, and the
 // following conditional can be folded away.
 if (x <= y)
   bar ();
   }

* We know the true side of all ordered conditionals (except !=)
  implies !NAN:

  if (x > y)
{
  if (__builtin_isnan (x) || __builtin_isnan (y))
link_error ();
}

Range-ops also works correctly with -ffinite-math-only, and avoids
checking for NANs, etc.

I believe this is enough to get a fully fleshed out floating point
support for evrp and friends, but doing so is beyond my limited FP
knowledge.  For example, frange could be enhanced to track constant
endpoints, and we could track other FP properties aside from NAN.
Further discussion is gladly welcome.

Tested on x86-64 Linux.

gcc/ChangeLog:

* value-range-pretty-print.cc (vrange_printer::visit): New.
(vrange_printer::print_frange_prop): New.
* value-range-pretty-print.h (class vrange_printer): Add visit and
print_frange_prop.
* value-range-storage.h (vrange_allocator::alloc_vrange): Handle frange.
(vrange_allocator::alloc_frange): New.
* value-range.cc (vrange::operator=): Handle frange.
(vrange::operator==): Same.
(frange::accept): New.
(frange::set): New.
(frange::normalize_kind): New.
(frange::union_): New.
(frange::intersect): New.
(frange::operator=): New.
(frange::operator==): New.
(frange::supports_type_p): New.
(frange::verify_range): New.
* value-range.h (enum value_range_discriminator): Handle frange.
(class fp_prop): New.
(FP_PROP_ACCESSOR): New.
(class frange_props): New.
(FRANGE_PROP_ACCESSOR): New.
(class frange): New.
(Value_Range::init): Handle frange.
(Value_Range::operator=): Same.
(Value_Range::supports_type_p): Same.
(frange_props::operator==): New.
(frange_props::union_): New.
(frange_props::intersect): New
(frange::frange): New.
(frange::type): New.
(frange::set_varying): New.
(frange::set_undefined): New.
---
 gcc/value-range-pretty-print.cc |  41 +++
 gcc/value-range-pretty-print.h  |   2 +
 gcc/value-range-storage.h   |  27 -
 gcc/value-range.cc  | 195 +++-
 gcc/value-range.h   | 194 ++-
 5 files changed, 452 insertions(+), 7 deletions(-)

diff --git a/gcc/value-range-pretty-print.cc b/gcc/value-range-pretty-print.cc
index b795e92d8fb..485612fe67c 100644
--- a/gcc/value-range-pretty-print.cc
+++ b/gcc/value-range-pretty-print.cc
@@ -109,3 +109,44 @@ vrange_printer::print_irange_bitmasks (const irange &r) 
const
   print_hex (nz, buf);
   pp_string (pp, buf);
 }
+
+// Print an frange.
+
+void
+vrange_printer::visit (const frange &r) const
+{
+  pp_string (pp, "[frange] ");
+  if (r.undefined_p ())
+{
+  pp_string (pp, "UNDEFINED");
+  return;
+}
+  dump_generic_node (pp, r.type (), 0, TDF_NONE, false);
+  pp_string (pp, " ");
+  if (r.varying_p ())
+{
+  pp_string (pp, "VARYING");
+  return;
+}
+  print_frange_prop ("NAN", r.get_nan ());
+  print_frange_prop ("INF", r.get_inf ());
+  print_frange_prop ("NINF", r.get_ninf ());
+}
+
+// Print the FP properties in an frange.
+
+void
+vrange_printer::print_frange_prop (const char *str, const fp_prop &prop) const
+{
+  if (prop.varying_p ())
+return;
+
+  if (prop.yes_p ())
+pp_string (pp, str);
+  else if (prop.no_p ())
+{
+  pp_character (pp, '!');
+  pp_string (pp, str);
+}
+  pp_character (pp, ' ');
+}
diff --git a/gcc/value-range-pretty-print.h b/gcc/value

[PATCH] libsanitizer: Cherry-pick 2bfb0fcb51510f22723c8cdfefe from upstream

[Dimitrije Milosevic]

2bfb0fcb51510f22723c8cdfefe [Sanitizer][MIPS] Fix stat struct size for the O32 
ABI.

Signed-off-by: Dimitrije Milosevic .

---
 .../sanitizer_common/sanitizer_platform_limits_posix.h | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h 
b/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h
index 89772a7e5c0..75c6cc7f285 100644
--- a/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h
+++ b/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h
@@ -81,9 +81,10 @@ const unsigned struct_kernel_stat64_sz = 104;
 const unsigned struct_kernel_stat_sz = 144;
 const unsigned struct_kernel_stat64_sz = 104;
 #elif defined(__mips__)
-const unsigned struct_kernel_stat_sz = SANITIZER_ANDROID
-   ? FIRST_32_SECOND_64(104, 128)
-   : FIRST_32_SECOND_64(144, 216);
+const unsigned struct_kernel_stat_sz =
+SANITIZER_ANDROID
+? FIRST_32_SECOND_64(104, 128)
+: FIRST_32_SECOND_64((_MIPS_SIM == _ABIN32) ? 160 : 144, 216);
 const unsigned struct_kernel_stat64_sz = 104;
 #elif defined(__s390__) && !defined(__s390x__)
 const unsigned struct_kernel_stat_sz = 64;
-- 
2.25.1