Re: [PATCH 2/2] C++ FE: handle misspelled identifiers and typenames

[Uros Bizjak]

On Thu, Jul 21, 2016 at 7:23 PM, David Malcolm  wrote:
> On Thu, 2016-07-21 at 10:38 -0400, David Malcolm wrote:
>> On Thu, 2016-07-21 at 10:28 -0400, David Malcolm wrote:
>> > On Thu, 2016-07-21 at 09:00 +0200, Uros Bizjak wrote:
>> > > Hello!
>> > >
>> > > > > gcc/ChangeLog:
>> > > > > PR c/70339
>> > > > > * diagnostic-show-locus.c (diagnostic_show_locus): If this is
>> > > > > the
>> > > > > same location as last time, don't skip if we have fix-it
>> > > > > hints.
>> > > > > Clarify the skipping logic by converting it from one "if"
>> > > > > clause
>> > > > > to repeated "if" clauses.
>> > > > > * spellcheck-tree.c: Include "cpplib.h".
>> > > > > (find_closest_macro_cpp_cb): Move here from c/c-decl.c.
>> > > > > (best_macro_match::best_macro_match): New constructor.
>> > > > > * spellcheck-tree.h (struct edit_distance_traits> > > > > *>):
>> > > > > Move here from c/c-decl.c.
>> > > > > (class best_macro_match): Move here from c/c-decl.c,
>> > > > > converting
>> > > > > from a typedef to a subclass, gaining a ctor.
>> > >
>> > > This part introduced bootstrap failure on CentOS 5.11:
>> > >
>> > > g++ -std=gnu++98 -fno-PIE -c   -g  -DIN_GCC-fno-strict
>> > > -aliasing
>> > > -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall
>> > > -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format
>> > > -attribute
>> > > -Woverloaded-virtual -fno-common  -DHAVE_CONFIG_H -I. -I.
>> > > -I../../git/gcc/gcc -I../../git/gcc/gcc/.
>> > > -I../../git/gcc/gcc/../include
>> > > -I../../git/gcc/gcc/../libcpp/include
>> > > -I/usr/local/include -I/usr/local/include -I/usr/local/include
>> > > -I../../git/gcc/gcc/../libdecnumber
>> > > -I../../git/gcc/gcc/../libdecnumber/bid -I../libdecnumber
>> > > -I../../git/gcc/gcc/../libbacktrace   -o spellcheck-tree.o -MT
>> > > spellcheck-tree.o -MMD -MP -MF ./.deps/spellcheck-tree.TPo
>> > > ../../git/gcc/gcc/spellcheck-tree.c
>> > > ../../git/gcc/gcc/spellcheck-tree.c: In constructor
>> > > ‘best_macro_match::best_macro_match(tree_node*, edit_distance_t,
>> > > cpp_reader*)’:
>> > > ../../git/gcc/gcc/spellcheck-tree.c:94: error: class
>> > > ‘best_macro_match’ does not have any field named ‘best_match’
>> > > ../../git/gcc/gcc/spellcheck-tree.c:94: error: no matching
>> > > function
>> > > for call to ‘best_match::best_match()’
>> > > ../../git/gcc/gcc/spellcheck.h:91: note: candidates are:
>> > > best_match::best_match(GOAL_TYPE,
>> > > edit_distance_t) [with GOAL_TYPE = tree_node*, CANDIDATE_TYPE =
>> > > cpp_hashnode*]
>> > > ../../git/gcc/gcc/spellcheck.h:81: note:
>> > > best_match::best_match(const
>> > > best_match&)
>> > > gmake: *** [spellcheck-tree.o] Error 1
>> > >
>> > > CentOS 5 has pretty old system compiler [gcc version 4.1.2
>> > > 20080704
>> > > (Red Hat 4.1.2-55)], but the build worked until the above patch
>> > > was
>> > > committed. Is it possible to work around this failure somehow?
>> >
>> > Sorry about the breakage.
>> >
>> > I've now built a gcc 4.1 locally, and with that I can reproduce the
>> > issue.  Am investigating...
>>
>> The following patch seems to fix it; successfully compiles that file
>> with my local builds of gcc 7 and gcc 4.1 (and with Fedora system gcc
>> 4.8.3).
>>
>> Does it fix the build for you?
>>
>> Bootstrap®rtesting underway here.
>>
>> gcc/ChangeLog:
>>   * spellcheck-tree.c (best_macro_match::best_macro_match):
>>   Explicitly specify the template arguments when invoking the
>> base
>>   class constructor, to help older C++ compilers.
>>
>> Sorry again about the breakage.
>
> This patch survived bootstrap®rtest, and compiles and runs OK with
> gcc-4.1, so I've committed it to trunk as r238598 (under the "obvious"
> rule).
>
> Please let me know if there are any configurations for which it still
> doesn't work.

Yes, the patch solves bootstrap problem for me.

Thanks!

Uros.

Re: [libstdc++] Add C++17clamp

[Jonathan Wakely]

On 21/07/16 19:38 -0400, NightStrike wrote:

On Thu, Jul 14, 2016 at 7:50 PM, Ed Smith-Rowland <3dw...@verizon.net> wrote:

Here is an implementation of P0025
An algorithm to "clamp" a value between a pair of boundary values.

Testing is almost finished - looks good so far.

OK if testing passes?

I didn't see a feature test in any of the SD-6 papers or P0025.



This is not an efficient implementation.  See here:

https://gcc.gnu.org/ml/gcc-help/2014-10/msg00112.html

Which I derived from this SO answer (which is sadly not the accepted
answer at this time):

http://stackoverflow.com/a/16659263

I suggest using the very efficient method that requires a temporary.


That isn't a valid implementation of std::clamp, since it performs a
copy. The template argument might not even be copyable.

Re: [libstdc++] Add C++17clamp

[Jonathan Wakely]

On 22/07/16 08:51 +0100, Jonathan Wakely wrote:

On 21/07/16 19:38 -0400, NightStrike wrote:

On Thu, Jul 14, 2016 at 7:50 PM, Ed Smith-Rowland <3dw...@verizon.net> wrote:

Here is an implementation of P0025
An algorithm to "clamp" a value between a pair of boundary values.

Testing is almost finished - looks good so far.

OK if testing passes?

I didn't see a feature test in any of the SD-6 papers or P0025.



This is not an efficient implementation.  See here:

https://gcc.gnu.org/ml/gcc-help/2014-10/msg00112.html

Which I derived from this SO answer (which is sadly not the accepted
answer at this time):

http://stackoverflow.com/a/16659263

I suggest using the very efficient method that requires a temporary.


That isn't a valid implementation of std::clamp, since it performs a
copy. The template argument might not even be copyable.



We could possibly dispatch to such an implementation for arithmetic
types, but we wouldn't want to do it for all copyable types. There's
no way you can know whether making that local copy is expensive for an
arbitrary type, and making a copy isn't allowed anyway.

[PATCH] predict.c: merge multi-edges

[Martin Liška]

Hi.

Following patch enhances prediction for basic blocks with >2 successor edges.
Currently, even probability is set and the patch considers unlikely edges, where
even probability is set for the remaining edges.

I run SPEC2006 benchmark, where aforementioned BBs have following predictor 
distribution:
48   loop guard with recursion
127   continue
196   null return
203   loop exit with recursion
284   negative return
455   recursive call
659   extra loop exit
664   noreturn call
956   loop exit
   1088   const return
   2110   loop guard
  10557   early return (on trees)
  40765   call

I would not make much sense to do a more sophisticated predictor merging because
majority of predictors are not so much strong (reliable). Thus considering just
'noreturn call' (unlikely) worth for handling.

Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.

Ready to be installed?
Martin
>From f572b283801d99e251f95b960cbd444968b3a73d Mon Sep 17 00:00:00 2001
From: marxin 
Date: Thu, 21 Jul 2016 16:20:42 +0200
Subject: [PATCH] predict.c: merge multi-edges

gcc/testsuite/ChangeLog:

2016-07-21  Martin Liska  

	* gcc.dg/predict-13.c: New test.

gcc/ChangeLog:

2016-07-21  Martin Liska  

	* predict.c (set_even_probabilities): Handle unlikely edges.
	(combine_predictions_for_bb): Likewise.
---
 gcc/predict.c | 66 +--
 gcc/testsuite/gcc.dg/predict-13.c | 24 ++
 2 files changed, 80 insertions(+), 10 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/predict-13.c

diff --git a/gcc/predict.c b/gcc/predict.c
index 7fbd404..41b87dd 100644
--- a/gcc/predict.c
+++ b/gcc/predict.c
@@ -785,20 +785,33 @@ dump_prediction (FILE *file, enum br_predictor predictor, int probability,
 }
 
 /* We can not predict the probabilities of outgoing edges of bb.  Set them
-   evenly and hope for the best.  */
+   evenly and hope for the best.  If UNLIKELY_EDGES is not null, distribute
+   evel probability for all edges not mentioned in the set.  These edges
+   are given PROB_VERY_UNLIKELY probability.  */
+
 static void
-set_even_probabilities (basic_block bb)
+set_even_probabilities (basic_block bb,
+			hash_set *unlikely_edges = NULL)
 {
   int nedges = 0;
   edge e;
   edge_iterator ei;
 
+  unsigned unlikely_count = unlikely_edges ? unlikely_edges->elements () : 0;
+
   FOR_EACH_EDGE (e, ei, bb->succs)
 if (!(e->flags & (EDGE_EH | EDGE_FAKE)))
   nedges ++;
+
+  unsigned c = nedges - unlikely_count;
   FOR_EACH_EDGE (e, ei, bb->succs)
 if (!(e->flags & (EDGE_EH | EDGE_FAKE)))
-  e->probability = (REG_BR_PROB_BASE + nedges / 2) / nedges;
+  {
+	if (unlikely_edges != NULL && unlikely_edges->contains (e))
+	  e->probability = PROB_VERY_UNLIKELY;
+	else
+	  e->probability = (REG_BR_PROB_BASE + c / 2) / c;
+  }
 else
   e->probability = 0;
 }
@@ -1068,18 +1081,51 @@ combine_predictions_for_bb (basic_block bb, bool dry_run)
 
   /* When there is no successor or only one choice, prediction is easy.
 
- We are lazy for now and predict only basic blocks with two outgoing
- edges.  It is possible to predict generic case too, but we have to
- ignore first match heuristics and do more involved combining.  Implement
- this later.  */
+ When we have a basic block with more than 2 successors, the situation
+ is more complicated as DS theory cannot be used literally.
+ More precisely, let's assume we predicted edge e1 with probability p1,
+ thus: m1({b1}) = p1.  As we're going to combine more than 2 edges, we
+ need to find probability of e.g. m1({b2}), which we don't know.
+ The only approximation is to equally distribute 1-p1 to all edges
+ different from b1.
+
+ According to numbers we've got from SPEC2006 benchark, there's only
+ one interesting reliable predictor (noreturn call), which can be
+ handled with a bit easier approach.  */
   if (nedges != 2)
 {
+  hash_set unlikely_edges (4);
+
+  /* Identify all edges that have a probability close to very unlikely.
+	 Doing the approach for very unlikely doesn't worth for doing as
+	 there's no such probability in SPEC2006 benchmark.  */
+  edge_prediction **preds = bb_predictions->get (bb);
+  if (preds)
+	for (pred = *preds; pred; pred = pred->ep_next)
+	  if (pred->ep_probability <= PROB_VERY_UNLIKELY)
+	unlikely_edges.add (pred->ep_edge);
+
   if (!bb->count && !dry_run)
-	set_even_probabilities (bb);
+	set_even_probabilities (bb, &unlikely_edges);
   clear_bb_predictions (bb);
   if (dump_file)
-	fprintf (dump_file, "%i edges in bb %i predicted to even probabilities\n",
-		 nedges, bb->index);
+	{
+	  fprintf (dump_file, "Predictions for bb %i\n", bb->index);
+	  if (unlikely_edges.elements () == 0)
+	fprintf (dump_file,
+		 "%i edges in bb %i predicted to even probabilities\n",
+		 nedges, bb->index);
+	  else
+	{
+	  fprintf (dump_f

[PATCH] Use correct form of delete in libstdc++.exp

[Jonathan Wakely]

Another testsuite memory bug found by ASan.

* testsuite/lib/libstdc++.exp (check_v3_target_namedlocale): Use
delete[] instead of delete.

Tested x86_64-linux, committed to trunk.

commit 001cfe5d6d3d75575efc5a746adc9b826dd5405b
Author: redi 
Date:   Fri Jul 22 08:33:26 2016 +

Use correct form of delete in libstdc++.exp

* testsuite/lib/libstdc++.exp (check_v3_target_namedlocale): Use
delete[] instead of delete.

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

diff --git a/libstdc++-v3/testsuite/lib/libstdc++.exp 
b/libstdc++-v3/testsuite/lib/libstdc++.exp
index 0f7f6d0..7bf91f3 100644
--- a/libstdc++-v3/testsuite/lib/libstdc++.exp
+++ b/libstdc++-v3/testsuite/lib/libstdc++.exp
@@ -936,13 +936,13 @@ proc check_v3_target_namedlocale { args } {
   puts $f "  try"
   puts $f "  {"
   puts $f "locale((const char*)namedloc);"
-  puts $f "delete namedloc;"
+  puts $f "delete\[\] namedloc;"
   puts $f "return 0;"
   puts $f "  }"
   puts $f "  catch(...)"
   puts $f "  {"
   puts $f "printf(\"locale '%s' not supported\\n\", namedloc);"
-  puts $f "delete namedloc;"
+  puts $f "delete\[\] namedloc;"
   puts $f "return 1;"
   puts $f "  }"
   puts $f "}"

Re: [PATCH] Consider functions with xloc.file == NULL (PR, gcov-profile/69028)

[Martin Liška]

On 07/21/2016 10:56 AM, Richard Biener wrote:
> On Wed, Jul 20, 2016 at 3:34 PM, Martin Liška  wrote:
>> Hi.
>>
>> Following patch addresses ICE which happens when coverage.c computes checksum
>> of a function w/o xloc.file. My patch assumes it's a valid state having a 
>> function
>> w/o xloc.file, which is situation exposed by cilkplus functions.
>>
>> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
>>
>> Ready to be installed?
> 
> Yes.
> 
> I think we should try to do better when assigning a location to new
> function decls,
> that is, avoid UNKNOWN_LOCATION and at least have some file information.
> For cilk-plus functions using the decl location of the original
> function might work.
> 
> That said, a safe-guard against this case is ok, thus the patch is as well.
> 
> Richard.

Thanks for review, I'm testing v2 where I copy SOURCE_LOCATION from the 
current_function_decl.

I'll install the patch after patch testing will pass.

M.

> 
>> Martin

>From 6a456aa0a1f3e7b1e702ecc87642cede92048c0e Mon Sep 17 00:00:00 2001
From: marxin 
Date: Wed, 20 Jul 2016 09:54:12 +0200
Subject: [PATCH] Consider functions with xloc.file == NULL (PR
 gcov-profile/69028)

gcc/testsuite/ChangeLog:

2016-07-20  Martin Liska  

	PR gcov-profile/69028
	PR gcov-profile/62047
	* g++.dg/cilk-plus/pr69028.C: New test.

gcc/c-family/ChangeLog:

2016-07-22  Martin Liska  

	* cilk.c (create_cilk_helper_decl): Set location of a new decl
	to the current_function_decl.

gcc/ChangeLog:

2016-07-20  Martin Liska  

	* coverage.c (coverage_compute_lineno_checksum): Do not
	calculate checksum for fns w/o xloc.file.
	(coverage_compute_profile_id): Likewise.
---
 gcc/c-family/cilk.c  |  5 +++--
 gcc/coverage.c   |  6 --
 gcc/testsuite/g++.dg/cilk-plus/pr69028.C | 13 +
 3 files changed, 20 insertions(+), 4 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cilk-plus/pr69028.C

diff --git a/gcc/c-family/cilk.c b/gcc/c-family/cilk.c
index 8f34cd6..39781c4 100644
--- a/gcc/c-family/cilk.c
+++ b/gcc/c-family/cilk.c
@@ -312,8 +312,9 @@ create_cilk_helper_decl (struct wrapper_data *wd)
 gcc_unreachable (); 
   
   clean_symbol_name (name);
-  tree fndecl = build_decl (UNKNOWN_LOCATION, FUNCTION_DECL, 
-			get_identifier (name), wd->fntype);
+
+  tree fndecl = build_decl (DECL_SOURCE_LOCATION (current_function_decl),
+			FUNCTION_DECL, get_identifier (name), wd->fntype);
 
   TREE_PUBLIC (fndecl) = 0;
   TREE_STATIC (fndecl) = 1;
diff --git a/gcc/coverage.c b/gcc/coverage.c
index 67cc908..d4d371e 100644
--- a/gcc/coverage.c
+++ b/gcc/coverage.c
@@ -553,7 +553,8 @@ coverage_compute_lineno_checksum (void)
 = expand_location (DECL_SOURCE_LOCATION (current_function_decl));
   unsigned chksum = xloc.line;
 
-  chksum = coverage_checksum_string (chksum, xloc.file);
+  if (xloc.file)
+chksum = coverage_checksum_string (chksum, xloc.file);
   chksum = coverage_checksum_string
 (chksum, IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (current_function_decl)));
 
@@ -580,7 +581,8 @@ coverage_compute_profile_id (struct cgraph_node *n)
   bool use_name_only = (PARAM_VALUE (PARAM_PROFILE_FUNC_INTERNAL_ID) == 0);
 
   chksum = (use_name_only ? 0 : xloc.line);
-  chksum = coverage_checksum_string (chksum, xloc.file);
+  if (xloc.file)
+	chksum = coverage_checksum_string (chksum, xloc.file);
   chksum = coverage_checksum_string
 	(chksum, IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (n->decl)));
   if (!use_name_only && first_global_object_name)
diff --git a/gcc/testsuite/g++.dg/cilk-plus/pr69028.C b/gcc/testsuite/g++.dg/cilk-plus/pr69028.C
new file mode 100644
index 000..31542f3
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cilk-plus/pr69028.C
@@ -0,0 +1,13 @@
+// PR c++/69028
+// { dg-require-effective-target c++11 }
+// { dg-options "-fcilkplus -fprofile-arcs" }
+
+void parallel()
+{
+}
+
+int main()
+{
+   _Cilk_spawn parallel();
+   _Cilk_sync;
+}
-- 
2.9.0

Re: [patch,avr] remove secondary_reload hook implementation

[Denis Chertykov]

2016-07-21 18:33 GMT+03:00 Georg-Johann Lay :
> This removes avr's TARGET_SECONDARY_RELOAD implementation which never worked
> as expected...
>
> Its intention was to provide an 8-bit scratch register for loads from
> non-generic address-spaces as they might need to set RAMPZ to the needed
> flash segment.
>
> The avr BE uses avr_find_unused_d_reg for that purpose, and if that function
> does not come up with a d-reg then the using function avr_out_lpm cooks up a
> scratch on the fly.
>
> Ok for trunk?
>
>
> Johann
>
> * config/avr/avr.c (TARGET_SECONDARY_RELOAD): Remove hook define...
> (avr_secondary_reload): ...and implementation.
> (avr_adjust_insn_length) [ADJUST_LEN_LPM]: Remove handling.
> * config/avr/avr.md (reload_in): Remove insns.
> (adjust_len) [lpm]: Remove insn attribute value.
> * config/avr/predicates.md (flash_operand): Remove insn predicate.

Ok.
Approved.

Re: [PATCH GCC/03]New option warning missed optimization on loops whose counter may overflow

[Martin Jambor]

On Thu, Jul 21, 2016 at 04:50:31PM +, Bin Cheng wrote:
> Hi,
> This patch adds new option -Wmissed-loop-optimizations warning on loops whose 
> counter may overflow, as well as makes -Wunsafe-loop-optimizations an alias 
> to the new option.
> Bootstrap and test on x86_64 ongoing.  Is it OK?

I'm repeating myself and since we already have a warning for this it
might make sense to continue having one, but shouldn't we be trying to
move towards the -fopt-info mechanism for optimization feedback?  We
already seem to have OPTGROUP_LOOP even, so could you perhaps consider
also adding a call to

dump_printf_loc (MSG_MISSED_OPTIMIZATION, loc, text)

?

Thanks,

Martin

> 
> Thanks,
> bin
> 
> 2016-07-20  Bin Cheng  
> 
>   * common.opt (Wmissed-loop-optimizations): New option.
>   (Wunsafe-loop-optimizations): Alias to Wmissed-loop-optimizations.
>   * doc/invoke.texi (Wmissed-loop-optimizations): Ditto.
>   (Wunsafe-loop-optimizations): Alias to Wmissed-loop-optimizations.
>   * tree-ssa-loop-niter.c (number_of_iterations_exit): Use option
>   Wmissed-loop-optimizations.

> diff --git a/gcc/common.opt b/gcc/common.opt
> index 8a292ed..3d62657 100644
> --- a/gcc/common.opt
> +++ b/gcc/common.opt
> @@ -625,7 +625,12 @@ Common Var(warn_null_dereference) Warning
>  Warn if dereferencing a NULL pointer may lead to erroneous or undefined 
> behavior.
>  
>  Wunsafe-loop-optimizations
> -Common Var(warn_unsafe_loop_optimizations) Warning
> +Common Alias(Wmissed-loop-optimizations)
> +Warn if the loop cannot be optimized due to nontrivial assumptions.
> +Same as -Wmissed-loop-optimizations.
> +
> +Wmissed-loop-optimizations
> +Common Var(warn_missed_loop_optimizations) Warning
>  Warn if the loop cannot be optimized due to nontrivial assumptions.
>  
>  Wmissing-noreturn
> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> index 3041c18..5a2bb09 100644
> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @@ -302,8 +302,8 @@ Objective-C and Objective-C++ Dialects}.
>  -Wswitch  -Wswitch-bool  -Wswitch-default  -Wswitch-enum @gol
>  -Wswitch-unreachable  -Wsync-nand @gol
>  -Wsystem-headers  -Wtautological-compare  -Wtrampolines  -Wtrigraphs @gol
> --Wtype-limits  -Wundef @gol
> --Wuninitialized  -Wunknown-pragmas  -Wunsafe-loop-optimizations @gol
> +-Wtype-limits  -Wundef -Wuninitialized  -Wunknown-pragmas @gol
> +-Wmissed-loop-optimizations -Wunsafe-loop-optimizations @gol
>  -Wunsuffixed-float-constants  -Wunused  -Wunused-function @gol
>  -Wunused-label  -Wunused-local-typedefs -Wunused-parameter @gol
>  -Wno-unused-result -Wunused-value @gol -Wunused-variable @gol
> @@ -4990,9 +4990,14 @@ If the stack usage is (partly) dynamic and not 
> bounded, it's:
>  @opindex Wunsafe-loop-optimizations
>  @opindex Wno-unsafe-loop-optimizations
>  Warn if the loop cannot be optimized because the compiler cannot
> -assume anything on the bounds of the loop indices.  With
> -@option{-funsafe-loop-optimizations} warn if the compiler makes
> -such assumptions.
> +assume anything on the bounds of the loop indices.  Same as
> +@option{-Wmissed-loop-optimizations}.
> +
> +@item -Wmissed-loop-optimizations
> +@opindex Wmissed-loop-optimizations
> +@opindex Wno-missed-loop-optimizations
> +Warn if the loop cannot be optimized because the compiler cannot
> +assume anything on the bounds of the loop indices.
>  
>  @item -Wno-pedantic-ms-format @r{(MinGW targets only)}
>  @opindex Wno-pedantic-ms-format
> diff --git a/gcc/tree-ssa-loop-niter.c b/gcc/tree-ssa-loop-niter.c
> index 2061eafa..38b5552 100644
> --- a/gcc/tree-ssa-loop-niter.c
> +++ b/gcc/tree-ssa-loop-niter.c
> @@ -2333,7 +2333,7 @@ number_of_iterations_exit (struct loop *loop, edge exit,
>  
>wording = N_("missed loop optimization, the loop counter may 
> overflow");
>warning_at ((LOCATION_LINE (loc) > 0) ? loc : input_location,
> -   OPT_Wunsafe_loop_optimizations, "%s", gettext (wording));
> +   OPT_Wmissed_loop_optimizations, "%s", gettext (wording));
>  }
>  
>return false;

Re: [PATCH GCC/03]New option warning missed optimization on loops whose counter may overflow

[Bin.Cheng]

On Fri, Jul 22, 2016 at 9:48 AM, Martin Jambor  wrote:
> On Thu, Jul 21, 2016 at 04:50:31PM +, Bin Cheng wrote:
>> Hi,
>> This patch adds new option -Wmissed-loop-optimizations warning on loops 
>> whose counter may overflow, as well as makes -Wunsafe-loop-optimizations an 
>> alias to the new option.
>> Bootstrap and test on x86_64 ongoing.  Is it OK?
>
> I'm repeating myself and since we already have a warning for this it
> might make sense to continue having one, but shouldn't we be trying to
> move towards the -fopt-info mechanism for optimization feedback?  We
> already seem to have OPTGROUP_LOOP even, so could you perhaps consider
> also adding a call to
>
> dump_printf_loc (MSG_MISSED_OPTIMIZATION, loc, text)
>
> ?
Hmm, in this way I will see if I can change this single patch and add
warning message in opt-info category.

Thanks,
bin
>
> Thanks,
>
> Martin
>

Re: [RFC, v2] Test coverage for --param boundary values

[Martin Liška]

On 07/21/2016 08:53 PM, Jeff Law wrote:
> On 07/18/2016 01:53 AM, Martin Liška wrote:
>> You are right, I was inspired by what we do for GCC plugins in:
>> gcc/testsuite/lib/plugin-support.exp
>>
>> where we have following comment:
>> # Note that the plugin test support currently only works when the GCC
>> # build tree is available. (We make sure that is the case in plugin.exp.)
>> # Once we have figured out how/where to package/install GCC header files
>> # for general plugin support, we should modify the following include 
>> paths
>> # accordingly.
>>
>> Well, I can imaging a guard which will test whether 
>> "$objdir/../../params.options" file exits,
>> and if so, then the tests are executed? Is it acceptable approach?
> Yes.  That's acceptable to me.
> 
>>
>>> >
 >> +set text [read $fd]
 >> +close $fd
 >> +
 >> +# Main loop.
 >> +foreach params [split $text "\n"] {
 >> +set parts [split $params "="]
 >> +set name [string trim [lindex $parts 0] '"']
 >> +set values [split [lindex $parts 1] ","]
 >> +if { [llength $values] == 3 } {
 >> +set default [lindex $values 0]
 >> +set min [lindex $values 1]
 >> +set max [lindex $values 2]
 >> +set int_max "INT_MAX"
 >> +
 >> +if { $min != -1 } {
 >> +param_run_test $name $min
 >> +}
 >> +if { $max != $min && $max > 0 && $max != $int_max } {
 >> +param_run_test $name $max
 >> +}
 >> +}
 >> +if { [llength $values] == 5 } {
 >> +foreach v $values {
 >> +param_run_test $name $v
 >> +}
 >> +}
 >> +}
>>> >
>>> > This produces ambiguous test result lines:
>>> >
>>> > Running 
>>> > /scratch/tschwing/nvidiak20-2/gcc/trunk-light/source-gcc/gcc/testsuite/gcc.dg/params/params.exp
>>> >  ...
>>> > PASS: gcc.dg/params/blocksort-part.c (test for excess errors)
>>> > PASS: gcc.dg/params/blocksort-part.c (test for excess errors)
>>> > PASS: gcc.dg/params/blocksort-part.c (test for excess errors)
>>> > PASS: gcc.dg/params/blocksort-part.c (test for excess errors)
>>> > [many more]
>>> >
>>> > OK to fix this as follows:
>>> >
>>> > PASS: gcc.dg/params/blocksort-part.c -O3 --param 
>>> > predictable-branch-outcome=0 (test for excess errors)
>>> > PASS: gcc.dg/params/blocksort-part.c -O3 --param 
>>> > predictable-branch-outcome=50 (test for excess errors)
>>> > PASS: gcc.dg/params/blocksort-part.c -O3 --param inline-min-speedup=0 
>>> > (test for excess errors)
>>> > PASS: gcc.dg/params/blocksort-part.c -O3 --param 
>>> > max-inline-insns-single=0 (test for excess errors)
>>> > [...]
>>> >
>>> > commit ae350ce9af062d7d2c05225280596b1bc982728b
>>> > Author: Thomas Schwinge 
>>> > Date:   Fri Jul 15 09:13:19 2016 +0200
>>> >
>>> > Disambiguate gcc.dg/params/params.exp test results
>>> >
>>> > gcc/testsuite/
>>> > * gcc.dg/params/params.exp (param_run_test): Swap flags and
>>> > default-extra-flags arguments when calling dg-runtest.
>>> > ---
>>> >  gcc/testsuite/gcc.dg/params/params.exp |2 +-
>>> >  1 file changed, 1 insertion(+), 1 deletion(-)
>>> >
>>> > diff --git gcc/testsuite/gcc.dg/params/params.exp 
>>> > gcc/testsuite/gcc.dg/params/params.exp
>>> > index f2f397e..dd82a5d 100644
>>> > --- gcc/testsuite/gcc.dg/params/params.exp
>>> > +++ gcc/testsuite/gcc.dg/params/params.exp
>>> > @@ -28,7 +28,7 @@ proc param_run_test { param_name param_value } {
>>> >  global srcdir
>>> >  global subdir
>>> >
>>> > -dg-runtest $srcdir/$subdir/blocksort-part.c "" "-O3 --param 
>>> > $param_name=$param_value"
>>> > +dg-runtest $srcdir/$subdir/blocksort-part.c "-O3 --param 
>>> > $param_name=$param_value" ""
>>> >  }
>>> >
>>> >  set fd [open "$objdir/../../params.options" r]
>>> >
>>> >
>>> > Grüße
>>> >  Thomas
>>> >
>> Thanks for the patch, that's probably the same problem that Andreas spotted.
>> I'm sending candidate patch.
>>
>> Martin
>>
>>
>> 0001-Fix-params.exp-test-cases.patch
>>
>>
>> From d5e3c5cb20306352af7f45cd827669b7ff51a709 Mon Sep 17 00:00:00 2001
>> From: marxin 
>> Date: Mon, 18 Jul 2016 09:50:12 +0200
>> Subject: [PATCH] Fix params.exp test-cases
>>
>> gcc/testsuite/ChangeLog:
>>
>> 2016-07-18  Thomas Schwinge  
>> Martin Liska  
>>
>> * gcc.dg/params/LICENSE: Add missing LICENSE that is mentioned
>> in a source file.
>> * gcc.dg/params/README: Same for the README.
>> * gcc.dg/params/params.exp (param_run_test): Swap flags and
>> default-extra-flags arguments when calling dg-runtest.
> OK.
> 
> jeff
> 

Thanks.

I'm sending the version of patch I've just installed as r238633.

Martin
>From 920fce946873a1ec6a5a1755adc4a78fe4409f8e Mon Sep 17 00:00:00 2001
From: marxin 
Date: Mon, 18 Jul 2016 09:50:12 +0200
Subject: [PATCH] Fix params.exp test-cases

2016-07-18  Thomas Schwinge  
	Martin Liska  

	* gcc.dg/params/LICENSE: Add missing LICENSE that

Re: [Fortran, patch, committed] Help with STAT= attribute in coarray reference

[Andre Vehreschild]

Hi all,

committed the cosmetics patch as r238635.

Regards,
Andre

On Thu, 21 Jul 2016 14:57:32 +0200
Andre Vehreschild  wrote:

> Hi all,
> 
> the attached patch fixes some style issues in the caf code recently
> modified. Furthermore does it correct the function specifications of 
> caf_get() and caf_send() that where missing some specifiers.
> 
> Bootstrapped and regtested ok on x86_64-linux/F23. If noone objects I
> commit this patch as obvious tomorrow.
> 
> In my pipeline is a patch that will add stat= support to the libcaf
> interface and caf_single.
> 
> Regards,
>   Andre
> 
> On Tue, 5 Jul 2016 09:33:49 -0600
> Alessandro Fanfarillo  wrote:
> 
> > Thanks, committed as rev. 238007.
> > 
> > 2016-07-04 14:41 GMT-06:00 Mikael Morin :  
> > > Le 30/06/2016 06:05, Alessandro Fanfarillo a écrit :
> > >>
> > >> Dear Mikael,
> > >>
> > >> thanks for your review and for the test. The attached patch,
> > >> built and regtested for x86_64-pc-linux-gnu, addresses all the
> > >> suggestions.
> > >>
> > >> The next patch will change the documentation related to the
> > >> caf_get and caf_send functions and will add support for STAT= to
> > >> the sendget function.
> > >>
> > >> In the meantime, is this patch OK for trunk?
> > >>
> > > Yes, thanks.
> > >
> > > Mikael
> > >
> > >
> 
> 


-- 
Andre Vehreschild * Email: vehre ad gmx dot de 
Index: gcc/fortran/ChangeLog
===
--- gcc/fortran/ChangeLog	(Revision 238631)
+++ gcc/fortran/ChangeLog	(Arbeitskopie)
@@ -1,3 +1,13 @@
+2016-07-22  Andre Vehreschild  
+
+	* expr.c (gfc_find_stat_co): Fixed whitespaces.
+	* gfortran.texi: Fixed typos and reversed meaning of caf_get()'s
+	src and dst description.
+	* trans-decl.c (gfc_build_builtin_function_decls): Fixed style
+	and corrected fnspec for caf functions.
+	* trans-intrinsic.c (gfc_conv_intrinsic_caf_get): Fixed style.
+	(conv_caf_send): Dito.
+
 2016-07-19  Thomas Koenig  
 
 	PR fortran/71902
Index: gcc/fortran/expr.c
===
--- gcc/fortran/expr.c	(Revision 238631)
+++ gcc/fortran/expr.c	(Arbeitskopie)
@@ -4437,9 +4437,9 @@
 if (ref->type == REF_ARRAY && ref->u.ar.codimen > 0)
   return ref->u.ar.stat;
 
-  if(e->value.function.actual->expr)
-for(ref = e->value.function.actual->expr->ref; ref;
-	ref = ref->next)
+  if (e->value.function.actual->expr)
+for (ref = e->value.function.actual->expr->ref; ref;
+	 ref = ref->next)
   if (ref->type == REF_ARRAY && ref->u.ar.codimen > 0)
 	return ref->u.ar.stat;
 
Index: gcc/fortran/gfortran.texi
===
--- gcc/fortran/gfortran.texi	(Revision 238631)
+++ gcc/fortran/gfortran.texi	(Arbeitskopie)
@@ -3799,7 +3799,7 @@
 number.
 @item @var{dest} @tab intent(in) Array descriptor for the remote image for the
 bounds and the size. The base_addr shall not be accessed.
-@item @var{dst_vector} @tab intent(int)  If not NULL, it contains the vector
+@item @var{dst_vector} @tab intent(in)  If not NULL, it contains the vector
 subscript of the destination array; the values are relative to the dimension
 triplet of the dest argument.
 @item @var{src} @tab intent(in) Array descriptor of the local array to be
@@ -3839,7 +3839,7 @@
 image identified by the image_index.
 
 @item @emph{Syntax}:
-@code{void _gfortran_caf_get_desc (caf_token_t token, size_t offset,
+@code{void _gfortran_caf_get (caf_token_t token, size_t offset,
 int image_index, gfc_descriptor_t *src, caf_vector_t *src_vector,
 gfc_descriptor_t *dest, int src_kind, int dst_kind, bool may_require_tmp)}
 
@@ -3850,13 +3850,13 @@
 compared to the base address of the coarray.
 @item @var{image_index} @tab The ID of the remote image; must be a positive
 number.
-@item @var{dest} @tab intent(in) Array descriptor of the local array to be
-transferred to the remote image
+@item @var{dest} @tab intent(out) Array descriptor of the local array to store
+the data transferred from the remote image
 @item @var{src} @tab intent(in) Array descriptor for the remote image for the
 bounds and the size. The base_addr shall not be accessed.
-@item @var{src_vector} @tab intent(int)  If not NULL, it contains the vector
-subscript of the destination array; the values are relative to the dimension
-triplet of the dest argument.
+@item @var{src_vector} @tab intent(in)  If not NULL, it contains the vector
+subscript of the source array; the values are relative to the dimension
+triplet of the src argument.
 @item @var{dst_kind} @tab Kind of the destination argument
 @item @var{src_kind} @tab Kind of the source argument
 @item @var{may_require_tmp} @tab The variable is false it is known at compile
Index: gcc/fortran/trans-decl.c
===
--- gcc/fortran/trans-decl.c	(Revision 238631)
+++ gcc/fortran/trans-decl.c	(Arbeitskopie)
@@ -3538,38 +3538,38 @@
 	= build_pointer_t

Re: [Fortran, patch, v1] Add STAT= support to caf_single get()/send()

[Andre Vehreschild]

Hi Paul, hi all,

thanks for the fast review. Committed as r238636.

Thanks again and regards,
Andre

On Thu, 21 Jul 2016 17:44:06 +0200
Paul Richard Thomas  wrote:

> Hi Andre,
> 
> That looks good to me. OK for trunk.
> 
> Thanks for the patch.
> 
> Paul
> 
> On 21 July 2016 at 15:31, Andre Vehreschild  wrote:
> > Hi all,
> >
> > the attached patch adds support for a stat parameter to caf_single's
> > caf_get() and caf_send() routines and adds a testcase.
> > Unfortunately is there not much that can go wrong in a caf_single's
> > get/send, so the test resides to check whether stat is reset
> > correctly.
> >
> > Bootstraps and regtests ok on x86_64-linux/F23.
> >
> > Ok for trunk?
> >
> > Regards,
> > Andre
> > --
> > Andre Vehreschild * Email: vehre ad gmx dot de  
> 
> 
> 


-- 
Andre Vehreschild * Email: vehre ad gmx dot de 
Index: gcc/testsuite/ChangeLog
===
--- gcc/testsuite/ChangeLog	(Revision 238634)
+++ gcc/testsuite/ChangeLog	(Arbeitskopie)
@@ -1,3 +1,7 @@
+2016-07-22  Andre Vehreschild  
+
+	* gfortran.dg/coarray_stat_2.f90: New test.
+
 2016-07-21  Michael Meissner  
 
 	* gcc.target/powerpc/vec-extract.h: New files to check the
Index: gcc/testsuite/gfortran.dg/coarray_stat_2.f90
===
--- gcc/testsuite/gfortran.dg/coarray_stat_2.f90	(nicht existent)
+++ gcc/testsuite/gfortran.dg/coarray_stat_2.f90	(Arbeitskopie)
@@ -0,0 +1,23 @@
+! { dg-do run }
+! { dg-options "-fcoarray=lib -lcaf_single" }
+!
+! Support for stat= in caf reference
+!
+program whitespace
+  implicit none
+
+  integer :: me[*],tmp,stat
+
+  me = this_image()
+  stat = 0
+
+  sync all(stat = stat)
+
+  if(stat /= 0) write(*,*) 'failure during sync'
+
+  stat = 42
+
+  tmp = me[num_images(),stat = stat]
+  if(stat /= 0) call abort()
+
+end program whitespace
Index: libgfortran/ChangeLog
===
--- libgfortran/ChangeLog	(Revision 238634)
+++ libgfortran/ChangeLog	(Arbeitskopie)
@@ -1,3 +1,13 @@
+2016-07-22  Andre Vehreschild  
+
+	* caf/libcaf.h: Add parameter stat to caf_get() and
+	caf_send()'s function prototypes.
+	* caf/single.c (_gfortran_caf_get): Implement reporting
+	error using stat instead of abort().
+	(_gfortran_caf_send): Same.
+	(_gfortran_caf_sendget): Use NULL for stat when calling
+	caf_send().
+
 2016-06-23  Jerry DeLisle  
 
 	PR libgfortran/48852
Index: libgfortran/caf/libcaf.h
===
--- libgfortran/caf/libcaf.h	(Revision 238634)
+++ libgfortran/caf/libcaf.h	(Arbeitskopie)
@@ -121,9 +121,11 @@
 			  int, int, int *, char *, int, int);
 
 void _gfortran_caf_get (caf_token_t, size_t, int, gfc_descriptor_t *,
-caf_vector_t *, gfc_descriptor_t *, int, int, bool);
+			caf_vector_t *, gfc_descriptor_t *, int, int, bool,
+			int *);
 void _gfortran_caf_send (caf_token_t, size_t, int, gfc_descriptor_t *,
-			 caf_vector_t *, gfc_descriptor_t *, int, int, bool);
+			 caf_vector_t *, gfc_descriptor_t *, int, int, bool,
+			 int *);
 void _gfortran_caf_sendget (caf_token_t, size_t, int, gfc_descriptor_t *,
 			caf_vector_t *, caf_token_t, size_t, int,
 			gfc_descriptor_t *, caf_vector_t *, int, int, bool);
Index: libgfortran/caf/single.c
===
--- libgfortran/caf/single.c	(Revision 238634)
+++ libgfortran/caf/single.c	(Arbeitskopie)
@@ -328,7 +328,7 @@
 
 static void
 convert_type (void *dst, int dst_type, int dst_kind, void *src, int src_type,
-	  int src_kind)
+	  int src_kind, int *stat)
 {
 #ifdef HAVE_GFC_INTEGER_16
   typedef __int128 int128t;
@@ -581,7 +581,10 @@
 error:
   fprintf (stderr, "libcaf_single RUNTIME ERROR: Cannot convert type %d kind "
 	   "%d to type %d kind %d\n", src_type, src_kind, dst_type, dst_kind);
-  abort();
+  if (stat)
+*stat = 1;
+  else
+abort ();
 }
 
 
