Re: [PATCH] Fix a C++ crash with may_alias type attribute

[Bernd Edlinger]

On 04/05/17 00:33, Ville Voutilainen wrote:
> On 5 April 2017 at 00:29, Bernd Edlinger  wrote:
>>> The new test doesn't really belong in the libstdc++, does it?
>>>
>>> If this is a bug in the front-end then a reduced version of the test
>>> belongs in the g++ testsuite.
>>>
>>
>> Yes, I moved the test case to the g++.dg/lto branch, where it
>> fortunately also works (I forgot to mention that the crash only
>> happened with -flto).
>>
>> Is it Ok for trunk?
>
>
> That's not a reduced test. You need to remove dependencies to library
> facilities.
>

I replaced the dependency to VERIFY and used a own macro,
and verified, that the test still produce the error.

It is IMHO not worth to invest more time than this in a test
for an already obvious bug-fix.


Bernd.

port contrib/download_prerequisites script to macOS

[Damian Rouson]

All,

The attached patch modifies the contrib/download_prerequisites script to work 
on macOS. 
The revised script detects the operating system and adjusts the shasum and md5 
commands 
to their expected name and arguments on macOS.  The revised script also uses 
curl if 
wget is not present.  macOS ships with curl but not wget.

Tested on macOS and Lubuntu and Fedora Linux distributions. 

Ok for trunk?

Damian


2017-04-05  Damian Rouson  

        * download_prerequisites (md5_check): New function emulates Linux
        'md5 --check' on macOS.  Modified script for macOS compatibility.



macOS-download_prerequisites.diff
Description: Binary data

Re: [PATCH] Fix a C++ crash with may_alias type attribute

[Ville Voutilainen]

On 5 April 2017 at 00:29, Bernd Edlinger  wrote:
>> The new test doesn't really belong in the libstdc++, does it?
>>
>> If this is a bug in the front-end then a reduced version of the test
>> belongs in the g++ testsuite.
>>
>
> Yes, I moved the test case to the g++.dg/lto branch, where it
> fortunately also works (I forgot to mention that the crash only
> happened with -flto).
>
> Is it Ok for trunk?


That's not a reduced test. You need to remove dependencies to library
facilities.

[PATCH] PR target/79890: S/390: Fix crash.

[Dominik Vogt]

The attached patch fixes PR 79890.  Bootstrapped and regression
tested on s390x biarch and s390.

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt
IBM Germany
gcc/ChangeLog-pr79890

PR target/79890
* config/s390/s390.c (s390_register_info_gprtofpr): Return if
call_eh_return is true.
gcc/testsuite/ChangeLog-pr79890

PR target/79890
* gcc.target/s390/pr79890.c: New test case.
>From 99062b1d7476132c996966f15c11c3090e0dcd2a Mon Sep 17 00:00:00 2001
From: Dominik Vogt 
Date: Tue, 4 Apr 2017 12:31:43 +0100
Subject: [PATCH] PR target/79890: S/390: Fix crash.

---
 gcc/config/s390/s390.c  |  6 ++
 gcc/testsuite/gcc.target/s390/pr79890.c | 11 +++
 2 files changed, 17 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/s390/pr79890.c

diff --git a/gcc/config/s390/s390.c b/gcc/config/s390/s390.c
index 51b3d46..2cb8947 100644
--- a/gcc/config/s390/s390.c
+++ b/gcc/config/s390/s390.c
@@ -9512,6 +9512,12 @@ s390_register_info_gprtofpr ()
   if (!TARGET_Z10 || !TARGET_HARD_FLOAT || !crtl->is_leaf)
 return;
 
+  /* builtin_eh_return needs to be able to modify the return address
+ on the stack.  It could also adjust the FPR save slot instead but
+ is it worth the trouble?!  */
+  if (crtl->calls_eh_return)
+return;
+
   for (i = 15; i >= 6; i--)
 {
   if (cfun_gpr_save_slot (i) == SAVE_SLOT_NONE)
diff --git a/gcc/testsuite/gcc.target/s390/pr79890.c 
b/gcc/testsuite/gcc.target/s390/pr79890.c
new file mode 100644
index 000..e9894df
--- /dev/null
+++ b/gcc/testsuite/gcc.target/s390/pr79890.c
@@ -0,0 +1,11 @@
+/* { dg-do compile } */
+/* { dg-options "-Wno-pedantic" } */
+
+void bar (void);
+
+void
+foo (int x)
+{
+  __builtin_unwind_init ();
+  __builtin_eh_return (x, bar);
+}
-- 
2.3.0

Re: [PATCH] Fix a C++ crash with may_alias type attribute

[Bernd Edlinger]

On 04/04/17 14:58, Jonathan Wakely wrote:
> On 04/04/17 12:39 +, Bernd Edlinger wrote:
>> Hi,
>>
>> I noticed that the already created reference and pointer types
>> are left in an inconsistent state if the may_alias attribute
>> is added to a class, in some cases.
>>
>> The attached patch fixes this by adding another loop over
>> all type variants of each pointer and reference type.
>>
>> The new test case 20_util/any/assign/2a.cc is just a
>> clone of 20_util/any/assign/2.cc with the may_alias
>> attribute at the right place.
>
> The new test doesn't really belong in the libstdc++, does it?
>
> If this is a bug in the front-end then a reduced version of the test
> belongs in the g++ testsuite.
>

Yes, I moved the test case to the g++.dg/lto branch, where it
fortunately also works (I forgot to mention that the crash only
happened with -flto).

Is it Ok for trunk?


Thanks
Bernd.
gcc/cp
2017-04-04  Bernd Edlinger  

PR c++/80287
* class.c (fixup_may_alias): Fix all type variants.

gcc/testsuite
2017-04-04  Bernd Edlinger  

PR c++/80287
* g++.dg/lto/pr80287_0.C: New test.


Index: gcc/cp/class.c
===
--- gcc/cp/class.c	(revision 246605)
+++ gcc/cp/class.c	(working copy)
@@ -2060,12 +2060,14 @@ fixup_type_variants (tree t)
 static void
 fixup_may_alias (tree klass)
 {
-  tree t;
+  tree t, v;
 
   for (t = TYPE_POINTER_TO (klass); t; t = TYPE_NEXT_PTR_TO (t))
-TYPE_REF_CAN_ALIAS_ALL (t) = true;
+for (v = TYPE_MAIN_VARIANT (t); v; v = TYPE_NEXT_VARIANT (v))
+  TYPE_REF_CAN_ALIAS_ALL (v) = true;
   for (t = TYPE_REFERENCE_TO (klass); t; t = TYPE_NEXT_REF_TO (t))
-TYPE_REF_CAN_ALIAS_ALL (t) = true;
+for (v = TYPE_MAIN_VARIANT (t); v; v = TYPE_NEXT_VARIANT (v))
+  TYPE_REF_CAN_ALIAS_ALL (v) = true;
 }
 
 /* Early variant fixups: we apply attributes at the beginning of the class
Index: gcc/testsuite/g++.dg/lto/pr80287_0.C
===
--- gcc/testsuite/g++.dg/lto/pr80287_0.C	(revision 0)
+++ gcc/testsuite/g++.dg/lto/pr80287_0.C	(working copy)
@@ -0,0 +1,92 @@
+// { dg-lto-options { "-std=gnu++17" } }
+// { dg-lto-do run }
+
+// Copyright (C) 2014-2017 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3.  If not see
+// .
+
+#include 
+#define VERIFY(x) if (!(x)) __builtin_abort()
+
+using std::any;
+using std::any_cast;
+
+bool moved = false;
+bool copied = false;
+
+struct X
+{
+  X() = default;
+  X(const X&) { copied = true; }
+  X(X&& x) { moved = true; }
+};
+
+struct X2
+{
+  X2() = default;
+  X2(const X2&) { copied = true; }
+  X2(X2&& x) noexcept { moved = true; }
+}__attribute((may_alias));
+
+void test01()
+{
+  moved = false;
+  X x;
+  any a1;
+  a1 = x;
+  VERIFY(moved == false);
+  any a2;
+  copied = false;
+  a2 = std::move(x);
+  VERIFY(moved == true);
+  VERIFY(copied == false);
+}
+
+void test02()
+{
+  moved = false;
+  X x;
+  any a1;
+  a1 = x;
+  VERIFY(moved == false);
+  any a2;
+  copied = false;
+  a2 = std::move(a1);
+  VERIFY(moved == false);
+  VERIFY(copied == false);
+}
+
+void test03()
+{
+  moved = false;
+  X2 x;
+  any a1;
+  a1 = x;
+  VERIFY(copied && moved);
+  any a2;
+  moved = false;
+  copied = false;
+  a2 = std::move(a1);
+  VERIFY(moved == true);
+  VERIFY(copied == false);
+}
+
+int main()
+{
+  test01();
+  test02();
+  test03();
+}

Re: [PR 79905] ICE with vector_type

[Bill Schmidt]

> On Apr 4, 2017, at 1:02 PM, Nathan Sidwell  wrote:
> 
> On 04/04/2017 01:40 PM, Bill Schmidt wrote:
>> At first blush, the POC patch breaks every test that uses -flto.  I'll see 
>> if I can dig deeper after a bit,
>> in case this doesn't make the problem obvious.
> 
> Try this.

Thanks, Nathan, that regstraps cleanly on powerpc64le and fixes the test case 
in the PR.

Bill

> 
> nathan
> 
> -- 
> Nathan Sidwell
> <79905-3.diff>

Re: Fix MIPS builds with current trunk

[Jeff Law]

On 04/04/2017 01:15 PM, Matthew Fortune wrote:

Jeff Law  writes:

All the MIPS compilers will fail to build using the trunk due to a
couple minor uninitialized memory issues.

First in mips_multi_add we add an uninitialized mips_multi_member object
to the mips_multi_members vec.  It's easy enough to just memset the new
member.

Second in mips_expand_vec_perm_const the tail of the orig_perm may be
uninitialized if the number of elements in the target object is smaller
than MAX_VECT_LEN.  This is also trivial to fix by explicitly clearing
the tail of the array.

Tested by verifying the MIPS targets in config-list.mk will build using
a trunk compiler again.

Installed on the trunk.


Thanks Jeff, and apologies for missing the report.
No worries at all.  I stumbled over it a month or so ago, put the hacks 
in a local tree and largely forgot about them until someone else piped 
in with the same failure.


jeff

Re: [PATCH] Avoid weird -Wpsabi warnings from NRV (PR target/80310)

[Richard Biener]

On April 4, 2017 9:29:19 PM GMT+02:00, Jakub Jelinek  wrote:
>Hi!
>
>When I've implemented vector -fsanitize=signed-integer-overflow,
>we've started to emit weirdo warnings on e.g. the following testcase.
>
>There is really no call with return value that changes ABI
>based on ISA options, there is just an internal fn call that is
>expanded
>completely inline (UBSAN_CHECK_*), but as the NRV pass calls
>aggregate_value_p even on those internal functions, we get the warning.
>
>The following patch keeps doing that for internal functions that have
>corresponding optab, those typically have a library counterpart, but
>for others that really don't have one and are always expanded inline
>avoids calling aggregate_value_p, we really can't NRV optimize those
>internal fns anyway.
>
>Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 

OK.

Richard.

>2017-04-04  Jakub Jelinek  
>
>   PR target/80310
>   * tree-nvr.c: Include internal-fn.h.
>   (pass_return_slot::execute): Ignore internal calls without
>   direct optab.
>
>   * c-c++-common/ubsan/pr80310.c: New test.
>
>--- gcc/tree-nrv.c.jj  2017-01-01 12:45:39.0 +0100
>+++ gcc/tree-nrv.c 2017-04-04 15:51:54.864211786 +0200
>@@ -28,6 +28,7 @@ along with GCC; see the file COPYING3.
> #include "tree-pretty-print.h"
> #include "gimple-iterator.h"
> #include "gimple-walk.h"
>+#include "internal-fn.h"
> 
> /* This file implements return value optimizations for functions which
>return aggregate types.
>@@ -377,6 +378,12 @@ pass_return_slot::execute (function *fun
> if (stmt
> && gimple_call_lhs (stmt)
> && !gimple_call_return_slot_opt_p (stmt)
>+/* Ignore internal functions without direct optabs,
>+   those are expanded specially and aggregate_value_p
>+   on their result might result in undesirable warnings
>+   with some backends.  */
>+&& (!gimple_call_internal_p (stmt)
>+|| direct_internal_fn_p (gimple_call_internal_fn (stmt)))
> && aggregate_value_p (TREE_TYPE (gimple_call_lhs (stmt)),
>   gimple_call_fndecl (stmt)))
>   {
>--- gcc/testsuite/c-c++-common/ubsan/pr80310.c.jj  2017-04-04
>16:13:35.108407423 +0200
>+++ gcc/testsuite/c-c++-common/ubsan/pr80310.c 2017-04-04
>16:12:24.0 +0200
>@@ -0,0 +1,12 @@
>+/* PR target/80310 */
>+/* { dg-do compile } */
>+/* { dg-options "-O2 -fsanitize=signed-integer-overflow" } */
>+/* { dg-additional-options "-mno-avx" { target i?86-*-* x86_64-*-* } }
>*/
>+
>+typedef int V __attribute__((vector_size (32)));
>+
>+void
>+foo (V *a, V *b, V *c)
>+{
>+  *a = *b + *c;   /* { dg-bogus "AVX vector return without AVX 
>enabled
>changes the ABI" "" { target i?86-*-* x86_64-*-* } } */
>+}
>
>   Jakub

[PATCH] PR libstdc++/80316 make promise::set_value throw no_state error

[Jonathan Wakely]

We got a bug report from a customer pointing out that calling
promise::set_value on a moved-from promise crashes instead of throwing
an exception with error code future_errc::no_state.

This fixes it, by moving the _S_check calls to *before* we deference
the pointer that the calls check!

This passes all tests, including the more comprehensive ones I've
added as part of this commit, but I think it can wait for stage 1
anyway. We've been shipping this bug for a couple of releases already.

PR libstdc++/80316
* include/std/future (_State_baseV2::_Setter::operator()): Remove
_S_check calls that are done after the pointer to the shared state is
already dereferenced.
(_State_baseV2::_Setter<_Res, void>): Define specialization for void
as partial specialization so it can be defined within the definition
of _State_baseV2.
(_State_baseV2::__setter): Call _S_check.
(_State_baseV2::__setter(promise*)): Add overload for use by
promise::set_value and promise::set_value_at_thread_exit.
(promise, promise, promise): Make _State a friend.
(_State_baseV2::_Setter): Remove explicit specialization.
(promise::set_value, promise::set_value_at_thread_exit):
Use new __setter overload.
* testsuite/30_threads/promise/members/at_thread_exit2.cc: New test.
* testsuite/30_threads/promise/members/set_exception.cc: Test
promise and promise specializations.
* testsuite/30_threads/promise/members/set_exception2.cc: Likewise.
Test for no_state error condition.
* testsuite/30_threads/promise/members/set_value2.cc: Likewise.


commit 83c1e45d0759dd095c7b35d67fb5ba98dc7bf909
Author: Jonathan Wakely 
Date:   Tue Apr 4 19:48:33 2017 +0100

PR libstdc++/80316 make promise::set_value throw no_state error

PR libstdc++/80316
* include/std/future (_State_baseV2::_Setter::operator()): Remove
_S_check calls that are done after the pointer to the shared state is
already dereferenced.
(_State_baseV2::_Setter<_Res, void>): Define specialization for void
as partial specialization so it can be defined within the definition
of _State_baseV2.
(_State_baseV2::__setter): Call _S_check.
(_State_baseV2::__setter(promise*)): Add overload for use by
promise::set_value and promise::set_value_at_thread_exit.
(promise, promise, promise): Make _State a friend.
(_State_baseV2::_Setter): Remove explicit specialization.
(promise::set_value, promise::set_value_at_thread_exit):
Use new __setter overload.
* testsuite/30_threads/promise/members/at_thread_exit2.cc: New test.
* testsuite/30_threads/promise/members/set_exception.cc: Test
promise and promise specializations.
* testsuite/30_threads/promise/members/set_exception2.cc: Likewise.
Test for no_state error condition.
* testsuite/30_threads/promise/members/set_value2.cc: Likewise.

diff --git a/libstdc++-v3/include/std/future b/libstdc++-v3/include/std/future
index cb53561..73d5a60 100644
--- a/libstdc++-v3/include/std/future
+++ b/libstdc++-v3/include/std/future
@@ -471,7 +471,6 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
  // Used by std::promise to copy construct the result.
   typename promise<_Res>::_Ptr_type operator()() const
   {
-_State_baseV2::_S_check(_M_promise->_M_future);
 _M_promise->_M_storage->_M_set(*_M_arg);
 return std::move(_M_promise->_M_storage);
   }
@@ -486,7 +485,6 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
  // Used by std::promise to move construct the result.
   typename promise<_Res>::_Ptr_type operator()() const
   {
-_State_baseV2::_S_check(_M_promise->_M_future);
 _M_promise->_M_storage->_M_set(std::move(*_M_arg));
 return std::move(_M_promise->_M_storage);
   }
@@ -494,6 +492,18 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   _Res* _M_arg;
 };
 
+  // set void
+  template
+   struct _Setter<_Res, void>
+   {
+ static_assert(is_void<_Res>::value, "Only used for promise");
+
+ typename promise<_Res>::_Ptr_type operator()() const
+ { return std::move(_M_promise->_M_storage); }
+
+ promise<_Res>*_M_promise;
+   };
+
   struct __exception_ptr_tag { };
 
   // set exceptions
@@ -503,7 +513,6 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
  // Used by std::promise to store an exception as the result.
   typename promise<_Res>::_Ptr_type operator()() const
   {
-_State_baseV2::_S_check(_M_promise->_M_future);
 _M_promise->_M_storage->_M_error = *_M_ex;
 return std::move(_M_promise->_M_storage);
   }
@@ -516,6 +525,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION

libgo patch committed: make time test more robust

[Ian Lance Taylor]

This patch to libgo backports a change from Go tip to make the time
test ParseInLocation more robust.  This lets the test pass on systems
that have updated their timezone database to 2017a or later.  This
fixes GCC PR 80302.  Bootstrapped and ran Go time test on
x86_64-pc-linux-gnu.  Committed to mainline.

Ian
Index: libgo/go/time/format_test.go
===
--- libgo/go/time/format_test.go(revision 245745)
+++ libgo/go/time/format_test.go(working copy)
@@ -245,27 +245,45 @@ func TestParseDayOutOfRange(t *testing.T
}
 }
 
+// TestParseInLocation checks that the Parse and ParseInLocation
+// functions do not get confused by the fact that AST (Arabia Standard
+// Time) and AST (Atlantic Standard Time) are different time zones,
+// even though they have the same abbreviation.
+//
+// ICANN has been slowly phasing out invented abbreviation in favor of
+// numeric time zones (for example, the Asia/Baghdad time zone
+// abbreviation got changed from AST to +03 in the 2017a tzdata
+// release); but we still want to make sure that the time package does
+// not get confused on systems with slightly older tzdata packages.
 func TestParseInLocation(t *testing.T) {
-   // Check that Parse (and ParseInLocation) understand that
-   // Feb 01 AST (Arabia Standard Time) and Feb 01 AST (Atlantic Standard 
Time)
-   // are in different time zones even though both are called AST
 
baghdad, err := LoadLocation("Asia/Baghdad")
if err != nil {
t.Fatal(err)
}
 
