[Bug c++/86173] New: Default construction of a union (in std::optional)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86173
Bug ID: 86173
Summary: Default construction of a union (in std::optional)
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
Default construction of std::optional always starts with a memset of the
whole optional to 0, while it doesn't with clang using the same libstdc++.
#include
struct AA {
double a[1024];
#ifndef TRIVIAL
AA(); AA(AA const&); AA& operator=(AA const&); ~AA();
#endif
};
typedef std::optional O;
// O fff(){ return {}; }
O fff(){ O o; return o; }
The .original dump has
* = {.D.34926={._M_payload={.D.34026={._M_empty={}}, ._M_engaged=0}}}
which looks good, it says it is initializing the small _M_empty part of the
union, but the gimple dump has
* = {};
which eagerly zeroes everything.
[Bug libstdc++/80335] perf of copying std::optional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80335 Marc Glisse changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Marc Glisse --- Looks like this is fixed. Although the limitations discussed are present: optional> copies the whole array even if it is never engaged.
[Bug c++/86173] Default construction of a union (in std::optional)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86173 --- Comment #1 from Marc Glisse --- Note that constructing optional from std::nullopt does avoid the memset.
[Bug c++/86171] [6/7/8/9 Regression] g++ ICE on valid code: tree check: expected var_decl or function_decl, have type_decl in duplicate_decls, at cp/decl.c:2291
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86171 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Version|unknown |9.0 Keywords||ice-checking Last reconfirmed||2018-06-16 CC||jakub at gcc dot gnu.org Ever confirmed|0 |1 Summary|g++ ICE on valid code: |[6/7/8/9 Regression] g++ |tree check: expected|ICE on valid code: tree |var_decl or function_decl, |check: expected var_decl or |have type_decl in |function_decl, have |duplicate_decls, at |type_decl in |cp/decl.c:2291 |duplicate_decls, at ||cp/decl.c:2291 Target Milestone|--- |6.5 --- Comment #1 from Jakub Jelinek --- Started with r181118.
[Bug libstdc++/80335] perf of copying std::optional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80335
--- Comment #3 from sgunderson at bigfoot dot com ---
Appears to have been fixed in GCC 8, indeed.
#include
std::optional func()
{
return 3;
}
GCC 7 (-O2) compiles to:
0: 48 89 f8mov%rdi,%rax
3: c7 07 03 00 00 00 movl $0x3,(%rdi)
9: c6 47 04 01 movb $0x1,0x4(%rdi)
d: c3 retq
GCC 8 (-O2):
0: 48 b8 03 00 00 00 01movabs $0x10003,%rax
7: 00 00 00
a: c3 retq
This is an ABI break, but I'll happily take it. :-)
[Bug c/86174] New: Poor vectorization/register allocation with omp simd, FMA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86174 Bug ID: 86174 Summary: Poor vectorization/register allocation with omp simd, FMA Product: gcc Version: 8.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: jed at 59A2 dot org Target Milestone: --- Created attachment 44287 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44287&action=edit Source demonstrating poor optimization The attached code produces lots of needless spills with gcc-8.1 on Linux. $ gcc -O3 -Wall -march=skylake -ffast-math -fopenmp -c mm-gcc.c 0080 vbroadcastsd ymm2,QWORD PTR [rdx] 0085 vmovupd ymm1,YMMWORD PTR [rcx] 0089 vmovapd ymm0,ymm1 008d vfmadd213pd ymm0,ymm2,YMMWORD PTR [rsp] 0093 vmovapd YMMWORD PTR [rsp],ymm0 0098 vmovupd ymm0,YMMWORD PTR [rcx+0x20] 009d vfmadd213pd ymm2,ymm0,YMMWORD PTR [rsp+0x20] 00a4 vmovapd YMMWORD PTR [rsp+0x20],ymm2 00aa vbroadcastsd ymm2,QWORD PTR [rdx+0x400] 00b3 vmovapd ymm3,ymm1 00b7 vfmadd213pd ymm3,ymm2,YMMWORD PTR [rsp+0x40] 00be vmovapd YMMWORD PTR [rsp+0x40],ymm3 00c4 vfmadd213pd ymm2,ymm0,YMMWORD PTR [rsp+0x60] 00cb vmovapd YMMWORD PTR [rsp+0x60],ymm2 00d1 vbroadcastsd ymm2,QWORD PTR [rdx+0x800] 00da vmovapd ymm3,ymm1 00de vfmadd213pd ymm3,ymm2,YMMWORD PTR [rsp+0x80] 00e8 vmovapd YMMWORD PTR [rsp+0x80],ymm3 00f1 vfmadd213pd ymm2,ymm0,YMMWORD PTR [rsp+0xa0] 00fb vmovapd YMMWORD PTR [rsp+0xa0],ymm2 0104 vbroadcastsd ymm2,QWORD PTR [rdx+0xc00] 010d vfmadd213pd ymm1,ymm2,YMMWORD PTR [rsp+0xc0] 0117 vmovapd YMMWORD PTR [rsp+0xc0],ymm1 0120 vfmadd213pd ymm0,ymm2,YMMWORD PTR [rsp+0xe0] 012a vmovapd YMMWORD PTR [rsp+0xe0],ymm0 0133 addrdx,0x8 0137 addrcx,0x400 013e cmprsi,rcx 0141 jne0080 GCC does not issue vector instructions if omp simd is removed. In contrast, clang-6 vectorizes well with or without omp simd: $ clang -O3 -Wall -march=haswell -ffast-math -c mm-gcc.c 00e0 vmovapd ymm9,ymm6 00e4 vbroadcastsd ymm10,QWORD PTR [rdi+rbx*8-0x800] 00ee vmovupd ymm6,YMMWORD PTR [rax-0x20] 00f3 vmovupd ymm11,YMMWORD PTR [rax] 00f7 vfmadd231pd ymm1,ymm6,ymm10 00fc vfmadd231pd ymm7,ymm11,ymm10 0101 vbroadcastsd ymm10,QWORD PTR [rdi+rbx*8-0x400] 010b vfmadd231pd ymm8,ymm6,ymm10 0110 vfmadd231pd ymm5,ymm11,ymm10 0115 vbroadcastsd ymm10,QWORD PTR [rdi+rbx*8] 011b vfmadd231pd ymm2,ymm6,ymm10 0120 vfmadd231pd ymm3,ymm11,ymm10 0125 vbroadcastsd ymm10,QWORD PTR [rdi+rbx*8+0x400] 012f vfmadd213pd ymm6,ymm10,ymm9 0134 vfmadd231pd ymm4,ymm11,ymm10 0139 addrax,0x400 013f addrbx,0x1 0143 jne00e0 (I used -march=haswell instead of -march=skylake due to https://bugs.llvm.org/show_bug.cgi?id=37819.)
[Bug lto/86175] New: LTO code generator does not respect ld -u option to force symbol inclusion in the link product
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86175 Bug ID: 86175 Summary: LTO code generator does not respect ld -u option to force symbol inclusion in the link product Product: gcc Version: 8.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: zenith432 at users dot sourceforge.net CC: marxin at gcc dot gnu.org Target Milestone: --- Created attachment 44288 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44288&action=edit Test case to demonstrate bug Please see test case in attached file that contains Makefile test.c GCC is 8.1.1 ld is from binutils 2.29.1 Compiling with -flto and attempting to force inclusion of a symbol with hidden visibility. The symbol is discarded. make gcc -o test1 -fvisibility=default -ffunction-sections -Wl,--gc-sections,-u,KeepMe test.c strings test1 | grep This This string should appear in the executable. gcc -o test2 -flto -fvisibility=default -ffunction-sections -Wl,--gc-sections,-u,KeepMe test.c strings test2 | grep This This string should appear in the executable. gcc -o test3 -fvisibility=hidden -ffunction-sections -Wl,--gc-sections,-u,KeepMe test.c strings test3 | grep This This string should appear in the executable. gcc -o test4 -flto -fvisibility=hidden -ffunction-sections -Wl,--gc-sections,-u,KeepMe test.c strings test4 | grep This make: [Makefile:18: test4] Error 1 (ignored)
[Bug c++/86176] New: Wnull-dereference warning disappears with a call to std::cout on the line after
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86176
Bug ID: 86176
Summary: Wnull-dereference warning disappears with a call to
std::cout on the line after
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jg at jguk dot org
Target Milestone: ---
Hello
Some possible issues. Could you give your opinion please.
1. printf Wnull-dereference warning is only visible with -O2 (not -O0)
2. printf Wnull-dereference warning disappears if I uncomment the std::cout on
line after.
There is bug 86172 but I have not linked it.
note, I also tried g++8.1 x86-64, same results.
g++-8 --version
g++-8 (Ubuntu 8-20180414-1ubuntu2) 8.0.1 20180414 (experimental) [trunk
revision 259383]
jonny@asus:~/code$ g++-8 -O0 -Wall -Wextra -Wnull-dereference -Wpedantic -o
main.o -c main.cpp
jonny@asus:~/code$ g++-8 -O2 -Wall -Wextra -Wnull-dereference -Wpedantic -o
main.o -c main.cpp
main.cpp: In function ‘int main()’:
main.cpp:8:11: warning: null pointer dereference [-Wnull-dereference]
printf("%d\n", *i);
~~^~~~
jonny@asus:~/code$
#include
#include
void f(const int *i)
{
printf("%d\n", *i);
//std::cout << *i;
}
int main () {
f(nullptr);
return 0;
}
[Bug c++/86177] New: Wnull-dereference warning for object file compile missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86177
Bug ID: 86177
Summary: Wnull-dereference warning for object file compile
missing
Product: gcc
Version: 8.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jg at jguk dot org
Target Milestone: ---
Hello
This doesn't give any warning that the pointer is not checked when being
compiled. If linked with second program example below, there is no issue
visible. Then crashes when runs:
jonny@asus:~/code$ ./main
Segmentation fault (core dumped)
//g++-8 -O2 -Wall -Wextra -Wnull-dereference -Wpedantic -o main -c main.cpp
void f(int *i)
{
*i = 1;
}
//g++-8 -O2 -Wall -Wextra -Wnull-dereference -Wpedantic main1.o -o main
main2.cpp
extern void f(int* i);
int main()
{
f(nullptr);
// return
}
[Bug c/86174] Poor vectorization/register allocation with omp simd, FMA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86174 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #1 from Alexander Monakov --- It might be useful to note that what the testcase "wants" to happen is for the compiler to notice that the temporary array 'double C[Si][Sk]' does not need to live in memory - ideally it would correspond to 8 256-bit (or 4 512-bit) registers.
[Bug c++/80485] rejects-valid: constexpr static_cast of pointer-to-member-function to bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80485 --- Comment #7 from Tony E Lewis --- Ah yes - I'm seeing it compiling cleanly now on Godbolt's trunk (9.0.0 20180615). Must have been a temporary glitch in the build (and couldn't possibly have been due to my error :P ).
[Bug c++/86177] Wnull-dereference warning for object file compile missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86177 --- Comment #1 from Jonny Grant --- If g++ compiles both main.cpp and main2.cpp at the same time (ie no separate obj file stage) it also doesn't give the expected warning. jonny@asus:~/code$ g++-8 -O2 -Wall -Wextra -Wnull-dereference -Wpedantic -o main main2.cpp main.cpp jonny@asus:~/code$
[Bug c/86178] New: No warning when missing return from function main()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86178
Bug ID: 86178
Summary: No warning when missing return from function main()
Product: gcc
Version: 8.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jg at jguk dot org
Target Milestone: ---
Hello, should GCC show an error when "return" is missing from function main()
below ? Maybe I am missing something...
jonny@asus:~/code$ g++ -O2 -Wreturn-type -Wall -Wextra -Wnull-dereference
-Wpedantic -o main main3.cpp
jonny@asus:~/code$
I expected:
In function ‘main’:
warning: control reaches end of non-void function [-Wreturn-type]
//g++-8 -O2 -Wreturn-type -Wall -Wextra -Wnull-dereference -Wpedantic -o main
main3.cpp
#include
int main(void)
{
printf("hello\n");
// return
}
[Bug c/86178] No warning when missing return from function main()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86178 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Jonathan Wakely --- You've set component=c but you're using g++ which means you're compiling C++ and so there's an implicit "return 0;" from main.
[Bug c++/86177] Wnull-dereference warning for object file compile missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86177 --- Comment #2 from Jonathan Wakely --- That's how C++ works. Each translation unit is compiled separately. It's your job to prevent such errors.
[Bug c/86178] No warning when missing return from function main()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86178 --- Comment #2 from Jonathan Wakely --- See 4) at http://en.cppreference.com/w/cpp/language/main_function#Explanation There's also an implicit "return 0;" for C, but only since C99 and only when the return type of main is compatible with int. See 3) at http://en.cppreference.com/w/c/language/main_function
[Bug middle-end/86172] [meta-bug] issues with -Wnull-dereference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86172 Bug 86172 depends on bug 86177, which changed state. Bug 86177 Summary: Wnull-dereference warning for object file compile missing https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86177 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID
[Bug c++/86177] Wnull-dereference warning for object file compile missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86177 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Jonathan Wakely --- If you compile with -flto then the link-time optimizations can see across translation units and give a warning. Otherwise it's impossible. Another alternative would be to decorate the function with __attribute__((nonnull)) which says it requires a non-null pointer: extern __attribute__((nonnull)) void f(int* i); Now you'll get a warning when compiling main2.cpp because the compiler can see you're passing a null pointer to a function that says it requires non-null pointers: b.cc: In function ‘int main()’: b.cc:5:14: warning: null argument where non-null required (argument 1) [-Wnonnull] f(nullptr); ^
[Bug c++/85471] closing a "thread" in "C++" using "pthread_exit(NULL)" creates a "SIGABRT"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85471 --- Comment #4 from Andreas Otto --- change my C++ wrapper from "embedded data" (large amount of data) to just an embedded pointer (only 8byte pointer in the C++ class) → the error is still there… ==57730== Process terminating with default action of signal 6 (SIGABRT) ==57730==at 0x6BA2F67: raise (raise.c:55) ==57730==by 0x6BA4339: abort (abort.c:78) ==57730==by 0x4178DD: _Unwind_SetGR (unwind-dw2.c:273) ==57730==by 0x409B8C: __gxx_personality_v0 (eh_personality.cc:712) ==57730==by 0x72AC4A4: _Unwind_ForcedUnwind_Phase2 (unwind.inc:175) ==57730==by 0x72ACA64: _Unwind_ForcedUnwind (unwind.inc:207) ==57730==by 0x696098F: __pthread_unwind (unwind.c:126) ==57730==by 0x695A8B4: __do_cancel (pthreadP.h:283) ==57730==by 0x695A8B4: pthread_exit (pthread_exit.c:28) ==57730==by 0x506554E: libmsgque::SysExit(int, int) (sys.cc:1000) ==57730==by 0x5059987: libmsgque::MqSysExit(int, int) (msgque.h:2038) ==57730==by 0x505B4F8: libmsgque::MqExitP(libmsgque::MqS*, char const*, char const*) (msgque.cc:440) ==57730==by 0x50B2FAA: ccmsgque::MqC::ExitP(char const*, char const*) (MqC.cc:380) ==57730==by 0x405EF7: Filter6::EXIT() (Filter6.cc:80) ==57730==by 0x5099A15: ccmsgque::MqC::ProcCall(libmsgque::MqS*, void*) (ccmisc.cc:50) ==57730==by 0x5043DA3: libmsgque::MqCallbackCall(libmsgque::MqS*, libmsgque::MqCallbackS) (msgque_private.h:326) ==57730==by 0x5045368: libmsgque::pTokenInvoke(libmsgque::pTokenS const*) (token.cc:342) ==57730==by 0x507836C: libmsgque::pServiceStart(libmsgque::MqS*, libmsgque::MqErrorE (*)(void*, libmsgque::MqS**, libmsgque::MqEnvS*), void*) (service.cc:244) ==57730==by 0x502D33B: libmsgque::pEventStart(libmsgque::MqS*, libmsgque::MqEventS*, timeval const*) (event.cc:287) ==57730==by 0x5055AD3: libmsgque::pIoSelectStart(libmsgque::MqIoS*, timeval const*) (io.cc:267) ==57730==by 0x5078B3E: libmsgque::MqProcessEvent(libmsgque::MqS*, long, libmsgque::MqWaitOnEventE) (service.cc:377) ==57730==by 0x5063F70: libmsgque::MqSysServerThreadMain(libmsgque::MqSysServerThreadMainS*) (sys.cc:488) ==57730==by 0x5063FB7: libmsgque::sSysServerThreadInit(void*) (sys.cc:502) ==57730==by 0x6959723: start_thread (pthread_create.c:457) ==57730==by 0x6C5AE8C: clone (clone.S:109) ==57730== ==57730== HEAP SUMMARY: ==57730== in use at exit: 160,370 bytes in 184 blocks ==57730== total heap usage: 940 allocs, 756 frees, 677,695 bytes allocated ==57730== ==57922== ==57922== HEAP SUMMARY: ==57922== in use at exit: 72,944 bytes in 4 blocks ==57922== total heap usage: 487 allocs, 483 frees, 273,097 bytes allocated ==57922== ==57922== LEAK SUMMARY: ==57922==definitely lost: 0 bytes in 0 blocks ==57922==indirectly lost: 0 bytes in 0 blocks ==57922== possibly lost: 0 bytes in 0 blocks ==57922==still reachable: 72,944 bytes in 4 blocks ==57922== suppressed: 0 bytes in 0 blocks ==57922== Rerun with --leak-check=full to see details of leaked memory ==57922== ==57922== For counts of detected and suppressed errors, rerun with: -v ==57922== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) ==57730== LEAK SUMMARY: but I have additional "leakcheck" data… trans2-3-TE2-init-(3|binary|uds|cc.uds.thread) start ==67406== 672 bytes in 2 blocks are possibly lost in loss record 131 of 151 ==67406==at 0x4C2C240: calloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==67406==by 0x40119E1: allocate_dtv (dl-tls.c:322) ==67406==by 0x401223D: _dl_allocate_tls (dl-tls.c:539) ==67406==by 0x695A180: allocate_stack (allocatestack.c:580) ==67406==by 0x695A180: pthread_create@@GLIBC_2.2.5 (pthread_create.c:654) ==67406==by 0x5064231: libmsgque::SysServerThread(libmsgque::MqS*, libmsgque::MqFactoryS*, libmsgque::MqBufferLS**, libmsgque::MqBufferLS**, char const*, int, libmsgque::MqIdS*) (sys.cc:562) ==67406==by 0x5057E6F: libmsgque::pIoStartServer(libmsgque::MqIoS*, libmsgque::IoStartServerE, libmsgque::MqSockS*, libmsgque::MqIdS*) (io.cc:692) ==67406==by 0x5053294: libmsgque::GenericServer(libmsgque::GenericS*, sockaddr*, unsigned int) (generic_io.cc:155) ==67406==by 0x5048FE9: libmsgque::UdsServer(libmsgque::UdsS*) (uds_io.cc:129) ==67406==by 0x505421E: libmsgque::pIoCreate(libmsgque::MqS*, libmsgque::MqIoS**) (io.cc:95) ==67406==by 0x5083507: libmsgque::MqLinkCreate(libmsgque::MqS*, libmsgque::MqBufferLS*) (link.cc:1104) ==67406==by 0x5084730: libmsgque::MqLinkDefault(libmsgque::MqS*, libmsgque::MqBufferLS*) (link.cc:1256) ==67406==by 0x5082279: libmsgque::MqLinkCreate(libmsgque::MqS*, libmsgque::MqBufferLS*) (link.cc:971) ==67406==by 0x50B3ACD: ccmsgque::MqC::LinkCreate(ccmsgque::MqBufferLC*) (MqC.cc:414) ==67406==by 0x5095DE2: ccmsgque::MqC::LinkCreate(ccmsgque::MqBufferLC) (ccmsgque.cc:151) ==67406==by 0x40498B: main (Filter6.cc:176) ==67406==
[Bug c/86179] New: ice in get_later_stmt, at tree-vectorizer.h:1108
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86179 Bug ID: 86179 Summary: ice in get_later_stmt, at tree-vectorizer.h:1108 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: ---
[Bug c/86179] ice in get_later_stmt, at tree-vectorizer.h:1108
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86179
--- Comment #1 from David Binderman ---
For this C code
c(int *d, char *g) {
char *a, *b, *e;
int f;
for (; f; f -= 8) {
*d++ = *e++ | (unsigned)*g++ << 8 | (unsigned)*b++ << 16 |
(unsigned)*a++ << 24;
*d++ = *e++ | (unsigned)*g++ << 8 | (unsigned)*b++ << 16 |
(unsigned)*a++ << 24;
}
}
compiled by recent gcc trunk and flag -O3, I get:
$ ~/gcc/results/bin/gcc -c -w -O3 bug446.c
during GIMPLE pass: vect
bug446.c: In function ‘c’:
bug446.c:1:1: internal compiler error: in get_later_stmt, at
tree-vectorizer.h:1108
c(int *d, char *g) {
^
0x7df578 get_later_stmt
../../trunk/gcc/tree-vectorizer.h:1105
0x7df578 vect_find_last_scalar_stmt_in_slp(_slp_tree*)
../../trunk/gcc/tree-vect-slp.c:1819
0x316 vect_find_last_scalar_stmt_in_slp(_slp_tree*)
../../trunk/gcc/tree-vect-slp.c:1815
0x316 vect_schedule_slp_instance
$ ~/gcc/results/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/home/dcb/gcc/results/bin/gcc
COLLECT_LTO_WRAPPER=/home/dcb/gcc/results.261680.ubsan/libexec/gcc/x86_64-pc-linux-gnu/9.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../trunk/configure --prefix=/home/dcb/gcc/results.261680.ubsan
--with-build-config=bootstrap-ubsan --disable-multilib --disable-werror
--enable-checking=df,extra,fold,rtl,yes --enable-languages=c,c++,fortran
Thread model: posix
gcc version 9.0.0 20180616 (experimental) (GCC)
$
[Bug tree-optimization/64946] [AArch64] gcc.target/aarch64/vect-abs-compile.c - "abs" vectorization fails for char/short types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64946 --- Comment #24 from kugan at gcc dot gnu.org --- Author: kugan Date: Sat Jun 16 21:34:29 2018 New Revision: 261681 URL: https://gcc.gnu.org/viewcvs?rev=261681&root=gcc&view=rev Log: gcc/ChangeLog: 2018-06-16 Kugan Vivekanandarajah PR middle-end/64946 * cfgexpand.c (expand_debug_expr): Hande ABSU_EXPR. * config/i386/i386.c (ix86_add_stmt_cost): Likewise. * dojump.c (do_jump): Likewise. * expr.c (expand_expr_real_2): Check operand type's sign. * fold-const.c (const_unop): Handle ABSU_EXPR. (fold_abs_const): Likewise. * gimple-pretty-print.c (dump_unary_rhs): Likewise. * gimple-ssa-backprop.c (backprop::process_assign_use): Likesie. (strip_sign_op_1): Likesise. * match.pd: Add new pattern to generate ABSU_EXPR. * optabs-tree.c (optab_for_tree_code): Handle ABSU_EXPR. * tree-cfg.c (verify_gimple_assign_unary): Likewise. * tree-eh.c (operation_could_trap_helper_p): Likewise. * tree-inline.c (estimate_operator_cost): Likewise. * tree-pretty-print.c (dump_generic_node): Likewise. * tree-vect-patterns.c (vect_recog_sad_pattern): Likewise. * tree.def (ABSU_EXPR): New. gcc/c-family/ChangeLog: 2018-06-16 Kugan Vivekanandarajah * c-common.c (c_common_truthvalue_conversion): Handle ABSU_EXPR. gcc/c/ChangeLog: 2018-06-16 Kugan Vivekanandarajah * c-typeck.c (build_unary_op): Handle ABSU_EXPR; * gimple-parser.c (c_parser_gimple_statement): Likewise. (c_parser_gimple_unary_expression): Likewise. gcc/cp/ChangeLog: 2018-06-16 Kugan Vivekanandarajah * constexpr.c (potential_constant_expression_1): Handle ABSU_EXPR. * cp-gimplify.c (cp_fold): Likewise. gcc/testsuite/ChangeLog: 2018-06-16 Kugan Vivekanandarajah PR middle-end/64946 * gcc.dg/absu.c: New test. * gcc.dg/gimplefe-29.c: New test. * gcc.target/aarch64/pr64946.c: New test. Added: trunk/gcc/testsuite/gcc.dg/absu.c trunk/gcc/testsuite/gcc.dg/gimplefe-29.c trunk/gcc/testsuite/gcc.target/aarch64/pr64946.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-common.c trunk/gcc/c/ChangeLog trunk/gcc/c/c-typeck.c trunk/gcc/c/gimple-parser.c trunk/gcc/cfgexpand.c trunk/gcc/config/i386/i386.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/constexpr.c trunk/gcc/cp/cp-gimplify.c trunk/gcc/dojump.c trunk/gcc/expr.c trunk/gcc/fold-const.c trunk/gcc/gimple-pretty-print.c trunk/gcc/gimple-ssa-backprop.c trunk/gcc/match.pd trunk/gcc/optabs-tree.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-cfg.c trunk/gcc/tree-eh.c trunk/gcc/tree-inline.c trunk/gcc/tree-pretty-print.c trunk/gcc/tree-vect-patterns.c trunk/gcc/tree.def
[Bug middle-end/82479] missing popcount builtin detection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82479 --- Comment #13 from kugan at gcc dot gnu.org --- Author: kugan Date: Sat Jun 16 21:39:31 2018 New Revision: 261682 URL: https://gcc.gnu.org/viewcvs?rev=261682&root=gcc&view=rev Log: gcc/ChangeLog: 2018-06-16 Kugan Vivekanandarajah PR middle-end/82479 * ipa-fnsummary.c (will_be_nonconstant_expr_predicate): Handle CALL_EXPR. * tree-scalar-evolution.c (interpret_expr): Likewise. (expression_expensive_p): Likewise. * tree-ssa-loop-ivopts.c (contains_abnormal_ssa_name_p): Likewise. * tree-ssa-loop-niter.c (number_of_iterations_popcount): New. (number_of_iterations_exit_assumptions): Use number_of_iterations_popcount. (ssa_defined_by_minus_one_stmt_p): New. gcc/testsuite/ChangeLog: 2018-06-16 Kugan Vivekanandarajah PR middle-end/82479 * gcc.dg/tree-ssa/popcount.c: New test. * gcc.dg/tree-ssa/popcount2.c: New test. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/popcount.c trunk/gcc/testsuite/gcc.dg/tree-ssa/popcount2.c Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-fnsummary.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-scalar-evolution.c trunk/gcc/tree-ssa-loop-ivopts.c trunk/gcc/tree-ssa-loop-niter.c
[Bug c++/86177] Wnull-dereference warning for object file compile missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86177 --- Comment #4 from Jonny Grant --- Thank you for your replies! Could the -flto tip be added to the -Wnull-dereference documentation? https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html
[Bug c++/86177] Wnull-dereference warning for object file compile missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86177 --- Comment #5 from Jonathan Wakely --- Why add it there and not to every other warning option that depends on interprocedural analysis and inlining? If the dereference and the null pointer are in separate files, then of course the compiler can't warn. That's just how C++ works.
[Bug c++/86180] New: Friend function definition not instantiated in certain circumstances
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86180
Bug ID: 86180
Summary: Friend function definition not instantiated in certain
circumstances
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 following code compiles fine on clang++:
template
struct provide {
friend T f() { return T(); }
};
void g() {
void f();
provide p;
f();
}
int main() {
g();
}
However, gcc++ reports that it cannot find the definition of f.
Indeed, a previous version of clang++ cannot compile the above code either. It
was fixed in https://bugs.llvm.org/show_bug.cgi?id=9518
I believe that gcc++ shall also fix the bug, right?
[Bug c++/86181] New: static object mangling conflicts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86181
Bug ID: 86181
Summary: static object mangling conflicts
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: ---
I found that gcc+ produces errors when it compiles the following code:
extern "C" void abort();
static int i;
int *p = &i;
int main()
{
int i;
{
extern int i;
i = 1;
*p = 2;
if (i == 2)
abort ();
}
return 0;
}
When compiling the above code, clang++ does not produce any errors. The code
comes from https://bugs.llvm.org/show_bug.cgi?id=5966
Indeed, the situation is more complicated. The above bug report of clang says
that the code comes from a bug report of gcc:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31775
The gcc report has a long discussion on this issue. Perhaps, the bug is not
fully fixed?
[Bug c++/86182] New: gcc crashes when compiling the code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86182
Bug ID: 86182
Summary: gcc crashes when compiling the 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:
#include
template static char const * f(T *t) {
T u(*t);
u.x = "hello world";
printf("%s\n", u.x);
return "initialized";
}
int main() {
union { char const *x = f(this); };
printf("%s\n", x);
}
gcc++ produces errors messages:
/home/haozhong/project/approach/otherreport/llvm/tmp/llvm_10531/code0.c.cpp: In
function ‘const char* f(T*) [with T = main()::]’:
/home/haozhong/project/approach/otherreport/llvm/tmp/llvm_10531/code0.c.cpp:3:42:
error：Local declaration from a different function
template static char const * f(T *t) {
^
D.2918
/home/haozhong/project/approach/otherreport/llvm/tmp/llvm_10531/code0.c.cpp:4:4:
T u(*t);
^
_1 = &D.2918;
/home/haozhong/project/approach/otherreport/llvm/tmp/llvm_10531/code0.c.cpp:3:42:
error：Local declaration from a different function
template static char const * f(T *t) {
^
/home/haozhong/project/approach/otherreport/llvm/tmp/llvm_10531/code0.c.cpp:3:42:
error：Local declaration from a different function
during GIMPLE pass: cfg
/home/haozhong/project/approach/otherreport/llvm/tmp/llvm_10531/code0.c.cpp:3:42:
internal error：verify_gimple 失败
0xf11023 verify_gimple_in_cfg(function*, bool)
../../code/gcc/tree-cfg.c:5585
0xdf808f execute_function_todo
../../code/gcc/passes.c:1994
0xdf8fde execute_todo
../../code/gcc/passes.c:2048
Please include the complete backtrace with any bug report.
The code comes from a bug report of clang++
https://bugs.llvm.org/show_bug.cgi?id=10531
The clang report can provide hints to understand the problem.
[Bug c++/86183] New: Scoped enumeration instantiated even if not required
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86183
Bug ID: 86183
Summary: Scoped enumeration instantiated even if not required
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: ---
gcc produces errors when compiling the following code:
template
struct A {
enum class B {
X = T::value
};
};
int main() {
A a;
}
A previous version of clang++ also produces errors when compiling the above
code, but it was fixed in https://bugs.llvm.org/show_bug.cgi?id=10044
Shall gcc also fix the problem?
[Bug c++/86184] New: Shall gcc support this feature?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86184
Bug ID: 86184
Summary: Shall gcc support this feature?
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: ---
gcc++ produces errors when compiling the following code:
#include
int main(int argc, char **argv) {
printf("%p\n", (void *)0xdeadbeef ? : (void *)0xaa);
return 0;
}
This code comes from a bug report of clang:
https://bugs.llvm.org/show_bug.cgi?id=7726
The programmers of clang discuss the code in details. They mentioned that gcc
does not accept the above code, but after all, they decide to implement the
feature to compile the code.
Shall gcc also support this feature?
[Bug c++/86185] New: gcc does not reject the ill-formed code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86185
Bug ID: 86185
Summary: gcc does not reject the ill-formed 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: ---
gcc++ does not produce any errors when it compiles the following code:
template
void f() {
auto i = T(), j = 0;
}
int main() {
f();
f();
}
The code comes from a bug report of clang:
https://bugs.llvm.org/show_bug.cgi?id=9276
Johannes Schaub analyzed why clang shall reject the code.
Shall gcc also reject the code?
[Bug c++/86186] New: Unqualified calls of std::get lead to ADL issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86186
Bug ID: 86186
Summary: Unqualified calls of std::get lead to ADL issues
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 sample code is as follow:
#include
#include
namespace foo {
struct bar { bool operator==(bar) const { return true; } };
template
struct hard_error { static_assert(I > 0, ""); using type = void; };
template
typename hard_error::type get(T) {}
}
int main()
{
std::tuple t1, t2;
t1 == t2; // error: static_assert failed ""
// note: in instantiation of template class 'foo::hard_error<0>'
// note: while substituting explicitly-specified template arguments into
function template 'get'
}
A previous version of clang++ does not produce any error messages for the above
code, but it was fixed in https://bugs.llvm.org/show_bug.cgi?id=20092
[Bug c++/86187] New: Subscript operator applied to an temporary array results in an lvalue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86187
Bug ID: 86187
Summary: Subscript operator applied to an temporary array
results in an lvalue
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:
using Y = int[10];
int main() {
(Y { })[0] = 1;
}
The code comes from a discussion on Stackoverflow:
http://stackoverflow.com/questions/33161003/using-a-temporary-array-as-an-lvalue
The problem was reported to clang and it was fixed:
https://bugs.llvm.org/show_bug.cgi?id=25357
Although now clang provides diagnostic, gcc++ still does not provide any error
messages. Please fix the problem.
[Bug libstdc++/86188] New: Enhancement to std::merge, constexpr check of iterator types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86188 Bug ID: 86188 Summary: Enhancement to std::merge, constexpr check of iterator types Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: joshua.r.marshall.1991 at gmail dot com Target Milestone: --- Before I go in an submitting patches all willy-nilly, I've been poking at std::merge and I think I see that it could catch some programming bugs better with constexpr std::iterator_traits::iterator_category == <>. This looks simple, but there may also be a reason it hasn't been done.
[Bug driver/40960] POSIX requires that option -D have a lower precedence than -U
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40960 Eric Gallager changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=80535 --- Comment #6 from Eric Gallager --- (In reply to Eric Gallager from comment #5) > > Confirmed, I think a configure option would be a good way to go about it. Other options as mentioned in bug 80535 comment 1 include respecting the POSIXLY_CORRECT environment variable, and/or adding a -posix-std= flag to mirror the existing -std= flag for the language standard
[Bug driver/29931] following argv[0] symlink in process_command breaks symlinked-together toolchain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29931 Eric Gallager changed: What|Removed |Added Status|NEW |WAITING --- Comment #7 from Eric Gallager --- (In reply to Eric Gallager from comment #6) > (In reply to Jorn Wolfgang Rennecke from comment #4) > > The bug is not fixed; the gcc.c patch has not been reviewed. > > What about now, after r169891? As mentioned in the comment after you: > > (In reply to simonb from comment #5) > > Author: simonb > > Date: Mon Feb 7 18:10:15 2011 > > New Revision: 169891 > > > > URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169891 > > Log: > > Auto-detect suitable default behaviour for prefix canonicalization. > > > > Current gcc offers -no-canonical-prefixes to turn off realpath() for > > prefixes > > generated from the path used to address the gcc driver. This allows gcc to > > work in "symlink farm" installations, where every file in gcc is actually a > > symlink to its real contents. However, the flag has to be given explicitly. > > If not, the default is to use realpath() to create prefixes and the result > > is usually failure to find cc1[plus], f951, etc. > > > > This patch adds a check for a file as a way to auto-detect whether prefix > > canonicalization is appropriate or not. Detection can be overridden by > > using the -[no-]canonical-prefixes flags. > > > > The patch also completes the fix for PR/29931, adding code that covers the > > unadopted portion of this PR's attached patch. > > > > gcc/ChangeLog.google: > > 2011-02-07 Simon Baldwin > > > > PR driver/29931 > > * doc/invoke.texi: Adjust -[no-]canonical-prefixes documentation. > > * gcc.c (display_help): Help text for -[no-]canonical-prefixes. > > (driver_handle_option): Ignore OPT_canonical_prefixes. > > (process_command): Handle OPT_[no_]canonical_prefixes, auto-detect > > suitable default prefix canonicalization mode. > > * common.opt (canonical-prefixes): New flag. > > > > Google ref: 40029, 38719 > > > > > > Modified: > > branches/google/integration/gcc/ChangeLog.google-integration > > branches/google/integration/gcc/common.opt > > branches/google/integration/gcc/doc/invoke.texi > > branches/google/integration/gcc/gcc.c WAITING on a reply
[Bug c++/68615] Unhelpful location when missing a semi-colon on a function declaration at the end of a header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68615 Eric Gallager changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #4 from Eric Gallager --- Since David put himself as the assignee for this, I'm changing the status to ASSIGNED.
[Bug c++/56084] poor error recovery for missing ";"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56084 Eric Gallager changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #9 from Eric Gallager --- ASSIGNED because it already has an assignee.
[Bug other/84904] Implement an option to attempt to auto-apply fix-it hints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84904 Eric Gallager changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-06-17 Ever confirmed|0 |1 Severity|normal |enhancement --- Comment #2 from Eric Gallager --- Confirmed as an enhancement and ASSIGNED since you already assigned yourself
[Bug c/84887] missing semicolon: further improvements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84887 Eric Gallager changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-06-17 Ever confirmed|0 |1 Severity|normal |enhancement --- Comment #4 from Eric Gallager --- (In reply to Eric Gallager from comment #3) > (In reply to Eric Gallager from comment #2) > > link to thread on reddit? > > > > Never mind, I found it: > https://www.reddit.com/r/programming/comments/84oizv/ > usability_improvements_in_gcc_8/dvr93d4/ > I'll confirm this bug after finding the Hacker News one, too. Actually never mind again; that link isn't necessary to confirm this bug. ASSIGNED since there's an assignee.
[Bug c++/85867] Subscript operator applied to an temporary array results in an lvalue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85867 Marc Glisse changed: What|Removed |Added CC||zhonghao at pku dot org.cn --- Comment #3 from Marc Glisse --- *** Bug 86187 has been marked as a duplicate of this bug. ***
[Bug c++/86187] Subscript operator applied to an temporary array results in an lvalue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86187 Marc Glisse changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Marc Glisse --- It has the same exact title, code, SO link, clang link... *** This bug has been marked as a duplicate of bug 85867 ***
