[Bug middle-end/64463] Add warning: returns_nonnull attribute on a function compared against NULL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64463 Andrew Pinski changed: What|Removed |Added Keywords||diagnostic Severity|normal |enhancement
[Bug tree-optimization/64464] Optimization for reusing values in loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64464
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
Status|UNCONFIRMED |NEW
Last reconfirmed||2016-08-01
Component|middle-end |tree-optimization
Ever confirmed|0 |1
--- Comment #1 from Andrew Pinski ---
here is the C testcase:
int f(int a, int b)
{
for(int i = 0; i< 1; i++)
{
int t = a * a - b * b;
int t1 = 2 * a + b;
g (t * t + t1 * t1 );
a = t;
b = t1;
}
}
int f1(int a, int b)
{
int a2 = a * a;
int b2 = b * b;
for(int i = 0; i< 1; i++)
{
int t = a2 - b2;
int t1 = 2 * a + b;
g (t * t + t1 * t1 );
a2 = t * t;
b2 = t1 * t1;
a = t;
b = t1;
}
}
CUT
I suspect this is a missing PRE; though I don't know if it makes sense to call
it that.
[Bug c/7652] -Wswitch-break : Warn if a switch case falls through
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652 --- Comment #54 from Marek Polacek --- (In reply to Ozkan Sezer from comment #53) > (In reply to Marek Polacek from comment #52) > > Author: mpolacek > > Date: Fri Jul 29 12:39:25 2016 > > New Revision: 238864 > > > > URL: https://gcc.gnu.org/viewcvs?rev=238864&root=gcc&view=rev > > Log: > > PR c/7652 > > * config/i386/i386.c (ix86_expand_args_builtin): Add break. > > (ix86_expand_round_builtin): Likewise. > > > > Modified: > > trunk/gcc/ChangeLog > > trunk/gcc/config/i386/i386.c > > Will this be applied to 4.9 branch? The same issue is there too. Yes, I'll backport the fix to 4.9, too.
[Bug c++/72759] [6/7 Regression] ICE on invalid C++ code on x86_64-linux-gnu (Segmentation fault, tree_class_check, ocp_convert)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72759 Martin Liška changed: What|Removed |Added Keywords||ice-on-invalid-code Status|UNCONFIRMED |NEW Last reconfirmed||2016-08-01 CC||marxin at gcc dot gnu.org, ||ppalka at gcc dot gnu.org Target Milestone|--- |6.2 Summary|ICE on invalid C++ code on |[6/7 Regression] ICE on |x86_64-linux-gnu|invalid C++ code on |(Segmentation fault,|x86_64-linux-gnu |tree_class_check, |(Segmentation fault, |ocp_convert)|tree_class_check, ||ocp_convert) Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed, started with r233365.
[Bug c++/72760] incorrectly rejects valid C++ code that invokes __typeof__ on a specialized template function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72760 Martin Liška changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2016-08-01 CC||marxin at gcc dot gnu.org Target Milestone|--- |4.9.4 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed.
[Bug c++/72763] incorrectly accepts invalid C++11 code that instantiates a non-template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72763 Martin Liška changed: What|Removed |Added Keywords||accepts-invalid Status|UNCONFIRMED |NEW Last reconfirmed||2016-08-01 CC||marxin at gcc dot gnu.org Target Milestone|--- |4.9.4 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed.
[Bug c++/72764] ICE on invalid C++11 code instantiating an alias template: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in typedef_variant_p, at tree.c:12660
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72764 Martin Liška changed: What|Removed |Added Keywords||ice-on-invalid-code Status|UNCONFIRMED |NEW Last reconfirmed||2016-08-01 CC||marxin at gcc dot gnu.org Target Milestone|--- |4.9.4 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed.
[Bug target/72749] [7 Regression] ICE: verify_flow_info failed (error: wrong amount of branch edges after conditional jump in bb 5) w/ -O2 -fsched2-use-superblocks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72749 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-08-01 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed on powerpc64le.
[Bug tree-optimization/72746] [5/6/7 Regression] gcc ICE at -O2 and above on valid code on x86_64-linux-gnu with “seg fault”
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72746 Martin Liška changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2016-08-01 CC||marxin at gcc dot gnu.org Target Milestone|7.0 |5.5 Summary|[7 Regression] gcc ICE at |[5/6/7 Regression] gcc ICE |-O2 and above on valid code |at -O2 and above on valid |on x86_64-linux-gnu with|code on x86_64-linux-gnu |“seg fault” |with “seg fault” Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed.
[Bug target/71151] [avr] -fmerge-constants and -fdata-sections/-ffunction-sections results in string constants in .progmem.gcc_sw section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71151 --- Comment #15 from Georg-Johann Lay --- Author: gjl Date: Mon Aug 1 09:15:24 2016 New Revision: 238935 URL: https://gcc.gnu.org/viewcvs?rev=238935&root=gcc&view=rev Log: gcc/ Backport from 2016-06-16 trunk r237536. 2016-06-16 Senthil Kumar Selvaraj PR target/71151 * config/avr/avr.c (avr_asm_init_sections): Remove setup of progmem_swtable_section. (progmem_swtable_section): Remove. (avr_asm_function_rodata_section): Remove. (TARGET_ASM_FUNCTION_RODATA_SECTION): Remove. * config/avr/avr.h (JUMP_TABLES_IN_TEXT_SECTION): Define to 1. testsuite/ Backport from 2016-06-16 trunk r237536, r237910. 2016-06-16 Senthil Kumar Selvaraj PR target/71151 * gcc.target/avr/pr71151-1.c: New test. * gcc.target/avr/pr71151-2.c: New test. * gcc.target/avr/pr71151-3.c: New test. * gcc.target/avr/pr71151-4.c: New test. * gcc.target/avr/pr71151-5.c: New test. * gcc.target/avr/pr71151-6.c: New test. * gcc.target/avr/pr71151-7.c: New test. * gcc.target/avr/pr71151-8.c: New test. * gcc.target/avr/pr71151-common.h: New file. Added: branches/gcc-6-branch/gcc/testsuite/gcc.target/avr/pr71151-1.c branches/gcc-6-branch/gcc/testsuite/gcc.target/avr/pr71151-2.c branches/gcc-6-branch/gcc/testsuite/gcc.target/avr/pr71151-3.c branches/gcc-6-branch/gcc/testsuite/gcc.target/avr/pr71151-4.c branches/gcc-6-branch/gcc/testsuite/gcc.target/avr/pr71151-5.c branches/gcc-6-branch/gcc/testsuite/gcc.target/avr/pr71151-6.c branches/gcc-6-branch/gcc/testsuite/gcc.target/avr/pr71151-7.c branches/gcc-6-branch/gcc/testsuite/gcc.target/avr/pr71151-8.c branches/gcc-6-branch/gcc/testsuite/gcc.target/avr/pr71151-common.h Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/config/avr/avr.c branches/gcc-6-branch/gcc/config/avr/avr.h branches/gcc-6-branch/gcc/testsuite/ChangeLog
[Bug target/58693] GCC aarch64 arm_neon.h missing intrinsics from ACLE 2.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58693 James Greenhalgh changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-08-01 Summary|GCC aarch64 arm_neon.h |GCC aarch64 arm_neon.h |inconsistent with Apple |missing intrinsics from |clang arm64 arm_neon.h |ACLE 2.0 Ever confirmed|0 |1
[Bug driver/72765] New: Dynamic stack buffer overflow in GCC driver with -save-temps switch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72765 Bug ID: 72765 Summary: Dynamic stack buffer overflow in GCC driver with -save-temps switch. Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: m.ostapenko at samsung dot com Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Build: x86_64-pc-linux-gnu When testing experimental allocas and VLAs handling in AddressSanitizer, I've got such an error during GCC's "make check": max@max:~/build/master$ /home/max/build/master/gcc/testsuite/g++/../../xg++ -B/home/max/build/master/gcc/testsuite/g++/../../ /home/max/workspace/downloads/gcc/gcc/testsuite/c-c++-common/cilk-plus/CK/pr69826-2.c -fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++ -I/home/max/build/master/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/home/max/build/master/x86_64-unknown-linux-gnu/libstdc++-v3/include -I/home/max/workspace/downloads/gcc/libstdc++-v3/libsupc++ -I/home/max/workspace/downloads/gcc/libstdc++-v3/include/backward -I/home/max/workspace/downloads/gcc/libstdc++-v3/testsuite/util -fmessage-length=0 -g -O2 -fcilkplus -save-temps -B/home/max/build/master/x86_64-unknown-linux-gnu/./libcilkrts/ -L/home/max/build/master/x86_64-unknown-linux-gnu/./libcilkrts/.libs -L/home/max/build/master/x86_64-unknown-linux-gnu/./libstdc++-v3/src/.libs -B/home/max/build/master/x86_64-unknown-linux-gnu/./libstdc++-v3/src/.libs -L/home/max/build/master/x86_64-unknown-linux-gnu/./libstdc++-v3/src/.libs -B/home/max/build/master/x86_64-unknown-linux-gnu/./libitm/ -L/home/max/build/master/x86_64-unknown-linux-gnu/./libitm/.libs -lm -o ./pr69826-2.exe = ==32062==ERROR: AddressSanitizer: dynamic-stack-buffer-overflow on address 0x7ffc9059d2cc at pc 0x0044fc2c bp 0x7ffc9059d250 sp 0x7ffc9059ca00 READ of size 13 at 0x7ffc9059d2cc thread T0 #0 0x44fc2b in __interceptor_memcpy /home/max/workspace/downloads/gcc/libsanitizer/asan/asan_interceptors.cc:436 #1 0x4e1397 in save_string /home/max/workspace/downloads/gcc/gcc/gcc.c:8368 #2 0x4f3027 in do_spec_1 /home/max/workspace/downloads/gcc/gcc/gcc.c:5423 #3 0x4f60f4 in process_brace_body /home/max/workspace/downloads/gcc/gcc/gcc.c:6431 #4 0x4f60f4 in handle_braces /home/max/workspace/downloads/gcc/gcc/gcc.c:6345 #5 0x4f2eb7 in do_spec_1 /home/max/workspace/downloads/gcc/gcc/gcc.c:5802 #6 0x4f60f4 in process_brace_body /home/max/workspace/downloads/gcc/gcc/gcc.c:6431 #7 0x4f60f4 in handle_braces /home/max/workspace/downloads/gcc/gcc/gcc.c:6345 #8 0x4f2eb7 in do_spec_1 /home/max/workspace/downloads/gcc/gcc/gcc.c:5802 #9 0x4f1a91 in do_spec_1 /home/max/workspace/downloads/gcc/gcc/gcc.c:5917 #10 0x4f60f4 in process_brace_body /home/max/workspace/downloads/gcc/gcc/gcc.c:6431 #11 0x4f60f4 in handle_braces /home/max/workspace/downloads/gcc/gcc/gcc.c:6345 #12 0x4f2eb7 in do_spec_1 /home/max/workspace/downloads/gcc/gcc/gcc.c:5802 #13 0x4f60f4 in process_brace_body /home/max/workspace/downloads/gcc/gcc/gcc.c:6431 #14 0x4f60f4 in handle_braces /home/max/workspace/downloads/gcc/gcc/gcc.c:6345 #15 0x4f2eb7 in do_spec_1 /home/max/workspace/downloads/gcc/gcc/gcc.c:5802 #16 0x4f60f4 in process_brace_body /home/max/workspace/downloads/gcc/gcc/gcc.c:6431 #17 0x4f60f4 in handle_braces /home/max/workspace/downloads/gcc/gcc/gcc.c:6345 #18 0x4f2eb7 in do_spec_1 /home/max/workspace/downloads/gcc/gcc/gcc.c:5802 #19 0x4f60f4 in process_brace_body /home/max/workspace/downloads/gcc/gcc/gcc.c:6431 #20 0x4f60f4 in handle_braces /home/max/workspace/downloads/gcc/gcc/gcc.c:6345 #21 0x4f2eb7 in do_spec_1 /home/max/workspace/downloads/gcc/gcc/gcc.c:5802 #22 0x4f474b in do_spec_2 /home/max/workspace/downloads/gcc/gcc/gcc.c:4841 #23 0x4f719e in do_spec(char const*) /home/max/workspace/downloads/gcc/gcc/gcc.c:4808 #24 0x4f74fe in driver::do_spec_on_infiles() const /home/max/workspace/downloads/gcc/gcc/gcc.c:8076 #25 0x406e59 in driver::main(int, char**) /home/max/workspace/downloads/gcc/gcc/gcc.c:7216 #26 0x407747 in main /home/max/workspace/downloads/gcc/gcc/gcc-main.c:46 #27 0x7f1513415ec4 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21ec4) #28 0x408509 (/home/max/build/master/gcc/xg+++0x408509) Address 0x7ffc9059d2cc is located in stack of thread T0 SUMMARY: AddressSanitizer: dynamic-stack-buffer-overflow /home/max/workspace/downloads/gcc/libsanitizer/asan/asan_interceptors.cc:436 in __interceptor_memcpy Shadow bytes around the buggy address: 0x1000120aba00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1000120aba10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1000120a
[Bug tree-optimization/65391] missed store motion for conditionally updated pointer in loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65391 --- Comment #5 from Richard Biener --- Note the easiest way out is to use the existing infrastructure to avoid store-data-races. But that only works when there is no (possibly trapping) load as we need to materialize a value for the register on loop entry. The non-trappingness is currently recorded on a BB basis and not tracked per reference so it's not easy to fix that part without a major rewrite in that area.
[Bug sanitizer/71042] libtsan requires __pointer_chk_guard@GLIBC_PRIVATE (6)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71042 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-08-01 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Marek Polacek --- We see this, too.
[Bug sanitizer/71042] libtsan requires __pointer_chk_guard@GLIBC_PRIVATE (6)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71042 --- Comment #4 from Richard Biener --- Btw, the solution for me was to disable tsan for aarch64.
[Bug sanitizer/71042] libtsan requires __pointer_chk_guard@GLIBC_PRIVATE (6)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71042 --- Comment #5 from Marek Polacek --- Thanks, I think I'll follow suit for the time being.
[Bug c++/72766] New: tree check fail in get_len, at tree.h:5303
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72766 Bug ID: 72766 Summary: tree check fail in get_len, at tree.h:5303 Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- Created attachment 39038 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39038&action=edit gzipped C++ source code The attached C++ code, when compiled by gcc trunk dated 20160801, does this: samplv1_jack.cpp: In member function ‘void samplv1_jack::alsa_capture(snd_seq_event_t*)’: samplv1_jack.cpp:563:66: internal compiler error: tree check: expected integer_cst, have nop_expr in get_len, at tree.h:5303 0x1132d5c tree_check_failed(tree_node const*, char const*, int, char const*, ...) ../../src/trunk/gcc/tree.c:9742 0x8b62d1 tree_check(tree_node const*, char const*, int, char const*, tree_code) ../../src/trunk/gcc/tree.h:3279 0x8b62d1 wi::extended_tree<192>::get_len() const ../../src/trunk/gcc/tree.h:5303 0x8b62d1 wi::int_traits > >::decompose(long*, unsigned int, generic_wide_int > const&) ../../src/trunk/gcc/wide-int.h:929 0x8b62d1 wide_int_ref_storage::wide_int_ref_storage > >(generic_wide_int > const&, unsigned int)
[Bug c/63886] float will fit into int with abs - possible missing warning Wabsolute-value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63886 --- Comment #11 from Eric Gallager --- (In reply to Manuel López-Ibáñez from comment #10) > (In reply to Eric Gallager from comment #8) > > (In reply to Andreas Schwab from comment #4) > > > float f = 3.1f; > > > > Isn't there already -Wunsuffixed-float-constants for warnings with that kind > > of fix? > > -Wfloat-conversion is not warning about the lack of suffix, but about the > fact that 3.1 does not fit into a double (3.5 does, so there is no warning). > > float f; > double d; > > f = 3.100088817841970012523233890533447265625; // > -Wfloat-conversion -Wunsuffixed-float-constants > d = 3.100088817841970012523233890533447265625; // > -Wunsuffixed-float-constants (not sure why!) > f = 3.5; // -Wunsuffixed-float-constants > d = 3.5; // -Wunsuffixed-float-constants (not sure why!) > f = 3.1f; // no warning > d = 3.1f; // no warning About the ones where you wrote "(not sure why!)", it's asking the programmer to add the nonstandard "d" suffix, which is a GNU extension. This has led projects to ignore the warning: https://lists.gnu.org/archive/html/bug-gzip/2011-11/msg00017.html But I suppose that's an issue for a separate bug.
[Bug target/72767] New: [avr] Some branches report too small insn length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72767 Bug ID: 72767 Summary: [avr] Some branches report too small insn length Product: gcc Version: 5.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: gjl at gcc dot gnu.org Target Milestone: --- Created attachment 39039 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39039&action=edit nops.c: C test case Some branch instructions report too small instruction length which might lead to problems if other branches crossing the critical ones use a wrong instruction sequence. Outcome can be "relocation truncted to fit" error from the linker. Compile test case with $ avr-gcc -S -dp -Os -mmcu=atmega16 nops.c In bra_63 there is (should be "length = 2"): brne .+2 ; 7 branch [length = 1] rjmp .L1 In bra_2045 (should be "length = 3"): brne .+4 ; 7 branch [length = 2] jmp .L6
[Bug target/72767] [avr] Some branches report too small insn length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72767 Georg-Johann Lay changed: What|Removed |Added Target||avr Priority|P3 |P4 Assignee|unassigned at gcc dot gnu.org |gjl at gcc dot gnu.org
[Bug target/72767] [avr] Some branches report too small insn length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72767 --- Comment #1 from Georg-Johann Lay --- Author: gjl Date: Mon Aug 1 12:36:11 2016 New Revision: 238948 URL: https://gcc.gnu.org/viewcvs?rev=238948&root=gcc&view=rev Log: PR target/72767 * config/avr/avr.md (length) [branch]: Correct insn length attribute for forward branches. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr.md
[Bug c++/72766] [7 Regression] tree check fail in get_len, at tree.h:5303
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72766
Markus Trippelsdorf changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2016-08-01
CC||trippels at gcc dot gnu.org
Summary|tree check fail in get_len, |[7 Regression] tree check
|at tree.h:5303 |fail in get_len, at
||tree.h:5303
Ever confirmed|0 |1
--- Comment #1 from Markus Trippelsdorf ---
long fn1() {
const int a = fn1();
int b[a];
int c = *(&b[0] + sizeof(0));
}
[Bug target/72767] [avr] Some branches report too small insn length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72767 --- Comment #2 from Georg-Johann Lay --- Author: gjl Date: Mon Aug 1 12:40:41 2016 New Revision: 238949 URL: https://gcc.gnu.org/viewcvs?rev=238949&root=gcc&view=rev Log: Backport from 2016-08-01 trunk r238948. PR target/72767 * config/avr/avr.md (length) [branch]: Correct insn length attribute for forward branches. Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/config/avr/avr.md
[Bug target/71805] incorrect code for test pr45752.c with -mcpu=power9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71805 --- Comment #8 from acsawdey at gcc dot gnu.org --- *** Bug 71722 has been marked as a duplicate of this bug. ***
[Bug target/71722] incorrect code for test pr64252.c for -mcpu=power9 -mpower9-vector -ftree-vectorize -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71722 acsawdey at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #5 from acsawdey at gcc dot gnu.org --- Meissner's fix for 71805 also fixes this one. *** This bug has been marked as a duplicate of bug 71805 ***
[Bug target/72767] [avr] Some branches report too small insn length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72767 --- Comment #3 from Georg-Johann Lay --- Author: gjl Date: Mon Aug 1 12:44:18 2016 New Revision: 238950 URL: https://gcc.gnu.org/viewcvs?rev=238950&root=gcc&view=rev Log: Backport from 2016-08-01 trunk r238948. PR target/72767 * config/avr/avr.md (length) [branch]: Correct insn length attribute for forward branches. Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/config/avr/avr.md
[Bug target/72767] [avr] Some branches report too small insn length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72767 Georg-Johann Lay changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Version|5.2.0 |5.4.0 Resolution|--- |FIXED Target Milestone|--- |5.4 --- Comment #4 from Georg-Johann Lay --- Fixed for 5.5 and 6.2+.
[Bug tree-optimization/71857] [7 Regression] gcc.dg/tree-ssa/ivopt_mult_4.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71857 --- Comment #5 from Martin Liška --- Author: marxin Date: Mon Aug 1 13:31:24 2016 New Revision: 238953 URL: https://gcc.gnu.org/viewcvs?rev=238953&root=gcc&view=rev Log: Change dump expectation in PR71857 PR tree-optimization/71857 * gcc.dg/tree-ssa/ivopt_mult_4.c: Change expectation. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/ivopt_mult_4.c
[Bug c++/72766] [7 Regression] tree check fail in get_len, at tree.h:5303
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72766 Markus Trippelsdorf changed: What|Removed |Added Keywords||ice-on-valid-code CC||jason at gcc dot gnu.org --- Comment #2 from Markus Trippelsdorf --- Started with r238559.
[Bug tree-optimization/71857] [7 Regression] gcc.dg/tree-ssa/ivopt_mult_4.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71857 Martin Liška changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Martin Liška --- Fixed.
[Bug c++/72766] [7 Regression] tree check fail in get_len, at tree.h:5303
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72766 Richard Biener changed: What|Removed |Added Target Milestone|--- |7.0
[Bug c++/72766] [7 Regression] tree check fail in get_len, at tree.h:5303
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72766
--- Comment #3 from Richard Biener ---
#11 0x00a7d226 in cxx_eval_pointer_plus_expression (
ctx=0x7fffd200, t=, lval=false,
non_constant_p=0x7fffd237, overflow_p=0x7fffd236)
at /space/rguenther/src/svn/trunk/gcc/cp/constexpr.c:3585
3585 if (!tree_int_cst_le (t, nelts))
(gdb) l
3580{
3581 tree type = TREE_TYPE (op00);
3582 t = fold_convert_loc (loc, ssizetype, TREE_OPERAND (op00, 1));
3583 tree nelts = array_type_nelts_top (TREE_TYPE (TREE_OPERAND (op00,
0)));
3584 /* Don't fold an out-of-bound access. */
3585 if (!tree_int_cst_le (t, nelts))
3586return NULL_TREE;
3587 op01 = cp_fold_convert (ssizetype, op01);
3588 /* Don't fold if op01 can't be divided exactly by TYPE_SIZE_UNIT.
3589 constexpr int A[1]; ... (char *)&A[0] + 1 */
(gdb) p t
$1 =
(gdb) p nelts
$2 =
[Bug gcov-profile/69004] Building t-engine on ARM fails during -fprofile-use stage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69004 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #17 from Martin Liška --- (In reply to PeteVine from comment #16) > I've just read 4.9.4 is to be released soon - any chance of landing a fix > for this issue? Hello. I would like to help you with the issues you have. I've just tried to build LuaJIT (https://github.com/LuaJIT) with PGO and it works fine (using LuaJIT-test-cleanup as training input). Can you please send me link to project you're trying, as well as reproduce steps I can do?
[Bug tree-optimization/71818] [7 Regression] ICE in as_a, at is-a.h:192 w/ -O2 -ftree-vectorize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71818 --- Comment #1 from alahay01 at gcc dot gnu.org --- Author: alahay01 Date: Mon Aug 1 14:33:23 2016 New Revision: 238955 URL: https://gcc.gnu.org/viewcvs?rev=238955&root=gcc&view=rev Log: 2016-08-01 Alan Hayward gcc/ PR tree-optimization/71818 * tree-vect-loop-manip.c (vect_can_advance_ivs_p): Don't advance IVs with non invariant evolutions testsuite/ PR tree-optimization/71818 * gcc.dg/vect/pr71818.c: New Added: trunk/gcc/testsuite/gcc.dg/vect/pr71818.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-loop-manip.c
[Bug tree-optimization/71818] [7 Regression] ICE in as_a, at is-a.h:192 w/ -O2 -ftree-vectorize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71818 alahay01 at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from alahay01 at gcc dot gnu.org --- Fixed. Allowing a non-invariant step to be incremented using vect_can_advance_ivs_p was causing: 1) Incorrect vectorisation of the IV and 2) Loop closed SSA to be broken (the step was being used outside the loop directly instead of via a PHI). The ICE was caused because vectorisable_live_operation was expecting the loop to be in loop closed SSA.
[Bug target/72748] [7 Regression] ICE on valid code at -O2 and -O3 with -g enabled in 64-bit mode on x86_64-linux-gnu: in simplify_subreg, at simplify-rtx.c:5952
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72748 --- Comment #3 from hjl at gcc dot gnu.org --- Author: hjl Date: Mon Aug 1 14:46:01 2016 New Revision: 238956 URL: https://gcc.gnu.org/viewcvs?rev=238956&root=gcc&view=rev Log: Convert V1TImode register to TImode in debug insn TImode register referenced in debug insn can be converted to V1TImode by scalar to vector optimization. When converting a TImode store to V1TImode, we need to check all debug insns on its use chain to convert the V1TImode register to SUBREG TImode if source register is undefined. gcc/ PR target/72748 * config/i386/i386.c (timode_scalar_chain::convert_insn): Call fix_debug_reg_uses after changing source register mode to V1TImode if source register is undefined. gcc/testsuite/ PR target/72748 * gcc.target/i386/pr72748.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr72748.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog
[Bug target/72748] [7 Regression] ICE on valid code at -O2 and -O3 with -g enabled in 64-bit mode on x86_64-linux-gnu: in simplify_subreg, at simplify-rtx.c:5952
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72748 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from H.J. Lu --- Fixed.
[Bug c++/72768] New: Potential bug about the order of destructors of static objects and atexit() callbacks in C++?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72768
Bug ID: 72768
Summary: Potential bug about the order of destructors of static
objects and atexit() callbacks in C++?
Product: gcc
Version: 6.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lh_mouse at 126 dot com
Target Milestone: ---
Created attachment 39040
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39040&action=edit
The testcase in question.
Reading the ISO C++ standard,
> 3.6.4 Termination [basic.start.term]
> 3 If the completion of the initialization of an object with
> static storage duration is sequenced before a call to std::atexit
> (see , 18.5), the call to the function passed to std::atexit
> is sequenced before the call to the destructor for the object. ...
Notwithstanding the vagueness of 'the completion of the initialization of an
object',
the following program:
#include
#include
enum class state {
null,
initialized,
destroyed,
};
extern void broken_atexit();
struct global_data {
state s;
global_data()
: s(state::null)
{
std::puts("delegated constructor");
}
global_data(int)
: global_data()
{
s = state::initialized;
std::atexit(&broken_atexit);
std::puts("delegating constructor");
}
~global_data(){
s = state::destroyed;
}
} data(1);
void broken_atexit(){
if(data.s == state::destroyed){
std::puts("attempt to use a destroyed object?");
std::abort();
}
std::puts("okay");
}
int main(){
}
, when compiled with GCC, results in use of a destroyed object:
lh_mouse@lhmouse-dev:~$ g++ test.cc -std=c++11
lh_mouse@lhmouse-dev:~$ ./a.out
delegated constructor
delegating constructor
attempt to use a destroyed object?
Aborted
lh_mouse@lhmouse-dev:~$
The reason of this problem is that GCC front-end registers the dtor after
the delegating constructor returns, which is invoked before the other
callback registered inside the delegating constructor body.
The problem would be gone only if the GCC front-end registers the dtor after
the delegated constructor returns.
Is this a GCC bug?
[Bug c++/72766] [7 Regression] tree check fail in get_len, at tree.h:5303
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72766 --- Comment #4 from Jason Merrill --- Author: jason Date: Mon Aug 1 15:01:03 2016 New Revision: 238957 URL: https://gcc.gnu.org/viewcvs?rev=238957&root=gcc&view=rev Log: PR c++/72766 - ICE with VLA * constexpr.c (cxx_eval_pointer_plus_expression): Check constancy of nelts. * cp-gimplify.c (cp_fully_fold): Only maybe_constant_value in C++11 and up. Added: trunk/gcc/testsuite/g++.dg/ext/vla16.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/constexpr.c trunk/gcc/cp/cp-gimplify.c
[Bug c++/72752] [6 Regression] ICE: in retrieve_specialization, at cp/pt.c:1183
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72752 --- Comment #4 from Jason Merrill --- Yeah, that work isn't safe enough to backport.
[Bug c++/72766] [7 Regression] tree check fail in get_len, at tree.h:5303
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72766 Jason Merrill changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org --- Comment #5 from Jason Merrill --- Fixed.
[Bug c++/72769] New: ifstream Optimed Out ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72769
Bug ID: 72769
Summary: ifstream Optimed Out ?
Product: gcc
Version: 6.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: roy at chameleon dot ad
Target Milestone: ---
Created attachment 39041
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39041&action=edit
the ii file
This is my first bug report so be patient!
g++ version is 6.1.1 20160707 [gcc-6-branch revision 238088]
Full compilation flag are those
https://gist.github.com/RoyBellingan/be151f3d22e7e0a50143d5dde622baba
System type is uname --all
Linux linux-gzgr 4.6.2-1-default #1 SMP PREEMPT Fri Jun 10 08:12:44 UTC 2016
(2a68ef0) x86_64 x86_64 x86_64 GNU/Linux
The invocation line is
g++-6 -save-temps -O2 campaigns/1350_tmp.cpp -std=c++11 -g -o
campaigns/1350_3.so -shared -fPIC -Wall -Wconversion -Wsign-compare
-pedantic-errors -I data/
Output given is
https://gist.github.com/RoyBellingan/7c09b6bf8908f62b9052575bf14cf43d just some
warning of non used variable (this code is create dynamically and loaded via
dlopen)
The .ii file is attached
In short the at line 37937 of the ii file
while (infile >> a){
fails because a is set to 0 WHEN the compiler is invoked with O2 (and also with
O1)
If I use O0 a is assigned the correct value ...
For now a "fix" is to force swap the first line in a std:string (the two empty
line at 37935 & 37936
unsigned long long a;
std::ifstream infile("campaigns/1350_ids");
std::string cry;
infile >> cry;
while (infile >> a){
ids.insert(std::pair(a,1));
}
The 1350_ids file contains a list of id to check some rows are here
https://gist.github.com/RoyBellingan/8dcde8d63001dfcd438ccf9921f60627
Hope is enought!
[Bug c++/72769] ifstream Optimed Out ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72769 Markus Trippelsdorf changed: What|Removed |Added CC||trippels at gcc dot gnu.org --- Comment #1 from Markus Trippelsdorf --- Please try to reduce the issue as much as possible. 37978 lines is much too large. A library is unusable for testing. Please provide a standalone testcase (with "int main()", that can be run directly.). Also try to compile and run with -fsanitize=undefined and see if anything pops up.
[Bug c/7652] -Wswitch-break : Warn if a switch case falls through
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652 --- Comment #55 from Marek Polacek --- Author: mpolacek Date: Mon Aug 1 16:03:41 2016 New Revision: 238958 URL: https://gcc.gnu.org/viewcvs?rev=238958&root=gcc&view=rev Log: PR c/7652 * config/i386/i386.c (ix86_expand_args_builtin): Add break. (ix86_expand_round_builtin): Likewise. Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/config/i386/i386.c
[Bug target/71948] [avr] Make progmem work on reduced Tiny cores by adding 0x4000 to symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71948 --- Comment #3 from Georg-Johann Lay --- Author: gjl Date: Mon Aug 1 17:12:32 2016 New Revision: 238961 URL: https://gcc.gnu.org/viewcvs?rev=238961&root=gcc&view=rev Log: PR target/71948 * config/avr/avr.c (AVR_SYMBOL_FLAG_TINY_PM): Use a value that does not overlap with other symbol flags. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr.c
[Bug rtl-optimization/69847] Spec 2006 403.gcc slows down with -mlra vs. reload on PowerPC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69847 --- Comment #16 from Bill Schmidt --- Hi Vlad, I need to re-run my tests one more time because I goofed up the build on a few of them; however, I was able to verify that the degradation on 403.gcc has now gone away (I saw a slight improvement with lra over reload with your patch). I'll check back in tomorrow with full results, but for now it looks like you nailed the problem, and the overall results with lra are tentatively looking quite good. Thanks! Bill
[Bug gcov-profile/69004] Building t-engine on ARM fails during -fprofile-use stage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69004 --- Comment #18 from PeteVine --- Great, thanks! Now, as I mentioned in one of previous comments, the same t-engine build procedure works fine on x86, so we can be fairly certain I didn't break anything. The large amount of physfs/luajit profile data probably leads to some sort of corruption on ARM. I'm going to write down the steps after trying to reproduce this again myself. I've got gcc 6.1.1 and 7.0.0 from a week ago, apart from 4.9 and 5.3 - which version would you prefer to see used? (better debugging tips welcome)
[Bug fortran/72770] New: ICE in make_ssa_name_fn, at tree-ssanames.c:263
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72770 Bug ID: 72770 Summary: ICE in make_ssa_name_fn, at tree-ssanames.c:263 Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- ICE with valid examples and experimental (--enable-checking=yes) version 7 from 20160731 at -Os, -O1 or higher. $ cat z1.f90 program p type t class(*), allocatable :: q(:) end type type(t) :: z integer :: a(3) = [1, 2, 3] character(2) :: c(3) = ['ab', 'ef', 'ih'] allocate (z%q(3), source=a) call s contains subroutine s select type (x => z%q) type is (integer) if ( any(x/=a) ) call abort type is (character(len=*)) if ( any(x/=c) ) call abort end select end end $ cat z2.f90 program p type t class(*), allocatable :: q(:) end type type(t) :: z integer :: a(3) = [1, 2, 3] character(2) :: c(3) = ['ab', 'ef', 'ih'] allocate (z%q(3), source=c) call s contains subroutine s select type (x => z%q) type is (integer) if ( any(x/=a) ) call abort type is (character(len=*)) if ( any(x/=c) ) call abort end select end end $ gfortran-7-20160731 -O2 z1.f90 z1.f90:9:0: call s internal compiler error: Segmentation fault 0xc1436f crash_signal ../../gcc/toplev.c:335 0xe1fe21 make_ssa_name_fn(function*, tree_node*, gimple*) ../../gcc/tree-ssanames.c:263 0xc8a3ac make_ssa_name ../../gcc/tree-ssanames.h:111 0xc8a3ac remap_ssa_name ../../gcc/tree-inline.c:238 0xc90afc copy_tree_body_r(tree_node**, int*, void*) ../../gcc/tree-inline.c:1083 0xec5c12 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*, tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*)) ../../gcc/tree.c:11646 0xec6066 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*, tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*)) ../../gcc/tree.c:11962 0xc89218 remap_type_1 ../../gcc/tree-inline.c:562 0xc899a1 remap_type(tree_node*, copy_body_data*) ../../gcc/tree-inline.c:591 0xc88974 remap_type_1 ../../gcc/tree-inline.c:416 0xc899a1 remap_type(tree_node*, copy_body_data*) ../../gcc/tree-inline.c:591 0xc913f8 remap_gimple_op_r ../../gcc/tree-inline.c:994 0xec5c12 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*, tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*)) ../../gcc/tree.c:11646 0x99e440 walk_gimple_op(gimple*, tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*) ../../gcc/gimple-walk.c:203 0xc8b2dc remap_gimple_stmt ../../gcc/tree-inline.c:1733 0xc8c4ce copy_bb ../../gcc/tree-inline.c:1791 0xc8d958 copy_cfg_body ../../gcc/tree-inline.c:2736 0xc8d958 copy_body ../../gcc/tree-inline.c:2976 0xc93e21 expand_call_inline ../../gcc/tree-inline.c:4717 0xc95154 gimple_expand_calls_inline ../../gcc/tree-inline.c:4862
[Bug fortran/72770] ICE in make_ssa_name_fn, at tree-ssanames.c:263
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72770 --- Comment #1 from Gerhard Steinmetz --- Compiles and works without character branch (type is). $ cat z3.f90 program p type t class(*), allocatable :: q(:) end type type(t) :: z integer :: a(3) = [1, 2, 3] real :: c(3) = [1.0, 2.0, 3.0] allocate (z%q(3), source=c) call s contains subroutine s select type (x => z%q) type is (integer) if ( any(x/=a) ) call abort type is (real) if ( any(x/=c) ) call abort end select end end $ gfortran-7-20160731 -O2 z3.f90 $ a.out
[Bug c++/72768] Potential bug about the order of destructors of static objects and atexit() callbacks in C++?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72768 --- Comment #1 from Jonathan Wakely --- (In reply to lh_mouse from comment #0) > Notwithstanding the vagueness of 'the completion of the initialization of an > object', The question hinges entirely on the definition of that term. Arguably the object is not completely initialized until the principal constructor returns. And as pointed out on the mailing list, other compilers do the same.
[Bug c++/68159] Demangler crash (GDB PR 19190)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68159 --- Comment #10 from Carlos Alberto Lopez Perez --- It seems c++filt also crashes with the very same test case: $ echo '_ZSt7forwardIRKZN5Write14DataMapGrammarISt20back_insert_iteratorISsEEC4EvEUlRT_E_EOS5_RNSt16remove_referenceIS5_E4typeE'|c++filt Segmentation fault (core dumped)
[Bug c++/68383] Demangler stack overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68383 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #11 from H.J. Lu --- Dup *** This bug has been marked as a duplicate of bug 68159 ***
[Bug c++/68159] Demangler crash (GDB PR 19190)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68159 --- Comment #11 from H.J. Lu --- *** Bug 68383 has been marked as a duplicate of this bug. ***
[Bug c++/68159] Demangler crash (GDB PR 19190)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68159 --- Comment #12 from H.J. Lu --- Created attachment 39042 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39042&action=edit A patch to avoid stack oveflow
[Bug middle-end/64396] Missed optimization in post-loop register handling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64396 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Severity|minor |enhancement
[Bug debug/63240] DWARF does not represent C++ defaulted methods
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63240 Alexandre Oliva changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-08-01 CC||aoliva at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Alexandre Oliva --- Created attachment 39043 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39043&action=edit Patch I'm testing to address the enhancement request Mine
[Bug c++/68383] Demangler stack overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68383
--- Comment #12 from H.J. Lu ---
Created attachment 39044
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39044&action=edit
A patch
This gives:
Write::DataMapGrammar, std::allocator > >
>::DataMapGrammar()::{lambda()#1} const&
std::forward, std::allocator > >
>::DataMapGrammar()::{lambda()#1}
const&>(std::remove_reference, std::allocator > >
>::DataMapGrammar()::{lambda()#1} const&>::type&)
No idea if it is correct.
[Bug c++/68383] Demangler stack overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68383 H.J. Lu changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|DUPLICATE |--- --- Comment #13 from H.J. Lu --- Not a dup.
[Bug c++/68159] Demangler crash (GDB PR 19190)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68159 --- Comment #13 from Carlos Alberto Lopez Perez --- (In reply to H.J. Lu from comment #12) > Created attachment 39042 [details] > A patch to avoid stack oveflow This fixes the issue with the previous test case. However, this other one (obtained from a coredump of WebKitGTK+) is still crashing: $ echo '_ZSt7forwardIRZZN6WebKit29NetworkConnectionToWebProcess26writeBlobsToTemporaryFilesERKN3WTF6VectorINS2_6StringELm0ENS2_15CrashOnOverflowELm16EEEmENUlRT_E_clIS7_EEDaSA_EUlvE_EOS9_RNSt16remove_referenceIS9_E4typeE' | c++filt Segmentation fault (core dumped)
[Bug c++/72768] Potential bug about the order of destructors of static objects and atexit() callbacks in C++?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72768 --- Comment #2 from lh_mouse --- (In reply to Jonathan Wakely from comment #1) > Arguably the object is not completely initialized until the principal > constructor returns. I doubt it. If an exception is thrown inside the principal ctor which delegates to another one, the dtor is called. It doesn't make sense to call a dtor on an object that has not been completely initialized. (A public target ctor and a private one have different semantical purposes, but it is a different story.)
[Bug debug/49366] pointer-to-member-function not given value in DW_TAG_template_value_param
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49366 Alexandre Oliva changed: What|Removed |Added CC||aoliva at gcc dot gnu.org Assignee|dodji at gcc dot gnu.org |aoliva at gcc dot gnu.org --- Comment #3 from Alexandre Oliva --- Created attachment 39045 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39045&action=edit Patch I posted to gcc-patches Mine
[Bug debug/55641] debug info for the type of a reference declared with a typedef has spurious 'const'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55641 Alexandre Oliva changed: What|Removed |Added Status|NEW |ASSIGNED CC||aoliva at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot gnu.org --- Comment #11 from Alexandre Oliva --- Created attachment 39046 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39046&action=edit Patch I'm testing to address the enhancement request Mine
[Bug rtl-optimization/68898] [6 Regression] ICE if rtl if-conversion is off.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68898 Andrew Pinski changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |6.0 Summary|ICE if rtl if-conversion is |[6 Regression] ICE if rtl |off.|if-conversion is off. --- Comment #4 from Andrew Pinski --- Fixed.
[Bug target/72771] New: powerpc64le ICE with -mcpu=power9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72771
Bug ID: 72771
Summary: powerpc64le ICE with -mcpu=power9
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: anton at samba dot org
CC: amodra at gcc dot gnu.org, meissner at gcc dot gnu.org,
segher at gcc dot gnu.org, wschmidt at gcc dot gnu.org
Target Milestone: ---
Target: powerpc64le-linux
The following test case:
void fn2(void);
void fn3(unsigned long);
signed char a;
int b, c, e, f;
float *d;
void fn1(void) {
short g = 0;
lbl_986:
for (;;) {
c = 0;
for (; c <= 2;) {
*d = g;
fn2();
if (e)
goto lbl_986;
}
g = 2;
for (; g >= 0; g--) {
for (; b;) {
fn3(45360);
f = 0;
for (; a >= 0; a--)
;
}
}
}
}
Built with:
gcc -O3 -mcpu=power9
Hits an ICE:
crash1.i:29:1: error: insn does not satisfy its constraints:
}
^
(insn 316 362 349 38 (parallel [
(set (reg:SF 63 31 [orig:334 _48 ] [334])
(float:SF (mem/u/c:HI (lo_sum:DI (reg:DI 6 6)
(unspec:DI [
(symbol_ref/u:DI ("*.LC14") [flags 0x2])
(reg:DI 2 2)
] UNSPEC_TOCREL)) [6 S2 A16])))
(clobber (reg:DI 77 0))
(clobber (scratch:DI))
]) 350 {*floathisf2_internal}
(expr_list:REG_EQUAL (const_double:SF -1.0e+0 [-0x0.8p+1])
(nil)))
crash1.i:29:1: internal compiler error: in extract_constrain_insn, at
recog.c:2211
0x10839993 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc/gcc/rtl-error.c:108
0x108399eb _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../gcc/gcc/rtl-error.c:119
0x107ff5f7 extract_constrain_insn(rtx_insn*)
../../gcc/gcc/recog.c:2211
0x107ce263 reload_cse_simplify_operands
../../gcc/gcc/postreload.c:390
0x107cfe43 reload_cse_simplify
../../gcc/gcc/postreload.c:176
0x107cfe43 reload_cse_regs_1
../../gcc/gcc/postreload.c:215
0x107d1737 reload_cse_regs
../../gcc/gcc/postreload.c:67
0x107d1737 execute
../../gcc/gcc/postreload.c:2342
[Bug c++/72768] Potential bug about the order of destructors of static objects and atexit() callbacks in C++?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72768 --- Comment #3 from lh_mouse --- > 15.2 Constructors and destructors [except.ctor] > 3 For an object of class type of any storage duration whose initialization or > destruction is terminated by an > exception, the destructor is invoked for each of the object’s fully > constructed subobjects, that is, for each > subobject for which the principal constructor (12.6.2) has completed > execution and the destructor has not > yet begun execution, except that in the case of destruction, the variant > members of a union-like class are not > destroyed. ... Strangely enough, the standard says 'fully constructed' instead of 'completely initialized' here. I tend to consider it a symbol indicating that the committee think the two phrases are distinct from each other. From my point of view, the object is 'completely initialized' once a (delegated or non-delegated, including principle) ctor returns - if an exception is thrown, the dtor shall be called -, despite the principal ctor in progress. The antonym of 'completely initialized' should be 'partially initialized', being in a state when the ctor of a subobject throws an exception， which is not the case here.
[Bug middle-end/65950] function becomes unlikely with -fwhole-program
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65950 Andrew Pinski changed: What|Removed |Added Component|lto |middle-end Summary|Loop is not vectorized |function becomes unlikely |with lto. |with -fwhole-program --- Comment #7 from Andrew Pinski --- (In reply to Richard Biener from comment #3) > Do we eventually think the loop is cold? Looks like we think the function is cold: unlikely_executed. Note -fwhole-program is enough to have it also become unlikely.
[Bug middle-end/65950] exit in main is causing the path to it to become unlikely.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65950 Andrew Pinski changed: What|Removed |Added Summary|function becomes unlikely |exit in main is causing the |with -fwhole-program|path to it to become ||unlikely. --- Comment #8 from Andrew Pinski --- Ok, the problem is the exit function call is causing the path to it becoming unlikely. That is change the exit to return and you get the optimization back. Basically an exit with a argument equal to 0 should not be considered as unlikely but a standard exit from the program.
[Bug middle-end/65950] exit in main is causing the path to it to become unlikely.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65950 --- Comment #9 from Andrew Pinski --- Basically this code in predict.c: if ((gimple_call_flags (stmt) & ECF_NORETURN) && has_return_edges) predict_paths_leading_to (bb, PRED_NORETURN, NOT_TAKEN); Needs to check if this is a BUILT_IN_EXIT, BUILT_IN__EXIT or BUILT_IN__EXIT2 and if the argument is a constant value of 0, don't predict it as not taken. After dinner I can code something up.
[Bug c++/67692] [concepts] ICE when using requires in non-concept contexts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67692 Andrew Pinski changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2016-08-02 Ever confirmed|0 |1 Known to fail||7.0 --- Comment #1 from Andrew Pinski --- Confirmed: t55.cc: In instantiation of 'bool f(T) [with T = int]': t55.cc:9:6: required from here t55.cc:6:1: internal compiler error: tree check: expected tree that contains 'typed' structure, have 'simple_req' in cp_fold, at cp/cp-gimplify.c:2049 } ^ 0xfc2eab tree_contains_struct_check_failed(tree_node const*, tree_node_structure_enum, char const*, int, char const*) ../../gcc/gcc/tree.c:9914 0x808617 contains_struct_check(tree_node*, tree_node_structure_enum, char const*, int, char const*) ../../gcc/gcc/tree.h:3137 0x808617 cp_fold ../../gcc/gcc/cp/cp-gimplify.c:2075 0x808a9f cp_fold_r ../../gcc/gcc/cp/cp-gimplify.c:1013
[Bug c++/67545] [concepts] Failure to properly substitute template parameters into requires-clause
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67545 Andrew Pinski changed: What|Removed |Added Severity|major |normal
[Bug c++/67571] Error: open CFI at the end of file; missing .cfi_endproc directive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67571 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #12 from Andrew Pinski --- No testcase in over 9 months so closing as invalid.
[Bug middle-end/65950] exit in main is causing the path to it to become unlikely.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65950
Andrew Pinski changed:
What|Removed |Added
CC||pinskia at gcc dot gnu.org
--- Comment #10 from Andrew Pinski ---
Something like:
diff --git a/gcc/predict.c b/gcc/predict.c
index f2b50be..0a571c5 100644
--- a/gcc/predict.c
+++ b/gcc/predict.c
@@ -2081,6 +2081,19 @@ tree_predict_by_opcode (basic_block bb)
}
}
+static bool
+is_exit_with_zero_arg (const gimple *stmt)
+{
+ /* This is not exit, _exit or _Exit. */
+ if (!gimple_call_builtin_p (stmt, BUILT_IN_EXIT)
+ && !gimple_call_builtin_p (stmt, BUILT_IN__EXIT)
+ && !gimple_call_builtin_p (stmt, BUILT_IN__EXIT2))
+return false;
+
+ /* Argument is an interger zero. */
+ return integer_zerop (gimple_call_arg (stmt, 0));
+}
+
/* Try to guess whether the value of return means error code. */
static enum br_predictor
@@ -2208,7 +2221,8 @@ tree_bb_level_predictions (void)
if (is_gimple_call (stmt))
{
if ((gimple_call_flags (stmt) & ECF_NORETURN)
- && has_return_edges)
+ && has_return_edges
+ && !is_exit_with_zero_arg (stmt))
predict_paths_leading_to (bb, PRED_NORETURN,
NOT_TAKEN);
decl = gimple_call_fndecl (stmt);
-- CUT ---
I am testing it right now.
[Bug c++/68383] Demangler stack overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68383 --- Comment #14 from fiesh at zefix dot tv --- It appears to be correct, as far as one can safely judge this by eye examination.
