[Bug other/86198] Libbacktrace does not properly work with ".note.gnu.build-id" section

[chefmax at gcc dot gnu.org]

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

--- Comment #4 from chefmax at gcc dot gnu.org ---
Author: chefmax
Date: Thu Jun 21 05:42:53 2018
New Revision: 261832

URL: https://gcc.gnu.org/viewcvs?rev=261832=gcc=rev
Log:
libbacktrace/

2018-06-21 Denis Khalikov 

PR other/86198
* elf.c (elf_add): Increase ".note.gnu.build-id" section size
checking up to 36 bytes.

Modified:
trunk/libbacktrace/ChangeLog
trunk/libbacktrace/elf.c

Fix safe iterator inconsistent assertion

[François Dumont]

Working on iterator == operator I noticed that a comparison in 
_Safe_iterator was inconsistent.


    * include/debug/debug.h
    (_Safe_iterator<>(const _Safe_iterator<_MutableIterator,>& __x)):
    Compare __x base iterator with a default initialized iterator of the
    same type.

Tested under linux x86_64.

François

Index: ChangeLog
===
--- ChangeLog	(revision 261830)
+++ ChangeLog	(working copy)
@@ -1,3 +1,10 @@
+2018-06-21  François Dumont  
+
+	* include/debug/debug.h
+	(_Safe_iterator<>(const _Safe_iterator<_MutableIterator,>& __x)):
+	Compare __x base iterator with a default initialized iterator of the
+	same type.
+
 2018-06-20  Jonathan Wakely  
 
 	PR libstdc++/70966
Index: include/debug/safe_iterator.h
===
--- include/debug/safe_iterator.h	(revision 261830)
+++ include/debug/safe_iterator.h	(working copy)
@@ -180,7 +180,7 @@
 	  // _GLIBCXX_RESOLVE_LIB_DEFECTS
 	  // DR 408. Is vector > forbidden?
 	  _GLIBCXX_DEBUG_VERIFY(!__x._M_singular()
-|| __x.base() == _Iterator(),
+|| __x.base() == _MutableIterator(),
 _M_message(__msg_init_const_singular)
 ._M_iterator(*this, "this")
 ._M_iterator(__x, "other"));

[Bug debug/86258] New: Program compiled with fPIC crashes while stepping over thread-local variable GDB

[jlangan at progress dot com]

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

Bug ID: 86258
   Summary: Program compiled with fPIC crashes while stepping over
thread-local variable GDB
   Product: gcc
   Version: 4.4.7
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jlangan at progress dot com
  Target Milestone: ---

A detailed description (not mine) and workaround can be found at the address
seen below: (credit goes to those contributors). However, I need an official
patch for this - hence this request

The description starts with:
-
This is a very strange problem which occurs only when the program is compiled
with -fPIC option.

Using gdb I'm able to print thread local variables but stepping over them leads
to crash.

https://stackoverflow.com/questions/33429912/program-compiled-with-fpic-crashes-while-stepping-over-thread-local-variable-in/33557963#comment54798247_334
--

I am also seeing the same issue on the following:

Platform information 
Linux 2.6.32-504.el6.x86_64 #1 SMP Wed Oct 15 04:27:16 UTC 2014 x86_64 x86_64
x86_64 GNU/Linux

gcc -v
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-ppl --with-cloog --with-tune=generic --with-arch_32=i686
--build=x86_64-redhat-linux
Thread model: posix
gcc version 4.4.7 20120313 (Red Hat 4.4.7-16) (GCC)

and also with the following
$/opt/rh/devtoolset-3/root/usr/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/opt/rh/devtoolset-3/root/usr/bin/gcc
COLLECT_LTO_WRAPPER=/opt/rh/devtoolset-3/root/usr/libexec/gcc/x86_64-redhat-linux/4.9.2/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/opt/rh/devtoolset-3/root/usr
--mandir=/opt/rh/devtoolset-3/root/usr/share/man
--infodir=/opt/rh/devtoolset-3/root/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap
--enable-shared --enable-threads=posix --enable-checking=release
--enable-multilib --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --enable-languages=c,c++,fortran,lto --enable-plugin
--with-linker-hash-style=gnu --enable-initfini-array --disable-libgcj
--with-isl=/builddir/build/BUILD/gcc-4.9.2-20150212/obj-x86_64-redhat-linux/isl-install
--with-cloog=/builddir/build/BUILD/gcc-4.9.2-20150212/obj-x86_64-redhat-linux/cloog-install
--with-mpc=/builddir/build/BUILD/gcc-4.9.2-20150212/obj-x86_64-redhat-linux/mpc-install
--with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.9.2 20150212 (Red Hat 4.9.2-6) (GCC)

[Bug debug/86257] New: Program compiled with fPIC crashes while stepping over thread-local variable GDB

[jlangan at progress dot com]

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

Bug ID: 86257
   Summary: Program compiled with fPIC crashes while stepping over
thread-local variable GDB
   Product: gcc
   Version: 4.4.7
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jlangan at progress dot com
  Target Milestone: ---

A detailed description (not mine) and workaround can be found at the following
address: (credit goes to those contributors). However, I need an official patch
for this - hence this request

The description starts with:
This is a very strange problem which occurs only when the program is compiled
with -fPIC option.

Using gdb I'm able to print thread local variables but stepping over them leads
to crash.

https://stackoverflow.com/questions/33429912/program-compiled-with-fpic-crashes-while-stepping-over-thread-local-variable-in/33557963#comment54798247_334

I am also seeing the same issue on the following:

Platform information 
Linux 2.6.32-504.el6.x86_64 #1 SMP Wed Oct 15 04:27:16 UTC 2014 x86_64 x86_64
x86_64 GNU/Linux

gcc -v
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-ppl --with-cloog --with-tune=generic --with-arch_32=i686
--build=x86_64-redhat-linux
Thread model: posix
gcc version 4.4.7 20120313 (Red Hat 4.4.7-16) (GCC)

I also tried this with the following
$/opt/rh/devtoolset-3/root/usr/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/opt/rh/devtoolset-3/root/usr/bin/gcc
COLLECT_LTO_WRAPPER=/opt/rh/devtoolset-3/root/usr/libexec/gcc/x86_64-redhat-linux/4.9.2/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/opt/rh/devtoolset-3/root/usr
--mandir=/opt/rh/devtoolset-3/root/usr/share/man
--infodir=/opt/rh/devtoolset-3/root/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap
--enable-shared --enable-threads=posix --enable-checking=release
--enable-multilib --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --enable-languages=c,c++,fortran,lto --enable-plugin
--with-linker-hash-style=gnu --enable-initfini-array --disable-libgcj
--with-isl=/builddir/build/BUILD/gcc-4.9.2-20150212/obj-x86_64-redhat-linux/isl-install
--with-cloog=/builddir/build/BUILD/gcc-4.9.2-20150212/obj-x86_64-redhat-linux/cloog-install
--with-mpc=/builddir/build/BUILD/gcc-4.9.2-20150212/obj-x86_64-redhat-linux/mpc-install
--with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.9.2 20150212 (Red Hat 4.9.2-6) (GCC)

[Bug c++/86256] New: Lambda will not add ref count for class intelligent pointer member when capture 'this' or & as argument

[kangchuanbo at 126 dot com]

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

Bug ID: 86256
   Summary: Lambda will not add ref count for class intelligent
pointer member when capture 'this' or & as argument
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kangchuanbo at 126 dot com
  Target Milestone: ---

For example:

#include 
#include 

class A {
public:
A(){
tmp = std::make_shared(1);
}
void start() {
std::cout << "ref count : " << tmp.use_count() << std::endl;
std::shared_ptr tmp2 = tmp;
std::cout << "ref count : " << tmp.use_count() << std::endl;
auto xxfunca = [this]()  { std::cout<<"func1 ref count :
"< tmp;
};

int main()
{
A a;
a.start();
return 0;
}

result and analyse：
[root~]]# ./test
ref count : 1// tmp init ref count = 1
ref count : 2// copy to tmp2，tmp ref count will incrase to 2
ref count : 2// Lambda capture this，tmp ref count no incrase
ref count : 3// Lambda capture tmp2，tmp ref count incrase to 3
ref count : 3// Lambda capture &，tmp ref count no incrase

==
The compiler will not copy class member, may feel too complex to check class
member, but should give warning or error to user when lambda capture Class with
intelligent member, or user may meet null pointer which lead to coredump.
Thanks.

[Bug c++/86255] New: addition of default argument on redeclaration makes this constructor a default constructor

[zhonghao at pku dot org.cn]

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

Bug ID: 86255
   Summary: addition of default argument on redeclaration makes
this constructor a default constructor
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhonghao at pku dot org.cn
  Target Milestone: ---

The code is as follow:

# 3 "bug3.cc"
class Z {
public:


 Z(int);

private:
 int i;
};
Z::Z(int j=43): i(j){}


int main()
{
 Z zobject=Z();

}

clang++ produces the following errors:
 bug3.cc:12:10: error: addition of default argument on redeclaration makes this
constructor a default constructor
Z::Z(int j=43): i(j){}
 ^ ~~
bug3.cc:7:2: note: previous declaration is here

The code comes from a gcc bug report:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=2189

I reported the difference to clang:https://bugs.llvm.org/show_bug.cgi?id=37850

 Richard Smith told me that Clang's diagnostic is correct. So, is this a
recurring bug in g++?

[Bug c++/86254] New: g++ rejects legal code?

[zhonghao at pku dot org.cn]

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

Bug ID: 86254
   Summary: g++ rejects legal code?
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhonghao at pku dot org.cn
  Target Milestone: ---

The code is as follow:

namespace N {
 extern "C" {
 extern const int foobar;
 const int foobar = 1;
 struct S { static const int foobar; };
 const int S::foobar = 2;
 }
}
int main () { return !(N::foobar + 1 == N::S::foobar); }

clang++ accepts the code, but g++ produces error messages:

conflicting declaration of ‘const int N::S::foobar’ with ‘C’ linkage
  const int S::foobar = 2;
previous declaration with ‘C++’ linkage
  struct S { static const int foobar; };

Indeed, the code comes from a bug report of gcc
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33786). A previous version of g++
produces a different error message, but was fixed in the latest version. 

I reported this as a bug in clang: https://bugs.llvm.org/show_bug.cgi?id=37844

However, Richard Smith told me that gcc is wrong. He cited a sentence "A C
language linkage is ignored in determining the language linkage of the names of
class members" to support his statement. This sounds like a specification. So,
is this really a bug in gcc?

[Bug c++/86253] New: N3639 array of runtime bound

[zhonghao at pku dot org.cn]

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

Bug ID: 86253
   Summary: N3639 array of runtime bound
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhonghao at pku dot org.cn
  Target Milestone: ---

The code is as follow:

int main(int argc, char** argv)
{
 int x[1][argc];

 [](int i)
 {
 x[0][i] = 0;
 }(5);

 return 0;
}

clang++ accepts the code, but g++ produces error messages:
capture of variably-modified type ‘int [1][argc]’ that is not an N3639 array of
runtime bound
because the array element type ‘int [argc]’ has variable size

I thought that this is a bug in clang, and reported it to
https://bugs.llvm.org/show_bug.cgi?id=37843

However, Richard Smith told me that clang++ can produce this message, since
clang++ has a feature that GCC's extension lacks. Does gcc have plan to
implement that feature?

[Bug c++/86252] New: Abstract class in function return type

[zhonghao at pku dot org.cn]

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

Bug ID: 86252
   Summary: Abstract class in function return type
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhonghao at pku dot org.cn
  Target Milestone: ---

The code is as follow:

template
struct S{};

struct A
{
 virtual void f() = 0;
};

int main()
{
 S s;
}

An abstract class shall not be used as a function return type, but clang++
accepts the code. 

The code comes from a gcc bug report
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51184).

I reported the problem to clang: https://bugs.llvm.org/show_bug.cgi?id=37833

Richard Smith told me that the language rule changed recently.

Will g++ catch up the so-called rule change?

[Bug c++/86251] New: legal or illegal code?

[zhonghao at pku dot org.cn]

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

Bug ID: 86251
   Summary: legal or illegal code?
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhonghao at pku dot org.cn
  Target Milestone: ---

Clang++ compiles the following code without any error messages:

#include 
#include 

using namespace std;

template 
void foo()
{
cout << __PRETTY_FUNCTION__ << endl;
}

int a = 0;

int b() { cout << __PRETTY_FUNCTION__ << endl; }

int main()
{
foo();
foo();
}

In the contrast, gcc produces the following error message:
‘int()’ is not a valid type for a template non-type parameter foo();

A bug report of gcc (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6030)
discusses more details of this issue.

I believed that clang++ shall add the error message as g++ does, and reported
the bug to https://bugs.llvm.org/show_bug.cgi?id=37829

However, Richard Smith believes that the code is legal, since int() decays to
int(*)(), which is valid.

His analysis seems to be contrary to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6030. Is this a bug in g++?

[Bug c++/86250] New: addition of default argument on redeclaration makes this constructor a default constructor

[zhonghao at pku dot org.cn]

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

Bug ID: 86250
   Summary: addition of default argument on redeclaration makes
this constructor a default constructor
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhonghao at pku dot org.cn
  Target Milestone: ---

The code is as follow:

//#include 
//using namespace std;
class Z {
public:
 // gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) allows to
 // write Z(int) while gcc version 2.97 20010205 wants Z(int j=43)
 Z(int);
 //void print ();
private:
 int i;
};
Z::Z(int j=43): i(j){}
//void Z::print(void){ cout << "Z : i= " << i << ".\n";}

int main()
{
 Z zobject=Z();
 //zobject.print();
}

clang++ rejects, and produces the following error messages:
error: addition of default argument on redeclaration makes this constructor a
default constructor
Z::Z(int j=43): i(j){}
 ^ ~~
note: previous declaration is here

A previous version of gcc also rejects the code. The bug report is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=2189

I reported this problem to clang: https://bugs.llvm.org/show_bug.cgi?id=37869

Richard Smith determined that the test case is ill-formed. So, is this a bug in
gcc, since it accepts ill-formed code?

[Bug c++/86249] New: declaration conflicts with target of using declaration already in scope

[zhonghao at pku dot org.cn]

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

Bug ID: 86249
   Summary: declaration conflicts with target of using declaration
already in scope
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhonghao at pku dot org.cn
  Target Milestone: ---

The code is as follow:

namespace Name {
 template  class Point;
}

using Name::Point;

template  class Point {
 public:
 Point() {}
 protected:
 T member;
};

int main(void) {
 Name::Point d;
 return(0);
}


clang++ rejects the code with error messages:
error: declaration conflicts with target of using declaration already in scope
template  class Point {
error: implicit instantiation of undefined template 'Name::Point'
 Name::Point d;

g++ accepts the code. The code comes from a gcc bug report:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=1876

I thought that it is a clang++ bug, and reported it to
https://bugs.llvm.org/show_bug.cgi?id=37867

Richard Smith determined that this is a gcc bug. Shall gcc repair the bug, if
it is?

Re: [PATCH], PowerPC long double transition patches, v2, Patch #1 (disable long double multilib)

[Segher Boessenkool]

On Wed, Jun 20, 2018 at 10:25:36AM -0400, Michael Meissner wrote:
> This code disables the automatic multilib creation unless you use the
> --with-advance-toolchain= option and the Advance Toolchain directoy has
> been modified to have the lib64/ieee128 and/or lib64/ibm128 directories for
> multilib support.  This allows the multilib to still be created, but it is not
> enabled by default.
> 
> Alternatively, I have a patch that disables the IEEE/IBM long double multilib
> support completely.

So what are the advantages and the disadvantages of both approaches?
And, why do you think this one is preferable?


Segher

[Bug c++/86238] No diagnostic for virtual base class with inaccessible destructor

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Simplified further:

struct B { ~B() {} };
struct C : private virtual B {};
struct D : C {} d;

[Bug c++/86238] No diagnostic for virtual base class with inaccessible destructor

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-06-21
 Ever confirmed|0   |1

Re: [PATCH, rs6000] Fix AIX expected builtin instruction counts

[Carl Love]

Segher:

I believe I have addressed all of your concerns with the patch.

I have retested it and it looks good.

Please let me know if the patch looks OK for GCC mainline. 

 Carl Love


>From 8d354f93c5ddb5161b86e69abb64486657c6c92d Mon Sep 17 00:00:00 2001
From: Carl Love 
Date: Wed, 20 Jun 2018 19:08:23 -0500
Subject: [PATCH] Fix expected instruction counts for tests

gcc/testsuite/ChangeLog:

2018-06-22  Carl Love  

* gcc.target/powerpc/altivec-7.c: Add qualifiers for counts on AIX
versus Linux.  Change checks for xxlnor, xxland and xxlxor to also look
for the vnor, vand and vxor instructions.
* gcc.target/powerpc/builtins-1.c: Move vec_or tests to a new file.
Remove counts for xxlor. Fix match on bl __divdi3 and bl __udivdi3.
* gcc.target/powerpc/builtins-4.c: Fix matching for vsl instructions.
* gcc.target/powerpc/builtins-5.c: New test file for vec_or test cases.
* gcc.target/powerpc/vsx-vector-6.p7.c: Fix xxlnor BE expected count.
Add -dp to dg-options, update expected counts.
---
 gcc/testsuite/gcc.target/powerpc/altivec-7.c   | 15 
 gcc/testsuite/gcc.target/powerpc/builtins-1.c  | 16 ++---
 gcc/testsuite/gcc.target/powerpc/builtins-4.c  |  5 ++-
 gcc/testsuite/gcc.target/powerpc/builtins-5.c  | 40 ++
 gcc/testsuite/gcc.target/powerpc/vsx-vector-6.p7.c | 14 
 5 files changed, 58 insertions(+), 32 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/powerpc/builtins-5.c

diff --git a/gcc/testsuite/gcc.target/powerpc/altivec-7.c 
b/gcc/testsuite/gcc.target/powerpc/altivec-7.c
index b61092c..ebc4a85 100644
--- a/gcc/testsuite/gcc.target/powerpc/altivec-7.c
+++ b/gcc/testsuite/gcc.target/powerpc/altivec-7.c
@@ -73,8 +73,8 @@ int main ()
  vec_unpacklvupkhsh
  vec_unpacklvupkhpx
  vec_unpacklvupkhsb
- vec_andc   xxnor
-xxland
+ vec_andc   xxlnor (vnor AIX)
+xxland (vand AIX)
  vec_vxor   xxlxor
  vec_vmsumubm   vmsumubm
  vec_vmulesbvmulosb
@@ -85,17 +85,16 @@ int main ()
 /* { dg-final { scan-assembler-times "vpkpx" 2 } } */
 /* { dg-final { scan-assembler-times "vmulesb" 1 } } */
 /* { dg-final { scan-assembler-times "vmulosb" 1 } } */
-/* { dg-final { scan-assembler-times {\mlxvd2x\M|\mlxv\M} 42 { target le } } } 
*/
-/* { dg-final { scan-assembler-times {\mlxvd2x\M|\mlxv\M} 4 { target be } } } 
*/
+/* { dg-final { scan-assembler-times {\mlvx\M} 0 { target { powerpc*-*-linux* 
} } } } */
+/* { dg-final { scan-assembler-times {\mlvx\M} 42 { target { powerpc*-*-aix* } 
} } } */
 /* { dg-final { scan-assembler-times "lvewx" 2 } } */
 /* { dg-final { scan-assembler-times "lvxl" 1 } } */
 /* { dg-final { scan-assembler-times "vupklsh" 2 } } */
 /* { dg-final { scan-assembler-times "vupkhsh" 2 } } */
-/* { dg-final { scan-assembler-times "xxlnor" 4 } } */
-/* { dg-final { scan-assembler-times "xxland" 4 } } */
-/* { dg-final { scan-assembler-times "xxlxor" 5 } } */
+/* { dg-final { scan-assembler-times {\mxxlnor\M|\mvnor\M} 4 } } */
+/* { dg-final { scan-assembler-times {\mxxland\M|\mvand\M} 4 } } */
+/* { dg-final { scan-assembler-times {\mxxlxor\M|\mvxor\M} 5 } } */
 /* { dg-final { scan-assembler-times "xxlandc" 0 } } */
-/* { dg-final { scan-assembler-times "lvx" 1 } } */
 /* { dg-final { scan-assembler-times "vmsumubm" 1 } } */
 /* { dg-final { scan-assembler-times "vupklpx" 1 } } */
 /* { dg-final { scan-assembler-times "vupklsx" 0 } } */
diff --git a/gcc/testsuite/gcc.target/powerpc/builtins-1.c 
b/gcc/testsuite/gcc.target/powerpc/builtins-1.c
index 45727b9..3b4b27d 100644
--- a/gcc/testsuite/gcc.target/powerpc/builtins-1.c
+++ b/gcc/testsuite/gcc.target/powerpc/builtins-1.c
@@ -81,14 +81,6 @@ int main ()
   vector unsigned long long uq = vec_nor (ua, ud);
   vector unsigned long long ur = vec_nor (ud, ua);
 
-  vector long long ls = vec_or (la, lb);
-  vector long long lt = vec_or (la, ld);
-  vector long long lu = vec_or (ld, la);
-
-  vector unsigned long long us = vec_or (ua, ub);
-  vector unsigned long long ut = vec_or (ua, ud);
-  vector unsigned long long uu = vec_or (ud, ua);
-
   vector unsigned char ca = {0,4,8,1,5,9,2,6,10,3,7,11,15,12,14,13};
   vector unsigned char cbb = {5,4,8,3,1,9,2,6,10,3,7,11,15,12,14,13};
 
@@ -267,7 +259,6 @@ int main ()
   vector short signed int z_vss1 = vec_splat (ssa, 2);
   vector unsigned short int z_vuss1 = vec_splat (usa, 1);
 
-
   return 0;
 }
 
