[PATCH] Fix PR71264 testcase

[Richard Biener]

As noted in the PR I have some local changes that seem to help.

Committed.

Richard.

2017-01-13  Richard Biener  

PR middle-end/78411
* gcc.target/i386/pr45685.c: Add -ftree-loop-if-convert.

Index: gcc/testsuite/gcc.target/i386/pr45685.c
===
--- gcc/testsuite/gcc.target/i386/pr45685.c (revision 244393)
+++ gcc/testsuite/gcc.target/i386/pr45685.c (working copy)
@@ -1,5 +1,5 @@
 /* { dg-do compile { target { ! ia32 } } } */
-/* { dg-options "-O3 -mno-sse4" } */
+/* { dg-options "-O3 -mno-sse4 -ftree-loop-if-convert" } */
 
 typedef unsigned long long int uint64_t;
 typedef long long int int64_t;

Re: [PATCH, v2] (9e) Update "startwith" logic for pass-skipping to handle __RTL functions

[Richard Biener]

On Thu, Jan 19, 2017 at 6:22 PM, David Malcolm  wrote:
> On Mon, 2017-01-16 at 14:42 -0700, Jeff Law wrote:
>> On 01/09/2017 07:38 PM, David Malcolm wrote:
>> > gcc/ChangeLog:
>> > * passes.c: Include "insn-addr.h".
>> > (should_skip_pass_p): Add logging.  Update logic for running
>> > "expand" to be compatible with both __GIMPLE and __RTL.  Guard
>> > property-provider override so it is only done for gimple
>> > passes.
>> > Don't skip dfinit.
>> > (skip_pass): New function.
>> > (execute_one_pass): Call skip_pass when skipping passes.
>> > ---
>> >  gcc/passes.c | 65
>> > +---
>> >  1 file changed, 58 insertions(+), 7 deletions(-)
>> >
>> > diff --git a/gcc/passes.c b/gcc/passes.c
>> > index 31262ed..6954d1e 100644
>> > --- a/gcc/passes.c
>> > +++ b/gcc/passes.c
>> > @@ -59,6 +59,7 @@ along with GCC; see the file COPYING3.  If not
>> > see
>> >  #include "cfgrtl.h"
>> >  #include "tree-ssa-live.h"  /* For remove_unused_locals.  */
>> >  #include "tree-cfgcleanup.h"
>> > +#include "insn-addr.h" /* for INSN_ADDRESSES_ALLOC.  */
>> insn-addr?  Yuk.
>>
>>
>> >
>> >  using namespace gcc;
>> >
>> > @@ -2315,26 +2316,73 @@ should_skip_pass_p (opt_pass *pass)
>> >if (!cfun->pass_startwith)
>> >  return false;
>> >
>> > -  /* We can't skip the lowering phase yet -- ideally we'd
>> > - drive that phase fully via properties.  */
>> > -  if (!(cfun->curr_properties & PROP_ssa))
>> > -return false;
>> > + /* For __GIMPLE functions, we have to at least start when we
>> > leave
>> > + SSA.  */
>> > +  if (pass->properties_destroyed & PROP_ssa)
>> > +{
>> > +  if (!quiet_flag)
>> > +   fprintf (stderr, "starting anyway when leaving SSA: %s\n",
>> > pass->name);
>> > +  cfun->pass_startwith = NULL;
>> > +  return false;
>> > +}
>> This seems to need a comment -- it's not obvious how destroying the
>> SSA
>> property maps to a pass that can not be skipped.
>
> Added:
>
>   /* For __GIMPLE functions, we have to at least start when we leave
>  SSA.  Hence, we need to detect the "expand" pass, and stop skipping
>  when we encounter it.  A cheap way to identify "expand" is it to
>  detect the destruction of PROP_ssa.
>  For __RTL functions, we invoke "rest_of_compilation" directly, which
>  is after "expand", and hence we don't reach this conditional.  */
>
>> > -  /* And also run any property provider.  */
>> > -  if (pass->properties_provided != 0)
>> > +  /* Run any property provider.  */
>> > +  if (pass->type == GIMPLE_PASS
>> > +  && pass->properties_provided != 0)
>> >  return false;
>> So comment needed here too.  I read this as "if a gimple pass
>> provides a
>> property then it should not be skipped.  Which means that an RTL pass
>> that provides a property can?
>
> Added:
>
>   /* For GIMPLE passes, run any property provider (but continue skipping
>  afterwards).
>  We don't want to force running RTL passes that are property providers:
>  "expand" is covered above, and the only pass other than "expand" that
>  provides a property is "into_cfglayout" (PROP_cfglayout), which does
>  too much for a dumped __RTL function.  */
>
> ...the problem being that into_cfglayout's execute vfunc calls
> cfg_layout_initialize, which does a lot more that just
> cfg_layout_rtl_register_cfg_hooks (the skip hack does just the latter).
>
>> > +  /* Don't skip df init; later RTL passes need it.  */
>> > +  if (strstr (pass->name, "dfinit") != NULL)
>> > +return false;
>> Which seems like a failing in RTL passes saying they need DF init.
>
> There isn't a "PROP_df"; should there be?
> Or is this hack accepable?
>
>> > +/* Skip the given pass, for handling passes before "startwith"
>> > +   in __GIMPLE and__RTL-marked functions.
>> > +   In theory, this ought to be a no-op, but some of the RTL passes
>> > +   need additional processing here.  */
>> > +
>> > +static void
>> > +skip_pass (opt_pass *pass)
>> ...
>> This all feels like a failing in how we handle state in the RTL
>> world.
>> And I suspect it's prone to error.  Imagine if I'm hacking on
>> something
>> in the RTL world and my code depends on something else being set up.
>>   I
>> really ought to have a way within my pass to indicate what I depend
>> on.
>> Having it hidden away in passes.c makes it easy to miss/forget.
>
> Indeed, it's a hack.  I preferred the vfunc idea, but Richi prefers
> to keep it all in one place.
>
>> > +{
>> > +  /* Pass "reload" sets the global "reload_completed", and many
>> > + things depend on this (e.g. instructions in .md files).  */
>> > +  if (strcmp (pass->name, "reload") == 0)
>> > +reload_completed = 1;
>> Seems like this ought to be a property provided by LRA/reload.
>
> If we have a __RTL function with a "startwith" of a pass after reload,
> we don't want to run "reload" when iterating through the pass list to
> reach the start pass, since presumably it coul

RE: [patch mips/gcc] add build-time and runtime options to disable or set madd.fmt type

[Matthew Fortune]

Moore, Catherine  writes:
> > -Original Message-
> > From: Matthew Fortune [mailto:matthew.fort...@imgtec.com]
> > Sent: Thursday, January 19, 2017 5:30 PM
> > To: Moore, Catherine 
> > Cc: 'Aurelien Jarno' ; 'Richard Sandiford'
> > ; Loosemore, Sandra
> > ; Yunqiang Su
> > ; 'gcc-patches' 
> > Subject: RE: [patch mips/gcc] add build-time and runtime options to
> > disable or set madd.fmt type
> >
> > Matthew Fortune  writes:
> > > I've rewritten/simplified this patch as it provides far too much
> > control
> > > to end users who will undoubtedly shoot themselves in the foot so to
> > > speak. The option I intend to support is simply --with-madd4 --
> > without-madd4
> > > and -mmadd4 -mno-madd4. This is a simple enable/disable on top of
> > > architecture checks to use/not use the madd4 family of instructions.
> > >
> > > We have to keep each of these unusual features simple so that we
> > can somehow
> > > reason about them in the future.
> > >
> >
> > Here is the tested patch.  Configure time default set/not set tested and
> > testsuite
> > fixes in place to deal with the fallout from running with the madd4
> > instructions
> > disabled.  Tests done with an o32 config on mips64el-linux-gnu.  If
> > there is any
> > other fallout from other test configurations I'll catch those as I try to
> > get the
> > rest of the testsuite issues resolved before release.
> >
> > Catherine, any issues to raise on this new option?
> 
> I committed this patch after fixing a couple of typos in the documentation 
> and ChangeLog
> entry.
> No other objections.
> Catherine

Thanks Catherine. I'll check to see what if/any documentation changes have gone 
in
without your review and send you a list in case you have time to review it 
before
release.

Thanks,
Matthew 

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

[Richard Biener]

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).

Those two passes could be used by a static analysis phase prior to
any optimization to emit warnings (just computing the lattice, not doing
any IL modification).

Richard.

> Thanks
> Martin

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

[Richard Biener]

On Thu, Jan 19, 2017 at 6:46 PM, Pekka Jääskeläinen  wrote:
> Hi Jakub and Richard,
>
> Attached is an updated BRIG FE patch which adds the HSAIL related
> builtins only internally in the BRIG FE. I didn't add LTO support as I
> believe it's not
> useful for BRIG FE due to it always inputting fully linked BRIGs and
> not mixing with
> other frontends.

So the #ifdef ENABLE_BRIG_FE shouldn't be needed anymore (nor the
configury for it).

Otherwise this looks ok to me then.

Thanks,
Richard.

> BR,
> Pekka
>
>
>
> On Mon, Jan 16, 2017 at 11:07 AM, Jakub Jelinek  wrote:
>> On Mon, Jan 16, 2017 at 09:46:43AM +0100, Richard Biener wrote:
>>> There are 187 of them (well, simple grep of DEF_HSAIL, so probably a bit 
>>> less).
>>> They aren't really documented but I guess that __hsail_bitmask_u64 for 
>>> example
>>> is really equivalent to sth like -1U >> n << m?  So I'm not sure why
>>> you have builtins
>>> like these represened as functions rather than as "expanded" code sequences?
>>>
>>> If that's the ones you are talking about having special target
>>> specific expansion.
>>>
>>> Note that builtins add to GCC startup times and if you don't expect
>>> people to enable
>>> BRIG then I wonder why you are submitting it for inclusion ;)
>>
>> I guess the question is when the DEF_HSAIL* builtins are actually needed.
>> If the FE is separate from the other FEs, I guess it would be enough to
>> define those builtins
>> 1) in the BRIG FE
>> 2) in tree-core.h
>> 3) in lto1 (only if any such builtin has been seen in the IL
>>
>> So, perhaps define DEF_HSAIL* just to DEF_BUILTIN_STUB in builtins.def
>> unless already defined, and override it in the BRIG FE where you create its
>> builtins, and then have some routine in the middle-end similar to
>> initialize_sanitizer_builtins which lazily initializes the DEF_HSAIL*
>> builtins during LTO reading if a call to any of the builtins in the hsail
>> range is noticed?
>>
>> Jakub

Re: [PATCH] Introduce --with-gcc-major-version-only configure option (take 2)

[Jakub Jelinek]

On Fri, Jan 20, 2017 at 12:12:17AM +0100, Matthias Klose wrote:
> On 19.01.2017 13:26, Jakub Jelinek wrote:
> > On Thu, Jan 19, 2017 at 01:13:14PM +0100, Franz Sirl wrote:
> >> Am 2017-01-12 um 21:16 schrieb Jakub Jelinek:
> >>> libmpx/
> >>>   * configure.ac: Add GCC_BASE_VER.
> >>>   * Makefile.am (gcc_version): Use @get_gcc_base_ver@ instead of cat to
> >>>   get version from BASE-VER file.
> >>>   * configure: Regenerated.
> >>
> >> Hi,
> >>
> >> it seems libmpx/configure.ac is missing the acx.m4 include, because there 
> >> is
> >> now a bare GCC_BASE_VER in the regenerated libmpx/configure.
> >>
> >> The attached patch seem to fix it, but I'm not good with autoconf.
> > 
> > Oops, sorry, dunno how this got unnoticed in my testing.
> > The include belongs to aclocal.m4 IMHO, I've committed this as obvious:
> 
> I think this is wrong. aclocal.m4 is an auto-generated file. why would be the
> one in libmpx special to patch directly?

While that is what I've done, apparently if I remove aclocal.m4 and run
PATH=~/autoconf-2.64/bin:~/automake-1.11.6/bin:$PATH aclocal -I .. -I ../config
I get exactly the same file.  Not so in liboffloadmic and libcilkrts, there
I've done the same thing, patching aclocal.m4 by hand, and got the order
differently from what aclocal does.

So here is what I've committed to fix this up:

2017-01-20  Jakub Jelinek  

PR other/79046
liboffloadmic/
* aclocal.m4: Regenerated.
* Makefile.in: Regenerated.
libcilkrts/
* aclocal.m4: Regenerated.
* Makefile.in: Regenerated.

--- liboffloadmic/aclocal.m4.jj 2017-01-17 10:28:40.975354196 +0100
+++ liboffloadmic/aclocal.m42017-01-20 09:20:19.425237914 +0100
@@ -988,11 +988,11 @@ AC_SUBST([am__tar])
 AC_SUBST([am__untar])
 ]) # _AM_PROG_TAR
 
+m4_include([../config/acx.m4])
 m4_include([../config/depstand.m4])
 m4_include([../config/lead-dot.m4])
 m4_include([../config/multi.m4])
 m4_include([../config/override.m4])
-m4_include([../config/acx.m4])
 m4_include([../libtool.m4])
 m4_include([../ltoptions.m4])
 m4_include([../ltsugar.m4])
--- liboffloadmic/Makefile.in.jj2017-01-17 10:28:41.611345693 +0100
+++ liboffloadmic/Makefile.in   2017-01-20 09:20:29.308107715 +0100
@@ -89,14 +89,14 @@ DIST_COMMON = ChangeLog $(srcdir)/Makefi
$(srcdir)/liboffloadmic_host.spec.in \
$(srcdir)/liboffloadmic_target.spec.in $(srcdir)/../depcomp
 ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
-am__aclocal_m4_deps = $(top_srcdir)/../config/depstand.m4 \
+am__aclocal_m4_deps = $(top_srcdir)/../config/acx.m4 \
+   $(top_srcdir)/../config/depstand.m4 \
$(top_srcdir)/../config/lead-dot.m4 \
$(top_srcdir)/../config/multi.m4 \
$(top_srcdir)/../config/override.m4 \
-   $(top_srcdir)/../config/acx.m4 $(top_srcdir)/../libtool.m4 \
-   $(top_srcdir)/../ltoptions.m4 $(top_srcdir)/../ltsugar.m4 \
-   $(top_srcdir)/../ltversion.m4 $(top_srcdir)/../lt~obsolete.m4 \
-   $(top_srcdir)/configure.ac
+   $(top_srcdir)/../libtool.m4 $(top_srcdir)/../ltoptions.m4 \
+   $(top_srcdir)/../ltsugar.m4 $(top_srcdir)/../ltversion.m4 \
+   $(top_srcdir)/../lt~obsolete.m4 $(top_srcdir)/configure.ac
 am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
$(ACLOCAL_M4)
 am__CONFIG_DISTCLEAN_FILES = config.status config.cache config.log \
--- libcilkrts/aclocal.m4.jj2017-01-17 10:28:40.741357325 +0100
+++ libcilkrts/aclocal.m4   2017-01-20 09:17:59.115089608 +0100
@@ -988,11 +988,11 @@ AC_SUBST([am__tar])
 AC_SUBST([am__untar])
 ]) # _AM_PROG_TAR
 
+m4_include([../config/acx.m4])
 m4_include([../config/depstand.m4])
 m4_include([../config/lead-dot.m4])
 m4_include([../config/multi.m4])
 m4_include([../config/override.m4])
-m4_include([../config/acx.m4])
 m4_include([../libtool.m4])
 m4_include([../ltoptions.m4])
 m4_include([../ltsugar.m4])
--- libcilkrts/Makefile.in.jj   2017-01-17 10:28:41.315349650 +0100
+++ libcilkrts/Makefile.in  2017-01-20 09:18:40.764539469 +0100
@@ -161,14 +161,14 @@ DIST_COMMON = $(srcdir)/include/internal
 @MAC_LINKER_SCRIPT_TRUE@am__append_2 = 
-Wl,-exported_symbols_list,$(srcdir)/runtime/mac-symbols.txt
 subdir = .
 ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
-am__aclocal_m4_deps = $(top_srcdir)/../config/depstand.m4 \
+am__aclocal_m4_deps = $(top_srcdir)/../config/acx.m4 \
+   $(top_srcdir)/../config/depstand.m4 \
$(top_srcdir)/../config/lead-dot.m4 \
$(top_srcdir)/../config/multi.m4 \
$(top_srcdir)/../config/override.m4 \
-   $(top_srcdir)/../config/acx.m4 $(top_srcdir)/../libtool.m4 \
-   $(top_srcdir)/../ltoptions.m4 $(top_srcdir)/../ltsugar.m4 \
-   $(top_srcdir)/../ltversion.m4 $(top_srcdir)/../lt~obsolete.m4 \
-   $(top_srcdir)/configure.ac
+   $(top_srcdir)/../libtool.m4 $(top_srcdir)/../ltoptions.m4 \
+   $(top_srcdir)/../ltsugar.m4 $(top_srcdir)/../ltversion.m4 \
+   $(top_srcdir)/../lt~obsolete.m4 $(top_srcdir)/configure.ac
 am__configure_deps = $(am__aclocal

[OBVIOUS] [PATCH] Fix --enable-gather-detailed-mem-stats

[Martin Liška]

Hi.

Fixing typo that breaks --enable-gather-detailed-mem-stats, where 
build_decl_stat really
expects memory report arguments.
Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.

Installed as r244686.
Martin
>From 34a4006c9eec67ee005b4c02c3553525376696e8 Mon Sep 17 00:00:00 2001
From: marxin 
Date: Thu, 19 Jan 2017 17:13:35 +0100
Subject: [PATCH] Fix --enable-gather-detailed-mem-stats

gcc/ChangeLog:

2017-01-19  Martin Liska  

	* read-rtl-function.c (function_reader::create_function): Use
	build_decl instread of build_decl_stat.
---
 gcc/read-rtl-function.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/gcc/read-rtl-function.c b/gcc/read-rtl-function.c
index c5cb3f7953f..9ef9610dde9 100644
--- a/gcc/read-rtl-function.c
+++ b/gcc/read-rtl-function.c
@@ -481,8 +481,7 @@ function_reader::create_function ()
   tree return_type = int_type;
   tree arg_types[3] = {int_type, int_type, int_type};
   tree fn_type = build_function_type_array (return_type, 3, arg_types);
-  tree fndecl = build_decl_stat (UNKNOWN_LOCATION, FUNCTION_DECL, fn_name,
- fn_type);
+  tree fndecl = build_decl (UNKNOWN_LOCATION, FUNCTION_DECL, fn_name, fn_type);
   tree resdecl = build_decl (UNKNOWN_LOCATION, RESULT_DECL, NULL_TREE,
 			 return_type);
   DECL_ARTIFICIAL (resdecl) = 1;
-- 
2.11.0

Re: [Ping~]Re: [5/5][libgcc] Runtime support for AArch64 return address signing (needs new target macros)

[Christophe Lyon]

Hi Jiong,

On 19 January 2017 at 15:46, Jiong Wang  wrote:
> Thanks for the review.
>
> On 19/01/17 14:18, Richard Earnshaw (lists) wrote:
>>
>>
>>>
>>>
>>> diff --git a/libgcc/unwind-dw2.c b/libgcc/unwind-dw2.c
>>> index
>>> 8085a42ace15d53f4cb0c6681717012d906a6d47..cf640135275deb76b820f8209fa51eacfd64c4a2
>>> 100644
>>> --- a/libgcc/unwind-dw2.c
>>> +++ b/libgcc/unwind-dw2.c
>>> @@ -136,6 +136,8 @@ struct _Unwind_Context
>>>  #define SIGNAL_FRAME_BIT ((~(_Unwind_Word) 0 >> 1) + 1)
>>>/* Context which has version/args_size/by_value fields.  */
>>>  #define EXTENDED_CONTEXT_BIT ((~(_Unwind_Word) 0 >> 2) + 1)
>>> +  /* Bit reserved on AArch64, return address has been signed with A key.
>>> */
>>> +#define RA_A_SIGNED_BIT ((~(_Unwind_Word) 0 >> 3) + 1)
>>
>>
>> Why is this here?   It appears to only be used within the
>> AArch64-specific header file.
>
>
> I was putting it here so that when we allocate the next general purpose bit,
> we
> know clearly that bit 3 is allocated to AArch64 already, and the new general
> bit
> needs to go to the next one.  This can avoid bit collision.
>
>>
>>> ...
>>>
>>> +/* Frob exception handler's address kept in TARGET before installing
>>> into
>>> +   CURRENT context.  */
>>> +
>>> +static void *
>>> +uw_frob_return_addr (struct _Unwind_Context *current,
>>> + struct _Unwind_Context *target)
>>> +{
>>> +  void *ret_addr = __builtin_frob_return_addr (target->ra);
>>> +#ifdef MD_POST_FROB_EH_HANDLER_ADDR
>>> +  ret_addr = MD_POST_FROB_EH_HANDLER_ADDR (current, target, ret_addr);
>>> +#endif
>>> +  return ret_addr;
>>> +}
>>> +
>>
>>
>> I think this function should be marked inline.  The optimizers would
>> probably inline it anyway, but it seems wrong for us to rely on that.
>
>
> Thanks, fixed.
>
> Does the updated patch looks OK to you know?
>
> libgcc/
>
> 2017-01-19  Jiong Wang  
>
>
> * config/aarch64/aarch64-unwind.h: New file.
> (DWARF_REGNUM_AARCH64_RA_STATE): Define.
> (MD_POST_EXTRACT_ROOT_ADDR): Define.
> (MD_POST_EXTRACT_FRAME_ADDR): Define.
> (MD_POST_FROB_EH_HANDLER_ADDR): Define.
> (MD_FROB_UPDATE_CONTEXT): Define.
> (aarch64_post_extract_frame_addr): New function.
> (aarch64_post_frob_eh_handler_addr): New function.
> (aarch64_frob_update_context): New function.
> * config/aarch64/linux-unwind.h: Include aarch64-unwind.h
> * config.host (aarch64*-*-elf, aarch64*-*-rtems*,
> aarch64*-*-freebsd*):
> Initialize md_unwind_header to include aarch64-unwind.h.
> * unwind-dw2.c (struct _Unwind_Context): Define "RA_A_SIGNED_BIT".
> (execute_cfa_program): Multiplex DW_CFA_GNU_window_save for
> __aarch64__.
> (uw_update_context): Honor MD_POST_EXTRACT_FRAME_ADDR.
> (uw_init_context_1): Honor MD_POST_EXTRACT_ROOT_ADDR.
> (uw_frob_return_addr): New function.
> (_Unwind_DebugHook): Use uw_frob_return_addr.
>

Since you committed this (r244673), GCC fails to build for AArch64:
/tmp/8132498_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libgcc/unwind-dw2.c:
In function 'execute_cfa_program':
/tmp/8132498_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libgcc/unwind-dw2.c:1193:17:
error: 'DWARF_REGNUM_AARCH64_RA_STATE' undeclared (first use in this
function)
fs->regs.reg[DWARF_REGNUM_AARCH64_RA_STATE].loc.offset ^= 1;
 ^

Christophe

Re: [PATCH] Fix IPA CP where it forgot to add a reference in cgraph

[Martin Liška]

On 01/19/2017 04:10 PM, Jan Hubicka wrote:
 2016-12-19  Martin Liska  

* cgraphclones.c (cgraph_node::create_virtual_clone):
Create either IPA_REF_LOAD of IPA_REF_READ depending on
whether new_tree is a VAR_DECL or an ADDR_EXPR.
* ipa-cp.c (create_specialized_node): Add reference just for
ADDR_EXPRs.
* symtab.c (symtab_node::maybe_create_reference): Remove guard
as it's guarded in callers.
> 
> Path is OK
>>  ipa_ref *
>> -symtab_node::maybe_create_reference (tree val, enum ipa_ref_use use_type,
>> - gimple *stmt)
>> +symtab_node::maybe_create_reference (tree val, gimple *stmt)
>>  {
>>STRIP_NOPS (val);
>> -  if (TREE_CODE (val) != ADDR_EXPR)
>> -return NULL;
>> +  ipa_ref_use use_type;
>> +
>> +  switch (TREE_CODE (val))
>> +{
>> +case VAR_DECL:
>> +  use_type = IPA_REF_LOAD;
>> +  break;
>> +case ADDR_EXPR:
>> +  use_type = IPA_REF_ADDR;
>> +  break;
>> +default:
>> +  return NULL;
>> +}
> 
> I would add assert into default that we don't get handled_component_ref here 
> so we are sure
> we don't miss any declarations (because the bug leads to quite esoteric 
> issues, it is better
> to be safe than sorry)
> 
> Honza
> 

Done in patch I've just installed as r244687.

Thanks for help,
Martin
>From b0c002ba76312ba7cf38a41b1127ae8a55e89639 Mon Sep 17 00:00:00 2001
From: marxin 
Date: Mon, 19 Dec 2016 11:03:34 +0100
Subject: [PATCH] Fix IPA CP where it forgot to add a reference in cgraph (PR
 ipa/71190).

gcc/ChangeLog:

2017-01-19  Martin Liska  

	PR ipa/71190
	* cgraph.h (maybe_create_reference): Remove argument and
	update comment.
	* cgraphclones.c (cgraph_node::create_virtual_clone): Remove one
	argument.
	* ipa-cp.c (create_specialized_node): Likewise.
	* symtab.c (symtab_node::maybe_create_reference): Handle
	VAR_DECLs and ADDR_EXPRs and select ipa_ref_use type.
---
 gcc/cgraph.h   |  6 ++
 gcc/cgraphclones.c |  2 +-
 gcc/ipa-cp.c   |  2 +-
 gcc/symtab.c   | 25 -
 4 files changed, 20 insertions(+), 15 deletions(-)

diff --git a/gcc/cgraph.h b/gcc/cgraph.h
index db2915c5751..5410a71176a 100644
--- a/gcc/cgraph.h
+++ b/gcc/cgraph.h
@@ -131,11 +131,9 @@ public:
 			 enum ipa_ref_use use_type, gimple *stmt);
 
   /* If VAL is a reference to a function or a variable, add a reference from
- this symtab_node to the corresponding symbol table node.  USE_TYPE specify
- type of the use and STMT the statement (if it exists).  Return the new
+ this symtab_node to the corresponding symbol table node.  Return the new
  reference or NULL if none was created.  */
-  ipa_ref *maybe_create_reference (tree val, enum ipa_ref_use use_type,
-   gimple *stmt);
+  ipa_ref *maybe_create_reference (tree val, gimple *stmt);
 
   /* Clone all references from symtab NODE to this symtab_node.  */
   void clone_references (symtab_node *node);
diff --git a/gcc/cgraphclones.c b/gcc/cgraphclones.c
index a17663519a9..c2337e84553 100644
--- a/gcc/cgraphclones.c
+++ b/gcc/cgraphclones.c
@@ -624,7 +624,7 @@ cgraph_node::create_virtual_clone (vec redirect_callers,
   || in_lto_p)
 new_node->unique_name = true;
   FOR_EACH_VEC_SAFE_ELT (tree_map, i, map)
-new_node->maybe_create_reference (map->new_tree, IPA_REF_ADDR, NULL);
+new_node->maybe_create_reference (map->new_tree, NULL);
 
   if (ipa_transforms_to_apply.exists ())
 new_node->ipa_transforms_to_apply
diff --git a/gcc/ipa-cp.c b/gcc/ipa-cp.c
index 9cc903769e8..aa3c9973a66 100644
--- a/gcc/ipa-cp.c
+++ b/gcc/ipa-cp.c
@@ -3786,7 +3786,7 @@ create_specialized_node (struct cgraph_node *node,
 	 args_to_skip, "constprop");
   ipa_set_node_agg_value_chain (new_node, aggvals);
   for (av = aggvals; av; av = av->next)
