[llvm-bugs] [Bug 45168] New: [inline assembly] "p" constraint is not always a valid address

via llvm-bugs llvm-bugs at lists.llvm.org
Tue Mar 10 11:06:43 PDT 2020


https://bugs.llvm.org/show_bug.cgi?id=45168

            Bug ID: 45168
           Summary: [inline assembly] "p" constraint is not always a valid
                    address
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Keywords: compile-fail, miscompilation
          Severity: normal
          Priority: P
         Component: Frontend
          Assignee: unassignedclangbugs at nondot.org
          Reporter: frederic.recoules at univ-grenoble-alpes.fr
                CC: llvm-bugs at lists.llvm.org, neeilans at live.com,
                    richard-llvm at metafoo.co.uk

Consider the following (useless) code:

int * f (int *p)
{
    __asm__ ("leal %a1, %0" : "=r" (p) : "p" (p));
    return p;
}

Which produces the following IR:

define dso_local i32* @f(i32* readnone) local_unnamed_addr #0 !dbg !8 {
  call void @llvm.dbg.value(metadata i32* %0, metadata !15, metadata
!DIExpression()), !dbg !16
  %2 = tail call i32* asm "leal ${1:a}, $0",
"=r,im,~{dirflag},~{fpsr},~{flags}"(i32* %0) #2, !dbg !17, !srcloc !18
  call void @llvm.dbg.value(metadata i32* %2, metadata !15, metadata
!DIExpression()), !dbg !16
  ret i32* %2, !dbg !19
}

We can see that "p" has been translated to "im". It is true from at least clang
3.0 to at least 9.0 (tested on https://godbolt.org/).
But "p" definition is "An operand that is a valid memory address is allowed.".
Correct me, but "m" is not a valid memory address as it is already a memory
access.
I think a non-optimal way to encode "p" would rather be "ir" as both constant
and register can be part of an address, but it would miss complex addresses
like "%ebp + 4 * %eax - 8".

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20200310/e847c745/attachment.html>


More information about the llvm-bugs mailing list