Re: [C++ PATCH] [PR87770] test partial specializations for type dependence

[Alexandre Oliva]

On Jan 27, 2019, Jason Merrill  wrote:

>> +tinfo = DECL_TEMPLATE_INFO (node);

> Maybe use get_template_info?

Neat!  But then, if we can assume node is a decl, we might as well go
straight for DECL_TEMPLATE_INFO.  I'd rather not make that assumption,
though, and allow this new function to be called for template types as
well, because you mentioned other places that used PRIMARY_TEMPLATE_P
might need the extra logic.  I don't know whether they might be dealing
with types though.

>> + ??? How do we
>> + tell apart a partial from a full explicit specialization in a
>> + non-template context?  */

> We don't need to tell them apart here, the caller checks if there are
> any dependent template arguments.

The single caller does, indeed, but the function does not make that a
requirement, so others might call it and fail to check it.  Should that
test be moved here too?

Anyhow, the question was really about the fact that the non-template
context has no template argument depth for us to compare with.  When I
wrote that comment, I was returning true for !ctinfo, unconditionally,
reasoning that if NODE's context is not a template, then NODE must
specialize some a primary template.  But if we want partial but not full
explicit specializations, then just having a deeper (or nonzero)
template argument depth is not enough, is it?

>> +  tree ctxt;
>> +  if (!DECL_P (node))
>> +ctxt = TYPE_CONTEXT (node);
>> +  else
>> +ctxt = DECL_CONTEXT (node);

> We know tmpl is a decl, so we can unconditionally take its DECL_CONTEXT.

Does it hurt too much to keep it more general, so that it can deal with
template class types too?  Or is there going to be no use for that?  In
the latter case, I suppose we should document that, and then we just use
tinfo = DECL_TEMPLATE_INFO (node) above (right?)

> And you can use get_template_info here as well.

*nod*, thanks

-- 
Alexandre Oliva, freedom fighter   https://FSFLA.org/blogs/lxo
Be the change, be Free! FSF Latin America board member
GNU Toolchain EngineerFree Software Evangelist
Hay que enGNUrecerse, pero sin perder la terGNUra jamás-GNUChe

Re: [PATCH] avoid assuming arrays have nonzero size (PR 88956)

[Martin Sebor]

Ping: https://gcc.gnu.org/ml/gcc-patches/2019-01/msg01340.html

This is a straightforward fix for an ICE.  I will commit it tomorrow
unless there are suggestions for other changes.

On 1/22/19 6:18 PM, Martin Sebor wrote:

The enhancement to treat char initializer-lists as STRING_CSTs
committed earlier last year introduced an assumption that array
elements have a non-zero size.  As it turns out, the zero-length
array extension that makes it possible to define even multi-
dimensional zero-length array objects breaks that assumption when
it's passed as an argument to a function like memcpy. The attached
patch removes that assumption.

Tested on x86_64-linux.

Martin

PS In GCC 10, unless there is an important use case that escapes
me, I think GCC should warn for zero-length non-member array
objects, or perhaps even for internal struct members (those followed
by another member).  Not to avoid these sorts of bugs but because
they seem too dangerous to use safely.

C++ PATCH for c++/88325 - ICE with invalid out-of-line template member definition

[Marek Polacek]

This patch fixes an ICE-on-invalid (becase out-of-line constructors can't have
template arguments and also because function templates can't be partially
specialized) in C++2a: when we're parsing

  template template A::A ()

in the attached test we end up parsing "A::A" as a type name, and first we
try a class-name.  First we process "A::" as the nested name specifier and 
then
we parse "A".  In this test that results in a BASELINK.  Because in this 
context
we're supposed to treat it as a typename ([temp.res]/6), we call 
make_typename_type,
but that crashes.

Implicit 'typename' doesn't make sense for function types, so a safe fix would 
be
the following: avoid calling make_typename_type; the rest of the function will
make sure to emit an error and return the error_mark_node.

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

2019-01-28  Marek Polacek  

PR c++/88325 - ICE with invalid out-of-line template member definition.
* parser.c (cp_parser_class_name): Don't call make_typename_type
for overloads.

* g++.dg/cpp2a/typename14.C: New test.

diff --git gcc/cp/parser.c gcc/cp/parser.c
index 16f2a32bc0b..1bfa0c88f5b 100644
--- gcc/cp/parser.c
+++ gcc/cp/parser.c
@@ -23167,7 +23167,9 @@ cp_parser_class_name (cp_parser *parser,
   decl = cp_parser_maybe_treat_template_as_class (decl, class_head_p);
 
   /* If this is a typename, create a TYPENAME_TYPE.  */
-  if (typename_p && decl != error_mark_node)
+  if (typename_p
+  && decl != error_mark_node
+  && !is_overloaded_fn (decl))
 {
   decl = make_typename_type (scope, decl, typename_type,
 /*complain=*/tf_error);
diff --git gcc/testsuite/g++.dg/cpp2a/typename14.C 
gcc/testsuite/g++.dg/cpp2a/typename14.C
new file mode 100644
index 000..4750db35cd8
--- /dev/null
+++ gcc/testsuite/g++.dg/cpp2a/typename14.C
@@ -0,0 +1,25 @@
+// PR c++/88325
+// { dg-do compile { target c++2a } }
+
+template struct A
+{
+  template A ();
+};
+
+template
+template
+A::A () // { dg-error "partial specialization" }
+{
+}
+
+template struct B
+{
+  template int foo (int);
+};
+
+template
+template
+B::foo(int) // { dg-error "partial specialization|declaration" }
+{
+  return 1;
+}

[PATCH] Fix tests for complex overloads of std::arg and std::proj

[Jonathan Wakely]

The test for the synopsis of  incorrectly adds constexpr to
two functions in C++2a mode, but the C++2a draft and the 
header do not declare them constexpr.

* testsuite/26_numerics/headers/complex/synopsis.cc: Remove incorrect
constexpr specifiers from arg and proj.

Tested x86_64-linux, committed to trunk.


commit 9b259812b364c850a3dc93707dac1ff41077704b
Author: Jonathan Wakely 
Date:   Tue Jan 29 00:50:56 2019 +

Fix tests for complex overloads of std::arg and std::proj

The test for the synopsis of  incorrectly adds constexpr to
two functions in C++2a mode, but the C++2a draft and the 
header do not declare them constexpr.

* testsuite/26_numerics/headers/complex/synopsis.cc: Remove 
incorrect
constexpr specifiers from arg and proj.

diff --git a/libstdc++-v3/testsuite/26_numerics/headers/complex/synopsis.cc 
b/libstdc++-v3/testsuite/26_numerics/headers/complex/synopsis.cc
index 3a22625c9d3..11307d194c0 100644
--- a/libstdc++-v3/testsuite/26_numerics/headers/complex/synopsis.cc
+++ b/libstdc++-v3/testsuite/26_numerics/headers/complex/synopsis.cc
@@ -89,10 +89,10 @@ namespace std {
   template _GLIBCXX_CONSTEXPR T real(const complex&);
   template _GLIBCXX_CONSTEXPR T imag(const complex&);
   template T abs(const complex&);
-  template _GLIBCXX20_CONSTEXPR T arg(const complex&);
+  template T arg(const complex&);
   template _GLIBCXX20_CONSTEXPR T norm(const complex&);
   template _GLIBCXX20_CONSTEXPR complex conj(const complex&);
-  template _GLIBCXX20_CONSTEXPR complex proj(const complex&);
+  template complex proj(const complex&);
   template complex polar(const T& rho, const T& theta);
 
   // 26.2.8 transcendentals:

Re: [Driver] Add support for -fuse-ld=lld

[Alan Modra]

On Sat, Jan 26, 2019 at 04:34:59PM -0600, Segher Boessenkool wrote:
> On Thu, Jun 23, 2016 at 09:01:30PM -0700, Davide Italiano wrote:
> > LLVM currently ships with a new ELF linker http://lld.llvm.org/.
> > I experiment a lot with gcc and lld so it would be nice if
> > -fuse-ld=lld is supported (considering the linker is now mature enough
> > to link large C/C++ applications).
> > 
> > Also, IMHO, -fuse-ld should be a generic facility which accept other
> > linkers (as long as they follow the convention ld.), and should
> > also support absolute path, e.g. -fuse-ld=/usr/local/bin/ld.mylinker.
> > Probably outside of the scope of this patch, but I thought worth
> > mentioning.
> 
> This can never work correctly.
> 
> The many HAVE_LD_* flags are set for the linker you are configured
> against.  Now normally GNU ld and Gold will be built from the same tree,
> so they will be at least mostly compatible.  But for some other linker
> that cannot ever work.  If you can choose a random linker at runtime then
> the linker features the compiler is built for will almost certainly not
> match those that linker has.
> 
> You can built with --with-ld=/some/path/to/your/lld, and *that* should
> work fine.  But -fuse-ld=/smth/random will result in randomness.

Yes, and please do note (distros!!) that --with-ld will result in -B
also not being able to specify a linker.  That's a pain if you want to
run the binutils ld testsuite.  You'll get something like:

ERROR: 
ERROR: Your compiler driver ignores -B when choosing ld.
ERROR: You will not be testing the new ld in many of the following tests.
ERROR: It seems you will be testing /usr/bin/x86_64-w64-mingw32-ld instead.
ERROR: 

-- 
Alan Modra
Australia Development Lab, IBM

[PATCH] [ARC]: Enable init_array support

[Vineet Gupta]

gcc's common configure script has a subtle flaw that it only tests
{init,fini.preinit}_array support when NOT cross compiling. This causes
cross builds to erroneously deduce that the feature is not supported by
the target.

| host-gcc-final-ab544139bfee/build/gcc/config.log
|
|configure:22941: checking for .preinit_array/.init_array/.fini_array support
|configure:23106: checking cross compile... guessing
|configure:23111: result: no

The right fix is to enable this for *all* cross setups (and address any
fallouts). However in the short-term to enable ARC glibc port to upstream,
force enable this for ARC.

This has been discussed at length on glibc mailing list [1], [2]

[1] https://sourceware.org/ml/libc-alpha/2018-11/msg00870.html
[2] https://sourceware.org/ml/libc-alpha/2019-01/msg00656.html

gcc/

2019-xx-xx  Vineet Gupta 

* gcc/config.gcc: Force .init_array for ARC

Signed-off-by: Vineet Gupta 
---
 gcc/ChangeLog  | 4 
 gcc/config.gcc | 3 +++
 2 files changed, 7 insertions(+)

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index f5872dbeab7c..4c86d5375bcc 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,7 @@
+2019-01-28  Vineet Gupta  
+
+   * gcc/config.gcc: Force .init_array for ARC
+
 2019-01-28  Jakub Jelinek  
 
PR middle-end/89002
diff --git a/gcc/config.gcc b/gcc/config.gcc
index a189cb19f633..eef4b4eac918 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -1110,6 +1110,9 @@ arc*-*-linux*)
case ${with_endian} in
big*)   tm_file="arc/big.h ${tm_file}"
esac
+   # Force .init_array support.  The configure script cannot always
+   # automatically detect that GAS supports it, yet we require it.
+   gcc_cv_initfini_array=yes
 ;;
 arm-wrs-vxworks|arm-wrs-vxworks7)
extra_options="${extra_options} arm/vxworks.opt"
-- 
2.7.4

Re: [libbacktrace] Don't assign check_PROGRAMS to TESTS

[Ian Lance Taylor]

On Mon, Jan 28, 2019 at 3:05 PM Tom de Vries  wrote:
>
> [ was: Re: [backtrace] Avoid segfault ]
>
> On 27-01-19 22:16, Tom de Vries wrote:
> > +# The file b2test_buildid is an objcopy of b2test, so these programs share 
> > the
> > +# same build-id.  The first time b2test is run, there's no corresponding 
> > debug
> > +# file at ./usr/lib/debug/.build-id/aa/bb..zz.debug.  The second time 
> > b2test is
> > +# run, the .debug file has been created for b2test_buildid, which is now 
> > picked
> > +# up by b2test as well.
>
> I realized now that what I was looking at were the consequences of the
> "TESTS = $(check_PROGRAMS)" setting in libbacktrace/Makefile.am, which
> forces b2test to be run, even though I specify just "check_PROGRAMS +=
> b2test".
>
> This patch undoes that setting, and introduces a variable BUILDTESTS to
> indicate that a test needs to be both build and run.
>
> OK for trunk?

This is OK.

Thanks.

Ian

libgo patch committed: Use the call instruction's PC for panic-in-runtime checks

[Ian Lance Taylor]

