Re: [PATCH] Fix reg-stack error-recovery on pr84828 testcase (PR target/84828)

[Richard Biener]

On Mon, 23 Apr 2018, Jakub Jelinek wrote:

> Hi!
> 
> My earlier attempts to replace bogus inline asm with something that
> reg-stack.c would be happy about failed, so this is just a quick hack to
> help the error-recovery on the pr84828.C testcase with -m32.
> 
> I bet bunch of other spots will need any_malformed_asm tweaks, just don't
> have testcases for those.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, fixes:
> -FAIL: g++.dg/ext/pr84828.C  -std=gnu++11 (internal compiler error)
> -FAIL: g++.dg/ext/pr84828.C  -std=gnu++11 (test for excess errors)
> -FAIL: g++.dg/ext/pr84828.C  -std=gnu++14 (internal compiler error)
> -FAIL: g++.dg/ext/pr84828.C  -std=gnu++14 (test for excess errors)
> -FAIL: g++.dg/ext/pr84828.C  -std=gnu++98 (internal compiler error)
> -FAIL: g++.dg/ext/pr84828.C  -std=gnu++98 (test for excess errors)
> on i686-linux, ok for trunk?

OK.

Thanks,
Richard.

> 2018-04-23  Jakub Jelinek  
> 
>   PR target/84828
>   * reg-stack.c (move_for_stack_reg): Don't fail assertion about dead
>   destination if any_malformed_asm.
> 
> --- gcc/reg-stack.c.jj2018-03-16 13:42:37.118852524 +0100
> +++ gcc/reg-stack.c   2018-04-23 17:16:41.085198214 +0200
> @@ -1105,13 +1105,16 @@ move_for_stack_reg (rtx_insn *insn, stac
>   }
>  
>/* The destination ought to be dead.  */
> -  gcc_assert (get_hard_regnum (regstack, dest) < FIRST_STACK_REG);
> +  if (get_hard_regnum (regstack, dest) >= FIRST_STACK_REG)
> + gcc_assert (any_malformed_asm);
> +  else
> + {
> +   replace_reg (psrc, get_hard_regnum (regstack, src));
>  
> -  replace_reg (psrc, get_hard_regnum (regstack, src));
> -
> -  regstack->reg[++regstack->top] = REGNO (dest);
> -  SET_HARD_REG_BIT (regstack->reg_set, REGNO (dest));
> -  replace_reg (pdest, FIRST_STACK_REG);
> +   regstack->reg[++regstack->top] = REGNO (dest);
> +   SET_HARD_REG_BIT (regstack->reg_set, REGNO (dest));
> +   replace_reg (pdest, FIRST_STACK_REG);
> + }
>  }
>else if (STACK_REG_P (src))
>  {
> 
>   Jakub
> 
> 

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

Re: [PATCH] Update nvptx newlib installation requirements

[Richard Biener]

On Mon, Apr 23, 2018 at 4:22 PM, Cesar Philippidis
 wrote:
> The nvptx port has been merged into newlib, so the Mentor Embedded
> github repository is no longer needed. While we're still maintaining the
> github mirror, given the stability of the nvptx port, going forward I
> expect all of the development to occur in the upstream newlib repository
> directly.
>
> This patch updates the install documentation to point the the upstream
> newlib sources instead of the Mentor Embedded github mirror. I don't see
> tarballs for any point releases on newlib's website, so I added a
> reference to the git revision containing nvptx port.
>
> Is this OK for trunk?

That's great news!  Note that we usually keep copies of build dependences at
ftp://gcc.gnu.org/pub/gcc/infrastructure/ and there's currently no nvptx newlib
variant there.  Maybe you can prepare a tarball that's ready to plug into gcc
sources with the nvptx support included?

Otherwise OK.

Btw, can you also update the GCC wiki with regarding to this change?

Thanks,
Richard.

> Thanks,
> Cesar

[PATCH] Fix PR85491

[Richard Biener]

The following patch restricts the previous fix for PR84037 to the case
of strided loads with non-constant step to avoid regression nbench
LU decomposition test on Haswell where the change causes us to use
AVX128 instead of AVX256 in the two critical loops.

Bootstrapped and tested on x86_64-unknown-linux-gnu.  SPEC CPU 2006
results are in the noise, so is SPEC CPU 2000 (200.sixtrack seems
to be awfully jumpy for me - it goes up and down by almost 50%!),
nbench LU factorization performance is back up.

OK for trunk?

Thanks,
Richard.

2018-04-24  Richard Biener  

PR target/85491
* config/i386/i386.c (ix86_add_stmt_cost): Restrict strided
load cost increase to the case of non-constant step.

Index: gcc/config/i386/i386.c
===
--- gcc/config/i386/i386.c  (revision 259556)
+++ gcc/config/i386/i386.c  (working copy)
@@ -50550,8 +50550,9 @@ ix86_add_stmt_cost (void *data, int coun
  construction cost by the number of elements involved.  */
   if (kind == vec_construct
   && stmt_info
-  && stmt_info->type == load_vec_info_type
-  && stmt_info->memory_access_type == VMAT_ELEMENTWISE)
+  && STMT_VINFO_TYPE (stmt_info) == load_vec_info_type
+  && STMT_VINFO_MEMORY_ACCESS_TYPE (stmt_info) == VMAT_ELEMENTWISE
+  && TREE_CODE (DR_STEP (STMT_VINFO_DATA_REF (stmt_info))) != INTEGER_CST)
 {
   stmt_cost = ix86_builtin_vectorization_cost (kind, vectype, misalign);
   stmt_cost *= TYPE_VECTOR_SUBPARTS (vectype);

[PATCH] Fix powerpc64le ICE in replace_swapped_load_constant (PR target/85503)

[Jakub Jelinek]

Hi!

The following patch adjusts the const_load_sequence_p predicate to match
what the replace_swapped_load_constant function guarded by it expects.

On the testcase base is a CONSTANT_POOL_ADDRESS_P SYMBOL_REF, but it
contains an address of a static data member + 8, so not a CONST_VECTOR nor
a CONSTANT_POOL_ADDRESS_P SYMBOL_REF.

Bootstrapped/regtested on powerpc64le-linux and powerpc64-linux, ok for
trunk?

2018-04-24  Jakub Jelinek  

PR target/85503
* config/rs6000/rs6000-p8swap.c (const_load_sequence_p): Punt if
const_vector is not CONST_VECTOR or SYMBOL_REF for a constant pool
containing a CONST_VECTOR.

* g++.dg/ext/pr85503.C: New test.

--- gcc/config/rs6000/rs6000-p8swap.c.jj2018-03-20 22:05:58.0 
+0100
+++ gcc/config/rs6000/rs6000-p8swap.c   2018-04-23 21:12:22.259096174 +0200
@@ -593,8 +593,10 @@ const_load_sequence_p (swap_web_entry *i
 remove this special test.  */
  rtx const_vector = get_pool_constant (base);
  if (GET_CODE (const_vector) == SYMBOL_REF
- && !CONSTANT_POOL_ADDRESS_P (const_vector))
-   return false;
+ && CONSTANT_POOL_ADDRESS_P (const_vector))
+   const_vector = get_pool_constant (const_vector);
+ if (GET_CODE (const_vector) != CONST_VECTOR)
+   return false;
}
}
 }
