https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114632
waffl3x changed:
What|Removed |Added
CC||waffl3x at protonmail dot com
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113388
--- Comment #1 from waffl3x ---
Yeah, looks like a bug. I won't be able to look at it as I am in the
process of moving but it seems like a similar one to PR113348.
Thanks for the report!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113348
Bug ID: 113348
Summary: ice when calling xobj member function without an
object in an xobj member function
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
--- Comment #29 from waffl3x ---
https://cplusplus.github.io/CWG/issues/2789.html
My alteration to CWG2789 came up on reddit and I realized I should
probably post about it here.
Instead of:
"if both are non-static member functions, they have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
--- Comment #26 from waffl3x ---
(In reply to corentinjabot from comment #25)
> Hey folks.
> Congrats on landing support for deducing this in GCC.
Thanks!
> While there is no spec for it, after discussion here,
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113307
--- Comment #1 from waffl3x ---
I'm on it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113308
--- Comment #3 from waffl3x ---
I meant to post this link instead of one of the others.
https://godbolt.org/z/oMP8185Yh
I guess I shouldn't be replying to things while still waking up, sorry!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113308
--- Comment #2 from waffl3x ---
(In reply to Nathaniel Shead from comment #1)
> I believe this is correct behaviour: The definition of `operator++` in the
> child class hides the `operator++` declared in the base class. Similarly to
> the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113191
--- Comment #2 from waffl3x ---
> Looking at the above commit, joust already takes care to check
> more_constrained for non-template functions, and only if their function
> parameters match according to cand_parms_match. But here
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113191
Bug ID: 113191
Summary: [10.1/11/12/13/14 Regression] Incorrect overload
resolution when base class function introduced with a
using declaration is more constrained than a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113075
Bug ID: 113075
Summary: Inconsistent/wrong diagnostic when incorrectly taking
address of single/overloaded
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83417
waffl3x changed:
What|Removed |Added
CC||waffl3x at protonmail dot com
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112874
Bug ID: 112874
Summary: low quality diagnostic for overload resolution failure
when taking address of overloaded function
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112810
Bug ID: 112810
Summary: bogus ambiguous overload resolution when taking
address of static/xobj member function template
introduced by using declaration where candidates have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
--- Comment #18 from waffl3x ---
(In reply to Gašper Ažman from comment #17)
> 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
--- Comment #16 from waffl3x ---
Just gotta note that the patch posted here had an oversight, it never worked as
I hoped. The good news is, I submitted a finalized patch to the patch maillist,
just before I have to leave. Thanks for the help
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
--- Comment #15 from waffl3x ---
Created attachment 55793
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55793=edit
inital support for P0847 explicit-object-parameter
Alright, I finalized something that I hope is worthy of criticism. I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
--- Comment #13 from waffl3x ---
I am finding myself realizing that implementing this as a member function and
turning off member function bits seems to be more difficult than implementing
it as a static function and implementing member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
--- Comment #11 from waffl3x ---
(In reply to Jonathan Wakely from comment #9)
> If we're right about that, then I agree that a warning would be useful for
> classes that have no such implicit conversion from S to S*.
>
> I think the warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
--- Comment #7 from waffl3x ---
struct S {
int f(this S*) {
return 5;
}
};
int main()
{
S s{};
return s.f();
}
Here is my current progress, this code works. I have a good feeling that the
rest is going to be easy.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
--- Comment #6 from waffl3x ---
I've noticed the standard does call `this` a specifier, I will perhaps rework
the code to just do parsing in cp_decl_specifier_seq.
(In reply to Gašper Ažman from comment #5)
> And of course by "this" I meant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
--- Comment #3 from waffl3x ---
I have some elements working so far, I opted to implement parsing for `this` in
cp_parser_parameter_declaration instead of in cp_parser_decl_specifier_seq
because I didn't want to add another member to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109181
--- Comment #6 from waffl3x ---
PR 110927 presents a similar use case that originally lead me to this bug, I
also posted the workarounds that I had since discovered there. If anyone coming
across this bug is looking for a solution you can find
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110927
waffl3x changed:
What|Removed |Added
CC||waffl3x at protonmail dot com
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110566
--- Comment #6 from waffl3x ---
(In reply to Patrick Palka from comment #5)
> Should be fixed on trunk so far.
Once it shows up on godbolt I will make sure that all the cases that exhibited
the bug are working for me now. I had a bunch of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110566
Bug ID: 110566
Summary: [13/14 Regression] ICE when instantiating function
template with template template parameter with 2 or
more auto parameters with a dependent member template,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110006
waffl3x changed:
What|Removed |Added
CC||waffl3x at protonmail dot com
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110291
--- Comment #1 from waffl3x ---
I opened Bug 110006 and forgot to check before submitting, looking over at it,
I'm pretty sure it's the same bug, and if not, then probably related.
https://godbolt.org/z/7zoWfG4Ws I checked their reproduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110291
Bug ID: 110291
Summary: [11.1 Regression] constraint on friend operator
template causes bizarre duplication of RHS template
parameter that is passed to the requires expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110122
--- Comment #5 from waffl3x ---
(In reply to Patrick Palka from comment #4)
>
> Yes, it seems the original testcase is exhibiting two bugs (one of which a
> GCC 13 regression), whereas the second testcase exhibits one
> (non-regression) bug.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110122
--- Comment #3 from waffl3x ---
Very cool, thanks, since your test case seems to cause problems in GCC 11 and
GCC 12 does that mean the bug goes deeper than I thought?
(In reply to Patrick Palka from comment #2)
> It seems only the first
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110122
Bug ID: 110122
Summary: using an aggregate with a member variable with a user
defined copy constructor in a class NTTP causes
capture and use of the `this` pointer in a generic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109181
--- Comment #5 from waffl3x ---
(In reply to Patrick Palka from comment #3)
> A workaround is to just remove the unneeded 'template' after the :: in this
> case. Or is there an example where the template keyword is needed that we
> incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109181
--- Comment #2 from waffl3x ---
(In reply to Andrew Pinski from comment #1)
> Confirmed.
> Goes away the way back when -fconcepts support was originally added in GCC
> 6. You can see that with this testcase:
> ```
> struct A {
> template
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109181
Bug ID: 109181
Summary: requires expression type requirement rejects valid
type when it is a nested member template
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109168
Bug ID: 109168
Summary: bogus error: 'X' is not a valid template argument of
type 'Y' because 'X' is not a variable
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108998
--- Comment #3 from waffl3x ---
I made a mistake in my previous comment, the version on my system that fails is
12.2.1, sorry for any possible confusion.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108998
--- Comment #1 from waffl3x ---
I ran it on my local system, just to get some line numbers, and I accidentally
ran it on an older version (12.1) and found that it has a similar result, I'm
posting the output of -v and the error of both here. As
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108998
Bug ID: 108998
Summary: ICE in tsubst, at cp/pt.cc:16037
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
39 matches
Mail list logo
