Re: [PATCH] match.pd: Add ~(X - Y) -> ~X + Y simplification [PR96685]

[Maciej W. Rozycki]

On Mon, 21 Dec 2020, Jakub Jelinek wrote:

> > > This patch adds the ~(X - Y) -> ~X + Y simplification requested
> > > in the PR (plus also ~(X + C) -> ~X + (-C) for constants C that can
> > > be safely negated.
> > 
> >  This regresses VAX code produced by the cmpelim-eq-notsi.c test case (and 
> > its similar counterparts) with the `vax-netbsdelf' target.
> 
> The point of the match.pd changes is to canonicalize GIMPLE on some form
> when there are several from GIMPLE POV equivalent or better forms of writing
> the same thing.  The advantage of having one canonical way is that ICF,
> SCCVN etc. optimizations can then understand the different forms are
> equivalent.

 Fair enough, though in cases like this I think it is unclear which of the 
two forms is going to be ultimately better, especially as it may depend on 
the exact form of the operands used, e.g. values of any immediates, so I 
think a way to make the reverse transformation (whether to undo one made 
here or genuinely) needs to be available at a later compilation stage.  
One size doesn't fit all.

 With this in mind...

> If another form is then better for a particular machine, it should be done
> either during expansion (being able to produce both RTLs and computing their
> costs), or during combine with either combine splitters or
> define_insn_and_split in the backend, or, if it can't be done in RTL, during
> the isel pass.

 Hmm, maybe it has been discussed before, so please forgive me if I write 
something silly, but it seems to me like this should be done in a generic 
way like match.pd so that all the targets do not have to track the changes 
made there and then perhaps repeat the same or similar code each.  So I 
think it would make sense to make a change like this include that reverse 
transformation as well, so that ultimately both forms are tried with RTL, 
as there is no clear advantage to either here.

 However expand AFAICT essentially boils down to `expand_expr_real_2', 
which uses a bijective mapping between individual operations in the tree 
and the RTL form respectively rather than sequences as with the unary one 
complement and an addition/subtraction covered here, for two operations 
total.  So this cannot be done with expand, by design, unless I'm missing 
something.

 So from the look at combine code I infer the way to handle this within 
the existing infrastructure would be with `try_combine'/`find_split_point' 
(as we have one sequence of insns to be replaced with another sequence 
rather than combined into a single insn), right?

 Overall it seems to me it would be the best if we were able to produce a 
reverse RTL transformation automatically straight from match.pd, however I 
am not sure whether the syntax used is suitable for reverse interpretation 
in the general case.  And in any case this would be a major effort, but it 
would be hugely beneficial, as we have lots of knowledge already collected 
in match.pd.

 Have I missed anything here?

 NB I've seen it often enough already to irritate me that someone claims 
we ought to do something "because LLVM does it".  Well, if someone wants 
things done the LLVM way, then there's LLVM readily available.  If there 
is a technical advantage in doing something, then surely we ought to do 
that, however whether LLVM does it too or does not is I think irrelevant.

  Maciej

[committed] d: Support deprecated, @disable, and user-defined attributes on enum members

[Iain Buclaw via Gcc-patches]

Hi,

This patch merges the D front-end with upstream dmd 9bba772fa, adding
support for `deprecated`, `@disable` and user-defined attributes to be
applied to enum members.

Bootstrapped and regression tested on x86_64-linux-gnu/-m32/-mx32, and
committed to mainline.

Regards
Iain.

---
gcc/d/ChangeLog:

* dmd/MERGE: Merge upstream dmd 9bba772fa.
---
 gcc/d/dmd/MERGE   |   2 +-
 gcc/d/dmd/declaration.c   |  45 ++
 gcc/d/dmd/declaration.h   |   1 +
 gcc/d/dmd/denum.c |  34 -
 gcc/d/dmd/dsymbol.c   |  23 +--
 gcc/d/dmd/dsymbol.h   |   2 +-
 gcc/d/dmd/enum.h  |   2 +
 gcc/d/dmd/expression.c|  26 +++-
 gcc/d/dmd/expression.h|   3 +-
 gcc/d/dmd/expressionsem.c |   9 ++
 gcc/d/dmd/mtype.c |  21 ++-
 gcc/d/dmd/parse.c | 132 ++
 gcc/d/dmd/traits.c|   4 +-
 gcc/testsuite/gdc.test/compilable/test17908.d |  17 +++
 gcc/testsuite/gdc.test/compilable/test9701.d  |  58 
 gcc/testsuite/gdc.test/compilable/vcg-ast.d   |  43 ++
 .../gdc.test/fail_compilation/disable.d   |  26 ++--
 .../gdc.test/fail_compilation/fail10968.d |  12 +-
 .../gdc.test/fail_compilation/fail11355.d |   2 +-
 .../gdc.test/fail_compilation/fail15044.d |   2 +-
 .../gdc.test/fail_compilation/fail341.d   |   4 +-
 .../gdc.test/fail_compilation/fail9346.d  |   4 +-
 .../fail_compilation/fail_contracts1.d|   8 ++
 .../fail_compilation/fail_contracts2.d|   8 ++
 .../fail_compilation/fail_contracts3.d|  14 ++
 .../fail_compilation/fail_contracts4.d|   8 ++
 .../gdc.test/fail_compilation/test17908a.d|  15 ++
 .../gdc.test/fail_compilation/test17908b.d|  14 ++
 .../gdc.test/fail_compilation/test9701.d  |  63 +
 .../gdc.test/fail_compilation/test9701b.d |  22 +++
 .../gdc.test/fail_compilation/udaparams.d |  57 
 31 files changed, 601 insertions(+), 80 deletions(-)
 create mode 100644 gcc/testsuite/gdc.test/compilable/test17908.d
 create mode 100644 gcc/testsuite/gdc.test/compilable/test9701.d
 create mode 100644 gcc/testsuite/gdc.test/compilable/vcg-ast.d
 create mode 100644 gcc/testsuite/gdc.test/fail_compilation/fail_contracts1.d
 create mode 100644 gcc/testsuite/gdc.test/fail_compilation/fail_contracts2.d
 create mode 100644 gcc/testsuite/gdc.test/fail_compilation/fail_contracts3.d
 create mode 100644 gcc/testsuite/gdc.test/fail_compilation/fail_contracts4.d
 create mode 100644 gcc/testsuite/gdc.test/fail_compilation/test17908a.d
 create mode 100644 gcc/testsuite/gdc.test/fail_compilation/test17908b.d
 create mode 100644 gcc/testsuite/gdc.test/fail_compilation/test9701.d
 create mode 100644 gcc/testsuite/gdc.test/fail_compilation/test9701b.d
 create mode 100644 gcc/testsuite/gdc.test/fail_compilation/udaparams.d

diff --git a/gcc/d/dmd/MERGE b/gcc/d/dmd/MERGE
index f6c8f6f02cf..a34fd4138d7 100644
--- a/gcc/d/dmd/MERGE
+++ b/gcc/d/dmd/MERGE
@@ -1,4 +1,4 @@
-e598f69c0726ad1bf6b2e15e0b60d7cead737fad
+9bba772fa67c6864e551bc87097402f691d947d4
 
 The first line of this file holds the git revision number of the last
 merge done from the dlang/dmd repository.
diff --git a/gcc/d/dmd/declaration.c b/gcc/d/dmd/declaration.c
index f196bc825a2..72a07d9b8f5 100644
--- a/gcc/d/dmd/declaration.c
+++ b/gcc/d/dmd/declaration.c
@@ -155,6 +155,51 @@ int Declaration::checkModify(Loc loc, Scope *sc, Type *, 
Expression *e1, int fla
 return 1;
 }
 
+/**
+ * Issue an error if an attempt to call a disabled method is made
+ *
+ * If the declaration is disabled but inside a disabled function,
+ * returns `true` but do not issue an error message.
+ *
+ * Params:
+ *   loc = Location information of the call
+ *   sc  = Scope in which the call occurs
+ *   isAliasedDeclaration = if `true` searches overload set
+ *
+ * Returns:
+ *   `true` if this `Declaration` is `@disable`d, `false` otherwise.
+ */
+bool Declaration::checkDisabled(Loc loc, Scope *sc, bool isAliasedDeclaration)
+{
+if (!(storage_class & STCdisable))
+return false;
+
+if (sc->func && (sc->func->storage_class & STCdisable))
+return true;
+
+Dsymbol *p = toParent();
+if (p && isPostBlitDeclaration())
+{
+p->error(loc, "is not copyable because it is annotated with 
`@disable`");
+return true;
+}
+
+// if the function is @disabled, maybe there
+// is an overload in the overload set that isn't
+if (isAliasedDeclaration)
+{
+FuncDeclaration *fd = isFuncDeclaration();
+if (fd)
+{
+for (FuncDeclaration *ovl = fd; ovl; ovl = (FuncDeclaration 
*)ovl->overnext)
+if (!(ovl->storage_class & STCdisable))
+return false;
+}
+

[committed] d: Implement expression-based contract syntax

[Iain Buclaw via Gcc-patches]

Hi,

This patch merges the D front-end with upstream dmd e598f69c0, adding
support for an expression-based contract syntax.  Contracts that consist
of a single assertion can now be written more succinctly and multiple
`in` or `out` contracts can be specified for the same function.

Bootstrapped and regression tested on x86_64-linux-gnu/-m32/-mx32, and
committed to mainline.

Regards
Iain.

---
gcc/d/ChangeLog:

* dmd/MERGE: Merge upstream dmd e598f69c0.
---
 gcc/d/dmd/MERGE   |   2 +-
 gcc/d/dmd/arraytypes.h|   2 +
 gcc/d/dmd/declaration.h   |  19 +-
 gcc/d/dmd/func.c  | 206 ++
 gcc/d/dmd/hdrgen.c|  81 +--
 gcc/d/dmd/parse.c | 139 ++--
 gcc/d/dmd/statement.c |  27 ++-
 gcc/d/dmd/statement.h |   1 +
 .../gdc.test/compilable/extra-files/header1.d |  31 ++-
 .../gdc.test/fail_compilation/fail17502.d |   8 +-
 .../gdc.test/runnable/testcontracts.d | 133 +++
 11 files changed, 551 insertions(+), 98 deletions(-)

diff --git a/gcc/d/dmd/MERGE b/gcc/d/dmd/MERGE
index 25b2b3ac965..f6c8f6f02cf 100644
--- a/gcc/d/dmd/MERGE
+++ b/gcc/d/dmd/MERGE
@@ -1,4 +1,4 @@
-9038e64c5b67a10763d32893f53bb6c610df3595
+e598f69c0726ad1bf6b2e15e0b60d7cead737fad
 
 The first line of this file holds the git revision number of the last
 merge done from the dlang/dmd repository.
diff --git a/gcc/d/dmd/arraytypes.h b/gcc/d/dmd/arraytypes.h
index ea57214f734..627464a635f 100644
--- a/gcc/d/dmd/arraytypes.h
+++ b/gcc/d/dmd/arraytypes.h
@@ -61,3 +61,5 @@ typedef Array ReturnStatements;
 typedef Array GotoStatements;
 
 typedef Array TemplateInstances;
+
+typedef Array Ensures;
diff --git a/gcc/d/dmd/declaration.h b/gcc/d/dmd/declaration.h
index a4e776697fc..19e4d1a5aa8 100644
--- a/gcc/d/dmd/declaration.h
+++ b/gcc/d/dmd/declaration.h
@@ -20,6 +20,16 @@ class LabelDsymbol;
 class Initializer;
 class Module;
 class ForeachStatement;
+struct Ensure
+{
+Identifier *id;
+Statement *ensure;
+
+Ensure();
+Ensure(Identifier *id, Statement *ensure);
+Ensure syntaxCopy();
+static Ensures *arraySyntaxCopy(Ensures *a);
+};
 class FuncDeclaration;
 class ExpInitializer;
 class StructDeclaration;
@@ -516,8 +526,10 @@ class FuncDeclaration : public Declaration
 {
 public:
 Types *fthrows; // Array of Type's of exceptions (not 
used)
-Statement *frequire;
-Statement *fensure;
+Statements *frequires;  // in contracts
+Ensures *fensures;  // out contracts
+Statement *frequire;// lowered in contract
+Statement *fensure; // lowered out contract
 Statement *fbody;
 
 FuncDeclarations foverrides;// functions this function overrides
@@ -526,8 +538,7 @@ public:
 
 const char *mangleString;   // mangled symbol created from 
mangleExact()
 
-Identifier *outId;  // identifier for out statement
-VarDeclaration *vresult;// variable corresponding to outId
+VarDeclaration *vresult;// result variable for out contracts
 LabelDsymbol *returnLabel;  // where the return goes
 
 // used to prevent symbols in different
diff --git a/gcc/d/dmd/func.c b/gcc/d/dmd/func.c
index 53621adcc41..f8f43dc09bb 100644
--- a/gcc/d/dmd/func.c
+++ b/gcc/d/dmd/func.c
@@ -292,6 +292,42 @@ public:
 }
 };
 
+/***
+ * Tuple of result identifier (possibly null) and statement.
+ * This is used to store out contracts: out(id){ ensure }
+ */
+Ensure::Ensure()
+{
+this->id = NULL;
+this->ensure = NULL;
+}
+
+Ensure::Ensure(Identifier *id, Statement *ensure)
+{
+this->id = id;
+this->ensure = ensure;
+}
+
+Ensure Ensure::syntaxCopy()
+{
+return Ensure(id, ensure->syntaxCopy());
+}
+
+/*
+ * Do syntax copy of an array of Ensure's.
+ */
+Ensures *Ensure::arraySyntaxCopy(Ensures *a)
+{
+Ensures *b = NULL;
+if (a)
+{
+b = a->copy();
+for (size_t i = 0; i < a->length; i++)
+(*b)[i] = (*a)[i].syntaxCopy();
+}
+return b;
+}
+
 /* FuncDeclaration 
/
 
 FuncDeclaration::FuncDeclaration(Loc loc, Loc endloc, Identifier *id, 
StorageClass storage_class, Type *type)
@@ -314,10 +350,11 @@ FuncDeclaration::FuncDeclaration(Loc loc, Loc endloc, 
Identifier *id, StorageCla
 fdrequire = NULL;
 fdensure = NULL;
 mangleString = NULL;
-outId = NULL;
 vresult = NULL;
 returnLabel = NULL;
 fensure = NULL;
+frequires = NULL;
+fensures = NULL;
 fbody = NULL;
 localsymtab = NULL;
 vthis = NULL;
@@ -372,10 +409,9 @@ Dsymbol *FuncDeclaration::syntaxCopy(Dsymbol *s)
 FuncDeclaration 

[PATCH] c++: Fix ICE with CTAD in concept [PR98611]

[Patrick Palka via Gcc-patches]

This patch teaches find_template_parameters to visit the template
represented by a CTAD placeholder, which is normally not visited by
for_each_template_parm.  This template may be a template template
parameter (as in the first testcase), or it may implicitly use the
template parameters of an enclosing class template (as in the second
testcase), and in either case we need to record the template parameters
used therein for later satisfaction.

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk and perhaps the 10 branch?  Also tested on range-v3 and cmcstl2.

gcc/cp/ChangeLog:

PR c++/98611
* pt.c (any_template_parm_r) : Visit
the template of a CTAD placeholder.

gcc/testsuite/ChangeLog:

PR c++/98611
* g++.dg/cpp2a/concepts-ctad1.C: New test.
* g++.dg/cpp2a/concepts-ctad2.C: New test.
---
 gcc/cp/pt.c |  4 
 gcc/testsuite/g++.dg/cpp2a/concepts-ctad1.C | 16 
 gcc/testsuite/g++.dg/cpp2a/concepts-ctad2.C | 14 ++
 3 files changed, 34 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-ctad1.C
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-ctad2.C

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 51540ca35a5..d3bb6231926 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -10694,6 +10694,10 @@ any_template_parm_r (tree t, void *data)
   if (is_auto (t))
if (tree constr = PLACEHOLDER_TYPE_CONSTRAINTS (t))
  WALK_SUBTREE (constr);
+  /* A use of a CTAD placeholder is also a use of the template it
+represents.  */
+  if (template_placeholder_p (t))
+ WALK_SUBTREE (CLASS_PLACEHOLDER_TEMPLATE (t));
   break;
 
 case TEMPLATE_ID_EXPR:
diff --git a/gcc/testsuite/g++.dg/cpp2a/concepts-ctad1.C 
b/gcc/testsuite/g++.dg/cpp2a/concepts-ctad1.C
new file mode 100644
index 000..ec2e4b014d7
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/concepts-ctad1.C
@@ -0,0 +1,16 @@
+// PR c++/98611
+// { dg-do compile { target c++20 } }
+
+template 
+concept IsSame = __is_same(T, U);
+
+template  class _Class>
+concept IsInstantiationOf = requires(T object) {
+ { _Class{object} } -> IsSame;
+};
+
+template  struct Degrees {};
+static_assert(IsInstantiationOf, Degrees>);
+
+template  struct NotDegrees {};
+static_assert(!IsInstantiationOf, NotDegrees>);
diff --git a/gcc/testsuite/g++.dg/cpp2a/concepts-ctad2.C 
b/gcc/testsuite/g++.dg/cpp2a/concepts-ctad2.C
new file mode 100644
index 000..de960487713
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/concepts-ctad2.C
@@ -0,0 +1,14 @@
+// PR c++/98611
+// { dg-do compile { target c++20 } }
+
+template 
+struct S
+{
+  template  struct Tmpl { Tmpl(T); };
+
+  template 
+requires requires (T object) { Tmpl{object}; }
+  static int f(T);
+};
+
+int a = S::f(0);
-- 
2.30.0

Re: [patch] fix -Wformat-diag warnings in rs6000-call.c

[Jakub Jelinek via Gcc-patches]

On Sat, Jan 09, 2021 at 07:44:31PM +0100, Matthias Klose wrote:
> These warnings, including the suggested fixes are seen on power*-linux builds.
> 
> warning: misspelled term 'builtin function' in format; use 'bult-in function'

Are you sure it printed bult-in ?

>  fatal_error (input_location,
> -  "internal error: builtin function %qs already processed",
> +  "internal error: builtin-function %qs already processed",

It meant built-in function instead of builtin-function I'm pretty sure.

>name);
>  
>rs6000_builtin_decls[(int)code] = t =
> @@ -11219,7 +11219,7 @@ altivec_expand_builtin (tree exp, rtx target, bool 
> *expandedp)
>   {
> size_t uns_fcode = (size_t) fcode;
> const char *name = rs6000_builtin_info[uns_fcode].name;
> -   error ("Second argument of %qs must be in the range [0, 3].", name);
> +   error ("Second argument of %qs must be in the range [0, 3]", name);

Diagnostics shouldn't start with capital letter either, so it should be
"second ..."
> -  "internal error: builtin function %qs had an unexpected "
> +  "internal error: builtin-function %qs had an unexpected "
>"return type %qs", name, GET_MODE_NAME (h.mode[0]));
> -  "internal error: builtin function %qs, argument %d "
> +  "internal error: builtin-function %qs, argument %d "

See above.


Jakub

Re: make FOR_EACH_IMM_USE_STMT safe for early exits

[Alexandre Oliva]

On Jan  7, 2021, Richard Biener  wrote:

> On Wed, Jan 6, 2021 at 12:34 PM Alexandre Oliva  wrote:
>> 
>> On Jan  4, 2021, Richard Biener  wrote:
>> 
>> > Thus, please remove uses of BREAK_FROM_IMM_USE_STMT
>> > together with this patch.
>> 
>> And RETURN_FROM_IMM_USE_STMT, I suppose?

> Sure.

Done.


make FOR_EACH_IMM_USE_STMT safe for early exits

Use a dtor to automatically remove ITER from IMM_USE list in
FOR_EACH_IMM_USE_STMT.

Regstrapped on x86_64-linux-gnu.  Ok to install?



for  gcc/ChangeLog

* ssa-iterators.h (end_imm_use_stmt_traverse): Forward
declare.
(auto_end_imm_use_stmt_traverse): New struct.
(FOR_EACH_IMM_USE_STMT): Use it.
(BREAK_FROM_IMM_USE_STMT, RETURN_FROM_IMM_USE_STMT): Remove,
along with uses...
* gimple-ssa-strength-reduction.c: ... here, ...
* graphite-scop-detection.c: ... here, ...
* ipa-modref.c, ipa-pure-const.c, ipa-sra.c: ... here, ...
* tree-predcom.c, tree-ssa-ccp.c: ... here, ...
* tree-ssa-dce.c, tree-ssa-dse.c: ... here, ...
* tree-ssa-loop-ivopts.c, tree-ssa-math-opts.c: ... here, ...
* tree-ssa-phiprop.c, tree-ssa.c: ... here, ...
* tree-vect-slp.c: ... and here, ...
* doc/tree-ssa.texi: ... and the example here.
---
 gcc/doc/tree-ssa.texi   |   16 ++
 gcc/gimple-ssa-strength-reduction.c |2 +-
 gcc/graphite-scop-detection.c   |4 +---
 gcc/ipa-modref.c|4 +---
 gcc/ipa-pure-const.c|8 ---
 gcc/ipa-sra.c   |   22 ++--
 gcc/ssa-iterators.h |   39 +++
 gcc/tree-predcom.c  |2 +-
 gcc/tree-ssa-ccp.c  |2 +-
 gcc/tree-ssa-dce.c  |2 +-
 gcc/tree-ssa-dse.c  |8 ---
 gcc/tree-ssa-loop-ivopts.c  |2 +-
 gcc/tree-ssa-math-opts.c|2 +-
 gcc/tree-ssa-phiprop.c  |2 +-
 gcc/tree-ssa.c  |2 +-
 gcc/tree-vect-slp.c |4 ++--
 16 files changed, 54 insertions(+), 67 deletions(-)

diff --git a/gcc/doc/tree-ssa.texi b/gcc/doc/tree-ssa.texi
index f927f89cb7f64..057135f80d116 100644
--- a/gcc/doc/tree-ssa.texi
+++ b/gcc/doc/tree-ssa.texi
@@ -385,20 +385,8 @@ optimization can manipulate the stmt when all the uses 
have been
 processed.  This is a little slower than the FAST version since it adds a
 placeholder element and must sort through the list a bit for each statement.
 This placeholder element must be also be removed if the loop is
-terminated early.  The macro @code{BREAK_FROM_IMM_USE_STMT} is provided
-to do this :
-
-@smallexample
-  FOR_EACH_IMM_USE_STMT (stmt, iterator, ssa_var)
-@{
-  if (stmt == last_stmt)
-BREAK_FROM_IMM_USE_STMT (iterator);
-
-  FOR_EACH_IMM_USE_ON_STMT (imm_use_p, iterator)
-SET_USE (imm_use_p, ssa_var_2);
-  fold_stmt (stmt);
-@}
-@end smallexample
+terminated early; a destructor takes care of that when leaving the
+@code{FOR_EACH_IMM_USE_STMT} scope.
 
 There are checks in @code{verify_ssa} which verify that the immediate use list
 is up to date, as well as checking that an optimization didn't break from the
diff --git a/gcc/gimple-ssa-strength-reduction.c 
b/gcc/gimple-ssa-strength-reduction.c
index b6cbb21dfbc73..a92cf03c1f322 100644
--- a/gcc/gimple-ssa-strength-reduction.c
+++ b/gcc/gimple-ssa-strength-reduction.c
@@ -524,7 +524,7 @@ uses_consumed_by_stmt (tree name, gimple *stmt, unsigned 
recurse = 0)
 recurse + 1))
{
  retval = false;
- BREAK_FROM_IMM_USE_STMT (iter);
+ break;
}
 }
 
