Re: [PATCH V4 02/11] opt-functions.awk: fix comparison of limit, begin and end

[Ulrich Drepper]

On Wed, Aug 28, 2019 at 1:47 AM Jose E. Marchesi 
wrote:

>  function integer_range_info(range_option, init, option)
>  {
>  if (range_option != "") {
> -   start = nth_arg(0, range_option);
> -   end = nth_arg(1, range_option);
> +   init = init + 0;
> +   start = nth_arg(0, range_option) + 0;
> +   end = nth_arg(1, range_option) + 0;
> if (init != "" && init != "-1" && (init < start || init > end))


In this case the test for init != "" is at least unnecessary.

Maybe something else has to be used.  I didn't trace the uses but if init
is deliberately set to "" then the test would have to be replaced with init
!= 0.

[Bug c++/16994] [meta-bug] VLA and C++

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16994
Bug 16994 depends on bug 91002, which changed state.

Bug 91002 Summary: ICE in make_ssa_name_fn, at tree-ssanames.c:271 with VLA 
type in reinterpret_cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91002

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

[Bug c++/88256] [7/8/9/10 Regression] ICE: Segmentation fault (in make_ssa_name_fn) with VLA cast, C++ FE missing DECL_EXPRs

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88256

Eric Gallager  changed:

   What|Removed |Added

 CC||ignat.loskutov at gmail dot com

--- Comment #11 from Eric Gallager  ---
*** Bug 91002 has been marked as a duplicate of this bug. ***

[Bug c++/91002] ICE in make_ssa_name_fn, at tree-ssanames.c:271 with VLA type in reinterpret_cast

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91002

Eric Gallager  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||egallager at gcc dot gnu.org
 Blocks||16994
 Depends on|16994   |
 Resolution|--- |DUPLICATE

--- Comment #4 from Eric Gallager  ---
Does this really require every single other bug with C++ VLAs to be fixed first
before it can be closed? I think rather that the "Depends on" and "Blocks"
fields are switched; so I'm correcting them now.

(In reply to Arseny Solokha from comment #3)
> (In reply to Richard Biener from comment #2)
> > One of the many duplicates with VLAs
> > missing DECL_EXPRs.
> 
> Namely, PR88256.

Closing as a dup of it then.

*** This bug has been marked as a duplicate of bug 88256 ***


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16994
[Bug 16994] [meta-bug] VLA and C++

[Bug middle-end/91515] missed optimization: no tailcall for types of class MEMORY

[peter at cordes dot ca]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91515

Peter Cordes  changed:

   What|Removed |Added

 CC||peter at cordes dot ca

--- Comment #1 from Peter Cordes  ---
The real missed optimization is that GCC is returning its own incoming arg
instead of returning the copy of it that create() will return in RAX.

This is what blocks tailcall optimization; it doesn't "trust" the callee to
return what it's passing as RDI.

See https://stackoverflow.com/a/57597039/224132 for my analysis (the OP asked
the same thing on SO before reporting this, but forgot to link it in the bug
report.)

The RAX return value tends to rarely be used, but probably it should be; it's
less likely to have just been reloaded recently.

RAX is more likely to be ready sooner than R12 for out-of-order exec.  Either
reloaded earlier (still in the callee somewhere if it's complex and/or
non-leaf) or never spilled/reloaded.

So we're not even gaining a benefit from saving/restoring R12 to hold our
incoming RDI.  Thus it's not worth the extra cost (in code-size and
instructions executed), IMO.  Trust the callee to return the pointer in RAX.

[Bug tree-optimization/91571] New: TBAA does not work for ao_ref created by ao_ref_init_from_ptr_and_size()

[fxue at os dot amperecomputing.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91571

Bug ID: 91571
   Summary: TBAA does not work for ao_ref created by
ao_ref_init_from_ptr_and_size()
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fxue at os dot amperecomputing.com
  Target Milestone: ---

Given a SSA_NAME pointer, its type information is discarded by
ao_ref_init_from_ptr_and_size() when building an ao_ref from the pointer, thus
TBAA for this kind of ao_ref is actually disabled. Related code snippet:

  else
{
  gcc_assert (POINTER_TYPE_P (TREE_TYPE (ptr)));
  ref->base = build2 (MEM_REF, char_type_node,
  ptr, null_pointer_node);
  ..
}
  .
  ref->ref_alias_set = 0;
  ref->base_alias_set = 0;

If enabled, some optimizations relying on this could produce better result.
Here is an example for IPA-CP, but not just it (others include dse,
strlen-opt).

struct A
{
   int a;
};

struct B
{
   int b;
};

void f2 (struct A *pa, struct B *pb)
{
   ...
}

void f1(int v, struct A *pa, struct B *pb)
{
  pa->a = 1;
  pb->b = v;

  f2 (pa, pb);
}

The ao_ref for f2's argument "pa" is setup by ao_ref_init_from_ptr_and_size(),
AA can not disambiguate pa->a and pb->b due to loss of original type
information, and IPA-CP gets a conservative conclusion that constant "1"
assigned to pa->a can not reach f2(pa, pb), then misses a chance of constant
propagation.

I check uses of ao_ref_init_from_ptr_and_size(), it is mainly used in alias
analysis on function call arguments. That's better to enable TBAA in this
scenario, but not sure is there any special consideration about it?

[Bug c/91206] -Wformat doesn't warn for %hd with char parameter

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91206

--- Comment #6 from Eric Gallager  ---
(In reply to Eric Gallager from comment #5)
> (In reply to Nick Desaulniers from comment #4)
> > Thanks for the feedback, in https://reviews.llvm.org/rL369791, Nathan made
> > [unsigned] char -> [unsigned]short warn only for -Wformat-pedantic, not
> > -Wformat.
> 
> there's a request for GCC to support -Wformat-pedantic, too, in bug 67479,
> so IMO this bug should stay open as a reminder to make GCC's
> -Wformat-pedantic warn on this, too, once the flag is added.

...or maybe, if leaving this one closed, at least mark it as a dup of bug 67479

[Bug c/91206] -Wformat doesn't warn for %hd with char parameter

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91206

--- Comment #5 from Eric Gallager  ---
(In reply to Nick Desaulniers from comment #4)
> Thanks for the feedback, in https://reviews.llvm.org/rL369791, Nathan made
> [unsigned] char -> [unsigned]short warn only for -Wformat-pedantic, not
> -Wformat.

there's a request for GCC to support -Wformat-pedantic, too, in bug 67479, so
IMO this bug should stay open as a reminder to make GCC's -Wformat-pedantic
warn on this, too, once the flag is added.

[Bug c++/81676] Wrong warning with unused-but-set-parameter within 'if constexpr'

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81676

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Marek Polacek  ---
Fixed.

[Bug c/89180] [meta-bug] bogus/missing -Wunused warnings

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89180
Bug 89180 depends on bug 81676, which changed state.

Bug 81676 Summary: Wrong warning with unused-but-set-parameter within 'if 
constexpr'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81676

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

[Bug c++/81676] Wrong warning with unused-but-set-parameter within 'if constexpr'

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81676

--- Comment #6 from Marek Polacek  ---
Author: mpolacek
Date: Wed Aug 28 02:22:29 2019
New Revision: 274982

URL: https://gcc.gnu.org/viewcvs?rev=274982=gcc=rev
Log:
PR c++/81676 - bogus -Wunused warnings in constexpr if.
* semantics.c (maybe_mark_exp_read_r): New function.
(finish_if_stmt): Call it on THEN_CLAUSE and ELSE_CLAUSE.

* g++.dg/cpp1z/constexpr-if31.C: New test.
* g++.dg/cpp1z/constexpr-if32.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp1z/constexpr-if31.C
trunk/gcc/testsuite/g++.dg/cpp1z/constexpr-if32.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/semantics.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/87403] [Meta-bug] Issues that suggest a new warning

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403
Bug 87403 depends on bug 91428, which changed state.

Bug 91428 Summary: Please warn on if constexpr (std::is_constant_evaluated())
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91428

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

[Bug c++/91428] Please warn on if constexpr (std::is_constant_evaluated())

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91428

Marek Polacek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Marek Polacek  ---
Done in GCC 10.1.

[Bug c++/91428] Please warn on if constexpr (std::is_constant_evaluated())

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91428

--- Comment #3 from Marek Polacek  ---
Author: mpolacek
Date: Wed Aug 28 02:03:48 2019
New Revision: 274981

URL: https://gcc.gnu.org/viewcvs?rev=274981=gcc=rev
Log:
PR c++/91428 - warn about std::is_constant_evaluated in if constexpr.
* cp-tree.h (decl_in_std_namespace_p): Declare.
* semantics.c (is_std_constant_evaluated_p): New.
(finish_if_stmt_cond): Warn about "std::is_constant_evaluated ()" in
an if-constexpr.
* typeck.c (decl_in_std_namespace_p): No longer static.

* g++.dg/cpp2a/is-constant-evaluated9.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp2a/is-constant-evaluated9.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/semantics.c
trunk/gcc/cp/typeck.c
trunk/gcc/testsuite/ChangeLog

Re: C++ PATCH for c++/91428 - warn about std::is_constant_evaluated in if constexpr

[Jason Merrill]

On Tue, Aug 27, 2019 at 5:50 PM Marek Polacek  wrote:
>
> As discussed in 91428 and in
> ,
>
>   if constexpr (std::is_constant_evaluated ())
> // ...
>   else
> // ...
>
> always evaluates the true branch.  Someone in the SO post said "But hopefully
> compilers will just diagnose that case" so I'm adding a warning.
>
> I didn't want to invent a completely new warning so I'm tagging along
> -Wtautological-compare.
>
> Bootstrapped/regtested on x86_64-linux, ok for trunk?

OK.

Jason

Re: C++ PATCH for c++/81676 - bogus -Wunused warnings in constexpr if

[Jason Merrill]

On Tue, Aug 27, 2019 at 4:10 PM Marek Polacek  wrote:
> On Fri, Aug 23, 2019 at 02:20:53PM -0700, Jason Merrill wrote:
> > On 8/19/19 11:28 AM, Marek Polacek wrote:
> > > On Fri, Aug 16, 2019 at 06:20:20PM -0700, Jason Merrill wrote:
> > > > On 8/16/19 2:29 PM, Marek Polacek wrote:
> > > > > This patch is an attempt to fix the annoying -Wunused-but-set-* 
> > > > > warnings that
> > > > > tend to occur with constexpr if.  When we have something like
> > > > >
> > > > > template < typename T >
> > > > > int f(T v){
> > > > > if constexpr(sizeof(T) == sizeof(int)){
> > > > >   return v;
> > > > > }else{
> > > > >   return 0;
> > > > > }
> > > > > }
> > > > >
> > > > > and call f('a'), then the condition is false, meaning that we won't 
> > > > > instantiate
> > > > > the then-branch, as per tsubst_expr/IF_STMT:
> > > > > 17284   if (IF_STMT_CONSTEXPR_P (t) && integer_zerop (tmp))
> > > > > 17285 /* Don't instantiate the THEN_CLAUSE. */;
> > > > > so we'll never get round to mark_exp_read-ing the decls used in the
> > > > > then-branch, causing finish_function to emit "parameter set but not 
> > > > > used"
> > > > > warnings.
> > > > >
> > > > > It's unclear how to best deal with this.  Marking the decls 
> > > > > DECL_READ_P while
> > > > > parsing doesn't seem like a viable approach
> > > >
> > > > Why not?
> > >
> > > Well, while parsing, we're in a template and so the condition won't be
> > > evaluated until tsubst_expr.  So we can't tell which branch is dead.
> >
> > But if a decl is used on one branch, we shouldn't warn even if it isn't used
> > on the selected branch.
>
> I didn't want to mark the decls as read multiple times but we do it anyway
> so that's no longer my concern.  So...
>
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
>
> 2019-08-27  Marek Polacek  
>
> PR c++/81676 - bogus -Wunused warnings in constexpr if.
> * semantics.c (maybe_mark_exp_read_r): New function.
> (finish_if_stmt): Call it on THEN_CLAUSE and ELSE_CLAUSE.

I was thinking of adding mark_exp_read to places where we currently
take a shortcut in templates, like check_return_expr or
build_x_binary_op, but this is probably simpler.  The patch is OK.

Jason

[PATCH] PR fortran/91551 -- ALLOCATED has one argument

[Steve Kargl]

The attach patch was built and tested on i586-*-freebsd.
It includes a check for ALLOCATED with no arguments.
OK to commit?

2019-08-28  Steven G. Kargl  

PR fortran/91551
* intrinsic.c (sort_actual): ALLOCATED has one argument. Check for
no argument case.

2019-08-28  Steven G. Kargl  

PR fortran/91551
* gfortran.dg/allocated_3.f90

-- 
Steve
Index: gcc/fortran/intrinsic.c
===
--- gcc/fortran/intrinsic.c	(revision 274900)
+++ gcc/fortran/intrinsic.c	(working copy)
@@ -4190,35 +4190,45 @@ sort_actual (const char *name, gfc_actual_arglist **ap
 
   /* ALLOCATED has two mutually exclusive keywords, but only one
  can be present at time and neither is optional. */
-  if (strcmp (name, "allocated") == 0 && a->name)
+  if (strcmp (name, "allocated") == 0)
 {
-  if (strcmp (a->name, "scalar") == 0)
+  if (!a)
 	{
-  if (a->next)
-	goto whoops;
-	  if (a->expr->rank != 0)
-	{
-	  gfc_error ("Scalar entity required at %L", >expr->where);
-	  return false;
-	}
-  return true;
+	  gfc_error ("ALLOCATED intrinsic at %L requires an array or scalar "
+		 "allocatable entity", where);
+	  return false;
 	}
-  else if (strcmp (a->name, "array") == 0)
+
+  if (a->name)
 	{
-  if (a->next)
-	goto whoops;
-	  if (a->expr->rank == 0)
+	  if (strcmp (a->name, "scalar") == 0)
 	{
-	  gfc_error ("Array entity required at %L", >expr->where);
+	  if (a->next)
+		goto whoops;
+	  if (a->expr->rank != 0)
+		{
+		  gfc_error ("Scalar entity required at %L", >expr->where);
+		  return false;
+		}
+	  return true;
+	}
+	  else if (strcmp (a->name, "array") == 0)
+	{
+	  if (a->next)
+		goto whoops;
+	  if (a->expr->rank == 0)
+		{
+		  gfc_error ("Array entity required at %L", >expr->where);
+		  return false;
+		}
+	  return true;
+	}
+	  else
+	{
+	  gfc_error ("Invalid keyword %qs in %qs intrinsic function at %L",
+			 a->name, name, >expr->where);
 	  return false;
 	}
-  return true;
-	}
-  else
-	{
-	  gfc_error ("Invalid keyword %qs in %qs intrinsic function at %L",
-		 a->name, name, >expr->where);
-	  return false;
 	}
 }
 
Index: gcc/testsuite/gfortran.dg/allocated_3.f90
===
--- gcc/testsuite/gfortran.dg/allocated_3.f90	(nonexistent)
+++ gcc/testsuite/gfortran.dg/allocated_3.f90	(working copy)
@@ -0,0 +1,6 @@
+! { dg-do compile }
+! PR fortran/91551
+! Contributed by Gerhard Steinmetz
+program p
+   if (allocated()) stop 1 ! { dg-error "requires an array or scalar allocatable" }
+end

[PATCH] PR fortran/91564 -- Additonal checks on STATUS

[Steve Kargl]

The attached patch has been built and tested on x86_64-*-freebsd.
It adds additional checks for the status dummy argument, and
therby prevents an ICE.  OK to commit?

2019-08-27  Steven G. Kargl  

PR fortran/91564
* check.c (gfc_check_kill_sub): Additional checks on status dummy
argument.

2019-08-27  Steven G. Kargl  

PR fortran/91564
* gfortran.dg/pr91564.f90: New test.
-- 
Steve
Index: gcc/fortran/check.c
===
--- gcc/fortran/check.c	(revision 274961)
+++ gcc/fortran/check.c	(working copy)
@@ -3301,6 +3301,22 @@ gfc_check_kill_sub (gfc_expr *pid, gfc_expr *sig, gfc_
 
   if (!scalar_check (status, 2))
 	return false;
+
+  if (status->expr_type != EXPR_VARIABLE)
+	{
+	  gfc_error ("STATUS at %L shall be an INTENT(OUT) variable",
+		 >where);
+	  return false;
+	}
+
+  if (status->expr_type == EXPR_VARIABLE
+	  && status->symtree && status->symtree->n.sym
+	  && status->symtree->n.sym->attr.intent == INTENT_IN)
+	{
+	  gfc_error ("%qs at %L shall be an INTENT(OUT) variable",
+		 status->symtree->name, >where);
+	  return false;
+	}
 }
 
   return true;
Index: gcc/testsuite/gfortran.dg/pr91564.f90
===
--- gcc/testsuite/gfortran.dg/pr91564.f90	(nonexistent)
+++ gcc/testsuite/gfortran.dg/pr91564.f90	(working copy)
@@ -0,0 +1,16 @@
+! { dg-do compile }
+! PR fortran/91564
+! Contributed by Gerhard Steinmetz.
+program p
+   integer i, j
+   call kill (1, 2, 3)! { dg-error "shall be an INTENT" }
+   i = 42
+   call bar(i, j)
+end
+
+subroutine bar(n, m)
+   integer, intent(in) :: n
+   integer, intent(inout) :: m
+   call kill (1, 3, n)! { dg-error "shall be an INTENT" }
+   call kill (1, 3, m)
+end subroutine bar

[Bug fortran/91564] [8/9/10 Regression] ICE in gimplify_expr, at gimplify.c:14147

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91564

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-08-28
 CC||kargl at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from kargl at gcc dot gnu.org ---
I have a patch.

Re: [PATCH V4 00/11] eBPF support for GCC

[Jose E. Marchesi]

. The mul32 instruction zero-extends arguments and then performs
  a multiplication.  Use the right pattern for this in bpf.md and
  name it umulsidi3.

Sorry, here I meant to say that the mul32 instruction multiplies and
then zero-extends its result.

[PATCH V4 05/11] bpf: new GCC port

[Jose E. Marchesi]

This patch adds a port for the Linux kernel eBPF architecture to GCC.

ChangeLog:

  * configure.ac: Support for bpf-*-* targets.
  * configure: Regenerate.

contrib/ChangeLog:

  * config-list.mk (LIST): Disable go in bpf-*-* targets.

gcc/ChangeLog:

  * config.gcc: Support for bpf-*-* targets.
  * common/config/bpf/bpf-common.c: New file.
  * config/bpf/t-bpf: Likewise.
  * config/bpf/predicates.md: Likewise.
  * config/bpf/constraints.md: Likewise.
  * config/bpf/bpf.opt: Likewise.
  * config/bpf/bpf.md: Likewise.
  * config/bpf/bpf.h: Likewise.
  * config/bpf/bpf.c: Likewise.
  * config/bpf/bpf-protos.h: Likewise.
  * config/bpf/bpf-opts.h: Likewise.
  * config/bpf/bpf-helpers.h: Likewise.
  * config/bpf/bpf-helpers.def: Likewise.
---
 ChangeLog  |   5 +
 configure  |  54 ++-
 configure.ac   |  54 ++-
 contrib/ChangeLog  |   4 +
 contrib/config-list.mk |   3 +-
 gcc/ChangeLog  |  16 +
 gcc/common/config/bpf/bpf-common.c |  55 +++
 gcc/config.gcc |   9 +
 gcc/config/bpf/bpf-helpers.def | 194 
 gcc/config/bpf/bpf-helpers.h   | 327 +
 gcc/config/bpf/bpf-opts.h  |  56 +++
 gcc/config/bpf/bpf-protos.h|  33 ++
 gcc/config/bpf/bpf.c   | 958 +
 gcc/config/bpf/bpf.h   | 532 
 gcc/config/bpf/bpf.md  | 497 +++
 gcc/config/bpf/bpf.opt | 123 +
 gcc/config/bpf/constraints.md  |  32 ++
 gcc/config/bpf/predicates.md   |  72 +++
 gcc/config/bpf/t-bpf   |   0
 19 files changed, 3021 insertions(+), 3 deletions(-)
 create mode 100644 gcc/common/config/bpf/bpf-common.c
 create mode 100644 gcc/config/bpf/bpf-helpers.def
 create mode 100644 gcc/config/bpf/bpf-helpers.h
 create mode 100644 gcc/config/bpf/bpf-opts.h
 create mode 100644 gcc/config/bpf/bpf-protos.h
 create mode 100644 gcc/config/bpf/bpf.c
 create mode 100644 gcc/config/bpf/bpf.h
 create mode 100644 gcc/config/bpf/bpf.md
 create mode 100644 gcc/config/bpf/bpf.opt
 create mode 100644 gcc/config/bpf/constraints.md
 create mode 100644 gcc/config/bpf/predicates.md
 create mode 100644 gcc/config/bpf/t-bpf

diff --git a/configure.ac b/configure.ac
index 1fe97c001cc..b8ce2ad20b9 100644
--- a/configure.ac
+++ b/configure.ac
@@ -638,6 +638,9 @@ case "${target}" in
 # No hosted I/O support.
 noconfigdirs="$noconfigdirs target-libssp"
 ;;
+  bpf-*-*)
+noconfigdirs="$noconfigdirs target-libssp"
+;;
   powerpc-*-aix* | rs6000-*-aix*)
 noconfigdirs="$noconfigdirs target-libssp"
 ;;
@@ -672,12 +675,43 @@ if test "${ENABLE_LIBSTDCXX}" = "default" ; then
 avr-*-*)
   noconfigdirs="$noconfigdirs target-libstdc++-v3"
   ;;
+bpf-*-*)
+  noconfigdirs="$noconfigdirs target-libstdc++-v3"
+  ;;
 ft32-*-*)
   noconfigdirs="$noconfigdirs target-libstdc++-v3"
   ;;
   esac
 fi
 
+# Disable C++ on systems where it is known to not work.
+# For testing, you can override this with --enable-languages=c++.
+case ,${enable_languages}, in
+  *,c++,*)
+;;
+  *)
+  case "${target}" in
+bpf-*-*)
+  unsupported_languages="$unsupported_languages c++"
+  ;;
+  esac
+  ;;
+esac
+
+# Disable Objc on systems where it is known to not work.
+# For testing, you can override this with --enable-languages=objc.
+case ,${enable_languages}, in
+  *,objc,*)
+;;
+  *)
+  case "${target}" in
+bpf-*-*)
+  unsupported_languages="$unsupported_languages objc"
+  ;;
+  esac
+  ;;
+esac
+
 # Disable D on systems where it is known to not work.
 # For testing, you can override this with --enable-languages=d.
 case ,${enable_languages}, in
@@ -687,6 +721,9 @@ case ,${enable_languages}, in
 case "${target}" in
   *-*-darwin*)
unsupported_languages="$unsupported_languages d"
+;;
+  bpf-*-*)
+   unsupported_languages="$unsupported_languages d"
;;
 esac
 ;;
@@ -715,6 +752,9 @@ case "${target}" in
 # See .
 unsupported_languages="$unsupported_languages fortran"
 ;;
+  bpf-*-*)
+unsupported_languages="$unsupported_languages fortran"
+;;
 esac
 
 # Disable libffi for some systems.
@@ -761,6 +801,9 @@ case "${target}" in
   arm*-*-symbianelf*)
 noconfigdirs="$noconfigdirs target-libffi"
 ;;
+  bpf-*-*)
+noconfigdirs="$noconfigdirs target-libffi"
+;;
   cris-*-* | crisv32-*-*)
 case "${target}" in
   *-*-linux*)
@@ -807,7 +850,7 @@ esac
 # Disable the go frontend on systems where it is known to not work. Please keep
 # this in sync with contrib/config-list.mk.
 case "${target}" in
-*-*-darwin* | *-*-cygwin* | *-*-mingw*)
+*-*-darwin* | *-*-cygwin* | *-*-mingw* | bpf-* )
 unsupported_languages="$unsupported_languages go"
  

[PATCH V4 02/11] opt-functions.awk: fix comparison of limit, begin and end

[Jose E. Marchesi]

The function integer_range_info makes sure that, if provided, the
initial value fills in the especified range.  However, it is necessary
to convert the values to a numerical context before comparing, to make
sure awk is using arithmetical order and not lexicographical order.

gcc/ChangeLog:

