From: Borut R. <bor...@si...> - 2007-01-02 12:42:16
|
Dear sdcc developers, I wish you a happy, healthy and successful 2007. I think that his is the right opportunity to start thinking about the new SDCC 2.7.0 release. My wish is to make a release at the end of 1^st quarter of 2007 (end of march). Probably I'm too optimistic, but let give a try... We already have a list of new features, added since the 2.6.0 release (see http://sdcc.sourceforge.net/release_wiki/index.php?page=SDCC+2.7.0+Release). Probably some new features are still not added to the list: Bernhard's “excessive push/pop between function calls“, probably Erik, Maarten and Raphael have something to add too? But there are still some open tasks on the “SDCC 2.7.0 Tasks” list. I know that Erik is working on integration of 'inline' keyword into the grammar. What about “SLOC Overlay Option”? Quite some time ago (tomorrow will be 2 months ;-) Mark Swayne invited you to give your vote for the new sdcc library license, but many of you still haven't done it. (see http://sdcc.sourceforge.net/release_wiki/index.php?page=Library+License+Selection). Mark, I think is time to start sending personal mails to developers. Will you take care? And now a SDCC 2.6.0 leftover: “fix pic16 regression test bugs“. Raphael and other pic16 specialists, can you give us your point of view about the issue? It is doable for 2.7.0? How can other developer help you? Borut |
From: Borut R. <bor...@si...> - 2007-01-02 14:11:19
|
Dear sdcc developers, I wish you a happy, healthy and successful 2007. I think that his is the right opportunity to start thinking about the new SDCC 2.7.0 release. My wish is to make a release at the end of 1st quarter of 2007 (end of march). Probably I'm too optimistic, but let give a try... We already have a list of new features, added since the 2.6.0 release (see http://sdcc.sourceforge.net/release_wiki/index.php?page=SDCC+2.7.0+Release). Probably some new features are still not added to the list: Bernhard's "excessive push/pop between function calls", probably Erik, Maarten and Raphael have something to add too? But there are still some open tasks on the "SDCC 2.7.0 Tasks" list. I know that Erik is working on integration of 'inline' keyword into the grammar. What about "SLOC Overlay Option"? Quite some time ago (tomorrow will be 2 months ;-) Mark Swayne invited you to give your vote for the new sdcc library license, but many of you still haven't done it. (see http://sdcc.sourceforge.net/release_wiki/index.php?page=Library+License+Selection). Mark, I think is time to start sending personal mails to developers. Will you take care? And now a SDCC 2.6.0 leftover: "fix pic16 regression test bugs". Raphael and other pic16 specialists, can you give us your point of view about the issue? It is doable for 2.7.0? How can other developer help you? Borut |
From: Borut R. <bor...@si...> - 2007-03-31 20:22:52
|
Hi sdcc developers, today is the last day of march, so we just missed my sdcc 2.7.0 release plan ;-) Many things in SDCC has been changed, many bugs fixed, but the items on the SDCC Release Wiki page (http://sdcc.sourceforge.net/release_wiki/index.php?page=SDCC+2.7.0+Release) are still opened. "Fix pic16 regression test bugs" is probably out of reach, "change the sdcc library license" probably too: we are waiting for at least 9 votes. Today I sent a mail to Sandeep. I hope he will replay... Mark, are you still around? What about "SLOC Overlay Option"? Erik committed "inline function". Is it stable? If not, we can disable it for the release in the way that the "inline" keyword is noop. We would need some regression tests to cover it... There is also some discussion going ob between Jan Waclawek and Maarten about the documentation. This could be also a candidate for the release? There is also [1505013] Inline assembler won't work with C99 (https://sourceforge.net/tracker/?func=detail&atid=350599&aid=1505013&group_id=599). Is the real solution to add an underscore to each _asm and _endasm in the library? Maarten? And an other one: [1493816] option --no-gen-comments (https://sourceforge.net/tracker/?func=detail&atid=350599&aid=1493816&group_id=599) discussed between Frieder, Maarten and me. Maarten, would be the "all or nothing" approach acceptable? Frieder, do you have time and will to implement whatever the final decision will be? Impatiently waiting for your replies, Borut Borut Razem wrote: > Dear sdcc developers, > > I wish you a happy, healthy and successful 2007. > > I think that his is the right opportunity to start thinking about the > new SDCC 2.7.0 release. > > My wish is to make a release at the end of 1st quarter of 2007 (end of > march). Probably I'm too optimistic, but let give a try... > > We already have a list of new features, added since the 2.6.0 release > (see > http://sdcc.sourceforge.net/release_wiki/index.php?page=SDCC+2.7.0+Release). > Probably some new features are still not added to the list: Bernhard's > "excessive push/pop between function calls", probably Erik, Maarten and > Raphael have something to add too? > > But there are still some open tasks on the "SDCC 2.7.0 Tasks" list. I > know that Erik is working on integration of 'inline' keyword into the > grammar. What about "SLOC Overlay Option"? > > Quite some time ago (tomorrow will be 2 months ;-) Mark Swayne invited > you to give your vote for the new sdcc library license, but many of you > still haven't done it. (see > http://sdcc.sourceforge.net/release_wiki/index.php?page=Library+License+Selection). > Mark, I think is time to start sending personal mails to developers. > Will you take care? > > And now a SDCC 2.6.0 leftover: "fix pic16 regression test bugs". Raphael > and other pic16 specialists, can you give us your point of view about > the issue? It is doable for 2.7.0? How can other developer help you? > > Borut > |
From: Borut R. <bor...@si...> - 2007-03-31 20:56:26
|
I created the "SDCC 2.7.0 Release Plan" page on SDCC Release Wiki: http://sdcc.sourceforge.net/release_wiki/index.php?page=SDCC+2.7.0+Release+Plan Borut Borut Razem wrote: > Hi sdcc developers, > > today is the last day of march, so we just missed my sdcc 2.7.0 release > plan ;-) > > Many things in SDCC has been changed, many bugs fixed, but the items on > the SDCC Release Wiki page > (http://sdcc.sourceforge.net/release_wiki/index.php?page=SDCC+2.7.0+Release) > are still opened. > > "Fix pic16 regression test bugs" is probably out of reach, "change the > sdcc library license" probably too: we are waiting for at least 9 votes. > Today I sent a mail to Sandeep. I hope he will replay... Mark, are you > still around? > > What about "SLOC Overlay Option"? > > Erik committed "inline function". Is it stable? If not, we can disable > it for the release in the way that the "inline" keyword is noop. We > would need some regression tests to cover it... > > There is also some discussion going ob between Jan Waclawek and Maarten > about the documentation. This could be also a candidate for the release? > > There is also [1505013] Inline assembler won't work with C99 > (https://sourceforge.net/tracker/?func=detail&atid=350599&aid=1505013&group_id=599). > Is the real solution to add an underscore to each _asm and _endasm in > the library? Maarten? > > And an other one: [1493816] option --no-gen-comments > (https://sourceforge.net/tracker/?func=detail&atid=350599&aid=1493816&group_id=599) > discussed between Frieder, Maarten and me. Maarten, would be the "all or > nothing" approach acceptable? Frieder, do you have time and will to > implement whatever the final decision will be? > > > Impatiently waiting for your replies, > Borut > > |
From: Borut R. <bor...@si...> - 2007-04-16 18:12:08
|
Nobody reacted on my mail, so I don't know if - you don't agree to make the release or - you are too busy to reply or - I make too much noise and you are ignoring me or - ... Please at least let me know if you are still alive or just tell me that I'm a moron and I'll quit ;-) Borut Borut Razem wrote: > Hi sdcc developers, > > today is the last day of march, so we just missed my sdcc 2.7.0 release > plan ;-) > > Many things in SDCC has been changed, many bugs fixed, but the items on > the SDCC Release Wiki page > (http://sdcc.sourceforge.net/release_wiki/index.php?page=SDCC+2.7.0+Release) > are still opened. > > "Fix pic16 regression test bugs" is probably out of reach, "change the > sdcc library license" probably too: we are waiting for at least 9 votes. > Today I sent a mail to Sandeep. I hope he will replay... Mark, are you > still around? > > What about "SLOC Overlay Option"? > > Erik committed "inline function". Is it stable? If not, we can disable > it for the release in the way that the "inline" keyword is noop. We > would need some regression tests to cover it... > > There is also some discussion going ob between Jan Waclawek and Maarten > about the documentation. This could be also a candidate for the release? > > There is also [1505013] Inline assembler won't work with C99 > (https://sourceforge.net/tracker/?func=detail&atid=350599&aid=1505013&group_id=599). > Is the real solution to add an underscore to each _asm and _endasm in > the library? Maarten? > > And an other one: [1493816] option --no-gen-comments > (https://sourceforge.net/tracker/?func=detail&atid=350599&aid=1493816&group_id=599) > discussed between Frieder, Maarten and me. Maarten, would be the "all or > nothing" approach acceptable? Frieder, do you have time and will to > implement whatever the final decision will be? > > > Impatiently waiting for your replies, > Borut > > |
From: Frieder F. <fri...@we...> - 2007-04-17 16:57:45
|
Hello Borut, sorry for taking such a long time before the response! It was a combination of being busy and me being too oblivious (with some emphasis on the later one). Please whatever I do (or whatever I do not do) continue!) As to the specific question: >> And an other one: [1493816] option --no-gen-comments >> (https://sourceforge.net/tracker/?func=detail&atid=350599&aid=1493816&group_id=599) >> discussed between Frieder, Maarten and me. Maarten, would be the "all or >> nothing" approach acceptable? Frieder, do you have time and will to >> implement whatever the final decision will be? Like Maarten I'd be fine with both outcomes. As a first step we could remove --no-gen-comments from the manual so Maarten/You/Me can go either direction. Greetings, Frieder |
From: Maarten B. <sou...@ds...> - 2007-04-16 21:54:31
|
Borut, My apologies, I forgot. I do agree we should get ready for a new release. On my mind was to fix at least the bug about wrong pushing of the virtual bits register. This has been done, but after that I seem to have introduced a new one. If I cannot fix it before (due to lack of time or comprehension) I think it's best to revert back to less optimized code. I would very much like to see the unified library license in the next version. It seems doable. 1505013 is covered. I adapted all library code and the documentation has been updated to compile without --std- sdccXX. Is it maybe an idea to deprecate _asm/_endasm/_naked and all those other single underscore keywords? B.t.w. do we still have some dangling deprecations that could be removed by now? I do not have a problem with an "all or nothing" approach for --no-gen-comments. It's just that some source code currently uses D(x) and DD(x) for different levels of verboseness. Somebody probably introduced that for a reason. Is there anything more I forgot? Greets, Maarten > Nobody reacted on my mail, so I don't know if > - you don't agree to make the release or > - you are too busy to reply or > - I make too much noise and you are ignoring me or > - ... > > Please at least let me know if you are still alive or just tell me that > I'm a moron and I'll quit ;-) > > Borut > > > Borut Razem wrote: > > Hi sdcc developers, > > > > today is the last day of march, so we just missed my sdcc 2.7.0 release > > plan ;-) > > > > Many things in SDCC has been changed, many bugs fixed, but the items on > > the SDCC Release Wiki page > > (http://sdcc.sourceforge.net/release_wiki/index.php?page=SDCC+2.7.0+Release) > > are still opened. > > > > "Fix pic16 regression test bugs" is probably out of reach, "change the > > sdcc library license" probably too: we are waiting for at least 9 votes. > > Today I sent a mail to Sandeep. I hope he will replay... Mark, are you > > still around? > > > > What about "SLOC Overlay Option"? > > > > Erik committed "inline function". Is it stable? If not, we can disable > > it for the release in the way that the "inline" keyword is noop. We > > would need some regression tests to cover it... > > > > There is also some discussion going ob between Jan Waclawek and Maarten > > about the documentation. This could be also a candidate for the release? > > > > There is also [1505013] Inline assembler won't work with C99 > > (https://sourceforge.net/tracker/?func=detail&atid=350599&aid=1505013&group_id=599). > > Is the real solution to add an underscore to each _asm and _endasm in > > the library? Maarten? > > > > And an other one: [1493816] option --no-gen-comments > > (https://sourceforge.net/tracker/?func=detail&atid=350599&aid=1493816&group_id=599) > > discussed between Frieder, Maarten and me. Maarten, would be the "all or > > nothing" approach acceptable? Frieder, do you have time and will to > > implement whatever the final decision will be? > > > > > > Impatiently waiting for your replies, > > Borut > > > > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-devel > |
From: Borut R. <bor...@si...> - 2007-04-17 16:55:57
|
Maarten Brock wrote: > Borut, > > My apologies, I forgot. I do agree we should get ready > for a new release. > > I'm thinking to make the release at the end of May and to start prerelease (release candidates, ...) at the beginning of May. > On my mind was to fix at least the bug about wrong > pushing of the virtual bits register. This has been > done, but after that I seem to have introduced a new > one. If I cannot fix it before (due to lack of time or > comprehension) I think it's best to revert back to less > optimized code. > > See what you can do... > I would very much like to see the unified library > license in the next version. It seems doable. > > I doubt that we will manage to do it. We are still waiting for 4 votes, even after several invitations, personal mails... I'm also afraid that the list is not complete: there are at least some authors of the library code which are not sdcc developers, for example Jean-Louis Vern. This means that somebody should carefully review the copyright notices in all library sources, add missing authors to the list and ask them to vote... > 1505013 is covered. I adapted all library code and the > documentation has been updated to compile without --std- > sdccXX. Is it maybe an idea to deprecate > _asm/_endasm/_naked and all those other single > underscore keywords? We could add this to the documentation and mention that it will be removed in one of next releases. My question: are now libraries for all targets --std-c99 compatible? I saw that many targets are compiled without --std-c99 option defined in CFLAGS... > B.t.w. do we still have some > dangling deprecations that could be removed by now? > > Which one exactly? > I do not have a problem with an "all or nothing" > approach for --no-gen-comments. It's just that some > source code currently uses D(x) and DD(x) for different > levels of verboseness. Somebody probably introduced that > for a reason. > > I think that we shouldn't make things more complicated then needed. I'll take a look... > Is there anything more I forgot? > > Probably yes, and me too ;-) Thank you for the replay, Borut |
From: Borut R. <bor...@si...> - 2007-04-28 18:26:39
|
Hello, there still are some issues I wold like to clarify for the 2.7.0 release: > What about "SLOC Overlay Option"? > Bernhard, are you still around? I'm not sure, but I think you put this one on the list (correct me if I'm wrong! Maybe it was Maarten?). Can you let us know about the status of this item? > Erik committed "inline function". Is it stable? If not, we can disable > it for the release in the way that the "inline" keyword is noop. We > would need some regression tests to cover it... > Erik, what about this one? Maarten, I hope you'll fix the following one: [ 1707003 ] Problem after 4/8/2007 build If not, is better to reverse the fix for [ 1699455 ] bit returning function passes result in dpl which probably caused it? I hope that the following one will find the way into the release too: [ 1700823 ] Z80 peephole and code generation patch Philipp can you adapt the patch for gbz80? If not, we could apply your patch only for z80 peephole in the way that it doesn't affect gbz80 and leave the gbz80 peephole as it was. What do you think? Raphael, I saw that you fixed two pic and pic16 bugs and it seems that the snapshot builds are now stable. Is there something else you plan for the release? Is there something else that should go into the release? Please answer me ASAP. Borut |
From: Raphael N. <rn...@we...> - 2007-04-28 20:35:19
|
Hi Borut, > Raphael, I saw that you fixed two pic and pic16 bugs and it seems that > the snapshot builds are now stable. Is there something else you plan for > the release? Good to hear the build is clean again. I am working on emitting symbol declarations/initial values in a different way for pic16 (similar to the current pic14, which should afterwards be changed to the final pic16 approach...) to fix (a) incorrectly initialized unions and (b) missing global symbols (if not used in the defining file). As these changes will probably destabilize the port, I'd vote against including them into the release and rather include them soon afterwards. So, the short answer is `no'. Regards, Raphael |
From: Erik P. <epe...@iv...> - 2007-05-01 06:00:36
|
On Sat, 28 Apr 2007, Borut Razem wrote: > > Erik committed "inline function". Is it stable? If not, we can disable > > it for the release in the way that the "inline" keyword is noop. We > > would need some regression tests to cover it... > > > Erik, what about this one? The spring semester finishes for me on Wednesday, so I'll make it a priority to finish up the loose ends by this weekend. Erik |
From: Frieder F. <fri...@we...> - 2007-05-06 20:08:32
|
Hi Borut, Borut Razem schrieb: > Is there something else that should go into the release? This one is still be open "[ 1618050 ] badly optimized xdata pointer" http://sourceforge.net/tracker/index.php?func=detail&aid=1618050&group_id=599&atid=100599 (The calling function which uses a pointer does not notice that the called function changed the pointer.) Greetings, Frieder |
From: Borut R. <bor...@si...> - 2007-05-07 05:33:02
|
This seems to be a new show stopper to me :-( Is it a new one, introduced after 2.6.0 release? Borut Frieder Ferlemann wrote: > Hi Borut, > > Borut Razem schrieb: > >> Is there something else that should go into the release? >> > > This one is still be open "[ 1618050 ] badly optimized xdata pointer" > http://sourceforge.net/tracker/index.php?func=detail&aid=1618050&group_id=599&atid=100599 > > (The calling function which uses a pointer does not notice > that the called function changed the pointer.) > > Greetings, > > Frieder > |
From: Frieder F. <fri...@we...> - 2007-05-07 12:47:48
|
Hi Borut Borut Razem schrieb: > This seems to be a new show stopper to me :-( > Is it a new one, introduced after 2.6.0 release? No, sdcc 2.6.0 has it too. >> This one is still be open "[ 1618050 ] badly optimized xdata pointer" >> http://sourceforge.net/tracker/index.php?func=detail&aid=1618050&group_id=599&atid=100599 >> >> (The calling function which uses a pointer does not notice >> that the called function changed the pointer.) Greetings, Frieder |
From: Maarten B. <sou...@ds...> - 2007-05-07 13:40:20
|
Frieder, Why is it surprising this test fails? It generates a warning about integer overflow in expression. If you change 19200 to 19200L it's allright. #define OSCILLATOR 11059200 #define BAUD 19200L #define T1_RELOAD_VALUE -(2*OSCILLATOR)/(32*12*BAUD) static unsigned char T1=T1_RELOAD_VALUE; void testLongLit(void) { ASSERT(T1==0xfd); } Or did SDCC in the past detect that 12*19200 does not fit in an int and automatically upcast the result to a long? I don't know, as I was not using SDCC back in 2001 when this test was added. What was this regression test exactly supposed to check? What is the required and/or expected behaviour in this case? Maarten > The longlit test within the regression tests is not executed > and would fail. > > If the function within file sdcc/support/regression/tests/longlit.c > is changed to: > > > void > testLongLit(void) > { > ASSERT(T1==0xfd); > } > > > the test would be checked for. > But the slightly different one within the regression tests would not: > > > void test (void) { > ASSERT(T1==0xfd); > } > > > Greetings, > Frieder |
From: Maarten B. <sou...@ds...> - 2007-04-29 08:11:58
|
Borut and others, > there still are some issues I wold like to clarify for the 2.7.0 release: > > > What about "SLOC Overlay Option"? > > > Bernhard, are you still around? I'm not sure, but I think you put this > one on the list (correct me if I'm wrong! Maybe it was Maarten?). Can > you let us know about the status of this item? I did not put this on the list. > Maarten, I hope you'll fix the following one: > [ 1707003 ] Problem after 4/8/2007 build > If not, is better to reverse the fix for > [ 1699455 ] bit returning function passes result in dpl > which probably caused it? I'll fix it today. I jumped to the conclusion it was identical to bug 1699455 because of the date, but it wasn't. > I hope that the following one will find the way into the release too: > [ 1700823 ] Z80 peephole and code generation patch > Philipp can you adapt the patch for gbz80? If not, we could apply your > patch only for z80 peephole in the way that it doesn't affect gbz80 and > leave the gbz80 peephole as it was. What do you think? Does this still need a review as Philipp asked or have you done that Borut? I could help with that. > Is there something else that should go into the release? Not to my knowledge. Maarten |
From: Borut R. <bor...@si...> - 2007-04-29 11:20:56
|
Maarten Brock wrote: >> I hope that the following one will find the way into the release too: >> [ 1700823 ] Z80 peephole and code generation patch >> Philipp can you adapt the patch for gbz80? If not, we could apply your >> patch only for z80 peephole in the way that it doesn't affect gbz80 and >> leave the gbz80 peephole as it was. What do you think? >> > > Does this still need a review as Philipp asked or have > you done that Borut? I could help with that. > No, I haven't done the review. I based my assumption that the patch is OK on Lin Rongrong's report (see thread "[ sdcc-Patches-1700823 ] Z80 peephole and codegeneration patch"). I would really appreciate your review, since the proposed patch (probably) breaks the gbz80 peephole. Maybe you'll find an elegant solution... Borut |
From: Maarten B. <sou...@ds...> - 2007-05-05 18:46:30
|
Borut, > there still are some issues I wold like to clarify for the 2.7.0 release: > > > What about "SLOC Overlay Option"? > > > Bernhard, are you still around? I'm not sure, but I think you put this > one on the list (correct me if I'm wrong! Maybe it was Maarten?). Can > you let us know about the status of this item? I looked into this once more and allthough a nice idea I doubt we should try to implement this quickly to get it into the release. Unless of course someone (Bernhard?) has already done half the job. Otherwise I vote to postpone it till after the release. And so should the first two items on the wiki be postponed now IMHO. I think it is time to announce a feature freeze after Erik has blessed the 'inline' feature. Of course you (Borut) have the last word on this. Would it be possible for you to set a schedule already? Greets, Maarten |
From: Borut R. <bor...@si...> - 2007-05-05 20:41:19
|
Maarten Brock wrote: > Borut, > > >> there still are some issues I wold like to clarify for the 2.7.0 release: >> >> >>> What about "SLOC Overlay Option"? >>> >>> >> Bernhard, are you still around? I'm not sure, but I think you put this >> one on the list (correct me if I'm wrong! Maybe it was Maarten?). Can >> you let us know about the status of this item? >> > > I looked into this once more and allthough a nice idea I > doubt we should try to implement this quickly to get it > into the release. Unless of course someone (Bernhard?) > has already done half the job. > > Otherwise I vote to postpone it till after the release. > Even if it is already implemented it would be too risky to include it just before the release, so I marked it as postponed. > And so should the first two items on the wiki be > postponed now IMHO. > > Ditto. > I think it is time to announce a feature freeze after > Erik has blessed the 'inline' feature. > > This is also my opinion. Erik, when do you think you'll be ready? > Of course you (Borut) have the last word on this. Would > it be possible for you to set a schedule already? > It depends on when Erik will bless the 'inline' feature. My current plan is: Code freeze and RC1: 2007-05-11 (or after Erik's confirmation) RC2: 2007-05-21 Release: 2007-05-31 (if no show stoppers will be found) Borut |
From: Borut R. <bor...@si...> - 2007-05-06 08:12:02
|
Maarten, we have new regression test failures :-( . See http://sdcc.sourceforge.net/regression_test_results/ppc-apple-macosx/regression-test-ppc-apple-macosx-20070506-4787.log This is definitely a show stopper... I suppose that this is a consequence of new z80 peephole rules. If there is no other solution, we cold undo the changes. Borut |
From: Maarten B. <sou...@ds...> - 2007-05-06 09:25:08
|
Help! I don't understand a single bit about this. I just did: > svn update > make distclean > ./configure > edit device/lib/Makefile to add --fverbose-asm to CFLAGS so I can see which peephole rules are applied > make -s SILENT=1 > cd support/regression > make test-ucz80 And I get no failures! So I did: > svn status -q And all I get is: ! src/izt/Makefile M sim/ucsim/libtool So I have no dangling modifications here. What am I missing? What did I forget? Where did I mess up? All help is really welcome at this point. Maarten > How strange, I saw them here too but while hunting it > down it disappeared. So I suspected an old build. I > removed device/lib/build/z80/printf_large.* several > times and let it rebuild. > > Nevertheless I will look into it today. > > > Maarten, > > > > we have new regression test failures :-( . > > See > > http://sdcc.sourceforge.net/regression_test_results/ppc-apple-macosx/regression-test-ppc-apple-macosx-20070506-4787.log > > > > This is definitely a show stopper... > > I suppose that this is a consequence of new z80 peephole rules. If there > > is no other solution, we cold undo the changes. > > > > Borut > > > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by DB2 Express > > Download DB2 Express C - the FREE version of DB2 express and take > > control of your XML. No limits. Just data. Click to get it now. > > http://sourceforge.net/powerbar/db2/ > > _______________________________________________ > > sdcc-devel mailing list > > sdc...@li... > > https://lists.sourceforge.net/lists/listinfo/sdcc-devel > > > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-devel > |
From: Borut R. <bor...@si...> - 2007-05-06 11:04:37
|
Maarten Brock wrote: > Help! > > I don't understand a single bit about this. I just did: > > >> svn update >> make distclean >> ./configure >> edit device/lib/Makefile to add --fverbose-asm to CFLAGS so I can see which peephole rules are applied >> make -s SILENT=1 >> cd support/regression >> make test-ucz80 >> > > And I get no failures! So I did: > > I reproduced the problem on Linux using the same steps as you described. The only difference is that I use a different directory for build (using vpath functionality): ... mkdir sdcc.build cd sdcc.build ../sdcc/configure ... This way I can remove the complete sdcc.build directory and rebuild everything from scratch if such strange thing as you described happens. Borut |
From: Philipp K. K. <pk...@sp...> - 2007-05-06 11:16:44
|
Maarten Brock schrieb: > Help! > > I don't understand a single bit about this. I just did: > >> svn update >> make distclean >> ./configure >> edit device/lib/Makefile to add --fverbose-asm to CFLAGS so I can see which peephole rules are applied >> make -s SILENT=1 >> cd support/regression >> make test-ucz80 > > And I get no failures! So I did: > I did a clean checkout and could reproduce the bug. It seems the problem is in strcmp istself, not in the regression tests, since even some tests where only a trivial peephole like changing an absolute to conditional jumps is applied fail. I do not see any peephole comments in device/lib/build/z80/_strcmp.asm though. Philipp |
From: Borut R. <bor...@si...> - 2007-05-06 11:27:32
|
Philipp Klaus Krause wrote: <snip> > I do not see any peephole comments in > device/lib/build/z80/_strcmp.asm though. > > This is because the libraries are built without --fverbose-asm command line option. Borut |
From: Borut R. <bor...@si...> - 2007-05-06 12:51:22
|
After the clean rebuild I reproduced the problem on Windows mingw too. Borut Borut Razem wrote: > Maarten Brock wrote: >> I did a clean checkout and could reproduce the problem also. >> >> Next I tried your proposed vpath but it fails with files it cannot >> find. I guess you cannot use it unless you've cleaned the original >> first. >> >> > > Yes, that's right. > >> Instead I did another clean checkout now and will build it with the >> --fverbose-asm modification to the Makefile to see if that solves it >> again. >> >> > > It is the best you can do to be sure that everything is OK. > >> I'm just guessing here because I can't think of anything better. >> >> Maarten >> > > In the mean time I tried to reproduce the problem on Windows with > mingw build, and (guess what?) I couldn't. Now I'll remove the build > directory and retry the build... > > Borut > |