Re: [avr-gcc-list] Optimisation help
Magnus Johansson schreef: I totally get the second and third reads. But the first one, just moving r24 to r17 will only work if r24 is only 0x00 or 0x01 not otherwise...? What should I do? Well I can't see all assembler so this is a bit of a guess. GCC is probably going to do a conditional load. Since result/r17 could be loaded after the first call it will do so. So it will probably generate a clr and conditional ldi r17, 1 or something alike. It would help if you provide all of the assembler between the first and the second call. HTH Wouter ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] How to get low byte off a function address?
Erik Christiansen schreef: On Sat, Jan 19, 2008 at 04:15:35PM +0100, Wouter van Gulik wrote: How do I do such a thing? Using the lower 8 bits is possible when loading a register so why not in a table? In the past, we've encountered other relocations that aren't handled by the avr port of binutils. It does look like this is another case that avr-ld hasn't been tweaked to handle. It sounds like you've tried one work-around, i.e. loading a register, then writing to the table, now necessarily in RAM. That's workable, code space allowing. Ehm no not exactly. I am wondering why something like this works: ldi r31, lo8(gs(foo)) and this not: .byte lo8(gs(foo)) Why does as or ld (?) in the latter state it's not constant and the second is no problem? After some more testing I found out that constructions like: .byte lo8(1024) are not allowed. Is this a bug? The learning curve for binutils internals being a bit too steep for a quick toolchain tweak, I'd alternatively be tempted to invoke a few lines of awk (from the makefile) to snaffle the absolute addresses from the map file, insert them in the table, reassemble that file, and link again. (Pre-existing dummy .byte lines would ensure addresses don't move in flash.) That's perhaps worthwhile if you're chasing this either because a RAM-resident table, or the copy loop, is intolerable in the tiny bootloader. Granted, this comes close to winning an ugly contest, but it pretty much has to work(tm). If the file with the function pointer table is linked last, then the others can be incrementally linked, and the table file linked after being awked. I am not afraid of winning the contest. As long as it save flash I am in for it :D That would be an other option yes. An afterthought: You could alternatively put the foo() functions into a separate output section, allowing the linker script to place the block of them at a fixed address. (Each could in fact be placed in an individual section.) The table could in the latter case be filled with constants. (It's not real pretty either, is it?) Well, the whole idea was to have it constant. I wanted to reduce the big cpi/brne tree and so I came up with this reduced-size jump table idea. The table in the real application should also contain an opcode. So the idea was to check against opc and the ijmp/icall to the correct function. After I wrote the assembler it turned out to be 2 bytes shorter then my cpi/brne... But I thought it reads better and it is easier to extend the table. So I kept on trying, but no success yet. Hope you can help Hope some of the above does, at least a little. :-) Thanks anyway! Wouter ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] testsuite needs sys/types.h
Anyway, some tests in gcc.c-torture/execute/builtins fail because they are expecting a sys/types.h include file. I manually added a sys/types.h file to my avr-libc with just: #include inttypes.h #include stdint.h and the testsuite passed a lot more tests from this section. The question is: should libc provide this include or shouldn't the tests rely on it existing? Where should the correction be made? What does the standard say that sys/types.h should contain? If it's easy enough, we should see about adding it to avr-libc. It's much easier to get changes incorporated into avr-libc than it is to get them into gcc. The sys/*.h header files are a part of the Unix/Posix standards. They are not a part of any C standards. The Open Group Base Specifications Issue 6 IEEE Std 1003.1, 2004 Edition http://www.opengroup.org/onlinepubs/009695399/toc.htm sys/types.h: http://www.opengroup.org/onlinepubs/009695399/basedefs/sys/types.h.html You can also get the specification here if you register with them online: http://www.unix.org/version3/online.html -Preston ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
[avr-gcc-list] local variables in ddd
Hi everyone. I'm trying to simulate and trace a program developed with avr-gcc, but I'm not able to see the value of any local variable with ddd or avr-gdb. when I wrote print variable I obtain this: No symbol variable in current context. Anyone knows how to fix it? thanks -- Nunca confies en un S.O. del que no tienes código fuente ;-) Javier Almansa Sobrino. Ingeniero Técnico en Informática de Sistemas. Grupo de Investigación ARCo. Escuela Superior de Informática. Ciudad Real Tel: (+34)926 29 53 00 Ext: 3705 ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] local variables in ddd
It is possible that you have optimization turned on - so gcc will put variables into register. Or, perhaps your code has used variables it did not need and gcc will optimise them away. For example: int i for (i=0;i1000;i++); will dissappear. -O0 (or optimisation 0) will stop this but code will be huge. -O0 is ok for debugging, but for goodness sake use O2 or Os before release. No attempt is made at O0 to create anything pretty. -O3 and inline optimisation are very powerful and will rip out large chunks of code that don't do anything. If you think thi is not the reason, post copy of code with problem Andy Javier Almansa Sobrino wrote: Hi everyone. I'm trying to simulate and trace a program developed with avr-gcc, but I'm not able to see the value of any local variable with ddd or avr-gdb. when I wrote print variable I obtain this: No symbol variable in current context. Anyone knows how to fix it? thanks ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Optimisation help
Magnus Johansson [EMAIL PROTECTED] wrote: What should I do? Post the entire function's C code as well as the resulting assembly -- without the obfuscating .lss style. (I'd personally prefer seeing the generated assembly rather than the disassembled, but others might have a different opinion on that.) -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] More results from the testsuite with avrtest
The bug with PR27364 testcase appears recent.
It fails with my 4.3 experimental copy 13/12/2007
Ok with avr-gcc (GCC) 4.2.2 (WinAVR 20071221)
reduced testcase is:
long f2(long number_of_digits_to_use)
{
return ( number_of_digits_to_use * 11L ) ;
}
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Whetstone Benchmark
On Monday 21 January 2008 11:00, Weddington, Eric wrote: A couple of quick comments/suggestions: - Please drop -morder1. We generally don't recommend this to users, and it looks like it really doesn't affect the results that much - Can you also try with avr-gc 4.2.2 and avr-libc 1.6.1? These are the latest released versions. Flash Cycles Avr-gcc Options - -- --- -- 4296 888074.0.4 -Os 4484 808394.0.4 -O3 4030 885654.1.2 -Os 5332 717514.1.2 -O3 4194 892044.2.2 -Os 5388 726434.2.2 -O3 4350 869864.3.X -Os 5608 753514.3.X -O3 -fno-unit-at-a-time Regards, Dmitry. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
[avr-gcc-list] local variables in ddd
Hi everyone. I'm trying to simulate and trace a program developed with avr-gcc, but I'm not able to see the value of any local variable with ddd or avr-gdb. when I wrote print variable I obtain this: No symbol variable in current context. Anyone knows how to fix it? thanks -- Nunca confies en un S.O. del que no tienes código fuente ;-) Javier Almansa Sobrino. Ingeniero Técnico en Informática de Sistemas. Grupo de Investigación ARCo. Escuela Superior de Informática. Ciudad Real Tel: (+34)926 29 53 00 Ext: 3705 ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] More results from the testsuite with avrtest
Paulo, please report bug with PR27364 testcase. I found that problem is somewhere in combine phase. Here it is trying to stick together pairs of instruction to make another. It fails but that is where load of constant dissappears. So if you post bug, I can add further info. Andy PS running your simulator now. Found bug in AVRORA - dunno where but it failed some testcases. Your's is same speed. Sadly Cygwin does not like spawn. Hopefully, our numbers will match! ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] local variables in ddd
--- Javier Almansa Sobrino [EMAIL PROTECTED] wrote: Hi everyone. I'm trying to simulate and trace a program developed with avr-gcc, but I'm not able to see the value of any local variable with ddd or avr-gdb. This is a common problem that is not simply solved. gcc is optimizing your code to the point where the variable you are interested is no longer being stored in memory, this keeps ddd from looking at it. Some options: * Reduce gcc's optimization while debugging (be sure to turn it back on once the bugs are removed). * Mark the variable(s) you are interested in as volatile (again, make sure you un-do this later). * Add code to store important values in a volatile location: #ifdef DEBUG volatile uint16_t DebugTrace; #endif x = f(y); #ifdef DEBUG DebugTrace = x; #endif z = g(x); #ifdef DEBUG DebugTrace = z; #endif HTH, Gre7g __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] More results from the testsuite with avrtest
Quoting Andrew Hutchinson [EMAIL PROTECTED]: Here are my test results using Paulo simulator. Seems I have more tests! I'm now running from SVN, so I'm always testing the latest version, although my initial report was for gcc 4.2.2. One thing I noticed is that almost everyday there is a new test added to the testsuite. So, if we're running a svn version from a month ago, many tests may have entered, or may have been marked as unsuported in the meantime. I may have less failures as I did fix a bug I found while sorting out test patterns. The rest look the same as Paulo found. Ok, to try to synchronize with you, so that our tests are consistent, I'm running a test against svn revision 131704 (from today). Changes I've made so far to solve some of the failures: - created a sys/types.h with: #include inttypes.h #include stdint.h - changed ldflags definition in atmega128-sim.exp to: set_board_info ldflags /home/pmarques/dejagnuboards/exit.c -Wl,-u,vfprintf -lprintf_flt -Wl,-Tbss=0x802000,--defsym=__heap_end=0x80 the -Wl,-Tbss=0x802000,--defsym=__heap_end=0x80 part points the bss to external RAM, so that we have 4kb of just data + stack and 56k of BSS. This allows some of the tests that need a little more memory to run. - changed the stack size definition to half the internal RAM: set_board_info gcc,stack_size 2048 - already applied this patch to gcc.c-torture/execute/builtins/pr23484-chk.c: --- gcc/testsuite/gcc.c-torture/execute/builtins/pr23484-chk.c (revision 131704) +++ gcc/testsuite/gcc.c-torture/execute/builtins/pr23484-chk.c (working copy) @@ -41,8 +41,8 @@ abort (); memset (buf, 'L', sizeof (buf)); - if (snprintf (buf, l1 ? sizeof (buf) : 4, %d, l1 + 65536) != 5 - || memcmp (buf, 655\0, 8)) + if (snprintf (buf, l1 ? sizeof (buf) : 4, %d, l1 + 32760) != 5 + || memcmp (buf, 327\0, 8)) abort (); if (chk_calls) The result of running 'make -k check RUNTESTFLAGS=--target_board=atmega128-sim --all execute.exp' under these conditions is: === gcc Summary === # of expected passes11799 # of unexpected failures52 # of unresolved testcases 23 # of unsupported tests 682 /home/pmarques/Desktop/gcc-4.2.2/svn/obj/gcc/xgcc version 4.3.0 20080119 (experimental) (GCC) The tests that fail for me are: 20010122-1.c execution, -O0 20010122-1.c execution, -O1 20010122-1.c execution, -O2 20010122-1.c execution, -O3 -g 20010122-1.c execution, -Os built-in-setjmp.c execution, -O2 built-in-setjmp.c execution, -O3 -fomit-frame-pointer built-in-setjmp.c execution, -O3 -fomit-frame-pointer -funroll-loops built-in-setjmp.c execution, -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions built-in-setjmp.c execution, -O3 -g built-in-setjmp.c execution, -Os builtin-bitops-1.c compilation, -O0 builtin-bitops-1.c compilation, -O1 builtin-bitops-1.c compilation, -O2 builtin-bitops-1.c compilation, -O3 -fomit-frame-pointer builtin-bitops-1.c compilation, -O3 -fomit-frame-pointer -funroll-loops builtin-bitops-1.c compilation, -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions builtin-bitops-1.c compilation, -O3 -g builtin-bitops-1.c compilation, -Os ffs-1.c compilation, -O0 ffs-1.c compilation, -O1 ffs-1.c compilation, -O2 ffs-1.c compilation, -O3 -fomit-frame-pointer ffs-1.c compilation, -O3 -g ffs-1.c compilation, -Os ffs-2.c compilation, -O0 ffs-2.c compilation, -O1 ffs-2.c compilation, -O2 ffs-2.c compilation, -O3 -fomit-frame-pointer ffs-2.c compilation, -O3 -fomit-frame-pointer -funroll-loops ffs-2.c compilation, -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions ffs-2.c compilation, -O3 -g ffs-2.c compilation, -Os float-floor.c execution, -O0 float-floor.c execution, -O1 float-floor.c execution, -O2 float-floor.c execution, -O3 -fomit-frame-pointer float-floor.c execution, -O3 -g float-floor.c execution, -Os multi-ix.c compilation, -O0 pr17377.c execution, -O0 pr17377.c execution, -O1 pr17377.c execution, -O2 pr17377.c execution, -O3 -fomit-frame-pointer pr17377.c execution, -O3 -g pr17377.c execution, -Os pr22493-1.c execution, -O1 pr22493-1.c execution, -O2 pr22493-1.c execution, -Os pr27364.c execution, -O1 pr27364.c execution, -O2 pr27364.c execution, -Os Unresolved are all missing float function - or mmix? where data is to large (causes 8 unresolved) If you mean the missing __clzhi2, __ctzhi2, etc., these are bit operations that are missing from libgcc. Some of them might be used by the floating point emulation, though. Importantly, I looks like my other compiler patches work too! Great :) === gcc Summary === # of expected passes11663 # of unexpected failures59 # of unresolved testcases 30 # of unsupported tests 676 These numbers do look familiar, so there aren't probably much differences between our results. I've reported the
Re: [avr-gcc-list] More results from the testsuite with avrtest
Quoting Andrew Hutchinson [EMAIL PROTECTED]: The bug with PR27364 testcase appears recent. It fails with my 4.3 experimental copy 13/12/2007 Ok with avr-gcc (GCC) 4.2.2 (WinAVR 20071221) This got me thinking: it would be really nice if we could setup an automated bisection test. We could start with something like: - known good revision: 117923 (gcc4.2 branch) - known bad revision: 131704 This gives us 13781 revisions to test. By bisecting, we should be able to lock in on the offending patch in less than 14 attempts. A script that automated this bisection process (checkout middle revision, test it, mark good/bad) would be great to find what exectly caused specific regressions. I may give it a try tomorrow, -- Paulo Marques This message was sent using IMP, the Internet Messaging Program. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] More results from the testsuite with avrtest
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] org] On Behalf Of Paulo Marques Sent: Monday, January 21, 2008 5:15 PM To: Andrew Hutchinson Cc: avr-gcc-list@nongnu.org; Andy Hutchinson Subject: Re: [avr-gcc-list] More results from the testsuite with avrtest Quoting Andrew Hutchinson [EMAIL PROTECTED]: The bug with PR27364 testcase appears recent. It fails with my 4.3 experimental copy 13/12/2007 Ok with avr-gcc (GCC) 4.2.2 (WinAVR 20071221) This got me thinking: it would be really nice if we could setup an automated bisection test. We could start with something like: - known good revision: 117923 (gcc4.2 branch) - known bad revision: 131704 This gives us 13781 revisions to test. By bisecting, we should be able to lock in on the offending patch in less than 14 attempts. A script that automated this bisection process (checkout middle revision, test it, mark good/bad) would be great to find what exectly caused specific regressions. I may give it a try tomorrow, Please see the GCC project about this. IIRC, they already have a script that does a binary search on failing test cases. IIRC, it is in the contrib subdirectory. Eric Weddington ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] More results from the testsuite with avrtest
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] org] On Behalf Of Paulo Marques Sent: Monday, January 21, 2008 5:14 PM To: Andrew Hutchinson Cc: avr-gcc-list@nongnu.org Subject: Re: [avr-gcc-list] More results from the testsuite with avrtest One thing I noticed is that almost everyday there is a new test added to the testsuite. So, if we're running a svn version from a month ago, many tests may have entered, or may have been marked as unsuported in the meantime. I may have less failures as I did fix a bug I found while sorting out test patterns. The rest look the same as Paulo found. Ok, to try to synchronize with you, so that our tests are consistent, I'm running a test against svn revision 131704 (from today). Changes I've made so far to solve some of the failures: - created a sys/types.h with: #include inttypes.h #include stdint.h Note that adding inttypes.h *only* should be sufficient. inttypes.h automatically includes stdint.h. The result of running 'make -k check RUNTESTFLAGS=--target_board=atmega128-sim --all execute.exp' under these conditions is: === gcc Summary === # of expected passes11799 # of unexpected failures52 # of unresolved testcases 23 # of unsupported tests 682 /home/pmarques/Desktop/gcc-4.2.2/svn/obj/gcc/xgcc version 4.3.0 20080119 (experimental) (GCC) Paulo, Andy, I owe you guys a beer! :-) These numbers are fantastic! Eric Weddington ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] More results from the testsuite with avrtest
- created a sys/types.h with: #include inttypes.h #include stdint.h where do I put new include file? (directory relative to prefix root) I have updated my GCC to same rev as you. Ok with ldflags changes So hopefully I can re-run in sync with you. Andy ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] More results from the testsuite with avrtest
Quoting Weddington, Eric [EMAIL PROTECTED]: [...] Ok, to try to synchronize with you, so that our tests are consistent, I'm running a test against svn revision 131704 (from today). Changes I've made so far to solve some of the failures: - created a sys/types.h with: #include inttypes.h #include stdint.h Note that adding inttypes.h *only* should be sufficient. inttypes.h automatically includes stdint.h. I didn't really look into it. I'll probably look closer to the builtins.exp part of the testsuite to see why is sys/types.h needed. Maybe it isn't really needed at all and we can just fix it there. Or maybe it is needed and this quick hack isn't really providing what the testsuite is expecting. The result of running 'make -k check RUNTESTFLAGS=--target_board=atmega128-sim --all execute.exp' under these conditions is: === gcc Summary === # of expected passes11799 # of unexpected failures52 # of unresolved testcases 23 # of unsupported tests 682 /home/pmarques/Desktop/gcc-4.2.2/svn/obj/gcc/xgcc version 4.3.0 20080119 (experimental) (GCC) Paulo, Andy, I owe you guys a beer! :-) These numbers are fantastic! Thanks, but please bare in mind that these are the results for execute.exp alone. My latest result for the full testsuite is still: === gcc Summary === # of expected passes42683 # of unexpected failures574 # of unexpected successes 5 # of expected failures 89 # of unresolved testcases 248 # of untested testcases 64 # of unsupported tests 1250 /home/pmarques/Desktop/gcc-4.2.2/svn/obj/gcc/xgcc version 4.3.0 20080119 (experimental) (GCC) If we consider an average of 5 tests failed per source file (with different compilation options), we are still ~128 problems away from a total cleanup. That doesn't mean you can skip that beer, though. After all, a promise is a promise ;) -- Paulo Marques This message was sent using IMP, the Internet Messaging Program. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] More results from the testsuite with avrtest
-Original Message- From: Paulo Marques [mailto:[EMAIL PROTECTED] Sent: Monday, January 21, 2008 6:14 PM To: Weddington, Eric Cc: Andrew Hutchinson; avr-gcc-list@nongnu.org Subject: RE: [avr-gcc-list] More results from the testsuite with avrtest Thanks, but please bare in mind that these are the results for execute.exp alone. My latest result for the full testsuite is still: === gcc Summary === # of expected passes42683 # of unexpected failures574 # of unexpected successes 5 # of expected failures 89 # of unresolved testcases 248 # of untested testcases 64 # of unsupported tests 1250 /home/pmarques/Desktop/gcc-4.2.2/svn/obj/gcc/xgcc version 4.3.0 20080119 (experimental) (GCC) If we consider an average of 5 tests failed per source file (with different compilation options), we are still ~128 problems away from a total cleanup. This is still better. The last full testsuite run, on HEAD (future 4.3.0) was sent to the gcc-testresults list on October 26, 2007, by Mike Stein: http://gcc.gnu.org/ml/gcc-testresults/2007-10/msg01205.html Which shows: === gcc Summary === # of expected passes41563 # of unexpected failures715 # of unexpected successes 1 # of expected failures 95 # of unresolved testcases 287 # of untested testcases 65 # of unsupported tests 1200 /home/mstein/sim/avr/build/gcc/xgcc version 4.3.0 20071025 (experimental) [trunk revision 129634] (GCC) That doesn't mean you can skip that beer, though. After all, a promise is a promise ;) No worries. ;-D Eric Weddington ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] More results from the testsuite with avrtest
Ok my latest build is squawking - I assume because my binutils is out of step. ../../../../gcc/libgcc/../gcc/config/avr/libgcc.S:283: Error: illegal opcode mov w for mcu avr3 To make this painless, can someone please point me at correct sources for binutils - and assocated patch set (one that works with sources even :-P ) Andy Paulo Marques wrote: Quoting Weddington, Eric [EMAIL PROTECTED]: [...] Ok, to try to synchronize with you, so that our tests are consistent, I'm running a test against svn revision 131704 (from today). Changes I've made so far to solve some of the failures: - created a sys/types.h with: #include inttypes.h #include stdint.h Note that adding inttypes.h *only* should be sufficient. inttypes.h automatically includes stdint.h. I didn't really look into it. I'll probably look closer to the builtins.exp part of the testsuite to see why is sys/types.h needed. Maybe it isn't really needed at all and we can just fix it there. Or maybe it is needed and this quick hack isn't really providing what the testsuite is expecting. The result of running 'make -k check RUNTESTFLAGS=--target_board=atmega128-sim --all execute.exp' under these conditions is: === gcc Summary === # of expected passes11799 # of unexpected failures52 # of unresolved testcases 23 # of unsupported tests 682 /home/pmarques/Desktop/gcc-4.2.2/svn/obj/gcc/xgcc version 4.3.0 20080119 (experimental) (GCC) Paulo, Andy, I owe you guys a beer! :-) These numbers are fantastic! Thanks, but please bare in mind that these are the results for execute.exp alone. My latest result for the full testsuite is still: === gcc Summary === # of expected passes42683 # of unexpected failures574 # of unexpected successes 5 # of expected failures 89 # of unresolved testcases 248 # of untested testcases 64 # of unsupported tests 1250 /home/pmarques/Desktop/gcc-4.2.2/svn/obj/gcc/xgcc version 4.3.0 20080119 (experimental) (GCC) If we consider an average of 5 tests failed per source file (with different compilation options), we are still ~128 problems away from a total cleanup. That doesn't mean you can skip that beer, though. After all, a promise is a promise ;) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] More results from the testsuite with avrtest
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] org] On Behalf Of Andrew Hutchinson Sent: Monday, January 21, 2008 6:56 PM To: Paulo Marques; avr-gcc-list@nongnu.org Subject: Re: [avr-gcc-list] More results from the testsuite with avrtest Ok my latest build is squawking - I assume because my binutils is out of step. ../../../../gcc/libgcc/../gcc/config/avr/libgcc.S:283: Error: illegal opcode mov w for mcu avr3 To make this painless, can someone please point me at correct sources for binutils - and assocated patch set (one that works with sources even :-P ) Binutils 2.18. Patch set from WinAVR project's CVS on SourceForge (under patches module): http://winavr.cvs.sourceforge.net/winavr/ Note the README file under that module. Look under binutils/2.18 subdirectory. The patch filenames are numbered at the beginning, in categories (README file explains this). Patch in that order. You don't have to do the 0x patches (WinAVR specific), or the 1x patches (MinGW host specific, unless you're buildling for that host). Eric Weddington ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] More results from the testsuite with avrtest
Quoting Andrew Hutchinson [EMAIL PROTECTED]: - created a sys/types.h with: #include inttypes.h #include stdint.h where do I put new include file? (directory relative to prefix root) In Linux, the default dir is /usr/local/avr/include so the full path for the file becomes /usr/local/avr/include/sys/types.h I have updated my GCC to same rev as you. That was fast. Ok with ldflags changes So hopefully I can re-run in sync with you. Great. I'm really curious about the results, -- Paulo Marques This message was sent using IMP, the Internet Messaging Program. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] More results from the testsuite with avrtest
Quoting Weddington, Eric [EMAIL PROTECTED]: Ok my latest build is squawking - I assume because my binutils is out of step. ../../../../gcc/libgcc/../gcc/config/avr/libgcc.S:283: Error: illegal opcode mov w for mcu avr3 To make this painless, can someone please point me at correct sources for binutils - and assocated patch set (one that works with sources even :-P ) Binutils 2.18. Patch set from WinAVR project's CVS on SourceForge (under patches module): http://winavr.cvs.sourceforge.net/winavr/ Note the README file under that module. Look under binutils/2.18 subdirectory. The patch filenames are numbered at the beginning, in categories (README file explains this). Patch in that order. You don't have to do the 0x patches (WinAVR specific), or the 1x patches (MinGW host specific, unless you're buildling for that host). FWIW, I've been running my tests with binutils just plain 2.18. After reading this I decided to try and apply the patches, but at least for the execute.exp test it didn't make a difference in the results. -- Paulo Marques This message was sent using IMP, the Internet Messaging Program. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] More results from the testsuite with avrtest
Please see the GCC project about this. IIRC, they already have a script that does a binary search on failing test cases. IIRC, it is in the contrib subdirectory. Also this Delta implementation is very useful for minimizing an offending test program (either before or after narrowing settling on a version of gcc): http://delta.tigris.org/ John ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] More results from the testsuite with avrtest
-Original Message- From: John Regehr [mailto:[EMAIL PROTECTED] Sent: Monday, January 21, 2008 8:58 PM To: Weddington, Eric Cc: Paulo Marques; Andrew Hutchinson; avr-gcc-list@nongnu.org; Andy Hutchinson Subject: RE: [avr-gcc-list] More results from the testsuite with avrtest Please see the GCC project about this. IIRC, they already have a script that does a binary search on failing test cases. IIRC, it is in the contrib subdirectory. Also this Delta implementation is very useful for minimizing an offending test program (either before or after narrowing settling on a version of gcc): http://delta.tigris.org/ Very interesting tool! Thanks for the link! Eric W. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
