[Bug inline-asm/31693] New: Incorrectly assigned registers to operands for ARM inline asm

[Bug inline-asm/31693] New: Incorrectly assigned registers to operands for ARM inline asm

[siarhei dot siamashka at gmail dot com]

In the attached testcase, gcc assigns the same register to several inline asm
named operands resulting in incorrect code generated. Seems like names of
operands do matter ('c' and 'count' are assigned the same register but renaming
'c' operand to 'xxc' for example makes this bug disappear).


-- 
           Summary: Incorrectly assigned registers to operands for ARM
                    inline asm
           Product: gcc
           Version: 4.1.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: inline-asm
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: siarhei dot siamashka at gmail dot com
GCC target triplet: arm-softfloat-linux-gnueabi


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31693

[Bug inline-asm/31693] Incorrectly assigned registers to operands for ARM inline asm

[siarhei dot siamashka at gmail dot com]

------- Comment #1 from siarhei dot siamashka at gmail dot com  2007-04-25 07:26 -------
Created an attachment (id=13436)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13436&action=view)
testcase for this bug

Testcase attached


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31693

[Bug inline-asm/31693] Incorrectly assigned registers to operands for ARM inline asm

[siarhei dot siamashka at gmail dot com]

------- Comment #2 from siarhei dot siamashka at gmail dot com  2007-04-25 07:28 -------
This may be related to #31386


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31693

[Bug inline-asm/31693] Incorrectly assigned registers to operands for ARM inline asm

[mikpe at it dot uu dot se]

------- Comment #3 from mikpe at it dot uu dot se  2007-05-31 20:01 -------
I can confirm this broken behaviour, including that it disappears if the 'c'
variable is renamed to 'xxc', with gcc-3.3.6, 4.0.4, 4.1.2, and 4.2.0, all
running natively on an armv5b-softvfp-linux machine.


-- 

mikpe at it dot uu dot se changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mikpe at it dot uu dot se


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31693

[Bug inline-asm/31693] Incorrectly assigned registers to operands for ARM inline asm

[siarhei dot siamashka at gmail dot com]

------- Comment #4 from siarhei dot siamashka at gmail dot com  2008-05-13 12:32 -------
This bug is still present in gcc 4.3


-- 

siarhei dot siamashka at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to fail|                            |3.3.6 4.0.4 4.1.2 4.2.0
                   |                            |4.3.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31693

[Bug inline-asm/31693] Incorrectly assigned registers to operands for ARM inline asm

[siarhei dot siamashka at gmail dot com]

------- Comment #5 from siarhei dot siamashka at gmail dot com  2008-09-03 09:52 -------
I'm sorry, is anybody investigating this quite serious bug? If nobody has
time/motivation to do this work, would it make sense for me to try fixing it
myself and submit a patch here?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31693

[Bug inline-asm/31693] Incorrectly assigned registers to operands for ARM inline asm

[rearnsha at gcc dot gnu dot org]

------- Comment #6 from rearnsha at gcc dot gnu dot org  2009-02-10 14:36 -------
This is not a bug, but a problem with your source code.

In order to understand why, you need to pre-process the code and look at the
output:

...
void *memset_arm9(void *a, int b, int c)
{
  return ({ uint8_t *dst = ((uint8_t *)a); uint8_t c = (b); int count = (c);
uin
t32_t dummy0, dummy1, dummy2; __asm__ __volatile__ (

Notice that first there is a declaration of a variable c (uint8_t), then in the
next statement there is a use of c.  This use (which is intended to be of the
formal parameter passed to memset_arm9 is instead interpreted as the newly
declared variable c (the uint8 one).


Compiling your testcase with -Wshadow gives:

inl.c: In function 'memset_arm9':
inl.c:66: warning: declaration of 'c' shadows a parameter
inl.c:64: warning: shadowed declaration is here


-- 

rearnsha at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rearnsha at gcc dot gnu dot
                   |                            |org
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31693

[Bug inline-asm/31693] Incorrectly assigned registers to operands for ARM inline asm

[siarhei dot siamashka at gmail dot com]

------- Comment #7 from siarhei dot siamashka at gmail dot com  2009-02-10 15:11 -------
(In reply to comment #6)
> This is not a bug, but a problem with your source code.
> 
> In order to understand why, you need to pre-process the code and look at the
> output:
> 
> ...
> void *memset_arm9(void *a, int b, int c)
> {
>   return ({ uint8_t *dst = ((uint8_t *)a); uint8_t c = (b); int count = (c);
> uin
> t32_t dummy0, dummy1, dummy2; __asm__ __volatile__ (
> 
> Notice that first there is a declaration of a variable c (uint8_t), then in the
> next statement there is a use of c.  This use (which is intended to be of the
> formal parameter passed to memset_arm9 is instead interpreted as the newly
> declared variable c (the uint8 one).
> 
> 
> Compiling your testcase with -Wshadow gives:
> 
> inl.c: In function 'memset_arm9':
> inl.c:66: warning: declaration of 'c' shadows a parameter
> inl.c:64: warning: shadowed declaration is here

Thanks for having a look at this. Indeed, macros are quite dangerous.

Nevertheless, would it make sense to add this -Wshadow option into the set
provided by -Wextra, or even introduce something like -Wreally-all option
specifically for debugging such cases?

Even better (but understandably not realistic) would be to have an option to
show this warning only for the code which was expanded by C preprocessor in
order to reduce the number of false positives.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31693

[Bug inline-asm/31693] Incorrectly assigned registers to operands for ARM inline asm

[rearnsha at gcc dot gnu dot org]

------- Comment #8 from rearnsha at gcc dot gnu dot org  2009-02-10 15:21 -------
Opinions vary wildly as to which warnings should be on by default, and which
should be part of whatever bundle.

I personally agree that shadowing variables is generally bad practice, but you
then have to be wary when porting code because you can end up shadowing things
that come from a library (different standard libraries contain all sorts of
wild and wacky variables or functions, most of which you'll never care about). 
For example:

#include <stdio.h>

int f()
{
  int printf = 3; return printf;
}

will generate a warning if compiled with -Wshadow (ok, that's somewhat
perverse, since every library has printf, but it makes the point).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31693