Ulrich, here's one of the workarounds I mentioned.  The other one is
pretty similar to this one as well.

After my investigation, I've come to the conclusion that this never
worked, and was not noticed before, because the optimizer mustn't
have ever used it before.

As such, it's appropriate to simply comment it out (which was my
"workaround").  However, before I do so, do you think this is close
to being correct?  I already made one correction, to put in that
XL1 rather than doing a fullword (which was always zero obviously).


(define_insn "movstrictqi"
 [(set (strict_low_part (match_operand:QI 0 "nonimmediate_operand" "+d"))
 (match_operand:QI 1 "general_operand" "g"))]
 ""
 "*
{
 check_label_emit ();
 if (REG_P (operands[1]))
   {
     mvs_check_page (0, 8, 0);
     return \"STC^I%1,\" CONVLO \"(,13)\;IC^I%0,\" CONVLO \"(,13)\";
   }
 mvs_check_page (0, 4, 0);
 return \"IC^I%0,=XL1'%X1'\";
}"
  [(set_attr "length" "8")]
)


The trouble is that when the instruction is active, things like this
happen:

C:\devel\gccnew\gcc>diff -c6 old\alias.s new\alias.s | head -50
*** old\alias.s Tue Sep 22 09:37:45 2009
--- new\alias.s Fri Sep 25 16:38:31 2009
***************
*** 277,290 ****
 L26      EQU   *
          N     2,=XL4'000000FF'
          LA    3,242(0,0)
          CR    2,3
          BE    L30
          BH    L45
!          LA    3,241(0,0)
!          CLR   2,3
          BE    L28
          B     L44
 L45      EQU   *
          LA    3,243(0,0)
          CLR   2,3
          BE    L37
--- 277,289 ----
 L26      EQU   *
          N     2,=XL4'000000FF'
          LA    3,242(0,0)
          CR    2,3
          BE    L30
          BH    L45
!          IC    3,=XL1'F1'
          BE    L28
          B     L44
 L45      EQU   *
          LA    3,243(0,0)
          CLR   2,3
          BE    L37

Which I can clearly see is different. Specifically, the IC by itself is fine,
although I would have preferred to see the LA instruction there, but for
some reason it is dropping the CLR.  That makes it technically
incorrect.

I checked the S/370 reference summary, and IC doesn't set the condition
code, and nor does the instruction pattern mention condition codes
anywhere.  Normally I would be suspicious of the rest of the compiler,
but in this case, I know that the compiler is stable and the i370
target is dubious.  :-)

After resolution of this one way or another, I think it's in a good enough
state for version 1.0 and will start on the preparations for all that.

BFN.  Paul.

Reply via email to