[LLVMbugs] [Bug 18316] New: [powerpc-darwin][AsmPrinter] addis instruction expects 0 instead of r0

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Mon Dec 23 21:33:04 PST 2013


http://llvm.org/bugs/show_bug.cgi?id=18316

            Bug ID: 18316
           Summary: [powerpc-darwin][AsmPrinter] addis instruction expects
                    0 instead of r0
           Product: libraries
           Version: trunk
          Hardware: Macintosh
                OS: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: PowerPC
          Assignee: unassignedbugs at nondot.org
          Reporter: fang at csl.cornell.edu
                CC: hfinkel at anl.gov, iains-llvm at btconnect.com,
                    llvmbugs at cs.uiuc.edu, ulrich.weigand at de.ibm.com
    Classification: Unclassified

During my stage-2 build of powerpc-darwin8 clang, stage-1 clang was found to
emit some assembly that was rejected by the system assembler (including the
'as' from odcctools-2009).  

% cat addis.s 
    addis r30, 0, 1      ; OK
    addis r30, r1, 1     ; OK
    addis r30, r0, 1     : rejected

% as addis.s -o addis.o
addis.s:3:Parameter error: r0 not allowed for parameter 2 (code as 0 not r0)

Apparently, r0 is special enough to warrant different syntax in certain
contexts.  
Would it be possible to emit such instructions differently?

The PPC darwin asm parser, accepts all of the above:

% ~/local/src/LLVM-svn/gcc40-cmake-build/bin/llvm-mc -triple
powerpc-apple-darwin8 addis.s -filetype=obj -o addis.o

I don't mind keeping that as-is, but if you want tighter conformity, you could
mimic the darwin assembler behavior.  

I think it's more important to emit darwin-asm-friendly code so that
-no-integrated-as continues to work.

-- 
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/20131224/532371d5/attachment.html>


More information about the llvm-bugs mailing list