* opt-functions.awk (integer_range_info): Make sure values are in
numeric context before operating with them.
---
 gcc/ChangeLog | 5 +
 gcc/opt-functions.awk | 5 +++--
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/gcc/opt-functions.awk b/gcc/opt-functions.awk
index 1190e6d6b66..0b28a6c3bff 100644
--- a/gcc/opt-functions.awk
+++ b/gcc/opt-functions.awk
@@ -346,8 +346,9 @@ function search_var_name(name, opt_numbers, opts, flags, 
n_opts)
 function integer_range_info(range_option, init, option)
 {
 if (range_option != "") {
-   start = nth_arg(0, range_option);
-   end = nth_arg(1, range_option);
+   init = init + 0;
+   start = nth_arg(0, range_option) + 0;
+   end = nth_arg(1, range_option) + 0;
if (init != "" && init != "-1" && (init < start || init > end))
  print "#error initial value " init " of '" option "' must be in range 
[" start "," end "]"
return start ", " end
-- 
2.11.0

[PATCH V4 09/11] bpf: adjust GCC testsuite to eBPF limitations

[Jose E. Marchesi]

This patch makes many tests in gcc.dg and gcc.c-torture to be skipped
in bpf-*-* targets.  This is due to the many limitations imposed by
eBPF to what would be perfectly valid C code: no support for more than
5 arguments to function calls, no support for indirect jumps, a very
limited range for direct jumps, etc.

Hopefully some of these restrictions will be relaxed in the future.
Also, as semantics associated with object linking get developed in
eBPF, it may be possible at some point to provide a set of standard
run-time libraries for eBPF programs.

gcc/testsuite/ChangeLog:

* gcc.dg/builtins-config.h: eBPF doesn't support C99 standard
functions.
* gcc.c-torture/compile/20101217-1.c: Add a function prototype for
printf.
* gcc.c-torture/compile/2211-1.c: Skip if target bpf-*-*.
* gcc.c-torture/compile/poor.c: Likewise.
* gcc.c-torture/compile/pr25311.c: Likewise.
* gcc.c-torture/compile/920501-7.c: Likewise.
* gcc.c-torture/compile/2403-1.c: Likewise.
* gcc.c-torture/compile/20001226-1.c: Likewise.
* gcc.c-torture/compile/20030903-1.c: Likewise.
* gcc.c-torture/compile/20031125-1.c: Likewise.
* gcc.c-torture/compile/20040101-1.c: Likewise.
* gcc.c-torture/compile/20040317-2.c: Likewise.
* gcc.c-torture/compile/20040726-1.c: Likewise.
* gcc.c-torture/compile/20051216-1.c: Likewise.
* gcc.c-torture/compile/900313-1.c: Likewise.
* gcc.c-torture/compile/920625-1.c: Likewise.
* gcc.c-torture/compile/930421-1.c: Likewise.
* gcc.c-torture/compile/930623-1.c: Likewise.
* gcc.c-torture/compile/961004-1.c: Likewise.
* gcc.c-torture/compile/980504-1.c: Likewise.
* gcc.c-torture/compile/980816-1.c: Likewise.
* gcc.c-torture/compile/990625-1.c: Likewise.
* gcc.c-torture/compile/DFcmp.c: Likewise.
* gcc.c-torture/compile/HIcmp.c: Likewise.
* gcc.c-torture/compile/HIset.c: Likewise.
* gcc.c-torture/compile/QIcmp.c: Likewise.
* gcc.c-torture/compile/QIset.c: Likewise.
* gcc.c-torture/compile/SFset.c: Likewise.
* gcc.c-torture/compile/SIcmp.c: Likewise.
* gcc.c-torture/compile/SIset.c: Likewise.
* gcc.c-torture/compile/UHIcmp.c: Likewise.
* gcc.c-torture/compile/UQIcmp.c: Likewise.
* gcc.c-torture/compile/USIcmp.c: Likewise.
* gcc.c-torture/compile/consec.c: Likewise.
* gcc.c-torture/compile/limits-fndefn.c: Likewise.
* gcc.c-torture/compile/lll.c: Likewise.
* gcc.c-torture/compile/parms.c: Likewise.
* gcc.c-torture/compile/pass.c: Likewise.
* gcc.c-torture/compile/pp.c: Likewise.
* gcc.c-torture/compile/pr32399.c: Likewise.
* gcc.c-torture/compile/pr34091.c: Likewise.
* gcc.c-torture/compile/pr34688.c: Likewise.
* gcc.c-torture/compile/pr37258.c: Likewise.
* gcc.c-torture/compile/pr37327.c: Likewise.
* gcc.c-torture/compile/pr37381.c: Likewise.
* gcc.c-torture/compile/pr37669-2.c: Likewise.
* gcc.c-torture/compile/pr37669.c: Likewise.
* gcc.c-torture/compile/pr37742-3.c: Likewise.
* gcc.c-torture/compile/pr44063.c: Likewise.
* gcc.c-torture/compile/pr48596.c: Likewise.
* gcc.c-torture/compile/pr51856.c: Likewise.
* gcc.c-torture/compile/pr54428.c: Likewise.
* gcc.c-torture/compile/pr54713-1.c: Likewise.
* gcc.c-torture/compile/pr54713-2.c: Likewise.
* gcc.c-torture/compile/pr54713-3.c: Likewise.
* gcc.c-torture/compile/pr55921.c: Likewise.
* gcc.c-torture/compile/pr70240.c: Likewise.
* gcc.c-torture/compile/pr70355.c: Likewise.
* gcc.c-torture/compile/pr82052.c: Likewise.
* gcc.c-torture/compile/pr83487.c: Likewise.
* gcc.c-torture/compile/pr86122.c: Likewise.
* gcc.c-torture/compile/pret-arg.c: Likewise.
* gcc.c-torture/compile/regs-arg-size.c: Likewise.
* gcc.c-torture/compile/structret.c: Likewise.
* gcc.c-torture/compile/uuarg.c: Likewise.
* gcc.dg/20001009-1.c: Likewise.
* gcc.dg/20020418-1.c: Likewise.
* gcc.dg/20020426-2.c: Likewise.
* gcc.dg/20020430-1.c: Likewise.
* gcc.dg/20040306-1.c: Likewise.
* gcc.dg/20040622-2.c: Likewise.
* gcc.dg/20050603-2.c: Likewise.
* gcc.dg/20050629-1.c: Likewise.
* gcc.dg/20061026.c: Likewise.
* gcc.dg/Warray-bounds-3.c: Likewise.
* gcc.dg/Warray-bounds-30.c: Likewise.
* gcc.dg/Wframe-larger-than-2.c: Likewise.
* gcc.dg/Wframe-larger-than.c: Likewise.
* gcc.dg/Wrestrict-11.c: Likewise.
* gcc.c-torture/compile/2804-1.c: Likewise.
---
 gcc/testsuite/ChangeLog| 85 ++
 gcc/testsuite/gcc.c-torture/compile/2211-1.c   |  2 +
 gcc/testsuite/gcc.c-torture/compile/2403-1.c   |  2 

[PATCH V4 11/11] bpf: add myself as the maintainer for the eBPF port

[Jose E. Marchesi]

ChangeLog:

* MAINTAINERS: Add myself as the maintainer of the eBPF port.
Remove myself from Write After Approval section.
---
 ChangeLog   | 5 +
 MAINTAINERS | 2 +-
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 5d8402949bc..5d69d696c2c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -57,6 +57,7 @@ arm port  Ramana Radhakrishnan

 arm port   Kyrylo Tkachov  
 avr port   Denis Chertykov 
 bfin port  Jie Zhang   
+bpf port   Jose E. Marchesi
 c6x port   Bernd Schmidt   
 cris port  Hans-Peter Nilsson  
 c-sky port Xianmiao Qu 
@@ -497,7 +498,6 @@ Luis Machado

 Ziga Mahkovec  
 Matthew Malcomson  
 Mikhail Maltsev
-Jose E. Marchesi   
 Patrick Marlier

 Simon Martin   
 Alejandro Martinez 

-- 
2.11.0

[PATCH V4 07/11] bpf: gcc.target eBPF testsuite

[Jose E. Marchesi]

This patch adds a new testsuite to gcc.target, with eBPF specific
tests.

Tests are included for:
- Target specific diagnostics.
- All built-in functions.

testsuite/ChangeLog:

* gcc.target/bpf/bpf.exp: New file.
* gcc.target/bpf/builtin-load.c: Likewise.
* cc.target/bpf/constant-calls.c: Likewise.
* gcc.target/bpf/diag-funargs.c: Likewise.
* cc.target/bpf/diag-indcalls.c: Likewise.
* gcc.target/bpf/helper-bind.c: Likewise.
* cc.target/bpf/helper-bpf-redirect.c: Likewise.
* gcc.target/bpf/helper-clone-redirect.c: Likewise.
* gcc.target/bpf/helper-csum-diff.c: Likewise.
* gcc.target/bpf/helper-csum-update.c: Likewise.
* gcc.target/bpf/helper-current-task-under-cgroup.c: Likewise.
* gcc.target/bpf/helper-fib-lookup.c: Likewise.
* gcc.target/bpf/helper-get-cgroup-classid.c: Likewise.
* gcc.target/bpf/helper-get-current-cgroup-id.c: Likewise.
* gcc.target/bpf/helper-get-current-comm.c: Likewise.
* gcc.target/bpf/helper-get-current-pid-tgid.c: Likewise.
* gcc.target/bpf/helper-get-current-task.c: Likewise.
* gcc.target/bpf/helper-get-current-uid-gid.c: Likewise.
* gcc.target/bpf/helper-get-hash-recalc.c: Likewise.
* gcc.target/bpf/helper-get-listener-sock.c: Likewise.
* gcc.target/bpf/helper-get-local-storage.c: Likewise.
* gcc.target/bpf/helper-get-numa-node-id.c: Likewise.
* gcc.target/bpf/helper-get-prandom-u32.c: Likewise.
* gcc.target/bpf/helper-get-route-realm.c: Likewise.
* gcc.target/bpf/helper-get-smp-processor-id.c: Likewise.
* gcc.target/bpf/helper-get-socket-cookie.c: Likewise.
* gcc.target/bpf/helper-get-socket-uid.c: Likewise.
* gcc.target/bpf/helper-getsockopt.c: Likewise.
* gcc.target/bpf/helper-get-stack.c: Likewise.
* gcc.target/bpf/helper-get-stackid.c: Likewise.
* gcc.target/bpf/helper-ktime-get-ns.c: Likewise.
* gcc.target/bpf/helper-l3-csum-replace.c: Likewise.
* gcc.target/bpf/helper-l4-csum-replace.c: Likewise.
* gcc.target/bpf/helper-lwt-push-encap.c: Likewise.
* gcc.target/bpf/helper-lwt-seg6-action.c: Likewise.
* gcc.target/bpf/helper-lwt-seg6-adjust-srh.c: Likewise.
* gcc.target/bpf/helper-lwt-seg6-store-bytes.c: Likewise.
* gcc.target/bpf/helper-map-delete-elem.c: Likewise.
* gcc.target/bpf/helper-map-lookup-elem.c: Likewise.
* gcc.target/bpf/helper-map-peek-elem.c: Likewise.
* gcc.target/bpf/helper-map-pop-elem.c: Likewise.
* gcc.target/bpf/helper-map-push-elem.c: Likewise.
* gcc.target/bpf/helper-map-update-elem.c: Likewise.
* gcc.target/bpf/helper-msg-apply-bytes.c: Likewise.
* gcc.target/bpf/helper-msg-cork-bytes.c: Likewise.
* gcc.target/bpf/helper-msg-pop-data.c: Likewise.
* gcc.target/bpf/helper-msg-pull-data.c: Likewise.
* gcc.target/bpf/helper-msg-push-data.c: Likewise.
* gcc.target/bpf/helper-msg-redirect-hash.c: Likewise.
* gcc.target/bpf/helper-msg-redirect-map.c: Likewise.
* gcc.target/bpf/helper-override-return.c: Likewise.
* gcc.target/bpf/helper-perf-event-output.c: Likewise.
* gcc.target/bpf/helper-perf-event-read.c: Likewise.
* gcc.target/bpf/helper-perf-event-read-value.c: Likewise.
* gcc.target/bpf/helper-perf-prog-read-value.c: Likewise.
* gcc.target/bpf/helper-probe-read.c: Likewise.
* gcc.target/bpf/helper-probe-read-str.c: Likewise.
* gcc.target/bpf/helper-probe-write-user.c: Likewise.
* gcc.target/bpf/helper-rc-keydown.c: Likewise.
* gcc.target/bpf/helper-rc-pointer-rel.c: Likewise.
* gcc.target/bpf/helper-rc-repeat.c: Likewise.
* gcc.target/bpf/helper-redirect-map.c: Likewise.
* gcc.target/bpf/helper-set-hash.c: Likewise.
* gcc.target/bpf/helper-set-hash-invalid.c: Likewise.
* gcc.target/bpf/helper-setsockopt.c: Likewise.
* gcc.target/bpf/helper-skb-adjust-room.c: Likewise.
* gcc.target/bpf/helper-skb-cgroup-id.c: Likewise.
* gcc.target/bpf/helper-skb-change-head.c: Likewise.
* gcc.target/bpf/helper-skb-change-proto.c: Likewise.
* gcc.target/bpf/helper-skb-change-tail.c: Likewise.
* gcc.target/bpf/helper-skb-change-type.c: Likewise.
* gcc.target/bpf/helper-skb-ecn-set-ce.c: Likewise.
* gcc.target/bpf/helper-skb-get-tunnel-key.c: Likewise.
* gcc.target/bpf/helper-skb-get-tunnel-opt.c: Likewise.
* gcc.target/bpf/helper-skb-get-xfrm-state.c: Likewise.
* gcc.target/bpf/helper-skb-load-bytes.c: Likewise.
* gcc.target/bpf/helper-skb-load-bytes-relative.c: Likewise.
* gcc.target/bpf/helper-skb-pull-data.c: Likewise.
* gcc.target/bpf/helper-skb-set-tunnel-key.c: Likewise.
* gcc.target/bpf/helper-skb-set-tunnel-opt.c: Likewise.

[PATCH V4 10/11] bpf: manual updates for eBPF

[Jose E. Marchesi]

gcc/ChangeLog:

* doc/invoke.texi (Option Summary): Cover eBPF.
(eBPF Options): New section.
* doc/extend.texi (BPF Built-in Functions): Likewise.
(BPF Kernel Helpers): Likewise.
---
 gcc/ChangeLog   |   7 +++
 gcc/doc/extend.texi | 171 
 gcc/doc/invoke.texi |  37 
 3 files changed, 215 insertions(+)

diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 4aea4d31761..e821cafff1e 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -13604,6 +13604,8 @@ instructions, but allow the compiler to schedule those 
calls.
 * ARM ARMv8-M Security Extensions::
 * AVR Built-in Functions::
 * Blackfin Built-in Functions::
+* BPF Built-in Functions::
+* BPF Kernel Helpers::
 * FR-V Built-in Functions::
 * MIPS DSP Built-in Functions::
 * MIPS Paired-Single Support::
@@ -14601,6 +14603,175 @@ void __builtin_bfin_csync (void)
 void __builtin_bfin_ssync (void)
 @end smallexample
 
+@node BPF Built-in Functions
+@subsection BPF Built-in Functions
+
+The following built-in functions are available for eBPF targets.
+
+@deftypefn {Built-in Function} unsigned long long __builtin_bpf_load_byte 
(unsigned long long @var{offset})
+Load a byte from the @code{struct sk_buff} packet data pointed by the register 
@code{%r6} and return it.
+@end deftypefn
+
+@deftypefn {Built-in Function} unsigned long long __builtin_bpf_load_half 
(unsigned long long @var{offset})
+Load 16-bits from the @code{struct sk_buff} packet data pointed by the 
register @code{%r6} and return it.
+@end deftypefn
+
+@deftypefn {Built-in Function} unsigned long long __builtin_bpf_load_word 
(unsigned long long @var{offset})
+Load 32-bits from the @code{struct sk_buff} packet data pointed by the 
register @code{%r6} and return it.
+@end deftypefn
+
+@node BPF Kernel Helpers
+@subsection BPF Kernel Helpers
+
+These built-in functions are available for calling kernel helpers, and
+they are available depending on the kernel version selected as the
+CPU.
+
+Rather than using the built-ins directly, it is preferred for programs
+to include @file{bpf-helpers.h} and use the wrappers defined there.
+
+For a full description of what the helpers do, the arguments they
+take, and the returned value, see the
+@file{linux/include/uapi/linux/bpf.h} in a Linux source tree.
+
+@smallexample
+void *__builtin_bpf_helper_map_lookup_elem (void *map, void *key)
+int   __builtin_bpf_helper_map_update_elem (void *map, void *key,
+void *value,
+unsigned long long flags)
+int   __builtin_bpf_helper_map_delete_elem (void *map, const void *key)
+int   __builtin_bpf_helper_map_push_elem (void *map, const void *value,
+  unsigned long long flags)
+int   __builtin_bpf_helper_map_pop_elem (void *map, void *value)
+int   __builtin_bpf_helper_map_peek_elem (void *map, void *value)
+int __builtin_bpf_helper_clone_redirect (void *skb,
+ unsigned int ifindex,
+ unsigned long long flags)
+int __builtin_bpf_helper_skb_get_tunnel_key (void *ctx, void *key, int size, 
int flags)
+int __builtin_bpf_helper_skb_set_tunnel_key (void *ctx, void *key, int size, 
int flags)
+int __builtin_bpf_helper_skb_get_tunnel_opt (void *ctx, void *md, int size)
+int __builtin_bpf_helper_skb_set_tunnel_opt (void *ctx, void *md, int size)
+int __builtin_bpf_helper_skb_get_xfrm_state (void *ctx, int index, void *state,
+int size, int flags)
+static unsigned long long __builtin_bpf_helper_skb_cgroup_id (void *ctx)
+static unsigned long long __builtin_bpf_helper_skb_ancestor_cgroup_id
+ (void *ctx, int level)
+int __builtin_bpf_helper_skb_vlan_push (void *ctx, __be16 vlan_proto, __u16 
vlan_tci)
+int __builtin_bpf_helper_skb_vlan_pop (void *ctx)
+int __builtin_bpf_helper_skb_ecn_set_ce (void *ctx)
+
+int __builtin_bpf_helper_skb_load_bytes (void *ctx, int off, void *to, int len)
+int __builtin_bpf_helper_skb_load_bytes_relative (void *ctx, int off, void 
*to, int len, __u32 start_header)
+int __builtin_bpf_helper_skb_store_bytes (void *ctx, int off, void *from, int 
len, int flags)
+int __builtin_bpf_helper_skb_under_cgroup (void *ctx, void *map, int index)
+int __builtin_bpf_helper_skb_change_head (void *, int len, int flags)
+int __builtin_bpf_helper_skb_pull_data (void *, int len)
+int __builtin_bpf_helper_skb_change_proto (void *ctx, __be16 proto, __u64 
flags)
+int __builtin_bpf_helper_skb_change_type (void *ctx, __u32 type)
+int __builtin_bpf_helper_skb_change_tail (void *ctx, __u32 len, __u64 flags)
+int __builtin_bpf_helper_skb_adjust_room (void *ctx, __s32 len_diff, __u32 
mode,
+ unsigned long long flags)
+@end smallexample
+
+Other helpers:
+
+@smallexample
+int 

[PATCH V4 04/11] testsuite: new require effective target indirect_calls

[Jose E. Marchesi]

This patch adds a new dg_require_effective_target procedure to the
testsuite infrastructure: indirect_calls.  This new function tells
whether a target supports calls to non-constant call targets.

This patch also annotates the tests in the gcc.c-torture testuite that
require support for indirect calls.

gcc/ChangeLog:

* doc/sourcebuild.texi (Effective-Target Keywords): Document
indirect_calls.

gcc/testsuite/ChangeLog:

* lib/target-supports.exp (check_effective_target_indirect_calls):
New proc.
* gcc.c-torture/compile/20010102-1.c: Annotate with
dg-require-effective-target indirect_calls.
* gcc.c-torture/compile/20010107-1.c: Likewise.
* gcc.c-torture/compile/20011109-1.c: Likewise.
* gcc.c-torture/compile/20011218-1.c: Likewise.
* gcc.c-torture/compile/20011229-1.c: Likewise.
* gcc.c-torture/compile/20020129-1.c: Likewise.
* gcc.c-torture/compile/20020320-1.c: Likewise.
* gcc.c-torture/compile/20020706-1.c: Likewise.
* gcc.c-torture/compile/20020706-2.c: Likewise.
* gcc.c-torture/compile/20021205-1.c: Likewise.
* gcc.c-torture/compile/20030921-1.c: Likewise.
* gcc.c-torture/compile/20031023-1.c: Likewise.
* gcc.c-torture/compile/20031023-2.c: Likewise.
* gcc.c-torture/compile/20031023-3.c: Likewise.
* gcc.c-torture/compile/20031023-4.c: Likewise.
* gcc.c-torture/compile/20040614-1.c: Likewise.
* gcc.c-torture/compile/20040909-1.c: Likewise.
* gcc.c-torture/compile/20050122-1.c: Likewise.
* gcc.c-torture/compile/20050202-1.c: Likewise.
* gcc.c-torture/compile/20060208-1.c: Likewise.
* gcc.c-torture/compile/20081108-1.c: Likewise.
* gcc.c-torture/compile/20150327.c: Likewise.
* gcc.c-torture/compile/920428-2.c: Likewise.
* gcc.c-torture/compile/920928-5.c: Likewise.
* gcc.c-torture/compile/930117-1.c: Likewise.
* gcc.c-torture/compile/930607-1.c: Likewise.
* gcc.c-torture/compile/991213-2.c: Likewise.
* gcc.c-torture/compile/callind.c: Likewise.
* gcc.c-torture/compile/calls-void.c: Likewise.
* gcc.c-torture/compile/calls.c: Likewise.
* gcc.c-torture/compile/pr21840.c: Likewise.
* gcc.c-torture/compile/pr32139.c: Likewise.
* gcc.c-torture/compile/pr35607.c: Likewise.
* gcc.c-torture/compile/pr37433-1.c: Likewise.
* gcc.c-torture/compile/pr37433.c: Likewise.
* gcc.c-torture/compile/pr39941.c: Likewise.
* gcc.c-torture/compile/pr40080.c: Likewise.
* gcc.c-torture/compile/pr43635.c: Likewise.
* gcc.c-torture/compile/pr43791.c: Likewise.
* gcc.c-torture/compile/pr43845.c: Likewise.
* gcc.c-torture/compile/pr44043.c: Likewise.
* gcc.c-torture/compile/pr51694.c: Likewise.
* gcc.c-torture/compile/pr77754-2.c: Likewise.
* gcc.c-torture/compile/pr77754-3.c: Likewise.
* gcc.c-torture/compile/pr77754-4.c: Likewise.
* gcc.c-torture/compile/pr89663-2.c: Likewise.
* gcc.c-torture/compile/pta-1.c: Likewise.
* gcc.c-torture/compile/stack-check-1.c: Likewise.
* gcc.dg/Walloc-size-larger-than-18.c: Likewise.
---
 gcc/ChangeLog  |  5 ++
 gcc/doc/sourcebuild.texi   |  4 ++
 gcc/testsuite/ChangeLog| 55 ++
 gcc/testsuite/gcc.c-torture/compile/20010102-1.c   |  2 +
 gcc/testsuite/gcc.c-torture/compile/20010107-1.c   |  2 +
 gcc/testsuite/gcc.c-torture/compile/20011109-1.c   |  2 +
 gcc/testsuite/gcc.c-torture/compile/20011218-1.c   |  2 +
 gcc/testsuite/gcc.c-torture/compile/20011229-1.c   |  3 ++
 gcc/testsuite/gcc.c-torture/compile/20020129-1.c   |  2 +
 gcc/testsuite/gcc.c-torture/compile/20020320-1.c   |  2 +
 gcc/testsuite/gcc.c-torture/compile/20020706-1.c   |  2 +
 gcc/testsuite/gcc.c-torture/compile/20020706-2.c   |  2 +
 gcc/testsuite/gcc.c-torture/compile/20021205-1.c   |  2 +
 gcc/testsuite/gcc.c-torture/compile/20030921-1.c   |  1 +
 gcc/testsuite/gcc.c-torture/compile/20031023-1.c   |  2 +
 gcc/testsuite/gcc.c-torture/compile/20031023-2.c   |  2 +
 gcc/testsuite/gcc.c-torture/compile/20031023-3.c   |  2 +
 gcc/testsuite/gcc.c-torture/compile/20031023-4.c   |  2 +
 gcc/testsuite/gcc.c-torture/compile/20040614-1.c   |  1 +
 gcc/testsuite/gcc.c-torture/compile/20040909-1.c   |  2 +
 gcc/testsuite/gcc.c-torture/compile/20050122-1.c   |  2 +
 gcc/testsuite/gcc.c-torture/compile/20050202-1.c   |  2 +
 gcc/testsuite/gcc.c-torture/compile/20060208-1.c   |  2 +
 gcc/testsuite/gcc.c-torture/compile/20081108-1.c   |  2 +
 gcc/testsuite/gcc.c-torture/compile/20150327.c |  2 +
 gcc/testsuite/gcc.c-torture/compile/920428-2.c |  2 +
 gcc/testsuite/gcc.c-torture/compile/920928-5.c |  3 ++
 gcc/testsuite/gcc.c-torture/compile/930117-1.c |  2 +
 

[PATCH V4 00/11] eBPF support for GCC

[Jose E. Marchesi]

[Differences from V3:
. Formatting/style fixes:
  + Remove redundant braces.
  + Remove unneeded ATTRIBUTE_UNUSED.
  + Truncate too long lines.
  + Remove an odd line split.
  + Do not break after returns.
  + Use function_arg_info methods instead of auxiliary functions.
  + Fix indentation in cbranchdi4.
. Use `sorry' and sorry_at to report lack of support for valid
  constructs.
. Rename GR_REGS to GENERAL_REGS and exclude the pseudo arg_reg
  from the class.
. Fix opcode in "sub3" insns.
. The mul32 instruction zero-extends arguments and then performs
  a multiplication.  Use the right pattern for this in bpf.md and
  name it umulsidi3.
. Use a mov32 instructions for zero-extending 32-bit values to 64-bit.
. Remove the *extendsidi2 insn, as it is not needed.
. (now for real, ahem) Remove dubious code from the move expanders, by
  not accepting constant addresses as legit.  Rework handling of call
  instructions accordingly.
. Improve "too many arguments" error reporting.
  New test gcc.target/bpf/diag-funargs-3.c.
. xfail gcc.target/bpf/constant-calls.c.
. Rebased to today's master.]

Hi people!

This patch series introduces a port of GCC to eBPF, which is a virtual
machine that resides in the Linux kernel.  Initially intended for
user-level packet capture and filtering, eBPF is nowadays generalized
to serve as a general-purpose infrastructure also for non-networking
purposes.

The binutils support is already upstream.  See
https://sourceware.org/ml/binutils/2019-05/msg00306.html.

eBPF architecture and ABI
=
   
Documentation for eBPF can be found in the linux kernel source tree,
file Documentation/networking/filter.txt.  It covers the instructions
set, the way the interpreter works and the many restrictions imposed
by the kernel verifier.
   
As for the ABI, att this moment compiled eBPF doesn't have very well
established conventions.  The details on what is expected to be in an
ELF file containing eBPF is determined, in practice, by what the llvm
BPF backend generates and what is expected by the the two existing
kernel loaders: bpf_load.c and libbpf.

We hope that the addition of this port to the GNU toolchain will help
to mature this domain.

Overview of the patch series

   
The first few patches are preparatory:

. The first patch updates config.guess and config.sub from the
  'config' upstream project, in order to recognize bpf-*-* triplets.

. The second patch fixes an integrity check in opt-functions.awk.

. The third patch annotates many tests in the gcc.c-torture/compile
  testsuite with their requirements in terms of stack frame size,
  using the existing dg-require-stack-size machinery.

. The fourth patch introduces a new effective target flag called
  indirect_call, and annotates the tests in gcc.c-torture/compile
  accordingly.

The rest of the patches are BPF specific:

The fifth patch adds the new GCC port proper.  Machine description,
implementation of target hooks and macros, command-line options and
the like.

The sixth patch adds a libgcc port for eBPF.  At the moment, it is
minimal and it basically addresses the limitations imposed by the
target, by excluding a few functions in libgcc2 (all of them related
to TImodes) whose default implementations exceed the eBPF stack limit.

The seventh, eight and ninth patches deal with testing the new
port. The gcc.target testsuite is extended with eBPF-specific tests,
covering the backend-specific built-in functions and diagnostics.  The
check-effective-target functions are made aware of eBPF targets. Many
tests in the gcc.c-torture/compile testsuite are annotated to be
skipped in bpf-*-* targets, since they violate some restriction
imposed by the hardware (such as surpassing the stack limit.)  The
resulting testsuite doesn't have unexpected failures, and is currently
the principal way to check for regressions in the port.  Likewise,
many tests in the gcc.dg testsuite are annotated to be skipped in
bpf-*-* targets.

The tenth patch adds documentation updates to the GCC manual,
including information on the new command line options and compiler
built-ins.

Finally, the last patch adds myself as the maintainer of the BPF port.
I personally commit to evolve and maintain the port for as long as
necessary, and to find a suitable replacement in case I have to step
down for whatever reason.

Some notes on the port
==

As a compilation target, eBPF is rather peculiar.  This is mainly due
to the quite hard restrictions imposed by the kernel verifier, and
also due to the security-driven design of the architecture itself.

To list a few examples:

. The stack is disjoint, and each stack frame corresponding to a
  function activation is isolated: it is not possible for a callee to
  access the stack frame of the caller, nor for a caller to access the
  stack frame of it's callees.  The frame pointer register is
  read-only.

. Therefore it is not possible to pass arguments in the 

[PATCH V4 08/11] bpf: make target-supports.exp aware of eBPF

[Jose E. Marchesi]

This patch makes the several effective target checks in
target-supports.exp to be aware of eBPF targets.

gcc/testsuite/ChangeLog:

* lib/target-supports.exp
(check_effective_target_trampolines): Adapt to eBPF.
(check_effective_target_stack_size): Likewise.
(dg-effective-target-value): Likewise.
(check_effective_target_indirect_jumps): Likewise.
(check_effective_target_nonlocal_goto): Likewise.
(check_effective_target_global_constructor): Likewise.
(check_effective_target_return_address): Likewise.
---
 gcc/testsuite/ChangeLog   |  9 +
 gcc/testsuite/lib/target-supports.exp | 18 +++---
 2 files changed, 20 insertions(+), 7 deletions(-)

diff --git a/gcc/testsuite/lib/target-supports.exp 
b/gcc/testsuite/lib/target-supports.exp
index f457a46a02b..ce08a2f8421 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -526,7 +526,8 @@ proc check_effective_target_trampolines { } {
 || [istarget nvptx-*-*]
 || [istarget hppa2.0w-hp-hpux11.23]
 || [istarget hppa64-hp-hpux11.23]
-|| [istarget pru-*-*] } {
+|| [istarget pru-*-*]
+|| [istarget bpf-*-*] } {
return 0;
 }
 return 1
@@ -781,7 +782,7 @@ proc add_options_for_tls { flags } {
 # Return 1 if indirect jumps are supported, 0 otherwise.
 
 proc check_effective_target_indirect_jumps {} {
-if { [istarget nvptx-*-*] } {
+if { [istarget nvptx-*-*] || [istarget bpf-*-*] } {
return 0
 }
 return 1
@@ -790,7 +791,7 @@ proc check_effective_target_indirect_jumps {} {
 # Return 1 if nonlocal goto is supported, 0 otherwise.
 
 proc check_effective_target_nonlocal_goto {} {
-if { [istarget nvptx-*-*] } {
+if { [istarget nvptx-*-*] || [istarget bpf-*-*] } {
return 0
 }
 return 1
@@ -799,10 +800,9 @@ proc check_effective_target_nonlocal_goto {} {
 # Return 1 if global constructors are supported, 0 otherwise.
 
 proc check_effective_target_global_constructor {} {
-if { [istarget nvptx-*-*] } {
-   return 0
-}
-if { [istarget amdgcn-*-*] } {
+if { [istarget nvptx-*-*]
+|| [istarget amdgcn-*-*]
+|| [istarget bpf-*-*] } {
return 0
 }
 return 1
@@ -825,6 +825,10 @@ proc check_effective_target_return_address {} {
 if { [istarget nvptx-*-*] } {
return 0
 }
+# No notion of return address in eBPF.
+if { [istarget bpf-*-*] } {
+   return 0
+}
 # It could be supported on amdgcn, but isn't yet.
 if { [istarget amdgcn*-*-*] } {
return 0
-- 
2.11.0

[PATCH V4 01/11] Update config.sub and config.guess.

[Jose E. Marchesi]

* config.sub: Import upstream version 2019-06-30.
* config.guess: Import upstream version 2019-07-24.
---
 ChangeLog|   5 ++
 config.guess | 264 +++
 config.sub   |  50 +--
 3 files changed, 240 insertions(+), 79 deletions(-)

diff --git a/config.guess b/config.guess
index 8e2a58b864f..97ad0733304 100755
--- a/config.guess
+++ b/config.guess
@@ -2,7 +2,7 @@
 # Attempt to guess a canonical system name.
 #   Copyright 1992-2019 Free Software Foundation, Inc.
 
-timestamp='2019-01-03'
+timestamp='2019-07-24'
 
 # This file is free software; you can redistribute it and/or modify it
 # under the terms of the GNU General Public License as published by
@@ -262,6 +262,9 @@ case 
"$UNAME_MACHINE:$UNAME_SYSTEM:$UNAME_RELEASE:$UNAME_VERSION" in
 *:SolidBSD:*:*)
echo "$UNAME_MACHINE"-unknown-solidbsd"$UNAME_RELEASE"
exit ;;
+*:OS108:*:*)
+   echo "$UNAME_MACHINE"-unknown-os108_"$UNAME_RELEASE"
+   exit ;;
 macppc:MirBSD:*:*)
echo powerpc-unknown-mirbsd"$UNAME_RELEASE"
exit ;;
@@ -275,8 +278,8 @@ case 
"$UNAME_MACHINE:$UNAME_SYSTEM:$UNAME_RELEASE:$UNAME_VERSION" in
echo "$UNAME_MACHINE"-unknown-redox
exit ;;
 mips:OSF1:*.*)
-echo mips-dec-osf1
-exit ;;
+   echo mips-dec-osf1
+   exit ;;
 alpha:OSF1:*:*)
case $UNAME_RELEASE in
*4.0)
@@ -385,20 +388,7 @@ case 
"$UNAME_MACHINE:$UNAME_SYSTEM:$UNAME_RELEASE:$UNAME_VERSION" in
echo sparc-hal-solaris2"`echo "$UNAME_RELEASE"|sed -e 's/[^.]*//'`"
exit ;;
 sun4*:SunOS:5.*:* | tadpole*:SunOS:5.*:*)
-   set_cc_for_build
-   SUN_ARCH=sparc
-   # If there is a compiler, see if it is configured for 64-bit objects.
-   # Note that the Sun cc does not turn __LP64__ into 1 like gcc does.
-   # This test works for both compilers.
-   if [ "$CC_FOR_BUILD" != no_compiler_found ]; then
-   if (echo '#ifdef __sparcv9'; echo IS_64BIT_ARCH; echo '#endif') | \
-   (CCOPTS="" $CC_FOR_BUILD -E - 2>/dev/null) | \
-   grep IS_64BIT_ARCH >/dev/null
-   then
-   SUN_ARCH=sparcv9
-   fi
-   fi
-   echo "$SUN_ARCH"-sun-solaris2"`echo "$UNAME_RELEASE"|sed -e 
's/[^.]*//'`"
+   echo sparc-sun-solaris2"`echo "$UNAME_RELEASE" | sed -e 's/[^.]*//'`"
exit ;;
 i86pc:AuroraUX:5.*:* | i86xen:AuroraUX:5.*:*)
echo i386-pc-auroraux"$UNAME_RELEASE"
@@ -998,22 +988,50 @@ EOF
exit ;;
 mips:Linux:*:* | mips64:Linux:*:*)
set_cc_for_build
+   IS_GLIBC=0
+   test x"${LIBC}" = xgnu && IS_GLIBC=1
sed 's/^//' << EOF > "$dummy.c"
#undef CPU
-   #undef ${UNAME_MACHINE}
-   #undef ${UNAME_MACHINE}el
+   #undef mips
+   #undef mipsel
+   #undef mips64
+   #undef mips64el
+   #if ${IS_GLIBC} && defined(_ABI64)
+   LIBCABI=gnuabi64
+   #else
+   #if ${IS_GLIBC} && defined(_ABIN32)
+   LIBCABI=gnuabin32
+   #else
+   LIBCABI=${LIBC}
+   #endif
+   #endif
+
+   #if ${IS_GLIBC} && defined(__mips64) && defined(__mips_isa_rev) && 
__mips_isa_rev>=6
+   CPU=mipsisa64r6
+   #else
+   #if ${IS_GLIBC} && !defined(__mips64) && defined(__mips_isa_rev) && 
__mips_isa_rev>=6
+   CPU=mipsisa32r6
+   #else
+   #if defined(__mips64)
+   CPU=mips64
+   #else
+   CPU=mips
+   #endif
+   #endif
+   #endif
+
#if defined(__MIPSEL__) || defined(__MIPSEL) || defined(_MIPSEL) || 
defined(MIPSEL)
-   CPU=${UNAME_MACHINE}el
+   MIPS_ENDIAN=el
#else
#if defined(__MIPSEB__) || defined(__MIPSEB) || defined(_MIPSEB) || 
defined(MIPSEB)
-   CPU=${UNAME_MACHINE}
+   MIPS_ENDIAN=
#else
-   CPU=
+   MIPS_ENDIAN=
#endif
#endif
 EOF
-   eval "`$CC_FOR_BUILD -E "$dummy.c" 2>/dev/null | grep '^CPU'`"
-   test "x$CPU" != x && { echo "$CPU-unknown-linux-$LIBC"; exit; }
+   eval "`$CC_FOR_BUILD -E "$dummy.c" 2>/dev/null | grep 
'^CPU\|^MIPS_ENDIAN\|^LIBCABI'`"
+   test "x$CPU" != x && { echo 
"$CPU${MIPS_ENDIAN}-unknown-linux-$LIBCABI"; exit; }
;;
 mips64el:Linux:*:*)
echo "$UNAME_MACHINE"-unknown-linux-"$LIBC"
@@ -1126,7 +1144,7 @@ EOF
*Pentium)UNAME_MACHINE=i586 ;;
*Pent*|*Celeron) UNAME_MACHINE=i686 ;;
esac
-   echo 
"$UNAME_MACHINE-unknown-sysv${UNAME_RELEASE}${UNAME_SYSTEM}{$UNAME_VERSION}"
+   echo 
"$UNAME_MACHINE-unknown-sysv${UNAME_RELEASE}${UNAME_SYSTEM}${UNAME_VERSION}"
exit ;;
 i*86:*:3.2:*)
if test -f /usr/options/cb.name; then
@@ -1310,38 +1328,39 @@ EOF
echo "$UNAME_MACHINE"-apple-rhapsody"$UNAME_RELEASE"
exit ;;
 *:Darwin:*:*)
-   UNAME_PROCESSOR=`uname -p` || UNAME_PROCESSOR=unknown
-   set_cc_for_build
-   if test "$UNAME_PROCESSOR" = unknown ; then
-   

[PATCH V4 06/11] bpf: new libgcc port

[Jose E. Marchesi]

This patch adds an eBPF port to libgcc.

As of today, compiled eBPF programs do not support a single-entry
point schema.  Instead, a BPF "executable" is a relocatable ELF object
file containing multiple entry points, in certain named sections.

Also, the BPF loaders in the kernel do not execute .ini/.fini
constructors/destructors.  Therefore, this patch provides empty crtn.S
and cri.S files.

libgcc/ChangeLog:

* config.host: Set cpu_type for bpf-*-* targets.
* config/bpf/t-bpf: Likewise.
* config/bpf/crtn.S: Likewise.
* config/bpf/crti.S: New file.
---
 libgcc/ChangeLog |  7 +++
 libgcc/config.host   |  7 +++
 libgcc/config/bpf/crti.S |  0
 libgcc/config/bpf/crtn.S |  0
 libgcc/config/bpf/t-bpf  | 23 +++
 5 files changed, 37 insertions(+)
 create mode 100644 libgcc/config/bpf/crti.S
 create mode 100644 libgcc/config/bpf/crtn.S
 create mode 100644 libgcc/config/bpf/t-bpf

diff --git a/libgcc/config.host b/libgcc/config.host
index 503ebb6be20..2e9fbc35482 100644
--- a/libgcc/config.host
+++ b/libgcc/config.host
@@ -107,6 +107,9 @@ avr-*-*)
 bfin*-*)
cpu_type=bfin
;;
+bpf-*-*)
+cpu_type=bpf
+;;
 cr16-*-*)
;;
 crisv32-*-*)
@@ -526,6 +529,10 @@ bfin*-*)
tmake_file="$tmake_file bfin/t-bfin t-fdpbit"
extra_parts="crtbegin.o crtend.o crti.o crtn.o"
 ;;
+bpf-*-*)
+tmake_file="$tmake_file ${cpu_type}/t-${cpu_type}"
+extra_parts="crti.o crtn.o"
+   ;;
 cr16-*-elf)
tmake_file="${tmake_file} cr16/t-cr16 cr16/t-crtlibid t-fdpbit"
extra_parts="$extra_parts crti.o crtn.o crtlibid.o"
diff --git a/libgcc/config/bpf/crti.S b/libgcc/config/bpf/crti.S
new file mode 100644
index 000..e69de29bb2d
diff --git a/libgcc/config/bpf/crtn.S b/libgcc/config/bpf/crtn.S
new file mode 100644
index 000..e69de29bb2d
diff --git a/libgcc/config/bpf/t-bpf b/libgcc/config/bpf/t-bpf
new file mode 100644
index 000..88129a78f61
--- /dev/null
+++ b/libgcc/config/bpf/t-bpf
@@ -0,0 +1,23 @@
+LIB2ADDEH = 
+
+crti.o: $(srcdir)/config/bpf/crti.S
+   $(crt_compile) $(CRTSTUFF_T_CFLAGS) -c $<
+
+crtn.o: $(srcdir)/config/bpf/crtn.S
+   $(crt_compile) $(CRTSTUFF_T_CFLAGS) -c $<
+
+# Some of the functions defined in libgcc2 exceed the eBPF stack
+# limit, or other restrictions imposed by this peculiar target.
+# Therefore we have to exclude them here.
+#
+# Patterns in bpf.md must guarantee that no calls to the excluded
+# functions are ever generated, and compiler tests should make sure
+# this holds.
+#
+# Note that the modes in the function names below are misleading: di
+# means TImode.
+LIB2FUNCS_EXCLUDE = _mulvdi3 _divdi3 _moddi3 _divmoddi4 _udivdi3 _umoddi3 \
+_udivmoddi4
+
+# Prevent building "advanced" stuff (for example, gcov support).
+INHIBIT_LIBC_CFLAGS = -Dinhibit_libc
-- 
2.11.0

[PATCH V4 03/11] testsuite: annotate c-torture/compile tests with dg-require-stack-size

[Jose E. Marchesi]

This patch annotates tests that make use of a significant a mount of
stack space.  Embedded and other restricted targets may have problems
compiling and running these tests.  Note that the annotations are in
many cases not exact.

testsuite/ChangeLog:

* gcc.c-torture/compile/2609-1.c: Annotate with
dg-require-stack-size.
* gcc/testsuite/gcc.c-torture/compile/2804-1.c: Likewise.
* gcc/testsuite/gcc.c-torture/compile/20020304-1.c: Likewise.
* gcc/testsuite/gcc.c-torture/compile/20020604-1.c: Likewise.
* gcc/testsuite/gcc.c-torture/compile/20021015-1.c: Likewise.
* gcc/testsuite/gcc.c-torture/compile/20050303-1.c: Likewise.
* gcc/testsuite/gcc.c-torture/compile/20060421-1.c: Likewise.
* gcc/testsuite/gcc.c-torture/compile/20071207-1.c: Likewise.
* gcc/testsuite/gcc.c-torture/compile/20080903-1.c: Likewise.
* gcc/testsuite/gcc.c-torture/compile/20121027-1.c: Likewise.
* gcc/testsuite/gcc.c-torture/compile/20151204.c: Likewise.
* gcc/testsuite/gcc.c-torture/compile/920501-12.c: Likewise.
* gcc/testsuite/gcc.c-torture/compile/920501-4.c: Likewise.
* gcc/testsuite/gcc.c-torture/compile/920723-1.c: Likewise.
* gcc/testsuite/gcc.c-torture/compile/921202-1.c: Likewise.
* gcc/testsuite/gcc.c-torture/compile/931003-1.c: Likewise.
* gcc/testsuite/gcc.c-torture/compile/931004-1.c: Likewise.
* gcc/testsuite/gcc.c-torture/compile/950719-1.c: Likewise.
* gcc/testsuite/gcc.c-torture/compile/951222-1.c: Likewise.
* gcc/testsuite/gcc.c-torture/compile/990517-1.c: Likewise.
* gcc/testsuite/gcc.c-torture/compile/bcopy.c: Likewise.
* gcc/testsuite/gcc.c-torture/compile/pr23929.c: Likewise.
* gcc/testsuite/gcc.c-torture/compile/pr25310.c: Likewise.
* gcc/testsuite/gcc.c-torture/compile/pr34458.c: Likewise.
* gcc/testsuite/gcc.c-torture/compile/pr39937.c: Likewise.
* gcc/testsuite/gcc.c-torture/compile/pr41181.c: Likewise.
* gcc/testsuite/gcc.c-torture/compile/pr41634.c: Likewise.
* gcc/testsuite/gcc.c-torture/compile/pr43415.c: Likewise.
* gcc/testsuite/gcc.c-torture/compile/pr43417.c: Likewise.
* gcc/testsuite/gcc.c-torture/compile/pr44788.c: Likewise.
* gcc/testsuite/gcc.c-torture/compile/sound.c: Likewise.
---
 gcc/testsuite/ChangeLog  | 35 
 gcc/testsuite/gcc.c-torture/compile/2609-1.c |  2 ++
 gcc/testsuite/gcc.c-torture/compile/2804-1.c |  1 +
 gcc/testsuite/gcc.c-torture/compile/20020304-1.c |  2 ++
 gcc/testsuite/gcc.c-torture/compile/20020604-1.c |  1 +
 gcc/testsuite/gcc.c-torture/compile/20021015-1.c |  1 +
 gcc/testsuite/gcc.c-torture/compile/20050303-1.c |  1 +
 gcc/testsuite/gcc.c-torture/compile/20060421-1.c |  2 ++
 gcc/testsuite/gcc.c-torture/compile/20071207-1.c |  1 +
 gcc/testsuite/gcc.c-torture/compile/20080903-1.c |  2 ++
 gcc/testsuite/gcc.c-torture/compile/20121027-1.c |  2 ++
 gcc/testsuite/gcc.c-torture/compile/20151204.c   |  1 +
 gcc/testsuite/gcc.c-torture/compile/920501-12.c  |  1 +
 gcc/testsuite/gcc.c-torture/compile/920501-4.c   |  1 +
 gcc/testsuite/gcc.c-torture/compile/920723-1.c   |  1 +
 gcc/testsuite/gcc.c-torture/compile/921202-1.c   |  2 ++
 gcc/testsuite/gcc.c-torture/compile/931003-1.c   |  2 ++
 gcc/testsuite/gcc.c-torture/compile/931004-1.c   |  2 ++
 gcc/testsuite/gcc.c-torture/compile/950719-1.c   |  2 ++
 gcc/testsuite/gcc.c-torture/compile/951222-1.c   |  2 ++
 gcc/testsuite/gcc.c-torture/compile/990517-1.c   |  3 ++
 gcc/testsuite/gcc.c-torture/compile/bcopy.c  |  1 +
 gcc/testsuite/gcc.c-torture/compile/pr23929.c|  1 +
 gcc/testsuite/gcc.c-torture/compile/pr25310.c|  1 +
 gcc/testsuite/gcc.c-torture/compile/pr34458.c|  1 +
 gcc/testsuite/gcc.c-torture/compile/pr39937.c|  2 ++
 gcc/testsuite/gcc.c-torture/compile/pr41181.c|  2 ++
 gcc/testsuite/gcc.c-torture/compile/pr41634.c|  2 ++
 gcc/testsuite/gcc.c-torture/compile/pr43415.c|  2 ++
 gcc/testsuite/gcc.c-torture/compile/pr43417.c|  2 ++
 gcc/testsuite/gcc.c-torture/compile/pr44788.c|  2 ++
 gcc/testsuite/gcc.c-torture/compile/sound.c  |  1 +
 32 files changed, 84 insertions(+)

diff --git a/gcc/testsuite/gcc.c-torture/compile/2609-1.c 
b/gcc/testsuite/gcc.c-torture/compile/2609-1.c
index f03aa35a7ac..e41701cc6d9 100644
--- a/gcc/testsuite/gcc.c-torture/compile/2609-1.c
+++ b/gcc/testsuite/gcc.c-torture/compile/2609-1.c
@@ -1,3 +1,5 @@
+/* { dg-require-stack-size "1024" } */
+
 int main ()
 {
   char temp[1024] = "tempfile";
diff --git a/gcc/testsuite/gcc.c-torture/compile/2804-1.c 
b/gcc/testsuite/gcc.c-torture/compile/2804-1.c
index 35464c212d2..550669b53a3 100644
--- a/gcc/testsuite/gcc.c-torture/compile/2804-1.c
+++ b/gcc/testsuite/gcc.c-torture/compile/2804-1.c
@@ -6,6 +6,7 @@
 /* { dg-skip-if "Not enough 64-bit registers" { pdp11-*-* 

[Bug tree-optimization/85741] [meta-bug] bogus/missing -Wformat-overflow

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85741
Bug 85741 depends on bug 91567, which changed state.

Bug 91567 Summary: [10 Regression] Spurious -Wformat-overflow warnings building 
glibc (32-bit only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91567

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

[Bug tree-optimization/91567] [10 Regression] Spurious -Wformat-overflow warnings building glibc (32-bit only)

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91567

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch
 Target||ilp32
 Status|ASSIGNED|RESOLVED
   Host||lp64
 Resolution|--- |FIXED
   Target Milestone|--- |10.0

--- Comment #3 from Martin Sebor  ---
Patch (https://gcc.gnu.org/ml/gcc-patches/2019-08/msg01843.html) committed in
r274976.  Please open new bugs for any outstanding issues in the Glibc build.

[Bug tree-optimization/91567] [10 Regression] Spurious -Wformat-overflow warnings building glibc (32-bit only)

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91567

--- Comment #2 from Martin Sebor  ---
Author: msebor
Date: Tue Aug 27 23:31:44 2019
New Revision: 274976

URL: https://gcc.gnu.org/viewcvs?rev=274976=gcc=rev
Log:
PR tree-optimization/91567 - Spurious -Wformat-overflow warnings building glibc
(32-bit only)

gcc/ChangeLog:

PR tree-optimization/91567
* gimple-ssa-sprintf.c (get_string_length): Handle more forms of
lengths
of unknown strings.
* vr-values.c (vr_values::extract_range_basic): Set strlen upper bound
to PTRDIFF_MAX - 2.

gcc/testsuite/ChangeLog:

PR tree-optimization/91567
* gcc.dg/tree-ssa/builtin-snprintf-6.c: Xfail a subset of assertions
on targets other than x86_64 to work around PR 83543.
* gcc.dg/tree-ssa/builtin-sprintf-warn-22.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-22.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-sprintf.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-snprintf-6.c
trunk/gcc/vr-values.c

[Bug tree-optimization/83543] strlen of a local array member not optimized on some targets

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83543

--- Comment #7 from Martin Sebor  ---
Author: msebor
Date: Tue Aug 27 23:31:44 2019
New Revision: 274976

URL: https://gcc.gnu.org/viewcvs?rev=274976=gcc=rev
Log:
PR tree-optimization/91567 - Spurious -Wformat-overflow warnings building glibc
(32-bit only)

gcc/ChangeLog:

PR tree-optimization/91567
* gimple-ssa-sprintf.c (get_string_length): Handle more forms of
lengths
of unknown strings.
* vr-values.c (vr_values::extract_range_basic): Set strlen upper bound
to PTRDIFF_MAX - 2.

gcc/testsuite/ChangeLog:

PR tree-optimization/91567
* gcc.dg/tree-ssa/builtin-snprintf-6.c: Xfail a subset of assertions
on targets other than x86_64 to work around PR 83543.
* gcc.dg/tree-ssa/builtin-sprintf-warn-22.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-22.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-sprintf.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-snprintf-6.c
trunk/gcc/vr-values.c

Fix ICE from sprintf/strlen integration work

[Jeff Law]

This showed up as an ICE when building the kernel on ppc64le after the
sprintf/strlen integration.

In simplest terms we can't size the ssa_ver_to_stridx array until after
we have initialized the loop optimizer and SCEV as they create new
SSA_NAMEs.  Usually this isn't a problem, but it can be if we need more
names than are currently available on the freelist of SSA_NAMEs to recycle.

Bootstrapped and regression tested on ppc64le.  Also verified the kernel
builds again.

Installing on the trunk,

jeff
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 39459d087b2..1d9d6cf0ff2 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,8 @@
+2019-08-27  Jeff Law  
+
+   * tree-ssa-strlen.c (printf_strlen_execute): Initialize
+   the loop optimizer and SCEV before sizing ssa_ver_to_stridx.
+
 2019-08-27  Uroš Bizjak  
 
PR target/91528
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 37133de87f5..2560faf8526 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,7 @@
+2019-08-27  Jeff Law  
+
+   * gcc.c-torture/compile/20190827-1.c: New test.
+
 2019-08-27  Harald Anlauf  
 
PR fortran/91496
diff --git a/gcc/testsuite/gcc.c-torture/compile/20190827-1.c 
b/gcc/testsuite/gcc.c-torture/compile/20190827-1.c
new file mode 100644
index 000..f0956179b1d
--- /dev/null
+++ b/gcc/testsuite/gcc.c-torture/compile/20190827-1.c
@@ -0,0 +1,104 @@
+typedef unsigned char __u8;
+typedef __u8 u8;
+typedef u8 u_int8_t;
+typedef unsigned int gfp_t;
+
+struct list_head
+{
+  struct list_head *next, *prev;
+};
+extern int strcmp (const char *, const char *);
+enum
+{
+  NFPROTO_UNSPEC = 0,
+  NFPROTO_INET = 1,
+  NFPROTO_IPV4 = 2,
+  NFPROTO_ARP = 3,
+  NFPROTO_NETDEV = 5,
+  NFPROTO_BRIDGE = 7,
+  NFPROTO_IPV6 = 10,
+  NFPROTO_DECNET = 12,
+  NFPROTO_NUMPROTO,
+};
+
+struct xt_target
+{
+  struct list_head list;
+  const char name[29];
+  u_int8_t revision;
+};
+
+struct xt_af
+{
+  struct list_head target;
+};
+
+static struct xt_af *xt;
+
+struct xt_af * kcalloc (int, int, int);
+
+static int
+target_revfn (u8 af, const char *name, u8 revision, int *bestp)
+{
+  const struct xt_target *t;
+  int have_rev = 0;
+
+  for (t = (
+{
+void *__mptr = (void *)(([af].target)->next);
+((typeof (*t) *) (__mptr -
+  __builtin_offsetof (typeof (*t), list)));}
+   ); >list != ([af].target); t = (
+ {
+ void *__mptr =
+ (void *)((t)->list.next);
+ ((typeof (*(t)) *) (__mptr -
+ 
__builtin_offsetof
+ (typeof
+  (*(t)),
+  list)));}
+   ))
+{
+  if (strcmp (t->name, name) == 0)
+   {
+ if (t->revision > *bestp)
+   *bestp = t->revision;
+ if (t->revision == revision)
+   have_rev = 1;
+   }
+}
+
+  if (af != NFPROTO_UNSPEC && !have_rev)
+return target_revfn (NFPROTO_UNSPEC, name, revision, bestp);
+
+  return have_rev;
+}
+
+int
+xt_find_revision (u8 af, const char *name, u8 revision, int target, int *err)
+{
+  int have_rev, best = -1;
+
+  have_rev = target_revfn (af, name, revision, );
+
+
+  if (best == -1)
+{
+  *err = -2;
+  return 0;
+}
+
+}
+
+
+static int __attribute__ ((__section__ (".init.text")))
+  __attribute__ ((__cold__)) xt_init (void)
+{
+  xt =
+kcalloc (NFPROTO_NUMPROTO, sizeof (struct xt_af),
+(((gfp_t) (0x400u | 0x800u)) | ((gfp_t) 0x40u) |
+ ((gfp_t) 0x80u)));
+}
+
+int init_module (void) __attribute__ ((__copy__ (xt_init)))
+  __attribute__ ((alias ("xt_init")));;
diff --git a/gcc/tree-ssa-strlen.c b/gcc/tree-ssa-strlen.c
index 5c5b83833c8..d38352a0c4c 100644
--- a/gcc/tree-ssa-strlen.c
+++ b/gcc/tree-ssa-strlen.c
@@ -4850,13 +4850,6 @@ printf_strlen_execute (function *fun, bool warn_only)
 {
   strlen_optimize = !warn_only;
 
-  gcc_assert (!strlen_to_stridx);
-  if (warn_stringop_overflow || warn_stringop_truncation)
-strlen_to_stridx = new hash_map ();
-
-  ssa_ver_to_stridx.safe_grow_cleared (num_ssa_names);
-  max_stridx = 1;
-
   calculate_dominance_info (CDI_DOMINATORS);
 
   bool use_scev = optimize > 0 && flag_printf_return_value;
@@ -4866,6 +4859,15 @@ printf_strlen_execute (function *fun, bool warn_only)
   scev_initialize ();
 }
 
+  gcc_assert (!strlen_to_stridx);
+  if (warn_stringop_overflow || warn_stringop_truncation)
+strlen_to_stridx = new hash_map ();
+
+  /* This has to happen after initializing the loop optimizer
+ and initializing SCEV as they c

Re: [PATCH] correct an ILP32/LP64 bug in sprintf warning (PR 91567)

[Jeff Law]

On 8/27/19 4:34 PM, Martin Sebor wrote:
> The recent sprintf+strlen integration doesn't handle unbounded
> string lengths entirely correctly for ILP32 targets and causes
> -Wformat-overflow false positives in some common cases, including
> during GCC bootstrap targeting such systems  The attached patch
> fixes that mistake.  (I think this code could be cleaned up and
> simplified some more but in the interest of unblocking the ILP32
> bootstrap and Glibc builds I haven't taken the time to do that.)
> The patch also adjusts down the maximum strlen result set by EVRP
> to PTRDIFF_MAX - 2, to match what the strlen pass does.
> 
> The strlen maximum would ideally be computed in terms of
> max_object_size() (for which there would ideally be a --param
> setting), and checked the same way to avoid off-by-one mistakes
> between subsystems and their clients.  I have not made this change
> here but added a FIXME comment mentioning it.  I plan to add such
> a parameter and use it in max_object_size() in a future change.
> 
> Testing with an ILP32 compiler also ran into the known limitation
> of the strlen pass being unable to determine the length of array
> members of local aggregates (PR 83543) initialized using
> the braced-list syntax.  gcc.dg/tree-ssa/builtin-snprintf-6.c
> fails a few cases as a result.I've xfailed the assertions
> for targets other than x86_64 where it isn't an issue.
> 
> Martin
> 
> gcc-91567.diff
> 
> PR tree-optimization/91567 - Spurious -Wformat-overflow warnings building 
> glibc (32-bit only)
> 
> gcc/ChangeLog:
> 
>   PR tree-optimization/91567
>   * gimple-ssa-sprintf.c (get_string_length): Handle more forms of lengths
>   of unknown strings.
>   * vr-values.c (vr_values::extract_range_basic): Set strlen upper bound
>   to PTRDIFF_MAX - 2.
> 
> gcc/testsuite/ChangeLog:
> 
>   PR tree-optimization/91567
>   * gcc.dg/tree-ssa/builtin-snprintf-6.c: Xfail a subset of assertions
>   on targets other than x86_64 to work around PR 83543.
>   * gcc.dg/tree-ssa/builtin-sprintf-warn-22.c: New test.
OK.  I'm not sure this will fix the glibc issue (it looked like it was
unrelated to ILP32 to me).

jeff

[Bug c++/91262] using template type parameter after typename

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91262

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-08-27
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

Re: [PATCH] builtin fadd variants implementation

[Joseph Myers]

On Mon, 26 Aug 2019, Tejas Joshi wrote:

> Hello.
> I have made changes in the patch according to the above corrections.
> However, I didn't understand how these following testcases are
> supposed to handle. Will you please elaborate some more?
> 
> > (E.g. fadd (0x1.01p0, FLT_MIN), as an example from the glibc
> > tests: cases where an intermediate rounding produces a result half way
> > between two values of the narrower type, but the exact value is such that
> > the result of fadd should end up with last bit odd whereas double rounding
> > would result in last bit even in such half-way cases.)

The point of this is to demonstrate that fadd (x, y) is different from 
(float) (x + y), by testing with inputs for which the two evaluate to 
different values.

> > Then you should have some tests of what does *not* get optimized with
> > given compiler options if possible.  (Such a test might e.g. define a
> > static fadd function locally that checks it gets called as expected, or
> > else check the exceptions / errno if you rely on a suitable libm being
> > available.)

There would include:

* A test where the result is within range but inexact; say fadd (1, 
DBL_MIN).  With -ftrapping-math -fno-rounding-math, or -frounding-math 
-fno-trapping-math, or -frounding-math -ftrapping-math, this should not be 
folded; that is, it should be compiled to call a fadd function (which you 
might define in the test as a staic function that sets a variable to 
indicate that it was called, so the test can verify at runtime that the 
call did not get folded).

* But the same inputs, with -fno-trapping-math -fno-rounding-math 
-fmath-errno, *should* get folded (so test the same inputs with those 
options with a link_error test like those for roundeven).

* Then similarly test overflow / underflow cases (e.g. fadd (DBL_MAX, 
DBL_MAX) or fadd (DBL_MIN, DBL_MIN)) with -fno-trapping-math 
-fno-rounding-math -fmath-errno (make sure they don't get folded), and 
with -fno-trapping-math-fno-rounding-math -fno-math-errno (make sure that 
in that case they do get folded, so link_error tests).

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

[PATCH] correct an ILP32/LP64 bug in sprintf warning (PR 91567)

[Martin Sebor]

The recent sprintf+strlen integration doesn't handle unbounded
string lengths entirely correctly for ILP32 targets and causes
-Wformat-overflow false positives in some common cases, including
during GCC bootstrap targeting such systems  The attached patch
fixes that mistake.  (I think this code could be cleaned up and
simplified some more but in the interest of unblocking the ILP32
bootstrap and Glibc builds I haven't taken the time to do that.)
The patch also adjusts down the maximum strlen result set by EVRP
to PTRDIFF_MAX - 2, to match what the strlen pass does.

The strlen maximum would ideally be computed in terms of
max_object_size() (for which there would ideally be a --param
setting), and checked the same way to avoid off-by-one mistakes
between subsystems and their clients.  I have not made this change
here but added a FIXME comment mentioning it.  I plan to add such
a parameter and use it in max_object_size() in a future change.

Testing with an ILP32 compiler also ran into the known limitation
of the strlen pass being unable to determine the length of array
members of local aggregates (PR 83543) initialized using
the braced-list syntax.  gcc.dg/tree-ssa/builtin-snprintf-6.c
fails a few cases as a result.I've xfailed the assertions
for targets other than x86_64 where it isn't an issue.

Martin
PR tree-optimization/91567 - Spurious -Wformat-overflow warnings building glibc (32-bit only)

gcc/ChangeLog:

	PR tree-optimization/91567
	* gimple-ssa-sprintf.c (get_string_length): Handle more forms of lengths
	of unknown strings.
	* vr-values.c (vr_values::extract_range_basic): Set strlen upper bound
	to PTRDIFF_MAX - 2.

gcc/testsuite/ChangeLog:

	PR tree-optimization/91567
	* gcc.dg/tree-ssa/builtin-snprintf-6.c: Xfail a subset of assertions
	on targets other than x86_64 to work around PR 83543.
	* gcc.dg/tree-ssa/builtin-sprintf-warn-22.c: New test.

Index: gcc/gimple-ssa-sprintf.c
===
--- gcc/gimple-ssa-sprintf.c	(revision 274960)
+++ gcc/gimple-ssa-sprintf.c	(working copy)
@@ -1994,11 +1994,22 @@ get_string_length (tree str, unsigned eltsize, con
  or it's SIZE_MAX otherwise.  */
 
   /* Return the default result when nothing is known about the string.  */
-  if (lendata.maxbound
-  && integer_all_onesp (lendata.maxbound)
-  && integer_all_onesp (lendata.maxlen))
-return fmtresult ();
+  if (lendata.maxbound)
+{
+  if (integer_all_onesp (lendata.maxbound)
+  	  && integer_all_onesp (lendata.maxlen))
+  	return fmtresult ();
 
+  if (!tree_fits_uhwi_p (lendata.maxbound)
+	  || !tree_fits_uhwi_p (lendata.maxlen))
+  	return fmtresult ();
+
+  unsigned HOST_WIDE_INT lenmax = tree_to_uhwi (max_object_size ()) - 2;
+  if (lenmax <= tree_to_uhwi (lendata.maxbound)
+	  && lenmax <= tree_to_uhwi (lendata.maxlen))
+	return fmtresult ();
+}
+
   HOST_WIDE_INT min
 = (tree_fits_uhwi_p (lendata.minlen)
? tree_to_uhwi (lendata.minlen)
Index: gcc/vr-values.c
===
--- gcc/vr-values.c	(revision 274960)
+++ gcc/vr-values.c	(working copy)
@@ -1319,7 +1319,12 @@ vr_values::extract_range_basic (value_range *vr, g
 		tree max = vrp_val_max (ptrdiff_type_node);
 		wide_int wmax = wi::to_wide (max, TYPE_PRECISION (TREE_TYPE (max)));
 		tree range_min = build_zero_cst (type);
-		tree range_max = wide_int_to_tree (type, wmax - 1);
+		/* To account for the terminating NUL, the maximum length
+		   is one less than the maximum array size, which in turn
+		   is one  less than PTRDIFF_MAX (or SIZE_MAX where it's
+		   smaller than the former type).
+		   FIXME: Use max_object_size() - 1 here.  */
+		tree range_max = wide_int_to_tree (type, wmax - 2);
 		vr->set (VR_RANGE, range_min, range_max);
 		return;
 	  }
Index: gcc/testsuite/gcc.dg/tree-ssa/builtin-snprintf-6.c
===
--- gcc/testsuite/gcc.dg/tree-ssa/builtin-snprintf-6.c	(revision 274960)
+++ gcc/testsuite/gcc.dg/tree-ssa/builtin-snprintf-6.c	(working copy)
@@ -65,6 +65,10 @@ void test_assign_init_list (void)
   T (5, ARGS ({ 1, 2, 3, 4, 5, 6, 0 }), "s=%.*s", 3, [2]);
 }
 
+#if __x86_64__
+
+/* Enabled only on x86_64 to work around PR 83543.  */
+
 #undef T
 #define T(expect, init, fmt, ...)			\
   do {			\
@@ -87,7 +91,10 @@ void test_assign_aggregate (void)
   T (5, "123456", "s=%.*s", 3, [2]);
 }
 
+/* { dg-final { scan-tree-dump-times "Function test_assign_aggregate" 1 "optimized" { xfail { ! x86_64-*-* } } } } */
 
+#endif   /* x86_64 */
+
 #undef T
 #define T(expect, init, fmt, ...)			\
   do {			\
Index: gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-22.c
===
--- gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-22.c	(nonexistent)
+++ gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-22.c	(working copy)
@@ -0,0 +1,58 @@
+/* PR 

[Bug tree-optimization/91570] [10 Regression] ICE in get_range_strlen_dynamic on a conditional of two strings

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91570

Martin Sebor  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-08-27
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
   Target Milestone|--- |10.0
 Ever confirmed|0   |1

[Bug tree-optimization/91570] New: [10 Regression] ICE in get_range_strlen_dynamic on a conditional of two strings

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91570

Bug ID: 91570
   Summary: [10 Regression] ICE in get_range_strlen_dynamic on a
conditional of two strings
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

A snprintf call with the conditional expression involving a string of known
length (zero) and another of some minimum length (at least 1) triggers an ICE
in the get_range_strlen_dynamic function newly added in r274933.

$ cat z.c && gcc -O2 -S -Wall -fdump-tree-strlen=/dev/stdout z.c
extern char a[], b[];

void f (int i)
{
  a[0] = 0; 
  b[0] = '1';

  const char *p = i ? b : a;

  if (__builtin_snprintf (0, 0, "%s", p) < 4)
__builtin_abort ();  
}

;; Function f (f, funcdef_no=0, decl_uid=1926, cgraph_uid=1, symbol_order=0)

;; 1 loops found
;;
;; Loop 0
;;  header 0, latch 1
;;  depth 0, outer -1
;;  nodes: 0 1 2 3 4 5 6
;; 2 succs { 3 4 }
;; 3 succs { 4 }
;; 4 succs { 5 6 }
;; 5 succs { }
;; 6 succs { 1 }
z.c:10: __builtin_snprintf: objsize = 9223372036854775807, fmtstr = "%s"
  Directive 1 at offset 0: "%s"
during GIMPLE pass: strlen
dump file: /dev/stdout



EMERGENCY DUMP:

f (int i)
{
  int _1;
  char[] * iftmp.0_2;

   [local count: 1073741824]:
  a[0] = 0;
  b[0] = 49;
  if (i_6(D) != 0)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 536870912]:

   [local count: 1073741824]:
  # iftmp.0_2 = PHI <(2), (3)>
  _1 = __builtin_snprintf (0B, 0, "%s", iftmp.0_2);
  if (_1 <= 3)
goto ; [0.00%]
  else
goto ; [100.00%]

   [count: 0]:
  __builtin_abort ();

   [local count: 1073741824]:
  return;

}


z.c: In function ‘f’:
z.c:3:6: internal compiler error: Segmentation fault
3 | void f (int i)
  |  ^
0x11c54ca crash_signal
/src/gcc/svn/gcc/toplev.c:326
0x815854 contains_struct_check(tree_node const*, tree_node_structure_enum, char
const*, int, char const*)
/src/gcc/svn/gcc/tree.h:3632
0x84e032 wi::extended_tree<192>::extended_tree(tree_node const*)
/src/gcc/svn/gcc/tree.h:5802
0x84cedf generic_wide_int >::generic_wide_int(tree_node const* const&)
/src/gcc/svn/gcc/wide-int.h:782
0x84ca19 wi::to_widest(tree_node const*)
/src/gcc/svn/gcc/tree.h:5729
0x84ca3b tree_int_cst_lt(tree_node const*, tree_node const*)
/src/gcc/svn/gcc/tree.h:5982
0x14bdde1 get_range_strlen_dynamic
/src/gcc/svn/gcc/tree-ssa-strlen.c:916
0x14be432 get_range_strlen_dynamic(tree_node*, c_strlen_data*, vr_values
const*)
/src/gcc/svn/gcc/tree-ssa-strlen.c:1037
0x2047374 get_string_length
/src/gcc/svn/gcc/gimple-ssa-sprintf.c:1980
0x204796b format_string
/src/gcc/svn/gcc/gimple-ssa-sprintf.c:2170
0x2049274 format_directive
/src/gcc/svn/gcc/gimple-ssa-sprintf.c:2730
0x204b522 compute_format_length
/src/gcc/svn/gcc/gimple-ssa-sprintf.c:3532
0x204cdec handle_printf_call(gimple_stmt_iterator*, vr_values const*)
/src/gcc/svn/gcc/gimple-ssa-sprintf.c:4199
0x14c8560 strlen_check_and_optimize_call
/src/gcc/svn/gcc/tree-ssa-strlen.c:4445
0x14c8ed3 check_and_optimize_stmt
/src/gcc/svn/gcc/tree-ssa-strlen.c:4581
0x14c9a08 strlen_dom_walker::before_dom_children(basic_block_def*)
/src/gcc/svn/gcc/tree-ssa-strlen.c:4808
0x1fbf79c dom_walker::walk(basic_block_def*)
/src/gcc/svn/gcc/domwalk.c:309
0x14c9cdc printf_strlen_execute
/src/gcc/svn/gcc/tree-ssa-strlen.c:4872
0x14c9f72 execute
/src/gcc/svn/gcc/tree-ssa-strlen.c:4974
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/91563] [9 regression] wrong code

[guillaume at morinfr dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91563

--- Comment #5 from Guillaume Morin  ---
Jakub mentioned that r273135 fixed the abort() in the trunk. I noticed that
this revision had already been backported to the gcc-9 branch as r274532. So I
built the gcc-9 branch and I can confirm that it does fix the problem.

[PATCH] PR fortran/91565 -- Extra checks on ORDER

[Steve Kargl]

The attached ptch implements additional checks on the
ORDER dummy argument for the RESHAPE intrinsic function.
Built and regression tested on x86_64-*-freebsd.  OK to
commit?

2019-08-27  Steven G. Kargl  

PR fortran/91565
* simplify.c (gfc_simplify_reshape): Add additional checks of the
ORDER dummy argument.

2019-08-27  Steven G. Kargl  

PR fortran/91565
* gfortran.dg/pr91565.f90: New test.
-- 
Steve
Index: gcc/fortran/simplify.c
===
--- gcc/fortran/simplify.c	(revision 274961)
+++ gcc/fortran/simplify.c	(working copy)
@@ -6495,7 +6503,14 @@ gfc_simplify_real (gfc_expr *e, gfc_expr *k)
   if (e->expr_type != EXPR_CONSTANT)
 return NULL;
 
+  /* For explicit conversion, turn off -Wconversion and -Wconversion-extra
+ warning.  */
+  tmp1 = warn_conversion;
+  tmp2 = warn_conversion_extra;
+  warn_conversion = warn_conversion_extra = 0;
   result = gfc_convert_constant (e, BT_REAL, kind);
+  warn_conversion = tmp1;
+  warn_conversion_extra = tmp2;
   if (result == _bad_expr)
 return _bad_expr;
 
@@ -6668,6 +6683,9 @@ gfc_simplify_reshape (gfc_expr *source, gfc_expr *shap
   mpz_init (index);
   rank = 0;
 
+  for (i = 0; i < GFC_MAX_DIMENSIONS; i++)
+x[i] = 0;
+
   for (;;)
 {
   e = gfc_constructor_lookup_expr (shape_exp->value.constructor, rank);
@@ -6692,9 +6710,29 @@ gfc_simplify_reshape (gfc_expr *source, gfc_expr *shap
 }
   else
 {
-  for (i = 0; i < rank; i++)
-	x[i] = 0;
+  mpz_t size;
+  int order_size, shape_size;
 
+  if (order_exp->rank != shape_exp->rank)
+	{
+	  gfc_error ("Shapes of ORDER at %L and SHAPE at %L are different",
+		 _exp->where, _exp->where);
+	  return _bad_expr;
+	}
+
+  gfc_array_size (shape_exp, );
+  shape_size = mpz_get_ui (size);
+  mpz_clear (size);
+  gfc_array_size (order_exp, );
+  order_size = mpz_get_ui (size);
+  mpz_clear (size);
+  if (order_size != shape_size)
+	{
+	  gfc_error ("Sizes of ORDER at %L and SHAPE at %L are different",
+		 _exp->where, _exp->where);
+	  return _bad_expr;
+	}
+
   for (i = 0; i < rank; i++)
 	{
 	  e = gfc_constructor_lookup_expr (order_exp->value.constructor, i);
@@ -6704,7 +6742,12 @@ gfc_simplify_reshape (gfc_expr *source, gfc_expr *shap
 
 	  gcc_assert (order[i] >= 1 && order[i] <= rank);
 	  order[i]--;
-	  gcc_assert (x[order[i]] == 0);
+	  if (x[order[i]] != 0)
+	{
+	  gfc_error ("ORDER at %L is not a permutation of the size of "
+			 "SHAPE at %L", _exp->where, _exp->where);
+	  return _bad_expr;
+	}
 	  x[order[i]] = 1;
 	}
 }
Index: gcc/testsuite/gfortran.dg/pr91565.f90
===
--- gcc/testsuite/gfortran.dg/pr91565.f90	(nonexistent)
+++ gcc/testsuite/gfortran.dg/pr91565.f90	(working copy)
@@ -0,0 +1,17 @@
+! { dg-do compile }
+! PR fortran/91565
+! Contributed by Gerhard Steinmetz
+program p
+   integer, parameter :: a(2) = [2,2]  ! { dg-error "\(1\)" }
+   print *, reshape([1,2,3,4,5,6], [2,3], order=a) ! { dg-error "not a permutation" }
+end
+
+subroutine foo
+   integer, parameter :: a(1) = 1  ! { dg-error "\(1\)" }
+   print *, reshape([1,2,3,4,5,6], [2,3], order=a) ! { dg-error "are different" }
+end
+
+subroutine bar
+   integer, parameter :: a(1,2) = 1! { dg-error "\(1\)" }
+   print *, reshape([1,2,3,4,5,6], [2,3], order=a) ! { dg-error "are different" }
+end

C++ PATCH for c++/91428 - warn about std::is_constant_evaluated in if constexpr

[Marek Polacek]

As discussed in 91428 and in
,

  if constexpr (std::is_constant_evaluated ())
// ...
  else
// ...

always evaluates the true branch.  Someone in the SO post said "But hopefully
compilers will just diagnose that case" so I'm adding a warning.

I didn't want to invent a completely new warning so I'm tagging along
-Wtautological-compare.

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

2019-08-27  Marek Polacek  

PR c++/91428 - warn about std::is_constant_evaluated in if constexpr.
* cp-tree.h (decl_in_std_namespace_p): Declare.
* semantics.c (is_std_constant_evaluated_p): New.
(finish_if_stmt_cond): Warn about "std::is_constant_evaluated ()" in
an if-constexpr.
* typeck.c (decl_in_std_namespace_p): No longer static.

* g++.dg/cpp2a/is-constant-evaluated9.C: New test.

diff --git gcc/cp/cp-tree.h gcc/cp/cp-tree.h
index 42f180d1dd3..225dbb67c63 100644
--- gcc/cp/cp-tree.h
+++ gcc/cp/cp-tree.h
@@ -7496,6 +7496,7 @@ extern tree finish_left_unary_fold_expr  (tree, int);
 extern tree finish_right_unary_fold_expr (tree, int);
 extern tree finish_binary_fold_expr  (tree, tree, int);
 extern bool treat_lvalue_as_rvalue_p(tree, bool);
+extern bool decl_in_std_namespace_p (tree);
 
 /* in typeck2.c */
 extern void require_complete_eh_spec_types (tree, tree);
diff --git gcc/cp/semantics.c gcc/cp/semantics.c
index 1f7745933f9..8603e57e7f7 100644
--- gcc/cp/semantics.c
+++ gcc/cp/semantics.c
@@ -723,6 +723,28 @@ begin_if_stmt (void)
   return r;
 }
 
+/* Returns true if FN, a CALL_EXPR, is a call to
+   std::is_constant_evaluated or __builtin_is_constant_evaluated.  */
+
+static bool
+is_std_constant_evaluated_p (tree fn)
+{
+  /* std::is_constant_evaluated takes no arguments.  */
+  if (call_expr_nargs (fn) != 0)
+return false;
+
+  tree fndecl = cp_get_callee_fndecl_nofold (fn);
+  if (fndecl_built_in_p (fndecl, CP_BUILT_IN_IS_CONSTANT_EVALUATED,
+BUILT_IN_FRONTEND))
+return true;
+
+  if (!decl_in_std_namespace_p (fndecl))
+return false;
+
+  tree name = DECL_NAME (fndecl);
+  return name && id_equal (name, "is_constant_evaluated");
+}
+
 /* Process the COND of an if-statement, which may be given by
IF_STMT.  */
 
@@ -738,6 +760,20 @@ finish_if_stmt_cond (tree cond, tree if_stmt)
 converted to bool.  */
   && TYPE_MAIN_VARIANT (TREE_TYPE (cond)) == boolean_type_node)
 {
+  /* if constexpr (std::is_constant_evaluated()) is always true,
+so give the user a clue.  */
+  if (warn_tautological_compare)
+   {
+ tree t = cond;
+ if (TREE_CODE (t) == CLEANUP_POINT_EXPR)
+   t = TREE_OPERAND (t, 0);
+ if (TREE_CODE (t) == CALL_EXPR
+ && is_std_constant_evaluated_p (t))
+   warning_at (EXPR_LOCATION (cond), OPT_Wtautological_compare,
+   "%qs always evaluates to true in %",
+   "std::is_constant_evaluated");
+   }
+
   cond = instantiate_non_dependent_expr (cond);
   cond = cxx_constant_value (cond, NULL_TREE);
 }
diff --git gcc/cp/typeck.c gcc/cp/typeck.c
index e2a4f285a72..c09bb309142 100644
--- gcc/cp/typeck.c
+++ gcc/cp/typeck.c
@@ -9328,7 +9328,7 @@ maybe_warn_about_returning_address_of_local (tree retval)
 
 /* Returns true if DECL is in the std namespace.  */
 
-static bool
+bool
 decl_in_std_namespace_p (tree decl)
 {
   return (decl != NULL_TREE
diff --git gcc/testsuite/g++.dg/cpp2a/is-constant-evaluated9.C 
gcc/testsuite/g++.dg/cpp2a/is-constant-evaluated9.C
new file mode 100644
index 000..37833698992
--- /dev/null
+++ gcc/testsuite/g++.dg/cpp2a/is-constant-evaluated9.C
@@ -0,0 +1,49 @@
+// PR c++/91428 - warn about std::is_constant_evaluated in if constexpr.
+// { dg-do compile { target c++2a } }
+// { dg-options "-Wtautological-compare" }
+
+namespace std {
+  constexpr inline bool
+  is_constant_evaluated () noexcept
+  {
+return __builtin_is_constant_evaluated (); 
+  }
+}
+
+constexpr int
+foo(int i)
+{
+  if constexpr (std::is_constant_evaluated ()) // { dg-warning 
".std::is_constant_evaluated. always evaluates to true in .if constexpr." }
+return 42;
+  else
+return i;
+}
+
+constexpr int
+foo2(int i)
+{
+  if constexpr (__builtin_is_constant_evaluated ()) // { dg-warning 
".std::is_constant_evaluated. always evaluates to true in .if constexpr." }
+return 42;
+  else
+return i;
+}
+
+constexpr int
+foo3(int i)
+{
+  // I is not a constant expression but we short-circuit it.
+  if constexpr (__builtin_is_constant_evaluated () || i)
+return 42;
+  else
+return i;
+}
+
+constexpr int
+foo4(int i)
+{
+  const int j = 0;
+  if constexpr (j && __builtin_is_constant_evaluated ())
+return 42;
+  else
+return i;
+}

[Bug target/88082] ICE in change_address_1, at emit-rtl.c:2286

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88082

Martin Liška  changed:

   What|Removed |Added

   Keywords|needs-bisection |
 Status|ASSIGNED|NEW
   Assignee|marxin at gcc dot gnu.org  |unassigned at gcc dot 
gnu.org

--- Comment #3 from Martin Liška  ---
It's fixed by your commit r268798. Feel free to close the issue it's a dup of
PR89233. Thanks.

Re: C++ PATCH for c++/81676 - bogus -Wunused warnings in constexpr if

[Marek Polacek]

On Fri, Aug 23, 2019 at 02:20:53PM -0700, Jason Merrill wrote:
> On 8/19/19 11:28 AM, Marek Polacek wrote:
> > On Fri, Aug 16, 2019 at 06:20:20PM -0700, Jason Merrill wrote:
> > > On 8/16/19 2:29 PM, Marek Polacek wrote:
> > > > This patch is an attempt to fix the annoying -Wunused-but-set-* 
> > > > warnings that
> > > > tend to occur with constexpr if.  When we have something like
> > > > 
> > > > template < typename T >
> > > > int f(T v){
> > > > if constexpr(sizeof(T) == sizeof(int)){
> > > >   return v;
> > > > }else{
> > > >   return 0;
> > > > }
> > > > }
> > > > 
> > > > and call f('a'), then the condition is false, meaning that we won't 
> > > > instantiate
> > > > the then-branch, as per tsubst_expr/IF_STMT:
> > > > 17284   if (IF_STMT_CONSTEXPR_P (t) && integer_zerop (tmp))
> > > > 17285 /* Don't instantiate the THEN_CLAUSE. */;
> > > > so we'll never get round to mark_exp_read-ing the decls used in the
> > > > then-branch, causing finish_function to emit "parameter set but not 
> > > > used"
> > > > warnings.
> > > > 
> > > > It's unclear how to best deal with this.  Marking the decls DECL_READ_P 
> > > > while
> > > > parsing doesn't seem like a viable approach
> > > 
> > > Why not?
> > 
> > Well, while parsing, we're in a template and so the condition won't be
> > evaluated until tsubst_expr.  So we can't tell which branch is dead.
> 
> But if a decl is used on one branch, we shouldn't warn even if it isn't used
> on the selected branch.

I didn't want to mark the decls as read multiple times but we do it anyway
so that's no longer my concern.  So...

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

2019-08-27  Marek Polacek  

PR c++/81676 - bogus -Wunused warnings in constexpr if.
* semantics.c (maybe_mark_exp_read_r): New function.
(finish_if_stmt): Call it on THEN_CLAUSE and ELSE_CLAUSE.

* g++.dg/cpp1z/constexpr-if31.C: New test.
* g++.dg/cpp1z/constexpr-if32.C: New test.

diff --git gcc/cp/semantics.c gcc/cp/semantics.c
index 1f7745933f9..2ba8e635ab7 100644
--- gcc/cp/semantics.c
+++ gcc/cp/semantics.c
@@ -774,6 +774,18 @@ finish_else_clause (tree if_stmt)
   ELSE_CLAUSE (if_stmt) = pop_stmt_list (ELSE_CLAUSE (if_stmt));
 }
 
+/* Callback for cp_walk_tree to mark all {VAR,PARM}_DECLs in a tree as
+   read.  */
+
+static tree
+maybe_mark_exp_read_r (tree *tp, int *, void *)
+{
+  tree t = *tp;
+  if (VAR_P (t) || TREE_CODE (t) == PARM_DECL)
+mark_exp_read (t);
+  return NULL_TREE;
+}
+
 /* Finish an if-statement.  */
 
 void
@@ -781,6 +793,16 @@ finish_if_stmt (tree if_stmt)
 {
   tree scope = IF_SCOPE (if_stmt);
   IF_SCOPE (if_stmt) = NULL;
+  if (IF_STMT_CONSTEXPR_P (if_stmt))
+{
+  /* Prevent various -Wunused warnings.  We might not instantiate
+either of these branches, so we would not mark the variables
+used in that branch as read.  */
+  cp_walk_tree_without_duplicates (_CLAUSE (if_stmt),
+  maybe_mark_exp_read_r, NULL);
+  cp_walk_tree_without_duplicates (_CLAUSE (if_stmt),
+  maybe_mark_exp_read_r, NULL);
+}
   add_stmt (do_poplevel (scope));
 }
 
diff --git gcc/testsuite/g++.dg/cpp1z/constexpr-if31.C 
gcc/testsuite/g++.dg/cpp1z/constexpr-if31.C
new file mode 100644
index 000..02140cff9fd
--- /dev/null
+++ gcc/testsuite/g++.dg/cpp1z/constexpr-if31.C
@@ -0,0 +1,79 @@
+// PR c++/81676 - bogus -Wunused warnings in constexpr if.
+// { dg-do compile { target c++17 } }
+// { dg-options "-Wall -Wextra" }
+
+template  int
+f1 (T v)
+{
+  T x = 0;
+  if constexpr(sizeof(T) == sizeof(int))
+return v + x;
+  else
+return 0;
+}
+
+template  int
+f2 (T v) // { dg-warning "unused parameter .v." }
+{
+  T x = 0;
+  if constexpr(sizeof(T) == sizeof(int))
+return x;
+  else
+return 0;
+}
+
+template  int
+f3 (T v)
+{
+  T x = 0; // { dg-warning "unused variable .x." }
+  if constexpr(sizeof(T) == sizeof(int))
+return v;
+  else
+return 0;
+}
+
+template  int
+f4 (T v)
+{
+  T x = 0;
+  if constexpr(sizeof(T) == sizeof(int))
+return 0;
+  else
+return v + x;
+}
+
+template  int
+f5 (T v) // { dg-warning "unused parameter .v." }
+{
+  T x = 0;
+  if constexpr(sizeof(T) == sizeof(int))
+return 0;
+  else
+return x;
+}
+
+template  int
+f6 (T v)
+{
+  T x = 0; // { dg-warning "unused variable .x." }
+  if constexpr(sizeof(T) == sizeof(int))
+return 0;
+  else
+return v;
+}
+
+int main()
+{
+  f1(0);
+  f1('a');
+  f2(0);
+  f2('a');
+  f3(0);
+  f3('a');
+  f4(0);
+  f4('a');
+  f5(0);
+  f5('a');
+  f6(0);
+  f6('a');
+}
diff --git gcc/testsuite/g++.dg/cpp1z/constexpr-if32.C 
gcc/testsuite/g++.dg/cpp1z/constexpr-if32.C
new file mode 100644
index 000..13a6039fce6
--- /dev/null
+++ gcc/testsuite/g++.dg/cpp1z/constexpr-if32.C
@@ -0,0 +1,16 @@
+// PR c++/81676 - bogus -Wunused warnings in constexpr if.
+// { dg-do 

[Bug c++/91222] [10 Regression] 507.cactuBSSN_r build fails in warn_types_mismatch at ipa-devirt.c:1006 since r273571

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91222

--- Comment #15 from Jason Merrill  ---
(In reply to Jason Merrill from comment #13)
> But that still doesn't make the types the same, and the use of the variable
> in 2.ii has undefined behavior because it is accessing the value of the
> object through the wrong type, so the warning is correct.  We may want to
> allow it anyway for C compatibility.  Thoughts?

This does seem like significant trouble to make something work that isn't
actually valid C++, and it isn't hard to fix the code by giving the struct a
name.  Is the problematic header part of publicly available source code or only
the benchmark?

[Bug target/88617] ICE in ix86_compute_frame_layout, at config/i386/i386.c:11238 since r248029

[daniel.santos at pobox dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88617

--- Comment #3 from Daniel Santos  ---
(In reply to Martin Liška from comment #2)
> @Daniel: Can you please take a look?

My apologies for missing this one!  I'll take a look.

Re: C++ PATCH to implement C++20 P1143R2, constinit (PR c++/91360)

[Marek Polacek]

On Tue, Aug 27, 2019 at 09:54:50PM +0200, Paolo Carlini wrote:
> Hi,
> 
> On 14/08/19 23:22, Marek Polacek wrote:
> > +  /* [dcl.spec]/2 "At most one of the constexpr, consteval, and constinit
> > + keywords shall appear in a decl-specifier-seq."  */
> > +  if (constinit_p && constexpr_p)
> > +{
> > +  error_at (min_location (declspecs->locations[ds_constinit],
> > + declspecs->locations[ds_constexpr]),
> > +   "can use at most one of the % and % "
> > +   "specifiers");
> 
> For this error we also have the option of using a gcc_rich_location, and
> add_range, etc, like for signed_p && unsigned_p, for example. Just saying,
> since we have the infrastructure ready...

Happy to polish the diagnostic after the core bits are in ;-).

--
Marek Polacek • Red Hat, Inc. • 300 A St, Boston, MA

Re: C++ PATCH to implement C++20 P1143R2, constinit (PR c++/91360)

[Paolo Carlini]

Hi,

On 14/08/19 23:22, Marek Polacek wrote:

+  /* [dcl.spec]/2 "At most one of the constexpr, consteval, and constinit
+ keywords shall appear in a decl-specifier-seq."  */
+  if (constinit_p && constexpr_p)
+{
+  error_at (min_location (declspecs->locations[ds_constinit],
+ declspecs->locations[ds_constexpr]),
+   "can use at most one of the % and % "
+   "specifiers");


For this error we also have the option of using a gcc_rich_location, and 
add_range, etc, like for signed_p && unsigned_p, for example. Just 
saying, since we have the infrastructure ready...


Paolo.

[Bug fortran/91565] [8/9/10 Regression] ICE in gfc_simplify_reshape, at fortran/simplify.c:6707 etc.

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91565

--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to kargl from comment #1)
> (In reply to G. Steinmetz from comment #0)
> > ICE hits gfortran-8 and higher - this changed just before 20180525.
> > Starting with correct code z0.f90, then providing wrong orders
> > (accepted up to gfortran-7) :
> > 
> > 
> > $ cat z0.f90
> > program p
> >integer, parameter :: a(2) = [2,1]
> >print *, reshape([1,2,3,4,5,6], [2,3], order=a)
> > end
> > 
> > $ gfortran-10 z0.f90 && ./a.out
> >1   4   2   5   3   6
> > 
> > 
> > 
> > $ cat z1.f90   # not a permutation
> > program p
> >integer, parameter :: a(2) = [2,2]
> >print *, reshape([1,2,3,4,5,6], [2,3], order=a)
> > end
> > 
> > 
> 
> If I understand correctly, this is invalid because 'a' is
> not a permutation of the [1, 2, ..., n] where n = size(shape).
> I have a fix for this.

Hmmm. This is messed up.  check.c(gfc_check_reshape) is doing some of the work
that is done in simplify.c(gfc__simplity_reshape).  These two functions can
probably use a rewrite to avoid duplication of effort.

Re: [PR fortran/91496] !GCC$ directives error if mistyped or unknown

[Harald Anlauf]

Committed to trunk as svn revision 274966, after removing some
accidentally left-over unused variable declarations (copy).
The actual committed version is attached.

Thanks, Paul, for the quick review!

Unless there are strong objections, I'd like to commit this to
9-branch, too, so that this can be used in the 9.3 release.
Applies/regtests cleanly.  Will wait for a week or so.

Harald

On 08/27/19 10:33, Paul Richard Thomas wrote:
> Hi Harald,
>
> This is OK for trunk.
>
> Thanks!
>
> Paul
>
> On Mon, 26 Aug 2019 at 22:13, Harald Anlauf  wrote:
>>
>> Dear all,
>>
>> the attached patch adds Fortran support for the following pragmas
>> (loop annotations): IVDEP (ignore vector dependencies), VECTOR, and
>> NOVECTOR.  Furthermore, it downgrades unsupported directives from
>> error to warning (by default, it stays an error with -pedantic),
>> thus fixing the PR.
>>
>> It has no effect on existing code (thus regtested cleanly on
>> x86_64-pc-linux-gnu), but gives users an option for fine-grained
>> control of optimization.  The above pragmas are supported by other
>> compilers (with different sentinels, e.g. !DIR$ for Intel, Cray,
>> sometimes with slightly different keywords).
>>
>> OK for trunk, and backport to 9?
>>
>> Thanks,
>> Harald
>>
>>
>> 2019-08-26  Harald Anlauf  
>>
>> PR fortran/91496
>> * gfortran.h: Extend struct gfc_iterator for loop annotations.
>> * array.c (gfc_copy_iterator): Copy loop annotations by IVDEP,
>> VECTOR, and NOVECTOR pragmas.
>> * decl.c (gfc_match_gcc_ivdep, gfc_match_gcc_vector)
>> (gfc_match_gcc_novector): New matcher functions handling IVDEP,
>> VECTOR, and NOVECTOR pragmas.
>> * match.h: Declare prototypes of matcher functions handling IVDEP,
>> VECTOR, and NOVECTOR pragmas.
>> * parse.c (decode_gcc_attribute, parse_do_block)
>> (parse_executable): Decode IVDEP, VECTOR, and NOVECTOR pragmas;
>> emit warning for unrecognized pragmas instead of error.
>> * trans-stmt.c (gfc_trans_simple_do, gfc_trans_do): Add code to
>> emit annotations for IVDEP, VECTOR, and NOVECTOR pragmas.
>> * gfortran.texi: Document IVDEP, VECTOR, and NOVECTOR pragmas.
>>
>> 2019-08-26  Harald Anlauf  
>>
>> PR fortran/91496
>> * gfortran.dg/pr91496.f90: New testcase.
>>
>
>

Index: gcc/fortran/array.c
===
--- gcc/fortran/array.c (Revision 274964)
+++ gcc/fortran/array.c (Arbeitskopie)
@@ -2185,6 +2185,9 @@
   dest->end = gfc_copy_expr (src->end);
   dest->step = gfc_copy_expr (src->step);
   dest->unroll = src->unroll;
+  dest->ivdep = src->ivdep;
+  dest->vector = src->vector;
+  dest->novector = src->novector;
 
   return dest;
 }
Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c  (Revision 274964)
+++ gcc/fortran/decl.c  (Arbeitskopie)
@@ -99,6 +99,11 @@
 /* Set upon parsing a !GCC$ unroll n directive for use in the next loop.  */
 int directive_unroll = -1;
 
+/* Set upon parsing supported !GCC$ pragmas for use in the next loop.  */
+bool directive_ivdep = false;
+bool directive_vector = false;
+bool directive_novector = false;
+
 /* Map of middle-end built-ins that should be vectorized.  */
 hash_map *gfc_vectorized_builtins;
 
@@ -11528,3 +11533,53 @@
 
   return MATCH_YES;
 }
+
+/* Match an !GCC$ IVDEP statement.
+   When we come here, we have already matched the !GCC$ IVDEP string.  */
+
+match
+gfc_match_gcc_ivdep (void)
+{
+  if (gfc_match_eos () == MATCH_YES)
+{
+  directive_ivdep = true;
+  return MATCH_YES;
+}
+
+  gfc_error ("Syntax error in !GCC$ IVDEP directive at %C");
+  return MATCH_ERROR;
+}
+
+/* Match an !GCC$ VECTOR statement.
+   When we come here, we have already matched the !GCC$ VECTOR string.  */
+
+match
+gfc_match_gcc_vector (void)
+{
+  if (gfc_match_eos () == MATCH_YES)
+{
+  directive_vector = true;
+  directive_novector = false;
+  return MATCH_YES;
+}
+
+  gfc_error ("Syntax error in !GCC$ VECTOR directive at %C");
+  return MATCH_ERROR;
+}
+
+/* Match an !GCC$ NOVECTOR statement.
+   When we come here, we have already matched the !GCC$ NOVECTOR string.  */
+
+match
+gfc_match_gcc_novector (void)
+{
+  if (gfc_match_eos () == MATCH_YES)
+{
+  directive_novector = true;
+  directive_vector = false;
+  return MATCH_YES;
+}
+
+  gfc_error ("Syntax error in !GCC$ NOVECTOR directive at %C");
+  return MATCH_ERROR;
+}
Index: gcc/fortran/gfortran.h
===
--- gcc/fortran/gfortran.h  (Revision 274964)
+++ gcc/fortran/gfortran.h  (Arbeitskopie)
@@ -2418,6 +2418,9 @@
 {
   gfc_expr *var, *start, *end, *step;
   unsigned short unroll;
+  bool ivdep;
+  bool vector;
+  bool novector;
 }
 gfc_iterator;
 
@@ -2794,6 +2797,9 @@
 bool gfc_in_match_data (void);
 match gfc_match_char_spec 

[Bug c++/91563] [9 regression] wrong code

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91563

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-08-27
 Ever confirmed|0   |1

--- Comment #4 from Jonathan Wakely  ---
You're right, sorry. GCC warns about the memset, but that warning is apparently
given for cases that are not undefined, just questionable:

mozilla_jwakely0/test_gcc9.cc:41:51: warning: ‘void* memset(void*, int,
size_t)’ writing to an object of non-trivial type ‘struct E’; use assignment
instead [-Wclass-memaccess]

Confirmed then.

[Bug fortran/91565] [8/9/10 Regression] ICE in gfc_simplify_reshape, at fortran/simplify.c:6707 etc.

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91565

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-08-27
 CC||kargl at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from kargl at gcc dot gnu.org ---
(In reply to G. Steinmetz from comment #0)
> ICE hits gfortran-8 and higher - this changed just before 20180525.
> Starting with correct code z0.f90, then providing wrong orders
> (accepted up to gfortran-7) :
> 
> 
> $ cat z0.f90
> program p
>integer, parameter :: a(2) = [2,1]
>print *, reshape([1,2,3,4,5,6], [2,3], order=a)
> end
> 
> $ gfortran-10 z0.f90 && ./a.out
>1   4   2   5   3   6
> 
> 
> 
> $ cat z1.f90   # not a permutation
> program p
>integer, parameter :: a(2) = [2,2]
>print *, reshape([1,2,3,4,5,6], [2,3], order=a)
> end
> 
> 

If I understand correctly, this is invalid because 'a' is
not a permutation of the [1, 2, ..., n] where n = size(shape).
I have a fix for this.

[Bug rtl-optimization/91569] New: Optimisation test case and unnecessary XOR-OR pair instead of MOV.

[cubitect at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91569

Bug ID: 91569
   Summary: Optimisation test case and unnecessary XOR-OR pair
instead of MOV.
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cubitect at gmail dot com
  Target Milestone: ---

I wasn't entirely sure where to post this, but I have a very simple test 
problem that shows some missed optimisation potential. The task is to cast 
an integer to a long and replace the second lowest byte of the result with 
a constant (4). Below are three ways to achieve this:


long opt_test1(int num) //  opt_test1:
{   //  movslq  %edi, %rax
union { //  mmovb   $4, %ah
long q; //  ret
struct { char l,h; };
} a;
a.q = num;
a.h = 4;
return a.q;
}

The union here is modelled after the structure of a r?x register which 
contains the low and high byte registers: ?l and ?h. The cast and second 
byte assignment can be done in one instruction each. The optimiser manages 
to understand this and gives the optimal instructions.


long opt_test2(int num) //  opt_test2:
{   //  movl%edi, %eax
long a = num;   //  xor %ah, %ah
a &= (-1UL ^ 0xff00);   //  orb $4, %ah
a |= (4 << 8);  //  cltq
return a;   //  ret
}

This solution, based on a bitwise AND and OR, is interesting. The optimiser 
recognised that I am interested in the second byte and makes use of the 'ah' 
register, but why is there a XOR and an OR rather than an a single, 
equivalent MOV? Similarly the (MOV + CLTQ) can be replaced outright with 
MOVSLQ. Notable here is that some older versions (such as "gcc-4.8.5 -O3") 
give results that correspond more to the C code:
andl$-65281, %edi
orl $1024, %edi
movslq  %edi, %rax
ret
which is actually better than the output for gcc-9.2.


long opt_test3(int num) //  opt_test3:
{   //  movslq  %edi, %rdi
long a = num;   //  movq%rdi, -8(%rsp)
((char*))[1] = 4; //  movb$4, -7(%rsp)
return a;   //  movq-8(%rsp), %rax
}   //  ret

This is the straightforwards approach, addressing the second byte in memory.
I am including this because LLVM manages to recognise that the stack is not 
actually necessary and goes for a register based solution.

As far as I could tell, these results seem quite consistent across most GCC 
versions and across all optimisation levels above -O0. However, I obtained 
the assembly code above using:

$ gcc-9.2 opt_tests.c -S -O3 -Wall -Wextra -pedantic

[Bug fortran/91496] !GCC$ directives error if mistyped or unknown

[anlauf at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91496

--- Comment #3 from anlauf at gcc dot gnu.org ---
Author: anlauf
Date: Tue Aug 27 19:16:33 2019
New Revision: 274966

URL: https://gcc.gnu.org/viewcvs?rev=274966=gcc=rev
Log:
2019-08-27  Harald Anlauf  

PR fortran/91496
* gfortran.h: Extend struct gfc_iterator for loop annotations.
* array.c (gfc_copy_iterator): Copy loop annotations by IVDEP,
VECTOR, and NOVECTOR pragmas.
* decl.c (gfc_match_gcc_ivdep, gfc_match_gcc_vector)
(gfc_match_gcc_novector): New matcher functions handling IVDEP,
VECTOR, and NOVECTOR pragmas.
* match.h: Declare prototypes of matcher functions handling IVDEP,
VECTOR, and NOVECTOR pragmas.
* parse.c (decode_gcc_attribute, parse_do_block)
(parse_executable): Decode IVDEP, VECTOR, and NOVECTOR pragmas;
emit warning for unrecognized pragmas instead of error.
* trans-stmt.c (gfc_trans_simple_do, gfc_trans_do): Add code to
emit annotations for IVDEP, VECTOR, and NOVECTOR pragmas.
* gfortran.texi: Document IVDEP, VECTOR, and NOVECTOR pragmas.

PR fortran/91496
* gfortran.dg/pr91496.f90: New testcase.

Added:
trunk/gcc/testsuite/gfortran.dg/pr91496.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/array.c
trunk/gcc/fortran/decl.c
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/gfortran.texi
trunk/gcc/fortran/match.h
trunk/gcc/fortran/parse.c
trunk/gcc/fortran/trans-stmt.c
trunk/gcc/testsuite/ChangeLog

Re: [SVE] PR86753

[Prathamesh Kulkarni]

On Tue, 27 Aug 2019 at 21:14, Richard Sandiford
 wrote:
>
> Richard should have the final say, but some comments...
>
> Prathamesh Kulkarni  writes:
> > diff --git a/gcc/tree-vect-stmts.c b/gcc/tree-vect-stmts.c
> > index 1e2dfe5d22d..862206b3256 100644
> > --- a/gcc/tree-vect-stmts.c
> > +++ b/gcc/tree-vect-stmts.c
> > @@ -1989,17 +1989,31 @@ check_load_store_masking (loop_vec_info loop_vinfo, 
> > tree vectype,
> >
> >  static tree
> >  prepare_load_store_mask (tree mask_type, tree loop_mask, tree vec_mask,
> > -  gimple_stmt_iterator *gsi)
> > +  gimple_stmt_iterator *gsi, tree mask,
> > +  cond_vmask_map_type *cond_to_vec_mask)
>
> "scalar_mask" might be a better name.  But maybe we should key off the
> vector mask after all, now that we're relying on the code having no
> redundancies.
>
> Passing the vinfo would be better than passing the cond_vmask_map_type
> directly.
>
> >  {
> >gcc_assert (useless_type_conversion_p (mask_type, TREE_TYPE (vec_mask)));
> >if (!loop_mask)
> >  return vec_mask;
> >
> >gcc_assert (TREE_TYPE (loop_mask) == mask_type);
> > +
> > +  tree *slot = 0;
> > +  if (cond_to_vec_mask)
>
> The pointer should never be null in this context.
Disabling check for NULL results in segfault with cond_arith_4.c because we
reach prepare_load_store_mask via vect_schedule_slp, called from
here in vect_transform_loop:
 /* Schedule the SLP instances first, then handle loop vectorization
 below.  */
  if (!loop_vinfo->slp_instances.is_empty ())
{
  DUMP_VECT_SCOPE ("scheduling SLP instances");
  vect_schedule_slp (loop_vinfo);
}

which is before bb processing loop.
>
> > +{
> > +  cond_vmask_key cond (mask, loop_mask);
> > +  slot = _to_vec_mask->get_or_insert (cond);
> > +  if (*slot)
> > + return *slot;
> > +}
> > +
> >tree and_res = make_temp_ssa_name (mask_type, NULL, "vec_mask_and");
> >gimple *and_stmt = gimple_build_assign (and_res, BIT_AND_EXPR,
> > vec_mask, loop_mask);
> >gsi_insert_before (gsi, and_stmt, GSI_SAME_STMT);
> > +
> > +  if (slot)
> > +*slot = and_res;
> >return and_res;
> >  }
> > [...]
> > @@ -9975,6 +9997,38 @@ vectorizable_condition (stmt_vec_info stmt_info, 
> > gimple_stmt_iterator *gsi,
> >/* Handle cond expr.  */
> >for (j = 0; j < ncopies; j++)
> >  {
> > +  tree vec_mask = NULL_TREE;
> > +
> > +  if (loop_vinfo && LOOP_VINFO_FULLY_MASKED_P (loop_vinfo)
>
> Nit: one condition per line when the whole thing doesn't fit on a single line.
>
> > +   && TREE_CODE_CLASS (TREE_CODE (cond_expr)) == tcc_comparison
>
> Why restrict this to embedded comparisons?  It should work for separate
> comparisons too.
>
> > +   && loop_vinfo->cond_to_vec_mask)
>
> This should always be nonnull given the above.
>
> > + {
> > +   vec_loop_masks *masks = _VINFO_MASKS (loop_vinfo);
> > +   if (masks)
>
> This is never null.
>
> > + {
> > +   tree loop_mask = vect_get_loop_mask (gsi, masks,
> > +ncopies, vectype, j);
> > +
> > +   cond_vmask_key cond (cond_expr, loop_mask);
> > +   tree *slot = loop_vinfo->cond_to_vec_mask->get (cond);
> > +   if (slot && *slot)
> > + vec_mask = *slot;
> > +   else
> > + {
> > +   cond.cond_ops.code
> > + = invert_tree_comparison (cond.cond_ops.code, true);
> > +   slot = loop_vinfo->cond_to_vec_mask->get (cond);
> > +   if (slot && *slot)
> > + {
> > +   vec_mask = *slot;
> > +   tree tmp = then_clause;
> > +   then_clause = else_clause;
> > +   else_clause = tmp;
>
> Can use std::swap.
>
> > + }
> > + }
> > + }
> > + }
> > +
> >stmt_vec_info new_stmt_info = NULL;
> >if (j == 0)
> >   {
> > @@ -10054,6 +10108,8 @@ vectorizable_condition (stmt_vec_info stmt_info, 
> > gimple_stmt_iterator *gsi,
> >
> > if (masked)
> >   vec_compare = vec_cond_lhs;
> > +   else if (vec_mask)
> > + vec_compare = vec_mask;
>
> If we do drop the comparison check above, this should win over "masked".
>
> > @@ -193,6 +194,81 @@ public:
> >poly_uint64 min_value;
> >  };
> >
> > +struct cond_vmask_key
>
> I'm no good at naming things, but since "vmask" doesn't occur elsewhere
> in target-independent code, how about "vec_masked_cond_key"?
>
> > +{
> > +  cond_vmask_key (tree t, tree loop_mask_)
> > +: cond_ops (t), loop_mask (loop_mask_)
> > +  {}
> > +
> > +  hashval_t hash () const
> > +  {
> > +inchash::hash h;
> > +h.add_int (cond_ops.code);
> > +h.add_int (TREE_HASH (cond_ops.op0));
> > +h.add_int (TREE_HASH (cond_ops.op1));
>
> These two need to use inchash::add_expr, since you're hashing for
> 

[Bug tree-optimization/91567] [10 Regression] Spurious -Wformat-overflow warnings building glibc (32-bit only)

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91567

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-08-27
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Thanks, I'm working on it.
https://gcc.gnu.org/ml/gcc-patches/2019-08/msg01827.html

[Bug c++/91222] [10 Regression] 507.cactuBSSN_r build fails in warn_types_mismatch at ipa-devirt.c:1006 since r273571

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91222

Jason Merrill  changed:

   What|Removed |Added

  Attachment #46765|0   |1
is obsolete||

--- Comment #14 from Jason Merrill  ---
Created attachment 46769
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46769=edit
clear TYPE_NAME in free_lang_data for extern "C" anonymous types

Here's a more focused variant of my earlier patch.

[Bug c++/91506] Incorrectly issued error: parameter may not have variably modified type

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91506

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
Started with r166167.

[Bug c++/91222] [10 Regression] 507.cactuBSSN_r build fails in warn_types_mismatch at ipa-devirt.c:1006 since r273571

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91222

--- Comment #13 from Jason Merrill  ---
Ah, I was reading the passage a bit wrong: where the extern "C" matters is not
on the type, but on the variable (ml_bssnrest_).  Because it's extern "C",
declarations in different translation units correspond even though we can't use
the same type in both.

But that still doesn't make the types the same, and the use of the variable in
2.ii has undefined behavior because it is accessing the value of the object
through the wrong type, so the warning is correct.  We may want to allow it
anyway for C compatibility.  Thoughts?

[Bug tree-optimization/91568] internal compiler error: in vect_schedule_slp_instance, at tree-vect-slp.c:3922

[wala1 at illinois dot edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91568

--- Comment #1 from Matt Wala  ---
Created attachment 46768
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46768=edit
Full compiler output

Re: C++ PATCH to implement C++20 P1143R2, constinit (PR c++/91360)

[Marek Polacek]

On Fri, Aug 23, 2019 at 03:10:37PM -0700, Jason Merrill wrote:
> > +/* True if DECL is declared 'constinit'.  */
> > +#define DECL_DECLARED_CONSTINIT_P(DECL) \
> > +  DECL_LANG_FLAG_0 (VAR_DECL_CHECK (STRIP_TEMPLATE (DECL)))
> 
> Hmm, given that 'constinit' only affects the declaration, do we really need
> a flag on the VAR_DECL?

I was able to do without DECL_DECLARED_CONSTINIT_P.  To achieve that I
introduced LOOKUP_CONSTINIT (yes, it's an abomination; we should probably
extirpate those LOOKUP_ macros).

But that wasn't enough for variable templates, so I also had to introduce
TINFO_VAR_DECLARED_CONSTINIT.  I suppose those DECL_TEMPLATE_INFO aren't
as precious as the VAR_DECL bits.

> Hmm, the existing code limiting the unification of constexpr to class-scope
> variables seems wrong:
> 
> constexpr float pi = 3.14;
> extern const float pi;
> constexpr float x = pi; // should be OK

Thanks for fixing this meanwhile.

Is this any better?

Bootstrapped/regtested on x86_64-linux.

2019-08-27  Marek Polacek  

PR c++/91360 - Implement C++20 P1143R2: constinit.
* c-common.c (c_common_reswords): Add constinit and __constinit.
(keyword_is_decl_specifier): Handle RID_CONSTINIT.
* c-common.h (enum rid): Add RID_CONSTINIT, RID_FIRST_CXX20, and
RID_LAST_CXX20.
(D_CXX20): Define.
* c-cppbuiltin.c (c_cpp_builtins): Define __cpp_constinit.
* c-format.c (cxx_keywords): Add "constinit".
* c.opt (Wc++2a-compat, Wc++20-compat): New options.

* cp-tree.h (TINFO_VAR_DECLARED_CONSTINIT): Define.
(LOOKUP_CONSTINIT): Define.
(enum cp_decl_spec): Add ds_constinit.
* decl.c (check_tag_decl): Give an error for constinit in type
declarations.
(check_initializer): Also check LOOKUP_CONSTINIT.
(cp_finish_decl): Add checking for a constinit declaration.  Set
TINFO_VAR_DECLARED_CONSTINIT.
(grokdeclarator): Add checking for a declaration with the constinit
specifier.
* lex.c (init_reswords): Handle D_CXX20.
* parser.c (cp_lexer_get_preprocessor_token): Pass a better location
to warning_at.  Warn about C++20 keywords.
(cp_keyword_starts_decl_specifier_p): Handle RID_CONSTINIT.
(cp_parser_diagnose_invalid_type_name): Add an inform about constinit.
(cp_parser_decomposition_declaration): Maybe pass LOOKUP_CONSTINIT to
cp_finish_decl.
(cp_parser_decl_specifier_seq): Handle RID_CONSTINIT.
(cp_parser_init_declarator): Maybe pass LOOKUP_CONSTINIT to
cp_finish_decl.
(set_and_check_decl_spec_loc): Add "constinit".
* pt.c (tsubst_decl): Set TINFO_VAR_DECLARED_CONSTINIT.
(instantiate_decl): Maybe pass LOOKUP_CONSTINIT to cp_finish_decl.
* typeck2.c (store_init_value): If a constinit variable wasn't
initialized using a constant initializer, give an error.

* doc/invoke.texi: Document -Wc++20-compat.

* g++.dg/cpp2a/constinit1.C: New test.
* g++.dg/cpp2a/constinit2.C: New test.
* g++.dg/cpp2a/constinit3.C: New test.
* g++.dg/cpp2a/constinit4.C: New test.
* g++.dg/cpp2a/constinit5.C: New test.
* g++.dg/cpp2a/constinit6.C: New test.
* g++.dg/cpp2a/constinit7.C: New test.
* g++.dg/cpp2a/constinit8.C: New test.
* g++.dg/cpp2a/constinit9.C: New test.
* g++.dg/cpp2a/constinit10.C: New test.
* g++.dg/cpp2a/constinit11.C: New test.
* g++.dg/cpp2a/constinit12.C: New test.

diff --git gcc/c-family/c-common.c gcc/c-family/c-common.c
index d516deaf24c..17ca1e683a2 100644
--- gcc/c-family/c-common.c
+++ gcc/c-family/c-common.c
@@ -326,8 +326,9 @@ static bool nonnull_check_p (tree, unsigned HOST_WIDE_INT);
C --std=c89: D_C99 | D_CXXONLY | D_OBJC | D_CXX_OBJC
C --std=c99: D_CXXONLY | D_OBJC
ObjC is like C except that D_OBJC and D_CXX_OBJC are not set
-   C++ --std=c++98: D_CONLY | D_CXX11 | D_OBJC
-   C++ --std=c++11: D_CONLY | D_OBJC
+   C++ --std=c++98: D_CONLY | D_CXX11 | D_CXX20 | D_OBJC
+   C++ --std=c++11: D_CONLY | D_CXX20 | D_OBJC
+   C++ --std=c++2a: D_CONLY | D_OBJC
ObjC++ is like C++ except that D_OBJC is not set
 
If -fno-asm is used, D_ASM is added to the mask.  If
@@ -392,6 +393,7 @@ const struct c_common_resword c_common_reswords[] =
   { "__complex__", RID_COMPLEX,0 },
   { "__const", RID_CONST,  0 },
   { "__const__",   RID_CONST,  0 },
+  { "__constinit", RID_CONSTINIT,  D_CXXONLY },
   { "__decltype",   RID_DECLTYPE,   D_CXXONLY },
   { "__direct_bases",   RID_DIRECT_BASES, D_CXXONLY },
   { "__extension__",   RID_EXTENSION,  0 },
@@ -462,6 +464,7 @@ const struct c_common_resword c_common_reswords[] =
   { "class",   RID_CLASS,  D_CXX_OBJC | D_CXXWARN },
   { "const",   RID_CONST,  0 },
   { "constexpr",   RID_CONSTEXPR,  D_CXXONLY | D_CXX11 | D_CXXWARN },
+  { "constinit",   RID_CONSTINIT, 

[Bug tree-optimization/91568] New: internal compiler error: in vect_schedule_slp_instance, at tree-vect-slp.c:3922

[wala1 at illinois dot edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91568

Bug ID: 91568
   Summary: internal compiler error: in
vect_schedule_slp_instance, at tree-vect-slp.c:3922
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wala1 at illinois dot edu
  Target Milestone: ---

Created attachment 46767
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46767=edit
helmrouts3d.f file causing internal compile error

Hi,

The attached file leads to an internal compile error when compiled as follows:

$ gfortran -Wall -g -ffixed-form -fno-second-underscore -fPIC -std=legacy
-Ofast -fopenmp helmrouts3d.f
...
during GIMPLE pass: vect
helmrouts3d.f:717:0:

  717 |   subroutine h3dall(nterms,z,scale,hvec,ifder,hder)
  | 
internal compiler error: in vect_schedule_slp_instance, at tree-vect-slp.c:3922
0x7f249db9c09a __libc_start_main
../csu/libc-start.c:308
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Version:
$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 9.2.1-4'
--with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-9
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib
--with-target-system-zlib=auto --enable-multiarch --disable-werror
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none,hsa
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 9.2.1 20190821 (Debian 9.2.1-4)

[PATCH, i386]: Fix PR 91528, ICE in ix86_expand_prologue

[Uros Bizjak]

When stack alignment is increased in convert_scalars_to_vector, we
have to update several other dependant fields in crtl struct, similar
to what expand_stack_alignment from cfgexpand.c does.

2019-08-27  Uroš Bizjak  

PR target/91528
* config/i386/i386-features.c (convert_scalars_to_vector):
Update crtl->stack_realign_needed, crtl->stack_realign_tried and
crtl->stack_realign_processed.  Update crtl->drap_reg by calling
targetm.calls.get_drap_rtx.  If drap_rtx is non-null then
Update crtl->args.internal_arg_pointer and call fixup_tail_calls.

testsuite/ChangeLog:

2019-08-27  Uroš Bizjak  

PR target/91528
* gcc.target/i386/pr91528.c: New test.

Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.

Committed to mainline SVN.

Uros.
Index: config/i386/i386-features.c
===
--- config/i386/i386-features.c (revision 274958)
+++ config/i386/i386-features.c (working copy)
@@ -1651,6 +1651,32 @@ convert_scalars_to_vector (bool timode_p)
crtl->stack_alignment_needed = 128;
   if (crtl->stack_alignment_estimated < 128)
crtl->stack_alignment_estimated = 128;
+
+  crtl->stack_realign_needed
+   = INCOMING_STACK_BOUNDARY < crtl->stack_alignment_estimated;
+  crtl->stack_realign_tried = crtl->stack_realign_needed;
+
+  crtl->stack_realign_processed = true;
+
+  if (!crtl->drap_reg)
+   {
+ rtx drap_rtx = targetm.calls.get_drap_rtx ();
+
+ /* stack_realign_drap and drap_rtx must match.  */
+ gcc_assert ((stack_realign_drap != 0) == (drap_rtx != NULL));
+
+ /* Do nothing if NULL is returned,
+which means DRAP is not needed.  */
+ if (drap_rtx != NULL)
+   {
+ crtl->args.internal_arg_pointer = drap_rtx;
+
+ /* Call fixup_tail_calls to clean up
+REG_EQUIV note if DRAP is needed. */
+ fixup_tail_calls ();
+   }
+   }
+
   /* Fix up DECL_RTL/DECL_INCOMING_RTL of arguments.  */
   if (TARGET_64BIT)
for (tree parm = DECL_ARGUMENTS (current_function_decl);
Index: testsuite/gcc.target/i386/pr91528.c
===
--- testsuite/gcc.target/i386/pr91528.c (nonexistent)
+++ testsuite/gcc.target/i386/pr91528.c (working copy)
@@ -0,0 +1,14 @@
+/* PR target/91528 */
+/* { dg-do compile { target ia32 } } */
+/* { dg-options "-Os -mavx512vbmi2 -mforce-drap" } */
+
+extern long int labs (long int j);
+
+int
+main ()
+{
+  long *a = (long *)"empty";
+  int i = 1441516387;
+  a[i] = labs (a[i]);
+  return 0;
+}

Re: [PATCH V3 05/11] bpf: new GCC port

[Jose E. Marchesi]

> +(define_expand "zero_extendsidi2"
> +  [(set (match_operand:DI 0 "register_operand")
> + (zero_extend:DI (match_operand:SI 1 
"reg_or_indirect_memory_operand")))]
> +  ""
> +{
> +  if (register_operand (operands[1], SImode))
> +{
> +  operands[1] = gen_lowpart (DImode, operands[1]);
> +  emit_insn (gen_ashldi3 (operands[0], operands[1], GEN_INT 
(32)));
> +  emit_insn (gen_lshrdi3 (operands[0], operands[0], GEN_INT 
(32)));
> +  DONE;
> +}
> +})
> +
> +(define_insn "*zero_extendsidi2"
> +  [(set (match_operand:DI 0 "register_operand" "=r,r")
> + (zero_extend:DI (match_operand:SI 1 
"reg_or_indirect_memory_operand" "0,m")))]
> +  ""
> +  "@
> +   lsh\t%0,32\n\trsh\t%0,32
> +   ldxw\t%0,%1"
> +  [(set_attr "type" "alu,ldx")
> +   (set_attr "length" "16,8")])

Sorry, should have noticed last time, but: you shouldn't need to handle
register operands here given the expander above.  It's OK if you find it
improves code quality, but it'd be interesting to know why if so

If I remove the 0,=r alternative from the insn above, and also adjust
the predicate to indirect_memory_operand, then I get a segfault in one
test, in update_costs_from_allocno (ira-color.c:1382), because:

(gdb) print mode
$1 = E_SImode
(gdb) print default_target_ira_int->x_ira_register_move_cost[mode]
$13 = (move_table *) 0x0

What I think is going on is:

1. The expand above is used, and

2. there is no insn in the program matched by a pattern that involves a
   SI operand, and therefore record_operand_costs is never called on
   SImode operand, and therefore the lazily-initialized
   x_ira_register_move_cost is never filled in for E_SImode, and then

3. ira() -> ira_color() -> color () -> do_coloring () ->
   ira_traverse_loop_tree () -> color_pass () -> color_allocnos () ->
   update_costs_from_prefs () -> update_costs_from_allocno () *CRASH*

Is this a bug, or am I expected to somehow trigger the initialization of
the SImode entry in the ira register move table in some other way?

This is the backtrace btw:

jemarch@termi:~/gnu/src/gcc-git/build-bpf/gcc$ PATH=.:$PATH ./xgcc -O2 -c 
/home/jemarch/gnu/src/gcc-git/gcc/testsuite/gcc.c-torture/compile/pr39928-2.c
during RTL pass: ira
/home/jemarch/gnu/src/gcc-git/gcc/testsuite/gcc.c-torture/compile/pr39928-2.c: 
In function ‘vq_nbest’:
/home/jemarch/gnu/src/gcc-git/gcc/testsuite/gcc.c-torture/compile/pr39928-2.c:8:1:
 internal compiler error: Segmentation fault
8 | }
  | ^
0xfa8cb7 crash_signal
../../gcc/toplev.c:326
0x7f278d44e05f ???

/build/glibc-yWQXbR/glibc-2.24/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0xd4ec8b update_costs_from_allocno
../../gcc/ira-color.c:1382
0xd4ee09 update_costs_from_prefs
../../gcc/ira-color.c:1422
0xd535d9 color_allocnos
../../gcc/ira-color.c:3170
0xd53e21 color_pass
../../gcc/ira-color.c:3309
0xd39b10 ira_traverse_loop_tree(bool, ira_loop_tree_node*, void 
(*)(ira_loop_tree_node*), void (*)(ira_loop_tree_node*))
../../gcc/ira-build.c:1781
0xd54703 do_coloring
../../gcc/ira-color.c:3460
0xd58203 color
../../gcc/ira-color.c:4837
0xd58746 ira_color()
../../gcc/ira-color.c:4968
0xd34990 ira
../../gcc/ira.c:5365
0xd35118 execute
../../gcc/ira.c:5663
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[PATCH, testsuite]: Use -mfpmath=sse in gcc.target/i386/sse4_1-round-roundeven-?.c tests

[Uros Bizjak]

Fix 32bit testing, where -mfpmath=387 is the default.

2019-08-27  Uroš Bizjak  

* gcc.target/i386/sse4_1-round-roundeven-1.c (dg-options):
Add -mfpmath=sse.
* gcc.target/i386/sse4_1-round-roundeven-2.c (dg-options): Ditto.

Tested on x86_64-linux-gnu {,-m32}.

Committed to mainline SVN.

Uros.
Index: gcc.target/i386/sse4_1-round-roundeven-1.c
===
--- gcc.target/i386/sse4_1-round-roundeven-1.c  (revision 274961)
+++ gcc.target/i386/sse4_1-round-roundeven-1.c  (working copy)
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-O2 -msse4.1" } */
+/* { dg-options "-O2 -msse4.1 -mfpmath=sse" } */
 
 __attribute__((noinline, noclone)) double
 f1 (double x)
Index: gcc.target/i386/sse4_1-round-roundeven-2.c
===
--- gcc.target/i386/sse4_1-round-roundeven-2.c  (revision 274961)
+++ gcc.target/i386/sse4_1-round-roundeven-2.c  (working copy)
@@ -1,6 +1,6 @@
 /* { dg-do run } */
 /* { dg-require-effective-target sse4 } */
-/* { dg-options "-O2 -msse4.1" } */
+/* { dg-options "-O2 -msse4.1 -mfpmath=sse" } */
 
 #include "sse4_1-check.h"
 #include "sse4_1-round-roundeven-1.c"

[Bug tree-optimization/91567] New: [10 Regression] Spurious -Wformat-overflow warnings building glibc (32-bit only)

[jsm28 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91567

Bug ID: 91567
   Summary: [10 Regression] Spurious -Wformat-overflow warnings
building glibc (32-bit only)
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jsm28 at gcc dot gnu.org
CC: msebor at gcc dot gnu.org
  Target Milestone: ---

r274933 ("PR tree-optimization/83431 - -Wformat-truncation may incorrectly
report truncation") introduced spurious -Wformat-truncation warnings on the
following code, built with -O2 -Wall, for 32-bit systems only (e.g. x86_64 -m32
or -mx32 but not -m64).  This is reduced from a build failure building glibc
for such systems with GCC trunk.

void f (char *);
void
g (char *s1, char *s2)
{
  char b[1025];
  __SIZE_TYPE__ n = __builtin_strlen (s1), d = __builtin_strlen (s2);
  if (n + d + 1 >= 1025)
return;
  __builtin_sprintf (b, "%s.%s", s1, s2);
  f (b);
}

t.c: In function 'g':
t.c:9:26: warning: '%s' directive writing up to 2147483645 bytes into a region
of size 1025 [-Wformat-overflow=]
9 |   __builtin_sprintf (b, "%s.%s", s1, s2);
  |  ^~
t.c:9:3: note: '__builtin_sprintf' output between 2 and 4294967292 bytes into a
destination of size 1025
9 |   __builtin_sprintf (b, "%s.%s", s1, s2);
  |   ^~

[Bug fortran/91566] New: [9/10 Regression] ICE in gfc_constructor_copy, at fortran/constructor.c:103

[gs...@t-online.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91566

Bug ID: 91566
   Summary: [9/10 Regression] ICE in gfc_constructor_copy, at
fortran/constructor.c:103
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Changed between 20180624 and 20180708 :


$ cat z1.f90
program p
   print *, -merge([3,4], 0, [.false.,.true.])
end


$ cat z2.f90
program p
   print *, 2 + merge([3,4], 0, [.false.,.true.])
end


$ gfortran-9-20180624 z1.f90 && ./a.out
   0  -4


$ gfortran-10-20190825 -c z1.f90
f951: internal compiler error: Segmentation fault
0xb3acef crash_signal
../../gcc/toplev.c:326
0x13f7bac splay_tree_foreach
../../libiberty/splay-tree.c:577
0x5fe5f4 gfc_constructor_copy(splay_tree_s*)
../../gcc/fortran/constructor.c:103
0x5e5cab reduce_unary
../../gcc/fortran/arith.c:1267
0x5e5ccf reduce_unary
../../gcc/fortran/arith.c:1270
0x5e651f eval_intrinsic
../../gcc/fortran/arith.c:1609
0x620307 simplify_intrinsic_op
../../gcc/fortran/expr.c:1180
0x620307 gfc_simplify_expr(gfc_expr*, int)
../../gcc/fortran/expr.c:2198
0x68d4e6 resolve_operator
../../gcc/fortran/resolve.c:4310
0x68d4e6 gfc_resolve_expr(gfc_expr*)
../../gcc/fortran/resolve.c:6944
0x684e5b gfc_resolve_code(gfc_code*, gfc_namespace*)
../../gcc/fortran/resolve.c:11416
0x694fbf gfc_resolve_blocks(gfc_code*, gfc_namespace*)
../../gcc/fortran/resolve.c:10460
0x684fe9 gfc_resolve_code(gfc_code*, gfc_namespace*)
../../gcc/fortran/resolve.c:11406
0x687ca7 resolve_codes
../../gcc/fortran/resolve.c:16921
0x687d6e gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:16956
0x67581c resolve_all_program_units
../../gcc/fortran/parse.c:6073
0x67581c gfc_parse_file()
../../gcc/fortran/parse.c:6320
0x6bf60f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug fortran/91565] New: [8/9/10 Regression] ICE in gfc_simplify_reshape, at fortran/simplify.c:6707 etc.

[gs...@t-online.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91565

Bug ID: 91565
   Summary: [8/9/10 Regression] ICE in gfc_simplify_reshape, at
fortran/simplify.c:6707 etc.
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

ICE hits gfortran-8 and higher - this changed just before 20180525.
Starting with correct code z0.f90, then providing wrong orders
(accepted up to gfortran-7) :


$ cat z0.f90
program p
   integer, parameter :: a(2) = [2,1]
   print *, reshape([1,2,3,4,5,6], [2,3], order=a)
end

$ gfortran-10 z0.f90 && ./a.out
   1   4   2   5   3   6



$ cat z1.f90   # not a permutation
program p
   integer, parameter :: a(2) = [2,2]
   print *, reshape([1,2,3,4,5,6], [2,3], order=a)
end


$ cat z2.f90   # size of order and shape differs
program p
   integer, parameter :: a(1) = 1
   print *, reshape([1,2,3,4,5,6], [2,3], order=a)
end


$ cat z3.f90   # shape of order and shape differs
program p
   integer, parameter :: a(1,2) = 1
   print *, reshape([1,2,3,4,5,6], [2,3], order=a)
end



$ gfortran-7 z3.f90 && ./a.out
   1   3   4  -1   0   0
$
$ gfortran-10-20190825 -c z1.f90
f951: internal compiler error: in gfc_simplify_reshape, at
fortran/simplify.c:6707
0x6a6a99 gfc_simplify_reshape(gfc_expr*, gfc_expr*, gfc_expr*, gfc_expr*)
../../gcc/fortran/simplify.c:6707
0x62ef5b do_simplify
../../gcc/fortran/intrinsic.c:4556
0x6395ee gfc_intrinsic_func_interface(gfc_expr*, int)
../../gcc/fortran/intrinsic.c:4931
0x6907a1 resolve_unknown_f
../../gcc/fortran/resolve.c:2896
0x6907a1 resolve_function
../../gcc/fortran/resolve.c:3233
0x68ce2d gfc_resolve_expr(gfc_expr*)
../../gcc/fortran/resolve.c:6951
0x684e5b gfc_resolve_code(gfc_code*, gfc_namespace*)
../../gcc/fortran/resolve.c:11416
0x694fbf gfc_resolve_blocks(gfc_code*, gfc_namespace*)
../../gcc/fortran/resolve.c:10460
0x684fe9 gfc_resolve_code(gfc_code*, gfc_namespace*)
../../gcc/fortran/resolve.c:11406
0x687ca7 resolve_codes
../../gcc/fortran/resolve.c:16921
0x687d6e gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:16956
0x67581c resolve_all_program_units
../../gcc/fortran/parse.c:6073
0x67581c gfc_parse_file()
../../gcc/fortran/parse.c:6320
0x6bf60f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug target/91528] [10 Regression] ICE in ix86_expand_prologue at i386.c:7844 since r274481

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91528

Uroš Bizjak  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |ubizjak at gmail dot com

--- Comment #13 from Uroš Bizjak  ---
Fixed.

[Bug target/91528] [10 Regression] ICE in ix86_expand_prologue at i386.c:7844 since r274481

[uros at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91528

--- Comment #12 from uros at gcc dot gnu.org ---
Author: uros
Date: Tue Aug 27 17:23:59 2019
New Revision: 274962

URL: https://gcc.gnu.org/viewcvs?rev=274962=gcc=rev
Log:
PR target/91528
* config/i386/i386-features.c (convert_scalars_to_vector):
Update crtl->stack_realign_needed, crtl->stack_realign_tried and
crtl->stack_realign_processed.  Update crtl->drap_reg by calling
targetm.calls.get_drap_rtx.  If drap_rtx is non-null then
Update crtl->args.internal_arg_pointer and call fixup_tail_calls.

testsuite/ChangeLog:

PR target/91528
* gcc.target/i386/pr91528.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr91528.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386-features.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/91564] New: [8/9/10 Regression] ICE in gimplify_expr, at gimplify.c:14147

[gs...@t-online.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91564

Bug ID: 91564
   Summary: [8/9/10 Regression] ICE in gimplify_expr, at
gimplify.c:14147
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affects gfortran-8 an higher, has changed before 20180525 :
(one argument more than the library-kill)


$ cat z1.f90
program p
   call kill (1, 2, 3)
end


$ gfortran-7 -c z1.f90
$
$ gfortran-10-20190825 -c z1.f90
z1.f90:2:0:

2 |call kill (1, 2, 3)
  |
internal compiler error: in gimplify_expr, at gimplify.c:14147
0x90827a gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:14147
0x9110e9 gimplify_modify_expr
../../gcc/gimplify.c:5747
0x906efd gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:13135
0x909c88 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:6779
0x907b5b gimplify_statement_list
../../gcc/gimplify.c:1849
0x907b5b gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:13579
0x909c88 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:6779
0x90a621 gimplify_bind_expr
../../gcc/gimplify.c:1417
0x907c1b gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:13336
0x909c88 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:6779
0x90a621 gimplify_bind_expr
../../gcc/gimplify.c:1417
0x907c1b gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:13336
0x909c88 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:6779
0x90b0ca gimplify_body(tree_node*, bool)
../../gcc/gimplify.c:14381
0x90b3b5 gimplify_function_tree(tree_node*)
../../gcc/gimplify.c:14525
0x7b9e37 cgraph_node::analyze()
../../gcc/cgraphunit.c:667
0x7bc7f7 analyze_functions
../../gcc/cgraphunit.c:1126
0x7bd152 symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.c:2840


$ gfortran-10-20190825-debug -c z1.f90
gimplification failed:
3  constant 3>
z1.f90:2:0:

2 |call kill (1, 2, 3)
  |
internal compiler error: gimplification failed
0x9f2a81 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:14144
0xa05658 gimplify_modify_expr
../../gcc/gimplify.c:5747
#...

Re: [PATCH V3 05/11] bpf: new GCC port

[Segher Boessenkool]

Hi!

On Tue, Aug 27, 2019 at 12:08:50PM +0100, Richard Sandiford wrote:
> Mostly trivial formatting comments, but I think there's still a couple
> of substantive points too.

Sorry to piggy-back on your review once again.

> jema...@gnu.org (Jose E. Marchesi) writes:
> > +static rtx
> > +bpf_function_value (const_tree ret_type,
> > +   const_tree fntype_or_decl ATTRIBUTE_UNUSED,
> 
> This *is* used. :-)  I only noticed because...

More modern style doesn't use ATTRIBUTE_UNUSED, it simply names the
parameter unnamed (or commented out, "const_tree /*fntype_or_decl*/").
Good luck accidentally using it, with that C++ style :-)

> > +(define_expand "zero_extendsidi2"
> > +  [(set (match_operand:DI 0 "register_operand")
> > +   (zero_extend:DI (match_operand:SI 1 "reg_or_indirect_memory_operand")))]
> > +  ""
> > +{
> > +  if (register_operand (operands[1], SImode))
> > +{
> > +  operands[1] = gen_lowpart (DImode, operands[1]);
> > +  emit_insn (gen_ashldi3 (operands[0], operands[1], GEN_INT (32)));
> > +  emit_insn (gen_lshrdi3 (operands[0], operands[0], GEN_INT (32)));
> > +  DONE;
> > +}
> > +})
> > +
> > +(define_insn "*zero_extendsidi2"
> > +  [(set (match_operand:DI 0 "register_operand" "=r,r")
> > +   (zero_extend:DI (match_operand:SI 1 "reg_or_indirect_memory_operand" 
> > "0,m")))]
> > +  ""
> > +  "@
> > +   lsh\t%0,32\n\trsh\t%0,32
> > +   ldxw\t%0,%1"
> > +  [(set_attr "type" "alu,ldx")
> > +   (set_attr "length" "16,8")])
> 
> Sorry, should have noticed last time, but: you shouldn't need to handle
> register operands here given the expander above.  It's OK if you find it
> improves code quality, but it'd be interesting to know why if so

Can't you just do "mov32 dst,src" for this?  Or "add32 dst,0" if that has
any advantages (maybe it is a shorter insn?  No idea).

So that then gets you

(define_insn "zero_extendsidi2"
  [(set (match_operand:DI 0 "register_operand" "=r,r")
(zero_extend:DI
  (match_operand:SI 1 "reg_or_indirect_memory_operand" "r,m")))]
  ""
  "@
   mov32\t%0,%1
   ldxw\t%0,%1"
  [(set_attr "type" "alu,ldx")])

(and no expander or anything).

(You still need one for the sign-extend, but only a define_expand for that,
nothing more).


Segher

Re: [PATCH V3 05/11] bpf: new GCC port

[Segher Boessenkool]

On Tue, Aug 27, 2019 at 02:59:01PM +0200, Jose E. Marchesi wrote:
> glglgl, scratch that, it is actually a 32-bit multiplication that then
> gets extended to 64-bits:
> 
> (define_insn "*mulsidi3_zeroextended"
>   [(set (match_operand:DI0 "register_operand" "=r,r")
> (zero_extend:DI
>  (mult:SI (match_operand:SI 1 "register_operand" "0,0")
>   (match_operand:SI 2 "reg_or_imm_operand" "r,I"]
>   ""
>   "mul32\t%0,%2"
>   [(set_attr "type" "alu32")])

Like pretty much *all* the 32-bit instructions, btw...  All of them could
have a variant with a zero_extend like this.  Something for define_subst,
perhaps.

On rs6000 we call such patterns "*rotlsi3_64" (where the pure 32-bit one
is called "rotlsi3"), maybe you want some similar naming?  Something that
makes it clearer that it is the same insn as mulsi3.


Segher

[Bug c++/91563] [9 regression] wrong code

[guillaume at morinfr dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91563

--- Comment #3 from Guillaume Morin  ---
Jonathan,

Are you sure? I modified the code to print std::is_trivially_copyable::value
and it does print "1". Am I missing something obvious?

[Bug c++/91563] [9 regression] wrong code

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91563

--- Comment #2 from Jakub Jelinek  ---
Just a note from bisection, stopped aborting on trunk with r273135, and started
to abort in r260318.

Re: Question about make_extraction() in combine.c

[Michael Eager]

On 8/20/19 4:07 PM, Jeff Law wrote:

On 11/20/18 4:39 PM, Michael Eager wrote:

On 11/20/2018 03:10 PM, Jeff Law wrote:

On 11/20/18 11:07 AM, Michael Eager wrote:

On 11/18/2018 08:14 AM, Jeff Law wrote:

On 11/18/18 8:44 AM, Michael Eager wrote:

On 11/16/18 14:50, Segher Boessenkool wrote:

Hi!

On Wed, Nov 14, 2018 at 11:22:58AM -0800, Michael Eager wrote:

The (mem:SI) is converted to (mem:QI).

The return from make_extract() is
   (zero_extract:SI (mem:QI (reg/v/f:SI 50 [ gp ]))
  (const_int 1 [0x1])
  (const_int 2 [0x2]))

The target has an instruction pattern for zero_extract, but it
matches
SI values, not QI.  So the instruction which implements a test of a
bit
flag is never generated.


The RTL documentation says:

  If @var{loc} is in memory, its mode must be a single-byte
integer
mode.

But obviously various ports use other modes, too.  I wonder if that
ever
worked well.


Thanks.  I hadn't noticed this.

Does anyone have any idea why there is a restriction on the mode?
Other instruction patterns don't place arbitrary restriction on the
memory access mode.

Not offhand.   BUt it's been around for a long time (at least since the
early 90s).  I stumbled over it several times through the years.  It
could well be an artifact of the m68k or the vax.


The internal RTL should not be dictating what the target arch can or
cannot implement.  Reload should insert any needed conversions,
especially ones which narrow the size.

I have a patch which removes this conversion.  Works for my target.  I
built and ran 'make check' for x86 with no additional failures.  I don't
have a VAX or M68K sitting around to test.  :-)

I can do correctness tests for m68k via qemu.  Essentially verifying it
still bootstraps:-)  Just pass along a git formatted patch and I can
throw it into the tester.


Here's the patch.  I'll edit the doc if this works for 68K.

So I'm finally coming back to this.  The test certainly bootstraps on
the m68k and various other targets.  It doesn't seem to cause any
regressions on the various targets that get tested.

I wandered the backends and uses of zero_extract with MEMs not in QImode
are actually relatively rare and not likely things that are being
exercised thoroughly.  Ironically the vax seems to have the most of
these kinds of patterns.

After re-reviewing Paulo's changes from 2006 as well as an old thread
from the gcc-2 era, I'm even more concerned than I was before WRT this
change potentially allowing a read beyond the boundary of the original
object, particularly on targets that don't require strict alignment.
That could be fatal if the object happens to be at the end of a page.

The 1992 thread I suspect is what ultimately led to the note in the
manual which limits memory operands of a zero_extract to QImode.  We
didn't have version control in those days, so I can't be 100% certain.

This kind of situation is rare, but not unheard of (I've tripped over
this kind of stuff myself).

I think we're ultimately better off fixing the target to better match
what combine is doing.


Thanks for investigating this.  It looks like you did quite a bit of 
archaeological research.


It seems to me that the only way that a read outside of the original 
object bounds is if the size is expanded.  There's code in combine.c to 
insure that does not happen.  I guess that an extv could be generated 
with incorrect operands which would be outside the object bounds, but 
that would be a bug.


I don't doubt that the QI restriction on zero_extract resolves some 
long-ago bug report, but I suspect that it hides the bug rather than 
fixes it.  It's also possible that the actual bug has been fixed, but 
the restriction has never been removed.  Without a test case, it isn't 
easy to do more than offer a conjecture.


Combine is complex, but I don't think that target descriptions should 
conform to its behaviors; combine should adapt to the target. 
(Incidentally, the target has a peephole optimization which is supposed 
to do what combine should be doing in this case.  It worked with GCC-4; 
I don't recall why I never investigated why it isn't working with GCC-8. 
 Possibly, the error occurs before peephole optimization.)


As a practical matter, the patch seems to work without problem.  (I've 
attached it here again; I'd sent it previously in an off-list email.) 
The target is not in the GCC tree, but in a separate public repo, and I 
don't believe that it will ever be upstreamed, so there's no issue with 
a future merge conflict.  My project to upgrade the target to GCC-8 was 
completed last year and I'm no longer maintaining the tool chain.


Thanks again for following up on this.


--
Michael Eagerea...@eagerm.com
1960 Park Blvd., Palo Alto, CA 94306
>From 7de0670b38c7b1cc3b805bdebe638357f384a9f8 Mon Sep 17 00:00:00 2001
From: Michael Eager 
Date: Tue, 20 Nov 2018 15:37:10 -0800
Subject: [PATCH] Eliminate narrowing of zero_extract MEM reference

Combine (make_extraction) 

[Bug c++/91563] [9 regression] wrong code

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91563

--- Comment #1 from Jonathan Wakely  ---
The program's behaviour is undefined, because memset can't be used for writing
to non-trivially copyable types.

[Bug testsuite/91562] [10 regression] gcc.dg/strlenopt-8.c fails starting with r274933

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91562

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org

--- Comment #2 from Martin Sebor  ---
Yes, I must have missed updating the name of the dump.  It should be strlen1.

[Bug c++/83431] -Wformat-truncation may incorrectly report truncation

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83431

--- Comment #8 from Martin Sebor  ---
Author: msebor
Date: Tue Aug 27 16:18:27 2019
New Revision: 274961

URL: https://gcc.gnu.org/viewcvs?rev=274961=gcc=rev
Log:
gcc/testsuite/ChangeLog:

PR c++/83431
PR testsuite/91562
* gcc.dg/strlenopt-8.c: Adjust pass/dump name.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/strlenopt-8.c

[Bug testsuite/91562] [10 regression] gcc.dg/strlenopt-8.c fails starting with r274933

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91562

--- Comment #1 from Martin Sebor  ---
Author: msebor
Date: Tue Aug 27 16:18:27 2019
New Revision: 274961

URL: https://gcc.gnu.org/viewcvs?rev=274961=gcc=rev
Log:
gcc/testsuite/ChangeLog:

PR c++/83431
PR testsuite/91562
* gcc.dg/strlenopt-8.c: Adjust pass/dump name.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/strlenopt-8.c

[Bug fortran/91556] Problems with better interface checking

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91556

Thomas Koenig  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-08-27
   Assignee|unassigned at gcc dot gnu.org  |tkoenig at gcc dot 
gnu.org
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #9 from Thomas Koenig  ---
After r274937, the new flag -fallow-argument-mismatch can also be used.

Now, I agree that the error message can be improved - the _formal_...
argument names can be improved, it would probably a better idea
to refer to the place that the declaration came from in that case.

I'll do this, but it will probably be a couple of weeks until I can
come up with something - too many things happening in Real Life (TM)
at the moment.

Re: [PATCH V3 05/11] bpf: new GCC port

[Jose E. Marchesi]

> +(define_expand "zero_extendsidi2"
> +  [(set (match_operand:DI 0 "register_operand")
> + (zero_extend:DI (match_operand:SI 1 "reg_or_indirect_memory_operand")))]
> +  ""
> +{
> +  if (register_operand (operands[1], SImode))
> +{
> +  operands[1] = gen_lowpart (DImode, operands[1]);
> +  emit_insn (gen_ashldi3 (operands[0], operands[1], GEN_INT (32)));
> +  emit_insn (gen_lshrdi3 (operands[0], operands[0], GEN_INT (32)));
> +  DONE;
> +}
> +})
> +
> +(define_insn "*zero_extendsidi2"
> +  [(set (match_operand:DI 0 "register_operand" "=r,r")
> + (zero_extend:DI (match_operand:SI 1 "reg_or_indirect_memory_operand" 
"0,m")))]
> +  ""
> +  "@
> +   lsh\t%0,32\n\trsh\t%0,32
> +   ldxw\t%0,%1"
> +  [(set_attr "type" "alu,ldx")
> +   (set_attr "length" "16,8")])

Sorry, should have noticed last time, but: you shouldn't need to handle
register operands here given the expander above.  It's OK if you find it
improves code quality, but it'd be interesting to know why if so

If I remove the 0,=r alternative from the insn above, and also adjust
the predicate to indirect_memory_operand, then I get a segfault in one
test, in update_costs_from_allocno (ira-color.c:1382), because:

(gdb) print mode
$1 = E_SImode
(gdb) print default_target_ira_int->x_ira_register_move_cost[mode]
$13 = (move_table *) 0x0

What I think is going on is:

1. The expand above is used, and

2. there is no insn in the program matched by a pattern that involves a
   SI operand, and therefore record_operand_costs is never called on
   SImode operand, and therefore the lazily-initialized
   x_ira_register_move_cost is never filled in for E_SImode, and then

3. ira() -> ira_color() -> color () -> do_coloring () ->
   ira_traverse_loop_tree () -> color_pass () -> color_allocnos () ->
   update_costs_from_prefs () -> update_costs_from_allocno () *CRASH*

Is this a bug, or am I expected to somehow trigger the initialization of
the SImode entry in the ira register move table in some other way?

> +
> +;;; Sign-extension
> +
> +;; Sign-extending a 32-bit value into a 64-bit value is achieved using
> +;; shifting, with instructions generated by the expand below.
> +
> +(define_expand "extendsidi2"
> +  [(set (match_operand:DI 0 "register_operand")
> + (sign_extend:DI (match_operand:SI 1 "register_operand")))]
> +  ""
> +{
> +  operands[1] = gen_lowpart (DImode, operands[1]);
> +  emit_insn (gen_ashldi3 (operands[0], operands[1], GEN_INT (32)));
> +  emit_insn (gen_ashrdi3 (operands[0], operands[0], GEN_INT (32)));
> +  DONE;
> +})
> +
> +(define_insn "*extendsidi2"
> +  [(set (match_operand:DI 0 "register_operand" "=r")
> + (sign_extend:DI (match_operand:SI 1 "register_operand" "0")))]
> +  ""
> +  "lsh\t%0,32\n\tarsh\t%0,32"
> +  [(set_attr "type" "alu")
> +   (set_attr "length" "16")])

Likewise this define_insn shouldn't be needed.

The removal of this one doesn't trigger any problem that I can see
running compile.exp.  I'm glad to get rid of yet another insn! :)

Re: [SVE] PR86753

[Richard Sandiford]

Richard should have the final say, but some comments...

Prathamesh Kulkarni  writes:
> diff --git a/gcc/tree-vect-stmts.c b/gcc/tree-vect-stmts.c
> index 1e2dfe5d22d..862206b3256 100644
> --- a/gcc/tree-vect-stmts.c
> +++ b/gcc/tree-vect-stmts.c
> @@ -1989,17 +1989,31 @@ check_load_store_masking (loop_vec_info loop_vinfo, 
> tree vectype,
>  
>  static tree
>  prepare_load_store_mask (tree mask_type, tree loop_mask, tree vec_mask,
> -  gimple_stmt_iterator *gsi)
> +  gimple_stmt_iterator *gsi, tree mask,
> +  cond_vmask_map_type *cond_to_vec_mask)

"scalar_mask" might be a better name.  But maybe we should key off the
vector mask after all, now that we're relying on the code having no
redundancies.

Passing the vinfo would be better than passing the cond_vmask_map_type
directly.

>  {
>gcc_assert (useless_type_conversion_p (mask_type, TREE_TYPE (vec_mask)));
>if (!loop_mask)
>  return vec_mask;
>  
>gcc_assert (TREE_TYPE (loop_mask) == mask_type);
> +
> +  tree *slot = 0;
> +  if (cond_to_vec_mask)

The pointer should never be null in this context.

> +{
> +  cond_vmask_key cond (mask, loop_mask);
> +  slot = _to_vec_mask->get_or_insert (cond);
> +  if (*slot)
> + return *slot;
> +}
> +
>tree and_res = make_temp_ssa_name (mask_type, NULL, "vec_mask_and");
>gimple *and_stmt = gimple_build_assign (and_res, BIT_AND_EXPR,
> vec_mask, loop_mask);
>gsi_insert_before (gsi, and_stmt, GSI_SAME_STMT);
> +
> +  if (slot)
> +*slot = and_res;
>return and_res;
>  }
> [...]
> @@ -9975,6 +9997,38 @@ vectorizable_condition (stmt_vec_info stmt_info, 
> gimple_stmt_iterator *gsi,
>/* Handle cond expr.  */
>for (j = 0; j < ncopies; j++)
>  {
> +  tree vec_mask = NULL_TREE;
> +
> +  if (loop_vinfo && LOOP_VINFO_FULLY_MASKED_P (loop_vinfo)

Nit: one condition per line when the whole thing doesn't fit on a single line.

> +   && TREE_CODE_CLASS (TREE_CODE (cond_expr)) == tcc_comparison

Why restrict this to embedded comparisons?  It should work for separate
comparisons too.

> +   && loop_vinfo->cond_to_vec_mask)

This should always be nonnull given the above.

> + {
> +   vec_loop_masks *masks = _VINFO_MASKS (loop_vinfo);
> +   if (masks)

This is never null.

> + {
> +   tree loop_mask = vect_get_loop_mask (gsi, masks,
> +ncopies, vectype, j);
> +
> +   cond_vmask_key cond (cond_expr, loop_mask);
> +   tree *slot = loop_vinfo->cond_to_vec_mask->get (cond);
> +   if (slot && *slot)
> + vec_mask = *slot;
> +   else
> + {
> +   cond.cond_ops.code
> + = invert_tree_comparison (cond.cond_ops.code, true);
> +   slot = loop_vinfo->cond_to_vec_mask->get (cond);
> +   if (slot && *slot)
> + {
> +   vec_mask = *slot;
> +   tree tmp = then_clause;
> +   then_clause = else_clause;
> +   else_clause = tmp;

Can use std::swap.

> + }
> + }
> + }
> + }
> +
>stmt_vec_info new_stmt_info = NULL;
>if (j == 0)
>   {
> @@ -10054,6 +10108,8 @@ vectorizable_condition (stmt_vec_info stmt_info, 
> gimple_stmt_iterator *gsi,
>  
> if (masked)
>   vec_compare = vec_cond_lhs;
> +   else if (vec_mask)
> + vec_compare = vec_mask;

If we do drop the comparison check above, this should win over "masked".

> @@ -193,6 +194,81 @@ public:
>poly_uint64 min_value;
>  };
>  
> +struct cond_vmask_key

I'm no good at naming things, but since "vmask" doesn't occur elsewhere
in target-independent code, how about "vec_masked_cond_key"?

> +{
> +  cond_vmask_key (tree t, tree loop_mask_)
> +: cond_ops (t), loop_mask (loop_mask_)
> +  {}
> +
> +  hashval_t hash () const
> +  {
> +inchash::hash h;
> +h.add_int (cond_ops.code);
> +h.add_int (TREE_HASH (cond_ops.op0));
> +h.add_int (TREE_HASH (cond_ops.op1));

These two need to use inchash::add_expr, since you're hashing for
operand_equal_p.

> +h.add_int (TREE_HASH (loop_mask));
> +return h.end ();
> +  }
> +
> +  void mark_empty ()
> +  {
> +loop_mask = NULL_TREE;
> +  }
> +
> +  bool is_empty ()
> +  {
> +return loop_mask == NULL_TREE;
> +  }
> +
> +  tree_cond_ops cond_ops;
> +  tree loop_mask;
> +};
> +
> +inline bool operator== (const cond_vmask_key& c1, const cond_vmask_key& c2)
> +{
> +  return c1.loop_mask == c2.loop_mask
> +  && c1.cond_ops == c2.cond_ops;

Multi-line expressions should be in brackets (or just put this one on
a single line).

> +}
> +
> +struct cond_vmask_key_traits

Might as well make this:

template<>
struct default_hash_traits

and then you can drop the third template parameter from hash_map.

> +{
> +  typedef 

Re: [PATCH] integrate sprintf pass into strlen (PR 83431)

[Martin Sebor]

On 8/27/19 3:09 AM, Christophe Lyon wrote:

On Fri, 23 Aug 2019 at 04:14, Jeff Law  wrote:


On 8/12/19 4:09 PM, Martin Sebor wrote:



gcc-83431.diff

PR tree-optimization/83431 - -Wformat-truncation may incorrectly report 
truncation

gcc/ChangeLog:

   PR c++/83431
   * gimple-ssa-sprintf.c (pass_data_sprintf_length): Remove object.
   (sprintf_dom_walker): Remove class.
   (get_int_range): Make argument const.
   (directive::fmtfunc, directive::set_precision): Same.
   (format_none): Same.
   (build_intmax_type_nodes): Same.
   (adjust_range_for_overflow): Same.
   (format_floating): Same.
   (format_character): Same.
   (format_string): Same.
   (format_plain): Same.
   (get_int_range): Cast away constness.
   (format_integer): Same.
   (get_string_length): Call get_range_strlen_dynamic.  Handle
   null lendata.maxbound.
   (should_warn_p): Adjust argument scope qualifier.
   (maybe_warn): Same.
   (format_directive): Same.
   (parse_directive): Same.
   (is_call_safe): Same.
   (try_substitute_return_value): Same.
   (sprintf_dom_walker::handle_printf_call): Rename...
   (handle_printf_call): ...to this.  Initialize target to host charmap
   here instead of in pass_sprintf_length::execute.
   (struct call_info): Make global.
   (sprintf_dom_walker::compute_format_length): Make global.
   (sprintf_dom_walker::handle_gimple_call): Same.
   * passes.def (pass_sprintf_length): Replace with pass_strlen.
   * print-rtl.c (print_pattern): Reduce the number of spaces to
   avoid -Wformat-truncation.
   * tree-pass.h (make_pass_warn_printf): New function.
   * tree-ssa-strlen.c (strlen_optimize): New variable.
   (get_string_length): Add comments.
   (get_range_strlen_dynamic): New function.
   (check_and_optimize_call): New function.
   (handle_integral_assign): New function.
   (strlen_check_and_optimize_stmt): Factor code out into
   strlen_check_and_optimize_call and handle_integral_assign.
   (strlen_dom_walker::evrp): New member.
   (strlen_dom_walker::before_dom_children): Use evrp member.
   (strlen_dom_walker::after_dom_children): Use evrp member.
   (printf_strlen_execute): New function.
   (pass_strlen::gate): Update to handle printf calls.
   (dump_strlen_info): New function.
   (pass_data_warn_printf): New variable.
   (pass_warn_printf): New class.
   * tree-ssa-strlen.h (get_range_strlen_dynamic): Declare.
   (handle_printf_call): Same.

gcc/testsuite/ChangeLog:

   PR c++/83431
   * gcc.dg/strlenopt-63.c: New test.
   * gcc.dg/pr79538.c: Adjust text of expected warning.
   * gcc.dg/pr81292-1.c: Adjust pass name.
   * gcc.dg/pr81292-2.c: Same.
   * gcc.dg/pr81703.c: Same.
   * gcc.dg/strcmpopt_2.c: Same.
   * gcc.dg/strcmpopt_3.c: Same.
   * gcc.dg/strcmpopt_4.c: Same.
   * gcc.dg/strlenopt-1.c: Same.
   * gcc.dg/strlenopt-10.c: Same.
   * gcc.dg/strlenopt-11.c: Same.
   * gcc.dg/strlenopt-13.c: Same.
   * gcc.dg/strlenopt-14g.c: Same.
   * gcc.dg/strlenopt-14gf.c: Same.
   * gcc.dg/strlenopt-15.c: Same.
   * gcc.dg/strlenopt-16g.c: Same.
   * gcc.dg/strlenopt-17g.c: Same.
   * gcc.dg/strlenopt-18g.c: Same.
   * gcc.dg/strlenopt-19.c: Same.
   * gcc.dg/strlenopt-1f.c: Same.
   * gcc.dg/strlenopt-2.c: Same.
   * gcc.dg/strlenopt-20.c: Same.
   * gcc.dg/strlenopt-21.c: Same.
   * gcc.dg/strlenopt-22.c: Same.
   * gcc.dg/strlenopt-22g.c: Same.
   * gcc.dg/strlenopt-24.c: Same.
   * gcc.dg/strlenopt-25.c: Same.
   * gcc.dg/strlenopt-26.c: Same.
   * gcc.dg/strlenopt-27.c: Same.
   * gcc.dg/strlenopt-28.c: Same.
   * gcc.dg/strlenopt-29.c: Same.
   * gcc.dg/strlenopt-2f.c: Same.
   * gcc.dg/strlenopt-3.c: Same.
   * gcc.dg/strlenopt-30.c: Same.
   * gcc.dg/strlenopt-31g.c: Same.
   * gcc.dg/strlenopt-32.c: Same.
   * gcc.dg/strlenopt-33.c: Same.
   * gcc.dg/strlenopt-33g.c: Same.
   * gcc.dg/strlenopt-34.c: Same.
   * gcc.dg/strlenopt-35.c: Same.
   * gcc.dg/strlenopt-4.c: Same.
   * gcc.dg/strlenopt-48.c: Same.
   * gcc.dg/strlenopt-49.c: Same.
   * gcc.dg/strlenopt-4g.c: Same.
   * gcc.dg/strlenopt-4gf.c: Same.
   * gcc.dg/strlenopt-5.c: Same.
   * gcc.dg/strlenopt-50.c: Same.
   * gcc.dg/strlenopt-51.c: Same.
   * gcc.dg/strlenopt-52.c: Same.
   * gcc.dg/strlenopt-53.c: Same.
   * gcc.dg/strlenopt-54.c: Same.
   * gcc.dg/strlenopt-55.c: Same.
   * gcc.dg/strlenopt-56.c: Same.
   * gcc.dg/strlenopt-6.c: Same.
   * gcc.dg/strlenopt-61.c: Same.
   * gcc.dg/strlenopt-7.c: Same.
   * gcc.dg/strlenopt-8.c: Same.
   * gcc.dg/strlenopt-9.c: Same.
   * gcc.dg/strlenopt.h (snprintf, snprintf): Declare.
   * gcc.dg/tree-ssa/builtin-snprintf-6.c: New test.
   * 

[Bug c++/91563] New: [9 regression] wrong code

[guillaume at morinfr dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91563

Bug ID: 91563
   Summary: [9 regression] wrong code
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: guillaume at morinfr dot org
  Target Milestone: ---

Created attachment 46766
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46766=edit
test program

Hi,

The attached program aborts with gcc 9.x -O{1,2,3} (including recent version of
the Debian package which has picked recent fixes to the gcc 9 branch). Adding
-fno-strict-aliasing does not make any difference. Full example is uploaded at
https://godbolt.org/z/We99i_

It seems to work correctly with gcc 8.x and the gcc trunk on goldbot.org.

Thank you.

[Bug c++/91506] Incorrectly issued error: parameter may not have variably modified type

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91506

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-08-27
 Ever confirmed|0   |1

[Bug libstdc++/91558] [C++11] should not be constexpr until C++14

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91558

--- Comment #4 from Jonathan Wakely  ---
(In reply to Yichen Yan from comment #3)
> (In reply to Jonathan Wakely from comment #1)
> > (In reply to Yichen Yan from comment #0)
> > > Detail: 
> > > Constexpr for  is in C++14 if I don't misunderstand. But a lot of
> > > testcases under libstdc++-v3/testsuite/26_numerics/complex/ (e.g. 
> > > dr844.cc)
> > 
> > Are you sure? That test doesn't seem to care about constexpr.
> 
> Yes, check_ret_type require its template argument and argument to be
> constexpr.

No it doesn't:

  template
typename __gnu_cxx::__enable_if::__value,
bool>::__type
check_ret_type(T)
{ return true; }

[Bug testsuite/91562] New: [10 regression] gcc.dg/strlenopt-8.c fails starting with r274933

[seurer at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91562

Bug ID: 91562
   Summary: [10 regression] gcc.dg/strlenopt-8.c fails starting
with r274933
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

Did this test case get missed when the others were updated?

Executing on host: /home/seurer/gcc/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test/gcc/
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/strlenopt-8.c   
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never   -O2 -fdump-tree-strlen  -lm  -o ./strlenopt-8.exe  
 (timeout = 300)
spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test/gcc/
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/strlenopt-8.c
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -O2 -fdump-tree-strlen -lm -o ./strlenopt-8.exe
PASS: gcc.dg/strlenopt-8.c (test for excess errors)
Setting LD_LIBRARY_PATH to
:/home/seurer/gcc/build/gcc-test/gcc::/home/seurer/gcc/build/gcc-test/gcc:/home/seurer/gcc/build/gcc-test/./gmp/.libs:/home/seurer/gcc/build/gcc-test/./prev-gmp/.libs:/home/seurer/gcc/build/gcc-test/./mpfr/src/.libs:/home/seurer/gcc/build/gcc-test/./prev-mpfr/src/.libs:/home/seurer/gcc/build/gcc-test/./mpc/src/.libs:/home/seurer/gcc/build/gcc-test/./prev-mpc/src/.libs:/home/seurer/gcc/build/gcc-test/./isl/.libs:/home/seurer/gcc/build/gcc-test/./prev-isl/.libs:/home/seurer/gcc/install/gcc-7.2.0/lib64
Execution timeout is: 300
spawn [open ...]
PASS: gcc.dg/strlenopt-8.c execution test
gcc.dg/strlenopt-8.c: dump file does not exist
UNRESOLVED: gcc.dg/strlenopt-8.c scan-tree-dump-times strlen "strlen \\(" 0
gcc.dg/strlenopt-8.c: dump file does not exist
UNRESOLVED: gcc.dg/strlenopt-8.c scan-tree-dump-times strlen "strcpy \\(" 0
gcc.dg/strlenopt-8.c: dump file does not exist
UNRESOLVED: gcc.dg/strlenopt-8.c scan-tree-dump-times strlen "strcat \\(" 0
gcc.dg/strlenopt-8.c: dump file does not exist
UNRESOLVED: gcc.dg/strlenopt-8.c scan-tree-dump-times strlen "strchr \\(" 0
gcc.dg/strlenopt-8.c: dump file does not exist
UNRESOLVED: gcc.dg/strlenopt-8.c scan-tree-dump-times strlen "stpcpy \\(" 0
testcase /home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/dg.exp completed in 0
seconds

=== gcc Summary ===

# of expected passes2
# of unresolved testcases   5

Re: Rust front-end

[David Malcolm]

On Fri, 2019-08-23 at 11:10 -0300, Mateus Carmo Martins de Freitas
Barbosa wrote:
> I'm interested in working on the Rust front-end for GCC.
> 
> So far I've cloned the repository  git>
> and tried to compile it as described in  tFrontEnd>.
> I've compiled it outside of the gcc directory tree with
> 
> $ ../gccrs/configure --prefix=/opt/gccrs --enable-languages=rust
> --disable-multilib --disable-bootstrap
> $ make
> 
> 
> But this produces some linking errors for functions that were called
> but never defined:
> 
> 
> /usr/bin/ld: rust/rust-lang.o: in function
> `rust_langhook_handle_option(unsigned long, char const*, long, int,
> unsigned int, cl_option_handlers const*)':
> /home/baal/gccrs-build/gcc/../../gccrs/gcc/rust/rust-lang.c:185:
> undefined reference to `rust_add_search_path(char const*)'
> /usr/bin/ld: /home/baal/gccrs-build/gcc/../../gccrs/gcc/rust/rust-
> lang.c:213:
> undefined reference to `rust_add_search_path(char const*)'
> /usr/bin/ld: /home/baal/gccrs-build/gcc/../../gccrs/gcc/rust/rust-
> lang.c:217:
> undefined reference to `rust_add_search_path(char const*)'
> /usr/bin/ld: rust/rust-lang.o: in function
> `rust_langhook_post_options':
> /home/baal/gccrs-build/gcc/../../gccrs/gcc/rust/rust-lang.c:245:
> undefined reference to `rust_add_search_path(char const*)'
> /usr/bin/ld: rust/rust-lang.o: in function
> `rust_langhook_parse_file()':
> /home/baal/gccrs-build/gcc/../../gccrs/gcc/rust/rust-lang.c:282:
> undefined reference to `rust_parse_input_files(char const**, unsigned
> int, bool)'
> /usr/bin/ld: rust/rust-lang.o:/home/baal/gccrs-build/gcc/./gtype-
> rust.h:24:
> undefined reference to `rust_non_zero_struct'
> collect2: error: ld returned 1 exit status
> make[2]: *** [../../gccrs/gcc/rust/Make-lang.in:61: rust1] Error 1
> make[2]: Leaving directory '/home/baal/gccrs-build/gcc'
> make[1]: *** [Makefile:4319: all-gcc] Error 2
> 
> 
> It's doesn't really help that the latest commit message
> (3b1e76d808b9725e6ef439ae534011370e65fb85) says simply "x" and the
> previous one, only "more". Anyhow, I'm left with those questions:
> 
> - Considering I'm new to gcc development, what should I read before
> getting into this?
> - Is there any developer in particular I should talk to?

As far as I can tell, this is a side-project by one gcc developer
("redbrain" aka Philip Herron), who appears to only work on it
intermittently.  It may not be the best start for someone new to gcc
development.

I've CCed him on this email (hi Philip!) as I suspect he hasn't seen
this thread (or might be on vacation).

> - Is there anything else I need to know before getting started?

FWIW, I'm not convinced that a rust frontend to gcc is the best
approach - Rust has some complicated semantic-checking rules that must
be implemented by a compiler (the "borrow checker").  Hopefully that
code is available via a library.

One approach would be something like how the GCC Go frontend works,
which uses a library shared with the other Go compiler implementation
to parse the code, and turn it into GCC's IR, which then goes through
GCC's optimizer and backend.

Another approach would be to build a gcc-based backend to the existing
rust compiler, as an alternative to its LLVM-based backend, rather than
a rust frontend to gcc.  libgccjit (despite its name) has the ability
to generate ahead-of-time code (e.g. .o files), and has rust bindings,
and thus could be embedded inside rustc - in theory, at least.  I'm the
maintainer of libgccjit.  See this discussion:

https://users.rust-lang.org/t/rust-front-end-to-gcc/11601

Although I'm a fan of Rust, I'm deep in the middle of another gcc-
related project, and I don't have cycles to spare to work on this
(beyond answering libgccjit questions).

Hope this is helpful and constructive
Dave

Re: [PATCH] Remove code leftover that has never been used.

[Martin Sebor]

On 8/27/19 8:04 AM, Martin Liška wrote:

Hi.

I would like to remove the leftover that hasn't been used since
when it was introduced.

Ready for trunk?


It's fine with me, thank you.

Martin

Re: [SVE] PR86753

[Prathamesh Kulkarni]

On Tue, 27 Aug 2019 at 17:29, Richard Sandiford
 wrote:
>
> Richard Biener  writes:
> > On Tue, Aug 27, 2019 at 11:58 AM Richard Sandiford
> >  wrote:
> >> ifcvt produces:
> >>
> >>[local count: 1063004407]:
> >>   # i_34 = PHI 
> >>   # ivtmp_5 = PHI 
> >>   _1 = (long unsigned int) i_34;
> >>   _2 = _1 * 2;
> >>   _3 = a_23(D) + _2;
> >>   _4 = *_3;
> >>   _7 = b_24(D) + _2;
> >>   _49 = _4 > 0;
> >>   _8 = .MASK_LOAD (_7, 16B, _49);
> >>   _12 = _4 > 0;
> >>   _13 = _8 > 0;
> >>   _9 = _12 & _13;
> >>   _10 = _4 > 0;
> >>   _11 = _8 > 0;
> >>   _27 = ~_11;
> >>   _15 = _10 & _27;
> >>   _14 = c_25(D) + _2;
> >>   iftmp.0_26 = .MASK_LOAD (_14, 16B, _15);
> >>   iftmp.0_19 = _9 ? _4 : iftmp.0_26;
> >>   _17 = x_28(D) + _2;
> >>   _50 = _4 > 0;
> >>   .MASK_STORE (_17, 16B, _50, iftmp.0_19);
> >>   i_30 = i_34 + 1;
> >>   ivtmp_6 = ivtmp_5 - 1;
> >>   if (ivtmp_6 != 0)
> >> goto ; [98.99%]
> >>   else
> >> goto ; [1.01%]
> >>
> >>[local count: 1052266994]:
> >>   goto ; [100.00%]
> >>
> >> which has 4 copies of _4 > 0 (a[i] > 0) and 2 copies of _8 > 0 (b[i] > 0).
> >
> > Huh.  if-conversion does
> >
> >   /* Now all statements are if-convertible.  Combine all the basic
> >  blocks into one huge basic block doing the if-conversion
> >  on-the-fly.  */
> >   combine_blocks (loop);
> >
> >   /* Delete dead predicate computations.  */
> >   ifcvt_local_dce (loop->header);
> >
> >   /* Perform local CSE, this esp. helps the vectorizer analysis if loads
> >  and stores are involved.  CSE only the loop body, not the entry
> >  PHIs, those are to be kept in sync with the non-if-converted copy.
> >  ???  We'll still keep dead stores though.  */
> >   exit_bbs = BITMAP_ALLOC (NULL);
> >   bitmap_set_bit (exit_bbs, single_exit (loop)->dest->index);
> >   bitmap_set_bit (exit_bbs, loop->latch->index);
> >   todo |= do_rpo_vn (cfun, loop_preheader_edge (loop), exit_bbs);
> >
> > which should remove those redundant _4 > 0 checks.  In fact when I
> > run this on x86_64 with -mavx512bw I see
> >
> >[local count: 1063004407]:
> >   # i_25 = PHI 
> >   # ivtmp_24 = PHI 
> >   _1 = (long unsigned int) i_25;
> >   _2 = _1 * 2;
> >   _3 = a_14(D) + _2;
> >   _4 = *_3;
> >   _5 = b_15(D) + _2;
> >   _49 = _4 > 0;
> >   _6 = .MASK_LOAD (_5, 16B, _49);
> >   _22 = _6 > 0;
> >   _28 = ~_22;
> >   _29 = _28 & _49;
> >   _7 = c_16(D) + _2;
> >   iftmp.0_17 = .MASK_LOAD (_7, 16B, _29);
> >   iftmp.0_10 = _29 ? iftmp.0_17 : _4;
> >   _8 = x_18(D) + _2;
> >   .MASK_STORE (_8, 16B, _49, iftmp.0_10);
> >   i_20 = i_25 + 1;
> >   ivtmp_12 = ivtmp_24 - 1;
> >   if (ivtmp_12 != 0)
> >
> > after if-conversion (that should be the case already on the GCC 9 branch).
>
> Gah, sorry for the noise.  Turns out I still had a local change that was
> trying to poke the patch into doing something wrong.  Will try to check
> my facts more carefully next time.
>
> The redundant pattern statements I was thinking of come from
> vect_recog_mask_conversion_pattern, but I guess that isn't so
> interesting here.
>
> So yeah, let's drop this whole vn thing for now...
The attached version drops VN, and uses operand_equal_p for comparison.
Does it look OK ?

Thanks,
Prathamesh
>
> Thanks,
> Richard
diff --git a/gcc/testsuite/gcc.target/aarch64/sve/fmla_2.c b/gcc/testsuite/gcc.target/aarch64/sve/fmla_2.c
index 5c04bcdb3f5..a1b0667dab5 100644
--- a/gcc/testsuite/gcc.target/aarch64/sve/fmla_2.c
+++ b/gcc/testsuite/gcc.target/aarch64/sve/fmla_2.c
@@ -15,5 +15,9 @@ f (double *restrict a, double *restrict b, double *restrict c,
 }
 }
 
-/* { dg-final { scan-assembler-times {\tfmla\tz[0-9]+\.d, p[0-7]/m, z[0-9]+\.d, z[0-9]+\.d\n} 2 } } */
+/* See https://gcc.gnu.org/ml/gcc-patches/2019-08/msg01644.html
+   for XFAILing the below test.  */
+
+/* { dg-final { scan-assembler-times {\tfmla\tz[0-9]+\.d, p[0-7]/m, z[0-9]+\.d, z[0-9]+\.d\n} 2 { xfail *-*-* } } } */
+/* { dg-final { scan-assembler-times {\tfmla\tz[0-9]+\.d, p[0-7]/m, z[0-9]+\.d, z[0-9]+\.d\n} 3 } } */
 /* { dg-final { scan-assembler-not {\tfmad\t} } } */
diff --git a/gcc/tree-vect-loop.c b/gcc/tree-vect-loop.c
index b0cbbac0cb5..0fc7171d7ea 100644
--- a/gcc/tree-vect-loop.c
+++ b/gcc/tree-vect-loop.c
@@ -8609,6 +8609,9 @@ vect_transform_loop (loop_vec_info loop_vinfo)
   basic_block bb = bbs[i];
   stmt_vec_info stmt_info;
 
+  if (LOOP_VINFO_FULLY_MASKED_P (loop_vinfo))
+	loop_vinfo->cond_to_vec_mask = new cond_vmask_map_type (8);
+
   for (gphi_iterator si = gsi_start_phis (bb); !gsi_end_p (si);
 	   gsi_next ())
 {
@@ -8717,6 +8720,12 @@ vect_transform_loop (loop_vec_info loop_vinfo)
 		}
 	}
 	}
