[Bug fortran/91443] -Wargument-mismatch does not catch mismatch for global procedure

2019-08-16 Thread jb at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91443

Janne Blomqvist  changed:

   What|Removed |Added

 CC||jb at gcc dot gnu.org

--- Comment #3 from Janne Blomqvist  ---
I'm seeing a failure in the testcase libgomp.fortran/appendix-a/a.28.5.f90
which looks like it might(?) be caused by this:

$ gfortran a.28.5.f90 
a.28.5.f90:29:20:

   29 |   CALL SUB1(A)
  |1
Error: Rank mismatch in argument ‘x’ at (1) (rank-1 and scalar)

Or is this something else?

[Bug fortran/91300] Wrong runtime error message with allocate and errmsg=

2019-08-16 Thread jb at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91300
Bug 91300 depends on bug 68401, which changed state.

Bug 68401 Summary: improve 'Allocation would exceed memory limit'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68401

   What|Removed |Added

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

[Bug fortran/68401] improve 'Allocation would exceed memory limit'

2019-08-16 Thread jb at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68401

Janne Blomqvist  changed:

   What|Removed |Added

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

--- Comment #14 from Janne Blomqvist  ---
Fixed on trunk, closing.

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

2019-08-16 Thread 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()

2019-08-16 Thread 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

2019-08-16 Thread 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


[Bug fortran/68401] improve 'Allocation would exceed memory limit'

2019-08-16 Thread jb at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68401

--- Comment #13 from Janne Blomqvist  ---
Author: jb
Date: Sat Aug 17 05:45:37 2019
New Revision: 274599

URL: https://gcc.gnu.org/viewcvs?rev=274599=gcc=rev
Log:
PR fortran/68401 Improve allocation error message

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.

gcc/fortran/ChangeLog:

2019-08-17  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-17  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.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-decl.c
trunk/gcc/fortran/trans.c
trunk/gcc/fortran/trans.h
trunk/libgfortran/ChangeLog
trunk/libgfortran/gfortran.map
trunk/libgfortran/libgfortran.h
trunk/libgfortran/runtime/error.c

Re: Expansion of narrowing math built-ins into power instructions

2019-08-16 Thread Tejas Joshi
Hi,

> It's just a different name, nothing more, nothing less.  Because it is
> a different name it can not be accidentally generated from actual
> truncations.

I have introduced float_narrow but I could not find appropriate places
to generate it for a call to fadd instead it to generate a CALL. I
used GDB to set breakpoints which hit fold_rtx and cse_insn but I got
confused with the rtx codes and passes which generate respective RTL.
It should not be similar to FLOAT_TRUNCATE if we want to avoid it
generating for actual truncations?

Thanks,
Tejas


On Fri, 16 Aug 2019 at 15:53, Richard Sandiford
 wrote:
>
> Segher Boessenkool  writes:
> > On Thu, Aug 15, 2019 at 01:47:47PM +0100, Richard Sandiford wrote:
> >> Tejas Joshi  writes:
> >> > Hello.
> >> > I just wanted to make sure that I am looking at the correct code here.
> >> > Except for rtl.def where I should be introducing something like
> >> > float_contract (or float_narrow?) and also simplify-rtx.c, breakpoints
> >
> > I like that "float_narrow" name :-)
> >
> >> > set on functions around expr.c, cfgexpand.c where I grep for
> >> > float_truncate/FLOAT_TRUNCATE did not hit.
> >> > Also, in what manner should float_contract/narrow be different from
> >> > float_truncate as both are trying to do similar things? (truncation
> >> > from DF to SF)
> >>
> >> I think the code should instead be a fused addition and truncation,
> >> a bit like FMA is a fused addition and multiplication.  Describing it as
> >> a DFmode addition followed by some conversion to SF would still involve
> >> double rounding.
> >
> > How so?  It would *mean* there is only single rounding, even!  That's
> > the whole point of it.
>
> But a PLUS should behave as a PLUS in any context.  Making its
> behaviour dependent on the containing rtxes (if any) would be a
> can of worms.
>
> Richard


libgo patch committed: Scan write barrier buffer conservatively

2019-08-16 Thread 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)


Question about pass_fix_loops or other loop fixing classes

2019-08-16 Thread xerofoify
Greetings,
I was wondering why the execute function in the file tree-ssa-loop.c
does not for all the pass fixing
classes run it on a separate thread. Seems a good idea to call execute
for these classes on another
thread and then join up with the main thread into order to avoid
shared state or waiting on complex
loops to be optimized.

Maybe I'm missing something so if anyone has a good reason why not let me know,

Nick


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

2019-08-16 Thread 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
===
--- 

[Bug c++/64372] [DR1560] Gratuitous lvalue-to-rvalue conversion in conditional-expression with throw-expression operand

2019-08-16 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64372

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work|9.0 |
 Resolution|--- |FIXED
   Target Milestone|--- |10.0

--- Comment #16 from Jason Merrill  ---
Fixed properly for GCC 10.

[Bug c++/90393] [9/10 Regression] ICE in return statement with a conditional operator, one of the second and third arguments is throw, and the other is a const variable of a class with a nontrivial co

