https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93299
--- Comment #4 from Marek Polacek ---
force_paren_expr now creates a VIEW_CONVERT_EXPR:
+ expr = build1 (VIEW_CONVERT_EXPR, TREE_TYPE (expr), expr);
+ REF_PARENTHESIZED_P (expr) = true;
but it's not a case that tsubst_copy can handle:
1
at gcc dot gnu.org |mpolacek at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93299
Marek Polacek changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93299
Marek Polacek changed:
What|Removed |Added
Keywords||patch
--- Comment #5 from Marek Polacek
|UNCONFIRMED |NEW
Last reconfirmed||2020-01-19
CC||mpolacek at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Marek Polacek ---
Started with
|ASSIGNED
Known to work||9.2.0
Keywords||ice-on-valid-code
Last reconfirmed||2020-01-19
CC||mpolacek at gcc dot gnu.org
Assignee
||2020-01-19
CC||mpolacek at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #2 from Marek Polacek ---
Confirmed with a cross:
subrepos/thingi/include/thingi/Interface.h:241:19: internal compiler error: in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93320
--- Comment #3 from Marek Polacek ---
We crash in is_base_type because it gets
(gdb) p type
$1 =
and that is not handled:
12990 gcc_unreachable ();
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93324
Marek Polacek changed:
What|Removed |Added
Keywords||patch
--- Comment #2 from Marek Polacek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93320
--- Comment #5 from Marek Polacek ---
Seems like it started with g:3075affdbcb3232fe549fbeed87bd94114c14758
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93323
Marek Polacek changed:
What|Removed |Added
Keywords|needs-reduction |
--- Comment #2 from Marek Polacek ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93275
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92907
--- Comment #4 from Marek Polacek ---
I think I see the problem -- in cp_parser_noexcept_specification_opt we inject
'this', but always without any qualifiers:
25737 if (current_class_type)
25738 inject_this_parameter (curre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92907
Marek Polacek changed:
What|Removed |Added
Keywords||patch
--- Comment #5 from Marek Polacek
Status|UNCONFIRMED |NEW
Last reconfirmed||2020-01-22
CC||mpolacek at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #2 from Marek Polacek ---
Confirmed, too late for GCC 10.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93324
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92907
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
||2020-01-22
CC||mpolacek at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Marek Polacek ---
Confirmed, ICEs with GCC 7 too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93383
--- Comment #2 from Marek Polacek ---
r7-5532-g35f4cbd4489519983a4f64da846be8352f611879 compiles OK
r7-5533-ga93634ba09c4b33d95233e48d9c452a529555d05 ICE in unify_one_argument
r7-6939-g853ef4e5632df32894b2366096c1ae1ef4ba03df ICE in resolve_args
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93383
--- Comment #3 from Marek Polacek ---
resolve_args gets a vector of arguments, one of which is
(gdb) p arg
$3 =
(gdb) pt
>
readonly constant
decl
readonly constant decl_0 VOID 93383.C:15:10
align:1 warn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79620
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93394
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93399
--- Comment #2 from Marek Polacek ---
The error I see is:
/tmp/ccmVatwF.s: Assembler messages:
/tmp/ccmVatwF.s:90: Error: invalid character (0xa) in mnemonic
/tmp/ccmVatwF.s:92: Error: unassigned file number 2
/tmp/ccmVatwF.s:92: Error: junk at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93279
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
||2020-01-24
CC||mpolacek at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #1 from Marek Polacek ---
Mine. Users
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93279
--- Comment #5 from Marek Polacek ---
Since r9-6405-gbddee796d0b4800b5ac3d7e7e9e315c23799424d, when we see in a
lambda a use of an operator that might be overloaded, we do name lookup and
save it away in an internal attribute on the lambda call o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93279
--- Comment #6 from Marek Polacek ---
This passes dg.exp but I haven't convinced it's the right solution so haven't
posted it...
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -21849,8 +21849,12 @@ type_unification_real (tree tparms,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93299
Marek Polacek changed:
What|Removed |Added
Summary|[9/10 Regression] ICE in|[9 Regression] ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93414
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
|UNCONFIRMED |NEW
Last reconfirmed||2020-01-25
CC||mpolacek at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #2 from Marek Polacek ---
Confirmed.
during GIMPLE pass: sanopt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93436
Marek Polacek changed:
What|Removed |Added
Target Milestone|--- |9.3
Summary|ICE during GIMPLE
at gcc dot gnu.org |mpolacek at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93436
Marek Polacek changed:
What|Removed |Added
Summary|[9/10 Regression] ICE |[9 Regression] ICE during
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92948
--- Comment #2 from Marek Polacek ---
Because of the alias template build_converted_constant_expr produces a
TARGET_EXPR containing a TEMPLATE_PARM_INDEX which makes it value-dependent.
So we don't call get_template_parm_object here
7449
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92948
--- Comment #3 from Marek Polacek ---
Test I've been playing with:
struct A {
constexpr A(int) { }
};
template
struct B {
using U = unsigned;
};
template
using U = B;
//template::U> // ok
template::U> // ICE
//template::U> // error
void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92948
--- Comment #4 from Marek Polacek ---
A related test that I think should compile:
struct A {
constexpr A(int) { }
};
template
struct B {
};
template
void foo()
{
B b; // works with B<1>
}
void
fn ()
{
foo<1>();
}
at gcc dot gnu.org |mpolacek at gcc dot
gnu.org
--- Comment #5 from Marek Polacek ---
I have a patch that fixes these two issues (it uses IMPLICIT_CONV_EXPR).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92948
Marek Polacek changed:
What|Removed |Added
Keywords||ice-on-valid-code, patch,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91754
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91754
Marek Polacek changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #3 from Marek Polacek -
at gcc dot gnu.org |mpolacek at gcc dot
gnu.org
--- Comment #4 from Marek Polacek ---
Testing a patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92171
--- Comment #2 from Marek Polacek ---
The constexpr evaluator doesn't see the "ref." part at all: VALUE is a static
data member, so build_class_member_access_expr produces "value":
(gdb) pt result
unit-size
align:8 warn_if_not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92171
--- Comment #3 from Marek Polacek ---
Not working on this now, needs to wait till GCC 11.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92003
Marek Polacek changed:
What|Removed |Added
Known to work||6.4.0
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92948
--- Comment #8 from Marek Polacek ---
Fixed on trunk so far, will backport to 9 sometime soon.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91803
Marek Polacek changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89565
Marek Polacek changed:
What|Removed |Added
CC||boris.rura at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90335
Marek Polacek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
at gcc dot gnu.org |mpolacek at gcc dot
gnu.org
--- Comment #9 from Marek Polacek ---
(In reply to Hana Dusíková from comment #5)
> So minimal example is:
>
> template
> struct S {
> constexpr S(...) { }
> };
>
> template S(T) -> S;
>
> template struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88092
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
||mpolacek at gcc dot gnu.org
Resolution|--- |INVALID
--- Comment #3 from Marek Polacek ---
Closing.
||mpolacek at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #3 from Marek Polacek ---
The lazily_declare_fn ICE was fixed and I don't see any other ICE, assuming
fixed.
||mpolacek at gcc dot gnu.org
Resolution|--- |DUPLICATE
--- Comment #4 from Marek Polacek ---
Yes, it is a dup, but thanks for the nice testcase!
*** This bug has been marked as a duplicate of bug 87765 ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87765
Marek Polacek changed:
What|Removed |Added
CC||daniel at ekpyron dot org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87765
--- Comment #4 from Marek Polacek ---
A short test by Daniel Kirchner:
struct X { int s(); };
template using Y = void;
template static constexpr void t(X x) { Y v; }
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91212
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
at gcc dot gnu.org |mpolacek at gcc dot
gnu.org
|UNCONFIRMED |NEW
Last reconfirmed||2020-01-29
CC||mpolacek at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Marek Polacek ---
Confirmed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93106
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91212
--- Comment #3 from Marek Polacek ---
Happens with a class too:
struct T { int i; };
struct X {
X(T&) { } // #1
X(const T&) { __builtin_abort (); } // #2
};
X
fn ()
{
T buf;
return buf;
}
int
main()
{
X c = fn ();
}
is it actually
||2020-01-30
CC||mpolacek at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #1 from Marek Polacek ---
IT ICEs in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91465
Marek Polacek changed:
What|Removed |Added
CC||andij.cr at gmail dot com
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93513
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91465
--- Comment #3 from Marek Polacek ---
Another test:
enum class error {};
template
void afunction(F) {
error{char(0)};
}
93513.C: In function ‘void afunction(F)’:
93513.C:4:16: internal compiler error: unexpected expression ‘(char)(0)’ of
kin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91212
--- Comment #4 from Marek Polacek ---
Jason, do you want to change anything here? Though clang/icc/msvc++ seem to
choose #1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92402
--- Comment #3 from Marek Polacek ---
Even shorter:
int a[1];
void f() {
[]() -> decltype(({auto&& [x] = a; 0;})) { return 0; };
}
clang++ compiles it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92402
--- Comment #4 from Marek Polacek ---
Not a regression though, so I'll leave it for GCC 11.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92434
--- Comment #2 from Marek Polacek ---
Extended testcase:
template
void foo_false(void(*)() noexcept(B))
{
static_assert (!B);
}
template
void foo_true(void(*)() noexcept(B))
{
static_assert (B);
}
void f();
void fn() noexcept;
void bar()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92434
--- Comment #3 from Marek Polacek ---
To match clang we could use
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -21470,6 +21470,12 @@ uses_deducible_template_parms (tree type)
for (; parm; parm = TREE_CHAIN (parm))
if (uses_deducible_templa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92434
--- Comment #4 from Marek Polacek ---
That should probably be
+ if (spec && TREE_PURPOSE (spec) && deducible_expression (TREE_PURPOSE
(spec)))
Note that clang fails if noexcept(B) is changed to e.g. noexcept(!B).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92434
Marek Polacek changed:
What|Removed |Added
Summary|noexcept couldn't be|[DR 2355] noexcept couldn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91465
--- Comment #4 from Marek Polacek ---
This is the fix, thought I recall it broke something. But we want to use fold_
here because we can have a non-dependent template code like CAST_EXPR.
--- a/gcc/cp/typeck2.c
+++ b/gcc/cp/typeck2.c
@@ -981,7
||mpolacek at gcc dot gnu.org
--- Comment #5 from Marek Polacek ---
Confirmed with -g.
#350 0x00f32eea in gen_subprogram_die (decl=,
context_die=) at
/home/mpolacek/src/gcc/gcc/dwarf2out.c:22942
#351 0x00f3c548 in force_decl_die (decl=)
at /home/mpolacek/src
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92169
--- Comment #6 from Marek Polacek ---
Started with r0-116587-g0fd0752e83525409addcdb904c67dc535bd5c1d1:
commit 0fd0752e83525409addcdb904c67dc535bd5c1d1
Author: Jason Merrill
Date: Thu May 3 12:19:02 2012 -0400
dwarf2out.c (modified_type_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91465
--- Comment #5 from Marek Polacek ---
(In reply to Marek Polacek from comment #4)
> This is the fix, thought I recall it broke something.
That was constexpr-ex4.C:
constexpr-ex4.C:13:11: error: no matching function for call to ‘A::operator
int
||2020-01-31
CC||mpolacek at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #2 from Marek Polacek ---
tar: This does not look like a tar archive
unzip x.zip also doesn't work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93527
Marek Polacek changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #4 from Marek Polacek -
||2020-01-31
CC||mpolacek at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Marek Polacek ---
Confirmed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93530
--- Comment #2 from Marek Polacek ---
r10-4969-g1723e1bedb9545c45619c4023729755243524584
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93530
Marek Polacek changed:
What|Removed |Added
Target Milestone|--- |10.0
--- Comment #3 from Marek Polacek
at gcc dot gnu.org |mpolacek at gcc dot
gnu.org
--- Comment #4 from Marek Polacek ---
Or, in fact, grokdeclarator should use cplus_decl_attributes instead of
decl_attributes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93530
--- Comment #5 from Marek Polacek ---
> b) that alignas is incorrectly placed
Bug 90847
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93530
Marek Polacek changed:
What|Removed |Added
Keywords||patch
--- Comment #7 from Marek Polacek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93530
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
||2020-02-03
CC||mpolacek at gcc dot gnu.org
Target Milestone|--- |10.0
Ever confirmed|0 |1
--- Comment #1 from Marek Polacek ---
Confirmed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93549
--- Comment #2 from Marek Polacek ---
Started with r10-3661-g8e007055dd1374ca4c44406a4ead172be0dfa3a8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93549
--- Comment #3 from Marek Polacek ---
Looking into why the above commit caused this.
,
||needs-bisection
Status|UNCONFIRMED |NEW
Last reconfirmed||2020-02-03
CC||mpolacek at gcc dot gnu.org
Target Milestone|--- |10.0
Ever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93559
Marek Polacek changed:
What|Removed |Added
Keywords|needs-bisection |
--- Comment #3 from Marek Polacek ---
at gcc dot gnu.org |mpolacek at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93559
--- Comment #4 from Marek Polacek ---
struct E { int d[10]; };
struct S {
constexpr int operator()(char) { return 42; }
};
template struct X {
constexpr static E foo(S s) { return {{s(1)}}; }
};
S s;
static_assert((X::foo(s), 1), "");
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: mpolacek at gcc dot gnu.org
Target Milestone: ---
Reduced from libXt:
struct E {
} e;
struct A {
unsigned long *l;
};
struct C {
unsigned long *l;
} c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93582
Marek Polacek changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
Target Miles
at gcc dot gnu.org |mpolacek at gcc dot
gnu.org
--- Comment #2 from Marek Polacek ---
Mine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93582
--- Comment #3 from Marek Polacek ---
This is about us not accepting the code anymore, I think it's what libXt relies
on. Quoting Adam J.:
"Where GRABEXT here is just doing the standard C trick for incrementing
past the current struct and retur
||mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93559
Marek Polacek changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93549
Marek Polacek changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92003
Marek Polacek changed:
What|Removed |Added
Priority|P3 |P2
||mpolacek at gcc dot gnu.org
901 - 1000 of 9289 matches
Mail list logo