+
+  if (loop_vinfo->cond_to_vec_mask)
+	{
+	  delete loop_vinfo->cond_to_vec_mask;
+	  loop_vinfo->cond_to_vec_mask = 0;
+	}
 }/* BBs in loop */
 
   /* The vectorization factor is always > 1, so if we use an IV increment of 1.
diff --git a/gcc/tree-vect-stmts.c b/gcc/tree-vect-stmts.c
index 1e2dfe5d22d..862206b3256 100644
--- 

[Bug c++/91222] [10 Regression] 507.cactuBSSN_r build fails in warn_types_mismatch at ipa-devirt.c:1006 since r273571

[hubicka at ucw dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91222

--- Comment #12 from Jan Hubicka  ---
> Created attachment 46765
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46765=edit
> clear TYPE_NAME in free_lang_data for anonymous types
> 
> Perhaps like this?

It seems that this will disable ODR handling of all anonymous types, not
only those declared as "extern C".  We make use of the info (by mangling
them to ) to handle them during devirtualization and also TBAA. So
perhaps we want to be more specific here?

Honza

[Bug c++/91222] [10 Regression] 507.cactuBSSN_r build fails in warn_types_mismatch at ipa-devirt.c:1006 since r273571

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91222

--- Comment #11 from Jason Merrill  ---
Created attachment 46765
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46765=edit
clear TYPE_NAME in free_lang_data for anonymous types

Perhaps like this?

[Bug target/88082] ICE in change_address_1, at emit-rtl.c:2286

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88082

Martin Liška  changed:

   What|Removed |Added

   Keywords||needs-bisection
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-08-27
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Liška  ---
You're right, let me bisect that first.

libgo patch committed: Rebuild runtime.inc if mkruntimeinc.sh changes

[Ian Lance Taylor]

This libgo patch rebuilds runtime.inc if mkruntimeinc.sh changes.  The
Makefile was missing a dependency.  Also remove runtime.inc.raw in
mostlyclean.  Bootstrapped on x86_64-pc-linux-gnu.  Committed to
mainline.

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 274935)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-58c0fc64d91edc53ef9828b85cf3dc86aeb94e12
+a6ddd0e1208a7d229c10be630c1110b3914038f5
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: libgo/Makefile.am
===
--- libgo/Makefile.am   (revision 274169)
+++ libgo/Makefile.am   (working copy)
@@ -612,7 +612,7 @@ s-zdefaultcc: Makefile
 # compiling runtime) to prune out certain types that should not be
 # exported back to C. See comments in mkruntimeinc.sh for more details.
 runtime.inc: s-runtime-inc; @true
-s-runtime-inc: runtime.lo Makefile
+s-runtime-inc: runtime.lo mkruntimeinc.sh Makefile
$(SHELL) $(srcdir)/mkruntimeinc.sh
$(SHELL) $(srcdir)/mvifdiff.sh tmp-runtime.inc runtime.inc
$(STAMP) $@
@@ -1205,7 +1205,8 @@ MOSTLYCLEANFILES = \
s-libcalls s-libcalls-list s-syscall_arch s-gen-sysinfo s-sysinfo \
s-errno s-epoll \
libgo.head libgo.sum.sep libgo.log.sep libgo.var \
-   libcalls-list runtime.inc runtime.inc.tmp2 runtime.inc.tmp3
+   libcalls-list \
+   runtime.inc runtime.inc.tmp2 runtime.inc.tmp3 runtime.inc.raw
 
 mostlyclean-local:
find . -name '*.lo' -print | xargs $(LIBTOOL) --mode=clean rm -f

[Bug d/91561] New: [Regression] Internal Compiler Error: type ‘ubyte[]’ can not be mapped to C++

[bugzilla at allegrodvt dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91561

Bug ID: 91561
   Summary: [Regression] Internal Compiler Error: type ‘ubyte[]’
can not be mapped to C++
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: bugzilla at allegrodvt dot com
  Target Milestone: ---

The following code compiles on gdc-8.2 but failed on gdc-9.2:
--
extern(C++) :
alias ubyte[] Array;

class Interface
{
  abstract void getArray(ref Array a);
}

void main()
{
}
---

The error is:
error: Internal Compiler Error: type ‘ubyte[]’ can not be mapped to C++
6 |   abstract void getArray(ref Array a);
  | ^