On 14/07/11 15:15, Richard Guenther wrote:
Is this version OK?
Ok.
I've just committed this slightly updated patch.
I found some bugs while testing, now fixed. Most of the changes in this
patch are context changes, and using widened_mode to handle VOIDmode
constants.
Andrew
2011-08-19 An
On 21/07/11 20:29, Joseph S. Myers wrote:
On Tue, 12 Jul 2011, Richard Guenther wrote:
(**) We really ought to forbid any arithmetic on types that have non-mode
precision and only allow conversions to/from such types.
Arithmetic on such types is a perfectly reasonable notion to have in
langua
On Tue, 12 Jul 2011, Richard Guenther wrote:
> (**) We really ought to forbid any arithmetic on types that have non-mode
> precision and only allow conversions to/from such types.
Arithmetic on such types is a perfectly reasonable notion to have in
language-independent code and carry out languag
On Thu, Jul 14, 2011 at 4:10 PM, Andrew Stubbs wrote:
> On 12/07/11 12:04, Richard Guenther wrote:
>>
>> I wonder if we want to restrict the WIDEN_* operations to operate
>> on types that have matching type/mode precision(**).
>
> I've now modified the patch to allow bitfields, or other case where
On 12/07/11 12:04, Richard Guenther wrote:
I wonder if we want to restrict the WIDEN_* operations to operate
on types that have matching type/mode precision(**).
I've now modified the patch to allow bitfields, or other case where the
precision is smaller than the mode-size. I've also addressed
On Tue, Jul 12, 2011 at 1:26 PM, Andrew Stubbs wrote:
> On 12/07/11 12:05, Richard Guenther wrote:
>>
>> (**) We really ought to forbid any arithmetic on types that have non-mode
>> precision and only allow conversions to/from such types.
>
> Hmmm, presumably the problem is that we might have a co
On 12/07/11 12:05, Richard Guenther wrote:
(**) We really ought to forbid any arithmetic on types that have non-mode
precision and only allow conversions to/from such types.
Hmmm, presumably the problem is that we might have a compatible
precision, but the backends actually work with purely mo
On Tue, Jul 12, 2011 at 1:04 PM, Richard Guenther
wrote:
> On Tue, Jul 12, 2011 at 11:50 AM, Andrew Stubbs wrote:
>> On 23/06/11 15:39, Andrew Stubbs wrote:
>>>
>>> This patch has two effects:
>>>
>>> 1. It permits the use of widening multiply instructions that widen by
>>> more than one mode. E.
On Tue, Jul 12, 2011 at 11:50 AM, Andrew Stubbs wrote:
> On 23/06/11 15:39, Andrew Stubbs wrote:
>>
>> This patch has two effects:
>>
>> 1. It permits the use of widening multiply instructions that widen by
>> more than one mode. E.g. HImode -> DImode.
>>
>> 2. It enables the use of widening multi
On 23/06/11 15:39, Andrew Stubbs wrote:
This patch has two effects:
1. It permits the use of widening multiply instructions that widen by
more than one mode. E.g. HImode -> DImode.
2. It enables the use of widening multiply instructions for (extended)
inputs of narrower mode than the instructio
This patch has two effects:
1. It permits the use of widening multiply instructions that widen by
more than one mode. E.g. HImode -> DImode.
2. It enables the use of widening multiply instructions for (extended)
inputs of narrower mode than the instruction takes. E.g. QImode ->
DImode where
11 matches
Mail list logo
