public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "avr at gjlay dot de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug inline-asm/37895] AVR inline assembly clobbers input value
Date: Sat, 06 Nov 2010 12:20:00 -0000	[thread overview]
Message-ID: <bug-37895-4-GHg9GGTokq@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-37895-4@http.gcc.gnu.org/bugzilla/>

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.


       reply	other threads:[~2010-11-06 12:20 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <bug-37895-4@http.gcc.gnu.org/bugzilla/>
2010-11-06 12:20 ` avr at gjlay dot de [this message]
2011-03-12 13:01 ` avr at gjlay dot de
2011-03-14 13:52 ` Rudolf.Leitgeb at gmx dot at
2011-03-14 14:14 ` eric.weddington at atmel dot com

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-37895-4-GHg9GGTokq@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).