This patch by Cherry Zhang changes libgo to use the call instruction's
PC for panic-in-runtime detection.  If a panic happens in the runtime
we turn that into a fatal error.  We use the caller's PC to determine
if the panic call is inside the runtime. getcallerpc returns the PC
immediately after the call instruction.  If the call is the very last
instruction of a function, it may not find this PC belong to a runtime
function,
giving false result.  We need to back off the PC by 1 to the call
instruction.  Bootstrapped and ran Go testsuite on
x86_64-pc-linux-gnu.  Committed to mainline.

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 268347)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-5ccb2d8593963e06ec3a35d362b384e82301d9f0
+c2cac0ba0a92e74d5675c3c9f4e53d2567dbc903
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: libgo/go/runtime/panic.go
===
--- libgo/go/runtime/panic.go   (revision 268158)
+++ libgo/go/runtime/panic.go   (working copy)
@@ -53,7 +53,7 @@ var indexError = error(errorString("inde
 // entire runtime stack for easier debugging.
 
 func panicindex() {
-   name, _, _ := funcfileline(getcallerpc(), -1)
+   name, _, _ := funcfileline(getcallerpc()-1, -1)
if hasPrefix(name, "runtime.") {
throw(string(indexError.(errorString)))
}
@@ -64,7 +64,7 @@ func panicindex() {
 var sliceError = error(errorString("slice bounds out of range"))
 
 func panicslice() {
-   name, _, _ := funcfileline(getcallerpc(), -1)
+   name, _, _ := funcfileline(getcallerpc()-1, -1)
if hasPrefix(name, "runtime.") {
throw(string(sliceError.(errorString)))
}
Index: libgo/runtime/go-runtime-error.c
===
--- libgo/runtime/go-runtime-error.c(revision 268158)
+++ libgo/runtime/go-runtime-error.c(working copy)
@@ -63,7 +63,7 @@ __go_runtime_error (int32 i)
   struct funcfileline_return fileline;
   bool in_runtime;
 
-  fileline = runtime_funcfileline ((uintptr) runtime_getcallerpc(), 0);
+  fileline = runtime_funcfileline ((uintptr) runtime_getcallerpc()-1, 0);
   in_runtime = (fileline.retfn.len > 0
&& (__builtin_strncmp ((const char *) fileline.retfn.str,
  "runtime.", 8)

[PATCH] Add missing exports for symbols used by directory iterators

[Jonathan Wakely]

* config/abi/pre/gnu.ver (GLIBCXX_3.4.26): Add missing exports for
__shared_ptr instantiations used by gcc4-compatible ABI.

Tested x86_64-linux, committed to trunk.

commit b50b2bf26eef0e87014c19991bebfa9b75c2b754
Author: Jonathan Wakely 
Date:   Tue Jan 29 00:19:59 2019 +

Add missing exports for symbols used by directory iterators

* config/abi/pre/gnu.ver (GLIBCXX_3.4.26): Add missing exports for
__shared_ptr instantiations used by gcc4-compatible ABI.

diff --git a/libstdc++-v3/config/abi/pre/gnu.ver 
b/libstdc++-v3/config/abi/pre/gnu.ver
index 34c70b6cb8f..a0860668b90 100644
--- a/libstdc++-v3/config/abi/pre/gnu.ver
+++ b/libstdc++-v3/config/abi/pre/gnu.ver
@@ -2225,6 +2225,12 @@ GLIBCXX_3.4.26 {
 _ZNSt10filesystem7__cxx1128recursive_directory_iteratoraSEOS1_;
 _ZNSt10filesystem7__cxx1128recursive_directory_iteratorppEv;
 
+
_ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEC1Ev;
+
_ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEC1EOS4_;
+
_ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEaSEOS4_;
+
_ZNSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC1Ev;
+
_ZNSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC1EOS5_;
+
 
_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEC1Ev;
 
_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEC1EOS5_;
 
_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEaSEOS5_;

[PATCH] Avoid ambiguity between C++2a std::erase_if and LFTS version

[Jonathan Wakely]

These calls should have been qualified to avoid ADL anyway, but in C++2a
it becomes essential to qualify the calls in experimental::erase because
std::erase_if is also declared and the calls become ambiguous.

* include/experimental/forward_list (experimental::erase): Qualify
call to erase_if.
* include/experimental/list (experimental::erase): Likewise.
* include/std/forward_list (std::erase): Likewise.
* include/std/list (std::erase): Likewise.

Tested x86_64-linux, committed to trunk.

commit b9d2ffc25b406e52ce921ced97a14fcdeabd558b
Author: Jonathan Wakely 
Date:   Tue Jan 29 00:14:11 2019 +

Avoid ambiguity between C++2a std::erase_if and LFTS version

These calls should have been qualified to avoid ADL anyway, but in C++2a
it becomes essential to qualify the calls in experimental::erase because
std::erase_if is also declared and the calls become ambiguous.

* include/experimental/forward_list (experimental::erase): Qualify
call to erase_if.
* include/experimental/list (experimental::erase): Likewise.
* include/std/forward_list (std::erase): Likewise.
* include/std/list (std::erase): Likewise.

diff --git a/libstdc++-v3/include/experimental/forward_list 
b/libstdc++-v3/include/experimental/forward_list
index 60f0564f065..f6ffbf0a0af 100644
--- a/libstdc++-v3/include/experimental/forward_list
+++ b/libstdc++-v3/include/experimental/forward_list
@@ -54,7 +54,9 @@ inline namespace fundamentals_v2
 erase(forward_list<_Tp, _Alloc>& __cont, const _Up& __value)
 {
   using __elem_type = typename forward_list<_Tp, _Alloc>::value_type;
-  erase_if(__cont, [&](__elem_type& __elem) { return __elem == __value; });
+  std::experimental::erase_if(__cont, [&](__elem_type& __elem) {
+ return __elem == __value;
+  });
 }
 
   namespace pmr {
diff --git a/libstdc++-v3/include/experimental/list 
b/libstdc++-v3/include/experimental/list
index 13c33f02e72..2b7a331e63a 100644
--- a/libstdc++-v3/include/experimental/list
+++ b/libstdc++-v3/include/experimental/list
@@ -54,7 +54,9 @@ inline namespace fundamentals_v2
 erase(list<_Tp, _Alloc>& __cont, const _Up& __value)
 {
   using __elem_type = typename list<_Tp, _Alloc>::value_type;
-  erase_if(__cont, [&](__elem_type& __elem) { return __elem == __value; });
+  experimental::erase_if(__cont, [&](__elem_type& __elem) {
+ return __elem == __value;
+  });
 }
 
 namespace pmr {
diff --git a/libstdc++-v3/include/std/forward_list 
b/libstdc++-v3/include/std/forward_list
index 3d3b6d4f5f6..9d6cc40593b 100644
--- a/libstdc++-v3/include/std/forward_list
+++ b/libstdc++-v3/include/std/forward_list
@@ -78,8 +78,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 erase(forward_list<_Tp, _Alloc>& __cont, const _Up& __value)
 {
   using __elem_type = typename forward_list<_Tp, _Alloc>::value_type;
-  return erase_if(__cont,
- [&](__elem_type& __elem) { return __elem == __value; });
+  return std::erase_if(__cont, [&](__elem_type& __elem) {
+ return __elem == __value;
+  });
 }
 _GLIBCXX_END_NAMESPACE_VERSION
 } // namespace std
diff --git a/libstdc++-v3/include/std/list b/libstdc++-v3/include/std/list
index 7b02e8685d4..8d6ac198c9a 100644
--- a/libstdc++-v3/include/std/list
+++ b/libstdc++-v3/include/std/list
@@ -102,8 +102,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 erase(list<_Tp, _Alloc>& __cont, const _Up& __value)
 {
   using __elem_type = typename list<_Tp, _Alloc>::value_type;
-  return erase_if(__cont,
- [&](__elem_type& __elem) { return __elem == __value; });
+  return std::erase_if(__cont, [&](__elem_type& __elem) {
+ return __elem == __value;
+  });
 }
 _GLIBCXX_END_NAMESPACE_VERSION
 } // namespace std

[PATCH] Fix tests that fail in C++2a mode

[Jonathan Wakely]

The nested typedefs in std::reference_wrapper are no longer present in
C++2a mode, so skip the tests that check for them.

The addition of the [[nodiscard]] attribute to a few functions causes
some failures in tests that intentionally ignore the return value.
Casting the result to void suppresses the new warnings.

* testsuite/20_util/reference_wrapper/result_type.cc: Disable for
C++2a.
* testsuite/20_util/reference_wrapper/typedefs-2.cc: Likewise.
* testsuite/20_util/reference_wrapper/typedefs-3.cc: Likewise.
* testsuite/20_util/reference_wrapper/typedefs.cc: Likewise.
* testsuite/30_threads/async/54297.cc: Suppress nodiscard warning.
* testsuite/ext/array_allocator/26875.cc: Likewise.
* testsuite/ext/pool_allocator/allocate_chunk.cc: Likewise.
* testsuite/util/replacement_memory_operators.h: Likewise.
* testsuite/util/testsuite_allocator.h: Likewise.

Tested x86_64-linux, committed to trunk.

commit 8669b5ad59b13d8112791f5dfbb046aa5ab092d2
Author: Jonathan Wakely 
Date:   Mon Jan 28 23:46:30 2019 +

Fix tests that fail in C++2a mode

The nested typedefs in std::reference_wrapper are no longer present in
C++2a mode, so skip the tests that check for them.

The addition of the [[nodiscard]] attribute to a few functions causes
some failures in tests that intentionally ignore the return value.
Casting the result to void suppresses the new warnings.

* testsuite/20_util/reference_wrapper/result_type.cc: Disable for
C++2a.
* testsuite/20_util/reference_wrapper/typedefs-2.cc: Likewise.
* testsuite/20_util/reference_wrapper/typedefs-3.cc: Likewise.
* testsuite/20_util/reference_wrapper/typedefs.cc: Likewise.
* testsuite/30_threads/async/54297.cc: Suppress nodiscard warning.
* testsuite/ext/array_allocator/26875.cc: Likewise.
* testsuite/ext/pool_allocator/allocate_chunk.cc: Likewise.
* testsuite/util/replacement_memory_operators.h: Likewise.
* testsuite/util/testsuite_allocator.h: Likewise.

diff --git a/libstdc++-v3/testsuite/20_util/reference_wrapper/result_type.cc 
b/libstdc++-v3/testsuite/20_util/reference_wrapper/result_type.cc
index 81b4986fb41..7c67283d2b9 100644
--- a/libstdc++-v3/testsuite/20_util/reference_wrapper/result_type.cc
+++ b/libstdc++-v3/testsuite/20_util/reference_wrapper/result_type.cc
@@ -1,4 +1,5 @@
 // { dg-do compile { target c++11 } }
+// { dg-skip-if "result_type removed for C++20" { c++2a } }
 
 // 2010-10-06  Paolo Carlini  
 
diff --git a/libstdc++-v3/testsuite/20_util/reference_wrapper/typedefs-2.cc 
b/libstdc++-v3/testsuite/20_util/reference_wrapper/typedefs-2.cc
index 5db372c82ba..e1aebd17352 100644
--- a/libstdc++-v3/testsuite/20_util/reference_wrapper/typedefs-2.cc
+++ b/libstdc++-v3/testsuite/20_util/reference_wrapper/typedefs-2.cc
@@ -1,4 +1,5 @@
 // { dg-do compile { target c++11 } }
+// { dg-skip-if "argument_type removed for C++20" { c++2a } }
 
 // 2010-10-06  Paolo Carlini  
 
diff --git a/libstdc++-v3/testsuite/20_util/reference_wrapper/typedefs-3.cc 
b/libstdc++-v3/testsuite/20_util/reference_wrapper/typedefs-3.cc
index 190fe91c13e..5ca596a10bc 100644
--- a/libstdc++-v3/testsuite/20_util/reference_wrapper/typedefs-3.cc
+++ b/libstdc++-v3/testsuite/20_util/reference_wrapper/typedefs-3.cc
@@ -1,4 +1,5 @@
 // { dg-do compile { target c++11 } }
+// { dg-skip-if "argument_type removed for C++20" { c++2a } }
 
 // Copyright (C) 2011-2019 Free Software Foundation, Inc.
 //
diff --git a/libstdc++-v3/testsuite/20_util/reference_wrapper/typedefs.cc 
b/libstdc++-v3/testsuite/20_util/reference_wrapper/typedefs.cc
index a17c1ede0a9..1f4c77eb006 100644
--- a/libstdc++-v3/testsuite/20_util/reference_wrapper/typedefs.cc
+++ b/libstdc++-v3/testsuite/20_util/reference_wrapper/typedefs.cc
@@ -1,4 +1,5 @@
 // { dg-do compile { target c++11 } }
+// { dg-skip-if "result_type removed for C++20" { c++2a } }
 
 // Copyright (C) 2008-2019 Free Software Foundation, Inc.
 //
diff --git a/libstdc++-v3/testsuite/30_threads/async/54297.cc 
b/libstdc++-v3/testsuite/30_threads/async/54297.cc
index 4a2d8fca698..654ce40f904 100644
--- a/libstdc++-v3/testsuite/30_threads/async/54297.cc
+++ b/libstdc++-v3/testsuite/30_threads/async/54297.cc
@@ -45,5 +45,5 @@ struct Task
 
 int main()
 {
-  std::async(std::launch::async, Task());
+  (void) std::async(std::launch::async, Task());
 }
diff --git a/libstdc++-v3/testsuite/ext/array_allocator/26875.cc 
b/libstdc++-v3/testsuite/ext/array_allocator/26875.cc
index d4cbb04d680..e72e3b2e0ef 100644
--- a/libstdc++-v3/testsuite/ext/array_allocator/26875.cc
+++ b/libstdc++-v3/testsuite/ext/array_allocator/26875.cc
@@ -33,8 +33,8 @@ int main()
 
   try
 {
-  Allocator1.allocate(1);
-  Allocator2.allocate(1);
+  (void) Allocator1.allocate(1);
+  (void) Allocator2.allocate(1);
 }
   catch (std::bad_alloc& ex)
   

[PATCH] Ensure pool resources always use normal mode vector

[Jonathan Wakely]

The __pool_resource::_M_unpooled member was declared with type
std::vector, which means that the type depends on whether debug mode is
active or not. Because the non-inline definitions in
src/c++17/memory_resource.cc are never compiled with debug mode, the
type declared in the header doesn't match the type in the library
definitions, leading to undefined behaviour.

The solution is to ensure the header always uses the non-debug vector,
even when debug mode is active. To make this easier a new alias template
is defined: _GLIBCXX_STD_C::pmr::vector.

* include/std/memory_resource (__pool_resource::_M_unpooled): Use
normal mode vector, even for debug mode.
* include/std/vector [_GLIBCXX_DEBUG] (_GLIBCXX_STD_C::pmr::vector):
Define alias template for normal mode vector.

Tested x86_64-linux, committed to trunk.


commit 88ea7aa5bcdfc98ead7f9ab5b01c8c58d482799c
Author: Jonathan Wakely 
Date:   Mon Jan 28 23:37:27 2019 +

Ensure pool resources always use normal mode vector

The __pool_resource::_M_unpooled member was declared with type
std::vector, which means that the type depends on whether debug mode is
active or not. Because the non-inline definitions in
src/c++17/memory_resource.cc are never compiled with debug mode, the
type declared in the header doesn't match the type in the library
definitions, leading to undefined behaviour.

The solution is to ensure the header always uses the non-debug vector,
even when debug mode is active. To make this easier a new alias template
is defined: _GLIBCXX_STD_C::pmr::vector.

* include/std/memory_resource (__pool_resource::_M_unpooled): Use
normal mode vector, even for debug mode.
* include/std/vector [_GLIBCXX_DEBUG] (_GLIBCXX_STD_C::pmr::vector):
Define alias template for normal mode vector.

diff --git a/libstdc++-v3/include/std/memory_resource 
b/libstdc++-v3/include/std/memory_resource
index 5573494b01f..93b2ebd9759 100644
--- a/libstdc++-v3/include/std/memory_resource
+++ b/libstdc++-v3/include/std/memory_resource
@@ -354,7 +354,7 @@ namespace pmr
 struct _BigBlock;
 // Collection of blocks too big for any pool, sorted by address.
 // This also stores the only copy of the upstream memory resource pointer.
-pmr::vector<_BigBlock> _M_unpooled;
+_GLIBCXX_STD_C::pmr::vector<_BigBlock> _M_unpooled;
 
 const int _M_npools;
   };
diff --git a/libstdc++-v3/include/std/vector b/libstdc++-v3/include/std/vector
index 2c90765b058..e5e13ab3ef7 100644
--- a/libstdc++-v3/include/std/vector
+++ b/libstdc++-v3/include/std/vector
@@ -89,6 +89,13 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 template
   using vector = std::vector<_Tp, polymorphic_allocator<_Tp>>;
   } // namespace pmr
+# ifdef _GLIBCXX_DEBUG
+  namespace _GLIBCXX_STD_C::pmr {
+template
+  using vector
+   = _GLIBCXX_STD_C::vector<_Tp, std::pmr::polymorphic_allocator<_Tp>>;
+  } // namespace _GLIBCXX_STD_C::pmr
+# endif
 _GLIBCXX_END_NAMESPACE_VERSION
 } // namespace std
 #endif // C++17

Re: [Patch] PR rtl-optimization/87763 - generate more bfi instructions on aarch64

[Jakub Jelinek]

On Tue, Jan 29, 2019 at 12:11:46AM +, Steve Ellcey wrote:
> > As mentioned in rs6000.md, I believe you also need a similar pattern where
> > the two ANDs are swapped, because they have the same priority.
> 
> I fixed the long lines in aarch64.md and I added a second pattern for
> the *aarch64_bfi4_noshift pattern, swapping the order of the
> IOR operands.  I did not swap the AND operands, I assume the compiler
> would ensure that the register was always before the constant or that
> it would check both orderings.

Yes, you can look at commutative_operand_precedence and
swap_commutative_operands_p.  The issue is just if 
commutative_operand_precedence
of both operands is equal (and that function doesn't recurse for
suboperands).

> I tried adding a second version of *aarch64_bfi5_shift as
> well but when I tested it, it never got used during a bootstrap build
> or a GCC test run so I decided it was not needed.

I'll try tomorrow if I can construct a testcase or not.

In any case, you want an aarch64 maintainer to ack this.

Thanks for working on this.

Jakub

Re: [Patch] PR rtl-optimization/87763 - generate more bfi instructions on aarch64

[Steve Ellcey]

On Sat, 2019-01-26 at 00:00 +0100, Jakub Jelinek wrote:
> 
> > +  /* Verify that there is no overlap in what bits are set in the two 
> > masks.  */
> > +  if ((m1 + m2 + 1) != 0)
> > +return false;
> 
> Wouldn't that be clearer to test
>   if (m1 + m2 != HOST_WIDE_INT_1U)
> return false;
> ?
> You IMHO also should test
>   if ((m1 & m2) != 0)
> return false;

I think you mean HOST_WIDE_INT_M1U, not HOST_WIDE_INT_1U.  That does
seem clearer and I made that change as well as adding the second test.

> > 
> > +  t = popcount_hwi (m2);
> > +  t = (1 << t) - 1;
> 
> This should be (HOST_WIDE_INT_1U << t), otherwise if popcount of m2 is
> > = 32, there will be UB.

Fixed.

> As mentioned in rs6000.md, I believe you also need a similar pattern where
> the two ANDs are swapped, because they have the same priority.

I fixed the long lines in aarch64.md and I added a second pattern for
the *aarch64_bfi4_noshift pattern, swapping the order of the
IOR operands.  I did not swap the AND operands, I assume the compiler
would ensure that the register was always before the constant or that
it would check both orderings.

I tried adding a second version of *aarch64_bfi5_shift as
well but when I tested it, it never got used during a bootstrap build
or a GCC test run so I decided it was not needed.

Tested on aarch64 with a bootstrap build and a GCC testsuite run.
OK to checkin?


Steve Ellcey
sell...@marvell.com


2018-01-28  Steve Ellcey  

PR rtl-optimization/87763
* config/aarch64/aarch64-protos.h (aarch64_masks_and_shift_for_bfi_p):
New prototype.
* config/aarch64/aarch64.c (aarch64_masks_and_shift_for_bfi_p):
New function.
* config/aarch64/aarch64.md (*aarch64_bfi5_shift):
New instruction.
(*aarch64_bfi4_noshift): Ditto.
(*aarch64_bfi4_noshift_alt): Ditto.


2018-01-28  Steve Ellcey  

PR rtl-optimization/87763
* gcc.target/aarch64/combine_bfxil.c: Change some bfxil checks
to bfi.


diff --git a/gcc/config/aarch64/aarch64-protos.h b/gcc/config/aarch64/aarch64-protos.h
index b035e35f33b..b6c0d0a8eb6 100644
--- a/gcc/config/aarch64/aarch64-protos.h
+++ b/gcc/config/aarch64/aarch64-protos.h
@@ -429,6 +429,9 @@ bool aarch64_label_mentioned_p (rtx);
 void aarch64_declare_function_name (FILE *, const char*, tree);
 bool aarch64_legitimate_pic_operand_p (rtx);
 bool aarch64_mask_and_shift_for_ubfiz_p (scalar_int_mode, rtx, rtx);
+bool aarch64_masks_and_shift_for_bfi_p (scalar_int_mode, unsigned HOST_WIDE_INT,
+	unsigned HOST_WIDE_INT,
+	unsigned HOST_WIDE_INT);
 bool aarch64_zero_extend_const_eq (machine_mode, rtx, machine_mode, rtx);
 bool aarch64_move_imm (HOST_WIDE_INT, machine_mode);
 opt_machine_mode aarch64_sve_pred_mode (unsigned int);
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index d7c453cdad0..9a3080b5db8 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -9330,6 +9330,41 @@ aarch64_mask_and_shift_for_ubfiz_p (scalar_int_mode mode, rtx mask,
 	 & ((HOST_WIDE_INT_1U << INTVAL (shft_amnt)) - 1)) == 0;
 }
 
+/* Return true if the masks and a shift amount from an RTX of the form
+   ((x & MASK1) | ((y << SHIFT_AMNT) & MASK2)) are valid to combine into
+   a BFI instruction of mode MODE.  See *arch64_bfi patterns.  */
+
+bool
+aarch64_masks_and_shift_for_bfi_p (scalar_int_mode mode,
+   unsigned HOST_WIDE_INT mask1,
+   unsigned HOST_WIDE_INT shft_amnt,
+   unsigned HOST_WIDE_INT mask2)
+{
+  unsigned HOST_WIDE_INT t;
+
+  /* Verify that there is no overlap in what bits are set in the two masks.  */
+  if ((mask1 + mask2) != HOST_WIDE_INT_M1U)
+return false;
+  if ((mask1 & mask2) != 0)
+return false;
+
+  /* Verify that the shift amount is less than the mode size.  */
+  if (shft_amnt >= GET_MODE_BITSIZE (mode))
+return false;
+
+  /* Verify that the mask being shifted is contiguous and would be in the
+ least significant bits after shifting by creating a mask 't' based on
+ the number of bits set in mask2 and the shift amount for mask2 and
+ comparing that to the actual mask2.  */
+  t = popcount_hwi (mask2);
+  t = (HOST_WIDE_INT_1U << t) - 1;
+  t = t << shft_amnt;
+  if (t != mask2)
+return false;
+  
+  return true;
+}
+
 /* Calculate the cost of calculating X, storing it in *COST.  Result
is true if the total cost of the operation has now been calculated.  */
 static bool
diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
index b7f6fe0f135..6b5339092ba 100644
--- a/gcc/config/aarch64/aarch64.md
+++ b/gcc/config/aarch64/aarch64.md
@@ -5476,6 +5476,56 @@
   [(set_attr "type" "bfm")]
 )
 
+;;  Match a bfi instruction where the shift of OP3 means that we are
+;;  actually copying the least significant bits of OP3 into OP0 by way
+;;  of the AND masks and the IOR instruction.  A similar instruction
+;;  with the two parts of the IOR swapped around was never triggered
+;;  in 

[PATCH] PR libstdc++/68737 Do not use vsnprintf on HPUX

[Jonathan Wakely]

It doesn't conform to the spec, so use vsprintf with a large buffer
instead.

PR libstdc++/68737
* config/locale/generic/c_locale.h (__convert_from_v)
[_GLIBCXX_USE_C99_STDIO]: Also check _GLIBCXX_HAVE_BROKEN_VSNPRINTF.
* config/os/hpux/os_defines.h: Define _GLIBCXX_HAVE_BROKEN_VSNPRINTF.
* include/bits/locale_facets.tcc (num_put::_M_insert_float)
[_GLIBCXX_USE_C99_STDIO]: Also check _GLIBCXX_HAVE_BROKEN_VSNPRINTF.

Tested powerpc64le-linux, committed to trunk.

commit f69cc2009670cea920dba01b0588f778a347e180
Author: Jonathan Wakely 
Date:   Mon Jan 28 23:34:32 2019 +

PR libstdc++/68737 Do not use vsnprintf on HPUX

It doesn't conform to the spec, so use vsprintf with a large buffer
instead.

PR libstdc++/68737
* config/locale/generic/c_locale.h (__convert_from_v)
[_GLIBCXX_USE_C99_STDIO]: Also check _GLIBCXX_HAVE_BROKEN_VSNPRINTF.
* config/os/hpux/os_defines.h: Define 
_GLIBCXX_HAVE_BROKEN_VSNPRINTF.
* include/bits/locale_facets.tcc (num_put::_M_insert_float)
[_GLIBCXX_USE_C99_STDIO]: Also check _GLIBCXX_HAVE_BROKEN_VSNPRINTF.

diff --git a/libstdc++-v3/config/locale/generic/c_locale.h 
b/libstdc++-v3/config/locale/generic/c_locale.h
index 3b95a43160e..625a61c8bb2 100644
--- a/libstdc++-v3/config/locale/generic/c_locale.h
+++ b/libstdc++-v3/config/locale/generic/c_locale.h
@@ -70,7 +70,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 __builtin_va_list __args;
 __builtin_va_start(__args, __fmt);
 
-#if _GLIBCXX_USE_C99_STDIO
+#if _GLIBCXX_USE_C99_STDIO && !_GLIBCXX_HAVE_BROKEN_VSNPRINTF
 const int __ret = __builtin_vsnprintf(__out, __size, __fmt, __args);
 #else
 const int __ret = __builtin_vsprintf(__out, __fmt, __args);
diff --git a/libstdc++-v3/config/os/hpux/os_defines.h 
b/libstdc++-v3/config/os/hpux/os_defines.h
index 04834b0cd0c..20a8b3ed30b 100644
--- a/libstdc++-v3/config/os/hpux/os_defines.h
+++ b/libstdc++-v3/config/os/hpux/os_defines.h
@@ -109,4 +109,9 @@ typedef long int __padding_type;
 #if defined (__hppa__)
 #define _GLIBCXX_HAVE_BROKEN_STRTOLD 1
 #endif
+
+// The vnsprintf function returns -1 when the buffer is too small.
+// See PR libstdc++/68737.
+#define _GLIBCXX_HAVE_BROKEN_VSNPRINTF 1
+
 #endif
diff --git a/libstdc++-v3/include/bits/locale_facets.tcc 
b/libstdc++-v3/include/bits/locale_facets.tcc
index c387fdfdbfb..2eb8167db9a 100644
--- a/libstdc++-v3/include/bits/locale_facets.tcc
+++ b/libstdc++-v3/include/bits/locale_facets.tcc
@@ -992,7 +992,7 @@ _GLIBCXX_BEGIN_NAMESPACE_LDBL
char __fbuf[16];
__num_base::_S_format_float(__io, __fbuf, __mod);
 
-#if _GLIBCXX_USE_C99_STDIO
+#if _GLIBCXX_USE_C99_STDIO && !_GLIBCXX_HAVE_BROKEN_VSNPRINTF
// Precision is always used except for hexfloat format.
const bool __use_prec =
  (__io.flags() & ios_base::floatfield) != ios_base::floatfield;

Re: [PATCH] [ARC] atomics: Add operand to DMB instruction

[Vineet Gupta]

On 1/20/19 8:19 AM, Claudiu Zissulescu wrote:
> Hi,
>> 2019-01-18  Vineet Gupta 
>>
>>* config/arc/atomic.md: Add operand to DMB instruction
>>
> This is ok. I'll push it asap,
> Claudiu

Thx, I see it merged into mainline. Can you please backport this to gcc-8-branch
as well ?

Thx,
-Vineet

Re: [C PATCH] Fix another compound literal ICE (PR c/89045)

[Joseph Myers]

On Mon, 28 Jan 2019, Jakub Jelinek wrote:

> Hi!
> 
> In this case, when a compound literal is in the parameter scope of a nested
> function, current_function_decl is non-NULL, but we still don't want to
> pushdecl it, as the code doesn't expect any VAR_DECLs etc. in parameter
> scope.
> 
> Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
> trunk?

OK.

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

Re: [PATCH] Add target-zlib to top-level configure, use zlib from libphobos

[Joseph Myers]

On Mon, 28 Jan 2019, Richard Biener wrote:

> On Mon, Jan 21, 2019 at 7:35 PM Iain Buclaw  wrote:
> >
> > Hi,
> >
> > Following on from the last, this adds target-zlib to target_libraries
> > and updates libphobos build scripts to link to libz_convenience.a.
> > The D front-end already has target-zlib in d/config-lang.in.
> >
> > Is the top-level part OK?  I considered disabling target-zlib if
> > libphobos is not being built, but decided against unless it's
> > requested.
> 
> Hmm, you overload --with-system-zlib to apply to both host and target
> (I guess it already applied to build), not sure if that's really desired?

I think it's best to keep this sort of option separate for host and 
target.

> You are also falling back to in-tree zlib if --with-system-zlib was
> specified but no zlib was found - I guess for cross builds that
> will easily get not noticed...  The toplevel --with-system-zlib makes
> it much harder and simply fails.

And I think failing is better if such an option is specified but zlib is 
not found.

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

Re: [C PATCH] Fix PR86125 fallout

[Joseph Myers]

On Sat, 26 Jan 2019, Jakub Jelinek wrote:

> Hi!
> 
> Here is an untested patch that should fix all of that, ok for trunk
> if it passes bootstrap/regtest on {x86_64,i686}-linux?

OK.

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

[libbacktrace] Don't assign check_PROGRAMS to TESTS

[Tom de Vries]

[ was: Re: [backtrace] Avoid segfault ]

On 27-01-19 22:16, Tom de Vries wrote:
> +# The file b2test_buildid is an objcopy of b2test, so these programs share 
> the
> +# same build-id.  The first time b2test is run, there's no corresponding 
> debug
> +# file at ./usr/lib/debug/.build-id/aa/bb..zz.debug.  The second time b2test 
> is
> +# run, the .debug file has been created for b2test_buildid, which is now 
> picked
> +# up by b2test as well.

I realized now that what I was looking at were the consequences of the
"TESTS = $(check_PROGRAMS)" setting in libbacktrace/Makefile.am, which
forces b2test to be run, even though I specify just "check_PROGRAMS +=
b2test".

This patch undoes that setting, and introduces a variable BUILDTESTS to
indicate that a test needs to be both build and run.

OK for trunk?

Thanks,
- Tom
[libbacktrace] Don't assign check_PROGRAMS to TESTS

In automake files, the check_PROGRAMS variable lists programs that need to be
build for testing, and TESTS lists the programs that need to be run.

The libbacktrace/Makefile.am uses a shortcut:
...
TESTS = $(check_PROGRAMS)
...
to make sure that each program added with:
...
check_PROGRAMS += foo
...
is both build and run.

However, for the allocfail.sh test, we need allocfail to be build and
allocfail.sh to be run:
...
check_PROGRAMS += allocfail
TESTS += allocfail.sh
...
but the shortcut causes allocfail also to be run, which is not required.

Fix this by removing the short-cut, allowing check_PROGRAMS to retain its
original semantics, and introducing a variable BUILDTESTS for programs that
need to be both build and run.

2019-01-28  Tom de Vries  

	* Makefile.am: Replace check_PROGRAMS with BUILDTESTS, except for
	allocfail.
	(TESTS): Don't add check_PROGRAMS. Add BUILDTESTS.
	(check_PROGRAMS): Add BUILDTESTS.
	* Makefile.in: Regenerate.

---
 libbacktrace/Makefile.am |  49 +++-
 libbacktrace/Makefile.in | 113 +++
 2 files changed, 85 insertions(+), 77 deletions(-)

diff --git a/libbacktrace/Makefile.am b/libbacktrace/Makefile.am
index 997a535dff4..a038234897a 100644
--- a/libbacktrace/Makefile.am
+++ b/libbacktrace/Makefile.am
@@ -84,9 +84,14 @@ libbacktrace_la_DEPENDENCIES = $(libbacktrace_la_LIBADD)
 
 # Testsuite.
 
+# Add test to this variable, if you want it to be build.
 check_PROGRAMS =
 
-TESTS = $(check_PROGRAMS)
+# Add test to this variable, if you want it to be run.
+TESTS =
+
+# Add test to this variable, if you want it to be build and run.
+BUILDTESTS =
 
 if NATIVE
 check_LTLIBRARIES = libbacktrace_alloc.la
@@ -114,37 +119,37 @@ xcoff_%.c: xcoff.c
 test_elf_SOURCES = test_format.c testlib.c
 test_elf_LDADD = libbacktrace_noformat.la elf.lo
 
-check_PROGRAMS += test_elf
+BUILDTESTS += test_elf
 
 test_xcoff_32_SOURCES = test_format.c testlib.c
 test_xcoff_32_LDADD = libbacktrace_noformat.la xcoff_32.lo
 
-check_PROGRAMS += test_xcoff_32
+BUILDTESTS += test_xcoff_32
 
 test_xcoff_64_SOURCES = test_format.c testlib.c
 test_xcoff_64_LDADD = libbacktrace_noformat.la xcoff_64.lo
 
-check_PROGRAMS += test_xcoff_64
+BUILDTESTS += test_xcoff_64
 
 test_pecoff_SOURCES = test_format.c testlib.c
 test_pecoff_LDADD = libbacktrace_noformat.la pecoff.lo
 
-check_PROGRAMS += test_pecoff
+BUILDTESTS += test_pecoff
 
 test_unknown_SOURCES = test_format.c testlib.c
 test_unknown_LDADD = libbacktrace_noformat.la unknown.lo
 
-check_PROGRAMS += test_unknown
+BUILDTESTS += test_unknown
 
 unittest_SOURCES = unittest.c testlib.c
 unittest_LDADD = libbacktrace.la
 
-check_PROGRAMS += unittest
+BUILDTESTS += unittest
 
 unittest_alloc_SOURCES = $(unittest_SOURCES)
 unittest_alloc_LDADD = libbacktrace_alloc.la
 
-check_PROGRAMS += unittest_alloc
+BUILDTESTS += unittest_alloc
 
 check_LTLIBRARIES += libbacktrace_instrumented_alloc.la
 
@@ -170,13 +175,13 @@ btest_SOURCES = btest.c testlib.c
 btest_CFLAGS = $(AM_CFLAGS) -g -O
 btest_LDADD = libbacktrace.la
 
-check_PROGRAMS += btest
+BUILDTESTS += btest
 
 btest_alloc_SOURCES = $(btest_SOURCES)
 btest_alloc_CFLAGS = $(btest_CFLAGS)
 btest_alloc_LDADD = libbacktrace_alloc.la
 
-check_PROGRAMS += btest_alloc
+BUILDTESTS += btest_alloc
 
 if HAVE_DWZ
 
@@ -201,12 +206,12 @@ endif HAVE_DWZ
 stest_SOURCES = stest.c
 stest_LDADD = libbacktrace.la
 
-check_PROGRAMS += stest
+BUILDTESTS += stest
 
 stest_alloc_SOURCES = $(stest_SOURCES)
 stest_alloc_LDADD = libbacktrace_alloc.la
 
-check_PROGRAMS += stest_alloc
+BUILDTESTS += stest_alloc
 
 ztest_SOURCES = ztest.c testlib.c
 ztest_CFLAGS = -DSRCDIR=\"$(srcdir)\"
@@ -220,22 +225,22 @@ endif
 ztest_LDADD += $(CLOCK_GETTIME_LINK)
 ztest_alloc_LDADD += $(CLOCK_GETTIME_LINK)
 
-check_PROGRAMS += ztest
+BUILDTESTS += ztest
 
 ztest_alloc_SOURCES = $(ztest_SOURCES)
 ztest_alloc_CFLAGS = $(ztest_CFLAGS)
 
-check_PROGRAMS += ztest_alloc
+BUILDTESTS += ztest_alloc
 
 edtest_SOURCES = edtest.c edtest2_build.c testlib.c
 edtest_LDADD = libbacktrace.la
 
-check_PROGRAMS += edtest
+BUILDTESTS += edtest
 
 

[committed] Fix lastprivate gimplification in taskloop (PR middle-end/89002)

[Jakub Jelinek]

Hi!

When gimplifying lastprivate or linear clause with non-NULL
OMP_CLAUSE_*_STMT, we wrap it into a BIND_EXPR and push temporaries there,
but I haven't done that when we are adding that only during gimplification
for the loop's IV.  For worksharing loop or distribute or simd it isn't
that big deal, because either there is no outlining of the corresponding
code, or it is through outer parallel, teams etc. so the temporaries end up
there.  But, in the case of taskloop, there is always outlining and so we
need to make sure the temporaries are in the right spot.

Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
committed to trunk (so far).

2019-01-28  Jakub Jelinek  

PR middle-end/89002
* gimplify.c (gimplify_omp_for): When adding OMP_CLAUSE_*_GIMPLE_SEQ
for lastprivate/linear IV, push gimplify context around gimplify_assign
and, if it needed any temporaries, pop it into a gimple bind around the
sequence.

* testsuite/libgomp.c/pr89002.c: New test.

--- gcc/gimplify.c.jj   2019-01-22 23:27:56.0 +0100
+++ gcc/gimplify.c  2019-01-28 17:32:58.149683211 +0100
@@ -11167,8 +11167,17 @@ gimplify_omp_for (tree *expr_p, gimple_s
  seq = _CLAUSE_LASTPRIVATE_GIMPLE_SEQ (c);
else
  seq = _CLAUSE_LINEAR_GIMPLE_SEQ (c);
+   push_gimplify_context ();
gimplify_assign (decl, t, seq);
-   }
+   gimple *bind = NULL;
+   if (gimplify_ctxp->temps)
+ {
+   bind = gimple_build_bind (NULL_TREE, *seq, NULL_TREE);
+   *seq = NULL;
+   gimplify_seq_add_stmt (seq, bind);
+ }
+   pop_gimplify_context (bind);
+ }
}
 }
 