@@ -296,7 +287,6 @@ int main ()
vec_mergeh  xxmrglw, vmrglh
vec_mul mulld | mullw, mulhwu
vec_nor xxlnor
-   vec_or  xxlor
vec_packsu  vpksdus
vec_

Re: LTO and other test failures on trunk

[David Malcolm]

On Mon, 2018-06-18 at 10:22 -0600, Martin Sebor wrote:
> David,
> 
> Have you been able to reproduce the jit test failures below on
> tor?  Is there some information I can get you from my builds to
> help you debug it?

Thanks for pointing it out.  I've started seeing it on my machine.

They appear to have been due to recent(?) changes to IPA; I've posted a
patch for the issue here:
  "[PATCH] Fix IPA crash in libgccjit"
https://gcc.gnu.org/ml/gcc-patches/2018-06/msg01282.html

Dave

[PATCH] Fix IPA crash in libgccjit

[David Malcolm]

All/most of the jit.dg testcases are segfaulting on cleanup of
the 2nd in-process iteration:

PATH=.:$PATH LD_LIBRARY_PATH=. LIBRARY_PATH=. \
 gdb --args \
   testsuite/jit/test-factorial.c.exe

Starting program: 
/home/david/coding-3/gcc-git-static-analysis/build/gcc/testsuite/jit/test-factorial.c.exe
 
PASSED: test-factorial.c.exe iteration 1 of 5: set_up_logging: logfile 
is non-null
NOTE: test-factorial.c.exe iteration 1 of 5: writing reproducer to 
/home/david/coding-3/gcc-git-static-analysis/build/gcc/testsuite/jit/test-factorial.c.exe.reproducer.c
Detaching after fork from child process 35787.
Detaching after fork from child process 35789.
PASSED: test-factorial.c.exe iteration 1 of 5: verify_code: result is 
non-null
PASSED: test-factorial.c.exe iteration 1 of 5: verify_code: 
my_factorial is non-null
NOTE: my_factorial returned: 3628800
PASSED: test-factorial.c.exe iteration 1 of 5: verify_code: actual: val 
== expected: 3628800
PASSED: test-factorial.c.exe iteration 2 of 5: set_up_logging: logfile 
is non-null
NOTE: test-factorial.c.exe iteration 2 of 5: writing reproducer to 
/home/david/coding-3/gcc-git-static-analysis/build/gcc/testsuite/jit/test-factorial.c.exe.reproducer.c

Program received signal SIGSEGV, Segmentation fault.
0x771abc75 in ipcp_driver () at ../../src/gcc/ipa-cp.c:5091
5091  delete edge_clone_summaries;

This appears to be due to recent(?) IPA changes that appear to assume
that the IPA code is only initialized and cleaned up once.

This patch fixes the crashes:

Changes to jit.sum
--

  FAIL: 65->0 (-65)
  PASS: 3186->10290 (+7104)
  UNRESOLVED: 1->0 (-1)

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.

OK for trunk?

gcc/ChangeLog:
* ipa-cp.c (ipcp_driver): Set edge_clone_summaries to NULL after
deleting it.
* ipa-reference.c (ipa_reference_c_finalize): Delete
ipa_ref_opt_sum_summaries and set it to NULL.
---
 gcc/ipa-cp.c| 1 +
 gcc/ipa-reference.c | 6 ++
 2 files changed, 7 insertions(+)

diff --git a/gcc/ipa-cp.c b/gcc/ipa-cp.c
index c192e84..42dd4cc 100644
--- a/gcc/ipa-cp.c
+++ b/gcc/ipa-cp.c
@@ -5089,6 +5089,7 @@ ipcp_driver (void)
   /* Free all IPCP structures.  */
   free_toporder_info ();
   delete edge_clone_summaries;
+  edge_clone_summaries = NULL;
   ipa_free_all_structures_after_ipa_cp ();
   if (dump_file)
 fprintf (dump_file, "\nIPA constant propagation end\n");
diff --git a/gcc/ipa-reference.c b/gcc/ipa-reference.c
index 9a9e94c..43bbdae 100644
--- a/gcc/ipa-reference.c
+++ b/gcc/ipa-reference.c
@@ -1230,6 +1230,12 @@ make_pass_ipa_reference (gcc::context *ctxt)
 void
 ipa_reference_c_finalize (void)
 {
+  if (ipa_ref_opt_sum_summaries != NULL)
+{
+  delete ipa_ref_opt_sum_summaries;
+  ipa_ref_opt_sum_summaries = NULL;
+}
+
   if (ipa_init_p)
 {
   bitmap_obstack_release (_summary_obstack);
-- 
1.8.5.3

[Bug c++/48665] type of const member function

[redi at gcc dot gnu.org]

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

--- Comment #19 from Jonathan Wakely  ---
No problem, now that Richard raised it on the core reflector we should see the
implementation divergence fixed, which is a Good Thing.

gcc-6-20180620 is now available

[gccadmin]

Snapshot gcc-6-20180620 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/6-20180620/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 6 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-6-branch 
revision 261826

You'll find:

 gcc-6-20180620.tar.xzComplete GCC

  SHA256=1fb3964f685326c13e8a10c3b98c679f3b1e33b1d9f18773525664f8ee926eb5
  SHA1=57baf7bd49cc9f73edc00584adf9c134f0693b63

Diffs from 6-20180613 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-6
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

[Bug libgcc/86213] -fsplit-stack runtime may clobber SSE input param reg

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Ian Lance Taylor  ---
Should be fixed.

Re: [patch] adjust default nvptx launch geometry for OpenACC offloaded regions

[Tom de Vries]

On 06/20/2018 11:59 PM, Cesar Philippidis wrote:
> Now it follows the formula contained in
> the "CUDA Occupancy Calculator" spreadsheet that's distributed with CUDA.

Any reason we're not using the cuda runtime functions to get the
occupancy (see PR85590 - [nvptx, libgomp, openacc] Use cuda runtime fns
to determine launch configuration in nvptx ) ?

Thanks,
- Tom

[Bug c++/48665] type of const member function

[dblaikie at gmail dot com]

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

--- Comment #18 from David Blaikie  ---
Thanks - looks like this got hashed out on the C++ reflector in favor of this
being invalid. The Clang bug has been re-opened to work on the fix there.
Thanks! Sorry for the noise.

[patch] adjust default nvptx launch geometry for OpenACC offloaded regions

[Cesar Philippidis]

At present, the nvptx libgomp plugin does not take into account the
amount of shared resources on GPUs (mostly shared-memory are register
usage) when selecting the default num_gangs and num_workers. In certain
situations, an OpenACC offloaded function can fail to launch if the GPU
does not have sufficient shared resources to accommodate all of the
threads in a CUDA block. This typically manifests when a PTX function
uses a lot of registers and num_workers is set too large, although it
can also happen if the shared-memory has been exhausted by the threads
in a vector.

This patch resolves that issue by adjusting num_workers based the amount
of shared resources used by each threads. If worker parallelism has been
requested, libgomp will spawn as many workers as possible up to 32.
Without this patch, libgomp would always default to launching 32 workers
when worker parallelism is used.

Besides for the worker parallelism, this patch also includes some
heuristics on selecting num_gangs. Before, the plugin would launch two
gangs per GPU multiprocessor. Now it follows the formula contained in
the "CUDA Occupancy Calculator" spreadsheet that's distributed with CUDA.

Is this patch OK for trunk?

Thanks,
Cesar
2018-06-20  Cesar Philippidis  

gcc/
* config/nvptx/nvptx.c (PTX_GANG_DEFAULT): Delete define.
(PTX_DEFAULT_RUNTIME_DIM): New define.
(nvptx_goacc_validate_dims): Use it to allow the runtime to
dynamically allocate num_workers and num_gangs.
(nvptx_dim_limit): Don't impose an arbritary num_workers.

libgomp/
* plugin/plugin-nvptx.c (struct ptx_device): Add
max_threads_per_block, warp_size, max_threads_per_multiprocessor,
max_shared_memory_per_multiprocessor, binary_version,
register_allocation_unit_size, register_allocation_granularity,
compute_capability_major, compute_capability_minor members.
(nvptx_open_device): Probe driver for those values.  Adjust
regs_per_sm and max_shared_memory_per_multiprocessor for K80
hardware. Dynamically allocate default num_workers.
(nvptx_exec): Don't probe the CUDA runtime for the hardware
info.  Use the new variables inside targ_fn_descriptor and
ptx_device instead.  (GOMP_OFFLOAD_load_image): Set num_gangs,
register_allocation_{unit_size,granularity}.  Adjust the
default num_gangs.  Add diagnostic when the hardware cannot
support the requested num_workers.
* plugin/cuda/cuda.h (CUdevice_attribute): Add
CU_DEVICE_ATTRIBUTE_COMPUTE_CAPABILITY_MAJOR,
CU_DEVICE_ATTRIBUTE_COMPUTE_CAPABILITY_MINOR.


diff --git a/gcc/config/nvptx/nvptx.c b/gcc/config/nvptx/nvptx.c
index 5608bee..c1946e7 100644
--- a/gcc/config/nvptx/nvptx.c
+++ b/gcc/config/nvptx/nvptx.c
@@ -5165,7 +5165,7 @@ nvptx_expand_builtin (tree exp, rtx target, rtx ARG_UNUSED (subtarget),
 /* Define dimension sizes for known hardware.  */
 #define PTX_VECTOR_LENGTH 32
 #define PTX_WORKER_LENGTH 32
-#define PTX_GANG_DEFAULT  0 /* Defer to runtime.  */
+#define PTX_DEFAULT_RUNTIME_DIM 0 /* Defer to runtime.  */
 
 /* Implement TARGET_SIMT_VF target hook: number of threads in a warp.  */
 
@@ -5214,9 +5214,9 @@ nvptx_goacc_validate_dims (tree decl, int dims[], int fn_level)
 {
   dims[GOMP_DIM_VECTOR] = PTX_VECTOR_LENGTH;
   if (dims[GOMP_DIM_WORKER] < 0)
-	dims[GOMP_DIM_WORKER] = PTX_WORKER_LENGTH;
+	dims[GOMP_DIM_WORKER] = PTX_DEFAULT_RUNTIME_DIM;
   if (dims[GOMP_DIM_GANG] < 0)
-	dims[GOMP_DIM_GANG] = PTX_GANG_DEFAULT;
+	dims[GOMP_DIM_GANG] = PTX_DEFAULT_RUNTIME_DIM;
   changed = true;
 }
 
@@ -5230,9 +5230,6 @@ nvptx_dim_limit (int axis)
 {
   switch (axis)
 {
-case GOMP_DIM_WORKER:
-  return PTX_WORKER_LENGTH;
-
 case GOMP_DIM_VECTOR:
   return PTX_VECTOR_LENGTH;
 
diff --git a/libgomp/plugin/cuda/cuda.h b/libgomp/plugin/cuda/cuda.h
index 4799825..c7d50db 100644
--- a/libgomp/plugin/cuda/cuda.h
+++ b/libgomp/plugin/cuda/cuda.h
@@ -69,6 +69,8 @@ typedef enum {
   CU_DEVICE_ATTRIBUTE_CONCURRENT_KERNELS = 31,
   CU_DEVICE_ATTRIBUTE_MAX_THREADS_PER_MULTIPROCESSOR = 39,
   CU_DEVICE_ATTRIBUTE_ASYNC_ENGINE_COUNT = 40,
+  CU_DEVICE_ATTRIBUTE_COMPUTE_CAPABILITY_MAJOR = 75,
+  CU_DEVICE_ATTRIBUTE_COMPUTE_CAPABILITY_MINOR = 76,
   CU_DEVICE_ATTRIBUTE_MAX_REGISTERS_PER_MULTIPROCESSOR = 82
 } CUdevice_attribute;
 
diff --git a/libgomp/plugin/plugin-nvptx.c b/libgomp/plugin/plugin-nvptx.c
index 89326e5..ada1df2 100644
--- a/libgomp/plugin/plugin-nvptx.c
+++ b/libgomp/plugin/plugin-nvptx.c
@@ -409,11 +409,25 @@ struct ptx_device
   bool map;
   bool concur;
   bool mkern;
-  int  mode;
+  int mode;
+  int compute_capability_major;
+  int compute_capability_minor;
   int clock_khz;
   int num_sms;
   int regs_per_block;
   int regs_per_sm;
+  int max_threads_per_block;
+  int warp_size;
+  int max_threads_per_multiprocessor;
+  int max_shared_memory_per_multiprocessor;
+
+  int binary_version;
+
+  

[Bug libgcc/86213] -fsplit-stack runtime may clobber SSE input param reg

[ian at gcc dot gnu.org]

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

--- Comment #2 from ian at gcc dot gnu.org  ---
Author: ian
Date: Wed Jun 20 21:57:44 2018
New Revision: 261826

URL: https://gcc.gnu.org/viewcvs?rev=261826=gcc=rev
Log:
libgcc/:
PR libgcc/86213
* generic-morestack.c (allocate_segment): Move calls to getenv and
getpagesize to __morestack_load_mmap.
(__morestack_load_mmap) Initialize static_pagesize and
use_guard_page here so as to avoid clobbering SSE regs during a
__morestack call.
gcc/testsuite/:
* gcc.dg/split-8.c: New.

Added:
branches/gcc-8-branch/gcc/testsuite/gcc.dg/split-8.c
Modified:
branches/gcc-8-branch/gcc/testsuite/ChangeLog
branches/gcc-8-branch/libgcc/ChangeLog
branches/gcc-8-branch/libgcc/generic-morestack.c

Re: [PATCH] fix PR 86213, split stack runtime clobber of SSE reg

[Ian Lance Taylor]

On Wed, Jun 20, 2018 at 2:11 PM, Ian Lance Taylor  wrote:
> On Wed, Jun 20, 2018 at 12:02 PM, Than McIntosh  wrote:
>>
>> Please find below a patch to fix PR 86213. This changes the runtime
>> code for -fsplit-stack to move a couple of calls (getenv, etc) from
>> the routine called by __morestack to a function called on startup,
>> so as to avoid having the calls clobber SSE input regs.
>
> Thanks.  Approved and committed.

Also committed to GCC 8 branch.

Ian

[Bug c++/71765] incorrectly accepts invalid C++ code that invokes base class dtor

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Jonathan Wakely  ---
dup

*** This bug has been marked as a duplicate of bug 38087 ***

[Bug c++/38087] g++ accepts invalid destructor call

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||su at cs dot ucdavis.edu

--- Comment #8 from Jonathan Wakely  ---
*** Bug 71765 has been marked as a duplicate of this bug. ***

[Bug c++/57005] alias template's pseudo-destructor is rejected

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
   Last reconfirmed|2013-04-20 00:00:00 |2018-6-20

--- Comment #2 from Jonathan Wakely  ---
G++ still rejects this (as does EDG) but Clang accepts it.

Re: [PATCH, PR85859][tail-merge] Factor out gimple_may_have_side_effects_p and use in stmt_local_def

[Martin Sebor]

On 06/20/2018 03:14 PM, Tom de Vries wrote:

Hi,

Consider the test-case from the patch.  When compiled with "-O2 -fno-dce
-fno-isolate-erroneous-paths-dereference -fno-tree-dce -fno-tree-vrp" and
run, we get:
...
$ ./a.out
Floating point exception
...

The problem is introduced by -ftree-tail-merge (enabled by -O2), so it
executes fine when compiled with -fno-tree-tail-merge.

Tail-merge merges two blocks it considers equal:
...
find_duplicates:  duplicate of 
Removing basic block 4

  
  _6 = foo (0);
  iftmp.2_10 = (long int) _6;
  goto ; [100.00%]

  
  iftmp.2_11 = (long int) 
...
while the blocks in fact aren't equal from the point of view of side effects.
Executing bb3 causes the 'Floating point exception', while executing bb4
doesn't.

This patch fixes the problem by factoring out a new function
gimple_may_have_side_effects_p from bb_no_side_effects_p, and reusing that
function in the side-effect test in stmt_local_def in tail-merge.


Would gimple.h be a better place to declare the function, to
make it easier to use (i.e., without searching for the header
to include when using it for the first time)?

Martin

PS With one exception, AFAICS, the functions called by
gimple_may_have_side_effects_p are all defined in gimple.c, but
gimple_uses_undefined_value_p is declared in gimple-ssa.h and
defined in tree-ssa.c.  I don't know enough about how functions
are divvied up among these files but it seems to me that the
easiest scheme to understand and follow would be to declare all
extern gimple_xxx functions in gimple.h, no matter where they
are defined.



The patch inhibits tail-merge in pr81192.c, because
gimple_may_have_side_effects_p tests for gimple_uses_undefined_value_p, which
triggers for this particular test-case.

Bootstrapped and reg-tested on x86_64.

OK for trunk?

Thanks,
- Tom

[tail-merge] Factor out gimple_may_have_side_effects_p and use in stmt_local_def

2018-06-20  Tom de Vries  

PR tree-optimization/85859
* tree-ssa-ifcombine.c (gimple_may_have_side_effects_p): Factor out of
...
(bb_no_side_effects_p): ... here.
* tree-ssa-ifcombine.h: New file.
(gimple_may_have_side_effects_p): Declare.
* tree-ssa-tail-merge.c (stmt_local_def): Use
gimple_may_have_side_effects_p.

* gcc.dg/pr85859.c: New test.
* gcc.dg/pr81192.c: Update.

---
 gcc/testsuite/gcc.dg/pr81192.c |  2 +-
 gcc/testsuite/gcc.dg/pr85859.c | 19 +++
 gcc/tree-ssa-ifcombine.c   | 34 +++---
 gcc/tree-ssa-ifcombine.h   | 24 
 gcc/tree-ssa-tail-merge.c  |  5 ++---
 5 files changed, 69 insertions(+), 15 deletions(-)

diff --git a/gcc/testsuite/gcc.dg/pr81192.c b/gcc/testsuite/gcc.dg/pr81192.c
index 0049f371b3d..9db641ba91d 100644
--- a/gcc/testsuite/gcc.dg/pr81192.c
+++ b/gcc/testsuite/gcc.dg/pr81192.c
@@ -24,4 +24,4 @@ fn2 (void)
   ;
 }

-/* { dg-final { scan-tree-dump-times "(?n)find_duplicates:  duplicate of " 
1 "pre" } } */
+/* { dg-final { scan-tree-dump-not "(?n)find_duplicates:  duplicate of " 
"pre" } } */
diff --git a/gcc/testsuite/gcc.dg/pr85859.c b/gcc/testsuite/gcc.dg/pr85859.c
new file mode 100644
index 000..96eb9671137
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr85859.c
@@ -0,0 +1,19 @@
+/* { dg-do run } */
+/* { dg-options "-ftree-tail-merge -Wno-div-by-zero -O2 -fno-dce 
-fno-isolate-erroneous-paths-dereference -fno-tree-dce -fno-tree-vrp" } */
+
+int b, c, d, e;
+
+__attribute__ ((noinline, noclone))
+int foo (short f)
+{
+  f %= 0;
+  return f;
+}
+
+int
+main (void)
+{
+  b = (unsigned char) __builtin_parity (d);
+  e ? foo (0) : (long) 
+  return 0;
+}
diff --git a/gcc/tree-ssa-ifcombine.c b/gcc/tree-ssa-ifcombine.c
index b63c600c47b..8ea51a793f9 100644
--- a/gcc/tree-ssa-ifcombine.c
+++ b/gcc/tree-ssa-ifcombine.c
@@ -40,6 +40,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "gimplify-me.h"
 #include "tree-cfg.h"
 #include "tree-ssa.h"
+#include "tree-ssa-ifcombine.h"

 #ifndef LOGICAL_OP_NON_SHORT_CIRCUIT
 #define LOGICAL_OP_NON_SHORT_CIRCUIT \
@@ -108,6 +109,27 @@ recognize_if_then_else (basic_block cond_bb,
   return true;
 }

+/* Return true if gimple STMT may have side effect.  */
+
+bool
+gimple_may_have_side_effects_p (gimple *stmt)
+{
+  if (gimple_has_side_effects (stmt)
+  || gimple_uses_undefined_value_p (stmt)
+  || gimple_could_trap_p (stmt)
+  || gimple_vuse (stmt)
+  /* const calls don't match any of the above, yet they could
+still have some side-effects - they could contain
+gimple_could_trap_p statements, like floating point
+exceptions or integer division by zero.  See PR70586.
+FIXME: perhaps gimple_has_side_effects or gimple_could_trap_p
+should handle this.  */
+  || is_gimple_call (stmt))
+return true;
+
+  return false;
+}
+
 /* Verify if the basic block BB does not have side-effects.  Return
true in this case, else false.  */

@@ 

[Bug tree-optimization/85859] [6/7/8/9 Regression] wrong code with -fno-isolate-erroneous-paths-dereference

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #4 from Tom de Vries  ---
https://gcc.gnu.org/ml/gcc-patches/2018-06/msg01277.html

[PATCH, PR85859][tail-merge] Factor out gimple_may_have_side_effects_p and use in stmt_local_def

[Tom de Vries]

Hi,

Consider the test-case from the patch.  When compiled with "-O2 -fno-dce
-fno-isolate-erroneous-paths-dereference -fno-tree-dce -fno-tree-vrp" and
run, we get:
...
$ ./a.out 
Floating point exception
...

The problem is introduced by -ftree-tail-merge (enabled by -O2), so it
executes fine when compiled with -fno-tree-tail-merge.

Tail-merge merges two blocks it considers equal:
...
find_duplicates:  duplicate of 
Removing basic block 4

  
  _6 = foo (0);
  iftmp.2_10 = (long int) _6;
  goto ; [100.00%]

  
  iftmp.2_11 = (long int) 
...
while the blocks in fact aren't equal from the point of view of side effects.
Executing bb3 causes the 'Floating point exception', while executing bb4
doesn't.

This patch fixes the problem by factoring out a new function
gimple_may_have_side_effects_p from bb_no_side_effects_p, and reusing that
function in the side-effect test in stmt_local_def in tail-merge.

The patch inhibits tail-merge in pr81192.c, because
gimple_may_have_side_effects_p tests for gimple_uses_undefined_value_p, which
triggers for this particular test-case.

Bootstrapped and reg-tested on x86_64.

OK for trunk?

Thanks,
- Tom

[tail-merge] Factor out gimple_may_have_side_effects_p and use in stmt_local_def

2018-06-20  Tom de Vries  

PR tree-optimization/85859
* tree-ssa-ifcombine.c (gimple_may_have_side_effects_p): Factor out of
...
(bb_no_side_effects_p): ... here.
* tree-ssa-ifcombine.h: New file.
(gimple_may_have_side_effects_p): Declare.
* tree-ssa-tail-merge.c (stmt_local_def): Use
gimple_may_have_side_effects_p.

* gcc.dg/pr85859.c: New test.
* gcc.dg/pr81192.c: Update.

---
 gcc/testsuite/gcc.dg/pr81192.c |  2 +-
 gcc/testsuite/gcc.dg/pr85859.c | 19 +++
 gcc/tree-ssa-ifcombine.c   | 34 +++---
 gcc/tree-ssa-ifcombine.h   | 24 
 gcc/tree-ssa-tail-merge.c  |  5 ++---
 5 files changed, 69 insertions(+), 15 deletions(-)

diff --git a/gcc/testsuite/gcc.dg/pr81192.c b/gcc/testsuite/gcc.dg/pr81192.c
index 0049f371b3d..9db641ba91d 100644
--- a/gcc/testsuite/gcc.dg/pr81192.c
+++ b/gcc/testsuite/gcc.dg/pr81192.c
@@ -24,4 +24,4 @@ fn2 (void)
   ;
 }
 
-/* { dg-final { scan-tree-dump-times "(?n)find_duplicates:  duplicate 
of " 1 "pre" } } */
+/* { dg-final { scan-tree-dump-not "(?n)find_duplicates:  duplicate of 
" "pre" } } */
diff --git a/gcc/testsuite/gcc.dg/pr85859.c b/gcc/testsuite/gcc.dg/pr85859.c
new file mode 100644
index 000..96eb9671137
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr85859.c
@@ -0,0 +1,19 @@
+/* { dg-do run } */
+/* { dg-options "-ftree-tail-merge -Wno-div-by-zero -O2 -fno-dce 
-fno-isolate-erroneous-paths-dereference -fno-tree-dce -fno-tree-vrp" } */
+
+int b, c, d, e;
+
+__attribute__ ((noinline, noclone))
+int foo (short f)
+{
+  f %= 0;
+  return f;
+}
+
+int
+main (void)
+{
+  b = (unsigned char) __builtin_parity (d);
+  e ? foo (0) : (long) 
+  return 0;
+}
diff --git a/gcc/tree-ssa-ifcombine.c b/gcc/tree-ssa-ifcombine.c
index b63c600c47b..8ea51a793f9 100644
--- a/gcc/tree-ssa-ifcombine.c
+++ b/gcc/tree-ssa-ifcombine.c
@@ -40,6 +40,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "gimplify-me.h"
 #include "tree-cfg.h"
 #include "tree-ssa.h"
+#include "tree-ssa-ifcombine.h"
 
 #ifndef LOGICAL_OP_NON_SHORT_CIRCUIT
 #define LOGICAL_OP_NON_SHORT_CIRCUIT \
@@ -108,6 +109,27 @@ recognize_if_then_else (basic_block cond_bb,
   return true;
 }
 
+/* Return true if gimple STMT may have side effect.  */
+
+bool
+gimple_may_have_side_effects_p (gimple *stmt)
+{
+  if (gimple_has_side_effects (stmt)
+  || gimple_uses_undefined_value_p (stmt)
+  || gimple_could_trap_p (stmt)
+  || gimple_vuse (stmt)
+  /* const calls don't match any of the above, yet they could
+still have some side-effects - they could contain
+gimple_could_trap_p statements, like floating point
+exceptions or integer division by zero.  See PR70586.
+FIXME: perhaps gimple_has_side_effects or gimple_could_trap_p
+should handle this.  */
+  || is_gimple_call (stmt))
+return true;
+
+  return false;
+}
+
 /* Verify if the basic block BB does not have side-effects.  Return
true in this case, else false.  */
 
@@ -123,17 +145,7 @@ bb_no_side_effects_p (basic_block bb)
   if (is_gimple_debug (stmt))
continue;
 
-  if (gimple_has_side_effects (stmt)
- || gimple_uses_undefined_value_p (stmt)
- || gimple_could_trap_p (stmt)
- || gimple_vuse (stmt)
- /* const calls don't match any of the above, yet they could
-still have some side-effects - they could contain
-gimple_could_trap_p statements, like floating point
-exceptions or integer division by zero.  See PR70586.
-FIXME: perhaps gimple_has_side_effects or gimple_could_trap_p
-should handle this.  */
- || 

Re: How to get GCC on par with ICC?

[NightStrike]

On Wed, Jun 6, 2018 at 11:57 AM, Joel Sherrill  wrote:
>
> On Wed, Jun 6, 2018 at 10:51 AM, Paul Menzel <
> pmenzel+gcc.gnu@molgen.mpg.de> wrote:
>
> > Dear GCC folks,
> >
> >
> > Some scientists in our organization still want to use the Intel compiler,
> > as they say, it produces faster code, which is then executed on clusters.
> > Some resources on the Web [1][2] confirm this. (I am aware, that it’s
> > heavily dependent on the actual program.)
> >
>
> Do they have specific examples where icc is better for them? Or can point
> to specific GCC PRs which impact them?
>
>
> GCC versions?
>
> Are there specific CPU model variants of concern?
>
> What flags are used to compile? Some times a bit of advice can produce
> improvements.
>
> Without specific examples, it is hard to set goals.

If I could perhaps jump in here for a moment...  Just today I hit upon
a series of small (in lines of code) loops that gcc can't vectorize,
and intel vectorizes like a madman.  They all involve a lot of heavy
use of std::vector>.  Comparisons were with gcc
8.1, intel 2018.u1, an AMD Opteron 6386 SE, with the program running
as sched_FIFO, mlockall, affinity set to its own core, and all
interrupts vectored off that core.  So, as close to not-noisy as
possible.

I was surprised at the results results, but using each compiler's methods of
dumping vectorization info, intel wins on two points:

1) It actually vectorizes
2) It's vectorizing output is much more easily readable

Options were:

gcc -Wall -ggdb3 -std=gnu++17 -flto -Ofast -march=native

vs:

icc -Ofast -std=gnu++14


So, not exactly exact, but pretty close.


So here's an example of a chunk of code (not very readable, sorry
about that) that intel can vectorize, and subsequently make about 50%
faster:

std::size_t nLayers { input.nn.size() };
//std::size_t ySize = std::max_element(input.nn.cbegin(),
input.nn.cend(), [](auto a, auto b){ return a.size() < b.size();
})->size();
std::size_t ySize = 0;
for (auto const & nn: input.nn)
ySize = std::max(ySize, nn.size());

