https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94775
--- Comment #7 from Marek Polacek ---
So a fix could be this, but maybe it would make us create a lot more variants
(?):
--- a/gcc/tree.c
+++ b/gcc/tree.c
@@ -6493,7 +6493,8 @@ check_base_type (const_tree cand, const_tree base)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94775
Marek Polacek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94775
Marek Polacek changed:
What|Removed |Added
Summary|[8/9/10 Regression] ICE in |[8/9 Regression] ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94885
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94885
Marek Polacek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94885
--- Comment #3 from Marek Polacek ---
process_init_constructor_record:
1743 if (DECL_SIZE (field) && integer_zerop (DECL_SIZE (field))
1744 && !TREE_SIDE_EFFECTS (next))
1745 /* Don't add trivial initialization of an empty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94890
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94890
--- Comment #6 from Marek Polacek ---
Thanks Ville. What I should have said...
(In reply to Marek Polacek from comment #4)
> My current theory is that it is not a bug.
...in the compiler proper. It'd be nice if the original test compiled.
|UNCONFIRMED |NEW
CC||mpolacek at gcc dot gnu.org
Ever confirmed|0 |1
|1
Last reconfirmed||2020-05-01
CC||mpolacek at gcc dot gnu.org
--- Comment #1 from Marek Polacek ---
We ICE here
9926 /* Remember that this function did return a value. */
9927
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94885
Marek Polacek changed:
What|Removed |Added
Summary|[10/11 Regression] |[10 Regression] Functional
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mpolacek at gcc dot gnu.org
Target Milestone: ---
template struct S { S(); S(bool); };
struct C {
bool operator()(S);
};
S fn (bool);
template void
foo (T)
{
S s;
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94938
Marek Polacek changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
Summ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94896
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94775
Marek Polacek changed:
What|Removed |Added
Summary|[8/9 Regression] ICE in |[8/9/10/11 Regression] ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94896
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94929
Marek Polacek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot
gnu.org
||mpolacek at gcc dot gnu.org
Status|UNCONFIRMED |NEW
Keywords||rejects-valid
Ever confirmed|0 |1
--- Comment #2 from Marek Polacek ---
Confirmed. Not a regression AFAICT.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94938
--- Comment #2 from Marek Polacek ---
value_dependent_expression_p (called via the new uses_template_parms call)
doesn't expect a non-constant expression. So one possible fix would be:
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -10624,7 +10624,8 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94929
Marek Polacek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94929
--- Comment #6 from Marek Polacek ---
(In reply to David Seifert from comment #5)
> (In reply to Marek Polacek from comment #3)
> > I'm going to backport the fix to 8 if it passes the usual testing.
>
> Hi Marek,
> could you also test the inline
at gcc dot gnu.org |mpolacek at gcc dot
gnu.org
--- Comment #10 from Marek Polacek ---
Mine. A reduced test would be very much appreciated, thanks Martin.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94938
Marek Polacek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94799
Marek Polacek changed:
What|Removed |Added
Summary|[8/9/10/11 Regression] |[8/9/10 Regression] Calling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94955
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94955
Marek Polacek changed:
What|Removed |Added
Last reconfirmed||2020-05-05
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94955
Marek Polacek changed:
What|Removed |Added
Target Milestone|--- |10.2
Summary|[10 regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94937
--- Comment #15 from Marek Polacek ---
Reduced:
struct B {
static constexpr bool foo() { return false; }
};
template
struct C {
static void bar ()
{
if constexpr (B::foo()) ;
}
};
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94937
--- Comment #17 from Marek Polacek ---
Ah, omp_declare_variant_finalize_one. I think I'll do something similar, but
not the same: if we see a CALL_EXPR whose CALL_EXPR_FN is a BASELINK, we know
it's not the std::is_constant_evaluated call we're
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94937
--- Comment #18 from Marek Polacek ---
Actually it might be better to make it out to a function and use that in both
places, otherwise I'm either duplicating code or it's just too ugly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94946
Marek Polacek changed:
What|Removed |Added
Summary|[10/11 Regression] error: |[9/10/11 Regression] error:
at gcc dot gnu.org |mpolacek at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94938
Marek Polacek changed:
What|Removed |Added
Summary|[10/11 Regression] internal |[10 Regression] internal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94957
Marek Polacek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot
gnu.org
||mpolacek at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94255
Marek Polacek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94590
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94938
Marek Polacek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94765
Marek Polacek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90915
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94885
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47765
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mpolacek at gcc dot gnu.org
Target Milestone: ---
We give two errors here:
void
f ()
{
int i;
extern void g(int x = i); // error
extern void h(int x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94404
Marek Polacek changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
|unassigned at gcc dot gnu.org |mpolacek at gcc dot
gnu.org
Ever confirmed|0 |1
Status|UNCONFIRMED |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94955
Marek Polacek changed:
What|Removed |Added
CC||john at mcfarlane dot name
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95022
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
||mpolacek at gcc dot gnu.org
Ever confirmed|0 |1
Target Milestone|--- |9.4
Last reconfirmed||2020-05-11
Summary|ICE with variadic type/nttp |[9/10/11 Regression] ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95036
Marek Polacek changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95036
Marek Polacek changed:
What|Removed |Added
Priority|P3 |P2
|--- |INVALID
CC||mpolacek at gcc dot gnu.org
--- Comment #4 from Marek Polacek ---
Not a bug then.
|UNCONFIRMED |NEW
CC||mpolacek at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #2 from Marek Polacek ---
Confirmed, started with r11-15-gbcbf334afe091ad7d0f5ffe164299f8730cf41d1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95066
Marek Polacek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94775
--- Comment #16 from Marek Polacek ---
It caused testsuite failures on non-x86-64 platforms, see bug 94896.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95066
--- Comment #3 from Marek Polacek ---
Reduced:
template
struct Foo {
template
explicit(static_cast(true)) operator Foo();
};
template
template
Foo::operator Foo() {
return {};
}
int
main ()
{
Foo a;
Foo b = a;
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95066
Marek Polacek changed:
What|Removed |Added
Keywords||patch
--- Comment #4 from Marek Polacek
ty: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mpolacek at gcc dot gnu.org
Target Milestone: ---
namespace N {
struct X { };
void f(X);
}
void
g ()
{
extern void f(); // #1
N::X x;
f(x); // calls locally declare
++
Assignee: unassigned at gcc dot gnu.org
Reporter: mpolacek at gcc dot gnu.org
Target Milestone: ---
namespace N {
struct S { };
void f(S);
}
namespace M {
void f(int);
}
int
main ()
{
N::S s;
extern void f(char); // #1
using M::f; // #2
f(s);
}
compiles fine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95074
Marek Polacek changed:
What|Removed |Added
Keywords||accepts-invalid
--- Comment #1 from Mare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95074
--- Comment #2 from Marek Polacek ---
This is where we're confused by the function introduced by M::f:
/* We do not perform argument-dependent lookup if
normal lookup finds a non-function, in accordance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95074
Marek Polacek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot
gnu.org
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mpolacek at gcc dot gnu.org
Target Milestone: ---
In C++11
enum E { };
void f(bool b)
{
E e = b ? *new enum E : E{};
}
should now compile: the colon is not an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95074
Marek Polacek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
|1
Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot
gnu.org
Last reconfirmed||2020-05-13
--- Comment #3 from Marek Polacek ---
A patch for DR 2289 posted:
https://gcc.gnu.org/pipermail/gcc-patches/2020-May/545692.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90320
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95116
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94799
--- Comment #10 from Marek Polacek ---
I see :(. I'll take a look, thanks for noticing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95164
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
||mpolacek at gcc dot gnu.org
Resolution|--- |DUPLICATE
--- Comment #1 from Marek Polacek ---
CWG 727.
*** This bug has been marked as a duplicate of bug 85282 ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85282
Marek Polacek changed:
What|Removed |Added
CC||mikelojkovic at gmail dot com
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95164
--- Comment #2 from Marek Polacek ---
It actually started with r5-7-g1c982d13138ee4518db10b6fbe02fa32d09ab51e -- it
was latent for a while.
||mpolacek at gcc dot gnu.org
Keywords||rejects-valid
Status|UNCONFIRMED |NEW
Last reconfirmed||2020-05-17
--- Comment #1 from Marek Polacek ---
Confirmed. The problem is that grokfield
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95164
--- Comment #3 from Marek Polacek ---
struct H {
int a;
};
struct I {
int c;
H b;
};
struct E { I d; };
void foo(E);
template
void fn ()
{
int a = 42;
int &k = a;
foo({1, {H{k}}});
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95192
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
||jason at gcc dot gnu.org,
||mpolacek at gcc dot gnu.org
Target Milestone|--- |11.0
Last reconfirmed||2020-05-18
Ever confirmed|0 |1
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87699
Marek Polacek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
|has_attribute, at |has_attribute, at
|c-family/c-attribs.c:4221 |c-family/c-attribs.c:4221
Assignee|paolo.carlini at oracle dot com|mpolacek at gcc dot
gnu.org
--- Comment #7 from Marek Polacek ---
Fixed on trunk. I'll also backport to 10.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94937
Marek Polacek changed:
What|Removed |Added
Summary|[10/11 Regression] ICE with |[10 Regression] ICE with if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94955
Marek Polacek changed:
What|Removed |Added
Summary|[10/11 Regression] ICE in |[10 Regression] ICE in
|P2
Ever confirmed|0 |1
CC||mpolacek at gcc dot gnu.org
Status|UNCONFIRMED |NEW
Summary|constexpr and alias |[9/10/11 Regression
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mpolacek at gcc dot gnu.org
Target Milestone: ---
See <https://gcc.gnu.org/pipermail/gcc-patches/2020-May/545879.html> for why
this fails. My workaround was
--- a/libgomp/tes
||mpolacek at gcc dot gnu.org
Resolution|--- |INVALID
--- Comment #1 from Marek Polacek ---
.
|--- |DUPLICATE
CC||mpolacek at gcc dot gnu.org
--- Comment #1 from Marek Polacek ---
Dup, fixed on trunk already. Will be fixed in GCC 10.2 too.
*** This bug has been marked as a duplicate of bug 94955 ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94955
Marek Polacek changed:
What|Removed |Added
CC||danny.schneider at posteo dot
de
--- Co
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mpolacek at gcc dot gnu.org
Target Milestone: ---
It's this code:
struct MyClass
{
virtual ~MyClass () {}
virtual void Doit () {}
};
int
main ()
{
MyClass *c = new MyClass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95221
--- Comment #1 from Marek Polacek ---
It is caused by this code:
853 if (flag_strong_eval_order == 2
854 && CALL_EXPR_FN (*expr_p)
855 && cp_get_callee_fndecl_nofold (*expr_p) == NULL_TREE)
856 {
857
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95221
--- Comment #2 from Marek Polacek ---
I think the thing is that we have a CALL_EXPR, something like
OBJ_TYPE_REF (...) (.UBSAN_VPTR ())
and now we first evaluate the OBJ_TYPE_REF. In this case this is what seems to
happen here:
1) we evalua
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95221
--- Comment #3 from Marek Polacek ---
And for completeness, the asm for the -fstrong-eval-order=all case:
movq%rbx, %rdi
call*%r12
movq-24(%rbp), %rax
movq(%rax), %rax
addq$16, %rax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95221
--- Comment #5 from Marek Polacek ---
You're not wrong, but here we're dealing with the undefined behavior sanitizer
whose point is to detect broken code like the above.
|range_expr in to_wide, at
|tree.h:5900 |tree.h:5900
Status|UNCONFIRMED |NEW
Last reconfirmed||2020-05-20
CC||mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94553
--- Comment #5 from Marek Polacek ---
The structured binding part is now fixed, but the variable template part isn't
yet, so not closing.
|--- |DUPLICATE
CC||mpolacek at gcc dot gnu.org
--- Comment #3 from Marek Polacek ---
Dup.
*** This bug has been marked as a duplicate of bug 68395 ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68395
--- Comment #3 from Marek Polacek ---
*** Bug 68394 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
Bug 67491 depends on bug 68394, which changed state.
Bug 68394 Summary: [concepts] segfault in valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68394
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68395
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
Bug 67491 depends on bug 68628, which changed state.
Bug 68628 Summary: [concepts] ICE: segmentation fault in crash_signal,
toplev.c:334
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68628
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68628
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95291
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95301
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95307
--- Comment #4 from Marek Polacek ---
And related to bug 93955.
201 - 300 of 10213 matches
Mail list logo
