http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52474
--- Comment #4 from Georg-Johann Lay <gjl at gcc dot gnu.org> 2012-03-14 11:11:47 UTC --- Created attachment 26889 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26889 main.s: FSF Assembler output Here is the assembler output of the main mudule generated with $ avr-gcc -mmcu=atmega168 -S main.c -O2 -dp If you see the same code your problem is somewhere else. If you see different code for these options, the problem comes from non-FSF changes. As indicated in comment #0 there is a call to __mulhisi3 which is not present in the attached main.s and is not part of the FSF sources, see http://gcc.gnu.org/viewcvs/branches/gcc-4_5-branch/gcc/config/avr/avr.md?content-type=text%2Fplain&view=co __mulhisi3 is present in avr-gcc 4.7 but that implementation is from scratch and does not use __mulhisi3 patches floating around. (In reply to comment #3) > OK, so talking to the debian maintainer, the GCC version I'm using is based > upon patches available here: > > http://distribute.atmel.no/tools/opensource/avr-gcc/ > > Here is a test case. I'm unsure how to make a test case for code > to be executed on a microcontroller because I need to make some > assumptions about the board so that the result can be shown to > the user somehow (flash a LED, whatever...) Please, do not make assumptions on the hardware. The more assumptions you make the more artificial barriert you build up. Just can use exit and abort from stdlib.h to indicate the problem. If you want to avoid that GCC uses knowledge on functions, you can short __attribute__((noinline,noclone)) query (void) { return 0; }