-   t1, err := ParseInLocation("Jan 02 2006 MST", "Feb 01 2013 AST", 
baghdad)
+   var t1, t2 Time
+
+   t1, err = ParseInLocation("Jan 02 2006 MST", "Feb 01 2013 AST", baghdad)
if err != nil {
t.Fatal(err)
}
-   t2 := Date(2013, February, 1, 00, 00, 00, 0, baghdad)
-   if t1 != t2 {
-   t.Fatalf("ParseInLocation(Feb 01 2013 AST, Baghdad) = %v, want 
%v", t1, t2)
-   }
+
_, offset := t1.Zone()
-   if offset != 3*60*60 {
-   t.Fatalf("ParseInLocation(Feb 01 2013 AST, Baghdad).Zone = _, 
%d, want _, %d", offset, 3*60*60)
+
+   // A zero offset means that ParseInLocation did not recognize the
+   // 'AST' abbreviation as matching the current location (Baghdad,
+   // where we'd expect a +03 hrs offset); likely because we're using
+   // a recent tzdata release (2017a or newer).
+   // If it happens, skip the Baghdad test.
+   if offset != 0 {
+   t2 = Date(2013, February, 1, 00, 00, 00, 0, baghdad)
+   if t1 != t2 {
+   t.Fatalf("ParseInLocation(Feb 01 2013 AST, Baghdad) = 
%v, want %v", t1, t2)
+   }
+   if offset != 3*60*60 {
+   t.Fatalf("ParseInLocation(Feb 01 2013 AST, 
Baghdad).Zone = _, %d, want _, %d", offset, 3*60*60)
+   }
}
 
blancSablon, err := LoadLocation("America/Blanc-Sablon")
@@ -273,6 +291,9 @@ func TestParseInLocation(t *testing.T) {
t.Fatal(err)
}
 
+   // In this case 'AST' means 'Atlantic Standard Time', and we
+   // expect the abbreviation to correctly match the american
+   // location.
t1, err = ParseInLocation("Jan 02 2006 MST", "Feb 01 2013 AST", 
blancSablon)
if err != nil {
t.Fatal(err)

[PATCH] Avoid weird -Wpsabi warnings from NRV (PR target/80310)

[Jakub Jelinek]

Hi!

When I've implemented vector -fsanitize=signed-integer-overflow,
we've started to emit weirdo warnings on e.g. the following testcase.

There is really no call with return value that changes ABI
based on ISA options, there is just an internal fn call that is expanded
completely inline (UBSAN_CHECK_*), but as the NRV pass calls
aggregate_value_p even on those internal functions, we get the warning.

The following patch keeps doing that for internal functions that have
corresponding optab, those typically have a library counterpart, but
for others that really don't have one and are always expanded inline
avoids calling aggregate_value_p, we really can't NRV optimize those
internal fns anyway.

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

2017-04-04  Jakub Jelinek  

PR target/80310
* tree-nvr.c: Include internal-fn.h.
(pass_return_slot::execute): Ignore internal calls without
direct optab.

* c-c++-common/ubsan/pr80310.c: New test.

--- gcc/tree-nrv.c.jj   2017-01-01 12:45:39.0 +0100
+++ gcc/tree-nrv.c  2017-04-04 15:51:54.864211786 +0200
@@ -28,6 +28,7 @@ along with GCC; see the file COPYING3.
 #include "tree-pretty-print.h"
 #include "gimple-iterator.h"
 #include "gimple-walk.h"
+#include "internal-fn.h"
 
 /* This file implements return value optimizations for functions which
return aggregate types.
@@ -377,6 +378,12 @@ pass_return_slot::execute (function *fun
  if (stmt
  && gimple_call_lhs (stmt)
  && !gimple_call_return_slot_opt_p (stmt)
+ /* Ignore internal functions without direct optabs,
+those are expanded specially and aggregate_value_p
+on their result might result in undesirable warnings
+with some backends.  */
+ && (!gimple_call_internal_p (stmt)
+ || direct_internal_fn_p (gimple_call_internal_fn (stmt)))
  && aggregate_value_p (TREE_TYPE (gimple_call_lhs (stmt)),
gimple_call_fndecl (stmt)))
{
--- gcc/testsuite/c-c++-common/ubsan/pr80310.c.jj   2017-04-04 
16:13:35.108407423 +0200
+++ gcc/testsuite/c-c++-common/ubsan/pr80310.c  2017-04-04 16:12:24.0 
+0200
@@ -0,0 +1,12 @@
+/* PR target/80310 */
+/* { dg-do compile } */
+/* { dg-options "-O2 -fsanitize=signed-integer-overflow" } */
+/* { dg-additional-options "-mno-avx" { target i?86-*-* x86_64-*-* } } */
+
+typedef int V __attribute__((vector_size (32)));
+
+void
+foo (V *a, V *b, V *c)
+{
+  *a = *b + *c;/* { dg-bogus "AVX vector return without AVX 
enabled changes the ABI" "" { target i?86-*-* x86_64-*-* } } */
+}

Jakub

[PATCH] Don't error about x86 return value in SSE reg (or x86 reg) or argument in SSE reg too early (PR target/80298)

[Jakub Jelinek]

Hi!

aggregate_value_p is called often very early during compilation, e.g.
from allocate_function or during gimplification of a call with lhs.
The problem with that is e.g. that on x86_64 -m64 -mno-sse we can't
include , because the always_inline inline functions
in mmx and 3dnow intrinsic headers return __m64 or take __m64 as arguments
and that in the 64-bit ABI is in SSE register.

The following patch makes sure we diagnose this only later (e.g. when
expanding a function to RTL or when expanding calls to other functions),
which means we don't diagnose e.g. inline functions that got successfully
inlined (because then there is really no function return in SSE or x87
reg) or e.g. for builtin calls if they are emitted inline rather than
as a library call (again, I think that is desirable).
I had to tweak a few tests because the reported line changed slightly,
and in the last test add -fno-builtin-fminl, because otherwise fminl
is expanded inline and again there is no call left with the problem.

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

2017-04-04  Jakub Jelinek  

PR target/80298
* config/i386/i386.c (construct_container): Postpone errors about
return values or arguments in SSE or x87 registers with those
disabled until inlining is done.

* gcc.target/i386/pr80298-1.c: New test.
* gcc.target/i386/pr80298-2.c: New test.
* gcc.target/i386/pr57655.c: Adjust expected diagnostic line.
* gcc.target/i386/pr59794-6.c: Likewise.
* gcc.target/i386/pr70738-1.c: Likewise.  Add -Wno-psabi to
dg-options.
* gcc.target/i386/pr68473-1.c: Add -fno-builtin-fminl to dg-options.

--- gcc/config/i386/i386.c.jj   2017-04-04 19:51:33.661684106 +0200
+++ gcc/config/i386/i386.c  2017-04-04 20:45:42.573366752 +0200
@@ -9330,7 +9330,12 @@ construct_container (machine_mode mode,
  some less clueful developer tries to use floating-point anyway.  */
   if (needed_sseregs && !TARGET_SSE)
 {
-  if (in_return)
+  /* Don't diagnose anything until after inlining, we might have
+functions with such arguments that are just always inlined
+and don't really need SSE returns or arguments.  */
+  if (symtab->state < IPA_SSA_AFTER_INLINING)
+;
+  else if (in_return)
{
  if (!issued_sse_ret_error)
{
@@ -9354,7 +9359,11 @@ construct_container (machine_mode mode,
  || regclass[i] == X86_64_X87UP_CLASS
  || regclass[i] == X86_64_COMPLEX_X87_CLASS)
{
- if (!issued_x87_ret_error)
+ /* Don't diagnose anything until after inlining, we might have
+functions with such arguments that are just always inlined
+and don't really need x87 returns.  */
+ if (symtab->state >= IPA_SSA_AFTER_INLINING
+ && !issued_x87_ret_error)
{
  error ("x87 register return with x87 disabled");
  issued_x87_ret_error = true;
--- gcc/testsuite/gcc.target/i386/pr80298-1.c.jj2017-04-04 
20:45:42.574366739 +0200
+++ gcc/testsuite/gcc.target/i386/pr80298-1.c   2017-04-04 20:45:42.574366739 
+0200
@@ -0,0 +1,7 @@
+/* PR target/80298 */
+/* { dg-do compile } */
+/* { dg-options "-mno-sse -mmmx" } */
+
+#include 
+
+int i;
--- gcc/testsuite/gcc.target/i386/pr80298-2.c.jj2017-04-04 
20:45:42.574366739 +0200
+++ gcc/testsuite/gcc.target/i386/pr80298-2.c   2017-04-04 20:45:42.574366739 
+0200
@@ -0,0 +1,7 @@
+/* PR target/80298 */
+/* { dg-do compile } */
+/* { dg-options "-mno-sse -mmmx -O2" } */
+
+#include 
+
+int i;
--- gcc/testsuite/gcc.target/i386/pr57655.c.jj  2016-05-22 12:20:31.0 
+0200
+++ gcc/testsuite/gcc.target/i386/pr57655.c 2017-04-04 20:48:31.867154730 
+0200
@@ -1,7 +1,7 @@
 /* { dg-do compile } */
 /* { dg-options "-mavx -mvzeroupper -mno-fp-ret-in-387" }
 
-/* { dg-error "x87 register return with x87 disabled" "" { target { ! ia32 } } 
8 } */
+/* { dg-error "x87 register return with x87 disabled" "" { target { ! ia32 } } 
7 } */
 
 long double
 foo (long double x)
--- gcc/testsuite/gcc.target/i386/pr59794-6.c.jj2014-01-15 
08:11:25.0 +0100
+++ gcc/testsuite/gcc.target/i386/pr59794-6.c   2017-04-04 20:49:21.820502031 
+0200
@@ -8,7 +8,7 @@ typedef int __v4si __attribute__ ((__vec
 extern __v4si x;
 
 __v4si
-foo (void)
-{ /* { dg-error "SSE register return with SSE disabled" } */
+foo (void) /* { dg-error "SSE register return with SSE disabled" } */
+{
   return x;
 }
--- gcc/testsuite/gcc.target/i386/pr70738-1.c.jj2016-05-26 
10:37:56.0 +0200
+++ gcc/testsuite/gcc.target/i386/pr70738-1.c   2017-04-04 20:54:32.750439367 
+0200
@@ -1,9 +1,9 @@
 /* { dg-do compile { target { ! ia32 } } } */
-/* { dg-options "-msse2 -mgeneral-regs-only" } */
+/* { dg-options "-msse2 -mgeneral-regs-only -Wno-psabi" } */
 
 typedef int int32x2_t __attribute__ ((__vector_size__ ((8;
 
-int32x2_t test 

[committed] FIx a tree sharing issue in generic-match.c (PR c++/80297)

[Jakub Jelinek]

Hi!

While generic tree sharing is usually harmless, because we unshare
everything before gimplification, on the following testcase a match.pd
pattern that uses @1 twice introduces tree sharing during the C
gimplification langhook, so after everything has been unshared.

The following patch fixes it by unsharing uses of captures except for the
last use.  Bootstrapped/regtested on x86_64-linux and i686-linux, acked
by Richard in the PR, committed to trunk.

2017-04-04  Jakub Jelinek  
Richard Biener  

PR c++/80297
* genmatch.c (capture::gen_transform): For GENERIC unshare_expr
captures used multiple times, except for the last use.
* generic-match-head.c: Include gimplify.h.

* g++.dg/torture/pr80297.C: New test.

--- gcc/genmatch.c.jj   2017-03-19 11:57:19.0 +0100
+++ gcc/genmatch.c  2017-04-04 13:23:15.053251358 +0200
@@ -2525,7 +2525,18 @@ capture::gen_transform (FILE *f, int ind
}
 }
 
-  fprintf_indent (f, indent, "%s = captures[%u];\n", dest, where);
+  /* If in GENERIC some capture is used multiple times, unshare it except
+ when emitting the last use.  */
+  if (!gimple
+  && cinfo->info.exists ()
+  && cinfo->info[cinfo->info[where].same_as].result_use_count > 1)
+{
+  fprintf_indent (f, indent, "%s = unshare_expr (captures[%u]);\n",
+ dest, where);
+  cinfo->info[cinfo->info[where].same_as].result_use_count--;
+}
+  else
+fprintf_indent (f, indent, "%s = captures[%u];\n", dest, where);
 
   /* ???  Stupid tcc_comparison GENERIC trees in COND_EXPRs.  Deal
  with substituting a capture of that.  */
--- gcc/generic-match-head.c.jj 2017-01-01 12:45:38.0 +0100
+++ gcc/generic-match-head.c2017-04-04 13:18:38.437884559 +0200
@@ -33,6 +33,7 @@ along with GCC; see the file COPYING3.
 #include "builtins.h"
 #include "dumpfile.h"
 #include "case-cfn-macros.h"
+#include "gimplify.h"
 
 
 /* Routine to determine if the types T1 and T2 are effectively
--- gcc/testsuite/g++.dg/torture/pr80297.C.jj   2017-04-04 13:47:45.254048537 
+0200
+++ gcc/testsuite/g++.dg/torture/pr80297.C  2017-04-04 13:47:29.0 
+0200
@@ -0,0 +1,12 @@
+// PR c++/80297
+// { dg-do compile }
+
+extern const unsigned long int b;
+extern const long long int c;
+
+int
+foo ()
+{
+  int a = 809 >> -(b & !c) + b - (long long)(b & !c);
+  return a;
+}

Jakub

RE: Fix MIPS builds with current trunk

[Matthew Fortune]

Jeff Law  writes:
> All the MIPS compilers will fail to build using the trunk due to a
> couple minor uninitialized memory issues.
> 
> First in mips_multi_add we add an uninitialized mips_multi_member object
> to the mips_multi_members vec.  It's easy enough to just memset the new
> member.
> 
> Second in mips_expand_vec_perm_const the tail of the orig_perm may be
> uninitialized if the number of elements in the target object is smaller
> than MAX_VECT_LEN.  This is also trivial to fix by explicitly clearing
> the tail of the array.
> 
> Tested by verifying the MIPS targets in config-list.mk will build using
> a trunk compiler again.
> 
> Installed on the trunk.

Thanks Jeff, and apologies for missing the report.

Matthew

Re: New prerequisites to support multi image COARRAY in gfortran

[Jerry DeLisle]

On 04/04/2017 10:44 AM, FX wrote:
>> We choose mpich as a default only because it is very stable.
> 
> Why are why tying ourselves to one MPI implementation?
> 
> FX
> 

Not tying ourselves at all. This just gives users who install gcc manually with
the ./configure process a default to use and only if they are using the download
prerequisites script which is optional. Distributions can still provide multiple
choices with package managers.

The final tie is at link time where a user may specify any compatible library
they choose. We do have a base of users who do not use package managers by the
way. So the goal is a minimal installation of a fully functional Fortran.

Jerry

Re: New prerequisites to support multi image COARRAY in gfortran

[Damian Rouson]

 



On April 4, 2017 at 9:48:23 AM, Jerry DeLisle 
(jvdeli...@charter.net(mailto:jvdeli...@charter.net)) wrote:

> Gerald, (or who does this)  
>  
> Since shared memory parallel programming with Fortran is now a Standard 
> feature  
> of the language, we would like to support full parallelism through the use of 
>  
> mpich and OpenCorrays.  


Clarification: Fortran’s parallel programming model is agnostic about the 
memory architecture. The 2008 standard made Fortran the only widely used 
language with a parallel programming model that works in shared- or 
distributed-memory systems.  I’ve seen papers in which people have run coarray 
Fortran (CAF) on over 100,000 cores with impressive results.

As a side note, the draft 2015 standard makes Fortran also the only widely used 
language with support for fault tolerance, which makes Alessandro’s and Andre’s 
work on failed-image support truly exciting and I’m amazed that there already 
exists an MPI limitation with some support for what is needed to support 
failed-image detection. 

Damian

Re: New prerequisites to support multi image COARRAY in gfortran

[Damian Rouson]

 
Resending as plain text (although now I realize my reply is at least partially 
redundant since reading Andre’s email):

On April 4, 2017 at 10:44:09 AM, FX 
(fxcoud...@gmail.com(mailto:fxcoud...@gmail.com)) wrote:

> > We choose mpich as a default only because it is very stable.
>  
> Why are why tying ourselves to one MPI implementation?
>  


Jerry’s request is just to put an MPICH tar ball on the GCC ftp server as a 
default.  When we modify “configure,” there will be a --with-mpi option that 
enables users to choose their own MPI implementation. 

Damian

Re: [PR 79905] ICE with vector_type

[Nathan Sidwell]

On 04/04/2017 01:40 PM, Bill Schmidt wrote:

At first blush, the POC patch breaks every test that uses -flto.  I'll see if I 
can dig deeper after a bit,
in case this doesn't make the problem obvious.


Try this.

nathan

--
Nathan Sidwell
Index: c-family/c-common.c
===
--- c-family/c-common.c	(revision 246647)
+++ c-family/c-common.c	(working copy)
@@ -7465,7 +7465,8 @@ set_underlying_type (tree x)
 {
   if (x == error_mark_node)
 return;
-  if (DECL_IS_BUILTIN (x) && TREE_CODE (TREE_TYPE (x)) != ARRAY_TYPE)
+  if (DECL_IS_BUILTIN (x) && TYPE_NAME (TREE_TYPE (x)) != error_mark_node
+  && TREE_CODE (TREE_TYPE (x)) != ARRAY_TYPE)
 {
   if (TYPE_NAME (TREE_TYPE (x)) == 0)
 	TYPE_NAME (TREE_TYPE (x)) = x;
Index: config/rs6000/rs6000.c
===
--- config/rs6000/rs6000.c	(revision 246647)
+++ config/rs6000/rs6000.c	(working copy)
@@ -17459,9 +17459,28 @@ rs6000_init_builtins (void)
   tdecl = add_builtin_type ("__vector unsigned int", unsigned_V4SI_type_node);
   TYPE_NAME (unsigned_V4SI_type_node) = tdecl;
 
-  tdecl = add_builtin_type ("__vector signed int", V4SI_type_node);
-  TYPE_NAME (V4SI_type_node) = tdecl;
+  { // Ugly POC hack
+TYPE_NAME (V4SI_type_node) = error_mark_node; // placeholder
+tdecl = add_builtin_type ("__vector signed int", V4SI_type_node);
+TYPE_NAME (V4SI_type_node) = NULL_TREE; // restore
 
+if (tdecl) 
+  {
+	// Ew, change the underlying type
+#if 0
+	DECL_ORIGINAL_TYPE (tdecl) = V4SI_type_node;
+	tree clone = build_variant_type_copy (V4SI_type_node);
+	TYPE_STUB_DECL (clone) = TYPE_STUB_DECL (V4SI_type_node);
+	TYPE_NAME (clone) = tdecl;
+
+	TREE_USED (clone) = 1;
+	TREE_TYPE (tdecl) = clone;
+#endif
+	TREE_USED (TREE_TYPE (tdecl)) = true;
+	V4SI_type_node = TREE_TYPE (tdecl);
+  }
+  }
+  
   tdecl = add_builtin_type ("__vector __bool int", bool_V4SI_type_node);
   TYPE_NAME (bool_V4SI_type_node) = tdecl;
 

Re: New prerequisites to support multi image COARRAY in gfortran

[Andre Vehreschild]

Hi FX,

we don't really do. You can use other MPI implementation as well, albeit not all
features are implemented in all the others. For failed images support we needed
the fault tolerance support for MPI, which I see only in mpich from 3.2 on. The
other MPI implementations publicy available do not support ft at the moment. So
as soon as they do in their stable versions, we might give the user more choice.

- Andre

On Tue, 4 Apr 2017 19:44:06 +0200
FX  wrote:

> > We choose mpich as a default only because it is very stable.  
> 
> Why are why tying ourselves to one MPI implementation?
> 
> FX


-- 
Andre Vehreschild * Email: vehre ad gmx dot de 

Re: New prerequisites to support multi image COARRAY in gfortran

[FX]

> We choose mpich as a default only because it is very stable.

Why are why tying ourselves to one MPI implementation?

FX

Re: [RFC]: Fix Ada boostrap failure on S/390 with -mzarch

[Eric Botcazou]

> This worked as well. I've committed the following patch:
> 
> gcc/ada/ChangeLog:
> 
> 2017-04-04  Andreas Krebbel  
> 
>   * system-linux-s390.ads: Use Long_Integer'Size to define
>   Memory_Size.

Thanks!

-- 
Eric Botcazou

Re: [PR 79905] ICE with vector_type

[Bill Schmidt]

At first blush, the POC patch breaks every test that uses -flto.  I'll see if I 
can dig deeper after a bit,
in case this doesn't make the problem obvious.

Thanks,
Bill

> On Apr 4, 2017, at 9:02 AM, Nathan Sidwell  wrote:
> 
> On 04/04/2017 09:57 AM, Bill Schmidt wrote:
>> I'll try the POC patch in a bit (kind of ugly as we have to replicate this 
>> for a whole bunch of types, I guess).
> 
> thanks.  Yup, all rs6000's builtins.  Wrapping it all in a
> tree my_builtin_vector (char const *name, tree elt, unsigned num);
> helper would probably make rs6000.c's initing cleaner?
> 
> 
>> Just FYI, I noticed this similar bug report came in today, not sure about 
>> the types:  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80309
> 
> thanks.  Probably not the same, but let's wait for a reduced testcase?
> 
> nathan
> 
> -- 
> Nathan Sidwell
> 

Re: [PATCH] On x86 allow if-conversion of more than one insn as long as there is at most one cmov (PR tree-optimization/79390)

[Jeff Law]

On 04/01/2017 06:20 AM, Jakub Jelinek wrote:

Hi!

As discussed in the PR, in the following testcase we don't if-convert
with the generic (and many other) tuning, because we default to
--param max-rtl-if-conversion-insns=1 in most of the tunings.
The problem we have is with multiple cmov instructions, but in the
testcase there is just one cmov and the other insn is turned into a SSE
max insn, which is fine.

This patch stops artificially lowering that param, and for one_if_conv_insn
tuning it instead rejects the if-conversion if the resulting sequence has
multiple cmov instructions.  The hook is passed if_info too, so it can
in the future do better heuristics based on predictability of the edges,
how far the uses of the cmov result are (I assume cmov major problem is
latency, right?) etc.

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

2017-04-01  Jakub Jelinek  

PR tree-optimization/79390
* target.h (struct noce_if_info): Declare.
* targhooks.h (default_noce_conversion_profitable_p): Declare.
* target.def (noce_conversion_profitable_p): New target hook.
* ifcvt.h (struct noce_if_info): New type, moved from ...
* ifcvt.c (struct noce_if_info): ... here.
(noce_conversion_profitable_p): Renamed to ...
(default_noce_conversion_profitable_p): ... this.  No longer
static nor inline.
(noce_try_store_flag_constants, noce_try_addcc,
noce_try_store_flag_mask, noce_try_cmove, noce_try_cmove_arith,
noce_convert_multiple_sets): Use targetm.noce_conversion_profitable_p
instead of noce_conversion_profitable_p.
* config/i386/i386.c: Include ifcvt.h.
(ix86_option_override_internal): Don't override
PARAM_MAX_RTL_IF_CONVERSION_INSNS default.
(ix86_noce_conversion_profitable_p): New function.
(TARGET_NOCE_CONVERSION_PROFITABLE_P): Redefine.
* config/i386/x86-tune.def (X86_TUNE_ONE_IF_CONV_INSN): Adjust comment.
* doc/tm.texi.in (TARGET_NOCE_CONVERSION_PROFITABLE_P): Add.
* doc/tm.texi: Regenerated.

* gcc.target/i386/pr79390.c: New test.
* gcc.dg/ifcvt-4.c: Use -mtune-ctrl=^one_if_conv_insn for i?86/x86_64.

OK.
jeff

Re: [PATCH, GCC/ARM, gcc-6-branch, ping2] Fix PR80082: LDRD erronously used for 64bit load on ARMv7-R

[Thomas Preudhomme]

Ping?

Best regards,

Thomas

On 30/03/17 11:46, Thomas Preudhomme wrote:

Ping?

Best regards,

Thomas

On 27/03/17 12:15, Thomas Preudhomme wrote:

Hi,

Currently GCC is happy to use LDRD to perform a 64bit load on ARMv7-R,
as shown by the testcase on this patch. However, LDRD is only atomic
when LPAE extensions is available, which they are not for ARMv7-R. This
commit solve the issue by introducing a new feature bit to distinguish
LPAE extensions instead of deducing it from div instruction
availability.

ChangeLog entries are as follow:

*** gcc/ChangeLog ***

2017-03-22  Thomas Preud'homme  

PR target/80082
* config/arm/arm-protos.h (FL_LPAE): Define macro.
(FL_FOR_ARCH7VE): Add FL_LPAE.
(arm_arch_lpae): Declare extern.
* config/arm/arm.c (arm_arch_lpae): Declare.
(arm_option_override): Define arm_arch_lpae.
* config/arm/arm.h (TARGET_HAVE_LPAE): Redefine in term of
arm_arch_lpae.

*** gcc/testsuite/ChangeLog ***

2017-03-22  Thomas Preud'homme  

PR target/80082
* gcc.target/arm/atomic_loaddi_10.c: New testcase.
* gcc.target/arm/atomic_loaddi_11.c: Likewise.


Testing: bootstrapped for -march=armv7ve and testsuite shows no regression.

Is this ok for gcc-6-branch?

Best regards,

Thomas
diff --git a/gcc/config/arm/arm-protos.h b/gcc/config/arm/arm-protos.h
index 0083673b161a49e19388c72d3a413aeb481dbfa3..dea00e42551c8295f7e83a72ddb81ae8e9c8e02d 100644
--- a/gcc/config/arm/arm-protos.h
+++ b/gcc/config/arm/arm-protos.h
@@ -360,7 +360,7 @@ extern bool arm_is_constant_pool_ref (rtx);
 #define FL_STRONG (1 << 8)	  /* StrongARM */
 #define FL_ARCH5E (1 << 9)/* DSP extensions to v5 */
 #define FL_XSCALE (1 << 10)	  /* XScale */
-/* spare	  (1 << 11)	*/
+#define FL_LPAE   (1 << 11)   /* ARMv7-A LPAE.  */
 #define FL_ARCH6  (1 << 12)   /* Architecture rel 6.  Adds
 	 media instructions.  */
 #define FL_VFPV2  (1 << 13)   /* Vector Floating Point V2.  */
@@ -412,7 +412,7 @@ extern bool arm_is_constant_pool_ref (rtx);
 #define FL_FOR_ARCH6M	(FL_FOR_ARCH6 & ~FL_NOTM)
 #define FL_FOR_ARCH7	((FL_FOR_ARCH6T2 & ~FL_NOTM) | FL_ARCH7)
 #define FL_FOR_ARCH7A	(FL_FOR_ARCH7 | FL_NOTM | FL_ARCH6K)
-#define FL_FOR_ARCH7VE	(FL_FOR_ARCH7A | FL_THUMB_DIV | FL_ARM_DIV)
+#define FL_FOR_ARCH7VE	(FL_FOR_ARCH7A | FL_THUMB_DIV | FL_ARM_DIV | FL_LPAE)
 #define FL_FOR_ARCH7R	(FL_FOR_ARCH7A | FL_THUMB_DIV)
 #define FL_FOR_ARCH7M	(FL_FOR_ARCH7 | FL_THUMB_DIV)
 #define FL_FOR_ARCH7EM  (FL_FOR_ARCH7M | FL_ARCH7EM)
@@ -608,6 +608,9 @@ extern int arm_arch_thumb2;
 extern int arm_arch_arm_hwdiv;
 extern int arm_arch_thumb_hwdiv;
 
+/* Nonzero if this chip supports the Large Physical Address Extension.  */
+extern int arm_arch_lpae;
+
 /* Nonzero if chip disallows volatile memory access in IT block.  */
 extern int arm_arch_no_volatile_ce;
 
diff --git a/gcc/config/arm/arm.h b/gcc/config/arm/arm.h
index ad123dde991a3e4c4b9563ee6ebb84981767988f..e93ff7f7d8583b653570cbb8605df5a10bfcc6f4 100644
--- a/gcc/config/arm/arm.h
+++ b/gcc/config/arm/arm.h
@@ -254,8 +254,7 @@ extern void (*arm_lang_output_object_attributes_hook)(void);
 #define TARGET_HAVE_LDREX((arm_arch6 && TARGET_ARM) || arm_arch7)
 
 /* Nonzero if this chip supports LPAE.  */
-#define TARGET_HAVE_LPAE		\
-  (arm_arch7 && ARM_FSET_HAS_CPU1 (insn_flags, FL_FOR_ARCH7VE))
+#define TARGET_HAVE_LPAE	(arm_arch_lpae)
 
 /* Nonzero if this chip supports ldrex{bh} and strex{bh}.  */
 #define TARGET_HAVE_LDREXBH ((arm_arch6k && TARGET_ARM) || arm_arch7)
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index c3c89b866355708d91dd2a3dab1e4b33f2215ff8..44bfb53a288f57fbc43a0bd146e193b768d939d2 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -859,6 +859,9 @@ int arm_arch_thumb2;
 int arm_arch_arm_hwdiv;
 int arm_arch_thumb_hwdiv;
 
+/* Nonzero if this chip supports the Large Physical Address Extension.  */
+int arm_arch_lpae;
+
 /* Nonzero if chip disallows volatile memory access in IT block.  */
 int arm_arch_no_volatile_ce;
 
@@ -3181,6 +3184,7 @@ arm_option_override (void)
   arm_arch_iwmmxt2 = ARM_FSET_HAS_CPU1 (insn_flags, FL_IWMMXT2);
   arm_arch_thumb_hwdiv = ARM_FSET_HAS_CPU1 (insn_flags, FL_THUMB_DIV);
   arm_arch_arm_hwdiv = ARM_FSET_HAS_CPU1 (insn_flags, FL_ARM_DIV);
+  arm_arch_lpae = ARM_FSET_HAS_CPU1 (insn_flags, FL_LPAE);
   arm_arch_no_volatile_ce = ARM_FSET_HAS_CPU1 (insn_flags, FL_NO_VOLATILE_CE);
   arm_tune_cortex_a9 = (arm_tune == cortexa9) != 0;
   arm_arch_crc = ARM_FSET_HAS_CPU1 (insn_flags, FL_CRC32);
diff --git a/gcc/testsuite/gcc.target/arm/atomic_loaddi_10.c b/gcc/testsuite/gcc.target/arm/atomic_loaddi_10.c
new file mode 100644
index ..ecc3d06d0c9f5966daa3ce7e2d52e09d14e0cbc8
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/atomic_loaddi_10.c
@@ -0,0 +1,15 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target arm_arch_v7ve_ok } */

Re: [PATCH, GCC/testsuite/ARM, stage4, ping] Compile atomic_loaddi_11 for Cortex-R5

[Thomas Preudhomme]

Hi,

gcc.target/arm/atomic_loaddi_11.c testcase contributed in r246365 does
not test the changed code since ARMv7-R does not have division
instructions in ARM state. This patch changes it to target Cortex-R5
processor instead which does have division instructions in ARM state.

ChangeLog entry is as follows:

*** gcc/testsuite/ChangeLog ***

2017-03-22  Thomas Preud'homme  

New prerequisites to support multi image COARRAY in gfortran

[Jerry DeLisle]

Gerald, (or who does this)

Since shared memory parallel programming with Fortran is now a Standard feature
of the language, we would like to support full parallelism through the use of
mpich and OpenCorrays.

We choose mpich as a default only because it is very stable. We choose
OpenCoarrays because it works well with gfortran and the developers have also
supported significant portions of the gfortran frontend (not to mention that it
is the only such library available). Choosing these as defaults for gfortran
does not exclude any user from using any other libraries in the future since the
final connection occurs at link time when a user compiles with -fcoarray=lib.

In order to support testing of installation of the new packages we are
requesting that the package tarballs be placed on the gcc.gnu.org along with the
other gcc prerequisite packages here:

ftp://gcc.gnu.org/pub/gcc/infrastructure/

There will be two stable released packages with appropriate shasum information
to be added. I can provide the links to those packages for download or send them
to you directly.

Requesting approval for this first step. (Later steps (more than one) will
provide patches for review of the contrib/download_prerequisites script. Another
step will be modifying OpenCoarrays build structure to align with the Gnu/gcc
build process. I believe mpich is already suitable, but will be testing.)

Is this OK?

Regards,

Jerry

Re: [PATCH, GCC/ARM, stage4] Fix small multiply feature

[Richard Earnshaw (lists)]

On 04/04/17 11:30, Thomas Preudhomme wrote:
> Small multiply variants of ARM Cortex-M0, Cortex-M0+ and Cortex-M1 were
> relying on the old cost model to work when optimizing for speed. These
> stopped being used in r241965 which led to these cores starting to use
> mul instructions instead of synthetizing the multiplications. This was
> not caught by the testsuite because the test only run if RUNTESTFLAGS
> targets one of the small multiply implementations.
> 
> This commit add the small multiply cost logic to the new speed cost
> model and change the dejagnu directives to only skip the corresponding
> tests if targeting another CPU. This means running the testsuite without
> targeting any CPU will let these tests run.
> 
> ChangeLog entries are as follow:
> 
> *** gcc/ChangeLog ***
> 
> 2017-03-31  Thomas Preud'homme  
> 
> PR target/80307
> * config/arm/arm.c (thumb1_rtx_costs): Give a cost of 32
> instructions for small multiply cores.
> 
> 
> *** gcc/testsuite/ChangeLog ***
> 
> 2017-03-31  Thomas Preud'homme  
> 
> PR target/80307
> * gcc.target/arm/small-multiply-m0-1.c: Do not skip test if not
> targeting any CPU or architecture.
> * gcc.target/arm/small-multiply-m0-2.c: Likewise.
> * gcc.target/arm/small-multiply-m0-3.c: Likewise.
> * gcc.target/arm/small-multiply-m0plus-1.c: Likewise.
> * gcc.target/arm/small-multiply-m0plus-2.c: Likewise.
> * gcc.target/arm/small-multiply-m0plus-3.c: Likewise.
> * gcc.target/arm/small-multiply-m1-1.c: Likewise.
> * gcc.target/arm/small-multiply-m1-2.c: Likewise.
> * gcc.target/arm/small-multiply-m1-3.c: Likewise.
> 
> Testing: With this patch the tests now all PASS if not targeting a
> special architecture or CPU. They were all UNSUPPORTED before in the
> same situation and the -1 tests were FAILing if targeting small
> multiply cores.
> 
> Is this ok for stage4?
> 

OK.

R.

> Best regards,
> 
> Thomas
> 
> fix_pr80307_arm_small_multiply.patch
> 
> 
> diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
> index 
> b24143e32e2f10f3b150f7ed0df4fabb3cc8..33146d1f0b54bad16cdaca1902d0f0a06a18c89d
>  100644
> --- a/gcc/config/arm/arm.c
> +++ b/gcc/config/arm/arm.c
> @@ -8727,6 +8727,9 @@ thumb1_rtx_costs (rtx x, enum rtx_code code, enum 
> rtx_code outer)
>return COSTS_N_INSNS (1);
>  
>  case MULT:
> +  if (arm_arch6m && arm_m_profile_small_mul)
> + return COSTS_N_INSNS (32);
> +
>if (CONST_INT_P (XEXP (x, 1)))
>   {
> int cycles = 0;
> diff --git a/gcc/testsuite/gcc.target/arm/small-multiply-m0-1.c 
> b/gcc/testsuite/gcc.target/arm/small-multiply-m0-1.c
> index 
> 49132e3e83d42874385523a3d0f05522a5974113..52c652c1cba3729c121d613bdb8c9f3524b04c98
>  100644
> --- a/gcc/testsuite/gcc.target/arm/small-multiply-m0-1.c
> +++ b/gcc/testsuite/gcc.target/arm/small-multiply-m0-1.c
> @@ -1,6 +1,6 @@
>  /* { dg-do compile } */
>  /* { dg-require-effective-target arm_thumb1_ok } */
> -/* { dg-skip-if "Test is specific to cortex-m0.small-multiply" { arm*-*-* } 
> { "*" } { "-mcpu=cortex-m0.small-multiply" } } */
> +/* { dg-skip-if "do not override -mcpu" { *-*-* } { "-mcpu=*" "-march=*" } { 
> "-mcpu=cortex-m0.small-multiply" } } */
>  /* { dg-options "-mcpu=cortex-m0.small-multiply -mthumb -O2" } */
>  
>  int
> diff --git a/gcc/testsuite/gcc.target/arm/small-multiply-m0-2.c 
> b/gcc/testsuite/gcc.target/arm/small-multiply-m0-2.c
> index 
> 7f1bf7bd604fcd6ef63f8dcb1fda0645d4803e87..10d49e9eace6141a5d3c906e235b6bbddaed8b4e
>  100644
> --- a/gcc/testsuite/gcc.target/arm/small-multiply-m0-2.c
> +++ b/gcc/testsuite/gcc.target/arm/small-multiply-m0-2.c
> @@ -1,6 +1,6 @@
>  /* { dg-do compile } */
>  /* { dg-require-effective-target arm_thumb1_ok } */
> -/* { dg-skip-if "Test is specific to cortex-m0.small-multiply" { arm*-*-* } 
> { "*" } { "-mcpu=cortex-m0.small-multiply" } } */
> +/* { dg-skip-if "do not override -mcpu" { *-*-* } { "-mcpu=*" "-march=*" } { 
> "-mcpu=cortex-m0.small-multiply" } } */
>  /* { dg-options "-mcpu=cortex-m0.small-multiply -mthumb -Os" } */
>  
>  int
> diff --git a/gcc/testsuite/gcc.target/arm/small-multiply-m0-3.c 
> b/gcc/testsuite/gcc.target/arm/small-multiply-m0-3.c
> index 
> aca39d746dc83ec94dce4d690bf1b87370192e94..b4af511af86c88a6d98a2779b3dc808d2163380c
>  100644
> --- a/gcc/testsuite/gcc.target/arm/small-multiply-m0-3.c
> +++ b/gcc/testsuite/gcc.target/arm/small-multiply-m0-3.c
> @@ -1,6 +1,6 @@
>  /* { dg-do compile } */
>  /* { dg-require-effective-target arm_thumb1_ok } */
> -/* { dg-skip-if "Test is specific to cortex-m0.small-multiply" { arm*-*-* } 
> { "*" } { "-mcpu=cortex-m0.small-multiply" } } */
> +/* { dg-skip-if "do not override -mcpu" { *-*-* } { "-mcpu=*" "-march=*" } { 
> "-mcpu=cortex-m0.small-multiply" } } */
>  /* { dg-options "-mcpu=cortex-m0.small-multiply -mthumb -Os" } */
>  
>  int
> diff --git a/gcc/testsuite/gcc.target/arm/small-multiply-m0plus-1.c 
> 

Re: Fix for PR79987

[Jeff Law]

On 04/04/2017 09:07 AM, Alexander Ivchenko wrote:

Hi,

When creating static bounds for foo below we end up with:

*((unsigned long *) &__chkp_bounds_of_foo + 8) =
~(__builtin_ia32_sizeof (foo) + ((long unsigned int)  +
18446744073709551615));

This fails in gimplify_function_tree with gcc_assert (!VOID_TYPE_P
(TREE_TYPE (*expr_p)));

Is it OK?

gcc/ChangeLog:

2017-04-04  Alexander Ivchenko  

* tree-chkp.c (chkp_get_bounds_for_decl_addr):
assigning zero bounds to void variables


gcc/testsuite/ChangeLog:

2017-04-04  Alexander Ivchenko  

* gcc.target/i386/mpx/PR79987.c: New test.
I've put this (and other CHKP fixes) in the queue for gcc-8 as AFAICT 
it's not a regression.


Jeff

Fix MIPS builds with current trunk

[Jeff Law]

All the MIPS compilers will fail to build using the trunk due to a 
couple minor uninitialized memory issues.


First in mips_multi_add we add an uninitialized mips_multi_member object 
to the mips_multi_members vec.  It's easy enough to just memset the new 
member.


Second in mips_expand_vec_perm_const the tail of the orig_perm may be 
uninitialized if the number of elements in the target object is smaller 
than MAX_VECT_LEN.  This is also trivial to fix by explicitly clearing 
the tail of the array.


Tested by verifying the MIPS targets in config-list.mk will build using 
a trunk compiler again.


Installed on the trunk.

Jeff

Re: [PATCH] Fix typos in comments throughout source tree

[Mike Stump]

On Apr 4, 2017, at 4:19 AM, Jonathan Wakely  wrote:
> Here's one more that somebody reported to the unofficial github
> mirror: https://github.com/gcc-mirror/gcc/pull/6/files
> 
> Committed to trunk.

Thanks.

Re: [BUILDROBOT] Maybe uninitialized warnings in mips targets

[Jeff Law]

On 03/18/2017 12:20 PM, Jan-Benedict Glaw wrote:

Hi Richard, Catherine, Matthew

On Thu, 2017-03-02 14:40:46 +0100, Richard Biener  wrote:
[...]

On IRC we decided to wait for the TREE_NO_WARNING issue.  So the
following is what I committed.

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

[...]

2017-03-02  Richard Biener  

PR tree-optimization/79345
PR c++/42000
* tree-ssa-alias.c (walk_aliased_vdefs_1): Take a limit
param and abort the walk, returning -1 if it is hit.
(walk_aliased_vdefs): Take a limit param and pass it on.
* tree-ssa-alias.h (walk_aliased_vdefs): Add a limit param,
defaulting to 0 and return a signed int.
* tree-ssa-uninit.c (struct check_defs_data): New struct.
(check_defs): New helper.
(warn_uninitialized_vars): Use walk_aliased_vdefs to warn
about uninitialized memory.

* fixed-value.c (fixed_from_string): Use ulow/uhigh to avoid
bogus uninitialized warning.
(fixed_convert_from_real): Likewise.

* g++.dg/warn/Wuninitialized-7.C: New testcase.
* c-c++-common/ubsan/bounds-2.c: Add -Wno-uninitialized.
* gcc.dg/uninit-pr19430-2.c: Add expected warning.


When building with config-list.mk, it seems to break for all of the
listed MIPS targets, but not on any other architecture:
I finally got around to installing the fixes to the MIPS backend for 
this problem.


Jeff

Re: [PATCH] Bump the default thread stack size on Darwin in libgomp (PR libgomp/79876)

[Mike Stump]

On Apr 4, 2017, at 2:20 AM, Dominique d'Humières  wrote:
>> Dominique has already tested it on Darwin 16 and said he'll test on Darwin
>> 10; I'm waiting for those results.
>> 
>>  Jakub
> 
> No problem with darwin10.

I'm fine with the patch.

Re: [PATCH, rs6000] Document location of ELF V2 ABI specification

[Bill Schmidt]

> On Apr 1, 2017, at 12:15 PM, Gerald Pfeifer  wrote:
> 
> On Fri, 31 Mar 2017, Bill Schmidt wrote:
>> OK, I've committed this as r246617.  Gerald, please let me know 
>> if you'd like any changes to the text.
> 
> This looks fine to me.
> 
> Just "These are described briefly below." I'd written as "These 
> are briefly described below." to avoid "briefly" seen as referring 
> to "below".

Thanks, I'll fix this later today.  Appreciate the review!

Bill

> 
> Gerald
> 

Re: [PATCH] Fix MMX/SSE/AVX* shifts by non-immediate scalar (PR target/80286)

[Jakub Jelinek]

On Tue, Apr 04, 2017 at 02:33:24PM +0200, Uros Bizjak wrote:
> > I assume split those before reload.  Because we want to give reload a chance
> > to do the zero extension on GPRs if it is more beneficial, and it might
> > choose to store it into memory and load into XMM from memory and that is
> > hard to do after reload.
> 
> Yes, split before reload, and hope that alternative's decorations play
> well with RA.

Haven't done these splitters yet, just playing now with:
typedef long long __m256i __attribute__ ((__vector_size__ (32), __may_alias__));
typedef int __v4si __attribute__ ((__vector_size__ (16)));
typedef short __v8hi __attribute__ ((__vector_size__ (16)));
typedef int __v8si __attribute__ ((__vector_size__ (32)));
typedef long long __m128i __attribute__ ((__vector_size__ (16), __may_alias__));
extern __inline __m128i __attribute__((__gnu_inline__, __always_inline__, 
__artificial__))
_mm256_castsi256_si128 (__m256i __A) { return (__m128i) __builtin_ia32_si_si256 
((__v8si)__A); }
extern __inline int __attribute__((__gnu_inline__, __always_inline__, 
__artificial__))
_mm_cvtsi128_si32 (__m128i __A) { return __builtin_ia32_vec_ext_v4si 
((__v4si)__A, 0); }
extern __inline __m128i __attribute__((__gnu_inline__, __always_inline__, 
__artificial__))
_mm_srli_epi16 (__m128i __A, int __B) { return 
(__m128i)__builtin_ia32_psrlwi128 ((__v8hi)__A, __B); }
__m256i m;
__m128i foo (__m128i minmax)
{
  int shift = _mm_cvtsi128_si32 (_mm256_castsi256_si128 (m));
  return _mm_srli_epi16 (minmax, shift);
}
to see what it emits (in that case we already have zero extension rather
than sign extension).
> > With ? in front of it or without?  I admit I've only tried so far:
> 
> I'd leave ?* in this case. In my experience, RA allocates alternative
> with ?* only when really needed.

So far I have following, which seems to work fine for the above testcase and
-O2 -m64 -mavx2, but doesn't work for -O2 -m32 -mavx2.
For 64-bit combiner matches the *vec_extractv4si_0_zext pattern and as that
doesn't have ? nor * in the constraint, it is used.
For 32-bit there is no such pattern and we end up with just zero_extendsidi2
pattern and apparently either the ? or * prevent IRA/LRA from using it.
If I remove both ?*, I get nice code even for 32-bit.

--- gcc/config/i386/sse.md.jj   2017-04-04 12:45:08.0 +0200
+++ gcc/config/i386/sse.md  2017-04-04 16:54:58.667382522 +0200
@@ -13517,16 +13517,17 @@ (define_insn "*vec_extract

Fix for PR79987

[Alexander Ivchenko]

Hi,

When creating static bounds for foo below we end up with:

*((unsigned long *) &__chkp_bounds_of_foo + 8) =
~(__builtin_ia32_sizeof (foo) + ((long unsigned int)  +
18446744073709551615));

This fails in gimplify_function_tree with gcc_assert (!VOID_TYPE_P
(TREE_TYPE (*expr_p)));

Is it OK?

gcc/ChangeLog:

2017-04-04  Alexander Ivchenko  

* tree-chkp.c (chkp_get_bounds_for_decl_addr):
assigning zero bounds to void variables


gcc/testsuite/ChangeLog:

2017-04-04  Alexander Ivchenko  

* gcc.target/i386/mpx/PR79987.c: New test.


diff --git a/gcc/testsuite/gcc.target/i386/mpx/PR79987.c
b/gcc/testsuite/gcc.target/i386/mpx/PR79987.c
new file mode 100644
index 000..14a32f3
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/mpx/PR79987.c
@@ -0,0 +1,5 @@
+/* { dg-do compile } */
+/* { dg-options "-fcheck-pointer-bounds -mmpx" } */
+
+extern void foo;
+void *bar = 
diff --git a/gcc/tree-chkp.c b/gcc/tree-chkp.c
index b1ff218..8a16025 100644
--- a/gcc/tree-chkp.c
+++ b/gcc/tree-chkp.c
@@ -3146,6 +3146,11 @@ chkp_get_bounds_for_decl_addr (tree decl)
   && !flag_chkp_incomplete_type)
   return chkp_get_zero_bounds ();

+  /* For void variables use zero bounds as well - we cannot
+ possibly get the size of the void.  */
+  if (VOID_TYPE_P (TREE_TYPE (decl)))
+  return chkp_get_zero_bounds ();
+
   if (flag_chkp_use_static_bounds
   && VAR_P (decl)
   && (TREE_STATIC (decl)

Re: libbacktrace PATCH: improve comment for backtrace_create_state

[basile]

On 2017-04-04 16:04, Ian Lance Taylor wrote:

On Tue, Apr 4, 2017 at 6:50 AM,   wrote:

On 2017-04-04 15:38, Ian Lance Taylor wrote:


How about we just add backtrace_destroy_state?


I don't know how to code that. In my
https://github.com/bstarynk/melt-monitor I observed that calling free 
on

such
a struct backtrace_state pointer is breaking things.


Well, yes, it would have to call backtrace_free.  But more than that
it would have to munmap the free list.  So you're right that it's not
trivial.

I also find the code of backtrace_create_state a bit complex (maybe 
for

historical reasons). Why does it call backtrace_alloc instead of just
calling malloc?


Because backtrace_create_state, like all the backtrace functions, can
be called from a signal handler.  The backtrace code can never call
malloc.  (It does call malloc on systems that do not support anonymous
mmap, because there is no other choice, which means that the backtrace
library does not really work entirely correctly on such systems.
Fortunately such systems are rare these days.  See
BACKTRACE_USES_MALLOC.)



This is great news! I would be tempted to suggest another comment change 
in backtrace.h saying that the functions are
(on most recent systems like Linux and those with anonymous mmap) 
async-signal-safe (when the user callbacks are also that).
I was unaware of that delicious property of your libbacktrace. Ian, you 
are impressing me even more than usual!



(I'm not a native English speaker or a POSIX guru, but to me the three 
words async-signal-safe means something important;
I am borrowing them from 
http://man7.org/linux/man-pages/man7/signal.7.html which might be my 
favorite man page, with time(7)).


Cheers.

--
Basile Starynkevitch   (France)http://starynkevitch/net/Basile/

Re: libbacktrace PATCH: improve comment for backtrace_create_state

[Ian Lance Taylor]

On Tue, Apr 4, 2017 at 6:50 AM,   wrote:
> On 2017-04-04 15:38, Ian Lance Taylor wrote:
>
>> How about we just add backtrace_destroy_state?
>
> I don't know how to code that. In my
> https://github.com/bstarynk/melt-monitor I observed that calling free on
> such
> a struct backtrace_state pointer is breaking things.

Well, yes, it would have to call backtrace_free.  But more than that
it would have to munmap the free list.  So you're right that it's not
trivial.

> I also find the code of backtrace_create_state a bit complex (maybe for
> historical reasons). Why does it call backtrace_alloc instead of just
> calling malloc?

Because backtrace_create_state, like all the backtrace functions, can
be called from a signal handler.  The backtrace code can never call
malloc.  (It does call malloc on systems that do not support anonymous
mmap, because there is no other choice, which means that the backtrace
library does not really work entirely correctly on such systems.
Fortunately such systems are rare these days.  See
BACKTRACE_USES_MALLOC.)

> And why would it call the error_callback on failure? (I would just return
> NULL in that case, leaving the caller of backtrace_create_state to handle
> that out-of-memory error itself).

It will call the error_callback on mmap failure, or an attempt to pass
threaded as true when it is not supported.

> Actually, I tend to believe that backtrace_create_state should have its
> signature changed to just:
>
>struct backtrace_state *backtrace_create_state (const char *filename, int
> threaded);
>
> Or maybe the above should be called backtrace_create_simple_state?

We could just document and implement passing error_callback as NULL.

Ian

Re: [PR 79905] ICE with vector_type

[Nathan Sidwell]

On 04/04/2017 09:57 AM, Bill Schmidt wrote:

I'll try the POC patch in a bit (kind of ugly as we have to replicate this for 
a whole bunch of types, I guess).


thanks.  Yup, all rs6000's builtins.  Wrapping it all in a
tree my_builtin_vector (char const *name, tree elt, unsigned num);
helper would probably make rs6000.c's initing cleaner?



Just FYI, I noticed this similar bug report came in today, not sure about the 
types:  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80309


thanks.  Probably not the same, but let's wait for a reduced testcase?

nathan

--
Nathan Sidwell

Re: [PR 79905] ICE with vector_type

[Bill Schmidt]

I'll try the POC patch in a bit (kind of ugly as we have to replicate this for 
a whole bunch of types, I guess).

Just FYI, I noticed this similar bug report came in today, not sure about the 
types:  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80309

-- Bill

Bill Schmidt, Ph.D.
GCC for Linux on Power
Linux on Power Toolchain
IBM Linux Technology Center
wschm...@linux.vnet.ibm.com

> On Apr 4, 2017, at 8:49 AM, Nathan Sidwell  wrote:
> 
> On 04/04/2017 09:00 AM, Richard Biener wrote:
> 
>> tree
>> add_builtin_type (const char *name, tree type)
>> {
>>  tree   id = get_identifier (name);
>>  tree decl = build_decl (BUILTINS_LOCATION, TYPE_DECL, id, type);
>>  return lang_hooks.decls.pushdecl (decl);
>> }
>> 
>> this seems to miss setting TYPE_NAME (type) = decl - oh, that may be
>> what set_underlying_type does via the langhook.
> 
> Correct, via the langhook.  I wonder if the smacking of the incoming-type's 
> TYPE_NAME is so that the global tree node references the now-named builtin 
> type.  If we were to make a clone here, (things like) VS4SI_type_node would 
> remain an unnamed type.  And I guess debug would be unhappy?
> 
>> At this point I'd rather restrict fiddling in this fragile area in
>> rs6000.c only ;)
> 
> me too.
> 
>> Does removing the TYPE_NAME setting fix things?
> 
> no,  those TYPE_NAME assignments are redundant -- set_underlying_type has 
> already initialized it.
> 
> The attached PoC fixes 79905 (no idea what ppc test it might break)
> 
> nathan
> 
> -- 
> Nathan Sidwell
> <79905-2.diff>

Re: libbacktrace PATCH: improve comment for backtrace_create_state

[basile]

On 2017-04-04 15:38, Ian Lance Taylor wrote:

On Tue, Apr 4, 2017 at 5:05 AM,   wrote:


I just discovered that backtrace_create_state should be called once, 
that it
is returning some heap-allocated data (which cannot be free-d, because 
there

is no
backtrace_destroy_state routine).

I suggest the attached patch (against GCC trunk r246678) which just 
improves

the comment describing that function.


You are adding that backtrace_create_state should be called "(probably
at startup, e.g. early in main)"?  But that is not accurate.  It's
perfectly reasonable to do what GCC itself does, which is call
backtrace_create_state only when it encounters an internal compiler
error (in diagnostic_action_after_output in gcc/diagnostic.c).

How about we just add backtrace_destroy_state?


I don't know how to code that. In my 
https://github.com/bstarynk/melt-monitor I observed that calling free on 
such

a struct backtrace_state pointer is breaking things.

I also find the code of backtrace_create_state a bit complex (maybe for 
historical reasons). Why does it call backtrace_alloc instead of just 
calling malloc?
And why would it call the error_callback on failure? (I would just 
return NULL in that case, leaving the caller of backtrace_create_state 
to handle

that out-of-memory error itself).

Actually, I tend to believe that backtrace_create_state should have its 
signature changed to just:


   struct backtrace_state *backtrace_create_state (const char *filename, 
int threaded);


Or maybe the above should be called backtrace_create_simple_state?

BTW, I guess that changing the API is not possible in current stage 
(that it why I suggested just a comment change).


Cheers

--
Basile Starynkevitch (France)http://starynkevitch.net/Basile/

Re: [PR 79905] ICE with vector_type

[Nathan Sidwell]

On 04/04/2017 09:00 AM, Richard Biener wrote:


tree
add_builtin_type (const char *name, tree type)
{
  tree   id = get_identifier (name);
  tree decl = build_decl (BUILTINS_LOCATION, TYPE_DECL, id, type);
  return lang_hooks.decls.pushdecl (decl);
}

this seems to miss setting TYPE_NAME (type) = decl - oh, that may be
what set_underlying_type does via the langhook.


Correct, via the langhook.  I wonder if the smacking of the 
incoming-type's TYPE_NAME is so that the global tree node references the 
now-named builtin type.  If we were to make a clone here, (things like) 
VS4SI_type_node would remain an unnamed type.  And I guess debug would 
be unhappy?



At this point I'd rather restrict fiddling in this fragile area in
rs6000.c only ;)


me too.


Does removing the TYPE_NAME setting fix things?


no,  those TYPE_NAME assignments are redundant -- set_underlying_type 
has already initialized it.


The attached PoC fixes 79905 (no idea what ppc test it might break)

nathan

--
Nathan Sidwell
Index: config/rs6000/rs6000.c
===
--- config/rs6000/rs6000.c	(revision 246647)
+++ config/rs6000/rs6000.c	(working copy)
@@ -17459,9 +17459,23 @@ rs6000_init_builtins (void)
   tdecl = add_builtin_type ("__vector unsigned int", unsigned_V4SI_type_node);
   TYPE_NAME (unsigned_V4SI_type_node) = tdecl;
 
-  tdecl = add_builtin_type ("__vector signed int", V4SI_type_node);
-  TYPE_NAME (V4SI_type_node) = tdecl;
+  { // Ugly POC hack
+TYPE_NAME (V4SI_type_node) = error_mark_node; // placeholder
+tdecl = add_builtin_type ("__vector signed int", V4SI_type_node);
+TYPE_NAME (V4SI_type_node) = NULL_TREE; // restore
 
+// Ew, change the underlying type
+DECL_ORIGINAL_TYPE (tdecl) = V4SI_type_node;
+tree clone = build_variant_type_copy (V4SI_type_node);
+TYPE_STUB_DECL (clone) = TYPE_STUB_DECL (V4SI_type_node);
+TYPE_NAME (clone) = tdecl;
+
+TREE_USED (clone) = 1;
+TREE_TYPE (tdecl) = clone;
+
+V4SI_type_node = TREE_TYPE (tdecl);
+  }
+  
   tdecl = add_builtin_type ("__vector __bool int", bool_V4SI_type_node);
   TYPE_NAME (bool_V4SI_type_node) = tdecl;
 

Re: libbacktrace PATCH: improve comment for backtrace_create_state

[Ian Lance Taylor]

On Tue, Apr 4, 2017 at 5:05 AM,   wrote:
>
> I just discovered that backtrace_create_state should be called once, that it
> is returning some heap-allocated data (which cannot be free-d, because there
> is no
> backtrace_destroy_state routine).
>
> I suggest the attached patch (against GCC trunk r246678) which just improves
> the comment describing that function.

You are adding that backtrace_create_state should be called "(probably
at startup, e.g. early in main)"?  But that is not accurate.  It's
perfectly reasonable to do what GCC itself does, which is call
backtrace_create_state only when it encounters an internal compiler
error (in diagnostic_action_after_output in gcc/diagnostic.c).

How about we just add backtrace_destroy_state?

Ian

Re: [PR 79905] ICE with vector_type

[Richard Biener]

On Tue, Apr 4, 2017 at 1:31 PM, Nathan Sidwell  wrote:
> On 04/04/2017 04:27 AM, Richard Biener wrote:
>>
>> On Mon, Apr 3, 2017 at 9:03 PM, Nathan Sidwell  wrote:
>
>
>>> However, as you can see there's already a get-out for COMPLEX_TYPE, and I
>>> think the same is needed for VECTOR_TYPE.
>>
>>
>> Hmm, but that is essentially a hack given that build_complex_type does
>> things
>> it shouldn't (assign a name to the type).
>
>
> Oh, didn't know that.
>
>>> Both set_underlying_type and rs6000 set the builtin vector type's
>>> TYPE_NAME,
>>> and so one constructed via applying __attribute__((vector_size(16))) will
>>> never match.   And it should.
>>
>>
>> why?  They only need to share the canonical type not the type node itself
>> (unless their name is the same, of course).
>
>
> Correct, that's what I meant.  the canonical type equal function must match
> a just-consed vector with the already-hashed builtin.
>
>> Now -- that name comparing is somewhat odd.  We hash type "variants"
>> with different names the same (so setting the name after inserting sth
>> into
>> the hash is allowed, but it will overwrite the old entry so any unnamed
>> uses
>> up to now get a type with a name...).  I guess we'd be better off leaving
>> only unnamed types in the hash and building a type variant whenever we
>> add a name to such type.
>
>
> Right, the name matching surprised me, and my first attempt was to remove
> it.  but that breaks wchar_t.  wchar_t is the same representation as int
> (pedantically, some integral type), but is a distinct type (in C++ at least,
> I don't think C cares).  The canonical type system records language-level
> distinctness, not representation distinctness.
>
> The difference between wchar_t and vector types is the only way to get a
> type the same as wchar_t is to use 'wchar_t' (so we have to start with a
> type at least as canonical as what we want).  Whereas vector types are
> constructed via applying attributes to some underlying scalar type (so we
> have to go find the canonical type).
>
> It would therefore seem that this code in set_underlying_type (c-common.c)
> is wrong:
>   if (DECL_IS_BUILTIN (x) && TREE_CODE (TREE_TYPE (x)) != ARRAY_TYPE)
> {
>   if (TYPE_NAME (TREE_TYPE (x)) == 0)
> TYPE_NAME (TREE_TYPE (x)) = x;
> }

This is quite a fragile area -- you also have to watch dwarf2out.c.  Most of the
TYPE_NAME "hacks" are to make debuginfo happy.

> And this rs6000.c code is totally bogus:
>   tdecl = add_builtin_type ("__vector unsigned int",
> unsigned_V4SI_type_node);
>   TYPE_NAME (unsigned_V4SI_type_node) = tdecl; <-- this line

Yeah, not sure what that like is for -- add_builtin_type properly adds a name.
Note it may be again to make debuginfo happy ;)

tree
add_builtin_type (const char *name, tree type)
{
  tree   id = get_identifier (name);
  tree decl = build_decl (BUILTINS_LOCATION, TYPE_DECL, id, type);
  return lang_hooks.decls.pushdecl (decl);
}

this seems to miss setting TYPE_NAME (type) = decl - oh, that may be
what set_underlying_type does via the langhook.

> (note that at this point, add_builtin_type has already set the TYPE_NAME via
> set_underlying type)
>
> For C++'s creation of the wchar_t node, we'd need to special case setting
> the node's name in some way?
>
> [char16_t and char32_t have the same distinctness property as wchar_t. I
> think that's the complete set]

At this point I'd rather restrict fiddling in this fragile area in
rs6000.c only ;)

Does removing the TYPE_NAME setting fix things?

Richard.

> nathan
>
> --
> Nathan Sidwell

Re: [PATCH] Fix a C++ crash with may_alias type attribute

[Jonathan Wakely]

On 04/04/17 12:39 +, Bernd Edlinger wrote:

Hi,

I noticed that the already created reference and pointer types
are left in an inconsistent state if the may_alias attribute
is added to a class, in some cases.

The attached patch fixes this by adding another loop over
all type variants of each pointer and reference type.

The new test case 20_util/any/assign/2a.cc is just a
clone of 20_util/any/assign/2.cc with the may_alias
attribute at the right place.


The new test doesn't really belong in the libstdc++, does it?

If this is a bug in the front-end then a reduced version of the test
belongs in the g++ testsuite.

[PATCH] Fix a C++ crash with may_alias type attribute

[Bernd Edlinger]

Hi,

I noticed that the already created reference and pointer types
are left in an inconsistent state if the may_alias attribute
is added to a class, in some cases.

The attached patch fixes this by adding another loop over
all type variants of each pointer and reference type.

The new test case 20_util/any/assign/2a.cc is just a
clone of 20_util/any/assign/2.cc with the may_alias
attribute at the right place.

Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?


Thanks
Bernd.
gcc/cp
2017-04-04  Bernd Edlinger  

PR c++/80287
* class.c (fixup_may_alias): Fix all type variants.

libstdc++-v3/
2017-04-04  Bernd Edlinger  

PR c++/80287
* testsuite/20_util/any/assign/2a.cc: New test.


Index: gcc/cp/class.c
===
--- gcc/cp/class.c	(revision 246605)
+++ gcc/cp/class.c	(working copy)
@@ -2060,12 +2060,14 @@ fixup_type_variants (tree t)
 static void
 fixup_may_alias (tree klass)
 {
-  tree t;
+  tree t, v;
 
   for (t = TYPE_POINTER_TO (klass); t; t = TYPE_NEXT_PTR_TO (t))
-TYPE_REF_CAN_ALIAS_ALL (t) = true;
+for (v = TYPE_MAIN_VARIANT (t); v; v = TYPE_NEXT_VARIANT (v))
+  TYPE_REF_CAN_ALIAS_ALL (v) = true;
   for (t = TYPE_REFERENCE_TO (klass); t; t = TYPE_NEXT_REF_TO (t))
-TYPE_REF_CAN_ALIAS_ALL (t) = true;
+for (v = TYPE_MAIN_VARIANT (t); v; v = TYPE_NEXT_VARIANT (v))
+  TYPE_REF_CAN_ALIAS_ALL (v) = true;
 }
 
 /* Early variant fixups: we apply attributes at the beginning of the class
Index: libstdc++-v3/testsuite/20_util/any/assign/2a.cc
===
--- libstdc++-v3/testsuite/20_util/any/assign/2a.cc	(revision 0)
+++ libstdc++-v3/testsuite/20_util/any/assign/2a.cc	(working copy)
@@ -0,0 +1,92 @@
+// { dg-options "-std=gnu++17" }
+// { dg-do run }
+
+// Copyright (C) 2014-2017 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3.  If not see
+// .
+
+#include 
+#include 
+
+using std::any;
+using std::any_cast;
+
+bool moved = false;
+bool copied = false;
+
+struct X
+{
+  X() = default;
+  X(const X&) { copied = true; }
+  X(X&& x) { moved = true; }
+};
+
+struct X2
+{
+  X2() = default;
+  X2(const X2&) { copied = true; }
+  X2(X2&& x) noexcept { moved = true; }
+}__attribute((may_alias));
+
+void test01()
+{
+  moved = false;
+  X x;
+  any a1;
+  a1 = x;
+  VERIFY(moved == false);
+  any a2;
+  copied = false;
+  a2 = std::move(x);
+  VERIFY(moved == true);
+  VERIFY(copied == false);
+}
+
+void test02()
+{
+  moved = false;
+  X x;
+  any a1;
+  a1 = x;
+  VERIFY(moved == false);
+  any a2;
+  copied = false;
+  a2 = std::move(a1);
+  VERIFY(moved == false);
+  VERIFY(copied == false);
+}
+
+void test03()
+{
+  moved = false;
+  X2 x;
+  any a1;
+  a1 = x;
+  VERIFY(copied && moved);
+  any a2;
+  moved = false;
+  copied = false;
+  a2 = std::move(a1);
+  VERIFY(moved == true);
+  VERIFY(copied == false);
+}
+
+int main()
+{
+  test01();
+  test02();
+  test03();
+}

Re: [PATCH] Fix MMX/SSE/AVX* shifts by non-immediate scalar (PR target/80286)

[Uros Bizjak]

On Tue, Apr 4, 2017 at 2:00 PM, Jakub Jelinek  wrote:
> On Tue, Apr 04, 2017 at 08:39:59AM +0200, Uros Bizjak wrote:
>> > Any thoughts on what to do to generate reasonable code when the shift count
>> > comes from memory (e.g. as int variable) or is in the low bits of some XMM
>> > regioster?
>>
>> The problem with int variable from memory is, that shifts access full
>> 128bits for their count operand, so this is effectively a no-go. If
>> there is a 128bit count value in memory, we can maybe define shift
>> pattern with:
>>
>> (subreg:DI (match_operand:V2DI 2 "general_operand" "xmN,vmN"))
>>
>> ?
>
> Well, if the original memory is say int, then we can't just read it as V2DI
> or V4SI.

Of course. The above was for the case when we *want* to load from
memory. The insn loads full 128bit value.

>> > First of all, perhaps we could have some combiner (or peephole) pattern 
>> > that would
>> > transform sign-extend from e.g. SI to DI on the shift count into 
>> > zero-extend
>> > if there are no other uses of the extension result - if the shift count is
>> > negative in SImode (or even QImode), then it is already large number and 
>> > the
>> > upper 32 bits or more don't really change anything on that.
>>
>> We can introduce shift patterns with embedded extensions, and split
>> them to zext + shift. These new patterns can be easily macroized with
>> any_extend code iterator and SWI124 mode iterator, so we avoid pattern
>> explosion.
>
> I assume split those before reload.  Because we want to give reload a chance
> to do the zero extension on GPRs if it is more beneficial, and it might
> choose to store it into memory and load into XMM from memory and that is
> hard to do after reload.

Yes, split before reload, and hope that alternative's decorations play
well with RA.

>> > Then perhaps we could emit pmovzxdq for SSE4.1+ instead of going through
>> > GPRs and back, or for SSE2 pxor on a scratch reg and punpck* to get it zero
>> > extended.  Not sure if we want to add =v / vm alternative to
>> > zero_extendsidi2*, it already has some x but with ?s that prevent the RA
>> > from using it.  So thoughts on that?
>>
>> The ? is there to discourage RA from allocating xmm reg (all these
>> alternatives have * on xmm reg), in effect instructing RA to prefer
>> GPRs. If the value is already in xmm reg, then I expect ? alternative
>> will be used. So, yes, v/v alternative as you proposed would be a good
>> addition to zero_extendsidi alternatives. Please note though that
>> pmovzxdq operates on a vector value, so memory operands should be
>> avoided.
>
> With ? in front of it or without?  I admit I've only tried so far:

I'd leave ?* in this case. In my experience, RA allocates alternative
with ?* only when really needed.

> @@ -4049,24 +4049,29 @@ (define_expand "extendsidi2"
>  })
>
>  (define_insn "*extendsidi2_rex64"
> -  [(set (match_operand:DI 0 "register_operand" "=*a,r")
> -   (sign_extend:DI (match_operand:SI 1 "nonimmediate_operand" "*0,rm")))]
> +  [(set (match_operand:DI 0 "register_operand" "=*a,r,v")
> +   (sign_extend:DI (match_operand:SI 1 "nonimmediate_operand" 
> "*0,rm,vm")))]
>"TARGET_64BIT"
>"@
> {cltq|cdqe}
> -   movs{lq|x}\t{%1, %0|%0, %1}"
> -  [(set_attr "type" "imovx")
> -   (set_attr "mode" "DI")
> -   (set_attr "prefix_0f" "0")
> -   (set_attr "modrm" "0,1")])
> +   movs{lq|x}\t{%1, %0|%0, %1}
> +   %vpmovsxdq\t{%1, %0|%0, %1}"
> +  [(set_attr "isa" "*,*,sse4")
> +   (set_attr "type" "imovx,imovx,ssemov")
> +   (set_attr "mode" "DI,DI,TI")
> +   (set_attr "prefix_0f" "0,0,*")
> +   (set_attr "prefix_extra" "*,*,1")
> +   (set_attr "prefix" "orig,orig,maybe_evex")
> +   (set_attr "modrm" "0,1,*")])
>
>
> and with the ? in front of v it for some reason didn't trigger.
> I'll try the zero_extendsidi2 now and see how it works.
>
>> OK for trunk and backports.
>
> Committed to trunk so far, backports in a week or so when I backport
> dozens of other patches together with it.
>
> Jakub

Uros.

Re: [DOC PATCH] PowerPC extended asm example

[Alan Modra]

Revised patch.

* doc/extend.texi (Extended Asm ): Rename to
"Clobbers and Scratch Registers".  Add OpenBLAS example.

diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 0f44ece..0b0a021 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -7869,7 +7869,7 @@ A comma-separated list of C expressions read by the 
instructions in the
 @item Clobbers
 A comma-separated list of registers or other values changed by the 
 @var{AssemblerTemplate}, beyond those listed as outputs.
-An empty list is permitted.  @xref{Clobbers}.
+An empty list is permitted.  @xref{Clobbers and Scratch Registers}.
 
 @item GotoLabels
 When you are using the @code{goto} form of @code{asm}, this section contains 
@@ -8229,7 +8229,7 @@ The enclosing parentheses are a required part of the 
syntax.
 
 When the compiler selects the registers to use to 
 represent the output operands, it does not use any of the clobbered registers 
-(@pxref{Clobbers}).
+(@pxref{Clobbers and Scratch Registers}).
 
 Output operand expressions must be lvalues. The compiler cannot check whether 
 the operands have data types that are reasonable for the instruction being 
@@ -8465,7 +8465,8 @@ as input.  The enclosing parentheses are a required part 
of the syntax.
 @end table
 
 When the compiler selects the registers to use to represent the input 
-operands, it does not use any of the clobbered registers (@pxref{Clobbers}).
+operands, it does not use any of the clobbered registers
+(@pxref{Clobbers and Scratch Registers}).
 
 If there are no output operands but there are input operands, place two 
 consecutive colons where the output operands would go:
@@ -8516,9 +8517,10 @@ asm ("cmoveq %1, %2, %[result]"
: "r" (test), "r" (new), "[result]" (old));
 @end example
 
-@anchor{Clobbers}
-@subsubsection Clobbers
+@anchor{Clobbers and Scratch Registers}
+@subsubsection Clobbers and Scratch Registers
 @cindex @code{asm} clobbers
+@cindex @code{asm} scratch registers
 
 While the compiler is aware of changes to entries listed in the output 
 operands, the inline @code{asm} code may modify more than just the outputs. 
For 
@@ -8589,6 +8591,110 @@ ten bytes of a string, use a memory input like:
 
 @end table
 
+Rather than allocating fixed registers via clobbers to provide scratch
+registers for an @code{asm} statement, there are better techniques you
+can use which give the compiler more freedom.  There are also better
+ways than using a @code{"memory"} clobber to tell GCC that an
+@code{asm} statement accesses or modifies memory.  The following
+PowerPC example taken from OpenBLAS illustrates some of these
+techniques.
+
+In the function shown below, all of the function parameters are inputs
+except for the @code{y} array, which is modified by the function.
+Only the first few lines of assembly in the @code{asm} statement are
+shown, and a comment handy for checking register assignments.  These
+insns set up some registers for later use in loops, and in particular,
+set up four pointers into the @code{ap} array, @code{a0=ap},
+@code{a1=ap+lda}, @code{a2=ap+2*lda}, and @code{a3=ap+3*lda}.  The
+rest of the assembly is simply too large to include here.
+
+@smallexample
+static void
+dgemv_kernel_4x4 (long n, const double *ap, long lda,
+  const double *x, double *y, double alpha)
+@{
+  double *a0;
+  double *a1;
+  double *a2;
+  double *a3;
+
+  __asm__
+(
+   "lxvd2x 34, 0, %10  \n\t"   // x0, x1
+   "lxvd2x 35, %11, %10\n\t"   // x2, x3
+   "xxspltd32, %x9, 0  \n\t"   // alpha, alpha
+   "sldi   %6, %13, 3  \n\t"   // lda * sizeof (double)
+   "xvmuldp34, 34, 32  \n\t"   // x0 * alpha, x1 * 
alpha
+   "xvmuldp35, 35, 32  \n\t"   // x2 * alpha, x3 * 
alpha
+   "add%4, %3, %6  \n\t"   // a0 = ap, a1 = a0 + lda
+   "add%6, %6, %6  \n\t"   // 2 * lda
+   "xxspltd32, 34, 0   \n\t"   // x0 * alpha, x0 * 
alpha
+   "xxspltd33, 34, 1   \n\t"   // x1 * alpha, x1 * 
alpha
+   "xxspltd34, 35, 0   \n\t"   // x2 * alpha, x2 * 
alpha
+   "xxspltd35, 35, 1   \n\t"   // x3 * alpha, x3 * 
alpha
+   "add%5, %3, %6  \n\t"   // a2 = a0 + 2 * lda
+   "add%6, %4, %6  \n\t"   // a3 = a1 + 2 * lda
+ ...
+ "#n=%1 ap=%8=%12 lda=%13 x=%7=%10 y=%0=%2 alpha=%9 o16=%11\n"
+ "#a0=%3 a1=%4 a2=%5 a3=%6"
+ :
+   "+m" (*y),
+   "+r" (n),   // 1
+   "+b" (y),   // 2
+   "=b" (a0),  // 3
+   "=b" (a1),  // 4
+   "=" (a2), // 5
+   "=" (a3)  // 6
+ :
+   "m" (*x),
+   "m" (*ap),
+   "d" (alpha),// 9
+   "r" (x),// 10
+   "b" (16),   // 11
+   "3" (ap),   // 12
+   "4" (lda)   // 13
+ :
+   "cr0",
+   

libbacktrace PATCH: improve comment for backtrace_create_state

[basile]

Hello All,

I just discovered that backtrace_create_state should be called once, 
that it is returning some heap-allocated data (which cannot be free-d, 
because there is no

backtrace_destroy_state routine).

I suggest the attached patch (against GCC trunk r246678) which just 
improves the comment describing that function.


libgcc/ChangeLog entry:

2017-04-04  Basile Starynkevitch  

   * backtrace.h (backtrace_create_state): Improve comment, since 
should be called once.


Comments are welcome. Otherwise, ok for trunk?

--
Basile Starynkevitch (France)
http://starynkevitch.net/Basile/Index: libbacktrace/backtrace.h
===
--- libbacktrace/backtrace.h	(revision 246678)
+++ libbacktrace/backtrace.h	(working copy)
@@ -83,16 +83,17 @@
 	  int errnum);
 
 /* Create state information for the backtrace routines.  This must be
-   called before any of the other routines, and its return value must
-   be passed to all of the other routines.  FILENAME is the path name
-   of the executable file; if it is NULL the library will try
-   system-specific path names.  If not NULL, FILENAME must point to a
-   permanent buffer.  If THREADED is non-zero the state may be
-   accessed by multiple threads simultaneously, and the library will
-   use appropriate atomic operations.  If THREADED is zero the state
-   may only be accessed by one thread at a time.  This returns a state
-   pointer on success, NULL on error.  If an error occurs, this will
-   call the ERROR_CALLBACK routine.  */
+   called once before any of the other routines (probably at startup,
+   e.g. early in main), and its return value must be passed to all of
+   the other routines.  FILENAME is the path name of the executable
+   file; if it is NULL the library will try system-specific path
+   names.  If not NULL, FILENAME must point to a permanent buffer.  If
+   THREADED is non-zero the state may be accessed by multiple threads
+   simultaneously, and the library will use appropriate atomic
+   operations.  If THREADED is zero the state may only be accessed by
+   one thread at a time.  This returns a state pointer on success,
+   NULL on error.  If an error occurs, this will call the
+   ERROR_CALLBACK routine.  */
 
 extern struct backtrace_state *backtrace_create_state (
 const char *filename, int threaded,

Re: [PATCH] Fix MMX/SSE/AVX* shifts by non-immediate scalar (PR target/80286)

[Jakub Jelinek]

On Tue, Apr 04, 2017 at 08:39:59AM +0200, Uros Bizjak wrote:
> > Any thoughts on what to do to generate reasonable code when the shift count
> > comes from memory (e.g. as int variable) or is in the low bits of some XMM
> > regioster?
> 
> The problem with int variable from memory is, that shifts access full
> 128bits for their count operand, so this is effectively a no-go. If
> there is a 128bit count value in memory, we can maybe define shift
> pattern with:
> 
> (subreg:DI (match_operand:V2DI 2 "general_operand" "xmN,vmN"))
> 
> ?

Well, if the original memory is say int, then we can't just read it as V2DI
or V4SI.

> > First of all, perhaps we could have some combiner (or peephole) pattern 
> > that would
> > transform sign-extend from e.g. SI to DI on the shift count into zero-extend
> > if there are no other uses of the extension result - if the shift count is
> > negative in SImode (or even QImode), then it is already large number and the
> > upper 32 bits or more don't really change anything on that.
> 
> We can introduce shift patterns with embedded extensions, and split
> them to zext + shift. These new patterns can be easily macroized with
> any_extend code iterator and SWI124 mode iterator, so we avoid pattern
> explosion.

I assume split those before reload.  Because we want to give reload a chance
to do the zero extension on GPRs if it is more beneficial, and it might
choose to store it into memory and load into XMM from memory and that is
hard to do after reload.

> > Then perhaps we could emit pmovzxdq for SSE4.1+ instead of going through
> > GPRs and back, or for SSE2 pxor on a scratch reg and punpck* to get it zero
> > extended.  Not sure if we want to add =v / vm alternative to
> > zero_extendsidi2*, it already has some x but with ?s that prevent the RA
> > from using it.  So thoughts on that?
> 
> The ? is there to discourage RA from allocating xmm reg (all these
> alternatives have * on xmm reg), in effect instructing RA to prefer
> GPRs. If the value is already in xmm reg, then I expect ? alternative
> will be used. So, yes, v/v alternative as you proposed would be a good
> addition to zero_extendsidi alternatives. Please note though that
> pmovzxdq operates on a vector value, so memory operands should be
> avoided.

With ? in front of it or without?  I admit I've only tried so far:
@@ -4049,24 +4049,29 @@ (define_expand "extendsidi2"
 })

 (define_insn "*extendsidi2_rex64"
-  [(set (match_operand:DI 0 "register_operand" "=*a,r")
-   (sign_extend:DI (match_operand:SI 1 "nonimmediate_operand" "*0,rm")))]
+  [(set (match_operand:DI 0 "register_operand" "=*a,r,v")
+   (sign_extend:DI (match_operand:SI 1 "nonimmediate_operand" 
"*0,rm,vm")))]
   "TARGET_64BIT"
   "@
{cltq|cdqe}
-   movs{lq|x}\t{%1, %0|%0, %1}"
-  [(set_attr "type" "imovx")
-   (set_attr "mode" "DI")
-   (set_attr "prefix_0f" "0")
-   (set_attr "modrm" "0,1")])
+   movs{lq|x}\t{%1, %0|%0, %1}
+   %vpmovsxdq\t{%1, %0|%0, %1}"
+  [(set_attr "isa" "*,*,sse4")
+   (set_attr "type" "imovx,imovx,ssemov")
+   (set_attr "mode" "DI,DI,TI")
+   (set_attr "prefix_0f" "0,0,*")
+   (set_attr "prefix_extra" "*,*,1")
+   (set_attr "prefix" "orig,orig,maybe_evex")
+   (set_attr "modrm" "0,1,*")])


and with the ? in front of v it for some reason didn't trigger.
I'll try the zero_extendsidi2 now and see how it works.

> OK for trunk and backports.

Committed to trunk so far, backports in a week or so when I backport
dozens of other patches together with it.

Jakub

Re: [RFC]: Fix Ada boostrap failure on S/390 with -mzarch

[Andreas Krebbel]

On 04/03/2017 06:18 PM, Eric Botcazou wrote:
>> On S/390 UNITS_PER_WORD is:
>> 8 with -m64
>> 4 with -m31
>> 8 with -m31 -mzarch
>>
>> This has been chosen to support use of 64 bit registers also in 32 bit
>> code.  Code compiled with -m31 -mzarch is supposed to adhere to the 32
>> bit ABI.  In order to make that work it was required to prevent
>> UNITS_PER_WORD from being used in ABI-relevant contexts.  That's why
>> Ulrich added the TARGET_UNWIND_WORD_MODE in 2008 (for SPU).
> 
> We do that for 32-bit SPARC on Solaris (-mv8plus) but UNITS_PER_WORD is 4.
> 
>> Now I could either fix this by reverting that change for S/390
>> (similiar to what Andreas Schwab did to fix the BZ) or I could just
>> use the size of the long data type (as we do in the ABI-relevant parts
>> of the backend as well).  Which one do you prefer?
> 
> Having System.Word_Size != Standard'Word_Size is a bit disturbing.  Does it 
> work to change only Memory_Size to 2 ** Long_Integer'Size?  This will also 
> correct the definition of Address below.

This worked as well. I've committed the following patch:

gcc/ada/ChangeLog:

2017-04-04  Andreas Krebbel  

* system-linux-s390.ads: Use Long_Integer'Size to define
Memory_Size.
---
 gcc/ada/system-linux-s390.ads | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/ada/system-linux-s390.ads b/gcc/ada/system-linux-s390.ads
index 485a8de..9bf8375 100644
--- a/gcc/ada/system-linux-s390.ads
+++ b/gcc/ada/system-linux-s390.ads
@@ -70,7 +70,7 @@ package System is

Storage_Unit : constant := 8;
Word_Size: constant := Standard'Word_Size;
-   Memory_Size  : constant := 2 ** Word_Size;
+   Memory_Size  : constant := 2 ** Long_Integer'Size;

--  Address comparison

Re: [PR 79905] ICE with vector_type

[Nathan Sidwell]

On 04/04/2017 04:27 AM, Richard Biener wrote:

On Mon, Apr 3, 2017 at 9:03 PM, Nathan Sidwell  wrote:



However, as you can see there's already a get-out for COMPLEX_TYPE, and I
think the same is needed for VECTOR_TYPE.


Hmm, but that is essentially a hack given that build_complex_type does things
it shouldn't (assign a name to the type).


Oh, didn't know that.


Both set_underlying_type and rs6000 set the builtin vector type's TYPE_NAME,
and so one constructed via applying __attribute__((vector_size(16))) will
never match.   And it should.


why?  They only need to share the canonical type not the type node itself
(unless their name is the same, of course).


Correct, that's what I meant.  the canonical type equal function must 
match a just-consed vector with the already-hashed builtin.



Now -- that name comparing is somewhat odd.  We hash type "variants"
with different names the same (so setting the name after inserting sth into
the hash is allowed, but it will overwrite the old entry so any unnamed uses
up to now get a type with a name...).  I guess we'd be better off leaving
only unnamed types in the hash and building a type variant whenever we
add a name to such type.


Right, the name matching surprised me, and my first attempt was to 
remove it.  but that breaks wchar_t.  wchar_t is the same representation 
as int (pedantically, some integral type), but is a distinct type (in 
C++ at least, I don't think C cares).  The canonical type system records 
language-level distinctness, not representation distinctness.


The difference between wchar_t and vector types is the only way to get a 
type the same as wchar_t is to use 'wchar_t' (so we have to start with a 
type at least as canonical as what we want).  Whereas vector types are 
constructed via applying attributes to some underlying scalar type (so 
we have to go find the canonical type).


It would therefore seem that this code in set_underlying_type 
(c-common.c) is wrong:

  if (DECL_IS_BUILTIN (x) && TREE_CODE (TREE_TYPE (x)) != ARRAY_TYPE)
{
  if (TYPE_NAME (TREE_TYPE (x)) == 0)
TYPE_NAME (TREE_TYPE (x)) = x;
}

And this rs6000.c code is totally bogus:
  tdecl = add_builtin_type ("__vector unsigned int", 
unsigned_V4SI_type_node);

  TYPE_NAME (unsigned_V4SI_type_node) = tdecl; <-- this line

(note that at this point, add_builtin_type has already set the TYPE_NAME 
via set_underlying type)


For C++'s creation of the wchar_t node, we'd need to special case 
setting the node's name in some way?


[char16_t and char32_t have the same distinctness property as wchar_t. 
I think that's the complete set]


nathan

--
Nathan Sidwell

Re: [PATCH] Fix typos in comments throughout source tree

[Jonathan Wakely]

On 03/04/17 23:31 +0100, Jonathan Wakely wrote:

On 03/04/17 20:06 +0100, Jonathan Wakely wrote:

On 03/04/17 11:48 -0700, Mike Stump wrote:

[ dup, I sent the wrong from the wrong email address, you might not see it 
because of that ]


On Apr 3, 2017, at 11:47 AM, Mike Stump  wrote:

On Apr 3, 2017, at 10:53 AM, Jonathan Wakely  wrote:


This fixes lots of typos throughout the tree. Can this be committed to
trunk as obvious?


Yes, it can.  However, I like it when even this patch is reviewed.  I reviewed 
it, looks good.

You missed initialisers -> initializers.


Ah yes, in a couple of places.

I think the original email about these typos only covered words
beginning with the letters A to E, so there are bound to be lots more
typos unfixed :-)



Not sure I like datastructures, should be data structures?


Will do. I also forgot to do something about the "accestor ???" part

We provide accestor to the inline_summary datastructure and
basic logic updating the parameters when inlining is performed.

I don't know what that's supposed to say. "access"? "accessors"?


I went for "access".

Thanks for the review.



figure out that poth parameters  -> figure out that both parameters


I'll fix that.


I've bootstrapped the C and C++ compilers, but not Ada, and of course
not compiled all the target changes in gcc/config/*

Is one big commit OK, or one per-ChangeLog? Or something else?


I'd just do one big commit.




Will do, thanks.



Here's one more that somebody reported to the unofficial github
mirror: https://github.com/gcc-mirror/gcc/pull/6/files

Committed to trunk.


commit e14421f33a7b205127f2c2d27103aa384313
Author: Jonathan Wakely 
Date:   Tue Apr 4 11:09:06 2017 +0100

	* ansidecl.h (ATTRIBUTE_PACKED): Fix typo in comment.

diff --git a/include/ansidecl.h b/include/ansidecl.h
index 6c0c837..25f33da 100644
--- a/include/ansidecl.h
+++ b/include/ansidecl.h
@@ -252,7 +252,7 @@ So instead we use the macro below and test it against specific values.  */
 # endif /* GNUC >= 3.0 */
 #endif /* ATTRIBUTE_ALIGNED_ALIGNOF */
 
-/* Useful for structures whose layout must much some binary specification
+/* Useful for structures whose layout must match some binary specification
regardless of the alignment and padding qualities of the compiler.  */
 #ifndef ATTRIBUTE_PACKED
 # define ATTRIBUTE_PACKED __attribute__ ((packed))

Re: [PATCH] ARM: Introduce ARM_DEFAULT_SHORT_ENUMS

[Sebastian Huber]

On 04/04/17 12:50, Sebastian Huber wrote:

On 04/04/17 12:41, Ramana Radhakrishnan wrote:

[dropping devel at rtems dot org as I don't want more bounces]

On Tue, Apr 4, 2017 at 10:07 AM, Sebastian Huber
 wrote:

>On 04/04/17 11:00, Ramana Radhakrishnan wrote:

>>>

>>> >  static bool
>>> >  arm_default_short_enums (void)
>>> >  {
>>> >-  return TARGET_AAPCS_BASED && arm_abi != ARM_ABI_AAPCS_LINUX;
>>> >+  return ARM_DEFAULT_SHORT_ENUMS;
>>> >  }
>>> >
>>> >
>>> >diff --git a/gcc/config/arm/rtems.h b/gcc/config/arm/rtems.h
>>> >index 53cd987..b34bbe8 100644
>>> >--- a/gcc/config/arm/rtems.h
>>> >+++ b/gcc/config/arm/rtems.h
>>> >@@ -27,3 +27,5 @@
>>> > builtin_assert ("system=rtems");\
>>> > TARGET_BPABI_CPP_BUILTINS();\
>>> >  } while (0)
>>> >+
>>> >+#define ARM_DEFAULT_SHORT_ENUMS false

>>
>>It's a change in ABI for the RTEMS platform but it certainly needs a
>>documentation update in the release notes . Also, is it necessary 
that
>>you need this in for GCC-7 or can you wait for stage-1 since we 
are in

>>regression fixes mode ?

>
>
>For RTEMS, ABI changes are not really critical. I would like to get 
this

>into GCC 6.4. For GCC 7 its not urgent.
>

The usual policy is not to have ABI changes within sub-releases of a
GCC release cycle. However if the RTEMs community is happy with it, I
have no particular objections.  I would however strongly suggest that
if you are fixing it for GCC 6.4 to then fix it for GCC-7*and*
document it in the release notes.


For RTEMS ABI changes are not a big deal. Its more important that we 
don't carry GCC patches around and can use a particular FSF release 
unmodified. I will add this change to the GCC 6.4 and 7.1 release 
notes, if this is all right for Jakub. 


v2 of the patch is here:

https://gcc.gnu.org/ml/gcc-patches/2017-04/msg00138.html

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

Re: [PATCH] ARM: Introduce ARM_DEFAULT_SHORT_ENUMS

[Sebastian Huber]

On 04/04/17 12:41, Ramana Radhakrishnan wrote:

[dropping devel at rtems dot org as I don't want more bounces]

On Tue, Apr 4, 2017 at 10:07 AM, Sebastian Huber
  wrote:

>On 04/04/17 11:00, Ramana Radhakrishnan wrote:

>>>

>>> >  static bool
>>> >  arm_default_short_enums (void)
>>> >  {
>>> >-  return TARGET_AAPCS_BASED && arm_abi != ARM_ABI_AAPCS_LINUX;
>>> >+  return ARM_DEFAULT_SHORT_ENUMS;
>>> >  }
>>> >
>>> >
>>> >diff --git a/gcc/config/arm/rtems.h b/gcc/config/arm/rtems.h
>>> >index 53cd987..b34bbe8 100644
>>> >--- a/gcc/config/arm/rtems.h
>>> >+++ b/gcc/config/arm/rtems.h
>>> >@@ -27,3 +27,5 @@
>>> > builtin_assert ("system=rtems");\
>>> > TARGET_BPABI_CPP_BUILTINS();\
>>> >  } while (0)
>>> >+
>>> >+#define ARM_DEFAULT_SHORT_ENUMS false

>>
>>It's a change in ABI for the RTEMS platform but it certainly needs a
>>documentation update in the release notes . Also, is it necessary that
>>you need this in for GCC-7 or can you wait for stage-1 since we are in
>>regression fixes mode ?

>
>
>For RTEMS, ABI changes are not really critical. I would like to get this
>into GCC 6.4. For GCC 7 its not urgent.
>

The usual policy is not to have ABI changes within sub-releases of a
GCC release cycle. However if the RTEMs community is happy with it, I
have no particular objections.  I would however strongly suggest that
if you are fixing it for GCC 6.4 to then fix it for GCC-7*and*
document it in the release notes.


For RTEMS ABI changes are not a big deal. Its more important that we 
don't carry GCC patches around and can use a particular FSF release 
unmodified. I will add this change to the GCC 6.4 and 7.1 release notes, 
if this is all right for Jakub.


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

Re: [PATCH] ARM: Introduce ARM_DEFAULT_SHORT_ENUMS

[Ramana Radhakrishnan]

[dropping devel at rtems dot org as I don't want more bounces]

On Tue, Apr 4, 2017 at 10:07 AM, Sebastian Huber
 wrote:
> On 04/04/17 11:00, Ramana Radhakrishnan wrote:
>>>
>>> >  static bool
>>> >  arm_default_short_enums (void)
>>> >  {
>>> >-  return TARGET_AAPCS_BASED && arm_abi != ARM_ABI_AAPCS_LINUX;
>>> >+  return ARM_DEFAULT_SHORT_ENUMS;
>>> >  }
>>> >
>>> >
>>> >diff --git a/gcc/config/arm/rtems.h b/gcc/config/arm/rtems.h
>>> >index 53cd987..b34bbe8 100644
>>> >--- a/gcc/config/arm/rtems.h
>>> >+++ b/gcc/config/arm/rtems.h
>>> >@@ -27,3 +27,5 @@
>>> > builtin_assert ("system=rtems");\
>>> > TARGET_BPABI_CPP_BUILTINS();\
>>> >  } while (0)
>>> >+
>>> >+#define ARM_DEFAULT_SHORT_ENUMS false
>>
>> It's a change in ABI for the RTEMS platform but it certainly needs a
>> documentation update in the release notes . Also, is it necessary that
>> you need this in for GCC-7 or can you wait for stage-1 since we are in
>> regression fixes mode ?
>
>
> For RTEMS, ABI changes are not really critical. I would like to get this
> into GCC 6.4. For GCC 7 its not urgent.
>

The usual policy is not to have ABI changes within sub-releases of a
GCC release cycle. However if the RTEMs community is happy with it, I
have no particular objections.  I would however strongly suggest that
if you are fixing it for GCC 6.4 to then fix it for GCC-7 *and*
document it in the release notes.




regards
Ramana

[PATCH v2] ARM: Introduce ARM_DEFAULT_SHORT_ENUMS

[Sebastian Huber]

Allow targets to define the default for the short enums option.

v2: Move ARM_DEFAULT_SHORT_ENUMS to arm.h.

gcc/

* config/arm/arm.h: (ARM_DEFAULT_SHORT_ENUMS): Provide default
definition.
* config/arm/arm.c: (arm_default_short_enums): Use
ARM_DEFAULT_SHORT_ENUMS.
* config/arm/rtems.h (ARM_DEFAULT_SHORT_ENUMS) Define.
---
 gcc/config/arm/arm.c   | 3 +--
 gcc/config/arm/arm.h   | 6 ++
 gcc/config/arm/rtems.h | 2 ++
 3 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index bc1e607..8f45bb9 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -26546,12 +26546,11 @@ arm_promote_function_mode (const_tree type 
ATTRIBUTE_UNUSED,
   return mode;
 }
 
-/* AAPCS based ABIs use short enums by default.  */
 
 static bool
 arm_default_short_enums (void)
 {
-  return TARGET_AAPCS_BASED && arm_abi != ARM_ABI_AAPCS_LINUX;
+  return ARM_DEFAULT_SHORT_ENUMS;
 }
 
 
diff --git a/gcc/config/arm/arm.h b/gcc/config/arm/arm.h
index 4dab73d..275004a 100644
--- a/gcc/config/arm/arm.h
+++ b/gcc/config/arm/arm.h
@@ -343,6 +343,12 @@ extern int arm_fpu_attr;
 #define ARM_DEFAULT_ABI ARM_ABI_APCS
 #endif
 
+/* AAPCS based ABIs use short enums by default.  */
+#ifndef ARM_DEFAULT_SHORT_ENUMS
+#define ARM_DEFAULT_SHORT_ENUMS \
+  (TARGET_AAPCS_BASED && arm_abi != ARM_ABI_AAPCS_LINUX)
+#endif
+
 /* Map each of the micro-architecture variants to their corresponding
major architecture revision.  */
 
diff --git a/gcc/config/arm/rtems.h b/gcc/config/arm/rtems.h
index 53cd987..b34bbe8 100644
--- a/gcc/config/arm/rtems.h
+++ b/gcc/config/arm/rtems.h
@@ -27,3 +27,5 @@
builtin_assert ("system=rtems");\
TARGET_BPABI_CPP_BUILTINS();\
 } while (0)
+
+#define ARM_DEFAULT_SHORT_ENUMS false
-- 
1.8.4.5

[PATCH, GCC/ARM, stage4] Fix small multiply feature

[Thomas Preudhomme]

Small multiply variants of ARM Cortex-M0, Cortex-M0+ and Cortex-M1 were
relying on the old cost model to work when optimizing for speed. These
stopped being used in r241965 which led to these cores starting to use
mul instructions instead of synthetizing the multiplications. This was
not caught by the testsuite because the test only run if RUNTESTFLAGS
targets one of the small multiply implementations.

This commit add the small multiply cost logic to the new speed cost
model and change the dejagnu directives to only skip the corresponding
tests if targeting another CPU. This means running the testsuite without
targeting any CPU will let these tests run.

ChangeLog entries are as follow:

*** gcc/ChangeLog ***

2017-03-31  Thomas Preud'homme  

PR target/80307
* config/arm/arm.c (thumb1_rtx_costs): Give a cost of 32
instructions for small multiply cores.


*** gcc/testsuite/ChangeLog ***

2017-03-31  Thomas Preud'homme  

PR target/80307
* gcc.target/arm/small-multiply-m0-1.c: Do not skip test if not
targeting any CPU or architecture.
* gcc.target/arm/small-multiply-m0-2.c: Likewise.
* gcc.target/arm/small-multiply-m0-3.c: Likewise.
* gcc.target/arm/small-multiply-m0plus-1.c: Likewise.
* gcc.target/arm/small-multiply-m0plus-2.c: Likewise.
* gcc.target/arm/small-multiply-m0plus-3.c: Likewise.
* gcc.target/arm/small-multiply-m1-1.c: Likewise.
* gcc.target/arm/small-multiply-m1-2.c: Likewise.
* gcc.target/arm/small-multiply-m1-3.c: Likewise.

Testing: With this patch the tests now all PASS if not targeting a
special architecture or CPU. They were all UNSUPPORTED before in the
same situation and the -1 tests were FAILing if targeting small
multiply cores.

Is this ok for stage4?

Best regards,

Thomas
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index b24143e32e2f10f3b150f7ed0df4fabb3cc8..33146d1f0b54bad16cdaca1902d0f0a06a18c89d 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -8727,6 +8727,9 @@ thumb1_rtx_costs (rtx x, enum rtx_code code, enum rtx_code outer)
   return COSTS_N_INSNS (1);
 
 case MULT:
+  if (arm_arch6m && arm_m_profile_small_mul)
+	return COSTS_N_INSNS (32);
+
   if (CONST_INT_P (XEXP (x, 1)))
 	{
 	  int cycles = 0;
diff --git a/gcc/testsuite/gcc.target/arm/small-multiply-m0-1.c b/gcc/testsuite/gcc.target/arm/small-multiply-m0-1.c
index 49132e3e83d42874385523a3d0f05522a5974113..52c652c1cba3729c121d613bdb8c9f3524b04c98 100644
--- a/gcc/testsuite/gcc.target/arm/small-multiply-m0-1.c
+++ b/gcc/testsuite/gcc.target/arm/small-multiply-m0-1.c
@@ -1,6 +1,6 @@
 /* { dg-do compile } */
 /* { dg-require-effective-target arm_thumb1_ok } */
-/* { dg-skip-if "Test is specific to cortex-m0.small-multiply" { arm*-*-* } { "*" } { "-mcpu=cortex-m0.small-multiply" } } */
+/* { dg-skip-if "do not override -mcpu" { *-*-* } { "-mcpu=*" "-march=*" } { "-mcpu=cortex-m0.small-multiply" } } */
 /* { dg-options "-mcpu=cortex-m0.small-multiply -mthumb -O2" } */
 
 int
diff --git a/gcc/testsuite/gcc.target/arm/small-multiply-m0-2.c b/gcc/testsuite/gcc.target/arm/small-multiply-m0-2.c
index 7f1bf7bd604fcd6ef63f8dcb1fda0645d4803e87..10d49e9eace6141a5d3c906e235b6bbddaed8b4e 100644
--- a/gcc/testsuite/gcc.target/arm/small-multiply-m0-2.c
+++ b/gcc/testsuite/gcc.target/arm/small-multiply-m0-2.c
@@ -1,6 +1,6 @@
 /* { dg-do compile } */
 /* { dg-require-effective-target arm_thumb1_ok } */
-/* { dg-skip-if "Test is specific to cortex-m0.small-multiply" { arm*-*-* } { "*" } { "-mcpu=cortex-m0.small-multiply" } } */
+/* { dg-skip-if "do not override -mcpu" { *-*-* } { "-mcpu=*" "-march=*" } { "-mcpu=cortex-m0.small-multiply" } } */
 /* { dg-options "-mcpu=cortex-m0.small-multiply -mthumb -Os" } */
 
 int
diff --git a/gcc/testsuite/gcc.target/arm/small-multiply-m0-3.c b/gcc/testsuite/gcc.target/arm/small-multiply-m0-3.c
index aca39d746dc83ec94dce4d690bf1b87370192e94..b4af511af86c88a6d98a2779b3dc808d2163380c 100644
--- a/gcc/testsuite/gcc.target/arm/small-multiply-m0-3.c
+++ b/gcc/testsuite/gcc.target/arm/small-multiply-m0-3.c
@@ -1,6 +1,6 @@
 /* { dg-do compile } */
 /* { dg-require-effective-target arm_thumb1_ok } */
-/* { dg-skip-if "Test is specific to cortex-m0.small-multiply" { arm*-*-* } { "*" } { "-mcpu=cortex-m0.small-multiply" } } */
+/* { dg-skip-if "do not override -mcpu" { *-*-* } { "-mcpu=*" "-march=*" } { "-mcpu=cortex-m0.small-multiply" } } */
 /* { dg-options "-mcpu=cortex-m0.small-multiply -mthumb -Os" } */
 
 int
diff --git a/gcc/testsuite/gcc.target/arm/small-multiply-m0plus-1.c b/gcc/testsuite/gcc.target/arm/small-multiply-m0plus-1.c
index 12e8839753c3cd01e466cf61860236ff425c4e90..59dba7cf4abc814f0ee2cf9c4776d76d644a07fc 100644
--- a/gcc/testsuite/gcc.target/arm/small-multiply-m0plus-1.c
+++ b/gcc/testsuite/gcc.target/arm/small-multiply-m0plus-1.c
@@ -1,6 +1,6 @@
 /* { dg-do compile } */
 /* { 

[PATCH 3/3] [ARC] Use long jumps for CRT calls

[Claudiu Zissulescu]

There are situations when the range offered by the bl instruction is
not sufficient to reach CRT routines. Thus, use a long jump
construction.

gcc/
2016-04-21  Claudiu Zissulescu  

* config/arc/arc.h (CRT_CALL_STATIC_FUNCTION): Use long calls.
---
 gcc/config/arc/arc.h | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/gcc/config/arc/arc.h b/gcc/config/arc/arc.h
index 0237e66..0c7e561 100644
--- a/gcc/config/arc/arc.h
+++ b/gcc/config/arc/arc.h
@@ -1518,10 +1518,11 @@ extern enum arc_function_type arc_compute_function_type 
(struct function *);
 /* Called by crtstuff.c to make calls to function FUNCTION that are defined in
SECTION_OP, and then to switch back to text section.  */
 #undef CRT_CALL_STATIC_FUNCTION
-#define CRT_CALL_STATIC_FUNCTION(SECTION_OP, FUNC) \
-asm (SECTION_OP "\n\t" \
-   "bl @" USER_LABEL_PREFIX #FUNC "\n" \
-   TEXT_SECTION_ASM_OP);
+#define CRT_CALL_STATIC_FUNCTION(SECTION_OP, FUNC) \
+  asm (SECTION_OP "\n\t"   \
+   "add r12,pcl,@" USER_LABEL_PREFIX #FUNC "@pcl\n\t"  \
+   "jl  [r12]\n"   \
+   TEXT_SECTION_ASM_OP);
 
 /* This macro expands to the name of the scratch register r12, used for
temporary calculations according to the ABI.  */
-- 
1.9.1

[PATCH 1/3] [ARC] Update mode_dependent_address_p hook.

[Claudiu Zissulescu]

Update arc_mode_dependent_address_p to avoid emitting subreg(mem (reg
..)) when expanding.

gcc/
2016-10-11  Claudiu Zissulescu  

* config/arc/arc.c (arc_mode_dependent_address_p): Relax
conditions to take advantage of various optimizations.
---
 gcc/config/arc/arc.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/gcc/config/arc/arc.c b/gcc/config/arc/arc.c
index 50bfa11..165f3d6 100644
--- a/gcc/config/arc/arc.c
+++ b/gcc/config/arc/arc.c
@@ -5641,13 +5641,9 @@ arc_mode_dependent_address_p (const_rtx addr, 
addr_space_t)
 {
   /* SYMBOL_REF is not mode dependent: it is either a small data reference,
  which is valid for loads and stores, or a limm offset, which is valid for
- loads.  */
-  /* Scaled indices are scaled by the access mode; likewise for scaled
- offsets, which are needed for maximum offset stores.  */
+ loads.  Scaled indices are scaled by the access mode.  */
   if (GET_CODE (addr) == PLUS
-  && (GET_CODE (XEXP ((addr), 0)) == MULT
- || (CONST_INT_P (XEXP ((addr), 1))
- && !SMALL_INT (INTVAL (XEXP ((addr), 1))
+  && GET_CODE (XEXP ((addr), 0)) == MULT)
 return true;
   return false;
 }
-- 
1.9.1

[PATCH 2/3] [ARC] DWARF emitting cleanup.

[Claudiu Zissulescu]

The use of CFA_FRAME_BASE_OFFSET and ARG_POINTER_CFA_OFFSET macros
leads to wrong offset calculation for DW_OP_fbreg constructions.
Remove them.

gcc/
2016-10-17  Claudiu Zissulescu  

* config/arc/arc-protos.h (arc_decl_pretend_args): Remove.
* config/arc/arc.c (arc_decl_pretend_args): Likewise.
* config/arc/arc.h (CFA_FRAME_BASE_OFFSET): Likewise.
(ARG_POINTER_CFA_OFFSET): Likewise.
---
 gcc/config/arc/arc-protos.h |  1 -
 gcc/config/arc/arc.c| 11 ---
 gcc/config/arc/arc.h|  5 -
 3 files changed, 17 deletions(-)

diff --git a/gcc/config/arc/arc-protos.h b/gcc/config/arc/arc-protos.h
index 55a7bf7..4ff8e9b 100644
--- a/gcc/config/arc/arc-protos.h
+++ b/gcc/config/arc/arc-protos.h
@@ -109,7 +109,6 @@ extern int arc_label_align (rtx_insn *label);
 extern bool arc_need_delay (rtx_insn *insn);
 extern bool arc_text_label (rtx_insn *insn);
 
-extern int arc_decl_pretend_args (tree decl);
 extern bool arc_short_comparison_p (rtx, int);
 extern bool arc_epilogue_uses (int regno);
 extern bool arc_eh_uses (int regno);
diff --git a/gcc/config/arc/arc.c b/gcc/config/arc/arc.c
index 165f3d6..d8ac6a6 100644
--- a/gcc/config/arc/arc.c
+++ b/gcc/config/arc/arc.c
@@ -9470,17 +9470,6 @@ arc_text_label (rtx_insn *label)
   return false;
 }
 
-/* Return the size of the pretend args for DECL.  */
-
-int
-arc_decl_pretend_args (tree decl)
-{
-  /* struct function is in DECL_STRUCT_FUNCTION (decl), but no
- pretend_args there...  See PR38391.  */
-  gcc_assert (decl == current_function_decl);
-  return crtl->args.pretend_args_size;
-}
-
 /* Without this, gcc.dg/tree-prof/bb-reorg.c fails to assemble
   when compiling with -O2 -freorder-blocks-and-partition -fprofile-use
   -D_PROFILE_USE; delay branch scheduling then follows a crossing jump
diff --git a/gcc/config/arc/arc.h b/gcc/config/arc/arc.h
index 24c2346..0237e66 100644
--- a/gcc/config/arc/arc.h
+++ b/gcc/config/arc/arc.h
@@ -1584,11 +1584,6 @@ extern enum arc_function_type arc_compute_function_type 
(struct function *);
 
 #define INIT_EXPANDERS arc_init_expanders ()
 
-#define CFA_FRAME_BASE_OFFSET(FUNDECL) (-arc_decl_pretend_args ((FUNDECL)))
-
-#define ARG_POINTER_CFA_OFFSET(FNDECL) \
-  (FIRST_PARM_OFFSET (FNDECL) + arc_decl_pretend_args ((FNDECL)))
-
 enum
 {
   ARC_LRA_PRIORITY_NONE, ARC_LRA_PRIORITY_NONCOMPACT, ARC_LRA_PRIORITY_COMPACT
-- 
1.9.1

[PATCH 0/3] ARC patches series

[Claudiu Zissulescu]

Hi Andrew,

Please find a number of small patches which are adding support to for CRT long 
calls, and fixes some errors when generating dwarf information and addresses.

Please let me know if more info is required,
Claudiu

Claudiu Zissulescu (3):
  [ARC] Update mode_dependent_address_p hook.
  [ARC] DWARF emitting cleanup.
  [ARC] Use long jumps for CRT calls

 gcc/config/arc/arc-protos.h |  1 -
 gcc/config/arc/arc.c| 19 ++-
 gcc/config/arc/arc.h| 14 +-
 3 files changed, 7 insertions(+), 27 deletions(-)

-- 
1.9.1

[C++ PATCH] Fix PR80294 -- Segfault in constexpr.c (reduced_constant_expression_p)

[Markus Trippelsdorf]

As the testcase shows, elt can become a NULL tree during
FOR_EACH_CONSTRUCTOR_VALUE. So guard against this possibility before
calling reduced_constant_expression_p() recursively.

Tested on ppc64le.
OK for trunk?

PR c++/80294
* constexpr.c (reduced_constant_expression_p): Guard against NULL
tree before recursing.

diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index 3ca356071810..9ee794d5bf37 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -1716,7 +1716,7 @@ reduced_constant_expression_p (tree t)
   /* And we need to handle PTRMEM_CST wrapped in a CONSTRUCTOR.  */
   tree elt; unsigned HOST_WIDE_INT idx;
   FOR_EACH_CONSTRUCTOR_VALUE (CONSTRUCTOR_ELTS (t), idx, elt)
-   if (!reduced_constant_expression_p (elt))
+   if (elt && !reduced_constant_expression_p (elt))
  return false;
   return true;
 
diff --git a/gcc/testsuite/g++.dg/torture/pr80294.C 
b/gcc/testsuite/g++.dg/torture/pr80294.C
new file mode 100644
index ..859a10ba3e31
--- /dev/null
+++ b/gcc/testsuite/g++.dg/torture/pr80294.C
@@ -0,0 +1,167 @@
+// { dg-do compile }
+
+namespace std {
+typedef long unsigned size_t;
+template  struct integral_constant {
+  static constexpr _Tp value = 0;
+};
+template  struct tuple_element;
+template  struct integer_sequence;
+} // namespace std
+namespace meta {
+using std::integer_sequence;
+template  struct list;
+template  class, typename...> struct defer;
+template  using _t = typename T::type;
+template  using size_t = std::integral_constant;
+namespace detail {
+enum indices_strategy_ { recurse };
+constexpr indices_strategy_ strategy_(std::size_t, std::size_t) {
+  return recurse;
+}
+template  struct make_indices_ 
{
+  using type = State;
+};
+} // namespace detail
+template 
+using index_sequence = integer_sequence;
+template 
+using make_index_sequence =
+_t, detail::strategy_(0, 0)>>;
+template 
+using invoke = typename F::template invoke;
+namespace lazy {
+template 
+using invoke = defer;
+}
+template  struct id { using type = int; };
+namespace detail {
+struct defer_if_ {
+  template  class C, typename... Ts> struct result {
+using type = C;
+  };
+  template  class C, typename... Ts>
+  result try_();
+};
+template  class C, typename... Ts>
+using defer_ = decltype(defer_if_{}.try_());
+} // namespace detail
+template  class C, typename... Ts>
+struct defer : detail::defer_ {};
+template  class C> struct quote {
+  template  using invoke = _t>;
+};
+template  class> using quote_trait = int;
+template  struct bind_front {
+  template  using invoke = invoke;
+};
+namespace extension {
+template  struct apply;
+template 
+struct apply : lazy::invoke {};
+} // namespace extension
+template 
+using apply = _t>;
+template  using curry = Q;
+template  using uncurry = bind_front;
+namespace detail {
+template  using first_ = T;
+template  struct repeat_n_c_;
+template 
+struct repeat_n_c_ {
+  using type = list...>;
+};
+} // namespace detail
+template 
+using repeat_n_c = _t>>;
+template  using repeat_n = repeat_n_c;
+namespace detail {
+template  struct at_impl_;
+template  struct at_impl_ {
+  template  static T eval(VoidPtrs..., T *);
+};
+template  struct at_;
+template 
+struct at_ : decltype(at_impl_>::eval(
+ static_cast(0)...)) {};
+} // namespace detail
+template  using at = _t>;
+template  using at_c = at>;
+namespace detail {
+template  struct front_;
+template  struct front_> {
+  using type = Head;
+};
+} // namespace detail
+template  using front = _t;
+namespace detail {
+template  struct back_;
+template  struct back_> {
+  using type = at_c, sizeof...(List)>;
+};
+} // namespace detail
+template  using back = _t;
+namespace detail {
+template 
+struct as_list_ : lazy::invoke>, Sequence> {};
+} // namespace detail
+template  using as_list = _t;
+} // namespace meta
+namespace detail {
+template  using tag_spec = meta::front;
+template  using tag_elem = meta::back;
+template  constexpr auto adl_get(T) {}
+} // namespace detail
+template  struct chain {
+  using type = int;
+};
+template 
+struct chain {
+  using type =
+  typename First::template getter

Re: [PATCH] Fix profiledbootstrap ada checking failure (PR debug/79255)

[Eric Botcazou]

> eric@polaris:~/build/gcc/native/gcc> rm ada/sem_util.o
> eric@polaris:~/build/gcc/native/gcc> make ADAFLAGS="-gnatpgn"
> /home/eric/build/gcc/native/./prev-gcc/xgcc -
> B/home/eric/build/gcc/native/./prev-gcc/
> -B/home/eric/install/gcc/x86_64-suse- linux/bin/
> -B/home/eric/install/gcc/x86_64-suse-linux/bin/ -
> B/home/eric/install/gcc/x86_64-suse-linux/lib/ -isystem
> /home/eric/install/gcc/x86_64-suse-linux/include -isystem
> /home/eric/install/gcc/x86_64-suse-linux/sys-include-c -g -O2  -gnatpgn 
> - W -Wall -nostdinc -I- -I. -Iada/generated -Iada
> -I/home/eric/svn/gcc/gcc/ada - I/home/eric/svn/gcc/gcc/ada/gcc-interface
> /home/eric/svn/gcc/gcc/ada/sem_util.adb -o ada/sem_util.o
> 
> raised STORAGE_ERROR : stack overflow or erroneous memory access
> /home/eric/svn/gcc/gcc/ada/gcc-interface/Make-lang.in:119: recipe for target
> 'ada/sem_util.o' failed

We have parent & child functions that are (partially) inlined into each other:

   ---
   -- Set_Debug_Info_Needed --
   ---

   procedure Set_Debug_Info_Needed (T : Entity_Id) is

  procedure Set_Debug_Info_Needed_If_Not_Set (E : Entity_Id);
  pragma Inline (Set_Debug_Info_Needed_If_Not_Set);
  --  Used to set debug info in a related node if not set already

  --
  -- Set_Debug_Info_Needed_If_Not_Set --
  --

  procedure Set_Debug_Info_Needed_If_Not_Set (E : Entity_Id) is
  begin
 if Present (E) and then not Needs_Debug_Info (E) then
Set_Debug_Info_Needed (E);

--  For a private type, indicate that the full view also needs
--  debug information.

if Is_Type (E)
  and then Is_Private_Type (E)
  and then Present (Full_View (E))
then
   Set_Debug_Info_Needed (Full_View (E));
end if;
 end if;
  end Set_Debug_Info_Needed_If_Not_Set;

   --  Start of processing for Set_Debug_Info_Needed

so -fno-partial-inlining is a workaround.

-- 
Eric Botcazou

Re: [PATCH] Bump the default thread stack size on Darwin in libgomp (PR libgomp/79876)

[Dominique d'Humières]

> Le 3 avr. 2017 à 19:00, Jakub Jelinek  a écrit :
> 
> On Mon, Apr 03, 2017 at 10:56:13AM -0600, Jeff Law wrote:
>> On 04/01/2017 06:24 AM, Jakub Jelinek wrote:
>>> Apparently Darwin has insane default stack size for pthread_create
>>> unless overridden through pthread_attr_setstacksize - 512kB, compared e.g.
>>> to Linux usual default of around 8MB.  For typical OpenMP uses that is way
>>> too low, so the following patch is an attempt to bump it to 2MB just on
>>> Darwin, and on other targets keep the default.  Everything can be in any
>>> case overridden through {,G}OMP_STACKSIZE env variables.
>>> 
>>> Bootstrapped/regtested on x86_64-linux and i686-linux, can anyone please 
>>> test it
>>> on darwin?
>>> 
>>> 2017-04-01  Jakub Jelinek  
>>> 
>>> PR libgomp/79876
>>> * config/posix/thread-stacksize.h: New file.
>>> * config/darwin/thread-stacksize.h: New file.
>>> * config/nvptx/thread-stacksize.h: New file.
>>> * env.c: Include thread-stacksize.h.
>>> (initialize_env): Initialize stacksize to GOMP_DEFAULT_STACKSIZE
>>> instead of 0.  Call pthread_attr_setstacksize even if
>>> GOMP_DEFAULT_STACKSIZE is non-zero.
>> I've got a build started, but it's on an ancient macbook pro, so it'll take
>> a long time.  Someone else with modern hardware could certainly get this
>> done faster :-)
> 
> Dominique has already tested it on Darwin 16 and said he'll test on Darwin
> 10; I'm waiting for those results.
> 
>   Jakub

No problem with darwin10.

Dominique

Re: [Patch C++/80296] Fix broken diagnostic: 'unary_plus_expr' not supported by expression

[Richard Biener]

On Mon, Apr 3, 2017 at 10:47 PM, Volker Reichelt
 wrote:
> The following patch fixes a broken diagnostic:
> #'unary_plus_expr' not supported by expression#
>
> The code to handle UNARY_PLUS_EXPR is already in place in
> cxx_pretty_printer::unary_expression. However, UNARY_PLUS_EXPR
> is not checked in cxx_pretty_printer::expression, so that we
> don't call cxx_pretty_printer::unary_expression.
> Fixed with the patch below.
>
> Bootstrapped and regtested on x86_64-pc-linux-gnu.
>
> OK for trunk? Or should this wait for stage 1?

I think it's obvious and can't break anything.

Richard.

> Regards,
> Volker
>
>
> 2017-04-03  Volker Reichelt  
>
> PR c++/80296
> * cxx-pretty-print.c (cxx_pretty_printer::expression): Add
> UNARY_PLUS_EXPR case.
>
> Index: gcc/cp/cxx-pretty-print.c
> ===
> --- gcc/cp/cxx-pretty-print.c   (revision 246620)
> +++ gcc/cp/cxx-pretty-print.c   (working copy)
> @@ -1112,6 +1112,7 @@
>  case SIZEOF_EXPR:
>  case ALIGNOF_EXPR:
>  case NOEXCEPT_EXPR:
> +case UNARY_PLUS_EXPR:
>unary_expression (t);
>break;
>
> 2017-04-03  Volker Reichelt  
>
> PR c++/80296
> * g++.dg/cpp0x/alias-decl-80296.C: New test.
>
> Index: gcc/testsuite/g++.dg/cpp0x/alias-decl-80296.C
> ===
> --- gcc/testsuite/g++.dg/cpp0x/alias-decl-80296.C   2017-04-03
> +++ gcc/testsuite/g++.dg/cpp0x/alias-decl-80296.C   2017-04-03
> @@ -0,0 +1,9 @@
> +// { dg-do compile { target c++11 } }
> +// { dg-bogus "not supported by" "" { target *-*-* } 0 }
> +
> +template  struct A {};
> +
> +template  using B = A<+N...>;
> +
> +B b; // { dg-error "type/value mismatch" }
> +  // { dg-message "expected a constant" "expected" { target *-*-* } 
> 8 }
> ===
>

Re: [PATCH] Fix profiledbootstrap ada checking failure (PR debug/79255)

[Eric Botcazou]

> We have local modifications in the Ada front-end so I cannot reproduce it
> with the pristine tree either. :-(

I apparently screwed up yesterday, this can be reproduced as such in the 
directory of a boostrapped compiler:

eric@polaris:~/build/gcc/native/gcc> rm ada/sem_util.o 
eric@polaris:~/build/gcc/native/gcc> make ADAFLAGS="-gnatpgn"
/home/eric/build/gcc/native/./prev-gcc/xgcc -
B/home/eric/build/gcc/native/./prev-gcc/ -B/home/eric/install/gcc/x86_64-suse-
linux/bin/ -B/home/eric/install/gcc/x86_64-suse-linux/bin/ -
B/home/eric/install/gcc/x86_64-suse-linux/lib/ -isystem 
/home/eric/install/gcc/x86_64-suse-linux/include -isystem 
/home/eric/install/gcc/x86_64-suse-linux/sys-include-c -g -O2  -gnatpgn  -
W -Wall -nostdinc -I- -I. -Iada/generated -Iada -I/home/eric/svn/gcc/gcc/ada -
I/home/eric/svn/gcc/gcc/ada/gcc-interface 
/home/eric/svn/gcc/gcc/ada/sem_util.adb -o ada/sem_util.o

raised STORAGE_ERROR : stack overflow or erroneous memory access
/home/eric/svn/gcc/gcc/ada/gcc-interface/Make-lang.in:119: recipe for target 
'ada/sem_util.o' failed
make: *** [ada/sem_util.o] Error 1

(gdb) bt
#0  0x00a2d4f8 in ggc_internal_alloc(unsigned long, void (*)(void*), 
unsigned long, unsigned long) ()
#1  0x00c2e069 in ggc_internal_cleared_alloc(unsigned long, void (*)
(void*), unsigned long, unsigned long) ()
#2  0x00b23865 in one_reg_loc_descriptor(unsigned int, 
var_init_status)
()
#3  0x00b5ba98 in loc_descriptor(rtx_def*, machine_mode, 
var_init_status) ()
#4  0x00b5c0b2 in loc_descriptor(rtx_def*, machine_mode, 
var_init_status) ()
#5  0x00b5661a in dw_loc_list_1(tree_node*, rtx_def*, int, 
var_init_status) ()
#6  0x00b56e0d in loc_list_from_tree_1(tree_node*, int, 
loc_descr_context*) ()
#7  0x00b59aeb in loc_list_from_tree(tree_node*, int, 
loc_descr_context*) ()
#8  0x00b5e14f in add_location_or_const_value_attribute(die_struct*, 
tree_node*, bool) ()
#9  0x00b60435 in gen_formal_parameter_die(tree_node*, tree_node*, 
bool, die_struct*) ()
#10 0x00b464c3 in gen_decl_die(tree_node*, tree_node*, vlr_context*, 
die_struct*) ()
#11 0x00b6660d in process_scope_var(tree_node*, tree_node*, 
tree_node*, die_struct*) ()
#12 0x00b40e78 in decls_for_scope(tree_node*, die_struct*) ()
#13 0x00b409db in gen_block_die(tree_node*, die_struct*) ()
#14 0x00b40f0b in decls_for_scope(tree_node*, die_struct*) ()
#15 0x00b41b7f in gen_subprogram_die(tree_node*, die_struct*) ()
#16 0x00b45c5a in gen_decl_die(tree_node*, tree_node*, vlr_context*, 
die_struct*) ()
#17 0x00b6660d in process_scope_var(tree_node*, tree_node*, 
tree_node*, die_struct*) ()
#18 0x00b40fad in decls_for_scope(tree_node*, die_struct*) ()
#19 0x00b409db in gen_block_die(tree_node*, die_struct*) ()
---Type  to continue, or q  to quit---
#20 0x00b40f0b in decls_for_scope(tree_node*, die_struct*) ()
#21 0x00b409db in gen_block_die(tree_node*, die_struct*) ()
#22 0x00b40f0b in decls_for_scope(tree_node*, die_struct*) ()
#23 0x00b41b7f in gen_subprogram_die(tree_node*, die_struct*) ()
#24 0x00b45c5a in gen_decl_die(tree_node*, tree_node*, vlr_context*, 
die_struct*) ()
#25 0x00b6660d in process_scope_var(tree_node*, tree_node*, 
tree_node*, die_struct*) ()
#26 0x00b40fad in decls_for_scope(tree_node*, die_struct*) ()
#27 0x00b409db in gen_block_die(tree_node*, die_struct*) ()
#28 0x00b40f0b in decls_for_scope(tree_node*, die_struct*) ()
#29 0x00b409db in gen_block_die(tree_node*, die_struct*) ()
#30 0x00b40f0b in decls_for_scope(tree_node*, die_struct*) ()
#31 0x00b41b7f in gen_subprogram_die(tree_node*, die_struct*) ()
#32 0x00b45c5a in gen_decl_die(tree_node*, tree_node*, vlr_context*, 
die_struct*) ()
#33 0x00b6660d in process_scope_var(tree_node*, tree_node*, 
tree_node*, die_struct*) ()
#34 0x00b40fad in decls_for_scope(tree_node*, die_struct*) ()
#35 0x00b409db in gen_block_die(tree_node*, die_struct*) ()
#36 0x00b40f0b in decls_for_scope(tree_node*, die_struct*) ()
#37 0x00b409db in gen_block_die(tree_node*, die_struct*) ()
#38 0x00b40f0b in decls_for_scope(tree_node*, die_struct*) ()
#39 0x00b41b7f in gen_subprogram_die(tree_node*, die_struct*) ()
#40 0x00b45c5a in gen_decl_die(tree_node*, tree_node*, vlr_context*, 
die_struct*) ()
#41 0x00b6660d in process_scope_var(tree_node*, tree_node*, 
tree_node*, die_struct*) ()

