This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c/50219] New: Combine pass generated wrong code for unsigned char comparison on MIPS target
- From: "yaocang at gmail dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Sun, 28 Aug 2011 12:44:12 +0000
- Subject: [Bug c/50219] New: Combine pass generated wrong code for unsigned char comparison on MIPS target
- Auto-submitted: auto-generated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50219
Bug #: 50219
Summary: Combine pass generated wrong code for unsigned char
comparison on MIPS target
Classification: Unclassified
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned@gcc.gnu.org
ReportedBy: yaocang@gmail.com
Gcc3.4.4 generate wrong MIPS instructions for the codes following when using
-O1 and -O2.
int test(unsigned char a, int *b)
{
if(b==NULL)
return -1;
if(a>=0x01 && a<=0xaf)
{
*b++;
return 0;
}
else if(a<=0xfe)
return 1;
else
return 3;
return 4;
}
In assemble codes, (a>=0x01 && a<=0xaf) correspond to "add $8,$8,-1; sltui
$8,$8,-81 " .
According to MIPS instruction manual, "sltui $8,$8,-81 " means the value in $8
will be compared with the constant 0xFFFFFFAF. So when the variable "a" has a
value larger than 0xaf, but "sltui $8,$8,-81 " make the condition "(a>=0x01 &&
a<=0xaf)" hold, and the program flow go into if-body, and get wrong result.
It seems to me that when simplify_comparison combining tow rtl insn about the
if condition, zero_extend and ltu, the constant was signed-extended.
This problem doesn't occur in 2.96 and 4.3, other versions not tested.