From: Borut R. <bor...@si...> - 2008-03-09 07:06:56
|
Dear sdcc developers, please consider the svn main branch as frozen, which means that only fixes for high severity bugs (after an agreement on this mailing list) and changes in the documentation can be committed. The SDCC 2.8.0 release schedule is published at http://sdcc.sourceforge.net/release_wiki/index.php?page=SDCC+2.8.0+Release. Borut |
From: Borut R. <bor...@si...> - 2008-03-09 07:15:51
|
The URL of the SDCC 2.8.0 Release page was wrong in my previous post. The correct one is: http://sdcc.wiki.sourceforge.net/SDCC+2.8.0+Release. But you already know it... Borut Borut Razem wrote: > Dear sdcc developers, > > please consider the svn main branch as frozen, which means that only fixes for high severity bugs (after an agreement on this mailing list) and changes in the documentation can be committed. > > The SDCC 2.8.0 release schedule is published at http://sdcc.sourceforge.net/release_wiki/index.php?page=SDCC+2.8.0+Release. > > Borut > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-devel > > > |
From: Larice R. <la...@vi...> - 2008-03-09 18:05:11
|
On Sun, 9 Mar 2008, Borut Razem wrote: > Dear sdcc developers, > > please consider the svn main branch as frozen, which means that only fixes for high severity bugs (after an agreement on this mailing list) and changes in the documentation can be committed. > > The SDCC 2.8.0 release schedule is published at http://sdcc.sourceforge.net/release_wiki/index.php?page=SDCC+2.8.0+Release. > > Borut May I suggest to apply the patch in http://sourceforge.net/tracker/index.php?func=detail&group_id=599&atid=100599&aid=1505811 thats an uggly bug, which was very easy to fix. Robert Larice |
From: Raphael N. <rn...@we...> - 2008-03-09 18:16:11
|
Hi, > May I suggest to apply the patch in > http://sourceforge.net/tracker/index.php?func=detail&group_id=599&atid=100599&aid=1505811 > > thats an ugly bug, which was very easy to fix. Although the report focuses on the PIC16 port, the bug itself is not port-specific and probably affects all ports. I'd support fixing this, but I am not familiar enough with the front-end to judge this one. Could one of the more involved developers review the patch and possibly apply it (with Borut's consent)? Thanks, Raphael |
From: Maarten B. <sou...@ds...> - 2008-03-09 22:12:18
|
Bug 1505811 is indeed nothing PIC specific and fails on all targets. The patch by Robert also seems to fix it. But I think it is too strict. IMO it should check if this sym is used to find the function it wants to call. I propose: case CALL: /* if local & not passed as parameter & not used to find the function then ok */ if (sym->level && !astHasSymbol (pbody->right, sym) && !astHasSymbol (pbody->left, sym)) { return TRUE; } return FALSE; Borut, what do you say? Shall I fix it or will it have to wait? Maarten > On Sun, 9 Mar 2008, Borut Razem wrote: > > > Dear sdcc developers, > > > > please consider the svn main branch as frozen, which means that only fixes for high severity bugs (after an agreement on this mailing list) and changes in the documentation can be committed. > > > > The SDCC 2.8.0 release schedule is published at http://sdcc.sourceforge.net/release_wiki/index.php?page=SDCC+2.8.0+Release. > > > > Borut > > May I suggest to apply the patch in > http://sourceforge.net/tracker/index.php?func=detail&group_id=599&atid=100599&aid=1505811 > > thats an uggly bug, which was very easy to fix. > > Robert Larice |
From: Borut R. <bor...@si...> - 2008-03-09 22:16:36
|
Maarten, I didn't look into details, but if you think that it is OK, I'd say let do it. Borut Maarten Brock wrote: > Bug 1505811 is indeed nothing PIC specific and fails on all targets. > The patch by Robert also seems to fix it. But I think it is too > strict. IMO it should check if this sym is used to find the function > it wants to call. I propose: > > case CALL: > /* if local & not passed as parameter & > not used to find the function then ok */ > if (sym->level && !astHasSymbol (pbody->right, sym) && > !astHasSymbol (pbody->left, sym)) > { > return TRUE; > } > return FALSE; > > Borut, what do you say? Shall I fix it or will it have to wait? > > Maarten > > >> On Sun, 9 Mar 2008, Borut Razem wrote: >> >> >>> Dear sdcc developers, >>> >>> please consider the svn main branch as frozen, which means that only fixes for high severity bugs (after an agreement on this mailing list) and changes in the documentation can be committed. >>> >>> The SDCC 2.8.0 release schedule is published at http://sdcc.sourceforge.net/release_wiki/index.php?page=SDCC+2.8.0+Release. >>> >>> Borut >>> >> May I suggest to apply the patch in >> http://sourceforge.net/tracker/index.php?func=detail&group_id=599&atid=100599&aid=1505811 >> >> thats an uggly bug, which was very easy to fix. >> >> Robert Larice >> |
From: Maarten B. <sou...@ds...> - 2008-03-09 22:25:50
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"><head> <title></title> <meta http-equiv="content-type" content="text/html;charset=utf-8"/> <meta http-equiv="Content-Style-Type" content="text/css"/> </head> <body> <div align="left"> <font face="Courier New" size="2"> <span style=" font-size:10pt"> Let me first do some extensive testing. If it turns out OK I will commit then.</span></font> </div> <div align="left"> <font face="Courier New" size="2"> <span style=" font-size:10pt"> <br /> </span> </font> </div> <div align="left"> <font face="Courier New" size="2"> <span style=" font-size:10pt"> Maarten</span></font> </div> <div align="left"> <font face="Arial" color="#7f0000" size="2"> <span style=" font-size:10pt"> <br /> </span> </font> </div> <div align="left"> <font face="Arial" color="#7f0000" size="2"> <span style=" font-size:10pt"> > Maarten,</span></font> </div> <div align="left"> <font face="Arial" color="#7f0000" size="2"> <span style=" font-size:10pt"> > </span></font> </div> <div align="left"> <font face="Arial" color="#7f0000" size="2"> <span style=" font-size:10pt"> > I didn't look into details, but if you think that it is OK, I'd say let </span></font> </div> <div align="left"> <font face="Arial" color="#7f0000" size="2"> <span style=" font-size:10pt"> > do it.</span></font> </div> <div align="left"> <font face="Arial" color="#7f0000" size="2"> <span style=" font-size:10pt"> > </span></font> </div> <div align="left"> <font face="Arial" color="#7f0000" size="2"> <span style=" font-size:10pt"> > Borut</span></font> </div> <div align="left"> <font face="Arial" color="#7f0000" size="2"> <span style=" font-size:10pt"> > </span></font> </div> <div align="left"> <font face="Arial" color="#7f0000" size="2"> <span style=" font-size:10pt"> > </span></font> </div> <div align="left"> <font face="Arial" color="#7f0000" size="2"> <span style=" font-size:10pt"> > Maarten Brock wrote:</span></font> </div> <div align="left"> <font face="Arial" color="#7f0000" size="2"> <span style=" font-size:10pt"> > > Bug 1505811 is indeed nothing PIC specific and fails on all targets. </span></font> </div> <div align="left"> <font face="Arial" color="#7f0000" size="2"> <span style=" font-size:10pt"> > > The patch by Robert also seems to fix it. But I think it is too </span></font> </div> <div align="left"> <font face="Arial" color="#7f0000" size="2"> <span style=" font-size:10pt"> > > strict. IMO it should check if this sym is used to find the function </span></font> </div> <div align="left"> <font face="Arial" color="#7f0000" size="2"> <span style=" font-size:10pt"> > > it wants to call. I propose:</span></font> </div> <div align="left"> <font face="Arial" color="#7f0000" size="2"> <span style=" font-size:10pt"> > ></span></font> </div> <div align="left"> <font face="Arial" color="#7f0000" size="2"> <span style=" font-size:10pt"> > >     case CALL:</span></font> </div> <div align="left"> <font face="Arial" color="#7f0000" size="2"> <span style=" font-size:10pt"> > >         /* if local & not passed as parameter &</span></font> </div> <div align="left"> <font face="Arial" color="#7f0000" size="2"> <span style=" font-size:10pt"> > >            not used to find the function then ok */</span></font> </div> <div align="left"> <font face="Arial" color="#7f0000" size="2"> <span style=" font-size:10pt"> > >         if (sym->level && !astHasSymbol (pbody->right, sym) &&</span></font> </div> <div align="left"> <font face="Arial" color="#7f0000" size="2"> <span style=" font-size:10pt"> > >             !astHasSymbol (pbody->left, sym))</span></font> </div> <div align="left"> <font face="Arial" color="#7f0000" size="2"> <span style=" font-size:10pt"> > >           {</span></font> </div> <div align="left"> <font face="Arial" color="#7f0000" size="2"> <span style=" font-size:10pt"> > >             return TRUE;</span></font> </div> <div align="left"> <font face="Arial" color="#7f0000" size="2"> <span style=" font-size:10pt"> > >           }</span></font> </div> <div align="left"> <font face="Arial" color="#7f0000" size="2"> <span style=" font-size:10pt"> > >       return FALSE;</span></font> </div> <div align="left"> <font face="Arial" color="#7f0000" size="2"> <span style=" font-size:10pt"> > ></span></font> </div> <div align="left"> <font face="Arial" color="#7f0000" size="2"> <span style=" font-size:10pt"> > > Borut, what do you say? Shall I fix it or will it have to wait?</span></font> </div> <div align="left"> <font face="Arial" color="#7f0000" size="2"> <span style=" font-size:10pt"> > ></span></font> </div> <div align="left"> <font face="Arial" color="#7f0000" size="2"> <span style=" font-size:10pt"> > > Maarten</span></font> </div> <div align="left"> <font face="Arial" color="#7f0000" size="2"> <span style=" font-size:10pt"> > ></span></font> </div> <div align="left"> <font face="Arial" color="#7f0000" size="2"> <span style=" font-size:10pt"> > >   </span></font> </div> <div align="left"> <font face="Arial" color="#7f0000" size="2"> <span style=" font-size:10pt"> > >> On Sun, 9 Mar 2008, Borut Razem wrote:</span></font> </div> <div align="left"> <font face="Arial" color="#7f0000" size="2"> <span style=" font-size:10pt"> > >></span></font> </div> <div align="left"> <font face="Arial" color="#7f0000" size="2"> <span style=" font-size:10pt"> > >>     </span></font> </div> <div align="left"> <font face="Arial" color="#7f0000" size="2"> <span style=" font-size:10pt"> > >>> Dear sdcc developers,</span></font> </div> <div align="left"> <font face="Arial" color="#7f0000" size="2"> <span style=" font-size:10pt"> > >>></span></font> </div> <div align="left"> <font face="Arial" color="#7f0000" size="2"> <span style=" font-size:10pt"> > >>> please consider the svn main branch as frozen, which means that only fixes for high severity bugs (after an agreement on this mailing list) and changes in the documentation can be committed.</span></font> </div> <div align="left"> <font face="Arial" color="#7f0000" size="2"> <span style=" font-size:10pt"> > >>></span></font> </div> <div align="left"> <font face="Arial" color="#7f0000" size="2"> <span style=" font-size:10pt"> > >>> The SDCC 2.8.0 release schedule is published at http://sdcc.sourceforge.net/release_wiki/index.php?page=SDCC+2.8.0+Release.</span></font> </div> <div align="left"> <font face="Arial" color="#7f0000" size="2"> <span style=" font-size:10pt"> > >>></span></font> </div> <div align="left"> <font face="Arial" color="#7f0000" size="2"> <span style=" font-size:10pt"> > >>> Borut</span></font> </div> <div align="left"> <font face="Arial" color="#7f0000" size="2"> <span style=" font-size:10pt"> > >>>       </span></font> </div> <div align="left"> <font face="Arial" color="#7f0000" size="2"> <span style=" font-size:10pt"> > >> May I suggest to apply the patch in</span></font> </div> <div align="left"> <font face="Arial" color="#7f0000" size="2"> <span style=" font-size:10pt"> > >>   http://sourceforge.net/tracker/index.php?func=detail&group_id=599&atid=100599&aid=1505811</span></font> </div> <div align="left"> <font face="Arial" color="#7f0000" size="2"> <span style=" font-size:10pt"> > >></span></font> </div> <div align="left"> <font face="Arial" color="#7f0000" size="2"> <span style=" font-size:10pt"> > >> thats an uggly bug, which was very easy to fix.</span></font> </div> <div align="left"> <font face="Arial" color="#7f0000" size="2"> <span style=" font-size:10pt"> > >></span></font> </div> <div align="left"> <font face="Arial" color="#7f0000" size="2"> <span style=" font-size:10pt"> > >> Robert Larice</span></font> </div> <div align="left"> </div> </body> </html> |
From: Larice R. <la...@vi...> - 2008-03-10 07:50:15
|
On Sun, 9 Mar 2008, Maarten Brock wrote: > Bug 1505811 is indeed nothing PIC specific and fails on all targets. > The patch by Robert also seems to fix it. But I think it is too > strict. IMO it should check if this sym is used to find the function > it wants to call. I propose: > > case CALL: > /* if local & not passed as parameter & > not used to find the function then ok */ > if (sym->level && !astHasSymbol (pbody->right, sym) && > !astHasSymbol (pbody->left, sym)) > { > return TRUE; > } > return FALSE; > Hello Maarten, are you sure checking for the symbol not occuring in pbody->left is enough ? Its a long time ago, i think i was nervous back then thinking about the possibility of something like for(local_i = ...) { another_local = local_i + 42; array[another_local](); } just checking for the left side of the CALL beeing a symbol is much easier to understand, safer, and propably would very seldom influence optimisation. Robert Larice |
From: Maarten B. <sou...@ds...> - 2008-03-10 11:19:31
|
Robert Thanks for the comment. But IMO 'another_local = local_i + 42;' should be caught by the '=' and the '+' cases in isConformingBody (and is in my preliminary tests). Maarten > On Sun, 9 Mar 2008, Maarten Brock wrote: > >> Bug 1505811 is indeed nothing PIC specific and fails on all targets. >> The patch by Robert also seems to fix it. But I think it is too >> strict. IMO it should check if this sym is used to find the function >> it wants to call. I propose: >> >> case CALL: >> /* if local & not passed as parameter & >> not used to find the function then ok */ >> if (sym->level && !astHasSymbol (pbody->right, sym) && >> !astHasSymbol (pbody->left, sym)) >> { >> return TRUE; >> } >> return FALSE; >> > > Hello Maarten, > > are you sure checking for the symbol not occuring in pbody->left is > enough ? Its a long time ago, i think i was nervous back then > thinking about the possibility of something like > for(local_i = ...) { > another_local = local_i + 42; > array[another_local](); > } > just checking for the left side of the CALL beeing a symbol > is much easier to understand, safer, and propably would > very seldom influence optimisation. > > Robert Larice |
From: Larice R. <la...@vi...> - 2008-03-11 20:59:47
|
On Mon, 10 Mar 2008, Maarten Brock wrote: > Robert > > Thanks for the comment. But IMO 'another_local = local_i + 42;' should be > caught by the '=' and the '+' cases in isConformingBody (and is in my > preliminary tests). > > Maarten Thank you Maarten for fixing that one. I've found another bug report #1717943 wrong optimized flow perhaps you have time to have look on that one too ? I think it is of somewhat similiar complexity. This bug has to to do with moving "loop invariants" to the outside of a loop. If there is something like while(...) { global = expr ....; if(...) fun_call(); } sdcc eronously considers the global = assignment to be a candidate for such movement to the outside of the loop. But of course if fun_call() somehow modfies that global this will lead to incorrect code. Robert Larice |
From: Maarten B. <sou...@ds...> - 2008-03-11 22:57:39
|
Robert, We are at a code freeze. The bug you mention was on my (rather long) shortlist of which I fixed some and others I knew would have to wait until after the release. I care more about a timely release than a total bugfree one. The longer we wait, the longer the users (or distribution maintainers) who rely on a released version have to wait for all the other bug fixes. So unless the release manager asks me to try and fix it before the release, I will not. I hope you understand. Maarten > On Mon, 10 Mar 2008, Maarten Brock wrote: > > > Robert > > > > Thanks for the comment. But IMO 'another_local = local_i + 42;' should be > > caught by the '=' and the '+' cases in isConformingBody (and is in my > > preliminary tests). > > > > Maarten > > Thank you Maarten for fixing that one. > > I've found another bug report > #1717943 wrong optimized flow > perhaps you have time to have look on that one too ? > I think it is of somewhat similiar complexity. > > This bug has to to do with > moving "loop invariants" to the outside of a loop. > > If there is something like > > while(...) { > global = expr ....; > if(...) > fun_call(); > } > > sdcc eronously considers the > global = > assignment to be a candidate for such movement to the outside of the loop. > But of course if fun_call() somehow modfies that global > this will lead to incorrect code. > > Robert Larice |
From: Larice R. <la...@vi...> - 2008-03-12 07:47:49
|
On Tue, 11 Mar 2008, Maarten Brock wrote: > Robert, > > We are at a code freeze. The bug you mention was on my > (rather long) shortlist of which I fixed some and others > I knew would have to wait until after the release. > > I care more about a timely release than a total bugfree > one. The longer we wait, the longer the users (or > distribution maintainers) who rely on a released version > have to wait for all the other bug fixes. > > So unless the release manager asks me to try and fix it > before the release, I will not. I hope you understand. > > Maarten of course i understand, especially if you have it on a list anyway. Robert Larice |
From: Maarten B. <sou...@ds...> - 2008-03-12 22:19:46
|
Borut, I have a question about the release wiki. On te tasks list two bugs are still open. Are they now officially postponed (if so please update the list) or is it still desired to work on these bugs to try and fix them before RC2? Maarten > Dear sdcc developers, > > please consider the svn main branch as frozen, which means that only fixes for high severity bugs (after an agreement on this mailing list) and changes in the documentation can be committed. > > The SDCC 2.8.0 release schedule is published at http://sdcc.sourceforge.net/release_wiki/index.php?page=SDCC+2.8.0+Release. > > Borut |
From: Maarten B. <sou...@ds...> - 2008-03-19 20:01:49
|
Dear fellow developers, After below announcement of a code freeze some have still commited bug fixes to the subversion repository without discussing them first on the developer list. Fortunately they were low risk and probably would have been blessed anyway but it undermines the task of the release manager. Please try to play by the rules during this exciting period of making a release. When RC2 is created I strongly recommend not to do any commit without asking for consent first, because it could result in another RC-period. Thanks, Maarten > Dear sdcc developers, > > please consider the svn main branch as frozen, which means that only > fixes for high severity bugs (after an agreement on this mailing list) > and changes in the documentation can be committed. > > The SDCC 2.8.0 release schedule is published at > http://sdcc.sourceforge.net/release_wiki/index.php?page=SDCC+2.8.0+Release. > > Borut |
From: Paul S. <pa...@pj...> - 2008-03-20 13:33:37
|
Opps, sorry. That was me. I hadn't followed all these messages carefully. That commit only effects the library function printf_fast_f, which is only on mcs51. Briefly, negative floating point numbers weren't being handled properly in a couple places. Again, I'm sorry. I should have been paying closer attention. -Paul |
From: Borut R. <bor...@si...> - 2008-03-23 16:59:41
|
SDCC 2.8.0 Release Candidate 2 source, doc and binary packages for x86 Linux, 32 bit Windows and universal Mac OS X are available at: http://sdcc.sourceforge.net/snapshots/sdcc-2.8.0-rc2 and http://sdcc.sourceforge.net/snap.php If you find a mistake, please send a mail to sdcc-devel mailing list sdc...@li.... I would appreciate any reports about a success or failure of running pre-compiled binary packages. Borut |
From: Borut R. <bor...@si...> - 2008-03-23 19:12:29
|
Dear sdcc developers, the sdcc RC2 is released. Thanks to anybody helped to bring it to the life. Please consider the svn main branch as DEEPLY FROZEN, which means NOTHING can be committed without the agreement between adcc developers and release manager. The SDCC 2.8.0 release schedule is published at http://sdcc.sourceforge.net/release_wiki/index.php?page=SDCC+2.8.0+Release. Borut Borut Razem wrote: > SDCC 2.8.0 Release Candidate 2 source, doc and binary packages for x86 Linux, 32 bit Windows and universal Mac OS X are available at: http://sdcc.sourceforge.net/snapshots/sdcc-2.8.0-rc2 and http://sdcc.sourceforge.net/snap.php > > If you find a mistake, please send a mail to sdcc-devel mailing list sdc...@li.... > > I would appreciate any reports about a success or failure of running pre-compiled binary packages. > > Borut > > |
From: Maarten B. <sou...@ds...> - 2008-03-23 21:23:24
|
Hello Borut, I wanted to bring you good news, but alas. I installed the W32 version on both XP and W98. XP looks ok, but on W98 the path is not set. It had RC1 on it and that was uninstalled first by the installer. Afterwards it requested a reboot and the SDCC-path was removed! I reran the RC2 installer several times and sometimes it asked to add the path, but never did it appear in autoexec.bat. Finally I reinstalled RC1 and this correctly added the path (but forgot to ask for reboot). Maarten > SDCC 2.8.0 Release Candidate 2 source, doc and binary packages for x86 > Linux, 32 bit Windows and universal Mac OS X are available at: > http://sdcc.sourceforge.net/snapshots/sdcc-2.8.0-rc2 and > http://sdcc.sourceforge.net/snap.php > > If you find a mistake, please send a mail to sdcc-devel mailing list > sdc...@li.... > > I would appreciate any reports about a success or failure of running > pre-compiled binary packages. > > Borut |
From: Borut R. <bor...@si...> - 2010-10-22 18:36:09
|
SDCC 3.0.0 Release Candidate 2 source, doc and binary packages for x86 Linux, 32 bit Windows and universal Mac OS X are available at: http://sourceforge.net/projects/sdcc/files/snapshot_builds/sdcc-3.0.0-rc2 If you find a mistake, please send a mail to sdcc-devel mailing list sdc...@li.... I would appreciate any reports about a success or failure of running pre-compiled binary packages. Borut |
From: Borut R. <bor...@gm...> - 2011-11-06 14:16:45
|
Dear sdcc developers, the sdcc RC1 is released. Thanks to anybody helped to bring it to the life. Please consider the svn main branch as frozen, which means that only fixes for high severity bugs (after an agreement on this mailing list) and changes in the documentation can be committed. The SDCC 3.1.0 release schedule is published at http://sourceforge.net/apps/trac/sdcc/wiki/SDCC%203.1.0%20Release. Borut |
From: Borut R. <bor...@gm...> - 2011-11-18 21:37:16
|
SDCC 3.1.0 Release Candidate 2 source, doc and binary packages for x86 Linux, 32 bit Windows and universal Mac OS X are available at: http://sourceforge.net/projects/sdcc/files/snapshot_builds/sdcc-3.1.0-rc2 If you find a mistake, please send a mail to sdcc-devel mailing list sdc...@li.... I would appreciate any reports about a success or failure of running pre-compiled binary packages. Borut |
From: Borut R. <bor...@gm...> - 2011-11-22 21:19:45
|
SDCC 3.1.0 Release Candidate 3 source, doc and binary packages for x86 Linux, 32 bit Windows and universal Mac OS X are available at: http://sourceforge.net/projects/sdcc/files/snapshot_builds/sdcc-3.1.0-rc3 If you find a mistake, please send a mail to sdcc-devel mailing list sdc...@li.... I would appreciate any reports about a success or failure of running pre-compiled binary packages. Borut |
From: Borut R. <bor...@gm...> - 2011-11-18 21:41:33
|
Dear sdcc developers, the sdcc RC2 is released. Thanks to anybody helped to bring it to the life. Please consider the svn main branch as DEEPLY FROZEN, which means NOTHING can be committed without the agreement between sdcc developers and release manager. The SDCC 3.1.0 release schedule is published at http://sourceforge.net/apps/trac/sdcc/wiki/SDCC%203.1.0%20Release <https://sourceforge.net/apps/trac/sdcc/wiki/SDCC%203.1.0%20Release>. Borut |
From: Borut R. <bor...@gm...> - 2011-11-22 21:33:31
|
Dear sdcc developers, the sdcc RC3 is released. This release candidate 3 was not originally planned, but we (Maarten, Philipp and me) decided to make it due to the fix of bug #3440327: wrong code for pointer to functions in a loop, z80 port. The final sdcc 3.1.0 release is still planned for the next week end. Please consider the svn main branch as DEEPLY FROZEN, which means NOTHING can be committed without the agreement between sdcc developers and release manager. The SDCC 3.1.0 release schedule is published at http://sourceforge.net/apps/trac/sdcc/wiki/SDCC%203.1.0%20Release <https://sourceforge.net/apps/trac/sdcc/wiki/SDCC%203.1.0%20Release>. Borut |
From: Borut R. <bor...@gm...> - 2012-06-17 15:07:33
|
SDCC 3.2.0 Release Candidate 1 source, doc and binary packages for x86 Linux, 32 bit Windows and universal Mac OS X are available at: http://sourceforge.net/projects/sdcc/files/snapshot_builds/sdcc-3.2.0-rc1 If you find a mistake, please send a mail to sdcc-devel mailing list sdc...@li.... I would appreciate any reports about a success or failure of running pre-compiled binary packages. Borut |