with thousands of similar frames.

-- 
Eric Botcazou

Re: [PATCH] ARM: Introduce ARM_DEFAULT_SHORT_ENUMS

[Sebastian Huber]

On 04/04/17 11:00, Ramana Radhakrishnan wrote:

>  static bool
>  arm_default_short_enums (void)
>  {
>-  return TARGET_AAPCS_BASED && arm_abi != ARM_ABI_AAPCS_LINUX;
>+  return ARM_DEFAULT_SHORT_ENUMS;
>  }
>
>
>diff --git a/gcc/config/arm/rtems.h b/gcc/config/arm/rtems.h
>index 53cd987..b34bbe8 100644
>--- a/gcc/config/arm/rtems.h
>+++ b/gcc/config/arm/rtems.h
>@@ -27,3 +27,5 @@
> builtin_assert ("system=rtems");\
> TARGET_BPABI_CPP_BUILTINS();\
>  } while (0)
>+
>+#define ARM_DEFAULT_SHORT_ENUMS false

It's a change in ABI for the RTEMS platform but it certainly needs a
documentation update in the release notes . Also, is it necessary that
you need this in for GCC-7 or can you wait for stage-1 since we are in
regression fixes mode ?


For RTEMS, ABI changes are not really critical. I would like to get this 
into GCC 6.4. For GCC 7 its not urgent.


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

