Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vittorio.romeo at outlook dot com
Target Milestone: ---
The following code
constexpr int f(const int* p)
{
if (p == nullptr
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vittorio.romeo at outlook dot com
Target Milestone: ---
Consider the following code:
enum class E : int { eA };
struct S { E i : 2; };
S f() { return {.i = E::eA}; }
Clang accepts
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vittorio.romeo at outlook dot com
Target Milestone: ---
Clang 21 supports a new builtin called `__builtin_structured_binding_size(T)`,
that efficiently returns the
NCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vittorio.romeo at outlook dot com
Target Milestone: ---
Given this code:
template struct S { S(); };
// extern template struct S;
temp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109380
--- Comment #2 from Vittorio Romeo ---
Hmm, you might be correct. Seeing that the issue has not been looked at since
2017, are you aware of any workaround besides `-Wl,--export-all-symbols`?
The issue is preventing me from applying explicit te
: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vittorio.romeo at outlook dot com
Target Milestone: ---
Created attachment 54801
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54801&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89088
Vittorio Romeo changed:
What|Removed |Added
CC||vittorio.romeo at outlook dot
com
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vittorio.romeo at outlook dot com
Target Milestone: ---
This is another possible compilation speed improvement that came to mind after
running ClangBuildAnalyzer on a few open
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100157
--- Comment #9 from Vittorio Romeo ---
(In reply to Jonathan Wakely from comment #8)
> (In reply to Vittorio Romeo from comment #6)
> > worthwhile to keep the same name as Clang for compatibility,
>
> No, that's not an option. Clang's is a buil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100157
--- Comment #6 from Vittorio Romeo ---
Thank you, Jonathan, for looking into this. I feel like it might be worthwhile
to keep the same name as Clang for compatibility, or maybe talk to some Clang
developers and see if there can be an agreement o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96780
--- Comment #7 from Vittorio Romeo ---
> As discussed on IRC, we might not want to do this folding at -O0 (although
> I'd personally be happy with it unconditionally).
I think you should reconsider this as discussed in these places:
- https://g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104719
--- Comment #9 from Vittorio Romeo ---
I have done some benchmarking for three use cases, both with `-O0` and `-Og`,
hacking my `libstdc++` headers to add `[[gnu::always_inline]]` where deemed
appropriate.
---
The use cases were:
1. `operato
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104719
--- Comment #6 from Vittorio Romeo ---
> The request is to replace it with some kind of magic that does the same as
> std::move without actually writing std::move.
More generally speaking, ensure that function such as `std::move`,
`std::forwar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104719
--- Comment #4 from Vittorio Romeo ---
I see that `std::move` is indeed inlined with `-Og`, my apologies on not
noticing that.
I like the idea of having the compiler itself fold calls to things like
`std::move` and `std::forward` as suggested
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: vittorio.romeo at outlook dot com
Target Milestone: ---
`std::accumulate` is defined as follows in `libstdc++`:
```
template
_GLIBCXX20_CONSTEXPR
inline _Tp
++
Assignee: unassigned at gcc dot gnu.org
Reporter: vittorio.romeo at outlook dot com
Target Milestone: ---
Clang provides a `__type_pack_element` builtin which allows efficient indexing
of parameter packs in variadic templates, and it seems that GCC has no
equivalent.
This
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: vittorio.romeo at outlook dot com
Target Milestone: ---
`std::clamp` generates poor assembly compared to hand-written counterpart for
primitive types like `float`, even with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79378
Vittorio Romeo changed:
What|Removed |Added
CC||vittorio.romeo at outlook dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81676
Vittorio Romeo changed:
What|Removed |Added
CC||vittorio.romeo at outlook dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90571
--- Comment #4 from Vittorio Romeo ---
> I wonder how the "original" testcase looked
like - the one in this bug is probably simplified from real-world code?
This is what the original author of the code (Filipp Gelman) said:
> I was reviewing so
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vittorio.romeo at outlook dot com
Target Milestone: ---
Given the following two functions:
int f() { return 0; }
int g() { return 1; }
And the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90215
--- Comment #4 from Vittorio Romeo ---
Simplified quite a lot, removed `` dependency:
https://gcc.godbolt.org/z/6uNcCN
struct X
{
template
void f(F f)
{
f(0);
}
};
template
void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90215
--- Comment #3 from Vittorio Romeo ---
Changing the lambda to the following
std::apply([&xs...](auto&... ys)
{
(xs.f([&ys...](auto y)
{
ys = y;
}), ...);
}, t);
produces a different ICE:
:
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vittorio.romeo at outlook dot com
Target Milestone: ---
The following code
#include
template
struct X
{
template
void f(F f)
{
f(0
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vittorio.romeo at outlook dot com
Target Milestone: ---
Consider the following code:
template
void foo(F f)
{
[f](auto... xs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88557
--- Comment #1 from Vittorio Romeo ---
The "ice-on-invalid-code" tag was added, but I thought this was valid C++2a
code. Am I mistaken?
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vittorio.romeo at outlook dot com
Target Milestone: ---
The following code
template
void f() { }
causes an internal compiler error on gcc 9.x version 20181218:
: In
verity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: vittorio.romeo at outlook dot com
Target Milestone: ---
Consider the following set of types:
struct Type0 { int x; };
struct Type1 { int x; };
struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47226
--- Comment #19 from Vittorio Romeo ---
(In reply to Jonathan Wakely from comment #18)
> (In reply to Vittorio Romeo from comment #17)
> > Was the patch merged in trunk?
>
> It was committed to trunk: r251433
>
> > The following still fails to
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vittorio.romeo at outlook dot com
Target Milestone: ---
The following code snippet...
template
void foo()
{
([i = Is]{}(), ...);
}
...does
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47226
--- Comment #17 from Vittorio Romeo ---
Was the patch merged in trunk?
The following still fails to compile on 20180407
template
int foo()
{
([i = Is]{}(), ...);
return 0;
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84916
Vittorio Romeo changed:
What|Removed |Added
CC||vittorio.romeo at outlook dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81486
--- Comment #2 from Vittorio Romeo ---
Here's a snippet that seems to reproduce this bug, even without an explicit
deduction guide:
template
struct foo
{
template
foo(Us...) { }
};
int main()
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80871
Vittorio Romeo changed:
What|Removed |Added
CC||vittorio.romeo at outlook dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52869
Vittorio Romeo changed:
What|Removed |Added
CC||vittorio.romeo at outlook dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79180
Vittorio Romeo changed:
What|Removed |Added
CC||vittorio.romeo at outlook dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79590
--- Comment #2 from Vittorio Romeo ---
This is still present. Here are some more examples:
int main()
{
[](auto x) noexcept(noexcept(x)) { } (0);
}
:3:40: internal compiler error: in nothrow_spec_p, at cp/except.c:1159
[](auto x) noe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80370
--- Comment #4 from Vittorio Romeo ---
Even shorter:
template struct tuple_size { static constexpr int value = 1; };
template struct tuple_element { typedef int type; };
template struct tuple {};
template int get(T);
int
main ()
{
[](aut
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64488
Vittorio Romeo changed:
What|Removed |Added
CC||vittorio.romeo at outlook dot
com
Version: 6.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vittorio.romeo at outlook dot com
Target Milestone: ---
Created attachment 38592
--> ht
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vittorio.romeo at outlook dot com
Target Milestone: ---
Long typenames, usually generated by heavy template metaprogramming code,
result in errors that are
critical
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vittorio.romeo at outlook dot com
Target Milestone: ---
Created attachment 38410
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38410&action=edit
Minimal code e
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vittorio.romeo at outlook dot com
Target Milestone: ---
https://godbolt.org/g/Tt8hfe
int main()
{
int x = 0;
// warning: logical 'or' of collectively exhaustive tests is always true
[-Wlogical-op
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vittorio.romeo at outlook dot com
Target Milestone: ---
auto bound_f = [=](auto... xs) -> decltype(f(x, xs...))
{
return f(x, xs...);
};
return curry_impl{}>::exec(b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69057
--- Comment #1 from Vittorio Romeo ---
> in constexpr expansion of ‘from_enum(array)’
> internal compiler error: Segmentation fault
static constexpr GLenum target_value{from_enum(buffer_target::array)};
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vittorio.romeo at outlook dot com
Target Milestone: ---
gcc.godbolt.org example: https://goo.gl/yGCVOB
---
#include
using GLenum = unsigned int;
template
inline constexpr auto
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vittorio.romeo at outlook dot com
Target Milestone: ---
gcc.godbolt.org: https://goo.gl/oJf4gs
auto count = [](auto&&... xs)
{
return sizeof...(xs);
};
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vittorio.romeo at outlook dot com
Target Milestone: ---
Not sure what's causing the segmentation fault, but here's a minimal example.
The segfault happens with g++ 5.
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vittorio.romeo at outlook dot com
Target Milestone: ---
struct C
{
template
auto operator()(T&& x, TRest&&...){ return x; }
};
int main()
{
// Compiles both with clang and gcc.
auto
ion: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vittorio.romeo at outlook dot com
Target Milestone: ---
Passing a `this`-capturing generic lambda (to a templ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67274
--- Comment #1 from Vittorio Romeo ---
More test cases, using minor variations to the code posted above:
With bar() = call([this](auto x){ foo(x); });
clang++ 3.6+ compiles.
g++ 5.2+ does not compile.
With bar() = call([this](auto x){ this->foo
++
Assignee: unassigned at gcc dot gnu.org
Reporter: vittorio.romeo at outlook dot com
Target Milestone: ---
The `-Wshadow` flag fires an incorrect warning using generic lambdas with
`auto` type deduction.
Minimal example:
http://melpon.org/wandbox/permlink/ynGNXTYN8rY40BgY
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67248
Vittorio Romeo changed:
What|Removed |Added
CC||vittorio.romeo at outlook dot
com
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vittorio.romeo at outlook dot com
inline constexpr int exampleFunction(int min, int max)
{
assert(min <= max);
return min + max;
}
The above function fails to compile, because of
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58130
Vittorio Romeo changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58130
--- Comment #1 from Vittorio Romeo ---
Isn't
decltype(items)
equivalent to
std::vector>
?
Severity: major
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vittorio.romeo at outlook dot com
Tested both on Windows 8 x86 and Arch Linux x64.
Compiling with "-O3 -Wall -Wextra -pedantic"
struct myStruct
57 matches
Mail list logo