2019-08-16 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90393

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #11 from Jason Merrill  ---
Fixed for GCC 10 and 9.3.

[Bug c++/64372] [DR1560] Gratuitous lvalue-to-rvalue conversion in conditional-expression with throw-expression operand

2019-08-16 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64372

--- Comment #15 from Jason Merrill  ---
Author: jason
Date: Sat Aug 17 01:34:00 2019
New Revision: 274597

URL: https://gcc.gnu.org/viewcvs?rev=274597=gcc=rev
Log:
PR c++/90393 - ICE with throw in ?:

I fixed the DR 1560 implementation properly for GCC 10, but for GCC 9 feel
that it's better not to change the meaning of well-formed code.  Reverting
the incomplete implementation fixes the ICEs.

* call.c (build_conditional_expr_1): Revert changes from
PR c++/64372 and c++/86205.

Added:
branches/gcc-9-branch/gcc/testsuite/g++.dg/expr/cond15.C
branches/gcc-9-branch/gcc/testsuite/g++.dg/expr/cond16.C
Removed:
branches/gcc-9-branch/gcc/testsuite/g++.dg/cpp1y/dr1560.C
Modified:
branches/gcc-9-branch/gcc/cp/ChangeLog
branches/gcc-9-branch/gcc/cp/call.c

[Bug c++/90393] [9/10 Regression] ICE in return statement with a conditional operator, one of the second and third arguments is throw, and the other is a const variable of a class with a nontrivial co

2019-08-16 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90393

--- Comment #10 from Jason Merrill  ---
Author: jason
Date: Sat Aug 17 01:34:00 2019
New Revision: 274597

URL: https://gcc.gnu.org/viewcvs?rev=274597=gcc=rev
Log:
PR c++/90393 - ICE with throw in ?:

I fixed the DR 1560 implementation properly for GCC 10, but for GCC 9 feel
that it's better not to change the meaning of well-formed code.  Reverting
the incomplete implementation fixes the ICEs.

* call.c (build_conditional_expr_1): Revert changes from
PR c++/64372 and c++/86205.

Added:
branches/gcc-9-branch/gcc/testsuite/g++.dg/expr/cond15.C
branches/gcc-9-branch/gcc/testsuite/g++.dg/expr/cond16.C
Removed:
branches/gcc-9-branch/gcc/testsuite/g++.dg/cpp1y/dr1560.C
Modified:
branches/gcc-9-branch/gcc/cp/ChangeLog
branches/gcc-9-branch/gcc/cp/call.c

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

2019-08-16 Thread 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

2019-08-16 Thread 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

2019-08-16 Thread 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

2019-08-16 Thread 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

2019-08-16 Thread 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

2019-08-16 Thread 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

2019-08-16 Thread 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

2019-08-16 Thread 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

2019-08-16 Thread 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

2019-08-16 Thread 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.

2019-08-16 Thread 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

2019-08-16 Thread 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
+   

[Bug c++/91477] New: error messages stop including column numbers for large source file

2019-08-16 Thread huili80 at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91477

Bug ID: 91477
   Summary: error messages stop including column numbers for large
source file
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: huili80 at gmail dot com
  Target Milestone: ---

At work we have generated headers that can be millions of lines. While
compiling with gcc-8.2.1, I noticed that I'm not getting column numbers in
error messages, only getting filenames and line numbers.

I initially tried adding -fshow-column but that didn't help.

After experimenting a bit, the problem appears to show up when header files are
large, regardless what code is actually in the headers, and regardless of
whether the code in the headers is related to the code that is erroneous.

I didn't try to find the exact file size to produce this problem, but I
observed that when the pre-processed source file had about 690k lines (~26MB in
size), column numbers were no longer shown in errors.

The only other compiler i had was gcc4.8.2 and I don't have the same problem.

[Bug fortran/88076] Shared Memory implementation for Coarrays

2019-08-16 Thread jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88076

--- Comment #19 from Jerry DeLisle  ---
(In reply to Nicolas Koenig from comment #18)
> Created attachment 46723 [details]
> Compiler Diff
> 
> I accidentally attached an old patch, here is the right one :) And thanks
> for helping, Jerry, what will you be working on?

My first step is to get what you have set up here and get some test cases in
place and try some things, then I can look further at trying to understand.
Then go from there. Will let you know seprately from this PR so we dont clutter
it up here. I also need to coordinate with Steve as we look at it.

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

2019-08-16 Thread 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

2019-08-16 Thread 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

2019-08-16 Thread 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


[Bug fortran/78739] ICE in gfc_get_symbol_decl, at fortran/trans-decl.c:1477

2019-08-16 Thread kargl at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78739

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||kargl at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org

--- Comment #2 from kargl at gcc dot gnu.org ---
I have a patch that detects most cases of a statement function re-using the
name of the containing function.  The only situation that I cannot detect is

function a()
  a() = x
end function

