Re: [PATCH] PR fortran/78719 -- Check for a CLASS

[Janne Blomqvist]

On Sat, Aug 17, 2019 at 4:00 AM Steve Kargl
 wrote:
>
> Regression tested on x86_64-*-freebsd.  OK to commit?
>
> When checking to see in attrbutes are being added to
> an entity that alrady has an explcit interface, gfortran
> failed to consider the case of CLASS.  The attach patch
> corrects this omission.  See the 3 testcases for clarity.
>
> 2019-08-16  Steven G. Kargl  
>
> PR fortran/78719
> * decl.c (get_proc_name): Check for a CLASS entity when trying to
> add attributes to an entity that already has an explicit interface.
>
> 2019-08-16  Steven G. Kargl  
>
> PR fortran/78719
> * gfortran.dg/pr78719_1.f90: New test.
> * gfortran.dg/pr78719_2.f90: Ditto.
> * gfortran.dg/pr78719_3.f90: Ditto.

Ok, thanks.


-- 
Janne Blomqvist

Re: [PATCH] PR fortran/91471 -- Remove a gfc_internal_error()

[Janne Blomqvist]

On Sat, Aug 17, 2019 at 2:53 AM Steve Kargl
 wrote:
>
> The attach patch has been tested on x86_64-*-freebsd.
> The code, testcase, and ChangeLog should provide
> sufficient information.  OK to commit?
>
> 2019-08-16  Steven G. Kargl  
>
> PR fortran/91471
> * primary.c (gfc_variable_attr): Remove a gfc_internal_error(),
> which cannot be reached by conforming Fortran code, but seems to
> be reachable from nonconforming Fortran code.  Treat the AR_UNKNOWN
> case as a no-op.
>
> 2019-08-16  Steven G. Kargl  
>
> PR fortran/91471
> * gfortran.dg/pr91471.f90: New test.

Ok.


-- 
Janne Blomqvist

Re: [PATCH] PR fortran/78739 -- detect statement function name conflict

[Janne Blomqvist]

On Sat, Aug 17, 2019 at 2:47 AM Steve Kargl
 wrote:
>
> The attach patch checks that a statement function name
> does not conflict the name of the containing function.
> Regression tested on x86_64-*-freebsd.  OK to commit?
>
> 2019-08-16  Steven G. Kargl  
>
> PR fortran/78739
> * match.c (gfc_match_st_function):  When matching a statement 
> function,
> need to check if the statement function name shadows the function
> name.
>
> 2019-08-16  Steven G. Kargl  
>
> PR fortran/78739
> * fortran.dg/pr78739.f90: New test.

Ok, thanks.



-- 
Janne Blomqvist

libgo patch committed: Scan write barrier buffer conservatively

[Ian Lance Taylor]

This libgo patch by Cherry Zhang scans the write barrier buffer
conservatively.  In gccgo, we insert the write barriers in the
frontend, and so we cannot completely prevent write barriers on stack
writes.  So it is possible for a bad pointer appearing in the write
barrier buffer.  When flushing the write barrier, treat it the same as
scanning the stack.  In particular, don't mark a pointer if it does
not point to an allocated object. We already have similar logic in
greyobject.  With this, hopefully, we can prevent an unallocated
object from being marked completely.  Bootstrapped and ran Go
testsuite on x86_64-pc-linux-gnu.  Committed to mainline.

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 274591)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-0f6d673d5b1a3474c3424cb6994ae8ff9baed255
+838f926c93898767f0337122725a4f52a1335186
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: libgo/go/runtime/mwbbuf.go
===
--- libgo/go/runtime/mwbbuf.go  (revision 274169)
+++ libgo/go/runtime/mwbbuf.go  (working copy)
@@ -285,10 +285,17 @@ func wbBufFlush1(_p_ *p) {
// path to reduce the rate of flushes?
continue
}
-   obj, span, objIndex := findObject(ptr, 0, 0, false)
+   obj, span, objIndex := findObject(ptr, 0, 0, !usestackmaps)
if obj == 0 {
continue
}
+   if span.isFree(objIndex) {
+   // For gccgo, it is possible that we have a write 
barrier
+   // writing to unintialized stack memory. So we could see
+   // a bad pointer in the write barrier buffer. Don't mark
+   // it in this case.
+   continue
+   }
// TODO: Consider making two passes where the first
// just prefetches the mark bits.
mbits := span.markBitsForIndex(objIndex)

Implement C++20 p1424 - 'constexpr' feature macro concerns.

[Ed Smith-Rowland via gcc-patches]

The latest draft and I guess the above paper changed the macro names for 
the C++20 constexpr lib featues.


__cpp_lib_constexpr_algorithms ->__cpp_lib_constexpr.

This patch changes the name but not the date because I still have some 
work to do before I can ship the "miscellaneous" constexpr material.


I would like to slot this patch in before that chunk 3 of the constexpr 
lib patch set rather than wait because it simplifies the testing of 
macros somewhat.


I would also like to kill a non-standard macro pretty quickly.

It is a trivial patch really and it built and tested cleanly on 
x86_64-linux.


Ok for mainline?

Ed


2019-08-19  Edward Smith-Rowland  <3dw...@verizon.net>

Implement C++20 p1424 - 'constexpr' feature macro concerns.
* include/std/version (__cpp_lib_constexpr_algorithms): Change macro
name to __cpp_lib_constexpr.
* include/bits/algorithmfwd.h: Ditto.
* include/std/utility: Ditto.
* testsuite/25_algorithms/constexpr_macro.cc: Ditto.
* testsuite/25_algorithms/cpp_lib_constexpr.cc: New check for
__cpp_lib_constexpr macro in .
* testsuite/20_util/exchange/constexpr.cc: Add check for
__cpp_lib_constexpr macro in .
* testsuite/25_algorithms/adjacent_find/constexpr.cc: Remove check for
__cpp_lib_constexpr_algorithms (now __cpp_lib_constexpr) in .
* testsuite/25_algorithms/all_of/constexpr.cc: Ditto.
* testsuite/25_algorithms/any_of/constexpr.cc: Ditto.
* testsuite/25_algorithms/binary_search/constexpr.cc: Ditto.
* testsuite/25_algorithms/copy/constexpr.cc: Ditto.
* testsuite/25_algorithms/copy_backward/constexpr.cc: Ditto.
* testsuite/25_algorithms/copy_if/constexpr.cc: Ditto.
* testsuite/25_algorithms/copy_n/constexpr.cc: Ditto.
* testsuite/25_algorithms/count/constexpr.cc: Ditto.
* testsuite/25_algorithms/count_if/constexpr.cc: Ditto.
* testsuite/25_algorithms/equal/constexpr.cc: Ditto.
* testsuite/25_algorithms/equal_range/constexpr.cc: Ditto.
* testsuite/25_algorithms/fill/constexpr.cc: Ditto.
* testsuite/25_algorithms/fill_n/constexpr.cc: Ditto.
* testsuite/25_algorithms/find/constexpr.cc: Ditto.
* testsuite/25_algorithms/find_end/constexpr.cc: Ditto.
* testsuite/25_algorithms/find_first_of/constexpr.cc: Ditto.
* testsuite/25_algorithms/find_if/constexpr.cc: Ditto.
* testsuite/25_algorithms/find_if_not/constexpr.cc: Ditto.
* testsuite/25_algorithms/for_each/constexpr.cc: Ditto.
* testsuite/25_algorithms/generate/constexpr.cc: Ditto.
* testsuite/25_algorithms/generate_n/constexpr.cc: Ditto.
* testsuite/25_algorithms/is_heap/constexpr.cc: Ditto.
* testsuite/25_algorithms/is_heap_until/constexpr.cc: Ditto.
* testsuite/25_algorithms/is_partitioned/constexpr.cc: Ditto.
* testsuite/25_algorithms/is_permutation/constexpr.cc: Ditto.
* testsuite/25_algorithms/is_sorted/constexpr.cc: Ditto.
* testsuite/25_algorithms/is_sorted_until/constexpr.cc: Ditto.
* testsuite/25_algorithms/lexicographical_compare/constexpr.cc: Ditto.
* testsuite/25_algorithms/lower_bound/constexpr.cc: Ditto.
* testsuite/25_algorithms/merge/constexpr.cc: Ditto.
* testsuite/25_algorithms/mismatch/constexpr.cc: Ditto.
* testsuite/25_algorithms/none_of/constexpr.cc: Ditto.
* testsuite/25_algorithms/partition_copy/constexpr.cc: Ditto.
* testsuite/25_algorithms/partition_point/constexpr.cc: Ditto.
* testsuite/25_algorithms/remove/constexpr.cc: Ditto.
* testsuite/25_algorithms/remove_copy/constexpr.cc: Ditto.
* testsuite/25_algorithms/remove_copy_if/constexpr.cc: Ditto.
* testsuite/25_algorithms/remove_if/constexpr.cc: Ditto.
* testsuite/25_algorithms/replace_copy/constexpr.cc: Ditto.
* testsuite/25_algorithms/replace_copy_if/constexpr.cc: Ditto.
* testsuite/25_algorithms/replace_if/constexpr.cc: Ditto.
* testsuite/25_algorithms/reverse_copy/constexpr.cc: Ditto.
* testsuite/25_algorithms/rotate_copy/constexpr.cc: Ditto.
* testsuite/25_algorithms/search/constexpr.cc: Ditto.
* testsuite/25_algorithms/search_n/constexpr.cc: Ditto.
* testsuite/25_algorithms/set_difference/constexpr.cc: Ditto.
* testsuite/25_algorithms/set_intersection/constexpr.cc: Ditto.
* testsuite/25_algorithms/set_symmetric_difference/constexpr.cc: Ditto.
* testsuite/25_algorithms/set_union/constexpr.cc: Ditto.
* testsuite/25_algorithms/transform/constexpr.cc: Ditto.
* testsuite/25_algorithms/unique/constexpr.cc: Ditto.
* testsuite/25_algorithms/unique_copy/constexpr.cc: Ditto.
* testsuite/25_algorithms/upper_bound/constexpr.cc: Ditto.

Index: include/bits/algorithmfwd.h
===
--- 

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

[Jason Merrill]

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?

Jason

[PATCH V2 2/8] 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  |   68 ++-
 configure.ac   |   54 +-
 contrib/ChangeLog  |4 +
 contrib/config-list.mk |2 +-
 gcc/ChangeLog  |   16 +
 gcc/common/config/bpf/bpf-common.c |   57 ++
 gcc/config.gcc |9 +
 gcc/config/bpf/bpf-helpers.def |  194 ++
 gcc/config/bpf/bpf-helpers.h   |  324 ++
 gcc/config/bpf/bpf-opts.h  |   56 ++
 gcc/config/bpf/bpf-protos.h|   33 ++
 gcc/config/bpf/bpf.c   | 1136 
 gcc/config/bpf/bpf.h   |  565 ++
 gcc/config/bpf/bpf.md  |  528 +
 gcc/config/bpf/bpf.opt |  119 
 gcc/config/bpf/constraints.md  |   29 +
 gcc/config/bpf/predicates.md   |  105 
 gcc/config/bpf/t-bpf   |0
 19 files changed, 3300 insertions(+), 4 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 b/configure
index 63b1e33f41c..4f8e68a4085 100755
--- a/configure
+++ b/configure
@@ -754,6 +754,7 @@ infodir
 docdir
 oldincludedir
 includedir
+runstatedir
 localstatedir
 sharedstatedir
 sysconfdir
@@ -919,6 +920,7 @@ datadir='${datarootdir}'
 sysconfdir='${prefix}/etc'
 sharedstatedir='${prefix}/com'
 localstatedir='${prefix}/var'
+runstatedir='${localstatedir}/run'
 includedir='${prefix}/include'
 oldincludedir='/usr/include'
 docdir='${datarootdir}/doc/${PACKAGE}'
@@ -1171,6 +1173,15 @@ do
   | -silent | --silent | --silen | --sile | --sil)
 silent=yes ;;
 
+  -runstatedir | --runstatedir | --runstatedi | --runstated \
+  | --runstate | --runstat | --runsta | --runst | --runs \
+  | --run | --ru | --r)
+ac_prev=runstatedir ;;
+  -runstatedir=* | --runstatedir=* | --runstatedi=* | --runstated=* \
+  | --runstate=* | --runstat=* | --runsta=* | --runst=* | --runs=* \
+  | --run=* | --ru=* | --r=*)
+runstatedir=$ac_optarg ;;
+
   -sbindir | --sbindir | --sbindi | --sbind | --sbin | --sbi | --sb)
 ac_prev=sbindir ;;
   -sbindir=* | --sbindir=* | --sbindi=* | --sbind=* | --sbin=* \
@@ -1308,7 +1319,7 @@ fi
 for ac_var in  exec_prefix prefix bindir sbindir libexecdir datarootdir \
datadir sysconfdir sharedstatedir localstatedir includedir \
oldincludedir docdir infodir htmldir dvidir pdfdir psdir \
-   libdir localedir mandir
+   libdir localedir mandir runstatedir
 do
   eval ac_val=\$$ac_var
   # Remove trailing slashes.
@@ -1468,6 +1479,7 @@ Fine tuning of the installation directories:
   --sysconfdir=DIRread-only single-machine data [PREFIX/etc]
   --sharedstatedir=DIRmodifiable architecture-independent data [PREFIX/com]
   --localstatedir=DIR modifiable single-machine data [PREFIX/var]
+  --runstatedir=DIR   modifiable per-process data [LOCALSTATEDIR/run]
   --libdir=DIRobject code libraries [EPREFIX/lib]
   --includedir=DIRC header files [PREFIX/include]
   --oldincludedir=DIR C header files for non-gcc [/usr/include]
@@ -3353,6 +3365,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"
 ;;
@@ -3387,12 +3402,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"
 

[PATCH] PR fortran/78719 -- Check for a CLASS

[Steve Kargl]

Regression tested on x86_64-*-freebsd.  OK to commit?

When checking to see in attrbutes are being added to
an entity that alrady has an explcit interface, gfortran
failed to consider the case of CLASS.  The attach patch
corrects this omission.  See the 3 testcases for clarity.

2019-08-16  Steven G. Kargl  

PR fortran/78719
* decl.c (get_proc_name): Check for a CLASS entity when trying to
add attributes to an entity that already has an explicit interface.

2019-08-16  Steven G. Kargl  

PR fortran/78719
* gfortran.dg/pr78719_1.f90: New test.
* gfortran.dg/pr78719_2.f90: Ditto.
* gfortran.dg/pr78719_3.f90: Ditto.

-- 
Steve
Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c	(revision 274578)
+++ gcc/fortran/decl.c	(working copy)
@@ -1363,9 +1363,9 @@ get_proc_name (const char *name, gfc_symbol **result, 
 	}
 
   /* Trap declarations of attributes in encompassing scope.  The
-	 signature for this is that ts.kind is set.  Legitimate
-	 references only set ts.type.  */
-  if (sym->ts.kind != 0
+	 signature for this is that ts.kind is nonzero for no-CLASS
+	 entity.  For a CLASS entity, ts.kind is zero.  */
+  if ((sym->ts.kind != 0 || sym->ts.type == BT_CLASS)
 	  && !sym->attr.implicit_type
 	  && sym->attr.proc == 0
 	  && gfc_current_ns->parent != NULL
Index: gcc/testsuite/gfortran.dg/pr78719_1.f90
===
--- gcc/testsuite/gfortran.dg/pr78719_1.f90	(nonexistent)
+++ gcc/testsuite/gfortran.dg/pr78719_1.f90	(working copy)
@@ -0,0 +1,29 @@
+! { dg-do run }
+! PR fortran/78719
+! Code contributed by Gerhard Steinmetz 
+program p
+
+   type t
+  integer :: n
+   end type
+
+   abstract interface
+  subroutine h
+  end
+   end interface
+
+   procedure(h), pointer :: s
+
+   s => f
+   call s
+   s => g
+   call s
+
+   contains
+
+  subroutine f
+  end
+
+  subroutine g
+  end
+end program p
Index: gcc/testsuite/gfortran.dg/pr78719_2.f90
===
--- gcc/testsuite/gfortran.dg/pr78719_2.f90	(nonexistent)
+++ gcc/testsuite/gfortran.dg/pr78719_2.f90	(working copy)
@@ -0,0 +1,32 @@
+! { dg-do compile }
+! PR fortran/78719
+! Code contributed by Gerhard Steinmetz 
+program p
+
+   type t
+  integer :: n
+   end type
+
+   real :: g
+
+   abstract interface
+  subroutine h
+  end
+   end interface
+
+   procedure(h), pointer :: s
+
+   s => f
+   call s
+   s => g! { dg-error "Invalid procedure pointer" }
+   call s
+
+   contains
+
+  subroutine f
+  end
+
+  subroutine g   ! { dg-error "has an explicit interface" }
+  end
+
+end program p! { dg-error "Syntax error" }
Index: gcc/testsuite/gfortran.dg/pr78719_3.f90
===
--- gcc/testsuite/gfortran.dg/pr78719_3.f90	(nonexistent)
+++ gcc/testsuite/gfortran.dg/pr78719_3.f90	(working copy)
@@ -0,0 +1,32 @@
+! { dg-do compile }
+! PR fortran/78719
+! Code contributed by Gerhard Steinmetz 
+program p
+
+   type t
+  integer :: n
+   end type
+
+   class(t) :: g ! { dg-error "must be dummy, allocatable or pointer" }
+
+   abstract interface
+  subroutine h
+  end
+   end interface
+
+   procedure(h), pointer :: s
+
+   s => f
+   call s
+   s => g! { dg-error "Invalid procedure pointer" }
+   call s
+
+   contains
+
+  subroutine f
+  end
+
+  subroutine g   ! { dg-error "has an explicit interface" }
+  end
+
+end program p! { dg-error "Syntax error" }

[PATCH V2 4/8] 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 V2 0/8] eBPF support for GCC

[Jose E. Marchesi]

[Differences from V1:
. A bug in bpf_target_macros was embarrassing enough to trigger me to
  send this fixed new version of the patch series.  My strlen
  vs. sizeof dyslexia attacking again...
. Rebased to latest 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 patch is preparatory.  It updates config.guess and
config.sub from the 'config' upstream project, in order to recognize
bpf-*-* triplets.

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

The third 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 fourth, fifth and sixth 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 seventh patch adds documentation updates to the GCC manual,
including information on the new command line options and compiler
built-ins.

Finally, the eight 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 stack.

. Argument passing is restricted to 5 arguments.

. Each stack frame is limited to 512 bytes.

. The instruction set doesn't support indirect jumps.

. The instruction set doesn't support indirect calls.

. The architecture doesn't provide an explicit stack pointer.
  Instead, the eBPF "hardware" (in this case the kernel verifier)
  examines the compiled program and, by looking at the way the stack
  is accessed, estimates the size of the stack frame for each
  function.

. eBPF "programs" are not ELF executables, but relocatable ELF
  objects.  This is because the kernel loaders need access to certain
  relocations, and each object contains several entry points, which
  are different kind of eBPF kernel programs hooked to different parts
  of the kernel.  We are working on a more "Elf conventional"
  alternative load model for eBPF programs, but that's a tangent at
  this point.

Restrictions like the above impact the port in several ways, some of
which are good to keep in mind while reviewing the patches:

. Only (a subset of) C is supported at the moment.  It should be
  possible to add more languages in the future, as the eBPF kernel
  verifier gets smarter and therefore more sophisticated programs are
  allowed.

. The back end tries to issue errors when an eBPF restriction is
  violated.  This is to increase the 

[PATCH V2 6/8] 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 indirect
calls, no support for more than 5 arguments to function calls, no
support for indirect jumps, a very limited range for direct jumps, the
stack limit, lack of standard header files, etc.

Hopefully some of these restrictions will be relaxed in the future.
In particular, I expect the stack limit will be significantly
increased at some point.  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/2211-1.c: Skip if target bpf-*-*.
* gcc.c-torture/compile/2403-1.c: Likewise.
* gcc.c-torture/compile/2609-1.c: Likewise.
* gcc.c-torture/compile/2804-1.c: Likewise.
* gcc.c-torture/compile/20001226-1.c: Likewise.
* gcc.c-torture/compile/20010102-1.c: Likewise.
* 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/20020304-1.c: Likewise.
* gcc.c-torture/compile/20020320-1.c: Likewise.
* gcc.c-torture/compile/20020604-1.c: Likewise.
* gcc.c-torture/compile/20020706-1.c: Likewise.
* gcc.c-torture/compile/20020706-2.c: Likewise.
* gcc.c-torture/compile/20021015-1.c: Likewise.
* gcc.c-torture/compile/20021205-1.c: Likewise.
* gcc.c-torture/compile/20030903-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/20031125-1.c: Likewise.
* gcc.c-torture/compile/20040101-1.c: Likewise.
* gcc.c-torture/compile/20040317-2.c: Likewise.
* gcc.c-torture/compile/20040614-1.c: Likewise.
* gcc.c-torture/compile/20040726-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/20050303-1.c: Likewise.
* gcc.c-torture/compile/20050622-1.c: Likewise.
* gcc.c-torture/compile/20051216-1.c: Likewise.
* gcc.c-torture/compile/20060208-1.c: Likewise.
* gcc.c-torture/compile/20060421-1.c: Likewise.
* gcc.c-torture/compile/20071207-1.c: Likewise.
* gcc.c-torture/compile/20080903-1.c: Likewise.
* gcc.c-torture/compile/20081108-1.c: Likewise.
* gcc.c-torture/compile/20101217-1.c: Likewise.
* gcc.c-torture/compile/20121027-1.c: Likewise.
* gcc.c-torture/compile/20150327.c: Likewise.
* gcc.c-torture/compile/20151204.c: Likewise.
* gcc.c-torture/compile/900313-1.c: Likewise.
* gcc.c-torture/compile/920428-2.c: Likewise.
* gcc.c-torture/compile/920501-12.c: Likewise.
* gcc.c-torture/compile/920501-4.c: Likewise.
* gcc.c-torture/compile/920501-7.c: Likewise.
* gcc.c-torture/compile/920625-1.c: Likewise.
* gcc.c-torture/compile/920723-1.c: Likewise.
* gcc.c-torture/compile/920928-5.c: Likewise.
* gcc.c-torture/compile/921202-1.c: Likewise.
* gcc.c-torture/compile/930117-1.c: Likewise.
* gcc.c-torture/compile/930421-1.c: Likewise.
* gcc.c-torture/compile/930607-1.c: Likewise.
* gcc.c-torture/compile/930623-1.c: Likewise.
* gcc.c-torture/compile/931003-1.c: Likewise.
* gcc.c-torture/compile/931004-1.c: Likewise.
* gcc.c-torture/compile/950719-1.c: Likewise.
* gcc.c-torture/compile/951222-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/990517-1.c: Likewise.
* gcc.c-torture/compile/990625-1.c: Likewise.
* gcc.c-torture/compile/991213-2.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.
* 

[PATCH V2 8/8] bpf: add myself as the maintainer for the eBPF port

[Jose E. Marchesi]

ChangeLog:

* MAINTAINERS: Add myself as the maintainer for the eBPF port.
---
 ChangeLog   | 4 
 MAINTAINERS | 1 +
 2 files changed, 5 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 5d8402949bc..bcf81e8f337 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 
-- 
2.11.0

[PATCH V2 5/8] 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_malloc): New
function.
(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   | 11 +++
 gcc/testsuite/lib/target-supports.exp | 27 +++
 2 files changed, 30 insertions(+), 8 deletions(-)

diff --git a/gcc/testsuite/lib/target-supports.exp 
b/gcc/testsuite/lib/target-supports.exp
index 300d22a2d65..8b6168626d8 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
@@ -538,6 +539,9 @@ proc check_effective_target_stack_size { } {
 if [target_info exists gcc,stack_size] {
return 1
 }
+if [istarget bpf-*-*] {
+   return 1
+}
 return 0
 }
 
@@ -546,7 +550,11 @@ proc check_effective_target_stack_size { } {
 proc dg-effective-target-value { effective_target } {
 if { "$effective_target" == "stack_size" } {
if [check_effective_target_stack_size] {
-   return [target_info gcc,stack_size]
+   if [istarget bpf-*-*] {
+   return "512"
+   } else {
+   return [target_info gcc,stack_size]
+   }
}
 }
 
@@ -781,7 +789,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 +798,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 +807,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 +832,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 V2 7/8] 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 |  30 +
 3 files changed, 208 insertions(+)

diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 2ba9b74811a..7b75326590c 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -13603,6 +13603,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::
@@ -14600,6 +14602,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 __builtin_bpf_helper_probe_read 

[PATCH V2 3/8] 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  | 24 
 5 files changed, 38 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..c1bda7c98cb
--- /dev/null
+++ b/libgcc/config/bpf/t-bpf
@@ -0,0 +1,24 @@
+HOST_LIBGCC2_CFLAGS += -O0
+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 V2 1/8] 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
-   

Re: C++ PATCH for c++/91264 - detect modifying const objects in constexpr

[Jason Merrill]

On 8/16/19 5:11 AM, Marek Polacek wrote:

On Thu, Aug 15, 2019 at 08:21:25PM -0400, Jason Merrill wrote:

On 8/15/19 5:34 PM, Marek Polacek wrote:

On Wed, Aug 14, 2019 at 02:50:13PM -0400, Jason Merrill wrote:

On Thu, Aug 8, 2019 at 3:25 PM Marek Polacek  wrote:


On Thu, Aug 08, 2019 at 11:06:17AM -0400, Jason Merrill wrote:

On 8/6/19 3:20 PM, Marek Polacek wrote:

On Mon, Aug 05, 2019 at 03:54:19PM -0400, Jason Merrill wrote:

On 7/31/19 3:26 PM, Marek Polacek wrote:

One of the features of constexpr is that it doesn't allow UB; and such UB must
be detected at compile-time.  So running your code in a context that requires
a constant expression should ensure that the code in question is free of UB.
In effect, constexpr can serve as a sanitizer.  E.g. this article describes in
in more detail:


[dcl.type.cv]p4 says "Any attempt to modify a const object during its lifetime
results in undefined behavior." However, as the article above points out, we
aren't detecting that case in constexpr evaluation.

This patch fixes that.  It's not that easy, though, because we have to keep in
mind [class.ctor]p5:
"A constructor can be invoked for a const, volatile or const volatile object.
const and volatile semantics are not applied on an object under construction.
They come into effect when the constructor for the most derived object ends."

I handled this by keeping a hash set which tracks objects under construction.
I considered other options, such as going up call_stack, but that wouldn't
work with trivial constructor/op=.  It was also interesting to find out that
the definition of TREE_HAS_CONSTRUCTOR says "When appearing in a FIELD_DECL,
it means that this field has been duly initialized in its constructor" though
nowhere in the codebase do we set TREE_HAS_CONSTRUCTOR on a FIELD_DECL as far
as I can see.  Unfortunately, using this bit proved useless for my needs here.



Also, be mindful of mutable subobjects.

Does this approach look like an appropriate strategy for tracking objects'
construction?


For scalar objects, we should be able to rely on INIT_EXPR vs. MODIFY_EXPR
to distinguish between initialization and modification; for class objects, I


This is already true: only class object go into the hash set.


wonder about setting a flag on the CONSTRUCTOR after initialization is
complete to indicate that the value is now constant.


But here we're not dealing with CONSTRUCTORs in the gcc sense (i.e. exprs with
TREE_CODE == CONSTRUCTOR).  We have a CALL_EXPR like Y::Y ((struct Y *) ),
which initializes the object "y".  Setting a flag on the CALL_EXPR or its 
underlying
function decl wouldn't help.

Am I missing something?


I was thinking that where in your current patch you call
remove_object_under_construction, we could instead mark the object's value
CONSTRUCTOR as immutable.


Ah, what you meant was to look at DECL_INITIAL of the object we're
constructing, which could be a CONSTRUCTOR.  Unfortunately, this
DECL_INITIAL is null (in all the new tests when doing
remove_object_under_construction), so there's nothing to mark as TREE_READONLY 
:/.


There's a value in ctx->values, isn't there?


Doesn't seem to be the case for e.g.

struct A {
int n;
constexpr A() : n(1) { n = 2; }
};

struct B {
const A a;
constexpr B(bool b) {
  if (b)
const_cast(a).n = 3; // { dg-error "modifying a const object" }
  }
};

constexpr B b(false);
static_assert(b.a.n == 2, "");

Here we're constructing "b", its ctx->values->get(new_obj) is initially
"{}".  In the middle of constructing "b", we construct "b.a", but that
has nothing in ctx->values.


Right, subobjects aren't in ctx->values.  In cxx_eval_call_expression we
have

   if (DECL_CONSTRUCTOR_P (fun))
 /* This can be null for a subobject constructor call, in

which case what we care about is the initialization

side-effects rather than the value.  We could get at the

value by evaluating *this, but we don't bother; there's

no need to put such a call in the hash table.  */
 result = lval ? ctx->object : ctx->ctor;

Your patch already finds *this (b.a) and puts it in new_obj; if it's const
we can evaluate it to get the CONSTRUCTOR to set TREE_READONLY on.


Ah, got it!  This patch uses setting TREE_READONLY to achieve what I was after.
I also needed to set TREE_READONLY in cxx_eval_constant_expression/DECL_EXPR.
The additional evaluating will only happen for const-qual objects so I hope not
very often.

Any further comments?  Thanks,

@@ -1910,6 +1958,29 @@ cxx_eval_call_expression (const constexpr_ctx *ctx, tree 
t,

+ /* At this point, the object's constructor will have run, so
+the object is no longer under construction, and its possible
+'const' semantics now apply.  Make a note of this fact by
+   

[PATCH] PR fortran/91471 -- Remove a gfc_internal_error()

[Steve Kargl]

The attach patch has been tested on x86_64-*-freebsd.
The code, testcase, and ChangeLog should provide 
sufficient information.  OK to commit?

2019-08-16  Steven G. Kargl  

PR fortran/91471
* primary.c (gfc_variable_attr): Remove a gfc_internal_error(),
which cannot be reached by conforming Fortran code, but seems to
be reachable from nonconforming Fortran code.  Treat the AR_UNKNOWN
case as a no-op.

2019-08-16  Steven G. Kargl  

PR fortran/91471
* gfortran.dg/pr91471.f90: New test.
-- 
Steve
Index: gcc/fortran/primary.c
===
--- gcc/fortran/primary.c	(revision 274578)
+++ gcc/fortran/primary.c	(working copy)
@@ -2597,12 +2597,10 @@ gfc_variable_attr (gfc_expr *expr, gfc_typespec *ts)
 	break;
 
 	  case AR_UNKNOWN:
-	/* If any of start, end or stride is not integer, there will
-	   already have been an error issued.  */
-	int errors;
-	gfc_get_errors (NULL, );
-	if (errors == 0)
-	  gfc_internal_error ("gfc_variable_attr(): Bad array reference");
+	/* For standard conforming code, AR_UNKNOWN should not happen.
+	   For nonconforming code, gfortran can end up here.  Treat it 
+	   as a no-op.  */
+	break;
 	  }
 
 	break;
Index: gcc/testsuite/gfortran.dg/pr91471.f90
===
--- gcc/testsuite/gfortran.dg/pr91471.f90	(nonexistent)
+++ gcc/testsuite/gfortran.dg/pr91471.f90	(working copy)
@@ -0,0 +1,14 @@
+! { dg-do compile }
+! PR fortran/91471
+! Code contributed by Sameeran Joshi 
+!
+! This invalid code (x(1) is referenced, but never set) caused an ICE due
+! to hitting a gfc_internal_error() in primary.c (gfc_variable_attr).  The
+! fix is to remove that gfc_internal_error().
+! 
+program dynamic
+   implicit none
+   integer, dimension(:), allocatable :: x
+   allocate(x(1))
+   stop x(1)
+end program dynamic

[PATCH] PR fortran/78739 -- detect statement function name conflict

[Steve Kargl]

The attach patch checks that a statement function name
does not conflict the name of the containing function.
Regression tested on x86_64-*-freebsd.  OK to commit?

2019-08-16  Steven G. Kargl  

PR fortran/78739
* match.c (gfc_match_st_function):  When matching a statement function,
need to check if the statement function name shadows the function
name.

2019-08-16  Steven G. Kargl  

PR fortran/78739
* fortran.dg/pr78739.f90: New test.

-- 
Steve
Index: gcc/fortran/match.c
===
--- gcc/fortran/match.c	(revision 274578)
+++ gcc/fortran/match.c	(working copy)
@@ -5751,7 +5751,29 @@ gfc_match_st_function (void)
   gfc_symbol *sym;
   gfc_expr *expr;
   match m;
+  char name[GFC_MAX_SYMBOL_LEN + 1];
+  locus old_locus;
+  bool fcn;
+  gfc_formal_arglist *ptr;
 
+  /* Read the possible statement function name, and then check to see if
+ a symbol is already present in the namespace.  Record if it is a
+ function and whether it has been referenced.  */
+  fcn = false;
+  ptr = NULL;
+  old_locus = gfc_current_locus;
+  m = gfc_match_name (name);
+  if (m == MATCH_YES)
+{
+  gfc_find_symbol (name, NULL, 1, );
+  if (sym && sym->attr.function && !sym->attr.referenced)
+	{
+	  fcn = true;
+	  ptr = sym->formal;
+	}
+}
+
+  gfc_current_locus = old_locus;
   m = gfc_match_symbol (, 0);
   if (m != MATCH_YES)
 return m;
@@ -5776,6 +5798,13 @@ gfc_match_st_function (void)
   if (recursive_stmt_fcn (expr, sym))
 {
   gfc_error ("Statement function at %L is recursive", >where);
+  return MATCH_ERROR;
+}
+
+  if (fcn && ptr != sym->formal)
+{
+  gfc_error ("Statement function %qs at %L conflicts with function name",
+		 sym->name, >where);
   return MATCH_ERROR;
 }
 
Index: gcc/testsuite/gfortran.dg/pr78739.f90
===
--- gcc/testsuite/gfortran.dg/pr78739.f90	(nonexistent)
+++ gcc/testsuite/gfortran.dg/pr78739.f90	(working copy)
@@ -0,0 +1,15 @@
+! { dg-do compile }
+! { dg-options "-w" }
+! PR fortran/78739
+! Code contributed Gerhard Steinmetz
+function f(n)
+   f() = n! { dg-error "conflicts with function name" }
+end
+
+function g()
+   g(x) = x   ! { dg-error "conflicts with function name" }
+end
+
+function a()  ! This should cause an error, but cannot be easily detected!
+   a() = x
+end

Re: [PATCH] PR fortran/68401 Improve allocation error message

[Steve Kargl]

On Fri, Aug 16, 2019 at 05:31:36PM +0300, Janne Blomqvist wrote:
> Improve the error message that is printed when a memory allocation
> fails, by including the location, and the size of the allocation that
> failed.
> 
> Regtested on x86_64-pc-linux-gnu, Ok for trunk?
> 

Looks good to me.

-- 
Steve

Go patch committed: Print runtime.hex in hex

[Ian Lance Taylor]

This is a patch to the Go frontend by Cherry Zhang.  The gc compiler
recognizes the type runtime.hex and prints values in this type as hex.
Do the same in the Go frontend. This makes debugging runtime crashes
slightly better.  Bootstrapped and ran Go testsuite on
x86_64-pc-linux-gnu.  Committed to mainline.

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 274169)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-480477ca64c3001b9c7e92ef8b978dc92a5912d2
+0f6d673d5b1a3474c3424cb6994ae8ff9baed255
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: gcc/go/gofrontend/expressions.cc
===
--- gcc/go/gofrontend/expressions.cc(revision 274169)
+++ gcc/go/gofrontend/expressions.cc(working copy)
@@ -10294,7 +10294,13 @@ Builtin_call_expression::do_get_backend(
  {
Type* itype = Type::lookup_integer_type("uint64");
arg = Expression::make_cast(itype, arg, location);
-code = Runtime::PRINTUINT;
+if (gogo->compiling_runtime()
+&& type->named_type() != NULL
+&& gogo->unpack_hidden_name(type->named_type()->name())
+   == "hex")
+  code = Runtime::PRINTHEX;
+else
+  code = Runtime::PRINTUINT;
  }
else if (type->integer_type() != NULL)
  {
Index: gcc/go/gofrontend/runtime.def
===
--- gcc/go/gofrontend/runtime.def   (revision 274169)
+++ gcc/go/gofrontend/runtime.def   (working copy)
@@ -384,6 +384,9 @@ DEF_GO_RUNTIME(PRINTSTRING, "runtime.pri
 // Print a uint64 (for print/println).
 DEF_GO_RUNTIME(PRINTUINT, "runtime.printuint", P1(UINT64), R0())
 
+// Print a uint64 in hex (for print/println, used for runtime.hex type).
+DEF_GO_RUNTIME(PRINTHEX, "runtime.printhex", P1(UINT64), R0())
+
 // Print a int64 (for print/println).
 DEF_GO_RUNTIME(PRINTINT, "runtime.printint", P1(INT64), R0())
 

[PATCH] issue consistent warning for past-the-end array stores (PR 91457)

[Martin Sebor]

With the recent enhancement to the strlen handling of multibyte
stores the g++.dg/warn/Warray-bounds-4.C for zero-length arrays
started failing on hppa (and probably elsewhere as well).  This
is partly the result of the added detection of past-the-end
writes into the strlen pass which detects more instances of
the problem than -Warray-bounds.  Since the IL each warning
works with varies between targets, the same invalid code can
be diagnosed by one warning one target and different warning
on another.

The attached patch does three things:

1) It enhances compute_objsize to also determine the size of
a flexible array member (and its various variants), including
from its initializer if necessary.  (This resolves 91457 but
introduces another warning where was previously just one.)
2) It guards the new instance of -Wstringop-overflow with
the no-warning bit on the assignment to avoid warning on code
that's already been diagnosed.
3) It arranges for -Warray-bounds to set the no-warning bit on
the enclosing expression to keep -Wstringop-overflow from issuing
another warning for the same problem.