float yNorm[ySize];
for (auto & y: yNorm)
y = 0.0f;
for (std::size_t i = 0; i < xSize; ++i)
yNorm[i] = xNorm[i];
for (std::size_t layer = 0; layer < nLayers; ++layer) {
auto & nn = input.nn[layer];
auto & b = nn.back();
float y[ySize];
for (std::size_t i = 0; i < nn[0].size(); ++i) {
y[i] = b[i];
for (std::size_t j = 0; j < nn.size() - 1; ++j)
y[i] += nn.at(j).at(i) * yNorm[j];
}
for (std::size_t i = 0; i < ySize; ++i) {
if (layer < nLayers - 1)
y[i] = std::max(y[i], 0.0f);
yNorm[i] = y[i];
}
}


If I was better at godbolt, I could show the asm, but I'm not.  I'm
willing to learn, though.

[Bug libgcc/86213] -fsplit-stack runtime may clobber SSE input param reg

[ian at gcc dot gnu.org]

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

--- Comment #1 from ian at gcc dot gnu.org  ---
Author: ian
Date: Wed Jun 20 21:11:23 2018
New Revision: 261823

URL: https://gcc.gnu.org/viewcvs?rev=261823=gcc=rev
Log:
libgcc/:
PR libgcc/86213
* generic-morestack.c (allocate_segment): Move calls to getenv and
getpagesize to __morestack_load_mmap.
(__morestack_load_mmap) Initialize static_pagesize and
use_guard_page here so as to avoid clobbering SSE regs during a
__morestack call.
gcc/testsuite/:
* gcc.dg/split-8.c: New.

Added:
trunk/gcc/testsuite/gcc.dg/split-8.c
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/libgcc/ChangeLog
trunk/libgcc/generic-morestack.c

Re: [PATCH] fix PR 86213, split stack runtime clobber of SSE reg

[Ian Lance Taylor]

On Wed, Jun 20, 2018 at 12:02 PM, Than McIntosh  wrote:
>
> Please find below a patch to fix PR 86213. This changes the runtime
> code for -fsplit-stack to move a couple of calls (getenv, etc) from
> the routine called by __morestack to a function called on startup,
> so as to avoid having the calls clobber SSE input regs.

Thanks.  Approved and committed.

Ian

[Bug fortran/86248] LEN_TRIM in specification expression causes link failure

[longb at cray dot com]

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

--- Comment #1 from Bill Long  ---
Possibly related to 44265.

[Bug fortran/86248] New: LEN_TRIM in specification expression causes link failure

[longb at cray dot com]

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

Bug ID: 86248
   Summary: LEN_TRIM in specification expression causes link
failure
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: longb at cray dot com
  Target Milestone: ---

> cat modu6.f90
module test_module

implicit none
public :: func_1
integer :: string_length = 3
character(len=*),parameter :: fixed_string = "el_"
character(len=3),dimension(0:2),parameter :: darray_fixed =
(/"el0","el1","el2"/)
character(len=*),dimension(0:2),parameter :: darray = (/"el0","el1","el2"/)

contains
function func_1(func_1_input)
!Declaration section
integer, intent(in) :: func_1_input
!Test6
character(len=len_trim(darray_fixed(func_1_input))) :: func_1
func_1=darray(func_1_input)
end function func_1

end module test_module

> cat test.f90
program test
use test_module
implicit none
write(*,*) "Accessing Element index : ",0,"inside value : ",func_1(0)
write(*,*) "Accessing Element index : ",1,"inside value : ",func_1(1)
write(*,*) "Accessing Element index : ",2,"inside value : ",func_1(2)
end program test

> diff modu6.f90 modu8.f90
15c15
< character(len=len_trim(darray_fixed(func_1_input))) :: func_1
---
> character(len=len(darray_fixed(func_1_input))) :: func_1
> 


Using LEN in specification works as expected:

> gfortran -c modu8.f90
> gfortran test.f90 modu8.o
> ./a.out
 Accessing Element index :0 inside value : el0
 Accessing Element index :1 inside value : el1
 Accessing Element index :2 inside value : el2


Using LEN_TRIM instead of LEN fails:

> gfortran -c modu6.f90
> gfortran test.f90 modu6.o
/lus/scratch/tmp/ccljHL3g.o: In function `MAIN__':
test.f90:(.text+0xaf): undefined reference to `__test_PROC_darray_fixed'
test.f90:(.text+0x212): undefined reference to `__test_PROC_darray_fixed'
test.f90:(.text+0x375): undefined reference to `__test_PROC_darray_fixed'
collect2: error: ld returned 1 exit status

[Bug c++/86246] [8/9 Regression] Template dispatching error inside a template function

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||7.3.0
Version|8.0.1   |8.1.0
   Keywords||rejects-valid
   Last reconfirmed||2018-06-20
 CC||nathan at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|Template dispatching error  |[8/9 Regression] Template
   |inside a template function  |dispatching error inside a
   ||template function
  Known to fail||8.1.0, 9.0

