This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug inline-asm/20718] New: "+r" constraint with uninitialized value
- From: "jakub at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 1 Apr 2005 16:39:50 -0000
- Subject: [Bug inline-asm/20718] New: "+r" constraint with uninitialized value
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
unsigned long foo (unsigned long *a, unsigned long *b,
unsigned long *c, int d)
{
unsigned long e, f;
if (d <= 0) return 0;
asm ("# registers %0 %1 %2 %3 %4 %5"
: "+a" (e),"+c" (d), "+r" (f)
: "r" (a), "r" (b), "r" (c));
return e;
}
at -O2 results in
# registers %rax %ecx %rdx %rdi %rsi %rdx
Note %2 and %5 being the same register, %rdx.
If f (and e) are initialized, both older GCCs and GCC4+ assign different
registers, but with unitialized values older GCCs seem to act as if "+r"
was instead "=&r" while GCC4+ treat it as "=r".
The library that used this (openssl) has been fixed to use "=&r" and "=&a"
instead, but I'd like to understand what is the desirable GCC behaviour
in this case. If it is undefined behaviour, so be it, but perhaps that
should be documented. Similarly if "r" (unitialized_var) among inputs means
GCC should allocate a unique register for that input or it doesn't have to.
--
Summary: "+r" constraint with uninitialized value
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: inline-asm
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org,rth at gcc dot gnu dot
org
GCC target triplet: x86_64-*-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20718