On Sat, 13 Apr 2024, Iain Sandoe wrote:
> Hi Patrick,
>
> > On 10 Apr 2024, at 17:33, Jason Merrill wrote:
> >
> > On 4/10/24 11:26, Patrick Palka wrote:
> >> On Wed, 10 Apr 2024, Patrick Palka wrote:
> >>>
> >>> On Tue, 9 Apr 2024, Jason Merrill wrote:
> >>>
> On 2/16/24 10:06, Patrick
Hi Patrick,
> On 10 Apr 2024, at 17:33, Jason Merrill wrote:
>
> On 4/10/24 11:26, Patrick Palka wrote:
>> On Wed, 10 Apr 2024, Patrick Palka wrote:
>>>
>>> On Tue, 9 Apr 2024, Jason Merrill wrote:
>>>
On 2/16/24 10:06, Patrick Palka wrote:
> On Thu, 15 Feb 2024, Patrick Palka wrote:
;base.public_flag);
+ else
+WB (false);
Can we simplify the pattern for conditionally writing/reading? It looks easy
to forget to add the else. Perhaps a COND_WB macro with rationale comment?
Fixed.
Here's an incremental diff of the changes. Will send updated patch as a
follow-up
cp/module.cc
> > > index 0291d456ff5..2ecee007e8a 100644
> > > --- a/gcc/cp/module.cc
> > > +++ b/gcc/cp/module.cc
> > > @@ -694,13 +656,126 @@ protected:
> > > /* Instrumentation. */
> > > static unsigned spans[4];
> > >
On Tue, 9 Apr 2024, Jason Merrill wrote:
> On 2/16/24 10:06, Patrick Palka wrote:
> > On Thu, 15 Feb 2024, Patrick Palka wrote:
> >
> > > One would expect consecutive calls to bytes_in/out::b for streaming
> > > adjacent bits, as we do for tree flag streaming, to at least be
> > > optimized by
On 2/16/24 10:06, Patrick Palka wrote:
On Thu, 15 Feb 2024, Patrick Palka wrote:
One would expect consecutive calls to bytes_in/out::b for streaming
adjacent bits, as we do for tree flag streaming, to at least be
optimized by the compiler into individual bit operations using
statically known bi
On Tue, 26 Mar 2024, Patrick Palka wrote:
> On Tue, 27 Feb 2024, Patrick Palka wrote:
>
> > On Fri, 16 Feb 2024, Patrick Palka wrote:
> >
> > > On Thu, 15 Feb 2024, Patrick Palka wrote:
> > >
> > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> > > > OK for trunk?
> > > >
On Tue, 27 Feb 2024, Patrick Palka wrote:
> On Fri, 16 Feb 2024, Patrick Palka wrote:
>
> > On Thu, 15 Feb 2024, Patrick Palka wrote:
> >
> > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> > > OK for trunk?
> > >
> > > -- >8 --
> > >
> > > One would expect consecutive ca
On Fri, 16 Feb 2024, Patrick Palka wrote:
> On Thu, 15 Feb 2024, Patrick Palka wrote:
>
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> > OK for trunk?
> >
> > -- >8 --
> >
> > One would expect consecutive calls to bytes_in/out::b for streaming
> > adjacent bits, as we d
On Thu, 15 Feb 2024, Patrick Palka wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> OK for trunk?
>
> -- >8 --
>
> One would expect consecutive calls to bytes_in/out::b for streaming
> adjacent bits, as we do for tree flag streaming, to at least be
> optimized by the
On Thu, Feb 15, 2024 at 7:38 PM Patrick Palka wrote:
>
> Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> OK for trunk?
Btw, there's the "bitpack" streaming support in data-streamer.h also
added for exactly the same reason, it's likely not easily re-usable
but this kind of appr
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
-- >8 --
One would expect consecutive calls to bytes_in/out::b for streaming
adjacent bits, as we do for tree flag streaming, to at least be
optimized by the compiler into individual bit operations using
statically kn
12 matches
Mail list logo
