Re: [RFC] combine: Handle zero_extend without subreg in change_zero_ext.

[Dominik Vogt]

On Thu, Jan 12, 2017 at 11:02:36AM -0600, Segher Boessenkool wrote:
> Thanks for the example.  ROSBG, what a weird instruction.

And it's annoying too because it does the same as RISBG in some
cases and can confuse "combine" to take a different branch that
turns out to be a dead end.

> On Thu, Jan 05, 2017 at 05:46:51PM +0100, Dominik Vogt wrote:
> > --- a/gcc/combine.c
> > +++ b/gcc/combine.c
> > @@ -11372,6 +11372,16 @@ change_zero_ext_src (subrtx_ptr_iterator *piter)
> >else if (GET_CODE (x) == ZERO_EXTEND
> >&& SCALAR_INT_MODE_P (mode)
> >&& REG_P (XEXP (x, 0))
> > +  && !HARD_REGISTER_P (XEXP (x, 0))
> > +  && GET_MODE_PRECISION (GET_MODE (XEXP (x, 0)))
> > + < GET_MODE_PRECISION (mode))
> > +{
> > +  /* (zero_extract (reg)) -> (and (subreg (reg) 0) (const_int)) */
> 
> s/zero_extract/zero_extend/
> 
> > * combine.c (change_zero_ext_src): Handle zero_extend without subreg.
> 
> "Handle zero_extend of a pseudo."?
> 
> Okay for trunk with that.  Thanks for the patch,

The patch forgot to set "size" and generated invalid Rtl because
of that.  Fixed and tested, but I'd prefer to repost my growing
stack of patches when gcc-7 is released.  There are too many
changes in "combine" and "simplify" that may depend on each other.

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt
IBM Germany

Re: [PATCH] Delete GCJ

[Andrew Haley]

On 22/01/17 18:41, Per Bothner wrote:
> In my opinion, all/most of these should be restored.

Because of the historical interest?  That's a good point, and perhaps
I was too hasty.  Sorry.

Andrew.

Re: [PATCH][PR lto/79061] Fix LTO plus ASAN fails with "AddressSanitizer: initialization-order-fiasco".

[Richard Biener]

On Wed, 18 Jan 2017, Maxim Ostapenko wrote:

> On 18/01/17 16:00, Richard Biener wrote:
> > On Wed, 18 Jan 2017, Maxim Ostapenko wrote:
> > 
> > > Hi,
> > > 
> > > as was figured out in PR LTO + ASan raises false initialization order
> > > fiasco
> > > alarm due to in LTO case main_input_filename doesn't match module name
> > > passed
> > > to __asan_before_dynamic_init.
> > > Following Jakub's suggestion I used TRANSLATION_UNIT_DECL for
> > > corresponding
> > > globals to overcome this issue (I needed to create a source location for
> > > each
> > > TRANSLATION_UNIT_DECL).
> > > However, when testing, I hit on a nasty issue: for some reason
> > > linemap_ordinary_map_lookup, called from lto_output_location for given
> > > TRANSLATION_UNIT_DECL, hit an assert:
> > > 
> > > [...]
> > >linemap_assert (line >= MAP_START_LOCATION (result));
> > >return result;
> > > }
> > > 
> > > due to line == 2.
> > > 
> > > After some investigation I noticed that source locations are propagated
> > > through location cache that can be partially invalidated by
> > > lto_location_cache::revert_location_cache call. And that was my case:
> > > after
> > > adding source location for TRANSLATION_UNIT_DECL into location cache, it
> > > was
> > > reverted by calling lto_location_cache::revert_location_cache from
> > > unify_scc
> > > before it was accepted:
> > > 
> > > static void
> > > lto_read_decls (struct lto_file_decl_data *decl_data, const void *data,
> > >  vec resolutions)
> > > {
> > > [...]
> > >/* Try to unify the SCC with already existing ones.  */
> > >if (!flag_ltrans
> > >&& unify_scc (data_in, from,
> > >  len, scc_entry_len, scc_hash))
> > >  continue;
> > > 
> > > For now I can overcome it by calling location_cache.accept_location_cache
> > > for
> > > TRANSLATION_UNIT_DECL, but I wonder if more reliable fix is possible.
> > > 
> > > Attached patch fixes the issue mentioned in PR and passes regression
> > > testing
> > > and LTO bootstrap on x86_64-unknown-linux-gnu.
> > > Could you please take a look on it?
> > Looks good to me (aka, OK).
> 
> Thanks, applied as r244581. Is it OK to commit the patch on branches if no new
> errors pop up in the next few days?

So this regresses compile-time by 100% on some fortran cases.  Doing the
linemap operation in build_translation_unit_decl confuses the linemap
code too much it seems.

Please revert this (and not backport it) for now.

A better place to store the filename would be eventually the DECL_NAME
of it or a new field alongside TRANSLATION_UNIT_DECL_LANGUAGE.

Thanks,
Richard.

> -Maxim
> 
> > 
> > Thanks,
> > Richard.
> > 
> > > -Maxim
> > > 
> 
> 

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

Re: [PATCH] Fix PR78189

[Richard Biener]

On Fri, 20 Jan 2017, Nick Clifton wrote:

> Hi Guys,
> 
>   [I have been asked to look at this PR in the hopes that it can be
>   fixed soon and so no longer act as a blocker for the gcc 7 branch].
> 
>   It seems to me that Richard's proposed patch does work:
> 
> https://gcc.gnu.org/ml/gcc-patches/2016-11/msg00909.html
> 
>   The only problem is that the check_effective_target_vect_hw_misalign
>   proc is always returning 0 (or false) for ARM, even when unaligned
>   vectors are supported.  This is why Richard's patch introduces a new
>   failure for the arm-* targets.
> 
>   So what I would like to suggest is an extended patch (attached) which
>   also updates the check_effective_target_vect_hw_misalign proc to use
>   the check_effective_target_arm_vect_no_misalign proc.  With this patch
>   applied not only does the gcc.dg/vect/vect-strided-a-u8-i2-gap.c test
>   for both big-endian and little-endian arm targets, but there is also a
>   significant reduction in the number of failures in the gcc.dg/vect
>   tests overall:
> 
>Little Endian ARM:
> < # of expected passes3275
> < # of unexpected failures63
> < # of unexpected successes   125
> < # of expected failures  123
> < # of unsupported tests  153
> ---
> > # of expected passes3448
> > # of unexpected failures2
> > # of unexpected successes   14
> > # of expected failures  131
> > # of unsupported tests  151
> 
>   Big Endian ARM:
> < # of expected passes2995
> < # of unexpected failures269
> < # of unexpected successes   21
> < # of expected failures  128
> ---
> > # of expected passes3037
> > # of unexpected failures127
> > # of unexpected successes   24
> > # of expected failures  228
> 
>   Which looks like a win to me.  So - any objections to my applying this
>   patch and then closing the PR ?

Ok.

Thanks,
Richard.

> Cheers
>   Nick
> 
> gcc/ChangeLog
> 2017-01-20  Richard Biener  
>   Nick Clifton  
> 
>   PR testsuite/78421
>   * lib/target-supports.exp (check_effective_target_vect_hw_misalign):
>   If the target is ARM return the result of the
>   check_effective_target_arm_vect_no_misalign proc.
>   * gcc.dg/vect/vect-strided-a-u8-i2-gap.c: If the target does not
>   support unaligned vectors then only expect one of the loops to be
>   unrolled.
> 
> 

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

Re: [PATCH] Delete GCJ

[Jakub Jelinek]

On Mon, Jan 23, 2017 at 09:01:24AM +, Andrew Haley wrote:
> On 22/01/17 18:41, Per Bothner wrote:
> > In my opinion, all/most of these should be restored.
> 
> Because of the historical interest?  That's a good point, and perhaps
> I was too hasty.  Sorry.

But then it should be probably moved somewhere where Gerald won't have to
spent time maintaining those pages (verification of URLs in there, updating
them when they are moved etc.).  Also to make it clear that GCJ is no longer
supported.

Jakub

Re: A + B CMP A -> A CMP' CST' match.pd patterns [was [PATCH] avoid calling memset et al. with excessively large sizes (PR 79095)]

[Richard Biener]

On Sat, Jan 21, 2017 at 6:22 AM, Jeff Law  wrote:
> On 01/20/2017 04:30 PM, Jeff Law wrote:
>>
>> Going to work from the self-contained test...
>>
>>
>>>
>>> Here's a test case that's closer to the one from the bug.  It also
>>> ends up with the out of bounds memset even at -O1, during PRE.
>>>
>>> typedef __SIZE_TYPE__ size_t;
>>>
>>> struct S
>>>   int *p0, *p1, *p2;
>>>
>>>   size_t size () const { return p1 - p0; }
>>>
>>>   void f (size_t n) {
>>> if (n > size ())   // can't happen because
>>>   foo (n - size ());   //   n is in [1, MIN(size() - 1, 3)]
>>> else if (n < size ())
>>>   bar (p0 + n);
>>>   }
>>>
>>>   void foo (size_t n)
>>>   {
>>> size_t left = (size_t)(p2 - p1);
>>> if (left >= n)
>>>   __builtin_memset (p2, 0, n * sizeof *p2);
>>>   }
>>>
>>>   void bar (int*);
>>> };
>>>
>>> void f (S &s)
>>> {
>>>   size_t n = s.size ();
>>>   if (n > 1 && n < 5)
>>> s.f (n - 1);
>>> }
>>
>>
>>
>> Looking at the .vrp1 dump for this test we find:
>>
>> ;;   basic block 3, loop depth 0, count 0, freq 3664, maybe hot
>> ;;prev block 2, next block 4, flags: (NEW, REACHABLE, VISITED)
>> ;;pred:   2 [36.6%]  (TRUE_VALUE,EXECUTABLE)
>>   _18 = ASSERT_EXPR <_13, _13 + 18446744073709551614 <= 2>;
>>   _2 = _18 + 18446744073709551615;
>>   if (_2 > _18)
>> goto ; [50.00%]
>>   else
>> goto ; [50.00%]
>>
>> _2 > _18 is the same as
>>
>> (_18 - 1) > _18
>>
>> Which is only true if _18 is zero.  And since _18 has a computed range
>> of [2..4], that can never happen.
>>
>> VRP doesn't currently handle this case, though we do have some code to
>> turn relational comparisons into equality comparisons.  If I manually
>> turn the relational into _18 == 0 at that point, then the next VRP pass
>> is able to optimize the conditional away which in turn eliminates the
>> problematical memset call & warning.
>>
>> So one possible approach would be to treat simplify_cond_using_ranges to
>> simplify that kind of condition.  I don't know if that would fix the
>> reported testcase as I haven't looked at it directly under the debugger
>> yet.
>
> In fact, match.pd already has a pattern to handle a relational like
> (X + -1) > X
>
> The pattern doesn't fire because of a single_use guard.   This was discussed
> back in 2015 with Jakub advocating for a single_use guard, but Marc leaning
> the other direction, but not enough to argue too much about it.
>
> In early 2016 Marc actually submitted the match.pd patch with the single use
> guard per Jakub's preference.
>
> The single use guard checks the SSA_NAME holding the (X + CST) expression
> for single use.   It's not entirely clear why we check for single use.  If
> it's because of object lifetimes, then that's a total red herring here.
>
> Given something like:
> x = a + c
> if (a > x)
>
> The transformation into
>
> x = a + c;
> if (a < c')
>
> Where x has multiple uses, the transformation will not inherently change the
> lifetime of "x" worse (if the conditional was the last use, then the
> lifetime of x may shorten somewhat).  If there were uses after the
> condition, the lifetime of "x" remains unchanged.
>
> "a" was already live from the assignment to at least the conditional. But
> again, we haven't inherently changed its lifetime.
>
> However, what can happen is after transformation, the assignment might sink
> to a later use point in the CFG, which might lengthen the lifetime of "a",
> but it's also shortening the lifetime of "x" by the same amount.
>
> So, ultimately I don't buy the argument that we should inhibit this based on
> register lifetime issues.
>
> Jakub, perhaps you remember why you wanted this restricted to cases where
> "x" has a single use?

I think it was added for the reason stated in the comment:

/* When one argument is a constant, overflow detection can be simplified.
   Currently restricted to single use so as not to interfere too much with
   ADD_OVERFLOW detection in tree-ssa-math-opts.c.
   A + CST CMP A  ->  A CMP' CST' */
(for cmp (lt le ge gt)
 out (gt gt le le)
 (simplify
  (cmp:c (plus@2 @0 INTEGER_CST@1) @0)
  (if (TYPE_UNSIGNED (TREE_TYPE (@0))
   && TYPE_OVERFLOW_WRAPS (TREE_TYPE (@0))
   && wi::ne_p (@1, 0)
   && single_use (@2))
   (out @0 { wide_int_to_tree (TREE_TYPE (@0), wi::max_value
   (TYPE_PRECISION (TREE_TYPE (@0)), UNSIGNED) - @1); }

> Certainly the easiest thing to do is remove the single use restriction. If
> we ultimately don't want to do that, we can probably detect when the
> transformation will allow the conditional to be eliminated in VRP and I
> would claim that elimination of the conditional at compile time trumps the
> other potential concerns here.  That's going to be uglier and essentially
> duplicate parts of what match.pd does, but certainly doable -- I've even
> prototyped it.

Yeah, duplicating that sounds ugly.

But undoing it for the sake of detecting overflow builtins is as well (OTOH
nothing does the reverse transform s

Re: [PATCH][PR lto/79061] Fix LTO plus ASAN fails with "AddressSanitizer: initialization-order-fiasco".

[Maxim Ostapenko]

On 23/01/17 12:03, Richard Biener wrote:

On Wed, 18 Jan 2017, Maxim Ostapenko wrote:


On 18/01/17 16:00, Richard Biener wrote:

On Wed, 18 Jan 2017, Maxim Ostapenko wrote:


Hi,

as was figured out in PR LTO + ASan raises false initialization order
fiasco
alarm due to in LTO case main_input_filename doesn't match module name
passed
to __asan_before_dynamic_init.
Following Jakub's suggestion I used TRANSLATION_UNIT_DECL for
corresponding
globals to overcome this issue (I needed to create a source location for
each
TRANSLATION_UNIT_DECL).
However, when testing, I hit on a nasty issue: for some reason
linemap_ordinary_map_lookup, called from lto_output_location for given
TRANSLATION_UNIT_DECL, hit an assert:

[...]
linemap_assert (line >= MAP_START_LOCATION (result));
return result;
}

due to line == 2.

After some investigation I noticed that source locations are propagated
through location cache that can be partially invalidated by
lto_location_cache::revert_location_cache call. And that was my case:
after
adding source location for TRANSLATION_UNIT_DECL into location cache, it
was
reverted by calling lto_location_cache::revert_location_cache from
unify_scc
before it was accepted:

static void
lto_read_decls (struct lto_file_decl_data *decl_data, const void *data,
  vec resolutions)
{
[...]
/* Try to unify the SCC with already existing ones.  */
if (!flag_ltrans
&& unify_scc (data_in, from,
  len, scc_entry_len, scc_hash))
  continue;

For now I can overcome it by calling location_cache.accept_location_cache
for
TRANSLATION_UNIT_DECL, but I wonder if more reliable fix is possible.

Attached patch fixes the issue mentioned in PR and passes regression
testing
and LTO bootstrap on x86_64-unknown-linux-gnu.
Could you please take a look on it?

Looks good to me (aka, OK).

Thanks, applied as r244581. Is it OK to commit the patch on branches if no new
errors pop up in the next few days?

So this regresses compile-time by 100% on some fortran cases.  Doing the
linemap operation in build_translation_unit_decl confuses the linemap
code too much it seems.

Please revert this (and not backport it) for now.


Done with r244773, sorry about that :-( . We'll probably need to reopen 
the bug, right?


-Maxim



A better place to store the filename would be eventually the DECL_NAME
of it or a new field alongside TRANSLATION_UNIT_DECL_LANGUAGE.

Thanks,
Richard.


-Maxim


Thanks,
Richard.


-Maxim

Re: [PATCH][PR lto/79061] Fix LTO plus ASAN fails with "AddressSanitizer: initialization-order-fiasco".

[Jakub Jelinek]

On Mon, Jan 23, 2017 at 12:14:21PM +0300, Maxim Ostapenko wrote:
> > Please revert this (and not backport it) for now.
> 
> Done with r244773, sorry about that :-( . We'll probably need to reopen the
> bug, right?

Sure.

Jakub

Re: [PATCH] Speed-up use-after-scope (re-writing to SSA) (version 2)

[Martin Liška]

On 01/20/2017 03:27 PM, Jakub Jelinek wrote:
> On Fri, Jan 20, 2017 at 03:08:21PM +0100, Martin Liška wrote:
>> Unfortunately this way would not work as clobber marks content of the memory 
>> as uninitialize
>> is different behavior that just marking a memory can be used (and maybe 
>> already contains a value).
>>
>> This shows the problem:
>>
>> #include 
>>
>> char cc;
>> char ptr[] = "sparta2";
>>
>> void get(char **x)
>> {
>>   *x = ptr;
>> }
>>   
>> int main()
>> {
>>   char *here = &cc;
>>
>>   for (;;)
>> {
>> next_line:
>>  if (here == NULL)
>>__builtin_abort();
>>  get (&here);
>>  if (strcmp (here, "sparta") == 0)
>>  goto next_line;
>>  else if (strcmp (here, "sparta2") == 0)
>>break;
>> }
>> }
>>
>> With the patch, DSE would optimize out '*here = &cc;' and thus aborts. The 
>> problem is definitely
>> related to goto magic, where we are more defensive in placement of 
>> ASAN_MARK(UNPOISON,...).
>> Hope your optimization is still valid for situations w/o artificial 
>> ASAN_MARK(UNPOISON,...) placed due
>> to goto magic.
>>
>> Do we still want to do it now, or postponing to GCC 8 would be better option?
> 
> I'd still like to resolve it for GCC 7 if at all possible, I think otherwise
> -fsanitize=address is by default unnecessarily slower (so it is a regression
> anyway).

Good, I hope I have patch that finally works as we want. It add attribute to 
variables that
are unpoisoned as live switch variables, or are defined in a label which 
address is taken.

With [1] I can bootstrap-asan and the patch can bootstrap on 
ppc64le-redhat-linux
and survives regression tests.

I'm sending latest diff, as well as the final pair of patches I would like to 
install.

Ready to be installed?
Martin

> So, do we always amit ASAN_MARK(UNPOISON, ...) at the start of scope and
> then yet another ASAN_MARK(UNPOISON, ...) at the goto destination?
> At least on the above testcase that is the case, so if we say split
> ASAN_MARK_UNPOISON into something that is used at the start of scope
> (we'd emit the clobber for those) and others (we would not), then perhaps we
> could get around that.  The above is BTW a clear case where shouldn't emit
> UNPOISON on the label, as the goto doesn't cross its initialization.
> But I can see with gotos from outside of some var's scope into it we
> wouldn't handle it properly.  Perhaps for now set some
> flag/attribute/whatever on vars for which we emit the conservative
> UNPOISON and never allow those to be made non-addressable (i.e. for those
> say that POISON/UNPOISON actually makes them always addressable)?
> 
>   Jakub
> 

[1] https://gcc.gnu.org/ml/gcc-patches/2017-01/msg01446.html

>From 97a900584714411521fc8ad3c7b99b0e74955fe6 Mon Sep 17 00:00:00 2001
From: marxin 
Date: Mon, 19 Dec 2016 15:36:11 +0100
Subject: [PATCH 1/2] Speed up use-after-scope (v2): rewrite into SSA

gcc/ChangeLog:

2016-12-22  Martin Liska  

	* asan.c (create_asan_shadow_var): New function.
	(asan_expand_poison_ifn): Likewise.
	* asan.h (asan_expand_poison_ifn): New declaration.
	* internal-fn.c (expand_ASAN_POISON): Likewise.
	* internal-fn.def (ASAN_POISON): New builtin.
	* sanopt.c (pass_sanopt::execute): Expand
	asan_expand_poison_ifn.
	* tree-inline.c (copy_decl_for_dup_finish): Make function
	external.
	* tree-inline.h (copy_decl_for_dup_finish): Likewise.
	* tree-ssa.c (is_asan_mark_p): New function.
	(execute_update_addresses_taken): Rewrite local variables
	(identified just by use-after-scope as addressable) into SSA.

gcc/testsuite/ChangeLog:

2016-12-22  Martin Liska  

	* gcc.dg/asan/use-after-scope-3.c: Add additional flags.
	* gcc.dg/asan/use-after-scope-9.c: Likewise and grep for
	sanopt optimization for ASAN_POISON.
---
 gcc/asan.c| 109 +-
 gcc/asan.h|   2 +
 gcc/internal-fn.c |   7 ++
 gcc/internal-fn.def   |   1 +
 gcc/sanopt.c  |  11 +++
 gcc/testsuite/gcc.dg/asan/use-after-scope-3.c |   1 +
 gcc/testsuite/gcc.dg/asan/use-after-scope-9.c |   2 +
 gcc/tree-inline.c |   2 +-
 gcc/tree-inline.h |   1 +
 gcc/tree-ssa.c|  69 +---
 10 files changed, 193 insertions(+), 12 deletions(-)

diff --git a/gcc/asan.c b/gcc/asan.c
index 9a59fe4f100..4aa5a4015ea 100644
--- a/gcc/asan.c
+++ b/gcc/asan.c
@@ -32,8 +32,8 @@ along with GCC; see the file COPYING3.  If not see
 #include "tree-pass.h"
 #include "memmodel.h"
 #include "tm_p.h"
+#include "ssa.h"
 #include "stringpool.h"
-#include "tree-vrp.h"
 #include "tree-ssanames.h"
 #include "optabs.h"
 #include "emit-rtl.h"
@@ -59,6 +59,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "params.h"
 #include "builtins.h"
 #include "fnmatch.h"
+#include "tree-inline.h"
 
 /* AddressSanitizer finds out-of-bound

Re: [PATCH] Speed-up use-after-scope (re-writing to SSA) (version 2)

[Jakub Jelinek]

On Mon, Jan 23, 2017 at 10:19:33AM +0100, Martin Liška wrote:
> diff --git a/gcc/gimplify.c b/gcc/gimplify.c
> index 2777a23eb93..1b076fdf45c 100644
> --- a/gcc/gimplify.c
> +++ b/gcc/gimplify.c
> @@ -1206,8 +1206,19 @@ asan_poison_variables (hash_set *variables, bool 
> poison, gimple_seq *seq_p
>  
>sorted_variables.qsort (sort_by_decl_uid);
>  
> -  for (unsigned i = 0; i < sorted_variables.length (); i++)
> -asan_poison_variable (sorted_variables[i], poison, seq_p);
> +  unsigned i;
> +  tree var;
> +  FOR_EACH_VEC_ELT (sorted_variables, i, var)
> +{
> +  asan_poison_variable (var, poison, seq_p);
> +
> +  /* Add use_after_scope_memory attribute for the variable in order
> +  to prevent re-written into SSA.  */
> +  DECL_ATTRIBUTES (var)
> + = tree_cons (get_identifier ("use_after_scope_memory"),

Please use "use after scope memory" to make it clear it is internal
only attribute users can't specify.
Also, can't asan_poison_variables be performed on the same var
multiple times (multiple labels, or switches, ...)?
If yes, then the addition of the attribute should be guarded
with if (!lookup_attribute ("use after scope memory", DECL_ATTRIBUTES (vars)))
so that you don't add the attributes many times.

> +  build_int_cst (integer_type_node, 1),
> +  DECL_ATTRIBUTES (var));

Please use:
 integer_one_node, DECL_ATTRIBUTES (var));
instead.

> --- a/gcc/tree-ssa.c
> +++ b/gcc/tree-ssa.c
> @@ -1565,6 +1565,10 @@ is_asan_mark_p (gimple *stmt)
>&& VAR_P (TREE_OPERAND (addr, 0)))
>  {
>tree var = TREE_OPERAND (addr, 0);
> +  if (lookup_attribute ("use_after_scope_memory",
> + DECL_ATTRIBUTES (var)))
> + return false;

See above.

Patchset is ok for trunk with these nits fixed, thanks.

Jakub

Re: [PATCH] Be careful about combined chain with length == 0 (PR, tree-optimization/70754).

[Richard Biener]

On Fri, Jan 20, 2017 at 3:30 PM, Bin.Cheng  wrote:
> On Thu, Jan 19, 2017 at 12:07 PM, Bin.Cheng  wrote:
>> On Thu, Jan 19, 2017 at 11:22 AM, Richard Biener
>>  wrote:
>>> On Thu, Jan 19, 2017 at 11:25 AM, Bin.Cheng  wrote:
 On Thu, Jan 19, 2017 at 9:42 AM, Richard Biener
>>>
>>> Or a later pass introduced it (in this case, the vectorizer).
>>>
 Predcom could be the
 only pass that can handle such case as it understands data reference
 better.  Note Martin's patch is not to skip handling of length == 0
 chain, later ref will still be CSEed with result of root ref, only the
 combination operation like chain1 + chain2 is skipped.  In this case,
 following dom should be able to handle such (loop independent) cse
 opportunities.
>>>
>>> I must admit I don't completely understand the consequences of this
>>> disabling but of course DOM should also be able to handle the CSE
>>> (ok, DOM is known to be quite weak with memory equivalence but
>>> it's not that data-dependence is really better in all cases).
>>>
>>> Can't we simply re-order refs in new_chain appropriately or handle
>>> this case in combinable_refs_p instead?
>> It's not refs need to be reordered, root ref always dominates others.
>> But yes, we need to find a dominator insertion place for combined
>> operation.  Looking at function reassociate_to_the_same_stmt, it
>> simply inserts new_stmt at root_stmt of root ref, which causes ICE in
>> this case.  The new_stmt needs to be inserted at a place also
>> dominating combination of later refs.  We can either compute the
>> information in place, or compute and pass the information from
>> previous combinable_refs_p.  This should be the real fix.
> Hi All,
> As analyzed, root cause is Predcom inserts combined stmt at place only
> wrto the root refs.  This is not enough because after combination,
> result is also used by the following combined refs, not only root
> refs.  This patch fixes the ICE by processing all refs reversely and
> computing dominance point for insertion.  When it comes to the root
> refs, dominance point is ready for use.
> Bootstrap and test on x86_64 and AArch64 ongoing, is it OK if no failures?

Ok.

RIchard.

> Thanks,
> bin
> 2017-01-19  Bin Cheng  
>
> PR tree-optimization/70754
> * tree-predcom.c (stmt_combining_refs): New parameter INSERT_BEFORE.
> (reassociate_to_the_same_stmt): New parameter INSERT_BEFORE.  Insert
> combined stmt before it if not NULL.
> (combine_chains): Process refs reversely and compute dominance point
> for root ref.
>
> gcc/testsuite/ChangeLog
> 2017-01-19  Bin Cheng  
>
> PR tree-optimization/70754
> * gfortran.dg/pr70754.f90: New test.
>
>>> That is, I understand the patch as a hack as it should be always
>>> possible to find dominating refs?
>>>
>>> In fact the point of the assert tells us a simpler fix may be
>>>
>>> Index: tree-predcom.c
>>> ===
>>> --- tree-predcom.c  (revision 244519)
>>> +++ tree-predcom.c  (working copy)
>>> @@ -2330,6 +2334,12 @@ combine_chains (chain_p ch1, chain_p ch2
>>>   break;
>>> }
>>>  }
>>> +  if (new_chain->length == 0
>>> +  && ! new_chain->has_max_use_after)
>>> +{
>>> +  release_chain (new_chain);
>>> +  return NULL;
>>> +}
>>>
>>>ch1->combined = true;
>>>ch2->combined = true;
>>>
>>> which obviously matches the assert we run into for the testcase?  I'd
>>> be ok with that
>>> (no stmt_dominates_stmt_p, heh) with a suitable comment before it.
>>>
>>> Richard.
>>>

Re: [PR middle-end/79123] cast false positive in -Walloca-larger-than=

[Richard Biener]

On Fri, Jan 20, 2017 at 5:37 PM, Martin Sebor  wrote:
> On 01/20/2017 01:17 AM, Richard Biener wrote:
>>
>> On Thu, Jan 19, 2017 at 5:53 PM, Martin Sebor  wrote:
>>>
>>> On 01/19/2017 05:45 AM, Richard Biener wrote:


 On Thu, Jan 19, 2017 at 1:17 PM, Aldy Hernandez 
 wrote:
>
>
> In the attached testcase, we have a clearly bounded case of alloca
> which
> is
> being incorrectly reported:
>
> void g (int *p, int *q)
> {
>size_t n = (size_t)(p - q);
>
>if (n < 10)
>  f (__builtin_alloca (n));
> }
>
> The problem is that VRP gives us an anti-range for `n' which may be out
> of
> range:
>
>   # RANGE ~[2305843009213693952, 16140901064495857663]
>n_9 = (long unsigned int) _4;
>
> We do a less than stellar job with casts and VR_ANTI_RANGE's, mostly
> because
> we're trying various heuristics to make up for the fact that we have
> crappy
> range info from VRP.  More specifically, we're basically punting on an
> VR_ANTI_RANGE and ignoring that the casted result (n_9) has a bound
> later
> on.
>
> Luckily, we already have code to check simple ranges coming into the
> alloca
> by looking into all the basic blocks feeding it.  The attached patch
> delays
> the final decision on anti ranges until we have examined the basic
> blocks
> and determined for that we are definitely out of range.
>
> I expect all this to disappear with Andrew's upcoming range info
> overhaul.
>
> OK for trunk?



 I _really_ wonder why all the range consuming warnings are not emitted
 from VRP itself (like we do for -Warray-bounds).  There we'd still see
 a range for the argument derived from the if () rather than needing to
 do our own mini-VRP from the needessly "incomplete" range-info on
 SSA vars.
>>>
>>>
>>>
>>> Can you explain why the range info is only available in VRP and
>>> not outside, via the get_range_info() API?  It sounds as though
>>> the API shouldn't be relied on (it was virtually unused before
>>> GCC 7).
>>
>>
>> It's very simple.  Look at the testcase from above
>
>
> Thanks for the detailed answer.  A few more questions below.
>
>>
>> void g (int *p, int *q)
>> {
>>size_t n = (size_t)(p - q);
>>
>>if (n < 10)
>>  f (__builtin_alloca (n));
>> }
>>
>> The IL outside of VRP is
>>
>>[100.00%]:
>>   p.0_1 = (long int) p_7(D);
>>   q.1_2 = (long int) q_8(D);
>>   _3 = p.0_1 - q.1_2;
>>   _4 = _3 /[ex] 4;
>>   n_9 = (size_t) _4;
>>   if (n_9 <= 9)
>> goto ; [36.64%]
>>   else
>> goto ; [63.36%]
>>
>>[36.64%]:
>>   _5 = __builtin_alloca (n_9);
>>   f (_5);
>>
>> so there is no SSA name we can tack a range to covering the n_9 <= 9
>> condition that dominates __builtin_alloca.
>
>
> This may be a naive question but why is it not possible to create
> such an SSA name?

You'd insert a copy (like VRP does with ASSERTs) but those will be
propagated out quickly again.

> Having the get_range_info() API depend on this subtlety makes its
> clients quite unreliable.  It may be acceptable for optimization
> but when it's visible to users in the form of false positives or
> negatives it's a source of bug reports.

Yes, but that's the fault of the warning machinery not the range-info API
which was designed for optimization.

>> Inside VRP we have
>>
>>[100.00%]:
>>   p.0_1 = (long int) p_7(D);
>>   q.1_2 = (long int) q_8(D);
>>   _3 = p.0_1 - q.1_2;
>>   _4 = _3 /[ex] 4;
>>   n_9 = (size_t) _4;
>>   if (n_9 <= 9)
>> goto ; [36.64%]
>>   else
>> goto ; [63.36%]
>>
>>[36.64%]:
>>   n_13 = ASSERT_EXPR ;
>>   _5 = __builtin_alloca (n_13);
>>   f (_5);
>>
>> and viola - now the alloca call uses n_13 which is defined at a point
>> dominated by if (n_9 <= 9) and thus it has an improved range:
>>
>> n_13: [0, 9]  EQUIVALENCES: { n_9 } (1 elements)
>
>
> Yes, I see that.  But when I change size_t to unsigned int (in LP64)
> like so:
>
>   void g (int *p, int *q)
>   {
> unsigned n = (unsigned)(p - q);
>
> if (n < 10)
>   f (__builtin_alloca (n));
>   }
>
> -Walloca-larger-than=100 still complains:
>
>   warning: argument to ‘alloca’ may be too large
>   note: limit is 100 bytes, but argument may be as large as 4294967295
>
> and the VRP dump shows
>
>   _5: [0, 4294967295]
>   _14: [0, 4294967295]
>   ...
> _3 = p.0_1 - q.1_2;
> _4 = _3 /[ex] 4;
> n_10 = (unsigned int) _4;
> if (n_10 <= 9)
>   goto ; [36.64%]
> else
>   goto ; [63.36%]
>
>  [36.64%]:
> _14 = _4 & 4294967295;
> _5 = (long unsigned int) _14;
> _6 = __builtin_alloca (_5);
>
> so it seems that even in VRP itself the range information isn't
> quite good enough to avoid false positives.  (Perhaps that's one
> the missed cases you mention below?)

Well, you see that there's no obvious way to use the n_10 <= 9 conditional
here.  VRP would need to register a [0,

Re: [PR middle-end/79123] cast false positive in -Walloca-larger-than=

[Richard Biener]

On Fri, Jan 20, 2017 at 8:48 PM, Jeff Law  wrote:
> On 01/20/2017 01:17 AM, Richard Biener wrote:
>>
>> On Thu, Jan 19, 2017 at 5:53 PM, Martin Sebor  wrote:
>>>
>>> On 01/19/2017 05:45 AM, Richard Biener wrote:


 On Thu, Jan 19, 2017 at 1:17 PM, Aldy Hernandez 
 wrote:
>
>
> In the attached testcase, we have a clearly bounded case of alloca
> which
> is
> being incorrectly reported:
>
> void g (int *p, int *q)
> {
>size_t n = (size_t)(p - q);
>
>if (n < 10)
>  f (__builtin_alloca (n));
> }
>
> The problem is that VRP gives us an anti-range for `n' which may be out
> of
> range:
>
>   # RANGE ~[2305843009213693952, 16140901064495857663]
>n_9 = (long unsigned int) _4;
>
> We do a less than stellar job with casts and VR_ANTI_RANGE's, mostly
> because
> we're trying various heuristics to make up for the fact that we have
> crappy
> range info from VRP.  More specifically, we're basically punting on an
> VR_ANTI_RANGE and ignoring that the casted result (n_9) has a bound
> later
> on.
>
> Luckily, we already have code to check simple ranges coming into the
> alloca
> by looking into all the basic blocks feeding it.  The attached patch
> delays
> the final decision on anti ranges until we have examined the basic
> blocks
> and determined for that we are definitely out of range.
>
> I expect all this to disappear with Andrew's upcoming range info
> overhaul.
>
> OK for trunk?



 I _really_ wonder why all the range consuming warnings are not emitted
 from VRP itself (like we do for -Warray-bounds).  There we'd still see
 a range for the argument derived from the if () rather than needing to
 do our own mini-VRP from the needessly "incomplete" range-info on
 SSA vars.
>>>
>>>
>>>
>>> Can you explain why the range info is only available in VRP and
>>> not outside, via the get_range_info() API?  It sounds as though
>>> the API shouldn't be relied on (it was virtually unused before
>>> GCC 7).
>>
>>
>> It's very simple.  Look at the testcase from above
>>
>> void g (int *p, int *q)
>> {
>>size_t n = (size_t)(p - q);
>>
>>if (n < 10)
>>  f (__builtin_alloca (n));
>> }
>>
>> The IL outside of VRP is
>>
>>[100.00%]:
>>   p.0_1 = (long int) p_7(D);
>>   q.1_2 = (long int) q_8(D);
>>   _3 = p.0_1 - q.1_2;
>>   _4 = _3 /[ex] 4;
>>   n_9 = (size_t) _4;
>>   if (n_9 <= 9)
>> goto ; [36.64%]
>>   else
>> goto ; [63.36%]
>>
>>[36.64%]:
>>   _5 = __builtin_alloca (n_9);
>>   f (_5);
>>
>> so there is no SSA name we can tack a range to covering the n_9 <= 9
>> condition that dominates __builtin_alloca.  Inside VRP we have
>>
>>[100.00%]:
>>   p.0_1 = (long int) p_7(D);
>>   q.1_2 = (long int) q_8(D);
>>   _3 = p.0_1 - q.1_2;
>>   _4 = _3 /[ex] 4;
>>   n_9 = (size_t) _4;
>>   if (n_9 <= 9)
>> goto ; [36.64%]
>>   else
>> goto ; [63.36%]
>>
>>[36.64%]:
>>   n_13 = ASSERT_EXPR ;
>>   _5 = __builtin_alloca (n_13);
>>   f (_5);
>>
>> and viola - now the alloca call uses n_13 which is defined at a point
>> dominated by if (n_9 <= 9) and thus it has an improved range:
>>
>> n_13: [0, 9]  EQUIVALENCES: { n_9 } (1 elements)
>>
>> When in EVRP you get similar behavior (well, there are some missed
>> cases I have patches queued for for GCC 8), but instead of modifying
>> the IL EVRP just temporarily sets the above range when it processes
>> BBs dominated by the condition.
>>
>> So while for VRP you can put the warning code after propagation for
>> EVRP you'd have to do warning processing during propagation itself
>> (and EVRP doesn't iterate).
>>
>>> To answer your question, the gimple-ssa-sprintf pass that depends
>>> heavily on ranges would also benefit from having access to the data
>>> computed in the strlen pass that's not available outside it.
>>>
>>> The -Wstringop-overflow and -Walloc-size-larger-than warnings depend
>>> on both VRP and tree-object-size.
>>>
>>> I have been thinking about how to integrate these passes in GCC 8
>>> to improve the overall quality.  (By integrating I don't necessarily
>>> mean merging the code but rather having them share data or be able
>>> to make calls into one another.)
>>>
>>> I'd be very interested in your thoughts on this.
>>
>>
>> Well, my thought is that we should not have N SSA propagation and
>> M "DOM" propagation passes but one of each kind.  My thought is
>> also that object-size and strlen are of either kind.
>>
>> So ideally DOM and EVRP would merge and CCP, copyprop and VRP
>> would merge.  It's probably not possible (or wise) to merge their lattices
>> (maybe to some extent)
>
> DOM's equivalency tables could be easily superceded by other
> implementations.  It's just two datastructures.  A trivial const/copy table
> and a stack to allow unwinding the state of the const/copy table. Throwing
> away the basic

Re: [PR 79108] Put ipa_node_params to GC memory

[Richard Biener]

On Fri, Jan 20, 2017 at 10:58 PM, Martin Jambor  wrote:
> Hi,
>
> when I fixed PR 78365 by streaming types of parameters that might not
> have been anywhere else, I forgot that I was holding them in non-GC
> memory and so I caused PR 79108.  The following patch fixes it by
> putting ipa_param_descriptor and ipa_node_params structures into GC
> memory, together with summary holding class ipa_node_params_t which is
> now a GC root.  In the process, I have turned the destructor of the
> latter into a remove and insert hooks of the summary holder.
>
> Bootstrapped and tested on x86_64-linux, also LTO-bootstrapped and
> tested, although with only C,C++ and Fortran and with sanitizers and
> multilib disabled.  (It is now a part of an undergoing  LTO bootstrap
> with everything).  OK for trunk?

Ok.

Richard.

> Thanks,
>
> Martin
>
>
> 2017-01-19  Martin Jambor  
>
> PR ipa/79108
> * ipa-prop.h (ipa_param_descriptor): Anotate with with GTY(()).
> (ipa_node_params): Annotate with GTY((for_user)).  Make descriptors
> field a pointer to garbage collected vector, mark lattices and
> ipcp_orig_node with GTY((skip)).
> (ipa_get_param_count): Adjust to descriptors being a pointer.
> (ipa_get_param): Likewise.
> (ipa_get_type): Likewise.
> (ipa_get_param_move_cost): Likewise.
> (ipa_set_param_used): Likewise.
> (ipa_get_controlled_uses): Likewise.
> (ipa_set_controlled_uses): Likewise.
> (ipa_is_param_used): Likewise.
> (ipa_node_params_t): Move into garbage collector.  New methods insert
> and remove.
> (ipa_node_params_sum): Annotate wth GTY(()).
> (ipa_check_create_node_params): Adjust to ipa_node_params_sum being
> garbage collected.
> (ipa_load_from_parm_agg): Adjust declaration.
> * ipa-icf.c (param_used_p): Adjust to descriptors being a pointer.
> * ipa-profile.c (ipa_profile): Likewise.
> * ipa-prop.c (ipa_get_param_decl_index_1): Likewise.
> (ipa_populate_param_decls): Make descriptors parameter garbage
> collected.
> (ipa_dump_param): Adjust to descriptors being a pointer.
> (ipa_alloc_node_params): Likewise.
> (ipa_initialize_node_params): Likewise.
> (load_from_param_1): Make descriptors parameter garbage collected.
> (load_from_unmodified_param): Likewise.
> (load_from_param): Likewise.
> (ipa_load_from_parm_agg): Likewise.
> (ipa_node_params::~ipa_node_params): Removed.
> (ipa_free_all_node_params): Remove call to delete operator.
> (ipa_node_params_t::insert): New.
> (ipa_node_params_t::remove): Likewise.
> (ipa_node_params_t::duplicate): Adjust to descriptors being a pointer,
> copy known_csts and known_contexts vectors.
> (ipa_read_node_info): Adjust to descriptors being a pointer.
> (ipcp_modif_dom_walker): Make m_descriptors field garbage
> collected.
> (ipcp_transform_function): Make descriptors variable garbage
> collected.
>
> testsuite/
> * gfortran.dg/lto/pr79108_0.f90: New test.
> ---
>  gcc/ipa-icf.c   |   5 +-
>  gcc/ipa-profile.c   |   3 +-
>  gcc/ipa-prop.c  | 101 
> +++-
>  gcc/ipa-prop.h  |  62 ++---
>  gcc/testsuite/gfortran.dg/lto/pr79108_0.f90 |  14 
>  5 files changed, 111 insertions(+), 74 deletions(-)
>  create mode 100644 gcc/testsuite/gfortran.dg/lto/pr79108_0.f90
>
> diff --git a/gcc/ipa-icf.c b/gcc/ipa-icf.c
> index c17a677b459..b9a5b4f2546 100644
> --- a/gcc/ipa-icf.c
> +++ b/gcc/ipa-icf.c
> @@ -539,9 +539,8 @@ sem_function::param_used_p (unsigned int i)
>
>struct ipa_node_params *parms_info = IPA_NODE_REF (get_node ());
>
> -  if (parms_info->descriptors.is_empty ()
> -  || parms_info->descriptors.length () <= i)
> - return true;
> +  if (vec_safe_length (parms_info->descriptors) <= i)
> +return true;
>
>return ipa_is_param_used (IPA_NODE_REF (get_node ()), i);
>  }
> diff --git a/gcc/ipa-profile.c b/gcc/ipa-profile.c
> index 3e9b2a915fc..ae1ca2f3762 100644
> --- a/gcc/ipa-profile.c
> +++ b/gcc/ipa-profile.c
> @@ -621,7 +621,8 @@ ipa_profile (void)
>  "and can be discarded.\n");
> }
>   else if (ipa_node_params_sum && ipa_edge_args_vector
> -  && !IPA_NODE_REF (n2)->descriptors.is_empty ()
> +  && (!vec_safe_is_empty
> +  (IPA_NODE_REF (n2)->descriptors))
>&& ipa_get_param_count (IPA_NODE_REF (n2))
>   != ipa_get_cs_argument_count (IPA_EDGE_REF (e))
> && (ipa_get_param_count (IPA_NODE_REF (n2))
> diff --git a/gcc/ipa-prop.c b/gcc/ipa-prop.c
> index 1f6

Re: [PATCH] Do not declare artificial variables in tree-profile.c to have a definition (PR lto/69188).

[Christophe Lyon]

On 13 January 2017 at 18:21, Jeff Law  wrote:
> On 01/13/2017 08:08 AM, Martin Liška wrote:
>>
>> Hello.
>>
>> Nice example provided in the PR causes ICE as we have an artificial symbol
>> created in tree-profile.c once being removed by remove unreachable nodes
>> (-O0)
>> and once not (-O1). Well, difference is in process_references where
>> following hunk
>> prevent removal:
>>
>>   || (((before_inlining_p
>> && ((TREE_CODE (node->decl) != FUNCTION_DECL
>>  && optimize)
>>
>> Anyway, these artificial symbols really should be just declarations as
>> they are defined
>> in libgcov library.
>>
>> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
>>
>> Ready to be installed?
>> Martin
>>
>>
>> 0001-Do-not-declare-artificial-variables-in-tree-profile..patch
>>
>>
>> From 87262b1b60009381fd943fb433bc38f5d5685ac9 Mon Sep 17 00:00:00 2001
>> From: marxin 
>> Date: Fri, 13 Jan 2017 13:12:57 +0100
>> Subject: [PATCH] Do not declare artificial variables in tree-profile.c to
>> have
>>  a definition (PR lto/69188).
>>
>> gcc/testsuite/ChangeLog:
>>
>> 2017-01-13  Martin Liska  
>>
>> PR lto/69188
>> * gcc.dg/lto/pr69188_0.c: New test.
>> * gcc.dg/lto/pr69188_1.c: New test.
>>
>> gcc/ChangeLog:
>>
>> 2017-01-13  Martin Liska  
>>
>> PR lto/69188
>> * tree-profile.c (init_ic_make_global_vars): Do not call
>> finalize_decl.
>> (gimple_init_gcov_profiler): Likewise.
>
> OK.
> jeff
>

Hi,

The new test fails on arm-none-eabi:
/cc6RcpEu.ltrans0.ltrans.o: In function `fn1':
:(.text+0x18): undefined reference to
`__gcov_indirect_call_profiler_v2'
:(.text+0x1c): undefined reference to `__gcov_indirect_call_callee'
:(.text+0x20): undefined reference to `__gcov_indirect_call_callee'
:(.text+0x60): undefined reference to `__gcov_time_profiler_counter'
:(.text+0x64): undefined reference to `__gcov_time_profiler_counter'
:(.text+0x80): undefined reference to `__gcov_time_profiler_counter'
:(.text+0x84): undefined reference to `__gcov_time_profiler_counter'
/cc6RcpEu.ltrans0.ltrans.o: In function `_GLOBAL__sub_D_00100_1_fn1':
:(.text+0xb8): undefined reference to `__gcov_exit'
/cc6RcpEu.ltrans0.ltrans.o: In function `main':
:(.text+0xd4): undefined reference to
`__gcov_indirect_call_profiler_v2'
:(.text+0xd8): undefined reference to `__gcov_indirect_call_callee'
:(.text+0xdc): undefined reference to `__gcov_indirect_call_callee'
:(.text+0x10c): undefined reference to
`__gcov_time_profiler_counter'
:(.text+0x110): undefined reference to
`__gcov_time_profiler_counter'
/cc6RcpEu.ltrans0.ltrans.o: In function `_GLOBAL__sub_D_00100_1_main':
:(.text+0x180): undefined reference to `__gcov_exit'
/cc6RcpEu.ltrans0.ltrans.o:(.data+0x4c): undefined reference to
`__gcov_merge_time_profile'
/cc6RcpEu.ltrans0.ltrans.o:(.data+0xac): undefined reference to
`__gcov_merge_time_profile'
collect2: error: ld returned 1 exit status

FAIL: gcc.dg/lto/pr69188 c_lto_pr69188_0.o-c_lto_pr69188_1.o link,
-flto -O0 -fprofile-generate

It works on arm-linux*.

Christophe

Re: [ARM] Fix broken sibcall with longcall, APCS frame and VFP

[Richard Earnshaw (lists)]

On 20/01/17 18:13, Eric Botcazou wrote:
>> This seems to have fallen through a crack.  Did you get a chance to try
>> either of these suggestions?
> 
> So just:
> 
> /* { dg-do run } */
> /* { dg-options "-mapcs-frame -O -foptimize-sibling-calls 
> -ffunction-sections" 
> } */
> 
> in the header of the tescase?
> 

Yes, let's try it like that.  If it causes problems on multilib test
runs we can always revisit and apply some restrictions.

R.

Re: [PATCH] Do not declare artificial variables in tree-profile.c to have a definition (PR lto/69188).

[Kyrill Tkachov]

On 23/01/17 09:58, Christophe Lyon wrote:

On 13 January 2017 at 18:21, Jeff Law  wrote:

On 01/13/2017 08:08 AM, Martin Liška wrote:

Hello.

Nice example provided in the PR causes ICE as we have an artificial symbol
created in tree-profile.c once being removed by remove unreachable nodes
(-O0)
and once not (-O1). Well, difference is in process_references where
following hunk
prevent removal:

   || (((before_inlining_p
 && ((TREE_CODE (node->decl) != FUNCTION_DECL
  && optimize)

Anyway, these artificial symbols really should be just declarations as
they are defined
in libgcov library.

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

Ready to be installed?
Martin


0001-Do-not-declare-artificial-variables-in-tree-profile..patch


 From 87262b1b60009381fd943fb433bc38f5d5685ac9 Mon Sep 17 00:00:00 2001
From: marxin 
Date: Fri, 13 Jan 2017 13:12:57 +0100
Subject: [PATCH] Do not declare artificial variables in tree-profile.c to
have
  a definition (PR lto/69188).

gcc/testsuite/ChangeLog:

2017-01-13  Martin Liska  

 PR lto/69188
 * gcc.dg/lto/pr69188_0.c: New test.
 * gcc.dg/lto/pr69188_1.c: New test.

gcc/ChangeLog:

2017-01-13  Martin Liska  

 PR lto/69188
 * tree-profile.c (init_ic_make_global_vars): Do not call
 finalize_decl.
 (gimple_init_gcov_profiler): Likewise.

OK.
jeff


Hi,

The new test fails on arm-none-eabi:
/cc6RcpEu.ltrans0.ltrans.o: In function `fn1':
:(.text+0x18): undefined reference to
`__gcov_indirect_call_profiler_v2'
:(.text+0x1c): undefined reference to `__gcov_indirect_call_callee'
:(.text+0x20): undefined reference to `__gcov_indirect_call_callee'
:(.text+0x60): undefined reference to `__gcov_time_profiler_counter'
:(.text+0x64): undefined reference to `__gcov_time_profiler_counter'
:(.text+0x80): undefined reference to `__gcov_time_profiler_counter'
:(.text+0x84): undefined reference to `__gcov_time_profiler_counter'
/cc6RcpEu.ltrans0.ltrans.o: In function `_GLOBAL__sub_D_00100_1_fn1':
:(.text+0xb8): undefined reference to `__gcov_exit'
/cc6RcpEu.ltrans0.ltrans.o: In function `main':
:(.text+0xd4): undefined reference to
`__gcov_indirect_call_profiler_v2'
:(.text+0xd8): undefined reference to `__gcov_indirect_call_callee'
:(.text+0xdc): undefined reference to `__gcov_indirect_call_callee'
:(.text+0x10c): undefined reference to
`__gcov_time_profiler_counter'
:(.text+0x110): undefined reference to
`__gcov_time_profiler_counter'
/cc6RcpEu.ltrans0.ltrans.o: In function `_GLOBAL__sub_D_00100_1_main':
:(.text+0x180): undefined reference to `__gcov_exit'
/cc6RcpEu.ltrans0.ltrans.o:(.data+0x4c): undefined reference to
`__gcov_merge_time_profile'
/cc6RcpEu.ltrans0.ltrans.o:(.data+0xac): undefined reference to
`__gcov_merge_time_profile'
collect2: error: ld returned 1 exit status

FAIL: gcc.dg/lto/pr69188 c_lto_pr69188_0.o-c_lto_pr69188_1.o link,
-flto -O0 -fprofile-generate

It works on arm-linux*.


Hi,

The testcase fails on bare-metal targets that don't support profiling.
I believe it needs to be guarded with dg-require-profiling (I grepped around 
the testsuite for similar directives).
With this patch the testcase appears unsupported on aarch64-none-elf where I 
observed the failure.

Ok to commit?

Thanks,
Kyrill

2016-01-23  Kyrylo Tkachov  

* gcc.dg/lto/pr69188_0.c: Require profiling support for testcase.



Christophe


diff --git a/gcc/testsuite/gcc.dg/lto/pr69188_0.c b/gcc/testsuite/gcc.dg/lto/pr69188_0.c
index 8bee874..a0b6ad9 100644
--- a/gcc/testsuite/gcc.dg/lto/pr69188_0.c
+++ b/gcc/testsuite/gcc.dg/lto/pr69188_0.c
@@ -1,6 +1,7 @@
 /* PR ipa/69188 */
 /* { dg-lto-do link } */
 /* { dg-lto-options { { -flto -O0 -fprofile-generate } } } */
+/* { dg-require-profiling "-fprofile-generate" } */
 
 void fn1(void) 
 { 

Re: [RFC] fix bootstrap on aarch64-*-freebsd and probably others

[Richard Earnshaw (lists)]

On 21/01/17 20:15, Andreas Tobler wrote:
> On 21.01.17 00:42, Jakub Jelinek wrote:
>> On Fri, Jan 20, 2017 at 01:37:13PM -0700, Jeff Law wrote:
> Which is best will depend on what the front/mid ends might have
> done to
> apply the documented limit.

 Here I know not enough to give a decision. In tree the priority_type is
 unsigned short. In varasm priority is an int.

 Similar functions, like arm_elf_asm_cdtor, do use the sprintf
 instead of
 snprintf. They theoretically have the same issue.

 So, either:
 2.) use %.5hu in snprintf
 or
 3.) cast priority in snprintf to (unsigned short)
>>> I'd go with #2.  I think #3 still requires range propagation to avoid
>>> the
>>> false positive.
>>
>> I actually think 1.) is best work-around, after 18 bytes there will be
>> some
>> padding so 23 bytes will almost always eat the same amount of stack
>> space,
>> and we avoid actually adding some instruction to cast it or hoping all
>> the
>> libcs we run on support %.5hu properly.
> 
> Richard, what do you think about this suggestion?
> 
> Thanks,
> Andreas
> 


I'm happy to go with that, but please add a comment as well, or some
well meaning individual may accidentally reverse the change after
counting the bytes...

R.

Re: [PATCH] Do not declare artificial variables in tree-profile.c to have a definition (PR lto/69188).

[Martin Liška]

On 01/23/2017 11:05 AM, Kyrill Tkachov wrote:
> 
> On 23/01/17 09:58, Christophe Lyon wrote:
>> On 13 January 2017 at 18:21, Jeff Law  wrote:
>>> On 01/13/2017 08:08 AM, Martin Liška wrote:
 Hello.

 Nice example provided in the PR causes ICE as we have an artificial symbol
 created in tree-profile.c once being removed by remove unreachable nodes
 (-O0)
 and once not (-O1). Well, difference is in process_references where
 following hunk
 prevent removal:

|| (((before_inlining_p
  && ((TREE_CODE (node->decl) != FUNCTION_DECL
   && optimize)

 Anyway, these artificial symbols really should be just declarations as
 they are defined
 in libgcov library.

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

 Ready to be installed?
 Martin


 0001-Do-not-declare-artificial-variables-in-tree-profile..patch


  From 87262b1b60009381fd943fb433bc38f5d5685ac9 Mon Sep 17 00:00:00 2001
 From: marxin 
 Date: Fri, 13 Jan 2017 13:12:57 +0100
 Subject: [PATCH] Do not declare artificial variables in tree-profile.c to
 have
   a definition (PR lto/69188).

 gcc/testsuite/ChangeLog:

 2017-01-13  Martin Liska  

  PR lto/69188
  * gcc.dg/lto/pr69188_0.c: New test.
  * gcc.dg/lto/pr69188_1.c: New test.

 gcc/ChangeLog:

 2017-01-13  Martin Liska  

  PR lto/69188
  * tree-profile.c (init_ic_make_global_vars): Do not call
  finalize_decl.
  (gimple_init_gcov_profiler): Likewise.
>>> OK.
>>> jeff
>>>
>> Hi,
>>
>> The new test fails on arm-none-eabi:
>> /cc6RcpEu.ltrans0.ltrans.o: In function `fn1':
>> :(.text+0x18): undefined reference to
>> `__gcov_indirect_call_profiler_v2'
>> :(.text+0x1c): undefined reference to 
>> `__gcov_indirect_call_callee'
>> :(.text+0x20): undefined reference to 
>> `__gcov_indirect_call_callee'
>> :(.text+0x60): undefined reference to 
>> `__gcov_time_profiler_counter'
>> :(.text+0x64): undefined reference to 
>> `__gcov_time_profiler_counter'
>> :(.text+0x80): undefined reference to 
>> `__gcov_time_profiler_counter'
>> :(.text+0x84): undefined reference to 
>> `__gcov_time_profiler_counter'
>> /cc6RcpEu.ltrans0.ltrans.o: In function `_GLOBAL__sub_D_00100_1_fn1':
>> :(.text+0xb8): undefined reference to `__gcov_exit'
>> /cc6RcpEu.ltrans0.ltrans.o: In function `main':
>> :(.text+0xd4): undefined reference to
>> `__gcov_indirect_call_profiler_v2'
>> :(.text+0xd8): undefined reference to 
>> `__gcov_indirect_call_callee'
>> :(.text+0xdc): undefined reference to 
>> `__gcov_indirect_call_callee'
>> :(.text+0x10c): undefined reference to
>> `__gcov_time_profiler_counter'
>> :(.text+0x110): undefined reference to
>> `__gcov_time_profiler_counter'
>> /cc6RcpEu.ltrans0.ltrans.o: In function `_GLOBAL__sub_D_00100_1_main':
>> :(.text+0x180): undefined reference to `__gcov_exit'
>> /cc6RcpEu.ltrans0.ltrans.o:(.data+0x4c): undefined reference to
>> `__gcov_merge_time_profile'
>> /cc6RcpEu.ltrans0.ltrans.o:(.data+0xac): undefined reference to
>> `__gcov_merge_time_profile'
>> collect2: error: ld returned 1 exit status
>>
>> FAIL: gcc.dg/lto/pr69188 c_lto_pr69188_0.o-c_lto_pr69188_1.o link,
>> -flto -O0 -fprofile-generate
>>
>> It works on arm-linux*.
> 
> Hi,
> 
> The testcase fails on bare-metal targets that don't support profiling.
> I believe it needs to be guarded with dg-require-profiling (I grepped around 
> the testsuite for similar directives).
> With this patch the testcase appears unsupported on aarch64-none-elf where I 
> observed the failure.
> 
> Ok to commit?
> 
> Thanks,
> Kyrill

Hi Kyrill.

Thanks for the patch.

Martin

> 
> 2016-01-23  Kyrylo Tkachov  
> 
> * gcc.dg/lto/pr69188_0.c: Require profiling support for testcase.
> 
> 
>> Christophe
> 

[Ada] Allocating large modular arrays

[Arnaud Charlet]

This patch computes a guard for a storage error  on an object declaration for
an array type with a modular index type with the size of Long_Long_Integer.
Special processing is needed in this case to compute reliably the size of the
object, and eventually to raise Storage_Error, when wrap-around arithmetic
might compute a meangingless size for the object.

Executing:

   gnatmake -q -gnatws -fstack-check fail
   fail

must yield:

   raised STORAGE_ERROR : fail.adb:6 object too large

---
with Mod_Array; use Mod_Array;
procedure Fail is
   Str : String (1 .. 2014);

   function Create (Last : My_Index) return A is
  R : A (0 .. Last);
  for R'Address use Str'Address;
  pragma Import (Ada, R);
   begin
  return R;
   end Create;

   function Create2 (Last : My_Index) return A is
  R : A (0 .. Last);
   begin
  return R;
   end Create2;

   C : constant A := Create (My_Index'Last);
begin
   if C'Length = 0 then
  raise Program_Error;
   end if;

   if Create2 (My_Index'Last)'Length = 0 then
  raise Program_Error;
   end if;
end Fail;
---
package Mod_Array with SPARK_mode is
   type My_Index is mod 2 ** 64;

   type redundant is new Long_Long_Integer;
   type A is array (My_Index range <>) of Boolean with Pack;

   function My_Length (X : A) return My_Index is (X'Length);
end Mod_Array;

Tested on x86_64-pc-linux-gnu, committed on trunk

2017-01-23  Ed Schonberg  

* exp_ch3.adb (Check_Large_Modular_Array): New procedure,
subsidiary to Expand_N_Object_ Declaration, to compute a guard on
an object declaration for an array type with a modular index type
with the size of Long_Long_Integer. Special processing is needed
in this case to compute reliably the size of the object, and
eventually  to raise Storage_Error, when wrap-around arithmetic
might compute a meangingless size for the object.

Index: exp_ch3.adb
===
--- exp_ch3.adb (revision 244773)
+++ exp_ch3.adb (working copy)
@@ -5465,6 +5465,13 @@
   --  value, it may be possible to build an equivalent aggregate instead,
   --  and prevent an actual call to the initialization procedure.
 
+  procedure Check_Large_Modular_Array;
+  --  Check that the size of the array can be computed without overflow,
+  --  and generate a Storage_Error otherwise. This is only relevant for
+  --  array types whose index in a (mod 2**64) type, where wrap-around
+  --  arithmetic might yield a meaningless value for the length of the
+  --  array, or its corresponding attribute.
+
   procedure Default_Initialize_Object (After : Node_Id);
   --  Generate all default initialization actions for object Def_Id. Any
   --  new code is inserted after node After.
@@ -5603,6 +5610,58 @@
   end Build_Equivalent_Aggregate;
 
   ---
+  -- Check_Large_Modular_Array --
+  ---
+
+  procedure Check_Large_Modular_Array is
+ Index_Typ : Entity_Id;
+
+  begin
+ if Is_Array_Type (Typ)
+   and then Is_Modular_Integer_Type (Etype (First_Index (Typ)))
+ then
+--  To prevent arithmetic overflow with large values, we
+--  raise Storage_Error under the following guard:
+--
+--  (Arr'Last / 2 - Arr'First / 2) > (Typ'Last - 1) / 2
+
+--  This takes care of the boundary case, but it is preferable
+--  to use a smaller limit, because even on 64-bit architectures
+--  an array of more than 2 ** 30 bytes is likely to raise
+--  Storage_Error.
+
+Index_Typ := Etype (First_Index (Typ));
+if RM_Size (Index_Typ) = RM_Size (Standard_Long_Long_Integer) then
+   Insert_Action (N,
+  Make_Raise_Storage_Error (Loc,
+   Condition =>
+ Make_Op_Ge (Loc,
+   Left_Opnd  =>
+ Make_Op_Subtract (Loc,
+   Left_Opnd =>
+ Make_Op_Divide (Loc,
+   Left_Opnd =>
+ Make_Attribute_Reference (Loc,
+   Prefix => New_Occurrence_Of (Typ, Loc),
+ Attribute_Name => Name_Last),
+Right_Opnd =>
+  Make_Integer_Literal (Loc, Uint_2)),
+   Right_Opnd =>
+ Make_Op_Divide (Loc,
+   Left_Opnd =>
+ Make_Attribute_Reference (Loc,
+   Prefix => New_Occurrence_Of (Typ, Loc),
+   Attribute_Name => Name_First),
+Right_Opnd =>
+  Make_Integer_Literal (Loc, Uint_

[Ada] Spurious error on convention of anonymous access-to-subprogram type

[Arnaud Charlet]

This patch ensures that Ada RM 6.3.1 13.1/3 which states

   The calling convention for an anonymous access-to-subprogram parameter or
   anonymous access-to-subprogram result is protected if the reserved word
   protected appears in its definition; otherwise, it is the convention of
   the subprogram that contains the parameter.

properly sets the convention of an anonymous access-to-subprogram type to that
of the related subprogram.


-- Source --


--  conventions.ads

package Conventions is

   -
   -- Inherit Ada --
   -

   procedure Ada_1 (Ptr : access procedure);
   function  Ada_2 return access procedure;
   function  Ada_3 return access procedure;
   function  Ada_4 return access procedure;

   ---
   -- Inherit C --
   ---

   procedure C_1 (Ptr : access procedure) with Convention => C;
   function  C_2 return access procedure  with Convention => C;
   function  C_3 return access procedure  with Convention => C;
   function  C_4 return access procedure  with Convention => C;

   ---
   -- Inherit Protected --
   ---

   protected IP is
  procedure Prot_1 (Ptr : access procedure);
  function  Prot_2 return access procedure;
  function  Prot_3 return access procedure;
  function  Prot_4 return access procedure;
   end IP;

   
   -- Protected with Ada --
   

   procedure Prot_Ada_1 (Ptr : access protected procedure);  --  OK
   function  Prot_Ada_2 return access protected procedure;   --  OK

   --
   -- Protected with C --
   --

   procedure Prot_C_1 (Ptr : access protected procedure) --  OK
 with Convention => C;
   function  Prot_C_2 return access protected procedure  --  OK
 with Convention => C;

   --
   -- Protected with Protected --
   --

   protected PP is
  procedure Prot_1 (Ptr : access protected procedure);   --  OK
  function  Prot_2 return access protected procedure;--  OK
  function  Prot_3 return access protected procedure;--  OK
  function  Prot_4 return access protected procedure;--  OK
   end PP;

   ---
   -- Renamings --
   ---

   procedure Ren_Ada_1 (Ptr : access procedure) renames Ada_1;
   function  Ren_Ada_2 return access procedure  renames Ada_2;

   procedure Ren_C_1 (Ptr : access procedure) renames C_1;
   function  Ren_C_2 return access procedure  renames C_2;

   procedure Ren_Prot_1 (Ptr : access procedure) renames IP.Prot_1;
   function  Ren_Prot_2 return access procedure  renames IP.Prot_2;

   --
   -- Nestings --
   --

   procedure Nest_Ada_1
 (Ptr_1 : access procedure (Ptr_2 : access procedure));
   function  Nest_Ada_2
 return access procedure (Ptr : access procedure);
   function  Nest_Ada_3
 return access procedure (Ptr : access procedure);
   function  Nest_Ada_4
 return access procedure (Ptr : access procedure);

   procedure Nest_C_1
 (Ptr_1 : access procedure (Ptr_2 : access procedure))
 with Convention => C;
   function Nest_C_2
 return access procedure (Ptr : access procedure)
 with Convention => C;
   function Nest_C_3
 return access procedure (Ptr : access procedure)
 with Convention => C;
   function Nest_C_4
 return access procedure (Ptr : access procedure)
 with Convention => C;

   protected NP is
  procedure Prot_1 (Ptr_1 : access procedure (Ptr_2 : access procedure));
  function  Prot_2  return  access procedure (Ptr   : access procedure);
  function  Prot_3  return  access procedure (Ptr   : access procedure);
  function  Prot_4  return  access procedure (Ptr   : access procedure);
   end NP;

   procedure Calls;
end Conventions;

--  conventions.adb

package body Conventions is

   --  Specs

   procedure Ada_Proc;
   procedure Ada_Proc_Access (Ptr : access procedure);

   procedure C_Proc with Convention => C;
   procedure C_Proc_Access (Ptr : access procedure) with Convention => C;

   protected P is
  procedure Proc;
   end P;

   protected P_Access is
  procedure Proc (Ptr : access procedure);
   end P_Access;

   --  Bodies

   procedure Ada_Proc is
   begin null; end Ada_Proc;

   procedure Ada_Proc_Access (Ptr : access procedure) is
   begin null; end Ada_Proc_Access;

   procedure C_Proc is
   begin null; end C_Proc;

   procedure C_Proc_Access (Ptr : access procedure) is
   begin null; end C_Proc_Access;

   protected body P is
  procedure Proc is begin null; end Proc;
   end P;

   protected body P_Access is
  procedure Proc (Ptr : access procedure) is
  begin null; end Proc;
   end P_Access;

   -
   -- Inherit Ada --
   -

   procedure Ada_1 (Ptr : access procedure) is
   begin null; e

[Patch AArch64] Use 128-bit vectors when autovectorizing 16-bit float types

[James Greenhalgh]

Hi,

As subject, we have an oversight in aarch64_simd_container_mode for
HFmode inputs. This results in trunk only autovectorizing to a 64-bit vector,
rather than a full 128-bit vector.

The fix is obvious, we just need to handle HFmode, and return an
appropriate vector mode.

Tested on aarch64-none-elf with no issues. This patch looks low risk
for this development stage to me, though it fixes an oversight rather
than a regression.

OK?

Thanks,
James

---
gcc/

2017-01-23  James Greenhalgh  

* config/aarch64/aarch64.c (aarch64_simd_container_mode): Handle
HFmode.

gcc/testsuite/

2017-01-23  James Greenhalgh  

* gcc.target/aarch64/vect_fp16_1.c: New.

diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 0cf7d12..7efc1f2 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -10777,6 +10777,8 @@ aarch64_simd_container_mode (machine_mode mode, unsigned width)
 	return V2DFmode;
 	  case SFmode:
 	return V4SFmode;
+	  case HFmode:
+	return V8HFmode;
 	  case SImode:
 	return V4SImode;
 	  case HImode:
@@ -10793,6 +10795,8 @@ aarch64_simd_container_mode (machine_mode mode, unsigned width)
 	  {
 	  case SFmode:
 	return V2SFmode;
+	  case HFmode:
+	return V4HFmode;
 	  case SImode:
 	return V2SImode;
 	  case HImode:
diff --git a/gcc/testsuite/gcc.target/aarch64/vect_fp16_1.c b/gcc/testsuite/gcc.target/aarch64/vect_fp16_1.c
new file mode 100644
index 000..da0cd81
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/vect_fp16_1.c
@@ -0,0 +1,30 @@
+/* { dg-do compile } */
+/* { dg-options "-O3 -fno-vect-cost-model" } */
+
+/* Check that we vectorize to a full 128-bit vector for _Float16 and __fp16
+   types.  */
+
+/* Enable ARMv8.2-A+fp16 so we have access to the vector instructions.  */
+#pragma GCC target ("arch=armv8.2-a+fp16")
+
+_Float16
+sum_Float16 (_Float16 *__restrict__ __attribute__ ((__aligned__ (16))) a,
+	 _Float16 *__restrict__ __attribute__ ((__aligned__ (16))) b,
+	 _Float16 *__restrict__ __attribute__ ((__aligned__ (16))) c)
+{
+  for (int i = 0; i < 256; i++)
+a[i] = b[i] + c[i];
+}
+
+_Float16
+sum_fp16 (__fp16 *__restrict__ __attribute__ ((__aligned__ (16))) a,
+	  __fp16 *__restrict__ __attribute__ ((__aligned__ (16))) b,
+	  __fp16 *__restrict__ __attribute__ ((__aligned__ (16))) c)
+{
+  for (int i = 0; i < 256; i++)
+a[i] = b[i] + c[i];
+}
+
+/* Two FADD operations on "8h" data widths, one from sum_Float16, one from
+   sum_fp16.  */
+/* { dg-final { scan-assembler-times "fadd\tv\[0-9\]\+.8h" 2 } } */

[Ada] Proper matching of attribute 'Result in Refined_Depends

[Arnaud Charlet]

This patch updates the analysis of pragma Refined_Depends to properly match
a dependence clause with output ...'Result against a refinement clause with
output ...'Result. The patch introduces a mechanism to handle clarification
clauses. These are clauses which indicate that a particular constituent does
not participate in the data flow of the related subprogram. Such clauses are
optional and must be silently accepted during the analysis of Refined_Depends.

--
-- Code --
--

--  refinements.ads

package Refinements
  with SPARK_Mode => On,
   Abstract_State => (State_1, State_2, State_3)
is
   function F_1 return Integer
 with Global  => State_1,
  Depends => (F_1'Result => State_1);

   function F_2 return Integer
 with Global  => (State_1, State_2),
  Depends => (F_2'Result => (State_1, State_2));

   function F_3 return Integer
 with Global  => State_3,
  Depends => (F_3'Result => State_3);

   function F_4 return Integer
 with Global  => (State_1, State_3),
  Depends => (F_4'Result => (State_1, State_3));
end Refinements;

--  refinements.adb

package body Refinements
  with SPARK_Mode => On,
   Refined_State => (State_1 => (A, B),
 State_2 => (X, Y),
 State_3 => null)
is
   A, B, X, Y : Integer := 0;

   function F_1 return Integer
 with Refined_Global  => (A, B),
  Refined_Depends => (F_1'Result => A,
  null   => B)
   is begin return 0; end F_1;

   function F_2 return Integer
 with Refined_Global  => (A, B, X, Y),
  Refined_Depends => (F_2'Result => B,
  null   => (A, X, Y))
   is begin return 0; end F_2;

   function F_3 return Integer
 with Refined_Global  => null,
  Refined_Depends => (F_3'Result => null)
   is begin return 0; end F_3;

   function F_4 return Integer
 with Refined_Global  => (A, B),
  Refined_Depends => (F_4'Result => null,
  null   => (A, B))
   is begin return 0; end F_4; 
end Refinements;


-- Compilation and output --


$ gcc -c refinements.adb
refinements.ads:11:34: dependence clause of subprogram "F_2" has no matching
  refinement in body
refinements.ads:19:34: dependence clause of subprogram "F_4" has no matching
  refinement in body

Tested on x86_64-pc-linux-gnu, committed on trunk

2017-01-23  Hristian Kirtchev  

* sem_prag.adb (Analyze_Refined_Depends_In_Decl_Part): Move all global
variables to the local variable section. Update the profile
of various nested routine that previously had visibility
of those globals. One the matching phase has completed,
remove certain classes of clauses which are considered noise.
(Check_Dependency_Clause): Properly detect a match between two
'Result attributes. Update the various post-match cases to use
Is_Already_Matched as this routine now automatically recognizes
a previously matched 'Result attribute.
(Is_Already_Matched): New routine.
(Remove_Extra_Clauses): New routine.
(Report_Extra_Clauses): Remove the detection of ... => null
clauses as this is now done in Remove_Extra_Clauses.

Index: sem_prag.adb
===
--- sem_prag.adb(revision 244778)
+++ sem_prag.adb(working copy)
@@ -23772,45 +23772,35 @@
--
 
procedure Analyze_Refined_Depends_In_Decl_Part (N : Node_Id) is
-  Body_Inputs  : Elist_Id := No_Elist;
-  Body_Outputs : Elist_Id := No_Elist;
-  --  The inputs and outputs of the subprogram body synthesized from pragma
-  --  Refined_Depends.
-
-  Dependencies : List_Id := No_List;
-  Depends  : Node_Id;
-  --  The corresponding Depends pragma along with its clauses
-
-  Matched_Items : Elist_Id := No_Elist;
-  --  A list containing the entities of all successfully matched items
-  --  found in pragma Depends.
-
-  Refinements : List_Id := No_List;
-  --  The clauses of pragma Refined_Depends
-
-  Spec_Id : Entity_Id;
-  --  The entity of the subprogram subject to pragma Refined_Depends
-
-  Spec_Inputs  : Elist_Id := No_Elist;
-  Spec_Outputs : Elist_Id := No_Elist;
-  --  The inputs and outputs of the subprogram spec synthesized from pragma
-  --  Depends.
-
   procedure Check_Dependency_Clause
-(States : Elist_Id;
- Dep_Clause : Node_Id);
+(Spec_Id   : Entity_Id;
+ Dep_Clause: Node_Id;
+ Dep_States: Elist_Id;
+ Refinements   : List_Id;
+ Matched_Items : in out Elist_Id);
   --  Try to match a single dependency clause Dep_Clause against one or
   --  more refinement clauses found in list Refinements. Each successful
   --  matc

[Ada] Implementation of AI12-125-3 : add @ as abbreviation for LHS.

[Arnaud Charlet]

This is a first check-in for the implementation of Ada Issue AI12-0125-3,
that proposes the use of '@' to designate the LHS of an assignment within
the corresponding RHS. The following is a simple example of use:

---
with Ada.Numerics.Complex_Types; use Ada.Numerics.Complex_Types;
with Ada.Text_IO; use Ada.Text_IO;
procedure Try3 is
  type Comp is array (integer range 1..10) of complex;
  My_Complex_Array : Comp := (others => (0.5, 0.3));
begin
   for Count in Comp'Range loop
  My_Complex_Array (Count) := (Re => @.Re**2 - @.Im**2,
 Im => 2.0 * @.Re * @.Im);
   end loop;
   Put_Line (Float'Image (My_Complex_Array (5).Re));
end;
---

Its execution (currently under the extensions flag -gnatX) must print:

 1.6E-01

Tested on x86_64-pc-linux-gnu, committed on trunk

2017-01-23  Ed Schonberg  

* scans.ads: New token At_Sign. Remove '@' from list of illegal
characters for future version of the language. '@' is legal name.
* scng.ads, scng.adb (Scan):  Handle '@' appropriately.
* scn.adb (Scan_Reserved_Identifier): An occurrence of '@'
denotes a Target_Name.
* par-ch4.adb (P_Name, P_Primary): Handle Target_Name.
* sinfo.ads, sinfo.adb (N_Target_Name): New non-terminal node.
(Has_Target_Names): New flag on N_Assignment_Statement, to
indicate that RHS has occurrences of N_Target_Name.
* sem.adb: Call Analyze_Target_Name.
* sem_ch5.ads, sem_ch5.adb (Analyze_Target_Name): New subpogram.
(urrent_LHS): Global variable that denotes LHS of assignment,
used in the analysis of Target_Name nodes.
* sem_res.adb (Resolve_Target_Name): New procedure.
* exp_ch5.adb (Expand_Assign_With_Target_Names): (AI12-0125):
N is an assignment statement whose RHS contains occurences of @
that designate the value of the LHS of the assignment. If the
LHS is side-effect free the target names can be replaced with
a copy of the LHS; otherwise the semantics of the assignment
is described in terms of a procedure with an in-out parameter,
and expanded as such.
(Expand_N_Assignment_Statement): Call
Expand_Assign_With_Target_Names when needed.
* exp_util.adb (Insert_Actions): Take into account N_Target_Name.
* sprint.adb: Handle N_Target_Name.

Index: exp_ch5.adb
===
--- exp_ch5.adb (revision 244773)
+++ exp_ch5.adb (working copy)
@@ -115,6 +115,13 @@
--  clause (this last case is required because holes in the tagged type
--  might be filled with components from child types).
 
+   procedure Expand_Assign_With_Target_Names (N : Node_Id);
+   --  (AI12-0125): N is an assignment statement whose RHS contains occurrences
+   --  of @ that designate the value of the LHS of the assignment. If the LHS
+   --  is side-effect free the target names can be replaced with a copy of the
+   --  LHS; otherwise the semantics of the assignment is described in terms of
+   --  a procedure with an in-out parameter, and expanded as such.
+
procedure Expand_Formal_Container_Loop (N : Node_Id);
--  Use the primitives specified in an Iterable aspect to expand a loop
--  over a so-called formal container, primarily for SPARK usage.
@@ -1605,6 +1612,111 @@
   end;
end Expand_Assign_Record;
 
+   -
+   -- Expand_Assign_With_Target_Names --
+   -
+
+   procedure Expand_Assign_With_Target_Names (N : Node_Id) is
+  Loc : constant Source_Ptr := Sloc (N);
+  LHS : constant Node_Id := Name (N);
+  RHS : constant Node_Id := Expression (N);
+  Ent : Entity_Id;
+
+  New_RHS : Node_Id;
+
+  function  Replace_Target (N : Node_Id) return Traverse_Result;
+  --  Replace occurrences of the target name by the proper entity: either
+  --  the entity of the LHS in simple cases, or the formal of the
+  --  constructed procedure otherwise.
+
+  
+  -- Replace_Target --
+  
+
+  function  Replace_Target (N : Node_Id) return Traverse_Result is
+  begin
+ if Nkind (N) = N_Target_Name then
+Rewrite (N, New_Occurrence_Of (Ent, Sloc (N)));
+ end if;
+
+ Set_Analyzed (N, False);
+ return OK;
+  end Replace_Target;
+
+  procedure Replace_Target_Name is new Traverse_Proc (Replace_Target);
+
+   begin
+
+  New_RHS := New_Copy_Tree (RHS);
+
+  if Is_Entity_Name (LHS)
+ and then not Is_Renaming_Of_Object (Entity (LHS))
+  then
+ Ent := Entity (LHS);
+ Replace_Target_Name (New_RHS);
+ Rewrite (N,
+   Make_Assignment_Statement (Loc,
+ Name => Relocate_Node (LHS),
+ Expression => New_RHS));
+
+  elsif Side_Effect_Free (LHS) then
+ Ent := Make_Temporary (Loc, 'T');
+ Inser

Re: [PATCH] Add AVX512 k-mask intrinsics

[Kirill Yukhin]

On 20 Jan 23:03, Andrew Senkevich wrote:
> 2017-01-20 20:08 GMT+03:00 Kirill Yukhin :
> > Hi,
> > On 20 Jan 14:46, Uros Bizjak wrote:
> >> On Fri, Jan 20, 2017 at 2:32 PM, Andrew Senkevich
> >>  wrote:
> >>
> >> > here is intrinsics for ktest{b,w,d,q} and kortest{b,w,d,q}. Is it Ok?
> >> >
> >> > gcc/
> >> > * config/i386/avx512bwintrin.h: Add k-mask test, kortest intrinsics.
> >> > * config/i386/avx512dqintrin.h: Ditto.
> >> > * config/i386/avx512fintrin.h: Ditto.
> >> > * gcc/config/i386/i386.c: Handle new builtins.
> >> > * config/i386/i386-builtin.def: Add new builtins.
> >> > * config/i386/sse.md (ktest, kortest): New.
> >> > (UNSPEC_KORTEST, UNSPEC_KTEST): New.
> >> >
> >> > gcc/testsuite/
> >> > * gcc.target/i386/avx512bw-ktestd-1.c: New test.
> >> > * gcc.target/i386/avx512bw-ktestq-1.c: Ditto.
> >> > * gcc.target/i386/avx512dq-ktestb-1.c: Ditto.
> >> > * gcc.target/i386/avx512f-ktestw-1.c: Ditto.
> >> > * gcc.target/i386/avx512bw-kortestd-1.c: Ditto.
> >> > * gcc.target/i386/avx512bw-kortestq-1.c: Ditto.
> >> > * gcc.target/i386/avx512dq-kortestb-1.c: Ditto.
> >> > * gcc.target/i386/avx512f-kortestw-1.c: Ditto.
> >>
> >> IMO, you should add some runtime tests.
> > +1
> >
> >> Otherwise, the patch LGTM, but I'l leave the final approval to Kirill.
> > Anyway trunk is frozen, so I suppose you'll need OK from RM.
>
> Kirill, attached with runtime tests.
>
> Richard, are you OK to approve commit of this patch?
> It is last part of k-mask intrinsics, it would be great to have all
> intrinsics of this type available in single GCC release..
OK for main trunk. I'll check it in.

--
Thanks, K

[Ada] Implement AI95-0133 in Ada 95 (and Ada 83) mode

[Arnaud Charlet]

The original interpretation of record representation clauses with
reverse bit order from Ada 95 was modified by a Binding Interpretation
(AI95-0133). Apply it by default even in running in -gnat95 mode
(as is already unconditionally done in Ada 2005 move and above),
since the original behaviour is more confusing than useful to users
in general. A debug switch -gnatd.p is introduced to re-enable to
previous behaviour, for compatibility. (-gnatd.p has no effect when
running in Ada 2005 mode or above).

Tested on x86_64-pc-linux-gnu, committed on trunk

2017-01-23  Thomas Quinot  

* sem_ch13.adb (Adjust_Record_For_Reverse_Bit_Order):
Split original Ada 95 part off into new subprogram
below. Call that subprogram (instead of proceeding with
AI95-0133 behaviour) if debug switch -gnatd.p is in use.
(Adjust_Record_For_Reverse_Bit_Order_Ada_95): ... new subprogram
* debug.adb Document new switch -gnatd.p
* freeze.adb (Freeze_Entity.Freeze_Record_Type): Do not adjust
record for reverse bit order if an error has already been posted
on the record type.  This avoids generating extraneous "info:"
messages for illegal code.

Index: debug.adb
===
--- debug.adb   (revision 244773)
+++ debug.adb   (working copy)
@@ -106,7 +106,7 @@
--  d.m  For -gnatl, print full source only for main unit
--  d.n  Print source file names
--  d.o  Conservative elaboration order for indirect calls
-   --  d.p
+   --  d.p  Use original Ada 95 semantics for Bit_Order (disable AI95-0133)
--  d.q
--  d.r  Enable OK_To_Reorder_Components in non-variant records
--  d.s
@@ -558,6 +558,10 @@
--  d.o  Conservative elaboration order for indirect calls. This causes
--   P'Access to be treated as a call in more cases.
 
+   --  d.p  In Ada 95 (or 83) mode, use original Ada 95 behaviour for the
+   --   interpretation of component clauses crossing byte boundaries when
+   --   using the non-default bit order (i.e. ignore AI95-0133).
+
--  d.r  Forces the flag OK_To_Reorder_Components to be set in all record
--   base types that have no discriminants.
 
Index: freeze.adb
===
--- freeze.adb  (revision 244785)
+++ freeze.adb  (working copy)
@@ -4262,10 +4262,14 @@
  ("\??since no component clauses were specified", ADC);
 
 --  Here is where we do the processing to adjust component clauses
---  for reversed bit order, when not using reverse SSO.
+--  for reversed bit order, when not using reverse SSO. If an error
+--  has been reported on Rec already (such as SSO incompatible with
+--  bit order), don't bother adjusting as this may generate extra
+--  noise.
 
 elsif Reverse_Bit_Order (Rec)
   and then not Reverse_Storage_Order (Rec)
+  and then not Error_Posted (Rec)
 then
Adjust_Record_For_Reverse_Bit_Order (Rec);
 
Index: sem_ch13.adb
===
--- sem_ch13.adb(revision 244773)
+++ sem_ch13.adb(working copy)
@@ -80,6 +80,10 @@
-- Local Subprograms --
---
 
+   procedure Adjust_Record_For_Reverse_Bit_Order_Ada_95 (R : Entity_Id);
+   --  Helper routine providing the original (pre-AI95-0133) behaviour for
+   --  Adjust_Record_For_Reverse_Bit_Order.
+
procedure Alignment_Check_For_Size_Change (Typ : Entity_Id; Size : Uint);
--  This routine is called after setting one of the sizes of type entity
--  Typ to Size. The purpose is to deal with the situation of a derived
@@ -351,372 +355,404 @@
   Comp : Node_Id;
   CC   : Node_Id;
 
+  Max_Machine_Scalar_Size : constant Uint :=
+  UI_From_Int
+(Standard_Long_Long_Integer_Size);
+  --  We use this as the maximum machine scalar size
+
+  Num_CC : Natural;
+  SSU: constant Uint := UI_From_Int (System_Storage_Unit);
+
begin
-  --  Processing depends on version of Ada
+  --  Processing here used to depend on Ada version: the behaviour was
+  --  changed by AI95-0133. However this AI is a Binding interpretation,
+  --  so we now implement it even in Ada 95 mode. The original behaviour
+  --  from unamended Ada 95 is still available for compatibility under
+  --  debugging switch -gnatd.
 
-  --  For Ada 95, we just renumber bits within a storage unit. We do the
-  --  same for Ada 83 mode, since we recognize the Bit_Order attribute in
-  --  Ada 83, and are free to add this extension.
+  if Ada_Version < Ada_2005 and then Debug_Flag_Dot_P then
+ Adjust_Record_For_Reverse_Bit_Order_Ada_95 (R);
+ return;
+  end if;
 
-  if Ada_Version < A

Re: Fold strstr (s, t) eq/ne s to strcmp (s, t) eq/ne 0 if strlen (t) is known

[Martin Liška]

On 12/14/2016 09:03 AM, Jakub Jelinek wrote:
> On Wed, Dec 14, 2016 at 01:27:44PM +0530, Prathamesh Kulkarni wrote:
>> 2016-12-14  Jakub Jelinek  
>>  Prathamesh Kulkarni  
>>
>>  * tree-ssa-strlen.c (fold_strstr_to_memcmp): New function.
>>  (strlen_optimize_stmt): Call fold_strstr_to_memcmp.
>>
>> testsuite/
>>  * gcc.dg/strlenopt-30.c: New test-case.
> 
> Ok, thanks.
> But, you wrote the patch, so if you want to give me some credit, put
> yourself first at least.
> 
>   Jakub
> 

Caused PR79196.

Thanks,
Martin

[Ada] Update SPARK rules for checking volatile flavors of protected objects

[Arnaud Charlet]

Implement new rule SPARK RM 7.1.2(16) that only assigns the Async_Readers and
Async_Writers flavors of volatility to protected objects by default, and makes
protected objects inherit the Effective_Reads and Effective_Writes flavors of
volatility from their Part_Of components.

Tested on x86_64-pc-linux-gnu, committed on trunk

2017-01-23  Yannick Moy  

* sem_util.adb (Has_Enabled_Property): Treat
protected objects and variables differently from other variables.

Index: sem_util.adb
===
--- sem_util.adb(revision 244778)
+++ sem_util.adb(working copy)
@@ -9118,6 +9118,10 @@
  (Item_Id  : Entity_Id;
   Property : Name_Id) return Boolean
is
+  function Protected_Object_Has_Enabled_Property return Boolean;
+  --  Determine whether a protected object denoted by Item_Id has the
+  --  property enabled.
+
   function State_Has_Enabled_Property return Boolean;
   --  Determine whether a state denoted by Item_Id has the property enabled
 
@@ -9125,6 +9129,44 @@
   --  Determine whether a variable denoted by Item_Id has the property
   --  enabled.
 
+  ---
+  -- Protected_Object_Has_Enabled_Property --
+  ---
+
+  function Protected_Object_Has_Enabled_Property return Boolean is
+ Constits : constant Elist_Id := Part_Of_Constituents (Item_Id);
+ Constit_Elmt : Elmt_Id;
+ Constit_Id   : Entity_Id;
+
+  begin
+ --  Protected objects always have the properties Async_Readers and
+ --  Async_Writers. (SPARK RM 7.1.2(16))
+
+ if Property = Name_Async_Readers
+   or else Property = Name_Async_Writers
+ then
+return True;
+
+ --  Protected objects that have Part_Of components also inherit
+ --  their properties Effective_Reads and Effective_Writes. (SPARK
+ --  RM 7.1.2(16))
+
+ elsif Present (Constits) then
+Constit_Elmt := First_Elmt (Constits);
+while Present (Constit_Elmt) loop
+   Constit_Id := Node (Constit_Elmt);
+
+   if Has_Enabled_Property (Constit_Id, Property) then
+  return True;
+   end if;
+
+   Next_Elmt (Constit_Elmt);
+end loop;
+ end if;
+
+ return False;
+  end Protected_Object_Has_Enabled_Property;
+
   
   -- State_Has_Enabled_Property --
   
@@ -9302,8 +9344,20 @@
  --  The implicit case lacks all property pragmas
 
  elsif No (AR) and then No (AW) and then No (ER) and then No (EW) then
-return True;
 
+--  A variable of a protected type only has the properties
+--  Async_Readers and Async_Writers. It cannot have Part_Of
+--  components (only protected objects can), hence it cannot
+--  inherit their properties Effective_Reads and Effective_Writes.
+--  (SPARK RM 7.1.2(16))
+
+if Is_Protected_Type (Etype (Item_Id)) then
+   return Property = Name_Async_Readers
+ or else Property = Name_Async_Writers;
+else
+   return True;
+end if;
+
  else
 return False;
  end if;
@@ -9321,6 +9375,14 @@
   elsif Ekind (Item_Id) = E_Variable then
  return Variable_Has_Enabled_Property;
 
+  --  By default, protected objects only have the properties Async_Readers
+  --  and Async_Writers. If they have Part_Of components, they also inherit
+  --  their properties Effective_Reads and Effective_Writes. (SPARK RM
+  --  7.1.2(16))
+
+  elsif Ekind (Item_Id) = E_Protected_Object then
+ return Protected_Object_Has_Enabled_Property;
+
   --  Otherwise a property is enabled when the related item is effectively
   --  volatile.
 

Re: [PATCH] BRIG frontend: request for a global review

[Richard Biener]

On Fri, Jan 20, 2017 at 6:25 PM, Pekka Jääskeläinen  wrote:
> Hi Richard,
>
> On Fri, Jan 20, 2017 at 10:26 AM, Richard Biener
>  wrote:
>> So the #ifdef ENABLE_BRIG_FE shouldn't be needed anymore (nor the
>> configury for it).
>>
>> Otherwise this looks ok to me then.
>
> Attached is a patch set with that unnecessary ENABLE_BRIG_FE macro
> removed.  It has also been refreshed to the latest trunk.

Are you set up to commit these to trunk yourself or do you need help here?

Thanks,
Richard.

> Thanks,
> Pekka

Re: [PATCH] BRIG frontend: request for a global review

[Martin Jambor]

Hi,


On Mon, Jan 23, 2017 at 12:56:13PM +0100, Richard Biener wrote:
> On Fri, Jan 20, 2017 at 6:25 PM, Pekka Jääskeläinen  
> wrote:
> > Hi Richard,
> >
> > On Fri, Jan 20, 2017 at 10:26 AM, Richard Biener
> >  wrote:
> >> So the #ifdef ENABLE_BRIG_FE shouldn't be needed anymore (nor the
> >> configury for it).
> >>
> >> Otherwise this looks ok to me then.
> >
> > Attached is a patch set with that unnecessary ENABLE_BRIG_FE macro
> > removed.  It has also been refreshed to the latest trunk.
> 
> Are you set up to commit these to trunk yourself or do you need help here?
> 

Pekka is still in the process of requesting an account at gcc.gnu.org.
We agreed that I would commit the patches.

Over Saturday and today morning, I have bootstrappet and tested them
in various configurations (although mostly on x86_64 and only a little
bit on aarch64) and (together with a "svn mv libgomp/plugin/hsa.h
include/") I have not found any issue so far.

I suppose I should go ahead (in any case, if there is any fallout,
reach out to me too, at least until Pekka gets his account).

Thanks,

Martin

[Ada] Missing range check on if expression

[Arnaud Charlet]

This patch removes an optimization when evaluating integer literals within
qualified expressions that caused checks on if and case expressions to not be
generated properly.


-- Source --


--  call_do_smth.adb

with Test; use Test;
with Ada.Text_IO;

procedure Call_Do_Smth is
   X : T;
   Y : T;
begin
   Do_Smth (True, X, Y);

   Ada.Text_IO.Put_Line (T'Image (X));
   Ada.Text_IO.Put_Line (T'Image (Y));

end Call_Do_Smth;

--  test.ads

package Test with SPARK_Mode is

   subtype T is Positive range 5 .. 16;

   procedure Do_Smth (I : Boolean; Oha : out T; Ohb : out T);

end Test;

--  test.adb

package body Test with SPARK_Mode is

   procedure Do_Smth (I : Boolean; Oha : out T; Ohb : out T) is
  V : T :=
T'(if I then
0
 else
16);
  V2 : T :=
T'(case I is
 when True => 0,
 when False => 16);
   begin
  Oha := V;
  Ohb := V2;
   end Do_Smth;

end Test;


-- Compilation and output --


$ gnatmake -q call_do_smth.adb
test.adb:6:13: value not in range of type "T" defined at test.ads:3
test.adb:6:13: "Constraint_Error" would have been raised at run time
test.adb:11:27: value not in range of type "T" defined at test.ads:3
test.adb:11:27: "Constraint_Error" would have been raised at run time
gnatmake: "test.adb" compilation error

Tested on x86_64-pc-linux-gnu, committed on trunk

2017-01-23  Justin Squirek  

* sem_eval.adb (Eval_Integer_Literal): Add special
case to avoid optimizing out check if the literal appears in
an if-expression.

Index: sem_eval.adb
===
--- sem_eval.adb(revision 244773)
+++ sem_eval.adb(working copy)
@@ -2682,9 +2682,12 @@
   --  If the literal appears in a non-expression context, then it is
   --  certainly appearing in a non-static context, so check it. This is
   --  actually a redundant check, since Check_Non_Static_Context would
-  --  check it, but it seems worth while avoiding the call.
+  --  check it, but it seems worth while to optimize out the call.
 
-  if Nkind (Parent (N)) not in N_Subexpr
+  --  An exception is made for a literal in an if or case expression
+
+  if (Nkind_In (Parent (N), N_If_Expression, N_Case_Expression_Alternative)
+   or else Nkind (Parent (N)) not in N_Subexpr)
 and then not In_Any_Integer_Context
   then
  Check_Non_Static_Context (N);

[Ada] Crash on class-wide 'Attribute clause

[Arnaud Charlet]

This patch adds an extra restriction to the placement of an 'Address attribute
definition clause where a prefix of a class-wide type cannot be subject to the
clause.


-- Source --


--  types.ads

with Ada.Finalization; use Ada.Finalization;

package Types is
   type Arr_Typ is array (1 .. 5) of Integer;

   type Ctrl is new Controlled with record
  Comp : Integer;
   end record;

   type Rec_Ctrl is record
  Comp : Ctrl;
   end record;

   type Rec_Typ is record
  Comp : Integer;
   end record;

   type Tag_Typ is tagged record
  Comp : Integer;
   end record;

   function Make_Any_Tag_Typ return Tag_Typ'Class;
end Types;

--  gnat_address.adb

with System; use System;
with Types;  use Types;

procedure GNAT_Address (Here : Address) is
   Obj_1 : Integer;
   for Obj_1'Address use Here;   --  OK

   Obj_2 : Arr_Typ;
   for Obj_2'Address use Here;   --  OK

   Obj_3 : Ctrl;
   for Obj_3'Address use Here;   --  Error

   Obj_4 : Rec_Ctrl;
   for Obj_4'Address use Here;   --  Error

   Obj_5 : Rec_Typ;
   for Obj_5'Address use Here;   --  OK

   Obj_6 : Tag_Typ;
   for Obj_6'Address use Here;   --  Error

   Obj_7 : Tag_Typ'Class := Make_Any_Tag_Typ;
   for Obj_7'Address use Here;   --  Error
begin null; end GNAT_Address;


-- Compilation and output --


$ gcc -c gnat_address.adb
t_address.adb:11:04: warning: variable "Obj_3" is read but never assigned
gnat_address.adb:12:08: warning: controlled object "Obj_3" must not be overlaid
gnat_address.adb:12:08: warning: Program_Error will be raised at run time
gnat_address.adb:14:04: warning: variable "Obj_4" is read but never assigned
gnat_address.adb:15:08: warning: controlled object "Obj_4" must not be overlaid
gnat_address.adb:15:08: warning: Program_Error will be raised at run time
gnat_address.adb:21:08: warning: default initialization of "Obj_6" may modify
  overlaid storage
gnat_address.adb:21:08: warning: use pragma Import for "Obj_6" to suppress
  initialization (RM B.1(24))
gnat_address.adb:24:08: warning: class-wide object "Obj_7" must not be overlaid
gnat_address.adb:24:08: warning: Program_Error will be raised at run time

Tested on x86_64-pc-linux-gnu, committed on trunk

2017-01-23  Hristian Kirtchev  

* sem_ch13.adb (Analyze_Attribute_Definition_Clause): Do not
allow an 'Address clause to be specified on a prefix of a
class-wide type.

Index: sem_ch13.adb
===
--- sem_ch13.adb(revision 244788)
+++ sem_ch13.adb(working copy)
@@ -4915,7 +4915,7 @@
   or else Has_Controlled_Component (Etype (U_Ent))
 then
Error_Msg_NE
- ("??controlled object& must not be overlaid", Nam, U_Ent);
+ ("??controlled object & must not be overlaid", Nam, U_Ent);
Error_Msg_N
  ("\??Program_Error will be raised at run time", Nam);
Insert_Action (Declaration_Node (U_Ent),
@@ -4923,6 +4923,19 @@
Reason => PE_Overlaid_Controlled_Object));
return;
 
+--  Case of an address clause for a class-wide object which is
+--  considered erroneous.
+
+elsif Is_Class_Wide_Type (Etype (U_Ent)) then
+   Error_Msg_NE
+ ("??class-wide object & must not be overlaid", Nam, U_Ent);
+   Error_Msg_N
+ ("\??Program_Error will be raised at run time", Nam);
+   Insert_Action (Declaration_Node (U_Ent),
+ Make_Raise_Program_Error (Loc,
+   Reason => PE_Overlaid_Controlled_Object));
+   return;
+
 --  Case of address clause for a (non-controlled) object
 
 elsif Ekind_In (U_Ent, E_Variable, E_Constant) then

[Ada] Validity checks prevent copy back of scalar IN OUT parameter

[Arnaud Charlet]

This patch modifies the generation of validity checks to generate a renaming of
the expression being verified when the expression denotes a name. For all other
kinds of expressions, the validity check machinery creates a constant to store
the value of the expression. The use of renaming prevents the generation of a
redundant copy and acts as a proper alias of the name.


-- Source --


--  pack.ads

package Pack is
   type Int is mod 2 ** 32;
   for Int'Size use 32;

   function Swap_All_Bits (Val : Int) return Int;
end Pack;

--  pack.adb

package body Pack is
   type Bit_Map is record
  Bit_1  : Boolean;
  Bit_2  : Boolean;
  Bit_3  : Boolean;
  Bit_4  : Boolean;
  Bit_5  : Boolean;
  Bit_6  : Boolean;
  Bit_7  : Boolean;
  Bit_8  : Boolean;
  Bit_9  : Boolean;
  Bit_10 : Boolean;
  Bit_11 : Boolean;
  Bit_12 : Boolean;
  Bit_13 : Boolean;
  Bit_14 : Boolean;
  Bit_15 : Boolean;
  Bit_16 : Boolean;
  Bit_17 : Boolean;
  Bit_18 : Boolean;
  Bit_19 : Boolean;
  Bit_20 : Boolean;
  Bit_21 : Boolean;
  Bit_22 : Boolean;
  Bit_23 : Boolean;
  Bit_24 : Boolean;
  Bit_25 : Boolean;
  Bit_26 : Boolean;
  Bit_27 : Boolean;
  Bit_28 : Boolean;
  Bit_29 : Boolean;
  Bit_30 : Boolean;
  Bit_31 : Boolean;
  Bit_32 : Boolean;
   end record;

   for Bit_Map'Size use 32;

   for Bit_Map use record
  Bit_1  at 0 range  0 .. 0;
  Bit_2  at 0 range  1 .. 1;
  Bit_3  at 0 range  2 .. 2;
  Bit_4  at 0 range  3 .. 3;
  Bit_5  at 0 range  4 .. 4;
  Bit_6  at 0 range  5 .. 5;
  Bit_7  at 0 range  6 .. 6;
  Bit_8  at 0 range  7 .. 7;
  Bit_9  at 0 range  8 .. 8;
  Bit_10 at 0 range  9 .. 9;
  Bit_11 at 0 range 10 .. 10;
  Bit_12 at 0 range 11 .. 11;
  Bit_13 at 0 range 12 .. 12;
  Bit_14 at 0 range 13 .. 13;
  Bit_15 at 0 range 14 .. 14;
  Bit_16 at 0 range 15 .. 15;
  Bit_17 at 0 range 16 .. 16;
  Bit_18 at 0 range 17 .. 17;
  Bit_19 at 0 range 18 .. 18;
  Bit_20 at 0 range 19 .. 19;
  Bit_21 at 0 range 20 .. 20;
  Bit_22 at 0 range 21 .. 21;
  Bit_23 at 0 range 22 .. 22;
  Bit_24 at 0 range 23 .. 23;
  Bit_25 at 0 range 24 .. 24;
  Bit_26 at 0 range 25 .. 25;
  Bit_27 at 0 range 26 .. 26;
  Bit_28 at 0 range 27 .. 27;
  Bit_29 at 0 range 28 .. 28;
  Bit_30 at 0 range 29 .. 29;
  Bit_31 at 0 range 30 .. 30;
  Bit_32 at 0 range 31 .. 31;
   end record;

   function Swap_All_Bits (Val : Int) return Int is
  procedure Swap_One_Bit (L : in out Boolean; R : in out Boolean) is
 Temp : Boolean := L;
  begin
 L := R;
 R := Temp;
  end Swap_One_Bit;

  Result : Int;

  Map : Bit_Map;
  for Map'Address use Result'Address;
  pragma Volatile (Map);

   begin
  Result := Val;

  Swap_One_Bit (Map.Bit_1, Map.Bit_8);
  Swap_One_Bit (Map.Bit_2, Map.Bit_7);
  Swap_One_Bit (Map.Bit_3, Map.Bit_6);
  Swap_One_Bit (Map.Bit_4, Map.Bit_5);

  Swap_One_Bit (Map.Bit_9,  Map.Bit_16);
  Swap_One_Bit (Map.Bit_10, Map.Bit_15);
  Swap_One_Bit (Map.Bit_11, Map.Bit_14);
  Swap_One_Bit (Map.Bit_12, Map.Bit_13);

  Swap_One_Bit (Map.Bit_17, Map.Bit_24);
  Swap_One_Bit (Map.Bit_18, Map.Bit_23);
  Swap_One_Bit (Map.Bit_19, Map.Bit_22);
  Swap_One_Bit (Map.Bit_20, Map.Bit_21);

  Swap_One_Bit (Map.Bit_25, Map.Bit_32);
  Swap_One_Bit (Map.Bit_26, Map.Bit_31);
  Swap_One_Bit (Map.Bit_27, Map.Bit_30);
  Swap_One_Bit (Map.Bit_28, Map.Bit_29);

  return Result;
   end Swap_All_Bits;
end Pack;

--  swapper.adb

with Ada.Text_IO; use Ada.Text_IO;
with Pack;use Pack;

procedure Swapper is
   Expect : constant Int := 16##;
   Output : constant Int := Swap_All_Bits (16##);

begin
   if Output /= Expect then
  Put_Line ("ERROR");
   end if;
end Swapper;

-
-- Compilation --
-

$ gnatmake -q -gnatVa swapper.adb
$ ./swapper

Tested on x86_64-pc-linux-gnu, committed on trunk

2017-01-23  Hristian Kirtchev  

* checks.adb (Insert_Valid_Check): Ensure that the prefix of
attribute 'Valid is a renaming of the original expression when
the expression denotes a name. For all other kinds of expression,
use a constant to capture the value.
* exp_util.adb (Is_Name_Reference): Moved to Sem_Util.
* sem_util.ads, sem_util.adb (Is_Name_Reference): Moved from Exp_Util.

Index: exp_util.adb
===
--- exp_util.adb(revision 244790)
+++ exp_util.adb(working copy)
@@ -9014,12 +9014,6 @@
   --  is present (xxx is taken from the Chars field of Related_Nod),
   --  otherwise it generates an internal temporary.
 
-  function Is_Name_Reference (N : Node_Id) return Boolean;
-  --  Determine if the tree refere

Re: [PATCH] Speed-up use-after-scope (re-writing to SSA) (version 2)

[Martin Liška]

On 01/23/2017 10:38 AM, Jakub Jelinek wrote:
> On Mon, Jan 23, 2017 at 10:19:33AM +0100, Martin Liška wrote:
>> diff --git a/gcc/gimplify.c b/gcc/gimplify.c
>> index 2777a23eb93..1b076fdf45c 100644
>> --- a/gcc/gimplify.c
>> +++ b/gcc/gimplify.c
>> @@ -1206,8 +1206,19 @@ asan_poison_variables (hash_set *variables, 
>> bool poison, gimple_seq *seq_p
>>  
>>sorted_variables.qsort (sort_by_decl_uid);
>>  
>> -  for (unsigned i = 0; i < sorted_variables.length (); i++)
>> -asan_poison_variable (sorted_variables[i], poison, seq_p);
>> +  unsigned i;
>> +  tree var;
>> +  FOR_EACH_VEC_ELT (sorted_variables, i, var)
>> +{
>> +  asan_poison_variable (var, poison, seq_p);
>> +
>> +  /* Add use_after_scope_memory attribute for the variable in order
>> + to prevent re-written into SSA.  */
>> +  DECL_ATTRIBUTES (var)
>> += tree_cons (get_identifier ("use_after_scope_memory"),
> 
> Please use "use after scope memory" to make it clear it is internal
> only attribute users can't specify.
> Also, can't asan_poison_variables be performed on the same var
> multiple times (multiple labels, or switches, ...)?
> If yes, then the addition of the attribute should be guarded
> with if (!lookup_attribute ("use after scope memory", DECL_ATTRIBUTES (vars)))
> so that you don't add the attributes many times.
> 
>> + build_int_cst (integer_type_node, 1),
>> + DECL_ATTRIBUTES (var));
> 
> Please use:
>integer_one_node, DECL_ATTRIBUTES (var));
> instead.
> 
>> --- a/gcc/tree-ssa.c
>> +++ b/gcc/tree-ssa.c
>> @@ -1565,6 +1565,10 @@ is_asan_mark_p (gimple *stmt)
>>&& VAR_P (TREE_OPERAND (addr, 0)))
>>  {
>>tree var = TREE_OPERAND (addr, 0);
>> +  if (lookup_attribute ("use_after_scope_memory",
>> +DECL_ATTRIBUTES (var)))
>> +return false;
> 
> See above.
> 
> Patchset is ok for trunk with these nits fixed, thanks.
> 
>   Jakub
> 

Great, installed as r244791 and r244793. One more time, really thank
you for help, it took some time to finalize the optimization.

Martin

[Ada] Pragma Discard_Names and exception declarations

[Arnaud Charlet]

This patch extends the functionality of pragma Discard_Names to suppress the
generation of the String names of exception declarations. As a result, these
names do not appear in the final binary. A side effect of this functionality
is that routine Ada.Exceptions.Exception_Name will return an empty String.


-- Source --


--  gnat.adc

pragma Discard_Names;

--  pack.ads

package Pack is
   External_Exception : exception;

   procedure Raise_EE (Do_It : Boolean);
end Pack;

--  pack.adb

with Ada.Text_IO; use Ada.Text_IO;

package body Pack is
   procedure Raise_EE (Do_It : Boolean) is
   begin
  if Do_It then
 Put_Line ("about to raise External_Exception");
 raise External_Exception;
  end if;
   end Raise_EE;
end Pack;

--  main.adb

with Ada.Exceptions; use Ada.Exceptions;
with Ada.Text_IO;use Ada.Text_IO;
with Pack;   use Pack;

procedure Main is
   Local_Exception : exception;

   procedure Iterate_Over (High : Natural) is
   begin
  for Iter in 0 .. High loop
 begin
Raise_EE (Iter mod 13 = 0);

 exception
when External_Exception =>
   Put_Line ("caught External_Exception");
 end;
  end loop;

  raise Local_Exception;
   end Iterate_Over;

begin
   Put_Line (Exception_Name (External_Exception'Identity));
   Put_Line (Exception_Name (Local_Exception'Identity));

   Iterate_Over (15);

exception
   when Local_Exception =>
  Put_Line ("caught Local_Exception");
end Main;


-- Compilation and output --


$ gnatmake -q main.adb
$ main
$ grep -c "EXTERNAL_EXCEPTION" main
$ grep -c "LOCAL_EXCEPTION" main


about to raise External_Exception
caught External_Exception
about to raise External_Exception
caught External_Exception
caught Local_Exception
0
0

Tested on x86_64-pc-linux-gnu, committed on trunk

2017-01-23  Hristian Kirtchev  

* exp_ch11.adb (Expand_N_Exception_Declaration): Generate an
empty name when the exception declaration is subject to pragma
Discard_Names.
(Null_String): New routine.

Index: exp_ch11.adb
===
--- exp_ch11.adb(revision 244773)
+++ exp_ch11.adb(working copy)
@@ -1171,11 +1171,8 @@
-- end if;
 
procedure Expand_N_Exception_Declaration (N : Node_Id) is
-  Id  : constant Entity_Id  := Defining_Identifier (N);
-  Loc : constant Source_Ptr := Sloc (N);
-  Ex_Id   : Entity_Id;
-  Flag_Id : Entity_Id;
-  L   : List_Id;
+  Id  : constant Entity_Id  := Defining_Identifier (N);
+  Loc : constant Source_Ptr := Sloc (N);
 
   procedure Force_Static_Allocation_Of_Referenced_Objects
 (Aggregate : Node_Id);
@@ -1205,6 +1202,9 @@
   --  references to other local (non-hoisted) objects (e.g., in the initial
   --  value expression).
 
+  function Null_String return String_Id;
+  --  Build a null-terminated empty string
+
   ---
   -- Force_Static_Allocation_Of_Referenced_Objects --
   ---
@@ -1248,6 +1248,24 @@
  Fixup_Tree (Aggregate);
   end Force_Static_Allocation_Of_Referenced_Objects;
 
+  -
+  -- Null_String --
+  -
+
+  function Null_String return String_Id is
+  begin
+ Start_String;
+ Store_String_Char (Get_Char_Code (ASCII.NUL));
+ return End_String;
+  end Null_String;
+
+  --  Local variables
+
+  Ex_Id   : Entity_Id;
+  Ex_Val  : String_Id;
+  Flag_Id : Entity_Id;
+  L   : List_Id;
+
--  Start of processing for Expand_N_Exception_Declaration
 
begin
@@ -1262,14 +1280,25 @@
   Ex_Id :=
 Make_Defining_Identifier (Loc, New_External_Name (Chars (Id), 'E'));
 
+  --  Do not generate an external name if the exception declaration is
+  --  subject to pragma Discard_Names. Use a null-terminated empty name
+  --  to ensure that Ada.Exceptions.Exception_Name functions properly.
+
+  if Global_Discard_Names or else Discard_Names (Ex_Id) then
+ Ex_Val := Null_String;
+
+  --  Otherwise generate the fully qualified name of the exception
+
+  else
+ Ex_Val := Fully_Qualified_Name_String (Id);
+  end if;
+
   Insert_Action (N,
 Make_Object_Declaration (Loc,
   Defining_Identifier => Ex_Id,
   Constant_Present=> True,
   Object_Definition   => New_Occurrence_Of (Standard_String, Loc),
-  Expression  =>
-Make_String_Literal (Loc,
-  Strval => Fully_Qualified_Name_String (Id;
+  Expression  => Make_String_Literal (Loc, Ex_Val)));
 
   Set_Is_Statically_Allocated (Ex_Id);
 

[Ada] Missing detection of illegally placed pragma Assert

[Arnaud Charlet]

This patch modifies the parsing of protected and task definitions to detect
illegal placement of pragmas Assert and Debug within the protected or task
item lists.


-- Source --


--  synch_pragmas.ads

package Synch_Pragmas is
   protected PO is
  pragma Assert (PO'Size > 0);   --  Error
  procedure P;
  pragma Assert (PO'Size > 0);   --  Error
   private
  pragma Assert (PO'Size > 0);   --  Error
  function F return Boolean;
  pragma Assert (PO'Size > 0);   --  Error
  Comp : Integer;
  pragma Assert (PO'Size > 0);   --  Error
   end PO;

   protected type PT is
  pragma Assert (PT'Size > 0);   --  Error
  procedure P;
  pragma Assert (PT'Size > 0);   --  Error
   private
  pragma Assert (PT'Size > 0);   --  Error
  function F return Boolean;
  pragma Assert (PT'Size > 0);   --  Error
  Comp : Integer;
  pragma Assert (PT'Size > 0);   --  Error
   end PT;

   task TO is
  pragma Assert (TO'Size > 0);   --  Error
  entry E;
  pragma Assert (TO'Size > 0);   --  Error
   private
  pragma Assert (TO'Size > 0);   --  Error
  entry E2;
  pragma Assert (TO'Size > 0);   --  Error
   end TO;

   task type TT is
  pragma Assert (TT'Size > 0);   --  Error
  entry E;
  pragma Assert (TT'Size > 0);   --  Error
   private
  pragma Assert (TT'Size > 0);   --  Error
  entry E2;
  pragma Assert (TT'Size > 0);   --  Error
   end TT;
end Synch_Pragmas;


-- Compilation and output --


$ gcc -c synch_pragmas.ads
synch_pragmas.ads:3:07: pragma "Assert" must be in declaration/statement
  context
synch_pragmas.ads:5:07: pragma "Assert" must be in declaration/statement
  context
synch_pragmas.ads:7:07: pragma "Assert" must be in declaration/statement
  context
synch_pragmas.ads:9:07: pragma "Assert" must be in declaration/statement
  context
synch_pragmas.ads:11:07: pragma "Assert" must be in declaration/statement
  context
synch_pragmas.ads:15:07: pragma "Assert" must be in declaration/statement
  context
synch_pragmas.ads:17:07: pragma "Assert" must be in declaration/statement
  context
synch_pragmas.ads:19:07: pragma "Assert" must be in declaration/statement
  context
synch_pragmas.ads:21:07: pragma "Assert" must be in declaration/statement
  context
synch_pragmas.ads:23:07: pragma "Assert" must be in declaration/statement
  context
synch_pragmas.ads:27:07: pragma "Assert" must be in declaration/statement
  context
synch_pragmas.ads:29:07: pragma "Assert" must be in declaration/statement
  context
synch_pragmas.ads:31:07: pragma "Assert" must be in declaration/statement
  context
synch_pragmas.ads:33:07: pragma "Assert" must be in declaration/statement
  context
synch_pragmas.ads:37:07: pragma "Assert" must be in declaration/statement
  context
synch_pragmas.ads:39:07: pragma "Assert" must be in declaration/statement
  context
synch_pragmas.ads:41:07: pragma "Assert" must be in declaration/statement
  context
synch_pragmas.ads:43:07: pragma "Assert" must be in declaration/statement
  context

Tested on x86_64-pc-linux-gnu, committed on trunk

2017-01-23  Hristian Kirtchev  

* par-ch9.adb (P_Protected_Definition): Parse
any optional and potentially illegal pragmas which appear in
a protected operation declaration list.
(P_Task_Items): Parse
any optional and potentially illegal pragmas which appear in a
task item list.

Index: par-ch9.adb
===
--- par-ch9.adb (revision 244773)
+++ par-ch9.adb (working copy)
@@ -338,10 +338,10 @@
  Decl_Sloc := Token_Ptr;
 
  if Token = Tok_Pragma then
-Append (P_Pragma, Items);
+P_Pragmas_Opt (Items);
 
- --  Ada 2005 (AI-397): Reserved words NOT and OVERRIDING
- --  may begin an entry declaration.
+ --  Ada 2005 (AI-397): Reserved words NOT and OVERRIDING may begin an
+ --  entry declaration.
 
  elsif Token = Tok_Entry
or else Token = Tok_Not
@@ -350,8 +350,9 @@
 Append (P_Entry_Declaration, Items);
 
  elsif Token = Tok_For then
---  Representation clause in task declaration. The only rep
---  clause which is legal in a protected is an address clause,
+
+--  Representation clause in

[Ada] Ada2020 feature: partial aggregate notation (Delta aggregates).

[Arnaud Charlet]

This patch implements AI12-0127, which describes a new constructor for
aggregate in terms of an existing record or array aggregate and a series
of component-wise modifications of its value.

Executing:

   gnatmake -gnat2020 -q a2020
   a2020


must yield:

 1
 2
 9
 16
 25

---
with Text_IO; use Text_IO;
procedure A2020 is
   type Powers is array (1..5) of integer;
   type Table is array (1..4) of Powers;
   Thing : Table;
begin
   Thing := (others => (for I in Powers'range => I));
   Thing (2) := (@ with delta for J in 3..5 => @(j) ** 2);
   for I in Powers'range loop
  Put_Line (Integer'Image (Thing (2)(I)));
   end loop;
end;

Tested on x86_64-pc-linux-gnu, committed on trunk

2017-01-23  Ed Schonberg  

* par-ch4.adb (P_Aggregate_Or_Parent_Expr): Recognize delta
aggregate construct.
(P_Record_Or_Array_Component_Association): An array aggregate
can start with an Iterated_Component_Association.
* scng.adb: Modify error message on improper use of @ in earlier
versions of the language.
* sinfo.ads: New node kind N_Delta_Aggregate.
* sinfo.adb: An N_Delta_Aggregate has component associations and
an expression.
* sem_res.adb (Resolve): Call Resolve_Delta_Aggregate.
* sem_aggr.ads, sem_aggr.adb (Resolve_Iterated_Component_Association):
Create a new index for each one of the choices in the association,
to prevent spurious homonyms in the scope.
(Resolve_Delta_Aggregate): New.
* sem.adb: An N_Delta_Aggregate is analyzed like an aggregate.
* exp_util.adb (Insert_Actions): Take into account
N_Delta_Aggregate.
* exp_aggr.ads: New procedure Expand_N_Delta_Aggregate.
* exp_aggr.adb: New procedure Expand_N_Delta_Aggregate,
and local procedures Expand_Delta_Array_Aggregate and
expand_Delta_Record_Aggregate.
* sprint.adb: Handle N_Delta_Aggregate.

Index: sem_aggr.adb
===
--- sem_aggr.adb(revision 244784)
+++ sem_aggr.adb(working copy)
@@ -1678,11 +1678,17 @@
  Set_Etype  (Ent, Standard_Void_Type);
  Set_Parent (Ent, Parent (N));
 
- Enter_Name (Id);
- Set_Etype (Id, Index_Typ);
- Set_Ekind (Id, E_Variable);
- Set_Scope (Id, Ent);
+ --  Decorate the index variable in the current scope. The association
+ --  may have several choices, each one leading to a loop, so we create
+ --  this variable only once to prevent homonyms in this scope.
 
+ if No (Scope (Id)) then
+Enter_Name (Id);
+Set_Etype (Id, Index_Typ);
+Set_Ekind (Id, E_Variable);
+Set_Scope (Id, Ent);
+ end if;
+
  Push_Scope (Ent);
  Dummy := Resolve_Aggr_Expr (Expression (N), False);
  End_Scope;
@@ -2082,6 +2088,9 @@
  return Failure;
   end if;
 
+   elsif Nkind (Assoc) = N_Iterated_Component_Association then
+  null;   --  handled above, in a loop context.
+
elsif not Resolve_Aggr_Expr
(Expression (Assoc), Single_Elmt => Single_Choice)
then
@@ -2726,6 +2735,143 @@
   return Success;
end Resolve_Array_Aggregate;
 
+   -
+   -- Resolve_Delta_Aggregate --
+   -
+
+   procedure Resolve_Delta_Aggregate (N : Node_Id; Typ : Entity_Id) is
+  Base   : constant Node_Id   := Expression (N);
+  Deltas : constant List_Id   := Component_Associations (N);
+  Assoc  : Node_Id;
+  Choice : Node_Id;
+  Comp_Type  : Entity_Id;
+  Index_Type : Entity_Id;
+
+  function Get_Component_Type (Nam : Node_Id) return Entity_Id;
+
+  
+  -- Get_Component_Type --
+  
+
+  function Get_Component_Type (Nam : Node_Id) return Entity_Id is
+ Comp : Entity_Id;
+
+  begin
+ Comp := First_Entity (Typ);
+
+ while Present (Comp) loop
+if Chars (Comp) = Chars (Nam) then
+   if Ekind (Comp) = E_Discriminant then
+  Error_Msg_N ("delta cannot apply to discriminant", Nam);
+   end if;
+
+   return Etype (Comp);
+end if;
+
+Comp := Next_Entity (Comp);
+ end loop;
+
+ Error_Msg_NE ("type& has no component with this name", Nam, Typ);
+ return Any_Type;
+  end Get_Component_Type;
+
+   begin
+  if not Is_Composite_Type (Typ) then
+ Error_Msg_N ("not a composite type", N);
+  end if;
+
+  Analyze_And_Resolve (Base, Typ);
+  if Is_Array_Type (Typ) then
+ Index_Type := Etype (First_Index (Typ));
+ Assoc := First (Deltas);
+ while Present (Assoc) loop
+if Nkind (Assoc) = N_Iterated_Component_Association 

[PATCH][wwwdocs] Mention new store merging pass for GCC 7

[Kyrill Tkachov]

Hi all,

This patch adds a short entry for the store merging pass in GCC 7 to the "General 
Optimizer Improvements" section.

Eyeballed the result in Firefox.

Ok to commit?

Thanks,
Kyrill
Index: htdocs/gcc-7/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-7/changes.html,v
retrieving revision 1.39
diff -U 3 -r1.39 changes.html
--- htdocs/gcc-7/changes.html	17 Jan 2017 21:26:31 -	1.39
+++ htdocs/gcc-7/changes.html	20 Jan 2017 12:10:17 -
@@ -40,11 +40,14 @@
 
 
 General Optimizer Improvements
-
 
 
 New Languages and Language specific improvements

Re: [PATCH] Delete GCJ

[Per Bothner]

On 01/23/2017 01:05 AM, Jakub Jelinek wrote:

On Mon, Jan 23, 2017 at 09:01:24AM +, Andrew Haley wrote:

On 22/01/17 18:41, Per Bothner wrote:

In my opinion, all/most of these should be restored.


Because of the historical interest?  That's a good point, and perhaps
I was too hasty.  Sorry.


But then it should be probably moved somewhere where Gerald won't have to
spent time maintaining those pages (verification of URLs in there, updating
them when they are moved etc.).


The last part is moot, as we should strive to not move pages and thus break 
links.
--
--Per Bothner
p...@bothner.com   http://per.bothner.com/

[PATCH] Fix PR79186

[Richard Biener]

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

Richard.

2017-01-23  Richard Biener  

PR tree-optimization/79186
* tree-vrp.c (register_new_assert_for): Make sure we've seen
both incoming edges before moving an assert.

* gcc.dg/torture/pr79186.c: New testcase.
* gcc.dg/torture/pr79187.c: Likewise.

Index: gcc/tree-vrp.c
===
--- gcc/tree-vrp.c  (revision 244771)
+++ gcc/tree-vrp.c  (working copy)
@@ -5035,6 +5035,7 @@ register_new_assert_for (tree name, tree
  /* If we have the same assertion on all incoming edges of a BB
 instead insert it at the beginning of it.  */
  if (e && loc->e
+ && e != loc->e
  && dest_bb == loc->e->dest
  && EDGE_COUNT (dest_bb->preds) == 2)
{
Index: gcc/testsuite/gcc.dg/torture/pr79186.c
===
--- gcc/testsuite/gcc.dg/torture/pr79186.c  (nonexistent)
+++ gcc/testsuite/gcc.dg/torture/pr79186.c  (working copy)
@@ -0,0 +1,16 @@
+/* { dg-do run } */
+
+int a, b;
+unsigned char c, d, e;
+
+int main ()
+{ 
+  if (b || !a)
+{ 
+  c = a;
+  if (!c && !a)
+   d = 0;
+  e = -a;
+}
+  return 0;
+}
Index: gcc/testsuite/gcc.dg/torture/pr79187.c
===
--- gcc/testsuite/gcc.dg/torture/pr79187.c  (nonexistent)
+++ gcc/testsuite/gcc.dg/torture/pr79187.c  (working copy)
@@ -0,0 +1,19 @@
+/* { dg-do run } */
+
+int printf (const char *, ...);
+
+int a, b = -600, c, d[] = { 0 }, e, f, g = -1, h;
+unsigned i = ~0;
+
+int main ()
+{
+  for (; h < 2; h++)
+{
+  if (a > 0)
+   printf ("%d\n", d[b]);
+  f = ~(b % i);
+  c = g | (f && g) && e | b;
+  a = ~(~g & b);
+}
+  return 0; 
+}

Re: [PATCH] BRIG frontend: request for a global review

[Richard Biener]

On Mon, Jan 23, 2017 at 1:02 PM, Martin Jambor  wrote:
> Hi,
>
>
> On Mon, Jan 23, 2017 at 12:56:13PM +0100, Richard Biener wrote:
>> On Fri, Jan 20, 2017 at 6:25 PM, Pekka Jääskeläinen  
>> wrote:
>> > Hi Richard,
>> >
>> > On Fri, Jan 20, 2017 at 10:26 AM, Richard Biener
>> >  wrote:
>> >> So the #ifdef ENABLE_BRIG_FE shouldn't be needed anymore (nor the
>> >> configury for it).
>> >>
>> >> Otherwise this looks ok to me then.
>> >
>> > Attached is a patch set with that unnecessary ENABLE_BRIG_FE macro
>> > removed.  It has also been refreshed to the latest trunk.
>>
>> Are you set up to commit these to trunk yourself or do you need help here?
>>
>
> Pekka is still in the process of requesting an account at gcc.gnu.org.
> We agreed that I would commit the patches.
>
> Over Saturday and today morning, I have bootstrappet and tested them
> in various configurations (although mostly on x86_64 and only a little
> bit on aarch64) and (together with a "svn mv libgomp/plugin/hsa.h
> include/") I have not found any issue so far.
>
> I suppose I should go ahead (in any case, if there is any fallout,
> reach out to me too, at least until Pekka gets his account).

Yes, sounds good to me.

Richard.

> Thanks,
>
> Martin
>

[PATCH] Fix PR79088/79188

[Richard Biener]

The following is a fix for jump-threading loop-assumption clearing
which was done only on the first header/irreducible crossing rather
than the one at the destination of the threading path.

Bootstrapped and tested on x86_64-unknown-linux-gnu, ok for trunk?

Thanks,
Richard.

2017-01-23  Richard Biener  

PR tree-optimization/79088
PR tree-optimization/79188
* tree-ssa-threadupdate.c (mark_threaded_blocks): Move code
resetting loop bounds after last path deletion.  Reset loop
bounds of the target loop, make code match the comments.
* tree-ssa-threadbackwards.c (pass_early_thread_jumps::execute):
Make sure loops need no fixups.

* gcc.dg/torture/pr79088.c: New testcase.
* gcc.dg/torture/pr79188.c: Likewise.

Index: gcc/tree-ssa-threadupdate.c
===
--- gcc/tree-ssa-threadupdate.c (revision 244771)
+++ gcc/tree-ssa-threadupdate.c (working copy)
@@ -2086,42 +2086,6 @@ mark_threaded_blocks (bitmap threaded_bl
   else
 bitmap_copy (threaded_blocks, tmp);
 
-  /* Look for jump threading paths which cross multiple loop headers.
-
- The code to thread through loop headers will change the CFG in ways
- that invalidate the cached loop iteration information.  So we must
- detect that case and wipe the cached information.  */
-  EXECUTE_IF_SET_IN_BITMAP (tmp, 0, i, bi)
-{
-  basic_block bb = BASIC_BLOCK_FOR_FN (cfun, i);
-  FOR_EACH_EDGE (e, ei, bb->preds)
-   {
- if (e->aux)
-   {
- vec *path = THREAD_PATH (e);
-
- for (unsigned int i = 0, crossed_headers = 0;
-  i < path->length ();
-  i++)
-   {
- basic_block dest = (*path)[i]->e->dest;
- basic_block src = (*path)[i]->e->src;
- crossed_headers += (dest == dest->loop_father->header);
- /* If we step from a block outside an irreducible region
-to a block inside an irreducible region, then we have
-crossed into a loop.  */
- crossed_headers += ((src->flags & BB_IRREDUCIBLE_LOOP)
- != (dest->flags & BB_IRREDUCIBLE_LOOP));
- if (crossed_headers > 1)
-   {
- vect_free_loop_info_assumptions (dest->loop_father);
- break;
-   }
-   }
-   }
-   }
-}
-
   /* If we have a joiner block (J) which has two successors S1 and S2 and
  we are threading though S1 and the final destination of the thread
  is S2, then we must verify that any PHI nodes in S2 have the same
@@ -2163,6 +2127,46 @@ mark_threaded_blocks (bitmap threaded_bl
}
}
}
+   }
+}
+
+  /* Look for jump threading paths which cross multiple loop headers.
+
+ The code to thread through loop headers will change the CFG in ways
+ that invalidate the cached loop iteration information.  So we must
+ detect that case and wipe the cached information.  */
+  EXECUTE_IF_SET_IN_BITMAP (tmp, 0, i, bi)
+{
+  basic_block bb = BASIC_BLOCK_FOR_FN (cfun, i);
+  FOR_EACH_EDGE (e, ei, bb->preds)
+   {
+ if (e->aux)
+   {
+ vec *path = THREAD_PATH (e);
+
+ for (unsigned int i = 0, crossed_headers = 0;
+  i < path->length ();
+  i++)
+   {
+ basic_block dest = (*path)[i]->e->dest;
+ basic_block src = (*path)[i]->e->src;
+ /* If we enter a loop.  */
+ if (flow_loop_nested_p (src->loop_father, dest->loop_father))
+   ++crossed_headers;
+ /* If we step from a block outside an irreducible region
+to a block inside an irreducible region, then we have
+crossed into a loop.  */
+ else if (! (src->flags & BB_IRREDUCIBLE_LOOP)
+  && (dest->flags & BB_IRREDUCIBLE_LOOP))
+ ++crossed_headers;
+ if (crossed_headers > 1)
+   {
+ vect_free_loop_info_assumptions
+   ((*path)[path->length () - 1]->e->dest->loop_father);
+ break;
+   }
+   }
+   }
}
 }
 
Index: gcc/tree-ssa-threadbackward.c
===
--- gcc/tree-ssa-threadbackward.c   (revision 244771)
+++ gcc/tree-ssa-threadbackward.c   (working copy)
@@ -865,6 +865,8 @@ pass_early_thread_jumps::gate (function
 unsigned int
 pass_early_thread_jumps::execute (function *fun)
 {
+  loop_optimizer_init (AVOID_CFG_MODIFICATIONS);
+
   /* Try to thread each block with more than one successor.  */
   basic_block bb;
   FOR_EACH_BB_FN

[Ada] Crash on illegally terminated extended return statement

[Arnaud Charlet]

This patch modifies the construct scope stack of the parser to ensure that an
extended return statement cannot have an optional end label.


-- Source --


--  main.adb

function Main return Boolean is
begin
   return Result : Boolean do
  null;
   end loop;
end Main;


-- Compilation and output --


$ gcc -c main.adb
main.adb:5:04: "end return;" expected for "return" at line 3

Tested on x86_64-pc-linux-gnu, committed on trunk

2017-01-23  Hristian Kirtchev  

* par.adb: Update the documentation of component Labl.
* par-ch6.adb (P_Return_Statement): Set the expected label of
an extended return statement to Error.

Index: par.adb
===
--- par.adb (revision 244773)
+++ par.adb (working copy)
@@ -476,8 +476,8 @@
   --  subprogram specifications and bodies the field holds the correponding
   --  program unit name. For task declarations and bodies, protected types
   --  and bodies, and accept statements the field hold the name of the type
-  --  or operation. For if-statements, case-statements, and selects, the
-  --  field is initialized to Error.
+  --  or operation. For if-statements, case-statements, return statements,
+  --  and selects, the field is initialized to Error.
 
   --  Note: this is a bit of an odd (mis)use of Error, since there is no
   --  Error, but we use this value as a place holder to indicate that it
Index: par-ch6.adb
===
--- par-ch6.adb (revision 244773)
+++ par-ch6.adb (working copy)
@@ -1909,8 +1909,9 @@
 
 if Token = Tok_Do then
Push_Scope_Stack;
+   Scope.Table (Scope.Last).Ecol := Ret_Strt;
Scope.Table (Scope.Last).Etyp := E_Return;
-   Scope.Table (Scope.Last).Ecol := Ret_Strt;
+   Scope.Table (Scope.Last).Labl := Error;
Scope.Table (Scope.Last).Sloc := Ret_Sloc;
 
Scan; -- past DO

[Ada] Aliasing checks on subprograms may cause side effects

[Arnaud Charlet]

Compiling with aliasing checks on subprograms parameters (-gnateA),
if the actual of a subprogram parameter is a function call the
compiler may generate a runtime check that invokes the function
more than once.

After this patch the following test compiles and executes well.

with Ada.Text_IO; use Ada.Text_IO;
procedure Do_Test is
   Call_Counter : Natural := 0;

   function Get_Value return String is
   begin
  Call_Counter := Call_Counter + 1;

  if Call_Counter = 1 then
 return "OK";
  else
 return "Failure";
  end if;
   end Get_Value;

   procedure Do_Test (S1 : String; S2 : in out String) is
   begin
  Put_Line (S1);
   end Do_Test;
 
   Dummy : String := ":";
begin
   Do_Test (Get_Value, Dummy);
end;

Command: gnatmake -gnateA do_test.adb; ./do_test
 Output: OK

Tested on x86_64-pc-linux-gnu, committed on trunk

2017-01-23  Javier Miranda  

* checks.adb (Apply_Parameter_Aliasing_Checks):
Remove side effects of the actuals before generating the overlap
check.

Index: checks.adb
===
--- checks.adb  (revision 244792)
+++ checks.adb  (working copy)
@@ -2360,6 +2360,9 @@
  and then not Is_Elementary_Type (Etype (Orig_Act_2))
  and then May_Cause_Aliasing (Formal_1, Formal_2)
then
+  Remove_Side_Effects (Actual_1);
+  Remove_Side_Effects (Actual_2);
+
   Overlap_Check
 (Actual_1 => Actual_1,
  Actual_2 => Actual_2,

[Ada] Wrong dispatching call through class-wide interface subtype

[Arnaud Charlet]

When the type of the controlling formal of a dispatching call is an
interface subtype the compiler can generate code that dispatch to
the wrong operation or crash the program.

After this patch the following test compiles and executes well.

package Small_Types is
   type I_Dummy is limited interface;
   procedure Dummy (Obj : I_Dummy) is abstract;

   type I_Writable is limited interface;
   procedure Write (Obj : I_Writable) is abstract;

   type I_Whole is limited interface and I_Dummy and I_Writable;
end;

with Small_Types; use Small_Types;
package Small_Tests is
   type T_Whole is new Small_Types.I_Whole with null record;
   procedure Dummy (Stream : T_Whole);
   procedure Write (Stream : T_Whole);

   procedure Run;
end;

with Ada.Text_IO; use Ada.Text_IO;
package body Small_Tests is
   procedure Write (Stream : T_Whole) is
   begin
  Put_Line ("OK");
   end;

   procedure Dummy (Stream : T_Whole) is
   begin
  Put_Line ("Wrong");
  raise Program_Error;
   end;

   procedure Test_1 (Obj : I_Writable'Class) is
   begin
  Obj.Write;  -- OK
   end;

   subtype T_Writable_Class is I_Writable'Class;

   procedure Test_2 (Obj : T_Writable_Class) is
   begin
  Obj.Write;  -- Wrong
   end;

   procedure Run is
  Obj : T_Whole;
   begin
  Put ("Test 1  "); Test_1 (Obj);
  Put ("Test 2  "); Test_2 (Obj);
   end;
end;

with Small_Tests;
procedure Small_Main is
begin
   Small_Tests.Run;
end;

Command: gnatmake small_main.adb; ./small_main
 Output:
Test 1  OK
Test 2  OK

Tested on x86_64-pc-linux-gnu, committed on trunk

2017-01-23  Javier Miranda  

* exp_ch6.adb (Expand_Call): Improve the code that
checks if some formal of the called subprogram is a class-wide
interface, to handle subtypes of class-wide interfaces.

Index: exp_ch6.adb
===
--- exp_ch6.adb (revision 244789)
+++ exp_ch6.adb (working copy)
@@ -2832,10 +2832,12 @@
  CW_Interface_Formals_Present :=
CW_Interface_Formals_Present
  or else
-   (Ekind (Etype (Formal)) = E_Class_Wide_Type
+   (Is_Class_Wide_Type (Etype (Formal))
  and then Is_Interface (Etype (Etype (Formal
  or else
(Ekind (Etype (Formal)) = E_Anonymous_Access_Type
+ and then Is_Class_Wide_Type (Directly_Designated_Type
+   (Etype (Etype (Formal
  and then Is_Interface (Directly_Designated_Type
  (Etype (Etype (Formal);
 

Fix PR78384: ICE in loop splitting

[Michael Matz]

Hi,

the loop structure in the testcase is funny enough to confuse loop 
splitting (it essentially would have been an irreducable region if it 
weren't for the fact that one entry edge is stopped with a builtin_trap; 
and so it transforms into a strangely rotated loop where latch and header 
aren't at the usual position).  We need to compute the edge staying in the 
loop given the exit edge, which I was doing by looking at predecessor 
edges of the latch, and that wasn't working with the testcase.  Of course 
there's an easier way: it's simply the edge out of exit->src that isn't 
exit itself :)

So, patch fixes the testcase.  Regstrapped on x86-64-linux with all 
languages+Ada, no regressions.  Okay for trunk?


Ciao,
Michael.

PR tree-optimization/78384
* tree-ssa-loop-split.c (patch_loop_exit): Use correct edge.

testsuite/
PR tree-optimization/78384
* gcc.dg/pr78384.c: New test.

diff --git a/gcc/tree-ssa-loop-split.c b/gcc/tree-ssa-loop-split.c
index 7809db0..f104b26 100644
--- a/gcc/tree-ssa-loop-split.c
+++ b/gcc/tree-ssa-loop-split.c
@@ -159,7 +159,7 @@ patch_loop_exit (struct loop *loop, gcond *guard, tree 
nextval, tree newbound,
 nextval, newbound);
   update_stmt (stmt);
 
-  edge stay = single_pred_edge (loop->latch);
+  edge stay = EDGE_SUCC (exit->src, EDGE_SUCC (exit->src, 0) == exit);
 
   exit->flags &= ~(EDGE_TRUE_VALUE | EDGE_FALSE_VALUE);
   stay->flags &= ~(EDGE_TRUE_VALUE | EDGE_FALSE_VALUE);
diff --git a/gcc/testsuite/gcc.dg/pr78384.c b/gcc/testsuite/gcc.dg/pr78384.c
new file mode 100644
index 000..d93437d
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr78384.c
@@ -0,0 +1,25 @@
+/* PR tree-optimization/78384
+   { dg-do compile }
+   { dg-options "-O3 -w -fsplit-loops" } */
+void
+a2 (int wv, int yg, int r9)
+{
+  while (wv < 1)
+{
+  int vn = r9 % 0;
+
+  while (yg < 1)
+{
+  int lz;
+
+  for (r9 = 0; r9 < 17; ++r9)
+{
+}
+
+ it:
+  lz = (yg++ >= 0) ? 2 : 0;
+  wv = vn < lz;
+}
+}
+  goto it;
+}

Re: [PATCH] Delete GCJ

[Jakub Jelinek]

On Mon, Jan 23, 2017 at 04:51:44AM -0800, Per Bothner wrote:
> On 01/23/2017 01:05 AM, Jakub Jelinek wrote:
> > On Mon, Jan 23, 2017 at 09:01:24AM +, Andrew Haley wrote:
> > > On 22/01/17 18:41, Per Bothner wrote:
> > > > In my opinion, all/most of these should be restored.
> > > 
> > > Because of the historical interest?  That's a good point, and perhaps
> > > I was too hasty.  Sorry.
> > 
> > But then it should be probably moved somewhere where Gerald won't have to
> > spent time maintaining those pages (verification of URLs in there, updating
> > them when they are moved etc.).
> 
> The last part is moot, as we should strive to not move pages and thus break 
> links.

I meant updating URLs in the pages when they refer to external web pages
which move over time (or switch from http to https, or disappear, etc.).  Gerald
does a great job handling that, but if there are too many pages for
historical purpose only, it will make his work harder.

Jakub

[C++ PATCH] 79118 bitfields & constexpr

[Nathan Sidwell]

This patch addresses 79118, where we ICE on a constexpr involving 
bitfields in an unnamed struct (unnamed struct members are a g++ extension).


This is really a band-aid, because our internal representation 
BITFIELD_REF and the (premature) optimizations it encourages is 
incompatible with constexpr requirements.  There's already signs of that 
with Jakub's code to deal with fold turning things like:

  int foo: 5;
  int baz: 3;
...
  ptr->baz == cst
turns into the moral equivalent of (little endian example)
  ((*(unsigned char *)ptr & 0xe0) == (cst << 5)

In this particular case we've also made the base object the containing 
class, not the unnamed struct member.  That means we're looking in the 
wrong CONSTRUCTOR and see CONSTRUCTOR_NO_IMPLICIT_ZERO is true.  Whereas 
for the subobj's CONSTRUCTOR it is false.  With this patch we end up 
thinking this is an OK constexpr of value zero, whereas it's actually an 
uninitialized bitfield read.


But I think we could already make that mistake given the above example & 
fold's behaviour.  If 'ptr->foo' has been initialized, we'll construct a 
value using just that field and think we have a valid initialization of 
ptr->baz too.


The equivalent testcase using non-bitfields has a base object of the 
unnamed struct member, and behaves correctly (given this is an extension 
anyway).


The right solution is to fix the IR.  In the C++ FE have BITFIELD_REF 
(or a new node) look much more like COMPONENT_REF (or even be 
COMPONENT_REF, but I suspect lots of places think ADDR (COMPONENT_REF 
(...)) is legit).  And lower it to the middle-end generic representation 
in cp_genericize.  I don't think this is the right time for a change of 
that magnitude though.


Perhaps for now we should just always err on the side of safety, and 
behave as-if uninitialized if we fall of the end of looking for a bitfield?


thoughts?

nathan
--
Nathan Sidwell
2017-01-23  Nathan Sidwell  

	PR c++/79118 - bitfields and constexpr
	* constexpr.c (cxx_eval_bitfield): Return zero or set non-constant
	if no bitfield found.

	PR c++/79118
	* g++.dg/cpp0x/pr79118.C: New.

Index: cp/constexpr.c
===
--- cp/constexpr.c	(revision 244728)
+++ cp/constexpr.c	(working copy)
@@ -2447,6 +2447,11 @@ cxx_eval_bit_field_ref (const constexpr_
   tree bitpos = bit_position (field);
   if (bitpos == start && DECL_SIZE (field) == TREE_OPERAND (t, 1))
 	return value;
+
+  /* fold likes to change bitfield accesses into byte-friendly
+	 sizes and adding explicit masking. If this field is within
+	 the range of bits being extracted, accumulate into
+	 retval.  */
   if (TREE_CODE (TREE_TYPE (field)) == INTEGER_TYPE
 	  && TREE_CODE (value) == INTEGER_CST
 	  && tree_fits_shwi_p (bitpos)
@@ -2476,8 +2481,31 @@ cxx_eval_bit_field_ref (const constexpr_
 }
   if (fld_seen)
 return fold_convert (TREE_TYPE (t), retval);
-  gcc_unreachable ();
-  return error_mark_node;
+
+  if (CONSTRUCTOR_NO_IMPLICIT_ZERO (whole))
+{
+  if (!ctx->quiet)
+	{
+	  /* Find the bitfield for a useful error message.  */
+	  for (field = TYPE_FIELDS (TREE_TYPE (TREE_OPERAND (t, 0)));
+	   field; field = TREE_CHAIN (field))
+	if (TREE_CODE (field) == FIELD_DECL
+		&& DECL_SIZE (field) == TREE_OPERAND (t, 1)
+		&& bit_position (field) == start)
+	  break;
+	  if (field)
+	error ("accessing uninitialized bitfield %qD", field);
+	  else
+	error ("accessing uninitialized bitfield");
+	}
+  *non_constant_p = true;
+  return t;
+}
+
+  /* If there's no explicit init for this field, it's value-initialized.  */
+  value = build_value_init (TREE_TYPE (t), tf_warning_or_error);
+  return cxx_eval_constant_expression (ctx, value, lval,
+   non_constant_p, overflow_p);
 }
 
 /* Subroutine of cxx_eval_constant_expression.
Index: testsuite/g++.dg/cpp0x/pr79118.C
===
--- testsuite/g++.dg/cpp0x/pr79118.C	(revision 0)
+++ testsuite/g++.dg/cpp0x/pr79118.C	(working copy)
@@ -0,0 +1,19 @@
+// { dg-do compile { target c++11 } }
+// { dg-options "-std=c++11" }
+// PR c++/79118 ICE with uninitialized bit field
+
+struct Impl {
+  struct {
+char raw;
+char type : 2;
+  };
+
+  constexpr Impl () : raw () {}
+
+  constexpr bool get () { return type; }
+};
+
+void Foo ()
+{
+  !Impl().get();
+}

Re: [PR c++/78469] default ctor makes dtor required

[Nathan Sidwell]

ping?

On 01/18/2017 01:25 PM, Nathan Sidwell wrote:

Jason,
I've figured out what's happening here.  Just not sure of the most
prudent way to fix it.

struct no_destr {
  no_destr() = default;

protected:
  ~no_destr() = default;
};

void *Foo ()
{
  return new no_destr ();
}

no_destr is a type for which the default ctor is not DECL_ARTIFICIAL,
but is_trivial is true.  type_build_ctor_call returns true because of that.

After parsing 'no_destr ()' part of the new expr, we're inside
build_new_1, which because it's an explicit_value_init, we end up doing:
/* Something like `new int()'.  */
  tree val = build_value_init (type, complain);

build_value_init ends up in build_over_call at:
 else if (!DECL_DELETED_FN (fn)
   && trivial_fn_p (fn))
{
  ...
  else if (default_ctor_p (fn))
{
  if (is_dummy_object (argarray[0]))
return force_target_expr (DECL_CONTEXT (fn), void_node, complain);

and force_target_expr ends up (via build_target_expr) with trying to
build a clean up for the object.  Poof!

We need to tell that force_target_expr to not create a cleanup. Choices are
1) augment tf_subst flags to add such a flag. (somewhat icky, but simple)
2) a new force_target_expr_nocleanup routine, wrapping things
appropriately.

thoughts?

nathan



--
Nathan Sidwell

Re: Fix PR78384: ICE in loop splitting

[Richard Biener]

On Mon, Jan 23, 2017 at 2:38 PM, Michael Matz  wrote:
> Hi,
>
> the loop structure in the testcase is funny enough to confuse loop
> splitting (it essentially would have been an irreducable region if it
> weren't for the fact that one entry edge is stopped with a builtin_trap;
> and so it transforms into a strangely rotated loop where latch and header
> aren't at the usual position).  We need to compute the edge staying in the
> loop given the exit edge, which I was doing by looking at predecessor
> edges of the latch, and that wasn't working with the testcase.  Of course
> there's an easier way: it's simply the edge out of exit->src that isn't
> exit itself :)
>
> So, patch fixes the testcase.  Regstrapped on x86-64-linux with all
> languages+Ada, no regressions.  Okay for trunk?

Ok.

Richard.

>
> Ciao,
> Michael.
>
> PR tree-optimization/78384
> * tree-ssa-loop-split.c (patch_loop_exit): Use correct edge.
>
> testsuite/
> PR tree-optimization/78384
> * gcc.dg/pr78384.c: New test.
>
> diff --git a/gcc/tree-ssa-loop-split.c b/gcc/tree-ssa-loop-split.c
> index 7809db0..f104b26 100644
> --- a/gcc/tree-ssa-loop-split.c
> +++ b/gcc/tree-ssa-loop-split.c
> @@ -159,7 +159,7 @@ patch_loop_exit (struct loop *loop, gcond *guard, tree 
> nextval, tree newbound,
>  nextval, newbound);
>update_stmt (stmt);
>
> -  edge stay = single_pred_edge (loop->latch);
> +  edge stay = EDGE_SUCC (exit->src, EDGE_SUCC (exit->src, 0) == exit);
>
>exit->flags &= ~(EDGE_TRUE_VALUE | EDGE_FALSE_VALUE);
>stay->flags &= ~(EDGE_TRUE_VALUE | EDGE_FALSE_VALUE);
> diff --git a/gcc/testsuite/gcc.dg/pr78384.c b/gcc/testsuite/gcc.dg/pr78384.c
> new file mode 100644
> index 000..d93437d
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/pr78384.c
> @@ -0,0 +1,25 @@
> +/* PR tree-optimization/78384
> +   { dg-do compile }
> +   { dg-options "-O3 -w -fsplit-loops" } */
> +void
> +a2 (int wv, int yg, int r9)
> +{
> +  while (wv < 1)
> +{
> +  int vn = r9 % 0;
> +
> +  while (yg < 1)
> +{
> +  int lz;
> +
> +  for (r9 = 0; r9 < 17; ++r9)
> +{
> +}
> +
> + it:
> +  lz = (yg++ >= 0) ? 2 : 0;
> +  wv = vn < lz;
> +}
> +}
> +  goto it;
> +}

[PATCH] Fix strstr folding (PR tree-optimization/79196).

[Martin Liška]

As mentioned in the PR, it should be valid to use strncmp instead of memcmp
because first argument of a strstr can be shorter than a second (known) 
argument.

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

Ready to be installed?
Martin
>From 4a9dcb24d82ce1793a281710ce1ddab59f9dd7a8 Mon Sep 17 00:00:00 2001
From: marxin 
Date: Mon, 23 Jan 2017 13:18:37 +0100
Subject: [PATCH] Fix strstr folding (PR tree-optimization/79196).

gcc/ChangeLog:

2017-01-23  Martin Liska  

	* tree-ssa-strlen.c (fold_strstr_to_memcmp): Rename
	to fold_strstr_to_strncmp and fold the pattern to strncmp
	instead of memcmp.
	(strlen_optimize_stmt): Call the renamed function.

gcc/testsuite/ChangeLog:

2017-01-23  Martin Liska  

	* gcc.dg/asan/pr79196.c: New test.
	* gcc.dg/strlenopt-30.c: Update scanned pattern.
---
 gcc/testsuite/gcc.dg/asan/pr79196.c | 17 +
 gcc/testsuite/gcc.dg/strlenopt-30.c |  2 +-
 gcc/tree-ssa-strlen.c   | 36 ++--
 3 files changed, 36 insertions(+), 19 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/asan/pr79196.c

diff --git a/gcc/testsuite/gcc.dg/asan/pr79196.c b/gcc/testsuite/gcc.dg/asan/pr79196.c
new file mode 100644
index 000..66a31b90f30
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/asan/pr79196.c
@@ -0,0 +1,17 @@
+// PR tree-optimization/79196
+// { dg-do run }
+
+int
+__attribute__((noinline))
+test(char *a)
+{
+  if (__builtin_strstr (a, "DROP CONVERSION") == a)
+return 1;
+
+  return 0;
+}
+
+int main(int argc, char **argv)
+{
+  return test ("x");
+}
diff --git a/gcc/testsuite/gcc.dg/strlenopt-30.c b/gcc/testsuite/gcc.dg/strlenopt-30.c
index 089b3a2341d..a85df686ce2 100644
--- a/gcc/testsuite/gcc.dg/strlenopt-30.c
+++ b/gcc/testsuite/gcc.dg/strlenopt-30.c
@@ -60,4 +60,4 @@ _Bool f7(char *s)
   return (t1 == s);
 }
 
-/* { dg-final { scan-tree-dump-times "__builtin_memcmp" 5 "strlen" } } */
+/* { dg-final { scan-tree-dump-times "__builtin_strncmp" 5 "strlen" } } */
diff --git a/gcc/tree-ssa-strlen.c b/gcc/tree-ssa-strlen.c
index 2e7ac2c7786..141115ed12b 100644
--- a/gcc/tree-ssa-strlen.c
+++ b/gcc/tree-ssa-strlen.c
@@ -2225,10 +2225,10 @@ handle_char_store (gimple_stmt_iterator *gsi)
   return true;
 }
 
-/* Try to fold strstr (s, t) eq/ne s to memcmp (s, t, strlen (t)) eq/ne 0.  */
+/* Try to fold strstr (s, t) eq/ne s to strncmp (s, t, strlen (t)) eq/ne 0.  */
 
 static void
-fold_strstr_to_memcmp (tree rhs1, tree rhs2, gimple *stmt)
+fold_strstr_to_strncmp (tree rhs1, tree rhs2, gimple *stmt)
 {
   if (TREE_CODE (rhs1) != SSA_NAME
   || TREE_CODE (rhs2) != SSA_NAME)
@@ -2273,34 +2273,34 @@ fold_strstr_to_memcmp (tree rhs1, tree rhs2, gimple *stmt)
 	  if (arg1_len != NULL_TREE)
 	{
 	  gimple_stmt_iterator gsi = gsi_for_stmt (call_stmt);
-	  tree memcmp_decl = builtin_decl_explicit (BUILT_IN_MEMCMP);
-	  gcall *memcmp_call = gimple_build_call (memcmp_decl, 3,
+	  tree strncmp_decl = builtin_decl_explicit (BUILT_IN_STRNCMP);
+	  gcall *strncmp_call = gimple_build_call (strncmp_decl, 3,
 		  arg0, arg1, arg1_len);
-	  tree memcmp_lhs = make_ssa_name (integer_type_node);
-	  gimple_set_vuse (memcmp_call, gimple_vuse (call_stmt));
-	  gimple_call_set_lhs (memcmp_call, memcmp_lhs);
+	  tree strncmp_lhs = make_ssa_name (integer_type_node);
+	  gimple_set_vuse (strncmp_call, gimple_vuse (call_stmt));
+	  gimple_call_set_lhs (strncmp_call, strncmp_lhs);
 	  gsi_remove (&gsi, true);
-	  gsi_insert_before (&gsi, memcmp_call, GSI_SAME_STMT);
-	  tree zero = build_zero_cst (TREE_TYPE (memcmp_lhs));
+	  gsi_insert_before (&gsi, strncmp_call, GSI_SAME_STMT);
+	  tree zero = build_zero_cst (TREE_TYPE (strncmp_lhs));
 
 	  if (is_gimple_assign (stmt))
 		{
 		  if (gimple_assign_rhs_code (stmt) == COND_EXPR)
 		{
 		  tree cond = gimple_assign_rhs1 (stmt);
-		  TREE_OPERAND (cond, 0) = memcmp_lhs;
+		  TREE_OPERAND (cond, 0) = strncmp_lhs;
 		  TREE_OPERAND (cond, 1) = zero;
 		}
 		  else
 		{
-		  gimple_assign_set_rhs1 (stmt, memcmp_lhs);
+		  gimple_assign_set_rhs1 (stmt, strncmp_lhs);
 		  gimple_assign_set_rhs2 (stmt, zero);
 		}
 		}
 	  else
 		{
 		  gcond *cond = as_a (stmt);
-		  gimple_cond_set_lhs (cond, memcmp_lhs);
+		  gimple_cond_set_lhs (cond, strncmp_lhs);
 		  gimple_cond_set_rhs (cond, zero);
 		}
 	  update_stmt (stmt);
@@ -2398,12 +2398,12 @@ strlen_optimize_stmt (gimple_stmt_iterator *gsi)
 	enum tree_code cond_code = TREE_CODE (cond);
 
 	if (cond_code == EQ_EXPR || cond_code == NE_EXPR)
-	  fold_strstr_to_memcmp (TREE_OPERAND (cond, 0),
- TREE_OPERAND (cond, 1), stmt);
+	  fold_strstr_to_strncmp (TREE_OPERAND (cond, 0),
+  TREE_OPERAND (cond, 1), stmt);
 	  }
 	else if (code == EQ_EXPR || code == NE_EXPR)
-	  fold_strstr_to_memcmp (gimple_assign_rhs1 (stmt),
- gimple_assign_rhs2 (stmt), stmt);
+	  fold_strstr_to_strnc

Re: [PATCH v5] add -fprolog-pad=N,M option

[Torsten Duwe]

And what's next now?

Maxim mentioned in this thread you should sort of formally approve(?)
a global feature, have you had a look at it yet?

I should emphasize that this code can substitute the -fentry for arm64 for
the purpose of kernel live patching that was discussed in the beginning,
as well as for some other architectures, plus the yet-to-be-discovered use
cases as a general instrumentation. In other words, it could save some work
in the future :-)

Torsten

Re: [PATCH] Fix strstr folding (PR tree-optimization/79196).

[Jakub Jelinek]

On Mon, Jan 23, 2017 at 02:58:05PM +0100, Martin Liška wrote:
> As mentioned in the PR, it should be valid to use strncmp instead of memcmp
> because first argument of a strstr can be shorter than a second (known) 
> argument.
> 
> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
> 
> Ready to be installed?
> Martin

> >From 4a9dcb24d82ce1793a281710ce1ddab59f9dd7a8 Mon Sep 17 00:00:00 2001
> From: marxin 
> Date: Mon, 23 Jan 2017 13:18:37 +0100
> Subject: [PATCH] Fix strstr folding (PR tree-optimization/79196).
> 
> gcc/ChangeLog:
> 
> 2017-01-23  Martin Liska  
> 
>   * tree-ssa-strlen.c (fold_strstr_to_memcmp): Rename
>   to fold_strstr_to_strncmp and fold the pattern to strncmp
>   instead of memcmp.

Please write it as:
PR tree-optimization/79196
* tree-ssa-strlen.c (fold_strstr_to_memcmp): Rename to ...
(fold_strstr_to_strncmp): ... this.  Fold the pattern to strncmp
instead of memcmp.

>   (strlen_optimize_stmt): Call the renamed function.
> 
> gcc/testsuite/ChangeLog:
> 
> 2017-01-23  Martin Liska  
> 
>   * gcc.dg/asan/pr79196.c: New test.
>   * gcc.dg/strlenopt-30.c: Update scanned pattern.

Ok, thanks.

Jakub

Re: [PATCH] Delete GCJ

[Andrew Haley]

On 23/01/17 13:41, Jakub Jelinek wrote:
> On Mon, Jan 23, 2017 at 04:51:44AM -0800, Per Bothner wrote:

>> The last part is moot, as we should strive to not move pages and thus break 
>> links.
> 
> I meant updating URLs in the pages when they refer to external web pages
> which move over time (or switch from http to https, or disappear, etc.).  
> Gerald
> does a great job handling that, but if there are too many pages for
> historical purpose only, it will make his work harder.

We can redirect to somewhere else.

Andrew.

Re: [Ada] Ada2020 feature: partial aggregate notation (Delta aggregates).

[Jakub Jelinek]

On Mon, Jan 23, 2017 at 07:07:40AM -0500, Arnaud Charlet wrote:
> This patch implements AI12-0127, which describes a new constructor for
> aggregate in terms of an existing record or array aggregate and a series
> of component-wise modifications of its value.

Please note that the trunk is in stage4, only regression bugfixes and
documentation fixes are allowed.  It is possible to seek exceptions,
but committing dozens of changes that do not fix regressions or
documentation is not desirable right now.

Jakub

Re: [PATCH][GCC][PATCHv3] Improve fpclassify w.r.t IEEE like numbers in GIMPLE.

[Tamar Christina]

Hi Jeff, Joseph,

Thank you for the reviews. This is hopefully the final version of the patch.

I was doing some extra testing on the FP fallback case
and noticed that the builtins Joseph told me about before were emitting GENERIC
and not GIMPLE code, particularly the TRUTH_NOT_EXPR expression was problematic.
So I've added calls to gimplify_expr and gimple_boolify where appropriate to do
the conversion.

In the testcase I've also had to remove `-funsafe-math-optimizations` because at
least on AArch64 this sets the LZ bit in the FPCR which causes the fcmp to
collapse small subnormal numbers to 0 and so iszero would fail.

With this both the FP and Integer versions have no regressions.

Ok for trunk?

Thanks,

Tamar.

gcc/
2017-01-23  Tamar Christina  

PR middle-end/77925
PR middle-end/77926
PR middle-end/66462

* gcc/builtins.c (fold_builtin_fpclassify): Removed.
(fold_builtin_interclass_mathfn): Removed.
(expand_builtin): Added builtins to lowering list.
(fold_builtin_n): Removed fold_builtin_varargs.
(fold_builtin_varargs): Removed.
* gcc/builtins.def (BUILT_IN_ISZERO, BUILT_IN_ISSUBNORMAL): Added.
* gcc/real.h (get_min_float): Added.
(real_format): Added is_ieee_compatible field.
* gcc/real.c (get_min_float): Added.
(ieee_single_format): Set is_ieee_compatible flag.
* gcc/gimple-low.c (lower_stm): Define BUILT_IN_FPCLASSIFY,
CASE_FLT_FN (BUILT_IN_ISINF), BUILT_IN_ISINFD32, BUILT_IN_ISINFD64,
BUILT_IN_ISINFD128, BUILT_IN_ISNAND32, BUILT_IN_ISNAND64,
BUILT_IN_ISNAND128, BUILT_IN_ISNAN, BUILT_IN_ISNORMAL, BUILT_IN_ISZERO,
BUILT_IN_ISSUBNORMAL, CASE_FLT_FN (BUILT_IN_FINITE), BUILT_IN_FINITED32
BUILT_IN_FINITED64, BUILT_IN_FINITED128, BUILT_IN_ISFINITE.
(lower_builtin_fpclassify, is_nan, is_normal, is_infinity): Added.
(is_zero, is_subnormal, is_finite, use_ieee_int_mode): Likewise.
(lower_builtin_isnan, lower_builtin_isinfinite): Likewise.
(lower_builtin_isnormal, lower_builtin_iszero): Likewise.
(lower_builtin_issubnormal, lower_builtin_isfinite): Likewise.
(emit_tree_cond, get_num_as_int, emit_tree_and_return_var): Added.
(mips_single_format): Likewise.
(motorola_single_format): Likewise.
(spu_single_format): Likewise.
(ieee_double_format): Likewise.
(mips_double_format): Likewise.
(motorola_double_format): Likewise.
(ieee_extended_motorola_format): Likewise.
(ieee_extended_intel_128_format): Likewise.
(ieee_extended_intel_96_round_53_format): Likewise.
(ibm_extended_format): Likewise.
(mips_extended_format): Likewise.
(ieee_quad_format): Likewise.
(mips_quad_format): Likewise.
(vax_f_format): Likewise.
(vax_d_format): Likewise.
(vax_g_format): Likewise.
(decimal_single_format): Likewise.
(decimal_quad_format): Likewise.
(iee_half_format): Likewise.
(mips_single_format): Likewise.
(arm_half_format): Likewise.
(real_internal_format): Likewise.
* gcc/doc/extend.texi: Added documentation for built-ins.
* gcc/c/c-typeck.c (convert_arguments): Added BUILT_IN_ISZERO
and BUILT_IN_ISSUBNORMAL.

gcc/testsuite/
2017-01-23  Tamar Christina  

* gcc.target/aarch64/builtin-fpclassify.c: New codegen test.
* gcc.dg/fold-notunord.c: Removed.
* gcc.dg/torture/floatn-tg-4.h: Added tests for iszero and issubnormal.
* gcc.dg/torture/float128-tg-4.c: Likewise.
* gcc.dg/torture/float128x-tg-4: Likewise.
* gcc.dg/torture/float16-tg-4.c: Likewise.
* gcc.dg/torture/float32-tg-4.c: Likewise.
* gcc.dg/torture/float32x-tg-4.c: Likewise.
* gcc.dg/torture/float64-tg-4.c: Likewise.
* gcc.dg/torture/float64x-tg-4.c: Likewise.
* gcc.dg/pr28796-1.c: Added -O2.
* gcc.dg/builtins-43.c: Check lower instead of gimple.
* gcc.dg/tg-tests.h: Added iszero and issubnormal.
* gcc.dg/pr28796-2.c: Dropped -funsafe-math-optimizations.

From: Joseph Myers 
Sent: Thursday, January 19, 2017 6:20:35 PM
To: Tamar Christina
Cc: Jeff Law; GCC Patches; Wilco Dijkstra; rguent...@suse.de; Michael Meissner; 
nd
Subject: Re: [PATCH][GCC][PATCHv3] Improve fpclassify w.r.t IEEE like numbers 
in GIMPLE.

On Thu, 19 Jan 2017, Tamar Christina wrote:

> Hi Joseph,
>
> I made the requested changes and did a quick pass over the rest
> of the fp cases.

I've no further comments, but watch out for any related test failures
being reported.

--
Joseph S. Myers
jos...@codesourcery.com
diff --git a/gcc/builtins.c b/gcc/builtins.c
index 3ac2d44148440b124559ba7cd3de483b7a74b72d..d8ff9c70ae6b9e72e09b8cbd9a0bd41b6830b83e 100644
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@ -160,7 +160,6 @@ static tree fold_builtin_0 (location_t, tree);
 st

[PATCH] PR libstdc++/79195 fix make_array type deduction

[Jonathan Wakely]

This adds indirection through a class template partial specialization
so we don't instantiate common_type<_Types...>::type unless we need
it.

PR libstdc++/79195
* include/experimental/array (__make_array_elem): New class template
and partial specialization.
(__is_reference_wrapper): Move into __make_array_elem specialization.
(make_array): Use __make_array_elem to determine element type and move
static assertion into specialization. Qualify std::forward call.
(to_array): Add exception specifiation.
* testsuite/experimental/array/make_array.cc: Test argument types
without a common type.
* testsuite/experimental/array/neg.cc: Adjust expected error message.

Tested powerpc64le-linux, committed to trunk (because it's only an
experimental TS feature).

commit 16438869aa70f6cad56c094ed26ac73dc75c3847
Author: Jonathan Wakely 
Date:   Mon Jan 23 15:15:07 2017 +

PR libstdc++/79195 fix make_array type deduction

PR libstdc++/79195
* include/experimental/array (__make_array_elem): New class template
and partial specialization.
(__is_reference_wrapper): Move into __make_array_elem specialization.
(make_array): Use __make_array_elem to determine element type and move
static assertion into specialization. Qualify std::forward call.
(to_array): Add exception specifiation.
* testsuite/experimental/array/make_array.cc: Test argument types
without a common type.
* testsuite/experimental/array/neg.cc: Adjust expected error message.

diff --git a/libstdc++-v3/include/experimental/array 
b/libstdc++-v3/include/experimental/array
index 5899486..11cb924 100644
--- a/libstdc++-v3/include/experimental/array
+++ b/libstdc++-v3/include/experimental/array
@@ -57,35 +57,40 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
* @{
*/
 
-template 
-  struct __is_reference_wrapper : false_type
-  {};
+template
+  struct __make_array_elem
+  {
+using type = _Dest;
+  };
 
-template 
-  struct __is_reference_wrapper> : true_type
-  {};
+template
+  struct __make_array_elem
+  : common_type<_Types...>
+  {
+template 
+  struct __is_reference_wrapper : false_type
+  {};
+
+template 
+  struct __is_reference_wrapper> : true_type
+  {};
+
+static_assert(!__or_<__is_reference_wrapper>...>::value,
+  "make_array must be used with an explicit target type when"
+  "any of the arguments is a reference_wrapper");
+  };
 
 template 
-  constexpr auto
+  constexpr
+  array::type, sizeof...(_Types)>
   make_array(_Types&&... __t)
--> array,
-   common_type_t<_Types...>,
-   _Dest>,
- sizeof...(_Types)>
   {
-static_assert(__or_<
-  __not_>,
-  __and_<__not_<__is_reference_wrapper>>...>>
-  ::value,
-  "make_array cannot be used without an explicit target type "
-  "if any of the types given is a reference_wrapper");
-return {{forward<_Types>(__t)...}};
+return {{ std::forward<_Types>(__t)... }};
   }
 
 template 
   constexpr array, _Nm>
-  __to_array(_Tp (&__a)[_Nm],
- index_sequence<_Idx...>)
+  __to_array(_Tp (&__a)[_Nm], index_sequence<_Idx...>)
   {
 return {{__a[_Idx]...}};
   }
@@ -93,6 +98,7 @@ template 
 template 
   constexpr array, _Nm>
   to_array(_Tp (&__a)[_Nm])
+  noexcept(is_nothrow_constructible, _Tp&>::value)
   {
 return __to_array(__a, make_index_sequence<_Nm>{});
   }
diff --git a/libstdc++-v3/testsuite/experimental/array/make_array.cc 
b/libstdc++-v3/testsuite/experimental/array/make_array.cc
index 45b1920..1b7d60e 100644
--- a/libstdc++-v3/testsuite/experimental/array/make_array.cc
+++ b/libstdc++-v3/testsuite/experimental/array/make_array.cc
@@ -18,7 +18,6 @@
 // .
 
 #include 
-#include 
 
 struct MoveOnly
 {
@@ -27,7 +26,7 @@ struct MoveOnly
   MoveOnly& operator=(MoveOnly&&) = default;
 };
 
-int main()
+void test01()
 {
   char x[42];
   std::array y = std::experimental::to_array(x);
@@ -45,3 +44,13 @@ int main()
 = std::experimental::make_array(1,2L, 3);
   constexpr std::array zzz2 = 
std::experimental::make_array(MoveOnly{});
 }
+
+void test02()
+{
+  // PR libstdc++/79195
+  struct A {};
+  struct B : A {};
+  struct C : A {};
+  auto arr = std::experimental::make_array(B{}, C{});
+  static_assert(std::is_same>::value, "");
+}
diff --git a/libstdc++-v3/testsuite/experimental/array/neg.cc 
b/libstdc++-v3/testsuite/experimental/array/neg.cc
index 790933d..3963287 100644
--- a/libstdc++-v3/testsuite/experimental/array/neg.cc
+++ b/libstdc++-v3/testsuite/experimental/array/neg.cc
@@ -24,5 +24,5 @@ int main()
 {
   int dummy;
   auto bad = std::experimental::make_array(std::ref(dummy));
-  // { dg-error "make_array cannot be used without an explicit target type if 
any of the types given is a r

Re: [PR middle-end/79123] cast false positive in -Walloca-larger-than=

[Martin Sebor]

Yes, I see that.  But when I change size_t to unsigned int (in LP64)
like so:

  void g (int *p, int *q)
  {
unsigned n = (unsigned)(p - q);

if (n < 10)
  f (__builtin_alloca (n));
  }

-Walloca-larger-than=100 still complains:

  warning: argument to ‘alloca’ may be too large
  note: limit is 100 bytes, but argument may be as large as 4294967295

and the VRP dump shows

  _5: [0, 4294967295]
  _14: [0, 4294967295]
  ...
_3 = p.0_1 - q.1_2;
_4 = _3 /[ex] 4;
n_10 = (unsigned int) _4;
if (n_10 <= 9)
  goto ; [36.64%]
else
  goto ; [63.36%]

 [36.64%]:
_14 = _4 & 4294967295;
_5 = (long unsigned int) _14;
_6 = __builtin_alloca (_5);

so it seems that even in VRP itself the range information isn't
quite good enough to avoid false positives.  (Perhaps that's one
the missed cases you mention below?)


Well, you see that there's no obvious way to use the n_10 <= 9 conditional
here.  VRP would need to register a [0, 9] range for the lower half of n_10
and then figure after seeing


_14 = _4 & 4294967295;


that _14 is now [0, 9].

That's a neat trick VRP cannot handle at the moment (there's no way the
lattice can encode a range for a sub-set of all bits of a SSA name).


Sure.  My point is just that it looks like there will be some false
positives whether the warnings are implemented as part of the VRP
pass or elsewhere.  (I admit I haven't studied the implementation
of the VRP pass to understand whether these false positives are
avoidable and I'm happy to take your word if if you say they can.)


Your source is bogus in the way that (unsigned)(p - q) might truncate
the pointer difference.


The problem is independent of the pointer difference and can be
reproduced by any conversion from a wider type to a narrower
unsigned type (even the safe ones), as the test case in bug 79191
I opened for it shows:

  void f (unsigned long n)
  {
if (n > 3)
  __builtin_abort ();
  }

  void h (unsigned long m)
  {
unsigned n = m;

if (n < 3)
  f (n);
  }

Martin

Re: [Ada] Ada2020 feature: partial aggregate notation (Delta aggregates).

[Arnaud Charlet]

> Please note that the trunk is in stage4, only regression bugfixes and
> documentation fixes are allowed.  It is possible to seek exceptions,
> but committing dozens of changes that do not fix regressions or
> documentation is not desirable right now.

Yes I understand, although Ada isn't considered "part of the critical
release criterias", but point taken.

Arno

Re: [PR middle-end/79123] cast false positive in -Walloca-larger-than=

[Jeff Law]

On 01/23/2017 02:50 AM, Richard Biener wrote:


So ideally DOM and EVRP would merge and CCP, copyprop and VRP
would merge.  It's probably not possible (or wise) to merge their lattices
(maybe to some extent)


DOM's equivalency tables could be easily superceded by other
implementations.  It's just two datastructures.  A trivial const/copy table
and a stack to allow unwinding the state of the const/copy table. Throwing
away the basic const/copy table and replacing it with something built by
copyprop ought to be trivial.

The big thing that would be left would be the scoped hash table for tracking
redundant expressions.  But I don't think that we'd necessarily have to rip
that out to merge DOM with one of hte other passes.

Hell we know DOM can fit well in any dominator based walk -- we used to do
it as part of the into-ssa transformation.


Sure.

The question is whether we want to make warning "passes" more expensive
by essentially doing a [E]VRP/DOM pass (but not doing any IL transform).

I believe doing that is more reasonable than doing their own hacky analysis.

Having less passes to choose to copy from for such static analysis (and the
ability to tame compile-time by some switches) would be a good thing to have.
Very true.  But your comment seemed to be about merging DOM and EVRP or 
other passes -- which is certainly possible and possibly even desirable.


The more I look at our SCCVN implementation, the more I want to explore 
trying to re-use that infrastructure to simplify DOM.



Jeff

Re: [PATCH][wwwdocs] Mention new store merging pass for GCC 7

[Jeff Law]

On 01/23/2017 05:26 AM, Kyrill Tkachov wrote:

Hi all,

This patch adds a short entry for the store merging pass in GCC 7 to the
"General Optimizer Improvements" section.

Eyeballed the result in Firefox.

Ok to commit?

OK.
jeff

[C++ Patch/RFC] PR 72764

[Paolo Carlini]

Hi,

in this relatively serious ICE on invalid regression (we don't emit any 
message before ICEing) make_typename_type, called by strip_typedefs, 
returns error_mark_node which then isn't handled by typedef_variant_p. 
Indeed, Jakub noticed that the same in principle can happen when 
strip_typedefs calls finish_decltype_type. make_typename_type is passed 
tf_none therefore cannot emit the diagnostic we want before the ICE 
anyway, thus it seems to me that we also have one of those well known 
issues about not propagating a tusbst_flags_t flag: 
canonicalize_type_argument (and canonicalize_expr_argument) get a 
tusbst_flags_t but doesn't propagate it to strip_typedefs (and 
strip_typedefs_expr).


Implementing the straightforward set of changes, consistently for 
strip_typedefs, strip_typedefs_expr and the related functions plus 
checking the return values of make_typename_type and 
finish_decltype_type for error_mark_node (only make_typename_type would 
be enough for the testcase at issue) appears to solve the problem 
without introducing regressions. Does that make sense?


Thanks,
Paolo.

/
Index: cp/cp-tree.h
===
--- cp/cp-tree.h(revision 244803)
+++ cp/cp-tree.h(working copy)
@@ -6597,8 +6597,10 @@ extern bool class_tmpl_impl_spec_p   
(const_tree);
 extern int zero_init_p (const_tree);
 extern bool check_abi_tag_redeclaration(const_tree, 
const_tree, const_tree);
 extern bool check_abi_tag_args (tree, tree);
-extern tree strip_typedefs (tree, bool * = NULL);
-extern tree strip_typedefs_expr(tree, bool * = NULL);
+extern tree strip_typedefs (tree, tsubst_flags_t,
+bool * = NULL);
+extern tree strip_typedefs_expr(tree, tsubst_flags_t,
+bool * = NULL);
 extern tree copy_binfo (tree, tree, tree,
 tree *, int);
 extern int member_p(const_tree);
Index: cp/error.c
===
--- cp/error.c  (revision 244803)
+++ cp/error.c  (working copy)
@@ -354,7 +354,7 @@ dump_template_bindings (cxx_pretty_printer *pp, tr
   pop_deferring_access_checks ();
   /* Strip typedefs.  We can't just use TFF_CHASE_TYPEDEF because
 pp_simple_type_specifier doesn't know about it.  */
-  t = strip_typedefs (t);
+  t = strip_typedefs (t, tf_none);
   dump_type (pp, t, TFF_PLAIN_IDENTIFIER);
 }
 }
@@ -393,7 +393,7 @@ dump_type (cxx_pretty_printer *pp, tree t, int fla
   || DECL_SELF_REFERENCE_P (decl)
   || (!flag_pretty_templates
   && DECL_LANG_SPECIFIC (decl) && DECL_TEMPLATE_INFO (decl)))
-   t = strip_typedefs (t);
+   t = strip_typedefs (t, tf_none);
   else if (alias_template_specialization_p (t))
{
  dump_alias_template_specialization (pp, t, flags);
@@ -3115,7 +3115,7 @@ type_to_string (tree typ, int verbose)
   struct obstack *ob = pp_buffer (cxx_pp)->obstack;
   /* Remember the end of the initial dump.  */
   int len = obstack_object_size (ob);
-  tree aka = strip_typedefs (typ);
+  tree aka = strip_typedefs (typ, tf_none);
   pp_string (cxx_pp, " {aka");
   pp_cxx_whitespace (cxx_pp);
   /* And remember the start of the aka dump.  */
Index: cp/pt.c
===
--- cp/pt.c (revision 244803)
+++ cp/pt.c (working copy)
@@ -1140,12 +1140,13 @@ verify_unstripped_args (tree args)
  if (TREE_CODE (arg) == TEMPLATE_DECL)
/* OK */;
  else if (TYPE_P (arg))
-   gcc_assert (strip_typedefs (arg, NULL) == arg);
- else if (strip_typedefs (TREE_TYPE (arg), NULL) != TREE_TYPE (arg))
+   gcc_assert (strip_typedefs (arg, tf_none, NULL) == arg);
+ else if (strip_typedefs (TREE_TYPE (arg),
+  tf_none, NULL) != TREE_TYPE (arg))
/* Allow typedefs on the type of a non-type argument, since a
   parameter can have them.  */;
  else
-   gcc_assert (strip_typedefs_expr (arg, NULL) == arg);
+   gcc_assert (strip_typedefs_expr (arg, tf_none, NULL) == arg);
}
 }
   --processing_template_decl;
@@ -7312,7 +7313,7 @@ canonicalize_type_argument (tree arg, tsubst_flags
   if (!arg || arg == error_mark_node || arg == TYPE_CANONICAL (arg))
 return arg;
   bool removed_attributes = false;
-  tree canon = strip_typedefs (arg, &removed_attributes);
+  tree canon = strip_typedefs (arg, complain, &removed_attributes);
   if (removed_attributes
   && (complain & tf_warning))
 warning (OPT_Wignored_attri

Re: [PATCH] Do not declare artificial variables in tree-profile.c to have a definition (PR lto/69188).

[Jeff Law]

On 01/23/2017 03:05 AM, Kyrill Tkachov wrote:


On 23/01/17 09:58, Christophe Lyon wrote:

On 13 January 2017 at 18:21, Jeff Law  wrote:

On 01/13/2017 08:08 AM, Martin Liška wrote:

Hello.

Nice example provided in the PR causes ICE as we have an artificial
symbol
created in tree-profile.c once being removed by remove unreachable
nodes
(-O0)
and once not (-O1). Well, difference is in process_references where
following hunk
prevent removal:

   || (((before_inlining_p
 && ((TREE_CODE (node->decl) != FUNCTION_DECL
  && optimize)

Anyway, these artificial symbols really should be just declarations as
they are defined
in libgcov library.

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

Ready to be installed?
Martin


0001-Do-not-declare-artificial-variables-in-tree-profile..patch


 From 87262b1b60009381fd943fb433bc38f5d5685ac9 Mon Sep 17 00:00:00 2001
From: marxin 
Date: Fri, 13 Jan 2017 13:12:57 +0100
Subject: [PATCH] Do not declare artificial variables in
tree-profile.c to
have
  a definition (PR lto/69188).

gcc/testsuite/ChangeLog:

2017-01-13  Martin Liska  

 PR lto/69188
 * gcc.dg/lto/pr69188_0.c: New test.
 * gcc.dg/lto/pr69188_1.c: New test.

gcc/ChangeLog:

2017-01-13  Martin Liska  

 PR lto/69188
 * tree-profile.c (init_ic_make_global_vars): Do not call
 finalize_decl.
 (gimple_init_gcov_profiler): Likewise.

OK.
jeff


Hi,

The new test fails on arm-none-eabi:
/cc6RcpEu.ltrans0.ltrans.o: In function `fn1':
:(.text+0x18): undefined reference to
`__gcov_indirect_call_profiler_v2'
:(.text+0x1c): undefined reference to
`__gcov_indirect_call_callee'
:(.text+0x20): undefined reference to
`__gcov_indirect_call_callee'
:(.text+0x60): undefined reference to
`__gcov_time_profiler_counter'
:(.text+0x64): undefined reference to
`__gcov_time_profiler_counter'
:(.text+0x80): undefined reference to
`__gcov_time_profiler_counter'
:(.text+0x84): undefined reference to
`__gcov_time_profiler_counter'
/cc6RcpEu.ltrans0.ltrans.o: In function `_GLOBAL__sub_D_00100_1_fn1':
:(.text+0xb8): undefined reference to `__gcov_exit'
/cc6RcpEu.ltrans0.ltrans.o: In function `main':
:(.text+0xd4): undefined reference to
`__gcov_indirect_call_profiler_v2'
:(.text+0xd8): undefined reference to
`__gcov_indirect_call_callee'
:(.text+0xdc): undefined reference to
`__gcov_indirect_call_callee'
:(.text+0x10c): undefined reference to
`__gcov_time_profiler_counter'
:(.text+0x110): undefined reference to
`__gcov_time_profiler_counter'
/cc6RcpEu.ltrans0.ltrans.o: In function `_GLOBAL__sub_D_00100_1_main':
:(.text+0x180): undefined reference to `__gcov_exit'
/cc6RcpEu.ltrans0.ltrans.o:(.data+0x4c): undefined reference to
`__gcov_merge_time_profile'
/cc6RcpEu.ltrans0.ltrans.o:(.data+0xac): undefined reference to
`__gcov_merge_time_profile'
collect2: error: ld returned 1 exit status

FAIL: gcc.dg/lto/pr69188 c_lto_pr69188_0.o-c_lto_pr69188_1.o link,
-flto -O0 -fprofile-generate

It works on arm-linux*.


Hi,

The testcase fails on bare-metal targets that don't support profiling.
I believe it needs to be guarded with dg-require-profiling (I grepped
around the testsuite for similar directives).
With this patch the testcase appears unsupported on aarch64-none-elf
where I observed the failure.

Ok to commit?

Thanks,
Kyrill

2016-01-23  Kyrylo Tkachov  

* gcc.dg/lto/pr69188_0.c: Require profiling support for testcase.

OK.
jeff

Re: [PATCH][GCC][PATCHv3] Improve fpclassify w.r.t IEEE like numbers in GIMPLE.

[Joseph Myers]

On Mon, 23 Jan 2017, Tamar Christina wrote:

> In the testcase I've also had to remove `-funsafe-math-optimizations` 
> because at least on AArch64 this sets the LZ bit in the FPCR which 
> causes the fcmp to collapse small subnormal numbers to 0 and so iszero 
> would fail.

That's not an appropriate change to the test; it's clear that test is 
deliberately about testing what happens with -funsafe-math-optimizations.  
Rather, any particular new pieces that won't work with 
-funsafe-math-optimizations should have #ifdef UNSAFE conditionals in 
tg-tests.h, like the existing conditionals there.

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

Re: [PATCH v5] add -fprolog-pad=N,M option

[Bernd Schmidt]

There's still a a few details that need addressing, and some questions I 
have. Also Ccing Jakub to have another pair of eyes on the name of the 
section - I don't know if we want some sort of .gnu.something name.


On 01/13/2017 01:19 PM, Torsten Duwe wrote:


2017-01-13  Torsten Duwe :


First, some people seem to care, so I'll have to ask to please check the 
correct formatting of this line (spacing and all) by looking at existing 
entries. Also remove some of the blank lines in the ChangeLog, you could 
still group the doc entries separately from the code ones.



 * c-family/c-attribs.c : introduce prolog_pad attribute and create
   a handler for it.

 * lto/lto-lang.c : Likewise.


> * testsuite/c-c++-common/attribute-prolog_pad-1.c : New test.

These three directories have separate ChangeLogs. The top-level 
directory name should be stripped and the entries added to the 
appropriate file.



+  for (it = &DECL_ATTRIBUTES (newdecl); *it; it = &TREE_CHAIN(*it))
+   {
+ if (IDENTIFIER_LENGTH (get_attribute_name (*it)) !=
+ strlen("prolog_pad"))


Still several instances of bad formatting, in the entire block of code. 
Please refer to my previous email.



+static tree
+handle_prolog_pad_attribute (tree *, tree, tree, int,
+bool *)
+{
+  /* Nothing to be done here.  */
+  return NULL_TREE;
+}


Should still add at least one-liner comments before these empty 
functions to say what interface they're implementing. Also, probably 
don't need to wrap the line containing the arguments.



diff --git a/gcc/testsuite/c-c++-common/attribute-prolog_pad-1.c 
b/gcc/testsuite/c-c++-common/attribute-prolog_pad-1.c
new file mode 100644
index 000..2236aa8
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/attribute-prolog_pad-1.c
@@ -0,0 +1,34 @@
+/* { dg-do compile } */
+/* { dg-options "-fprolog-pad=3,1" } */


This test does not actually seem to verify that the padding has the 
expected size.



  /* Do not use IPA optimizations for register allocation if profiler is active
+or prolog pads are inserted for run-time instrumentation
 or port does not emit prologue and epilogue as RTL.  */
-  if (profile_flag || !targetm.have_prologue () || !targetm.have_epilogue ())
+  if (profile_flag || prolog_nop_pad_size
+  || !targetm.have_prologue () || !targetm.have_epilogue ())
 flag_ipa_ra = 0;


Was this explained? Why would ipa-ra be a problem?


+  if (pad_size > pad_entry)
+targetm.asm_out.print_prolog_pad (asm_out_file, pad_size-pad_entry,
+ (pad_entry == 0));


Unnecessary parens around the last argument, and missing spaces around 
operators.



Bernd

Re: [libcc1] add support for C++

[Joseph Myers]

On Sun, 22 Jan 2017, Alexandre Oliva wrote:

> On Jan 13, 2017, Jason Merrill  wrote:
> 
> > On 09/23/2016 08:41 PM, Alexandre Oliva wrote:
> >> +static tree global_friend_list;
> 
> > This should be a hash_set rather than a TREE_LIST.
> 
> You sure?  At least in the libcc1 use scenario, this is going to have a
> single entry.  I didn't even have to make it a list, but I made it one
> because, well, I could :-)  A hash_set seems excessive, unless you
> envision other uses for it.

TREE_LIST should die, so whatever it should be, it shouldn't be a 
TREE_LIST (even if this is one of the cases where TREE_LIST doesn't cause 
efficiency issues).

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

Re: [PATCH][wwwdocs] Mention new store merging pass for GCC 7

[Gerald Pfeifer]

Hi Kyrill,

On Mon, 23 Jan 2017, Kyrill Tkachov wrote:

This patch adds a short entry for the store merging pass in GCC 7 to the
"General Optimizer Improvements" section.


+  A new store merging pass has been added.  It will attempt to merge
+  constant stores to adjacent memory locations into fewer wider stores.
+  It can be enabled by using the -fstore-merging option and is
+  enabled by default at the -O2 optimization level or
+  higher.

Here I'd say "it attempts to merge" or, better yet, let's just say
"it merges".

Let's not be too shy. :-)  (This still does not claim that it always
succeeds or anything like that, mind.)

Okay, with that note taken into consideration.

Thanks,
Gerald

[PATCH] PR66669: Fix failure of gcc.dg/loop-8.c on Power

[Kelvin Nilsen]

The test gcc.dg/loop-8.c makes assumptions that are not valid on Power
architecture (and on certain other architectures for which this issue
has already been addressed).  The test case assumes that a single
loop-invariant statement will be moved outside the loop.  On Power, a
constant is copy-propagated within the loop, and the subsequent
loop-invariant code motion moves two loop-invariant statements out of
the loop.

This patch simply disables this test case on Power architecture.


gcc/testsuite/ChangeLog:

2017-01-23  Kelvin Nilsen  

PR target/9
* gcc.dg/loop-8.c: Modify dg-skip-if directive to exclude this
test on powerpc targets.

Index: gcc/testsuite/gcc.dg/loop-8.c
===
--- gcc/testsuite/gcc.dg/loop-8.c   (revision 244730)
+++ gcc/testsuite/gcc.dg/loop-8.c   (working copy)
@@ -1,6 +1,6 @@
 /* { dg-do compile } */
 /* { dg-options "-O1 -fdump-rtl-loop2_invariant" } */
-/* { dg-skip-if "unexpected IV" { "hppa*-*-* mips*-*-* visium-*-*" } { "*" } { 
"" } } */
+/* { dg-skip-if "unexpected IV" { "hppa*-*-* mips*-*-* visium-*-* 
powerpc*-*-*" } { "*" } { "" } } */
 
 void
 f (int *a, int *b)

Re: [PATCH] PR66669: Fix failure of gcc.dg/loop-8.c on Power

[Jeff Law]

On 01/23/2017 09:59 AM, Kelvin Nilsen wrote:


The test gcc.dg/loop-8.c makes assumptions that are not valid on Power
architecture (and on certain other architectures for which this issue
has already been addressed).  The test case assumes that a single
loop-invariant statement will be moved outside the loop.  On Power, a
constant is copy-propagated within the loop, and the subsequent
loop-invariant code motion moves two loop-invariant statements out of
the loop.

This patch simply disables this test case on Power architecture.


gcc/testsuite/ChangeLog:

2017-01-23  Kelvin Nilsen  

PR target/9
* gcc.dg/loop-8.c: Modify dg-skip-if directive to exclude this
test on powerpc targets.

OK.
jeff

Re: [PATCH] Fix -Wformat-security warnings in dwarf2out.c

[Jeff Law]

On 01/20/2017 04:24 PM, Jakub Jelinek wrote:

Hi!

When building gcc with -Wformat -Werror=format-security, there are various
warnings->errors.  This set has been introduced by me :( in the DWARF5
work, thus it is a 7 Regression.

Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?

2017-01-20  Jakub Jelinek  

* dwarf2out.c (output_compilation_unit_header, output_file_names):
Avoid -Wformat-security warning.
OK.  I'd consider these obvious, so if there's others you find, no need 
to wait on an approval.


jeff

[c== pATCH] 71710 dependent FIELD_DECL

[Nathan Sidwell]

Jason,
Bug 71710 is a crash on 'decltype (a)', where 'a' is a FIELD_DECL wth 
dependent type.  finish_class_member_access_expr barfs on that.  The 
earlier sequence of if..elses has a check for FIELD_DECL, but that's in 
the shadow of a type_dependent_expression_p (object) check.  The field's 
type is the main template type, so it does have a type dependent object. 
 But there's no reason it shouldn't go through the usual 
finish_non_static_data_member processing.


Fixed by moving the FIELD_DECL check earlier.

ok?

nathan
--
Nathan Sidwell
2017-01-23  Nathan Sidwell  

	PR c++/71710 - template using directive of field
	* pt.c (tsubst_copy_and_build [COMPONENT_REF]): Move FIELD_DECL
	check earlier.

	PR C++/71710
	* g++.dg/template/pr71710.C: New.

Index: cp/pt.c
===
--- cp/pt.c	(revision 244815)
+++ cp/pt.c	(working copy)
@@ -17470,7 +17470,14 @@ tsubst_copy_and_build (tree t,
 	if (member == error_mark_node)
 	  RETURN (error_mark_node);
 
-	if (type_dependent_expression_p (object))
+	if (TREE_CODE (member) == FIELD_DECL)
+	  {
+	r = finish_non_static_data_member (member, object, NULL_TREE);
+	if (TREE_CODE (r) == COMPONENT_REF)
+	  REF_PARENTHESIZED_P (r) = REF_PARENTHESIZED_P (t);
+	RETURN (r);
+	  }
+	else if (type_dependent_expression_p (object))
 	  /* We can't do much here.  */;
 	else if (!CLASS_TYPE_P (object_type))
 	  {
@@ -17535,13 +17542,6 @@ tsubst_copy_and_build (tree t,
 	  }
 	RETURN (error_mark_node);
 	  }
-	else if (TREE_CODE (member) == FIELD_DECL)
-	  {
-	r = finish_non_static_data_member (member, object, NULL_TREE);
-	if (TREE_CODE (r) == COMPONENT_REF)
-	  REF_PARENTHESIZED_P (r) = REF_PARENTHESIZED_P (t);
-	RETURN (r);
-	  }
 
 	r = finish_class_member_access_expr (object, member,
 	 /*template_p=*/false,
Index: testsuite/g++.dg/template/pr71710.C
===
--- testsuite/g++.dg/template/pr71710.C	(revision 0)
+++ testsuite/g++.dg/template/pr71710.C	(working copy)
@@ -0,0 +1,10 @@
+// { dg-do compile { target c++11 } }
+// PR C++/71710 ICE with decltype & using
+
+template < typename > struct A
+{
+  A a;
+  template < int > using B = decltype (a);
+  B < 0 > b;
+  template < int C > B < C > foo ();
+};

[PATCH, libstdc++-v3] Fix 69301.cc FAIL: require atomic builtins

[Thomas Preudhomme]

Hi,

69301.cc C++ test uses atomic features but fail to require atomic builtins. This 
causes the test to fail on ARMv6-M instead of being skipped. Fixed as obvious.


ChangeLog entry is as follows:

*** libstdc++-v3/ChangeLog ***

2017-01-23  Thomas Preud'homme  

* testsuite/29_atomics/atomic/69301.cc: Require atomic builtins.

Best regards,

Thomas
diff --git a/libstdc++-v3/testsuite/29_atomics/atomic/69301.cc b/libstdc++-v3/testsuite/29_atomics/atomic/69301.cc
index 1af36525af5c3e40c1234d0a2500dd2e958032d7..29d19d57d7027baeea30c90b3650c60fdbcda757 100644
--- a/libstdc++-v3/testsuite/29_atomics/atomic/69301.cc
+++ b/libstdc++-v3/testsuite/29_atomics/atomic/69301.cc
@@ -16,6 +16,7 @@
 // .
 
 // { dg-do run { target c++11 } }
+// { dg-require-atomic-builtins "" }
 
 #include 
 #include 

[PATCH][doc] Correct optimisation levels documentation for -fstore-merging

[Kyrill Tkachov]

Hi all,

I had forgotten to update the -fstore-merging documentation from a previous 
iteration of the pass
and it says that it's enabled at -O and higher. The option is in fact enabled 
at -O2 and higher, as well as -Os.
This patch clarifies that.

Is this ok? Or is there a more preferred style of listing optimisation levels?

Thanks,
Kyrill

2016-01-23  Kyrylo Tkachov  

* doc/invoke.texi (-fstore-merging): Correct default optimization
levels at which it is enabled.
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 45af80c..b29348c 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -8342,7 +8342,7 @@ early.  This flag is enabled by default at @option{-O} and higher.
 Perform merging of narrow stores to consecutive memory addresses.  This pass
 merges contiguous stores of immediate values narrower than a word into fewer
 wider stores to reduce the number of instructions.  This is enabled by default
-at @option{-O} and higher.
+at @option{-O2} and higher as well as @option{-Os}.
 
 @item -ftree-ter
 @opindex ftree-ter

Re: [PR tree-optimization/71691] Fix unswitching in presence of maybe-undef SSA_NAMEs (take 2)

[Aldy Hernandez]

On 01/18/2017 10:10 AM, Richard Biener wrote:

On Fri, Jan 13, 2017 at 7:48 PM, Aldy Hernandez  wrote:


Hi Richard.

I'd be happy to provide a patch, but could you please elaborate, as I'm 
afraid I'm not following.



We could go back to my original, no caching version (with the other
suggestions).  That solves the problem quite simply, with no regressions.


So let's go with a unswitching-local solution then.  Based on
tree_may_unswitch_on:


What do you mean by unswitching-local?



  /* Condition must be invariant.  */
  FOR_EACH_SSA_TREE_OPERAND (use, stmt, iter, SSA_OP_USE)
{
  /* Unswitching on undefined values would introduce undefined
 behavior that the original program might never exercise.  */
  if (ssa_undefined_value_p (use, true))
return NULL_TREE;
  def = SSA_NAME_DEF_STMT (use);
  def_bb = gimple_bb (def);
  if (def_bb
  && flow_bb_inside_loop_p (loop, def_bb))
return NULL_TREE;

we only have to look for uses in blocks dominating the loop header block
(or in blocks post-dominating that loop header, but we can probably implement
that by simply including the loop header itself with a FIXME comment).


Look for *uses*??  Do you mean definitions?  I mean, we're trying to 
figure out whether we are going to unswitch on a use that is inside a 
the loop, not before or after. So perhaps we only care about 
*definitions* (SSA_NAME_DEF_STMT) dominating the loop header.




Note that we only need to know whether a BB will be always executed when
the loop is entered -- there's "infrastructure" elsewhere that computes this
w/o the need of post-dominance.  For example see fill_always_executed_in_1
tree-ssa-loop-im.c (we can't use that 1:1 I think because we already use ->aux
via the original copy tables, but we could simplify it as we're only
interested in
the loop which preheader we put the unswitch condition on so we can use
a bitmap to record whether a block of the loop is always executed or not).


I don't see any use of ->aux within loop unswitching, so perhaps no 
adjustment is needed?  I verified this by successfully bootstrapping with:


diff --git a/gcc/tree-ssa-loop-unswitch.c b/gcc/tree-ssa-loop-unswitch.c
index 92599fb..774d6bf 100644
--- a/gcc/tree-ssa-loop-unswitch.c
+++ b/gcc/tree-ssa-loop-unswitch.c
@@ -94,6 +94,14 @@ tree_ssa_unswitch_loops (void)
   struct loop *loop;
   bool changed = false;

+  basic_block bb;
+  FOR_ALL_BB_FN (bb, cfun)
+if (bb->aux)
+  {
+   gcc_unreachable ();
+  }

Furthermore, you say that we have this "infrastructure" without the need 
for post-dominance.  But we still need dominance info.  The function 
fill_always_execute_in_1 uses CDI_DOMINATORS both inside said function, 
and throughout its dependencies.  I thought the point of pre-calculating 
dominance info (or post-dominance info) originally was because we 
couldn't depend on dominance info being kept up to date between 
executions of tree_unswitch_single_loop(), which BTW, runs recursively.



Can you send a patch that does this maybe?


Sure, when I understand what you suggest ;-).

Again, thanks for your input here.
Aldy

Re: [RFC] fix bootstrap on aarch64-*-freebsd and probably others

[Andreas Tobler]

On 23.01.17 11:07, Richard Earnshaw (lists) wrote:

On 21/01/17 20:15, Andreas Tobler wrote:

On 21.01.17 00:42, Jakub Jelinek wrote:

On Fri, Jan 20, 2017 at 01:37:13PM -0700, Jeff Law wrote:

Which is best will depend on what the front/mid ends might have
done to
apply the documented limit.


Here I know not enough to give a decision. In tree the priority_type is
unsigned short. In varasm priority is an int.

Similar functions, like arm_elf_asm_cdtor, do use the sprintf
instead of
snprintf. They theoretically have the same issue.

So, either:
2.) use %.5hu in snprintf
or
3.) cast priority in snprintf to (unsigned short)

I'd go with #2.  I think #3 still requires range propagation to avoid
the
false positive.


I actually think 1.) is best work-around, after 18 bytes there will be
some
padding so 23 bytes will almost always eat the same amount of stack
space,
and we avoid actually adding some instruction to cast it or hoping all
the
libcs we run on support %.5hu properly.


Richard, what do you think about this suggestion?

Thanks,
Andreas




I'm happy to go with that, but please add a comment as well, or some
well meaning individual may accidentally reverse the change after
counting the bytes...


Something like below?

If ok, I can commit, right?

Thanks,

Andreas

2017-01-23  Andreas Tobler  

* config/aarch64/aarch64.c (aarch64_elf_asm_constructor): Increase
size of buf.
(aarch64_elf_asm_destructor): Likewise.


Index: config/aarch64/aarch64.c
===
--- config/aarch64/aarch64.c(revision 244819)
+++ config/aarch64/aarch64.c(working copy)
@@ -5787,7 +5787,11 @@
   else
 {
   section *s;
-  char buf[18];
+  /* The size of the buf must be big enough to hold the string and the
+ full integer size of priority. Otherwise we will get a warning
+ about format-truncation.
+  */
+  char buf[23];
   snprintf (buf, sizeof (buf), ".init_array.%.5u", priority);
   s = get_section (buf, SECTION_WRITE, NULL);
   switch_to_section (s);
@@ -5804,7 +5808,11 @@
   else
 {
   section *s;
-  char buf[18];
+  /* The size of the buf must be big enough to hold the string and the
+ full integer size of priority. Otherwise we will get a warning
+ about format-truncation.
+  */
+  char buf[23];
   snprintf (buf, sizeof (buf), ".fini_array.%.5u", priority);
   s = get_section (buf, SECTION_WRITE, NULL);
   switch_to_section (s);

Re: [RFC] fix bootstrap on aarch64-*-freebsd and probably others

[Jakub Jelinek]

On Mon, Jan 23, 2017 at 06:42:15PM +0100, Andreas Tobler wrote:
> Something like below?
> 
> If ok, I can commit, right?
> 
> Thanks,
> 
> Andreas
> 
> 2017-01-23  Andreas Tobler  
> 
>   * config/aarch64/aarch64.c (aarch64_elf_asm_constructor): Increase
>   size of buf.
>   (aarch64_elf_asm_destructor): Likewise.
> --- config/aarch64/aarch64.c  (revision 244819)
> +++ config/aarch64/aarch64.c  (working copy)
> @@ -5787,7 +5787,11 @@
>else
>  {
>section *s;
> -  char buf[18];
> +  /* The size of the buf must be big enough to hold the string and the
> + full integer size of priority. Otherwise we will get a warning
> + about format-truncation.
> +  */

Please put the */ on the same line as about format-truncation, like:
 about format-truncation.  */
After . there should be 2 spaces rather than one.
Also, the comment doesn't tell the truth, the buffer doesn't have to be that
big, because we know priority is bounded, just the compiler doesn't know
that.  So perhaps:
  /* While priority is known to be in range [0, 65535], so 18 bytes
 would be enough, the compiler might not know that.  To avoid
 -Wformat-truncation false positive, use a larger size.  */
  char buf[23];
or so?

Jakub

Re: [RFC] fix bootstrap on aarch64-*-freebsd and probably others

[Andreas Tobler]

On 23.01.17 18:48, Jakub Jelinek wrote:

On Mon, Jan 23, 2017 at 06:42:15PM +0100, Andreas Tobler wrote:

Something like below?

If ok, I can commit, right?

Thanks,

Andreas

2017-01-23  Andreas Tobler  

* config/aarch64/aarch64.c (aarch64_elf_asm_constructor): Increase
size of buf.
(aarch64_elf_asm_destructor): Likewise.
--- config/aarch64/aarch64.c(revision 244819)
+++ config/aarch64/aarch64.c(working copy)
@@ -5787,7 +5787,11 @@
   else
 {
   section *s;
-  char buf[18];
+  /* The size of the buf must be big enough to hold the string and the
+ full integer size of priority. Otherwise we will get a warning
+ about format-truncation.
+  */


Please put the */ on the same line as about format-truncation, like:
 about format-truncation.  */
After . there should be 2 spaces rather than one.
Also, the comment doesn't tell the truth, the buffer doesn't have to be that
big, because we know priority is bounded, just the compiler doesn't know
that.  So perhaps:
  /* While priority is known to be in range [0, 65535], so 18 bytes
 would be enough, the compiler might not know that.  To avoid
 -Wformat-truncation false positive, use a larger size.  */
  char buf[23];
or so?



Danke.

Andreas

2017-01-23  Andreas Tobler  

* config/aarch64/aarch64.c (aarch64_elf_asm_constructor): Increase
size of buf.
(aarch64_elf_asm_destructor): Likewise.

Index: config/aarch64/aarch64.c
===
--- config/aarch64/aarch64.c(revision 244819)
+++ config/aarch64/aarch64.c(working copy)
@@ -5787,7 +5787,10 @@
   else
 {
   section *s;
-  char buf[18];
+  /* While priority is known to be in range [0, 65535], so 18 bytes
+ would be enough, the compiler might not know that.  To avoid
+ -Wformat-truncation false positive, use a larger size.  */
+  char buf[23];
   snprintf (buf, sizeof (buf), ".init_array.%.5u", priority);
   s = get_section (buf, SECTION_WRITE, NULL);
   switch_to_section (s);
@@ -5804,7 +5807,10 @@
   else
 {
   section *s;
-  char buf[18];
+  /* While priority is known to be in range [0, 65535], so 18 bytes
+ would be enough, the compiler might not know that.  To avoid
+ -Wformat-truncation false positive, use a larger size.  */
+  char buf[23];
   snprintf (buf, sizeof (buf), ".fini_array.%.5u", priority);
   s = get_section (buf, SECTION_WRITE, NULL);
   switch_to_section (s);

Re: libgo patch committed: Update to Go1.8rc1

[Ian Lance Taylor]

On Tue, Jan 17, 2017 at 8:44 AM, Lynn A. Boger
 wrote:
> In the past, the libgo version number has always matched the Go version, not
> the gcc release.
>
> The libgo for Go 1.7 and Go 1.8 are not the same.  If someone wanted to
> build gccgo for Go 1.7 using an old commit
>
> maybe for testing or comparison purposes, the libgo version would not
> identify which one it was because
>
> libgo.so.10 could be either Go 1.7 or 1.8.  Maybe nobody cares about doing
> that. It's not a huge deal to me but
>
> it would be a point of confusion.
>
> GCC 6.x was Go 1.6.

I do usually update the version number for each major import (and I do
usually forget to do it the first time around).  I committed this
patch to mainline.

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 244733)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-b573d4756096523d8bd4bf7b11e56383e5a2cca4
+6d8ef03e760ff737ff2c613642142290b0f02e0e
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: libgo/configure.ac
===
--- libgo/configure.ac  (revision 244166)
+++ libgo/configure.ac  (working copy)
@@ -11,7 +11,7 @@ AC_INIT(package-unused, version-unused,,
 AC_CONFIG_SRCDIR(Makefile.am)
 AC_CONFIG_HEADER(config.h)
 
-libtool_VERSION=10:0:0
+libtool_VERSION=11:0:0
 AC_SUBST(libtool_VERSION)
 
 AM_ENABLE_MULTILIB(, ..)

Go patch committed: Fixes for m68k

[Ian Lance Taylor]

I committed a patch to the Go frontend and libgo to fix alignment
issues on m68k.  This fixes PR 79037.  Bootstrapped and ran Go tests
on x86_64-pc-linux-gnu.  Tested by John Paul Adrian Glaubitz on
m68k-linux-gnu.  Committed to mainline.

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 244823)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-6d8ef03e760ff737ff2c613642142290b0f02e0e
+0655e25d8e4acfac50c6b1422dc32eca3e30803a
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: gcc/go/gofrontend/types.cc
===
--- gcc/go/gofrontend/types.cc  (revision 244460)
+++ gcc/go/gofrontend/types.cc  (working copy)
@@ -2468,13 +2468,28 @@ Type::make_gc_symbol_var(Gogo* gogo)
   is_common = true;
 }
 
+  // The current garbage collector requires that the GC symbol be
+  // aligned to at least a four byte boundary.  See the use of PRECISE
+  // and LOOP in libgo/runtime/mgc0.c.
+  int64_t align;
+  if (!sym_init->type()->backend_type_align(gogo, &align))
+go_assert(saw_errors());
+  if (align < 4)
+align = 4;
+  else
+{
+  // Use default alignment.
+  align = 0;
+}
+
   // Since we are building the GC symbol in this package, we must create the
   // variable before converting the initializer to its backend representation
   // because the initializer may refer to the GC symbol for this type.
   std::string asm_name(go_selectively_encode_id(sym_name));
   this->gc_symbol_var_ =
   gogo->backend()->implicit_variable(sym_name, asm_name,
- sym_btype, false, true, is_common, 0);
+sym_btype, false, true, is_common,
+align);
   if (phash != NULL)
 *phash = this->gc_symbol_var_;
 
Index: libgo/runtime/go-unsafe-pointer.c
===
--- libgo/runtime/go-unsafe-pointer.c   (revision 244256)
+++ libgo/runtime/go-unsafe-pointer.c   (working copy)
@@ -36,7 +36,8 @@ static const String reflection_string =
   sizeof REFLECTION - 1
 };
 
-const uintptr unsafe_Pointer_gc[] = {sizeof(void*), GC_APTR, 0, GC_END};
+const uintptr unsafe_Pointer_gc[] __attribute__((aligned(4))) =
+  {sizeof(void*), GC_APTR, 0, GC_END};
 
 extern const FuncVal runtime_pointerhash_descriptor
   __asm__ (GOSYM_PREFIX "runtime.pointerhash$descriptor");
Index: libgo/runtime/parfor.c
===
--- libgo/runtime/parfor.c  (revision 244456)
+++ libgo/runtime/parfor.c  (working copy)
@@ -11,7 +11,7 @@
 struct ParForThread
 {
// the thread's iteration space [32lsb, 32msb)
-   uint64 pos;
+   uint64 pos __attribute__((aligned(8)));
// stats
uint64 nsteal;
uint64 nstealcnt;
Index: libgo/runtime/runtime.h
===
--- libgo/runtime/runtime.h (revision 244456)
+++ libgo/runtime/runtime.h (working copy)
@@ -191,7 +191,7 @@ struct ParFor
// otherwise parfor may return while 
other threads are still working
ParForThread *thr;  // array of thread descriptors
// stats
-   uint64 nsteal;
+   uint64 nsteal __attribute__((aligned(8))); // force alignment for m68k
uint64 nstealcnt;
uint64 nprocyield;
uint64 nosyield;

Re: [PATCH][doc] Correct optimisation levels documentation for -fstore-merging

[Sandra Loosemore]

On 01/23/2017 10:28 AM, Kyrill Tkachov wrote:

Hi all,

I had forgotten to update the -fstore-merging documentation from a
previous iteration of the pass
and it says that it's enabled at -O and higher. The option is in fact
enabled at -O2 and higher, as well as -Os.
This patch clarifies that.

Is this ok? Or is there a more preferred style of listing optimisation
levels?

Thanks,
Kyrill

2016-01-23  Kyrylo Tkachov  

 * doc/invoke.texi (-fstore-merging): Correct default optimization
 levels at which it is enabled.


It looks to me like you also need to move -fstore-merging from the list 
of optimizations enabled by -O to the list documented under -O2.


-Sandra

Re: [PATCH 1/5] consolidate handling of directives (PR 78703)

[Jeff Law]

On 01/22/2017 04:52 PM, Martin Sebor wrote:

The substance of the attached change set is to lay the groundwork
of consolidating the handling of format directives and conversion
specifications.

1) Extend (and rename) struct conversion_spec used thus far to
represent a format conversion specification (the part of the format
string that starts with the percent character) to struct directive.
A directive can be either a conversion specification or a sequence
of plain characters that do not include the percent sign.  This
change significantly simplifies the handling of the whole format
string.

2) Separate code that parses a directive from code that subsequently
processes it.  This makes both the parsing and the processing logic
cleaner and easier to follow and modify.

3) Consolidate the code that extracts width and precision specified
by the asterisk (as in "%*.*i") from all of the directive-specific
format_xxx functions into a single function (parse_directive).
This reduces code duplication and lets the width and precision be
treated consistently in all directives.

4) Split single character handling from format_string and into its
own function.  The handling, while similar enough at first, has
diverged to the point that the conditionals to differentiate one
from the other were obscuring the logic for handling each.

None of these changes affects the tests.

gcc-78703-1.diff


commit a469182f012696107759cfe590cad3a06bd8a416
Author: Martin Sebor 
Date:   Thu Jan 19 16:47:02 2017 -0700

2017-01-19  Martin Sebor  

* gimple-ssa-sprintf.c (pass_sprintf_length::gate): Adjust formatting.
(fmtresult::operator+=): Outlined.
(struct fmtresult): Add ctors.
(struct conversion_spec): Rename...
(struct directive): ...to this.  Add and remove data members.
(directive::set_width, directive::set_precision): New functions.
(format_percent): Use ftresult ctor.
(get_width_and_precision): Remove.
(format_integer): Make naming changes.  Avoid computing width and
precision.
(format_floating): Same.  Adjust indentation.
(format_character): New function.
(format_string): Moved character handling to format_character.
(format_directive): Remove arguments, change return type.
(parse_directive): New function.
(pass_sprintf_length::compute_format_length): Move directive
parsing to parse_directive.
Please add a regression marker for 78703.  This is infrastructure that 
you need in place to address that BZ in a reasonable manner.


If this has been bootstrapped and regression tested, then I would go 
ahead and install it now.  That way you don't have to carry this 
refactoring patch around if I'm unable to get through all 5 patches quickly.


jeff

ps.  This really does help -- most of the changes were very easy to work 
through and give a high level looksie and spot check here and there. 
parse_directive/compute_format_length was a bit painful, but even that 
wasn't terrible.

[C++ PATCH] 71406, 77508 scoped template_ids

[Nathan Sidwell]

This patch fixes 71406 and 77508, which are both ICEs dealing with 
'X::Foo<...>'.  finish_class_member_access_expr wasn't prepared to 
handle SCOPE_REF (TEMPLATE_ID_EXPR (...)), which is what it was being 
fed.  Fixed by moving the SCOPE_REF splitting to before the 
TEMPLATE_ID_EXPR handling, but leaving the scope checking where it was.


ok?

nathan
--
Nathan Sidwell
2017-01-23  Nathan Sidwell  

	PR c++/71406 - ICE with scope-ref'd template id exprs
	PR c++/77508
	* typeck.c (finish_class_member_access_expr): Break up SCOPE_REF
	before breaking up TEMPLATE_ID_EXPR.

	PR c++/71406
	PR c++/77508
	* g++.dg/template/pr71406.C: New.

Index: cp/typeck.c
===
--- cp/typeck.c	(revision 244819)
+++ cp/typeck.c	(working copy)
@@ -2730,19 +2730,9 @@ finish_class_member_access_expr (cp_expr
 {
   bool is_template_id = false;
   tree template_args = NULL_TREE;
-  tree scope;
+  tree scope = NULL_TREE;
 
-  if (TREE_CODE (name) == TEMPLATE_ID_EXPR)
-	{
-	  is_template_id = true;
-	  template_args = TREE_OPERAND (name, 1);
-	  name = TREE_OPERAND (name, 0);
-
-	  if (TREE_CODE (name) == OVERLOAD)
-	name = DECL_NAME (get_first_fn (name));
-	  else if (DECL_P (name))
-	name = DECL_NAME (name);
-	}
+  access_path = object_type;
 
   if (TREE_CODE (name) == SCOPE_REF)
 	{
@@ -2761,9 +2751,25 @@ finish_class_member_access_expr (cp_expr
 		   scope, name, object_type);
 	  return error_mark_node;
 	}
+	}
+  
+  if (TREE_CODE (name) == TEMPLATE_ID_EXPR)
+	{
+	  is_template_id = true;
+	  template_args = TREE_OPERAND (name, 1);
+	  name = TREE_OPERAND (name, 0);
 
+	  if (TREE_CODE (name) == OVERLOAD)
+	name = DECL_NAME (get_first_fn (name));
+	  else if (DECL_P (name))
+	name = DECL_NAME (name);
+	}
+
+  if (scope)
+	{
 	  if (TREE_CODE (scope) == ENUMERAL_TYPE)
 	{
+	  gcc_assert (!is_template_id);
 	  /* Looking up a member enumerator (c++/56793).  */
 	  if (!TYPE_CLASS_SCOPE_P (scope)
 		  || !DERIVED_FROM_P (TYPE_CONTEXT (scope), object_type))
@@ -2812,11 +2818,6 @@ finish_class_member_access_expr (cp_expr
 	  return error_mark_node;
 	}
 	}
-  else
-	{
-	  scope = NULL_TREE;
-	  access_path = object_type;
-	}
 
   if (TREE_CODE (name) == BIT_NOT_EXPR)
 	{
Index: testsuite/g++.dg/template/pr71406.C
===
--- testsuite/g++.dg/template/pr71406.C	(revision 0)
+++ testsuite/g++.dg/template/pr71406.C	(working copy)
@@ -0,0 +1,28 @@
+// { dg-do compile }
+// PR c++/71406 ICE with X::template Name
+
+template < typename T >
+struct C : T
+{
+  void foo () { this->C::template bar <>; }
+};
+
+template < typename T >
+struct A
+{ 
+  template < void (T::*Fn) () > void f () {}
+};
+
+template < typename T > struct B : A < B < T > >
+{ 
+  void g ()
+  { 
+this->B::template f < &B < T >::g > ();
+  }
+};
+
+void Foo ()
+{ 
+  B < int > b;
+  b.g ();
+}

Re: [RFC] fix bootstrap on aarch64-*-freebsd and probably others

[Richard Earnshaw (lists)]

On 23/01/17 18:00, Andreas Tobler wrote:
> On 23.01.17 18:48, Jakub Jelinek wrote:
>> On Mon, Jan 23, 2017 at 06:42:15PM +0100, Andreas Tobler wrote:
>>> Something like below?
>>>
>>> If ok, I can commit, right?
>>>
>>> Thanks,
>>>
>>> Andreas
>>>
>>> 2017-01-23  Andreas Tobler  
>>>
>>> * config/aarch64/aarch64.c (aarch64_elf_asm_constructor): Increase
>>> size of buf.
>>> (aarch64_elf_asm_destructor): Likewise.
>>> --- config/aarch64/aarch64.c(revision 244819)
>>> +++ config/aarch64/aarch64.c(working copy)
>>> @@ -5787,7 +5787,11 @@
>>>else
>>>  {
>>>section *s;
>>> -  char buf[18];
>>> +  /* The size of the buf must be big enough to hold the string
>>> and the
>>> + full integer size of priority. Otherwise we will get a warning
>>> + about format-truncation.
>>> +  */
>>
>> Please put the */ on the same line as about format-truncation, like:
>>  about format-truncation.  */
>> After . there should be 2 spaces rather than one.
>> Also, the comment doesn't tell the truth, the buffer doesn't have to
>> be that
>> big, because we know priority is bounded, just the compiler doesn't know
>> that.  So perhaps:
>>   /* While priority is known to be in range [0, 65535], so 18 bytes
>>  would be enough, the compiler might not know that.  To avoid
>>  -Wformat-truncation false positive, use a larger size.  */
>>   char buf[23];
>> or so?
> 
> 
> Danke.
> 
> Andreas
> 
> 2017-01-23  Andreas Tobler  
> 
> * config/aarch64/aarch64.c (aarch64_elf_asm_constructor): Increase
> size of buf.
> (aarch64_elf_asm_destructor): Likewise.
> 

OK.

Contents of PO file 'cpplib-7.1-b20170101.da.po'

[Translation Project Robot]

cpplib-7.1-b20170101.da.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.

New Danish PO file for 'cpplib' (version 7.1-b20170101)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'cpplib' has been submitted
by the Danish team of translators.  The file is available at:

http://translationproject.org/latest/cpplib/da.po

(This file, 'cpplib-7.1-b20170101.da.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

http://translationproject.org/latest/cpplib/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

http://translationproject.org/domain/cpplib.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

Re: [PATCH] Fix PR78189

[Christophe Lyon]

Hi Nick,

On 23 January 2017 at 10:04, Richard Biener  wrote:
> On Fri, 20 Jan 2017, Nick Clifton wrote:
>
>> Hi Guys,
>>
>>   [I have been asked to look at this PR in the hopes that it can be
>>   fixed soon and so no longer act as a blocker for the gcc 7 branch].
>>
>>   It seems to me that Richard's proposed patch does work:
>>
>> https://gcc.gnu.org/ml/gcc-patches/2016-11/msg00909.html
>>
>>   The only problem is that the check_effective_target_vect_hw_misalign
>>   proc is always returning 0 (or false) for ARM, even when unaligned
>>   vectors are supported.  This is why Richard's patch introduces a new
>>   failure for the arm-* targets.
>>
>>   So what I would like to suggest is an extended patch (attached) which
>>   also updates the check_effective_target_vect_hw_misalign proc to use
>>   the check_effective_target_arm_vect_no_misalign proc.  With this patch
>>   applied not only does the gcc.dg/vect/vect-strided-a-u8-i2-gap.c test
>>   for both big-endian and little-endian arm targets, but there is also a
>>   significant reduction in the number of failures in the gcc.dg/vect
>>   tests overall:
>>
>>Little Endian ARM:
>> < # of expected passes3275
>> < # of unexpected failures63
>> < # of unexpected successes   125
>> < # of expected failures  123
>> < # of unsupported tests  153
>> ---
>> > # of expected passes3448
>> > # of unexpected failures2
>> > # of unexpected successes   14
>> > # of expected failures  131
>> > # of unsupported tests  151
>>
>>   Big Endian ARM:
>> < # of expected passes2995
>> < # of unexpected failures269
>> < # of unexpected successes   21
>> < # of expected failures  128
>> ---
>> > # of expected passes3037
>> > # of unexpected failures127
>> > # of unexpected successes   24
>> > # of expected failures  228
>>
>>   Which looks like a win to me.  So - any objections to my applying this
>>   patch and then closing the PR ?
>
> Ok.
>

I must be missing something, but I see many regressions since you
committed this patch (r244796).
See
http://people.linaro.org/~christophe.lyon/cross-validation/gcc/trunk/244796/report-build-info.html
for more details.

In short, on arm-*,
  gcc.dg/vect/vect-strided-a-u8-i2-gap.c -flto -ffat-lto-objects
scan-tree-dump-times vect "vectorized 1 loops" 1
  gcc.dg/vect/vect-strided-a-u8-i2-gap.c scan-tree-dump-times vect
"vectorized 1 loops" 1
now FAIL instead of PASS.

on armeb, there are many more differences.

Christophe


> Thanks,
> Richard.
>
>> Cheers
>>   Nick
>>
>> gcc/ChangeLog
>> 2017-01-20  Richard Biener  
>>   Nick Clifton  
>>
>>   PR testsuite/78421
>>   * lib/target-supports.exp (check_effective_target_vect_hw_misalign):
>>   If the target is ARM return the result of the
>>   check_effective_target_arm_vect_no_misalign proc.
>>   * gcc.dg/vect/vect-strided-a-u8-i2-gap.c: If the target does not
>>   support unaligned vectors then only expect one of the loops to be
>>   unrolled.
>>
>>
>
> --
> Richard Biener 
> SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 
> 21284 (AG Nuernberg)

Re: [patch, fortran] Warn about integer**(negative integer)

[Thomas Koenig]

Hi FX,


The idea seems reasonable, but I am not sure about the wording
(“truncated” in particular).  “Integer exponentiation truncated
to constant 0”? Why not “Negative integer exponent has result
value zero”?

Other than that, OK to commit.



You're right, the error message was a bit strange.  Here is the
version of the patch I committed with corresponding change in the
test case.

Regards

Thomas


Index: fortran/arith.c
===
--- fortran/arith.c (Revision 244747)
+++ fortran/arith.c (Arbeitskopie)
@@ -874,6 +874,10 @@ arith_power (gfc_expr *op1, gfc_expr *op2, gfc_exp
  {
/* if op2 < 0, op1**op2 == 0  because abs(op1) > 1.  */
mpz_set_si (result->value.integer, 0);
+   if (warn_integer_division)
+ gfc_warning_now (OPT_Winteger_division, "Negative 
" 


+  "exponent of integer has zero "
+  "result at %L", &result->where);
  }
else if (gfc_extract_int (op2, &power))
  {

Re: [PATCH 2/5] remove unused member (PR 78703)

[Jeff Law]

On 01/22/2017 04:52 PM, Martin Sebor wrote:

The attached simple patch removes the format_result::constant member
that is not used except in debugging dumps.  Removing it makes
the handling of non-constant arguments simpler.  Since this handling
increases in the substantive changes that follow this change reduces
the complexity of those changes.

In addition, this change simplifies the try_substitute_return_value
function to make the logic that controls the sprintf return value
optimization clearer.  This change also benefits the subsequent
patches by simplifying the necessary changes.

Neither of these changes affects the tests.

gcc-78703-2.diff


commit 3802ab59aec722b25e9be85a0748138ef89e4aec
Author: Martin Sebor 
Date:   Fri Jan 20 14:26:47 2017 -0700

2017-01-20  Martin Sebor  

* gimple-ssa-sprintf.c (struct format_result): Remove constant member.
(struct fmtresult, format_integer, format_floating): Adjust.
(get_string_length, format_string,format_directive): Same.
(pass_sprintf_length::compute_format_length): Same.
(try_substitute_return_value): Simplify slightly.

diff --git a/gcc/gimple-ssa-sprintf.c b/gcc/gimple-ssa-sprintf.c
index 3464b45..38412b0 100644
--- a/gcc/gimple-ssa-sprintf.c
+++ b/gcc/gimple-ssa-sprintf.c
@@ -465,11 +458,10 @@ struct fmtresult
   : argmin (), argmax (),
 knownrange (min < HOST_WIDE_INT_MAX && max < HOST_WIDE_INT_MAX),
 bounded (),
-constant (),
 nullp ()
   {
 range.min = min;
-range.max = min;
+range.max = max;
   }

Yow!  Probably deserves a mention in the ChangeLog.




@@ -2866,42 +2840,71 @@ try_substitute_return_value (gimple_stmt_iterator *gsi,
 const pass_sprintf_length::call_info &info,
 const format_result &res)
 {
+  if (!res.bounded)
+return false;
+
   tree lhs = gimple_get_lhs (info.callstmt);

+  /* Set to true when the entire call has been removed.  */
+  bool removed = false;
+
+  /* The minumum return value.  */

s/minumum/minimum/

OK with those nits fixed.  Like the prior patch, if this has been 
bootstrapped and regression tested, then go ahead and install it now 
rather than waiting.


jeff

Re: [PATCH 3/5] simply handling of -Wformat-overflow/truncation options (PR 78703)

[Jeff Law]

On 01/22/2017 04:53 PM, Martin Sebor wrote:

The attached patch is the last of the refactoring/restructuring
series.  It consists of the following changes:

1) Introduce a single global variable, warn_level, that the pass
uses to test the level of the warning that applies to the function
currently being processed (i.e., either -Wformat-overflow or
-Wformat-truncation).

2) Slightly adjust the format_integer function in preparation for
the upcoming substantive changes.

3) Factor code responsible for issuing per-directive warnings out
of format_directive and into a function of its own, maybe_warn.
This also simplifies the upcoming extensive changes in this area
but more importantly, should make them easier to review by
grouping warnings in the same function.

4) Enhance information printed in debugging dumps.

gcc-78703-3.diff


commit d1a41d89a3b359e63937e87c619314ccd33562c5
Author: Martin Sebor 
Date:   Fri Jan 20 17:26:56 2017 -0700

2017-01-20  Martin Sebor  

* gimple-ssa-sprintf.c (warn_level): New global.
(format_integer): Use it here and throughout the rest of the file.
Use the same switch to compute sign as base.
(maybe_warn): New function.
(format_directive): Factor out warnings into maybe_warn.
Add debugging output.  Use warn_level.
(add_bytes): Use warn_level.
(pass_sprintf_length::compute_format_length): Add debugging output.
(try_substitute_return_value): Same.
(pass_sprintf_length::handle_gimple_call): Set and use warn_level.
OK.  As with prior patches, go ahead and install now if it's been 
bootstrapped and regression tested.


jeff

Re: [libcc1] add support for C++

[Jason Merrill]

On Sun, Jan 22, 2017 at 6:06 PM, Alexandre Oliva  wrote:
> On Jan 13, 2017, Jason Merrill  wrote:
>
>> On 09/23/2016 08:41 PM, Alexandre Oliva wrote:
>>> +static tree global_friend_list;
>
>> This should be a hash_set rather than a TREE_LIST.
>
> You sure?  At least in the libcc1 use scenario, this is going to have a
> single entry.  I didn't even have to make it a list, but I made it one
> because, well, I could :-)  A hash_set seems excessive, unless you
> envision other uses for it.

Well, in general TREE_LISTs are discouraged nowadays in favor of
hash_sets or VECs.  If it's a single entry, putting it there alone is
fine too.

>>> +  // FIXME: we need a more space-efficient representation for
>>> +  // oracle_looked_up.
>
>> A hash_set would work for that, too.
>
> I was hoping for an unused bit in IDENTIFIERs, but I guess that will do.
> I'm a bit concerned about the performance impact of this in all name
> lookups, though.  Just computing the hash for every lookup seems
> excessive, compared with testing a bit.  Unless...  I guess making it a
> hash_set*, NULL unless there is an Oracle, would alleviate this concern,
> making it cost only when it's in use.

Sounds good.

>>> +/* Exported wrapper for cp_literal_operator_id.  */
>>> +
>>> +tree
>>> +ansi_litopname (const char *name)
>>> +{
>>> +  return cp_literal_operator_id (name);
>>> +}
>
>> Why not export cp_literal_operator_id itself?
>
> My sense of aesthetics demanded a uniform set of exported names along
> with ansi_opname and ansi_assopname ;-)

Heh.  But I'd prefer to unify them in the other direction; use of
"ansi" is obsolete.

>>> +   If the newly-created namespace is to be an inline namespace, after
>>> +   push_namespace, get the nested namespace decl with
>>> +   get_current_binding_level, pop back to the enclosing namespace,
>>> +   call using_namespace with INLINE_P, and then push to the inline
>>> +   namespace again.  */
>
>> This seems like unnecessary contortions to expect of the caller
>> (i.e. GDB).  Let's add a new front end function to handle this.
>
> Heh, it's really nothing compared with some other contortions required
> to navigate binding levels, e.g. to reenter a function scope.
>
> I didn't want to add redundant functionality to the libcc1 API, and we'd
> need the ability to separate the introduction or reentry in a namespace,
> from a using directive with attribute strong.  And since inline
> namespaces use the same implementation as that, I figured it made sense
> to use the same interface for both.

> Besides, push_namespace is called a lot more often than using_namespace,
> so it makes sense to keep it simpler, and leave the extra parameter for
> the less common operation.
>
> Another argument to keep things as they are is that the inline-ness of a
> namespace is not a property related with entering the namespace, but
> rather with how names from it are brought into the other namespace.

Well, it's a property of the namespace.  But I guess I won't insist on this.

>>> + As a general rule, before we can declare or define any local name
>>> + with a discriminator, we have to at least declare any other
>>> + occurrences of the same name in the same enclosing entity with
>>> + lower or absent discriminator.
>
>> This seems unfortunate, wouldn't it be better to allow the plugin to
>> specify the discriminator directly?
>
> That would have required a major reworking of the internal handling of
> such discriminators, and it didn't seem worth the effort and risk of
> pushback, considering that libcc1 already requires all occurrences of a
> name to be defined at once.

Fair enough.

>>> +   Just entering the scope of the class containing member function f
>>> +   reactivates the names of its members, including the class name
>>> +   itself.  */
>
>> Does it reactivate the names of other declarations in scope in the
>> enclosing function, e.g. static local variables?
>
> My understanding is that anything local needs explicit reactivation when
> reentering a function scope.  That makes sense and is helpful for us,
> given that a local scope is not always a single scope; unlike namespace
> and class scopes, there could be multiple scopes within a function
> scope, and each would have a different set of active names.  The client
> has to select the active names upon function reentry.

OK.

>>> +/* Pop the namespace last entered with push_namespace, or class last
>>> +   entered with push_class, or function last entered with
>>> +   push_function, restoring the binding level in effect before the
>>> +   matching push_* call.  */
>>> +
>>> +GCC_METHOD0 (int /* bool */, pop_namespace)
>
>> This should have a different name, perhaps pop_last_entered_scope?
>
> It was introduced very early on, long before the need for exposing
> function scopes was realized and implemented.  GDB (branch) already had
> plenty of code using this primitive, so I didn't want to rename it, but
> if you insist in such spelling changes, I won

Re: [C++ PATCH] 71406, 77508 scoped template_ids

[Jason Merrill]

OK.

On Mon, Jan 23, 2017 at 1:53 PM, Nathan Sidwell  wrote:
> This patch fixes 71406 and 77508, which are both ICEs dealing with
> 'X::Foo<...>'.  finish_class_member_access_expr wasn't prepared to handle
> SCOPE_REF (TEMPLATE_ID_EXPR (...)), which is what it was being fed.  Fixed
> by moving the SCOPE_REF splitting to before the TEMPLATE_ID_EXPR handling,
> but leaving the scope checking where it was.
>
> ok?
>
> nathan
> --
> Nathan Sidwell

Re: [c== pATCH] 71710 dependent FIELD_DECL

[Jason Merrill]

On Mon, Jan 23, 2017 at 12:09 PM, Nathan Sidwell  wrote:
> Jason,
> Bug 71710 is a crash on 'decltype (a)', where 'a' is a FIELD_DECL wth
> dependent type.  finish_class_member_access_expr barfs on that.  The earlier
> sequence of if..elses has a check for FIELD_DECL, but that's in the shadow
> of a type_dependent_expression_p (object) check.  The field's type is the
> main template type, so it does have a type dependent object.  But there's no
> reason it shouldn't go through the usual finish_non_static_data_member
> processing.

The issue is that we want to allow cases where the object type is the
current instantiation.

> Fixed by moving the FIELD_DECL check earlier.

...but this ought to handle that case fine, since the current
instantiation is when we will have successfully found a FIELD_DECL.

OK.

Jason

Re: [C++ Patch/RFC] PR 72764

[Jason Merrill]

On Mon, Jan 23, 2017 at 11:15 AM, Paolo Carlini
 wrote:
> in this relatively serious ICE on invalid regression (we don't emit any
> message before ICEing) make_typename_type, called by strip_typedefs, returns
> error_mark_node which then isn't handled by typedef_variant_p. Indeed, Jakub
> noticed that the same in principle can happen when strip_typedefs calls
> finish_decltype_type. make_typename_type is passed tf_none therefore cannot
> emit the diagnostic we want before the ICE anyway, thus it seems to me that
> we also have one of those well known issues about not propagating a
> tusbst_flags_t flag: canonicalize_type_argument (and
> canonicalize_expr_argument) get a tusbst_flags_t but doesn't propagate it to
> strip_typedefs (and strip_typedefs_expr).
>
> Implementing the straightforward set of changes, consistently for
> strip_typedefs, strip_typedefs_expr and the related functions plus checking
> the return values of make_typename_type and finish_decltype_type for
> error_mark_node (only make_typename_type would be enough for the testcase at
> issue) appears to solve the problem without introducing regressions. Does
> that make sense?

Hmm.  How did we get the typedef in the first place to a type that we
can't reconstruct?  I would think that instantiating C should
give an error before we get to strip_typedefs.

Jason

[PATCH] -fsanitize=address,undefined support on s390x

[Jakub Jelinek]

On Mon, Jan 23, 2017 at 04:10:01PM +0100, Ulrich Weigand wrote:
> Bill Schmidt wrote:
> > On Jan 23, 2017, at 8:32 AM, Jakub Jelinek  wrote:
> > >
> > > Another question is, it seems upstream has s390{,x}-*-linux* support for
> > > asan/ubsan, does that work?  In that case we should add it to 
> > > configure.tgt
> > > too (similarly to the sparc*-*-linux* entry).
> > 
> > CCing Uli for the s390 question.
> 
> Asan support was added just recently to LLVM for s390x-linux.  However,
> I'm not sure it will work out-of-the-box on GCC, since we haven't done any
> back-end work to enable it.  Also, LLVM is 64-bit only, so there probably
> would have to be extra work in the libraries to enable 31-bit mode.

So, I've bootstrapped/regtested s390x-linux (64-bit only, don't have 32-bit
userland around anymore to test 31-bit) with the attached patch (and on top
of the PR79168 patch I'll post soon) and the
only regressions I got are:
FAIL: c-c++-common/asan/null-deref-1.c   {-O2,-O2 -flto -fno-use-linker-plugin 
-flto-partition=none,-O2 -flto -fuse-linker-plugin -fno-fat-lto-objects,-O3 
-g,-Os}  output pattern test
FAIL: g++.dg/asan/deep-stack-uaf-1.C   {-O0,-O1,-O2,-O3 -g,-Os}  output pattern 
test
FAIL: c-c++-common/ubsan/overflow-vec-1.c   {-O0,-O1,-O2,-O2 -flto 
-fno-use-linker-plugin -flto-partition=none,-O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects,-O3 -g,-Os}  execution test
FAIL: c-c++-common/ubsan/overflow-vec-2.c   {-O0,-O1,-O2,-O2 -flto 
-fno-use-linker-plugin -flto-partition=none,-O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects,-O3 -g,-Os}  execution test
All but deep-stack-uaf-1.C in both check-gcc and check-g++.

In null-deref-1.c it seems the problem is in the line for the deref,
the testcase is expecting runtime error on line 10, while
#0 0x8a6d in NullDeref c-c++-common/asan/null-deref-1.c:11  
   
#1 0x88f1 in main c-c++-common/asan/null-deref-1.c:15   
   
#2 0x3ff93022c5f in __libc_start_main (/lib64/libc.so.6+0x22c5f)
   
#3 0x896d  
(gcc-7.0.1-20170120/obj-s390x-redhat-linux/gcc/testsuite/g++/null-deref-1.exe+0x896d)
   
is reported.
The second test fails
ERROR: AddressSanitizer: heap-use-after-free on address 0x61500205 at pc 
0x8b12 bp 0x03fff8378928 sp 0x03fff8378918   
READ of size 1 at 0x61500205 thread T0  
   
#0 0x8b11 in main g++.dg/asan/deep-stack-uaf-1.C:33 
   
#1 0x3ffabe22c5f in __libc_start_main (/lib64/libc.so.6+0x22c5f)
   
#2 0x89cd  
(gcc-7.0.1-20170120/obj-s390x-redhat-linux/gcc/testsuite/g++/deep-stack-uaf-1.exe+0x89cd)
will need to debug if we don't need to add further options on s390x to
make sure it has all the frames it is expecting.
The last 2 tests aren't really asan related, will debug.

Note apparently asan_test.C isn't enabled on non-i?86/x86_64, which
is a big mistake, will try to change it separately.

2017-01-23  Jakub Jelinek  

gcc/
* config/s390/s390.c (s390_asan_shadow_offset): New function.
(TARGET_ASAN_SHADOW_OFFSET): Redefine.
libsanitizer/
* configure.tgt: Enable asan and ubsan on 64-bit s390*-*-linux*.

--- gcc/config/s390/s390.c.jj   2017-01-19 16:58:25.0 +0100
+++ gcc/config/s390/s390.c  2017-01-23 16:32:28.220398187 +0100
@@ -15435,6 +15435,14 @@ s390_excess_precision (enum excess_preci
   return FLT_EVAL_METHOD_UNPREDICTABLE;
 }
 
+/* Implement the TARGET_ASAN_SHADOW_OFFSET hook.  */
+
+static unsigned HOST_WIDE_INT
+s390_asan_shadow_offset (void)
+{
+  return TARGET_64BIT ? HOST_WIDE_INT_1U << 52 : HOST_WIDE_INT_UC (0x2000);
+}
+
 /* Initialize GCC target structure.  */
 
 #undef  TARGET_ASM_ALIGNED_HI_OP
@@ -15536,6 +15544,8 @@ s390_excess_precision (enum excess_preci
 #define TARGET_BUILD_BUILTIN_VA_LIST s390_build_builtin_va_list
 #undef TARGET_EXPAND_BUILTIN_VA_START
 #define TARGET_EXPAND_BUILTIN_VA_START s390_va_start
+#undef TARGET_ASAN_SHADOW_OFFSET
+#define TARGET_ASAN_SHADOW_OFFSET s390_asan_shadow_offset
 #undef TARGET_GIMPLIFY_VA_ARG_EXPR
 #define TARGET_GIMPLIFY_VA_ARG_EXPR s390_gimplify_va_arg
 
--- libsanitizer/configure.tgt.jj   2017-01-23 15:25:21.0 +0100
+++ libsanitizer/configure.tgt  2017-01-23 15:36:40.787456320 +0100
@@ -39,6 +39,11 @@ case "${target}" in
;;
   sparc*-*-linux*)
;;
+  s390*-*-linux*)
+   if test x$ac_cv_sizeof_void_p = x4; then
+   UNSUPPORTED=1
+   fi
+   ;;
   arm*-*-linux*)
;;
   aarch64*-*-linux*)


  

Re: [PATCH 5/5] add support for width and precision ranges (PR 78703)

[Jeff Law]

On 01/22/2017 04:53 PM, Martin Sebor wrote:

This is the last patch in the series.  It adds logic to handle
non-constant width and precision with range information to help
reduce both false positives false negatives.  The patch replaces
the scalar width and precision with two element arrays throughout
the pass and makes adjustments to reflect their bounds in the byte
counters.  Since the basic infrastructure for this is present in
the code the changes are fairly mechanical.

gcc-78703-5.diff


commit c0a1f67fedb531abaf4760e8cd5b9b037ef5d4c4
Author: Martin Sebor 
Date:   Sun Jan 22 12:37:33 2017 -0700

2017-01-22  Martin Sebor  

* gimple-ssa-sprintf.c (adjust_for_width_or_precision): Change
to accept adjustment as an array.
(get_int_range): New function.
(struct directive): Make width and prec arrays.
(directive::set_width, directive::set_precision): Call get_int_range.
(format_integer, format_floating): Handle width and precision ranges.
(format_string, parse_directive): Same.

gcc/testsuite:
* gcc.dg/tree-ssa/builtin-snprintf-warn-1.c: Update
* gcc.dg/tree-ssa/builtin-sprintf-warn-9.c: Rename...
* gcc.dg/tree-ssa/builtin-sprintf-warn-10.c: ...to this.
* gcc.dg/tree-ssa/builtin-sprintf-warn-9.c: New test.
I'm still working on #4, which is still fairly large.  I needed to step 
away from it for a bit.


Regardless #5 is OK.

Jeff

Re: [PATCH] Fix PR79088/79188

[Jeff Law]

On 01/23/2017 06:17 AM, Richard Biener wrote:


The following is a fix for jump-threading loop-assumption clearing
which was done only on the first header/irreducible crossing rather
than the one at the destination of the threading path.

Bootstrapped and tested on x86_64-unknown-linux-gnu, ok for trunk?

Thanks,
Richard.

2017-01-23  Richard Biener  

PR tree-optimization/79088
PR tree-optimization/79188
* tree-ssa-threadupdate.c (mark_threaded_blocks): Move code
resetting loop bounds after last path deletion.  Reset loop
bounds of the target loop, make code match the comments.
* tree-ssa-threadbackwards.c (pass_early_thread_jumps::execute):
Make sure loops need no fixups.

* gcc.dg/torture/pr79088.c: New testcase.
* gcc.dg/torture/pr79188.c: Likewise.

OK.  If you don't commit it today, I likely will.

Thanks,
Jeff

Re: [C++ PATCH] 79118 bitfields & constexpr

[Jason Merrill]

On Mon, Jan 23, 2017 at 8:49 AM, Nathan Sidwell  wrote:
> This patch addresses 79118, where we ICE on a constexpr involving bitfields
> in an unnamed struct (unnamed struct members are a g++ extension).
>
> This is really a band-aid, because our internal representation BITFIELD_REF
> and the (premature) optimizations it encourages is incompatible with
> constexpr requirements.  There's already signs of that with Jakub's code to
> deal with fold turning things like:
>   int foo: 5;
>   int baz: 3;
> ...
>   ptr->baz == cst
> turns into the moral equivalent of (little endian example)
>   ((*(unsigned char *)ptr & 0xe0) == (cst << 5)
>
> In this particular case we've also made the base object the containing
> class, not the unnamed struct member.  That means we're looking in the wrong
> CONSTRUCTOR and see CONSTRUCTOR_NO_IMPLICIT_ZERO is true.  Whereas for the
> subobj's CONSTRUCTOR it is false.

Why is it false?

> With this patch we end up thinking this
> is an OK constexpr of value zero, whereas it's actually an uninitialized
> bitfield read.
>
> But I think we could already make that mistake given the above example &
> fold's behaviour.  If 'ptr->foo' has been initialized, we'll construct a
> value using just that field and think we have a valid initialization of
> ptr->baz too.
>
> The equivalent testcase using non-bitfields has a base object of the unnamed
> struct member, and behaves correctly (given this is an extension anyway).
>
> The right solution is to fix the IR.  In the C++ FE have BITFIELD_REF (or a
> new node) look much more like COMPONENT_REF (or even be COMPONENT_REF, but I
> suspect lots of places think ADDR (COMPONENT_REF (...)) is legit).  And
> lower it to the middle-end generic representation in cp_genericize.  I don't
> think this is the right time for a change of that magnitude though.

Yes, for this and other reasons we should do constexpr evaluation on
the pre-genericized trees.

> Perhaps for now we should just always err on the side of safety, and behave
> as-if uninitialized if we fall of the end of looking for a bitfield?

That makes sense.

Jason

Re: [C++ PATCH] 79118 bitfields & constexpr

[Jakub Jelinek]

On Mon, Jan 23, 2017 at 04:06:22PM -0500, Jason Merrill wrote:
> > The right solution is to fix the IR.  In the C++ FE have BITFIELD_REF (or a
> > new node) look much more like COMPONENT_REF (or even be COMPONENT_REF, but I
> > suspect lots of places think ADDR (COMPONENT_REF (...)) is legit).  And
> > lower it to the middle-end generic representation in cp_genericize.  I don't
> > think this is the right time for a change of that magnitude though.
> 
> Yes, for this and other reasons we should do constexpr evaluation on
> the pre-genericized trees.

Maybe even pre-cp_folded.

Jakub

Re: A + B CMP A -> A CMP' CST' match.pd patterns [was [PATCH] avoid calling memset et al. with excessively large sizes (PR 79095)]

[Jeff Law]

On 01/23/2017 02:10 AM, Richard Biener wrote:


I think it was added for the reason stated in the comment:

/* When one argument is a constant, overflow detection can be simplified.
   Currently restricted to single use so as not to interfere too much with
   ADD_OVERFLOW detection in tree-ssa-math-opts.c.
   A + CST CMP A  ->  A CMP' CST' */
(for cmp (lt le ge gt)
 out (gt gt le le)
 (simplify
  (cmp:c (plus@2 @0 INTEGER_CST@1) @0)
  (if (TYPE_UNSIGNED (TREE_TYPE (@0))
   && TYPE_OVERFLOW_WRAPS (TREE_TYPE (@0))
   && wi::ne_p (@1, 0)
   && single_use (@2))
   (out @0 { wide_int_to_tree (TREE_TYPE (@0), wi::max_value
   (TYPE_PRECISION (TREE_TYPE (@0)), UNSIGNED) - @1); }


Certainly the easiest thing to do is remove the single use restriction. If
we ultimately don't want to do that, we can probably detect when the
transformation will allow the conditional to be eliminated in VRP and I
would claim that elimination of the conditional at compile time trumps the
other potential concerns here.  That's going to be uglier and essentially
duplicate parts of what match.pd does, but certainly doable -- I've even
prototyped it.


Yeah, duplicating that sounds ugly.
So one possibility is to put an additional if case in the code above 
without the single_use condition which fires iff we're turning the two 
operand relational into a zero/not-zero test.


The only problem is that doesn't manage to clean things up until dom3. 
We could instead have them cleaned up by dom2 if the tweak is in VRP. 
This is because we don't call the gimple folders on the statement until 
after dom2 is already complete.


So there's 10 blocks of crud in the IL for the 40 passes between dom2 
and dom3.  And FWIW, this shows up a hundred times or so during a GCC 
bootstrap.  I haven't looked to see how many of those result in just a 
simplified test vs those with nice secondary optimizations like we see 
with the test in the BZ.





But undoing it for the sake of detecting overflow builtins is as well (OTOH
nothing does the reverse transform so if the user wrote the "simplified"
variant we don't detect overflow either).
I'm not sure there'd be enough information left to undo the 
transformation, even if it were restricted to the zero/not-zero 
resulting test.


Jeff

Re: [C++ PATCH] 79118 bitfields & constexpr

[Jason Merrill]

On Mon, Jan 23, 2017 at 4:13 PM, Jakub Jelinek  wrote:
> On Mon, Jan 23, 2017 at 04:06:22PM -0500, Jason Merrill wrote:
>> > The right solution is to fix the IR.  In the C++ FE have BITFIELD_REF (or a
>> > new node) look much more like COMPONENT_REF (or even be COMPONENT_REF, but 
>> > I
>> > suspect lots of places think ADDR (COMPONENT_REF (...)) is legit).  And
>> > lower it to the middle-end generic representation in cp_genericize.  I 
>> > don't
>> > think this is the right time for a change of that magnitude though.
>>
>> Yes, for this and other reasons we should do constexpr evaluation on
>> the pre-genericized trees.
>
> Maybe even pre-cp_folded.

Definitely.  I think of that as being part of genericization.

Jason