You can subscribe to this list here.
2000 |
Jan
(1) |
Feb
(56) |
Mar
(65) |
Apr
(18) |
May
(40) |
Jun
(12) |
Jul
(18) |
Aug
(19) |
Sep
(164) |
Oct
(86) |
Nov
(67) |
Dec
(29) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(96) |
Feb
(176) |
Mar
(119) |
Apr
(59) |
May
(181) |
Jun
(193) |
Jul
(140) |
Aug
(180) |
Sep
(182) |
Oct
(322) |
Nov
(263) |
Dec
(187) |
2002 |
Jan
(130) |
Feb
(83) |
Mar
(106) |
Apr
(28) |
May
(39) |
Jun
(46) |
Jul
(78) |
Aug
(107) |
Sep
(66) |
Oct
(33) |
Nov
(58) |
Dec
(53) |
2003 |
Jan
(197) |
Feb
(261) |
Mar
(282) |
Apr
(242) |
May
(218) |
Jun
(107) |
Jul
(108) |
Aug
(78) |
Sep
(129) |
Oct
(181) |
Nov
(139) |
Dec
(108) |
2004 |
Jan
(224) |
Feb
(185) |
Mar
(115) |
Apr
(102) |
May
(98) |
Jun
(103) |
Jul
(124) |
Aug
(88) |
Sep
(124) |
Oct
(100) |
Nov
(74) |
Dec
(79) |
2005 |
Jan
(66) |
Feb
(83) |
Mar
(123) |
Apr
(53) |
May
(109) |
Jun
(46) |
Jul
(126) |
Aug
(78) |
Sep
(61) |
Oct
(43) |
Nov
(213) |
Dec
(93) |
2006 |
Jan
(63) |
Feb
(109) |
Mar
(79) |
Apr
(185) |
May
(283) |
Jun
(179) |
Jul
(147) |
Aug
(156) |
Sep
(114) |
Oct
(173) |
Nov
(137) |
Dec
(148) |
2007 |
Jan
(154) |
Feb
(108) |
Mar
(132) |
Apr
(151) |
May
(241) |
Jun
(94) |
Jul
(109) |
Aug
(50) |
Sep
(62) |
Oct
(128) |
Nov
(90) |
Dec
(74) |
2008 |
Jan
(53) |
Feb
(161) |
Mar
(261) |
Apr
(53) |
May
(87) |
Jun
(44) |
Jul
(73) |
Aug
(67) |
Sep
(54) |
Oct
(37) |
Nov
(72) |
Dec
(53) |
2009 |
Jan
(51) |
Feb
(73) |
Mar
(84) |
Apr
(67) |
May
(59) |
Jun
(31) |
Jul
(78) |
Aug
(45) |
Sep
(90) |
Oct
(56) |
Nov
(69) |
Dec
(51) |
2010 |
Jan
(188) |
Feb
(73) |
Mar
(20) |
Apr
(46) |
May
(91) |
Jun
(24) |
Jul
(115) |
Aug
(135) |
Sep
(132) |
Oct
(90) |
Nov
(92) |
Dec
(58) |
2011 |
Jan
(121) |
Feb
(90) |
Mar
(56) |
Apr
(79) |
May
(98) |
Jun
(109) |
Jul
(104) |
Aug
(113) |
Sep
(234) |
Oct
(143) |
Nov
(160) |
Dec
(93) |
2012 |
Jan
(162) |
Feb
(160) |
Mar
(219) |
Apr
(186) |
May
(135) |
Jun
(360) |
Jul
(138) |
Aug
(72) |
Sep
(130) |
Oct
(146) |
Nov
(64) |
Dec
(137) |
2013 |
Jan
(65) |
Feb
(18) |
Mar
(35) |
Apr
(26) |
May
(108) |
Jun
(34) |
Jul
(16) |
Aug
(11) |
Sep
(61) |
Oct
(4) |
Nov
(23) |
Dec
(24) |
2014 |
Jan
(56) |
Feb
(58) |
Mar
(54) |
Apr
(26) |
May
(3) |
Jun
(31) |
Jul
(13) |
Aug
(13) |
Sep
(7) |
Oct
(26) |
Nov
(65) |
Dec
(54) |
2015 |
Jan
(64) |
Feb
(15) |
Mar
(25) |
Apr
(41) |
May
(22) |
Jun
(62) |
Jul
(26) |
Aug
(17) |
Sep
(35) |
Oct
(33) |
Nov
(37) |
Dec
(17) |
2016 |
Jan
(39) |
Feb
(12) |
Mar
(15) |
Apr
(13) |
May
(41) |
Jun
(76) |
Jul
(53) |
Aug
(38) |
Sep
(31) |
Oct
(11) |
Nov
(9) |
Dec
(19) |
2017 |
Jan
(11) |
Feb
(19) |
Mar
|
Apr
(28) |
May
(61) |
Jun
(9) |
Jul
(9) |
Aug
(14) |
Sep
|
Oct
(63) |
Nov
(43) |
Dec
(21) |
2018 |
Jan
(24) |
Feb
(46) |
Mar
(38) |
Apr
(6) |
May
(14) |
Jun
(10) |
Jul
(12) |
Aug
(12) |
Sep
(29) |
Oct
(9) |
Nov
(17) |
Dec
(22) |
2019 |
Jan
(20) |
Feb
(22) |
Mar
(22) |
Apr
(10) |
May
(2) |
Jun
(7) |
Jul
(5) |
Aug
|
Sep
(5) |
Oct
(13) |
Nov
(8) |
Dec
(11) |
2020 |
Jan
(23) |
Feb
(14) |
Mar
(2) |
Apr
(11) |
May
(14) |
Jun
(48) |
Jul
(111) |
Aug
(26) |
Sep
(6) |
Oct
(22) |
Nov
(7) |
Dec
(26) |
2021 |
Jan
(4) |
Feb
(40) |
Mar
(64) |
Apr
(46) |
May
(18) |
Jun
(20) |
Jul
(11) |
Aug
(40) |
Sep
(16) |
Oct
(15) |
Nov
(46) |
Dec
(10) |
2022 |
Jan
(60) |
Feb
(163) |
Mar
(117) |
Apr
(8) |
May
(22) |
Jun
(13) |
Jul
(5) |
Aug
(1) |
Sep
(20) |
Oct
(4) |
Nov
(13) |
Dec
(16) |
2023 |
Jan
(45) |
Feb
(5) |
Mar
(1) |
Apr
(7) |
May
(128) |
Jun
(41) |
Jul
(40) |
Aug
(52) |
Sep
(20) |
Oct
(18) |
Nov
(40) |
Dec
(52) |
2024 |
Jan
(19) |
Feb
(5) |
Mar
(6) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Erik P. <epe...@iv...> - 2024-03-12 04:41:38
|
On Mon, 2024-03-11 at 16:04 +0100, Sebastien Lorquet wrote: > > Hello, > > Here it is in the svn book: > https://svnbook.red-bean.com/en/1.5/svn-book.pdf > > page 221: > > use-commit-times > Normally your working copy files have timestamps that reflect the > last time they were > touched by any process, whether your own editor or some svn > subcommand. This is > generally convenient for people developing software, because build > systems often look > at timestamps as a way of deciding which files need to be recompiled. > In other situations, however, it's sometimes nice for the working > copy files to have > timestamps that reflect the last time they were changed in the > repository. The svn ex- > port command always places these “last-commit timestamps” on trees > that it pro- > duces. By setting this config variable to yes, the svn checkout, svn > update, svn > switch, and svn revert commands will also set last-commit timestamps > on files that > they touch. > > Looks like this setting is to be defined in the subversion > configuration file at $HOME/.subversion/config > > Alternatively svn export should be used instead of checkout/update. > > Best regards > > Sebastien Thanks for tracking this down for me. My day job is keeping me quite busy lately, so this is helpful. I'll try to implement this in the snapshot generation / website update process this weekend. Erik > |
From: Sebastien L. <seb...@lo...> - 2024-03-11 15:21:53
|
Hello, Here it is in the svn book: https://svnbook.red-bean.com/en/1.5/svn-book.pdf page 221: use-commit-times Normally your working copy files have timestamps that reflect the last time they were touched by any process, whether your own editor or somesvnsubcommand. This is generally convenient for people developing software, because build systems often look at timestamps as a way of deciding which files need to be recompiled. In other situations, however, it's sometimes nice for the working copy files to have timestamps that reflect the last time they were changed in the repository. Thesvn ex- portcommand always places these “last-commit timestamps” on trees that it pro- duces. By setting this config variable toyes, thesvn checkout,svn update,svn switch, andsvn revertcommands will also set last-commit timestamps on files that they touch. Looks like this setting is to be defined in the subversion configuration file at $HOME/.subversion/config Alternatively svn export should be used instead of checkout/update. Best regards Sebastien Le 09/03/2024 à 10:04, Erik Petrich a écrit : > On Tue, 2024-03-05 at 10:21 +0100, Philipp Klaus Krause wrote: >> Am 05.03.24 um 07:00 schrieb Erik Petrich: >>> Yes, it updates using rsync with the --size-only parameter. >> What is the reason for the --size-only? A normal rsync would trigger >> if >> times or sizes change. Does something not under our control change >> the >> times? >> >> Philipp > I looked into the history hoping to find a comment when the option was > introduced, but the --size-only has been there since Borut's initial > check-in of both files that I've seen it used. > > Looking further, it seems that the default timestamp on files created > during the svn checkout reflect the time they were checked out, rather > than the time they were last committed. In that case, rsync would be > trying to update all the web site files every day since there was a > fresh checkout from svn every day. I think we can change how the > timestamps are set on checkout, but I need to read more of the svn > documentation to understand this better first. > > Erik > > > > > > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-devel |
From: Erik P. <epe...@iv...> - 2024-03-09 09:04:56
|
On Tue, 2024-03-05 at 10:21 +0100, Philipp Klaus Krause wrote: > Am 05.03.24 um 07:00 schrieb Erik Petrich: > > Yes, it updates using rsync with the --size-only parameter. > > What is the reason for the --size-only? A normal rsync would trigger > if > times or sizes change. Does something not under our control change > the > times? > > Philipp I looked into the history hoping to find a comment when the option was introduced, but the --size-only has been there since Borut's initial check-in of both files that I've seen it used. Looking further, it seems that the default timestamp on files created during the svn checkout reflect the time they were checked out, rather than the time they were last committed. In that case, rsync would be trying to update all the web site files every day since there was a fresh checkout from svn every day. I think we can change how the timestamps are set on checkout, but I need to read more of the svn documentation to understand this better first. Erik |
From: Philipp K. K. <pk...@sp...> - 2024-03-05 09:21:30
|
Am 05.03.24 um 07:00 schrieb Erik Petrich: > Yes, it updates using rsync with the --size-only parameter. What is the reason for the --size-only? A normal rsync would trigger if times or sizes change. Does something not under our control change the times? Philipp |
From: Erik P. <epe...@iv...> - 2024-03-05 06:15:45
|
On Mon, 2024-03-04 at 12:18 +0100, Philipp Klaus Krause wrote: > Do we still have the problem of the website updating from svn only > when > the size of files changes? > > I fixed a typo on our starting page 26 hours ago, and the website > still > has the typo. > > Philipp Yes, it updates using rsync with the --size-only parameter. If you want to change just a single character, remember to also add/remove a blank or newline somewhere inconspicuous so that the overall file size also changes. Erik |
From: Philipp K. K. <pk...@sp...> - 2024-03-04 11:18:41
|
Do we still have the problem of the website updating from svn only when the size of files changes? I fixed a typo on our starting page 26 hours ago, and the website still has the typo. Philipp |
From: Steve S. <ste...@gm...> - 2024-02-25 09:21:13
|
I'm wondering how difficult it would be to support the gcc syntax for inline asm. Maybe nor everything at once, or not optimally. I'm actually very interested in the %1 style parameters, in order to avoid coping local vars to specific registers before inline asm code. -- Steve SCHNEPP |
From: Strobl A. <a.s...@aw...> - 2024-02-15 11:09:05
|
These pic16 types I have in use in my projects/devices * PIC18F2550 * PIC18F25J50 * PIC18F2620 * PIC18F2680 * PIC18F2685 * PIC18F4550 * PIC18F4620 * PIC18F4680 * PIC18F67J60 * PIC18F97J60 most current projects are using * PIC18F26K22 * PIC18F46K22 with compiler: sdcc-4.3.2 svn version 14342 (gputils svn 1331) All my pic14 and pic16 code is compiled using sdcc. I have tried to compile a current pic18f46k22 project and uploaded it to chip. A first test shows, the program is still functional. The code size increases with the new patches... Best regards, Toni |
From: Kustaa N. <ea...@ea...> - 2024-02-08 04:27:08
|
I'm using SDCC with PIC18F45K50 for a couple of projects. wbr Kusti On 7.2.2024 15.40, Jonathon Hall wrote: > Hi all, I have been working for some time on getting the pic16 backend > fully working. The first goal is to get all unit tests passing, then > look at optimizing the generated code. > > Is anybody currently using the pic16 backend? I have a few patches > that could use review from other pic16 users. Patches 4-6 here are > not yet merged and could use review: > https://sourceforge.net/p/sdcc/patches/472/ > > 0004 "pic16: CALL/RETURN uses FSR0H, add generic pointer calling > conventions" fixes the register usage model for CALL/RETURN > instructions. FSR0H was not considered "used" for a return > instruction, but it is used when returning a >4 byte value. >4 byte > values are placed on the stack and the address returned in > FSR0H:FSR0L. Since FSR0H was not considered "used", its > initialization could be omitted, which means the returned address was > wrong. > > It also adds the specialized calling conventions used for the generic > pointer functions. I had not actually seen it omit these > initializations but they should be modeled correctly. > > 0005 "pic16 tests: enable stdout to USART" makes it easier to > troubleshoot unit tests by capturing stdout in the logs. The tests > already write assertion failure information to stdout, but that went > nowhere on pic16. > > 0006 "device/lib/pic16: Wait for PIR1.TXIF when writing to USART, not > TXSTA.TRMT" is just an improvement for stdout output to USART, when > troubleshooting some code on a real pic16 I noticed the USART output > was waiting longer than necessary. It was waiting until the prior > byte was fully shifted out of the USART before writing another, when > it really only needs to wait until the transmit register is empty. > > I would appreciate any review / comments on any of these patches! > Just knowing how (or if) the pic16 backend is used by anybody right > now would be helpful too, I intend to keep any working code working > throughout this process. > > Thanks! > Jonathon > > > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-devel |
From: Jonathon H. <dab...@gm...> - 2024-02-07 13:41:10
|
Hi all, I have been working for some time on getting the pic16 backend fully working. The first goal is to get all unit tests passing, then look at optimizing the generated code. Is anybody currently using the pic16 backend? I have a few patches that could use review from other pic16 users. Patches 4-6 here are not yet merged and could use review: https://sourceforge.net/p/sdcc/patches/472/ 0004 "pic16: CALL/RETURN uses FSR0H, add generic pointer calling conventions" fixes the register usage model for CALL/RETURN instructions. FSR0H was not considered "used" for a return instruction, but it is used when returning a >4 byte value. >4 byte values are placed on the stack and the address returned in FSR0H:FSR0L. Since FSR0H was not considered "used", its initialization could be omitted, which means the returned address was wrong. It also adds the specialized calling conventions used for the generic pointer functions. I had not actually seen it omit these initializations but they should be modeled correctly. 0005 "pic16 tests: enable stdout to USART" makes it easier to troubleshoot unit tests by capturing stdout in the logs. The tests already write assertion failure information to stdout, but that went nowhere on pic16. 0006 "device/lib/pic16: Wait for PIR1.TXIF when writing to USART, not TXSTA.TRMT" is just an improvement for stdout output to USART, when troubleshooting some code on a real pic16 I noticed the USART output was waiting longer than necessary. It was waiting until the prior byte was fully shifted out of the USART before writing another, when it really only needs to wait until the transmit register is empty. I would appreciate any review / comments on any of these patches! Just knowing how (or if) the pic16 backend is used by anybody right now would be helpful too, I intend to keep any working code working throughout this process. Thanks! Jonathon |
From: Philipp K. K. <pk...@sp...> - 2024-02-05 12:28:22
|
Am 05.02.24 um 09:53 schrieb Maarten Brock: > I guess this depends on whether we find a proper solution quickly. If > so, there might be an intermediate release. And otherwise there will > only be the win32 variant for Windows. > > It would be interesting to know about different build times between > win32 and win64. This would have been the amd64 Windows installer, if it had been released along with the other release files: http://www.colecovision.eu/stuff/sdcc-4.4.0-x64-setup.exe |
From: Philipp K. K. <pk...@sp...> - 2024-01-29 12:58:08
|
Following the SDCC 4.4.0 release, the trnk is about to become unfrozen. This shall happen by merging the next branch to trunk (to ensure consistency of version numbers vs. .rel fomrat for z80-related ports). So feel free to commit future sufficiently-tested changes to trunk once next has been merged to trunk. Philipp |
From: Philipp K. K. <pk...@sp...> - 2024-01-29 12:53:48
|
The official release for SDCC 4.4.0 is available in our SourceForge File release system: https://sourceforge.net/projects/sdcc/files/ In addition to the source package, binaries are available for x86 Windows, amd64 macOS, and amd64 GNU/Linux. In addition to various bug fixes, notable features added since the 4.3.0 release are: * Optimizations for rotations. * struct / union parameters for hc08, s08 and mos6502. * Many bug fixes for -ms08 --stack-auto. * struct / union return support for hc08 and s08 (caller side only). * Generalized constant propagation. * New command line option --syntax-only to only parse the input. * Added C99 header inttypes.h * Added library functions imaxabs, imaxdiv, llabs, strtoimax, strtoll, strtoull, strtoumax, wcsncmp, wcstoimax, wcstol, wcstoll, wcstoul, wcstoull, wcstoumax * New r800 port to better support the ASCII Corp R800 and Zilog Z280. * Changed the default calling convention for r2k, r2ka, r3ka, tlcs90, ez80-z80 from version 0 to 1 (this is an ABI break, and will require changes to user-written asm functions or their declarations). * Improved optimizations for code speed for stm8, pdk, z80 (and related). * New mos65c02 port to better support the WDC 65C02. A full list of changes can be found in the ChangeLog: https://sourceforge.net/p/sdcc/code/HEAD/tree/tags/sdcc-4.4.0-/sdcc/ChangeLog Philipp (SDCC 4.4.0 release manager) |
From: Philipp K. K. <pk...@sp...> - 2024-01-26 09:54:15
|
There was progress: we now have SDCC 4.4.0 RC3. I'm still not happy with the windows situation. * Locally built windows snapshots are bad on my laptop (regression test failures for multiple ports, which ones and how depends on x86 vs amd64 build). * I see regression test failures for the amd64 Windows builds in the farm: one test fails for stm8-large, multiple ones fail for mos65c02. The release is already delayed quite bit, and Windows issues tend to take time to solve, since SDCC developers tend to not be familiar with that OS. To avoid delaying the release further, I suggest to not release amd64 SDCC binaries for windows, and just release x86 Windows builds from the snapshots built in the farm. AFAIK, x86 Windows software should still run fine on current amd64 Windows. Philipp |
From: Benedikt F. <b.f...@gm...> - 2024-01-20 11:56:27
|
Am 20.01.24 um 10:52 schrieb Philipp Klaus Krause: > Am 19.01.24 um 10:09 schrieb Philipp Klaus Krause: >> Am 18.01.24 um 08:31 schrieb Philipp Klaus Krause: >>> Progress update on the SDCC 4.4.0 release: >>> >>> All previously found release-critical issues have been fixed. >>> >>> However, one of them turned out to be an issue in the snapshots >>> cross-build system, that resulted in 32-Bit Windows results >>> appearing as 64Bit Windows snapshot results: >>> >>> https://sourceforge.net/p/sdcc/bugs/3698/ >> >> I think the patch posted there should do to fis this one. At least it >> didn't break my local 64-Bit Windows snapshot testing (using hte >> nativecrosstools branch), so it doesn't regress. >> Please have a look to see if it is okay to go into trunk. > > I consider this one to be a low-risk change: the change does not > directly affect any release deliverable; it only affects regression > testing of Windows snaposhots inthe compile farm. > > Philipp > Looking at the patch and its trivial nature, I would say: Go ahead and apply it, provided that we can be sure that 32 and 64 bit regression testing does indeed happen sequentially and not concurrently. Benedikt |
From: Philipp K. K. <pk...@sp...> - 2024-01-20 09:53:10
|
Am 19.01.24 um 10:09 schrieb Philipp Klaus Krause: > Am 18.01.24 um 08:31 schrieb Philipp Klaus Krause: >> Progress update on the SDCC 4.4.0 release: >> >> All previously found release-critical issues have been fixed. >> >> However, one of them turned out to be an issue in the snapshots >> cross-build system, that resulted in 32-Bit Windows results appearing >> as 64Bit Windows snapshot results: >> >> https://sourceforge.net/p/sdcc/bugs/3698/ > > I think the patch posted there should do to fis this one. At least it > didn't break my local 64-Bit Windows snapshot testing (using hte > nativecrosstools branch), so it doesn't regress. > Please have a look to see if it is okay to go into trunk. I consider this one to be a low-risk change: the change does not directly affect any release deliverable; it only affects regression testing of Windows snaposhots inthe compile farm. Philipp |
From: Philipp K. K. <pk...@sp...> - 2024-01-19 09:09:50
|
Am 18.01.24 um 08:31 schrieb Philipp Klaus Krause: > Progress update on the SDCC 4.4.0 release: > > All previously found release-critical issues have been fixed. > > However, one of them turned out to be an issue in the snapshots > cross-build system, that resulted in 32-Bit Windows results appearing as > 64Bit Windows snapshot results: > > https://sourceforge.net/p/sdcc/bugs/3698/ I think the patch posted there should do to fis this one. At least it didn't break my local 64-Bit Windows snapshot testing (using hte nativecrosstools branch), so it doesn't regress. Please have a look to see if it is okay to go into trunk. > IMO, that issue by itself is not bad enough to furhter delay the SDCC > 4.4.0 release. But it meant that we never really saw real 64-Bit Windwos > regression test results on snapshots. > And when I finally got them, I found that we do have another problem > that looks release-critical: https://sourceforge.net/p/sdcc/bugs/3697/ This one is weird. On the 64-bit Windows build we get register allocations that are quite odd. And I don't see how they could be optimal. Sure the allocator still tries to put as much into registers as possible, but the choice of registers a vs. p looks weird. I don't know yet, why that happens. Sometimes it feels as if the cost function was pseudo-randomized. Still, all the failures are due to real bugs in code generation, that maybe might be triggered on any OS by some different input. So I keep working on fixing the code generation bugs for now. Philipp |
From: Philipp K. K. <pk...@sp...> - 2024-01-18 07:32:23
|
Progress update on the SDCC 4.4.0 release: All previously found release-critical issues have been fixed. However, one of them turned out to be an issue in the snapshots cross-build system, that resulted in 32-Bit Windows results appearing as 64Bit Windows snapshot results: https://sourceforge.net/p/sdcc/bugs/3698/ IMO, that issue by itself is not bad enough to furhter delay the SDCC 4.4.0 release. But it meant that we never really saw real 64-Bit Windwos regression test results on snapshots. And when I finally got them, I found that we do have another problem that looks release-critical: https://sourceforge.net/p/sdcc/bugs/3697/ Philipp |
From: Philipp K. K. <pk...@sp...> - 2024-01-16 06:53:35
|
Am 16.01.24 um 07:39 schrieb Philipp Klaus Krause: > Am 15.01.24 um 16:01 schrieb Benedikt Freisen via sdcc-devel: >> The patch for https://sourceforge.net/p/sdcc/bugs/3695/ looks good to me. >> I also suggest to add a makeshift fix for >> https://sourceforge.net/p/sdcc/bugs/3694/ to the uninstall target in >> sdcc/src/Makefile.in, i.e. to simply delete sdcpp there, unless somebody >> objects. > > While that doesn't look like a clean solution, it fixes the bug for now, > so I agree. Once that fix for the make uninstall issue is in, the only remaining release-critical issue I know about is https://sourceforge.net/p/sdcc/bugs/3690/ It got partially fixed (GNU/Linux, FreeBSD, and 32-Bit Windows builds apparently are fine now), but still affects 64-Bit Windows regression tests. Philipp |
From: Philipp K. K. <pk...@sp...> - 2024-01-16 06:40:11
|
Am 15.01.24 um 16:01 schrieb Benedikt Freisen via sdcc-devel: > The patch for https://sourceforge.net/p/sdcc/bugs/3695/ looks good to me. > I also suggest to add a makeshift fix for > https://sourceforge.net/p/sdcc/bugs/3694/ to the uninstall target in > sdcc/src/Makefile.in, i.e. to simply delete sdcpp there, unless somebody > objects. While that doesn't look like a clean solution, it fixes the bug for now, so I agree. Philipp |
From: Benedikt F. <b.f...@gm...> - 2024-01-15 15:02:55
|
The patch for https://sourceforge.net/p/sdcc/bugs/3695/ looks good to me. I also suggest to add a makeshift fix for https://sourceforge.net/p/sdcc/bugs/3694/ to the uninstall target in sdcc/src/Makefile.in, i.e. to simply delete sdcpp there, unless somebody objects. -- Benedikt Am 13.01.24 um 13:41 schrieb Philipp Klaus Krause: > Am 12.01.24 um 12:51 schrieb Philipp Klaus Krause: >> Am 11.01.24 um 15:34 schrieb Maarten Brock: >>> Hi Philipp, >>> >>> I suggest to try to fix all three. But if fixing 1) takes too long we >>> might as well continue and add an explicit warning about this open bug. >>> >>> Maarten >>> >> >> Issues 0 and 2 should be fixed now. For issue 1 I have posted a patch >> that should fix it in the ticket: >> https://sourceforge.net/p/sdcc/bugs/3690/ >> >> Meanwhile, a new issue 3 has been found (make uninstall leaves a file >> behind): >> https://sourceforge.net/p/sdcc/bugs/3694/ >> > > The fix for issue 1 turned out to be incomplete (it apaprently fixes > the issue for non-regression testing use on GNU/Linux, but Windows > regression testing still fails the old way). > > And a new issue 4: https://sourceforge.net/p/sdcc/bugs/3695/ (Windows > installer does not install one of the library files, I posted a patch > in the ticket). > > Philipp > |
From: Philipp K. K. <pk...@sp...> - 2024-01-13 12:41:53
|
Am 12.01.24 um 12:51 schrieb Philipp Klaus Krause: > Am 11.01.24 um 15:34 schrieb Maarten Brock: >> Hi Philipp, >> >> I suggest to try to fix all three. But if fixing 1) takes too long we >> might as well continue and add an explicit warning about this open bug. >> >> Maarten >> > > Issues 0 and 2 should be fixed now. For issue 1 I have posted a patch > that should fix it in the ticket: https://sourceforge.net/p/sdcc/bugs/3690/ > > Meanwhile, a new issue 3 has been found (make uninstall leaves a file > behind): > https://sourceforge.net/p/sdcc/bugs/3694/ > The fix for issue 1 turned out to be incomplete (it apaprently fixes the issue for non-regression testing use on GNU/Linux, but Windows regression testing still fails the old way). And a new issue 4: https://sourceforge.net/p/sdcc/bugs/3695/ (Windows installer does not install one of the library files, I posted a patch in the ticket). Philipp |
From: Maarten B. <sou...@ds...> - 2024-01-12 13:33:02
|
Hi Philipp, I assume here that you are talking about SDCC target libraries and not about used Windows DLLs. It seems that the linker is missing a verbosity flag to make debugging this problem easier. Have you looked in the generated .lk linker scripts? Maarten Philipp Klaus Krause schreef op 2024-01-12 12:34: > Looks like -ms08 --stack-auto nearly always uses the wrong library. It > only gets it right for regression testing on non-Windows systems. E.g. > even on GNU/Linux the wrong library gets chosen, unless we happen to > be compiling the regression tests. > > Philipp |
From: Philipp K. K. <pk...@sp...> - 2024-01-12 11:51:17
|
Am 11.01.24 um 15:34 schrieb Maarten Brock: > Hi Philipp, > > I suggest to try to fix all three. But if fixing 1) takes too long we > might as well continue and add an explicit warning about this open bug. > > Maarten > Issues 0 and 2 should be fixed now. For issue 1 I have posted a patch that should fix it in the ticket: https://sourceforge.net/p/sdcc/bugs/3690/ Meanwhile, a new issue 3 has been found (make uninstall leaves a file behind): https://sourceforge.net/p/sdcc/bugs/3694/ Philipp |
From: Philipp K. K. <pk...@sp...> - 2024-01-12 11:34:49
|
Looks like -ms08 --stack-auto nearly always uses the wrong library. It only gets it right for regression testing on non-Windows systems. E.g. even on GNU/Linux the wrong library gets chosen, unless we happen to be compiling the regression tests. Philipp |