[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds

2019-08-16 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
Bug 56456 depends on bug 35903, which changed state.

Bug 35903 Summary: false Warray-bounds warning when passing quoted string to 
function strcmp(arg,"no");
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35903

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME

[Bug middle-end/35903] false Warray-bounds warning when passing quoted string to function strcmp(arg,"no");

2019-08-16 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35903

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |WORKSFORME

--- Comment #12 from Martin Sebor  ---
I haven't been able to reproduce the false positive with any of the test cases
here, with -O2 or -O3 and with -funsigned-chars or without.  Since there have
been updates in almost a decade I'm going to close this.  If someone still can
reproduce it please either reopen this bug or open a new one and include a test
case that reproduce the warning and compiles without errors.  Also mention the
target for which you are compiling -- at least one of the attachments looks
like it's from a powerpc system.

Go patch committed: Print runtime.hex in hex

2019-08-16 Thread 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())
 


[Bug tree-optimization/91457] FAIL: g++.dg/warn/Warray-bounds-4.C -std=gnu++98 (test for warnings, line 25)

2019-08-16 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91457

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch
   Target Milestone|--- |10.0

--- Comment #4 from Martin Sebor  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2019-08/msg01202.html

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

2019-08-16 Thread 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 

gcc-8-20190816 is now available

2019-08-16 Thread gccadmin
Snapshot gcc-8-20190816 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/8-20190816/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 8 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-8-branch 
revision 274590

You'll find:

 gcc-8-20190816.tar.xzComplete GCC

  SHA256=f5ad4a42df2ce767e050faca2ba8c7c45b72e834fed5afeccdc5071995e020e3
  SHA1=3090a37707212d2deb9deece7fc3885fb3fd4f7b

Diffs from 8-20190809 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-8
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.


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

2019-08-16 Thread 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

2019-08-16 Thread 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

2019-08-16 Thread 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

2019-08-16 Thread 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

2019-08-16 Thread 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 } }  */


[Bug target/91472] gmp testsuite segfaults with gcc-8 and gcc-9, works fine with gcc-7

2019-08-16 Thread matorola at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91472

--- Comment #1 from Anatoly Pugachev  ---
compiling under gcc-8 but without "-O2" in CFLAGS makes it PASS instead of FAIL
(segfault).

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

2019-08-16 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81676

Marek Polacek  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #5 from Marek Polacek  ---
Well, patch posted: https://gcc.gnu.org/ml/gcc-patches/2019-08/msg01196.html

I'm not very optimistic about it being accepted, but so far no one has
submitted anything better.

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

2019-08-16 Thread 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

2019-08-16 Thread 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


[Bug c++/90885] GCC should warn about 2^16 and 2^32 and 2^64

2019-08-16 Thread david.bolvansky at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90885

--- Comment #20 from Dávid Bolvanský  ---
Clang implemented [0] this diagnostic under -Wxor-used-as-pow.
From user perspective it would be reasonable if GCC follows this naming.

[0] https://reviews.llvm.org/D63423

[Bug c++/91475] Optimization causes infinite loop

2019-08-16 Thread eric_musser at yahoo dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91475

--- Comment #2 from Eric Musser  ---
But in this case the undefineness is not directly related to the for loop.
Further the optimizer that changes the loop to maintain and compare j *
0x2001 as opposed to just j could detect certain overflow as the upperbound
for the loop is a constant (j < 9) -- since 9 * 0x2001 > (1<<31). In this
case the optimization could either be disabled or produce a warning. The fact
the end-condition of the for loop is optimized away completely suggests this is
not a runtime issue (the infinite loop is hardcoded into resulting assembly).

In the case the upperbound of the for loop is variable I agree it is not
possible to detect nor may it be worth disabling the optimization if there is
only a chance of overflow.

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

2019-08-16 Thread 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


[Bug c++/89179] compiler error: in ggc_set_mark, at ggc-page.c:1532

2019-08-16 Thread sje at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89179

--- Comment #16 from Steve Ellcey  ---
I built ggc-page.c with GCC_DEBUG_LEVEL 5 and I see:

Allocating object, requested size=360, actual=360 at 0x8726c210 on
0x10549200
Freeing object, actual size=360, at 0x8726c210 on 0x10549200

But then I wind up calling gt_ggc_mx_symtab_node with x_p of 0x8726c210.
I don't think I should be calling this (via ggc_mark_roots and  ggc_collect) if
it has already been freed.

[Bug fortran/88076] Shared Memory implementation for Coarrays

2019-08-16 Thread koenigni at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88076

Nicolas Koenig  changed:

   What|Removed |Added

  Attachment #46714|0   |1
is obsolete||

--- Comment #18 from Nicolas Koenig  ---
Created attachment 46723
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46723=edit
Compiler Diff

I accidentally attached an old patch, here is the right one :) And thanks for
helping, Jerry, what will you be working on?

[Bug c++/85827] false positive for -Wunused-but-set-variable because of constexpr-if

2019-08-16 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85827

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #6 from Marek Polacek  ---
Done.

[Bug c++/85827] false positive for -Wunused-but-set-variable because of constexpr-if

2019-08-16 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85827

--- Comment #5 from Marek Polacek  ---
Author: mpolacek
Date: Fri Aug 16 20:40:36 2019
New Revision: 274587

URL: https://gcc.gnu.org/viewcvs?rev=274587=gcc=rev
Log:
PR c++/85827
g++.dg/cpp1z/constexpr-if29.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp1z/constexpr-if29.C
Modified:
trunk/gcc/cp/ChangeLog

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

