date:20160817


On 08/12/2016 07:31 AM, Martin Liška wrote:

On 08/09/2016 09:03 PM, Andi Kleen wrote:

It could potentially make things a lot slower. I don't think it's a good
idea to do this by default.

-Andi


Ok, alternative can be a warning in the driver that would inform a user
that combining -pthread and -fprofile-update=single can lead to profile 
corruption.
My first attempt with option handling gcc.c was not successful, I'll try it 
once.

Is it reasonable approach?
I'd prefer to make updates atomic in multi-threaded applications.  The 
best proxy we have for that is -pthread.


Is it slower, most definitely, but odds are we're giving folks garbage 
data otherwise, which in many ways is even worse.


jeff

Re: RFC: A few more fallthrus


On 08/16/2016 10:59 AM, Marek Polacek wrote:

On Thu, Aug 11, 2016 at 04:49:30PM +0200, Marek Polacek wrote:

A few more cases where I'm unsure whether the fall through is intended.
Jason, can you please look at the cp/ part?


Given Jason is on PTO this week, can I just commit the patch as-is, modulo
the already-committed tree-complex.c part?  We can always revisit these few
cases later.  It'd make my next patch submission more manageable.


Richi, would you mind looking at the tree-complex.c bit?
What 'bout the pch.c?

Thanks,

2016-08-11  Marek Polacek  

PR c/7652
gcc/
* tree-complex.c (expand_complex_division): Likewise.
gcc/cp/
* call.c (add_builtin_candidate): Add gcc_fallthrough.
* cxx-pretty-print.c (pp_cxx_unqualified_id): Likewise.
* parser.c (cp_parser_skip_to_end_of_statement): Likewise.
(cp_parser_cache_defarg): Likewise.
libcpp/
* pch.c (write_macdef): Add CPP_FALLTHRU.
They obviously don't change behavior, so they're safe in that sense. 
And you've got a marker so you can find them later or anyone else 
looking at the code knows we weren't sure on these.


OK.
jeff

Re: [PATCH][6.2] Fix build error with in-tree ISL for GCC 4.3 host compiler


On 08/17/2016 05:33 AM, Richard Biener wrote:


The ISL version we download from download_prerequesites on the GCC 6
branch (0.15) has a trailing comma at the end of an enumerator list.
This causes GCC 4.3.4 to error as we are compiling with -pedantic
(GCC 4.4 and up just warn).  The following fixes this bootstrap issue
by patching the ISL sources after downloading them.

Tested on SLE11 SP4 with GCC 4.3.4 host compiler (where I also reproduced
the issue).

As we control ftp://gcc.gnu.org/pub/gcc/infrastructure/isl-0.15.tar.bz2
the sed expression is quite simplistic.

Ok for the GCC 6 branch?

I hope mv can reliably overwrite the destination on all supported
hosts (not sure if -f is portable).  I can use cp as well, of course.
I hope && outside of 'if' is portable as well.

Thanks,
Richard.

2016-08-17  Richard Biener  

* download_prerequisites: Patch ISL 0.15 to remove trailing comma
which causes PR77297.

Seems reasonable to me.

Jeff

Re: [PATCH] [GCC] Don't use section anchors for declarations that don't fit in a single anchor range


On 08/17/2016 02:23 AM, Richard Biener wrote:

On Tue, Aug 16, 2016 at 6:06 PM, Jeff Law  wrote:

On 08/16/2016 08:01 AM, Tamar Christina wrote:



Hi All,

This patch turns off the usage of section anchors for
declarations that do not fit in a single anchor range.
A large enough object will use the full anchor range
and also force the use of another anchor pointer.

By not using an anchor for large objects more globals
can share the same anchor.

The patch has been benchmarked using Spec2000 and
the impact on performance is negligible, however some files
using large arrays showed a appreciable reduction in amount of
instructions in the assembly file.

Regression tests were run on aarch64-none-elf and no regressions.

Ok for trunk?

2016-08-16  Tamar Christina  
Ramana Radhakrishnan  

* gcc/varasm.c
(default_use_anchors_for_symbol_p): Reject too large decls.


Do you have to worry about DECL_SIZE being non-constant here or are those
filtered out earlier?


Globals can't have variable size.

Duh.  You're obviously correct.

Patch is OK for the trunk.

jeff

[patch,gomp4] fix pr70828

2016-08-17 Thread Cesar Philippidis

In OpenACC, if an offloaded region is lexically nested inside an acc
data region, then those variables should technically be marked as
present. For the most part we can get away with a simpler analysis and
making those variables present_or_copy, as that is the default for array
variables. However, that scheme falls apart when the data region
contains a data clause for a subarray of a local array. The problem
there is, the data region transfers the subarray to the accelerator, but
the offloaded region expects the entire local array to be present on the
device. And since only part of the array resides on the device, the
runtime ultimately generates an error for unmapped data.

There are two separate cases that are addressed in this patch. 1) The
creation of present and firstprivate_pointer data clauses for C and C++
subarrays and 2) the creation of a pointer data clause for fortran
subarrays. I suspect that fortran will eventually utilize firstprivate
pointers for subarrays too, but then this patch would stop working
because the fortran FE uses an separate internal pointer for the array
data, that doesn't correspond to the actual array decl like it does it
does in C/C++.

In the meantime, I'll apply this WIP patch to gomp-4_0-branch.

Cesar
2016-08-17  Cesar Philippidis  

	PR middle-end/70828

	gcc/
	* gimplify.c (struct gimplify_omp_ctx): Add tree clauses member.
	(new_omp_context): Initialize clauses to NULL_TREE.
	(gimplify_scan_omp_clauses): Set clauses in the gimplify_omp_ctx.
	(omp_clause_matching_array_ref): New function.
	(gomp_needs_data_present): New function.
	(gimplify_adjust_omp_clauses_1): Use preset or pointer omp clause map
	kinds when creating implicit data clauses for OpenACC offloaded
	variables defined used an acc data region as necessary. 

	libgomp/
	* testsuite/libgomp.oacc-c-c++-common/pr70828.c: New test.
	* testsuite/libgomp.oacc-fortran/pr70828.f90: New test.


diff --git a/gcc/gimplify.c b/gcc/gimplify.c
index 717b25f..9efb907 100644
--- a/gcc/gimplify.c
+++ b/gcc/gimplify.c
@@ -180,6 +180,7 @@ struct gimplify_omp_ctx
   bool target_map_scalars_firstprivate;
   bool target_map_pointers_as_0len_arrays;
   bool target_firstprivatize_array_bases;
+  tree clauses;
 };
 
 static struct gimplify_ctx *gimplify_ctxp;
@@ -396,6 +397,7 @@ new_omp_context (enum omp_region_type region_type)
   c->privatized_types = new hash_set;
   c->location = input_location;
   c->region_type = region_type;
+  c->clauses = NULL_TREE;
   if ((region_type & ORT_TASK) == 0)
 c->default_kind = OMP_CLAUSE_DEFAULT_SHARED;
   else
