[Bug lto/79587] ICE in streamer_write_gcov_count_stream, at data-streamer-out.c:343 while building Python 3.6.0 with PGO and LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79587 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-02-18 CC||trippels at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Markus Trippelsdorf --- Confirmed. Also happens on trunk: (gdb) p work $1 = -1099511627775 (gdb) p ob $2 = (output_block *) 0x1e2a970 (gdb) p *ob $3 = { section_type = LTO_section_function_body, decl_state = 0x1e2a550, main_stream = 0x1e2a620, string_stream = 0x1e2a6a0, cfg_stream = 0x1e2a740, string_hash_table = 0x1e2a770, symbol = 0x76f24450, current_file = 0x1eb0e80 "/home/markus/tmp/Python-3.6.0/Modules/_decimal/libmpdec/crt.c", current_line = 159, current_col = 24, current_sysp = false, writer_cache = 0x1e2a6d0, obstack = { chunk_size = 65536, chunk = 0x1f30ff0, object_base = 0x1f312e0 '\257' , next_free = 0x1f312e0 '\257' , chunk_limit = 0x1f40ff0 "", temp = { i = 0, p = 0x0 }, alignment_mask = 15, chunkfun = { plain = 0x13aeaf0 , extra = 0x13aeaf0 }, freefun = { plain = 0x13aebd0 , extra = 0x13aebd0 }, extra_arg = 0x0, use_extra_arg = 0, maybe_empty_object = 0, alloc_failed = 0 } } (gdb) cont Continuing. /home/markus/tmp/Python-3.6.0/Modules/_decimal/libmpdec/crt.c: In function ‘crt3’: /home/markus/tmp/Python-3.6.0/Modules/_decimal/libmpdec/crt.c:177:1: internal compiler error: in streamer_write_gcov_count_stream, at data-streamer-out.c:343 } ^ 0x1273565 streamer_write_gcov_count_stream(lto_output_stream*, long) /home/markus/gcc/gcc/data-streamer-out.c:343 0x1273565 streamer_write_gcov_count(output_block*, long) /home/markus/gcc/gcc/data-streamer-out.c:228 0xe39e8d stream_out_histogram_value(output_block*, histogram_value_t*) /home/markus/gcc/gcc/value-prof.c:368 0x12a7170 output_gimple_stmt /home/markus/gcc/gcc/gimple-streamer-out.c:195 0x12a7170 output_bb(output_block*, basic_block_def*, function*) /home/markus/gcc/gcc/gimple-streamer-out.c:225 0xa0a5a5 output_function /home/markus/gcc/gcc/lto-streamer-out.c:2128 0xa0a5a5 lto_output() /home/markus/gcc/gcc/lto-streamer-out.c:2343 0xa78f4e write_lto /home/markus/gcc/gcc/passes.c:2578 0xa7cd56 ipa_write_summaries_1 /home/markus/gcc/gcc/passes.c:2642 0xa7cd56 ipa_write_summaries() /home/markus/gcc/gcc/passes.c:2702 0x7432e9 ipa_passes /home/markus/gcc/gcc/cgraphunit.c:2368 0x7432e9 symbol_table::compile() /home/markus/gcc/gcc/cgraphunit.c:2462 0x745b94 symbol_table::compile() /home/markus/gcc/gcc/cgraphunit.c:2624 0x745b94 symbol_table::finalize_compilation_unit() /home/markus/gcc/gcc/cgraphunit.c:2621
[Bug lto/79587] ICE in streamer_write_gcov_count_stream, at data-streamer-out.c:343 while building Python 3.6.0 with PGO and LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79587 --- Comment #3 from Markus Trippelsdorf --- Created attachment 40768 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40768&action=edit testcase for trunk
[Bug lto/79587] ICE in streamer_write_gcov_count_stream, at data-streamer-out.c:343 while building Python 3.6.0 with PGO and LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79587 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org --- Comment #4 from Martin Liška --- I'll take a look at Monday.
[Bug c/35503] Warning about restricted pointers?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35503 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #5 from Martin Liška --- Can we close this PR as resolved?
[Bug c++/79588] New: [7 Regression] ICE in warn_for_restrict with -Wrestrict
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79588 Bug ID: 79588 Summary: [7 Regression] ICE in warn_for_restrict with -Wrestrict Product: gcc Version: unknown Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: prathamesh3492 at gcc dot gnu.org Target Milestone: --- Starting from revision where -Wrestrict was introduced (r242366), we ICE: $ g++ /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/opt/expect2.C -Wrestrict /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/opt/expect2.C: In function ‘void bar()’: /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/opt/expect2.C:10:26: internal compiler error: Segmentation fault __builtin_expect (foo () && true, 1) ? 0 : (abort (), 0); ^ 0xb8b2af crash_signal ../../gcc/toplev.c:337 0x7f7008 warn_for_restrict(unsigned int, vec*) ../../gcc/c-family/c-warn.c:2176 0x6ef18a cp_parser_postfix_expression ../../gcc/cp/parser.c:6952 0x6ed1fa cp_parser_unary_expression ../../gcc/cp/parser.c:8124 0x6f5497 cp_parser_cast_expression ../../gcc/cp/parser.c:8801 0x6f5a2d cp_parser_binary_expression ../../gcc/cp/parser.c:8902 0x6f6120 cp_parser_assignment_expression ../../gcc/cp/parser.c:9189 0x6f7906 cp_parser_parenthesized_expression_list ../../gcc/cp/parser.c:7595 0x6eea2e cp_parser_postfix_expression ../../gcc/cp/parser.c:6850 0x6ed1fa cp_parser_unary_expression ../../gcc/cp/parser.c:8124 0x6f5497 cp_parser_cast_expression ../../gcc/cp/parser.c:8801 0x6f5a2d cp_parser_binary_expression ../../gcc/cp/parser.c:8902 0x6f6120 cp_parser_assignment_expression ../../gcc/cp/parser.c:9189 0x6f848a cp_parser_expression ../../gcc/cp/parser.c:9358 0x6f89f8 cp_parser_expression_statement ../../gcc/cp/parser.c:10906 0x707667 cp_parser_statement ../../gcc/cp/parser.c:10722 0x7081e4 cp_parser_statement_seq_opt ../../gcc/cp/parser.c:11048 0x7082bf cp_parser_compound_statement ../../gcc/cp/parser.c:11002 0x7039c3 cp_parser_function_body ../../gcc/cp/parser.c:21445 0x7039c3 cp_parser_ctor_initializer_opt_and_function_body ../../gcc/cp/parser.c:21481
[Bug sanitizer/79589] New: ICE in gimplify_compound_expr (gimplify.c:5712) with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79589 Bug ID: 79589 Summary: ICE in gimplify_compound_expr (gimplify.c:5712) with -fsanitize=undefined Product: gcc Version: unknown Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, mpolacek at gcc dot gnu.org Target Milestone: --- Running trunk, following ICEs: $ g++ /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/cpp1z/decomp18.C -fsanitize=undefined -c -std=c++14 /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/cpp1z/decomp18.C: In function ‘void foo()’: /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/cpp1z/decomp18.C:10:15: warning: decomposition declaration only available with -std=c++1z or -std=gnu++1z for (auto & [ b, c, d, e, f, g, h, i, j, k, l, m, n, o, p, q, r, s ] : a) // { dg-warning "decomposition declaration only available with" "" { target c++14_down } } ^ /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/cpp1z/decomp18.C:11:12: internal compiler error: Segmentation fault z += b + c + d + e + f + g + h + i + j + k + l + m + n + o + p + q + r + s; ~~^~~ 0xb8b2af crash_signal ../../gcc/toplev.c:337 0x988e5a gimplify_compound_expr ../../gcc/gimplify.c:5712 0x985c97 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../gcc/gimplify.c:11181 0x98822a gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../gcc/gimplify.c:11312 0x985572 gimplify_compound_lval ../../gcc/gimplify.c:2844 0x985572 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../gcc/gimplify.c:11144 0x98563a gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../gcc/gimplify.c:11132 0x985334 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../gcc/gimplify.c:11920 0x985334 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../gcc/gimplify.c:11920 0x985334 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../gcc/gimplify.c:11920 0x985334 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../gcc/gimplify.c:11920 0x985334 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../gcc/gimplify.c:11920 0x985334 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../gcc/gimplify.c:11920 0x985334 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../gcc/gimplify.c:11920 0x985334 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../gcc/gimplify.c:11920 0x985334 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../gcc/gimplify.c:11920 0x985334 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../gcc/gimplify.c:11920 0x985334 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../gcc/gimplify.c:11920 0x985334 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../gcc/gimplify.c:11920 0x985334 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../gcc/gimplify.c:11920
[Bug c/35503] Warning about restricted pointers?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35503 --- Comment #6 from Samuel Thibault --- Well, yes and no: -Wrestrict does indeed warn about this in gcc 7 now, but -Wall -Wextra does not contain -Wrestrict, so that makes it almost useless. Is there a reason for not including -Wrestrict in at least -Wextra (I'd even argue for -Wall because it's really sure that there is a bug in code doing this)
[Bug target/79559] [5/6/7 Regression] ICE in ix86_print_operand, at config/i386/i386.c:18189
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79559 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Sat Feb 18 13:13:43 2017 New Revision: 245560 URL: https://gcc.gnu.org/viewcvs?rev=245560&root=gcc&view=rev Log: PR target/79559 * config/i386/i386.c (ix86_print_operand): Use output_operand_lossage instead of gcc_assert for K, r and R code checks. Formatting fixes. * gcc.target/i386/pr79559.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr79559.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog
[Bug target/79569] Unrecognized command line option ‘-m3dnowa’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79569 --- Comment #6 from Jakub Jelinek --- Author: jakub Date: Sat Feb 18 13:14:43 2017 New Revision: 245561 URL: https://gcc.gnu.org/viewcvs?rev=245561&root=gcc&view=rev Log: PR target/79569 * config/i386/i386.opt (m3dnowa): Replace Undocumented with Report. * common/config/i386/i386-common.c (OPTION_MASK_ISA_3DNOW_A_SET): Define. (ix86_handle_option): Handle OPT_m3dnowa. * doc/invoke.texi (-m3dnowa): Document. * doc/extend.texi (__builtin_ia32_pmulhuw, __builtin_ia32_pf2iw): Use -m3dnowa instead of -m3dnow -march=athlon. * gcc.target/i386/3dnowA-3.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/3dnowA-3.c Modified: trunk/gcc/ChangeLog trunk/gcc/common/config/i386/i386-common.c trunk/gcc/config/i386/i386.opt trunk/gcc/doc/extend.texi trunk/gcc/doc/invoke.texi trunk/gcc/testsuite/ChangeLog
[Bug libstdc++/68739] FAIL: 30_threads/call_once/constexpr.cc (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68739 --- Comment #2 from Jonathan Wakely --- The standard says those types must have a constexpr constructor, but we can't implement that on all targets: // Common base class for std::mutex and std::timed_mutex class __mutex_base { protected: typedef __gthread_mutex_t __native_type; #ifdef __GTHREAD_MUTEX_INIT __native_type _M_mutex = __GTHREAD_MUTEX_INIT; constexpr __mutex_base() noexcept = default; #else __native_type _M_mutex; __mutex_base() noexcept { // XXX EAGAIN, ENOMEM, EPERM, EBUSY(may), EINVAL(may) __GTHREAD_MUTEX_INIT_FUNCTION(&_M_mutex); } ~__mutex_base() noexcept { __gthread_mutex_destroy(&_M_mutex); } #endif ... class mutex : private __mutex_base { public: typedef __native_type* native_handle_type; #ifdef __GTHREAD_MUTEX_INIT constexpr #endif mutex() noexcept = default; I think we simply need to disable the tests for targets that don't support static initializers such as PTHREAD_MUTEX_INITIALIZER.
[Bug target/79581] VFP4 slower than VFP3 in C-ray
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79581 --- Comment #2 from PeteVine --- Created attachment 40769 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40769&action=edit sphract The other file required to run the benchmark straight from bugzilla! :)
[Bug libstdc++/68739] FAIL: 30_threads/call_once/constexpr.cc (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68739 --- Comment #3 from John David Anglin --- As far as I can tell, the definition for PTHREAD_MUTEX_INITIALIZE only involves constant elements: #define PTHREAD_MUTEX_INITIALIZER {\ __PTHREAD_MUTEX_VALID, 0, \ (PTHREAD_MUTEX_DEFAULT | PTHREAD_PROCESS_PRIVATE), \ __SPNLCK_INITIALIZER, \ 0, 0, -1, 0,\ 0, __LWP_MTX_VALID, 0, 1, 1, 1, 1, \ 0, 0\ } __GTHREAD_MUTEX_INIT is defined. We have the following declaration for struct pthread_mutex: #ifdef __LP64__ #define __MPOINTER void*m_ptr #define __POINTER_SET ((void *) 1LL) #else #define __MPOINTER int m_pad; \ void*m_ptr #define __POINTER_SET 0, ((void *) 1L) #endif struct pthread_mutex { short m_short[2]; int m_int; int m_int1[4]; __MPOINTER; int m_int2[2]; int m_int3[4]; short m_short2[2]; int m_int4[5]; int m_int5[2]; }; We have: #define __PTHREAD_MUTEX_VALID 0x36 #define __LWP_MTX_VALID 2368 #define PTHREAD_MUTEX_DEFAULT 0x80 #define PTHREAD_PROCESS_PRIVATE 0x1 and #define __SPNLCK_INITIALIZER\ 1, 1, 1, 1, \ __POINTER_SET, \ 1, \ 0 I guess the problem is the shorts. But we don't have a literal suffix for it.
[Bug target/79559] [5/6 Regression] ICE in ix86_print_operand, at config/i386/i386.c:18189
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79559 Jakub Jelinek changed: What|Removed |Added Summary|[5/6/7 Regression] ICE in |[5/6 Regression] ICE in |ix86_print_operand, at |ix86_print_operand, at |config/i386/i386.c:18189|config/i386/i386.c:18189 --- Comment #5 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug target/79569] Unrecognized command line option ‘-m3dnowa’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79569 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Jakub Jelinek --- Fixed on the trunk.
[Bug c++/79588] [7 Regression] ICE in warn_for_restrict with -Wrestrict
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79588 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-02-18 CC||jakub at gcc dot gnu.org Target Milestone|--- |7.0 Ever confirmed|0 |1
[Bug c++/79588] [7 Regression] ICE in warn_for_restrict with -Wrestrict
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79588 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Created attachment 40770 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40770&action=edit gcc7-pr79588.patch Untested fix.
[Bug c++/79588] [7 Regression] ICE in warn_for_restrict with -Wrestrict
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79588 --- Comment #2 from prathamesh3492 at gcc dot gnu.org --- Created attachment 40771 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40771&action=edit untested patch Hi Jakub, IIUC, the patch punts if param_pos < args->length(), ie, the default value has been passed. I suppose it won't warn for case when an argument passed by caller would equal default argument ? for eg: int obj; bool foo (int *__restrict q, int *__restrict p = &obj) { return false; } int bar () { return foo(&obj) == 0; } param_pos for p is 1 which equals number of arguments passed and so warn_for_restrict won't get called ? I have attached untested patch that tries to warn for above case by appending default arguments to args vector. Does it look OK ? Thanks, Prathamesh
[Bug c++/79588] [7 Regression] ICE in warn_for_restrict with -Wrestrict
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79588 --- Comment #3 from Jakub Jelinek --- I think the big question is if it isn't simply too early to warn at the place you've added it, shouldn't it be done later on when the call arguments are already complete? E.g. do you warn properly for calls in templates where the arguments might be type or value dependent and it is hard to figure out what exactly they are?
[Bug libstdc++/68739] FAIL: 30_threads/call_once/constexpr.cc (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68739 --- Comment #4 from Jonathan Wakely --- OK, so we get: struct pthread_mutex { short m_short[2]; int m_int; int m_int1[4]; void *m_ptr; int m_int2[2]; int m_int3[4]; short m_short2[2]; int m_int4[5]; int m_int5[2]; }; struct M { pthread_mutex m = { 0x36, 0, (0x80 | 0x1), 1, 1, 1, 1, ((void *) 1LL), 1, 0, 0, 0, -1, 0, 0, 2368, 0, 1, 1, 1, 1, 0, 0 }; }; constexpr M m; Which gives the unhelpful error: pt.cc:17:13: error: ‘constexpr M::M()’ called in a constant expression constexpr M m; ^ pt.cc:13:8: note: ‘constexpr M::M()’ is not usable as a constexpr function because: struct M { ^ (I'll report that as a front-end bug). I think the (void*) 1LL is the problem, you can't do a reinterpret_cast in a constant expression. This gives the same error: struct pthread_mutex { void *m_ptr; }; struct M { pthread_mutex m = { ((void *) 1LL) }; }; constexpr M m;
[Bug libstdc++/68739] FAIL: 30_threads/call_once/constexpr.cc (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68739 --- Comment #5 from Jonathan Wakely --- ((void *)0 + 1) is also technically ill-formed, but G++ accepts it (Bug 60760).
[Bug libstdc++/68739] FAIL: 30_threads/call_once/constexpr.cc (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68739 --- Comment #6 from Jonathan Wakely --- Oh, (void*)1 works, it's only rejected with the LL suffix. That's not conforming either (and Clang rejects it).
[Bug c++/79591] New: [concepts] failure to distinguish overloads from different namespaces with differing constraints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79591 Bug ID: 79591 Summary: [concepts] failure to distinguish overloads from different namespaces with differing constraints Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: Casey at Carter dot net Target Milestone: --- Created attachment 40772 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40772&action=edit Minimal repro GCC 6.3 and trunk both miscompile this program: template concept bool True = true; // Fine. namespace X { void f(auto) {} void f(True) {} } void f(auto) {} namespace Y { void f(True) {} using ::f; // error: 'template void f(auto:3)' conflicts with a previous declaration } The compiler is happy to overload when the two abbreviated function templates are declared in the same scope - as in namespace X - but not when one is imported into the namespace via a using declaration.
[Bug c++/79592] New: incomplete diagnostic "is not usable as a constexpr function because:"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79592 Bug ID: 79592 Summary: incomplete diagnostic "is not usable as a constexpr function because:" Product: gcc Version: 6.3.1 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org Target Milestone: --- struct pthread_mutex { void *m_ptr; }; struct M { pthread_mutex m = { ((void *) 1LL) }; }; constexpr M m; pt.cc:9:13: error: ‘constexpr M::M()’ called in a constant expression constexpr M m; ^ pt.cc:5:8: note: ‘constexpr M::M()’ is not usable as a constexpr function because: struct M { ^ It just says "because:" without saying what the problem is (the cast is not allowed in a constant expression). If the expression is (void*)1 rather than (void*)1LL then it is incorrectly accepted.
[Bug libstdc++/68739] FAIL: 30_threads/call_once/constexpr.cc (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68739 --- Comment #7 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #4) > (I'll report that as a front-end bug). Bug 79592
[Bug c++/59284] missing diagnostic on incomplete type at the point of template definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59284 Jonathan Wakely changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2017-02-18 Ever confirmed|0 |1 Severity|normal |enhancement --- Comment #1 from Jonathan Wakely --- Not a bug, because "no diagnostic is required". A diagnostic is only required if the function template is instantiated, and we do that. G++ has been getting stricter about diagnosing errors with non-dependent names and types in uninstantiated templates, so confirming as an enhancement request.
[Bug rtl-optimization/79593] New: [Regression] Poor/Worse code generation for FPU on versions after 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79593 Bug ID: 79593 Summary: [Regression] Poor/Worse code generation for FPU on versions after 6 Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: katsunori.kumatani at gmail dot com Target Milestone: --- First of all sorry if the "Component" is set wrong, I didn't know what to pick (in respect to worse code generation than former versions) :) Newer GCC versions seem to have regressed in their x87 code generation and do it extremely poor mistakes. This is about a regression in code generation for x87 code, not a "wishlist" of better code (i.e. it's about the possibility of having it reverted back to v5, at least in respect to x87 code gen). Sometimes I want to use it for various reasons, for example for "long double" high intermediate precision. So technically this is a "performance bug" regression: In fact GCC version 5 generates quite good x87 code! So I'd simply want that generation reverted as a goal with this report (if the culprit is found of course), so don't misunderstand my intention please. For example, since GCC 6, when you "convert" from say a "float" to a "long double", it generates spurious instructions like this sequence: fld st(0) fcomip st, st(2) Instead of just: fcomip st, st(1) Which is IMHO killing one of the few nice features of x87 that it has automatic conversions to 80-bit all the time at no extra cost. Bear in mind, GCC 5 is just fine and does the latter which is optimal. My C++ code actually does all calculations in "long double" on purpose, but it has to interface with data found in a "float" on a constant basis (reading it), and also returning some of it as float or double. The problem is, as you can see, newer versions of GCC do pointless "conversions" or something like that (I'm not sure myself why it does those pointless loads) when you load a "float" into a "long double" or something similar to that effect. This is a two-fold problem: not only there's extra instructions, but it also requires one more "space" in the register stack resulting in more pointless spills (of long doubles!). Now to illustrate what I mean so you can verify yourself, I've included a stupid little testcase that doesn't do much of anything, but it seems to exhibit this "poor code" generation, here's the code: #include #undef MIN #undef MAX template T inline MIN(T a, T b) { return a < b ? a : b; } template T inline MAX(T a, T b) { return a > b ? a : b; } struct foo { uint32_t num; union { uint32_t i; float f; }; }; extern float global_data[1024]; float bar(foo* __restrict__ e, uint32_t id) { if(id >= e->num) return 0.0f; long double delta = (global_data[0]), min = (global_data[1]); delta = ((delta < 0.0l) ? (min-((long double)e->i)) : ((e->f)-min)) / delta; return (MIN(MAX(delta, 0.0l), 1.0l)); } I compiled with e.g. -m32 -Ofast -mfpmath=387(to have the return value in st(0) to show this issue better) Here's the outputs for GCC versions 5, 6 and 7, with comments from me showing obvious poor code: GCC 5: sub esp, 12 fldz mov eax, DWORD PTR [esp+16] mov ecx, DWORD PTR [esp+20] cmp DWORD PTR [eax], ecx jbe .L2 fld DWORD PTR global_data fld DWORD PTR global_data+4 fxchst(2) fcomip st, st(1) ja .L12 fxchst(1) fsubr DWORD PTR [eax+4] .L5: fdivrp st(1), st fldz fxchst(1) fcomi st, st(1) fcmovb st, st(1) fstpst(1) fld1 fcomi st, st(1) fcmovnb st, st(1) fstpst(1) .L2: add esp, 12 ret .L12: mov eax, DWORD PTR [eax+4] # here the only issue I have with GCC 5 xor edx, edx mov DWORD PTR [esp+4], edx # I don't understand what's this spill for? mov DWORD PTR [esp], eax # can't it load directly from [eax+4]? fildQWORD PTR [esp]# fild DWORD PTR [eax+4] or am I wrong? fsubp st(2), st fxchst(1) jmp .L5 GCC 6: sub esp, 12 fldz mov eax, DWORD PTR [esp+16] mov ecx, DWORD PTR [esp+20] cmp DWORD PTR [eax], ecx jbe .L1 fld DWORD PTR global_data fld st(0)# this is the poor "conversion" mentioned fld DWORD PTR global_data+4 fxchst(3) fcomip st, st(2)# here's its "pop" (unneeded otherwise) fstpst(1) ja .L12 fxchst(1) fsubr DWORD PTR [eax+4] .L5: fdivrp st(1), st fldz fxchst(1) fcomi st, st(1) fcmovb st, st(1) fstpst(1) fld1 fcomi st, st(1) fcmovnb st, st(1) fstpst(1) .L1: add esp, 12 ret .L12: mov eax, DWORD PTR [eax+4] xor edx, edx mov DWORD PTR [esp+4], edx mov D
[Bug c++/66944] ICE on static thread_local member in class template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66944 Oleg Pronin changed: What|Removed |Added CC||syber at crazypanda dot ru --- Comment #4 from Oleg Pronin --- (In reply to Laurent Rineau from comment #3) > I got hit by this bug today. Do you know a workaround? Yes. Use static thread_local inside static member function. template struct A { virtual void foo() { v(); } static Heavy& v () { static thread_local Heavy obj; return obj; } }; However i discovered that perfomance of getting thread_local variables somewhy depends on the class (Heavy) in this case, it's size and constructor complexity maybe i dunno, however i benchmarked the code above for some my class and got just only 100M/s calls. After that i changed the code above to: template struct A { virtual void foo() { v(); } static Heavy* v () { static thread_local Heavy* ptr; if (!ptr) { static thread_local Heavy inst; ptr = &inst; } return ptr; } }; and got 300M/s calls. The point is that you should not allow code flow to go through static thread_local object declaration itself, only through POD pointer type. I don't know why thread_local is so ineffective however this workaround gave x3 speed for me in GCC 4.9 In clang, there is no thread_local bug, however it's speed is always slow (100M/s) and i could not speedup it with any of workarounds :(