[Bug tree-optimization/46193] ICE: in omp_reduction_init, at omp-low.c:2212 with -ftree-parallelize-loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46193 --- Comment #8 from vries at gcc dot gnu.org --- Author: vries Date: Sat Aug 29 07:07:51 2015 New Revision: 227315 URL: https://gcc.gnu.org/viewcvs?rev=227315root=gccview=rev Log: Handle mix/max pointer reductions in parloops 2015-08-29 Tom de Vries t...@codesourcery.com PR tree-optimization/46193 * omp-low.c (omp_reduction_init): Handle pointer type for min or max clause. * gcc.dg/autopar/pr46193.c: New test. * testsuite/libgomp.c/pr46193.c: New test. Added: trunk/gcc/testsuite/gcc.dg/autopar/pr46193.c trunk/libgomp/testsuite/libgomp.c/pr46193.c Modified: trunk/gcc/ChangeLog trunk/gcc/omp-low.c trunk/gcc/testsuite/ChangeLog trunk/libgomp/ChangeLog
[Bug tree-optimization/46193] ICE: in omp_reduction_init, at omp-low.c:2212 with -ftree-parallelize-loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46193 vries at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from vries at gcc dot gnu.org --- patch and test-case committed, marking resolved-fixed
[Bug tree-optimization/65488] parloops runs for functions it doesn't process
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65488 vries at gcc dot gnu.org changed: What|Removed |Added Keywords|patch | --- Comment #4 from vries at gcc dot gnu.org --- Given the discussion, retracting patch.
[Bug fortran/54599] Issues found in gfortran by the Coverity Scan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54599 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #11 from Dominique d'Humieres dominiq at lps dot ens.fr --- What is left of this PR besides pr46244? I think new PRs should be opened for the remaining issues and this should be closed. No answer for almost nine months. Closing as FIXED.
[Bug fortran/67044] ICE on valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67044 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-08-29 CC||mikael at gcc dot gnu.org, ||pault at gcc dot gnu.org, ||vehre at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Confirmed from 4.8 up to trunk (6.0 configured with --enable-checking=release). When 6.0 is configured with the default value of --enable-checking, the ICE is internal compiler error: tree check: expected function_type or method_type, have pointer_type in gimplify_call_expr, at gimplify.c:2391 The ICE with 4.7 is pr67044.f90: In function 'cont_add': pr67044.f90:39:0: error: non-function in gimple call D.1930 = unpck.4 (D.1900, D.1901); pr67044.f90:39: confused by earlier errors, bailing out and with 4.6 pr67044.f90: In function 'cont_add': pr67044.f90:49:0: internal compiler error: in cgraph_node, at cgraph.c:495 The code compiles if the line allocate( z%f , source=unpck(x)+unpck(y) ) is replaced with allocate( z%f , source=unpck(x) )
[Bug fortran/67044] ICE: in aggregate_value_p, at function.c:2068
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67044 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Keywords||ice-on-valid-code Summary|ICE on valid code |ICE: in aggregate_value_p, ||at function.c:2068 Known to fail||4.9.3, 5.2.0, 6.0 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- Changing the summary to something making duplicates easier to spot.
[Bug fortran/65454] Extending both forms of relational operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65454 --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr --- Could this PR be closed as INVALID?
[Bug fortran/64854] No bound check for explicit-shape arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64854 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WONTFIX --- Comment #8 from Dominique d'Humieres dominiq at lps dot ens.fr --- Per comment 7, closing as WONTFIX.
[Bug target/67391] New: [SH] Convert clrt addc to normal add insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67391 Bug ID: 67391 Summary: [SH] Convert clrt addc to normal add insn Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: olegendo at gcc dot gnu.org Target Milestone: --- Looking through bzip2 compress.c of the CSiBE set, I've spotted sequences such as: mov r15,r4 add #64,r4 mov.l @(44,r4),r2 mov r15,r0 mov.w .L615,r5 add #124,r0 clrt mov.l @(16,r0),r0 mov r14,r1 add r2,r5 addcr12,r1 mov.l r5,@(44,r4) cmp/eq r1,r0 bf/s.L126 It seems that this is a left-over of what originally was a 64 bit addition. The high word of the 64 bit add result is unused, which makes it effectively a 32 bit addition. The clrt can be removed and the addc can be converted into a regular add insn.
[Bug middle-end/63510] Wrong line number in Wstrict-overflow message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63510 --- Comment #11 from Chen Gang gang.chen.5i5j at gmail dot com --- Created attachment 36267 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36267action=edit The related fix patch for it. The related fix patch for it: current input_location isn't precise for reporting warning. The correct location is gimple location of current statement.
[Bug fortran/67277] segfault when passing a missing optional argument to an elemental intrinsic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67277 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-08-29 Ever confirmed|0 |1 --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr --- Confirmed from 4.8 up to trunk (6.0).
[Bug fortran/31601] RFC: legacy-only allowed: State that code is allowed with -std=legacy ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31601 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WONTFIX --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- No answer to comment 1 since over a year and a half! Closing as WONTFIX.
[Bug fortran/48244] iso-c-binding support missing on NetBSD (with patch)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48244 --- Comment #10 from Dominique d'Humieres dominiq at lps dot ens.fr --- I have submitted the necessary patches and test_result.log as pr64271 Does this mean that this PR can be closed? If yes, with which resolution?
[Bug fortran/56408] Fix dependency handling of testsuite/gfortran.dg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56408 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #11 from Dominique d'Humieres dominiq at lps dot ens.fr --- Is it fixed or not after r215293? No answer after over eight months. Closing as FIXED. Please open new PRs for remaining issues.
[Bug other/67392] New: Invalid mmap return value check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67392 Bug ID: 67392 Summary: Invalid mmap return value check Product: gcc Version: 5.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: tobias at stoeckmann dot org Target Milestone: --- Created attachment 36268 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36268action=edit check for MAP_FAILED instead of NULL If mmap() fails, MAP_FAILED will be returned. The code checks for NULL though, the error return value of malloc() and basically every other function out there.
[Bug fortran/66979] gfortran internal compiler error with malformed FLUSH statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66979 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-08-29 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Confirmed from 4.8 up to trunk (6.0).
[Bug fortran/66709] ICE on formatted io with parameter array specifier fmt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66709 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-08-29 CC||jvdelisle at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- Confirmed from 4.8 up to trunk (6.0).
[Bug fortran/66461] [4.9/5/6 Regression] ICE on missing end program in fixed source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66461 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Known to work||4.4.7 Keywords||ice-on-invalid-code Last reconfirmed||2015-08-29 Ever confirmed|0 |1 Summary|ICE on missing end program |[4.9/5/6 Regression] ICE on |in fixed source |missing end program in ||fixed source Known to fail||4.5.0 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- That's obviously an old regression: ... As old as r154654.
[Bug fortran/67367] Program crashes on READ(IOSTAT=IOS, ...) on directory OPEN()ed without error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67367 --- Comment #7 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Author: jvdelisle Date: Sat Aug 29 15:38:39 2015 New Revision: 227320 URL: https://gcc.gnu.org/viewcvs?rev=227320root=gccview=rev Log: 2015-08-29 Jerry DeLisle jvdeli...@gcc.gnu.org PR libgfortran/67367 * io/unix.c (buf_read): Check for error condition and if found return the error code. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/unix.c
[Bug fortran/67367] Program crashes on READ(IOSTAT=IOS, ...) on directory OPEN()ed without error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67367 --- Comment #8 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Author: jvdelisle Date: Sat Aug 29 15:52:43 2015 New Revision: 227321 URL: https://gcc.gnu.org/viewcvs?rev=227321root=gccview=rev Log: 2015-08-29 Jerry DeLisle jvdeli...@gcc.gnu.org PR fortran/67367 * gfortran.dg/read_dir.f90: New test. May fail on some platforms. Added: trunk/gcc/testsuite/gfortran.dg/read_dir.f90 Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/67026] GCC incorrectly rejects well-formed constexpr function definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67026
Markus Trippelsdorf trippels at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2015-08-29
CC||trippels at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #4 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
Confirmed.
Another example:
constexpr int f3() {
return 0;
throw;
}
Checking should stop after the return statement.
[Bug c++/65970] [C++14] Endless loop with constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65970
Markus Trippelsdorf trippels at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2015-08-29
CC||trippels at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
Confirmed. Loops in:
3014 static tree
3015 cxx_eval_loop_expr (const constexpr_ctx *ctx, tree t,
3016 bool *non_constant_p, bool *overflow_p,
3017 tree *jump_target)
3018 {
3019 tree body = TREE_OPERAND (t, 0);
3020 while (true)
3021 {
3022 cxx_eval_statement_list (ctx, body,
3023non_constant_p, overflow_p, jump_target);
3024 if (returns (jump_target) || breaks (jump_target) ||
*non_constant_p)
3025 break;
3026 }
3027 if (breaks (jump_target))
3028 *jump_target = NULL_TREE;
3029 return NULL_TREE;
3030 }
A variant ICEs:
markus@x4 tmp % cat const.ii
constexpr int foo() {
while (true)
;
return 0;
}
int i = foo();
markus@x4 tmp % g++ -std=c++14 -c const.ii
const.ii:7:12: in constexpr expansion of ‘foo()’
const.ii:7:13: internal compiler error: tree check: expected statement_list,
have nop_expr in tsi_start, at tree-iterator.h:42
int i = foo();
^
0xeef92c tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/gcc/tree.c:9499
0x59db9a tree_check(tree_node*, char const*, int, char const*, tree_code)
../../gcc/gcc/tree.h:2858
0x59db9a tsi_start
../../gcc/gcc/tree-iterator.h:42
0x7f085f tsi_start
../../gcc/gcc/cp/constexpr.c:2949
0x7f085f cxx_eval_statement_list
../../gcc/gcc/cp/constexpr.c:2980
0x7eacb6 cxx_eval_loop_expr
../../gcc/gcc/cp/constexpr.c:3023
0x7eacb6 cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.c:3646
0x7f06e6 cxx_eval_statement_list
../../gcc/gcc/cp/constexpr.c:2996
0x7eb3a4 cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.c:3580
0x7ea3ba cxx_eval_call_expression
../../gcc/gcc/cp/constexpr.c:1379
0x7eb191 cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.c:3205
0x7f0991 cxx_eval_outermost_constant_expr
../../gcc/gcc/cp/constexpr.c:3740
0x7f2b3f maybe_constant_init(tree_node*, tree_node*)
../../gcc/gcc/cp/constexpr.c:3943
0x67f5dc store_init_value(tree_node*, tree_node*, vectree_node*, va_gc,
vl_embed**, int)
../../gcc/gcc/cp/typeck2.c:826
0x5e83df check_initializer
../../gcc/gcc/cp/decl.c:6089
0x607884 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../gcc/gcc/cp/decl.c:6714
0x704895 cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:17846
0x707155 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:11681
0x7008f3 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:11555
0x70c737 cp_parser_declaration
../../gcc/gcc/cp/parser.c:11452
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
markus@x4 tmp % clang++ -Wall -Wextra -std=c++14 -c const.ii
const.ii:1:15: error: constexpr function never produces a constant expression
[-Winvalid-constexpr]
constexpr int foo() {
^
const.ii:3:5: note: constexpr evaluation hit maximum step limit; possible
infinite loop?
;
^
1 error generated.
[Bug c++/67394] New: crash due to null pointer deref in demangle_signature()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67394 Bug ID: 67394 Summary: crash due to null pointer deref in demangle_signature() Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: brian.carpenter at gmail dot com Target Milestone: --- While fuzzing binutils/cxxfilt with AFL (http://lcamtuf.coredump.cx/afl/), I discovered a crash due to a null ptr deref in demangle_signature(). This is with GCC 4.9.2 and Debian 7 (x64). ./cxxfilt _Q.__0 Valgrind: ==4253== Invalid write of size 8 ==4253==at 0x7AD3A0: register_Btype (cplus-dem.c:4319) ==4253==by 0x7AD3A0: demangle_class (cplus-dem.c:2594) ==4253==by 0x7AD3A0: demangle_signature (cplus-dem.c:1490) ==4253==by 0x7BB869: internal_cplus_demangle (cplus-dem.c:1203) ==4253==by 0x7825B2: cplus_demangle (cplus-dem.c:886) ==4253==by 0x408192: demangle_it (cxxfilt.c:62) ==4253==by 0x407618: main (cxxfilt.c:227) ==4253== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==4253== ==4253== ==4253== Process terminating with default action of signal 11 (SIGSEGV) ==4253== Access not within mapped region at address 0x0 ==4253==at 0x7AD3A0: register_Btype (cplus-dem.c:4319) ==4253==by 0x7AD3A0: demangle_class (cplus-dem.c:2594) ==4253==by 0x7AD3A0: demangle_signature (cplus-dem.c:1490) ==4253==by 0x7BB869: internal_cplus_demangle (cplus-dem.c:1203) ==4253==by 0x7825B2: cplus_demangle (cplus-dem.c:886) ==4253==by 0x408192: demangle_it (cxxfilt.c:62) ==4253==by 0x407618: main (cxxfilt.c:227) ==4253== If you believe this happened as a result of a stack ==4253== overflow in your program's main thread (unlikely but ==4253== possible), you can try to increase the size of the ==4253== main thread stack using the --main-stacksize= flag. ==4253== The main thread stack size used in this run was 8388608. Segmentation fault GDB: Program received signal SIGSEGV, Segmentation fault. 0x007ad3a0 in demangle_signature () (gdb) bt #0 0x007ad3a0 in demangle_signature () #1 0x007bb86a in internal_cplus_demangle () #2 0x007825b3 in cplus_demangle () #3 0x00408193 in demangle_it () at cxxfilt.c:62 #4 0x00407619 in main () at cxxfilt.c:227 (gdb) i R rax0x0 0 rbx0x0 0 rcx0x0 0 rdx0x7fffe110 140737488347408 rsi0x7fffe108 140737488347400 rdi0x0 0 rbp0x7fffe108 0x7fffe108 rsp0x7fffdfe0 0x7fffdfe0 r8 0xabe000 11264000 r9 0x0 0 r100x20 32 r110x1e 30 r120x7fffe110 140737488347408 r130x0 0 r140x7fffe180 140737488347520 r150x1 1 rip0x7ad3a0 0x7ad3a0 demangle_signature+9248 eflags 0x10293 [ CF AF SF IF RF ] cs 0x33 51 ss 0x2b 43 ds 0x0 0 es 0x0 0 fs 0x0 0 gs 0x0 0
[Bug fortran/67039] Documentation of pseudorandom number intrinsics is incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67039 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-08-29 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- Resolved as WONTFIX?
[Bug c++/67376] Comparison with pointer to past-the-end of array fails inside constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67376 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added CC||colu...@gmx-topmail.de --- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org --- *** Bug 67380 has been marked as a duplicate of this bug. ***
[Bug fortran/67039] Documentation of pseudorandom number intrinsics is incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67039 --- Comment #3 from kargl at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #2) Resolved as WONTFIX? Probably not. See the last 2 paragraphs in comment #1.
[Bug c++/67380] constexpr: Comparison of pointers to member array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67380 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||trippels at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org --- dup. *** This bug has been marked as a duplicate of bug 67376 ***
[Bug fortran/67174] [6 regression] gfortran.dg/do_iterator.f90 FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67174 Paul Thomas pault at gcc dot gnu.org changed: What|Removed |Added CC||pault at gcc dot gnu.org --- Comment #1 from Paul Thomas pault at gcc dot gnu.org --- (In reply to Rainer Orth from comment #0) Since about 20150529 (r223861), there's a testsuite regression on Solaris 11 (both sparc and x86, both 32 and 64-bit): FAIL: gfortran.dg/do_iterator.f90 -O changing do-iterator 3 (test for errors, line 10) FAIL: gfortran.dg/do_iterator.f90 -O changing do-iterator 3 (test for errors, line 9) Rainer Hi Rainer, If you run the testcase outside of the testsuite does the error appear but without the offending line? I have been plagued by such a problem with an F2008 patch that I have prepared. Cheers Paul
[Bug c++/67393] New: segfault in cxxfilt in d_unqualified_name () at ./cp-demangle.c:1547
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67393 Bug ID: 67393 Summary: segfault in cxxfilt in d_unqualified_name () at ./cp-demangle.c:1547 Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: brian.carpenter at gmail dot com Target Milestone: --- I was fuzzing binutils/cxxfilt with AFL (http://lcamtuf.coredump.cx/afl/) and came across a crash and was told that it was a gcc bug not a cxxfilt bug. This is with GCC 4.9.2 on Debian 7 (x64). ./cxxfilt _Z66 Valgrind: ==35143== Invalid read of size 1 ==35143==at 0x80CDBF: d_unqualified_name (cp-demangle.c:1547) ==35143==by 0x813F87: d_name (cp-demangle.c:1391) ==35143==by 0x815BE7: d_encoding (cp-demangle.c:1257) ==35143==by 0x8189F4: cplus_demangle_mangled_name (cp-demangle.c:1172) ==35143==by 0x81AD60: d_demangle_callback (cp-demangle.c:5886) ==35143==by 0x81AD60: d_demangle (cp-demangle.c:5937) ==35143==by 0x81AD60: cplus_demangle_v3 (cp-demangle.c:6094) ==35143==by 0x783A73: cplus_demangle (cplus-dem.c:864) ==35143==by 0x408192: demangle_it (cxxfilt.c:62) ==35143==by 0x407618: main (cxxfilt.c:227) ==35143== Address 0x8ae0ae97 is not stack'd, malloc'd or (recently) free'd ==35143== ==35143== ==35143== Process terminating with default action of signal 11 (SIGSEGV) ==35143== Access not within mapped region at address 0x8AE0AE97 ==35143==at 0x80CDBF: d_unqualified_name (cp-demangle.c:1547) ==35143==by 0x813F87: d_name (cp-demangle.c:1391) ==35143==by 0x815BE7: d_encoding (cp-demangle.c:1257) ==35143==by 0x8189F4: cplus_demangle_mangled_name (cp-demangle.c:1172) ==35143==by 0x81AD60: d_demangle_callback (cp-demangle.c:5886) ==35143==by 0x81AD60: d_demangle (cp-demangle.c:5937) ==35143==by 0x81AD60: cplus_demangle_v3 (cp-demangle.c:6094) ==35143==by 0x783A73: cplus_demangle (cplus-dem.c:864) ==35143==by 0x408192: demangle_it (cxxfilt.c:62) ==35143==by 0x407618: main (cxxfilt.c:227) ==35143== If you believe this happened as a result of a stack ==35143== overflow in your program's main thread (unlikely but ==35143== possible), you can try to increase the size of the ==35143== main thread stack using the --main-stacksize= flag. ==35143== The main thread stack size used in this run was 8388608. Segmentation fault GDB: Program received signal SIGSEGV, Segmentation fault. 0x0080cdbf in d_unqualified_name () at ./cp-demangle.c:1547 1547ret = d_source_name (di); (gdb) bt #0 0x0080cdbf in d_unqualified_name () at ./cp-demangle.c:1547 #1 0x00813f88 in d_name () at ./cp-demangle.c:1391 #2 0x00815be8 in d_encoding () at ./cp-demangle.c:1257 #3 0x008189f5 in cplus_demangle_mangled_name () at ./cp-demangle.c:1172 #4 0x0081ad61 in cplus_demangle_v3 () at ./cp-demangle.c:5886 #5 0x00783a74 in cplus_demangle () #6 0x00408193 in demangle_it () at cxxfilt.c:62 #7 0x00407619 in main () at cxxfilt.c:227 (gdb) i r rax0x7fffde30 140737488346672 rbx0x7fffe0c0 140737488347328 rcx0xabe2e1 11264737 rdx0x0 0 rsi0x8a0fe4ec -1978669844 rdi0x0 0 rbp0x7fffde30 0x7fffde30 rsp0x7fffdcf0 0x7fffdcf0 r8 0xffd0 4294967248 r9 0x0 0 r100x8a0fe4ec -1978669844 r110x18 24 r120x1 1 r130x7fffe080 140737488347264 r140x10b267 r150xbc617592186043334 rip0x80cdbf 0x80cdbf d_unqualified_name+1439 eflags 0x10202 [ IF RF ] cs 0x33 51 ss 0x2b 43 ds 0x0 0 es 0x0 0 fs 0x0 0 gs 0x0 0
[Bug target/66634] Cross building native *-w64-mingw32 failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66634 Berlos Cander ntl21042 at kmhow dot com changed: What|Removed |Added CC||ntl21042 at kmhow dot com --- Comment #1 from Berlos Cander ntl21042 at kmhow dot com --- any chance of fixing this please?
[Bug c++/67394] crash due to null pointer deref in demangle_signature()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67394
Mikhail Maltsev miyuki at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2015-08-29
CC||miyuki at gcc dot gnu.org
Ever confirmed|0 |1
Known to fail||6.0
--- Comment #1 from Mikhail Maltsev miyuki at gcc dot gnu.org ---
Reproduces on trunk (the bug is in pre-v3 demangler, cplus-dem.c, I did not
fuzz it). Something like this should fix it:
diff --git a/libiberty/cplus-dem.c b/libiberty/cplus-dem.c
index c68b981..7ab46dd 100644
--- a/libiberty/cplus-dem.c
+++ b/libiberty/cplus-dem.c
@@ -1237,11 +1237,13 @@ squangle_mop_up (struct work_stuff *work)
{
free ((char *) work - btypevec);
work-btypevec = NULL;
+ work-bsize = 0;
}
if (work - ktypevec != NULL)
{
free ((char *) work - ktypevec);
work-ktypevec = NULL;
+ work-ksize = 0;
}
}
[Bug c/67396] New: [4.9/5.0 regression] Performance regression compiling variadic function with many arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67396 Bug ID: 67396 Summary: [4.9/5.0 regression] Performance regression compiling variadic function with many arguments Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: ppluzhnikov at google dot com Target Milestone: --- Created attachment 36270 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36270action=edit test generator script For https://sourceware.org/bugzilla/show_bug.cgi?id=18872, I need a test case that calls printf() with = 2700 arguments. GCC-4.9 and 5.0 (and current trunk) take excessively long to compile such test cases with optimization: $ perl gen_bz18872.pl 500 t.c time gcc-svn-r227321/bin/gcc -c -O2 t.c user0m1.506s $ perl gen_bz18872.pl 1000 t.c time gcc-svn-r227321/bin/gcc -c -O2 t.c user0m11.976s $ perl gen_bz18872.pl 2000 t.c gcc-svn-r227321/bin/gcc -c -O2 t.c user1m40.911s $ perl gen_bz18872.pl 4000 t.c gcc-svn-r227321/bin/gcc -c -O2 t.c user14m0.767s ### Yikes! For comparison, gcc-4.8 (Ubuntu 4.8.4-2ubuntu1~14.04) 4.8.4 compiles the 4000 argument case in 1.3s. The problem is already present in r220312 (the oldest build I have).
[Bug c++/67333] [C++11][constexpr] constexpr functions incorrectly prohibit taking references to volatile types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67333 Mikhail Maltsev miyuki at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-08-29 Blocks||55004 Ever confirmed|0 |1 Known to fail||6.0 --- Comment #2 from Mikhail Maltsev miyuki at gcc dot gnu.org --- For the record: https://gcc.gnu.org/ml/gcc-patches/2015-08/msg01735.html Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004 [Bug 55004] [meta-bug] constexpr issues
[Bug c++/67371] Never executed throw in constexpr function fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67371 --- Comment #8 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Author: trippels Date: Sat Aug 29 18:51:26 2015 New Revision: 227323 URL: https://gcc.gnu.org/viewcvs?rev=227323root=gccview=rev Log: Fix c++/67371 (issues with throw in constexpr) As PR67371 shows gcc currently rejects all throw statements in constant-expressions, even when they are never executed. PR c++/67371 * constexpr.c (potential_constant_expression_1): Remove IF_STMT case. Move label to COND_EXPR case. Remove checking of SWITCH_STMT_BODY. Added: trunk/gcc/testsuite/g++.dg/cpp1y/constexpr-new.C trunk/gcc/testsuite/g++.dg/cpp1y/constexpr-throw.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/constexpr.c
[Bug c++/55004] [meta-bug] constexpr issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004 Bug 55004 depends on bug 67371, which changed state. Bug 67371 Summary: Never executed throw in constexpr function fails to compile https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67371 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/67371] Never executed throw in constexpr function fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67371 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Fixed.
[Bug c++/67395] New: It is possible to override c++ access control in case of indirect inheritance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67395 Bug ID: 67395 Summary: It is possible to override c++ access control in case of indirect inheritance Product: gcc Version: 5.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: webczat_200 at poczta dot onet.pl Target Milestone: --- Created attachment 36269 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36269action=edit test case It seems that g++ does have an access control bug. In case of multiple inheritance, where one base class appears multiple times in a hierarchy, once inherited as a private, once as a public member, it is possible to override this. That is quite difficult to explain, I am attaching a test case that g++ does compile, clang fails on that. I didn't check the standard itself, so it is possible that it is not a bug, but for me it seems unlikely.
[Bug c++/67393] segfault in cxxfilt in d_unqualified_name () at ./cp-demangle.c:1547
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67393 Mikhail Maltsev miyuki at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||miyuki at gcc dot gnu.org Resolution|--- |FIXED Severity|critical|normal --- Comment #1 from Mikhail Maltsev miyuki at gcc dot gnu.org --- I believe, this was fixed in r225727 (and there were no plans to backport the fix). Related issue (remaining crashes discovered by AFL): PR67264.
[Bug c++/67397] New: GCC incorrectly accepts non-type template parameter pack expansion of a parameter pack declared in the same template-parameter-list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67397
Bug ID: 67397
Summary: GCC incorrectly accepts non-type template parameter
pack expansion of a parameter pack declared in the
same template-parameter-list
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: brunocodutra at gmail dot com
Target Milestone: ---
The following is incorrectly accepted by GCC (and clang but not MSVC 14)
templatetypename...
struct foo;
templatetypename... t, t... v
struct foostd::integral_constantt, v...
{
using type = foo;
};
using bar = foostd::integral_constantint, -1, std::true_type::type;
[temp.param]/p15:
A template parameter pack that is a pack expansion shall not expand a
parameter pack declared in the same template-parameter-list.
