[Bug c++/63405] [4.9/5 regression] ICE in cp_perform_integral_promotions, at cp/typeck.c:2084
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63405 --- Comment #11 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Gert-jan, there is no need to rerun git-bisect. The issue started with r215171 on trunk and with r215172 on 4.9 branch. Can you take a look, Jason?
[Bug c++/63423] New: internal compiler error: in cp_parser_abort_tentative_parse, at cp/parser.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63423 Bug ID: 63423 Summary: internal compiler error: in cp_parser_abort_tentative_parse, at cp/parser.c Product: gcc Version: 4.8.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: kretz at kde dot org Testcase: template typename F, typename A, typename = decltype(static_castvoid ()(A )(F::operator())(A())) void test(); Compile it with '-std=c++11'. Tested to fail with GCC 4.8.[0123]. GCC 4.9.x does not fail. Output from GCC 4.8.3: ice.cpp:2:76: internal compiler error: in cp_parser_abort_tentative_parse, at cp/parser.c:23778 typename = decltype(static_castvoid ()(A )(F::operator())(A())) ^ 0x584872 cp_parser_abort_tentative_parse ../.././gcc/cp/parser.c:23777 0x5937ec cp_parser_decltype ../.././gcc/cp/parser.c:11425 0x592172 cp_parser_simple_type_specifier ../.././gcc/cp/parser.c:13885 0x58e83d cp_parser_type_specifier ../.././gcc/cp/parser.c:13756 0x590f17 cp_parser_type_specifier_seq ../.././gcc/cp/parser.c:17296 0x59638a cp_parser_type_id_1 ../.././gcc/cp/parser.c:17177 0x5a0e5a cp_parser_type_id ../.././gcc/cp/parser.c:17214 0x5a0e5a cp_parser_type_parameter ../.././gcc/cp/parser.c:12512 0x5a1019 cp_parser_template_parameter ../.././gcc/cp/parser.c:12345 0x5a1019 cp_parser_template_parameter_list ../.././gcc/cp/parser.c:12262 0x5a67d9 cp_parser_template_declaration_after_export ../.././gcc/cp/parser.c:21914 0x5aafa9 cp_parser_declaration ../.././gcc/cp/parser.c:10412 0x5a9bfd cp_parser_declaration_seq_opt ../.././gcc/cp/parser.c:10334 0x5ab402 cp_parser_translation_unit ../.././gcc/cp/parser.c:3813 0x5ab402 c_parse_file() ../.././gcc/cp/parser.c:28334 0x641b84 c_common_parse_file() ../.././gcc/c-family/c-opts.c:1052
[Bug preprocessor/58893] [4.8/4.9 Regression] command-line:0:0: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58893 --- Comment #13 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Backports of your fix would be appreciated.
[Bug c++/63415] [4.9/5 Regression] internal compiler error: unexpected expression ‘static_castint(std::is_sameT, A1{})’ of kind static_cast_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63415 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- The error turned into ICE with r196724.
[Bug c++/26099] support for type traits is not available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26099 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.0 --- Comment #32 from Paolo Carlini paolo.carlini at oracle dot com --- The __is_trivially_* bits are tracked by c++/63362.
[Bug c++/63362] The c++11 triviality-traits need front-end help
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63362 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.0 --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com --- Implemented in r215735-r215738.
[Bug c++/26099] support for type traits is not available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26099 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Target Milestone|5.0 |---
[Bug c++/63424] New: Octave -O3 build: internal compiler error: in prepare_cmp_insn, at optabs.c:4237
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63424 Bug ID: 63424 Summary: Octave -O3 build: internal compiler error: in prepare_cmp_insn, at optabs.c:4237 Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: david.sherwood at arm dot com Created attachment 33634 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33634action=edit A reduced test case from the Octave build failure Whilst building Octave with CFLAGS=-O3 -pipe on target aarch64-linux-gnu I got the following compiler error: internal compiler error: in prepare_cmp_insn, at optabs.c:4237 ival = truncate_int (static_castunsigned long long (ival) ^ 0xb2b205 prepare_cmp_insn /work/davshe01/oban-work/src/gcc/gcc/optabs.c:4237 0xb2b288 emit_cmp_and_jump_insns(rtx_def*, rtx_def*, rtx_code, rtx_def*, machine_mode, int, rtx_def*, int) /work/davshe01/oban-work/src/gcc/gcc/optabs.c:4381 0x8d3019 do_compare_rtx_and_jump(rtx_def*, rtx_def*, rtx_code, int, machine_mode, rtx_def*, rtx_def*, rtx_def*, int) /work/davshe01/oban-work/src/gcc/gcc/dojump.c:1135 0x95c9bf expand_expr_real_2(separate_ops*, rtx_def*, machine_mode, expand_modifier) /work/davshe01/oban-work/src/gcc/gcc/expr.c:8855 0x94ff1f expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) /work/davshe01/oban-work/src/gcc/gcc/expr.c:9428 0x958a00 expand_expr /work/davshe01/oban-work/src/gcc/gcc/expr.h:451 0x958a00 expand_operands /work/davshe01/oban-work/src/gcc/gcc/expr.c:7541 0x95bc92 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode, expand_modifier) /work/davshe01/oban-work/src/gcc/gcc/expr.c:9233 0x94ff1f expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) /work/davshe01/oban-work/src/gcc/gcc/expr.c:9428 0x959945 store_expr(tree_node*, rtx_def*, int, bool) /work/davshe01/oban-work/src/gcc/gcc/expr.c:5337 0x960cbf expand_assignment(tree_node*, tree_node*, bool) /work/davshe01/oban-work/src/gcc/gcc/expr.c:5123 0x876a0b expand_gimple_stmt_1 /work/davshe01/oban-work/src/gcc/gcc/cfgexpand.c:3274 0x876a0b expand_gimple_stmt /work/davshe01/oban-work/src/gcc/gcc/cfgexpand.c:3370 0x87ca33 expand_gimple_basic_block /work/davshe01/oban-work/src/gcc/gcc/cfgexpand.c:5209 0x87e5d6 execute /work/davshe01/oban-work/src/gcc/gcc/cfgexpand.c:5815 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. I have attached a reduced test case, Thanks, David Sherwood.
[Bug other/63425] New: Demangler crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63425 Bug ID: 63425 Summary: Demangler crash Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: riku at multitaction dot com The demangler crashes when given this symbol: _ZN6NimblemlIiiEENS_8Vector2TIDTmlcvT__EcvT0__S3_RKNS1_IS2_EE Using GDB 7.8.50.20141001-cvs (git 8d7edfd), this is a different bug from https://sourceware.org/bugzilla/show_bug.cgi?id=14963 c++filt demangles that as Nimble::Vector2Tdecltype (((int)())*((int)())) Nimble::operator*int, int(int, Nimble::Vector2Tint const) Beginning of the infinite recursion: #65427 0x006f75fd in d_print_comp_inner (dpi=dpi@entry=0x7fffc640, options=options@entry=259, dc=dc@entry=0x7fffcb50) at ./cp-demangle.c:5046 #65428 0x006f9813 in d_print_comp (dc=0x7fffcb50, options=259, dpi=0x7fffc640) at ./cp-demangle.c:5368 #65429 d_print_subexpr (dpi=dpi@entry=0x7fffc640, options=options@entry=259, dc=0x7fffcb50) at ./cp-demangle.c:4228 #65430 0x006f4ca4 in d_print_comp_inner (dpi=dpi@entry=0x7fffc640, options=259, dc=0x7fffcbe0) at ./cp-demangle.c:5104 #65431 0x006f8264 in d_print_comp (dpi=0x7fffc640, options=optimized out, dc=optimized out) at ./cp-demangle.c:5368 #65432 0x006f6dda in d_print_comp_inner (dpi=dpi@entry=0x7fffc640, options=259, dc=0x7fffcbf8) at ./cp-demangle.c:5276 #65433 0x006f8264 in d_print_comp (dpi=0x7fffc640, options=optimized out, dc=optimized out) at ./cp-demangle.c:5368 #65434 0x006f641f in d_print_comp_inner (dpi=dpi@entry=0x7fffc640, options=options@entry=259, dc=optimized out) at ./cp-demangle.c:4537 #65435 0x006f943a in d_print_comp (dc=optimized out, options=259, dpi=0x7fffc640) at ./cp-demangle.c:5368 #65436 d_print_cast (dpi=dpi@entry=0x7fffc640, options=options@entry=259, dc=0x7fffcb20) at ./cp-demangle.c:5754 #65437 0x006f75fd in d_print_comp_inner (dpi=dpi@entry=0x7fffc640, options=options@entry=259, dc=dc@entry=0x7fffcb50) at ./cp-demangle.c:5046 #65438 0x006f9813 in d_print_comp (dc=0x7fffcb50, options=259, dpi=0x7fffc640) at ./cp-demangle.c:5368 #65439 d_print_subexpr (dpi=dpi@entry=0x7fffc640, options=options@entry=259, dc=0x7fffcb50) at ./cp-demangle.c:4228 #65440 0x006f4ca4 in d_print_comp_inner (dpi=dpi@entry=0x7fffc640, options=259, dc=0x7fffcbe0) at ./cp-demangle.c:5104 #65441 0x006f8264 in d_print_comp (dpi=0x7fffc640, options=optimized out, dc=optimized out) at ./cp-demangle.c:5368 #65442 0x006f6dda in d_print_comp_inner (dpi=dpi@entry=0x7fffc640, options=259, dc=0x7fffcbf8) at ./cp-demangle.c:5276 #65443 0x006f8264 in d_print_comp (dpi=0x7fffc640, options=optimized out, dc=optimized out) at ./cp-demangle.c:5368 #65444 0x006f59c3 in d_print_comp_inner (dpi=dpi@entry=0x7fffc640, options=259, dc=0x7fffcc10) at ./cp-demangle.c:4950 #65445 0x006f8264 in d_print_comp (dpi=0x7fffc640, options=optimized out, dc=optimized out) at ./cp-demangle.c:5368 #65446 0x006f60b0 in d_print_comp_inner (dpi=dpi@entry=0x7fffc640, options=259, dc=0x7fffcc28) at ./cp-demangle.c:4501 #65447 0x006f8264 in d_print_comp (dpi=0x7fffc640, options=optimized out, dc=optimized out) at ./cp-demangle.c:5368 #65448 0x006f7b1d in d_print_comp_inner (dpi=dpi@entry=0x7fffc640, options=259, dc=0x7fffccd0) at ./cp-demangle.c:4820 #65449 0x006f8264 in d_print_comp (dpi=0x7fffc640, options=optimized out, dc=optimized out) at ./cp-demangle.c:5368 #65450 0x006f6207 in d_print_comp_inner (dpi=dpi@entry=0x7fffc640, options=options@entry=259, dc=dc@entry=0x7fffcce8) at ./cp-demangle.c:4442 #65451 0x006fc886 in d_print_comp (dc=0x7fffcce8, options=259, dpi=0x7fffc640) at ./cp-demangle.c:5368 #65452 cplus_demangle_print_callback (options=options@entry=259, dc=dc@entry=0x7fffcce8, callback=callback@entry=0x6f4b10 d_growable_string_callback_adapter, opaque=opaque@entry=0x7fffd6f0) at ./cp-demangle.c:4071 #65453 0x006fca8f in d_demangle_callback (mangled=optimized out, mangled@entry=0x77e107a5 _ZN6NimblemlIiiEENS_8Vector2TIDTmlcvT__EcvT0__S3_RKNS1_IS2_EE, options=259, callback=callback@entry=0x6f4b10 d_growable_string_callback_adapter, opaque=opaque@entry=0x7fffd6f0) at ./cp-demangle.c:5898
[Bug c++/63362] The c++11 triviality-traits need front-end help
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63362
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Last reconfirmed||2014-10-01
Resolution|FIXED |---
Ever confirmed|0 |1
--- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com ---
Let's keep this open until the following also works fine:
template class T, class... Args void bar() {
static_assert(__is_trivially_constructible(T, Args...), );
}
[Bug other/63426] New: [meta-bug] Issues found with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426 Bug ID: 63426 Summary: [meta-bug] Issues found with -fsanitize=undefined Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: trippels at gcc dot gnu.org
[Bug other/57324] Undefined behavior issues found with clang's -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57324 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 #3 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Closing old bug. Most issues here are already fixed. *** This bug has been marked as a duplicate of bug 59545 ***
[Bug other/59545] Signed integer overflow issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59545 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added CC||octoploid at yandex dot com --- Comment #13 from Markus Trippelsdorf trippels at gcc dot gnu.org --- *** Bug 57324 has been marked as a duplicate of this bug. ***
[Bug target/62662] [4.9/5 Regression] Miscompilation of Qt on s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62662 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed, thanks.
[Bug other/63426] [meta-bug] Issues found with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-10-01 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1
[Bug middle-end/63427] New: hwint.h:250:29: runtime error: shift exponent 64 is too large for 64-bit type 'long int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63427 Bug ID: 63427 Summary: hwint.h:250:29: runtime error: shift exponent 64 is too large for 64-bit type 'long int' Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: trippels at gcc dot gnu.org CC: zadeck at gcc dot gnu.org Blocks: 63426 gcc build with -fsanitize=undefined hits the following issue when compiling testsuite/gfortran.dg/integer_exponentiation_5.F90: markus@x4 gfortran % /var/tmp/gcc_build_dir_/gcc/testsuite/gfortran/../../gfortran -B/var/tmp/gcc_build_dir_/gcc/testsuite/gfortran/../../ -B/var/tmp/gcc_build_dir_/x86_64-unknown-linux-gnu/./libgfortran/ /var/tmp/gcc/gcc/testsuite/gfortran.dg/integer_exponentiation_5.F90 -fno-diagnostics-show-caret -fdiagnostics-color=never-O0 -fno-range-check -B/var/tmp/gcc_build_dir_/x86_64-unknown-linux-gnu/./libgfortran/.libs -L/var/tmp/gcc_build_dir_/x86_64-unknown-linux-gnu/./libgfortran/.libs -L/var/tmp/gcc_build_dir_/x86_64-unknown-linux-gnu/./libgfortran/.libs -B/var/tmp/gcc_build_dir_/x86_64-unknown-linux-gnu/./libquadmath/.libs -L/var/tmp/gcc_build_dir_/x86_64-unknown-linux-gnu/./libquadmath/.libs -L/var/tmp/gcc_build_dir_/x86_64-unknown-linux-gnu/./libquadmath/.libs -lm -o ./integer_exponentiation_5.exe ../../gcc/gcc/hwint.h:250:19: runtime error: shift exponent 64 is too large for 64-bit type 'long int' ../../gcc/gcc/hwint.h:250:29: runtime error: shift exponent 64 is too large for 64-bit type 'long int'
[Bug preprocessor/59805] invalid preprocessing directive not diagnosed with assembler-with-cpp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59805 Bernhard Reutner-Fischer aldot at gcc dot gnu.org changed: What|Removed |Added CC||joseph at codesourcery dot com --- Comment #1 from Bernhard Reutner-Fischer aldot at gcc dot gnu.org --- CCing jsm. I am undecided if this is a valid request after all. On one hand this is not a valid preprocessing token, on the other hand this behaviour might be ok with respect to ASM_COMMENT_START. Thoughts?
[Bug other/63426] [meta-bug] Issues found with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426 --- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Here's the full list (cut down to one instance per issue) of todays trunk: gcc/fortran/interface.c:2667:43: runtime error: load of value 1818451807, which is not a valid value for type 'expr_t' gcc/fortran/interface.c:2908:47: runtime error: load of value 108398592, which is not a valid value for type 'ar_type' gcc/fortran/trans-array.c:2211:9: runtime error: load of value 92, which is not a valid value for type 'bool' gcc/fortran/trans-expr.c:2286:48: runtime error: negation of -9223372036854775808 cannot be represented in type 'long int'; cast to an unsigned type to negate this value to itself gcc/hwint.h:250:29: runtime error: shift exponent 64 is too large for 64-bit type 'long int' gcc/ira.c:2465:24: runtime error: signed integer overflow: -2097715000 + -65536000 cannot be represented in type 'int' gcc/ira.c:2472:31: runtime error: signed integer overflow: -209760 + -65536000 cannot be represented in type 'int' gcc/loop-iv.c:2305:24: runtime error: signed integer overflow: 9223372036854775807 - -9223372036854775808 cannot be represented in type 'long int' gcc/loop-iv.c:2643:14: runtime error: signed integer overflow: 9223372036854775806 - -9223372036854775808 cannot be represented in type 'long int' gcc/tree-data-ref.c:2352:38: runtime error: signed integer overflow: 1073741824 + 1073741824 cannot be represented in type 'int' gcc/tree-data-ref.c:2443:16: runtime error: negation of -2147483648 cannot be represented in type 'int'; cast to an unsigned type to negate this value to itself gcc/tree-ssa-loop-ivopts.c:4192:24: runtime error: signed integer overflow: 4 * 4611686018427387903 cannot be represented in type 'long int' libiberty/cp-demangle.c:4074:40: runtime error: variable length array bound evaluates to non-positive value 0 libiberty/cp-demangle.c:4075:43: runtime error: variable length array bound evaluates to non-positive value 0 There are also a couple of buggy testcases: testsuite/gcc.dg/compat/generate-random_r.c:363:19: runtime error: signed integer overflow: 1627687941 + 1735697613 cannot be represented in type 'int' testsuite/gcc.dg/compat/struct-layout-1_generate.c:1081:13: runtime error: shift exponent 64 is too large for 64-bit type 'long long unsigned int' testsuite/g++.dg/compat/../../gcc.dg/compat/generate-random_r.c:363:19: runtime error: signed integer overflow: 1627687941 + 1735697613 cannot be represented in type 'int' testsuite/g++.dg/compat/struct-layout-1_generate.c:795:26: runtime error: shift exponent 64 is too large for 64-bit type 'long long unsigned int' testsuite/g++.dg/compat/struct-layout-1_generate.c:805:13: runtime error: shift exponent 65 is too large for 64-bit type 'long long unsigned int
[Bug middle-end/35545] tracer pass is run too late
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35545 --- Comment #25 from Martin Liška mliska at suse dot cz --- SPEC CPU numbers (--size=train, --iterations=3): First 3 columns present time (where smaller means faster) and for binary size the same. ++--++---+-+-++ || gcc-O3 | gcc-O3-fdo | gcc-O3-tracer | gcc-O3_SIZE | gcc-O3-fdo_SIZE | gcc-O3-tracer_SIZE | ++--++---+-+-++ | GemsFDTD | 100.00 % |96.00 % | 95.56 % |100.00 % | 101.14 % | 109.58 % | | hmmer | 100.00 % |97.44 % | 97.14 % |100.00 % | 73.94 % | 105.71 % | | sphinx3| 100.00 % |95.42 % | 97.76 % |100.00 % | 88.44 % | 104.29 % | | milc | 100.00 % |99.35 % | 101.13 % |100.00 % | 101.48 % | 103.98 % | | cactusADM | 100.00 % |99.97 % | 99.46 % |100.00 % | 76.84 % | 106.86 % | | tonto | 100.00 % |94.72 % | 98.04 % |100.00 % | 80.27 % | 107.15 % | | bwaves | 100.00 % | 104.47 % | 101.77 % |100.00 % | 100.33 % | 103.21 % | | lbm| 100.00 % |96.65 % | 98.49 % |100.00 % | 106.25 % | 102.04 % | | wrf| 100.00 % |61.39 % | 65.49 % |100.00 % | 64.51 % | 112.40 % | | bzip2 | 100.00 % |93.79 % | 100.10 % |100.00 % | 115.36 % | 108.78 % | | leslie3d | 100.00 % |96.52 % | 98.73 % |100.00 % | 100.24 % | 107.03 % | | gromacs| 100.00 % |97.12 % | 100.75 % |100.00 % | 77.08 % | 104.82 % | | sjeng | 100.00 % |98.77 % | 99.80 % |100.00 % | 84.01 % | 101.87 % | | calculix | 100.00 % | 101.55 % | 100.28 % |100.00 % | 79.58 % | 104.36 % | | astar | 100.00 % | 101.70 % | 97.19 % |100.00 % | 102.73 % | 101.95 % | | zeusmp | 100.00 % |98.79 % | 101.00 % |100.00 % | 113.59 % | 102.36 % | | povray | 100.00 % |89.17 % | 100.35 % |100.00 % | 83.61 % | 105.07 % | | omnetpp| 100.00 % |88.23 % | 102.54 % |100.00 % | 90.70 % | 102.47 % | | mcf| 100.00 % |95.92 % | 100.03 % |100.00 % | 124.69 % | 102.62 % | | gcc| 100.00 % |97.04 % | 98.88 % |100.00 % | 108.29 % | 101.24 % | | h264ref| 100.00 % |94.61 % | 100.58 % |100.00 % | 88.25 % | 105.93 % | | perlbench | 100.00 % |98.90 % | 100.46 % |100.00 % | 106.21 % | 106.23 % | | xalancbmk | 100.00 % |75.17 % | 82.56 % |100.00 % | 87.10 % | 103.41 % | | namd | 100.00 % |99.48 % | 100.59 % |100.00 % | 88.25 % | 100.74 % | | gamess | 100.00 % | 130.31 % | 131.62 % |100.00 % | 96.00 % | 101.59 % | | libquantum | 100.00 % |97.04 % | 98.98 % |100.00 % | 68.74 % | 104.55 % | | soplex | 100.00 % |96.15 % | 100.92 % |100.00 % | 87.04 % | 100.96 % | | gobmk | 100.00 % |91.22 % | 104.56 % |100.00 % | 84.16 % | 106.75 % | ++--++---+-+-++ | AVG| 100.00 % |95.96 % | 99.10 % |100.00 % | 92.10 % | 104.57 % | ++--++---+-+-++ Martin
[Bug target/63428] New: [4.8/4.9/5 Regression] vshuf-v4di.c miscompilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63428 Bug ID: 63428 Summary: [4.8/4.9/5 Regression] vshuf-v4di.c miscompilation Product: gcc Version: 5.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: target Assignee: jakub at gcc dot gnu.org Reporter: jakub at gcc dot gnu.org Target: x86_64-linux GCC_TEST_RUN_EXPENSIVE=1 make check-gcc \ RUNTESTFLAGS='--target_board=unix/-mavx2 dg-torture.exp=vshuf*.c' fails starting with 4.8 (4.7 works), test_122 function is miscompiled.
[Bug middle-end/61529] [5 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in check_probability, at basic-block.h:953
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61529 --- Comment #4 from David Binderman dcb314 at hotmail dot com --- (In reply to Jakub Jelinek from comment #3) Started with r210538. I am seeing something similar when compiling glibc with trunk 20141001 with only -O2. ../iconv/skeleton.c: In function ‘gconv’: ../iconv/skeleton.c:792:1: internal compiler error: in check_probability, at basic-block.h:959 } ^ 0x10685aa check_probability ../../src/trunk/gcc/basic-block.h:959 0x10685aa apply_probability ../../src/trunk/gcc/basic-block.h:988 0x10685aa compute_outgoing_frequencies ../../src/trunk/gcc/cfgbuild.c:545 0x10685aa find_many_sub_basic_blocks(simple_bitmap_def*) ../../src/trunk/gcc/cfgbuild.c:636 Code ok with 20140927.
[Bug middle-end/63427] hwint.h:250:29: runtime error: shift exponent 64 is too large for 64-bit type 'long int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63427 Kenneth Zadeck zadeck at naturalbridge dot com changed: What|Removed |Added CC||zadeck at naturalbridge dot com --- Comment #1 from Kenneth Zadeck zadeck at naturalbridge dot com --- This failure is caused by the caller trying to sign extend something with a precision of zero. This bug should be fixed upstream of this call.
[Bug pch/63429] New: [Regression 5] Cannot build compiler with --enable-gather-detailed-mem-stats
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63429 Bug ID: 63429 Summary: [Regression 5] Cannot build compiler with --enable-gather-detailed-mem-stats Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: pch Assignee: unassigned at gcc dot gnu.org Reporter: mliska at suse dot cz Error: g++ -c -g -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../gcc -I../../gcc/build -I../../gcc/../include -I../../gcc/../libcpp/include \ -o build/gencondmd.o build/gencondmd.c In file included from ../../gcc/hash-table.h:199:0, from ../../gcc/hash-set.h:24, from ../../gcc/function.h:24, from build/gencondmd.c:25: ../../gcc/ggc.h:165:59: error: default argument given for parameter 3 of ‘void* ggc_realloc(void*, size_t, const char*, int, const char*)’ [-fpermissive] extern void *ggc_realloc (void *, size_t CXX_MEM_STAT_INFO); ^ In file included from ../../gcc/rtl.h:28:0, from build/gencondmd.c:23: ../../gcc/vec.h:54:16: note: previous specification in ‘void* ggc_realloc(void*, size_t, const char*, int, const char*)’ here extern void *ggc_realloc (void *, size_t CXX_MEM_STAT_INFO); ^ In file included from ../../gcc/hash-table.h:199:0, from ../../gcc/hash-set.h:24, from ../../gcc/function.h:24, from build/gencondmd.c:25: ../../gcc/ggc.h:165:59: error: default argument given for parameter 4 of ‘void* ggc_realloc(void*, size_t, const char*, int, const char*)’ [-fpermissive] extern void *ggc_realloc (void *, size_t CXX_MEM_STAT_INFO); ^ In file included from ../../gcc/rtl.h:28:0, from build/gencondmd.c:23: ../../gcc/vec.h:54:16: note: previous specification in ‘void* ggc_realloc(void*, size_t, const char*, int, const char*)’ here extern void *ggc_realloc (void *, size_t CXX_MEM_STAT_INFO); ^ In file included from ../../gcc/hash-table.h:199:0, from ../../gcc/hash-set.h:24, from ../../gcc/function.h:24, from build/gencondmd.c:25: ../../gcc/ggc.h:165:59: error: default argument given for parameter 5 of ‘void* ggc_realloc(void*, size_t, const char*, int, const char*)’ [-fpermissive] extern void *ggc_realloc (void *, size_t CXX_MEM_STAT_INFO); ^ In file included from ../../gcc/rtl.h:28:0, from build/gencondmd.c:23: ../../gcc/vec.h:54:16: note: previous specification in ‘void* ggc_realloc(void*, size_t, const char*, int, const char*)’ here extern void *ggc_realloc (void *, size_t CXX_MEM_STAT_INFO); Started with r214834. Thanks, Martin
[Bug libstdc++/59603] std::random_shuffle tries to swap element with itself
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59603 --- Comment #9 from Jonathan Wakely redi at gcc dot gnu.org --- Author: redi Date: Wed Oct 1 12:34:04 2014 New Revision: 215754 URL: https://gcc.gnu.org/viewcvs?rev=215754root=gccview=rev Log: PR libstdc++/59603 * include/bits/stl_algo.h (random_shuffle): Prevent self-swapping. * testsuite/25_algorithms/random_shuffle/59603.cc: New. Added: branches/gcc-4_9-branch/libstdc++-v3/testsuite/25_algorithms/random_shuffle/59603.cc Modified: branches/gcc-4_9-branch/libstdc++-v3/ChangeLog branches/gcc-4_9-branch/libstdc++-v3/include/bits/stl_algo.h
[Bug fortran/63427] hwint.h:250:29: runtime error: shift exponent 64 is too large for 64-bit type 'long int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63427 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Component|middle-end |fortran --- Comment #2 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Thanks. Backtrace shows that it is a Fortran issue: Breakpoint 1, 0x76e33160 in __ubsan::Diag::~Diag() () from /usr/lib/gcc/x86_64-pc-linux-gnu/5.0.0/libubsan.so.0 (gdb) bt #0 0x76e33160 in __ubsan::Diag::~Diag() () from /usr/lib/gcc/x86_64-pc-linux-gnu/5.0.0/libubsan.so.0 #1 0x76e35e1a in handleShiftOutOfBoundsImpl(__ubsan::ShiftOutOfBoundsData*, unsigned long, unsigned long, __ubsan::ReportOptions) () from /usr/lib/gcc/x86_64-pc-linux-gnu/5.0.0/libubsan.so.0 #2 0x76e36613 in __ubsan_handle_shift_out_of_bounds () from /usr/lib/gcc/x86_64-pc-linux-gnu/5.0.0/libubsan.so.0 #3 0x019d5e10 in sext_hwi (prec=optimized out, src=optimized out) at ../../gcc/gcc/hwint.h:250 #4 set_len (is_sign_extended=optimized out, l=optimized out, this=optimized out) at ../../gcc/gcc/wide-int.h:1075 #5 wi::from_mpz (type=0x11, x=0x53b5e20, wrap=64, wrap@entry=true) at ../../gcc/gcc/wide-int.cc:265 #6 0x007633a5 in gfc_conv_mpz_to_tree (i=0x53b5e20, kind=8) at ../../gcc/gcc/fortran/trans-const.c:206 #7 0x00764c38 in gfc_conv_constant (se=0x7fffd760, expr=0x53b5da0) at ../../gcc/gcc/fortran/trans-const.c:403 #8 0x007aec0b in gfc_conv_expr (se=se@entry=0x7fffd760, expr=expr@entry=0x53b5da0) at ../../gcc/gcc/fortran/trans-expr.c:6520 #9 0x007ba908 in gfc_conv_expr_reference (se=0x7fffd760, expr=0x53b5da0) at ../../gcc/gcc/fortran/trans-expr.c:6651 #10 0x007a0ccf in gfc_conv_procedure_call (se=0x7fffd170, se@entry=0x7fffd8b0, sym=0x4396944, args=0x7fffd1f0, args@entry=0x53aa0d0, expr=0x40, expr@entry=0x0, append_args=0x4396940, append_args@entry=0x0) at ../../gcc/gcc/fortran/trans-expr.c:4429 #11 0x00831728 in gfc_trans_call (code=code@entry=0x53b5e70, dependency_check=optimized out, mask=mask@entry=0x0, count1=count1@entry=0x0, invert=invert@entry=false) at ../../gcc/gcc/fortran/trans-stmt.c:408 #12 0x00726aca in trans_code (code=0x53b5e70, cond=cond@entry=0x0) at ../../gcc/gcc/fortran/trans.c:1717 #13 0x0072a277 in gfc_trans_code (code=optimized out) at ../../gcc/gcc/fortran/trans.c:1928 #14 0x00789f34 in gfc_generate_function_code (ns=optimized out) at ../../gcc/gcc/fortran/trans-decl.c:5789 #15 0x0072a2a5 in gfc_generate_code (ns=optimized out) at ../../gcc/gcc/fortran/trans.c:1945 #16 0x0068148b in translate_all_program_units (gfc_global_ns_list=0x53a48b0) at ../../gcc/gcc/fortran/parse.c:4947 #17 gfc_parse_file () at ../../gcc/gcc/fortran/parse.c:5144 #18 0x00715db8 in gfc_be_parse_file () at ../../gcc/gcc/fortran/f95-lang.c:212 #19 0x0129d388 in compile_file () at ../../gcc/gcc/toplev.c:551 #20 0x012a0aab in do_compile () at ../../gcc/gcc/toplev.c:1946 #21 toplev_main (argc=20, argv=0x7fffe038) at ../../gcc/gcc/toplev.c:2022 #22 0x76ae1fd0 in __libc_start_main () from /lib/libc.so.6 #23 0x0058d3a1 in _start () (gdb)
[Bug c++/63430] New: [5 Regression] internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63430
Bug ID: 63430
Summary: [5 Regression] internal compiler error: Segmentation
fault
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ai.azuma at gmail dot com
Created attachment 33635
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33635action=edit
Output of -v option and preprocessed file
The following valid code causes segfault with GCC 5.0.0 20140928.
//==
extern int f(int *);
static int i __attribute__ ((__weakref__(f)));
templatetypename T
class X
{
static __thread T* value_;
};
//==
Note that the above code compiles successfully with 4.9.2 20140924 and 4.8.4
20140925.
[Bug c/63421] GCC generates a very misleading warning when looking at an erroneously-overloaded type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63421 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||manu at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Manuel López-Ibáñez manu at gcc dot gnu.org --- Duplicate. There is a bug in the pretty-printer and also we should do typedef unwrapping in the C FE. *** This bug has been marked as a duplicate of bug 56980 ***
[Bug c/56980] C pretty-printer does not handle well pointer to typedef of struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56980 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||gccbugs at dima dot secretsauce.ne ||t --- Comment #6 from Manuel López-Ibáñez manu at gcc dot gnu.org --- *** Bug 63421 has been marked as a duplicate of this bug. ***
[Bug middle-end/63422] [5.0 Regression] ICE in freqs_to_counts_path, at tree-ssa-threadupdate.c:981
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63422 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added CC||trippels at gcc dot gnu.org --- Comment #4 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Created attachment 33636 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33636action=edit testcase Here is a relative small testcase: markus@x4 /tmp % g++ -flto -fprofile-use -fno-exceptions -std=gnu++0x -O2 mozilla-xremote-client.ii XRemoteClient.ii /var/tmp/mozilla-central/widget/xremoteclient/mozilla-xremote-client.cpp: In function ‘main’: /var/tmp/mozilla-central/widget/xremoteclient/mozilla-xremote-client.cpp:16:5: internal compiler error: in freqs_to_counts_path, at tree-ssa-threadupdate.c:988 int main(int argc, char **argv) ^ 0xb00cf0 freqs_to_counts_path ../../gcc/gcc/tree-ssa-threadupdate.c:988 0xb00cf0 ssa_fix_duplicate_block_edges(redirection_data*, ssa_local_info_t*) ../../gcc/gcc/tree-ssa-threadupdate.c:1061 0xb02260 ssa_fixup_template_block ../../gcc/gcc/tree-ssa-threadupdate.c:1301 0xb02260 traverse_noresizessa_local_info_t*, ssa_fixup_template_block ../../gcc/gcc/hash-table.h:942 0xb02260 traversessa_local_info_t*, ssa_fixup_template_block ../../gcc/gcc/hash-table.h:964 0xb02260 thread_block_1 ../../gcc/gcc/tree-ssa-threadupdate.c:1523 0xb02994 thread_block ../../gcc/gcc/tree-ssa-threadupdate.c:1560 0xb031dd thread_through_all_blocks(bool) ../../gcc/gcc/tree-ssa-threadupdate.c:2279 0xb856a1 finalize_jump_threads ../../gcc/gcc/tree-vrp.c:9856 0xb856a1 execute_vrp ../../gcc/gcc/tree-vrp.c:10010 0xb856a1 execute ../../gcc/gcc/tree-vrp.c:10073 Please submit a full bug report,
[Bug preprocessor/59805] invalid preprocessing directive not diagnosed with assembler-with-cpp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59805 --- Comment #2 from joseph at codesourcery dot com joseph at codesourcery dot com --- If there's something in the preprocessor that does this deliberately for assembler-with-cpp instead of being an accidental consequence of something else, then it's probably working as designed.
[Bug c/63307] [4.9/5 Regression] Cilk+ breaks -fcompare-debug bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63307 --- Comment #5 from Igor Zamyatin izamyatin at gmail dot com --- (In reply to Jakub Jelinek from comment #4) I don't think so. They copy declarations, i.e. create new declarations, and the different ordering of their DECL_UID values may result in code generation differences (e.g. various other spots in the compiler sort based on DECL_UIDs, if you create them in pretty random order, you'll surely trigger some -fcompare-debug (perhaps not with current limited testsuite coverage, but with other tests). Right, thanks for the clarification. Will prepare the whole patch then
[Bug middle-end/54303] -fdata-sections -ffunction-sections and -fmerge-constants do not work well together
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54303 Andrew Haley aph at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-10-01 CC||aph at gcc dot gnu.org Ever confirmed|0 |1
[Bug middle-end/63422] [5.0 Regression] ICE in freqs_to_counts_path, at tree-ssa-threadupdate.c:981
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63422 --- Comment #5 from Teresa Johnson tejohnson at google dot com --- Thanks for the test case. Reproduced and looking at it. Teresa
[Bug c++/63419] verify_gimple failed: vector CONSTRUCTOR element is not a GIMPLE value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63419 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-10-01 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Mine.
[Bug ipa/63416] Three calls to empty functions via pointers get folded, but not inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63416 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization CC||hubicka at gcc dot gnu.org --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Must be sth wrong with size/time estimates. Honza?
[Bug c++/63430] [5 Regression] internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63430 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |5.0
[Bug target/63428] [4.8/4.9/5 Regression] vshuf-v4di.c miscompilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63428 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.4
[Bug middle-end/63186] [4.9 Regression] Undefined .L* symbols because of fnsplit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63186 --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Wed Oct 1 14:41:49 2014 New Revision: 215765 URL: https://gcc.gnu.org/viewcvs?rev=215765root=gccview=rev Log: Backported from mainline 2014-09-10 Jan Hubicka hubi...@ucw.cz PR tree-optimization/63186 * ipa-split.c (test_nonssa_use): Skip nonforced labels. (mark_nonssa_use): Likewise. (verify_non_ssa_vars): Verify all header blocks for label definitions. * gcc.dg/pr63186.c: New testcase. Added: branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/pr63186.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/ipa-split.c branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug middle-end/63422] [5.0 Regression] ICE in freqs_to_counts_path, at tree-ssa-threadupdate.c:981
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63422 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |5.0
[Bug debug/63285] [4.9 Regression] -fcompare-debug scheduler related failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63285 --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Wed Oct 1 14:42:46 2014 New Revision: 215766 URL: https://gcc.gnu.org/viewcvs?rev=215766root=gccview=rev Log: Backported from mainline 2014-09-18 Vladimir Makarov vmaka...@redhat.com PR debug/63285 * haifa-sched.c (schedule_block): Advance cycle at the end of BB if advance != 0. * gcc.target/i386/pr63285.c: New test. Added: branches/gcc-4_9-branch/gcc/testsuite/gcc.target/i386/pr63285.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/haifa-sched.c branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug c++/63431] New: implicit conversion changes value but no warning ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63431
Bug ID: 63431
Summary: implicit conversion changes value but no warning ?
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Given C++ source code
extern void g(int);
void f(int p1)
{
int i;
if (p1 = 0)
i = 0.01;
else
i = -0.02;
g(i);
}
trunk 20141001 says nothing, even with provocation:
$ ~/gcc/results/bin/g++ -c -O2 -Wall -Wextra oct1a.cc
$
Here is clang being a bit more helpful:
$ clang++ -c -O2 -Wall -Wextra oct1a.cc
oct1a.cc:9:7: warning: implicit conversion from 'double' to 'int' changes value
from 0.01 to 0 [-Wliteral-conversion]
i = 0.01;
~ ^~~~
oct1a.cc:11:8: warning: implicit conversion from 'double' to 'int' changes
value
from 0.02 to 0 [-Wliteral-conversion]
i = -0.02;
~ ^~~~
2 warnings generated.
$
There are half a dozen examples of this in Fedora's current Linux source code.
[Bug c++/63430] [5 Regression] internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63430 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 61558 ***
[Bug regression/61510] [4.10 Regression]: 20_util/scoped_allocator/requirements/explicit_instantiation.cc and tr1/6_containers/tuple/requirements/explicit_instantiation.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61510 --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Wed Oct 1 14:46:32 2014 New Revision: 215767 URL: https://gcc.gnu.org/viewcvs?rev=215767root=gccview=rev Log: PR c++/63306 Backported from mainline 2014-08-01 James Greenhalgh james.greenha...@arm.com PR regression/61510 * cgraphunit.c (analyze_functions): Use get_create rather than get for decls which are clones of abstract functions. * g++.dg/ipa/pr63306.C: New test. Added: branches/gcc-4_9-branch/gcc/testsuite/g++.dg/ipa/pr63306.C Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/cgraphunit.c branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug middle-end/61558] [5 Regression] ICE: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61558 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added CC||ai.azuma at gmail dot com --- Comment #9 from Markus Trippelsdorf trippels at gcc dot gnu.org --- *** Bug 63430 has been marked as a duplicate of this bug. ***
[Bug c++/63306] [4.9 Regression] ICE: Segmentation fault in analyze_functions()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63306 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Wed Oct 1 14:46:32 2014 New Revision: 215767 URL: https://gcc.gnu.org/viewcvs?rev=215767root=gccview=rev Log: PR c++/63306 Backported from mainline 2014-08-01 James Greenhalgh james.greenha...@arm.com PR regression/61510 * cgraphunit.c (analyze_functions): Use get_create rather than get for decls which are clones of abstract functions. * g++.dg/ipa/pr63306.C: New test. Added: branches/gcc-4_9-branch/gcc/testsuite/g++.dg/ipa/pr63306.C Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/cgraphunit.c branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug middle-end/61558] [5 Regression] ICE: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61558 --- Comment #10 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Honza?
[Bug tree-optimization/63375] [4.8/4.9/5 Regression] reordering of reads across fences
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63375 --- Comment #5 from Martin Jambor jamborm at gcc dot gnu.org --- I'v posted the SRA patch to the mailing list: https://gcc.gnu.org/ml/gcc-patches/2014-10/msg00062.html
[Bug c++/63431] implicit conversion changes value but no warning ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63431 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- -Wconversion
[Bug c++/55077] implement and enable by default -Wliteral-conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55077 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||dcb314 at hotmail dot com --- Comment #4 from Manuel López-Ibáñez manu at gcc dot gnu.org --- *** Bug 63431 has been marked as a duplicate of this bug. ***
[Bug c++/63431] implicit conversion changes value but no warning ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63431 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||manu at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #2 from Manuel López-Ibáñez manu at gcc dot gnu.org --- There is a patch to make this enabled by default, but I didn't have time to push it for review. *** This bug has been marked as a duplicate of bug 55077 ***
[Bug c++/55077] implement and enable by default -Wliteral-conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55077 --- Comment #5 from Manuel López-Ibáñez manu at gcc dot gnu.org --- Created attachment 33637 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33637action=edit untested patch Untested patch. Bonus points if we show the value before and after conversion like clang does.
[Bug middle-end/63325] [5.0 regression] ICE fold check: original tree changed by fold
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63325 Thomas Schwinge tschwinge at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-10-01 CC||tschwinge at gcc dot gnu.org Ever confirmed|0 |1
[Bug c++/63431] implicit conversion changes value but no warning ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63431 --- Comment #3 from David Binderman dcb314 at hotmail dot com --- (In reply to Jonathan Wakely from comment #1) -Wconversion Thanks for that. I tried it out and I got far more warnings than I could triage. While all the new warnings that I checked seemed technically accurate, very few seem useful. E.g. for source code float end = 9434.20 + 42994.82; I got aug4a.cc:7:23: warning: conversion to ‘float’ alters ‘double’ constant value [-Wfloat-conversion] float end = 9434.20 + 42994.82; ^ Floats and doubles are only ever approximate, so I used -Wno-float-conversion. That didn't help much. I'd be happier with a much smaller warning that only ever warned for floats and double literals being put into integral types, as per clang.
[Bug bootstrap/63432] New: [5 Regression] profiledbootstrap failure with bootstrap-lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63432 Bug ID: 63432 Summary: [5 Regression] profiledbootstrap failure with bootstrap-lto Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com On Linux/x86-64, r215740 failed to profiledbootstrap when configured with --with-build-config=bootstrap-lto: /export/project/git/gcc-regression/gcc/gcc/genhooks.c: In function ‘emit_documentation’: /export/project/git/gcc-regression/gcc/gcc/genhooks.c:117:1: internal compiler error: in freqs_to_counts_path, at tree-ssa-threadupdate.c:981 emit_documentation (const char *in_fname) ^ 0x107902e freqs_to_counts_path /export/project/git/gcc-regression/gcc/gcc/tree-ssa-threadupdate.c:981 0x107902e ssa_fix_duplicate_block_edges(redirection_data*, ssa_local_info_t*) /export/project/git/gcc-regression/gcc/gcc/tree-ssa-threadupdate.c:1061 0x10791ea ssa_create_duplicates(redirection_data**, ssa_local_info_t*) /export/project/git/gcc-regression/gcc/gcc/tree-ssa-threadupdate.c:1275 0x1080149 void hash_tableredirection_data, xcallocator, false::traverse_noresizessa_local_info_t*, (ssa_create_duplicates(redirection_data**, ssa_local_info_t*))(ssa_local_info_t*) /export/project/git/gcc-regression/gcc/gcc/hash-table.h:942 0x1080149 void hash_tableredirection_data, xcallocator, false::traversessa_local_info_t*, (ssa_create_duplicates(redirection_data**, ssa_local_info_t*))(ssa_local_info_t*) /export/project/git/gcc-regression/gcc/gcc/hash-table.h:964 0x10794b3 thread_block_1 /export/project/git/gcc-regression/gcc/gcc/tree-ssa-threadupdate.c:1515 0x107d556 thread_block /export/project/git/gcc-regression/gcc/gcc/tree-ssa-threadupdate.c:1559 0x107d556 thread_through_all_blocks(bool) /export/project/git/gcc-regression/gcc/gcc/tree-ssa-threadupdate.c:2279 0x114eecb finalize_jump_threads /export/project/git/gcc-regression/gcc/gcc/tree-vrp.c:9856 0x114eecb execute_vrp /export/project/git/gcc-regression/gcc/gcc/tree-vrp.c:10010 0x114eecb execute /export/project/git/gcc-regression/gcc/gcc/tree-vrp.c:10073 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. make[4]: *** [/tmp/ccyuxuEg.ltrans0.ltrans.o] Error 1 lto-wrapper: fatal error: make returned 2 exit status compilation terminated. /bin/ld: lto-wrapper failed r215738 is OK. r215739 may be the cause.
[Bug c++/63431] implicit conversion changes value but no warning ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63431 --- Comment #4 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to David Binderman from comment #3) I'd be happier with a much smaller warning that only ever warned for floats and double literals being put into integral types, as per clang. See the patch attached in PR55077. As always, someone has to spend their time to submit it and get it reviewed. We need (many) more contributors to gcc, specially the front-ends.
[Bug middle-end/63422] [5.0 Regression] ICE in freqs_to_counts_path, at tree-ssa-threadupdate.c:981
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63422 --- Comment #6 from Teresa Johnson tejohnson at google dot com --- My new code is exposing an upstream profile count insanity that is being introduced by the copyrename2 phase. The new freqs_to_counts_path routine is invoked only when we don't have profile info, and in this case main() is in mozilla-xremote-client.ii which does not have a gcda file. So the profile status for the fn != PROFILE_READ. Before copyrename2, all the counts in main() are 0, and everything looks fine. But coming out of copyrename2, some of the blocks and edges have a count == 1. So my assert in freqs_to_counts_path that expects the edges to all have 0 weight is firing. The two approaches I could take are to either skip freqs_to_counts if there are actually non-zero counts or simply remove the assert with a comment about upstream insanities. I am probably going to do the latter, because the former will result in really insane frequencies coming out of jump threading (the updates are based on counts, which in this case are bogus coming in). It would be good to figure out why copyrename2 is introducing non-zero counts, but presumably there is some kind of profile update that has an off-by-one error? I don't see any count manipulation within tree-ssa-copyrename.c itself.
[Bug bootstrap/63432] [5 Regression] profiledbootstrap failure with bootstrap-lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63432 Teresa Johnson tejohnson at google dot com changed: What|Removed |Added CC||tejohnson at google dot com --- Comment #1 from Teresa Johnson tejohnson at google dot com --- Looks like a dup of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63422, due to incoming profile insanities. Will loosen up the new assert. Teresa
[Bug c++/63433] New: init_priority not working on ARM target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63433 Bug ID: 63433 Summary: init_priority not working on ARM target Product: gcc Version: 4.8.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: marcelo at brs dot ind.br Target: ARM I think this was started on bug #46770 (already closed). In 4.8.4 ARM target, init_priority is not working across TUs. I have a class declared on a static library with __attribute__ ((init_priority (101))). On main project i have another class declared with no attributes. The main project's class constructor is called before the static library class. In bug #46770 there's a comment that say that library's constructors will always be called after main project. But this is wrong by description of init_priority attribute. Both files (main e library) are compiled with 4.8.4 gcc version. Both creates init_array structs. Is there a way to change constructor order?
[Bug other/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770 Marcelo Richter marcelo at brs dot ind.br changed: What|Removed |Added CC||marcelo at brs dot ind.br --- Comment #105 from Marcelo Richter marcelo at brs dot ind.br --- Any news on that? With gcc 4.8.4 (ARM target), init_priority attribute doesn't work with a static library and main C++ file. I have a class declared in library with __attribute__ ((init_priority (101))). In main project, another class declared with no attributes. The main class constructor is called BEFORE library constructor (with high priority attribute).
[Bug c++/63362] The c++11 triviality-traits need front-end help
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63362 --- Comment #7 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Wed Oct 1 17:21:08 2014 New Revision: 215772 URL: https://gcc.gnu.org/viewcvs?rev=215772root=gccview=rev Log: PR c++/63362 * method.c (constructible_expr): Handle value-init of non-class. * parser.c (cp_parser_trait_expr): Allow pack expansion. * pt.c (tsubst_copy_and_build): Handle pack expansion. Added: trunk/gcc/testsuite/g++.dg/ext/is_trivially_constructible3.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/method.c trunk/gcc/cp/parser.c trunk/gcc/cp/pt.c
[Bug c++/63362] The c++11 triviality-traits need front-end help
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63362 --- Comment #6 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Wed Oct 1 17:21:01 2014 New Revision: 215771 URL: https://gcc.gnu.org/viewcvs?rev=215771root=gccview=rev Log: PR c++/63362 * class.c (type_has_non_user_provided_default_constructor): Rename from type_has_user_provided_default_constructor, reverse sense. (default_init_uninitialized_part, explain_non_literal_class): Adjust. (check_bases_and_members): Set TYPE_HAS_COMPLEX_DFLT. * call.c (build_new_method_call_1): Adjust. * cp-tree.h: Adjust. * decl.c (grok_special_member_properties): Don't set TYPE_HAS_COMPLEX_DFLT. * init.c (build_value_init_noctor): Don't use type_has_user_provided_default_constructor. Added: trunk/gcc/testsuite/g++.dg/ext/is_trivially_constructible2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/cp/class.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/decl.c trunk/gcc/cp/init.c
[Bug libstdc++/60132] C++11: lack of is_trivially_copy_constructible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60132 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-10-01 Component|c++ |libstdc++ Ever confirmed|0 |1
[Bug libstdc++/60132] C++11: lack of is_trivially_copy_constructible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60132 Ville Voutilainen ville.voutilainen at gmail dot com changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ville.voutilainen at gmail dot com --- Comment #2 from Ville Voutilainen ville.voutilainen at gmail dot com --- Mine.
[Bug libstdc++/60132] C++11: lack of is_trivially_copy_constructible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60132 Ville Voutilainen ville.voutilainen at gmail dot com changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug debug/62225] DW_AT_location for local variable is missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62225 --- Comment #5 from Sandra Loosemore sandra at codesourcery dot com --- Thinking about this some more Why doesn't -g always enable -fvar-tracking by default? It's currently only enabled if you specify both -g and -O.
[Bug c++/63386] Release version of CB wont compile Bullet (-o2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63386
--- Comment #7 from TechoMan root at borealis dot su ---
https://github.com/bulletphysics/bullet3/blob/master/src/BulletCollision/CollisionDispatch/btInternalEdgeUtility.cpp
- that file. For 3.x line would be 310 , '{'.
[Bug other/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770 --- Comment #106 from Marcelo Richter marcelo at brs dot ind.br --- Update: init_priority not work across TUs. It works to change constructor order in same CPP file. Between .cpp files or between cpp and library, it not work.
[Bug other/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770 --- Comment #107 from Ian Lance Taylor ian at airs dot com --- This problem report is closed. If you want to report a new bug, please open a new problem report. Using init_priority does work in general across translation units. There may be a bug in your environment. In your new problem report, be sure to give an example of source code, and mention the exact version of the compiler and linker you are using.
[Bug c/63434] New: builtins.c has incorrect parameters for GEN_CALL_VALUE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63434 Bug ID: 63434 Summary: builtins.c has incorrect parameters for GEN_CALL_VALUE Product: gcc Version: 4.8.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: steve at hearnden dot org.uk When trying to compile a new machine description, I found that testsuite testsuite/gcc.c-torture/compile/930623-1.c was crashing. The machine description needs a 4th parameter to be added. On investigation of the cause, my 4th parameter to the call function (number of registers) had been set to NULL. With some searching, it appears that the builtins don't work when the 4th Parameter is added, or require it to be specially coded. I believe the correct fix is described below - switching the last two parameters emit_call_insn (GEN_CALL_VALUE (valreg, gen_rtx_MEM (FUNCTION_MODE, function), - const0_rtx, NULL_RTX, const0_rtx)); + const0_rtx, const0_rtx, NULL_RTX));
[Bug c++/53025] [C++11] noexcept operator depends on copy-elision
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53025 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #6 from Jason Merrill jason at gcc dot gnu.org --- I think this is a question for CWG. EDG matches G++ on your testcases.
[Bug c++/62056] Long compile times with large tuples
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62056 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||jwakely.gcc at gmail dot com --- Comment #11 from Manuel López-Ibáñez manu at gcc dot gnu.org --- Jonathan, what should we do about this? Is this implementation better than the one in libstdc++? If so, what steps are needed to get this integrated?
[Bug libstdc++/62056] Long compile times with large tuples
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62056 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Component|c++ |libstdc++ --- Comment #12 from Manuel López-Ibáñez manu at gcc dot gnu.org --- I think this is a libstdc++ issue for now. It would be nice to have a simpler testcase for the g++ compile time problem, then we can open a different independent report.
[Bug target/63428] [4.8/4.9/5 Regression] vshuf-v4di.c miscompilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63428 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Wed Oct 1 20:40:29 2014 New Revision: 215776 URL: https://gcc.gnu.org/viewcvs?rev=215776root=gccview=rev Log: PR target/63428 * config/i386/i386.c (expand_vec_perm_pshufb): Fix up rperm[0] argument to avx2_permv2ti. * gcc.dg/torture/vshuf-4.inc: Move test 122 from EXPTESTS to test 24 in TESTS. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/torture/vshuf-4.inc
[Bug c++/63306] [4.9 Regression] ICE: Segmentation fault in analyze_functions()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63306 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Wed Oct 1 20:42:23 2014 New Revision: 215779 URL: https://gcc.gnu.org/viewcvs?rev=215779root=gccview=rev Log: PR c++/63306 * g++.dg/ipa/pr63306.C: New test. Added: trunk/gcc/testsuite/g++.dg/ipa/pr63306.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug target/63404] [5 Regression] gcc 5 miscompiles linux block layer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63404 --- Comment #10 from Pat Haugen pthaugen at gcc dot gnu.org --- (In reply to Jiong Wang from comment #8) and I am curious about whether there are any performance change since this insn sink change. I built/ran cpu2000 and didn't see any difference outside the noise range. The number of shrink-wrapped procedures over the entire benchmark suite build went from 558 to 567.
[Bug target/63428] [4.8/4.9/5 Regression] vshuf-v4di.c miscompilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63428 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Wed Oct 1 20:45:12 2014 New Revision: 215780 URL: https://gcc.gnu.org/viewcvs?rev=215780root=gccview=rev Log: PR target/63428 * config/i386/i386.c (expand_vec_perm_pshufb): Fix up rperm[0] argument to avx2_permv2ti. * gcc.dg/torture/vshuf-4.inc: Move test 122 from EXPTESTS to test 24 in TESTS. Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/config/i386/i386.c branches/gcc-4_9-branch/gcc/testsuite/ChangeLog branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/torture/vshuf-4.inc
[Bug libstdc++/62056] Long compile times with large tuples
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62056 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Severity|normal |enhancement
[Bug target/63428] [4.8/4.9/5 Regression] vshuf-v4di.c miscompilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63428 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Wed Oct 1 20:47:29 2014 New Revision: 215781 URL: https://gcc.gnu.org/viewcvs?rev=215781root=gccview=rev Log: PR target/63428 * config/i386/i386.c (expand_vec_perm_pshufb): Fix up rperm[0] argument to avx2_permv2ti. * gcc.dg/torture/vshuf-4.inc: Move test 122 from EXPTESTS to test 24 in TESTS. Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/config/i386/i386.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/torture/vshuf-4.inc
[Bug debug/63342] [5 Regression] ICE in loc_list_from_tree, at dwarf2out.c:14698
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63342 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Wed Oct 1 20:51:34 2014 New Revision: 215782 URL: https://gcc.gnu.org/viewcvs?rev=215782root=gccview=rev Log: PR debug/63342 * dwarf2out.c (loc_list_from_tree): Handle MEM_REF with non-zero offset, TARGET_MEM_REF and SSA_NAME. * gcc.dg/pr63342.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr63342.c Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c trunk/gcc/testsuite/ChangeLog
[Bug debug/63342] [5 Regression] ICE in loc_list_from_tree, at dwarf2out.c:14698
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63342 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Wed Oct 1 20:57:44 2014 New Revision: 215783 URL: https://gcc.gnu.org/viewcvs?rev=215783root=gccview=rev Log: PR debug/63342 * dwarf2out.c (loc_list_from_tree): Handle TARGET_MEM_REF and SSA_NAME. * gcc.dg/pr63342.c: New test. Added: branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/pr63342.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/dwarf2out.c branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug debug/63342] [5 Regression] ICE in loc_list_from_tree, at dwarf2out.c:14698
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63342 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Wed Oct 1 21:01:39 2014 New Revision: 215784 URL: https://gcc.gnu.org/viewcvs?rev=215784root=gccview=rev Log: PR debug/63342 * dwarf2out.c (loc_list_from_tree): Handle TARGET_MEM_REF and SSA_NAME. * gcc.dg/pr63342.c: New test. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/pr63342.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/dwarf2out.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug target/53568] SH Target: Add support for bswap built-ins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53568 Oleg Endo olegendo at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Oleg Endo olegendo at gcc dot gnu.org --- I'd like to close this PR, since the basic functionality is there.
[Bug c++/61489] Wrong warning with -Wmissing-field-initializers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61489 Daniel Sommermann dcsommer at fb dot com changed: What|Removed |Added CC||dcsommer at fb dot com --- Comment #10 from Daniel Sommermann dcsommer at fb dot com --- Which release will this go out in?
[Bug debug/62225] DW_AT_location for local variable is missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62225 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org --- Comment #6 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Why doesn't -g always enable -fvar-tracking by default? It's currently only enabled if you specify both -g and -O. The full answer is in the gcc-patches@ archives. The short answer is that it essentially doesn't work at -O0.
[Bug middle-end/63325] [5.0 regression] ICE fold check: original tree changed by fold
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63325 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot gnu.org --- Comment #3 from Jan Hubicka hubicka at gcc dot gnu.org --- Mine.
[Bug c/63435] New: Bad code with weak vs localalias on AIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63435 Bug ID: 63435 Summary: Bad code with weak vs localalias on AIX Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: gcc at dixie dot net.nz Host: powerpc-ibm-aix7.1.0.0 Target: powerpc-ibm-aix7.1.0.0 Build: powerpc-ibm-aix7.1.0.0 Created attachment 33638 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33638action=edit testcase Consider attached testcase. The recvfrom function is generated as a weak symbol, symtab_node::noninterposable_alias creates a localalias. .weak recvfrom[DS] .weak .recvfrom .csect recvfrom[DS] recvfrom: .long .recvfrom, TOC[tc0], 0 .csect .text[PR] .recvfrom: --- gcc-4.9.1 generates local alias to the weak symbol: .lglobl .recvfrom.localalias.0 .lglobl recvfrom.localalias.0 .set.recvfrom.localalias.0,.recvfrom .set recvfrom.localalias.0,recvfrom --- This local alias is called with local calling convention (missing nop): bl .recvfrom.localalias.0 mr 9,3 --- The linker discards the weak local recvfrom symbol, and chooses recvfrom from libc. The recvfrom in libc is remote and needs a nop instruction. The linker correctly issues a diagnostic about this: ld: 0711-768 WARNING: Object myrecvfrom.o, section 1, function .recvfrom: The branch at address 0xc8 is not followed by a recognized no-op or TOC-reload instruction. The unrecognized instruction is 0x7C691B78. At runtime this results in corrupt TOC pointer (possibly requires larger testcase to observe problems).
[Bug c/63435] Bad code with weak vs localalias on AIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63435 Andrew Dixie gcc at dixie dot net.nz changed: What|Removed |Added CC||dje at gcc dot gnu.org, ||hubicka at gcc dot gnu.org --- Comment #1 from Andrew Dixie gcc at dixie dot net.nz --- This is a regression sometime between gcc-4.4 and gcc-4.9 Looks like it was fixed in gcc-5 by: https://gcc.gnu.org/ml/gcc-patches/2014-07/msg00500.html
[Bug libstdc++/62056] Long compile times with large tuples
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62056 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Keywords||patch Status|WAITING |NEW --- Comment #13 from Manuel López-Ibáñez manu at gcc dot gnu.org --- Thus, I guess this is confirmed, just waiting for a review.
[Bug c++/61489] Wrong warning with -Wmissing-field-initializers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61489 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #11 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Daniel Sommermann from comment #10) Which release will this go out in? GCC 5.1.0 presumably.
[Bug libgcc/63436] New: libgcc2.c:273:1: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63436 Bug ID: 63436 Summary: libgcc2.c:273:1: internal compiler error: Segmentation fault Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: major Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: xhzcomputer at 126 dot com My Steps are as follows: $./gcc-4.7.2/configure --prefix=$CROSS_GCC_TMP --target=$TARGET --with-sysroot=$SYSROOT --with-newlib --enable-languages=c --with-mpfr-include=/vita/build/gcc-4.7.2/mpfr/src --with-mpfr-lib=/vita/build/gcc-build/mpfr/src/.libs --disable-shared --disable-threads --disable-decimal-float --disable-libquadmath --disable-libmudflap --disable-libgomp --disable-nls --disable-libssp $make Then errors are coming: ... ../../../gcc-4.7.2/libgcc/libgcc2.c: In function '__absvdi2': ../../../gcc-4.7.2/libgcc/libgcc2.c:273:1: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[2]: *** [_absvdi2.o] Error 1 make[2]: Leaving directory `/vita/build/gcc-build/i686-none-linux-gnu/libgcc' make[1]: *** [all-target-libgcc] Error 2 make[1]: Leaving directory `/vita/build/gcc-build' make: *** [all] Error 2 How to resolve it?Someone help me please.
[Bug rtl-optimization/62151] [5 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62151 --- Comment #10 from Segher Boessenkool segher at gcc dot gnu.org --- Author: segher Date: Thu Oct 2 02:18:01 2014 New Revision: 215789 URL: https://gcc.gnu.org/viewcvs?rev=215789root=gccview=rev Log: 2014-10-01 Segher Boessenkool seg...@kernel.crashing.org gcc/ PR rtl-optimization/62151 * combine.c (can_combine_p): Allow the destination register of INSN to be clobbered in I3. (subst): Do not substitute into clobbers of registers. gcc/testsuite/ * gcc.dg/combine-clobber.c: New. Modified: trunk/gcc/ChangeLog trunk/gcc/combine.c trunk/gcc/testsuite/ChangeLog
[Bug c++/63437] New: [4.9/5 regression][C++14] Parenthesized movable but not copyable object doesn't compile in return statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63437
Bug ID: 63437
Summary: [4.9/5 regression][C++14] Parenthesized movable but
not copyable object doesn't compile in return
statement
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: flast at flast dot jp
After GCC 4.9, parenthesized movable but not copyable object doesn't compile
in return statement under C++14 mode (C++11 mode does compile).
I'm not sure that the behavior was changed in C++14 spec; Clang seems compile
under both of C++11/14 mode.
example:
struct X // movable but not copyable
{
X() = default;
X(X ) = default;
X(const X ) = delete;
};
X non_parenthesized()
{
X x;
return x; // works
}
X parenthesized()
{
X x;
return (x); // error: use of deleted function 'X::X(const X)'
}
Online compiler results:
- GCC 4.8.2
- C++11 http://melpon.org/wandbox/permlink/lRR60fvDgKfqd0UZ
- C++14 http://melpon.org/wandbox/permlink/BAdrBmEG3euQLnqv
- GCC 4.9.1
- C++11 http://melpon.org/wandbox/permlink/XllfUNu0VV0mnYsu
- C++14 http://melpon.org/wandbox/permlink/qm67F6vODyADgKvQ (fail)
- GCC 5.0 20141001
- C++11 http://melpon.org/wandbox/permlink/21bPbcuXB7S87DUG
- C++14 http://melpon.org/wandbox/permlink/da8AeqX7HrS17T2n (fail)
- Clang 3.5.0
- C++11 http://melpon.org/wandbox/permlink/VqgnlKRTOBHd5IDt
- C++14 http://melpon.org/wandbox/permlink/tAkgLiaD50nOMtEz
[Bug rtl-optimization/62151] [5 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62151 Segher Boessenkool segher at gcc dot gnu.org changed: What|Removed |Added CC||segher at gcc dot gnu.org --- Comment #11 from Segher Boessenkool segher at gcc dot gnu.org --- With the patch in #c10, insn 30/71/72 (from #c7) are now combined, hiding the problem. It looks like the problematic situation can still happen though, with some very improbable instruction sequence (the three-insn combination has to be more expensive than the original first three insns, but the three-insn combination and the four-insn combination together have to be cheaper than the original four insns).
[Bug go/61877] [5 Regression]: reflect: cannot use []string as type string in Call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61877 --- Comment #3 from Michael Hudson-Doyle michael.hudson at linaro dot org --- The problem is that the call to m.Call at https://gcc.gnu.org/viewcvs/gcc/trunk/libgo/go/reflect/makefunc.go?revision=212853view=markup#l133 needs, in this case, to be a call to m.CallSlice. I don't know how it can know when it needs to do that though.
[Bug c++/63437] [4.9/5 regression][C++14] Parenthesized movable but not copyable object doesn't compile in return statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63437 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- in C++14 (a) means the same as static_casttypeof(a) (a). So it is a reference at this point which means const is better than . Or at least that is how I understand this. Does clang implement the C++11 () rule correctly?
[Bug go/61877] [5 Regression]: reflect: cannot use []string as type string in Call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61877 --- Comment #4 from Michael Hudson-Doyle michael.hudson at linaro dot org --- Created attachment 33639 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33639action=edit proposed fix This fix works for me. I can't find any tests of this behaviour -- casting the result of (*reflect.Value).Interface to an actual pointer type and then calling it. Am I just being blind?
[Bug go/61877] [5 Regression]: reflect: cannot use []string as type string in Call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61877 --- Comment #5 from Ian Lance Taylor ian at airs dot com --- Hmmm, I don't quite see how that patch could be correct. Does it do the right thing for both f(a, b, c) and f(a, sliceval...)? Any test would look like TestMethodValue in all_test.go, but it looks like that doesn't test a variadic function. Or in TestMakeFuncVariadic, but it looks like that doesn't test a method value.
