[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 :(
