https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108563
--- Comment #5 from Luke Dalessandro ---
Just checked again, this seems to be resolved in the 13 and 14 lines, as well
as trunk. Still fails in 12.4.0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115181
Bug ID: 115181
Summary: [ICE] internal compiler error in
invalid_tparm_referent_p, at cp/pt.cc:7274
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93008
--- Comment #15 from Luke Dalessandro ---
(In reply to Jonathan Wakely from comment #5)
>
> IMO the ideal solution is for GCC to stop using whether a function is inline
> as an optimisation hint. Then we wouldn't need some extra GCC-specific wa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114142
Bug ID: 114142
Summary: [coroutines]: internal compiler error: tree check:
expected record_type or union_type or qual_union_type,
have reference_type in lookup_base, at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113844
Bug ID: 113844
Summary: inline namespace lookup ambiguity for using
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110256
Bug ID: 110256
Summary: passing concept to concept compiles
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109751
--- Comment #16 from Luke Dalessandro ---
(In reply to Luke Dalessandro from comment #15)
> Thanks for looking at this.
> [...]
>
> Also, from what I understand, I should report Andrew's reduced case as a bug
> in clang, and msvc (and maybe nvc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109751
--- Comment #15 from Luke Dalessandro ---
Thanks for looking at this. I'd like to report it back to boost as an issue,
but I want to make sure I understand what to tell them.
1. The error produce by Andrew's reduction ("error: satisfaction of a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109751
--- Comment #8 from Luke Dalessandro ---
(In reply to Andrew Pinski from comment #7)
> I think the error message is correct.
>
> In the original code we have:
> ```
> ...
> template
> concept incrementable = regular<_Iter> && requires(_It
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109751
--- Comment #5 from Luke Dalessandro ---
Ah, I didn't realize that. If you want to close one of the two issues that's
fine with me. I sort of thought two different things were going on.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109752
--- Comment #4 from Luke Dalessandro ---
(In reply to Andrew Pinski from comment #2)
> (In reply to Luke Dalessandro from comment #0)
> >
> > PR: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108451 fails the same
> > assert but I don't know if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109751
--- Comment #3 from Luke Dalessandro ---
One thing to note about this failure, the concept evaluation changes in gcc-13.
The when I try with current trunk it actually ICEs in addition.
I reported that ICE as https://gcc.gnu.org/bugzilla/show_bu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109752
--- Comment #3 from Luke Dalessandro ---
Created attachment 55010
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55010&action=edit
Preprocessed source copied from the godbolt live link.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109751
--- Comment #2 from Luke Dalessandro ---
Created attachment 55009
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55009&action=edit
Preprocessed source copied from the godbolt live link included in the original
text.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109752
Bug ID: 109752
Summary: [ICE] in check_complete_insertion, at hash-table.h:578
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109751
Bug ID: 109751
Summary: boost interface_interface fails concept check starting
in gcc-13
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109136
Bug ID: 109136
Summary: [concepts] initializer_list constructor constraint
should require static_cast for explicit conversion
operator
Product: gcc
Version: 13.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108736
Bug ID: 108736
Summary: pconcepts] multidimensional subscript operator reports
invalid error in requires test
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108669
--- Comment #3 from Luke Dalessandro ---
(In reply to Jonathan Wakely from comment #2)
> (In reply to Luke Dalessandro from comment #0)
> > This should run afoul of the second half of
> > https://eel.is/c++draft/vector#overview-4. "T shall be co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108669
Bug ID: 108669
Summary: [diagnostic] std::vector of incomplete type has member
referenced
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108563
Bug ID: 108563
Summary: [concepts] ICE (segfault) when requiring
sizeof(variable_tempalate_v)
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106086
Bug ID: 106086
Summary: ICE: trying to capture 'this' in instantiation of
generic lambda
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106084
Bug ID: 106084
Summary: using constructor fails to inherit consteval
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106040
Bug ID: 106040
Summary: gcc reports error in aggregate when member has
explicit constructor
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106026
--- Comment #1 from Luke Dalessandro ---
Actually, I take back the part about it being invalid code, I'm not sure it's
invalid. The godbolt link compiles on clang-14 without error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106026
Bug ID: 106026
Summary: ICE: error reporting routines re-entered.
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105912
--- Comment #1 from Luke Dalessandro ---
Somewhat reduced testcase:
template struct A {};
template struct B {};
template
static consteval auto operator~(A) -> B {
return {};
}
A<'i'> i;
template
au
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105912
Bug ID: 105912
Summary: internal compiler error: in extract_call_expr, at
cp/call.cc:7114
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104177
--- Comment #14 from Luke Dalessandro ---
Thanks for the information Iain.
Is there something short-term where gcc could provide an "unimplemented"
failure or warning diagnostic for requests for coroutine frames with extended
alignment?
This
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104177
--- Comment #4 from Luke Dalessandro ---
Oh, that would be great. I tried relatively hard to find a bug like that, but I
have previously shown a surprising level of incompetence with bugzilla search.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104177
--- Comment #1 from Luke Dalessandro ---
Also described in
https://stackoverflow.com/questions/66546906/is-it-defined-behavior-to-place-exotically-aligned-objects-in-the-coroutine-stat.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104177
Bug ID: 104177
Summary: [diagnostic] basic.align#9 should emit diagnostic for
unsupported alignas
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100557
--- Comment #2 from Luke Dalessandro ---
Still failing in trunk, here's a CE link to the preprocessed source
https://godbolt.org/z/YPfTGnT5f.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93320
Luke Dalessandro changed:
What|Removed |Added
CC||ldalessandro at gmail dot com
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97911
Luke Dalessandro changed:
What|Removed |Added
CC||ldalessandro at gmail dot com
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102418
Bug ID: 102418
Summary: [concepts] prefer iterator to range concept failures
in ranges (QoI)
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102286
--- Comment #2 from Luke Dalessandro ---
Okay, one last simplification for posterity.
constexpr void bar() {
union {
int data[1];
} u;
std::construct_at(u.data, 0);
}
https://godbolt.org/z/r4M3voh6W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102286
--- Comment #1 from Luke Dalessandro ---
Oops, slightly reduced testcase, don't think the struct is necessary (just part
of my RL code).
union U {
int data[1];
constexpr U() {} // no active member
};
constexpr bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102286
Bug ID: 102286
Summary: [constexpr] construct_at incorrectly starts union
array lifetime in some cases
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101155
Bug ID: 101155
Summary: comparing non-capturing lambdas is not constexpr
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82632
Luke Dalessandro changed:
What|Removed |Added
CC||ldalessandro at gmail dot com
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101051
Bug ID: 101051
Summary: [ICE] in splice_late_return_type, at cp/pt.c:29738
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100557
--- Comment #1 from Luke Dalessandro ---
Created attachment 50796
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50796&action=edit
Preprocessed source (bzipped for size)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100557
Bug ID: 100557
Summary: [ICE] Internal compiler error: Error reporting
routines re-entered.
Product: gcc
Version: 11.1.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100553
Bug ID: 100553
Summary: [constexpr] new/delete matching fails when ref-counted
pointers are stored in arrays
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Sev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100495
--- Comment #2 from Luke Dalessandro ---
It's also possible to workaround this with array allocation.
```
struct Foo {
constexpr virtual ~Foo() {}
};
constexpr bool foo() {
Foo *ptr = new Foo[1]{};
delete [] ptr;
return true;
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100495
--- Comment #1 from Luke Dalessandro ---
A short-term workaround for this appears to be explicit allocator usage (works
back at least to 10.2).
```
#include
struct Foo {
constexpr virtual ~Foo() {}
};
constexpr bool foo() {
std::allo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100495
Bug ID: 100495
Summary: constexpr virtual destructor incorrectly reports
memory leak
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93413
Luke Dalessandro changed:
What|Removed |Added
CC||ldalessandro at gmail dot com
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99963
--- Comment #3 from Luke Dalessandro ---
I understand. Thank you (I've forwarded this on to clang, which _does_ accept
the ambiguous form).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100055
Bug ID: 100055
Summary: ICE on invalid requires expression
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99963
Bug ID: 99963
Summary: [concepts] template vs concept auto reports
ambiguous overload
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99885
Bug ID: 99885
Summary: CTAD fails for auto const& NTTP
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99859
--- Comment #1 from Luke Dalessandro ---
It was pointed out that it _also_ works if I change
> static_assert(foo());
to
> constexpr bool b = foo();
> static_assert(b);
static_assert(foo());
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99859
Bug ID: 99859
Summary: constexpr evaluation with member function is incorrect
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99059
--- Comment #2 from Luke Dalessandro ---
Ran into this in a static constexpr initializer, not really a workaround for it
that I can find.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97790
--- Comment #1 from Luke Dalessandro ---
It is possible to workaround this bug by creating a symbol for the offending
allocation in the IILE.
https://godbolt.org/z/jeoEra
```
struct vector {
int *data;
int n;
constexpr vector() :
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97790
Bug ID: 97790
Summary: constexpr evaluation reports false positive memory
leak
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priorit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96115
Luke Dalessandro changed:
What|Removed |Added
CC||ldalessandro at gmail dot com
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97681
--- Comment #5 from Luke Dalessandro ---
The more I think about this the more it bothers me.
I recognize that it might be very difficult to implement in gcc's
infrastructure, but I think the design decision that "if it _can_ be constant
evaluat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97681
--- Comment #4 from Luke Dalessandro ---
There are other occurrences of `a` that _are_ in `constexpr` context, it is
used in both contexts within the application thus the keyword is necessary.
This report came from a testcase reduction, so I'll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97681
--- Comment #2 from Luke Dalessandro ---
Okay, how would one constrain such inlining in order to retain a symbol and
stack frame for debugging purposes?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97681
Bug ID: 97681
Summary: noinline attribute ignored on constexpr function
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97665
--- Comment #7 from Luke Dalessandro ---
Thank you, sorry for the confusion.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97665
--- Comment #5 from Luke Dalessandro ---
Ugh... replying to myself.
> You can do Foo foo = Foo(); and it compiles.
>> 1. I can't do `Foo foo = Foo();` because the purpose of the union is to
>> allocate uninitialized storage for the `Foo` durin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97665
--- Comment #4 from Luke Dalessandro ---
Hi Jakob,
Thank you for looking at this. I restructured the code sample according to your
suggestions and it is available here https://godbolt.org/z/P1bMEz. I don't
understand a couple of things that you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97665
--- Comment #1 from Luke Dalessandro ---
(In reply to Luke Dalessandro from comment #0)
> GCC currently rejects the following code snippet, where it infers the
> constexpr definition of V as non-constexpr.
The definition of `v`, not the type `V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97665
Bug ID: 97665
Summary: constexpr union array member incorrectly rejected as
non-constexpr
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97664
Bug ID: 97664
Summary: constexpr evaluation incorrectly accepts non-constant
destruction
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97427
Bug ID: 97427
Summary: constexpr destructor for const object incorrectly
rejected as modifying const object
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Sever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85576
--- Comment #1 from Luke Dalessandro ---
Just ran into this today while testing 11. https://godbolt.org/z/37G7P5
Any possibility we'll see a fix soon?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97328
Bug ID: 97328
Summary: [ICE] internal compiler error: in verify_ctor_sanity,
at cp/constexpr.c:3995
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: nor
72 matches
Mail list logo
