http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37895
Georg Lay <avr at gjlay dot de> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |avr at gjlay dot de,
| |Rudolf.Leitgeb at gmx dot
| |at
--- Comment #1 from Georg Lay <avr at gjlay dot de> 2010-11-06 12:20:27 UTC ---
(In reply to comment #0)
> I carefully followed the instructions how to write proper inline assembly for
Please not that no one will be able to reproduce this without a compileable
testcase and compiler options.
> Here's sample code, I tried to write a fast routine for multiplying a 16-bit
> number with an 8 bit number, the result would be written to a 32 bit number:
The snippet itself looks ok. However, the clobber are good for nothing except
confusing you or potential readers. R0 and R1 are fixed as per avr ABI so
clobbering them is useless. That's the reason why you have to write the final
CLR
> I get incorrect results. I believe this is the case because the "left"
> variable
> is assigned to the same registers as "result", and "left" is overwritten
> during
> the multiplication. According to several web pages the "=&r" (result)
> directive should prevent exactly this ....
Correct.
> Since the bug reporting guide explicitly discourages from posting assembly
> code
> generated by the compiler, I refrain from posting it here, although it might
> help clarify this issue. I will post it upon request, though :)
asm might be helpful here to explain, but exev more helpful would be the
source.
> Some extra information:
>
> I don't use plain vanilla avr gcc, but the win avr version: WinAVR 20071221,
> which is 4.2.2 plus some AVR specific patches (some bug fixes, extra device
> support). Please let me know, if gcc-bugzilla is the wrong address for these
> bugs!
Probably. There might be bugs that are introduced by some patches that are
incorporated in WinAVR but not in mainline avr-gcc, so claritying where a bug
originates is tedious and the first place to consult might be a place like
avrfreaks.net or mikrocontroller.net which are much more busy than this page.