Re: [PATCH] ARM: Introduce ARM_DEFAULT_SHORT_ENUMS

[Ramana Radhakrishnan]

On Mon, Apr 3, 2017 at 12:32 PM, Sebastian Huber
 wrote:
> Allow targets to define the default for the short enums option.
>
> gcc/
>
> * config/arm/arm.c: (ARM_DEFAULT_SHORT_ENUMS): Provide default
> definition.
> * config/arm/rtems.h (ARM_DEFAULT_SHORT_ENUMS) Define.
> ---
>  gcc/config/arm/arm.c   | 6 +-
>  gcc/config/arm/rtems.h | 2 ++
>  2 files changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
> index b24143e..33d3834 100644
> --- a/gcc/config/arm/arm.c
> +++ b/gcc/config/arm/arm.c
> @@ -26547,11 +26547,15 @@ arm_promote_function_mode (const_tree type 
> ATTRIBUTE_UNUSED,
>  }
>
>  /* AAPCS based ABIs use short enums by default.  */
> +#ifndef ARM_DEFAULT_SHORT_ENUMS
> +#define ARM_DEFAULT_SHORT_ENUMS \
> +  (TARGET_AAPCS_BASED && arm_abi != ARM_ABI_AAPCS_LINUX)
> +#endif

This belongs in arm.h rather than in arm.c

