target/5107: ICE when building an ARM/Thumb cross compiler for/on HP-UX.

[Klaus Pedersen]

The following reply was made to PR target/5107; it has been noted by GNATS.

From: Klaus Pedersen <klaus.k.pedersen@nokia.com>
To: Richard.Earnshaw@arm.com
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: target/5107: ICE when building an ARM/Thumb cross compiler  for/on 
 HP-UX.
Date: Mon, 17 Dec 2001 11:33:03 +0100

 Thanks a lot for tracking this down.
 
 Did you put the bug in gnats?
 
 The following program will provoke the error with "-O2", but runs 
 without error with "-O1" on HP PA:
 
 ---
 int main()
 {
     int operands[10] = {0, 65536};
     unsigned int val = operands[1];
     unsigned int mask = 0xff;
     int i;
     
     for (i = 0; i < 25; i++)
       if ((val & (mask << i)) == val)
         break;
 
     if (i == 0)
       puts("Fail");
 
     return 0;
 }
 ---
 
 Pretty frightening, that code this simple doesn't compile correctly!
 
 (Now I am looking forward to a emacs that doesn't crash!).
 
 BR, Klaus Pedersen
 
 
 ext Richard Earnshaw wrote:
 > 
 > Right, I've tracked this down to what I believe is the mis-compiled
 > function.
 > 
 > The arm.md file defines the split pattern
 > 
 > (define_split
 >   [(set (match_operand:SI 0 "register_operand" "")
 >         (match_operand:SI 1 "const_int_operand" ""))]
 >   "TARGET_THUMB && CONST_OK_FOR_THUMB_LETTER (INTVAL (operands[1]),
 > 'K')"
 >   [(set (match_dup 0) (match_dup 1))
 >    (set (match_dup 0) (ashift:SI (match_dup 0) (match_dup 2)))]
 >   "
 >   {
 >     unsigned HOST_WIDE_INT val = INTVAL (operands[1]);
 >     unsigned HOST_WIDE_INT mask = 0xff;
 >     int i;
 > 
 >     for (i = 0; i < 25; i++)
 >       if ((val & (mask << i)) == val)
 >         break;
 > 
 >     if (i == 0)
 >       FAIL;
 > 
 >     operands[1] = GEN_INT (val >> i);
 >     operands[2] = GEN_INT (i);
 >   }"
 > ...
 > 
 > With the current sources (as of 15/12/2001) this is gen_split_415().
 > 
 > The body of the for() loop in this pattern is never executing.
 > Consequently the "if (i == 0)" clause is true and the pattern fails.
 > Clearly this is incorrect behaviour when val is 65536.
 > 
 > You might be able to work around this problem by building the compiler
 > with a lower optimization level.  Try
 >         make all CFLAGS="-g".
 > 
 > So over the the pa maintainers.  Sorry, I don't know pa code well enough
 > 
 > to even begin to work out why this is failing.
 > 
 > R.