@@ -6546,6 +6548,7 @@ gimplify_scan_omp_clauses (tree *list_p, gimple_seq *pre_p,
   tree *prev_list_p = NULL;
 
   ctx = new_omp_context (region_type);
+  ctx->clauses = *list_p;
   outer_ctx = ctx->outer_context;
   if (code == OMP_TARGET && !lang_GNU_Fortran ())
 {
@@ -7694,6 +7697,58 @@ struct gimplify_adjust_omp_clauses_data
   gimple_seq *pre_p;
 };
 
+/* Return true if clause contains an array_ref of DECL.  */
+
+static bool
+omp_clause_matching_array_ref (tree clause, tree decl)
+{
+  tree cdecl = OMP_CLAUSE_DECL (clause);
+
+  if (TREE_CODE (cdecl) != ARRAY_REF)
+return false;
+
+  return TREE_OPERAND (cdecl, 0) == decl;
+}
+
+/* Inside OpenACC parallel and kernels regions, the implicit data
+   clauses for arrays must respect the explicit data clauses set by a
+   containing acc data region.  Specifically, care must be taken
+   pointers or if an subarray of a local array is specified in an acc
+   data region, so that the referenced array inside the offloaded
+   region has a present data clasue for that array with an
+   approporiate subarray argument.  This function returns the tree
+   node of the acc data clause that utilizes DECL as an argument.  */
+
+static tree
+gomp_needs_data_present (tree decl)
+{
+  gimplify_omp_ctx *ctx = NULL;
+  bool found_match = false;
+  tree c = NULL_TREE;
+
+  if (TREE_CODE (TREE_TYPE (decl)) != ARRAY_TYPE)
+return NULL_TREE;
+
+  if (gimplify_omp_ctxp->region_type != ORT_ACC_PARALLEL
+  && gimplify_omp_ctxp->region_type != ORT_ACC_KERNELS)
+return NULL_TREE;
+
+  for (ctx = gimplify_omp_ctxp->outer_context; !found_match && ctx;
+   ctx = ctx->outer_context)
+{
+  if (ctx->region_type != ORT_ACC_DATA)
+	break;
+
+  for (c = ctx->clauses; c; c = OMP_CLAUSE_CHAIN (c))
+	if (OMP_CLAUSE_CODE (c) == OMP_CLAUSE_MAP
+	&& (omp_clause_matching_array_ref (c, decl)
+		|| OMP_CLAUSE_MAP_KIND (c) == GOMP_MAP_POINTER))
+	  return c;
+}
+
+  return NULL_TREE;
+}
+
 /* For all variables that were not actually used within the context,
remove PRIVATE, SHARED, and FIRSTPRIVATE clauses.  */
 
@@ -7806,10 +7861,54 @@ gimplify_adjust_omp_clauses_1 (splay_tree_node n, void *data)
   int kind = (flags & GOVD_MAP_TO_ONLY
 		  ? GOMP_MAP_TO
 		  : GOMP_MAP_TOFROM);
+  tree c2 = NULL_TREE;
   if (flags & GOVD_MAP_FORCE)
 	kind |= GOMP_MAP_FLAG_FORCE;

Re: [PATCH] Fix caret locations in format_type_warning (PR c/72857)

2016-08-17 Thread David Malcolm

On Wed, 2016-08-17 at 09:51 -0400, David Malcolm wrote:
> On Wed, 2016-08-17 at 10:12 +0200, Andreas Schwab wrote:
> > ../../gcc/input.c:1470:1: error: 'const char*
> > get_source_range_for_char(cpp_reader*, string_concat_db*,
> > location_t,
> > cpp_ttype, int, source_range*)' defined but not used [
> > -Werror=unused
> > -function]
> >  get_source_range_for_char (cpp_reader *pfile,
> >  ^
> 
> I'm guessing you have a --enable-checking=release build, and that
> this
> is happening in stage2.  My testing was with a debug build.
> 
> Sorry about this.
> 
> Does the attached patch fix it for you?  (I verified that it builds
> without warnings with both plain and --enable-checking=release
> configurations; bootstrapping it now)

That one didn't actually bootstrap for me, due to:

In file included from ../../../src/gcc/input.c:25:0:
../../../src/gcc/selftest.h: In function ‘void 
selftest::assert_num_substring_ranges(const selftest::location&, 
selftest::lexer_test&, location_t, cpp_ttype, int)’:
../../../src/gcc/selftest.h:155:3: error: ‘actual_num_ranges’ may be used 
uninitialized in this function [-Werror=maybe-uninitialized]
   if ((EXPECTED) == (ACTUAL))   \
   ^~
../../../src/gcc/input.c:2084:7: note: ‘actual_num_ranges’ was declared here
   int actual_num_ranges;
   ^
cc1plus: all warnings being treated as errors

apparently due to get_num_source_ranges_for_substring being inlined
into assert_num_substring_ranges, and then the logic being too
complicated for -Wmaybe-uninitialized to follow.  I was able to satisfy
a reduced version of the function that demonstrated the false warning
by adding "noreturn" to selftest::fail, but not the full version, so as
a simple fix, I've initialized actual_num_ranges to a dummy value.

I've committed the attached fix to trunk (as r239550), having verified
bootstrap on x86_64-pc-linux-gnu (debug build), and verified
the absence of warnings with a release build.

Sorry again about the breakage.
Dave

From 9c9f9e1c3ff1be538f77c32b9d1cf53baae5e577 Mon Sep 17 00:00:00 2001
From: David Malcolm 
Date: Wed, 17 Aug 2016 10:13:20 -0400
Subject: [PATCH] input.c: move test functions within #CHECKING_P and into selftest::

gcc/ChangeLog:
	* input.c (get_source_range_for_char): Rename to...
	(selftest::get_source_range_for_char): ...this, and move within
	the #if CHECKING_P guard.
	(get_num_source_ranges_for_substring): Rename to...
	(selftest::get_num_source_ranges_for_substring): ...this, move
	within the #if CHECKING_P guard, and make static.
	(selftest::assert_num_substring_ranges): Initialize
	actual_num_ranges.
---
 gcc/input.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/gcc/input.c b/gcc/input.c
index 653e54d..cfc62f3 100644
--- a/gcc/input.c
+++ b/gcc/input.c
@@ -1454,6 +1454,12 @@ get_source_location_for_substring (cpp_reader *pfile,
   return NULL;
 }
 
+#if CHECKING_P
+
+namespace selftest {
+
+/* Selftests of location handling.  */
+
 /* Attempt to populate *OUT_RANGE with source location information on the
given character within the string literal found at STRLOC.
CHAR_IDX refers to an offset within the execution character set.
@@ -1493,7 +1499,7 @@ get_source_range_for_char (cpp_reader *pfile,
 /* As get_source_range_for_char, but write to *OUT the number
of ranges that are available.  */
 
-const char *
+static const char *
 get_num_source_ranges_for_substring (cpp_reader *pfile,
  string_concat_db *concats,
  location_t strloc,
@@ -1513,12 +1519,6 @@ get_num_source_ranges_for_substring (cpp_reader *pfile,
   return NULL;
 }
 
-#if CHECKING_P
-
-namespace selftest {
-
-/* Selftests of location handling.  */
-
 /* A class for writing out a temporary sourcefile for use in selftests
of input handling.  */
 
@@ -2081,7 +2081,7 @@ assert_num_substring_ranges (const location ,
   cpp_reader *pfile = test.m_parser;
   string_concat_db *concats = _concats;
 
-  int actual_num_ranges;
+  int actual_num_ranges = -1;
   const char *err
 = get_num_source_ranges_for_substring (pfile, concats, strloc, type,
 	   _num_ranges);
-- 
1.8.5.3

Re: [wwwdocs] Buildstat update for 6.x

2016-08-17 Thread Gerald Pfeifer

On Thu, 16 Jun 2016, Tom G. Christensen wrote:
> Latest results for 6.x

Thanks a bunch, Tom!  (Somehow I must have missed this, unlike
the other one, and then I was essentially out for a month, sorry.)

Gerald

[PATCH] Add a TARGET_GEN_MEMSET_VALUE hook

2016-08-17 Thread H.J. Lu

builtin_memset_gen_str returns a register used for memset, which only
supports integer registers.  But a target may use vector registers in
memmset.  This patch adds a TARGET_GEN_MEMSET_VALUE hook to duplicate
QImode value to mode derived from STORE_MAX_PIECES, which can be used
with vector instructions.  The default hook is the same as the original
builtin_memset_gen_str.  A target can override it to support vector
instructions for STORE_MAX_PIECES.

Tested on x86-64 and i686.  Any comments?

H.J.
---
gcc/

* builtins.c (builtin_memset_gen_str): Call targetm.gen_memset_value.
(default_gen_memset_value): New function.
* target.def (gen_memset_value): New hook.
* targhooks.c: Inclue "expmed.h" and "builtins.h".
(default_gen_memset_value): New function.
* targhooks.h (default_gen_memset_value): New prototype.
* config/i386/i386.c (ix86_gen_memset_value): New function.
(TARGET_GEN_MEMSET_VALUE): New.
* config/i386/i386.h (STORE_MAX_PIECES): Likewise.
* doc/tm.texi.in: Add TARGET_GEN_MEMSET_VALUE hook.
* doc/tm.texi: Updated.

gcc/testsuite/

* gcc.target/i386/pieces-memset-1.c: New test.
* gcc.target/i386/pieces-memset-2.c: Likewise.
* gcc.target/i386/pieces-memset-3.c: Likewise.
* gcc.target/i386/pieces-memset-4.c: Likewise.
* gcc.target/i386/pieces-memset-5.c: Likewise.
* gcc.target/i386/pieces-memset-6.c: Likewise.
* gcc.target/i386/pieces-memset-7.c: Likewise.
* gcc.target/i386/pieces-memset-8.c: Likewise.
* gcc.target/i386/pieces-memset-9.c: Likewise.
* gcc.target/i386/pieces-memset-10.c: Likewise.
* gcc.target/i386/pieces-memset-11.c: Likewise.
* gcc.target/i386/pieces-memset-12.c: Likewise.
* gcc.target/i386/pieces-memset-13.c: Likewise.
* gcc.target/i386/pieces-memset-14.c: Likewise.
* gcc.target/i386/pieces-memset-15.c: Likewise.
* gcc.target/i386/pieces-memset-16.c: Likewise.
* gcc.target/i386/pieces-memset-17.c: Likewise.
* gcc.target/i386/pieces-memset-18.c: Likewise.
* gcc.target/i386/pieces-memset-19.c: Likewise.
* gcc.target/i386/pieces-memset-20.c: Likewise.
* gcc.target/i386/pieces-memset-21.c: Likewise.
* gcc.target/i386/pieces-memset-22.c: Likewise.
* gcc.target/i386/pieces-memset-23.c: Likewise.
* gcc.target/i386/pieces-memset-24.c: Likewise.
* gcc.target/i386/pieces-memset-25.c: Likewise.
* gcc.target/i386/pieces-memset-26.c: Likewise.
* gcc.target/i386/pieces-memset-27.c: Likewise.
* gcc.target/i386/pieces-memset-28.c: Likewise.
* gcc.target/i386/pieces-memset-29.c: Likewise.
* gcc.target/i386/pieces-memset-30.c: Likewise.
* gcc.target/i386/pieces-memset-31.c: Likewise.
* gcc.target/i386/pieces-memset-32.c: Likewise.
* gcc.target/i386/pieces-memset-33.c: Likewise.
* gcc.target/i386/pieces-memset-34.c: Likewise.
* gcc.target/i386/pieces-memset-35.c: Likewise.
* gcc.target/i386/pieces-memset-36.c: Likewise.
* gcc.target/i386/pieces-memset-37.c: Likewise.
* gcc.target/i386/pieces-memset-38.c: Likewise.
* gcc.target/i386/pieces-memset-39.c: Likewise.
* gcc.target/i386/pieces-memset-40.c: Likewise.
* gcc.target/i386/pieces-memset-41.c: Likewise.
* gcc.target/i386/pieces-memset-42.c: Likewise.
* gcc.target/i386/pieces-memset-43.c: Likewise.
* gcc.target/i386/pieces-memset-44.c: Likewise.
---
 gcc/builtins.c   | 32 
 gcc/config/i386/i386.c   | 38 
 gcc/config/i386/i386.h   | 13 
 gcc/doc/tm.texi  |  7 +
 gcc/doc/tm.texi.in   |  2 ++
 gcc/target.def   |  9 ++
 gcc/targhooks.h  |  1 +
 gcc/testsuite/gcc.target/i386/pieces-memset-1.c  | 12 
 gcc/testsuite/gcc.target/i386/pieces-memset-10.c | 12 
 gcc/testsuite/gcc.target/i386/pieces-memset-11.c | 12 
 gcc/testsuite/gcc.target/i386/pieces-memset-12.c | 12 
 gcc/testsuite/gcc.target/i386/pieces-memset-13.c | 12 
 gcc/testsuite/gcc.target/i386/pieces-memset-14.c | 12 
 gcc/testsuite/gcc.target/i386/pieces-memset-15.c | 12 
 gcc/testsuite/gcc.target/i386/pieces-memset-16.c | 12 
 gcc/testsuite/gcc.target/i386/pieces-memset-17.c | 12 
 gcc/testsuite/gcc.target/i386/pieces-memset-18.c | 12 
 gcc/testsuite/gcc.target/i386/pieces-memset-19.c | 13 
 gcc/testsuite/gcc.target/i386/pieces-memset-2.c  | 12 
 gcc/testsuite/gcc.target/i386/pieces-memset-20.c | 13 
 gcc/testsuite/gcc.target/i386/pieces-memset-21.c | 13

[PATCH] Fix invalid dg-do directive


This dg-do compile was being ignored due to a missing space, so we
were running a test that was meant to be compile-only. I've also taken
the opportunity to make it use an effective target of c++11.

* testsuite/20_util/reference_wrapper/invoke-2.cc: Fix invalid dg-do
directive and use effective target instead of dg-options.

Tested x86_64-linux, committed to trunk.

commit 73d3f1bbdd8f1235fddaf5b374cb3a2fd5662e40
Author: redi 
Date:   Wed Aug 17 19:58:44 2016 +

Fix invalid dg-do directive

* testsuite/20_util/reference_wrapper/invoke-2.cc: Fix invalid dg-do
directive and use effective target instead of dg-options.

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

diff --git a/libstdc++-v3/testsuite/20_util/reference_wrapper/invoke-2.cc 
b/libstdc++-v3/testsuite/20_util/reference_wrapper/invoke-2.cc
index 89b81ac..85803ba 100644
--- a/libstdc++-v3/testsuite/20_util/reference_wrapper/invoke-2.cc
+++ b/libstdc++-v3/testsuite/20_util/reference_wrapper/invoke-2.cc
@@ -1,5 +1,4 @@
-// { dg-options "-std=gnu++11" }
-// { dg-do compile}
+// { dg-do compile { target c++11 } }
 // Copyright (C) 2011-2016 Free Software Foundation, Inc.
 //
 // This file is part of the GNU ISO C++ Library.  This library is free

[PATCH] Use effective target instead of -std in dg-options


This changes some tests that have multiple dg-options directives to
use { target c++11 }, so they only need the dg-options that sets extra
options for simulators.

(We could use dg-additional-options for the simulator targets, but I
haven't bothered as it doesn't make any practical difference for these
tests).

* testsuite/20_util/hash/chi2_q_bit_flip_set.cc: Use effective target
instead of -std in dg-options.
* testsuite/20_util/hash/chi2_q_bit_string_set.cc: Likewise.
* testsuite/20_util/hash/chi2_q_numeric_pattern_set.cc: Likewise.
* testsuite/20_util/hash/chi2_q_uniform_random.cc: Likewise.
* testsuite/20_util/hash/quality.cc: Likewise.
* testsuite/25_algorithms/heap/moveable.cc: Likewise.
* testsuite/25_algorithms/heap/moveable2.cc: Likewise.
* testsuite/25_algorithms/nth_element/random_test.cc: Likewise.
* testsuite/25_algorithms/partial_sort/random_test.cc: Likewise.
* testsuite/25_algorithms/partial_sort_copy/random_test.cc: Likewise.
* testsuite/25_algorithms/sort/random_test.cc: Likewise.

Tested x86_64-linux, committed to trunk.

commit 791cea687810ef14aa28bfae7967b25f08a98a02
Author: redi 
Date:   Wed Aug 17 19:43:13 2016 +

Use effective target instead of -std in dg-options

* testsuite/20_util/hash/chi2_q_bit_flip_set.cc: Use effective target
instead of -std in dg-options.
* testsuite/20_util/hash/chi2_q_bit_string_set.cc: Likewise.
* testsuite/20_util/hash/chi2_q_numeric_pattern_set.cc: Likewise.
* testsuite/20_util/hash/chi2_q_uniform_random.cc: Likewise.
* testsuite/20_util/hash/quality.cc: Likewise.
* testsuite/25_algorithms/heap/moveable.cc: Likewise.
* testsuite/25_algorithms/heap/moveable2.cc: Likewise.
* testsuite/25_algorithms/nth_element/random_test.cc: Likewise.
* testsuite/25_algorithms/partial_sort/random_test.cc: Likewise.
* testsuite/25_algorithms/partial_sort_copy/random_test.cc: Likewise.
* testsuite/25_algorithms/sort/random_test.cc: Likewise.

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

diff --git a/libstdc++-v3/testsuite/20_util/hash/chi2_q_bit_flip_set.cc 
b/libstdc++-v3/testsuite/20_util/hash/chi2_q_bit_flip_set.cc
index 2e858e7..8da12a0 100644
--- a/libstdc++-v3/testsuite/20_util/hash/chi2_q_bit_flip_set.cc
+++ b/libstdc++-v3/testsuite/20_util/hash/chi2_q_bit_flip_set.cc
@@ -1,6 +1,6 @@
-// { dg-options "-std=gnu++11" }
 // Use smaller statistics when running on simulators, so it takes less time.
-// { dg-options "-std=gnu++11 -DSAMPLES=3" { target simulator } }
+// { dg-options "-DSAMPLES=3" { target simulator } }
+// { dg-do run { target c++11 } }
 
 // Copyright (C) 2010-2016 Free Software Foundation, Inc.
 //
diff --git a/libstdc++-v3/testsuite/20_util/hash/chi2_q_bit_string_set.cc 
b/libstdc++-v3/testsuite/20_util/hash/chi2_q_bit_string_set.cc
index fa589ea..8275523 100644
--- a/libstdc++-v3/testsuite/20_util/hash/chi2_q_bit_string_set.cc
+++ b/libstdc++-v3/testsuite/20_util/hash/chi2_q_bit_string_set.cc
@@ -1,8 +1,8 @@
-// { dg-options "-std=gnu++11" }
 // Use smaller statistics when running on simulators, so it takes less time.
 // For e.g. cris-elf, mipsisa32r2el-elf, powerpc-eabi and i386-linux-gnu,
 // this test fails for SAMPLES=3.
-// { dg-options "-std=gnu++11 -DSAMPLES=35000" { target simulator } }
+// { dg-options "-DSAMPLES=35000" { target simulator } }
+// { dg-do run { target c++11 } }
 
 // Copyright (C) 2010-2016 Free Software Foundation, Inc.
 //
diff --git a/libstdc++-v3/testsuite/20_util/hash/chi2_q_numeric_pattern_set.cc 
b/libstdc++-v3/testsuite/20_util/hash/chi2_q_numeric_pattern_set.cc
index e2ba187..e4ff66e 100644
--- a/libstdc++-v3/testsuite/20_util/hash/chi2_q_numeric_pattern_set.cc
+++ b/libstdc++-v3/testsuite/20_util/hash/chi2_q_numeric_pattern_set.cc
@@ -1,7 +1,7 @@
-// { dg-options "-std=gnu++11" }
 // Use smaller statistics when running on simulators, so it takes less time.
 // For x86_64-linux-gnu SAMPLES=3 fails, so increase slightly.
-// { dg-options "-std=gnu++11 -DSAMPLES=35000" { target simulator } }
+// { dg-options "-DSAMPLES=35000" { target simulator } }
+// { dg-do run { target c++11 } }
 
 // Copyright (C) 2010-2016 Free Software Foundation, Inc.
 //
diff --git a/libstdc++-v3/testsuite/20_util/hash/chi2_q_uniform_random.cc 
b/libstdc++-v3/testsuite/20_util/hash/chi2_q_uniform_random.cc
index 1659128..075f1cd 100644
--- a/libstdc++-v3/testsuite/20_util/hash/chi2_q_uniform_random.cc
+++ b/libstdc++-v3/testsuite/20_util/hash/chi2_q_uniform_random.cc
@@ -1,7 +1,7 @@
-// { dg-options "-std=gnu++11" }
 // Use smaller statistics when running on simulators, so it takes less time.
 // For powerpc-eabi, SAMPLES=3 fails.
-// { dg-options "-std=gnu++11 -DSAMPLES=35000" { target simulator } }
+// { dg-options

[PATCH] Add c++11 effective target to tests for C++11 features


This prevents these tests from failing when run with -std=gnu++98

* testsuite/20_util/tuple/67844.cc: Require c++11 effective target.
* testsuite/20_util/tuple/cons/nested_tuple_construct.cc: Likewise.
* testsuite/27_io/rvalue_streams.cc: Likewise.

Tested x86_64-linux, committed to trunk.


commit d021ad476ed0a8c89830b2b195e80a3428d4287b
Author: redi 
Date:   Wed Aug 17 19:23:15 2016 +

Add c++11 effective target to tests for C++11 features

* testsuite/20_util/tuple/67844.cc: Require c++11 effective target.
* testsuite/20_util/tuple/cons/nested_tuple_construct.cc: Likewise.
* testsuite/27_io/rvalue_streams.cc: Likewise.

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

diff --git a/libstdc++-v3/testsuite/20_util/tuple/67844.cc 
b/libstdc++-v3/testsuite/20_util/tuple/67844.cc
index 0416a51..d515b7b 100644
--- a/libstdc++-v3/testsuite/20_util/tuple/67844.cc
+++ b/libstdc++-v3/testsuite/20_util/tuple/67844.cc
@@ -1,4 +1,4 @@
-// { dg-do compile }
+// { dg-do compile { target c++11 } }
 
 // Copyright (C) 2015-2016 Free Software Foundation, Inc.
 //
diff --git 
a/libstdc++-v3/testsuite/20_util/tuple/cons/nested_tuple_construct.cc 
b/libstdc++-v3/testsuite/20_util/tuple/cons/nested_tuple_construct.cc
index 7f64239..39ae516 100644
--- a/libstdc++-v3/testsuite/20_util/tuple/cons/nested_tuple_construct.cc
+++ b/libstdc++-v3/testsuite/20_util/tuple/cons/nested_tuple_construct.cc
@@ -1,3 +1,5 @@
+// { dg-do run { target c++11 } }
+
 // Copyright (C) 2015-2016 Free Software Foundation, Inc.
 //
 // This file is part of the GNU ISO C++ Library.  This library is free
diff --git a/libstdc++-v3/testsuite/27_io/rvalue_streams.cc 
b/libstdc++-v3/testsuite/27_io/rvalue_streams.cc
index 5918595..f232c11 100644
--- a/libstdc++-v3/testsuite/27_io/rvalue_streams.cc
+++ b/libstdc++-v3/testsuite/27_io/rvalue_streams.cc
@@ -15,7 +15,7 @@
 // with this library; see the file COPYING3.  If not see
 // .
 
-// { dg-do run }
+// { dg-do run { target c++11 } }
 
 #include 
 #include

Re: [PATCH] Fix up trans_array_constructor UB (PR fortran/67496)

2016-08-17 Thread Mikael Morin


Le 17/08/2016 à 20:56, Jakub Jelinek a écrit :

Hi!

The bug here is that it dereferences expr->ts.u.cl if non-NULL
unconditionally, no matter what expr->ts.type is.
But, ts.u is an union, where ts.u.cl is only valid for BT_CHARACTER,
ts.u.derived for BT_DERIVED etc. ts.u.pad (an int rather than pointer)
for BT_HOLLERITH? and unused in others.
So, as on the testcase, where expr->ts.type == BT_DERIVED,
expr->ts.u.derived points to a gfc_symbol structure and thus dereferencing
ts.u.cl means reading gfc_symbol bytes as if it is gfc_charlen.
length_from_typespec is a bool, which can be only false or true, but
on the testcase happens to point to a byte in gfc_symbol that has some other
value (60 in my case), so the read is undefined behavior.

Fixed by doing it only when ts.u.cl is valid.  Bootstrapped/regtested on
x86_64-linux and i686-linux, ok for trunk?


Sure, it could go in as obvious actually.

Mikael

[PATCH] Fix up trans_array_constructor UB (PR fortran/67496)

Hi!

The bug here is that it dereferences expr->ts.u.cl if non-NULL
unconditionally, no matter what expr->ts.type is.
But, ts.u is an union, where ts.u.cl is only valid for BT_CHARACTER,
ts.u.derived for BT_DERIVED etc. ts.u.pad (an int rather than pointer)
for BT_HOLLERITH? and unused in others.
So, as on the testcase, where expr->ts.type == BT_DERIVED,
expr->ts.u.derived points to a gfc_symbol structure and thus dereferencing
ts.u.cl means reading gfc_symbol bytes as if it is gfc_charlen.
length_from_typespec is a bool, which can be only false or true, but
on the testcase happens to point to a byte in gfc_symbol that has some other
value (60 in my case), so the read is undefined behavior.

Fixed by doing it only when ts.u.cl is valid.  Bootstrapped/regtested on
x86_64-linux and i686-linux, ok for trunk?

2016-08-17  Jakub Jelinek  

PR fortran/67496
* trans-array.c (trans_array_constructor): Load
expr->ts.u.cl->length_from_typespec only if expr->ts.type is
BT_CHARACTER.

* gfortran.dg/pr67496.f90: New test.

--- gcc/fortran/trans-array.c.jj2016-08-12 17:33:44.0 +0200
+++ gcc/fortran/trans-array.c   2016-08-17 15:20:44.248509114 +0200
@@ -2239,7 +2239,8 @@ trans_array_constructor (gfc_ss * ss, lo
 
   /* Do bounds-checking here and in gfc_trans_array_ctor_element only if no
  typespec was given for the array constructor.  */
-  typespec_chararray_ctor = (expr->ts.u.cl
+  typespec_chararray_ctor = (expr->ts.type == BT_CHARACTER
+&& expr->ts.u.cl
 && expr->ts.u.cl->length_from_typespec);
 
   if ((gfc_option.rtcheck & GFC_RTCHECK_BOUNDS)
--- gcc/testsuite/gfortran.dg/pr67496.f90.jj2016-08-17 15:28:45.445223929 
+0200
+++ gcc/testsuite/gfortran.dg/pr67496.f90   2016-08-17 15:28:09.0 
+0200
@@ -0,0 +1,12 @@
+! PR fortran/67496
+! { dg-do compile }
+
+  type :: a
+  end type a
+  type :: b
+type (a) :: j(1)
+  end type b
+  type(a) :: x
+  type(b) :: y
+  y = b((/x/))
+end

Jakub

[PATCH] PR target/72839: Increase MOVE_RATIO to 17 for Lakemont

2016-08-17 Thread H.J. Lu

Larger MOVE_RATIO will always make code faster.  17 is the number with
smaller code sizes for Lakemont.

Tested on x86-64.  OK for trunk?


H.J.
---
gcc/

PR target/72839
* config/i386/i386.c (lakemont_cost): Set MOVE_RATIO to 17.

gcc/testsuite/

PR target/72839
* gcc.target/i386/pr72839.c: New test.
---
 gcc/config/i386/i386.c  |  2 +-
 gcc/testsuite/gcc.target/i386/pr72839.c | 17 +
 2 files changed, 18 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.target/i386/pr72839.c

diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 3805817..8fe3821 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -426,7 +426,7 @@ struct processor_costs lakemont_cost = {
   COSTS_N_INSNS (3),   /* cost of movsx */
   COSTS_N_INSNS (2),   /* cost of movzx */
   8,   /* "large" insn */
-  9,   /* MOVE_RATIO */
+  17,  /* MOVE_RATIO */
   6,/* cost for loading QImode using movzbl */
   {2, 4, 2},   /* cost of loading integer registers
   in QImode, HImode and SImode.
diff --git a/gcc/testsuite/gcc.target/i386/pr72839.c 
b/gcc/testsuite/gcc.target/i386/pr72839.c
new file mode 100644
index 000..ea724f7
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr72839.c
@@ -0,0 +1,17 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target ia32 } */
+/* { dg-options "-O2 -mtune=lakemont" } */
+
+extern char *strcpy (char *, const char *);
+
+void
+foo (char *s)
+{
+  strcpy (s,
+ "12345678123456781234567812345678123456781234567812345678"
+ "1234567");
+}
+
+/* { dg-final { scan-assembler-times "movl\[ \\t\]+\\$\[0-9\]+, 
\[0-9\]*\\(%\[^,\]+\\)" 16 } } */
+/* { dg-final { scan-assembler-not "rep movsl" } } */
+/* { dg-final { scan-assembler-not "rep movsb" } } */
-- 
2.7.4

Re: [wwwdocs] Add more PowerPC information to gcc-6/changes.html

2016-08-17 Thread Gerald Pfeifer

Hi Bill,

On Wed, 3 Feb 2016, Bill Schmidt wrote:
> The following was applied to the website to record additional GCC 6
> changes for PowerPC.  The changes passed XHTML verification.

Thanks for documenting all those changes so diligently!


Somehow I missed this originally, but ran into this now, and
here are some editorial changes I applied on top of this:

 - NOT -> not
 - Mark up command-line options and types.
 - cpu -> CPU
 - Linux -> GNU/Linux
 - Omit  inside .


Gerald

Index: changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-6/changes.html,v
retrieving revision 1.87
diff -u -r1.87 changes.html
--- changes.html8 Aug 2016 09:17:13 -   1.87
+++ changes.html17 Aug 2016 16:48:46 -
@@ -605,43 +605,42 @@
 
 PowerPC / PowerPC64 / RS6000
   
-PowerPC64 now supports IEEE 128-bit floating-point using the
-   __float128 data type.  In GCC 6, this is NOT enabled by default,
-   but you can enable it with -mfloat128.  The IEEE 128-bit
+PowerPC64 now supports IEEE 128-bit floating-point using the
+   __float128 data type.  In GCC 6, this is not enabled 
by default,
+   but you can enable it with -mfloat128.  The IEEE 128-bit
floating-point support requires the use of the VSX instruction
set.  IEEE 128-bit floating-point values are passed and returned
as a single vector value.  The software emulator for IEEE 128-bit
-   floating-point support is only built on PowerPC Linux systems
-   where the default cpu is at least power7.  On future ISA 3.0
-   systems (power9 and later), you will be able to use the
-   -mfloat128-hardware option to use the ISA 3.0 instructions
+   floating-point support is only built on PowerPC GNU/Linux systems
+   where the default CPU is at least power7.  On future ISA 3.0
+   systems (POWER 9 and later), you will be able to use the
+   -mfloat128-hardware option to use the ISA 3.0 instructions
that support IEEE 128-bit floating-point.  An additional type
(__ibm128) has been added to refer to the IBM extended double
-   type that normally implements long double.  This will allow
-   for a future transition to implementing long double with IEEE
-   128-bit floating-point.
-Basic support has been added for POWER9 hardware that will use the
+   type that normally implements long double.  This will allow
+   for a future transition to implementing long double with 
IEEE
+   128-bit floating-point.
+Basic support has been added for POWER9 hardware that will use the
recently published OpenPOWER ISA 3.0 instructions.  The following
-   new switches are available:
+   new switches are available:

- -mcpu=power9:  Implement all of the ISA 3.0
- instructions supported by the compiler.
- -mtune=power9:  In the future, apply tuning for
- POWER9 systems.  Currently, POWER8 tunings are used.
- -mmodulo:  Generate code using the ISA 3.0
+ -mcpu=power9:  Implement all of the ISA 3.0
+ instructions supported by the compiler.
+ -mtune=power9:  In the future, apply tuning for
+ POWER9 systems.  Currently, POWER8 tunings are used.
+ -mmodulo:  Generate code using the ISA 3.0
  integer instructions (modulus, count trailing zeros, array
- index support, integer multiply/add).
- -mpower9-fusion:  Generate code to suitably fuse
- instruction sequences for a POWER9 system.
- -mpower9-dform:  Generate code to use the new D-form
- (register +offset) memory instructions for the vector
- registers.
- -mpower9-vector:  Generate code using the new ISA
- 3.0 vector (VSX or Altivec) instructions.
- -mpower9-minmax:  Reserved for future development.
- 
- -mtoc-fusion:  Keep TOC entries together to provide
- more fusion opportunities.
+ index support, integer multiply/add).
+ -mpower9-fusion:  Generate code to suitably fuse
+ instruction sequences for a POWER9 system.
+ -mpower9-dform:  Generate code to use the new D-form
+ (register+offset) memory instructions for the vector
+ registers.
+ -mpower9-vector:  Generate code using the new ISA
+ 3.0 vector (VSX or Altivec) instructions.
+ -mpower9-minmax:  Reserved for future development.
+ -mtoc-fusion:  Keep TOC entries together to provide
+ more fusion opportunities.

 New constraints have been added to support IEEE 128-bit
floating-point and ISA 3.0 instructions:
@@ -663,28 +662,28 @@
  wL:  Integer constant identifying the element
  number mfvsrld accesses within a vector.

-Support has been added for __builtin_cpu_is () and
-

Re: Implement C _FloatN, _FloatNx types [version 5]

2016-08-17 Thread Joseph Myers

On Wed, 17 Aug 2016, James Greenhalgh wrote:

> The obvious fix would be this modification to fp-int-convert.h:
> 
> -  TEST_I_F_VAL (U, F, (U)~(((U)~(U)0) >> 1), 1);   \
> +  TEST_I_F_VAL (U, F, (U)~(((U)~(U)0) >> 1), P_OK1 (P, U));\

That's not logically correct, because this is an issue about exponent 
range, not precision; it's fine to test this input value when converting 
from TImode to float, for example, because it's 2**127 which is exactly 
representable in float.

I'll do another revision of the patch that addresses this and has other 
testsuite improvements (but no changes to the actual compiler changes, 
which still need review for language-independent changes outside the 
rs6000 back end).

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

[PATCH] Add comment explaining why -std=c++14 is needed.


I tried changing this test to use { dg-do compile { target c++14 } }
and it started to FAIL, because the complex_literals operators are
only used for -std=c++14 mode. With -std=gnu++14 we get the GNU
extension described at https://gcc.gnu.org/onlinedocs/gcc/Complex.html

* testsuite/26_numerics/complex/literals/types.cc: Add comment.

Tested x86_64-linux, committed to trunk.

commit 9565c37c3a3a3624190b38fe92d9f5a2cc9b7a04
Author: redi 
Date:   Wed Aug 17 16:09:15 2016 +

Add comment explaining why -std=c++14 is needed.

* testsuite/26_numerics/complex/literals/types.cc: Add comment.

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

diff --git a/libstdc++-v3/testsuite/26_numerics/complex/literals/types.cc 
b/libstdc++-v3/testsuite/26_numerics/complex/literals/types.cc
index ef48c0d..ad9b863 100644
--- a/libstdc++-v3/testsuite/26_numerics/complex/literals/types.cc
+++ b/libstdc++-v3/testsuite/26_numerics/complex/literals/types.cc
@@ -1,4 +1,6 @@
-// { dg-options "-std=c++1y" }
+// Use -std=c++14 explicitly, because -std=gnu++14 enables GNU extension for
+// complex literals, so 1.0if is __complex__ float not std::complex.
+// { dg-options "-std=c++14" }
 // { dg-do compile }
 
 // Copyright (C) 2013-2016 Free Software Foundation, Inc.

Re: Implement C _FloatN, _FloatNx types [version 5]

2016-08-17 Thread James Greenhalgh

On Fri, Jul 22, 2016 at 09:59:33PM +, Joseph Myers wrote:
> Index: gcc/testsuite/gcc.dg/torture/fp-int-convert-float16-timode.c
> ===
> --- gcc/testsuite/gcc.dg/torture/fp-int-convert-float16-timode.c  
> (nonexistent)
> +++ gcc/testsuite/gcc.dg/torture/fp-int-convert-float16-timode.c  
> (working copy)
> @@ -0,0 +1,15 @@
> +/* Test floating-point conversions.  _Float16 type with TImode.  */
> +/* { dg-do run } */
> +/* { dg-require-effective-target float16 } */
> +/* { dg-options "" } */
> +
> +#define __STDC_WANT_IEC_60559_TYPES_EXT__
> +#include 
> +#include "fp-int-convert.h"
> +
> +int
> +main (void)
> +{
> +  TEST_I_F(TItype, UTItype, _Float16, FLT16_MANT_DIG);
> +  exit (0);
> +}
> Index: gcc/testsuite/gcc.dg/torture/fp-int-convert-float16.c
> ===
> --- gcc/testsuite/gcc.dg/torture/fp-int-convert-float16.c (nonexistent)
> +++ gcc/testsuite/gcc.dg/torture/fp-int-convert-float16.c (working copy)
> @@ -0,0 +1,19 @@
> +/* Test floating-point conversions.  Standard types and _Float16.  */
> +/* { dg-do run } */
> +/* { dg-require-effective-target float16 } */
> +/* { dg-options "" } */
> +
> +#define __STDC_WANT_IEC_60559_TYPES_EXT__
> +#include 
> +#include "fp-int-convert.h"
> +
> +int
> +main (void)
> +{
> +  TEST_I_F(signed char, unsigned char, _Float16, FLT16_MANT_DIG);
> +  TEST_I_F(signed short, unsigned short, _Float16, FLT16_MANT_DIG);
> +  TEST_I_F(signed int, unsigned int, _Float16, FLT16_MANT_DIG);
> +  TEST_I_F(signed long, unsigned long, _Float16, FLT16_MANT_DIG);
> +  TEST_I_F(signed long long, unsigned long long, _Float16, FLT16_MANT_DIG);
> +  exit (0);
> +}

Hi Joseph,

These tests will fail for _Float16 implementations.

One of the tests in fp-int-convert.h tries to convert to and from
0x8..0 in the width of the unsigned integer mode. But 0x8..0 is not
representable in a 16-bit float for any of unsigned int, unsigned long,
unsigned long long, or UTItype so the check that conversion to and from
16-bit float returns the input value will fail.

The relevant line in testsuite/gcc.dg/torture/fp-int-convert.h is:

  TEST_I_F_VAL (U, F, (U)~(((U)~(U)0) >> 1), 1);

The reduced, preprocessed test below should show the issue I am referring
to clearly:

  extern void abort(void);
  extern void exit(int);

  typedef int int128_t __attribute__((mode(TI)));
  typedef unsigned int uint128_t __attribute__((mode(TI)));


  int main (int argc, char** argv)
  {
static volatile uint128_t ivin, ivout;
static volatile _Float16 fv1, fv2;

ivin = ~((~(uint128_t)0) >> 1);
fv1 = ~((~(uint128_t)0) >> 1);
fv2 = ivin;
ivout = fv2;
if (ivout != ivin)
  abort ();
  }

This test will always abort for a _Float16 implementation.

The obvious fix would be this modification to fp-int-convert.h:

-  TEST_I_F_VAL (U, F, (U)~(((U)~(U)0) >> 1), 1);   \
+  TEST_I_F_VAL (U, F, (U)~(((U)~(U)0) >> 1), P_OK1 (P, U));\

Thanks,
James

Re: [PATCH] Small cleanups to use gimple_call_noreturn_p

On Wed, 17 Aug 2016, Jakub Jelinek wrote:

> Hi!
> 
> I've noticed a couple of places that should be using
> gimple_call_noreturn_p but are using gimple_call_flags (stmt) & ECF_NORETURN
> instead.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

Ok.

Richard.

> 2016-08-17  Jakub Jelinek  
> 
>   * gimple-fold.c (gimple_fold_call): Use gimple_call_noreturn_p
>   instead of testing ECF_NORETURN bit in gimple_call_flags.
>   * tree-cfg.c (make_edges_bb, execute_fixup_cfg): Likewise.
>   * predict.c (tree_bb_level_predictions): Likewise.
>   * gimple-low.c (gimple_stmt_may_fallthru): Likewise.
> 
> --- gcc/gimple-fold.c.jj  2016-07-19 19:29:05.250752770 +0200
> +++ gcc/gimple-fold.c 2016-08-17 13:34:21.209544835 +0200
> @@ -3184,7 +3184,7 @@ gimple_fold_call (gimple_stmt_iterator *
> /* If changing the call to __cxa_pure_virtual
>or similar noreturn function, adjust gimple_call_fntype
>too.  */
> -   if ((gimple_call_flags (stmt) & ECF_NORETURN)
> +   if (gimple_call_noreturn_p (stmt)
> && VOID_TYPE_P (TREE_TYPE (TREE_TYPE (fndecl)))
> && TYPE_ARG_TYPES (TREE_TYPE (fndecl))
> && (TREE_VALUE (TYPE_ARG_TYPES (TREE_TYPE (fndecl)))
> --- gcc/tree-cfg.c.jj 2016-08-16 18:50:14.918137409 +0200
> +++ gcc/tree-cfg.c2016-08-17 13:35:49.059419876 +0200
> @@ -807,7 +807,7 @@ make_edges_bb (basic_block bb, struct om
>   }
>/* Some calls are known not to return.  */
>else
> - fallthru = !(gimple_call_flags (last) & ECF_NORETURN);
> + fallthru = !gimple_call_noreturn_p (last);
>break;
>  
>  case GIMPLE_ASSIGN:
> @@ -9083,7 +9083,7 @@ execute_fixup_cfg (void)
> if (!stmt
> || (!is_ctrl_stmt (stmt)
> && (!is_gimple_call (stmt)
> -   || (gimple_call_flags (stmt) & ECF_NORETURN) == 0)))
> +   || !gimple_call_noreturn_p (stmt
>   {
> if (stmt && is_gimple_call (stmt))
>   gimple_call_set_ctrl_altering (stmt, false);
> --- gcc/predict.c.jj  2016-08-06 12:11:52.254489381 +0200
> +++ gcc/predict.c 2016-08-17 13:35:12.365889754 +0200
> @@ -2639,8 +2639,7 @@ tree_bb_level_predictions (void)
>  
> if (is_gimple_call (stmt))
>   {
> -   if ((gimple_call_flags (stmt) & ECF_NORETURN)
> -   && has_return_edges)
> +   if (gimple_call_noreturn_p (stmt) && has_return_edges)
>   predict_paths_leading_to (bb, PRED_NORETURN,
> NOT_TAKEN);
> decl = gimple_call_fndecl (stmt);
> --- gcc/gimple-low.c.jj   2016-05-03 14:12:19.053019350 +0200
> +++ gcc/gimple-low.c  2016-08-17 13:34:54.813114525 +0200
> @@ -610,7 +610,7 @@ gimple_stmt_may_fallthru (gimple *stmt)
>  
>  case GIMPLE_CALL:
>/* Functions that do not return do not fall through.  */
> -  return (gimple_call_flags (stmt) & ECF_NORETURN) == 0;
> +  return !gimple_call_noreturn_p (stmt);
>  
>  default:
>return true;
> 
>   Jakub
> 
> 

-- 
Richard Biener 
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 
21284 (AG Nuernberg)

[PATCH] Small cleanups to use gimple_call_noreturn_p

Hi!

I've noticed a couple of places that should be using
gimple_call_noreturn_p but are using gimple_call_flags (stmt) & ECF_NORETURN
instead.

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

2016-08-17  Jakub Jelinek  

* gimple-fold.c (gimple_fold_call): Use gimple_call_noreturn_p
instead of testing ECF_NORETURN bit in gimple_call_flags.
* tree-cfg.c (make_edges_bb, execute_fixup_cfg): Likewise.
* predict.c (tree_bb_level_predictions): Likewise.
* gimple-low.c (gimple_stmt_may_fallthru): Likewise.

--- gcc/gimple-fold.c.jj2016-07-19 19:29:05.250752770 +0200
+++ gcc/gimple-fold.c   2016-08-17 13:34:21.209544835 +0200
@@ -3184,7 +3184,7 @@ gimple_fold_call (gimple_stmt_iterator *
  /* If changing the call to __cxa_pure_virtual
 or similar noreturn function, adjust gimple_call_fntype
 too.  */
- if ((gimple_call_flags (stmt) & ECF_NORETURN)
+ if (gimple_call_noreturn_p (stmt)
  && VOID_TYPE_P (TREE_TYPE (TREE_TYPE (fndecl)))
  && TYPE_ARG_TYPES (TREE_TYPE (fndecl))
  && (TREE_VALUE (TYPE_ARG_TYPES (TREE_TYPE (fndecl)))
--- gcc/tree-cfg.c.jj   2016-08-16 18:50:14.918137409 +0200
+++ gcc/tree-cfg.c  2016-08-17 13:35:49.059419876 +0200
@@ -807,7 +807,7 @@ make_edges_bb (basic_block bb, struct om
}
   /* Some calls are known not to return.  */
   else
-   fallthru = !(gimple_call_flags (last) & ECF_NORETURN);
+   fallthru = !gimple_call_noreturn_p (last);
   break;
 
 case GIMPLE_ASSIGN:
@@ -9083,7 +9083,7 @@ execute_fixup_cfg (void)
  if (!stmt
  || (!is_ctrl_stmt (stmt)
  && (!is_gimple_call (stmt)
- || (gimple_call_flags (stmt) & ECF_NORETURN) == 0)))
+ || !gimple_call_noreturn_p (stmt
{
  if (stmt && is_gimple_call (stmt))
gimple_call_set_ctrl_altering (stmt, false);
--- gcc/predict.c.jj2016-08-06 12:11:52.254489381 +0200
+++ gcc/predict.c   2016-08-17 13:35:12.365889754 +0200
@@ -2639,8 +2639,7 @@ tree_bb_level_predictions (void)
 
  if (is_gimple_call (stmt))
{
- if ((gimple_call_flags (stmt) & ECF_NORETURN)
- && has_return_edges)
+ if (gimple_call_noreturn_p (stmt) && has_return_edges)
predict_paths_leading_to (bb, PRED_NORETURN,
  NOT_TAKEN);
  decl = gimple_call_fndecl (stmt);
--- gcc/gimple-low.c.jj 2016-05-03 14:12:19.053019350 +0200
+++ gcc/gimple-low.c2016-08-17 13:34:54.813114525 +0200
@@ -610,7 +610,7 @@ gimple_stmt_may_fallthru (gimple *stmt)
 
 case GIMPLE_CALL:
   /* Functions that do not return do not fall through.  */
-  return (gimple_call_flags (stmt) & ECF_NORETURN) == 0;
+  return !gimple_call_noreturn_p (stmt);
 
 default:
   return true;

Jakub

Re: [PATCH] Speed up ix86_expand_builtin

On Tue, Aug 16, 2016 at 09:21:57PM +0200, Uros Bizjak wrote:
> The idea is indeed good, but please leave full names in the *.def
> file. We can change them later, if need arises.

Ok, here it is.
i386-builtin.def is basically moved the bdesc_* definitions, except that
  { ... },
is replaced with
BDESC (...)
and comments reindented.  The first entry in each bdesc_* array
uses BDESC_FIRST macro instead of BDESC, and there is BDESC_END after the
last one.  I've managed to do it without gaps in between enumerator values
for the boundaries, and with the goal that additions of BDESC entries at the
end of bdesc_* sections will be much more common than adding new bdesc_*
arrays, so e.g. didn't want a BDESC_LAST macro that would need to be changed
to BDESC and added for some new entry every time something is appended.
Also, I've tried to make the real builtin IX86_BUILTIN_* values to always
precede the IX86_BUILTIN__BDESC_*_{FIRST,LAST} aliases, so that in the
debugger one can see IX86_BUILTIN_COMIEQSS rather than
IX86_BUILTIN__BDESC_COMI_FIRST etc.

Full patch is attached xz compressed, included below is the same patch with
lots of - or + lines replaced with ... where it doesn't contain anything
interesting for the review.

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

2016-08-17  Jakub Jelinek  

* config/i386/i386.c (enum ix86_builtins): Remove IX86_BUILTIN_*
codes that appear in bdesc_* arrays, instead include i386-builtin.def
twice to define those.
(bdesc_comi, bdesc_pcmpestr, bdesc_pcmpistr, bdesc_special_args,
bdesc_args, bdesc_round_args, bdesc_mpx, bdesc_mpx_const,
bdesc_multi_arg): Define by including i386-builtin.def the third time.
* config/i386/i386-builtin.def: New file.

--- gcc/config/i386/i386.c.jj   2016-08-16 21:27:02.0 +0200
+++ gcc/config/i386/i386.c  2016-08-17 12:43:20.255605518 +0200
@@ -30661,2415 +30661,41 @@ enum ix86_builtins
   IX86_BUILTIN_READ_FLAGS,
   IX86_BUILTIN_WRITE_FLAGS,

-  /* All the remaining builtins are tracked in bdesc_* arrays.
...
-  IX86_BUILTIN_VPERMIL2PS256,
-  IX86_BUILTIN__BDESC_MULTI_ARG_LAST = IX86_BUILTIN_VPERMIL2PS256,
+  /* All the remaining builtins are tracked in bdesc_* arrays in
+ i386-builtin.def.  Don't add any IX86_BUILTIN_* enumerators after
+ this point.  */
+#define BDESC(mask, icode, name, code, comparison, flag) \
+  code,
+#define BDESC_FIRST(kind, kindu, mask, icode, name, code, comparison, flag) \
+  code,
\
+  IX86_BUILTIN__BDESC_##kindu##_FIRST = code,
+#define BDESC_END(kind, next_kind)
+
+#include "i386-builtin.def"
+
+#undef BDESC
+#undef BDESC_FIRST
+#undef BDESC_END
+
+  IX86_BUILTIN_MAX,
+
+  IX86_BUILTIN__BDESC_MAX_FIRST = IX86_BUILTIN_MAX,
+
+  /* Now just the aliases for bdesc_* start/end.  */
+#define BDESC(mask, icode, name, code, comparison, flag)
+#define BDESC_FIRST(kind, kindu, mask, icode, name, code, comparison, flag)
+#define BDESC_END(kind, next_kind) \
+  IX86_BUILTIN__BDESC_##kind##_LAST\
+= IX86_BUILTIN__BDESC_##next_kind##_FIRST - 1,
+
+#include "i386-builtin.def"
+
+#undef BDESC
+#undef BDESC_FIRST
+#undef BDESC_END

-  IX86_BUILTIN_MAX
+  /* Just to make sure there is no comma after the last enumerator.  */
+  IX86_BUILTIN__BDESC_MAX_LAST = IX86_BUILTIN__BDESC_MAX_FIRST
 };

 /* Table for the ix86 builtin decls.  */
@@ -33236,2475 +30862,6 @@ struct builtin_description
   const int flag;
 };

-static const struct builtin_description bdesc_comi[] =
-{
-  { OPTION_MASK_ISA_SSE, CODE_FOR_sse_comi, "__builtin_ia32_comieq", 
IX86_BUILTIN_COMIEQSS, UNEQ, 0 },
...
-
-/* FMA4 and XOP.  */
 #define MULTI_ARG_4_DF2_DI_I   V2DF_FTYPE_V2DF_V2DF_V2DI_INT
 #define MULTI_ARG_4_DF2_DI_I1  V4DF_FTYPE_V4DF_V4DF_V4DI_INT
 #define MULTI_ARG_4_SF2_SI_I   V4SF_FTYPE_V4SF_V4SF_V4SI_INT
@@ -35758,199 +30915,20 @@ static const struct builtin_description
 #define MULTI_ARG_1_QI_SI  V4SI_FTYPE_V16QI
 #define MULTI_ARG_1_QI_HI  V8HI_FTYPE_V16QI

-static const struct builtin_description bdesc_multi_arg[] =
-{
...
-  { OPTION_MASK_ISA_XOP, CODE_FOR_xop_vpermil2v8sf3, 
"__builtin_ia32_vpermil2ps256", IX86_BUILTIN_VPERMIL2PS256, UNKNOWN, 
(int)MULTI_ARG_4_SF2_SI_I1 },
-
+#define BDESC(mask, icode, name, code, comparison, flag) \
+  { mask, icode, name, code, comparison, flag },
+#define BDESC_FIRST(kind, kindu, mask, icode, name, code, comparison, flag) \
+static const struct builtin_description bdesc_##kind[] =   \
+{  \
+  BDESC (mask, icode, name, code, comparison, flag)
+#define BDESC_END(kind, next_kind) \
 };
+
+#include "i386-builtin.def"
+
+#undef BDESC
+#undef BDESC_FIRST
+#undef BDESC_END

 /* TM vector builtins.  */

--- gcc/config/i386/i386-builtin.def.jj 2016-08-17 11:08:34.194237549 +0200
+++

[PATCH] Remove duplicate dg-options directive


This test got a second dg-options directive in the middle of the
licence text somehow.

* testsuite/21_strings/basic_string_view/operations/rfind/char/2.cc:
Remove duplicate dg-options directive.

Tested x86_64-linux, committed to trunk.

commit 50786265d0950ac2cc2d21bcc960bcd17d68e1d3
Author: Jonathan Wakely 
Date:   Wed Aug 17 15:09:40 2016 +0100

Remove duplicate dg-options directive

* testsuite/21_strings/basic_string_view/operations/rfind/char/2.cc:
Remove duplicate dg-options directive.

diff --git 
a/libstdc++-v3/testsuite/21_strings/basic_string_view/operations/rfind/char/2.cc
 
b/libstdc++-v3/testsuite/21_strings/basic_string_view/operations/rfind/char/2.cc
index 031a01b..49232f8 100644
--- 
a/libstdc++-v3/testsuite/21_strings/basic_string_view/operations/rfind/char/2.cc
+++ 
b/libstdc++-v3/testsuite/21_strings/basic_string_view/operations/rfind/char/2.cc
@@ -12,7 +12,6 @@
 // but WITHOUT ANY WARRANTY; without even the implied warranty of
 // MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 // GNU General Public License for more details.
-// { dg-options "-std=gnu++17" }
 
 // You should have received a copy of the GNU General Public License along
 // with this library; see the file COPYING3.  If not see

[PATCH 1/2] Adjust DG directives in libstdc++ XFAIL test


Some tweaks to dejagnu directives.

* testsuite/20_util/bind/ref_neg.cc: Use effective target instead of
-std=gnu++11. Add -fno-show-columns to dg-options. Use dg-prune-output
instead of dg-excess-errors.

Tested powerpc64le-linux, committed to trunk.


commit 964ab6e50270e231f92c2e892906e7f2aa4ef5b5
Author: Jonathan Wakely 
Date:   Wed Aug 17 12:41:24 2016 +0100

Adjust DG directives in libstdc++ XFAIL test

* testsuite/20_util/bind/ref_neg.cc: Use effective target instead of
-std=gnu++11. Add -fno-show-columns to dg-options. Use dg-prune-output
instead of dg-excess-errors.

diff --git a/libstdc++-v3/testsuite/20_util/bind/ref_neg.cc 
b/libstdc++-v3/testsuite/20_util/bind/ref_neg.cc
index f1a1c78..ff2dffb 100644
--- a/libstdc++-v3/testsuite/20_util/bind/ref_neg.cc
+++ b/libstdc++-v3/testsuite/20_util/bind/ref_neg.cc
@@ -17,8 +17,8 @@
 
 // 20.8.9 Function template bind
 
-// { dg-do compile }
-// { dg-options "-std=gnu++11" }
+// { dg-options "-fno-show-column" }
+// { dg-do compile { target c++11 } }
 
 #include 
 
@@ -48,7 +48,8 @@ void test02()
   std::bind(::f, Inc(), std::ref(dummy))(); // { dg-error  "no match" }
 }
 
-// { dg-excess-errors "reasons for deduction/substitution failures" }
+// Ignore the reasons for deduction/substitution failure in the headers.
+// { dg-prune-output "/include/(functional|bits/invoke.h):" }
 
 int main()
 {

Re: [PATCH 2/2] Adjust DG directives in libstdc++ XFAIL test


Another patch tweaking directives, and replacing -std with an
effective target.

   Adjust DG directives in libstdc++ Profile Mode test
   
   	* testsuite/ext/profile/all.cc: Use effective target instead of

-std=gnu++11. Use dg-additional-options instead of repeating options.

Tested powerpc64le-linux, committed to trunk.

commit 1ad68a57c0ac214033949b16c38b04688845cb84
Author: Jonathan Wakely 
Date:   Wed Aug 17 13:22:17 2016 +0100

Adjust DG directives in libstdc++ Profile Mode test

	* testsuite/ext/profile/all.cc: Use effective target instead of
	-std=gnu++11. Use dg-additional-options instead of repeating options.

diff --git a/libstdc++-v3/testsuite/ext/profile/all.cc b/libstdc++-v3/testsuite/ext/profile/all.cc
index 17be8bc..c1eb440 100644
--- a/libstdc++-v3/testsuite/ext/profile/all.cc
+++ b/libstdc++-v3/testsuite/ext/profile/all.cc
@@ -1,6 +1,6 @@
-// { dg-options "-std=gnu++11 -O0" }
-// { dg-options "-std=gnu++11 -O0 -D_GLIBCXX_PROFILE_NO_THREADS" { target { ! tls_native } } }
-// { dg-do compile }
+// { dg-options "-O0" }
+// { dg-additional-options "-D_GLIBCXX_PROFILE_NO_THREADS" { target { ! tls_native } } }
+// { dg-do compile { target c++11 } }
 // { dg-require-profile-mode "" }
 
 // -*- C++ -*-

[PATCH 2/2] Adjust testcases for C++17 compatibility


Adding TR1 and LFTS components to namespace std makes some tests fail
due to ambiguous names. This resolves those problems so the tests pass
using C++17.

   Adjust testcases for C++17 compatibility
   
   	* testsuite/26_numerics/headers/cmath/types_std_c++0x_neg.cc: Disable

test for C++17.
* testsuite/experimental/chrono/value.cc: Avoid ambiguities in C++17.
* testsuite/experimental/ratio/value.cc: Likewise.
* testsuite/ext/pb_ds/regression/hash_map_rand.cc: Disable test for
C++17.
* testsuite/ext/pb_ds/regression/hash_set_rand.cc: Likewise.
* testsuite/ext/pb_ds/regression/list_update_map_rand.cc: Likewise.
* testsuite/ext/pb_ds/regression/list_update_set_rand.cc: Likewise.
* testsuite/ext/pb_ds/regression/priority_queue_rand.cc: Likewise.
* testsuite/ext/pb_ds/regression/tree_map_rand.cc: Likewise.
* testsuite/ext/pb_ds/regression/tree_set_rand.cc: Likewise.
* testsuite/ext/pb_ds/regression/trie_map_rand.cc: Likewise.
* testsuite/ext/pb_ds/regression/trie_set_rand.cc: Likewise.
* testsuite/tr1/5_numerical_facilities/special_functions/
10_cyl_bessel_k/airy.cc: Adjust namespace of __detail::__airy for
C++17 compatibility.

Tested powerpc64le-linux, committed to trunk.


commit 9e77fc9382dd99fb38e39bcd91b385e668c6b742
Author: Jonathan Wakely 
Date:   Wed Aug 17 00:29:39 2016 +0100

Adjust testcases for C++17 compatibility

	* testsuite/26_numerics/headers/cmath/types_std_c++0x_neg.cc: Disable
	test for C++17.
	* testsuite/experimental/chrono/value.cc: Avoid ambiguities in C++17.
	* testsuite/experimental/ratio/value.cc: Likewise.
	* testsuite/ext/pb_ds/regression/hash_map_rand.cc: Disable test for
	C++17.
	* testsuite/ext/pb_ds/regression/hash_set_rand.cc: Likewise.
	* testsuite/ext/pb_ds/regression/list_update_map_rand.cc: Likewise.
	* testsuite/ext/pb_ds/regression/list_update_set_rand.cc: Likewise.
	* testsuite/ext/pb_ds/regression/priority_queue_rand.cc: Likewise.
	* testsuite/ext/pb_ds/regression/tree_map_rand.cc: Likewise.
	* testsuite/ext/pb_ds/regression/tree_set_rand.cc: Likewise.
	* testsuite/ext/pb_ds/regression/trie_map_rand.cc: Likewise.
	* testsuite/ext/pb_ds/regression/trie_set_rand.cc: Likewise.
	* testsuite/tr1/5_numerical_facilities/special_functions/
	10_cyl_bessel_k/airy.cc: Adjust namespace of __detail::__airy for
	C++17 compatibility.

diff --git a/libstdc++-v3/testsuite/26_numerics/headers/cmath/types_std_c++0x_neg.cc b/libstdc++-v3/testsuite/26_numerics/headers/cmath/types_std_c++0x_neg.cc
index 8910c7e..14be447 100644
--- a/libstdc++-v3/testsuite/26_numerics/headers/cmath/types_std_c++0x_neg.cc
+++ b/libstdc++-v3/testsuite/26_numerics/headers/cmath/types_std_c++0x_neg.cc
@@ -1,5 +1,4 @@
-// { dg-options "-std=gnu++11" }
-// { dg-do compile }
+// { dg-do compile { target { ! c++1z } } }
 
 // Copyright (C) 2007-2016 Free Software Foundation, Inc.
 //
diff --git a/libstdc++-v3/testsuite/experimental/chrono/value.cc b/libstdc++-v3/testsuite/experimental/chrono/value.cc
index 80117fd..64c16fea 100644
--- a/libstdc++-v3/testsuite/experimental/chrono/value.cc
+++ b/libstdc++-v3/testsuite/experimental/chrono/value.cc
@@ -1,5 +1,4 @@
-// { dg-options "-std=gnu++14" }
-// { dg-do compile }
+// { dg-do compile { target c++14 } }
 
 // Copyright (C) 2014-2016 Free Software Foundation, Inc.
 //
@@ -20,8 +19,8 @@
 
 #include 
 
-using namespace std::chrono;
-using namespace std::chrono::experimental;
+using std::chrono::treat_as_floating_point;
+using std::chrono::experimental::treat_as_floating_point_v;
 
 // These tests are rather simple, the front-end tests already test
 // variable templates, and the library tests for the underlying
diff --git a/libstdc++-v3/testsuite/experimental/ratio/value.cc b/libstdc++-v3/testsuite/experimental/ratio/value.cc
index 4c8a7f0..17a732b 100644
--- a/libstdc++-v3/testsuite/experimental/ratio/value.cc
+++ b/libstdc++-v3/testsuite/experimental/ratio/value.cc
@@ -1,5 +1,4 @@
-// { dg-options "-std=gnu++14" }
-// { dg-do compile }
+// { dg-do compile { target c++14 } }
 
 // Copyright (C) 2014-2016 Free Software Foundation, Inc.
 //
@@ -20,8 +19,19 @@
 
 #include 
 
-using namespace std;
-using namespace std::experimental;
+using std::ratio;
+using std::ratio_equal;
+using std::ratio_not_equal;
+using std::ratio_less;
+using std::ratio_less_equal;
+using std::ratio_greater;
+using std::ratio_greater_equal;
+using std::experimental::ratio_equal_v;
+using std::experimental::ratio_not_equal_v;
+using std::experimental::ratio_less_v;
+using std::experimental::ratio_less_equal_v;
+using std::experimental::ratio_greater_v;
+using std::experimental::ratio_greater_equal_v;
 
 // These tests are rather simple, the front-end tests already test
 // variable templates, and the library tests for the underlying
diff --git

Re: [PATCH] Fix caret locations in format_type_warning (PR c/72857)

2016-08-17 Thread David Malcolm

On Wed, 2016-08-17 at 10:12 +0200, Andreas Schwab wrote:
> ../../gcc/input.c:1470:1: error: 'const char*
> get_source_range_for_char(cpp_reader*, string_concat_db*, location_t,
> cpp_ttype, int, source_range*)' defined but not used [-Werror=unused
> -function]
>  get_source_range_for_char (cpp_reader *pfile,
>  ^

I'm guessing you have a --enable-checking=release build, and that this
is happening in stage2.  My testing was with a debug build.

Sorry about this.

Does the attached patch fix it for you?  (I verified that it builds
without warnings with both plain and --enable-checking=release
configurations; bootstrapping it now)

DaveFrom 397d1bed2f014416f0c287b7872d025fb8003705 Mon Sep 17 00:00:00 2001
From: David Malcolm 
Date: Wed, 17 Aug 2016 10:13:20 -0400
Subject: [PATCH] input.c: move test functions within #CHECKING_P and into
 selftest::

gcc/ChangeLog:
	* input.c (get_source_range_for_char): Rename to...
	(selftest::get_source_range_for_char): ...this, and move within
	the #if CHECKING_P guard.
	(get_num_source_ranges_for_substring): Rename to...
	(selftest::get_num_source_ranges_for_substring): ...this, move within
	the #if CHECKING_P guard, and make static.
---
 gcc/input.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/gcc/input.c b/gcc/input.c
index 653e54d..bd0d214 100644
--- a/gcc/input.c
+++ b/gcc/input.c
@@ -1454,6 +1454,12 @@ get_source_location_for_substring (cpp_reader *pfile,
   return NULL;
 }
 
+#if CHECKING_P
+
+namespace selftest {
+
+/* Selftests of location handling.  */
+
 /* Attempt to populate *OUT_RANGE with source location information on the
given character within the string literal found at STRLOC.
CHAR_IDX refers to an offset within the execution character set.
@@ -1493,7 +1499,7 @@ get_source_range_for_char (cpp_reader *pfile,
 /* As get_source_range_for_char, but write to *OUT the number
of ranges that are available.  */
 
-const char *
+static const char *
 get_num_source_ranges_for_substring (cpp_reader *pfile,
  string_concat_db *concats,
  location_t strloc,
@@ -1513,12 +1519,6 @@ get_num_source_ranges_for_substring (cpp_reader *pfile,
   return NULL;
 }
 
-#if CHECKING_P
-
-namespace selftest {
-
-/* Selftests of location handling.  */
-
 /* A class for writing out a temporary sourcefile for use in selftests
of input handling.  */
 
-- 
1.8.5.3

[PATCH 1/2] Adjust testcase for C++14 compatibility


These patches fix some failures seen when running tests with different
-std options.

   Adjust testcase for C++14 compatibility
   
   	* testsuite/24_iterators/headers/iterator/range_access.cc: Adjust

expected signatures for C++14 compatibility.

Tested powerpc64le-linux, committed to trunk.

commit 28d8a921bdab1065a080e3a40a2eedfb8b6443ed
Author: Jonathan Wakely 
Date:   Wed Aug 17 01:14:34 2016 +0100

Adjust testcase for C++14 compatibility

	* testsuite/24_iterators/headers/iterator/range_access.cc: Adjust
	expected signatures for C++14 compatibility.

diff --git a/libstdc++-v3/testsuite/24_iterators/headers/iterator/range_access.cc b/libstdc++-v3/testsuite/24_iterators/headers/iterator/range_access.cc
index b66381e..873a730 100644
--- a/libstdc++-v3/testsuite/24_iterators/headers/iterator/range_access.cc
+++ b/libstdc++-v3/testsuite/24_iterators/headers/iterator/range_access.cc
@@ -1,5 +1,4 @@
-// { dg-do compile }
-// { dg-options "-std=gnu++11" }
+// { dg-do compile { target c++11 } }
 
 // Copyright (C) 2010-2016 Free Software Foundation, Inc.
 //
@@ -28,6 +27,11 @@ namespace std
   template auto end(C& c) -> decltype(c.end());
   template auto end(const C& c) -> decltype(c.end());
 
+#if __cplusplus >= 201402L
+  template constexpr T* begin(T ()[N]);
+  template constexpr T* end(T ()[N]);
+#else
   template T* begin(T ()[N]);
   template T* end(T ()[N]);
+#endif
 }

Re: [PATCH] PR71752 - SLP: Maintain operand ordering when creating vec defs

On Wed, Aug 17, 2016 at 12:52 PM, Alan Hayward  wrote:
>
>
> On 16/08/2016 10:01, "Alan Hayward"  wrote:
>
>>
>>
>>On 16/08/2016 09:33, "Richard Biener"  wrote:
>>
>>>On Mon, Aug 15, 2016 at 4:16 PM, Alan Hayward 
>>>wrote:


 On 15/08/2016 12:17, "Richard Biener" 
wrote:

>On Mon, Aug 15, 2016 at 11:48 AM, Alan Hayward 
>wrote:
>> The testcase pr71752.c was failing because the SLP code was
>>generating
>>an
>> SLP
>> vector using arguments from the SLP scalar stmts, but was using the
>>wrong
>> argument number.
>>
>> vect_get_slp_defs() is given a vector of operands. When calling down
>>to
>> vect_get_constant_vectors it uses i as op_num - making the assumption
>>that
>> the
>> first op in the vector refers to the first argument in the SLP scalar
>> statement, the second op refers to the second arg and so on.
>>
>> However, previously in vectorizable_reduction, the call to
>> vect_get_vec_defs
>> destroyed this ordering by potentially only passing op1.
>>
>> The solution is in vectorizable_reduction to create a vector of
>>operands
>> equal
>> in size to the number of arguments in the SLP statements. We maintain
>>the
>> argument ordering and if we don't require defs for that argument we
>>instead
>> push NULL into the vector. In vect_get_slp_defs we need to handle
>>cases
>> where
>> an op might be NULL.
>>
>> Tested with a check run on X86 and AArch64.
>> Ok to commit?
>>
>
>Ugh.  Note the logic in vect_get_slp_defs is incredibly fragile - I
>think you can't
>simply "skip" ops the way you do as you need to still increment
>child_index
>accordingly for ignored ops.

 Agreed, I should be maintaining the child_index.
 Looking at the code, I need a valid oprnd for that code to work.

 Given that the size of the ops vector is never more than 3, it probably
 makes
 sense to reset child_index each time and do a quick for loop through
all
 the
 children.
>>>
>>>Hmm, yes - that should work.  It should also remove the need to keep
>>>operand order in sync?  So it might no longer require the
>>>vectorizable_reduction change.
>>
>>We still need to pass the correct index down to
>>vect_get_constant_vectors(),
>>which requires the operands in the original order for i to be correct.
>>(We can’t use child_index for that).
>>
>>Another option would be to pass down an additional vector containing the
>>indexes
>>of the operands. But I think that’d be an even worse option.
>>
>
> Updated with a loop for calculating child_index.
> Tested with a check run for x86 and aarch64.

LGTM.

Thanks,
Richard.

>
> diff --git a/gcc/testsuite/gcc.dg/vect/pr71752.c
> b/gcc/testsuite/gcc.dg/vect/pr71752.c
> new file mode 100644
> index
> ..8d26754b4fedf8b104caae8742a445dff
> bf23f0a
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/vect/pr71752.c
> @@ -0,0 +1,19 @@
> +/* { dg-do compile } */
> +
> +unsigned int q4, yg;
> +
> +unsigned int
> +w6 (unsigned int z5, unsigned int jv)
> +{
> +  unsigned int *f2 = 
> +
> +  while (*f2 < 21)
> +{
> +  q4 -= jv;
> +  z5 -= jv;
> +  f2 = 
> +  ++(*f2);
> +}
> +  return z5;
> +}
> +
> diff --git a/gcc/tree-vect-loop.c b/gcc/tree-vect-loop.c
> index
> 2a7e0c6661bc1ba82c9f03720e550749f2252a7c..826481af3d1d8b29bcdbd7d81c0fd5a85
> 9ecd9b0 100644
> --- a/gcc/tree-vect-loop.c
> +++ b/gcc/tree-vect-loop.c
> @@ -5364,7 +5364,7 @@ vectorizable_reduction (gimple *stmt,
> gimple_stmt_iterator *gsi,
>auto_vec vect_defs;
>auto_vec phis;
>int vec_num;
> -  tree def0, def1, tem, op0, op1 = NULL_TREE;
> +  tree def0, def1, tem, op1 = NULL_TREE;
>bool first_p = true;
>tree cr_index_scalar_type = NULL_TREE, cr_index_vector_type = NULL_TREE;
>gimple *cond_expr_induction_def_stmt = NULL;
> @@ -5964,29 +5964,36 @@ vectorizable_reduction (gimple *stmt,
> gimple_stmt_iterator *gsi,
>/* Handle uses.  */
>if (j == 0)
>  {
> -  op0 = ops[!reduc_index];
> -  if (op_type == ternary_op)
> -{
> -  if (reduc_index == 0)
> -op1 = ops[2];
> -  else
> -op1 = ops[1];
> -}
> + if (slp_node)
> +   {
> + /* Get vec defs for all the operands except the reduction index,
> +   ensuring the ordering of the ops in the vector is kept.  */
> + auto_vec slp_ops;
> + auto_vec vec_defs;
>
> -  if (slp_node)
> -vect_get_vec_defs (op0, op1, stmt, _oprnds0, _oprnds1,
> -   slp_node, -1);
> + slp_ops.quick_push ((reduc_index == 0) ? NULL :

Re: [RFC][IPA-VRP] Re-factor tree-vrp to factor out common code

On Wed, Aug 17, 2016 at 4:50 AM, kugan
 wrote:
> Hi Richard,
>
>
> On 17/08/16 08:20, kugan wrote:
>>
>> Hi,
>>
>> On 16/08/16 21:56, Richard Biener wrote:
>>>
>>> On Tue, Aug 16, 2016 at 10:09 AM, kugan
>>>  wrote:




 On 23/07/16 20:12, kugan wrote:
>
>
> Hi Richard,
>
>>> As we had value_range_type in tree-ssanames.h why not put value_range
>>> there?
>>>
>> For IPA_VRP, we now need value_range used in ipa-prop.h (in ipa-vrp
>> patch). Based on this, attached patch now adds struct value_range to
>> tree-ssanames.h and fixes the header files. Please note that I also
>> had
>> to add other headers in few places due to the dependency. Are you OK
>> with this ?
>
>
> Here is alternate patch where we keep struct value_range and enum
> value_range_type to tree-vrp.h. May be it is a better approach? Please
> let me know what is your preference.
>

 Ping?

 This patch places value_range_type and value_range in tree-vrp.h. May be
 this is better?

 Alternate patch which keeps value_range_type and value_range in
 tree-ssanames.h is in:
 https://gcc.gnu.org/ml/gcc-patches/2016-07/msg01491.html

 I also added the necessary header files changed needed for ipa-vrp as
 part
 of this patch so that changes needed are clear.
>>>
>>>
>>> I think tree-vrp.h is a better place.  Please don't export functions
>>> you don't need
>>> (the _1 helpers).
>
> I had unintentionally removed a static from a _1 helper. I think thats what
> caused the confusion. I also added constant modifiers to parameters mainly
> due to ipa-vrp passing second parameters to lattice operation as const.
>
>> Agreed.
>>
>> I have exported the following for now:
>> +extern void vrp_intersect_ranges (value_range *vr0, value_range *vr1);
>> +extern void vrp_meet (value_range *vr0, const value_range *vr1);
>> +extern void dump_value_range (FILE *, const value_range *);
>
>
> This again is the exported operations.
>
>> It might be useful to add vrp_unary_op, vrp_binary_op on value_range.
>> But that is for later if that is needed.
>>
>>>
>>> I still believe sharing vrp_initialize/finalize is wrong and the
>>> lattice setup / teardown
>>> should be split out.
>>
>>
>> I have done that too as part of the early-vrp patch in:
>>
>> https://gcc.gnu.org/ml/gcc-patches/2016-08/msg01155.html
>>
>> I just wanted to focus on the functionality required for the IPA-VRP on
>> this patch.
>
>
>
> Attaching the latest version of the patch. Is this OK?

Yes.

Thanks,
Richard.

> Thanks,
> Kugan

Re: [RFC][IPA-VRP] splits out the update_value_range calls from vrp_visit_stmt

On Wed, Aug 17, 2016 at 4:27 AM, kugan
 wrote:
> Hi,
>
>
> On 16/08/16 20:58, Richard Biener wrote:
>>
>> On Tue, Aug 16, 2016 at 9:39 AM, kugan
>>  wrote:
>>>
>>> Hi,
>>>
 as said the refactoring that would be appreciated is to split out the
 update_value_range calls
 from the worker functions so you can call the respective functions
 from the DOM implementations.
 That they are globbed in vrp_visit_stmt currently is due to the API of
 the SSA propagator.
>>>
>>>
>>>
>>> Here is a patch that just splits out the update_value_range calls
>>> visit_stmts. Bootstrapped and regression tested on x86_64-linux with no
>>> new
>>> regressions.
>>>
>>> I also verified few random fdump-tree-vrp1-details from stage2 to make
>>> sure
>>> they are same.
>>>
>>> Is this OK for trunk?
>>
>>
>> For vrp_visit_assignment_or_call please defer the question whether the
>> update
>> is interesting (for the internal call stuff) to the caller and always
>> return new_vr.
>>
>> Also do not perform the "not handled stmt" handling here but make the
>> return
>> value reflect whether we handled the stmt or not and put
>>
>>   /* Every other statement produces no useful ranges.  */
>>   FOR_EACH_SSA_TREE_OPERAND (def, stmt, iter, SSA_OP_DEF)
>> set_value_range_to_varying (get_value_range (def));
>>
>> into the caller (as that's also a lattice-updating thing).
>>
>> +static enum ssa_prop_result
>> +vrp_visit_stmt (gimple *stmt, edge *taken_edge_p, tree *output_p)
>> +{
>> +  value_range vr = VR_INITIALIZER;
>> +  tree lhs = gimple_get_lhs (stmt);
>> +  bool vr_found = vrp_visit_stmt_worker (stmt, taken_edge_p,
>> +output_p, );
>> +
>> +  if (lhs)
>> +{
>> +  if (vr_found
>> + && update_value_range (lhs, ))
>> +   {
>> + *output_p = lhs;
>>
>> I think rather than computing LHS here you should use *output_p.
>>
>> Otherwise this looks good though I'd rename the _worker variants
>> to extract_range_from_phi_node, extract_range_from_stmt and
>> extract_range_from_assignment_or_call.
>>
>
> Please find the patch attached which addresses the comments above. Bootstrap
> and regression testing is ongoing. Is this of if there is no new
> regressions?

Yes, this looks good to me.

Thanks,
Richard.

> Thanks,
> Kugan
>
>
> gcc/ChangeLog:
>
> 2016-08-17  Kugan Vivekanandarajah  
>
> * tree-vrp.c (vrp_visit_assignment_or_call): Changed to Return VR.
> (vrp_visit_cond_stmt): Just sets TAKEN_EDGE_P.
> (vrp_visit_switch_stmt): Likewise.
> (extract_range_from_stmt): Factored out from vrp_visit_stmt.
> (extract_range_from_phi_node): Factored out from vrp_visit_phi_stmt.
> (vrp_visit_stmt): Use extract_range_from_stmt.
> (vrp_visit_phi_node): Use extract_range_from_phi_node.
>

Re: [v3 PATCH] Implement LWG 2758.


On 16/08/16 16:15 +0300, Ville Voutilainen wrote:

On 16 August 2016 at 15:58, Jonathan Wakely  wrote:

This patch constrains the new overloads using:

 template
   using _If_sv = enable_if_t<
 __and_>::value,
 _Res>;

so that anything convertible to const _CharT* goes to the same
overload as would have been chosen prior to C++17.

I'm testing this now but won't commit it until it's clear this is a
sensible resolution for LWG 2758.



It's crystal clear to me that it is, ship it.


Here's what I've committed, adding tests for the other functions too.

Tested ppx64le-linux, committed to trunk.


commit 23d36bb4513f6917f55729080e03f3d69f558acf
Author: Jonathan Wakely 
Date:   Tue Aug 16 13:50:55 2016 +0100

PR 77264 constrain new std::basic_string overloads

	PR libstdc++/77264
	* include/bits/basic_string.h (operator=(__sv_type)
	(append(__sv_type), assign(__sv_type), insert(size_type, __sv_type))
	(replace(size_type, size_type, __sv_type))
	(replace(const_iterator, const_iterator, __sv_type))
	(find(__sv_type, size_type), rfind(__sv_type, size_type))
	(compare(size_type, size_type, __sv_type)): Reformat.
	(_If_sv): Define helper for SFINAE constaints.
	(append(const _Tp&, size_type, size_type))
	(assign(const _Tp&, size_type, size_type))
	(insert(size_type, const _Tp&, size_type, size_type))
	(replace(size_type, size_type, const _Tp&, size_type, size_type)):
	Use _If_sv.
	* testsuite/21_strings/basic_string/modifiers/append/char/4.cc: Test
	SFINAE constraints.
	* testsuite/21_strings/basic_string/modifiers/append/wchar_t/4.cc:
	Likewise.
	* testsuite/21_strings/basic_string/modifiers/replace/char/7.cc:
	Likewise.
	* testsuite/21_strings/basic_string/modifiers/replace/wchar_t/7.cc:
	Likewise.
	* testsuite/21_strings/basic_string/modifiers/assign/char/4.cc:
	Likewise.
	* testsuite/21_strings/basic_string/modifiers/assign/wchar_t/4.cc:
	Likewise.
	* testsuite/21_strings/basic_string/modifiers/insert/char/3.cc:
	Likewise.
	* testsuite/21_strings/basic_string/modifiers/insert/wchar_t/3.cc:
	Likewise.
	* testsuite/21_strings/basic_string/modifiers/replace/char/7.cc:
	Likewise.
	* testsuite/21_strings/basic_string/operations/compare/char/2.cc:
	Likewise.
	* testsuite/21_strings/basic_string/operations/compare/wchar_t/2.cc:
	Likewise.

diff --git a/libstdc++-v3/include/bits/basic_string.h b/libstdc++-v3/include/bits/basic_string.h
index 89e2100..68cfc99 100644
--- a/libstdc++-v3/include/bits/basic_string.h
+++ b/libstdc++-v3/include/bits/basic_string.h
@@ -709,7 +709,8 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
*  @brief  Set value to string constructed from a string_view.
*  @param  __sv  A string_view.
*/
-  basic_string& operator=(__sv_type __sv)
+  basic_string&
+  operator=(__sv_type __sv)
   {	return this->assign(__sv); }
 
   /**
@@ -1217,9 +1218,16 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
*  @param __sv  The string_view to be appended.
*  @return  Reference to this string.
*/
-  basic_string& append(__sv_type __sv)
+  basic_string&
+  append(__sv_type __sv)
   { return this->append(__sv.data(), __sv.size()); }
 
+  template
+	using _If_sv = enable_if_t<
+	  __and_>::value,
+	  _Res>;
+
   /**
*  @brief  Append a range of characters from a string_view.
*  @param __sv  The string_view to be appended from.
@@ -1227,17 +1235,15 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
*  @param __n   The number of characters to append from the string_view.
*  @return  Reference to this string.
*/
-  template ,
-			bool> = true>
-  basic_string& append(const _Tp& __svt,
-			   size_type __pos, size_type __n = npos)
-  {
-	__sv_type __sv = __svt;
-	return _M_append(__sv.data()
-			 + __sv._M_check(__pos, "basic_string::append"),
-			 __sv._M_limit(__pos, __n));
-  }
+  template 
+	_If_sv<_Tp, basic_string&>
+	append(const _Tp& __svt, size_type __pos, size_type __n = npos)
+	{
+	  __sv_type __sv = __svt;
+	  return _M_append(__sv.data()
+			   + __sv._M_check(__pos, "basic_string::append"),
+			   __sv._M_limit(__pos, __n));
+	}
 #endif // C++17
 
   /**
@@ -1386,7 +1392,8 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
*  @param __sv  The source string_view.
*  @return  Reference to this string.
*/
-  basic_string& assign(__sv_type __sv)
+  basic_string&
+  assign(__sv_type __sv)
   {	return this->assign(__sv.data(), __sv.size()); }
 
   /**
@@ -1396,18 +1403,15 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
*  @param __n  The number of characters to assign.
*  @return  Reference to this string.
*/
-  template ,
-			bool> = true>
-  basic_string&
-

Re: protected alloca class for malloc fallback

2016-08-17 Thread Martin Sebor


On 08/17/2016 02:27 AM, Richard Biener wrote:

On Tue, Aug 16, 2016 at 7:54 PM, Martin Sebor  wrote:

On 08/16/2016 10:47 AM, Jeff Law wrote:


On 08/16/2016 10:44 AM, Jakub Jelinek wrote:


On Tue, Aug 16, 2016 at 10:27:58AM -0600, Jeff Law wrote:


I think you're being rather short-sighed here.  GCC is being used in
ways we
can't necessarily predict -- which might include compile servers,
JITs, web
services, etc.



For compile server/web services one needs to add the protection
outside of
gcc (sandboxing, containers, SELinux, limiting CPU and/or memory, etc.),
because even with very short testcases e.g. in C/C++ one can eat
arbitrary
amounts of stack even without any uses of alloca in the compiler, simply
through deep recursion in the parsers etc.


Agreed.  However, that doesn't mean we should not be locking down things
like alloca and other attack vectors.



I think I made this suggestion when Aldy posted his first patch
but it didn't get much traction so let me try again.  Since the
concern is alloca calls with excessively large arguments, would
transforming those (determined both at compile time and at run
time) into pairs of malloc/free calls be an acceptable compromise?

It would seem like a natural complement to the transformation
in the opposite direction, brought up back then, of turning calls
to malloc with small (compile-time) arguments into alloca.

I would expect the malloc optimization to more than outweigh
the performance cost of the alloca to malloc transformation.
Perhaps even to the point to obviate the need for any explicit
alloca calls at all.  With the optimization in place, it seems
that it should even be possible to transparently transform at
least the most basic uses of some C++ containers written in
terms of operator new and delete to use alloca instead when
their sizes were known and under the alloca to malloc threshold.


Please instead work on sth like -fstack-protector for alloca -- it should
be straight-forward to add a runtime test on the stack adjustment
being performed against some magic bound (yeah, needs more than
only GCC support here).


I agree that would be a useful first step, and certainly a more 
attainable goal.  The C++ patch that handled the VLA part (bug

69517) had to be reverted just before 6.1 was released but it's
still on my to do list to add to it a knob to adjust the bound
at runtime and resubmit it.  It should be straightforward to
extend a similar approach to alloca and do the same thing in C
(except with trapping rather than throwing an exception).

Martin

Re: [PATCH, RELOAD] Don't assume subreg mem address is ok

2016-08-17 Thread Ulrich Weigand

Alan Modra wrote:

>   PR rtl-optimization/72771
>   * reload.c (find_reloads): Don't assume that a subreg mem is OK
>   when find_reloads_toplev returns address_reloaded==-1.
>   (alternative_allows_const_pool_ref): Update comment.
> testsuite/
>   * gcc.c-torture/compile/pr72771.c: New.

Yes, this makes sense.  address_reloaded == -1 means that the address
may or may not have been fully reloaded, so we always need to take the
conservative action in that case.

The patch is OK.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU/Linux compilers and toolchain
  ulrich.weig...@de.ibm.com

Re: [patch, OpenACC] Fix reduction lowering segfault in omp-low

2016-08-17 Thread Chung-Lin Tang

On 2016/8/15 5:57 PM, Jakub Jelinek wrote:
> On Mon, Aug 15, 2016 at 05:52:29PM +0800, Chung-Lin Tang wrote:
>> Hi Jakub,
>> This patch fixes an OpenACC reduction lowering segfault which
>> triggers when nested acc loop directives are present.
>> Cesar has reviewed this patch internally (since he mostly wrote
>> the code originally)
>>
>> Patch has been tested and committed to gomp-4_0-branch,
>> is this also okay for trunk?
>>
>> Thanks,
>> Chung-Lin
>>
>> 2016-08-15  Chung-Lin Tang  
>>
>> * omp-low.c (lower_oacc_reductions): Adjust variable lookup to use
>> maybe_lookup_decl, to handle nested acc loop directives.
> 
> Is this covered by an existing testcase in the testsuite?
> If not, can you please add a testcase for it.
> Otherwise LGTM (not extra happy about accepting any kinds of contexts,
> but I hope the nesting diagnostics error out on OpenMP contexts mixed with
> OpenACC ones and hope that there can't be some other OpenACC context around
> that you wouldn't want to handle).

Thanks, I've committed the patch along with a new testcase (full patch as 
attached).
Testcase is also backported to gomp-4_0-branch.

Thanks,
Chung-Lin

Index: omp-low.c
===
--- omp-low.c   (revision 239529)
+++ omp-low.c   (working copy)
@@ -5660,10 +5660,19 @@ lower_oacc_reductions (location_t loc, tree clause
outgoing = var;
incoming = omp_reduction_init_op (loc, rcode, type);
  }
-   else if (ctx->outer)
- incoming = outgoing = lookup_decl (orig, ctx->outer);
else
- incoming = outgoing = orig;
+ {
+   /* Try to look at enclosing contexts for reduction var,
+  use original if no mapping found.  */
+   tree t = NULL_TREE;
+   omp_context *c = ctx->outer;
+   while (c && !t)
+ {
+   t = maybe_lookup_decl (orig, c);
+   c = c->outer;
+ }
+   incoming = outgoing = (t ? t : orig);
+ }
  
  has_outer_reduction:;
  }
Index: testsuite/c-c++-common/goacc/reduction-6.c
===
--- testsuite/c-c++-common/goacc/reduction-6.c  (revision 0)
+++ testsuite/c-c++-common/goacc/reduction-6.c  (revision 0)
@@ -0,0 +1,58 @@
+/* Check if different occurences of the reduction clause on
+   OpenACC loop nests will compile.  */
+
+int foo (int N)
+{
+  int a = 0, b = 0, c = 0, d = 0, e = 0;
+
+  #pragma acc parallel
+  {
+#pragma acc loop
+for (int i = 0; i < N; i++)
+  {
+#pragma acc loop reduction(+:a)
+   for (int j = 0; j < N; j++)
+ a += 1;
+  }
+  }
+
+  #pragma acc parallel
+  {
+#pragma acc loop reduction(+:b)
+for (int i = 0; i < N; i++)
+  {
+#pragma acc loop
+   for (int j = 0; j < N; j++)
+ b += 1;
+  }
+  }
+
+  #pragma acc parallel
+  {
+#pragma acc loop reduction(+:c)
+for (int i = 0; i < N; i++)
+  {
+#pragma acc loop reduction(+:c)
+   for (int j = 0; j < N; j++)
+ c += 1;
+  }
+  }
+
+  #pragma acc parallel loop
+  for (int i = 0; i < N; i++)
+{
+  #pragma acc loop reduction(+:d)
+  for (int j = 0; j < N; j++)
+   d += 1;
+}
+
+  #pragma acc parallel loop reduction(+:e)
+  for (int i = 0; i < N; i++)
+{
+  #pragma acc loop reduction(+:e)
+  for (int j = 0; j < N; j++)
+   e += 1;
+}
+
+  return a + b + c + d + e;
+}

Re: [PATCH, Fortran] Extension: AUTOMATIC/STATIC symbol attributes with -fdec-static

2016-08-17 Thread Fritz Reese

https://gcc.gnu.org/ml/fortran/2016-08/msg00077.html

Minor correction to the previously submitted patch:

On Wed, Aug 17, 2016 at 7:20 AM, Fritz Reese  wrote:
> ...
> Note that AUTOMATIC does NOT override -fno-automatic; with the flag, a
> warning is produced for variables marked AUTOMATIC.
> ...

This statement was true for a previous version of this patch, but I
had changed the behavior and this is now incorrect. AUTOMATIC
attributes _do_ override -fno-automatic. I also submitted a slightly
older version of the patch file, which contained two errors. This
re-submission fixes these two artifacts; (1) Rename dec_static_*.for
-> dec_static-*.f90; and (2) fix a comment in the second test case:

--- a/gcc/testsuite/gfortran.dg/dec_static_2.f90
+++ b/gcc/testsuite/gfortran.dg/dec_static_2.f90
@@ -1,9 +1,7 @@
 ! { dg-do run }
 ! { dg-options "-fdec-static -fno-automatic -finit-local-zero" }
 !
-! Make sure a warning is produced when variables marked AUTOMATIC
-! cannot be automatic due to compilation with -fno-automatic, and
-! that they are in fact still saved.
+! Test STATIC and AUTOMATIC with -fno-automatic and recursive subroutines.
 !

The attached patch is the CORRECT version that I intend to commit.
Sorry for the mixup.

> Bootstraps and regtests on x86_64-redhat-linux. Questions, comments,
> and critique welcome. Ok for trunk?

---
Fritz Reese

> 08-17-2016  Fritz Reese  
>
> gcc/fortran/
> * lang.opt, invoke.texi, gfortran.texi: New flag -fdec-static.
> * options.c (set_dec_flags): Set -fdec-static with -fdec.
> * gfortran.h (symbol_attribute): New attribute AUTOMATIC.
> * gfortran.h (gfc_add_automatic): New prototype.
> * match.h (gfc_match_automatic, gfc_match_static): New functions.
> * decl.c (gfc_match_automatic, gfc_match_static): Ditto.
> * symbol.c (gfc_add_automatic): Ditto.
> * decl.c (match_attr_spec): Match AUTOMATIC and STATIC decls.
> * parse.c (decode_specification_statement, decode_statement): Ditto.
> * resolve.c (apply_default_init_local, resolve_fl_variable_derived,
> resolve_symbol): Support for automatic attribute.
> * symbol.c (check_conflict, gfc_copy_attr, gfc_is_var_automatic):
> Ditto.
> * trans-decl.c (gfc_finish_var_decl): Ditto.
>
> gcc/testsuite/gfortran.dg/
> * dec_static_1.f90, dec_static_2.f90: New testcases.
diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index ce5ebb7..db431dd 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -3794,6 +3794,7 @@ match_attr_spec (void)
 DECL_ALLOCATABLE = GFC_DECL_BEGIN, DECL_DIMENSION, DECL_EXTERNAL,
 DECL_IN, DECL_OUT, DECL_INOUT, DECL_INTRINSIC, DECL_OPTIONAL,
 DECL_PARAMETER, DECL_POINTER, DECL_PROTECTED, DECL_PRIVATE,
+DECL_STATIC, DECL_AUTOMATIC,
 DECL_PUBLIC, DECL_SAVE, DECL_TARGET, DECL_VALUE, DECL_VOLATILE,
 DECL_IS_BIND_C, DECL_CODIMENSION, DECL_ASYNCHRONOUS, DECL_CONTIGUOUS,
 DECL_NONE, GFC_DECL_END /* Sentinel */
@@ -3857,6 +3858,14 @@ match_attr_spec (void)
 		  d = DECL_ASYNCHRONOUS;
 		}
 		  break;
+
+case 'u':
+  if (match_string_p ("tomatic"))
+{
+  /* Matched "automatic".  */
+  d = DECL_AUTOMATIC;
+}
+  break;
 		}
 	  break;
 
@@ -3986,8 +3995,25 @@ match_attr_spec (void)
 	  break;
 
 	case 's':
-	  if (match_string_p ("save"))
-		d = DECL_SAVE;
+  gfc_next_ascii_char ();
+  switch (gfc_next_ascii_char  ())
+{
+  case 'a':
+if (match_string_p ("ve"))
+  {
+/* Matched "save".  */
+d = DECL_SAVE;
+  }
+break;
+
+  case 't':
+if (match_string_p ("atic"))
+  {
+/* Matched "static".  */
+d = DECL_STATIC;
+  }
+break;
+}
 	  break;
 
 	case 't':
@@ -4124,6 +4150,12 @@ match_attr_spec (void)
 	  case DECL_SAVE:
 	attr = "SAVE";
 	break;
+  case DECL_STATIC:
+attr = "STATIC";
+break;
+  case DECL_AUTOMATIC:
+attr = "AUTOMATIC";
+break;
 	  case DECL_TARGET:
 	attr = "TARGET";
 	break;
@@ -4152,6 +4184,18 @@ match_attr_spec (void)
   if (seen[d] == 0)
 	continue;
 
+  if ((d == DECL_STATIC || d == DECL_AUTOMATIC)
+  && !flag_dec_static)
+{
+  gfc_error ("%s at %L is a DEC extension, enable with -fdec-static",
+ d == DECL_STATIC ? "STATIC" : "AUTOMATIC", _at[d]);
+  m = MATCH_ERROR;
+  goto cleanup;
+}
+  /* Allow SAVE with STATIC, but don't complain. */

Re: transaction_safe exceptions prevent libstdc++ building for some targets

2016-08-17 Thread Joe Seymour

On 17/08/2016 12:30, Jonathan Wakely wrote:
> On 17/08/16 12:19 +0100, Joe Seymour wrote:
>> Disabling the original changes for targets with unsupported pointer sizes 
>> seems
>> like a reasonable solution to me, but I can't see an existing mechanism to do
>> so? Do others agree?
> 
> Yes, the intention was that the transaction-safe exceptions would only
> be defined where it is relatively straightforward to support them. If
> they're causing build failures they can be simply disabled for that
> target. Maybe the configure script should check for 32-bit or 64-bit
> pointers and completely disable the TM exceptions otherwise.
> 
>> More generally, it might be useful to have a mechanism to disable 
>> transactional
>> memory for some targets. I've observed things like register_tm_clones taking 
>> up
>> space in ARM Cortex-M binaries. Presumably, this would be achieved by adding 
>> an
>> --{enable,disable}-transactional-memory argument to configure? I'm happy to
>> work on a patch, if this is acceptable in principle.
> 
> I think that makes sense, for cases where the target can support the
> TM clones but they aren't wanted.
> 
> If we add such an option then the checks for 32/64-bit pointers can go
> in there, so that when the option isn't used the default depends on
> the target.
> 

I'll start working on a patch.

Thanks,

Joe

Re: [PATCH] Fix PR76490

On Mon, 15 Aug 2016, Richard Biener wrote:

> 
> The following fixes PR76490 which happens because how VRP expects
> +INF vs. +INF(OVF) to behave wrt comparisons.  I fixed all
> operand_equal_p cases that matter.
> 
> Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.

The following is what I applied - it adds more similar fixes and
has to XFAIL gcc.dg/pr52904.c because that was only "fixed" when
the bug was introduced.

Boostrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.

Richard.

2016-08-17  Richard Biener  

PR tree-optimization/76490
* tree-vrp.c (update_value_range): Preserve overflow infinities
when intersecting with ranges from get_range_info.
(operand_less_p): Handle overflow infinities correctly.
(value_range_constant_singleton): Use vrp_operand_equal_p
to handle overflow max/min correctly.
(vrp_valueize): Likewise.
(union_ranges): Likewise.
(intersect_ranges): Likewise.
(vrp_visit_phi_node): Improve iteration limitation to only
apply when we'll possibly re-visit the PHI via a changed argument
on the backedge.

* gfortran.fortran-torture/compile/pr76490.f90: New testcase.
* gcc.dg/pr52904.c: XFAIL.

Index: gcc/tree-vrp.c
===
*** gcc/tree-vrp.c.orig 2016-08-17 10:30:24.164280986 +0200
--- gcc/tree-vrp.c  2016-08-17 10:59:12.416332674 +0200
*** update_value_range (const_tree var, valu
*** 775,782 
{
  value_range nr;
  nr.type = rtype;
! nr.min = wide_int_to_tree (TREE_TYPE (var), min);
! nr.max = wide_int_to_tree (TREE_TYPE (var), max);
  nr.equiv = NULL;
  vrp_intersect_ranges (new_vr, );
}
--- 775,794 
{
  value_range nr;
  nr.type = rtype;
! /* Range info on SSA names doesn't carry overflow information
!so make sure to preserve the overflow bit on the lattice.  */
! if (new_vr->type == VR_RANGE
! && is_negative_overflow_infinity (new_vr->min)
! && wi::eq_p (new_vr->min, min))
!   nr.min = new_vr->min;
! else
!   nr.min = wide_int_to_tree (TREE_TYPE (var), min);
! if (new_vr->type == VR_RANGE
! && is_positive_overflow_infinity (new_vr->max)
! && wi::eq_p (new_vr->max, max))
!   nr.max = new_vr->max;
! else
!   nr.max = wide_int_to_tree (TREE_TYPE (var), max);
  nr.equiv = NULL;
  vrp_intersect_ranges (new_vr, );
}
*** operand_less_p (tree val, tree val2)
*** 1139,1145 
  {
/* LT is folded faster than GE and others.  Inline the common case.  */
if (TREE_CODE (val) == INTEGER_CST && TREE_CODE (val2) == INTEGER_CST)
! return tree_int_cst_lt (val, val2);
else
  {
tree tcmp;
--- 1151,1160 
  {
/* LT is folded faster than GE and others.  Inline the common case.  */
if (TREE_CODE (val) == INTEGER_CST && TREE_CODE (val2) == INTEGER_CST)
! {
!   if (! is_positive_overflow_infinity (val2))
!   return tree_int_cst_lt (val, val2);
! }
else
  {
tree tcmp;
*** static tree
*** 1423,1429 
  value_range_constant_singleton (value_range *vr)
  {
if (vr->type == VR_RANGE
!   && operand_equal_p (vr->min, vr->max, 0)
&& is_gimple_min_invariant (vr->min))
  return vr->min;
  
--- 1438,1444 
  value_range_constant_singleton (value_range *vr)
  {
if (vr->type == VR_RANGE
!   && vrp_operand_equal_p (vr->min, vr->max)
&& is_gimple_min_invariant (vr->min))
  return vr->min;
  
*** vrp_valueize (tree name)
*** 7006,7013 
  {
value_range *vr = get_value_range (name);
if (vr->type == VR_RANGE
! && (vr->min == vr->max
! || operand_equal_p (vr->min, vr->max, 0)))
return vr->min;
  }
return name;
--- 7021,7027 
  {
value_range *vr = get_value_range (name);
if (vr->type == VR_RANGE
! && vrp_operand_equal_p (vr->min, vr->max))
return vr->min;
  }
return name;
*** union_ranges (enum value_range_type *vr0
*** 7973,7980 
  enum value_range_type vr1type,
  tree vr1min, tree vr1max)
  {
!   bool mineq = operand_equal_p (*vr0min, vr1min, 0);
!   bool maxeq = operand_equal_p (*vr0max, vr1max, 0);
  
/* [] is vr0, () is vr1 in the following classification comments.  */
if (mineq && maxeq)
--- 7987,7994 
  enum value_range_type vr1type,
  tree vr1min, tree vr1max)
  {
!   bool mineq = vrp_operand_equal_p (*vr0min, vr1min);
!   bool maxeq = vrp_operand_equal_p (*vr0max, vr1max);
  
/* [] is vr0, () is vr1 in the following classification comments.  */
if (mineq && maxeq)
*** intersect_ranges (enum

[PATCH][6.2] Fix build error with in-tree ISL for GCC 4.3 host compiler


The ISL version we download from download_prerequesites on the GCC 6 
branch (0.15) has a trailing comma at the end of an enumerator list.
This causes GCC 4.3.4 to error as we are compiling with -pedantic
(GCC 4.4 and up just warn).  The following fixes this bootstrap issue
by patching the ISL sources after downloading them.

Tested on SLE11 SP4 with GCC 4.3.4 host compiler (where I also reproduced
the issue).

As we control ftp://gcc.gnu.org/pub/gcc/infrastructure/isl-0.15.tar.bz2
the sed expression is quite simplistic.

Ok for the GCC 6 branch?

I hope mv can reliably overwrite the destination on all supported
hosts (not sure if -f is portable).  I can use cp as well, of course.
I hope && outside of 'if' is portable as well.

Thanks,
Richard.

2016-08-17  Richard Biener  

* download_prerequisites: Patch ISL 0.15 to remove trailing comma
which causes PR77297.

Index: contrib/download_prerequisites
===
--- contrib/download_prerequisites  (revision 239479)
+++ contrib/download_prerequisites  (working copy)
@@ -52,5 +52,7 @@ if [ "$GRAPHITE_LOOP_OPT" = "yes" ] ; th
 
   wget ftp://gcc.gnu.org/pub/gcc/infrastructure/$ISL.tar.bz2 || exit 1
   tar xjf $ISL.tar.bz2  || exit 1
+  # Fix trailing comma which errors with -pedantic for host GCC <= 4.3
+  sed -e 's/isl_stat_ok = 0,/isl_stat_ok = 0/' isl-0.15/include/isl/ctx.h > 
isl-0.15/include/isl/ctx.h.tem && mv isl-0.15/include/isl/ctx.h.tem 
isl-0.15/include/isl/ctx.h
   ln -sf $ISL isl || exit 1
 fi

Re: transaction_safe exceptions prevent libstdc++ building for some targets


On 17/08/16 12:19 +0100, Joe Seymour wrote:
Disabling the original changes for targets with unsupported pointer 
sizes seems
like a reasonable solution to me, but I can't see an existing 
mechanism to do

so? Do others agree?


Yes, the intention was that the transaction-safe exceptions would only
be defined where it is relatively straightforward to support them. If
they're causing build failures they can be simply disabled for that
target. Maybe the configure script should check for 32-bit or 64-bit
pointers and completely disable the TM exceptions otherwise.

More generally, it might be useful to have a mechanism to disable 
transactional
memory for some targets. I've observed things like register_tm_clones 
taking up
space in ARM Cortex-M binaries. Presumably, this would be achieved by 
adding an

--{enable,disable}-transactional-memory argument to configure? I'm happy to
work on a patch, if this is acceptable in principle.


I think that makes sense, for cases where the target can support the
TM clones but they aren't wanted.

If we add such an option then the checks for 32/64-bit pointers can go
in there, so that when the option isn't used the default depends on
the target.

[PATCH, Fortran] Extension: AUTOMATIC/STATIC symbol attributes with -fdec-static

2016-08-17 Thread Fritz Reese

Greetings,

This patch extends the GNU Fortran front-end to add support for
DEC-style AUTOMATIC and STATIC symbol attributes with a new flag
-fdec-static, allowing explicit control of variable storage. AUTOMATIC
local variables are placed on the stack, whereas STATIC variables are
placed in static storage.

Currently, GNU Fortran provides some control over variable storage
through the use of its options -f[no-]automatic, -f[no-]recursive, and
-fmax-stack-var-size=, as well as the Fortran standard SAVE attribute.
However there is no way to mark a particular variable to be allocated
in automatic storage without potentially affecting other variables in
a given program. There are programs written in legacy (non-standard)
Fortran which do use the AUTOMATIC attribute for this reason. STATIC
is just an alias for SAVE, but provides further compatibility for such
legacy programs.

AUTOMATIC is implemented as a new symbol_attribute 'automatic', which
is checked in a couple places in resolve.c (apply_default_init_local,
resolve_fl_variable_derived, resolve_symbol), symbol.c
(gfc_is_var_automatic), and trans-decl.c (gfc_finish_var_decl). Note
that AUTOMATIC does NOT override -fno-automatic; with the flag, a
warning is produced for variables marked AUTOMATIC. STATIC is
implemented by setting the 'save' attribute and no distinction is made
from SAVE. Parser support for these attributes is enabled only with
the new compile flag -fdec-static.

Bootstraps and regtests on x86_64-redhat-linux. Questions, comments,
and critique welcome. Ok for trunk?

P.S. Historical note: a user of some legacy code pointed out to me
that some other compilers allow the AUTOMATIC attribute to be
specified for variables in an EQUIVALENCE, and that some legacy code
contains usages of such. As one of my primary goals is (unfortunately)
to provide support for legacy code I debated whether to allow this. In
the end I restricted this combination for several reasons. Firstly,
F95§5.5.1 states "... an equivalence object shall not be... an
automatic object...". This is a less convincing reason, since the
AUTOMATIC/STATIC attributes are already non-standard, and implement
non-standard behavior, but GNU Fortran in implementing the standard
will follow this behavior. Thus implementing an "automatic
equivalence" variable would potentially be non-trivial and have
strange consequences in the first place. Furthermore, I have found
empirically that other compilers which accept the combination
syntactically still specify in documentation that the combination is
illegal, and the implementation is unpredictable. So AUTOMATIC +
EQUIVALENCE seems like something to be fixed in user code.

---
Fritz Reese

08-17-2016  Fritz Reese  

gcc/fortran/
* lang.opt, invoke.texi, gfortran.texi: New flag -fdec-static.
* options.c (set_dec_flags): Set -fdec-static with -fdec.
* gfortran.h (symbol_attribute): New attribute AUTOMATIC.
* gfortran.h (gfc_add_automatic): New prototype.
* match.h (gfc_match_automatic, gfc_match_static): New functions.
* decl.c (gfc_match_automatic, gfc_match_static): Ditto.
* symbol.c (gfc_add_automatic): Ditto.
* decl.c (match_attr_spec): Match AUTOMATIC and STATIC decls.
* parse.c (decode_specification_statement, decode_statement): Ditto.
* resolve.c (apply_default_init_local, resolve_fl_variable_derived,
resolve_symbol): Support for automatic attribute.
* symbol.c (check_conflict, gfc_copy_attr, gfc_is_var_automatic):
Ditto.
* trans-decl.c (gfc_finish_var_decl): Ditto.

gcc/testsuite/gfortran.dg/
* dec_static_1.f90, dec_static_2.f90: New testcases.
diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index ce5ebb7..db431dd 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -3794,6 +3794,7 @@ match_attr_spec (void)
 DECL_ALLOCATABLE = GFC_DECL_BEGIN, DECL_DIMENSION, DECL_EXTERNAL,
 DECL_IN, DECL_OUT, DECL_INOUT, DECL_INTRINSIC, DECL_OPTIONAL,
 DECL_PARAMETER, DECL_POINTER, DECL_PROTECTED, DECL_PRIVATE,
+DECL_STATIC, DECL_AUTOMATIC,
 DECL_PUBLIC, DECL_SAVE, DECL_TARGET, DECL_VALUE, DECL_VOLATILE,
 DECL_IS_BIND_C, DECL_CODIMENSION, DECL_ASYNCHRONOUS, DECL_CONTIGUOUS,
 DECL_NONE, GFC_DECL_END /* Sentinel */
@@ -3857,6 +3858,14 @@ match_attr_spec (void)
 		  d = DECL_ASYNCHRONOUS;
 		}
 		  break;
+
+case 'u':
+  if (match_string_p ("tomatic"))
+{
+  /* Matched "automatic".  */
+  d = DECL_AUTOMATIC;
+}
+  break;
 		}
 	  break;
 
@@ -3986,8 +3995,25 @@ match_attr_spec (void)
 	  break;
 
 	case 's':
-	  if (match_string_p ("save"))
-		d = DECL_SAVE;
+  gfc_next_ascii_char ();
+  switch (gfc_next_ascii_char  ())
+{
+  case 'a':
+if

transaction_safe exceptions prevent libstdc++ building for some targets

2016-08-17 Thread Joe Seymour


../configure --target=msp430-elf --enable-languages=c,c++ && make -j4

Results in the msp430 -mlarge multilib failing to build with...

> configure: error: Unknown underlying type for size_t
> make[1]: *** [configure-target-libstdc++-v3] Error 1

This relates to...

> commit 13143e139230dc4d72710a6c4c312105aeddce4f
> Author: torvald 
> Date:  Fri Jan 15 22:42:41 2016 +
>
>libstdc++: Make certain exceptions transaction_safe.

https://gcc.gnu.org/ml/libstdc++/2016-01/msg00015.html

...which iterates through a list of types at configure time, looking for one
matching __SIZE_TYPE__. The following patch (wip) allows the build to 
proceed

(to the next error), by adding __int20 to the list of types to try.

- Is this an acceptable solution?
- There's a comment above GLIBCXX_CHECK_SIZE_T_MANGLING, saying that it was
  copied from libitm. Should that be updated too, even if it's 
irrelevant for

  msp430?

Proceeding past that build error, all multilibs then fail to build with...

> ../../../../../libstdc++-v3/src/c++11/cow-stdexcept.cc:274:3: error: 
static assertion failed: Pointers must be 32 bits or 64 bits wide

>  static_assert(sizeof(uint64_t) == sizeof(void*)

The assert fails because msp430 has 16-bit or 20-bit pointers. The same 
error

can be reproduced for the rl78-elf target, which has 16-bit pointers.

Disabling the original changes for targets with unsupported pointer 
sizes seems
like a reasonable solution to me, but I can't see an existing mechanism 
to do

so? Do others agree?

More generally, it might be useful to have a mechanism to disable 
transactional
memory for some targets. I've observed things like register_tm_clones 
taking up
space in ARM Cortex-M binaries. Presumably, this would be achieved by 
adding an

--{enable,disable}-transactional-memory argument to configure? I'm happy to
work on a patch, if this is acceptable in principle.

Thanks,

2016-08-XX  Joe Seymour  

* acinclude.m4 (GLIBCXX_CHCK_SIZE_T_MANGLING): Try __int20.
* configure: Regenerate.

diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
index b0f88cb..7332d3e 100644
--- a/libstdc++-v3/acinclude.m4
+++ b/libstdc++-v3/acinclude.m4
@@ -4405,9 +4405,13 @@ AC_DEFUN([GLIBCXX_CHECK_SIZE_T_MANGLING], [
[extern __SIZE_TYPE__ x; extern unsigned long 
long x;],

[glibcxx_cv_size_t_mangling=y], [
   AC_TRY_COMPILE([],
- [extern __SIZE_TYPE__ x; extern unsigned short 
x;],

- [glibcxx_cv_size_t_mangling=t],
- [glibcxx_cv_size_t_mangling=x])
+ [extern __SIZE_TYPE__ x; extern unsigned long 
long x;],

+ [glibcxx_cv_size_t_mangling=y], [
+AC_TRY_COMPILE([],
+   [extern __SIZE_TYPE__ x; extern __int20 
unsigned x;],

+   [glibcxx_cv_size_t_mangling=u6uint20],
+   [glibcxx_cv_size_t_mangling=x])
+  ])
 ])
   ])
 ])
diff --git a/libstdc++-v3/configure b/libstdc++-v3/configure
index 41797a9..7ab84eb 100755
--- a/libstdc++-v3/configure
+++ b/libstdc++-v3/configure
@@ -80475,13 +80475,28 @@ else
 int
 main ()
 {
-extern __SIZE_TYPE__ x; extern unsigned short x;
+extern __SIZE_TYPE__ x; extern unsigned long long x;
   ;
   return 0;
 }
 _ACEOF
 if ac_fn_c_try_compile "$LINENO"; then :
-  glibcxx_cv_size_t_mangling=t
+  glibcxx_cv_size_t_mangling=y
+else
+
+cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h.  */
+
+int
+main ()
+{
+extern __SIZE_TYPE__ x; extern __int20 unsigned x;
+  ;
+  return 0;
+}
+_ACEOF
+if ac_fn_c_try_compile "$LINENO"; then :
+  glibcxx_cv_size_t_mangling=u6uint20
 else
   glibcxx_cv_size_t_mangling=x
 fi
@@ -80497,6 +80512,9 @@ fi
 rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext

 fi
+rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
+
+fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: 
$glibcxx_cv_size_t_mangling" >&5

 $as_echo "$glibcxx_cv_size_t_mangling" >&6; }
   if test $glibcxx_cv_size_t_mangling = x; then

Re: [PATCH] PR71752 - SLP: Maintain operand ordering when creating vec defs

2016-08-17 Thread Alan Hayward



On 16/08/2016 10:01, "Alan Hayward"  wrote:

>
>
>On 16/08/2016 09:33, "Richard Biener"  wrote:
>
>>On Mon, Aug 15, 2016 at 4:16 PM, Alan Hayward 
>>wrote:
>>>
>>>
>>> On 15/08/2016 12:17, "Richard Biener" 
>>>wrote:
>>>
On Mon, Aug 15, 2016 at 11:48 AM, Alan Hayward 
wrote:
> The testcase pr71752.c was failing because the SLP code was
>generating
>an
> SLP
> vector using arguments from the SLP scalar stmts, but was using the
>wrong
> argument number.
>
> vect_get_slp_defs() is given a vector of operands. When calling down
>to
> vect_get_constant_vectors it uses i as op_num - making the assumption
>that
> the
> first op in the vector refers to the first argument in the SLP scalar
> statement, the second op refers to the second arg and so on.
>
> However, previously in vectorizable_reduction, the call to
> vect_get_vec_defs
> destroyed this ordering by potentially only passing op1.
>
> The solution is in vectorizable_reduction to create a vector of
>operands
> equal
> in size to the number of arguments in the SLP statements. We maintain
>the
> argument ordering and if we don't require defs for that argument we
>instead
> push NULL into the vector. In vect_get_slp_defs we need to handle
>cases
> where
> an op might be NULL.
>
> Tested with a check run on X86 and AArch64.
> Ok to commit?
>

Ugh.  Note the logic in vect_get_slp_defs is incredibly fragile - I
think you can't
simply "skip" ops the way you do as you need to still increment
child_index
accordingly for ignored ops.
>>>
>>> Agreed, I should be maintaining the child_index.
>>> Looking at the code, I need a valid oprnd for that code to work.
>>>
>>> Given that the size of the ops vector is never more than 3, it probably
>>> makes
>>> sense to reset child_index each time and do a quick for loop through
>>>all
>>> the
>>> children.
>>
>>Hmm, yes - that should work.  It should also remove the need to keep
>>operand order in sync?  So it might no longer require the
>>vectorizable_reduction change.
>
>We still need to pass the correct index down to
>vect_get_constant_vectors(),
>which requires the operands in the original order for i to be correct.
>(We can’t use child_index for that).
>
>Another option would be to pass down an additional vector containing the
>indexes
>of the operands. But I think that’d be an even worse option.
>

Updated with a loop for calculating child_index.
Tested with a check run for x86 and aarch64.


diff --git a/gcc/testsuite/gcc.dg/vect/pr71752.c
b/gcc/testsuite/gcc.dg/vect/pr71752.c
new file mode 100644
index 
..8d26754b4fedf8b104caae8742a445dff
bf23f0a
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/vect/pr71752.c
@@ -0,0 +1,19 @@
+/* { dg-do compile } */
+
+unsigned int q4, yg;
+
+unsigned int
+w6 (unsigned int z5, unsigned int jv)
+{
+  unsigned int *f2 = 
+
+  while (*f2 < 21)
+{
+  q4 -= jv;
+  z5 -= jv;
+  f2 = 
+  ++(*f2);
+}
+  return z5;
+}
+
diff --git a/gcc/tree-vect-loop.c b/gcc/tree-vect-loop.c
index 
2a7e0c6661bc1ba82c9f03720e550749f2252a7c..826481af3d1d8b29bcdbd7d81c0fd5a85
9ecd9b0 100644
--- a/gcc/tree-vect-loop.c
+++ b/gcc/tree-vect-loop.c
@@ -5364,7 +5364,7 @@ vectorizable_reduction (gimple *stmt,
gimple_stmt_iterator *gsi,
   auto_vec vect_defs;
   auto_vec phis;
   int vec_num;
-  tree def0, def1, tem, op0, op1 = NULL_TREE;
+  tree def0, def1, tem, op1 = NULL_TREE;
   bool first_p = true;
   tree cr_index_scalar_type = NULL_TREE, cr_index_vector_type = NULL_TREE;
   gimple *cond_expr_induction_def_stmt = NULL;
@@ -5964,29 +5964,36 @@ vectorizable_reduction (gimple *stmt,
gimple_stmt_iterator *gsi,
   /* Handle uses.  */
   if (j == 0)
 {
-  op0 = ops[!reduc_index];
-  if (op_type == ternary_op)
-{
-  if (reduc_index == 0)
-op1 = ops[2];
-  else
-op1 = ops[1];
-}
+ if (slp_node)
+   {
+ /* Get vec defs for all the operands except the reduction index,
+   ensuring the ordering of the ops in the vector is kept.  */
+ auto_vec slp_ops;
+ auto_vec vec_defs;

-  if (slp_node)
-vect_get_vec_defs (op0, op1, stmt, _oprnds0, _oprnds1,
-   slp_node, -1);
+ slp_ops.quick_push ((reduc_index == 0) ? NULL : ops[0]);
+ slp_ops.quick_push ((reduc_index == 1) ? NULL : ops[1]);
+ if (op_type == ternary_op)
+   slp_ops.quick_push ((reduc_index == 2) ? NULL : ops[2]);
+
+ vect_get_slp_defs (slp_ops, slp_node, _defs, -1);
+
+ vec_oprnds0.safe_splice (vec_defs[(reduc_index ==

Re: Fwd: [PATCH, doc/ARM, ping] Remove false affirmation that Thumb cannot use an FPU


Ping?

Best regards,

Thomas

On 11/08/16 11:31, Thomas Preudhomme wrote:

Hi Sandra,

Thanks for your feedback. Please find an updated version attached to this email.
ChangeLog entry is unchanged:

*** gcc/ChangeLog ***

2016-08-02  Thomas Preud'homme  

* doc/fragments.texi (MULTILIB_EXCEPTIONS): Replace example with
preventing combination of -mfloat-abi=soft with any -mfpu option.

Best regards,

Thomas

On 11/08/16 04:09, Sandra Loosemore wrote:

On 08/10/2016 09:51 AM, Thomas Preudhomme wrote:


diff --git a/gcc/doc/fragments.texi b/gcc/doc/fragments.texi
index
b6d8541c8ca820fa732363a05221e2cd4d1251c2..a060635c9cee7374d9d187858ac87acdd08860f2

100644
--- a/gcc/doc/fragments.texi
+++ b/gcc/doc/fragments.texi
@@ -117,12 +117,15 @@ specified, there are combinations that should not be
built.  In that
 case, set @code{MULTILIB_EXCEPTIONS} to be all of the switch exceptions
 in shell case syntax that should not be built.

-For example the ARM processor cannot execute both hardware floating
-point instructions and the reduced size THUMB instructions at the same
-time, so there is no need to build libraries with both of these
-options enabled.  Therefore @code{MULTILIB_EXCEPTIONS} is set to:
+For example on ARM targets @code{-mfloat-abi=soft} requests to use a
+softfloat implementation for floating-point operations.  Therefore, it


For example, on ARM targets @option{-mfloat-abi=soft} requests use of software
floating-point operations.  Therefore, it


+does not make sense to find both @code{-mfloat-abi=soft} and an


@option here too


+@code{mfpu} option on the command line so @code{MULTILIB_EXCEPTIONS}


and here @option{-mfpu}


+could contain the following exception (assuming that @code{-mfloat-abi}


@option


+comes after in MULTILIB_OPTIONS and given that soft is the default


@code markup on MULTILIB_OPTIONS?
@samp markup on soft?


+value):
 @smallexample
-*mthumb/*mhard-float*
+*mfpu=*
 @end smallexample

 @findex MULTILIB_REQUIRED


-Sandra

Re: [PATCH] [GCC] Don't use section anchors for declarations that don't fit in a single anchor range

2016-08-17 Thread Richard Earnshaw (lists)

On 17/08/16 09:23, Richard Biener wrote:
> On Tue, Aug 16, 2016 at 6:06 PM, Jeff Law  wrote:
>> On 08/16/2016 08:01 AM, Tamar Christina wrote:
>>>
>>>
>>> Hi All,
>>>
>>> This patch turns off the usage of section anchors for
>>> declarations that do not fit in a single anchor range.
>>> A large enough object will use the full anchor range
>>> and also force the use of another anchor pointer.
>>>
>>> By not using an anchor for large objects more globals
>>> can share the same anchor.
>>>
>>> The patch has been benchmarked using Spec2000 and
>>> the impact on performance is negligible, however some files
>>> using large arrays showed a appreciable reduction in amount of
>>> instructions in the assembly file.
>>>
>>> Regression tests were run on aarch64-none-elf and no regressions.
>>>
>>> Ok for trunk?
>>>
>>> 2016-08-16  Tamar Christina  
>>> Ramana Radhakrishnan  
>>>
>>> * gcc/varasm.c
>>> (default_use_anchors_for_symbol_p): Reject too large decls.
>>
>> Do you have to worry about DECL_SIZE being non-constant here or are those
>> filtered out earlier?
> 
> Globals can't have variable size.
> 

And Common variables (which may change size at link time) can't go in
anchor groups.  Nor, for that matter, can anything that's preemtible at
link time.

R.


> Richard.
> 
>> jeff
>

Re: [PATCH, ping] genmultilib: improve error reporting for MULTILIB_REUSE

Ping?

Best regards,

Thomas

On 10/08/16 15:07, Thomas Preudhomme wrote:

Hi,

It was discovered while working on ARM's aprofile multilib Makefile fragment
that some REUSE rules were mentioning on the RHS options not in
MULTILIB_OPTIONS. This is not supposed to happen and leads to unexpected
behavior: genmultilib will generate a rule that matches for any option not in
MULTILIB_OPTIONS (eg. in the case of ARM, it would create a rule matching for
-march=armv7-a -mfloat-abi=hard with any -mfpu option not in MULTILIB_OPTIONS).

This patch (i) adds logic in genmultilib to detect this situation and give an
error. It also make sure (ii) the error is visible by outputing it to standard
error since standard output is redirected to multilib.h when invoking
genmultilib. Finally, (iii) it documents the need to use options present in
MULTILIB_OPTIONS while doing various small wording fixes.

Patch is in attachment. ChangeLog entry is as follows:

*** gcc/ChangeLog ***

2016-08-01 Thomas Preud'homme

* doc/fragments.texi (MULTILIB_REUSE): Mention that only options in
MULTILIB_OPTIONS should be used. Small wording fixes.
* genmultilib: Memorize set of all option combinations in
combination_space. Detect if RHS of MULTILIB_REUSE uses an option not
found in MULTILIB_OPTIONS by checking if option set is listed in
combination_space. Output new and existing error message to stderr.

GCC and libgcc have been built with multilib for all targets supporting
--with-multilib-list without error as follows:

* --build=i386-linux-gnu --with-multilib-list=m32,m64,mx32
* --target=x86_64-linux-gnu --with-multilib-list=m32,m64,mx32
* --target=sh-none-elf
--with-multilib-list=m1,m2,m2e,m3,m3e,m4,m4-single,m4a-single-only,m4al,m2a,m2a-single,m2a-single-only
(lib1func failed to build with -nofpu variants due to unrecognized instructions)
* --target=aarch64-none-elf --with-multilib-list=default
* --target=arm-none-eabi --with-multilib-list=aprofile

Is this ok for trunk?

Best regards,

Thomas

Re: [PATCH, ARM, ping] Use a MULTILIB_REQUIRED approach for aprofile multilib


Ping?

Best regards,

Thomas

On 10/08/16 14:51, Thomas Preudhomme wrote:

Hi,

Currently, the Makefile fragment for ARM aprofile multilib is using a
substractive approach. It specifies a set of options to be combined (eg.
-march=armv7-a,armv7ve,armv8-a, with
-mfpu=vfpv3-d16,neon,vfpv4-d16,neon-fpv4,neon-fp-armv8) using MULTILIB_OPTIONS
and then specifies which combination should *not* be built with
MULTILIB_EXCEPTIONS.

This patch replaces that approach by an additive one: using MULTILIB_REQUIRED to
specify the combinations we *do* want. This approach is more scalable and
maintainable:

1) Scalability

The substractive approach (MULTILIB_EXCEPTIONS) is doable today because there is
only 3 -march and 5 -mfpu options in t-aprofile. Yet it needs already 22
MULTILIB_EXCEPTIONS to define the set of multilib to be built. Adding new
architecture or new mfpu would make that worse. Since we only care about a small
number of combinations (each mfpu is used with only one march), it makes more
sense to specify what we want. The new approach only needs 9 MULTILIB_REQUIRED
lines.

2) Maintainability

Adding one new architecture or vfp option means adding exceptions for all
combinations which does not make sense with that option (eg. if we add mfpu=foo
we'll have to exclude all the march we don't want to mix with foo). It forces us
to think about all combinations involved with this new option and thinking about
the combinations in it that we do not want. Basically we have to do the work of
genmultilib in our mind. MULTILIB_REQUIRED on the other hand would allow us to
just specify the combination involving that new option that we care about which
is likely to be more obvious IMHO.

Patch is in attachment. ChangeLog entry is as follows:


*** gcc/ChangeLog ***

2016-08-01  Thomas Preud'homme  

* config/arm/t-aprofile (MULTILIB_EXCEPTIONS): Rewrite into ...
(MULTILIB_REQUIRED): This by specifying multilib needing to be built
rather than those that should not be built.


The output of "tree lib/gcc/arm-none-eabi/7.0.0" before and after the patch
shows that the same set of multilib is being built.

Is this ok for trunk?

Best regards,

Thomas

Re: [PATCH, ARM, ping] Fix aprofile multilib mappings


Ping?

Best regards,

Thomas

On 10/08/16 14:28, Thomas Preudhomme wrote:

Hi,

Mappings (MULTILIB_MATCHES and MULTILIB_REUSE) in ARM aprofile multilib suffer
from a number of issues:

* missing mapping of -mcpu=cortex-a7 to -march=armv7-a
* typo on vfpv3-d16-fp16 (MULTILIB_MATCHES uses vfpv3-fp16-d16 instead)
* missing mapping for neon-fp16, fpv5-d16 and fp-armv8 to neon, vfpv4 and vfpv4
respectively
* reuse directive with option not in MULTILIB_OPTION (-mfpu=vfpv4 and
-mfpu=fp-armv8)

The latter leads to unexpected results currently: GCC creates a reuse mapping
that match for any -mfpu not in MULTILIB_OPTIONS. This means for instance that
-march=armv7-a -mfpu=vfp -mfloat-abi=hard is mapped to -march=armv7-a
-mfpu=vfpv3-d16 -mfloat-abi=hard. With this patch, it is now mapped to the
default multilib (ie. -print-multi-directory gives .) which is a softfloat
multilib. Arguably an option not in MULTILIB_OPTIONS should give an error when
appearing in MULTILIB_REUSE rather the current behavior. This should be the
object of a future patch.

The patch in attachment fixes all the issues mentioned above.

ChangeLog entry is as follows:


*** gcc/ChangeLog ***

2016-08-01  Thomas Preud'homme  

* config/arm/t-aprofile (MULTILIB_MATCHES): Add mapping for
-mcpu=cortex-a7, -mfpu=neon-fp16, -mfpu=fpv5-d16 and -mfpu=fp-armv8.
Fix typo in -mfpu=vfpv3-d16-fp16 mapping.
(MULTILIB_REUSE): Remove reuse rules for option set including
-mfpu=fp-armv8 and -mfpu=vfpv4


The mappings added have been tested to work as expected and the option
combinations that the intended behavior of removed MULTILIB_REUSE directives
were checked as well. For details, see [1]. Regression testsuite for
arm-none-eabi with aprofile multilib shows no regression.

Is this ok for trunk?

Best regards,

Thomas


[1] Format of the tests is as follows:

# expected mapping
% command line for getting multilib we should be mapping to
expected result
% command line for the multilib that should be mapped to the one above
[before] result without patch
[ after] result with patch

Provided that the second set of options should indeed be mapped to the first
set, the result [ after] should be the same as the expected result.


# cortex-a7 -> armv7-a
% arm-none-eabi-gcc -march=armv7ve -print-multi-directory
v7ve
% arm-none-eabi-gcc -mcpu=cortex-a7 -print-multi-directory
[before] .
[ after] v7ve

# vfpv3-d16-fp16 -> vfpv3-d16
% arm-none-eabi-gcc -march=armv7ve -mfpu=vfpv3-d16 -mfloat-abi=hard
-print-multi-directory
v7-a/fpv3/hard
% arm-none-eabi-gcc -march=armv7ve -mfpu=vfpv3-d16-fp16 -mfloat-abi=hard
-print-multi-directory
[before] v7ve/fpv4/hard
[ after] v7-a/fpv3/hard

# neon-fp16 -> neon
arm-none-eabi-gcc -march=armv7-a -mfpu=neon -mfloat-abi=hard 
-print-multi-directory
v7-a/simdv1/hard
% arm-none-eabi-gcc -march=armv7-a -mfpu=neon-fp16 -mfloat-abi=hard
-print-multi-directory
[before] v7-a/fpv3/hard
[ after] v7-a/simdv1/hard

# fpv5-d16 -> vfpv4-d16
% arm-none-eabi-gcc -march=armv7ve -mfpu=vfpv4-d16 -mfloat-abi=hard
-print-multi-directory
v7ve/fpv4/hard
% arm-none-eabi-gcc -march=armv7ve -mfpu=fpv5-d16 -mfloat-abi=hard
-print-multi-directory
[before] v7ve/fpv4/hard
[ after] v7ve/fpv4/hard

# fp-armv8 -> vfpv4-d16
% arm-none-eabi-gcc -march=armv7ve -mfpu=vfpv4-d16 -mfloat-abi=hard
-print-multi-directory
v7ve/fpv4/hard
% arm-none-eabi-gcc -march=armv7ve -mfpu=fp-armv8 -mfloat-abi=hard
-print-multi-directory
[before] v7ve/fpv4/hard
[ after] v7ve/fpv4/hard

# armv7-a vfpv4 softfp -> armv7-a vfpv3-d16 softfp
% arm-none-eabi-gcc -march=armv7-a -mfpu=vfpv4-d16 -mfloat-abi=softfp
-print-multi-directory
v7-a/fpv3/softfp
% arm-none-eabi-gcc -march=armv7-a -mfpu=vfpv4 -mfloat-abi=softfp
-print-multi-directory
[before] v7-a/fpv3/softfp
[ after] v7-a/fpv3/softfp

# armv7-a vfpv4 hard -> armv7-a vfpv3-d16 hard
% arm-none-eabi-gcc -march=armv7-a -mfpu=vfpv3-d16 -mfloat-abi=hard
-print-multi-directory
v7-a/fpv3/hard
% arm-none-eabi-gcc -march=armv7-a -mfpu=vfpv4 -mfloat-abi=hard
-print-multi-directory
[before] v7-a/fpv3/hard
[ after] v7-a/fpv3/hard

# armv7ve fp-armv8 softfp -> armv7ve vfpv4-d16 softfp
% arm-none-eabi-gcc -march=armv7ve -mfpu=vfpv4-d16 -mfloat-abi=softfp
-print-multi-directory
v7ve/fpv4/softfp
% arm-none-eabi-gcc -march=armv7ve -mfpu=fp-armv8 -mfloat-abi=softfp
-print-multi-directory
[before] v7ve/fpv4/softfp
[ after] v7ve/fpv4/softfp

# armv7ve fp-armv8 hard -> armv7ve vfpv4-d16 hard
% arm-none-eabi-gcc -march=armv7ve -mfpu=vfpv4-d16 -mfloat-abi=hard
-print-multi-directory
v7ve/fpv4/hard
% arm-none-eabi-gcc -march=armv7ve -mfpu=fp-armv8 -mfloat-abi=hard
-print-multi-directory
[before] v7ve/fpv4/hard
[ after] v7ve/fpv4/hard

# armv8-a vfpv4 softfp -> armv7ve vfpv4-d16 softfp
% arm-none-eabi-gcc -march=armv7ve -mfpu=vfpv4-d16 -mfloat-abi=softfp
-print-multi-directory
v7ve/fpv4/softfp
% arm-none-eabi-gcc -march=armv8-a -mfpu=vfpv4 -mfloat-abi=softfp
-print-multi-directory
[before] v7ve/fpv4/softfp

Re: [PATCH] Fix ICE with FRE devirtualization (PR middle-end/77259)

On Wed, 17 Aug 2016, Jakub Jelinek wrote:

> On Wed, Aug 17, 2016 at 10:03:28AM +0200, Richard Biener wrote:
> > On Tue, 16 Aug 2016, Jakub Jelinek wrote:
> > 
> > > Hi!
> > > 
> > > The FRE devirtualization unlike gimple-fold or other places would 
> > > transform
> > > some method call with TREE_ADDRESSABLE lhs into __builtin_unreachable call
> > > with the same lhs, which is invalid (__builtin_unreachable returns void).
> > > Also, gimple_call_fntype has not been adjusted in these cases.
> > > 
> > > Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok 
> > > for
> > > trunk?  What about 6.x?  Do you prefer it in 6.2, or 6.3?
> > 
> > I think the patch can be simplified to just set fntype - PRE/FRE already
> > arrange to fixup stmts, including calling fixup_noreturn_call which
> > removes the lhs if required.
> 
> That isn't enough, unless fixup_noreturn_call is changed to test not just
> should_remove_lhs_p, but also VOID_TYPE_P (TREE_TYPE (gimple_call_fntype 
> (call_stmt))
> Otherwise, should_remove_lhs_p would in this case return true (we don't want
> to remove TREE_ADDRESSABLE lhs).  The exception is when we change the return
> type because we've turned the function into one returning void (i.e.
> __builtin_unreachable/__cxa_pure_virtual and the like).
> 
> So, do you prefer following (so far tested just with make check-g++ 
> RUNTESTFLAGS=devirt*.C)
> instead?

Yes.  This is ok if it passes testing.  I wonder if should_remove_lhs_p
should better take the stmt as argument so it can perform the test for
the exception itself.

Thanks,
Richard.

> 2016-08-17  Jakub Jelinek  
> 
>   PR middle-end/77259
>   * tree-ssa-pre.c (eliminate_dom_walker::before_dom_children): If
>   turning a call into __builtin_unreachable-like noreturn call, adjust
>   gimple_call_set_fntype.
>   * tree-cfgcleanup.c (fixup_noreturn_call): Remove lhs also if
>   gimple_call_fntype has void return type.
> 
>   * g++.dg/ipa/devirt-52.C: New test.
> 
> --- gcc/tree-ssa-pre.c.jj 2016-08-16 13:22:49.095671219 +0200
> +++ gcc/tree-ssa-pre.c2016-08-17 10:24:42.498730917 +0200
> @@ -4543,6 +4543,15 @@ eliminate_dom_walker::before_dom_childre
>  lang_hooks.decl_printable_name (fn, 2));
>   }
> gimple_call_set_fndecl (call_stmt, fn);
> +   /* If changing the call to __builtin_unreachable
> +  or similar noreturn function, adjust gimple_call_fntype
> +  too.  */
> +   if (gimple_call_noreturn_p (call_stmt)
> +   && VOID_TYPE_P (TREE_TYPE (TREE_TYPE (fn)))
> +   && TYPE_ARG_TYPES (TREE_TYPE (fn))
> +   && (TREE_VALUE (TYPE_ARG_TYPES (TREE_TYPE (fn)))
> +   == void_type_node))
> + gimple_call_set_fntype (call_stmt, TREE_TYPE (fn));
> maybe_remove_unused_call_args (cfun, call_stmt);
> gimple_set_modified (stmt, true);
>   }
> --- gcc/tree-cfgcleanup.c.jj  2016-08-09 09:41:14.0 +0200
> +++ gcc/tree-cfgcleanup.c 2016-08-17 10:36:24.198791289 +0200
> @@ -602,9 +602,14 @@ fixup_noreturn_call (gimple *stmt)
>/* If there is an LHS, remove it, but only if its type has fixed size.
>   The LHS will need to be recreated during RTL expansion and creating
>   temporaries of variable-sized types is not supported.  Also don't
> - do this with TREE_ADDRESSABLE types, as assign_temp will abort.  */
> + do this with TREE_ADDRESSABLE types, as assign_temp will abort.
> + Drop LHS regardless of TREE_ADDRESSABLE, if the function call
> + has been changed into a call that does not return a value, like
> + __builtin_unreachable or __cxa_pure_virtual.  */
>tree lhs = gimple_call_lhs (stmt);
> -  if (should_remove_lhs_p (lhs))
> +  if (lhs
> +  && (should_remove_lhs_p (lhs)
> +   || VOID_TYPE_P (TREE_TYPE (gimple_call_fntype (stmt)
>  {
>gimple_call_set_lhs (stmt, NULL_TREE);
>  
> --- gcc/testsuite/g++.dg/ipa/devirt-52.C.jj   2016-08-17 10:23:39.775528901 
> +0200
> +++ gcc/testsuite/g++.dg/ipa/devirt-52.C  2016-08-17 10:23:39.775528901 
> +0200
> @@ -0,0 +1,56 @@
> +// PR middle-end/77259
> +// { dg-do compile { target c++11 } }
> +// { dg-options "-O2" }
> +
> +template  class A;
> +template  struct A
> +{
> +  A (A &&);
> +};
> +template 
> +A operator+(S *, const A &);
> +template 
> +void operator+(const A &, S *);
> +struct B
> +{
> +  template  B (V);
> +};
> +template  V foo (B) {}
> +class C;
> +template  struct D
> +{
> +  C *operator->() { return d; }
> +  C *d;
> +};
> +struct C
> +{
> +  virtual A bar ();
> +};
> +struct E
> +{
> +  ~E ();
> +  virtual A bar (const B &) const;
> +};
> +template  struct F : E
> +{
> +};
> +template  struct F : E
> +{
> +  A bar (const B &) const try
> +{
>

Re: [PATCH] Fix ICE with FRE devirtualization (PR middle-end/77259)

On Wed, Aug 17, 2016 at 10:03:28AM +0200, Richard Biener wrote:
> On Tue, 16 Aug 2016, Jakub Jelinek wrote:
> 
> > Hi!
> > 
> > The FRE devirtualization unlike gimple-fold or other places would transform
> > some method call with TREE_ADDRESSABLE lhs into __builtin_unreachable call
> > with the same lhs, which is invalid (__builtin_unreachable returns void).
> > Also, gimple_call_fntype has not been adjusted in these cases.
> > 
> > Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
> > trunk?  What about 6.x?  Do you prefer it in 6.2, or 6.3?
> 
> I think the patch can be simplified to just set fntype - PRE/FRE already
> arrange to fixup stmts, including calling fixup_noreturn_call which
> removes the lhs if required.

That isn't enough, unless fixup_noreturn_call is changed to test not just
should_remove_lhs_p, but also VOID_TYPE_P (TREE_TYPE (gimple_call_fntype 
(call_stmt))
Otherwise, should_remove_lhs_p would in this case return true (we don't want
to remove TREE_ADDRESSABLE lhs).  The exception is when we change the return
type because we've turned the function into one returning void (i.e.
__builtin_unreachable/__cxa_pure_virtual and the like).

So, do you prefer following (so far tested just with make check-g++ 
RUNTESTFLAGS=devirt*.C)
instead?

2016-08-17  Jakub Jelinek  

PR middle-end/77259
* tree-ssa-pre.c (eliminate_dom_walker::before_dom_children): If
turning a call into __builtin_unreachable-like noreturn call, adjust
gimple_call_set_fntype.
* tree-cfgcleanup.c (fixup_noreturn_call): Remove lhs also if
gimple_call_fntype has void return type.

* g++.dg/ipa/devirt-52.C: New test.

--- gcc/tree-ssa-pre.c.jj   2016-08-16 13:22:49.095671219 +0200
+++ gcc/tree-ssa-pre.c  2016-08-17 10:24:42.498730917 +0200
@@ -4543,6 +4543,15 @@ eliminate_dom_walker::before_dom_childre
   lang_hooks.decl_printable_name (fn, 2));
}
  gimple_call_set_fndecl (call_stmt, fn);
+ /* If changing the call to __builtin_unreachable
+or similar noreturn function, adjust gimple_call_fntype
+too.  */
+ if (gimple_call_noreturn_p (call_stmt)
+ && VOID_TYPE_P (TREE_TYPE (TREE_TYPE (fn)))
+ && TYPE_ARG_TYPES (TREE_TYPE (fn))
+ && (TREE_VALUE (TYPE_ARG_TYPES (TREE_TYPE (fn)))
+ == void_type_node))
+   gimple_call_set_fntype (call_stmt, TREE_TYPE (fn));
  maybe_remove_unused_call_args (cfun, call_stmt);
  gimple_set_modified (stmt, true);
}
--- gcc/tree-cfgcleanup.c.jj2016-08-09 09:41:14.0 +0200
+++ gcc/tree-cfgcleanup.c   2016-08-17 10:36:24.198791289 +0200
@@ -602,9 +602,14 @@ fixup_noreturn_call (gimple *stmt)
   /* If there is an LHS, remove it, but only if its type has fixed size.
  The LHS will need to be recreated during RTL expansion and creating
  temporaries of variable-sized types is not supported.  Also don't
- do this with TREE_ADDRESSABLE types, as assign_temp will abort.  */
+ do this with TREE_ADDRESSABLE types, as assign_temp will abort.
+ Drop LHS regardless of TREE_ADDRESSABLE, if the function call
+ has been changed into a call that does not return a value, like
+ __builtin_unreachable or __cxa_pure_virtual.  */
   tree lhs = gimple_call_lhs (stmt);
-  if (should_remove_lhs_p (lhs))
+  if (lhs
+  && (should_remove_lhs_p (lhs)
+ || VOID_TYPE_P (TREE_TYPE (gimple_call_fntype (stmt)
 {
   gimple_call_set_lhs (stmt, NULL_TREE);
 
--- gcc/testsuite/g++.dg/ipa/devirt-52.C.jj 2016-08-17 10:23:39.775528901 
+0200
+++ gcc/testsuite/g++.dg/ipa/devirt-52.C2016-08-17 10:23:39.775528901 
+0200
@@ -0,0 +1,56 @@
+// PR middle-end/77259
+// { dg-do compile { target c++11 } }
+// { dg-options "-O2" }
+
+template  class A;
+template  struct A
+{
+  A (A &&);
+};
+template 
+A operator+(S *, const A &);
+template 
+void operator+(const A &, S *);
+struct B
+{
+  template  B (V);
+};
+template  V foo (B) {}
+class C;
+template  struct D
+{
+  C *operator->() { return d; }
+  C *d;
+};
+struct C
+{
+  virtual A bar ();
+};
+struct E
+{
+  ~E ();
+  virtual A bar (const B &) const;
+};
+template  struct F : E
+{
+};
+template  struct F : E
+{
+  A bar (const B &) const try
+{
+  D a = baz ();
+}
+  catch (int)
+{
+}
+  D baz () const
+  {
+D b = foo(0);
+"" + b->bar () + "";
+  }
+};
+struct G : F
+{
+  G (int);
+};
+void test () { G (0); }


Jakub

Re: [PATCH 2/3] Smarter folding of __builtin_memchr

On Tue, Aug 16, 2016 at 3:14 PM, marxin  wrote:
> gcc/ChangeLog:
>
> 2016-08-16  Martin Liska  
>
> * builtins.c (fold_builtin_memchr): Support following
> transformations:
> memchr (x, y, 0) -> NULL
> memchr ("known_string", 'n', 5) -> &"known_string" + 1
> memchr ("known_string", 'n', 1) -> NULL

Aww.  Can I convince you to move this and related foldings to gimple-fold.c?

Richard.

> ---
>  gcc/builtins.c | 20 
>  1 file changed, 16 insertions(+), 4 deletions(-)
>
> diff --git a/gcc/builtins.c b/gcc/builtins.c
> index 8f1c752..ac251f8 100644
> --- a/gcc/builtins.c
> +++ b/gcc/builtins.c
> @@ -7267,8 +7267,12 @@ fold_builtin_memchr (location_t loc, tree arg1, tree 
> arg2, tree len, tree type)
>   || !tree_fits_uhwi_p (len))
> return NULL_TREE;
>
> +  /* If the LEN parameter is zero, return zero.  */
> +  if (integer_zerop (len))
> +   return build_int_cst (TREE_TYPE (arg1), 0);
> +
>p1 = c_getstr (arg1);
> -  if (p1 && compare_tree_int (len, strlen (p1) + 1) <= 0)
> +  if (p1)
> {
>   char c;
>   const char *r;
> @@ -7281,9 +7285,17 @@ fold_builtin_memchr (location_t loc, tree arg1, tree 
> arg2, tree len, tree type)
>
>   if (r == NULL)
> return build_int_cst (TREE_TYPE (arg1), 0);
> -
> - tem = fold_build_pointer_plus_hwi_loc (loc, arg1, r - p1);
> - return fold_convert_loc (loc, type, tem);
> + else

the else seems superfluous and just adds to indentation.

> +   {
> + size_t offset = r - p1;
> + if (compare_tree_int (len, offset) <= 0)
> +   return build_int_cst (TREE_TYPE (arg1), 0);
> + else
> +   {
> + tem = fold_build_pointer_plus_hwi_loc (loc, arg1, offset);
> + return fold_convert_loc (loc, type, tem);
> +   }
> +   }
> }
>return NULL_TREE;
>  }
> --
> 2.9.2
>
>

Re: protected alloca class for malloc fallback

On Tue, Aug 16, 2016 at 7:54 PM, Martin Sebor  wrote:
> On 08/16/2016 10:47 AM, Jeff Law wrote:
>>
>> On 08/16/2016 10:44 AM, Jakub Jelinek wrote:
>>>
>>> On Tue, Aug 16, 2016 at 10:27:58AM -0600, Jeff Law wrote:

 I think you're being rather short-sighed here.  GCC is being used in
 ways we
 can't necessarily predict -- which might include compile servers,
 JITs, web
 services, etc.
>>>
>>>
>>> For compile server/web services one needs to add the protection
>>> outside of
>>> gcc (sandboxing, containers, SELinux, limiting CPU and/or memory, etc.),
>>> because even with very short testcases e.g. in C/C++ one can eat
>>> arbitrary
>>> amounts of stack even without any uses of alloca in the compiler, simply
>>> through deep recursion in the parsers etc.
>>
>> Agreed.  However, that doesn't mean we should not be locking down things
>> like alloca and other attack vectors.
>
>
> I think I made this suggestion when Aldy posted his first patch
> but it didn't get much traction so let me try again.  Since the
> concern is alloca calls with excessively large arguments, would
> transforming those (determined both at compile time and at run
> time) into pairs of malloc/free calls be an acceptable compromise?
>
> It would seem like a natural complement to the transformation
> in the opposite direction, brought up back then, of turning calls
> to malloc with small (compile-time) arguments into alloca.
>
> I would expect the malloc optimization to more than outweigh
> the performance cost of the alloca to malloc transformation.
> Perhaps even to the point to obviate the need for any explicit
> alloca calls at all.  With the optimization in place, it seems
> that it should even be possible to transparently transform at
> least the most basic uses of some C++ containers written in
> terms of operator new and delete to use alloca instead when
> their sizes were known and under the alloca to malloc threshold.

Please instead work on sth like -fstack-protector for alloca -- it should
be straight-forward to add a runtime test on the stack adjustment
being performed against some magic bound (yeah, needs more than
only GCC support here).

Richard.

> Martin

Re: [PATCH] [GCC] Don't use section anchors for declarations that don't fit in a single anchor range

On Tue, Aug 16, 2016 at 6:06 PM, Jeff Law  wrote:
> On 08/16/2016 08:01 AM, Tamar Christina wrote:
>>
>>
>> Hi All,
>>
>> This patch turns off the usage of section anchors for
>> declarations that do not fit in a single anchor range.
>> A large enough object will use the full anchor range
>> and also force the use of another anchor pointer.
>>
>> By not using an anchor for large objects more globals
>> can share the same anchor.
>>
>> The patch has been benchmarked using Spec2000 and
>> the impact on performance is negligible, however some files
>> using large arrays showed a appreciable reduction in amount of
>> instructions in the assembly file.
>>
>> Regression tests were run on aarch64-none-elf and no regressions.
>>
>> Ok for trunk?
>>
>> 2016-08-16  Tamar Christina  
>> Ramana Radhakrishnan  
>>
>> * gcc/varasm.c
>> (default_use_anchors_for_symbol_p): Reject too large decls.
>
> Do you have to worry about DECL_SIZE being non-constant here or are those
> filtered out earlier?

Globals can't have variable size.

Richard.

> jeff

Re: [PATCH] Add verifier for virtual SSA form

On Mon, 15 Aug 2016, Richard Biener wrote:

> 
> This adds a verifier that makes sure no overlapping life-ranges occur
> for virtuals.
> 
> Bootstrap and regtest running on x86_64-unknown-linux-gnu.

The following is what I ended up applying.  It fixes fallout found
in the vectorizer, general SSA iteration (GIMPLE_TRANSACTION was
mishandled), and CHKP-opt not updating virtual SSA form when moving
stmts.

It also works around an issue in the SSA updater which in case you
had both virtual ops to rename _and_ virtual ops to update via
old/new name mappings could end up creating two virtual PHIs in a block.
The solution is to ignore old/new name mappings when virtuals are
rewritten (disallowing this mode has too much fallout at the moment).
Note this also means that "tricks" like delaying virtual SSA rewrite
until the end of the pass (because nobody cares) but using incremental
SSA update for loop versioning like if conversion does does not work
which means you pay the updating penalty each time you do versioning.

I noticed that MPX tests are not even compiled (nor is the mpx runtime)
on non-MPX capable CPUs.  This means there might be additional fallout
on other targets or other systems I was not able to test -- note that
this is all latent wrong-code (but luckily we're rewriting virtual SSA
form completely at enough points that it may not matter in practice...
*fingers crossing*)

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

Richard.

2016-08-17  Richard Biener  

* tree-ssa.c: Include tree-cfg.h and tree-dfa.h.
(verify_vssa): New function verifying virtual SSA form.
(verify_ssa): Call it.
* tree-ssa-loop-manip.c (slpeel_update_phi_nodes_for_guard2):
Do not apply loop-closed SSA handling to virtuals.
* ssa-iterators.h (op_iter_init): Handle GIMPLE_TRANSACTION.
* tree-into-ssa.c (prepare_use_sites_for): Skip virtual SSA names
when rewriting their symbol.
(prepare_def_site_for): Likewise.
* tree-chkp-opt.c (chkp_reduce_bounds_lifetime): Clear virtual
operands of moved stmts.

Index: gcc/tree-ssa.c
===
--- gcc/tree-ssa.c.orig 2016-08-16 13:21:13.006071948 +0200
+++ gcc/tree-ssa.c  2016-08-16 14:00:15.697408150 +0200
@@ -39,6 +39,8 @@ along with GCC; see the file COPYING3.
 #include "tree-ssa.h"
 #include "cfgloop.h"
 #include "cfgexpand.h"
+#include "tree-cfg.h"
+#include "tree-dfa.h"

 /* Pointer map of variable mappings, keyed by edge.  */
 static hash_map *edge_var_maps;
@@ -603,6 +605,104 @@ release_defs_bitset (bitmap toremove)
   }
 }

+/* Verify virtual SSA form.  */
+
+bool
+verify_vssa (basic_block bb, tree current_vdef, sbitmap visited)
+{
+  bool err = false;
+
+  if (bitmap_bit_p (visited, bb->index))
+return false;
+
+  bitmap_set_bit (visited, bb->index);
+
+  /* Pick up the single virtual PHI def.  */
+  gphi *phi = NULL;
+  for (gphi_iterator si = gsi_start_phis (bb); !gsi_end_p (si);
+   gsi_next ())
+{
+  tree res = gimple_phi_result (si.phi ());
+  if (virtual_operand_p (res))
+   {
+ if (phi)
+   {
+ error ("multiple virtual PHI nodes in BB %d", bb->index);
+ print_gimple_stmt (stderr, phi, 0, 0);
+ print_gimple_stmt (stderr, si.phi (), 0, 0);
+ err = true;
+   }
+ else
+   phi = si.phi ();
+   }
+}
+  if (phi)
+{
+  current_vdef = gimple_phi_result (phi);
+  if (TREE_CODE (current_vdef) != SSA_NAME)
+   {
+ error ("virtual definition is not an SSA name");
+ print_gimple_stmt (stderr, phi, 0, 0);
+ err = true;
+   }
+}
+
+  /* Verify stmts.  */
+  for (gimple_stmt_iterator gsi = gsi_start_bb (bb); !gsi_end_p (gsi);
+   gsi_next ())
+{
+  gimple *stmt = gsi_stmt (gsi);
+  tree vuse = gimple_vuse (stmt);
+  if (vuse)
+   {
+ if (vuse != current_vdef)
+   {
+ error ("stmt with wrong VUSE");
+ print_gimple_stmt (stderr, stmt, 0, TDF_VOPS);
+ fprintf (stderr, "expected ");
+ print_generic_expr (stderr, current_vdef, 0);
+ fprintf (stderr, "\n");
+ err = true;
+   }
+ tree vdef = gimple_vdef (stmt);
+ if (vdef)
+   {
+ current_vdef = vdef;
+ if (TREE_CODE (current_vdef) != SSA_NAME)
+   {
+ error ("virtual definition is not an SSA name");
+ print_gimple_stmt (stderr, phi, 0, 0);
+ err = true;
+   }
+   }
+   }
+}
+
+  /* Verify destination PHI uses and recurse.  */
+  edge_iterator ei;
+  edge e;
+  FOR_EACH_EDGE (e, ei, bb->succs)
+{
+  gphi *phi = get_virtual_phi (e->dest);
+  if (phi
+ && PHI_ARG_DEF_FROM_EDGE (phi, e) != current_vdef)

Re: [PATCH] Fix caret locations in format_type_warning (PR c/72857)

2016-08-17 Thread Andreas Schwab

../../gcc/input.c:1470:1: error: 'const char* 
get_source_range_for_char(cpp_reader*, string_concat_db*, location_t, 
cpp_ttype, int, source_range*)' defined but not used [-Werror=unused-function]
 get_source_range_for_char (cpp_reader *pfile,
 ^

Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: [BUILDROBOT] avr broken

2016-08-17 Thread Jan-Benedict Glaw

On Tue, 2016-08-16 14:26:38 -0400, Nathan Sidwell  wrote:
> On 08/16/16 13:04, Jan-Benedict Glaw wrote:
> 
> > That'll probably work. But after all, I'm not an AVR maintainer
> > (not even an user), but just running the Build Robot.
> 
> Does your robot approve? :)

Ohoooh! See there! :)

http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=602648

The Robot has an answer. I guess that means he's okay with the patch
(of which, unfortunately, both versions didn't make it to the list.)

MfG, JBG

-- 
  Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
Signature of:  The course of history shows that as a government grows, liberty
the second  : decreases."  (Thomas Jefferson)


signature.asc
Description: Digital signature

Re: [PATCH] Fix ICE with FRE devirtualization (PR middle-end/77259)

On Tue, 16 Aug 2016, Jakub Jelinek wrote:

> Hi!
> 
> The FRE devirtualization unlike gimple-fold or other places would transform
> some method call with TREE_ADDRESSABLE lhs into __builtin_unreachable call
> with the same lhs, which is invalid (__builtin_unreachable returns void).
> Also, gimple_call_fntype has not been adjusted in these cases.
> 
> Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
> trunk?  What about 6.x?  Do you prefer it in 6.2, or 6.3?

I think the patch can be simplified to just set fntype - PRE/FRE already
arrange to fixup stmts, including calling fixup_noreturn_call which
removes the lhs if required.

Richard.

> 2016-08-16  Jakub Jelinek  
> 
>   PR middle-end/77259
>   * tree-ssa-pre.c (eliminate_dom_walker::before_dom_children): If
>   turning a call into __builtin_unreachable-like noreturn call, adjust
>   gimple_call_set_fntype and remove lhs if needed.
> 
>   * g++.dg/ipa/devirt-52.C: New test.
> 
> --- gcc/tree-ssa-pre.c.jj 2016-08-12 17:33:46.0 +0200
> +++ gcc/tree-ssa-pre.c2016-08-16 11:24:53.605976981 +0200
> @@ -4543,6 +4543,32 @@ eliminate_dom_walker::before_dom_childre
>  lang_hooks.decl_printable_name (fn, 2));
>   }
> gimple_call_set_fndecl (call_stmt, fn);
> +   /* If changing the call to __builtin_unreachable
> +  or similar noreturn function, adjust gimple_call_fntype
> +  too.  */
> +   if ((gimple_call_flags (call_stmt) & ECF_NORETURN)
> +   && VOID_TYPE_P (TREE_TYPE (TREE_TYPE (fn)))
> +   && TYPE_ARG_TYPES (TREE_TYPE (fn))
> +   && (TREE_VALUE (TYPE_ARG_TYPES (TREE_TYPE (fn)))
> +   == void_type_node))
> + gimple_call_set_fntype (call_stmt, TREE_TYPE (fn));
> +   tree lhs = gimple_call_lhs (call_stmt);
> +   /* If the call becomes noreturn, remove the lhs.  */
> +   if (lhs
> +   && gimple_call_noreturn_p (call_stmt)
> +   && (VOID_TYPE_P (TREE_TYPE (gimple_call_fntype
> + (call_stmt)))
> +   || should_remove_lhs_p (lhs)))
> + {
> +   if (TREE_CODE (lhs) == SSA_NAME)
> + {
> +   tree var = create_tmp_var (TREE_TYPE (lhs));
> +   tree def = get_or_create_ssa_default_def (cfun, var);
> +   gimple *new_stmt = gimple_build_assign (lhs, def);
> +   gsi_insert_before (, new_stmt, GSI_SAME_STMT);
> + }
> +   gimple_call_set_lhs (call_stmt, NULL_TREE);
> + }
> maybe_remove_unused_call_args (cfun, call_stmt);
> gimple_set_modified (stmt, true);
>   }
> --- gcc/testsuite/g++.dg/ipa/devirt-52.C.jj   2016-08-16 11:08:49.943108247 
> +0200
> +++ gcc/testsuite/g++.dg/ipa/devirt-52.C  2016-08-16 11:32:25.295300721 
> +0200
> @@ -0,0 +1,56 @@
> +// PR middle-end/77259
> +// { dg-do compile { target c++11 } }
> +// { dg-options "-O2" }
> +
> +template  class A;
> +template  struct A
> +{
> +  A (A &&);
> +};
> +template 
> +A operator+(S *, const A &);
> +template 
> +void operator+(const A &, S *);
> +struct B
> +{
> +  template  B (V);
> +};
> +template  V foo (B) {}
> +class C;
> +template  struct D
> +{
> +  C *operator->() { return d; }
> +  C *d;
> +};
> +struct C
> +{
> +  virtual A bar ();
> +};
> +struct E
> +{
> +  ~E ();
> +  virtual A bar (const B &) const;
> +};
> +template  struct F : E
> +{
> +};
> +template  struct F : E
> +{
> +  A bar (const B &) const try
> +{
> +  D a = baz ();
> +}
> +  catch (int)
> +{
> +}
> +  D baz () const
> +  {
> +D b = foo(0);
> +"" + b->bar () + "";
> +  }
> +};
> +struct G : F
> +{
> +  G (int);
> +};
> +void test () { G (0); }
> 
>   Jakub
> 
> 

-- 
Richard Biener 
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 
21284 (AG Nuernberg)

Re: [PATCH 3/3] Test folding of strn{case}cmp and memchr

2016-08-17 Thread Martin Liška

v2.

Martin
>From 42ea652d00fec821514d34b2af81f2a9e11b248c Mon Sep 17 00:00:00 2001
From: marxin 
Date: Tue, 16 Aug 2016 15:56:01 +0200
Subject: [PATCH 3/3] Test folding of strn{case}cmp and memchr

gcc/testsuite/ChangeLog:

2016-08-16  Martin Liska  

	* gcc.dg/tree-ssa/builtins-folding.c: New test.
---
 gcc/testsuite/gcc.dg/tree-ssa/builtins-folding.c | 74 
 1 file changed, 74 insertions(+)
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/builtins-folding.c

diff --git a/gcc/testsuite/gcc.dg/tree-ssa/builtins-folding.c b/gcc/testsuite/gcc.dg/tree-ssa/builtins-folding.c
new file mode 100644
index 000..48a86e3
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/builtins-folding.c
@@ -0,0 +1,74 @@
+/* { dg-do run } */
+/* { dg-options "-O2 -fdump-tree-optimized" } */
+
+char *buffer1;
+char *buffer2;
+
+int
+main (void)
+{
+  const char* const foo1 = "hello world";
+
+  buffer1 = __builtin_malloc (1000);
+  __builtin_strcpy (buffer1, foo1);
+  buffer2 = __builtin_malloc (1000);
+  __builtin_strcpy (buffer2, foo1);
+
+  /* MEMCHR.  */
+  if (__builtin_memchr (foo1, 'x', 11))
+__builtin_abort ();
+  if (__builtin_memchr (foo1, 'x', 100))
+__builtin_abort ();
+  if (__builtin_memchr (buffer1, 'x', 0) != 0)
+__builtin_abort ();
+  if (__builtin_memchr (foo1, 'o', 11) != foo1 + 4)
+__builtin_abort ();
+  if (__builtin_memchr (foo1, 'w', 2))
+__builtin_abort ();
+  if (__builtin_memchr (foo1 + 5, 'o', 6) != foo1 + 7)
+__builtin_abort ();
+  if (__builtin_memchr (foo1, 'd', 11) != foo1 + 10)
+__builtin_abort ();
+  if (__builtin_memchr (foo1, 'd', 10))
+__builtin_abort ();
+  if (__builtin_memchr (foo1, '\0', 11))
+__builtin_abort ();
+  if (__builtin_memchr (foo1, '\0', 12) != foo1 + 11)
+__builtin_abort ();
+
+  /* STRNCMP.  */
+  if (__builtin_strncmp ("hello", "a", 0) != 0)
+__builtin_abort ();
+  if (__builtin_strncmp ("a", "a", 100) != 0)
+__builtin_abort ();
+  if (__builtin_strncmp ("a", "", 100) <= 0)
+__builtin_abort ();
+  if (__builtin_strncmp ("", "a", 100) >= 0)
+__builtin_abort ();
+  if (__builtin_strncmp ("ab", "ba", 1) >= 0)
+__builtin_abort ();
+  if (__builtin_strncmp (buffer1, buffer2, 1) != 0)
+__builtin_abort (); /* not folded away */
+
+  /* STRNCASECMP.  */
+  if (__builtin_strncasecmp ("hello", "a", 0) != 0)
+__builtin_abort ();
+  if (__builtin_strncasecmp ("a", "a", 100) != 0)
+__builtin_abort ();
+  if (__builtin_strncasecmp ("a", "", 100) <= 0)
+__builtin_abort ();
+  if (__builtin_strncasecmp ("", "a", 100) >= 0)
+__builtin_abort ();
+  if (__builtin_strncasecmp ("ab", "ba", 1) >= 0) /* not folded away */
+__builtin_abort (); /* not folded away */
+  if (__builtin_strncasecmp (buffer1, buffer2, 1) != 0) /* not folded away */
+__builtin_abort (); /* not folded away */
+  if (__builtin_strncasecmp (buffer1, buffer2, 100) != 0) /* not folded away */
+__builtin_abort (); /* not folded away */
+
+  return 0;
+}
+
+/* { dg-final { scan-tree-dump-not "__builtin_memchr" "optimized" } } */
+/* { dg-final { scan-tree-dump-not "__builtin_strncmp" "optimized" } } */
+/* { dg-final { scan-tree-dump-times "__builtin_strncasecmp" 3 "optimized" } } */
-- 
2.9.2

Re: [PATCH 1/3] Fold BUILT_IN_STRNCASECMP

2016-08-17 Thread Martin Liška

On 08/17/2016 09:10 AM, Jakub Jelinek wrote:
> Did you really mean to use this block for strncasecmp only (rather than for
> strncmp only, i.e. !is_strncasecmp)?

Sure, that was a typo. Unfortunately I had a test case with strings that was
eaten by fold_const_call. I enhanced test coverage for that.

> 
> Also, while you are changing this, I'd replace
>   tree_fits_uhwi_p (len) && tree_to_uhwi (len) == 1
> with integer_onep (len).

Fixed in v2.

Martin

> 
>   Jakub

>From f1c30311d2f9274bd213fa703ad51da8151a1b1b Mon Sep 17 00:00:00 2001
From: marxin 
Date: Tue, 16 Aug 2016 15:10:13 +0200
Subject: [PATCH 1/3] Fold BUILT_IN_STRNCASECMP

gcc/ChangeLog:

2016-08-16  Martin Liska  

	* builtins.c (fold_builtin_strncmp): Rename to
	fold_builtin_strncmp_strncasecmp and support also
	strncasecmp.
	(fold_builtin_3): Handle BUILT_IN_STRNCASECMP.
---
 gcc/builtins.c | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/gcc/builtins.c b/gcc/builtins.c
index 03a0dc8..3926049 100644
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@ -150,7 +150,8 @@ static tree fold_builtin_strchr (location_t, tree, tree, tree);
 static tree fold_builtin_memchr (location_t, tree, tree, tree, tree);
 static tree fold_builtin_memcmp (location_t, tree, tree, tree);
 static tree fold_builtin_strcmp (location_t, tree, tree);
-static tree fold_builtin_strncmp (location_t, tree, tree, tree);
+static tree fold_builtin_strncmp_strncasecmp (location_t, tree, tree, tree,
+	  bool);
 static tree fold_builtin_isascii (location_t, tree);
 static tree fold_builtin_toascii (location_t, tree);
 static tree fold_builtin_isdigit (location_t, tree);
@@ -7383,11 +7384,13 @@ fold_builtin_strcmp (location_t loc, tree arg1, tree arg2)
   return NULL_TREE;
 }
 
-/* Fold function call to builtin strncmp with arguments ARG1, ARG2, and LEN.
-   Return NULL_TREE if no simplification can be made.  */
+/* Fold function call to builtin strncmp (or strncasecmp) with arguments ARG1,
+   ARG2, and LEN.  Return NULL_TREE if no simplification can be made.
+   IS_STRNCASECMP is true for strncasecmp, false otherwise.  */
 
 static tree
-fold_builtin_strncmp (location_t loc, tree arg1, tree arg2, tree len)
+fold_builtin_strncmp_strncasecmp (location_t loc, tree arg1, tree arg2,
+  tree len, bool is_strncasecmp)
 {
   if (!validate_arg (arg1, POINTER_TYPE)
   || !validate_arg (arg2, POINTER_TYPE)
@@ -7442,7 +7445,7 @@ fold_builtin_strncmp (location_t loc, tree arg1, tree arg2, tree len)
 
   /* If len parameter is one, return an expression corresponding to
  (*(const unsigned char*)arg1 - (const unsigned char*)arg2).  */
-  if (tree_fits_uhwi_p (len) && tree_to_uhwi (len) == 1)
+  if (!is_strncasecmp && integer_onep (len))
 {
   tree cst_uchar_node = build_type_variant (unsigned_char_type_node, 1, 0);
   tree cst_uchar_ptr_node
@@ -8483,7 +8486,10 @@ fold_builtin_3 (location_t loc, tree fndecl,
 break;
 
 case BUILT_IN_STRNCMP:
-  return fold_builtin_strncmp (loc, arg0, arg1, arg2);
+  return fold_builtin_strncmp_strncasecmp (loc, arg0, arg1, arg2, false);
+
+case BUILT_IN_STRNCASECMP:
+  return fold_builtin_strncmp_strncasecmp (loc, arg0, arg1, arg2, true);
 
 case BUILT_IN_MEMCHR:
   return fold_builtin_memchr (loc, arg0, arg1, arg2, type);
-- 
2.9.2

Re: [BUILDROBOT] avr broken

2016-08-17 Thread Martin Liška

On 08/17/2016 09:20 AM, Denis Chertykov wrote:
> 2016-08-16 21:26 GMT+03:00 Nathan Sidwell :
>> On 08/16/16 13:04, Jan-Benedict Glaw wrote:
>>
>>> That'll probably work. But after all, I'm not an AVR maintainer (not
>>> even an user), but just running the Build Robot.
>>
>>
>> Does your robot approve? :)
>>
> 
> I'm an AVR maintainer.
> The patch does not have any AVR port modifications.
> I can't approve it.
> 

Based on Nathan's ACK, I've installed the patch as r239522.

Martin

Re: [BUILDROBOT] avr broken

2016-08-17 Thread Denis Chertykov

2016-08-16 21:26 GMT+03:00 Nathan Sidwell :
> On 08/16/16 13:04, Jan-Benedict Glaw wrote:
>
>> That'll probably work. But after all, I'm not an AVR maintainer (not
>> even an user), but just running the Build Robot.
>
>
> Does your robot approve? :)
>

I'm an AVR maintainer.
The patch does not have any AVR port modifications.
I can't approve it.

Re: [PATCH 1/3] Fold BUILT_IN_STRNCASECMP