>
>  static bool
>  arm_default_short_enums (void)
>  {
> -  return TARGET_AAPCS_BASED && arm_abi != ARM_ABI_AAPCS_LINUX;
> +  return ARM_DEFAULT_SHORT_ENUMS;
>  }
>
>
> diff --git a/gcc/config/arm/rtems.h b/gcc/config/arm/rtems.h
> index 53cd987..b34bbe8 100644
> --- a/gcc/config/arm/rtems.h
> +++ b/gcc/config/arm/rtems.h
> @@ -27,3 +27,5 @@
> builtin_assert ("system=rtems");\
> TARGET_BPABI_CPP_BUILTINS();\
>  } while (0)
> +
> +#define ARM_DEFAULT_SHORT_ENUMS false


It's a change in ABI for the RTEMS platform but it certainly needs a
documentation update in the release notes . Also, is it necessary that
you need this in for GCC-7 or can you wait for stage-1 since we are in
regression fixes mode ?

Ramana

> --
> 1.8.4.5
>

Re: [PATCH] ARM: Introduce ARM_DEFAULT_SHORT_ENUMS

[Ramana Radhakrishnan]

On Tue, Apr 4, 2017 at 8:43 AM, Bernhard Reutner-Fischer
 wrote:
> On 3 April 2017 13:32:30 CEST, Sebastian Huber 
>  wrote:
>>Allow targets to define the default for the short enums option.
>
> Does this work nowadays?
> About 10 years ago I did this for some arm and had to force TREE_CODE at al 
> to 16 bit manually, IIRC.
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34205