--- libgomp/testsuite/libgomp.c/pr89002.c.jj2019-01-28 17:49:47.791086171 
+0100
+++ libgomp/testsuite/libgomp.c/pr89002.c   2019-01-28 17:49:17.836600273 
+0100
@@ -0,0 +1,43 @@
+/* PR middle-end/89002 */
+
+extern void abort (void);
+
+int
+foo (int x)
+{
+  int a;
+  int *p = 
+
+#pragma omp taskloop lastprivate (a)
+  for (a = 0; a < x; ++a)
+;
+  return *p;
+}
+
+int
+bar (int x)
+{
+  int a;
+  int *p = 
+
+#pragma omp parallel
+#pragma omp single
+#pragma omp taskloop lastprivate (a)
+  for (a = 0; a < x; ++a)
+;
+  return *p;
+}
+
+int
+main ()
+{
+#pragma omp parallel
+#pragma omp single
+  {
+if (foo (4) != 4)
+  abort ();
+  }
+  if (bar (6) != 6)
+abort ();
+  return 0;
+}

Jakub

Go patch committed: Avoid compiler crash in recursive type detection

[Ian Lance Taylor]

This patch by Ben Shi fixes the Go frontend to avoid crashing when
handling a recursive type definition like

type T0 T1; type T1 T2; .. type Tn T0

This fixes https://golang.org/issue/25320.

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

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 268230)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-d67c4bf0c42b79d54925ba8c5f23278ee6c3efb6
+5ccb2d8593963e06ec3a35d362b384e82301d9f0
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: gcc/go/gofrontend/types.cc
===
--- gcc/go/gofrontend/types.cc  (revision 268158)
+++ gcc/go/gofrontend/types.cc  (working copy)
@@ -10259,6 +10259,15 @@ Find_type_use::type(Type* type)
  break;
 
case Type::TYPE_NAMED:
+  if (type->named_type() == type->base()->named_type())
+{
+  this->found_ = true;
+  return TRAVERSE_EXIT;
+}
+  else
+   go_assert(saw_errors());
+   break;
+
case Type::TYPE_FORWARD:
  go_assert(saw_errors());
  break;

[C PATCH] Fix another compound literal ICE (PR c/89045)

[Jakub Jelinek]

Hi!

In this case, when a compound literal is in the parameter scope of a nested
function, current_function_decl is non-NULL, but we still don't want to
pushdecl it, as the code doesn't expect any VAR_DECLs etc. in parameter
scope.

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

2019-01-28  Jakub Jelinek  

PR c/89045
* c-decl.c (build_compound_literal): Don't pushdecl if in parameter
scope.

* gcc.dg/pr89045.c: New test.

--- gcc/c/c-decl.c.jj   2019-01-27 12:55:16.714550950 +0100
+++ gcc/c/c-decl.c  2019-01-28 15:36:29.579811998 +0100
@@ -5512,7 +5512,7 @@ build_compound_literal (location_t loc,
   pushdecl (decl);
   rest_of_decl_compilation (decl, 1, 0);
 }
-  else if (current_function_decl)
+  else if (current_function_decl && !current_scope->parm_flag)
 pushdecl (decl);
 
   if (non_const)
--- gcc/testsuite/gcc.dg/pr89045.c.jj   2019-01-28 15:41:16.623104584 +0100
+++ gcc/testsuite/gcc.dg/pr89045.c  2019-01-28 15:43:18.333108582 +0100
@@ -0,0 +1,15 @@
+/* PR c/89045 */
+/* { dg-do compile } */
+/* { dg-options "" } */
+
+int
+foo (int x)
+{
+  int v[(int){ x }];
+  v[0] = 0;
+  int bar (int p[(int){ x }])
+  {
+return p[0];
+  }
+  return bar (v);
+}

Jakub

Re: [libbacktrace] Add gen-xcoff-n.sh

[Ian Lance Taylor]

On Mon, Jan 28, 2019 at 2:24 AM Tom de Vries  wrote:
>
> [ was: Re: [libbacktrace] Fix and simplify xcoff_%.c pattern rule ]
>
> On 28-01-19 10:25, Tom de Vries wrote:
> > [ was: Re: [backtrace] Avoid segfault  ]
> > On 27-01-19 22:53, Ian Lance Taylor wrote:
> >> On Sun, Jan 27, 2019 at 1:16 PM Tom de Vries  wrote:
> >>>
> >>> On 25-01-19 18:15, Nathan Sidwell wrote:
>  On 1/25/19 5:28 AM, Tom de Vries wrote:
> >
> > This patch fixes it by passing "" instead of NULL, in the call to
> > elf_add at line 3083 (for .gnu_debugaltlink), not the call to elf_add at
> > line 3044 (for .gnu_debuglink) mentioned above.
> >
> > Nathan, does this fix the problem for you? If not, can you provide a
> > reproducer, or give a hint on how one could be constructed?
> 
>  I still hit the problem, and am installing this as sufficiently obvious.
>   I'm on a fedora system debugging pr88995.  The debuglink_name is
>  "../../.dwz/isl-0.16.1-7.fc29.x86_64"
> 
> >>>
> >>> I've managed to reproduce this segfault instance by adding a test-case
> >>> that uses both build-id and dwz.
> >>>
> >>> OK for trunk?
> >>
> >>> +elf_for_test.c: elf.c
> >>> + PWD=$$(pwd -P); \
> >>> + BUILD_ID_DIR="usr/lib/debug/.build-id/"; \
> >>> + SEARCH='#define SYSTEM_BUILD_ID_DIR'; \
> >>> + REPLACE="#define SYSTEM_BUILD_ID_DIR \"$$PWD/$$BUILD_ID_DIR\""; \
> >>> + $(SED) "s%^$$SEARCH.*\$$%$$REPLACE%" \
> >>> + $< \
> >>> + > $@
> >>
> >> You need to use a temporary file, such as $@.tmp, for the final sed
> >> command, followed by a mv to $@.  Otherwise a failure in the sed will
> >> leave what appears to be an up to date file.
> >
> > I noticed the same problem in the xcoff_%.c pattern rule.
> >
>
> And looking over the rule again, I wondered if it would be more readable
> if split off into a separate script file.
>
> Is this follow-up patch OK for trunk?

I guess for this case I think it's OK to keep the lines in the Makefile.

Ian

Re: [PATCH, gotools]: Really regenerate Makefile.in

[Ian Lance Taylor]

On Sun, Jan 27, 2019 at 11:50 PM Uros Bizjak  wrote:
>
> Recent commit increased GOTOOLS_TEST_TIMEOUT in Makefile.am, but
> forgot to update Makefile.in. Fix the omission.
>
> 2019-01-28  Uroš Bizjak  
>
> * Makefile.in: Really regenerate.
>
> Tested on x86_64-linux-gnu.

Whoops, thanks.

Ian

Re: C++ PATCH for c++/88358 - name wrongly treated as type

[Jason Merrill]

On 1/28/19 3:35 PM, Marek Polacek wrote:

This is a further fix for P0634.  When we have

   template 
   int foo(T::bar);

we shouldn't assume that T::bar is a type because this isn't one of the
contexts specified by P0634 -- for that, the function name would have to
be qualified.  So this patch refines my earlier fix.  I should've realized
it before, but here we are.

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


OK.

Jason

Re: C++ PATCH for c++/89024 - ICE with incomplete enum type

[Jason Merrill]

On 1/28/19 12:29 PM, Marek Polacek wrote:

On Mon, Jan 28, 2019 at 11:55:21AM -0500, Jason Merrill wrote:

The new test fails on arm-eabi (with newlib, but passes on on arm*linux*):
FAIL: g++.dg/cpp0x/enum37.C  -std=c++14 (test for excess errors)
FAIL: g++.dg/cpp0x/enum37.C  -std=c++17 (test for excess errors)

The log says:
/gcc/testsuite/g++.dg/cpp0x/enum37.C:24:41: error: aggregate
'same s2' has incomplete type and cannot
be defined


I imagine that this is because arm-eabi defaults to -fshort-enums; you
can check for this in the testsuite with { target short_enums }.


Indeed, I wasn't aware of this.


Clearly the additional checking I added won't fly; Jason, can I commit
this?

Tested on x86_64-linux, ok for trunk?

2019-01-28  Marek Polacek  

 * g++.dg/cpp0x/enum37.C: Remove a check.


I'd prefer to make the check conditional.


In which case, this.  I think it's better than making the whole test
conditional on short_enums.

Tested on x86_64-linux, ok for trunk?

2019-01-28  Marek Polacek  

* g++.dg/cpp0x/enum37.C: Add dg-error.

diff --git gcc/testsuite/g++.dg/cpp0x/enum37.C 
gcc/testsuite/g++.dg/cpp0x/enum37.C
index 6aa3d4015d7..b67720d5ea0 100644
--- gcc/testsuite/g++.dg/cpp0x/enum37.C
+++ gcc/testsuite/g++.dg/cpp0x/enum37.C
@@ -21,4 +21,4 @@ enum E {
  };
  
  same s;

-same s2;
+same s2; // { dg-error "incomplete type" "" 
{ target short_enums } }



OK.

Jason

[og8] Add user-friendly diagnostics for OpenACC loop parallelism assigned

[Thomas Schwinge]

Hi!

On Fri, 14 Dec 2018 22:03:26 +0100, I wrote:
> On Thu, 26 Jul 2018 07:14:21 -0700, Cesar Philippidis 
>  wrote:
> > [...]
> 
> I further changed that to make it build ;-) at all, and also emit
> diagnostics for OpenACC kernels constructs, and also added considerably
> more testsuite coverage.
> 
> Committed to trunk in r267146:
> 
> commit 75180da2a558d3106e26173326933f65b417182c
> Author: tschwinge 
> Date:   Fri Dec 14 20:41:58 2018 +
> 
> Add user-friendly diagnostics for OpenACC loop parallelism assigned

Backported my changes to openacc-gcc-8-branch, see attached.


Grüße
 Thomas


>From 010a7a9220c55c6bdf803617c72ed912a790267c Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Wed, 23 Jan 2019 15:22:58 +0100
Subject: [PATCH] Add user-friendly diagnostics for OpenACC loop parallelism
 assigned

Backport changes from trunk r267146.

	gcc/
	* omp-offload.c (inform_oacc_loop, execute_oacc_device_lower):
	Update.
	gcc/testsuite/
	* c-c++-common/goacc/classify-kernels-unparallelized.c: Update.
	* c-c++-common/goacc/classify-kernels.c: Likewise.
	* c-c++-common/goacc/classify-parallel.c: Likewise.
	* c-c++-common/goacc/classify-routine.c: Likewise.
	* c-c++-common/goacc/kernels-1.c: Likewise.
	* c-c++-common/goacc/kernels-double-reduction-n.c: Likewise.
	* c-c++-common/goacc/kernels-double-reduction.c: Likewise.
	* c-c++-common/goacc/loop-auto-3.c: Likewise.
	* c-c++-common/goacc/note-parallelism.c: Likewise.
	* c-c++-common/goacc/orphan-reductions-2.c: Likewise.
	* gcc.target/nvptx/oacc-autopar.c: Likewise.
	* gfortran.dg/goacc/classify-kernels-unparallelized.f95: Likewise.
	* gfortran.dg/goacc/classify-kernels.f95: Likewise.
	* gfortran.dg/goacc/classify-parallel.f95: Likewise.
	* gfortran.dg/goacc/classify-routine.f95: Likewise.
	* gfortran.dg/goacc/kernels-loop-inner.f95: Likewise.
	* gfortran.dg/goacc/loop-auto-1.f90: Likewise.
	* gfortran.dg/goacc/note-parallelism.f90: Likewise.
	* gfortran.dg/goacc/orphan-reductions-2.f90: Likewise.
---
 gcc/ChangeLog.openacc |   5 +
 gcc/omp-offload.c |  51 ++---
 gcc/testsuite/ChangeLog.openacc   |  22 
 .../goacc/classify-kernels-unparallelized.c   |   3 +-
 .../c-c++-common/goacc/classify-kernels.c |   3 +-
 .../c-c++-common/goacc/classify-parallel.c|   3 +-
 .../c-c++-common/goacc/classify-routine.c |   3 +-
 gcc/testsuite/c-c++-common/goacc/kernels-1.c  |  10 +-
 .../goacc/kernels-double-reduction-n.c|   3 +-
 .../goacc/kernels-double-reduction.c  |   3 +-
 .../c-c++-common/goacc/loop-auto-3.c  |  48 -
 .../c-c++-common/goacc/note-parallelism.c |  86 ---
 .../c-c++-common/goacc/orphan-reductions-2.c  |  26 ++---
 gcc/testsuite/gcc.target/nvptx/oacc-autopar.c |  54 +-
 .../goacc/classify-kernels-unparallelized.f95 |   3 +-
 .../gfortran.dg/goacc/classify-kernels.f95|   3 +-
 .../gfortran.dg/goacc/classify-parallel.f95   |   3 +-
 .../gfortran.dg/goacc/classify-routine.f95|   3 +-
 .../gfortran.dg/goacc/kernels-loop-inner.f95  |   3 +-
 .../gfortran.dg/goacc/loop-auto-1.f90 |  48 -
 .../gfortran.dg/goacc/note-parallelism.f90| 101 +++---
 .../gfortran.dg/goacc/orphan-reductions-2.f90 |  26 ++---
 22 files changed, 346 insertions(+), 164 deletions(-)

diff --git a/gcc/ChangeLog.openacc b/gcc/ChangeLog.openacc
index 22cdb5ba753..28d60da45b2 100644
--- a/gcc/ChangeLog.openacc
+++ b/gcc/ChangeLog.openacc
@@ -1,3 +1,8 @@
+2019-01-28  Thomas Schwinge  
+
+	* omp-offload.c (inform_oacc_loop, execute_oacc_device_lower):
+	Update.
+
 2019-01-09  Julian Brown  
 
 	* doc/invoke.texi: Update mention of OpenACC version to 2.6.
diff --git a/gcc/omp-offload.c b/gcc/omp-offload.c
index d428c6fdb62..60a85cba613 100644
--- a/gcc/omp-offload.c
+++ b/gcc/omp-offload.c
@@ -873,7 +873,7 @@ dump_oacc_loop_part (FILE *file, gcall *from, int depth,
 }
 }
 
-/* Dump OpenACC loops LOOP, its siblings and its children.  */
+/* Dump OpenACC loop LOOP, its children, and its siblings.  */
 
 static void
 dump_oacc_loop (FILE *file, oacc_loop *loop, int depth)
@@ -916,23 +916,22 @@ debug_oacc_loop (oacc_loop *loop)
   dump_oacc_loop (stderr, loop, 0);
 }
 
-/* Provide diagnostics on OpenACC loops LOOP, its siblings and its
-   children.  */
+/* Provide diagnostics on OpenACC loop LOOP, its children, and its
+   siblings.  */
 
 static void