@@ -591,7 +594,7 @@
 		   gfc_descriptor_t *src,
 		   caf_vector_t *src_vector __attribute__ ((unused)),
 		   gfc_descriptor_t *dest, int src_kind, int dst_kind,
-		   bool may_require_tmp)
+		   bool may_require_tmp, int *stat)
 {
   /* FIXME: Handle vector subscripts.  */
   size_t i, k, size;
@@ -600,6 +603,9 @@
   size_t src_size = GFC_DESCRIPTOR_SIZE (src);
   size_t dst_size = GFC_DESCRIPTOR_SIZE (dest);
 
+  if (stat)
+*stat = 0;
+
   if (rank == 0)
 {
   void *sr = (void *) ((char *) TOKEN (token) + offset);
@@ -626,7 +632,7 @@
  sr);
   else
 	convert_type (GFC_DESCRIPTOR_DATA (dest), GFC_DESCRIPTOR_TYPE (dest),
-		  dst_kind, sr, GFC_DESCRIPTOR_TYPE (src), src_kind);
+		  dst_kind, sr, GFC_DESCRIPTOR_TYPE (src), src_kind, stat);
   return;
 }
 
@@ -710,7 +716,7 @@
 	assign_char4_from_char1 (dst_size, src_size, dst, sr);
 	  else
 	convert_type (dst, GFC_DESCRIPTOR_TYPE (dest), dst_kind,
-			  sr, GFC_DESCRI

[Patch, fortran, committed] Fix PR 71795

[Thomas Koenig]

Hello world,

I have committed the attached patch as obvious and simple
after regression-testing. This fixes a regression.

Will commit to the other affected branches shortly.

Regards

Thomas

2016-07-22  Thomas Koenig  

PR fortran/71795
* frontend-passes.c (combine_array_constructor):  Don't
do anything if the expression is inside an array iterator.

2016-07-22  Thomas Koenig  

PR fortran/71795
* gfortran.dg/constructor_50.f90:  New test.

Index: frontend-passes.c
===
--- frontend-passes.c	(Revision 238497)
+++ frontend-passes.c	(Arbeitskopie)
@@ -1255,6 +1255,11 @@ combine_array_constructor (gfc_expr *e)
   if (forall_level > 0)
 return false;
 
+  /* Inside an iterator, things can get hairy; we are likely to create
+ an invalid temporary variable.  */
+  if (iterator_level > 0)
+return false;
+
   op1 = e->value.op.op1;
   op2 = e->value.op.op2;
 
! { dg-do run }
! PR 71795 - wrong result when putting an array constructor
! instide an iterator.
 program test

 implicit none
 integer :: i,n
 logical, dimension(1) :: ra
 logical :: rs
 integer, allocatable :: a(:)

 allocate ( a(1) )

 n = 1
 a = 2

 ra = (/ (any(a(i).eq.(/1,2,3/)) ,i=1,n) /)
 if (.not. all(ra)) call abort
 rs = any ( (/ (any(a(i).eq.(/1,2,3/)) ,i=1,n) /) )
 if (.not. rs) call abort
   end program test

Implement -Wimplicit-fallthrough: core

[Marek Polacek]

Since my last attempt to attack this beast wasn't exactly successful,
I'm offering a better version.  For the general introduction regarding
what and why, kindly see
.

What has changed:
* I renamed the option to -Wimplicit-fallthrough.  While I don't like this
  name that much, it's what clang uses, so let's follow their naming.
* we now take various /* fall thru */ comments into account.  This has
  significantly reduced the verbosity of the warning.
* several people raised concerns about __builtin_fallthrough.  I changed
  my mind and instead of that builtin I implemented
  __attribute__((fallthrough)), and for C++ also [[fallthrough]] (for 
Jakub Jelinek  

PR c/7652
gcc/
* common.opt (Wimplicit-fallthrough): New option.
* doc/extend.texi: Document statement attributes and the fallthrough
attribute.
* doc/invoke.texi: Document -Wimplicit-fallthrough.
* gimple.h (gimple_call_internal_p): New function.
* gimplify.c (struct gimplify_ctx): Add in_switch_expr.
(struct label_entry): New struct.
(find_label_entry): New function.
(last_stmt_in_scope): New function.
(warn_implicit_fallthrough_r): New function.
(maybe_warn_implicit_fallthrough): New function.
(expand_FALLTHROUGH_r): New function.
(expand_FALLTHROUGH): New function.
(gimplify_switch_expr): Call maybe_warn_implicit_fallthrough and
expand_FALLTHROUGH for the innermost GIMPLE_SWITCH.
(gimplify_label_expr): New function.
(gimplify_case_label_expr): Set location.
(gimplify_expr): Call gimplify_label_expr.
* internal-fn.c (expand_FALLTHROUGH): New function.
* internal-fn.def (FALLTHROUGH): New internal function.
* system.h (gcc_fallthrough): Define.
* tree-core.h: Add FALLTHROUGH_LABEL_P comment.
* tree.h (FALLTHROUGH_LABEL_P): Define.
gcc/c-family/
* c-common.c (c_common_attribute_table): Add fallthrough attribute.
(handle_fallthrough_attribute): New function.
* c-lex.c (c_lex_with_flags): Change parameter to unsigned char.
* c-pragma.h (c_lex_with_flags): Update declaration.
gcc/c/
* c-parser.c (struct c_token): Add flags field.
(c_lex_one_token): Pass it to c_lex_with_flags.
(c_parser_declaration_or_fndef): Turn __attribute__((fallthrough));
into IFN_FALLTHROUGH.
(c_parser_label): Set FALLTHROUGH_LABEL_P on labels.
(c_parser_statement_after_labels): Handle RID_ATTRIBUTE.
gcc/cp/
* constexpr.c (cxx_eval_internal_function): Handle IFN_FALLTHROUGH.
(potential_constant_expression_1): Likewise.
* parser.c (cp_parser_primary_expression): Handle RID_ATTRIBUTE.
(cp_parser_statement): Handle fallthrough attribute.
(cp_parser_label_for_labeled_statement): Set FALLTHROUGH_LABEL_P on
labels.
(cp_parser_std_attribute): Handle fallthrough attribute.
(cp_parser_check_std_attribute): Detect duplicated fallthrough
attribute.
* parser.h (struct cp_token): Change the type of flags to unsigned
short.
gcc/testsuite/
* c-c++-common/Wimplicit-fallthrough-1.c: New test.
* c-c++-common/Wimplicit-fallthrough-10.c: New test.
* c-c++-common/Wimplicit-fallthrough-11.c: New test.
* c-c++-common/Wimplicit-fallthrough-12.c: New test.
* c-c++-common/Wimplicit-fallthrough-13.c: New test.
* c-c++-common/Wimplicit-fallthrough-14.c: New test.
* c-c++-common/Wimplicit-fallthrough-15.c: New test.
* c-c++-common/Wimplicit-fallthrough-16.c: New test.
* c-c++-common/Wimplicit-fallthrough-2.c: New test.
* c-c++-common/Wimplicit-fallthrough-3.c: New test.
* c-c++-common/Wimplicit-fallthrough-4.c: New test.
* c-c++-common/Wimplicit-fallthrough-5.c: New test.
* c-c++-common/Wimplicit-fallthrough-6.c: New test.
* c-c++-common/Wimplicit-fallthrough-7.c: New test.
* c-c++-common/Wimplicit-fallthrough-8.c: New test.
* c-c++-common/Wimplicit-fallthrough-9.c: New test.
* c-c++-common/attr-fallthrough-1.c: New test.
* c-c++-common/attr-fallthrough-2.c: New test.
* g++.dg/cpp0x/fallthrough1.C: New test.
* g++.dg/cpp0x/fallthrough2.C: New test.
* g++.dg/cpp1z/fallthrough1.C: New test.
libcpp/
* include/cpplib.h (PREV_FALLTHROUGH): Define.
* internal.h (CPP_FALLTHRU): Define.
* lex.c (fallthrough_comment_p): New function.
(_cpp_lex_direct): Set PREV_FALLTHROUGH on tokens succeeding a falls
through comment.

diff --git gcc/gcc/c-family/c-common.c gcc/gcc/c-family/c-common.c
index 9900e93..11adabb 100644
--- gcc/gcc/c-family/c-common.c
+++ gcc/gcc/c-family/c-common.c
@@ -392,6 +392,7 @@ static tree handle_designated_init_attribute (tree *, tree, 
tree, int, bool *);
 static tree h

Implement -Wimplicit-fallthrough: the rest

[Marek Polacek]

...and the boring part.  It found a few bugs, e.g. in jcf-dump.c
and rs6000.c - I fixed those.

I think generally it's better to use the attribute rather than a falls
through comment, because the latter can't be followed by other comment
or a macro to work.

This patch has been tested on powerpc64le-unknown-linux-gnu, aarch64-linux-gnu,
and x86_64-redhat-linux.

2016-07-22  Marek Polacek  

PR c/7652
gcc/
* Makefile.in (insn-attrtab.o-warn, insn-dfatab.o-warn,
insn-latencytab.o-warn, insn-output.o-warn, insn-emit.o-warn): Add
-Wno-switch-fallthrough.
* alias.c (find_base_value): Adjust falls through comment.
* builtins.c (expand_builtin_int_roundingfn_2): Add gcc_fallthrough.
(expand_builtin): Likewise.
* cfgexpand.c (expand_debug_expr): Adjust falls through comment.
* combine.c (find_split_point): Likewise.
(expand_compound_operation): Likewise.  Add gcc_fallthrough.
(make_compound_operation): Adjust falls through comment.
(canon_reg_for_combine): Add gcc_fallthrough.
(force_to_mode): Adjust falls through comment.  Add gcc_fallthrough.
(simplify_shift_const_1): Adjust falls through comment.
(simplify_comparison): Likewise.
* config/aarch64/aarch64-builtins.c (aarch64_simd_expand_args): Add
gcc_fallthrough.
* config/aarch64/predicates.md: Likewise.
* config/i386/i386.c (ix86_gimplify_va_arg): Add gcc_fallthrough.
(ix86_legitimate_constant_p): Likewise.
(print_reg): Likewise.
(ix86_print_operand): Likewise.
(ix86_build_const_vector): Likewise.
(ix86_expand_branch): Likewise.
(ix86_sched_init_global): Adjust falls through comment.
(ix86_expand_multi_arg_builtin): Add gcc_fallthrough.
(ix86_expand_args_builtin): Add break.
(ix86_expand_round_builtin): Likewise.
(ix86_expand_builtin): Add gcc_fallthrough.
(ix86_expand_vector_init_one_var): Likewise.
* config/rs6000/rs6000.c (rs6000_builtin_vectorized_libmass): Likewise.
(altivec_expand_ld_builtin): Add break.
(altivec_expand_st_builtin): Likewise.
(rs6000_emit_vector_compare_inner): Add gcc_fallthrough.
(rs6000_adjust_cost): Likewise.
(insn_must_be_first_in_group): Likewise.
(rs6000_handle_altivec_attribute): Likewise.
* config/rs6000/rs6000.md: Likewise.  Adjust falls through comment.
* convert.c (convert_to_real_1): Add gcc_fallthrough.
(convert_to_integer_1): Likewise.
* cselib.c (cselib_expand_value_rtx_1): Add gcc_fallthrough.
* dbxout.c (dbxout_symbol): Adjust falls through comment.
* gcc/df-scan.c (df_uses_record): Likewise.
* dojump.c (do_jump): Add gcc_fallthrough.
* dwarf2out.c (mem_loc_descriptor): Likewise.  Adjust falls through
comment.
(resolve_args_picking_1): Likewise.
(loc_list_from_tree_1): Likewise.
(gen_formal_parameter_die): Likewise.
* expmed.c (expand_divmod): Add gcc_fallthrough.
(make_tree): Adjust falls through comment.
* expr.c (expand_expr_real_2): Add gcc_fallthrough.
(expand_expr_real_1): Likewise.  Adjust falls through comment.
* final.c (output_alternate_entry_point): Add gcc_fallthrough.
* fold-const.c (const_binop): Adjust falls through comment.
(fold_truth_not_expr): Likewise.
(make_range_step): Add gcc_fallthrough.
(fold_cond_expr_with_comparison): Likewise.
(fold_binary_loc): Likewise.
(contains_label_1): Adjust falls through comment.
(multiple_of_p): Likewise.
* gcc.c (driver_handle_option): Add gcc_fallthrough.
* gcov-tool.c (process_args): Likewise.
* genattrtab.c (check_attr_test): Likewise.
(make_canonical): Likewise.
(write_test_expr): Likewise.
* genconfig.c (walk_insn_part): Likewise.
* gengtype.c (dbgprint_count_type_at): Add break.
* genpreds.c (validate_exp): Adjust falls through comment.  Add
gcc_fallthrough.
(needs_variable): Adjust falls through comment.
* gensupport.c (get_alternatives_number): Add gcc_fallthrough.
(subst_dup): Likewise.
* gimple-pretty-print.c (dump_gimple_assign): Likewise.
* gimple-ssa-strength-reduction.c
(find_candidates_dom_walker::before_dom_children): Likewise.
* gimplify.c (gimplify_addr_expr): Adjust falls through comment.
(omp_default_clause): Add gcc_fallthrough.
(gimplify_scan_omp_clauses): Likewise.
(goa_stabilize_expr): Likewise.
* godump.c (go_format_type): Add gcc_fallthrough.
* graphite-isl-ast-to-gimple.c (substitute_ssa_name): Adjust falls
through comment.
* hsa-gen.c (get_address_from_value): Likewise.
(gen_hsa_insn_for_internal_fn_call): Add gcc_fallthrough.
* ipa-icf.c (sem_function::hash_stmt):

Re: [PATCH] predict.c: merge multi-edges

[Segher Boessenkool]

Hi Martin,

On Fri, Jul 22, 2016 at 10:17:51AM +0200, Martin Liška wrote:
>  /* We can not predict the probabilities of outgoing edges of bb.  Set them
> -   evenly and hope for the best.  */
> +   evenly and hope for the best.  If UNLIKELY_EDGES is not null, distribute
> +   evel probability for all edges not mentioned in the set.  These edges
> +   are given PROB_VERY_UNLIKELY probability.  */

Typo ("evel");

> +  unsigned unlikely_count = unlikely_edges ? unlikely_edges->elements () : 0;
> +
>FOR_EACH_EDGE (e, ei, bb->succs)
>  if (!(e->flags & (EDGE_EH | EDGE_FAKE)))
>nedges ++;
> +
> +  unsigned c = nedges - unlikely_count;

What prevents c from becoming 0?  The sum of outgoing edge probabilities
will be very small then (unless there are very many such noreturn edges,
then the sum is too big, instead).

>FOR_EACH_EDGE (e, ei, bb->succs)
>  if (!(e->flags & (EDGE_EH | EDGE_FAKE)))
> -  e->probability = (REG_BR_PROB_BASE + nedges / 2) / nedges;
> +  {
> + if (unlikely_edges != NULL && unlikely_edges->contains (e))
> +   e->probability = PROB_VERY_UNLIKELY;
> + else
> +   e->probability = (REG_BR_PROB_BASE + c / 2) / c;
> +  }
>  else
>e->probability = 0;
>  }

Even in the normal case, the sum of probabilities will not be almost 1
this way (almost REG_BR_PROB_BASE), but somewhat bigger.


Segher

Re: Implement -Wimplicit-fallthrough: core

[Jakub Jelinek]

On Fri, Jul 22, 2016 at 12:44:07PM +0200, Marek Polacek wrote:
> --- gcc/gcc/cp/parser.h
> +++ gcc/gcc/cp/parser.h
> @@ -46,7 +46,7 @@ struct GTY (()) cp_token {
>   Otherwise, this value is RID_MAX.  */
>ENUM_BITFIELD (rid) keyword : 8;
>/* Token flags.  */
> -  unsigned char flags;
> +  unsigned short flags;
>/* True if this token is from a context where it is implicitly extern "C" 
> */
>BOOL_BITFIELD implicit_extern_c : 1;
>/* True if an error has already been reported for this token, such as a

I'm afraid this is really bad.
Right now, there are 8 and 8 bit bitfields, then 8-bit char, 3 individual
bits, 5 unused bits and 32-bit int, nicely packed into 64-bit word before a
union with pointer members, and the C++ FE lexes everything first, so there
are possibly millions of tokens in memory.
Can't you just make it unsigned int flags : 11; instead?  Or instead
reshuffle the cpplib.h flags?  E.g. I don't see the C++ FE to use the
NO_EXPAND flag, so moving it to the upper byte of the short and moving the
new flag to its bit?  Perhaps that is even better for now.

Jakub

Re: Implement -Wimplicit-fallthrough: the rest

[Jakub Jelinek]

On Fri, Jul 22, 2016 at 12:44:30PM +0200, Marek Polacek wrote:
> ...and the boring part.  It found a few bugs, e.g. in jcf-dump.c
> and rs6000.c - I fixed those.
> 
> I think generally it's better to use the attribute rather than a falls
> through comment, because the latter can't be followed by other comment
> or a macro to work.

The comment has the advantage (at least if it is some well standardized one)
that lint/coverity and other tools already understand it.  So I think using
the comment in the cases where it really is immediately before case/default
is better.

> @@ -32335,6 +32341,7 @@ rs6000_handle_altivec_attribute (tree *node,
>   case V4SImode: case V8HImode: case V16QImode: case V4SFmode:
>   case V2DImode: case V2DFmode:
> result = type;
> +   gcc_fallthrough ();
>   default: break;
>   }
>break;
> @@ -32345,6 +32352,7 @@ rs6000_handle_altivec_attribute (tree *node,
>   case SImode: case V4SImode: result = bool_V4SI_type_node; break;
>   case HImode: case V8HImode: result = bool_V8HI_type_node; break;
>   case QImode: case V16QImode: result = bool_V16QI_type_node;
> +   gcc_fallthrough ();
>   default: break;
>   }
>break;
> @@ -32352,6 +32360,7 @@ rs6000_handle_altivec_attribute (tree *node,
>switch (mode)
>   {
>   case V8HImode: result = pixel_V8HI_type_node;
> +   gcc_fallthrough ();
>   default: break;
>   }
>  default: break;

I thought we don't warn on these anymore?

Also, as others said, I think it would be best to split this patch into:
1) bugfixes part (where you've added break; that was missing and it changes
   (fixes) behavior)
2) questionable cases (your XX), with request for the corresponding
   maintainers to decide
3) the actual addition of the attribute/comments or tweaking their wording,
   so that for intentional fallthrus we don't warn

Jakub

Re: Implement -Wimplicit-fallthrough: the rest

[Bernd Schmidt]

On 07/22/2016 01:15 PM, Jakub Jelinek wrote:

@@ -32335,6 +32341,7 @@ rs6000_handle_altivec_attribute (tree *node,
case V4SImode: case V8HImode: case V16QImode: case V4SFmode:
case V2DImode: case V2DFmode:
  result = type;
+ gcc_fallthrough ();
default: break;
}
   break;
@@ -32345,6 +32352,7 @@ rs6000_handle_altivec_attribute (tree *node,
case SImode: case V4SImode: result = bool_V4SI_type_node; break;
case HImode: case V8HImode: result = bool_V8HI_type_node; break;
case QImode: case V16QImode: result = bool_V16QI_type_node;
+ gcc_fallthrough ();
default: break;
}
   break;
@@ -32352,6 +32360,7 @@ rs6000_handle_altivec_attribute (tree *node,
   switch (mode)
{
case V8HImode: result = pixel_V8HI_type_node;
+ gcc_fallthrough ();
default: break;
}
 default: break;


I thought we don't warn on these anymore?


Also, please just add a break for cases like this. The last one ought to 
be an if statement in any case.



Bernd

Re: [PATCH, vec-tails 07/10] Support loop epilogue combining

[Richard Biener]

On Thu, Jul 21, 2016 at 6:34 PM, Jeff Law  wrote:
> On 07/21/2016 03:15 AM, Ilya Enkovich wrote:
>>
>> In my list I see #1, #4, and #5 are not approved.
>
> So I think Richi wanted to see param control for the new options; Joseph
> wanted the new options properly documented in invoke.texi;  I had a few
> higher level questions which you answered.  Your updated patch #1 added
> param control and invoke.texi documentation.  So IMHO, #1 is approved.
>
>
> #4 had some whitespace nits and needed some light doc improvements which
> you've done.  I think the only real implementation issue was computing costs
> in a single scan vs restarting the scan.  I was OK with the single scan
> approach you took -- not sure how strongly Richi feels about restarting the
> scan.  Seems like Richi needs to chime in on that topic.

I'm ok with a single scan as well.

The thing that needs work I think is re-running of if-conversion.
Also I don't like at
all that we have many variants of vectorizing but somehow the decision which one
to choose is rather unclear.  The way the epilogue vectorization code
is hooked in
is rather awkward and bound to be a maintainance burden (well, maybe a
small one).

And last, I double there is a case for a masked vectorized loop - I can bet that
doing a non-masked vectorized loop plus a masked epilogue (with no iteration
then!) will be always faster unless you hit the window of very few iterations
(or optimizing for size - in which case vectorizing is questionable on
its own and
disabled IIRC).

I don't mind Jeff not caring too much about this as I do not have
sufficient time
to iterate over this patch series with you within reasonable time.

Thanks,
Richard.

> I'm hoping to finish reviewing the update to #5 today.
>
> jeff

[PATCH] rs6000: Fix logic for when to emit .machine (PR71216)

[Segher Boessenkool]

The current logic determining whether to use .machine in the generated
asm code puts it there if the compiler is not configured with a default
target cpu, _or_ no -mcpu= was given on the command line.  It should
be "and" instead.

Tested on powerpc64-linux (-m32 as well).  Also tested manually with
the testcase in the PR (not included in the patch, it depends on your GCC
configuration).

Is this okay for trunk?  And backports later?


Segher


2016-07-22  Segher Boessenkool  

* config/rs6000/rs6000.c (rs6000_file_start): Fix condition for
when to emit a ".machine" pseudo-op.

---
 gcc/config/rs6000/rs6000.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 6fe94d5..7d47f45 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -5794,8 +5794,8 @@ rs6000_file_start (void)
 }
 
 #ifdef USING_ELFOS_H
-  if (rs6000_default_cpu == 0 || rs6000_default_cpu[0] == '\0'
-  || !global_options_set.x_rs6000_cpu_index)
+  if (!(rs6000_default_cpu && rs6000_default_cpu[0])
+  && !global_options_set.x_rs6000_cpu_index)
 {
   fputs ("\t.machine ", asm_out_file);
   if ((rs6000_isa_flags & OPTION_MASK_MODULO) != 0)
-- 
1.9.3

Re: [PATCH] predict.c: merge multi-edges

[Martin Liška]

On 07/22/2016 12:53 PM, Segher Boessenkool wrote:
> Hi Martin,
> 
> On Fri, Jul 22, 2016 at 10:17:51AM +0200, Martin Liška wrote:
>>  /* We can not predict the probabilities of outgoing edges of bb.  Set them
>> -   evenly and hope for the best.  */
>> +   evenly and hope for the best.  If UNLIKELY_EDGES is not null, distribute
>> +   evel probability for all edges not mentioned in the set.  These edges
>> +   are given PROB_VERY_UNLIKELY probability.  */
> 
> Typo ("evel");

Hello Segher.

The typo is fixed.

> 
>> +  unsigned unlikely_count = unlikely_edges ? unlikely_edges->elements () : 
>> 0;
>> +
>>FOR_EACH_EDGE (e, ei, bb->succs)
>>  if (!(e->flags & (EDGE_EH | EDGE_FAKE)))
>>nedges ++;
>> +
>> +  unsigned c = nedges - unlikely_count;
> 
> What prevents c from becoming 0?  The sum of outgoing edge probabilities
> will be very small then (unless there are very many such noreturn edges,
> then the sum is too big, instead).

You are right, I'm sending second version where I set even probabilities
in case of all edges are PROB_VERY_UNLIKELY. However, I was unable to come
up with a test-case for that:

int main(int argc, char **argv)
{
  switch (argc)
{
case 1:
  __builtin_unreachable();
case 4:
  __builtin_unreachable();
default:
  __builtin_unreachable();
}

  return 10;
}

No predictors are set as 'has_return_edges' == false in 
tree_bb_level_predictions.

I'm going to re-trigger tests for the patch.

Martin

> 
>>FOR_EACH_EDGE (e, ei, bb->succs)
>>  if (!(e->flags & (EDGE_EH | EDGE_FAKE)))
>> -  e->probability = (REG_BR_PROB_BASE + nedges / 2) / nedges;
>> +  {
>> +if (unlikely_edges != NULL && unlikely_edges->contains (e))
>> +  e->probability = PROB_VERY_UNLIKELY;
>> +else
>> +  e->probability = (REG_BR_PROB_BASE + c / 2) / c;
>> +  }
>>  else
>>e->probability = 0;
>>  }
> 
> Even in the normal case, the sum of probabilities will not be almost 1
> this way (almost REG_BR_PROB_BASE), but somewhat bigger.
> 
> 
> Segher
> 

>From f746848bec44877173bbe9ea3b04bdabe947119c Mon Sep 17 00:00:00 2001
From: marxin 
Date: Thu, 21 Jul 2016 16:20:42 +0200
Subject: [PATCH] predict.c: merge multi-edges

gcc/testsuite/ChangeLog:

2016-07-21  Martin Liska  

	* gcc.dg/predict-13.c: New test.

gcc/ChangeLog:

2016-07-21  Martin Liska  

	* predict.c (set_even_probabilities): Handle unlikely edges.
	(combine_predictions_for_bb): Likewise.
---
 gcc/predict.c | 73 +--
 gcc/testsuite/gcc.dg/predict-13.c | 24 +
 2 files changed, 87 insertions(+), 10 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/predict-13.c

diff --git a/gcc/predict.c b/gcc/predict.c
index 7fbd404..ca320cd 100644
--- a/gcc/predict.c
+++ b/gcc/predict.c
@@ -785,9 +785,13 @@ dump_prediction (FILE *file, enum br_predictor predictor, int probability,
 }
 
 /* We can not predict the probabilities of outgoing edges of bb.  Set them
-   evenly and hope for the best.  */
+   evenly and hope for the best.  If UNLIKELY_EDGES is not null, distribute
+   even probability for all edges not mentioned in the set.  These edges
+   are given PROB_VERY_UNLIKELY probability.  */
+
 static void
-set_even_probabilities (basic_block bb)
+set_even_probabilities (basic_block bb,
+			hash_set *unlikely_edges = NULL)
 {
   int nedges = 0;
   edge e;
@@ -796,9 +800,25 @@ set_even_probabilities (basic_block bb)
   FOR_EACH_EDGE (e, ei, bb->succs)
 if (!(e->flags & (EDGE_EH | EDGE_FAKE)))
   nedges ++;
+
+  /* Make the distribution even if all edges are unlikely.  */
+  unsigned unlikely_count = unlikely_edges ? unlikely_edges->elements () : 0;
+  if (unlikely_count == nedges)
+{
+  unlikely_edges = NULL;
+  unlikely_count = 0;
+}
+
+  unsigned c = nedges - unlikely_count;
+
   FOR_EACH_EDGE (e, ei, bb->succs)
 if (!(e->flags & (EDGE_EH | EDGE_FAKE)))
-  e->probability = (REG_BR_PROB_BASE + nedges / 2) / nedges;
+  {
+	if (unlikely_edges != NULL && unlikely_edges->contains (e))
+	  e->probability = PROB_VERY_UNLIKELY;
+	else
+	  e->probability = (REG_BR_PROB_BASE + c / 2) / c;
+  }
 else
   e->probability = 0;
 }
@@ -1068,18 +1088,51 @@ combine_predictions_for_bb (basic_block bb, bool dry_run)
 
   /* When there is no successor or only one choice, prediction is easy.
 
- We are lazy for now and predict only basic blocks with two outgoing
- edges.  It is possible to predict generic case too, but we have to
- ignore first match heuristics and do more involved combining.  Implement
- this later.  */
+ When we have a basic block with more than 2 successors, the situation
+ is more complicated as DS theory cannot be used literally.
+ More precisely, let's assume we predicted edge e1 with probability p1,
+ thus: m1({b1}) = p1.  As we're going to combine more than 2 edges, we
+ need to find probability of e.g. m1({b2}), which we don't kn

Re: [Patch GCC/01]Bring back warning message on loop whose counter might overflow

[Richard Biener]

On Thu, Jul 21, 2016 at 6:48 PM, Bin Cheng  wrote:
> Hi,
> Previous patch removed warning message on loops whose counter might overflow, 
> while this patch adds it back.  Reason is it's always good to have a warning 
> message indicating missed loop optimizations.  Also warning message itself is 
> slightly changed.
> There will be following patch which removes -funsafe-loop-optimizations.
>
> Bootstrap and test on x86_64.  Is it OK?

Please do not use 'input_location'.  You never should check
LOCATION_LINE either but
just for loc != UNKNOWN_LOCATION.  Note that simply passing
gimple_location should
work and fall back to sth sensible for UNKNOWN_LOCATION.

Ok with that change,
Richard.

> Thanks,
> bin
>
> 2016-07-20  Bin Cheng  
>
> * tree-ssa-loop-niter.h (number_of_iterations_exit_assumptions): New
> Parameter.
> * tree-ssa-loop-niter.c (number_of_iterations_exit_assumptions): New
> Parameter.
> (number_of_iterations_exit): Warn missed loop optimization for
> possible infinite loops.
>
> gcc/testsuite/ChangeLog
> 2016-07-20  Bin Cheng  
>
> * gcc.dg/tree-ssa/pr19210-1.c: Refine test strings.
> * gcc.dg/tree-ssa/pr19210-2.c: Delete.

Re: [PATCH GCC/02]Remove -funsafe-loop-optimizations option.

[Richard Biener]

On Thu, Jul 21, 2016 at 6:49 PM, Bin Cheng  wrote:
> Hi,
> This patch removes support for -funsafe-loop-optimizations on both GIMPLE and 
> RTL level by marking it as ignored.
> Bootstrap and test on x86_64.  Is it OK?

Ok.

Richard.

> Thanks,
> bin
>
> 2016-07-20  Bin Cheng  
>
> * common.opt (funsafe-loop-optimizations): Mark ignore.
> * doc/invoke.texi (funsafe-loop-optimizations): Remove.
> * loop-iv.c (get_simple_loop_desc): Remove unsafe-loop-optimizations
> related code.
> * tree-ssa-loop-niter.c (finite_loop_p): Ditto.
> * config/bfin/bfin.c (bfin_can_use_doloop_p): Ditto.

[PATCH] Adapt the numbering scheme (PR gcov-profile/64874)

[Martin Liška]

Hi.

As described in the PR, current numbering scheme in gcov-io.h would overflow in 
couple of years.
Thus, I'm suggesting to switch from:

[major][minor/10][minor%10][release_status]

to:
[major/10][major%10][minor][release_status]

Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.

Ready to be installed?
Martin
>From 3e35f8f08558d95f5d6bd674f659c976ea86f311 Mon Sep 17 00:00:00 2001
From: marxin 
Date: Fri, 22 Jul 2016 11:54:20 +0200
Subject: [PATCH] Adapt the numbering scheme (PR gcov-profile/64874)

gcc/ChangeLog:

2016-07-22  Martin Liska  

	PR gcov-profile/64874
	* gcov-io.h: Update command about file format.
	* gcov-iov.c (main): Adapt the numbering scheme.
---
 gcc/gcov-io.h  | 17 -
 gcc/gcov-iov.c |  6 +++---
 2 files changed, 11 insertions(+), 12 deletions(-)

diff --git a/gcc/gcov-io.h b/gcc/gcov-io.h
index 3446407..4475d1f 100644
--- a/gcc/gcov-io.h
+++ b/gcc/gcov-io.h
@@ -63,19 +63,18 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
 
Although the ident and version are formally 32 bit numbers, they
are derived from 4 character ASCII strings.  The version number
-   consists of the single character major version number, a two
-   character minor version number (leading zero for versions less than
-   10), and a single character indicating the status of the release.
+   consists of a two character major version number (leading zero for versions
+   less than 10), the single character minor version number,
+   and a single character indicating the status of the release.
That will be 'e' experimental, 'p' prerelease and 'r' for release.
Because, by good fortune, these are in alphabetical order, string
collating can be used to compare version strings.  Be aware that
the 'e' designation will (naturally) be unstable and might be
-   incompatible with itself.  For gcc 3.4 experimental, it would be
-   '304e' (0x33303465).  When the major version reaches 10, the
-   letters A-Z will be used.  Assuming minor increments releases every
-   6 months, we have to make a major increment every 50 years.
-   Assuming major increments releases every 5 years, we're ok for the
-   next 155 years -- good enough for me.
+   incompatible with itself.  For gcc 7.0 experimental, it would be
+   '070e' (0x30373065).  As we currently do not release more than 5 minor
+   releases, the single character should be always fine.  Major number
+   is currently changed roughly every year, which gives us space
+   for next 90 years.
 
A record has a tag, length and variable amount of data.
 
diff --git a/gcc/gcov-iov.c b/gcc/gcov-iov.c
index 202f32a..6685c49 100644
--- a/gcc/gcov-iov.c
+++ b/gcc/gcov-iov.c
@@ -58,9 +58,9 @@ main (int argc, char **argv)
   || strcmp (argv[2], "prerelease") == 0)
 phase = '*';
 