-new_node->maybe_create_reference (av->value, IPA_REF_ADDR, NULL);
+new_node->maybe_create_reference (av->value, NULL);
 
   if (dump_file && (dump_flags & TDF_DETAILS))
 {
diff --git a/gcc/symtab.c b/gcc/symtab.c
index 87120970d34..c21e7acf28c 100644
--- a/gcc/symtab.c
+++ b/gcc/symtab.c
@@ -588,18 +588,25 @@ symtab_node::create_reference (symtab_node *referred_node,
   return ref;
 }
 
-/* If VAL is a reference to a function or a variable, add a reference from
-   this symtab_node to the corresponding symbol table node.  USE_TYPE specify
-   type of the use and STMT the statement (if it exists).  Return the new
-   reference or NULL if none was created.  */
-
 ipa_ref *
-symtab_node::maybe_create_reference (tree val, enum ipa_ref_use use_type,
- gimple *stmt)
+symtab_node::maybe_create_reference (tree val, gimple *stmt)
 {
   STRIP_NOPS (val);
-  if (TREE_CODE (val) != ADDR_EXPR)
-return NULL;
+  ipa_ref_use use_type;
+
+  switch (TREE_CODE (val))
+{
+case VAR_DECL:
+  use_type = IPA_REF_LOAD;
+  break;
+case ADDR_EXPR:
+  use_type = IPA_REF_ADDR;
+  break;
+default:
+  gcc_assert (!handl

Re: [PATCH, GCC/x86 mingw32] Add configure option to force wildcard behavior on Windows

[Thomas Preudhomme]

Hi JonY,

On 19/01/17 01:37, JonY wrote:

On 01/18/2017 09:48 AM, Thomas Preudhomme wrote:

By default, wildcard support on Windows for programs compiled with mingw
depends on how the mingw runtime was configured. This means if one wants
to build GCC for Windows with a consistent behavior with Wildcard
(enabled or disabled) the mingw runtime must be built as well. This
patch adds an option to GCC configuration to force the behavior with
wildcard when building GCC for Windows host. It does so by setting the
_dowildcard variable in the driver to a given value depending on the
configure option value (yes or no), thus overriding the variable from
mingw runtime.

Testing: I've successfully done a build of the arm-none-eabi cross GCC
for Windows with Ubuntu system mingw runtime (configured without
wildcard support by default) with the three configure options:
  1) --enable-wildcard: wildcard can be used successfully and nm of
driver-mingw32.o shows that _dowildcard is in .data section
  2) --disable-wildcard: wildcard cannot be used and nm of
driver-mingw32.o shows that _dowildcard is in .bss section
  3) no option: wildcard cannot be used and nm of driver-mingw32.o shows
no _dowildcard defined and all sections are empty

Is this ok for stage1?

Best regards,

Thomas


No objections, but documentation should mention that wildcard expansion
is not handled by the CMD shell on Windows, it is up to individual
programs to interpret it.


Do you mean that this configuration option should make it clear that it only 
affects wildcard expansion for GCC itself but not for programs built by GCC?


Best regards,

Thomas

Re: Re: Fortran, committed: Forall-with-temporary problems(pr 50069 and pr 55086).

[Christophe Lyon]

On 20 January 2017 at 00:27, Louis Krupp  wrote:
> I was able to reproduce this on my x86 box by doing "make -k check". 
> Apparently, "make check-fortran" wasn't enough to catch all of the 
> consequences of changing gcc/fortran/lang.opt.
>
> The problem was the help text associated with the -ftest-forall-temp option; 
> it needed to end with a period, and it didn't. I fixed that in revision 
> 244657:
>
>  ftest-forall-temp
>  Fortran Var(flag_test_forall_temp) Init(0)
> -Force creation of temporary to test infrequently-executed forall code
> +Force creation of temporary to test infrequently-executed forall code.
>

Thanks for catching the typo, I didn't notice it.
I confirm the test now pass on my side.

Thanks for the prompt fix.

Christophe

> Louis
>
>  On Thu, 19 Jan 2017 04:52:54 -0800 Christophe Lyon  wrote 
>>Hi,
>>
>>
>>On 18 January 2017 at 22:45, Louis Krupp  wrote:
>>> Fixed in revision 244601.
>>>
>>
>>I've noticed a new failure on arm/aarch64:
>> compiler driver --help=fortran option(s): "^ +-.*[^:.]$" absent from
>>output: " -ftest-forall-temp Force creation of temporary to
>>test infrequently-executed forall code"
>>when testing gcc. (I mean the error appears in gcc.sum/gcc.log, not
>>gfortran.sum)
>>
>>The output above the failure does contain:
>>[...]
>> -fstack-arrays Put all local arrays on stack.
>> -ftest-forall-temp Force creation of temporary to test
>>infrequently-executed forall code
>> -funderscoring Append underscores to externally visible names.
>>[...]
>>so I'm not sure why there is a failure?
>>
>>Christophe
>>
>>
>
>

Re: [Ping~]Re: [5/5][libgcc] Runtime support for AArch64 return address signing (needs new target macros)

[Jiong Wang]

On 20/01/17 08:41, Christophe Lyon wrote:

Hi Jiong,

On 19 January 2017 at 15:46, Jiong Wang  wrote:

Thanks for the review.

On 19/01/17 14:18, Richard Earnshaw (lists) wrote:




diff --git a/libgcc/unwind-dw2.c b/libgcc/unwind-dw2.c
index
8085a42ace15d53f4cb0c6681717012d906a6d47..cf640135275deb76b820f8209fa51eacfd64c4a2
100644
--- a/libgcc/unwind-dw2.c
+++ b/libgcc/unwind-dw2.c
@@ -136,6 +136,8 @@ struct _Unwind_Context
  #define SIGNAL_FRAME_BIT ((~(_Unwind_Word) 0 >> 1) + 1)
/* Context which has version/args_size/by_value fields.  */
  #define EXTENDED_CONTEXT_BIT ((~(_Unwind_Word) 0 >> 2) + 1)
+  /* Bit reserved on AArch64, return address has been signed with A key.
*/
+#define RA_A_SIGNED_BIT ((~(_Unwind_Word) 0 >> 3) + 1)


Why is this here?   It appears to only be used within the
AArch64-specific header file.


I was putting it here so that when we allocate the next general purpose bit,
we
know clearly that bit 3 is allocated to AArch64 already, and the new general
bit
needs to go to the next one.  This can avoid bit collision.


...

+/* Frob exception handler's address kept in TARGET before installing
into
+   CURRENT context.  */
+
+static void *
+uw_frob_return_addr (struct _Unwind_Context *current,
+ struct _Unwind_Context *target)
+{
+  void *ret_addr = __builtin_frob_return_addr (target->ra);
+#ifdef MD_POST_FROB_EH_HANDLER_ADDR
+  ret_addr = MD_POST_FROB_EH_HANDLER_ADDR (current, target, ret_addr);
+#endif
+  return ret_addr;
+}
+


I think this function should be marked inline.  The optimizers would
probably inline it anyway, but it seems wrong for us to rely on that.


Thanks, fixed.

Does the updated patch looks OK to you know?

libgcc/

2017-01-19  Jiong Wang  


 * config/aarch64/aarch64-unwind.h: New file.
 (DWARF_REGNUM_AARCH64_RA_STATE): Define.
 (MD_POST_EXTRACT_ROOT_ADDR): Define.
 (MD_POST_EXTRACT_FRAME_ADDR): Define.
 (MD_POST_FROB_EH_HANDLER_ADDR): Define.
 (MD_FROB_UPDATE_CONTEXT): Define.
 (aarch64_post_extract_frame_addr): New function.
 (aarch64_post_frob_eh_handler_addr): New function.
 (aarch64_frob_update_context): New function.
 * config/aarch64/linux-unwind.h: Include aarch64-unwind.h
 * config.host (aarch64*-*-elf, aarch64*-*-rtems*,
aarch64*-*-freebsd*):
 Initialize md_unwind_header to include aarch64-unwind.h.
 * unwind-dw2.c (struct _Unwind_Context): Define "RA_A_SIGNED_BIT".
 (execute_cfa_program): Multiplex DW_CFA_GNU_window_save for
__aarch64__.
 (uw_update_context): Honor MD_POST_EXTRACT_FRAME_ADDR.
 (uw_init_context_1): Honor MD_POST_EXTRACT_ROOT_ADDR.
 (uw_frob_return_addr): New function.
 (_Unwind_DebugHook): Use uw_frob_return_addr.


Since you committed this (r244673), GCC fails to build for AArch64:
/tmp/8132498_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libgcc/unwind-dw2.c:
In function 'execute_cfa_program':
/tmp/8132498_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libgcc/unwind-dw2.c:1193:17:
error: 'DWARF_REGNUM_AARCH64_RA_STATE' undeclared (first use in this
function)
 fs->regs.reg[DWARF_REGNUM_AARCH64_RA_STATE].loc.offset ^= 1;
  ^


Hi Christophe, could you please confirm you svn revision please?

I do have done bootstrap and regression on both x86 and aarch64 before 
commit this patch.  I had forgotten to "svn add" one header file, but 
add it later.


Thanks.


Christophe

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

[Martin Liška]

On 01/13/2017 06:21 PM, 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
> 

May I install the same patch to both active branches after it survives 
regression tests?

Thanks,
Martin

Re: [Ping~]Re: [5/5][libgcc] Runtime support for AArch64 return address signing (needs new target macros)

[Christophe Lyon]

On 20 January 2017 at 10:44, Jiong Wang  wrote:
>
>
> On 20/01/17 08:41, Christophe Lyon wrote:
>>
>> Hi Jiong,
>>
>> On 19 January 2017 at 15:46, Jiong Wang  wrote:
>>>
>>> Thanks for the review.
>>>
>>> On 19/01/17 14:18, Richard Earnshaw (lists) wrote:


>
> diff --git a/libgcc/unwind-dw2.c b/libgcc/unwind-dw2.c
> index
>
> 8085a42ace15d53f4cb0c6681717012d906a6d47..cf640135275deb76b820f8209fa51eacfd64c4a2
> 100644
> --- a/libgcc/unwind-dw2.c
> +++ b/libgcc/unwind-dw2.c
> @@ -136,6 +136,8 @@ struct _Unwind_Context
>   #define SIGNAL_FRAME_BIT ((~(_Unwind_Word) 0 >> 1) + 1)
> /* Context which has version/args_size/by_value fields.  */
>   #define EXTENDED_CONTEXT_BIT ((~(_Unwind_Word) 0 >> 2) + 1)
> +  /* Bit reserved on AArch64, return address has been signed with A
> key.
> */
> +#define RA_A_SIGNED_BIT ((~(_Unwind_Word) 0 >> 3) + 1)


 Why is this here?   It appears to only be used within the
 AArch64-specific header file.
>>>
>>>
>>> I was putting it here so that when we allocate the next general purpose
>>> bit,
>>> we
>>> know clearly that bit 3 is allocated to AArch64 already, and the new
>>> general
>>> bit
>>> needs to go to the next one.  This can avoid bit collision.
>>>
> ...
>
> +/* Frob exception handler's address kept in TARGET before installing
> into
> +   CURRENT context.  */
> +
> +static void *
> +uw_frob_return_addr (struct _Unwind_Context *current,
> + struct _Unwind_Context *target)
> +{
> +  void *ret_addr = __builtin_frob_return_addr (target->ra);
> +#ifdef MD_POST_FROB_EH_HANDLER_ADDR
> +  ret_addr = MD_POST_FROB_EH_HANDLER_ADDR (current, target, ret_addr);
> +#endif
> +  return ret_addr;
> +}
> +


 I think this function should be marked inline.  The optimizers would
 probably inline it anyway, but it seems wrong for us to rely on that.
>>>
>>>
>>> Thanks, fixed.
>>>
>>> Does the updated patch looks OK to you know?
>>>
>>> libgcc/
>>>
>>> 2017-01-19  Jiong Wang  
>>>
>>>
>>>  * config/aarch64/aarch64-unwind.h: New file.
>>>  (DWARF_REGNUM_AARCH64_RA_STATE): Define.
>>>  (MD_POST_EXTRACT_ROOT_ADDR): Define.
>>>  (MD_POST_EXTRACT_FRAME_ADDR): Define.
>>>  (MD_POST_FROB_EH_HANDLER_ADDR): Define.
>>>  (MD_FROB_UPDATE_CONTEXT): Define.
>>>  (aarch64_post_extract_frame_addr): New function.
>>>  (aarch64_post_frob_eh_handler_addr): New function.
>>>  (aarch64_frob_update_context): New function.
>>>  * config/aarch64/linux-unwind.h: Include aarch64-unwind.h
>>>  * config.host (aarch64*-*-elf, aarch64*-*-rtems*,
>>> aarch64*-*-freebsd*):
>>>  Initialize md_unwind_header to include aarch64-unwind.h.
>>>  * unwind-dw2.c (struct _Unwind_Context): Define
>>> "RA_A_SIGNED_BIT".
>>>  (execute_cfa_program): Multiplex DW_CFA_GNU_window_save for
>>> __aarch64__.
>>>  (uw_update_context): Honor MD_POST_EXTRACT_FRAME_ADDR.
>>>  (uw_init_context_1): Honor MD_POST_EXTRACT_ROOT_ADDR.
>>>  (uw_frob_return_addr): New function.
>>>  (_Unwind_DebugHook): Use uw_frob_return_addr.
>>>
>> Since you committed this (r244673), GCC fails to build for AArch64:
>>
>> /tmp/8132498_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libgcc/unwind-dw2.c:
>> In function 'execute_cfa_program':
>>
>> /tmp/8132498_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libgcc/unwind-dw2.c:1193:17:
>> error: 'DWARF_REGNUM_AARCH64_RA_STATE' undeclared (first use in this
>> function)
>>  fs->regs.reg[DWARF_REGNUM_AARCH64_RA_STATE].loc.offset ^= 1;
>>   ^
>
>
> Hi Christophe, could you please confirm you svn revision please?
>
> I do have done bootstrap and regression on both x86 and aarch64 before
> commit this patch.  I had forgotten to "svn add" one header file, but add it
> later.
>

The failures started with r244673, and are still present with r244687.
When did you add the missing file?

> Thanks.
>
>> Christophe
>
>

Re: [Ping~]Re: [5/5][libgcc] Runtime support for AArch64 return address signing (needs new target macros)

[Jiong Wang]

On 20/01/17 10:11, Christophe Lyon wrote:



/tmp/8132498_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libgcc/unwind-dw2.c:
In function 'execute_cfa_program':

/tmp/8132498_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libgcc/unwind-dw2.c:1193:17:
error: 'DWARF_REGNUM_AARCH64_RA_STATE' undeclared (first use in this
function)
  fs->regs.reg[DWARF_REGNUM_AARCH64_RA_STATE].loc.offset ^= 1;
   ^


Hi Christophe, could you please confirm you svn revision please?

I do have done bootstrap and regression on both x86 and aarch64 before
commit this patch.  I had forgotten to "svn add" one header file, but add it
later.


The failures started with r244673, and are still present with r244687.
When did you add the missing file?


It was r244674, https://gcc.gnu.org/ml/gcc-cvs/2017-01/msg00689.html,  
so should have been included in your code.  The faliure looks strange to 
me then,  I will svn up and re-start a fresh bootstrap on AArch64.





Thanks.


Christophe

Re: [Ping~]Re: [5/5][libgcc] Runtime support for AArch64 return address signing (needs new target macros)

[Christophe Lyon]

On 20 January 2017 at 11:18, Jiong Wang  wrote:
>
>
> On 20/01/17 10:11, Christophe Lyon wrote:
>>
>>

 /tmp/8132498_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libgcc/unwind-dw2.c:
 In function 'execute_cfa_program':


 /tmp/8132498_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libgcc/unwind-dw2.c:1193:17:
 error: 'DWARF_REGNUM_AARCH64_RA_STATE' undeclared (first use in this
 function)
   fs->regs.reg[DWARF_REGNUM_AARCH64_RA_STATE].loc.offset ^= 1;
^
>>>
>>>
>>> Hi Christophe, could you please confirm you svn revision please?
>>>
>>> I do have done bootstrap and regression on both x86 and aarch64 before
>>> commit this patch.  I had forgotten to "svn add" one header file, but add
>>> it
>>> later.
>>>
>> The failures started with r244673, and are still present with r244687.
>> When did you add the missing file?
>
>
> It was r244674, https://gcc.gnu.org/ml/gcc-cvs/2017-01/msg00689.html,  so
> should have been included in your code.  The faliure looks strange to me
> then,  I will svn up and re-start a fresh bootstrap on AArch64.
>

The file is present in my git clone.
I'm not bootstrapping on AArch64, I'm building a cross-compiler on x86_64,
but it shouldn't matter.

>>
>>> Thanks.
>>>
 Christophe
>>>
>>>
>

[Ada] Spurious error on Default_Initial_Condition

[Arnaud Charlet]

This patch modifies the generation of the Default_Initial_Condition procedure
to disregard class-wide types and the underlying full views of private types.
In addition, the patch preserves the attributes of freeze nodes when the
partial and/or full views of a private type inherit the freeze node of the
underlying full view.


-- Source --


--  pack_1.ads

package Pack_1 is
   type Untag_Par (Size : Natural) is private
 with Default_Initial_Condition => Is_OK_UP (Untag_Par);

   type Tag_Par (Size : Natural) is tagged private
 with Default_Initial_Condition => Is_OK_TP (Tag_Par);

   type Lim_Untag_Par (Size : Natural) is limited private
 with Default_Initial_Condition => Is_OK_LUP (Lim_Untag_Par);

   type Lim_Tag_Par (Size : Natural) is tagged limited private
 with Default_Initial_Condition => Is_OK_LTP (Lim_Tag_Par);

   function Is_OK_UP  (Obj : Untag_Par) return Boolean;
   function Is_OK_TP  (Obj : Tag_Par)   return Boolean;
   function Is_OK_LUP (Obj : Lim_Untag_Par) return Boolean;
   function Is_OK_LTP (Obj : Lim_Tag_Par)   return Boolean;

private
   type Untag_Par (Size : Natural) is record
  Comp : Natural := Size;
   end record;

   type Tag_Par (Size : Natural) is tagged record
  Comp : Natural := Size;
   end record;

   type Lim_Untag_Par (Size : Natural) is limited record
  Comp : Natural := Size;
   end record;

   type Lim_Tag_par (Size : Natural) is tagged limited record
  Comp : Natural := Size;
   end record;
end Pack_1;

--  pack_1.adb

with Ada.Text_IO; use Ada.Text_IO;

package body Pack_1 is
   function Is_OK_UP (Obj : Untag_Par) return Boolean is
   begin
  Put_Line ("Untag_Par");
  return True;
   end Is_OK_UP;

   function Is_OK_TP (Obj : Tag_Par) return Boolean is
   begin
  Put_Line ("Tag_Par");
  return True;
   end Is_OK_TP;

   function Is_OK_LUP (Obj : Lim_Untag_Par) return Boolean is
   begin
  Put_Line ("Lim_Untag_Par");
  return True;
   end Is_OK_LUP;

   function Is_OK_LTP (Obj : Lim_Tag_Par) return Boolean is
   begin
  Put_Line ("Lim_Tag_Par");
  return True;
   end Is_OK_LTP;
end Pack_1;

--  pack_2.ads

with Pack_1; use Pack_1;

package Pack_2 is
   type Deriv_1 is private
 with Default_Initial_Condition => Is_OK_Deriv_1 (Deriv_1);

   type Deriv_2 is tagged private
 with Default_Initial_Condition => Is_OK_Deriv_2 (Deriv_2);

   type Deriv_3 is limited private
 with Default_Initial_Condition => Is_OK_Deriv_3 (Deriv_3);

   type Deriv_4 is tagged limited private
 with Default_Initial_Condition => Is_OK_Deriv_4 (Deriv_4);

   type Deriv_5 is private
 with Default_Initial_Condition;

   type Deriv_6 is tagged private
 with Default_Initial_Condition;

   type Deriv_7 is limited private
 with Default_Initial_Condition;

   type Deriv_8 is tagged limited private
 with Default_Initial_Condition;

   function Is_OK_Deriv_1 (Obj : Deriv_1) return Boolean;
   function Is_OK_Deriv_2 (Obj : Deriv_2) return Boolean;
   function Is_OK_Deriv_3 (Obj : Deriv_3) return Boolean;
   function Is_OK_Deriv_4 (Obj : Deriv_4) return Boolean;

private
   type Deriv_1 is new Untag_Par (1);
   type Deriv_2 is new Tag_Par   (2) with null record;
   type Deriv_3 is new Lim_Untag_Par (3);
   type Deriv_4 is new Lim_Tag_Par   (4) with null record;
   type Deriv_5 is new Untag_Par (5);
   type Deriv_6 is new Tag_Par   (6) with null record;
   type Deriv_7 is new Lim_Untag_Par (7);
   type Deriv_8 is new Lim_Tag_Par   (8) with null record;

end Pack_2;

--  pack_2.adb

with Ada.Text_IO; use Ada.Text_IO;

package body Pack_2 is
   function Is_OK_Deriv_1 (Obj : Deriv_1) return Boolean is
   begin
  Put_Line ("Deriv_1");
  return True;
   end Is_OK_Deriv_1;

   function Is_OK_Deriv_2 (Obj : Deriv_2) return Boolean is
   begin
  Put_Line ("Deriv_2");
  return True;
   end Is_OK_Deriv_2;

   function Is_OK_Deriv_3 (Obj : Deriv_3) return Boolean is
   begin
  Put_Line ("Deriv_3");
  return True;
   end Is_OK_Deriv_3;

   function Is_OK_Deriv_4 (Obj : Deriv_4) return Boolean is
   begin
  Put_Line ("Deriv_4");
  return True;
   end Is_OK_Deriv_4;
end Pack_2;

--  main.adb

with Pack_2; use Pack_2;

procedure Main is
   Obj_1 : Deriv_1;
   Obj_2 : Deriv_2;
   Obj_3 : Deriv_3;
   Obj_4 : Deriv_4;
   Obj_5 : Deriv_5;
   Obj_6 : Deriv_6;
   Obj_7 : Deriv_7;
   Obj_8 : Deriv_8;
begin
   null;
end Main;


-- Compilation and output --


$ gnatmake -q -gnata main.adb
$ ./main
Deriv_1
Deriv_2
Deriv_3
Deriv_4

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

2017-01-20  Hristian Kirtchev  

* einfo.adb Flag298 now denotes Is_Underlying_Full_View.
(Is_Underlying_Full_View): New routine.
(Set_Is_Underlying_Full_View): New routine.
(Write_Entity_Flags): Add an entry for Is_Underlying_Full_View.
* einfo.ads Add new attribute Is_Underlying_Full_View

[Ada] Fix typing in special frontend inlining for GNATprove

[Arnaud Charlet]

In some cases of an assignment to an unconstrained formal parameter
being inlined as part of the special frontend inlining in GNATprove mode,
the inlined assignment is to an unconstrained view of a constrained local
variable, which is unexpected in GNATprove. Rather, keep the most precise
type of the actual parameter in such cases.

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

2017-01-20  Yannick Moy  

* inline.adb (Expand_Inlined_Call): Keep more
precise type of actual for inlining whenever possible. In
particular, do not switch to the formal type in GNATprove mode in
some case where the GNAT backend might require it for visibility.

Index: inline.adb
===
--- inline.adb  (revision 244691)
+++ inline.adb  (working copy)
@@ -3087,8 +3087,10 @@
 
  elsif Base_Type (Etype (F)) = Base_Type (Etype (A))
and then Etype (F) /= Base_Type (Etype (F))
+   and then Is_Constrained (Etype (F))
  then
 Temp_Typ := Etype (F);
+
  else
 Temp_Typ := Etype (A);
  end if;
@@ -3150,7 +3152,15 @@
Subtype_Mark => New_Occurrence_Of (Etype (F), Loc),
Expression   => Relocate_Node (Expression (A)));
 
-elsif Etype (F) /= Etype (A) then
+--  In GNATprove mode, keep the most precise type of the actual
+--  for the temporary variable. Otherwise, the AST may contain
+--  unexpected assignment statements to a temporary variable of
+--  unconstrained type renaming a local variable of constrained
+--  type, which is not expected by GNATprove.
+
+elsif Etype (F) /= Etype (A)
+  and then not GNATprove_Mode
+then
New_A := Unchecked_Convert_To (Etype (F), Relocate_Node (A));
Temp_Typ := Etype (F);
 

[Ada] Update Ada.Locales for RM 2012 COR:1:2016

[Arnaud Charlet]

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

2017-01-20  Pascal Obry  

* a-locale.adb, a-locale.ads: Update Ada.Locales for RM 2012 COR:1:2016

Index: a-locale.adb
===
--- a-locale.adb(revision 244691)
+++ a-locale.adb(working copy)
@@ -33,8 +33,7 @@
 
 package body Ada.Locales is
 
-   type Lower_4 is array (1 .. 4) of Character range 'a' .. 'z';
-   type Upper_4 is array (1 .. 4) of Character range 'A' .. 'Z';
+   type Str_4 is new String (1 .. 4);
 
--
-- Language --
@@ -43,7 +42,7 @@
function Language return Language_Code is
   procedure C_Get_Language_Code (P : Address);
   pragma Import (C, C_Get_Language_Code);
-  F : Lower_4;
+  F : Str_4;
begin
   C_Get_Language_Code (F'Address);
   return Language_Code (F (1 .. 3));
@@ -56,7 +55,7 @@
function Country return Country_Code is
   procedure C_Get_Country_Code (P : Address);
   pragma Import (C, C_Get_Country_Code);
-  F : Upper_4;
+  F : Str_4;
begin
   C_Get_Country_Code (F'Address);
   return Country_Code (F (1 .. 2));
Index: a-locale.ads
===
--- a-locale.ads(revision 244691)
+++ a-locale.ads(working copy)
@@ -19,9 +19,14 @@
pragma Preelaborate (Locales);
pragma Remote_Types (Locales);
 
-   type Language_Code is array (1 .. 3) of Character range 'a' .. 'z';
-   type Country_Code  is array (1 .. 2) of Character range 'A' .. 'Z';
+   type Language_Code is new String (1 .. 3)
+  with Dynamic_Predicate =>
+ (for all E of Language_Code => E in 'a' .. 'z');
 
+   type Country_Code is new String (1 .. 2)
+  with Dynamic_Predicate =>
+ (for all E of Country_Code => E in 'A' .. 'Z');
+
Language_Unknown : constant Language_Code := "und";
Country_Unknown  : constant Country_Code := "ZZ";
 

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

[Aldy Hernandez]

On 01/20/2017 03: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)


Yes, I remember getting much better range information when doing things 
within VRP2, however since VRP2 runs after jump threading sometimes I'd 
get more false positives.


Tell you what, for GCC8 I volunteer to rewrite gimple-ssa-warn-alloca.c 
within VRP (or using whatever range information we decide upon or is 
ready for GCC8).  In the meantime, can we fix the PR with my patch (or a 
similar approach)?


Aldy

Re: Implement -Wduplicated-branches (PR c/64279) (v3)

[Marek Polacek]

On Mon, Jan 16, 2017 at 03:32:59PM -0700, Jeff Law wrote:
> s/indentical/identical in the doc/invoke.texi changes.
 
Fixed.

> > diff --git gcc/c/c-typeck.c gcc/c/c-typeck.c
> > index 96e7351..ed8ffe4 100644
> > --- gcc/c/c-typeck.c
> > +++ gcc/c/c-typeck.c
> > @@ -5193,6 +5193,15 @@ build_conditional_expr (location_t colon_loc, tree 
> > ifexp, bool ifexp_bcp,
> >  ret = build1 (EXCESS_PRECISION_EXPR, semantic_result_type, ret);
> > 
> >protected_set_expr_location (ret, colon_loc);
> > +
> > +  /* If the OP1 and OP2 are the same and don't have side-effects,
> > + warn here, because the COND_EXPR will be turned into OP1.  */
> > +  if (warn_duplicated_branches
> > +  && TREE_CODE (ret) == COND_EXPR
> > +  && (op1 == op2 || operand_equal_p (op1, op2, 0)))
> Did you want OEP_LEXICOGRAPHIC here, or in this context do we not have to
> worry about the more complex forms?  What about a statement expressions?
> Have we lowered those at this point already?
 
I think we do not want OEP_LEXICOGRAPHIC here, because if the op0 or op1
of ?: have side-effects, they'll survive until c_genericize, so the warning
will warn.  With OEP_LEXICOGRAPHIC, it'd warn twice.

Simple statement expressions are handled (there are a few tests).  More
complicated ({})s are represented as BIND_EXPRs and those aren't handled.

> > diff --git gcc/cp/call.c gcc/cp/call.c
> > index e431221..84931fb 100644
> > --- gcc/cp/call.c
> > +++ gcc/cp/call.c
> > @@ -5302,6 +5302,13 @@ build_conditional_expr_1 (location_t loc, tree arg1, 
> > tree arg2, tree arg3,
> >   valid_operands:
> >result = build3_loc (loc, COND_EXPR, result_type, arg1, arg2, arg3);
> > 
> > +  /* If the ARG2 and ARG3 are the same and don't have side-effects,
> > + warn here, because the COND_EXPR will be turned into ARG2.  */
> > +  if (warn_duplicated_branches
> > +  && (arg2 == arg3 || operand_equal_p (arg2, arg3, 0)))
> Likewise.
 
Same as above.

> So, typo fix in invoke.texi and change to use OEP_LEXICOGRAPHIC in those two
> spots if needed and then OK for the trunk.

Thanks!

This is the patch with the typo fixed.  I'll commit it today after regtesting.

2017-01-20  Marek Polacek  

PR c/64279
* c-common.h (do_warn_duplicated_branches_r): Declare.
* c-gimplify.c (c_genericize): Walk the function tree calling
do_warn_duplicated_branches_r.
* c-warn.c (expr_from_macro_expansion_r): New.
(do_warn_duplicated_branches): New.
(do_warn_duplicated_branches_r): New.
* c.opt (Wduplicated-branches): New option.

* c-typeck.c (build_conditional_expr): Warn about duplicated branches.

* call.c (build_conditional_expr_1): Warn about duplicated branches.
* semantics.c (finish_expr_stmt): Build statement using the proper
location.

* doc/invoke.texi: Document -Wduplicated-branches.
* fold-const.c (operand_equal_p): Handle MODIFY_EXPR, INIT_EXPR,
COMPOUND_EXPR, PREDECREMENT_EXPR, PREINCREMENT_EXPR,
POSTDECREMENT_EXPR, POSTINCREMENT_EXPR, CLEANUP_POINT_EXPR, EXPR_STMT,
STATEMENT_LIST, and RETURN_EXPR.  For non-pure non-const functions
return 0 only when not OEP_LEXICOGRAPHIC.
(fold_build_cleanup_point_expr): Use the expression
location when building CLEANUP_POINT_EXPR.
* tree-core.h (enum operand_equal_flag): Add OEP_LEXICOGRAPHIC.
* tree.c (add_expr): Handle error_mark_node.

* c-c++-common/Wduplicated-branches-1.c: New test.
* c-c++-common/Wduplicated-branches-10.c: New test.
* c-c++-common/Wduplicated-branches-11.c: New test.
* c-c++-common/Wduplicated-branches-12.c: New test.
* c-c++-common/Wduplicated-branches-2.c: New test.
* c-c++-common/Wduplicated-branches-3.c: New test.
* c-c++-common/Wduplicated-branches-4.c: New test.
* c-c++-common/Wduplicated-branches-5.c: New test.
* c-c++-common/Wduplicated-branches-6.c: New test.
* c-c++-common/Wduplicated-branches-7.c: New test.
* c-c++-common/Wduplicated-branches-8.c: New test.
* c-c++-common/Wduplicated-branches-9.c: New test.
* c-c++-common/Wimplicit-fallthrough-7.c: Coalesce dg-warning.
* g++.dg/cpp0x/lambda/lambda-switch.C: Move dg-warning.
* g++.dg/ext/builtin-object-size3.C: Likewise.
* g++.dg/gomp/loop-1.C: Likewise.
* g++.dg/warn/Wduplicated-branches1.C: New test.
* g++.dg/warn/Wduplicated-branches2.C: New test.

diff --git gcc/c-family/c-common.h gcc/c-family/c-common.h
index b838869..06918db 100644
--- gcc/c-family/c-common.h
+++ gcc/c-family/c-common.h
@@ -1537,6 +1537,7 @@ extern void maybe_warn_bool_compare (location_t, enum 
tree_code, tree, tree);
 extern bool maybe_warn_shift_overflow (location_t, tree, tree);
 extern void warn_duplicated_cond_add_or_warn (location_t, tree, vec **);
 extern bool diagnose_mismatched_attributes (tree, tree);
+extern tree do_warn_duplicated_branch

Re: [1/5][AArch64] Return address protection on AArch64

[Jiong Wang]

On 20/01/17 03:39, Andrew Pinski wrote:

On Fri, Jan 6, 2017 at 3:47 AM, Jiong Wang  wrote:

On 11/11/16 18:22, Jiong Wang wrote:

As described in the cover letter, this patch implements return address
signing
for AArch64, it's controlled by the new option:

-msign-return-address=[none | non-leaf | all]

"none" means don't do return address signing at all on any function.
"non-leaf"
means only sign non-leaf function.  "all" means sign all functions.
Return
address signing is currently disabled on ILP32.  I haven't tested it.

The instructions added in the architecture are of 2 kinds.

* In the NOP instruction space, which allows binaries to run without any
traps
on older versions of the architecture. This doesn't give any additional
protection on older hardware but allows for the same binary to be used on
earlier versions of the architecture and newer versions of the
architecture.

* New instructions that are only valid for v8.3 and will trap if used on
earlier
versions of the architecture.

At default, once return address signing is enabled, it will only generates
NOP
instruction.

While if -march=armv8.3-a specified, GCC will try to use the most
efficient
pointer authentication instruction as it can.

The architecture has 2 user invisible system keys for signing and creating
signed addresses as part of these instructions. For some use case, the
user
might want to use difference key for different functions.  The new option
"-msign-return-address-key=key_name" let GCC select the key used for
return
address signing.  Permissible values are "a_key" for A key and "b_key" for
B
key, and this option are supported by function target attribute and LTO
will
hopefully just work.



gcc/
2016-11-09  Jiong Wang

  * config/aarch64/aarch64-opts.h (aarch64_pauth_key_index): New
enum.
  (aarch64_function_type): New enum.
  * config/aarch64/aarch64-protos.h (aarch64_output_sign_auth_reg):
New
  declaration.
  * config/aarch64/aarch64.c (aarch64_expand_prologue): Sign return
  address before it's pushed onto stack.
  (aarch64_expand_epilogue): Authenticate return address fetched
from
  stack.
  (aarch64_output_sign_auth_reg): New function.
  (aarch64_override_options): Sanity check for ILP32 and ISA level.
  (aarch64_attributes): New function attributes for
"sign-return-address",
  "pauth-key".
  * config/aarch64/aarch64.md (UNSPEC_AUTH_REG,
UNSPEC_AUTH_REG1716,
  UNSPEC_SIGN_REG, UNSPEC_SIGN_REG1716, UNSPEC_STRIP_REG_SIGN,
  UNSPEC_STRIP_X30_SIGN): New unspecs.
  ("*do_return"): Generate combined instructions according to key
index.
  ("sign_reg", "sign_reg1716", "auth_reg", "auth_reg1716",
  "strip_reg_sign", "strip_lr_sign"): New.
  * config/aarch64/aarch64.opt (msign-return-address, mpauth-key):
New.
  * config/aarch64/predicates.md (aarch64_const0_const1): New
predicate.
  * doc/extend.texi (AArch64 Function Attributes): Documents
  "sign-return-address=", "pauth-key".
  * doc/invoke.texi (AArch64 Options): Documents
"-msign-return-address=",
  "-pauth-key".

gcc/testsuite/
2016-11-09  Jiong Wang

  * gcc.target/aarch64/return_address_sign_1.c: New testcase.
  * gcc.target/aarch64/return_address_sign_scope_1.c: New testcase.


Update the patchset according to new DWARF proposal described at

   https://gcc.gnu.org/ml/gcc-patches/2016-11/msg03010.html

One of these patches of this patch set break ILP32 building for
aarch64-elf and most likely also aarch64-linux-gnu.

/home/jenkins/workspace/BuildToolchainAARCH64_thunder_elf_upstream/toolchain/scripts/../src/libgcc/unwind-dw2.c:
In function ‘uw_init_context_1’:
/home/jenkins/workspace/BuildToolchainAARCH64_thunder_elf_upstream/toolchain/scripts/../src/libgcc/unwind-dw2.c:1567:6:
internal compiler error: in emit_move_insn, at expr.c:3698
ra = MD_POST_EXTRACT_ROOT_ADDR (ra);
0x8270cf emit_move_insn(rtx_def*, rtx_def*)
/home/jenkins/workspace/BuildToolchainAARCH64_thunder_elf_upstream/toolchain/scripts/../src/gcc/expr.c:3697
0x80867b force_reg(machine_mode, rtx_def*)
Must be the Pmode issue under ILP32, I am testing a fix (I don't have 
full ILP32 environment, so can only test simply by force libgcc build 
with -mabi=ilp32)




Thanks,
Andrew





While A key support for return address signing using DW_CFA_GNU_window_save
only
needs simple modifications on code and associated DWARF generation, B key
support is complexer, it needs multiple CIE support in GCC and Binutils, so
currently we fall back to DWARF value expression which fully works although
requires longer encodings. Value expression also requires a few changes on
AArch64 prologue and epilogue hooks that code review will not be easy.

Therefore I have removed all B key support code in the initial support patch
set,
and will organize them into a seperate follow up patchset so that we can do
A key
cod

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

[Richard Biener]

On Fri, Jan 20, 2017 at 11:52 AM, Aldy Hernandez  wrote:
> On 01/20/2017 03: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)
>
>
> Yes, I remember getting much better range information when doing things
> within VRP2, however since VRP2 runs after jump threading sometimes I'd get
> more false positives.
>
> Tell you what, for GCC8 I volunteer to rewrite gimple-ssa-warn-alloca.c
> within VRP (or using whatever range information we decide upon or is ready
> for GCC8).  In the meantime, can we fix the PR with my patch (or a similar
> approach)?

Sure.

Richard.

> Aldy

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

[Martin Liška]

On 01/19/2017 05:33 PM, Jakub Jelinek wrote:
> On Wed, Jan 18, 2017 at 04:34:48PM +0100, Martin Liška wrote:
>> Hello.
>>
>> During bootstrap, I came to following test-case:
>>
>> struct A
>> {
>>   int regno;
>> };
>> struct
>> {
>>   A base;
>> } typedef *df_ref;
>> int *a;
>> void
>> fn1 (int N)
>> {
>>   for (int i = 0; i < N; i++)
>> {
>>   df_ref b;
>>   a[(b)->base.regno]++;
>> }
>> }
> 
> Well, in this case it is UB too, just not actually out of bounds access,
> but use of uninitialized variable.
> Perhaps what we should do, in addition to turning ASAN_MARK (POISON, &b, ...)
> into b = ASAN_POISON (); turn ASAN_MARK (UNPOISON, &b, ...) into
> b = b_YYY(D);

Great, thanks a lot. I'm going to re-trigger asan-bootstrap with your patch.
I'm also adding gcc/testsuite/gcc.dg/asan/use-after-scope-10.c that is a valid
test-case for this issue.

Hopefully it will survive both regression tests and asan-bootstrap.

Thanks,
Martin


> The following seems to do the job:
> --- gcc/tree-ssa.c.jj 2017-01-19 17:20:15.0 +0100
> +++ gcc/tree-ssa.c2017-01-19 17:29:58.015356370 +0100
> @@ -1911,7 +1911,16 @@ execute_update_addresses_taken (void)
>   gsi_replace (&gsi, call, GSI_SAME_STMT);
> }
>   else
> -   gsi_remove (&gsi, true);
> +   {
> + /* In ASAN_MARK (UNPOISON, &b, ...) the variable
> +is uninitialized.  Avoid dependencies on
> +previous out of scope value.  */
> + tree clobber
> +   = build_constructor (TREE_TYPE (var), NULL);
> + TREE_THIS_VOLATILE (clobber) = 1;
> + gimple *g = gimple_build_assign (var, clobber);
> + gsi_replace (&gsi, g, GSI_SAME_STMT);
> +   }
>   continue;
> }
> }
> 
>   Jakub
> 

