https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121231
--- Comment #10 from Gašper Ažman ---
:applause:
That was quick :)
On Wed, Aug 6, 2025 at 3:44 PM ppalka at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121231
>
> Patrick Palka changed:
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121231
--- Comment #6 from Gašper Ažman ---
Yeah, but shouldn't `{}` do zero-initialization?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121231
--- Comment #3 from Gašper Ažman ---
Would that make it a /way/ reduced test case in that case?
PR 94511 seems to be value-dependent. In this case, both clang and msvc accept
and generate correct code. PR 94511 seems like you needed to tweak it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121231
Bug ID: 121231
Summary: [13->trunk] miscompile with brace-initialized constant
template parameter perhaps due to function coalescing
Product: gcc
Version: 16.0
Status: U
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117983
Bug ID: 117983
Summary: [13.2 regression] -Wstringop-overflow false positive
for __builtin_memmove from vector::insert
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
--- Comment #30 from Gašper Ažman ---
I don't really understand what you meant by "they have corresponding object
parameters" - you mean that the object parameters are equal in both constraint
and type? "Corresponding" to my recollection is only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
--- Comment #27 from Gašper Ažman ---
I think there is an example in the standard that distinguishes those two as
far as overload resolution is concerned.
On Thu, Jan 11, 2024, 21:08 waffl3x at protonmail dot com <
gcc-bugzi...@gcc.gnu.org> wro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
--- Comment #19 from Gašper Ažman ---
Correct, the use of the capture is the source of the error, not the
instantiation with an unrelated type.
On Sat, Sep 2, 2023, 09:54 waffl3x at protonmail dot com <
gcc-bugzi...@gcc.gnu.org> wrote:
> https
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
--- Comment #17 from Gašper Ažman ---
Read through the patch quickly, want to suggest a few tests.
When a lambda has captures, the explicit object parameter is used to get at
them *silently*, if they are related, otherwise the program is ill-fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
--- Comment #12 from Gašper Ažman ---
Replies to relevant snippets inline.
That was quite a write-up!
> The only compelling case I can think of for such a thing would be passing a
> pointer type that isn't related by inheritance anyway. That
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
--- Comment #10 from Gašper Ažman ---
Yes, the explicit object parameter always receives the cv-l/r qualified
reference to the object of the call. Implicit conversions are then of
course allowed, same as any other parameter. S* is not that usefu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
--- Comment #5 from Gašper Ažman ---
And of course by "this" I meant support for a default argument on the explicit
object parameter.
We might add it back in the future if we find a usecase.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
--- Comment #4 from Gašper Ažman ---
As one of the authors, I can assure you you never need to implement this for
c++23.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110441
--- Comment #2 from Gašper Ažman ---
Some more color from twitter, courtesy of @matthewecross:
Interestingly both "return S::f();" and "auto s = S(); return s.f();" both
pass. It's only when you create a temporary instance of S in the return
s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110441
Gašper Ažman changed:
What|Removed |Added
CC||gasper.azman at gmail dot com
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110380
--- Comment #4 from Gašper Ažman ---
John McFarlane noted that pre-initializing coverage datastructures with the
results of the constexpr-evaluated traces would also be a possible direction.
It does mean the linker needs to then correctly merge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110380
--- Comment #2 from Gašper Ažman ---
-fprofile-constexpr is perfectly fine :), as long as it gets a filename
argument for the output; build automation will be thankful.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110380
Bug ID: 110380
Summary: [feature request] "-pg-constexpr=coverage-output" emit
coverage metrics for constexpr code evaluated at
compile time
Product: gcc
Version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98660
--- Comment #5 from Gašper Ažman ---
s/endif/pragma GCC diagnostic pop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98660
--- Comment #4 from Gašper Ažman ---
@Eric Gallager: yes, the #pragma solution is what I currently use. It is
entirely unsatisfactory, for the reasons described in my original request.
The long-term usefulness of warnings is directly proportiona
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98660
--- Comment #2 from Gašper Ažman ---
Ivan: indeed, you could use a static cast, or a macro - you're literally just
changing the value category of the expression to its original one. The cast is
safe.
The reason Niebler and friends (including me)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98660
Bug ID: 98660
Summary: -Wold-style-cast should not warn on casts that look
like (decltype(x))(x)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: nor
22 matches
Mail list logo