I don't see why it won't work in cross-compilers and on Linux. the bug
report that you allude to seems to suggest that bootstrap was broken
with -fshort-enums i.e. -fshort-enums on a host. I don't see how
that's going to be possible without major work in the software but for
cross-compilers targeting embedded platforms I see no reason why
-fshort-enums won't work.


regards
Ramana

Re: [PR 79905] ICE with vector_type

[Richard Biener]

On Mon, Apr 3, 2017 at 9:03 PM, Nathan Sidwell  wrote:
> Bill,
> can you give this patch a spin please? I've smoke tested it on a ppc64le
> x-compiler, but don't have one to run executables.  regression testing on an
> x86_64-linux system is ok.
>
> The DEPENDENT_TYPE_VALID_P thing is a red herring.
>
> It is the canonical type table's equal function considering most types with
> different TYPE_NAMEs to be different.  Now, you might think that only
> applies to things like RECORD_TYPE, but no,  wchar_t is different from plain
> int, for example.
>
> However, as you can see there's already a get-out for COMPLEX_TYPE, and I
> think the same is needed for VECTOR_TYPE.

Hmm, but that is essentially a hack given that build_complex_type does things
it shouldn't (assign a name to the type).  make_vector_type doesn't do that so
it shouldn't get such special-handing.

