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

[Klaus Pedersen <klaus.k.pedersen@nokia.com>]

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 15:25:54 +0100

 Looking at the code again. I think that there is a bug.
 
 >     for (i = 0; i < 25; i++)
 >       if ((val & (mask << i)) == val)
 >         break;
 > 
 >     if (i == 0)
 >       FAIL;
 
 Consider "val = 0x55", which can be represented as 0x55 << 0, but
 calling the function with this value causes the function FAIL to
 be called.
 
 On the other hand, FAIL isn't called when passing the constant 0x101, 
 which can't be represented, therefor I think that:
 
 >     if (i == 0)
 >       FAIL;
 
 should read:
 
 >     if (i == 25)
 >       FAIL;
 
 
 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.