>From fa8a7fa81df7cf775dcf9018911044e5a331570d Mon Sep 17 00:00:00 2001
From: marxin 
Date: Tue, 17 Jan 2017 16:49:29 +0100
Subject: [PATCH] use-after-scope: handle writes to a poisoned variable

gcc/testsuite/ChangeLog:

2017-01-17  Martin Liska  

	* gcc.dg/asan/use-after-scope-10.c: New test.
	* g++.dg/asan/use-after-scope-5.C: New test.

gcc/ChangeLog:

2017-01-16  Jakub Jelinek  

	* asan.c (asan_expand_poison_ifn): Support stores and use
	appropriate ASAN report function.
	* internal-fn.c (expand_ASAN_POISON_USE): New function.
	* internal-fn.def (ASAN_POISON_USE): Declare.
	* tree-into-ssa.c (maybe_add_asan_poison_write): New function.
	(maybe_register_def): Create ASAN_POISON_USE when sanitizing.
	* tree-ssa-dce.c (eliminate_unnecessary_stmts): Remove
	ASAN_POISON calls w/o LHS.
	* tree-ssa.c (execute_update_addresses_taken): Create clobber
	for ASAN_MARK (UNPOISON, &x, ...) in order to prevent usage of a LHS
	from ASAN_MARK (POISON, &x, ...) coming to a PHI node.
---
 gcc/asan.c | 19 +++---
 gcc/internal-fn.c  |  8 
 gcc/internal-fn.def|  1 +
 gcc/testsuite/g++.dg/asan/use-after-scope-5.C  | 23 ++
 gcc/testsuite/gcc.dg/asan/use-after-scope-10.c | 22 +
 gcc/tree-into-ssa.c| 27 +-
 gcc/tree-ssa-dce.c | 16 +++
 gcc/tree-ssa.c | 11 ++-
 8 files changed, 114 insertions(+), 13 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/asan/use-after-scope-5.C
 create mode 100644 gcc/testsuite/gcc.dg/asan/use-after-scope-10.c

diff --git a/gcc/asan.c b/gcc/asan.c
index fe117a6951a..486ebfdb6af 100644
--- a/gcc/asan.c
+++ b/gcc/asan.c
@@ -3094,6 +3094,8 @@ create_asan_shadow_var (tree var_decl,
 return *slot;
 }
 
+/* Expand ASAN_POISON ifn.  */
+
 bool
 asan_expand_poison_ifn (gimple_stmt_iterator *iter,
 			bool *need_commit_edge_insert,
@@ -3107,8 +3109,8 @@ asan_expand_poison_ifn (gimple_stmt_iterator *iter,
   return true;
 }
 
-  tree shadow_var  = create_asan_shadow_var (SSA_NAME_VAR (poisoned_var),
-	 shadow_vars_mapping);
+  tree shadow_var = create_asan_shadow_var (SSA_NAME_VAR (poisoned_var),
+	shadow_vars_mapping);
 
   bool recover_p;
   if (flag_sanitize & SANITIZE_USER_ADDRESS)
@@ -3122,16 +3124,16 @@ asan_expand_poison_ifn (gimple_stmt_iterator *iter,
 		 ASAN_MARK_POISON),
   build_fold_addr_expr (shadow_var), size);
 
-  use_operand_p use_p;
+  gimple *use;
   imm_use_iterator imm_iter;
-  FOR_EACH_IMM_USE_FAST (use_p, imm_iter, poisoned_var)
+  FOR_EACH_IMM_USE_STMT (use, imm_iter, poisoned_var)
 {
-  gimple *use = USE_STMT (use_p);
   if (is_gimple_debug (use))
 	continue;
 
   int nargs;
-  tree fun = report_error_func (false, recover_p, tree_to_uhwi (

[Ada] Legality and removal of ignored Ghost context clauses

[Arnaud Charlet]

This patch implements several checks on use clauses to prevent mixing Ghost and
non-Ghost names. A context clause is marked as ignored Ghost when it mentions
an ignored Ghost package or type. Pruning of ignored Ghost code now looks at
compilation unit nodes in order to remove ignored Ghost clauses and pragmas.


-- Source --


--  g1.ads

package G1 with Ghost is
end G1;

--  g2.ads

package G2 with Ghost is
end G2;

--  l1.ads

package L1 is
end L1;

--  l2.ads

package L2 is
end L2;

--  types.ads

package Types is
   type G1 is null record with Ghost;
   type G2 is null record with Ghost;

   type L1 is null record;
   type L2 is null record;
end Types;

--  uses1.ads

with G1, G2;
use  G1, G2;  --  OK

with Types;

package Uses1 is
   use type Types.G1, Types.G2;  --  OK
end Uses1;

--  uses2.ads

with G1, L1;
use  G1, L1;  --  ERROR

with Types;

package Uses2 is
   use type Types.G1, Types.L1;  --  ERROR
end Uses2;

--  uses3.ads

with L1, L2, G2;
use  L1, L2, G2;  --  ERROR

with Types;

package Uses3 is
   use type Types.L1, Types.L2, Types.G2;  --  ERROR
end Uses3;

--  uses4.ads

with G1; use G1;
with G2; use G2;

with Types;

package Uses4 is
   use type Types.G1, Types.G2;
end Uses4;


-- Compilation and output --


$ gcc -c uses1.ads
$ gcc -c uses2.ads
$ gcc -c uses3.ads
$ gcc -c uses4.ads -gnatDG
$ grep -c "g[12]" uses4.ads.dg
uses2.ads:2:01: use clause cannot mention ghost and non-ghost ghost units
uses2.ads:2:01: "G1" at g1.ads:1 declared as ghost
uses2.ads:2:01: "L1" at l1.ads:1 declared as non-ghost
uses2.ads:7:04: use clause cannot mention ghost and non-ghost ghost types
uses2.ads:7:04: "G1" at types.ads:2 declared as ghost
uses2.ads:7:04: "L1" at types.ads:5 declared as non-ghost
uses3.ads:2:01: use clause cannot mention ghost and non-ghost ghost units
uses3.ads:2:01: "G2" at g2.ads:1 declared as ghost
uses3.ads:2:01: "L1" at l1.ads:1 declared as non-ghost
uses3.ads:7:04: use clause cannot mention ghost and non-ghost ghost types
uses3.ads:7:04: "G2" at types.ads:3 declared as ghost
uses3.ads:7:04: "L1" at types.ads:5 declared as non-ghost
0

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

2017-01-20  Hristian Kirtchev  

* ghost.adb (Mark_Ghost_Clause): New routine.
(Prune_Node): Do not prune compilation unit nodes.
(Remove_Ignored_Ghost_Code): Prune the compilation unit node directly.
This does not touch the node itself, but does prune all its fields.
* ghost.ads (Mark_Ghost_Clause): New routine.
* sem_ch8.adb (Analyze_Use_Package): Emit an error when a use
package clause mentions Ghost and non-Ghost packages. Mark a
use package clause as Ghost when it mentions a Ghost package.
(Analyze_Use_Type): Emit an error when a use type clause mentions
Ghost and non-Ghost types. Mark a use type clause as Ghost when
it mentions a Ghost type.
* sem_ch10.adb (Analyze_With_Clause): Mark a with clause as
Ghost when it withs a Ghost unit.

Index: sem_ch10.adb
===
--- sem_ch10.adb(revision 244703)
+++ sem_ch10.adb(working copy)
@@ -34,6 +34,7 @@
 with Fname; use Fname;
 with Fname.UF;  use Fname.UF;
 with Freeze;use Freeze;
+with Ghost; use Ghost;
 with Impunit;   use Impunit;
 with Inline;use Inline;
 with Lib;   use Lib;
@@ -2826,6 +2827,8 @@
Set_Fatal_Error (Current_Sem_Unit, Error_Ignored);
 end if;
   end case;
+
+  Mark_Ghost_Clause (N);
end Analyze_With_Clause;
 
--
Index: ghost.adb
===
--- ghost.adb   (revision 244691)
+++ ghost.adb   (working copy)
@@ -1430,6 +1430,34 @@
end Mark_Ghost_Declaration_Or_Body;
 
---
+   -- Mark_Ghost_Clause --
+   ---
+
+   procedure Mark_Ghost_Clause (N : Node_Id) is
+  Nam : Node_Id := Empty;
+
+   begin
+  if Nkind (N) = N_Use_Package_Clause then
+ Nam := First (Names (N));
+
+  elsif Nkind (N) = N_Use_Type_Clause then
+ Nam := First (Subtype_Marks (N));
+
+  elsif Nkind (N) = N_With_Clause then
+ Nam := Name (N);
+  end if;
+
+  if Present (Nam)
+and then Is_Entity_Name (Nam)
+and then Present (Entity (Nam))
+and then Is_Ignored_Ghost_Entity (Entity (Nam))
+  then
+ Set_Is_Ignored_Ghost_Node (N);
+ Propagate_Ignored_Ghost_Code (N);
+  end if;
+   end Mark_Ghost_Clause;
+
+   ---
-- Mark_Ghost_Pragma --
---
 
@@ -1574,10 +1602,17 @@
 Id : Entity_Id;
 
  begin
+--  Do not prune compilation unit nodes because many mechanisms
+--  depend on their presence. Note that context items must still
+--  be process

Re: [Ping~]Re: [5/5][libgcc] Runtime support for AArch64 return address signing (needs new target macros)

[Jiong Wang]

On 20/01/17 10:30, Christophe Lyon wrote:

error: 'DWARF_REGNUM_AARCH64_RA_STATE' undeclared (first use in this
function)
   fs->regs.reg[DWARF_REGNUM_AARCH64_RA_STATE].loc.offset ^= 1;
^


Hi Christophe, could you please confirm you svn revision please?

I do have done bootstrap and regression on both x86 and aarch64 before
commit this patch.  I had forgotten to "svn add" one header file, but add
it
later.


The failures started with r244673, and are still present with r244687.
When did you add the missing file?


It was r244674, https://gcc.gnu.org/ml/gcc-cvs/2017-01/msg00689.html,  so
should have been included in your code.  The faliure looks strange to me
then,  I will svn up and re-start a fresh bootstrap on AArch64.


The file is present in my git clone.
I'm not bootstrapping on AArch64, I'm building a cross-compiler on x86_64,
but it shouldn't matter.


Hi Christophe,

  Thanks, I reproduced this on cross linux environment, the reason is the 
header file is not included because of the inhabit_libc guard, while the 
unwinder header file should always be included.

   I will committed the attached patch as obvious, once I finished a fresh 
bootstrap, cross elf, cross linux.

   Thanks.

libgcc/

2017-01-20  Jiong Wang  

* config/aarch64/linux-unwind.h: Always include aarch64-unwind.h.


diff --git a/libgcc/config/aarch64/linux-unwind.h b/libgcc/config/aarch64/linux-unwind.h
index a8fa1d5..70e5a8a 100644
--- a/libgcc/config/aarch64/linux-unwind.h
+++ b/libgcc/config/aarch64/linux-unwind.h
@@ -20,11 +20,13 @@
see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
.  */
 
+/* Always include AArch64 unwinder header file.  */
+#include "config/aarch64/aarch64-unwind.h"
+
 #ifndef inhibit_libc
 
 #include 
 #include 
-#include "config/aarch64/aarch64-unwind.h"
 
 
 /* Since insns are always stored LE, on a BE system the opcodes will

[Ada] Warn on non-standard check pragmas

[Arnaud Charlet]

The pragma Check_Poliy and the names Precondition / Postcondition were
introduced in GNAT before the Ada2012 standardization, and they have a
different behavior from that of the standardized pragma Assertion_Policy.
Rather than making the behavior of both more conformant we choose to preserve
the original semantics but indicate that these are deprecated constructs.

Compiling p.adb must yield:

   p.ads:2:25: warning:  Check_Policy is a non-standard pragma
   p.ads:2:25: warning:
 use Assertion_Policy and aspect names Pre/Post for Ada2012 conformance
---
package body P is
   Last_X : Integer;

   procedure Latch (X : Integer) is
   begin
  Last_X := X;
   end;
end;
--
package P is
   pragma Check_Policy (Precondition, On);
   procedure Latch (X : Integer)
 with Pre => (X > 0);
end;

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

2017-01-20  Ed Schonberg  

* sem_prag.adb (Rewrite_Assertion_Kind): If the name is
Precondition or Postcondition, and the context is pragma
Check_Policy, indicate that this Pre-Ada2012 usage is deprecated
and suggest the standard names Assertion_Policy /Pre /Post
instead.

Index: sem_prag.adb
===
--- sem_prag.adb(revision 244699)
+++ sem_prag.adb(working copy)
@@ -282,11 +282,16 @@
--  function, this routine finds the corresponding state and sets the entity
--  of N to that of the state.
 
-   procedure Rewrite_Assertion_Kind (N : Node_Id);
+   procedure Rewrite_Assertion_Kind
+ (N   : Node_Id;
+  From_Policy : Boolean := False);
--  If N is Pre'Class, Post'Class, Invariant'Class, or Type_Invariant'Class,
--  then it is rewritten as an identifier with the corresponding special
--  name _Pre, _Post, _Invariant, or _Type_Invariant. Used by pragmas Check
-   --  and Check_Policy.
+   --  and Check_Policy. If the names are Precondition or Postcondition, this
+   --  combination is deprecated in favor of Assertion_Policy and Ada2012
+   --  Aspect names. The parameter From_Policy indicates that the pragma
+   --  is the old non-standard Check_Policy and not a rewritten pragma.
 
procedure Set_Elab_Unit_Name (N : Node_Id; With_Item : Node_Id);
--  Place semantic information on the argument of an Elaborate/Elaborate_All
@@ -12807,7 +12812,8 @@
Check_Arg_Count (2);
Check_Optional_Identifier (Arg1, Name_Name);
Kind := Get_Pragma_Arg (Arg1);
-   Rewrite_Assertion_Kind (Kind);
+   Rewrite_Assertion_Kind (Kind,
+ From_Policy => Comes_From_Source (N));
Check_Arg_Is_Identifier (Arg1);
 
--  Check forbidden check kind
@@ -29448,10 +29454,14 @@
-- Rewrite_Assertion_Kind --

 
-   procedure Rewrite_Assertion_Kind (N : Node_Id) is
+   procedure Rewrite_Assertion_Kind
+ (N   : Node_Id;
+  From_Policy : Boolean := False)
+   is
   Nam : Name_Id;
 
begin
+  Nam := No_Name;
   if Nkind (N) = N_Attribute_Reference
 and then Attribute_Name (N) = Name_Class
 and then Nkind (Prefix (N)) = N_Identifier
@@ -29473,6 +29483,25 @@
return;
  end case;
 
+  --  Recommend standard use of aspect names Pre/Post
+
+  elsif Nkind (N) = N_Identifier
+and then From_Policy
+and then Serious_Errors_Detected = 0
+and then not ASIS_Mode
+  then
+ if Chars (N) = Name_Precondition
+  or else Chars (N) = Name_Postcondition
+ then
+Error_Msg_N (" Check_Policy is a non-standard pragma??", N);
+Error_Msg_N
+  (" \use Assertion_Policy and aspect names Pre/Post"
+& " for Ada2012 conformance?", N);
+ end if;
+ return;
+  end if;
+
+  if Nam /= No_Name then
  Rewrite (N, Make_Identifier (Sloc (N), Chars => Nam));
   end if;
end Rewrite_Assertion_Kind;

[Ada] Crash on overloaded function call with limited view

[Arnaud Charlet]

This patch fixes a compiler abort on a call to a function that returns a
limited view of a type. The following sources must compile quietly:

limited with Root;
package Api is
   type Object is tagged null record;

   function Is_Present (Name : in String) return Boolean;
   function Get (Name : in String) return Root.Object'Class;
end Api;

with Api;
package Root is
   type Object is new Api.Object with null record;
end Root;

with Root;
package body Api is
   function Get (Name : in String) return Root.Object'Class is
  B : Root.Object;
   begin
  return B;
   end Get;

   function Is_Present (Name : in String) return Boolean is
  O : constant Object'Class := Object'Class (Get (Name));
   begin
  return True;
   end Is_Present;
end Api;

Command: gcc -c api.adb

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

2017-01-20  Javier Miranda  

* sem_res.adb (Resolve_Call): If a function call
returns a limited view of a type and at the point of the call the
function is not declared in the extended main unit then replace
it with the non-limited view, which must be available. If the
called function is in the extended main unit then no action is
needed since the back-end handles this case.

Index: sem_res.adb
===
--- sem_res.adb (revision 244700)
+++ sem_res.adb (working copy)
@@ -6061,12 +6061,16 @@
  end;
 
   else
- --  If the function returns the limited view of type, the call must
- --  appear in a context in which the non-limited view is available.
- --  As is done in Try_Object_Operation, use the available view to
- --  prevent back-end confusion.
+ --  If the called function is not declared in the main unit and it
+ --  returns the limited view of type then use the available view (as
+ --  is done in Try_Object_Operation) to prevent back-end confusion;
+ --  the call must appear in a context where the nonlimited view is
+ --  available. If the called function is in the extended main unit
+ --  then no action is needed, because the back end handles this case.
 
- if From_Limited_With (Etype (Nam)) then
+ if not In_Extended_Main_Code_Unit (Nam)
+   and then From_Limited_With (Etype (Nam))
+ then
 Set_Etype (Nam, Available_View (Etype (Nam)));
  end if;
 

Re: [PATCH] PR72792 PR72793 relax requirements on rebind members

[Jonathan Wakely]

On 20/01/17 02:37 +, Jonathan Wakely wrote:

I misread the specifications for pointer_traits::rebind and
allocator_traits::rebind_alloc and was requiring them to be valid for
any specialization of the class templates. In fact they're only needed
if instantiated. This fixes the problem.

PR libstdc++/72792
PR libstdc++/72793
* include/bits/alloc_traits.h (__allocator_traits_base::__rebind):
Replace with class template using void_t.
(__alloc_rebind): Define in terms of
__allocator_traits_base::__rebind.
(allocator_traits): Remove unconditional static_assert for
rebind_alloc.
* include/bits/ptr_traits.h (__replace_first_arg): Remove type member.
(pointer_traits::__rebind): Replace with class template using void_t.
(pointer_traits::rebind): Define in terms of __rebind.
(pointer_traits): Remove unconditional static_assert for rebind.
* testsuite/20_util/allocator_traits/members/rebind_alloc.cc: New test.
* testsuite/20_util/pointer_traits/rebind.cc: New test.

Tested powerpc64le-linux, committed to trunk.


That patch prevented pointer_traits::rebind being instantiated
automatically when pointer_traits is instantiated.  We need a further
fix to prevent allocator_traits from doing invalid instantiations of
pointer_traits::rebind when detecting the const_pointer, void_pointer
and const_void_pointer types. Currently we rebind the pointer type too
early, even when it isn't needed, and that can fail.

With this patch we delay trying to use pointer_traits::rebind until we
know it's really needed. I've also done something similar for
difference_type and size_type, although I think that's maybe overkill
because pointer_traits::difference_type is always supposed to be
valid, and because the Allocator requirements say difference_type must
be a signed integer type, so using make_unsigned on it must also be
valid always.

Tested powerpc64le-linux, committed to trunk.

commit ab76d45be2de3e6d9c0a43044b5ff74127633a19
Author: Jonathan Wakely 
Date:   Fri Jan 20 11:48:33 2017 +

PR72792 detect allocator pointer types without invalid rebinding

	PR libstdc++/72792
	* include/bits/alloc_traits.h (__allocator_traits_base::__diff_type)
	(__allocator_traits_base::__size_type): Remove.
	(allocator_traits::_Ptr): New class template to detect const and void
	pointer types without instantiating pointer_traits::rebind
	unnecessarily.
	(allocator_traits::_Diff): Likewise for detecting difference_type.
	(allocator_traits::_Size): New class template to detect size_type
	without instantiating make_unsigned unnecessarily.
	* include/bits/ptr_traits.h (pointer_traits::element_type): Use
	__detected_or_t instead of __detected_or_t_.
	* include/std/type_traits (__detected_or_t_): Remove.
	* testsuite/20_util/allocator_traits/members/pointers.cc: New test.

diff --git a/libstdc++-v3/include/bits/alloc_traits.h b/libstdc++-v3/include/bits/alloc_traits.h
index a836711..4d1e489 100644
--- a/libstdc++-v3/include/bits/alloc_traits.h
+++ b/libstdc++-v3/include/bits/alloc_traits.h
@@ -62,10 +62,6 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 template
   using __cv_pointer = typename _Tp::const_void_pointer;
 template
-  using __diff_type = typename _Tp::difference_type;
-template
-  using __size_type = typename _Tp::size_type;
-template
   using __pocca = typename _Tp::propagate_on_container_copy_assignment;
 template
   using __pocma = typename _Tp::propagate_on_container_move_assignment;
@@ -98,15 +94,45 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   */
   using pointer = __detected_or_t;
 
+private:
+  // Select _Func<_Alloc> or pointer_traits::rebind<_Tp>
+  template class _Func, typename _Tp, typename = void>
+	struct _Ptr
+	{
+	  using type = typename pointer_traits::template rebind<_Tp>;
+	};
+
+  template class _Func, typename _Tp>
+	struct _Ptr<_Func, _Tp, __void_t<_Func<_Alloc>>>
+	{
+	  using type = _Func<_Alloc>;
+	};
+
+  // Select _A2::difference_type or pointer_traits<_Ptr>::difference_type
+  template
+	struct _Diff
+	{ using type = typename pointer_traits<_PtrT>::difference_type; };
+
+  template
+	struct _Diff<_A2, _PtrT, __void_t>
+	{ using type = typename _A2::difference_type; };
+
+  // Select _A2::size_type or make_unsigned<_DiffT>::type
+  template
+	struct _Size : make_unsigned<_DiffT> { };
+
+  template
+	struct _Size<_A2, _DiffT, __void_t>
+	{ using type = typename _A2::size_type; };
+
+public:
   /**
* @brief   The allocator's const pointer type.
*
* @c Alloc::const_pointer if that type exists, otherwise
*  pointer_traits::rebind 
   */
-  using const_pointer
-	= __detected_or_t<__ptr_rebind,
-			  __c_pointer, _Alloc>;
+  using const_pointer = typename _Ptr<__c_pointer, const value_type>::type;
 
   /**
* @brief   

Re: [Ping~]Re: [5/5][libgcc] Runtime support for AArch64 return address signing (needs new target macros)

[Richard Earnshaw (lists)]

On 20/01/17 11:54, Jiong Wang wrote:
> On 20/01/17 10:30, Christophe Lyon wrote:
>> error: 'DWARF_REGNUM_AARCH64_RA_STATE' undeclared (first use in this
>> function)
>>fs->regs.reg[DWARF_REGNUM_AARCH64_RA_STATE].loc.offset ^= 1;
>> ^
>
> Hi Christophe, could you please confirm you svn revision please?
>
> I do have done bootstrap and regression on both x86 and aarch64 before
> commit this patch.  I had forgotten to "svn add" one header file,
> but add
> it
> later.
>
 The failures started with r244673, and are still present with r244687.
 When did you add the missing file?
>>>
>>> It was r244674,
>>> https://gcc.gnu.org/ml/gcc-cvs/2017-01/msg00689.html,  so
>>> should have been included in your code.  The faliure looks strange to me
>>> then,  I will svn up and re-start a fresh bootstrap on AArch64.
>>>
>> The file is present in my git clone.
>> I'm not bootstrapping on AArch64, I'm building a cross-compiler on
>> x86_64,
>> but it shouldn't matter.
> 
> Hi Christophe,
> 
>   Thanks, I reproduced this on cross linux environment, the reason is
> the header file is not included because of the inhabit_libc guard, while
> the unwinder header file should always be included.
> 
>I will committed the attached patch as obvious, once I finished a
> fresh bootstrap, cross elf, cross linux.
> 

If this survives a cross-build, please just commit it.  It's very
unlikely that a native build will throw up any problems.

R.

>Thanks.
> 
> libgcc/
> 
> 2017-01-20  Jiong Wang  
> 
> * config/aarch64/linux-unwind.h: Always include aarch64-unwind.h.
> 
> 
> 
> k.patch
> 
> 
> diff --git a/libgcc/config/aarch64/linux-unwind.h 
> b/libgcc/config/aarch64/linux-unwind.h
> index a8fa1d5..70e5a8a 100644
> --- a/libgcc/config/aarch64/linux-unwind.h
> +++ b/libgcc/config/aarch64/linux-unwind.h
> @@ -20,11 +20,13 @@
> see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
> .  */
>  
> +/* Always include AArch64 unwinder header file.  */
> +#include "config/aarch64/aarch64-unwind.h"
> +
>  #ifndef inhibit_libc
>  
>  #include 
>  #include 
> -#include "config/aarch64/aarch64-unwind.h"
>  
>  
>  /* Since insns are always stored LE, on a BE system the opcodes will
> 

[hsa] Rename hsa.[ch] to hsa-common.[ch]

[Martin Jambor]

Hi,

because the BRIG FE run-time and HSA libgomp plugin need the same
hsa.h that is currently in libgomp/plugin/, the plan is to move that
file to top-level include/ subdirectory.

This patch renames gcc/hsa.h to gcc/hsa-common.h so that it does not
conflict with the one in include.  It was an unfortunate coincidence
the names conflicted anyway.

I am bootstrapping the patch, I will commit it to trunk shortly
afterwards.

Thanks,

Martin


2017-01-20  Martin Jambor  

* hsa.h: Renaed to hsa-common.h.  Adjusted a comment.
* hsa.c: Renaed to hsa-common.c.  Change include of gt-hsa.h to
gt-hsa-common.h.

* Makefile.in (OBJS): Rename hsa.o to hsa-common.o.
(GTFILES): Rename hsa.c to hsa-common.c.
* hsa-brig.c: Change include of hsa.h to hsa-common.h.
* hsa-dump.c: Likewise.
* hsa-gen.c: Likewise.
* hsa-regalloc.c: Likewise.
* ipa-hsa.c: Likewise.
* omp-expand.c: Likewise.
* omp-low.c: Likewise.
* toplev.c: Likewise.

diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index c53c78a2f03..78f17e4f745 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -1329,7 +1329,7 @@ OBJS = \
haifa-sched.o \
hash-map-tests.o \
hash-set-tests.o \
-   hsa.o \
+   hsa-common.o \
hsa-gen.o \
hsa-regalloc.o \
hsa-brig.o \
@@ -2516,7 +2516,7 @@ GTFILES = $(CPP_ID_DATA_H) $(srcdir)/input.h 
$(srcdir)/coretypes.h \
   $(srcdir)/sancov.c \
   $(srcdir)/ipa-devirt.c \
   $(srcdir)/internal-fn.h \
-  $(srcdir)/hsa.c \
+  $(srcdir)/hsa-common.c \
   @all_gtfiles@
 
 # Compute the list of GT header files from the corresponding C sources,
diff --git a/gcc/hsa-brig.c b/gcc/hsa-brig.c
index 5fe302f25f5..1a2d45fcc52 100644
--- a/gcc/hsa-brig.c
+++ b/gcc/hsa-brig.c
@@ -44,7 +44,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "dumpfile.h"
 #include "print-tree.h"
 #include "symbol-summary.h"
-#include "hsa.h"
+#include "hsa-common.h"
 #include "gomp-constants.h"
 
 /* Convert VAL to little endian form, if necessary.  */
diff --git a/gcc/hsa.c b/gcc/hsa-common.c
similarity index 99%
rename from gcc/hsa.c
rename to gcc/hsa-common.c
index 2035ce446a1..95636ebc9a8 100644
--- a/gcc/hsa.c
+++ b/gcc/hsa-common.c
@@ -36,7 +36,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "print-tree.h"
 #include "stringpool.h"
 #include "symbol-summary.h"
-#include "hsa.h"
+#include "hsa-common.h"
 #include "internal-fn.h"
 #include "ctype.h"
 #include "builtins.h"
@@ -991,4 +991,4 @@ hsa_internal_fn::get_argument_type (int n)
 }
 }
 
-#include "gt-hsa.h"
+#include "gt-hsa-common.h"
diff --git a/gcc/hsa.h b/gcc/hsa-common.h
similarity index 99%
rename from gcc/hsa.h
rename to gcc/hsa-common.h
index a74f2d9553b..a24bf6e5ad1 100644
--- a/gcc/hsa.h
+++ b/gcc/hsa-common.h
@@ -1309,7 +1309,7 @@ hsa_internal_fn_hasher::equal (const value_type a, const 
compare_type b)
   return a->m_fn == b->m_fn && a->m_type_bit_size == b->m_type_bit_size;
 }
 
