[C++ Patch ping] Bunch of location improvements

[Paolo Carlini]

Hi,

On 02/09/19 16:28, Paolo Carlini wrote:

Hi,

all should be more or less straightforward. I also propose to use an 
additional range for that error message about constinit && constexpr 
mentioned to Marek a few days ago. Tested x86_64-linux.


I'm gently piniging this very early because the first time I forgot to 
add the C++ Patch tag.


    https://gcc.gnu.org/ml/gcc-patches/2019-09/msg00063.html

Cheers, Paolo.

Re: [PATCH] PR tree-optimization/90836 Missing popcount pattern matching

[Richard Biener]

On Fri, Sep 6, 2019 at 2:13 PM Wilco Dijkstra  wrote:
>
> Hi,
>
> +(simplify
> +  (convert
> +(rshift
> +  (mult
>
> > is the outer convert really necessary?  That is, if we change
> > the simplification result to
>
> Indeed that should be "convert?" to make it optional.

Rather drop it, a generated conversion should be elided by
conversion simplification.

> > Is the Hamming weight popcount
> > faster than the libgcc table-based approach?  I wonder if we really
> > need to restrict this conversion to the case where the target
> > has an expander.
>
> Well libgcc uses the exact same sequence (not a table):
>
> objdump -d ./aarch64-unknown-linux-gnu/libgcc/_popcountsi2.o
>
>  <__popcountdi2>:
>0:   d341fc01lsr x1, x0, #1
>4:   b200c3e3mov x3, #0x101010101010101  // 
> #72340172838076673
>8:   9200f021and x1, x1, #0x
>c:   cb010001sub x1, x0, x1
>   10:   9200e422and x2, x1, #0x
>   14:   d342fc21lsr x1, x1, #2
>   18:   9200e421and x1, x1, #0x
>   1c:   8b010041add x1, x2, x1
>   20:   8b411021add x1, x1, x1, lsr #4
>   24:   9200cc20and x0, x1, #0xf0f0f0f0f0f0f0f
>   28:   9b037c00mul x0, x0, x3
>   2c:   d378fc00lsr x0, x0, #56
>   30:   d65f03c0ret
>
> So if you don't check for an expander you get an endless loop in libgcc since
> the makefile doesn't appear to use -fno-builtin anywhere...

Hm, must be aarch specific.  But indeed it should use -fno-builtin ...

Richard.

>
> Wilco
>

Re: libgo: Update to Go 1.13beta1 release

[Rainer Orth]

Hi Ian,

> I've committed a patch to update libgo to the Go 1.13beta1 release.
> As is usual with these updates, the patch is too large to include
> here; I've included the diffs of the various GCC-specific configury
> and other files.  Bootstrapped and ran Go testsuite on
> x86_64-pc-linux-gnu.  Committed to mainline.

this patch caused quite some fallout on Solaris, both SPARC and x86:

* The golang.org/x/net/lif package won't build:

make[4]: *** No rule to make target 'golang.org/x/net/lif.gox', needed by 
'net.lo'.  Stop.

  It moved from go/internal/x/net/lif/lif.go to
  go/golang.org/x/net/lif/lif.go, but neither was Makefile.am adapted to
  reflect this nor the Solaris fixes in the old version carried over to
  the new location.

* go/runtime/os_solaris.go doesn't compile:

/vol/gcc/src/hg/trunk/local/libgo/go/runtime/os_solaris.go:34:7: error: 
reference to undefined field or method ‘mos’
   34 |  if mp.mos.waitsema != 0 {
  |   ^

  and several more instances.  Caused by losing the explict mos member
  of m in go/runtime/runtime2.go, fixed by dropping it here, to.

* As Bernd mentioned, go/golang.org/x/sys/cpu/cpu_gccgo.{c, go} don't
  compile on non-x86 systems due to lack of .  Fixed by
  restricting to 386 or amd64 and wrapping the C code in __i386__ ||
  __x86_64__.

* The go/golang.org/x/sys/cpu package doesn't compile on SPARC:

/vol/gcc/src/hg/trunk/local/libgo/go/golang.org/x/sys/cpu/cpu.go:17:30: error: 
reference to undefined name 'cacheLineSize'
   17 | type CacheLinePad struct{ _ [cacheLineSize]byte }
  |  ^
make[8]: *** [Makefile:2826: golang.org/x/sys/cpu.lo] Error 1

  For the moment, I've worked around this by introducing cpu_sparcx.go
  with appropriate build tags.  However, I'm uncertain what do do about
  the actual value of cacheLineSize: the L1 D$ size is 16 on
  UltraSPARC-T2, but 32 on SPARC-S7.

With the attached patch, I can now bootstrap mainline on both
i386-pc-solaris2.11 and sparc-sun-solaris2.11.  Test results are similar
to pre-1.13, but I'll have to check further.  One thing that's new on
both sparc and x86 is an ICE compiling internal/poll:

go1: internal compiler error: in bind_field_or_method, at 
go/gofrontend/types.cc:11878
0x56d3df Type::bind_field_or_method(Gogo*, Type const*, Expression*, 
std::__cxx11::basic_string, std::allocator > 
const&, Location)
/vol/gcc/src/hg/trunk/local/gcc/go/gofrontend/types.cc:11878
0x4d2dcf Selector_expression::do_lower(Gogo*, Named_object*, 
Statement_inserter*, int)
/vol/gcc/src/hg/trunk/local/gcc/go/gofrontend/expressions.cc:14403
[...]

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University


# HG changeset patch
# Parent  cc2b98a3fc293d157b70a090c69a78d264801762
Fix libgo 1.13beta1 compilation on Solaris

diff --git a/libgo/Makefile.am b/libgo/Makefile.am
--- a/libgo/Makefile.am
+++ b/libgo/Makefile.am
@@ -1055,9 +1055,9 @@ endif
 
 if LIBGO_IS_SOLARIS
 
-# Build internal/x/net/lif only on Solaris systems.
+# Build golang.org/x/net/lif only on Solaris systems.
 
-$(eval $(call PACKAGE_template,internal/x/net/lif))
+$(eval $(call PACKAGE_template,golang.org/x/net/lif))
 
 golangorg_x_net_lif_lo = \
 	golang.org/x/net/lif.lo
diff --git a/libgo/go/golang.org/x/net/lif/address_test.go b/libgo/go/golang.org/x/net/lif/address_test.go
new file mode 100644
--- /dev/null
+++ b/libgo/go/golang.org/x/net/lif/address_test.go
@@ -0,0 +1,123 @@
+// Copyright 2016 The Go Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style
+// license that can be found in the LICENSE file.
+
+// +build solaris
+
+package lif
+
+import (
+	"fmt"
+	"testing"
+)
+
+type addrFamily int
+
+func (af addrFamily) String() string {
+	switch af {
+	case sysAF_UNSPEC:
+		return "unspec"
+	case sysAF_INET:
+		return "inet4"
+	case sysAF_INET6:
+		return "inet6"
+	default:
+		return fmt.Sprintf("%d", af)
+	}
+}
+
+const hexDigit = "0123456789abcdef"
+
+type llAddr []byte
+
+func (a llAddr) String() string {
+	if len(a) == 0 {
+		return ""
+	}
+	buf := make([]byte, 0, len(a)*3-1)
+	for i, b := range a {
+		if i > 0 {
+			buf = append(buf, ':')
+		}
+		buf = append(buf, hexDigit[b>>4])
+		buf = append(buf, hexDigit[b&0xF])
+	}
+	return string(buf)
+}
+
+type ipAddr []byte
+
+func (a ipAddr) String() string {
+	if len(a) == 0 {
+		return ""
+	}
+	if len(a) == 4 {
+		return fmt.Sprintf("%d.%d.%d.%d", a[0], a[1], a[2], a[3])
+	}
+	if len(a) == 16 {
+		return fmt.Sprintf("%02x%02x:%02x%02x:%02x%02x:%02x%02x:%02x%02x:%02x%02x:%02x%02x:%02x%02x", a[0], a[1], a[2], a[3], a[4], a[5], a[6], a[7], a[8], a[9], a[10], a[11], a[12], a[13], a[14], a[15])
+	}
+	s := make([]byte, len(a)*2)
+	for i, tn := range a {
+		s[i*2], s[i*2+1] = hexDigit[tn>>4], hexDigit[tn&0xf]
+	}
+	return string(s)
+}
+
+func (a *Inet4Addr) String() string {
+	return fmt.Sprintf("(%s %s %d)", addrFamily(a.Family()), ipA

Re: [PATCH] Use type alignment in get_builtin_sync_mem

[Richard Biener]

On Fri, Sep 6, 2019 at 3:00 PM Ulrich Weigand  wrote:
>
> Richard Biener wrote:
> > On Tue, Sep 3, 2019 at 3:09 PM Ulrich Weigand  wrote:
> > > > If you read the C standards fine-print then yes.  But people (or
> > > > even the C frontend!) hardly get that correct since for example
> > > > for
> > > >
> > > > struct __attribute__((packed)) { int i; } s;
> > > >
> > > > void foo ()
> > > > {
> > > >   __builtin_printf ("%p", &s.i);
> > > > }
> > > >
> > > > the C fronted actually creates a int * typed pointer for the ADDR_EXPR
> > > > (and not an int * variant with 1-byte alignment).  And people use
> > > > int * to pass such pointers everywhere.
> > >
> > > Well ... I'd say if you cast to int * and then use an atomic operation,
> > > it's your own fault that it fails :-/   If the frontend itself uses
> > > the wrong type, that is of course a problem.
> >
> > Yes.  The C standard says that if you cast something to a pointer type
> > the pointer has to be aligned according to the pointed-to type, otherwise
> > undefined.  But we have no chance to use this because of this kind of
> > issues (and of course developer laziness...).
>
> But as far as I can see, for *atomic* operations at least, we do make
> that assumption.  The x86 back-end for example just assumes that any
> "int" or "long" object that is the target of an atomic operation is
> naturally aligned, or else the generated code would just crash.   So
> if you used your example with a packed struct and passed that pointer
> to an atomic, the back-end would still assume the alignment and the
> code would crash.  But I'd still consider this a perfectly reasonable
> and expected behavior in this case ...

Would it crash?  I think it would be not atomic if it crossed a cache-line
boundary.

> The only thing that is special on s390 is that for the 16-byte integer
> type, the "natural" (mode) alignment is only 8 bytes, but for atomics
> we require 16 bytes.  But if you explicitly use a 16-byte aligned
> pointer type to assert to the compiler that this object *is* aligned,
> the compiler should be able to rely on that.
>
> Of course if some part of the middle end get the alignment wrong, we
> have a problem.  But I'm not sure how this could happen here.  I agree
> that it might be the case that a user-specified *under*-alignment might
> get lost somewhere (e.g. you have a packed int and somewhere in the
> optimizers this gets accidentally cast to a normal int with the default
> alignment).  But in *this* case, what would have to happen is that the
> middle-end accidentally casts something to a pointer with *higher*
> than the default alignment for the type, even though no such pointer
> cast is present in the source.  Can this really happen?

If the cast to the lower-aligned type is lost and there is an earlier cast
to the aligned type.

So - I don't see how this cannot happen.  Will it be likely?  Probably
not.

> > I'm not sure how it is done now but IIRC the users
> > use __atomic_load (ptr) and then the frontend changes that
> > to one of BUILT_IN_ATOMIC_LOAD_{N,1,2,4,8,16} based on
> > some criteria (size mainly).  I'm saying we should factor in
> > alignment here, _not_ using say BUILT_IN_ATOMIC_LOAD_16
> > if according to the C standard the data isn't aligned.  Maybe we can
> > ask the target whether the alignment according to C matches the
> > requirement for _16 expansion.  And if things are not fine
> > the FE should instead use BUILT_IN_ATOMIC_LOAD_N
> > which we later if the compiler can prove bigger alignment and N
> > is constant could expand as one of the others.
> >
> > But safety first.
>
> The problem with using the _N variant is that we then get a call
> to the _n version of the library routine, right?

Yes.

> This would actually
> be wrong on s390.  The problem is that all atomic operations on any
> one single object need to be consistent: they either all use the
> 16-byte atomic instruction, or else they all protect the access with
> a lock.  If you have parts of the code use the lock and other parts
> use the instruction, they're not actually protected against each other.

But then the user has to be consistent in accessing the object
atomically.  If he accesses it once as (aligned_int128_t *)
and once as (int128_t *) it's his fault, no?

If we'd document that the user invokes undefined behavior
when performing __builtin_atomic () on objects that are not
sufficiently aligned according to target specific needs then
we are of course fine and should simply assume the memory
is aligned accordingly (similar to your patch but probably with
some target hook specifying the atomic alignment requirement
when it differs from mode alignment).  But I don't read the
documentation of our atomic builtins that way.

Does _Atomic __int128_t work properly on s390?

> This is why the _16 version of the library routine does the runtime
> alignment check, so that all accesses to actually 16-byte aligned
> objects use the instruction, both in the library and

Re: [ARM/FDPIC v5 20/21] [ARM][testsuite] FDPIC: Skip tests using architectures unsupported by FDPIC

[Christophe Lyon]

On Fri, 6 Sep 2019 at 19:43, Christophe Lyon  wrote:
>
> On Fri, 6 Sep 2019 at 11:09, Christophe Lyon  
> wrote:
> >
> > On Fri, 6 Sep 2019 at 10:28, Kyrill Tkachov  
> > wrote:
> > >
> > >
> > > On 9/6/19 9:01 AM, Christophe Lyon wrote:
> > > > On Fri, 19 Jul 2019 at 11:00, Kyrill Tkachov
> > > >  wrote:
> > > >>
> > > >> On 5/15/19 1:39 PM, Christophe Lyon wrote:
> > > >>> Since FDPIC currently supports arm and thumb-2 modes only, these tests
> > > >>> fail because they enforce an architecture version that doesn't match
> > > >>> these restrictions.
> > > >>>
> > > >>> This patch introduces new values for the arm_arch effective-target
> > > >>> (v4t_thumb, v5t_thumb, v5te_thumb, v6_thumb, v6k_thumb, v6z_thumb) as
> > > >>> needed, and adds them to the relevant tests.  It also adds the
> > > >>> corresponding non-thumb effective-target to the tests that were
> > > >>> missing it.
> > > >>>
> > > >>> 2019-XX-XX  Christophe Lyon  
> > > >>>
> > > >>>  * lib/target-supports.exp
> > > >>>  (check_effective_target_arm_arch_FUNC_ok): Add v4t_thumb,
> > > >>>  v5t_thumb, v5te_thumb, v6_thumb, v6k_thumb, v6z_thumb.
> > > >>>  * gcc.target/arm/armv6-unaligned-load-ice.c: Add arm_arch
> > > >>>  effective-target.
> > > >>>  * gcc.target/arm/attr-unaligned-load-ice.c: Likewise.
> > > >>>  * gcc.target/arm/attr_arm-err.c: Likewise.
> > > >>>  * gcc.target/arm/ftest-armv4-arm.c: Likewise.
> > > >>>  * gcc.target/arm/ftest-armv4t-arm.c: Likewise.
> > > >>>  * gcc.target/arm/ftest-armv4t-thumb.c: Likewise.
> > > >>>  * gcc.target/arm/ftest-armv5t-arm.c: Likewise.
> > > >>>  * gcc.target/arm/ftest-armv5t-thumb.c: Likewise.
> > > >>>  * gcc.target/arm/ftest-armv5te-arm.c: Likewise.
> > > >>>  * gcc.target/arm/ftest-armv5te-thumb.c: Likewise.
> > > >>>  * gcc.target/arm/ftest-armv6-arm.c: Likewise.
> > > >>>  * gcc.target/arm/ftest-armv6-thumb.c: Likewise.
> > > >>>  * gcc.target/arm/ftest-armv6k-arm.c: Likewise.
> > > >>>  * gcc.target/arm/ftest-armv6k-thumb.c: Likewise.
> > > >>>  * gcc.target/arm/ftest-armv6m-thumb.c: Likewise.
> > > >>>  * gcc.target/arm/ftest-armv6t2-arm.c: Likewise.
> > > >>>  * gcc.target/arm/ftest-armv6t2-thumb.c: Likewise.
> > > >>>  * gcc.target/arm/ftest-armv6z-arm.c: Likewise.
> > > >>>  * gcc.target/arm/ftest-armv6z-thumb.c: Likewise.
> > > >>>  * gcc.target/arm/g2.c: Likewise.
> > > >>>  * gcc.target/arm/macro_defs1.c: Likewise.
> > > >>>  * gcc.target/arm/pr59858.c: Likewise.
> > > >>>  * gcc.target/arm/pr65647-2.c: Likewise.
> > > >>>  * gcc.target/arm/pr79058.c: Likewise.
> > > >>>  * gcc.target/arm/pr83712.c: Likewise.
> > > >>>  * gcc.target/arm/pragma_arch_switch_2.c: Likewise.
> > > >>>  * gcc.target/arm/scd42-1.c: Likewise.
> > > >>>  * gcc.target/arm/scd42-2.c: Likewise.
> > > >>>  * gcc.target/arm/scd42-3.c: Likewise.
> > > >>>  * gcc.c-torture/compile/pr82096.c: Fix arm_arch 
> > > >>> effective-target.
> > > >>>
> > > >> Ok.
> > > >>
> > > >> This looks like a good improvement on its own.
> > > >>
> > > > Sigh, after more testing I found problems :(
> > > >
> > > >> Thanks,
> > > >>
> > > >> Kyrill
> > > >>
> > > >>
> > > >>
> > > >>> Change-Id: I0845b262b241026561cc52a19ff8bb1659675e49
> > > >>>
> > > >>> diff --git a/gcc/testsuite/gcc.c-torture/compile/pr82096.c
> > > >>> b/gcc/testsuite/gcc.c-torture/compile/pr82096.c
> > > >>> index d144b70..4e695cd 100644
> > > >>> --- a/gcc/testsuite/gcc.c-torture/compile/pr82096.c
> > > >>> +++ b/gcc/testsuite/gcc.c-torture/compile/pr82096.c
> > > >>> @@ -1,4 +1,4 @@
> > > >>> -/* { dg-require-effective-target arm_arch_v5t_ok { target arm*-*-* } 
> > > >>> } */
> > > >>> +/* { dg-require-effective-target arm_arch_v5t_thumb_ok { target
> > > >>> arm*-*-* } } */
> > > >>>   /* { dg-skip-if "Do not combine float-abi values" { arm*-*-* } {
> > > >>> "-mfloat-abi=*" } { "-mfloat-abi=soft" } } */
> > > >>>   /* { dg-additional-options "-march=armv5t -mthumb -mfloat-abi=soft" 
> > > >>> {
> > > >>> target arm*-*-* } } */
> > > >>>
> > > >>> diff --git a/gcc/testsuite/gcc.target/arm/armv6-unaligned-load-ice.c
> > > >>> b/gcc/testsuite/gcc.target/arm/armv6-unaligned-load-ice.c
> > > >>> index 88528f1..886a012 100644
> > > >>> --- a/gcc/testsuite/gcc.target/arm/armv6-unaligned-load-ice.c
> > > >>> +++ b/gcc/testsuite/gcc.target/arm/armv6-unaligned-load-ice.c
> > > >>> @@ -1,6 +1,7 @@
> > > >>>   /* { dg-do compile } */
> > > >>>   /* { dg-skip-if "avoid conflicting multilib options" { *-*-* } {
> > > >>> "-march=*" } { "-march=armv6k" } } */
> > > >>>   /* { dg-skip-if "avoid conflicting multilib options" { *-*-* } {
> > > >>> "-marm" } { "" } } */
> > > >>> +/* { dg-require-effective-target arm_arch_v6k_thumb_ok } */
> > > >>>   /* { dg-options "-mthumb -Os -mfloat-abi=softfp" } */

[PATCH V3] Extend IPA-CP to support arithmetically-computed value-passing on by-ref argument (PR ipa/91682))

[Feng Xue OS]

Made some changes.

Feng
---
diff --git a/gcc/ipa-cp.c b/gcc/ipa-cp.c
index 33d52fe5537..f218f1093b8 100644
--- a/gcc/ipa-cp.c
+++ b/gcc/ipa-cp.c
@@ -1244,23 +1244,23 @@ initialize_node_lattices (struct cgraph_node *node)
   }
 }
 
-/* Return the result of a (possibly arithmetic) pass through jump function
-   JFUNC on the constant value INPUT.  RES_TYPE is the type of the parameter
-   to which the result is passed.  Return NULL_TREE if that cannot be
-   determined or be considered an interprocedural invariant.  */
+/* Return the result of a (possibly arithmetic) operation on the constant
+   value INPUT.  OPERAND is 2nd operand for binary operation.  RES_TYPE is
+   the type of the parameter to which the result is passed.  Return
+   NULL_TREE if that cannot be determined or be considered an
+   interprocedural invariant.  */
 
 static tree
-ipa_get_jf_pass_through_result (struct ipa_jump_func *jfunc, tree input,
-   tree res_type)
+ipa_get_jf_arith_result (enum tree_code opcode, tree input, tree operand,
+tree res_type)
 {
   tree res;
 
-  if (ipa_get_jf_pass_through_operation (jfunc) == NOP_EXPR)
+  if (opcode == NOP_EXPR)
 return input;
   if (!is_gimple_ip_invariant (input))
 return NULL_TREE;
 
-  tree_code opcode = ipa_get_jf_pass_through_operation (jfunc);
   if (!res_type)
 {
   if (TREE_CODE_CLASS (opcode) == tcc_comparison)
@@ -1274,8 +1274,7 @@ ipa_get_jf_pass_through_result (struct ipa_jump_func 
*jfunc, tree input,
   if (TREE_CODE_CLASS (opcode) == tcc_unary)
 res = fold_unary (opcode, res_type, input);
   else
-res = fold_binary (opcode, res_type, input,
-  ipa_get_jf_pass_through_operand (jfunc));
+res = fold_binary (opcode, res_type, input, operand);
 
   if (res && !is_gimple_ip_invariant (res))
 return NULL_TREE;
@@ -1283,6 +1282,21 @@ ipa_get_jf_pass_through_result (struct ipa_jump_func 
*jfunc, tree input,
   return res;
 }
 
+/* Return the result of a (possibly arithmetic) pass through jump function
+   JFUNC on the constant value INPUT.  RES_TYPE is the type of the parameter
+   to which the result is passed.  Return NULL_TREE if that cannot be
+   determined or be considered an interprocedural invariant.  */
+
+static tree
+ipa_get_jf_pass_through_result (struct ipa_jump_func *jfunc, tree input,
+   tree res_type)
+{
+  return ipa_get_jf_arith_result (ipa_get_jf_pass_through_operation (jfunc),
+ input,
+ ipa_get_jf_pass_through_operand (jfunc),
+ res_type);
+}
+
 /* Return the result of an ancestor jump function JFUNC on the constant value
INPUT.  Return NULL_TREE if that cannot be determined.  */
 
@@ -1416,6 +1430,146 @@ ipa_context_from_jfunc (ipa_node_params *info, 
cgraph_edge *cs, int csidx,
   return ctx;
 }
 
+/* See if NODE is a clone with a known aggregate value at a given OFFSET of a
+   parameter with the given INDEX.  */
+
+static tree
+get_clone_agg_value (struct cgraph_node *node, HOST_WIDE_INT offset,
+int index)
+{
+  struct ipa_agg_replacement_value *aggval;
+
+  aggval = ipa_get_agg_replacements_for_node (node);
+  while (aggval)
+{
+  if (aggval->offset == offset
+ && aggval->index == index)
+   return aggval->value;
+  aggval = aggval->next;
+}
+  return NULL_TREE;
+}
+
+/* Determine whether ITEM, jump function for an aggregate part, evaluates to a
+   single known constant value and if so, return it.  Otherwise return NULL.
+   NODE and INFO describes the caller node or the one it is inlined to, and
+   its related info.  */
+
+static tree
+ipa_agg_value_from_node (class ipa_node_params *info,
+struct cgraph_node *node,
+struct ipa_agg_jf_item *item)
+{
+  tree value = NULL_TREE;
+  int src_idx;
+
+  if (item->offset < 0 || item->jftype == IPA_JF_UNKNOWN)
+return NULL_TREE;
+
+  if (item->jftype == IPA_JF_CONST)
+return item->value.constant;
+
+  gcc_checking_assert (item->jftype == IPA_JF_PASS_THROUGH
+  || item->jftype == IPA_JF_LOAD_AGG);
+
+  src_idx = item->value.pass_through.formal_id;
+
+  if (info->ipcp_orig_node)
+{
+  if (item->jftype == IPA_JF_PASS_THROUGH)
+   value = info->known_csts[src_idx];
+  else
+   value = get_clone_agg_value (node, item->value.load_agg.offset,
+src_idx);
+}
+  else if (info->lattices)
+{
+  class ipcp_param_lattices *src_plats
+   = ipa_get_parm_lattices (info, src_idx);
+
+  if (item->jftype == IPA_JF_PASS_THROUGH)
+   {
+ struct ipcp_lattice *lat = &src_plats->itself;
+
+ if (!lat->is_single_const ())
+   return NULL_TREE;
+
+ value = lat->values->value;
+   }
+  else if (src_plats->aggs
+  && !src_plats->aggs_bottom
+ 

Re: [PATCH v3 1/9] Allow COND_EXPR and VEC_COND_EXPR condtions to trap

[Richard Biener]

On Fri, Sep 6, 2019 at 5:45 PM Ilya Leoshkevich  wrote:
>
> > Am 06.09.2019 um 13:07 schrieb Richard Biener :
> >
> > On Thu, Sep 5, 2019 at 1:10 PM Ilya Leoshkevich  wrote:
> >>
> >> Right now gimplifier does not allow VEC_COND_EXPR's condition to trap
> >> and introduces a temporary if this could happen, for example, generating
> >>
> >>  _5 = _4 > { 2.0e+0, 2.0e+0, 2.0e+0, 2.0e+0 };
> >>  _6 = VEC_COND_EXPR <_5, { -1, -1, -1, -1 }, { 0, 0, 0, 0 }>;
> >>
> >> from GENERIC
> >>
> >>  VEC_COND_EXPR < (*b > { 2.0e+0, 2.0e+0, 2.0e+0, 2.0e+0 }) ,
> >>  { -1, -1, -1, -1 } ,
> >>  { 0, 0, 0, 0 } >
> >>
> >> This is not necessary and makes the resulting GIMPLE harder to analyze.
> >> In particular, one of the next patches in series needs to get to
> >> VEC_COND_EXPR's comparison code, which is not possible when a temporary
> >> is introduced.
> >>
> >> This patch takes special care to avoid introducing trapping comparisons
> >> in GIMPLE_COND.  They are not allowed, because they would require 3
> >> outgoing edges (then, else and EH), which is awkward to say the least.
> >> Therefore, computations of such conditions should live in their own basic
> >> blocks.
> >
> > Comments inline (thanks for the work btw)
> >
> >> #endif /* GCC_GIMPLE_EXPR_H */
> >> diff --git a/gcc/gimple.c b/gcc/gimple.c
> >> index 633ef512a19..fd14fbec15e 100644
> >> --- a/gcc/gimple.c
> >> +++ b/gcc/gimple.c
> >> @@ -2144,6 +2144,8 @@ gimple_could_trap_p_1 (gimple *s, bool include_mem, 
> >> bool include_stores)
> >>   op = gimple_assign_rhs_code (s);
> >>   if (get_gimple_rhs_class (op) == GIMPLE_BINARY_RHS)
> >>div = gimple_assign_rhs2 (s);
> >> +  else if (op == COND_EXPR || op == VEC_COND_EXPR)
> >> +   op = TREE_CODE (gimple_assign_rhs1 (s));
> >
> > I think this is not correct since we can have
> >
> > int i = fp > 1. ? intval1 : intval2
> >
> > and thus FLOAT_TYPE_P (t)  is wrong.  You need to do
> >
> >  t = TREE_TYPE (op);
> >
> > as well I think.
>
> Doesn't this mean there is a problem with the existing logic too? If `s`
> is
>
> int i = fp > 1.;
>
> then
>
> t = gimple_expr_type (s);
>
> would give us BOOLEAN_TYPE instead of REAL_TYPE.

Yeah, that looks broken as well.

>
> Also, the new logic will probably be a bit more complicated, since I
> will first have to do:
>
> tree cond = gimple_assign_rhs1 (s);
>
> then see if `cond` is not e.g. an SSA_NAME, but rather a tcc_comparison,
> and only then
>
> t = TREE_TYPE (TREE_OPERAND (cond, 0))
>
> So I'd rather send a new version before merging this :-)

Fine with me ;)

Richard.

Re: [ARM/FDPIC v5 10/21] [ARM] FDPIC: Implement TLS support.

[Christophe Lyon]

On Wed, 4 Sep 2019 at 22:03, Christophe Lyon  wrote:
>
> On Wed, 4 Sep 2019 at 16:16, Kyrill Tkachov  
> wrote:
> >
> > Hi Christophe,
> >
> > On 5/15/19 1:39 PM, Christophe Lyon wrote:
> > > Support additional relocations: TLS_GD32_FDPIC, TLS_LDM32_FDPIC, and
> > > TLS_IE32_FDPIC.
> > >
> > > We do not support the GNU2 TLS dialect.
> > >
> > > 2019-XX-XX  Christophe Lyon  
> > > Mickaël Guêné 
> > >
> > > gcc/
> > > * config/arm/arm.c (tls_reloc): Add TLS_GD32_FDPIC,
> > > TLS_LDM32_FDPIC and TLS_IE32_FDPIC.
> > > (arm_call_tls_get_addr): Add FDPIC support.
> > > (legitimize_tls_address): Likewise.
> > > (arm_emit_tls_decoration): Likewise.
> > >
> > > Change-Id: I4ea5034ff654540c4658d0a79fb92f70550cdf4a
> > >
> > > diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
> > > index 99d13bf..5fc7a20 100644
> > > --- a/gcc/config/arm/arm.c
> > > +++ b/gcc/config/arm/arm.c
> > > @@ -2379,9 +2379,12 @@ char arm_arch_name[] = "__ARM_ARCH_PROFILE__";
> > >
> > >  enum tls_reloc {
> > >TLS_GD32,
> > > +  TLS_GD32_FDPIC,
> > >TLS_LDM32,
> > > +  TLS_LDM32_FDPIC,
> > >TLS_LDO32,
> > >TLS_IE32,
> > > +  TLS_IE32_FDPIC,
> > >TLS_LE32,
> > >TLS_DESCSEQ  /* GNU scheme */
> > >  };
> > > @@ -8760,20 +8763,34 @@ arm_call_tls_get_addr (rtx x, rtx reg, rtx
> > > *valuep, int reloc)
> > >gcc_assert (reloc != TLS_DESCSEQ);
> > >start_sequence ();
> > >
> > > -  labelno = GEN_INT (pic_labelno++);
> > > -  label = gen_rtx_UNSPEC (Pmode, gen_rtvec (1, labelno),
> > > UNSPEC_PIC_LABEL);
> > > -  label = gen_rtx_CONST (VOIDmode, label);
> > > +  if (TARGET_FDPIC)
> > > +{
> > > +  sum = gen_rtx_UNSPEC (Pmode,
> > > +   gen_rtvec (2, x, GEN_INT (reloc)),
> > > +   UNSPEC_TLS);
> > > +}
> > > +  else
> > > +{
> > > +  labelno = GEN_INT (pic_labelno++);
> > > +  label = gen_rtx_UNSPEC (Pmode, gen_rtvec (1, labelno),
> > > UNSPEC_PIC_LABEL);
> > > +  label = gen_rtx_CONST (VOIDmode, label);
> > >
> > > -  sum = gen_rtx_UNSPEC (Pmode,
> > > -   gen_rtvec (4, x, GEN_INT (reloc), label,
> > > -  GEN_INT (TARGET_ARM ? 8 : 4)),
> > > -   UNSPEC_TLS);
> > > +  sum = gen_rtx_UNSPEC (Pmode,
> > > +   gen_rtvec (4, x, GEN_INT (reloc), label,
> > > +  GEN_INT (TARGET_ARM ? 8 : 4)),
> > > +   UNSPEC_TLS);
> > > +}
> > >reg = load_tls_operand (sum, reg);
> > >
> > > -  if (TARGET_ARM)
> > > -emit_insn (gen_pic_add_dot_plus_eight (reg, reg, labelno));
> > > +  if (TARGET_FDPIC)
> > > +{
> > > +  emit_insn (gen_addsi3 (reg, reg, gen_rtx_REG (Pmode,
> > > FDPIC_REGNUM)));
> > > +}
> >
> > No {} around single statement.
> >
> > >else
> > > -emit_insn (gen_pic_add_dot_plus_four (reg, reg, labelno));
> > > +if (TARGET_ARM)
> > > +  emit_insn (gen_pic_add_dot_plus_eight (reg, reg, labelno));
> >
> >
> > Merge that "if" with the "else" in an "else if"
> >
> > > +else
> > > +  emit_insn (gen_pic_add_dot_plus_four (reg, reg, labelno));
> > >
> > >*valuep = emit_library_call_value (get_tls_get_addr (), NULL_RTX,
> > >   LCT_PURE, /* LCT_CONST?  */
> > > @@ -8808,6 +8825,7 @@ arm_tls_descseq_addr (rtx x, rtx reg)
> > >return reg;
> > >  }
> > >
> > > +
> > >  rtx
> > >  legitimize_tls_address (rtx x, rtx reg)
> > >  {
> > > @@ -8820,6 +8838,9 @@ legitimize_tls_address (rtx x, rtx reg)
> > >  case TLS_MODEL_GLOBAL_DYNAMIC:
> > >if (TARGET_GNU2_TLS)
> > >  {
> > > + if (TARGET_FDPIC)
> > > +   gcc_unreachable();
> > > +
> >
> > Use gcc_assert (TARGET_FDPIC)
> >
> >
> > >reg = arm_tls_descseq_addr (x, reg);
> > >
> > >tp = arm_load_tp (NULL_RTX);
> > > @@ -8829,7 +8850,10 @@ legitimize_tls_address (rtx x, rtx reg)
> > >else
> > >  {
> > >/* Original scheme */
> > > - insns = arm_call_tls_get_addr (x, reg, &ret, TLS_GD32);
> > > + if (TARGET_FDPIC)
> > > +   insns = arm_call_tls_get_addr (x, reg, &ret, TLS_GD32_FDPIC);
> > > + else
> > > +   insns = arm_call_tls_get_addr (x, reg, &ret, TLS_GD32);
> > >dest = gen_reg_rtx (Pmode);
> > >emit_libcall_block (insns, dest, ret, x);
> > >  }
> > > @@ -8838,6 +8862,9 @@ legitimize_tls_address (rtx x, rtx reg)
> > >  case TLS_MODEL_LOCAL_DYNAMIC:
> > >if (TARGET_GNU2_TLS)
> > >  {
> > > + if (TARGET_FDPIC)
> > > +   gcc_unreachable();
> > > +
> >
> > Likewise.
> >
> > Ok with those changes.
>
> Thanks, here is the updated version, with the initialization of labelno in
> call_tls_get_addr moved from patch 4/21.
>
There was an obvious mistake in the previous update: the attached
version inverts the assert condition to:

Re: [ARM/FDPIC v5 13/21] [ARM] FDPIC: Force LSB bit for PC in Cortex-M architecture

[Christophe Lyon]

On Thu, 5 Sep 2019 at 11:03, Kyrill Tkachov  wrote:
>
> Hi Christophe,
>
> On 9/5/19 9:30 AM, Christophe Lyon wrote:
> > On Thu, 29 Aug 2019 at 17:32, Kyrill Tkachov
> >  wrote:
> >> Hi Christophe,
> >>
> >> On 5/15/19 1:39 PM, Christophe Lyon wrote:
> >>> Without this, when we are unwinding across a signal frame we can jump
> >>> to an even address which leads to an exception.
> >>>
> >>> This is needed in __gnu_persnality_sigframe_fdpic() when restoring the
> >>> PC from the signal frame since the PC saved by the kernel has the LSB
> >>> bit set to zero.
> >>>
> >>> 2019-XX-XX  Christophe Lyon  
> >>>  Mickaël Guêné 
> >>>
> >>>  libgcc/
> >>>  * config/arm/unwind-arm.c (_Unwind_VRS_Set): Handle v7m
> >>>  architecture.
> >>>
> >>> Change-Id: Ie84de548226bcf1751e19a09e8f091fb3013ccea
> >>>
> >>> diff --git a/libgcc/config/arm/unwind-arm.c
> >>> b/libgcc/config/arm/unwind-arm.c
> >>> index 9ba73e7..ba47150 100644
> >>> --- a/libgcc/config/arm/unwind-arm.c
> >>> +++ b/libgcc/config/arm/unwind-arm.c
> >>> @@ -199,6 +199,11 @@ _Unwind_VRS_Result _Unwind_VRS_Set
> >>> (_Unwind_Context *context,
> >>>   return _UVRSR_FAILED;
> >>>
> >>> vrs->core.r[regno] = *(_uw *) valuep;
> >>> +#if defined(__ARM_ARCH_7M__)
> >>> +  /* Force LSB bit since we always run thumb code.  */
> >>> +  if (regno == 15)
> >>> +   vrs->core.r[regno] |= 1;
> >>> +#endif
> >> Hmm, this looks quite specific. There are other architectures that are
> >> thumb-only too (6-M, 7E-M etc).
> >>
> >> Would checking for __thumb__ be better?
> >>
> > Right.
> > The attached updated patch also uses R_PC instead of 15.
>
>
> Looks ok to me but we'll need to make sure this doesn't break non-FDPIC
> targets now.
>
> A bootstrap and test of an arm-none-linux-gnueabihf targeting thumb
> should do it.
>

Bootstrap of the whole series OK, modulo the problems with the tests
discussed in patch 20.
(some tests became unsupported on arm-linux-gnueabihf with thumb target)

Christophe

> Thanks,
>
> Kyrill
>
>
> >
> > Christophe
> >
> >> Thanks,
> >>
> >> Kyrill
> >>
> >>
> >>> return _UVRSR_OK;
> >>>
> >>>   case _UVRSC_VFP:
> >>> --
> >>> 2.6.3
> >>>

Re: [PATCH V6 01/11] Update config.sub and config.guess.

[Jose E. Marchesi]

* config.sub: Import upstream version 2019-06-30.
* config.guess: Import upstream version 2019-07-24.

Just installed this in svn trunk.

[PATCH] Fix up -funsigned-char behavior of _mm256_cmpgt_epi8 (PR target/91704)

[Jakub Jelinek]

Hi!

This PR is a repetition of PR87853, just for avx2 instead of sse2.
See https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00195.html
for the previous patch.

This time there is just one intrinsic with the problem (note, the previous
patch didn't have to change _mm_cmpeq_epi8, as __v16qi vs. __v16qs doesn't
make any difference for equality comparisons).

I've grepped for similar issues in other headers, including 512-byte
vectors, but couldn't find any, in those cases we use a builtin with a mask
argument.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk and
release branches?  I've also noticed PR87853 didn't come up with a testcase,
so that is also attached, ok to commit too?

As for tests, I chose not to do a dg-do run test with -funsigned-char,
because that option is an ABI change and when including some headers that
also include system headers one is never sure what will become of that.

2019-09-09  Jakub Jelinek  

PR target/91704
* config/i386/avxintrin.h (__v32qs): New typedef.
* config/i386/avx2intrin.h (_mm256_cmpgt_epi8): Use casts to __v32qs
instead of __v32qi.

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

--- gcc/config/i386/avxintrin.h.jj  2019-08-12 17:55:19.039139772 +0200
+++ gcc/config/i386/avxintrin.h 2019-09-08 23:22:11.829573162 +0200
@@ -47,6 +47,7 @@ typedef unsigned int __v8su __attribute_
 typedef short __v16hi __attribute__ ((__vector_size__ (32)));
 typedef unsigned short __v16hu __attribute__ ((__vector_size__ (32)));
 typedef char __v32qi __attribute__ ((__vector_size__ (32)));
+typedef signed char __v32qs __attribute__ ((__vector_size__ (32)));
 typedef unsigned char __v32qu __attribute__ ((__vector_size__ (32)));
 
 /* The Intel API is flexible enough that we must allow aliasing with other
--- gcc/config/i386/avx2intrin.h.jj 2019-01-01 12:37:32.000731417 +0100
+++ gcc/config/i386/avx2intrin.h2019-09-08 23:24:23.391560853 +0200
@@ -258,7 +258,7 @@ extern __inline __m256i
 __attribute__ ((__gnu_inline__, __always_inline__, __artificial__))
 _mm256_cmpgt_epi8 (__m256i __A, __m256i __B)
 {
-  return (__m256i) ((__v32qi)__A > (__v32qi)__B);
+  return (__m256i) ((__v32qs)__A > (__v32qs)__B);
 }
 
 extern __inline __m256i
--- gcc/testsuite/gcc.target/i386/pr91704.c.jj  2019-09-09 11:01:14.588282654 
+0200
+++ gcc/testsuite/gcc.target/i386/pr91704.c 2019-09-09 11:09:55.659355290 
+0200
@@ -0,0 +1,14 @@
+/* PR target/91704 */
+/* { dg-do compile } */
+/* { dg-options "-O2 -funsigned-char -mavx2 -mavx512f -masm=att" } */
+/* { dg-final { scan-assembler-times "\tvpcmpgtb\t%ymm" 1 } } */
+/* { dg-final { scan-assembler-not "\tvpsubusb\t" } } */
+/* { dg-final { scan-assembler-not "\tvpcmpeqb\t" } } */
+
+#include 
+
+__m256i
+foo (__m256i x, __m256i y)
+{
+  return _mm256_cmpgt_epi8 (x, y);
+}

Jakub
2019-09-09  Jakub Jelinek  

PR target/87853
* gcc.target/i386/pr87853.c: New test.

--- gcc/testsuite/gcc.target/i386/pr87853.c.jj  2019-09-09 11:00:43.984752380 
+0200
+++ gcc/testsuite/gcc.target/i386/pr87853.c 2019-09-09 11:03:14.580448353 
+0200
@@ -0,0 +1,20 @@
+/* PR target/87853 */
+/* { dg-do compile } */
+/* { dg-options "-O2 -funsigned-char -msse2 -mno-sse3 -masm=att" } */
+/* { dg-final { scan-assembler-times "\tpcmpgtb\t%xmm" 2 } } */
+/* { dg-final { scan-assembler-not "\tpsubusb\t" } } */
+/* { dg-final { scan-assembler-not "\tpcmpeqb\t" } } */
+
+#include 
+
+__m128i
+foo (__m128i x, __m128i y)
+{
+  return _mm_cmpgt_epi8 (x, y);
+}
+
+__m128i
+bar (__m128i x, __m128i y)
+{
+  return _mm_cmplt_epi8 (x, y);
+}

Re: [RFC][PATCH 1/X][libsanitizer] Introduce libsanitizer to GCC tree

[Martin Liška]

On 9/6/19 4:46 PM, Matthew Malcomson wrote:

Hello.

> We have taken the libsanitizer library from the same SVN revision as
> the other sanitizer libraries are taken from (SVN revision 345033 as
> mentioned in libsanitizer/MERGE).

Note that I updated the libsanitizer in the meantime to r368656. That said
I guess the patch does not correspond to what's the content of the newly
added hwasan/* files.

I would probably recommend to start with the change to merge.sh:
+merge lib/hwasan hwasan 

and then run the script to update to latest libsanitizer version.

Martin

Re: [RFC][PATCH 3/X][libsanitizer] Allow compilation for HWASAN_WITH_INTERCEPTORS=OFF

[Martin Liška]

On 9/6/19 4:46 PM, Matthew Malcomson wrote:
> This is a port of the LLVM-svn commit number 359914, it allows
> compilation of the library without using interceptors.

As mentioned in the previous email, the cherry-pick will not be
needed any longer.

Martin

Re: [RFC][PATCH 4/X][libsanitizer] Pass size and pointer info to error reporting functions

[Martin Liška]

On 9/6/19 4:46 PM, Matthew Malcomson wrote:
> This is taken from upstream LLVM (change made in LLVM svn commit
> 351730), but is not a direct cherry-pick of a commit since the commit
> does not apply cleanly.

As mentioned in the previous email, the cherry-pick will not be
needed any longer.

Martin

Re: We should mark "Should Span be Regular? P1085R2" as well.

[Jonathan Wakely]

On 06/09/19 18:08 -0400, Ed Smith-Rowland via libstdc++ wrote:

As the title says.

 was (correctly) delivered without comparison ops. so we chould 
check off p1085.


Indeed, thanks!


This includes the status updates for constexpr lib diffs posted previously.

I also regenerated the html (resulted in pure boiler except for 
manual/status.html).


The boilerplate change are a bit annoying, because next time I regen
the docs with the latest version I'll just flip it all back from
V1.79.1 to Vsnapshot again. That's a lot of noisy churn in the repo
for no benefit. Could you revert your local changes to all the HTML
files except for doc/html/manual/status.html ?

Or just kluge the string back to the current value by running
something like:

   find doc/html -name '*.html' | sed -i s/V1.79.1/Vsnapshot/

FWIW the unhelpful "Vsnapshot" string seems to be a bug in the 1.79.2
stylesheets:
https://lists.oasis-open.org/archives/docbook-apps/201612/msg00017.html
https://github.com/docbook/xslt10-stylesheets/issues/17

But I've been using V1.79.2 for nearly two years now (since r254078)
so we might as well stick with it now, at least until there's a newer
release of the stylesheets.

If you want to just check in the XML change and leave me to regen the
HTML later this week, that's also fine.

Re: [PATCH, libstdc++] Doc changes for constexpr additions for C++20 status.

[Jonathan Wakely]

On 05/09/19 15:45 -0400, Ed Smith-Rowland via libstdc++ wrote:
Here is a patch to the libstdc++ docs re constexpr additions. They 
reflect the latest macro assignments AFAICT.


Constexpr interator reqs are implemented in 9.1, the rest for 10.1.

Ok?

Should I bother adding the Constexpr interator requirements to the 
gcc-9 branch docs?


Yes please, it would be good to have that part in the gcc-9 docs. No
need to regen the HTML on the branch at this time though.

Thanks!

Re: [PATCH V6 02/11] opt-functions.awk: fix comparison of limit, begin and end

[Jose E. Marchesi]

The function integer_range_info makes sure that, if provided, the
initial value fills in the especified range.  However, it is necessary
to convert the values to a numerical context before comparing, to make
sure awk is using arithmetical order and not lexicographical order.

gcc/ChangeLog:

* opt-functions.awk (integer_range_info): Make sure values are in
numeric context before operating with them.

I just installed this in svn trunk.
Salud!

Re: [PATCH V6 03/11] testsuite: annotate c-torture/compile tests with dg-require-stack-size

[Jose E. Marchesi]

This patch annotates tests that make use of a significant a mount of
stack space.  Embedded and other restricted targets may have problems
compiling and running these tests.  Note that the annotations are in
many cases not exact.

As this implements a solution proposed by Jeff Law and I got no further
comments, I just installed it in its own commit in svn trunk.

Salud!

Re: [PATCH V6 04/11] testsuite: new require effective target indirect_calls

[Jose E. Marchesi]

This patch adds a new dg_require_effective_target procedure to the
testsuite infrastructure: indirect_calls.  This new function tells
whether a target supports calls to non-constant call targets.

This patch also annotates the tests in the gcc.c-torture testuite that
require support for indirect calls.

As this implements a solution proposed by a global maintainer and I
didn't get any further comments on it, I just installed it in its own
commit in svn trunk.

Salud!

Re: [RFC][PATCH 5/X][libsanitizer] Introduce longjmp/setjmp interceptors to libhwasan

[Martin Liška]

Hi.

On 9/6/19 4:46 PM, Matthew Malcomson wrote:
> Ensuring that the shadow stack is cleared on normal function exit will
> be done by adding instrumentation to the function epilogue through the
> compiler.
> longjmp and setjmp are some abnormal methods of exiting the function
> that can't be handled in the compiler since they can be called in
> uninstrumented code to unwind past instrumented function frames.

I'm curious why you are adding a new code that is not part of libsanitizer 
runtime?
Does it mean the current LLVM implementation does not properly handle setjmp and
longjmp?

Note that rule of thumb is that we need to upstream all libsanitizer
changes before we merge libsanitizer. We are doing that in order to not
have a bug difference against upstream libsanitizer.

Martin

Re: [RFC][PATCH 6/X][libsanitizer] Add -fsanitize=hwaddress flags

[Martin Liška]

On 9/6/19 4:46 PM, Matthew Malcomson wrote:
> This flag can't be used at the same time as any of the other sanitizers.
> We add an equivalent flag to -static-libasan in -static-libhwasan to
> ensure static linking.

Hello.

You're introducing new option argument -fsanitize=hwaddress. However,
clang is using 'hwasan':
https://github.com/llvm-mirror/clang/blob/master/lib/Driver/ToolChains/CommonArgs.cpp#L625

I would align it with the existing clang's option.

Thanks,
Martin

Re: [PATCH] Fix up -funsigned-char behavior of _mm256_cmpgt_epi8 (PR target/91704)

[Uros Bizjak]

On Mon, Sep 9, 2019 at 11:18 AM Jakub Jelinek  wrote:
>
> Hi!
>
> This PR is a repetition of PR87853, just for avx2 instead of sse2.
> See https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00195.html
> for the previous patch.
>
> This time there is just one intrinsic with the problem (note, the previous
> patch didn't have to change _mm_cmpeq_epi8, as __v16qi vs. __v16qs doesn't
> make any difference for equality comparisons).

Can you please change the above intrinsic back to __v16qi? IMO _mm and
__mm256 intrinsics should be consistent between each other as much as
possible.

> I've grepped for similar issues in other headers, including 512-byte
> vectors, but couldn't find any, in those cases we use a builtin with a mask
> argument.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk and
> release branches?  I've also noticed PR87853 didn't come up with a testcase,
> so that is also attached, ok to commit too?

Sure!

> As for tests, I chose not to do a dg-do run test with -funsigned-char,
> because that option is an ABI change and when including some headers that
> also include system headers one is never sure what will become of that.
>
> 2019-09-09  Jakub Jelinek  
>
> PR target/91704
> * config/i386/avxintrin.h (__v32qs): New typedef.
> * config/i386/avx2intrin.h (_mm256_cmpgt_epi8): Use casts to __v32qs
> instead of __v32qi.
>
> * gcc.target/i386/pr91704.c: New test.

OK.

Thanks,
Uros.

> --- gcc/config/i386/avxintrin.h.jj  2019-08-12 17:55:19.039139772 +0200
> +++ gcc/config/i386/avxintrin.h 2019-09-08 23:22:11.829573162 +0200
> @@ -47,6 +47,7 @@ typedef unsigned int __v8su __attribute_
>  typedef short __v16hi __attribute__ ((__vector_size__ (32)));
>  typedef unsigned short __v16hu __attribute__ ((__vector_size__ (32)));
>  typedef char __v32qi __attribute__ ((__vector_size__ (32)));
> +typedef signed char __v32qs __attribute__ ((__vector_size__ (32)));
>  typedef unsigned char __v32qu __attribute__ ((__vector_size__ (32)));
>
>  /* The Intel API is flexible enough that we must allow aliasing with other
> --- gcc/config/i386/avx2intrin.h.jj 2019-01-01 12:37:32.000731417 +0100
> +++ gcc/config/i386/avx2intrin.h2019-09-08 23:24:23.391560853 +0200
> @@ -258,7 +258,7 @@ extern __inline __m256i
>  __attribute__ ((__gnu_inline__, __always_inline__, __artificial__))
>  _mm256_cmpgt_epi8 (__m256i __A, __m256i __B)
>  {
> -  return (__m256i) ((__v32qi)__A > (__v32qi)__B);
> +  return (__m256i) ((__v32qs)__A > (__v32qs)__B);
>  }
>
>  extern __inline __m256i
> --- gcc/testsuite/gcc.target/i386/pr91704.c.jj  2019-09-09 11:01:14.588282654 
> +0200
> +++ gcc/testsuite/gcc.target/i386/pr91704.c 2019-09-09 11:09:55.659355290 
> +0200
> @@ -0,0 +1,14 @@
> +/* PR target/91704 */
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -funsigned-char -mavx2 -mavx512f -masm=att" } */
> +/* { dg-final { scan-assembler-times "\tvpcmpgtb\t%ymm" 1 } } */
> +/* { dg-final { scan-assembler-not "\tvpsubusb\t" } } */
> +/* { dg-final { scan-assembler-not "\tvpcmpeqb\t" } } */
> +
> +#include 
> +
> +__m256i
> +foo (__m256i x, __m256i y)
> +{
> +  return _mm256_cmpgt_epi8 (x, y);
> +}
>
> Jakub

Re: [RFC][PATCH 6/X][libsanitizer] Add -fsanitize=hwaddress flags

[Matthew Malcomson]

On 09/09/19 11:06, Martin Liška wrote:
> On 9/6/19 4:46 PM, Matthew Malcomson wrote:
>> This flag can't be used at the same time as any of the other sanitizers.
>> We add an equivalent flag to -static-libasan in -static-libhwasan to
>> ensure static linking.
> 
> Hello.
> 
> You're introducing new option argument -fsanitize=hwaddress. However,
> clang is using 'hwasan':
> https://github.com/llvm-mirror/clang/blob/master/lib/Driver/ToolChains/CommonArgs.cpp#L625
> 
> I would align it with the existing clang's option.
> 
> Thanks,
> Martin
> 

Hi there,

I don't believe that's where this particular option is defined.
I think it's here.
https://github.com/llvm-mirror/clang/blob/master/include/clang/Basic/Sanitizers.def#L53

I took the `hwaddress' argument from what my local build of clang accepted.

(Helpfully enough, finding that option also shows the option that clang 
uses for the AArch64 memtag extension, which I've been meaning to get 
around to finding for a while ;-] )

Cheers,
Matthew.

Re: [RFC][PATCH 6/X][libsanitizer] Add -fsanitize=hwaddress flags

[Martin Liška]

On 9/9/19 12:17 PM, Matthew Malcomson wrote:
> On 09/09/19 11:06, Martin Liška wrote:
>> On 9/6/19 4:46 PM, Matthew Malcomson wrote:
>>> This flag can't be used at the same time as any of the other sanitizers.
>>> We add an equivalent flag to -static-libasan in -static-libhwasan to
>>> ensure static linking.
>>
>> Hello.
>>
>> You're introducing new option argument -fsanitize=hwaddress. However,
>> clang is using 'hwasan':
>> https://github.com/llvm-mirror/clang/blob/master/lib/Driver/ToolChains/CommonArgs.cpp#L625
>>
>> I would align it with the existing clang's option.
>>
>> Thanks,
>> Martin
>>
> 
> Hi there,
> 
> I don't believe that's where this particular option is defined.
> I think it's here.
> https://github.com/llvm-mirror/clang/blob/master/include/clang/Basic/Sanitizers.def#L53

Ah, you are right. Sorry for the noise :)

Martin

> 
> I took the `hwaddress' argument from what my local build of clang accepted.
> 
> (Helpfully enough, finding that option also shows the option that clang 
> uses for the AArch64 memtag extension, which I've been meaning to get 
> around to finding for a while ;-] )
> 
> Cheers,
> Matthew.
> 

Re: [PATCH V6 05/11] bpf: new GCC port

[Jose E. Marchesi]

I think the bits are in good enough shape they can go in now.

I just committed the port to svn trunk, in a single commit, yay!

Many thanks to you, richard, seguer and the other reviewers for the
great feedback and suggestions.  What got committed is certainly WAY
better than what I submitted initially.

Now the real fun starts :))

Re: [RFC][PATCH 5/X][libsanitizer] Introduce longjmp/setjmp interceptors to libhwasan

[Matthew Malcomson]

On 09/09/19 11:01, Martin Liška wrote:
> Hi.
> 
> On 9/6/19 4:46 PM, Matthew Malcomson wrote:
>> Ensuring that the shadow stack is cleared on normal function exit will
>> be done by adding instrumentation to the function epilogue through the
>> compiler.
>> longjmp and setjmp are some abnormal methods of exiting the function
>> that can't be handled in the compiler since they can be called in
>> uninstrumented code to unwind past instrumented function frames.
> 
> I'm curious why you are adding a new code that is not part of libsanitizer 
> runtime?
> Does it mean the current LLVM implementation does not properly handle setjmp 
> and
> longjmp?

Honestly -- I'm not sure.

I did a basic test that seemed to show clang not supporting setjmp & 
longjmp and I made a bit of a foray into how one would approach the 
problem, but I then left it in a partially done state to focus on other 
things.

It also seems on first blush that C++ exceptions are not handled, but 
again I haven't yet gone and asked anyone in the know.

(it's on the list of things to do, but not yet at the top).

> 
> Note that rule of thumb is that we need to upstream all libsanitizer
> changes before we merge libsanitizer. We are doing that in order to not
> have a bug difference against upstream libsanitizer.

That sounds good to me -- I will remember to go upstream when I look 
into this.

> 
> Martin
> 

Re: [Patch 0/X] [WIP][RFC][libsanitizer] Introduce HWASAN to GCC

[Martin Liška]

On 9/6/19 4:46 PM, Matthew Malcomson wrote:
> Hello,
> 
> This patch series is a WORK-IN-PROGRESS towards porting the LLVM hardware
> address sanitizer (HWASAN) in GCC.  The document describing HWASAN can be 
> found
> here http://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html.

Hello.

I'm happy that you are working on the functionality for GCC and I can provide
my knowledge that I have with ASAN. I briefly read the patch series and I have
multiple questions (and observations):

1) Is the ambition of the patchset to be a software emulation of MTE that can
   work targets that do not support MTE? Is it something what clang
   names hwasan-abi=interceptor?

2) Do you have a real aarch64 hardware that has MTE support? Would it be 
possible
   for the future to give such a machine to GCC Compile Farm for testing 
purpose?

3) I like the idea of sharing of internal functions like 
ASAN_CHECK/HWASAN_CHECK.
   We should benefit from that in the future.

4) Am I correct that due to escape of "tagged" pointers, one needs to have an 
entire
DSO (dynamic shared object) built with hwasan enabled? Otherwise, a dereference 
of
a tagged pointer will lead to a segfault (except TBI feature on aarch64)?

5) Is there a documentation/definition of how shadow memory for memory tagging 
looks like?
Is it similar to ASAN, where one can get to tag with:
u8 memory_tag = *((PTR >> TG) + SHADOW_OFFSET) & 0xf?

6) Note that thing like memtag_tag_size, memtag_granule_size define an ABI of 
libsanitizer

> 
> The current patch series is far from complete, but I'm posting the current 
> state
> to provide something to discuss at the Cauldron next week.
> 
> In its current state, this sanitizer only works on AArch64 with a custom 
> kernel
> to allow tagged pointers in system calls.  This is discussed in the below link
> https://source.android.com/devices/tech/debug/hwasan -- the custom kernel 
> allows
> tagged pointers in syscalls.

Can you be please more specific. Is the MTE in upstream linux kernel? If so,
starting from which version?

> I have also not yet put tests into the DejaGNU framework, but instead have a
> simple test file from which the tests will eventually come.  That test file is
> attached to this email despite not being in the patch series.
> 
> Something close to this patch series bootstraps and passes most regression
> tests when ~--with-build-config=bootstrap-hwasan~ is used.  The regressions it
> doesn't pass are all the other sanitizer tests and all linker plugin tests.
> The linker plugin tests fail due to a configuration problem where the library
> path is not correctly set.
> (I say "something close to this patch series" because I recently made a change
> that breaks bootstrap but I believe is the best approach once I've fixed it,
> hence for an RFC I'm leaving it in).
> 
> HWASAN works by storing a tag in the top bits of every pointer and a colour in
> a shadow memory region corresponding to every area of memory.  On every memory
> access through a pointer the tag in the pointer is checked against the colour 
> in
> shadow memory corresponding to the memory the pointer is accessing.  If the 
> tag
> and colour do not match then a fault is signalled.
> 
> The instrumentation required for this sanitizer has a large overlap with the
> instrumentation required for implementing MTE (which has similar functionality
> but checks are automatically done in the hardware and instructions for 
> colouring
> shadow memory and for managing tags are provided by the architecture).
> https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/arm-a-profile-architecture-2018-developments-armv85a
> 
> We hope to use the HWASAN framework to implement MTE tagging on the stack, and
> hence I have a "dummy" patch demonstrating the approach envisaged for this.

What's the situation with heap allocated memory and global variables?

> 
> Though there is still much to implement here, the general approach should be
> clear.  Any feedback is welcomed, but I have three main points that I'm
> particularly hoping for external opinions.
> 
> 1) The current approach stores a tag on the RTL representing a given variable,
>in order to implement HWASAN for x86_64 the tag needs to be removed before
>every memory access but not on things like function calls.
>Is there any obvious way to handle removing the tag in these places?
>Maybe something with legitimize_address?

Not being a target expect, but I bet you'll need to store the tag with a RTL
representation of a stack variable.

Thanks,
Martin

> 2) The first draft presented here introduces a new RTL expression called
>ADDTAG.  I now believe that a hook would be neater here but haven't yet
>looked into it.  Do people agree?
>(addtag is introduced in the patch titled "Put tags into each stack 
> variable
>pointer", but the reason it's introduced is so the backend can define how
>this gets implemented with a ~define_exp

Re: [RFC][PATCH 5/X][libsanitizer] Introduce longjmp/setjmp interceptors to libhwasan

[Martin Liška]

On 9/9/19 12:29 PM, Matthew Malcomson wrote:
> On 09/09/19 11:01, Martin Liška wrote:
>> Hi.
>>
>> On 9/6/19 4:46 PM, Matthew Malcomson wrote:
>>> Ensuring that the shadow stack is cleared on normal function exit will
>>> be done by adding instrumentation to the function epilogue through the
>>> compiler.
>>> longjmp and setjmp are some abnormal methods of exiting the function
>>> that can't be handled in the compiler since they can be called in
>>> uninstrumented code to unwind past instrumented function frames.
>>
>> I'm curious why you are adding a new code that is not part of libsanitizer 
>> runtime?
>> Does it mean the current LLVM implementation does not properly handle setjmp 
>> and
>> longjmp?
> 
> Honestly -- I'm not sure.
> 
> I did a basic test that seemed to show clang not supporting setjmp & 
> longjmp and I made a bit of a foray into how one would approach the 
> problem, but I then left it in a partially done state to focus on other 
> things.

I see. Then I would probably file an issue and ask the community:
https://github.com/google/sanitizers/issues

> 
> It also seems on first blush that C++ exceptions are not handled, but 
> again I haven't yet gone and asked anyone in the know.

Likewise I would ask them for the C++ exceptions.

Martin

> 
> (it's on the list of things to do, but not yet at the top).
> 
>>
>> Note that rule of thumb is that we need to upstream all libsanitizer
>> changes before we merge libsanitizer. We are doing that in order to not
>> have a bug difference against upstream libsanitizer.
> 
> That sounds good to me -- I will remember to go upstream when I look 
> into this.
> 
>>
>> Martin
>>
> 

Re: [PATCH] Deprecate -frepo option.

[Martin Liška]

On 9/6/19 4:56 PM, Jakub Jelinek wrote:
> On Fri, Sep 06, 2019 at 10:48:53AM -0400, Marek Polacek wrote:
>> On Fri, Sep 06, 2019 at 08:58:48AM +0200, Martin Liška wrote:
>>> Ok, hopefully nobody is strongly against. I've just retested the
>>> patch and installed it as r275450.
>>
>> --- a/gcc/c-family/c.opt
>> +++ b/gcc/c-family/c.opt
>> @@ -1763,8 +1763,8 @@ ObjC ObjC++ LTO Var(flag_replace_objc_classes)
>>  Used in Fix-and-Continue mode to indicate that object files may be swapped 
>> in at runtime.
>>
>>  frepo
>> -C++ ObjC++
>> -Enable automatic template instantiation.
>> +C++ ObjC++ Deprecated
>> +Deprecated in GCC 10.  This switch has no effect.
> 
> The Deprecated keyword is just misnamed, I believe it does the same thing as
> Ignore, except that it also prints a warning that the switch is no longer
> supported, so kind like Ignore Warn(switch %<-frepo%> is no longer supported).
> The description should be just This switch has no effect. or
> Does nothing.  Preserved for backward compatibility.

I verified the description and it's fine to me:

frepo
C++ ObjC++ Deprecated
Deprecated in GCC 10.  This switch has no effect.

> 
>   Jakub
> 

Re: [PATCH] Deprecate -frepo option.

[Jakub Jelinek]

On Mon, Sep 09, 2019 at 01:02:32PM +0200, Martin Liška wrote:
> On 9/6/19 4:56 PM, Jakub Jelinek wrote:
> > On Fri, Sep 06, 2019 at 10:48:53AM -0400, Marek Polacek wrote:
> >> On Fri, Sep 06, 2019 at 08:58:48AM +0200, Martin Liška wrote:
> >>> Ok, hopefully nobody is strongly against. I've just retested the
> >>> patch and installed it as r275450.
> >>
> >> --- a/gcc/c-family/c.opt
> >> +++ b/gcc/c-family/c.opt
> >> @@ -1763,8 +1763,8 @@ ObjC ObjC++ LTO Var(flag_replace_objc_classes)
> >>  Used in Fix-and-Continue mode to indicate that object files may be 
> >> swapped in at runtime.
> >>
> >>  frepo
> >> -C++ ObjC++
> >> -Enable automatic template instantiation.
> >> +C++ ObjC++ Deprecated
> >> +Deprecated in GCC 10.  This switch has no effect.
> > 
> > The Deprecated keyword is just misnamed, I believe it does the same thing as
> > Ignore, except that it also prints a warning that the switch is no longer
> > supported, so kind like Ignore Warn(switch %<-frepo%> is no longer 
> > supported).
> > The description should be just This switch has no effect. or
> > Does nothing.  Preserved for backward compatibility.
> 
> I verified the description and it's fine to me:
> 
> frepo
> C++ ObjC++ Deprecated
> Deprecated in GCC 10.  This switch has no effect.

This first part looks wrong to me.
"deprecated
(computing) Obsolescent; said of a construct in a computing language considered 
old,
and planned to be phased out, but still available for use."
That is not the case here in GCC 10, the feature has been removed, it has
been deprecated in GCC 9.N for N >= 2 only.

Jakub

Re: [ PATCH ] C++20

[Jonathan Wakely]

And some further simplifications and improvements to the constructor
constraints for std::span.

   This patch simplifies the constraints on the constructors from arrays by
   removing the redundant checks that element_type and value_type are
   convertible to element_type. The incorrect uses of __adl_data in those
   constructors are removed as well (they should use std::data not
   std::ranges::data, and the former doesn't use ADL).

   The range/container constructors are now constrained to exclude all
   specializations of std::span, not just the current instantiation. The
   range constructor now also checks s subset of the contiguous_range
   requirements.

   All relevant constructor constraints now use the _Require helper in
   order to short circuit and avoid unnecessary instantiations after the
   first failed constraint.

   A new constructor supports initialization from different specializations
   of std::span, as specified in the C++20 draft.


Tested x86_64-linux, committed to trunk.


commit cf9248752de63a49bde062eb00681ae1c6d1a546
Author: Jonathan Wakely 
Date:   Mon Sep 9 10:56:54 2019 +0100

Improve constraints for std::span constructors

This patch simplifies the constraints on the constructors from arrays by
removing the redundant checks that element_type and value_type are
convertible to element_type. The incorrect uses of __adl_data in those
constructors are removed as well (they should use std::data not
std::ranges::data, and the former doesn't use ADL).

The range/container constructors are now constrained to exclude all
specializations of std::span, not just the current instantiation. The
range constructor now also checks s subset of the contiguous_range
requirements.

All relevant constructor constraints now use the _Require helper in
order to short circuit and avoid unnecessary instantiations after the
first failed constraint.

A new constructor supports initialization from different specializations
of std::span, as specified in the C++20 draft.

* include/bits/range_access.h (__adl_to_address): Remove.
* include/std/span (__is_base_derived_safe_convertible_v): Replace
with span::__is_compatible.
(__is_std_array_v): Replace with __is_std_array class template and
partial specializations.
(__is_std_array, __is_std_span): New class templates and partial
specializations.
(span::__is_compatible): New alias template for SFINAE constraints.
(span::span(element_type (&)[N])): Remove redundant constraints. Do
not use __adl_data to obtain a pointer.
(span::span(array&)): Likewise.
(span::span(const array&)): Likewise.
[_GLIBCXX_P1394] (span::iter_reference_t, span::iterator_t)
(span::iter_value_t, span::derived_from): New alias templates for
SFINAE constraints, until the equivalents are supported in 
and .
[_GLIBCXX_P1394] (span::__is_compatible_iterator): New alias template
for SFINAE constraints.
[_GLIBCXX_P1394] (span::is_compatible_range): New class template for
SFINAE constraints.
[_GLIBCXX_P1394] (span::span(Range&&)): Improve constraints.
[_GLIBCXX_P1394] (span::span(ContiguousIterator, Sentinel)): Likewise.
Use std::to_address instead of __adl_to_address.
[_GLIBCXX_P1394] (span::span(ContiguousIterator, size_type)): Likewise.
[!_GLIBCXX_P1394] (span::__is_compatible_container): New alias
template for SFINAE constraints.
[!_GLIBCXX_P1394] (span::span(Container&))
(span::span(const Container&)): Improve constraints.
[!_GLIBCXX_P1394] (span::span(pointer, size_type))
(span::span(pointer, pointer)): Remove redundant cast of pointer.
(span(const span&)): New constructor.

diff --git a/libstdc++-v3/include/bits/range_access.h b/libstdc++-v3/include/bits/range_access.h
index c5744145590..bc137d7396e 100644
--- a/libstdc++-v3/include/bits/range_access.h
+++ b/libstdc++-v3/include/bits/range_access.h
@@ -396,13 +396,6 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 constexpr auto
 __adl_empty(_Container& __cont) noexcept(noexcept(empty(__cont)))
 { return empty(__cont); }
-
-#if defined(_GLIBCXX_P1394) && _GLIBCXX_P1394
-  template 
-constexpr auto
-__adl_to_address(_Container& __cont) noexcept(noexcept(to_address(__cont)))
-{ return to_address(__cont); }
-#endif // P1394 and new contiguous_iterator requirements [iterator.concept.contiguous]
 #endif // C++20
 
 _GLIBCXX_END_NAMESPACE_VERSION
diff --git a/libstdc++-v3/include/std/span b/libstdc++-v3/include/std/span
index 95d778b104b..1a0d61c1947 100644
--- a/libstdc++-v3/include/std/span
+++ b/libstdc++-v3/include/std/span
@@ -53,24 +53,27 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
   in

Re: [PATCH] Optimize to_chars

[Jonathan Wakely]

On 08/09/19 16:44 +0300, Antony Polukhin wrote:

We've already beaten this topic to death, so let's put a final nail in
the coffin:


__to_chars_10_impl is quite fast. According to the IACA the main loop
takes only 6.0 cycles, the whole function with one iteration takes
10.0 cycles. Replacing the __first[pos] and __first[pos - 1] with
__first[0] and __first[1] drops the function time to 7.53 cycles.

Changelog:

2019-09-08  Antony Polukhin  

   * include/bits/charconv.h (__detail::__to_chars_10_impl): Replace
   final offsets with constants.


Excellent, thanks for the patch and all the benchmarking!

I've committed this to trunk now.

Re: [SVE] PR86753

[Richard Sandiford]

Prathamesh Kulkarni  writes:
> With patch, the only following FAIL remains for aarch64-sve.exp:
> FAIL: gcc.target/aarch64/sve/cond_unary_2.c -march=armv8.2-a+sve
> scan-assembler-times \\tmovprfx\\t 6
> which now contains 14.
> Should I adjust the test, assuming the change isn't a regression ?

Well, it is kind-of a regression, but it really just means that the
integer code is now consistent with the floating-point code in having
an unnecessary MOVPRFX.  So I think adjusting the count is fine.
Presumably any future fix for the existing redundant MOVPRFXs will
apply to the new ones as well.

The patch looks good to me, just some very minor nits:

> @@ -8309,11 +8309,12 @@ vect_double_mask_nunits (tree type)
>  
>  /* Record that a fully-masked version of LOOP_VINFO would need MASKS to
> contain a sequence of NVECTORS masks that each control a vector of type
> -   VECTYPE.  */
> +   VECTYPE. SCALAR_MASK if non-null, represents the mask used for 
> corresponding
> +   load/store stmt.  */

Should be two spaces between sentences.  Maybe:

   VECTYPE.  If SCALAR_MASK is nonnull, the fully-masked loop would AND
   these vector masks with the vector version of SCALAR_MASK.  */

since the mask isn't necessarily for a load or store statement.

> [...]
> @@ -1879,7 +1879,8 @@ static tree permute_vec_elements (tree, tree, tree, 
> stmt_vec_info,
> says how the load or store is going to be implemented and GROUP_SIZE
> is the number of load or store statements in the containing group.
> If the access is a gather load or scatter store, GS_INFO describes
> -   its arguments.
> +   its arguments. SCALAR_MASK is the scalar mask used for corresponding
> +   load or store stmt.

Maybe:

   its arguments.  If the load or store is conditional, SCALAR_MASK is the
   condition under which it occurs.

since SCALAR_MASK can be null here too.

> [...]
> @@ -9975,6 +9978,31 @@ vectorizable_condition (stmt_vec_info stmt_info, 
> gimple_stmt_iterator *gsi,
>/* Handle cond expr.  */
>for (j = 0; j < ncopies; j++)
>  {
> +  tree loop_mask = NULL_TREE;
> +  bool swap_cond_operands = false;
> +
> +  if (loop_vinfo && LOOP_VINFO_FULLY_MASKED_P (loop_vinfo))
> + {
> +   scalar_cond_masked_key cond (cond_expr, ncopies);
> +   if (loop_vinfo->scalar_cond_masked_set.contains (cond))
> + {
> +   vec_loop_masks *masks = &LOOP_VINFO_MASKS (loop_vinfo);
> +   loop_mask = vect_get_loop_mask (gsi, masks, ncopies, vectype, j);
> + }
> +   else
> + {
> +   cond.code = invert_tree_comparison (cond.code,
> +   HONOR_NANS (TREE_TYPE 
> (cond.op0)));

Long line.  Maybe just split it out into a separate assignment:

  bool honor_nans = HONOR_NANS (TREE_TYPE (cond.op0));
  cond.code = invert_tree_comparison (cond.code, honor_nans);

> +   if (loop_vinfo->scalar_cond_masked_set.contains (cond))
> + {
> +   vec_loop_masks *masks = &LOOP_VINFO_MASKS (loop_vinfo);
> +   loop_mask = vect_get_loop_mask (gsi, masks, ncopies, vectype, 
> j);

Long line here too.

> [...]
> @@ -10090,6 +10121,26 @@ vectorizable_condition (stmt_vec_info stmt_info, 
> gimple_stmt_iterator *gsi,
>   }
>   }
>   }
> +
> +   if (loop_mask)
> + {
> +   if (COMPARISON_CLASS_P (vec_compare))
> + {
> +   tree tmp = make_ssa_name (vec_cmp_type);
> +   gassign *g = gimple_build_assign (tmp,
> + TREE_CODE (vec_compare),
> + TREE_OPERAND (vec_compare, 
> 0),
d> +TREE_OPERAND (vec_compare, 
1));

Two long lines.

> +   vect_finish_stmt_generation (stmt_info, g, gsi);
> +   vec_compare = tmp;
> + }
> +
> +   tree tmp2 = make_ssa_name (vec_cmp_type);
> +   gassign *g = gimple_build_assign (tmp2, BIT_AND_EXPR, 
> vec_compare, loop_mask);

Long line here too.

> [...]
> diff --git a/gcc/tree-vectorizer.c b/gcc/tree-vectorizer.c
> index dc181524744..c4b2d8e8647 100644
> --- a/gcc/tree-vectorizer.c
> +++ b/gcc/tree-vectorizer.c
> @@ -1513,3 +1513,39 @@ make_pass_ipa_increase_alignment (gcc::context *ctxt)
>  {
>return new pass_ipa_increase_alignment (ctxt);
>  }
> +
> +/* If code(T) is comparison op or def of comparison stmt,
> +   extract it's operands.
> +   Else return .  */
> +
> +void
> +scalar_cond_masked_key::get_cond_ops_from_tree (tree t) 
> +{
> +  if (TREE_CODE_CLASS (TREE_CODE (t)) == tcc_comparison)
> +{
> +  this->code = TREE_CODE (t);
> +  this->op0 = TREE_OPERAND (t, 0);
> +  this->op1 = TREE_OPERAND (t, 1);
> +  return;
> +}
> +
> +  if (TREE_CODE (t) == SSA_NAME)
> +{
> +  gassign *stmt = dyn_cast (SSA_NAME_DEF_STMT (t));
> +  if (stmt)
> +{

Remove bt-load.c

[Richard Sandiford]

bt-load.c has AFAIK been dead code since the removal of the SH5 port
in 2016.  I have a patch series that would need to update the liveness
tracking in a nontrivial way, so it seemed better to remove the pass
rather than install an untested and probably bogus change.

Tested on aarch64-linux-gnu, x86_64-linux-gnu and by cross-building
one target for each CPU directory.  OK to install?

Richard


2019-09-09  Richard Sandiford  

gcc/
* Makefile.in (OBJS): Remove bt-load.o.
* doc/invoke.texi (fbranch-target-load-optimize): Delete.
(fbranch-target-load-optimize2, fbtr-bb-exclusive): Likewise.
* common.opt (fbranch-target-load-optimize): Mark as Ignore and
document that the option no longer does anything.
(fbranch-target-load-optimize2, fbtr-bb-exclusive): Likewise.
* target.def (branch_target_register_class): Delete.
(branch_target_register_callee_saved): Likewise.
* doc/tm.texi.in (TARGET_BRANCH_TARGET_REGISTER_CLASS): Likewise.
(TARGET_BRANCH_TARGET_REGISTER_CALLEE_SAVED): Likewise.
* doc/tm.texi: Regenerate.
* tree-pass.h (make_pass_branch_target_load_optimize1): Delete.
(make_pass_branch_target_load_optimize2): Likewise.
* passes.def (pass_branch_target_load_optimize1): Likewise.
(pass_branch_target_load_optimize2): Likewise.
* targhooks.h (default_branch_target_register_class): Likewise.
* targhooks.c (default_branch_target_register_class): Likewise.
* opt-suggestions.c (test_completion_valid_options): Remove
-fbtr-bb-exclusive from the list of test options.
* bt-load.c: Remove.

Index: gcc/Makefile.in
===
--- gcc/Makefile.in 2019-09-09 12:19:41.357572457 +0100
+++ gcc/Makefile.in 2019-09-09 12:20:07.085390926 +0100
@@ -1241,7 +1241,6 @@ OBJS = \
auto-profile.o \
bb-reorder.o \
bitmap.o \
-   bt-load.o \
builtins.o \
caller-save.o \
calls.o \
Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi 2019-09-09 12:19:39.289587049 +0100
+++ gcc/doc/invoke.texi 2019-09-09 12:20:07.093390870 +0100
@@ -406,8 +406,7 @@ Objective-C and Objective-C++ Dialects}.
 -falign-loops[=@var{n}[:@var{m}:[@var{n2}[:@var{m2} @gol
 -fassociative-math  -fauto-profile  -fauto-profile[=@var{path}] @gol
 -fauto-inc-dec  -fbranch-probabilities @gol
--fbranch-target-load-optimize  -fbranch-target-load-optimize2 @gol
--fbtr-bb-exclusive  -fcaller-saves @gol
+-fcaller-saves @gol
 -fcombine-stack-adjustments  -fconserve-stack @gol
 -fcompare-elim  -fcprop-registers  -fcrossjumping @gol
 -fcse-follow-jumps  -fcse-skip-blocks  -fcx-fortran-rules @gol
@@ -11025,24 +11024,6 @@ locations inside a translation unit sinc
 link time.  An example of such an optimization is relaxing calls to short call
 instructions.
 
-@item -fbranch-target-load-optimize
-@opindex fbranch-target-load-optimize
-Perform branch target register load optimization before prologue / epilogue
-threading.
-The use of target registers can typically be exposed only during reload,
-thus hoisting loads out of loops and doing inter-block scheduling needs
-a separate optimization pass.
-
-@item -fbranch-target-load-optimize2
-@opindex fbranch-target-load-optimize2
-Perform branch target register load optimization after prologue / epilogue
-threading.
-
-@item -fbtr-bb-exclusive
-@opindex fbtr-bb-exclusive
-When performing branch target register load optimization, don't reuse
-branch target registers within any basic block.
-
 @item -fstdarg-opt
 @opindex fstdarg-opt
 Optimize the prologue of variadic argument functions with respect to usage of
Index: gcc/common.opt
===
--- gcc/common.opt  2019-08-25 19:10:35.538157161 +0100
+++ gcc/common.opt  2019-09-09 12:20:07.089390898 +0100
@@ -1076,16 +1076,16 @@ Common Report Var(flag_branch_probabilit
 Use profiling information for branch probabilities.
 
 fbranch-target-load-optimize
-Common Report Var(flag_branch_target_load_optimize) Optimization
-Perform branch target load optimization before prologue / epilogue threading.
+Common Ignore
+Does nothing.  Preserved for backward compatibility.
 
 fbranch-target-load-optimize2
-Common Report Var(flag_branch_target_load_optimize2) Optimization
-Perform branch target load optimization after prologue / epilogue threading.
+Common Ignore
+Does nothing.  Preserved for backward compatibility.
 
 fbtr-bb-exclusive
-Common Report Var(flag_btr_bb_exclusive) Optimization
-Restrict target load migration not to re-use registers in any basic block.
+Common Ignore
+Does nothing.  Preserved for backward compatibility.
 
 fcall-saved-
 Common Joined RejectNegative Var(common_deferred_options) Defer
Index: gcc/target.def
===

[PATCH] Update comment of removed options.

[Martin Liška]

On 9/9/19 1:08 PM, Jakub Jelinek wrote:
> On Mon, Sep 09, 2019 at 01:02:32PM +0200, Martin Liška wrote:
>> On 9/6/19 4:56 PM, Jakub Jelinek wrote:
>>> On Fri, Sep 06, 2019 at 10:48:53AM -0400, Marek Polacek wrote:
 On Fri, Sep 06, 2019 at 08:58:48AM +0200, Martin Liška wrote:
> Ok, hopefully nobody is strongly against. I've just retested the
> patch and installed it as r275450.

 --- a/gcc/c-family/c.opt
 +++ b/gcc/c-family/c.opt
 @@ -1763,8 +1763,8 @@ ObjC ObjC++ LTO Var(flag_replace_objc_classes)
  Used in Fix-and-Continue mode to indicate that object files may be 
 swapped in at runtime.

  frepo
 -C++ ObjC++
 -Enable automatic template instantiation.
 +C++ ObjC++ Deprecated
 +Deprecated in GCC 10.  This switch has no effect.
>>>
>>> The Deprecated keyword is just misnamed, I believe it does the same thing as
>>> Ignore, except that it also prints a warning that the switch is no longer
>>> supported, so kind like Ignore Warn(switch %<-frepo%> is no longer 
>>> supported).
>>> The description should be just This switch has no effect. or
>>> Does nothing.  Preserved for backward compatibility.
>>
>> I verified the description and it's fine to me:
>>
>> frepo
>> C++ ObjC++ Deprecated
>> Deprecated in GCC 10.  This switch has no effect.
> 
> This first part looks wrong to me.
> "deprecated
> (computing) Obsolescent; said of a construct in a computing language 
> considered old,
> and planned to be phased out, but still available for use."

You are right. What about the suggested patch?

Martin

> That is not the case here in GCC 10, the feature has been removed, it has
> been deprecated in GCC 9.N for N >= 2 only.
> 
>   Jakub
> 

>From ece8a83bdf6c2504bfe57dd033f6876cf2ffb9a2 Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Mon, 9 Sep 2019 13:22:51 +0200
Subject: [PATCH] Update comment of removed options.

gcc/ChangeLog:

2019-09-09  Martin Liska  

	* config/i386/i386.opt: Update comment of removed
	options that are preserved only for backward
	compatibility.

gcc/c-family/ChangeLog:

2019-09-09  Martin Liska  

	* c.opt: Update comment of removed
	options that are preserved only for backward
	compatibility.
---
 gcc/c-family/c.opt   | 46 
 gcc/config/i386/i386.opt |  4 ++--
 2 files changed, 25 insertions(+), 25 deletions(-)

diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index ec546663029..c5804470d47 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -429,7 +429,7 @@ Warn about subscripts whose type is \"char\".
 
 Wchkp
 C ObjC C++ ObjC++ Warning Deprecated
-Deprecated in GCC 9.  This switch has no effect.
+Removed in GCC 9.  This switch has no effect.
 
 Wclobbered
 C ObjC C++ ObjC++ Var(warn_clobbered) Warning EnabledBy(Wextra)
@@ -1338,90 +1338,90 @@ and character literals.
 
 fcheck-pointer-bounds
 C ObjC C++ ObjC++ LTO Deprecated
-Deprecated in GCC 9.  This switch has no effect.
+Removed in GCC 9.  This switch has no effect.
 
 fchkp-check-incomplete-type
 C ObjC C++ ObjC++ LTO Deprecated
-Deprecated in GCC 9.  This switch has no effect.
+Removed in GCC 9.  This switch has no effect.
 
 fchkp-zero-input-bounds-for-main
 C ObjC C++ ObjC++ LTO Deprecated
-Deprecated in GCC 9.  This switch has no effect.
+Removed in GCC 9.  This switch has no effect.
 
 fchkp-first-field-has-own-bounds
 C ObjC C++ ObjC++ LTO Deprecated RejectNegative
-Deprecated in GCC 9.  This switch has no effect.
+Removed in GCC 9.  This switch has no effect.
 
 fchkp-narrow-bounds
 C ObjC C++ ObjC++ LTO Deprecated
-Deprecated in GCC 9.  This switch has no effect.
+Removed in GCC 9.  This switch has no effect.
 
 fchkp-narrow-to-innermost-array
 C ObjC C++ ObjC++ LTO Deprecated RejectNegative
-Deprecated in GCC 9.  This switch has no effect.
+Removed in GCC 9.  This switch has no effect.
 
 fchkp-flexible-struct-trailing-arrays
 C ObjC C++ ObjC++ LTO Deprecated
-Deprecated in GCC 9.  This switch has no effect.
+Removed in GCC 9.  This switch has no effect.
 
 fchkp-optimize
 C ObjC C++ ObjC++ LTO Deprecated
 
 fchkp-use-fast-string-functions
 C ObjC C++ ObjC++ LTO Deprecated
-Deprecated in GCC 9.  This switch has no effect.
+Removed in GCC 9.  This switch has no effect.
 
 fchkp-use-nochk-string-functions
 C ObjC C++ ObjC++ LTO Deprecated
-Deprecated in GCC 9.  This switch has no effect.
+Removed in GCC 9.  This switch has no effect.
 
 fchkp-use-static-bounds
 C ObjC C++ ObjC++ LTO Deprecated
-Deprecated in GCC 9.  This switch has no effect.
+Removed in GCC 9.  This switch has no effect.
 
 fchkp-use-static-const-bounds
 C ObjC C++ ObjC++ LTO Deprecated
-Deprecated in GCC 9.  This switch has no effect.
+Removed in GCC 9.  This switch has no effect.
 
 fchkp-treat-zero-dynamic-size-as-infinite
 C ObjC C++ ObjC++ LTO Deprecated
-Deprecated in GCC 9.  This switch has no effect.
+Removed in GCC 9.  This switch has no effect.
 
 fchkp-check-read
 C ObjC C++ ObjC++ LTO Deprecated
-Deprecated in GCC 9.  This swit

Make note_stores take an rtx_insn

[Richard Sandiford]

I have a series of patches that (as a side effect) makes all rtl
passes use the information collected by -fipa-ra.  This showed up a
latent bug in the liveness tracking in regrename.c, which doesn't take
CALL_INSN_FUNCTION_USAGE into account when processing clobbers.

This actually seems to be quite a common problem with passes that use
note_stores; only a handful remember to walk CALL_INSN_FUNCTION_USAGE
too.  I think it was just luck that I saw it with regrename first.

This patch tries to make things more robust by passing an insn rather
than a pattern to note_stores.  The old function is still available
as note_pattern_stores for the few places that need it.

When updating callers, I've erred on the side of using note_stores
rather than note_pattern_stores, because IMO note_stores should be
the default choice and we should only use note_pattern_stores if
there's a specific reason.  Specifically:

* For cselib.c, "body" may be a COND_EXEC_CODE instead of the main
  insn pattern.

* For ira.c, I wasn't sure whether extending no_equiv to
  CALL_INSN_FUNCTION_USAGE really made sense, since we don't do that
  for normal call-clobbered registers.  Same for mark_not_eliminable
  in reload1.c

* Some other places only have a pattern available, and since those
  places wouldn't benefit from walking CALL_INSN_FUNCTION_USAGE,
  it seemed better to alter the code as little as possible.

* In the config/ changes, quite a few callers have already weeded
  out CALL insns.  It still seemed better to use note_stores rather
  than prematurely optimise.  (note_stores should tail call to
  note_pattern_stores once it sees that the insn isn't a call.)

The patch also documents what SETs mean in CALL_INSN_FUNCTION_USAGE.

Tested on aarch64-linux-gnu and x86_64-linux-gnu.  Also tested by
building one target for each CPU directory and testing for no new
warnings.  Comparing the asm output for gcc.c-torture, gcc.dg and
g++.dg for those targets at -O2 showed some changes for AArch64
and AArch32 targets (all neutral or very minor improvements).
There were no changes for other ports.

(This was before BPF, but fortunately BPF doesn't use note_stores. :-))

OK to install?

Richard


2019-09-09  Richard Sandiford  

gcc/
* rtl.h (CALL_INSN_FUNCTION_USAGE): Document what SETs mean.
(note_pattern_stores): Declare.
(note_stores): Take an rtx_insn *.
* rtlanal.c (set_of): Use note_pattern_stores instead of note_stores.
(find_all_hard_reg_sets): Pass the insn rather than its pattern to
note_stores.  Remove explicit handling of CALL_INSN_FUNCTION_USAGE.
(note_stores): Take an rtx_insn * as argument and process
CALL_INSN_FUNCTION_USAGE.  Rename old function to...
(note_pattern_stores): ...this.
(find_first_parameter_load): Pass the insn rather than
its pattern to note_stores.
* alias.c (memory_modified_in_insn_p, init_alias_analysis): Likewise.
* caller-save.c (setup_save_areas, save_call_clobbered_regs)
(insert_one_insn): Likewise.
* combine.c (combine_instructions): Likewise.
(likely_spilled_retval_p): Likewise.
(try_combine): Use note_pattern_stores instead of note_stores.
(record_dead_and_set_regs): Pass the insn rather than its pattern
to note_stores.
(reg_dead_at_p): Likewise.
* config/bfin/bfin.c (workaround_speculation): Likewise.
* config/c6x/c6x.c (maybe_clobber_cond): Likewise.  Take an rtx_insn *
rather than an rtx.
* config/frv/frv.c (frv_registers_update): Use note_pattern_stores
instead of note_stores.
(frv_optimize_membar_local): Pass the insn rather than its pattern
to note_stores.
* config/gcn/gcn.c (gcn_md_reorg): Likewise.
* config/i386/i386.c (ix86_avx_u128_mode_after): Likewise.
* config/mips/mips.c (vr4130_true_reg_dependence_p): Likewise.
(r10k_needs_protection_p, mips_sim_issue_insn): Likewise.
(mips_reorg_process_insns): Likewise.
* config/s390/s390.c (s390_regs_ever_clobbered): Likewise.
* config/sh/sh.c (flow_dependent_p): Likewise.  Take rtx_insn *s
rather than rtxes.
* cse.c (delete_trivially_dead_insns): Pass the insn rather than
its pattern to note_stores.
* cselib.c (cselib_record_sets): Use note_pattern_stores instead
of note_stores.
* dce.c (mark_nonreg_stores): Remove the "body" parameter and pass
the insn to note_stores.
(prescan_insns_for_dce): Update call accordingly.
* ddg.c (mem_write_insn_p): Pass the insn rather than its pattern
to note_stores.
* df-problems.c (can_move_insns_across): Likewise.
* dse.c (emit_inc_dec_insn_before, replace_read): Likewise.
* function.c (assign_parm_setup_reg): Likewise.
* gcse-common.c (record_last_mem_set_info_common): Likewise.
* gcse.c (load_killed_in_block_p, compute_hash_table

Re: [PATCH] Update comment of removed options.

[Jonathan Wakely]

On Mon, 9 Sep 2019 at 12:24, Martin Liška  wrote:
>
> On 9/9/19 1:08 PM, Jakub Jelinek wrote:
> > On Mon, Sep 09, 2019 at 01:02:32PM +0200, Martin Liška wrote:
> >> On 9/6/19 4:56 PM, Jakub Jelinek wrote:
> >>> On Fri, Sep 06, 2019 at 10:48:53AM -0400, Marek Polacek wrote:
>  On Fri, Sep 06, 2019 at 08:58:48AM +0200, Martin Liška wrote:
> > Ok, hopefully nobody is strongly against. I've just retested the
> > patch and installed it as r275450.
> 
>  --- a/gcc/c-family/c.opt
>  +++ b/gcc/c-family/c.opt
>  @@ -1763,8 +1763,8 @@ ObjC ObjC++ LTO Var(flag_replace_objc_classes)
>   Used in Fix-and-Continue mode to indicate that object files may be 
>  swapped in at runtime.
> 
>   frepo
>  -C++ ObjC++
>  -Enable automatic template instantiation.
>  +C++ ObjC++ Deprecated
>  +Deprecated in GCC 10.  This switch has no effect.
> >>>
> >>> The Deprecated keyword is just misnamed, I believe it does the same thing 
> >>> as
> >>> Ignore, except that it also prints a warning that the switch is no longer
> >>> supported, so kind like Ignore Warn(switch %<-frepo%> is no longer 
> >>> supported).
> >>> The description should be just This switch has no effect. or
> >>> Does nothing.  Preserved for backward compatibility.
> >>
> >> I verified the description and it's fine to me:
> >>
> >> frepo
> >> C++ ObjC++ Deprecated
> >> Deprecated in GCC 10.  This switch has no effect.
> >
> > This first part looks wrong to me.
> > "deprecated
> > (computing) Obsolescent; said of a construct in a computing language 
> > considered old,
> > and planned to be phased out, but still available for use."

I agree with this definition. If it's deprecated it still needs to be
available for use.

Re: [PATCH] Update comment of removed options.

[Jakub Jelinek]

On Mon, Sep 09, 2019 at 01:24:53PM +0200, Martin Liška wrote:
> You are right. What about the suggested patch?

Can you please quickly (say with svn blame) double check whether the
descriptions weren't actually right but misleading (an option could
be deprecated in N and removed in N+1 or so, so see if it has been actually
removed in the GCC release mentioned in there, rather than deprecated and
removed later)?

Ok with that.  Perhaps it would be desirable to also rename the Deprecated
keyword in *.opt to Removed and adjust documentation, but that can be
handled separately.

Jakub

Re: [PATCH] Update comment of removed options.

[Martin Liška]

On 9/9/19 1:39 PM, Jakub Jelinek wrote:
> On Mon, Sep 09, 2019 at 01:24:53PM +0200, Martin Liška wrote:
>> You are right. What about the suggested patch?
> 
> Can you please quickly (say with svn blame) double check whether the
> descriptions weren't actually right but misleading (an option could
> be deprecated in N and removed in N+1 or so, so see if it has been actually
> removed in the GCC release mentioned in there, rather than deprecated and
> removed later)?

Yes, majority of the changes are MPX-related options. There were really removed 
in GCC 9.x.
Then there's fcilkplus (really removed in GCC 8.x) and last one is -frepo, 
which I've just
removed (thus GCC 10).

Martin

> 
> Ok with that.  Perhaps it would be desirable to also rename the Deprecated
> keyword in *.opt to Removed and adjust documentation, but that can be
> handled separately.
> 
>   Jakub
> 

[PATCH] Make LTO link pick up compile-time -g

[Richard Biener]

Currently when you compile with -g -flto and then link without
repeating -g you'll get a binary that has all early debug
but none of the late because the driver doesn't pass -g along
to the LTRANS stage.

This has always been the case and as with other options
"guessing" correctly is hard.  The following goes a very
simple way of recording debug_info_level > DINFO_LEVEL_NONE
at compile-time into lto-opts.c as -g and picking that one
up in lto-wrapper.

So if _any_ object was compiled with debug-info (of any kind)
then we'll now get -g (sic!) enabled at LTRANS time.

The patch also re-instantiates the support for -g0 at link-time,
dropping the early created debug as well.

There are a gazillion different -g options we'd need to handle
if we try to do better like if all compile-time objects had
-gdwarf5 enabled then do so at link time.  But then there's
no change to consistently carry diferent settings to the link
stage if you consider inlining and partitioning.

So this is really a very poor mans solution that also might
uncover issues with -g0 at compile-time vs. -g at link-time
if there are mixed -g0/g TUs in the LTO link.

We've run into this "issue" with openSUSE packages now built
with -flto which in turn means some objects (those linked w/o -g)
ended up without the LTRANS debug part...

Any opinions welcome.

Thanks,
Richard.

2019-09-09  Richard Biener  

* lto-opts.c (lto_write_options): Stream -g when debug is enabled.
* lto-wrapper.c (merge_and_complain): Pick up -g.
(append_compiler_options): Likewise.
(run_gcc): Re-instantiate handling -g0 at link-time.

Index: gcc/lto-opts.c
===
--- gcc/lto-opts.c  (revision 275454)
+++ gcc/lto-opts.c  (working copy)
@@ -94,6 +94,10 @@ lto_write_options (void)
  : "-fno-pie");
 }
 
+  /* If debug info is enabled append -g.  */
+  if (debug_info_level > DINFO_LEVEL_NONE)
+append_to_collect_gcc_options (&temporary_obstack, &first_p, "-g");
+
   /* Append options from target hook and store them to offload_lto section.  */
   if (lto_stream_offload_p)
 {
Index: gcc/lto-wrapper.c
===
--- gcc/lto-wrapper.c   (revision 275454)
+++ gcc/lto-wrapper.c   (working copy)
@@ -265,6 +265,7 @@ merge_and_complain (struct cl_decoded_op
case OPT_fshow_column:
case OPT_fcommon:
case OPT_fgnu_tm:
+   case OPT_g:
  /* Do what the old LTO code did - collect exactly one option
 setting per OPT code, we pick the first we encounter.
 ???  This doesn't make too much sense, but when it doesn't
@@ -617,6 +618,7 @@ append_compiler_options (obstack *argv_o
case OPT_fopenacc:
case OPT_fopenacc_dim_:
case OPT_foffload_abi_:
+   case OPT_g:
case OPT_O:
case OPT_Ofast:
case OPT_Og:
@@ -1399,6 +1401,10 @@ run_gcc (unsigned argc, char *argv[])
  linker_output_rel = !strcmp (option->arg, "rel");
  break;
 
+   case OPT_g:
+ /* Recognize -g0.  */
+ skip_debug = option->arg && !strcmp (option->arg, "0");
+ break;
 
default:
  break;

Re: [PATCH 1/2] Auto-generate maybe_fold_and/or_comparisons from match.pd

[Martin Liška]

Hi.

I'm sending slightly updated version of the patch where we
need to properly select type in maybe_fold_comparisons_from_match_pd
function for the created SSA_NAMEs. We can be called for a VECTOR_TYPE
and so that we can't return a boolean_type_node.

Patch can bootstrap on x86_64-linux-gnu and survives regression tests.

Ready to be installed?
Thanks,
Martin
>From b6165b1d4be04f47bfa2b511974f5b8e784acb41 Mon Sep 17 00:00:00 2001
From: Li Jia He 
Date: Mon, 15 Jul 2019 00:30:25 -0500
Subject: [PATCH 1/5] Auto-generate maybe_fold_and/or_comparisons from match.pd

gcc/ChangeLog

2019-07-16  Li Jia He  
	Martin Liska  

	* gimple.h (gimple_init): Declare.
	(gimple_size): Likewise.
	* gimple.c (gimple_init): Remove static and inline restrictions.
	(gimple_alloc): Only allocate memory and call gimple_init.
	(gimple_size): Likewise.
	* gimple-fold.c (maybe_fold_comparisons_from_match_pd): New function.
	(maybe_fold_and_comparisons): Modify and_comparisons_1 invocation and
	call maybe_fold_comparisons_from_match_pd.
	(maybe_fold_or_comparisons): Modify or_comparisons_1 invocation and
	call maybe_fold_comparisons_from_match_pd.
	* tree-ssanames.c (init_ssa_name_imm_use): Use make_ssa_name_fn.
	(make_ssa_name_fn): New.
	* tree-ssanames.h (init_ssa_name_imm_use): New.
---
 gcc/gimple-fold.c   | 112 
 gcc/gimple.c|  37 +--
 gcc/gimple.h|   2 +
 gcc/tree-ssanames.c |  21 ++---
 gcc/tree-ssanames.h |   1 +
 5 files changed, 142 insertions(+), 31 deletions(-)

diff --git a/gcc/gimple-fold.c b/gcc/gimple-fold.c
index fcffb9802b7..8a9eca13b87 100644
--- a/gcc/gimple-fold.c
+++ b/gcc/gimple-fold.c
@@ -5834,6 +5834,89 @@ and_comparisons_1 (enum tree_code code1, tree op1a, tree op1b,
   return NULL_TREE;
 }
 
+/* Helper function for maybe_fold_and_comparisons and maybe_fold_or_comparisons
+   : try to simplify the AND/OR of the ssa variable VAR with the comparison
+   specified by (OP2A CODE2 OP2B) from match.pd.  Return NULL_EXPR if we can't
+   simplify this to a single expression.  As we are going to lower the cost
+   of building SSA names / gimple stmts significantly, we need to allocate
+   them ont the stack.  This will cause the code to be a bit ugly.  */
+
+static tree
+maybe_fold_comparisons_from_match_pd (enum tree_code code, enum tree_code code1,
+  tree op1a, tree op1b,
+  enum tree_code code2, tree op2a,
+  tree op2b)
+{
+  tree type = TREE_TYPE (op1a);
+  if (TREE_CODE (type) != VECTOR_TYPE)
+type = boolean_type_node;
+
+  /* Allocate gimple stmt1 on the stack.  */
+  gimple *stmt1 = (gimple *) XALLOCAVEC (char, gimple_size (GIMPLE_ASSIGN, 2));
+  gimple_init (stmt1, GIMPLE_ASSIGN, 3);
+  gimple_assign_set_rhs_code (stmt1, code1);
+  gimple_assign_set_rhs1 (stmt1, op1a);
+  gimple_assign_set_rhs2 (stmt1, op1b);
+
+  /* Allocate gimple stmt2 on the stack.  */
+  gimple *stmt2 = (gimple *) XALLOCAVEC (char, gimple_size (GIMPLE_ASSIGN, 2));
+  gimple_init (stmt2, GIMPLE_ASSIGN, 3);
+  gimple_assign_set_rhs_code (stmt2, code2);
+  gimple_assign_set_rhs1 (stmt2, op2a);
+  gimple_assign_set_rhs2 (stmt2, op2b);
+
+  /* Allocate SSA names(lhs1) on the stack.  */
+  tree lhs1 = (tree)XALLOCA (tree_ssa_name);
+  memset (lhs1, 0, sizeof (tree_ssa_name));
+  TREE_SET_CODE (lhs1, SSA_NAME);
+  TREE_TYPE (lhs1) = type;
+  init_ssa_name_imm_use (lhs1);
+
+  /* Allocate SSA names(lhs2) on the stack.  */
+  tree lhs2 = (tree)XALLOCA (tree_ssa_name);
+  memset (lhs2, 0, sizeof (tree_ssa_name));
+  TREE_SET_CODE (lhs2, SSA_NAME);
+  TREE_TYPE (lhs2) = type;
+  init_ssa_name_imm_use (lhs2);
+
+  gimple_assign_set_lhs (stmt1, lhs1);
+  gimple_assign_set_lhs (stmt2, lhs2);
+
+  gimple_match_op op (gimple_match_cond::UNCOND, code,
+		  type, gimple_assign_lhs (stmt1),
+		  gimple_assign_lhs (stmt2));
+  if (op.resimplify (NULL, follow_all_ssa_edges))
+{
+  if (gimple_simplified_result_is_gimple_val (&op))
+	{
+	  tree res = op.ops[0];
+	  switch (TREE_CODE (res))
+	{
+	case SSA_NAME:
+		{
+		  gimple *def = SSA_NAME_DEF_STMT (res);
+
+		  if (!is_gimple_assign (def)
+		  || TREE_CODE_CLASS (gimple_assign_rhs_code (def))
+		  != tcc_comparison)
+		return NULL_TREE;
+
+		  return fold_build2 (gimple_assign_rhs_code (def),
+  type, gimple_assign_rhs1 (def),
+  gimple_assign_rhs2 (def));
+		}
+	case INTEGER_CST:
+	  /* Fold expression to boolean_true_node or boolean_false_node.  */
+	  return res;
+	default:
+	  return NULL_TREE;
+	}
+	}
+}
+
+  return NULL_TREE;
+}
+
 /* Try to simplify the AND of two comparisons, specified by
(OP1A CODE1 OP1B) and (OP2B CODE2 OP2B), respectively.
If this can be simplified to a single expression (without requiring
@@ -5845,11 +5928,17 @@ tree
 maybe_fold_and_comparisons (enum tree_code code1, tree op1a, tree op1b,
 			enum tree_code code2, tree op2a, tree op2b)
 {
-  tree t = and_comparisons_1 (code1, op

[PATCH 3/5] Rewrite part of and_comparisons_1 into match.pd.

[Martin Liška]

Hi.

The patch is about transition of and_comparisons_1 matching
into match.pd.

Patch can bootstrap on x86_64-linux-gnu and survives regression tests.

Ready to be installed?
Thanks,
Martin
>From 15045058d6caf84734ea949a297b6e31d9a8647c Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Fri, 6 Sep 2019 12:34:49 +0200
Subject: [PATCH 3/5] Rewrite part of and_comparisons_1 into match.pd.

gcc/ChangeLog:

2019-09-09  Martin Liska  

	* genmatch.c (dt_node::append_simplify): Ignore warning
	for the same location.
	* gimple-fold.c (same_bool_result_p): Handle newly
	created SSA_NAMEs ar arguments.
	(and_comparisons_1): Add new argument gimple_stmt_iterator.
	(and_var_with_comparison): Likewise.
	(and_var_with_comparison_1): Likewise.
	(or_comparisons_1): Likewise.
	(or_var_with_comparison): Likewise.
	(or_var_with_comparison_1): Likewise.
	(maybe_fold_comparisons_from_match_pd): Handle creation
	of temporary SSA_NAMEs. Add new argument gimple_stmt_iterator.
	(maybe_fold_and_comparisons): Likewise.
	(maybe_fold_or_comparisons): Likewise.
	* gimple-fold.h (maybe_fold_and_comparisons): Likewise.
	(maybe_fold_or_comparisons): Likewise.
	* match.pd: Add rules for (X OP1 CST1) && (X OP2 CST2).
	* tree-if-conv.c (fold_or_predicates): Do not
	pass gimple_stmt_iterator.
	* tree-ssa-ifcombine.c (ifcombine_ifandif): Pass gimple_stmt_iterator.
	* tree-ssa-reassoc.c (eliminate_redundant_comparison): Do not
	pass gimple_stmt_iterator.
	(optimize_vec_cond_expr): Likewise.
---
 gcc/genmatch.c   |   4 +-
 gcc/gimple-fold.c| 261 +--
 gcc/gimple-fold.h|   6 +-
 gcc/match.pd |  68 ++
 gcc/tree-if-conv.c   |   2 +-
 gcc/tree-ssa-ifcombine.c |   5 +-
 gcc/tree-ssa-reassoc.c   |  11 +-
 7 files changed, 172 insertions(+), 185 deletions(-)

diff --git a/gcc/genmatch.c b/gcc/genmatch.c
index 2e7bf27eeda..b7194448a0f 100644
--- a/gcc/genmatch.c
+++ b/gcc/genmatch.c
@@ -1894,9 +1894,11 @@ dt_node *
 dt_node::append_simplify (simplify *s, unsigned pattern_no,
 			  dt_operand **indexes)
 {
+  dt_simplify *s2;
   dt_simplify *n = new dt_simplify (s, pattern_no, indexes);
   for (unsigned i = 0; i < kids.length (); ++i)
-if (dt_simplify *s2 = dyn_cast  (kids[i]))
+if ((s2 = dyn_cast  (kids[i]))
+	&& s->match->location != s2->s->match->location)
   {
 	warning_at (s->match->location, "duplicate pattern");
 	warning_at (s2->s->match->location, "previous pattern defined here");
diff --git a/gcc/gimple-fold.c b/gcc/gimple-fold.c
index 8a9eca13b87..f9971c004b7 100644
--- a/gcc/gimple-fold.c
+++ b/gcc/gimple-fold.c
@@ -5350,6 +5350,19 @@ same_bool_result_p (const_tree op1, const_tree op2)
   if (operand_equal_p (op1, op2, 0))
 return true;
 
+  /* Function maybe_fold_comparisons_from_match_pd creates temporary
+ SSA_NAMEs.  */
+  if (TREE_CODE (op1) == SSA_NAME && TREE_CODE (op2) == SSA_NAME)
+{
+  gimple *s = SSA_NAME_DEF_STMT (op2);
+  if (is_gimple_assign (s))
+	return same_bool_comparison_p (op1, gimple_assign_rhs_code (s),
+   gimple_assign_rhs1 (s),
+   gimple_assign_rhs2 (s));
+  else
+	return false;
+}
+
   /* Check the cases where at least one of the operands is a comparison.
  These are a bit smarter than operand_equal_p in that they apply some
  identifies on SSA_NAMEs.  */
@@ -5372,22 +5385,28 @@ same_bool_result_p (const_tree op1, const_tree op2)
 
 static tree
 and_comparisons_1 (enum tree_code code1, tree op1a, tree op1b,
-		   enum tree_code code2, tree op2a, tree op2b);
+		   enum tree_code code2, tree op2a, tree op2b,
+		   gimple_stmt_iterator *gsi);
 static tree
 and_var_with_comparison (tree var, bool invert,
-			 enum tree_code code2, tree op2a, tree op2b);
+			 enum tree_code code2, tree op2a, tree op2b,
+			 gimple_stmt_iterator *gsi);
 static tree
 and_var_with_comparison_1 (gimple *stmt,
-			   enum tree_code code2, tree op2a, tree op2b);
+			   enum tree_code code2, tree op2a, tree op2b,
+			   gimple_stmt_iterator *gsi);
 static tree
 or_comparisons_1 (enum tree_code code1, tree op1a, tree op1b,
-		  enum tree_code code2, tree op2a, tree op2b);
+		  enum tree_code code2, tree op2a, tree op2b,
+		  gimple_stmt_iterator *gsi);
 static tree
 or_var_with_comparison (tree var, bool invert,
-			enum tree_code code2, tree op2a, tree op2b);
+			enum tree_code code2, tree op2a, tree op2b,
+			gimple_stmt_iterator *gsi);
 static tree
 or_var_with_comparison_1 (gimple *stmt,
-			  enum tree_code code2, tree op2a, tree op2b);
+			  enum tree_code code2, tree op2a, tree op2b,
+			  gimple_stmt_iterator *gsi);
 
 /* Helper function for and_comparisons_1:  try to simplify the AND of the
ssa variable VAR with the comparison specified by (OP2A CODE2 OP2B).
@@ -5396,7 +5415,8 @@ or_var_with_comparison_1 (gimple *stmt,
 
 static tree
 and_var_with_comparison (tree var, bool invert,
-			 enum tree_code code2, tree op2a, tree op2b)
+			 enum tree_code code2, tree op2a, tree op2b,
+			 gimp

[PATCH 4/5] Rewrite first part of or_comparisons_1 into match.pd.

[Martin Liška]

Hi.

Next part if about transition of part of the OR patterns
into match.pd.

Patch can bootstrap on x86_64-linux-gnu and survives regression tests.

Ready to be installed?
Thanks,
Martin
>From 0cc83b72025d243e9e6ebaa9a85c68c17f9cd09a Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Fri, 6 Sep 2019 12:47:01 +0200
Subject: [PATCH 4/5] Rewrite first part of or_comparisons_1 into match.pd.

gcc/ChangeLog:

2019-09-09  Martin Liska  

	* gimple-fold.c (or_comparisons_1): Remove rules
	moved to ...
	* match.pd: ... here.
---
 gcc/gimple-fold.c | 87 +--
 gcc/match.pd  | 29 
 2 files changed, 30 insertions(+), 86 deletions(-)

diff --git a/gcc/gimple-fold.c b/gcc/gimple-fold.c
index f9971c004b7..e691780591c 100644
--- a/gcc/gimple-fold.c
+++ b/gcc/gimple-fold.c
@@ -6088,93 +6088,8 @@ or_comparisons_1 (enum tree_code code1, tree op1a, tree op1b,
 {
   int cmp = tree_int_cst_compare (op1b, op2b);
 
-  /* If we have (op1a != op1b), we should either be able to
-	 return that or TRUE, depending on whether the constant op1b
-	 also satisfies the other comparison against op2b.  */
-  if (code1 == NE_EXPR)
-	{
-	  bool done = true;
-	  bool val;
-	  switch (code2)
-	{
-	case EQ_EXPR: val = (cmp == 0); break;
-	case NE_EXPR: val = (cmp != 0); break;
-	case LT_EXPR: val = (cmp < 0); break;
-	case GT_EXPR: val = (cmp > 0); break;
-	case LE_EXPR: val = (cmp <= 0); break;
-	case GE_EXPR: val = (cmp >= 0); break;
-	default: done = false;
-	}
-	  if (done)
-	{
-	  if (val)
-		return boolean_true_node;
-	  else
-		return fold_build2 (code1, boolean_type_node, op1a, op1b);
-	}
-	}
-  /* Likewise if the second comparison is a != comparison.  */
-  else if (code2 == NE_EXPR)
-	{
-	  bool done = true;
-	  bool val;
-	  switch (code1)
-	{
-	case EQ_EXPR: val = (cmp == 0); break;
-	case NE_EXPR: val = (cmp != 0); break;
-	case LT_EXPR: val = (cmp > 0); break;
-	case GT_EXPR: val = (cmp < 0); break;
-	case LE_EXPR: val = (cmp >= 0); break;
-	case GE_EXPR: val = (cmp <= 0); break;
-	default: done = false;
-	}
-	  if (done)
-	{
-	  if (val)
-		return boolean_true_node;
-	  else
-		return fold_build2 (code2, boolean_type_node, op2a, op2b);
-	}
-	}
-
-  /* See if an equality test is redundant with the other comparison.  */
-  else if (code1 == EQ_EXPR)
-	{
-	  bool val;
-	  switch (code2)
-	{
-	case EQ_EXPR: val = (cmp == 0); break;
-	case NE_EXPR: val = (cmp != 0); break;
-	case LT_EXPR: val = (cmp < 0); break;
-	case GT_EXPR: val = (cmp > 0); break;
-	case LE_EXPR: val = (cmp <= 0); break;
-	case GE_EXPR: val = (cmp >= 0); break;
-	default:
-	  val = false;
-	}
-	  if (val)
-	return fold_build2 (code2, boolean_type_node, op2a, op2b);
-	}
-  else if (code2 == EQ_EXPR)
-	{
-	  bool val;
-	  switch (code1)
-	{
-	case EQ_EXPR: val = (cmp == 0); break;
-	case NE_EXPR: val = (cmp != 0); break;
-	case LT_EXPR: val = (cmp > 0); break;
-	case GT_EXPR: val = (cmp < 0); break;
-	case LE_EXPR: val = (cmp >= 0); break;
-	case GE_EXPR: val = (cmp <= 0); break;
-	default:
-	  val = false;
-	}
-	  if (val)
-	return fold_build2 (code1, boolean_type_node, op1a, op1b);
-	}
-
   /* Chose the less restrictive of two < or <= comparisons.  */
-  else if ((code1 == LT_EXPR || code1 == LE_EXPR)
+  if ((code1 == LT_EXPR || code1 == LE_EXPR)
 	   && (code2 == LT_EXPR || code2 == LE_EXPR))
 	{
 	  if ((cmp < 0) || (cmp == 0 && code1 == LT_EXPR))
diff --git a/gcc/match.pd b/gcc/match.pd
index 2c64c460fda..2923f5b4cbe 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -2017,6 +2017,35 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
{ constant_boolean_node (false, type); })
   ))
 
+/* Convert (X == CST1) || (X OP2 CST2) to a known value
+   based on CST1 OP2 CST2.  Similarly for (X != CST1).  */
+
+(for code1 (eq ne)
+ (for code2 (eq ne lt gt le ge)
+  (for or (truth_or bit_ior)
+   (simplify
+(or:c (code1 @0 INTEGER_CST@1) (code2 @0 INTEGER_CST@2))
+ (with
+  {
+   int cmp = tree_int_cst_compare (@1, @2);
+   bool val;
+   switch (code2)
+	 {
+	 case EQ_EXPR: val = (cmp == 0); break;
+	 case NE_EXPR: val = (cmp != 0); break;
+	 case LT_EXPR: val = (cmp < 0); break;
+	 case GT_EXPR: val = (cmp > 0); break;
+	 case LE_EXPR: val = (cmp <= 0); break;
+	 case GE_EXPR: val = (cmp >= 0); break;
+	 default: gcc_unreachable ();
+	 }
+  }
+  (switch
+   (if (code1 == EQ_EXPR && val) (code2 @0 @2))
+   (if (code1 == NE_EXPR && val) { constant_boolean_node (true, type); })
+   (if (code1 == NE_EXPR && !val) (code1 @0 @1
+
+
 /* We can't reassociate at all for saturating types.  */
 (if (!TYPE_SATURATING (type))
 
-- 
2.23.0

[PATCH 5/5] Rewrite second part of or_comparisons_1 into match.pd.

[Martin Liška]

And finally the second part of OR patterns.

Patch can bootstrap on x86_64-linux-gnu and survives regression tests.

Ready to be installed?
Thanks,
Martin
>From 621d25811179bce8a8ad58a88b742528e97917d6 Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Fri, 6 Sep 2019 12:59:36 +0200
Subject: [PATCH 5/5] Rewrite second part of or_comparisons_1 into match.pd.

gcc/ChangeLog:

2019-09-09  Martin Liska  

	* gimple-fold.c (or_comparisons_1): Remove rules moved
	to ...
	* match.pd: ... here.
---
 gcc/gimple-fold.c | 45 -
 gcc/match.pd  | 39 +++
 2 files changed, 39 insertions(+), 45 deletions(-)

diff --git a/gcc/gimple-fold.c b/gcc/gimple-fold.c
index e691780591c..ac24f3b408b 100644
--- a/gcc/gimple-fold.c
+++ b/gcc/gimple-fold.c
@@ -6080,51 +6080,6 @@ or_comparisons_1 (enum tree_code code1, tree op1a, tree op1b,
 	return t;
 }
 
-  /* If both comparisons are of the same value against constants, we might
- be able to merge them.  */
-  if (operand_equal_p (op1a, op2a, 0)
-  && TREE_CODE (op1b) == INTEGER_CST
-  && TREE_CODE (op2b) == INTEGER_CST)
-{
-  int cmp = tree_int_cst_compare (op1b, op2b);
-
-  /* Chose the less restrictive of two < or <= comparisons.  */
-  if ((code1 == LT_EXPR || code1 == LE_EXPR)
-	   && (code2 == LT_EXPR || code2 == LE_EXPR))
-	{
-	  if ((cmp < 0) || (cmp == 0 && code1 == LT_EXPR))
-	return fold_build2 (code2, boolean_type_node, op2a, op2b);
-	  else
-	return fold_build2 (code1, boolean_type_node, op1a, op1b);
-	}
-
-  /* Likewise chose the less restrictive of two > or >= comparisons.  */
-  else if ((code1 == GT_EXPR || code1 == GE_EXPR)
-	   && (code2 == GT_EXPR || code2 == GE_EXPR))
-	{
-	  if ((cmp > 0) || (cmp == 0 && code1 == GT_EXPR))
-	return fold_build2 (code2, boolean_type_node, op2a, op2b);
-	  else
-	return fold_build2 (code1, boolean_type_node, op1a, op1b);
-	}
-
-  /* Check for singleton ranges.  */
-  else if (cmp == 0
-	   && ((code1 == LT_EXPR && code2 == GT_EXPR)
-		   || (code1 == GT_EXPR && code2 == LT_EXPR)))
-	return fold_build2 (NE_EXPR, boolean_type_node, op1a, op2b);
-
-  /* Check for less/greater pairs that don't restrict the range at all.  */
-  else if (cmp >= 0
-	   && (code1 == LT_EXPR || code1 == LE_EXPR)
-	   && (code2 == GT_EXPR || code2 == GE_EXPR))
-	return boolean_true_node;
-  else if (cmp <= 0
-	   && (code1 == GT_EXPR || code1 == GE_EXPR)
-	   && (code2 == LT_EXPR || code2 == LE_EXPR))
-	return boolean_true_node;
-}
-
   /* Perhaps the first comparison is (NAME != 0) or (NAME == 1) where
  NAME's definition is a truth value.  See if there are any simplifications
  that can be done against the NAME's definition.  */
diff --git a/gcc/match.pd b/gcc/match.pd
index 2923f5b4cbe..15916800bc1 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -2045,6 +2045,45 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
(if (code1 == NE_EXPR && val) { constant_boolean_node (true, type); })
(if (code1 == NE_EXPR && !val) (code1 @0 @1
 
+/* Convert (X OP1 CST1) || (X OP2 CST2).  */
+
+(for code1 (lt le gt ge)
+ (for code2 (lt le gt ge)
+  (for or (truth_or bit_ior)
+   (simplify
+   (or (code1:c @0 INTEGER_CST@1) (code2:c @0 INTEGER_CST@2))
+(with
+ {
+  int cmp = tree_int_cst_compare (@1, @2);
+ }
+ (switch
+  /* Chose the more restrictive of two < or <= comparisons.  */
+  (if ((code1 == LT_EXPR || code1 == LE_EXPR)
+	   && (code2 == LT_EXPR || code2 == LE_EXPR))
+   (if ((cmp < 0) || (cmp == 0 && code1 == LT_EXPR))
+	(code2 @0 @2)
+	(code1 @0 @1)))
+  /* Likewise chose the more restrictive of two > or >= comparisons.  */
+  (if ((code1 == GT_EXPR || code1 == GE_EXPR)
+	   && (code2 == GT_EXPR || code2 == GE_EXPR))
+   (if ((cmp > 0) || (cmp == 0 && code1 == GT_EXPR))
+	(code2 @0 @2)
+	(code1 @0 @1)))
+  /* Check for singleton ranges.  */
+  (if (cmp == 0
+	   && ((code1 == LT_EXPR && code2 == GT_EXPR)
+	   || (code1 == GT_EXPR && code2 == LT_EXPR)))
+   (ne @0 @2))
+  /* Check for disjoint ranges.  */
+  (if (cmp >= 0
+	   && (code1 == LT_EXPR || code1 == LE_EXPR)
+	   && (code2 == GT_EXPR || code2 == GE_EXPR))
+   { constant_boolean_node (true, type); })
+  (if (cmp <= 0
+	   && (code1 == GT_EXPR || code1 == GE_EXPR)
+	   && (code2 == LT_EXPR || code2 == LE_EXPR))
+   { constant_boolean_node (true, type); })
+  ))
 
 /* We can't reassociate at all for saturating types.  */
 (if (!TYPE_SATURATING (type))
-- 
2.23.0

Re: [PATCH] Come up with json::integer_number and use it in GCOV.

[Martin Liška]

PING^3

On 8/30/19 10:55 AM, Martin Liška wrote:
> PING^2
> 
> On 8/26/19 2:34 PM, Martin Liška wrote:
>> PING^1
>>
>> On 8/13/19 1:51 PM, Martin Liška wrote:
>>> On 8/2/19 2:40 PM, David Malcolm wrote:
 Something that occurred to me reading the updated patch: maybe it would
 make things easier to have utility member functions of json::object to
 implicitly make the child, e.g.:

 void
 json::object::set (const char *key, long v)
 {
set (key, new json::integer_number (v));
 }

 so that all those calls can be just:

   obj->set ("line", exploc.line);
   obj->set ("column", exploc.column);

 etc (assuming overloading is unambiguous).

 But that's probably orthogonal to this patch.
>>>
>>> Looks good to me. It's a candidate for a follow up patch.
>>>


> And I changed all occurrences of float_number with integer_number
> as you suggested.
 Thanks.

> I'm currently testing the updated patch.
> Martin
 The updated patch looks good to me, but technically I'm not a reviewer
 for these files.
>>>
>>> Sure, I hope @Jakub or @Richi can approve me that?
>>> Thanks,
>>> Martin
>>>

 Dave
>>>
>>
> 

Re: [PATCH] Prevent LTO section collision for a symbol name starting with '*'.

[Martin Liška]

PING^1

On 8/26/19 12:04 PM, Martin Liška wrote:
> Ok. I have a semi-working patch that has issues for inline clones.
> When we call cgraph_node::get_untransformed_body for an inline clone,
> then one needs to use clone_of->order to find proper LTO stream.
> 
> What's more problematic is that such clone can be expanded:
> 
> f/12 (f) @0x7769f708
>   Type: function definition analyzed
>   Visibility: external public
>   References: mumble.lto_priv.0/8 (write)
>   Referring: 
>   Read from file: /tmp/cciAkXHp.ltrans1.o
>   Function f/12 is inline copy in main/0
>   Availability: local
>   Function flags: count:1073741824 (estimated locally) local nonfreeing_fn 
> executed_once
>   Called by: main/0 (inlined) (1073741824 (estimated locally),1.00 per call) 
>   Calls: 
> 
> and lost. So we end up with an orphan and we ICE with:
> 
> /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/lto/20081112_0.c: In 
> function ‘main’:
> /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/lto/20081112_0.c:10:3: 
> fatal error: /tmp/cciAkXHp.ltrans1.o: section f is missing
> 
> So usage of symtab_node::order seems awkward to me :/
> 
> Martin
> 

Re: [PATCH] Make LTO link pick up compile-time -g

[Matthias Klose]

On 09.09.19 14:02, Richard Biener wrote:

So this is really a very poor mans solution that also might
uncover issues with -g0 at compile-time vs. -g at link-time
if there are mixed -g0/g TUs in the LTO link.


Could this be documented, at least in the man page? e.g. invoke.texi.  As a 
bonus I would very much welcome a section in the user manual about LTO building. 
 E.g. what will work, what currently doesn't work, etc.  Happy to review and 
extend such documentation, but I don't feel comfortable to write that on my own.


Matthias

[PATCH] Rename Deprecated to IgnoreWarn in *.opt files.

[Martin Liška]

Hi.

I'm suggesting to rename Deprecated to IgnoreWarn as deprecated
means that an option is still working, but marked as obsolete.
We use the name for options that removed (no longer supported),
but still supported for backward compatibility.

Patch can bootstrap on x86_64-linux-gnu and survives regression tests.

Ready to be installed?
Thanks,
Martin

gcc/ChangeLog:

2019-09-09  Martin Liska  

* common.opt: Use newly added IgnoreWarn.
* config/aarch64/aarch64.opt: Likewise.
* config/arm/arm.opt: Likewise.
* config/i386/i386.opt: Likewise.
* config/ia64/ia64.opt: Likewise.
* config/rs6000/rs6000.opt: Likewise.
* doc/options.texi: Document IgnoreWarn properly.
* dwarf2out.c (gen_producer_string): Handle renamed
OPT_SPECIAL_ignore_warn.
* lto-opts.c (lto_write_options): Likewise.
* lto-wrapper.c (merge_and_complain): Likewise.
* opts-common.c (decode_cmdline_option): Likewise.
(prune_options): Likewise.
(read_cmdline_option): Likewise.
(control_warning_option): Likewise.
* opts.c (print_filtered_help): Likewise.
* optc-gen.awk: Parse for IgnoreWarn and make usage
of Deprecated an error.
* opth-gen.awk: Generate new OPT_SPECIAL_ignore_warn.

gcc/c-family/ChangeLog:

2019-09-09  Martin Liska  

* c.opt: Use newly added IgnoreWarn.
---
 gcc/c-family/c.opt | 92 +-
 gcc/common.opt |  8 +--
 gcc/config/aarch64/aarch64.opt |  2 +-
 gcc/config/arm/arm.opt |  2 +-
 gcc/config/i386/i386.opt   |  9 ++--
 gcc/config/ia64/ia64.opt   |  4 +-
 gcc/config/rs6000/rs6000.opt   |  6 +--
 gcc/doc/options.texi   |  6 +--
 gcc/dwarf2out.c|  2 +-
 gcc/lto-opts.c |  2 +-
 gcc/lto-wrapper.c  |  2 +-
 gcc/optc-gen.awk   | 10 ++--
 gcc/opth-gen.awk   |  2 +-
 gcc/opts-common.c  | 10 ++--
 gcc/opts.c |  2 +-
 15 files changed, 79 insertions(+), 80 deletions(-)


diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index c5804470d47..3c26a6b2e9e 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -428,7 +428,7 @@ C ObjC C++ ObjC++ Var(warn_char_subscripts) Warning LangEnabledBy(C ObjC C++ Obj
 Warn about subscripts whose type is \"char\".
 
 Wchkp
-C ObjC C++ ObjC++ Warning Deprecated
+C ObjC C++ ObjC++ Warning IgnoreWarn
 Removed in GCC 9.  This switch has no effect.
 
 Wclobbered
@@ -864,7 +864,7 @@ C ObjC Var(warn_missing_prototypes) Warning
 Warn about global functions without prototypes.
 
 Wmudflap
-C ObjC C++ ObjC++ Deprecated
+C ObjC C++ ObjC++ IgnoreWarn
 
 Wmultichar
 C ObjC C++ ObjC++ CPP(warn_multichar) CppReason(CPP_W_MULTICHAR) Var(cpp_warn_multichar) Init(0) Warning
@@ -1302,14 +1302,14 @@ C++ ObjC++ Joined RejectNegative Var(aligned_new_threshold) UInteger Init(-1)
 -faligned-new= Use C++17 over-aligned type allocation for alignments greater than N.
 
 fall-virtual
-C++ ObjC++ Deprecated
+C++ ObjC++ IgnoreWarn
 
 fallow-parameterless-variadic-functions
 C ObjC Var(flag_allow_parameterless_variadic_functions)
 Allow variadic functions without named parameter.
 
 falt-external-templates
-C++ ObjC++ Deprecated
+C++ ObjC++ IgnoreWarn
 No longer supported.
 
 fasm
@@ -1337,86 +1337,86 @@ Enable the char8_t fundamental type and use it as the type for UTF-8 string
 and character literals.
 
 fcheck-pointer-bounds
-C ObjC C++ ObjC++ LTO Deprecated
+C ObjC C++ ObjC++ LTO IgnoreWarn
 Removed in GCC 9.  This switch has no effect.
 
 fchkp-check-incomplete-type
-C ObjC C++ ObjC++ LTO Deprecated
+C ObjC C++ ObjC++ LTO IgnoreWarn
 Removed in GCC 9.  This switch has no effect.
 
 fchkp-zero-input-bounds-for-main
-C ObjC C++ ObjC++ LTO Deprecated
+C ObjC C++ ObjC++ LTO IgnoreWarn
 Removed in GCC 9.  This switch has no effect.
 
 fchkp-first-field-has-own-bounds
-C ObjC C++ ObjC++ LTO Deprecated RejectNegative
+C ObjC C++ ObjC++ LTO IgnoreWarn RejectNegative
 Removed in GCC 9.  This switch has no effect.
 
 fchkp-narrow-bounds
-C ObjC C++ ObjC++ LTO Deprecated
+C ObjC C++ ObjC++ LTO IgnoreWarn
 Removed in GCC 9.  This switch has no effect.
 
 fchkp-narrow-to-innermost-array
-C ObjC C++ ObjC++ LTO Deprecated RejectNegative
+C ObjC C++ ObjC++ LTO IgnoreWarn RejectNegative
 Removed in GCC 9.  This switch has no effect.
 
 fchkp-flexible-struct-trailing-arrays
-C ObjC C++ ObjC++ LTO Deprecated
+C ObjC C++ ObjC++ LTO IgnoreWarn
 Removed in GCC 9.  This switch has no effect.
 
 fchkp-optimize
-C ObjC C++ ObjC++ LTO Deprecated
+C ObjC C++ ObjC++ LTO IgnoreWarn
 
 fchkp-use-fast-string-functions
-C ObjC C++ ObjC++ LTO Deprecated
+C ObjC C++ ObjC++ LTO IgnoreWarn
 Removed in GCC 9.  This switch has no effect.
 
 fchkp-use-nochk-string-functions
-C ObjC C++ ObjC++ LTO Deprecated
+C ObjC C++ ObjC++ LTO IgnoreWarn
 Removed in GCC 9.  This switch has no effect.
 
 fchkp-use-static-bounds
-C ObjC C++ Obj

Re: [PATCH 1/2] Auto-generate maybe_fold_and/or_comparisons from match.pd

[Richard Biener]

On Mon, 9 Sep 2019, Martin Liška wrote:

> Hi.
> 
> I'm sending slightly updated version of the patch where we
> need to properly select type in maybe_fold_comparisons_from_match_pd
> function for the created SSA_NAMEs. We can be called for a VECTOR_TYPE
> and so that we can't return a boolean_type_node.
> 
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> 
> Ready to be installed?

2019-07-16  Li Jia He  
Martin Liska  

* gimple.h (gimple_init): Declare.
(gimple_size): Likewise.
* gimple.c (gimple_init): Remove static and inline restrictions.
(gimple_alloc): Only allocate memory and call gimple_init.
(gimple_size): Likewise.

Likewise?

* tree-ssanames.c (init_ssa_name_imm_use): Use make_ssa_name_fn.
(make_ssa_name_fn): New.

You didn't touch make_ssa_name_fn.

Since we're needing another iteration:

+  /* Allocate gimple stmt1 on the stack.  */
+  gimple *stmt1 = (gimple *) XALLOCAVEC (char, gimple_size 
(GIMPLE_ASSIGN, 2));

You can use gassign *stmt1 here so all the gimple_assign_ fns below
get cheaper.

+  if (op.resimplify (NULL, follow_all_ssa_edges))
+{
+  if (gimple_simplified_result_is_gimple_val (&op))
+   {
+ tree res = op.ops[0];
+ switch (TREE_CODE (res))
+   {
+   case SSA_NAME:
+   {
+ gimple *def = SSA_NAME_DEF_STMT (res);

you shouldn't expand SSA names here unless that SSA name is
exactly lhs1 or lhs2 from above.  So

 if (res == lhs1)
   return build2 (...);
 else if (res == lhs2)
   return build2 (..);
 else
   return res;

plus you miss the case where 'op' became a simplified comparison
in itself.  So,

 if (op.code.is_tree_code ()
 && TREE_CODE_CLASS ((enum tree_code)op.code) == tcc_comparison)
   {
  tree op0 = op.ops[0];
  tree op1 = op.ops[1];
  if (op0 == lhs1 || op0 == lhs2 || op1 == lhs1 || op1 == lhs2)
return NULL_TREE;  /* not simple */
  return build2 ((enum tree_code)op.code, op.type,
 op0, op1);
   }

note you need not fold_ again.  It's of course ugly that we
need to build a GENERIC tree here but that's the current interface
and thus OK at the moment.

Thanks,
Richard.

Re: [PATCH 1/2] Auto-generate maybe_fold_and/or_comparisons from match.pd

[Marc Glisse]

On Mon, 9 Sep 2019, Martin Liška wrote:


I'm sending slightly updated version of the patch where we
need to properly select type in maybe_fold_comparisons_from_match_pd
function for the created SSA_NAMEs. We can be called for a VECTOR_TYPE
and so that we can't return a boolean_type_node.


+  tree type = TREE_TYPE (op1a);
+  if (TREE_CODE (type) != VECTOR_TYPE)
+type = boolean_type_node;

Don't you need build_same_sized_truth_vector_type or something, for 
instance with AVX512?


Also, IIRC EQ_EXPR for vectors can return either a vector or a boolean. I 
don't know if we can end up here with both versions, but if we can, 
guessing the type could be dangerous. Would it be hard to add a type 
argument to those functions and delegate this to the caller? Any better 
idea (maybe this is already safe and I am just missing it)?


--
Marc Glisse

Re: [PATCH 1/2] Auto-generate maybe_fold_and/or_comparisons from match.pd

[Martin Liška]

On 9/9/19 3:10 PM, Marc Glisse wrote:
> On Mon, 9 Sep 2019, Martin Liška wrote:
> 
>> I'm sending slightly updated version of the patch where we
>> need to properly select type in maybe_fold_comparisons_from_match_pd
>> function for the created SSA_NAMEs. We can be called for a VECTOR_TYPE
>> and so that we can't return a boolean_type_node.
> 
> +  tree type = TREE_TYPE (op1a);
> +  if (TREE_CODE (type) != VECTOR_TYPE)
> +    type = boolean_type_node;
> 
> Don't you need build_same_sized_truth_vector_type or something, for instance 
> with AVX512?
> 
> Also, IIRC EQ_EXPR for vectors can return either a vector or a boolean. I 
> don't know if we can end up here with both versions, but if we can, guessing 
> the type could be dangerous. Would it be hard to add a type argument to those 
> functions and delegate this to the caller? Any better idea (maybe this is 
> already safe and I am just missing it)?

Richi can you help us here? I'm not sure what guarantees do we have here in 
GIMPLE?

Martin

> 

Re: [PATCH 1/2] Auto-generate maybe_fold_and/or_comparisons from match.pd

[Richard Biener]

On Mon, 9 Sep 2019, Martin Liška wrote:

> On 9/9/19 3:10 PM, Marc Glisse wrote:
> > On Mon, 9 Sep 2019, Martin Liška wrote:
> > 
> >> I'm sending slightly updated version of the patch where we
> >> need to properly select type in maybe_fold_comparisons_from_match_pd
> >> function for the created SSA_NAMEs. We can be called for a VECTOR_TYPE
> >> and so that we can't return a boolean_type_node.
> > 
> > +  tree type = TREE_TYPE (op1a);
> > +  if (TREE_CODE (type) != VECTOR_TYPE)
> > +    type = boolean_type_node;
> > 
> > Don't you need build_same_sized_truth_vector_type or something, for 
> > instance with AVX512?
> > 
> > Also, IIRC EQ_EXPR for vectors can return either a vector or a boolean. I 
> > don't know if we can end up here with both versions, but if we can, 
> > guessing the type could be dangerous. Would it be hard to add a type 
> > argument to those functions and delegate this to the caller? Any better 
> > idea (maybe this is already safe and I am just missing it)?
> 
> Richi can you help us here? I'm not sure what guarantees do we have here in 
> GIMPLE?

Oops, I missed this hunk - the caller needs to pass this down, but at 
least from the ifcombine use we are always coming from a if (a CMP b)
context and thus a boolean_type_node result type.  For the reassoc
case there's indeed nothing preventing from vector typed comparisons
sneaking in here, likewise recursion via or_var_with_comparison_1
might run into vectors.

Thus the toplevel interface has to pass down the (common) type of
the two comparisons.

Richard.

Re: [PATCH 1/2] Auto-generate maybe_fold_and/or_comparisons from match.pd

[Martin Liška]

On 9/9/19 3:10 PM, Richard Biener wrote:
> On Mon, 9 Sep 2019, Martin Liška wrote:
> 
>> Hi.
>>
>> I'm sending slightly updated version of the patch where we
>> need to properly select type in maybe_fold_comparisons_from_match_pd
>> function for the created SSA_NAMEs. We can be called for a VECTOR_TYPE
>> and so that we can't return a boolean_type_node.
>>
>> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>>
>> Ready to be installed?
> 
> 2019-07-16  Li Jia He  
> Martin Liska  
> 
> * gimple.h (gimple_init): Declare.
> (gimple_size): Likewise.
> * gimple.c (gimple_init): Remove static and inline restrictions.
> (gimple_alloc): Only allocate memory and call gimple_init.
> (gimple_size): Likewise.
> 
> Likewise?

Fixed.

> 
> * tree-ssanames.c (init_ssa_name_imm_use): Use make_ssa_name_fn.
> (make_ssa_name_fn): New.
> 
> You didn't touch make_ssa_name_fn.

Likewise here.

> 
> Since we're needing another iteration:
> 
> +  /* Allocate gimple stmt1 on the stack.  */
> +  gimple *stmt1 = (gimple *) XALLOCAVEC (char, gimple_size 
> (GIMPLE_ASSIGN, 2));
> 
> You can use gassign *stmt1 here so all the gimple_assign_ fns below
> get cheaper.
> 
> +  if (op.resimplify (NULL, follow_all_ssa_edges))
> +{
> +  if (gimple_simplified_result_is_gimple_val (&op))
> +   {
> + tree res = op.ops[0];
> + switch (TREE_CODE (res))
> +   {
> +   case SSA_NAME:
> +   {
> + gimple *def = SSA_NAME_DEF_STMT (res);
> 
> you shouldn't expand SSA names here unless that SSA name is
> exactly lhs1 or lhs2 from above.  So

Ah, got it.

> 
>  if (res == lhs1)
>return build2 (...);
>  else if (res == lhs2)
>return build2 (..);
>  else
>return res;
> 
> plus you miss the case where 'op' became a simplified comparison
> in itself.  So,

Yes, that part is included in part 3. I'm going to send the updated patch
3 as well soon.

> 
>  if (op.code.is_tree_code ()
>  && TREE_CODE_CLASS ((enum tree_code)op.code) == tcc_comparison)
>{
>   tree op0 = op.ops[0];
>   tree op1 = op.ops[1];
>   if (op0 == lhs1 || op0 == lhs2 || op1 == lhs1 || op1 == lhs2)
> return NULL_TREE;  /* not simple */
>   return build2 ((enum tree_code)op.code, op.type,
>  op0, op1);
>}
> 
> note you need not fold_ again.  It's of course ugly that we
> need to build a GENERIC tree here but that's the current interface
> and thus OK at the moment.

I see. But what I need is to insert newly created GIMPLE assignment to
the provided gimple sequence (gsi), right?

Thanks,
Martin

> 
> Thanks,
> Richard.
> 

>From a0b4daec604ee92ac8e76e416cd912d7d176a811 Mon Sep 17 00:00:00 2001
From: Li Jia He 
Date: Mon, 15 Jul 2019 00:30:25 -0500
Subject: [PATCH 1/5] Auto-generate maybe_fold_and/or_comparisons from match.pd

gcc/ChangeLog

2019-07-16  Li Jia He  
	Martin Liska  

	* gimple.h (gimple_init): Declare.
	(gimple_size): Likewise.
	* gimple.c (gimple_init): Remove static and inline restrictions.
	(gimple_alloc): Only allocate memory and call gimple_init.
	(gimple_size): Make it external and add new num_ops argument.
	* gimple-fold.c (maybe_fold_comparisons_from_match_pd): New function.
	(maybe_fold_and_comparisons): Modify and_comparisons_1 invocation and
	call maybe_fold_comparisons_from_match_pd.
	(maybe_fold_or_comparisons): Modify or_comparisons_1 invocation and
	call maybe_fold_comparisons_from_match_pd.
	* tree-ssanames.c (init_ssa_name_imm_use): New.
	(make_ssa_name_fn): Use make_ssa_name_fn.
	* tree-ssanames.h (init_ssa_name_imm_use): New.
---
 gcc/gimple-fold.c   | 108 
 gcc/gimple.c|  37 +--
 gcc/gimple.h|   2 +
 gcc/tree-ssanames.c |  21 ++---
 gcc/tree-ssanames.h |   1 +
 5 files changed, 138 insertions(+), 31 deletions(-)

diff --git a/gcc/gimple-fold.c b/gcc/gimple-fold.c
index fcffb9802b7..50cb3bf7e32 100644
--- a/gcc/gimple-fold.c
+++ b/gcc/gimple-fold.c
@@ -5834,6 +5834,85 @@ and_comparisons_1 (enum tree_code code1, tree op1a, tree op1b,
   return NULL_TREE;
 }
 
+/* Helper function for maybe_fold_and_comparisons and maybe_fold_or_comparisons
+   : try to simplify the AND/OR of the ssa variable VAR with the comparison
+   specified by (OP2A CODE2 OP2B) from match.pd.  Return NULL_EXPR if we can't
+   simplify this to a single expression.  As we are going to lower the cost
+   of building SSA names / gimple stmts significantly, we need to allocate
+   them ont the stack.  This will cause the code to be a bit ugly.  */
+
+static tree
+maybe_fold_comparisons_from_match_pd (enum tree_code code, enum tree_code code1,
+  tree op1a, tree op1b,
+  enum tree_code code2, tree op2a,
+  tree op2b)
+{
+  tree type = TREE_TYPE (op1a);
+  if (TREE_CODE (type) != VECTOR_

Re: [PATCH 3/5] Rewrite part of and_comparisons_1 into match.pd.

[Martin Liška]

On 9/9/19 2:24 PM, Martin Liška wrote:
> Hi.
> 
> The patch is about transition of and_comparisons_1 matching
> into match.pd.
> 
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> 
> Ready to be installed?
> Thanks,
> Martin
> 

Updated version (as mentioned in part 1).

Martin
>From a4127ffe3d55c67dc8ef78d62a27277807740995 Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Fri, 6 Sep 2019 12:34:49 +0200
Subject: [PATCH 3/5] Rewrite part of and_comparisons_1 into match.pd.

gcc/ChangeLog:

2019-09-09  Martin Liska  

	* genmatch.c (dt_node::append_simplify): Ignore warning
	for the same location.
	* gimple-fold.c (same_bool_result_p): Handle newly
	created SSA_NAMEs ar arguments.
	(and_comparisons_1): Add new argument gimple_stmt_iterator.
	(and_var_with_comparison): Likewise.
	(and_var_with_comparison_1): Likewise.
	(or_comparisons_1): Likewise.
	(or_var_with_comparison): Likewise.
	(or_var_with_comparison_1): Likewise.
	(maybe_fold_comparisons_from_match_pd): Handle creation
	of temporary SSA_NAMEs. Add new argument gimple_stmt_iterator.
	(maybe_fold_and_comparisons): Likewise.
	(maybe_fold_or_comparisons): Likewise.
	* gimple-fold.h (maybe_fold_and_comparisons): Likewise.
	(maybe_fold_or_comparisons): Likewise.
	* match.pd: Add rules for (X OP1 CST1) && (X OP2 CST2).
	* tree-if-conv.c (fold_or_predicates): Do not
	pass gimple_stmt_iterator.
	* tree-ssa-ifcombine.c (ifcombine_ifandif): Pass gimple_stmt_iterator.
	* tree-ssa-reassoc.c (eliminate_redundant_comparison): Do not
	pass gimple_stmt_iterator.
	(optimize_vec_cond_expr): Likewise.
---
 gcc/genmatch.c   |   4 +-
 gcc/gimple-fold.c| 266 ++-
 gcc/gimple-fold.h|   6 +-
 gcc/match.pd |  68 ++
 gcc/tree-if-conv.c   |   2 +-
 gcc/tree-ssa-ifcombine.c |   5 +-
 gcc/tree-ssa-reassoc.c   |  11 +-
 7 files changed, 177 insertions(+), 185 deletions(-)

diff --git a/gcc/genmatch.c b/gcc/genmatch.c
index 2e7bf27eeda..b7194448a0f 100644
--- a/gcc/genmatch.c
+++ b/gcc/genmatch.c
@@ -1894,9 +1894,11 @@ dt_node *
 dt_node::append_simplify (simplify *s, unsigned pattern_no,
 			  dt_operand **indexes)
 {
+  dt_simplify *s2;
   dt_simplify *n = new dt_simplify (s, pattern_no, indexes);
   for (unsigned i = 0; i < kids.length (); ++i)
-if (dt_simplify *s2 = dyn_cast  (kids[i]))
+if ((s2 = dyn_cast  (kids[i]))
+	&& s->match->location != s2->s->match->location)
   {
 	warning_at (s->match->location, "duplicate pattern");
 	warning_at (s2->s->match->location, "previous pattern defined here");
diff --git a/gcc/gimple-fold.c b/gcc/gimple-fold.c
index 50cb3bf7e32..d046603fd6f 100644
--- a/gcc/gimple-fold.c
+++ b/gcc/gimple-fold.c
@@ -5350,6 +5350,19 @@ same_bool_result_p (const_tree op1, const_tree op2)
   if (operand_equal_p (op1, op2, 0))
 return true;
 
+  /* Function maybe_fold_comparisons_from_match_pd creates temporary
+ SSA_NAMEs.  */
+  if (TREE_CODE (op1) == SSA_NAME && TREE_CODE (op2) == SSA_NAME)
+{
+  gimple *s = SSA_NAME_DEF_STMT (op2);
+  if (is_gimple_assign (s))
+	return same_bool_comparison_p (op1, gimple_assign_rhs_code (s),
+   gimple_assign_rhs1 (s),
+   gimple_assign_rhs2 (s));
+  else
+	return false;
+}
+
   /* Check the cases where at least one of the operands is a comparison.
  These are a bit smarter than operand_equal_p in that they apply some
  identifies on SSA_NAMEs.  */
@@ -5372,22 +5385,28 @@ same_bool_result_p (const_tree op1, const_tree op2)
 
 static tree
 and_comparisons_1 (enum tree_code code1, tree op1a, tree op1b,
-		   enum tree_code code2, tree op2a, tree op2b);
+		   enum tree_code code2, tree op2a, tree op2b,
+		   gimple_stmt_iterator *gsi);
 static tree
 and_var_with_comparison (tree var, bool invert,
-			 enum tree_code code2, tree op2a, tree op2b);
+			 enum tree_code code2, tree op2a, tree op2b,
+			 gimple_stmt_iterator *gsi);
 static tree
 and_var_with_comparison_1 (gimple *stmt,
-			   enum tree_code code2, tree op2a, tree op2b);
+			   enum tree_code code2, tree op2a, tree op2b,
+			   gimple_stmt_iterator *gsi);
 static tree
 or_comparisons_1 (enum tree_code code1, tree op1a, tree op1b,
-		  enum tree_code code2, tree op2a, tree op2b);
+		  enum tree_code code2, tree op2a, tree op2b,
+		  gimple_stmt_iterator *gsi);
 static tree
 or_var_with_comparison (tree var, bool invert,
-			enum tree_code code2, tree op2a, tree op2b);
+			enum tree_code code2, tree op2a, tree op2b,
+			gimple_stmt_iterator *gsi);
 static tree
 or_var_with_comparison_1 (gimple *stmt,
-			  enum tree_code code2, tree op2a, tree op2b);
+			  enum tree_code code2, tree op2a, tree op2b,
+			  gimple_stmt_iterator *gsi);
 
 /* Helper function for and_comparisons_1:  try to simplify the AND of the
ssa variable VAR with the comparison specified by (OP2A CODE2 OP2B).
@@ -5396,7 +5415,8 @@ or_var_with_comparison_1 (gimple *stmt,
 
 static tree
 and_var_with_comparison (tree var, bool in

Re: [PATCH 1/2] Auto-generate maybe_fold_and/or_comparisons from match.pd

[Richard Biener]

On Mon, 9 Sep 2019, Martin Liška wrote:

> On 9/9/19 3:10 PM, Richard Biener wrote:
> > On Mon, 9 Sep 2019, Martin Liška wrote:
> > 
> >> Hi.
> >>
> >> I'm sending slightly updated version of the patch where we
> >> need to properly select type in maybe_fold_comparisons_from_match_pd
> >> function for the created SSA_NAMEs. We can be called for a VECTOR_TYPE
> >> and so that we can't return a boolean_type_node.
> >>
> >> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> >>
> >> Ready to be installed?
> > 
> > 2019-07-16  Li Jia He  
> > Martin Liska  
> > 
> > * gimple.h (gimple_init): Declare.
> > (gimple_size): Likewise.
> > * gimple.c (gimple_init): Remove static and inline restrictions.
> > (gimple_alloc): Only allocate memory and call gimple_init.
> > (gimple_size): Likewise.
> > 
> > Likewise?
> 
> Fixed.
> 
> > 
> > * tree-ssanames.c (init_ssa_name_imm_use): Use make_ssa_name_fn.
> > (make_ssa_name_fn): New.
> > 
> > You didn't touch make_ssa_name_fn.
> 
> Likewise here.
> 
> > 
> > Since we're needing another iteration:
> > 
> > +  /* Allocate gimple stmt1 on the stack.  */
> > +  gimple *stmt1 = (gimple *) XALLOCAVEC (char, gimple_size 
> > (GIMPLE_ASSIGN, 2));
> > 
> > You can use gassign *stmt1 here so all the gimple_assign_ fns below
> > get cheaper.
> > 
> > +  if (op.resimplify (NULL, follow_all_ssa_edges))
> > +{
> > +  if (gimple_simplified_result_is_gimple_val (&op))
> > +   {
> > + tree res = op.ops[0];
> > + switch (TREE_CODE (res))
> > +   {
> > +   case SSA_NAME:
> > +   {
> > + gimple *def = SSA_NAME_DEF_STMT (res);
> > 
> > you shouldn't expand SSA names here unless that SSA name is
> > exactly lhs1 or lhs2 from above.  So
> 
> Ah, got it.
> 
> > 
> >  if (res == lhs1)
> >return build2 (...);
> >  else if (res == lhs2)
> >return build2 (..);
> >  else
> >return res;
> > 
> > plus you miss the case where 'op' became a simplified comparison
> > in itself.  So,
> 
> Yes, that part is included in part 3. I'm going to send the updated patch
> 3 as well soon.
> 
> > 
> >  if (op.code.is_tree_code ()
> >  && TREE_CODE_CLASS ((enum tree_code)op.code) == tcc_comparison)
> >{
> >   tree op0 = op.ops[0];
> >   tree op1 = op.ops[1];
> >   if (op0 == lhs1 || op0 == lhs2 || op1 == lhs1 || op1 == lhs2)
> > return NULL_TREE;  /* not simple */
> >   return build2 ((enum tree_code)op.code, op.type,
> >  op0, op1);
> >}
> > 
> > note you need not fold_ again.  It's of course ugly that we
> > need to build a GENERIC tree here but that's the current interface
> > and thus OK at the moment.
> 
> I see. But what I need is to insert newly created GIMPLE assignment to
> the provided gimple sequence (gsi), right?

There is no newly created GIMPLE?

Richard.

Re: [PATCH 1/2] Auto-generate maybe_fold_and/or_comparisons from match.pd

[Martin Liška]

On 9/9/19 3:42 PM, Richard Biener wrote:
> There is no newly created GIMPLE?

Hm, I thought from the beginning that maybe_fold_comparisons_from_match_pd
can come up with new temporary expressions that need to be inserted into
GIMPLE stream? But that's probably handled in ifcombine with:


  t = force_gimple_operand_gsi_1 (&gsi, t, is_gimple_condexpr, NULL, 
true,
  GSI_SAME_STMT);
?

Martin

Re: [PATCH] Make LTO link pick up compile-time -g

[Richard Biener]

On Mon, 9 Sep 2019, Matthias Klose wrote:

> On 09.09.19 14:02, Richard Biener wrote:
> > So this is really a very poor mans solution that also might
> > uncover issues with -g0 at compile-time vs. -g at link-time
> > if there are mixed -g0/g TUs in the LTO link.
> 
> Could this be documented, at least in the man page? e.g. invoke.texi.  As a
> bonus I would very much welcome a section in the user manual about LTO
> building.  E.g. what will work, what currently doesn't work, etc.  Happy to
> review and extend such documentation, but I don't feel comfortable to write
> that on my own.

Like the following?

Richard.

2019-09-09  Richard Biener  

* lto-opts.c (lto_write_options): Stream -g when debug is enabled.
* lto-wrapper.c (merge_and_complain): Pick up -g.
(append_compiler_options): Likewise.
(run_gcc): Re-instantiate handling -g0 at link-time.
* doc/invoke.texi (flto): Document debug info generation.

Index: gcc/lto-opts.c
===
--- gcc/lto-opts.c  (revision 275454)
+++ gcc/lto-opts.c  (working copy)
@@ -94,6 +94,10 @@ lto_write_options (void)
  : "-fno-pie");
 }
 
+  /* If debug info is enabled append -g.  */
+  if (debug_info_level > DINFO_LEVEL_NONE)
+append_to_collect_gcc_options (&temporary_obstack, &first_p, "-g");
+
   /* Append options from target hook and store them to offload_lto section.  */
   if (lto_stream_offload_p)
 {
Index: gcc/lto-wrapper.c
===
--- gcc/lto-wrapper.c   (revision 275454)
+++ gcc/lto-wrapper.c   (working copy)
@@ -265,6 +265,7 @@ merge_and_complain (struct cl_decoded_op
case OPT_fshow_column:
case OPT_fcommon:
case OPT_fgnu_tm:
+   case OPT_g:
  /* Do what the old LTO code did - collect exactly one option
 setting per OPT code, we pick the first we encounter.
 ???  This doesn't make too much sense, but when it doesn't
@@ -617,6 +618,7 @@ append_compiler_options (obstack *argv_o
case OPT_fopenacc:
case OPT_fopenacc_dim_:
case OPT_foffload_abi_:
+   case OPT_g:
case OPT_O:
case OPT_Ofast:
case OPT_Og:
@@ -1399,6 +1401,10 @@ run_gcc (unsigned argc, char *argv[])
  linker_output_rel = !strcmp (option->arg, "rel");
  break;
 
+   case OPT_g:
+ /* Recognize -g0.  */
+ skip_debug = option->arg && !strcmp (option->arg, "0");
+ break;
 
default:
  break;
Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi (revision 275454)
+++ gcc/doc/invoke.texi (working copy)
@@ -10335,6 +10335,14 @@ conflicting translation units.  Specific
 precedence; and for example @option{-ffp-contract=off} takes precedence
 over @option{-ffp-contract=fast}.  You can override them at link time.
 
+To enable debug info generation you need to supply @option{-g} at
+compile-time.  If any of the input files at link time were built
+with debug info generation enabled the link will enable debug info
+generation as well.  Any elaborate debug info settings
+like the dwarf level @option{-gdwarf-5} need to be explicitely repeated
+at the linker command line and mixing different settings in different
+translation units is discouraged.
+
 If LTO encounters objects with C linkage declared with incompatible
 types in separate translation units to be linked together (undefined
 behavior according to ISO C99 6.2.7), a non-fatal diagnostic may be

[PATCH] Fortran - character type names in errors and warning - for review

[Mark Eggleston]

Currently character type names are given as CHARACTER(1) or CHARACTER(4) 
for unicode.  I find this misleading as I would expect the length to be 
used instead of the kind.


I changed gfc_typename in misc.c to use the character length structure 
in the gfc_typespec structure. This works fine for character variables 
but not for character literals.  I then attempted to set the character 
length in the gfc_typespec structure, creating it if necessary, this 
apparently solved the problem, however, it had some unforeseen side affects:


The expected errors in:

 * gfortran.dg/char_length_7.f90
 * gfortran.dg/char_result_13.f90
 * gfortran.dg/entry_dummy_ref_3.f90
 * gfortran.dg/whole_file_23.f90

are different.

More seriously the following failed to execute correctly:

 * gfortran.dg/array_constructor_type_16.f03
 * gfortran.dg/structure_constructor_14.f90

To work around these problems I added a new length field to gfc_typespec 
to used to produce the name of a character type if the character length 
structure is not present.


The remaining problem was that of assumed length which can only occur 
for formal arguments, a new routine to handle the type names of dummy 
variables was added.  If the length structure is not present in the 
gfc_typespec for a formal argument of type CHARACTER then it has assumed 
length.


If the kind is the default character kind then the kind is omitted from 
the type name otherwise it is inserted after the length separated by a 
comma.


Reported name examples:

character(5) is reported as CHARACTER(5)
"" is reported as CHARACTER(0)
character(*) is reported as CHARACTER(*)
character(len=20, kind=4) is reported as CHARACTER(20,4)
4_"" is reported as CHARACTER(*,4)

The addition of the length field is a bit of kludge any pointers 
regarding a better solution will be appreciated.


The patch including test cases is attached.

ChangeLogs:

gcc/fortran

    Mark Eggleston 

    * arith.c (gfc_arith_concat): Set length field in typespec.
    * expr.c (gfc_get_character_expr): Set length field in typespec.
    * gfortran.h: Add length field to gfc_typespec for use to allow the
    length to available for character literals.
    * interface.c (gfc_check_dummy_characteristics): Use gfc_dummy_typename
    instead of gfc_typename when constructing error message to allow for
    CHARACTER(*) and CHARACTER(*,4).
    (compare_parameter): Use gfc_dummy_typename for formal argument when
    constructing error message to allow for CHARACTER(*) and
    CHARACTER(*,4).
    * intrinsic.c (gfc_actual_arglist): Reword error message so that
    CHARACTER(*) or CHARACTER(*,4) can be reported as the target type.  Use
    gfc_dummy_typename for the formal argument.
    * misc.c (gfc_typename): Add new local variable length and initialise
    with the value from the length field in typespec passed in.  If there
    is a character structure use the value from there for length.  If the
    kind is the default character kind construct the type name using length
    otherwise use the length followed by kind separated by a comma.
    (gfc_dummy_typename): New routine for use with formal arguments, if the
    typespec does not have a character length structure then the length is
    assumed and * is used for the length, if kind is not the default
    character kind follow * with a comma and then the kind.

gcc/testsuite

    Mark Eggleston 

    * gfortran.dg/bad_operands.f90: New test.
    * gfortran.dg/character mismatch.f90: New test.
    * gfortran.dg/compare_interfaces.f90: New test.
    * gfortran.dg/widechar_intrinsics_1.f90: Checked for specific character
    type names instead of "Type of argument".
    * gfortran.dg/widechar_intrinsics_2.f90: Checked for specific character
    type names instead of "Type of argument".
    * gfortran.dg/widechar_intrinsics_3.f90: Checked for specific character
    type names instead of "Type of argument".

--
https://www.codethink.co.uk/privacy.html

>From d8d42618b4dc2f653887b7723b17d1f6bf4e8f63 Mon Sep 17 00:00:00 2001
From: Mark Eggleston 
Date: Fri, 30 Aug 2019 11:08:26 +0100
Subject: [PATCH] Character typenames in errors and warnings

Character type names now incorporate length, kind is only shown if
the default character is not being used.

Examples:

  character(7) is reported as CHARACTER(7)
  character(len=20,kind=4) is reported as CHARACTER(20,4)

dummy character variables with assumed length:

  character(*) is reported as CHARACTER(*)
  character(*,kind=4) is reported as CHARACTER(*,4)
---
 gcc/fortran/arith.c|  1 +
 gcc/fortran/expr.c |  1 +
 gcc/fortran/gfortran.h |  2 +
 gcc/fortran/interface.c| 10 +--
 gcc/fortran/intrinsic.c| 11 ++--
 gcc/fortran/misc.c | 41 +++-
 gcc/testsuite/gfortran.dg/bad_operands.f90 | 10 +++
 gcc/testsuite/gfor

Re: [PATCH 1/2] Auto-generate maybe_fold_and/or_comparisons from match.pd

[Richard Biener]

On Mon, 9 Sep 2019, Martin Liška wrote:

> On 9/9/19 3:42 PM, Richard Biener wrote:
> > There is no newly created GIMPLE?
> 
> Hm, I thought from the beginning that maybe_fold_comparisons_from_match_pd
> can come up with new temporary expressions that need to be inserted into
> GIMPLE stream? But that's probably handled in ifcombine with:
> 
> t = force_gimple_operand_gsi_1 (&gsi, t, is_gimple_condexpr, NULL, 
> true,
> GSI_SAME_STMT);
> ?

No, that case is done when forcing short-circuiting when there was no
simplification.  When there was a simplification we do

  if (result_inv)
t = fold_build1 (TRUTH_NOT_EXPR, TREE_TYPE (t), t);
  t = canonicalize_cond_expr_cond (t);
  if (!t)
return false;

so when it is not a condition suitable for direct replacement into

  gimple_cond_set_condition_from_tree (inner_cond, t);

we fail.

Richard.

Re: [PATCH] Rename Deprecated to IgnoreWarn in *.opt files.

[Segher Boessenkool]

Hi Martin,

On Mon, Sep 09, 2019 at 03:04:20PM +0200, Martin Liška wrote:
> I'm suggesting to rename Deprecated to IgnoreWarn

That is an even worse name IMO.

Just call it Removed or Deleted or something like that?  Something that
says what it _is_, not something that is an amalgamate of how we should
handle it.


Segher

Re: [PATCH] Make LTO link pick up compile-time -g

[Matthias Klose]

On 09.09.19 15:51, Richard Biener wrote:

On Mon, 9 Sep 2019, Matthias Klose wrote:


On 09.09.19 14:02, Richard Biener wrote:

So this is really a very poor mans solution that also might
uncover issues with -g0 at compile-time vs. -g at link-time
if there are mixed -g0/g TUs in the LTO link.


Could this be documented, at least in the man page? e.g. invoke.texi.  As a
bonus I would very much welcome a section in the user manual about LTO
building.  E.g. what will work, what currently doesn't work, etc.  Happy to
review and extend such documentation, but I don't feel comfortable to write
that on my own.


Like the following?



Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi (revision 275454)
+++ gcc/doc/invoke.texi (working copy)
@@ -10335,6 +10335,14 @@ conflicting translation units.  Specific
  precedence; and for example @option{-ffp-contract=off} takes precedence
  over @option{-ffp-contract=fast}.  You can override them at link time.
  
+To enable debug info generation you need to supply @option{-g} at

+compile-time.  If any of the input files at link time were built
+with debug info generation enabled the link will enable debug info
+generation as well.  Any elaborate debug info settings
+like the dwarf level @option{-gdwarf-5} need to be explicitely repeated
+at the linker command line and mixing different settings in different
+translation units is discouraged.
+
  If LTO encounters objects with C linkage declared with incompatible
  types in separate translation units to be linked together (undefined
  behavior according to ISO C99 6.2.7), a non-fatal diagnostic may be


Thanks!

Re: [PATCH] Rename Deprecated to IgnoreWarn in *.opt files.

[Jakub Jelinek]

On Mon, Sep 09, 2019 at 08:56:17AM -0500, Segher Boessenkool wrote:
> Hi Martin,
> 
> On Mon, Sep 09, 2019 at 03:04:20PM +0200, Martin Liška wrote:
> > I'm suggesting to rename Deprecated to IgnoreWarn
> 
> That is an even worse name IMO.
> 
> Just call it Removed or Deleted or something like that?  Something that
> says what it _is_, not something that is an amalgamate of how we should
> handle it.

Well, the current Deprecated is essentially Ignore Warn(switch %qs is no longer 
supported)
so the name was meant to say that it is like Ignore with a warning,
the option is ignored after warning about it.
Though, the documentation needs to be clear, it isn't the option that was
removed, just the feature behind the option.

Jakub

Re: [PATCH] Rename Deprecated to IgnoreWarn in *.opt files.

[Segher Boessenkool]

On Mon, Sep 09, 2019 at 04:04:01PM +0200, Jakub Jelinek wrote:
> On Mon, Sep 09, 2019 at 08:56:17AM -0500, Segher Boessenkool wrote:
> > Hi Martin,
> > 
> > On Mon, Sep 09, 2019 at 03:04:20PM +0200, Martin Liška wrote:
> > > I'm suggesting to rename Deprecated to IgnoreWarn
> > 
> > That is an even worse name IMO.
> > 
> > Just call it Removed or Deleted or something like that?  Something that
> > says what it _is_, not something that is an amalgamate of how we should
> > handle it.
> 
> Well, the current Deprecated is essentially Ignore Warn(switch %qs is no 
> longer supported)
> so the name was meant to say that it is like Ignore with a warning,
> the option is ignored after warning about it.
> Though, the documentation needs to be clear, it isn't the option that was
> removed, just the feature behind the option.

"IgnoreWarn" reads as "ignore the warning".

If we want it named as two things, can we just make it two things?
"Ignore WarnDeleted" or something.  Which also says what it is warning
about.


Segher

Re: [PATCH] Rename Deprecated to IgnoreWarn in *.opt files.

[Jakub Jelinek]

On Mon, Sep 09, 2019 at 09:08:43AM -0500, Segher Boessenkool wrote:
> On Mon, Sep 09, 2019 at 04:04:01PM +0200, Jakub Jelinek wrote:
> > On Mon, Sep 09, 2019 at 08:56:17AM -0500, Segher Boessenkool wrote:
> > > Hi Martin,
> > > 
> > > On Mon, Sep 09, 2019 at 03:04:20PM +0200, Martin Liška wrote:
> > > > I'm suggesting to rename Deprecated to IgnoreWarn
> > > 
> > > That is an even worse name IMO.
> > > 
> > > Just call it Removed or Deleted or something like that?  Something that
> > > says what it _is_, not something that is an amalgamate of how we should
> > > handle it.
> > 
> > Well, the current Deprecated is essentially Ignore Warn(switch %qs is no 
> > longer supported)
> > so the name was meant to say that it is like Ignore with a warning,
> > the option is ignored after warning about it.
> > Though, the documentation needs to be clear, it isn't the option that was
> > removed, just the feature behind the option.
> 
> "IgnoreWarn" reads as "ignore the warning".
> 
> If we want it named as two things, can we just make it two things?
> "Ignore WarnDeleted" or something.  Which also says what it is warning
> about.

Or WarnRemoved.  Both work for me, but ultimately it would be best if Joseph
decides.

Jakub

Re: [PATCH] Use type alignment in get_builtin_sync_mem

[Ulrich Weigand]

Richard Biener wrote:
> On Fri, Sep 6, 2019 at 3:00 PM Ulrich Weigand  wrote:
> > But as far as I can see, for *atomic* operations at least, we do make
> > that assumption.  The x86 back-end for example just assumes that any
> > "int" or "long" object that is the target of an atomic operation is
> > naturally aligned, or else the generated code would just crash.   So
> > if you used your example with a packed struct and passed that pointer
> > to an atomic, the back-end would still assume the alignment and the
> > code would crash.  But I'd still consider this a perfectly reasonable
> > and expected behavior in this case ...
> 
> Would it crash?  I think it would be not atomic if it crossed a cache-line
> boundary.

Sorry, I misremembered the x86 operations, it does indeed work for
unaligned 4- or 8-byte accesses.  However, for 16-byte accesses,
CMPXCHG16B does require aligned memory, the manual says:

  Note that CMPXCHG16B requires that the destination (memory)
  operand be 16-byte aligned.
[...]
64-Bit Mode Exceptions
[...]
#GP(0) If the memory address is in a non-canonical form.
   If memory operand for CMPXCHG16B is not aligned on a
   16-byte boundary.
[...]

So this is basically the same situation as on s390, except that on x86
the default TImode alignment is already 16 bytes.

> > Of course if some part of the middle end get the alignment wrong, we
> > have a problem.  But I'm not sure how this could happen here.  I agree
> > that it might be the case that a user-specified *under*-alignment might
> > get lost somewhere (e.g. you have a packed int and somewhere in the
> > optimizers this gets accidentally cast to a normal int with the default
> > alignment).  But in *this* case, what would have to happen is that the
> > middle-end accidentally casts something to a pointer with *higher*
> > than the default alignment for the type, even though no such pointer
> > cast is present in the source.  Can this really happen?
> 
> If the cast to the lower-aligned type is lost and there is an earlier cast
> to the aligned type.

My point is that this "cast to the aligned type" must have come from the
user in this case (since the aligned type is *more* aligned that any
standard version of the typ), and if the user casts the value to the aligned
type, it is undefined behavior anyway if the value was in fact not aligned.

> > This would actually
> > be wrong on s390.  The problem is that all atomic operations on any
> > one single object need to be consistent: they either all use the
> > 16-byte atomic instruction, or else they all protect the access with
> > a lock.  If you have parts of the code use the lock and other parts
> > use the instruction, they're not actually protected against each other.
> 
> But then the user has to be consistent in accessing the object
> atomically.  If he accesses it once as (aligned_int128_t *)
> and once as (int128_t *) it's his fault, no?

I'm not sure why this should be a requirement.  E.g. if we have a
set of subroutines that operates (correctly) on any int128_t *,
aligned or not, and have one user of those routines that actually
locally has an aligned_int128_t, then that user could no longer
safely pass that a pointer to its aligned variable to that
subsystem if it also does atomic operations locally ...

> If we'd document that the user invokes undefined behavior
> when performing __builtin_atomic () on objects that are not
> sufficiently aligned according to target specific needs then
> we are of course fine and should simply assume the memory
> is aligned accordingly (similar to your patch but probably with
> some target hook specifying the atomic alignment requirement
> when it differs from mode alignment).  But I don't read the
> documentation of our atomic builtins that way.
> 
> Does _Atomic __int128_t work properly on s390?

Yes, it currently does work properly in all cases (just not in
all cases as efficiently as it could be).

The rule to perform atomic operations on __int128_t on s390 is:
 - If the object is *actually* 16-byte aligned at runtime, then
   every atomic access must be performed using one of the atomic
   instructions (CDSG, LPQ, STPQ).
 - If the object is actually *not* 16-byte aligned, then every
   atomic access must be performed under protection of an
   out-of-line lock.

This rule is correctly implemented by:
 - The __builtin_*_16 family of libatomic library routines;
   these all perform a run-time alignment check and use either
   the instruction or the lock, as appropriate; and
 - Compiler-generated inline code;
   this will always use the instruction, but the compiler will
   generate it only if it can prove at compile-time that the
   object *must* be aligned at run-time.

[ However, this rule is *not* implemented by the _n family of
libatomic library routines.  That is not a problem at the moment
since those will *never* get called on any object of size 16;
but they would be if we implemented your proposal; that's why
I pointed out

Re: r272976 - in /trunk/gcc/ada: ChangeLog ali.adb ...

[Christophe Lyon]

On Thu, 5 Sep 2019 at 11:52, Arnaud Charlet  wrote:
>
> > > Can someone please remind me in which repository I can find the GCC
> > > prerequisites doc sources?
> >
> > Answering my own question: found it under gcc/doc/install.texi
> >
> > Working on it...
>
> Just installed the following change on trunk, thanks again for your feedback!
>
> 2019-09-05  Arnaud Charlet  
>
> * doc/install.texi: Update and clarify requirements to build GNAT.
>
Hi Arnaud,

It seems there's a problem with this patch:
/snapshots/gcc.git~master/gcc/doc/install.texi:2730: @ref reference to
nonexistent node `GNAT-prerequisite'
Makefile:3300: recipe for target
'/builds/armv8l-unknown-linux-gnueabihf/armv8l-unknown-linux-gnueabihf/gcc.git~master-stage2/gcc/HTML/gcc-10.0.0/gccinstall/index.html'
failed

Christophe

> Index: doc/install.texi
> ===
> --- doc/install.texi(revision 275399)
> +++ doc/install.texi(working copy)
> @@ -270,13 +270,35 @@
>  @option{--disable-multilib}.  Otherwise, you may encounter an error such as
>  @samp{fatal error: gnu/stubs-32.h: No such file}
>
> -@item GNAT
> +@item @anchor{GNAT-prerequisite}GNAT
>
> -In order to build the Ada compiler (GNAT) you must already have GNAT
> -installed because portions of the Ada frontend are written in Ada (with
> -GNAT extensions.)  Refer to the Ada installation instructions for more
> -specific information.
> +In order to build GNAT, the Ada compiler, you need a working GNAT
> +compiler (GCC version 4.7 or later).
>
> +This includes GNAT tools such as @command{gnatmake} and
> +@command{gnatlink}, since the Ada front end is written in Ada and
> +uses some GNAT-specific extensions.
> +
> +In order to build a cross compiler, it is strongly recommended to install
> +the new compiler as native first, and then use it to build the cross
> +compiler. Other native compiler versions may work but this is not guaranteed 
> and
> +will typically fail with hard to understand compilation errors during the
> +build.
> +
> +Similarly, it is strongly recommended to use an older version of GNAT to 
> build
> +GNAT. More recent versions of GNAT than the version built are not guaranteed
> +to work and will often fail during the build with compilation errors.
> +
> +Note that @command{configure} does not test whether the GNAT installation 
> works
> +and has a sufficiently recent version; if too old a GNAT version is
> +installed and @option{--enable-languages=ada} is used, the build will fail.
> +
> +@env{ADA_INCLUDE_PATH} and @env{ADA_OBJECT_PATH} environment variables
> +must not be set when building the Ada compiler, the Ada tools, or the
> +Ada runtime libraries. You can check that your build environment is clean
> +by verifying that @samp{gnatls -v} lists only one explicit path in each
> +section.
> +
>  @item A ``working'' POSIX compatible shell, or GNU bash
>
>  Necessary when running @command{configure} because some
> @@ -2705,27 +2727,8 @@
>
>  @section Building the Ada compiler
>
> -In order to build GNAT, the Ada compiler, you need a working GNAT
> -compiler (GCC version 4.0 or later).
> -This includes GNAT tools such as @command{gnatmake} and
> -@command{gnatlink}, since the Ada front end is written in Ada and
> -uses some GNAT-specific extensions.
> +See @ref{GNAT-prerequisite}.
>
> -In order to build a cross compiler, it is suggested to install
> -the new compiler as native first, and then use it to build the cross
> -compiler.
> -
> -@command{configure} does not test whether the GNAT installation works
> -and has a sufficiently recent version; if too old a GNAT version is
> -installed, the build will fail unless @option{--enable-languages} is
> -used to disable building the Ada front end.
> -
> -@env{ADA_INCLUDE_PATH} and @env{ADA_OBJECT_PATH} environment variables
> -must not be set when building the Ada compiler, the Ada tools, or the
> -Ada runtime libraries. You can check that your build environment is clean
> -by verifying that @samp{gnatls -v} lists only one explicit path in each
> -section.
> -
>  @section Building with profile feedback
>
>  It is possible to use profile feedback to optimize the compiler itself.  This

Re: [PATCH] Prevent LTO section collision for a symbol name starting with '*'.

[Jan Hubicka]

> PING^1
> 
> On 8/26/19 12:04 PM, Martin Liška wrote:
> > Ok. I have a semi-working patch that has issues for inline clones.
> > When we call cgraph_node::get_untransformed_body for an inline clone,
> > then one needs to use clone_of->order to find proper LTO stream.

This seems OK to me - when using inline clone we really look for a body
of its master, so that seems OK.
> > 
> > What's more problematic is that such clone can be expanded:
> > 
> > f/12 (f) @0x7769f708
> >   Type: function definition analyzed
> >   Visibility: external public
> >   References: mumble.lto_priv.0/8 (write)
> >   Referring: 
> >   Read from file: /tmp/cciAkXHp.ltrans1.o
> >   Function f/12 is inline copy in main/0
> >   Availability: local
> >   Function flags: count:1073741824 (estimated locally) local nonfreeing_fn 
> > executed_once
> >   Called by: main/0 (inlined) (1073741824 (estimated locally),1.00 per 
> > call) 
> >   Calls: 
> > 
> > and lost. So we end up with an orphan and we ICE with:

We do some work on removing unnecesary master clone when function is
fully inlined and I guess in that case you lose the order info.
One option would be to copy order into all inline clones (it does not
have very good meaning there) or do that when reshaping the tree.
This is done in cgraph_node::remove at the place clone_of is
manipulated.
This is probably bit cleaner.
> > 
> > /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/lto/20081112_0.c: In 
> > function ‘main’:
> > /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/lto/20081112_0.c:10:3: 
> > fatal error: /tmp/cciAkXHp.ltrans1.o: section f is missing
> > 
> > So usage of symtab_node::order seems awkward to me :/
> > 
> > Martin
> > 
> 

Re: [PATCH][gcc] libgccjit: handle long literals in playback::context::new_string_literal

[Andrea Corallo]

Andrea Corallo writes:

> Hi all,
> yesterday I've found an interesting bug in libgccjit.
> Seems we have an hard limitation of 200 characters for literal strings.
> Attempting to create longer strings lead to ICE during pass_expand
> while performing a sanity check in get_constant_size.
>
> Tracking down the issue seems the code we have was inspired from
> c-family/c-common.c:c_common_nodes_and_builtins were array_domain_type
> is actually defined with a size of 200.
> The comment that follows that point sounded premonitory :) :)
>
> /* Make a type for arrays of characters.
>With luck nothing will ever really depend on the length of this
>array type.  */
>
> At least in the current implementation the type is set by
> fix_string_type were the actual string length is taken in account.
>
> I attach a patch updating the logic accordingly and a new testcase
>  for that.
>
> make check-jit is passing clean.
>
> Best Regards
>   Andrea
>
> gcc/jit/ChangeLog
> 2019-??-??  Andrea Corallo  
>
>   * jit-playback.h
>   (gcc::jit::recording::context m_recording_ctxt): Remove
>   m_char_array_type_node field.
>   * jit-playback.c
>   (playback::context::context) Remove m_char_array_type_node from member
>   initializer list.
>   (playback::context::new_string_literal) Fix logic to handle string
>   length > 200.
>
> gcc/testsuite/ChangeLog
> 2019-??-??  Andrea Corallo  
>
>   * jit.dg/all-non-failing-tests.h: Add test-long-string-literal.c.
>   * jit.dg/test-long-string-literal.c: New testcase.
> diff --git a/gcc/jit/jit-playback.c b/gcc/jit/jit-playback.c
> index 9eeb2a7..a26b8d3 100644
> --- a/gcc/jit/jit-playback.c
> +++ b/gcc/jit/jit-playback.c
> @@ -88,7 +88,6 @@ playback::context::context (recording::context *ctxt)
>: log_user (ctxt->get_logger ()),
>  m_recording_ctxt (ctxt),
>  m_tempdir (NULL),
> -m_char_array_type_node (NULL),
>  m_const_char_ptr (NULL)
>  {
>JIT_LOG_SCOPE (get_logger ());
> @@ -670,9 +669,12 @@ playback::rvalue *
>  playback::context::
>  new_string_literal (const char *value)
>  {
> -  tree t_str = build_string (strlen (value), value);
> -  gcc_assert (m_char_array_type_node);
> -  TREE_TYPE (t_str) = m_char_array_type_node;
> +  /* Compare with c-family/c-common.c: fix_string_type.  */
> +  size_t len = strlen (value);
> +  tree i_type = build_index_type (size_int (len));
> +  tree a_type = build_array_type (char_type_node, i_type);
> +  tree t_str = build_string (len, value);
> +  TREE_TYPE (t_str) = a_type;
>
>/* Convert to (const char*), loosely based on
>   c/c-typeck.c: array_to_pointer_conversion,
> @@ -2703,10 +2705,6 @@ playback::context::
>  replay ()
>  {
>JIT_LOG_SCOPE (get_logger ());
> -  /* Adapted from c-common.c:c_common_nodes_and_builtins.  */
> -  tree array_domain_type = build_index_type (size_int (200));
> -  m_char_array_type_node
> -= build_array_type (char_type_node, array_domain_type);
>
>m_const_char_ptr
>  = build_pointer_type (build_qualified_type (char_type_node,
> diff --git a/gcc/jit/jit-playback.h b/gcc/jit/jit-playback.h
> index d4b148e..801f610 100644
> --- a/gcc/jit/jit-playback.h
> +++ b/gcc/jit/jit-playback.h
> @@ -322,7 +322,6 @@ private:
>
>auto_vec m_functions;
>auto_vec m_globals;
> -  tree m_char_array_type_node;
>tree m_const_char_ptr;
>
>/* Source location handling.  */
> diff --git a/gcc/testsuite/jit.dg/all-non-failing-tests.h 
> b/gcc/testsuite/jit.dg/all-non-failing-tests.h
> index 0272e6f8..1b3d561 100644
> --- a/gcc/testsuite/jit.dg/all-non-failing-tests.h
> +++ b/gcc/testsuite/jit.dg/all-non-failing-tests.h
> @@ -220,6 +220,13 @@
>  #undef create_code
>  #undef verify_code
>
> +/* test-long-string-literal.c */
> +#define create_code create_code_long_string_literal
> +#define verify_code verify_code_long_string_literal
> +#include "test-long-string-literal.c"
> +#undef create_code
> +#undef verify_code
> +
>  /* test-sum-of-squares.c */
>  #define create_code create_code_sum_of_squares
>  #define verify_code verify_code_sum_of_squares
> diff --git a/gcc/testsuite/jit.dg/test-long-string-literal.c 
> b/gcc/testsuite/jit.dg/test-long-string-literal.c
> new file mode 100644
> index 000..882567c
> --- /dev/null
> +++ b/gcc/testsuite/jit.dg/test-long-string-literal.c
> @@ -0,0 +1,48 @@
> +#include 
> +#include 
> +#include 
> +
> +#include "libgccjit.h"
> +
> +#include "harness.h"
> +
> +const char very_long_string[] =
> +  
> "abcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabc"
> +  
> "abcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabc"
> +  
> "abcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabc"
> +  "abcabcabcabcabcabcabcabcabcabca";
> +
> +void
> +create_code (gcc_jit_context *ctxt, void *user_data)
> +{
> +  /* Build the test_fn.  */
> +  gcc_jit_function *f =
> +gcc_jit_context_new_function (
> +  ctxt, NULL,
> +  GCC_JIT_FUNCTION_EXPORTE

Re: r272976 - in /trunk/gcc/ada: ChangeLog ali.adb ...

[Arnaud Charlet]

> > Just installed the following change on trunk, thanks again for your 
> > feedback!
> >
> > 2019-09-05  Arnaud Charlet  
> >
> > * doc/install.texi: Update and clarify requirements to build GNAT.
> >
> Hi Arnaud,
> 
> It seems there's a problem with this patch:
> /snapshots/gcc.git~master/gcc/doc/install.texi:2730: @ref reference to
> nonexistent node `GNAT-prerequisite'
> Makefile:3300: recipe for target
> '/builds/armv8l-unknown-linux-gnueabihf/armv8l-unknown-linux-gnueabihf/gcc.git~master-stage2/gcc/HTML/gcc-10.0.0/gccinstall/index.html'
> failed

Hmm strange, the ref should be there:

> > -@item GNAT
> > +@item @anchor{GNAT-prerequisite}GNAT

which "make" target is failing for you?

I guess the HTML generation is not handling the above anchor properly, although
it's not the first such use of @anchor{}.

Generating install.info certainly works fine and generates the proper xref.

Arno

Re: r272976 - in /trunk/gcc/ada: ChangeLog ali.adb ...

[Christophe Lyon]

On Mon, 9 Sep 2019 at 17:18, Arnaud Charlet  wrote:
>
> > > Just installed the following change on trunk, thanks again for your 
> > > feedback!
> > >
> > > 2019-09-05  Arnaud Charlet  
> > >
> > > * doc/install.texi: Update and clarify requirements to build GNAT.
> > >
> > Hi Arnaud,
> >
> > It seems there's a problem with this patch:
> > /snapshots/gcc.git~master/gcc/doc/install.texi:2730: @ref reference to
> > nonexistent node `GNAT-prerequisite'
> > Makefile:3300: recipe for target
> > '/builds/armv8l-unknown-linux-gnueabihf/armv8l-unknown-linux-gnueabihf/gcc.git~master-stage2/gcc/HTML/gcc-10.0.0/gccinstall/index.html'
> > failed
>
> Hmm strange, the ref should be there:
>
Indeed, that's what I thought too

> > > -@item GNAT
> > > +@item @anchor{GNAT-prerequisite}GNAT
>
> which "make" target is failing for you?

My log says:
make: *** [do-install-html] Error 2

> I guess the HTML generation is not handling the above anchor properly, 
> although
> it's not the first such use of @anchor{}.
>
> Generating install.info certainly works fine and generates the proper xref.
>
Maybe a problem with makeinfo version?

> Arno

Re: Remove bt-load.c

[Jeff Law]

On 9/9/19 5:21 AM, Richard Sandiford wrote:
> bt-load.c has AFAIK been dead code since the removal of the SH5 port
> in 2016.  I have a patch series that would need to update the liveness
> tracking in a nontrivial way, so it seemed better to remove the pass
> rather than install an untested and probably bogus change.
> 
> Tested on aarch64-linux-gnu, x86_64-linux-gnu and by cross-building
> one target for each CPU directory.  OK to install?
> 
> Richard
> 
> 
> 2019-09-09  Richard Sandiford  
> 
> gcc/
>   * Makefile.in (OBJS): Remove bt-load.o.
>   * doc/invoke.texi (fbranch-target-load-optimize): Delete.
>   (fbranch-target-load-optimize2, fbtr-bb-exclusive): Likewise.
>   * common.opt (fbranch-target-load-optimize): Mark as Ignore and
>   document that the option no longer does anything.
>   (fbranch-target-load-optimize2, fbtr-bb-exclusive): Likewise.
>   * target.def (branch_target_register_class): Delete.
>   (branch_target_register_callee_saved): Likewise.
>   * doc/tm.texi.in (TARGET_BRANCH_TARGET_REGISTER_CLASS): Likewise.
>   (TARGET_BRANCH_TARGET_REGISTER_CALLEE_SAVED): Likewise.
>   * doc/tm.texi: Regenerate.
>   * tree-pass.h (make_pass_branch_target_load_optimize1): Delete.
>   (make_pass_branch_target_load_optimize2): Likewise.
>   * passes.def (pass_branch_target_load_optimize1): Likewise.
>   (pass_branch_target_load_optimize2): Likewise.
>   * targhooks.h (default_branch_target_register_class): Likewise.
>   * targhooks.c (default_branch_target_register_class): Likewise.
>   * opt-suggestions.c (test_completion_valid_options): Remove
>   -fbtr-bb-exclusive from the list of test options.
>   * bt-load.c: Remove.
OK
jeff

[ARM/FDPIC v6 00/24] FDPIC ABI for ARM

[Christophe Lyon]

Hello,

Since all patches of v5 have now been approved, I'm posting v6 to
share the actual patches I'm about to commit (some had minor changes
compared to v5).

Thanks to the reviewers,

Christophe

Changes between v5 and v6:
- rebased on top of recent gcc-10 master (September 9th, 2019)
- fixed libitm support
- addressed feedback received about v5
- there are 3 more patches (skip tests that use -static, libitm fixes,
  split of libstdc++ configury)

Changes between v4 and v5:
- rebased on top of recent gcc-10 master (April 26th, 2019)
- fixed handling of stack-protector combined patterns in FDPIC mode

Changes between v3 and v4:

- improved documentation (patch 1)
- emit an error message (sorry) if the target architecture does not
  support arm nor thumb-2 modes (patch 4)
- handle Richard's comments on patch 4 (comments, unspec)
- added .align directive (patch 5)
- fixed use of kernel helpers (__kernel_cmpxchg, __kernel_dmb) (patch 6)
- code factorization in patch 7
- typos/internal function name in patch 8
- improved patch 12
- dropped patch 16
- patch 20 introduces arm_arch*_thumb_ok effective targets to help
  skip some tests
- I tested patch 2 on xtensa-buildroot-uclinux-uclibc, it adds many
  new tests, but a few regressions
  (https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00713.html)
- I compiled and executed several LTP tests to exercise pthreads and signals
- I wrote and executed a simple testcase to change the interaction
  with __kernel_cmpxchg (ie. call the kernel helper rather than use an
  implementation in libgcc as requested by Richard)

Changes between v2 and v3:
- added doc entry for -mfdpic new option
- took Kyrill's comments into account (use "Armv7" instead of "7",
  code factorization, use preprocessor instead of hard-coding "r9",
  remove leftover code for thumb1 support, fixed comments)
- rebase over recent trunk
- patches with changes: 1, 2 (commit message), 3 (rebase), 4, 6, 7, 9,
  14 (rebase), 19 (rebase)

Changes between v1 and v2:
- fix GNU coding style
- exit with an error for pre-Armv7
- use ACLE __ARM_ARCH and remove dead code for pre-Armv4
- remove unsupported attempts of pre-Armv7/thumb1 support
- add instructions in comments next to opcodes
- merge patches 11 and 13
- fixed protected visibility handling in patch 8
- merged legitimize_tls_address_fdpic and
  legitimize_tls_address_not_fdpic as requested



This patch series implements the GCC contribution of the FDPIC ABI for
ARM targets.

This ABI enables to run Linux on ARM MMU-less cores and supports
shared libraries to reduce the memory footprint.

Without MMU, text and data segments relative distances are different
from one process to another, hence the need for a dedicated FDPIC
register holding the start address of the data segment. One of the
side effects is that function pointers require two words to be
represented: the address of the code, and the data segment start
address. These two words are designated as "Function Descriptor",
hence the "FD PIC" name.

On ARM, the FDPIC register is r9 [1], and the target name is
arm-uclinuxfdpiceabi. Note that arm-uclinux exists, but uses another
ABI and the BFLAT file format; it does not support code sharing.
The -mfdpic option is enabled by default, and -mno-fdpic should be
used to build the Linux kernel.

This work was developed some time ago by STMicroelectronics, and was
presented during Linaro Connect SFO15 (September 2015). You can watch
the discussion and read the slides [2].
This presentation was related to the toolchain published on github [3],
which is based on binutils-2.22, gcc-4.7, uclibc-0.9.33.2, gdb-7.5.1
and qemu-2.3.0, and for which pre-built binaries are available [3].

The ABI itself is described in details in [1].

Our Linux kernel patches have been updated and committed by Nicolas
Pitre (Linaro) in July 2017. They are required so that the loader is
able to handle this new file type. Indeed, the ELF files are tagged
with ELFOSABI_ARM_FDPIC. This new tag has been allocated by ARM, as
well as the new relocations involved.

The binutils, QEMU and uclibc-ng patch series have been merged a few
months ago. [4][5][6]

This series provides support for architectures that support ARM and/or
Thumb-2 and has been tested on arm-linux-gnueabi without regression,
as well as arm-uclinuxfdpiceabi, using QEMU. arm-uclinuxfdpiceabi has
a few more failures than arm-linux-gnueabi, but is quite functional.

I have also booted an STM32 board (stm32f469) which uses a cortex-m4
with linux-4.20.17 and ran successfully several tools.

Thanks,

Christophe.


[1] https://github.com/mickael-guene/fdpic_doc/blob/master/abi.txt
[2] 
http://connect.linaro.org/resource/sfo15/sfo15-406-arm-fdpic-toolset-kernel-libraries-for-cortex-m-cortex-r-mmuless-cores/
[3] https://github.com/mickael-guene/fdpic_manifest
[4] 
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=f1ac0afe481e83c9a33f247b81fa7de789edc4d9
[5] 
https://git.qemu.org/?p=qemu.git;a=commit;h=e8fa72957419c1198460

[ARM/FDPIC v6 01/24] [ARM] FDPIC: Add -mfdpic option support

[Christophe Lyon]

From: Christophe Lyon 

2019-XX-XX  Christophe Lyon  
Mickaël Guêné  

gcc/
* config/arm/arm.opt: Add -mfdpic option.
* doc/invoke.texi: Add documentation for -mfdpic.

Change-Id: I05b98d6ae87c2b3fc04dd7fba415c730accdf33e

diff --git a/gcc/config/arm/arm.opt b/gcc/config/arm/arm.opt
index 5ecc5e5..545ec49 100644
--- a/gcc/config/arm/arm.opt
+++ b/gcc/config/arm/arm.opt
@@ -306,3 +306,7 @@ Cost to assume for a branch insn.
 mgeneral-regs-only
 Target Report RejectNegative Mask(GENERAL_REGS_ONLY) Save
 Generate code which uses the core registers only (r0-r14).
+
+mfdpic
+Target Report Mask(FDPIC)
+Enable Function Descriptor PIC mode.
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index bfcd76e..cc283ff 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -711,7 +711,8 @@ Objective-C and Objective-C++ Dialects}.
 -mrestrict-it @gol
 -mverbose-cost-dump @gol
 -mpure-code @gol
--mcmse}
+-mcmse @gol
+-mfdpic}
 
 @emph{AVR Options}
 @gccoptlist{-mmcu=@var{mcu}  -mabsdata  -maccumulate-args @gol
@@ -18043,6 +18044,27 @@ MOVT instruction.
 Generate secure code as per the "ARMv8-M Security Extensions: Requirements on
 Development Tools Engineering Specification", which can be found on
 
@url{http://infocenter.arm.com/help/topic/com.arm.doc.ecm0359818/ECM0359818_armv8m_security_extensions_reqs_on_dev_tools_1_0.pdf}.
+
+@item -mfdpic
+@itemx -mno-fdpic
+@opindex mfdpic
+@opindex mno-fdpic
+Select the FDPIC ABI, which uses 64-bit function descriptors to
+represent pointers to functions.  When the compiler is configured for
+@code{arm-*-uclinuxfdpiceabi} targets, this option is on by default
+and implies @option{-fPIE} if none of the PIC/PIE-related options is
+provided.  On other targets, it only enables the FDPIC-specific code
+generation features, and the user should explicitly provide the
+PIC/PIE-related options as needed.
+
+Note that static linking is not supported because it would still
+involve the dynamic linker when the program self-relocates.  If such
+behavior is acceptable, use -static and -Wl,-dynamic-linker options.
+
+The opposite @option{-mno-fdpic} option is useful (and required) to
+build the Linux kernel using the same (@code{arm-*-uclinuxfdpiceabi})
+toolchain as the one used to build the userland programs.
+
 @end table
 
 @node AVR Options
-- 
2.6.3

[ARM/FDPIC v6 02/24] [ARM] FDPIC: Handle arm*-*-uclinuxfdpiceabi in configure scripts

[Christophe Lyon]

From: Christophe Lyon 

The new arm-uclinuxfdpiceabi target behaves pretty much like
arm-linux-gnueabi. In order to enable the same set of features, we
have to update several configure scripts that generally match targets
like *-*-linux*: in most places, we add *-uclinux* where there is
already *-linux*, or uclinux* when there is already linux*.

In gcc/config.gcc and libgcc/config.host we use *-*-uclinuxfdpiceabi
because there is already a different behaviour for *-*uclinux* target.

In libtool.m4, we use uclinuxfdpiceabi in cases where ELF shared
libraries support is required, as uclinux does not guarantee that.

2019-XX-XX  Christophe Lyon  

config/
* futex.m4: Handle *-uclinux*.
* tls.m4 (GCC_CHECK_TLS): Likewise.

gcc/
* config.gcc: Handle *-*-uclinuxfdpiceabi.

libatomic/
* configure.tgt: Handle arm*-*-uclinux*.
* configure: Regenerate.

libgcc/
* config.host: Handle *-*-uclinuxfdpiceabi.

libitm/
* configure.tgt: Handle *-*-uclinux*.
* configure: Regenerate.

* libtool.m4: Handle uclinuxfdpiceabi.

Change-Id: Ib3a08905879ef917ee6c04c3988cf4ced7209fef

diff --git a/config/futex.m4 b/config/futex.m4
index 1b43829..c212438 100644
--- a/config/futex.m4
+++ b/config/futex.m4
@@ -9,7 +9,7 @@ AC_DEFUN([GCC_LINUX_FUTEX],[dnl
 GCC_ENABLE(linux-futex,default, ,[use the Linux futex system call],
   permit yes|no|default)
 case "$target" in
-  *-linux*)
+  *-linux* | *-uclinux*)
 case "$enable_linux_futex" in
   default)
# If headers don't have gettid/futex syscalls definition, then
diff --git a/config/tls.m4 b/config/tls.m4
index 1a5fc59..7532305 100644
--- a/config/tls.m4
+++ b/config/tls.m4
@@ -76,7 +76,7 @@ AC_DEFUN([GCC_CHECK_TLS], [
  dnl Shared library options may depend on the host; this check
  dnl is only known to be needed for GNU/Linux.
  case $host in
-   *-*-linux*)
+   *-*-linux* | -*-uclinuxfdpic*)
  LDFLAGS="-shared -Wl,--no-undefined $LDFLAGS"
  ;;
  esac
diff --git a/gcc/config.gcc b/gcc/config.gcc
index 94a3608..69904fd 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -771,7 +771,7 @@ case ${target} in
 *-*-fuchsia*)
   native_system_header_dir=/include
   ;;
-*-*-linux* | frv-*-*linux* | *-*-kfreebsd*-gnu | *-*-gnu* | 
*-*-kopensolaris*-gnu)
+*-*-linux* | frv-*-*linux* | *-*-kfreebsd*-gnu | *-*-gnu* | 
*-*-kopensolaris*-gnu | *-*-uclinuxfdpiceabi)
   extra_options="$extra_options gnu-user.opt"
   gas=yes
   gnu_ld=yes
@@ -800,7 +800,7 @@ case ${target} in
 *-*-*android*)
   tm_defines="$tm_defines DEFAULT_LIBC=LIBC_BIONIC"
   ;;
-*-*-*uclibc*)
+*-*-*uclibc* | *-*-uclinuxfdpiceabi)
   tm_defines="$tm_defines DEFAULT_LIBC=LIBC_UCLIBC"
   ;;
 *-*-*musl*)
@@ -1198,7 +1198,7 @@ arm*-*-netbsdelf*)
armv7*) target_cpu_cname="generic-armv7-a";;
esac
;;
-arm*-*-linux-*)# ARM GNU/Linux with ELF
+arm*-*-linux-* | arm*-*-uclinuxfdpiceabi)
tm_file="dbxelf.h elfos.h gnu-user.h linux.h linux-android.h 
glibc-stdint.h arm/elf.h arm/linux-gas.h arm/linux-elf.h"
extra_options="${extra_options} linux-android.opt"
case $target in
diff --git a/libatomic/configure b/libatomic/configure
index e6f5fb7..7bd01a1 100755
--- a/libatomic/configure
+++ b/libatomic/configure
@@ -6055,7 +6055,7 @@ irix5* | irix6* | nonstopux*)
   ;;
 
 # This must be Linux ELF.
-linux* | k*bsd*-gnu | kopensolaris*-gnu)
+linux* | k*bsd*-gnu | kopensolaris*-gnu | uclinuxfdpiceabi)
   lt_cv_deplibs_check_method=pass_all
   ;;
 
@@ -9135,7 +9135,7 @@ _LT_EOF
   archive_expsym_cmds='sed "s,^,_," $export_symbols 
>$output_objdir/$soname.expsym~$CC -shared $pic_flag $libobjs $deplibs 
$compiler_flags ${wl}-h,$soname 
${wl}--retain-symbols-file,$output_objdir/$soname.expsym 
${wl}--image-base,`expr ${RANDOM-$$} % 4096 / 2 \* 262144 + 1342177280` -o $lib'
   ;;
 
-gnu* | linux* | tpf* | k*bsd*-gnu | kopensolaris*-gnu)
+gnu* | linux* | tpf* | k*bsd*-gnu | kopensolaris*-gnu | uclinuxfdpiceabi)
   tmp_diet=no
   if test "$host_os" = linux-dietlibc; then
case $cc_basename in
@@ -10666,7 +10666,12 @@ linux*oldld* | linux*aout* | linux*coff*)
   ;;
 
 # This must be Linux ELF.
-linux* | k*bsd*-gnu | kopensolaris*-gnu)
+
+# uclinux* changes (here and below) have been submitted to the libtool
+# project, but have not yet been accepted: they are GCC-local changes
+# for the time being.  (See
+# https://lists.gnu.org/archive/html/libtool-patches/2018-05/msg0.html)
+linux* | k*bsd*-gnu | kopensolaris*-gnu | uclinuxfdpiceabi)
   version_type=linux
   need_lib_prefix=no
   need_version=no
diff --git a/libatomic/configure.tgt b/libatomic/configure.tgt
index 4a1294b..61778fb 100644
--- a/libatomic/configure.tgt
+++ b/libatomic/configure.tgt
@@ -124,7 +124,7 @@ case "${target}" in
config_path="${config_path} li

[ARM/FDPIC v6 03/24] [ARM] FDPIC: Force FDPIC related options unless -mno-fdpic is provided

[Christophe Lyon]

From: Christophe Lyon 

In FDPIC mode, we set -fPIE unless the user provides -fno-PIE, -fpie,
-fPIC or -fpic: indeed FDPIC code is PIC, but we want to generate code
for executables rather than shared libraries by default.

We also make sure to use the --fdpic assembler option, and select the
appropriate linker emulation.

At link time, we also default to -pie, unless we are generating a
shared library or a relocatable file (-r). Note that static link is
not supported as it requires specifying the dynamic linker because the
executable still has to relocate itself at startup.

We also force 'now' binding since lazy binding is not supported.

We should also apply the same behavior for -Wl,-Ur as for -r, but I
couldn't find how to describe that in the specs fragment.

2019-XX-XX  Christophe Lyon  
Mickaël Guêné 

gcc/
* config.gcc: Handle arm*-*-uclinuxfdpiceabi.
* config/arm/bpabi.h (TARGET_FDPIC_ASM_SPEC): New.
(SUBTARGET_EXTRA_ASM_SPEC): Use TARGET_FDPIC_ASM_SPEC.
* config/arm/linux-eabi.h (FDPIC_CC1_SPEC): New.
(CC1_SPEC): Use FDPIC_CC1_SPEC.
(MUSL_DYNAMIC_LINKER): Add -fdpic suffix when needed.
* config/arm/uclinuxfdpiceabi.h: New file.

libsanitizer/
* configure.tgt (arm*-*-*fdpiceabi): Sanitizers are
unsupported in this configuration.

Change-Id: I74ac1fbb2e809e864d2b0acce66b173e76bcf92b

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 69904fd..2a6a8f0 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -1208,6 +1208,11 @@ arm*-*-linux-* | arm*-*-uclinuxfdpiceabi)
esac
tmake_file="${tmake_file} arm/t-arm arm/t-arm-elf arm/t-bpabi 
arm/t-linux-eabi"
tm_file="$tm_file arm/bpabi.h arm/linux-eabi.h arm/aout.h arm/arm.h"
+   case $target in
+   arm*-*-uclinuxfdpiceabi)
+   tm_file="$tm_file arm/uclinuxfdpiceabi.h"
+   ;;
+   esac
# Generation of floating-point instructions requires at least ARMv5te.
if [ "$with_float" = "hard" -o "$with_float" = "softfp" ] ; then
target_cpu_cname="arm10e"
diff --git a/gcc/config/arm/bpabi.h b/gcc/config/arm/bpabi.h
index e1bacf4..75d9a99 100644
--- a/gcc/config/arm/bpabi.h
+++ b/gcc/config/arm/bpabi.h
@@ -55,6 +55,8 @@
 #define TARGET_FIX_V4BX_SPEC " %{mcpu=arm8|mcpu=arm810|mcpu=strongarm*"\
   "|march=armv4|mcpu=fa526|mcpu=fa626:--fix-v4bx}"
 
+#define TARGET_FDPIC_ASM_SPEC ""
+
 #define BE8_LINK_SPEC  \
   "%{!r:%{!mbe32:%:be8_linkopt(%{mlittle-endian:little}"   \
   "   %{mbig-endian:big}"  \
@@ -64,7 +66,8 @@
 /* Tell the assembler to build BPABI binaries.  */
 #undef  SUBTARGET_EXTRA_ASM_SPEC
 #define SUBTARGET_EXTRA_ASM_SPEC \
-  "%{mabi=apcs-gnu|mabi=atpcs:-meabi=gnu;:-meabi=5}" TARGET_FIX_V4BX_SPEC
+  "%{mabi=apcs-gnu|mabi=atpcs:-meabi=gnu;:-meabi=5}" TARGET_FIX_V4BX_SPEC \
+  TARGET_FDPIC_ASM_SPEC
 
 #ifndef SUBTARGET_EXTRA_LINK_SPEC
 #define SUBTARGET_EXTRA_LINK_SPEC ""
diff --git a/gcc/config/arm/linux-eabi.h b/gcc/config/arm/linux-eabi.h
index 66ec0ea..b348971 100644
--- a/gcc/config/arm/linux-eabi.h
+++ b/gcc/config/arm/linux-eabi.h
@@ -89,7 +89,7 @@
 #define MUSL_DYNAMIC_LINKER_E "%{mbig-endian:eb}"
 #endif
 #define MUSL_DYNAMIC_LINKER \
-  "/lib/ld-musl-arm" MUSL_DYNAMIC_LINKER_E "%{mfloat-abi=hard:hf}.so.1"
+  "/lib/ld-musl-arm" MUSL_DYNAMIC_LINKER_E 
"%{mfloat-abi=hard:hf}%{mfdpic:-fdpic}.so.1"
 
 /* At this point, bpabi.h will have clobbered LINK_SPEC.  We want to
use the GNU/Linux version, not the generic BPABI version.  */
@@ -101,9 +101,12 @@
 #undef  ASAN_CC1_SPEC
 #define ASAN_CC1_SPEC "%{%:sanitize(address):-funwind-tables}"
 
+#define FDPIC_CC1_SPEC ""
+
 #undef  CC1_SPEC
 #define CC1_SPEC   \
-  LINUX_OR_ANDROID_CC (GNU_USER_TARGET_CC1_SPEC " " ASAN_CC1_SPEC, \
+  LINUX_OR_ANDROID_CC (GNU_USER_TARGET_CC1_SPEC " " ASAN_CC1_SPEC " "  \
+  FDPIC_CC1_SPEC,  \
   GNU_USER_TARGET_CC1_SPEC " " ASAN_CC1_SPEC " "   \
   ANDROID_CC1_SPEC)
 
diff --git a/gcc/config/arm/uclinuxfdpiceabi.h 
b/gcc/config/arm/uclinuxfdpiceabi.h
new file mode 100644
index 000..328adcb
--- /dev/null
+++ b/gcc/config/arm/uclinuxfdpiceabi.h
@@ -0,0 +1,54 @@
+/* Configuration file for ARM GNU/Linux FDPIC EABI targets.
+   Copyright (C) 2018,2019 Free Software Foundation, Inc.
+   Contributed by STMicroelectronics.
+
+   This file is part of GCC.
+
+   GCC is free software; you can redistribute it and/or modify it
+   under the terms of the GNU General Public License as published
+   by the Free Software Foundation; either version 3, or (at your
+   option) any later version.
+
+   GCC is distributed in the hope that it will be useful, but WITHOUT
+   ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+   or FITNESS FOR A PARTICULAR PURPOSE

[ARM/FDPIC v6 04/24] [ARM] FDPIC: Add support for FDPIC for arm architecture

[Christophe Lyon]

From: Christophe Lyon 

The FDPIC register is hard-coded to r9, as defined in the ABI.

We have to disable tailcall optimizations if we don't know if the
target function is in the same module. If not, we have to set r9 to
the value associated with the target module.

When generating a symbol address, we have to take into account whether
it is a pointer to data or to a function, because different
relocations are needed.

2019-XX-XX  Christophe Lyon  
Mickaël Guêné 

gcc/
* config/arm/arm-c.c (__FDPIC__): Define new pre-processor macro
in FDPIC mode.
* config/arm/arm-protos.h (arm_load_function_descriptor): Declare
new function.
* config/arm/arm.c (arm_option_override): Define pic register to
FDPIC_REGNUM.
(arm_function_ok_for_sibcall): Disable sibcall optimization if we
have no decl or go through PLT.
(calculate_pic_address_constant): New function.
(legitimize_pic_address): Call calculate_pic_address_constant.
(arm_load_pic_register): Handle TARGET_FDPIC.
(arm_is_segment_info_known): New function.
(arm_pic_static_addr): Add support for FDPIC.
(arm_load_function_descriptor): New function.
(arm_emit_call_insn): Add support for FDPIC.
(arm_assemble_integer): Add support for FDPIC.
* config/arm/arm.h (PIC_OFFSET_TABLE_REG_CALL_CLOBBERED):
Define. (FDPIC_REGNUM): New define.
* config/arm/arm.md (call): Add support for FDPIC.
(call_value): Likewise.
(restore_pic_register_after_call): New pattern.
(untyped_call): Disable if FDPIC.
(untyped_return): Likewise.
* config/arm/unspecs.md (UNSPEC_PIC_RESTORE): New.

gcc/testsuite/
* gcc.target/arm/fp16-aapcs-2.c: Adjust scan-assembler-times.
* gcc.target/arm/fp16-aapcs-4.c: Likewise.

Change-Id: I1e96d260074ab7b75d36cdff5d34ad898f35c66f

diff --git a/gcc/config/arm/arm-c.c b/gcc/config/arm/arm-c.c
index 6e256ee..34695fa 100644
--- a/gcc/config/arm/arm-c.c
+++ b/gcc/config/arm/arm-c.c
@@ -203,6 +203,8 @@ arm_cpu_builtins (struct cpp_reader* pfile)
   builtin_define ("__ARM_EABI__");
 }
 
+  def_or_undef_macro (pfile, "__FDPIC__", TARGET_FDPIC);
+
   def_or_undef_macro (pfile, "__ARM_ARCH_EXT_IDIV__", TARGET_IDIV);
   def_or_undef_macro (pfile, "__ARM_FEATURE_IDIV", TARGET_IDIV);
 
diff --git a/gcc/config/arm/arm-protos.h b/gcc/config/arm/arm-protos.h
index 8386d89..f995974 100644
--- a/gcc/config/arm/arm-protos.h
+++ b/gcc/config/arm/arm-protos.h
@@ -139,6 +139,7 @@ extern int arm_max_const_double_inline_cost (void);
 extern int arm_const_double_inline_cost (rtx);
 extern bool arm_const_double_by_parts (rtx);
 extern bool arm_const_double_by_immediates (rtx);
+extern rtx arm_load_function_descriptor (rtx funcdesc);
 extern void arm_emit_call_insn (rtx, rtx, bool);
 bool detect_cmse_nonsecure_call (tree);
 extern const char *output_call (rtx *);
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 8576431..c34aab8 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -3456,6 +3456,14 @@ arm_option_override (void)
   if (flag_pic && TARGET_VXWORKS_RTP)
 arm_pic_register = 9;
 
+  /* If in FDPIC mode then force arm_pic_register to be r9.  */
+  if (TARGET_FDPIC)
+{
+  arm_pic_register = FDPIC_REGNUM;
+  if (TARGET_THUMB1)
+   sorry ("FDPIC mode is not supported in Thumb-1 mode");
+}
+
   if (arm_pic_register_string != NULL)
 {
   int pic_register = decode_reg_name (arm_pic_register_string);
@@ -7251,6 +7259,15 @@ arm_function_ok_for_sibcall (tree decl, tree exp)
   if (cfun->machine->sibcall_blocked)
 return false;
 
+  if (TARGET_FDPIC)
+{
+  /* In FDPIC, never tailcall something for which we have no decl:
+the target function could be in a different module, requiring
+a different FDPIC register value.  */
+  if (decl == NULL)
+   return false;
+}
+
   /* Never tailcall something if we are generating code for Thumb-1.  */
   if (TARGET_THUMB1)
 return false;
@@ -7461,6 +7478,24 @@ require_pic_register (rtx pic_reg, bool compute_now)
 }
 }
 
+/* Generate insns to calculate the address of ORIG in pic mode.  */
+static rtx_insn *
+calculate_pic_address_constant (rtx reg, rtx pic_reg, rtx orig)
+{
+  rtx pat;
+  rtx mem;
+
+  pat = gen_calculate_pic_address (reg, pic_reg, orig);
+
+  /* Make the MEM as close to a constant as possible.  */
+  mem = SET_SRC (pat);
+  gcc_assert (MEM_P (mem) && !MEM_VOLATILE_P (mem));
+  MEM_READONLY_P (mem) = 1;
+  MEM_NOTRAP_P (mem) = 1;
+
+  return emit_insn (pat);
+}
+
 /* Legitimize PIC load to ORIG into REG.  If REG is NULL, a new pseudo is
created to hold the result of the load.  If not NULL, PIC_REG indicates
which register to use as PIC register, otherwise it is decided by register
@@ -7505,24 +7540,13 @@ legitimize_pic_address (rtx orig, machine_mode mode, 
rtx reg, rtx pic_reg,
insn = ar

[ARM/FDPIC v6 05/24] [ARM] FDPIC: Fix __do_global_dtors_aux and frame_dummy generation

[Christophe Lyon]

From: Christophe Lyon 

In FDPIC, we need to make sure __do_global_dtors_aux and frame_dummy
are referenced by their address, not by pointers to the function
descriptors.

2019-XX-XX  Christophe Lyon  
Mickaël Guêné 

libgcc/
* libgcc/crtstuff.c: Add support for FDPIC.

Change-Id: I0bc4b1232fbf3c69068fb23a1b9cafc895d141b1

diff --git a/libgcc/crtstuff.c b/libgcc/crtstuff.c
index c8a8e2c..c93e1cb 100644
--- a/libgcc/crtstuff.c
+++ b/libgcc/crtstuff.c
@@ -429,9 +429,17 @@ __do_global_dtors_aux (void)
 #ifdef FINI_SECTION_ASM_OP
 CRT_CALL_STATIC_FUNCTION (FINI_SECTION_ASM_OP, __do_global_dtors_aux)
 #elif defined (FINI_ARRAY_SECTION_ASM_OP)
+#if defined(__FDPIC__)
+__asm__("\t.equ\t__do_global_dtors_aux_alias, __do_global_dtors_aux\n");
+extern char __do_global_dtors_aux_alias;
+static void *__do_global_dtors_aux_fini_array_entry[]
+__attribute__ ((__used__, section(".fini_array"), aligned(sizeof(void *
+ = { &__do_global_dtors_aux_alias };
+#else /* defined(__FDPIC__) */
 static func_ptr __do_global_dtors_aux_fini_array_entry[]
   __attribute__ ((__used__, section(".fini_array"),
  aligned(__alignof__(func_ptr = { __do_global_dtors_aux };
+#endif /* defined(__FDPIC__) */
 #else /* !FINI_SECTION_ASM_OP && !FINI_ARRAY_SECTION_ASM_OP */
 static void __attribute__((used))
 __do_global_dtors_aux_1 (void)
@@ -473,9 +481,17 @@ frame_dummy (void)
 #ifdef __LIBGCC_INIT_SECTION_ASM_OP__
 CRT_CALL_STATIC_FUNCTION (__LIBGCC_INIT_SECTION_ASM_OP__, frame_dummy)
 #else /* defined(__LIBGCC_INIT_SECTION_ASM_OP__) */
+#if defined(__FDPIC__)
+__asm__("\t.equ\t__frame_dummy_alias, frame_dummy\n");
+extern char __frame_dummy_alias;
+static void *__frame_dummy_init_array_entry[]
+__attribute__ ((__used__, section(".init_array"), aligned(sizeof(void *
+ = { &__frame_dummy_alias };
+#else /* defined(__FDPIC__) */
 static func_ptr __frame_dummy_init_array_entry[]
   __attribute__ ((__used__, section(".init_array"),
  aligned(__alignof__(func_ptr = { frame_dummy };
+#endif /* defined(__FDPIC__) */
 #endif /* !defined(__LIBGCC_INIT_SECTION_ASM_OP__) */
 #endif /* USE_EH_FRAME_REGISTRY || USE_TM_CLONE_REGISTRY */
 
-- 
2.6.3

[ARM/FDPIC v6 06/24] [ARM] FDPIC: Add support for c++ exceptions

[Christophe Lyon]

From: Christophe Lyon 

The main difference with existing support is that function addresses
are function descriptor addresses instead. This means that all code
dealing with function pointers now has to cope with function
descriptors instead.

For the same reason, Linux kernel helpers can no longer be called by
dereferencing their address, so we implement wrappers that directly
call the kernel helpers.

When restoring a function address, we also have to restore the FDPIC
register value (r9).

2019-XX-XX  Christophe Lyon  
Mickaël Guêné 

gcc/
* ginclude/unwind-arm-common.h (unwinder_cache): Add reserved5
field.

libgcc/
* config/arm/linux-atomic.c (__kernel_cmpxchg): Add FDPIC support.
(__kernel_dmb): Likewise.
(__fdpic_cmpxchg): New function.
(__fdpic_dmb): New function.
* config/arm/unwind-arm.h (FDPIC_REGNUM): New define.
(gnu_Unwind_Find_got): New function.
(_Unwind_decode_typeinfo_ptr): Add FDPIC support.
* unwind-arm-common.inc (UCB_PR_GOT): New.
(funcdesc_t): New struct.
(get_eit_entry): Add FDPIC support.
(unwind_phase2): Likewise.
(unwind_phase2_forced): Likewise.
(__gnu_Unwind_RaiseException): Likewise.
(__gnu_Unwind_Resume): Likewise.
(__gnu_Unwind_Backtrace): Likewise.
* unwind-pe.h (read_encoded_value_with_base): Likewise.

libstdc++/
* libsupc++/eh_personality.cc (get_ttype_entry): Add FDPIC
support.

Change-Id: I64b81cfaf390a05f2fd121f44ba1912cb4b47cae

diff --git a/gcc/ginclude/unwind-arm-common.h b/gcc/ginclude/unwind-arm-common.h
index 6df783e..d4eb03e 100644
--- a/gcc/ginclude/unwind-arm-common.h
+++ b/gcc/ginclude/unwind-arm-common.h
@@ -91,7 +91,7 @@ extern "C" {
  _uw reserved2;  /* Personality routine address */
  _uw reserved3;  /* Saved callsite address */
  _uw reserved4;  /* Forced unwind stop arg */
- _uw reserved5;
+ _uw reserved5;  /* Personality routine GOT value in FDPIC mode.  */
}
   unwinder_cache;
   /* Propagation barrier cache (valid after phase 1): */
diff --git a/libgcc/config/arm/linux-atomic.c b/libgcc/config/arm/linux-atomic.c
index 06a6d46..565f829 100644
--- a/libgcc/config/arm/linux-atomic.c
+++ b/libgcc/config/arm/linux-atomic.c
@@ -25,11 +25,62 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  
If not, see
 
 /* Kernel helper for compare-and-exchange.  */
 typedef int (__kernel_cmpxchg_t) (int oldval, int newval, int *ptr);
-#define __kernel_cmpxchg (*(__kernel_cmpxchg_t *) 0x0fc0)
+
+#define STR(X) #X
+#define XSTR(X) STR(X)
+
+#define KERNEL_CMPXCHG 0x0fc0
+
+#if __FDPIC__
+/* Non-FDPIC ABIs call __kernel_cmpxchg directly by dereferencing its
+   address, but under FDPIC we would generate a broken call
+   sequence. That's why we have to implement __kernel_cmpxchg and
+   __kernel_dmb here: this way, the FDPIC call sequence works.  */
+#define __kernel_cmpxchg __fdpic_cmpxchg
+#else
+#define __kernel_cmpxchg (*(__kernel_cmpxchg_t *) KERNEL_CMPXCHG)
+#endif
 
 /* Kernel helper for memory barrier.  */
 typedef void (__kernel_dmb_t) (void);
-#define __kernel_dmb (*(__kernel_dmb_t *) 0x0fa0)
+
+#define KERNEL_DMB 0x0fa0
+
+#if __FDPIC__
+#define __kernel_dmb __fdpic_dmb
+#else
+#define __kernel_dmb (*(__kernel_dmb_t *) KERNEL_DMB)
+#endif
+
+#if __FDPIC__
+static int __fdpic_cmpxchg (int oldval, int newval, int *ptr)
+{
+  int result;
+
+  asm volatile (
+   "ldrip, 1f\n\t"
+   "bx ip\n\t"
+   "1:\n\t"
+   ".word " XSTR(KERNEL_CMPXCHG) "\n\t"
+   : "=r" (result)
+   : "r" (oldval) , "r" (newval), "r" (ptr)
+   : "r3", "memory");
+  /* The result is actually returned by the kernel helper, we need
+ this to avoid a warning.  */
+  return result;
+}
+
+static void __fdpic_dmb (void)
+{
+  asm volatile (
+   "ldrip, 1f\n\t"
+   "bx ip\n\t"
+   "1:\n\t"
+   ".word " XSTR(KERNEL_DMB) "\n\t"
+   );
+}
+
+#endif
 
 /* Note: we implement byte, short and int versions of atomic operations using
the above kernel helpers; see linux-atomic-64bit.c for "long long" (64-bit)
diff --git a/libgcc/config/arm/unwind-arm.h b/libgcc/config/arm/unwind-arm.h
index 43c5379..2bf320a 100644
--- a/libgcc/config/arm/unwind-arm.h
+++ b/libgcc/config/arm/unwind-arm.h
@@ -33,9 +33,33 @@
 /* Use IP as a scratch register within the personality routine.  */
 #define UNWIND_POINTER_REG 12
 
+#define FDPIC_REGNUM 9
+
+#define STR(x) #x
+#define XSTR(x) STR(x)
+
 #ifdef __cplusplus
 extern "C" {
 #endif
+_Unwind_Ptr __attribute__((weak)) __gnu_Unwind_Find_got (_Unwind_Ptr);
+
+static inline _Unwind_Ptr gnu_Unwind_Find_got (_Unwind_Ptr ptr)
+{
+_Unwind_Ptr res;
+
+if (__gnu_Unwind_Find_got)
+   res =  __gnu_Unwind_Find_got (ptr);
+else
+  {
+

[ARM/FDPIC v6 07/24] [ARM] FDPIC: Avoid saving/restoring r9 on stack since it is read-only

[Christophe Lyon]

From: Christophe Lyon 

2019-XX-XX  Christophe Lyon  
Mickaël Guêné 

gcc/
* config/arm/arm.h (PIC_REGISTER_MAY_NEED_SAVING): New helper.
* config/arm/arm.c (arm_compute_save_reg0_reg12_mask): Handle
FDPIC.

Change-Id: I0f3b2023ab2a2a0433dfe081dac6bbb194b7a76c

diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index c34aab8..6ff3001 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -19571,9 +19571,7 @@ arm_compute_save_reg0_reg12_mask (void)
  save_reg_mask |= (1 << reg);
 
   /* Also save the pic base register if necessary.  */
-  if (flag_pic
- && !TARGET_SINGLE_PIC_BASE
- && arm_pic_register != INVALID_REGNUM
+  if (PIC_REGISTER_MAY_NEED_SAVING
  && crtl->uses_pic_offset_table)
save_reg_mask |= 1 << PIC_OFFSET_TABLE_REGNUM;
 }
@@ -19605,9 +19603,7 @@ arm_compute_save_reg0_reg12_mask (void)
 
   /* If we aren't loading the PIC register,
 don't stack it even though it may be live.  */
-  if (flag_pic
- && !TARGET_SINGLE_PIC_BASE
- && arm_pic_register != INVALID_REGNUM
+  if (PIC_REGISTER_MAY_NEED_SAVING
  && (df_regs_ever_live_p (PIC_OFFSET_TABLE_REGNUM)
  || crtl->uses_pic_offset_table))
save_reg_mask |= 1 << PIC_OFFSET_TABLE_REGNUM;
diff --git a/gcc/config/arm/arm.h b/gcc/config/arm/arm.h
index e404e2c..490d22d 100644
--- a/gcc/config/arm/arm.h
+++ b/gcc/config/arm/arm.h
@@ -1960,6 +1960,13 @@ extern unsigned arm_pic_register;
   || label_mentioned_p (get_pool_constant (X)  \
 || tls_mentioned_p (X))
 
+/* We may want to save the PIC register if it is a dedicated one.  */
+#define PIC_REGISTER_MAY_NEED_SAVING   \
+  (flag_pic\
+   && !TARGET_SINGLE_PIC_BASE  \
+   && !TARGET_FDPIC\
+   && arm_pic_register != INVALID_REGNUM)
+
 /* We need to know when we are making a constant pool; this determines
whether data needs to be in the GOT or can be referenced via a GOT
offset.  */
-- 
2.6.3

[ARM/FDPIC v6 08/24] [ARM] FDPIC: Enforce local/global binding for function descriptors

[Christophe Lyon]

From: Christophe Lyon 

Use local binding rules to decide whether we can use GOTOFFFUNCDESC to
compute the function address.

2019-XX-XX  Christophe Lyon  
Mickaël Guêné 

gcc/
* config/arm/arm.c (arm_fdpic_local_funcdesc_p): New function.
(legitimize_pic_address): Enforce binding rules on function
pointers in FDPIC mode.
(arm_assemble_integer): Likewise.

Change-Id: I3fa0b63bc0f672903f405aa72cc46052de1c0feb

diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 6ff3001..6b0c95f 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -3754,6 +3754,42 @@ arm_options_perform_arch_sanity_checks (void)
 }
 }
 
+/* Test whether a local function descriptor is canonical, i.e.,
+   whether we can use GOTOFFFUNCDESC to compute the address of the
+   function.  */
+static bool
+arm_fdpic_local_funcdesc_p (rtx fnx)
+{
+  tree fn;
+  enum symbol_visibility vis;
+  bool ret;
+
+  if (!TARGET_FDPIC)
+return true;
+
+  if (! SYMBOL_REF_LOCAL_P (fnx))
+return false;
+
+  fn = SYMBOL_REF_DECL (fnx);
+
+  if (! fn)
+return false;
+
+  vis = DECL_VISIBILITY (fn);
+
+  if (vis == VISIBILITY_PROTECTED)
+/* Private function descriptors for protected functions are not
+   canonical.  Temporarily change the visibility to global so that
+   we can ensure uniqueness of funcdesc pointers.  */
+DECL_VISIBILITY (fn) = VISIBILITY_DEFAULT;
+
+  ret = default_binds_local_p_1 (fn, flag_pic);
+
+  DECL_VISIBILITY (fn) = vis;
+
+  return ret;
+}
+
 static void
 arm_add_gc_roots (void)
 {
@@ -7534,7 +7570,9 @@ legitimize_pic_address (rtx orig, machine_mode mode, rtx 
reg, rtx pic_reg,
   || (GET_CODE (orig) == SYMBOL_REF
   && SYMBOL_REF_LOCAL_P (orig)
   && (SYMBOL_REF_DECL (orig)
-  ? !DECL_WEAK (SYMBOL_REF_DECL (orig)) : 1)))
+  ? !DECL_WEAK (SYMBOL_REF_DECL (orig)) : 1)
+  && (!SYMBOL_REF_FUNCTION_P (orig)
+  || arm_fdpic_local_funcdesc_p (orig
  && NEED_GOT_RELOC
  && arm_pic_data_is_text_relative)
insn = arm_pic_static_addr (orig, reg);
@@ -23160,7 +23198,9 @@ arm_assemble_integer (rtx x, unsigned int size, int 
aligned_p)
  || (GET_CODE (x) == SYMBOL_REF
  && (!SYMBOL_REF_LOCAL_P (x)
  || (SYMBOL_REF_DECL (x)
- ? DECL_WEAK (SYMBOL_REF_DECL (x)) : 0
+ ? DECL_WEAK (SYMBOL_REF_DECL (x)) : 0)
+ || (SYMBOL_REF_FUNCTION_P (x)
+ && !arm_fdpic_local_funcdesc_p (x)
{
  if (TARGET_FDPIC && SYMBOL_REF_FUNCTION_P (x))
fputs ("(GOTFUNCDESC)", asm_out_file);
-- 
2.6.3

[ARM/FDPIC v6 09/24] [ARM] FDPIC: Add support for taking address of nested function

[Christophe Lyon]

From: Christophe Lyon 

In FDPIC mode, the trampoline generated to support pointers to nested
functions looks like:

   .wordtrampoline address
   .wordtrampoline GOT address
   ldr  r12, [pc, #8]
   ldr  r9, [pc, #8]
   ldr  pc, [pc, #8]
   .wordstatic chain value
   .wordGOT address
   .wordfunction's address

because in FDPIC function pointers are actually pointers to function
descriptors, we have to actually generate a function descriptor for
the trampoline.

2019-XX-XX  Christophe Lyon  
Mickaël Guêné 

gcc/
* config/arm/arm.c (arm_asm_trampoline_template): Add FDPIC
support.
(arm_trampoline_init): Likewise.
(arm_trampoline_adjust_address): Likewise.
* config/arm/arm.h (TRAMPOLINE_SIZE): Likewise.

Change-Id: Idc4d5f629ae4f8d79bdf9623517481d524a0c144

diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 6b0c95f..d01fae3 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -3939,14 +3939,52 @@ arm_warn_func_return (tree decl)
   ldr  pc, [pc]
   .wordstatic chain value
   .wordfunction's address
-   XXX FIXME: When the trampoline returns, r8 will be clobbered.  */
+   XXX FIXME: When the trampoline returns, r8 will be clobbered.
+
+   In FDPIC mode, the trampoline looks like:
+  .wordtrampoline address
+  .wordtrampoline GOT address
+  ldr  r12, [pc, #8] ; #4 for Arm mode
+  ldr  r9,  [pc, #8] ; #4 for Arm mode
+  ldr  pc,  [pc, #8] ; #4 for Arm mode
+  .wordstatic chain value
+  .wordGOT address
+  .wordfunction's address
+*/
 
 static void
 arm_asm_trampoline_template (FILE *f)
 {
   fprintf (f, "\t.syntax unified\n");
 
-  if (TARGET_ARM)
+  if (TARGET_FDPIC)
+{
+  /* The first two words are a function descriptor pointing to the
+trampoline code just below.  */
+  if (TARGET_ARM)
+   fprintf (f, "\t.arm\n");
+  else if (TARGET_THUMB2)
+   fprintf (f, "\t.thumb\n");
+  else
+   /* Only ARM and Thumb-2 are supported.  */
+   gcc_unreachable ();
+
+  assemble_aligned_integer (UNITS_PER_WORD, const0_rtx);
+  assemble_aligned_integer (UNITS_PER_WORD, const0_rtx);
+  /* Trampoline code which sets the static chain register but also
+PIC register before jumping into real code.  */
+  asm_fprintf (f, "\tldr\t%r, [%r, #%d]\n",
+  STATIC_CHAIN_REGNUM, PC_REGNUM,
+  TARGET_THUMB2 ? 8 : 4);
+  asm_fprintf (f, "\tldr\t%r, [%r, #%d]\n",
+  PIC_OFFSET_TABLE_REGNUM, PC_REGNUM,
+  TARGET_THUMB2 ? 8 : 4);
+  asm_fprintf (f, "\tldr\t%r, [%r, #%d]\n",
+  PC_REGNUM, PC_REGNUM,
+  TARGET_THUMB2 ? 8 : 4);
+  assemble_aligned_integer (UNITS_PER_WORD, const0_rtx);
+}
+  else if (TARGET_ARM)
 {
   fprintf (f, "\t.arm\n");
   asm_fprintf (f, "\tldr\t%r, [%r, #0]\n", STATIC_CHAIN_REGNUM, PC_REGNUM);
@@ -3987,12 +4025,40 @@ arm_trampoline_init (rtx m_tramp, tree fndecl, rtx 
chain_value)
   emit_block_move (m_tramp, assemble_trampoline_template (),
   GEN_INT (TRAMPOLINE_SIZE), BLOCK_OP_NORMAL);
 
-  mem = adjust_address (m_tramp, SImode, TARGET_32BIT ? 8 : 12);
-  emit_move_insn (mem, chain_value);
+  if (TARGET_FDPIC)
+{
+  rtx funcdesc = XEXP (DECL_RTL (fndecl), 0);
+  rtx fnaddr = gen_rtx_MEM (Pmode, funcdesc);
+  rtx gotaddr = gen_rtx_MEM (Pmode, plus_constant (Pmode, funcdesc, 4));
+  /* The function start address is at offset 8, but in Thumb mode
+we want bit 0 set to 1 to indicate Thumb-ness, hence 9
+below.  */
+  rtx trampoline_code_start
+   = plus_constant (Pmode, XEXP (m_tramp, 0), TARGET_THUMB2 ? 9 : 8);
+
+  /* Write initial funcdesc which points to the trampoline.  */
+  mem = adjust_address (m_tramp, SImode, 0);
+  emit_move_insn (mem, trampoline_code_start);
+  mem = adjust_address (m_tramp, SImode, 4);
+  emit_move_insn (mem, gen_rtx_REG (Pmode, PIC_OFFSET_TABLE_REGNUM));
+  /* Setup static chain.  */
+  mem = adjust_address (m_tramp, SImode, 20);
+  emit_move_insn (mem, chain_value);
+  /* GOT + real function entry point.  */
+  mem = adjust_address (m_tramp, SImode, 24);
+  emit_move_insn (mem, gotaddr);
+  mem = adjust_address (m_tramp, SImode, 28);
+  emit_move_insn (mem, fnaddr);
+}
+  else
+{
+  mem = adjust_address (m_tramp, SImode, TARGET_32BIT ? 8 : 12);
+  emit_move_insn (mem, chain_value);
 
-  mem = adjust_address (m_tramp, SImode, TARGET_32BIT ? 12 : 16);
-  fnaddr = XEXP (DECL_RTL (fndecl), 0);
-  emit_move_insn (mem, fnaddr);
+  mem = adjust_address (m_tramp, SImode, TARGET_32BIT ? 12 : 16);
+  fnadd

[ARM/FDPIC v6 10/24] [ARM] FDPIC: Implement TLS support.

[Christophe Lyon]

From: Christophe Lyon 

Support additional relocations: TLS_GD32_FDPIC, TLS_LDM32_FDPIC, and
TLS_IE32_FDPIC.

We do not support the GNU2 TLS dialect.

2019-XX-XX  Christophe Lyon  
Mickaël Guêné 

gcc/
* config/arm/arm.c (tls_reloc): Add TLS_GD32_FDPIC,
TLS_LDM32_FDPIC and TLS_IE32_FDPIC.
(arm_call_tls_get_addr): Add FDPIC support.
(legitimize_tls_address): Likewise.
(arm_emit_tls_decoration): Likewise.

Change-Id: I4ea5034ff654540c4658d0a79fb92f70550cdf4a

diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index d01fae3..5f1d2d4 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -2350,9 +2350,12 @@ char arm_arch_name[] = "__ARM_ARCH_PROFILE__";
 
 enum tls_reloc {
   TLS_GD32,
+  TLS_GD32_FDPIC,
   TLS_LDM32,
+  TLS_LDM32_FDPIC,
   TLS_LDO32,
   TLS_IE32,
+  TLS_IE32_FDPIC,
   TLS_LE32,
   TLS_DESCSEQ  /* GNU scheme */
 };
@@ -8708,22 +8711,33 @@ load_tls_operand (rtx x, rtx reg)
 static rtx_insn *
 arm_call_tls_get_addr (rtx x, rtx reg, rtx *valuep, int reloc)
 {
-  rtx label, labelno, sum;
+  rtx label, labelno = NULL_RTX, sum;
 
   gcc_assert (reloc != TLS_DESCSEQ);
   start_sequence ();
 
-  labelno = GEN_INT (pic_labelno++);
-  label = gen_rtx_UNSPEC (Pmode, gen_rtvec (1, labelno), UNSPEC_PIC_LABEL);
-  label = gen_rtx_CONST (VOIDmode, label);
+  if (TARGET_FDPIC)
+{
+  sum = gen_rtx_UNSPEC (Pmode,
+   gen_rtvec (2, x, GEN_INT (reloc)),
+   UNSPEC_TLS);
+}
+  else
+{
+  labelno = GEN_INT (pic_labelno++);
+  label = gen_rtx_UNSPEC (Pmode, gen_rtvec (1, labelno), UNSPEC_PIC_LABEL);
+  label = gen_rtx_CONST (VOIDmode, label);
 
-  sum = gen_rtx_UNSPEC (Pmode,
-   gen_rtvec (4, x, GEN_INT (reloc), label,
-  GEN_INT (TARGET_ARM ? 8 : 4)),
-   UNSPEC_TLS);
+  sum = gen_rtx_UNSPEC (Pmode,
+   gen_rtvec (4, x, GEN_INT (reloc), label,
+  GEN_INT (TARGET_ARM ? 8 : 4)),
+   UNSPEC_TLS);
+}
   reg = load_tls_operand (sum, reg);
 
-  if (TARGET_ARM)
+  if (TARGET_FDPIC)
+  emit_insn (gen_addsi3 (reg, reg, gen_rtx_REG (Pmode, FDPIC_REGNUM)));
+  else if (TARGET_ARM)
 emit_insn (gen_pic_add_dot_plus_eight (reg, reg, labelno));
   else
 emit_insn (gen_pic_add_dot_plus_four (reg, reg, labelno));
@@ -8761,6 +8775,7 @@ arm_tls_descseq_addr (rtx x, rtx reg)
   return reg;
 }
 
+
 rtx
 legitimize_tls_address (rtx x, rtx reg)
 {
@@ -8773,6 +8788,8 @@ legitimize_tls_address (rtx x, rtx reg)
 case TLS_MODEL_GLOBAL_DYNAMIC:
   if (TARGET_GNU2_TLS)
{
+ gcc_assert (!TARGET_FDPIC);
+
  reg = arm_tls_descseq_addr (x, reg);
 
  tp = arm_load_tp (NULL_RTX);
@@ -8782,7 +8799,10 @@ legitimize_tls_address (rtx x, rtx reg)
   else
{
  /* Original scheme */
- insns = arm_call_tls_get_addr (x, reg, &ret, TLS_GD32);
+ if (TARGET_FDPIC)
+   insns = arm_call_tls_get_addr (x, reg, &ret, TLS_GD32_FDPIC);
+ else
+   insns = arm_call_tls_get_addr (x, reg, &ret, TLS_GD32);
  dest = gen_reg_rtx (Pmode);
  emit_libcall_block (insns, dest, ret, x);
}
@@ -8791,6 +8811,8 @@ legitimize_tls_address (rtx x, rtx reg)
 case TLS_MODEL_LOCAL_DYNAMIC:
   if (TARGET_GNU2_TLS)
{
+ gcc_assert (!TARGET_FDPIC);
+
  reg = arm_tls_descseq_addr (x, reg);
 
  tp = arm_load_tp (NULL_RTX);
@@ -8799,7 +8821,10 @@ legitimize_tls_address (rtx x, rtx reg)
}
   else
{
- insns = arm_call_tls_get_addr (x, reg, &ret, TLS_LDM32);
+ if (TARGET_FDPIC)
+   insns = arm_call_tls_get_addr (x, reg, &ret, TLS_LDM32_FDPIC);
+ else
+   insns = arm_call_tls_get_addr (x, reg, &ret, TLS_LDM32);
 
  /* Attach a unique REG_EQUIV, to allow the RTL optimizers to
 share the LDM result with other LD model accesses.  */
@@ -8818,23 +8843,35 @@ legitimize_tls_address (rtx x, rtx reg)
   return dest;
 
 case TLS_MODEL_INITIAL_EXEC:
-  labelno = GEN_INT (pic_labelno++);
-  label = gen_rtx_UNSPEC (Pmode, gen_rtvec (1, labelno), UNSPEC_PIC_LABEL);
-  label = gen_rtx_CONST (VOIDmode, label);
-  sum = gen_rtx_UNSPEC (Pmode,
-   gen_rtvec (4, x, GEN_INT (TLS_IE32), label,
-  GEN_INT (TARGET_ARM ? 8 : 4)),
-   UNSPEC_TLS);
-  reg = load_tls_operand (sum, reg);
-
-  if (TARGET_ARM)
-   emit_insn (gen_tls_load_dot_plus_eight (reg, reg, labelno));
-  else if (TARGET_THUMB2)
-   emit_insn (gen_tls_load_dot_plus_four (reg, NULL, reg, labelno));
+  if (TARGET_FDPIC)
+   {
+ sum = gen_rtx_UNSPEC (Pmode,
+   gen_rtvec (2, x, GEN_INT (TLS_IE32_FDPIC)),
+   U

[ARM/FDPIC v6 11/24] [ARM] FDPIC: Add support to unwind FDPIC signal frame

[Christophe Lyon]

From: Christophe Lyon 

2019-XX-XX  Christophe Lyon  
Mickaël Guêné 

libgcc/
* unwind-arm-common.inc (ARM_SET_R7_RT_SIGRETURN)
(THUMB2_SET_R7_RT_SIGRETURN, FDPIC_LDR_R12_WITH_FUNCDESC)
(FDPIC_LDR_R9_WITH_GOT, FDPIC_LDR_PC_WITH_RESTORER)
(FDPIC_FUNCDESC_OFFSET, ARM_NEW_RT_SIGFRAME_UCONTEXT)
(ARM_UCONTEXT_SIGCONTEXT, ARM_SIGCONTEXT_R0, 
FDPIC_T2_LDR_R12_WITH_FUNCDESC)
(FDPIC_T2_LDR_R9_WITH_GOT, FDPIC_T2_LDR_PC_WITH_RESTORER): New.
(__gnu_personality_sigframe_fdpic): New.
(get_eit_entry): Add FDPIC signal frame support.

Change-Id: I7f9527cc50665dd1a731b7badf71c319fb38bf57

diff --git a/libgcc/unwind-arm-common.inc b/libgcc/unwind-arm-common.inc
index 0bacc11..c9a82b7 100644
--- a/libgcc/unwind-arm-common.inc
+++ b/libgcc/unwind-arm-common.inc
@@ -30,6 +30,26 @@
 #include 
 #endif
 
+#if __FDPIC__
+/* Load r7 with rt_sigreturn value.  */
+#define ARM_SET_R7_RT_SIGRETURN0xe3a070ad  /* mov   r7, 
#0xad */
+#define THUMB2_SET_R7_RT_SIGRETURN 0x07adf04f  /* mov.w r7, #0xad */
+
+/* FDPIC jump to restorer sequence.  */
+#define FDPIC_LDR_R12_WITH_FUNCDESC0xe59fc004  /* ldr   r12, [pc, #4] 
*/
+#define FDPIC_LDR_R9_WITH_GOT  0xe59c9004  /* ldr   r9, [r12, #4] 
*/
+#define FDPIC_LDR_PC_WITH_RESTORER 0xe59cf000  /* ldr   pc, [r12] */
+#define FDPIC_T2_LDR_R12_WITH_FUNCDESC  0xc008f8df /* ldr.w r12, [pc, #8] 
*/
+#define FDPIC_T2_LDR_R9_WITH_GOT   0x9004f8dc  /* ldr.w r9, [r12, #4] 
*/
+#define FDPIC_T2_LDR_PC_WITH_RESTORER   0xf000f8dc /* ldr.w pc, [r12] */
+#define FDPIC_FUNCDESC_OFFSET  12
+
+/* Signal frame offsets.  */
+#define ARM_NEW_RT_SIGFRAME_UCONTEXT   0x80
+#define ARM_UCONTEXT_SIGCONTEXT0x14
+#define ARM_SIGCONTEXT_R0  0xc
+#endif
+
 /* We add a prototype for abort here to avoid creating a dependency on
target headers.  */
 extern void abort (void);
@@ -199,6 +219,45 @@ search_EIT_table (const __EIT_entry * table, int nrec, _uw 
return_address)
 }
 }
 
+#if __FDPIC__
+/* VFP is not restored, but this is sufficient to allow unwinding.  */
+static _Unwind_Reason_Code
+__gnu_personality_sigframe_fdpic (_Unwind_State state,
+ _Unwind_Control_Block *ucbp,
+ _Unwind_Context *context)
+{
+unsigned int sp;
+unsigned int pc;
+unsigned int funcdesc;
+unsigned int handler;
+unsigned int first_handler_instruction;
+int i;
+
+_Unwind_VRS_Get (context, _UVRSC_CORE, R_SP, _UVRSD_UINT32, &sp);
+_Unwind_VRS_Get (context, _UVRSC_CORE, R_PC, _UVRSD_UINT32, &pc);
+
+funcdesc = *(unsigned int *)((pc & ~1) + FDPIC_FUNCDESC_OFFSET);
+handler = *(unsigned int *)(funcdesc);
+first_handler_instruction = *(unsigned int *)(handler & ~1);
+
+/* Adjust SP to point to the start of registers according to
+   signal type.  */
+if (first_handler_instruction == ARM_SET_R7_RT_SIGRETURN
+   || first_handler_instruction == THUMB2_SET_R7_RT_SIGRETURN)
+   sp += ARM_NEW_RT_SIGFRAME_UCONTEXT
+ + ARM_UCONTEXT_SIGCONTEXT
+ + ARM_SIGCONTEXT_R0;
+else
+   sp += ARM_UCONTEXT_SIGCONTEXT
+ + ARM_SIGCONTEXT_R0;
+/* Restore regs saved on stack by the kernel.  */
+for (i = 0; i < 16; i++)
+   _Unwind_VRS_Set (context, _UVRSC_CORE, i, _UVRSD_UINT32, sp + 4 * i);
+
+return _URC_CONTINUE_UNWIND;
+}
+#endif
+
 /* Find the exception index table eintry for the given address.
Fill in the relevant fields of the UCB.
Returns _URC_FAILURE if an error occurred, _URC_OK on success.  */
@@ -222,6 +281,27 @@ get_eit_entry (_Unwind_Control_Block *ucbp, _uw 
return_address)
&nrec);
   if (!eitp)
{
+#if __FDPIC__
+ /* If we are unwinding a signal handler then perhaps we have
+reached a trampoline.  Try to detect jump to restorer
+sequence.  */
+ _uw *pc = (_uw *)((return_address+2) & ~1);
+ if ((pc[0] == FDPIC_LDR_R12_WITH_FUNCDESC
+  && pc[1] == FDPIC_LDR_R9_WITH_GOT
+  && pc[2] == FDPIC_LDR_PC_WITH_RESTORER)
+ || (pc[0] == FDPIC_T2_LDR_R12_WITH_FUNCDESC
+ && pc[1] == FDPIC_T2_LDR_R9_WITH_GOT
+ && pc[2] == FDPIC_T2_LDR_PC_WITH_RESTORER))
+   {
+ struct funcdesc_t *funcdesc
+   = (struct funcdesc_t *) &__gnu_personality_sigframe_fdpic;
+
+ UCB_PR_ADDR (ucbp) = funcdesc->ptr;
+ UCB_PR_GOT (ucbp) = funcdesc->got;
+
+ return _URC_OK;
+   }
+#endif
  UCB_PR_ADDR (ucbp) = 0;
  return _URC_FAILURE;
}
@@ -236,6 +316,27 @@ get_eit_entry (_Unwind_Control_Block *ucbp, _uw 
return_address)
 
   if (!eitp)
 {
+#if __FDPIC__
+  /* If we are unwinding a signal handler then perhaps we have
+reached a trampoline.  T

[ARM/FDPIC v6 12/24] [ARM] FDPIC: Restore r9 after we call __aeabi_read_tp

[Christophe Lyon]

From: Christophe Lyon 

We call __aeabi_read_tp() to get the thread pointer. Since this is a
function call, we have to restore the FDPIC register afterwards.

2019-XX-XX  Christophe Lyon  
Mickaël Guêné 

gcc/
* config/arm/arm.c (arm_load_tp): Add FDPIC support.
* config/arm/arm.md (FDPIC_REGNUM): New constant.
(load_tp_soft_fdpic): New pattern.
(load_tp_soft): Disable in FDPIC mode.

Change-Id: I0811cc7c5df8f44dd8b8b1f4caf54c7d3609c414

diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 5f1d2d4..c452771 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -8685,7 +8685,18 @@ arm_load_tp (rtx target)
 
   rtx tmp;
 
-  emit_insn (gen_load_tp_soft ());
+  if (TARGET_FDPIC)
+   {
+ rtx fdpic_reg = gen_rtx_REG (Pmode, FDPIC_REGNUM);
+ rtx initial_fdpic_reg = get_hard_reg_initial_val (Pmode, 
FDPIC_REGNUM);
+
+ emit_insn (gen_load_tp_soft_fdpic ());
+
+ /* Restore r9.  */
+ emit_insn (gen_restore_pic_register_after_call(fdpic_reg, 
initial_fdpic_reg));
+   }
+  else
+   emit_insn (gen_load_tp_soft ());
 
   tmp = gen_rtx_REG (SImode, R0_REGNUM);
   emit_move_insn (target, tmp);
diff --git a/gcc/config/arm/arm.md b/gcc/config/arm/arm.md
index 027febb..918271d 100644
--- a/gcc/config/arm/arm.md
+++ b/gcc/config/arm/arm.md
@@ -31,6 +31,7 @@
   [(R0_REGNUM 0)   ; First CORE register
(R1_REGNUM1); Second CORE register
(R4_REGNUM4); Fifth CORE register
+   (FDPIC_REGNUM  9)   ; FDPIC register
(IP_REGNUM   12); Scratch register
(SP_REGNUM   13); Stack pointer
(LR_REGNUM14)   ; Return address register
@@ -11165,12 +11166,25 @@
 )
 
 ;; Doesn't clobber R1-R3.  Must use r0 for the first operand.
+(define_insn "load_tp_soft_fdpic"
+  [(set (reg:SI 0) (unspec:SI [(const_int 0)] UNSPEC_TLS))
+   (clobber (reg:SI FDPIC_REGNUM))
+   (clobber (reg:SI LR_REGNUM))
+   (clobber (reg:SI IP_REGNUM))
+   (clobber (reg:CC CC_REGNUM))]
+  "TARGET_SOFT_TP && TARGET_FDPIC"
+  "bl\\t__aeabi_read_tp\\t@ load_tp_soft"
+  [(set_attr "conds" "clob")
+   (set_attr "type" "branch")]
+)
+
+;; Doesn't clobber R1-R3.  Must use r0 for the first operand.
 (define_insn "load_tp_soft"
   [(set (reg:SI 0) (unspec:SI [(const_int 0)] UNSPEC_TLS))
(clobber (reg:SI LR_REGNUM))
(clobber (reg:SI IP_REGNUM))
(clobber (reg:CC CC_REGNUM))]
-  "TARGET_SOFT_TP"
+  "TARGET_SOFT_TP && !TARGET_FDPIC"
   "bl\\t__aeabi_read_tp\\t@ load_tp_soft"
   [(set_attr "conds" "clob")
(set_attr "type" "branch")]
-- 
2.6.3

[ARM/FDPIC v6 13/24] [ARM] FDPIC: Force LSB bit for PC in Cortex-M architecture

[Christophe Lyon]

From: Christophe Lyon 

Without this, when we are unwinding across a signal frame we can jump
to an even address which leads to an exception.

This is needed in __gnu_persnality_sigframe_fdpic() when restoring the
PC from the signal frame since the PC saved by the kernel has the LSB
bit set to zero.

2019-XX-XX  Christophe Lyon  
Mickaël Guêné 

libgcc/
* config/arm/unwind-arm.c (_Unwind_VRS_Set): Handle thumb-only
architecture.

Change-Id: Ie84de548226bcf1751e19a09e8f091fb3013ccea

diff --git a/libgcc/config/arm/unwind-arm.c b/libgcc/config/arm/unwind-arm.c
index 9ba73e7..8313ee0 100644
--- a/libgcc/config/arm/unwind-arm.c
+++ b/libgcc/config/arm/unwind-arm.c
@@ -199,6 +199,11 @@ _Unwind_VRS_Result _Unwind_VRS_Set (_Unwind_Context 
*context,
return _UVRSR_FAILED;
 
   vrs->core.r[regno] = *(_uw *) valuep;
+#if defined(__thumb__)
+  /* Force LSB bit since we always run thumb code.  */
+  if (regno == R_PC)
+   vrs->core.r[regno] |= 1;
+#endif
   return _UVRSR_OK;
 
 case _UVRSC_VFP:
-- 
2.6.3

[ARM/FDPIC v6 14/24] [ARM][testsuite] FDPIC: Skip unsupported tests

[Christophe Lyon]

From: Christophe Lyon 

Several tests cannot work on ARM-FDPIC for various reasons: skip them,
or skip some directives.

gcc.dg/20020312-2.c: Skip since it forces -fno-pic.

gcc.target/arm/:
* Skip since r9 is clobbered by assembly code:
  20051215-1.c
  mmx-1.c
  pr61948.c
  pr77933-1.c
  pr77933-2.c

* Skip since the test forces armv5te which is not supported by FDPIC:
  pr40887.c
  pr19599.c

* Skip since FDPIC disables sibcall to external functions:
  sibcall-1.c
  tail-long-call
  vfp-longcall-apcs

* Skip size check since it's different for FDPIC:
  ivopts-2.c
  ivopts-3.c
  ivopts-4.c
  ivopts-5.c
  pr43597.c
  pr43920-2.c

* Disable assembler scanning invalid for FDPIC:
  pr45701-1.c
  pr45701-2.c
  stack-red-zone.c

* gnu2 TLS dialect is not supported by FDPIC:
  tlscall.c

* Test relies on symbols not generated in FDPIC:
  data-rel-2.c
  data-rel-3.c

2019-XX-XX  Christophe Lyon  
Mickaël Guêné 

gcc/testsuite/
* gcc.dg/20020312-2.c: Skip on arm*-*-uclinuxfdpiceabi.
* gcc.target/arm/20051215-1.c: Likewise.
* gcc.target/arm/mmx-1.c: Likewise.
* gcc.target/arm/pr19599.c: Likewise.
* gcc.target/arm/pr40887.c: Likewise.
* gcc.target/arm/pr61948.c: Likewise.
* gcc.target/arm/pr77933-1.c: Likewise.
* gcc.target/arm/pr77933-2.c: Likewise.
* gcc.target/arm/sibcall-1.c: Likewise.
* gcc.target/arm/data-rel-2.c: Likewise.
* gcc.target/arm/data-rel-3.c: Likewise.
* gcc.target/arm/tail-long-call: Likewise.
* gcc.target/arm/tlscall.c: Likewise.
* gcc.target/arm/vfp-longcall-apcs: Likewise.
* gcc.target/arm/ivopts-2.c: Skip object-size test on
arm*-*-uclinuxfdpiceabi.
* gcc.target/arm/ivopts-3.c: Likewise.
* gcc.target/arm/ivopts-4.c: Likewise.
* gcc.target/arm/ivopts-5.c: Likewise.
* gcc.target/arm/pr43597.c: Likewise.
* gcc.target/arm/pr43920-2.c: Likewise.
* gcc.target/arm/pr45701-1.c: Skip scan-assembler on
arm*-*-uclinuxfdpiceabi.
* gcc.target/arm/pr45701-2.c: Likewise.
* gcc.target/arm/stack-red-zone.c: Likewise.

Change-Id: Icada7ce52537901fdac10403e7997571b7e2c509

diff --git a/gcc/testsuite/gcc.dg/20020312-2.c 
b/gcc/testsuite/gcc.dg/20020312-2.c
index 98af0d4..52c33d0 100644
--- a/gcc/testsuite/gcc.dg/20020312-2.c
+++ b/gcc/testsuite/gcc.dg/20020312-2.c
@@ -9,6 +9,7 @@
 /* { dg-options "-O -fno-pic" } */
 /* { dg-additional-options "-no-pie" { target pie_enabled } } */
 /* { dg-require-effective-target nonlocal_goto } */
+/* { dg-skip-if "" { arm*-*-uclinuxfdpiceabi } "*" "" } */
 
 extern void abort (void);
 
diff --git a/gcc/testsuite/gcc.target/arm/20051215-1.c 
b/gcc/testsuite/gcc.target/arm/20051215-1.c
index 0519dc7..cc07693 100644
--- a/gcc/testsuite/gcc.target/arm/20051215-1.c
+++ b/gcc/testsuite/gcc.target/arm/20051215-1.c
@@ -3,6 +3,7 @@
the call would need an output reload.  */
 /* { dg-do run } */
 /* { dg-options "-O2 -fno-omit-frame-pointer" } */
+/* { dg-skip-if "r9 is reserved in FDPIC" { arm*-*-uclinuxfdpiceabi } "*" "" } 
*/
 extern void abort (void);
 typedef void (*callback) (void);
 
diff --git a/gcc/testsuite/gcc.target/arm/data-rel-2.c 
b/gcc/testsuite/gcc.target/arm/data-rel-2.c
index 6ba47d6..7d37a8c 100644
--- a/gcc/testsuite/gcc.target/arm/data-rel-2.c
+++ b/gcc/testsuite/gcc.target/arm/data-rel-2.c
@@ -1,3 +1,4 @@
+/* { dg-skip-if "Not supported in FDPIC" { arm*-*-uclinuxfdpiceabi } "*" "" } 
*/
 /* { dg-options "-fPIC -mno-pic-data-is-text-relative -mno-single-pic-base" } 
*/
 /* { dg-final { scan-assembler-not "j-\\(.LPIC"  } } */
 /* { dg-final { scan-assembler "_GLOBAL_OFFSET_TABLE_-\\(.LPIC" } } */
diff --git a/gcc/testsuite/gcc.target/arm/data-rel-3.c 
b/gcc/testsuite/gcc.target/arm/data-rel-3.c
index 2ce1e66..534c6c4 100644
--- a/gcc/testsuite/gcc.target/arm/data-rel-3.c
+++ b/gcc/testsuite/gcc.target/arm/data-rel-3.c
@@ -1,3 +1,4 @@
+/* { dg-skip-if "Not supported in FDPIC" { arm*-*-uclinuxfdpiceabi } "*" "" } 
*/
 /* { dg-options "-fPIC -mpic-data-is-text-relative" } */
 /* { dg-final { scan-assembler "j-\\(.LPIC"  } } */
 /* { dg-final { scan-assembler-not "_GLOBAL_OFFSET_TABLE_-\\(.LPIC" } } */
diff --git a/gcc/testsuite/gcc.target/arm/ivopts-2.c 
b/gcc/testsuite/gcc.target/arm/ivopts-2.c
index afe91aa..f1d5edb 100644
--- a/gcc/testsuite/gcc.target/arm/ivopts-2.c
+++ b/gcc/testsuite/gcc.target/arm/ivopts-2.c
@@ -14,4 +14,4 @@ tr4 (short array[], int n)
 
 /* { dg-final { scan-tree-dump-times "PHI 

[ARM/FDPIC v6 15/24] [ARM][testsuite] FDPIC: Adjust scan-assembler patterns.

[Christophe Lyon]

From: Christophe Lyon 

In FDPIC mode, r9 is saved in addition to other registers, so update
the expected patterns accordingly.

2019-XX-XX  Christophe Lyon  
Mickaël Guêné 

* gcc/testsuite/
* gcc.target/arm/interrupt-1.c: Add scan-assembler pattern for
arm*-*-uclinuxfdpiceabi.
* gcc.target/arm/interrupt-2.c: Likewise.
* gcc.target/arm/pr70830.c: Likewise.

Change-Id: Id946b79bacc32be585c31e60a355191f104cc29e

diff --git a/gcc/testsuite/gcc.target/arm/interrupt-1.c 
b/gcc/testsuite/gcc.target/arm/interrupt-1.c
index fe94877..493763d 100644
--- a/gcc/testsuite/gcc.target/arm/interrupt-1.c
+++ b/gcc/testsuite/gcc.target/arm/interrupt-1.c
@@ -13,5 +13,7 @@ void foo ()
   bar (0);
 }
 
-/* { dg-final { scan-assembler "push\t{r0, r1, r2, r3, r4, fp, ip, lr}" } } */
-/* { dg-final { scan-assembler "ldmfd\tsp!, {r0, r1, r2, r3, r4, fp, ip, 
pc}\\^" } } */
+/* { dg-final { scan-assembler "push\t{r0, r1, r2, r3, r4, fp, ip, lr}" { 
target { ! arm*-*-uclinuxfdpiceabi } } } } */
+/* { dg-final { scan-assembler "ldmfd\tsp!, {r0, r1, r2, r3, r4, fp, ip, 
pc}\\^" { target { ! arm*-*-uclinuxfdpiceabi } } } } */
+/* { dg-final { scan-assembler "push\t{r0, r1, r2, r3, r4, r5, r9, fp, ip, 
lr}" { target arm*-*-uclinuxfdpiceabi } } } */
+/* { dg-final { scan-assembler "ldmfd\tsp!, {r0, r1, r2, r3, r4, r5, r9, fp, 
ip, pc}\\^" { target arm*-*-uclinuxfdpiceabi } } } */
diff --git a/gcc/testsuite/gcc.target/arm/interrupt-2.c 
b/gcc/testsuite/gcc.target/arm/interrupt-2.c
index 289eca0..5be1f16 100644
--- a/gcc/testsuite/gcc.target/arm/interrupt-2.c
+++ b/gcc/testsuite/gcc.target/arm/interrupt-2.c
@@ -15,5 +15,7 @@ void test()
   foo = 0;
 }
 
-/* { dg-final { scan-assembler "push\t{r0, r1, r2, r3, r4, r5, ip, lr}" } } */
-/* { dg-final { scan-assembler "ldmfd\tsp!, {r0, r1, r2, r3, r4, r5, ip, 
pc}\\^" } } */
+/* { dg-final { scan-assembler "push\t{r0, r1, r2, r3, r4, r5, ip, lr}" { 
target { ! arm*-*-uclinuxfdpiceabi } } } } */
+/* { dg-final { scan-assembler "ldmfd\tsp!, {r0, r1, r2, r3, r4, r5, ip, 
pc}\\^" { target { ! arm*-*-uclinuxfdpiceabi } } } } */
+/* { dg-final { scan-assembler "push\t{r0, r1, r2, r3, r4, r5, r6, r9, ip, 
lr}" { target arm*-*-uclinuxfdpiceabi } } } */
+/* { dg-final { scan-assembler "ldmfd\tsp!, {r0, r1, r2, r3, r4, r5, r6, r9, 
ip, pc}\\^" { target arm*-*-uclinuxfdpiceabi } } } */
diff --git a/gcc/testsuite/gcc.target/arm/pr70830.c 
b/gcc/testsuite/gcc.target/arm/pr70830.c
index cad903b..cd84c42 100644
--- a/gcc/testsuite/gcc.target/arm/pr70830.c
+++ b/gcc/testsuite/gcc.target/arm/pr70830.c
@@ -11,4 +11,5 @@ void __attribute__ ((interrupt ("IRQ"))) 
dm3730_IRQHandler(void)
 {
 prints("IRQ" );
 }
-/* { dg-final { scan-assembler "ldmfd\tsp!, {r0, r1, r2, r3, ip, pc}\\^" } } */
+/* { dg-final { scan-assembler "ldmfd\tsp!, {r0, r1, r2, r3, ip, pc}\\^" { 
target { ! arm*-*-uclinuxfdpiceabi } } } } */
+/* { dg-final { scan-assembler "ldmfd\tsp!, {r0, r1, r2, r3, r4, r9, ip, 
pc}\\^" { target arm*-*-uclinuxfdpiceabi } } } */
-- 
2.6.3

[ARM/FDPIC v6 16/24] [ARM][testsuite] FDPIC: Skip tests that don't work in PIC mode

[Christophe Lyon]

From: Christophe Lyon 

Some tests fail on arm*-*-uclinuxfdpiceabi because it generates PIC
code and they don't support it: skip them. They also fail on
arm*-linux* when forcing -fPIC.

2019-XX-XX  Christophe Lyon  

gcc/testsuite/
* gcc.target/arm/eliminate.c: Accept only nonpic targets.
* g++.dg/other/anon5.C: Likewise.

Change-Id: I8efb8d356ce25b020c44a84b07f79a996dca0358

diff --git a/gcc/testsuite/g++.dg/other/anon5.C 
b/gcc/testsuite/g++.dg/other/anon5.C
index ee4601e..dadd92e 100644
--- a/gcc/testsuite/g++.dg/other/anon5.C
+++ b/gcc/testsuite/g++.dg/other/anon5.C
@@ -1,5 +1,6 @@
 // PR c++/34094
 // { dg-do link { target { ! { *-*-darwin* *-*-hpux* *-*-solaris2.* } } } }
+// { dg-require-effective-target nonpic }
 // { dg-options "-gdwarf-2" }
 // Ignore additional message on powerpc-ibm-aix
 // { dg-prune-output "obtain more information" } */
diff --git a/gcc/testsuite/gcc.target/arm/eliminate.c 
b/gcc/testsuite/gcc.target/arm/eliminate.c
index f254dd8..299d4df 100644
--- a/gcc/testsuite/gcc.target/arm/eliminate.c
+++ b/gcc/testsuite/gcc.target/arm/eliminate.c
@@ -1,4 +1,4 @@
-/* { dg-do compile } */
+/* { dg-do compile { target { nonpic } } } */
 /* { dg-options "-O2" }  */
 
 struct X
-- 
2.6.3

[ARM/FDPIC v6 17/24] [ARM][testsuite] FDPIC: Handle *-*-uclinux*

[Christophe Lyon]

From: Christophe Lyon 

Add *-*-uclinux* to tests that work on this target.

2019-XX-XX  Christophe Lyon  

gcc/testsuite/
* g++.dg/abi/forced.C: Add *-*-uclinux*.
* g++.dg/abi/guard2.C: Likewise.
* g++.dg/ext/cleanup-10.C: Likewise.
* g++.dg/ext/cleanup-11.C: Likewise.
* g++.dg/ext/cleanup-8.C: Likewise.
* g++.dg/ext/cleanup-9.C: Likewise.
* g++.dg/ext/sync-4.C: Likewise.
* g++.dg/ipa/comdat.C: Likewise.
* gcc.dg/20041106-1.c: Likewise.
* gcc.dg/cleanup-10.c: Likewise.
* gcc.dg/cleanup-11.c: Likewise.
* gcc.dg/cleanup-8.c: Likewise.
* gcc.dg/cleanup-9.c: Likewise.
* gcc.dg/fdata-sections-1.c: Likewise.
* gcc.dg/fdata-sections-2.c: Likewise.
* gcc.dg/pr39323-1.c: Likewise.
* gcc.dg/pr39323-2.c: Likewise.
* gcc.dg/pr39323-3.c: Likewise.
* gcc.dg/pr65780-1.c: Likewise.
* gcc.dg/pr65780-2.c: Likewise.
* gcc.dg/pr67338.c: Likewise.
* gcc.dg/pr78185.c: Likewise.
* gcc.dg/pr83100-1.c: Likewise.
* gcc.dg/pr83100-4.c: Likewise.
* gcc.dg/strlenopt-12g.c: Likewise.
* gcc.dg/strlenopt-14g.c: Likewise.
* gcc.dg/strlenopt-14gf.c: Likewise.
* gcc.dg/strlenopt-16g.c: Likewise.
* gcc.dg/strlenopt-17g.c: Likewise.
* gcc.dg/strlenopt-18g.c: Likewise.
* gcc.dg/strlenopt-1f.c: Likewise.
* gcc.dg/strlenopt-22g.c: Likewise.
* gcc.dg/strlenopt-2f.c: Likewise.
* gcc.dg/strlenopt-31g.c: Likewise.
* gcc.dg/strlenopt-33g.c: Likewise.
* gcc.dg/strlenopt-4g.c: Likewise.
* gcc.dg/strlenopt-4gf.c: Likewise.
* gcc.dg/strncmp-2.c: Likewise.
* gcc.dg/struct-ret-3.c: Likewise.
* gcc.dg/torture/pr69760.c: Likewise.
* gcc.target/arm/div64-unwinding.c: Likewise.
* gcc.target/arm/stack-checking.c: Likewise.
* gcc.target/arm/synchronize.c: Likewise.
* gcc.target/arm/pr66912.c: Add arm*-*-uclinuxfdpiceabi.
* lib/target-supports.exp (check_effective_target_pie): Likewise.
(check_effective_target_sync_long_long_runtime): Likewise.
(check_effective_target_sync_int_long): Likewise.
(check_effective_target_sync_char_short): Likewise.

Change-Id: I89bfea79d4490c5df0b6470def5a31d7f31ac2cc

diff --git a/gcc/testsuite/g++.dg/abi/forced.C 
b/gcc/testsuite/g++.dg/abi/forced.C
index 0e6be28..2d1ec53 100644
--- a/gcc/testsuite/g++.dg/abi/forced.C
+++ b/gcc/testsuite/g++.dg/abi/forced.C
@@ -1,4 +1,4 @@
-// { dg-do run { target *-*-linux* *-*-gnu* } }
+// { dg-do run { target *-*-linux* *-*-gnu* *-*-uclinux* } }
 // { dg-options "-pthread" }
 
 #include 
diff --git a/gcc/testsuite/g++.dg/abi/guard2.C 
b/gcc/testsuite/g++.dg/abi/guard2.C
index c35fa7e..74139a8 100644
--- a/gcc/testsuite/g++.dg/abi/guard2.C
+++ b/gcc/testsuite/g++.dg/abi/guard2.C
@@ -1,6 +1,6 @@
 // PR c++/41611
 // Test that the guard gets its own COMDAT group.
-// { dg-final { scan-assembler "_ZGVZN1A1fEvE1i,comdat" { target *-*-linux* 
*-*-gnu* } } }
+// { dg-final { scan-assembler "_ZGVZN1A1fEvE1i,comdat" { target *-*-linux* 
*-*-gnu* *-*-uclinux* } } }
 
 struct A {
   static int f()
diff --git a/gcc/testsuite/g++.dg/ext/cleanup-10.C 
b/gcc/testsuite/g++.dg/ext/cleanup-10.C
index 66c7b76..56aeb66 100644
--- a/gcc/testsuite/g++.dg/ext/cleanup-10.C
+++ b/gcc/testsuite/g++.dg/ext/cleanup-10.C
@@ -1,4 +1,4 @@
-/* { dg-do run { target hppa*-*-hpux* *-*-linux* *-*-gnu* powerpc*-*-darwin* 
*-*-darwin[912]* } } */
+/* { dg-do run { target hppa*-*-hpux* *-*-linux* *-*-gnu* powerpc*-*-darwin* 
*-*-darwin[912]* *-*-uclinux* } } */
 /* { dg-options "-fexceptions -fnon-call-exceptions -O2" } */
 /* Verify that cleanups work with exception handling through signal frames
on alternate stack.  */
diff --git a/gcc/testsuite/g++.dg/ext/cleanup-11.C 
b/gcc/testsuite/g++.dg/ext/cleanup-11.C
index 6e96521..c6d3560 100644
--- a/gcc/testsuite/g++.dg/ext/cleanup-11.C
+++ b/gcc/testsuite/g++.dg/ext/cleanup-11.C
@@ -1,4 +1,4 @@
-/* { dg-do run { target hppa*-*-hpux* *-*-linux* *-*-gnu* powerpc*-*-darwin* 
*-*-darwin[912]* } } */
+/* { dg-do run { target hppa*-*-hpux* *-*-linux* *-*-gnu* powerpc*-*-darwin* 
*-*-darwin[912]* *-*-uclinux* } } */
 /* { dg-options "-fexceptions -fnon-call-exceptions -O2" } */
 /* Verify that cleanups work with exception handling through realtime signal
frames on alternate stack.  */
diff --git a/gcc/testsuite/g++.dg/ext/cleanup-8.C 
b/gcc/testsuite/g++.dg/ext/cleanup-8.C
index ccf9bef..e99508d 100644
--- a/gcc/testsuite/g++.dg/ext/cleanup-8.C
+++ b/gcc/testsuite/g++.dg/ext/cleanup-8.C
@@ -1,4 +1,4 @@
-/* { dg-do run { target hppa*-*-hpux* *-*-linux* *-*-gnu* powerpc*-*-darwin* 
*-*-darwin[912]* } } */
+/* { dg-do run { target hppa*-*-hpux* *-*-linux* *-*-gnu* powerpc*-*-darwin* 
*-*-darwin[912]* *-*-uclinux* } } */
 /* { dg-options "-fexceptions -fnon-call-exceptions -O2" } */
 /* Verify that clea

[ARM/FDPIC v6 18/24] [ARM][testsuite] FDPIC: Enable tests on pie_enabled targets

[Christophe Lyon]

From: Christophe Lyon 

Some tests have the "nonpic" guard, but pass on
arm*-*-uclinuxfdpiceabi because it is in PIE mode by default. Rather
than adding this target to all these tests, add the "pie_enabled"
effective target.

2019-XX-XX  Christophe Lyon  

gcc/testsuite/
* g++.dg/cpp0x/noexcept03.C: Add pie_enabled.
* g++.dg/ipa/devirt-c-7.C: Likewise.
* g++.dg/ipa/ivinline-1.C: Likewise.
* g++.dg/ipa/ivinline-2.C: Likewise.
* g++.dg/ipa/ivinline-3.C: Likewise.
* g++.dg/ipa/ivinline-4.C: Likewise.
* g++.dg/ipa/ivinline-5.C: Likewise.
* g++.dg/ipa/ivinline-7.C: Likewise.
* g++.dg/ipa/ivinline-8.C: Likewise.
* g++.dg/ipa/ivinline-9.C: Likewise.
* g++.dg/tls/pr79288.C: Likewise.
* gcc.dg/addr_equal-1.c: Likewise.
* gcc.dg/const-1.c: Likewise.
* gcc.dg/ipa/pure-const-1.c: Likewise.
* gcc.dg/noreturn-8.c: Likewise.
* gcc.dg/pr33826.c: Likewise.
* gcc.dg/torture/ipa-pta-1.c: Likewise.
* gcc.dg/tree-ssa/alias-2.c: Likewise.
* gcc.dg/tree-ssa/ipa-split-5.c: Likewise.
* gcc.dg/tree-ssa/loadpre6.c: Likewise.
* gcc.dg/uninit-19.c: Likewise.

Change-Id: I1a0d836b892c23891f739fccdc467d0f354ab82c

diff --git a/gcc/testsuite/g++.dg/cpp0x/noexcept03.C 
b/gcc/testsuite/g++.dg/cpp0x/noexcept03.C
index 2d37867..906a44d 100644
--- a/gcc/testsuite/g++.dg/cpp0x/noexcept03.C
+++ b/gcc/testsuite/g++.dg/cpp0x/noexcept03.C
@@ -1,6 +1,6 @@
 // Runtime test for noexcept-specification.
 // { dg-options "-Wnoexcept" }
-// { dg-do run { target nonpic } }
+// { dg-do run { target { nonpic || pie_enabled } } }
 // { dg-require-effective-target c++11 }
 
 #include 
diff --git a/gcc/testsuite/g++.dg/ipa/devirt-c-7.C 
b/gcc/testsuite/g++.dg/ipa/devirt-c-7.C
index 2e76cbe..efb65c2 100644
--- a/gcc/testsuite/g++.dg/ipa/devirt-c-7.C
+++ b/gcc/testsuite/g++.dg/ipa/devirt-c-7.C
@@ -1,7 +1,6 @@
 /* Verify that ipa-cp will not get confused by placement new constructing an
object within another one when looking for dynamic type change .  */
-/* { dg-do run } */
-/* { dg-require-effective-target nonpic } */
+/* { dg-do run { target { nonpic || pie_enabled } } } */
 /* { dg-options "-O3 -Wno-attributes"  } */
 
 extern "C" void abort (void);
diff --git a/gcc/testsuite/g++.dg/ipa/ivinline-1.C 
b/gcc/testsuite/g++.dg/ipa/ivinline-1.C
index 9b10d20..2d988bc 100644
--- a/gcc/testsuite/g++.dg/ipa/ivinline-1.C
+++ b/gcc/testsuite/g++.dg/ipa/ivinline-1.C
@@ -1,6 +1,6 @@
 /* Verify that simple virtual calls are inlined even without early
inlining.  */
-/* { dg-do run { target nonpic } } */
+/* { dg-do run { target { nonpic || pie_enabled } } } */
 /* { dg-options "-O3 -fdump-ipa-inline -fno-early-inlining -fno-ipa-cp"  } */
 
 extern "C" void abort (void);
diff --git a/gcc/testsuite/g++.dg/ipa/ivinline-2.C 
b/gcc/testsuite/g++.dg/ipa/ivinline-2.C
index 21cd46f..d978638 100644
--- a/gcc/testsuite/g++.dg/ipa/ivinline-2.C
+++ b/gcc/testsuite/g++.dg/ipa/ivinline-2.C
@@ -1,6 +1,6 @@
 /* Verify that simple virtual calls using this pointer are inlined
even without early inlining..  */
-/* { dg-do run { target nonpic } } */
+/* { dg-do run { target { nonpic || pie_enabled } } } */
 /* { dg-options "-O3 -fdump-ipa-inline -fno-early-inlining -fno-ipa-cp"  } */
 
 extern "C" void abort (void);
diff --git a/gcc/testsuite/g++.dg/ipa/ivinline-3.C 
b/gcc/testsuite/g++.dg/ipa/ivinline-3.C
index 1e24644..f756a16 100644
--- a/gcc/testsuite/g++.dg/ipa/ivinline-3.C
+++ b/gcc/testsuite/g++.dg/ipa/ivinline-3.C
@@ -1,6 +1,6 @@
 /* Verify that simple virtual calls on an object refrence are inlined
even without early inlining.  */
-/* { dg-do run { target nonpic } } */
+/* { dg-do run { target { nonpic || pie_enabled } } } */
 /* { dg-options "-O3 -fdump-ipa-inline -fno-early-inlining -fno-ipa-cp"  } */
 
 extern "C" void abort (void);
diff --git a/gcc/testsuite/g++.dg/ipa/ivinline-4.C 
b/gcc/testsuite/g++.dg/ipa/ivinline-4.C
index cf0d980..5fbd3ef 100644
--- a/gcc/testsuite/g++.dg/ipa/ivinline-4.C
+++ b/gcc/testsuite/g++.dg/ipa/ivinline-4.C
@@ -1,7 +1,7 @@
 /* Verify that simple virtual calls are inlined even without early
inlining, even when a typecast to an ancestor is involved along the
way.  */
-/* { dg-do run { target nonpic } } */
+/* { dg-do run { target { nonpic || pie_enabled } } } */
 /* { dg-options "-O3 -fdump-ipa-inline -fno-early-inlining -fno-ipa-cp"  } */
 
 extern "C" void abort (void);
diff --git a/gcc/testsuite/g++.dg/ipa/ivinline-5.C 
b/gcc/testsuite/g++.dg/ipa/ivinline-5.C
index f15ebf2..6c19907 100644
--- a/gcc/testsuite/g++.dg/ipa/ivinline-5.C
+++ b/gcc/testsuite/g++.dg/ipa/ivinline-5.C
@@ -1,6 +1,6 @@
 /* Verify that virtual call inlining does not pick a wrong method when
there is a user defined ancestor in an object.  */
-/* { dg-do run { target nonpic } } */
+/* { dg-do run { target { nonpic || pie_enabled } } } */
 /* { dg-options "-O3 -fdump-ipa-inline -f

[ARM/FDPIC v6 19/24] [ARM][testsuite] FDPIC: Adjust pr43698.c to avoid clash with uclibc.

[Christophe Lyon]

From: Christophe Lyon 

uclibc defines bswap_32, so use a different name in this test.

2019-XX-XX  Christophe Lyon  

gcc/testsuite/
* gcc.target/arm/pr43698.c (bswap_32): Rename as my_bswap_32.

Change-Id: I2591bd911030814331cabf97ee5cf6cf8124b4f3

diff --git a/gcc/testsuite/gcc.target/arm/pr43698.c 
b/gcc/testsuite/gcc.target/arm/pr43698.c
index 1fc497c..3b5dad0 100644
--- a/gcc/testsuite/gcc.target/arm/pr43698.c
+++ b/gcc/testsuite/gcc.target/arm/pr43698.c
@@ -6,7 +6,7 @@
 
 char do_reverse_endian = 0;
 
-#  define bswap_32(x) \
+#  define my_bswap_32(x) \
   x) & 0xff00) >> 24) | \
(((x) & 0x00ff) >>  8) | \
(((x) & 0xff00) <<  8) | \
@@ -16,7 +16,7 @@ char do_reverse_endian = 0;
   (__extension__ ({ \
   uint64_t __res; \
   if (!do_reverse_endian) {__res = (X); \
-  } else if (sizeof(X) == 4) { __res = bswap_32((X)); \
+  } else if (sizeof(X) == 4) { __res = my_bswap_32((X)); \
   } \
   __res; \
 }))
-- 
2.6.3

[0/9] Make HARD_REG_SETs easier to use

[Richard Sandiford]

I have a series of patches that allows several ABIs to be used
interoperably within the same translation unit.  Part of that involves
removing our reliance on global register sets that describe "the ABI".

One of the difficulties is that we have several global sets that contain
related information.  E.g.:

   call_used_reg_set == regs_invalidated_by_call | fixed_reg_set

call_fixed_reg_set is derived from call_used_reg_set.
no_caller_save_reg_set is in turn derived from call_fixed_reg_set.

I don't think there's a strong efficiency reason for having a global
cache of things like call_used_reg_set above.  On most targets the
"|" operation is two (parallel) 64-bit logical ORs of nearby data and
so should be very cheap to compute.  I think the sets are more there
for convenience.  And I think the main reason they're convenient is
that HARD_REG_SET is so unwieldly to use.  E.g. if you want to do:

   a &= b | c;

you have to write:

   HARD_REG_SET tmp;
   COPY_HARD_REG_SET (tmp, b);
   IOR_HARD_REG_SET (tmp, c);
   AND_HARD_REG_SET (a, tmp);

Again, each of these operations is individually very cheap on most
targets (a couple of moves or logic ops each).  But because it takes
so much code to write, there's a strong temptation to cache "b | c"
if it's used often.

This series therefore provides the following operators for HARD_REG_SET
and converts existing code to use them:

  = ~ & &= | |= == !=

The reason for picking (only) these is that they work on plain integer
bitmasks too, and so we can continue to treat HARD_REG_SET as a plain
integer when FIRST_PSEUDO_REGISTER is small enough.  As noted at the
end of the covering note for the first patch, that might be overly
conservative, since the sets aren't passed by value all that often
and so the performance gain is probably very slight in practice.
I nevertheless stopped here because the series seems like a strict
improvement compared to the status quo and is all that I need for the
motivating follow-on series.

Tested on aarch64-linux-gnu and x86_64-linux-gnu.  Also tested by
compiling one target for each CPU directory and making sure that
there were no changes in assembly code for gcc.c-torture, gcc.dg
and g++.dg.  (This was before the eBPF port went in, but that's
conveniently free of HARD_REG_SETs.)

Richard

[ARM/FDPIC v6 20/24] [ARM][testsuite] FDPIC: Skip tests using architectures unsupported by FDPIC

[Christophe Lyon]

From: Christophe Lyon 

Since FDPIC currently supports arm and thumb-2 modes only, these tests
fail because they enforce an architecture version that doesn't match
these restrictions.

This patch introduces new values for the arm_arch effective-target
(v4t_thumb, v5t_thumb, v5te_thumb, v6_thumb, v6k_thumb, v6z_thumb) as
needed, and adds them to the relevant tests.  In addition, it adds
v4t_arm, v5t_arm, v5te_arm, v6_arm, v6k_arm and v6z_arm to avoid
skipping some tests when GCC is configured to generate Thumb code by
default.

It also adds the corresponding non-thumb effective-target to the tests
that were missing it.

The existing v4t, v5t, v5te, v6 v6k and v6z effective-targets now force
-mfloat-abi=softfp since these thumb-1 targets do not support
hard-float anyway.

Finally, the patch removes the special case to detect the presence of
-marm in the flags, since it makes atomic_loaddi tests unsupported:
since the flags in question also include -march, the combination is
supported, while -marm alone is not if GCC is configured to target an
M-profile CPU.

2019-XX-XX  Christophe Lyon  

gcc/testsuite/
* lib/target-supports.exp
(check_effective_target_arm_arch_FUNC_ok): Add v4t_arm, v4t_thumb,
v5t_arm, v5t_thumb, v5te_arm, v5te_thumb, v6_arm, v6_thumb,
v6k_arm, v6k_thumb, v6z_arm, v6z_thumb.
Add -mfloat-abi=softfp to v4t, v5t, v5te, v6, v6k, v6z.
Remove early exit for -marm.
* gcc.target/arm/armv6-unaligned-load-ice.c: Add arm_arch
effective-target.
* gcc.target/arm/attr-unaligned-load-ice.c: Likewise.
* gcc.target/arm/ftest-armv4-arm.c: Likewise.
* gcc.target/arm/ftest-armv4t-arm.c: Likewise.
* gcc.target/arm/ftest-armv4t-thumb.c: Likewise.
* gcc.target/arm/ftest-armv5t-arm.c: Likewise.
* gcc.target/arm/ftest-armv5t-thumb.c: Likewise.
* gcc.target/arm/ftest-armv5te-arm.c: Likewise.
* gcc.target/arm/ftest-armv5te-thumb.c: Likewise.
* gcc.target/arm/ftest-armv6-arm.c: Likewise.
* gcc.target/arm/ftest-armv6-thumb.c: Likewise.
* gcc.target/arm/ftest-armv6k-arm.c: Likewise.
* gcc.target/arm/ftest-armv6k-thumb.c: Likewise.
* gcc.target/arm/ftest-armv6m-thumb.c: Likewise.
* gcc.target/arm/ftest-armv6t2-arm.c: Likewise.
* gcc.target/arm/ftest-armv6t2-thumb.c: Likewise.
* gcc.target/arm/ftest-armv6z-arm.c: Likewise.
* gcc.target/arm/ftest-armv6z-thumb.c: Likewise.
* gcc.target/arm/g2.c: Likewise.
* gcc.target/arm/macro_defs1.c: Likewise.
* gcc.target/arm/pr59858.c: Likewise.
* gcc.target/arm/pr65647-2.c: Likewise.
* gcc.target/arm/pr79058.c: Likewise.
* gcc.target/arm/pr83712.c: Likewise.
* gcc.target/arm/pragma_arch_switch_2.c: Likewise.
* gcc.target/arm/scd42-1.c: Likewise.
* gcc.target/arm/scd42-2.c: Likewise.
* gcc.target/arm/scd42-3.c: Likewise.
* gcc.c-torture/compile/pr82096.c: Fix arm_arch effective-target.
* gcc.target/arm/attr_arm-err.c: Likewise.
* gcc.target/arm/di-longlong64-sync-withldrexd.c: Likewise.

Change-Id: I0845b262b241026561cc52a19ff8bb1659675e49

diff --git a/gcc/testsuite/gcc.c-torture/compile/pr82096.c 
b/gcc/testsuite/gcc.c-torture/compile/pr82096.c
index d144b70..4e695cd 100644
--- a/gcc/testsuite/gcc.c-torture/compile/pr82096.c
+++ b/gcc/testsuite/gcc.c-torture/compile/pr82096.c
@@ -1,4 +1,4 @@
-/* { dg-require-effective-target arm_arch_v5t_ok { target arm*-*-* } } */
+/* { dg-require-effective-target arm_arch_v5t_thumb_ok { target arm*-*-* } } */
 /* { dg-skip-if "Do not combine float-abi values" { arm*-*-* } { 
"-mfloat-abi=*" } { "-mfloat-abi=soft" } } */
 /* { dg-additional-options "-march=armv5t -mthumb -mfloat-abi=soft" { target 
arm*-*-* } } */
 
diff --git a/gcc/testsuite/gcc.target/arm/armv6-unaligned-load-ice.c 
b/gcc/testsuite/gcc.target/arm/armv6-unaligned-load-ice.c
index 88528f1..886a012 100644
--- a/gcc/testsuite/gcc.target/arm/armv6-unaligned-load-ice.c
+++ b/gcc/testsuite/gcc.target/arm/armv6-unaligned-load-ice.c
@@ -1,6 +1,7 @@
 /* { dg-do compile } */
 /* { dg-skip-if "avoid conflicting multilib options" { *-*-* } { "-march=*" } 
{ "-march=armv6k" } } */
 /* { dg-skip-if "avoid conflicting multilib options" { *-*-* } { "-marm" } { 
"" } } */
+/* { dg-require-effective-target arm_arch_v6k_thumb_ok } */
 /* { dg-options "-mthumb -Os -mfloat-abi=softfp" } */
 /* { dg-add-options arm_arch_v6k } */
 
diff --git a/gcc/testsuite/gcc.target/arm/attr-unaligned-load-ice.c 
b/gcc/testsuite/gcc.target/arm/attr-unaligned-load-ice.c
index e1ed1c1..2eeb522 100644
--- a/gcc/testsuite/gcc.target/arm/attr-unaligned-load-ice.c
+++ b/gcc/testsuite/gcc.target/arm/attr-unaligned-load-ice.c
@@ -2,6 +2,7 @@
Verify that unaligned_access is correctly with attribute target.  */
 /* { dg-do compile } */
 /* { dg-skip-if "avoid conflicting multilib options" { *-*-* } { "-march=*" } 
{ "

[ARM/FDPIC v6 21/24] [ARM] FDPIC: Handle stack-protector combined patterns

[Christophe Lyon]

From: Christophe Lyon 

The recent stack_protect_combined_set_insn and
stack_protect_combined_test_insn force recomputing of GOT base, but
need to take into account that in FDPIC mode, the PIC register is
fixed by the ABI (r9).

2019-XX-XX  Christophe Lyon  

gcc/
* config/arm/arm.md (stack_protect_combined_set_insn): Handle
FDPIC mode.
(stack_protect_combined_test_insn): Likewise.

Change-Id: I0e47cf30cfe0dc401f43bd728aaae07bffa4c9cc

diff --git a/gcc/config/arm/arm.md b/gcc/config/arm/arm.md
index 918271d..6513c2d 100644
--- a/gcc/config/arm/arm.md
+++ b/gcc/config/arm/arm.md
@@ -8270,8 +8270,15 @@
 {
   if (flag_pic)
 {
+  rtx pic_reg;
+
+  if (TARGET_FDPIC)
+ pic_reg = gen_rtx_REG (Pmode, FDPIC_REGNUM);
+  else
+ pic_reg = operands[3];
+
   /* Forces recomputing of GOT base now.  */
-  legitimize_pic_address (operands[1], SImode, operands[2], operands[3],
+  legitimize_pic_address (operands[1], SImode, operands[2], pic_reg,
  true /*compute_now*/);
 }
   else
@@ -8346,8 +8353,15 @@
 
   if (flag_pic)
 {
+  rtx pic_reg;
+
+  if (TARGET_FDPIC)
+ pic_reg = gen_rtx_REG (Pmode, FDPIC_REGNUM);
+  else
+ pic_reg = operands[4];
+
   /* Forces recomputing of GOT base now.  */
-  legitimize_pic_address (operands[1], SImode, operands[3], operands[4],
+  legitimize_pic_address (operands[1], SImode, operands[3], pic_reg,
  true /*compute_now*/);
 }
   else
-- 
2.6.3

[ARM/FDPIC v6 22/24] [ARM][testsuite] FDPIC: Skip tests that require -static support

[Christophe Lyon]

From: Christophe Lyon 

Since FDPIC does not support -static, skip the related tests.

2019-XX-XX  Christophe Lyon  

gcc/testsuite/
* lib/target-supports.exp (check_effective_target_static): Disable
for ARM FDPIC target.

Change-Id: I119d0541e53f2f1e531540b20e7bc47d8338d89a

diff --git a/gcc/testsuite/lib/target-supports.exp 
b/gcc/testsuite/lib/target-supports.exp
index 1a1eed8..19899ce 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -1083,6 +1083,9 @@ proc check_effective_target_pe_aligned_commons {} {
 
 # Return 1 if the target supports -static
 proc check_effective_target_static {} {
+if { [istarget arm*-*-uclinuxfdpiceabi] } {
+   return 0;
+}
 return [check_no_compiler_messages static executable {
int main (void) { return 0; }
 } "-static"]
-- 
2.6.3

[ARM/FDPIC v6 23/24] [ARM] FDPIC: Implement libitm support.

[Christophe Lyon]

From: Christophe Lyon 

The ldaddr macro in sjlj.S needs to be updated to support the FDPIC
model.

2019-XX-XX  Christophe Lyon  

libitm/
* config/arm/sjlj.S (ldaddr): Add FDPIC support.

Change-Id: Ieb2c6613363341d109c3500af0575b133b17407d

diff --git a/libitm/config/arm/sjlj.S b/libitm/config/arm/sjlj.S
index a9abf16..5d44964 100644
--- a/libitm/config/arm/sjlj.S
+++ b/libitm/config/arm/sjlj.S
@@ -49,7 +49,16 @@
.arch   armv7-m
 #endif
 
-#if defined(HAVE_MOVT) && defined(PIC)
+#if defined(__FDPIC__)
+.macro ldaddr reg, addr
+   ldr \reg, 99f
+   add \reg, \reg, r9
+.subsection 1
+   .align  2
+99:.word   \addr(GOTOFF)
+.subsection 0
+.endm
+#elif defined(HAVE_MOVT) && defined(PIC)
 .macro ldaddr reg, addr
movw\reg, #:lower16:(\addr - (98f + PC_OFS))
movt\reg, #:upper16:(\addr - (98f + PC_OFS))
-- 
2.6.3

[ARM/FDPIC v6 24/24] [ARM] FDPIC: Handle arm*-*-uclinuxfdpiceabi in libstdc++ configure scripts

[Christophe Lyon]

From: Christophe Lyon 

2019-XX-XX  Christophe Lyon  

libstdc++-v3/
* acinclude.m4: Handle uclinux*.
* configure: Regenerate.
* configure.host: Handle uclinux*

Change-Id: Ia1b53693625e4153a090fcfc925a4d605bc98e59

diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
index bc9095f..ad2cb01 100644
--- a/libstdc++-v3/acinclude.m4
+++ b/libstdc++-v3/acinclude.m4
@@ -1441,6 +1441,9 @@ AC_DEFUN([GLIBCXX_ENABLE_LIBSTDCXX_TIME], [
 ac_has_nanosleep=yes
 ac_has_sched_yield=yes
 ;;
+  uclinux*)
+ac_has_nanosleep=yes
+ac_has_sched_yield=yes
 esac
 
   elif test x"$enable_libstdcxx_time" != x"no"; then
@@ -1526,7 +1529,7 @@ AC_DEFUN([GLIBCXX_ENABLE_LIBSTDCXX_TIME], [
 
   if test x"$ac_has_clock_monotonic" != x"yes"; then
 case ${target_os} in
-  linux*)
+  linux* | uclinux*)
AC_MSG_CHECKING([for clock_gettime syscall])
AC_TRY_COMPILE(
  [#include 
@@ -4424,7 +4427,7 @@ AC_DEFUN([GLIBCXX_ENABLE_FILESYSTEM_TS], [
   freebsd*|netbsd*|openbsd*|dragonfly*|darwin*)
 enable_libstdcxx_filesystem_ts=yes
 ;;
-  gnu* | linux* | kfreebsd*-gnu | knetbsd*-gnu)
+  gnu* | linux* | kfreebsd*-gnu | knetbsd*-gnu | uclinux*)
 enable_libstdcxx_filesystem_ts=yes
 ;;
   rtems*)
@@ -4606,7 +4609,7 @@ dnl
 AC_MSG_CHECKING([for sendfile that can copy files])
 AC_CACHE_VAL(glibcxx_cv_sendfile, [dnl
   case "${target_os}" in
-gnu* | linux* | solaris*)
+gnu* | linux* | solaris* | uclinux*)
   GCC_TRY_COMPILE_OR_LINK(
 [#include ],
 [sendfile(1, 2, (off_t*)0, sizeof 1);],
diff --git a/libstdc++-v3/configure b/libstdc++-v3/configure
index 4e714e5..c63789c 100755
--- a/libstdc++-v3/configure
+++ b/libstdc++-v3/configure
@@ -6652,7 +6652,7 @@ irix5* | irix6* | nonstopux*)
   ;;
 
 # This must be Linux ELF.
-linux* | k*bsd*-gnu | kopensolaris*-gnu)
+linux* | k*bsd*-gnu | kopensolaris*-gnu | uclinuxfdpiceabi)
   lt_cv_deplibs_check_method=pass_all
   ;;
 
@@ -9598,7 +9598,7 @@ _LT_EOF
   archive_expsym_cmds='sed "s,^,_," $export_symbols 
>$output_objdir/$soname.expsym~$CC -shared $pic_flag $libobjs $deplibs 
$compiler_flags ${wl}-h,$soname 
${wl}--retain-symbols-file,$output_objdir/$soname.expsym 
${wl}--image-base,`expr ${RANDOM-$$} % 4096 / 2 \* 262144 + 1342177280` -o $lib'
   ;;
 
-gnu* | linux* | tpf* | k*bsd*-gnu | kopensolaris*-gnu)
+gnu* | linux* | tpf* | k*bsd*-gnu | kopensolaris*-gnu | uclinuxfdpiceabi)
   tmp_diet=no
   if test "$host_os" = linux-dietlibc; then
case $cc_basename in
@@ -11138,7 +11138,12 @@ linux*oldld* | linux*aout* | linux*coff*)
   ;;
 
 # This must be Linux ELF.
-linux* | k*bsd*-gnu | kopensolaris*-gnu)
+
+# uclinux* changes (here and below) have been submitted to the libtool
+# project, but have not yet been accepted: they are GCC-local changes
+# for the time being.  (See
+# https://lists.gnu.org/archive/html/libtool-patches/2018-05/msg0.html)
+linux* | k*bsd*-gnu | kopensolaris*-gnu | uclinuxfdpiceabi)
   version_type=linux
   need_lib_prefix=no
   need_version=no
@@ -14822,7 +14827,12 @@ linux*oldld* | linux*aout* | linux*coff*)
   ;;
 
 # This must be Linux ELF.
-linux* | k*bsd*-gnu | kopensolaris*-gnu)
+
+# uclinux* changes (here and below) have been submitted to the libtool
+# project, but have not yet been accepted: they are GCC-local changes
+# for the time being.  (See
+# https://lists.gnu.org/archive/html/libtool-patches/2018-05/msg0.html)
+linux* | k*bsd*-gnu | kopensolaris*-gnu | uclinuxfdpiceabi)
   version_type=linux
   need_lib_prefix=no
   need_version=no
@@ -20899,6 +20909,9 @@ $as_echo "$glibcxx_glibc217" >&6; }
 ac_has_nanosleep=yes
 ac_has_sched_yield=yes
 ;;
+  uclinux*)
+ac_has_nanosleep=yes
+ac_has_sched_yield=yes
 esac
 
   elif test x"$enable_libstdcxx_time" != x"no"; then
@@ -21347,7 +21360,7 @@ $as_echo "$ac_has_nanosleep" >&6; }
 
   if test x"$ac_has_clock_monotonic" != x"yes"; then
 case ${target_os} in
-  linux*)
+  linux* | uclinux*)
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for clock_gettime 
syscall" >&5
 $as_echo_n "checking for clock_gettime syscall... " >&6; }
cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -28316,7 +28329,7 @@ _ACEOF
 if ac_fn_c_try_link "$LINENO"; then :
   chktls_save_LDFLAGS="$LDFLAGS"
  case $host in
-   *-*-linux*)
+   *-*-linux* | -*-uclinuxfdpic*)
  LDFLAGS="-shared -Wl,--no-undefined $LDFLAGS"
  ;;
  esac
@@ -47824,7 +47837,7 @@ _ACEOF
 if ac_fn_c_try_link "$LINENO"; then :
   chktls_save_LDFLAGS="$LDFLAGS"
  case $host in
-   *-*-linux*)
+   *-*-linux* | -*-uclinuxfdpic*)
  LDFLAGS="-shared -Wl,--no-undefined $LDFLAGS"
  ;;
  esac
@@ -54011,7 +54024,7 @@ _ACEO

[1/9] Simplify the implementation of HARD_REG_SET

[Richard Sandiford]

We have two styles of HARD_REG_SET: a single integer based on
HOST_WIDEST_FAST_INT (used when FIRST_PSEUDO_REGISTER is small enough)
or an array of integers.  One of the nice properties of this arrangement
is that:

  void foo (const HARD_REG_SET);

is passed by value as an integer when the set is small enough and
by reference otherwise.

(This is in constrast to "const HARD_REG_SET &", which would always
be passed by reference, and in contrast to passing a structure wrapper
like "struct s { T elts[1]; }" by value, where the structure might be
passed like a T or by reference, depending on the ABI.)

However, one of the disadvantages of using an array is that simple
assignment doesn't work.  We need to use COPY_HARD_REG_SET instead.

This patch uses a structure wrapper around the array, and preserves
the above "nice property" using a new const_hard_reg_set typedef.
The patch also removes the manual unrolling for small array sizes;
I think these days we can rely on the compiler to do that for us.

This meant fixing two port-specific quirks:

- epiphany passed NULL as a HARD_REG_SET whose value doesn't matter.
  The patch passes the NO_REGS set instead.

- ia64 reused TEST_HARD_REG_BIT and SET_HARD_REG_BIT for arrays that
  are bigger than HARD_REG_SET.  The patch just open-codes them.

The patch is probably being too conservative.  Very few places actually
take advantage of the "nice property" above, and we could have a
cleaner interface if we used a structure wrapper for all cases.


2019-09-09  Richard Sandiford  

gcc/
* hard-reg-set.h (HARD_REG_SET): Define using a typedef rather
than a #define.  Use a structure rather than an array as the
fallback definition.  Remove special cases for low array sizes.
(const_hard_reg_set): New typedef.
(hard_reg_set_subset_p): Use it instead of "const HARD_REG_SET".
(hard_reg_set_equal_p, hard_reg_set_intersect_p): Likewise.
(hard_reg_set_empty_p): Likewise.
(SET_HARD_REG_BIT): Use a function rather than a macro to
handle the case in which HARD_REG_SET is a structure.
(CLEAR_HARD_REG_BIT, TEST_HARD_REG_BIT, CLEAR_HARD_REG_SET)
(SET_HARD_REG_SET, COPY_HARD_REG_SET, COMPL_HARD_REG_SET)
(AND_HARD_REG_SET, AND_COMPL_HARD_REG_SET, IOR_HARD_REG_SET)
(IOR_COMPL_HARD_REG_SET): Likewise.
(hard_reg_set_iterator::pset): Constify the pointer target.
(hard_reg_set_iter_init): Take a const_hard_reg_set instead
of a "const HARD_REG_SET".  Update the handling of non-integer
HARD_REG_SETs.
* recog.h: Test HARD_CONST instead of CLEAR_HARD_REG_SET.
* reload.h: Likewise.
* rtl.h (choose_hard_reg_mode): Remove unnecessary line break.
* regs.h (in_hard_reg_set_p): Take a const_hard_reg_set instead
of a "const HARD_REG_SET".
(overlaps_hard_reg_set_p, range_overlaps_hard_reg_set_p): Likewise.
(range_in_hard_reg_set_p): Likewise.
* ira-costs.c (restrict_cost_classes): Likewise.
* shrink-wrap.c (move_insn_for_shrink_wrap): Likewise.
* config/epiphany/resolve-sw-modes.c (pass_resolve_sw_modes::execute):
Pass a NO_REGS HARD_REG_SET rather than NULL to emit_set_fp_mode.
* config/ia64/ia64.c (rws_insn): In the CHECKING_P version,
use unsigned HOST_WIDEST_FAST_INT rather than HARD_REG_ELT_TYPE.
(rws_insn_set, rws_insn_test): In the CHECKING_P version,
take an unsigned int and open-code the HARD_REG_SET operations.

Index: gcc/hard-reg-set.h
===
*** gcc/hard-reg-set.h  2019-09-09 16:53:27.837266363 +0100
--- gcc/hard-reg-set.h  2019-09-09 16:53:27.829266420 +0100
*** typedef unsigned HOST_WIDEST_FAST_INT HA
*** 42,55 
  
  #if FIRST_PSEUDO_REGISTER <= HOST_BITS_PER_WIDEST_FAST_INT
  
! #define HARD_REG_SET HARD_REG_ELT_TYPE
  
  #else
  
  #define HARD_REG_SET_LONGS \
   ((FIRST_PSEUDO_REGISTER + HOST_BITS_PER_WIDEST_FAST_INT - 1) \
/ HOST_BITS_PER_WIDEST_FAST_INT)
! typedef HARD_REG_ELT_TYPE HARD_REG_SET[HARD_REG_SET_LONGS];
  
  #endif
  
--- 42,61 
  
  #if FIRST_PSEUDO_REGISTER <= HOST_BITS_PER_WIDEST_FAST_INT
  
! typedef HARD_REG_ELT_TYPE HARD_REG_SET;
! typedef const HARD_REG_SET const_hard_reg_set;
  
  #else
  
  #define HARD_REG_SET_LONGS \
   ((FIRST_PSEUDO_REGISTER + HOST_BITS_PER_WIDEST_FAST_INT - 1) \
/ HOST_BITS_PER_WIDEST_FAST_INT)
! 
! struct HARD_REG_SET
! {
!   HARD_REG_ELT_TYPE elts[HARD_REG_SET_LONGS];
! };
! typedef const HARD_REG_SET &const_hard_reg_set;
  
  #endif
  
*** #define HARD_CONST(X) ((HARD_REG_ELT_TYP
*** 98,104 
  
  #define UHOST_BITS_PER_WIDE_INT ((unsigned) HOST_BITS_PER_WIDEST_FAST_INT)
  
! #ifdef HARD_REG_SET
  
  #define SET_HARD_REG_BIT(SET, BIT)  \
   ((SET) |= HARD_CONST (1) << (BIT))
--- 104,110 
  
  #define UHOST_BITS_PER_WIDE_INT ((unsigned) HOST_BITS_PER_WIDEST_FAST_INT)
  
! #if FIRST_PSEU

Re: [Patch 0/X] [WIP][RFC][libsanitizer] Introduce HWASAN to GCC

[Matthew Malcomson]

On 09/09/19 11:47, Martin Liška wrote:
> On 9/6/19 4:46 PM, Matthew Malcomson wrote:
>> Hello,
>>
>> This patch series is a WORK-IN-PROGRESS towards porting the LLVM hardware
>> address sanitizer (HWASAN) in GCC.  The document describing HWASAN can be 
>> found
>> here http://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html.
> 
> Hello.
> 
> I'm happy that you are working on the functionality for GCC and I can provide
> my knowledge that I have with ASAN. I briefly read the patch series and I have
> multiple questions (and observations):
> 
> 1) Is the ambition of the patchset to be a software emulation of MTE that can
> work targets that do not support MTE? Is it something what clang
> names hwasan-abi=interceptor?

The ambition is to provide a software emulation of MTE for AArch64 
targets that don't support MTE.
I also hope to have the framework set up so that enabling for other 
architectures is relatively easy and can be done by those interested.

As I understand it, `hwasan-abi=interceptor` vs `platform` is about 
adding such MTE emulation for "application code" or "platform code (e.g. 
kernel)" respectively.

> 
> 2) Do you have a real aarch64 hardware that has MTE support? Would it be 
> possible
> for the future to give such a machine to GCC Compile Farm for testing 
> purpose?

No our team doesn't have real MTE hardware, I have been testing on an 
AArch64 machine that has TBI, other work in the team that requires MTE 
support is being tested on the Arm "Fast Models" emulator.

> 
> 3) I like the idea of sharing of internal functions like 
> ASAN_CHECK/HWASAN_CHECK.
> We should benefit from that in the future.
> 
> 4) Am I correct that due to escape of "tagged" pointers, one needs to have an 
> entire
> DSO (dynamic shared object) built with hwasan enabled? Otherwise, a 
> dereference of
> a tagged pointer will lead to a segfault (except TBI feature on aarch64)?


Yes, one needs to take pains to avoid the escape of tagged pointers on 
architectures other than AArch64.

I don't believe that compiling the entire DSO with HWASAN enabled is 
enough, since pointers can be passed across DSO boundaries.
I haven't yet looked into how to handle this.

There's an even more fundamental problem of accesses within the 
instrumented binary -- I haven't yet figured out how to remove the tag 
before accesses on architectures without the AArch64 TBI feature.


> 
> 5) Is there a documentation/definition of how shadow memory for memory 
> tagging looks like?
> Is it similar to ASAN, where one can get to tag with:
> u8 memory_tag = *((PTR >> TG) + SHADOW_OFFSET) & 0xf?
> 

Yes, it's similar.

 From the libhwasan code, the function to fetch a pointer to the shadow 
memory byte corresponding to a memory address is MemToShadow.

constexpr uptr kShadowScale = 4;
inline uptr MemToShadow(uptr untagged_addr) {
   return (untagged_addr >> kShadowScale) +
  __hwasan_shadow_memory_dynamic_address;
}

https://github.com/llvm-mirror/compiler-rt/blob/99ce9876124e910475c627829bf14326b8073a9d/lib/hwasan/hwasan_mapping.h#L42


> 6) Note that thing like memtag_tag_size, memtag_granule_size define an ABI of 
> libsanitizer
> 

Yes, the size of these values define an ABI.

Those particular hooks are added as a demonstration for how something 
like MTE would be implemented on top of this framework (where the 
backend would specify the tag and granule size to match their targets 
architecture).

HWASAN itself would use the hard-coded tag and granule size that matches 
what libsanitizer uses.
https://github.com/llvm-mirror/compiler-rt/blob/99ce9876124e910475c627829bf14326b8073a9d/lib/hwasan/hwasan_mapping.h#L36

I define these as `HWASAN_TAG_SIZE` and `HWASAN_TAG_GRANULE_SIZE` in 
asan.h, and when using the sanitizer library the macro 
`HARDWARE_MEMORY_TAGGING` would be false so their values would be constant.


>>
>> The current patch series is far from complete, but I'm posting the current 
>> state
>> to provide something to discuss at the Cauldron next week.
>>
>> In its current state, this sanitizer only works on AArch64 with a custom 
>> kernel
>> to allow tagged pointers in system calls.  This is discussed in the below 
>> link
>> https://source.android.com/devices/tech/debug/hwasan -- the custom kernel 
>> allows
>> tagged pointers in syscalls.
> 
> Can you be please more specific. Is the MTE in upstream linux kernel? If so,
> starting from which version?

I find I can only make complicated statements remotely clear in bullet 
points ;-)

What I was trying to say was:
- HWASAN from this patch series requires AArch64 TBI.
   (I have not handled architectures without TBI)
- The upstream kernel does not accept tagged pointers in syscalls.
   (programs that use TBI must currently clear tags before passing
pointers to the kernel)
- This patch series doesn't include any way to avoid passing tagged
   pointers to syscalls.
- Hence on order to test the sanitizer I'm using a kernel that has been

[2/9] Remove COPY_HARD_REG_SET

[Richard Sandiford]

This patch replaces "COPY_HARD_REG_SET (x, y)" with "x = y".


2019-09-09  Richard Sandiford  

gcc/
* hard-reg-set.h (COPY_HARD_REG_SET): Delete.
* caller-save.c (save_call_clobbered_regs): Use assignment instead
of COPY_HARD_REG_SET.
* config/epiphany/epiphany.c (epiphany_compute_frame_size): Likewise.
(epiphany_conditional_register_usage): Likewise.
* config/frv/frv.c (frv_ifcvt_modify_tests): Likewise.
* config/gcn/gcn.c (gcn_md_reorg): Likewise.
* config/ia64/ia64.c (ia64_compute_frame_size): Likewise.
* config/m32c/m32c.c (m32c_register_move_cost): Likewise.
* config/m68k/m68k.c (m68k_conditional_register_usage): Likewise.
* config/mips/mips.c (mips_class_max_nregs): Likewise.
* config/pdp11/pdp11.c (pdp11_conditional_register_usage): Likewise.
* config/rs6000/rs6000.c (rs6000_register_move_cost): Likewise.
* config/sh/sh.c (output_stack_adjust): Likewise.
* final.c (collect_fn_hard_reg_usage): Likewise.
(get_call_reg_set_usage): Likewise.
* ira-build.c (ira_create_object, remove_low_level_allocnos)
(ira_flattening): Likewise.
* ira-color.c (add_allocno_hard_regs, add_allocno_hard_regs_to_forest)
(setup_left_conflict_sizes_p, setup_profitable_hard_regs)
(get_conflict_and_start_profitable_regs, allocno_reload_assign)
(ira_reassign_pseudos): Likewise.
* ira-conflicts.c (print_allocno_conflicts): Likewise.
(ira_build_conflicts): Likewise.
* ira-costs.c (restrict_cost_classes): Likewise.
(setup_regno_cost_classes_by_aclass): Likewise.
* ira.c (setup_class_hard_regs, setup_alloc_regs): Likewise.
(setup_reg_subclasses, setup_class_subset_and_memory_move_costs)
(setup_stack_reg_pressure_class, setup_pressure_classes)
(setup_allocno_and_important_classes, setup_class_translate_array)
(setup_reg_class_relations, setup_prohibited_class_mode_regs)
(ira_setup_eliminable_regset): Likewise.
* lra-assigns.c (find_hard_regno_for_1): Likewise.
(setup_live_pseudos_and_spill_after_risky_transforms): Likewise.
* lra-constraints.c (prohibited_class_reg_set_mode_p): Likewise.
(process_alt_operands, inherit_in_ebb): Likewise.
* lra-lives.c (process_bb_lives): Likewise.
* lra-spills.c (assign_spill_hard_regs): Likewise.
* lra.c (lra): Likewise.
* mode-switching.c (new_seginfo): Likewise.
* postreload.c (reload_combine): Likewise.
* reg-stack.c (straighten_stack): Likewise.
* reginfo.c (save_register_info, restore_register_info): Likewise.
(init_reg_sets_1, record_subregs_of_mode): Likewise
* regrename.c (create_new_chain, rename_chains): Likewise.
* reload1.c (order_regs_for_reload, find_reg): Likewise.
(find_reload_regs): Likewise.
* resource.c (find_dead_or_set_registers): Likewise.
(mark_target_live_regs): Likewise.
* sel-sched.c (mark_unavailable_hard_regs): Likewise.

Index: gcc/hard-reg-set.h
===
--- gcc/hard-reg-set.h  2019-09-09 16:04:49.265855317 +0100
+++ gcc/hard-reg-set.h  2019-09-09 16:06:17.649228402 +0100
@@ -83,10 +83,10 @@ #define HARD_CONST(X) ((HARD_REG_ELT_TYP
CLEAR_HARD_REG_SET and SET_HARD_REG_SET.
These take just one argument.
 
-   Also define macros for copying hard reg sets:
-   COPY_HARD_REG_SET and COMPL_HARD_REG_SET.
-   These take two arguments TO and FROM; they read from FROM
-   and store into TO.  COMPL_HARD_REG_SET complements each bit.
+   Also define macros for copying the complement of a hard reg set:
+   COMPL_HARD_REG_SET.
+   This takes two arguments TO and FROM; it reads from FROM
+   and stores into TO.
 
Also define macros for combining hard reg sets:
IOR_HARD_REG_SET and AND_HARD_REG_SET.
@@ -116,7 +116,6 @@ #define TEST_HARD_REG_BIT(SET, BIT)  \
 #define CLEAR_HARD_REG_SET(TO) ((TO) = HARD_CONST (0))
 #define SET_HARD_REG_SET(TO) ((TO) = ~ HARD_CONST (0))
 
-#define COPY_HARD_REG_SET(TO, FROM) ((TO) = (FROM))
 #define COMPL_HARD_REG_SET(TO, FROM) ((TO) = ~(FROM))
 
 #define IOR_HARD_REG_SET(TO, FROM) ((TO) |= (FROM))
@@ -186,12 +185,6 @@ SET_HARD_REG_SET (HARD_REG_SET &set)
 }
 
 inline void
-COPY_HARD_REG_SET (HARD_REG_SET &to, const_hard_reg_set from)
-{
-  to = from;
-}
-
-inline void
 COMPL_HARD_REG_SET (HARD_REG_SET &to, const_hard_reg_set from)
 {
   for (unsigned int i = 0; i < ARRAY_SIZE (to.elts); ++i)
Index: gcc/caller-save.c
===
--- gcc/caller-save.c   2019-09-09 12:27:14.238372431 +0100
+++ gcc/caller-save.c   2019-09-09 16:06:17.629228543 +0100
@@ -775,7 +775,7 @@ save_call_clobbered_regs (void)
 
  if (code == JUMP_INSN)
/* Restore all registers if this is a JUMP_INSN.  */
-   COPY_HARD_REG_SE