Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldalessandro at gmail dot com
Target Milestone: ---
UBSan + OpenMP ICE
C-Vise reduced test case, compile with -fsanitize=undefined -fopenmp.
void copy_n(int, long, int);
unsigned
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldalessandro at gmail dot com
Target Milestone: ---
Invalid code uses tag without a second parameter.
template
struct tag {};
template
bool foo(tag);
tag x;
auto y = foo(x);
Works for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100553
--- Comment #2 from Luke Dalessandro ---
This still fails in 14.2 but looks like it's been resolved in trunk (15?).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
--- Comment #48 from Luke Dalessandro ---
(In reply to LIU Hao from comment #47)
> (In reply to Luke Dalessandro from comment #46)
> > But if 104688 isn't related to this issue, and thus Jakub's comment was in
> > error, I definitely don't under
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
--- Comment #46 from Luke Dalessandro ---
(In reply to Xi Ruoyao from comment #45)
> (In reply to Luke Dalessandro from comment #44)
> > Now that https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688 was resolved is
> > it possible to actually get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
Luke Dalessandro changed:
What|Removed |Added
CC||ldalessandro at gmail dot com
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldalessandro at gmail dot com
Target Milestone: ---
The following gives a uninfor
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.
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldalessandro at gmail dot com
Target Milestone: ---
Attempting to use an array literal as an NTTP.
```
template struct foo{};
foo<(int[]){1}> x;
```
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
cp/search.cc:252
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldalessandro at gmail dot com
Target Milestone
++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldalessandro at gmail dot com
Target Milestone: ---
namespace a {
inline namespace b {
inline int b{};
}
}
using namespace a::b; // gcc & msvc & edg reject, clang accepts
I think that
++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldalessandro at gmail dot com
Target Milestone: ---
I accidentally passed a concept to convertible_to and was surprised to see it
compile.
```
#include
template
concept b = requires (T t ) {
{ auto(t) } -> std::convertible
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.
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldalessandro at gmail dot com
Target Milestone: ---
The following example is reduced from
https://github.com/boostorg/stl_interfaces/blob/boost-1.82.0/example/node_iterator.cpp.
It causes the ICE on trunk (gcc-14
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldalessandro at gmail dot com
Target Milestone: ---
The following example is reduced from
https://github.com/boostorg/stl_interfaces/blob/boost-1.82.0/example/node_iterator.cpp
: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldalessandro at gmail dot com
Target Milestone: ---
The following concept should fail the static_assert, but passes (I
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldalessandro at gmail dot com
Target Milestone: ---
The following code produces an error when evaluating the concept.
auto foo(auto a, auto... i) -> declt
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
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldalessandro at gmail dot com
Target Milestone: ---
In the following code example, I perform a value initialization of a
std::vector of incomplete type.
-
#include
struct B
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldalessandro at gmail dot com
Target Milestone: ---
The following valid code causes an ICE (segfault)
template
struct foo {
static constexpr int value = 0
ty: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldalessandro at gmail dot com
Target Milestone: ---
Following code generates ICE
#include
#include
#include
template
struct foo {
cons
++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldalessandro at gmail dot com
Target Milestone: ---
The following code sample fails to compile with gcc.
struct base {
consteval base() {}
};
struct child : base {
using base::base
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldalessandro at gmail dot com
Target Milestone: ---
gcc fails to compile the following example, as it seems to be treating .i{0} as
an implicit operation rather than an explicit
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.
++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldalessandro at gmail dot com
Target Milestone: ---
Created attachment 53163
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53163&action=edit
Eric's tag_invoke implementation.
Triggered with complicate
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
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldalessandro at gmail dot com
Target Milestone: ---
Created attachment 53113
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53113&action=edit
output from -freport-bug
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.
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldalessandro at gmail dot com
Target Milestone: ---
Created attachment 52264
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52264&action=edit
Downloaded CE examp
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97911
Luke Dalessandro changed:
What|Removed |Added
CC||ldalessandro at gmail dot com
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldalessandro at gmail dot com
Target Milestone: ---
When interacting with the ranges library I am occasionally presented with
hundreds of lines of circuitous concept failures driven
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
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldalessandro at gmail dot com
Target Milestone: ---
Given the following struct and union,
struct Foo {
constexpr explicit Foo(int) {}
};
union U
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldalessandro at gmail dot com
Target Milestone: ---
I think the following function pointer comparison should be constexpr.
```
auto a = []{};
auto b = []{};
static_assert(a != b); // error: '(::_FUN != ::_FUN)'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82632
Luke Dalessandro changed:
What|Removed |Added
CC||ldalessandro at gmail dot com
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldalessandro at gmail dot com
Target Milestone: ---
Following invalid code triggers ICE in 10, 11, and trunk.
```
template
class Foo
{
constexpr operator T() -> T {}
};
```
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)
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldalessandro at gmail dot com
Target Milestone: ---
Not sure if this duplicates https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90747.
/home/ldalessa/open/ttl20/include/ttl/cpos.hpp
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldalessandro at gmail dot com
Target Milestone: ---
Sorry about the complexity of this test case. Consider the following code.
```
#include
struct Node {
int
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
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldalessandro at gmail dot com
Target Milestone: ---
When using a constexpr virtual destructor gcc fails to match delete with
corresponding new.
```
struct Foo {
constexpr virtual ~Foo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93413
Luke Dalessandro changed:
What|Removed |Added
CC||ldalessandro at gmail dot 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).
++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldalessandro at gmail dot com
Target Milestone: ---
The following invalid code triggers a segfault.
```
void foo(auto&& arg) requires({});
:1:30: error: statement-expressions are not allowed outside functions
nor in
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldalessandro at gmail dot com
Target Milestone: ---
Consider the following code (https://godbolt.org/z/h1bz1qxan).
#include
struct A{};
struct B : A {};
template
concept is_a = std
t: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldalessandro at gmail dot com
Target Milestone: ---
Following (much-reduced) code causes a CTAD failure in gcc but not clang
(https://godbolt.org/z/zWhWGj7PE) with both C++17 and C++20.
template
struct Foo {};
template
struct
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());
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldalessandro at gmail dot com
Target Milestone: ---
I'm at a loss for how to describe this.
I have an intrusive reference counting smart pointer that manipulates the
pointed-to object's `count_` mem
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() :
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldalessandro at gmail dot com
Target Milestone: ---
The constexpr evaluator seems to lose track of dynamic allocations in some
contexts, resulting in false-positive leaks and rejected valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96115
Luke Dalessandro changed:
What|Removed |Added
CC||ldalessandro at gmail dot 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?
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldalessandro at gmail dot com
Target Milestone: ---
GCC inlines function marked noinline when the function is marked as
`constexpr`, even if it is not used in `constexpr` context.
https://godbolt.org/z/b94Kje
```
[[gnu
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
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldalessandro at gmail dot com
Target Milestone: ---
GCC currently rejects the following code snippet, where it infers the constexpr
definition of V as non-constexpr. The monostate
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldalessandro at gmail dot com
Target Milestone: ---
This one involves some language-lawyering, which is not my forte.
While developing a constexpr, array-based vector that supports non
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldalessandro at gmail dot com
Target Milestone: ---
The destructor below is rejected (see https://godbolt.org/z/M8YxTY). Workaround
for now is to mark n as mutable
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?
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldalessandro at gmail dot com
Target Milestone: ---
Following code causes ICE, but *ONLY* when explicitly passing `-std=c++20`.
```
template
struct vector {
union
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldalessandro at gmail dot com
Target Milestone: ---
I get some confusing results from the following code.
https://godbolt.org/z/p5uZgH
> struct [[ gnu::packed ]] Foo {
> Foo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92650
--- Comment #1 from Luke Dalessandro ---
x86-64 gcc (trunk) - cached
#1 with x86-64 gcc (trunk)
In file included from
/opt/compiler-explorer/libs/rangesv3/trunk/include/range/v3/action/action.hpp:19,
from
/opt/compiler-explorer
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldalessandro at gmail dot com
Target Milestone: ---
Created attachment 47349
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47349&action=edit
test case
Following code t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90480
--- Comment #3 from Luke Dalessandro ---
Created attachment 47336
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47336&action=edit
Testcast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90480
--- Comment #2 from Luke Dalessandro ---
I'm hitting this with the following similar, but different snippet. Maybe it
will help with this.
#include
struct Foo {
int operator()(int i) {
return 0;
}
template
auto opera
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86875
--- Comment #1 from Luke Dalessandro ---
Created attachment 44515
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44515&action=edit
Preprocessed source
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldalessandro at gmail dot com
Target Milestone: ---
ICE in 8.2 (Debian gcc package) when capturing `const` variable in y_combinator
recursive lambda. This code works fine in 7.x. Capturing by
86 matches
Mail list logo