-/* in hsa.c */
+/* in hsa-common.c */
 extern struct hsa_function_representation *hsa_cfun;
 extern hash_map  *> *hsa_decl_kernel_dependencies;
 extern hsa_summary_t *hsa_summaries;
diff --git a/gcc/hsa-dump.c b/gcc/hsa-dump.c
index 1cd128ea3b4..e2ef58693c9 100644
--- a/gcc/hsa-dump.c
+++ b/gcc/hsa-dump.c
@@ -33,7 +33,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "cgraph.h"
 #include "print-tree.h"
 #include "symbol-summary.h"
-#include "hsa.h"
+#include "hsa-common.h"
 
 /* Return textual name of TYPE.  */
 
diff --git a/gcc/hsa-gen.c b/gcc/hsa-gen.c
index 632561d5e45..7721fcc9334 100644
--- a/gcc/hsa-gen.c
+++ b/gcc/hsa-gen.c
@@ -49,7 +49,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "cgraph.h"
 #include "print-tree.h"
 #include "symbol-summary.h"
-#include "hsa.h"
+#include "hsa-common.h"
 #include "cfghooks.h"
 #include "tree-cfg.h"
 #include "cfgloop.h"
diff --git a/gcc/hsa-regalloc.c b/gcc/hsa-regalloc.c
index 5f2ac13c823..4d9441c91d4 100644
--- a/gcc/hsa-regalloc.c
+++ b/gcc/hsa-regalloc.c
@@ -35,7 +35,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "print-tree.h"
 #include "cfghooks.h"
 #include "symbol-summary.h"
-#include "hsa.h"
+#include "hsa-common.h"
 
 
 /* Process a PHI node PHI of basic block BB as a part of naive out-f-ssa.  */
diff --git a/gcc/ipa-hsa.c b/gcc/ipa-hsa.c
index 6a3f660672e..af70b0a9230 100644
--- a/gcc/ipa-hsa.c
+++ b/gcc/ipa-hsa.c
@@ -41,7 +41,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "cgraph.h"
 #include "print-tree.h"
 #include "symbol-summary.h"
-#include "hsa.h"
+#include "hsa-common.h"
 
 namespace {
 
diff --git a/gcc/omp-expand.c b/gcc/omp-expand.c
index f0e98873e28..57d9fdea85a 100644
--- a/gcc/omp-expand.c
+++ b/gcc/omp-expand.c
@@ -56,7 +56,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "cilk.h"
 #include "gomp-constants.h"
 #include "gimple-pretty-print.h"
-#include "hsa.h"
+#i

Another cprop trap_if fix, PR79125

[Bernd Schmidt]

This is essentially the same patch I sent for the previous instance of 
this problem, but this time applied to local_cprop_pass. Bootstrapped 
and tested on x86_64-linux, and it seems to fix the testcase with a ppc 
cross. Ok?



Bernd
	PR rtl-optimization/79125
	* cprop.c (local_cprop_pass): Handle cases where we make an
	unconditional trap.

	PR rtl-optimization/79125
	* gcc.dg/torture/pr79125.c: New test.

Index: gcc/cprop.c
===
--- gcc/cprop.c	(revision 244528)
+++ gcc/cprop.c	(working copy)
@@ -1248,6 +1248,8 @@ local_cprop_pass (void)
   bool changed = false;
   unsigned i;
 
+  auto_vec uncond_traps;
+
   cselib_init (0);
   FOR_EACH_BB_FN (bb, cfun)
 {
@@ -1255,6 +1257,9 @@ local_cprop_pass (void)
 	{
 	  if (INSN_P (insn))
 	{
+	  bool was_uncond_trap
+		= (GET_CODE (PATTERN (insn)) == TRAP_IF
+		   && XEXP (PATTERN (insn), 0) == const1_rtx);
 	  rtx note = find_reg_equal_equiv_note (insn);
 	  do
 		{
@@ -1273,6 +1278,13 @@ local_cprop_pass (void)
 			  break;
 			}
 		}
+		  if (!was_uncond_trap
+		  && GET_CODE (PATTERN (insn)) == TRAP_IF
+		  && XEXP (PATTERN (insn), 0) == const1_rtx)
+		{
+		  uncond_traps.safe_push (insn);
+		  break;
+		}
 		  if (insn->deleted ())
 		break;
 		}
@@ -1287,6 +1299,14 @@ local_cprop_pass (void)
 
   cselib_finish ();
 
+  while (!uncond_traps.is_empty ())
+{
+  rtx_insn *insn = uncond_traps.pop ();
+  basic_block to_split = BLOCK_FOR_INSN (insn);
+  remove_edge (split_block (to_split, insn));
+  emit_barrier_after_bb (to_split);
+}
+
   return changed;
 }
 
Index: gcc/testsuite/gcc.dg/torture/pr79125.c
===
--- gcc/testsuite/gcc.dg/torture/pr79125.c	(nonexistent)
+++ gcc/testsuite/gcc.dg/torture/pr79125.c	(working copy)
@@ -0,0 +1,32 @@
+int za;
+
+void
+hl (void)
+{
+  short int o8 = 0;
+  short int m6 = 1;
+  short int *ni = &m6;
+
+  for (;;)
+{
+  int af;
+  short int *fd = (short int *)∋
+
+  if (ni != 0)
+{
+  if (m6 != 0)
+*ni = 0;
+  else
+za = 0;
+  af = (o8 * o8) || o8;
+  if (af == 0)
+m6 /= 0; /* { dg-warning "division" } */
+  while (za != 0)
+{
+}
+}
+  *fd = &o8; /* { dg-warning "without a cast" } */
+  for (af = 0; af < 2; ++af)
+af = za;
+}
+}

Re: [WPA PATCH] Comdat group splitting

[Nathan Sidwell]

On 01/19/2017 10:26 AM, Jan Hubicka wrote:


2) For LDPR_PREVAILING_DEF members we don't make_decl_local, but instead
clear DECL_COMDAT and DECL_WEAK.  Thus forcing this decl to be the
prevailing decl in the final link

3) For decls we localize, we also clear node->externally_visible and
node->force_by_abi.  That matches the behavior for the decl of interest too
and will clue the wpa partitioning logic into knowing it needs to
hidden-externalize the decl.


So at the moment it works in a way
 1) we walk first symbol of the comdat and it is LDPR_PREVAILING_DEF and thus
we set externall visible flag
 2) we walk second symbol of the comdat and it is LDPR_PREVAILING_DEF_IRONLY
and thus we decide to privatize the whole comdat group, during this
process we force the first symbol local and clear the externally_visible
flag?


Nearly correct.  We attempt to do #2 but we fail to clear 
node->externally_visible (but we do update DECL_PUBLIC).  Thus the 
PREVAILING_DEF symbol is in an inconsistent state (which is what 
confused the partitioning logic).



I think at a time we decide on external visibility of a symbol in a comdat
group, we need to check that the comdat group as a whole is not exporte (i.e.
no LDPR_PREVAILING_DEF_EXP or incremental linking).  Then we know we can 
dissolve
the comdat group (without actually affecting visibility) and then we can
handle each symbol independently.


Could be.  I did consider splitting this loop into two (which I think is 
an outcome of what you suggest) -- one that set each nodes 
external_visiblilty as desired and the a second loop that did the 
processing.


It also occurs to me that if we did that we'd need to process the 
vardecls in a similar order.  I.e. go from the current:


foreach FN
  determine visibility
  adjust decl/break comdat
for each VAR
  determine visibility
  adjust decl/break comdat

to
foreach FN
  determine visibility
foreach VAR
  determine visibility
foreach FN
  adjust decl/maybe break comdat
foreach VAR
  adjust decl/maybe break comdat

nathan
--
Nathan Sidwell

Improve things for PR71724, in combine/if_then_else_cond

[Bernd Schmidt]

The PR is about infinite recursion in combine_simplify_rtx, because 
if_then_else_cond does strange things to an expression, and we end up 
simplifying something to itself. The patch below tries to address this 
by improving that function a little. As stated in the PR, the situation 
is that we have


(plus:SI (if_then_else:SI (eq (reg:CC 185)
(const_int 0 [0]))
(reg:SI 165)
(reg:SI 174 [ t9.0_1+4 ]))
(reg:SI 165))

Reg 165 is known to be zero or one, so it gets turned into a condition, 
and we have two different conditions on the operands. That causes us to 
fail to make the fairly obvious transformation to


 cond = reg:CC 185
 true_rtx = (plus r165 r165)
 false_rtx = (plus r174 r165)

So, when looking for situations where we have only one condition, we can 
try to undo the conversion of a plain REG into a condition, on the 
grounds that this is probably less helpful.


This seems to cure the testcase, but Segher also has a patch in the PR 
that looks like a good and more direct approach. IMO both should be 
applied. This one was bootstrapped and tested on x86_64-linux. Ok?



Bernd
	PR rtl-optimization/71724
	* combine.c (if_then_else_cond): Look for situations where it is
	beneficial to undo the work of one of the recursive calls.

