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

            Bug ID: 30523
           Summary: [MIPS] Incorrectly extended registers for returning
                    unsigned short values.
           Product: compiler-rt
           Version: 3.9
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: compiler-rt
          Assignee: [email protected]
          Reporter: [email protected]
                CC: [email protected], [email protected],
                    [email protected]
    Classification: Unclassified

Created attachment 17348
  --> https://llvm.org/bugs/attachment.cgi?id=17348&action=edit
Attached a test which returns an unsigned short.

For a function which returns an unsigned short, clang generates a "move v0, a0"
where as gcc generates "andi v0, a0, 0xffff" for returning the unsigned short
value. Theres a function in dfsan which returns an unsigned short. When we
compiled this function using clang the caller of this function gets a wrong
return value because the value was not truncated to 16 bits before returning.
The same function when compiled using gcc worked as expected for the caller. I
have attached a reduced test which simply returns an unsigned short. We
compiled this test with O2 optimization level with both gcc and clang to get
the difference in the generated code.

Clang generated code :

foo:
    .frame    $sp,0,$ra
    .mask     0x00000000,0
    .fmask    0x00000000,0
    .set    noreorder
    .set    nomacro
    .set    noat
    jr    $ra
    move     $2, $4
    .set    at
    .set    macro
    .set    reorder
    .end    foo

Gcc generated code :

    .type    foo, @function
foo:
    .frame    $sp,0,$31        # vars= 0, regs= 0/0, args= 0, gp= 0
    .mask    0x00000000,0
    .fmask    0x00000000,0
    .set    noreorder
    .set    nomacro
    j    $31
    andi    $2,$4,0xffff

    .set    macro
    .set    reorder
    .end    foo

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
llvm-bugs mailing list
[email protected]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

Reply via email to