This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Patch for hppa64-*-* bad code generation bug. 3.4.*? 4.0.*?
- From: Steve Ellcey <sje at cup dot hp dot com>
- To: gcc-patches at gcc dot gnu dot org
- Cc: dave at hiauly1 dot hia dot nrc dot ca
- Date: Mon, 19 Sep 2005 14:14:00 -0700 (PDT)
- Subject: Patch for hppa64-*-* bad code generation bug. 3.4.*? 4.0.*?
- Reply-to: sje at cup dot hp dot com
Is it too late to check in bug fixes for 3.4.5 and/or 4.0.2? I was
building grep 2.5 using the 3.4.4 GCC compiler on hppa64-*-* and found a
bad codegen problem (platform specific to hppa). I haven't done a full
regression test yet, but assuming that I have no regressions, is the
following bug fix OK for the 3.4.*, 4.0.*, and mainline branches?
The problem is that when building grep GCC was generating a 32 bit
compare instead of a 64 bit compare and thus getting the wrong results.
This was because the zero compare hack that is in output_cbranch allowed
for const0_rtx as the first argument but not as the second argument.
2005-09-19 Steve Ellcey <sje@cup.hp.com>
* config/pa/pa.c (output_cbranch): Check for zero in operands[2].
*** gcc.orig/gcc/config/pa/pa.c Mon Sep 19 13:58:46 2005
--- gcc/gcc/config/pa/pa.c Mon Sep 19 13:58:21 2005
*************** output_cbranch (rtx *operands, int nulli
*** 6075,6080 ****
--- 6075,6082 ----
zero for cmpb, we must ensure that we use cmpb for the comparison. */
if (GET_MODE (operands[1]) == DImode && operands[2] == const0_rtx)
operands[2] = gen_rtx_REG (DImode, 0);
+ if (GET_MODE (operands[2]) == DImode && operands[1] == const0_rtx)
+ operands[1] = gen_rtx_REG (DImode, 0);
/* If this is a long branch with its delay slot unfilled, set `nullify'
as it can nullify the delay slot and save a nop. */