Index: gcc/combine.c
===
--- gcc/combine.c	(revision 244528)
+++ gcc/combine.c	(working copy)
@@ -9044,11 +9044,31 @@ if_then_else_cond (rtx x, rtx *ptrue, rt
  the same value, compute the new true and false values.  */
   else if (BINARY_P (x))
 {
-  cond0 = if_then_else_cond (XEXP (x, 0), &true0, &false0);
-  cond1 = if_then_else_cond (XEXP (x, 1), &true1, &false1);
+  rtx op0 = XEXP (x, 0);
+  rtx op1 = XEXP (x, 1);
+  cond0 = if_then_else_cond (op0, &true0, &false0);
+  cond1 = if_then_else_cond (op1, &true1, &false1);
+
+  if ((cond0 != 0 && cond1 != 0 && !rtx_equal_p (cond0, cond1))
+	  && (REG_P (op0) || REG_P (op1)))
+	{
+	  /* Try to enable a simplification by undoing work done by
+	 if_then_else_cond if it converted a REG into something more
+	 complex.  */
+	  if (REG_P (op0))
+	{
+	  cond0 = 0;
+	  true0 = false0 = op0;
+	}
+	  else
+	{
+	  cond1 = 0;
+	  true1 = false1 = op1;
+	}
+	}
 
   if ((cond0 != 0 || cond1 != 0)
-	  && ! (cond0 != 0 && cond1 != 0 && ! rtx_equal_p (cond0, cond1)))
+	  && ! (cond0 != 0 && cond1 != 0 && !rtx_equal_p (cond0, cond1)))
 	{
 	  /* If if_then_else_cond returned zero, then true/false are the
 	 same rtl.  We must copy one of them to prevent invalid rtl

Re: [1/5][AArch64] Return address protection on AArch64

[Jiong Wang]

On 20/01/17 11:15, Jiong Wang wrote:



On 20/01/17 03:39, Andrew Pinski wrote:
On Fri, Jan 6, 2017 at 3:47 AM, Jiong Wang  
wrote:

On 11/11/16 18:22, Jiong Wang wrote:

As described in the cover letter, this patch implements return address
signing
for AArch64, it's controlled by the new option:

-msign-return-address=[none | non-leaf | all]

"none" means don't do return address signing at all on any function.
"non-leaf"
means only sign non-leaf function.  "all" means sign all functions.
Return
address signing is currently disabled on ILP32.  I haven't tested it.

The instructions added in the architecture are of 2 kinds.

* In the NOP instruction space, which allows binaries to run 
without any

traps
on older versions of the architecture. This doesn't give any 
additional
protection on older hardware but allows for the same binary to be 
used on

earlier versions of the architecture and newer versions of the
architecture.

* New instructions that are only valid for v8.3 and will trap if 
used on

earlier
versions of the architecture.

At default, once return address signing is enabled, it will only 
generates

NOP
instruction.

While if -march=armv8.3-a specified, GCC will try to use the most
efficient
pointer authentication instruction as it can.

The architecture has 2 user invisible system keys for signing and 
creating

signed addresses as part of these instructions. For some use case, the
user
might want to use difference key for different functions. The new 
option

"-msign-return-address-key=key_name" let GCC select the key used for
return
address signing.  Permissible values are "a_key" for A key and 
"b_key" for

B
key, and this option are supported by function target attribute and 
LTO

will
hopefully just work.



gcc/
2016-11-09  Jiong Wang

  * config/aarch64/aarch64-opts.h 
(aarch64_pauth_key_index): New

enum.
  (aarch64_function_type): New enum.
  * config/aarch64/aarch64-protos.h 
(aarch64_output_sign_auth_reg):

New
  declaration.
  * config/aarch64/aarch64.c (aarch64_expand_prologue): 
Sign return

  address before it's pushed onto stack.
  (aarch64_expand_epilogue): Authenticate return address 
fetched

from
  stack.
  (aarch64_output_sign_auth_reg): New function.
  (aarch64_override_options): Sanity check for ILP32 and 
ISA level.

  (aarch64_attributes): New function attributes for
"sign-return-address",
  "pauth-key".
  * config/aarch64/aarch64.md (UNSPEC_AUTH_REG,
UNSPEC_AUTH_REG1716,
  UNSPEC_SIGN_REG, UNSPEC_SIGN_REG1716, UNSPEC_STRIP_REG_SIGN,
  UNSPEC_STRIP_X30_SIGN): New unspecs.
  ("*do_return"): Generate combined instructions according 
to key

index.
  ("sign_reg", "sign_reg1716", "auth_reg", "auth_reg1716",
  "strip_reg_sign", "strip_lr_sign"): New.
  * config/aarch64/aarch64.opt (msign-return-address, 
mpauth-key):

New.
  * config/aarch64/predicates.md (aarch64_const0_const1): New
predicate.
  * doc/extend.texi (AArch64 Function Attributes): Documents
  "sign-return-address=", "pauth-key".
  * doc/invoke.texi (AArch64 Options): Documents
"-msign-return-address=",
  "-pauth-key".

gcc/testsuite/
2016-11-09  Jiong Wang

  * gcc.target/aarch64/return_address_sign_1.c: New testcase.
  * gcc.target/aarch64/return_address_sign_scope_1.c: New 
testcase.


Update the patchset according to new DWARF proposal described at

   https://gcc.gnu.org/ml/gcc-patches/2016-11/msg03010.html

One of these patches of this patch set break ILP32 building for
aarch64-elf and most likely also aarch64-linux-gnu.

/home/jenkins/workspace/BuildToolchainAARCH64_thunder_elf_upstream/toolchain/scripts/../src/libgcc/unwind-dw2.c: 


In function ‘uw_init_context_1’:
/home/jenkins/workspace/BuildToolchainAARCH64_thunder_elf_upstream/toolchain/scripts/../src/libgcc/unwind-dw2.c:1567:6: 


internal compiler error: in emit_move_insn, at expr.c:3698
ra = MD_POST_EXTRACT_ROOT_ADDR (ra);
0x8270cf emit_move_insn(rtx_def*, rtx_def*)
/home/jenkins/workspace/BuildToolchainAARCH64_thunder_elf_upstream/toolchain/scripts/../src/gcc/expr.c:3697 


0x80867b force_reg(machine_mode, rtx_def*)
Must be the Pmode issue under ILP32, I am testing a fix (I don't have 
full ILP32 environment, so can only test simply by force libgcc build 
with -mabi=ilp32)


Here is the patch.

For XPACLRI builtin which drops the signature in a pointer, it's prototype is  "void 
*foo (void *)"
FOR PAC/AUT builtin which sign or authenticate a pointer, it's prototype is "void 
*foo (void *, uint64)".

This patch adjusted those modes to make sure they strictly follow the C 
prototype. I also borrow the type define in ARM backend

  typedef unsigned _uw64 __attribute__((mode(__DI__)));

And this is need to type cast the salt value which is always DImode.

It passed my local ILP32 cross build.

OK for trunk?

gcc/
2017-01-20  Jiong 

[C++ PATCH] c++/78495 inherited ctor and inivis-ref parm

[Nathan Sidwell]

Bug 78495 is a wrong code bug caused by an invisiref parm.  When 
building the inherited ctor, we use forward_parm to create a forwarding 
reference.  That code generation considers the type of the parm to be 
'T'.  We thus end up with a tree that looks like *&PARM


The subsequent call gets 'CALL_FROM_THUNK' set.  We need that set so 
code generation doesn't copy pass-by-invisiref objects that are 
specified by the C abi (but not specified so by the C++ abi) (POD 
structs, commonly).


cp_genericize is used to mutate invisiref parm_decls from T to &T and 
bash their uses from PARM to *PARM (with suitable checking of &PARM 
turning into plain PARM).  However it explicitly skips genericizing the 
args of a CALL_FROM_THUNK tree. Thus we end up taking the address of the 
reference parm itself.


That appears to be incorrect now we have forward_parm.  This patch 
deletes that skipping.


ok?

nathan
--
Nathan Sidwell
2017-01-20  Nathan Sidwell  

	PR c++/78495 - wrong code inherited ctor and invisi-ref parm
	* cp-gimplify.c (cp_generize_r): Don't skip thunks.

	PR c++/79495
	* g++.dg/cpp1z/inh-ctor38.C: New.

Index: cp/cp-gimplify.c
===
--- cp/cp-gimplify.c	(revision 244596)
+++ cp/cp-gimplify.c	(working copy)
@@ -1103,15 +1103,7 @@ cp_genericize_r (tree *stmt_p, int *walk
   && omp_var_to_track (stmt))
 omp_cxx_notice_variable (wtd->omp_ctx, stmt);
 
-  /* Don't dereference parms in a thunk, pass the references through. */
-  if ((TREE_CODE (stmt) == CALL_EXPR && CALL_FROM_THUNK_P (stmt))
-  || (TREE_CODE (stmt) == AGGR_INIT_EXPR && AGGR_INIT_FROM_THUNK_P (stmt)))
-{
-  *walk_subtrees = 0;
-  return NULL;
-}
-
-  /* Otherwise, do dereference invisible reference parms.  */
+  /* Dereference invisible reference parms.  */
   if (wtd->handle_invisiref_parm_p && is_invisiref_parm (stmt))
 {
   *stmt_p = convert_from_reference (stmt);
Index: testsuite/g++.dg/cpp1z/inh-ctor38.C
===
--- testsuite/g++.dg/cpp1z/inh-ctor38.C	(revision 0)
+++ testsuite/g++.dg/cpp1z/inh-ctor38.C	(working copy)
@@ -0,0 +1,31 @@
+// { dg-do run { target c++11 } }
+// PR78495 failed to propagate pass-by-value struct to base ctor.
+
+struct Ptr {
+  void *ptr = 0;
+
+  Ptr() {}
+  Ptr(Ptr const&) = delete;
+  Ptr(Ptr&& other) : ptr (other.ptr) {}
+};
+
+struct Base {
+  Ptr val;
+  Base(Ptr val_) : val(static_cast(val_)) {}
+};
+
+struct Derived: Base {
+  using Base::Base;
+};
+
+void *Foo () {
+  Ptr ptr;
+
+  Derived d(static_cast(ptr));
+
+  return d.val.ptr;
+}
+
+int main () {
+  return Foo () != 0;
+}

Re: [PATCH] Add AVX512 k-mask intrinsics

[Andrew Senkevich]

2017-01-19 20:55 GMT+03:00 Kirill Yukhin :
> On 19 Jan 19:42, Andrew Senkevich wrote:
>> 2017-01-19 13:39 GMT+03:00 Kirill Yukhin :
>> > Hi Andrew,
>> > On 18 Jan 15:45, Andrew Senkevich wrote:
>> >> 2017-01-17 16:51 GMT+03:00 Jakub Jelinek :
>> >> > On Tue, Jan 17, 2017 at 04:03:08PM +0300, Andrew Senkevich wrote:
>> >> >> > I've played a bit w/ SDE. And looks like operands are not early 
>> >> >> > clobber:
>> >> >> > TID0: INS 0x004003ee AVX512VEX kmovd k0, eax
>> >> >> > TID0:   k0 := _
>> >> >> > ...
>> >> >> > TID0: INS 0x004003f4 AVX512VEX kshiftlw k0, k0, 
>> >> >> > 0x3
>> >> >> > TID0:   k0 := _fff8
>> >> >> >
>> >> >> > You can see that same dest and source works just fine.
>> >> >>
>> >> >> Hmm, I looked only on what ICC generates, and it was not correct way.
>> >> >
>> >> > I've just tried
>> >> > int
>> >> > main ()
>> >> > {
>> >> >   unsigned int a = 0x;
>> >> >   asm volatile ("kmovw %1, %%k6; kshiftlw $1, %%k6, %%k6; kmovw %%k6, 
>> >> > %0" : "=r" (a) : "r" (a) : "k6");
>> >> >   __builtin_printf ("%x\n", a);
>> >> >   return 0;
>> >> > }
>> >> > on KNL and got 0x.
>> >> > Are you going to report to the SDM authors so that they fix it up?
>> >> > E.g. using TEMP <- SRC1[0:...] before DEST[...] <- 0 and using TEMP
>> >> > instead of SRC1[0:...] would fix it, or filling up TEMP first and only
>> >> > at the end assigning DEST <- TEMP etc. would do.
>> >>
>> >> Yes, we will work on it.
>> >>
>> >> Attached patch refactored in part of builtints declarations and tests, is 
>> >> it Ok?
>> >
>> > Could you please add runtime tests for new intrinsics as well?
>>
>> Attached with runtime tests.
> Great! Thanks. Patch is OK for main trunk.
>
> --
> Thanks, K
>>
>> gcc/
>> * config/i386/avx512bwintrin.h: Add k-mask registers shift intrinsics.
>> * config/i386/avx512dqintrin.h: Ditto.
>> * config/i386/avx512fintrin.h: Ditto.
>> * config/i386/i386-builtin-types.def: Add new types.
>> * gcc/config/i386/i386.c: Handle new types.
>> * config/i386/i386-builtin.def (__builtin_ia32_kshiftliqi,
>> __builtin_ia32_kshiftlihi, __builtin_ia32_kshiftlisi,
>> __builtin_ia32_kshiftlidi, __builtin_ia32_kshiftriqi,
>> __builtin_ia32_kshiftrihi, __builtin_ia32_kshiftrisi,
>> __builtin_ia32_kshiftridi): New.
>> * config/i386/sse.md (k): Rename *k.
>>
>> gcc/testsuite/
>> * gcc.target/i386/avx512bw-kshiftld-1.c: New test.
>> * gcc.target/i386/avx512bw-kshiftlq-1.c: Ditto.
>> * gcc.target/i386/avx512dq-kshiftlb-1.c: Ditto.
>> * gcc.target/i386/avx512f-kshiftlw-1.c: Ditto.
>> * gcc.target/i386/avx512bw-kshiftrd-1.c: Ditto.
>> * gcc.target/i386/avx512bw-kshiftrq-1.c: Ditto.
>> * gcc.target/i386/avx512dq-kshiftrb-1.c: Ditto.
>> * gcc.target/i386/avx512f-kshiftrw-1.c: Ditto.
>> * gcc.target/i386/avx512bw-kshiftld-2.c: Ditto.
>> * gcc.target/i386/avx512bw-kshiftlq-2.c: Ditto.
>> * gcc.target/i386/avx512bw-kshiftrd-2.c: Ditto.
>> * gcc.target/i386/avx512bw-kshiftrq-2.c: Ditto.
>> * gcc.target/i386/avx512dq-kshiftlb-2.c: Ditto.
>> * gcc.target/i386/avx512dq-kshiftrb-2.c: Ditto.
>> * gcc.target/i386/avx512f-kshiftlw-2.c: Ditto.
>> * gcc.target/i386/avx512f-kshiftrw-2.c: Ditto.
>> * gcc.target/i386/avx-1.c: Test new intrinsics.
>> * gcc.target/i386/sse-13.c: Ditto.
>> * gcc.target/i386/sse-23.c: Ditto.

Hi,

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.


--
WBR,
Andrew


avx512-kmask-intrin-part5.patch
Description: Binary data

Re: [PATCH] Use arclinux_nps linker emulation for nps400

[Andrew Burgess]

* Graham Markall  [2016-12-12 20:44:17 +]:

> Hi Claudiu,
> 
> On 12/12/16 19:18, Claudiu Zissulescu wrote:
> > It looks sane to me, please apply (ask Andrew to do it for you)
> > 
> > //Claudiu
> 
> Many thanks for the quick review. I'll ask Andrew to do it once the
> binutils patch is approved and applied.

I've pushed this as revision 244712.  This should only effect arc/nps
(so -mcpu=nps400).

Thanks,
Andrew

Re: [C++ PATCH] c++/78495 inherited ctor and inivis-ref parm

[Jason Merrill]

On Fri, Jan 20, 2017 at 8:15 AM, Nathan Sidwell  wrote:
> Bug 78495 is a wrong code bug caused by an invisiref parm.  When building
> the inherited ctor, we use forward_parm to create a forwarding reference.
> That code generation considers the type of the parm to be 'T'.  We thus end
> up with a tree that looks like *&PARM
>
> The subsequent call gets 'CALL_FROM_THUNK' set.  We need that set so code
> generation doesn't copy pass-by-invisiref objects that are specified by the
> C abi (but not specified so by the C++ abi) (POD structs, commonly).
>
> cp_genericize is used to mutate invisiref parm_decls from T to &T and bash
> their uses from PARM to *PARM (with suitable checking of &PARM turning into
> plain PARM).  However it explicitly skips genericizing the args of a
> CALL_FROM_THUNK tree. Thus we end up taking the address of the reference
> parm itself.
>
> That appears to be incorrect now we have forward_parm.  This patch deletes
> that skipping.

Hmm, I would guess that if we're going to do this we need to also use
forward_parm in maybe_thunk_body.

Jason

Re: [PATCH] Add AVX512 k-mask intrinsics

[Uros Bizjak]

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.

Otherwise, the patch LGTM, but I'l leave the final approval to Kirill.

Uros.

Re: [PATCH] C++: fix fix-it hints for misspellings within explicit namespaces (v2)

[Jason Merrill]

On Thu, Jan 19, 2017 at 3:56 PM, David Malcolm  wrote:
> On Thu, 2017-01-19 at 13:15 -0500, Jason Merrill wrote:
>> On Wed, Jan 18, 2017 at 5:29 PM, David Malcolm 
>> wrote:
>> > Here's a version of the patch which simply tweaks
>> > cp_parser_primary_expression's call to finish_id_expression so that
>> > it passes the location of the id_expression, rather than that of
>> > id_expr_token.
>> >
>> > The id_expression in question came from cp_parser_id_expression,
>> > whereas the id_expr_token is the first token within the id
>> > -expression.
>> >
>> > The location passed here to finish_id_expression only affects:
>> > the location used for name-lookup errors, and for the resulting
>> > decl cp_expr.  Given that the following code immediately does this:
>> > decl.set_location (id_expr_token->location);
>>
>> What happens if we use id_expression.get_location() here, too?
>>
>> OK.
>
> With that other change it bootstraps but introduces some regressions:
>
>  PASS -> FAIL : g++.dg/cpp0x/pr51420.C  -std=c++11  (test for errors, line 6)
>  PASS -> FAIL : g++.dg/cpp0x/pr51420.C  -std=c++11 (test for excess errors)
>  PASS -> FAIL : g++.dg/cpp0x/pr51420.C  -std=c++14  (test for errors, line 6)
>  PASS -> FAIL : g++.dg/cpp0x/pr51420.C  -std=c++14 (test for excess errors)
>  PASS -> FAIL : g++.dg/cpp0x/udlit-declare-neg.C  -std=c++11  (test for 
> errors, line 11)
>  PASS -> FAIL : g++.dg/cpp0x/udlit-declare-neg.C  -std=c++11  (test for 
> errors, line 14)
>  PASS -> FAIL : g++.dg/cpp0x/udlit-declare-neg.C  -std=c++11  (test for 
> errors, line 5)
>  PASS -> FAIL : g++.dg/cpp0x/udlit-declare-neg.C  -std=c++11  (test for 
> errors, line 8)
>  PASS -> FAIL : g++.dg/cpp0x/udlit-declare-neg.C  -std=c++11 (test for excess 
> errors)
>  PASS -> FAIL : g++.dg/cpp0x/udlit-declare-neg.C  -std=c++14  (test for 
> errors, line 11)
>  PASS -> FAIL : g++.dg/cpp0x/udlit-declare-neg.C  -std=c++14  (test for 
> errors, line 14)
>  PASS -> FAIL : g++.dg/cpp0x/udlit-declare-neg.C  -std=c++14  (test for 
> errors, line 5)
>  PASS -> FAIL : g++.dg/cpp0x/udlit-declare-neg.C  -std=c++14  (test for 
> errors, line 8)
>  PASS -> FAIL : g++.dg/cpp0x/udlit-declare-neg.C  -std=c++14 (test for excess 
> errors)
>
> It would change:
>
> g++.dg/cpp0x/pr51420.C: In function ‘void foo()’:
> g++.dg/cpp0x/pr51420.C:6:13: error: ‘operator""_F’ was not declared in this 
> scope
>float x = operator"" _F();  //  { dg-error  "13:'operator\"\"_F' was not 
> declared in this scope" }
>  ^~~~
> g++.dg/cpp0x/pr51420.C:6:13: note: suggested alternative: ‘operator new’
>float x = operator"" _F();  //  { dg-error  "13:'operator\"\"_F' was not 
> declared in this scope" }
>  ^~~~
>  operator new
>
> to:
>
> g++.dg/cpp0x/pr51420.C: In function ‘void foo()’:
> g++.dg/cpp0x/pr51420.C:6:27: error: ‘operator""_F’ was not declared in this 
> scope
>float x = operator"" _F();  //  { dg-error  "13:'operator\"\"_F' was not 
> declared in this scope" }
>^
>
> and would change:
>
> g++.dg/cpp0x/udlit-declare-neg.C:5:9: error: ‘operator""_Bar’ was not 
> declared in this scope
>  int i = operator"" _Bar('x');  // { dg-error "9:'operator\"\"_Bar' was not 
> declared in this scope" }
>  ^~~~
> g++.dg/cpp0x/udlit-declare-neg.C:5:9: note: suggested alternative: ‘operator 
> new’
>  int i = operator"" _Bar('x');  // { dg-error "9:'operator\"\"_Bar' was not 
> declared in this scope" }
>  ^~~~
>  operator new
>
> to:
>
> g++.dg/cpp0x/udlit-declare-neg.C:5:28: error: ‘operator""_Bar’ was not 
> declared in this scope
>  int i = operator"" _Bar('x');  // { dg-error "9:'operator\"\"_Bar' was not 
> declared in this scope" }
> ^
>
> (DejaGnu picked up on this via the changing column numbers, but it
> didn't detect the missing "suggested alternative").
>
>
> With the patch I posted as-is, we get:
>
> g++.dg/cpp0x/pr51420.C:6:13: error: ‘operator""_F’ was not declared in this 
> scope
>float x = operator"" _F();  //  { dg-error  "13:'operator\"\"_F' was not 
> declared in this scope" }
>  ^~~~
>
> and:
>
> g++.dg/cpp0x/udlit-declare-neg.C:5:9: error: ‘operator""_Bar’ was not 
> declared in this scope
>  int i = operator"" _Bar('x');  // { dg-error "9:'operator\"\"_Bar' was not 
> declared in this scope" }
>  ^~~~
>
> i.e. the same locations as the status quo, but dropping the suggested
> "operator new" hint.
>
>
> Is the patch still OK as-is?

Yes.

Jason

GCC 7 Status report, trunk in regression/documentation fixes mode now (2017-01-20)

[Richard Biener]

Status
==

The trunk is now in regression and documentation fixes mode (Stage 4)
thus as if it were a release branch.  We still have the pending adoptions of
the BRIG FE and the RISC-V port.


Quality Data


Priority  #   Change from last report
---   ---
P1   25   +  13
P2  127   -  11
P3   37   -  51
P4  134
P5   30
---   ---
Total P1-P3 189   -  49
Total   353   -  49


Previous Report
===

https://gcc.gnu.org/ml/gcc/2017-01/msg00058.html

Bump BASE-VER

[Richard Biener]

As our development plan says, stage4 means bumping to 7.0.1.

Richard.

2017-01-20  Richard Biener  

* BASE-VER: Bump to 7.0.1.
Index: gcc/BASE-VER
===
--- gcc/BASE-VER(revision 244712)
+++ gcc/BASE-VER(working copy)
@@ -1 +1 @@
-7.0.0
+7.0.1

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

[Martin Liška]

On 01/20/2017 12:49 PM, Martin Liška wrote:
> Great, thanks a lot. I'm going to re-trigger asan-bootstrap with your patch.
> I'm also adding gcc/testsuite/gcc.dg/asan/use-after-scope-10.c that is a valid
> test-case for this issue.

Hi.

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?

Thanks,
Martin

Re: [PATCH, ARM] PR71607: New approach to arm_disable_literal_pool

[Ramana Radhakrishnan]

On Wed, Dec 28, 2016 at 9:58 AM, Andre Vieira (lists)
 wrote:
> On 29/11/16 09:45, Andre Vieira (lists) wrote:
>> On 17/11/16 10:00, Ramana Radhakrishnan wrote:
>>> On Thu, Oct 6, 2016 at 2:57 PM, Andre Vieira (lists)
>>>  wrote:
 Hello,

 This patch tackles the issue reported in PR71607. This patch takes a
 different approach for disabling the creation of literal pools. Instead
 of disabling the patterns that would normally transform the rtl into
 actual literal pools, it disables the creation of this literal pool rtl
 by making the target hook TARGET_CANNOT_FORCE_CONST_MEM return true if
 arm_disable_literal_pool is true. I added patterns to split floating
 point constants for both SF and DFmode. A pattern to handle the
 addressing of label_refs had to be included as well since all
 "memory_operand" patterns are disabled when
 TARGET_CANNOT_FORCE_CONST_MEM returns true. Also the pattern for
 splitting 32-bit immediates had to be changed, it was not accepting
 unsigned 32-bit unsigned integers with the MSB set. I believe
 const_int_operand expects the mode of the operand to be set to VOIDmode
 and not SImode. I have only changed it in the patterns that were
 affecting this code, though I suggest looking into changing it in the
 rest of the ARM backend.

 I added more test cases. No regressions for arm-none-eabi with
 Cortex-M0, Cortex-M3 and Cortex-M7.

 Is this OK for trunk?
>>>
>>> Including -mslow-flash-data in your multilib flags ? If no regressions
>>> with that ok .
>>>
>>>
>>> regards
>>> Ramana
>>>

>>
>> Hello,
>>
>> I found some new ICE's with the -mslow-flash-data testing so I had to
>> rework this patch. I took the opportunity to rebase it as well.
>>
>> The problem was with the way the old version of the patch handled label
>> references.  After some digging I found I wasn't using the right target
>> hook and so I implemented the 'TARGET_USE_BLOCKS_FOR_CONSTANT_P' for
>> ARM.  This target hook determines whether a literal pool ends up in an
>> 'object_block' structure. So I reverted the changes made in the old
>> version of the patch to the ARM implementation of the
>> 'TARGET_CANNOT_FORCE_CONST_MEM' hook and rely on
>> 'TARGET_USE_BLOCKS_FOR_CONSTANT_P' instead. This patch adds an ARM
>> implementation for this hook that returns false if
>> 'arm_disable_literal_pool' is set to true and true otherwise.
>>
>> This version of the patch also reverts back to using the check for
>> 'SYMBOL_REF' in 'thumb2_legitimate_address_p' that was removed in the
>> last version, this code is required to place the label references in
>> rodata sections.
>>
>> Another thing this patch does is revert the changes made to the 32-bit
>> constant split in arm.md. The reason this was needed before was because
>> 'real_to_target' returns a long array and does not sign-extend values in
>> it, which would make sense on hosts with 64-bit longs. To fix this the
>> value is now casted to 'int' first.  It would probably be a good idea to
>> change the 'real_to_target' function to return an array with
>> 'HOST_WIDE_INT' elements instead and either use all 64-bits or
>> sign-extend them.  Something for the future?
>>
>> I added more test cases in this patch and reran regression tests for:
>> Cortex-M0, Cortex-M4 with and without -mslow-flash-data. Also did a
>> bootstrap+regressions on arm-none-linux-gnueabihf.
>>
>> Is this OK for trunk?
>>
>> Cheers,
>> Andre
>>
>> gcc/ChangeLog:
>>
>> 2016-11-29  Andre Vieira  
>>
>> PR target/71607
>> * config/arm/arm.md (use_literal_pool): Removes.
>> (64-bit immediate split): No longer takes cost into consideration
>> if 'arm_disable_literal_pool' is enabled.
>> * config/arm/arm.c (arm_use_blocks_for_constant_p): New.
>> (TARGET_USE_BLOCKS_FOR_CONSTANT_P): Define.
>> (arm_max_const_double_inline_cost): Remove use of
>> arm_disable_literal_pool.
>> * config/arm/vfp.md (no_literal_pool_df_immediate): New.
>> (no_literal_pool_sf_immediate): New.
>>
>>
>> gcc/testsuite/ChangeLog:
>>
>> 2016-11-29  Andre Vieira  
>> Thomas Preud'homme  
>>
>> PR target/71607
>> * gcc.target/arm/thumb2-slow-flash-data.c: Renamed to ...
>> * gcc.target/arm/thumb2-slow-flash-data-1.c: ... this.
>> * gcc.target/arm/thumb2-slow-flash-data-2.c: New.
>> * gcc.target/arm/thumb2-slow-flash-data-3.c: New.
>> * gcc.target/arm/thumb2-slow-flash-data-4.c: New.
>> * gcc.target/arm/thumb2-slow-flash-data-5.c: New.
>>
> Hello,
>
> As I have mentioned in my commit message for the fix on embedded-6  (see
> https://gcc.gnu.org/ml/gcc-patches/2016-12/msg01304.html) I found an
> issue with this code when testing its backport on the embedded-6-branch.
>
> I misread the definition of the target hook
> TARGET_USE_BLOCKS_FOR_CONSTANT_P and it seems the way I implemented it
> before only changed code generation if the -mslow-flash-data option
> wasn't passed. I.e. 

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

[Jakub Jelinek]

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).
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

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

[Bin.Cheng]

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?

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.
>>
diff --git a/gcc/testsuite/gfortran.dg/pr70754.f90 
b/gcc/testsuite/gfortran.dg/pr70754.f90
new file mode 100644
index 000..d7e790c
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr70754.f90
@@ -0,0 +1,35 @@
+! { dg-do compile }
+! { dg-options "-Ofast" }
+module m
+  implicit none
+  private
+  save
+
+  integer, parameter, public :: &
+ii4  = selected_int_kind(6), &
+rr8  = selected_real_kind(13)
+
+  integer (ii4), dimension(40,40,199), public :: xyz
+  public :: foo
+contains
+  subroutine foo(a)
+real (rr8), dimension(40,40), intent(out) :: a
+real (rr8), dimension(40,40) :: b
+integer (ii4), dimension(40,40) :: c
+integer  i, j
+
+do i=1,20
+  b(i,j) = 123 * a(i,j) + 34 * a(i,j+1) &
+ + 34 * a(i,j-1) + a(i+1,j+1) &
+ + a(i+1,j-1) + a(i-1,j+1) &
+ + a(i-1,j-1)
+  c(i,j) = 123
+end do
+
+where ((xyz(:,:,2) /= 0) .and. (c /= 0))
+  a = b/real(c)
+elsewhere
+  a = 456
+endwhere
+ end subroutine foo
+end module m
diff --git a/gcc/tree-predcom.c b/gcc/tree-predcom.c
index f0b70a6..9723e9c 100644
--- a/gcc/tree-predcom.c
+++ b/gcc/tree-predcom.c
@@ -2164,10 +2164,11 @@ remove_name_from_operation (gimple *stmt, tree op)
 }
 
 /* Reassociates the expression in that NAME1 and NAME2 are used so that they
-   are combined in a single statement, and returns this statement.  */
+   are combined in a single statement, and returns this statement.  Note the
+   statement is inserted before INSERT_BEFORE if it's not NULL.  */
 
 static gimple *

Re: [Ping~]Re: [5/5][libgcc] Runtime support for AArch64 return address signing (needs new target macros)

[Christophe Lyon]

On 20 January 2017 at 12:54, Jiong Wang  wrote:
> On 20/01/17 10:30, Christophe Lyon wrote:
>>
>> error: 'DWARF_REGNUM_AARCH64_RA_STATE' undeclared (first use in this
>> function)
>>fs->regs.reg[DWARF_REGNUM_AARCH64_RA_STATE].loc.offset ^= 1;
>> ^
>
>
> Hi Christophe, could you please confirm you svn revision please?
>
> I do have done bootstrap and regression on both x86 and aarch64 before
> commit this patch.  I had forgotten to "svn add" one header file, but
> add
> it
> later.
>
 The failures started with r244673, and are still present with r244687.
 When did you add the missing file?
>>>
>>>
>>> It was r244674, https://gcc.gnu.org/ml/gcc-cvs/2017-01/msg00689.html,  so
>>> should have been included in your code.  The faliure looks strange to me
>>> then,  I will svn up and re-start a fresh bootstrap on AArch64.
>>>
>> The file is present in my git clone.
>> I'm not bootstrapping on AArch64, I'm building a cross-compiler on x86_64,
>> but it shouldn't matter.
>
>
> Hi Christophe,
>
>   Thanks, I reproduced this on cross linux environment, the reason is the
> header file is not included because of the inhabit_libc guard, while the
> unwinder header file should always be included.
>
>I will committed the attached patch as obvious, once I finished a fresh
> bootstrap, cross elf, cross linux.
>

After you committed this (r244710), my cross build for aarch64-linux-gnu
now passes.

I'm now left with the build failure reported by Andrew on aarch64(_be)-none-elf.

Thanks for the fix.

Christophe.

>Thanks.
>
> libgcc/
>
> 2017-01-20  Jiong Wang  
>
> * config/aarch64/linux-unwind.h: Always include aarch64-unwind.h.
>
>

Re: [PATCH][ARM] PR target/71270 fix neon_valid_immediate for big-endian

[Richard Earnshaw (lists)]

On 06/01/17 11:54, Kyrill Tkachov wrote:
> Hi all,
> 
> In this wrong-code issue the RTL tries to load a const_vector:
> (const_vector:V8QI [
> (const_int 1 [0x1])
> (const_int 0 [0])
> (const_int 1 [0x1])
> (const_int 0 [0])
> (const_int 1 [0x1])
> (const_int 0 [0])
> (const_int 1 [0x1])
> (const_int 0 [0])
> ])
> 
> into a NEON register. The logic for that is in neon_valid_immediate
> which does a number of tricks
> to decide what value and of what size to do a VMOV on to load the
> correct vector immediate into the register.
> It goes wrong on big-endian. On both big and little-endian this outputs:
> vmov.i16d18, #0x1
> 
> This is wrong on big-endian. The vector layout has to be such as if
> loaded from memory.
> I've tried various approaches of fixing neon_valid_immediate to generate
> the correct immediate but have been unsuccessful,
> resulting in regressions in various parts of the testsuite or making a
> big mess of the function.
> 
> Given that armeb is not a target of major concern I believe the safest
> route at this stage is to only allow vector constants
> that will obviously work on big-endian, that is the ones that are just a
> single element duplicated in all lanes.
> 
> This patch fixes the execution failures:
> FAIL: gfortran.dg/intrinsic_pack_1.f90
> FAIL: gfortran.dg/c_f_pointer_logical.f03
> FAIL: gcc.dg/torture/pr60183.c
> FAIL: gcc.dg/vect/pr51581-4.c
> 
> on armeb-none-eabi.
> 
> Ok for trunk?
> 
> Thanks,
> Kyrill
> 
> 2017-01-06  Kyrylo Tkachov  
> 
> PR target/71270
> * config/arm/arm.c (neon_valid_immediate): Reject vector constants
> in big-endian mode when they are not a single duplicated value.
> 

Ok, but if you plan to close the PR above, please create a new
'enhancement' PR to fix the missed optimization.

R.

> armeb-vec.patch
> 
> 
> diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
> index 
> 45e0a3cd11fa650f456f7382ffbbcd1c932b95eb..2beee8ebe94eeadd6fb1d5b119e3b474e1ab902a
>  100644
> --- a/gcc/config/arm/arm.c
> +++ b/gcc/config/arm/arm.c
> @@ -11542,6 +11542,12 @@ neon_valid_immediate (rtx op, machine_mode mode, int 
> inverse,
>   return 18;
>  }
>  
> +  /* The tricks done in the code below apply for little-endian vector layout.
> + For big-endian vectors only allow vectors of the form { a, a, a..., a }.
> + FIXME: Implement logic for big-endian vectors.  */
> +  if (BYTES_BIG_ENDIAN && vector && !const_vec_duplicate_p (op))
> +return -1;
> +
>/* Splat vector constant out into a byte vector.  */
>for (i = 0; i < n_elts; i++)
>  {
> 

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

[Markus Trippelsdorf]

On 2017.01.20 at 15:27 +0100, 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).

Another possibility would be to disable use-after-scope for gcc-7 (like
LLVM) and re-enable it for gcc-8.

diff --git a/gcc/opts.c b/gcc/opts.c
index 5f573a16ff15..2664b54133e4 100644
--- a/gcc/opts.c
+++ b/gcc/opts.c
@@ -993,7 +993,7 @@ finish_options (struct gcc_options *opts, struct 
gcc_options *opts_set,
  enabled.  */
   if ((opts->x_flag_sanitize & SANITIZE_USER_ADDRESS)
   && !opts_set->x_flag_sanitize_address_use_after_scope)
-opts->x_flag_sanitize_address_use_after_scope = true;
+opts->x_flag_sanitize_address_use_after_scope = false;

   /* Force -fstack-reuse=none in case -fsanitize-address-use-after-scope
  is enabled.  */

-- 
Markus

Re: [PATCH][ARM] PR target/71270 fix neon_valid_immediate for big-endian

[Kyrill Tkachov]

On 20/01/17 14:33, Richard Earnshaw (lists) wrote:

On 06/01/17 11:54, Kyrill Tkachov wrote:

Hi all,

In this wrong-code issue the RTL tries to load a const_vector:
(const_vector:V8QI [
 (const_int 1 [0x1])
 (const_int 0 [0])
 (const_int 1 [0x1])
 (const_int 0 [0])
 (const_int 1 [0x1])
 (const_int 0 [0])
 (const_int 1 [0x1])
 (const_int 0 [0])
 ])

into a NEON register. The logic for that is in neon_valid_immediate
which does a number of tricks
to decide what value and of what size to do a VMOV on to load the
correct vector immediate into the register.
It goes wrong on big-endian. On both big and little-endian this outputs:
vmov.i16d18, #0x1

This is wrong on big-endian. The vector layout has to be such as if
loaded from memory.
I've tried various approaches of fixing neon_valid_immediate to generate
the correct immediate but have been unsuccessful,
resulting in regressions in various parts of the testsuite or making a
big mess of the function.

Given that armeb is not a target of major concern I believe the safest
route at this stage is to only allow vector constants
that will obviously work on big-endian, that is the ones that are just a
single element duplicated in all lanes.

This patch fixes the execution failures:
FAIL: gfortran.dg/intrinsic_pack_1.f90
FAIL: gfortran.dg/c_f_pointer_logical.f03
FAIL: gcc.dg/torture/pr60183.c
FAIL: gcc.dg/vect/pr51581-4.c

on armeb-none-eabi.

Ok for trunk?

Thanks,
Kyrill

2017-01-06  Kyrylo Tkachov  

 PR target/71270
 * config/arm/arm.c (neon_valid_immediate): Reject vector constants
 in big-endian mode when they are not a single duplicated value.


Ok, but if you plan to close the PR above, please create a new
'enhancement' PR to fix the missed optimization.


Thanks, I've committed it as r244716 and opened PR 79166 to track
the missed optimisation.

Kyrill


R.


armeb-vec.patch


diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 
45e0a3cd11fa650f456f7382ffbbcd1c932b95eb..2beee8ebe94eeadd6fb1d5b119e3b474e1ab902a
 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -11542,6 +11542,12 @@ neon_valid_immediate (rtx op, machine_mode mode, int 
inverse,
return 18;
  }
  
+  /* The tricks done in the code below apply for little-endian vector layout.

+ For big-endian vectors only allow vectors of the form { a, a, a..., a }.
+ FIXME: Implement logic for big-endian vectors.  */
+  if (BYTES_BIG_ENDIAN && vector && !const_vec_duplicate_p (op))
+return -1;
+
/* Splat vector constant out into a byte vector.  */
for (i = 0; i < n_elts; i++)
  {

Re: [ARM,AArch64][testsuite] Fix format string in AdvSIMD tests

[Richard Earnshaw (lists)]

On 17/01/17 08:52, Christophe Lyon wrote:
> Hi,
> 
> This patch fixes inconsistencies in the format strings used to emit
> error messages when problems are detected in the AdvSIMD tests. They
> are not used normally since there is currently no error, but Doko
> complained about warnings when he runs the testsuite with -Wformat=1.
> 
> The patch consists in:
> * New CHECK_POLY() helper, uses an union to print poly*_t values.
> * Call it when needed (everywhere the intrinsic result is of poly*_t type)
> * Fix a few places where PRIxNN didn't match the size of the actual value.
> 
> Tested on aarch64 and arm with no regression. Additional runs of the
> tests with -Wformat=1 showed no warning.
> 
> Is it OK for now, or should I wait until stage1?
> 

OK now (it's testsuite only).

R.

> Thanks,
> 
> Christophe
> 
> 
> neon-warnings.chlog.txt
> 
> 
> gcc/testsuite/ChangeLog:
> 
> 2017-01-17  Christophe Lyon  
> 
>   * gcc.target/aarch64/advsimd-intrinsics/arm-neon-ref.h (CHECK_POLY): 
> New.
>   (CHECK_RESULTS_NAMED_NO_FP16): Call CHECK_POLY instead of CHECK
>   for poly*_t types.
>   * gcc.target/aarch64/advsimd-intrinsics/vcnt.c (FNNAME): Likewise.
>   * gcc.target/aarch64/advsimd-intrinsics/vcombine.c (void
>   exec_vcombine): Likewise.
>   * gcc.target/aarch64/advsimd-intrinsics/vcreate.c (FNNAME): Likewise.
>   * gcc.target/aarch64/advsimd-intrinsics/vget_high.c (void 
> exec_vget_high): Likewise.
>   * gcc.target/aarch64/advsimd-intrinsics/vget_low.c (void 
> exec_vget_low): Likewise.
>   * gcc.target/aarch64/advsimd-intrinsics/vldX.c (void exec_vldX): 
> Likewise.
>   * gcc.target/aarch64/advsimd-intrinsics/vldX_dup.c (void 
> exec_vldX_dup): Likewise.
>   * gcc.target/aarch64/advsimd-intrinsics/vldX_lane.c (void 
> exec_vldX_lane): Likewise.
>   * gcc.target/aarch64/advsimd-intrinsics/vmul.c: Likewise.
>   * gcc.target/aarch64/advsimd-intrinsics/vmvn.c: Likewise.
>   * gcc.target/aarch64/advsimd-intrinsics/vqtbX.c (void exec_vqtbX): 
> Likewise.
>   * gcc.target/aarch64/advsimd-intrinsics/vreinterpret_p128.c: Likewise.
>   * gcc.target/aarch64/advsimd-intrinsics/vrev.c (void exec_vrev): 
> Likewise.
>   * gcc.target/aarch64/advsimd-intrinsics/vsXi_n.inc: Likewise.
>   * gcc.target/aarch64/advsimd-intrinsics/vshuffle.inc: Likewise.
>   * gcc.target/aarch64/advsimd-intrinsics/vsli_n.c (void vsli_extra): 
> Likewise.
>   * gcc.target/aarch64/advsimd-intrinsics/vsri_n.c (void vsri_extra): 
> Likewise.
>   * gcc.target/aarch64/advsimd-intrinsics/vstX_lane.c (void 
> exec_vstX_lane): Likewise.
>   * gcc.target/aarch64/advsimd-intrinsics/vtbX.c (void exec_vtbX): 
> Likewise.
>   * gcc.target/aarch64/advsimd-intrinsics/p64_p128.c (int main):
>   Likewise.
>   (TEST_VGET_LANE): Cast to uint to avoid warning.
>   * gcc.target/aarch64/advsimd-intrinsics/unary_sat_op.inc (void
>   FNNAME): Fix PRIx format for int16_t, int32_t, uint16_t, uint32_t.
>   * gcc.target/aarch64/advsimd-intrinsics/vfms_vfma_n.c (void
>   exec_vfma_vfms_n): Fix PRIx format for float64_t.
>   * gcc.target/aarch64/advsimd-intrinsics/vmovn.c (void exec_vmovn):
>   Fix PRIx format for int8_t, int16_t, uint8_t, uint16_t.
>   * gcc.target/aarch64/advsimd-intrinsics/vmul_lane.c (void
>   exec_vmul_lane): Fix PRIx format for int16_t, uint16_t.
>   * gcc.target/aarch64/advsimd-intrinsics/vmul_n.c: Likewise.
>   * gcc.target/aarch64/advsimd-intrinsics/vmull.c (void exec_vmull):
>   Fix PRIx format for int16_t, int64_t, uint16_t, uint64_t. Call
>   CHECK_POLY instead of CHECK for poly64_t types.
>   * gcc.target/aarch64/advsimd-intrinsics/vmull_lane.c (void
>   exec_vmull_lane): Fix PRIx format for int64_t, uint64_t.
>   * gcc.target/aarch64/advsimd-intrinsics/vpXXX.inc:
>   Fix PRIx format for int8_t, int16_t, uint8_t, uint16_t.
>   * gcc.target/aarch64/advsimd-intrinsics/vqabs.c (void
>   vqabs_extra): Fix PRIx format for int16_t, int32_t, uint16_t,
>   uint32_t.
>   * gcc.target/aarch64/advsimd-intrinsics/vqdmull.c: Fix PRIx format
>   for int32_t, int64_t.
>   * gcc.target/aarch64/advsimd-intrinsics/vqneg.c (void
>   vqneg_extra): Fix PRIx format for int16_t, int32_t.
>   * gcc.target/aarch64/advsimd-intrinsics/vreinterpret_p64.c
>   (TEST_VREINTERPRET_TO_POLY): New. (main): Call
>   TEST_VREINTERPRET_TO_POLY instead of TEST_VREINTERPRET where
>   needed.
> 
> 
> 
> 
> neon-warnings.patch.txt
> 
> 
> diff --git 
> a/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/arm-neon-ref.h 
> b/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/arm-neon-ref.h
> index 4728639..fde6029 100644
> --- a/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/arm-neon-ref.h
> +++ b/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/arm-neon-ref.h
> @@ -128,6 +128,35 @@ extern size_t strlen(const char *);
>  fprintf(stderr, "CHECKED %s %s\n", STR(VECT_

Re: [PATCH, v2] (9e) Update "startwith" logic for pass-skipping to handle __RTL functions

[David Malcolm]

On Fri, 2017-01-20 at 09:06 +0100, Richard Biener wrote:
> On Thu, Jan 19, 2017 at 6:22 PM, David Malcolm 
> wrote:
> > On Mon, 2017-01-16 at 14:42 -0700, Jeff Law wrote:
> > > On 01/09/2017 07:38 PM, David Malcolm wrote:
> > > > gcc/ChangeLog:
> > > > * passes.c: Include "insn-addr.h".
> > > > (should_skip_pass_p): Add logging.  Update logic for
> > > > running
> > > > "expand" to be compatible with both __GIMPLE and __RTL. 
> > > >  Guard
> > > > property-provider override so it is only done for gimple
> > > > passes.
> > > > Don't skip dfinit.
> > > > (skip_pass): New function.
> > > > (execute_one_pass): Call skip_pass when skipping passes.
> > > > ---
> > > >  gcc/passes.c | 65
> > > > +---
> > > >  1 file changed, 58 insertions(+), 7 deletions(-)
> > > > 
> > > > diff --git a/gcc/passes.c b/gcc/passes.c
> > > > index 31262ed..6954d1e 100644
> > > > --- a/gcc/passes.c
> > > > +++ b/gcc/passes.c
> > > > @@ -59,6 +59,7 @@ along with GCC; see the file COPYING3.  If
> > > > not
> > > > see
> > > >  #include "cfgrtl.h"
> > > >  #include "tree-ssa-live.h"  /* For remove_unused_locals.  */
> > > >  #include "tree-cfgcleanup.h"
> > > > +#include "insn-addr.h" /* for INSN_ADDRESSES_ALLOC.  */
> > > insn-addr?  Yuk.
> > > 
> > > 
> > > > 
> > > >  using namespace gcc;
> > > > 
> > > > @@ -2315,26 +2316,73 @@ should_skip_pass_p (opt_pass *pass)
> > > >if (!cfun->pass_startwith)
> > > >  return false;
> > > > 
> > > > -  /* We can't skip the lowering phase yet -- ideally we'd
> > > > - drive that phase fully via properties.  */
> > > > -  if (!(cfun->curr_properties & PROP_ssa))
> > > > -return false;
> > > > + /* For __GIMPLE functions, we have to at least start when we
> > > > leave
> > > > + SSA.  */
> > > > +  if (pass->properties_destroyed & PROP_ssa)
> > > > +{
> > > > +  if (!quiet_flag)
> > > > +   fprintf (stderr, "starting anyway when leaving SSA: %s\n",
> > > > pass->name);
> > > > +  cfun->pass_startwith = NULL;
> > > > +  return false;
> > > > +}
> > > This seems to need a comment -- it's not obvious how destroying
> > > the
> > > SSA
> > > property maps to a pass that can not be skipped.
> > 
> > Added:
> > 
> >   /* For __GIMPLE functions, we have to at least start when we
> > leave
> >  SSA.  Hence, we need to detect the "expand" pass, and stop
> > skipping
> >  when we encounter it.  A cheap way to identify "expand" is it
> > to
> >  detect the destruction of PROP_ssa.
> >  For __RTL functions, we invoke "rest_of_compilation" directly,
> > which
> >  is after "expand", and hence we don't reach this conditional. 
> >  */
> > 
> > > > -  /* And also run any property provider.  */
> > > > -  if (pass->properties_provided != 0)
> > > > +  /* Run any property provider.  */
> > > > +  if (pass->type == GIMPLE_PASS
> > > > +  && pass->properties_provided != 0)
> > > >  return false;
> > > So comment needed here too.  I read this as "if a gimple pass
> > > provides a
> > > property then it should not be skipped.  Which means that an RTL
> > > pass
> > > that provides a property can?
> > 
> > Added:
> > 
> >   /* For GIMPLE passes, run any property provider (but continue
> > skipping
> >  afterwards).
> >  We don't want to force running RTL passes that are property
> > providers:
> >  "expand" is covered above, and the only pass other than
> > "expand" that
> >  provides a property is "into_cfglayout" (PROP_cfglayout),
> > which does
> >  too much for a dumped __RTL function.  */
> > 
> > ...the problem being that into_cfglayout's execute vfunc calls
> > cfg_layout_initialize, which does a lot more that just
> > cfg_layout_rtl_register_cfg_hooks (the skip hack does just the
> > latter).
> > 
> > > > +  /* Don't skip df init; later RTL passes need it.  */
> > > > +  if (strstr (pass->name, "dfinit") != NULL)
> > > > +return false;
> > > Which seems like a failing in RTL passes saying they need DF
> > > init.
> > 
> > There isn't a "PROP_df"; should there be?
> > Or is this hack accepable?
> > 
> > > > +/* Skip the given pass, for handling passes before "startwith"
> > > > +   in __GIMPLE and__RTL-marked functions.
> > > > +   In theory, this ought to be a no-op, but some of the RTL
> > > > passes
> > > > +   need additional processing here.  */
> > > > +
> > > > +static void
> > > > +skip_pass (opt_pass *pass)
> > > ...
> > > This all feels like a failing in how we handle state in the RTL
> > > world.
> > > And I suspect it's prone to error.  Imagine if I'm hacking on
> > > something
> > > in the RTL world and my code depends on something else being set
> > > up.
> > >   I
> > > really ought to have a way within my pass to indicate what I
> > > depend
> > > on.
> > > Having it hidden away in passes.c makes it easy to miss/forget.
> > 
> > Indeed, it's a hack.  I preferred the vfunc idea, but Richi prefers
> > to keep it all in one pl

Re: Implement -Wduplicated-branches (PR c/64279) (v3)

[Marek Polacek]

On Fri, Jan 20, 2017 at 10:05:22AM -0500, David Edelsohn wrote:
> This patch introduced a new testsuite failure:
> 
> FAIL: g++.dg/warn/Wduplicated-branches1.C  -std=gnu++98 (test for excess 
> errors)
> Excess errors:
> /nasfarm/edelsohn/src/src/gcc/testsuite/g++.dg/warn/Wduplicated-branches1.C:9:3:
>  warning: this condition has identical branches [-Wduplicated-branches]
> /nasfarm/edelsohn/src/src/gcc/testsuite/g++.dg/warn/Wduplicated-branches1.C:9:3:
>  warning: this condition has identical branches [-Wduplicated-branches]

Sorry about that.  I'll investigate.

Marek

[v3 PATCH] Make poisoned hashes SFINAE away the call operator of the hash.

[Ville Voutilainen]

Tested on Linux-x64. The approach is a bit ugly, the hashes derive
from __poison_hash and also use its nested __enable_hash_call as
an argument for another utility base. I prototyped various approaches
to try to decrease that duplication, but didn't like any of them (more
utility bases, aliases, even passing a lambda that does the concrete
hash to a more generic hash in a base), and they certainly didn't make
the code any shorter.

The reason this patch was done is that K-ballo pointed out that
our hashes have a non-SFINAED call operator that uses a constructing-expression
in its noexcept-spec - so asking is_callable from a poisoned hash leads
to a hard error, including in cases where the user would correctly
check both callability and constructibility, but in that order. I steered
away from turning the call operators into constrained templates, and
chose a conditional base approach instead, because that keeps functions
as functions instead of turning them into templates; we do not want
to open the possibility that a caller starts providing template arguments
explicitly.

This patch covers unique_ptr, std::optional and std::variant. We might
want to entertain doing this for std::experimental::optional as well.

2017-01-20  Ville Voutilainen  

Make poisoned hashes SFINAE away the call operator
of the hash.
* include/bits/functional_hash.h
(__poison_hash::__enable_hash_call): New.
* include/bits/unique_ptr.h (__unique_ptr_hash_call_base): New.
(hash>): Derive from the new base,
move the hash function into that base, use the added enabling
flag to SFINAE.
* include/std/optional (__optional_hash_call_base): New.
(hash>): Derive from the new base,
move the hash function into that base, use the added enabling
flag to SFINAE.
* include/std/variant(__variant_hash_call_base): New.
(hash>): Derive from the new base,
move the hash function into that base, use the added enabling
flag to SFINAE.
* testsuite/20_util/optional/hash.cc: Add tests for is_callable.
* testsuite/20_util/unique_ptr/hash/1.cc: Likewise.
* testsuite/20_util/variant/hash.cc: Likewise.
diff --git a/libstdc++-v3/include/bits/functional_hash.h 
b/libstdc++-v3/include/bits/functional_hash.h
index 14f7fae..38be172 100644
--- a/libstdc++-v3/include/bits/functional_hash.h
+++ b/libstdc++-v3/include/bits/functional_hash.h
@@ -60,6 +60,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   template
 struct __poison_hash
 {
+  static constexpr bool __enable_hash_call = false;
 private:
   // Private rather than deleted to be non-trivially-copyable.
   __poison_hash(__poison_hash&&);
@@ -69,6 +70,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   template
 struct __poison_hash<_Tp, __void_t()(declval<_Tp>()))>>
 {
+  static constexpr bool __enable_hash_call = true;
 };
 
   // Helper struct for SFINAE-poisoning non-enum types.
diff --git a/libstdc++-v3/include/bits/unique_ptr.h 
b/libstdc++-v3/include/bits/unique_ptr.h
index a31cd67..f4763a0 100644
--- a/libstdc++-v3/include/bits/unique_ptr.h
+++ b/libstdc++-v3/include/bits/unique_ptr.h
@@ -789,10 +789,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 { return !(nullptr < __x); }
 
   /// std::hash specialization for unique_ptr.
-  template
-struct hash>
-: public __hash_base>,
-private __poison_hash::pointer>
+
+  template
+struct __unique_ptr_hash_call_base
 {
   size_t
   operator()(const unique_ptr<_Tp, _Dp>& __u) const noexcept
@@ -802,6 +801,19 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   }
 };
 
+  template
+struct __unique_ptr_hash_call_base<_Tp, _Dp, false> {};
+
+  template
+struct hash>
+: public __hash_base>,
+private __poison_hash::pointer>,
+public __unique_ptr_hash_call_base<_Tp, _Dp,
+  __poison_hash::pointer>::
+__enable_hash_call>
+{
+};
+
 #if __cplusplus > 201103L
 
 #define __cpp_lib_make_unique 201304
diff --git a/libstdc++-v3/include/std/optional 
b/libstdc++-v3/include/std/optional
index 85ec91d..85c95b1 100644
--- a/libstdc++-v3/include/std/optional
+++ b/libstdc++-v3/include/std/optional
@@ -951,21 +951,32 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 { return optional<_Tp> { in_place, __il, std::forward<_Args>(__args)... }; 
}
 
   // Hash.
+
+  template
+struct __optional_hash_call_base
+  {
+size_t
+operator()(const optional<_Tp>& __t) const
+  noexcept(noexcept(hash<_Tp> {}(*__t)))
+{
+  // We pick an arbitrary hash for disengaged optionals which hopefully
+  // usual values of _Tp won't typically hash to.
+  constexpr size_t __magic_disengaged_hash = static_cast(-);
+  return __t ? hash<_Tp> {}(*__t) : __magic_disengaged_hash;
+}
+  };
+
   template
-struct hash> : private __poison_hash>
+struct __optional_hash_call_base<_Tp, false> {};
+
+  template
+struct hash> : private __poison_hash>,
+   public __optional_hash_call_base<_Tp,
+   

contrib/update-copyright.py: remove Java

[Gerald Pfeifer]

This is a follow-up to

  2017-01-01  Jakub Jelinek  

* update-copyright.py (TestsuiteFilter): Skip params/README.
(GCCCmdLine): Remove libjava and libjava/testsuite add_dir.

which removed the usage of LibJavaFilter in this script, just not the
filter class itself.

Applied.

Gerald

2017-01-20  Gerald Pfeifer  
 
* update-copyright.py (LibJavaFilter): Remove.
 
Index: update-copyright.py
===
--- update-copyright.py (revision 244714)
+++ update-copyright.py (working copy)
@@ -611,29 +611,6 @@
 'soft-fp',
 ])
 
-class LibJavaFilter (GenericFilter):
-def __init__ (self):
-GenericFilter.__init__ (self)
-
-self.skip_dirs |= set ([
-# Handled separately.
-'testsuite',
-
-# Not really part of the library
-'contrib',
-
-# Imported from upstream
-'classpath',
-'libltdl',
-])
-
-def get_line_filter (self, dir, filename):
-if filename == 'NameDecoder.h':
-return re.compile ('.*NAME_COPYRIGHT')
-if filename == 'ICC_Profile.h':
-return re.compile ('.*icSigCopyrightTag')
-return GenericFilter.get_line_filter (self, dir, filename)
-
 class LibStdCxxFilter (GenericFilter):
 def __init__ (self):
 GenericFilter.__init__ (self)

Re: Implement -Wduplicated-branches (PR c/64279) (v3)

[David Edelsohn]

This patch introduced a new testsuite failure:

FAIL: g++.dg/warn/Wduplicated-branches1.C  -std=gnu++98 (test for excess errors)
Excess errors:
/nasfarm/edelsohn/src/src/gcc/testsuite/g++.dg/warn/Wduplicated-branches1.C:9:3:
 warning: this condition has identical branches [-Wduplicated-branches]
/nasfarm/edelsohn/src/src/gcc/testsuite/g++.dg/warn/Wduplicated-branches1.C:9:3:
 warning: this condition has identical branches [-Wduplicated-branches]

Thanks, David

Re: [PATCH, v2] (9e) Update "startwith" logic for pass-skipping to handle __RTL functions

[Richard Biener]

On January 20, 2017 3:56:31 PM GMT+01:00, David Malcolm  
wrote:
>On Fri, 2017-01-20 at 09:06 +0100, Richard Biener wrote:
>> On Thu, Jan 19, 2017 at 6:22 PM, David Malcolm 
>> wrote:
>> > On Mon, 2017-01-16 at 14:42 -0700, Jeff Law wrote:
>> > > On 01/09/2017 07:38 PM, David Malcolm wrote:
>> > > > gcc/ChangeLog:
>> > > > * passes.c: Include "insn-addr.h".
>> > > > (should_skip_pass_p): Add logging.  Update logic for
>> > > > running
>> > > > "expand" to be compatible with both __GIMPLE and __RTL. 
>> > > >  Guard
>> > > > property-provider override so it is only done for gimple
>> > > > passes.
>> > > > Don't skip dfinit.
>> > > > (skip_pass): New function.
>> > > > (execute_one_pass): Call skip_pass when skipping passes.
>> > > > ---
>> > > >  gcc/passes.c | 65
>> > > > +---
>> > > >  1 file changed, 58 insertions(+), 7 deletions(-)
>> > > > 
>> > > > diff --git a/gcc/passes.c b/gcc/passes.c
>> > > > index 31262ed..6954d1e 100644
>> > > > --- a/gcc/passes.c
>> > > > +++ b/gcc/passes.c
>> > > > @@ -59,6 +59,7 @@ along with GCC; see the file COPYING3.  If
>> > > > not
>> > > > see
>> > > >  #include "cfgrtl.h"
>> > > >  #include "tree-ssa-live.h"  /* For remove_unused_locals.  */
>> > > >  #include "tree-cfgcleanup.h"
>> > > > +#include "insn-addr.h" /* for INSN_ADDRESSES_ALLOC.  */
>> > > insn-addr?  Yuk.
>> > > 
>> > > 
>> > > > 
>> > > >  using namespace gcc;
>> > > > 
>> > > > @@ -2315,26 +2316,73 @@ should_skip_pass_p (opt_pass *pass)
>> > > >if (!cfun->pass_startwith)
>> > > >  return false;
>> > > > 
>> > > > -  /* We can't skip the lowering phase yet -- ideally we'd
>> > > > - drive that phase fully via properties.  */
>> > > > -  if (!(cfun->curr_properties & PROP_ssa))
>> > > > -return false;
>> > > > + /* For __GIMPLE functions, we have to at least start when we
>> > > > leave
>> > > > + SSA.  */
>> > > > +  if (pass->properties_destroyed & PROP_ssa)
>> > > > +{
>> > > > +  if (!quiet_flag)
>> > > > +   fprintf (stderr, "starting anyway when leaving SSA: %s\n",
>> > > > pass->name);
>> > > > +  cfun->pass_startwith = NULL;
>> > > > +  return false;
>> > > > +}
>> > > This seems to need a comment -- it's not obvious how destroying
>> > > the
>> > > SSA
>> > > property maps to a pass that can not be skipped.
>> > 
>> > Added:
>> > 
>> >   /* For __GIMPLE functions, we have to at least start when we
>> > leave
>> >  SSA.  Hence, we need to detect the "expand" pass, and stop
>> > skipping
>> >  when we encounter it.  A cheap way to identify "expand" is it
>> > to
>> >  detect the destruction of PROP_ssa.
>> >  For __RTL functions, we invoke "rest_of_compilation" directly,
>> > which
>> >  is after "expand", and hence we don't reach this conditional. 
>> >  */
>> > 
>> > > > -  /* And also run any property provider.  */
>> > > > -  if (pass->properties_provided != 0)
>> > > > +  /* Run any property provider.  */
>> > > > +  if (pass->type == GIMPLE_PASS
>> > > > +  && pass->properties_provided != 0)
>> > > >  return false;
>> > > So comment needed here too.  I read this as "if a gimple pass
>> > > provides a
>> > > property then it should not be skipped.  Which means that an RTL
>> > > pass
>> > > that provides a property can?
>> > 
>> > Added:
>> > 
>> >   /* For GIMPLE passes, run any property provider (but continue
>> > skipping
>> >  afterwards).
>> >  We don't want to force running RTL passes that are property
>> > providers:
>> >  "expand" is covered above, and the only pass other than
>> > "expand" that
>> >  provides a property is "into_cfglayout" (PROP_cfglayout),
>> > which does
>> >  too much for a dumped __RTL function.  */
>> > 
>> > ...the problem being that into_cfglayout's execute vfunc calls
>> > cfg_layout_initialize, which does a lot more that just
>> > cfg_layout_rtl_register_cfg_hooks (the skip hack does just the
>> > latter).
>> > 
>> > > > +  /* Don't skip df init; later RTL passes need it.  */
>> > > > +  if (strstr (pass->name, "dfinit") != NULL)
>> > > > +return false;
>> > > Which seems like a failing in RTL passes saying they need DF
>> > > init.
>> > 
>> > There isn't a "PROP_df"; should there be?
>> > Or is this hack accepable?
>> > 
>> > > > +/* Skip the given pass, for handling passes before "startwith"
>> > > > +   in __GIMPLE and__RTL-marked functions.
>> > > > +   In theory, this ought to be a no-op, but some of the RTL
>> > > > passes
>> > > > +   need additional processing here.  */
>> > > > +
>> > > > +static void
>> > > > +skip_pass (opt_pass *pass)
>> > > ...
>> > > This all feels like a failing in how we handle state in the RTL
>> > > world.
>> > > And I suspect it's prone to error.  Imagine if I'm hacking on
>> > > something
>> > > in the RTL world and my code depends on something else being set
>> > > up.
>> > >   I
>> > > really ought to have a way within my pass to indicate what I
>

Re: [PATCH, GCC/testsuite/ARM, ping] Skip optional_mthumb tests if GCC has a default mode

[Richard Earnshaw (lists)]

On 13/01/17 18:17, Thomas Preudhomme wrote:
> Ping ARM maintainers? (target independent part ACKed by Jeff)
> 
> Best regards,
> 
> Thomas
> 
> On 03/01/17 17:19, Thomas Preudhomme wrote:
>> Ping?
>>
>> Best regards,
>>
>> Thomas
>>
>> On 12/12/16 17:52, Thomas Preudhomme wrote:
>>> Hi,
>>>
>>> The logic to make -mthumb optional for Thumb-only devices is only
>>> executed when
>>> no -marm or -mthumb is given on the command-line. This includes
>>> configuring GCC
>>> with --with-mode= because this makes the option to be passed before
>>> any others.
>>> The optional_mthumb-* testcases are skipped when -marm or -mthumb is
>>> passed on
>>> the command line but not when GCC was configured with --with-mode.
>>> Not only are
>>> the tests meaningless in these configurations, they also spuriously
>>> FAIL if
>>> --with-mode=arm was used since the test are built for Thumb-only
>>> devices, as
>>> reported by Christophe Lyon in [1].
>>>
>>> [1] https://gcc.gnu.org/ml/gcc-patches/2016-11/msg02082.html
>>>
>>> This patch adds logic to target-support.exp to check how was GCC
>>> configured and
>>> changes the optional_mthumb testcases to be skipped if there is a
>>> default mode
>>> (--with-mode=). It also fixes a couple of typo on the selectors.
>>>
>>> ChangeLog entry is as follows:
>>>
>>>
>>> *** gcc/testsuite/ChangeLog ***
>>>
>>> 2016-12-09  Thomas Preud'homme  
>>>
>>> * lib/target-supports.exp (check_configured_with): New
>>> procedure.
>>> (check_effective_target_default_mode): new effective target.
>>> * gcc.target/arm/optional_thumb-1.c: Skip if GCC was
>>> configured with a
>>> default mode.  Fix dg-skip-if target selector syntax.
>>> * gcc.target/arm/optional_thumb-2.c: Likewise.
>>> * gcc.target/arm/optional_thumb-3.c: Fix dg-skip-if target
>>> selector
>>> syntax.
>>>
>>>

OK.

R.

>>> Is this ok for stage3?
>>>
>>> Best regards,
>>>
>>> Thomas
> 
> skip_optional_mthumb_test_default_mode.patch
> 
> 
> diff --git a/gcc/testsuite/gcc.target/arm/optional_thumb-1.c 
> b/gcc/testsuite/gcc.target/arm/optional_thumb-1.c
> index 
> 23df62887ba4aaa1d8717a34ecda9a40246f0552..99cb0c3f33b601fff4493feef72765f7590e18f6
>  100644
> --- a/gcc/testsuite/gcc.target/arm/optional_thumb-1.c
> +++ b/gcc/testsuite/gcc.target/arm/optional_thumb-1.c
> @@ -1,5 +1,5 @@
> -/* { dg-do compile } */
> -/* { dg-skip-if "-marm/-mthumb/-march/-mcpu given" { *-*-*} { "-marm" 
> "-mthumb" "-march=*" "-mcpu=*" } } */
> +/* { dg-do compile { target { ! default_mode } } } */
> +/* { dg-skip-if "-marm/-mthumb/-march/-mcpu given" { *-*-* } { "-marm" 
> "-mthumb" "-march=*" "-mcpu=*" } } */
>  /* { dg-options "-march=armv6-m" } */
>  
>  /* Check that -mthumb is not needed when compiling for a Thumb-only target.  
> */
> diff --git a/gcc/testsuite/gcc.target/arm/optional_thumb-2.c 
> b/gcc/testsuite/gcc.target/arm/optional_thumb-2.c
> index 
> 4bd53a45eca97e62dd3b86d5a1a66c5ca21e7aad..280dfb3fec55570b6cfe934303c9bd3d50322b86
>  100644
> --- a/gcc/testsuite/gcc.target/arm/optional_thumb-2.c
> +++ b/gcc/testsuite/gcc.target/arm/optional_thumb-2.c
> @@ -1,5 +1,5 @@
> -/* { dg-do compile } */
> -/* { dg-skip-if "-marm/-mthumb/-march/-mcpu given" { *-*-*} { "-marm" 
> "-mthumb" "-march=*" "-mcpu=*" } } */
> +/* { dg-do compile { target { ! default_mode } } } */
> +/* { dg-skip-if "-marm/-mthumb/-march/-mcpu given" { *-*-* } { "-marm" 
> "-mthumb" "-march=*" "-mcpu=*" } } */
>  /* { dg-options "-mcpu=cortex-m4" } */
>  
>  /* Check that -mthumb is not needed when compiling for a Thumb-only target.  
> */
> diff --git a/gcc/testsuite/gcc.target/arm/optional_thumb-3.c 
> b/gcc/testsuite/gcc.target/arm/optional_thumb-3.c
> index 
> f1fd5c8840b191e600c20a7817c611bb9bb645df..d9150e09e475dfbeb7b0b0c153c913b1ad6f0777
>  100644
> --- a/gcc/testsuite/gcc.target/arm/optional_thumb-3.c
> +++ b/gcc/testsuite/gcc.target/arm/optional_thumb-3.c
> @@ -1,8 +1,8 @@
>  /* { dg-do compile } */
>  /* { dg-require-effective-target arm_cortex_m } */
> -/* { dg-skip-if "-mthumb given" { *-*-*} { "-mthumb" } } */
> +/* { dg-skip-if "-mthumb given" { *-*-* } { "-mthumb" } } */
>  /* { dg-options "-marm" } */
> -/* { dg-error "target CPU does not support ARM mode" "missing error with 
> -marm on Thumb-only targets" { target *-*-*} 0 } */
> +/* { dg-error "target CPU does not support ARM mode" "missing error with 
> -marm on Thumb-only targets" { target *-*-* } 0 } */
>  
>  /* Check that -marm gives an error when compiling for a Thumb-only target.  
> */
>  
> diff --git a/gcc/testsuite/lib/target-supports.exp 
> b/gcc/testsuite/lib/target-supports.exp
> index 
> 0fc0bafa67d8d34ec74ce2d1d7a2323a375615cc..f7511ef3aebca72c798496fb95ce43fcbbc08ed1
>  100644
> --- a/gcc/testsuite/lib/target-supports.exp
> +++ b/gcc/testsuite/lib/target-supports.exp
> @@ -252,6 +252,20 @@ proc check_runtime {prop args} {
>  }]
>  }
>  
> +# Return 1 if GCC was configured with $pattern.
> +proc check_configured_with { pattern } {
> +g

Re: [v3 PATCH] Make poisoned hashes SFINAE away the call operator of the hash.

[Jonathan Wakely]

On 20/01/17 17:00 +0200, Ville Voutilainen wrote:

--- a/libstdc++-v3/include/bits/unique_ptr.h
+++ b/libstdc++-v3/include/bits/unique_ptr.h
@@ -789,10 +789,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
{ return !(nullptr < __x); }

  /// std::hash specialization for unique_ptr.
-  template
-struct hash>
-: public __hash_base>,
-private __poison_hash::pointer>
+
+  template
+struct __unique_ptr_hash_call_base


Could this deduce the bool automatically? i.e.

 template::pointer>::__enable_hash_call>
   struct __unique_ptr_hash_call_base


{
  size_t
  operator()(const unique_ptr<_Tp, _Dp>& __u) const noexcept
@@ -802,6 +801,19 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
  }
};

+  template
+struct __unique_ptr_hash_call_base<_Tp, _Dp, false> {};
+
+  template
+struct hash>
+: public __hash_base>,
+private __poison_hash::pointer>,
+public __unique_ptr_hash_call_base<_Tp, _Dp,
+  __poison_hash::pointer>::
+__enable_hash_call>


If the bool is deduced then this would be slightly less complicated:

 template
   struct hash>
   : public __hash_base>,
 private __poison_hash::pointer>,
 public __unique_ptr_hash_call_base<_Tp, _Dp>
   { };

(But when this much effort is needed to define std::hash something
tells me we've taken a wrong turn in the standard.)

This part for std::unique_ptr is the only part that isn't C++17-only,
so this is the part I'm most nervous about. Given that we're in stage
4 and this isn't even fixing something in Bugzilla (even if it is a
real bug), would it be possible to only fix optional and variant for
now? We could revisit the unique_ptr part once we know this approach
doesn't have some other problem that we haven't guessed yet.

Or if this is fixing some regression introduced by the __poison_hash
stuff please put something in BZ for the record.



diff --git a/libstdc++-v3/include/std/optional 
b/libstdc++-v3/include/std/optional
index 85ec91d..85c95b1 100644
--- a/libstdc++-v3/include/std/optional
+++ b/libstdc++-v3/include/std/optional
@@ -951,21 +951,32 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
{ return optional<_Tp> { in_place, __il, std::forward<_Args>(__args)... }; }

  // Hash.
+
+  template


Could we deduce the bool here too?


+struct __optional_hash_call_base
+  {


This brace (and the rest of the body) should be indented to line up
with "struct"


+size_t
+operator()(const optional<_Tp>& __t) const
+  noexcept(noexcept(hash<_Tp> {}(*__t)))
+{
+  // We pick an arbitrary hash for disengaged optionals which hopefully
+  // usual values of _Tp won't typically hash to.
+  constexpr size_t __magic_disengaged_hash = static_cast(-);
+  return __t ? hash<_Tp> {}(*__t) : __magic_disengaged_hash;
+}
+  };
+
  template
-struct hash> : private __poison_hash>
+struct __optional_hash_call_base<_Tp, false> {};
+
+  template
+struct hash> : private __poison_hash>,
+   public __optional_hash_call_base<_Tp,
+ __poison_hash>::
+   __enable_hash_call>


The base classes don't need to be indented so much. Maybe like this
instead:

   struct hash>
   : private __poison_hash>,
 public __optional_hash_call_base<_Tp,
  __poison_hash>::__enable_hash_call>

Or if the bool parameter can be deduced it's simpler:

   struct hash>
   : private __poison_hash>,
 public __optional_hash_call_base<_Tp>

[libgcc] i386/cygming-crtbegin.c: remove LIBGCJ_SONAME

[Gerald Pfeifer]

Not a regression in the strict sense, but a left over from the Java
removal.  Can we still get that in?

(I think I pretty much committed all other changes of things I found
as left overs from the GCJ/libgcj removal.)

Gerald

2017-01-20  Gerald Pfeifer  

* config/i386/cygming-crtbegin.c (LIBGCJ_SONAME): No longer #define.

Index: libgcc/config/i386/cygming-crtbegin.c
===
--- libgcc/config/i386/cygming-crtbegin.c   (revision 244714)
+++ libgcc/config/i386/cygming-crtbegin.c   (working copy)
@@ -42,10 +42,6 @@
 #define LIBGCC_SONAME "libgcc_s.dll"
 #endif
 
-#ifndef LIBGCJ_SONAME
-#define LIBGCJ_SONAME "libgcj_s.dll"
-#endif
-
 #if DWARF2_UNWIND_INFO
 /* Make the declarations weak.  This is critical for
_Jv_RegisterClasses because it lives in libgcj.a  */

Re: [v3 PATCH] Make poisoned hashes SFINAE away the call operator of the hash.

[Ville Voutilainen]

On 20 January 2017 at 17:21, Jonathan Wakely  wrote:
> This part for std::unique_ptr is the only part that isn't C++17-only,
> so this is the part I'm most nervous about. Given that we're in stage
> 4 and this isn't even fixing something in Bugzilla (even if it is a
> real bug), would it be possible to only fix optional and variant for
> now? We could revisit the unique_ptr part once we know this approach
> doesn't have some other problem that we haven't guessed yet.

Sure. I would guesstimate that custom pointer types that aren't
hashable should be rare,
so hitting that problem is unlikely.

I'll remove the unique_ptr bits, will give the deduced-bool a spin and
fix the whitespace, and will then
send a new patch for review.

[PATCH] PR69240 Define inequality operators for param types

[Jonathan Wakely]

We're in stage 4 now, and this isn't a regression, but I'm going to be
naughty and commit it anyway because it's a large patch but very
simple. It just adds operator!= to every xxx_distribution::param_type,
doing return (!p1 == p2), so hard to get wrong. The rest of the patch
only changes whitespace and adds tests.

Tested powerpc64le-linux, committed to trunk.

commit 6d37d8d3aa1bfa16954fd914242fcc6bc7ea1a5c
Author: Jonathan Wakely 
Date:   Fri Jan 20 14:23:06 2017 +

PR69240 Define inequality operators for  param types

	PR libstdc++/69240
	* include/bits/random.h (uniform_real_distribution::param_type)
	(normal_distribution::param_type, lognormal_distribution::param_type)
	(gamma_distribution::param_type, chi_squared_distribution::param_type)
	(cauchy_distribution::param_type, fisher_f_distribution::param_type)
	(student_t_distribution::param_type)
	(bernoulli_distribution::param_type, binomial_distribution::param_type)
	(geometric_distribution::param_type)
	(negative_binomial_distribution::param_type)
	(poisson_distribution::param_type)
	(exponential_distribution::param_type)
	(weibull_distribution::param_type)
	(extreme_value_distribution::param_type)
	(discrete_distribution::param_type)
	(piecewise_constant_distribution::param_type)
	(piecewise_linear_distribution::param_type): Define operator!=.
	* include/bits/uniform_int_dist.h
	(uniform_int_distribution::param_type): Likewise.
	* include/ext/random (beta_distribution::param_type)
	(rice_distribution::param_type, nakagami_distribution::param_type)
	(pareto_distribution::param_type, k_distribution::param_type)
	(arcsine_distribution::param_type, hoyt_distribution::param_type)
	(triangular_distribution::param_type)
	(von_mises_distribution::param_type)
	(hypergeometric_distribution::param_type)
	(logistic_distribution::param_type)
	(uniform_on_sphere_distribution::param_type)
	(uniform_inside_sphere_distribution::param_type): Likewise.
	* testsuite/26_numerics/random/bernoulli_distribution/cons/parms.cc:
	Test construction with param_type.
	* testsuite/26_numerics/random/binomial_distribution/cons/parms.cc:
	Likewise.
	* testsuite/26_numerics/random/cauchy_distribution/cons/parms.cc:
	Likewise.
	* testsuite/26_numerics/random/chi_squared_distribution/cons/parms.cc:
	Likewise.
	* testsuite/26_numerics/random/exponential_distribution/cons/parms.cc:
	Likewise.
	* testsuite/26_numerics/random/extreme_value_distribution/cons/
	parms.cc: Likewise.
	* testsuite/26_numerics/random/fisher_f_distribution/cons/parms.cc:
	Likewise.
	* testsuite/26_numerics/random/gamma_distribution/cons/parms.cc:
	Likewise.
	* testsuite/26_numerics/random/geometric_distribution/cons/parms.cc:
	Likewise.
	* testsuite/26_numerics/random/lognormal_distribution/cons/parms.cc:
	Likewise.
	* testsuite/26_numerics/random/negative_binomial_distribution/cons/
	parms.cc: Likewise.
	* testsuite/26_numerics/random/normal_distribution/cons/parms.cc:
	Likewise.
	* testsuite/26_numerics/random/poisson_distribution/cons/parms.cc:
	Likewise.
	* testsuite/26_numerics/random/student_t_distribution/cons/parms.cc:
	Likewise.
	* testsuite/26_numerics/random/uniform_int_distribution/cons/parms.cc:
	Likewise.
	* testsuite/26_numerics/random/uniform_real_distribution/cons/parms.cc:
	Likewise.
	* testsuite/26_numerics/random/weibull_distribution/cons/parms.cc:
	Likewise.
	* testsuite/ext/random/arcsine_distribution/cons/parms.cc: Likewise.
	* testsuite/ext/random/beta_distribution/cons/parms.cc: Likewise.
	* testsuite/ext/random/hoyt_distribution/cons/parms.cc: Likewise.
	* testsuite/ext/random/hypergeometric_distribution/cons/parms.cc:
	Likewise.
	* testsuite/ext/random/k_distribution/cons/parms.cc: Likewise.
	* testsuite/ext/random/logistic_distribution/cons/parms.cc: Likewise.
	* testsuite/ext/random/nakagami_distribution/cons/parms.cc: Likewise.
	* testsuite/ext/random/normal_mv_distribution/cons/parms.cc: Likewise.
	* testsuite/ext/random/pareto_distribution/cons/parms.cc: Likewise.
	* testsuite/ext/random/rice_distribution/cons/parms.cc: Likewise.
	* testsuite/ext/random/triangular_distribution/cons/parms.cc:
	Likewise.
	* testsuite/ext/random/uniform_inside_sphere_distribution/cons/
	parms.cc: Likewise.
	* testsuite/ext/random/von_mises_distribution/cons/parms.cc: Likewise.

diff --git a/libstdc++-v3/include/bits/random.h b/libstdc++-v3/include/bits/random.h
index 2586cbc..d39cc3e 100644
--- a/libstdc++-v3/include/bits/random.h
+++ b/libstdc++-v3/include/bits/random.h
@@ -1707,6 +1707,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 public:
   /** The type of the range of the distribution. */
   typedef _RealType result_type;
+
   /** Parameter type. */
   struct para

Re: [v3 PATCH] Make poisoned hashes SFINAE away the call operator of the hash.

[Ville Voutilainen]

On 20 January 2017 at 17:27, Ville Voutilainen
 wrote:
> On 20 January 2017 at 17:21, Jonathan Wakely  wrote:
>> This part for std::unique_ptr is the only part that isn't C++17-only,
>> so this is the part I'm most nervous about. Given that we're in stage
>> 4 and this isn't even fixing something in Bugzilla (even if it is a
>> real bug), would it be possible to only fix optional and variant for
>> now? We could revisit the unique_ptr part once we know this approach
>> doesn't have some other problem that we haven't guessed yet.
>
> Sure. I would guesstimate that custom pointer types that aren't
> hashable should be rare,
> so hitting that problem is unlikely.
>
> I'll remove the unique_ptr bits, will give the deduced-bool a spin and
> fix the whitespace, and will then
> send a new patch for review.

Here:

2017-01-20  Ville Voutilainen  

2017-01-20  Ville Voutilainen  

Make poisoned hashes SFINAE away the call operator
of the hash.
* include/bits/functional_hash.h
(__poison_hash::__enable_hash_call): New.
* include/std/optional (__optional_hash_call_base): New.
(hash>): Derive from the new base,
move the hash function into that base.
* include/std/variant (__variant_hash_call_base_impl): New.
(__variant_hash_call_base): Likewise.
(hash>): Derive from the new base,
move the hash function into that base.
* testsuite/20_util/optional/hash.cc: Add tests for is_callable.
* testsuite/20_util/variant/hash.cc: Likewise.
diff --git a/libstdc++-v3/include/bits/functional_hash.h 
b/libstdc++-v3/include/bits/functional_hash.h
index 14f7fae..38be172 100644
--- a/libstdc++-v3/include/bits/functional_hash.h
+++ b/libstdc++-v3/include/bits/functional_hash.h
@@ -60,6 +60,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   template
 struct __poison_hash
 {
+  static constexpr bool __enable_hash_call = false;
 private:
   // Private rather than deleted to be non-trivially-copyable.
   __poison_hash(__poison_hash&&);
@@ -69,6 +70,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   template
 struct __poison_hash<_Tp, __void_t()(declval<_Tp>()))>>
 {
+  static constexpr bool __enable_hash_call = true;
 };
 
   // Helper struct for SFINAE-poisoning non-enum types.
diff --git a/libstdc++-v3/include/std/optional 
b/libstdc++-v3/include/std/optional
index 85ec91d..887bf9e 100644
--- a/libstdc++-v3/include/std/optional
+++ b/libstdc++-v3/include/std/optional
@@ -951,12 +951,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 { return optional<_Tp> { in_place, __il, std::forward<_Args>(__args)... }; 
}
 
   // Hash.
-  template
-struct hash> : private __poison_hash>
-{
-  using result_type = size_t;
-  using argument_type = optional<_Tp>;
 
+  template>::__enable_hash_call>
+struct __optional_hash_call_base
+{
   size_t
   operator()(const optional<_Tp>& __t) const
   noexcept(noexcept(hash<_Tp> {}(*__t)))
@@ -968,6 +967,18 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   }
 };
 
+  template
+struct __optional_hash_call_base<_Tp, false> {};
+
+  template
+struct hash>
+: private __poison_hash>,
+  public __optional_hash_call_base<_Tp>
+{
+  using result_type = size_t;
+  using argument_type = optional<_Tp>;
+};
+
   /// @}
 
 _GLIBCXX_END_NAMESPACE_VERSION
diff --git a/libstdc++-v3/include/std/variant b/libstdc++-v3/include/std/variant
index 6404fce..c5138e5 100644
--- a/libstdc++-v3/include/std/variant
+++ b/libstdc++-v3/include/std/variant
@@ -1273,14 +1273,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   std::forward<_Variants>(__variants)...);
 }
 
