On 12/17/20 8:44 AM, Nathan Sidwell wrote:
> On 12/17/20 10:38 AM, Richard Sandiford via Gcc-patches wrote:
>> Tom Tromey writes:
"Richard" == Richard Sandiford via Gcc-patches
writes:
>>>
>>> Richard> +// A class that stores a choice "A or B", where A has type
>>> T1 * and B
On 12/17/20 10:38 AM, Richard Sandiford via Gcc-patches wrote:
Tom Tromey writes:
"Richard" == Richard Sandiford via Gcc-patches writes:
Richard> +// A class that stores a choice "A or B", where A has type T1 * and B
has
Richard> +// type T2 *. Both T1 and T2 must have an alignment greater
Tom Tromey writes:
>> "Richard" == Richard Sandiford via Gcc-patches
>> writes:
>
> Richard> +// A class that stores a choice "A or B", where A has type T1 * and
> B has
> Richard> +// type T2 *. Both T1 and T2 must have an alignment greater than
> 1, since
> Richard> +// the low bit
> "Richard" == Richard Sandiford via Gcc-patches
> writes:
Richard> +// A class that stores a choice "A or B", where A has type T1 * and B
has
Richard> +// type T2 *. Both T1 and T2 must have an alignment greater than 1,
since
Richard> +// the low bit is used to identify B over A. T1
Martin Sebor writes:
> On 11/26/20 10:06 AM, Richard Sandiford wrote:
>> Martin Sebor writes:
>>> I do have one concern: the tendency to prioritize efficiency
>>> over safety (this can be said about most GCC code). Specifically
>>> in this class, the address bit twiddling makes me uneasy. I don'
On 11/26/20 9:15 AM, Richard Sandiford wrote:
> Jeff Law writes:
>> On 11/13/20 1:14 AM, Richard Sandiford via Gcc-patches wrote:
>>> This patch adds a pointer_mux class that provides similar
>>> functionality to:
>>>
>>> union { T1 *a; T2 *b; };
>>> ...
>>> bool is_b_rather_than_a;
On 11/26/20 10:06 AM, Richard Sandiford wrote:
Martin Sebor writes:
I do have one concern: the tendency to prioritize efficiency
over safety (this can be said about most GCC code). Specifically
in this class, the address bit twiddling makes me uneasy. I don't
think the object model in either l
Richard Sandiford via Gcc-patches writes:
> One thing I'd deliberately tried to avoid was converting integers
> “back” to pointers, because that seemed like a more dangerous thing.
> That's why:
>
>>> +template
>>> +inline T2 *
>>> +pointer_mux::second_or_null () const
>>> +{
>>> + // Micro optim
Martin Sebor writes:
> I do have one concern: the tendency to prioritize efficiency
> over safety (this can be said about most GCC code). Specifically
> in this class, the address bit twiddling makes me uneasy. I don't
> think the object model in either language (certainly not C but
> I don't hav
Jeff Law writes:
> On 11/13/20 1:14 AM, Richard Sandiford via Gcc-patches wrote:
>> This patch adds a pointer_mux class that provides similar
>> functionality to:
>>
>> union { T1 *a; T2 *b; };
>> ...
>> bool is_b_rather_than_a;
>>
>> except that the is_b_rather_than_a tag is stored in
On 11/13/20 1:14 AM, Richard Sandiford via Gcc-patches wrote:
This patch adds a pointer_mux class that provides similar
functionality to:
union { T1 *a; T2 *b; };
...
bool is_b_rather_than_a;
except that the is_b_rather_than_a tag is stored in the low bit
of the pointer. See the
On 11/13/20 1:14 AM, Richard Sandiford via Gcc-patches wrote:
> This patch adds a pointer_mux class that provides similar
> functionality to:
>
> union { T1 *a; T2 *b; };
> ...
> bool is_b_rather_than_a;
>
> except that the is_b_rather_than_a tag is stored in the low bit
> of the poi
This patch adds a pointer_mux class that provides similar
functionality to:
union { T1 *a; T2 *b; };
...
bool is_b_rather_than_a;
except that the is_b_rather_than_a tag is stored in the low bit
of the pointer. See the comments in the patch for a comparison
between the two approaches
13 matches
Mail list logo