2012/1/14 Denis Chertykov :
> 2012/1/13 Georg-Johann Lay :
>> Denis Chertykov wrote:
>>
>>> Committed
>>>
>>> Denis
>>
>>
>> Consider code prom PR51374
>>
>> void __vector_18 (void)
>> {
>> extern char slot;
>> unsigned char status = (*(volatile unsigned char*) 0x2B);
>> unsigned char data
2012/1/13 Georg-Johann Lay :
> Denis Chertykov wrote:
>
>> Committed
>>
>> Denis
>
>
> Consider code prom PR51374
>
> void __vector_18 (void)
> {
> extern char slot;
> unsigned char status = (*(volatile unsigned char*) 0x2B);
> unsigned char data = (*(volatile unsigned char*) 0x2C);
>
>
Denis Chertykov wrote:
> Committed
>
> Denis
Consider code prom PR51374
void __vector_18 (void)
{
extern char slot;
unsigned char status = (*(volatile unsigned char*) 0x2B);
unsigned char data = (*(volatile unsigned char*) 0x2C);
if (status & 0x10)
slot = 0;
}
the cod
2012/1/13 Georg-Johann Lay :
> Denis Chertykov wrote:
>> Georg-Johann Lay:
>>> Denis Chertykov schrieb:
>>>
>>> 2) Can we remove from avr.c:avr_option_override() the following:
>>>
>>> if (avr_strict_X)
>>> flag_caller_saves = 0;
>>>
>>> that hacked around similar spill fails?
>>>
>>> 3) As
Denis Chertykov wrote:
> Georg-Johann Lay:
>> Denis Chertykov schrieb:
>>
>> 2) Can we remove from avr.c:avr_option_override() the following:
>>
>> if (avr_strict_X)
>> flag_caller_saves = 0;
>>
>> that hacked around similar spill fails?
>>
>> 3) As PR50775 is fixed: Would it make sense to
2012/1/13 Georg-Johann Lay :
> Denis Chertykov schrieb:
>
>> Committed
>>
>> Denis
>
>
> Some questions regarding the fix:
>
> 1) You know if PR42204 is still relevant and can be closed?
> Or is it not related to PR50925?
The PR42204 is a duplicate of PR50925 or vice versa.
But, I'm not sure tha
Denis Chertykov schrieb:
Committed
Denis
Some questions regarding the fix:
1) You know if PR42204 is still relevant and can be closed?
Or is it not related to PR50925?
2) Can we remove from avr.c:avr_option_override() the following:
if (avr_strict_X)
flag_caller_saves = 0;
t
2012/1/9 Denis Chertykov :
> Hi Georg.
>
> I have found that conversion AVR port to using hard_frame_pointer have
> resolved PR 50925 .
> I have tested the patch without regressions, but I'm worry about it.
> Can you test it with your testsuite for regressions ?
> May be you have your own special d
Denis Chertykov wrote:
> Hi Georg.
>
> I have found that conversion AVR port to using hard_frame_pointer have
> resolved PR 50925 .
> I have tested the patch without regressions, but I'm worry about it.
> Can you test it with your testsuite for regressions ?
> May be you have your own special diff
Denis Chertykov wrote:
> Hi Georg.
>
> I have found that conversion AVR port to using hard_frame_pointer have
> resolved PR 50925 .
> I have tested the patch without regressions, but I'm worry about it.
> Can you test it with your testsuite for regressions ?
> May be you have your own special diff
Hi Georg.
I have found that conversion AVR port to using hard_frame_pointer have
resolved PR 50925 .
I have tested the patch without regressions, but I'm worry about it.
Can you test it with your testsuite for regressions ?
May be you have your own special difficult tests (special for addressing)
11 matches
Mail list logo