[Bug other/86198] Libbacktrace does not properly work with ".note.gnu.build-id" section
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
[Bug debug/86258] New: Program compiled with fPIC crashes while stepping over thread-local variable GDB
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
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
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
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?
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
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
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?
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
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
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?
[Bug c++/86238] No diagnostic for virtual base class with inaccessible destructor
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
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
[Bug c++/48665] type of const member function
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.
[Bug libgcc/86213] -fsplit-stack runtime may clobber SSE input param reg
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.
[Bug c++/48665] type of const member function
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.
[Bug libgcc/86213] -fsplit-stack runtime may clobber SSE input param reg
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
[Bug c++/71765] incorrectly accepts invalid C++ code that invokes base class dtor
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
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
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.
[Bug tree-optimization/85859] [6/7/8/9 Regression] wrong code with -fno-isolate-erroneous-paths-dereference
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
[Bug libgcc/86213] -fsplit-stack runtime may clobber SSE input param reg
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
[Bug fortran/86248] LEN_TRIM in specification expression causes link failure
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
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
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
[Bug c++/86184] Conditional expression with omitted operand cannot use rvalue of type convertible to bool
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
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
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
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
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, );
}
[Bug libstdc++/70966] new_delete_resource() has deinit lifetime issues.
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.
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
[Bug c++/85634] [8/9 Regression] ICE in tsubst_copy, at cp/pt.c:15483
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
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
[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations
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
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+.
[Bug c++/86226] A bug seems to be not fully fixed
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
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
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 ***
[Bug c++/53109] e.E::~E() should compile without error in c++ 2011
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.
[Bug c++/85634] [8/9 Regression] ICE in tsubst_copy, at cp/pt.c:15483
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 ...
[Bug c++/85634] [8/9 Regression] ICE in tsubst_copy, at cp/pt.c:15483
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
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
[Bug c++/86225] Missing error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86225 --- Comment #1 from Jonathan Wakely --- This is a dup of an existing bug.
[Bug c++/86210] [6/7/8/9 Regression] Missing -Wnonnull warning for function defined in the same TU
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
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
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
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
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!
[Bug c++/86210] [6/7/8/9 Regression] Missing -Wnonnull warning for function defined in the same TU
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
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
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
[Bug tree-optimization/86244] misleading use of "may be too large" in -Walloca-larger-than and -Wvla-larger-than warnings involving ranges
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
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
[Bug tree-optimization/85859] [6/7/8/9 Regression] wrong code with -fno-isolate-erroneous-paths-dereference
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
[Bug c++/86243] unknown attributes causing hard error
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.
[Bug c++/86243] New: unknown attributes causing hard error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86243
Bug ID: 86243
Summary: unknown attributes causing hard error
Product: gcc
Version: 7.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: h2+bugs at fsfe dot org
Target Milestone: ---
The following code (based on
http://open-std.org/JTC1/SC22/WG21/docs/papers/2017/p0479r1.html)
int main()
{
if (1 == 2) [[unlikely]]
throw int{};
return 2;
}
produces an error:
% g++7 -std=c++17 test.cpp
test.cpp: In function 'int main()':
test.cpp:3:18: error: expected identifier before '[' token
if (1 == 2) [[unlikely]]
^
test.cpp: In lambda function:
test.cpp:4:9: error: expected '{' before 'throw'
throw int{};
^
test.cpp: In function 'int main()':
test.cpp:4:9: error: expected ';' before 'throw'
This strongly looks like a bug. If one encloses the if-block in braces, I
instead get a warning:
int main()
{
if (1 == 2) [[unlikely]]
{
throw int{};
}
return 2;
}
results in:
% g++7 -std=c++17 test.cpp
test.cpp: In function 'int main()':
test.cpp:3:17: warning: attributes at the beginning of statement are ignored
[-Wattributes]
if (1 == 2) [[unlikely]]
^
Note that I am not even setting -Wall or -Wextra. Even then I would think that
unknown attributes should just be silently ignored as suggested by the
standard, or not?
Thanks for your help!
Tested versions:
g++7 (FreeBSD Ports Collection) 7.3.1 20180531
g++8 (FreeBSD Ports Collection) 8.1.1 20180608
g++9 (FreeBSD Ports Collection) 9.0.0 20180603 (experimental)
[Bug tree-optimization/86097] [8 Regression] ICE: verify_gimple failed (error: mismatching comparison operand types)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86097 --- Comment #10 from Jakub Jelinek --- Sure, that is why this is an 8/9 regression. Checking needs to be enabled to reproduce on the 8.x branch.
[Bug tree-optimization/86097] [8 Regression] ICE: verify_gimple failed (error: mismatching comparison operand types)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86097 Arseny Solokha changed: What|Removed |Added Summary|[8/9 Regression] ICE: |[8 Regression] ICE: |verify_gimple failed|verify_gimple failed |(error: mismatching |(error: mismatching |comparison operand types) |comparison operand types) --- Comment #9 from Arseny Solokha --- I believe it's fixed on trunk now.
[Bug tree-optimization/86097] [8/9 Regression] ICE: verify_gimple failed (error: mismatching comparison operand types)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86097 --- Comment #8 from Tom de Vries --- (In reply to Jakub Jelinek from comment #1) > This first started to ICE in r254867, with: That commit is part of gcc-8-branch, and was committed to trunk before the gcc-8-branch branch point, so that probably means this ICE reproduces as well for the 8 branch.
[Bug debug/86194] [8/9 Regression] ICE: SIGSEGV in avoid_constant_pool_reference (simplify-rtx.c:215) with -O -g -mavx512bw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86194 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Wed Jun 20 14:57:55 2018 New Revision: 261808 URL: https://gcc.gnu.org/viewcvs?rev=261808=gcc=rev Log: PR debug/86194 * var-tracking.c (use_narrower_mode_test): Check if shift amount can be narrowed. * gcc.target/i386/pr86194.c: New test. Added: branches/gcc-8-branch/gcc/testsuite/gcc.target/i386/pr86194.c Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/gcc/var-tracking.c
[Bug tree-optimization/86231] [6/7 Regression] vrp_meet causes wrong-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86231 Jakub Jelinek changed: What|Removed |Added Target Milestone|8.2 |6.5 Summary|[8/9 Regression] vrp_meet |[6/7 Regression] vrp_meet |causes wrong-code |causes wrong-code --- Comment #4 from Jakub Jelinek --- Fixed for 8.2+. The bug exists in 6.x and 7.x too, so keeping open for backporting consideration.
[Bug debug/86194] [8/9 Regression] ICE: SIGSEGV in avoid_constant_pool_reference (simplify-rtx.c:215) with -O -g -mavx512bw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86194 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Wed Jun 20 14:51:04 2018 New Revision: 261807 URL: https://gcc.gnu.org/viewcvs?rev=261807=gcc=rev Log: PR debug/86194 * var-tracking.c (use_narrower_mode_test): Check if shift amount can be narrowed. * gcc.target/i386/pr86194.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr86194.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/var-tracking.c
[Bug tree-optimization/86231] [8/9 Regression] vrp_meet causes wrong-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86231 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Wed Jun 20 14:50:09 2018 New Revision: 261806 URL: https://gcc.gnu.org/viewcvs?rev=261806=gcc=rev Log: PR tree-optimization/86231 * tree-vrp.c (union_ranges): For ( [ ) ] or ( )[ ] range and anti-range don't overwrite *vr0min before using it to compute *vr0max. * gcc.dg/tree-ssa/vrp119.c: New test. * gcc.c-torture/execute/pr86231.c: New test. Added: branches/gcc-8-branch/gcc/testsuite/gcc.c-torture/execute/pr86231.c branches/gcc-8-branch/gcc/testsuite/gcc.dg/tree-ssa/vrp119.c Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/gcc/tree-vrp.c
[Bug tree-optimization/86231] [8/9 Regression] vrp_meet causes wrong-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86231 --- Comment #2 from Jakub Jelinek --- Author: jakub Date: Wed Jun 20 14:47:28 2018 New Revision: 261805 URL: https://gcc.gnu.org/viewcvs?rev=261805=gcc=rev Log: PR tree-optimization/86231 * tree-vrp.c (union_ranges): For ( [ ) ] or ( )[ ] range and anti-range don't overwrite *vr0min before using it to compute *vr0max. * gcc.dg/tree-ssa/vrp119.c: New test. * gcc.c-torture/execute/pr86231.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr86231.c trunk/gcc/testsuite/gcc.dg/tree-ssa/vrp119.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c
[Bug tree-optimization/86097] [8/9 Regression] ICE: verify_gimple failed (error: mismatching comparison operand types)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86097 --- Comment #7 from Tom de Vries --- Author: vries Date: Wed Jun 20 14:44:45 2018 New Revision: 261804 URL: https://gcc.gnu.org/viewcvs?rev=261804=gcc=rev Log: Generate correctly typed compare in canonicalize_loop_ivs 2018-06-20 Tom de Vries PR tree-optimization/86097 * tree-ssa-loop-manip.c (canonicalize_loop_ivs): Also convert *nit to iv type if signedness of iv type is not the same as that of *nit. * gcc.dg/autopar/pr86097.c: New test. Added: trunk/gcc/testsuite/gcc.dg/autopar/pr86097.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-loop-manip.c
[Bug tree-optimization/86097] [8/9 Regression] ICE: verify_gimple failed (error: mismatching comparison operand types)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86097 Tom de Vries changed: What|Removed |Added Keywords||patch --- Comment #6 from Tom de Vries --- https://gcc.gnu.org/ml/gcc-patches/2018-06/msg01240.html
[Bug c++/86184] Conditional expression with omitted operand cannot use rvalue of type convertible to bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86184
Jonathan Wakely changed:
What|Removed |Added
Keywords||rejects-valid
Status|WAITING |NEW
Summary|Shall gcc support this |Conditional expression with
|feature?|omitted operand cannot use
||rvalue of type convertible
||to bool
--- Comment #3 from Jonathan Wakely ---
Reduced:
struct X {
operator bool() { return true; }
};
X x;
X y = X() ? X() : x;
X z = X() ? : y;
tern.cc:7:15: error: lvalue required as unary ‘&’ operand
X z = X() ? : y;
^
tern.cc:7:7: error: could not convert ‘X()’ from ‘X’ to ‘bool’
X z = X() ? : y;
^~~
The manual says the conditional expression with the omitted operand should
"perfectly equivalent" to the first one.
[Bug c++/85634] [8/9 Regression] ICE in tsubst_copy, at cp/pt.c:15483
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85634 --- Comment #7 from Nathan Sidwell --- Fixed trunk r261802
[Bug c++/85634] [8/9 Regression] ICE in tsubst_copy, at cp/pt.c:15483
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85634 --- Comment #8 from Nathan Sidwell --- Author: nathan Date: Wed Jun 20 14:34:06 2018 New Revision: 261802 URL: https://gcc.gnu.org/viewcvs?rev=261802=gcc=rev Log: [PR c++/85634] Fix tsubst ICE https://gcc.gnu.org/ml/gcc-patches/2018-06/msg01237.html PR c++/85634 * cp-tree.h (lookup_keep): Drop KEEP parm. (lookup_list_keep): Delete. (maybe_get_fns): Declare. * parser.c (cp_parser_primary_expression): Call lookup_keep here. (cp_parser_template_id): Not here ... * decl.c (cp_finish_decl): ... nor here ... * init.c (build_raw_new_expr): ... nor here ... * pt.c (process_template_parm): ... nor here ... * semantics.c (perform_koenig_lookup): Call lookup_keep. (finish_call_expr): Not here. * tree.c (ovl_cache): Delete. (ovl_make, ovl_copy): No cache. (lookup_keep): Always keep. (lookup_list_keep): Delete. (maybe_get_fns): New, broken out of ... (get_fns): ... here. Call it. (built_min_nt_loc, build_min, build_min_non_dep): Drop lookup_keep. (build_min_nt_call_vec): Likewise. PR c++/85634 * g++.dg/lookup/pr85634.C: New. Added: trunk/gcc/testsuite/g++.dg/lookup/pr85634.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/decl.c trunk/gcc/cp/init.c trunk/gcc/cp/parser.c trunk/gcc/cp/pt.c trunk/gcc/cp/semantics.c trunk/gcc/cp/tree.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/86242] New: [F03] ICE for derived type with allocatable class component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86242 Bug ID: 86242 Summary: [F03] ICE for derived type with allocatable class component Product: gcc Version: 8.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: c...@mnet-mail.de Target Milestone: --- The following Fortran 2003 code (which compiles with flang 6.0, pgfortran 17.10, and ifort 19.0.0.070 Beta) generates an internal compiler error (ICE) with gfortran 8.0.1: $ cat test.F90 module test implicit none private public :: tester type :: wrapper integer(4) :: n end type wrapper type :: output real(8) :: dummy end type output type :: tester class(wrapper), allocatable :: wrap procedure(proc1), pointer :: ptr => null() end type tester abstract interface function proc1(self) result(uc) import :: tester, output class(tester), intent(in) :: self class(output), allocatable :: uc end function proc1 end interface end module test $ gfortran-8 -c test.F90 test.F90:29:0: end module test internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. Gfortran version output is: $ gfortran-8 -v Using built-in specs. COLLECT_GCC=gfortran-8 COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 8-20180424-0ubuntu1~16.04.1' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --with-as=/usr/bin/x86_64-linux-gnu-as --with-ld=/usr/bin/x86_64-linux-gnu-ld --program-suffix=-8 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 8.0.1 20180424 (experimental) [trunk revision 259590] (Ubuntu 8-20180424-0ubuntu1~16.04.1)
[Bug tree-optimization/86203] duplicate non-constant call to strlen() not folded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86203 Martin Sebor changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=86241 --- Comment #6 from Martin Sebor --- snprintf (0, 0, "%s", s) returns the length of s without storing any characters. I opened bug 86241 to implement that optimization.
[Bug tree-optimization/86241] New: duplicate strlen-like snprintf calls not folded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86241
Bug ID: 86241
Summary: duplicate strlen-like snprintf calls not folded
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 calls to snprintf in the function below compute the length of the string s
without storing any output. As mentioned in bug 86203 comment #4, the result
of the function with the same arguments (and a null destination) is constant so
the duplicate snprintf call could be replaced by the result of the first,
analogously to how the strlen optimization pass folds the corresponding call to
strlen().
$ cat c.c && gcc -S -O2 -Wall -Wextra -fdump-tree-optimized=/dev/stdout c.c
int f (char *s)
{
int n = __builtin_strlen (s);
int m = __builtin_strlen (s); // folded into m = n;
return m + n;
}
int g (char *s)
{
int n = __builtin_snprintf (0, 0, "%s", s);
int m = __builtin_snprintf (0, 0, "%s", s); // could be folded into m = n
return m + n;
}
;; Function f (f, funcdef_no=0, decl_uid=1956, cgraph_uid=0, symbol_order=0)
f (char * s)
{
int n;
long unsigned int _1;
int _5;
[local count: 1073741825]:
_1 = __builtin_strlen (s_3(D));
n_4 = (int) _1;
_5 = n_4 * 2;
return _5;
}
;; Function g (g, funcdef_no=1, decl_uid=1961, cgraph_uid=1, symbol_order=1)
g (char * s)
{
int m;
int n;
int _7;
[local count: 1073741825]:
n_4 = __builtin_snprintf (0B, 0, "%s", s_2(D));
m_6 = __builtin_snprintf (0B, 0, "%s", s_2(D));
_7 = n_4 + m_6;
return _7;
}
[Bug c++/86240] [9 Regression] ice: unexpected expression absu_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86240 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org
[Bug c++/86238] No diagnostic for virtual base class with inaccessible destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86238
Jonathan Wakely changed:
What|Removed |Added
Keywords||accepts-invalid
Summary|a vtable layout bug |No diagnostic for virtual
||base class with
||inaccessible destructor
--- Comment #2 from Jonathan Wakely ---
Please try to provide meaningful bug titles, and reduce the code to remove
everything that isn't relevant.
This bug reduces from a 72kB testcase to simply:
struct s2 { ~s2() {} };
class s3 : virtual protected s2 { };
class s4 : private s3 { };
class s11 : s4 { } a11;
C++ and EDG accept this, but Clang prints:
test.cc:4:7: error: inherited virtual base class 's2' has private destructor
class s11 : s4 { } a11;
^
test.cc:4:20: note: in implicit default constructor for 's11' first required
here
class s11 : s4 { } a11;
^
test.cc:3:12: note: constrained by private inheritance here
class s4 : private s3 { };
^~
test.cc:4:7: error: inherited virtual base class 's2' has private destructor
class s11 : s4 { } a11;
^
test.cc:4:20: note: in implicit destructor for 's11' first required here
class s11 : s4 { } a11;
^
test.cc:3:12: note: constrained by private inheritance here
class s4 : private s3 { };
^~
2 errors generated.
[Bug c++/86240] [9 Regression] ice: unexpected expression absu_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86240 Marek Polacek changed: What|Removed |Added Target Milestone|--- |9.0 Summary|ice: unexpected expression |[9 Regression] ice: |absu_expr |unexpected expression ||absu_expr --- Comment #3 from Marek Polacek --- Started with r261681.
[Bug c++/86238] a vtable layout bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86238 --- Comment #1 from Jonathan Wakely --- Clang's errors have absolutely nothing to do with a vtable bug (that was a completely different bug that was demonstrated by the same code).
[Bug c++/86240] ice: unexpected expression absu_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86240 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-06-20 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Marek Polacek --- Confirmed. I'll take a look.
[Bug c++/86233] explicit specialization of function template accepted with weaker exception specification
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86233
Jonathan Wakely changed:
What|Removed |Added
Summary|A tricky code sample|explicit specialization of
||function template accepted
||with weaker exception
||specification
--- Comment #3 from Jonathan Wakely ---
Reduced further:
template void f() noexcept { }
template<> void f() { }
[Bug c++/86240] ice: unexpected expression absu_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86240 David Binderman changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #1 from David Binderman --- From svn blame, it looks like Jason may be able to help.
[Bug c++/86233] A tricky code sample
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86233
Jonathan Wakely changed:
What|Removed |Added
Keywords||accepts-invalid
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-06-20
Ever confirmed|0 |1
--- Comment #2 from Jonathan Wakely ---
I can't find the relevant standarese but I think the code should be rejected
because the specialization has a weaker exception-specification.
Reduced:
template struct X {
void f() noexcept { }
};
template<> void X::f() { }
EDG says:
"es.cc", line 5: error: allowing all exceptions is incompatible with function
"X::f" (declared at line 2)
template<> void X::f() { }
^
1 error detected in the compilation of "es.cc".
Clang says:
es.cc:5:25: error: 'f' is missing exception specification 'noexcept'
template<> void X::f() { }
^
noexcept
es.cc:2:8: note: previous declaration is here
void f() noexcept { }
^
1 error generated.
[Bug c++/86240] New: ice: unexpected expression absu_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86240
Bug ID: 86240
Summary: ice: unexpected expression absu_expr
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
Somewhere between revisions 261680 and 261730, this C++ code
causes trouble:
extern "C" int abs(int);
class a {
public:
short b;
};
short c;
void d() {
a e;
abs(c) >= e.b;
}
$ ~/gcc/results.261730/bin/gcc -c -w bug447.cc
bug447.cc: In function ‘void d()’:
bug447.cc:9:15: internal compiler error: unexpected expression ‘#‘absu_expr’
not supported by dump_expr#’ of kind absu_expr
abs(c) >= e.b;
^
0x822d5d cxx_eval_constant_expression
../../trunk/gcc/cp/constexpr.c:4815
0x820019 cxx_eval_constant_expression
../../trunk/gcc/cp/constexpr.c:4612
0x820019 cxx_eval_constant_expression
../../trunk/gcc/cp/constexpr.c:4612
[Bug c++/86218] [9 Regression] ICE in compare_ics, at cp/call.c:9769
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86218 --- Comment #3 from Marek Polacek --- Which I guess is Bug 78244.
[Bug c++/65969] typename allowed in using declaration of non-types names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65969 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-06-20 Ever confirmed|0 |1
[Bug c++/86230] missing exception specification
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86230 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Jonathan Wakely --- Looks like a dup of your own bug. *** This bug has been marked as a duplicate of bug 86233 ***
[Bug middle-end/83623] [8 Regression] ICE: in convert_move, at expr.c:248 with -march=knl and 16bit vector bswap/rotate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83623 Richard Biener changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED Target Milestone|8.0 |6.5 Known to fail||6.4.0 --- Comment #10 from Richard Biener --- Fixed.
[Bug c++/86233] A tricky code sample
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86233 --- Comment #1 from Jonathan Wakely --- *** Bug 86230 has been marked as a duplicate of this bug. ***
[Bug c++/65969] typename allowed in using declaration of non-types names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65969 Jonathan Wakely changed: What|Removed |Added CC||zhonghao at pku dot org.cn --- Comment #1 from Jonathan Wakely --- *** Bug 86235 has been marked as a duplicate of this bug. ***
[Bug c++/86235] g++ accept an erroneous code sample
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86235 Jonathan Wakely changed: What|Removed |Added Keywords||accepts-invalid Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Jonathan Wakely --- dup *** This bug has been marked as a duplicate of bug 65969 ***
[Bug c++/86230] missing exception specification
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86230 --- Comment #1 from Jonathan Wakely --- Isn't this the same as PR 86233 ?
[Bug c++/57891] No diagnostic of narrowing conversion in non-type template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57891 Jonathan Wakely changed: What|Removed |Added CC||zhonghao at pku dot org.cn --- Comment #4 from Jonathan Wakely --- *** Bug 86237 has been marked as a duplicate of this bug. ***
[Bug c++/78244] Narrowing conversion is accepted in a function template, but it should be rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78244 Jonathan Wakely changed: What|Removed |Added Last reconfirmed|2016-11-08 00:00:00 |2018-6-20 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=57891 --- Comment #2 from Jonathan Wakely --- Closely related to PR 57891 but that relates to narrowing of a non-type template argument, whereas this is narrowing during substitution so let's keep it open.
[Bug c++/86237] Narrowing from int to bool is not allowed in a non type template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86237 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Jonathan Wakely --- dup *** This bug has been marked as a duplicate of bug 57891 ***
[Bug c/84873] [6 Regression] ICE: verify_ssa failed (error: definition in block 3 does not dominate use in block 4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84873 --- Comment #13 from Richard Biener --- Author: rguenth Date: Wed Jun 20 13:10:21 2018 New Revision: 261800 URL: https://gcc.gnu.org/viewcvs?rev=261800=gcc=rev Log: 2018-06-20 Richard Biener Backport from mainline 2018-03-16 Richard Biener PR c/84873 * c-gimplify.c (c_gimplify_expr): Revert previous change. Instead unshare the possibly folded expression. 2018-03-15 Richard Biener PR c/84873 * c-gimplify.c (c_gimplify_expr): Do not fold expressions. * c-c++-common/pr84873.c: New testcase. 2018-05-02 Richard Biener PR tree-optimization/85597 * tree-vect-stmts.c (vectorizable_operation): For ternary SLP do not use split vect_get_vec_defs call but call vect_get_slp_defs directly. * gcc.dg/vect/pr85597.c: New testcase. Added: branches/gcc-6-branch/gcc/testsuite/c-c++-common/pr84873.c branches/gcc-6-branch/gcc/testsuite/gcc.dg/vect/pr85597.c Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/c-family/ChangeLog branches/gcc-6-branch/gcc/c-family/c-gimplify.c branches/gcc-6-branch/gcc/testsuite/ChangeLog branches/gcc-6-branch/gcc/tree-vect-stmts.c
[Bug tree-optimization/85597] [6 Regression] internal compiler error: in compute_live_loop_exits, at tree-ssa-loop-manip.c:229
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85597 --- Comment #7 from Richard Biener --- Author: rguenth Date: Wed Jun 20 13:10:21 2018 New Revision: 261800 URL: https://gcc.gnu.org/viewcvs?rev=261800=gcc=rev Log: 2018-06-20 Richard Biener Backport from mainline 2018-03-16 Richard Biener PR c/84873 * c-gimplify.c (c_gimplify_expr): Revert previous change. Instead unshare the possibly folded expression. 2018-03-15 Richard Biener PR c/84873 * c-gimplify.c (c_gimplify_expr): Do not fold expressions. * c-c++-common/pr84873.c: New testcase. 2018-05-02 Richard Biener PR tree-optimization/85597 * tree-vect-stmts.c (vectorizable_operation): For ternary SLP do not use split vect_get_vec_defs call but call vect_get_slp_defs directly. * gcc.dg/vect/pr85597.c: New testcase. Added: branches/gcc-6-branch/gcc/testsuite/c-c++-common/pr84873.c branches/gcc-6-branch/gcc/testsuite/gcc.dg/vect/pr85597.c Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/c-family/ChangeLog branches/gcc-6-branch/gcc/c-family/c-gimplify.c branches/gcc-6-branch/gcc/testsuite/ChangeLog branches/gcc-6-branch/gcc/tree-vect-stmts.c
[Bug tree-optimization/85597] [6 Regression] internal compiler error: in compute_live_loop_exits, at tree-ssa-loop-manip.c:229
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85597 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||6.4.1 Resolution|--- |FIXED Known to fail||6.4.0 --- Comment #8 from Richard Biener --- Fixed.
[Bug c/84873] [6 Regression] ICE: verify_ssa failed (error: definition in block 3 does not dominate use in block 4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84873 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||6.4.1 Resolution|--- |FIXED --- Comment #12 from Richard Biener --- Fixed.
[Bug c++/86228] ordered comparison between pointer and zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86228 Jonathan Wakely changed: What|Removed |Added Keywords||accepts-invalid Status|UNCONFIRMED |NEW Last reconfirmed||2018-06-20 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- The standard says: The usual arithmetic conversions (8.3) are performed on operands of arithmetic or enumeration type. If both operands are pointers, pointer conversions (7.11) and qualification conversions (7.5) are performed to bring them to their composite pointer type (8.2). After conversions, the operands shall have the same type. Although 0 is a null pointer constant, its type is 'int' not a pointer type, so I think Clang is right, and this should be ill-formed.
[Bug c++/86173] Default construction of a union (in std::optional)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86173 --- Comment #4 from Marc Glisse --- Recent related commits: r261758 r261735 (they don't fix the issue).
[Bug c/86239] New: Suggestion: Improve "set but not used variable" warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86239 Bug ID: 86239 Summary: Suggestion: Improve "set but not used variable" warning Product: gcc Version: 8.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: pattakosn at yahoo dot com Target Milestone: --- Created attachment 44304 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44304=edit compiled with gcc -Wall -Wextra -pedantic Hi, I am not sure if I am right on this, but I noticed that having code like this: useless = 0; useless = useless; silences the set but not used variable warning (assume that useless is a local variable and is not used anywhere else). Now, I would agree that the second line is useless and a terrible thing to do, but still, wouldn't it better if the compiler still complained about the set but not used variable (perhaps about the useless command as well, but I do not know if it would be easy to classify identity/"useless" commands. I attach a very small file that I used to test the compiler warnings.