2019-08-16 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89180
Bug 89180 depends on bug 85827, which changed state.

Bug 85827 Summary: false positive for -Wunused-but-set-variable because of 
constexpr-if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85827

   What|Removed |Added

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

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

2019-08-16 Thread 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>();
+}


[Bug fortran/91473] [10 regression] test case libgomp.fortran/appendix-a/a.28.5.f90 fails starting with r274551

2019-08-16 Thread seurer at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91473

--- Comment #5 from seurer at gcc dot gnu.org ---
For what it's worth several spec 2000 tests also won't compile any more after
this revision.

I guess -std=legacy all around!

[libsanitizer, committed] Reapply r272406.

2019-08-16 Thread 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



[Bug c++/91475] Optimization causes infinite loop

2019-08-16 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91475

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Andrew Pinski  ---
Signed integer overflow is undefined at runtime; this means we cannot error out
when it happens at compile time.  The warning is not done for loops on purpose
since those are normally places where the user wants to take advantage of the
undefineness.

Use -fsanitize=undefined to find it at runtime.
It is hard sometimes to find that the code will run into this code.

[Bug c++/91476] New: const reference variables sharing the same name in two anonymous namespaces cause a multiple definition error

2019-08-16 Thread abbeyj+gcc at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91476

Bug ID: 91476
   Summary: const reference variables sharing the same name in two
anonymous namespaces cause a multiple definition error
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: abbeyj+gcc at gmail dot com
  Target Milestone: ---

There is a problem when having two different variables both of which are const
references and which have the same name but are in different anonymous
namespaces.  You'll need at least two files to reproduce this, say a.cpp and
b.cpp.

a.cpp:
namespace { const int  = 1; }
int main() {}

b.cpp:
namespace { const int  = 2; }


