> On Tue, 31 May 2016 00:09:01 +0200 (CEST) > "Maarten Brock" <sourceforge.br...@dse.nl> wrote: > >> Hello SDCC followers, >> >> Today the first Release Candidate (RC1) for SDCC 3.6.0 has been created. >> As always it has been put online in our SourceForge File section. >> https://sourceforge.net/projects/sdcc/files/ >> >> If you have the time, please verify it and report back with the positive >> or negative results. > > The positive: > > l9x now builds without weird type errors that were present on 950x
I'm not quite sure what you mean here. What is l9x? And I guess 950x is a subversion revision of sdcc. > Code generation for compactness at least is again way better on Z80. The > Bourne shell was 25762 bytes last time I looked and is now down to 24354 > (assuming of course it still works when I get round to testing!) > > Almost everything still builds for the Fuzix C libraries and application > set, which is becoming a fairly large chunk of code. > > The negative: > > calendar.c:233: warning 84: 'auto' variable 'retval' may be used before > initialization Caught signal 11: SIGSEGV > > m4.c:485: error 9: FATAL Compiler Internal Error in file 'gen.c' line > number '4224' : code generator internal error Contact Author with source > code m4.c:485: error 9: FATAL Compiler Internal Error in file 'gen.c' > line number '4224' : code generator internal error Contact Author with > source code > > In one case code that used to build now errors (correctly due to the > tightening up on type specifiers) but shows weird behaviour - some of the > warnings are not displaying the correct line number and show "-" as the > filename: > > exec.c:88: error 226: no type specifier for 'i' > -:0: warning 85: in function setcmd unreferenced local variable : 'len' > -:0: warning 85: in function setcmd unreferenced local variable : 'i' > exec.c:524: warning 85: in function backup unreferenced local variable : > 'p' > -:0: warning 85: in function nextfile unreferenced local variable : 'what' > > > None of these have obvious small reproducers - is there a preferred way > to send you something to debug ? > > > Minor > > > An implicit declaration is now followed by a confusing report about auto > variables > > man.c:590: warning 112: function 'build_headers' implicit > declaration > man.c:590: warning 84: 'auto' variable 'build_headers' may be > used before initialization > > > Warnings for the common expression > > for (tp = tbuf; tp < &tbuf[TSIZE]; tp++) > > where TSZIZE is the size of the struct. > > Although having quickly checked those don't appear to be that new > > > > I've not done any real runtime testing but I will try and do that and > also pull out some of the workarounds I have for older sdcc and see how > many of those still break. > > So far this all looks pretty good to me for a first release candidate. > > > I still hit the following limits (unsurprisingly) > > - the speed of optimized compilation for Z80 (ok it is a bitch of a CPU to > generate code for) > - code generation (way better than any other Z80 compiler but still > some real facepalm grade code generation in there and often for trivial > easily optimised cases like 16bit equality compares with 0-255) (*) > - inability to assign structs (even ones that fit an int or pointer > size), which stops me from using sdcc with yacc when %union is used > > > Also a question: I have some nice clean compiler patches for code banking > but not yet good linker ones. I don't know if you are interested in them > once 3.6 is out but basically they add a Z80 compiler option which > > - changes the calling sequence to expect arguments two bytes further up > the stack > - puts text constants in const not code (IMHO this is a bug fix) > - generates > > push af > call func > pop af > > sequences for function calls. The smart linker then replaces > inter-segment calls with > > call _helperfunc_a_b ; helperfunc is the right helper, a b > ; are the banks > defw func > > and the helpers use the extra two stack bytes to save/restore the banks > when switching. Indirect calls via pointers are revectored via stubs > generated by the linker. > > I've been using it for the Fuzix kernel on ZX Spectrum for a while and it > seems to be fairly solid at this point. Bugs and patches can be sent to our Sourceforge trackers: https://sourceforge.net/p/sdcc/bugs/ https://sourceforge.net/p/sdcc/patches/ > Thanks for all the work on the compiler > > Alan Are any of the problems you experience regressions from sdcc 3.5.0? Thanks for checking, Maarten > > (*) In that case it's > > ld a,b > dec a > jr nz, false_path > ld a,c > or a > .. > > where of course the second part should just or c knowing a is 0 ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e _______________________________________________ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
