On Tue, Mar 10, 2015 at 8:31 PM, Ian Romanick wrote:
> Also... I'm not a fan of these ever-growing macros. They're a lot like
> alligators. They're pretty cute when they're small, but when they grow
> up they drown you in a river and eat you. I feel like the users of
> this macro should just us
On Tuesday, March 10, 2015 05:48:20 PM Jason Ekstrand wrote:
> On Tue, Mar 10, 2015 at 5:45 PM, Matt Turner wrote:
>
> > On Tue, Mar 10, 2015 at 1:09 PM, Jason Ekstrand
> > wrote:
> > > How about we do things slightly differently and check
> > "(__node)->field.next
> > > != NULL" just like we do
On 03/10/2015 08:04 PM, Connor Abbott wrote:
> On Tue, Mar 10, 2015 at 10:54 PM, Ian Romanick wrote:
>> On 03/09/2015 06:36 PM, Kenneth Graunke wrote:
>>> From: Jason Ekstrand
>>>
>>> __next and __prev are pointers to the structure containing the exec_node
>>> link, not the embedded exec_node. N
On Tue, Mar 10, 2015 at 10:54 PM, Ian Romanick wrote:
> On 03/09/2015 06:36 PM, Kenneth Graunke wrote:
>> From: Jason Ekstrand
>>
>> __next and __prev are pointers to the structure containing the exec_node
>> link, not the embedded exec_node. NULL checks would fail unless the
>> embedded exec_no
On 03/09/2015 06:36 PM, Kenneth Graunke wrote:
> From: Jason Ekstrand
>
> __next and __prev are pointers to the structure containing the exec_node
> link, not the embedded exec_node. NULL checks would fail unless the
> embedded exec_node happened to be at offset 0 in the parent struct.
Wait...
On Tue, Mar 10, 2015 at 5:45 PM, Matt Turner wrote:
> On Tue, Mar 10, 2015 at 1:09 PM, Jason Ekstrand
> wrote:
> > How about we do things slightly differently and check
> "(__node)->field.next
> > != NULL" just like we do on regular versions. Since the check happens
> > between the increment st
On Tue, Mar 10, 2015 at 1:09 PM, Jason Ekstrand wrote:
> How about we do things slightly differently and check "(__node)->field.next
> != NULL" just like we do on regular versions. Since the check happens
> between the increment step and running the user's code, __node is valid for
> every invoca
On Mon, Mar 9, 2015 at 11:06 PM, Matt Turner wrote:
> On Mon, Mar 9, 2015 at 6:36 PM, Kenneth Graunke
> wrote:
> > From: Jason Ekstrand
> >
> > __next and __prev are pointers to the structure containing the exec_node
> > link, not the embedded exec_node. NULL checks would fail unless the
> > e
On Mon, Mar 9, 2015 at 6:36 PM, Kenneth Graunke wrote:
> From: Jason Ekstrand
>
> __next and __prev are pointers to the structure containing the exec_node
> link, not the embedded exec_node. NULL checks would fail unless the
> embedded exec_node happened to be at offset 0 in the parent struct.
>
On Mon, Mar 9, 2015 at 11:02 PM, Jason Ekstrand wrote:
>
>
> On Mon, Mar 9, 2015 at 7:59 PM, Connor Abbott wrote:
>>
>> On Mon, Mar 9, 2015 at 10:54 PM, Jason Ekstrand
>> wrote:
>> >
>> >
>> > On Mon, Mar 9, 2015 at 7:48 PM, Connor Abbott
>> > wrote:
>> >>
>> >> On Mon, Mar 9, 2015 at 10:35 PM,
On Mon, Mar 9, 2015 at 7:59 PM, Connor Abbott wrote:
> On Mon, Mar 9, 2015 at 10:54 PM, Jason Ekstrand
> wrote:
> >
> >
> > On Mon, Mar 9, 2015 at 7:48 PM, Connor Abbott
> wrote:
> >>
> >> On Mon, Mar 9, 2015 at 10:35 PM, Matt Turner
> wrote:
> >> > On Mon, Mar 9, 2015 at 7:24 PM, Matt Turner
On Mon, Mar 9, 2015 at 7:58 PM, Matt Turner wrote:
> On Mon, Mar 9, 2015 at 7:32 PM, Jason Ekstrand
> wrote:
> >
> >
> > On Mon, Mar 9, 2015 at 7:24 PM, Matt Turner wrote:
> >>
> >> On Mon, Mar 9, 2015 at 6:36 PM, Kenneth Graunke
> >> wrote:
> >> > From: Jason Ekstrand
> >> >
> >> > __next an
On Mon, Mar 9, 2015 at 10:54 PM, Jason Ekstrand wrote:
>
>
> On Mon, Mar 9, 2015 at 7:48 PM, Connor Abbott wrote:
>>
>> On Mon, Mar 9, 2015 at 10:35 PM, Matt Turner wrote:
>> > On Mon, Mar 9, 2015 at 7:24 PM, Matt Turner wrote:
>> >> On Mon, Mar 9, 2015 at 6:36 PM, Kenneth Graunke
>> >> wrote:
On Mon, Mar 9, 2015 at 7:32 PM, Jason Ekstrand wrote:
>
>
> On Mon, Mar 9, 2015 at 7:24 PM, Matt Turner wrote:
>>
>> On Mon, Mar 9, 2015 at 6:36 PM, Kenneth Graunke
>> wrote:
>> > From: Jason Ekstrand
>> >
>> > __next and __prev are pointers to the structure containing the exec_node
>> > link,
On Mon, Mar 9, 2015 at 7:48 PM, Connor Abbott wrote:
> On Mon, Mar 9, 2015 at 10:35 PM, Matt Turner wrote:
> > On Mon, Mar 9, 2015 at 7:24 PM, Matt Turner wrote:
> >> On Mon, Mar 9, 2015 at 6:36 PM, Kenneth Graunke
> wrote:
> >>> From: Jason Ekstrand
> >>>
> >>> __next and __prev are pointers
On Mon, Mar 9, 2015 at 10:35 PM, Matt Turner wrote:
> On Mon, Mar 9, 2015 at 7:24 PM, Matt Turner wrote:
>> On Mon, Mar 9, 2015 at 6:36 PM, Kenneth Graunke
>> wrote:
>>> From: Jason Ekstrand
>>>
>>> __next and __prev are pointers to the structure containing the exec_node
>>> link, not the embe
On Mon, Mar 9, 2015 at 7:24 PM, Matt Turner wrote:
> On Mon, Mar 9, 2015 at 6:36 PM, Kenneth Graunke wrote:
>> From: Jason Ekstrand
>>
>> __next and __prev are pointers to the structure containing the exec_node
>> link, not the embedded exec_node. NULL checks would fail unless the
>> embedded e
On Mon, Mar 9, 2015 at 7:24 PM, Matt Turner wrote:
> On Mon, Mar 9, 2015 at 6:36 PM, Kenneth Graunke
> wrote:
> > From: Jason Ekstrand
> >
> > __next and __prev are pointers to the structure containing the exec_node
> > link, not the embedded exec_node. NULL checks would fail unless the
> > em
On Mon, Mar 9, 2015 at 6:36 PM, Kenneth Graunke wrote:
> From: Jason Ekstrand
>
> __next and __prev are pointers to the structure containing the exec_node
> link, not the embedded exec_node. NULL checks would fail unless the
> embedded exec_node happened to be at offset 0 in the parent struct.
>
Reviewed-by: Connor Abbott
On Mon, Mar 9, 2015 at 9:36 PM, Kenneth Graunke wrote:
> From: Jason Ekstrand
>
> __next and __prev are pointers to the structure containing the exec_node
> link, not the embedded exec_node. NULL checks would fail unless the
> embedded exec_node happened to be at off
From: Jason Ekstrand
__next and __prev are pointers to the structure containing the exec_node
link, not the embedded exec_node. NULL checks would fail unless the
embedded exec_node happened to be at offset 0 in the parent struct.
Signed-off-by: Jason Ekstrand
Reviewed-by: Kenneth Graunke
---
21 matches
Mail list logo