Then compile and link:
$ g++ -c a.cpp b.cpp
$ g++ a.o b.o
b.o:(.rodata+0x0): multiple definition of `_ZGRN12_GLOBAL__N_13fooE_'
a.o:(.rodata+0x0): first defined here
collect2: error: ld returned 1 exit status


This works fine in older versions of GCC and in clang.

Looking at the output on https://gcc.godbolt.org/z/A6LxAG shows the following
differences:
- The mangled name for "reference temporary #0 for (anonymous namespace)::foo"
changed from _ZGRN12_GLOBAL__N_13fooE0 to _ZGRN12_GLOBAL__N_13fooE_. 
Interestingly, godbolt.org is unable to demangle the second name.
- There is an additional line `.globl  _ZGRN12_GLOBAL__N_13fooE_`.  This seems
like the part causing the issue.

I originally found this when using objects of class type with user-defined
constructors.  I reduced it down to using `int` for this bug report.  Any
proposed fix should probably be tested with such types in addition to plain
`int`.


gcc version 9.1.0 (GCC)
Target: x86_64-pc-linux-gnu

[Bug c++/91475] New: Optimization causes infinite loop

2019-08-16 Thread eric_musser at yahoo dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91475

Bug ID: 91475
   Summary: Optimization causes infinite loop
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric_musser at yahoo dot com
  Target Milestone: ---

The following code on x86-64 9.2.0 compiled with:

gcc -Wall -O2

unexpectedly produces wrong output and an infinite loop:

#include 
#include 

int main(int argc, char** argv) {
char buf[50];
for (int j = 0; j < 9; ++j) {
  std::cout << (j * 0x2001) << " " << j << std::endl;
  sprintf(buf, "%d", j);
}
return 0;
}

Output (truncated) is:
0 0

536870913 1
1073741826 2
1610612739 3
-2147483644 4
-1610612731 5
-1073741818 6
-536870905 7
8 8
536870921 9
1073741834 10
1610612747 11
-2147483636 12
-1610612723 13
...

The sprintf is present only to prevent the loop from being unrolled (and the
issue doesn't occur). The issue appears to because the code is being optimized
roughly as:

int main(int argc, char** argv) {
char buf[50];
for (int j = 0, running_j = 0; running_j != 9 * 0x2001LL ; running_j +=
0x2001, ++j) {
  std::cout << running_j << " " << j << std::endl;
  sprintf(buf, "%d", j);
}
return 0;
}


It loops because running_j is int32 and cannot possibly equal the pre-computed
total. The optimizer actually detects this and removes the end condition of the
for loop completely.

I realize the code is invoking undefined behavior because of signed overflow
with j * 0x2001LL but it seems either the compiler should error/warning
because of this or the for loop optimization should not happen. Without, the
sprintf I do see a warning of undefined behavior (in loop iteration 4).

I see other bugs similar to this but this is the only I see with a hardcoded
constant as the end condition of the for loop.

[Bug c++/85827] false positive for -Wunused-but-set-variable because of constexpr-if

2019-08-16 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85827

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org

--- Comment #4 from Marek Polacek  ---
This particular problem was fixed in r269433, because the condition is not
dependent.  I'll add the test.  For another problem not fixed by this rev see
PR81676.

[Bug c++/91474] New: Internal compiler error when building mabi=32 mips64-elf cross-compiler: segfault in parallel_settings.cc

2019-08-16 Thread joey.dumont at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91474

Bug ID: 91474
   Summary: Internal compiler error when building mabi=32
mips64-elf cross-compiler: segfault in
parallel_settings.cc
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: joey.dumont at gmail dot com
CC: joey.dumont at gmail dot com
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: mips64-elf
 Build: x86_64-pc-linux-gnu

Created attachment 46722
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46722=edit
Patch to enable the 32-bit ABI

Let me preface this by saying that this is my first bug report, and I could not
find information on what to submit for issues with cross-compilers. Let me know
what information you need and I'll gladly provide it.

When trying to build a gcc-9.2.0 mips64-elf cross-compiler with gcc-9.1.0, I
get an internal compiler error when trying to compile
`libstdc++-v3/src/c++98/parallel_settings.cc`: 

```
libtool: compile: 
/home/valandil/software/n64-dev/mips64-elf-gcc/src/build-gcc/./gcc/xgcc
-shared-libgcc
-B/home/valandil/software/n64-dev/mips64-elf-gcc/src/build-gcc/./gcc
-nostdinc++
-L/home/valandil/software/n64-dev/mips64-elf-gcc/src/build-gcc/mips64-elf/32/libstdc++-v3/src
-L/home/valandil/software/n64-dev/mips64-elf-gcc/src/build-gcc/mips64-elf/32/libstdc++-v3/src/.libs
-L/home/valandil/software/n64-dev/mips64-elf-gcc/src/build-gcc/mips64-elf/32/libstdc++-v3/libsupc++/.libs
-B/usr/mips64-elf/bin/ -B/usr/mips64-elf/lib/ -isystem /usr/mips64-elf/include
-isystem /usr/mips64-elf/sys-include -mabi=32
-I/home/valandil/software/n64-dev/mips64-elf-gcc/src/gcc-9.2.0/libstdc++-v3/../libgcc
-I/home/valandil/software/n64-dev/mips64-elf-gcc/src/build-gcc/mips64-elf/32/libstdc++-v3/include/mips64-elf
-I/home/valandil/software/n64-dev/mips64-elf-gcc/src/build-gcc/mips64-elf/32/libstdc++-v3/include
-I/home/valandil/software/n64-dev/mips64-elf-gcc/src/gcc-9.2.0/libstdc++-v3/libsupc++
-std=gnu++98 -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual
-Wabi=2 -fdiagnostics-show-location=once -ffunction-sections -fdata-sections
-frandom-seed=parallel_settings.lo -g -O2 -mabi=32 -D_GLIBCXX_PARALLEL -c
/home/valandil/software/n64-dev/mips64-elf-gcc/src/gcc-9.2.0/libstdc++-v3/src/c++98/parallel_settings.cc
-o parallel_settings.o
during RTL pass: split2
/home/valandil/software/n64-dev/mips64-elf-gcc/src/gcc-9.2.0/libstdc++-v3/src/c++98/parallel_settings.cc:
In function '(static initializers for
/home/valandil/software/n64-dev/mips64-elf-gcc/src/gcc-9.2.0/libstdc++-v3/src/c++98/parallel_settings.cc)':
/home/valandil/software/n64-dev/mips64-elf-gcc/src/gcc-9.2.0/libstdc++-v3/src/c++98/parallel_settings.cc:42:1:
internal compiler error: Segmentation fault
   42 | }
  | ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[9]: *** [Makefile:912: parallel_settings.lo] Error 1
make[9]: Leaving directory
'/home/valandil/software/n64-dev/mips64-elf-gcc/src/build-gcc/mips64-elf/32/libstdc++-v3/src/c++98'
make[8]: *** [Makefile:730: all-recursive] Error 1
make[8]: Leaving directory
'/home/valandil/software/n64-dev/mips64-elf-gcc/src/build-gcc/mips64-elf/32/libstdc++-v3/src'
make[7]: *** [Makefile:562: all-recursive] Error 1
make[7]: Leaving directory
'/home/valandil/software/n64-dev/mips64-elf-gcc/src/build-gcc/mips64-elf/32/libstdc++-v3'
make[6]: *** [Makefile:487: all] Error 2
make[6]: Leaving directory
'/home/valandil/software/n64-dev/mips64-elf-gcc/src/build-gcc/mips64-elf/32/libstdc++-v3'
make[5]: *** [Makefile:855: multi-do] Error 1
make[5]: Leaving directory
'/home/valandil/software/n64-dev/mips64-elf-gcc/src/build-gcc/mips64-elf/libstdc++-v3'
make[4]: *** [Makefile:823: all-multi] Error 2
make[4]: Leaving directory
'/home/valandil/software/n64-dev/mips64-elf-gcc/src/build-gcc/mips64-elf/libstdc++-v3'
make[3]: *** [Makefile:562: all-recursive] Error 1
make[3]: Leaving directory
'/home/valandil/software/n64-dev/mips64-elf-gcc/src/build-gcc/mips64-elf/libstdc++-v3'
make[2]: *** [Makefile:487: all] Error 2
make[2]: Leaving directory
'/home/valandil/software/n64-dev/mips64-elf-gcc/src/build-gcc/mips64-elf/libstdc++-v3'
make[1]: *** [Makefile:11232: all-target-libstdc++-v3] Error 2
make[1]: Leaving directory
'/home/valandil/software/n64-dev/mips64-elf-gcc/src/build-gcc'
make: *** [Makefile:951: all] Error 2
```

Here's the output of `gcc -v`:

```
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/9.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info

