[llvm-bugs] [Bug 30523] New: [MIPS] Incorrectly extended registers for returning unsigned short values.
via llvm-bugs
llvm-bugs at lists.llvm.org
Mon Sep 26 01:24:15 PDT 2016
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: unassignedbugs at nondot.org
Reporter: sagar.thakur at imgtec.com
CC: llvm-bugs at lists.llvm.org, simon.dardis at imgtec.com,
Vasileios.Kalintiris at imgtec.com
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20160926/2d227d92/attachment.html>
More information about the llvm-bugs
mailing list