--- gcc/testsuite/g++.dg/ext/pr85503.C.jj   2018-04-23 21:22:54.291572309 
+0200
+++ gcc/testsuite/g++.dg/ext/pr85503.C  2018-04-23 21:22:34.049557064 +0200
@@ -0,0 +1,218 @@
+// PR target/85503
+// { dg-do compile { target { { powerpc64le-*-* } && c++11 } } }
+// { dg-require-effective-target powerpc_vsx_ok }
+// { dg-options "-O2 -mvsx" }
+
+namespace b {
+template < int c > struct d { static constexpr int e = c; };
+typedef d< false > f;
+template < typename g > struct h { typedef g i; };
+template < typename > class j;
+template < bool, bool, typename... > struct aa;
+struct k {
+  template < typename n, typename... q >
+  static h< decltype(n()(q()...)) > o(int);
+};
+template < typename p, typename... t > struct aa< false, false, p, t... > : k {
+  typedef decltype(o< p, t... >(0)) i;
+};
+template < typename p, typename... t >
+struct ab : aa< f::e, f::e, p, t... >::i {};
+template < typename p, typename... t > struct j< p(t...) > : ab< p, t... > {};
+} enum { r, s };
+typedef long x;
+template < typename > struct ac;
+template < typename y > struct ac< y & > { typedef y i; };
+template < typename y > struct j { typedef typename b::j< y >::i i; };
+template < typename > struct ad;
+template < typename > struct ae;
+template < typename > class af;
+template < typename, int ag, int ah, int = 0, int = ag, int = ah > class ai;
+template < typename > class aj;
+template < typename, typename, typename > class ak;
+template < typename > class al;
+template < typename > struct am;
+template < typename > struct an;
+template < typename y > struct ao { typedef typename am< y >::i i; };
+struct aq {
+  typedef const ai< double, 2, 1 > &ar;
+};
+template < typename as > struct at { typedef aj< as > i; };
+template < typename as > struct au { typedef typename at< as >::i i; };
+template < typename av > av aw(const typename an< av >::i *);
+template < typename av, int > av az(const typename an< av >::i *ba) {
+  return aw< av >(ba);
+}
+typedef __attribute__((altivec(vector__))) double bb;
+template <> struct am< double > { typedef bb i; };
+template <> struct an< bb > { typedef double i; };
+template <> bb aw(const double *ba) { return __builtin_vec_vsx_ld(0, ba); }
+struct bc {
+  template < typename av > int bd(av a) { bd(a); __builtin_unreachable (); }
+};
+struct be {
+  double operator()(const int, const int);
+};
+template < typename as > class bf : public ae< as > {
+public:
+  typedef typename ad< as >::bg bg;
+  using ae< as >::bh;
+  enum { bi };
+  bg bj() const;
+  template < typename bk > bg bl(const bk &) const;
+};
+template < typename as > class aj : public bf< as > {
+public:
+  using bf< as >::bh;
+  template < typename bm > ak< be, const as, const bm > operator-(bm bn) {
+return ak< be, const as, const bm >(bh(), bn);
+  }
+  int bo() const;
+  al< as > array() { return bh(); }
+};
+template < typename as > struct ae {
+  const as &bh() const { return *static_cast< const as * >(this); }
+};
+template < typename > struct bp;
+template < typename > struct bq;
+template < typename y > struct br : bq< y > {
+  br(y bs) : bq< y >(bs) {}
+};
+template < typename y > struct br< const y > : br< y > {
+  br(const y &bs) : br< y >(bs) {}
+};
+template < typename as > struct br< af< as > > {
+  typedef as bt;
+  br(const bt &m) : bu(m.bv()) {}
+  template < int bw, typename ay > ay bx(x, x by) {
+return az< ay, bw >(bu + by);
+  }
+  const typename bt::bg *bu;
+};
+template < typename bg, int u, int bz, int ca, int cb, int cc >
+struct br< ai< bg, u, bz, ca, cb, cc > > : br< af< ai< bg, u, bz > > > {

[Committed] Fix PR85478

[Andreas Krebbel]

Bootstrapped and regression tested on x86_64, ppc64, and s390x.

Pre-approved by Richard in the PR.

-Andreas-

gcc/ChangeLog:

2018-04-24  Andreas Krebbel  

PR tree-optimization/85478
* tree-vect-loop.c (vect_analyze_loop_2): Do not call
vect_grouped_store_supported for single element vectors.

gcc/testsuite/ChangeLog:

2018-04-24  Andreas Krebbel  

PR tree-optimization/85478
* g++.dg/pr85478.C: New test.
---
 gcc/testsuite/g++.dg/pr85478.C | 46 ++
 gcc/tree-vect-loop.c   |  5 +++--
 2 files changed, 49 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/pr85478.C

diff --git a/gcc/testsuite/g++.dg/pr85478.C b/gcc/testsuite/g++.dg/pr85478.C
new file mode 100644
index 000..4eb4f24
--- /dev/null
+++ b/gcc/testsuite/g++.dg/pr85478.C
@@ -0,0 +1,46 @@
+/* { dg-do compile { target { s390*-*-* } } } */
+/* { dg-options "-O3 -march=arch12 -std=c++11 -Wno-return-type" } */
+
+struct a {
+  enum { b };
+};
+struct c {
+  template  static void f(d g, e h) {
+d i;
+for (; i != g; ++h, ++i)
+  *h = *i;
+  }
+};
+template  void j(d g, e h) { c::f(g, h); }
+template  void l(d g, e h) { j(g, h); }
+template  void aa(d g, e h) { l(g, h); }
+template  class ab;
+template <> struct ab {
+  _Complex m() { return n; }
+  _Complex n;
+};
+template <> struct ab {
+  ab(ab g) : n(g.m()) {}
+  _Complex long double n;
+};
+template  class p {
+public:
+  template  p &operator=(const p &);
+  o *ad;
+};
+template  class r : public p<2, o> {};
+template 
+template 
+p &p::operator=(const p &g) {
+  aa(&g.ad[0], &ad[0]);
+}
+template  class s : public r {
+  template  s &operator=(const s &);
+};
+template 
+template 
+s &s::operator=(const s &g) {
+  p<2, ae>::operator=(g);
+}
+template s> &s>::
+operator=(const s> &);
diff --git a/gcc/tree-vect-loop.c b/gcc/tree-vect-loop.c
index 7b3009a..4ce721ed 100644
--- a/gcc/tree-vect-loop.c
+++ b/gcc/tree-vect-loop.c
@@ -2492,8 +2492,9 @@ again:
   unsigned int size = STMT_VINFO_GROUP_SIZE (vinfo);
   tree vectype = STMT_VINFO_VECTYPE (vinfo);
   if (! vect_store_lanes_supported (vectype, size, false)
- && ! vect_grouped_store_supported (vectype, size))
-   return false;
+&& ! known_eq (TYPE_VECTOR_SUBPARTS (vectype), 1U)
+&& ! vect_grouped_store_supported (vectype, size))
+   return false;
   FOR_EACH_VEC_ELT (SLP_INSTANCE_LOADS (instance), j, node)
{
  vinfo = vinfo_for_stmt (SLP_TREE_SCALAR_STMTS (node)[0]);
-- 
2.9.1

Re: [PATCH 0/2] Require that constraints are used to reference global regs

[Michael Matz]

Hi,

On Tue, 24 Apr 2018, Alexander Monakov wrote:

> On Mon, 23 Apr 2018, Michael Matz wrote:
> > Sooo, hmm, I don't know ;-)  We could try doing a roll backwards and 
> > demand explicit dependencies from asms with unknown effects on the few 
> > unknown users, though the timing really makes me nervous.  But my gut 
> > feeling says to remain (or become again) very conservative with global reg 
> > vars (and document that for real then!).
> 
> What's the problem with the timing? The code change is proposed for stage 1,
> only the doc change is intended for gcc-8.1.

Sure but even for that we need to decide if we want to go that or the 
opposite way, and that's not easy when a deadline is lurking behind you.


Ciao,
Michael.

[PATCH] Fix UB in ix86_expand_vector_init_one_var (PR target/85508)

[Jakub Jelinek]

Hi!

WHen INTVAL (x) is negative, this invokes UB, because left shift of negative
value is undefined in C++.

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

2018-04-24  Jakub Jelinek  

PR target/85508
* config/i386/i386.c (ix86_expand_vector_init_one_var): Use UINTVAL
instead of INTVAL when shifting x left.

* gcc.target/i386/pr85508.c: New test.

--- gcc/config/i386/i386.c.jj   2018-04-24 10:37:01.258882134 +0200
+++ gcc/config/i386/i386.c  2018-04-24 11:37:29.002706293 +0200
@@ -43200,7 +43200,7 @@ ix86_expand_vector_init_one_var (bool mm
   else
{
  var = convert_modes (HImode, QImode, var, true);
- x = gen_int_mode (INTVAL (x) << 8, HImode);
+ x = gen_int_mode (UINTVAL (x) << 8, HImode);
}
   if (x != const0_rtx)
var = expand_simple_binop (HImode, IOR, var, x, var,
--- gcc/testsuite/gcc.target/i386/pr85508.c.jj  2018-04-24 11:37:48.890721003 
+0200
+++ gcc/testsuite/gcc.target/i386/pr85508.c 2018-04-24 11:32:40.598491856 
+0200
@@ -0,0 +1,12 @@
+/* PR target/85508 */
+/* { dg-do compile } */
+/* { dg-options "-O2 -msse2" } */
+
+typedef signed char V __attribute__((vector_size (16)));
+signed char c;
+
+V
+foo (void)
+{
+  return (V) { c, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1 };
+}

Jakub

Re: [PATCH 0/2] Require that constraints are used to reference global regs

[Alexander Monakov]

On Tue, 24 Apr 2018, Michael Matz wrote:
> Sure but even for that we need to decide if we want to go that or the 
> opposite way, and that's not easy when a deadline is lurking behind you.

I am surprised there is any question. Even gcc-3.4 optimizes reg vars over asms,
on a testcase not unlike the very one you've used I see:

register int foo asm("ebx");

void g(void);

void f(void)
{
foo=0;
asm("foo=1");
if (foo) g();
}

.globl f
.type   f, @function
f:
.LFB2:
xorl%ebx, %ebx
#APP
foo=1
#NO_APP
ret


(here GCSE makes the propagation)

Besides, I don't really understand the objection about changing the docs for
gcc-8.1. Even if there's a doubt about future development, improving the
documentation to explain the behavior of a released compiler should be good.
Right now the docs are simply wrong.

Alexander

Re: [PATCH] Fix UB in ix86_expand_vector_init_one_var (PR target/85508)

[Richard Biener]

On Tue, Apr 24, 2018 at 2:53 PM, Jakub Jelinek  wrote:
> Hi!
>
> WHen INTVAL (x) is negative, this invokes UB, because left shift of negative
> value is undefined in C++.
>
> Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
> trunk?

OK.

Richard.

> 2018-04-24  Jakub Jelinek  
>
> PR target/85508
> * config/i386/i386.c (ix86_expand_vector_init_one_var): Use UINTVAL
> instead of INTVAL when shifting x left.
>
> * gcc.target/i386/pr85508.c: New test.
>
> --- gcc/config/i386/i386.c.jj   2018-04-24 10:37:01.258882134 +0200
> +++ gcc/config/i386/i386.c  2018-04-24 11:37:29.002706293 +0200
> @@ -43200,7 +43200,7 @@ ix86_expand_vector_init_one_var (bool mm
>else
> {
>   var = convert_modes (HImode, QImode, var, true);
> - x = gen_int_mode (INTVAL (x) << 8, HImode);
> + x = gen_int_mode (UINTVAL (x) << 8, HImode);
> }
>if (x != const0_rtx)
> var = expand_simple_binop (HImode, IOR, var, x, var,
> --- gcc/testsuite/gcc.target/i386/pr85508.c.jj  2018-04-24 11:37:48.890721003 
> +0200
> +++ gcc/testsuite/gcc.target/i386/pr85508.c 2018-04-24 11:32:40.598491856 
> +0200
> @@ -0,0 +1,12 @@
> +/* PR target/85508 */
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -msse2" } */
> +
> +typedef signed char V __attribute__((vector_size (16)));
> +signed char c;
> +
> +V
> +foo (void)
> +{
> +  return (V) { c, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1 
> };
> +}
>
> Jakub

Re: [PATCH 0/2] Require that constraints are used to reference global regs

[Michael Matz]

Hi,

On Tue, 24 Apr 2018, Alexander Monakov wrote:

> > Sure but even for that we need to decide if we want to go that or the 
> > opposite way, and that's not easy when a deadline is lurking behind 
> > you.
> 
> I am surprised there is any question. Even gcc-3.4 optimizes reg vars 
> over asms, on a testcase not unlike the very one you've used I see:

Thanks for checking.  Seems all the code that was supposed to care for 
enabling this was always incomplete since a long time, which certainly 
speaks for going the explicit dependency way.

> Besides, I don't really understand the objection about changing the docs 
> for gcc-8.1. Even if there's a doubt about future development, improving 
> the documentation to explain the behavior of a released compiler should 
> be good. Right now the docs are simply wrong.

Well, documentation is both: a description and specification.  If we 
change the documentation now we might not be in the position anymore to 
change behaviour and docu back because people might in the meanwhile rely 
on the specification.  Which is why documentation changes that promise a 
certain behaviour are exactly the ones that shouldn't be rushed (even less 
than actual implementation changes).

But in the meantime you seem to have established that everyone thinking 
that asms ever had implicit dependencies on global reg vars was merely 
wishful.  I retract my objection to the documentation change (i.e. the 
specification of non implicit dependencies).  Thanks for persisting :)


Ciao,
Michael.

Re: [PATCH] Fix PR85491

[Jakub Jelinek]

On Tue, Apr 24, 2018 at 09:42:03AM +0200, Richard Biener wrote:
> 
> The following patch restricts the previous fix for PR84037 to the case
> of strided loads with non-constant step to avoid regression nbench
> LU decomposition test on Haswell where the change causes us to use
> AVX128 instead of AVX256 in the two critical loops.
> 
> Bootstrapped and tested on x86_64-unknown-linux-gnu.  SPEC CPU 2006
> results are in the noise, so is SPEC CPU 2000 (200.sixtrack seems
> to be awfully jumpy for me - it goes up and down by almost 50%!),
> nbench LU factorization performance is back up.
> 
> OK for trunk?
> 
> Thanks,
> Richard.
> 
> 2018-04-24  Richard Biener  
> 
>   PR target/85491
>   * config/i386/i386.c (ix86_add_stmt_cost): Restrict strided
>   load cost increase to the case of non-constant step.

LGTM.

> --- gcc/config/i386/i386.c(revision 259556)
> +++ gcc/config/i386/i386.c(working copy)
> @@ -50550,8 +50550,9 @@ ix86_add_stmt_cost (void *data, int coun
>   construction cost by the number of elements involved.  */
>if (kind == vec_construct
>&& stmt_info
> -  && stmt_info->type == load_vec_info_type
> -  && stmt_info->memory_access_type == VMAT_ELEMENTWISE)
> +  && STMT_VINFO_TYPE (stmt_info) == load_vec_info_type
> +  && STMT_VINFO_MEMORY_ACCESS_TYPE (stmt_info) == VMAT_ELEMENTWISE
> +  && TREE_CODE (DR_STEP (STMT_VINFO_DATA_REF (stmt_info))) != 
> INTEGER_CST)
>  {
>stmt_cost = ix86_builtin_vectorization_cost (kind, vectype, misalign);
>stmt_cost *= TYPE_VECTOR_SUBPARTS (vectype);

Jakub

Re: RFC: C++ PATCH for c++/69763, making C++ alignof match C _Alignof

[Jakub Jelinek]

On Mon, Apr 23, 2018 at 04:49:24PM -0400, Jason Merrill wrote:
> On Tue, Apr 17, 2018 at 8:50 AM, Joseph Myers  wrote:
> > On Tue, 10 Apr 2018, Jason Merrill wrote:
> >
> >> But really this is beside the point: the x86 ABI says that the
> >> alignment of double is 4, so alignof(double) should be 4 regardless of
> >> what GCC wants to do internally.  And I think the same is true of
> >> __alignof__.
> >
> > __alignof__ needs to stay reflecting the preferred, standalone alignment
> > of 8 bytes; changing that is ABI-incompatible; code such as that in
> > stddef.h uses __attribute__((__aligned__(__alignof__(long long to give
> > structure members the same alignment those types would have for standalone
> > objects.  (This doesn't affect the alignment of max_align_t *now* on i386,
> > but only because that now includes __float128 as well.)
> 
> In that case, here's a patch following the 52023 change to the C front
> end, to change only "alignof".
> 
> Tested x86_64-pc-linux-gnu, applying to trunk.

This regressed:
+FAIL: c-c++-common/attr-aligned-1.c  -std=c++11 (test for excess errors)
+UNRESOLVED: c-c++-common/attr-aligned-1.c  -std=c++11 compilation failed to 
produce executable
+FAIL: c-c++-common/attr-aligned-1.c  -std=c++14 (test for excess errors)
+UNRESOLVED: c-c++-common/attr-aligned-1.c  -std=c++14 compilation failed to 
produce executable
+FAIL: g++.dg/cpp0x/alignas4.C  -std=c++11  scan-assembler align 8
+FAIL: g++.dg/cpp0x/alignas4.C  -std=c++14  scan-assembler align 8
on i686-linux, can be reproduced even with just
make check-gcc check-g++ RUNTESTFLAGS="--target_board=unix\{-m64,-m32\} 
dg.exp='attr-aligned-1.c alignas4.C'"
on x86_64-linux.

On alignas4.C, this was changed with r249409, perhaps we can limit
the target to && { ! ia32 } or similar, or do we want to expect align 4
for ia32?

attr-aligned-1.c testcase doesn't work if
__alignof__ (double) != alignof (double).  Either we should use __alignof__
in the static_asserts, or guard the static_asserts for targets known not to
have different results between the two.

> commit c42f365685b86fa7cecc2666adf93037f7bd0289
> Author: Jason Merrill 
> Date:   Tue Apr 10 11:48:51 2018 -0400
> 
> PR c++/69560 - wrong alignof(double) on x86.
> 
> CWG 1879 - Inadequate definition of alignment requirement.
> * cp-tree.h (ALIGNOF_EXPR_STD_P): New.
> * typeck.c (cxx_sizeof_or_alignof_type): Add std_alignof parm.
> (cxx_sizeof_expr, cxx_sizeof_nowarn, cxx_alignas_expr)
> (cxx_alignof_expr): Pass it.
> * parser.c (cp_parser_unary_expression): Pass it.
> * pt.c (tsubst_copy): Copy it.
> (tsubst_copy_and_build): Pass it.
> * decl.c (fold_sizeof_expr): Pass it.

Jakub

[PATCH, rs6000] Improve Documentation of Built-In Functions Part 1

[Kelvin Nilsen]

This is the first of several patches to address shortcomings in existing
documentation of
PowerPC built-in functions.  The focus of this particular patch is to
improve documentation
of low-level built-in functions that do not require special include headers.

A summary of this patch follows:

1. Change the name of the first PowerPC built-in section from "PowerPC
Built-in Functions"
   to "Low-Level PowerPC Built-in Functions".  This section has never
described all PowerPC
   built-in functions.

2. Introduce subsubsections within this section to independently
describe built-in functions
   that target particular ISA levels.  Sort function descriptions into
appropriate
   subsubsections.

3. Add descriptions of three new features that can be tested with the
__builtin_cpu_supports
   function: darn, htm-no-suspend, and scv.

4. Remove descriptions of built-in function that do not belong in this
section because the
   built-in functions are generic (not specific to PowerPC):
__builtin_fabsq,
   __builtin_copysignq, __builtin_infq, __builtin_huge_valq, __builtin_nanq,
   __builtin_nansq, __builtin_sqrtf128, __builtin_fmaf128.

5. Corrected the spellings of several built-in functions:
__builtin_fmaf128_round_to_odd,
   __builtin_addg6s, __builtin_cbctdt, __builtin_cdtbcd.

This patch is limited in scope in order to manage complexity of the
diffs.  Subsequent patches
will address different sections of the documentation.  Subsequent
patches will also add
new function descriptions into these sections.

This patch affects only extend.texi.  The gcc.pdf file has been built
and reviewed.

Is this ok for the trunk?

gcc/ChangeLog:

2018-04-24  Kelvin Nilsen  

    * doc/extend.texi: Tidy documentation of PowerPC built-in functions.

Index: gcc/doc/extend.texi
===
--- gcc/doc/extend.texi    (revision 259504)
+++ gcc/doc/extend.texi    (working copy)
@@ -15524,12 +15524,17 @@ implementing assertions.
 
 @end table
 
-@node PowerPC Built-in Functions
-@subsection PowerPC Built-in Functions
+@node Low-Level PowerPC Built-in Functions
+@subsection Low-Level PowerPC Built-in Functions
 
-The following built-in functions are always available and can be used to
-check the PowerPC target platform type:
+This section describes PowerPC built-in functions that do not require
+the inclusion of any special header files to declare prototypes or
+provide macro definitions.  The sections that follow describe
+additional PowerPC built-in functions.
 
+@node Low-Level PowerPC Built-in Functions Available on all Targets
+@subsubsection Low-Level PowerPC Built-in Functions Available on all
Targets
+
 @deftypefn {Built-in Function} void __builtin_cpu_init (void)
 This function is a @code{nop} on the PowerPC platform and is included
solely
 to maintain API compatibility with the x86 builtins.
@@ -15633,6 +15638,8 @@ CPU supports the set of compatible performance mon
 CPU supports the Embedded ISA category.
 @item cellbe
 CPU has a CELL broadband engine.
+@item darn
+CPU supports the darn (deliver a random number) instruction.
 @item dfp
 CPU has a decimal floating point unit.
 @item dscr
@@ -15649,6 +15656,8 @@ CPU has a floating point unit.
 CPU has hardware transaction memory instructions.
 @item htm-nosc
 Kernel aborts hardware transactions when a syscall is made.
+@item htm-no-suspend
+Kernel aborts hardware transactions when the thread is suspended.
 @item ic_snoop
 CPU supports icache snooping capabilities.
 @item ieee128
@@ -15677,6 +15686,8 @@ CPU supports the old POWER ISA (eg, 601)
 CPU supports 64-bit mode execution.
 @item ppcle
 CPU supports a little-endian mode that uses address swizzling.
+@item scv
+Kernel supports system call vectored.
 @item smt
 CPU support simultaneous multi-threading.
 @item spe
@@ -15708,19 +15719,81 @@ Here is an example:
 @end smallexample
 @end deftypefn
 
-These built-in functions are available for the PowerPC family of
+The following built-in functions are also available on all PowerPC
 processors:
 @smallexample
-float __builtin_recipdivf (float, float);
-float __builtin_rsqrtf (float);
-double __builtin_recipdiv (double, double);
-double __builtin_rsqrt (double);
 uint64_t __builtin_ppc_get_timebase ();
 unsigned long __builtin_ppc_mftb ();
-double __builtin_unpack_longdouble (long double, int);
-long double __builtin_pack_longdouble (double, double);
 @end smallexample
 
+The @code{__builtin_ppc_get_timebase} and @code{__builtin_ppc_mftb}
+functions generate instructions to read the Time Base Register.  The
+@code{__builtin_ppc_get_timebase} function may generate multiple
+instructions and always returns the 64 bits of the Time Base Register.
+The @code{__builtin_ppc_mftb} function always generates one instruction and
+returns the Time Base Register value as an unsigned long, throwing away
+the most significant word on 32-bit environments.
+
+@node Low-Level PowerPC Built-in Functions Available on ISA 2.05
+@subsubsection Low-Level

Re: [PATCH AArch64]Fix test failure for pr84682-2.c

[Bin.Cheng]

On Thu, Mar 22, 2018 at 11:07 AM, Bin.Cheng  wrote:
> On Sat, Mar 17, 2018 at 8:54 AM, Richard Sandiford
>  wrote:
>> Kyrill  Tkachov  writes:
>>> Hi Bin,
>>>
>>> On 16/03/18 11:42, Bin Cheng wrote:
 Hi,
 This simple patch fixes test case failure for pr84682-2.c by returning
 false on wrong mode rtx in aarch64_classify_address, rather than assert.

 Bootstrap and test on aarch64.  Is it OK?

 Thanks,
 bin

 2018-03-16  Bin Cheng  

 * config/aarch64/aarch64.c (aarch64_classify_address): Return false
 on wrong mode rtx, rather than assert.
>>>
>>> This looks ok to me in light of
>>> https://gcc.gnu.org/ml/gcc-patches/2018-03/msg00633.html
>>> This function is used to validate inline asm operands too, not just
>>> internally-generated addresses.
>>> Therefore all kinds of garbage must be rejected gracefully rather than 
>>> ICEing.
>>>
>>> You'll need an approval from an AArch64 maintainer though.
>>
>> IMO we should make address_operand itself check something like:
>>
>>   (GET_MODE (x) == VOIDmode || SCALAR_INT_MODE_P (GET_MODE (x)))
>>
>> Target-independent code fundamentally assumes that an address will not
>> be a float, so I think the check should be in target-independent code
>> rather than copied to each individual backend.
>>
>> This was only caught on aarch64 because we added the assert, but I think
>> some backends ignore the mode of the address and so would actually accept
>> simple float rtxes.
> Hi Richard,
> Thanks for the suggestion generalizing the fix.  Here is the updated patch.
> Bootstrap and test on x86_64 and AArch64, is it OK?

Ping.

Better to have this ICE fix in GCC8?  But I guess RTL review/approval is needed.

Thanks,
bin
>
> Thanks,
> bin
>
> 2018-03-22  Bin Cheng  
>
> * recog.c (address_operand): Return false on wrong mode for address.
> * config/aarch64/aarch64.c (aarch64_classify_address): Remove assert
> since it's checked in general code now.
>
>>
>> Thanks,
>> Richard

Re: GCC 7 backports

[Martin Liška]

Hi.

I'm sending GCC 7 branch backports I've just tested and regbootstrapped.
I'm going to install that.

Thanks,
Martin
>From 3f14f2b8c441f2919a026bd86a5419f4fbdf33f5 Mon Sep 17 00:00:00 2001
From: marxin 
Date: Tue, 13 Mar 2018 08:20:27 +
Subject: [PATCH 1/9] Backport r258480

gcc/ChangeLog:

2018-03-13  Martin Liska  

	PR ipa/84658.
	* (sem_item_optimizer::sem_item_optimizer): Initialize new
	vector.
	(sem_item_optimizer::~sem_item_optimizer): Release it.
	(sem_item_optimizer::merge_classes): Register variable aliases.
	(sem_item_optimizer::fixup_pt_set): New function.
	(sem_item_optimizer::fixup_points_to_sets): Likewise.
	* ipa-icf.h: Declare new variables and functions.

gcc/testsuite/ChangeLog:

2018-03-13  Martin Liska  

	PR ipa/84658.
	* g++.dg/ipa/pr84658.C: New test.
---
 gcc/ipa-icf.c  | 112 ++---
 gcc/ipa-icf.h  |  12 
 gcc/testsuite/g++.dg/ipa/pr84658.C |  30 ++
 3 files changed, 134 insertions(+), 20 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/ipa/pr84658.C

diff --git a/gcc/ipa-icf.c b/gcc/ipa-icf.c
index 95fad30e83a..9ceee20b652 100644
--- a/gcc/ipa-icf.c
+++ b/gcc/ipa-icf.c
@@ -2132,23 +2132,6 @@ sem_variable::get_hash (void)
   return m_hash;
 }
 
-/* Set all points-to UIDs of aliases pointing to node N as UID.  */
-
-static void
-set_alias_uids (symtab_node *n, int uid)
-{
-  ipa_ref *ref;
-  FOR_EACH_ALIAS (n, ref)
-{
-  if (dump_file)
-	fprintf (dump_file, "  Setting points-to UID of [%s] as %d\n",
-		 xstrdup_for_dump (ref->referring->asm_name ()), uid);
-
-  SET_DECL_PT_UID (ref->referring->decl, uid);
-  set_alias_uids (ref->referring, uid);
-}
-}
-
 /* Merges instance with an ALIAS_ITEM, where alias, thunk or redirection can
be applied.  */
 
@@ -2275,7 +2258,6 @@ sem_variable::merge (sem_item *alias_item)
   if (dump_file)
 	fprintf (dump_file, "Unified; Variable alias has been created.\n");
 
-  set_alias_uids (original, DECL_UID (original->decl));
   return true;
 }
 }
@@ -2295,7 +2277,7 @@ unsigned int sem_item_optimizer::class_id = 0;
 
 sem_item_optimizer::sem_item_optimizer ()
 : worklist (0), m_classes (0), m_classes_count (0), m_cgraph_node_hooks (NULL),
-  m_varpool_node_hooks (NULL)
+  m_varpool_node_hooks (NULL), m_merged_variables ()
 {
   m_items.create (0);
   bitmap_obstack_initialize (&m_bmstack);
@@ -2320,6 +2302,7 @@ sem_item_optimizer::~sem_item_optimizer ()
   m_items.release ();
 
   bitmap_obstack_release (&m_bmstack);
+  m_merged_variables.release ();
 }
 
 /* Write IPA ICF summary for symbols.  */
@@ -3571,13 +3554,102 @@ sem_item_optimizer::merge_classes (unsigned int prev_class_count)
 	  }
 
 	if (dbg_cnt (merged_ipa_icf))
-	  merged_p |= source->merge (alias);
+	  {
+		bool merged = source->merge (alias);
+		merged_p |= merged;
+
+		if (merged && alias->type == VAR)
+		  {
+		symtab_pair p = symtab_pair (source->node, alias->node);
+		m_merged_variables.safe_push (p);
+		  }
+	  }
 	  }
   }
 
+  if (!m_merged_variables.is_empty ())
+fixup_points_to_sets ();
+
   return merged_p;
 }
 
+/* Fixup points to set PT.  */
+
+void
+sem_item_optimizer::fixup_pt_set (struct pt_solution *pt)
+{
+  if (pt->vars == NULL)
+return;
+
+  unsigned i;
+  symtab_pair *item;
+  FOR_EACH_VEC_ELT (m_merged_variables, i, item)
+if (bitmap_bit_p (pt->vars, DECL_UID (item->second->decl)))
+  bitmap_set_bit (pt->vars, DECL_UID (item->first->decl));
+}
+
+/* Set all points-to UIDs of aliases pointing to node N as UID.  */
+
+static void
+set_alias_uids (symtab_node *n, int uid)
+{
+  ipa_ref *ref;
+  FOR_EACH_ALIAS (n, ref)
+{
+  if (dump_file)
+	fprintf (dump_file, "  Setting points-to UID of [%s] as %d\n",
+		 xstrdup_for_dump (ref->referring->asm_name ()), uid);
+
+  SET_DECL_PT_UID (ref->referring->decl, uid);
+  set_alias_uids (ref->referring, uid);
+}
+}
+
+/* Fixup points to analysis info.  */
+
+void
+sem_item_optimizer::fixup_points_to_sets (void)
+{
+  /* TODO: remove in GCC 9 and trigger PTA re-creation after IPA passes.  */
+
+  cgraph_node *cnode;
+  return;
+
+  FOR_EACH_DEFINED_FUNCTION (cnode)
+{
+  tree name;
+  unsigned i;
+  function *fn = DECL_STRUCT_FUNCTION (cnode->decl);
+  FOR_EACH_SSA_NAME (i, name, fn)
+	if (POINTER_TYPE_P (TREE_TYPE (name))
+	&& SSA_NAME_PTR_INFO (name))
+	  fixup_pt_set (&SSA_NAME_PTR_INFO (name)->pt);
+  fixup_pt_set (&fn->gimple_df->escaped);
+
+   /* The above get's us to 99% I guess, at least catching the
+	  address compares.  Below also gets us aliasing correct
+	  but as said we're giving leeway to the situation with
+	  readonly vars anyway, so ... */
+   basic_block bb;
+   FOR_EACH_BB_FN (bb, fn)
+	for (gimple_stmt_iterator gsi = gsi_start_bb (bb); !gsi_end_p (gsi);
+	 gsi_next (&gsi))
+	  {
+	gcall *call = dyn_cast (gsi_stmt (gsi));
+	if (call)
+	  {
+		fixup_pt_s

Re: [PATCH 0/2] Require that constraints are used to reference global regs

[Alexander Monakov]

On Tue, 24 Apr 2018, Michael Matz wrote:
> Well, documentation is both: a description and specification.  If we 
> change the documentation now we might not be in the position anymore to 
> change behaviour and docu back because people might in the meanwhile rely 
> on the specification.  Which is why documentation changes that promise a 
> certain behaviour are exactly the ones that shouldn't be rushed (even less 
> than actual implementation changes).

My patch isn't making any promises; in a nutshell, it says "must use
constraints", which is the most tight specification and doesn't open
any new doors (in contrast with the position that you were arguing,
which would be a new promise).

Did the other changes in patch 1 look fine to you, content-wise?

Thanks.
Alexander

[PATCH][AArch64] PR target/85512: Tighten SIMD right shift immediate constraints

[Kyrill Tkachov]

Hi all,

In this testcase it is possible to generate an invalid SISD shift of zero:
Error: immediate value out of range 1 to 64 at operand 3 -- `sshr v9.2s,v0.2s,0'

The SSHR and USHR instructions require a shift from 1 up to the element size.
However our constraints on the scalar shifts that generate these patterns
allow a shift amount of zero as well. The pure GP-reg ASR and LSR instructions 
allow a shift amount of zero.

It is unlikely that a shift of zero will survive till the end of compilation, 
but it's not impossible, as this PR shows.

The patch tightens up the constraints in the offending patterns by adding two 
new constraints
that allow shift amounts [1,32] and [1,64] and using them in 
*aarch64_ashr_sisd_or_int_3
and *aarch64_lshr_sisd_or_int_3.
The left-shift SISD instructions SHL and USHL allow a shift amount of zero so 
don't need adjustment
The vector shift patterns that map down to SSHR and USHR already enforce the 
correct immediate range.

Bootstrapped and tested on aarch64-none-linux-gnu.
Ok for trunk?

The issue is latent on the branches so I would like to backport there after 
some time on trunk.

Thanks,
Kyrill

2018-04-24  Kyrylo Tkachov  

PR target/85512
* config/aarch64/constraints.md (Usg, Usj): New constraints.
* config/aarch64/iterators.md (cmode_simd): New mode attribute.
* config/aarch64/aarch64.md (*aarch64_ashr_sisd_or_int_3):
Use the above on operand 2.  Reindent.
(*aarch64_lshr_sisd_or_int_3): Likewise.

2018-04-24  Kyrylo Tkachov  

PR target/85512
* gcc.dg/pr85512.c: New test.
commit d8890f8682517336648b6c780087e131a8943f09
Author: Kyrylo Tkachov 
Date:   Tue Apr 24 13:51:19 2018 +0100

[AArch64] PR target/85512

diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
index 4924168..953edb7 100644
--- a/gcc/config/aarch64/aarch64.md
+++ b/gcc/config/aarch64/aarch64.md
@@ -4403,7 +4403,8 @@ (define_insn "*aarch64_lshr_sisd_or_int_3"
   [(set (match_operand:GPI 0 "register_operand" "=r,r,w,&w,&w")
 	(lshiftrt:GPI
 	 (match_operand:GPI 1 "register_operand" "r,r,w,w,w")
-	 (match_operand:QI 2 "aarch64_reg_or_shift_imm_" "Us,r,Us,w,0")))]
+	 (match_operand:QI 2 "aarch64_reg_or_shift_imm_"
+			  "Us,r,Us,w,0")))]
   ""
   "@
lsr\t%0, %1, %2
@@ -4448,9 +4449,10 @@ (define_split
 ;; Arithmetic right shift using SISD or Integer instruction
 (define_insn "*aarch64_ashr_sisd_or_int_3"
   [(set (match_operand:GPI 0 "register_operand" "=r,r,w,&w,&w")
-(ashiftrt:GPI
-  (match_operand:GPI 1 "register_operand" "r,r,w,w,w")
-  (match_operand:QI 2 "aarch64_reg_or_shift_imm_di" "Us,r,Us,w,0")))]
+	(ashiftrt:GPI
+	  (match_operand:GPI 1 "register_operand" "r,r,w,w,w")
+	  (match_operand:QI 2 "aarch64_reg_or_shift_imm_di"
+			   "Us,r,Us,w,0")))]
   ""
   "@
asr\t%0, %1, %2
diff --git a/gcc/config/aarch64/constraints.md b/gcc/config/aarch64/constraints.md
index f052103..b5da997 100644
--- a/gcc/config/aarch64/constraints.md
+++ b/gcc/config/aarch64/constraints.md
@@ -153,6 +153,20 @@ (define_constraint "Usf"
(match_test "!(aarch64_is_noplt_call_p (op)
 		  || aarch64_is_long_call_p (op))")))
 
+(define_constraint "Usg"
+  "@internal
+  A constraint that matches an immediate right shift constant in SImode
+  suitable for a SISD instruction."
+  (and (match_code "const_int")
+   (match_test "IN_RANGE (ival, 1, 32)")))
+
+(define_constraint "Usj"
+  "@internal
+  A constraint that matches an immediate right shift constant in DImode
+  suitable for a SISD instruction."
+  (and (match_code "const_int")
+   (match_test "IN_RANGE (ival, 1, 64)")))
+
 (define_constraint "UsM"
   "@internal
   A constraint that matches the immediate constant -1."
diff --git a/gcc/config/aarch64/iterators.md b/gcc/config/aarch64/iterators.md
index 33933ec..bd97408 100644
--- a/gcc/config/aarch64/iterators.md
+++ b/gcc/config/aarch64/iterators.md
@@ -589,6 +589,9 @@ (define_mode_attr lconst2 [(SI "UsO") (DI "UsP")])
 ;; Map a mode to a specific constraint character.
 (define_mode_attr cmode [(QI "q") (HI "h") (SI "s") (DI "d")])
 
+;; Map modes to Usg and Usj constraints for SISD right shifts
+(define_mode_attr cmode_simd [(SI "g") (DI "j")])
+
 (define_mode_attr Vtype [(V8QI "8b") (V16QI "16b")
 			 (V4HI "4h") (V8HI  "8h")
  (V2SI "2s") (V4SI  "4s")
diff --git a/gcc/testsuite/gcc.dg/pr85512.c b/gcc/testsuite/gcc.dg/pr85512.c
new file mode 100644
index 000..ce3cdb0
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr85512.c
@@ -0,0 +1,118 @@
+/* { dg-do assemble } */
+/* { dg-options "-O -fno-if-conversion" } */
+
+typedef unsigned char u8;
+typedef unsigned short u16;
+typedef unsigned int u32;
+typedef unsigned long long u64;
+inline u64
+bar0(u8 u8_0, u16 u16_0, u32 u32_0, u64 u64_0, u8 u8_1, u16 u16_1, u32 u32_1, u64 u64_1, u8 u8_2, u16 u16_2, u32 u32_2, u64 u64_2, u8 u8_3, u16 u16_3, u32 u32_3, u64 u64_3);
+static __attribute__((noipa)) u64
+bar1(u8 u8_0, u16 u16_0, u32 u32_0,

Re: [PATCH] Fix powerpc64le ICE in replace_swapped_load_constant (PR target/85503)

[Segher Boessenkool]

Hi Jakub,

On Tue, Apr 24, 2018 at 09:52:29AM +0200, Jakub Jelinek wrote:
> The following patch adjusts the const_load_sequence_p predicate to match
> what the replace_swapped_load_constant function guarded by it expects.
> 
> On the testcase base is a CONSTANT_POOL_ADDRESS_P SYMBOL_REF, but it
> contains an address of a static data member + 8, so not a CONST_VECTOR nor
> a CONSTANT_POOL_ADDRESS_P SYMBOL_REF.

Okay for trunk (and backports where needed).  Thanks!  Some day we should
figure out why we need this hack.  But not today I guess :-)


Segher


> 2018-04-24  Jakub Jelinek  
> 
>   PR target/85503
>   * config/rs6000/rs6000-p8swap.c (const_load_sequence_p): Punt if
>   const_vector is not CONST_VECTOR or SYMBOL_REF for a constant pool
>   containing a CONST_VECTOR.
> 
>   * g++.dg/ext/pr85503.C: New test.

Re: [PATCH 0/2] Require that constraints are used to reference global regs

[Michael Matz]

Hi,

On Tue, 24 Apr 2018, Alexander Monakov wrote:

> On Tue, 24 Apr 2018, Michael Matz wrote:
> > Well, documentation is both: a description and specification.  If we 
> > change the documentation now we might not be in the position anymore to 
> > change behaviour and docu back because people might in the meanwhile rely 
> > on the specification.  Which is why documentation changes that promise a 
> > certain behaviour are exactly the ones that shouldn't be rushed (even less 
> > than actual implementation changes).
> 
> My patch isn't making any promises; in a nutshell, it says "must use
> constraints", which is the most tight specification and doesn't open
> any new doors (in contrast with the position that you were arguing,
> which would be a new promise).
> 
> Did the other changes in patch 1 look fine to you, content-wise?

Let's see again:

-@item The register is reserved entirely for this use, and will not be 
-allocated for any other purpose.
-@item The register is not saved and restored by any functions.
-@item Stores into this register are never deleted even if they appear to be
-dead, but references may be deleted, moved or simplified.
+@item If the register is a call-saved register, call ABI is affected:
+the register will not be restored in function epilogue sequences after
+the variable has been assigned.  Therefore, functions cannot safely
+return to callers that assume standard ABI.
+@item Conversely, if the register is a call-clobbered register, making
+calls to functions that use standard ABI may lose contents of the variable.
+Such calls may be created by the compiler even if none are evident in
+the original program, for example when libgcc functions are used to
+make up for unavailable instructions.
+@item Accesses to the variable may be optimized as usual and the register
+remains available for allocation and use in any computations, provided that
+observable values of the variable are not affected.
+@item If the variable is referenced in inline assembly, the type of access
+must be provided to the compiler via constraints (@pxref{Constraints}).
+Accesses from basic asms are not supported.

What is lost here (it wasn't explicit before, but is the case and must 
continue to work) is that function calls and returns count as needing the 
observable value in the specified register (function calls also count as 
setters of them).  I think that should be made more explicit.  Especially 
because you make it explicit that the register remains available for 
allocation (where it before said it's not) we need to make sure that 
everybody understand that it's only during tiny windows like:

  regvar = ...
  ... code not accessing regvar and containing no calls ...
  regvar = ...

The return of functions also must remain making the regvar setter live, to 
give us the important parts of the former "stores aren't deleted even if 
appearing dead" guarantee.


Ciao,
Michael.

Re: RFC: C++ PATCH for c++/69763, making C++ alignof match C _Alignof

[Jason Merrill]

On Tue, Apr 24, 2018 at 9:19 AM, Jakub Jelinek  wrote:
> On Mon, Apr 23, 2018 at 04:49:24PM -0400, Jason Merrill wrote:
>> On Tue, Apr 17, 2018 at 8:50 AM, Joseph Myers  
>> wrote:
>> > On Tue, 10 Apr 2018, Jason Merrill wrote:
>> >
>> >> But really this is beside the point: the x86 ABI says that the
>> >> alignment of double is 4, so alignof(double) should be 4 regardless of
>> >> what GCC wants to do internally.  And I think the same is true of
>> >> __alignof__.
>> >
>> > __alignof__ needs to stay reflecting the preferred, standalone alignment
>> > of 8 bytes; changing that is ABI-incompatible; code such as that in
>> > stddef.h uses __attribute__((__aligned__(__alignof__(long long to give
>> > structure members the same alignment those types would have for standalone
>> > objects.  (This doesn't affect the alignment of max_align_t *now* on i386,
>> > but only because that now includes __float128 as well.)
>>
>> In that case, here's a patch following the 52023 change to the C front
>> end, to change only "alignof".
>>
>> Tested x86_64-pc-linux-gnu, applying to trunk.
>
> This regressed:
> +FAIL: c-c++-common/attr-aligned-1.c  -std=c++11 (test for excess errors)
> +UNRESOLVED: c-c++-common/attr-aligned-1.c  -std=c++11 compilation failed to 
> produce executable
> +FAIL: c-c++-common/attr-aligned-1.c  -std=c++14 (test for excess errors)
> +UNRESOLVED: c-c++-common/attr-aligned-1.c  -std=c++14 compilation failed to 
> produce executable
> +FAIL: g++.dg/cpp0x/alignas4.C  -std=c++11  scan-assembler align 8
> +FAIL: g++.dg/cpp0x/alignas4.C  -std=c++14  scan-assembler align 8
> on i686-linux, can be reproduced even with just
> make check-gcc check-g++ RUNTESTFLAGS="--target_board=unix\{-m64,-m32\} 
> dg.exp='attr-aligned-1.c alignas4.C'"
> on x86_64-linux.

Thanks.  How is your build tree configured so that this finds the
appropriate runtime libraries?

> On alignas4.C, this was changed with r249409, perhaps we can limit
> the target to && { ! ia32 } or similar, or do we want to expect align 4
> for ia32?
>
> attr-aligned-1.c testcase doesn't work if
> __alignof__ (double) != alignof (double).  Either we should use __alignof__
> in the static_asserts, or guard the static_asserts for targets known not to
> have different results between the two.

Done, thanks.
commit 006eabc3e6328b219f2eee271439cb90f8890856
Author: Jason Merrill 
Date:   Tue Apr 24 11:50:34 2018 -0400

Testsuite fixes for C++11 alignof change.

gcc/testsuite:
* c-c++-common/attr-aligned-1.c: Use __alignof__ in C++11.
* g++.dg/cpp0x/alignas4.C: Expect 4-byte alignment on x86.

diff --git a/gcc/testsuite/c-c++-common/attr-aligned-1.c b/gcc/testsuite/c-c++-common/attr-aligned-1.c
index 671e86baeb6..26b62393ac0 100644
--- a/gcc/testsuite/c-c++-common/attr-aligned-1.c
+++ b/gcc/testsuite/c-c++-common/attr-aligned-1.c
@@ -17,8 +17,8 @@ main ()
 }
 
 #if defined(__cplusplus) && __cplusplus >= 201103L
-static_assert (alignof (S) == 2 * alignof (double), "alignment of S");
-static_assert (alignof (T) == 2 * alignof (double), "alignment of T");
-static_assert (alignof (const S) == 2 * alignof (double), "alignment of const S");
-static_assert (alignof (const T) == 2 * alignof (double), "alignment of const T");
+static_assert (alignof (S) == 2 * __alignof__ (double), "alignment of S");
+static_assert (alignof (T) == 2 * __alignof__ (double), "alignment of T");
+static_assert (alignof (const S) == 2 * __alignof__ (double), "alignment of const S");
+static_assert (alignof (const T) == 2 * __alignof__ (double), "alignment of const T");
 #endif
diff --git a/gcc/testsuite/g++.dg/cpp0x/alignas4.C b/gcc/testsuite/g++.dg/cpp0x/alignas4.C
index baa56eb8ac5..b66fa651bc2 100644
--- a/gcc/testsuite/g++.dg/cpp0x/alignas4.C
+++ b/gcc/testsuite/g++.dg/cpp0x/alignas4.C
@@ -1,6 +1,7 @@
 // PR c++/59012
 // { dg-do compile { target c++11 } }
-// { dg-final { scan-assembler "align 8" { target { { i?86-*-* x86_64-*-* } && { ! *-*-darwin* } } } } }
+// { dg-final { scan-assembler "align 8" { target { { i?86-*-* x86_64-*-* } && { { ! ia32 } && { ! *-*-darwin* } } } } } }
+// { dg-final { scan-assembler "align 4" { target ia32 } } }
 
 template 
 struct A

Re: [PATCH] Update nvptx newlib installation requirements

[Cesar Philippidis]

On 04/24/2018 12:10 AM, Richard Biener wrote:

> That's great news!  Note that we usually keep copies of build dependences at
> ftp://gcc.gnu.org/pub/gcc/infrastructure/ and there's currently no nvptx 
> newlib
> variant there.  Maybe you can prepare a tarball that's ready to plug into gcc
> sources with the nvptx support included?

How do I go about uploading tarball to that ftp server?

I could be mistaken, but I think that GCC's build system would need to
be taught how to build nvptx-tools automatically like newlib. And that's
likely a stage 1 task. But in the meantime, having tarballs for the
build dependencies would be nice.

> Otherwise OK.
> 
> Btw, can you also update the GCC wiki with regarding to this change?

Done. I added a new 'Build Dependencies' section to the nvptx wiki:

https://gcc.gnu.org/wiki/nvptx

Cesar

Re: [PATCH][AArch64] PR target/85512: Tighten SIMD right shift immediate constraints

[James Greenhalgh]

On Tue, Apr 24, 2018 at 04:38:31PM +0100, Kyrill Tkachov wrote:
> Hi all,
> 
> In this testcase it is possible to generate an invalid SISD shift of zero:
> Error: immediate value out of range 1 to 64 at operand 3 -- `sshr 
> v9.2s,v0.2s,0'
> 
> The SSHR and USHR instructions require a shift from 1 up to the element size.
> However our constraints on the scalar shifts that generate these patterns
> allow a shift amount of zero as well. The pure GP-reg ASR and LSR
> instructions allow a shift amount of zero.
> 
> It is unlikely that a shift of zero will survive till the end of compilation,
> but it's not impossible, as this PR shows.
> 
> The patch tightens up the constraints in the offending patterns by adding two
> new constraints that allow shift amounts [1,32] and [1,64] and using them in
> *aarch64_ashr_sisd_or_int_3
> and *aarch64_lshr_sisd_or_int_3.
> The left-shift SISD instructions SHL and USHL allow a shift amount of zero so
> don't need adjustment The vector shift patterns that map down to SSHR and
> USHR already enforce the correct immediate range.
> 
> Bootstrapped and tested on aarch64-none-linux-gnu.
> Ok for trunk?

OK if the release managers are fine with this.

I was a little nervous that we were tightening restrictions on an instruction
which has caused trouble in the past, but this patch looks right to me.

Thanks,
James

> 2018-04-24  Kyrylo Tkachov  
> 
>  PR target/85512
>  * config/aarch64/constraints.md (Usg, Usj): New constraints.
>  * config/aarch64/iterators.md (cmode_simd): New mode attribute.
>  * config/aarch64/aarch64.md (*aarch64_ashr_sisd_or_int_3):
>  Use the above on operand 2.  Reindent.
>  (*aarch64_lshr_sisd_or_int_3): Likewise.
> 
> 2018-04-24  Kyrylo Tkachov  
> 
>  PR target/85512
>  * gcc.dg/pr85512.c: New test.

RE: [PATCH 0/5] x86/CET: Remove the -mcet command-lint option

[Tsimbalist, Igor V]

> -Original Message-
> From: H.J. Lu [mailto:hjl.to...@gmail.com]
> Sent: Sunday, April 22, 2018 3:48 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Tsimbalist, Igor V ; Uros Bizjak
> 
> Subject: [PATCH 0/5] x86/CET: Remove the -mcet command-lint option
> 
> With revision 259496:
> 
> commit b1384095a7c1d06a44b70853372ebe037b2f7867
> Author: hjl 
> Date:   Thu Apr 19 15:15:04 2018 +
> 
> x86: Enable -fcf-protection with multi-byte NOPs
> 
> -fcf-protection no longer depens on -mcet and with revision 259522:
> 
> commit d59cfa9a4064339cf2bd2da828c4c133f13e57f0
> Author: hjl 
> Date:   Fri Apr 20 13:30:13 2018 +
> 
> Define __CET__ for -fcf-protection and remove -mibt
> 
> -mcet becomes an alias for -mshstk.
> 
> To enable shadow stack protection in a program, -fcf-protection=return
> must be used to compile the program.  -mcet/-mshstk are used to enable
> shadow stack intrinsics to IMPLEMENT shadow stack, not to ENABLE shadow
> stack protection.  Since -mcet won't get any shadow stack protection,
> -mcet will only lead user confusions.  This set of patches removes -mcet
> from GCC 8.
> 
> H.J. Lu (5):
>   x86/CET: Build target libraries with -mshstk
>   Regenerate configure of target libraries
>   Don't bootstrap GCC with -mcet
>   x86/CET tests: Remove -mcet/-mno-cet or replace -mcet with -mshstk
>   x86/CET: Remove the -mcet command-lint option
> 
>  config/bootstrap-cet.mk|  6 +--
>  config/cet.m4  |  2 +-
>  gcc/common/config/i386/i386-common.c   |  1 -
>  gcc/config/i386/i386.opt   |  5 ---
>  gcc/doc/install.texi   |  4 +-
>  gcc/doc/invoke.texi| 10 +
>  gcc/testsuite/g++.dg/cet-notrack-1.C   |  2 +-
>  gcc/testsuite/g++.dg/torture/pr85334.C |  2 +-
>  gcc/testsuite/gcc.dg/pr85388-1.c   |  2 +-
>  gcc/testsuite/gcc.dg/pr85388-2.c   |  2 +-
>  gcc/testsuite/gcc.dg/pr85388-3.c   |  2 +-
>  gcc/testsuite/gcc.dg/pr85388-4.c   |  2 +-
>  gcc/testsuite/gcc.dg/pr85388-5.c   |  2 +-
>  gcc/testsuite/gcc.dg/pr85388-6.c   |  4 +-
>  gcc/testsuite/gcc.dg/torture/pr85397-1.c   |  2 +-
>  gcc/testsuite/gcc.target/i386/attr-nocf-check-1a.c |  2 +-
>  gcc/testsuite/gcc.target/i386/attr-nocf-check-3a.c |  2 +-
>  gcc/testsuite/gcc.target/i386/cet-intrin-10.c  |  2 +-
>  gcc/testsuite/gcc.target/i386/cet-intrin-3.c   |  2 +-
>  gcc/testsuite/gcc.target/i386/cet-intrin-5.c   |  2 +-
>  gcc/testsuite/gcc.target/i386/cet-intrin-6.c   |  2 +-
>  gcc/testsuite/gcc.target/i386/cet-intrin-7.c   |  2 +-
>  gcc/testsuite/gcc.target/i386/cet-intrin-8.c   |  2 +-
>  gcc/testsuite/gcc.target/i386/cet-intrin-9.c   |  2 +-
>  gcc/testsuite/gcc.target/i386/cet-label-2.c|  2 +-
>  gcc/testsuite/gcc.target/i386/cet-label-3.c| 16 
>  gcc/testsuite/gcc.target/i386/cet-label.c  |  4 +-
>  gcc/testsuite/gcc.target/i386/cet-notrack-1a.c |  2 +-
>  gcc/testsuite/gcc.target/i386/cet-notrack-1b.c |  2 +-
>  gcc/testsuite/gcc.target/i386/cet-notrack-2a.c |  2 +-
>  gcc/testsuite/gcc.target/i386/cet-notrack-2b.c |  2 +-
>  gcc/testsuite/gcc.target/i386/cet-notrack-3.c  |  2 +-
>  gcc/testsuite/gcc.target/i386/cet-notrack-4a.c |  2 +-
>  gcc/testsuite/gcc.target/i386/cet-notrack-4b.c |  2 +-
>  gcc/testsuite/gcc.target/i386/cet-notrack-5a.c |  2 +-
>  gcc/testsuite/gcc.target/i386/cet-notrack-5b.c |  2 +-
>  gcc/testsuite/gcc.target/i386/cet-notrack-6a.c |  2 +-
>  gcc/testsuite/gcc.target/i386/cet-notrack-6b.c |  2 +-
>  gcc/testsuite/gcc.target/i386/cet-notrack-7.c  |  2 +-
>  gcc/testsuite/gcc.target/i386/cet-notrack-icf-2.c  |  2 +-
>  gcc/testsuite/gcc.target/i386/cet-notrack-icf-4.c  |  2 +-
>  gcc/testsuite/gcc.target/i386/cet-property-1.c |  2 +-
>  gcc/testsuite/gcc.target/i386/cet-property-2.c |  2 +-
>  gcc/testsuite/gcc.target/i386/cet-property-3.c | 11 -
>  gcc/testsuite/gcc.target/i386/cet-rdssp-1.c|  2 +-
>  gcc/testsuite/gcc.target/i386/cet-sjlj-1.c |  2 +-
>  gcc/testsuite/gcc.target/i386/cet-sjlj-2.c |  2 +-
>  gcc/testsuite/gcc.target/i386/cet-sjlj-3.c |  2 +-
>  gcc/testsuite/gcc.target/i386/cet-sjlj-4.c |  2 +-
>  gcc/testsuite/gcc.target/i386/cet-sjlj-5.c |  2 +-
>  gcc/testsuite/gcc.target/i386/cet-sjlj-6a.c|  2 +-
>  gcc/testsuite/gcc.target/i386/cet-sjlj-6b.c|  2 +-
>  gcc/testsuite/gcc.target/i386/cet-sjlj-7.c | 48 
> --
>  gcc/testsuite/gcc.target/i386/cet-switch-1.c   |  2 +-
>  gcc/testsuite/gcc.target/i386/cet-switch-2.c   |  2 +-
>  gcc/testsuite/gcc.target/i386/cet-switch-3.c   |  2 +-
>  gcc/testsuite/gcc.target/i386/indirect-thunk-11.c  |  2 +-
>  gcc/testsuite/gcc.target/i386/indirect-

Re: [PATCH][AArch64] PR target/85512: Tighten SIMD right shift immediate constraints

[Kyrill Tkachov]

On 24/04/18 17:09, James Greenhalgh wrote:

On Tue, Apr 24, 2018 at 04:38:31PM +0100, Kyrill Tkachov wrote:

Hi all,

In this testcase it is possible to generate an invalid SISD shift of zero:
Error: immediate value out of range 1 to 64 at operand 3 -- `sshr v9.2s,v0.2s,0'

The SSHR and USHR instructions require a shift from 1 up to the element size.
However our constraints on the scalar shifts that generate these patterns
allow a shift amount of zero as well. The pure GP-reg ASR and LSR
instructions allow a shift amount of zero.

It is unlikely that a shift of zero will survive till the end of compilation,
but it's not impossible, as this PR shows.

The patch tightens up the constraints in the offending patterns by adding two
new constraints that allow shift amounts [1,32] and [1,64] and using them in
*aarch64_ashr_sisd_or_int_3
and *aarch64_lshr_sisd_or_int_3.
The left-shift SISD instructions SHL and USHL allow a shift amount of zero so
don't need adjustment The vector shift patterns that map down to SSHR and
USHR already enforce the correct immediate range.

Bootstrapped and tested on aarch64-none-linux-gnu.
Ok for trunk?

OK if the release managers are fine with this.

I was a little nervous that we were tightening restrictions on an instruction
which has caused trouble in the past, but this patch looks right to me.


Thanks James.

I've cleaned up the testcase a bit to leave only the function that generates 
the invalid instruction,
making it shorter.

Jakub, is the patch ok to go in for GCC 8 from your perspective?

Thanks,
Kyrill


Thanks,
James


2018-04-24  Kyrylo Tkachov  

  PR target/85512
  * config/aarch64/constraints.md (Usg, Usj): New constraints.
  * config/aarch64/iterators.md (cmode_simd): New mode attribute.
  * config/aarch64/aarch64.md (*aarch64_ashr_sisd_or_int_3):
  Use the above on operand 2.  Reindent.
  (*aarch64_lshr_sisd_or_int_3): Likewise.

2018-04-24  Kyrylo Tkachov  

  PR target/85512
  * gcc.dg/pr85512.c: New test.


commit 0856b82380edda94b4e70b19522366fb80ebecff
Author: Kyrylo Tkachov 
Date:   Tue Apr 24 13:51:19 2018 +0100

[AArch64] PR target/85512

diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
index 4924168..953edb7 100644
--- a/gcc/config/aarch64/aarch64.md
+++ b/gcc/config/aarch64/aarch64.md
@@ -4403,7 +4403,8 @@ (define_insn "*aarch64_lshr_sisd_or_int_3"
   [(set (match_operand:GPI 0 "register_operand" "=r,r,w,&w,&w")
 	(lshiftrt:GPI
 	 (match_operand:GPI 1 "register_operand" "r,r,w,w,w")
-	 (match_operand:QI 2 "aarch64_reg_or_shift_imm_" "Us,r,Us,w,0")))]
+	 (match_operand:QI 2 "aarch64_reg_or_shift_imm_"
+			  "Us,r,Us,w,0")))]
   ""
   "@
lsr\t%0, %1, %2
@@ -4448,9 +4449,10 @@ (define_split
 ;; Arithmetic right shift using SISD or Integer instruction
 (define_insn "*aarch64_ashr_sisd_or_int_3"
   [(set (match_operand:GPI 0 "register_operand" "=r,r,w,&w,&w")
-(ashiftrt:GPI
-  (match_operand:GPI 1 "register_operand" "r,r,w,w,w")
-  (match_operand:QI 2 "aarch64_reg_or_shift_imm_di" "Us,r,Us,w,0")))]
+	(ashiftrt:GPI
+	  (match_operand:GPI 1 "register_operand" "r,r,w,w,w")
+	  (match_operand:QI 2 "aarch64_reg_or_shift_imm_di"
+			   "Us,r,Us,w,0")))]
   ""
   "@
asr\t%0, %1, %2
diff --git a/gcc/config/aarch64/constraints.md b/gcc/config/aarch64/constraints.md
index f052103..b5da997 100644
--- a/gcc/config/aarch64/constraints.md
+++ b/gcc/config/aarch64/constraints.md
@@ -153,6 +153,20 @@ (define_constraint "Usf"
(match_test "!(aarch64_is_noplt_call_p (op)
 		  || aarch64_is_long_call_p (op))")))
 
+(define_constraint "Usg"
+  "@internal
+  A constraint that matches an immediate right shift constant in SImode
+  suitable for a SISD instruction."
+  (and (match_code "const_int")
+   (match_test "IN_RANGE (ival, 1, 32)")))
+
+(define_constraint "Usj"
+  "@internal
+  A constraint that matches an immediate right shift constant in DImode
+  suitable for a SISD instruction."
+  (and (match_code "const_int")
+   (match_test "IN_RANGE (ival, 1, 64)")))
+
 (define_constraint "UsM"
   "@internal
   A constraint that matches the immediate constant -1."
diff --git a/gcc/config/aarch64/iterators.md b/gcc/config/aarch64/iterators.md
index 33933ec..bd97408 100644
--- a/gcc/config/aarch64/iterators.md
+++ b/gcc/config/aarch64/iterators.md
@@ -589,6 +589,9 @@ (define_mode_attr lconst2 [(SI "UsO") (DI "UsP")])
 ;; Map a mode to a specific constraint character.
 (define_mode_attr cmode [(QI "q") (HI "h") (SI "s") (DI "d")])
 
+;; Map modes to Usg and Usj constraints for SISD right shifts
+(define_mode_attr cmode_simd [(SI "g") (DI "j")])
+
 (define_mode_attr Vtype [(V8QI "8b") (V16QI "16b")
 			 (V4HI "4h") (V8HI  "8h")
  (V2SI "2s") (V4SI  "4s")
diff --git a/gcc/testsuite/gcc.dg/pr85512.c b/gcc/testsuite/gcc.dg/pr85512.c
new file mode 100644
index 000..b581f83
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr85512.c
@@ -0,0 +1,47 @@
+/* 

Re: RFC: C++ PATCH for c++/69763, making C++ alignof match C _Alignof

[Jakub Jelinek]

On Tue, Apr 24, 2018 at 11:55:44AM -0400, Jason Merrill wrote:
> >> Tested x86_64-pc-linux-gnu, applying to trunk.
> >
> > This regressed:
> > +FAIL: c-c++-common/attr-aligned-1.c  -std=c++11 (test for excess errors)
> > +UNRESOLVED: c-c++-common/attr-aligned-1.c  -std=c++11 compilation failed 
> > to produce executable
> > +FAIL: c-c++-common/attr-aligned-1.c  -std=c++14 (test for excess errors)
> > +UNRESOLVED: c-c++-common/attr-aligned-1.c  -std=c++14 compilation failed 
> > to produce executable
> > +FAIL: g++.dg/cpp0x/alignas4.C  -std=c++11  scan-assembler align 8
> > +FAIL: g++.dg/cpp0x/alignas4.C  -std=c++14  scan-assembler align 8
> > on i686-linux, can be reproduced even with just
> > make check-gcc check-g++ RUNTESTFLAGS="--target_board=unix\{-m64,-m32\} 
> > dg.exp='attr-aligned-1.c alignas4.C'"
> > on x86_64-linux.
> 
> Thanks.  How is your build tree configured so that this finds the
> appropriate runtime libraries?

For the above make check or for i686-linux bootstraps?

For the former, nothing special is needed, on Fedora/RHEL I guess just
making sure {glibc{,-devel},libgcc}.i686 is installed.

For the latter, I'm using hack scripts:
for i in ~/hbin/*; do echo $i; cat $i; done
/home/jakub/hbin/as
#!/bin/sh
exec /usr/bin/as --32 "$@"
/home/jakub/hbin/g++
#!/bin/sh
exec /usr/bin/g++ -m32 "$@"
/home/jakub/hbin/gcc
#!/bin/sh
exec /usr/bin/gcc -m32 "$@"
/home/jakub/hbin/ld
#!/bin/sh
case "$*" in
  --version) cat <<\EOF
GNU ld version 2.20.52.0.1-10.fc17 20100131
Copyright 2012 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.
EOF
  exit 0;;
esac
exec /usr/bin/ld -m elf_i386 -L /usr/lib/ "$@"

The ld ugliness is to avoid lto-plugin.  And then just
PATH=~/hbin:$PATH i386 ../configure 
--enable-languages=default,obj-c++,lto,go,brig --enable-checking=yes,rtl,extra 
&& PATH=~/hbin:$PATH i386 make -j16 bootstrap > LOG 2>&1 && PATH=~/hbin:$PATH 
i386 make -j16 -k check > LOGC 2>&1; ../contrib/test_summary > LOGT 2>&1

Jakub

Re: [PATCH] Remove __builtin_ia32_readeflags_u32/__builtin_ia32_writeeflags_u32 builtins for TARGET_64BIT (PR target/85511)

[Uros Bizjak]

On Tue, Apr 24, 2018 at 2:51 PM, Jakub Jelinek  wrote:
> Hi!
>
> These two *_u32 builtins are defined also in -m64 mode, but share the
> builtin codes with the *_u64 ones and the expansion of them uses word_mode.
>
> The following patch just removes them, ia32intrin.h uses the u32 suffixed
> ones only when __x86_64__ is not defined, bootstrapped/regtested on
> x86_64-linux and i686-linux, ok for trunk?
>
> A variant would be to use separate IX86_BUILTIN_ codes for the 32-bit and
> 64-bit builtins and add separate expansion for them, but that looks like
> overkill to me, people should use __readeflags/__writeeflags anyway and
> those do the right thing.
>
> 2018-04-24  Jakub Jelinek  
>
> PR target/85511
> * config/i386/i386.c (ix86_init_mmx_sse_builtins): Don't define
> __builtin_ia32_readeflags_u32 and __builtin_ia32_writeeflags_u32
> if TARGET_64BIT.
>
> * gcc.target/i386/pr85511.c: New test.

OK.

Thanks,
Uros.

> --- gcc/config/i386/i386.c.jj   2018-04-24 09:37:36.029459208 +0200
> +++ gcc/config/i386/i386.c  2018-04-24 10:37:01.258882134 +0200
> @@ -31934,14 +31934,20 @@ ix86_init_mmx_sse_builtins (void)
>IX86_BUILTIN_SBB64);
>
>/* Read/write FLAGS.  */
> -  def_builtin (0, "__builtin_ia32_readeflags_u32",
> -   UNSIGNED_FTYPE_VOID, IX86_BUILTIN_READ_FLAGS);
> -  def_builtin (OPTION_MASK_ISA_64BIT, "__builtin_ia32_readeflags_u64",
> -   UINT64_FTYPE_VOID, IX86_BUILTIN_READ_FLAGS);
> -  def_builtin (0, "__builtin_ia32_writeeflags_u32",
> -   VOID_FTYPE_UNSIGNED, IX86_BUILTIN_WRITE_FLAGS);
> -  def_builtin (OPTION_MASK_ISA_64BIT, "__builtin_ia32_writeeflags_u64",
> -   VOID_FTYPE_UINT64, IX86_BUILTIN_WRITE_FLAGS);
> +  if (TARGET_64BIT)
> +{
> +  def_builtin (OPTION_MASK_ISA_64BIT, "__builtin_ia32_readeflags_u64",
> +  UINT64_FTYPE_VOID, IX86_BUILTIN_READ_FLAGS);
> +  def_builtin (OPTION_MASK_ISA_64BIT, "__builtin_ia32_writeeflags_u64",
> +  VOID_FTYPE_UINT64, IX86_BUILTIN_WRITE_FLAGS);
> +}
> +  else
> +{
> +  def_builtin (0, "__builtin_ia32_readeflags_u32",
> +  UNSIGNED_FTYPE_VOID, IX86_BUILTIN_READ_FLAGS);
> +  def_builtin (0, "__builtin_ia32_writeeflags_u32",
> +  VOID_FTYPE_UNSIGNED, IX86_BUILTIN_WRITE_FLAGS);
> +}
>
>/* CLFLUSHOPT.  */
>def_builtin (OPTION_MASK_ISA_CLFLUSHOPT, "__builtin_ia32_clflushopt",
> --- gcc/testsuite/gcc.target/i386/pr85511.c.jj  2018-04-24 10:45:18.099260629 
> +0200
> +++ gcc/testsuite/gcc.target/i386/pr85511.c 2018-04-24 10:47:46.069374103 
> +0200
> @@ -0,0 +1,15 @@
> +/* PR target/85511 */
> +/* { dg-do compile } */
> +/* { dg-options "-Wimplicit-function-declaration" } */
> +
> +unsigned int
> +foo (void)
> +{
> +  return __builtin_ia32_readeflags_u32 (); /* { dg-warning "implicit 
> declaration of function" "" { target { ! ia32 } } } */
> +}
> +
> +void
> +bar (unsigned int x)
> +{
> +  __builtin_ia32_writeeflags_u32 (x);  /* { dg-warning "implicit 
> declaration of function" "" { target { ! ia32 } } } */
> +}
>
> Jakub

Re: [PATCH] [PR c++/85437] accept static_casted ptrmem in constexpr

[Nathan Sidwell]

On 04/23/2018 01:19 PM, Jason Merrill wrote:
On Fri, Apr 20, 2018, 12:52 PM Nathan Sidwell 


I have to change convert_ptrmem to always
expand the constant (into an OFFSET_TYPE) so that
initializer_constant_valid_p (used by reduced_constant_expression_p)
doesn't get confused by a zero-adjusting conversion of a ptrmem_cst.


Hmm, I'm nervous about this change.  Maybe teach r_c_e_p to handle this 
case properly?


Here's an updated patch.  We keep convert_ptrmem unchanged.  I didn't 
need to teach RCEP anything new, fortunately.  In 
cxx_eval_constant_expression I call cplus_expand_constant on the cases 
that we previously complained were reinterpret_casts.  This does seem 
somewhat ugly though.


bootstrapped on x86_64-linux

nathan

--
Nathan Sidwell

Re: [PATCH] [PR c++/85437] accept static_casted ptrmem in constexpr

[Nathan Sidwell]

Now with added patchy goodness.

On 04/24/2018 12:31 PM, Nathan Sidwell wrote:

On 04/23/2018 01:19 PM, Jason Merrill wrote:
On Fri, Apr 20, 2018, 12:52 PM Nathan Sidwell 


    I have to change convert_ptrmem to always
    expand the constant (into an OFFSET_TYPE) so that
    initializer_constant_valid_p (used by reduced_constant_expression_p)
    doesn't get confused by a zero-adjusting conversion of a ptrmem_cst.


Hmm, I'm nervous about this change.  Maybe teach r_c_e_p to handle 
this case properly?


Here's an updated patch.  We keep convert_ptrmem unchanged.  I didn't 
need to teach RCEP anything new, fortunately.  In 
cxx_eval_constant_expression I call cplus_expand_constant on the cases 
that we previously complained were reinterpret_casts.  This does seem 
somewhat ugly though.


bootstrapped on x86_64-linux

nathan




--
Nathan Sidwell
2018-04-24  Nathan Sidwell  

	PR c++/85437
	PR c++/49171
	* cp-tree.h (REINTERPRET_CAST_P): New.
	* constexpr.c (cxx_eval_constant_expression) :
	Reject REINTERPET_CAST_P conversions.  Use cplus_expand_constant
	for non-trivial PTRMEM_CST cases.
	* typeck.c (build_nop_reinterpret): New.
	(build_reinterpret_cast_1): Use it.  Set REINTERPRET_CAST_P on
	NOP_EXPRs returned by cp_convert.

2018-04-24  Jakub Jelinek  

	PR c++/85437
	PR c++/49171
	* g++.dg/cpp0x/addressof1.C: Make reinterpret cases runtime checks.
	* g++.dg/cpp0x/constexpr-cast.C: Remove xfails
	* g++.dg/cpp0x/constexpr-nullptr-2.C: Likewise.
	* g++.dg/cpp0x/constexpr-pmf1.C: Check when optimized.
	* g++.dg/cpp0x/pr85437-1.C: New.
	* g++.dg/cpp0x/pr85437-2.C: New.
	* g++.dg/cpp0x/pr85437-3.C: New.
	* g++.dg/cpp0x/pr85437-4.C: New.

Index: cp/constexpr.c
===
--- cp/constexpr.c	(revision 259592)
+++ cp/constexpr.c	(working copy)
@@ -1822,8 +1822,8 @@ reduced_constant_expression_p (tree t)
 }
 
 /* Some expressions may have constant operands but are not constant
-   themselves, such as 1/0.  Call this function (or rather, the macro
-   following it) to check for that condition.
+   themselves, such as 1/0.  Call this function to check for that
+   condition.
 
We only call this in places that require an arithmetic constant, not in
places where we might have a non-constant expression that can be a
@@ -4579,9 +4579,18 @@ cxx_eval_constant_expression (const cons
    non_constant_p, overflow_p);
   break;
 
+case NOP_EXPR:
+  if (REINTERPRET_CAST_P (t))
+	{
+	  if (!ctx->quiet)
+	error_at (EXPR_LOC_OR_LOC (t, input_location),
+		  "a reinterpret_cast is not a constant expression");
+	  *non_constant_p = true;
+	  return t;
+	}
+  /* FALLTHROUGH.  */
 case CONVERT_EXPR:
 case VIEW_CONVERT_EXPR:
-case NOP_EXPR:
 case UNARY_PLUS_EXPR:
   {
 	tree oldop = TREE_OPERAND (t, 0);
@@ -4595,20 +4604,13 @@ cxx_eval_constant_expression (const cons
 	if (TREE_CODE (op) == PTRMEM_CST
 	&& !TYPE_PTRMEM_P (type))
 	  op = cplus_expand_constant (op);
+
 	if (TREE_CODE (op) == PTRMEM_CST && tcode == NOP_EXPR)
 	  {
-	if (same_type_ignoring_top_level_qualifiers_p (type,
-			   TREE_TYPE (op))
-		|| can_convert_qual (type, op))
-	  return cp_fold_convert (type, op);
-	else
-	  {
-		if (!ctx->quiet)
-		  error_at (EXPR_LOC_OR_LOC (t, input_location),
-			"a reinterpret_cast is not a constant expression");
-		*non_constant_p = true;
-		return t;
-	  }
+	if (!same_type_ignoring_top_level_qualifiers_p (type, TREE_TYPE (op))
+		&& !can_convert_qual (type, op))
+	  op = cplus_expand_constant (op);
+	return cp_fold_convert (type, op);
 	  }
 
 	if (POINTER_TYPE_P (type) && TREE_CODE (op) == INTEGER_CST)
@@ -4653,14 +4655,17 @@ cxx_eval_constant_expression (const cons
 		return t;
 	  }
 	  }
+
 	if (op == oldop && tcode != UNARY_PLUS_EXPR)
 	  /* We didn't fold at the top so we could check for ptr-int
 	 conversion.  */
 	  return fold (t);
+
 	if (tcode == UNARY_PLUS_EXPR)
 	  r = fold_convert (TREE_TYPE (t), op);
 	else
 	  r = fold_build1 (tcode, type, op);
+
 	/* Conversion of an out-of-range value has implementation-defined
 	   behavior; the language considers it different from arithmetic
 	   overflow, which is undefined.  */
Index: cp/cp-tree.h
===
--- cp/cp-tree.h	(revision 259592)
+++ cp/cp-tree.h	(working copy)
@@ -372,6 +372,7 @@ extern GTY(()) tree cp_global_trees[CPTI
   TEMPLATE_TYPE_PARM_FOR_CLASS (TEMPLATE_TYPE_PARM)
   DECL_NAMESPACE_INLINE_P (in NAMESPACE_DECL)
   SWITCH_STMT_ALL_CASES_P (in SWITCH_STMT)
+  REINTERPRET_CAST_P (in NOP_EXPR)
   ALIGNOF_EXPR_STD_P (in ALIGNOF_EXPR)
1: IDENTIFIER_KIND_BIT_1 (in IDENTIFIER_NODE)
   TI_PENDING_TEMPLATE_FLAG.
@@ -632,6 +633,11 @@ typedef struct ptrmem_cst * ptrmem_cst_t
 #define COND_EXPR_IS_VEC_DELETE(NODE) \
   TREE_LANG_FLAG_0 (COND_EXPR_CHECK (NODE))
 
+/* Nonzero if this NOP_EXPR is a reinterpret_cast.  

Re: [PATCH 0/2] Require that constraints are used to reference global regs

[Alexander Monakov]

On Tue, 24 Apr 2018, Michael Matz wrote:
> What is lost here (it wasn't explicit before, but is the case and must 
> continue to work) is that function calls and returns count as needing the 
> observable value in the specified register (function calls also count as 
> setters of them).  I think that should be made more explicit.

It's no different from a normal variable in global scope. If the compiler sees

  gvar = 0;
  bar();
  gvar = 1;

it can delete the first store iff it can prove that it's dead ('bar' does
not read it), gvar being a register variable making no difference. So I
don't think it needs additional clarification.

> Especially 
> because you make it explicit that the register remains available for 
> allocation (where it before said it's not) we need to make sure that 
> everybody understand that it's only during tiny windows like:
> 
>   regvar = ...
>   ... code not accessing regvar and containing no calls ...
>   regvar = ...

No, the first store is not needed. If the regvar is dead, the register is
freely allocatable (if not dead, it's allocatable at a cost of 1 spill).

> The return of functions also must remain making the regvar setter live, to 
> give us the important parts of the former "stores aren't deleted even if 
> appearing dead" guarantee.

This also follows from the variable being a global variable in the first place.

Alexander

Re: [PATCH][AArch64] PR target/85512: Tighten SIMD right shift immediate constraints

[Kyrill Tkachov]

On 24/04/18 17:41, Jakub Jelinek wrote:

On Tue, Apr 24, 2018 at 05:22:15PM +0100, Kyrill Tkachov wrote:

I've cleaned up the testcase a bit to leave only the function that generates 
the invalid instruction,
making it shorter.

Jakub, is the patch ok to go in for GCC 8 from your perspective?

The PR is marked P1 now, so sure, please commit this for GCC 8, the sooner
the better.  We have only one other P1 left.


Thanks, I've committed it as 259614.


The only thing I'm unsure about is whether you want to make the top of the
range 32 and 64 rather than just 31 and 63, after all the operand
predicate used there requires < 32 and < 64, and from middle-end's POV
shifts by 32 or 64 are undefined (unless SHIFT_COUNT_TRUNCATED, but
aarch64 defines it to
#define SHIFT_COUNT_TRUNCATED (!TARGET_SIMD)

So, using
(match_test "IN_RANGE (ival, 1, 31)")))
and
(match_test "IN_RANGE (ival, 1, 63)")))
would feel safer to me, but your call.


I don't think this is necessary.
We already nominally allow shifts up to 32/64 in the SIMD versions
(see aarch64_simd_ashr in aarch64-simd.md) though I imagine if such shifts
are undefined in the midend then it will just not generate them or at least blow
up somewhere along the way.

So I've left the range as is.
Thanks,
Kyrill


2018-04-24  Kyrylo Tkachov  

   PR target/85512
   * config/aarch64/constraints.md (Usg, Usj): New constraints.
   * config/aarch64/iterators.md (cmode_simd): New mode attribute.
   * config/aarch64/aarch64.md (*aarch64_ashr_sisd_or_int_3):
   Use the above on operand 2.  Reindent.
   (*aarch64_lshr_sisd_or_int_3): Likewise.

2018-04-24  Kyrylo Tkachov  

   PR target/85512
   * gcc.dg/pr85512.c: New test.


Jakub

[PATCH 2/2] x86: Update __CET__ check

[H.J. Lu]

__CET__ has been changed by revision 259522:

commit d59cfa9a4064339cf2bd2da828c4c133f13e57f0
Author: hjl 
Date:   Fri Apr 20 13:30:13 2018 +

Define __CET__ for -fcf-protection and remove -mibt

to

(__CET__ & 1) != 0: -fcf-protection=branch or -fcf-protection=full
(__CET__ & 2) != 0: -fcf-protection=return or -fcf-protection=full

We should check (__CET__ & 2) != 0 for shadow stack.

libgcc/

* config/i386/linux-unwind.h: Add (__CET__ & 2) != 0 check
when including "config/i386/shadow-stack-unwind.h".

libitm/

* config/x86/sjlj.S (_ITM_beginTransaction): Add
(__CET__ & 2) != 0 check for shadow stack.
(GTM_longjmp): Likewise.
---
 libgcc/config/i386/linux-unwind.h | 2 +-
 libitm/config/x86/sjlj.S  | 8 
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/libgcc/config/i386/linux-unwind.h 
b/libgcc/config/i386/linux-unwind.h
index f1f52334d8d..ea838e4e47b 100644
--- a/libgcc/config/i386/linux-unwind.h
+++ b/libgcc/config/i386/linux-unwind.h
@@ -23,7 +23,7 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  If 
not, see
 .  */
 
 /* Unwind shadow stack for -fcf-protection -mshstk.  */
-#if defined __SHSTK__ && defined __CET__
+#if defined __SHSTK__ && defined __CET__ && (__CET__ & 2) != 0
 # include "config/i386/shadow-stack-unwind.h"
 #endif
 
diff --git a/libitm/config/x86/sjlj.S b/libitm/config/x86/sjlj.S
index 2345b2f4ec4..e5cdbab48a7 100644
--- a/libitm/config/x86/sjlj.S
+++ b/libitm/config/x86/sjlj.S
@@ -141,7 +141,7 @@ SYM(_ITM_beginTransaction):
movq%r15, -24(%rax)
xorq%rdx, %rdx
/* Save zero or shadow stack pointer in the new field.  */
-#if defined(__SHSTK__) && defined(__CET__)
+#if defined __SHSTK__ && defined __CET__ && (__CET__ & 2) != 0
rdsspq  %rdx
 #endif
movq%rdx, -16(%rax)
@@ -177,7 +177,7 @@ SYM(_ITM_beginTransaction):
movl%ebp, 20(%esp)
xorl%edx, %edx
/* Save zero or shadow stack pointer in the new field.  */
-#if defined(__SHSTK__) && defined(__CET__)
+#if defined __SHSTK__ && defined __CET__ && (__CET__ & 2) != 0
rdsspd  %edx
 #endif
movl%edx, 24(%esp)
@@ -221,7 +221,7 @@ SYM(GTM_longjmp):
cfi_offset(%rip, 64)
cfi_register(%rsp, %rcx)
movq%rcx, %rsp
-#if defined(__SHSTK__) && defined(__CET__)
+#if defined __SHSTK__ && defined __CET__ && (__CET__ & 2) != 0
/* Check if Shadow Stack is enabled.  */
xorq%rcx, %rcx
rdsspq  %rcx
@@ -259,7 +259,7 @@ SYM(GTM_longjmp):
cfi_offset(%eip, 24)
cfi_register(%esp, %ecx)
movl%ecx, %esp
-#if defined(__SHSTK__) && defined(__CET__)
+#if defined __SHSTK__ && defined __CET__ && (__CET__ & 2) != 0
/* Check if Shadow Stack is enabled.  */
xorl%ecx, %ecx
rdsspd  %ecx
-- 
2.14.3

[PATCH 1/2] x86/CET: Add -fcf-protection to STAGE4_CFLAGS

[H.J. Lu]

Since profiledbootstrap uses

STAGEfeedback_CFLAGS = $(STAGE4_CFLAGS) -fprofile-use

add

STAGE4_CFLAGS += -fcf-protection -mcet

to bootstrap-cet.mk to support profiledbootstrap with CET.

PR bootstrap/85490
* bootstrap-cet.mk (STAGE4_CFLAGS): New.
---
 config/bootstrap-cet.mk | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/config/bootstrap-cet.mk b/config/bootstrap-cet.mk
index b5dee601a3f..6ef1ba279cd 100644
--- a/config/bootstrap-cet.mk
+++ b/config/bootstrap-cet.mk
@@ -1,4 +1,5 @@
-# This option enables -fcf-protection for stage2 and stage3.
+# This option enables -fcf-protection for stage2, stage3 and stage4.
 
 STAGE2_CFLAGS += -fcf-protection
 STAGE3_CFLAGS += -fcf-protection
+STAGE4_CFLAGS += -fcf-protection
-- 
2.14.3

[PATCH] Remove __builtin_ia32_readeflags_u32/__builtin_ia32_writeeflags_u32 builtins for TARGET_64BIT (PR target/85511)

[Jakub Jelinek]

Hi!

These two *_u32 builtins are defined also in -m64 mode, but share the
builtin codes with the *_u64 ones and the expansion of them uses word_mode.

The following patch just removes them, ia32intrin.h uses the u32 suffixed
ones only when __x86_64__ is not defined, bootstrapped/regtested on
x86_64-linux and i686-linux, ok for trunk?

A variant would be to use separate IX86_BUILTIN_ codes for the 32-bit and
64-bit builtins and add separate expansion for them, but that looks like
overkill to me, people should use __readeflags/__writeeflags anyway and
those do the right thing.

2018-04-24  Jakub Jelinek  

PR target/85511
* config/i386/i386.c (ix86_init_mmx_sse_builtins): Don't define
__builtin_ia32_readeflags_u32 and __builtin_ia32_writeeflags_u32
if TARGET_64BIT.

* gcc.target/i386/pr85511.c: New test.

--- gcc/config/i386/i386.c.jj   2018-04-24 09:37:36.029459208 +0200
+++ gcc/config/i386/i386.c  2018-04-24 10:37:01.258882134 +0200
@@ -31934,14 +31934,20 @@ ix86_init_mmx_sse_builtins (void)
   IX86_BUILTIN_SBB64);
 
   /* Read/write FLAGS.  */
-  def_builtin (0, "__builtin_ia32_readeflags_u32",
-   UNSIGNED_FTYPE_VOID, IX86_BUILTIN_READ_FLAGS);
-  def_builtin (OPTION_MASK_ISA_64BIT, "__builtin_ia32_readeflags_u64",
-   UINT64_FTYPE_VOID, IX86_BUILTIN_READ_FLAGS);
-  def_builtin (0, "__builtin_ia32_writeeflags_u32",
-   VOID_FTYPE_UNSIGNED, IX86_BUILTIN_WRITE_FLAGS);
-  def_builtin (OPTION_MASK_ISA_64BIT, "__builtin_ia32_writeeflags_u64",
-   VOID_FTYPE_UINT64, IX86_BUILTIN_WRITE_FLAGS);
+  if (TARGET_64BIT)
+{
+  def_builtin (OPTION_MASK_ISA_64BIT, "__builtin_ia32_readeflags_u64",
+  UINT64_FTYPE_VOID, IX86_BUILTIN_READ_FLAGS);
+  def_builtin (OPTION_MASK_ISA_64BIT, "__builtin_ia32_writeeflags_u64",
+  VOID_FTYPE_UINT64, IX86_BUILTIN_WRITE_FLAGS);
+}
+  else
+{
+  def_builtin (0, "__builtin_ia32_readeflags_u32",
+  UNSIGNED_FTYPE_VOID, IX86_BUILTIN_READ_FLAGS);
+  def_builtin (0, "__builtin_ia32_writeeflags_u32",
+  VOID_FTYPE_UNSIGNED, IX86_BUILTIN_WRITE_FLAGS);
+}
 
   /* CLFLUSHOPT.  */
   def_builtin (OPTION_MASK_ISA_CLFLUSHOPT, "__builtin_ia32_clflushopt",
--- gcc/testsuite/gcc.target/i386/pr85511.c.jj  2018-04-24 10:45:18.099260629 
+0200
+++ gcc/testsuite/gcc.target/i386/pr85511.c 2018-04-24 10:47:46.069374103 
+0200
@@ -0,0 +1,15 @@
+/* PR target/85511 */
+/* { dg-do compile } */
+/* { dg-options "-Wimplicit-function-declaration" } */
+
+unsigned int
+foo (void)
+{
+  return __builtin_ia32_readeflags_u32 (); /* { dg-warning "implicit 
declaration of function" "" { target { ! ia32 } } } */
+}
+
+void
+bar (unsigned int x)
+{
+  __builtin_ia32_writeeflags_u32 (x);  /* { dg-warning "implicit 
declaration of function" "" { target { ! ia32 } } } */
+}

Jakub

Re: [PATCH] PR 85075, Fix PowerPC __float182/__ibm128 types and mangling

[Joseph Myers]

On Mon, 16 Apr 2018, Segher Boessenkool wrote:

> > The manglings that are now used are:
> > 
> > For -mabi=ieeelongdouble:
> > 
> > __float128  "u10__float128"
> > __ibm128"u8__ibm128"
> > long double "u9__ieee128"
> > 
> > For -mabi=ibmlongdouble:
> > 
> > __float128  "u10__float128"
> > __ibm128"u8__ibm128"
> > long double "g"
> > 
> > For -mlong-double-64:
> > 
> > __float128  "u10__float128"
> > __ibm128"u8__ibm128"
> > long double "e"
> 
> If __float128 is the same type as _Float128, as which of those should
> it be mangled?  The C++ ABI has "DF" for _FloatN, but the demangler uses
> that same code for fixed points types.  Ugh.
> 
> I don't think mangling "long double" as "u9__ieee128" works well with for
> example GDB.
> 
> Cc:ing Joseph Myers; Joseph, do you have any advice here?

I believe it has been stated that the goal is for IEEE long double not to 
require separate multilibs of GCC's libraries; that is, for both libgcc 
and libstdc++ to provide all the required functions under appropriate 
names, whichever is the default when GCC is built, and for the right 
functions to be used automatically.

For libgcc, this is achieved by the existing *tf* names continuing to be 
bound to IBM long double, and new *kf* names being used for IEEE long 
double.  (I don't know if the correct functions now get built for both 
choices of the default ABI - i.e. all *tf* functions, including those from 
libgcc2.c, always being built for IBM long double even when TFmode is IEEE 
long double, all *kf* functions always being built for IEEE long double, 
and the compiler always generating calls to the correct functions for 
IFmode, KFmode and TFmode, whichever format TFmode has.  But if there are 
any remaining issues in this area, they are orthogonal to the C++ issues.)

For libstdc++, avoiding multilibs means the same set of mangled names 
should be present, with the same ABIs, regardless of the default ABI.  
This is why, for example, the existing IBM long double uses "g" rather 
than "e" (the normal long double mangling) - because when long double 
originally had the same ABI as double, that meant "e" symbols were used 
for that 64-bit long double.

It is of course possible for different files in libstdc++ to be built with 
different ABI options (given the existing use of -mno-gnu-attribute for 
building libstdc++ to avoid this causing linker errors for incompatible 
ABIs), and for symbols using one mangled name for a given floating-point 
format to be aliases for symbols using another mangled name for that 
format.  And whereas libstdc++ needs to support long double, whatever type 
long double is in that particular compilation, it's less clear if it needs 
to provide much if any support for the other types (although the compiler 
needs to).

The requirement for _Float128 to be different from long double even if 
they have the same format is a C requirement coming from TS 18661-3.  The 
_FloatN names are deliberately not supported for C++ in GCC, because of an 
expectation that any C++ binding for types for particular floating-point 
formats would be class-based, given that was the approach C++ chose for 
decimal floating point (rather than the C _DecimalN approach).  glibc 
headers do "typedef long double _Float128;" in the C++ case where long 
double has the correct format, so the distinct _Float128 type is not 
normally accessible from C++ in that case.  However, you *can* access 
those _FloatN types via typeof and built-in functions, resulting in ICEs 
for which I've just filed bug 85518.

Returning to the long double, __ibm128 and __float128 types, I suppose 
there are questions:

* Which types need to be different types at the C++ language level?  If 
people do want to use these types in templates and overloads, I suppose 
that indicates always having three separate types as you suggest.

* Where does __ieee128 fit in?

* Where does __typeof (__builtin_inff128 ()) (GCC's internal _Float128 
type, cf. bug 85518) fit in?

* What is the mangling for all those types?

* Which types are supported by libstdc++ (in that it's valid to use them 
as arguments to libstdc++ functions / templates)?

* Which function names are provided by libstdc++ (possibly as aliases)?

The "DF_" mangling was introduced to distinguish _Float16 from 
__fp16, see .  *If* 
it were decided to address bug 85518 by generically supporting mangling 
for the not-quite-hidden-for-C++ _FloatN types (as opposed to arranging 
for float64_type_node etc. to actually be copies of double etc. for C++, 
or for the types to otherwise be completely hidden), I suppose it would be 
natural to use that mangling for those types - but the C++ ABI would need 
to be extended to cover _FloatNx as well if that bug is to be completely 
fixed that way.  (And this ignores the fixed-point issue - I don't know 
why that support is in 

Re: [PATCH, rs6000] Improve Documentation of Built-In Functions Part 1

[Kelvin Nilsen]

I'm updating this patch to make two improvements to what was submitted
earlier today:

1. Correct the description of the htm-no-suspend CPU feature.

2. Add a comment to clarify that the builtin_divde and builtin_divdeu
   built-in functions require 64-bit targets.

Everything else is the same as submitted previously.

On 4/24/18 9:12 AM, Kelvin Nilsen wrote:
> This is the first of several patches to address shortcomings in existing
> documentation of
> PowerPC built-in functions.  The focus of this particular patch is to
> improve documentation
> of low-level built-in functions that do not require special include headers.
> 
> A summary of this patch follows:
> 
> 1. Change the name of the first PowerPC built-in section from "PowerPC
> Built-in Functions"
>    to "Low-Level PowerPC Built-in Functions".  This section has never
> described all PowerPC
>    built-in functions.
> 
> 2. Introduce subsubsections within this section to independently
> describe built-in functions
>    that target particular ISA levels.  Sort function descriptions into
> appropriate
>    subsubsections.
> 
> 3. Add descriptions of three new features that can be tested with the
> __builtin_cpu_supports
>    function: darn, htm-no-suspend, and scv.
> 
> 4. Remove descriptions of built-in function that do not belong in this
> section because the
>    built-in functions are generic (not specific to PowerPC):
> __builtin_fabsq,
>    __builtin_copysignq, __builtin_infq, __builtin_huge_valq, __builtin_nanq,
>    __builtin_nansq, __builtin_sqrtf128, __builtin_fmaf128.
> 
> 5. Corrected the spellings of several built-in functions:
> __builtin_fmaf128_round_to_odd,
>    __builtin_addg6s, __builtin_cbctdt, __builtin_cdtbcd.
> 
> This patch is limited in scope in order to manage complexity of the
> diffs.  Subsequent patches
> will address different sections of the documentation.  Subsequent
> patches will also add
> new function descriptions into these sections.
> 
> This patch affects only extend.texi.  The gcc.pdf file has been built
> and reviewed.
> 
> Is this ok for the trunk?
gcc/ChangeLog:

2018-04-24  Kelvin Nilsen  

* doc/extend.texi: Tidy documentation of PowerPC built-in functions.

Index: gcc/doc/extend.texi
===
--- gcc/doc/extend.texi (revision 259504)
+++ gcc/doc/extend.texi (working copy)
@@ -15524,12 +15524,17 @@ implementing assertions.
 
 @end table
 
-@node PowerPC Built-in Functions
-@subsection PowerPC Built-in Functions
+@node Low-Level PowerPC Built-in Functions
+@subsection Low-Level PowerPC Built-in Functions
 
-The following built-in functions are always available and can be used to
-check the PowerPC target platform type:
+This section describes PowerPC built-in functions that do not require
+the inclusion of any special header files to declare prototypes or
+provide macro definitions.  The sections that follow describe
+additional PowerPC built-in functions.
 
+@node Low-Level PowerPC Built-in Functions Available on all Targets
+@subsubsection Low-Level PowerPC Built-in Functions Available on all Targets
+
 @deftypefn {Built-in Function} void __builtin_cpu_init (void)
 This function is a @code{nop} on the PowerPC platform and is included solely
 to maintain API compatibility with the x86 builtins.
@@ -15633,6 +15638,8 @@ CPU supports the set of compatible performance mon
 CPU supports the Embedded ISA category.
 @item cellbe
 CPU has a CELL broadband engine.
+@item darn
+CPU supports the darn (deliver a random number) instruction.
 @item dfp
 CPU has a decimal floating point unit.
 @item dscr
@@ -15649,6 +15656,9 @@ CPU has a floating point unit.
 CPU has hardware transaction memory instructions.
 @item htm-nosc
 Kernel aborts hardware transactions when a syscall is made.
+@item htm-no-suspend
+CPU supports hardware transaction memory but does not support the
+tsuspend. instruction.
 @item ic_snoop
 CPU supports icache snooping capabilities.
 @item ieee128
@@ -15677,6 +15687,8 @@ CPU supports the old POWER ISA (eg, 601)
 CPU supports 64-bit mode execution.
 @item ppcle
 CPU supports a little-endian mode that uses address swizzling.
+@item scv
+Kernel supports system call vectored.
 @item smt
 CPU support simultaneous multi-threading.
 @item spe
@@ -15708,19 +15720,81 @@ Here is an example:
 @end smallexample
 @end deftypefn
 
-These built-in functions are available for the PowerPC family of
+The following built-in functions are also available on all PowerPC
 processors:
 @smallexample
-float __builtin_recipdivf (float, float);
-float __builtin_rsqrtf (float);
-double __builtin_recipdiv (double, double);
-double __builtin_rsqrt (double);
 uint64_t __builtin_ppc_get_timebase ();
 unsigned long __builtin_ppc_mftb ();
-double __builtin_unpack_longdouble (long double, int);
-long double __builtin_pack_longdouble (double, double);
 @end smallexample
 
+The @code{__builtin_ppc_get_timebase} and @code{__builtin_ppc_mftb}
+functions generate instructi

Re: [PATCH] Warn for ignored ASM labels on typdef declarations

[Joseph Myers]

This patch is missing testcases, which need to be added to the testsuite 
for any such new feature, and when submitting a patch you should say 
explicitly in what configuration it was bootstrapped and tested without 
regressions.  Also, it's always incorrect to use -Wpedantic as the option 
controlling a warning that's not a warning about something not being part 
of the standard (since asm specifiers aren't part of the standard at all, 
it's thus wrong for -Wpedantic to control any diagnostic about them other 
than for them being used at all).

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

Re: [PATCH][AArch64] PR target/85512: Tighten SIMD right shift immediate constraints

[Jakub Jelinek]

On Tue, Apr 24, 2018 at 05:22:15PM +0100, Kyrill Tkachov wrote:
> I've cleaned up the testcase a bit to leave only the function that generates 
> the invalid instruction,
> making it shorter.
> 
> Jakub, is the patch ok to go in for GCC 8 from your perspective?

The PR is marked P1 now, so sure, please commit this for GCC 8, the sooner
the better.  We have only one other P1 left.

The only thing I'm unsure about is whether you want to make the top of the
range 32 and 64 rather than just 31 and 63, after all the operand
predicate used there requires < 32 and < 64, and from middle-end's POV
shifts by 32 or 64 are undefined (unless SHIFT_COUNT_TRUNCATED, but
aarch64 defines it to
#define SHIFT_COUNT_TRUNCATED (!TARGET_SIMD)

So, using
(match_test "IN_RANGE (ival, 1, 31)")))
and
(match_test "IN_RANGE (ival, 1, 63)")))
would feel safer to me, but your call.

> > > 2018-04-24  Kyrylo Tkachov  
> > > 
> > >   PR target/85512
> > >   * config/aarch64/constraints.md (Usg, Usj): New constraints.
> > >   * config/aarch64/iterators.md (cmode_simd): New mode attribute.
> > >   * config/aarch64/aarch64.md (*aarch64_ashr_sisd_or_int_3):
> > >   Use the above on operand 2.  Reindent.
> > >   (*aarch64_lshr_sisd_or_int_3): Likewise.
> > > 
> > > 2018-04-24  Kyrylo Tkachov  
> > > 
> > >   PR target/85512
> > >   * gcc.dg/pr85512.c: New test.
> 


Jakub

Re: [PATCH] [PR c++/85437] accept static_casted ptrmem in constexpr

[Jason Merrill]

On Tue, Apr 24, 2018 at 12:31 PM, Nathan Sidwell  wrote:
> On 04/23/2018 01:19 PM, Jason Merrill wrote:
>>
>> On Fri, Apr 20, 2018, 12:52 PM Nathan Sidwell 
>
>> I have to change convert_ptrmem to always
>> expand the constant (into an OFFSET_TYPE) so that
>> initializer_constant_valid_p (used by reduced_constant_expression_p)
>> doesn't get confused by a zero-adjusting conversion of a ptrmem_cst.
>>
>>
>> Hmm, I'm nervous about this change.  Maybe teach r_c_e_p to handle this
>> case properly?
>
>
> Here's an updated patch.  We keep convert_ptrmem unchanged.  I didn't need
> to teach RCEP anything new, fortunately.  In cxx_eval_constant_expression I
> call cplus_expand_constant on the cases that we previously complained were
> reinterpret_casts.  This does seem somewhat ugly though.

Well, in such a static_cast we are no longer referring to a member of
the class type, so abandoning the more symbolic PTRMEM_CST seems
reasonable.

The patch looks good to me.

Jason

Re: [PATCH, rs6000] Improve Documentation of Built-In Functions Part 1

[Segher Boessenkool]

Hi!

On Tue, Apr 24, 2018 at 02:25:58PM -0500, Kelvin Nilsen wrote:
> > 4. Remove descriptions of built-in function that do not belong in this
> > section because the
> >    built-in functions are generic (not specific to PowerPC):
> > __builtin_fabsq,
> >    __builtin_copysignq, __builtin_infq, __builtin_huge_valq, __builtin_nanq,
> >    __builtin_nansq, __builtin_sqrtf128, __builtin_fmaf128.

Are these described in a generic place, then?  I don't see it?

> +@node Low-Level PowerPC Built-in Functions Available on all Targets
> +@subsubsection Low-Level PowerPC Built-in Functions Available on all Targets

"Targets" is not such a great name.  "Configurations", maybe?

>  CPU supports the Embedded ISA category.
>  @item cellbe
>  CPU has a CELL broadband engine.
> +@item darn
> +CPU supports the darn (deliver a random number) instruction.

"the @code{darn}" etc.

>  CPU has hardware transaction memory instructions.
>  @item htm-nosc
>  Kernel aborts hardware transactions when a syscall is made.
> +@item htm-no-suspend
> +CPU supports hardware transaction memory but does not support the
> +tsuspend. instruction.

"@code{tsuspend.} instruction"

> +The following functions require (@option{-mhard-float}),
> +(@option{-mpowerpc-gfxopt}), and (@option{-mpopcntb}) options.

Why the parentheses?  The text within parens is not an explanation of
something that came before, it's just part of the main sentence.

Similar in many places.

> +The @code{__builtin_darn} and @code{__builtin_darn_raw}
> +functions require a
> +64-bit environment supporting ISA 3.0 or later.
> +The @code{__builtin_darn} function provides a 64-bit conditioned
> +random number.  The @code{__builtin_darn_raw} function provides a
> +64-bit raw random number.  The @code{__builtin_darn_32} function
> +provides a 32-bit random number.

Is darn_32 conditioned or raw?  (I realise you didn't change this text :-) )

The rest looks great, thanks!  If you fix those details, and probably not
delete the q/f128 things yet, it is okay for trunk.

Cheers,


Segher

RE: [PATCH 1/2] x86/CET: Add -fcf-protection to STAGE4_CFLAGS

[Tsimbalist, Igor V]

> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of H.J. Lu
> Sent: Tuesday, April 24, 2018 7:08 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Tsimbalist, Igor V ; Uros Bizjak
> 
> Subject: [PATCH 1/2] x86/CET: Add -fcf-protection to STAGE4_CFLAGS
> 
> Since profiledbootstrap uses
> 
> STAGEfeedback_CFLAGS = $(STAGE4_CFLAGS) -fprofile-use
> 
> add
> 
> STAGE4_CFLAGS += -fcf-protection -mcet
> 
> to bootstrap-cet.mk to support profiledbootstrap with CET.
> 
>   PR bootstrap/85490
>   * bootstrap-cet.mk (STAGE4_CFLAGS): New.
> ---
>  config/bootstrap-cet.mk | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/config/bootstrap-cet.mk b/config/bootstrap-cet.mk
> index b5dee601a3f..6ef1ba279cd 100644
> --- a/config/bootstrap-cet.mk
> +++ b/config/bootstrap-cet.mk
> @@ -1,4 +1,5 @@
> -# This option enables -fcf-protection for stage2 and stage3.
> +# This option enables -fcf-protection for stage2, stage3 and stage4.
> 
>  STAGE2_CFLAGS += -fcf-protection
>  STAGE3_CFLAGS += -fcf-protection
> +STAGE4_CFLAGS += -fcf-protection
> --
> 2.14.3

OK.

Igor

RE: [PATCH 2/2] x86: Update __CET__ check

[Tsimbalist, Igor V]

> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of H.J. Lu
> Sent: Tuesday, April 24, 2018 7:08 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Tsimbalist, Igor V ; Uros Bizjak
> 
> Subject: [PATCH 2/2] x86: Update __CET__ check
> 
> __CET__ has been changed by revision 259522:
> 
> commit d59cfa9a4064339cf2bd2da828c4c133f13e57f0
> Author: hjl 
> Date:   Fri Apr 20 13:30:13 2018 +
> 
> Define __CET__ for -fcf-protection and remove -mibt
> 
> to
> 
> (__CET__ & 1) != 0: -fcf-protection=branch or -fcf-protection=full
> (__CET__ & 2) != 0: -fcf-protection=return or -fcf-protection=full
> 
> We should check (__CET__ & 2) != 0 for shadow stack.
> 
> libgcc/
> 
>   * config/i386/linux-unwind.h: Add (__CET__ & 2) != 0 check
>   when including "config/i386/shadow-stack-unwind.h".
> 
> libitm/
> 
>   * config/x86/sjlj.S (_ITM_beginTransaction): Add
>   (__CET__ & 2) != 0 check for shadow stack.
>   (GTM_longjmp): Likewise.
> ---
>  libgcc/config/i386/linux-unwind.h | 2 +-
>  libitm/config/x86/sjlj.S  | 8 
>  2 files changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/libgcc/config/i386/linux-unwind.h b/libgcc/config/i386/linux-
> unwind.h
> index f1f52334d8d..ea838e4e47b 100644
> --- a/libgcc/config/i386/linux-unwind.h
> +++ b/libgcc/config/i386/linux-unwind.h
> @@ -23,7 +23,7 @@ see the files COPYING3 and COPYING.RUNTIME
> respectively.  If not, see
>  .  */
> 
>  /* Unwind shadow stack for -fcf-protection -mshstk.  */
> -#if defined __SHSTK__ && defined __CET__
> +#if defined __SHSTK__ && defined __CET__ && (__CET__ & 2) != 0
>  # include "config/i386/shadow-stack-unwind.h"
>  #endif
> 
> diff --git a/libitm/config/x86/sjlj.S b/libitm/config/x86/sjlj.S
> index 2345b2f4ec4..e5cdbab48a7 100644
> --- a/libitm/config/x86/sjlj.S
> +++ b/libitm/config/x86/sjlj.S
> @@ -141,7 +141,7 @@ SYM(_ITM_beginTransaction):
>   movq%r15, -24(%rax)
>   xorq%rdx, %rdx
>   /* Save zero or shadow stack pointer in the new field.  */
> -#if defined(__SHSTK__) && defined(__CET__)
> +#if defined __SHSTK__ && defined __CET__ && (__CET__ & 2) != 0
>   rdsspq  %rdx
>  #endif
>   movq%rdx, -16(%rax)
> @@ -177,7 +177,7 @@ SYM(_ITM_beginTransaction):
>   movl%ebp, 20(%esp)
>   xorl%edx, %edx
>   /* Save zero or shadow stack pointer in the new field.  */
> -#if defined(__SHSTK__) && defined(__CET__)
> +#if defined __SHSTK__ && defined __CET__ && (__CET__ & 2) != 0
>   rdsspd  %edx
>  #endif
>   movl%edx, 24(%esp)
> @@ -221,7 +221,7 @@ SYM(GTM_longjmp):
>   cfi_offset(%rip, 64)
>   cfi_register(%rsp, %rcx)
>   movq%rcx, %rsp
> -#if defined(__SHSTK__) && defined(__CET__)
> +#if defined __SHSTK__ && defined __CET__ && (__CET__ & 2) != 0
>   /* Check if Shadow Stack is enabled.  */
>   xorq%rcx, %rcx
>   rdsspq  %rcx
> @@ -259,7 +259,7 @@ SYM(GTM_longjmp):
>   cfi_offset(%eip, 24)
>   cfi_register(%esp, %ecx)
>   movl%ecx, %esp
> -#if defined(__SHSTK__) && defined(__CET__)
> +#if defined __SHSTK__ && defined __CET__ && (__CET__ & 2) != 0
>   /* Check if Shadow Stack is enabled.  */
>   xorl%ecx, %ecx
>   rdsspd  %ecx
> --
> 2.14.3

OK.

Igor

[PATCH] rs6000: Fix __powikf2 and __abskf2 spelling

[Segher Boessenkool]

Both of these libfuncs had a "tkf" misspelling, which caused
gcc.target/powerpc/pr85456.c to fail (there is no test for __abskf2).

Committing to trunk.


Segher


2018-04-24  Segher Boessenkool  

* config/rs6000/rs6000.c (init_float128_ieee): Fix spelling mistakes
in __abskf2 and __powikf2.

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

diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 0c148cf..3777ecd 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -18493,8 +18493,8 @@ init_float128_ieee (machine_mode mode)
   set_optab_libfunc (smul_optab, mode, "__mulkf3");
   set_optab_libfunc (sdiv_optab, mode, "__divkf3");
   set_optab_libfunc (sqrt_optab, mode, "__sqrtkf2");
-  set_optab_libfunc (abs_optab, mode, "__abstkf2");
-  set_optab_libfunc (powi_optab, mode, "__powitkf2");
+  set_optab_libfunc (abs_optab, mode, "__abskf2");
+  set_optab_libfunc (powi_optab, mode, "__powikf2");
 
   set_optab_libfunc (eq_optab, mode, "__eqkf2");
   set_optab_libfunc (ne_optab, mode, "__nekf2");
-- 
1.8.3.1

[Committed] PR fortran/85520 -- check for negative length

[Steve Kargl]

I've committed the attached patch after checking that
it does not cause any regression and that it fixes the
problem in the PR.  The patch checks for a negative
string length, and resets it to 0 if it is < 0.

2018-04-24  Steven G. Kargl  

PR fortran/85520
* decl.c (gfc_match_char_spec): Check for negative length and set to 0.

2018-04-24  Steven G. Kargl  

PR fortran/85520
* gfortran.dg/pr85520.f90: New test.

-- 
Steve
Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c	(revision 259619)
+++ gcc/fortran/decl.c	(working copy)
@@ -3235,7 +3249,11 @@ done:
 	  e = gfc_copy_expr (len);
 	  gfc_reduce_init_expr (e);
 	  if (e->expr_type == EXPR_CONSTANT)
-	gfc_replace_expr (len, e);
+	{
+	  gfc_replace_expr (len, e);
+	  if (mpz_cmp_si (len->value.integer, 0) < 0)
+		mpz_set_ui (len->value.integer, 0);
+	}
 	  else
 	gfc_free_expr (e);
 	  cl->length = len;
Index: gcc/testsuite/gfortran.dg/pr85520.f90
===
--- gcc/testsuite/gfortran.dg/pr85520.f90	(nonexistent)
+++ gcc/testsuite/gfortran.dg/pr85520.f90	(working copy)
@@ -0,0 +1,7 @@
+! { dg-do run }
+! PR fortran/85520
+! Original code from Gerhard Steinmetz 
+program p
+   character(-huge(1)) :: c = ' '
+if (len(c) /= 0) stop 1
+end