Daniele Nicolodi wrote:
> On 12/08/11 10:18, Daniele Nicolodi wrote:
>> On 12/08/11 01:18, Gilles Chanteperdrix wrote:
>>> The following patch seems to do the trick. It makes the assumption that
>>> when compiling with -fomit-frame-pointer, we have one more register, so
>>> the "R" constraint will
On 12/08/11 10:18, Daniele Nicolodi wrote:
> On 12/08/11 01:18, Gilles Chanteperdrix wrote:
>> The following patch seems to do the trick. It makes the assumption that
>> when compiling with -fomit-frame-pointer, we have one more register, so
>> the "R" constraint will always be able to avoid choos
Daniele Nicolodi wrote:
> On 12/08/11 01:18, Gilles Chanteperdrix wrote:
>> The following patch seems to do the trick. It makes the assumption that
>> when compiling with -fomit-frame-pointer, we have one more register, so
>> the "R" constraint will always be able to avoid choosing eax, and eax
>>
Hi,
On 08/12/2011 01:18 AM, Gilles Chanteperdrix wrote:
> The following patch seems to do the trick. It makes the assumption that
> when compiling with -fomit-frame-pointer, we have one more register, so
> the "R" constraint will always be able to avoid choosing eax, and eax
> will be free for t
On 12/08/11 01:18, Gilles Chanteperdrix wrote:
> The following patch seems to do the trick. It makes the assumption that
> when compiling with -fomit-frame-pointer, we have one more register, so
> the "R" constraint will always be able to avoid choosing eax, and eax
> will be free for the muxcode