https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84684
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84684
--- Comment #18 from Marek Polacek ---
Author: mpolacek
Date: Wed Mar 7 07:50:57 2018
New Revision: 258313
URL: https://gcc.gnu.org/viewcvs?rev=258313&root=gcc&view=rev
Log:
PR c++/84684
* constexpr.c (cxx_bind_parameters_in_cal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84684
--- Comment #17 from Marek Polacek ---
Author: mpolacek
Date: Tue Mar 6 21:11:46 2018
New Revision: 258303
URL: https://gcc.gnu.org/viewcvs?rev=258303&root=gcc&view=rev
Log:
PR c++/84684
* constexpr.c (cxx_bind_parameters_in_cal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84684
--- Comment #16 from Jakub Jelinek ---
Author: jakub
Date: Mon Mar 5 22:12:45 2018
New Revision: 258262
URL: https://gcc.gnu.org/viewcvs?rev=258262&root=gcc&view=rev
Log:
PR c++/84684
* constexpr.c (constexpr_call_hasher::equal)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84684
--- Comment #15 from Marek Polacek ---
I think this is the fix:
--- a/gcc/cp/typeck2.c
+++ b/gcc/cp/typeck2.c
@@ -1251,8 +1251,7 @@ massage_init_elt (tree type, tree init, int nested,
tsubst_flags_t complain)
init = TARGET_EXPR_INITIAL (ini
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84684
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84684
--- Comment #13 from Jakub Jelinek ---
If the in-place modification of the CONSTRUCTOR in these cases are intentional,
the fix could be:
if (entry == NULL)
{
/* We need to keep a pointer to the entry, not just the slot,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84684
Jakub Jelinek changed:
What|Removed |Added
Keywords||wrong-code
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84684
--- Comment #11 from Marek Polacek ---
Seems like another of the wrong caching issues. I can't reproduce it on my
laptop though; can you figure out where the first call, the one which ends up
cached in the constexpr_call_table originates?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84684
--- Comment #10 from Jakub Jelinek ---
In the debugger when looking at cxx_eval_call_expression
union_composition<0, dna4>::value_to_char_helper<4, dna4> (TARGET_EXPR
);
I see:
(gdb) p debug_generic_stmt (result)
{._M_elems={65, 67, 67, 84}}
whic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84684
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84684
--- Comment #8 from Jakub Jelinek ---
Created attachment 43562
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43562&action=edit
pr84684-7.ii
Even with this simplified version I still get:
pr84684-6.C: In instantiation of ‘static constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84684
--- Comment #7 from Jakub Jelinek ---
#include
#include
template
constexpr char to_char(alphabet_type const alph)
{
return alph.to_char();
}
constexpr const char *check[][3] = {
{ "ACGT", __null, __null },
{ "ACGT", "-", __null },
{ "ACG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84684
--- Comment #6 from gcc-bugs at marehr dot dialup.fu-berlin.de ---
I use now a more simpler approach for the fold expression [1], but the problem
from this bug ticket still persisted when I used the same kind of assignment:
for (size_t i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84684
--- Comment #5 from Jakub Jelinek ---
Or also defining another method in union_composition, like:
static constexpr auto make_value_to_char1()
{
constexpr auto N = sizeof...(alphabet_types);
return N;
}
makes it go aw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84684
--- Comment #4 from Jonathan Wakely ---
(In reply to Jakub Jelinek from comment #3)
> the errors go away. Or if I remove int main () { and }, i.e. keep the
> static_asserts at the toplevel, it fails, but in different spots than when
> it is in m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84684
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84684
--- Comment #2 from Richard Biener ---
(In reply to Jonathan Wakely from comment #1)
> Confirmed, valgrind shows a lot of errors like this:
Use --enable-valgrind-annotations, the sparseset errors are spurious.
> ==13397== Conditional jump or mo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84684
Jonathan Wakely changed:
What|Removed |Added
Keywords||rejects-valid
Status|UNCON
19 matches
Mail list logo