-  template
-struct hash>
-: private __detail::__variant::_Variant_hash_base<
-   variant<_Types...>, std::index_sequence_for<_Types...>>
+  template
+struct __variant_hash_call_base_impl
 {
-  using result_type = size_t;
-  using argument_type = variant<_Types...>;
-
   size_t
   operator()(const variant<_Types...>& __t) const
   noexcept((is_nothrow_callable_v>(_Types)> && ...))
@@ -1297,6 +1292,24 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   }
 };
 
+  template
+struct __variant_hash_call_base_impl {};
+
+  template
+using __variant_hash_call_base =
+__variant_hash_call_base_impl<(__poison_hash>::
+  __enable_hash_call &&...), _Types...>;
+
+  template
+struct hash>
+: private __detail::__variant::_Variant_hash_base<
+variant<_Types...>, std::index_sequence_for<_Types...>>,
+  public __variant_hash_call_base<_Types...>
+{
+  using result_type = size_t;
+  using argument_type = variant<_Types...>;
+};
+
   template<>
 struct hash
 {
diff --git a/libstdc++-v3/testsuite/20_util/optional/hash.cc 
b/libstdc++-v3/testsuite/20_util/optional/hash.cc
index ceb862b..297ea2e 100644
--- a/libstdc++-v3/testsuite/20_util/optional/hash.cc
+++ b/libstdc++-v3/testsuite/20_util/optional/hash.cc
@@ -29,6 +29,12 @@ template
 a

Re: [C++ PATCH] c++/78495 inherited ctor and inivis-ref parm

[Nathan Sidwell]

On 01/20/2017 08:45 AM, Jason Merrill wrote:


Hmm, I would guess that if we're going to do this we need to also use
forward_parm in maybe_thunk_body.


Apparently not needed.  maybe_thunk_body is called after we've 
genericized the parent ctor.  That ctor's parms have been bashed to 
reference and have DECL_BY_REFERENCE set appropriately.  The clone's 
parms have also been bashed, but do not have DECL_BY_REFERENCE set.


For POD struct (which remain as struct T) the backend machinery already 
DTRT.


nathan

--
Nathan Sidwell

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

[Richard Earnshaw (lists)]

On 19/01/17 06:38, Andreas Tobler wrote:
> On 19.01.17 00:33, Jeff Law wrote:
>> On 01/18/2017 11:43 AM, Andreas Tobler wrote:
>>> Hi all,
>>>
>>> I have the following issue here on aarch64-*-freebsd:
>>>
>>> (sorry if the format is hardly readable)
>>>
>>> ..
>>> /export/devel/net/src/gcc/head/gcc/gcc/config/aarch64/aarch64.c: In
>>> function 'void aarch64_elf_asm_destructor(rtx, int)':
>>> /export/devel/net/src/gcc/head/gcc/gcc/config/aarch64/aarch64.c:5760:1:
>>> error: %.5u' directive output may be truncated writing between 5 and 10
>>> bytes into a region of size 6 [-Werror=format-truncation=]
>>>  aarch64_elf_asm_destructor (rtx symbol, int priority)
>>>  ^~
>>> /export/devel/net/src/gcc/head/gcc/gcc/config/aarch64/aarch64.c:5760:1:
>>> note: using the range [1, 4294967295] for directive argument
>>> /export/devel/net/src/gcc/head/gcc/gcc/config/aarch64/aarch64.c:5768:65:
>>> note: format output between 18 and 23 bytes into a destination of
>>> size 18
>>>snprintf (buf, sizeof (buf), ".fini_array.%.5u", priority);
>>>
>>> ^
>>> ...
>>>
>>> This is the code snippet, it does not only occur in aarch64, but also at
>>> least in pa and avr.
>>>
>>> 
>>> static void
>>> aarch64_elf_asm_destructor (rtx symbol, unsigned short priority)
>>> {
>>>   if (priority == DEFAULT_INIT_PRIORITY)
>>> default_dtor_section_asm_out_destructor (symbol, priority);
>>>   else
>>> {
>>>   section *s;
>>>   char buf[18];
>>>   snprintf (buf, sizeof (buf), ".fini_array.%.5u", priority);
>>>   s = get_section (buf, SECTION_WRITE, NULL);
>>>   switch_to_section (s);
>>>   assemble_align (POINTER_SIZE);
>>>   assemble_aligned_integer (POINTER_BYTES, symbol);
>>> }
>>> }
>>> 
>>>
>>> I have now four options to solve this, (a fifth one would be to remove
>>> format-truncation from -Wall/Wextra?)
>>>
>>> 1.) increase buf to 23
>>> 2.) use %.5hu in snprintf
>>> 3.) cast priority in snprintf to (unsigned int)
>>> 4.) make priority unsigned short.
>>>
>>> Solution 1, 2 and 3 work, but with pros and cons.
>> #3 likely won't work with with lower optimization levels since it
>> depends on VRP to narrow the object's range.
>>
>> I'd approve #2 or #1 without hesitation.
> 
> Ok.
> 
> I did a mistake while describing the situation. The function has this
> parameter:
> 
> aarch64_elf_asm_destructor (rtx symbol, int priority)
> 
> I copied the already modified piece of code
> 