--- Comment #1 from Jonathan Wakely  ---
(In reply to Tianqi Chen from comment #0)
> There is also evidence that it
> still exists in gcc-8.1

We're really not interested in bugs reported against pre-release 8.0.1 builds
now that there's an actual 8.1 release. It's very easy to check the 8.1 release
using an online compiler such as https://wandbox.org


It does fail with 8.1 though.

Reduced:


namespace std {
  template struct is_class {
static constexpr bool value = true;
  };
  template<> struct is_class {
static constexpr bool value = false;
  };
}

class MyClass {
 public:
  operator double() const {
return 1;
  }
  template
  operator T() const {
static_assert(std::is_class::value, "problem");
return T();
  }
};

template
void SetValue(const MyClass& obj, T* value) {
  //  always dispatches to operator T even if T is double
  *value = obj.operator T();
}

int main() {
  MyClass obj;
  // works fine 
  obj.operator double();
  double x;
  // error, when operator T is called in SetValue   
  SetValue(obj, );
}


This compiled OK until r255605 when it started to ICE:

86246.cc: In instantiation of ‘void SetValue(const MyClass&, T*) [with T =
double]’:
86246.cc:34:19:   required from here
86246.cc:25:25: internal compiler error: in tsubst_baselink, at cp/pt.c:14471
   *value = obj.operator T();
~^
0xa0090e tsubst_baselink
../../gcc/cp/pt.c:14471
0xa14c27 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/cp/pt.c:17980
0xa1270a tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/cp/pt.c:17592
0xa11b30 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/cp/pt.c:17433
0xa0e93c tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:16767
0xa08d23 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:16008
0xa0aadb tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:16251
0xa2be19 instantiate_decl(tree_node*, bool, bool)
../../gcc/cp/pt.c:23302
0xa2c7ca instantiate_pending_templates(int)
../../gcc/cp/pt.c:23416
0x8cfdc2 c_parse_final_cleanups()
../../gcc/cp/decl2.c:4666
0xb3f0b8 c_common_parse_file()
../../gcc/c-family/c-opts.c:1149
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Then at r256986 the ICE was fixed but it started calling the wrong function:

86246.cc: In instantiation of ‘MyClass::operator T() const [with T = double]’:
86246.cc:25:10:   required from ‘void SetValue(const MyClass&, T*) [with T =
double]’
86246.cc:34:19:   required from here
86246.cc:17:19: error: static assertion failed: problem
 static_assert(std::is_class::value, "problem");
   ^~~

[Bug c++/86184] Conditional expression with omitted operand cannot use rvalue of type convertible to bool

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #4 from Marek Polacek  ---
It looks like we should avoid wrapping a TARGET_EXPR in SAVE_EXPR:
 4806   /* Make sure that lvalues remain lvalues.  See g++.oliva/ext1.C. 
*/
 4807   if (lvalue_p (arg1))
 4808 arg2 = arg1 = cp_stabilize_reference (arg1);
 4809   else
 4810 arg2 = arg1 = cp_save_expr (arg1);
because that makes the clk_class expression a clk_none.

[Bug c/86093] [8/9 Regression] volatile ignored on pointer in C

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Wed Jun 20 20:40:33 2018
New Revision: 261820

URL: https://gcc.gnu.org/viewcvs?rev=261820=gcc=rev
Log:
Backported from mainline
2018-06-15  Jakub Jelinek  

PR c/86093
* c-typeck.c (pointer_diff): Cast both pointers to unqualified types
before doing POINTER_DIFF_EXPR.

* c-c++-common/pr86093.c: New test.

Added:
branches/gcc-8-branch/gcc/testsuite/c-c++-common/pr86093.c
Modified:
branches/gcc-8-branch/gcc/c/ChangeLog
branches/gcc-8-branch/gcc/c/c-typeck.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog

[Bug rtl-optimization/86108] [8 Regression] crash during unwinding with -O2

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
Author: jakub
Date: Wed Jun 20 20:41:12 2018
New Revision: 261821

URL: https://gcc.gnu.org/viewcvs?rev=261821=gcc=rev
Log:
Backported from mainline
2018-06-16  Jakub Jelinek  

PR rtl-optimization/86108
* bb-reorder.c (create_forwarder_block): Renamed to ...
(create_eh_forwarder_block): ... this.  Split OLD_BB after labels and
jump from new landing pad to the second part.
(sjlj_fix_up_crossing_landing_pad, dw2_fix_up_crossing_landing_pad):
Adjust callers.

Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/bb-reorder.c

[Bug tree-optimization/86247] New: warning on alloca within a loop overly restrictive for constant loops

[msebor at gcc dot gnu.org]

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

Bug ID: 86247
   Summary: warning on alloca within a loop overly restrictive for
constant loops
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The usability of the-Walloca-larger-than= warnings could be improved by taking
into consideration the product of the upper bound on the number of iterations
of the loop and the alloca argument.  For example, the loop in the following
test case effectively results in allocating just 32 * 17 or 544 bytes, well
below the  4K limit set by the -Walloca-larger-than=4096 option.  The warning
could be avoided in this case.

$ cat c.c && gcc -S -O2 -Wall -Wextra -Walloca-larger-than=4096 c.c
void f (void*, ...);

void g (void)
{
  for (int i = 0; i != 17; ++i)
f (__builtin_alloca (32));
}
c.c: In function ‘g’:
c.c:6:5: warning: use of ‘alloca’ within a loop [-Walloca-larger-than=]
 f (__builtin_alloca (32));
 ^

[Bug c++/86246] New: Template dispatching error inside a template function

[tqchen at cs dot washington.edu]

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

Bug ID: 86246
   Summary: Template dispatching error inside a template function
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tqchen at cs dot washington.edu
  Target Milestone: ---

See bellow minimum reproducible example. There is also evidence that it still
exists in gcc-8.1, gcc-7 or prior versions do not have this problem

#include 

class MyClass {
 public:
  operator double() const {
return 1;
  }
  template
  operator T() const {
static_assert(std::is_class::value, "problem");
return T();
  }
};

template
void SetValue(const MyClass& obj, T* value) {
  //  always dispatches to operator T even if T is double
  *value = obj.operator T();
}

int main() {
  MyClass obj;
  // works fine 
  obj.operator double();
  double x;
  // error, when operator T is called in SetValue   
  SetValue(obj, );
}

2019 MIPIM Yacht Charters

[Nancy Gordon]

Experience Cannes in style on a Corporate Yacht Charter 
(https://u7419970.ct.sendgrid.net/wf/click?upn=FBDq8VEpDC2W9whzzZ5c9UJyWBG4s3G5UcA5SNxaxBVGA9wckcjt9k-2FbhUn2dI9YOr52YVi7UwEsDGMNmBD9Mw-3D-3D_iaYFtpR3d-2FR9fRvTiX3jMD42Aa63RX3G1cmVpk5p2CXwpUNZbHyoN4Gmkj0CQsf-2Brt7-2BnLgLPfxz3M0o1is-2FfpV3R010QzOFYFyYXlW4NARfDXAKbeBcnHrGh-2BTUbykLd8c4bJoZljFTVPc6mWrpTjvQLtx-2Bnq-2BstF4359crVLZHrlWo5Nt9WQ38terqhSmITkwM6UuDjIrvdKLKKZKtsw-3D-3D
 
 
 
 


CANNES, FRANCE 
(https://u7419970.ct.sendgrid.net/wf/click?upn=FBDq8VEpDC2W9whzzZ5c9UJyWBG4s3G5UcA5SNxaxBVGA9wckcjt9k-2FbhUn2dI9YwsrvwhSJMuMi6qd4z8Hr2Q-3D-3D_iaYFtpR3d-2FR9fRvTiX3jMD42Aa63RX3G1cmVpk5p2CXwpUNZbHyoN4Gmkj0CQsf-2B7rwZ-2FckH2bE1lOGTjORQgog-2FXcStwZNQjp3jXgjgWu5-2Bb0YkEa4jryfQ1fgBw-2BwkXGrBsCzG0WG-2BRX-2FQWJ1XvIahZhluqBVTxAOjMbjFYNZiJa8WtsG7TtPkVdmr3sJ92Tfj1N1DcuLlOQuPjixO0Q-3D-3D
12 to 15 March 2019 
(https://u7419970.ct.sendgrid.net/wf/click?upn=FBDq8VEpDC2W9whzzZ5c9UJyWBG4s3G5UcA5SNxaxBVGA9wckcjt9k-2FbhUn2dI9YwsrvwhSJMuMi6qd4z8Hr2Q-3D-3D_iaYFtpR3d-2FR9fRvTiX3jMD42Aa63RX3G1cmVpk5p2CXwpUNZbHyoN4Gmkj0CQsf-2BL4I-2B5gEtY4BUGIfClqeBXF6UpwFSc9EATfF208QT4f8RHKoeU3cusLXJzxo40Lwz7k6w-2BXUsgwhTHmRDMrTqWSyi0GJ2VhWfY6SeIk25XEcl6CnaRcDmJT9lA9xW-2FQzcX-2FKkYoqqn-2FyGkW-2Bc-2BWroJQ-3D-3D

MIPIM 2019 
(https://u7419970.ct.sendgrid.net/wf/click?upn=FBDq8VEpDC2W9whzzZ5c9UJyWBG4s3G5UcA5SNxaxBVGA9wckcjt9k-2FbhUn2dI9YwsrvwhSJMuMi6qd4z8Hr2Q-3D-3D_iaYFtpR3d-2FR9fRvTiX3jMD42Aa63RX3G1cmVpk5p2CXwpUNZbHyoN4Gmkj0CQsf-2BJilYz1iBlGxtKiJSzxThw0OjHqXLa7ySNAYrLsxt5RNHAx3il4CCA2-2BNtRTcFrhqxiI6S6G-2Flf4-2BMHZz-2BMOf-2Fon057qONNiESE8EgEIG-2Fk8kVpC8-2BlzdOMDS20AIZHelwG2ylHZI1mQNnqgqO-2Bxvog-3D-3D

The World’s Leading Commercial Property Market 
(https://u7419970.ct.sendgrid.net/wf/click?upn=FBDq8VEpDC2W9whzzZ5c9UJyWBG4s3G5UcA5SNxaxBVGA9wckcjt9k-2FbhUn2dI9YwsrvwhSJMuMi6qd4z8Hr2Q-3D-3D_iaYFtpR3d-2FR9fRvTiX3jMD42Aa63RX3G1cmVpk5p2CXwpUNZbHyoN4Gmkj0CQsf-2BMFjaA7L8SBNJf0Yh5jyOoHFJdoTGoWJ53jidFuWoGTvv6-2BtZiJ-2BgPyoViW7A8989lp1jjyoZ-2F4F4-2B0c-2BQKFqN1Esv6YpqlRqCb6-2BUILz6EK1Zu2CLYMjHMzd8tsd5LtO-2FsEkiD10bKvgc0IYkx1fRQ-3D-3D


 
 
 
 
CANNES YACHT CHARTERS 
(https://u7419970.ct.sendgrid.net/wf/click?upn=FBDq8VEpDC2W9whzzZ5c9UJyWBG4s3G5UcA5SNxaxBVGA9wckcjt9k-2FbhUn2dI9YwsrvwhSJMuMi6qd4z8Hr2Q-3D-3D_iaYFtpR3d-2FR9fRvTiX3jMD42Aa63RX3G1cmVpk5p2CXwpUNZbHyoN4Gmkj0CQsf-2BJz1qNlnBKtjuv-2Bl7ufMX-2Fqu6-2F3QgkYbPGvxqcJwXjDP5-2FCBkbacjvJQL3GxM3P-2B-2FZ-2BdaW0KH-2BQN9Zbt8xH3e5wDRsaXQdX5qL2LMq6lIoLu8DiNsYlxrOFTHakvQ425XeDoOJILVny8Csk3se-2BAuuA-3D-3D
Since 1998, we have offering the finest luxury yacht charters 
(mailto:j...@ultimate-charters.com?subject=Yacht%20Charters) on the French Riviera, 
from Cannes to Monaco & St. Tropez.  We specialize in corporate yacht charters 
(mailto:j...@ultimate-charters.com?subject=Yacht%20Charters) for events like MIPIM, 
MAPIC, Cannes Lions, MIDEM, MIPTV, the Cannes Film Festival & the Monaco Grand 
Prix.  Contact us 
(https://u7419970.ct.sendgrid.net/wf/click?upn=FBDq8VEpDC2W9whzzZ5c9UJyWBG4s3G5UcA5SNxaxBVGA9wckcjt9k-2FbhUn2dI9YwsrvwhSJMuMi6qd4z8Hr2Q-3D-3D_iaYFtpR3d-2FR9fRvTiX3jMD42Aa63RX3G1cmVpk5p2CXwpUNZbHyoN4Gmkj0CQsf-2BBnFv-2BmhGjCObgH1M3dHlu6grt4VWzaYrYZMf2nBWPwHOnOMQSiF3mPSH9SeOU4s4hq4g8whgA-2Fns968oVLQJHN2eICnY5VFnmwXvFgXme4DRpAY9mcPGsL1i1XU86dq7odP8Y5WVb0f2f3rxpVOLuQ-3D-3D
 to explore the endless possibilities.
 
 
 
 
AVAILABLE YACHTS IN CANNES 
(https://u7419970.ct.sendgrid.net/wf/click?upn=FBDq8VEpDC2W9whzzZ5c9UJyWBG4s3G5UcA5SNxaxBXaB-2FYYKlCKtMMYe-2FhaMSU8PMGERa5ZhfyZIoSX27ltFvD4ezOCjTbU-2BOxC0aACuna7FfQ0zO02y9rB8oliiHYAQjCfwLCrnyh21d5a32xKeg-3D-3D_iaYFtpR3d-2FR9fRvTiX3jMD42Aa63RX3G1cmVpk5p2CXwpUNZbHyoN4Gmkj0CQsf-2BSJXu0YOwQkspLvAc-2B2fobmpbY3Bql8jO0FmeU-2F0FoFAB-2FkHz9k2fzSoBvq-2BLYZFWedfT7r91KSYuLeHbY9c5usb-2B8KnhHXkj-2FCIGbNYNGuN4bpLNA6cO09EaB5FT2gz-2Fy4-2Bu8gydRibM1cqJI-2BuW4A-3D-3D
 
 
 
 
M/Y Princess, 75ft/23m 
(https://u7419970.ct.sendgrid.net/wf/click?upn=FBDq8VEpDC2W9whzzZ5c9UJyWBG4s3G5UcA5SNxaxBXaB-2FYYKlCKtMMYe-2FhaMSU8PMGERa5ZhfyZIoSX27ltFvD4ezOCjTbU-2BOxC0aACuna7FfQ0zO02y9rB8oliiHYABhDCGXr-2B6cMBO3yfL5REXQ-3D-3D_iaYFtpR3d-2FR9fRvTiX3jMD42Aa63RX3G1cmVpk5p2CXwpUNZbHyoN4Gmkj0CQsf-2BR7SW-2BCVWb6eFho-2FnWXMsh6veg2Bfr0TzklV3oKW0SCWzOfl3FR6p2LopvpRPFHMiWjla30NlK1fWm0jixrWPB5IR95vlIS0FWNokFRYI65SnIsJ2Gpm3LAI8hj7O1cMJo0Uo8H01WshKjLw4BWZQqQ-3D-3D
Beautiful flybridge motor yacht with 4 Cabins, 3 Meeting Areas, Entertains up 
to 12.  Daily Rate: 8,335€ (+ charges).
 
 
 
More Details (mailto:j...@ultimate-charters.com?subject=Yacht%20Charters)
 
 

(https://u7419970.ct.sendgrid.net/wf/click?upn=FBDq8VEpDC2W9whzzZ5c9UJyWBG4s3G5UcA5SNxaxBVGA9wckcjt9k-2FbhUn2dI9YwsrvwhSJMuMi6qd4z8Hr2Q-3D-3D_iaYFtpR3d-2FR9fRvTiX3jMD42Aa63RX3G1cmVpk5p2CXwpUNZbHyoN4Gmkj0CQsf-2BU2djVFjykkn-2FgvjutfuXviRc9X-2FC2wZpAHdLtk3XJIibLQo0RSOocxZ1aK6ZjZXdpEALVei6cTIIAP6hSWstvsTdWtgE1mCSeeHNTyyPa8fdtKtknLEA7zmswO-2B-2B5G2xvUl6mNc4EZcv37Ngedb6lw-3D-3D

[Bug libstdc++/70966] new_delete_resource() has deinit lifetime issues.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |9.0

--- Comment #2 from Jonathan Wakely  ---
Fixed on trunk.

[Bug libstdc++/70966] new_delete_resource() has deinit lifetime issues.

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
Author: redi
Date: Wed Jun 20 19:34:53 2018
New Revision: 261818

URL: https://gcc.gnu.org/viewcvs?rev=261818=gcc=rev
Log:
PR libstdc++/70966 make pmr::new_delete_resource() immortal

Construct the program-wide resource objects using placement new. This
means they have dynamic storage duration and won't be destroyed during
termination.

PR libstdc++/70966
* include/experimental/memory_resource (__resource_adaptor_imp): Add
static assertions to enforce requirements on pointer types.
(__resource_adaptor_imp::get_allocator()): Add noexcept.
(new_delete_resource, null_memory_resource): Return address of an
object with dynamic storage duration.
(__null_memory_resource): Remove.
* testsuite/experimental/memory_resource/70966.cc: New.

Added:
trunk/libstdc++-v3/testsuite/experimental/memory_resource/70966.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/experimental/memory_resource

[PATCH] PR libstdc++/70966 make pmr::new_delete_resource() immortal

[Jonathan Wakely]

Construct the program-wide resource objects using placement new. This
means they have dynamic storage duration and won't be destroyed during
termination.

PR libstdc++/70966
* include/experimental/memory_resource (__resource_adaptor_imp): Add
static assertions to enforce requirements on pointer types.
(__resource_adaptor_imp::get_allocator()): Add noexcept.
(new_delete_resource, null_memory_resource): Return address of an
object with dynamic storage duration.
(__null_memory_resource): Remove.
* testsuite/experimental/memory_resource/70966.cc: New.

Tested x86_64-linux, committed to trunk. I plan to backport this to
the branches too, as it's experimental TS material.


commit 2a3eba3f0312c8c15f4f2fd7fe7dcc4896036797
Author: Jonathan Wakely 
Date:   Wed Jun 20 20:01:04 2018 +0100

PR libstdc++/70966 make pmr::new_delete_resource() immortal

Construct the program-wide resource objects using placement new. This
means they have dynamic storage duration and won't be destroyed during
termination.

PR libstdc++/70966
* include/experimental/memory_resource (__resource_adaptor_imp): Add
static assertions to enforce requirements on pointer types.
(__resource_adaptor_imp::get_allocator()): Add noexcept.
(new_delete_resource, null_memory_resource): Return address of an
object with dynamic storage duration.
(__null_memory_resource): Remove.
* testsuite/experimental/memory_resource/70966.cc: New.

diff --git a/libstdc++-v3/include/experimental/memory_resource 
b/libstdc++-v3/include/experimental/memory_resource
index b8480c2a17b..670a2210804 100644
--- a/libstdc++-v3/include/experimental/memory_resource
+++ b/libstdc++-v3/include/experimental/memory_resource
@@ -33,7 +33,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 namespace std {
@@ -258,6 +257,22 @@ namespace pmr {
   template 
 class __resource_adaptor_imp : public memory_resource
 {
+  static_assert(is_same::value_type>::value,
+ "Allocator's value_type is char");
+  static_assert(is_same::pointer>::value,
+ "Allocator's pointer type is value_type*");
+  static_assert(is_same::const_pointer>::value,
+ "Allocator's const_pointer type is value_type const*");
+  static_assert(is_same::void_pointer>::value,
+ "Allocator's void_pointer type is void*");
+  static_assert(is_same::const_void_pointer>::value,
+ "Allocator's const_void_pointer type is void const*");
+
 public:
   using allocator_type = _Alloc;
 
@@ -276,7 +291,7 @@ namespace pmr {
   __resource_adaptor_imp&
   operator=(const __resource_adaptor_imp&) = default;
 
-  allocator_type get_allocator() const { return _M_alloc; }
+  allocator_type get_allocator() const noexcept { return _M_alloc; }
 
 protected:
   virtual void*
@@ -311,13 +326,13 @@ namespace pmr {
 private:
   // Calculate Aligned Size
   // Returns a size that is larger than or equal to __size and divisible
-  // by __alignment, where __alignment is required to be the power of 2.
+  // by __alignment, where __alignment is required to be a power of 2.
   static size_t
   _S_aligned_size(size_t __size, size_t __alignment)
   { return ((__size - 1)|(__alignment - 1)) + 1; }
 
   // Determine whether alignment meets one of those preconditions:
-  // 1. Equals to Zero
+  // 1. Equal to Zero
   // 2. Is power of two
   static bool
   _S_supported (size_t __x)
@@ -337,34 +352,33 @@ namespace pmr {
   inline memory_resource*
   new_delete_resource() noexcept
   {
-static resource_adaptor> __r;
-return static_cast(&__r);
+using type = resource_adaptor>;
+alignas(type) static unsigned char __buf[sizeof(type)];
+static type* __r = new(__buf) type;
+return __r;
   }
 
-  template 
-class __null_memory_resource : private memory_resource
-{
-protected:
-  void*
-  do_allocate(size_t, size_t)
-  { std::__throw_bad_alloc(); }
-
-  void
-  do_deallocate(void*, size_t, size_t) noexcept
-  { }
-
-  bool
-  do_is_equal(const memory_resource& __other) const noexcept
-  { return this == &__other; }
-
-  friend memory_resource* null_memory_resource() noexcept;
-};
-
   inline memory_resource*
   null_memory_resource() noexcept
   {
-static __null_memory_resource __r;
-return static_cast(&__r);
+class type final : public memory_resource
+{
+  void*
+  do_allocate(size_t, size_t) override
+  { std::__throw_bad_alloc(); }
+
+  void
+  do_deallocate(void*, size_t, size_t) noexcept override
+  { }
+
+  bool
+  do_is_equal(const memory_resource& __other) const noexcept override
+  { return this == &__other; }
+};
+
+alignas(type) static unsigned char __buf[sizeof(type)];
+static 

[Bug c++/85634] [8/9 Regression] ICE in tsubst_copy, at cp/pt.c:15483

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #12 from Nathan Sidwell  ---
Regression caused by first patch fixed in r261817.

No regression on gcc-8 branch.

[Bug c++/85634] [8/9 Regression] ICE in tsubst_copy, at cp/pt.c:15483

[nathan at gcc dot gnu.org]

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

--- Comment #13 from Nathan Sidwell  ---
Author: nathan
Date: Wed Jun 20 19:22:53 2018
New Revision: 261817

URL: https://gcc.gnu.org/viewcvs?rev=261817=gcc=rev
Log:
[PR c++/85634] Fix tsubst ICE

https://gcc.gnu.org/ml/gcc-patches/2018-06/msg01274.html
PR c++/85634
* friend.c (add_friend): Keep lookup sets of tempate sets.

PR c++/85634
* g++.dg/lookup/pr85634-2.C: New.

Added:
trunk/gcc/testsuite/g++.dg/lookup/pr85634-2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/friend.c
trunk/gcc/testsuite/ChangeLog

Re: [PR c++/85634] Fix tsubst ICE

[Nathan Sidwell]

On 06/20/2018 10:33 AM, Nathan Sidwell wrote:
This patch fixes 85634, an ice during tsubst where we encounter an 
unmarked lookup.  Such lookups could be mutated by declarations added 
after the template definition containing them.   That would be bad.


This patch is needed on trunk, to handle friends of templates.  I 
happened to leave the equivalent marking of a template-id-expr in the 
gcc-8 branch, so it's not needed there (but does mark more than necessary).


nathan
--
Nathan Sidwell
2018-06-20  Nathan Sidwell  

	PR c++/85634
	* friend.c (add_friend): Keep lookup sets of tempate sets.

	PR c++/85634
	* g++.dg/lookup/pr85634-2.C: New.

Index: gcc/cp/friend.c
===
--- gcc/cp/friend.c	(revision 261814)
+++ gcc/cp/friend.c	(working copy)
@@ -173,6 +173,12 @@ add_friend (tree type, tree decl, bool c
   if (decl == error_mark_node)
 return;
 
+  if (TREE_CODE (decl) == FUNCTION_DECL
+  && DECL_TEMPLATE_INSTANTIATION (decl))
+/* We'll have parsed this as a declaration, and therefore not
+   marked the lookup set for keeping.  Do that now.  */
+lookup_keep (DECL_TI_TEMPLATE (decl));
+
   typedecl = TYPE_MAIN_DECL (type);
   list = DECL_FRIENDLIST (typedecl);
   name = DECL_NAME (decl);
Index: gcc/testsuite/g++.dg/lookup/pr85634-2.C
===
--- gcc/testsuite/g++.dg/lookup/pr85634-2.C	(revision 0)
+++ gcc/testsuite/g++.dg/lookup/pr85634-2.C	(working copy)
@@ -0,0 +1,16 @@
+// PR c++/85634
+
+namespace bsl {
+  template  void frob (const T *);
+}
+
+using namespace bsl;
+
+template void frob (const VALUE &);
+
+template 
+struct TPL {
+  friend void frob  (const T &);
+};
+
+TPL x;

[PATCH] fix PR 86213, split stack runtime clobber of SSE reg

[Than McIntosh via gcc-patches]

Hi all,

Please find below a patch to fix PR 86213. This changes the runtime
code for -fsplit-stack to move a couple of calls (getenv, etc) from
the routine called by __morestack to a function called on startup,
so as to avoid having the calls clobber SSE input regs.

Thanks, Than

---

libgcc/ChangeLog:

   * libgcc/generic-morestack.c (allocate_segment): move
   calls to getenv and getpagesize to __morestack_load_mmap
   (__morestack_load_mmap) initialize static_pagesize and
   use_guard_page here so as to avoid clobbering SSE
   regs during a __morestack call.

gcc/testsuite/ChangeLog:

PR libgcc/86213
* gcc.dg/split-8.c: New test.

diff --git a/gcc/testsuite/gcc.dg/split-8.c b/gcc/testsuite/gcc.dg/split-8.c
new file mode 100644
index 000..33662e24c4f
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/split-8.c
@@ -0,0 +1,43 @@
+/* { dg-do run } */
+/* { dg-require-effective-target split_stack } */
+/* { dg-options "-fsplit-stack" } */
+
+/* Testcase for PR86213. On the first call to __morestack there is a live
+   value in xmm0, which was being clobbered by a call to getenv().  */
+
+#include 
+
+double gd[8];
+int z;
+
+double bar(double q)  __attribute__ ((noinline));
+double foo(double q)  __attribute__ ((noinline));
+int ck(double q)  __attribute__ ((noinline));
+int main(int argc, char **argv) __attribute__ ((no_split_stack));
+
+double bar(double q)
+{
+  double d[8];
+  for (unsigned i = 0; i < 8; ++i)
+d[i] = gd[8-i-1];
+  return q + d[z&3];
+}
+
+double foo(double d)
+{
+  return bar(d);
+}
+
+int ck(double d)
+{
+  if (d != 64.0)
+abort();
+  return 0;
+}
+
+typedef double (*fp)(double);
+fp g = foo;
+
+int main(int argc, char **argv) {
+  return ck(g(64.0));
+}
diff --git a/libgcc/generic-morestack.c b/libgcc/generic-morestack.c
index 80bfd7feda7..d70ca0922ce 100644
--- a/libgcc/generic-morestack.c
+++ b/libgcc/generic-morestack.c
@@ -243,6 +243,12 @@ __thread struct initial_sp __morestack_initial_sp

 static sigset_t __morestack_fullmask;

+/* Page size, as returned from getpagesize(). Set on startup. */
+static unsigned int static_pagesize;
+
+/* Set on startup to non-zero value if SPLIT_STACK_GUARD env var is set. */
+static int use_guard_page;
+
 /* Convert an integer to a decimal string without using much stack
space.  Return a pointer to the part of the buffer to use.  We this
instead of sprintf because sprintf will require too much stack
@@ -320,8 +326,6 @@ __morestack_fail (const char *msg, size_t len, int err)
 static struct stack_segment *
 allocate_segment (size_t frame_size)
 {
-  static unsigned int static_pagesize;
-  static int use_guard_page;
   unsigned int pagesize;
   unsigned int overhead;
   unsigned int allocate;
@@ -329,27 +333,6 @@ allocate_segment (size_t frame_size)
   struct stack_segment *pss;

   pagesize = static_pagesize;
-  if (pagesize == 0)
-{
-  unsigned int p;
-
-  pagesize = getpagesize ();
-
-#ifdef __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4
-  p = __sync_val_compare_and_swap (_pagesize, 0, pagesize);
-#else
-  /* Just hope this assignment is atomic.  */
-  static_pagesize = pagesize;
-  p = 0;
-#endif
-
-  use_guard_page = getenv ("SPLIT_STACK_GUARD") != 0;
-
-  /* FIXME: I'm not sure this assert should be in the released
- code.  */
-  assert (p == 0 || p == pagesize);
-}
-
   overhead = sizeof (struct stack_segment);

   allocate = pagesize;
@@ -815,7 +798,10 @@ __generic_findstack (void *stack)
 /* This function is called at program startup time to make sure that
mmap, munmap, and getpagesize are resolved if linking dynamically.
We want to resolve them while we have enough stack for them, rather
-   than calling into the dynamic linker while low on stack space.  */
+   than calling into the dynamic linker while low on stack space.
+   Similarly, invoke getenv here to check for split-stack related control
+   variables, since doing do as part of the __morestack path can result
+   in unwanted use of SSE/AVX registers (see GCC PR 86213). */

 void
 __morestack_load_mmap (void)
@@ -825,7 +811,12 @@ __morestack_load_mmap (void)
  TLS accessor function is resolved.  */
   mmap (__morestack_current_segment, 0, PROT_READ, MAP_ANONYMOUS, -1, 0);
   mprotect (NULL, 0, 0);
-  munmap (0, getpagesize ());
+  munmap (0, static_pagesize);
+
+  /* Initialize these values here, so as to avoid dynamic linker
+ activity as part of a __morestack call. */
+  static_pagesize = getpagesize();
+  use_guard_page = getenv ("SPLIT_STACK_GUARD") != 0;
 }

 /* This function may be used to iterate over the stack segments.

Re: Next question: sizeof(char buf[2042])

[Marek Polacek]

On Wed, Jun 20, 2018 at 11:47:45AM -0700, Bruce Korb wrote:
> Yeah, I guess this is Clang, but is it a legal interpretation for Clang?
> 
> In file included from gnu-pw-mgr.c:24:
> 
> In file included from ./fwd.h:288:
> 
> *./seed.c:178:43: **warning: **sizeof on pointer operation will return size
> of 'const char *' instead of 'const char [2042]'*
> 
> *  [-Wsizeof-array-decay]*
> 
> char * tag = scribble_get(sizeof (tag_fmt) + strlen(OPT_ARG(TAG)));
> 
> *  ^~~*
> 
> 
> *It seems like a pretty brain damaged interpretation.*

We'd need to see the code but the warning seems legit.  What's the problem?

Marek

Re: Next question: sizeof(char buf[2042])

[Bruce Korb]

OK. My mistake. "Nevermind" -- side effect of another change.

On Wed, Jun 20, 2018 at 11:47 AM Bruce Korb  wrote:

> Yeah, I guess this is Clang, but is it a legal interpretation for Clang?
>
> In file included from gnu-pw-mgr.c:24:
>
> In file included from ./fwd.h:288:
>
> *./seed.c:178:43: **warning: **sizeof on pointer operation will return
> size of 'const char *' instead of 'const char [2042]'*
>
> *  [-Wsizeof-array-decay]*
>
> char * tag = scribble_get(sizeof (tag_fmt) + strlen(OPT_ARG(TAG)));
>
> *  ^~~*
>
>
> *It seems like a pretty brain damaged interpretation.*
>
> --
>  - Bruce
>


-- 
 - Bruce

Next question: sizeof(char buf[2042])

[Bruce Korb]

Yeah, I guess this is Clang, but is it a legal interpretation for Clang?

In file included from gnu-pw-mgr.c:24:

In file included from ./fwd.h:288:

*./seed.c:178:43: **warning: **sizeof on pointer operation will return size
of 'const char *' instead of 'const char [2042]'*

*  [-Wsizeof-array-decay]*

char * tag = scribble_get(sizeof (tag_fmt) + strlen(OPT_ARG(TAG)));

*  ^~~*


*It seems like a pretty brain damaged interpretation.*

-- 
 - Bruce

Re: -Wno-format-contains-nul

[Bruce Korb]

Thanks. I guess clang forked after the clever NUL-in-format-string was
added, but before my fix. :( I'll add -Wno-format if I can identify clang
over GCC.

On Wed, Jun 20, 2018 at 11:32 AM Jakub Jelinek  wrote:

> On Wed, Jun 20, 2018 at 11:17:50AM -0700, Bruce Korb wrote:
> > Years and years ago, I went to a mess of trouble to implement this
> > specialized warning so I would not have to see it anymore. I use a code
> > generator that puts constant strings into one huge buffer with all the
> > contained strings NUL separated.  Today, I was trying to build on OS/X:
> >
> > libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I. -I../lib -g -O2
> > -Wcast-align -Wmissing-prototypes -Wpointer-arith -Wshadow
> > -Wstrict-prototypes -Wwrite-strings -Wno-format-contains-nul
> > -fno-strict-aliasing -Wstrict-aliasing=2 -MT libopts_la-libopts.lo -MD
> -MP
> > -MF .deps/libopts_la-libopts.Tpo -c libopts.c  -fno-common -DPIC -o
> > .libs/libopts_la-libopts.o
> >
> > warning: unknown warning option '-Wno-format-contains-nul'
> > [-Wunknown-warning-option]
> > In file included from libopts.c:26:
> > ./enum.c:112:38: warning: format string contains '\0' within the string
> > body [-Wformat]
> > fprintf(option_usage_fp, ENUM_ERR_LINE, *(paz_names++));
> >  ^
> > ./ao-strs.h:70:31: note: expanded from macro 'ENUM_ERR_LINE'
> > #define ENUM_ERR_LINE (ao_strs_strtable+304)
> >   ^~
> > ./ao-strs.c:90:20: note: format string is defined here
> > /*   304 */ "  %s\n\0"
> > ~~~^~~
> >
> >
> > Did somebody go to a bunch of trouble to undo my work for the OS/X
> > platform? :(
>
> No, you are probably just using clang rather than gcc.
> gcc has no -Wunknown-warning-option warning, -Wformat-contains-nul
> is a known option and if you used some unknown -Wno-... warning option
> and any diagnostics was emitted, the message would be just:
> warning: unrecognized command line option ‘-Wno-whatever’
>
> Jakub
>


-- 
 - Bruce

Re: -Wno-format-contains-nul

[Jakub Jelinek]

On Wed, Jun 20, 2018 at 11:17:50AM -0700, Bruce Korb wrote:
> Years and years ago, I went to a mess of trouble to implement this
> specialized warning so I would not have to see it anymore. I use a code
> generator that puts constant strings into one huge buffer with all the
> contained strings NUL separated.  Today, I was trying to build on OS/X:
> 
> libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I. -I../lib -g -O2
> -Wcast-align -Wmissing-prototypes -Wpointer-arith -Wshadow
> -Wstrict-prototypes -Wwrite-strings -Wno-format-contains-nul
> -fno-strict-aliasing -Wstrict-aliasing=2 -MT libopts_la-libopts.lo -MD -MP
> -MF .deps/libopts_la-libopts.Tpo -c libopts.c  -fno-common -DPIC -o
> .libs/libopts_la-libopts.o
> 
> warning: unknown warning option '-Wno-format-contains-nul'
> [-Wunknown-warning-option]
> In file included from libopts.c:26:
> ./enum.c:112:38: warning: format string contains '\0' within the string
> body [-Wformat]
> fprintf(option_usage_fp, ENUM_ERR_LINE, *(paz_names++));
>  ^
> ./ao-strs.h:70:31: note: expanded from macro 'ENUM_ERR_LINE'
> #define ENUM_ERR_LINE (ao_strs_strtable+304)
>   ^~
> ./ao-strs.c:90:20: note: format string is defined here
> /*   304 */ "  %s\n\0"
> ~~~^~~
> 
> 
> Did somebody go to a bunch of trouble to undo my work for the OS/X
> platform? :(

No, you are probably just using clang rather than gcc.
gcc has no -Wunknown-warning-option warning, -Wformat-contains-nul
is a known option and if you used some unknown -Wno-... warning option
and any diagnostics was emitted, the message would be just:
warning: unrecognized command line option ‘-Wno-whatever’

Jakub

ICE in a testcase, not sure about solution

[Paul Koning]

I'm running into an ICE in the GIMPLE phase, for gcc.c-torture/compile/386.c, 
on pdp11 -mint32.  That's an oddball where int is 32 bits (due to the flag) but 
Pmode is 16 bits (HImode).

The ICE message is:

../../gcc/gcc/testsuite/gcc.c-torture/compile/386.c: In function ‘main’:
../../gcc/gcc/testsuite/gcc.c-torture/compile/386.c:24:1: error: invalid types 
in nop conversion
 }
 ^
int
int *
b_3 = (int) 
during GIMPLE pass: einline
../../gcc/gcc/testsuite/gcc.c-torture/compile/386.c:24:1: internal compiler 
error: verify_gimple failed

The offending code snippet is (I think):

main ()
{
  int i;
  foobar (i, );
}


foobar (a, b)
{
  int c;

  c = a % b;
  a = a / b;
  return a + b;
}

where the foobar(i, ) call passes an int* to a (defaulted) int function 
parameter.  Is there an assumption that sizeof (int*) >= sizeof(int)?

Any idea where to look?  It only shows up with -mint32; if int is 16 bits all 
is well.  I'm not used to my target breaking things before I even get to RTL...

paul

-Wno-format-contains-nul

[Bruce Korb]

Years and years ago, I went to a mess of trouble to implement this
specialized warning so I would not have to see it anymore. I use a code
generator that puts constant strings into one huge buffer with all the
contained strings NUL separated.  Today, I was trying to build on OS/X:

libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I. -I../lib -g -O2
-Wcast-align -Wmissing-prototypes -Wpointer-arith -Wshadow
-Wstrict-prototypes -Wwrite-strings -Wno-format-contains-nul
-fno-strict-aliasing -Wstrict-aliasing=2 -MT libopts_la-libopts.lo -MD -MP
-MF .deps/libopts_la-libopts.Tpo -c libopts.c  -fno-common -DPIC -o
.libs/libopts_la-libopts.o

warning: unknown warning option '-Wno-format-contains-nul'
[-Wunknown-warning-option]
In file included from libopts.c:26:
./enum.c:112:38: warning: format string contains '\0' within the string
body [-Wformat]
fprintf(option_usage_fp, ENUM_ERR_LINE, *(paz_names++));
 ^
./ao-strs.h:70:31: note: expanded from macro 'ENUM_ERR_LINE'
#define ENUM_ERR_LINE (ao_strs_strtable+304)
  ^~
./ao-strs.c:90:20: note: format string is defined here
/*   304 */ "  %s\n\0"
~~~^~~


Did somebody go to a bunch of trouble to undo my work for the OS/X
platform? :(
-- 
 - Bruce

[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
Bug 53947 depends on bug 85918, which changed state.

Bug 85918 Summary: Conversions to/from [unsigned] long long are not vectorized 
for AVX512DQ target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85918

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

[Bug target/85918] Conversions to/from [unsigned] long long are not vectorized for AVX512DQ target

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Jakub Jelinek  ---
Fixed for 9.1+.

Re: [GSOC] LTO dump tool project

[Hrishikesh Kulkarni]

Hi,

Please find the diff file for dumping tree type stats attached here with.

example:

$ ../stage1-build/gcc/lto1 test_hello.o -fdump-lto-tree-type-stats
Reading object files: test_hello.o
integer_type3
pointer_type3
array_type1
function_type4

I have pushed the changes on Github repo.

Regards,

Hrishikesh

On Mon, Jun 18, 2018 at 2:15 PM, Martin Jambor  wrote:
> Hi,
>
> On Sun, Jun 17 2018, Hrishikesh Kulkarni wrote:
>> Hi,
>>
>> I am trying to isolate the dump tool into real lto-dump tool. I have
>> started with the copy of lto.c into lto-dump.c and done the
>> changes to Make-lang.in and config-lang.in suggested by Martin (patch
>> attached). However when I try to build, I get the following error:
>>
>> In file included from ../../gcc/gcc/lto/lto-dump.c:24:0:
>>
>> ../../gcc/gcc/coretypes.h:397:24: fatal error: insn-modes.h: No such
>>
>> file or directory
>>
>> compilation terminated.
>>
>>
>> I am unable to find the missing dependencies and would be grateful for
>> suggestions on how to resolve the issue.
>
> insn-modes.h is one of header files which are generated at build time,
> you will find it in the gcc subdirectory of your build directory (as
> opposed to the source directory).
>
> Martin
diff --git a/gcc/lto/lang.opt b/gcc/lto/lang.opt
index c10c662..dd506c0 100644
--- a/gcc/lto/lang.opt
+++ b/gcc/lto/lang.opt
@@ -77,6 +77,9 @@ LTO Driver RejectNegative Joined Var(flag_lto_dump_symbol)
 demangle
 LTO Var(flag_lto_dump_demangle)
 
+fdump-lto-tree-type-stats
+LTO Var(flag_lto_dump_tree_type_stats)
+
 fdump-lto-body=
 LTO Driver RejectNegative Joined Var(flag_lto_dump_body)
 
diff --git a/gcc/lto/lto.c b/gcc/lto/lto.c
index afdb76a..760a796 100644
--- a/gcc/lto/lto.c
+++ b/gcc/lto/lto.c
@@ -1799,9 +1799,6 @@ lto_read_decls (struct lto_file_decl_data *decl_data, const void *data,
 	  data_in->location_cache.accept_location_cache ();
 
 	  bool seen_type = false;
-
-
-
 	  for (unsigned i = 0; i < len; ++i)
 	{
 	  tree t = streamer_tree_cache_get_tree (data_in->reader_cache,
@@ -1810,14 +1807,14 @@ lto_read_decls (struct lto_file_decl_data *decl_data, const void *data,
 		 chains.  */
 	  if (TYPE_P (t))
 		{ 
-  itr = stats.find(TREE_CODE(t));
-  if (itr == stats.end())
+  if (flag_lto_dump_tree_type_stats)
   {
-stats.insert(std :: pair  (TREE_CODE(t), 1));
-  }
-  else
-itr->second++;
-
+itr = stats.find(TREE_CODE(t));
+if (itr == stats.end())
+  stats.insert(std :: pair  (TREE_CODE(t), 1));
+else
+  itr->second++;
+  }  
 		  seen_type = true;
 		  num_prevailing_types++;
 		  lto_fixup_prevailing_type (t);
@@ -1865,10 +1862,9 @@ lto_read_decls (struct lto_file_decl_data *decl_data, const void *data,
 	}
 }
 fprintf(stderr, "\n");
-for (itr = stats.begin(); itr != stats.end(); ++itr)
-{
-  fprintf(stderr, "\t%s\t%d\n", get_tree_code_name(itr->first), itr->second );
-}
+if (flag_lto_dump_tree_type_stats)
+  for (itr = stats.begin(); itr != stats.end(); ++itr)
+fprintf(stderr, "\t%s\t%d\n", get_tree_code_name(itr->first), itr->second );
 
   data_in->location_cache.apply_location_cache ();
 

[Bug c++/86226] A bug seems to be not fully fixed

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Jonathan Wakely  ---
(In reply to zhonghao from comment #0)
> It seems that the bug is not fixed, right?

Wrong. The old bug was fixed by making it a "pedwarn" i.e. diagnosing the
extension when -pedantic is used. That was fixed.

In C++2a the code is now valid, not a GNU extension, so you get no warning with
-std=c++2a, as expected.

This is not a bug.

[Bug c++/38087] g++ accepts invalid destructor call

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||zhonghao at pku dot org.cn

--- Comment #7 from Jonathan Wakely  ---
*** Bug 86225 has been marked as a duplicate of this bug. ***

[Bug c++/86225] Missing error message

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Jonathan Wakely  ---
.

*** This bug has been marked as a duplicate of bug 38087 ***

Re: [OpenACC] Update OpenACC data clause semantics to the 2.5 behavior - runtime

[Cesar Philippidis]

On 06/20/2018 10:03 AM, Jakub Jelinek wrote:
> On Wed, Jun 20, 2018 at 09:59:29AM -0700, Cesar Philippidis wrote:

>> If it means anything, we have a significant async change that removes
>> the async_refcount field in that struct.
> 
> Wasn't async_refcount removed 2 years ago?

You're right. I was looking at the og8 history. I'm juggling a lot of
patches right now.

Cesar

[Bug c++/53109] e.E::~E() should compile without error in c++ 2011

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-06-20
 Ever confirmed|0   |1

--- Comment #3 from Jonathan Wakely  ---
I think the code is valid and should be accepted.

Re: [OpenACC] Update OpenACC data clause semantics to the 2.5 behavior - runtime

[Jakub Jelinek]

On Wed, Jun 20, 2018 at 09:59:29AM -0700, Cesar Philippidis wrote:
> > I'm not entirely happy about this, it grows the structure for not just
> > OpenACC, but also OpenMP which will never use it.  Are there any fields
> > not used by OpenACC?  E.g. is link_key used?
> > Or could the dynamic refcounts be an array allocated (for OpenACC mappings
> > only) after the tgt->array array, accessed using
> > key->tgt->dynamic_refcounts[key - key->tgt->array] ?
> Sorry, I mistakenly committed this patch with the front end changes. Can
> I address this issue in a follow up patch?

Yes.  If it isn't possible to get rid of it, I can live with it, but would
appreciate if you tried to avoid it if possible.

> If it means anything, we have a significant async change that removes
> the async_refcount field in that struct.

Wasn't async_refcount removed 2 years ago?

Jakub

[Bug c++/85634] [8/9 Regression] ICE in tsubst_copy, at cp/pt.c:15483

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

 Status|RESOLVED|ASSIGNED
 Resolution|FIXED   |---

--- Comment #11 from Nathan Sidwell  ---
Bah, there's another bug lurking in the original testcase ...

Re: [OpenACC] Update OpenACC data clause semantics to the 2.5 behavior - runtime

[Cesar Philippidis]

On 06/20/2018 09:45 AM, Jakub Jelinek wrote:
> On Tue, Jun 19, 2018 at 10:01:20AM -0700, Cesar Philippidis wrote:

>> >From 53ee03231c5e6e4747b4ef01335079a2d4a98480 Mon Sep 17 00:00:00 2001
>> From: Cesar Philippidis 
>> Date: Tue, 19 Jun 2018 09:33:04 -0700
>> Subject: [PATCH 7/7] runtime changes
>>
>> ---
>>  libgomp/libgomp.h   |   7 +-
>>  libgomp/libgomp.map |  12 +++
>>  libgomp/oacc-mem.c  | 196 ---
>>  libgomp/oacc-parallel.c | 198 ++--
>>  libgomp/openacc.f90 | 112 +++
>>  libgomp/openacc.h   |   6 ++
>>  libgomp/openacc_lib.h   |  40 
>>  libgomp/target.c|  41 -
>>  8 files changed, 528 insertions(+), 84 deletions(-)
>>
>> diff --git a/libgomp/libgomp.h b/libgomp/libgomp.h
>> index 10ea8940c96..3a8cc2bd7d6 100644
>> --- a/libgomp/libgomp.h
>> +++ b/libgomp/libgomp.h
>> @@ -853,6 +853,8 @@ struct splay_tree_key_s {
>>uintptr_t tgt_offset;
>>/* Reference count.  */
>>uintptr_t refcount;
>> +  /* Dynamic reference count.  */
>> +  uintptr_t dynamic_refcount;
>>/* Pointer to the original mapping of "omp declare target link" object.  
>> */
>>splay_tree_key link_key;
>>  };
> 
> I'm not entirely happy about this, it grows the structure for not just
> OpenACC, but also OpenMP which will never use it.  Are there any fields
> not used by OpenACC?  E.g. is link_key used?
> Or could the dynamic refcounts be an array allocated (for OpenACC mappings
> only) after the tgt->array array, accessed using
> key->tgt->dynamic_refcounts[key - key->tgt->array] ?
Sorry, I mistakenly committed this patch with the front end changes. Can
I address this issue in a follow up patch?

If it means anything, we have a significant async change that removes
the async_refcount field in that struct.

Cesar

[Bug c++/85634] [8/9 Regression] ICE in tsubst_copy, at cp/pt.c:15483

[nathan at gcc dot gnu.org]

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

--- Comment #10 from Nathan Sidwell  ---
Author: nathan
Date: Wed Jun 20 16:54:44 2018
New Revision: 261814

URL: https://gcc.gnu.org/viewcvs?rev=261814=gcc=rev
Log:
[PR c++/85634] Fix tsubst ICE

https://gcc.gnu.org/ml/gcc-patches/2018-06/msg01269.html
PR c++/85634 - tsubst ICE on unmarked lookup
* parser.c (cp_parser_primary_expression): Keep lookup in template.

PR c++/85634 - tsubst ICE on unmarked lookup
* g++.dg/lookup/pr85634.C: New.

Added:
branches/gcc-8-branch/gcc/testsuite/g++.dg/lookup/pr85634.C
Modified:
branches/gcc-8-branch/gcc/cp/ChangeLog
branches/gcc-8-branch/gcc/cp/parser.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog

[Bug c++/85634] [8/9 Regression] ICE in tsubst_copy, at cp/pt.c:15483

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #9 from Nathan Sidwell  ---
Fixed gcc-8 r261814

Re: [PR c++/85634] Fix tsubst ICE

[Nathan Sidwell]

And here's the patch for gcc-8.

nathan
--
Nathan Sidwell
2018-06-20  Nathan Sidwell  

	PR c++/85634 - tsubst ICE on unmarked lookup
	* parser.c (cp_parser_primary_expression): Keep lookup in template.

	PR c++/85634 - tsubst ICE on unmarked lookup
	* g++.dg/lookup/pr85634.C: New.

Index: gcc/cp/parser.c
===
--- gcc/cp/parser.c	(revision 261802)
+++ gcc/cp/parser.c	(working copy)
@@ -5609,6 +5609,9 @@ cp_parser_primary_expression (cp_parser
 	  }
 	  }
 
+	if (processing_template_decl && is_overloaded_fn (decl))
+	  lookup_keep (get_fns (decl), true);
+
 	decl = (finish_id_expression
 		(id_expression, decl, parser->scope,
 		 idk,
Index: gcc/testsuite/g++.dg/lookup/pr85634.C
===
--- gcc/testsuite/g++.dg/lookup/pr85634.C	(revision 0)
+++ gcc/testsuite/g++.dg/lookup/pr85634.C	(working copy)
@@ -0,0 +1,18 @@
+// PR c++/85634 ICE managing lookup set
+
+namespace N {
+  template  void Foo (T *const &);
+}
+
+using namespace N;
+
+template void Foo (const T &);
+
+
+template 
+void Frob()
+{
+  void (*op)(const T&) = Foo;
+}
+
+template void Frob();

Re: [OpenACC] Update OpenACC data clause semantics to the 2.5 behavior - runtime

[Jakub Jelinek]

On Tue, Jun 19, 2018 at 10:01:20AM -0700, Cesar Philippidis wrote:
> This patch implements the OpenACC 2.5 data clause semantics in libgomp.
> 
> Is it OK for trunk?

> 2018-06-19  Chung-Lin Tang 
>   Thomas Schwinge 
>   Cesar Philippidis  
> 
>   libgomp/
>   * libgomp.h (struct splay_tree_key_s): Add dynamic_refcount member.
>   (gomp_acc_remove_pointer): Update declaration.
>   (gomp_acc_declare_allocate): Declare.
>   (gomp_remove_var): Declare.
>   * libgomp.map (OACC_2.5): Define.
>   * oacc-mem.c (acc_map_data): Update refcount.
>   (acc_unmap_data): Likewise.
>   (present_create_copy): Likewise.
>   (acc_create): Add FLAG_PRESENT when calling present_create_copy.
>   (acc_copyin): Likewise.
>   (FLAG_FINALIZE): Define.
>   (delete_copyout): Update dynamic refcounts, add support for FINALIZE.
>   (acc_delete_finalize): New function.
>   (acc_delete_finalize_async): New function.
>   (acc_copyout_finalize): New function.
>   (acc_copyout_finalize_async): New function.
>   (gomp_acc_insert_pointer): Update refcounts.
>   (gomp_acc_remove_pointer): Return if data is not present on the
>   accelerator.
>   * oacc-parallel.c (find_pset): Rename to find_pointer.
>   (find_pointer): Add support for GOMP_MAP_POINTER.
>   (handle_ftn_pointers): New function.
>   (GOACC_parallel_keyed): Update refcounts of variables.
>   (GOACC_enter_exit_data): Add support for finalized data mappings.
>   Add support for GOMP_MAP_{TO,ALLOC,RELESE,FROM}. Update handling
>   of fortran arrays.
>   (GOACC_update): Add support for GOMP_MAP_{ALWAYS_POINTER,TO,FROM}.
>   (GOACC_declare): Add support for GOMP_MAP_RELEASE, remove support
>   for GOMP_MAP_FORCE_FROM.
>   * openacc.f90 (module openacc_internal): Add
>   acc_copyout_finalize_{32_h,64_h,array_h,_l}, and
>   acc_delete_finalize_{32_h,64_h,array_h,_l}. Add interfaces for
>   acc_copyout_finalize and acc_delete_finalize.
>   (acc_copyout_finalize_32_h): New subroutine.
>   (acc_copyout_finalize_64_h): New subroutine.
>   (acc_copyout_finalize_array_h): New subroutine.
>   (acc_delete_finalize_32_h): New subroutine.
>   (acc_delete_finalize_64_h): New subroutine.
>   (acc_delete_finalize_array_h): New subroutine.
>   * openacc.h (acc_copyout_finalize): Declare.
>   (acc_copyout_finalize_async): Declare.
>   (acc_delete_finalize): Declare.
>   (acc_delete_finalize_async): Declare.
>   * openacc_lib.h (acc_copyout_finalize): New interface.
>   (acc_delete_finalize): New interface.
>   * target.c (gomp_map_vars): Update dynamic_refcount.
>   (gomp_remove_var): New function.
>   (gomp_unmap_vars): Use it.
>   (gomp_unload_image_from_device): Likewise.
> 
> 
> >From 53ee03231c5e6e4747b4ef01335079a2d4a98480 Mon Sep 17 00:00:00 2001
> From: Cesar Philippidis 
> Date: Tue, 19 Jun 2018 09:33:04 -0700
> Subject: [PATCH 7/7] runtime changes
> 
> ---
>  libgomp/libgomp.h   |   7 +-
>  libgomp/libgomp.map |  12 +++
>  libgomp/oacc-mem.c  | 196 ---
>  libgomp/oacc-parallel.c | 198 ++--
>  libgomp/openacc.f90 | 112 +++
>  libgomp/openacc.h   |   6 ++
>  libgomp/openacc_lib.h   |  40 
>  libgomp/target.c|  41 -
>  8 files changed, 528 insertions(+), 84 deletions(-)
> 
> diff --git a/libgomp/libgomp.h b/libgomp/libgomp.h
> index 10ea8940c96..3a8cc2bd7d6 100644
> --- a/libgomp/libgomp.h
> +++ b/libgomp/libgomp.h
> @@ -853,6 +853,8 @@ struct splay_tree_key_s {
>uintptr_t tgt_offset;
>/* Reference count.  */
>uintptr_t refcount;
> +  /* Dynamic reference count.  */
> +  uintptr_t dynamic_refcount;
>/* Pointer to the original mapping of "omp declare target link" object.  */
>splay_tree_key link_key;
>  };

I'm not entirely happy about this, it grows the structure for not just
OpenACC, but also OpenMP which will never use it.  Are there any fields
not used by OpenACC?  E.g. is link_key used?
Or could the dynamic refcounts be an array allocated (for OpenACC mappings
only) after the tgt->array array, accessed using
key->tgt->dynamic_refcounts[key - key->tgt->array] ?

Jakub

[Bug c++/86225] Missing error message

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
This is a dup of an existing bug.

Re: [OpenACC] Update OpenACC data clause semantics to the 2.5 behavior - middle end

[Jakub Jelinek]

On Tue, Jun 19, 2018 at 10:00:37AM -0700, Cesar Philippidis wrote:
> This patch implements the OpenACC 2.5 data clause semantics in the
> middle end.
> 
> Is it OK for trunk?
> 
> Cesar

> 2018-06-19  Chung-Lin Tang 
>   Thomas Schwinge 
>   Cesar Philippidis  
> 
>   gcc/c-family/
>   * c-pragma.h (enum pragma_omp_clause): Add
>   PRAGMA_OACC_CLAUSE_{FINALIZE,IF_PRESENT}. Remove
>   PRAGMA_OACC_CLAUSE_PRESENT_OR_{COPY,COPYIN,COPYOUT,CREATE}.
> 
>   gcc/
>   * gimplify.c (gimplify_scan_omp_clauses): Add support for
>   OMP_CLAUSE_{IF_PRESENT,FINALIZE}.
>   (gimplify_adjust_omp_clauses): Likewise.
>   (gimplify_oacc_declare_1): Add support for GOMP_MAP_RELEASE, remove
>   support for GOMP_MAP_FORCE_{ALLOC,TO,FROM,TOFROM}.
>   (gimplify_omp_target_update): Update handling of acc update and
>   enter/exit data.
>   * omp-low.c (install_var_field): Remove unused parameter
>   base_pointers_restrict.
>   (scan_sharing_clauses): Remove base_pointers_restrict parameter.
>   Update call to install_var_field. Handle OMP_CLAUSE_{IF_PRESENT,
>   FINALIZE}
>   (omp_target_base_pointers_restrict_p): Delete.
>   (scan_omp_target): Update call to scan_sharing_clauses.
>   * tree-core.h (enum omp_clause_code): Add OMP_CLAUSE_{IF_PRESENT,
>   FINALIZE}.
>   * tree-nested.c (convert_nonlocal_omp_clauses): Handle
>   OMP_CLAUSE_{IF_PRESENT,FINALIZE}.
>   (convert_local_omp_clauses): Likewise.
>   * tree-pretty-print.c (dump_omp_clause): Likewise.
>   * tree.c (omp_clause_num_ops): Add entries for  OMP_CLAUSE_{IF_PRESENT,
>   FINALIZE}.
>   (omp_clause_code_name): Likewise.

Ok.

Jakub

Re: [OpenACC] Update OpenACC data clause semantics to the 2.5 behavior - Fortran

[Jakub Jelinek]

On Tue, Jun 19, 2018 at 09:59:57AM -0700, Cesar Philippidis wrote:
> This patch implements the OpenACC 2.5 data clause semantics in the
> Fortran FE.
> 
> Is it OK for trunk?
> 
> Cesar

> 2018-06-19  Chung-Lin Tang 
>   Thomas Schwinge 
>   Cesar Philippidis  
> 
>   gcc/fortran/
>   * gfortran.h (gfc_omp_clauses): Add unsigned if_present, finalize
>   bitfields.
>   * openmp.c (enum omp_mask2): Remove OMP_CLAUSE_PRESENT_OR_*. Add
>   OMP_CLAUSE_{IF_PRESENT,FINALIZE}.
>   (gfc_match_omp_clauses): Update handling of copy, copyin, copyout,
>   create, deviceptr, present_of_*. Add support for finalize and
>   if_present.
>   (OACC_PARALLEL_CLAUSES): Remove PRESENT_OR_* clauses.
>   (OACC_KERNELS_CLAUSES): Likewise.
>   (OACC_DATA_CLAUSES): Likewise.
>   (OACC_DECLARE_CLAUSES): Likewise.
>   (OACC_UPDATE_CLAUSES): Add IF_PRESENT clause.
>   (OACC_ENTER_DATA_CLAUSES): Remove PRESENT_OR_* clauses.
>   (OACC_EXIT_DATA_CLAUSES): Add FINALIZE clause.
>   (gfc_match_oacc_declare): Update to OpenACC 2.5 semantics.
>   * trans-openmp.c (gfc_trans_omp_clauses): Add support for IF_PRESENT
>   and FINALIZE.

Ok.

Jakub

[wwwdocs] Document some recent libstdc++ changes

[Jonathan Wakely]

Committed to CVS.


Index: htdocs/gcc-9/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-9/changes.html,v
retrieving revision 1.8
diff -u -r1.8 changes.html
--- htdocs/gcc-9/changes.html	8 Jun 2018 15:28:59 -	1.8
+++ htdocs/gcc-9/changes.html	20 Jun 2018 16:15:05 -
@@ -57,7 +57,15 @@
   
 
 
-
+Runtime Library (libstdc++)
+
+  Improved experimental support for C++2a,
+  including std::remove_cvref
+  and the version header.
+  Support for opening file streams with wide character paths on Windows
+  Incomplete support for the C++17 Filesystem library and the Filesystem
+  TS on Windows.
+
 
 
 

Re: [OpenACC] Update OpenACC data clause semantics to the 2.5 behavior - C++

[Jakub Jelinek]

On Tue, Jun 19, 2018 at 09:58:26AM -0700, Cesar Philippidis wrote:
> This patch implements the OpenACC 2.5 data clause semantics in the C++ FE.
> 
> Is it OK for trunk?
> 
> Cesar

> 2018-06-19  Chung-Lin Tang 
>   Thomas Schwinge 
>   Cesar Philippidis  
> 
>   gcc/cp/
>   * parser.c (cp_parser_omp_clause_name): Add support for finalize
>   and if_present. Make present_or_{copy,copyin,copyout,create} aliases
>   to their non-present_or_* counterparts. Make 'self' an alias to
>   PRAGMA_OACC_CLAUSE_HOST.
>   (cp_parser_oacc_data_clause): Update GOMP mappings for
>   PRAGMA_OACC_CLAUSE_{COPY,COPYIN,COPYOUT,CREATE,DELETE}. Remove
>   PRAGMA_OACC_CLAUSE_{SELF,PRESENT_OR_*}.
>   (cp_parser_oacc_all_clauses): Handle finalize and if_present clauses.
>   Remove support for present_or_* clauses.
>   (OACC_KERNELS_CLAUSE_MASK): Remove PRESENT_OR_* clauses.
>   (OACC_PARALLEL_CLAUSE_MASK): Likewise.
>   (OACC_DECLARE_CLAUSE_MASK): Likewise.
>   (OACC_DATA_CLAUSE_MASK): Likewise.
>   (OACC_ENTER_DATA_CLAUSE_MASK): Remove PRESENT_OR_* clauses.
>   (OACC_EXIT_DATA_CLAUSE_MASK): Add FINALIZE clause.
>   (OACC_UPDATE_CLAUSE_MASK): Remove SELF, add IF_PRESENT.
>   (cp_parser_oacc_declare): Remove PRESENT_OR_* clauses.
>   * pt.c (tsubst_omp_clauses): Handle IF_PRESENT and FINALIZE.
>   * semantics.c (finish_omp_clauses): Handle IF_PRESENT and FINALIZE.

Ok, thanks.

Jakub

Re: [OpenACC] Update OpenACC data clause semantics to the 2.5 behavior - C

[Jakub Jelinek]

On Tue, Jun 19, 2018 at 09:59:09AM -0700, Cesar Philippidis wrote:
> This patch implements the OpenACC 2.5 data clause semantics in the C FE.
> 
> Is it OK for trunk?
> 
> Cesar

> 2018-06-19  Chung-Lin Tang 
>   Thomas Schwinge 
>   Cesar Philippidis  
> 
>   gcc/c/
>   * c-parser.c (c_parser_omp_clause_name): Add support for finalize
>   and if_present. Make present_or_{copy,copyin,copyout,create} aliases
>   to their non-present_or_* counterparts. Make 'self' an alias to
>   PRAGMA_OACC_CLAUSE_HOST.
>   (c_parser_oacc_data_clause): Update GOMP mappings for
>   PRAGMA_OACC_CLAUSE_{COPY,COPYIN,COPYOUT,CREATE,DELETE}. Remove
>   PRAGMA_OACC_CLAUSE_{SELF,PRESENT_OR_*}.
>   (c_parser_oacc_all_clauses): Handle finalize and if_present clauses.
>   Remove support for present_or_* clauses.
>   (OACC_KERNELS_CLAUSE_MASK): Remove PRESENT_OR_* clauses.
>   (OACC_PARALLEL_CLAUSE_MASK): Likewise.
>   (OACC_DECLARE_CLAUSE_MASK): Likewise.
>   (OACC_DATA_CLAUSE_MASK): Likewise.
>   (OACC_ENTER_DATA_CLAUSE_MASK): Remove PRESENT_OR_* clauses.
>   (OACC_EXIT_DATA_CLAUSE_MASK): Add FINALIZE clause.
>   (OACC_UPDATE_CLAUSE_MASK): Remove SELF, add IF_PRESENT.
>   (c_parser_oacc_declare): Remove PRESENT_OR_* clauses.
>   * c-typeck.c (c_finish_omp_clauses): Handle IF_PRESENT and FINALIZE.

Ok.

Jakub

[Bug c++/86210] [6/7/8/9 Regression] Missing -Wnonnull warning for function defined in the same TU

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Regression fixed for 8.2+ so far by the above changes, for the enhancement see
above comment.

[Bug c++/86210] [6/7/8/9 Regression] Missing -Wnonnull warning for function defined in the same TU

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Wed Jun 20 16:08:14 2018
New Revision: 261812

URL: https://gcc.gnu.org/viewcvs?rev=261812=gcc=rev
Log:
PR c++/86210
* c-common.c (check_nonnull_arg): Use fold_for_warn.  Adjust obsolete
comment.

* g++.dg/warn/Wnonnull4.C: New test.

Added:
branches/gcc-8-branch/gcc/testsuite/g++.dg/warn/Wnonnull4.C
Modified:
branches/gcc-8-branch/gcc/c-family/ChangeLog
branches/gcc-8-branch/gcc/c-family/c-common.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog

[Bug c++/86210] [6/7/8/9 Regression] Missing -Wnonnull warning for function defined in the same TU

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Wed Jun 20 16:07:21 2018
New Revision: 261811

URL: https://gcc.gnu.org/viewcvs?rev=261811=gcc=rev
Log:
PR c++/86210
* c-common.c (check_nonnull_arg): Use fold_for_warn.  Adjust obsolete
comment.

* g++.dg/warn/Wnonnull4.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/warn/Wnonnull4.C
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/86245] New: _GLIBCXX_LONG_DOUBLE_COMPAT GLIBCXX_3.4.21 issues

[jakub at gcc dot gnu.org]

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

Bug ID: 86245
   Summary: _GLIBCXX_LONG_DOUBLE_COMPAT GLIBCXX_3.4.21 issues
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

The powerpc64-linux basic_symbols.txt shows a couple of problematic symbols:

FUNC:_ZNKSt7__cxx119money_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE3getES4_S4_bRSt8ios_baseRSt12_Ios_IostateRg@@GLIBCXX_3.4.21
FUNC:_ZNKSt7__cxx119money_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE6do_getES4_S4_bRSt8ios_baseRSt12_Ios_IostateRg@@GLIBCXX_3.4.21
FUNC:_ZNKSt7__cxx119money_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE3getES4_S4_bRSt8ios_baseRSt12_Ios_IostateRg@@GLIBCXX_3.4.21
FUNC:_ZNKSt7__cxx119money_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE6do_getES4_S4_bRSt8ios_baseRSt12_Ios_IostateRg@@GLIBCXX_3.4.21
FUNC:_ZNKSt7__cxx119money_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEE3putES4_bRSt8ios_basecg@@GLIBCXX_3.4.21
FUNC:_ZNKSt7__cxx119money_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEE6do_putES4_bRSt8ios_basecg@@GLIBCXX_3.4.21
FUNC:_ZNKSt7__cxx119money_putIwSt19ostreambuf_iteratorIwSt11char_traitsIwEEE3putES4_bRSt8ios_basewg@@GLIBCXX_3.4.21
FUNC:_ZNKSt7__cxx119money_putIwSt19ostreambuf_iteratorIwSt11char_traitsIwEEE6do_putES4_bRSt8ios_basewg@@GLIBCXX_3.4.21

One issue is that those really should have been added in the
_GLIBCXX_LONG_DOUBLE_COMPAT != 0 configurations to GLIBCXX_LDBL_3.4.21 symver
rather than GLIBCXX_3.4.21.  Perhaps it is a waste to add alias for those
though and we can just live with that glitch.  The bigger problem is that using
those symbols will not work in programs compiled with -mlong-double-64, because
nothing exports the corresponding e mangled symbols.  I think that needs
fixing, either they can be implemented with a double argument and aliases (and
make the d mangled symbols hidden), or in separate source files that are
compiled with -mlong-double-64.

[Bug c++/86243] unknown attributes causing hard error

[h2+bugs at fsfe dot org]

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

--- Comment #2 from Hannes Hauswedell  ---
(In reply to Jonathan Wakely from comment #1)
> (In reply to Hannes Hauswedell from comment #0)
> > Note that I am not even setting -Wall or -Wextra.
> 
> As documented, -Wattributes is enabled by default and you need to use
> -Wno-attributes to disable it.

Hm, IMHO this could maybe be reconsidered now that attributes are a
standardised feature of the language and the standard explicitly states:
"Any attribute-token that is not recognized by the implementation is ignored."
I think this was added precisely to make upgrades to new attributes seamless
and to support different platform-specific ones. This is not the case if they
produce warnings, especially by default.

BUT this bug report is primarily about the error and not the warning!

Re: [PATCH] LWG 3050 Fix cv-qualification of convertibility constraints

[Jonathan Wakely]

On 18/06/18 19:00 +0100, Jonathan Wakely wrote:

This issue hasn't been voted into the working draft yet, but it's been
approved by LWG and is obviously correct.

* include/std/chrono (duration, operator*, operator/, operator%): Use
const-qualified type as source type in is_convertible constraints.
* testsuite/20_util/duration/arithmetic/dr3050.cc: New.


I forgot to 'git add' this new test. Here it is.

Tested x86_64-linux, committed to trunk.

commit 89ea69b95205a1cfadee6599f2168bc077f57fb7
Author: Jonathan Wakely 
Date:   Tue Jun 19 22:06:56 2018 +0100

Add testcase accidentally not committed earlier

* testsuite/20_util/duration/arithmetic/dr3050.cc: Add new test
missed from recent commit.

diff --git a/libstdc++-v3/testsuite/20_util/duration/arithmetic/dr3050.cc b/libstdc++-v3/testsuite/20_util/duration/arithmetic/dr3050.cc
new file mode 100644
index 000..a2d26620466
--- /dev/null
+++ b/libstdc++-v3/testsuite/20_util/duration/arithmetic/dr3050.cc
@@ -0,0 +1,30 @@
+// Copyright (C) 2018 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3.  If not see
+// .
+
+// { dg-do compile { target c++11 } }
+
+#include 
+
+struct X { operator int64_t() /* not const */; };
+
+void test01(std::chrono::seconds s, X x)
+{
+  s * x; // { dg-error "no match" }
+  x * s; // { dg-error "no match" }
+  s / x; // { dg-error "no match" }
+  s % x; // { dg-error "no match" }
+}

[Bug c++/86210] [6/7/8/9 Regression] Missing -Wnonnull warning for function defined in the same TU

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
WIP patch to warn also during inlining, with the intent to handle e.g.
  int *p = 0;
  declared_and_defined(p);
for both C/C++.  Unfortunately if it is inlined during early inlining, we still
don't warn, because no forward propagation etc. is done before early inlining.
With -fno-early-inlining -O2 -Wnonnull we don't warn either, because the call
is optimized away, as it is determined const and doesn't use return value. 
With a side-effect in there it warns without early inlining.

Is this still worth doing?

--- gcc/tree-ssa-ccp.c.jj   2018-06-13 10:05:30.357110986 +0200
+++ gcc/tree-ssa-ccp.c  2018-06-20 17:14:00.374389421 +0200
@@ -3391,6 +3391,41 @@ make_pass_fold_builtins (gcc::context *c
   return new pass_fold_builtins (ctxt);
 }

+/* Emit -Wnonnull warnings for call STMT.  */
+
+void
+warn_nonnull_call (gcall *stmt)
+{
+  bitmap nonnullargs = get_nonnull_args (gimple_call_fntype (stmt));
+  if (!nonnullargs)
+return;
+
+  for (unsigned i = 0; i < gimple_call_num_args (stmt); i++)
+{
+  tree arg = gimple_call_arg (stmt, i);
+  if (TREE_CODE (TREE_TYPE (arg)) != POINTER_TYPE)
+   continue;
+  if (!integer_zerop (arg))
+   continue;
+  if (!bitmap_empty_p (nonnullargs) && !bitmap_bit_p (nonnullargs, i))
+   continue;
+
+  location_t loc = gimple_location (stmt);
+  if (warning_at (loc, OPT_Wnonnull,
+ "%Gargument %u null where non-null expected",
+ stmt, i + 1))
+   {
+ tree fndecl = gimple_call_fndecl (stmt);
+ if (fndecl && DECL_IS_BUILTIN (fndecl))
+   inform (loc, "in a call to built-in function %qD", fndecl);
+ else if (fndecl)
+   inform (DECL_SOURCE_LOCATION (fndecl),
+   "in a call to function %qD declared here", fndecl);
+   }
+}
+  BITMAP_FREE (nonnullargs);
+}
+
 /* A simple pass that emits some warnings post IPA.  */

 namespace {
@@ -3437,41 +3474,7 @@ pass_post_ipa_warn::execute (function *f
continue;

  if (warn_nonnull)
-   {
- bitmap nonnullargs
-   = get_nonnull_args (gimple_call_fntype (stmt));
- if (nonnullargs)
-   {
- for (unsigned i = 0; i < gimple_call_num_args (stmt); i++)
-   {
- tree arg = gimple_call_arg (stmt, i);
- if (TREE_CODE (TREE_TYPE (arg)) != POINTER_TYPE)
-   continue;
- if (!integer_zerop (arg))
-   continue;
- if (!bitmap_empty_p (nonnullargs)
- && !bitmap_bit_p (nonnullargs, i))
-   continue;
-
- location_t loc = gimple_location (stmt);
- if (warning_at (loc, OPT_Wnonnull,
- "%Gargument %u null where non-null "
- "expected", as_a (stmt), i + 1))
-   {
- tree fndecl = gimple_call_fndecl (stmt);
- if (fndecl && DECL_IS_BUILTIN (fndecl))
-   inform (loc, "in a call to built-in function %qD",
-   fndecl);
- else if (fndecl)
-   inform (DECL_SOURCE_LOCATION (fndecl),
-   "in a call to function %qD declared here",
-   fndecl);
-
-   }
-   }
- BITMAP_FREE (nonnullargs);
-   }
-   }
+   warn_nonnull_call (as_a (stmt));
}
 }
   return 0;
--- gcc/tree-ssa-ccp.h.jj   2018-01-03 10:19:54.257533814 +0100
+++ gcc/tree-ssa-ccp.h  2018-06-20 17:14:38.915447584 +0200
@@ -26,4 +26,6 @@ void bit_value_binop (enum tree_code, si
 void bit_value_unop (enum tree_code, signop, int, widest_int *, widest_int *,
 signop, int, const widest_int &, const widest_int &);

+void warn_nonnull_call (gcall *);
+
 #endif
--- gcc/tree-inline.c.jj2018-06-20 08:15:41.224868655 +0200
+++ gcc/tree-inline.c   2018-06-20 17:34:39.676261250 +0200
@@ -60,6 +60,7 @@ along with GCC; see the file COPYING3.
 #include "stringpool.h"
 #include "attribs.h"
 #include "sreal.h"
+#include "tree-ssa-ccp.h"

 /* I'm not real happy about this, but we need to handle gimple and
non-gimple trees.  */
@@ -4409,6 +4410,9 @@ expand_call_inline (basic_block bb, gimp
 }
   id->src_node = cg_edge->callee;

+  if (warn_nonnull && !gimple_no_warning_p (call_stmt))
+warn_nonnull_call (call_stmt);
+
   /* If callee is thunk, all we need is to adjust the THIS pointer
  and redirect to function being thunked.  */
   if (id->src_node->thunk.thunk_p)

[Bug c++/86240] [9 Regression] ice: unexpected expression absu_expr

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Marek Polacek  ---
Fixed.

[Bug c++/86240] [9 Regression] ice: unexpected expression absu_expr

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
Author: mpolacek
Date: Wed Jun 20 15:46:02 2018
New Revision: 261809

URL: https://gcc.gnu.org/viewcvs?rev=261809=gcc=rev
Log:
PR c++/86240
* constexpr.c (cxx_eval_constant_expression): Handle ABSU_EXPR.
(fold_simple_1): Likewise.
* error.c (dump_expr): Likewise.

* g++.dg/pr86240.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/pr86240.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c
trunk/gcc/cp/error.c
trunk/gcc/testsuite/ChangeLog

Re: [C++ Patch] Improve grokfndecl locations

[Jason Merrill]

On Tue, Jun 19, 2018 at 4:55 PM, Paolo Carlini  wrote:
> Hi,
>
> the below implements a couple of independent ideas. First, adds a const
> cp_decl_specifier_seq * parameter, similarly to grokvardecl: this way the
> function has available locations[ds_inline], locations[ds_constexpr],
> locations[ds_type_spec] which can use in some error messages. Second, the
> handling of an UNKNOWN_LOCATION as location_t argument is reworked a bit -
> in particular the "deprecated" build_lang_decl call is changed to
> build_lang_decl_loc: everything I already tweaked in the function about
> locations should be now 100% correct + the use of the location_t argument
> can be safely extended to a couple of additional places. Tested
> x86_64-linux.

>+   error_at (location,
>+ "default arguments are not allowed in declaration "
>+ "of friend template specialization %qD",
>+ decl);

You can use defarg_location (or location_of) for the location of a
default argument.  OK with that change.

Jason

Re: C++ PATCH for c++/86240, ICE with ABSU_EXPR

[Jason Merrill]

OK.

On Wed, Jun 20, 2018 at 11:34 AM, Marek Polacek  wrote:
> The recent change introducing ABSU_EXPR neglected to also handle this code
> in cxx_eval_constant_expression so this patch puts it there.  Also two
> other spots for good measure.  It's possible we'll find out that we need
> to fix other spots too.
>
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
>
> 2018-06-20  Marek Polacek  
>
> PR c++/86240
> * constexpr.c (cxx_eval_constant_expression): Handle ABSU_EXPR.
> (fold_simple_1): Likewise.
> * error.c (dump_expr): Likewise.
>
> * g++.dg/pr86240.C: New test.
>
> diff --git gcc/cp/constexpr.c gcc/cp/constexpr.c
> index 216eecd4b06..44f3093ab47 100644
> --- gcc/cp/constexpr.c
> +++ gcc/cp/constexpr.c
> @@ -4412,6 +4412,7 @@ cxx_eval_constant_expression (const constexpr_ctx *ctx, 
> tree t,
>  case FLOAT_EXPR:
>  case NEGATE_EXPR:
>  case ABS_EXPR:
> +case ABSU_EXPR:
>  case BIT_NOT_EXPR:
>  case TRUTH_NOT_EXPR:
>  case FIXED_CONVERT_EXPR:
> @@ -5056,6 +5057,7 @@ fold_simple_1 (tree t)
>return fold_sizeof_expr (t);
>
>  case ABS_EXPR:
> +case ABSU_EXPR:
>  case CONJ_EXPR:
>  case REALPART_EXPR:
>  case IMAGPART_EXPR:
> diff --git gcc/cp/error.c gcc/cp/error.c
> index 6a261132afb..b0d8e322e65 100644
> --- gcc/cp/error.c
> +++ gcc/cp/error.c
> @@ -2764,6 +2764,7 @@ dump_expr (cxx_pretty_printer *pp, tree t, int flags)
>  case VEC_DELETE_EXPR:
>  case MODOP_EXPR:
>  case ABS_EXPR:
> +case ABSU_EXPR:
>  case CONJ_EXPR:
>  case VECTOR_CST:
>  case FIXED_CST:
> diff --git gcc/testsuite/g++.dg/pr86240.C gcc/testsuite/g++.dg/pr86240.C
> index e69de29bb2d..16ae89cccd1 100644
> --- gcc/testsuite/g++.dg/pr86240.C
> +++ gcc/testsuite/g++.dg/pr86240.C
> @@ -0,0 +1,12 @@
> +// { dg-do compile }
> +
> +extern "C" int abs (int);
> +struct a {
> +  short b;
> +} e;
> +short c;
> +bool
> +foo ()
> +{
> +  return abs(c) >= e.b;
> +}

C++ PATCH for c++/86240, ICE with ABSU_EXPR

[Marek Polacek]

The recent change introducing ABSU_EXPR neglected to also handle this code
in cxx_eval_constant_expression so this patch puts it there.  Also two
other spots for good measure.  It's possible we'll find out that we need
to fix other spots too.

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

2018-06-20  Marek Polacek  

PR c++/86240
* constexpr.c (cxx_eval_constant_expression): Handle ABSU_EXPR.
(fold_simple_1): Likewise.
* error.c (dump_expr): Likewise.

* g++.dg/pr86240.C: New test.

diff --git gcc/cp/constexpr.c gcc/cp/constexpr.c
index 216eecd4b06..44f3093ab47 100644
--- gcc/cp/constexpr.c
+++ gcc/cp/constexpr.c
@@ -4412,6 +4412,7 @@ cxx_eval_constant_expression (const constexpr_ctx *ctx, 
tree t,
 case FLOAT_EXPR:
 case NEGATE_EXPR:
 case ABS_EXPR:
+case ABSU_EXPR:
 case BIT_NOT_EXPR:
 case TRUTH_NOT_EXPR:
 case FIXED_CONVERT_EXPR:
@@ -5056,6 +5057,7 @@ fold_simple_1 (tree t)
   return fold_sizeof_expr (t);
 
 case ABS_EXPR:
+case ABSU_EXPR:
 case CONJ_EXPR:
 case REALPART_EXPR:
 case IMAGPART_EXPR:
diff --git gcc/cp/error.c gcc/cp/error.c
index 6a261132afb..b0d8e322e65 100644
--- gcc/cp/error.c
+++ gcc/cp/error.c
@@ -2764,6 +2764,7 @@ dump_expr (cxx_pretty_printer *pp, tree t, int flags)
 case VEC_DELETE_EXPR:
 case MODOP_EXPR:
 case ABS_EXPR:
+case ABSU_EXPR:
 case CONJ_EXPR:
 case VECTOR_CST:
 case FIXED_CST:
diff --git gcc/testsuite/g++.dg/pr86240.C gcc/testsuite/g++.dg/pr86240.C
index e69de29bb2d..16ae89cccd1 100644
--- gcc/testsuite/g++.dg/pr86240.C
+++ gcc/testsuite/g++.dg/pr86240.C
@@ -0,0 +1,12 @@
+// { dg-do compile }
+
+extern "C" int abs (int);
+struct a {
+  short b;
+} e;
+short c;
+bool
+foo ()
+{
+  return abs(c) >= e.b;
+}

Re: [C++ PATCH] Fix delayed folding -Wnonnull regression (PR c++/86210)

[Jason Merrill]

On Wed, Jun 20, 2018 at 10:32 AM, Jakub Jelinek  wrote:
> Hi!
>
> This patch fixes a regression caused by C++ delayed folding, when
> check_nonnull_arg is called, the arguments aren't folded yet and so unlike
> GCC 4.8 and earlier we don't report -Wnonnull warning unless the argument is
> literal NULL without any folding.
>
> Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
> trunk?  Is this something we should backport (at least to 8.2) or not?

OK for trunk and 8.2.

> 2018-06-20  Jakub Jelinek  
>
> PR c++/86210
> * c-common.c (check_nonnull_arg): Use fold_for_warn.  Adjust obsolete
> comment.
>
> * g++.dg/warn/Wnonnull4.C: New test.
>
> --- gcc/c-family/c-common.c.jj  2018-06-20 08:15:20.697849713 +0200
> +++ gcc/c-family/c-common.c 2018-06-20 12:14:27.828098317 +0200
> @@ -5404,10 +5404,8 @@ check_nonnull_arg (void *ctx, tree param
>if (TREE_CODE (TREE_TYPE (param)) != POINTER_TYPE)
>  return;
>
> -  /* When not optimizing diagnose the simple cases of null arguments.
> - When optimization is enabled defer the checking until expansion
> - when more cases can be detected.  */
> -  if (integer_zerop (param))
> +  /* Diagnose the simple cases of null arguments.  */
> +  if (integer_zerop (fold_for_warn (param)))
>  {
>warning_at (pctx->loc, OPT_Wnonnull, "null argument where non-null "
>   "required (argument %lu)", (unsigned long) param_num);
> --- gcc/testsuite/g++.dg/warn/Wnonnull4.C.jj2018-06-20 12:21:50.424552232 
> +0200
> +++ gcc/testsuite/g++.dg/warn/Wnonnull4.C   2018-06-20 12:20:47.356487553 
> +0200
> @@ -0,0 +1,21 @@
> +// PR c++/86210
> +// { dg-do compile }
> +// { dg-options "-Wnonnull" }
> +
> +void *declared_not_defined (void *p) __attribute__((nonnull));
> +
> +inline void *declared_and_defined (void *p) __attribute__((nonnull));
> +
> +int
> +main ()
> +{
> +  int *const p = 0;
> +  declared_not_defined (p);// { dg-warning "null argument where non-null 
> required" }
> +  declared_and_defined (p);// { dg-warning "null argument where non-null 
> required" }
> +}
> +
> +void *
> +declared_and_defined (void *p)
> +{
> +  return p;
> +}
>
> Jakub

[Bug tree-optimization/86244] misleading use of "may be too large" in -Walloca-larger-than and -Wvla-larger-than warnings involving ranges

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
   Severity|normal  |minor

[Bug tree-optimization/86244] New: misleading use of "may be too large" in -Walloca-larger-than and -Wvla-larger-than warnings involving ranges

[msebor at gcc dot gnu.org]

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

Bug ID: 86244
   Summary: misleading use of "may be too large" in
-Walloca-larger-than and -Wvla-larger-than warnings
involving ranges
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

While testing some changes to -Walloca-larger-than and -Wvla-larger-than I
noticed that the messages issued by the warnings are somewhat misleading in
cases when the alloca/VLA argument is in a range whose lower bound exceeds the
specified threshold.  The message uses the phrase "may be too large" even
though the argument definitely is too large.

For comparison, the test case below shows the different format and wording of
the three diagnostics.  It would be nice to make them all consistent (maybe
even by using the same function to issue them).

$ cat d.c && gcc -S -O2 -Wall -Walloc-size-larger-than=1 -Walloca-larger-than=1
-Wvla-larger-than=1 d.c
void f (void*);

void g (unsigned n)
{
  if (n < 5 || 7 < n)
n = 5;

  void *p = __builtin_malloc (n);   // warning: n exceeds object size (good)
  f (p);
}

void h (unsigned n)
{
  n = 5;

  void *p = __builtin_alloca (n);   // warning: n is too large (good)
  f (p);
}


void i (unsigned n)
{
  if (n < 5 || 7 < n)
n = 5;

  char a[n];   // warning: n may be too large even though it definitely is
  f (a);
}
d.c: In function ‘g’:
d.c:8:13: warning: argument 1 range [5, 7] exceeds maximum object size 1
[-Walloc-size-larger-than=]
   void *p = __builtin_malloc (n);   // warning: n exceeds object size (good)
 ^~~~
d.c:8:13: note: in a call to built-in allocation function ‘__builtin_malloc’
d.c: In function ‘h’:
d.c:16:13: warning: argument to ‘alloca’ is too large [-Walloca-larger-than=]
   void *p = __builtin_alloca (n);   // warning: n is too large (good)
 ^~~~
d.c:16:13: note: limit is 1 bytes, but argument is 5
d.c: In function ‘i’:
d.c:26:8: warning: argument to variable-length array may be too large
[-Wvla-larger-than=]
   char a[n];   // warning: n may be too large even though it definitely is
^
d.c:26:8: note: limit is 1 bytes, but argument may be as large as 7

Re: [PATCH 3/3] Come up with new --completion option.

[David Malcolm]

On Mon, 2018-05-14 at 14:51 +0200, Martin Liška wrote:
> Main part where I still need to write ChangeLog file and
> gcc.sh needs to be moved to bash-completions project.
> 
> Martin

As before, I'm not an official reviewer for it, but it touches code
that I wrote, so here goes.

Overall looks good to me, but I have some nitpicks:

(needs a ChangeLog)

[...snip gcc.sh change; I don't feel qualified to comment...]

[...snip sane-looking changes to common.opt and gcc.c.  */
 
diff --git a/gcc/opt-suggestions.c b/gcc/opt-suggestions.c
index e322fcd91c5..2da094a5960 100644
--- a/gcc/opt-suggestions.c
+++ b/gcc/opt-suggestions.c
@@ -28,18 +28,6 @@ along with GCC; see the file COPYING3.  If not see
 #include "opt-suggestions.h"
 #include "selftest.h"
 
-option_proposer::~option_proposer ()
-{
-  if (m_option_suggestions)
-{
-  int i;
-  char *str;
-  FOR_EACH_VEC_ELT (*m_option_suggestions, i, str)
-   free (str);
-  delete m_option_suggestions;
-}
-}

Why is this dtor going away?  If I'm reading the patch correctly,
option_proposer still "owns" m_option_suggestions.

What happens if you run "make selftest-valgrind" ?  (my guess is some
new memory leaks)
 
+void
+option_proposer::get_completions (const char *option_prefix,
+ auto_string_vec )

Missing leading comment.  Maybe something like:

/* Populate RESULTS with valid completions of options that begin
   with OPTION_PREFIX.  */

or somesuch.

+{
+  /* Bail out for an invalid input.  */
+  if (option_prefix == NULL || option_prefix[0] == '\0')
+return;
+
+  /* Option suggestions are built without first leading dash character.  */
+  if (option_prefix[0] == '-')
+option_prefix++;
+
+  size_t length = strlen (option_prefix);
+
+  /* Handle parameters.  */
+  const char *prefix = "-param";
+  if (length >= strlen (prefix)
+  && strstr (option_prefix, prefix) == option_prefix)

Maybe reword that leading comment to

   /* Handle OPTION_PREFIX starting with "-param".  */

(or somesuch) to clarify the intent?

[...snip...]

+void
+option_proposer::suggest_completion (const char *option_prefix)
+{

Missing leading comment.  Maybe something like:

/* Print on stdout a list of valid options that begin with OPTION_PREFIX,
   one per line, suitable for use by Bash completion.

   Implementation of the "-completion=" option.  */

or somesuch.

[...snip...]

+void
+option_proposer::find_param_completions (const char separator,
+const char *option_prefix,
+auto_string_vec )

Maybe rename "option_prefix" to "param_prefix"?  I believe it's now
the prefix of the param name, rather than the option.

Missing leading comment.  Maybe something like:

/* Populate RESULTS with bash-completions options for all parameters
   that begin with PARAM_PREFIX, using SEPARATOR.

   For example, if PARAM_PREFIX is "max-" and SEPARATOR is "=" then
   strings of the form:
 "--param=max-unrolled-insns"
 "--param=max-early-inliner-iterations"
   will be added to RESULTS.  */

(did I get that right?)

+{
+  char separator_str[] {separator, '\0'};

Is the above initialization valid C++98, or is it a C++11-ism?

+  size_t length = strlen (option_prefix);
+  for (unsigned i = 0; i < get_num_compiler_params (); ++i)
+{
+  const char *candidate = compiler_params[i].option;
+  if (strlen (candidate) >= length
+ && strstr (candidate, option_prefix) == candidate)
+   results.safe_push (concat ("--param", separator_str, candidate, NULL));
+}
+}
+
+#if CHECKING_P
+
+namespace selftest {
+
+/* Verify that PROPOSER generates sane auto-completion suggestions
+   for OPTION_PREFIX.  */
+static void
+verify_autocompletions (option_proposer , const char *option_prefix)
+{
+  auto_string_vec suggestions;
+  proposer.get_completions (option_prefix, suggestions);


Maybe a comment here to specify:

   /* There must be at least one suggestion, and every suggestion must
  indeed begin with OPTION_PREFIX.  */

+  ASSERT_GT (suggestions.length (), 0);
+
+  for (unsigned i = 0; i < suggestions.length (); i++)
+ASSERT_STR_STARTSWITH (suggestions[i], option_prefix);
+}

[...snip...]

diff --git a/gcc/opt-suggestions.h b/gcc/opt-suggestions.h
index 5e3ee9e2671..d0c32af7e5c 100644
--- a/gcc/opt-suggestions.h
+++ b/gcc/opt-suggestions.h
@@ -33,9 +33,6 @@ public:
   option_proposer (): m_option_suggestions (NULL)
   {}
 
-  /* Default destructor.  */
-  ~option_proposer ();

Again, why does this dtor go away?

 
+  /* Find parameter completions for --param format with SEPARATOR.
+ Again, save the completions into results.  */
+  void find_param_completions (const char separator, const char *option_prefix,
+  auto_string_vec );

If we're renaming "option_prefix" to "param_prefix", please do so here as well.

 private:
   /* Cache with all suggestions.  */
   auto_vec  *m_option_suggestions;

[...snip...]

[Bug tree-optimization/85859] [6/7/8/9 Regression] wrong code with -fno-isolate-erroneous-paths-dereference

[vries at gcc dot gnu.org]

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

--- Comment #3 from Tom de Vries  ---
Created attachment 44305
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44305=edit
Tentative patch

Re: [PATCH 2/4] Switch other switch expansion methods into classes.

[Jeff Law]

On 06/20/2018 09:20 AM, Jakub Jelinek wrote:
> On Wed, Jun 20, 2018 at 09:15:08AM -0600, Jeff Law wrote:
>>> Thank you for the trust. I tried to split it into multiple patches, but
>>> it wasn't readable enough.
>> Yea, it can be painful to find the right way to structure a series.  In
>> fact, I'm going to be faced with that shortly for a target change my son
>> and I have in the works (converting v850 away from cc0).  In the end it
>> looks like 75% of the file changed, but a lot of it is just unidiff
>> presenting the changes in a particularly  bad way.
> 
> Have you tried diff -upd?  -d helps a lot in some cases to make diffs more
> readable.
It's one of the things I'll look at.  It may also be the case that I can
stage them in such a way as to keep the diffs reasonable.  It may mean a
couple revs in the repo where we don't optimize well, but given the
target I doubt that's a big deal.  This was mostly an exercise to keep
my son's mind occupied :-)

Jeff

[Bug c++/86243] unknown attributes causing hard error

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to Hannes Hauswedell from comment #0)
> Note that I am not even setting -Wall or -Wextra.

As documented, -Wattributes is enabled by default and you need to use
-Wno-attributes to disable it.

Re: [PATCH 2/4] Switch other switch expansion methods into classes.

[Jakub Jelinek]

On Wed, Jun 20, 2018 at 09:15:08AM -0600, Jeff Law wrote:
> > Thank you for the trust. I tried to split it into multiple patches, but
> > it wasn't readable enough.
> Yea, it can be painful to find the right way to structure a series.  In
> fact, I'm going to be faced with that shortly for a target change my son
> and I have in the works (converting v850 away from cc0).  In the end it
> looks like 75% of the file changed, but a lot of it is just unidiff
> presenting the changes in a particularly  bad way.

Have you tried diff -upd?  -d helps a lot in some cases to make diffs more
readable.

Jakub

Re: [PATCH 2/4] Switch other switch expansion methods into classes.

[Jeff Law]

On 06/20/2018 05:25 AM, Steven Bosscher wrote:
> On Tue, Jun 12, 2018 at 10:44 PM, Jeff Law wrote:
>> On 06/05/2018 01:15 AM, marxin wrote:
>>>
>>> + The definition of "much bigger" depends on whether we are
>>> + optimizing for size or for speed.  If the former, the maximum
>>> + ratio range/count = 3, because this was found to be the optimal
>>> + ratio for size on i686-pc-linux-gnu, see PR11823.  The ratio
>>> + 10 is much older, and was probably selected after an extensive
>>> + benchmarking investigation on numerous platforms.  Or maybe it
>>> + just made sense to someone at some point in the history of GCC,
>>> + who knows...  */
>> "much older" is an understatement.  I believe the magic "10" pre-dates
>> my involvement in GCC.  You can find evidence of it as far back as
>> gcc-0.9.  I doubt it was extensively benchmarked, and even if it was,
>> the targets on which it was benchmarked don't reflect modern target
>> reality in terms of importance.
> 
> When I added this comment
> (https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/stmt.c?r1=189284=189285;)
> it as an attempt at humor. I should have turned the number into a
> PARAM at the time. Maybe that's something Martin could still do now?
A PARAM feels like overkill, but I certainly wouldn't object.I'd be
happy with that, a const member in the class or even the adjusted
constant.

jeff