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 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. Thanks for all the work on the compiler Alan (*) 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
