On 10/24/2013 05:02 AM, Richard Sandiford wrote:
> Do we actually need to do a conversion here at all? It looks like the
> modes of "expected" and "desired" should already match "mem", so we could
> just use create_input_operand.
This works. I've committed the following to mainline, and will
tes
Eric Botcazou writes:
>> That's a fairly dangerous hack in my opinion, in particular this breaks the
>> uniqueness of representation of -1 as constm1_rtx. Can't we find a really
>> contained hack instead, especially if we want to backport it to 4.8?
>
> In particular, can't Uros' patch be conside
> That's a fairly dangerous hack in my opinion, in particular this breaks the
> uniqueness of representation of -1 as constm1_rtx. Can't we find a really
> contained hack instead, especially if we want to backport it to 4.8?
In particular, can't Uros' patch be considered as such here? Frankly, t
On Thu, Oct 24, 2013 at 10:43 AM, Eric Botcazou wrote:
>> The most isolated patch I can come up with, especially since we ought to
>> fix this in 4.8 branch as well, is to only allow expansion of wide int
>> modes to const_int when they're positive.
>>
>> Thoughts?
>
> That's a fairly dangerous ha
> The most isolated patch I can come up with, especially since we ought to
> fix this in 4.8 branch as well, is to only allow expansion of wide int
> modes to const_int when they're positive.
>
> Thoughts?
That's a fairly dangerous hack in my opinion, in particular this breaks the
uniqueness of
In this pr, we have a -1 in type __int128. Since this value can be
represented in a HOST_WIDE_INT, we expand this to a const_int.
The expansion from tree to rtl happens in expand_builtin_atomic_store. And as
with most of our builtins, we then pass off the rtl to another routine for
expansion. W