-inform_oacc_loop (oacc_loop *loop)
+inform_oacc_loop (const oacc_loop *loop)
 {
+  const char *gang
+= loop->mask & GOMP_DIM_MASK (GOMP_DIM_GANG) ? " gang" : "";
+  const char *worker
+= loop->mask & GOMP_DIM_MASK (GOMP_DIM_WORKER) ? " worker" : "";
+  const char *vector
+= loop->mask & GOMP_DIM_MASK (GOMP_DIM_VECTOR) ? " vector" : "";
   const char *seq = loop->mask == 0 ? " seq" : "";
-  const char *gang = loop->mask & GOMP_DIM_MASK (GOMP_DIM_GANG)
-? " gang" : "";
-  const char *worker = loop->mask & GOMP_DIM_MASK (GOMP_DIM_WORKER)
-? " 

Re: [PATCH v3 09/10] Ignore LLVM's blank lines.

[H.J. Lu]

On Wed, Dec 12, 2018 at 3:55 AM Andrew Stubbs  wrote:
>
>
> [Already approved by Jeff Law. Included here for completeness.]
>
> The GCN toolchain must use the LLVM assembler and linker because there's no
> binutils port.  The LLVM tools do not have the same diagnostic style as
> binutils, so the "blank line(s) in output" tests are inappropriate (and very
> noisy).
>
> The LLVM tools also have different command line options, so it's not possible
> to autodetect object formats in the same way.
>
> This patch addresses both issues.
>
> 2018-12-12  Andrew Stubbs  
>
> gcc/testsuite/
> * lib/file-format.exp (gcc_target_object_format): Handle AMD GCN.
> * lib/gcc-dg.exp (gcc-dg-prune): Ignore blank lines from the LLVM
> linker.
> * lib/target-supports.exp (check_effective_target_llvm_binutils): New.
> ---
>  gcc/testsuite/lib/file-format.exp |  3 +++
>  gcc/testsuite/lib/gcc-dg.exp  |  2 +-
>  gcc/testsuite/lib/target-supports.exp | 15 +++
>  3 files changed, 19 insertions(+), 1 deletion(-)
>

Why do we have to call check_effective_target_offload_gcn over and over:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89095

Do we expect different answer between calls?

-- 
H.J.

C++ PATCH for c++/88358 - name wrongly treated as type

[Marek Polacek]

This is a further fix for P0634.  When we have

  template 
  int foo(T::bar);

we shouldn't assume that T::bar is a type because this isn't one of the
contexts specified by P0634 -- for that, the function name would have to
be qualified.  So this patch refines my earlier fix.  I should've realized
it before, but here we are.

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

2019-01-28  Marek Polacek  

PR c++/88358 - name wrongly treated as type.
* parser.c (cp_parser_direct_declarator): Don't assume a qualified-id
in parameter-list is a type if the function's declarator-id is not
qualified.

* g++.dg/cpp2a/typename1.C: Add dg-error.
* g++.dg/cpp2a/typename13.C: New test.
* g++.dg/cpp2a/typename6.C: Make a function name qualified.
Add typename.

diff --git gcc/cp/parser.c gcc/cp/parser.c
index dc9d651308a..16f2a32bc0b 100644
--- gcc/cp/parser.c
+++ gcc/cp/parser.c
@@ -21107,23 +21107,28 @@ cp_parser_direct_declarator (cp_parser* parser,
if (cxx_dialect >= cxx2a
&& (flags & CP_PARSER_FLAGS_TYPENAME_OPTIONAL)
&& declarator->kind == cdk_id
-   /* ...whose declarator-id is qualified.  */
-   && qualifying_scope != NULL_TREE
&& !at_class_scope_p ()
&& cp_lexer_next_token_is (parser->lexer, CPP_OPEN_PAREN))
  {
-   /* Now we have something like
-  template  int C::x(S::p);
-  which can be a function template declaration or a
-  variable template definition.  If name lookup for
-  the declarator-id C::x finds one or more function
-  templates, assume S::p to name a type.  Otherwise,
-  don't.  */
-   tree decl
- = cp_parser_lookup_name_simple (parser, unqualified_name,
- token->location);
-   if (!is_overloaded_fn (decl))
+   /* ...whose declarator-id is qualified.  If it isn't, never
+  assume the parameters to refer to types.  */
+   if (qualifying_scope == NULL_TREE)
  flags &= ~CP_PARSER_FLAGS_TYPENAME_OPTIONAL;
+   else
+ {
+   /* Now we have something like
+  template  int C::x(S::p);
+  which can be a function template declaration or a
+  variable template definition.  If name lookup for
+  the declarator-id C::x finds one or more function
+  templates, assume S::p to name a type.  Otherwise,
+  don't.  */
+   tree decl
+ = cp_parser_lookup_name_simple (parser, unqualified_name,
+ token->location);
+   if (!is_overloaded_fn (decl))
+ flags &= ~CP_PARSER_FLAGS_TYPENAME_OPTIONAL;
+ }
  }
  }
 
diff --git gcc/testsuite/g++.dg/cpp2a/typename1.C 
gcc/testsuite/g++.dg/cpp2a/typename1.C
index 833d3b86093..0c1f6309c5b 100644
--- gcc/testsuite/g++.dg/cpp2a/typename1.C
+++ gcc/testsuite/g++.dg/cpp2a/typename1.C
@@ -6,7 +6,7 @@ template T::R f();
 
 // Ill-formed (no diagnostic required), attempt to declare
 // a void variable template
-template void f(T::R);
+template void f(T::R); // { dg-error "declared void" }
 
 template  struct A;
 template  using B = A::U;
diff --git gcc/testsuite/g++.dg/cpp2a/typename13.C 
gcc/testsuite/g++.dg/cpp2a/typename13.C
new file mode 100644
index 000..c439f726c5d
--- /dev/null
+++ gcc/testsuite/g++.dg/cpp2a/typename13.C
@@ -0,0 +1,13 @@
+// P0634R3, PR c++/88358
+// { dg-do compile { target c++2a } }
+
+template 
+int pi(T::your_pi);
+
+struct Foo { static constexpr int your_pi = 10; };
+
+int
+main ()
+{
+  return pi;
+}
diff --git gcc/testsuite/g++.dg/cpp2a/typename6.C 
gcc/testsuite/g++.dg/cpp2a/typename6.C
index 49e2235a53d..e96e2ab802c 100644
--- gcc/testsuite/g++.dg/cpp2a/typename6.C
+++ gcc/testsuite/g++.dg/cpp2a/typename6.C
@@ -55,11 +55,14 @@ struct S2 {
 // (5.2.4) parameter-declaration in a declarator of a function or function
 // template declaration whose declarator-id is qualified,
 // unless that parameter-declaration appears in a default argument
-template
-int fn3 (T::X);
+
+struct M {
+  template
+  int fn (T::X);
+};
 
 template
-int fn4 (T::X p) { return p; }
+int M::fn (T::X p) { return p; }
 
 // (5.2.5) parameter-declaration in a lambda-declarator,
 // unless that parameter-declaration appears in a default argument
@@ -92,7 +95,7 @@ struct S5 {
 };
 
 template
-void fn7 (T::X p)
+void fn7 (typename T::X p)
 {
   int i = static_cast(p);
   i = dynamic_cast(p);

Re: [PATCH, OpenACC] Remove spurious OpenACC error on combining "auto" with gang/worker/vector

[Thomas Schwinge]

Hi Gergő!

On Fri, 25 Jan 2019 15:18:56 +0100, Gergö Barany  wrote:
> On OpenACC loop constructs, it is OK according to the OpenACC spec to 
> have both the "auto" clause and one or more of the "gang", "worker", or 
> "vector" clauses. GCC emits errors for this combination; this patch 
> eliminates that error.

Right.  As I'd mentioned internally, there might be more such things to
be fixed, which we shall re-visit later.  That said, your change is valid
as is, so...

> OK for openacc-gcc-8-branch?

OK.


Grüße
 Thomas


> From d8e7f1826d423de05e11afcb6e422ccaced0f6ea Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Gerg=C3=B6=20Barany?= 
> Date: Wed, 23 Jan 2019 03:10:07 -0800
> Subject: [PATCH] Remove spurious OpenACC error on combining "auto" with
>  gang/worker/vector
> 
> gcc/
> * omp-low.c (check_oacc_kernel_gwv): Remove spurious error message.
> * omp-offload.c (oacc_loop_fixed_partitions): Likewise.
> 
> gcc/testsuite/
> * c-c++-common/goacc/combined-directives-3.c: Adjust test.
> * c-c++-common/goacc/loop-2-kernels.c: Likewise.
> * c-c++-common/goacc/loop-2-parallel.c: Likewise.
> ---
>  gcc/ChangeLog.openacc|  5 +
>  gcc/omp-low.c|  3 ---
>  gcc/omp-offload.c|  7 ++-
>  gcc/testsuite/ChangeLog.openacc  |  6 ++
>  gcc/testsuite/c-c++-common/goacc/combined-directives-3.c |  4 ++--
>  gcc/testsuite/c-c++-common/goacc/loop-2-kernels.c| 12 ++--
>  gcc/testsuite/c-c++-common/goacc/loop-2-parallel.c   | 12 ++--
>  7 files changed, 27 insertions(+), 22 deletions(-)
> 
> diff --git a/gcc/ChangeLog.openacc b/gcc/ChangeLog.openacc
> index 932fb37..f3c741c 100644
> --- a/gcc/ChangeLog.openacc
> +++ b/gcc/ChangeLog.openacc
> @@ -1,5 +1,10 @@
>  2019-01-24  Gergö Barany  
>  
> + * omp-low.c (check_oacc_kernel_gwv): Remove spurious error message.
> + * omp-offload.c (oacc_loop_fixed_partitions): Likewise.
> +
> +2019-01-24  Gergö Barany  
> +
>   * gimplify.c (oacc_default_clause): Refactor and unify computation of
>   default mapping clauses.
>  
> diff --git a/gcc/omp-low.c b/gcc/omp-low.c
> index 72b6548..f48002e 100644
> --- a/gcc/omp-low.c
> +++ b/gcc/omp-low.c
> @@ -2397,9 +2397,6 @@ check_oacc_kernel_gwv (gomp_for *stmt, omp_context *ctx)
>if (has_seq && (this_mask || has_auto))
>   error_at (gimple_location (stmt), "% overrides other"
> " OpenACC loop specifiers");
> -  else if (has_auto && this_mask)
> - error_at (gimple_location (stmt), "% conflicts with other"
> -   " OpenACC loop specifiers");
>  
>if (this_mask & outer_mask)
>   error_at (gimple_location (stmt), "inner loop uses same"
> diff --git a/gcc/omp-offload.c b/gcc/omp-offload.c
> index d428c6f..57a7a06 100644
> --- a/gcc/omp-offload.c
> +++ b/gcc/omp-offload.c
> @@ -1211,14 +1211,11 @@ oacc_loop_fixed_partitions (oacc_loop *loop, unsigned 
> outer_mask)
>bool maybe_auto
>   = !seq_par && this_mask == (tiling ? this_mask & -this_mask : 0);
>  
> -  if ((this_mask != 0) + auto_par + seq_par > 1)
> +  if (seq_par && (this_mask != 0 || auto_par))
>   {
> if (noisy)
>   error_at (loop->loc,
> -   seq_par
> -   ? G_("% overrides other OpenACC loop specifiers")
> -   : G_("% conflicts with other OpenACC loop "
> -"specifiers"));
> +   G_("% overrides other OpenACC loop specifiers"));
> maybe_auto = false;
> loop->flags &= ~OLF_AUTO;
> if (seq_par)
> diff --git a/gcc/testsuite/ChangeLog.openacc b/gcc/testsuite/ChangeLog.openacc
> index 3bdce2e..3850d97 100644
> --- a/gcc/testsuite/ChangeLog.openacc
> +++ b/gcc/testsuite/ChangeLog.openacc
> @@ -1,3 +1,9 @@
> +2019-01-24  Gergö Barany  
> +
> + * c-c++-common/goacc/combined-directives-3.c: Adjust test.
> + * c-c++-common/goacc/loop-2-kernels.c: Likewise.
> + * c-c++-common/goacc/loop-2-parallel.c: Likewise.
> +
>  2019-01-09  Julian Brown  
>  
>   * c-c++-common/cpp/openacc-define-3.c: Update expected value for
> diff --git a/gcc/testsuite/c-c++-common/goacc/combined-directives-3.c 
> b/gcc/testsuite/c-c++-common/goacc/combined-directives-3.c
> index 77d4182..5aa84dc 100644
> --- a/gcc/testsuite/c-c++-common/goacc/combined-directives-3.c
> +++ b/gcc/testsuite/c-c++-common/goacc/combined-directives-3.c
> @@ -12,9 +12,9 @@ main ()
>  for (y = 0; y < 10; y++)
>;
>  
> -#pragma acc parallel loop gang auto /* { dg-error "'auto' conflicts with 
> other OpenACC loop specifiers" } */
> +#pragma acc parallel loop gang seq /* { dg-error "'seq' overrides other 
> OpenACC loop specifiers" } */
>for (x = 0; x < 10; x++)
> -#pragma acc loop worker auto /* { dg-error "'auto' conflicts with other 
> OpenACC loop specifiers" } */
> +#pragma acc loop worker 

Re: [PATCH, OpenACC] Rework OpenACC Fortran DO loop initialization

[Thomas Schwinge]

Hi Gergő!

(We're asked for to CC the GCC Fortran developers, ,
for any Fortran related changes.)

On Fri, 25 Jan 2019 15:13:48 +0100, Gergö Barany  
wrote:
> This patch moves OpenACC Fortan DO loop setup code from the head of a 
> region to just before each loop.

The code that you're modifying: "gfc_privatize_nodesc_arrays" has been
added by Cesar, years ago, and is not yet in GCC trunk, and I'm not at
all familiar with that stuff.
,
.  (We
shall re-visit that in next GCC development stage 1.)

That all said, your rationale of why/how you're changing the code seems
reasonable, and as I understand, you're mostly moving existing code
around, so...

> This is in preparation for upcoming 
> patches reworking the handling of OpenACC kernels regions.
> 
> OK for openacc-gcc-8-branch?

OK.

The test case (which is not really too useful right now, but I understand
will be later) needs to get a "dg-do run" directive added (to enable
"torture testing": cycling through optimization and other flags, which is
done (only) for Fortran, "for reasons"), and then needs to be "avoid
offloading" XFAILed, which we shall be able to remove as part of later
changes, yay.  I'm attaching a patch that you can squeeze in as is.


Grüße
 Thomas


> From f4768a88a4e2ab5dc80feb7bfb06cd273c849f72 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Gerg=C3=B6=20Barany?= 
> Date: Mon, 21 Jan 2019 03:08:57 -0800
> Subject: [PATCH] Rework OpenACC Fortran DO loop initialization
> 
> Fortran DO loops on arrays with non-constant bounds (like a(lo:hi)) need
> special setup code to compute the bounds and offsets for the iteration. In
> an OpenACC region containing multiple loops, this used to be done in a block
> of code at the start of the region for all of the loops. But the upcoming
> kernels conversion expects this kind of setup code to immediately precede
> the corresponding loop, and variables are not mapped correctly otherwise.
> This patch separates out the initialization part for each loop and places it
> immediately before the loop.
> 
> gcc/fortran/
> * trans-openmp.c (gfc_privatize_nodesc_array_clauses): Renamed from
> gfc_privatize_nodesc_arrays, initialization part factored out to...
> (gfc_reinitialize_privatized_arrays): ... this new function, called...
> (gfc_trans_omp_do): ... from here for OpenACC loops.
> 
> libgomp/
> * testsuite/libgomp.oacc-fortran/initialize_kernels_loops.f90: New test.
> ---
>  gcc/fortran/ChangeLog.openacc  |  7 ++
>  gcc/fortran/trans-openmp.c | 86 
> +-
>  libgomp/ChangeLog.openacc  |  4 +
>  .../initialize_kernels_loops.f90   | 31 
>  4 files changed, 92 insertions(+), 36 deletions(-)
>  create mode 100644 
> libgomp/testsuite/libgomp.oacc-fortran/initialize_kernels_loops.f90
> 
> diff --git a/gcc/fortran/ChangeLog.openacc b/gcc/fortran/ChangeLog.openacc
> index 0f31f3e..450056d 100644
> --- a/gcc/fortran/ChangeLog.openacc
> +++ b/gcc/fortran/ChangeLog.openacc
> @@ -1,3 +1,10 @@
> +2019-01-24  Gergö Barany  
> +
> + * trans-openmp.c (gfc_privatize_nodesc_array_clauses): Renamed from
> + gfc_privatize_nodesc_arrays, initialization part factored out to...
> + (gfc_reinitialize_privatized_arrays): ... this new function, called...
> + (gfc_trans_omp_do): ... from here for OpenACC loops.
> +
>  2019-01-09  Julian Brown  
>  
>   * cpp.c (cpp_define_builtins): Update _OPENACC define to 201711.
> diff --git a/gcc/fortran/trans-openmp.c b/gcc/fortran/trans-openmp.c
> index d5dbf18..5a444c3 100644
> --- a/gcc/fortran/trans-openmp.c
> +++ b/gcc/fortran/trans-openmp.c
> @@ -3198,6 +3198,44 @@ gfc_scan_nodesc_arrays (gfc_expr **e, int 
> *walk_subtrees ATTRIBUTE_UNUSED,
>return 0;
>  }
>  
> +/* Reinitialize any arrays used inside CODE.  Place the initialization
> +   sequences in CODE.  */
> +
> +static void
> +gfc_reinitialize_privatized_arrays (gfc_code *code, stmtblock_t *block)
> +{
> +  hash_set  *array_set = new hash_set  ();
> +  gfc_code_walker (, gfc_dummy_code_callback, gfc_scan_nodesc_arrays,
> +array_set);
> +
> +  hash_set::iterator its = array_set->begin ();
> +
> +  for (; its != array_set->end (); ++its)
> +{
> +  gfc_symbol *sym = *its;
> +  tree parm = gfc_get_symbol_decl (sym);
> +  tree type = TREE_TYPE (parm);
> +  tree offset, tmp;
> +
> +  /* Evaluate the bounds of the array.  */
> +  gfc_trans_array_bounds (type, sym, , block, false);
> +
> +  /* Set the offset.  */
> +  if (TREE_CODE (GFC_TYPE_ARRAY_OFFSET (type)) == VAR_DECL)
> +gfc_add_modify (block, GFC_TYPE_ARRAY_OFFSET (type), offset);
> +
> +  /* Set the pointer itself if we aren't using the parameter
> + directly.  */
> +  if (TREE_CODE (parm) != PARM_DECL && DECL_LANG_SPECIFIC 

[patch, fortran] Fix PR 57048

[Thomas König]

Hello world,

let the regression hunt continue!

the attached patch fixes a long-time regression where a c_funptr from a
module could not be found.

The solution is a bit of a hack, but so is our whole implementation of
the C interop stuff.

Regression-tested. OK for trunk?

Regards

Thomas

2019-01-28  Thomas Koenig  

PR fortran/57048
* interface.c (gfc_compare_types): If a derived type and an
integer both have a derived type, and they are identical,
this is a C binding type and compares equal.

2019-01-28  Thomas Koenig  

PR fortran/57048
* gfortran.dg/c_funptr_1.f90: New file.
* gfortran.dg/c_funptr_1_mod.f90: New file.
Index: interface.c
===
--- interface.c	(Revision 268104)
+++ interface.c	(Arbeitskopie)
@@ -692,6 +692,15 @@ gfc_compare_types (gfc_typespec *ts1, gfc_typespec
   if (ts1->type == BT_VOID || ts2->type == BT_VOID)
 return true;
 
+  /* Special case for our C interop types.  There should be a better
+ way of doing this...  */
+
+  if (((ts1->type == BT_INTEGER && ts2->type == BT_DERIVED)
+   || (ts1->type == BT_DERIVED && ts2->type == BT_INTEGER))
+  && ts1->u.derived && ts2->u.derived
+  && ts1->u.derived == ts2->u.derived)
+return true;
+
   /* The _data component is not always present, therefore check for its
  presence before assuming, that its derived->attr is available.
  When the _data component is not present, then nevertheless the
! { dg-do preprocess }
! { dg-additional-options "-cpp" }
! PR 57048 - this used not to compile. Original test case by Angelo
! Graziosi.  Only works if compiled c_funptr_1_mod.f90, hence the
! do-nothing directive above.
module procs
  
  implicit none
  private

  public WndProc

contains
  function WndProc()
integer :: WndProc

WndProc = 0
  end function WndProc
end module procs

function WinMain()
  use, intrinsic :: iso_c_binding, only: C_INT,c_sizeof,c_funloc
  use win32_types
  use procs
  implicit none

  integer :: WinMain

  type(WNDCLASSEX_T) :: WndClass

  WndClass%cbSize = int(c_sizeof(Wndclass),C_INT)
  WndClass%lpfnWndProc = c_funloc(WndProc)

  WinMain = 0
end function WinMain

program main
end 
! { dg-do  run }
! { dg-additional-sources c_funptr_1.f90 }
! Additional module to go with c_funptr_1.f90
module win32_types
  use, intrinsic :: iso_c_binding, only: C_INT,C_FUNPTR
  implicit none
  private

  public WNDCLASSEX_T
  type, bind(C) :: WNDCLASSEX_T
 integer(C_INT) :: cbSize
 type(C_FUNPTR) :: lpfnWndProc

  end type WNDCLASSEX_T

end module win32_types

Re: [wwwdocs] List -Wabsolute-value in gcc-9/changes.html

[Gerald Pfeifer]

Hi Martin,

On Sat, 26 Jan 2019, Martin Jambor wrote:
>> What is a "wrong absolute value function"?  That might be good to
>> show by means of an example?  (Also in invoke.texi, which I checked
>> before writing this.)
> I'm not sure how to change the wording, perhaps "...when a used absolute
> value function seems wrong for the type of its argument" ...?

yes, that definitely would have helped me as a user.  (I guessed
it might be that, but seeing it in writing helps.)

On Mon, 28 Jan 2019, Martin Sebor wrote:
>   -Wabsolute-value warns for calls to standard functions that compute
>   the absolute value of an argument when a more appropriate standard
>   function is available.  For example, calling abs(3.14) triggers
>   the warning because the appropriate function to call to compute
>   the absolute value of a double argument is fabs.  The option also
>   triggers warnings when the argument in a call to such a function
>   has an unsigned type.

Lovely.  

(I'd say "This option...", but that's probably a matter of taste.)

Are you going to enhance both invoke.texi and apply a patch to the
release notes (changes.html)?  That would be ideal.

Thanks!

Gerald

Re: [wwwdocs] List -Wabsolute-value in gcc-9/changes.html

[Martin Sebor]

On 1/26/19 3:37 PM, Martin Jambor wrote:

Hi,

On Sat, Jan 26 2019, Gerald Pfeifer wrote:

On Sat, 26 Jan 2019, Martin Jambor wrote:

I'd like to propose the following hunk mentioning -Wabsolute-value in
changes.html of the upcoming gcc 9.  Is it OK?


Lovely^WThanks, ok!

Actually, one question:


+  -Wabsolute-value warns when a wrong absolute value
+   function seems to be used or when it does not have any effect because
+   its argument is an unsigned type.  The -Wabsolute-value
+   option is included in -Wextra.


What is a "wrong absolute value function"?  That might be good to
show by means of an example?  (Also in invoke.texi, which I checked
before writing this.)


Most usually wrong means an absolute value function for a shorter type
than the one privided, such as abs when labs would be approproiate, or
abs or labs when you actually need llabs.  Or using normal
floating-point absolute value function such as fabs for
binary-coded-decimal.  Or even for a complex double/float, which
hitherto passed without a warning.

I'm not sure how to change the wording, perhaps "...when a used absolute
value function seems wrong for the type of its argument" ...?


Would this work?

  -Wabsolute-value warns for calls to standard functions that compute
  the absolute value of an argument when a more appropriate standard
  function is available.  For example, calling abs(3.14) triggers
  the warning because the appropriate function to call to compute
  the absolute value of a double argument is fabs.  The option also
  triggers warnings when the argument in a call to such a function
  has an unsigned type.

Martin

Re: [PATCH, rs6000] Fix invalid type returned from builtin vec_extract

[Segher Boessenkool]

Hi Kelvin,

On Mon, Jan 28, 2019 at 12:11:34PM -0600, Kelvin Nilsen wrote:
> An error in the type returned from the built-in vec_extract function was 
> recently reported, as represented in the following sample program:

[ snip ]

> The fix is to coerce the result of vec_extract so that it matches the type of 
> the array element supplied as its first argument.

The patch is fine, but there are some issues with the new testcases:

> --- gcc/testsuite/gcc.target/powerpc/vec-extract-schar-1.c(nonexistent)
> +++ gcc/testsuite/gcc.target/powerpc/vec-extract-schar-1.c(working copy)
> @@ -0,0 +1,27 @@
> +/* Test to verify that the vec_extract from a vector of
> +   signed chars remains signed.  */
> +/* { dg-do run } */
> +/* { dg-options "-ansi -mcpu=power8 " } */

(stray space)

You need to also have

/* { dg-require-effective-target powerpc_p8vector_ok } */
/* { dg-skip-if "do not override -mcpu" { powerpc*-*-* } { "-mcpu=*" } { 
"-mcpu=power8" } } */

(the first so that the builtins exist, the second so that things work if
you set -mcpu= in RUNTESTFLAGS, as is common).

Could you test with that please?

Okay for trunk with that.  Also okay for backport where wanted/needed.

Thanks!


Segher

Re: [libbacktrace] Fix and simplify xcoff_%.c pattern rule

[Ian Lance Taylor]

On Mon, Jan 28, 2019 at 1:25 AM Tom de Vries  wrote:
>
> [ was: Re: [backtrace] Avoid segfault  ]
> On 27-01-19 22:53, Ian Lance Taylor wrote:
> > On Sun, Jan 27, 2019 at 1:16 PM Tom de Vries  wrote:
> >>
> >> On 25-01-19 18:15, Nathan Sidwell wrote:
> >>> On 1/25/19 5:28 AM, Tom de Vries wrote:
> 
>  This patch fixes it by passing "" instead of NULL, in the call to
>  elf_add at line 3083 (for .gnu_debugaltlink), not the call to elf_add at
>  line 3044 (for .gnu_debuglink) mentioned above.
> 
>  Nathan, does this fix the problem for you? If not, can you provide a
>  reproducer, or give a hint on how one could be constructed?
> >>>
> >>> I still hit the problem, and am installing this as sufficiently obvious.
> >>>  I'm on a fedora system debugging pr88995.  The debuglink_name is
> >>> "../../.dwz/isl-0.16.1-7.fc29.x86_64"
> >>>
> >>
> >> I've managed to reproduce this segfault instance by adding a test-case
> >> that uses both build-id and dwz.
> >>
> >> OK for trunk?
> >
> >> +elf_for_test.c: elf.c
> >> + PWD=$$(pwd -P); \
> >> + BUILD_ID_DIR="usr/lib/debug/.build-id/"; \
> >> + SEARCH='#define SYSTEM_BUILD_ID_DIR'; \
> >> + REPLACE="#define SYSTEM_BUILD_ID_DIR \"$$PWD/$$BUILD_ID_DIR\""; \
> >> + $(SED) "s%^$$SEARCH.*\$$%$$REPLACE%" \
> >> + $< \
> >> + > $@
> >
> > You need to use a temporary file, such as $@.tmp, for the final sed
> > command, followed by a mv to $@.  Otherwise a failure in the sed will
> > leave what appears to be an up to date file.
>
> I noticed the same problem in the xcoff_%.c pattern rule.
>
> OK for trunk?

This is OK.

Thanks.

Ian

[PATCH, rs6000] Fix invalid type returned from builtin vec_extract

[Kelvin Nilsen]

An error in the type returned from the built-in vec_extract function was 
recently reported, as represented in the following sample program:

#include 
#include 

int main() {
unsigned char uc = 0xf6;
printf("explicit cast: %x\n", (int)uc);

vector unsigned char v = vec_splats((unsigned char)0xf6);
printf("cast from vec_extract(): %x\n", (int)vec_extract(v, 0));
return 0;
}

When compiled with the current trunk, the output of running this program is:

$ ./a.out 
explicit cast: f6
cast from vec_extract(): fff6

The fix is to coerce the result of vec_extract so that it matches the type of 
the array element supplied as its first argument.

I have built and regression tested this patch on powerpc64le-unknown-linux with 
no regressions.  Is this ok for trunk?

gcc/ChangeLog:

2019-01-28  Kelvin Nilsen  

* config/rs6000/rs6000-c.c (altivec-resolve_overloaded_builtin):
Change handling of ALTIVEC_BUILTIN_VEC_EXTRACT.  Coerce result to
type of vector element when vec_extract is implemented by direct
move.

gcc/testsuite/ChangeLog:

2019-01-28  Kelvin Nilsen  

* gcc.target/powerpc/vec-extract-schar-1.c: New test.
* gcc.target/powerpc/vec-extract-sint-1.c: New test.
* gcc.target/powerpc/vec-extract-sint128-1.c: New test.
* gcc.target/powerpc/vec-extract-slong-1.c: New test.
* gcc.target/powerpc/vec-extract-sshort-1.c: New test.
* gcc.target/powerpc/vec-extract-uchar-1.c: New test.
* gcc.target/powerpc/vec-extract-uint-1.c: New test.
* gcc.target/powerpc/vec-extract-uint128-1.c: New test.
* gcc.target/powerpc/vec-extract-ulong-1.c: New test.
* gcc.target/powerpc/vec-extract-ushort-1.c: New test.

Index: gcc/config/rs6000/rs6000-c.c
===
--- gcc/config/rs6000/rs6000-c.c(revision 268196)
+++ gcc/config/rs6000/rs6000-c.c(working copy)
@@ -6645,7 +6645,13 @@
}
 
  if (call)
-   return build_call_expr (call, 2, arg1, arg2);
+   {
+ tree result = build_call_expr (call, 2, arg1, arg2);
+ /* Coerce the result to vector element type.  May be no-op.  */
+ arg1_inner_type = TREE_TYPE (arg1_type);
+ result = fold_convert (arg1_inner_type, result);
+ return result;
+   }
}
 
   /* Build *(((arg1_inner_type*)&(vector type){arg1})+arg2). */
Index: gcc/testsuite/gcc.target/powerpc/vec-extract-schar-1.c
===
--- gcc/testsuite/gcc.target/powerpc/vec-extract-schar-1.c  (nonexistent)
+++ gcc/testsuite/gcc.target/powerpc/vec-extract-schar-1.c  (working copy)
@@ -0,0 +1,27 @@
+/* Test to verify that the vec_extract from a vector of
+   signed chars remains signed.  */
+/* { dg-do run } */
+/* { dg-options "-ansi -mcpu=power8 " } */
+
+#include 
+#include 
+#include 
+
+int test1(signed char sc) {
+  int sce;
+
+  vector signed char v = vec_splats(sc);
+  sce = vec_extract(v,0);
+
+  if (sce != sc)
+abort();
+  return 0;
+}
+
+int main()
+{
+  test1 (0xf6);
+  test1 (0x76);
+  test1 (0x06);
+  return 0;
+}
Index: gcc/testsuite/gcc.target/powerpc/vec-extract-sint-1.c
===
--- gcc/testsuite/gcc.target/powerpc/vec-extract-sint-1.c   (nonexistent)
+++ gcc/testsuite/gcc.target/powerpc/vec-extract-sint-1.c   (working copy)
@@ -0,0 +1,27 @@
+/* Test to verify that the vec_extract from a vector of
+   signed ints remains signed.  */
+/* { dg-do run } */
+/* { dg-options "-ansi -mcpu=power8 " } */
+
+#include 
+#include 
+#include 
+
+int test1(signed int si) {
+  long long int sie;
+
+  vector signed int v = vec_splats(si);
+  sie = vec_extract(v,0);
+
+  if (sie != si)
+abort();
+  return 0;
+}
+
+int main()
+{
+  test1 (0xf600);
+  test1 (0x7600);
+  test1 (0x0600);
+  return 0;
+}
Index: gcc/testsuite/gcc.target/powerpc/vec-extract-sint128-1.c
===
--- gcc/testsuite/gcc.target/powerpc/vec-extract-sint128-1.c(nonexistent)
+++ gcc/testsuite/gcc.target/powerpc/vec-extract-sint128-1.c(working copy)
@@ -0,0 +1,25 @@
+/* Test to verify that the vec_extract from a vector of
+   signed __int128s remains signed.  */
+/* { dg-do run } */
+/* { dg-options "-ansi -mcpu=power8 " } */
+
+#include 
+#include 
+#include 
+
+int test1(signed __int128 st) {
+
+  vector signed long long int v = vec_splats(st);
+
+  if (vec_extract (v, 0) > st)
+abort();
+  return 0;
+}
+
+int main()
+{
+  test1 (((__int128) 0xf600LL) << 64);
+  test1 (((__int128) 0x7600LL) << 64);
+  test1 (((__int128) 0x0600LL) << 64);
+  return 0;
+}
Index: gcc/testsuite/gcc.target/powerpc/vec-extract-slong-1.c
===
--- 

Re: C++ PATCH for c++/89024 - ICE with incomplete enum type

[Marek Polacek]

On Mon, Jan 28, 2019 at 11:55:21AM -0500, Jason Merrill wrote:
> > > The new test fails on arm-eabi (with newlib, but passes on on arm*linux*):
> > > FAIL: g++.dg/cpp0x/enum37.C  -std=c++14 (test for excess errors)
> > > FAIL: g++.dg/cpp0x/enum37.C  -std=c++17 (test for excess errors)
> > >
> > > The log says:
> > > /gcc/testsuite/g++.dg/cpp0x/enum37.C:24:41: error: aggregate
> > > 'same s2' has incomplete type and cannot
> > > be defined
> 
> I imagine that this is because arm-eabi defaults to -fshort-enums; you
> can check for this in the testsuite with { target short_enums }.

Indeed, I wasn't aware of this.

> > Clearly the additional checking I added won't fly; Jason, can I commit
> > this?
> >
> > Tested on x86_64-linux, ok for trunk?
> >
> > 2019-01-28  Marek Polacek  
> >
> > * g++.dg/cpp0x/enum37.C: Remove a check.
> 
> I'd prefer to make the check conditional.

In which case, this.  I think it's better than making the whole test
conditional on short_enums.

Tested on x86_64-linux, ok for trunk?

2019-01-28  Marek Polacek  

* g++.dg/cpp0x/enum37.C: Add dg-error.

diff --git gcc/testsuite/g++.dg/cpp0x/enum37.C 
gcc/testsuite/g++.dg/cpp0x/enum37.C
index 6aa3d4015d7..b67720d5ea0 100644
--- gcc/testsuite/g++.dg/cpp0x/enum37.C
+++ gcc/testsuite/g++.dg/cpp0x/enum37.C
@@ -21,4 +21,4 @@ enum E {
 };
 
 same s;
-same s2;
+same s2; // { dg-error "incomplete type" "" 
{ target short_enums } }

PING ^1: V3 [PATCH] i386: Add pass_remove_partial_avx_dependency

[H.J. Lu]

On Tue, Jan 22, 2019 at 5:28 AM H.J. Lu  wrote:
>
> On Tue, Jan 22, 2019 at 4:08 AM Richard Biener
>  wrote:
> >
> > On Mon, Jan 21, 2019 at 10:27 PM H.J. Lu  wrote:
> > >
> > > On Mon, Jan 21, 2019 at 10:54 AM Jeff Law  wrote:
> > > >
> > > > On 1/7/19 6:55 AM, H.J. Lu wrote:
> > > > > On Sun, Dec 30, 2018 at 8:40 AM H.J. Lu  wrote:
> > > > >> On Wed, Nov 28, 2018 at 12:17 PM Jeff Law  wrote:
> > > > >>> On 11/28/18 12:48 PM, H.J. Lu wrote:
> > > >  On Mon, Nov 5, 2018 at 7:29 AM Jan Hubicka  wrote:
> > > > >> On 11/5/18 7:21 AM, Jan Hubicka wrote:
> > > >  Did you mean "the nearest common dominator"?
> > > > >>> If the nearest common dominator appears in the loop while all 
> > > > >>> uses are
> > > > >>> out of loops, this will result in suboptimal xor placement.
> > > > >>> In this case you want to split edges out of the loop.
> > > > >>>
> > > > >>> In general this is what the LCM framework will do for you if 
> > > > >>> the problem
> > > > >>> is modelled siimlar way as in mode_swtiching.  At entry 
> > > > >>> function mode is
> > > > >>> "no zero register needed" and all conversions need mode "zero 
> > > > >>> register
> > > > >>> needed".  Mode switching should then do the correct placement 
> > > > >>> decisions
> > > > >>> (reaching minimal number of executions of xor).
> > > > >>>
> > > > >>> Jeff, whan is your optinion on the approach taken by the patch?
> > > > >>> It seems like a special case of more general issue, but I do 
> > > > >>> not see
> > > > >>> very elegant way to solve it at least in the GCC 9 horisont, so 
> > > > >>> if
> > > > >>> the placement is correct we can probalby go either with new 
> > > > >>> pass or
> > > > >>> making this part of mode swithcing (which is anyway run by x86 
> > > > >>> backend)
> > > > >> So I haven't followed this discussion at all, but did touch on 
> > > > >> this
> > > > >> issue with some patch a month or two ago with a target patch 
> > > > >> that was
> > > > >> trying to avoid the partial stalls.
> > > > >>
> > > > >> My assumption is that we're trying to find one or more places to
> > > > >> initialize the upper half of an avx register so as to avoid 
> > > > >> partial
> > > > >> register stall at existing sites that set the upper half.
> > > > >>
> > > > >> This sounds like a classic PRE/LCM style problem (of which mode
> > > > >> switching is just another variant).   A common-dominator 
> > > > >> approach is
> > > > >> closer to a classic GCSE and is going to result is more 
> > > > >> initializations
> > > > >> at sub-optimal points than a PRE/LCM style.
> > > > > yes, it is usual code placement problem. It is special case 
> > > > > because the
> > > > > zero register is not modified by the conversion (just we need to 
> > > > > have
> > > > > zero somewhere).  So basically we do not have kills to the zero 
> > > > > except
> > > > > for entry block.
> > > > >
> > > >  Do you have  testcase to show thatf the nearest common dominator
> > > >  in the loop, while all uses areout of loops, leads to suboptimal 
> > > >  xor
> > > >  placement?
> > > > >>> I don't have a testcase, but it's all but certain nearest common
> > > > >>> dominator is going to be a suboptimal placement.  That's going to 
> > > > >>> create
> > > > >>> paths where you're going to emit the xor when it's not used.
> > > > >>>
> > > > >>> The whole point of the LCM algorithms is they are optimal in terms 
> > > > >>> of
> > > > >>> expression evaluations.
> > > > >> We tried LCM and it didn't work well for this case.  LCM places a 
> > > > >> single
> > > > >> VXOR close to the location where it is needed, which can be inside a
> > > > >> loop.  There is nothing wrong with the LCM algorithms.   But this 
> > > > >> doesn't
> > > > >> solve
> > > > >>
> > > > >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87007
> > > > >>
> > > > >> where VXOR is executed multiple times inside of a function, instead 
> > > > >> of
> > > > >> just once.   We are investigating to generate a single VXOR at entry 
> > > > >> of the
> > > > >> nearest dominator for basic blocks with SF/DF conversions, which is 
> > > > >> in
> > > > >> the the fake loop that contains the whole function:
> > > > >>
> > > > >>   bb = nearest_common_dominator_for_set (CDI_DOMINATORS,
> > > > >>  convert_bbs);
> > > > >>   while (bb->loop_father->latch
> > > > >>  != EXIT_BLOCK_PTR_FOR_FN (cfun))
> > > > >> bb = get_immediate_dominator (CDI_DOMINATORS,
> > > > >>   bb->loop_father->header);
> > > > >>
> > > > >>   insn = BB_HEAD (bb);
> > > > >>   if (!NONDEBUG_INSN_P (insn))
> > > > >> insn = next_nonnote_nondebug_insn (insn);
> > > > >>   set = 

Re: [PATCH] Fix PR87295

[Jason Merrill]

On 1/28/19 6:30 AM, Richard Biener wrote:

On Mon, 28 Jan 2019, Richard Biener wrote:


On Sat, 26 Jan 2019, Jason Merrill wrote:


On Fri, Jan 25, 2019 at 7:57 AM Richard Biener  wrote:


The following fixes an ICE with -flto -ffat-lto-objects
-fdebug-types-section -g where optimize_external_refs does not
expect to see DW_AT_signature as made "local" by build_abbrev_table(sic!).

This is because we run optimize_external_refs twice in this setup.

The fix is to make the second run not pick up "local" DW_AT_signature
as external.  Alternatively build_abbrev_table could be adjusted
to not keep those as DW_AT_signature.  It's not even clear to me
whether a DW_AT_signature as we output it is valid DWARF ...
to quote non-LTO -g:

  <1><1d>: Abbrev Number: 13 (DW_TAG_structure_type)
 <1e>   DW_AT_name: (indirect string, offset: 0x8b):
integral_constant
 <22>   DW_AT_signature   : <0x5d>


Yes, that seems pretty clearly wrong.  It doesn't make sense for
DW_AT_signature to be a local reference; it should only have
DW_FORM_ref_sig8.


OK, thus the fix below is then obvious.


Apart from not working because I skip marking the refs external.
Adjusted patch in testing...




 <26>   DW_AT_declaration : 1
 <26>   DW_AT_sibling : <0x48>
...
  <1><5d>: Abbrev Number: 16 (DW_TAG_structure_type)
 <5e>   DW_AT_name: (indirect string, offset: 0x8b):
integral_constant
 <62>   DW_AT_signature   : signature: 0x1f6a4ae7cc5a362e
 <6a>   DW_AT_declaration : 1
 <6a>   DW_AT_sibling : <0x7b>


And there's no reason to have two skeleton DIEs for the same type.


Of course the main "issue" is that copy_unworthy_types
duplicated this parent into 1d and 5d in the first place
(but that's a pure optimization issue?).


Indeed.


Not doing that
would have avoided the situation in PR87295.  But then
why should optimize_external_refs_1 have this special
code handling DW_AT_signature in the first place if this
was not intended...  (so even better, kill that and the
build_abbrev_table optimization and fix copy_unworthy_types?)


The point of optimize_external_refs_1 is to remember when we've seen a
skeleton DIE so we can refer to it from other DIEs in the same unit
rather than use DW_FORM_ref_sig8.  The problem is just that we get two
skeleton DIEs so we wrongly change one to refer to the other.  One
possibility would be to suppress the local reference optimization for
DW_AT_signature, but avoiding the redundant skeleton should fix the
problem and also save space.


I'll avoid the bogus DW_AT_signature change for now and see if I
can come up with a fix for the duplicate as followup.  I'm going
to backport the fix to the 8 branch and on trunk if I manage to
avoid the duplicate change the fix to assert we do not try to
replace a DW_AT_signature refrence instead.


... but this one isn't too bad either, see below.  I've tried
to merge this into copy_decls_for_unworthy_types but this becomes
somewhat messy, the pre-scan of the CU is easier to follow
thus I've settled with that.

Bootstrap & regtest running on x86_64-unknown-linux-gnu.  A backport
would instead of the assert have the a->dw_attr != DW_AT_signature
check in place.

Richard.

2019-01-28  Richard Biener  

PR debug/87295
* dwarf2out.c (collect_skeleton_dies): New helper.
(copy_decls_for_unworthy_types): Call it.
(build_abbrev_table): Assert we do not try to replace
DW_AT_signature refs with local refs.


Looks good, apart from a typo:


+  /* Record in DECL_TABLE that TARG has been alreay copied


"already"

Jason

Re: [PATCH, OpenACC] Rework computation of default OpenACC mapping clauses

[Thomas Schwinge]

Hi Gergő!

On Fri, 25 Jan 2019 15:09:49 +0100, Gergö Barany  
wrote:
> This patch unifies and simplifies the handling of OpenACC default 
> mapping clauses for parallel, serial, and kernels regions.

Thanks.  This answers/resolves at least some of the questions that I
asked (not you) many months ago, about why 'kernels' and 'parallel'
constructs are being treated differently here.

I'll be good to eventually add proper testing so that we verify (at
"gimple" tree-dump level?) that the expected mappings are set up under
all the different conditions, but your patch certainly is an improvement
already, so:

> OK for openacc-gcc-8-branch?

Yes.


A few comments (for later):

> From 32a38daf2084bb266aa3a0c61c9176098d2d4bdb Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Gerg=C3=B6=20Barany?= 
> Date: Mon, 21 Jan 2019 03:01:02 -0800
> Subject: [PATCH] Rework computation of default OpenACC mapping clauses
> 
> gcc/
> * gimplify.c (oacc_default_clause): Refactor and unify computation of
> default mapping clauses.
> ---
>  gcc/ChangeLog.openacc |  5 
>  gcc/gimplify.c| 75 
> +--
>  2 files changed, 41 insertions(+), 39 deletions(-)
> 
> diff --git a/gcc/ChangeLog.openacc b/gcc/ChangeLog.openacc
> index 22cdb5b..932fb37 100644
> --- a/gcc/ChangeLog.openacc
> +++ b/gcc/ChangeLog.openacc
> @@ -1,3 +1,8 @@
> +2019-01-24  Gergö Barany  
> +
> + * gimplify.c (oacc_default_clause): Refactor and unify computation of
> + default mapping clauses.
> +
>  2019-01-09  Julian Brown  
>  
>   * doc/invoke.texi: Update mention of OpenACC version to 2.6.
> diff --git a/gcc/gimplify.c b/gcc/gimplify.c
> index a60e395..a6a4d2a 100644
> --- a/gcc/gimplify.c
> +++ b/gcc/gimplify.c
> @@ -7191,58 +7191,55 @@ oacc_default_clause (struct gimplify_omp_ctx *ctx, 
> tree decl, unsigned flags)
>flags |= GOVD_MAP_TO_ONLY;
>  }
>  
> +  unsigned private_mapping_flag = 0;
> +  unsigned default_scalar_flags = 0;

It might make sense to initialize these to some "invalid" values, so that
we can at some later point detect when these are being used, when they
shouldn't.

> +  /* Aggregates default to 'present_or_copy', or 'present'.  */
> +  unsigned aggregate_flags
> += (ctx->default_kind != OMP_CLAUSE_DEFAULT_PRESENT
> +? GOVD_MAP
> +: GOVD_MAP | GOVD_MAP_FORCE_PRESENT);
> +
>switch (ctx->region_type)
>  {
>  case ORT_ACC_KERNELS:
>rkind = "kernels";
> -
> -  if (is_private)
> - flags |= GOVD_MAP;
> -  else if (AGGREGATE_TYPE_P (type))
> - {
> -   /* Aggregates default to 'present_or_copy', or 'present'.  */
> -   if (ctx->default_kind != OMP_CLAUSE_DEFAULT_PRESENT)
> - flags |= GOVD_MAP;
> -   else
> - flags |= GOVD_MAP | GOVD_MAP_FORCE_PRESENT;
> - }
> -  else
> - /* Scalars default to 'copy'.  */
> - flags |= GOVD_MAP | GOVD_MAP_FORCE;
> -
> +  /* Scalars default to 'copy'.  */
> +  default_scalar_flags = GOVD_MAP | GOVD_MAP_FORCE;
> +  /* There are no private mappings on kernels regions.  */
> +  gcc_assert (!is_private);
>break;

Ah, is this literally the 'private' clause?  (Or something else -- I have
not yet looked up what exactly "is_private =
lang_hooks.decls.omp_disregard_value_expr (decl, false)" is doing "if
(RECORD_OR_UNION_TYPE_P (type))".)

> -
>  case ORT_ACC_PARALLEL:
> +  rkind = "parallel";
> +  /* Scalars default to 'firstprivate'.  */
> +  default_scalar_flags = GOVD_FIRSTPRIVATE;
> +  private_mapping_flag = GOVD_FIRSTPRIVATE;
> +  break;
>  case ORT_ACC_SERIAL:
> -  rkind = ctx->region_type == ORT_ACC_PARALLEL ? "parallel" : "serial";
> -
> -  if (TREE_CODE (type) == REFERENCE_TYPE
> -   && TREE_CODE (TREE_TYPE (type)) == POINTER_TYPE)
> - flags |= GOVD_MAP | GOVD_MAP_0LEN_ARRAY;
> -  else if (!lang_GNU_Fortran () && TREE_CODE (type) == POINTER_TYPE)
> - flags |= GOVD_MAP | GOVD_MAP_0LEN_ARRAY;
> -  else if (is_private)
> - flags |= GOVD_FIRSTPRIVATE;
> -  else if (on_device || declared)
> - flags |= GOVD_MAP;
> -  else if (AGGREGATE_TYPE_P (type))
> - {
> -   /* Aggregates default to 'present_or_copy', or 'present'.  */
> -   if (ctx->default_kind != OMP_CLAUSE_DEFAULT_PRESENT)
> - flags |= GOVD_MAP;
> -   else
> - flags |= GOVD_MAP | GOVD_MAP_FORCE_PRESENT;
> - }
> -  else
> - /* Scalars default to 'firstprivate'.  */
> - flags |= GOVD_FIRSTPRIVATE;
> -
> +  rkind = "serial";
> +  /* Scalars default to 'firstprivate'.  */
> +  default_scalar_flags = GOVD_FIRSTPRIVATE;
> +  private_mapping_flag = GOVD_FIRSTPRIVATE;
>break;
>  
>  default:
>gcc_unreachable ();
>  }
>  
> +  if (TREE_CODE (type) == REFERENCE_TYPE
> +  && TREE_CODE (TREE_TYPE (type)) == POINTER_TYPE)
> +flags |= GOVD_MAP | GOVD_MAP_0LEN_ARRAY;
> +  else if (!lang_GNU_Fortran () && 

Re: PING [PATCH] tighten up -Wbuiltin-declaration-mismatch (PR 86125, 88886, 86308)

[Martin Sebor]

On 1/28/19 9:43 AM, Joseph Myers wrote:

On Mon, 28 Jan 2019, Martin Sebor wrote:


On 1/25/19 6:25 PM, Joseph Myers wrote:

It's also broken the build of the glibc testsuite, e.g.:

../time/time.h:88:15: error: mismatch in argument 1 type of built-in
function 'strftime'; expected 'char *'
[-Werror=builtin-declaration-mismatch]
 88 | extern size_t strftime (char *__restrict __s, size_t __maxsize,

(presence or absence of qualifiers on a parameter is not part of the
function type and should not be compared here).


Not sure I see which pointer the warning is complaining about but
detecting mismatches in constness is intentional.  Users will want
to know when they accidentally swapped the arguments of, say,
memcpy, and declared it as:


It's about qualifiers on the pointer itself (which do not affect the
function's type, although such qualifiers in the function definition
affect code inside the function), not qualifiers on the pointer target
type.  GCC can't assume whether system headers do or do not have the
"restrict" qualification on some parameters that's included in C99
(essentially as documentation of aliasing requirements for parameters for
those functions), nor do GCC's built-in function declarations have that
"restrict" anywhere.  But it's complaining here about a mismatch between
"char *restrict" and "char *".


I see.  That's certainly not intentional.  Looks like we need better
tests.  None of the ones I added focus on exercising qualifiers, and
I can't find any others for the warning that do either.

Martin

Re: C++ PATCH for c++/89024 - ICE with incomplete enum type

[Jason Merrill]

On Mon, Jan 28, 2019 at 10:40 AM Marek Polacek  wrote:
> On Mon, Jan 28, 2019 at 10:37:01AM +0100, Christophe Lyon wrote:
> > On Sun, 27 Jan 2019 at 01:25, Jason Merrill  wrote:
> > >
> > > On Fri, Jan 25, 2019 at 6:22 PM Marek Polacek  wrote:
> > > >
> > > > On Fri, Jan 25, 2019 at 12:14:07PM -0500, Jason Merrill wrote:
> > > > > On 1/25/19 12:09 PM, Marek Polacek wrote:
> > > > > > On Fri, Jan 25, 2019 at 10:55:55AM -0600, Tim Song wrote:
> > > > > > > On Thu, Jan 24, 2019 at 4:14 PM Jason Merrill  
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > On 1/24/19 2:16 PM, Marek Polacek wrote:
> > > > > > > > > This test ICEs since r159006 which added
> > > > > > > > >
> > > > > > > > >  type = ENUM_UNDERLYING_TYPE (type);
> > > > > > > > >
> > > > > > > > > to type_promotes_to.  In this test ENUM_UNDERLYING_TYPE is 
> > > > > > > > > null because we
> > > > > > > > > haven't yet parsed '}' of the enum and the underlying type 
> > > > > > > > > isn't fixed, and
> > > > > > > > > so checking TYPE_UNSIGNED crashed.
> > > > > > > > >
> > > > > > > > > I've added some checks to the test to see if the types seem 
> > > > > > > > > to be OK; clang++
> > > > > > > > > agrees.
> > > > > > > > >
> > > > > > > > > Bootstrapped/regtested on x86_64-linux, ok for trunk/8/7?
> > > > > > > > >
> > > > > > > > > 2019-01-24  Marek Polacek  
> > > > > > > > >
> > > > > > > > >PR c++/89024 - ICE with incomplete enum type.
> > > > > > > > >* cvt.c (type_promotes_to): Check if prom is non-null.
> > > > > > > >
> > > > > > > > 9.6/6: An enumeration whose underlying type is not fixed is an
> > > > > > > > incomplete type from its point of declaration to immediately 
> > > > > > > > after the
> > > > > > > > closing } of its enum-specifier, at which point it becomes a 
> > > > > > > > complete type.
> > > > > > > >
> > > > > > > > So the conversion is ill-formed.
> > > > > > > >
> > > > > > > > Jason
> > > > > > >
> > > > > > > But the conversion in the example (in
> > > > > > > decltype(__test_aux<_To1>(declval<_From1>(
> > > > > > > is in a SFINAE context, so shouldn't it gracefully fall back to 
> > > > > > > the
> > > > > > > `(...)` overload?
> > > > > >
> > > > > > I think so, and clang++ and icc also compile the testcase fine (and 
> > > > > > we used to
> > > > > > too, before r159006).
> > > > >
> > > > > Absolutely, the conversion being ill-formed means substitution fails, 
> > > > > and we
> > > > > reject that candidate.  I meant that we shouldn't get as far as
> > > > > type_promotes_to for an incomplete type.
> > > >
> > > > Makes sense.  So here's another attempt:
> > > >
> > > > Bootstrapped/regtested on x86_64-linux, ok for trunk?
> > > >
> > > > 2019-01-25  Marek Polacek  
> > > >
> > > > PR c++/89024 - ICE with incomplete enum type.
> > > > * call.c (standard_conversion): When converting an
> > > > ARITHMETIC_TYPE_P to an incomplete type, return NULL.
> > >
> > > OK.
> > >
> >
> > Hi,
> > The new test fails on arm-eabi (with newlib, but passes on on arm*linux*):
> > FAIL: g++.dg/cpp0x/enum37.C  -std=c++14 (test for excess errors)
> > FAIL: g++.dg/cpp0x/enum37.C  -std=c++17 (test for excess errors)
> >
> > The log says:
> > /gcc/testsuite/g++.dg/cpp0x/enum37.C:24:41: error: aggregate
> > 'same s2' has incomplete type and cannot
> > be defined

I imagine that this is because arm-eabi defaults to -fshort-enums; you
can check for this in the testsuite with { target short_enums }.

> Clearly the additional checking I added won't fly; Jason, can I commit
> this?
>
> Tested on x86_64-linux, ok for trunk?
>
> 2019-01-28  Marek Polacek  
>
> * g++.dg/cpp0x/enum37.C: Remove a check.

I'd prefer to make the check conditional.

Jason

Re: PING [PATCH] tighten up -Wbuiltin-declaration-mismatch (PR 86125, 88886, 86308)

[Joseph Myers]

On Mon, 28 Jan 2019, Martin Sebor wrote:

> On 1/25/19 6:25 PM, Joseph Myers wrote:
> > It's also broken the build of the glibc testsuite, e.g.:
> > 
> > ../time/time.h:88:15: error: mismatch in argument 1 type of built-in
> > function 'strftime'; expected 'char *'
> > [-Werror=builtin-declaration-mismatch]
> > 88 | extern size_t strftime (char *__restrict __s, size_t __maxsize,
> > 
> > (presence or absence of qualifiers on a parameter is not part of the
> > function type and should not be compared here).
> 
> Not sure I see which pointer the warning is complaining about but
> detecting mismatches in constness is intentional.  Users will want
> to know when they accidentally swapped the arguments of, say,
> memcpy, and declared it as:

It's about qualifiers on the pointer itself (which do not affect the 
function's type, although such qualifiers in the function definition 
affect code inside the function), not qualifiers on the pointer target 
type.  GCC can't assume whether system headers do or do not have the 
"restrict" qualification on some parameters that's included in C99 
(essentially as documentation of aliasing requirements for parameters for 
those functions), nor do GCC's built-in function declarations have that 
"restrict" anywhere.  But it's complaining here about a mismatch between 
"char *restrict" and "char *".

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

Re: PING [PATCH] tighten up -Wbuiltin-declaration-mismatch (PR 86125, 88886, 86308)

[Martin Sebor]

On 1/25/19 6:25 PM, Joseph Myers wrote:

It's also broken the build of the glibc testsuite, e.g.:

../time/time.h:88:15: error: mismatch in argument 1 type of built-in function 
'strftime'; expected 'char *' [-Werror=builtin-declaration-mismatch]
88 | extern size_t strftime (char *__restrict __s, size_t __maxsize,

(presence or absence of qualifiers on a parameter is not part of the
function type and should not be compared here).


Not sure I see which pointer the warning is complaining about but
detecting mismatches in constness is intentional.  Users will want
to know when they accidentally swapped the arguments of, say,
memcpy, and declared it as:

  memcpy (const char*, char*, size_t);

Martin

Re: C++ PATCH for c++/89024 - ICE with incomplete enum type

[Marek Polacek]

On Mon, Jan 28, 2019 at 10:37:01AM +0100, Christophe Lyon wrote:
> On Sun, 27 Jan 2019 at 01:25, Jason Merrill  wrote:
> >
> > On Fri, Jan 25, 2019 at 6:22 PM Marek Polacek  wrote:
> > >
> > > On Fri, Jan 25, 2019 at 12:14:07PM -0500, Jason Merrill wrote:
> > > > On 1/25/19 12:09 PM, Marek Polacek wrote:
> > > > > On Fri, Jan 25, 2019 at 10:55:55AM -0600, Tim Song wrote:
> > > > > > On Thu, Jan 24, 2019 at 4:14 PM Jason Merrill  
> > > > > > wrote:
> > > > > > >
> > > > > > > On 1/24/19 2:16 PM, Marek Polacek wrote:
> > > > > > > > This test ICEs since r159006 which added
> > > > > > > >
> > > > > > > >  type = ENUM_UNDERLYING_TYPE (type);
> > > > > > > >
> > > > > > > > to type_promotes_to.  In this test ENUM_UNDERLYING_TYPE is null 
> > > > > > > > because we
> > > > > > > > haven't yet parsed '}' of the enum and the underlying type 
> > > > > > > > isn't fixed, and
> > > > > > > > so checking TYPE_UNSIGNED crashed.
> > > > > > > >
> > > > > > > > I've added some checks to the test to see if the types seem to 
> > > > > > > > be OK; clang++
> > > > > > > > agrees.
> > > > > > > >
> > > > > > > > Bootstrapped/regtested on x86_64-linux, ok for trunk/8/7?
> > > > > > > >
> > > > > > > > 2019-01-24  Marek Polacek  
> > > > > > > >
> > > > > > > >PR c++/89024 - ICE with incomplete enum type.
> > > > > > > >* cvt.c (type_promotes_to): Check if prom is non-null.
> > > > > > >
> > > > > > > 9.6/6: An enumeration whose underlying type is not fixed is an
> > > > > > > incomplete type from its point of declaration to immediately 
> > > > > > > after the
> > > > > > > closing } of its enum-specifier, at which point it becomes a 
> > > > > > > complete type.
> > > > > > >
> > > > > > > So the conversion is ill-formed.
> > > > > > >
> > > > > > > Jason
> > > > > >
> > > > > > But the conversion in the example (in
> > > > > > decltype(__test_aux<_To1>(declval<_From1>(
> > > > > > is in a SFINAE context, so shouldn't it gracefully fall back to the
> > > > > > `(...)` overload?
> > > > >
> > > > > I think so, and clang++ and icc also compile the testcase fine (and 
> > > > > we used to
> > > > > too, before r159006).
> > > >
> > > > Absolutely, the conversion being ill-formed means substitution fails, 
> > > > and we
> > > > reject that candidate.  I meant that we shouldn't get as far as
> > > > type_promotes_to for an incomplete type.
> > >
> > > Makes sense.  So here's another attempt:
> > >
> > > Bootstrapped/regtested on x86_64-linux, ok for trunk?
> > >
> > > 2019-01-25  Marek Polacek  
> > >
> > > PR c++/89024 - ICE with incomplete enum type.
> > > * call.c (standard_conversion): When converting an
> > > ARITHMETIC_TYPE_P to an incomplete type, return NULL.
> >
> > OK.
> >
> 
> Hi,
> The new test fails on arm-eabi (with newlib, but passes on on arm*linux*):
> FAIL: g++.dg/cpp0x/enum37.C  -std=c++14 (test for excess errors)
> FAIL: g++.dg/cpp0x/enum37.C  -std=c++17 (test for excess errors)
> 
> The log says:
> /gcc/testsuite/g++.dg/cpp0x/enum37.C:24:41: error: aggregate
> 'same s2' has incomplete type and cannot
> be defined

Clearly the additional checking I added won't fly; Jason, can I commit
this?

Tested on x86_64-linux, ok for trunk?

2019-01-28  Marek Polacek  

* g++.dg/cpp0x/enum37.C: Remove a check.

diff --git gcc/testsuite/g++.dg/cpp0x/enum37.C 
gcc/testsuite/g++.dg/cpp0x/enum37.C
index 6aa3d4015d7..e6539af762e 100644
--- gcc/testsuite/g++.dg/cpp0x/enum37.C
+++ gcc/testsuite/g++.dg/cpp0x/enum37.C
@@ -21,4 +21,3 @@ enum E {
 };
 
 same s;
-same s2;

Re: [PATCH] Add testcase for C++ placement new and the important difference between dtor clobbers and end of scope clobbers

[Michael Matz]

Hi,

On Mon, 28 Jan 2019, Richard Biener wrote:

> > -  MEM[(struct  &)] ={v} {CLOBBER};
> > +  buf1 ={v} {CLOBBER};
> 
> Eww :/  That means they are not semantically the same which IMHO is
> bad.

But they really are different.  One is saying "these bytes contain nothing 
anymore", the other says "these bytes are gone".  (in the original CLOBBER 
design there was only the latter, so perhaps both shouldn't have been 
conflated, but alas, afterwards it's always easy to say :) ).


Ciao,
Michael.

Re: [PATCH] Wrap 'expand_all_functions' and 'ipa_passes' around timevars

[Richard Biener]

On Mon, Jan 28, 2019 at 2:16 PM Giuliano Belinassi
 wrote:
>
> On 01/28, Richard Biener wrote:
> > On Thu, Jan 24, 2019 at 8:51 PM Giuliano Belinassi
> >  wrote:
> > >
> > > This patch adds two variables named 'TV_CGRAPH_FUNC_EXPANSION' and
> > > 'TV_CGRAPH_IPA_PASSES' that count the elapsed time of the functions
> > > 'expand_all_functions' and 'ipa_passes', respectivelly.
> > >
> > > The main point of this is that these functions takes a very long time
> > > when compiling the 'gimple-match.c' file, and therefore may also take
> > > a long time when compiling other large files.
> >
> > But as implemented those shouldn't accumulate a lot of time because other
> > timevars are pushed for them.
> >
>
> It seems not to be what is happening. For instance:
>
>  callgraph functions expansion  :  49.42 ( 73%)   1.18 ( 29%)  50.60 ( 
> 70%)  770140 kB ( 48%)
>  callgraph ipa passes   :  13.10 ( 19%)   1.47 ( 36%)  14.57 ( 
> 20%)  388727 kB ( 24%)
>
> I also tried push/pop'ing these variables, however the reported time
> was 0
>
> > I think you want to instead split TV_PHASE_OPT_GEN into
> > TV_PHASE_OPT_GIMPLE TV_PHASE_IPA and TV_PHASE_RTL
> > which probably can be easiest managed by the pass manager
> > pushing/popping those appropriately depending on the pass kind
> > that is invoked?
> >
> I will check this out.
> Just a question: Is the function expansion a part of GIMPLE?

It covers both GIMPLE and RTL I think (maybe also parts of IPA).

Richard.

> Giuliano.
>
> > Richard.
> >
> > > I also accept suggestions about how to improve this :-)
> > >
> > > ChangeLog:
> > >
> > > 2019-01-24  Giuliano Belinassi 
> > >
> > > * cgraph_unit.c (compile): TV_CGRAPH_FUNC_EXPANSION and
> > > TV_CGRAPH_IPA_PASSES start, stop.
> > > * timevar.def (TV_CGRAPH_IPA_PASSES, TV_CGRAPH_FUNC_EXPANSION): 
> > > New.
> > >
> > >

Re: [PATCH] Add testcase for C++ placement new and the important difference between dtor clobbers and end of scope clobbers

[Jason Merrill]

On Mon, Jan 28, 2019 at 8:52 AM Jonathan Wakely  wrote:
>
> On 28/01/19 14:29 +0100, Jakub Jelinek wrote:
> >On Mon, Jan 28, 2019 at 01:55:38PM +0100, Richard Biener wrote:
> >> So I guess in the end we're being lucky.  Somehow.  I've played with
> >>
> >> __attribute__((noipa)) void
> >> qux ()
> >> {
> >>   S buf1;
> >>   foo ((char *));
> >>   S *p = new () (S);
> >>   bar (p);
> >>   p->~S ();
> >>   {
> >> char buf2[128];
> >> baz (buf2);
> >>   }
> >> }
> >
> >I'd think the above is already invalid, by doing a placement new into
> >a variable with non-trivial ctor and dtor while it is still constructed,
> >then destruct the placement new created var in there and after a while
> >destruct the original variable doesn't feel right to me, but I'm not a C++
>
> Right. When the second object is constructed in that location, the
> lifetime of the first one ends. When the destructor is automatically
> run at the end of the scope you're destroying something that is no
> longer alive, so undefined.

Indeed.

> >language lawyer.  I'd expect that usually either the whole var has
> >char/std::byte etc. array type, or the placement new is into a field inside
> >of some class (again char/std::byte etc. array type).
> >Would could be valid is:
>
> Yeah I think the one below is OK. I'm still looking at the original
> testcase at the top of the thread.

The original testcase looks good to me.  And I agree with Jakub's
point, that destroying an object created in a buffer is necessarily
different from destroying the buffer itself.

Jason

Re: testsuite dg-directives glitches

[Manfred Schwarb]

Am 26.01.2019 um 16:14 schrieb Dominique d'Humières:
> I have committed the following patch to the gcc-7-branch as r268294 after a 
> regtest.
> Manfred, could you please check with your script that I did not miss 
> some test in the gcc-7 and gcc-8 branches?

In the GCC-7 branch, there is
./pr68318_1.f90:2:! { dg-options "-O0"

and in the GCC-8 branch I found
./newunit_5.f90.f90:1:! { dg-do run )


Thanks,
Manfred


> TIA
> 
> Dominique
> Index: gcc/testsuite/ChangeLog
> ===
> --- gcc/testsuite/ChangeLog   (revision 268292)
> +++ gcc/testsuite/ChangeLog   (working copy)
> @@ -1,3 +1,15 @@
> +2019-01-26  Manfred Schwarb  
> +
> + * gfortran.dg/array_function_5.f90
> + * gfortran.dg/class_66.f90
> + * gfortran.dg/dec_structure_12.f90
> + * gfortran.dg/dec_structure_14.f90
> + * gfortran.dg/dec_structure_15.f90
> + * gfortran.dg/extends_11.f03
> + * gfortran.dg/pr58968.f
> + * gfortran.dg/pr78259.f90
> + * gfortran.dg/debug/pr35154-stabs.f
> +
>  2019-01-24  Uroš Bizjak  
>  
>   PR target/88998
> diff -up ../7_clean/gcc/testsuite/gfortran.dg/array_function_5.f90 
> gcc/testsuite/gfortran.dg/array_function_5.f90
> --- ../7_clean/gcc/testsuite/gfortran.dg/array_function_5.f90 2017-04-21 
> 16:03:35.0 +0200
> +++ gcc/testsuite/gfortran.dg/array_function_5.f902019-01-25 
> 12:27:40.0 +0100
> @@ -1,4 +1,4 @@
> -! {  dg-do run }
> +! { dg-do run }
>  ! PR41278 internal compiler error related to matmul and transpose
>  ! Test case prepared by Jerry DeLisle  
>  ! Original test case by Chris 
> diff -up ../7_clean/gcc/testsuite/gfortran.dg/class_66.f90 
> gcc/testsuite/gfortran.dg/class_66.f90
> --- ../7_clean/gcc/testsuite/gfortran.dg/class_66.f90 2017-12-07 
> 12:49:38.0 +0100
> +++ gcc/testsuite/gfortran.dg/class_66.f902019-01-25 12:28:06.0 
> +0100
> @@ -1,4 +1,4 @@
> -! { dg- do run }
> +! { dg-do run }
>  !
>  ! Test the fix for PR78641 in which an ICE occured on assignment
>  ! of a class array constructor to a derived type array.
> diff -up ../7_clean/gcc/testsuite/gfortran.dg/dec_structure_12.f90 
> gcc/testsuite/gfortran.dg/dec_structure_12.f90
> --- ../7_clean/gcc/testsuite/gfortran.dg/dec_structure_12.f90 2017-04-21 
> 16:03:35.0 +0200
> +++ gcc/testsuite/gfortran.dg/dec_structure_12.f902019-01-25 
> 12:28:58.0 +0100
> @@ -1,4 +1,4 @@
> -! { dg-do "compile" }
> +! { dg-do compile }
>  ! { dg-options "-fdec-structure" }
>  !
>  ! Test a regression where multiple anonymous structures failed to
> diff -up ../7_clean/gcc/testsuite/gfortran.dg/dec_structure_14.f90 
> gcc/testsuite/gfortran.dg/dec_structure_14.f90
> --- ../7_clean/gcc/testsuite/gfortran.dg/dec_structure_14.f90 2017-04-21 
> 16:03:32.0 +0200
> +++ gcc/testsuite/gfortran.dg/dec_structure_14.f902019-01-25 
> 12:29:10.0 +0100
> @@ -1,4 +1,4 @@
> -  ! { dg-do "compile" }
> +  ! { dg-do compile }
>! { dg-options "-fdec-structure" }
>!
>! Test that structures inside a common block do not require the
> diff -up ../7_clean/gcc/testsuite/gfortran.dg/dec_structure_15.f90 
> gcc/testsuite/gfortran.dg/dec_structure_15.f90
> --- ../7_clean/gcc/testsuite/gfortran.dg/dec_structure_15.f90 2017-04-21 
> 16:03:29.0 +0200
> +++ gcc/testsuite/gfortran.dg/dec_structure_15.f902019-01-25 
> 12:29:23.0 +0100
> @@ -1,4 +1,4 @@
> -! { dg-do "compile" }
> +! { dg-do compile }
>  ! { dg-options "" }
>  !
>  ! PR fortran/77584
> diff -up ../7_clean/gcc/testsuite/gfortran.dg/extends_11.f03 
> gcc/testsuite/gfortran.dg/extends_11.f03
> --- ../7_clean/gcc/testsuite/gfortran.dg/extends_11.f03   2017-04-21 
> 16:03:35.0 +0200
> +++ gcc/testsuite/gfortran.dg/extends_11.f03  2019-01-25 12:29:59.0 
> +0100
> @@ -37,4 +37,4 @@
>recruit%service%education%person%ss = 9
>  end
>  
> -! { dg-final { scan-tree-dump-times " 
> +recruit\\.service\\.education\\.person\\.ss =" 8 "original"} }
> +! { dg-final { scan-tree-dump-times " 
> +recruit\\.service\\.education\\.person\\.ss =" 8 "original" } }
> diff -up ../7_clean/gcc/testsuite/gfortran.dg/pr58968.f 
> gcc/testsuite/gfortran.dg/pr58968.f
> --- ../7_clean/gcc/testsuite/gfortran.dg/pr58968.f2017-04-21 
> 16:03:35.0 +0200
> +++ gcc/testsuite/gfortran.dg/pr58968.f   2019-01-25 12:30:29.0 
> +0100
> @@ -1,5 +1,5 @@
>  C PR rtl-optimization/58968.f
> -C { dg-do compile { target powerpc*-*-*} }
> +C { dg-do compile { target powerpc*-*-* } }
>  C { dg-options "-mcpu=power7 -O3 -w -ffast-math  -funroll-loops" }
>SUBROUTINE MAKTABS(IW,SOME,LBOX1,LBOX2,LBOX3,NSPACE,NA,NB,
>   *LBST,X,
> diff -up ../7_clean/gcc/testsuite/gfortran.dg/pr78259.f90 
> gcc/testsuite/gfortran.dg/pr78259.f90
> --- ../7_clean/gcc/testsuite/gfortran.dg/pr78259.f90  2017-04-21 
> 16:03:34.0 +0200
> +++ gcc/testsuite/gfortran.dg/pr78259.f90 2019-01-25 12:31:01.0 
> 

Re: [PATCH] Add testcase for C++ placement new and the important difference between dtor clobbers and end of scope clobbers

[Jonathan Wakely]

On 28/01/19 14:29 +0100, Jakub Jelinek wrote:

On Mon, Jan 28, 2019 at 01:55:38PM +0100, Richard Biener wrote:

So I guess in the end we're being lucky.  Somehow.  I've played with

__attribute__((noipa)) void
qux ()
{
  S buf1;
  foo ((char *));
  S *p = new () (S);
  bar (p);
  p->~S ();
  {
char buf2[128];
baz (buf2);
  }
}


I'd think the above is already invalid, by doing a placement new into
a variable with non-trivial ctor and dtor while it is still constructed,
then destruct the placement new created var in there and after a while
destruct the original variable doesn't feel right to me, but I'm not a C++


Right. When the second object is constructed in that location, the
lifetime of the first one ends. When the destructor is automatically
run at the end of the scope you're destroying something that is no
longer alive, so undefined.


language lawyer.  I'd expect that usually either the whole var has
char/std::byte etc. array type, or the placement new is into a field inside
of some class (again char/std::byte etc. array type).
Would could be valid is:


Yeah I think the one below is OK. I'm still looking at the original
testcase at the top of the thread.


__attribute__((noipa)) void
qux ()
{
 S buf1;
 foo (buf1.buf);
 S *p = new (buf1.buf) (S);
 bar (p);
 p->~S ();
 {
   char buf2[128];
   baz (buf2);
 }
}

but we don't really fold that into VAR_DECL lhs either, the type in the
MEM_REF isn't really S even in this case, but CLASSTYPE_AS_BASE of the S
type.

Jakub

Re: [PATCH] Add testcase for C++ placement new and the important difference between dtor clobbers and end of scope clobbers

[Jakub Jelinek]

On Mon, Jan 28, 2019 at 01:55:38PM +0100, Richard Biener wrote:
> So I guess in the end we're being lucky.  Somehow.  I've played with
> 
> __attribute__((noipa)) void
> qux ()
> {
>   S buf1;
>   foo ((char *));
>   S *p = new () (S);
>   bar (p);
>   p->~S ();
>   {
> char buf2[128];
> baz (buf2);
>   }
> }

I'd think the above is already invalid, by doing a placement new into
a variable with non-trivial ctor and dtor while it is still constructed,
then destruct the placement new created var in there and after a while
destruct the original variable doesn't feel right to me, but I'm not a C++
language lawyer.  I'd expect that usually either the whole var has
char/std::byte etc. array type, or the placement new is into a field inside
of some class (again char/std::byte etc. array type).
Would could be valid is:
__attribute__((noipa)) void
qux ()
{
  S buf1;
  foo (buf1.buf);
  S *p = new (buf1.buf) (S);
  bar (p);
  p->~S ();
  {
char buf2[128];
baz (buf2);
  }
}

but we don't really fold that into VAR_DECL lhs either, the type in the
MEM_REF isn't really S even in this case, but CLASSTYPE_AS_BASE of the S
type.

Jakub

Re: [PATCH] Wrap 'expand_all_functions' and 'ipa_passes' around timevars

[Giuliano Belinassi]

On 01/28, Richard Biener wrote:
> On Thu, Jan 24, 2019 at 8:51 PM Giuliano Belinassi
>  wrote:
> >
> > This patch adds two variables named 'TV_CGRAPH_FUNC_EXPANSION' and
> > 'TV_CGRAPH_IPA_PASSES' that count the elapsed time of the functions
> > 'expand_all_functions' and 'ipa_passes', respectivelly.
> >
> > The main point of this is that these functions takes a very long time
> > when compiling the 'gimple-match.c' file, and therefore may also take
> > a long time when compiling other large files.
> 
> But as implemented those shouldn't accumulate a lot of time because other
> timevars are pushed for them.
> 

It seems not to be what is happening. For instance:

 callgraph functions expansion  :  49.42 ( 73%)   1.18 ( 29%)  50.60 ( 70%) 
 770140 kB ( 48%)
 callgraph ipa passes   :  13.10 ( 19%)   1.47 ( 36%)  14.57 ( 20%) 
 388727 kB ( 24%)

I also tried push/pop'ing these variables, however the reported time
was 0

> I think you want to instead split TV_PHASE_OPT_GEN into
> TV_PHASE_OPT_GIMPLE TV_PHASE_IPA and TV_PHASE_RTL
> which probably can be easiest managed by the pass manager
> pushing/popping those appropriately depending on the pass kind
> that is invoked?
>
I will check this out.
Just a question: Is the function expansion a part of GIMPLE?

Giuliano.

> Richard.
> 
> > I also accept suggestions about how to improve this :-)
> >
> > ChangeLog:
> >
> > 2019-01-24  Giuliano Belinassi 
> >
> > * cgraph_unit.c (compile): TV_CGRAPH_FUNC_EXPANSION and
> > TV_CGRAPH_IPA_PASSES start, stop.
> > * timevar.def (TV_CGRAPH_IPA_PASSES, TV_CGRAPH_FUNC_EXPANSION): New.
> >
> >

Re: [PATCH] Add testcase for C++ placement new and the important difference between dtor clobbers and end of scope clobbers

[Richard Biener]

On Mon, 28 Jan 2019, Jakub Jelinek wrote:

> On Mon, Jan 28, 2019 at 01:18:43PM +0100, Richard Biener wrote:
> > Eww :/  That means they are not semantically the same which IMHO is
> > bad.  If you make buf1 volatile does it trip over
> > maybe_canonicalize_mem_ref_addr and miscompile?  Or are we somehow
> 
> If buf1 is volatile, then no clobbers are added for it for when it goes out
> of scope:
>   if (VAR_P (t)
>   && !is_global_var (t)
>   && DECL_CONTEXT (t) == current_function_decl)
> {
>   if (!DECL_HARD_REGISTER (t)
>   && !TREE_THIS_VOLATILE (t)
>   && !DECL_HAS_VALUE_EXPR_P (t)
>   /* Only care for variables that have to be in memory.  Others
>  will be rewritten into SSA names, hence moved to the
>  top-level.  */
>   && !is_gimple_reg (t)
>   && flag_stack_reuse != SR_NONE)
> {
>   tree clobber = build_clobber (TREE_TYPE (t));
> The clobbers from ctors and dtors are still there, but nothing folds them to
> non-MEM_REF anyway:
>   volatile char buf2[128];
>   volatile char buf1[128];
> 
>[local count: 1073741824]:
>   foo ();
>   MEM[(struct  &)] ={v} {CLOBBER};
>   memset ([(void *)], 32, 128);
>   bar ();
>   MEM[(struct  &)] ={v} {CLOBBER};
>   baz ();
>   return;
> in *.optimized.

Ah, OK.  The clobber has record type, not array type.  And we don't
mark the LHS of clobbers TREE_THIS_VOLATILE but the RHS CONSTRUCTOR.

So to have it folded you need to in-place dtor the declared type,
not some other.

The only reason I cannot get it folded it seems to be the

  if (/* Same volatile qualification.  */
  TREE_THIS_VOLATILE (*t) == TREE_THIS_VOLATILE (decl)
  /* Same TBAA behavior with -fstrict-aliasing.  */
  && !TYPE_REF_CAN_ALIAS_ALL (alias_type)
  && (TYPE_MAIN_VARIANT (TREE_TYPE (decl))
  == TYPE_MAIN_VARIANT (TREE_TYPE (alias_type)))
  /* Same alignment.  */
  && TYPE_ALIGN (TREE_TYPE (decl)) == TYPE_ALIGN (TREE_TYPE (*t))
  /* We have to look out here to not drop a required conversion
 from the rhs to the lhs if *t appears on the lhs or 
vice-versa
 if it appears on the rhs.  Thus require strict type
 compatibility.  */
  && types_compatible_p (TREE_TYPE (*t), TREE_TYPE (decl)))

check where TYPE_MAIN_VARIANT (TREE_TYPE (decl))
== TYPE_MAIN_VARIANT (TREE_TYPE (alias_type) fails.  Oddly the
two different main variants _do_ share their TYPE_FIELDs...

So I guess in the end we're being lucky.  Somehow.  I've played with

__attribute__((noipa)) void
qux ()
{
  S buf1;
  foo ((char *));
  S *p = new () (S);
  bar (p);
  p->~S ();
  {
char buf2[128];
baz (buf2);
  }
}


Richard.

Re: [PATCH] Add testcase for C++ placement new and the important difference between dtor clobbers and end of scope clobbers

[Jakub Jelinek]

On Mon, Jan 28, 2019 at 01:18:43PM +0100, Richard Biener wrote:
> Eww :/  That means they are not semantically the same which IMHO is
> bad.  If you make buf1 volatile does it trip over
> maybe_canonicalize_mem_ref_addr and miscompile?  Or are we somehow

If buf1 is volatile, then no clobbers are added for it for when it goes out
of scope:
  if (VAR_P (t)
  && !is_global_var (t)
  && DECL_CONTEXT (t) == current_function_decl)
{
  if (!DECL_HARD_REGISTER (t)
  && !TREE_THIS_VOLATILE (t)
  && !DECL_HAS_VALUE_EXPR_P (t)
  /* Only care for variables that have to be in memory.  Others
 will be rewritten into SSA names, hence moved to the
 top-level.  */
  && !is_gimple_reg (t)
  && flag_stack_reuse != SR_NONE)
{
  tree clobber = build_clobber (TREE_TYPE (t));
The clobbers from ctors and dtors are still there, but nothing folds them to
non-MEM_REF anyway:
  volatile char buf2[128];
  volatile char buf1[128];

   [local count: 1073741824]:
  foo ();
  MEM[(struct  &)] ={v} {CLOBBER};
  memset ([(void *)], 32, 128);
  bar ();
  MEM[(struct  &)] ={v} {CLOBBER};
  baz ();
  return;
in *.optimized.

Jakub

Re: [PATCH] Add testcase for C++ placement new and the important difference between dtor clobbers and end of scope clobbers

[Richard Biener]

On Mon, 28 Jan 2019, Jakub Jelinek wrote:

> Hi!
> 
> While thinking about PR59813, I came up with following testcase.
> Is that valid C++?
> 
> What I want to highlight here that we need to treat the clobbers created
> for C++ destructors differently from clobbers added for when variables go
> out of scope.
> Right now we end up with:
>   char buf2[128];
>   char buf1[128];
> 
>[local count: 1073741824]:
>   foo ();
>   MEM[(struct  &)] ={v} {CLOBBER};
>   memset ([(void *)], 32, 128);
>   bar ();
>   MEM[(struct  &)] ={v} {CLOBBER};
>   baz ();
>   buf2 ={v} {CLOBBER};
>   buf1 ={v} {CLOBBER};
>   return;
> where the MEM[(struct  &)] ={v} {CLOBBER}; is what is coming from
> the inlined dtor (and the earlier one from inlined ctor), while
> buf1 ={v} {CLOBBER}; is what is added by the gimplifier for vars that go out
> of scope.  The var conflict code only considers clobbers with VAR_DECLs on
> the lhs and thus the testcase is not miscompiled.
> 
> Now, if I manually change the second clobber in the function
>MEM[(struct  &)] ={v} {CLOBBER};
>memset ([(void *)], 32, 128);
>bar ();
> -  MEM[(struct  &)] ={v} {CLOBBER};
> +  buf1 ={v} {CLOBBER};
>baz ();
>buf2 ={v} {CLOBBER};
>buf1 ={v} {CLOBBER};
> the testcase is miscompiled, so that just points at the need to never fold
> the clobbers with MEM_REF on the lhs into the form with VAR_DECL on the lhs.

Eww :/  That means they are not semantically the same which IMHO is
bad.  If you make buf1 volatile does it trip over
maybe_canonicalize_mem_ref_addr and miscompile?  Or are we somehow
doubly lucky and never share stack space of volatiles...

Richard.

> Tested on x86_64-linux and i686-linux, is the testcase ok for the trunk?
> 
> 2019-01-28  Jakub Jelinek  
> 
>   * g++.dg/torture/alias-1.C: New test.
> 
> --- gcc/testsuite/g++.dg/torture/alias-1.C.jj 2019-01-28 12:49:21.044341442 
> +0100
> +++ gcc/testsuite/g++.dg/torture/alias-1.C2019-01-28 12:49:04.697612121 
> +0100
> @@ -0,0 +1,57 @@
> +// Verify we don't try to allocate the same stack slot for
> +// buf1 and buf2 in qux.  While there is a CLOBBER stmt for buf1
> +// from inlined destructor, the buf1 variable doesn't go out of scope
> +// until after the baz call.
> +// { dg-do run }
> +
> +#include 
> +#include 
> +#include 
> +
> +char *p;
> +struct S { char buf[128]; S () { memset (buf, ' ', 128); }; ~S () {}; };
> +
> +__attribute__((noipa)) void
> +foo (char *x)
> +{
> +  p = x;
> +}
> +
> +__attribute__((noipa)) int
> +bar (S *x)
> +{
> +  return x->buf[12];
> +}
> +
> +__attribute__((noipa)) void
> +baz (char *x)
> +{
> +  S *a = new (p) (S);
> +  S *b = new (x) (S);
> +  memset (a->buf, '0', 128);
> +  memset (b->buf, '1', 128);
> +  if (bar (a) != '0' || bar (b) != '1')
> +abort ();
> +  b->~S ();
> +  a->~S ();
> +}
> +
> +__attribute__((noipa)) void
> +qux ()
> +{
> +  char buf1[128];
> +  foo (buf1);
> +  S *p = new (buf1) (S);
> +  bar (p);
> +  p->~S ();
> +  {
> +char buf2[128];
> +baz (buf2);
> +  }
> +}
> +
> +int
> +main ()
> +{
> +  qux ();
> +}
> 
>   Jakub
> 
> 

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

Re: [PATCH] Add target-zlib to top-level configure, use zlib from libphobos

[Richard Biener]

On Mon, Jan 21, 2019 at 7:35 PM Iain Buclaw  wrote:
>
> Hi,
>
> Following on from the last, this adds target-zlib to target_libraries
> and updates libphobos build scripts to link to libz_convenience.a.
> The D front-end already has target-zlib in d/config-lang.in.
>
> Is the top-level part OK?  I considered disabling target-zlib if
> libphobos is not being built, but decided against unless it's
> requested.

Hmm, you overload --with-system-zlib to apply to both host and target
(I guess it already applied to build), not sure if that's really desired?
I suppose libphobos is the first target library linking against zlib?

You are also falling back to in-tree zlib if --with-system-zlib was
specified but no zlib was found - I guess for cross builds that
will easily get not noticed...  The toplevel --with-system-zlib makes
it much harder and simply fails.

Joseph, does it make sense to do this?

Richard.

> --
> Iain
> ---
> ChangeLog:
>
> 2019-01-21  Iain Buclaw  
>
> * configure.ac: configure.ac: Add target-zlib to target_libraries.
> * configure: Regenerate.
>
> libphobos/ChangeLog:
>
> 2019-01-21  Iain Buclaw  
>
> * m4/druntime/libraries.m4 (DRUNTIME_LIBRARIES_ZLIB): Use
> libz_convenience.a if not using system zlib.
> * Makefile.in: Regenerate.
> * configure: Regenerate.
> * libdruntime/Makefile.in: Regenerate.
> * src/Makefile.am: Remove ZLIB_CSOURCES and AM_CFLAGS.
> * src/Makefile.in: Regenerate.
> * testsuite/Makefile.in: Regenerate.
>
> ---

[PATCH] Add testcase for C++ placement new and the important difference between dtor clobbers and end of scope clobbers

[Jakub Jelinek]

Hi!

While thinking about PR59813, I came up with following testcase.
Is that valid C++?

What I want to highlight here that we need to treat the clobbers created
for C++ destructors differently from clobbers added for when variables go
out of scope.
Right now we end up with:
  char buf2[128];
  char buf1[128];

   [local count: 1073741824]:
  foo ();
  MEM[(struct  &)] ={v} {CLOBBER};
  memset ([(void *)], 32, 128);
  bar ();
  MEM[(struct  &)] ={v} {CLOBBER};
  baz ();
  buf2 ={v} {CLOBBER};
  buf1 ={v} {CLOBBER};
  return;
where the MEM[(struct  &)] ={v} {CLOBBER}; is what is coming from
the inlined dtor (and the earlier one from inlined ctor), while
buf1 ={v} {CLOBBER}; is what is added by the gimplifier for vars that go out
of scope.  The var conflict code only considers clobbers with VAR_DECLs on
the lhs and thus the testcase is not miscompiled.

Now, if I manually change the second clobber in the function
   MEM[(struct  &)] ={v} {CLOBBER};
   memset ([(void *)], 32, 128);
   bar ();
-  MEM[(struct  &)] ={v} {CLOBBER};
+  buf1 ={v} {CLOBBER};
   baz ();
   buf2 ={v} {CLOBBER};
   buf1 ={v} {CLOBBER};
the testcase is miscompiled, so that just points at the need to never fold
the clobbers with MEM_REF on the lhs into the form with VAR_DECL on the lhs.

Tested on x86_64-linux and i686-linux, is the testcase ok for the trunk?

2019-01-28  Jakub Jelinek  

* g++.dg/torture/alias-1.C: New test.

--- gcc/testsuite/g++.dg/torture/alias-1.C.jj   2019-01-28 12:49:21.044341442 
+0100
+++ gcc/testsuite/g++.dg/torture/alias-1.C  2019-01-28 12:49:04.697612121 
+0100
@@ -0,0 +1,57 @@
+// Verify we don't try to allocate the same stack slot for
+// buf1 and buf2 in qux.  While there is a CLOBBER stmt for buf1
+// from inlined destructor, the buf1 variable doesn't go out of scope
+// until after the baz call.
+// { dg-do run }
+
+#include 
+#include 
+#include 
+
+char *p;
+struct S { char buf[128]; S () { memset (buf, ' ', 128); }; ~S () {}; };
+
+__attribute__((noipa)) void
+foo (char *x)
+{
+  p = x;
+}
+
+__attribute__((noipa)) int
+bar (S *x)
+{
+  return x->buf[12];
+}
+
+__attribute__((noipa)) void
+baz (char *x)
+{
+  S *a = new (p) (S);
+  S *b = new (x) (S);
+  memset (a->buf, '0', 128);
+  memset (b->buf, '1', 128);
+  if (bar (a) != '0' || bar (b) != '1')
+abort ();
+  b->~S ();
+  a->~S ();
+}
+
+__attribute__((noipa)) void
+qux ()
+{
+  char buf1[128];
+  foo (buf1);
+  S *p = new (buf1) (S);
+  bar (p);
+  p->~S ();
+  {
+char buf2[128];
+baz (buf2);
+  }
+}
+
+int
+main ()
+{
+  qux ();
+}

Jakub

Re: incorrect parsing of -fopt-info

[Richard Biener]

On Mon, Jan 21, 2019 at 12:31 PM Ulrich Drepper  wrote:
>
> There is a problem with parsing the second part of the -fopt-info
> command line parameter in case there is an equal sign followed by a
> filename with a dash:
>
> $ g++ -c -O -fopt-info-all=some-file u.cc
> cc1plus: warning: unknown option ‘all=some’ in ‘-fopt-info-all=some-file’
> cc1plus: error: unrecognized command line option ‘-fopt-info-all=some-file’
>
> The code looks for a '-' and a '=' concurrently but does not ignore the
> '-' if it is part of the filename specified after the '='.  The patch
> below fixes this.  I also changed the second 'if' into 'else if' which
> is clearly always the case but the current code makes it unnecessarily
> cumbersome to understand.
>
> This is a highly annoying bug in the right circumstance. I have file
> names generated based in the source file name and those include in some
> situations dashes.
>
> OK for trunk?

OK.

Richard.

>
> gcc/ChangeLog
> 2019-01-21  Ulrich Drepper  
>
> * dumpfile.c (opt_info_switch_p_1): Ignore '-' if it appears
> after the '='.
>
>

Re: [PATCH] Wrap 'expand_all_functions' and 'ipa_passes' around timevars

[Richard Biener]

On Thu, Jan 24, 2019 at 8:51 PM Giuliano Belinassi
 wrote:
>
> This patch adds two variables named 'TV_CGRAPH_FUNC_EXPANSION' and
> 'TV_CGRAPH_IPA_PASSES' that count the elapsed time of the functions
> 'expand_all_functions' and 'ipa_passes', respectivelly.
>
> The main point of this is that these functions takes a very long time
> when compiling the 'gimple-match.c' file, and therefore may also take
> a long time when compiling other large files.

But as implemented those shouldn't accumulate a lot of time because other
timevars are pushed for them.

I think you want to instead split TV_PHASE_OPT_GEN into
TV_PHASE_OPT_GIMPLE TV_PHASE_IPA and TV_PHASE_RTL
which probably can be easiest managed by the pass manager
pushing/popping those appropriately depending on the pass kind
that is invoked?

Richard.

> I also accept suggestions about how to improve this :-)
>
> ChangeLog:
>
> 2019-01-24  Giuliano Belinassi 
>
> * cgraph_unit.c (compile): TV_CGRAPH_FUNC_EXPANSION and
> TV_CGRAPH_IPA_PASSES start, stop.
> * timevar.def (TV_CGRAPH_IPA_PASSES, TV_CGRAPH_FUNC_EXPANSION): New.
>
>

Re: [PATCH] Fix PR87295

[Richard Biener]

On Mon, 28 Jan 2019, Richard Biener wrote:

> On Sat, 26 Jan 2019, Jason Merrill wrote:
> 
> > On Fri, Jan 25, 2019 at 7:57 AM Richard Biener  wrote:
> > >
> > > The following fixes an ICE with -flto -ffat-lto-objects
> > > -fdebug-types-section -g where optimize_external_refs does not
> > > expect to see DW_AT_signature as made "local" by build_abbrev_table(sic!).
> > >
> > > This is because we run optimize_external_refs twice in this setup.
> > >
> > > The fix is to make the second run not pick up "local" DW_AT_signature
> > > as external.  Alternatively build_abbrev_table could be adjusted
> > > to not keep those as DW_AT_signature.  It's not even clear to me
> > > whether a DW_AT_signature as we output it is valid DWARF ...
> > > to quote non-LTO -g:
> > >
> > >  <1><1d>: Abbrev Number: 13 (DW_TAG_structure_type)
> > > <1e>   DW_AT_name: (indirect string, offset: 0x8b):
> > > integral_constant
> > > <22>   DW_AT_signature   : <0x5d>
> > 
> > Yes, that seems pretty clearly wrong.  It doesn't make sense for
> > DW_AT_signature to be a local reference; it should only have
> > DW_FORM_ref_sig8.
> 
> OK, thus the fix below is then obvious.

Apart from not working because I skip marking the refs external.
Adjusted patch in testing...

> 
> > > <26>   DW_AT_declaration : 1
> > > <26>   DW_AT_sibling : <0x48>
> > > ...
> > >  <1><5d>: Abbrev Number: 16 (DW_TAG_structure_type)
> > > <5e>   DW_AT_name: (indirect string, offset: 0x8b):
> > > integral_constant
> > > <62>   DW_AT_signature   : signature: 0x1f6a4ae7cc5a362e
> > > <6a>   DW_AT_declaration : 1
> > > <6a>   DW_AT_sibling : <0x7b>
> > 
> > And there's no reason to have two skeleton DIEs for the same type.
> > 
> > > Of course the main "issue" is that copy_unworthy_types
> > > duplicated this parent into 1d and 5d in the first place
> > > (but that's a pure optimization issue?).
> > 
> > Indeed.
> > 
> > > Not doing that
> > > would have avoided the situation in PR87295.  But then
> > > why should optimize_external_refs_1 have this special
> > > code handling DW_AT_signature in the first place if this
> > > was not intended...  (so even better, kill that and the
> > > build_abbrev_table optimization and fix copy_unworthy_types?)
> > 
> > The point of optimize_external_refs_1 is to remember when we've seen a
> > skeleton DIE so we can refer to it from other DIEs in the same unit
> > rather than use DW_FORM_ref_sig8.  The problem is just that we get two
> > skeleton DIEs so we wrongly change one to refer to the other.  One
> > possibility would be to suppress the local reference optimization for
> > DW_AT_signature, but avoiding the redundant skeleton should fix the
> > problem and also save space.
> 
> I'll avoid the bogus DW_AT_signature change for now and see if I
> can come up with a fix for the duplicate as followup.  I'm going
> to backport the fix to the 8 branch and on trunk if I manage to
> avoid the duplicate change the fix to assert we do not try to
> replace a DW_AT_signature refrence instead.

... but this one isn't too bad either, see below.  I've tried
to merge this into copy_decls_for_unworthy_types but this becomes
somewhat messy, the pre-scan of the CU is easier to follow
thus I've settled with that.

Bootstrap & regtest running on x86_64-unknown-linux-gnu.  A backport
would instead of the assert have the a->dw_attr != DW_AT_signature
check in place.

Richard.

2019-01-28  Richard Biener  

PR debug/87295
* dwarf2out.c (collect_skeleton_dies): New helper.
(copy_decls_for_unworthy_types): Call it.
(build_abbrev_table): Assert we do not try to replace
DW_AT_signature refs with local refs.

* g++.dg/lto/pr87295_0.C: New testcase.

Index: gcc/dwarf2out.c
===
--- gcc/dwarf2out.c (revision 268334)
+++ gcc/dwarf2out.c (working copy)
@@ -8722,6 +8722,33 @@ copy_decls_walk (dw_die_ref unit, dw_die
   FOR_EACH_CHILD (die, c, copy_decls_walk (unit, c, decl_table));
 }
 
+/* Collect skeleton dies in DIE created by break_out_comdat_types already
+   and record them in DECL_TABLE.  */
+
+static void
+collect_skeleton_dies (dw_die_ref die, decl_hash_type *decl_table)
+{
+  dw_die_ref c;
+
+  if (dw_attr_node *a = get_AT (die, DW_AT_signature))
+{
+  dw_die_ref targ = AT_ref (a);
+  gcc_assert (targ->die_mark == 0 && targ->comdat_type_p);
+  decl_table_entry **slot
+= decl_table->find_slot_with_hash (targ,
+  htab_hash_pointer (targ),
+  INSERT);
+  gcc_assert (*slot == HTAB_EMPTY_ENTRY);
+  /* Record in DECL_TABLE that TARG has been alreay copied
+by remove_child_or_replace_with_skeleton.  */
+  decl_table_entry *entry = XCNEW (struct decl_table_entry);
+  entry->orig = targ;
+  entry->copy = die;
+  *slot = entry;
+}
+  FOR_EACH_CHILD (die, 

[libbacktrace] Add gen-xcoff-n.sh

[Tom de Vries]

[ was: Re: [libbacktrace] Fix and simplify xcoff_%.c pattern rule ]

On 28-01-19 10:25, Tom de Vries wrote:
> [ was: Re: [backtrace] Avoid segfault  ]
> On 27-01-19 22:53, Ian Lance Taylor wrote:
>> On Sun, Jan 27, 2019 at 1:16 PM Tom de Vries  wrote:
>>>
>>> On 25-01-19 18:15, Nathan Sidwell wrote:
 On 1/25/19 5:28 AM, Tom de Vries wrote:
>
> This patch fixes it by passing "" instead of NULL, in the call to
> elf_add at line 3083 (for .gnu_debugaltlink), not the call to elf_add at
> line 3044 (for .gnu_debuglink) mentioned above.
>
> Nathan, does this fix the problem for you? If not, can you provide a
> reproducer, or give a hint on how one could be constructed?

 I still hit the problem, and am installing this as sufficiently obvious.
  I'm on a fedora system debugging pr88995.  The debuglink_name is
 "../../.dwz/isl-0.16.1-7.fc29.x86_64"

>>>
>>> I've managed to reproduce this segfault instance by adding a test-case
>>> that uses both build-id and dwz.
>>>
>>> OK for trunk?
>>
>>> +elf_for_test.c: elf.c
>>> + PWD=$$(pwd -P); \
>>> + BUILD_ID_DIR="usr/lib/debug/.build-id/"; \
>>> + SEARCH='#define SYSTEM_BUILD_ID_DIR'; \
>>> + REPLACE="#define SYSTEM_BUILD_ID_DIR \"$$PWD/$$BUILD_ID_DIR\""; \
>>> + $(SED) "s%^$$SEARCH.*\$$%$$REPLACE%" \
>>> + $< \
>>> + > $@
>>
>> You need to use a temporary file, such as $@.tmp, for the final sed
>> command, followed by a mv to $@.  Otherwise a failure in the sed will
>> leave what appears to be an up to date file.
> 
> I noticed the same problem in the xcoff_%.c pattern rule.
> 

And looking over the rule again, I wondered if it would be more readable
if split off into a separate script file.

Is this follow-up patch OK for trunk?

Thanks,
- Tom
[Libbacktrace] Add gen-xcoff-n.sh

Factor out xcoff_%.c generation into gen-xcoff-n.c, getting rid of the
escaping of shell variables.

2019-01-28  Tom de Vries  

	* Makefile.am: Factor out xcoff_%.c generation ...
	* gen-xcoff-n.sh: ... here.  New file.
	* Makefile.in: Regenerate.

---
 libbacktrace/Makefile.am|  8 +---
 libbacktrace/Makefile.in|  8 +---
 libbacktrace/gen-xcoff-n.sh | 20 
 3 files changed, 22 insertions(+), 14 deletions(-)

diff --git a/libbacktrace/Makefile.am b/libbacktrace/Makefile.am
index 0d5b3193e25..43d0c9ffd73 100644
--- a/libbacktrace/Makefile.am
+++ b/libbacktrace/Makefile.am
@@ -104,13 +104,7 @@ libbacktrace_noformat_la_LIBADD = $(BACKTRACE_FILE) $(VIEW_FILE) $(ALLOC_FILE)
 libbacktrace_noformat_la_DEPENDENCIES = $(libbacktrace_noformat_la_LIBADD)
 
 xcoff_%.c: xcoff.c
-	SEARCH='#error "Unknown BACKTRACE_XCOFF_SIZE"'; \
-	REPLACE='#undef BACKTRACE_XCOFF_SIZE\
-	#define BACKTRACE_XCOFF_SIZE'; \
-	$(SED) "s/^$$SEARCH\$$/$$REPLACE $*/" \
-		$< \
-		> $@.tmp
-	mv $@.tmp $@
+	$(srcdir)/gen-xcoff-n.sh $(SED) $< $* $@
 
 test_elf_SOURCES = test_format.c testlib.c
 test_elf_LDADD = libbacktrace_noformat.la elf.lo
diff --git a/libbacktrace/Makefile.in b/libbacktrace/Makefile.in
index b25ac92aeda..650392c2988 100644
--- a/libbacktrace/Makefile.in
+++ b/libbacktrace/Makefile.in
@@ -1750,13 +1750,7 @@ uninstall-am:
 
 
 @NATIVE_TRUE@xcoff_%.c: xcoff.c
-@NATIVE_TRUE@	SEARCH='#error "Unknown BACKTRACE_XCOFF_SIZE"'; \
-@NATIVE_TRUE@	REPLACE='#undef BACKTRACE_XCOFF_SIZE\
-@NATIVE_TRUE@	#define BACKTRACE_XCOFF_SIZE'; \
-@NATIVE_TRUE@	$(SED) "s/^$$SEARCH\$$/$$REPLACE $*/" \
-@NATIVE_TRUE@		$< \
-@NATIVE_TRUE@		> $@.tmp
-@NATIVE_TRUE@	mv $@.tmp $@
+@NATIVE_TRUE@	$(srcdir)/gen-xcoff-n.sh $(SED) $< $* $@
 
 @NATIVE_TRUE@instrumented_alloc.lo: alloc.c
 
diff --git a/libbacktrace/gen-xcoff-n.sh b/libbacktrace/gen-xcoff-n.sh
new file mode 100755
index 000..c8825a9deba
--- /dev/null
+++ b/libbacktrace/gen-xcoff-n.sh
@@ -0,0 +1,20 @@
+#!/bin/sh
+
+sed="$1"
+src="$2"
+n="$3"
+dst="$4"
+
+tmp=$dst.tmp
+
+search='^#error "Unknown BACKTRACE_XCOFF_SIZE"$'
+
+replace='#undef BACKTRACE_XCOFF_SIZE\
+	#define BACKTRACE_XCOFF_SIZE '"$n"
+
+$sed \
+"s/$search/$replace/" \
+$src \
+> $tmp
+
+mv $tmp $dst

Re: [PATCH] Add various missing x86 ISA options to doc/{invoke,extend}.texi (PR target/89073)

[Richard Biener]

On Mon, Jan 28, 2019 at 10:48 AM Jakub Jelinek  wrote:
>
> Hi!
>
> The documentation has several lists of x86 ISA options and various options
> were missing from them.  The PR was mainly about missing options in x86
> target attribute section, which missed a lot of the options, but for each
> of the missing ones I've also double checked invoke.texi - some options were
> missing there, one had missing @opindex and some of them were listed in the
> list, but in the description weren't actually listed or were listed in
> different order.
>
> Tested on x86_64-linux with make doc, ok for trunk?

OK.

Richard.

> 2019-01-28  Jakub Jelinek  
>
> PR target/89073
> * doc/invoke.texi (-mclwb, -mprfchw, -mrdpid, -mrdseed, -msgx,
> -madx, -mhle, -mavx5124fmaps, -mavx512vnni, -mavx5124vnniw): Document
> x86 ISA options.
> (bmi2): Add missing @opindex.
> * doc/extend.texi (x86 target attribute): Move fma4, lwp, ssse3
> options alphabetically.  Add missing 3dnow, 3dnowa, adx, avx, avx2,
> avx5124fmaps, avx5124vnniw, avx512bitalg, avx512bw, avx512cd,
> avx512dq, avx512er, avx512f, avx512ifma, avx512pf, avx512vbmi,
> avx512vbmi2, avx512vl, avx512vnni, avx512vpopcntdq, bmi, bmi2,
> cldemote, clflushopt, clwb, clzero, crc32, cx16, f16c, fma, fsgsbase,
> fxsr, gfni, hle, lzcnt, movbe, movdir64b, movdiri, mwaitx, pconfig,
> pku, prefetchwt1, prfchw, ptwrite, rdpid, rdrnd, rdseed, rtm, sahf,
> sgx, sha, shstk, tbm, vaes, vpclmulqdq, waitpkg, wbnoinvd, xsave,
> xsavec, xsaveopt and xsaves options.
>
> --- gcc/doc/invoke.texi.jj  2019-01-23 09:34:35.954725873 +0100
> +++ gcc/doc/invoke.texi 2019-01-28 10:18:41.017990421 +0100
> @@ -1266,12 +1266,14 @@ See RS/6000 and PowerPC Options.
>  -mavx2  -mavx512f  -mavx512pf  -mavx512er  -mavx512cd  -mavx512vl @gol
>  -mavx512bw  -mavx512dq  -mavx512ifma  -mavx512vbmi  -msha  -maes @gol
>  -mpclmul  -mfsgsbase  -mrdrnd  -mf16c  -mfma  -mpconfig  -mwbnoinvd  @gol
> --mptwrite  -mprefetchwt1  -mclflushopt  -mxsavec  -mxsaves @gol
> +-mptwrite  -mprefetchwt1  -mclflushopt  -mclwb  -mxsavec  -mxsaves @gol
>  -msse4a  -m3dnow  -m3dnowa  -mpopcnt  -mabm  -mbmi  -mtbm  -mfma4  -mxop @gol
> --mlzcnt  -mbmi2  -mfxsr  -mxsave  -mxsaveopt  -mrtm  -mlwp @gol
> +-madx  -mlzcnt  -mbmi2  -mfxsr  -mxsave  -mxsaveopt  -mrtm  -mhle  -mlwp @gol
>  -mmwaitx  -mclzero  -mpku  -mthreads  -mgfni  -mvaes  -mwaitpkg @gol
>  -mshstk -mmanual-endbr -mforce-indirect-call  -mavx512vbmi2 @gol
>  -mvpclmulqdq  -mavx512bitalg  -mmovdiri  -mmovdir64b  -mavx512vpopcntdq @gol
> +-mavx5124fmaps  -mavx512vnni  -mavx5124vnniw  -mprfchw  -mrdpid @gol
> +-mrdseed  -msgx @gol
>  -mcldemote  -mms-bitfields  -mno-align-stringops  -minline-all-stringops @gol
>  -minline-stringops-dynamically  -mstringop-strategy=@var{alg} @gol
>  -mmemcpy-strategy=@var{strategy}  -mmemset-strategy=@var{strategy} @gol
> @@ -27877,6 +27879,9 @@ preferred alignment to @option{-mpreferr
>  @itemx -mclflushopt
>  @opindex mclflushopt
>  @need 200
> +@itemx -mclwb
> +@opindex mclwb
> +@need 200
>  @itemx -mfsgsbase
>  @opindex mfsgsbase
>  @need 200
> @@ -27901,9 +27906,21 @@ preferred alignment to @option{-mpreferr
>  @itemx -mfma4
>  @opindex mfma4
>  @need 200
> +@itemx -mprfchw
> +@opindex mprfchw
> +@need 200
> +@itemx -mrdpid
> +@opindex mrdpid
> +@need 200
>  @itemx -mprefetchwt1
>  @opindex mprefetchwt1
>  @need 200
> +@itemx -mrdseed
> +@opindex mrdseed
> +@need 200
> +@itemx -msgx
> +@opindex msgx
> +@need 200
>  @itemx -mxop
>  @opindex mxop
>  @need 200
> @@ -27922,10 +27939,14 @@ preferred alignment to @option{-mpreferr
>  @itemx -mabm
>  @opindex mabm
>  @need 200
> +@itemx -madx
> +@opindex madx
> +@need 200
>  @itemx -mbmi
>  @opindex mbmi
>  @need 200
>  @itemx -mbmi2
> +@opindex mbmi2
>  @need 200
>  @itemx -mlzcnt
>  @opindex mlzcnt
> @@ -27948,6 +27969,9 @@ preferred alignment to @option{-mpreferr
>  @itemx -mrtm
>  @opindex mrtm
>  @need 200
> +@itemx -mhle
> +@opindex mhle
> +@need 200
>  @itemx -mtbm
>  @opindex mtbm
>  @need 200
> @@ -27987,17 +28011,28 @@ preferred alignment to @option{-mpreferr
>  @itemx -mavx512vpopcntdq
>  @opindex mavx512vpopcntdq
>  @need 200
> +@itemx -mavx5124fmaps
> +@opindex mavx5124fmaps
> +@need 200
> +@itemx -mavx512vnni
> +@opindex mavx512vnni
> +@need 200
> +@itemx -mavx5124vnniw
> +@opindex mavx5124vnniw
> +@need 200
>  @itemx -mcldemote
>  @opindex mcldemote
>  These switches enable the use of instructions in the MMX, SSE,
> -SSE2, SSE3, SSSE3, SSE4.1, AVX, AVX2, AVX512F, AVX512PF, AVX512ER, AVX512CD,
> -SHA, AES, PCLMUL, FSGSBASE, PTWRITE, RDRND, F16C, FMA, SSE4A, FMA4, XOP, 
> LWP, ABM,
> -AVX512VL, AVX512BW, AVX512DQ, AVX512IFMA, AVX512VBMI, BMI, BMI2, VAES, 
> WAITPKG,
> -FXSR, XSAVE, XSAVEOPT, LZCNT, RTM, MWAITX, PKU, IBT, SHSTK, AVX512VBMI2,
> -GFNI, VPCLMULQDQ, AVX512BITALG, MOVDIRI, MOVDIR64B,
> -AVX512VPOPCNTDQ, CLDEMOTE, 3DNow!@: or enhanced 3DNow!@: extended 

Re: [PATCH PR88932]Fix ICE by sorting chain refs in Dom order

[Richard Biener]

On Mon, Jan 28, 2019 at 2:39 AM bin.cheng  wrote:
>
> Hi,
> This simple patch fixes the ICE by getting loop bbs in dominance order and 
> sorting
> chain references against it.  Previously it didn't take dominance in 
> consideration for
> loop thus resulted in use-before-def issue.
> After looking at the code closer, I think sorting references isn't necessary, 
> what we
> need actually is to find the most dominant reference in the length=0 
> sub-chain. In
> other words, we only need a linear scan here, rather than quadratic sorting.  
> I will
> try to revise it in next Stage1.
>
> Bootstrap and test on x86_64, is it OK?

OK.

Richard.

> Thanks,
> bin
> 2019-01-28  Bin Cheng  
>
> PR tree-optimization/88932
> * tree-predcom.c (try_combine_chains): Get loop bbs in dom order.
>
> 2019-01-28  Bin Cheng  
>
> PR tree-optimization/88932
> * gfortran.dg/pr88932.f90: New test.

[PATCH] Add various missing x86 ISA options to doc/{invoke,extend}.texi (PR target/89073)

[Jakub Jelinek]

Hi!

The documentation has several lists of x86 ISA options and various options
were missing from them.  The PR was mainly about missing options in x86
target attribute section, which missed a lot of the options, but for each
of the missing ones I've also double checked invoke.texi - some options were
missing there, one had missing @opindex and some of them were listed in the
list, but in the description weren't actually listed or were listed in
different order.

Tested on x86_64-linux with make doc, ok for trunk?

2019-01-28  Jakub Jelinek  

PR target/89073
* doc/invoke.texi (-mclwb, -mprfchw, -mrdpid, -mrdseed, -msgx,
-madx, -mhle, -mavx5124fmaps, -mavx512vnni, -mavx5124vnniw): Document
x86 ISA options.
(bmi2): Add missing @opindex.
* doc/extend.texi (x86 target attribute): Move fma4, lwp, ssse3
options alphabetically.  Add missing 3dnow, 3dnowa, adx, avx, avx2,
avx5124fmaps, avx5124vnniw, avx512bitalg, avx512bw, avx512cd,
avx512dq, avx512er, avx512f, avx512ifma, avx512pf, avx512vbmi,
avx512vbmi2, avx512vl, avx512vnni, avx512vpopcntdq, bmi, bmi2,
cldemote, clflushopt, clwb, clzero, crc32, cx16, f16c, fma, fsgsbase,
fxsr, gfni, hle, lzcnt, movbe, movdir64b, movdiri, mwaitx, pconfig,
pku, prefetchwt1, prfchw, ptwrite, rdpid, rdrnd, rdseed, rtm, sahf,
sgx, sha, shstk, tbm, vaes, vpclmulqdq, waitpkg, wbnoinvd, xsave,
xsavec, xsaveopt and xsaves options.

--- gcc/doc/invoke.texi.jj  2019-01-23 09:34:35.954725873 +0100
+++ gcc/doc/invoke.texi 2019-01-28 10:18:41.017990421 +0100
@@ -1266,12 +1266,14 @@ See RS/6000 and PowerPC Options.
 -mavx2  -mavx512f  -mavx512pf  -mavx512er  -mavx512cd  -mavx512vl @gol
 -mavx512bw  -mavx512dq  -mavx512ifma  -mavx512vbmi  -msha  -maes @gol
 -mpclmul  -mfsgsbase  -mrdrnd  -mf16c  -mfma  -mpconfig  -mwbnoinvd  @gol
--mptwrite  -mprefetchwt1  -mclflushopt  -mxsavec  -mxsaves @gol
+-mptwrite  -mprefetchwt1  -mclflushopt  -mclwb  -mxsavec  -mxsaves @gol
 -msse4a  -m3dnow  -m3dnowa  -mpopcnt  -mabm  -mbmi  -mtbm  -mfma4  -mxop @gol
--mlzcnt  -mbmi2  -mfxsr  -mxsave  -mxsaveopt  -mrtm  -mlwp @gol
+-madx  -mlzcnt  -mbmi2  -mfxsr  -mxsave  -mxsaveopt  -mrtm  -mhle  -mlwp @gol
 -mmwaitx  -mclzero  -mpku  -mthreads  -mgfni  -mvaes  -mwaitpkg @gol
 -mshstk -mmanual-endbr -mforce-indirect-call  -mavx512vbmi2 @gol
 -mvpclmulqdq  -mavx512bitalg  -mmovdiri  -mmovdir64b  -mavx512vpopcntdq @gol
+-mavx5124fmaps  -mavx512vnni  -mavx5124vnniw  -mprfchw  -mrdpid @gol
+-mrdseed  -msgx @gol
 -mcldemote  -mms-bitfields  -mno-align-stringops  -minline-all-stringops @gol
 -minline-stringops-dynamically  -mstringop-strategy=@var{alg} @gol
 -mmemcpy-strategy=@var{strategy}  -mmemset-strategy=@var{strategy} @gol
@@ -27877,6 +27879,9 @@ preferred alignment to @option{-mpreferr
 @itemx -mclflushopt
 @opindex mclflushopt
 @need 200
+@itemx -mclwb
+@opindex mclwb
+@need 200
 @itemx -mfsgsbase
 @opindex mfsgsbase
 @need 200
@@ -27901,9 +27906,21 @@ preferred alignment to @option{-mpreferr
 @itemx -mfma4
 @opindex mfma4
 @need 200
+@itemx -mprfchw
+@opindex mprfchw
+@need 200
+@itemx -mrdpid
+@opindex mrdpid
+@need 200
 @itemx -mprefetchwt1
 @opindex mprefetchwt1
 @need 200
+@itemx -mrdseed
+@opindex mrdseed
+@need 200
+@itemx -msgx
+@opindex msgx
+@need 200
 @itemx -mxop
 @opindex mxop
 @need 200
@@ -27922,10 +27939,14 @@ preferred alignment to @option{-mpreferr
 @itemx -mabm
 @opindex mabm
 @need 200
+@itemx -madx
+@opindex madx
+@need 200
 @itemx -mbmi
 @opindex mbmi
 @need 200
 @itemx -mbmi2
+@opindex mbmi2
 @need 200
 @itemx -mlzcnt
 @opindex mlzcnt
@@ -27948,6 +27969,9 @@ preferred alignment to @option{-mpreferr
 @itemx -mrtm
 @opindex mrtm
 @need 200
+@itemx -mhle
+@opindex mhle
+@need 200
 @itemx -mtbm
 @opindex mtbm
 @need 200
@@ -27987,17 +28011,28 @@ preferred alignment to @option{-mpreferr
 @itemx -mavx512vpopcntdq
 @opindex mavx512vpopcntdq
 @need 200
+@itemx -mavx5124fmaps
+@opindex mavx5124fmaps
+@need 200
+@itemx -mavx512vnni
+@opindex mavx512vnni
+@need 200
+@itemx -mavx5124vnniw
+@opindex mavx5124vnniw
+@need 200
 @itemx -mcldemote
 @opindex mcldemote
 These switches enable the use of instructions in the MMX, SSE,
-SSE2, SSE3, SSSE3, SSE4.1, AVX, AVX2, AVX512F, AVX512PF, AVX512ER, AVX512CD,
-SHA, AES, PCLMUL, FSGSBASE, PTWRITE, RDRND, F16C, FMA, SSE4A, FMA4, XOP, LWP, 
ABM,
-AVX512VL, AVX512BW, AVX512DQ, AVX512IFMA, AVX512VBMI, BMI, BMI2, VAES, WAITPKG,
-FXSR, XSAVE, XSAVEOPT, LZCNT, RTM, MWAITX, PKU, IBT, SHSTK, AVX512VBMI2,
-GFNI, VPCLMULQDQ, AVX512BITALG, MOVDIRI, MOVDIR64B,
-AVX512VPOPCNTDQ, CLDEMOTE, 3DNow!@: or enhanced 3DNow!@: extended instruction
-sets. Each has a corresponding @option{-mno-} option to disable use of these
-instructions.
+SSE2, SSE3, SSSE3, SSE4, SSE4A, SSE4.1, SSE4.2, AVX, AVX2, AVX512F, AVX512PF,
+AVX512ER, AVX512CD, AVX512VL, AVX512BW, AVX512DQ, AVX512IFMA, AVX512VBMI, SHA,
+AES, PCLMUL, CLFLUSHOPT, CLWB, FSGSBASE, PTWRITE, RDRND, F16C, FMA, 

Re: C++ PATCH for c++/89024 - ICE with incomplete enum type

[Christophe Lyon]

On Sun, 27 Jan 2019 at 01:25, Jason Merrill  wrote:
>
> On Fri, Jan 25, 2019 at 6:22 PM Marek Polacek  wrote:
> >
> > On Fri, Jan 25, 2019 at 12:14:07PM -0500, Jason Merrill wrote:
> > > On 1/25/19 12:09 PM, Marek Polacek wrote:
> > > > On Fri, Jan 25, 2019 at 10:55:55AM -0600, Tim Song wrote:
> > > > > On Thu, Jan 24, 2019 at 4:14 PM Jason Merrill  
> > > > > wrote:
> > > > > >
> > > > > > On 1/24/19 2:16 PM, Marek Polacek wrote:
> > > > > > > This test ICEs since r159006 which added
> > > > > > >
> > > > > > >  type = ENUM_UNDERLYING_TYPE (type);
> > > > > > >
> > > > > > > to type_promotes_to.  In this test ENUM_UNDERLYING_TYPE is null 
> > > > > > > because we
> > > > > > > haven't yet parsed '}' of the enum and the underlying type isn't 
> > > > > > > fixed, and
> > > > > > > so checking TYPE_UNSIGNED crashed.
> > > > > > >
> > > > > > > I've added some checks to the test to see if the types seem to be 
> > > > > > > OK; clang++
> > > > > > > agrees.
> > > > > > >
> > > > > > > Bootstrapped/regtested on x86_64-linux, ok for trunk/8/7?
> > > > > > >
> > > > > > > 2019-01-24  Marek Polacek  
> > > > > > >
> > > > > > >PR c++/89024 - ICE with incomplete enum type.
> > > > > > >* cvt.c (type_promotes_to): Check if prom is non-null.
> > > > > >
> > > > > > 9.6/6: An enumeration whose underlying type is not fixed is an
> > > > > > incomplete type from its point of declaration to immediately after 
> > > > > > the
> > > > > > closing } of its enum-specifier, at which point it becomes a 
> > > > > > complete type.
> > > > > >
> > > > > > So the conversion is ill-formed.
> > > > > >
> > > > > > Jason
> > > > >
> > > > > But the conversion in the example (in
> > > > > decltype(__test_aux<_To1>(declval<_From1>(
> > > > > is in a SFINAE context, so shouldn't it gracefully fall back to the
> > > > > `(...)` overload?
> > > >
> > > > I think so, and clang++ and icc also compile the testcase fine (and we 
> > > > used to
> > > > too, before r159006).
> > >
> > > Absolutely, the conversion being ill-formed means substitution fails, and 
> > > we
> > > reject that candidate.  I meant that we shouldn't get as far as
> > > type_promotes_to for an incomplete type.
> >
> > Makes sense.  So here's another attempt:
> >
> > Bootstrapped/regtested on x86_64-linux, ok for trunk?
> >
> > 2019-01-25  Marek Polacek  
> >
> > PR c++/89024 - ICE with incomplete enum type.
> > * call.c (standard_conversion): When converting an
> > ARITHMETIC_TYPE_P to an incomplete type, return NULL.
>
> OK.
>

Hi,
The new test fails on arm-eabi (with newlib, but passes on on arm*linux*):
FAIL: g++.dg/cpp0x/enum37.C  -std=c++14 (test for excess errors)
FAIL: g++.dg/cpp0x/enum37.C  -std=c++17 (test for excess errors)

The log says:
/gcc/testsuite/g++.dg/cpp0x/enum37.C:24:41: error: aggregate
'same s2' has incomplete type and cannot
be defined

Christophe


> Jason

[PATCH] Fix PR89076

[Richard Biener]

Committed as obvious.

Richard.

2019-01-28  Richard Biener  

PR debug/89076
* dwarf2out.c (gen_subprogram_die): Remove leftover from MPX
support removal.

Index: gcc/dwarf2out.c
===
--- gcc/dwarf2out.c (revision 268332)
+++ gcc/dwarf2out.c (working copy)
@@ -23267,8 +23267,6 @@ gen_subprogram_die (tree decl, dw_die_re
 
  parm = DECL_CHAIN (parm);
}
- else if (parm)
-   parm = DECL_CHAIN (parm);
 
  if (generic_decl_parm)
generic_decl_parm = DECL_CHAIN (generic_decl_parm);

[libbacktrace] Fix and simplify xcoff_%.c pattern rule

[Tom de Vries]

[ was: Re: [backtrace] Avoid segfault  ]
On 27-01-19 22:53, Ian Lance Taylor wrote:
> On Sun, Jan 27, 2019 at 1:16 PM Tom de Vries  wrote:
>>
>> On 25-01-19 18:15, Nathan Sidwell wrote:
>>> On 1/25/19 5:28 AM, Tom de Vries wrote:

 This patch fixes it by passing "" instead of NULL, in the call to
 elf_add at line 3083 (for .gnu_debugaltlink), not the call to elf_add at
 line 3044 (for .gnu_debuglink) mentioned above.

 Nathan, does this fix the problem for you? If not, can you provide a
 reproducer, or give a hint on how one could be constructed?
>>>
>>> I still hit the problem, and am installing this as sufficiently obvious.
>>>  I'm on a fedora system debugging pr88995.  The debuglink_name is
>>> "../../.dwz/isl-0.16.1-7.fc29.x86_64"
>>>
>>
>> I've managed to reproduce this segfault instance by adding a test-case
>> that uses both build-id and dwz.
>>
>> OK for trunk?
> 
>> +elf_for_test.c: elf.c
>> + PWD=$$(pwd -P); \
>> + BUILD_ID_DIR="usr/lib/debug/.build-id/"; \
>> + SEARCH='#define SYSTEM_BUILD_ID_DIR'; \
>> + REPLACE="#define SYSTEM_BUILD_ID_DIR \"$$PWD/$$BUILD_ID_DIR\""; \
>> + $(SED) "s%^$$SEARCH.*\$$%$$REPLACE%" \
>> + $< \
>> + > $@
> 
> You need to use a temporary file, such as $@.tmp, for the final sed
> command, followed by a mv to $@.  Otherwise a failure in the sed will
> leave what appears to be an up to date file.

I noticed the same problem in the xcoff_%.c pattern rule.

OK for trunk?

Thanks,
- Tom

[libbacktrace] Fix and simplify xcoff_%.c pattern rule

When generating xcoff_%.c, the last command is a sed command.  In case of a
sed failure, this will leave an incomplete file, which will appear as up to
date to make, so consequently it will not be regenerated.  Fix this by
sedding into a temporary file instead.

Also, use $< to access the prerequisite xcoff.c, instead of spelling out the
file name once more.

2019-01-28  Tom de Vries  

	* Makefile.am (xcoff_%.c): Generate sed result into temporary file.
	Use $< to access prerequisite.
	* Makefile.in: Regenerate.

---
 libbacktrace/Makefile.am | 5 +++--
 libbacktrace/Makefile.in | 5 +++--
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/libbacktrace/Makefile.am b/libbacktrace/Makefile.am
index 997a535dff4..0d5b3193e25 100644
--- a/libbacktrace/Makefile.am
+++ b/libbacktrace/Makefile.am
@@ -108,8 +108,9 @@ xcoff_%.c: xcoff.c
 	REPLACE='#undef BACKTRACE_XCOFF_SIZE\
 	#define BACKTRACE_XCOFF_SIZE'; \
 	$(SED) "s/^$$SEARCH\$$/$$REPLACE $*/" \
-		$(srcdir)/xcoff.c \
-		> $@
+		$< \
+		> $@.tmp
+	mv $@.tmp $@
 
 test_elf_SOURCES = test_format.c testlib.c
 test_elf_LDADD = libbacktrace_noformat.la elf.lo
diff --git a/libbacktrace/Makefile.in b/libbacktrace/Makefile.in
index f04577066f8..b25ac92aeda 100644
--- a/libbacktrace/Makefile.in
+++ b/libbacktrace/Makefile.in
@@ -1754,8 +1754,9 @@ uninstall-am:
 @NATIVE_TRUE@	REPLACE='#undef BACKTRACE_XCOFF_SIZE\
 @NATIVE_TRUE@	#define BACKTRACE_XCOFF_SIZE'; \
 @NATIVE_TRUE@	$(SED) "s/^$$SEARCH\$$/$$REPLACE $*/" \
-@NATIVE_TRUE@		$(srcdir)/xcoff.c \
-@NATIVE_TRUE@		> $@
+@NATIVE_TRUE@		$< \
+@NATIVE_TRUE@		> $@.tmp
+@NATIVE_TRUE@	mv $@.tmp $@
 
 @NATIVE_TRUE@instrumented_alloc.lo: alloc.c
 

[PATCH] Fix PR89064

[Richard Biener]

XFAILed on trunk as well.  Somehow I missed this.

Richard.

2019-01-28  Richard Biener  

PR testsuite/89064
PR tree-optimization/86865
* testsuite/libgomp.graphite/force-parallel-5.c: XFAIL.

Index: libgomp/testsuite/libgomp.graphite/force-parallel-5.c
===
--- libgomp/testsuite/libgomp.graphite/force-parallel-5.c   (revision 
268332)
+++ libgomp/testsuite/libgomp.graphite/force-parallel-5.c   (working copy)
@@ -31,6 +31,6 @@ int main(void)
 }
 
 /* Check that parallel code generation part make the right answer.  */
-/* { dg-final { scan-tree-dump-times "2 loops carried no dependency" 1 
"graphite" } } */
+/* { dg-final { scan-tree-dump-times "2 loops carried no dependency" 1 
"graphite" { xfail *-*-* } } } */
 /* { dg-final { scan-tree-dump-times "loopfn.0" 4 "optimized" } } */
 /* { dg-final { scan-tree-dump-times "loopfn.1" 4 "optimized" } } */

Re: [PATCH] Fix PR87295

[Richard Biener]

On Sat, 26 Jan 2019, Jason Merrill wrote:

> On Fri, Jan 25, 2019 at 7:57 AM Richard Biener  wrote:
> >
> > The following fixes an ICE with -flto -ffat-lto-objects
> > -fdebug-types-section -g where optimize_external_refs does not
> > expect to see DW_AT_signature as made "local" by build_abbrev_table(sic!).
> >
> > This is because we run optimize_external_refs twice in this setup.
> >
> > The fix is to make the second run not pick up "local" DW_AT_signature
> > as external.  Alternatively build_abbrev_table could be adjusted
> > to not keep those as DW_AT_signature.  It's not even clear to me
> > whether a DW_AT_signature as we output it is valid DWARF ...
> > to quote non-LTO -g:
> >
> >  <1><1d>: Abbrev Number: 13 (DW_TAG_structure_type)
> > <1e>   DW_AT_name: (indirect string, offset: 0x8b):
> > integral_constant
> > <22>   DW_AT_signature   : <0x5d>
> 
> Yes, that seems pretty clearly wrong.  It doesn't make sense for
> DW_AT_signature to be a local reference; it should only have
> DW_FORM_ref_sig8.

OK, thus the fix below is then obvious.

> > <26>   DW_AT_declaration : 1
> > <26>   DW_AT_sibling : <0x48>
> > ...
> >  <1><5d>: Abbrev Number: 16 (DW_TAG_structure_type)
> > <5e>   DW_AT_name: (indirect string, offset: 0x8b):
> > integral_constant
> > <62>   DW_AT_signature   : signature: 0x1f6a4ae7cc5a362e
> > <6a>   DW_AT_declaration : 1
> > <6a>   DW_AT_sibling : <0x7b>
> 
> And there's no reason to have two skeleton DIEs for the same type.
> 
> > Of course the main "issue" is that copy_unworthy_types
> > duplicated this parent into 1d and 5d in the first place
> > (but that's a pure optimization issue?).
> 
> Indeed.
> 
> > Not doing that
> > would have avoided the situation in PR87295.  But then
> > why should optimize_external_refs_1 have this special
> > code handling DW_AT_signature in the first place if this
> > was not intended...  (so even better, kill that and the
> > build_abbrev_table optimization and fix copy_unworthy_types?)
> 
> The point of optimize_external_refs_1 is to remember when we've seen a
> skeleton DIE so we can refer to it from other DIEs in the same unit
> rather than use DW_FORM_ref_sig8.  The problem is just that we get two
> skeleton DIEs so we wrongly change one to refer to the other.  One
> possibility would be to suppress the local reference optimization for
> DW_AT_signature, but avoiding the redundant skeleton should fix the
> problem and also save space.

I'll avoid the bogus DW_AT_signature change for now and see if I
can come up with a fix for the duplicate as followup.  I'm going
to backport the fix to the 8 branch and on trunk if I manage to
avoid the duplicate change the fix to assert we do not try to
replace a DW_AT_signature refrence instead.

> > Oh, and insert rants of -fdebug-types-section not being
> > used by anybody.
> 
> Jakub, what's your thinking on -fdebug-types-section these days?

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

Richard.

2019-01-28  Richard Biener  

PR debug/87295
* dwarf2out.c (optimize_external_refs_1): Do not pick up
already optimized DW_AT_signature refs.

* g++.dg/lto/pr87295_0.C: New testcase.

Index: gcc/dwarf2out.c
===
--- gcc/dwarf2out.c (revision 268260)
+++ gcc/dwarf2out.c (working copy)
@@ -9018,9 +9018,12 @@ build_abbrev_table (dw_die_ref die, exte
 
   /* Scan the DIE references, and replace any that refer to
  DIEs from other CUs (i.e. those which are not marked) with
- the local stubs we built in optimize_external_refs.  */
+ the local stubs we built in optimize_external_refs.
+ But avoid redirecting any references to type units from
+ duplicate local stubs we might have inadvertently created.  */
   FOR_EACH_VEC_SAFE_ELT (die->die_attr, ix, a)
-if (AT_class (a) == dw_val_class_die_ref
+if (a->dw_attr != DW_AT_signature
+   && AT_class (a) == dw_val_class_die_ref
&& (c = AT_ref (a))->die_mark == 0)
   {
struct external_ref *ref_p;
Index: gcc/testsuite/g++.dg/lto/pr87295_0.C
===
--- gcc/testsuite/g++.dg/lto/pr87295_0.C(nonexistent)
+++ gcc/testsuite/g++.dg/lto/pr87295_0.C(working copy)
@@ -0,0 +1,20 @@
+// { dg-lto-do assemble }
+// { dg-lto-options { { -flto -ffat-lto-objects -fdebug-types-section -g 
-std=gnu++17 } } }
+
+template
+struct integral_constant
+{
+  static constexpr _Tp value = __v;
+  typedef _Tp value_type;
+  constexpr operator value_type() const noexcept { return value; }
+};
+
+typedef integral_constant false_type;
+
+template
+struct __or_;
+
+template<>
+struct __or_<>
+  : public false_type
+{ };

[PATCH] Fix PR88739

[Richard Biener]

This restricts BIT_FIELD_REFs we create to ones operating on
mode-precision entities (iff INTEGRAL_TYPE_P).  This avoids
issues with endianess when expanding them.

No testcase, BE folks have to come up with sth suitable for
the testsuite.

Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk,
queued for backporting (w/o the checking hunks).

Richard.

2019-01-28  Richard Biener  

PR tree-optimization/88739
* tree-cfg.c (verify_types_in_gimple_reference): Verify
BIT_FIELD_REFs only are applied to mode-precision operands
when they are integral.
(verify_gimple_assign_ternary): Likewise for BIT_INSERT_EXPR.
* tree-ssa-sccvn.c (vn_reference_lookup_3): Avoid generating
BIT_FIELD_REFs of non-mode-precision integral operands.

Index: gcc/tree-cfg.c
===
--- gcc/tree-cfg.c  (revision 268257)
+++ gcc/tree-cfg.c  (working copy)
@@ -3118,6 +3118,12 @@ verify_types_in_gimple_reference (tree e
 "match field size of BIT_FIELD_REF");
  return true;
}
+ if (INTEGRAL_TYPE_P (TREE_TYPE (op))
+ && !type_has_mode_precision_p (TREE_TYPE (op)))
+   {
+ error ("BIT_FIELD_REF of non-mode-precision operand");
+ return true;
+   }
  if (!AGGREGATE_TYPE_P (TREE_TYPE (op))
  && maybe_gt (size + bitpos,
   tree_to_poly_uint64 (TYPE_SIZE (TREE_TYPE (op)
@@ -4319,6 +4325,12 @@ verify_gimple_assign_ternary (gassign *s
  error ("invalid position or size in BIT_INSERT_EXPR");
  return true;
}
+  if (INTEGRAL_TYPE_P (rhs1_type)
+ && !type_has_mode_precision_p (rhs1_type))
+   {
+ error ("BIT_INSERT_EXPR into non-mode-precision operand");
+ return true;
+   }
   if (INTEGRAL_TYPE_P (rhs1_type))
{
  unsigned HOST_WIDE_INT bitpos = tree_to_uhwi (rhs3);
Index: gcc/tree-ssa-sccvn.c
===
--- gcc/tree-ssa-sccvn.c(revision 268257)
+++ gcc/tree-ssa-sccvn.c(working copy)
@@ -2298,6 +2298,7 @@ vn_reference_lookup_3 (ao_ref *ref, tree
   base2 = get_ref_base_and_extent (gimple_assign_lhs (def_stmt),
   , , ,
   );
+  tree def_rhs = gimple_assign_rhs1 (def_stmt);
   if (!reverse
  && known_size_p (maxsize2)
  && known_eq (maxsize2, size2)
@@ -2309,11 +2310,13 @@ vn_reference_lookup_3 (ao_ref *ref, tree
 according to endianness.  */
  && (! INTEGRAL_TYPE_P (vr->type)
  || known_eq (ref->size, TYPE_PRECISION (vr->type)))
- && multiple_p (ref->size, BITS_PER_UNIT))
+ && multiple_p (ref->size, BITS_PER_UNIT)
+ && (! INTEGRAL_TYPE_P (TREE_TYPE (def_rhs))
+ || type_has_mode_precision_p (TREE_TYPE (def_rhs
{
  gimple_match_op op (gimple_match_cond::UNCOND,
  BIT_FIELD_REF, vr->type,
- vn_valueize (gimple_assign_rhs1 (def_stmt)),
+ vn_valueize (def_rhs),
  bitsize_int (ref->size),
  bitsize_int (offset - offset2));
  tree val = vn_nary_build_or_lookup ();