Re: middle-end/10475: [3.2/3.3/3.4 regression] ICE in subreg_highpart_offset for code with long long

http://gcc.gnu.org/PR10475

This happens when emit_store_flag() gets passed two long integers, the
2nd being 0 and the code being EQ or NE.

This call

/* If we are comparing a double-word integer with zero, we can convert
     the comparison into one involving a single word.  */
  if (GET_MODE_BITSIZE (mode) == BITS_PER_WORD * 2
      && GET_MODE_CLASS (mode) == MODE_INT
      && op1 == const0_rtx
      && (GET_CODE (op0) != MEM || ! MEM_VOLATILE_P (op0)))
    {
      if (code == EQ || code == NE)
        {
          /* Do a logical OR of the two words and compare the result.  * */
          rtx op0h = gen_highpart (word_mode, op0);
          rtx op0l = gen_lowpart (word_mode, op0);

to gen_highpart silently assumes that GET_MODE (op0) == mode. But
if op0 is CONST_INT, it has VOIDmode, of course.

The patch (against HEAD on 2003-05-21) below makes the ICE go away, but of
course one might want to do s.th. more intelligent with a comparison of
two integer constants...

(And another solution would of course be to teach gen_highpart () to
handle integer constants.)

Arend


Index: gcc/expmed.c
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/expmed.c,v
retrieving revision 1.133
diff -u -p -r1.133 expmed.c
--- gcc/expmed.c	21 Apr 2003 21:32:00 -0000	1.133
+++ gcc/expmed.c	21 May 2003 14:17:20 -0000
@@ -4350,7 +4350,8 @@ emit_store_flag (target, code, op0, op1,
   if (GET_MODE_BITSIZE (mode) == BITS_PER_WORD * 2
       && GET_MODE_CLASS (mode) == MODE_INT
       && op1 == const0_rtx
-      && (GET_CODE (op0) != MEM || ! MEM_VOLATILE_P (op0)))
+      && (GET_CODE (op0) != MEM || ! MEM_VOLATILE_P (op0))
+      && GET_CODE (op0) != CONST_INT)
     {
       if (code == EQ || code == NE)
 	{