2012/1/14 Denis Chertykov cherty...@gmail.com:
2012/1/13 Georg-Johann Lay a...@gjlay.de:
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
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 turn on
2012/1/13 Georg-Johann Lay a...@gjlay.de:
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:
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 code
2012/1/13 Georg-Johann Lay a...@gjlay.de:
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
2012/1/9 Denis Chertykov cherty...@gmail.com:
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
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;
2012/1/13 Georg-Johann Lay a...@gjlay.de:
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
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 difficult
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)
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 difficult
11 matches
Mail list logo