diff --git a/gcc/graphite-scop-detection.c b/gcc/graphite-scop-detection.c
index 4f7bbe5d03524..3e729b159b095 100644
--- a/gcc/graphite-scop-detection.c
+++ b/gcc/graphite-scop-detection.c
@@ -1262,9 +1262,7 @@ build_cross_bb_scalars_def (scop_p scop, tree def, 
basic_block def_bb,
&& (def_bb != gimple_bb (use_stmt) && !is_gimple_debug (use_stmt)))
   {
add_write (writes, def);
-   /* This is required by the FOR_EACH_IMM_USE_STMT when we want to break
-  before all the uses have been visited.  */
-   BREAK_FROM_IMM_USE_STMT (imm_iter);
+   break;
   }
 }
 
diff --git a/gcc/ipa-modref.c b/gcc/ipa-modref.c
index 04613201f1f1e..74ad876cf581e 100644
--- a/gcc/ipa-modref.c
+++ b/gcc/ipa-modref.c
@@ -1597,9 +1597,7 @@ analyze_ssa_name_flags (tree name, vec 
, int depth,
   FOR_EACH_IMM_USE_STMT (use_stmt, ui, name)
 {
   if (lattice[index].flags == 0)
-   {
- BREAK_FROM_IMM_USE_STMT (ui);
-   }
+   break;
   if (is_gimple_debug (use_stmt))
continue;
   if (dump_file)
diff --git a/gcc/ipa-pure-const.c b/gcc/ipa-pure-const.c
index 66f2177110788..957217ae4ae34 100644
--- a/gcc/ipa-pure-const.c
+++ b/gcc/ipa-pure-const.c
@@ -842,20 

--enable-link-serialization=1 doesn't work

[Matthias Klose]

The attached patch makes the link targets a little bit more verbose. Ok to 
commit?

It shows that --enable-link-serialization=1 doesn't work:

$ grep ^Linking ../log
Linking gnat1 |==--  | 9%
Linking cc1 |--| 0%
Linking cc1 |==| 9%
Linking gnat1 |  | 18%
Linking brig1 |--| 18%
Linking brig1 |==| 27%
Linking cc1plus |==--  | 27%
Linking cc1plus |  | 36%
Linking d21 |--| 36%
Linking d21 |==| 45%
Linking f951 |==--  | 45%
Linking f951 |  | 54%
Linking go1 |--| 54%
Linking go1 |==| 63%
Linking lto1 |==--  | 63%
Linking lto1 |  | 72%
Linking lto-dump |--| 72%
Linking lto-dump |==| 81%
Linking cc1obj |==--  | 81%
Linking cc1obj |  | 90%
Linking cc1objplus |--| 90%
Linking cc1objplus |==| 100%

At least the gnat1 link is started before the cc1 link finishes.

Matthias

--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -1793,7 +1793,7 @@ DO_LINK_SERIALIZATION = @DO_LINK_SERIALIZATION@
 ifeq ($(DO_LINK_SERIALIZATION),)
 LINK_PROGRESS = :
 else
-LINK_PROGRESS = msg="Linking |"; cnt=0; if test "$(2)" = start; then \
+LINK_PROGRESS = msg="Linking $@ |"; cnt=0; if test "$(2)" = start; then \
   idx=0; cnt2=$(DO_LINK_SERIALIZATION); \
   while test $$cnt2 -le $(1); do msg="$${msg}=="; cnt2=`expr $$cnt2 + 1`; idx=`expr $$idx + 1`; done; \
   cnt=$$idx; \

Re: [PATCH v3] libgcc: Thumb-1 Floating-Point Library for Cortex M0

[Daniel Engel]

On Sat, Jan 9, 2021, at 5:09 AM, Christophe Lyon wrote:
> On Sat, 9 Jan 2021 at 13:27, Daniel Engel  wrote:
> >
> > -- snip --
> >
> > To reiterate what I said above, I intend to push forward and incorporate
> > your current recommendations plus any further feedback I may get.  I
> > expect you to say that this doesn't merit inclusion yet, but I'd rather
> > spend the time while I have it.
> >
> > I'll post a patch series for review within the next day or so.
> 
> Here are the results of the validation of your latest version 
> (20210105):
> https://people.linaro.org/~christophe.lyon/cross-validation/gcc-test-patches/r11-5993-g159b0bd9ce263dfb791eff5133b0ca0207201c84-cortex-m0-fplib-20210105.patch/report-build-info.html

Thanks for this.  
 
> "BIG-REGR" just means the regression report is large enough that it's
> provided in compressed form to avoid overloading the browser.
> 
> So it really seems your patch introduces regressions in arm*linux* configs.
> For the 2 arm-none-eabi configs which show regressions (cortex-m0 and
> cortex-m3), the logs seem to indicate some tests timed out, and it's
> possible the server used was overloaded.

Looks like I added _divdi3 in LIB1ASMFUNCS with too much scope.  So the
C implementation gets locked out of the build.  On EABI, _divdi3 is
renamed as __aeabi_ldivmod, so both symbols are always found.  On GNU
EABI, that doesn't happen.

It should be a trivial fix, and I think there are a couple more similar.
I'll integrate this change in the patch series.

> The same applies to the 3 aarch64*elf cases, where the regressions
> seem only caused by timed out; there's no reason your patch would have
> an impact on aarch64.
> (there 5 configs were tested on the same machine, so overload is indeed 
> likely).
> 
> I didn't check why all the ubsan tests now seem to fail, they are in
> the "unstable" category because in the past some of them had some
> randomness.
> I do not see such noise in trunk validation though.

I tried looking up a few of them to analyze.  Couldn't find the names
in the logs (e.g. "pr95810").  Are you sure they actually failed, or just
didn't run?  Regression reports say "ignored".

> Thanks,
> 
> Christophe
> 

Thanks again,
Daniel

[patch] fix -Wformat-diag warnings in rs6000-call.c

[Matthias Klose]

These warnings, including the suggested fixes are seen on power*-linux builds.

warning: misspelled term 'builtin function' in format; use 'bult-in function'
instead [-Wformat-diag]

warning: spurious trailing punctuation sequence '].' in format [-Wformat-diag]

warning: misspelled term 'floating point' in format; use 'floating-point'
instead [-Wformat-diag]

Ok to fix these?

Matthias
diff --git a/gcc/config/rs6000/rs6000-call.c b/gcc/config/rs6000/rs6000-call.c
index 2308cc8b4a2..3988dd81481 100644
--- a/gcc/config/rs6000/rs6000-call.c
+++ b/gcc/config/rs6000/rs6000-call.c
@@ -8741,7 +8741,7 @@ def_builtin (const char *name, tree type, enum rs6000_builtins code)
 
   if (rs6000_builtin_decls[(int)code])
 fatal_error (input_location,
-		 "internal error: builtin function %qs already processed",
+		 "internal error: builtin-function %qs already processed",
 		 name);
 
   rs6000_builtin_decls[(int)code] = t =
@@ -11219,7 +11219,7 @@ altivec_expand_builtin (tree exp, rtx target, bool *expandedp)
 	{
 	  size_t uns_fcode = (size_t) fcode;
 	  const char *name = rs6000_builtin_info[uns_fcode].name;
-	  error ("Second argument of %qs must be in the range [0, 3].", name);
+	  error ("Second argument of %qs must be in the range [0, 3]", name);
 	  return expand_call (exp, target, false);
 	}
   break;
@@ -11479,7 +11479,7 @@ rs6000_invalid_builtin (enum rs6000_builtins fncode)
   else if ((fnmask & RS6000_BTM_HARD_FLOAT) != 0)
 error ("%qs requires the %qs option", name, "-mhard-float");
   else if ((fnmask & RS6000_BTM_FLOAT128_HW) != 0)
-error ("%qs requires ISA 3.0 IEEE 128-bit floating point", name);
+error ("%qs requires ISA 3.0 IEEE 128-bit floating-point", name);
   else if ((fnmask & RS6000_BTM_FLOAT128) != 0)
 error ("%qs requires the %qs option", name, "%<-mfloat128%>");
   else if ((fnmask & (RS6000_BTM_POPCNTD | RS6000_BTM_POWERPC64))
@@ -14582,7 +14582,7 @@ builtin_function_type (machine_mode mode_ret, machine_mode mode_arg0,
 
   if (!ret_type)
 fatal_error (input_location,
-		 "internal error: builtin function %qs had an unexpected "
+		 "internal error: builtin-function %qs had an unexpected "
 		 "return type %qs", name, GET_MODE_NAME (h.mode[0]));
 
   for (i = 0; i < (int) ARRAY_SIZE (arg_type); i++)
@@ -14604,7 +14604,7 @@ builtin_function_type (machine_mode mode_ret, machine_mode mode_arg0,
 
   if (!arg_type[i])
 	fatal_error (input_location,
-		 "internal error: builtin function %qs, argument %d "
+		 "internal error: builtin-function %qs, argument %d "
 		 "had unexpected argument type %qs", name, i,
 		 GET_MODE_NAME (m));
 }

Re: [PATCH v3] libgcc: Thumb-1 Floating-Point Library for Cortex M0

[Daniel Engel]

On Sat, Jan 9, 2021, at 5:09 AM, Christophe Lyon wrote:
> On Sat, 9 Jan 2021 at 13:27, Daniel Engel  wrote:
> >
> > On Thu, Jan 7, 2021, at 4:56 AM, Richard Earnshaw wrote:
> > > On 07/01/2021 00:59, Daniel Engel wrote:
> > > > --snip--
> > > >
> > > > On Wed, Jan 6, 2021, at 9:05 AM, Richard Earnshaw wrote:
> > > >
> > > >> -- snip --
> > > >>
> > > >> - finally, your popcount implementations have data in the code segment.
> > > >>  That's going to cause problems when we have compilation options such 
> > > >> as
> > > >> -mpure-code.
> > > >
> > > > I am just following the precedent of existing lib1funcs (e.g. __clz2si).
> > > > If this matters, you'll need to point in the right direction for the
> > > > fix.  I'm not sure it does matter, since these functions are PIC anyway.
> > >
> > > That might be a bug in the clz implementations - Christophe: Any thoughts?
> >
> > __clzsi2() has test coverage in "gcc.c-torture/execute/builtin-bitops-1.c"
> Thanks, I'll have a closer look at why I didn't see problems.
> 
> > The 'clzs' and 'ctz' functions should never have problems.   -mpure-code
> > appears to be valid only when the 'movt' instruction is available, which
> > means that the 'clz' instruction will also be available, so no array loads.
> No, -mpure-code is also supported with v6m.
> 
> > Is the -mpure-code state detectable as a preprocessor flag?  While
> No.
> 
> > 'movw'/'movt' appears to be the canonical solution, I'm not sure it
> > should be the default just because a processor supports Thumb-2.
> >
> > Do users wanting to use -mpure-code recompile the toolchain to avoid
> > constant data in compiled C functions?  I don't think this is the
> > default for the typical toolchain scripts.
> No, users of -mpure-code do not recompile the toolchain.

I won't claim that my use of inline constants is correct.  It was not
hard to find references to high security model processors that block
reading from executable sections.

However, if all of the above is true, I think libgcc as a whole
will have much bigger problems.  I count over 500 other instances
in the disassembled v6m *.a file where functions load pc-relative
data from '.text'.

For example:
* C version of popcount
* __powidf2 (0x3FF0)
* __mulsc3 (0x7F7F)
* Most soft-float functions.

Still not seeing a clear resolution here.  Is it acceptable to use the 

"ldr rD, =const" 

pattern?

Thanks,
Daniel

Support the PGO build for binutils+gdb (2.36 Branch imminent)

[H.J. Lu via Gcc-patches]

On Thu, Jan 7, 2021 at 4:10 AM Nick Clifton  wrote:
>
> Hi H.J.
>
> > I got no feedbacks for my current patch set:
> > https://sourceware.org/pipermail/gdb-patches/2020-December/174216.html
>
> Right - in which case I would like to do this:
>
>1. Do not apply the patch now.  But when the 2.36 branch is
>   created apply it there as soon as you can.  (In order to
>   give us time to see if any problem arise - I am not
>   expecting any though).

I am checking in my patches now.

>2. Continue to ping the gdb abd gcc folks.  If we can get
>   them to approve the patch then we can check it into the
>   mainline sources, hopefully before the 2.37 release happens.
>
> Cheers
>Nick
>
>


-- 
H.J.

[PATCH] doc: Fix typos in C++ Modules documentation

[Jonathan Wakely via Gcc-patches]

gcc/ChangeLog:

* doc/invoke.texi (C++ Modules): Fix typos.

I plan to commit this as obvious.

The s/it/they/ change is because the previous sentence says "Modules
are" so we should consistently refer to them as plural, not singular.


commit 142b67a620e343c62524c170682f4b50980ee0a0
Author: Jonathan Wakely 
Date:   Sat Jan 9 14:31:48 2021

doc: Fix typos in C++ Modules documentation

gcc/ChangeLog:

* doc/invoke.texi (C++ Modules): Fix typos.

diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 226b8ade430..298f1f873e3 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -32860,7 +32860,7 @@ not get debugging information for routines in the 
precompiled header.
 @section C++ Modules
 @cindex speed of compilation
 
-Modules are a C++ 20 language feature.  As the name suggests, it
+Modules are a C++20 language feature.  As the name suggests, they
 provides a modular compilation system, intending to provide both
 faster builds and better library isolation.  The ``Merging Modules''
 paper @uref{https://wg21.link/p1103}, provides the easiest to read set
@@ -32892,7 +32892,7 @@ emitted.
 
 @item Translation-Unit local referencing rules
 Papers p1815 (@uref{https://wg21.link/p1815}) and p2003
-(@uref{https://wg21.link/p2003} add limitations on which entities an
+(@uref{https://wg21.link/p2003}) add limitations on which entities an
 exported region may reference (for instance, the entities an exported
 template definition may reference).  These are not fully implemented.
 

Re: [PATCH v3] libgcc: Thumb-1 Floating-Point Library for Cortex M0

[Christophe Lyon via Gcc-patches]

On Sat, 9 Jan 2021 at 13:27, Daniel Engel  wrote:
>
> On Thu, Jan 7, 2021, at 4:56 AM, Richard Earnshaw wrote:
> > On 07/01/2021 00:59, Daniel Engel wrote:
> > > --snip--
> > >
> > > On Wed, Jan 6, 2021, at 9:05 AM, Richard Earnshaw wrote:
> > >
> > >>
> > >> Thanks for working on this, Daniel.
> > >>
> > >> This is clearly stage1 material, so we've got time for a couple of
> > >> iterations to sort things out.
> > >
> > > I appreciate your feedback.  I had been hoping that with no regressions
> > > this might still be eligible for stage2.  Christophe never indicated
> > > either way. but the fact that he was looking at it seemed positive.
> > > I thought I would be a couple of weeks faster with this last
> > > iteration, but holidays got in the way.
> >
> > GCC doesn't have a stage 2 any more (historical wart).  We were in
> > (late) stage3 when this was first posted, and because of the significant
> > impact this might have on not just CM0 but other targets as well, I
> > don't think it's something we should try to squeeze in at the last
> > minute.  We're now in stage 4, so that is doubly the case.
>
> Of course I meant stage3.  Oops.  I actually thought stage 3 would
> continue through next week based on the average historical dates.

I expected stage4 to start on Jan 1st :-)

> It would have been nice to get this feedback when I emailed you a
> preview version of this patch (2020-Nov-11).  Christophe's logs have
> been very helpful on the technical integration, but it's proving a chore
> to go back and re-create some of the intermediate chunks.
>
> Regardless, I still have free time for at least a little while longer to
> work on this, so I'll push forward with any further feedback you are
> willing to give me.  I have failed to free up any time during the last 2
> years to actually work on this during stage1, and I have no guarantee
> this coming year will be different.
>
> >
> > Christophe is a very valuable member of our community, but he's not a
> > port maintainer and thus cannot really rule on what can go into the
> > tools, or when.
> >
> > >
> > > I actually think your comments below could all be addressable within a
> > > couple of days.  But, I'm not accounting for the review process.
> > >
> > >> Firstly, the patch is very large, but contains a large number of
> > >> distinct changes, so it would really benefit from being broken down into
> > >> a number of distinct patches.  This will make reviewing the individual
> > >> changes much more straight-forward.

And if you can generate the patch with git, that will help: the reason for the
previous build errors was because I had to "reformat" your patch before
submitting it for validation, and I messed things up.

> > >
> > > I have no context for "large" or "small" with respect to gcc.  This
> > > patch comprises about 30% of a previously-monolithic library that's
> > > been shipping since ~2016 (the rest is libm material).  Other than
> > > (1) the aforementioned change to div0(), (2) a nascent adaptation
> > > for __truncdfsf2() (not enabled), and (3) the gratuitous addition of
> > > the bitwise functions, the library remains pretty much as it was
> > > originally released.
> >
> > Large, like many other terms is relative.  For assembler file changes,
> > which this is primarily, the overall size can be much smaller and still
> > be considered 'large'.
> >
> > >
> > > The driving force in the development of this library was small size,
> > > which of course was never possible with the softfp routines.  It's not
> > > half-slow, either, for the limitations of the M0 architecture.   And,
> > > it's IEEE compliant.  But, that means that most of the functions are
> > > highly interconnected.  So, some of it can be broken up as you outline
> > > below, but that last patch is still worth more than half of the total.
> >
> > Nevertheless, having the floating-point code separated out will make
> > reviewing more straight forward.  I'll likely need to ask one of our FP
> > experts to have a specific look at that part and that will be easier if
> > it is disentangled from the other changes.
> > >
> > > I also have ~70k lines of test vectors that seem mostly redundant, but
> > > not completely.  I haven't decided what to do here.  For example, I have
> > > coverage for __aeabi_u/ldivmod, while GCC does not.  If I do anything
> > > with this code it will be in a separate thread.
> >
> > Publishing the test code, even if it isn't integrated into the GCC
> > testsuite would be useful.  Perhaps someone else could then help with that.
>
> Very brute force stuff, not production quality:
>  (160 kb)
>
> > >> I'd suggest:
> > >>
> > >> 1) Some basic makefile cleanups to ease initial integration - in
> > >> particular where we have things like
> > >>
> > >> LIB1FUNCS += 
> > >>
> > >> that this be rewritten with one function per line (and sorted
> > >> alphabetically) - then we can see which functions are being 

Re: [PATCH v3] libgcc: Thumb-1 Floating-Point Library for Cortex M0

[Daniel Engel]

On Thu, Jan 7, 2021, at 4:56 AM, Richard Earnshaw wrote:
> On 07/01/2021 00:59, Daniel Engel wrote:
> > --snip--
> > 
> > On Wed, Jan 6, 2021, at 9:05 AM, Richard Earnshaw wrote:
> > 
> >>
> >> Thanks for working on this, Daniel.
> >>
> >> This is clearly stage1 material, so we've got time for a couple of
> >> iterations to sort things out.
> > 
> > I appreciate your feedback.  I had been hoping that with no regressions
> > this might still be eligible for stage2.  Christophe never indicated
> > either way. but the fact that he was looking at it seemed positive.
> > I thought I would be a couple of weeks faster with this last
> > iteration, but holidays got in the way.
> 
> GCC doesn't have a stage 2 any more (historical wart).  We were in
> (late) stage3 when this was first posted, and because of the significant
> impact this might have on not just CM0 but other targets as well, I
> don't think it's something we should try to squeeze in at the last
> minute.  We're now in stage 4, so that is doubly the case.

Of course I meant stage3.  Oops.  I actually thought stage 3 would
continue through next week based on the average historical dates.

It would have been nice to get this feedback when I emailed you a
preview version of this patch (2020-Nov-11).  Christophe's logs have
been very helpful on the technical integration, but it's proving a chore
to go back and re-create some of the intermediate chunks.

Regardless, I still have free time for at least a little while longer to
work on this, so I'll push forward with any further feedback you are
willing to give me.  I have failed to free up any time during the last 2
years to actually work on this during stage1, and I have no guarantee
this coming year will be different.

> 
> Christophe is a very valuable member of our community, but he's not a
> port maintainer and thus cannot really rule on what can go into the
> tools, or when.
> 
> > 
> > I actually think your comments below could all be addressable within a
> > couple of days.  But, I'm not accounting for the review process.
> >  
> >> Firstly, the patch is very large, but contains a large number of
> >> distinct changes, so it would really benefit from being broken down into
> >> a number of distinct patches.  This will make reviewing the individual
> >> changes much more straight-forward.  
> > 
> > I have no context for "large" or "small" with respect to gcc.  This
> > patch comprises about 30% of a previously-monolithic library that's
> > been shipping since ~2016 (the rest is libm material).  Other than
> > (1) the aforementioned change to div0(), (2) a nascent adaptation
> > for __truncdfsf2() (not enabled), and (3) the gratuitous addition of
> > the bitwise functions, the library remains pretty much as it was
> > originally released.
> 
> Large, like many other terms is relative.  For assembler file changes,
> which this is primarily, the overall size can be much smaller and still
> be considered 'large'.
> 
> > 
> > The driving force in the development of this library was small size,
> > which of course was never possible with the softfp routines.  It's not
> > half-slow, either, for the limitations of the M0 architecture.   And,
> > it's IEEE compliant.  But, that means that most of the functions are
> > highly interconnected.  So, some of it can be broken up as you outline
> > below, but that last patch is still worth more than half of the total.
> 
> Nevertheless, having the floating-point code separated out will make
> reviewing more straight forward.  I'll likely need to ask one of our FP
> experts to have a specific look at that part and that will be easier if
> it is disentangled from the other changes.
> > 
> > I also have ~70k lines of test vectors that seem mostly redundant, but
> > not completely.  I haven't decided what to do here.  For example, I have
> > coverage for __aeabi_u/ldivmod, while GCC does not.  If I do anything
> > with this code it will be in a separate thread.
> 
> Publishing the test code, even if it isn't integrated into the GCC
> testsuite would be useful.  Perhaps someone else could then help with that.

Very brute force stuff, not production quality:
 (160 kb)

> >> I'd suggest:
> >>
> >> 1) Some basic makefile cleanups to ease initial integration - in
> >> particular where we have things like
> >>
> >> LIB1FUNCS += 
> >>
> >> that this be rewritten with one function per line (and sorted
> >> alphabetically) - then we can see which functions are being changed in
> >> subsequent patches.  It makes the Makefile fragments longer, but the
> >> improvement in clarity for makes this worthwhile.
> > 
> > I know next to nothing about Makefiles, particularly ones as complex as
> > GCC's.  I was just trying to work with the existing style to avoid
> > breaking something.  However, I can certainly adopt this suggestion.
> >  
> >> 2) The changes for the existing integer functions - preferably one
> >> function per patch.
> 

[PATCH] widening_mul: Pattern recognize also signed multiplication with overflow check [PR95852]

[Jakub Jelinek via Gcc-patches]

Hi!

On top of the previous widening_mul patch, this one recognizes also
(non-perfect) signed multiplication with overflow, like:
int
f5 (int x, int y, int *res)
{
  *res = (unsigned) x * y;
  return x && (*res / x) != y;
}
The problem with such checks is that they invoke UB if x is -1 and
y is INT_MIN during the division, but perhaps the code knows that
those values won't appear.  As that case is UB, we can do for that
case whatever we want and handling that case as signed overflow
is the best option.  If x is a constant not equal to -1, then the checks
are 100% correct though.
Haven't tried to pattern match bullet-proof checks, because I really don't
know if users would write it in real-world code like that,
perhaps
  *res = (unsigned) x * y;
  return x && (x == -1 ? (*res / y) != x : (*res / x) != y);
?

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

https://wiki.sei.cmu.edu/confluence/display/c/INT32-C.+Ensure+that+operations+on+signed+integers+do+not+result+in+overflow
suggests to use twice as wide multiplication (perhaps we should handle that
too, for both signed and unsigned), or some very large code
with 4 different divisions nested in many conditionals, no way one can
match all the possible variants thereof.

2021-01-08  Jakub Jelinek  

PR tree-optimization/95852
* tree-ssa-math-opts.c (maybe_optimize_guarding_check): Change
mul_stmts parameter type to vec &.  Before cond_stmt
allow in the bb any of the stmts in that vector, div_stmt and
up to 3 cast stmts.
(arith_cast_equal_p): New function.
(arith_overflow_check_p): Add cast_stmt argument, handle signed
multiply overflow checks.
(match_arith_overflow): Adjust caller.  Handle signed multiply
overflow checks.

* gcc.target/i386/pr95852-3.c: New test.
* gcc.target/i386/pr95852-4.c: New test.

--- gcc/tree-ssa-math-opts.c.jj 2021-01-08 17:45:47.251561681 +0100
+++ gcc/tree-ssa-math-opts.c2021-01-08 20:42:54.350664472 +0100
@@ -3471,7 +3471,7 @@ convert_mult_to_fma (gimple *mul_stmt, t
optimize the x_4(D) != 0 condition to 1.  */
 
 static void
-maybe_optimize_guarding_check (gimple **mul_stmts, gimple *cond_stmt,
+maybe_optimize_guarding_check (vec _stmts, gimple *cond_stmt,
   gimple *div_stmt, bool *cfg_changed)
 {
   basic_block bb = gimple_bb (cond_stmt);
@@ -3525,37 +3525,34 @@ maybe_optimize_guarding_check (gimple **
  != TYPE_PRECISION (TREE_TYPE (rhs2
return;
 }
-  gimple_stmt_iterator gsi = gsi_for_stmt (div_stmt);
-  gsi_prev_nondebug ();
-  if (!gsi_end_p (gsi))
+  gimple_stmt_iterator gsi = gsi_after_labels (bb);
+  mul_stmts.quick_push (div_stmt);
+  if (is_gimple_debug (gsi_stmt (gsi)))
+gsi_next_nondebug ();
+  unsigned cast_count = 0;
+  while (gsi_stmt (gsi) != cond_stmt)
 {
   /* If original mul_stmt has a single use, allow it in the same bb,
 we are looking then just at __builtin_mul_overflow_p.
 Though, in that case the original mul_stmt will be replaced
 by .MUL_OVERFLOW, REALPART_EXPR and IMAGPART_EXPR stmts.  */
-  for (int i = 2; i >= 0; --i)
+  gimple *mul_stmt;
+  unsigned int i;
+  bool ok = false;
+  FOR_EACH_VEC_ELT (mul_stmts, i, mul_stmt)
{
- if (gsi_stmt (gsi) != mul_stmts[i])
-   return;
- gsi_prev_nondebug ();
-   }
-  /* Allow up to 2 extra casts.  Given the way we check PHIs,
-nothing from this bb should be consumed by any other bb
-anyway.  */
-  for (int i = 0; i < 2 && !gsi_end_p (gsi); i++)
-   {
- gimple *g = gsi_stmt (gsi);
- if (!gimple_assign_cast_p (g))
-   return;
- gsi_prev_nondebug ();
+ if (gsi_stmt (gsi) == mul_stmt)
+   {
+ ok = true;
+ break;
+   }
}
-  if (!gsi_end_p (gsi))
+  if (!ok && gimple_assign_cast_p (gsi_stmt (gsi)) && ++cast_count < 4)
+   ok = true;
+  if (!ok)
return;
+  gsi_next_nondebug ();
 }
-  gsi = gsi_for_stmt (div_stmt);
-  gsi_next_nondebug ();
-  if (gsi_stmt (gsi) != cond_stmt)
-return;
   if (gimple_code (cond_stmt) == GIMPLE_COND)
 {
   basic_block succ_bb = other_edge->dest;
@@ -3633,19 +3630,39 @@ maybe_optimize_guarding_check (gimple **
   *cfg_changed = true;
 }
 
+/* Helper function for arith_overflow_check_p.  Return true
+   if VAL1 is equal to VAL2 cast to corresponding integral type
+   with other signedness or vice versa.  */
+
+static bool
+arith_cast_equal_p (tree val1, tree val2)
+{
+  if (TREE_CODE (val1) == INTEGER_CST && TREE_CODE (val2) == INTEGER_CST)
+return wi::eq_p (wi::to_wide (val1), wi::to_wide (val2));
+  else if (TREE_CODE (val1) != SSA_NAME || TREE_CODE (val2) != SSA_NAME)
+return false;
+  if (gimple_assign_cast_p (SSA_NAME_DEF_STMT (val1))
+  && gimple_assign_rhs1 (SSA_NAME_DEF_STMT (val1)) == val2)
+

Re: [PATCH] vregs: Fix up instantiate_virtual_regs_in_insn for asm goto with outputs [PR98603]

[Richard Biener]

On January 9, 2021 10:22:22 AM GMT+01:00, Jakub Jelinek  
wrote:
>Hi!
>
>If an asm insn fails constraint checking during vregs, it is just
>deleted.
>We don't delete asm goto though because of the edges to the labels, so
>instantiate_virtual_regs_in_insn would just remove the inputs and their
>constraints, the pattern etc.
>This worked fine when asm goto couldn't have output operands, but
>causes
>ICEs later on when it has more than one output (and furthermore doesn't
>really remove the problematic outputs).  The problem is that
>for multiple outputs we have a PARALLEL with multiple ASM_OPERANDS, but
>those must use the same ASM_OPERANDS_INPUT_VEC etc., but the code was
>adjusting just one.
>
>The following patch turns invalid asm goto into a bare
>asm goto ("" : : : : lab, lab2, lab3);
>i.e. no inputs/outputs/clobbers, just the labels.
>
>Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

Ok. 

Richard. 

>2021-01-08  Jakub Jelinek  
>
>   PR rtl-optimization/98603
>   * function.c (instantiate_virtual_regs_in_insn): For asm goto
>   with impossible constraints, drop all SETs, CLOBBERs, drop PARALLEL
>   if any, set ASM_OPERANDS mode to VOIDmode and change
>   ASM_OPERANDS_OUTPUT_CONSTRAINT and ASM_OPERANDS_OUTPUT_IDX.
>
>   * gcc.target/i386/pr98603.c: New test.
>   * gcc.target/aarch64/pr98603.c: New test.
>
>--- gcc/function.c.jj  2021-01-04 10:25:37.929244060 +0100
>+++ gcc/function.c 2021-01-08 15:28:42.864335347 +0100
>@@ -1785,12 +1785,16 @@ instantiate_virtual_regs_in_insn (rtx_in
>   {
> error_for_asm (insn, "impossible constraint in %");
> /* For asm goto, instead of fixing up all the edges
>-   just clear the template and clear input operands
>-   (asm goto doesn't have any output operands).  */
>+   just clear the template and clear input and output operands
>+   and strip away clobbers.  */
> if (JUMP_P (insn))
>   {
> rtx asm_op = extract_asm_operands (PATTERN (insn));
>+PATTERN (insn) = asm_op;
>+PUT_MODE (asm_op, VOIDmode);
> ASM_OPERANDS_TEMPLATE (asm_op) = ggc_strdup ("");
>+ASM_OPERANDS_OUTPUT_CONSTRAINT (asm_op) = "";
>+ASM_OPERANDS_OUTPUT_IDX (asm_op) = 0;
> ASM_OPERANDS_INPUT_VEC (asm_op) = rtvec_alloc (0);
> ASM_OPERANDS_INPUT_CONSTRAINT_VEC (asm_op) = rtvec_alloc (0);
>   }
>--- gcc/testsuite/gcc.target/i386/pr98603.c.jj 2021-01-08
>15:36:56.985764842 +0100
>+++ gcc/testsuite/gcc.target/i386/pr98603.c2021-01-08
>15:36:44.301907830 +0100
>@@ -0,0 +1,11 @@
>+/* PR rtl-optimization/98603 */
>+/* { dg-do compile } */
>+/* { dg-options "-O0 -w" } */
>+
>+int
>+foo (void)
>+{
>+  int b, c;
>+  asm goto ("" : "=r" (b), "=r" (c) : "I" (128) : : lab); /* {
>dg-error "impossible constraint in 'asm'" } */
>+lab:;
>+}
>--- gcc/testsuite/gcc.target/aarch64/pr98603.c.jj  2021-01-08
>15:31:31.719431751 +0100
>+++ gcc/testsuite/gcc.target/aarch64/pr98603.c 2021-01-08
>15:31:05.343729099 +0100
>@@ -0,0 +1,11 @@
>+/* PR rtl-optimization/98603 */
>+/* { dg-do compile } */
>+/* { dg-options "-O0" } */
>+
>+int
>+foo (void)
>+{
>+  int b, c;
>+  asm goto ("" : "=R" (b), "=r" (c) : : : lab);   /* { dg-error
>"impossible constraint in 'asm'" } */
>+lab:;
>+}
>
>   Jakub

Re: [PATCH] tree-cfg: Allow enum types as result of POINTER_DIFF_EXPR [PR98556]

[Richard Biener]

On January 9, 2021 10:32:52 AM GMT+01:00, Jakub Jelinek  
wrote:
>Hi!
>
>As conversions between signed integers and signed enums with the same
>precision are useless in GIMPLE, it seems strange that we require that
>POINTER_DIFF_EXPR result must be INTEGER_TYPE.
>
>If we really wanted to require that, we'd need to change the gimplifier
>to ensure that, which it isn't the case on the following testcase.
>What is going on during the gimplification is that when we have the
>(enum T) (p - q) cast, it is stripped through
>  /* Strip away as many useless type conversions as possible
> at the toplevel.  */
>  STRIP_USELESS_TYPE_CONVERSION (*expr_p);
>and when the MODIFY_EXPR is gimplified, the *to_p has enum T type,
>while *from_p has intptr_t type and as there is no conversion in
>between,
>we just create GIMPLE_ASSIGN from that.
>
>Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

Ok also for the branch. 

Thanks, 
Richard. 

>2021-01-08  Jakub Jelinek  
>
>   PR c++/98556
>   * tree-cfg.c (verify_gimple_assign_binary): Allow lhs of
>   POINTER_DIFF_EXPR to be any integral type.
>
>   * c-c++-common/pr98556.c: New test.
>
>--- gcc/tree-cfg.c.jj  2021-01-04 10:25:38.914232907 +0100
>+++ gcc/tree-cfg.c 2021-01-08 15:57:41.605738398 +0100
>@@ -3940,7 +3940,7 @@ verify_gimple_assign_binary (gassign *st
>   /* Because we special-case pointers to void we allow difference
>  of arbitrary pointers with the same mode.  */
>   || TYPE_MODE (rhs1_type) != TYPE_MODE (rhs2_type)
>-  || TREE_CODE (lhs_type) != INTEGER_TYPE
>+  || !INTEGRAL_TYPE_P (lhs_type)
>   || TYPE_UNSIGNED (lhs_type)
>   || TYPE_PRECISION (lhs_type) != TYPE_PRECISION (rhs1_type))
> {
>--- gcc/testsuite/c-c++-common/pr98556.c.jj2021-01-08
>16:03:22.29892 +0100
>+++ gcc/testsuite/c-c++-common/pr98556.c   2021-01-08 16:03:07.715064312
>+0100
>@@ -0,0 +1,11 @@
>+/* PR c++/98556 */
>+/* { dg-do compile } */
>+/* { dg-options "-O0" } */
>+
>+enum T { E = -__LONG_MAX__ - 1 };
>+
>+enum T
>+foo (char *p, char *q)
>+{
>+  return (enum T) (p - q);
>+}
>
>   Jakub

[PATCH] tree-cfg: Allow enum types as result of POINTER_DIFF_EXPR [PR98556]

[Jakub Jelinek via Gcc-patches]

Hi!

As conversions between signed integers and signed enums with the same
precision are useless in GIMPLE, it seems strange that we require that
POINTER_DIFF_EXPR result must be INTEGER_TYPE.

If we really wanted to require that, we'd need to change the gimplifier
to ensure that, which it isn't the case on the following testcase.
What is going on during the gimplification is that when we have the
(enum T) (p - q) cast, it is stripped through
  /* Strip away as many useless type conversions as possible
 at the toplevel.  */
  STRIP_USELESS_TYPE_CONVERSION (*expr_p);
and when the MODIFY_EXPR is gimplified, the *to_p has enum T type,
while *from_p has intptr_t type and as there is no conversion in between,
we just create GIMPLE_ASSIGN from that.

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

2021-01-08  Jakub Jelinek  

PR c++/98556
* tree-cfg.c (verify_gimple_assign_binary): Allow lhs of
POINTER_DIFF_EXPR to be any integral type.

* c-c++-common/pr98556.c: New test.

--- gcc/tree-cfg.c.jj   2021-01-04 10:25:38.914232907 +0100
+++ gcc/tree-cfg.c  2021-01-08 15:57:41.605738398 +0100
@@ -3940,7 +3940,7 @@ verify_gimple_assign_binary (gassign *st
/* Because we special-case pointers to void we allow difference
   of arbitrary pointers with the same mode.  */
|| TYPE_MODE (rhs1_type) != TYPE_MODE (rhs2_type)
-   || TREE_CODE (lhs_type) != INTEGER_TYPE
+   || !INTEGRAL_TYPE_P (lhs_type)
|| TYPE_UNSIGNED (lhs_type)
|| TYPE_PRECISION (lhs_type) != TYPE_PRECISION (rhs1_type))
  {
--- gcc/testsuite/c-c++-common/pr98556.c.jj 2021-01-08 16:03:22.29892 
+0100
+++ gcc/testsuite/c-c++-common/pr98556.c2021-01-08 16:03:07.715064312 
+0100
@@ -0,0 +1,11 @@
+/* PR c++/98556 */
+/* { dg-do compile } */
+/* { dg-options "-O0" } */
+
+enum T { E = -__LONG_MAX__ - 1 };
+
+enum T
+foo (char *p, char *q)
+{
+  return (enum T) (p - q);
+}

Jakub

[PATCH] vregs: Fix up instantiate_virtual_regs_in_insn for asm goto with outputs [PR98603]

[Jakub Jelinek via Gcc-patches]

Hi!

If an asm insn fails constraint checking during vregs, it is just deleted.
We don't delete asm goto though because of the edges to the labels, so
instantiate_virtual_regs_in_insn would just remove the inputs and their
constraints, the pattern etc.
This worked fine when asm goto couldn't have output operands, but causes
ICEs later on when it has more than one output (and furthermore doesn't
really remove the problematic outputs).  The problem is that
for multiple outputs we have a PARALLEL with multiple ASM_OPERANDS, but
those must use the same ASM_OPERANDS_INPUT_VEC etc., but the code was
adjusting just one.

The following patch turns invalid asm goto into a bare
asm goto ("" : : : : lab, lab2, lab3);
i.e. no inputs/outputs/clobbers, just the labels.

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

2021-01-08  Jakub Jelinek  

PR rtl-optimization/98603
* function.c (instantiate_virtual_regs_in_insn): For asm goto
with impossible constraints, drop all SETs, CLOBBERs, drop PARALLEL
if any, set ASM_OPERANDS mode to VOIDmode and change
ASM_OPERANDS_OUTPUT_CONSTRAINT and ASM_OPERANDS_OUTPUT_IDX.

* gcc.target/i386/pr98603.c: New test.
* gcc.target/aarch64/pr98603.c: New test.

--- gcc/function.c.jj   2021-01-04 10:25:37.929244060 +0100
+++ gcc/function.c  2021-01-08 15:28:42.864335347 +0100
@@ -1785,12 +1785,16 @@ instantiate_virtual_regs_in_insn (rtx_in
{
  error_for_asm (insn, "impossible constraint in %");
  /* For asm goto, instead of fixing up all the edges
-just clear the template and clear input operands
-(asm goto doesn't have any output operands).  */
+just clear the template and clear input and output operands
+and strip away clobbers.  */
  if (JUMP_P (insn))
{
  rtx asm_op = extract_asm_operands (PATTERN (insn));
+ PATTERN (insn) = asm_op;
+ PUT_MODE (asm_op, VOIDmode);
  ASM_OPERANDS_TEMPLATE (asm_op) = ggc_strdup ("");
+ ASM_OPERANDS_OUTPUT_CONSTRAINT (asm_op) = "";
+ ASM_OPERANDS_OUTPUT_IDX (asm_op) = 0;
  ASM_OPERANDS_INPUT_VEC (asm_op) = rtvec_alloc (0);
  ASM_OPERANDS_INPUT_CONSTRAINT_VEC (asm_op) = rtvec_alloc (0);
}
--- gcc/testsuite/gcc.target/i386/pr98603.c.jj  2021-01-08 15:36:56.985764842 
+0100
+++ gcc/testsuite/gcc.target/i386/pr98603.c 2021-01-08 15:36:44.301907830 
+0100
@@ -0,0 +1,11 @@
+/* PR rtl-optimization/98603 */
+/* { dg-do compile } */
+/* { dg-options "-O0 -w" } */
+
+int
+foo (void)
+{
+  int b, c;
+  asm goto ("" : "=r" (b), "=r" (c) : "I" (128) : : lab);  /* { dg-error 
"impossible constraint in 'asm'" } */
+lab:;
+}
--- gcc/testsuite/gcc.target/aarch64/pr98603.c.jj   2021-01-08 
15:31:31.719431751 +0100
+++ gcc/testsuite/gcc.target/aarch64/pr98603.c  2021-01-08 15:31:05.343729099 
+0100
@@ -0,0 +1,11 @@
+/* PR rtl-optimization/98603 */
+/* { dg-do compile } */
+/* { dg-options "-O0" } */
+
+int
+foo (void)
+{
+  int b, c;
+  asm goto ("" : "=R" (b), "=r" (c) : : : lab);/* { dg-error 
"impossible constraint in 'asm'" } */
+lab:;
+}

Jakub

[PATCH] widening_mul: Pattern recognize unsigned multiplication with overflow check [PR95852]

[Jakub Jelinek via Gcc-patches]

Hi!

The following patch pattern recognizes some forms of multiplication followed
by overflow check through division by one of the operands compared to the
other one, with optional removal of guarding non-zero check for that operand
if possible.  The patterns are replaced with effectively
__builtin_mul_overflow or __builtin_mul_overflow_p.  The testcases cover 64
different forms of that.

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

2021-01-08  Jakub Jelinek  

PR tree-optimization/95852
* tree-ssa-math-opts.c (maybe_optimize_guarding_check): New function.
(uaddsub_overflow_check_p): Renamed to ...
(arith_overflow_check_p): ... this.  Handle also multiplication
with overflow check.
(match_uaddsub_overflow): Renamed to ...
(match_arith_overflow): ... this.  Add cfg_changed argument.  Handle
also multiplication with overflow check.  Adjust function comment.
(math_opts_dom_walker::after_dom_children): Adjust callers.  Call
match_arith_overflow also for MULT_EXPR.

* gcc.target/i386/pr95852-1.c: New test.

--- gcc/tree-ssa-math-opts.c.jj 2021-01-08 12:27:46.066177063 +0100
+++ gcc/tree-ssa-math-opts.c2021-01-08 14:39:11.872358339 +0100
@@ -3451,17 +3451,228 @@ convert_mult_to_fma (gimple *mul_stmt, t
 }
 
 
-/* Helper function of match_uaddsub_overflow.  Return 1
+/* Helper function of match_arith_overflow.  For MUL_OVERFLOW, if we have
+   a check for non-zero like:
+   _1 = x_4(D) * y_5(D);
+   *res_7(D) = _1;
+   if (x_4(D) != 0)
+ goto ; [50.00%]
+   else
+ goto ; [50.00%]
+
+[local count: 536870913]:
+   _2 = _1 / x_4(D);
+   _9 = _2 != y_5(D);
+   _10 = (int) _9;
+
+[local count: 1073741824]:
+   # iftmp.0_3 = PHI <_10(3), 0(2)>
+   then in addition to using .MUL_OVERFLOW (x_4(D), y_5(D)) we can also
+   optimize the x_4(D) != 0 condition to 1.  */
+
+static void
+maybe_optimize_guarding_check (gimple **mul_stmts, gimple *cond_stmt,
+  gimple *div_stmt, bool *cfg_changed)
+{
+  basic_block bb = gimple_bb (cond_stmt);
+  if (gimple_bb (div_stmt) != bb || !single_pred_p (bb))
+return;
+  edge pred_edge = single_pred_edge (bb);
+  basic_block pred_bb = pred_edge->src;
+  if (EDGE_COUNT (pred_bb->succs) != 2)
+return;
+  edge other_edge = EDGE_SUCC (pred_bb, EDGE_SUCC (pred_bb, 0) == pred_edge);
+  edge other_succ_edge = NULL;
+  if (gimple_code (cond_stmt) == GIMPLE_COND)
+{
+  if (EDGE_COUNT (bb->succs) != 2)
+   return;
+  other_succ_edge = EDGE_SUCC (bb, 0);
+  if (gimple_cond_code (cond_stmt) == NE_EXPR)
+   {
+ if (other_succ_edge->flags & EDGE_TRUE_VALUE)
+   other_succ_edge = EDGE_SUCC (bb, 1);
+   }
+  else if (other_succ_edge->flags & EDGE_FALSE_VALUE)
+   other_succ_edge = EDGE_SUCC (bb, 0);
+  if (other_edge->dest != other_succ_edge->dest)
+   return;
+}
+  else if (!single_succ_p (bb) || other_edge->dest != single_succ (bb))
+return;
+  gimple *zero_cond = last_stmt (pred_bb);
+  if (zero_cond == NULL
+  || gimple_code (zero_cond) != GIMPLE_COND
+  || (gimple_cond_code (zero_cond)
+ != ((pred_edge->flags & EDGE_TRUE_VALUE) ? NE_EXPR : EQ_EXPR))
+  || !integer_zerop (gimple_cond_rhs (zero_cond)))
+return;
+  tree zero_cond_lhs = gimple_cond_lhs (zero_cond);
+  if (TREE_CODE (zero_cond_lhs) != SSA_NAME)
+return;
+  if (gimple_assign_rhs2 (div_stmt) != zero_cond_lhs)
+{
+  /* Allow the divisor to be result of a same precision cast
+from zero_cond_lhs.  */
+  tree rhs2 = gimple_assign_rhs2 (div_stmt);
+  if (TREE_CODE (rhs2) != SSA_NAME)
+   return;
+  gimple *g = SSA_NAME_DEF_STMT (rhs2);
+  if (!gimple_assign_cast_p (g)
+ || gimple_assign_rhs1 (g) != gimple_cond_lhs (zero_cond)
+ || !INTEGRAL_TYPE_P (TREE_TYPE (zero_cond_lhs))
+ || (TYPE_PRECISION (TREE_TYPE (zero_cond_lhs))
+ != TYPE_PRECISION (TREE_TYPE (rhs2
+   return;
+}
+  gimple_stmt_iterator gsi = gsi_for_stmt (div_stmt);
+  gsi_prev_nondebug ();
+  if (!gsi_end_p (gsi))
+{
+  /* If original mul_stmt has a single use, allow it in the same bb,
+we are looking then just at __builtin_mul_overflow_p.
+Though, in that case the original mul_stmt will be replaced
+by .MUL_OVERFLOW, REALPART_EXPR and IMAGPART_EXPR stmts.  */
+  for (int i = 2; i >= 0; --i)
+   {
+ if (gsi_stmt (gsi) != mul_stmts[i])
+   return;
+ gsi_prev_nondebug ();
+   }
+  /* Allow up to 2 extra casts.  Given the way we check PHIs,
+nothing from this bb should be consumed by any other bb
+anyway.  */
+  for (int i = 0; i < 2 && !gsi_end_p (gsi); i++)
+   {
+ gimple *g = gsi_stmt (gsi);
+ if (!gimple_assign_cast_p (g))
+   return;
+ gsi_prev_nondebug ();
+   }
+  if (!gsi_end_p (gsi))
+   return;