Ah, that makes much more sense.

> So the cast in #3 would be (unsigned short) iso (unsigned int).
> 
> If no other opinions come up I'll go with #2.
> 
> Thanks.
> Andreas
> 
> 

I agree, some sort of cast seems preferable.  The documentation for
constructor priorities says that the lowest priority is 65535, so
alternatives here are:

- assert (priority < 65536) then cast to unsigned short.
- simply cast to unsigned short
- saturate to 16 bits unsigned then cast to short.

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

R.

[PATCH] Fix bogus warning with -Wimplicit-fallthrough (PR c/79152)

[Marek Polacek]

We already have code to handle

  case 0:
foo ();
  label:
bar ();

where we don't want to warn, but the code didn't handle consecutive non-case
labels.  Thus fixed.

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

2017-01-20  Marek Polacek  

PR c/79152
* gimplify.c (should_warn_for_implicit_fallthrough): Handle consecutive
non-case labels.

* c-c++-common/Wimplicit-fallthrough-35.c: New test.

diff --git gcc/gimplify.c gcc/gimplify.c
index 2777a23..d382eea 100644
--- gcc/gimplify.c
+++ gcc/gimplify.c
@@ -1985,7 +1985,7 @@ should_warn_for_implicit_fallthrough 
(gimple_stmt_iterator *gsi_p, tree label)
   if (FALLTHROUGH_LABEL_P (label))
 return false;
 
-  /* Don't warn for a non-case label followed by a statement:
+  /* Don't warn for non-case labels followed by a statement:
case 0:
 foo ();
label:
@@ -1993,7 +1993,12 @@ should_warn_for_implicit_fallthrough 
(gimple_stmt_iterator *gsi_p, tree label)
  as these are likely intentional.  */
   if (!case_label_p (&gimplify_ctxp->case_labels, label))
 {
-  gsi_next (&gsi);
+  tree l;
+  while (!gsi_end_p (gsi)
+&& gimple_code (gsi_stmt (gsi)) == GIMPLE_LABEL
+&& (l = gimple_label_label (as_a  (gsi_stmt (gsi
+&& !case_label_p (&gimplify_ctxp->case_labels, l))
+   gsi_next (&gsi);
   if (gsi_end_p (gsi) || gimple_code (gsi_stmt (gsi)) != GIMPLE_LABEL)
return false;
 }
diff --git gcc/testsuite/c-c++-common/Wimplicit-fallthrough-35.c 
gcc/testsuite/c-c++-common/Wimplicit-fallthrough-35.c
index e69de29..9a0aba6 100644
--- gcc/testsuite/c-c++-common/Wimplicit-fallthrough-35.c
+++ gcc/testsuite/c-c++-common/Wimplicit-fallthrough-35.c
@@ -0,0 +1,61 @@
+/* PR c/79152 */
+/* { dg-do compile } */
+/* { dg-options "-Wimplicit-fallthrough" } */
+
+extern void foo (int);
+
+void
+f (int i)
+{
+  switch (i)
+{
+case 0:
+  foo (0);
+l1:
+  foo (1);
+}
+
+  switch (i)
+{
+case 0:
+  foo (0);
+l2:;
+}
+
+  switch (i)
+{
+case 0:
+  foo (0);
+l3:
+l4:
+  foo (1);
+}
+
+  switch (i)
+{
+case 0:
+  foo (0);
+l5:
+l6:;
+}
+
+  switch (i)
+{
+case 0:
+  foo (0); /* { dg-warning "statement may fall through" } */
+l7:
+l8:
+case 1:
+  foo (1);
+}
+
+  switch (i)
+{
+case 0:
+  foo (0); /* { dg-warning "statement may fall through" } */
+l9:
+case 1:
+l10:
+  foo (1);
+}
+}

Marek

Re: [1/5][AArch64] Return address protection on AArch64

[Richard Earnshaw (lists)]

On 20/01/17 12:36, Jiong Wang wrote:
> 
> 
> On 20/01/17 11:15, Jiong Wang wrote:
>>
>>
>> On 20/01/17 03:39, Andrew Pinski wrote:
>>> On Fri, Jan 6, 2017 at 3:47 AM, Jiong Wang 
>>> wrote:
 On 11/11/16 18:22, Jiong Wang wrote:
> As described in the cover letter, this patch implements return address
> signing
> for AArch64, it's controlled by the new option:
>
> -msign-return-address=[none | non-leaf | all]
>
> "none" means don't do return address signing at all on any function.
> "non-leaf"
> means only sign non-leaf function.  "all" means sign all functions.
> Return
> address signing is currently disabled on ILP32.  I haven't tested it.
>
> The instructions added in the architecture are of 2 kinds.
>
> * In the NOP instruction space, which allows binaries to run
> without any
> traps
> on older versions of the architecture. This doesn't give any
> additional
> protection on older hardware but allows for the same binary to be
> used on
> earlier versions of the architecture and newer versions of the
> architecture.
>
> * New instructions that are only valid for v8.3 and will trap if
> used on
> earlier
> versions of the architecture.
>
> At default, once return address signing is enabled, it will only
> generates
> NOP
> instruction.
>
> While if -march=armv8.3-a specified, GCC will try to use the most
> efficient
> pointer authentication instruction as it can.
>
> The architecture has 2 user invisible system keys for signing and
> creating
> signed addresses as part of these instructions. For some use case, the
> user
> might want to use difference key for different functions. The new
> option
> "-msign-return-address-key=key_name" let GCC select the key used for
> return
> address signing.  Permissible values are "a_key" for A key and
> "b_key" for
> B
> key, and this option are supported by function target attribute and
> LTO
> will
> hopefully just work.
>
>
>
> gcc/
> 2016-11-09  Jiong Wang
>
>   * config/aarch64/aarch64-opts.h
> (aarch64_pauth_key_index): New
> enum.
>   (aarch64_function_type): New enum.
>   * config/aarch64/aarch64-protos.h
> (aarch64_output_sign_auth_reg):
> New
>   declaration.
>   * config/aarch64/aarch64.c (aarch64_expand_prologue):
> Sign return
>   address before it's pushed onto stack.
>   (aarch64_expand_epilogue): Authenticate return address
> fetched
> from
>   stack.
>   (aarch64_output_sign_auth_reg): New function.
>   (aarch64_override_options): Sanity check for ILP32 and
> ISA level.
>   (aarch64_attributes): New function attributes for
> "sign-return-address",
>   "pauth-key".
>   * config/aarch64/aarch64.md (UNSPEC_AUTH_REG,
> UNSPEC_AUTH_REG1716,
>   UNSPEC_SIGN_REG, UNSPEC_SIGN_REG1716, UNSPEC_STRIP_REG_SIGN,
>   UNSPEC_STRIP_X30_SIGN): New unspecs.
>   ("*do_return"): Generate combined instructions according
> to key
> index.
>   ("sign_reg", "sign_reg1716", "auth_reg", "auth_reg1716",
>   "strip_reg_sign", "strip_lr_sign"): New.
>   * config/aarch64/aarch64.opt (msign-return-address,
> mpauth-key):
> New.
>   * config/aarch64/predicates.md (aarch64_const0_const1): New
> predicate.
>   * doc/extend.texi (AArch64 Function Attributes): Documents
>   "sign-return-address=", "pauth-key".
>   * doc/invoke.texi (AArch64 Options): Documents
> "-msign-return-address=",
>   "-pauth-key".
>
> gcc/testsuite/
> 2016-11-09  Jiong Wang
>
>   * gcc.target/aarch64/return_address_sign_1.c: New testcase.
>   * gcc.target/aarch64/return_address_sign_scope_1.c: New
> testcase.

 Update the patchset according to new DWARF proposal described at

https://gcc.gnu.org/ml/gcc-patches/2016-11/msg03010.html
>>> One of these patches of this patch set break ILP32 building for
>>> aarch64-elf and most likely also aarch64-linux-gnu.
>>>
>>> /home/jenkins/workspace/BuildToolchainAARCH64_thunder_elf_upstream/toolchain/scripts/../src/libgcc/unwind-dw2.c:
>>>
>>> In function ‘uw_init_context_1’:
>>> /home/jenkins/workspace/BuildToolchainAARCH64_thunder_elf_upstream/toolchain/scripts/../src/libgcc/unwind-dw2.c:1567:6:
>>>
>>> internal compiler error: in emit_move_insn, at expr.c:3698
>>> ra = MD_POST_EXTRACT_ROOT_ADDR (ra);
>>> 0x8270cf emit_move_insn(rtx_def*, rtx_def*)
>>> /home/jenkins/workspace/BuildToolchainAARCH64_thunder_elf_upstream/toolchain/scripts/../src/gcc/expr.c:3697
>>>
>>> 0x80867b force_reg(machine_mode, rtx_def*)
>> Must be 

Re: [PATCH] Fix bogus warning with -Wimplicit-fallthrough (PR c/79152)

[Jakub Jelinek]

On Fri, Jan 20, 2017 at 05:14:34PM +0100, Marek Polacek wrote:
> We already have code to handle
> 
>   case 0:
> foo ();
>   label:
> bar ();
> 
> where we don't want to warn, but the code didn't handle consecutive non-case
> labels.  Thus fixed.
> 
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
> 
> 2017-01-20  Marek Polacek  
> 
>   PR c/79152
>   * gimplify.c (should_warn_for_implicit_fallthrough): Handle consecutive
>   non-case labels.
> 
>   * c-c++-common/Wimplicit-fallthrough-35.c: New test.

Ok, thanks.

Jakub

Re: [PATCH] c++/78771 ICE with inheriting ctor

[Nathan Sidwell]

ping?

On 01/11/2017 10:53 AM, Nathan Sidwell wrote:

On 01/04/2017 12:53 AM, Jason Merrill wrote:


Hmm, that seems like where the problem is.  We shouldn't try to
instantiate the inheriting constructor until we've already chosen the
base constructor; in the new model the inheriting constructor is just an
implementation detail.


Oh what fun.  This testcase behaves differently for C++17, C++11
-fnew-inheriting-ctors and C++11 -fno-new-inheriting-ctors compilation
modes.

Firstly, unpatched G++ is fine in C++17 mode, because:
  /* In C++17, "If the initializer expression is a prvalue and the
 cv-unqualified version of the source type is the same class as the
class
 of the destination, the initializer expression is used to
initialize the
 destination object."  Handle that here to avoid doing overload
 resolution.  */
and inside that we have:

  /* FIXME P0135 doesn't say how to handle direct initialization from a
 type with a suitable conversion operator.  Let's handle it like
 copy-initialization, but allowing explict conversions.  */

That conversion lookup short-circuits the subsequent overload resolution
that would otherwise explode.

Otherwise, with -fnew-inheriting-ctors, you are indeed correct.  There
needs to be a call to strip_inheriting_ctors in deduce_inheriting_ctor.

With -fno-new-inheriting-ctors we need the original patch I posted
(included herein).  I suppose we might be able to remove the assert from
strip_inheriting_ctors and always call that from deduce_inheriting_ctor,
but that seems a bad idea to me.

I was unable to produce a c++17 testcase that triggered this problem by
avoiding the above-mentioned overload resolution short-circuiting.

As -fnew-inheriting-ctors is a mangling-affecting flag, I guess we're
stuck with it for the foreseable future.

ok?

nathan




--
Nathan Sidwell

Re: [PATCH] Fix PR78189

[Nick Clifton]

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 passes  3275
< # of unexpected failures  63
< # of unexpected successes 125
< # of expected failures123
< # of unsupported tests153
---
> # of expected passes  3448
> # of unexpected failures  2
> # of unexpected successes 14
> # of expected failures131
> # of unsupported tests151

  Big Endian ARM:
< # of expected passes  2995
< # of unexpected failures  269
< # of unexpected successes 21
< # of expected failures128
---
> # of expected passes  3037
> # of unexpected failures  127
> # of unexpected successes 24
> # of expected failures228

  Which looks like a win to me.  So - any objections to my applying this
  patch and then closing the PR ?

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.

Index: gcc/testsuite/gcc.dg/vect/vect-strided-a-u8-i2-gap.c
===
--- gcc/testsuite/gcc.dg/vect/vect-strided-a-u8-i2-gap.c	(revision 244691)
+++ gcc/testsuite/gcc.dg/vect/vect-strided-a-u8-i2-gap.c	(working copy)
@@ -71,5 +71,6 @@
   return 0;
 }
 
-/* { dg-final { scan-tree-dump-times "vectorized 2 loops" 1 "vect"  { target vect_strided2 } } } */
+/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect"  { target { vect_strided2 && { ! vect_hw_misalign } } } } } */
+/* { dg-final { scan-tree-dump-times "vectorized 2 loops" 1 "vect"  { target { vect_strided2 && vect_hw_misalign } } } } */
   
Index: gcc/testsuite/lib/target-supports.exp
===
--- gcc/testsuite/lib/target-supports.exp	(revision 244691)
+++ gcc/testsuite/lib/target-supports.exp	(working copy)
@@ -5732,6 +5732,9 @@
 	 || ([istarget mips*-*-*] && [et-is-effective-target mips_msa]) } {
 	  set et_vect_hw_misalign_saved($et_index) 1
 	}
+	if { [istarget arm*-*-*] } {
+	set et_vect_hw_misalign_saved($et_index) [check_effective_target_arm_vect_no_misalign]
+	}
 }
 verbose "check_effective_target_vect_hw_misalign:\
 	 returning $et_vect_hw_misalign_saved($et_index)" 2

Re: [C++ PATCH] c++/78495 inherited ctor and inivis-ref parm

[Jason Merrill]

On Fri, Jan 20, 2017 at 11:12 AM, Nathan Sidwell  wrote:
> On 01/20/2017 08:45 AM, Jason Merrill wrote:
>
>> Hmm, I would guess that if we're going to do this we need to also use
>> forward_parm in maybe_thunk_body.
>
>
> Apparently not needed.  maybe_thunk_body is called after we've genericized
> the parent ctor.  That ctor's parms have been bashed to reference and have
> DECL_BY_REFERENCE set appropriately.  The clone's parms have also been
> bashed, but do not have DECL_BY_REFERENCE set.
>
> For POD struct (which remain as struct T) the backend machinery already
> DTRT.

OK, then.

Jason

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

[Martin Sebor]

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?

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.


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?)


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 

Re: [v3 PATCH] Make poisoned hashes SFINAE away the call operator of the hash.

[Jonathan Wakely]

On 20/01/17 17:50 +0200, Ville Voutilainen wrote:

On 20 January 2017 at 17:27, Ville Voutilainen
 wrote:

On 20 January 2017 at 17:21, Jonathan Wakely  wrote:

This part for std::unique_ptr is the only part that isn't C++17-only,
so this is the part I'm most nervous about. Given that we're in stage
4 and this isn't even fixing something in Bugzilla (even if it is a
real bug), would it be possible to only fix optional and variant for
now? We could revisit the unique_ptr part once we know this approach
doesn't have some other problem that we haven't guessed yet.


Sure. I would guesstimate that custom pointer types that aren't
hashable should be rare,
so hitting that problem is unlikely.

I'll remove the unique_ptr bits, will give the deduced-bool a spin and
fix the whitespace, and will then
send a new patch for review.


Here:


OK for trunk - thanks.

RFA: Update XFAIL comments in

[Nick Clifton]

Hi Guys,

  I would like to close out PR 70681 by applying the patch below.  It
  updates the XFAIL comments in the two affected tests, explaining why
  the check for shrink-wrapping will fail.  There is nothing actually
  wrong here.  The shrink wrapping optimization is working and the
  targets are not broken, it is just that, for these particular test
  cases, for these specific architectures (ARM, PPC), the unshrink-
  wrapped code is actually smaller than the shrink wrapped version.

  So - is it OK to apply the patch ?

Cheers
  Nick

gcc/testsuite/ChangeLog
2017-01-20  Nick Clifton  

* gcc.dg/pr10474.c: Update XFAIL comment to explain why the
check for shrink-wrapping can be expected to fail.
* gcc.dg/vect/vect-strided-a-u8-i2-gap.c: Likewise.

Index: gcc/testsuite/gcc.dg/ira-shrinkwrap-prep-2.c
===
--- gcc/testsuite/gcc.dg/ira-shrinkwrap-prep-2.c	(revision 244691)
+++ gcc/testsuite/gcc.dg/ira-shrinkwrap-prep-2.c	(working copy)
@@ -31,5 +31,7 @@
 
 /* { dg-final { scan-rtl-dump "Will split live ranges of parameters" "ira"  } } */
 /* { dg-final { scan-rtl-dump "Split live-range of register" "ira"  } } */
-/* XFAIL due to PR70681.  */ 
+/* The XFAILs are because these targets produce better code without
+   shrinkwrapping, and hence the optimization is not triggered.  See
+   PR70681 for more details.  */
 /* { dg-final { scan-rtl-dump "Performing shrink-wrapping" "pro_and_epilogue" { xfail arm*-*-* powerpc*-*-* } } } */
Index: gcc/testsuite/gcc.dg/pr10474.c
===
--- gcc/testsuite/gcc.dg/pr10474.c	(revision 244691)
+++ gcc/testsuite/gcc.dg/pr10474.c	(working copy)
@@ -12,5 +12,7 @@
 	}
 }
 
-/* XFAIL due to PR70681.  */ 
+/* The XFAILs are because these targets produce better code without
+   shrinkwrapping, and hence the optimization is not triggered.  See
+   PR70681 for more details.  */
 /* { dg-final { scan-rtl-dump "Performing shrink-wrapping" "pro_and_epilogue"  { xfail arm*-*-* powerpc*-*-* } } } */

Re: [PATCH] Add AVX512 k-mask intrinsics

[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.

So, no much hurry. Pls add runtime tests.

--
Thanks, K
>
> Uros.

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

[Richard Earnshaw (lists)]

On 01/09/16 10:03, Richard Earnshaw (lists) wrote:
> On 01/09/16 10:03, Richard Earnshaw (lists) wrote:
>> On 01/09/16 08:47, Eric Botcazou wrote:
 Since you're going to need a back-port there should be a PR filed for this.
>>>
>>> PR target/77439
>>>
 Have you checked that this works with multi-lib dejagnu runs and on
 hard-float systems?  I doubt this will work in armhf-linux, for example.
>>>
>>> No, I guess some dg-skip-if would be in order, but I'm not able to devise 
>>> one.
>>>
>>
>> Since the test is an execution test, why not just drop the problematic
>> parts of dg-options "-mfpu=vfp -mfloat-abi=softfp" and rely on multilib
>> permutations as appropriate.  That gives more all-round coverage as well.
>>
>> R.
>>
> 
> That would also allow you to drop the effective-target test as well.
> 
> R.
> 

This seems to have fallen through a crack.  Did you get a chance to try
either of these suggestions?

R.

Re: RFA: Update XFAIL comments in

[Andreas Schwab]

On Jan 20 2017, Nick Clifton  wrote:

> Index: gcc/testsuite/gcc.dg/ira-shrinkwrap-prep-2.c
> ===
> --- gcc/testsuite/gcc.dg/ira-shrinkwrap-prep-2.c  (revision 244691)
> +++ gcc/testsuite/gcc.dg/ira-shrinkwrap-prep-2.c  (working copy)
> @@ -31,5 +31,7 @@
>  
>  /* { dg-final { scan-rtl-dump "Will split live ranges of parameters" "ira"  
> } } */
>  /* { dg-final { scan-rtl-dump "Split live-range of register" "ira"  } } */
> -/* XFAIL due to PR70681.  */ 
> +/* The XFAILs are because these targets produce better code without
> +   shrinkwrapping, and hence the optimization is not triggered.  See
> +   PR70681 for more details.  */
>  /* { dg-final { scan-rtl-dump "Performing shrink-wrapping" 
> "pro_and_epilogue" { xfail arm*-*-* powerpc*-*-* } } } */

Shouldn't that rather be target { ! { arm*-*-* powerpc*-*-* } }?

Andreas.

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

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

[Jonathan Wakely]

On 19/01/17 12:05 +, Joe Seymour wrote:

Here's the patch I'm proposing. I've tested it as follows:

- msp430-elf no longer encounters the error when configuring libstdc++-v3. Note
 that libstdc++-v3 doesn't build due to an ICE though.

- Configuring libstdc++-v3 for x86_64-unknown-linux-gnu produces:
 include/bits/c++config.h:#define _GLIBCXX_MANGLE_SIZE_T m
 Both with and without this patch.

- Configuring libstdc++-v3 for i686-unknown-linux-gnu produces:
 include/bits/c++config.h:#define _GLIBCXX_MANGLE_SIZE_T j
 Both with and without this patch.

If it's acceptable I would appreciate it if someone would commit it on my
behalf.


Done - it's committed to trunk now. Thanks for the patch.

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

[Eric Botcazou]

> 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?

-- 
Eric Botcazou

Re: [1/5][AArch64] Return address protection on AArch64

[Jiong Wang]

Here is the patch.

For XPACLRI builtin which drops the signature in a pointer, it's
prototype is  "void *foo (void *)"
FOR PAC/AUT builtin which sign or authenticate a pointer, it's prototype
is "void *foo (void *, uint64)".

This patch adjusted those modes to make sure they strictly follow the C
prototype. I also borrow the type define in ARM backend

   typedef unsigned _uw64 __attribute__((mode(__DI__)));

And this is need to type cast the salt value which is always DImode.

It passed my local ILP32 cross build.

OK for trunk?

gcc/
2017-01-20  Jiong Wang  
 * config/aarch64/aarch64-builtins.c (aarch64_expand_builtin):
Fix modes
 for AARCH64_PAUTH_BUILTIN_XPACLRI,
AARCH64_PAUTH_BUILTIN_PACIA1716 and
 AARCH64_PAUTH_BUILTIN_AUTIA1716.

libgcc/
 * config/aarch64/aarch64-unwind.h (_uw64): New typedef.
 (aarch64_post_extract_frame_addr):  Cast salt to _uw64.
 (aarch64_post_frob_eh_handler_addr): Likewise.



Hmm, we currently don't support ILP32 at all for pointer signing (sorry
("Return address signing is only supported for -mabi=lp64");), so I
wonder if it would be better for now to simply suppress all the new
hooks in aarch64-unwind.h ifdef __ILP32__.

R.



OK, the attached patch disable the building of pointer signing code in libgcc
on ILP32 mode, except the macro bit RA_A_SIGNED_BIT is still defined as I
want to book this bit for ILP32 as LP64 in case we later enable ILP32 support.

All pauth builtins are not registered as well for ILP32 mode as these builtins
are supposed to be used by libgcc unwinder code only.

I also gated the three new testcases for return address signing using the
following directive and verified it works under my dejagnu environment.

{ dg-require-effective-target lp64 }

multilib cross build finished (lp64, ilp32), OK for trunk?

BTW, the mode fix patch doesn't have conflict with this patch, we may
still need it if we want to enable ILP32 support later.

Thanks.

gcc/
2017-01-20  Jiong Wang  

* config/aarch64/aarch64-builtins.c (aarch64_init_builtins): Don't
register pauth builtins for ILP32.

libgcc/
* config/aarch64/aarch64-unwind.h: Restrict this file on LP64 only.
* unwind-dw2.c (execute_cfa_program):  Only multiplexing
DW_CFA_GNU_window_save for AArch64 LP64.


diff --git a/gcc/config/aarch64/aarch64-builtins.c b/gcc/config/aarch64/aarch64-builtins.c
index 7ef351eb53b21c94a07dbd7c49813276dfcebdb2..66bcb9ad5872d1f6cac4ce9613806eb390be33af 100644
--- a/gcc/config/aarch64/aarch64-builtins.c
+++ b/gcc/config/aarch64/aarch64-builtins.c
@@ -983,9 +983,14 @@ aarch64_init_builtins (void)
   aarch64_init_crc32_builtins ();
   aarch64_init_builtin_rsqrt ();
 
-/* Initialize pointer authentication builtins which are backed by instructions
-   in NOP encoding space.  */
-  aarch64_init_pauth_hint_builtins ();
+  /* Initialize pointer authentication builtins which are backed by instructions
+ in NOP encoding space.
+
+ NOTE: these builtins are supposed to be used by libgcc unwinder only, as
+ there is no support on return address signing under ILP32, we don't
+ register them.  */
+  if (!TARGET_ILP32)
+aarch64_init_pauth_hint_builtins ();
 }
 
 tree
diff --git a/gcc/testsuite/gcc.target/aarch64/return_address_sign_1.c b/gcc/testsuite/gcc.target/aarch64/return_address_sign_1.c
index fda72a414f1df7e81785864e994681e3695852f1..f87c3d28d1edff473a787a39a436e57076f97508 100644
--- a/gcc/testsuite/gcc.target/aarch64/return_address_sign_1.c
+++ b/gcc/testsuite/gcc.target/aarch64/return_address_sign_1.c
@@ -1,6 +1,7 @@
 /* Testing return address signing where no combined instructions used.  */
 /* { dg-do compile } */
 /* { dg-options "-O2 -msign-return-address=all" } */
+/* { dg-require-effective-target lp64 } */
 
 int foo (int);
 
diff --git a/gcc/testsuite/gcc.target/aarch64/return_address_sign_2.c b/gcc/testsuite/gcc.target/aarch64/return_address_sign_2.c
index 54fe47a69723d182c65941ddb73e2f1a5aa0af84..c5c1439b92e6637f85c47c6161cd797c0d68df25 100644
--- a/gcc/testsuite/gcc.target/aarch64/return_address_sign_2.c
+++ b/gcc/testsuite/gcc.target/aarch64/return_address_sign_2.c
@@ -1,6 +1,7 @@
 /* Testing return address signing where combined instructions used.  */
 /* { dg-do compile } */
 /* { dg-options "-O2 -msign-return-address=all" } */
+/* { dg-require-effective-target lp64 } */
 
 int foo (int);
 int bar (int, int);
diff --git a/gcc/testsuite/gcc.target/aarch64/return_address_sign_3.c b/gcc/testsuite/gcc.target/aarch64/return_address_sign_3.c
index adc5effdded8900b2dfb68459883d399ebd91ac8..7d9ec6eebd1ce452013d2895a551671c59e98f0c 100644
--- a/gcc/testsuite/gcc.target/aarch64/return_address_sign_3.c
+++ b/gcc/testsuite/gcc.target/aarch64/return_address_sign_3.c
@@ -1,6 +1,7 @@
 /* Testing the disable of return address signing.  */
 /* { dg-do compile } */
 /* { dg-options "-O2 -msign-return-address=all" } */
+/* { dg-require-effective-target lp64 } */
 
 int bar (int, int);
 
d

Re: [1/5][AArch64] Return address protection on AArch64

[Jiong Wang]

On 20/01/17 18:23, Jiong Wang wrote:


OK, the attached patch disable the building of pointer signing code in 
libgcc

on ILP32 mode, except the macro bit RA_A_SIGNED_BIT is still defined as I
want to book this bit for ILP32 as LP64 in case we later enable ILP32 
support.


All pauth builtins are not registered as well for ILP32 mode as these 
builtins

are supposed to be used by libgcc unwinder code only.

I also gated the three new testcases for return address signing using the
following directive and verified it works under my dejagnu environment.

{ dg-require-effective-target lp64 }

multilib cross build finished (lp64, ilp32), OK for trunk?

BTW, the mode fix patch doesn't have conflict with this patch, we may
still need it if we want to enable ILP32 support later.

Thanks.

gcc/
2017-01-20  Jiong Wang  

* config/aarch64/aarch64-builtins.c (aarch64_init_builtins): 
Don't

register pauth builtins for ILP32.

libgcc/
* config/aarch64/aarch64-unwind.h: Restrict this file on LP64 
only.

