Re: [avr-gcc-list] testsuite saga continues
Hi, all Wouter van Gulik wrote: The exit through the exit port already shows the address. Its only the exit through rjmp +0 that doesn't. I'll change that to make it consistent. On exit you print CPU_C while in log you print CPU_C * 2. That's the difference, and CPU_C is not so useful. Having the true address makes referencing back into a .lss file easier. Just a little note to let you know that the above change and other small cleanups have been committed to cvs. From the changelog: - give more information at program exit - cleanup a lot of #ifdef's - change the timeout from cycles to instructions, because the simulator runs slightly faster this way - add a barrier for the stack at 0x60, that makes avrtest abort with stack overflow when crossed The next step will definitely be ELF loading support. With ELF loading, I can decode symbols like __bss_end to know where the stack overflows exactly or use __stack to know where the stack underflows. I can also do a more symbolic log, by decoding addresses to their symbol names. -- Paulo Marques Software Development Department - Grupo PIE, S.A. Phone: +351 252 290600, Fax: +351 252 290601 Web: www.grupopie.com Deleted code is debugged code. Jeff Sickel ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] testsuite saga continues
Just a little note to let you know that the above change and other small cleanups have been committed to cvs. From the changelog: - give more information at program exit - cleanup a lot of #ifdef's - change the timeout from cycles to instructions, because the simulator runs slightly faster this way - add a barrier for the stack at 0x60, that makes avrtest abort with stack overflow when crossed Yes I have seen it, and used it. My clz no longer passes the test. It bails on stack overflow. But if I comment out the long long parts, all is ok. The next step will definitely be ELF loading support. With ELF loading, I can decode symbols like __bss_end to know where the stack overflows exactly or use __stack to know where the stack underflows. I can also do a more symbolic log, by decoding addresses to their symbol names. That would be very cool! Although a dump log at an abort might also be useful when debugging testcases. Some more thoughts about the smaller avr's. I did not intend to catch wrong instruction, but I was aiming at finding bugs that are do not apply to the mega series. Because if there are bugs in the less capable devices, it's very likely to be in the avr backend, which is easier to fix. Can't avrtest/gcc fake a avr2 device (e.g. at90s8535) with tons of flash and ram? Just like you now fake huge amounts of external memory? Thanks for the good work! Wouter ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] patch posted
Hi, Andrew, Andrew Hutchinson wrote: I posted patch to cure spill bugs. It passed all testing. I tested the patch too, and it seems to fix a few failures. Nice work. before your patch (complete gcc.c-torture): # of expected passes21244 # of unexpected failures162 # of unresolved testcases 52 # of unsupported tests 85 /home/pmarques/Desktop/gcc-4.2.2/svn/obj/gcc/xgcc version 4.3.0 20080129 (experimental) (GCC) after your patch (complete gcc.c-torture): # of expected passes21247 # of unexpected failures152 # of unresolved testcases 53 # of unsupported tests 86 /home/pmarques/Desktop/gcc-4.2.2/svn/obj/gcc/xgcc version 4.3.0 20080129 (experimental) (GCC) I had to apply the patch manually, though, as I couldn't get the patch out of the mailing list archive without corruption :( That extra unresolved and extra unsupported test case is probably a .text segment full error. If this is the case, then probably the generated code is slightly larger for at least one test case. I still have to dig some more to find out exactly what happened. I would be interested in seeing how this affects size,speed of avr-gcc. Me too. I was wondering what would be the best way to use the testsuite and avrtest to get a quantitative estimate of code size / execution time variations. I thought that the first rough estimate would be to make avrtest accumulate all the bytes loaded and cycles executed during a testsuite run. Then I could apply a patch and redo the tests and see how that affected the values. But this doesn't really work, because: - if a test fails in one run and not on the other, it can exit early and execute in less cycles. Not using failed tests for the statistics has similar problems. - we probably want code size with -Os and execution speed with -O2 / -O3 and not both mixed. I know that the testsuite probably isn't the best speed / code size / RAM used benchmark available, but since I'll be running it on a regular basis and I'll be using it to bisect regressions, I could get these results basically for free... -- Paulo Marques Software Development Department - Grupo PIE, S.A. Phone: +351 252 290600, Fax: +351 252 290601 Web: www.grupopie.com There cannot be a crisis today; my schedule is already full. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
[avr-gcc-list] Move '__do_copy_data' from gcrt1.S to libgcc.S
Hello.
This patches move '_do_copy_data' code for devices with 128KB and up FLASH
from avr-libc to libgcc.
Anatoly.
begin 666 gcc-4.3-do_copy_data.txt
[EMAIL PROTECTED](=C8R]C;VYF:6O879R+VQI8F=C8RY3CT]/3T]/3T]/3T]/3T]
M/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]
M/3T]/3T]/3T*+2TM(=C8R]C;VYF:6O879R+VQI8F=C8RY32AR979IVEO
M;B Q,S([EMAIL PROTECTED]BLK*R!G8V,O8V]N9FEG+V%VB]L:6)G8V,N4PDH=V]R:VEN
M9R!C;W!Y*0I 0 M,S(L-B K,S(L-R! 0 H@(V1E9FEN92!?7U-214=?7R P
M#-FB C95F:6YE(%]?4U!?2%]?(#!X,V4*(-D969I;[EMAIL PROTECTED],7U\@
M,'@S9 HK(V1E9FEN92!?7U)!35!:7U\@,'@[EMAIL PROTECTED]@B O*B!-;W-T(]F('1H
M92!F=6YC=EO;G,@:5R92!A[EMAIL PROTECTED];5D(1IF5C=QY(9R;[EMAIL
PROTECTED]
M+FUDB @(!P871T97)NRP@:6YS=5A9!O9B!UVEN9R!T:4@W1A;F1A
MF0@;EB8V%L;!M96-H86YI[EMAIL PROTECTED] 0 [EMAIL PROTECTED](P(LV.#[EMAIL
PROTECTED] *
M( DN96YD9G5N8PH@(V5N9EF(\J([EMAIL PROTECTED]%B;5J=6UP*2 J
M+PH@BTO*B!?7V1O7V-O'E?9%T82!IR!O;FQY(YE8V5SV%R2!I9B!T
M:5R92!IR!A;GET:EN9R!I;B N9%T82!S96-T:[EMAIL PROTECTED]( @1]ER!N
M;[EMAIL PROTECTED](%)!35!:([EMAIL
PROTECTED])T*BYO('!R;W9I95S($@F5P;%C96UE;G0@
M9F]R([EMAIL PROTECTED]5V:6-ERX@(HOBT*(-I9F1E9B!,7V-O'E?9%T80H@
M2YS96-T:6]N(YI;FET-[EMAIL PROTECTED]F]G8FETPH@2YG;[EMAIL PROTECTED]
M;U]C;W!Y7V1A=$*(%]?9]?8V]P[EMAIL PROTECTED](VEF(1E9FEN960H7U]!
M5E)?2$%615]%3%!-6%]?*0H@6QD:0ER,3L(AI.A?7V1A=%?96YD*0H@
M6QD:0ER,C8L(QO.A?7V1A=%?W1AG0IB );1I7(R-RP@:DX*%]?
M9%T85]S=%R=D*( EL9D)C,P+!L;[EMAIL PROTECTED]W1AG0I
MB );1I7(S,2P@:DX*%]?9%T85]L;V%D7W-T87)T*0HM7)J;7 )+F1O
M7V-O'E?9%T85]S=%R= HM+F1O7V-O'E?9%T85]L;[EMAIL PROTECTED]6QD:0ER
M,38L(AH.A?7V1A=%?;]A9%]S=%R=D**PEO=70)7U]204U06E]?+!R
M,38**PER:FUP2Y,7U]D;U]C;W!Y7V1A=%?W1AG0**RY,7U]D;U]C;W!Y
M7V1A=%?;]O#H**PEE;'!M7(P+!:*PHK7-T[EMAIL PROTECTED]!R, HK+DQ?7V1O
M7V-O'E?9%T85]S=%R=#H**PECD)C(V+!L;[EMAIL PROTECTED]D*
M*PEC,)C(W+!R,3**PEBFYE2Y,7U]D;U]C;W!Y7V1A=%?;]O HK
M(V5L:68@(%D969I;F5D*%]?05927TA!5D5?14Q035A?7RD@)[EMAIL PROTECTED]5F:6YE
M9A?7T%64E](059%7T5,4$U?7RD**PEL9D)C$W+!H:[EMAIL PROTECTED]
M9D**PEL9D)C(V+!L;[EMAIL PROTECTED])T*0HK6QD:0ER,CL(AI
M.A?7V1A=%?W1AG0IBL);1I7(S,P@;\X*%]?9%T85]L;V%D7W-T
M87)T*0HK6QD:0ER,S$L(AI.A?7V1A=%?;]A9%]S=%R=D**PEL9D)
MC$V+!H:[EMAIL PROTECTED]W1A[EMAIL PROTECTED] P#$P,# P*0HK+DQ?7V1O
M7V-O'E?9%T85]C87)R3H**PEI;F,)C$VBL);W5T5]?4D%-4%I?7RP@
MC$VBL)FIM DN3%]?9]?8V]P5]D871A7W-T87)TBLN3%]?9]?8V]P
M5]D871A7VQO;W ZBL)96QP;0HK7-T[EMAIL PROTECTED]!R, HK6%D:7)C,P+ Q
MBL)8G)CPDN3%]?9]?8V]P5]D871A7V-AG)YBLN3%]?9]?8V]P5]D
M871A7W-T87)[EMAIL PROTECTED]6-P:0ER,C8L(QO.A?7V1A=%?96YD*0HK6-P8PER
M,CL('(Q-PHK6)R;F4)+DQ?7V1O7V-O'E?9%T85]L;V]PBLC96QI9B A
M95F:6YE9A?7T%64E](059%7T5,4$U87U\I(8F(%D969I;F5D*%]?0592
M7TA!5D5?14Q035]?*0HK6QD:0ER,3L(AI.A?7V1A=%?96YD*0HK6QD
M:0ER,C8L(QO.A?7V1A=%?W1AG0IBL);1I7(R-RP@:DX*%]?9%T
M85]S=%R=D**PEL9D)C,P+!L;[EMAIL PROTECTED]W1AG0IBL)
M;1I7(S,2P@:DX*%]?9%T85]L;V%D7W-T87)T*0HK7)J;7 )+DQ?7V1O
M7V-O'E?9%T85]S=%R= HK+DQ?7V1O7V-O'E?9%T85]L;[EMAIL PROTECTED]@(VEF
M([EMAIL PROTECTED]@6QP;0ER,[EMAIL PROTECTED](-E
M;'-ED! (TW,#L,3 @*ST,BPQ,2! 0 H@6%D:7)C,P+ QB C96YD
M:68*( ES= E8*RP@C *+2YD;U]C;W!Y7V1A=%?W1AG0ZBLN3%]?9]?
M8V]P5]D871A7W-T87)[EMAIL PROTECTED]@6-P:0ER,C8L(QO.A?7V1A=%?96YD*0H@
M6-P8PER,CL('(Q-PHM6)R;F4)+F1O7V-O'E?9%T85]L;V]PBL)8G)N
M90DN3%]?9]?8V]P5]D871A7VQO;W **R-E;F1I9B O*B A95F:6YE9A?
M7T%64E](059%7T5,4$U87U\I(8F(%D969I;F5D*%]?05927TA!5D5?14Q0
M35]?*2 J+PH@(V5N9EF(\J($Q?8V]P5]D871A(HOB *(\J(%]?9]?
M8VQE87)?8G-S(ES(]N;'D@;F5C97-S87)Y(EF('1H97)E(ES(%N71H
9:6YG(EN(YBW,@V5C=EO;BX@(HO@``
`
end
begin 666 avr-libc-do_copy_data.txt
[EMAIL PROTECTED](-R=#$O9V-R=#$N4PH]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]
M/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]E)#
M4R!F:6QE.B OV]UF-ER]A=G(M;EB8R]A=G(M;EB8R]CG0Q+V=CG0Q
M+E,[EMAIL PROTECTED]:65V:6YG(')E=FES:6]N(#$N,3(*9EF9B M=2 MC$N,3(@
[EMAIL PROTECTED])T,2]G8W)T,2Y33(S($]C= R,# W(#$S.C,R.C$U
M(TP,# P3$N,3(**RLK(-R=#$O9V-R=#$N4PDR($9E8B R,# X(# T.C(R
M.C$T(TP,# PD! (TQ-38L-B K,34V+#@0$ *( EO=70)7U-4E])3U]!
M1$12*$5)3D0I+!R,38*(-E;[EMAIL PROTECTED])95$5?4$-?7R J
M+PH@BLC:[EMAIL PROTECTED]5F:6YE9A?7T=.54-?7RD@)[EMAIL
PROTECTED]A?7T=.54-?7R \/2 S
M*2!\? H7U]'3E5#7U\@/[EMAIL PROTECTED] F)B!?7T=.54-?34E.3U)?7R \/2 R*2D*
M(-I9B!24=?0T]$10H@2\J($]N;'[EMAIL PROTECTED]([EMAIL
PROTECTED]5V:6-ER!W:71H
M(%)!35!:+!R97!L86-ER!T:[EMAIL PROTECTED]5F875L=!C;V1EB )( @')O=FED
[EMAIL PROTECTED]@;EB9V-C+E,@=VAI8V@@:7,@;VYL2!L:6YK960@:6X@:68@;F5C
M97-S87)Y+B @*B\*0$ @+3$Y-RPV([EMAIL PROTECTED] 0 H@6-P8PER,CL('(Q
M-PH@6)R;F4)+DQ?7V1O7V-O'E?9%T85]L;V]PB C96YD:[EMAIL PROTECTED]@0DE'
M7T-/[EMAIL PROTECTED];F1I9B O*B!D969I;F5D*%]?1TY50U]?*2 F)B H*%]?
M1TY50U]?(#P](#,I('Q\(A?7T=.54-?7R ]/2 T(8F(%]?1TY50U]-24Y/
M4E]?(#P](#(I*2 J+PH@B )+G-E= E?7W-T86-K+!204U%3D0*(-E;F1I
:9B O*B A7U]!5E)?05--7T].3%E?7R J+PH`
`
end
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] testsuite saga continues
Wouter van Gulik wrote: [...] The next step will definitely be ELF loading support. With ELF loading, I can decode symbols like __bss_end to know where the stack overflows exactly or use __stack to know where the stack underflows. I can also do a more symbolic log, by decoding addresses to their symbol names. That would be very cool! Although a dump log at an abort might also be useful when debugging testcases. Can you elaborate on that? What exactly are you calling a dump log? Some more thoughts about the smaller avr's. I did not intend to catch wrong instruction, but I was aiming at finding bugs that are do not apply to the mega series. Because if there are bugs in the less capable devices, it's very likely to be in the avr backend, which is easier to fix. Can't avrtest/gcc fake a avr2 device (e.g. at90s8535) with tons of flash and ram? Just like you now fake huge amounts of external memory? That probably won't work because (IIRC) smaller parts don't have the JMP and CALL instructions and only have RJMP / RCALL, so they can't address a large flash in a natural way. One thing we could do is setup our own benchmark suite (not the testsuite) that could be used to test size / speed regressions in all architectures. This could also trigger failures if gcc started using invalid instructions for a particular architecture. We could then have a nice matrix with compiler version / optimization setting / architecture, to show regressions on every architecture we support. Thanks for the good work! You're welcome :) -- Paulo Marques Software Development Department - Grupo PIE, S.A. Phone: +351 252 290600, Fax: +351 252 290601 Web: www.grupopie.com Anything is possible, unless it's not. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
