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

 
 

bug #20778: strtod problems in ATmega2560

Submitted by:  max <guran>
Submitted on:  Tue 14 Aug 2007 09:20:41 AM UTC  
 
Category: LibrarySeverity: 4 - Important
Priority: 9 - ImmediateItem Group: libc code
Status: Works For MePercent Complete: 0%
Assigned to: NoneOpen/Closed: Closed
Release: UnknownFixed Release: None

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

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

No feedback within 2 years, assumed to be fixed.

Joerg Wunsch <joerg_wunsch>
Project 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>
Project 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>
Project 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.)

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 7 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Wed 09 Jun 2010 08:17:54 AM UTCjoerg_wunschStatusNone=>Works For Me
      Open/ClosedOpen=>Closed
    Sat 28 Feb 2009 04:38:40 PM UTCarcanumSeverity5 - Blocker=>4 - Important
      ReleaseNone=>Unknown
    Wed 12 Sep 2007 08:45:01 PM UTCarcanumPriority7 - High=>9 - Immediate
    Tue 14 Aug 2007 05:11:41 PM UTCarcanumSeverity3 - Normal=>5 - Blocker
      Priority5 - Normal=>7 - High

    Back to the top


    Powered by Savane 3.1-cleanup1