* unwind-dw2.c (execute_cfa_program):  Only multiplexing
DW_CFA_GNU_window_save for AArch64 LP64.




Missing testcase change in Changelog, added:

gcc/
2017-01-20  Jiong Wang  

 * config/aarch64/aarch64-builtins.c (aarch64_init_builtins): Register
 register pauth builtins for LP64 only.
 * testsuite/gcc.target/aarch64/return_address_sign_1.c: Enable on LP64
 only.
 * testsuite/gcc.target/aarch64/return_address_sign_2.c: Likewise.
 * testsuite/gcc.target/aarch64/return_address_sign_3.c: Likewise.

libgcc/
 * config/aarch64/aarch64-unwind.h: Empty this file on ILP32.
 * unwind-dw2.c (execute_cfa_program):  Only multiplexing
 DW_CFA_GNU_window_save for AArch64 and LP64.

Re: [1/5][AArch64] Return address protection on AArch64

[Richard Earnshaw (lists)]

On 20/01/17 18:30, Jiong Wang wrote:
> 
> On 20/01/17 18:23, Jiong Wang wrote:
>>
>> OK, the attached patch disable the building of pointer signing code in
>> libgcc
>> on ILP32 mode, except the macro bit RA_A_SIGNED_BIT is still defined as I
>> want to book this bit for ILP32 as LP64 in case we later enable ILP32
>> support.
>>
>> All pauth builtins are not registered as well for ILP32 mode as these
>> builtins
>> are supposed to be used by libgcc unwinder code only.
>>
>> I also gated the three new testcases for return address signing using the
>> following directive and verified it works under my dejagnu environment.
>>
>> { dg-require-effective-target lp64 }
>>
>> multilib cross build finished (lp64, ilp32), OK for trunk?
>>
>> BTW, the mode fix patch doesn't have conflict with this patch, we may
>> still need it if we want to enable ILP32 support later.
>>
>> Thanks.
>>
>> gcc/
>> 2017-01-20  Jiong Wang  
>>
>> * config/aarch64/aarch64-builtins.c (aarch64_init_builtins):
>> Don't
>> register pauth builtins for ILP32.
>>
>> libgcc/
>> * config/aarch64/aarch64-unwind.h: Restrict this file on LP64
>> only.
>> * unwind-dw2.c (execute_cfa_program):  Only multiplexing
>> DW_CFA_GNU_window_save for AArch64 LP64.
>>
>>
> 
> Missing testcase change in Changelog, added:
> 
> gcc/
> 2017-01-20  Jiong Wang  
> 
>  * config/aarch64/aarch64-builtins.c (aarch64_init_builtins):
> Register
>  register pauth builtins for LP64 only.
>  * testsuite/gcc.target/aarch64/return_address_sign_1.c: Enable
> on LP64
>  only.
>  * testsuite/gcc.target/aarch64/return_address_sign_2.c: Likewise.
>  * testsuite/gcc.target/aarch64/return_address_sign_3.c: Likewise.
> 
> libgcc/
>  * config/aarch64/aarch64-unwind.h: Empty this file on ILP32.
>  * unwind-dw2.c (execute_cfa_program):  Only multiplexing
>  DW_CFA_GNU_window_save for AArch64 and LP64.
> 
> 

The testsuite has its own ChangeLog file.

Otherwise OK.

R.

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

[Jeff Law]

On 01/20/2017 02:46 AM, Martin Liška wrote:

On 01/13/2017 06:21 PM, 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



May I install the same patch to both active branches after it survives 
regression tests?

Yes.

jeff

Re: Improve things for PR71724, in combine/if_then_else_cond

[Segher Boessenkool]

Hi Bernd,

On Fri, Jan 20, 2017 at 01:33:59PM +0100, Bernd Schmidt wrote:
> So, when looking for situations where we have only one condition, we can 
> try to undo the conversion of a plain REG into a condition, on the 
> grounds that this is probably less helpful.
> 
> This seems to cure the testcase, but Segher also has a patch in the PR 
> that looks like a good and more direct approach. IMO both should be 
> applied. This one was bootstrapped and tested on x86_64-linux. Ok?

My patch does not cure all problems, it simply simplifies things a bit
better; but the same is true for your patch if I read it correctly.

Okay for trunk, and I'll do my half as well.  Thanks,


Segher


>   PR rtl-optimization/71724
>   * combine.c (if_then_else_cond): Look for situations where it is
>   beneficial to undo the work of one of the recursive calls.

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

[Jeff Law]

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.

Blame me.

My thinking was that the warnings themselves are just part of what we 
want to be doing.  We ought to be warning *and* doing erroneous path 
isolation when we find these out of bounds situations.  I felt that VRP 
was already complex and big enough that adding the additional code to do 
the path specific bounds checking and path isolation wasn't appropriate.


The downside is that we lose a lot of valuable information when we leave 
VRP -- essentially what's left attached to a given SSA_NAME is a 
conservative range that applies in all contexts where the SSA_NAME is 
used.  And that is usually too imprecise to give the warnings we want.


jeff

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

[Jeff Law]

On 01/20/2017 09:37 AM, 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?
Time and space complexity.  To get the range information in this case we 
have to create new SSA_NAMEs and PHI nodes to merge them at BB3.


Even if you create them, passes post VRP are going to blow them away :-)

This is the problem Andrew is working on.  In simplest terms the ability 
to query the range of an object on a path through the CFG.  So we could 
ask for the range of n_9 on the edge 2->3 (<=9) or we could ask for the 
range of n_9 on the edge 2->4 which would be > 9.





Jeff

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

[Jakub Jelinek]

On Fri, Jan 20, 2017 at 12:35:32PM -0700, Jeff Law wrote:
> > This may be a naive question but why is it not possible to create
> > such an SSA name?
> Time and space complexity.  To get the range information in this case we
> have to create new SSA_NAMEs and PHI nodes to merge them at BB3.

Not just that.  Also lots of optimizations rely on the extra SSA_NAME copies
to be removed to be able to optimize well.  If you'd have lots of SSA_NAMEs with
the same value, just differing with their range info, then unless passes
perform SCCVN or something similar, they wouldn't be able to figure equality
etc.  And if in SCCVN those SSA_NAMEs with different range info, but same
value, compare the same, then they are going to be replaced just by one of
them anyway.

> Even if you create them, passes post VRP are going to blow them away :-)

Exactly.

Jakub

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

[Jeff Law]

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 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.



Jeff

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

[Andreas Tobler]

On 20.01.17 17:12, Richard Earnshaw (lists) wrote:

On 19/01/17 06:38, Andreas Tobler wrote:

On 19.01.17 00:33, Jeff Law wrote:

On 01/18/2017 11:43 AM, Andreas Tobler wrote:

Hi all,

I have the following issue here on aarch64-*-freebsd:

(sorry if the format is hardly readable)

..
/export/devel/net/src/gcc/head/gcc/gcc/config/aarch64/aarch64.c: In
function 'void aarch64_elf_asm_destructor(rtx, int)':
/export/devel/net/src/gcc/head/gcc/gcc/config/aarch64/aarch64.c:5760:1:
error: %.5u' directive output may be truncated writing between 5 and 10
bytes into a region of size 6 [-Werror=format-truncation=]
 aarch64_elf_asm_destructor (rtx symbol, int priority)
 ^~
/export/devel/net/src/gcc/head/gcc/gcc/config/aarch64/aarch64.c:5760:1:
note: using the range [1, 4294967295] for directive argument
/export/devel/net/src/gcc/head/gcc/gcc/config/aarch64/aarch64.c:5768:65:
note: format output between 18 and 23 bytes into a destination of
size 18
   snprintf (buf, sizeof (buf), ".fini_array.%.5u", priority);

^
...

This is the code snippet, it does not only occur in aarch64, but also at
least in pa and avr.


static void
aarch64_elf_asm_destructor (rtx symbol, unsigned short priority)
{
  if (priority == DEFAULT_INIT_PRIORITY)
default_dtor_section_asm_out_destructor (symbol, priority);
  else
{
  section *s;
  char buf[18];
  snprintf (buf, sizeof (buf), ".fini_array.%.5u", priority);
  s = get_section (buf, SECTION_WRITE, NULL);
  switch_to_section (s);
  assemble_align (POINTER_SIZE);
  assemble_aligned_integer (POINTER_BYTES, symbol);
}
}


I have now four options to solve this, (a fifth one would be to remove
format-truncation from -Wall/Wextra?)

1.) increase buf to 23
2.) use %.5hu in snprintf
3.) cast priority in snprintf to (unsigned int)
4.) make priority unsigned short.

Solution 1, 2 and 3 work, but with pros and cons.

#3 likely won't work with with lower optimization levels since it
depends on VRP to narrow the object's range.

I'd approve #2 or #1 without hesitation.


Ok.

I did a mistake while describing the situation. The function has this
parameter:

aarch64_elf_asm_destructor (rtx symbol, int priority)

I copied the already modified piece of code



Ah, that makes much more sense.


So the cast in #3 would be (unsigned short) iso (unsigned int).

If no other opinions come up I'll go with #2.

Thanks.
Andreas




I agree, some sort of cast seems preferable.  The documentation for
constructor priorities says that the lowest priority is 65535, so
alternatives here are:

- assert (priority < 65536) then cast to unsigned short.
- simply cast to unsigned short
- saturate to 16 bits unsigned then cast to short.

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)


Thanks,
Andreas

Re: Another cprop trap_if fix, PR79125

[Jeff Law]

On 01/20/2017 05:24 AM, Bernd Schmidt wrote:

This is essentially the same patch I sent for the previous instance of
this problem, but this time applied to local_cprop_pass. Bootstrapped
and tested on x86_64-linux, and it seems to fix the testcase with a ppc
cross. Ok?


Bernd

pr79125.diff


PR rtl-optimization/79125
* cprop.c (local_cprop_pass): Handle cases where we make an
unconditional trap.

PR rtl-optimization/79125
* gcc.dg/torture/pr79125.c: New test.
OK.  Though part of me dislikes having this code appear twice, but I can 
live with it.


jeff

Re: [PATCH] Add AVX512 k-mask intrinsics

[Andrew Senkevich]

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..

Updated changelog:

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.
* gcc.target/i386/avx512bw-ktestd-2.c: Ditt
* gcc.target/i386/avx512bw-ktestq-2.c: Ditto.
* gcc.target/i386/avx512dq-ktestb-2.c: Ditto.
* gcc.target/i386/avx512f-ktestw-2.c: Ditto.
* gcc.target/i386/avx512bw-kortestd-2.c: Ditto.
* gcc.target/i386/avx512bw-kortestq-2.c: Ditto.
* gcc.target/i386/avx512dq-kortestb-2.c: Ditto.
* gcc.target/i386/avx512f-kortestw-2.c: Ditto.


--
WBR,
Andrew


avx512-kmask-intrin-part5.patch
Description: Binary data

Re: [PATCH 9e] Update "startwith" logic for pass-skipping to handle __RTL functions

[Jeff Law]

On 01/19/2017 02:26 AM, Richard Biener wrote:

On Wed, Jan 18, 2017 at 5:36 PM, Jeff Law  wrote:

On 01/17/2017 02:28 AM, Richard Biener wrote:



This feels somewhat different, but still a hack.

I don't have strong suggestions on how to approach this, but what we've
got
here feels like a hack and one prone to bitrot.



All the above needs a bit of cleanup in the way we use (or not use)
PROP_xxx.
For example right now you can't startwith a __GIMPLE with a pass inside
the
loop pipeline because those passes expect loops to be initialized and be
in
loop-closed SSA.  And with the hack above for the property providers
you'll
always run pass_crited (that's a bad user of a PROP_).

Ideally we'd figure out required properties from the startwith pass
(but there's not
an easy way to compute it w/o actually "executing" the passes) and then
enable
enough passes on the way to it providing those properties.

Or finally restructure things in a way that the pass manager automatically
runs
property provider passes before passes requiring properties that are
not yet available...

Instead of those pass->name comparisions we could invent a new flag in the
pass structure whether a pass should always be run for __GIMPLE or ___RTL
but that's a bit noisy right now.

So I'm fine with the (localized) "hacks" for the moment.


David suggested that we could have a method in the pass manager that would
be run if the pass is skipped.  "run_if_skipped" or some such.

What I like about that idea is the hack and the real code end up in the same
place.  So someone working on (for example) reload has a much better chance
of catching that they need to update the run_if_skipped method as they make
changes to reload.  It doesn't fix all the problems in this space, but I
think it's cleaner than bundling the hacks into the pass manager itself.

Would that work for you?  It does for me.


I think that walks in the wrong direction and just distributes the
hack over multiple
files.

I'd rather have it in one place.
We disagree, but I don't feel strongly enough about it to object. 
Though I'll probably chime in regularly as the list of hacks grows or 
gets out-of-date  :-)



Jeff

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

[Jeff Law]

On 01/20/2017 12:56 PM, Andreas Tobler wrote:

On 20.01.17 17:12, Richard Earnshaw (lists) wrote:

On 19/01/17 06:38, Andreas Tobler wrote:

On 19.01.17 00:33, Jeff Law wrote:

On 01/18/2017 11:43 AM, Andreas Tobler wrote:

Hi all,

I have the following issue here on aarch64-*-freebsd:

(sorry if the format is hardly readable)

..
/export/devel/net/src/gcc/head/gcc/gcc/config/aarch64/aarch64.c: In
function 'void aarch64_elf_asm_destructor(rtx, int)':
/export/devel/net/src/gcc/head/gcc/gcc/config/aarch64/aarch64.c:5760:1:

error: %.5u' directive output may be truncated writing between 5
and 10
bytes into a region of size 6 [-Werror=format-truncation=]
 aarch64_elf_asm_destructor (rtx symbol, int priority)
 ^~
/export/devel/net/src/gcc/head/gcc/gcc/config/aarch64/aarch64.c:5760:1:

note: using the range [1, 4294967295] for directive argument
/export/devel/net/src/gcc/head/gcc/gcc/config/aarch64/aarch64.c:5768:65:

note: format output between 18 and 23 bytes into a destination of
size 18
   snprintf (buf, sizeof (buf), ".fini_array.%.5u", priority);

^
...

This is the code snippet, it does not only occur in aarch64, but
also at
least in pa and avr.


static void
aarch64_elf_asm_destructor (rtx symbol, unsigned short priority)
{
  if (priority == DEFAULT_INIT_PRIORITY)
default_dtor_section_asm_out_destructor (symbol, priority);
  else
{
  section *s;
  char buf[18];
  snprintf (buf, sizeof (buf), ".fini_array.%.5u", priority);
  s = get_section (buf, SECTION_WRITE, NULL);
  switch_to_section (s);
  assemble_align (POINTER_SIZE);
  assemble_aligned_integer (POINTER_BYTES, symbol);
}
}


I have now four options to solve this, (a fifth one would be to remove
format-truncation from -Wall/Wextra?)

1.) increase buf to 23
2.) use %.5hu in snprintf
3.) cast priority in snprintf to (unsigned int)
4.) make priority unsigned short.

Solution 1, 2 and 3 work, but with pros and cons.

#3 likely won't work with with lower optimization levels since it
depends on VRP to narrow the object's range.

I'd approve #2 or #1 without hesitation.


Ok.

I did a mistake while describing the situation. The function has this
parameter:

aarch64_elf_asm_destructor (rtx symbol, int priority)

I copied the already modified piece of code



Ah, that makes much more sense.


So the cast in #3 would be (unsigned short) iso (unsigned int).

If no other opinions come up I'll go with #2.

Thanks.
Andreas




I agree, some sort of cast seems preferable.  The documentation for
constructor priorities says that the lowest priority is 65535, so
alternatives here are:

- assert (priority < 65536) then cast to unsigned short.
- simply cast to unsigned short
- saturate to 16 bits unsigned then cast to short.

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.


jeff

Re: libgo patch committed: Fix build on s390x GNU/Linux

[Ian Lance Taylor]

On Thu, Jan 19, 2017 at 6:27 PM, Ian Lance Taylor  wrote:
> This patch to libgo fixes the build on s390x GNU/Linux by ignoring an
> s390x-specific file that only works in conjunction with s390x assembly
> code that has not (yet) been ported to gccgo.  Bootstrapped and ran Go
> tests on x86_64-pc-linux-gnu, which admittedly proves little.
> Verified that the right files are selected when building for s390.
> This fixes GCC PR 79146.

And another fix, for a similar problem that only appears at link time,
not compile time.  Bootstrapped on x86_64-pc-linux-gnu, checked list
of files compiled on s390x.  Committed to mainline.

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 244679)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-a21ebb50459ba9608d0325ad1c1d62e6c9290186
+907f6e31975443993c47fa45e09cf85d0709b7e6
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: libgo/go/math/big/arith_decl_s390x.go
===
--- libgo/go/math/big/arith_decl_s390x.go   (revision 244456)
+++ libgo/go/math/big/arith_decl_s390x.go   (working copy)
@@ -2,6 +2,7 @@
 // Use of this source code is governed by a BSD-style
 // license that can be found in the LICENSE file.
 
+// +build ignore
 // +build !math_big_pure_go
 
 package big

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

[Richard Earnshaw (lists)]

On 20/01/17 19:56, Andreas Tobler wrote:
> On 20.01.17 17:12, Richard Earnshaw (lists) wrote:
>> On 19/01/17 06:38, Andreas Tobler wrote:
>>> On 19.01.17 00:33, Jeff Law wrote:
 On 01/18/2017 11:43 AM, Andreas Tobler wrote:
> Hi all,
>
> I have the following issue here on aarch64-*-freebsd:
>
> (sorry if the format is hardly readable)
>
> ..
> /export/devel/net/src/gcc/head/gcc/gcc/config/aarch64/aarch64.c: In
> function 'void aarch64_elf_asm_destructor(rtx, int)':
> /export/devel/net/src/gcc/head/gcc/gcc/config/aarch64/aarch64.c:5760:1:
>
> error: %.5u' directive output may be truncated writing between 5
> and 10
> bytes into a region of size 6 [-Werror=format-truncation=]
>  aarch64_elf_asm_destructor (rtx symbol, int priority)
>  ^~
> /export/devel/net/src/gcc/head/gcc/gcc/config/aarch64/aarch64.c:5760:1:
>
> note: using the range [1, 4294967295] for directive argument
> /export/devel/net/src/gcc/head/gcc/gcc/config/aarch64/aarch64.c:5768:65:
>
> note: format output between 18 and 23 bytes into a destination of
> size 18
>snprintf (buf, sizeof (buf), ".fini_array.%.5u", priority);
>
> ^
> ...
>
> This is the code snippet, it does not only occur in aarch64, but
> also at
> least in pa and avr.
>
> 
> static void
> aarch64_elf_asm_destructor (rtx symbol, unsigned short priority)
> {
>   if (priority == DEFAULT_INIT_PRIORITY)
> default_dtor_section_asm_out_destructor (symbol, priority);
>   else
> {
>   section *s;
>   char buf[18];
>   snprintf (buf, sizeof (buf), ".fini_array.%.5u", priority);
>   s = get_section (buf, SECTION_WRITE, NULL);
>   switch_to_section (s);
>   assemble_align (POINTER_SIZE);
>   assemble_aligned_integer (POINTER_BYTES, symbol);
> }
> }
> 
>
> I have now four options to solve this, (a fifth one would be to remove
> format-truncation from -Wall/Wextra?)
>
> 1.) increase buf to 23
> 2.) use %.5hu in snprintf
> 3.) cast priority in snprintf to (unsigned int)
> 4.) make priority unsigned short.
>
> Solution 1, 2 and 3 work, but with pros and cons.
 #3 likely won't work with with lower optimization levels since it
 depends on VRP to narrow the object's range.

 I'd approve #2 or #1 without hesitation.
>>>
>>> Ok.
>>>
>>> I did a mistake while describing the situation. The function has this
>>> parameter:
>>>
>>> aarch64_elf_asm_destructor (rtx symbol, int priority)
>>>
>>> I copied the already modified piece of code
>>>
>>
>> Ah, that makes much more sense.
>>
>>> So the cast in #3 would be (unsigned short) iso (unsigned int).
>>>
>>> If no other opinions come up I'll go with #2.
>>>
>>> Thanks.
>>> Andreas
>>>
>>>
>>
>> I agree, some sort of cast seems preferable.  The documentation for
>> constructor priorities says that the lowest priority is 65535, so
>> alternatives here are:
>>
>> - assert (priority < 65536) then cast to unsigned short.
>> - simply cast to unsigned short
>> - saturate to 16 bits unsigned then cast to short.
>>
>> 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)
> 
> 
> Thanks,
> Andreas
> 

Not a really valid use of destructors, but

void  __attribute__((destructor(65536))) f()
{
}

causes
/tmp/x.c:2:1: error: destructor priorities must be integers from 0 to
65535 inclusive
 {


So I think we can ignore saturation.  Now it's down to assert then cast
or simply cast.

My inclination is just the cast at this point.

R.

libgo patch committed: Fixes for cgo

[Ian Lance Taylor]

This patch to libgo fixes misc/cgo/test in the master repository to
work with gccgo.

The package testing/internal/testdeps is now installed.  It is
required by the new go test.

The function runtime.lockedOSThread is exported from the runtime
package, so that it can be called from misc/cgo/test using a
go:linkname comment.

We loop on EAGAIN when creating a new thread.  This is what the gc
library does, and misc/cgo/test has a test for it.

Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.  Committed
to mainline.

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 244731)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-907f6e31975443993c47fa45e09cf85d0709b7e6
+b573d4756096523d8bd4bf7b11e56383e5a2cca4
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: libgo/Makefile.am
===
--- libgo/Makefile.am   (revision 244483)
+++ libgo/Makefile.am   (working copy)
@@ -360,6 +360,11 @@ toolexeclibgotesting_DATA = \
testing/iotest.gox \
testing/quick.gox
 
+toolexeclibgotestinginternaldir = $(toolexeclibgotestingdir)/internal
+
+toolexeclibgotestinginternal_DATA = \
+   testing/internal/testdeps.gox
+
 toolexeclibgotextdir = $(toolexeclibgodir)/text
 
 toolexeclibgotext_DATA = \
Index: libgo/go/runtime/proc.go
===
--- libgo/go/runtime/proc.go(revision 244456)
+++ libgo/go/runtime/proc.go(working copy)
@@ -43,6 +43,9 @@ import (
 //go:linkname runqempty runtime.runqempty
 //go:linkname runqput runtime.runqput
 
+// Function called by misc/cgo/test.
+//go:linkname lockedOSThread runtime.lockedOSThread
+
 // Functions temporarily in C that have not yet been ported.
 func allocm(*p, bool, *unsafe.Pointer, *uintptr) *m
 func malg(bool, bool, *unsafe.Pointer, *uintptr) *g
Index: libgo/runtime/proc.c
===
--- libgo/runtime/proc.c(revision 244456)
+++ libgo/runtime/proc.c(working copy)
@@ -2,6 +2,7 @@
 // Use of this source code is governed by a BSD-style
 // license that can be found in the LICENSE file.
 
+#include 
 #include 
 #include 
 #include 
@@ -216,6 +217,7 @@ runtime_newosproc(M *mp)
pthread_attr_t attr;
sigset_t clear, old;
pthread_t tid;
+   int tries;
int ret;
 
if(pthread_attr_init(&attr) != 0)
@@ -234,11 +236,21 @@ runtime_newosproc(M *mp)
 
sigemptyset(&old);
pthread_sigmask(SIG_BLOCK, &clear, &old);
-   ret = pthread_create(&tid, &attr, runtime_mstart, mp);
+
+   for (tries = 0; tries < 20; tries++) {
+   ret = pthread_create(&tid, &attr, runtime_mstart, mp);
+   if (ret != EAGAIN) {
+   break;
+   }
+   runtime_usleep((tries + 1) * 1000); // Milliseconds.
+   }
+
pthread_sigmask(SIG_SETMASK, &old, nil);
 
-   if (ret != 0)
+   if (ret != 0) {
+   runtime_printf("pthread_create failed: %d\n", ret);
runtime_throw("pthread_create");
+   }
 }
 
 // First function run by a new goroutine.  This replaces gogocall.

[PR 79108] Put ipa_node_params to GC memory

[Martin Jambor]

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?

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 1f68f736e46..4d77c9b25ef 100644
--- a/gcc/ipa-prop.c
+++ b/gcc/ipa-prop.c
@@ -99,13 +99,14 @@ ipa_func_spec_opts_forbid_analysis_p (struct cgraph_node 
*node)
to INFO.  */
 
 static int
-ipa_get_param_decl_index_1 (vec descriptors, tree ptree)
+ipa_get_param_decl_index_1 (

Re: [PATCH] Fix PR78515

[Martin Jambor]

Hi,

On Fri, Nov 25, 2016 at 02:55:29PM +0100, Richard Biener wrote:
> On Fri, 25 Nov 2016, Martin Jambor wrote:
>
> ...
>
> > > There's still that odd 'stmt2'
> > > hanging around that gets set to sth else than stmt with
> > > 
> > >   op1 = gimple_assign_rhs1 (stmt);
> > > 
> > >   if (TREE_CODE (op1) == SSA_NAME)
> > > {
> > >   if (SSA_NAME_IS_DEFAULT_DEF (op1))
> > > index = ipa_get_param_decl_index (info, SSA_NAME_VAR (op1));
> > >   else
> > > {
> > >   index = load_from_param (fbi, info->descriptors,
> > >SSA_NAME_DEF_STMT (op1));
> > >   stmt2 = SSA_NAME_DEF_STMT (op1);
> > > 
> > > I assume that the original code wanted to restrict its processing
> > > to unary RHS of 'stmt' but still this "skips" arbitrary unary
> > > operations in 'stmt'?  But maybe I'm not understanding jump functions
> > > here.  If we have
> > > 
> > >   _2 = -param_1(D);
> > >   _3 = ~_2;
> > > 
> > > and stmt is _3 then we create a unary pass through JF with - (and the ~
> > > gets lost?).
> > >
> > 
> > It definitely looks like that.  Unary arithmetic jump functions have
> > been added only recently with the IPA VRP propagation and I remember
> > staring at the stmt2 thingy for a while during review but then
> > apparently I forgot about it.
> > 
> > It seems to me that the check should refer to stmt, I will do that and
> > see what breaks and how the IL looks at that point and then decide
> > where to go from there.
> 
> it's the only use of stmt2 though, so it must have been added for some
> reason... (maybe somebody wanted to handle simple copy-propagation?!).
> I'd say rip it out and thus keep stmt2 == stmt.  There must be
> a testcase added for this...
> 

So I have pondered about this some more and found out that while the
current code really makes no sense, it is fortunately harmless because
load_from_param will suceed only if it looks at a load from a
PARM_DECL that does not have an SSA_NAME and so cannot have any
arithmetic operation associated with it.  That means that there cannot
really be any difference between load_from_unmodified_param and
load_from_param and so the patch below re-unifies them.

It also removes the stmt2 variable from
compute_complex_assign_jump_func which means that the function is
actually more powerful now, able to do IPA-VRP on the added
testcase... which kind of makes me wonder whether it is appropriate at
this stage, but I'd prefer to put the code in order.

Bootstrapped and tested on x86_64-linux.  LTO-bootstrapped and testing
of the result still running on the same architecture.  OK for trunk if
it succeeds?  (The patch is intended to go on top of my fix for PR
79108).

Sorry for not spotting this when reviewing the patch that introduced
it in the first place,

Martin


2017-01-20  Martin Jambor  

* ipa-prop.c (load_from_param_1): Removed.
(load_from_unmodified_param): Bits from load_from_param_1 put back
here.
(load_from_param): Removed.
(compute_complex_assign_jump_func): Removed stmt2 and just replaced it
with stmt.  Reverted back to use of load_from_unmodified_param.

testsuite/
* gcc.dg/ipa/vrp8.c: New test.
---
 gcc/ipa-prop.c  | 68 ++---
 gcc/testsuite/gcc.dg/ipa/vrp8.c | 42 +
 2 files changed, 58 insertions(+), 52 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/ipa/vrp8.c

diff --git a/gcc/ipa-prop.c b/gcc/ipa-prop.c
index 4d77c9b25ef..512bcbed0cb 100644
--- a/gcc/ipa-prop.c
+++ b/gcc/ipa-prop.c
@@ -862,31 +862,6 @@ parm_preserved_before_stmt_p (struct ipa_func_body_info 
*fbi, int index,
   return !modified;
 }
 
-/* Main worker for load_from_unmodified_param and load_from_param.
-   If STMT is an assignment that loads a value from an parameter declaration,
-   return the index of the parameter in ipa_node_params.  Otherwise return -1. 
 */
-
-static int
-load_from_param_1 (struct ipa_func_body_info *fbi,
-  vec *descriptors,
-  gimple *stmt)
-{
-  int index;
-  tree op1;
-
-  gcc_checking_assert (is_gimple_assign (stmt));
-  op1 = gimple_assign_rhs1 (stmt);
-  if (TREE_CODE (op1) != PARM_DECL)
-return -1;
-
-  index = ipa_get_param_decl_index_1 (descriptors, op1);
-  if (index < 0
-  || !parm_preserved_before_stmt_p (fbi, index, stmt, op1))
-return -1;
-
-  return index;
-}
-
 /* If STMT is an assignment that loads a value from an parameter declaration,
return the index of the parameter in ipa_node_params which has not been
modified.  Otherwise return -1.  */
@@ -896,29 +871,22 @@ load_from_unmodified_param (struct ipa_func_body_info 
*fbi,
vec *descriptors,
gimple *stmt)
 {
+  int index;
+  tree op1;
+
   if (!gimple_assign_single_p (stmt))
 return -1;
 
-  return load_from_param_1 (fbi, descriptors, stmt);
-}
-
-/* If STMT is an assignment that l

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

[Jakub Jelinek]

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.

--- gcc/dwarf2out.c.jj  2017-01-19 16:58:12.0 +0100
+++ gcc/dwarf2out.c 2017-01-20 12:51:10.466654949 +0100
@@ -10286,7 +10286,7 @@ output_compilation_unit_header (enum dwa
case DW_UT_split_type: name = "DW_UT_split_type"; break;
default: gcc_unreachable ();
}
-  dw2_asm_output_data (1, ut, name);
+  dw2_asm_output_data (1, ut, "%s", name);
   dw2_asm_output_data (1, DWARF2_ADDR_SIZE, "Pointer Size (in bytes)");
 }
   dw2_asm_output_offset (DWARF_OFFSET_SIZE, abbrev_section_label,
@@ -11551,7 +11551,8 @@ output_file_names (void)
   if (DWARF5_USE_DEBUG_LINE_STR)
str_form = DW_FORM_line_strp;
   dw2_asm_output_data_uleb128 (DW_LNCT_path, "DW_LNCT_path");
-  dw2_asm_output_data_uleb128 (str_form, get_DW_FORM_name (str_form));
+  dw2_asm_output_data_uleb128 (str_form, "%s",
+  get_DW_FORM_name (str_form));
   dw2_asm_output_data_uleb128 (ndirs + idx_offset, "Directories count");
   if (str_form == DW_FORM_string)
{
@@ -11631,10 +11632,12 @@ output_file_names (void)
   dw2_asm_output_data (1, 2, "File name entry format count");
 #endif
   dw2_asm_output_data_uleb128 (DW_LNCT_path, "DW_LNCT_path");
-  dw2_asm_output_data_uleb128 (str_form, get_DW_FORM_name (str_form));
+  dw2_asm_output_data_uleb128 (str_form, "%s",
+  get_DW_FORM_name (str_form));
   dw2_asm_output_data_uleb128 (DW_LNCT_directory_index,
   "DW_LNCT_directory_index");
-  dw2_asm_output_data_uleb128 (idx_form, get_DW_FORM_name (idx_form));
+  dw2_asm_output_data_uleb128 (idx_form, "%s",
+  get_DW_FORM_name (idx_form));
 #ifdef VMS_DEBUGGING_INFO
   dw2_asm_output_data_uleb128 (DW_LNCT_timestamp, "DW_LNCT_timestamp");
   dw2_asm_output_data_uleb128 (DW_FORM_udata, "DW_FORM_udata");

Jakub