On 9/20/24 7:34 PM, Patrick Palka wrote:
On Fri, 20 Sep 2024, Jason Merrill wrote:
On 9/20/24 6:51 PM, Patrick Palka wrote:
On Fri, 20 Sep 2024, Jason Merrill wrote:
On 9/18/24 10:59 PM, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this
look OK for trunk? I'
On Fri, 20 Sep 2024, Jason Merrill wrote:
> On 9/20/24 6:51 PM, Patrick Palka wrote:
> > On Fri, 20 Sep 2024, Jason Merrill wrote:
> >
> > > On 9/18/24 10:59 PM, Patrick Palka wrote:
> > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this
> > > > look OK for trunk? I'm not sure this
On 9/20/24 6:51 PM, Patrick Palka wrote:
On Fri, 20 Sep 2024, Jason Merrill wrote:
On 9/18/24 10:59 PM, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this
look OK for trunk? I'm not sure this is worth backporting
without the previous CWG 2273 tweak since it'll m
On Fri, 20 Sep 2024, Jason Merrill wrote:
> On 9/18/24 10:59 PM, Patrick Palka wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this
> > look OK for trunk? I'm not sure this is worth backporting
> > without the previous CWG 2273 tweak since it'll mean inconsistent
> > behavior b
On 9/18/24 10:59 PM, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this
look OK for trunk? I'm not sure this is worth backporting
without the previous CWG 2273 tweak since it'll mean inconsistent
behavior between implict vs explicit object members in GCC 14: the ca
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this
look OK for trunk? I'm not sure this is worth backporting
without the previous CWG 2273 tweak since it'll mean inconsistent
behavior between implict vs explicit object members in GCC 14: the call
to S<>{}.f() in concepts-memfun4.C would