> Both set_underlying_type and rs6000 set the builtin vector type's TYPE_NAME,
> and so one constructed via applying __attribute__((vector_size(16))) will
> never match.   And it should.

why?  They only need to share the canonical type not the type node itself
(unless their name is the same, of course).

Now -- that name comparing is somewhat odd.  We hash type "variants"
with different names the same (so setting the name after inserting sth into
the hash is allowed, but it will overwrite the old entry so any unnamed uses
up to now get a type with a name...).  I guess we'd be better off leaving
only unnamed types in the hash and building a type variant whenever we
add a name to such type.

Richard.


> nathan
> --
> Nathan Sidwell
>

Re: [PATCH] ARM: Introduce ARM_DEFAULT_SHORT_ENUMS

[Sebastian Huber]

On 04/04/17 09:43, Bernhard Reutner-Fischer wrote:

On 3 April 2017 13:32:30 CEST, Sebastian Huber 
 wrote:

Allow targets to define the default for the short enums option.

Does this work nowadays?
About 10 years ago I did this for some arm and had to force TREE_CODE at al to 
16 bit manually, IIRC.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34205


The short enums work fine on ARM. I want to get rid of them not due to 
compiler bugs.


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

Re: [PATCH] ARM: Introduce ARM_DEFAULT_SHORT_ENUMS