Testing the compute_objsize enhancement to bring it up to par
with -Warray-bounds in turn exposed a weakness in the latter
warning for flexible array members.  Rather than snowballing
additional improvements into this one I decided to put that
off until later, so the new -Warray-bounds test has a bunch
of XFAILs.  I'll see if I can find the time to deal with those
either still in stage 1 or in stage 3 (one of them is actually
an ancient regression).

Martin

PS I imagine the new get_flexarray_size function will probably
need to move somewhere more appropriate so that other warnings
(like -Warray-bounds to remove the XFAILs) and optimizations
can make use of it.
PR tree-optimization/91458 - inconsistent warning for writing past the end of an array member

gcc/testsuite/ChangeLog:

	PR tree-optimization/91458
	* g++.dg/warn/Warray-bounds-8.C: New test.
	* g++.dg/warn/Wstringop-overflow-3.C: New test.

gcc/ChangeLog:

	PR tree-optimization/91458
	* builtins.c (get_initializer_for, get_flexarray_size): New functions.
	(compute_objsize): Add argument. Handle ARRAY_REF and COMPONENT_REF.
	* builtins.h ((compute_objsize): Add argument.
	* tree-ssa-strlen.c (handle_store): Handle no-warning bit.
	* tree-vrp.c (vrp_prop::check_array_ref): Return warning result.
	(vrp_prop::check_mem_ref): Same.
	(vrp_prop::search_for_addr_array): Set no-warning bit.
	(check_array_bounds): Same.
Index: gcc/builtins.c
===
--- gcc/builtins.c	(revision 274541)
+++ gcc/builtins.c	(working copy)
@@ -3560,6 +3560,51 @@ check_access (tree exp, tree, tree, tree dstwrite,
   return true;
 }
 
+/* Given the initializer INIT, return the initializer for the field
+   DECL if it exists, otherwise null.  Used to obtain the initializer
+   for a flexible array member and determine its size.  */
+
+static tree
+get_initializer_for (tree init, tree decl)
+{
+  STRIP_NOPS (init);
+
+  tree fld, fld_init;
+  unsigned HOST_WIDE_INT i;
+  FOR_EACH_CONSTRUCTOR_ELT (CONSTRUCTOR_ELTS (init), i, fld, fld_init)
+{
+  if (decl == fld)
+	return fld_init;
+
+  if (TREE_CODE (fld) == CONSTRUCTOR)
+	{
+	  fld_init = get_initializer_for (fld_init, decl);
+	  if (fld_init)
+	return fld_init;
+	}
+}
+
+  return NULL_TREE;
+}
+
+/* Determine the size of the flexible array FLD from the initializer
+   expression for the struct object DECL in which the meber is declared
+   (possibly recursively).  Return the size or zero constant if it isn't
+   initialized.  */
+
+static tree
+get_flexarray_size (tree decl, tree fld)
+{
+  if (tree init = DECL_INITIAL (decl))
+{
+  init = get_initializer_for (init, fld);
+  if (init)
+	return TYPE_SIZE_UNIT (TREE_TYPE (init));
+}
+
+  return integer_zero_node;
+}
+
 /* Helper to compute the size of the object referenced by the DEST
expression which must have pointer type, using Object Size type
OSTYPE (only the least significant 2 bits are used).  Return
@@ -3567,12 +3612,18 @@ check_access (tree exp, tree, tree, tree dstwrite,
the size cannot be determined.  When the referenced object involves
a non-constant offset in some range the returned value represents
the largest size given the smallest non-negative offset in the
-   range.  The function is intended for diagnostics and should not
-   be used to influence code generation or optimization.  */
+   range.  If nonnull, set *PDECL to the decl of the referenced
+   subobject if it can be determined, or to null otherwise.
+   The function is intended for diagnostics and should not be used
+   to influence code generation or optimization.  */
 
 tree
-compute_objsize (tree dest, int ostype)
+compute_objsize (tree dest, int ostype, tree *pdecl /* = NULL */)
 {
+  tree dummy = NULL_TREE;
+  if (!pdecl)
+pdecl = 
+
   unsigned HOST_WIDE_INT size;
 
   /* Only the two least 

Re: [RFA] [tree-optimization/80576] Handle non-constant sizes in DSE

[Martin Sebor]

On 8/16/19 12:15 PM, Jeff Law wrote:

On 8/16/19 12:09 PM, Marc Glisse wrote:

On Fri, 16 Aug 2019, Jeff Law wrote:


This patch improves our ability to detect dead stores by handling cases
where the size memcpy, memset, strncpy, etc call is not constant.  This
addresses some, but not all, of the issues in 80576.

The key here is when the size is not constant we can make conservative
decisions that still give us a chance to analyze the code for dead
stores.

Remember that for dead store elimination, we're trying to prove that
given two stores, the second store overwrites (partially or fully) the
same memory locations as the first store.  That makes the first store
either partially or fully dead.

When we encounter the first store, we set up a bitmap of bytes written
by that store (live_bytes).  We then look at subsequent stores and clear
the appropriate entries in the bitmap.

If the first store has a nonconstant length argument we can use the
range of the length argument (max) and the size of the destination
object to make a conservative estimation of how many bytes are written.

For the second store the conservative thing to do for a non-constant
length is to use the minimum of the range of the length argument.


So I guess it won't handle things like

void f(char*p,int n){
   __builtin_memset(p,3,n);
   __builtin_memset(p,7,n);
}

where we know nothing about the length, except that it is the same? Or
do you look at symbolic ranges?

Nope.  I think ao_ref can represent that, so it'd just be a matter of
recording "n" as the length, then verifying that the second call's
length is "n" as well.  That makes the first call dead.  We'd have to
bypass the byte tracking in that case, but I think that's trivial
because we already have a means to do that when the sizes are too large.




This doesn't come up a lot in practice.  But it also happens to put some
of the infrastructure in place to handle strcpy and strcpy_chk which are
needed to fully resolve 80576.

Bootstrapped and regression tested on x86, x86_64, ppc64le, ppc64,
ppc32, aarch64, sparc, s390x and probably others.  Also verified that
the tests work on the various *-elf targets in my tester.

OK for the trunk?


ENOPATCH

Opps.Attached.


It's an improvement and I realize you said it doesn't handle
everything and that you don't think it comes up a lot, but...
I would actually expect the following example (from the bug)
not to be that uncommon:

  void g (char *s)
  {
char a[8];
__builtin_strcpy (a, s);
__builtin_memset (a, 0, sizeof a);
f (a);
  }

or at least to be more common than the equivalent alternative
the improvement does optimize:

  void g (char *s)
  {
char a[8];
__builtin_memcpy (a, s,  __builtin_strlen (s));
__builtin_memset (a, 0, 8);
f (a);
  }

It seems that making the first one work should be just a matter
of handling strcpy analogously (the string length doesn't matter).

As an aside, the new tests make me realize that -Wstringop-overflow
should be enhanced to detect this problem (i.e., a consider
the largest size in a PHI).

Martin

Re: [RFA] [tree-optimization/80576] Handle non-constant sizes in DSE

[Jeff Law]

On 8/16/19 4:06 PM, Marc Glisse wrote:
> On Fri, 16 Aug 2019, Jeff Law wrote:
> 
>> On 8/16/19 12:09 PM, Marc Glisse wrote:
>>> On Fri, 16 Aug 2019, Jeff Law wrote:
>>>
 This patch improves our ability to detect dead stores by handling cases
 where the size memcpy, memset, strncpy, etc call is not constant.  This
 addresses some, but not all, of the issues in 80576.

 The key here is when the size is not constant we can make conservative
 decisions that still give us a chance to analyze the code for dead
 stores.

 Remember that for dead store elimination, we're trying to prove that
 given two stores, the second store overwrites (partially or fully) the
 same memory locations as the first store.  That makes the first store
 either partially or fully dead.

 When we encounter the first store, we set up a bitmap of bytes written
 by that store (live_bytes).  We then look at subsequent stores and
 clear
 the appropriate entries in the bitmap.

 If the first store has a nonconstant length argument we can use the
 range of the length argument (max) and the size of the destination
 object to make a conservative estimation of how many bytes are written.

 For the second store the conservative thing to do for a non-constant
 length is to use the minimum of the range of the length argument.
>>>
>>> So I guess it won't handle things like
>>>
>>> void f(char*p,int n){
>>>   __builtin_memset(p,3,n);
>>>   __builtin_memset(p,7,n);
>>> }
>>>
>>> where we know nothing about the length, except that it is the same? Or
>>> do you look at symbolic ranges?
>>
>> So handling this was slightly uglier than I'd hoped.  I mis-remembered
>> what we had in an ao_ref.  We have a way to describe constant sizes and
>> to mark that something was non-constant (size of -1), but not what the
>> non-constant value was.
>>
>> I looked at two approaches.  One created a dse_ref structure that had an
>> embedded ao_ref.  That creates a fair amount of churn.  But it certainly
>> looks do-able.
>>
>> The second derived a dse_ref from an ao_ref which allows the vast
>> majority of the code in tree-ssa-dse.c to just work as-is.  With that in
>> place it was fairly simply to initialize the new field and check it in a
>> couple places.  Resulting in:
>>
>>> ; Function f (f, funcdef_no=0, decl_uid=1909, cgraph_uid=1,
>>> symbol_order=0)
>>>
>>>   Deleted dead call: __builtin_memset (p_5(D), 3, _1);
>>>
>>> f (char * p, int n)
>>> {
>>>   long unsigned int _1;
>>>
>>> ;;   basic block 2, loop depth 0, maybe hot
>>> ;;    prev block 0, next block 1, flags: (NEW, VISITED)
>>> ;;    pred:   ENTRY (FALLTHRU,EXECUTABLE)
>>>   _1 = (long unsigned int) n_3(D);
>>>   __builtin_memset (p_5(D), 7, _1);
>>>   return;
>>> ;;    succ:   EXIT (EXECUTABLE)
>>>
>>> }
>>>
>>
>> Not sure how useful this will be in practice though.
> 
> Oh, I wasn't expecting you to handle it right now...
Might as well since I'm already in the code :-)


> 
> I've seen this kind of thing (not necessarily with memset, memcpy was
> probably involved as well) a few times, enough that it immediately came
> to mind when I saw the title of your message. There are probably traces
> in bugzilla, although I don't think there is a convenient search query
> to find them. I found PR 79716 that seems related at least, but not what
> I was looking for.
I didn't realize this was 79716.  I'd just glossed over that today
looking for something else in this space :-)  With the way DSE works it
really shouldn't matter if it's memset, or memcpy.

79716 also raises the issue of turning a calloc back into a simple
malloc when the zero initialization was overwritten.  We're not handling
that either.  But that seems even less likely to be seen with any
regularity.

jeff

[wwwdocs] readings.html - www.xilinx.com has moved to https

[Gerald Pfeifer]

Committed.

Gerald

Index: readings.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/readings.html,v
retrieving revision 1.319
diff -u -r1.319 readings.html
--- readings.html   10 Aug 2019 21:04:08 -  1.319
+++ readings.html   16 Aug 2019 22:12:26 -
@@ -193,7 +193,7 @@
 
  MicroBlace
Manufacturer: Xilinx
-   http://www.xilinx.com/support/documentation/sw_manuals/xilinx11/mb_ref_guide.pdf;>
+   https://www.xilinx.com/support/documentation/sw_manuals/xilinx11/mb_ref_guide.pdf;>
  MicroBlaze Processor Reference Guide
GDB includes a simulator for an earlier version of the processor.
  

Re: [RFA] [tree-optimization/80576] Handle non-constant sizes in DSE

[Marc Glisse]

On Fri, 16 Aug 2019, Jeff Law wrote:


On 8/16/19 12:09 PM, Marc Glisse wrote:

On Fri, 16 Aug 2019, Jeff Law wrote:


This patch improves our ability to detect dead stores by handling cases
where the size memcpy, memset, strncpy, etc call is not constant.  This
addresses some, but not all, of the issues in 80576.

The key here is when the size is not constant we can make conservative
decisions that still give us a chance to analyze the code for dead
stores.

Remember that for dead store elimination, we're trying to prove that
given two stores, the second store overwrites (partially or fully) the
same memory locations as the first store.  That makes the first store
either partially or fully dead.

When we encounter the first store, we set up a bitmap of bytes written
by that store (live_bytes).  We then look at subsequent stores and clear
the appropriate entries in the bitmap.

If the first store has a nonconstant length argument we can use the
range of the length argument (max) and the size of the destination
object to make a conservative estimation of how many bytes are written.

For the second store the conservative thing to do for a non-constant
length is to use the minimum of the range of the length argument.


So I guess it won't handle things like

void f(char*p,int n){
  __builtin_memset(p,3,n);
  __builtin_memset(p,7,n);
}

where we know nothing about the length, except that it is the same? Or
do you look at symbolic ranges?


So handling this was slightly uglier than I'd hoped.  I mis-remembered
what we had in an ao_ref.  We have a way to describe constant sizes and
to mark that something was non-constant (size of -1), but not what the
non-constant value was.

I looked at two approaches.  One created a dse_ref structure that had an
embedded ao_ref.  That creates a fair amount of churn.  But it certainly
looks do-able.

The second derived a dse_ref from an ao_ref which allows the vast
majority of the code in tree-ssa-dse.c to just work as-is.  With that in
place it was fairly simply to initialize the new field and check it in a
couple places.  Resulting in:


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

  Deleted dead call: __builtin_memset (p_5(D), 3, _1);

f (char * p, int n)
{
  long unsigned int _1;

;;   basic block 2, loop depth 0, maybe hot
;;prev block 0, next block 1, flags: (NEW, VISITED)
;;pred:   ENTRY (FALLTHRU,EXECUTABLE)
  _1 = (long unsigned int) n_3(D);
  __builtin_memset (p_5(D), 7, _1);
  return;
;;succ:   EXIT (EXECUTABLE)

}



Not sure how useful this will be in practice though.


Oh, I wasn't expecting you to handle it right now...

I've seen this kind of thing (not necessarily with memset, memcpy was 
probably involved as well) a few times, enough that it immediately came to 
mind when I saw the title of your message. There are probably traces in 
bugzilla, although I don't think there is a convenient search query to 
find them. I found PR 79716 that seems related at least, but not what I 
was looking for.


--
Marc Glisse

[committed] Fix SH test compromised by recent forwprop changes

[Jeff Law]

My tester threw regressions for the SH targets overnight.

This was bisect down to this patch:


commit ce1d21d251fee17a70ee9f8ff9e57620126f28c7 (refs/bisect/bad)
Author: rguenth 
Date:   Fri Aug 16 09:27:34 2019 +

2019-08-16  Richard Biener  

* tree-ssa-forwprop.c (simplify_builtin_call): Do not remove
stmt at gsi_p, instead replace it with a NOP removed later.
(pass_forwprop::execute): Fully propagate lattice, DCE stmts
that became dead because of that.

fortran/
* trans-intrinsic.c (gfc_conv_intrinsic_findloc): Initialize
forward_branch to avoid bogus uninitialized warning.

* gcc.dg/tree-ssa/forwprop-31.c: Adjust.


git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@274563
138bc75d-0d04-0410-961f-82ee72b054a4

After looking at the .optimized dump as well as the resulting assembly
it's quite clear that after Richi's change the resulting code is better
(smaller & fewer branches).

The test still seems useful and can be restored to testing its original
intent by disabling forwprop.  So that's what I've done.

Installing on the trunk momentarily.

Jeff
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index b9a752cedff..408897e47f4 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,7 @@
+2019-08-16  Jeff Law  
+
+   * gcc.target/sh/pr54236-6.c: Use -fno-tree-forwprop.
+
 2019-08-16  Martin Sebor  
 
* gcc.dg/struct-ret-1.c: Enable on all targets.
diff --git a/gcc/testsuite/gcc.target/sh/pr54236-6.c 
b/gcc/testsuite/gcc.target/sh/pr54236-6.c
index cc477927d2a..93bfeb36951 100644
--- a/gcc/testsuite/gcc.target/sh/pr54236-6.c
+++ b/gcc/testsuite/gcc.target/sh/pr54236-6.c
@@ -9,7 +9,7 @@
 */
 
 /* { dg-do compile }  */
-/* { dg-options "-O2" }  */
+/* { dg-options "-O2 -fno-tree-forwprop" }  */
 
 /* { dg-final { scan-assembler-times {tst  #1,r0} 1 } }  */
 /* { dg-final { scan-assembler-times {subc r} 1 } }  */

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

[Marek Polacek]

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, and since in this testcase the
decl is type-dependent, doing something similiar to the fix for c++/85827 is
out too.

One option is the below, still don't instantiate anything in such a dead
clause, but mark any use of a decl in it as a read.  Which means that "set but
unused" won't be warned about, but that's still better than bogus warnings.
(Clang doesn't seem to handle that, either.)
retrieve_local_specialization is there because we need to set the flag on the
aready instantiated PARM/VAR_DECL, not the template itself.

The good news is that when a param/decl is really unused, we still get the
warning.  And it works with lambdas too.  Better ideas, anyone?
(If anyone's wondering, constexpr function templates don't have this problem.)

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

2019-08-16  Marek Polacek  

PR c++/81676 - bogus -Wunused warnings in constexpr if.
* pt.c (maybe_mark_exp_read_r): New function.
(tsubst_expr) : Call it for an uninstantiated THEN_CLAUSE
and ELSE_CLAUSE.

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

diff --git gcc/cp/pt.c gcc/cp/pt.c
index 17585119bce..e146ad38443 100644
--- gcc/cp/pt.c
+++ gcc/cp/pt.c
@@ -16995,6 +16995,23 @@ lookup_init_capture_pack (tree decl)
   return r;
 }
 
+/* Callback for cp_walk_tree to mark all instantiations of {VAR,PARM}_DECLs
+   in a tree as read.  The point is to mark the parameters or local variables
+   of a template function as read to prevent various -Wunused warnings.  */
+
+static tree
+maybe_mark_exp_read_r (tree *tp, int *, void *)
+{
+  tree t = *tp;
+  if (VAR_P (t) || TREE_CODE (t) == PARM_DECL)
+{
+  tree s = retrieve_local_specialization (t);
+  if (s)
+   mark_exp_read (s);
+}
+  return NULL_TREE;
+}
+
 /* Like tsubst_copy for expressions, etc. but also does semantic
processing.  */
 
@@ -17282,7 +17299,10 @@ tsubst_expr (tree t, tree args, tsubst_flags_t 
complain, tree in_decl,
  break;
}
   if (IF_STMT_CONSTEXPR_P (t) && integer_zerop (tmp))
-   /* Don't instantiate the THEN_CLAUSE. */;
+   /* Don't instantiate the THEN_CLAUSE.  But mark the PARM_DECLs and
+  VAR_DECLs used in the THEN_CLAUSE as read, so as to suppress
+  -Wunused-but-set-{variable,parameter} warnings.  */
+   cp_walk_tree (_CLAUSE (t), maybe_mark_exp_read_r, NULL, NULL);
   else
{
  tree folded = fold_non_dependent_expr (tmp, complain);
@@ -17296,7 +17316,10 @@ tsubst_expr (tree t, tree args, tsubst_flags_t 
complain, tree in_decl,
   finish_then_clause (stmt);
 
   if (IF_STMT_CONSTEXPR_P (t) && integer_nonzerop (tmp))
-   /* Don't instantiate the ELSE_CLAUSE. */;
+   /* Don't instantiate the ELSE_CLAUSE.  But mark the PARM_DECLs and
+  VAR_DECLs used in the ELSE_CLAUSE as read, so as to suppress
+  -Wunused-but-set-{variable,parameter} warnings.  */
+   cp_walk_tree (_CLAUSE (t), maybe_mark_exp_read_r, NULL, NULL);
   else if (ELSE_CLAUSE (t))
{
  tree folded = fold_non_dependent_expr (tmp, complain);
diff --git gcc/testsuite/g++.dg/cpp1z/constexpr-if30.C 
gcc/testsuite/g++.dg/cpp1z/constexpr-if30.C
new file mode 100644
index 000..26e0c6f39a6
--- /dev/null
+++ gcc/testsuite/g++.dg/cpp1z/constexpr-if30.C
@@ -0,0 +1,79 @@
+// PR c++/81676 - bogus -Wunused warnings in constexpr if.
+// { dg-do compile { target c++17 } }
+// { dg-options "-Wunused-variable -Wunused-parameter" }
+
+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 

Re: [RFA] [tree-optimization/80576] Handle non-constant sizes in DSE

[Jeff Law]

On 8/16/19 12:09 PM, Marc Glisse wrote:
> On Fri, 16 Aug 2019, Jeff Law wrote:
> 
>> This patch improves our ability to detect dead stores by handling cases
>> where the size memcpy, memset, strncpy, etc call is not constant.  This
>> addresses some, but not all, of the issues in 80576.
>>
>> The key here is when the size is not constant we can make conservative
>> decisions that still give us a chance to analyze the code for dead
>> stores.
>>
>> Remember that for dead store elimination, we're trying to prove that
>> given two stores, the second store overwrites (partially or fully) the
>> same memory locations as the first store.  That makes the first store
>> either partially or fully dead.
>>
>> When we encounter the first store, we set up a bitmap of bytes written
>> by that store (live_bytes).  We then look at subsequent stores and clear
>> the appropriate entries in the bitmap.
>>
>> If the first store has a nonconstant length argument we can use the
>> range of the length argument (max) and the size of the destination
>> object to make a conservative estimation of how many bytes are written.
>>
>> For the second store the conservative thing to do for a non-constant
>> length is to use the minimum of the range of the length argument.
> 
> So I guess it won't handle things like
> 
> void f(char*p,int n){
>   __builtin_memset(p,3,n);
>   __builtin_memset(p,7,n);
> }
> 
> where we know nothing about the length, except that it is the same? Or
> do you look at symbolic ranges?

So handling this was slightly uglier than I'd hoped.  I mis-remembered
what we had in an ao_ref.  We have a way to describe constant sizes and
to mark that something was non-constant (size of -1), but not what the
non-constant value was.

I looked at two approaches.  One created a dse_ref structure that had an
embedded ao_ref.  That creates a fair amount of churn.  But it certainly
looks do-able.

The second derived a dse_ref from an ao_ref which allows the vast
majority of the code in tree-ssa-dse.c to just work as-is.  With that in
place it was fairly simply to initialize the new field and check it in a
couple places.  Resulting in:

> ; Function f (f, funcdef_no=0, decl_uid=1909, cgraph_uid=1, symbol_order=0)
> 
>   Deleted dead call: __builtin_memset (p_5(D), 3, _1);
> 
> f (char * p, int n)
> {
>   long unsigned int _1;
> 
> ;;   basic block 2, loop depth 0, maybe hot
> ;;prev block 0, next block 1, flags: (NEW, VISITED)
> ;;pred:   ENTRY (FALLTHRU,EXECUTABLE)
>   _1 = (long unsigned int) n_3(D);
>   __builtin_memset (p_5(D), 7, _1);
>   return;
> ;;succ:   EXIT (EXECUTABLE)
> 
> }
> 

Not sure how useful this will be in practice though.

Jeff

[wwwdocs] Remove reference to G77 bugs from bugs/index.html

[Gerald Pfeifer]

Applied.  G77 really is a *while* ago now. ;-)

Gerald

Index: index.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/bugs/index.html,v
retrieving revision 1.129
diff -u -r1.129 index.html
--- index.html  31 Jan 2019 09:32:18 -  1.129
+++ index.html  16 Aug 2019 20:58:05 -
@@ -254,10 +254,6 @@
 In particular, bugs caused by invalid code have a simple work-around:
 fix the code.
 
-G77 bugs were documented under
-https://gcc.gnu.org/onlinedocs/gcc-3.4.6/g77/Trouble.html;>Known
-Causes of Trouble with GNU Fortran in the G77 manual.
-
 
 
 Non-bugs

C++ PATCH to add test for c++/85827

[Marek Polacek]

This one was fixed in r269433

Tested on x86_64-linux, applying to trunk.

2019-08-16  Marek Polacek  

PR c++/85827
* g++.dg/cpp1z/constexpr-if29.C: New test.

diff --git gcc/testsuite/g++.dg/cpp1z/constexpr-if29.C 
gcc/testsuite/g++.dg/cpp1z/constexpr-if29.C
new file mode 100644
index 000..a40912a6fa5
--- /dev/null
+++ gcc/testsuite/g++.dg/cpp1z/constexpr-if29.C
@@ -0,0 +1,28 @@
+// PR c++/85827
+// { dg-do compile { target c++17 } }
+// { dg-options "-Wunused-variable -Wunused-parameter" }
+
+template  int f()
+{
+constexpr bool _1 = N == 1;
+constexpr bool _2 = N == 2;
+constexpr bool _3 = N == 3;
+
+if constexpr (_1) {
+return 5;
+} else if constexpr (_2) {
+return 1;
+} else if constexpr (_3) {
+return 7;
+}
+}
+
+int a() {
+return f<1>();
+}
+int b() {
+return f<2>();
+}
+int c() {
+return f<3>();
+}

[libsanitizer, committed] Reapply r272406.

[Iain Sandoe]

Hi

Somehow, I failed to commit the change to LOCAL_PATCHES for the fix for PR87880 
applied in r272406.

Fixed as below after re-checking on x86_64-linux-gnu, powerpc64-linux-gnu and 
x86_64-darwin.

Also committed the change to LOCAL_PATCHES this time!

thanks
Iain.

libsanitizer/

2019-08-16  Iain Sandoe  

* asan/asan_interceptors.h: Reapply r272406.

 diff --git a/libsanitizer/asan/asan_interceptors.h 
b/libsanitizer/asan/asan_interceptors.h
index 155ea4156a..035a84e1a4 100644
--- a/libsanitizer/asan/asan_interceptors.h
+++ b/libsanitizer/asan/asan_interceptors.h
@@ -80,7 +80,12 @@ void InitializePlatformInterceptors();
 #if ASAN_HAS_EXCEPTIONS && !SANITIZER_WINDOWS && !SANITIZER_SOLARIS && \
 !SANITIZER_NETBSD
 # define ASAN_INTERCEPT___CXA_THROW 1
-# define ASAN_INTERCEPT___CXA_RETHROW_PRIMARY_EXCEPTION 1
+# if ! defined(ASAN_HAS_CXA_RETHROW_PRIMARY_EXCEPTION) \
+ || ASAN_HAS_CXA_RETHROW_PRIMARY_EXCEPTION
+#   define ASAN_INTERCEPT___CXA_RETHROW_PRIMARY_EXCEPTION 1
+# else
+#   define ASAN_INTERCEPT___CXA_RETHROW_PRIMARY_EXCEPTION 0
+# endif
 # if defined(_GLIBCXX_SJLJ_EXCEPTIONS) || (SANITIZER_IOS && defined(__arm__))
 #  define ASAN_INTERCEPT__UNWIND_SJLJ_RAISEEXCEPTION 1
 # else


libsanitizer/

2019-08-16  Iain Sandoe  

* LOCAL_PATCHES: Add r274585.


diff --git a/libsanitizer/LOCAL_PATCHES b/libsanitizer/LOCAL_PATCHES
index 4f36773022..4fe34f58b7 100644
--- a/libsanitizer/LOCAL_PATCHES
+++ b/libsanitizer/LOCAL_PATCHES
@@ -1,2 +1,3 @@
 r274427
 r274540
+r274585

Re: [RFA] [tree-optimization/80576] Handle non-constant sizes in DSE

[Jeff Law]

On 8/16/19 12:09 PM, Marc Glisse wrote:
> On Fri, 16 Aug 2019, Jeff Law wrote:
> 
>> This patch improves our ability to detect dead stores by handling cases
>> where the size memcpy, memset, strncpy, etc call is not constant.  This
>> addresses some, but not all, of the issues in 80576.
>>
>> The key here is when the size is not constant we can make conservative
>> decisions that still give us a chance to analyze the code for dead
>> stores.
>>
>> Remember that for dead store elimination, we're trying to prove that
>> given two stores, the second store overwrites (partially or fully) the
>> same memory locations as the first store.  That makes the first store
>> either partially or fully dead.
>>
>> When we encounter the first store, we set up a bitmap of bytes written
>> by that store (live_bytes).  We then look at subsequent stores and clear
>> the appropriate entries in the bitmap.
>>
>> If the first store has a nonconstant length argument we can use the
>> range of the length argument (max) and the size of the destination
>> object to make a conservative estimation of how many bytes are written.
>>
>> For the second store the conservative thing to do for a non-constant
>> length is to use the minimum of the range of the length argument.
> 
> So I guess it won't handle things like
> 
> void f(char*p,int n){
>   __builtin_memset(p,3,n);
>   __builtin_memset(p,7,n);
> }
> 
> where we know nothing about the length, except that it is the same? Or
> do you look at symbolic ranges?
Nope.  I think ao_ref can represent that, so it'd just be a matter of
recording "n" as the length, then verifying that the second call's
length is "n" as well.  That makes the first call dead.  We'd have to
bypass the byte tracking in that case, but I think that's trivial
because we already have a means to do that when the sizes are too large.

> 
>> This doesn't come up a lot in practice.  But it also happens to put some
>> of the infrastructure in place to handle strcpy and strcpy_chk which are
>> needed to fully resolve 80576.
>>
>> Bootstrapped and regression tested on x86, x86_64, ppc64le, ppc64,
>> ppc32, aarch64, sparc, s390x and probably others.  Also verified that
>> the tests work on the various *-elf targets in my tester.
>>
>> OK for the trunk?
> 
> ENOPATCH
Opps.Attached.

Jeff


PR tree-optimizatoin/80576
* tree-ssa-dse.c: Include builtins.h and gimple-fold.h.
(objsize_from_type): New function.
(initialize_ao_ref_for_dse): Add new argument.  Handle non
constant sizes for currently supported builtin calls.
(clear_bytes_written_by): Pass new argument to
initialize_ao_ref_for_dse.
(dse_optimize_redundant_stores): Likewise.
(dse_dom_walker::dse_optimize_stmt): Likewise.  Do not trim
calls if the size is not constant.

* gcc.dg/tree-ssa/ssa-dse-39.c: New test.
* gcc.dg/tree-ssa/ssa-dse-40.c: New test.

diff --git a/gcc/tree-ssa-dse.c b/gcc/tree-ssa-dse.c
index 5b7c4fc6d1a..ae03980f792 100644
--- a/gcc/tree-ssa-dse.c
+++ b/gcc/tree-ssa-dse.c
@@ -36,6 +36,8 @@ along with GCC; see the file COPYING3.  If not see
 #include "params.h"
 #include "alias.h"
 #include "tree-ssa-loop.h"
+#include "builtins.h"
+#include "gimple-fold.h"
 
 /* This file implements dead store elimination.
 
@@ -91,16 +93,47 @@ enum dse_store_status
   DSE_STORE_DEAD
 };
 
+/* OBJECT is an ADDR_EXPR.  If its underlying type is an array,
+   return the size of the array in bytes.  */
+
+static tree
+objsize_from_type (tree object)
+{
+  if (TREE_CODE (object) != ADDR_EXPR)
+return NULL_TREE;
+
+  tree type = TREE_TYPE (object);
+  if (POINTER_TYPE_P (type))
+type = TREE_TYPE (type);
+
+  type = TYPE_MAIN_VARIANT (type);
+
+  if (TREE_CODE (type) == ARRAY_TYPE && !array_at_struct_end_p (object))
+{
+  tree t = TYPE_SIZE_UNIT (type);
+  if (t && TREE_CODE (t) == INTEGER_CST && !integer_zerop (t))
+   return t;
+}
+
+  return NULL_TREE;
+}
+
 /* STMT is a statement that may write into memory.  Analyze it and
initialize WRITE to describe how STMT affects memory.
 
+   If MAXLEN is true, then we are computing how many bytes this write
+   might perform.  When false we are computing the minimum number of
+   bytes this write may perform.  This only matters for calls like
+   strcpy where the number of bytes written is determined by the length
+   of the input string operand.
+
Return TRUE if the the statement was analyzed, FALSE otherwise.
 
It is always safe to return FALSE.  But typically better optimziation
can be achieved by analyzing more statements.  */
 
 static bool
-initialize_ao_ref_for_dse (gimple *stmt, ao_ref *write)
+initialize_ao_ref_for_dse (gimple *stmt, ao_ref *write, bool maxlen)
 {
   /* It's advantageous to handle certain mem* functions.  */
   if (gimple_call_builtin_p (stmt, BUILT_IN_NORMAL))
@@ -117,8 +150,34 @@ initialize_ao_ref_for_dse (gimple *stmt, ao_ref *write)
case 

Re: [RFA] [tree-optimization/80576] Handle non-constant sizes in DSE

[Marc Glisse]

On Fri, 16 Aug 2019, Jeff Law wrote:


This patch improves our ability to detect dead stores by handling cases
where the size memcpy, memset, strncpy, etc call is not constant.  This
addresses some, but not all, of the issues in 80576.

The key here is when the size is not constant we can make conservative
decisions that still give us a chance to analyze the code for dead stores.

Remember that for dead store elimination, we're trying to prove that
given two stores, the second store overwrites (partially or fully) the
same memory locations as the first store.  That makes the first store
either partially or fully dead.

When we encounter the first store, we set up a bitmap of bytes written
by that store (live_bytes).  We then look at subsequent stores and clear
the appropriate entries in the bitmap.

If the first store has a nonconstant length argument we can use the
range of the length argument (max) and the size of the destination
object to make a conservative estimation of how many bytes are written.

For the second store the conservative thing to do for a non-constant
length is to use the minimum of the range of the length argument.


So I guess it won't handle things like

void f(char*p,int n){
  __builtin_memset(p,3,n);
  __builtin_memset(p,7,n);
}

where we know nothing about the length, except that it is the same? Or do 
you look at symbolic ranges?



This doesn't come up a lot in practice.  But it also happens to put some
of the infrastructure in place to handle strcpy and strcpy_chk which are
needed to fully resolve 80576.

Bootstrapped and regression tested on x86, x86_64, ppc64le, ppc64,
ppc32, aarch64, sparc, s390x and probably others.  Also verified that
the tests work on the various *-elf targets in my tester.

OK for the trunk?


ENOPATCH

--
Marc Glisse

Re: [patch] Add guard to build_reconstructed_reference

[Richard Biener]

On August 16, 2019 3:44:36 PM GMT+02:00, Eric Botcazou  
wrote:
>Hi,
>
>this adds a small guard to the new function
>build_reconstructed_reference for 
>broken VIEW_CONVERT_EXPRs.  Users can easily generate these in Ada
>through the 
>generic function Ada.Unchecked_Conversion and they need to be
>accepted...
>
>Tested on x86_64-suse-linux, OK for the mainline?

Ok. 

Richard. 

>
>2019-08-16  Eric Botcazou  
>
>   * tree-sra.c (build_reconstructed_reference): Return NULL_TREE instead
>   of NULL.  Add guard for broken VIEW_CONVERT_EXPRs.
>
>
>2019-08-16  Eric Botcazou  
>
>   * gnat.dg/opt81.ad[sb]: New test.

[RFA] [tree-optimization/80576] Handle non-constant sizes in DSE

[Jeff Law]

This patch improves our ability to detect dead stores by handling cases
where the size memcpy, memset, strncpy, etc call is not constant.  This
addresses some, but not all, of the issues in 80576.

The key here is when the size is not constant we can make conservative
decisions that still give us a chance to analyze the code for dead stores.

Remember that for dead store elimination, we're trying to prove that
given two stores, the second store overwrites (partially or fully) the
same memory locations as the first store.  That makes the first store
either partially or fully dead.

When we encounter the first store, we set up a bitmap of bytes written
by that store (live_bytes).  We then look at subsequent stores and clear
the appropriate entries in the bitmap.

If the first store has a nonconstant length argument we can use the
range of the length argument (max) and the size of the destination
object to make a conservative estimation of how many bytes are written.

For the second store the conservative thing to do for a non-constant
length is to use the minimum of the range of the length argument.

This doesn't come up a lot in practice.  But it also happens to put some
of the infrastructure in place to handle strcpy and strcpy_chk which are
needed to fully resolve 80576.

Bootstrapped and regression tested on x86, x86_64, ppc64le, ppc64,
ppc32, aarch64, sparc, s390x and probably others.  Also verified that
the tests work on the various *-elf targets in my tester.

OK for the trunk?

Jeff

Re: [PATCH] Add --with-static-standard-libraries to the top level

[Jonathan Wakely]

On 13/08/19 09:18 -0600, Tom Tromey wrote:

Jonathan> What I don't understand is why GDB crashes. It should still be able to
Jonathan> catch exceptions from a shared library even if linked to libstdc++.a,
Jonathan> unless the static libstdc++.a is somehow incompatible with the shared
Jonathan> libstdc++.so the shared lib linked to.

Jonathan> Is this on GNU/Linux, or something with a different linking model?

GNU/Linux, Fedora 29 in particular.  I didn't look into why it fails but
the gcc docs specifically mention this problem:

'-static-libgcc'
[...]
There are several situations in which an application should use the
shared 'libgcc' instead of the static version.  The most common of
these is when the application wishes to throw and catch exceptions
across different shared libraries.  In that case, each of the
libraries as well as the application itself should use the shared
'libgcc'.


I was able to reproduce it with a simple test program:

   $ cd /tmp
   $ cat t.cc
   void thrower() {
 throw 23;
   }
   $ g++ -fPIC -shared -o libt.so t.cc
   $ cat a.cc
   extern void thrower ();

   int main () {
 try {
   thrower ();
 } catch (...) {
 }
 return 0;
   }
   $ g++ -o a -static-libgcc -static-libstdc++ a.cc -L$(pwd) -lt
   $ LD_LIBRARY_PATH=$(pwd) ./a
   Aborted (core dumped)


This works perfectly for me on F29, but I have no idea why I get
different results. I'll look into that separately.

Given that the problem does exist, I think being able to disable the
GCC build flags for non-GCC components in the build tree makes sense.
I'm not sure if Jeff deferring to me means I can approve the patch
(normally I can't approve top-level config stuff) but for whatever
it's worth, I approve the patch.

Re: [PATCH] Improve DSE to handle redundant zero initializations.

[Jeff Law]

On 8/13/19 9:09 AM, Matthew Beliveau wrote:
> Hello,
> 
> This should have the changes you all asked for! Let me know if I
> missed anything!
> 
> Thank you,
> Matthew Beliveau
> 
> On Tue, Aug 13, 2019 at 5:15 AM Richard Biener
>  wrote:
>> On Tue, Aug 13, 2019 at 10:18 AM Richard Sandiford
>>  wrote:
>>> Thanks for doing this.
>>>
>>> Matthew Beliveau  writes:
 diff --git gcc/tree-ssa-dse.c gcc/tree-ssa-dse.c
 index 5b7c4fc6d1a..dcaeb8edbfe 100644
 --- gcc/tree-ssa-dse.c
 +++ gcc/tree-ssa-dse.c
 @@ -628,11 +628,8 @@ dse_optimize_redundant_stores (gimple *stmt)
tree fndecl;
if ((is_gimple_assign (use_stmt)
  && gimple_vdef (use_stmt)
 -&& ((gimple_assign_rhs_code (use_stmt) == CONSTRUCTOR
 - && CONSTRUCTOR_NELTS (gimple_assign_rhs1 (use_stmt)) == 0
 - && !gimple_clobber_p (stmt))
 -|| (gimple_assign_rhs_code (use_stmt) == INTEGER_CST
 -&& integer_zerop (gimple_assign_rhs1 (use_stmt)
 +&& initializer_zerop (gimple_op (use_stmt, 1), NULL)
 +&& !gimple_clobber_p (stmt))
 || (gimple_call_builtin_p (use_stmt, BUILT_IN_NORMAL)
 && (fndecl = gimple_call_fndecl (use_stmt)) != NULL
 && (DECL_FUNCTION_CODE (fndecl) == BUILT_IN_MEMSET
 @@ -1027,15 +1024,13 @@ dse_dom_walker::dse_optimize_stmt 
 (gimple_stmt_iterator *gsi)
  {
bool by_clobber_p = false;

 -  /* First see if this store is a CONSTRUCTOR and if there
 -  are subsequent CONSTRUCTOR stores which are totally
 -  subsumed by this statement.  If so remove the subsequent
 -  CONSTRUCTOR store.
 +  /* Check if this store initalizes zero, or some aggregate of zeros,
 +  and check if there are subsequent stores which are subsumed by this
 +  statement.  If so, remove the subsequent store.

This will tend to make fewer calls into memset with longer
arguments.  */
 -  if (gimple_assign_rhs_code (stmt) == CONSTRUCTOR
 -   && CONSTRUCTOR_NELTS (gimple_assign_rhs1 (stmt)) == 0
 +  if (initializer_zerop (gimple_op (stmt, 1), NULL)
 && !gimple_clobber_p (stmt))
   dse_optimize_redundant_stores (stmt);

>>> In addition to Jeff's comment, the original choice of gimple_assign_rhs1
>>> is the preferred way to write this (applies to both hunks).
>> And the !gimple_clobber_p test is now redundant.
>>
>>> Richard
> 
> DSE-2.patch
> 
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
> 
> 2019-08-13  Matthew Beliveau  
> 
>   * tree-ssa-dse.c (dse_optimize_redundant_stores): Improved check to
>   catch more redundant zero initialization cases.
>   (dse_dom_walker::dse_optimize_stmt): Likewise.
>   
>   * gcc.dg/tree-ssa/redundant-assign-zero-1.c: New test.
>   * gcc.dg/tree-ssa/redundant-assign-zero-2.c: New test.
> 
> diff --git gcc/testsuite/gcc.dg/tree-ssa/redundant-assign-zero-1.c 
> gcc/testsuite/gcc.dg/tree-ssa/redundant-assign-zero-1.c
> new file mode 100644
> index 000..b8d01d1644b
> --- /dev/null
> +++ gcc/testsuite/gcc.dg/tree-ssa/redundant-assign-zero-1.c
> @@ -0,0 +1,13 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -fdump-tree-dse-details" } */
> +
> +void blah (char *);
> +
> +void bar ()
> +{
> +  char a[256] = "";
> +  a[3] = 0; 
> +  blah (a);
> +}
> +
> +/* { dg-final { scan-tree-dump-times "Deleted redundant store" 1 "dse1"} } */
> diff --git gcc/testsuite/gcc.dg/tree-ssa/redundant-assign-zero-2.c 
> gcc/testsuite/gcc.dg/tree-ssa/redundant-assign-zero-2.c
> new file mode 100644
> index 000..8cefa6f0cb7
> --- /dev/null
> +++ gcc/testsuite/gcc.dg/tree-ssa/redundant-assign-zero-2.c
> @@ -0,0 +1,18 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -fdump-tree-dse-details" } */
> +
> +#include 
> +
> +void blahd (double *);
> +
> +void fubar ()
> +{
> +  double d;
> +  double *x = 
> +
> +  memset (, 0 , sizeof d);
> +  *x = 0.0;
> +  blahd (x);
> +}
> +
> +/* { dg-final { scan-tree-dump-times "Deleted redundant store" 1 "dse1"} } */
> diff --git gcc/tree-ssa-dse.c gcc/tree-ssa-dse.c
> index 5b7c4fc6d1a..14b66228e1e 100644
> --- gcc/tree-ssa-dse.c
> +++ gcc/tree-ssa-dse.c
> @@ -628,11 +628,7 @@ dse_optimize_redundant_stores (gimple *stmt)
>tree fndecl;
>if ((is_gimple_assign (use_stmt)
>  && gimple_vdef (use_stmt)
> -&& ((gimple_assign_rhs_code (use_stmt) == CONSTRUCTOR
> - && CONSTRUCTOR_NELTS (gimple_assign_rhs1 (use_stmt)) == 0
> - && !gimple_clobber_p (stmt))
> -|| (gimple_assign_rhs_code (use_stmt) == INTEGER_CST
> -&& integer_zerop (gimple_assign_rhs1 (use_stmt)
> +&& initializer_zerop (gimple_assign_rhs1 (use_stmt)))
So I think we over-simplified here.  All we know is that USE_STMT is a
gimple assignment with virtual operands.  We don't know 

Re: types for VR_VARYING

[Jeff Law]

On 8/15/19 10:06 AM, Aldy Hernandez wrote:
> 
> 
> On 8/15/19 7:23 AM, Richard Biener wrote:
>> On Thu, Aug 15, 2019 at 12:40 PM Aldy Hernandez  wrote:
>>>
>>> On 8/14/19 1:37 PM, Jeff Law wrote:
 On 8/13/19 6:39 PM, Aldy Hernandez wrote:
>
>
> On 8/12/19 7:46 PM, Jeff Law wrote:
>> On 8/12/19 12:43 PM, Aldy Hernandez wrote:
>>> This is a fresh re-post of:
>>>
>>> https://gcc.gnu.org/ml/gcc-patches/2019-07/msg6.html
>>>
>>> Andrew gave me some feedback a week ago, and I obviously don't
>>> remember
>>> what it was because I was about to leave on PTO.  However, I do
>>> remember
>>> I addressed his concerns before getting drunk on rum in tropical
>>> islands.
>>>
>> FWIW found a great coffee infused rum while in Kauai last week. 
>> I'm not
>> a coffee fan, but it was wonderful.  The one bottle we brought back
>> isn't going to last until Cauldron and I don't think I can get a
>> special
>> order filled before I leave :(
>
> You must bring some to Cauldron before we believe you. :)
 That's the problem.  The nearest place I can get it is in Vegas and
 there's no distributor in Montreal.   I can special order it in our
 state run stores, but it won't be here in time.

 Of course, I don't mind if you don't believe me.  More for me in that
 case...


>> Is the supports_type_p stuff there to placate the calls from
>> ipa-cp?  I
>> can live with it in the short term, but it really feels like there
>> should be something in the ipa-cp client that avoids this silliness.
>
> I am not happy with this either, but there are various places where
> statements that are !stmt_interesting_for_vrp() are still setting a
> range of VARYING, which is then being ignored at a later time.
>
> For example, vrp_initialize:
>
>     if (!stmt_interesting_for_vrp (phi))
>   {
>     tree lhs = PHI_RESULT (phi);
>     set_def_to_varying (lhs);
>     prop_set_simulate_again (phi, false);
>   }
>
> Also in evrp_range_analyzer::record_ranges_from_stmt(), where we if
> the
> statement is interesting for VRP but extract_range_from_stmt() does
> not
> produce a useful range, we also set a varying for a range we will
> never
> use.  Similarly for a statement that is not interesting in this hunk.
 Ugh.  One could perhaps argue that setting any kind of range in these
 circumstances is silly.   But I suspect it's necessary due to the
 optimistic handling of VR_UNDEFINED in value_range_base::union_helper.
 It's all coming back to me now...


>
> Then there is vrp_prop::visit_stmt() where we also set VARYING for
> types
> that VRP will never handle:
>
>     case IFN_ADD_OVERFLOW:
>     case IFN_SUB_OVERFLOW:
>     case IFN_MUL_OVERFLOW:
>     case IFN_ATOMIC_COMPARE_EXCHANGE:
>   /* These internal calls return _Complex integer type,
>  which VRP does not track, but the immediate uses
>  thereof might be interesting.  */
>   if (lhs && TREE_CODE (lhs) == SSA_NAME)
>     {
>   imm_use_iterator iter;
>   use_operand_p use_p;
>   enum ssa_prop_result res = SSA_PROP_VARYING;
>
>   set_def_to_varying (lhs);
>
> I've adjusted the patch so that set_def_to_varying will set the
> range to
> VR_UNDEFINED if !supports_type_p.  This is a fail safe, as we can't
> really do anything with a nonsensical range.  I just don't want to
> leave
> the range in an indeterminate state.
>
 I think VR_UNDEFINED is unsafe due to value_range_base::union_helper.
 And that's a more general than this patch.  VR_UNDEFINED is _not_ a
 safe
 range to set something to if we can't handle it.  We have to use
 VR_VARYING.

 Why?  See the beginning of value_range_base::union_helper:

  /* VR0 has the resulting range if VR1 is undefined or VR0 is
 varying.  */
  if (vr1->undefined_p ()
  || vr0->varying_p ())
    return *vr0;

  /* VR1 has the resulting range if VR0 is undefined or VR1 is
 varying.  */
  if (vr0->undefined_p ()
  || vr1->varying_p ())
    return *vr1;
 This can get called for something like

     a =  ? name1 : name2;

 If name1 was set to VR_UNDEFINED thinking that VR_UNDEFINED was a safe
 value for something we can't handle, then we'll incorrectly return the
 range for name2.
>>>
>>> I think that if name1 was !supports_type_p, we will have never called
>>> union/intersect.  We will have bailed at some point earlier.  However, I
>>> do see your point about being consistent.
>>>

 VR_UNDEFINED can only be used for the ranges of objects we haven't

Re: [PATCH] PR target/91441 - Turn off -fsanitize=kernel-address if TARGET_ASAN_SHADOW_OFFSET is not implemented.

[Jeff Law]

On 8/15/19 8:45 PM, Kito Cheng wrote:
>  - -fsanitize=kernel-address will call targetm.asan_shadow_offset ()
>at asan_shadow_offset, so it will crash if TARGET_ASAN_SHADOW_OFFSET
>is not implemented, that's mean -fsanitize=kernel-address is not
>supported for target without TARGET_ASAN_SHADOW_OFFSET implementation.
> 
> gcc/ChangeLog:
> 
>   PR target/91441
>   * toplev.c (process_options): Check TARGET_ASAN_SHADOW_OFFSET is
>   implemented for -fsanitize=kernel-address, and merge check logic
>   with -fsanitize=address.
> 
> testsuite/ChangeLog:
> 
>   PR target/91441
>   * gcc.target/riscv/pr91441.c: New.
OK
jeff

Re: [patch] Add guard to build_reconstructed_reference

[Jeff Law]

On 8/16/19 7:44 AM, Eric Botcazou wrote:
> Hi,
> 
> this adds a small guard to the new function build_reconstructed_reference for 
> broken VIEW_CONVERT_EXPRs.  Users can easily generate these in Ada through 
> the 
> generic function Ada.Unchecked_Conversion and they need to be accepted...
> 
> Tested on x86_64-suse-linux, OK for the mainline?
> 
> 
> 2019-08-16  Eric Botcazou  
> 
>   * tree-sra.c (build_reconstructed_reference): Return NULL_TREE instead
>   of NULL.  Add guard for broken VIEW_CONVERT_EXPRs.
> 
> 
> 2019-08-16  Eric Botcazou  
> 
>   * gnat.dg/opt81.ad[sb]: New test.
> 
OK
jeff

Re: [PATCH] Automatics in equivalence statements

[Mark Eggleston]

On 14/08/2019 18:10, Jeff Law wrote:

On 8/14/19 2:45 AM, Mark Eggleston wrote:

I now have commit access.

gcc/fortran

     Jeff Law 
     Mark Eggleston 

     * gfortran.h: Add gfc_check_conflict declaration.
     * symbol.c (check_conflict): Rename cfg_check_conflict and remove
     static.
     * symbol.c (cfg_check_conflict): Remove automatic in equivalence
     conflict check.
     * symbol.c (save_symbol): Add check for in equivalence to stop the
     the save attribute being added.
     * trans-common.c (build_equiv_decl): Add is_auto parameter and
     add !is_auto to condition where TREE_STATIC (decl) is set.
     * trans-common.c (build_equiv_decl): Add local variable is_auto,
     set it true if an atomatic attribute is encountered in the variable
     list.  Call build_equiv_decl with is_auto as an additional parameter.
     flag_dec_format_defaults is enabled.
     * trans-common.c (accumulate_equivalence_attributes) : New subroutine.
     * trans-common.c (find_equivalence) : New local variable dummy_symbol,
     accumulated equivalence attributes from each symbol then check for
     conflicts.

gcc/testsuite

     Mark Eggleston 

     * gfortran.dg/auto_in_equiv_1.f90: New test.
     * gfortran.dg/auto_in_equiv_2.f90: New test.
     * gfortran.dg/auto_in_equiv_3.f90: New test.

OK to commit?

How do I know that I have approval to commit?

Yes, this is OK to commit.  Steve acked it in a private message to me.

Committed as revision 274565.

Normally you'll get an ACK/OK on the public list.  But private ACKs or
ACKs on IRC also count as approval :-)

jeff


--
https://www.codethink.co.uk/privacy.html

[PATCH] PR libstdc++/91371 make std::is_function handle other calling conventions

[Jonathan Wakely]

The x86 attributes such as ms_abi, stdcall, fastcall etc. alter the
function type, which means that functions with one of those attributes
do not match any of the partial specializations of std::is_function.

Rather than duplicating the list for every calling convention, this
adds a fallback to the std::is_function primary template which
identifies other function types. The fallback works by assuming that
all function types fall into one of two categories: referenceable and
abominable. The former can be detected by testing for
function-to-pointer decay, and the latter are non-referenceable types
that are not cv void.

In order to detect referenceable types it's necessary to replace the
current definition of __is_referenceable with one that doesn't depend on
std::is_function, to avoid a cycle. The definition of std::decay can
also be modified to only act on referenceable function types, because
abominable function types do not decay.

PR libstdc++/91371
* include/std/type_traits (__declval, declval, __void_t): Declare
earlier in the file.
(__is_referenceable): Rewrite to not depend on is_function.
(__is_referenceable_function): New trait to identify non-abominable
function types.
(__is_qualified_function): New alias to identify abominable function
types.
(is_function): Make primary template use __is_referenceable_function
and __is_qualified_function to detect function types not covered by
the partial specializations.
(__decay_selector): Use __is_referenceable_function instead of
is_function.
(__decay_selector<_Up, false, true>): Do not use add_pointer.
* testsuite/20_util/bind/91371.cc: New test.
* testsuite/20_util/is_function/91371.cc: New test.
* testsuite/20_util/is_function/value.cc: Check more pointer types.
* testsuite/20_util/is_member_function_pointer/91371.cc: New test.

Tested x86_64-linux. Not committed yet.

I'd like to hear Daniel's thoughts on this approach, as he wrote the
original __is_referenceable trait, and much of .

This new __is_referenceable simply uses void_t to detect whether
forming T& is valid.

The detection for function-to-pointer decay works by checking whether
static_cast(declval()) is well-formed. If T is not a class
type (which could have a conversion operator) and is not nullptr or cv
void*cv (which can convert to nullptr* and cv void*cv* repectively)
then it must be a function.

The detection for abominable function types assumes that all types are
referenceable except functions with cv- or ref-qualifiers and cv void
types. So if it's not referenceable and not void, it's an abominable
function type.


commit 2c8c1d0ef4b9ed6e80abf3694618c0e63859de78
Author: Jonathan Wakely 
Date:   Fri Aug 16 15:03:54 2019 +0100

PR libstdc++/91371 make std::is_function handle other calling conventions

The x86 attributes such as ms_abi, stdcall, fastcall etc. alter the
function type, which means that functions with one of those attributes
do not match any of the partial specializations of std::is_function.

Rather than duplicating the list for every calling convention, add a
fallback to the std::is_function primary template which identifies other
function types. The fallback works by assuming that all function types
fall into one of two categories: referenceable and abominable. The
former can be detected by testing for function-to-pointer decay, and the
latter are non-referenceable types that are not cv void.

In order to detect referenceable types it's necessary to replace the
current definition of __is_referenceable with one that doesn't depend on
std::is_function, to avoid a cycle. The definition of std::decay can
also be modified to only act on referenceable function types, because
abominable function types do not decay.

PR libstdc++/91371
* include/std/type_traits (__declval, declval, __void_t): Declare
earlier in the file.
(__is_referenceable): Rewrite to not depend on is_function.
(__is_referenceable_function): New trait to identify non-abominable
function types.
(__is_qualified_function): New alias to identify abominable function
types.
(is_function): Make primary template use __is_referenceable_function
and __is_qualified_function to detect function types not covered by
the partial specializations.
(__decay_selector): Use __is_referenceable_function instead of
is_function.
(__decay_selector<_Up, false, true>): Do not use add_pointer.
* testsuite/20_util/bind/91371.cc: New test.
* testsuite/20_util/is_function/91371.cc: New test.
* testsuite/20_util/is_function/value.cc: Check more pointer types.
* 

Re: [PATCH 8/9] ifcvt: Handle swap-style idioms differently.

[Richard Sandiford]

Robin Dapp  writes:
>> Looks like a nice optimisation, but could we just test whether the
>> destination of a set isn't live on exit from the then block?  I think
>> we could do that on the fly during the main noce_convert_multiple_sets
>> loop.
>
> I included this locally along with the rest of the remarks. Any comments
> on the rest/bulk of the patch (the part trying to compare costs of both
> cmovs "types")?

I'm still a bit worried about the overlap between the expanded
noce_convert_multiple_sets and cond_move_process_if_block (5/9).
It seems like we're making noce_convert_multiple_set handle most of
the conditional move cases that cond_move_process_if_block can handle.
But like you say, noce_convert_multiple_set is still restricted to
half-diamonds, whereas cond_move_process_if_block can handle full
diamonds.

3/9, 4/9 and 8/9 seems like good independent improvements.
But for 5/9, 6/9 and 7/9, it looks to me like it would be better
to improve cond_move_process_if_block so that it handles all the
conditional move cases you're targetting.

Definitely welcome other opinions though. :-)

Thanks,
Richard

Re: [PATCH] [LRA] Fix wrong-code PR 91109 take 2

[Vladimir Makarov]

On 2019-08-16 11:06 a.m., Vladimir Makarov wrote:


On 2019-08-15 3:46 p.m., Bernd Edlinger wrote:

Hi,

as discussed in the PR 91109 audit trail,
my previous patch missed a case where no spilling is necessary,
but the re-materialized instruction has now scratch regs without
a hard register assignment.  And thus the LRA pass falls out of
the loop pre-maturely.

Fixed by checking for scratch regs with no assignment
and continuing the loop in that case.


Boot-strapped and reg-tested on x86_64-pc-linux-gnu and 
arm-linux-gnueabihf.

Is it OK for trunk?


Sorry, I am afraid this patch can make LRA cycle forever in some cases.

The reason for this is an existing pattern (scratch "r,X").  So if LRA 
makes a choice for the 2nd alternative, it will be a former spilled 
scratch (such spilled pseudo is changed into scratch at the end of 
LRA).  In this case the constraint subpass satisfies all constraints. 
There are no changes at all but because there are spilled (not in 
remat subpass) former scratches we continue the loop.


I guess you need something more accurate interaction with remat subpass.


Sorry, I missed that your new code is run only if remat returns true 
which means some changes in it.  It was not seen in the patch context.  
So there will be no cycling as remat at some point stop to do changes.


The patch is ok for trunk and gcc-9 branch.

Thank you, Bernd

Re: Add TIGERLAKE and COOPERLAKE to GCC

[Uros Bizjak]

On Fri, Aug 16, 2019 at 5:01 PM H.J. Lu  wrote:
>
> On Fri, Aug 16, 2019 at 5:53 AM Uros Bizjak  wrote:
> >
> > On Fri, Aug 16, 2019 at 6:10 AM Cui, Lili  wrote:
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: H.J. Lu [mailto:hjl.to...@gmail.com]
> > > > Sent: Friday, August 16, 2019 6:02 AM
> > > > To: Jeff Law 
> > > > Cc: Cui, Lili ; Uros Bizjak ; GCC
> > > > Patches ; Zhang, Annita
> > > > ; Xiao, Wei3 ; Liu, Hongtao
> > > > ; Wang, Hongyu ;
> > > > Castillo, Jason M 
> > > > Subject: Re: Add TIGERLAKE and COOPERLAKE to GCC
> > > >
> > > > On Wed, Aug 14, 2019 at 11:04 AM Jeff Law  wrote:
> > > > >
> > > > > On 8/14/19 1:38 AM, Cui, Lili wrote:
> > > > > > Resend this mail for GCC Patches rejected my message, thanks.
> > > > > >
> > > > > > -Original Message-
> > > > > >
> > > > > > Hi Uros and all:
> > > > > >
> > > > > > This patch is about to add TIGERLAKE and COOPERLAKE to GCC.
> > > > > > TIGERLAKE is based on ICELAKE_CLIENT and plus new ISA
> > > > MOVEDIRI/MOVDIR64B/AVX512VP2INTERSECT.
> > > > > > COOPERLAKE is based on CASCADELAKE and plus new ISA AVX512BF16.
> > > > > >
> > > > > > Bootstrap is ok, and no regressions for i386/x86-64 testsuite.
> > > > > >
> > > > > > Changelog:
> > > > > > gcc/
> > > > > >   * common/config/i386/i386-common.c
> > > > > >   (processor_names): Add tigerlake and cooperlake.
> > > > > >   (processor_alias_table): Add tigerlake and cooperlake.
> > > > > >   * config.gcc: Add -march=tigerlake and cooperlake.
> > > > > >   * config/i386/driver-i386.c
> > > > > >(host_detect_local_cpu): Detect tigerlake and cooperlake.
> > > > > >   * config/i386/i386-builtins.c
> > > > > >   (processor_model) : Add M_INTEL_COREI7_TIGERLAKE and
> > > > M_INTEL_COREI7_COOPERLAKE.
> > > > > >   (arch_names_table): Add tigerlake and cooperlake.
> > > > > >   (get_builtin_code_for_version) : Handle PROCESSOR_TIGERLAKE 
> > > > > > and
> > > > PROCESSOR_COOPERLAKE.
> > > > > >   * config/i386/i386-c.c
> > > > > >   (ix86_target_macros_internal): Handle tigerlake and 
> > > > > > cooperlake.
> > > > > >   (ix86_target_macros_internal): Handle
> > > > OPTION_MASK_ISA_AVX512VP2INTERSECT.
> > > > > >   * config/i386/i386-options.c
> > > > > >   (m_TIGERLAKE)  : Define.
> > > > > >   (m_COOPERLAKE) : Ditto.
> > > > > >   (m_CORE_AVX512): Ditto.
> > > > > >   (processor_cost_table): Add cascadelake.
> > > > > >   (ix86_target_string)  : Handle -mavx512vp2intersect.
> > > > > >   (ix86_valid_target_attribute_inner_p) : Handle 
> > > > > > avx512vp2intersect.
> > > > > >   (ix86_option_override_internal): Hadle PTA_SHSTK, PTA_MOVDIRI,
> > > > > >PTA_MOVDIR64B, PTA_AVX512VP2INTERSECT.
> > > > > >   * config/i386/i386.h
> > > > > >   (ix86_size_cost) : Define TARGET_TIGERLAKE and
> > > > TARGET_COOPERLAKE.
> > > > > >   (processor_type) : Add PROCESSOR_TIGERLAKE and
> > > > PROCESSOR_COOPERLAKE.
> > > > > >   (PTA_SHSTK) : Define.
> > > > > >   (PTA_MOVDIRI): Ditto.
> > > > > >   (PTA_MOVDIR64B): Ditto.
> > > > > >   (PTA_COOPERLAKE) : Ditto.
> > > > > >   (PTA_TIGERLAKE)  : Ditto.
> > > > > >   (TARGET_AVX512VP2INTERSECT) : Ditto.
> > > > > >   (TARGET_AVX512VP2INTERSECT_P(x)) : Ditto.
> > > > > >   (processor_type) : Add PROCESSOR_TIGERLAKE and
> > > > PROCESSOR_COOPERLAKE.
> > > > > >   * doc/extend.texi: Add tigerlake and cooperlake.
> > > > > >
> > > > > > gcc/testsuite/
> > > > > >   * gcc.target/i386/funcspec-56.inc: Handle new march.
> > > > > >   * g++.target/i386/mv16.C: Handle new march
> > > > > >
> > > > > > libgcc/
> > > > > >   * config/i386/cpuinfo.h: Add INTEL_COREI7_TIGERLAKE and
> > > > INTEL_COREI7_COOPERLAKE.
> > > > > >
> > > > > ENOPATCH
> > > > >
> > > > > Note that HJ's reworking of the cost tables may require this patch to
> > > > > change for the trunk.
> > > > >
> > > >
> > > > Yes, I have checked in my patch.  Please rebase.
> > >
> > > Done, there is no conflict , thanks.
> >
> > @@ -863,36 +863,45 @@ const char *host_detect_local_cpu (int argc,
> > const char **argv)
> >if (arch)
> >  {
> >/* This is unknown family 0x6 CPU.  */
> > -  /* Assume Ice Lake Server.  */
> > -  if (has_wbnoinvd)
> > - cpu = "icelake-server";
> > -  /* Assume Ice Lake.  */
> > -  else if (has_gfni)
> > - cpu = "icelake-client";
> > -  /* Assume Cannon Lake.  */
> > -  else if (has_avx512vbmi)
> > - cpu = "cannonlake";
> > -  /* Assume Knights Mill.  */
> > -  else if (has_avx5124vnniw)
> > - cpu = "knm";
> > -  /* Assume Knights Landing.  */
> > -  else if (has_avx512er)
> > - cpu = "knl";
> > -  /* Assume Skylake with AVX-512.  */
> > -  else if (has_avx512f)
> > - cpu = "skylake-avx512";
> > -  /* Assume Skylake.  */
> > -  else if (has_clflushopt)
> > - cpu = "skylake";
> > -  /* Assume Broadwell.  */
> > -  else if (has_adx)
> > 

Re: [PATCH] [LRA] Fix wrong-code PR 91109 take 2

[Vladimir Makarov]

On 2019-08-15 3:46 p.m., Bernd Edlinger wrote:

Hi,

as discussed in the PR 91109 audit trail,
my previous patch missed a case where no spilling is necessary,
but the re-materialized instruction has now scratch regs without
a hard register assignment.  And thus the LRA pass falls out of
the loop pre-maturely.

Fixed by checking for scratch regs with no assignment
and continuing the loop in that case.


Boot-strapped and reg-tested on x86_64-pc-linux-gnu and arm-linux-gnueabihf.
Is it OK for trunk?


Sorry, I am afraid this patch can make LRA cycle forever in some cases.

The reason for this is an existing pattern (scratch "r,X").  So if LRA 
makes a choice for the 2nd alternative, it will be a former spilled 
scratch (such spilled pseudo is changed into scratch at the end of 
LRA).  In this case the constraint subpass satisfies all constraints. 
There are no changes at all but because there are spilled (not in remat 
subpass) former scratches we continue the loop.


I guess you need something more accurate interaction with remat subpass.

Re: Add TIGERLAKE and COOPERLAKE to GCC

[H.J. Lu]

On Fri, Aug 16, 2019 at 5:53 AM Uros Bizjak  wrote:
>
> On Fri, Aug 16, 2019 at 6:10 AM Cui, Lili  wrote:
> >
> >
> >
> > > -Original Message-
> > > From: H.J. Lu [mailto:hjl.to...@gmail.com]
> > > Sent: Friday, August 16, 2019 6:02 AM
> > > To: Jeff Law 
> > > Cc: Cui, Lili ; Uros Bizjak ; GCC
> > > Patches ; Zhang, Annita
> > > ; Xiao, Wei3 ; Liu, Hongtao
> > > ; Wang, Hongyu ;
> > > Castillo, Jason M 
> > > Subject: Re: Add TIGERLAKE and COOPERLAKE to GCC
> > >
> > > On Wed, Aug 14, 2019 at 11:04 AM Jeff Law  wrote:
> > > >
> > > > On 8/14/19 1:38 AM, Cui, Lili wrote:
> > > > > Resend this mail for GCC Patches rejected my message, thanks.
> > > > >
> > > > > -Original Message-
> > > > >
> > > > > Hi Uros and all:
> > > > >
> > > > > This patch is about to add TIGERLAKE and COOPERLAKE to GCC.
> > > > > TIGERLAKE is based on ICELAKE_CLIENT and plus new ISA
> > > MOVEDIRI/MOVDIR64B/AVX512VP2INTERSECT.
> > > > > COOPERLAKE is based on CASCADELAKE and plus new ISA AVX512BF16.
> > > > >
> > > > > Bootstrap is ok, and no regressions for i386/x86-64 testsuite.
> > > > >
> > > > > Changelog:
> > > > > gcc/
> > > > >   * common/config/i386/i386-common.c
> > > > >   (processor_names): Add tigerlake and cooperlake.
> > > > >   (processor_alias_table): Add tigerlake and cooperlake.
> > > > >   * config.gcc: Add -march=tigerlake and cooperlake.
> > > > >   * config/i386/driver-i386.c
> > > > >(host_detect_local_cpu): Detect tigerlake and cooperlake.
> > > > >   * config/i386/i386-builtins.c
> > > > >   (processor_model) : Add M_INTEL_COREI7_TIGERLAKE and
> > > M_INTEL_COREI7_COOPERLAKE.
> > > > >   (arch_names_table): Add tigerlake and cooperlake.
> > > > >   (get_builtin_code_for_version) : Handle PROCESSOR_TIGERLAKE and
> > > PROCESSOR_COOPERLAKE.
> > > > >   * config/i386/i386-c.c
> > > > >   (ix86_target_macros_internal): Handle tigerlake and cooperlake.
> > > > >   (ix86_target_macros_internal): Handle
> > > OPTION_MASK_ISA_AVX512VP2INTERSECT.
> > > > >   * config/i386/i386-options.c
> > > > >   (m_TIGERLAKE)  : Define.
> > > > >   (m_COOPERLAKE) : Ditto.
> > > > >   (m_CORE_AVX512): Ditto.
> > > > >   (processor_cost_table): Add cascadelake.
> > > > >   (ix86_target_string)  : Handle -mavx512vp2intersect.
> > > > >   (ix86_valid_target_attribute_inner_p) : Handle 
> > > > > avx512vp2intersect.
> > > > >   (ix86_option_override_internal): Hadle PTA_SHSTK, PTA_MOVDIRI,
> > > > >PTA_MOVDIR64B, PTA_AVX512VP2INTERSECT.
> > > > >   * config/i386/i386.h
> > > > >   (ix86_size_cost) : Define TARGET_TIGERLAKE and
> > > TARGET_COOPERLAKE.
> > > > >   (processor_type) : Add PROCESSOR_TIGERLAKE and
> > > PROCESSOR_COOPERLAKE.
> > > > >   (PTA_SHSTK) : Define.
> > > > >   (PTA_MOVDIRI): Ditto.
> > > > >   (PTA_MOVDIR64B): Ditto.
> > > > >   (PTA_COOPERLAKE) : Ditto.
> > > > >   (PTA_TIGERLAKE)  : Ditto.
> > > > >   (TARGET_AVX512VP2INTERSECT) : Ditto.
> > > > >   (TARGET_AVX512VP2INTERSECT_P(x)) : Ditto.
> > > > >   (processor_type) : Add PROCESSOR_TIGERLAKE and
> > > PROCESSOR_COOPERLAKE.
> > > > >   * doc/extend.texi: Add tigerlake and cooperlake.
> > > > >
> > > > > gcc/testsuite/
> > > > >   * gcc.target/i386/funcspec-56.inc: Handle new march.
> > > > >   * g++.target/i386/mv16.C: Handle new march
> > > > >
> > > > > libgcc/
> > > > >   * config/i386/cpuinfo.h: Add INTEL_COREI7_TIGERLAKE and
> > > INTEL_COREI7_COOPERLAKE.
> > > > >
> > > > ENOPATCH
> > > >
> > > > Note that HJ's reworking of the cost tables may require this patch to
> > > > change for the trunk.
> > > >
> > >
> > > Yes, I have checked in my patch.  Please rebase.
> >
> > Done, there is no conflict , thanks.
>
> @@ -863,36 +863,45 @@ const char *host_detect_local_cpu (int argc,
> const char **argv)
>if (arch)
>  {
>/* This is unknown family 0x6 CPU.  */
> -  /* Assume Ice Lake Server.  */
> -  if (has_wbnoinvd)
> - cpu = "icelake-server";
> -  /* Assume Ice Lake.  */
> -  else if (has_gfni)
> - cpu = "icelake-client";
> -  /* Assume Cannon Lake.  */
> -  else if (has_avx512vbmi)
> - cpu = "cannonlake";
> -  /* Assume Knights Mill.  */
> -  else if (has_avx5124vnniw)
> - cpu = "knm";
> -  /* Assume Knights Landing.  */
> -  else if (has_avx512er)
> - cpu = "knl";
> -  /* Assume Skylake with AVX-512.  */
> -  else if (has_avx512f)
> - cpu = "skylake-avx512";
> -  /* Assume Skylake.  */
> -  else if (has_clflushopt)
> - cpu = "skylake";
> -  /* Assume Broadwell.  */
> -  else if (has_adx)
> - cpu = "broadwell";
> -  else if (has_avx2)
> +  if (has_avx)
> +  {
> + /* Assume Tiger Lake */
> + if (has_avx512vp2intersect)
> +  cpu = "tigerlake";
> + /* Assume Cooper Lake */
> + else if (has_avx512bf16)
> +  cpu = "cooperlake";
> + /* Assume Ice Lake Server.  */
> + else if (has_wbnoinvd)
> +  cpu = 

Re: [PATCH] Adding _Dependent_ptr type qualifier in C part 1/3

[Paul E. McKenney]

And please see the following URL for an update:

http://www.rdrop.com/~paulmck/submission/D%20_Dependent_ptr%20to%20simplify%20carries%20a%20dependency.pdf

This adds a description of conversions, warnings, and patches.

Thanx, Paul

On Sun, Aug 04, 2019 at 04:11:12PM -0700, Paul E. McKenney wrote:
> Good points!
> 
> On the type-qualifier interactions, here is an initial list.  Thoughts?
> 
>   Thanx, Paul
> 
> _Alignas: Dependency-breaking optimizations would be avoided, and the
> variable would be aligned as specified.
> 
> _Atomic: Dependency-breaking optimizations would be avoided, and the
> variable would be accessed using C11 atomics.
> 
> const: This is not particularly useful for variables with static storage
> duration because compile-time initialization does not require dependency
> ordering, but then again, use of _Dependent_ptr on such variables is
> suspect to begin with.  Otherwise, the const _Dependent_ptr variable
> would normally be initialized from another _Dependent_ptr variable or
> from a memory_order_consume load.  The variable would disallow further
> stores and avoid breaking dependencies.
> 
> extern: Dependency-breaking optimizations would be avoided, and the
> variable would be usable within other translation units.  This is
> also an unusual addition to a _Dependent_ptr unless also accompanied by
> _Thread_local because there are no known non-suspect multi-threaded-access
> use cases for _Dependent_ptr.
> 
> register: Dependency-breaking optimizations would be avoided, and the
> compiler would be given a hint to keep the variable in a register.
> 
> restrict: Dependency-breaking optimizations would be avoided, and the
> compiler may assume that the pointed-to object is only accessed through
> this pointer and through pointers derived from it.
> 
> static: Dependency-breaking optimizations would be avoided, and the
> variable would be static.  This is also an unusual addition to a
> _Dependent_ptr unless also accompanied by _Thread_local because there are
> no known non-suspect multi-threaded-access use cases for _Dependent_ptr.
> 
> _Thread_local: The dependency-carrying variable is thread-local, and
> avoids dependency-breaking optimizations.
> 
> volatile: All accesses would be executed as per the abstract machine,
> and dependency-breaking optimizations would be avoided.
> 
> On Fri, Aug 02, 2019 at 08:30:49PM -0600, Martin Sebor wrote:
> > On 8/1/19 9:26 AM, Paul McKenney wrote:
> > >Excellent point, this discussion needs to be made official.
> > >Please see attached for an initial draft of a working paper.
> > >
> > >Thoughts?
> > 
> > The draft is a start but it (obviously) needs a lot of work to cover
> > the constraints and semantics so I'll just comment on the patch in
> > a bit more detail.
> > 
> > Since the feature is being (or will be) proposed to WG14 and could
> > change I would expect it to be only available under -std=c2x and
> > disabled otherwise, so that code that makes use of it does so with
> > the understanding that it's only experimental.  (I just noticed
> > Akshat email with a tweak to the patch.  I'm not sure that issuing
> > a pedantic warning and having the name in the implementation namepace
> > is enough but others (the C FE maintainers) will know better.)
> > 
> > Other than that, I would also expect to see more extensive test
> > coverage, at a minimum to exercise error detection (invalid uses,
> > conversions, etc.).  For example, I see the code that rejects it
> > but no tests for declaring, say, a _Dependent_ptr-qualified integer.
> > What I don't think I see is code that rejects _Dependent_ptr-qualified
> > function pointers (AFAIK, POINTER_TYPE_P evaluates to nonzero for both).
> > Is that intended?  (And if so, what does it mean?)I also see that
> > the new tests look for warnings but it's not clear to me that that's
> > their intent or that the dg-warning directives are being used to
> > "suppress" warnings for issues in the tests.  For instance, this
> > is common:
> > 
> >   rcu_assign_pointer (gp,p);/* { dg-warning
> > "\\\[-Wincompatible-pointer-types]" } */
> > 
> > but neither gp nor p is a  _Dependent_ptr.  (I may be missing
> > the purpose of the compile-only tests.  E.g., the only thing
> > p0190r4_fig10.c seems to be exercising besides that the _Dependent_ptr
> > qualifier is accepted is a couple of warnings, one of which is the one
> > above.)  I would suggest to look at tests for other qualifiers for
> > examples and model the new ones after those.
> > 
> > I'm also wondering how the new qualifier interacts with others like
> > const.  Should all combinations of qualifiers be accepted and do
> > they affect the semantics in any interesting way?  This is probably
> > something to cover in the proposal.
> > 
> > Martin
> > 
> > >
> > >  Thanx, Paul
> > >
> > 

Re: [PATCH] BOZ Documentation update

[Steve Kargl]

On Fri, Aug 16, 2019 at 03:25:03PM +0100, Mark Eggleston wrote:
> In section 6.1.10 BOZ literal constants of the gfortran manual 
> (gfortran.pdf) the final paragraph refers to integer overflow error. As 
> a result of Steve Kargl's work on BOZ constants these errors no longer 
> occur.
> 
> This patch deletes the paragraph. I've checked info, pdf, dvi and HTML 
> documents.
> 
> OK to commit?
> 

Yes.  Thanks for cleaning this up.  I've been off fixing
other issues and forgot about updating the docs.

-- 
Steve

[PATCH, i386]: Introduce uavg3_ceil for 64bit MMX modes

[Uros Bizjak]

Attached patch introduces uavg3_ceil for V8QI and V4HI modes for
TARGET_MMX_WITH_SSE targets.  Also, the patch fixes invalid RTX
generation for SSE and AVX uavg3 patterns.

2019-08-16  Uroš Bizjak  

* config/i386/mmx.md (mmxdoublemode): New mode attribute.
(mmx_uavg3): Macroize expaner from mmx_uavgv8qi3 and
mmx_uavgv4hi3 using MMXMODE12 mode iterator.
(uavg3_ceil): New expander.
* config/i386/sse.md (uavg3_ceil): Use ssedoublemode
mode iterator when creating CONST1_RTX.
(_uavg3): Ditto.
(*_uavg3): Use ssedoublemode
mode iterator for const1_operand predicate.

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

Committed to mainline SVN.

Uros.
Index: config/i386/mmx.md
===
--- config/i386/mmx.md  (revision 274564)
+++ config/i386/mmx.md  (working copy)
@@ -58,6 +58,9 @@
 ;; Mapping from integer vector mode to mnemonic suffix
 (define_mode_attr mmxvecsize [(V8QI "b") (V4HI "w") (V2SI "d") (V1DI "q")])
 
+(define_mode_attr mmxdoublemode
+  [(V8QI "V8HI") (V4HI "V4SI")])
+
 ;
 ;;
 ;; Move patterns
@@ -1948,24 +1951,24 @@
 ;;
 ;
 
-(define_expand "mmx_uavgv8qi3"
-  [(set (match_operand:V8QI 0 "register_operand")
-   (truncate:V8QI
- (lshiftrt:V8HI
-   (plus:V8HI
- (plus:V8HI
-   (zero_extend:V8HI
- (match_operand:V8QI 1 "register_mmxmem_operand"))
-   (zero_extend:V8HI
- (match_operand:V8QI 2 "register_mmxmem_operand")))
- (const_vector:V8HI [(const_int 1) (const_int 1)
- (const_int 1) (const_int 1)
- (const_int 1) (const_int 1)
- (const_int 1) (const_int 1)]))
+(define_expand "mmx_uavg3"
+  [(set (match_operand:MMXMODE12 0 "register_operand")
+   (truncate:MMXMODE12
+ (lshiftrt:
+   (plus:
+ (plus:
+   (zero_extend:
+ (match_operand:MMXMODE12 1 "register_mmxmem_operand"))
+   (zero_extend:
+ (match_operand:MMXMODE12 2 "register_mmxmem_operand")))
+ (match_dup 3))
(const_int 1]
   "(TARGET_MMX || TARGET_MMX_WITH_SSE)
&& (TARGET_SSE || TARGET_3DNOW)"
-  "ix86_fixup_binary_operands_no_copy (PLUS, V8QImode, operands);")
+{
+  operands[3] = CONST1_RTX(mode);
+  ix86_fixup_binary_operands_no_copy (PLUS, mode, operands);
+})
 
 (define_insn "*mmx_uavgv8qi3"
   [(set (match_operand:V8QI 0 "register_operand" "=y,x,Yv")
@@ -1984,7 +1987,7 @@
(const_int 1]
   "(TARGET_MMX || TARGET_MMX_WITH_SSE)
&& (TARGET_SSE || TARGET_3DNOW)
-   && ix86_binary_operator_ok (PLUS, V8QImode, operands)"
+   && !(MEM_P (operands[1]) && MEM_P (operands[2]))"
 {
   switch (which_alternative)
 {
@@ -2013,23 +2016,6 @@
(const_string "*")))
(set_attr "mode" "DI,TI,TI")])
 
-(define_expand "mmx_uavgv4hi3"
-  [(set (match_operand:V4HI 0 "register_operand")
-   (truncate:V4HI
- (lshiftrt:V4SI
-   (plus:V4SI
- (plus:V4SI
-   (zero_extend:V4SI
- (match_operand:V4HI 1 "register_mmxmem_operand"))
-   (zero_extend:V4SI
- (match_operand:V4HI 2 "register_mmxmem_operand")))
- (const_vector:V4SI [(const_int 1) (const_int 1)
- (const_int 1) (const_int 1)]))
-   (const_int 1]
-  "(TARGET_MMX || TARGET_MMX_WITH_SSE)
-   && (TARGET_SSE || TARGET_3DNOW_A)"
-  "ix86_fixup_binary_operands_no_copy (PLUS, V4HImode, operands);")
-
 (define_insn "*mmx_uavgv4hi3"
   [(set (match_operand:V4HI 0 "register_operand" "=y,x,Yv")
(truncate:V4HI
@@ -2045,7 +2031,7 @@
(const_int 1]
   "(TARGET_MMX || TARGET_MMX_WITH_SSE)
&& (TARGET_SSE || TARGET_3DNOW_A)
-   && ix86_binary_operator_ok (PLUS, V4HImode, operands)"
+   && !(MEM_P (operands[1]) && MEM_P (operands[2]))"
   "@
pavgw\t{%2, %0|%0, %2}
pavgw\t{%2, %0|%0, %2}
@@ -2055,6 +2041,24 @@
(set_attr "type" "mmxshft,sseiadd,sseiadd")
(set_attr "mode" "DI,TI,TI")])
 
+(define_expand "uavg3_ceil"
+  [(set (match_operand:MMXMODE12 0 "register_operand")
+   (truncate:MMXMODE12
+ (lshiftrt:
+   (plus:
+ (plus:
+   (zero_extend:
+ (match_operand:MMXMODE12 1 "register_operand"))
+   (zero_extend:
+ (match_operand:MMXMODE12 2 "register_operand")))
+ (match_dup 3))
+   (const_int 1]
+  "TARGET_MMX_WITH_SSE"
+{
+  operands[3] = CONST1_RTX(mode);
+  ix86_fixup_binary_operands_no_copy (PLUS, mode, operands);
+})
+
 (define_insn "mmx_psadbw"
   [(set (match_operand:V1DI 0 "register_operand" "=y,x,Yv")
 (unspec:V1DI [(match_operand:V8QI 1 

[PATCH] PR fortran/68401 Improve allocation error message

[Janne Blomqvist]

Improve the error message that is printed when a memory allocation
fails, by including the location, and the size of the allocation that
failed.

Regtested on x86_64-pc-linux-gnu, Ok for trunk?

(libgomp.fortran/appendix-a/a.28.5.f90 fails, but that seems
unrelated)

gcc/fortran/ChangeLog:

2019-08-16  Janne Blomqvist  

PR fortran/68401
* trans-decl.c (gfc_build_builtin_function_decls): Replace
os_error with os_error_at decl.
* trans.c (trans_runtime_error_vararg): Modify so the error
function decl is passed directly.
(gfc_trans_runtime_error): Pass correct error function decl.
(gfc_trans_runtime_check): Likewise.
(trans_os_error_at): New function.
(gfc_call_malloc): Use trans_os_error_at.
(gfc_allocate_using_malloc): Likewise.
(gfc_call_realloc): Likewise.
* trans.h (gfor_fndecl_os_error): Replace with gfor_fndecl_os_error_at.

libgfortran/ChangeLog:

2019-08-16  Janne Blomqvist  

PR fortran/68401
* gfortran.map: Add GFORTRAN_10 node, add _gfortran_os_error_at
symbol.
* libgfortran.h (os_error_at): New prototype.
* runtime/error.c (os_error_at): New function.
---
 gcc/fortran/trans-decl.c| 12 +++
 gcc/fortran/trans.c | 68 ++---
 gcc/fortran/trans.h |  2 +-
 libgfortran/gfortran.map|  5 +++
 libgfortran/libgfortran.h   |  4 +++
 libgfortran/runtime/error.c | 46 -
 6 files changed, 102 insertions(+), 35 deletions(-)

diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c
index 2a9b852568a..3c6ab60e9b2 100644
--- a/gcc/fortran/trans-decl.c
+++ b/gcc/fortran/trans-decl.c
@@ -102,7 +102,7 @@ tree gfor_fndecl_error_stop_string;
 tree gfor_fndecl_runtime_error;
 tree gfor_fndecl_runtime_error_at;
 tree gfor_fndecl_runtime_warning_at;
-tree gfor_fndecl_os_error;
+tree gfor_fndecl_os_error_at;
 tree gfor_fndecl_generate_error;
 tree gfor_fndecl_set_args;
 tree gfor_fndecl_set_fpe;
@@ -3679,11 +3679,11 @@ gfc_build_builtin_function_decls (void)
void_type_node, 3, pvoid_type_node, integer_type_node,
pchar_type_node);
 
-  gfor_fndecl_os_error = gfc_build_library_function_decl_with_spec (
-   get_identifier (PREFIX("os_error")), ".R",
-   void_type_node, 1, pchar_type_node);
-  /* The runtime_error function does not return.  */
-  TREE_THIS_VOLATILE (gfor_fndecl_os_error) = 1;
+  gfor_fndecl_os_error_at = gfc_build_library_function_decl_with_spec (
+   get_identifier (PREFIX("os_error_at")), ".RR",
+   void_type_node, -2, pchar_type_node, pchar_type_node);
+  /* The os_error_at function does not return.  */
+  TREE_THIS_VOLATILE (gfor_fndecl_os_error_at) = 1;
 
   gfor_fndecl_set_args = gfc_build_library_function_decl (
get_identifier (PREFIX("set_args")),
diff --git a/gcc/fortran/trans.c b/gcc/fortran/trans.c
index 84511477b39..583f6e3b25b 100644
--- a/gcc/fortran/trans.c
+++ b/gcc/fortran/trans.c
@@ -447,7 +447,7 @@ gfc_build_array_ref (tree base, tree offset, tree decl, 
tree vptr)
arguments and a locus.  */
 
 static tree
-trans_runtime_error_vararg (bool error, locus* where, const char* msgid,
+trans_runtime_error_vararg (tree errorfunc, locus* where, const char* msgid,
va_list ap)
 {
   stmtblock_t block;
@@ -501,18 +501,13 @@ trans_runtime_error_vararg (bool error, locus* where, 
const char* msgid,
   /* Build the function call to runtime_(warning,error)_at; because of the
  variable number of arguments, we can't use build_call_expr_loc 
dinput_location,
  irectly.  */
-  if (error)
-fntype = TREE_TYPE (gfor_fndecl_runtime_error_at);
-  else
-fntype = TREE_TYPE (gfor_fndecl_runtime_warning_at);
+  fntype = TREE_TYPE (errorfunc);
 
   loc = where ? where->lb->location : input_location;
   tmp = fold_build_call_array_loc (loc, TREE_TYPE (fntype),
   fold_build1_loc (loc, ADDR_EXPR,
 build_pointer_type (fntype),
-error
-? gfor_fndecl_runtime_error_at
-: gfor_fndecl_runtime_warning_at),
+errorfunc),
   nargs + 2, argarray);
   gfc_add_expr_to_block (, tmp);
 
@@ -527,7 +522,10 @@ gfc_trans_runtime_error (bool error, locus* where, const 
char* msgid, ...)
   tree result;
 
   va_start (ap, msgid);
-  result = trans_runtime_error_vararg (error, where, msgid, ap);
+  result = trans_runtime_error_vararg (error
+  ? gfor_fndecl_runtime_error_at
+  : gfor_fndecl_runtime_warning_at,
+  where, msgid, ap);
   va_end (ap);
   return result;
 }
@@ -566,8 +564,10 @@ gfc_trans_runtime_check (bool error, bool once, tree cond, 

[PATCH] BOZ Documentation update

[Mark Eggleston]

In section 6.1.10 BOZ literal constants of the gfortran manual 
(gfortran.pdf) the final paragraph refers to integer overflow error. As 
a result of Steve Kargl's work on BOZ constants these errors no longer 
occur.


This patch deletes the paragraph. I've checked info, pdf, dvi and HTML 
documents.


OK to commit?

ChangeLog:

gcc/fortran

    Mark Eggleston  

    * gfortran.texi: Delete paragraph about integer overload errors
    when initialising integer variables with BOZ constants as these
    no longer occur.

--
https://www.codethink.co.uk/privacy.html

>From ac4020d699dac4585c801cd62e34db59d766cfca Mon Sep 17 00:00:00 2001
From: Mark Eggleston 
Date: Thu, 15 Aug 2019 14:34:28 +0100
Subject: [PATCH 3/3] BOZ documentation update

Remove paragraph referring to integer overflow messages as it is no longer
the case.
---
 gcc/fortran/gfortran.texi | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi
index 16be9e05b43..4515b9d02e4 100644
--- a/gcc/fortran/gfortran.texi
+++ b/gcc/fortran/gfortran.texi
@@ -1882,13 +1882,6 @@ with @code{2.0}.) As different compilers implement the extension
 differently, one should be careful when doing bitwise initialization
 of non-integer variables.
 
-Note that initializing an @code{INTEGER} variable with a statement such
-as @code{DATA i/Z''/} will give an integer overflow error rather
-than the desired result of @math{-1} when @code{i} is a 32-bit integer
-on a system that supports 64-bit integers.  The @samp{-fno-range-check}
-option can be used as a workaround for legacy code that initializes
-integers in this manner.
-
 @node Real array indices
 @subsection Real array indices
 @cindex array, indices of type real
-- 
2.11.0

[patch] Add guard to build_reconstructed_reference

[Eric Botcazou]

Hi,

this adds a small guard to the new function build_reconstructed_reference for 
broken VIEW_CONVERT_EXPRs.  Users can easily generate these in Ada through the 
generic function Ada.Unchecked_Conversion and they need to be accepted...

Tested on x86_64-suse-linux, OK for the mainline?


2019-08-16  Eric Botcazou  

* tree-sra.c (build_reconstructed_reference): Return NULL_TREE instead
of NULL.  Add guard for broken VIEW_CONVERT_EXPRs.


2019-08-16  Eric Botcazou  

* gnat.dg/opt81.ad[sb]: New test.

-- 
Eric BotcazouIndex: tree-sra.c
===
--- tree-sra.c	(revision 274487)
+++ tree-sra.c	(working copy)
@@ -1812,11 +1812,15 @@ build_reconstructed_reference (location_t, tree ba
   while (!types_compatible_p (TREE_TYPE (expr), TREE_TYPE (base)))
 {
   if (!handled_component_p (expr))
-	return NULL;
+	return NULL_TREE;
   prev_expr = expr;
   expr = TREE_OPERAND (expr, 0);
 }
 
+  /* Guard against broken VIEW_CONVERT_EXPRs...  */
+  if (!prev_expr)
+return NULL_TREE;
+
   TREE_OPERAND (prev_expr, 0) = base;
   tree ref = unshare_expr (model->expr);
   TREE_OPERAND (prev_expr, 0) = expr;
package Opt81 is

  type String_Access is access String;

  type Rec is record
A : String_Access;
  end record;

  for Rec use record
A at 0 range 0 .. (Standard'Word_Size - 1);
  end record;

  procedure Copy(From, To : Rec);

end Opt81;
-- { dg-do compile }
-- { dg-options "-O -gnatws" }

with Unchecked_Conversion;

package body Opt81 is

  procedure Copy (From, To : Rec) is
Len : constant Natural := From.A.all'Length;
subtype Fixed_String is String (1 .. Len);
type Fixed_String_Access is access Fixed_String;
function To_Fixed is new
  Unchecked_Conversion (Source => String_Access,
Target => Fixed_String_Access);
S : Fixed_String_Access := To_Fixed (To.A);
  begin
S (1 .. Len) := From.A.all;
  end;

end Opt81;

[PATCH] Refactor SCEV DFS finding

[Richard Biener]

This refactors the code to have a more obivous call structure and
to avoid duplicate code.

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

Richard.

2019-08-16  Richard Biener  

* tree-scalar-evolution.c (follow_ssa_edge_expr): Declare.
(follow_ssa_edge_binary): Call follow_ssa_edge_expr instead of
follow_ssa_edge.
(follow_ssa_edge_in_condition_phi_branch): Likewise.
(analyze_evolution_in_loop): Likewise.
(follow_ssa_edge, follow_ssa_edge_in_rhs): Inline into ...
(follow_ssa_edge_expr): ... here.  Refactor code.

Index: gcc/tree-scalar-evolution.c
===
--- gcc/tree-scalar-evolution.c (revision 274563)
+++ gcc/tree-scalar-evolution.c (working copy)
@@ -876,8 +876,8 @@ enum t_bool {
 };
 
 
-static t_bool follow_ssa_edge (class loop *loop, gimple *, gphi *,
-  tree *, int);
+static t_bool follow_ssa_edge_expr (class loop *loop, gimple *, tree, gphi *,
+   tree *, int);
 
 /* Follow the ssa edge into the binary expression RHS0 CODE RHS1.
Return true if the strongly connected component has been found.  */
@@ -912,8 +912,8 @@ follow_ssa_edge_binary (class loop *loop
  (loop->num,
   chrec_convert (type, evol, at_stmt),
   code, rhs1, at_stmt);
- res = follow_ssa_edge
-   (loop, SSA_NAME_DEF_STMT (rhs0), halting_phi, , limit);
+ res = follow_ssa_edge_expr
+   (loop, at_stmt, rhs0, halting_phi, , limit);
  if (res == t_true)
*evolution_of_loop = evol;
  else if (res == t_false)
@@ -922,8 +922,8 @@ follow_ssa_edge_binary (class loop *loop
  (loop->num,
   chrec_convert (type, *evolution_of_loop, at_stmt),
   code, rhs0, at_stmt);
- res = follow_ssa_edge
-   (loop, SSA_NAME_DEF_STMT (rhs1), halting_phi,
+ res = follow_ssa_edge_expr
+   (loop, at_stmt, rhs1, halting_phi,
 evolution_of_loop, limit);
  if (res == t_true)
;
@@ -943,8 +943,8 @@ follow_ssa_edge_binary (class loop *loop
  (loop->num, chrec_convert (type, *evolution_of_loop,
 at_stmt),
   code, rhs1, at_stmt);
- res = follow_ssa_edge
-   (loop, SSA_NAME_DEF_STMT (rhs0), halting_phi,
+ res = follow_ssa_edge_expr
+   (loop, at_stmt, rhs0, halting_phi,
 evolution_of_loop, limit);
  if (res == t_true)
;   
@@ -961,8 +961,8 @@ follow_ssa_edge_binary (class loop *loop
  (loop->num, chrec_convert (type, *evolution_of_loop,
 at_stmt),
   code, rhs0, at_stmt);
- res = follow_ssa_edge
-   (loop, SSA_NAME_DEF_STMT (rhs1), halting_phi,
+ res = follow_ssa_edge_expr
+   (loop, at_stmt, rhs1, halting_phi,
 evolution_of_loop, limit);
  if (res == t_true)
;
@@ -993,8 +993,8 @@ follow_ssa_edge_binary (class loop *loop
  *evolution_of_loop = add_to_evolution
  (loop->num, chrec_convert (type, *evolution_of_loop, at_stmt),
   MINUS_EXPR, rhs1, at_stmt);
- res = follow_ssa_edge (loop, SSA_NAME_DEF_STMT (rhs0), halting_phi,
-evolution_of_loop, limit);
+ res = follow_ssa_edge_expr (loop, at_stmt, rhs0, halting_phi,
+ evolution_of_loop, limit);
  if (res == t_true)
;
  else if (res == t_dont_know)
@@ -1014,140 +1014,6 @@ follow_ssa_edge_binary (class loop *loop
   return res;
 }
 
-/* Follow the ssa edge into the expression EXPR.
-   Return true if the strongly connected component has been found.  */
-
-static t_bool
-follow_ssa_edge_expr (class loop *loop, gimple *at_stmt, tree expr,
- gphi *halting_phi, tree *evolution_of_loop,
- int limit)
-{
-  enum tree_code code = TREE_CODE (expr);
-  tree type = TREE_TYPE (expr), rhs0, rhs1;
-  t_bool res;
-
-  /* The EXPR is one of the following cases:
- - an SSA_NAME,
- - an INTEGER_CST,
- - a PLUS_EXPR,
- - a POINTER_PLUS_EXPR,
- - a MINUS_EXPR,
- - an ASSERT_EXPR,
- - other cases are not yet handled.  */
-
-  switch (code)
-{
-CASE_CONVERT:
-  /* This assignment is under the form "a_1 = (cast) rhs.  */
-  res = follow_ssa_edge_expr (loop, at_stmt, TREE_OPERAND (expr, 0),
- halting_phi, evolution_of_loop, limit);
-  *evolution_of_loop = chrec_convert (type, *evolution_of_loop, at_stmt);
-  break;
-
-case INTEGER_CST:
-  /* This assignment is under the form "a_1 = 

Re: [PATCH 8/9] ifcvt: Handle swap-style idioms differently.

[Robin Dapp]

> Looks like a nice optimisation, but could we just test whether the
> destination of a set isn't live on exit from the then block?  I think
> we could do that on the fly during the main noce_convert_multiple_sets
> loop.

I included this locally along with the rest of the remarks. Any comments
on the rest/bulk of the patch (the part trying to compare costs of both
cmovs "types")?

Regards
 Robin

Re: Add TIGERLAKE and COOPERLAKE to GCC

[Uros Bizjak]

On Fri, Aug 16, 2019 at 6:10 AM Cui, Lili  wrote:
>
>
>
> > -Original Message-
> > From: H.J. Lu [mailto:hjl.to...@gmail.com]
> > Sent: Friday, August 16, 2019 6:02 AM
> > To: Jeff Law 
> > Cc: Cui, Lili ; Uros Bizjak ; GCC
> > Patches ; Zhang, Annita
> > ; Xiao, Wei3 ; Liu, Hongtao
> > ; Wang, Hongyu ;
> > Castillo, Jason M 
> > Subject: Re: Add TIGERLAKE and COOPERLAKE to GCC
> >
> > On Wed, Aug 14, 2019 at 11:04 AM Jeff Law  wrote:
> > >
> > > On 8/14/19 1:38 AM, Cui, Lili wrote:
> > > > Resend this mail for GCC Patches rejected my message, thanks.
> > > >
> > > > -Original Message-
> > > >
> > > > Hi Uros and all:
> > > >
> > > > This patch is about to add TIGERLAKE and COOPERLAKE to GCC.
> > > > TIGERLAKE is based on ICELAKE_CLIENT and plus new ISA
> > MOVEDIRI/MOVDIR64B/AVX512VP2INTERSECT.
> > > > COOPERLAKE is based on CASCADELAKE and plus new ISA AVX512BF16.
> > > >
> > > > Bootstrap is ok, and no regressions for i386/x86-64 testsuite.
> > > >
> > > > Changelog:
> > > > gcc/
> > > >   * common/config/i386/i386-common.c
> > > >   (processor_names): Add tigerlake and cooperlake.
> > > >   (processor_alias_table): Add tigerlake and cooperlake.
> > > >   * config.gcc: Add -march=tigerlake and cooperlake.
> > > >   * config/i386/driver-i386.c
> > > >(host_detect_local_cpu): Detect tigerlake and cooperlake.
> > > >   * config/i386/i386-builtins.c
> > > >   (processor_model) : Add M_INTEL_COREI7_TIGERLAKE and
> > M_INTEL_COREI7_COOPERLAKE.
> > > >   (arch_names_table): Add tigerlake and cooperlake.
> > > >   (get_builtin_code_for_version) : Handle PROCESSOR_TIGERLAKE and
> > PROCESSOR_COOPERLAKE.
> > > >   * config/i386/i386-c.c
> > > >   (ix86_target_macros_internal): Handle tigerlake and cooperlake.
> > > >   (ix86_target_macros_internal): Handle
> > OPTION_MASK_ISA_AVX512VP2INTERSECT.
> > > >   * config/i386/i386-options.c
> > > >   (m_TIGERLAKE)  : Define.
> > > >   (m_COOPERLAKE) : Ditto.
> > > >   (m_CORE_AVX512): Ditto.
> > > >   (processor_cost_table): Add cascadelake.
> > > >   (ix86_target_string)  : Handle -mavx512vp2intersect.
> > > >   (ix86_valid_target_attribute_inner_p) : Handle avx512vp2intersect.
> > > >   (ix86_option_override_internal): Hadle PTA_SHSTK, PTA_MOVDIRI,
> > > >PTA_MOVDIR64B, PTA_AVX512VP2INTERSECT.
> > > >   * config/i386/i386.h
> > > >   (ix86_size_cost) : Define TARGET_TIGERLAKE and
> > TARGET_COOPERLAKE.
> > > >   (processor_type) : Add PROCESSOR_TIGERLAKE and
> > PROCESSOR_COOPERLAKE.
> > > >   (PTA_SHSTK) : Define.
> > > >   (PTA_MOVDIRI): Ditto.
> > > >   (PTA_MOVDIR64B): Ditto.
> > > >   (PTA_COOPERLAKE) : Ditto.
> > > >   (PTA_TIGERLAKE)  : Ditto.
> > > >   (TARGET_AVX512VP2INTERSECT) : Ditto.
> > > >   (TARGET_AVX512VP2INTERSECT_P(x)) : Ditto.
> > > >   (processor_type) : Add PROCESSOR_TIGERLAKE and
> > PROCESSOR_COOPERLAKE.
> > > >   * doc/extend.texi: Add tigerlake and cooperlake.
> > > >
> > > > gcc/testsuite/
> > > >   * gcc.target/i386/funcspec-56.inc: Handle new march.
> > > >   * g++.target/i386/mv16.C: Handle new march
> > > >
> > > > libgcc/
> > > >   * config/i386/cpuinfo.h: Add INTEL_COREI7_TIGERLAKE and
> > INTEL_COREI7_COOPERLAKE.
> > > >
> > > ENOPATCH
> > >
> > > Note that HJ's reworking of the cost tables may require this patch to
> > > change for the trunk.
> > >
> >
> > Yes, I have checked in my patch.  Please rebase.
>
> Done, there is no conflict , thanks.

@@ -863,36 +863,45 @@ const char *host_detect_local_cpu (int argc,
const char **argv)
   if (arch)
 {
   /* This is unknown family 0x6 CPU.  */
-  /* Assume Ice Lake Server.  */
-  if (has_wbnoinvd)
- cpu = "icelake-server";
-  /* Assume Ice Lake.  */
-  else if (has_gfni)
- cpu = "icelake-client";
-  /* Assume Cannon Lake.  */
-  else if (has_avx512vbmi)
- cpu = "cannonlake";
-  /* Assume Knights Mill.  */
-  else if (has_avx5124vnniw)
- cpu = "knm";
-  /* Assume Knights Landing.  */
-  else if (has_avx512er)
- cpu = "knl";
-  /* Assume Skylake with AVX-512.  */
-  else if (has_avx512f)
- cpu = "skylake-avx512";
-  /* Assume Skylake.  */
-  else if (has_clflushopt)
- cpu = "skylake";
-  /* Assume Broadwell.  */
-  else if (has_adx)
- cpu = "broadwell";
-  else if (has_avx2)
+  if (has_avx)
+  {
+ /* Assume Tiger Lake */
+ if (has_avx512vp2intersect)
+  cpu = "tigerlake";
+ /* Assume Cooper Lake */
+ else if (has_avx512bf16)
+  cpu = "cooperlake";
+ /* Assume Ice Lake Server.  */
+ else if (has_wbnoinvd)
+  cpu = "icelake-server";
+ /* Assume Ice Lake.  */
+ else if (has_avx512bitalg)
+  cpu = "icelake-client";
+ /* Assume Cannon Lake.  */
+ else if (has_avx512vbmi)
+  cpu = "cannonlake";
+ /* Assume Knights Mill.  */
+ else if (has_avx5124vnniw)
+  cpu = "knm";
+ /* Assume Knights Landing.  */
+ else if (has_avx512er)
+  cpu = "knl";
+ /* 

[PATCH, alpha]: Update baseline_symbols.txt

[Uros Bizjak]

2019-08-16  Uros Bizjak  

* config/abi/post/alpha-linux-gnu/baseline_symbols.txt: Update.

Tested on alphaev68-linux-gnu, committed to mainline SVN.

Uros.


a.diff.txt.bz2
Description: application/bzip

Re: [PATCH 2/3] Add simplify rules for wrapped binary operations.

[Robin Dapp]

> So - what are you really after? (sorry if I don't remeber, testcase(s)
> are missing
> from this patch)
> 
> To me it seems that 1) loses information if A + CST was done in a signed type
> and we know that overflow doesn't happen because of that.  For the reverse
> transformation we don't.  Btw, if you make A == A' + CST' then
> you get (T)A + CST -> (T)(A' + CST' + CST) which is again trivially handled
> so why do you need both transforms again?

As far as I know the second transformation resulted from some suggestion
to split what was the status back then.  Some things have changed in
match.pd so I checked again:

What I want to achieve in the end is getting rid of
 add r1,-1
 extend r1
 add r1,1.
emitted via doloop.

We have
(1)   (T)(A + CST1) + CST2 -> (T)(A) + (T)CST1 + CST2
(2)   (T)(A) + (T)CST1 + CST2 -> (T)(A) + (T)(CST1 + CST2)
(2better) (A +- CST1) +- CST2 -> A + CST3 (the one Marc mentioned)
(3)   (T)(A) + CST -> T(A + CST)

Considering
 unsigned long foo(unsigned int a)
 {
   if (a > 3 && a < INT_MAX - 100)
 return (unsigned long)(a - 1) + 1;
 }.

This results in s390 assembly
 ahi%r2,-1
 llgfr  %r2,%r2
 aghi   %r2,1
 br %r14.

With the second transform it becomes just
 br %r14
due to

(3) Applying pattern match.pd:2091, gimple-match.c:36515
Matching expression match.pd:111, gimple-match.c:65
(2better) Applying pattern match.pd:1980, gimple-match.c:1011

in evrp.

I believe when I last tried long time ago it would not work that way but
now it does, so (3) is basically an enabler of (2better).  As far as I
can tell (2better) does not make use of range information but I didn't
really now why it works the way it does using (3).


Now for

 unsigned long bar(unsigned int a)
 {
   if (a > 3 && a < INT_MAX - 100)
 return (unsigned long)(a + 1) + ULONG_MAX;
 }

we have

Folded into: _2 = a_7 + 1;
Folding statement: _3 = (long unsigned int) _2;
Folded into: _3 = (long unsigned int) _2;
Folding statement: _6 = _3 + 18446744073709551615;
(1) Applying pattern match.pd:2060, gimple-match.c:36437

in vrp1.

This is not being handled by (2alt) but by (1).  The same applies for
long/int instead of ulong/uint except that we don't need range
information there.

Now, when removing (2) from my patch I run into nasty out-of-mem errors
during bootstrap which I didn't find the reason for yet.  I thought of
something like two match.md patterns that keep reverting the other's
result but I think we have a recursion depth check in place there.

> Also do
> 
>   if ((did_replace || fold_all_stmts)
>  && fold_stmt (...))
>{
>}
> 
> to avoid extra work when folding does nothing.

Does this work like this? We want to mark the statement as modified even
if folding wasn't successful, I guess, and the gimple_set_modified ()
call should not be that expensive? Could do a separate

 if (fold_all_stmts && fold_stmt (...))

of course.

Regards
 Robin

Re: C++ PATCH for c++/91264 - detect modifying const objects in constexpr

[Marek Polacek]

On Thu, Aug 15, 2019 at 08:21:25PM -0400, Jason Merrill wrote:
> On 8/15/19 5:34 PM, Marek Polacek wrote:
> > On Wed, Aug 14, 2019 at 02:50:13PM -0400, Jason Merrill wrote:
> > > On Thu, Aug 8, 2019 at 3:25 PM Marek Polacek  wrote:
> > > > 
> > > > On Thu, Aug 08, 2019 at 11:06:17AM -0400, Jason Merrill wrote:
> > > > > On 8/6/19 3:20 PM, Marek Polacek wrote:
> > > > > > On Mon, Aug 05, 2019 at 03:54:19PM -0400, Jason Merrill wrote:
> > > > > > > On 7/31/19 3:26 PM, Marek Polacek wrote:
> > > > > > > > One of the features of constexpr is that it doesn't allow UB; 
> > > > > > > > and such UB must
> > > > > > > > be detected at compile-time.  So running your code in a context 
> > > > > > > > that requires
> > > > > > > > a constant expression should ensure that the code in question 
> > > > > > > > is free of UB.
> > > > > > > > In effect, constexpr can serve as a sanitizer.  E.g. this 
> > > > > > > > article describes in
> > > > > > > > in more detail:
> > > > > > > > 
> > > > > > > > 
> > > > > > > > [dcl.type.cv]p4 says "Any attempt to modify a const object 
> > > > > > > > during its lifetime
> > > > > > > > results in undefined behavior." However, as the article above 
> > > > > > > > points out, we
> > > > > > > > aren't detecting that case in constexpr evaluation.
> > > > > > > > 
> > > > > > > > This patch fixes that.  It's not that easy, though, because we 
> > > > > > > > have to keep in
> > > > > > > > mind [class.ctor]p5:
> > > > > > > > "A constructor can be invoked for a const, volatile or const 
> > > > > > > > volatile object.
> > > > > > > > const and volatile semantics are not applied on an object under 
> > > > > > > > construction.
> > > > > > > > They come into effect when the constructor for the most derived 
> > > > > > > > object ends."
> > > > > > > > 
> > > > > > > > I handled this by keeping a hash set which tracks objects under 
> > > > > > > > construction.
> > > > > > > > I considered other options, such as going up call_stack, but 
> > > > > > > > that wouldn't
> > > > > > > > work with trivial constructor/op=.  It was also interesting to 
> > > > > > > > find out that
> > > > > > > > the definition of TREE_HAS_CONSTRUCTOR says "When appearing in 
> > > > > > > > a FIELD_DECL,
> > > > > > > > it means that this field has been duly initialized in its 
> > > > > > > > constructor" though
> > > > > > > > nowhere in the codebase do we set TREE_HAS_CONSTRUCTOR on a 
> > > > > > > > FIELD_DECL as far
> > > > > > > > as I can see.  Unfortunately, using this bit proved useless for 
> > > > > > > > my needs here.
> > > > > > > 
> > > > > > > > Also, be mindful of mutable subobjects.
> > > > > > > > 
> > > > > > > > Does this approach look like an appropriate strategy for 
> > > > > > > > tracking objects'
> > > > > > > > construction?
> > > > > > > 
> > > > > > > For scalar objects, we should be able to rely on INIT_EXPR vs. 
> > > > > > > MODIFY_EXPR
> > > > > > > to distinguish between initialization and modification; for class 
> > > > > > > objects, I
> > > > > > 
> > > > > > This is already true: only class object go into the hash set.
> > > > > > 
> > > > > > > wonder about setting a flag on the CONSTRUCTOR after 
> > > > > > > initialization is
> > > > > > > complete to indicate that the value is now constant.
> > > > > > 
> > > > > > But here we're not dealing with CONSTRUCTORs in the gcc sense (i.e. 
> > > > > > exprs with
> > > > > > TREE_CODE == CONSTRUCTOR).  We have a CALL_EXPR like Y::Y ((struct 
> > > > > > Y *) ),
> > > > > > which initializes the object "y".  Setting a flag on the CALL_EXPR 
> > > > > > or its underlying
> > > > > > function decl wouldn't help.
> > > > > > 
> > > > > > Am I missing something?
> > > > > 
> > > > > I was thinking that where in your current patch you call
> > > > > remove_object_under_construction, we could instead mark the object's 
> > > > > value
> > > > > CONSTRUCTOR as immutable.
> > > > 
> > > > Ah, what you meant was to look at DECL_INITIAL of the object we're
> > > > constructing, which could be a CONSTRUCTOR.  Unfortunately, this
> > > > DECL_INITIAL is null (in all the new tests when doing
> > > > remove_object_under_construction), so there's nothing to mark as 
> > > > TREE_READONLY :/.
> > > 
> > > There's a value in ctx->values, isn't there?
> > 
> > Doesn't seem to be the case for e.g.
> > 
> > struct A {
> >int n;
> >constexpr A() : n(1) { n = 2; }
> > };
> > 
> > struct B {
> >const A a;
> >constexpr B(bool b) {
> >  if (b)
> >const_cast(a).n = 3; // { dg-error "modifying a const object" }
> >  }
> > };
> > 
> > constexpr B b(false);
> > static_assert(b.a.n == 2, "");
> > 
> > Here we're constructing "b", its ctx->values->get(new_obj) is initially
> > "{}".  In the middle of constructing "b", we construct "b.a", but that
> > has nothing in ctx->values.
> 
> Right, subobjects 

Re: [PATCH 2/9] operand_equal_p: add support for FIELD_DECL

[Jan Hubicka]

> On Thu, Aug 15, 2019 at 4:17 PM Jan Hubicka  wrote:
> >
> > > On Tue, Aug 6, 2019 at 5:44 PM Martin Liska  wrote:
> > > >
> > > >
> > > > gcc/ChangeLog:
> > >
> > > So I suppose this isn't to call operand_equal_p on two FIELD_DECLs
> > > but to make two COMPONENT_REFs "more equal"?  If so I then
> >
> > yes. The patch originates from my original patchset I believe and it is
> > what ICF does.
> > > I suggest to make this change "local" to the COMPONENT_REF handling.
> > > This also interacts with path-based disambiguation so you want to make
> > > sure to only make things equal here iff it wouldn't change the outcome
> > > of path-based analysis.  Honza?
> >
> > Indeed this can be handled as part of COMPONENT_REF match.
> > Access path oracle here basically checks:
> >  1) that MEM_REF type matches (we want predicate for this)
> >  2) if it finds type match via same_type_for_tbaa and then it applies
> > the assumption about disjointness or overlap
> >
> > So I guess ideally we should
> >
> >  1) do matching part of COMPONENT_REF
> >  2) compare OFFSET, BIT_OFFSET
> > This establishes that the access has same semantics.
> >  3) for -fno-strict-aliasing be happy
> >  4) for -fstrict-aliaisng check if access path applies (we should export
> > predicate from tree-ssa-alias as discussed earlier)
> >  5) compare types by same_type_for_tbaa_p
> 
> Ick.  This smells like a layering violation to me.  IMHO this extended
> equality handling should be handled with the overloading/callback
> and not in native operand_equal_p.  Either on the level of the
> COMPONENT_REF itself (sounds like that would be needed)
> or the FIELD_DECL.  Not sure if the above suggestions make
> it neccessary to look at more than a single COMPONENT_REF/FIELD_DECL
> in the access path.  If so then watch out for quadraticness as operand_equal_p
> traverses a reference chain...

I suppose we want to match whole access paths at once, since only having
the MEM_REF allows one to check whether access path oracle applies to
the given reference or not...

Honza
> 
> Richard.
> 
> > Honza

Re: [PATCH 3/9] operand_equal_p: add support for OBJ_TYPE_REF.

[Jan Hubicka]

> 
> When we compare OBJ_TYPE_REF_TOKEN and OBJ_TYPE_REF_OBJECT
> and they are equal, are there cases where types_same_for_odr returns false?

OBJ_TYPE_REF_OBJECT is pointer to the instance, OBJ_TYPE_REF_TOKEN is
index in the vtable or the type given by obj_ref_type_class.  I guess
one can do something like

 void *ptr;
 ...
 if (cond)
   ((class_a *)ptr)->firstvirtualmethod_of_class_a ();
 else
   ((class_b *)ptr)->firstvirtualmethod_of_class_b ();

Here OBJECT will be always *ptr, TOKEN will be 0, but the actual virtual
method is different. So merging this may lead to invalid
devirtualization at least when the classes are anonymous namespace and
we work out late in compilation that they are not derived.
> 
> I guess we went over this some time ago when talking about value-numbering
> of them.  I realize the devirt machinery use the class type to get at the
> virtual table but since we later expand simply OBJ_TPE_REF_EXPR _that_
> already has the result of the load from the vitual table.
> 
> So - do we need to compare obj_type_ref_class at all?  The worst thing
> that could happen is that devirt no longer can devirtualize after the merging
> but it should never result in "wrong" devirtualization?  So, do we really
> want to inhibit ICF of two equal functions that could be eventually
> devirtualized both but into different direct calls?  Can't this sort of thing

I think it is like with the TBAA info.  I would suggest first implement
tests that preserve correctness of both TBAA and devirt annotations.
Incrementally we can teach ICF to be agressive with -Os and merge anyway
while dropping the metadata (removing OBJ_TYPE_REF or adjusting alias
sets
> happen anyway when you'd factor in IPA-CP and two identical functions
> with indirect calls to a function argument but called with different constant
> args?  And should IPA-CP then not consider cloning after ICF merging
> (not sure how ordering works here).

I am not sure how those are realated. For sure IPA-CP can clone when it
works out that different types are passed to the function and
devirtualize to different calls. But this is bit different - it is about
the type annotation we

Honza
> 
> Richard.
> 
> > Honza
> > >
> > > + }
> > >
> > >
> > > > 2019-07-24  Martin Liska  
> > > >
> > > > * fold-const.c (operand_equal_p): Support OBJ_TYPE_REF.
> > > > * tree.c (add_expr): Hash parts of OBJ_TYPE_REF.
> > > > ---
> > > >  gcc/fold-const.c | 21 +
> > > >  gcc/tree.c   |  9 +
> > > >  2 files changed, 30 insertions(+)
> > > >

Re: [PATCH] Fix PR91469

[Uros Bizjak]

On Fri, Aug 16, 2019 at 1:10 PM Richard Biener  wrote:
>
>
> The following fixes PR91469 where STV replaced uses inside address
> expressions.  The issue arises here because convert_regs is called
> before convert_insns which eventually splits out memory operands.
>
> Bootstrapped / tested on x86_64-unknown-linux-gnu, OK?
>
> Thanks,
> Richard.
>
> 2019-08-16  Richard Biener  
>
> PR target/91469
> * config/i386/i386-features.c
> (general_scalar_chain::replace_with_subreg): Stop at memory operands.
>
> * gcc.target/i386/pr91469-1.c: New testcase.
> * gcc.target/i386/pr91469-2.c: Likewise.

OK.

Thanks,
Uros.

> Index: gcc/config/i386/i386-features.c
> ===
> --- gcc/config/i386/i386-features.c (revision 274536)
> +++ gcc/config/i386/i386-features.c (working copy)
> @@ -613,6 +613,10 @@ general_scalar_chain::replace_with_subre
>if (x == reg)
>  return gen_rtx_SUBREG (vmode, new_reg, 0);
>
> +  /* But not in memory addresses.  */
> +  if (MEM_P (x))
> +return x;
> +
>const char *fmt = GET_RTX_FORMAT (GET_CODE (x));
>int i, j;
>for (i = GET_RTX_LENGTH (GET_CODE (x)) - 1; i >= 0; i--)
> Index: gcc/testsuite/gcc.target/i386/pr91469-1.c
> ===
> --- gcc/testsuite/gcc.target/i386/pr91469-1.c   (nonexistent)
> +++ gcc/testsuite/gcc.target/i386/pr91469-1.c   (working copy)
> @@ -0,0 +1,17 @@
> +/* { dg-do compile } */
> +/* { dg-options "-funroll-loops -O2 -fno-gcse -mavx512vbmi -fno-ivopts 
> -mstv" } */
> +
> +int a, b, e;
> +long long c;
> +int d[6];
> +
> +void fn1() {
> +int i;
> +unsigned f;
> +c = a;
> +f = i;
> +for (; i < b; i++)
> +  if (d[i] > f)
> +   f = d[i];
> +e = f;
> +}
> Index: gcc/testsuite/gcc.target/i386/pr91469-2.c
> ===
> --- gcc/testsuite/gcc.target/i386/pr91469-2.c   (nonexistent)
> +++ gcc/testsuite/gcc.target/i386/pr91469-2.c   (working copy)
> @@ -0,0 +1,11 @@
> +/* { dg-do compile } */
> +/* { dg-options "-Os --param scev-max-expr-size=0 -mavx512vnni 
> -funroll-all-loops" } */
> +
> +int a, b, c, d;
> +int *e;
> +void fn1()
> +{
> +  b = c > 0 ? c : 0;
> +  d += e[b];
> +  a = d > 0 ? d : 0;
> +}

Re: [PATCH] [LRA] Fix wrong-code PR 91109 take 2

[Bernd Edlinger]

On 8/15/19 9:46 PM, Bernd Edlinger wrote:
> Hi,
> 
> as discussed in the PR 91109 audit trail,
> my previous patch missed a case where no spilling is necessary,
> but the re-materialized instruction has now scratch regs without
> a hard register assignment.  And thus the LRA pass falls out of
> the loop pre-maturely.
> 
> Fixed by checking for scratch regs with no assignment
> and continuing the loop in that case.
> 
> 
> Boot-strapped and reg-tested on x86_64-pc-linux-gnu and arm-linux-gnueabihf.
> Is it OK for trunk?
> 

Aehm, sorry, I forgot to ask, but is it also OK for the gcc-9 branch ?

Thanks
Bernd.

[PATCH] Fix PR91469

[Richard Biener]

The following fixes PR91469 where STV replaced uses inside address
expressions.  The issue arises here because convert_regs is called
before convert_insns which eventually splits out memory operands.

Bootstrapped / tested on x86_64-unknown-linux-gnu, OK?

Thanks,
Richard.

2019-08-16  Richard Biener  

PR target/91469
* config/i386/i386-features.c
(general_scalar_chain::replace_with_subreg): Stop at memory operands.

* gcc.target/i386/pr91469-1.c: New testcase.
* gcc.target/i386/pr91469-2.c: Likewise.

Index: gcc/config/i386/i386-features.c
===
--- gcc/config/i386/i386-features.c (revision 274536)
+++ gcc/config/i386/i386-features.c (working copy)
@@ -613,6 +613,10 @@ general_scalar_chain::replace_with_subre
   if (x == reg)
 return gen_rtx_SUBREG (vmode, new_reg, 0);
 
+  /* But not in memory addresses.  */
+  if (MEM_P (x))
+return x;
+
   const char *fmt = GET_RTX_FORMAT (GET_CODE (x));
   int i, j;
   for (i = GET_RTX_LENGTH (GET_CODE (x)) - 1; i >= 0; i--)
Index: gcc/testsuite/gcc.target/i386/pr91469-1.c
===
--- gcc/testsuite/gcc.target/i386/pr91469-1.c   (nonexistent)
+++ gcc/testsuite/gcc.target/i386/pr91469-1.c   (working copy)
@@ -0,0 +1,17 @@
+/* { dg-do compile } */
+/* { dg-options "-funroll-loops -O2 -fno-gcse -mavx512vbmi -fno-ivopts -mstv" 
} */
+
+int a, b, e;
+long long c;
+int d[6];
+
+void fn1() {
+int i;
+unsigned f;
+c = a;
+f = i;
+for (; i < b; i++)
+  if (d[i] > f)
+   f = d[i];
+e = f;
+}
Index: gcc/testsuite/gcc.target/i386/pr91469-2.c
===
--- gcc/testsuite/gcc.target/i386/pr91469-2.c   (nonexistent)
+++ gcc/testsuite/gcc.target/i386/pr91469-2.c   (working copy)
@@ -0,0 +1,11 @@
+/* { dg-do compile } */
+/* { dg-options "-Os --param scev-max-expr-size=0 -mavx512vnni 
-funroll-all-loops" } */
+
+int a, b, c, d;
+int *e;
+void fn1()
+{
+  b = c > 0 ? c : 0;
+  d += e[b];
+  a = d > 0 ? d : 0;
+}

[PATCH 10/N] Use const_tree more in IPA ICF.

[Martin Liška]

Hi.

The patch is a mechanical clean up that changes some
functions and data structures to use const_tree instead
of tree.

Martin
>From 4f8267c542b038ff1c766b57f168fe817d8dbb91 Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Thu, 15 Aug 2019 13:38:51 +0200
Subject: [PATCH 10/10] Use const_tree more in IPA ICF.

gcc/ChangeLog:

2019-08-15  Martin Liska  

	* ipa-icf-gimple.c (func_checker::compare_ssa_name): Use
	const_tree as function argument.
	(func_checker::compare_decl): Likewise.
	(func_checker::operand_equal_p): Likewise.
	(func_checker::compare_variable_decl): Likewise.
	(func_checker::parse_labels): Likewise.
	* ipa-icf-gimple.h: Likewise.
---
 gcc/ipa-icf-gimple.c | 25 +++--
 gcc/ipa-icf-gimple.h | 10 +-
 2 files changed, 16 insertions(+), 19 deletions(-)

diff --git a/gcc/ipa-icf-gimple.c b/gcc/ipa-icf-gimple.c
index 5b0fbc19fc4..990ee046035 100644
--- a/gcc/ipa-icf-gimple.c
+++ b/gcc/ipa-icf-gimple.c
@@ -85,7 +85,7 @@ func_checker::~func_checker ()
 /* Verifies that trees T1 and T2 are equivalent from perspective of ICF.  */
 
 bool
-func_checker::compare_ssa_name (tree t1, tree t2)
+func_checker::compare_ssa_name (const_tree t1, const_tree t2)
 {
   gcc_assert (TREE_CODE (t1) == SSA_NAME);
   gcc_assert (TREE_CODE (t2) == SSA_NAME);
@@ -139,7 +139,7 @@ func_checker::compare_edge (edge e1, edge e2)
come from functions FUNC1 and FUNC2.  */
 
 bool
-func_checker::compare_decl (tree t1, tree t2)
+func_checker::compare_decl (const_tree t1, const_tree t2)
 {
   if (!auto_var_in_fn_p (t1, m_source_func_decl)
   || !auto_var_in_fn_p (t2, m_target_func_decl))
@@ -154,7 +154,7 @@ func_checker::compare_decl (tree t1, tree t2)
 return return_false ();
 
   bool existed_p;
-  tree  = m_decl_map.get_or_insert (t1, _p);
+  const_tree  = m_decl_map.get_or_insert (t1, _p);
   if (existed_p)
 return return_with_debug (slot == t2);
   else
@@ -258,9 +258,6 @@ func_checker::operand_equal_p (const_tree t1, const_tree t2,
   if (TREE_CODE (t1) != TREE_CODE (t2))
 return return_false ();
 
-  tree tree1 = (tree)const_cast (t1);
-  tree tree2 = (tree)const_cast (t2);
-
   switch (TREE_CODE (t1))
 {
 case FUNCTION_DECL:
@@ -268,11 +265,11 @@ func_checker::operand_equal_p (const_tree t1, const_tree t2,
 	 before we start comparing bodies.  */
   return true;
 case VAR_DECL:
-  return return_with_debug (compare_variable_decl (tree1, tree2));
+  return return_with_debug (compare_variable_decl (t1, t2));
 case LABEL_DECL:
   {
-	int *bb1 = m_label_bb_map.get (tree1);
-	int *bb2 = m_label_bb_map.get (tree2);
+	int *bb1 = m_label_bb_map.get (t1);
+	int *bb2 = m_label_bb_map.get (t2);
 	/* Labels can point to another function (non-local GOTOs).  */
 	return return_with_debug (bb1 != NULL && bb2 != NULL && *bb1 == *bb2);
   }
@@ -280,9 +277,9 @@ func_checker::operand_equal_p (const_tree t1, const_tree t2,
 case PARM_DECL:
 case RESULT_DECL:
 case CONST_DECL:
-  return compare_decl (tree1, tree2);
+  return compare_decl (t1, t2);
 case SSA_NAME:
-  return compare_ssa_name (tree1, tree2);
+  return compare_ssa_name (t1, t2);
 default:
   break;
 }
@@ -342,7 +339,7 @@ func_checker::compare_asm_inputs_outputs (tree t1, tree t2)
 /* Verifies that trees T1 and T2 do correspond.  */
 
 bool
-func_checker::compare_variable_decl (tree t1, tree t2)
+func_checker::compare_variable_decl (const_tree t1, const_tree t2)
 {
   bool ret = false;
 
@@ -356,7 +353,7 @@ func_checker::compare_variable_decl (tree t1, tree t2)
 return return_false_with_msg ("DECL_HARD_REGISTER are different");
 
   if (DECL_HARD_REGISTER (t1)
-  && DECL_ASSEMBLER_NAME (t1) != DECL_ASSEMBLER_NAME (t2))
+  && DECL_ASSEMBLER_NAME_RAW (t1) != DECL_ASSEMBLER_NAME_RAW (t2))
 return return_false_with_msg ("HARD REGISTERS are different");
 
   /* Symbol table variables are known to match before we start comparing
@@ -416,7 +413,7 @@ func_checker::parse_labels (sem_bb *bb)
 
   if (glabel *label_stmt = dyn_cast  (stmt))
 	{
-	  tree t = gimple_label_label (label_stmt);
+	  const_tree t = gimple_label_label (label_stmt);
 	  gcc_assert (TREE_CODE (t) == LABEL_DECL);
 
 	  m_label_bb_map.put (t, bb->bb->index);
diff --git a/gcc/ipa-icf-gimple.h b/gcc/ipa-icf-gimple.h
index 8e0f03c1d14..25dff31394b 100644
--- a/gcc/ipa-icf-gimple.h
+++ b/gcc/ipa-icf-gimple.h
@@ -144,7 +144,7 @@ public:
   bool compare_bb (sem_bb *bb1, sem_bb *bb2);
 
   /* Verifies that trees T1 and T2 are equivalent from perspective of ICF.  */
-  bool compare_ssa_name (tree t1, tree t2);
+  bool compare_ssa_name (const_tree t1, const_tree t2);
 
   /* Verification function for edges E1 and E2.  */
   bool compare_edge (edge e1, edge e2);
@@ -188,7 +188,7 @@ public:
   bool compare_gimple_asm (const gasm *s1, const gasm *s2);
 
   /* Verification function for declaration trees T1 and T2.  */
-  bool compare_decl (tree t1, tree t2);
+  bool compare_decl 

Re: [PATCH 6/9] Integrate that for IPA ICF.

[Martin Liška]

I'm sending updated version of the patch.

Note: there are some (tree)const_cast (t2) casting. I've got a clean up
patch for that which will improve it.

Martin
>From 20020586beabf1fc9f7860f46bb0c092f8536539 Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Mon, 10 Jun 2019 14:34:15 +0200
Subject: [PATCH 6/9] Integrate that for IPA ICF.

gcc/ChangeLog:

2019-08-15  Martin Liska  

	* ipa-icf-gimple.c (func_checker::hash_operand): New.
	(func_checker::compare_cst_or_decl): Remove handling
	of FIELD_DECL.
	(func_checker::compare_operand): Transform to ...
	(func_checker::operand_equal_p): ... this.
	* ipa-icf-gimple.h (class func_checker): Add
	operand_equal_p and hash_operand.
	* ipa-icf.c (sem_function::equals_private): Fix
	pushing and popping of cfun.
---
 gcc/ipa-icf-gimple.c | 228 +++
 gcc/ipa-icf-gimple.h |  12 ++-
 gcc/ipa-icf.c|   7 +-
 3 files changed, 95 insertions(+), 152 deletions(-)

diff --git a/gcc/ipa-icf-gimple.c b/gcc/ipa-icf-gimple.c
index 4060c0e8eb3..96e688c129d 100644
--- a/gcc/ipa-icf-gimple.c
+++ b/gcc/ipa-icf-gimple.c
@@ -324,6 +324,34 @@ func_checker::compare_memory_operand (tree t1, tree t2)
 /* Function compare for equality given trees T1 and T2 which
can be either a constant or a declaration type.  */
 
+void
+func_checker::hash_operand (const_tree arg, inchash::hash ,
+			unsigned int flags)
+{
+  if (arg == NULL_TREE)
+{
+  hstate.merge_hash (0);
+  return;
+}
+
+  switch (TREE_CODE (arg))
+{
+case FUNCTION_DECL:
+case VAR_DECL:
+case LABEL_DECL:
+case PARM_DECL:
+case RESULT_DECL:
+case CONST_DECL:
+case SSA_NAME:
+  return;
+
+default:
+  break;
+}
+
+  return operand_compare::hash_operand (arg, hstate, flags);
+}
+
 bool
 func_checker::compare_cst_or_decl (tree t1, tree t2)
 {
@@ -347,19 +375,6 @@ func_checker::compare_cst_or_decl (tree t1, tree t2)
   return true;
 case VAR_DECL:
   return return_with_debug (compare_variable_decl (t1, t2));
-case FIELD_DECL:
-  {
-	tree offset1 = DECL_FIELD_OFFSET (t1);
-	tree offset2 = DECL_FIELD_OFFSET (t2);
-
-	tree bit_offset1 = DECL_FIELD_BIT_OFFSET (t1);
-	tree bit_offset2 = DECL_FIELD_BIT_OFFSET (t2);
-
-	ret = compare_operand (offset1, offset2)
-	  && compare_operand (bit_offset1, bit_offset2);
-
-	return return_with_debug (ret);
-  }
 case LABEL_DECL:
   {
 	if (t1 == t2)
@@ -383,165 +398,80 @@ func_checker::compare_cst_or_decl (tree t1, tree t2)
 }
 }
 
-/* Function responsible for comparison of various operands T1 and T2.
-   If these components, from functions FUNC1 and FUNC2, are equal, true
-   is returned.  */
-
 bool
-func_checker::compare_operand (tree t1, tree t2)
+func_checker::operand_equal_p (const_tree t1, const_tree t2,
+			   unsigned int flags)
 {
-  tree x1, x2, y1, y2, z1, z2;
-  bool ret;
+  bool r;
+  if (verify_hash_value (t1, t2, flags, ))
+return r;
 
-  if (!t1 && !t2)
+  if (t1 == t2)
 return true;
   else if (!t1 || !t2)
 return false;
 
-  tree tt1 = TREE_TYPE (t1);
-  tree tt2 = TREE_TYPE (t2);
-
-  if (!func_checker::compatible_types_p (tt1, tt2))
-return false;
-
   if (TREE_CODE (t1) != TREE_CODE (t2))
 return return_false ();
 
+  tree tree1 = (tree)const_cast (t1);
+  tree tree2 = (tree)const_cast (t2);
+
   switch (TREE_CODE (t1))
 {
-case CONSTRUCTOR:
+case FUNCTION_DECL:
+  /* All function decls are in the symbol table and known to match
+	 before we start comparing bodies.  */
+  return true;
+case VAR_DECL:
+  return return_with_debug (compare_variable_decl (tree1, tree2));
+case LABEL_DECL:
   {
-	unsigned length1 = CONSTRUCTOR_NELTS (t1);
-	unsigned length2 = CONSTRUCTOR_NELTS (t2);
-
-	if (length1 != length2)
-	  return return_false ();
-
-	for (unsigned i = 0; i < length1; i++)
-	  if (!compare_operand (CONSTRUCTOR_ELT (t1, i)->value,
-CONSTRUCTOR_ELT (t2, i)->value))
-	return return_false();
-
-	return true;
+	int *bb1 = m_label_bb_map.get (tree1);
+	int *bb2 = m_label_bb_map.get (tree2);
+	/* Labels can point to another function (non-local GOTOs).  */
+	return return_with_debug (bb1 != NULL && bb2 != NULL && *bb1 == *bb2);
   }
-case ARRAY_REF:
-case ARRAY_RANGE_REF:
-  /* First argument is the array, second is the index.  */
-  x1 = TREE_OPERAND (t1, 0);
-  x2 = TREE_OPERAND (t2, 0);
-  y1 = TREE_OPERAND (t1, 1);
-  y2 = TREE_OPERAND (t2, 1);
-
-  if (!compare_operand (array_ref_low_bound (t1),
-			array_ref_low_bound (t2)))
-	return return_false_with_msg ("");
-  if (!compare_operand (array_ref_element_size (t1),
-			array_ref_element_size (t2)))
-	return return_false_with_msg ("");
-
-  if (!compare_operand (x1, x2))
-	return return_false_with_msg ("");
-  return compare_operand (y1, y2);
-case MEM_REF:
-  {
-	x1 = TREE_OPERAND (t1, 0);
-	x2 = TREE_OPERAND (t2, 0);
-	y1 = TREE_OPERAND (t1, 1);
-	

Re: [PATCH 5/9] Come up with an abstraction.

[Martin Liška]

On 8/14/19 3:56 PM, Richard Biener wrote:
> On Wed, Aug 14, 2019 at 3:19 PM Martin Liška  wrote:
>>
>> On 8/14/19 3:04 PM, Richard Biener wrote:
>>> On Mon, Aug 12, 2019 at 3:56 PM Martin Liška  wrote:

 On 8/12/19 2:43 PM, Richard Biener wrote:
> On Mon, Aug 12, 2019 at 1:49 PM Martin Liška  wrote:
>>
>> On 8/12/19 1:40 PM, Richard Biener wrote:
>>> On Mon, Aug 12, 2019 at 1:19 PM Martin Liška  wrote:

 On 8/8/19 5:55 PM, Michael Matz wrote:
> Hi,
>
> On Mon, 10 Jun 2019, Martin Liska wrote:
>
>> 2019-07-24  Martin Liska  
>>
>>  * fold-const.c (operand_equal_p): Rename to ...
>>  (operand_compare::operand_equal_p): ... this.
>>  (add_expr):  Rename to ...
>>  (operand_compare::hash_operand): ... this.
>>  (operand_compare::operand_equal_valueize): Likewise.
>>  (operand_compare::hash_operand_valueize): Likewise.
>>  * fold-const.h (operand_equal_p): Set default
>>  value for last argument.
>>  (class operand_compare): New.
>
> Hmpf.  A class without any data?  That doesn't sound like a good 
> design.

 Yes, the base class (current operand_equal_p) does not have a data.
 But the ICF derive class has a data and e.g. 
 func_checker::operand_equal_valueize
 will use m_label_bb_map.get (t1). Which are member data of class 
 func_checker.

> You seem to need it only to have the possibility of virtual functions,
> i.e. fancy callbacks.  AFAICS you only have one derived class, i.e. a
> simple distinction of two cases.  What do you think about encoding the
> additional new (ICF) case in the (existing) 'flags' argument to
> operand_equal_p (and in case the ICF flag is set simply call the
> "callback" directly)?

 That's possible. I can add two more callbacks to the operand_equal_p 
 function
 (hash_operand_valueize and operand_equal_valueize).

 Is Richi also supporting this approach?
>>>
>>> I still see no value in the abstraction since you invoke none of the
>>> (virtual) methods from the base class operand_equal_p.
>>
>> I call operand_equal_valueize (and hash_operand) from operand_equal_p.
>> These are then used in IPA ICF (patch 6/9).
>
> Ugh.  I see you call that after
>
>   if (TREE_CODE (arg0) != TREE_CODE (arg1))
> {
> ...
> }
>   else
> return false;
> }
>
> and also after
>
>   /* Check equality of integer constants before bailing out due to
>  precision differences.  */
>   if (TREE_CODE (arg0) == INTEGER_CST && TREE_CODE (arg1) == INTEGER_CST)
>
> which means for arg0 == SSA_NAME and arg1 == INTEGER_CST you return false
> instead of valueizing arg0 to the possibly same or same "lose" value
> and returning true.

 Yes. ICF does not allow to have anything where TREE_CODEs do not match.

>
> Also
>
> +  int val = operand_equal_valueize (arg0, arg1, flags);
> +  if (val == 1)
> +return 1;
> +  if (val == 0)
> +return 0;
>
> suggests that you pass in arbirtrary trees for "valueization" but it
> isn't actually
> valueization that is performed but instead it should do an alternate 
> comparison
> of arg0 and arg1 with valueization.  Why's this done this way instead of
> sth like
>
>   if (TREE_CODE (arg0) == SSA_NAME)
>arg0 = operand_equal_valueize (arg0, flags);
>  if (TREE_CODE (arg1) == SSA_NAME)
>arg1 = operand_equal_valueize (arg1, flags);

 Because I want to be given a pair of trees about which the function
 operand_equal_valueize returns match/no-match/dunno.

>
> and why's this done with virtual functions rather than a callback that we 
> can
> cheaply check for NULLness in the default implementation?

 I can transform it into a hook. But as mentioned I'll need two hooks.

>
> So - what does ICF want to make "equal" that isn't equal normally and 
> how's
> that "valueization"?

 E.g. for a FUNCTION_DECL, ICF always return true because it can only calls
 the operand_equal_p after callgraph is compared. Similarly for LABEL_DECLs,
 we have a map (m_label_bb_map). Please take a look at patch 6/9 in this
 series.
>>>
>>> Hmm, ok, so you basically replace recursive calls to operand_equal_p with
> 
> _recursive calls_
> 
>>>
>>>   operand_equal_valueize (t1, t2, 0)
>>>   || operand_equal_p (t1, t2, 0)
>>>
>>> no?
>>
>> This is not going to work ..
> 
> I wonder if
> 
> class base
> {
>   virtual operand_equal_p (tree a, tree b, int f);
> };
> 
> base::operand_equal_p (tree a, tree b, int f)
> {
>   as-is now, recursing to 

Re: [PATCH] Make GIMPLE forwprop DCE dead stmts

[Richard Biener]

On Wed, 14 Aug 2019, Jeff Law wrote:

> On 8/14/19 7:36 AM, Richard Biener wrote:
> > 
> > The following patch makes forwprop DCE the stmts that become dead
> > because of propagation of copies and constants.  For this to work
> > we actually have to do that reliably rather than relying on
> > fold_stmt doing this for us.
> > 
> > This hits fortran/trans-intrinsic.c in a way that we do "interesting"
> > jump threading exposing a bogus uninit warning.  I'll open a PR
> > for this with an (unreduced) testcase after committing.
> Feel free to mark it as a regression, if for no other reason than that
> guarantees that I look at it during stage3/stage4.  I can adjust the
> marker at that time based on what I find.

Done (PR91470).

The following is what I have installed (needed to fiddle with
a helper removing the stmt we iterate on).

Bootstrapped / tested on x68_64-unknown-linux-gnu.

Richard.

2019-08-16  Richard Biener  

* tree-ssa-forwprop.c (simplify_builtin_call): Do not remove
stmt at gsi_p, instead replace it with a NOP removed later.
(pass_forwprop::execute): Fully propagate lattice, DCE stmts
that became dead because of that.

fortran/
* trans-intrinsic.c (gfc_conv_intrinsic_findloc): Initialize
forward_branch to avoid bogus uninitialized warning.

* gcc.dg/tree-ssa/forwprop-31.c: Adjust.

Index: gcc/tree-ssa-forwprop.c
===
--- gcc/tree-ssa-forwprop.c (revision 274538)
+++ gcc/tree-ssa-forwprop.c (working copy)
@@ -1403,7 +1403,7 @@ simplify_builtin_call (gimple_stmt_itera
   build_int_cst (TREE_TYPE (len1), src_len));
  update_stmt (stmt1);
  unlink_stmt_vdef (stmt2);
- gsi_remove (gsi_p, true);
+ gsi_replace (gsi_p, gimple_build_nop (), false);
  fwprop_invalidate_lattice (gimple_get_lhs (stmt2));
  release_defs (stmt2);
  if (lhs1 && DECL_FUNCTION_CODE (callee1) == BUILT_IN_MEMPCPY)
@@ -2299,13 +2299,14 @@ pass_forwprop::execute (function *fun)
   int postorder_num = pre_and_rev_post_order_compute_fn (cfun, NULL,
 postorder, false);
   auto_vec to_fixup;
+  auto_vec to_remove;
   to_purge = BITMAP_ALLOC (NULL);
   for (int i = 0; i < postorder_num; ++i)
 {
   gimple_stmt_iterator gsi;
   basic_block bb = BASIC_BLOCK_FOR_FN (fun, postorder[i]);
 
-  /* Propagate into PHIs and record degenerate ones in the lattice.  */
+  /* Record degenerate PHIs in the lattice.  */
   for (gphi_iterator si = gsi_start_phis (bb); !gsi_end_p (si);
   gsi_next ())
{
@@ -2321,17 +2322,20 @@ pass_forwprop::execute (function *fun)
  FOR_EACH_PHI_ARG (use_p, phi, it, SSA_OP_USE)
{
  tree use = USE_FROM_PTR (use_p);
- tree tem = fwprop_ssa_val (use);
  if (! first)
-   first = tem;
- else if (! operand_equal_p (first, tem, 0))
-   all_same = false;
- if (tem != use
- && may_propagate_copy (use, tem))
-   propagate_value (use_p, tem);
+   first = use;
+ else if (! operand_equal_p (first, use, 0))
+   {
+ all_same = false;
+ break;
+   }
}
  if (all_same)
-   fwprop_set_lattice_val (res, first);
+   {
+ if (may_propagate_copy (res, first))
+   to_remove.safe_push (phi);
+ fwprop_set_lattice_val (res, first);
+   }
}
 
   /* Apply forward propagation to all stmts in the basic-block.
@@ -2648,148 +2652,223 @@ pass_forwprop::execute (function *fun)
 
   /* Combine stmts with the stmts defining their operands.
 Note we update GSI within the loop as necessary.  */
-  for (gsi = gsi_start_bb (bb); !gsi_end_p (gsi);)
+  for (gsi = gsi_start_bb (bb); !gsi_end_p (gsi); gsi_next ())
{
  gimple *stmt = gsi_stmt (gsi);
- gimple *orig_stmt = stmt;
- bool changed = false;
- bool was_noreturn = (is_gimple_call (stmt)
-  && gimple_call_noreturn_p (stmt));
 
  /* Mark stmt as potentially needing revisiting.  */
  gimple_set_plf (stmt, GF_PLF_1, false);
 
- if (fold_stmt (, fwprop_ssa_val))
+ /* Substitute from our lattice.  We need to do so only once.  */
+ bool substituted_p = false;
+ use_operand_p usep;
+ ssa_op_iter iter;
+ FOR_EACH_SSA_USE_OPERAND (usep, stmt, iter, SSA_OP_USE)
{
- changed = true;
- stmt = gsi_stmt (gsi);
- if (maybe_clean_or_replace_eh_stmt (orig_stmt, stmt))
-   bitmap_set_bit (to_purge, bb->index);
- if (!was_noreturn
- && is_gimple_call 

Re: [PATCH][gensupport] PR 91255: Do not error out immediately on set_attr_alternative with define_subst

[Richard Sandiford]

Kyrill Tkachov  writes:
> Hi all,
>
> I'm trying to add a define_subst use in the arm backend but am getting 
> many build errors complaining about:
> `set_attr_alternative' is unsupported by `define_subst'
>
> Looking at the gensupport.c code it iterates over all define_insns and 
> errors if any of them have set_attr_alternative.
>
> The usecase I'm targetting doesn't involve patterns with 
> set_attr_alternative, so I would like to make the define_subst handling
> more robust to only error out if the define_subst is actually attempted 
> on a set_attr_alternative.
>
> This patch produces the error only if the set_attr_alternative attr 
> matches the subst name.
> This allows a build of the arm backend with a define_subst usage to succeed.
>
> Bootstrapped and tested on arm-none-linux-gnueabihf and x86_64-linux-gnu.
>
> Ok for trunk?

OK, thanks.

Richard

>
> Thanks,
> Kyrill
>
> 2019-08-15  Kyrylo Tkachov  
>
>      PR other/91255
>      * gensupport.c (has_subst_attribute): Error out on set_attr_alternative
>      only if subst_name matches curr_attr string.
>
> diff --git a/gcc/gensupport.c b/gcc/gensupport.c
> index 1aab7119901..c64f683bc5c 100644
> --- a/gcc/gensupport.c
> +++ b/gcc/gensupport.c
> @@ -788,9 +788,10 @@ has_subst_attribute (class queue_elem *elem, class 
> queue_elem *subst_elem)
> return false;
>  
>   case SET_ATTR_ALTERNATIVE:
> -   error_at (elem->loc,
> - "%s: `set_attr_alternative' is unsupported by "
> - "`define_subst'", XSTR (elem->data, 0));
> +   if (strcmp (XSTR (cur_attr, 0), subst_name) == 0)
> + error_at (elem->loc,
> +   "%s: `set_attr_alternative' is unsupported by "
> +   "`define_subst'", XSTR (elem->data, 0));
> return false;
>  
>  

Re: [PATCH 2/9] operand_equal_p: add support for FIELD_DECL

[Richard Biener]

On Thu, Aug 15, 2019 at 4:17 PM Jan Hubicka  wrote:
>
> > On Tue, Aug 6, 2019 at 5:44 PM Martin Liska  wrote:
> > >
> > >
> > > gcc/ChangeLog:
> >
> > So I suppose this isn't to call operand_equal_p on two FIELD_DECLs
> > but to make two COMPONENT_REFs "more equal"?  If so I then
>
> yes. The patch originates from my original patchset I believe and it is
> what ICF does.
> > I suggest to make this change "local" to the COMPONENT_REF handling.
> > This also interacts with path-based disambiguation so you want to make
> > sure to only make things equal here iff it wouldn't change the outcome
> > of path-based analysis.  Honza?
>
> Indeed this can be handled as part of COMPONENT_REF match.
> Access path oracle here basically checks:
>  1) that MEM_REF type matches (we want predicate for this)
>  2) if it finds type match via same_type_for_tbaa and then it applies
> the assumption about disjointness or overlap
>
> So I guess ideally we should
>
>  1) do matching part of COMPONENT_REF
>  2) compare OFFSET, BIT_OFFSET
> This establishes that the access has same semantics.
>  3) for -fno-strict-aliasing be happy
>  4) for -fstrict-aliaisng check if access path applies (we should export
> predicate from tree-ssa-alias as discussed earlier)
>  5) compare types by same_type_for_tbaa_p

Ick.  This smells like a layering violation to me.  IMHO this extended
equality handling should be handled with the overloading/callback
and not in native operand_equal_p.  Either on the level of the
COMPONENT_REF itself (sounds like that would be needed)
or the FIELD_DECL.  Not sure if the above suggestions make
it neccessary to look at more than a single COMPONENT_REF/FIELD_DECL
in the access path.  If so then watch out for quadraticness as operand_equal_p
traverses a reference chain...

Richard.

> Honza

Re: [PATCH 3/9] operand_equal_p: add support for OBJ_TYPE_REF.

[Richard Biener]

On Thu, Aug 15, 2019 at 4:57 PM Jan Hubicka  wrote:
>
> > On Tue, Aug 6, 2019 at 5:43 PM Martin Liska  wrote:
> > >
> > >
> > > gcc/ChangeLog:
> >
> > +   /* Virtual table call.  */
> > +   case OBJ_TYPE_REF:
> > + {
> > +   if (!operand_equal_p (OBJ_TYPE_REF_EXPR (arg0),
> > + OBJ_TYPE_REF_EXPR (arg1), flags))
> > + return false;
> > +   if (virtual_method_call_p (arg0))
> > + {
> > +   if (tree_to_uhwi (OBJ_TYPE_REF_TOKEN (arg0))
> > +   != tree_to_uhwi (OBJ_TYPE_REF_TOKEN (arg1)))
> > + return false;
> > +   if (!types_same_for_odr (obj_type_ref_class (arg0),
> > +obj_type_ref_class (arg1)))
> > + return false;
> > +   if (!operand_equal_p (OBJ_TYPE_REF_OBJECT (arg0),
> > + OBJ_TYPE_REF_OBJECT (arg1), flags))
> > + return false;
> >
> > this all gets deep into the devirt machinery, including looking at
> > ODR type hashes.  So I'm not sure if we really want to handle
> > it this "optimistic" in operand_equal_p and completely ignore
> > other operands when !virtual_method_call_p?  That is, why
> > not compare OBJ_TYPE_REF_TOKEN/OBJECT always at least?
>
> For !virtual_method_call_p we do not use OBJ_TYPE_REF at all yet obj-C 
> frontend
> produce it.  I think we should remove them somewhere during gimplification.
> We can definitly turn "optimistic" to "pesimistic" and return false here.
>
> Otherwise the checks makes sense to me - it the tests above passes devirt
> machinery ought to give same results.
> >
> > Do we then have cases where the OBJ_TYPE_REF is actually
> > distinct according to the remaining check?
>
> I am not sure what you mean here?

When we compare OBJ_TYPE_REF_TOKEN and OBJ_TYPE_REF_OBJECT
and they are equal, are there cases where types_same_for_odr returns false?

I guess we went over this some time ago when talking about value-numbering
of them.  I realize the devirt machinery use the class type to get at the
virtual table but since we later expand simply OBJ_TPE_REF_EXPR _that_
already has the result of the load from the vitual table.

So - do we need to compare obj_type_ref_class at all?  The worst thing
that could happen is that devirt no longer can devirtualize after the merging
but it should never result in "wrong" devirtualization?  So, do we really
want to inhibit ICF of two equal functions that could be eventually
devirtualized both but into different direct calls?  Can't this sort of thing
happen anyway when you'd factor in IPA-CP and two identical functions
with indirect calls to a function argument but called with different constant
args?  And should IPA-CP then not consider cloning after ICF merging
(not sure how ordering works here).

Richard.

> Honza
> >
> > + }
> >
> >
> > > 2019-07-24  Martin Liska  
> > >
> > > * fold-const.c (operand_equal_p): Support OBJ_TYPE_REF.
> > > * tree.c (add_expr): Hash parts of OBJ_TYPE_REF.
> > > ---
> > >  gcc/fold-const.c | 21 +
> > >  gcc/tree.c   |  9 +
> > >  2 files changed, 30 insertions(+)
> > >

Re: [PATCH] Prevent LTO section collision for a symbol name starting with '*'.

[Richard Biener]

On Thu, Aug 15, 2019 at 4:33 PM Jan Hubicka  wrote:
>
> > On Fri, Aug 9, 2019 at 3:57 PM Martin Liška  wrote:
> > >
> > > Hi.
> > >
> > > The patch is about prevention of LTO section name clashing.
> > > Now we have a situation where body of 2 functions is streamed
> > > into the same ELF section. Then we'll end up with smashed data.
> > >
> > > Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> > >
> > > Ready to be installed?
> >
> > I think the comment should mention why we skip a leading '*'
> > at all.  IIRC this is some target mangling applied to DECL_ASSEMBLER_NAME?
> DECL_ASSEMBLER_NAME works in a way that if it starts with "*"
> it is copied verbatim to the linker ouptut.  If it is w/o "*"
> then user_label_prefix is applied first, see
> symbol_table::assembler_names_equal_p
>
> So if we skip "*" one can definitly construct testcases of different
> function names ending up in same section especially when
> user_label_prefix is non-empty, like on Windows I think it is "_".
>
> > And section names cannot contain '*'?  Or do we need to actually
> > indentify '*fn' and 'fn' as the same?  For the testcase what is the clashing
> > symbol?  Can't we have many so that using "0" always is broken as well?
>
> We may have duplicate symbols during the compile time->WPA streaming
> since we do not do lto-symtab at compile time and user can use asm names
> that way.  This is not limited to extern inlines, so it would be nice to
> make this work reliably. I also plan support for keeping multiple
> function bodies defined for one symbol in cases it is necessary (glibc
> checking, when optimization flags are mismatches) for WPA->ltrans
> streaming.
>
> I was always considering option to simply use node->order ids to stream
> sections.  Because of way node->order is merged we area always able to
> recover the ID.

Heh, that sounds like a nice idea indeed.

>
> It is however kind of nice to see actual names in the objdump
> of the LTO .o files.  I would not mind that much to see this go and it
> would also save bit of space since symbol names can be long.
>
> Honza
> >
> > Richard.
> >
> > > Thanks,
> > > Martin
> > >
> > > gcc/ChangeLog:
> > >
> > > 2019-08-09  Martin Liska  
> > >
> > > PR lto/91393
> > > PR lto/88220
> > > * lto-streamer.c (lto_get_section_name): Replace '*' leading
> > > character with '0'.
> > >
> > > gcc/testsuite/ChangeLog:
> > >
> > > 2019-08-09  Martin Liska  
> > >
> > > PR lto/91393
> > > PR lto/88220
> > > * gcc.dg/lto/pr91393_0.c: New test.
> > > ---
> > >  gcc/lto-streamer.c   | 15 ---
> > >  gcc/testsuite/gcc.dg/lto/pr91393_0.c | 11 +++
> > >  2 files changed, 23 insertions(+), 3 deletions(-)
> > >  create mode 100644 gcc/testsuite/gcc.dg/lto/pr91393_0.c
> > >
> > >

Re: [PATCH] Make cdtor names stable for LTO (PR lto/91307).

[Richard Biener]

On Fri, Aug 16, 2019 at 10:47 AM Richard Biener
 wrote:
>
> On Thu, Aug 15, 2019 at 4:25 PM Jan Hubicka  wrote:
> >
> > > On Thu, Aug 1, 2019 at 3:10 PM Martin Liška  wrote:
> > > >
> > > > Hi.
> > > >
> > > > In LTO WPA mode we don't have to append temp file name
> > > > to the global cdtor function names.
> > >
> > > Is that true?  You can link with -r -flinker-output=rel and use
> > > multiple WPA phases whose results you then finally link.
> > >
> > > So I don't think it's that easy.  You might be able to look at
> > > all_translation_units, pick the one with a sensible name
> > > (hmm, not sure if we actually have a name there) and the lowest
> > > UID and use that?  Thus, make the set of involved source files
> > > known and pick one.  Ah,
> > >
> > > struct GTY(()) tree_translation_unit_decl {
> > >   struct tree_decl_common common;
> > >   /* Source language of this translation unit.  Used for DWARF output.  */
> > >   const char * GTY((skip(""))) language;
> > >   /* TODO: Non-optimization used to build this translation unit.  */
> > >   /* TODO: Root of a partial DWARF tree for global types and decls.  */
> > > };
> > >
> > > so you might be able to get at a filename via the decls location,
> > > I'm not sure.  Do we have any LTO records per "input file" where we
> > > can stream main_input_filename to?
> >
> > This is all bit sloppy.  If you incrmentally link into .o file and then
> > use LTO again to add more code, you will very likely run into conflict
> > with .lto_priv clones as well. Especially now when we made them more
> > stable.
> >
> > I wondered if Linker should not provide us also with list of symbols
> > that are used in the unit, so we can safely produce more local ones?
>
> OTOH those are all local symbols so the only effect is that the
> user may see duplicates when debugging.
>
> So I wonder why we even try to invent these fancy names for
> targets where we have targetm.have_ctors_dtors and thus those
> end up being local...  My theory is that either gdb has some
> fancy way to break on global initializers from file X (doesn't work
> with LTO merging anyways) or it's just the users will  be able to
> pick up the correct one with tab-completion more easily!?
>
> So I believe choosing any name is fine for targetm_have_ctors_dtors
> like with the following change, local to the IPA logic:
>
> Index: gcc/ipa.c
> ===
> --- gcc/ipa.c   (revision 274536)
> +++ gcc/ipa.c   (working copy)
> @@ -836,13 +836,15 @@ cgraph_build_static_cdtor_1 (char which,
>/* The priority is encoded in the constructor or destructor name.
>   collect2 will sort the names and arrange that they are called at
>   program startup.  */
> -  if (final)
> -sprintf (which_buf, "%c_%.5d_%d", which, priority, counter++);
> +  if (!targetm.have_ctors_dtors && final)
> +{
> +  sprintf (which_buf, "%c_%.5d_%d", which, priority, counter++);
> +  name = get_file_function_name (which_buf);
> +}
>else
> -  /* Proudce sane name but one not recognizable by collect2, just for the
> - case we fail to inline the function.  */
> +/* Proudce sane name but one not recognizable by collect2, just for the
> +   case we fail to inline the function.  */
>  sprintf (which_buf, "sub_%c_%.5d_%d", which, priority, counter++);
> -  name = get_file_function_name (which_buf);
>
>decl = build_decl (input_location, FUNCTION_DECL, name,
>  build_function_type_list (void_type_node, NULL_TREE));
>
> Is that change OK with you?  If so I'll test & commit it.

Better the following which actually works ;)

Richard.

2019-08-16  Richard Biener  

PR lto/91307
* ipa.c (cgraph_build_static_cdtor_1): Use names not recognizable
by collect2 when targetm.have_ctors_dtors which avoids dragging
in temporary filenames from LTO input objects.

Index: gcc/ipa.c
===
--- gcc/ipa.c   (revision 274536)
+++ gcc/ipa.c   (working copy)
@@ -836,13 +836,18 @@ cgraph_build_static_cdtor_1 (char which,
   /* The priority is encoded in the constructor or destructor name.
  collect2 will sort the names and arrange that they are called at
  program startup.  */
-  if (final)
-sprintf (which_buf, "%c_%.5d_%d", which, priority, counter++);
+  if (!targetm.have_ctors_dtors && final)
+{
+  sprintf (which_buf, "%c_%.5d_%d", which, priority, counter++);
+  name = get_file_function_name (which_buf);
+}
   else
-  /* Proudce sane name but one not recognizable by collect2, just for the
- case we fail to inline the function.  */
-sprintf (which_buf, "sub_%c_%.5d_%d", which, priority, counter++);
-  name = get_file_function_name (which_buf);
+{
+  /* Proudce sane name but one not recognizable by collect2, just for the
+case we fail to inline the function.  */
+  sprintf (which_buf, "_sub_%c_%.5d_%d", 

Re: [PATCH] Make cdtor names stable for LTO (PR lto/91307).

[Richard Biener]

On Thu, Aug 15, 2019 at 4:25 PM Jan Hubicka  wrote:
>
> > On Thu, Aug 1, 2019 at 3:10 PM Martin Liška  wrote:
> > >
> > > Hi.
> > >
> > > In LTO WPA mode we don't have to append temp file name
> > > to the global cdtor function names.
> >
> > Is that true?  You can link with -r -flinker-output=rel and use
> > multiple WPA phases whose results you then finally link.
> >
> > So I don't think it's that easy.  You might be able to look at
> > all_translation_units, pick the one with a sensible name
> > (hmm, not sure if we actually have a name there) and the lowest
> > UID and use that?  Thus, make the set of involved source files
> > known and pick one.  Ah,
> >
> > struct GTY(()) tree_translation_unit_decl {
> >   struct tree_decl_common common;
> >   /* Source language of this translation unit.  Used for DWARF output.  */
> >   const char * GTY((skip(""))) language;
> >   /* TODO: Non-optimization used to build this translation unit.  */
> >   /* TODO: Root of a partial DWARF tree for global types and decls.  */
> > };
> >
> > so you might be able to get at a filename via the decls location,
> > I'm not sure.  Do we have any LTO records per "input file" where we
> > can stream main_input_filename to?
>
> This is all bit sloppy.  If you incrmentally link into .o file and then
> use LTO again to add more code, you will very likely run into conflict
> with .lto_priv clones as well. Especially now when we made them more
> stable.
>
> I wondered if Linker should not provide us also with list of symbols
> that are used in the unit, so we can safely produce more local ones?

OTOH those are all local symbols so the only effect is that the
user may see duplicates when debugging.

So I wonder why we even try to invent these fancy names for
targets where we have targetm.have_ctors_dtors and thus those
end up being local...  My theory is that either gdb has some
fancy way to break on global initializers from file X (doesn't work
with LTO merging anyways) or it's just the users will  be able to
pick up the correct one with tab-completion more easily!?

So I believe choosing any name is fine for targetm_have_ctors_dtors
like with the following change, local to the IPA logic:

Index: gcc/ipa.c
===
--- gcc/ipa.c   (revision 274536)
+++ gcc/ipa.c   (working copy)
@@ -836,13 +836,15 @@ cgraph_build_static_cdtor_1 (char which,
   /* The priority is encoded in the constructor or destructor name.
  collect2 will sort the names and arrange that they are called at
  program startup.  */
-  if (final)
-sprintf (which_buf, "%c_%.5d_%d", which, priority, counter++);
+  if (!targetm.have_ctors_dtors && final)
+{
+  sprintf (which_buf, "%c_%.5d_%d", which, priority, counter++);
+  name = get_file_function_name (which_buf);
+}
   else
-  /* Proudce sane name but one not recognizable by collect2, just for the
- case we fail to inline the function.  */
+/* Proudce sane name but one not recognizable by collect2, just for the
+   case we fail to inline the function.  */
 sprintf (which_buf, "sub_%c_%.5d_%d", which, priority, counter++);
-  name = get_file_function_name (which_buf);

   decl = build_decl (input_location, FUNCTION_DECL, name,
 build_function_type_list (void_type_node, NULL_TREE));

Is that change OK with you?  If so I'll test & commit it.

Thanks,
Richard.

> Honza
> >
> > > It helps to have a reproducible
> > > builds with LTO mode.
> > >
> > > Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> > >
> > > Ready to be installed?
> > > Thanks,
> > > Martin
> > >
> > > gcc/ChangeLog:
> > >
> > > 2019-08-01  Martin Liska  
> > >
> > > PR lto/91307
> > > * tree.c (get_file_function_name): Use "wpa" when
> > > we are in WPA LTO mode.
> > > ---
> > >  gcc/tree.c | 17 +++--
> > >  1 file changed, 11 insertions(+), 6 deletions(-)
> > >
> > >

[PATCH][OBVIOUS] Add missed to a opt-info dump.

[Martin Liška]

Hi.

It's an obvious fix for the test-case. It's verified by the
reported that it helps.

Martin

gcc/testsuite/ChangeLog:

2019-08-15  Martin Liska  

PR ipa/91447
* g++.dg/ipa/ipa-icf-4.C: Add -missed for target that
don't have aliases.
---
 gcc/testsuite/g++.dg/ipa/ipa-icf-4.C | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


diff --git a/gcc/testsuite/g++.dg/ipa/ipa-icf-4.C b/gcc/testsuite/g++.dg/ipa/ipa-icf-4.C
index 86954055382..0b49c6f014c 100644
--- a/gcc/testsuite/g++.dg/ipa/ipa-icf-4.C
+++ b/gcc/testsuite/g++.dg/ipa/ipa-icf-4.C
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-O2 -fdump-ipa-icf-optimized -fno-inline" } */
+/* { dg-options "-O2 -fdump-ipa-icf-optimized-missed -fno-inline" } */
 
 namespace {
 struct A

Re: types for VR_VARYING

[Aldy Hernandez]

On 8/15/19 12:06 PM, Aldy Hernandez wrote:



On 8/15/19 7:23 AM, Richard Biener wrote:

On Thu, Aug 15, 2019 at 12:40 PM Aldy Hernandez  wrote:


On 8/14/19 1:37 PM, Jeff Law wrote:

On 8/13/19 6:39 PM, Aldy Hernandez wrote:



On 8/12/19 7:46 PM, Jeff Law wrote:

On 8/12/19 12:43 PM, Aldy Hernandez wrote:

This is a fresh re-post of:

https://gcc.gnu.org/ml/gcc-patches/2019-07/msg6.html

Andrew gave me some feedback a week ago, and I obviously don't 
remember
what it was because I was about to leave on PTO.  However, I do 
remember
I addressed his concerns before getting drunk on rum in tropical 
islands.


FWIW found a great coffee infused rum while in Kauai last week.  
I'm not

a coffee fan, but it was wonderful.  The one bottle we brought back
isn't going to last until Cauldron and I don't think I can get a 
special

order filled before I leave :(


You must bring some to Cauldron before we believe you. :)

That's the problem.  The nearest place I can get it is in Vegas and
there's no distributor in Montreal.   I can special order it in our
state run stores, but it won't be here in time.

Of course, I don't mind if you don't believe me.  More for me in that
case...


Is the supports_type_p stuff there to placate the calls from 
ipa-cp?  I

can live with it in the short term, but it really feels like there
should be something in the ipa-cp client that avoids this silliness.


I am not happy with this either, but there are various places where
statements that are !stmt_interesting_for_vrp() are still setting a
range of VARYING, which is then being ignored at a later time.

For example, vrp_initialize:

    if (!stmt_interesting_for_vrp (phi))
  {
    tree lhs = PHI_RESULT (phi);
    set_def_to_varying (lhs);
    prop_set_simulate_again (phi, false);
  }

Also in evrp_range_analyzer::record_ranges_from_stmt(), where we if 
the
statement is interesting for VRP but extract_range_from_stmt() does 
not
produce a useful range, we also set a varying for a range we will 
never

use.  Similarly for a statement that is not interesting in this hunk.

Ugh.  One could perhaps argue that setting any kind of range in these
circumstances is silly.   But I suspect it's necessary due to the
optimistic handling of VR_UNDEFINED in value_range_base::union_helper.
It's all coming back to me now...




Then there is vrp_prop::visit_stmt() where we also set VARYING for 
types

that VRP will never handle:

    case IFN_ADD_OVERFLOW:
    case IFN_SUB_OVERFLOW:
    case IFN_MUL_OVERFLOW:
    case IFN_ATOMIC_COMPARE_EXCHANGE:
  /* These internal calls return _Complex integer type,
 which VRP does not track, but the immediate uses
 thereof might be interesting.  */
  if (lhs && TREE_CODE (lhs) == SSA_NAME)
    {
  imm_use_iterator iter;
  use_operand_p use_p;
  enum ssa_prop_result res = SSA_PROP_VARYING;

  set_def_to_varying (lhs);

I've adjusted the patch so that set_def_to_varying will set the 
range to

VR_UNDEFINED if !supports_type_p.  This is a fail safe, as we can't
really do anything with a nonsensical range.  I just don't want to 
leave

the range in an indeterminate state.


I think VR_UNDEFINED is unsafe due to value_range_base::union_helper.
And that's a more general than this patch.  VR_UNDEFINED is _not_ a 
safe
range to set something to if we can't handle it.  We have to use 
VR_VARYING.


Why?  See the beginning of value_range_base::union_helper:

 /* VR0 has the resulting range if VR1 is undefined or VR0 is 
varying.  */

 if (vr1->undefined_p ()
 || vr0->varying_p ())
   return *vr0;

 /* VR1 has the resulting range if VR0 is undefined or VR1 is 
varying.  */

 if (vr0->undefined_p ()
 || vr1->varying_p ())
   return *vr1;
This can get called for something like

    a =  ? name1 : name2;

If name1 was set to VR_UNDEFINED thinking that VR_UNDEFINED was a safe
value for something we can't handle, then we'll incorrectly return the
range for name2.


I think that if name1 was !supports_type_p, we will have never called
union/intersect.  We will have bailed at some point earlier.  However, I
do see your point about being consistent.



VR_UNDEFINED can only be used for the ranges of objects we haven't
processed.  If we can't produce a range for an object because the
statement is something we don't handle or just doesn't produce anythign
useful, then the right result is VR_VARYING.

This may be worth commenting at the definition site for VR_*.



I also noticed that Andrew's patch was setting num_vr_values to
num_ssa_names + num_ssa_names / 10.  I think he meant num_vr_values +
num_vr_values / 10.  Please verify the current incantation makes 
sense.
Going to assume this will be adjusted per the other messages in this 
thread.


Done.





diff --git a/gcc/tree-ssa-threadedge.c b/gcc/tree-ssa-threadedge.c
index 39ea22f0554..663dd6e2398 100644
---