[Bug fortran/91471] f951: internal compiler error: gfc_variable_attr(): Bad array reference

2019-08-16 Thread kargl at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91471

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords|ice-on-valid-code   |
   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-08-16
 CC||kargl at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from kargl at gcc dot gnu.org ---
I have a patch that prevents the ICE.  Remove ICE-on-valid-code
tag as the code is invalid.

[Bug fortran/91473] [10 regression] test case libgomp.fortran/appendix-a/a.28.5.f90 fails starting with r274551

2019-08-16 Thread tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91473

--- Comment #4 from Thomas Koenig  ---
(In reply to seurer from comment #0)
> make -k check-target-libgomp
> RUNTESTFLAGS=fortran.exp=libgomp.fortran/appendix-a/a.28.5.f90
> 
> FAIL: libgomp.fortran/appendix-a/a.28.5.f90   -O  (test for excess errors)

Easy enough to "fix" with

Index: testsuite/libgomp.fortran/appendix-a/a.28.5.f90  
=== 
--- testsuite/libgomp.fortran/appendix-a/a.28.5.f90 (Revision 274370)   
+++ testsuite/libgomp.fortran/appendix-a/a.28.5.f90 (Arbeitskopie)  
@@ -1,5 +1,5 @@ 
 ! { dg-do compile }
-! { dg-options "-w" }  
+! { dg-options "-w -std=legacy" }  
 !  
 ! "-w" added as libgomp/testsuite seemingly cannot parse with  
 ! dg-warning Fortran's output. Fortran warns for "call sub1(a)" 

but the real problem is that this is illegal Fortran. You cannot have
mismatching ranks in an argument, even if it "happens" to work.

Same thing with the SPEC code, I suppose.

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

2019-08-16 Thread 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

2019-08-16 Thread 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

2019-08-16 Thread 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.



[Bug tree-optimization/91109] [10 regression][arm] gcc.c-torture/execute/20040709-1.c fails since r273135

2019-08-16 Thread bernd.edlinger at hotmail dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91109

--- Comment #19 from Bernd Edlinger  ---
Hope all is now working again.

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

2019-08-16 Thread 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

2019-08-16 Thread 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.




[Bug fortran/88076] Shared Memory implementation for Coarrays

2019-08-16 Thread jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88076

--- Comment #17 from Jerry DeLisle  ---
I am getting this at the moment after applying patches to trunk.

../../trunk/gcc/fortran/trans-stmt.c: In function ‘tree_node*
gfc_trans_deallocate(gfc_code*)’:
../../trunk/gcc/fortran/trans-stmt.c:6925:4: error: ‘is_native_coarray’ was not
declared in this scope
 6925 |is_native_coarray = ar_attr.codimension;
  |^
../../trunk/gcc/fortran/trans-stmt.c:6928:45: error: ‘is_native_coarray’ was
not declared in this scope
 6928 |   if (expr->rank || is_coarray_array || is_native_coarray)
  | ^
make[2]: *** [Makefile:1118: fortran/trans-stmt.o] Error 1
make[2]: *** Waiting for unfinished jobs
make[1]: *** [Makefile:4360: all-gcc] Error 2
make: *** [Makefile:958: all] Error 2

[Bug tree-optimization/91109] [10 regression][arm] gcc.c-torture/execute/20040709-1.c fails since r273135

2019-08-16 Thread edlinger at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91109

--- Comment #18 from Bernd Edlinger  ---
Author: edlinger
Date: Fri Aug 16 16:37:04 2019
New Revision: 274578

URL: https://gcc.gnu.org/viewcvs?rev=274578=gcc=rev
Log:
2019-08-16  Bernd Edlinger  

Backport from mainline
2019-08-16  Bernd Edlinger  

PR tree-optimization/91109
* lra-int.h (lra_need_for_scratch_reg_p): Declare.
* lra.c (lra): Use lra_need_for_scratch_reg_p.
* lra-spills.c (lra_need_for_scratch_reg_p): New function.

Modified:
branches/gcc-9-branch/gcc/ChangeLog
branches/gcc-9-branch/gcc/lra-int.h
branches/gcc-9-branch/gcc/lra-spills.c
branches/gcc-9-branch/gcc/lra.c

[Bug tree-optimization/91109] [10 regression][arm] gcc.c-torture/execute/20040709-1.c fails since r273135

2019-08-16 Thread edlinger at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91109

--- Comment #17 from Bernd Edlinger  ---
Author: edlinger
Date: Fri Aug 16 16:31:13 2019
New Revision: 274577

URL: https://gcc.gnu.org/viewcvs?rev=274577=gcc=rev
Log:
2019-08-16  Bernd Edlinger  

Backport from mainline
2019-08-07  Bernd Edlinger  

PR tree-optimization/91109
* lra-remat.c (update_scratch_ops): Remove assignment of the
hard register.

Modified:
branches/gcc-9-branch/gcc/ChangeLog
branches/gcc-9-branch/gcc/lra-remat.c

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

2019-08-16 Thread 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 

[Bug fortran/68401] improve 'Allocation would exceed memory limit'

2019-08-16 Thread jb at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68401

Janne Blomqvist  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/ml/gcc-
   ||patches/2019-08/msg01172.ht
   ||ml

--- Comment #12 from Janne Blomqvist  ---
Patch at https://gcc.gnu.org/ml/gcc-patches/2019-08/msg01172.html

With this the test.f90 in the original report prints something like:

In file 'test.f90', around line 5: Error allocating 4294967296 bytes: Cannot
allocate memory

Error termination. Backtrace:
#0  0x400874 in test
at /home/janne/src/gfortran/my-patches/pr68401-oserror/test.f90:4
#1  0x4008d3 in main
at /home/janne/src/gfortran/my-patches/pr68401-oserror/test.f90:4


(yes, the location is off a little bit)

[Bug tree-optimization/18487] Warnings for pure and const functions that are not actually pure or const

2019-08-16 Thread david.bolvansky at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18487

Dávid Bolvanský  changed:

   What|Removed |Added

 CC||david.bolvansky at gmail dot 
com

--- Comment #18 from Dávid Bolvanský  ---
a.c

int foo(void) __attribute__((const));


int main(void) {
return foo();
}

b.c

#include 

int foo(void) {
puts("BUM");
return 0;
}

gcc a.c b.c -Wall -Wextra -flto -o bum


It would be nice to get a warning.

[Bug fortran/88076] Shared Memory implementation for Coarrays

2019-08-16 Thread jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88076

--- Comment #16 from Jerry DeLisle  ---
(In reply to Steve Kargl from comment #15)
> On Wed, Aug 14, 2019 at 08:33:04PM +, koenigni at gcc dot gnu.org wrote:
> > 
> > Yes, I'm still working on it (slowly, though, sorry :( ). Here is a diff of 
> > my
> > current trunk. I don't know what exactly changed since the last version, but
> > the biggest two things still missing are actually deallocating coarrays in
> > DEALLOCATE-statements or in types and all the intrinsics like CO_SUM. Locks
> > already work, though.
> 
> Thanks for the update.  No need to apologize.  I assume you
> are off doing work, school, fun stuff, ...
> 
> I'm running out of bugs that I can fix, so thought I would
> venture into coarray territory.  Having a SHM backend might
> be easier to work with than opencoarray and openmpi.

I will be loading up these patches on my new machine here to as well. so we
start to grind away on this.

[Bug preprocessor/77672] wrong rich location in warning: writing a terminating nul past the end

2019-08-16 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77672

Martin Sebor  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
  Known to work||7.1.0
 Resolution|--- |FIXED
  Known to fail||7.0

--- Comment #9 from Martin Sebor  ---
The output looks good now and has since 7.1 so we can resolve this bug.

Re: types for VR_VARYING

2019-08-16 Thread 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.

2019-08-16 Thread 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


[Bug libstdc++/90415] [9/10 Regression] std::is_copy_constructible> is incomplete

2019-08-16 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90415

--- Comment #9 from Jonathan Wakely  ---
(In reply to Lei YU from comment #7)
> Additional information.
> 
> std::experimental::fundamentals_v1::any has no problem, so the below code
> compiles fine.

The difference is that std::experimental::any doesn't constrain the any(T&&)
constructor on is_copy_constructible, instead it just makes it a hard error
(using a static assert in the constructor body).

std::any has to SFINAE the any(T&&) constructor away if T is not copy
constructible, which leads to a cycle when that constructor is being considered
during instantiation of is_copy_constructible.

[Bug testsuite/91458] FAIL: g++.dg/tree-ssa/pr19807.C -std=gnu++98 scan-tree-dump-times optimized "\\\\[\\\\(void .\\\\) \\\\+ 8B\\\\]" 3

2019-08-16 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91458

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #5 from Martin Sebor  ---
I've made the change in r274574.

[Bug testsuite/91458] FAIL: g++.dg/tree-ssa/pr19807.C -std=gnu++98 scan-tree-dump-times optimized "\\\\[\\\\(void .\\\\) \\\\+ 8B\\\\]" 3

2019-08-16 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91458

--- Comment #4 from Martin Sebor  ---
Author: msebor
Date: Fri Aug 16 15:47:25 2019
New Revision: 274574

URL: https://gcc.gnu.org/viewcvs?rev=274574=gcc=rev
Log:
PR testsuite/91458

gcc/testsuite/ChangeLog:

* g++.dg/tree-ssa/pr19807.C: Use the same search pattern
unconditionally (correcting r272199, PR middle-end/90676).


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/tree-ssa/pr19807.C

[Bug middle-end/90676] default GIMPLE dumps lack information

2019-08-16 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90676

--- Comment #10 from Martin Sebor  ---
Author: msebor
Date: Fri Aug 16 15:47:25 2019
New Revision: 274574

URL: https://gcc.gnu.org/viewcvs?rev=274574=gcc=rev
Log:
PR testsuite/91458

gcc/testsuite/ChangeLog:

* g++.dg/tree-ssa/pr19807.C: Use the same search pattern
unconditionally (correcting r272199, PR middle-end/90676).


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/tree-ssa/pr19807.C

Re: [patch] Add guard to build_reconstructed_reference

2019-08-16 Thread 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


[Bug libstdc++/91456] std::function and std::is_invocable_r do not understand guaranteed elision

2019-08-16 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91456

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |9.3

--- Comment #3 from Jonathan Wakely  ---
Fixed on trunk so far, but I'd like to backport this for 9.3 too.

[Bug libstdc++/91371] std::bind and bind_front don't work with function with call convention

2019-08-16 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91371

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||patch, rejects-valid
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org

--- Comment #7 from Jonathan Wakely  ---
Patch posted: https://gcc.gnu.org/ml/gcc-patches/2019-08/msg01181.html

Re: [PATCH] Automatics in equivalence statements

2019-08-16 Thread 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



[Bug rtl-optimization/91347] [7/8/9/10 Regression] pointer_string in linux vsprintf.c is miscompiled when sibling calls are optimized

2019-08-16 Thread danglin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91347

--- Comment #10 from John David Anglin  ---
(In reply to Eric Botcazou from comment #6)
> This looks similar to PR target/55023.

Yes.  Looking at how scan_insn() evolved since PR target/55023, it is
clear why this is a regression.

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

2019-08-16 Thread 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.
* 

[Bug tree-optimization/91109] [10 regression][arm] gcc.c-torture/execute/20040709-1.c fails since r273135

2019-08-16 Thread edlinger at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91109

--- Comment #16 from Bernd Edlinger  ---
Author: edlinger
Date: Fri Aug 16 15:34:47 2019
New Revision: 274573

URL: https://gcc.gnu.org/viewcvs?rev=274573=gcc=rev
Log:
2019-08-16  Bernd Edlinger  

PR tree-optimization/91109
* lra-int.h (lra_need_for_scratch_reg_p): Declare.
* lra.c (lra): Use lra_need_for_scratch_reg_p.
* lra-spills.c (lra_need_for_scratch_reg_p): New function.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-int.h
trunk/gcc/lra-spills.c
trunk/gcc/lra.c

[Bug testsuite/91458] FAIL: g++.dg/tree-ssa/pr19807.C -std=gnu++98 scan-tree-dump-times optimized "\\\\[\\\\(void .\\\\) \\\\+ 8B\\\\]" 3

2019-08-16 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91458

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org

--- Comment #3 from Martin Sebor  ---
Let me fix it.

[Bug testsuite/91458] FAIL: g++.dg/tree-ssa/pr19807.C -std=gnu++98 scan-tree-dump-times optimized "\\\\[\\\\(void .\\\\) \\\\+ 8B\\\\]" 3

2019-08-16 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91458

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Sebor  ---
I think it's just a mistake in the pattern:

/* { dg-final { scan-tree-dump-times "\\\[\\\(void .\\\) \\\+ 8B\\\]" 3
"optimized" { target { ! store_merge } } } }
   { dg-final { scan-tree-dump-times "  \\\[\\\(void .\\\) \\\+
8B\\\]" 3 "optimized" { target { store_merge } } } } */

No store merging takes place here so the test should use the second pattern
unconditionally.

[Bug fortran/91473] [10 regression] test case libgomp.fortran/appendix-a/a.28.5.f90 fails starting with r274551

2019-08-16 Thread hjl.tools at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91473

--- Comment #3 from H.J. Lu  ---
It looks like -std=legacy is needed for wrf.

[Bug fortran/91473] [10 regression] test case libgomp.fortran/appendix-a/a.28.5.f90 fails starting with r274551

2019-08-16 Thread hjl.tools at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91473

--- Comment #2 from H.J. Lu  ---
In case of wrf, there are

  INTEGER  :: Field(*)
  INTEGER  :: FieldType
...
 ELSE IF ( FieldType .EQ. WRF_INTEGER ) THEN

 CALL call_pkg_and_dist_int ( fcn,&
   Hndl , DateStr , VarName , Field , FieldType , Comm , IOComm , &
   DomainDesc , MemoryOrder , Stagger , DimNames ,  &
   DomainStart , DomainEnd ,&
   MemoryStart , MemoryEnd ,&
   PatchStart , PatchEnd ,  &
   Status )

call_pkg_and_dist_int has

  REAL,   INTENT(INOUT):: Field(*)
  INTEGER   ,INTENT(IN):: FieldType

Field is used as some kind of generic pointer.

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

2019-08-16 Thread 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

2019-08-16 Thread 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




[Bug fortran/91473] [10 regression] test case libgomp.fortran/appendix-a/a.28.5.f90 fails starting with r274551

2019-08-16 Thread hjl.tools at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91473

H.J. Lu  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #1 from H.J. Lu  ---
481.wrf in SPEC CPU 2006 also got

Error: Type mismatch in argument 'field' at (1); passed INTEGER(4) to REAL(4)
module_io.fppized.f90:18713:23:

18713 |Status )
  |   1

  1   2   >