[Bernhard Reutner-Fischer]

On 3 April 2017 13:32:30 CEST, Sebastian Huber 
 wrote:
>Allow targets to define the default for the short enums option.

Does this work nowadays?
About 10 years ago I did this for some arm and had to force TREE_CODE at al to 
16 bit manually, IIRC.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34205

Re: [PATCH] For broken exception handling in GDB on AIX platform

[Nitish Kumar Mishra]

Hi Jeff,

Our AIX team is parallely working on the issue that why EH is not
working with static linking on AIX. For time being this patch
will be work around for the issue.


On Thu, Mar 30, 2017 at 1:07 AM, Jeff Law  wrote:
> On 03/26/2017 06:05 PM, Joel Brobecker wrote:
>>
>> Hello,
>>
>>> I got some review comment from Bernhard Reutner-Fischer, and I have
>>> updated the patch accordingly.
>>> This patch is for bug opened
>>> here:https://sourceware.org/bugzilla/show_bug.cgi?id=21187
>>
>>
>> This patch has been identified as one of the desirable patches
>> to have for the GDB 8.0 release, for which we are hoping to create
>> the branch ASAP. Without this patch, it would be difficult for
>> users on AIX to build a functional debugger.
>>
>> Would it be possible to help Nitish through the review and approval
>> process?
>>
>> Here is a ChangeLog entry:
>>
>> * configure.ac: Add support for --disable-staticlib.
>> * configure: Regenerate.
>>
>> Can someone review the patch, please?
>
> Isn't this just papering over the problem by just disabling static linking
> rather than digging into why EH is not working with static linking on AIX?
>
> It'd be different if there was some fundamental reason why EH could not work
> with static linking on AIX.
>
> Am I missing something?
>
> Jeff
>

Re: [PATCH] Fix PR80275

[Richard Biener]

On Tue, 4 Apr 2017, Marc Glisse wrote:

> On Tue, 4 Apr 2017, Markus Trippelsdorf wrote:
> 
> > On 2017.04.03 at 11:16 +0200, Richard Biener wrote:
> > > 
> > > The following extends split_address_to_core_and_offset to handle
> > > POINTER_PLUS_EXPR to be able to simplify
> > > (unsigned long) [(void *) + 12B] - (unsigned long) ((const int
> > > *)  + 4) which appears during niter analysis.
> > > 
> > > We seem to have various copies of similar code but refactoring didn't
> > > seem appropriate at this stage so I went for the minimal fix.
> > > 
> > > Bootstrap and regtest running on x86_64-unknown-linux-gnu.
> > > 
> > > Richard.
> > > 
> > > 2017-04-03  Richard Biener  
> > > 
> > >   PR tree-optimization/80275
> > >   * fold-const.c (split_address_to_core_and_offset): Handle
> > >   POINTER_PLUS_EXPR.
> > > 
> > >   * g++.dg/opt/pr80275.C: New testcase.
> > > 
> > > Index: gcc/fold-const.c
> > > ===
> > > --- gcc/fold-const.c  (revision 246642)
> > > +++ gcc/fold-const.c  (working copy)
> > > @@ -14341,6 +14341,24 @@ split_address_to_core_and_offset (tree e
> > > );
> > >core = build_fold_addr_expr_loc (loc, core);
> > >  }
> > > +  else if (TREE_CODE (exp) == POINTER_PLUS_EXPR)
> > > +{
> > > +  core = TREE_OPERAND (exp, 0);
> > > +  STRIP_NOPS (core);
> > > +  *pbitpos = 0;
> > > +  *poffset = TREE_OPERAND (exp, 1);
> > > +  if (TREE_CODE (*poffset) == INTEGER_CST)
> > > + {
> > > +   offset_int tem = wi::sext (wi::to_offset (*poffset),
> > > +  TYPE_PRECISION (TREE_TYPE (*poffset)));
> > > +   tem <<= LOG2_BITS_PER_UNIT;
> > > +   if (wi::fits_shwi_p (tem))
> > > + {
> > > +   *pbitpos = tem.to_shwi ();
> > > +   *poffset = NULL_TREE;
> > > + }
> > > + }
> > > +}
> > >else
> > >  {
> > >core = exp;
> > > Index: gcc/testsuite/g++.dg/opt/pr80275.C
> > > ===
> > > --- gcc/testsuite/g++.dg/opt/pr80275.C(nonexistent)
> > > +++ gcc/testsuite/g++.dg/opt/pr80275.C(working copy)
> > > @@ -0,0 +1,16 @@
> > > +// { dg-do compile { target c++14 } }
> > > +// { dg-options "-O2 -fdump-tree-optimized" }
> > > +
> > > +#include 
> > > +
> > > +int g()
> > > +{
> > > +  return 1234;
> > > +}
> > > +
> > > +int f2()
> > > +{
> > > +  return std::min({1, g(), 4});
> > > +}
> > > +
> > > +// { dg-final { scan-tree-dump "return 1;" "optimized" } }
> > 
> > The testcase fails with -fpic, e.g.:
> > https://gcc.gnu.org/ml/gcc-regression/2017-04/msg2.html
> > 
> > So perhaps:
> > 
> > diff --git a/gcc/testsuite/g++.dg/opt/pr80275.C
> > b/gcc/testsuite/g++.dg/opt/pr80275.C
> > index 7296a07fb2dd..7d625f2c7757 100644
> > --- a/gcc/testsuite/g++.dg/opt/pr80275.C
> > +++ b/gcc/testsuite/g++.dg/opt/pr80275.C
> > @@ -1,4 +1,4 @@
> > -// { dg-do compile { target c++14 } }
> > +// { dg-do compile { target c++14 && nonpic } }
> > // { dg-options "-O2 -fdump-tree-optimized" }
> > 
> > #include 
> 
> Making g static should work even with PIC.

Tested on x86_64-unknown-linux-gnu, applied.

Richard.

2017-04-04  Richard Biener  

PR tree-optimization/80275
* g++.dg/opt/pr80275.C: Make g static.

Index: gcc/testsuite/g++.dg/opt/pr80275.C
===
--- gcc/testsuite/g++.dg/opt/pr80275.C  (revision 246670)
+++ gcc/testsuite/g++.dg/opt/pr80275.C  (working copy)
@@ -3,7 +3,7 @@
 
 #include 
 
-int g()
+static int g()
 {
   return 1234;
 }

Re: [PATCH] Fix MMX/SSE/AVX* shifts by non-immediate scalar (PR target/80286)

[Uros Bizjak]

On Mon, Apr 3, 2017 at 10:34 PM, Jakub Jelinek  wrote:
> Hi!
>
> This patch deals just with correctness of vector shifts by scalar
> non-immediate.  The manuals say the shift count is bits [0:63] of
> the corresponding source operand (XMM reg or memory in some cases),
> and if the count is bigger than number of bits - 1 in the vector element,
> it is treated as number of bits shift count.
> We are modelling it as SImode shift count though, the upper 32 bits
> may be random in some cases which causes wrong-code.
> Fixed by using DImode that matches what the insns do.

IIRC, SImode was choosen to simplify GPR->XMM register moves on 32bit
target. It does look this was wrong choice from the correctness point.

> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> Any thoughts on what to do to generate reasonable code when the shift count
> comes from memory (e.g. as int variable) or is in the low bits of some XMM
> regioster?

The problem with int variable from memory is, that shifts access full
128bits for their count operand, so this is effectively a no-go. If
there is a 128bit count value in memory, we can maybe define shift
pattern with:

(subreg:DI (match_operand:V2DI 2 "general_operand" "xmN,vmN"))

?

> First of all, perhaps we could have some combiner (or peephole) pattern that 
> would
> transform sign-extend from e.g. SI to DI on the shift count into zero-extend
> if there are no other uses of the extension result - if the shift count is
> negative in SImode (or even QImode), then it is already large number and the
> upper 32 bits or more don't really change anything on that.

We can introduce shift patterns with embedded extensions, and split
them to zext + shift. These new patterns can be easily macroized with
any_extend code iterator and SWI124 mode iterator, so we avoid pattern
explosion.

> Then perhaps we could emit pmovzxdq for SSE4.1+ instead of going through
> GPRs and back, or for SSE2 pxor on a scratch reg and punpck* to get it zero
> extended.  Not sure if we want to add =v / vm alternative to
> zero_extendsidi2*, it already has some x but with ?s that prevent the RA
> from using it.  So thoughts on that?

The ? is there to discourage RA from allocating xmm reg (all these
alternatives have * on xmm reg), in effect instructing RA to prefer
GPRs. If the value is already in xmm reg, then I expect ? alternative
will be used. So, yes, v/v alternative as you proposed would be a good
addition to zero_extendsidi alternatives. Please note though that
pmovzxdq operates on a vector value, so memory operands should be
avoided.

>
> 2017-04-03  Jakub Jelinek  
>
> PR target/80286
> * config/i386/i386.c (ix86_expand_args_builtin): If op has scalar
> int mode, convert_modes it to mode as unsigned, otherwise use
> lowpart_subreg to mode rather than SImode.
> * config/i386/sse.md (ashr3,
> ashr3, ashr3, 3):
> Use DImode instead of SImode for the shift count operand.
> * config/i386/mmx.md (mmx_ashr3, mmx_3):
> Likewise.
> testsuite/
> * gcc.target/i386/avx-pr80286.c: New test.
> * gcc.dg/pr80286.c: New test.

OK for trunk and backports.

Thanks,
Uros.

> --- gcc/config/i386/i386.c.jj   2017-04-03 10:40:22.0 +0200
> +++ gcc/config/i386/i386.c  2017-04-03 18:31:39.482367634 +0200
> @@ -35582,10 +35582,17 @@ ix86_expand_args_builtin (const struct b
> {
>   /* SIMD shift insns take either an 8-bit immediate or
>  register as count.  But builtin functions take int as
> -count.  If count doesn't match, we put it in register.  */
> +count.  If count doesn't match, we put it in register.
> +The instructions are using 64-bit count, if op is just
> +32-bit, zero-extend it, as negative shift counts
> +are undefined behavior and zero-extension is more
> +efficient.  */
>   if (!match)
> {
> - op = lowpart_subreg (SImode, op, GET_MODE (op));
> + if (SCALAR_INT_MODE_P (GET_MODE (op)))
> +   op = convert_modes (mode, GET_MODE (op), op, 1);
> + else
> +   op = lowpart_subreg (mode, op, GET_MODE (op));
>   if (!insn_p->operand[i + 1].predicate (op, mode))
> op = copy_to_reg (op);
> }
> --- gcc/config/i386/sse.md.jj   2017-04-03 13:43:50.179572564 +0200
> +++ gcc/config/i386/sse.md  2017-04-03 18:01:19.713852914 +0200
> @@ -10620,7 +10620,7 @@ (define_insn "ashr3<
>[(set (match_operand:VI24_AVX512BW_1 0 "register_operand" "=v,v")
> (ashiftrt:VI24_AVX512BW_1
>   (match_operand:VI24_AVX512BW_1 1 "nonimmediate_operand" "v,vm")
> - (match_operand:SI 2 "nonmemory_operand" "v,N")))]
> + (match_operand:DI 2 "nonmemory_operand" "v,N")))]
>"TARGET_AVX512VL"
>"vpsra\t{%2, %1, %0|%0, %1, 
> %2}"
>[(set_attr 

Re: [PATCH] Fix PR80275

[Marc Glisse]

On Tue, 4 Apr 2017, Markus Trippelsdorf wrote:


On 2017.04.03 at 11:16 +0200, Richard Biener wrote:


The following extends split_address_to_core_and_offset to handle
POINTER_PLUS_EXPR to be able to simplify
(unsigned long) [(void *) + 12B] - (unsigned long) ((const int
*)  + 4) which appears during niter analysis.

We seem to have various copies of similar code but refactoring didn't
seem appropriate at this stage so I went for the minimal fix.

Bootstrap and regtest running on x86_64-unknown-linux-gnu.

Richard.

2017-04-03  Richard Biener  

PR tree-optimization/80275
* fold-const.c (split_address_to_core_and_offset): Handle
POINTER_PLUS_EXPR.

* g++.dg/opt/pr80275.C: New testcase.

Index: gcc/fold-const.c
===
--- gcc/fold-const.c(revision 246642)
+++ gcc/fold-const.c(working copy)
@@ -14341,6 +14341,24 @@ split_address_to_core_and_offset (tree e
  );
   core = build_fold_addr_expr_loc (loc, core);
 }
+  else if (TREE_CODE (exp) == POINTER_PLUS_EXPR)
+{
+  core = TREE_OPERAND (exp, 0);
+  STRIP_NOPS (core);
+  *pbitpos = 0;
+  *poffset = TREE_OPERAND (exp, 1);
+  if (TREE_CODE (*poffset) == INTEGER_CST)
+   {
+ offset_int tem = wi::sext (wi::to_offset (*poffset),
+TYPE_PRECISION (TREE_TYPE (*poffset)));
+ tem <<= LOG2_BITS_PER_UNIT;
+ if (wi::fits_shwi_p (tem))
+   {
+ *pbitpos = tem.to_shwi ();
+ *poffset = NULL_TREE;
+   }
+   }
+}
   else
 {
   core = exp;
Index: gcc/testsuite/g++.dg/opt/pr80275.C
===
--- gcc/testsuite/g++.dg/opt/pr80275.C  (nonexistent)
+++ gcc/testsuite/g++.dg/opt/pr80275.C  (working copy)
@@ -0,0 +1,16 @@
+// { dg-do compile { target c++14 } }
+// { dg-options "-O2 -fdump-tree-optimized" }
+
+#include 
+
+int g()
+{
+  return 1234;
+}
+
+int f2()
+{
+  return std::min({1, g(), 4});
+}
+
+// { dg-final { scan-tree-dump "return 1;" "optimized" } }


The testcase fails with -fpic, e.g.:
https://gcc.gnu.org/ml/gcc-regression/2017-04/msg2.html

So perhaps:

diff --git a/gcc/testsuite/g++.dg/opt/pr80275.C 
b/gcc/testsuite/g++.dg/opt/pr80275.C
index 7296a07fb2dd..7d625f2c7757 100644
--- a/gcc/testsuite/g++.dg/opt/pr80275.C
+++ b/gcc/testsuite/g++.dg/opt/pr80275.C
@@ -1,4 +1,4 @@
-// { dg-do compile { target c++14 } }
+// { dg-do compile { target c++14 && nonpic } }
// { dg-options "-O2 -fdump-tree-optimized" }

#include 


Making g static should work even with PIC.

--
Marc Glisse