-  v[0] = (major < 10 ? '0' : 'A' - 10) + major;
-  v[1] = (minor / 10) + '0';
-  v[2] = (minor % 10) + '0';
+  v[0] = (major / 10) + '0';
+  v[1] = (major % 10) + '0';
+  v[2] = minor + '0';
   v[3] = phase;
 
   for (ix = 0; ix != 4; ix++)
-- 
2.9.0

Re: [PATCH] Fix early debug regression with DW_AT_string_length (PR debug/71906)

[Richard Biener]

On Thu, Jul 21, 2016 at 6:53 PM, Jakub Jelinek  wrote:
> Hi!
>
> The early debug changes broke e.g. following testcase:
> program pr71906
>   character(len=8) :: vard
>   character(len=:), allocatable :: vare
>   type t
> character(len=:), allocatable :: f
>   end type
>   type(t) :: varf
>   allocate(character(len=10) :: vare)
>   allocate(character(len=9) :: varf%f)
>   vare = 'foo'
>   call foo (vard, vare, varf)
> contains
>   subroutine foo (vara, varb, varc)
> character(len=*) :: vara
> character(len=:), allocatable :: varb
> type(t) :: varc
> vara = 'bar'
> varb = 'baz'
> varc%f = 'str'
>   end subroutine
> end program pr71906
>
> The issue is that unlike e.g. DW_AT_upper_bound, DW_AT_string_length
> doesn't allow a reference to some other DIE, so while for the former
> we just emit a reference to an artificial var holding the VLA sizes,
> for non-constant string length loc_list_from_tree used to work, but
> doesn't anymore.
>
> The following patch has 4 major parts:
> 1) Fortran FE change to emit the artificial vars holding string length
>before the string vars (something I broke recently with PR71687
>fix)
> 2) for early_dwarf, loc_list_from_tree for the DW_AT_string_length
>var will most likely fail, the code in gen_array_type_die
>in that case adds DW_OP_call4 referencing the DIE of the artificial
>var or parameter; DW_OP_call4 is a rough match, in that it only works
>properly if the artificial var has DWARF expressions (rather than
>location descriptions); the patch also adds newly support for
>varb above, where the string length is INDIRECT_REF of artificial
>PARM_DECL; for early dwarf this adds DW_OP_call4; DW_OP_deref{,_size};
>the reason to handle it this way is that IMHO it matches more the
>spirit and intention of the early dwarf eventually for LTO, where
>I presume we'd stream the early dwarf created debug info and read/adjust
>it afterwards; LTO doesn't know that something is a fortran character
>and what string length it has
> 3) unfortunately, for the PARM_DECL and INDIRECT_REF of PARM_DECL
>cases, usually we need to refer to a parameter whose DIE has not
>been created yet during early_dwarf; and trying to create it
>out of order has various issues, e.g. the debugger would show them
>up in different order.  So, this is resolved using the string_types
>vector, adjust_string_types function and some code in gen_subprogram_die
> 4) finally, when finalizing the debug info, resolve_addr and its helper
>functions look at DW_AT_string_length with DW_OP_call4 optionally
>followed by DW_OP_deref{,_size} in its DWARF expression, look up the
>referenced DIE, consider its DW_AT_location and either:
>- keep it as is, if it is valid DWARF (i.e. known to be defined for
>  all PCs to a DWARF expression)
>- copy the DW_AT_location attribute value/form to the DW_AT_string_length
>  (in the non-deref case)
>- for the deref case, adjust what can be easily adjusted
>  (DWARF expression with DW_OP_stack_value at the end drops the stack
>  value and thus handles the dereference, regx/regN replaced by
>  bregx/bregN 0, for DWARF expression only add dereference at the end,
>  drop cases that can't be adjusted
>- drop the DW_AT_string_length attribute and DW_AT_byte_size if present
>  too if the DIE doesn't have DW_AT_location, or it isn't usable etc.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2016-07-21  Jakub Jelinek  
>
> PR debug/71906
> * dwarf2out.c (string_types): New variable.
> (gen_array_type_die): Change early_dwarf handling of
> DW_AT_string_length, create DW_OP_call4 referencing the
> length var temporarily.  Handle parameters that are pointers
> to string length.
> (adjust_string_types): New function.
> (gen_subprogram_die): Temporarily set string_types to local var,
> call adjust_string_types if needed.
> (non_dwarf_expression, copy_deref_exprloc, optimize_string_length):
> New functions.
> (resolve_addr): Adjust DW_AT_string_length if it is DW_OP_call4.
>
> * trans-decl.c (gfc_get_symbol_decl): Call gfc_finish_var_decl
> for decl's character length before gfc_finish_var_decl on the
> decl itself.
>
> --- gcc/dwarf2out.c.jj  2016-07-21 08:59:47.101616662 +0200
> +++ gcc/dwarf2out.c 2016-07-21 11:10:11.510137511 +0200
> @@ -3123,6 +3123,10 @@ static bool frame_pointer_fb_offset_vali
>
>  static vec base_types;
>
> +/* Pointer to vector of DW_TAG_string_type DIEs that need finalization
> +   once all arguments are parsed.  */
> +static vec *string_types;
> +
>  /* Flags to represent a set of attribute classes for attributes that 
> represent
> a scalar value (bounds, pointers, ...).  */
>  enum dw_scalar_form
> @@ -19201,18 +19205,70 @@ gen_array_type_die (tree type, dw_die_re
>

Re: [PATCH] Adapt the numbering scheme (PR gcov-profile/64874)

[Nathan Sidwell]

On 07/22/16 07:46, Martin Liška wrote:

Hi.

As described in the PR, current numbering scheme in gcov-io.h would overflow in 
couple of years.
Thus, I'm suggesting to switch from:

[major][minor/10][minor%10][release_status]

to:
[major/10][major%10][minor][release_status]


If I'm reading that right, although we'll have a strange collating order that 
won't match release ordering, we won't get collisions (because the minor version 
never got above 9).



Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.


Yes thanks.  I was wondering when gcc's new version numbering would impact this 
ident.



nathan

Re: [PATCH 2/2][v3] Drop excess size used for run time allocated stack variables.

[Dominik Vogt]

On Thu, Jul 21, 2016 at 02:07:05PM -0600, Jeff Law wrote:
> On 06/23/2016 03:57 AM, Dominik Vogt wrote:
> >>and use that rather than rounding size up to an alignment boundary.
> >
> >Not exactly.  Consider the unpatched code.  At the beginning we
> >have some amount of space to be allocated on the stack at runtime
> >("SSIZE"), some requested alignment for it ("SALIGN").
> >
> >get_dynamic_stack_size() first calculates the space needed for run
> >time alignment:
> >
> >  SIZE = SSIZE + SALIGN - 1
> >
> >Then it calls round_push() to add *another* chunk of memory to the
> >allocation size to be able to align it to the required stack slot
> >alignment ("SLOTALIGN") at run time.
> >
> >  SIZE = SIZE + SLOTALIGN - 1
> >   = SSIZE + (SALIGN - 1) + (SLOTALIGN - 1)
> >
> >Now it has added two chunks of memory but alignment is only done
> >once.  With the patch it just adds the maximum of (SALIGN - 1) and
> >(SLOTALIGN - 1), not both.  Thinking about it, the "round_push"
> >stuff is a very complicated way of saying "add max(A, B)".
> Now I see it.  Thanks, that helped a ton.
> 
> >
> >I'd volunteer to clean this up more, but preferrably when the two
> >pending patches are in.  The current code is a real brain-twister.
> I'd be all for such cleanups after we wrap up the pending patches.
> It's certainly a rats nest of code right now.
> 
> This patch is fine for the trunk.  Thanks for your patience.

Actually I was goind to abandon the patch in its current state.
:-)  We talked about it internally and concluded that the problem
is really this:

 * get_dynamic_stack_size is passed a SIZE of a data block (which
   is allocated elsewhere), the SIZE_ALIGN of the SIZE (i.e. the
   alignment of the underlying memory units (e.g. 32 bytes split
   into 4 times 8 bytes = 64 bit alignment) and the
   REQUIRED_ALIGN of the data portion of the allocated memory.
 * Assuming the function is called with SIZE = 2, SIZE_ALIGN = 8
   and REQUIRED_ALIGN = 64 it first adds 7 bytes to SIZE -> 9.
   This is what is needed to have two bytes 8-byte-aligned at some
   memory location without any known alignment.
 * Finally round_push is called to round up SIZE to a multiple of
   the stack slot size.

The key to understanding this is that the function assumes that
STACK_DYNMAIC_OFFSET is completely unknown at the time its called
and therefore it does not make assumptions about the alignment of
STACKPOINTER + STACK_DYNMAIC_OFFSET.  The latest patch simply
hard-codes that SP + SDO is supposed to be aligned to at least
stack slot size (and does that in a very complicated way).  Since
there is no guarantee that this is the case on all targets, the
patch is broken.  It may miscalculate a SIZE that is too small in
some cases.

However, on many targets there is some guarantee about the
alignment of SP + SDO even if the actual value of SDO is unknown.
On s390x it's always 8-byte-aligned (stack slot size).  So the
right fix should be to add knowledge about the target's guaranteed
alignment of SP + SDO to the function.  I'm right now testing a
much simpler patch that uses
REGNO_POINTER_ALIGN(VIRTUAL_STACK_DYNAMIC_REGNUM) as the
alignment.

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt
IBM Germany

Re: [PATCH] Avoid invoking ranlib on libbackend.a

[Patrick Palka]

On Fri, Jul 22, 2016 at 2:19 AM, Andrew Pinski  wrote:
> On Wed, Jul 20, 2016 at 7:11 AM, Patrick Palka  wrote:
>> On Wed, 20 Jul 2016, Bernd Schmidt wrote:
>>
>>> On 07/19/2016 10:20 AM, Richard Biener wrote:
>>> > I like it.  Improving re-build time in my dev tree is very much
>>> > welcome, and yes,
>>> > libbackend build time is a big part of it usually (plus of course cc1
>>> > link time).
>>>
>>> Since that wasn't an entirely explicit ack, I'll add mine. Thank you for 
>>> doing
>>> this.
>>>
>>>
>>> Bernd
>>>
>>>
>>
>> Committed as r238524 with the following minor change to the configure
>> test to use $CFLAGS and $LDFLAGS consistently:
>
> What is interesting is I did not see any change in my bootstrap/test
> times.  Constant at 1 hour and 39 minutes (this includes archiving the
> build away).
> And yes I checked the logs to make sure T option to ar is being used too.
>
> Thanks,
> Andrew

Do you see any change in rebuild times in a --disable-bootstrap dev
tree?  On average I guess you'd save about 20s per stage which is a
significant amount of time during development (in a
--disable-bootstrap tree) but not so much when bootstrap/regtesting.
The ar+ranlib invocation is primarily I/O bottlenecked (it writes out
900MB of stuff) so the amount of time saved by using a thin archive
depends on how slow your block device is.

>
>>
>> diff --git a/gcc/configure.ac b/gcc/configure.ac
>> index 63052ba..241e82d 100644
>> --- a/gcc/configure.ac
>> +++ b/gcc/configure.ac
>> @@ -4905,7 +4905,7 @@ echo 'int main (void) { return 0; }' > conftest.c
>>  if ($AR --version | sed 1q | grep "GNU ar" \
>>  && $CC $CFLAGS -c conftest.c \
>>  && $AR rcT conftest.a conftest.o \
>> -&& $CC -o conftest conftest.a) >/dev/null 2>&1; then
>> +&& $CC $CFLAGS $LDFLAGS -o conftest conftest.a) >/dev/null 2>&1; then
>>thin_archive_support=yes
>>  fi
>>  rm -f conftest.c conftest.o conftest.a conftest

Re: [PATCH] Fix early debug regression with DW_AT_string_length (PR debug/71906)

[Jakub Jelinek]

On Fri, Jul 22, 2016 at 01:55:22PM +0200, Richard Biener wrote:
> > @@ -19201,18 +19205,70 @@ gen_array_type_die (tree type, dw_die_re
> >if (size >= 0)
> > add_AT_unsigned (array_die, DW_AT_byte_size, size);
> >else if (TYPE_DOMAIN (type) != NULL_TREE
> > -  && TYPE_MAX_VALUE (TYPE_DOMAIN (type)) != NULL_TREE
> > -  && DECL_P (TYPE_MAX_VALUE (TYPE_DOMAIN (type
> > +  && TYPE_MAX_VALUE (TYPE_DOMAIN (type)) != NULL_TREE)
> > {
> >   tree szdecl = TYPE_MAX_VALUE (TYPE_DOMAIN (type));
> > - dw_loc_list_ref loc = loc_list_from_tree (szdecl, 2, NULL);
> > + tree rszdecl = szdecl;
> > + HOST_WIDE_INT rsize = 0;
> >
> >   size = int_size_in_bytes (TREE_TYPE (szdecl));
> > - if (loc && size > 0)
> > + if (!DECL_P (szdecl))
> > {
> > - add_AT_location_description (array_die, DW_AT_string_length, 
> > loc);
> > - if (size != DWARF2_ADDR_SIZE)
> > -   add_AT_unsigned (array_die, DW_AT_byte_size, size);
> > + if (TREE_CODE (szdecl) == INDIRECT_REF
> 
> So I wonder how this can happen with variable-size type
> gimplification.  Shouldn't
> this be on, say, DECL_VALUE_EXPR of the DECL_P TYPE_MAX_VALUE?

If you mean the INDIRECT_REF, that only happens with PARM_DECLs, and
conceptually a dereference of the argument is the right spot where the
length lives (if you reallocate the string with different character length,
then that is where you store the value.  If you add some artificial
decl that will hold the value of *_varb, then the trouble is that the
variable won't be assigned before the function prologue and most likely will
be optimized away anyway.

>  <1><28d>: Abbrev Number: 19 (DW_TAG_string_type)
>  <1><28e>: Abbrev Number: 19 (DW_TAG_string_type)
>  <1><28f>: Abbrev Number: 6 (DW_TAG_pointer_type)
> 
> so there is nothing to annotate with a location later.

With the patch there will be DW_OP_call4 in 2 DW_AT_string_length
attributes and one DW_OP_call4; DW_OP_deref.

> Note that even with GCC 5 'varb' didn't get a DW_AT_string_length,
> 'vara' did, though.

Yeah, I've mentioned that in the mail.

Jakub

Re: [RFC][IPA-VRP] Early VRP Implementation

[kugan]

Hi Richard,

Thanks for the review.

On 18/07/16 21:51, Richard Biener wrote:

On Fri, Jul 15, 2016 at 9:33 AM, kugan
 wrote:

Hi Andrew,

On 15/07/16 17:28, Andrew Pinski wrote:


On Fri, Jul 15, 2016 at 12:08 AM, kugan
 wrote:


Hi Andrew,


Why separate out early VRP from tree-vrp?  Just a little curious.




It is based on the discussion in
https://gcc.gnu.org/ml/gcc/2016-01/msg00069.html.
In summary, conclusion (based on my understanding) was to implement a
simplified VRP algorithm that doesn't require ASSERT_EXPR insertion.



But I don't see why you are moving it from tree-vrp.c .  That was my
question, you pointing to that discussion does not say to split it
into a new file and expose these interfaces.



Are you saying that I should keep this part of tree-vrp.c. I am happy to do
that if this is considered the best approach.


Yes, I think that's the best approach.


Thanks. Moved it into tree-vrp.c now.


Can you, as a refactoring before your patch, please change VRP to use
an alloc-pool
for allocating value_range?  The DOM-based VRP will add a lot of
malloc/free churn
otherwise.

Generally watch coding-style such as  missed function comments.

As you do a non-iterating VRP and thus do not visit back-edges you don't need
to initialize loops or SCEV nor do you need loop-closed SSA.

As you do a DOM-based VRP using SSA propagator stuff like ssa_prop_result
doesn't make any sense.


I have removed it.


+edge evrp_dom_walker::before_dom_children (basic_block bb)
+{
+  /* If we are going out of scope, restore the old VR.  */
+  while (!cond_stack.is_empty ()
+&& !dominated_by_p (CDI_DOMINATORS, bb, cond_stack.last ().first))
+{
+  tree var = cond_stack.last ().second.first;
+  value_range *vr = cond_stack.last ().second.second;
+  value_range *vr_to_del = get_value_range (var);
+  XDELETE (vr_to_del);
+  change_value_range (var, vr);
+  cond_stack.pop ();
+}

that should be in after_dom_children I think and use a marker instead
of a DOM query.
See other examples like DOM itself or SCCVN.



Done.

+ /* Discover VR when condition is true.  */
+ if (te == e
+ && !TREE_OVERFLOW_P (op0)
+ && !TREE_OVERFLOW_P (op1))


This is mainly to handle gcc.dg/pr38934.c. This would result in ICE from 
set_value_range otherwise:


gcc_assert ((!TREE_OVERFLOW_P (min) || is_overflow_infinity (min))
  && (!TREE_OVERFLOW_P (max) || is_overflow_infinity 
(max)));




you can use e->flags & EDGE_TRUE_VALUE/EDGE_FALSE_VALUE

why do you need those TREE_OVERFLOW checks?

+ tree cond = build2 (code, boolean_type_node, op0, op1);
+ tree a = build2 (ASSERT_EXPR, TREE_TYPE (op0), op0, cond);
+ extract_range_from_assert (&vr, a);

so I was hoping that the "refactoring" patch in the series would expose a more
useful interface than extract_range_from_assert ... namely one that can
extract a range from the comparison directly and does not require building
a scratch ASSERT_EXPR.


I have split extract_range_from_assert into 
extract_range_for_var_from_comparison_expr and using it now. Is that better?


+ /* If we found any usable VR, set the VR to ssa_name and create a
+restore point in the cond_stack with the  old VR. */
+ if (vr.type == VR_RANGE || vr.type == VR_ANTI_RANGE)
+   {
+ value_range *new_vr = XCNEW (value_range);
+ *new_vr = vr;
+ cond_stack.safe_push (std::make_pair (bb,
+   std::make_pair (op0,
+   old_vr)));
+ change_value_range (op0, new_vr);

I don't like 'change_value_range' as interface, please integrate that into
a push/pop_value_range style interface instead.


Tried using push/pop interface.


+   vrp_visit_stmt (stmt, &taken_edge_p, &output_p);
+}
+
+  return NULL;

you should return taken_edge_p (misnamed as it isn't a pointer) and take
advantage of EDGE_EXECUTABLE.  Again see DOM/SCCVN (might want to
defer this as a followup improvement).


I have added a TODO to this effect and will comeback to it.


Note that the advantage of a DOM-based VRP is that backtracking is easy
to implement (you don't do that yet).  That is, after DEF got a (better)
value-range you can simply re-visit all the defs of its uses (and recursively).
I think you have to be careful with stmts that might prematurely leave a BB
though (like via EH).  So sth for a followup as well.


Is this OK now. Bootstrapped and regression tested on x86_64-linux  with 
no new regressions.


Thanks,
Kugan

gcc/ChangeLog:

2016-07-22  Kugan Vivekanandarajah  

* common.opt: New option -ftree-evrp.
* doc/invoke.texi: Document -ftree-evrp.
* passes.def: Define new pass_early_vrp.
* timevar.def: Define new TV_TREE_EARLY_VRP.
* tree-pass.h (make_pass_early_vrp): New.
* tree-vrp.c (ex

Re: [Patch GCC/01]Bring back warning message on loop whose counter might overflow

[Bin.Cheng]

On Fri, Jul 22, 2016 at 12:39 PM, Richard Biener
 wrote:
> On Thu, Jul 21, 2016 at 6:48 PM, Bin Cheng  wrote:
>> Hi,
>> Previous patch removed warning message on loops whose counter might 
>> overflow, while this patch adds it back.  Reason is it's always good to have 
>> a warning message indicating missed loop optimizations.  Also warning 
>> message itself is slightly changed.
>> There will be following patch which removes -funsafe-loop-optimizations.
>>
>> Bootstrap and test on x86_64.  Is it OK?
>
> Please do not use 'input_location'.  You never should check
> LOCATION_LINE either but
> just for loc != UNKNOWN_LOCATION.  Note that simply passing
> gimple_location should
> work and fall back to sth sensible for UNKNOWN_LOCATION.
>
> Ok with that change,
Thanks for reviewing, attachment is the updated patch.

Thanks,
bin
> Richard.
>
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr19210-1.c 
b/gcc/testsuite/gcc.dg/tree-ssa/pr19210-1.c
index 906132c..3c8ee06 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/pr19210-1.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr19210-1.c
@@ -6,10 +6,10 @@ void
 f (unsigned n)
 {
   unsigned k;
-  for(k = 0;k <= n;k++) /* { dg-warning "cannot optimize.*infinite loops" } */
+  for(k = 0;k <= n;k++) /* { dg-warning "missed loop optimization.*overflow" } 
*/
 g();
 
-  for(k = 0;k <= n;k += 4) /* { dg-warning "cannot optimize.*overflow" } */
+  for(k = 0;k <= n;k += 4) /* { dg-warning "missed loop 
optimization.*overflow" } */
 g();
 
   /* We used to get warning for this loop.  However, since then # of iterations
@@ -21,9 +21,9 @@ f (unsigned n)
 g();
 
   /* So we need the following loop, instead.  */
-  for(k = 4;k <= n;k += 5) /* { dg-warning "cannot optimize.*overflow" } */
+  for(k = 4;k <= n;k += 5) /* { dg-warning "missed loop 
optimization.*overflow" } */
 g();
   
-  for(k = 15;k >= n;k--) /* { dg-warning "cannot optimize.*infinite" } */
+  for(k = 15;k >= n;k--) /* { dg-warning "missed loop optimization.*overflow" 
} */
 g();
 }
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr19210-2.c 
b/gcc/testsuite/gcc.dg/tree-ssa/pr19210-2.c
deleted file mode 100644
index 9116e97..000
--- a/gcc/testsuite/gcc.dg/tree-ssa/pr19210-2.c
+++ /dev/null
@@ -1,29 +0,0 @@
-/* { dg-do compile } */
-/* { dg-options "-O2 -funsafe-loop-optimizations -Wunsafe-loop-optimizations" 
} */
-extern void g(void);
-
-void
-f (unsigned n)
-{
-  unsigned k;
-  for(k = 0;k <= n;k++) /* { dg-warning "assuming.*not infinite" } */
-g();
-
-  for(k = 5;k <= n;k += 4) /* { dg-warning "assuming.*not overflow" } */
-g();
-
-  /* We used to get warning for this loop.  However, since then # of iterations
- analysis improved, and we can now prove that this loop does not verflow.
- This is because the only case when it would overflow is if n = ~0 (since
- ~0 is divisible by 5), and this cannot be the case, since when we got
- here, the previous loop exited, thus there exists k > n.  */
-  for(k = 5;k <= n;k += 5)
-g();
-
-  for(k = 4;k <= n;k += 5) /* { dg-warning "assuming.*not overflow" } */
-g();
-
-  for(k = 15;k >= n;k--) /* { dg-warning "assuming.*not infinite" } */
-g();
-
-}
diff --git a/gcc/tree-ssa-loop-niter.c b/gcc/tree-ssa-loop-niter.c
index d96c03b..3697fbf 100644
--- a/gcc/tree-ssa-loop-niter.c
+++ b/gcc/tree-ssa-loop-niter.c
@@ -2181,12 +2181,13 @@ loop_only_exit_p (const struct loop *loop, const_edge 
exit)
in comments at struct tree_niter_desc declaration), false otherwise.
When EVERY_ITERATION is true, only tests that are known to be executed
every iteration are considered (i.e. only test that alone bounds the loop).
- */
+   If AT_STMT is not NULL, this function stores LOOP's condition statement in
+   it when returning true.  */
 
 bool
 number_of_iterations_exit_assumptions (struct loop *loop, edge exit,
   struct tree_niter_desc *niter,
-  bool every_iteration)
+  gcond **at_stmt, bool every_iteration)
 {
   gimple *last;
   gcond *stmt;
@@ -2303,6 +2304,9 @@ number_of_iterations_exit_assumptions (struct loop *loop, 
edge exit,
   if (TREE_CODE (niter->niter) == INTEGER_CST)
 niter->max = wi::to_widest (niter->niter);
 
+  if (at_stmt)
+*at_stmt = stmt;
+
   return (!integer_zerop (niter->assumptions));
 }
 
@@ -2312,13 +2316,26 @@ number_of_iterations_exit_assumptions (struct loop 
*loop, edge exit,
 bool
 number_of_iterations_exit (struct loop *loop, edge exit,
   struct tree_niter_desc *niter,
-  bool, bool every_iteration)
+  bool warn, bool every_iteration)
 {
+  gcond *stmt;
   if (!number_of_iterations_exit_assumptions (loop, exit, niter,
- every_iteration))
+ &stmt, every_iteration))
 return false;
 
-  return (integer_nonzerop (niter->assumptions));
+  

Re: [PATCH] Avoid invoking ranlib on libbackend.a

[Patrick Palka]

On Fri, Jul 22, 2016 at 8:02 AM, Patrick Palka  wrote:
> On Fri, Jul 22, 2016 at 2:19 AM, Andrew Pinski  wrote:
>> On Wed, Jul 20, 2016 at 7:11 AM, Patrick Palka  wrote:
>>> On Wed, 20 Jul 2016, Bernd Schmidt wrote:
>>>
 On 07/19/2016 10:20 AM, Richard Biener wrote:
 > I like it.  Improving re-build time in my dev tree is very much
 > welcome, and yes,
 > libbackend build time is a big part of it usually (plus of course cc1
 > link time).

 Since that wasn't an entirely explicit ack, I'll add mine. Thank you for 
 doing
 this.


 Bernd


>>>
>>> Committed as r238524 with the following minor change to the configure
>>> test to use $CFLAGS and $LDFLAGS consistently:
>>
>> What is interesting is I did not see any change in my bootstrap/test
>> times.  Constant at 1 hour and 39 minutes (this includes archiving the
>> build away).
>> And yes I checked the logs to make sure T option to ar is being used too.
>>
>> Thanks,
>> Andrew
>
> Do you see any change in rebuild times in a --disable-bootstrap dev
> tree?  On average I guess you'd save about 20s per stage which is a
> significant amount of time during development (in a
> --disable-bootstrap tree) but not so much when bootstrap/regtesting.
> The ar+ranlib invocation is primarily I/O bottlenecked (it writes out
> 900MB of stuff) so the amount of time saved by using a thin archive
> depends on how slow your block device is.

... so it's weird that your build times are constant because building
a thin archive is much faster than building a regular archive and
using a thin archive should not make subsequent steps, like linking
that archive, slower.  So overall build times should be lower.

>
>>
>>>
>>> diff --git a/gcc/configure.ac b/gcc/configure.ac
>>> index 63052ba..241e82d 100644
>>> --- a/gcc/configure.ac
>>> +++ b/gcc/configure.ac
>>> @@ -4905,7 +4905,7 @@ echo 'int main (void) { return 0; }' > conftest.c
>>>  if ($AR --version | sed 1q | grep "GNU ar" \
>>>  && $CC $CFLAGS -c conftest.c \
>>>  && $AR rcT conftest.a conftest.o \
>>> -&& $CC -o conftest conftest.a) >/dev/null 2>&1; then
>>> +&& $CC $CFLAGS $LDFLAGS -o conftest conftest.a) >/dev/null 2>&1; then
>>>thin_archive_support=yes
>>>  fi
>>>  rm -f conftest.c conftest.o conftest.a conftest

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

[kugan]

Hi,

Now that early vrp is moved as part of tree-vrp, there is only minimal 
interface tree-vrp should expose for ipa-vrp. However, I have not found 
the right place to place struct value_range (with GTY marker) and enum 
value_range_type.


enum value_range_type is needed in tree-ssanames.[h|c] and in all the 
places where get|set_range_info is used.


struct value_range is needed in ipa-prop.h, therefore all the places 
ipa-prop.h is included.


One option is to place it in tree-vrp.h and expose this to GTY 
infrastructure. Then include it in all the places we need any of these 
types. It is in lots of c files.


I have now placed both in tree.h. Even though that compiles, I am not 
convinced that is the right place.


I would appreciate comment/preferences in this regard. I am also 
attaching the current version of this patch for review. I will update it 
based on the comments.


Thanks,
Kugan



>From 2e7d10923fefddafdeffc571e870508ac0ee193c Mon Sep 17 00:00:00 2001
From: Kugan Vivekanandarajah 
Date: Tue, 21 Jun 2016 12:42:44 +1000
Subject: [PATCH 4/7] Refactor vrp

---
 gcc/tree-ssanames.h |  5 -
 gcc/tree-vrp.c  | 50 --
 gcc/tree-vrp.h  | 23 +++
 gcc/tree.h  | 31 +++
 4 files changed, 66 insertions(+), 43 deletions(-)
 create mode 100644 gcc/tree-vrp.h

diff --git a/gcc/tree-ssanames.h b/gcc/tree-ssanames.h
index c81b1a1..8e66ce6 100644
--- a/gcc/tree-ssanames.h
+++ b/gcc/tree-ssanames.h
@@ -62,11 +62,6 @@ struct GTY ((variable_size)) range_info_def {
 #define num_ssa_names (vec_safe_length (cfun->gimple_df->ssa_names))
 #define ssa_name(i) ((*cfun->gimple_df->ssa_names)[(i)])
 
-
-/* Type of value ranges.  See value_range_d In tree-vrp.c for a
-   description of these types.  */
-enum value_range_type { VR_UNDEFINED, VR_RANGE, VR_ANTI_RANGE, VR_VARYING };
-
 /* Sets the value range to SSA.  */
 extern void set_range_info (tree, enum value_range_type, const wide_int_ref &,
 			const wide_int_ref &);
diff --git a/gcc/tree-vrp.c b/gcc/tree-vrp.c
index edaacf2..a318d39 100644
--- a/gcc/tree-vrp.c
+++ b/gcc/tree-vrp.c
@@ -59,32 +59,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "target.h"
 #include "case-cfn-macros.h"
 #include "alloc-pool.h"
-
-/* Range of values that can be associated with an SSA_NAME after VRP
-   has executed.  */
-struct value_range
-{
-  /* Lattice value represented by this range.  */
-  enum value_range_type type;
-
-  /* Minimum and maximum values represented by this range.  These
- values should be interpreted as follows:
-
-	- If TYPE is VR_UNDEFINED or VR_VARYING then MIN and MAX must
-	  be NULL.
-
-	- If TYPE == VR_RANGE then MIN holds the minimum value and
-	  MAX holds the maximum value of the range [MIN, MAX].
-
-	- If TYPE == ANTI_RANGE the variable is known to NOT
-	  take any values in the range [MIN, MAX].  */
-  tree min;
-  tree max;
-
-  /* Set of SSA names whose value ranges are equivalent to this one.
- This set is only valid when TYPE is VR_RANGE or VR_ANTI_RANGE.  */
-  bitmap equiv;
-};
+#include "tree-vrp.h"
 
 #define VR_INITIALIZER { VR_UNDEFINED, NULL_TREE, NULL_TREE, NULL }
 
@@ -108,8 +83,6 @@ live_on_edge (edge e, tree name)
 /* Local functions.  */
 static int compare_values (tree val1, tree val2);
 static int compare_values_warnv (tree val1, tree val2, bool *);
-static void vrp_meet (value_range *, value_range *);
-static void vrp_intersect_ranges (value_range *, value_range *);
 static tree vrp_evaluate_conditional_warnv_with_ops (enum tree_code,
 		 tree, tree, bool, bool *,
 		 bool *);
@@ -4605,7 +4578,7 @@ compare_range_with_value (enum tree_code comp, value_range *vr, tree val,
 
 /* Debugging dumps.  */
 
-void dump_value_range (FILE *, value_range *);
+void dump_value_range (FILE *, const value_range *);
 void debug_value_range (value_range *);
 void dump_all_value_ranges (FILE *);
 void debug_all_value_ranges (void);
@@ -4616,7 +4589,7 @@ void debug_vr_equiv (bitmap);
 /* Dump value range VR to FILE.  */
 
 void
-dump_value_range (FILE *file, value_range *vr)
+dump_value_range (FILE *file, const value_range *vr)
 {
   if (vr == NULL)
 fprintf (file, "[]");
@@ -8447,7 +8420,7 @@ intersect_ranges (enum value_range_type *vr0type,
 /* Intersect the two value-ranges *VR0 and *VR1 and store the result
in *VR0.  This may not be the smallest possible such range.  */
 
-static void
+void
 vrp_intersect_ranges_1 (value_range *vr0, value_range *vr1)
 {
   value_range saved;
@@ -8499,7 +8472,7 @@ vrp_intersect_ranges_1 (value_range *vr0, value_range *vr1)
 bitmap_copy (vr0->equiv, vr1->equiv);
 }
 
-static void
+void
 vrp_intersect_ranges (value_range *vr0, value_range *vr1)
 {
   if (dump_file && (dump_flags & TDF_DETAILS))
@@ -8524,7 +8497,7 @@ vrp_intersect_ranges (value_range *vr0, value_range *vr1)
may not be the smallest possible such range.  */
 
 static void
-vrp_meet_

Re: [PATCH] Fix unsafe function attributes for special functions (PR 71876)

[Richard Biener]

On Thu, 21 Jul 2016, Bernd Edlinger wrote:

> Hi,
> 
> based on the discussion here, I have updated my patch again...
> 
> This is the rest of the patch, which removes outdated function names,
> and creates built-in definitions for vfork, getcontext, savectx.
> These built-ins have the return_twice attribute but not the
> leaf attribute, because we do not really know, what these functions
> do.
> 
> The reason for ceating the builtin functions is, that I would like
> to get a warning about conflicting builtin definition if someone
> accidentally picks the name of one of these less well known special
> functions, which are _not_ reserved names in most environments.
> 
> I do not define builtins (without __builtin_ prefix) for setjmp and
> sigsetjmp because these are like wildcards, and they fall in the
> well-known category anyways.
> 
> I still retain the handling of these functions in special_function_p
> because even in a free standing environment, returning
> ECF_RETURNS_TWICE is on the safe side.
> 
> 
> 
> Is it OK for trunk after boot-strap and regression-testing?

As DEF_EXT_LIB_BUILTIN won't have any effect with -std=c99 for example
I don't think having the builtins helps much.  I think we have
this name-matching function for correctness purposes (and even my
local glibc doesn't declare [v]fork as returning twice nor does
the existing BUILT_IN_FORK btw).

So please simply leave special_function_p as-is, and simply just
return the for-correctness flags - ECF_RETURNS_TWICE and 
ECF_MAY_BE_ALLOCA.

I think all callers but flags_from_decl_or_type should vanish
(calling that function instead).

Richard.

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

Re: [PATCH] Fix unsafe function attributes for special functions (PR 71876)

[Jakub Jelinek]

On Fri, Jul 22, 2016 at 02:28:15PM +0200, Richard Biener wrote:
> As DEF_EXT_LIB_BUILTIN won't have any effect with -std=c99 for example
> I don't think having the builtins helps much.  I think we have

Well, -std=gnu11 is the default, so it will help.

Jakub

Re: [PATCH] Fix early debug regression with DW_AT_string_length (PR debug/71906)

[Richard Biener]

On Fri, Jul 22, 2016 at 2:08 PM, Jakub Jelinek  wrote:
> On Fri, Jul 22, 2016 at 01:55:22PM +0200, Richard Biener wrote:
>> > @@ -19201,18 +19205,70 @@ gen_array_type_die (tree type, dw_die_re
>> >if (size >= 0)
>> > add_AT_unsigned (array_die, DW_AT_byte_size, size);
>> >else if (TYPE_DOMAIN (type) != NULL_TREE
>> > -  && TYPE_MAX_VALUE (TYPE_DOMAIN (type)) != NULL_TREE
>> > -  && DECL_P (TYPE_MAX_VALUE (TYPE_DOMAIN (type
>> > +  && TYPE_MAX_VALUE (TYPE_DOMAIN (type)) != NULL_TREE)
>> > {
>> >   tree szdecl = TYPE_MAX_VALUE (TYPE_DOMAIN (type));
>> > - dw_loc_list_ref loc = loc_list_from_tree (szdecl, 2, NULL);
>> > + tree rszdecl = szdecl;
>> > + HOST_WIDE_INT rsize = 0;
>> >
>> >   size = int_size_in_bytes (TREE_TYPE (szdecl));
>> > - if (loc && size > 0)
>> > + if (!DECL_P (szdecl))
>> > {
>> > - add_AT_location_description (array_die, DW_AT_string_length, 
>> > loc);
>> > - if (size != DWARF2_ADDR_SIZE)
>> > -   add_AT_unsigned (array_die, DW_AT_byte_size, size);
>> > + if (TREE_CODE (szdecl) == INDIRECT_REF
>>
>> So I wonder how this can happen with variable-size type
>> gimplification.  Shouldn't
>> this be on, say, DECL_VALUE_EXPR of the DECL_P TYPE_MAX_VALUE?
>
> If you mean the INDIRECT_REF, that only happens with PARM_DECLs, and
> conceptually a dereference of the argument is the right spot where the
> length lives (if you reallocate the string with different character length,
> then that is where you store the value.  If you add some artificial
> decl that will hold the value of *_varb, then the trouble is that the
> variable won't be assigned before the function prologue and most likely will
> be optimized away anyway.

True.  I wonder how other cases look like with the length not based on a
parameter.

>>  <1><28d>: Abbrev Number: 19 (DW_TAG_string_type)
>>  <1><28e>: Abbrev Number: 19 (DW_TAG_string_type)
>>  <1><28f>: Abbrev Number: 6 (DW_TAG_pointer_type)
>>
>> so there is nothing to annotate with a location later.
>
> With the patch there will be DW_OP_call4 in 2 DW_AT_string_length
> attributes and one DW_OP_call4; DW_OP_deref.
>
>> Note that even with GCC 5 'varb' didn't get a DW_AT_string_length,
>> 'vara' did, though.
>
> Yeah, I've mentioned that in the mail.
>
> Jakub

Re: [PATCH] Fix unsafe function attributes for special functions (PR 71876)

[Bernd Edlinger]

On 07/21/16 23:57, Bernd Edlinger wrote:
> Hi,
>
> based on the discussion here, I have updated my patch again...
>
> This is the rest of the patch, which removes outdated function names,
> and creates built-in definitions for vfork, getcontext, savectx.
> These built-ins have the return_twice attribute but not the
> leaf attribute, because we do not really know, what these functions
> do.
>
> The reason for ceating the builtin functions is, that I would like
> to get a warning about conflicting builtin definition if someone
> accidentally picks the name of one of these less well known special
> functions, which are _not_ reserved names in most environments.
>
> I do not define builtins (without __builtin_ prefix) for setjmp and
> sigsetjmp because these are like wildcards, and they fall in the
> well-known category anyways.
>
> I still retain the handling of these functions in special_function_p
> because even in a free standing environment, returning
> ECF_RETURNS_TWICE is on the safe side.
>
>
>
> Is it OK for trunk after boot-strap and regression-testing?
>


Hmm, cough...

Boot-strap and reg-test was OK, but...

I just noticed that the new built-ins do not quite work as expected.

First with C++ there is no warning in this example although the
parameters are different:

cat test2.C
extern "C"
void savectx   () __attribute__((nothrow));

int test () throw()
{
   savectx ();
   return 0;
}


and what I do not understand at all in the moment, is:
although both the builtin and the explict header say
"nothrow" there is still eh code emitted that was not
there before.

So I would like to split that patch again, in the
cleanup of special_function_p and drop the new built-ins
in the moment, until I understand what went wrong there.
The built-in were just meant to bring up warnings, and
are therefore less important.


Sorry for all the iterations this took already :(

So here is the next version of the patch that I am gonna try.


Is it OK for trunk?


Thanks
Bernd.
2016-07-21  Bernd Edlinger  

	PR middle-end/71876
	* calls.c (special_function_p): Remove special handling of
	"setjmp_syscall", "qsetjmp", "longjmp", "siglongjmp" and the
	prefix "__x".  Recognize "savectx", "vfork" and "getcontext" only
	without prefix.  Remove potentially unsafe ECF_LEAF and ECF_NORETURN.

Index: gcc/calls.c
===
--- gcc/calls.c	(Revision 238611)
+++ gcc/calls.c	(Arbeitskopie)
@@ -468,15 +468,13 @@
 anti_adjust_stack (GEN_INT (n_popped));
 }
 
-/* Determine if the function identified by NAME and FNDECL is one with
-   special properties we wish to know about.
+/* Determine if the function identified by FNDECL is one with
+   special properties we wish to know about.  Modify FLAGS accordingly.
 
For example, if the function might return more than one time (setjmp), then
-   set RETURNS_TWICE to a nonzero value.
+   set ECF_RETURNS_TWICE.
 
-   Similarly set NORETURN if the function is in the longjmp family.
-
-   Set MAY_BE_ALLOCA for any memory allocation function that might allocate
+   Set ECF_MAY_BE_ALLOCA for any memory allocation function that might allocate
space from the stack such as alloca.  */
 
 static int
@@ -491,7 +489,7 @@
 name_decl = DECL_NAME (cgraph_node::get (fndecl)->orig_decl);
 
   if (fndecl && name_decl
-  && IDENTIFIER_LENGTH (name_decl) <= 17
+  && IDENTIFIER_LENGTH (name_decl) <= 11
   /* Exclude functions not at the file scope, or not `extern',
 	 since they are not the magic functions we would otherwise
 	 think they are.
@@ -514,43 +512,22 @@
 	  && ! strcmp (name, "alloca"))
 	flags |= ECF_MAY_BE_ALLOCA;
 
-  /* Disregard prefix _, __ or __x.  */
+  /* Disregard prefix _ or __.  */
   if (name[0] == '_')
 	{
-	  if (name[1] == '_' && name[2] == 'x')
-	tname += 3;
-	  else if (name[1] == '_')
+	  if (name[1] == '_')
 	tname += 2;
 	  else
 	tname += 1;
 	}
 
-  if (tname[0] == 's')
-	{
-	  if ((tname[1] == 'e'
-	   && (! strcmp (tname, "setjmp")
-		   || ! strcmp (tname, "setjmp_syscall")))
-	  || (tname[1] == 'i'
-		  && ! strcmp (tname, "sigsetjmp"))
-	  || (tname[1] == 'a'
-		  && ! strcmp (tname, "savectx")))
-	flags |= ECF_RETURNS_TWICE | ECF_LEAF;
-
-	  if (tname[1] == 'i'
-	  && ! strcmp (tname, "siglongjmp"))
-	flags |= ECF_NORETURN;
-	}
-  else if ((tname[0] == 'q' && tname[1] == 's'
-		&& ! strcmp (tname, "qsetjmp"))
-	   || (tname[0] == 'v' && tname[1] == 'f'
-		   && ! strcmp (tname, "vfork"))
-	   || (tname[0] == 'g' && tname[1] == 'e'
-		   && !strcmp (tname, "getcontext")))
-	flags |= ECF_RETURNS_TWICE | ECF_LEAF;
-
-  else if (tname[0] == 'l' && tname[1] == 'o'
-	   && ! strcmp (tname, "longjmp"))
-	flags |= ECF_NORETURN;
+  /* ECF_RETURNS_TWICE is safe even for -ffreestanding.  */
+  if (! strcmp (tname, "setjmp")
+	  || ! strcmp (tname, "sigsetjmp")
+	  || ! strcmp (name, "savectx")
+	  || ! strcmp (name, "vfork"

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

[Richard Biener]

On Fri, Jul 22, 2016 at 2:27 PM, kugan
 wrote:
> Hi,
>
> Now that early vrp is moved as part of tree-vrp, there is only minimal
> interface tree-vrp should expose for ipa-vrp. However, I have not found the
> right place to place struct value_range (with GTY marker) and enum
> value_range_type.
>
> enum value_range_type is needed in tree-ssanames.[h|c] and in all the places
> where get|set_range_info is used.
>
> struct value_range is needed in ipa-prop.h, therefore all the places
> ipa-prop.h is included.
>
> One option is to place it in tree-vrp.h and expose this to GTY
> infrastructure. Then include it in all the places we need any of these
> types. It is in lots of c files.
>
> I have now placed both in tree.h. Even though that compiles, I am not
> convinced that is the right place.

I'm convinced it is not ;)

As we had value_range_type in tree-ssanames.h why not put value_range there?

Or simply put value_range into tree-vrp.h and leave value_range_type
where it is.

You no longer export vrp_finalize so no need to change it.

> I would appreciate comment/preferences in this regard. I am also attaching
> the current version of this patch for review. I will update it based on the
> comments.

Richard.

> Thanks,
> Kugan
>
>
>

Re: [PATCH] rs6000: Fix logic for when to emit .machine (PR71216)

[David Edelsohn]

On Fri, Jul 22, 2016 at 4:36 AM, Segher Boessenkool
 wrote:
> The current logic determining whether to use .machine in the generated
> asm code puts it there if the compiler is not configured with a default
> target cpu, _or_ no -mcpu= was given on the command line.  It should
> be "and" instead.
>
> Tested on powerpc64-linux (-m32 as well).  Also tested manually with
> the testcase in the PR (not included in the patch, it depends on your GCC
> configuration).
>
> Is this okay for trunk?  And backports later?
>
>
> Segher
>
>
> 2016-07-22  Segher Boessenkool  
>
> * config/rs6000/rs6000.c (rs6000_file_start): Fix condition for
> when to emit a ".machine" pseudo-op.

Okay.

Thanks, David

Re: [PATCH] Fix unsafe function attributes for special functions (PR 71876)

[Bernd Edlinger]

On 07/22/16 14:28, Richard Biener wrote:
> On Thu, 21 Jul 2016, Bernd Edlinger wrote:
>
>> Hi,
>>
>> based on the discussion here, I have updated my patch again...
>>
>> This is the rest of the patch, which removes outdated function names,
>> and creates built-in definitions for vfork, getcontext, savectx.
>> These built-ins have the return_twice attribute but not the
>> leaf attribute, because we do not really know, what these functions
>> do.
>>
>> The reason for ceating the builtin functions is, that I would like
>> to get a warning about conflicting builtin definition if someone
>> accidentally picks the name of one of these less well known special
>> functions, which are _not_ reserved names in most environments.
>>
>> I do not define builtins (without __builtin_ prefix) for setjmp and
>> sigsetjmp because these are like wildcards, and they fall in the
>> well-known category anyways.
>>
>> I still retain the handling of these functions in special_function_p
>> because even in a free standing environment, returning
>> ECF_RETURNS_TWICE is on the safe side.
>>
>>
>>
>> Is it OK for trunk after boot-strap and regression-testing?
>
> As DEF_EXT_LIB_BUILTIN won't have any effect with -std=c99 for example
> I don't think having the builtins helps much.  I think we have
> this name-matching function for correctness purposes (and even my
> local glibc doesn't declare [v]fork as returning twice nor does
> the existing BUILT_IN_FORK btw).
>

fork does not have to, but it is a no-leaf function because it
calls pthread_atfork handlers.  So it has to be __TROWNL.

I think in the long run the header files just should be fixed.
But that will take a while...


Bernd.

Re: Merge switch statements in tree-cfgcleanup

[Richard Biener]

On Wed, Jul 20, 2016 at 6:26 PM, Bernd Schmidt  wrote:
> On 07/20/2016 06:09 PM, Jeff Law wrote:
>>
>> So I'm going to let Richi run with the review on this one since the two
>> of you are already iterating.  But I did have one comment on the
>> placement of the pass.
>>
>> I believe one of the key things to consider for whether or not something
>> like this belongs in the cfgcleanup code is whether or not the
>> optimization is likely exposed repeatedly through the optimization
>> pipeline.  If it's mostly a source level issue or only usually exposed
>> by a limited set of optimizers, then a separate pass might be better.
>
>
> It can trigger before switchconv, and could expose optimization
> opportunities there, but I've also seen it trigger much later. Since I think
> it's cheap I don't see a reason not to put it in cfgcleanup, IMO it's the
> best fit conceptually.

I'm not convinced.  We do have CFG matching passes like phi-opt,
if-combine.  With your logic even simple jump-threading like
if (a) if (a) ... would be a job for CFG cleanup?

+  gsi2 = gsi_start_nondebug_after_labels_bb (bb);
+  if (gsi_end_p (gsi2))
+return false;
+
+  gimple *stmt = gsi_stmt (gsi2);
+  if (gimple_code (stmt) != GIMPLE_SWITCH)
+return false;

  stmt = last_stmt (bb);
  if (!stmt || gimple_code (stmt) != GIMPLE_SWITHC)
return false;

is shorter and has the same effect.

+  edge e;
+  edge_iterator ei;
+  FOR_EACH_EDGE (e, ei, bb->succs)
+{
+  basic_block dest = e->dest;
+  if (find_edge (pred_bb, dest))
+   {
+ /* If a destination block is reached from both switches, any
+phi nodes there would become corrupted.  */
+ gphi_iterator psi = gsi_start_phis (dest);
+ if (!gsi_end_p (psi))
+   return false;
+   }
+}

I wonder if this tests all required blocks.  Why can't there be a forwarder
between pred_bb and dest for example?  I think you want sth like

 if (! dominated_by_p (CDI_DOMINATORS, dest, bb))
   ... verify no PHIs ...


+  auto_vec new_labels;
+

please pre-reserve enough space to hold labels from both switches
and use quick_push below.

+  /* Merge adjacent ranges.  */
+  size_t new_count = new_labels.length ();
+  for (i1 = i2 = 1; i1 < new_count; )
+{
+  ce1 = new_labels[i1++];
+  tree high = CASE_HIGH (ce1);
+  if (high == NULL_TREE)
+   high = CASE_LOW (ce1);
+  while (i1 < new_count)
+   {
+ ce2 = new_labels[i1];

what about re-using the code from tree-cfg.c instead?  (group_case_labels_stmt)

+  if (dom_info_available_p (CDI_DOMINATORS))

I think DOM info is always available during CFG cleanup

+{
+  basic_block dombb = get_immediate_dominator (CDI_DOMINATORS, bb);
+  gcc_assert (dombb == pred_bb);
+  vec fix_bbs;
+  fix_bbs = get_all_dominated_blocks (CDI_DOMINATORS, pred_bb);
+  iterate_fix_dominators (CDI_DOMINATORS, fix_bbs, false);
+  fix_bbs.release ();
+}


Richard.

>
> Bernd
>

Re: [PATCH] Adapt the numbering scheme (PR gcov-profile/64874)

[Jakub Jelinek]

On Fri, Jul 22, 2016 at 01:46:44PM +0200, Martin Liška wrote:
> As described in the PR, current numbering scheme in gcov-io.h would overflow 
> in couple of years.
> Thus, I'm suggesting to switch from:
> 
> [major][minor/10][minor%10][release_status]
> 
> to:
> [major/10][major%10][minor][release_status]
> 
> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.

Won't this clash with the already released versions?
Unless you start e.g. using different release_status letters from the past
(but that is complicated with vendor supplied DEV-PHASE), won't
say gcc 3.4.0 and gcc 30.4.1 have the same string?

Wouldn't it be better to just use letters for the major/10?  As GCC major
didn't reach 10 yet, we only had [0-9][0-9][0-9]. in the past, so I think:

-  v[0] = (major < 10 ? '0' : 'A' - 10) + major;
-  v[1] = (minor / 10) + '0';
-  v[2] = (minor % 10) + '0';
+  v[0] = (major / 10) + 'A';
+  v[1] = (major % 10) + '0';
+  v[2] = minor + '0';

would be better, then there will be no clash, and the versioning scheme will
allow until 259.9.

Jakub

[PATCH] Add a STATIC_ASSERT on sizeof (struct cp_token)

[David Malcolm]

On Fri, 2016-07-22 at 13:06 +0200, Jakub Jelinek wrote:
> On Fri, Jul 22, 2016 at 12:44:07PM +0200, Marek Polacek wrote:
> > --- gcc/gcc/cp/parser.h
> > +++ gcc/gcc/cp/parser.h
> > @@ -46,7 +46,7 @@ struct GTY (()) cp_token {
> >   Otherwise, this value is RID_MAX.  */
> >ENUM_BITFIELD (rid) keyword : 8;
> >/* Token flags.  */
> > -  unsigned char flags;
> > +  unsigned short flags;
> >/* True if this token is from a context where it is implicitly
> > extern "C" */
> >BOOL_BITFIELD implicit_extern_c : 1;
> >/* True if an error has already been reported for this token,
> > such as a
> 
> I'm afraid this is really bad.
> Right now, there are 8 and 8 bit bitfields, then 8-bit char, 3
> individual
> bits, 5 unused bits and 32-bit int, nicely packed into 64-bit word
> before a
> union with pointer members, and the C++ FE lexes everything first, so
> there
> are possibly millions of tokens in memory.
> Can't you just make it unsigned int flags : 11; instead?  Or instead
> reshuffle the cpplib.h flags?  E.g. I don't see the C++ FE to use the
> NO_EXPAND flag, so moving it to the upper byte of the short and
> moving the
> new flag to its bit?  Perhaps that is even better for now

Would something like this be appropriate, if it bootstraps?

gcc/cp/ChangeLog:
* parser.h (struct cp_token): Add a STATIC_ASSERT on the
size of the struct.
---
 gcc/cp/parser.h | 9 +
 1 file changed, 9 insertions(+)

diff --git a/gcc/cp/parser.h b/gcc/cp/parser.h
index ccbace9..8c1de57 100644
--- a/gcc/cp/parser.h
+++ b/gcc/cp/parser.h
@@ -71,6 +71,15 @@ struct GTY (()) cp_token {
   "|| (%1.type == CPP_DECLTYPE)"))) u;
 };
 
+/* The C++ frontend lexes everything first, and keeps the tokens
+   in memory, so there are possibly millions of tokens in memory.
+   Ensure that we don't accidentally grow the structure.  */
+STATIC_ASSERT (sizeof (cp_token) ==
+  (2 // "type" and "keyword"
+   + 1 // "flags"
+   + 1 // bitfields
+   + 4 // location_t
+   + sizeof (void *))); // union
 
 /* We use a stack of token pointer for saving token sets.  */
 typedef struct cp_token *cp_token_position;
-- 
1.8.5.3

Re: [PATCH] Add a STATIC_ASSERT on sizeof (struct cp_token)

[Jakub Jelinek]

On Fri, Jul 22, 2016 at 10:33:50AM -0400, David Malcolm wrote:
> gcc/cp/ChangeLog:
>   * parser.h (struct cp_token): Add a STATIC_ASSERT on the
>   size of the struct.
> ---
>  gcc/cp/parser.h | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/gcc/cp/parser.h b/gcc/cp/parser.h
> index ccbace9..8c1de57 100644
> --- a/gcc/cp/parser.h
> +++ b/gcc/cp/parser.h
> @@ -71,6 +71,15 @@ struct GTY (()) cp_token {
>  "|| (%1.type == CPP_DECLTYPE)"))) u;
>  };
>  
> +/* The C++ frontend lexes everything first, and keeps the tokens
> +   in memory, so there are possibly millions of tokens in memory.
> +   Ensure that we don't accidentally grow the structure.  */
> +STATIC_ASSERT (sizeof (cp_token) ==
> +(2 // "type" and "keyword"
> + + 1 // "flags"
> + + 1 // bitfields
> + + 4 // location_t
> + + sizeof (void *))); // union

Doesn't that assume way too much on the host data layout?
This can be compiled with weirdo system compilers or on weirdo hosts,
I bet we don't really support non-8-bit char hosts, but still this might
break somewhere...

The formatting is wrong BTW, == shouldn't appear at the end of line.

Jakub

[PATCH]: A couple of remaining conversions to HOST_WIDE_INT_{,M}1{,U}

[Uros Bizjak]

c/ChangeLog:

2016-07-22  Uros Bizjak  

* c-typeck.c: Use HOST_WIDE_INT_1 instead of (HOST_WIDE_INT) 1,

c-family/ChangeLog:

2016-07-22  Uros Bizjak  

* c-common.c: Use HOST_WIDE_INT_M1U instead of
~(unsigned HOST_WIDE_INT) 0.

Bootstrapped and regression tested on x86_64-linux-gnu, committed to
mainline SVN.

Uros.
Index: gcc/c/c-typeck.c
===
--- gcc/c/c-typeck.c(revision 238642)
+++ gcc/c/c-typeck.c(working copy)
@@ -8594,7 +8594,7 @@ set_nonincremental_init_from_string (tree str,
  bitpos = ((wchar_bytes - 1) * charwidth) + HOST_BITS_PER_CHAR;
  if (bitpos < HOST_BITS_PER_WIDE_INT)
{
- if (val[0] & (((HOST_WIDE_INT) 1) << (bitpos - 1)))
+ if (val[0] & (HOST_WIDE_INT_1 << (bitpos - 1)))
{
  val[0] |= HOST_WIDE_INT_M1U << bitpos;
  val[1] = -1;
@@ -8605,7 +8605,7 @@ set_nonincremental_init_from_string (tree str,
  if (val[0] < 0)
val[1] = -1;
}
- else if (val[1] & (((HOST_WIDE_INT) 1)
+ else if (val[1] & (HOST_WIDE_INT_1
 << (bitpos - 1 - HOST_BITS_PER_WIDE_INT)))
val[1] |= HOST_WIDE_INT_M1U << (bitpos - HOST_BITS_PER_WIDE_INT);
}
Index: gcc/c-family/c-common.c
===
--- gcc/c-family/c-common.c (revision 238642)
+++ gcc/c-family/c-common.c (working copy)
@@ -11999,7 +11999,7 @@ warn_for_sign_compare (location_t location,
   if (bits < TYPE_PRECISION (result_type)
   && bits < HOST_BITS_PER_LONG && unsignedp)
 {
-  mask = (~ (unsigned HOST_WIDE_INT) 0) << bits;
+  mask = HOST_WIDE_INT_M1U << bits;
   if ((mask & constant) != mask)
{
  if (constant == 0)

Re: Rework C/C++ OpenACC routine parsing (was: C/C++: Simplify handling of location information for OpenACC routine directives)

[Jakub Jelinek]

On Wed, Jul 13, 2016 at 04:10:31PM +0200, Thomas Schwinge wrote:
> @@ -14029,29 +14032,32 @@ c_parser_oacc_kernels_parallel (location_t loc, 
> c_parser *parser,
>  static void
>  c_parser_oacc_routine (c_parser *parser, enum pragma_context context)
>  {
> -  tree decl = NULL_TREE;
> +  gcc_checking_assert (context == pragma_external);
> +
>oacc_routine_data data;
> +  data.error_seen = false;
> +  data.fndecl_seen = false;
>data.clauses = NULL_TREE;
>data.loc = c_parser_peek_token (parser)->location;
> -  
> -  if (context != pragma_external)
> -c_parser_error (parser, "%<#pragma acc routine%> not at file scope");
>  
>c_parser_consume_pragma (parser);
>  
> -  /* Scan for optional '( name )'.  */
> +  /* Look for optional '( name )'.  */
>if (c_parser_peek_token (parser)->type == CPP_OPEN_PAREN)

Can you please change this to
  if (c_parser_next_token_is (parser, CPP_OPEN_PAREN))
?
Ok for trunk with that change.

Jakub

Patch ping

[Cesar Philippidis]

The following patches still need to be reviewed:

* Change an LTO wrapper assert failure to an error when it detects
  missing symbols. This situation can arise in offloading code, e.g.
  when the user forgets to declare a global variable as offloadable.

  https://gcc.gnu.org/ml/gcc-patches/2016-07/msg00043.html

* Add support for OpenACC routine clauses in fortran modules. Also,
  allow the routine directive to be applied to intrinsic procedures.

  https://gcc.gnu.org/ml/gcc-patches/2016-07/msg00063.html

Thanks,
Cesar

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

[kugan]

Hi Richard,

Thanks for the review.

On 22/07/16 22:49, Richard Biener wrote:

On Fri, Jul 22, 2016 at 2:27 PM, kugan
 wrote:

Hi,

Now that early vrp is moved as part of tree-vrp, there is only minimal
interface tree-vrp should expose for ipa-vrp. However, I have not found the
right place to place struct value_range (with GTY marker) and enum
value_range_type.

enum value_range_type is needed in tree-ssanames.[h|c] and in all the places
where get|set_range_info is used.

struct value_range is needed in ipa-prop.h, therefore all the places
ipa-prop.h is included.

One option is to place it in tree-vrp.h and expose this to GTY
infrastructure. Then include it in all the places we need any of these
types. It is in lots of c files.

I have now placed both in tree.h. Even though that compiles, I am not
convinced that is the right place.


I'm convinced it is not ;)


I totally agree. I just kept it their for the time being.



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 ?



Or simply put value_range into tree-vrp.h and leave value_range_type
where it is.


In this case, we will have to add tree-vrp.h and tree-ssanames.h in 
those places.


You no longer export vrp_finalize so no need to change it.


Thanks,
Kugan

>From f75f2f836238e2e65615bec7ea2ce3a31257e204 Mon Sep 17 00:00:00 2001
From: Kugan Vivekanandarajah 
Date: Tue, 21 Jun 2016 12:42:44 +1000
Subject: [PATCH 4/7] Refactor vrp

---
 gcc/cgraph.c   |  2 ++
 gcc/cgraphunit.c   |  1 +
 gcc/ipa-cp.c   |  3 +++
 gcc/ipa-devirt.c   |  2 ++
 gcc/ipa-inline-transform.c |  3 +++
 gcc/ipa-inline.c   |  2 ++
 gcc/ipa-profile.c  |  2 ++
 gcc/ipa-utils.c|  2 ++
 gcc/ipa.c  |  1 +
 gcc/lto/lto-partition.c|  1 +
 gcc/lto/lto.c  |  2 ++
 gcc/toplev.c   |  2 ++
 gcc/trans-mem.c|  1 +
 gcc/tree-ssanames.h| 29 ++-
 gcc/tree-vrp.c | 50 +++---
 gcc/tree-vrp.h | 23 +
 16 files changed, 87 insertions(+), 39 deletions(-)
 create mode 100644 gcc/tree-vrp.h

diff --git a/gcc/cgraph.c b/gcc/cgraph.c
index e256dd0..01fbf5e 100644
--- a/gcc/cgraph.c
+++ b/gcc/cgraph.c
@@ -49,6 +49,8 @@ along with GCC; see the file COPYING3.  If not see
 #include "value-prof.h"
 #include "ipa-utils.h"
 #include "symbol-summary.h"
+#include "stringpool.h"
+#include "tree-ssanames.h"
 #include "ipa-prop.h"
 #include "ipa-inline.h"
 #include "cfgloop.h"
diff --git a/gcc/cgraphunit.c b/gcc/cgraphunit.c
index 4bfcad7..bf85356 100644
--- a/gcc/cgraphunit.c
+++ b/gcc/cgraphunit.c
@@ -190,6 +190,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "toplev.h"
 #include "debug.h"
 #include "symbol-summary.h"
+#include "tree-ssanames.h"
 #include "ipa-prop.h"
 #include "gimple-pretty-print.h"
 #include "plugin.h"
diff --git a/gcc/ipa-cp.c b/gcc/ipa-cp.c
index 4b7f6bb..7e08a31 100644
--- a/gcc/ipa-cp.c
+++ b/gcc/ipa-cp.c
@@ -114,6 +114,9 @@ along with GCC; see the file COPYING3.  If not see
 #include "fold-const.h"
 #include "gimple-fold.h"
 #include "symbol-summary.h"
+#include "tree-ssa-alias.h"
+#include "stringpool.h"
+#include "tree-ssanames.h"
 #include "ipa-prop.h"
 #include "tree-pretty-print.h"
 #include "tree-inline.h"
diff --git a/gcc/ipa-devirt.c b/gcc/ipa-devirt.c
index 2cf018b..cdc539c 100644
--- a/gcc/ipa-devirt.c
+++ b/gcc/ipa-devirt.c
@@ -122,6 +122,8 @@ along with GCC; see the file COPYING3.  If not see
 #include "ipa-utils.h"
 #include "gimple-fold.h"
 #include "symbol-summary.h"
+#include "stringpool.h"
+#include "tree-ssanames.h"
 #include "ipa-prop.h"
 #include "ipa-inline.h"
 #include "demangle.h"
diff --git a/gcc/ipa-inline-transform.c b/gcc/ipa-inline-transform.c
index f6b7d41..ea7c9c7 100644
--- a/gcc/ipa-inline-transform.c
+++ b/gcc/ipa-inline-transform.c
@@ -39,6 +39,9 @@ along with GCC; see the file COPYING3.  If not see
 #include "cgraph.h"
 #include "tree-cfg.h"
 #include "symbol-summary.h"
+#include "tree-ssa-alias.h"
+#include "stringpool.h"
+#include "tree-ssanames.h"
 #include "ipa-prop.h"
 #include "ipa-inline.h"
 #include "tree-inline.h"
diff --git a/gcc/ipa-inline.c b/gcc/ipa-inline.c
index 5c9366a..3eac298 100644
--- a/gcc/ipa-inline.c
+++ b/gcc/ipa-inline.c
@@ -108,6 +108,8 @@ along with GCC; see the file COPYING3.  If not see
 #include "params.h"
 #include "profile.h"
 #include "symbol-summary.h"
+#include "stringpool.h"
+#include "tree-ssanames.h"
 #include "ipa-prop.h"
 #include "ipa-inline.h"
 #include "ipa-utils.h"
diff --git a/gcc/ipa-profile.c b/gcc/ipa-profile.c
index da17bcd..e43c3c9 100644
--

[PATCH] Move allocator in std::string and RB tree move constructors

[Jonathan Wakely]

The move constructors for strings and RB trees were not move
constructing the allocator.

PR libstdc++/71964
* include/bits/basic_string.h [_GLIBCXX_USE_CXX11_ABI]
(basic_string::_Alloc_hider(pointer, _Alloc&&)): Add constructor.
* include/bits/stl_tree.h (_Rb_tree(_Rb_tree&&)): Move allocator.
* testsuite/21_strings/basic_string/allocator/71964.cc: New test.
* testsuite/23_containers/set/allocator/71964.cc: New test.

Tested powerpc64-linux, committed to trunk. I will backport this to
gcc-5 and gcc-6 too, but probably not 4.9 as the branch is about to be
closed.

commit 8ac696266745e7f735d1921edb95fc1d78f46c0b
Author: redi 
Date:   Fri Jul 22 15:03:11 2016 +

Move allocator in std::string and RB tree move constructors

PR libstdc++/71964
* include/bits/basic_string.h [_GLIBCXX_USE_CXX11_ABI]
(basic_string::_Alloc_hider(pointer, _Alloc&&)): Add constructor.
* include/bits/stl_tree.h (_Rb_tree(_Rb_tree&&)): Move allocator.
* testsuite/21_strings/basic_string/allocator/71964.cc: New test.
* testsuite/23_containers/set/allocator/71964.cc: New test.

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

diff --git a/libstdc++-v3/include/bits/basic_string.h 
b/libstdc++-v3/include/bits/basic_string.h
index 60e1dbf..58d6e4d 100644
--- a/libstdc++-v3/include/bits/basic_string.h
+++ b/libstdc++-v3/include/bits/basic_string.h
@@ -106,8 +106,16 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
   // Use empty-base optimization: http://www.cantrip.org/emptyopt.html
   struct _Alloc_hider : allocator_type // TODO check __is_final
   {
+#if __cplusplus < 201103L
_Alloc_hider(pointer __dat, const _Alloc& __a = _Alloc())
: allocator_type(__a), _M_p(__dat) { }
+#else
+   _Alloc_hider(pointer __dat, const _Alloc& __a)
+   : allocator_type(__a), _M_p(__dat) { }
+
+   _Alloc_hider(pointer __dat, _Alloc&& __a = _Alloc())
+   : allocator_type(std::move(__a)), _M_p(__dat) { }
+#endif
 
pointer _M_p; // The actual data.
   };
diff --git a/libstdc++-v3/include/bits/stl_tree.h 
b/libstdc++-v3/include/bits/stl_tree.h
index a9ca3fa..7a9a4a6 100644
--- a/libstdc++-v3/include/bits/stl_tree.h
+++ b/libstdc++-v3/include/bits/stl_tree.h
@@ -851,7 +851,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   }
 
   _Rb_tree(_Rb_tree&& __x)
-  : _M_impl(__x._M_impl._M_key_compare, __x._M_get_Node_allocator())
+  : _M_impl(__x._M_impl._M_key_compare,
+   std::move(__x._M_get_Node_allocator()))
   {
if (__x._M_root() != 0)
  _M_move_data(__x, std::true_type());
diff --git a/libstdc++-v3/testsuite/21_strings/basic_string/allocator/71964.cc 
b/libstdc++-v3/testsuite/21_strings/basic_string/allocator/71964.cc
new file mode 100644
index 000..ebb66cf
--- /dev/null
+++ b/libstdc++-v3/testsuite/21_strings/basic_string/allocator/71964.cc
@@ -0,0 +1,74 @@
+// Copyright (C) 2016 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// 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.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3.  If not see
+// .
+
+// { dg-options "-std=gnu++11" }
+
+#include 
+#include 
+
+template
+  struct mv_allocator
+  {
+using value_type = T;
+using size_type = unsigned;
+
+mv_allocator()
+: moved_to(false), moved_from(false) { }
+
+template
+  mv_allocator(const mv_allocator & a)
+  : moved_to(a.moved_to), moved_from(a.moved_from) { }
+
+mv_allocator(const mv_allocator &) = default;
+
+mv_allocator(mv_allocator && a) noexcept : moved_to(true)
+{
+  a.moved_from = true;
+}
+
+T* allocate(unsigned n) { return std::allocator{}.allcoate(n); }
+void deallocate(T* p, unsigned n) { std::allocator{}.deallocate(p, n); }
+
+bool moved_to;
+bool moved_from;
+  };
+
+template
+bool
+operator==(const mv_allocator&, const mv_allocator&) { return true; }
+
+template
+bool
+operator!=(const mv_allocator&, const mv_allocator&) { return false; }
+
+void
+test01()
+{
+  // COW strings don't support C++11 allocators
+#if _GLIBCXX_USE_CXX11_ABI
+  std::basic_string, mv_allocator> s;
+  auto t = std::move(s);
+  VERIFY( s.get_allocator().moved_from );
+  VERIFY( t.get_allocator().moved_to );
+#endif
+}
+
+int
+main()
+{
+  test01();
+}
diff --git a/libstdc++-v3/testsuite/23_containers/se

[C PATCH] Don't mark C99 inline functions as always_inline (PR c/71969)

[Jakub Jelinek]

Hi!

As Richard reported on IRC, we are marking C99 inline (without extern)
functions as effectively always_inline, even when the intent has been to do
this only for the GNU extern inline functions (i.e. -fgnu89-inline extern
inline or extern inline __attribute__((gnu_inline))).

Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?  The alias-11.c change is needed because the inliner decides not to
inline new_cfi, and as it uses since -std=c11 default C99 inline semantics
without extern, the body isn't emitted.

2016-07-22  Jakub Jelinek  

PR c/71969
* c-decl.c (finish_function): Only set DECL_DISREGARD_INLINE_LIMITS
on GNU extern inline functions.

* gcc.dg/alias-11.c (add_cfi, new_cfi): Change __inline__ to
static __inline__.
* gcc.dg/pr71969-1.c: New test.
* gcc.dg/pr71969-2.c: New test.
* gcc.dg/pr71969-3.c: New test.

--- gcc/c/c-decl.c.jj   2016-07-21 08:59:53.0 +0200
+++ gcc/c/c-decl.c  2016-07-22 13:46:40.766019603 +0200
@@ -9262,7 +9262,9 @@ finish_function (void)
 
   /* For GNU C extern inline functions disregard inline limits.  */
   if (DECL_EXTERNAL (fndecl)
-  && DECL_DECLARED_INLINE_P (fndecl))
+  && DECL_DECLARED_INLINE_P (fndecl)
+  && (flag_gnu89_inline
+ || lookup_attribute ("gnu_inline", DECL_ATTRIBUTES (fndecl
 DECL_DISREGARD_INLINE_LIMITS (fndecl) = 1;
 
   /* Genericize before inlining.  Delay genericizing nested functions
--- gcc/testsuite/gcc.dg/alias-11.c.jj  2008-09-05 12:54:36.0 +0200
+++ gcc/testsuite/gcc.dg/alias-11.c 2016-07-22 17:01:49.930290850 +0200
@@ -24,7 +24,7 @@ dw_cfi_node *cie_cfi_head;
 unsigned fde_table_in_use;
 dw_fde_node *fde_table;
 
-__inline__ void
+static __inline__ void
 add_cfi (dw_cfi_node **list_head, dw_cfi_node *cfi)
 {
   dw_cfi_node **p;
@@ -35,7 +35,7 @@ add_cfi (dw_cfi_node **list_head, dw_cfi
   *p = cfi;
 }
 
-__inline__ struct dw_cfi_struct *
+static __inline__ struct dw_cfi_struct *
 new_cfi (void)
 {
   dw_cfi_node *cfi = (dw_cfi_node *) malloc (sizeof (dw_cfi_node));
--- gcc/testsuite/gcc.dg/pr71969-1.c.jj 2016-07-22 14:18:44.336452571 +0200
+++ gcc/testsuite/gcc.dg/pr71969-1.c2016-07-22 14:25:23.877557343 +0200
@@ -0,0 +1,37 @@
+/* PR c/71969 */
+/* { dg-do compile } */
+/* { dg-options "-std=gnu99 -fno-gnu89-inline -O2 -fdump-tree-einline-details" 
} */
+
+volatile int v;
+#define S v++;
+#define S10 S S S S S S S S S S
+#define S100 S10 S10 S10 S10 S10 S10 S10 S10 S10 S10
+
+extern inline void
+foo (void) { S100 }
+
+inline void
+bar (void) { S100 }
+
+static inline void
+baz (void) { S100 }
+
+int
+main ()
+{
+  foo ();
+  foo ();
+  foo ();
+  foo ();
+  bar ();
+  bar ();
+  bar ();
+  bar ();
+  baz ();
+  baz ();
+  baz ();
+  baz ();
+  return 0;
+}
+
+/* { dg-final { scan-tree-dump-times "will not early inline" 12 "einline" } } 
*/
--- gcc/testsuite/gcc.dg/pr71969-2.c.jj 2016-07-22 14:27:35.781941234 +0200
+++ gcc/testsuite/gcc.dg/pr71969-2.c2016-07-22 14:29:18.873678141 +0200
@@ -0,0 +1,23 @@
+/* PR c/71969 */
+/* { dg-do compile } */
+/* { dg-options "-std=gnu99 -fno-gnu89-inline -O2 -fdump-tree-einline-details" 
} */
+
+volatile int v;
+#define S v++;
+#define S10 S S S S S S S S S S
+#define S100 S10 S10 S10 S10 S10 S10 S10 S10 S10 S10
+
+extern inline __attribute__((gnu_inline)) void
+foo (void) { S100 }
+
+int
+main ()
+{
+  foo ();
+  foo ();
+  foo ();
+  foo ();
+  return 0;
+}
+
+/* { dg-final { scan-tree-dump-times "Inlining foo into main" 4 "einline" } } 
*/
--- gcc/testsuite/gcc.dg/pr71969-3.c.jj 2016-07-22 14:29:33.300501382 +0200
+++ gcc/testsuite/gcc.dg/pr71969-3.c2016-07-22 14:30:18.360949296 +0200
@@ -0,0 +1,38 @@
+/* PR c/71969 */
+/* { dg-do compile } */
+/* { dg-options "-std=gnu99 -fgnu89-inline -O2 -fdump-tree-einline-details" } 
*/
+
+volatile int v;
+#define S v++;
+#define S10 S S S S S S S S S S
+#define S100 S10 S10 S10 S10 S10 S10 S10 S10 S10 S10
+
+extern inline void
+foo (void) { S100 }
+
+inline void
+bar (void) { S100 }
+
+static inline void
+baz (void) { S100 }
+
+int
+main ()
+{
+  foo ();
+  foo ();
+  foo ();
+  foo ();
+  bar ();
+  bar ();
+  bar ();
+  bar ();
+  baz ();
+  baz ();
+  baz ();
+  baz ();
+  return 0;
+}
+
+/* { dg-final { scan-tree-dump-times "will not early inline" 8 "einline" } } */
+/* { dg-final { scan-tree-dump-times "Inlining foo into main" 4 "einline" } } 
*/

Jakub

Re: [PATCH] nvptx: do not implicitly enable -ftoplevel-reorder

[Alexander Monakov]

On Thu, 21 Jul 2016, Thomas Schwinge wrote:
> Hmm.  In an offloading configuration I see the following regression:

First of all: sorry about this (bah, this is fairly embarrassing, while I forgot
to check offloading, I should have seen the fallout in check-c testing; might
have tested the wrong source checkout).

> [-PASS:-]{+FAIL:+}
> libgomp.oacc-c/../libgomp.oacc-c-c++-common/reduction-cplx-dbl.c
> -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 -foffload=nvptx-none  -O0
[snip]
> ptxas /tmp/ccmABlIh.o, line 1408; error   : Label expected for forward
> reference of '__reduction_lock'

This is due to the following:

1. VAR_DECL for __reduction_lock is created on-demand when offloaded functions
are compiled.
2. output_in_order does not care if new declarations appear while
already-existing function bodies are emitted.  It's followed by
process_new_functions that handles only functions.
3. Normally process_pending_assemble_externals would have handled this, but the
nvptx backend doesn't use ASM_OUTPUT_EXTERNAL (:/, I wonder why), so it's a
no-op there.

> C:
> 
> [-PASS:-]{+WARNING: program timed out.+}
> {+FAIL:+} gcc.dg/large-size-array-4.c (test for excess errors)
> 
> This one times out when creating a huge *.s file:
> 
> [...]
> .global .align 8 .u64 name[2147483649] = { 0, 0, [...]
> 
> Running with -ftoplevel-reorder (as implicitly enabled before), a *.s
> file with just the preamble gets created.  Are these behaviors correct?

Yes, with -ftoplevel-reorder the huge variable is not emitted because it's
unused.  In PTX there's no way to emit such a huge initializer without spelling
it all out, so the behavior after the patch is expected.

I think the testcase uncovers a flaw in GCC's behavior: it tests for an error
diagnostic, but it wouldn't be emitted on any 32-bit platform with
-ftoplevel-reorder. So, while as a quick-fix it's possible to skip this test on
NVPTX, it's better to make GCC diagnose this consistently and run the testcase
with -fsyntax-only to avoid emitting the huge initializer.

> [-PASS:-]{+FAIL:+} gcc.dg/pr16973.c (test for excess errors)

This test needs "label_values" dg-require-effective-target annotation.

> C++:
[snip]
> [-PASS:-]{+FAIL:+} g++.dg/debug/dwarf2/dwarf4-typedef.C  -std=gnu++14 
> (test for excess errors)
> 
> These now all FAIL due to "sorry, unimplemented: target cannot support
> nonlocal goto", which is "acceptable", but should be XFAILed.  (Though,
> that has generally not yet been done for C++.)

Nonlocal gotos appear where a possibly-throwing call is followed by a destructor
invocation (in other words, where unwinding after an exception is thrown needs
to invoke destructors). Here -ftoplevel-reorder affects whether the compiler is
able to deduce some calls as non-throwing (even at -O0).

As NVPTX doesn't support C++ exceptions at all, you must be seeing an extreme
amount of similar failure already.

> [-PASS:-]{+FAIL:+} g++.dg/cpp1y/nsdmi-aggr1.C  -std=c++14 (test for 
> excess errors)
> 
> Now fails with:
> 
> nvptx-as: circular reference in variable initializers

Here -ftoplevel-reorder affects whether a static variable that needs a
self-recursive initializer is emitted.  This wouldn't work on NVPTX and passed
by luck previously (if the variable wasn't unused, it would fail).

> More "sorry, unimplemented: target cannot support nonlocal goto".  But
> why did these PASS before?  Is this generally just a problem with -O0, or
> are there any optimizations doing things differently whether
> -ftoplevel-reorder is in effect or not, and we could perhaps shuffle some
> things so that for nvptx we run into "sorry, unimplemented: target cannot
> support nonlocal goto" less often?  That is, I'm not clear on how
> -fno-toplevel-reorder interacts with "nonlocal goto".

I've provided an explanation above, but to put it in different words,
-ftoplevel-reorder is a form of optimization (enabled by default except at -O0),
and on nvptx it was implicitly enabled at -O0 previously, allowing some cleanups
to happen and thus concealing some issues. The biggest of those, "cannot support
nonlocal goto", is due to no possibility of C++ exceptions on NVPTX.

Did you consider enabling -fno-exceptions by default for nvptx?

> [-PASS:-]{+FAIL:+} g++.old-deja/g++.pt/crash55.C  -std=c++14 (test for 
> excess errors)
> 
> These now fail with:
> 
> ptxas crash55.o, line 61; error   : Arguments mismatch for instruction 
> 'mov'
> ptxas crash55.o, line 63; error   : Arguments mismatch for instruction 
> 'mov'
> ptxas crash55.o, line 80; error   : Label expected for argument 0 of 
> instruction 'call'
> ptxas crash55.o, line 80; error   : Function '_ZN3fooIcE1dEPS0_' not 
> declared in this scope

This is due to a combination of bogus sjlj exception emission and a bug in
nvptx-as that is not ready for such bogosity.

I hope I've satisfactorily explained the failures you've pointed out (thanks for
the data).  I think I

Re: [Fortran, Patch, PR71807, v1] [5/6/7 Regression] Internal compiler error with NULL() reference in structure constructor

[Andre Vehreschild]

Hi all,

committed to gcc-6-branch as r238649, and
to gcc-5-branch as r238650.

Regards,
Andre

On Fri, 15 Jul 2016 11:29:37 +0200
Andre Vehreschild  wrote:

> Hi Jerry,
> 
> thanks for the fast review. Committed to trunk as r238368.
> 
> Regards,
>   Andre
> 
> On Thu, 14 Jul 2016 10:49:37 -0700
> Jerry DeLisle  wrote:
> 
> > On 07/14/2016 09:17 AM, Andre Vehreschild wrote:  
> > > Hi all,
> > > 
> > > attached patch fixes the ICE when assigning null() to an
> > > allocatable component in an initializer.
> > > 
> > > Bootstrapped and regtested on x86_64-linux/F23 ok for trunk,
> > > gcc-6-branch and gcc-5-branch.
> > > 
> > > Ok for trunk and one week later for the other branches?
> > > 
> > > Regards,
> > >   Andre
> > > 
> > 
> > Yes, OK and thanks for patch.
> > 
> > Jerry  
> 
> 


-- 
Andre Vehreschild * Email: vehre ad gmx dot de 
Index: gcc/fortran/ChangeLog
===
--- gcc/fortran/ChangeLog	(Revision 238640)
+++ gcc/fortran/ChangeLog	(Arbeitskopie)
@@ -1,5 +1,12 @@
 2016-07-22  Andre Vehreschild  
 
+	Backported from trunk:
+	PR fortran/71807
+	* trans-expr.c (gfc_trans_subcomponent_assign): Special casing
+	when allocatable component is set to null() in initializer.
+
+2016-07-22  Andre Vehreschild  
+
 	Backport from trunk:
 	PR fortran/70842
 	* simplify.c (gfc_simplify_len): Only for unlimited polymorphic
Index: gcc/fortran/trans-expr.c
===
--- gcc/fortran/trans-expr.c	(Revision 238639)
+++ gcc/fortran/trans-expr.c	(Arbeitskopie)
@@ -7200,6 +7200,12 @@
   tmp = gfc_trans_alloc_subarray_assign (tmp, cm, expr);
   gfc_add_expr_to_block (&block, tmp);
 }
+  else if (init && cm->attr.allocatable && expr->expr_type == EXPR_NULL)
+{
+  /* NULL initialization for allocatable components.  */
+  gfc_add_modify (&block, dest, fold_convert (TREE_TYPE (dest),
+		  null_pointer_node));
+}
   else if (init && (cm->attr.allocatable
 	   || (cm->ts.type == BT_CLASS && CLASS_DATA (cm)->attr.allocatable
 	   && expr->ts.type != BT_CLASS)))
Index: gcc/testsuite/ChangeLog
===
--- gcc/testsuite/ChangeLog	(Revision 238640)
+++ gcc/testsuite/ChangeLog	(Arbeitskopie)
@@ -1,5 +1,11 @@
 2016-07-22  Andre Vehreschild  
 
+	Backported from trunk:
+	PR fortran/71807
+	* gfortran.dg/null_9.f90: New test.
+
+2016-07-22  Andre Vehreschild  
+
 	Backport from trunk:
 	PR fortran/70842
 	* gfortran.dg/select_type_35.f03: New test.
Index: gcc/testsuite/gfortran.dg/null_9.f90
===
--- gcc/testsuite/gfortran.dg/null_9.f90	(nicht existent)
+++ gcc/testsuite/gfortran.dg/null_9.f90	(Arbeitskopie)
@@ -0,0 +1,30 @@
+! { dg-do run }
+
+MODULE fold_convert_loc_ice
+  IMPLICIT NONE
+  PRIVATE
+
+  TYPE, PUBLIC :: ta
+PRIVATE
+INTEGER :: a_comp
+  END TYPE ta
+
+  TYPE, PUBLIC :: tb
+TYPE(ta), ALLOCATABLE :: b_comp
+  END TYPE tb
+
+  PUBLIC :: proc
+CONTAINS
+  SUBROUTINE proc
+TYPE(tb) :: b
+
+b = tb(null())
+if (allocated( b%b_comp )) call abort()
+  END SUBROUTINE proc
+END MODULE fold_convert_loc_ice
+
+  USE fold_convert_loc_ice
+
+  call proc()
+END
+
Index: gcc/fortran/ChangeLog
===
--- gcc/fortran/ChangeLog	(Revision 238644)
+++ gcc/fortran/ChangeLog	(Arbeitskopie)
@@ -1,6 +1,13 @@
 2016-07-22  Andre Vehreschild  
 
 	Backport from trunk:
+	PR fortran/71807
+	* trans-expr.c (gfc_trans_subcomponent_assign): Special casing
+	when allocatable component is set to null() in initializer.
+
+2016-07-22  Andre Vehreschild  
+
+	Backport from trunk:
 	PR fortran/70842
 	* simplify.c (gfc_simplify_len): Only for unlimited polymorphic
 	types replace the expression's _data ref with a _len ref.
Index: gcc/fortran/trans-expr.c
===
--- gcc/fortran/trans-expr.c	(Revision 238643)
+++ gcc/fortran/trans-expr.c	(Arbeitskopie)
@@ -7012,6 +7012,12 @@
   tmp = gfc_trans_alloc_subarray_assign (tmp, cm, expr);
   gfc_add_expr_to_block (&block, tmp);
 }
+  else if (init && cm->attr.allocatable && expr->expr_type == EXPR_NULL)
+{
+  /* NULL initialization for allocatable components.  */
+  gfc_add_modify (&block, dest, fold_convert (TREE_TYPE (dest),
+		  null_pointer_node));
+}
   else if (init && (cm->attr.allocatable
 	   || (cm->ts.type == BT_CLASS && CLASS_DATA (cm)->attr.allocatable
 	   && expr->ts.type != BT_CLASS)))
Index: gcc/testsuite/ChangeLog
===
--- gcc/testsuite/ChangeLog	(Revision 238644)
+++ gcc/testsuite/ChangeLog	(Arbeitskopie)
@@ -1,6 +1,12 @@
 2016-07-22  Andre Vehreschild  
 
 	Backport from trunk:
+	PR fortran/71807
+	* gfortran.dg/null_9.f90: New test.
+
+2016-07-22  Andre Vehreschild  

Re: [PATCH] nvptx: do not implicitly enable -ftoplevel-reorder

[Bernd Schmidt]

On 07/22/2016 05:19 PM, Alexander Monakov wrote:

I hope I've satisfactorily explained the failures you've pointed out (thanks for
the data).  I think I should leave the choice of what to do next (revert the
patch or leave it in and install fixups where appropriate) up to you?


What's the motivation for supporting -fno-toplevel-reorder anyway? 
That's practically just a legacy mode as far as I know.



Bernd

Re: Merge switch statements in tree-cfgcleanup

[Jeff Law]

On 07/22/2016 07:13 AM, Richard Biener wrote:


+  if (dom_info_available_p (CDI_DOMINATORS))

I think DOM info is always available during CFG cleanup
My recollection is that the cfg cleanup routines start by removing 
unreachables, then recomputing the dominator tree if it's not available.


That sequencing is vital as the dominator tree builder will assert 
there's no unreachables in the CFG.


jeff

Re: [PATCH] Avoid invoking ranlib on libbackend.a

[Andreas Schwab]

Patrick Palka  writes:

> ... so it's weird that your build times are constant because building
> a thin archive is much faster than building a regular archive and
> using a thin archive should not make subsequent steps, like linking
> that archive, slower.  So overall build times should be lower.

Linking a thin archive requires opening each archive member as a file
instead of only reading within a single file.  This could add some
non-trivial overhead.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [PATCH] doc fix for c/71560 - union compound literal initializes wrong union field

[Martin Sebor]

On 07/14/2016 11:16 AM, Jeff Law wrote:

On 07/14/2016 09:03 AM, Martin Sebor wrote:

Ping.  The updated patch at the link below corrects the issues
with the tags pointed out by Sandra in her review.

https://gcc.gnu.org/ml/gcc-patches/2016-07/msg00350.html

OK.
jeff



Thanks.  After committing it (r238651) I noticed the patch had
a typo (a missing '@' in the @code{...} tag) that broke bootstrap.
I've quickly fixed it (r238652) but this is just a heads up in
case someone manages to run into it.

Martin

Re: [PATCH] nvptx: do not implicitly enable -ftoplevel-reorder

[Alexander Monakov]

On Fri, 22 Jul 2016, Bernd Schmidt wrote:
> What's the motivation for supporting -fno-toplevel-reorder anyway? That's
> practically just a legacy mode as far as I know.

I've made the prerequisite middle-end patch after noticing that libgcc
explicitly enables -fno-toplevel-reorder (and that was breaking the build on my
branch). The patch in the opening message of this thread is just a small cleanup
for the backend that could be made as a followup.

(plus, nothing in the nvptx backend fundamentally depends on
-ftoplevel-reorder, so the override was rather confusing)

Can you comment on the question about ASM_OUTPUT_EXTERNAL, did you avoid it for
any particular reason?

Thanks.
Alexander

Re: [libstdc++] Add C++17clamp

[Daniel Krügler]

2016-07-22 9:55 GMT+02:00 Jonathan Wakely :
> On 22/07/16 08:51 +0100, Jonathan Wakely wrote:
>>
>> On 21/07/16 19:38 -0400, NightStrike wrote:
>>>
>>> On Thu, Jul 14, 2016 at 7:50 PM, Ed Smith-Rowland <3dw...@verizon.net>
>>> wrote:

 Here is an implementation of P0025
 An algorithm to "clamp" a value between a pair of boundary values.

 Testing is almost finished - looks good so far.

 OK if testing passes?

 I didn't see a feature test in any of the SD-6 papers or P0025.

>>>
>>> This is not an efficient implementation.  See here:
>>>
>>> https://gcc.gnu.org/ml/gcc-help/2014-10/msg00112.html
>>>
>>> Which I derived from this SO answer (which is sadly not the accepted
>>> answer at this time):
>>>
>>> http://stackoverflow.com/a/16659263
>>>
>>> I suggest using the very efficient method that requires a temporary.
>>
>>
>> That isn't a valid implementation of std::clamp, since it performs a
>> copy. The template argument might not even be copyable.
>
> We could possibly dispatch to such an implementation for arithmetic
> types, but we wouldn't want to do it for all copyable types. There's
> no way you can know whether making that local copy is expensive for an
> arbitrary type, and making a copy isn't allowed anyway.

But given that clamp is required not even to *return* copies of any of
it's arguments, it doesn't seem to be possible to do that for
arithmetic types either, unless I'm misunderstanding something very
fundamentally here. Or are you interpolating that the same performance
will result out of (ignoring constexpr) the following transformation

const float& clamp(const float& x, const float& min, const max) {
  const float& t = x < min ? min : x;
  return t > max ? max : t;
}

?

libgo patch committed: Update to 1.7rc3

[Ian Lance Taylor]

I have committed a patch to update libgo to the 1.7rc3 release
candidate.  This is very close to the upcoming 1.7 release.  As usual
with libgo updates, the patch is too large to include in this e-mail
message.  I've appended the changes to the gccgo-specific directories.

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 238618)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-4c88f31a83ca28963d29d6dc9fcdb2e9b093610c
+b156d71ad75a1b73d0ed805a5370a297648d9270
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: libgo/MERGE
===
--- libgo/MERGE (revision 236804)
+++ libgo/MERGE (working copy)
@@ -1,4 +1,4 @@
-f5cf5673590a68c55b2330df9dfcdd6fac75b893
+8707f31c0abc6b607014e843b7cc188b3019daa9
 
 The first line of this file holds the git revision number of the
 last merge done from the master library sources.
Index: libgo/Makefile.am
===
--- libgo/Makefile.am   (revision 236804)
+++ libgo/Makefile.am   (working copy)
@@ -111,6 +111,7 @@ endif
 toolexeclibgo_DATA = \
bufio.gox \
bytes.gox \
+   context.gox \
crypto.gox \
encoding.gox \
errors.gox \
@@ -315,6 +316,7 @@ toolexeclibgonethttp_DATA = \
net/http/cookiejar.gox \
net/http/fcgi.gox \
net/http/httptest.gox \
+   net/http/httptrace.gox \
net/http/httputil.gox \
net/http/pprof.gox
 
@@ -593,6 +595,9 @@ go_bytes_files = \
 go_bytes_c_files = \
go/bytes/indexbyte.c
 
+go_context_files = \
+   go/context/context.go
+
 go_crypto_files = \
go/crypto/crypto.go
 
@@ -776,15 +781,19 @@ if LIBGO_IS_LINUX
 go_net_interface_file = go/net/interface_linux.go
 else
 if LIBGO_IS_NETBSD
-go_net_interface_file = go/net/interface_netbsd.go
+go_net_interface_file = go/net/interface_bsdvar.go
 else
 if LIBGO_IS_DRAGONFLY
-go_net_interface_file = go/net/interface_dragonfly.go
+go_net_interface_file = go/net/interface_bsdvar.go
+else
+if LIBGO_IS_OPENBSD
+go_net_interface_file = go/net/interface_bsdvar.go
 else
 go_net_interface_file = go/net/interface_stub.go
 endif
 endif
 endif
+endif
 
 if LIBGO_IS_LINUX
 go_net_cloexec_file = go/net/sock_cloexec.go go/net/hook_cloexec.go
@@ -845,6 +854,7 @@ go_net_common_files = \
go/net/nss.go \
go/net/parse.go \
go/net/pipe.go \
+   go/net/port.go \
go/net/fd_poll_runtime.go \
go/net/port_unix.go \
$(go_net_sendfile_file) \
@@ -991,6 +1001,20 @@ endif
 endif
 endif
 
+if LIBGO_IS_LINUX
+go_os_wait_file = go/os/wait_waitid.go
+else
+if LIBGO_IS_DARWIN
+go_os_wait_file = go/os/wait_waitid.go
+else
+if LIBGO_IS_FREEBSD
+go_os_wait_file = go/os/wait_wait6.go
+else
+go_os_wait_file = go/os/wait_unimp.go
+endif
+endif
+endif
+
 go_os_files = \
$(go_os_dir_file) \
go/os/dir.go \
@@ -1016,7 +1040,8 @@ go_os_files = \
$(go_os_sys_file) \
$(go_os_cloexec_file) \
go/os/types.go \
-   go/os/types_unix.go
+   go/os/types_unix.go \
+   $(go_os_wait_file)
 
 go_path_files = \
go/path/match.go \
@@ -1048,6 +1073,7 @@ go_runtime_files = \
go/runtime/error.go \
go/runtime/extern.go \
go/runtime/mem.go \
+   go/runtime/symtab.go \
version.go
 
 version.go: s-version; @true
@@ -1134,6 +1160,7 @@ go_testing_files = \
go/testing/benchmark.go \
go/testing/cover.go \
go/testing/example.go \
+   go/testing/match.go \
go/testing/testing.go
 
 go_time_files = \
@@ -1174,6 +1201,7 @@ endif
 
 go_archive_tar_files = \
go/archive/tar/common.go \
+   go/archive/tar/format.go \
go/archive/tar/reader.go \
go/archive/tar/stat_unix.go \
go/archive/tar/writer.go \
@@ -1192,8 +1220,9 @@ go_compress_bzip2_files = \
go/compress/bzip2/move_to_front.go
 
 go_compress_flate_files = \
-   go/compress/flate/copy.go \
go/compress/flate/deflate.go \
+   go/compress/flate/deflatefast.go \
+   go/compress/flate/dict_decoder.go \
go/compress/flate/huffman_bit_writer.go \
go/compress/flate/huffman_code.go \
go/compress/flate/inflate.go \
@@ -1225,7 +1254,8 @@ go_crypto_aes_files = \
go/crypto/aes/block.go \
go/crypto/aes/cipher.go \
go/crypto/aes/cipher_generic.go \
-   go/crypto/aes/const.go
+   go/crypto/aes/const.go \
+   go/crypto/aes/modes.go
 go_crypto_cipher_files = \
go/crypto/cipher/cbc.go \
go/crypto/cipher/cfb.go \
@@ -1257,8 +1287,12 @@ go_crypto_md5_files = \
 if LIBGO_IS_LINUX
 crypto_rand_file = go/crypto/rand/rand_linux.go
 else
+if LIBGO_IS_OPENBSD
+crypto_rand_file = go/crypto/rand/rand_openbsd.go
+else
 crypto_rand_file =
 endif
+endif
 
 go_

Re: [libstdc++] Add C++17clamp

[Jonathan Wakely]

On 22/07/16 19:38 +0200, Daniel Krügler wrote:

2016-07-22 9:55 GMT+02:00 Jonathan Wakely :

On 22/07/16 08:51 +0100, Jonathan Wakely wrote:


On 21/07/16 19:38 -0400, NightStrike wrote:


On Thu, Jul 14, 2016 at 7:50 PM, Ed Smith-Rowland <3dw...@verizon.net>
wrote:


Here is an implementation of P0025
An algorithm to "clamp" a value between a pair of boundary values.

Testing is almost finished - looks good so far.

OK if testing passes?

I didn't see a feature test in any of the SD-6 papers or P0025.



This is not an efficient implementation.  See here:

https://gcc.gnu.org/ml/gcc-help/2014-10/msg00112.html

Which I derived from this SO answer (which is sadly not the accepted
answer at this time):

http://stackoverflow.com/a/16659263

I suggest using the very efficient method that requires a temporary.



That isn't a valid implementation of std::clamp, since it performs a
copy. The template argument might not even be copyable.


We could possibly dispatch to such an implementation for arithmetic
types, but we wouldn't want to do it for all copyable types. There's
no way you can know whether making that local copy is expensive for an
arbitrary type, and making a copy isn't allowed anyway.


But given that clamp is required not even to *return* copies of any of
it's arguments, it doesn't seem to be possible to do that for
arithmetic types either, unless I'm misunderstanding something very
fundamentally here. Or are you interpolating that the same performance
will result out of (ignoring constexpr) the following transformation

const float& clamp(const float& x, const float& min, const max) {
 const float& t = x < min ? min : x;
 return t > max ? max : t;
}

?


No, I was just overlooking the fact that of course we can't make a
copy if we have to return a reference to one of the arguments.

[Committed] PR fortran/71935

[Steve Kargl]

I've committed the following patch under "obviously correct."

2016-07-22  Steven G. Kargl  

PR fortran/71935
* check.c (is_c_interoperable): Simplify right expression. 

2016-07-22  Steven G. Kargl  

PR fortran/71935
* gfortran.dg/c_sizeof_1.f90: Move invalid code to ...
* gfortran.dg/c_sizeof_6.f90: here.  Test for error.
* gfortran.dg/pr71935.f90: New test.

Index: gcc/fortran/check.c
===
--- gcc/fortran/check.c (revision 238660)
+++ gcc/fortran/check.c (working copy)
@@ -4278,7 +4278,7 @@ is_c_interoperable (gfc_expr *expr, cons
   }
 
 if (expr->ts.u.cl && expr->ts.u.cl->length
-   && !gfc_simplify_expr (expr, 0))
+   && !gfc_simplify_expr (expr->ts.u.cl->length, 0))
   gfc_internal_error ("is_c_interoperable(): gfc_simplify_expr failed");
 
 if (!c_loc && expr->ts.u.cl
Index: gcc/testsuite/gfortran.dg/c_sizeof_1.f90
===
--- gcc/testsuite/gfortran.dg/c_sizeof_1.f90(revision 238660)
+++ gcc/testsuite/gfortran.dg/c_sizeof_1.f90(working copy)
@@ -22,9 +22,6 @@ if (i /= 4) call abort()
 i = c_sizeof(str2(1))
 if (i /= 1) call abort()
 
-i = c_sizeof(str2(1:3))
-if (i /= 3) call abort()
-
 write(*,*) c_sizeof(cptr), c_sizeof(iptr), c_sizeof(C_NULL_PTR)
 
 ! Using GNU's SIZEOF
Index: gcc/testsuite/gfortran.dg/c_sizeof_6.f90
===
--- gcc/testsuite/gfortran.dg/c_sizeof_6.f90(nonexistent)
+++ gcc/testsuite/gfortran.dg/c_sizeof_6.f90(working copy)
@@ -0,0 +1,16 @@
+! { dg-do compile }
+!
+program foo
+
+   use iso_c_binding, only: c_int, c_char, c_sizeof
+
+   integer(kind=c_int) :: i
+
+   character(kind=c_char,len=1),parameter :: str2(4) = ["a","b","c","d"]
+
+   i = c_sizeof(str2(1:3)) ! { dg-error "must be an interoperable data" }
+
+   if (i /= 3) call abort()
+
+end program foo
+
Index: gcc/testsuite/gfortran.dg/pr71935.f90
===
--- gcc/testsuite/gfortran.dg/pr71935.f90   (nonexistent)
+++ gcc/testsuite/gfortran.dg/pr71935.f90   (working copy)
@@ -0,0 +1,7 @@
+! { dg-do compile }
+program p
+   use iso_c_binding
+   character(len=1, kind=c_char), parameter :: z(2) = 'z'
+   print *, sizeof(z(3))  ! { dg-error "is out of bounds" }
+   print *, c_sizeof(z(3))! { dg-error "is out of bounds" }
+end

-- 
Steve

[PATCH] accept flexible arrays in struct in unions (c++/71912 - [6/7 regression])

[Martin Sebor]

r231665 committed in the 6.0 cycle tightened up the checking of
flexible array members in C++ with the goal of rejecting code
that could lead to hard to find bugs, while at the same time
accepting (with a warning) benign extensions also accepted in
C mode.

c++/71912 is a complaint that G++ rejects one such extension:
defining structs with flexible array members in a union.  When
reviewing the code that causes it to be rejected I realized
that it was, in fact, meant to be accepted and is rejected due
to a bug.

The attached patch fixes that bug and implements more robust
checking for this class of problems.  As in C mode, it accepts
"benign" instances of this idiom (with a pedantic warning) while
still rejecting the erroneous cases.

There are outstanding problems with flexible array members in
C++, such as c++/68489 - arrays of flexible array members are
silently accepted.  In a follow-on patch I will address at
least a part of the problem.  I submit this one separately
since it's considered a regression and as such might be
a candidate for backporting to the 6.x branch.

Is this patch okay for trunk?  For 6.x?

Thanks
Martin
PR c++/71912 - [6/7 regression] flexible array in struct in union rejected

gcc/cp/ChangeLog:
2016-07-22  Martin Sebor  

	PR c++/71912
	* class.c (struct flexmems_t):  Add members.
	(find_flexarrays): Add arguments.  Correct handling of anonymous
	structs.
	(diagnose_flexarrays): Adjust to issue warnings in addition to errors.
	(check_flexarrays): Add argument.

gcc/testsuite/ChangeLog:
2016-07-22  Martin Sebor  

	PR c++/71912
	* g++.dg/ext/flexary18.C: New test.
	* g++.dg/ext/flexary4.C: Correct the handling of anonymous structs.

diff --git a/gcc/cp/class.c b/gcc/cp/class.c
index b2db7f8..65b373f 100644
--- a/gcc/cp/class.c
+++ b/gcc/cp/class.c
@@ -149,9 +149,9 @@ static bool accessible_nvdtor_p (tree);
 
 /* Used by find_flexarrays and related.  */
 struct flexmems_t;
-static void find_flexarrays (tree, flexmems_t *);
+static void find_flexarrays (tree, flexmems_t *, bool = false, tree = NULL_TREE);
 static void diagnose_flexarrays (tree, const flexmems_t *);
-static void check_flexarrays (tree, flexmems_t * = NULL);
+static void check_flexarrays (tree, bool = false, flexmems_t * = NULL);
 static void check_bases (tree, int *, int *);
 static void check_bases_and_members (tree);
 static tree create_vtable_ptr (tree, tree *);
@@ -6688,25 +6688,45 @@ field_nonempty_p (const_tree fld)
   return false;
 }
 
-/* Used by find_flexarrays and related.  */
-struct flexmems_t {
+/* Used by find_flexarrays and related members.  */
+
+struct flexmems_t
+{
   /* The first flexible array member or non-zero array member found
- in order of layout.  */
+ in the order of layout.  */
   tree array;
   /* First non-static non-empty data member in the class or its bases.  */
   tree first;
-  /* First non-static non-empty data member following either the flexible
- array member, if found, or the zero-length array member.  */
-  tree after;
+  /* A pair of the first non-static non-empty data members following
+ either the flexible array member, if found, or the zero-length
+ array member otherwise.  AFTER[1] refers to the first such data
+ member of a union that the struct containing the flexible array
+ member or zero-length array is a member, or NULL when no such
+ union exists.  AFTER[0] refers to the first such data member
+ that is not a member of such a union.  */
+  tree after[2];
+
+  /* The type in which an anonymous struct or union containing ARRAY
+ is defined..  */
+  tree anonctx;
 };
 
 /* Find either the first flexible array member or the first zero-length
array, in that order or preference, among members of class T (but not
-   its base classes), and set members of FMEM accordingly.  */
+   its base classes), and set members of FMEM accordingly.
+   BASE_P is true if T is a base class of another class.
+   PUN is set to the outermost union of which T is a member if one such
+   union exists, otherwsie to NULL.  */
 
 static void
-find_flexarrays (tree t, flexmems_t *fmem)
+find_flexarrays (tree t, flexmems_t *fmem, bool base_p,
+		 tree pun /* = NULL_TREE */)
 {
+  /* Set the "pointer" to the outsermost enclosing union if not set
+ yet and maintain it for the remainder of the recursion.   */
+  if (!pun && TREE_CODE (t) == UNION_TYPE)
+pun = t;
+
   for (tree fld = TYPE_FIELDS (t), next; fld; fld = next)
 {
   /* Find the next non-static data member if it exists.  */
@@ -6714,17 +6734,48 @@ find_flexarrays (tree t, flexmems_t *fmem)
 	   (next = DECL_CHAIN (next))
 	 && TREE_CODE (next) != FIELD_DECL; );
 
+  /* Type of the member.  */
   tree fldtype = TREE_TYPE (fld);
+
   if (TREE_CODE (fld) != TYPE_DECL
 	  && RECORD_OR_UNION_TYPE_P (fldtype)
-	  && TYPE_ANONYMOUS_P (fldtype))
+	  && (FIELD_DECL != TREE_CODE (fld) || !DECL_FIELD_IS_BASE (fld)))
 	{
-	  /* Members of anonymous structs and unions are treat

Re: [PATCH] - improve sprintf buffer overflow detection (middle-end/49905)

[Jeff Law]

On 07/21/2016 03:57 PM, Martin Sebor wrote:


The pass only runs once.  Without optimization, it's invoked early,
does its thing, and is never invoked again.  With optimization,
it's also invoked early but returns without doing anything, only
to to invoked again much later on to do real work.  I wasn't sure
where among all the passes might be the best spot to insert it so
I put in the same place as Aldy's -Walloca patch because it relies
on the same prior passes.
Seems reasonable.  I'm not sure were best to put the late call either; 
it's a balancing act many passes have opportunities to simplify stuff in 
ways that may make a false positive go away, but many passes can also 
muck up the range information that you're likely depending on.


I'd say stick with its current position in the pipeline, then we should 
reevaluate after some of the range reimplementation lands.


jeff

[PATCH] Teach VRP to register assertions along default switch labels (PR 18046)

[Patrick Palka]

This patch teaches VRP to register along a default switch label
assertions that corresponds to the anti range of each case label.

Does this look OK to commit after bootstrap + regtest on
x86_64-pc-linux-gnu?
---
 gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-6.c |  2 +-
 gcc/testsuite/gcc.dg/tree-ssa/vrp103.c   | 30 ++
 gcc/testsuite/gcc.dg/tree-ssa/vrp104.c   | 32 +++
 gcc/tree-vrp.c   | 39 ++--
 4 files changed, 100 insertions(+), 3 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/vrp103.c
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/vrp104.c

diff --git a/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-6.c 
b/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-6.c
index 5ec4687..551fbac 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-6.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-6.c
@@ -1,7 +1,7 @@
 /* { dg-do compile } */
 /* { dg-options "-O2 -fdump-tree-thread1-details -fdump-tree-thread2-details" 
} */
 /* { dg-final { scan-tree-dump-times "FSM" 3 "thread1" } } */
-/* { dg-final { scan-tree-dump-times "FSM" 4 "thread2" } } */
+/* { dg-final { scan-tree-dump-times "FSM" 5 "thread2" } } */
 
 int sum0, sum1, sum2, sum3;
 int foo (char *s, char **ret)
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/vrp103.c 
b/gcc/testsuite/gcc.dg/tree-ssa/vrp103.c
new file mode 100644
index 000..eea98bb
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/vrp103.c
@@ -0,0 +1,30 @@
+/* PR tree-optimization/18046  */
+/* { dg-options "-O2 -fdump-tree-vrp" }  */
+/* { dg-final { scan-tree-dump-times "baz \\(0\\);" 4 "vrp1" } }  */
+
+void foo ();
+void bar ();
+void baz (int);
+
+void
+test (int i)
+{
+  switch (i)
+{
+case 1:
+case 2:
+case 3:
+  foo ();
+  break;
+case 5:
+  bar ();
+  break;
+default:
+  /* These tests should be folded to 0, resulting in 4 calls to bar (0).  
*/
+  baz (i == 1);
+  baz (i == 2);
+  baz (i == 3);
+  baz (i == 5);
+  break;
+}
+}
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/vrp104.c 
b/gcc/testsuite/gcc.dg/tree-ssa/vrp104.c
new file mode 100644
index 000..6410847
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/vrp104.c
@@ -0,0 +1,32 @@
+/* PR tree-optimization/18046  */
+/* { dg-options "-O2 -fdump-tree-optimized" }  */
+/* { dg-final { scan-tree-dump-times "switch" 1 "optimized" } }  */
+
+void foo ();
+void bar ();
+
+void
+test (int i)
+{
+  switch (i)
+{
+case 1:
+  foo ();
+  break;
+case 2:
+  bar ();
+  break;
+default:
+  break;
+}
+
+  /* This switch should be gone after threading/VRP.  */
+  switch (i)
+{
+case 1:
+  foo ();
+  break;
+default:
+  break;
+}
+}
diff --git a/gcc/tree-vrp.c b/gcc/tree-vrp.c
index 06364b7..32a4de3 100644
--- a/gcc/tree-vrp.c
+++ b/gcc/tree-vrp.c
@@ -5917,6 +5917,7 @@ find_switch_asserts (basic_block bb, gswitch *last)
   ci[idx].expr = gimple_switch_label (last, idx);
   ci[idx].bb = label_to_block (CASE_LABEL (ci[idx].expr));
 }
+  edge default_edge = find_edge (bb, ci[0].bb);
   qsort (ci, n, sizeof (struct case_info), compare_case_labels);
 
   for (idx = 0; idx < n; ++idx)
@@ -5945,8 +5946,8 @@ find_switch_asserts (basic_block bb, gswitch *last)
max = CASE_LOW (ci[idx].expr);
}
 
-  /* Nothing to do if the range includes the default label until we
-can register anti-ranges.  */
+  /* Can't extract a useful assertion out of a range that includes the
+ default label.  */
   if (min == NULL_TREE)
continue;
 
@@ -5963,6 +5964,40 @@ find_switch_asserts (basic_block bb, gswitch *last)
  fold_convert (TREE_TYPE (op), max));
 }
 
+  /* For each case label, register along the default label an assertion that
+ corresponds to the anti-range of that label.  */
+  for (idx = 0; idx < n; ++idx)
+{
+  tree min, max;
+  tree cl = ci[idx].expr;
+
+  min = CASE_LOW (cl);
+  max = CASE_HIGH (cl);
+
+  if (min == NULL_TREE)
+   continue;
+
+  if (max == NULL_TREE)
+   {
+ /* Register the assertion OP != MIN.  */
+ min = fold_convert (TREE_TYPE (op), min);
+ register_edge_assert_for (op, default_edge, bsi, NE_EXPR, op, min);
+   }
+  else
+   {
+ /* Register the assertion (unsigned)OP - MIN > (MAX - MIN),
+which will give OP the anti-range ~[MIN,MAX].  */
+ tree uop = fold_convert (unsigned_type_for (TREE_TYPE (op)), op);
+ min = fold_convert (TREE_TYPE (uop), min);
+ max = fold_convert (TREE_TYPE (uop), max);
+
+ tree lhs = fold_build2 (MINUS_EXPR, TREE_TYPE (uop), uop, min);
+ tree rhs = int_const_binop (MINUS_EXPR, max, min);
+ register_new_assert_for (op, lhs, GT_EXPR, rhs,
+  NULL, default_edge, bsi);
+   }
+}
+
   XD

Re: [PATCH] Teach VRP to register assertions along default switch labels (PR 18046)

[Patrick Palka]

On Fri, 22 Jul 2016, Patrick Palka wrote:

> This patch teaches VRP to register along a default switch label
> assertions that corresponds to the anti range of each case label.
> 
> Does this look OK to commit after bootstrap + regtest on
> x86_64-pc-linux-gnu?

Forgot the changelog:

gcc/ChangeLog:

PR tree-optimization/18046
* tree-vrp.c (find_switch_asserts): Register edge assertions
for the default label which correspond to the anti-ranges
of each non-case label.

gcc/testsuite/ChangeLog:

PR tree-optimization/18046
* gcc.dg/tree-ssa/ssa-dom-thread-6.c: Bump FSM count to 5.
* gcc.dg/tree-ssa/vrp103.c: New test.
* gcc.dg/tree-ssa/vrp104.c: New test.

> ---
>  gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-6.c |  2 +-
>  gcc/testsuite/gcc.dg/tree-ssa/vrp103.c   | 30 ++
>  gcc/testsuite/gcc.dg/tree-ssa/vrp104.c   | 32 +++
>  gcc/tree-vrp.c   | 39 
> ++--
>  4 files changed, 100 insertions(+), 3 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/vrp103.c
>  create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/vrp104.c
> 
> diff --git a/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-6.c 
> b/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-6.c
> index 5ec4687..551fbac 100644
> --- a/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-6.c
> +++ b/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-6.c
> @@ -1,7 +1,7 @@
>  /* { dg-do compile } */
>  /* { dg-options "-O2 -fdump-tree-thread1-details 
> -fdump-tree-thread2-details" } */
>  /* { dg-final { scan-tree-dump-times "FSM" 3 "thread1" } } */
> -/* { dg-final { scan-tree-dump-times "FSM" 4 "thread2" } } */
> +/* { dg-final { scan-tree-dump-times "FSM" 5 "thread2" } } */
>  
>  int sum0, sum1, sum2, sum3;
>  int foo (char *s, char **ret)
> diff --git a/gcc/testsuite/gcc.dg/tree-ssa/vrp103.c 
> b/gcc/testsuite/gcc.dg/tree-ssa/vrp103.c
> new file mode 100644
> index 000..eea98bb
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/tree-ssa/vrp103.c
> @@ -0,0 +1,30 @@
> +/* PR tree-optimization/18046  */
> +/* { dg-options "-O2 -fdump-tree-vrp" }  */
> +/* { dg-final { scan-tree-dump-times "baz \\(0\\);" 4 "vrp1" } }  */
> +
> +void foo ();
> +void bar ();
> +void baz (int);
> +
> +void
> +test (int i)
> +{
> +  switch (i)
> +{
> +case 1:
> +case 2:
> +case 3:
> +  foo ();
> +  break;
> +case 5:
> +  bar ();
> +  break;
> +default:
> +  /* These tests should be folded to 0, resulting in 4 calls to bar (0). 
>  */
> +  baz (i == 1);
> +  baz (i == 2);
> +  baz (i == 3);
> +  baz (i == 5);
> +  break;
> +}
> +}
> diff --git a/gcc/testsuite/gcc.dg/tree-ssa/vrp104.c 
> b/gcc/testsuite/gcc.dg/tree-ssa/vrp104.c
> new file mode 100644
> index 000..6410847
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/tree-ssa/vrp104.c
> @@ -0,0 +1,32 @@
> +/* PR tree-optimization/18046  */
> +/* { dg-options "-O2 -fdump-tree-optimized" }  */
> +/* { dg-final { scan-tree-dump-times "switch" 1 "optimized" } }  */
> +
> +void foo ();
> +void bar ();
> +
> +void
> +test (int i)
> +{
> +  switch (i)
> +{
> +case 1:
> +  foo ();
> +  break;
> +case 2:
> +  bar ();
> +  break;
> +default:
> +  break;
> +}
> +
> +  /* This switch should be gone after threading/VRP.  */
> +  switch (i)
> +{
> +case 1:
> +  foo ();
> +  break;
> +default:
> +  break;
> +}
> +}
> diff --git a/gcc/tree-vrp.c b/gcc/tree-vrp.c
> index 06364b7..32a4de3 100644
> --- a/gcc/tree-vrp.c
> +++ b/gcc/tree-vrp.c
> @@ -5917,6 +5917,7 @@ find_switch_asserts (basic_block bb, gswitch *last)
>ci[idx].expr = gimple_switch_label (last, idx);
>ci[idx].bb = label_to_block (CASE_LABEL (ci[idx].expr));
>  }
> +  edge default_edge = find_edge (bb, ci[0].bb);
>qsort (ci, n, sizeof (struct case_info), compare_case_labels);
>  
>for (idx = 0; idx < n; ++idx)
> @@ -5945,8 +5946,8 @@ find_switch_asserts (basic_block bb, gswitch *last)
>   max = CASE_LOW (ci[idx].expr);
>   }
>  
> -  /* Nothing to do if the range includes the default label until we
> -  can register anti-ranges.  */
> +  /* Can't extract a useful assertion out of a range that includes the
> + default label.  */
>if (min == NULL_TREE)
>   continue;
>  
> @@ -5963,6 +5964,40 @@ find_switch_asserts (basic_block bb, gswitch *last)
> fold_convert (TREE_TYPE (op), max));
>  }
>  
> +  /* For each case label, register along the default label an assertion that
> + corresponds to the anti-range of that label.  */
> +  for (idx = 0; idx < n; ++idx)
> +{
> +  tree min, max;
> +  tree cl = ci[idx].expr;
> +
> +  min = CASE_LOW (cl);
> +  max = CASE_HIGH (cl);
> +
> +  if (min == NULL_TREE)
> + continue;
> +
> +  if (max == NULL_TREE)
> + {
> +   /* Reg

[PATCH], Fix PowerPC multi-line string formating issue

[Michael Meissner]

In working on the vector extracts, I noticed that the function
altivec_resolve_overloaded_builtin has two strings that span more than one
line.  This confuses the diff -p command, as it thinks modified code after the
long line is in another function.

This patch fixes the formatting.  I did a bootstrap and make check, and there
were no regressions.  Is it ok to change into the trunk?

2016-07-22  Michael Meissner  

* config/rs6000/rs6000-c.c (altivec_resolve_overloaded_builtin):
Reformat two multi-line strings.

Index: gcc/config/rs6000/rs6000-c.c
===
--- gcc/config/rs6000/rs6000-c.c(revision 238490)
+++ gcc/config/rs6000/rs6000-c.c(working copy)
@@ -4731,11 +4731,13 @@ altivec_resolve_overloaded_builtin (loca
  
   /* vec_lvsl and vec_lvsr are deprecated for use with LE element order.  */
   if (fcode == ALTIVEC_BUILTIN_VEC_LVSL && !VECTOR_ELT_ORDER_BIG)
-warning (OPT_Wdeprecated, "vec_lvsl is deprecated for little endian; use \
-assignment for unaligned loads and stores");
+warning (OPT_Wdeprecated,
+"vec_lvsl is deprecated for little endian; use "
+"assignment for unaligned loads and stores");
   else if (fcode == ALTIVEC_BUILTIN_VEC_LVSR && !VECTOR_ELT_ORDER_BIG)
-warning (OPT_Wdeprecated, "vec_lvsr is deprecated for little endian; use \
-assignment for unaligned loads and stores");
+warning (OPT_Wdeprecated,
+"vec_lvsr is deprecated for little endian; use "
+"assignment for unaligned loads and stores");
 
   if (fcode == ALTIVEC_BUILTIN_VEC_MUL)
 {

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797

[PR fortran/71862] Patch

[Steve Kargl]

I intend to commit the following patch and close the
PR in approximate 6.283 hours.

2016-07-22  Steven G. Kargl  

PR fortran/71862
* class.c: Remove assert.  Iterate over component only if non-null.

 
2016-07-22  Steven G. Kargl  

PR fortran/71862
* gfortran.dg/pr71862.f90: New test.

Index: gcc/fortran/class.c
===
--- gcc/fortran/class.c (revision 238665)
+++ gcc/fortran/class.c (working copy)
@@ -238,12 +238,14 @@ gfc_add_component_ref (gfc_expr *e, cons
 /* Avoid losing memory.  */
 gfc_free_ref_list (*tail);
   c = gfc_find_component (derived, name, true, true, tail);
-  gcc_assert (c);
-  for (ref = *tail; ref->next; ref = ref->next)
-;
-  ref->next = next;
-  if (!next)
-e->ts = c->ts;
+
+  if (c) {
+for (ref = *tail; ref->next; ref = ref->next)
+  ;
+ref->next = next;
+if (!next)
+  e->ts = c->ts;
+  }
 }
 
 
Index: gcc/testsuite/gfortran.dg/pr71862.f90
===
--- gcc/testsuite/gfortran.dg/pr71862.f90   (nonexistent)
+++ gcc/testsuite/gfortran.dg/pr71862.f90   (working copy)
@@ -0,0 +1,16 @@
+! { dg-do compile }
+program p
+   type t
+  integer :: n = 0
+  integer, pointer :: q => null()
+   end type
+   type(t) :: x
+   print *, associated(x%q)
+   x = f()
+   print *, associated(x%q)
+contains
+   function f() result (z)! { dg-error "must be dummy, allocatable or 
pointer" }
+  class(t) :: z
+  print *, associated(z%q)
+   end
+end

-- 
Steve

Re: [PATCH] - improve sprintf buffer overflow detection (middle-end/49905)

[Jakub Jelinek]

On Mon, Jul 18, 2016 at 03:59:11PM -0600, Martin Sebor wrote:
> +  /* Try to use __builtin_object_size although it rarely returns
> + a useful result even for straighforward cases.  */
> +  tree ost = warn_format_length < 2
> +? integer_zero_node : build_int_cst (size_type_node, 2);
> +  tree args[] = { dest, ost };
> +  tree func = builtin_decl_explicit (BUILT_IN_OBJECT_SIZE);
> +  if (tree size = fold_builtin_n (UNKNOWN_LOCATION, func, args, 2, false))

What is the point of going through fold etc.?  You can just
(for ADDR_EXPR and SSA_NAME) call compute_builtin_object_size without,
and don't have to convert the result back to tree and then back to uhwi.

> +return tree_to_uhwi (STRIP_NOPS  (size));

Formatting.
> +
> +  /* If __builtin_object_size fails to deliver, try to compute
> + it for the very basic (but common) cases.  */
> +  if (TREE_CODE (dest) == SSA_NAME
> +  && POINTER_TYPE_P (TREE_TYPE (dest)))
> +{
> +  gimple *def = SSA_NAME_DEF_STMT (dest);
> +  if (gimple_code (def) == GIMPLE_ASSIGN)

is_gimple_assign (def) ?

> + {
> +   tree_code code = gimple_assign_rhs_code (def);
> +   if (code == POINTER_PLUS_EXPR)
> + {
> +   tree off = gimple_assign_rhs2 (def);
> +   dest = gimple_assign_rhs1 (def);
> +
> +   if (cst_and_fits_in_hwi (off))
> + {
> +   unsigned HOST_WIDE_INT size = get_destination_size (dest);
> +   if (size != HOST_WIDE_INT_M1U)
> + return size - tree_to_shwi (off);
> + }

I think you need to be very careful on negative offsets here (or don't allow
them).

> + }

Shouldn't this have some upper bound for the recursion?
E.g. PARAM_VALUE (PARAM_MAX_SSA_NAME_QUERY_DEPTH)?
> + }
> +}
> +
> +  return -1;
> +}

Jakub

Re: [PR fortran/71862] Patch

[Paul Richard Thomas]

Hi Steve,

It looks good to me. OK to commit for as far back as you have a mind to go.

Cheers

Paul

On 22 July 2016 at 21:52, Steve Kargl  wrote:
> I intend to commit the following patch and close the
> PR in approximate 6.283 hours.
>
> 2016-07-22  Steven G. Kargl  
>
> PR fortran/71862
> * class.c: Remove assert.  Iterate over component only if non-null.
>
>
> 2016-07-22  Steven G. Kargl  
>
> PR fortran/71862
> * gfortran.dg/pr71862.f90: New test.
>
> Index: gcc/fortran/class.c
> ===
> --- gcc/fortran/class.c (revision 238665)
> +++ gcc/fortran/class.c (working copy)
> @@ -238,12 +238,14 @@ gfc_add_component_ref (gfc_expr *e, cons
>  /* Avoid losing memory.  */
>  gfc_free_ref_list (*tail);
>c = gfc_find_component (derived, name, true, true, tail);
> -  gcc_assert (c);
> -  for (ref = *tail; ref->next; ref = ref->next)
> -;
> -  ref->next = next;
> -  if (!next)
> -e->ts = c->ts;
> +
> +  if (c) {
> +for (ref = *tail; ref->next; ref = ref->next)
> +  ;
> +ref->next = next;
> +if (!next)
> +  e->ts = c->ts;
> +  }
>  }
>
>
> Index: gcc/testsuite/gfortran.dg/pr71862.f90
> ===
> --- gcc/testsuite/gfortran.dg/pr71862.f90   (nonexistent)
> +++ gcc/testsuite/gfortran.dg/pr71862.f90   (working copy)
> @@ -0,0 +1,16 @@
> +! { dg-do compile }
> +program p
> +   type t
> +  integer :: n = 0
> +  integer, pointer :: q => null()
> +   end type
> +   type(t) :: x
> +   print *, associated(x%q)
> +   x = f()
> +   print *, associated(x%q)
> +contains
> +   function f() result (z)! { dg-error "must be dummy, allocatable or 
> pointer" }
> +  class(t) :: z
> +  print *, associated(z%q)
> +   end
> +end
>
> --
> Steve



-- 
The difference between genius and stupidity is; genius has its limits.

Albert Einstein

Re: [libstdc++] Add C++17clamp

[NightStrike]

Would it be possible to fix the missed optimization to give the better
asm without having to do -ffast-math as mentioned here:

https://gcc.gnu.org/ml/gcc-help/2014-11/msg00034.html

If so, then the proposed implementation would be optimized for the simple case.


On Fri, Jul 22, 2016 at 3:55 AM, Jonathan Wakely  wrote:
> On 22/07/16 08:51 +0100, Jonathan Wakely wrote:
>>
>> On 21/07/16 19:38 -0400, NightStrike wrote:
>>>
>>> On Thu, Jul 14, 2016 at 7:50 PM, Ed Smith-Rowland <3dw...@verizon.net>
>>> wrote:

 Here is an implementation of P0025
 An algorithm to "clamp" a value between a pair of boundary values.

 Testing is almost finished - looks good so far.

 OK if testing passes?

 I didn't see a feature test in any of the SD-6 papers or P0025.

>>>
>>> This is not an efficient implementation.  See here:
>>>
>>> https://gcc.gnu.org/ml/gcc-help/2014-10/msg00112.html
>>>
>>> Which I derived from this SO answer (which is sadly not the accepted
>>> answer at this time):
>>>
>>> http://stackoverflow.com/a/16659263
>>>
>>> I suggest using the very efficient method that requires a temporary.
>>
>>
>> That isn't a valid implementation of std::clamp, since it performs a
>> copy. The template argument might not even be copyable.
>
>
>
> We could possibly dispatch to such an implementation for arithmetic
> types, but we wouldn't want to do it for all copyable types. There's
> no way you can know whether making that local copy is expensive for an
> arbitrary type, and making a copy isn't allowed anyway.
>

[PR fortran/71859] Patch

[Steve Kargl]

I intend to commit the following patch in approximately
2 * exp(1.) = 5.436 hours.

2016-07-22  Steven G. Kargl  

PR fortran/71859
* check.c(numeric_check): Prevent ICE.  Issue error for invalid
subroutine as an actual argument when numeric argument is expected.

2016-07-22  Steven G. Kargl  

PR fortran/71859
* gfortran.dg/pr71859.f90: New test.
* gfortran.dg/intrinsic_numeric_arg.f: Update error message.
* gfortran.dg/coarray_collectives_1.f90: Ditto.


Index: gcc/fortran/check.c
===
--- gcc/fortran/check.c (revision 238665)
+++ gcc/fortran/check.c (working copy)
@@ -72,6 +72,11 @@ type_check (gfc_expr *e, int n, bt type)
 static bool
 numeric_check (gfc_expr *e, int n)
 {
+  /* Users sometime use a subroutine designator as an actual argument to
+ an intrinsic subprogram that expects an argument with a numeric type.  */
+  if (e->symtree && e->symtree->n.sym->attr.subroutine)
+goto bandaid;
+
   if (gfc_numeric_ts (&e->ts))
 return true;
 
@@ -86,7 +91,9 @@ numeric_check (gfc_expr *e, int n)
   return true;
 }
 
-  gfc_error ("%qs argument of %qs intrinsic at %L must be a numeric type",
+bandaid:
+
+  gfc_error ("%qs argument of %qs intrinsic at %L must have a numeric type",
 gfc_current_intrinsic_arg[n]->name, gfc_current_intrinsic,
 &e->where);
 
Index: gcc/testsuite/gfortran.dg/pr71859.f90
===
--- gcc/testsuite/gfortran.dg/pr71859.f90   (nonexistent)
+++ gcc/testsuite/gfortran.dg/pr71859.f90   (working copy)
@@ -0,0 +1,8 @@
+! { dg-do compile }
+program p
+   call s(1)
+   x = abs(s)  ! { dg-error "must have a numeric type" }
+end
+subroutine s(n)
+   print *, n
+end
Index: gcc/testsuite/gfortran.dg/intrinsic_numeric_arg.f
===
--- gcc/testsuite/gfortran.dg/intrinsic_numeric_arg.f   (revision 238665)
+++ gcc/testsuite/gfortran.dg/intrinsic_numeric_arg.f   (working copy)
@@ -4,6 +4,6 @@
LOGICAL Z
CHARACTER A
REAL R
-   R = ABS(Z) !  { dg-error " must be a numeric type" }
-   R = ABS(A) !  { dg-error " must be a numeric type" }
+   R = ABS(Z) !  { dg-error " must have a numeric type" }
+   R = ABS(A) !  { dg-error " must have a numeric type" }
END
Index: gcc/testsuite/gfortran.dg/coarray_collectives_1.f90
===
--- gcc/testsuite/gfortran.dg/coarray_collectives_1.f90 (revision 238665)
+++ gcc/testsuite/gfortran.dg/coarray_collectives_1.f90 (working copy)
@@ -14,7 +14,7 @@ program test
   integer(8) :: i8
   character(len=19, kind=4) :: msg4
 
-  call co_sum("abc") ! { dg-error "must be a numeric type" }
+  call co_sum("abc") ! { dg-error "must have a numeric type" }
   call co_max(cmplx(1.0,0.0)) ! { dg-error "shall be of type integer, real or 
character" }
   call co_min(cmplx(0.0,1.0)) ! { dg-error "shall be of type integer, real or 
character" }
 
-- 
Steve

Merge from trunk to gccgo branch

[Ian Lance Taylor]

I merged trunk revision 238662 to the gccgo branch.

Ian

Implement C _FloatN, _FloatNx types [version 5]

[Joseph Myers]

[Version 5 is respun to apply without conflicts to current sources but
has no other changes.]


ISO/IEC TS 18661-3:2015 defines C bindings to IEEE interchange and
extended types, in the form of _FloatN and _FloatNx type names with
corresponding fN/FN and fNx/FNx constant suffixes and FLTN_* / FLTNX_*
 macros.  This patch implements support for this feature in
GCC.

The _FloatN types, for N = 16, 32, 64 or >= 128 and a multiple of 32,
are types encoded according to the corresponding IEEE interchange
format (endianness unspecified; may use either the NaN conventions
recommended in IEEE 754-2008, or the MIPS NaN conventions, since the
choice of convention is only an IEEE recommendation, not a
requirement).  The _FloatNx types, for N = 32, 64 and 128, are IEEE
"extended" types: types extending a narrower format with range and
precision at least as big as those specified in IEEE 754 for each
extended type (and with unspecified representation, but still
following IEEE semantics for their values and operations - and with
the set of values being determined by the precision and the maximum
exponent, which means that while Intel "extended" is suitable for
_Float64x, m68k "extended" is not).  These types are always distinct
from and not compatible with each other and the standard floating
types float, double, long double; thus, double, _Float64 and _Float32x
may all have the same ABI, but they are three still distinct types.
The type names may be used with _Complex to construct corresponding
complex types (unlike __float128, which acts more like a typedef name
than a keyword - thus, this patch may be considered to fix PR
c/32187).  The new suffixes can be combined with GNU "i" and "j"
suffixes for constants of complex types (e.g. 1.0if128, 2.0f64i).

The set of types supported is implementation-defined.  In this GCC
patch, _Float32 is SFmode if that is suitable; _Float32x and _Float64
are DFmode if that is suitable; _Float128 is TFmode if that is
suitable; _Float64x is XFmode if that is suitable, and otherwise
TFmode if that is suitable.  There is a target hook to override the
choices if necessary.  "Suitable" means both conforming to the
requirements of that type, and supported as a scalar type including in
libgcc.  The ABI is whatever the back end does for scalars of that
mode (but note that _Float32 is passed without promotion in variable
arguments, unlike float).  All the existing issues with exceptions and
rounding modes for existing types apply equally to the new type names.

No GCC port supports a floating-point format suitable for _Float128x.
Although there is HFmode support for ARM and AArch64, use of that for
_Float16 is not enabled.  Supporting _Float16 would require additional
work on the excess precision aspects of TS 18661-3: there are new
values of FLT_EVAL_METHOD, which are not currently supported in GCC,
and FLT_EVAL_METHOD == 0 now means that operations and constants on
types narrower than float are evaluated to the range and precision of
float.  Implementing that, so that _Float16 gets evaluated with excess
range and precision, would involve changes to the excess precision
infrastructure so that the _Float16 case is enabled by default, unlike
the x87 case which is only enabled for -fexcess-precision=standard.
Other differences between _Float16 and __fp16 would also need to be
disentangled.

GCC has some prior support for nonstandard floating-point types in the
form of __float80 and __float128.  Where these were previously types
distinct from long double, they are made by this patch into aliases
for _Float64x / _Float128 if those types have the required properties.

In principle the set of possible _FloatN types is infinite.  This
patch hardcodes the four such types for N <= 128, but with as much
code as possible using loops over types to minimize the number of
places with such hardcoding.  I don't think it's likely any further
such types will be of use in future (or indeed that formats suitable
for _Float128x will actually be implemented).  There is a corner case
that all _FloatN, for N >= 128 and a multiple of 32, should be treated
as keywords even when the corresponding type is not supported; I
intend to deal with that in a followup patch.

Tests are added for various functionality of the new types, mostly
using type-generic headers.  PowerPC maintainers should note that the
tests do not do anything regarding passing special options to enable
support for the types, either for the tests themselves or for the
corresponding effective-target tests.  Thus, to run the _Float128
tests on PowerPC, you will need to add such support, { dg-add-options
float128 } or similar and make sure it affects both the
effective-target tests and the tests themselves.  The complex
arithmetic support in libgcc will also be needed, as otherwise the
associated tests will fail.  (The same would apply to _Float16 on ARM
as well if that were enabled with -mfp16-format=ieee required to use
it.  Of course, -mfp16-format=alternat

Re: [PATCH], Fix PowerPC multi-line string formating issue

[Segher Boessenkool]

On Fri, Jul 22, 2016 at 03:51:31PM -0400, Michael Meissner wrote:
> In working on the vector extracts, I noticed that the function
> altivec_resolve_overloaded_builtin has two strings that span more than one
> line.  This confuses the diff -p command, as it thinks modified code after the
> long line is in another function.
> 
> This patch fixes the formatting.  I did a bootstrap and make check, and there
> were no regressions.  Is it ok to change into the trunk?

Does that work for gettext?  Okay for trunk if so, thanks!


Segher


>/* vec_lvsl and vec_lvsr are deprecated for use with LE element order.  */
>if (fcode == ALTIVEC_BUILTIN_VEC_LVSL && !VECTOR_ELT_ORDER_BIG)
> -warning (OPT_Wdeprecated, "vec_lvsl is deprecated for little endian; use 
> \
> -assignment for unaligned loads and stores");
> +warning (OPT_Wdeprecated,
> +  "vec_lvsl is deprecated for little endian; use "
> +  "assignment for unaligned loads and stores");
>else if (fcode == ALTIVEC_BUILTIN_VEC_LVSR && !VECTOR_ELT_ORDER_BIG)
> -warning (OPT_Wdeprecated, "vec_lvsr is deprecated for little endian; use 
> \
> -assignment for unaligned loads and stores");
> +warning (OPT_Wdeprecated,
> +  "vec_lvsr is deprecated for little endian; use "
> +  "assignment for unaligned loads and stores");

Re: [PATCH] - improve sprintf buffer overflow detection (middle-end/49905)

[Jeff Law]

Working through the new pass...  Overall it looks pretty good.  There's 
a certain level of trust I'll extend WRT getting the low level details 
right -- a thorough testsuite obviously helps there.





+const pass_data pass_data_sprintf_length = {
+  GIMPLE_PASS,// pass type
+  "sprintf_length",   // pass name
+  OPTGROUP_NONE,  // optinfo_flags
+  TV_NONE,// tv_id
+  PROP_cfg,   // properties_required
+  0, // properties_provided
+  0, // properties_destroyed
+  0, // properties_start
+  0, // properties_finish
So the worry here is that you need PROP_ssa in the late pass.  I'm not 
sure if we have the infrastructure to allow you to distinguish the two. 
I guess we could literally make it two passes with two distinct 
pass_data structures.



In handle_gimple_call, you don't handle anti ranges -- I haven't looked 
closely at canonicalization rules in VRP, so I don't know if you're 
likely to see a range like ![MININT, -1] which would be a synonym for 
[0..MAXINT].  It might be worth doing some instrumentation to see if 
you're getting useful anti-ranges with any kind of consistency.  ISTM 
the most interesting ones are going to allow you to drop or insist on a 
"-" sign.





+  /* As a special case, bounded function allow the explicitly
+specified destination size argument to be zero as a request
+to determine the number of bytes on output without actually
+writing any output.  Disable length checking for those.  */

This doesn't parse well.



+  /* Try to use __builtin_object_size although it rarely returns
+ a useful result even for straighforward cases.  */
Hopefully you've stashed away some tests for this so that we can work on 
them independently of the sprintf checking itself?  ISTM that the 
recursive handling of POINTER_PLUS_EXPR really ought to move into the 
generic builtin_object_size handling itself as an independent change.





+  /* Bail early if format length checking is disabled, either
+ via a command line option, or as a result of the size of
+ the destination object not being available, or due to
+ format directives or arguments encountered during processing
+ that prevent length tracking with any reliability.  */
+
+  if (HOST_WIDE_INT_MAX <= info.objsize)
+  return;

I think the return is indented too deep.


+  if (*pf == 0)
+   {
+ /* Incomplete directive.  */
+ return;
+   }
For this and the other early returns from compute_format_length, do we 
know if -Wformat will catch these errors?  Might that be a low priority 
follow-up project if it doesn't?




+static void
+add_bytes (const pass_sprintf_length::call_info &info,
+  const char   *beg,
+  const char   *end,
+  format_result*res)
In general, don't try to line up parameters, args or variable 
declarations like you've done here.  Similarly in other places.



+  /* if (warn_format_length */
+  /* && (overflowed || navail < nbytes */
+  /* || (1 < warn_format_length && )) */

Presumably old implementation and/or debugging code...  Please remove it.

Please check indention of the curleys & code block in the loop over the 
phi arguments in get_string_length.



In format_floating, we end up using actual host floating point 
arithmetic.  That's generally been frowned upon.  We're not doing 
anything in terms of code generation here, so ultimately that might be 
what allows us to still be safe from a cross compilation standpoint.


It's also not clear if that routine handles the other target floating 
point formats.  For things like VAX FP, I'm comfortable issuing a 
warning that this stuff isn't supported on that target.   We have other 
targets where a double might be the same size as a float.   Though I 
guess in that case the worst we get is false positives, so that may not 
be a huge issue either.  I'm not sure how to check for this stuff 
without bringing in aspects of the target though, which we'd like to avoid.


In format_integer you have target specific ifdefs (solaris and aix). 
First we want to avoid conditionally compiled code.  Second, from a 
modularity something like TARGET_AIX and TARGET_SOLARIS really aren't 
appropriate in here. I suspect what you're going to want to do is add 
something to the targetm structure that you can query and/or call here 
is the best we can do.


Again, overall it looks good.  My biggest concern is format_integer and 
format_float and the bleeding of target dependencies into this code.  To 
some degree it may be unavoidable and we can mitigate the damage with 
stuff in targetm -- I'd like to hear your thoughts.


Jeff

Re: [PATCH, contrib] download_prerequisites: check for existing symlinks before making new ones

[Jeff Law]

On 07/21/2016 12:15 PM, Bernd Edlinger wrote:

Hi,

 > So rather than relying on ln to remove the link, why don't we just
 > explicitly remove it with rm -f?

sounds good, I ran into similar issues already.

ln -nfs does not follow the target if it is a symlink

-n, --no-dereference
   treat  LINK_NAME  as a normal file if it is a symbolic
link to a
   directory


but I think a simple rm -f will do as well, and avoid potential
interoperability issues.

However wget has a similar issue, if the $MPFR.tar.gz file is already
there, maybe incomplete, the wget chooses a new name, so I'd suggest
to rm -f that file as well, and the whole $MPFR subtree while you are
already there.
Agreed.  And naturally the question is do we bother to check the return 
code from the rm -f?  I think we should and exit with an error if it fails.


jeff

C++ PATCH for c++/71748 (call to base dtor in template)

[Jason Merrill]

The fix for 52746 was incomplete; it didn't propagate the
adjust_result_of_qualified_name_lookup handling from lookup_destructor
to tsubst_baselink.  Fixed thus.

Tested x86_64-pc-linux-gnu, applying to trunk.

Re: C++ PATCH for c++/71748 (call to base dtor in template)

[Jason Merrill]

On Fri, Jul 22, 2016 at 7:32 PM, Jason Merrill  wrote:
> The fix for 52746 was incomplete; it didn't propagate the
> adjust_result_of_qualified_name_lookup handling from lookup_destructor
> to tsubst_baselink.  Fixed thus.
>
> Tested x86_64-pc-linux-gnu, applying to trunk.
commit 732dce1a04cbe7d9d6edcbb2abe6a403541a9560
Author: Jason Merrill 
Date:   Fri Jul 22 12:57:48 2016 -0400

PR c++/71748 - call to base destructor in template.

PR c++/52746
* pt.c (tsubst_baselink): Call
adjust_result_of_qualified_name_lookup for unqualified
destructors.

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 5e29d99..3ee53d1 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -13760,10 +13760,17 @@ tsubst_baselink (tree baselink, tree object_type,
 if (!object_type)
   object_type = current_class_type;
 
-if (qualified)
-  baselink = adjust_result_of_qualified_name_lookup (baselink,
-qualifying_scope,
-object_type);
+if (qualified || name == complete_dtor_identifier)
+  {
+   baselink = adjust_result_of_qualified_name_lookup (baselink,
+  qualifying_scope,
+  object_type);
+   if (!qualified)
+ /* We need to call adjust_result_of_qualified_name_lookup in case the
+destructor names a base class, but we unset BASELINK_QUALIFIED_P
+so that we still get virtual function binding.  */
+ BASELINK_QUALIFIED_P (baselink) = false;
+  }
 return baselink;
 }
 
diff --git a/gcc/testsuite/g++.dg/template/dtor10.C 
b/gcc/testsuite/g++.dg/template/dtor10.C
new file mode 100644
index 000..4307a68
--- /dev/null
+++ b/gcc/testsuite/g++.dg/template/dtor10.C
@@ -0,0 +1,23 @@
+// PR c++/71748
+
+struct A
+{ 
+  virtual ~A () {}
+};
+
+struct B : public A
+{ 
+  virtual ~B () {}
+};
+
+template < int > void foo ()
+{ 
+  B *b = new B;
+  b->~A ();
+}
+
+int main ()
+{ 
+  foo < 0 > ();
+  return 0;
+}

C++ PATCH for c++/71350 (error recursion with initializer-list)

[Jason Merrill]

Here the problem was just that we were failing to check complain for
the missing braces warning.

Tested x86_64-pc-linux-gnu, applying to trunk.
commit 9d4ef5496bdd42e5986a06089901631983b04846
Author: Jason Merrill 
Date:   Fri Jul 22 14:42:53 2016 -0400

PR c++/71515 - typename in partial specialization

* pt.c (resolve_typename_type): Check currently_open_class later.

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 3ee53d1..7758f44 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -23675,10 +23675,6 @@ resolve_typename_type (tree type, bool only_current_p)
  resolving the name.  */
   if (TREE_CODE (scope) == TEMPLATE_TYPE_PARM)
 return type;
-  /* If the SCOPE is not the current instantiation, there's no reason
- to look inside it.  */
-  if (only_current_p && !currently_open_class (scope))
-return type;
   /* If this is a typedef, we don't want to look inside (c++/11987).  */
   if (typedef_variant_p (type))
 return type;
@@ -23693,6 +23689,10 @@ resolve_typename_type (tree type, bool only_current_p)
 /* scope is a partial instantiation, so we can't do the lookup or we
will lose the template arguments.  */
 return type;
+  /* If the SCOPE is not the current instantiation, there's no reason
+ to look inside it.  */
+  if (only_current_p && !currently_open_class (scope))
+return type;
   /* Enter the SCOPE so that name lookup will be resolved as if we
  were in the class definition.  In particular, SCOPE will no
  longer be considered a dependent type.  */
diff --git a/gcc/testsuite/g++.dg/template/typename22.C 
b/gcc/testsuite/g++.dg/template/typename22.C
new file mode 100644
index 000..b5dc1b5
--- /dev/null
+++ b/gcc/testsuite/g++.dg/template/typename22.C
@@ -0,0 +1,8 @@
+// PR c++/71515
+
+template < typename, typename = int > struct A;
+
+template < typename T > struct A < T, typename A < T >::type >
+{
+  A < int > *a;
+};

Re: [libstdc++] Add C++17clamp

[Jonathan Wakely]

On 22/07/16 17:12 -0400, NightStrike wrote:

Would it be possible to fix the missed optimization to give the better
asm without having to do -ffast-math as mentioned here:

https://gcc.gnu.org/ml/gcc-help/2014-11/msg00034.html

If so, then the proposed implementation would be optimized for the simple case.


If you want a missed optimization fixed then you should report it to
bugzilla, not on these lists.

Re: [PATCH] Teach VRP to register assertions along default switch labels (PR 18046)

[Patrick Palka]

On Fri, 22 Jul 2016, Patrick Palka wrote:

> On Fri, 22 Jul 2016, Patrick Palka wrote:
> 
> > This patch teaches VRP to register along a default switch label
> > assertions that corresponds to the anti range of each case label.
> > 
> > Does this look OK to commit after bootstrap + regtest on
> > x86_64-pc-linux-gnu?
> 
> Forgot the changelog:
> 
> gcc/ChangeLog:
> 
>   PR tree-optimization/18046
>   * tree-vrp.c (find_switch_asserts): Register edge assertions
>   for the default label which correspond to the anti-ranges
>   of each non-case label.
> 
> gcc/testsuite/ChangeLog:
> 
>   PR tree-optimization/18046
>   * gcc.dg/tree-ssa/ssa-dom-thread-6.c: Bump FSM count to 5.
>   * gcc.dg/tree-ssa/vrp103.c: New test.
>   * gcc.dg/tree-ssa/vrp104.c: New test.
> 

The patch failed to bootstrap due to a number -Warray-bounds warnings
getting emitted for the autogenerated header file insn-modes.h:

In file included from /home/patrick/code/gcc/gcc/machmode.h:24:0,
 from /home/patrick/code/gcc/gcc/coretypes.h:391,
 from /home/patrick/code/gcc/gcc/lto-streamer-out.c:25:
./insn-modes.h: In function ‘void produce_asm_for_decls()’:
./insn-modes.h:638:36: warning: array subscript is outside array bounds 
[-Warray-bounds]
 default: return mode_inner[mode];
 ~~~^

These new warnings seem legitimate.  From what I can tell, this array
access along the default switch label will always be out of bounds.  The
code it's warning about basically looks like this:

  enum A { a, b, c };
  int foo (A i)
  {
int array[3];
switch (i)
{
  case a: return x;
  case b: return y;
  case c: return z;
  default: return array[i];
}
  }

and while the switch does exhaust every possible enumeration value of A,
there's nothing stopping the user from passing an arbitrary int to
foo() thus triggering the default case.  So this patch suppresses these
warnings by making genemit emit an assertion that verifies that mode is
within the bounds of the array.  This assertion won't affect performance
because the mode_*_inline functions are always called with constant
arguments.

This version of the patch has the following changes:

1. Fixes the bootstrap failure as mentioned above.
2. Checks if the switch operand is live along the default edge before
registering assertions.
3. Combines contiguous case ranges to reduce the number of assert
expressions to insert.

Bootstrap + regtesting in progress on x86_64-pc-linux-gnu.

gcc/ChangeLog:

PR tree-optimization/18046
* genmodes.c (emit_mode_size_inline): Emit an assert that
verifies that mode is a valid array index.
(emit_mode_nuinits_inline): Likewise.
(emit_mode_inner_inline): Likewise.
(emit_mode_unit_size_inline): Likewise.
(emit_mode_unit_precision_inline): Likewise.
* tree-vrp.c (compare_case_label_values): New qsort callback.
(find_switch_asserts): Register edge assertions for
the default label, which correspond to the anti-range of each
non-case label.

gcc/testsuite/ChangeLog:

PR tree-optimization/18046
* gcc.dg/tree-ssa/ssa-dom-thread-6.c: Bump FSM count to 5.
* gcc.dg/tree-ssa/vrp103.c: New test.
* gcc.dg/tree-ssa/vrp104.c: New test.
---
 gcc/genmodes.c   |  5 ++
 gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-6.c |  2 +-
 gcc/testsuite/gcc.dg/tree-ssa/vrp103.c   | 30 +
 gcc/testsuite/gcc.dg/tree-ssa/vrp104.c   | 32 +
 gcc/tree-vrp.c   | 85 +++-
 5 files changed, 151 insertions(+), 3 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/vrp103.c
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/vrp104.c

diff --git a/gcc/genmodes.c b/gcc/genmodes.c
index 097cc80..1170d4f 100644
--- a/gcc/genmodes.c
+++ b/gcc/genmodes.c
@@ -976,6 +976,7 @@ unsigned char\n\
 mode_size_inline (machine_mode mode)\n\
 {\n\
   extern %sunsigned char mode_size[NUM_MACHINE_MODES];\n\
+  gcc_assert (mode >= 0 && mode < NUM_MACHINE_MODES);\n\
   switch (mode)\n\
 {\n", adj_bytesize ? "" : "const ");
 
@@ -1006,6 +1007,7 @@ unsigned char\n\
 mode_nunits_inline (machine_mode mode)\n\
 {\n\
   extern const unsigned char mode_nunits[NUM_MACHINE_MODES];\n\
+  gcc_assert (mode >= 0 && mode < NUM_MACHINE_MODES);\n\
   switch (mode)\n\
 {");
 
@@ -1035,6 +1037,7 @@ unsigned char\n\
 mode_inner_inline (machine_mode mode)\n\
 {\n\
   extern const unsigned char mode_inner[NUM_MACHINE_MODES];\n\
+  gcc_assert (mode >= 0 && mode < NUM_MACHINE_MODES);\n\
   switch (mode)\n\
 {");
 
@@ -1067,6 +1070,7 @@ mode_unit_size_inline (machine_mode mode)\n\
 {\n\
   extern CONST_MODE_UNIT_SIZE unsigned char mode_unit_size[NUM_MACHINE_MODES];\
 \n\
+  gcc_assert (mode >= 0 && mode < NUM_MACHINE_MODES);\n\
   switch (mode)\n\
 {");
 
@@ -1103,6 +1107,7 @@ unsigned sh