bugAVR C Runtime Library - Bugs: bug #20778, strtod problems in ATmega2560

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #20778: strtod problems in ATmega2560

Submitter:  max <guran>
Submitted:  Tue 14 Aug 2007 09:20:41 AM UTC
   
 
Category:  Library Severity:  4 - Important
Priority:  9 - Immediate Item Group:  libc code
Status:  Works For Me Assigned to:  None
Percent Complete:  0% Open/Closed:  Closed
Release:  Unknown Fixed Release:  None

Wed 09 Jun 2010 08:17:54 AM UTC, comment #3: 

No feedback within 2 years, assumed to be fixed.

Joerg Wunsch <joerg_wunsch>
Group administrator
Tue 18 Mar 2008 11:03:51 PM UTC, comment #2: 

Now with 1.6.1 out, this needs to be retested.

Eric Weddington <arcanum>
Group administrator
Tue 18 Dec 2007 09:35:53 PM UTC, comment #1: 

This only affects the 1.4 branch anymore, because the code in
HEAD has been rewritten completely, and is now written in C.

More analysis: it's not quite clear to me what the correct
course to take is.  The code in question pops three bytes
from the stack, and then jumps to __prologue_saves after
massaging the required arguments.  Obviously, popping three
bytes is the correct action, but then, how can it be right
to discard the third byte?

I think the best remedy would be to replace the call prologues
by standard prologues.  After all, anyone using floating point
numbers is likely to not run this on a 1 or 2 KiB device so
adding another few bytes of code wouldn't really hurt here.

As this is a 1.4 only thing, I'm deferring this by now due to
the amount of testing required to ensure nothing gets broken
by this.

Joerg Wunsch <joerg_wunsch>
Group administrator
Tue 14 Aug 2007 09:20:41 AM UTC, original submission:  

The strtod() -function alters EIND at the end and calls
" __prologue_saves " in ATmega2560.
After that, any function call that uses EICALL fails probably because EIND was set to the wrong value in strtod().

It may depend on code size whether EICALL succeed or not. This seems to happen when codesize pass around 50% of available flash memory in ATmega2560 because everything is working below this limit.

max <guran>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by joerg_wunsch (Posted a comment)
  • -email is unavailable- added by arcanum (Updated the item)
  • -email is unavailable- added by guran (Submitted the item)
  •  

    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2010-06-09 joerg_wunsch StatusNone Works For Me
        Open/ClosedOpen Closed
    2009-02-28 arcanum Severity5 - Blocker 4 - Important
        ReleaseNone Unknown
    2007-09-12 arcanum Priority7 - High 9 - Immediate
    2007-08-14 arcanum Severity3 - Normal 5 - Blocker
        Priority5 - Normal 7 - High

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code