egcs-1.2 stuff

egcs-1.2 stuff

[Jeffrey A Law]

OK.  Now that egcs-1.1.2 is done, we need to start discussing the major
stuff that needs to be resolved for egcs-1.2.  My quick list:

	1. lcm.c tied into gcse.c -- Done internally at Cygnus, just need
	   to push the remaining bits into egcs

	2. fast-fixincludes -- basically needs testing and resolution of
	   any problems

	3. aligned stack slots for x86 -- patch submitted, needs final
	   review & install.

	4. EH vs unrolling problem -- patch submitted, needs final review
	   and install.

	5. unrolling & splittable GIVs problems -- needs to be analyzed and
	   fixed.

	6. Beat on the i18n support and make sure it's at least basically
	   working.

	7. Various bugs effecting glibc, the linux kernel, mips large frames,
	   etc etc.  Basically some major bug hunting sessions.
		
	8. Do we actually have the gcc include path stuff resolved?  Do we
	   want to suck in the code to allow the installed toolchain to move
	   around without the need for -B and/or GCC_EXEC_PREFIX?

	9. masked bitfield comparison issues reported by Charles Hannum

       10. Revamped cpp wrapper -- patch submitted.  Needs review
 
       11. Revamped install documentation (kill the various subdir install
	   stuff for a single install document for egcs).  Basically step 1
	   of the long term doc reorganization.

       12. New target issues (uwin, interix, hpux11, arm-vxworks, openbsd)

       13. --program-prefix fixes?

       14. SMP build fixes (particularly for chill & java)

       15. Testsuite legal issues need to be resolved.


I'm sure there's more.  I suspect once we've got a better list we'll have to
chop some stuff off to be able to make any kind of sane release schedule.

I've still got ~50 patches in my queue to review.  Much of it backlog from
concentrating on egcs-1.1.2 and Cygnus deliverables.

I'd like to get at least one additional person more closely involved in the
release process.  Someone to handle regression test coordination would be
good, as would someone to coordinate testing of major free software packages
would be a major win.



jeff

Re: egcs-1.2 stuff

[H.J. Lu]

> 
> 
> I'm sure there's more.  I suspect once we've got a better list we'll have to
> chop some stuff off to be able to make any kind of sane release schedule.
> 

How about PPro optimization?

-- 
H.J. Lu (hjl@gnu.org)

Re: egcs-1.2 stuff

[Jeffrey A Law]

  In message < m10O2Sm-000ErMC@ocean.lucon.org >you write:
  > > 
  > > 
  > > I'm sure there's more.  I suspect once we've got a better list we'll have
  >  to
  > > chop some stuff off to be able to make any kind of sane release schedule.
  > > 
  > 
  > How about PPro optimization?
Such as?

If it's not already basically done, then it probably won't get in.

jeff

Re: egcs-1.2 stuff

[H.J. Lu]

> 
> 
>   In message < m10O2Sm-000ErMC@ocean.lucon.org >you write:
>   > > 
>   > > 
>   > > I'm sure there's more.  I suspect once we've got a better list we'll have
>   >  to
>   > > chop some stuff off to be able to make any kind of sane release schedule.
>   > > 
>   > 
>   > How about PPro optimization?
> Such as?

I enabled all TARGET_CMOVE and CC_FCOMI. I also optimized the fp
cmove.

> 
> If it's not already basically done, then it probably won't get in.
> 

What do you mean by that? I sent in patches months ago and you said
you would take a look. What happened?

Also you wanted a patch to remove gxx_include_dir from the top level
configure. I sent you one and I never saw it in egcs.


-- 
H.J. Lu (hjl@gnu.org)

Re: egcs-1.2 stuff

[Jeffrey A Law]

  In message < m10O2ic-000ErMC@ocean.lucon.org >you write:
  > I enabled all TARGET_CMOVE and CC_FCOMI. I also optimized the fp
  > cmove.
  > 
  > What do you mean by that? I sent in patches months ago and you said
  > you would take a look. What happened?
The FCOMI stuff I explicitly left with you and John to sort out.  Last I
heard there were still technical problems with that patch.  If you and John
think the patch is done, then send the final patch.

  > Also you wanted a patch to remove gxx_include_dir from the top level
  > configure. I sent you one and I never saw it in egcs.
I'm quite busy.  That stuff fell behind egcs-1.1.2.  It's in the queue.

jeff

Re: egcs-1.2 stuff

[H.J. Lu]

> 
> 
> 
>   In message < m10O2ic-000ErMC@ocean.lucon.org >you write:
>   > I enabled all TARGET_CMOVE and CC_FCOMI. I also optimized the fp
>   > cmove.
>   > 
>   > What do you mean by that? I sent in patches months ago and you said
>   > you would take a look. What happened?
> The FCOMI stuff I explicitly left with you and John to sort out.  Last I
> heard there were still technical problems with that patch.  If you and John
> think the patch is done, then send the final patch.
> 

This is the latest patch I have been using. It seems ok.


H.J.
----
Mon Jan 11 20:02:56 1999  H.J. Lu  (hjl@gnu.org)

	* config/i386/i386.c (notice_update_cc): No need to check the
	INT mode for conditional moves since FLOAT conditional moves
	don't affect cc0.
	(output_fp_conditional_move): Abort for LT, LE, GE, and GT
	signed integer comparisons.
	(output_int_conditional_move): Use "enum rtx_code" for code
	type.
	(output_fp_cc0_set): Don't check the JUMP_INSN code for
	conditional move.

	* config/i386/i386.c (notice_update_cc, output_float_compare):
	Enable TARGET_CMOVE support.

	* config/i386/i386.c (output_float_compare): Fix the FLOAT
	comparison for IEEE math and CC_FCOMI.

--- ../../../import/egcs/gcc/config/i386/i386.c	Wed Jul 29 07:35:38 1998
+++ config/i386/i386.c	Mon Jan 11 17:15:57 1999
@@ -3646,8 +3646,7 @@ notice_update_cc (exp)
       if (REG_P (SET_DEST (exp))
 	  && (REG_P (SET_SRC (exp)) || GET_CODE (SET_SRC (exp)) == MEM
 	      || GET_RTX_CLASS (GET_CODE (SET_SRC (exp))) == '<'
-	      || (GET_CODE (SET_SRC (exp)) == IF_THEN_ELSE
-		  && GET_MODE_CLASS (GET_MODE (SET_DEST (exp))) == MODE_INT)))
+	      || GET_CODE (SET_SRC (exp)) == IF_THEN_ELSE))
 	{
 	  if (cc_status.value1
 	      && reg_overlap_mentioned_p (SET_DEST (exp), cc_status.value1))
@@ -3749,7 +3748,7 @@ notice_update_cc (exp)
           if (stack_regs_mentioned_p (SET_SRC (XVECEXP (exp, 0, 0))))
 	    {
               cc_status.flags |= CC_IN_80387;
-	      if (0 && TARGET_CMOVE && stack_regs_mentioned_p
+	      if (TARGET_CMOVE && stack_regs_mentioned_p
 		  (XEXP (SET_SRC (XVECEXP (exp, 0, 0)), 1)))
 		cc_status.flags |= CC_FCOMI;
 	    }
@@ -4079,7 +4078,7 @@ output_float_compare (insn, operands)
   int unordered_compare = GET_MODE (SET_SRC (body)) == CCFPEQmode;
   rtx tmp;
 
-  if (0 && TARGET_CMOVE && STACK_REG_P (operands[1]))
+  if (TARGET_CMOVE && STACK_REG_P (operands[1]))
     {
       cc_status.flags |= CC_FCOMI;
       cc_prev_status.flags &= ~CC_TEST_AX;
@@ -4113,7 +4112,8 @@ output_float_compare (insn, operands)
 	    {
 	      output_asm_insn (AS2 (fucomip,%y1,%0), operands);
 	      output_asm_insn (AS1 (fstp, %y0), operands);
-	      return "";
+	      if (!TARGET_IEEE_FP)
+		return "";
 	    }
 	  else
 	    output_asm_insn ("fucompp", operands);
@@ -4124,7 +4124,8 @@ output_float_compare (insn, operands)
 	    {
 	      output_asm_insn (AS2 (fcomip, %y1,%0), operands);
 	      output_asm_insn (AS1 (fstp, %y0), operands);
-	      return "";
+	      if (!TARGET_IEEE_FP)
+		return "";
 	    }
 	  else
 	    output_asm_insn ("fcompp", operands);
@@ -4154,7 +4155,8 @@ output_float_compare (insn, operands)
       else if (cc_status.flags & CC_FCOMI)
 	{
 	  output_asm_insn (strcat (buf, AS2 (%z1,%y1,%0)), operands);
-	  return "";
+	  if (!TARGET_IEEE_FP)
+	    return "";
 	}
       else
         output_asm_insn (strcat (buf, AS1 (%z1,%y1)), operands);
@@ -4178,17 +4180,19 @@ output_fp_cc0_set (insn)
   rtx next;
   enum rtx_code code;
 
-  xops[0] = gen_rtx_REG (HImode, 0);
-  output_asm_insn (AS1 (fnsts%W0,%0), xops);
+  if (!(cc_status.flags & CC_FCOMI))
+    {
+      xops[0] = gen_rtx_REG (HImode, 0);
+      output_asm_insn (AS1 (fnsts%W0,%0), xops);
+    }
 
   if (! TARGET_IEEE_FP)
     {
       if (!(cc_status.flags & CC_REVERSED))
         {
           next = next_cc0_user (insn);
-
-          if (GET_CODE (next) == JUMP_INSN
-              && GET_CODE (PATTERN (next)) == SET
+  
+          if (GET_CODE (PATTERN (next)) == SET
               && SET_DEST (PATTERN (next)) == pc_rtx
               && GET_CODE (SET_SRC (PATTERN (next))) == IF_THEN_ELSE)
 	    code = GET_CODE (XEXP (SET_SRC (PATTERN (next)), 0));
@@ -4213,8 +4217,7 @@ output_fp_cc0_set (insn)
   if (next == NULL_RTX)
     abort ();
 
-  if (GET_CODE (next) == JUMP_INSN
-      && GET_CODE (PATTERN (next)) == SET
+  if (GET_CODE (PATTERN (next)) == SET
       && SET_DEST (PATTERN (next)) == pc_rtx
       && GET_CODE (SET_SRC (PATTERN (next))) == IF_THEN_ELSE)
     code = GET_CODE (XEXP (SET_SRC (PATTERN (next)), 0));
@@ -4237,61 +4240,103 @@ output_fp_cc0_set (insn)
   else
     abort ();
 
-  xops[0] = gen_rtx_REG (QImode, 0);
+  if (cc_status.flags & CC_FCOMI)
+    {
+      /* It is very tricky. We have to do it right. */
 
-  switch (code)
+      xops [0] = gen_rtx_REG (QImode, 0);
+
+      switch (code)
+	{
+	case GT:
+	case GE:
+	  break;
+
+	case LT:
+	  output_asm_insn (AS1 (setb,%b0), xops);
+	  output_asm_insn (AS1 (setp,%h0), xops);
+	  output_asm_insn (AS2 (cmp%B0,%b0,%h0), xops);
+	  break;
+
+	case LE:
+	  output_asm_insn (AS1 (setbe,%b0), xops);
+	  output_asm_insn (AS1 (setnp,%h0), xops);
+	  output_asm_insn (AS2 (xor%B0,%b0,%h0), xops);
+	  break;
+
+	case EQ:
+	case NE:
+	  output_asm_insn (AS1 (setne,%b0), xops);
+	  output_asm_insn (AS1 (setp,%h0), xops);
+	  output_asm_insn (AS2 (or%B0,%b0,%h0), xops);
+	  break;
+
+	case GTU:
+	case LTU:
+	case GEU:
+	case LEU:
+	default:
+	  abort ();
+	}
+    }
+  else
     {
-    case GT:
-      xops[1] = GEN_INT (0x45);
-      output_asm_insn (AS2 (and%B0,%1,%h0), xops);
-      /* je label */
-      break;
+      xops[0] = gen_rtx_REG (QImode, 0);
 
-    case LT:
-      xops[1] = GEN_INT (0x45);
-      xops[2] = GEN_INT (0x01);
-      output_asm_insn (AS2 (and%B0,%1,%h0), xops);
-      output_asm_insn (AS2 (cmp%B0,%2,%h0), xops);
-      /* je label */
-      break;
+      switch (code)
+	{
+	case GT:
+	  xops[1] = GEN_INT (0x45);
+	  output_asm_insn (AS2 (and%B0,%1,%h0), xops);
+	  /* je label */
+	  break;
 
-    case GE:
-      xops[1] = GEN_INT (0x05);
-      output_asm_insn (AS2 (and%B0,%1,%h0), xops);
-      /* je label */
-      break;
+	case LT:
+	  xops[1] = GEN_INT (0x45);
+	  xops[2] = GEN_INT (0x01);
+	  output_asm_insn (AS2 (and%B0,%1,%h0), xops);
+	  output_asm_insn (AS2 (cmp%B0,%2,%h0), xops);
+	  /* je label */
+	  break;
 
-    case LE:
-      xops[1] = GEN_INT (0x45);
-      xops[2] = GEN_INT (0x40);
-      output_asm_insn (AS2 (and%B0,%1,%h0), xops);
-      output_asm_insn (AS1 (dec%B0,%h0), xops);
-      output_asm_insn (AS2 (cmp%B0,%2,%h0), xops);
-      /* jb label */
-      break;
+	case GE:
+	  xops[1] = GEN_INT (0x05);
+	  output_asm_insn (AS2 (and%B0,%1,%h0), xops);
+	  /* je label */
+	  break;
 
-    case EQ:
-      xops[1] = GEN_INT (0x45);
-      xops[2] = GEN_INT (0x40);
-      output_asm_insn (AS2 (and%B0,%1,%h0), xops);
-      output_asm_insn (AS2 (cmp%B0,%2,%h0), xops);
-      /* je label */
-      break;
+	case LE:
+	  xops[1] = GEN_INT (0x45);
+	  xops[2] = GEN_INT (0x40);
+	  output_asm_insn (AS2 (and%B0,%1,%h0), xops);
+	  output_asm_insn (AS1 (dec%B0,%h0), xops);
+	  output_asm_insn (AS2 (cmp%B0,%2,%h0), xops);
+	  /* jb label */
+	  break;
 
-    case NE:
-      xops[1] = GEN_INT (0x44);
-      xops[2] = GEN_INT (0x40);
-      output_asm_insn (AS2 (and%B0,%1,%h0), xops);
-      output_asm_insn (AS2 (xor%B0,%2,%h0), xops);
-      /* jne label */
-      break;
+	case EQ:
+	  xops[1] = GEN_INT (0x45);
+	  xops[2] = GEN_INT (0x40);
+	  output_asm_insn (AS2 (and%B0,%1,%h0), xops);
+	  output_asm_insn (AS2 (cmp%B0,%2,%h0), xops);
+	  /* je label */
+	  break;
 
-    case GTU:
-    case LTU:
-    case GEU:
-    case LEU:
-    default:
-      abort ();
+	case NE:
+	  xops[1] = GEN_INT (0x44);
+	  xops[2] = GEN_INT (0x40);
+	  output_asm_insn (AS2 (and%B0,%1,%h0), xops);
+	  output_asm_insn (AS2 (xor%B0,%2,%h0), xops);
+	  /* jne label */
+	  break;
+
+	case GTU:
+	case LTU:
+	case GEU:
+	case LEU:
+	default:
+	  abort ();
+	}
     }
 
   return "";
@@ -5196,6 +5241,13 @@ output_fp_conditional_move (which_altern
      int which_alternative;
      rtx operands[];
 {
+  enum rtx_code code = GET_CODE (operands[1]);
+
+  /* It should never happen. */
+  if (!(cc_prev_status.flags & CC_IN_80387)
+      && (code == GT || code == LE || code == GE || code == LT))
+    abort ();
+
   switch (which_alternative)
     {
     case 0:
@@ -5226,7 +5272,7 @@ output_int_conditional_move (which_alter
      int which_alternative;
      rtx operands[];
 {
-  int code = GET_CODE (operands[1]);
+  enum rtx_code code = GET_CODE (operands[1]);
   enum machine_mode mode;
   rtx xops[4];
 

Re: egcs-1.2 stuff

[H.J. Lu]

> 
> 
> 
>   In message < m10O2ic-000ErMC@ocean.lucon.org >you write:
>   > I enabled all TARGET_CMOVE and CC_FCOMI. I also optimized the fp
>   > cmove.
>   > 
>   > What do you mean by that? I sent in patches months ago and you said
>   > you would take a look. What happened?
> The FCOMI stuff I explicitly left with you and John to sort out.  Last I
> heard there were still technical problems with that patch.  If you and John
> think the patch is done, then send the final patch.
> 

This is the latest patch I have been using. It seems ok.


H.J.
----
Mon Jan 11 20:02:56 1999  H.J. Lu  (hjl@gnu.org)

	* config/i386/i386.c (notice_update_cc): No need to check the
	INT mode for conditional moves since FLOAT conditional moves
	don't affect cc0.
	(output_fp_conditional_move): Abort for LT, LE, GE, and GT
	signed integer comparisons.
	(output_int_conditional_move): Use "enum rtx_code" for code
	type.
	(output_fp_cc0_set): Don't check the JUMP_INSN code for
	conditional move.

	* config/i386/i386.c (notice_update_cc, output_float_compare):
	Enable TARGET_CMOVE support.

	* config/i386/i386.c (output_float_compare): Fix the FLOAT
	comparison for IEEE math and CC_FCOMI.

--- ../../../import/egcs/gcc/config/i386/i386.c	Wed Jul 29 07:35:38 1998
+++ config/i386/i386.c	Mon Jan 11 17:15:57 1999
@@ -3646,8 +3646,7 @@ notice_update_cc (exp)
       if (REG_P (SET_DEST (exp))
 	  && (REG_P (SET_SRC (exp)) || GET_CODE (SET_SRC (exp)) == MEM
 	      || GET_RTX_CLASS (GET_CODE (SET_SRC (exp))) == '<'
-	      || (GET_CODE (SET_SRC (exp)) == IF_THEN_ELSE
-		  && GET_MODE_CLASS (GET_MODE (SET_DEST (exp))) == MODE_INT)))
+	      || GET_CODE (SET_SRC (exp)) == IF_THEN_ELSE))
 	{
 	  if (cc_status.value1
 	      && reg_overlap_mentioned_p (SET_DEST (exp), cc_status.value1))
@@ -3749,7 +3748,7 @@ notice_update_cc (exp)
           if (stack_regs_mentioned_p (SET_SRC (XVECEXP (exp, 0, 0))))
 	    {
               cc_status.flags |= CC_IN_80387;
-	      if (0 && TARGET_CMOVE && stack_regs_mentioned_p
+	      if (TARGET_CMOVE && stack_regs_mentioned_p
 		  (XEXP (SET_SRC (XVECEXP (exp, 0, 0)), 1)))
 		cc_status.flags |= CC_FCOMI;
 	    }
@@ -4079,7 +4078,7 @@ output_float_compare (insn, operands)
   int unordered_compare = GET_MODE (SET_SRC (body)) == CCFPEQmode;
   rtx tmp;
 
-  if (0 && TARGET_CMOVE && STACK_REG_P (operands[1]))
+  if (TARGET_CMOVE && STACK_REG_P (operands[1]))
     {
       cc_status.flags |= CC_FCOMI;
       cc_prev_status.flags &= ~CC_TEST_AX;
@@ -4113,7 +4112,8 @@ output_float_compare (insn, operands)
 	    {
 	      output_asm_insn (AS2 (fucomip,%y1,%0), operands);
 	      output_asm_insn (AS1 (fstp, %y0), operands);
-	      return "";
+	      if (!TARGET_IEEE_FP)
+		return "";
 	    }
 	  else
 	    output_asm_insn ("fucompp", operands);
@@ -4124,7 +4124,8 @@ output_float_compare (insn, operands)
 	    {
 	      output_asm_insn (AS2 (fcomip, %y1,%0), operands);
 	      output_asm_insn (AS1 (fstp, %y0), operands);
-	      return "";
+	      if (!TARGET_IEEE_FP)
+		return "";
 	    }
 	  else
 	    output_asm_insn ("fcompp", operands);
@@ -4154,7 +4155,8 @@ output_float_compare (insn, operands)
       else if (cc_status.flags & CC_FCOMI)
 	{
 	  output_asm_insn (strcat (buf, AS2 (%z1,%y1,%0)), operands);
-	  return "";
+	  if (!TARGET_IEEE_FP)
+	    return "";
 	}
       else
         output_asm_insn (strcat (buf, AS1 (%z1,%y1)), operands);
@@ -4178,17 +4180,19 @@ output_fp_cc0_set (insn)
   rtx next;
   enum rtx_code code;
 
-  xops[0] = gen_rtx_REG (HImode, 0);
-  output_asm_insn (AS1 (fnsts%W0,%0), xops);
+  if (!(cc_status.flags & CC_FCOMI))
+    {
+      xops[0] = gen_rtx_REG (HImode, 0);
+      output_asm_insn (AS1 (fnsts%W0,%0), xops);
+    }
 
   if (! TARGET_IEEE_FP)
     {
       if (!(cc_status.flags & CC_REVERSED))
         {
           next = next_cc0_user (insn);
-
-          if (GET_CODE (next) == JUMP_INSN
-              && GET_CODE (PATTERN (next)) == SET
+  
+          if (GET_CODE (PATTERN (next)) == SET
               && SET_DEST (PATTERN (next)) == pc_rtx
               && GET_CODE (SET_SRC (PATTERN (next))) == IF_THEN_ELSE)
 	    code = GET_CODE (XEXP (SET_SRC (PATTERN (next)), 0));
@@ -4213,8 +4217,7 @@ output_fp_cc0_set (insn)
   if (next == NULL_RTX)
     abort ();
 
-  if (GET_CODE (next) == JUMP_INSN
-      && GET_CODE (PATTERN (next)) == SET
+  if (GET_CODE (PATTERN (next)) == SET
       && SET_DEST (PATTERN (next)) == pc_rtx
       && GET_CODE (SET_SRC (PATTERN (next))) == IF_THEN_ELSE)
     code = GET_CODE (XEXP (SET_SRC (PATTERN (next)), 0));
@@ -4237,61 +4240,103 @@ output_fp_cc0_set (insn)
   else
     abort ();
 
-  xops[0] = gen_rtx_REG (QImode, 0);
+  if (cc_status.flags & CC_FCOMI)
+    {
+      /* It is very tricky. We have to do it right. */
 
-  switch (code)
+      xops [0] = gen_rtx_REG (QImode, 0);
+
+      switch (code)
+	{
+	case GT:
+	case GE:
+	  break;
+
+	case LT:
+	  output_asm_insn (AS1 (setb,%b0), xops);
+	  output_asm_insn (AS1 (setp,%h0), xops);
+	  output_asm_insn (AS2 (cmp%B0,%b0,%h0), xops);
+	  break;
+
+	case LE:
+	  output_asm_insn (AS1 (setbe,%b0), xops);
+	  output_asm_insn (AS1 (setnp,%h0), xops);
+	  output_asm_insn (AS2 (xor%B0,%b0,%h0), xops);
+	  break;
+
+	case EQ:
+	case NE:
+	  output_asm_insn (AS1 (setne,%b0), xops);
+	  output_asm_insn (AS1 (setp,%h0), xops);
+	  output_asm_insn (AS2 (or%B0,%b0,%h0), xops);
+	  break;
+
+	case GTU:
+	case LTU:
+	case GEU:
+	case LEU:
+	default:
+	  abort ();
+	}
+    }
+  else
     {
-    case GT:
-      xops[1] = GEN_INT (0x45);
-      output_asm_insn (AS2 (and%B0,%1,%h0), xops);
-      /* je label */
-      break;
+      xops[0] = gen_rtx_REG (QImode, 0);
 
-    case LT:
-      xops[1] = GEN_INT (0x45);
-      xops[2] = GEN_INT (0x01);
-      output_asm_insn (AS2 (and%B0,%1,%h0), xops);
-      output_asm_insn (AS2 (cmp%B0,%2,%h0), xops);
-      /* je label */
-      break;
+      switch (code)
+	{
+	case GT:
+	  xops[1] = GEN_INT (0x45);
+	  output_asm_insn (AS2 (and%B0,%1,%h0), xops);
+	  /* je label */
+	  break;
 
-    case GE:
-      xops[1] = GEN_INT (0x05);
-      output_asm_insn (AS2 (and%B0,%1,%h0), xops);
-      /* je label */
-      break;
+	case LT:
+	  xops[1] = GEN_INT (0x45);
+	  xops[2] = GEN_INT (0x01);
+	  output_asm_insn (AS2 (and%B0,%1,%h0), xops);
+	  output_asm_insn (AS2 (cmp%B0,%2,%h0), xops);
+	  /* je label */
+	  break;
 
-    case LE:
-      xops[1] = GEN_INT (0x45);
-      xops[2] = GEN_INT (0x40);
-      output_asm_insn (AS2 (and%B0,%1,%h0), xops);
-      output_asm_insn (AS1 (dec%B0,%h0), xops);
-      output_asm_insn (AS2 (cmp%B0,%2,%h0), xops);
-      /* jb label */
-      break;
+	case GE:
+	  xops[1] = GEN_INT (0x05);
+	  output_asm_insn (AS2 (and%B0,%1,%h0), xops);
+	  /* je label */
+	  break;
 
-    case EQ:
-      xops[1] = GEN_INT (0x45);
-      xops[2] = GEN_INT (0x40);
-      output_asm_insn (AS2 (and%B0,%1,%h0), xops);
-      output_asm_insn (AS2 (cmp%B0,%2,%h0), xops);
-      /* je label */
-      break;
+	case LE:
+	  xops[1] = GEN_INT (0x45);
+	  xops[2] = GEN_INT (0x40);
+	  output_asm_insn (AS2 (and%B0,%1,%h0), xops);
+	  output_asm_insn (AS1 (dec%B0,%h0), xops);
+	  output_asm_insn (AS2 (cmp%B0,%2,%h0), xops);
+	  /* jb label */
+	  break;
 
-    case NE:
-      xops[1] = GEN_INT (0x44);
-      xops[2] = GEN_INT (0x40);
-      output_asm_insn (AS2 (and%B0,%1,%h0), xops);
-      output_asm_insn (AS2 (xor%B0,%2,%h0), xops);
-      /* jne label */
-      break;
+	case EQ:
+	  xops[1] = GEN_INT (0x45);
+	  xops[2] = GEN_INT (0x40);
+	  output_asm_insn (AS2 (and%B0,%1,%h0), xops);
+	  output_asm_insn (AS2 (cmp%B0,%2,%h0), xops);
+	  /* je label */
+	  break;
 
-    case GTU:
-    case LTU:
-    case GEU:
-    case LEU:
-    default:
-      abort ();
+	case NE:
+	  xops[1] = GEN_INT (0x44);
+	  xops[2] = GEN_INT (0x40);
+	  output_asm_insn (AS2 (and%B0,%1,%h0), xops);
+	  output_asm_insn (AS2 (xor%B0,%2,%h0), xops);
+	  /* jne label */
+	  break;
+
+	case GTU:
+	case LTU:
+	case GEU:
+	case LEU:
+	default:
+	  abort ();
+	}
     }
 
   return "";
@@ -5196,6 +5241,13 @@ output_fp_conditional_move (which_altern
      int which_alternative;
      rtx operands[];
 {
+  enum rtx_code code = GET_CODE (operands[1]);
+
+  /* It should never happen. */
+  if (!(cc_prev_status.flags & CC_IN_80387)
+      && (code == GT || code == LE || code == GE || code == LT))
+    abort ();
+
   switch (which_alternative)
     {
     case 0:
@@ -5226,7 +5272,7 @@ output_int_conditional_move (which_alter
      int which_alternative;
      rtx operands[];
 {
-  int code = GET_CODE (operands[1]);
+  enum rtx_code code = GET_CODE (operands[1]);
   enum machine_mode mode;
   rtx xops[4];
 

Re: egcs-1.2 stuff

[Jeffrey A Law]

  In message <m10O9fD-000ErMC@ocean.lucon.org>you write:
  > > 
  > > 
  > > 
  > >   In message <m10O2ic-000ErMC@ocean.lucon.org>you write:
  > >   > I enabled all TARGET_CMOVE and CC_FCOMI. I also optimized the fp
  > >   > cmove.
  > >   > 
  > >   > What do you mean by that? I sent in patches months ago and you said
  > >   > you would take a look. What happened?
  > > The FCOMI stuff I explicitly left with you and John to sort out.  Last I
  > > heard there were still technical problems with that patch.  If you and Jo
  > hn
  > > think the patch is done, then send the final patch.
  > > 
  > 
  > This is the latest patch I have been using. It seems ok.
  > 
  > 
  > H.J.
  > ----
  > Mon Jan 11 20:02:56 1999  H.J. Lu  (hjl@gnu.org)
  > 
  > 	* i386.c (output_fp_cc0_set): Don't check the JUMP_INSN code for
  > 	conditional move.
  > 
  > 	* config/i386/i386.c (notice_update_cc, output_float_compare):
  > 	Enable TARGET_CMOVE support.
  > 
  > 	* config/i386/i386.c (output_float_compare): Fix the FLOAT
  > 	comparison for IEEE math and CC_FCOMI.
I tried compiling specfp92 with this patch -- about half of the benchmarks
as mis-compiled in some manner.

I think you need to do some additional testing and debugging of this patch.

jeff

Re: egcs-1.2 stuff

[H.J. Lu]

> 
> 
>   In message <m10O9fD-000ErMC@ocean.lucon.org>you write:
>   > > 
>   > > 
>   > > 
>   > >   In message <m10O2ic-000ErMC@ocean.lucon.org>you write:
>   > >   > I enabled all TARGET_CMOVE and CC_FCOMI. I also optimized the fp
>   > >   > cmove.
>   > >   > 
>   > >   > What do you mean by that? I sent in patches months ago and you said
>   > >   > you would take a look. What happened?
>   > > The FCOMI stuff I explicitly left with you and John to sort out.  Last I
>   > > heard there were still technical problems with that patch.  If you and Jo
>   > hn
>   > > think the patch is done, then send the final patch.
>   > > 
>   > 
>   > This is the latest patch I have been using. It seems ok.
>   > 
>   > 
>   > H.J.
>   > ----
>   > Mon Jan 11 20:02:56 1999  H.J. Lu  (hjl@gnu.org)
>   > 
>   > 	* i386.c (output_fp_cc0_set): Don't check the JUMP_INSN code for
>   > 	conditional move.
>   > 
>   > 	* config/i386/i386.c (notice_update_cc, output_float_compare):
>   > 	Enable TARGET_CMOVE support.
>   > 
>   > 	* config/i386/i386.c (output_float_compare): Fix the FLOAT
>   > 	comparison for IEEE math and CC_FCOMI.
> I tried compiling specfp92 with this patch -- about half of the benchmarks
> as mis-compiled in some manner.

I have SPEC95. I cannot even get the FP part to work with egcs. Richard
told me he got the same problem as I do.

> 
> I think you need to do some additional testing and debugging of this patch.
> 

Let's first find out why you got the gcc testsuite failure and I don't.

Thanks.


-- 
H.J. Lu (hjl@gnu.org)

Re: egcs-1.2 stuff

[H.J. Lu]

> 
> 
>   In message <m10O9fD-000ErMC@ocean.lucon.org>you write:
>   > > 
>   > > 
>   > > 
>   > >   In message <m10O2ic-000ErMC@ocean.lucon.org>you write:
>   > >   > I enabled all TARGET_CMOVE and CC_FCOMI. I also optimized the fp
>   > >   > cmove.
>   > >   > 
>   > >   > What do you mean by that? I sent in patches months ago and you said
>   > >   > you would take a look. What happened?
>   > > The FCOMI stuff I explicitly left with you and John to sort out.  Last I
>   > > heard there were still technical problems with that patch.  If you and Jo
>   > hn
>   > > think the patch is done, then send the final patch.
>   > > 
>   > 
>   > This is the latest patch I have been using. It seems ok.
>   > 
>   > 
>   > H.J.
>   > ----
>   > Mon Jan 11 20:02:56 1999  H.J. Lu  (hjl@gnu.org)
>   > 
>   > 	* i386.c (output_fp_cc0_set): Don't check the JUMP_INSN code for
>   > 	conditional move.
>   > 
>   > 	* config/i386/i386.c (notice_update_cc, output_float_compare):
>   > 	Enable TARGET_CMOVE support.
>   > 
>   > 	* config/i386/i386.c (output_float_compare): Fix the FLOAT
>   > 	comparison for IEEE math and CC_FCOMI.
> I tried compiling specfp92 with this patch -- about half of the benchmarks
> as mis-compiled in some manner.

I have SPEC95. I cannot even get the FP part to work with egcs. Richard
told me he got the same problem as I do.

> 
> I think you need to do some additional testing and debugging of this patch.
> 

Let's first find out why you got the gcc testsuite failure and I don't.

Thanks.


-- 
H.J. Lu (hjl@gnu.org)

Re: egcs-1.2 stuff

[Jeffrey A Law]

  In message <m10O9fD-000ErMC@ocean.lucon.org>you write:
  > > 
  > > 
  > > 
  > >   In message <m10O2ic-000ErMC@ocean.lucon.org>you write:
  > >   > I enabled all TARGET_CMOVE and CC_FCOMI. I also optimized the fp
  > >   > cmove.
  > >   > 
  > >   > What do you mean by that? I sent in patches months ago and you said
  > >   > you would take a look. What happened?
  > > The FCOMI stuff I explicitly left with you and John to sort out.  Last I
  > > heard there were still technical problems with that patch.  If you and Jo
  > hn
  > > think the patch is done, then send the final patch.
  > > 
  > 
  > This is the latest patch I have been using. It seems ok.
  > 
  > 
  > H.J.
  > ----
  > Mon Jan 11 20:02:56 1999  H.J. Lu  (hjl@gnu.org)
  > 
  > 	* i386.c (output_fp_cc0_set): Don't check the JUMP_INSN code for
  > 	conditional move.
  > 
  > 	* config/i386/i386.c (notice_update_cc, output_float_compare):
  > 	Enable TARGET_CMOVE support.
  > 
  > 	* config/i386/i386.c (output_float_compare): Fix the FLOAT
  > 	comparison for IEEE math and CC_FCOMI.
I tried compiling specfp92 with this patch -- about half of the benchmarks
as mis-compiled in some manner.

I think you need to do some additional testing and debugging of this patch.

jeff

Re: egcs-1.2 stuff

[Jeffrey A Law]

  In message <m10O9fD-000ErMC@ocean.lucon.org>you write:
  > > 
  > > 
  > > 
  > >   In message <m10O2ic-000ErMC@ocean.lucon.org>you write:
  > >   > I enabled all TARGET_CMOVE and CC_FCOMI. I also optimized the fp
  > >   > cmove.
  > >   > 
  > >   > What do you mean by that? I sent in patches months ago and you said
  > >   > you would take a look. What happened?
  > > The FCOMI stuff I explicitly left with you and John to sort out.  Last I
  > > heard there were still technical problems with that patch.  If you and Jo
  > hn
  > > think the patch is done, then send the final patch.
  > > 
  > 
  > This is the latest patch I have been using. It seems ok.
  > 
  > 
  > H.J.
  > ----
  > Mon Jan 11 20:02:56 1999  H.J. Lu  (hjl@gnu.org)
  > 
  > 	* i386.c (output_fp_cc0_set): Don't check the JUMP_INSN code for
  > 	conditional move.
  > 
  > 	* config/i386/i386.c (notice_update_cc, output_float_compare):
  > 	Enable TARGET_CMOVE support.
  > 
  > 	* config/i386/i386.c (output_float_compare): Fix the FLOAT
  > 	comparison for IEEE math and CC_FCOMI.
Here's a nice simple example from the gcc testsuite that breaks with this
patch installed.

Compile & run on a PPro/PII with -O1 -march=pentiumpro

The program will abort instead of exiting with zero status:
f (double *ty)
{
  *ty = -1.0;
}

main ()
{
  double foo[6];
  double tx = 0.0, ty, d;

  f (&ty);

  if (ty < 0)
    ty = -ty;
  d = (tx > ty) ? tx : ty;
  if (ty != d)
    abort ();
  exit (0);
}


When you resubmit this patch, can you please test it with the gcc testsuite
first?

Thanks,
jeff

Re: egcs-1.2 stuff

[H.J. Lu]

> 
> 
>   In message <m10O9fD-000ErMC@ocean.lucon.org>you write:
>   > > 
>   > > 
>   > > 
>   > >   In message <m10O2ic-000ErMC@ocean.lucon.org>you write:
>   > >   > I enabled all TARGET_CMOVE and CC_FCOMI. I also optimized the fp
>   > >   > cmove.
>   > >   > 
>   > >   > What do you mean by that? I sent in patches months ago and you said
>   > >   > you would take a look. What happened?
>   > > The FCOMI stuff I explicitly left with you and John to sort out.  Last I
>   > > heard there were still technical problems with that patch.  If you and Jo
>   > hn
>   > > think the patch is done, then send the final patch.
>   > > 
>   > 
>   > This is the latest patch I have been using. It seems ok.
>   > 
>   > 
>   > H.J.
>   > ----
>   > Mon Jan 11 20:02:56 1999  H.J. Lu  (hjl@gnu.org)
>   > 
>   > 	* i386.c (output_fp_cc0_set): Don't check the JUMP_INSN code for
>   > 	conditional move.
>   > 
>   > 	* config/i386/i386.c (notice_update_cc, output_float_compare):
>   > 	Enable TARGET_CMOVE support.
>   > 
>   > 	* config/i386/i386.c (output_float_compare): Fix the FLOAT
>   > 	comparison for IEEE math and CC_FCOMI.
> Here's a nice simple example from the gcc testsuite that breaks with this
> patch installed.
> 
> Compile & run on a PPro/PII with -O1 -march=pentiumpro
> 
> The program will abort instead of exiting with zero status:
> f (double *ty)
> {
>   *ty = -1.0;
> }
> 
> main ()
> {
>   double foo[6];
>   double tx = 0.0, ty, d;
> 
>   f (&ty);
> 
>   if (ty < 0)
>     ty = -ty;
>   d = (tx > ty) ? tx : ty;
>   if (ty != d)
>     abort ();
>   exit (0);
> }
> 
> 
> When you resubmit this patch, can you please test it with the gcc testsuite
> first?
> 

I am quite confused here:

1. I have verified that there are no regressions with egcs 1.1.2.
2. The testcase works fine with egcs in CVS at 10:15am on Apr. 3
plus my CC_FCOMI patch.

Could you please check my asm ouput against yours to see why yours
doesn't work?

I am enclosing the failures I got with egcs in CVS at 10:15am on Apr.
3 plus my CC_FCOMI patch using -march=pentiumpro -mcpu=pentiumpro. How
does it compare with your results?

If you use Linux/x86 or any x86 OSes for that matter, you should use
binutils 2.9.1.0.23. There are a few x86 gas bugs fixed. I know one
of them causes the problem you have seen. I haven't check the gas
snapshot yet. I assume it is ok.

BTW, one more benefit of binutils 2.9.1.0.23 on x86 is you can use
P/III instructions if you have P/III. binutils 2.9.1.0.23 is available
from

ftp://ftp.varesearch.com/pub/support/hjl/binutils

Thanks.

-- 
H.J. Lu (hjl@gnu.org)
---
	.file	"x.c"
	.version	"01.01"
gcc2_compiled.:
.section	.rodata
	.align 8
.LC0:
	.long 0x0,0xbff00000
.text
	.align 4
.globl f
	.type	 f,@function
f:
	pushl %ebp
	movl %esp,%ebp
	subl $8,%esp
	movl 8(%ebp),%eax
	fldl .LC0
	fstpl (%eax)
	movl %ebp,%esp
	popl %ebp
	ret
.Lfe1:
	.size	 f,.Lfe1-f
	.align 4
.globl main
	.type	 main,@function
main:
	pushl %ebp
	movl %esp,%ebp
	subl $88,%esp
	addl $-12,%esp
	leal -72(%ebp),%eax
	pushl %eax
	call f
	addl $16,%esp
	fldl -72(%ebp)
	fldz
	fcomip %st(1),%st
	jbe .L8
	fchs
	fstpl -72(%ebp)
	jmp .L4
.L8:
	fstp %st(0)
.L4:
	fldz
	fcoml -72(%ebp)
	fnstsw %ax
	andb $69,%ah
	je .L6
	fstp %st(0)
	fldl -72(%ebp)
.L6:
	fldl -72(%ebp)
	fucomip %st(1),%st
	fstp %st(0)
	setne %al
	setp %ah
	orb %al,%ah
	je .L7
	call abort
	.p2align 4,,7
.L7:
	addl $-12,%esp
	pushl $0
	call exit
.Lfe2:
	.size	 main,.Lfe2-main
	.ident	"GCC: (GNU) egcs-2.93.14 19990403 (gcc2 ss-980929 experimental)"
---
FAIL: g++.dg/special/conpr-1.C execution test
FAIL: objc/execute/bf-1.m compilation,  -O 
FAIL: g++.dg/special/conpr-2.C execution test
FAIL: objc/execute/bf-10.m compilation,  -O 
FAIL: g++.dg/special/conpr-3.C execution test
FAIL: g++.dg/special/conpr-3.C execution test
FAIL: objc/execute/bf-11.m compilation,  -O 
FAIL: objc/execute/bf-12.m compilation,  -O 
FAIL: objc/execute/bf-13.m compilation,  -O 
FAIL: objc/execute/bf-14.m compilation,  -O 
FAIL: objc/execute/bf-15.m compilation,  -O 
FAIL: objc/execute/bf-16.m compilation,  -O 
FAIL: objc/execute/bf-17.m compilation,  -O 
FAIL: objc/execute/bf-18.m compilation,  -O 
FAIL: objc/execute/bf-19.m compilation,  -O 
FAIL: objc/execute/bf-2.m compilation,  -O 
FAIL: objc/execute/bf-3.m compilation,  -O 
FAIL: objc/execute/bf-4.m compilation,  -O 
FAIL: objc/execute/bf-5.m compilation,  -O 
FAIL: objc/execute/bf-6.m compilation,  -O 
FAIL: objc/execute/bf-7.m compilation,  -O 
FAIL: objc/execute/bf-8.m compilation,  -O 
FAIL: objc/execute/bf-9.m compilation,  -O 
FAIL: g77.f-torture/execute/19990325-1.f execution,  -O0 
FAIL: g77.f-torture/execute/19990325-1.f execution,  -O1 
FAIL: g77.f-torture/execute/19990325-1.f execution,  -O2 
FAIL: g77.f-torture/execute/19990325-1.f execution,  -O2 -fomit-frame-pointer -finline-functions 
FAIL: g77.f-torture/execute/19990325-1.f execution,  -Os 
FAIL: g77.f-torture/execute/970625-2.f compilation,  -O1 
FAIL: gcc.c-torture/execute/990130-1.c compilation,  -O0 
FAIL: gcc.c-torture/execute/990130-1.c compilation,  -O1 
FAIL: gcc.c-torture/execute/990130-1.c compilation,  -O2 
FAIL: gcc.c-torture/execute/990130-1.c compilation,  -O3 -fomit-frame-pointer 
FAIL: gcc.c-torture/execute/990130-1.c compilation,  -O3 -g 
FAIL: gcc.c-torture/execute/990130-1.c compilation,  -Os 
FAIL: gcc.c-torture/execute/loop-2b.c execution,  -O2 
FAIL: gcc.c-torture/execute/loop-2b.c execution,  -O3 -fomit-frame-pointer 
FAIL: gcc.c-torture/execute/loop-2b.c execution,  -O3 -fomit-frame-pointer -funroll-loops 
FAIL: gcc.c-torture/execute/loop-2b.c execution,  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions 
FAIL: gcc.c-torture/execute/loop-2b.c execution,  -O3 -g 
FAIL: gcc.dg/990119-1.c execution test
FAIL: gcc.dg/special/weak-1.c execution test

Re: egcs-1.2 stuff

[Jeffrey A Law]

  In message < m10TgYt-000ErMC@ocean.lucon.org >you write:
  > 1. I have verified that there are no regressions with egcs 1.1.2.
I don't care about regressions again egcs-1.1.2.

  > 2. The testcase works fine with egcs in CVS at 10:15am on Apr. 3
  > plus my CC_FCOMI patch.
This is very odd since I did it with a fresh tree this afternoon.


  > Could you please check my asm ouput against yours to see why yours
  > doesn't work?
I don't know the x86 architecture well enough to do that.


  > I am enclosing the failures I got with egcs in CVS at 10:15am on Apr.
  > 3 plus my CC_FCOMI patch using -march=pentiumpro -mcpu=pentiumpro. How
  > does it compare with your results?
I only used "-march=pentiumpro -O1"   Please verify using the compiler
options I specified in my message.  When you use different options you make
your testresults worthless.

I just tried it again from the CVS tree.  Without your patch it runs fine,
with your patch it aborts.

Here's the assembly code that works:

	.file	"k.c"
	.version	"01.01"
gcc2_compiled.:
.section	.rodata
	.align 8
.LC0:
	.long 0x0,0xbff00000
.text
	.align 4
.globl f
	.type	 f,@function
f:
	pushl %ebp
	movl %esp,%ebp
	subl $8,%esp
	movl 8(%ebp),%eax
	fldl .LC0
	fstpl (%eax)
	movl %ebp,%esp
	popl %ebp
	ret
.Lfe1:
	.size	 f,.Lfe1-f
	.align 4
.globl main
	.type	 main,@function
main:
	pushl %ebp
	movl %esp,%ebp
	subl $88,%esp
	addl $-12,%esp
	leal -72(%ebp),%eax
	pushl %eax
	call f
	addl $16,%esp
	fldl -72(%ebp)
	fldz
	fcomp %st(1)
	fnstsw %ax
	andb $69,%ah
	jne .L8
	fchs
	fstpl -72(%ebp)
	jmp .L4
.L8:
	fstp %st(0)
.L4:
	fldz
	fcoml -72(%ebp)
	fnstsw %ax
	andb $69,%ah
	je .L6
	fstp %st(0)
	fldl -72(%ebp)
.L6:
	fldl -72(%ebp)
	fucompp
	fnstsw %ax
	andb $69,%ah
	cmpb $64,%ah
	je .L7
	call abort
	.p2align 4,,7
.L7:
	addl $-12,%esp
	pushl $0
	call exit
.Lfe2:
	.size	 main,.Lfe2-main
	.ident	"GCC: (GNU) egcs-2.93.14 19990403 (gcc2 ss-980929 experimental)"


And the assembly code that does not work

	.file	"j.c"
	.version	"01.01"
gcc2_compiled.:
.section	.rodata
	.align 8
.LC0:
	.long 0x0,0xbff00000
.text
	.align 4
.globl f
	.type	 f,@function
f:
	pushl %ebp
	movl %esp,%ebp
	subl $8,%esp
	movl 8(%ebp),%eax
	fldl .LC0
	fstpl (%eax)
	movl %ebp,%esp
	popl %ebp
	ret
.Lfe1:
	.size	 f,.Lfe1-f
	.align 4
.globl main
	.type	 main,@function
main:
	pushl %ebp
	movl %esp,%ebp
	subl $88,%esp
	addl $-12,%esp
	leal -72(%ebp),%eax
	pushl %eax
	call f
	addl $16,%esp
	fldl -72(%ebp)
	fldz
	fcomip %st(1),%st
	jne .L8
	fchs
	fstpl -72(%ebp)
	jmp .L4
.L8:
	fstp %st(0)
.L4:
	fldz
	fcoml -72(%ebp)
	fnstsw %ax
	andb $69,%ah
	je .L6
	fstp %st(0)
	fldl -72(%ebp)
.L6:
	fldl -72(%ebp)
	fucomip %st(1),%st
	fstp %st(0)
	setne %al
	setp %ah
	orb %al,%ah
	je .L7
	call abort
	.p2align 4,,7
.L7:
	addl $-12,%esp
	pushl $0
	call exit
.Lfe2:
	.size	 main,.Lfe2-main
	.ident	"GCC: (GNU) egcs-2.93.14 19990403 (gcc2 ss-980929 experimental)"

Re: egcs-1.2 stuff

[H.J. Lu]

>   > I am enclosing the failures I got with egcs in CVS at 10:15am on Apr.
>   > 3 plus my CC_FCOMI patch using -march=pentiumpro -mcpu=pentiumpro. How
>   > does it compare with your results?
> I only used "-march=pentiumpro -O1"   Please verify using the compiler
> options I specified in my message.  When you use different options you make
> your testresults worthless.

I have been using -march=pentiumpro -mcpu=pentiumpro to run "make check"
for every egcs I build. I didn't make that one for you. I am doing

# cd gcc
# make -j 8 check RUNTESTFLAGS="--tool_opts \"-march=pentiumpro\""

Is that ok or should I use

# make -j 8 check RUNTESTFLAGS="--tool_opts \"-O1 -march=pentiumpro\""

> 
> I just tried it again from the CVS tree.  Without your patch it runs fine,
> with your patch it aborts.

Can you send me the patch you used? I like to see why it fails.

> 
> And the assembly code that does not work
> 
> 	.file	"j.c"
> 	.version	"01.01"

That is the difference between yours and mine. I want to know why you
get the wrong result. I need the patch you used to see it myself.

Thanks.


--- foo.s	Sun Apr  4 08:43:26 1999
+++ x.s	Sun Apr  4 08:42:53 1999
@@ -1,4 +1,4 @@
-	.file	"j.c"
+	.file	"x.c"
 	.version	"01.01"
 gcc2_compiled.:
 .section	.rodata
@@ -36,7 +36,7 @@
 	fldl -72(%ebp)
 	fldz
 	fcomip %st(1),%st
-	jne .L8
+	jbe .L8
 	fchs
 	fstpl -72(%ebp)
 	jmp .L4

Re: egcs-1.2 stuff

[Jeffrey A Law]

  In message < m10Tp9T-000ErMC@ocean.lucon.org >you write:
  > 
  > >   > I am enclosing the failures I got with egcs in CVS at 10:15am on Apr.
  > >   > 3 plus my CC_FCOMI patch using -march=pentiumpro -mcpu=pentiumpro. Ho
  > w
  > >   > does it compare with your results?
  > > I only used "-march=pentiumpro -O1"   Please verify using the compiler
  > > options I specified in my message.  When you use different options you
  > > make your testresults worthless.
  > 
  > I have been using -march=pentiumpro -mcpu=pentiumpro to run "make check"
  > for every egcs I build. I didn't make that one for you. I am doing
When trying to look for a specific problem you should try to perform the
exact same test.  Otherwise you introduce additional variables into the test
which is poor programming/debugging practice.

  > > 
  > > I just tried it again from the CVS tree.  Without your patch it runs fine
  > ,
  > > with your patch it aborts.
  > 
  > Can you send me the patch you used? I like to see why it fails.
Attached at the end of this message.

To recap when I add the fcomi patch 930614-1.c fails when compiled with
"-O1 -march=pentiumpro".


  > That is the difference between yours and mine. I want to know why you
  > get the wrong result. I need the patch you used to see it myself.
  > 
  > @@ -36,7 +36,7 @@
  >  	fldl -72(%ebp)
  >  	fldz
  >  	fcomip %st(1),%st
  > -	jne .L8
  > +	jbe .L8
  >  	fchs
  >  	fstpl -72(%ebp)
  >  	jmp .L4
Interesting.  I wonder if the patch got mis-applied.  Quite possible since
the patch is old.

Anyway, here's the diffs against the current tree.  Even if you find the
problem, I would still like John to review the patch before it goes into
the tree.  I'm simply not qualified to review this code.


Index: i386.c
===================================================================
RCS file: /egcs/carton/cvsfiles/egcs/gcc/config/i386/i386.c,v
retrieving revision 1.60
diff -c -3 -p -r1.60 i386.c
*** i386.c	1999/04/10 17:18:06	1.60
--- i386.c	1999/04/12 09:53:23
*************** notice_update_cc (exp)
*** 3896,3902 ****
            if (stack_regs_mentioned_p (SET_SRC (XVECEXP (exp, 0, 0))))
  	    {
                cc_status.flags |= CC_IN_80387;
! 	      if (0 && TARGET_CMOVE && stack_regs_mentioned_p
  		  (XEXP (SET_SRC (XVECEXP (exp, 0, 0)), 1)))
  		cc_status.flags |= CC_FCOMI;
  	    }
--- 3896,3902 ----
            if (stack_regs_mentioned_p (SET_SRC (XVECEXP (exp, 0, 0))))
  	    {
                cc_status.flags |= CC_IN_80387;
! 	      if (TARGET_CMOVE && stack_regs_mentioned_p
  		  (XEXP (SET_SRC (XVECEXP (exp, 0, 0)), 1)))
  		cc_status.flags |= CC_FCOMI;
  	    }
*************** output_float_compare (insn, operands)
*** 4194,4200 ****
    int unordered_compare = GET_MODE (SET_SRC (body)) == CCFPEQmode;
    rtx tmp;
  
!   if (0 && TARGET_CMOVE && STACK_REG_P (operands[1]))
      {
        cc_status.flags |= CC_FCOMI;
        cc_prev_status.flags &= ~CC_TEST_AX;
--- 4194,4200 ----
    int unordered_compare = GET_MODE (SET_SRC (body)) == CCFPEQmode;
    rtx tmp;
  
!   if (TARGET_CMOVE && STACK_REG_P (operands[1]))
      {
        cc_status.flags |= CC_FCOMI;
        cc_prev_status.flags &= ~CC_TEST_AX;
*************** output_float_compare (insn, operands)
*** 4228,4234 ****
  	    {
  	      output_asm_insn (AS2 (fucomip,%y1,%0), operands);
  	      output_asm_insn (AS1 (fstp, %y0), operands);
! 	      return "";
  	    }
  	  else
  	    output_asm_insn ("fucompp", operands);
--- 4228,4235 ----
  	    {
  	      output_asm_insn (AS2 (fucomip,%y1,%0), operands);
  	      output_asm_insn (AS1 (fstp, %y0), operands);
! 	      if (!TARGET_IEEE_FP)
! 		return "";
  	    }
  	  else
  	    output_asm_insn ("fucompp", operands);
*************** output_float_compare (insn, operands)
*** 4239,4245 ****
  	    {
  	      output_asm_insn (AS2 (fcomip, %y1,%0), operands);
  	      output_asm_insn (AS1 (fstp, %y0), operands);
! 	      return "";
  	    }
  	  else
  	    output_asm_insn ("fcompp", operands);
--- 4240,4247 ----
  	    {
  	      output_asm_insn (AS2 (fcomip, %y1,%0), operands);
  	      output_asm_insn (AS1 (fstp, %y0), operands);
! 	      if (!TARGET_IEEE_FP)
! 		return "";
  	    }
  	  else
  	    output_asm_insn ("fcompp", operands);
*************** output_float_compare (insn, operands)
*** 4264,4270 ****
        if (cc_status.flags & CC_FCOMI)
  	{
  	  output_asm_insn (strcat (buf, AS2 (%z1,%y1,%0)), operands);
! 	  return "";
  	}
        else
          output_asm_insn (strcat (buf, AS1 (%z1,%y1)), operands);
--- 4266,4273 ----
        if (cc_status.flags & CC_FCOMI)
  	{
  	  output_asm_insn (strcat (buf, AS2 (%z1,%y1,%0)), operands);
! 	  if (!TARGET_IEEE_FP)
! 	    return "";
  	}
        else
          output_asm_insn (strcat (buf, AS1 (%z1,%y1)), operands);
*************** output_fp_cc0_set (insn)
*** 4288,4304 ****
    rtx next;
    enum rtx_code code;
  
!   xops[0] = gen_rtx_REG (HImode, 0);
!   output_asm_insn (AS1 (fnsts%W0,%0), xops);
  
    if (! TARGET_IEEE_FP)
      {
        if (!(cc_status.flags & CC_REVERSED))
          {
            next = next_cc0_user (insn);
! 
!           if (GET_CODE (next) == JUMP_INSN
!               && GET_CODE (PATTERN (next)) == SET
                && SET_DEST (PATTERN (next)) == pc_rtx
                && GET_CODE (SET_SRC (PATTERN (next))) == IF_THEN_ELSE)
  	    code = GET_CODE (XEXP (SET_SRC (PATTERN (next)), 0));
--- 4291,4309 ----
    rtx next;
    enum rtx_code code;
  
!   if (!(cc_status.flags & CC_FCOMI))
!     {
!       xops[0] = gen_rtx_REG (HImode, 0);
!       output_asm_insn (AS1 (fnsts%W0,%0), xops);
!     }
  
    if (! TARGET_IEEE_FP)
      {
        if (!(cc_status.flags & CC_REVERSED))
          {
            next = next_cc0_user (insn);
!   
!           if (GET_CODE (PATTERN (next)) == SET
                && SET_DEST (PATTERN (next)) == pc_rtx
                && GET_CODE (SET_SRC (PATTERN (next))) == IF_THEN_ELSE)
  	    code = GET_CODE (XEXP (SET_SRC (PATTERN (next)), 0));
*************** output_fp_cc0_set (insn)
*** 4323,4330 ****
    if (next == NULL_RTX)
      abort ();
  
!   if (GET_CODE (next) == JUMP_INSN
!       && GET_CODE (PATTERN (next)) == SET
        && SET_DEST (PATTERN (next)) == pc_rtx
        && GET_CODE (SET_SRC (PATTERN (next))) == IF_THEN_ELSE)
      code = GET_CODE (XEXP (SET_SRC (PATTERN (next)), 0));
--- 4328,4334 ----
    if (next == NULL_RTX)
      abort ();
  
!   if (GET_CODE (PATTERN (next)) == SET
        && SET_DEST (PATTERN (next)) == pc_rtx
        && GET_CODE (SET_SRC (PATTERN (next))) == IF_THEN_ELSE)
      code = GET_CODE (XEXP (SET_SRC (PATTERN (next)), 0));
*************** output_fp_cc0_set (insn)
*** 4346,4407 ****
      }
    else
      abort ();
- 
-   xops[0] = gen_rtx_REG (QImode, 0);
  
!   switch (code)
      {
!     case GT:
!       xops[1] = GEN_INT (0x45);
!       output_asm_insn (AS2 (and%B0,%1,%h0), xops);
!       /* je label */
!       break;
! 
!     case LT:
!       xops[1] = GEN_INT (0x45);
!       xops[2] = GEN_INT (0x01);
!       output_asm_insn (AS2 (and%B0,%1,%h0), xops);
!       output_asm_insn (AS2 (cmp%B0,%2,%h0), xops);
!       /* je label */
!       break;
! 
!     case GE:
!       xops[1] = GEN_INT (0x05);
!       output_asm_insn (AS2 (and%B0,%1,%h0), xops);
!       /* je label */
!       break;
! 
!     case LE:
!       xops[1] = GEN_INT (0x45);
!       xops[2] = GEN_INT (0x40);
!       output_asm_insn (AS2 (and%B0,%1,%h0), xops);
!       output_asm_insn (AS1 (dec%B0,%h0), xops);
!       output_asm_insn (AS2 (cmp%B0,%2,%h0), xops);
!       /* jb label */
!       break;
  
!     case EQ:
!       xops[1] = GEN_INT (0x45);
!       xops[2] = GEN_INT (0x40);
!       output_asm_insn (AS2 (and%B0,%1,%h0), xops);
!       output_asm_insn (AS2 (cmp%B0,%2,%h0), xops);
!       /* je label */
!       break;
  
!     case NE:
!       xops[1] = GEN_INT (0x44);
!       xops[2] = GEN_INT (0x40);
!       output_asm_insn (AS2 (and%B0,%1,%h0), xops);
!       output_asm_insn (AS2 (xor%B0,%2,%h0), xops);
!       /* jne label */
!       break;
  
!     case GTU:
!     case LTU:
!     case GEU:
!     case LEU:
!     default:
!       abort ();
      }
  
    return "";
--- 4350,4453 ----
      }
    else
      abort ();
  
!   if (cc_status.flags & CC_FCOMI)
      {
!       /* It is very tricky. We have to do it right. */
  
!       xops [0] = gen_rtx_REG (QImode, 0);
  
!       switch (code)
! 	{
! 	case GT:
! 	case GE:
! 	  break;
! 
! 	case LT:
! 	  output_asm_insn (AS1 (setb,%b0), xops);
! 	  output_asm_insn (AS1 (setp,%h0), xops);
! 	  output_asm_insn (AS2 (cmp%B0,%b0,%h0), xops);
! 	  break;
! 
! 	case LE:
! 	  output_asm_insn (AS1 (setbe,%b0), xops);
! 	  output_asm_insn (AS1 (setnp,%h0), xops);
! 	  output_asm_insn (AS2 (xor%B0,%b0,%h0), xops);
! 	  break;
! 
! 	case EQ:
! 	case NE:
! 	  output_asm_insn (AS1 (setne,%b0), xops);
! 	  output_asm_insn (AS1 (setp,%h0), xops);
! 	  output_asm_insn (AS2 (or%B0,%b0,%h0), xops);
! 	  break;
! 
! 	case GTU:
! 	case LTU:
! 	case GEU:
! 	case LEU:
! 	default:
! 	  abort ();
! 	}
!     }
!   else
!     {
!       xops[0] = gen_rtx_REG (QImode, 0);
  
!       switch (code)
! 	{
! 	case GT:
! 	  xops[1] = GEN_INT (0x45);
! 	  output_asm_insn (AS2 (and%B0,%1,%h0), xops);
! 	  /* je label */
! 	  break;
! 
! 	case LT:
! 	  xops[1] = GEN_INT (0x45);
! 	  xops[2] = GEN_INT (0x01);
! 	  output_asm_insn (AS2 (and%B0,%1,%h0), xops);
! 	  output_asm_insn (AS2 (cmp%B0,%2,%h0), xops);
! 	  /* je label */
! 	  break;
! 
! 	case GE:
! 	  xops[1] = GEN_INT (0x05);
! 	  output_asm_insn (AS2 (and%B0,%1,%h0), xops);
! 	  /* je label */
! 	  break;
! 
! 	case LE:
! 	  xops[1] = GEN_INT (0x45);
! 	  xops[2] = GEN_INT (0x40);
! 	  output_asm_insn (AS2 (and%B0,%1,%h0), xops);
! 	  output_asm_insn (AS1 (dec%B0,%h0), xops);
! 	  output_asm_insn (AS2 (cmp%B0,%2,%h0), xops);
! 	  /* jb label */
! 	  break;
! 
! 	case EQ:
! 	  xops[1] = GEN_INT (0x45);
! 	  xops[2] = GEN_INT (0x40);
! 	  output_asm_insn (AS2 (and%B0,%1,%h0), xops);
! 	  output_asm_insn (AS2 (cmp%B0,%2,%h0), xops);
! 	  /* je label */
! 	  break;
! 
! 	case NE:
! 	  xops[1] = GEN_INT (0x44);
! 	  xops[2] = GEN_INT (0x40);
! 	  output_asm_insn (AS2 (and%B0,%1,%h0), xops);
! 	  output_asm_insn (AS2 (xor%B0,%2,%h0), xops);
! 	  /* jne label */
! 	  break;
! 
! 	case GTU:
! 	case LTU:
! 	case GEU:
! 	case LEU:
! 	default:
! 	  abort ();
! 	}
      }
  
    return "";

Re: egcs-1.2 stuff

[H.J. Lu]

>   > >   > I am enclosing the failures I got with egcs in CVS at 10:15am on Apr.
>   > >   > 3 plus my CC_FCOMI patch using -march=pentiumpro -mcpu=pentiumpro. Ho
>   > w
>   > >   > does it compare with your results?
>   > > I only used "-march=pentiumpro -O1"   Please verify using the compiler
>   > > options I specified in my message.  When you use different options you
>   > > make your testresults worthless.
>   > 
>   > I have been using -march=pentiumpro -mcpu=pentiumpro to run "make check"
>   > for every egcs I build. I didn't make that one for you. I am doing
> When trying to look for a specific problem you should try to perform the
> exact same test.  Otherwise you introduce additional variables into the test
> which is poor programming/debugging practice.

I mentioned it because you accused me that I didn't check if there
were any regressions. I just told you that it was false.

> 
>   > > 
>   > > I just tried it again from the CVS tree.  Without your patch it runs fine
>   > ,
>   > > with your patch it aborts.
>   > 
>   > Can you send me the patch you used? I like to see why it fails.
> Attached at the end of this message.
> 
> To recap when I add the fcomi patch 930614-1.c fails when compiled with
> "-O1 -march=pentiumpro".
> 
> 
>   > That is the difference between yours and mine. I want to know why you
>   > get the wrong result. I need the patch you used to see it myself.
>   > 
>   > @@ -36,7 +36,7 @@
>   >  	fldl -72(%ebp)
>   >  	fldz
>   >  	fcomip %st(1),%st
>   > -	jne .L8
>   > +	jbe .L8
>   >  	fchs
>   >  	fstpl -72(%ebp)
>   >  	jmp .L4
> Interesting.  I wonder if the patch got mis-applied.  Quite possible since
> the patch is old.
> 
> Anyway, here's the diffs against the current tree.  Even if you find the
> problem, I would still like John to review the patch before it goes into
> the tree.  I'm simply not qualified to review this code.
> 

Thanks for the diff. It is wrong. I am in the process to verify it.
What kind of patch do you want? Do you want one against yours or one
against CVS.


H.J.

Re: egcs-1.2 stuff

[H.J. Lu]

>   > >   > I am enclosing the failures I got with egcs in CVS at 10:15am on Apr.
>   > >   > 3 plus my CC_FCOMI patch using -march=pentiumpro -mcpu=pentiumpro. Ho
>   > w
>   > >   > does it compare with your results?
>   > > I only used "-march=pentiumpro -O1"   Please verify using the compiler
>   > > options I specified in my message.  When you use different options you
>   > > make your testresults worthless.
>   > 
>   > I have been using -march=pentiumpro -mcpu=pentiumpro to run "make check"
>   > for every egcs I build. I didn't make that one for you. I am doing
> When trying to look for a specific problem you should try to perform the
> exact same test.  Otherwise you introduce additional variables into the test
> which is poor programming/debugging practice.

I mentioned it because you accused me that I didn't check if there
were any regressions. I just told you that it was false.

> 
>   > > 
>   > > I just tried it again from the CVS tree.  Without your patch it runs fine
>   > ,
>   > > with your patch it aborts.
>   > 
>   > Can you send me the patch you used? I like to see why it fails.
> Attached at the end of this message.
> 
> To recap when I add the fcomi patch 930614-1.c fails when compiled with
> "-O1 -march=pentiumpro".
> 
> 
>   > That is the difference between yours and mine. I want to know why you
>   > get the wrong result. I need the patch you used to see it myself.
>   > 
>   > @@ -36,7 +36,7 @@
>   >  	fldl -72(%ebp)
>   >  	fldz
>   >  	fcomip %st(1),%st
>   > -	jne .L8
>   > +	jbe .L8
>   >  	fchs
>   >  	fstpl -72(%ebp)
>   >  	jmp .L4
> Interesting.  I wonder if the patch got mis-applied.  Quite possible since
> the patch is old.
> 
> Anyway, here's the diffs against the current tree.  Even if you find the
> problem, I would still like John to review the patch before it goes into
> the tree.  I'm simply not qualified to review this code.
> 

Thanks for the diff. It is wrong. I am in the process to verify it.
What kind of patch do you want? Do you want one against yours or one
against CVS.


H.J.

Re: egcs-1.2 stuff

[H.J. Lu]

> 
> Anyway, here's the diffs against the current tree.  Even if you find the
> problem, I would still like John to review the patch before it goes into
> the tree.  I'm simply not qualified to review this code.
> 

Just curious. With your patch, I couldn't even pass "make bootstrap".
I got:

Bootstrap comparison failure!
cccp.o differs
cse.o differs
cxxmain.o differs
emit-rtl.o differs
except.o differs
expmed.o differs
expr.o differs
fold-const.o differs
gcc.o differs
gcse.o differs
genattr.o differs
genattrtab.o differs
......


I have been using

BOOT_CFLAGS=-mcpu=pentiumpro -march=pentiumpro -O2 -g 

BTW, what happened to my patch to libf2c/Makefile.in:

Fri Jan 15 07:06:25 1999  H.J. Lu  (hjl@gnu.org)

        * Makefile.in (FLAGS_TO_PASS): Use "" instead of ''.

I need it to add

RUNTESTFLAGS=--tool_opts '-mcpu=pentiumpro -march=pentiumpro'

and

RUNTESTFLAGS=--tool_opts '-mcpu=pentiumpro -march=pentiumpro -fPIC'

to the top level Makefile. It is useful to run testsuites for PPro and
PIC. Does anyone else run testsuites for PPro on libf2c? I have
complained about libf2c many times. Does anyone from libf2c really have
time to listen and care?

Thanks.

H.J.

Re: egcs-1.2 stuff

[craig]

>BTW, what happened to my patch to libf2c/Makefile.in:
>
>Fri Jan 15 07:06:25 1999  H.J. Lu  (hjl@gnu.org)
>
>        * Makefile.in (FLAGS_TO_PASS): Use "" instead of ''.
>
>I need it to add
>
>RUNTESTFLAGS=--tool_opts '-mcpu=pentiumpro -march=pentiumpro'
>
>and
>
>RUNTESTFLAGS=--tool_opts '-mcpu=pentiumpro -march=pentiumpro -fPIC'
>
>to the top level Makefile. It is useful to run testsuites for PPro and
>PIC. Does anyone else run testsuites for PPro on libf2c? I have
>complained about libf2c many times. Does anyone from libf2c really have
>time to listen and care?

It's in my queue, from back when you complained about this for the Nth
time.

And, like before, I'll ask you for a proper *bug report* or a properly
researched *patch*, if you want this to become higher priority than
it is for me right now.  As it stands, I'll look at it only when I feel
I have the time to study all of the issues (runtest, expect, tcl, shell
quoting rules, etc.) myself, and that does *not* seem like low-hanging
fruit to me.

Of course, I welcome anyone who *already* understands those things
stepping in and saying "here's the *right* way to do stuff like this",
but that hasn't happened yet, AFAIK.

        tq vm, (burley)

Re: egcs-1.2 stuff

[Zack Weinberg]

On 12 Apr 1999 17:16:42 -0000, craig@jcb-sc.com wrote:
>>BTW, what happened to my patch to libf2c/Makefile.in:
>>
>>Fri Jan 15 07:06:25 1999  H.J. Lu  (hjl@gnu.org)
>>
>>        * Makefile.in (FLAGS_TO_PASS): Use "" instead of ''.
>>
>>I need it to add
>>
>>RUNTESTFLAGS=--tool_opts '-mcpu=pentiumpro -march=pentiumpro'
>>
>>and
>>
>>RUNTESTFLAGS=--tool_opts '-mcpu=pentiumpro -march=pentiumpro -fPIC'
>>
>>to the top level Makefile. It is useful to run testsuites for PPro and
>>PIC. Does anyone else run testsuites for PPro on libf2c? I have
>>complained about libf2c many times. Does anyone from libf2c really have
>>time to listen and care?
>
>It's in my queue, from back when you complained about this for the Nth
>time.
[...]
>Of course, I welcome anyone who *already* understands those things
>stepping in and saying "here's the *right* way to do stuff like this",
>but that hasn't happened yet, AFAIK.

It's a consistency issue.  All the other Makefiles have FLAGS_TO_PASS
defined like so:

FLAGS_TO_PASS = CC="$(CC)" BISON="$(BISON)" ...

but libf2c has

FLAGS_TO_PASS = CC='$(CC)' BISON='$(BISON)' ...

Therefore, you can't use "" or '' quotes in any of the FLAGS_TO_PASS
variables.  If libf2c used "" quotes, it would be safe to put ''
quotes into FLAGS_TO_PASS variables.  I don't have HJ's patch to look
at, but if it does just what the ChangeLog says it does, I think it's
the Right Thing.

This is yet another way the build framework is too complicated.

zw

Re: egcs-1.2 stuff

[craig]

>It's a consistency issue.  All the other Makefiles have FLAGS_TO_PASS
>defined like so:
>
>FLAGS_TO_PASS = CC="$(CC)" BISON="$(BISON)" ...
>
>but libf2c has
>
>FLAGS_TO_PASS = CC='$(CC)' BISON='$(BISON)' ...
>
>Therefore, you can't use "" or '' quotes in any of the FLAGS_TO_PASS
>variables.  If libf2c used "" quotes, it would be safe to put ''
>quotes into FLAGS_TO_PASS variables.  I don't have HJ's patch to look
>at, but if it does just what the ChangeLog says it does, I think it's
>the Right Thing.

Okay, that's all I need to hear...I approve it!  Won't commit it tonight,
probably, so if Jeff or someone has it handy, they can go ahead...otherwise,
I'll dig it out soon and apply it myself.

>This is yet another way the build framework is too complicated.

Yup.

        tq vm, (burley)

Re: egcs-1.2 stuff

[Zack Weinberg]

On 13 Apr 1999 02:13:52 -0000, craig@jcb-sc.com wrote:
>>It's a consistency issue.  All the other Makefiles have FLAGS_TO_PASS
>>defined like so:
>>
>>FLAGS_TO_PASS = CC="$(CC)" BISON="$(BISON)" ...
>>
>>but libf2c has
>>
>>FLAGS_TO_PASS = CC='$(CC)' BISON='$(BISON)' ...
>>
>>Therefore, you can't use "" or '' quotes in any of the FLAGS_TO_PASS
>>variables.  If libf2c used "" quotes, it would be safe to put ''
>>quotes into FLAGS_TO_PASS variables.  I don't have HJ's patch to look
>>at, but if it does just what the ChangeLog says it does, I think it's
>>the Right Thing.
>
>Okay, that's all I need to hear...I approve it!

Now HJ, do you suppose you could've told Craig that yourself, months
ago, and saved us all the trouble?  <g>

zw

Re: egcs-1.2 stuff

[H.J. Lu]

> 
> On 13 Apr 1999 02:13:52 -0000, craig@jcb-sc.com wrote:
> >>It's a consistency issue.  All the other Makefiles have FLAGS_TO_PASS
> >>defined like so:
> >>
> >>FLAGS_TO_PASS = CC="$(CC)" BISON="$(BISON)" ...
> >>
> >>but libf2c has
> >>
> >>FLAGS_TO_PASS = CC='$(CC)' BISON='$(BISON)' ...
> >>
> >>Therefore, you can't use "" or '' quotes in any of the FLAGS_TO_PASS
> >>variables.  If libf2c used "" quotes, it would be safe to put ''
> >>quotes into FLAGS_TO_PASS variables.  I don't have HJ's patch to look
> >>at, but if it does just what the ChangeLog says it does, I think it's
> >>the Right Thing.
> >
> >Okay, that's all I need to hear...I approve it!
> 
> Now HJ, do you suppose you could've told Craig that yourself, months
> ago, and saved us all the trouble?  <g>
> 

I forwarded an old email of mine to you.

-- 
H.J. Lu (hjl@gnu.org)

Re: egcs-1.2 stuff

[H.J. Lu]

> 
> On 13 Apr 1999 02:13:52 -0000, craig@jcb-sc.com wrote:
> >>It's a consistency issue.  All the other Makefiles have FLAGS_TO_PASS
> >>defined like so:
> >>
> >>FLAGS_TO_PASS = CC="$(CC)" BISON="$(BISON)" ...
> >>
> >>but libf2c has
> >>
> >>FLAGS_TO_PASS = CC='$(CC)' BISON='$(BISON)' ...
> >>
> >>Therefore, you can't use "" or '' quotes in any of the FLAGS_TO_PASS
> >>variables.  If libf2c used "" quotes, it would be safe to put ''
> >>quotes into FLAGS_TO_PASS variables.  I don't have HJ's patch to look
> >>at, but if it does just what the ChangeLog says it does, I think it's
> >>the Right Thing.
> >
> >Okay, that's all I need to hear...I approve it!
> 
> Now HJ, do you suppose you could've told Craig that yourself, months
> ago, and saved us all the trouble?  <g>
> 

I forwarded an old email of mine to you.

-- 
H.J. Lu (hjl@gnu.org)

Re: egcs-1.2 stuff

[craig]

>Now HJ, do you suppose you could've told Craig that yourself, months
>ago, and saved us all the trouble?  <g>

As you've now seen, he did, long ago, in one of the earlier discussions.

Problem was, we never did have a bug report (meeting the usual definition
of the term), e.g. output from a compile session showing what went
wrong, and I didn't, myself, want to just blindly apply a patch that
Dave Love was hesitant about (IIRC, he thought there'd been some reason
to use ' instead of " earlier), without confirmation of its appropriateness
from at least one other person.

Now we have that confirmation.

BTW, I've written elsewhere about how I prioritize my g77 work.  Since
nobody pays me to do it, that also means there's nobody I can go to (at
the moment) to get marching instructions regarding what to do next.

So, I often use the effort, and quality, a person puts into submitting a
bug report and/or patch, as a fairly substantial weight in my decision-
making process.

I also use repetition of what I call "whines", as in getting several
emails from one person asking "why won't you fix X" but no useful
response when I ask "could you submit a proper bug report" -- but
I use this as a *negative* weight, meaning, the more whining I get about
a problem, the less important I consider it, mainly because I don't
want to encourage that behavior in others.  But there's another reason
as well.

Recent g77 "whines" included no support for AUTOMATIC and giving an
error instead of a warning for READONLY.

After (increasingly pointedly) asking for more substantial info about both,
I finally got some pretty good info (in private email) about AUTOMATIC
from the person that wanted it.  So support for AUTOMATIC went up
on my priority list.  (Who knows when it'll be implemented, but still,
at least I now have some clue about what it's supposed to do.)

I got a *little* bit more info on READONLY, but ended up having to do
the research myself anyway, and discovered that, if I'd just blindly
done what I was asked, the result would have been that g77 would have
become perfectly capable of compiling a program that, when run, *deleted
a file* that it wasn't supposed to!  (I'll be adding to the g77 docs
about this, as well as AUTOMATIC, after finishing up my current megapatch.)

So it's not just that I don't *like* whining.  (I like it fine when *I*
do it...okay, that's an exaggeration.  :)  It's that, in my experience,
people who just whine, rather than say "here's what I need, here's what
I've learned about how it might affect *others*, here's how badly I
need it, here's how I'm working around it for now", are less likely to
have cared enough to *research* the problem -- meaning they effectively
want me to not only *implement* their favorite feature, they want me
to do all the up-front research on whether it'll break things for
others *myself*.

So the quoting patch from HJ, while I'm now assuming won't hurt anyone
else, *was* being treated by me as if it would, pending at least one
other person, in this case a known contributor to egcs, speaking up.
(That was all that was needed, because it was such a trivial "fix" to
apply, assuming it wasn't going to risk making an entire snapshot useless
for g77.  So I'm not saying all I need is one other person saying
"make g77 ignore READONLY" to get me to commit *that* fix, since I now
know doing so would be a bug.)

        tq vm, (burley)

Re: egcs-1.2 stuff

[craig]

>Now HJ, do you suppose you could've told Craig that yourself, months
>ago, and saved us all the trouble?  <g>

As you've now seen, he did, long ago, in one of the earlier discussions.

Problem was, we never did have a bug report (meeting the usual definition
of the term), e.g. output from a compile session showing what went
wrong, and I didn't, myself, want to just blindly apply a patch that
Dave Love was hesitant about (IIRC, he thought there'd been some reason
to use ' instead of " earlier), without confirmation of its appropriateness
from at least one other person.

Now we have that confirmation.

BTW, I've written elsewhere about how I prioritize my g77 work.  Since
nobody pays me to do it, that also means there's nobody I can go to (at
the moment) to get marching instructions regarding what to do next.

So, I often use the effort, and quality, a person puts into submitting a
bug report and/or patch, as a fairly substantial weight in my decision-
making process.

I also use repetition of what I call "whines", as in getting several
emails from one person asking "why won't you fix X" but no useful
response when I ask "could you submit a proper bug report" -- but
I use this as a *negative* weight, meaning, the more whining I get about
a problem, the less important I consider it, mainly because I don't
want to encourage that behavior in others.  But there's another reason
as well.

Recent g77 "whines" included no support for AUTOMATIC and giving an
error instead of a warning for READONLY.

After (increasingly pointedly) asking for more substantial info about both,
I finally got some pretty good info (in private email) about AUTOMATIC
from the person that wanted it.  So support for AUTOMATIC went up
on my priority list.  (Who knows when it'll be implemented, but still,
at least I now have some clue about what it's supposed to do.)

I got a *little* bit more info on READONLY, but ended up having to do
the research myself anyway, and discovered that, if I'd just blindly
done what I was asked, the result would have been that g77 would have
become perfectly capable of compiling a program that, when run, *deleted
a file* that it wasn't supposed to!  (I'll be adding to the g77 docs
about this, as well as AUTOMATIC, after finishing up my current megapatch.)

So it's not just that I don't *like* whining.  (I like it fine when *I*
do it...okay, that's an exaggeration.  :)  It's that, in my experience,
people who just whine, rather than say "here's what I need, here's what
I've learned about how it might affect *others*, here's how badly I
need it, here's how I'm working around it for now", are less likely to
have cared enough to *research* the problem -- meaning they effectively
want me to not only *implement* their favorite feature, they want me
to do all the up-front research on whether it'll break things for
others *myself*.

So the quoting patch from HJ, while I'm now assuming won't hurt anyone
else, *was* being treated by me as if it would, pending at least one
other person, in this case a known contributor to egcs, speaking up.
(That was all that was needed, because it was such a trivial "fix" to
apply, assuming it wasn't going to risk making an entire snapshot useless
for g77.  So I'm not saying all I need is one other person saying
"make g77 ignore READONLY" to get me to commit *that* fix, since I now
know doing so would be a bug.)

        tq vm, (burley)

Re: egcs-1.2 stuff

[Zack Weinberg]

On 13 Apr 1999 02:13:52 -0000, craig@jcb-sc.com wrote:
>>It's a consistency issue.  All the other Makefiles have FLAGS_TO_PASS
>>defined like so:
>>
>>FLAGS_TO_PASS = CC="$(CC)" BISON="$(BISON)" ...
>>
>>but libf2c has
>>
>>FLAGS_TO_PASS = CC='$(CC)' BISON='$(BISON)' ...
>>
>>Therefore, you can't use "" or '' quotes in any of the FLAGS_TO_PASS
>>variables.  If libf2c used "" quotes, it would be safe to put ''
>>quotes into FLAGS_TO_PASS variables.  I don't have HJ's patch to look
>>at, but if it does just what the ChangeLog says it does, I think it's
>>the Right Thing.
>
>Okay, that's all I need to hear...I approve it!

Now HJ, do you suppose you could've told Craig that yourself, months
ago, and saved us all the trouble?  <g>

zw

Re: libf2c FLAGS_TO_PASS [was Re: egcs-1.2 stuff ]

[Jeffrey A Law]

  In message < 19990413021352.2947.qmail@deer >you write:
  > >It's a consistency issue.  All the other Makefiles have FLAGS_TO_PASS
  > >defined like so:
  > >
  > >FLAGS_TO_PASS = CC="$(CC)" BISON="$(BISON)" ...
  > >
  > >but libf2c has
  > >
  > >FLAGS_TO_PASS = CC='$(CC)' BISON='$(BISON)' ...
  > >
  > >Therefore, you can't use "" or '' quotes in any of the FLAGS_TO_PASS
  > >variables.  If libf2c used "" quotes, it would be safe to put ''
  > >quotes into FLAGS_TO_PASS variables.  I don't have HJ's patch to look
  > >at, but if it does just what the ChangeLog says it does, I think it's
  > >the Right Thing.
  > 
  > Okay, that's all I need to hear...I approve it!  Won't commit it tonight,
  > probably, so if Jeff or someone has it handy, they can go ahead...otherwise
  > I'll dig it out soon and apply it myself.
I don't have the patch handy.  

I'd go groping through the archives myself, but the subject on this thread
hasn't been well suited to searching for specific patches until now :-)

HJ, if you have the patch handy and send it, I will install it.  Else I'll
wait for Craig to find it.


jeff

Re: libf2c FLAGS_TO_PASS [was Re: egcs-1.2 stuff ]

[H.J. Lu]

> 
> 
>   In message < 19990413021352.2947.qmail@deer >you write:
>   > >It's a consistency issue.  All the other Makefiles have FLAGS_TO_PASS
>   > >defined like so:
>   > >
>   > >FLAGS_TO_PASS = CC="$(CC)" BISON="$(BISON)" ...
>   > >
>   > >but libf2c has
>   > >
>   > >FLAGS_TO_PASS = CC='$(CC)' BISON='$(BISON)' ...
>   > >
>   > >Therefore, you can't use "" or '' quotes in any of the FLAGS_TO_PASS
>   > >variables.  If libf2c used "" quotes, it would be safe to put ''
>   > >quotes into FLAGS_TO_PASS variables.  I don't have HJ's patch to look
>   > >at, but if it does just what the ChangeLog says it does, I think it's
>   > >the Right Thing.
>   > 
>   > Okay, that's all I need to hear...I approve it!  Won't commit it tonight,
>   > probably, so if Jeff or someone has it handy, they can go ahead...otherwise
>   > I'll dig it out soon and apply it myself.
> I don't have the patch handy.  
> 
> I'd go groping through the archives myself, but the subject on this thread
> hasn't been well suited to searching for specific patches until now :-)
> 
> HJ, if you have the patch handy and send it, I will install it.  Else I'll
> wait for Craig to find it.
> 
> 

http://www.cygnus.com/ml/egcs-patches/1999-Jan/0265.html

Thanks.

-- 
H.J. Lu (hjl@gnu.org)

Re: libf2c FLAGS_TO_PASS [was Re: egcs-1.2 stuff ]

[H.J. Lu]

> 
> 
>   In message < 19990413021352.2947.qmail@deer >you write:
>   > >It's a consistency issue.  All the other Makefiles have FLAGS_TO_PASS
>   > >defined like so:
>   > >
>   > >FLAGS_TO_PASS = CC="$(CC)" BISON="$(BISON)" ...
>   > >
>   > >but libf2c has
>   > >
>   > >FLAGS_TO_PASS = CC='$(CC)' BISON='$(BISON)' ...
>   > >
>   > >Therefore, you can't use "" or '' quotes in any of the FLAGS_TO_PASS
>   > >variables.  If libf2c used "" quotes, it would be safe to put ''
>   > >quotes into FLAGS_TO_PASS variables.  I don't have HJ's patch to look
>   > >at, but if it does just what the ChangeLog says it does, I think it's
>   > >the Right Thing.
>   > 
>   > Okay, that's all I need to hear...I approve it!  Won't commit it tonight,
>   > probably, so if Jeff or someone has it handy, they can go ahead...otherwise
>   > I'll dig it out soon and apply it myself.
> I don't have the patch handy.  
> 
> I'd go groping through the archives myself, but the subject on this thread
> hasn't been well suited to searching for specific patches until now :-)
> 
> HJ, if you have the patch handy and send it, I will install it.  Else I'll
> wait for Craig to find it.
> 
> 

http://www.cygnus.com/ml/egcs-patches/1999-Jan/0265.html

Thanks.

-- 
H.J. Lu (hjl@gnu.org)

Re: libf2c FLAGS_TO_PASS [was Re: egcs-1.2 stuff ]

[Dave Love]

>>>>> "Jeff" == Jeffrey A Law <law@upchuck.cygnus.com> writes:

 >> >I don't have HJ's patch to look 
 >> >at, but if it does just what the ChangeLog says it does, I think it's 
 >> >the Right Thing.

You are very wise.  It doesn't.

[FWIW, IIRC there was a good historical reason for the exact quoting
used from the days of GCC 2.5 or 2.6, so people have had a good chance
to complain.]

 >> Okay, that's all I need to hear...I approve it!  Won't commit it
 >> tonight, probably, so if Jeff or someone has it handy, they can go
 >> ahead...otherwise I'll dig it out soon and apply it myself.

If you don't believe what I said before and don't want my ossifying
fix, please read the Makefile.  Or actually try on the config.status
target.

[It's surely clear that RUNTESTFLAGS is irrelevant to libf2c, at best
a fossil.]

PICFLAG might also get attention depending on whether someone can
explain it or not.

 Jeff> I don't have the patch handy.  

 Jeff> I'd go groping through the archives myself, but the subject on
 Jeff> this thread hasn't been well suited to searching for specific
 Jeff> patches until now :-)

Thanks for changing the Subject: off a thread I killed.

 Jeff> HJ, if you have the patch handy and send it, I will install it.
 Jeff> Else I'll wait for Craig to find it.

Sigh.

Re: libf2c FLAGS_TO_PASS [was Re: egcs-1.2 stuff ]

[Jeffrey A Law]

  In message < rzqg16354r5.fsf@djlvig.dl.ac.uk >you write:
  > >>>>> "Jeff" == Jeffrey A Law <law@upchuck.cygnus.com> writes:
  > 
  >  >> >I don't have HJ's patch to look 
  >  >> >at, but if it does just what the ChangeLog says it does, I think it's 
  >  >> >the Right Thing.
  > 
  > You are very wise.  It doesn't.
  > 
  > [FWIW, IIRC there was a good historical reason for the exact quoting
  > used from the days of GCC 2.5 or 2.6, so people have had a good chance
  > to complain.]
True.  But that also predates inclusion of the runtime libraries within a
single tree.  It also predates moving the runtime libraries out of the libf2c
directory.

There's a nonzero chance that the problems that were solved by the precise
quoting used in the libf2c are not issues anymore.

I don't see any reason why libf2c should be using a different quoting scheme
than everything else.  If it is, then we need to find the reason why.  Either
libf2c is wrong and needs to be fixed, or it is right and the other runtimes
are probably wrong (and need to be fixed).


  >  >> Okay, that's all I need to hear...I approve it!  Won't commit it
  >  >> tonight, probably, so if Jeff or someone has it handy, they can go
  >  >> ahead...otherwise I'll dig it out soon and apply it myself.
  > 
  > If you don't believe what I said before and don't want my ossifying
  > fix, please read the Makefile.  Or actually try on the config.status
  > target.
I certainly believe you.  And I'd like more information about this.  I don't
want to install a patch that is going to screw us later.


  > [It's surely clear that RUNTESTFLAGS is irrelevant to libf2c, at best
  > a fossil.]
Not really.  If we ever made libf2c's testsuite work work like the rest, then
RUNTESTFLAGS would become highly relevant.

  >  Jeff> HJ, if you have the patch handy and send it, I will install it.
  >  Jeff> Else I'll wait for Craig to find it.
  > 
  > Sigh.
Well, let's hold off and discuss it.

jeff

Re: libf2c FLAGS_TO_PASS [was Re: egcs-1.2 stuff ]

[Dave Love]

>>>>> "Jeff" == Jeffrey A Law <law@upchuck.cygnus.com> writes:

 Jeff> There's a nonzero chance that the problems that were solved by
 Jeff> the precise quoting used in the libf2c are not issues anymore.

I mentioned history just to be clear that it wasn't done through
incompetence or cussedness.

 Jeff> I don't see any reason why libf2c should be using a different
 Jeff> quoting scheme than everything else.  If it is, then we need to
 Jeff> find the reason why.  

There's a comment about it even in the context of the bogus patch.  It
may be ambiguous, but M-x occur easily finds the use to set shell
variables (done for maintenance reasons); at the moment I don't see
any need to change that.

 Jeff> If we ever made libf2c's testsuite 

It doesn't have one AFAIK, and I'm not sure it would make sense
separately.  Regardless, it isn't necessary to understand dejagnu to
solve the problem at hand.

 Jeff> work work like the rest, then RUNTESTFLAGS would become highly
 Jeff> relevant.

The remaking stuff in libf2c has broken anyway, making maintenance a
pain, but I don't think it has to be made worse.

I'll send my current diffs for the makefile separately.

Re: libf2c FLAGS_TO_PASS [was Re: egcs-1.2 stuff ]

[Jeffrey A Law]

  In message < rzq676y56m0.fsf@djlvig.dl.ac.uk >you write:
  >  Jeff> I don't see any reason why libf2c should be using a different
  >  Jeff> quoting scheme than everything else.  If it is, then we need to
  >  Jeff> find the reason why.  
  > 
  > There's a comment about it even in the context of the bogus patch.  It
  > may be ambiguous, but M-x occur easily finds the use to set shell
  > variables (done for maintenance reasons); at the moment I don't see
  > any need to change that.
Yea.  I'll note that libchill handles this by doing CC='$(CC)' and similarly
for other variables instead of using FLAGS_TO_PASS in the config.status rule.
libiberty does nothing to pass CC and friends around when running config.status
 libobjc works like libchill.

I think cleaning up this *(@#$ mess ought to be put on the configure/makefile
rewrite list.  Having every runtime library do things a little differently
is just plain dumb.

  >  Jeff> If we ever made libf2c's testsuite 
  > 
  > It doesn't have one AFAIK, and I'm not sure it would make sense
  > separately.  Regardless, it isn't necessary to understand dejagnu to
  > solve the problem at hand.
Sure it makes sense.  There's no reason we can't build a dejagnu testsuite
for libf2c just like we've started doing for libstdc++, libio & libg++.

  >  Jeff> work work like the rest, then RUNTESTFLAGS would become highly
  >  Jeff> relevant.
  > 
  > The remaking stuff in libf2c has broken anyway, making maintenance a
  > pain, but I don't think it has to be made worse.
I don't think that RUNTESTFLAGS is particularly important for the rebuilding
of config.status.  But I don't see the benefit of taking it out.  Every
runtime should pass the same set of flags around in the long term.  Anything
else is dumb.

In fact, I might claim that we should have a single template Makefile and
configury the runtimes and the runtimes should simply plug in a set of subdirs
to build, the sources and library name.   The way we're doing things now is far
from maintainable in the long term.

jeff

Re: libf2c FLAGS_TO_PASS [was Re: egcs-1.2 stuff ]

[Jeffrey A Law]

  In message < rzq676y56m0.fsf@djlvig.dl.ac.uk >you write:
  >  Jeff> I don't see any reason why libf2c should be using a different
  >  Jeff> quoting scheme than everything else.  If it is, then we need to
  >  Jeff> find the reason why.  
  > 
  > There's a comment about it even in the context of the bogus patch.  It
  > may be ambiguous, but M-x occur easily finds the use to set shell
  > variables (done for maintenance reasons); at the moment I don't see
  > any need to change that.
Yea.  I'll note that libchill handles this by doing CC='$(CC)' and similarly
for other variables instead of using FLAGS_TO_PASS in the config.status rule.
libiberty does nothing to pass CC and friends around when running config.status
 libobjc works like libchill.

I think cleaning up this *(@#$ mess ought to be put on the configure/makefile
rewrite list.  Having every runtime library do things a little differently
is just plain dumb.

  >  Jeff> If we ever made libf2c's testsuite 
  > 
  > It doesn't have one AFAIK, and I'm not sure it would make sense
  > separately.  Regardless, it isn't necessary to understand dejagnu to
  > solve the problem at hand.
Sure it makes sense.  There's no reason we can't build a dejagnu testsuite
for libf2c just like we've started doing for libstdc++, libio & libg++.

  >  Jeff> work work like the rest, then RUNTESTFLAGS would become highly
  >  Jeff> relevant.
  > 
  > The remaking stuff in libf2c has broken anyway, making maintenance a
  > pain, but I don't think it has to be made worse.
I don't think that RUNTESTFLAGS is particularly important for the rebuilding
of config.status.  But I don't see the benefit of taking it out.  Every
runtime should pass the same set of flags around in the long term.  Anything
else is dumb.

In fact, I might claim that we should have a single template Makefile and
configury the runtimes and the runtimes should simply plug in a set of subdirs
to build, the sources and library name.   The way we're doing things now is far
from maintainable in the long term.

jeff

Re: libf2c FLAGS_TO_PASS [was Re: egcs-1.2 stuff ]

[Dave Love]

>>>>> "Jeff" == Jeffrey A Law <law@upchuck.cygnus.com> writes:

 Jeff> There's a nonzero chance that the problems that were solved by
 Jeff> the precise quoting used in the libf2c are not issues anymore.

I mentioned history just to be clear that it wasn't done through
incompetence or cussedness.

 Jeff> I don't see any reason why libf2c should be using a different
 Jeff> quoting scheme than everything else.  If it is, then we need to
 Jeff> find the reason why.  

There's a comment about it even in the context of the bogus patch.  It
may be ambiguous, but M-x occur easily finds the use to set shell
variables (done for maintenance reasons); at the moment I don't see
any need to change that.

 Jeff> If we ever made libf2c's testsuite 

It doesn't have one AFAIK, and I'm not sure it would make sense
separately.  Regardless, it isn't necessary to understand dejagnu to
solve the problem at hand.

 Jeff> work work like the rest, then RUNTESTFLAGS would become highly
 Jeff> relevant.

The remaking stuff in libf2c has broken anyway, making maintenance a
pain, but I don't think it has to be made worse.

I'll send my current diffs for the makefile separately.

Re: libf2c FLAGS_TO_PASS [was Re: egcs-1.2 stuff ]

[craig]

>Well, let's hold off and discuss it.

If I get to this, I'll try a build with the patch in, and maybe play
a little.  If I don't see a problem, why not just check it in, and
see if it breaks things?  I take Dave's concerns seriously, but if I
can't get a clear description of the problems double-quoting would
introduce, sufficient to override Jeff's valid point about consistency
wrt other libraries, then that might be the time to bazaarize the
patch and see whether a bunch more eyes help.

        tq vm, (burley)

Re: libf2c FLAGS_TO_PASS [was Re: egcs-1.2 stuff ]

[Jeffrey A Law]

  In message < 19990415135929.23354.qmail@deer >you write:
  > If I get to this, I'll try a build with the patch in, and maybe play
  > a little.  If I don't see a problem, why not just check it in, and
  > see if it breaks things?
Well, that's not really the attitude we want to have.  Though I do think I
understand what you're trying to say :-)

  > I take Dave's concerns seriously, but if I
  > can't get a clear description of the problems double-quoting would
  > introduce, sufficient to override Jeff's valid point about consistency
  > wrt other libraries, then that might be the time to bazaarize the
  > patch and see whether a bunch more eyes help.
It looks to me the problem is consistency when we run config.status after
something like configure changes.

What I don't get is why we pass these things around when doing that anyway,
isn't this stuff actually embedded in config.status?  Is it right for a
rebuild to use potentially different values for those variables?

Or is the setting of those variables solely to make the _tests_ run by
configure/config.status work properly?  In which case we probably can settle
on a set of variables that need to be passed with the different quoting
scheme and arrange to pass them to all the runtime libraries so that we don't
have to always go into the runtime lib dirs if we need to update that list.

Depending on the various answers and the amount of work each entails we may
take different directions -- for example, we might decide the issue simply
isn't important enough to risk revamping this stuff this close to egcs-1.2.
Or we may decide that HJ's patch is good enough for egcs-1.2.  Or we may
decide that we can unify this particular issue in the runtimes easily and do
it now.  Or just about anything in between.

The important thing is to get our facts & options together quickly so that we
can make informed decisions.


jeff

Re: libf2c FLAGS_TO_PASS [was Re: egcs-1.2 stuff ]

[Jeffrey A Law]

  In message < 19990415135929.23354.qmail@deer >you write:
  > If I get to this, I'll try a build with the patch in, and maybe play
  > a little.  If I don't see a problem, why not just check it in, and
  > see if it breaks things?
Well, that's not really the attitude we want to have.  Though I do think I
understand what you're trying to say :-)

  > I take Dave's concerns seriously, but if I
  > can't get a clear description of the problems double-quoting would
  > introduce, sufficient to override Jeff's valid point about consistency
  > wrt other libraries, then that might be the time to bazaarize the
  > patch and see whether a bunch more eyes help.
It looks to me the problem is consistency when we run config.status after
something like configure changes.

What I don't get is why we pass these things around when doing that anyway,
isn't this stuff actually embedded in config.status?  Is it right for a
rebuild to use potentially different values for those variables?

Or is the setting of those variables solely to make the _tests_ run by
configure/config.status work properly?  In which case we probably can settle
on a set of variables that need to be passed with the different quoting
scheme and arrange to pass them to all the runtime libraries so that we don't
have to always go into the runtime lib dirs if we need to update that list.

Depending on the various answers and the amount of work each entails we may
take different directions -- for example, we might decide the issue simply
isn't important enough to risk revamping this stuff this close to egcs-1.2.
Or we may decide that HJ's patch is good enough for egcs-1.2.  Or we may
decide that we can unify this particular issue in the runtimes easily and do
it now.  Or just about anything in between.

The important thing is to get our facts & options together quickly so that we
can make informed decisions.


jeff

Re: libf2c FLAGS_TO_PASS [was Re: egcs-1.2 stuff ]

[craig]

>Well, let's hold off and discuss it.

If I get to this, I'll try a build with the patch in, and maybe play
a little.  If I don't see a problem, why not just check it in, and
see if it breaks things?  I take Dave's concerns seriously, but if I
can't get a clear description of the problems double-quoting would
introduce, sufficient to override Jeff's valid point about consistency
wrt other libraries, then that might be the time to bazaarize the
patch and see whether a bunch more eyes help.

        tq vm, (burley)

Re: libf2c FLAGS_TO_PASS [was Re: egcs-1.2 stuff ]

[Jeffrey A Law]

  In message < rzqg16354r5.fsf@djlvig.dl.ac.uk >you write:
  > >>>>> "Jeff" == Jeffrey A Law <law@upchuck.cygnus.com> writes:
  > 
  >  >> >I don't have HJ's patch to look 
  >  >> >at, but if it does just what the ChangeLog says it does, I think it's 
  >  >> >the Right Thing.
  > 
  > You are very wise.  It doesn't.
  > 
  > [FWIW, IIRC there was a good historical reason for the exact quoting
  > used from the days of GCC 2.5 or 2.6, so people have had a good chance
  > to complain.]
True.  But that also predates inclusion of the runtime libraries within a
single tree.  It also predates moving the runtime libraries out of the libf2c
directory.

There's a nonzero chance that the problems that were solved by the precise
quoting used in the libf2c are not issues anymore.

I don't see any reason why libf2c should be using a different quoting scheme
than everything else.  If it is, then we need to find the reason why.  Either
libf2c is wrong and needs to be fixed, or it is right and the other runtimes
are probably wrong (and need to be fixed).


  >  >> Okay, that's all I need to hear...I approve it!  Won't commit it
  >  >> tonight, probably, so if Jeff or someone has it handy, they can go
  >  >> ahead...otherwise I'll dig it out soon and apply it myself.
  > 
  > If you don't believe what I said before and don't want my ossifying
  > fix, please read the Makefile.  Or actually try on the config.status
  > target.
I certainly believe you.  And I'd like more information about this.  I don't
want to install a patch that is going to screw us later.


  > [It's surely clear that RUNTESTFLAGS is irrelevant to libf2c, at best
  > a fossil.]
Not really.  If we ever made libf2c's testsuite work work like the rest, then
RUNTESTFLAGS would become highly relevant.

  >  Jeff> HJ, if you have the patch handy and send it, I will install it.
  >  Jeff> Else I'll wait for Craig to find it.
  > 
  > Sigh.
Well, let's hold off and discuss it.

jeff

Re: libf2c FLAGS_TO_PASS [was Re: egcs-1.2 stuff ]

[Dave Love]

>>>>> "Jeff" == Jeffrey A Law <law@upchuck.cygnus.com> writes:

 >> >I don't have HJ's patch to look 
 >> >at, but if it does just what the ChangeLog says it does, I think it's 
 >> >the Right Thing.

You are very wise.  It doesn't.

[FWIW, IIRC there was a good historical reason for the exact quoting
used from the days of GCC 2.5 or 2.6, so people have had a good chance
to complain.]

 >> Okay, that's all I need to hear...I approve it!  Won't commit it
 >> tonight, probably, so if Jeff or someone has it handy, they can go
 >> ahead...otherwise I'll dig it out soon and apply it myself.

If you don't believe what I said before and don't want my ossifying
fix, please read the Makefile.  Or actually try on the config.status
target.

[It's surely clear that RUNTESTFLAGS is irrelevant to libf2c, at best
a fossil.]

PICFLAG might also get attention depending on whether someone can
explain it or not.

 Jeff> I don't have the patch handy.  

 Jeff> I'd go groping through the archives myself, but the subject on
 Jeff> this thread hasn't been well suited to searching for specific
 Jeff> patches until now :-)

Thanks for changing the Subject: off a thread I killed.

 Jeff> HJ, if you have the patch handy and send it, I will install it.
 Jeff> Else I'll wait for Craig to find it.

Sigh.

Re: libf2c FLAGS_TO_PASS [was Re: egcs-1.2 stuff ]

[Jeffrey A Law]

  In message < 19990413021352.2947.qmail@deer >you write:
  > >It's a consistency issue.  All the other Makefiles have FLAGS_TO_PASS
  > >defined like so:
  > >
  > >FLAGS_TO_PASS = CC="$(CC)" BISON="$(BISON)" ...
  > >
  > >but libf2c has
  > >
  > >FLAGS_TO_PASS = CC='$(CC)' BISON='$(BISON)' ...
  > >
  > >Therefore, you can't use "" or '' quotes in any of the FLAGS_TO_PASS
  > >variables.  If libf2c used "" quotes, it would be safe to put ''
  > >quotes into FLAGS_TO_PASS variables.  I don't have HJ's patch to look
  > >at, but if it does just what the ChangeLog says it does, I think it's
  > >the Right Thing.
  > 
  > Okay, that's all I need to hear...I approve it!  Won't commit it tonight,
  > probably, so if Jeff or someone has it handy, they can go ahead...otherwise
  > I'll dig it out soon and apply it myself.
I don't have the patch handy.  

I'd go groping through the archives myself, but the subject on this thread
hasn't been well suited to searching for specific patches until now :-)

HJ, if you have the patch handy and send it, I will install it.  Else I'll
wait for Craig to find it.


jeff

Re: egcs-1.2 stuff

[craig]

>It's a consistency issue.  All the other Makefiles have FLAGS_TO_PASS
>defined like so:
>
>FLAGS_TO_PASS = CC="$(CC)" BISON="$(BISON)" ...
>
>but libf2c has
>
>FLAGS_TO_PASS = CC='$(CC)' BISON='$(BISON)' ...
>
>Therefore, you can't use "" or '' quotes in any of the FLAGS_TO_PASS
>variables.  If libf2c used "" quotes, it would be safe to put ''
>quotes into FLAGS_TO_PASS variables.  I don't have HJ's patch to look
>at, but if it does just what the ChangeLog says it does, I think it's
>the Right Thing.

Okay, that's all I need to hear...I approve it!  Won't commit it tonight,
probably, so if Jeff or someone has it handy, they can go ahead...otherwise,
I'll dig it out soon and apply it myself.

>This is yet another way the build framework is too complicated.

Yup.

        tq vm, (burley)

Re: egcs-1.2 stuff

[Zack Weinberg]

On 12 Apr 1999 17:16:42 -0000, craig@jcb-sc.com wrote:
>>BTW, what happened to my patch to libf2c/Makefile.in:
>>
>>Fri Jan 15 07:06:25 1999  H.J. Lu  (hjl@gnu.org)
>>
>>        * Makefile.in (FLAGS_TO_PASS): Use "" instead of ''.
>>
>>I need it to add
>>
>>RUNTESTFLAGS=--tool_opts '-mcpu=pentiumpro -march=pentiumpro'
>>
>>and
>>
>>RUNTESTFLAGS=--tool_opts '-mcpu=pentiumpro -march=pentiumpro -fPIC'
>>
>>to the top level Makefile. It is useful to run testsuites for PPro and
>>PIC. Does anyone else run testsuites for PPro on libf2c? I have
>>complained about libf2c many times. Does anyone from libf2c really have
>>time to listen and care?
>
>It's in my queue, from back when you complained about this for the Nth
>time.
[...]
>Of course, I welcome anyone who *already* understands those things
>stepping in and saying "here's the *right* way to do stuff like this",
>but that hasn't happened yet, AFAIK.

It's a consistency issue.  All the other Makefiles have FLAGS_TO_PASS
defined like so:

FLAGS_TO_PASS = CC="$(CC)" BISON="$(BISON)" ...

but libf2c has

FLAGS_TO_PASS = CC='$(CC)' BISON='$(BISON)' ...

Therefore, you can't use "" or '' quotes in any of the FLAGS_TO_PASS
variables.  If libf2c used "" quotes, it would be safe to put ''
quotes into FLAGS_TO_PASS variables.  I don't have HJ's patch to look
at, but if it does just what the ChangeLog says it does, I think it's
the Right Thing.

This is yet another way the build framework is too complicated.

zw

Re: egcs-1.2 stuff

[craig]

>BTW, what happened to my patch to libf2c/Makefile.in:
>
>Fri Jan 15 07:06:25 1999  H.J. Lu  (hjl@gnu.org)
>
>        * Makefile.in (FLAGS_TO_PASS): Use "" instead of ''.
>
>I need it to add
>
>RUNTESTFLAGS=--tool_opts '-mcpu=pentiumpro -march=pentiumpro'
>
>and
>
>RUNTESTFLAGS=--tool_opts '-mcpu=pentiumpro -march=pentiumpro -fPIC'
>
>to the top level Makefile. It is useful to run testsuites for PPro and
>PIC. Does anyone else run testsuites for PPro on libf2c? I have
>complained about libf2c many times. Does anyone from libf2c really have
>time to listen and care?

It's in my queue, from back when you complained about this for the Nth
time.

And, like before, I'll ask you for a proper *bug report* or a properly
researched *patch*, if you want this to become higher priority than
it is for me right now.  As it stands, I'll look at it only when I feel
I have the time to study all of the issues (runtest, expect, tcl, shell
quoting rules, etc.) myself, and that does *not* seem like low-hanging
fruit to me.

Of course, I welcome anyone who *already* understands those things
stepping in and saying "here's the *right* way to do stuff like this",
but that hasn't happened yet, AFAIK.

        tq vm, (burley)

Re: egcs-1.2 stuff

[H.J. Lu]

> 
> Anyway, here's the diffs against the current tree.  Even if you find the
> problem, I would still like John to review the patch before it goes into
> the tree.  I'm simply not qualified to review this code.
> 

Just curious. With your patch, I couldn't even pass "make bootstrap".
I got:

Bootstrap comparison failure!
cccp.o differs
cse.o differs
cxxmain.o differs
emit-rtl.o differs
except.o differs
expmed.o differs
expr.o differs
fold-const.o differs
gcc.o differs
gcse.o differs
genattr.o differs
genattrtab.o differs
......


I have been using

BOOT_CFLAGS=-mcpu=pentiumpro -march=pentiumpro -O2 -g 

BTW, what happened to my patch to libf2c/Makefile.in:

Fri Jan 15 07:06:25 1999  H.J. Lu  (hjl@gnu.org)

        * Makefile.in (FLAGS_TO_PASS): Use "" instead of ''.

I need it to add

RUNTESTFLAGS=--tool_opts '-mcpu=pentiumpro -march=pentiumpro'

and

RUNTESTFLAGS=--tool_opts '-mcpu=pentiumpro -march=pentiumpro -fPIC'

to the top level Makefile. It is useful to run testsuites for PPro and
PIC. Does anyone else run testsuites for PPro on libf2c? I have
complained about libf2c many times. Does anyone from libf2c really have
time to listen and care?

Thanks.

H.J.

Re: egcs-1.2 stuff

[H.J. Lu]

> Interesting.  I wonder if the patch got mis-applied.  Quite possible since
> the patch is old.
> 

I applied your patch and fixed the bugs in it. This is what I got by
adding "-mcpu=pentiumpro -march=pentiumpro" to CFLAGS. I didn't find
any regressions.

Please let me know which patch you want, against yours or CVS.

Thanks.


H.J.
----
FAIL: g++.dg/special/conpr-1.C execution test
FAIL: g++.dg/special/conpr-2.C execution test
FAIL: g++.dg/special/conpr-3.C execution test
FAIL: g++.dg/special/conpr-3.C execution test
FAIL: g77.f-torture/execute/19990325-0.f execution,  -O0 
FAIL: g77.f-torture/execute/19990325-0.f execution,  -O1 
FAIL: g77.f-torture/execute/19990325-0.f execution,  -O2 
FAIL: g77.f-torture/execute/19990325-0.f execution,  -O2 -fomit-frame-pointer -finline-functions 
FAIL: g77.f-torture/execute/19990325-0.f execution,  -Os 
FAIL: g77.f-torture/execute/19990325-1.f execution,  -O0 
FAIL: g77.f-torture/execute/19990325-1.f execution,  -O1 
FAIL: g77.f-torture/execute/19990325-1.f execution,  -O2 
FAIL: g77.f-torture/execute/19990325-1.f execution,  -O2 -fomit-frame-pointer -finline-functions 
FAIL: g77.f-torture/execute/19990325-1.f execution,  -Os 
FAIL: g77.f-torture/execute/970625-2.f compilation,  -O1 
FAIL: gcc.c-torture/execute/990130-1.c compilation,  -O0 
FAIL: gcc.c-torture/execute/990130-1.c compilation,  -O1 
FAIL: gcc.c-torture/execute/990130-1.c compilation,  -O2 
FAIL: gcc.c-torture/execute/990130-1.c compilation,  -O3 -fomit-frame-pointer 
FAIL: gcc.c-torture/execute/990130-1.c compilation,  -O3 -g 
FAIL: gcc.c-torture/execute/990130-1.c compilation,  -Os 
FAIL: gcc.dg/990119-1.c execution test
FAIL: gcc.dg/special/weak-1.c execution test
FAIL: objc/execute/bf-1.m compilation,  -O 
FAIL: objc/execute/bf-10.m compilation,  -O 
FAIL: objc/execute/bf-11.m compilation,  -O 
FAIL: objc/execute/bf-12.m compilation,  -O 
FAIL: objc/execute/bf-13.m compilation,  -O 
FAIL: objc/execute/bf-14.m compilation,  -O 
FAIL: objc/execute/bf-15.m compilation,  -O 
FAIL: objc/execute/bf-16.m compilation,  -O 
FAIL: objc/execute/bf-17.m compilation,  -O 
FAIL: objc/execute/bf-18.m compilation,  -O 
FAIL: objc/execute/bf-19.m compilation,  -O 
FAIL: objc/execute/bf-2.m compilation,  -O 
FAIL: objc/execute/bf-3.m compilation,  -O 
FAIL: objc/execute/bf-4.m compilation,  -O 
FAIL: objc/execute/bf-5.m compilation,  -O 
FAIL: objc/execute/bf-6.m compilation,  -O 
FAIL: objc/execute/bf-7.m compilation,  -O 
FAIL: objc/execute/bf-8.m compilation,  -O 
FAIL: objc/execute/bf-9.m compilation,  -O 

Re: egcs-1.2 stuff

[Jeffrey A Law]

  In message < m10WkA2-000ErMC@ocean.lucon.org >you write:
  > > Interesting.  I wonder if the patch got mis-applied.  Quite possible sinc
  > e
  > > the patch is old.
  > > 
  > 
  > I applied your patch and fixed the bugs in it. This is what I got by
  > adding "-mcpu=pentiumpro -march=pentiumpro" to CFLAGS. I didn't find
  > any regressions.
  > 
  > Please let me know which patch you want, against yours or CVS.
Against CVS would be best.  Thanks!

What was the problem?
jeff

Re: egcs-1.2 stuff

[H.J. Lu]

> 
> 
>   In message < m10WkA2-000ErMC@ocean.lucon.org >you write:
>   > > Interesting.  I wonder if the patch got mis-applied.  Quite possible sinc
>   > e
>   > > the patch is old.
>   > > 
>   > 
>   > I applied your patch and fixed the bugs in it. This is what I got by
>   > adding "-mcpu=pentiumpro -march=pentiumpro" to CFLAGS. I didn't find
>   > any regressions.
>   > 
>   > Please let me know which patch you want, against yours or CVS.
> Against CVS would be best.  Thanks!

I will do that. It may take a while. I am updating it now.

> 
> What was the problem?
> jeff
> 

You left out the following changes.


-- 
H.J. Lu (hjl@gnu.org)
----
--- /tmp/i386.c	Mon Apr 12 13:33:24 1999
+++ ./i386.c	Mon Apr 12 09:08:25 1999
@@ -3187,7 +3187,8 @@ put_jump_code (code, reverse, file)
      FILE *file;
 {
   int flags = cc_prev_status.flags;
-  int ieee = (TARGET_IEEE_FP && (flags & CC_IN_80387));
+  int ieee = (TARGET_IEEE_FP && (flags & CC_IN_80387)
+	      && !(cc_prev_status.flags & CC_FCOMI));
   const char *suffix;
 
   if (flags & CC_Z_IN_NOT_C)
@@ -4288,8 +4289,7 @@ output_float_compare (insn, operands)
 	    {
 	      output_asm_insn (AS2 (fcomip, %y1,%0), operands);
 	      output_asm_insn (AS1 (fstp, %y0), operands);
-	      if (!TARGET_IEEE_FP)
-		return "";
+	      return "";
 	    }
 	  else
 	    output_asm_insn ("fcompp", operands);

Re: egcs-1.2 stuff

[Jeffrey A Law]

  In message < m10WnRe-000ErMC@ocean.lucon.org >you write:
  > > 
  > > 
  > >   In message < m10WkA2-000ErMC@ocean.lucon.org >you write:
  > >   > > Interesting.  I wonder if the patch got mis-applied.  Quite possibl
  > e sinc
  > >   > e
  > >   > > the patch is old.
  > >   > > 
  > >   > 
  > >   > I applied your patch and fixed the bugs in it. This is what I got by
  > >   > adding "-mcpu=pentiumpro -march=pentiumpro" to CFLAGS. I didn't find
  > >   > any regressions.
  > >   > 
  > >   > Please let me know which patch you want, against yours or CVS.
  > > Against CVS would be best.  Thanks!
  > 
  > I will do that. It may take a while. I am updating it now.
  > 
  > > 
  > > What was the problem?
  > > jeff
  > > 
  > 
  > You left out the following changes.
Err, I beg to differ.  I went and pulled your patch out of the archives.
Your patch does not modify put_jump_code in any way shape or form.  I didn't
leave that part of the patch out, you did.  I'm not sure what happened with
the second hunk since I applied the patch you sent to the list.  Presumably
it was wrong or was mis-applied by patch.

You should be more careful -- I wasted quite a bit of time sorting through
that stuff.

In any event, hopefully John will be able to review the updated patch soon.

Thanks,
jeff

Re: egcs-1.2 stuff

[Jeffrey A Law]

  In message < m10WnRe-000ErMC@ocean.lucon.org >you write:
  > > 
  > > 
  > >   In message < m10WkA2-000ErMC@ocean.lucon.org >you write:
  > >   > > Interesting.  I wonder if the patch got mis-applied.  Quite possibl
  > e sinc
  > >   > e
  > >   > > the patch is old.
  > >   > > 
  > >   > 
  > >   > I applied your patch and fixed the bugs in it. This is what I got by
  > >   > adding "-mcpu=pentiumpro -march=pentiumpro" to CFLAGS. I didn't find
  > >   > any regressions.
  > >   > 
  > >   > Please let me know which patch you want, against yours or CVS.
  > > Against CVS would be best.  Thanks!
  > 
  > I will do that. It may take a while. I am updating it now.
  > 
  > > 
  > > What was the problem?
  > > jeff
  > > 
  > 
  > You left out the following changes.
Err, I beg to differ.  I went and pulled your patch out of the archives.
Your patch does not modify put_jump_code in any way shape or form.  I didn't
leave that part of the patch out, you did.  I'm not sure what happened with
the second hunk since I applied the patch you sent to the list.  Presumably
it was wrong or was mis-applied by patch.

You should be more careful -- I wasted quite a bit of time sorting through
that stuff.

In any event, hopefully John will be able to review the updated patch soon.

Thanks,
jeff

Re: egcs-1.2 stuff

[H.J. Lu]

> 
> 
>   In message < m10WkA2-000ErMC@ocean.lucon.org >you write:
>   > > Interesting.  I wonder if the patch got mis-applied.  Quite possible sinc
>   > e
>   > > the patch is old.
>   > > 
>   > 
>   > I applied your patch and fixed the bugs in it. This is what I got by
>   > adding "-mcpu=pentiumpro -march=pentiumpro" to CFLAGS. I didn't find
>   > any regressions.
>   > 
>   > Please let me know which patch you want, against yours or CVS.
> Against CVS would be best.  Thanks!

I will do that. It may take a while. I am updating it now.

> 
> What was the problem?
> jeff
> 

You left out the following changes.


-- 
H.J. Lu (hjl@gnu.org)
----
--- /tmp/i386.c	Mon Apr 12 13:33:24 1999
+++ ./i386.c	Mon Apr 12 09:08:25 1999
@@ -3187,7 +3187,8 @@ put_jump_code (code, reverse, file)
      FILE *file;
 {
   int flags = cc_prev_status.flags;
-  int ieee = (TARGET_IEEE_FP && (flags & CC_IN_80387));
+  int ieee = (TARGET_IEEE_FP && (flags & CC_IN_80387)
+	      && !(cc_prev_status.flags & CC_FCOMI));
   const char *suffix;
 
   if (flags & CC_Z_IN_NOT_C)
@@ -4288,8 +4289,7 @@ output_float_compare (insn, operands)
 	    {
 	      output_asm_insn (AS2 (fcomip, %y1,%0), operands);
 	      output_asm_insn (AS1 (fstp, %y0), operands);
-	      if (!TARGET_IEEE_FP)
-		return "";
+	      return "";
 	    }
 	  else
 	    output_asm_insn ("fcompp", operands);

Re: egcs-1.2 stuff

[Jeffrey A Law]

  In message < m10WkA2-000ErMC@ocean.lucon.org >you write:
  > > Interesting.  I wonder if the patch got mis-applied.  Quite possible sinc
  > e
  > > the patch is old.
  > > 
  > 
  > I applied your patch and fixed the bugs in it. This is what I got by
  > adding "-mcpu=pentiumpro -march=pentiumpro" to CFLAGS. I didn't find
  > any regressions.
  > 
  > Please let me know which patch you want, against yours or CVS.
Against CVS would be best.  Thanks!

What was the problem?
jeff

Re: egcs-1.2 stuff

[H.J. Lu]

> Interesting.  I wonder if the patch got mis-applied.  Quite possible since
> the patch is old.
> 

I applied your patch and fixed the bugs in it. This is what I got by
adding "-mcpu=pentiumpro -march=pentiumpro" to CFLAGS. I didn't find
any regressions.

Please let me know which patch you want, against yours or CVS.

Thanks.


H.J.
----
FAIL: g++.dg/special/conpr-1.C execution test
FAIL: g++.dg/special/conpr-2.C execution test
FAIL: g++.dg/special/conpr-3.C execution test
FAIL: g++.dg/special/conpr-3.C execution test
FAIL: g77.f-torture/execute/19990325-0.f execution,  -O0 
FAIL: g77.f-torture/execute/19990325-0.f execution,  -O1 
FAIL: g77.f-torture/execute/19990325-0.f execution,  -O2 
FAIL: g77.f-torture/execute/19990325-0.f execution,  -O2 -fomit-frame-pointer -finline-functions 
FAIL: g77.f-torture/execute/19990325-0.f execution,  -Os 
FAIL: g77.f-torture/execute/19990325-1.f execution,  -O0 
FAIL: g77.f-torture/execute/19990325-1.f execution,  -O1 
FAIL: g77.f-torture/execute/19990325-1.f execution,  -O2 
FAIL: g77.f-torture/execute/19990325-1.f execution,  -O2 -fomit-frame-pointer -finline-functions 
FAIL: g77.f-torture/execute/19990325-1.f execution,  -Os 
FAIL: g77.f-torture/execute/970625-2.f compilation,  -O1 
FAIL: gcc.c-torture/execute/990130-1.c compilation,  -O0 
FAIL: gcc.c-torture/execute/990130-1.c compilation,  -O1 
FAIL: gcc.c-torture/execute/990130-1.c compilation,  -O2 
FAIL: gcc.c-torture/execute/990130-1.c compilation,  -O3 -fomit-frame-pointer 
FAIL: gcc.c-torture/execute/990130-1.c compilation,  -O3 -g 
FAIL: gcc.c-torture/execute/990130-1.c compilation,  -Os 
FAIL: gcc.dg/990119-1.c execution test
FAIL: gcc.dg/special/weak-1.c execution test
FAIL: objc/execute/bf-1.m compilation,  -O 
FAIL: objc/execute/bf-10.m compilation,  -O 
FAIL: objc/execute/bf-11.m compilation,  -O 
FAIL: objc/execute/bf-12.m compilation,  -O 
FAIL: objc/execute/bf-13.m compilation,  -O 
FAIL: objc/execute/bf-14.m compilation,  -O 
FAIL: objc/execute/bf-15.m compilation,  -O 
FAIL: objc/execute/bf-16.m compilation,  -O 
FAIL: objc/execute/bf-17.m compilation,  -O 
FAIL: objc/execute/bf-18.m compilation,  -O 
FAIL: objc/execute/bf-19.m compilation,  -O 
FAIL: objc/execute/bf-2.m compilation,  -O 
FAIL: objc/execute/bf-3.m compilation,  -O 
FAIL: objc/execute/bf-4.m compilation,  -O 
FAIL: objc/execute/bf-5.m compilation,  -O 
FAIL: objc/execute/bf-6.m compilation,  -O 
FAIL: objc/execute/bf-7.m compilation,  -O 
FAIL: objc/execute/bf-8.m compilation,  -O 
FAIL: objc/execute/bf-9.m compilation,  -O 

Re: egcs-1.2 stuff

[Jeffrey A Law]

  In message < m10Tp9T-000ErMC@ocean.lucon.org >you write:
  > 
  > >   > I am enclosing the failures I got with egcs in CVS at 10:15am on Apr.
  > >   > 3 plus my CC_FCOMI patch using -march=pentiumpro -mcpu=pentiumpro. Ho
  > w
  > >   > does it compare with your results?
  > > I only used "-march=pentiumpro -O1"   Please verify using the compiler
  > > options I specified in my message.  When you use different options you
  > > make your testresults worthless.
  > 
  > I have been using -march=pentiumpro -mcpu=pentiumpro to run "make check"
  > for every egcs I build. I didn't make that one for you. I am doing
When trying to look for a specific problem you should try to perform the
exact same test.  Otherwise you introduce additional variables into the test
which is poor programming/debugging practice.

  > > 
  > > I just tried it again from the CVS tree.  Without your patch it runs fine
  > ,
  > > with your patch it aborts.
  > 
  > Can you send me the patch you used? I like to see why it fails.
Attached at the end of this message.

To recap when I add the fcomi patch 930614-1.c fails when compiled with
"-O1 -march=pentiumpro".


  > That is the difference between yours and mine. I want to know why you
  > get the wrong result. I need the patch you used to see it myself.
  > 
  > @@ -36,7 +36,7 @@
  >  	fldl -72(%ebp)
  >  	fldz
  >  	fcomip %st(1),%st
  > -	jne .L8
  > +	jbe .L8
  >  	fchs
  >  	fstpl -72(%ebp)
  >  	jmp .L4
Interesting.  I wonder if the patch got mis-applied.  Quite possible since
the patch is old.

Anyway, here's the diffs against the current tree.  Even if you find the
problem, I would still like John to review the patch before it goes into
the tree.  I'm simply not qualified to review this code.


Index: i386.c
===================================================================
RCS file: /egcs/carton/cvsfiles/egcs/gcc/config/i386/i386.c,v
retrieving revision 1.60
diff -c -3 -p -r1.60 i386.c
*** i386.c	1999/04/10 17:18:06	1.60
--- i386.c	1999/04/12 09:53:23
*************** notice_update_cc (exp)
*** 3896,3902 ****
            if (stack_regs_mentioned_p (SET_SRC (XVECEXP (exp, 0, 0))))
  	    {
                cc_status.flags |= CC_IN_80387;
! 	      if (0 && TARGET_CMOVE && stack_regs_mentioned_p
  		  (XEXP (SET_SRC (XVECEXP (exp, 0, 0)), 1)))
  		cc_status.flags |= CC_FCOMI;
  	    }
--- 3896,3902 ----
            if (stack_regs_mentioned_p (SET_SRC (XVECEXP (exp, 0, 0))))
  	    {
                cc_status.flags |= CC_IN_80387;
! 	      if (TARGET_CMOVE && stack_regs_mentioned_p
  		  (XEXP (SET_SRC (XVECEXP (exp, 0, 0)), 1)))
  		cc_status.flags |= CC_FCOMI;
  	    }
*************** output_float_compare (insn, operands)
*** 4194,4200 ****
    int unordered_compare = GET_MODE (SET_SRC (body)) == CCFPEQmode;
    rtx tmp;
  
!   if (0 && TARGET_CMOVE && STACK_REG_P (operands[1]))
      {
        cc_status.flags |= CC_FCOMI;
        cc_prev_status.flags &= ~CC_TEST_AX;
--- 4194,4200 ----
    int unordered_compare = GET_MODE (SET_SRC (body)) == CCFPEQmode;
    rtx tmp;
  
!   if (TARGET_CMOVE && STACK_REG_P (operands[1]))
      {
        cc_status.flags |= CC_FCOMI;
        cc_prev_status.flags &= ~CC_TEST_AX;
*************** output_float_compare (insn, operands)
*** 4228,4234 ****
  	    {
  	      output_asm_insn (AS2 (fucomip,%y1,%0), operands);
  	      output_asm_insn (AS1 (fstp, %y0), operands);
! 	      return "";
  	    }
  	  else
  	    output_asm_insn ("fucompp", operands);
--- 4228,4235 ----
  	    {
  	      output_asm_insn (AS2 (fucomip,%y1,%0), operands);
  	      output_asm_insn (AS1 (fstp, %y0), operands);
! 	      if (!TARGET_IEEE_FP)
! 		return "";
  	    }
  	  else
  	    output_asm_insn ("fucompp", operands);
*************** output_float_compare (insn, operands)
*** 4239,4245 ****
  	    {
  	      output_asm_insn (AS2 (fcomip, %y1,%0), operands);
  	      output_asm_insn (AS1 (fstp, %y0), operands);
! 	      return "";
  	    }
  	  else
  	    output_asm_insn ("fcompp", operands);
--- 4240,4247 ----
  	    {
  	      output_asm_insn (AS2 (fcomip, %y1,%0), operands);
  	      output_asm_insn (AS1 (fstp, %y0), operands);
! 	      if (!TARGET_IEEE_FP)
! 		return "";
  	    }
  	  else
  	    output_asm_insn ("fcompp", operands);
*************** output_float_compare (insn, operands)
*** 4264,4270 ****
        if (cc_status.flags & CC_FCOMI)
  	{
  	  output_asm_insn (strcat (buf, AS2 (%z1,%y1,%0)), operands);
! 	  return "";
  	}
        else
          output_asm_insn (strcat (buf, AS1 (%z1,%y1)), operands);
--- 4266,4273 ----
        if (cc_status.flags & CC_FCOMI)
  	{
  	  output_asm_insn (strcat (buf, AS2 (%z1,%y1,%0)), operands);
! 	  if (!TARGET_IEEE_FP)
! 	    return "";
  	}
        else
          output_asm_insn (strcat (buf, AS1 (%z1,%y1)), operands);
*************** output_fp_cc0_set (insn)
*** 4288,4304 ****
    rtx next;
    enum rtx_code code;
  
!   xops[0] = gen_rtx_REG (HImode, 0);
!   output_asm_insn (AS1 (fnsts%W0,%0), xops);
  
    if (! TARGET_IEEE_FP)
      {
        if (!(cc_status.flags & CC_REVERSED))
          {
            next = next_cc0_user (insn);
! 
!           if (GET_CODE (next) == JUMP_INSN
!               && GET_CODE (PATTERN (next)) == SET
                && SET_DEST (PATTERN (next)) == pc_rtx
                && GET_CODE (SET_SRC (PATTERN (next))) == IF_THEN_ELSE)
  	    code = GET_CODE (XEXP (SET_SRC (PATTERN (next)), 0));
--- 4291,4309 ----
    rtx next;
    enum rtx_code code;
  
!   if (!(cc_status.flags & CC_FCOMI))
!     {
!       xops[0] = gen_rtx_REG (HImode, 0);
!       output_asm_insn (AS1 (fnsts%W0,%0), xops);
!     }
  
    if (! TARGET_IEEE_FP)
      {
        if (!(cc_status.flags & CC_REVERSED))
          {
            next = next_cc0_user (insn);
!   
!           if (GET_CODE (PATTERN (next)) == SET
                && SET_DEST (PATTERN (next)) == pc_rtx
                && GET_CODE (SET_SRC (PATTERN (next))) == IF_THEN_ELSE)
  	    code = GET_CODE (XEXP (SET_SRC (PATTERN (next)), 0));
*************** output_fp_cc0_set (insn)
*** 4323,4330 ****
    if (next == NULL_RTX)
      abort ();
  
!   if (GET_CODE (next) == JUMP_INSN
!       && GET_CODE (PATTERN (next)) == SET
        && SET_DEST (PATTERN (next)) == pc_rtx
        && GET_CODE (SET_SRC (PATTERN (next))) == IF_THEN_ELSE)
      code = GET_CODE (XEXP (SET_SRC (PATTERN (next)), 0));
--- 4328,4334 ----
    if (next == NULL_RTX)
      abort ();
  
!   if (GET_CODE (PATTERN (next)) == SET
        && SET_DEST (PATTERN (next)) == pc_rtx
        && GET_CODE (SET_SRC (PATTERN (next))) == IF_THEN_ELSE)
      code = GET_CODE (XEXP (SET_SRC (PATTERN (next)), 0));
*************** output_fp_cc0_set (insn)
*** 4346,4407 ****
      }
    else
      abort ();
- 
-   xops[0] = gen_rtx_REG (QImode, 0);
  
!   switch (code)
      {
!     case GT:
!       xops[1] = GEN_INT (0x45);
!       output_asm_insn (AS2 (and%B0,%1,%h0), xops);
!       /* je label */
!       break;
! 
!     case LT:
!       xops[1] = GEN_INT (0x45);
!       xops[2] = GEN_INT (0x01);
!       output_asm_insn (AS2 (and%B0,%1,%h0), xops);
!       output_asm_insn (AS2 (cmp%B0,%2,%h0), xops);
!       /* je label */
!       break;
! 
!     case GE:
!       xops[1] = GEN_INT (0x05);
!       output_asm_insn (AS2 (and%B0,%1,%h0), xops);
!       /* je label */
!       break;
! 
!     case LE:
!       xops[1] = GEN_INT (0x45);
!       xops[2] = GEN_INT (0x40);
!       output_asm_insn (AS2 (and%B0,%1,%h0), xops);
!       output_asm_insn (AS1 (dec%B0,%h0), xops);
!       output_asm_insn (AS2 (cmp%B0,%2,%h0), xops);
!       /* jb label */
!       break;
  
!     case EQ:
!       xops[1] = GEN_INT (0x45);
!       xops[2] = GEN_INT (0x40);
!       output_asm_insn (AS2 (and%B0,%1,%h0), xops);
!       output_asm_insn (AS2 (cmp%B0,%2,%h0), xops);
!       /* je label */
!       break;
  
!     case NE:
!       xops[1] = GEN_INT (0x44);
!       xops[2] = GEN_INT (0x40);
!       output_asm_insn (AS2 (and%B0,%1,%h0), xops);
!       output_asm_insn (AS2 (xor%B0,%2,%h0), xops);
!       /* jne label */
!       break;
  
!     case GTU:
!     case LTU:
!     case GEU:
!     case LEU:
!     default:
!       abort ();
      }
  
    return "";
--- 4350,4453 ----
      }
    else
      abort ();
  
!   if (cc_status.flags & CC_FCOMI)
      {
!       /* It is very tricky. We have to do it right. */
  
!       xops [0] = gen_rtx_REG (QImode, 0);
  
!       switch (code)
! 	{
! 	case GT:
! 	case GE:
! 	  break;
! 
! 	case LT:
! 	  output_asm_insn (AS1 (setb,%b0), xops);
! 	  output_asm_insn (AS1 (setp,%h0), xops);
! 	  output_asm_insn (AS2 (cmp%B0,%b0,%h0), xops);
! 	  break;
! 
! 	case LE:
! 	  output_asm_insn (AS1 (setbe,%b0), xops);
! 	  output_asm_insn (AS1 (setnp,%h0), xops);
! 	  output_asm_insn (AS2 (xor%B0,%b0,%h0), xops);
! 	  break;
! 
! 	case EQ:
! 	case NE:
! 	  output_asm_insn (AS1 (setne,%b0), xops);
! 	  output_asm_insn (AS1 (setp,%h0), xops);
! 	  output_asm_insn (AS2 (or%B0,%b0,%h0), xops);
! 	  break;
! 
! 	case GTU:
! 	case LTU:
! 	case GEU:
! 	case LEU:
! 	default:
! 	  abort ();
! 	}
!     }
!   else
!     {
!       xops[0] = gen_rtx_REG (QImode, 0);
  
!       switch (code)
! 	{
! 	case GT:
! 	  xops[1] = GEN_INT (0x45);
! 	  output_asm_insn (AS2 (and%B0,%1,%h0), xops);
! 	  /* je label */
! 	  break;
! 
! 	case LT:
! 	  xops[1] = GEN_INT (0x45);
! 	  xops[2] = GEN_INT (0x01);
! 	  output_asm_insn (AS2 (and%B0,%1,%h0), xops);
! 	  output_asm_insn (AS2 (cmp%B0,%2,%h0), xops);
! 	  /* je label */
! 	  break;
! 
! 	case GE:
! 	  xops[1] = GEN_INT (0x05);
! 	  output_asm_insn (AS2 (and%B0,%1,%h0), xops);
! 	  /* je label */
! 	  break;
! 
! 	case LE:
! 	  xops[1] = GEN_INT (0x45);
! 	  xops[2] = GEN_INT (0x40);
! 	  output_asm_insn (AS2 (and%B0,%1,%h0), xops);
! 	  output_asm_insn (AS1 (dec%B0,%h0), xops);
! 	  output_asm_insn (AS2 (cmp%B0,%2,%h0), xops);
! 	  /* jb label */
! 	  break;
! 
! 	case EQ:
! 	  xops[1] = GEN_INT (0x45);
! 	  xops[2] = GEN_INT (0x40);
! 	  output_asm_insn (AS2 (and%B0,%1,%h0), xops);
! 	  output_asm_insn (AS2 (cmp%B0,%2,%h0), xops);
! 	  /* je label */
! 	  break;
! 
! 	case NE:
! 	  xops[1] = GEN_INT (0x44);
! 	  xops[2] = GEN_INT (0x40);
! 	  output_asm_insn (AS2 (and%B0,%1,%h0), xops);
! 	  output_asm_insn (AS2 (xor%B0,%2,%h0), xops);
! 	  /* jne label */
! 	  break;
! 
! 	case GTU:
! 	case LTU:
! 	case GEU:
! 	case LEU:
! 	default:
! 	  abort ();
! 	}
      }
  
    return "";

Re: egcs-1.2 stuff

[H.J. Lu]

>   > I am enclosing the failures I got with egcs in CVS at 10:15am on Apr.
>   > 3 plus my CC_FCOMI patch using -march=pentiumpro -mcpu=pentiumpro. How
>   > does it compare with your results?
> I only used "-march=pentiumpro -O1"   Please verify using the compiler
> options I specified in my message.  When you use different options you make
> your testresults worthless.

I have been using -march=pentiumpro -mcpu=pentiumpro to run "make check"
for every egcs I build. I didn't make that one for you. I am doing

# cd gcc
# make -j 8 check RUNTESTFLAGS="--tool_opts \"-march=pentiumpro\""

Is that ok or should I use

# make -j 8 check RUNTESTFLAGS="--tool_opts \"-O1 -march=pentiumpro\""

> 
> I just tried it again from the CVS tree.  Without your patch it runs fine,
> with your patch it aborts.

Can you send me the patch you used? I like to see why it fails.

> 
> And the assembly code that does not work
> 
> 	.file	"j.c"
> 	.version	"01.01"

That is the difference between yours and mine. I want to know why you
get the wrong result. I need the patch you used to see it myself.

Thanks.


--- foo.s	Sun Apr  4 08:43:26 1999
+++ x.s	Sun Apr  4 08:42:53 1999
@@ -1,4 +1,4 @@
-	.file	"j.c"
+	.file	"x.c"
 	.version	"01.01"
 gcc2_compiled.:
 .section	.rodata
@@ -36,7 +36,7 @@
 	fldl -72(%ebp)
 	fldz
 	fcomip %st(1),%st
-	jne .L8
+	jbe .L8
 	fchs
 	fstpl -72(%ebp)
 	jmp .L4

Re: egcs-1.2 stuff

[Jeffrey A Law]

  In message < m10TgYt-000ErMC@ocean.lucon.org >you write:
  > 1. I have verified that there are no regressions with egcs 1.1.2.
I don't care about regressions again egcs-1.1.2.

  > 2. The testcase works fine with egcs in CVS at 10:15am on Apr. 3
  > plus my CC_FCOMI patch.
This is very odd since I did it with a fresh tree this afternoon.


  > Could you please check my asm ouput against yours to see why yours
  > doesn't work?
I don't know the x86 architecture well enough to do that.


  > I am enclosing the failures I got with egcs in CVS at 10:15am on Apr.
  > 3 plus my CC_FCOMI patch using -march=pentiumpro -mcpu=pentiumpro. How
  > does it compare with your results?
I only used "-march=pentiumpro -O1"   Please verify using the compiler
options I specified in my message.  When you use different options you make
your testresults worthless.

I just tried it again from the CVS tree.  Without your patch it runs fine,
with your patch it aborts.

Here's the assembly code that works:

	.file	"k.c"
	.version	"01.01"
gcc2_compiled.:
.section	.rodata
	.align 8
.LC0:
	.long 0x0,0xbff00000
.text
	.align 4
.globl f
	.type	 f,@function
f:
	pushl %ebp
	movl %esp,%ebp
	subl $8,%esp
	movl 8(%ebp),%eax
	fldl .LC0
	fstpl (%eax)
	movl %ebp,%esp
	popl %ebp
	ret
.Lfe1:
	.size	 f,.Lfe1-f
	.align 4
.globl main
	.type	 main,@function
main:
	pushl %ebp
	movl %esp,%ebp
	subl $88,%esp
	addl $-12,%esp
	leal -72(%ebp),%eax
	pushl %eax
	call f
	addl $16,%esp
	fldl -72(%ebp)
	fldz
	fcomp %st(1)
	fnstsw %ax
	andb $69,%ah
	jne .L8
	fchs
	fstpl -72(%ebp)
	jmp .L4
.L8:
	fstp %st(0)
.L4:
	fldz
	fcoml -72(%ebp)
	fnstsw %ax
	andb $69,%ah
	je .L6
	fstp %st(0)
	fldl -72(%ebp)
.L6:
	fldl -72(%ebp)
	fucompp
	fnstsw %ax
	andb $69,%ah
	cmpb $64,%ah
	je .L7
	call abort
	.p2align 4,,7
.L7:
	addl $-12,%esp
	pushl $0
	call exit
.Lfe2:
	.size	 main,.Lfe2-main
	.ident	"GCC: (GNU) egcs-2.93.14 19990403 (gcc2 ss-980929 experimental)"


And the assembly code that does not work

	.file	"j.c"
	.version	"01.01"
gcc2_compiled.:
.section	.rodata
	.align 8
.LC0:
	.long 0x0,0xbff00000
.text
	.align 4
.globl f
	.type	 f,@function
f:
	pushl %ebp
	movl %esp,%ebp
	subl $8,%esp
	movl 8(%ebp),%eax
	fldl .LC0
	fstpl (%eax)
	movl %ebp,%esp
	popl %ebp
	ret
.Lfe1:
	.size	 f,.Lfe1-f
	.align 4
.globl main
	.type	 main,@function
main:
	pushl %ebp
	movl %esp,%ebp
	subl $88,%esp
	addl $-12,%esp
	leal -72(%ebp),%eax
	pushl %eax
	call f
	addl $16,%esp
	fldl -72(%ebp)
	fldz
	fcomip %st(1),%st
	jne .L8
	fchs
	fstpl -72(%ebp)
	jmp .L4
.L8:
	fstp %st(0)
.L4:
	fldz
	fcoml -72(%ebp)
	fnstsw %ax
	andb $69,%ah
	je .L6
	fstp %st(0)
	fldl -72(%ebp)
.L6:
	fldl -72(%ebp)
	fucomip %st(1),%st
	fstp %st(0)
	setne %al
	setp %ah
	orb %al,%ah
	je .L7
	call abort
	.p2align 4,,7
.L7:
	addl $-12,%esp
	pushl $0
	call exit
.Lfe2:
	.size	 main,.Lfe2-main
	.ident	"GCC: (GNU) egcs-2.93.14 19990403 (gcc2 ss-980929 experimental)"

Re: egcs-1.2 stuff

[H.J. Lu]

> 
> 
>   In message <m10O9fD-000ErMC@ocean.lucon.org>you write:
>   > > 
>   > > 
>   > > 
>   > >   In message <m10O2ic-000ErMC@ocean.lucon.org>you write:
>   > >   > I enabled all TARGET_CMOVE and CC_FCOMI. I also optimized the fp
>   > >   > cmove.
>   > >   > 
>   > >   > What do you mean by that? I sent in patches months ago and you said
>   > >   > you would take a look. What happened?
>   > > The FCOMI stuff I explicitly left with you and John to sort out.  Last I
>   > > heard there were still technical problems with that patch.  If you and Jo
>   > hn
>   > > think the patch is done, then send the final patch.
>   > > 
>   > 
>   > This is the latest patch I have been using. It seems ok.
>   > 
>   > 
>   > H.J.
>   > ----
>   > Mon Jan 11 20:02:56 1999  H.J. Lu  (hjl@gnu.org)
>   > 
>   > 	* i386.c (output_fp_cc0_set): Don't check the JUMP_INSN code for
>   > 	conditional move.
>   > 
>   > 	* config/i386/i386.c (notice_update_cc, output_float_compare):
>   > 	Enable TARGET_CMOVE support.
>   > 
>   > 	* config/i386/i386.c (output_float_compare): Fix the FLOAT
>   > 	comparison for IEEE math and CC_FCOMI.
> Here's a nice simple example from the gcc testsuite that breaks with this
> patch installed.
> 
> Compile & run on a PPro/PII with -O1 -march=pentiumpro
> 
> The program will abort instead of exiting with zero status:
> f (double *ty)
> {
>   *ty = -1.0;
> }
> 
> main ()
> {
>   double foo[6];
>   double tx = 0.0, ty, d;
> 
>   f (&ty);
> 
>   if (ty < 0)
>     ty = -ty;
>   d = (tx > ty) ? tx : ty;
>   if (ty != d)
>     abort ();
>   exit (0);
> }
> 
> 
> When you resubmit this patch, can you please test it with the gcc testsuite
> first?
> 

I am quite confused here:

1. I have verified that there are no regressions with egcs 1.1.2.
2. The testcase works fine with egcs in CVS at 10:15am on Apr. 3
plus my CC_FCOMI patch.

Could you please check my asm ouput against yours to see why yours
doesn't work?

I am enclosing the failures I got with egcs in CVS at 10:15am on Apr.
3 plus my CC_FCOMI patch using -march=pentiumpro -mcpu=pentiumpro. How
does it compare with your results?

If you use Linux/x86 or any x86 OSes for that matter, you should use
binutils 2.9.1.0.23. There are a few x86 gas bugs fixed. I know one
of them causes the problem you have seen. I haven't check the gas
snapshot yet. I assume it is ok.

BTW, one more benefit of binutils 2.9.1.0.23 on x86 is you can use
P/III instructions if you have P/III. binutils 2.9.1.0.23 is available
from

ftp://ftp.varesearch.com/pub/support/hjl/binutils

Thanks.

-- 
H.J. Lu (hjl@gnu.org)
---
	.file	"x.c"
	.version	"01.01"
gcc2_compiled.:
.section	.rodata
	.align 8
.LC0:
	.long 0x0,0xbff00000
.text
	.align 4
.globl f
	.type	 f,@function
f:
	pushl %ebp
	movl %esp,%ebp
	subl $8,%esp
	movl 8(%ebp),%eax
	fldl .LC0
	fstpl (%eax)
	movl %ebp,%esp
	popl %ebp
	ret
.Lfe1:
	.size	 f,.Lfe1-f
	.align 4
.globl main
	.type	 main,@function
main:
	pushl %ebp
	movl %esp,%ebp
	subl $88,%esp
	addl $-12,%esp
	leal -72(%ebp),%eax
	pushl %eax
	call f
	addl $16,%esp
	fldl -72(%ebp)
	fldz
	fcomip %st(1),%st
	jbe .L8
	fchs
	fstpl -72(%ebp)
	jmp .L4
.L8:
	fstp %st(0)
.L4:
	fldz
	fcoml -72(%ebp)
	fnstsw %ax
	andb $69,%ah
	je .L6
	fstp %st(0)
	fldl -72(%ebp)
.L6:
	fldl -72(%ebp)
	fucomip %st(1),%st
	fstp %st(0)
	setne %al
	setp %ah
	orb %al,%ah
	je .L7
	call abort
	.p2align 4,,7
.L7:
	addl $-12,%esp
	pushl $0
	call exit
.Lfe2:
	.size	 main,.Lfe2-main
	.ident	"GCC: (GNU) egcs-2.93.14 19990403 (gcc2 ss-980929 experimental)"
---
FAIL: g++.dg/special/conpr-1.C execution test
FAIL: objc/execute/bf-1.m compilation,  -O 
FAIL: g++.dg/special/conpr-2.C execution test
FAIL: objc/execute/bf-10.m compilation,  -O 
FAIL: g++.dg/special/conpr-3.C execution test
FAIL: g++.dg/special/conpr-3.C execution test
FAIL: objc/execute/bf-11.m compilation,  -O 
FAIL: objc/execute/bf-12.m compilation,  -O 
FAIL: objc/execute/bf-13.m compilation,  -O 
FAIL: objc/execute/bf-14.m compilation,  -O 
FAIL: objc/execute/bf-15.m compilation,  -O 
FAIL: objc/execute/bf-16.m compilation,  -O 
FAIL: objc/execute/bf-17.m compilation,  -O 
FAIL: objc/execute/bf-18.m compilation,  -O 
FAIL: objc/execute/bf-19.m compilation,  -O 
FAIL: objc/execute/bf-2.m compilation,  -O 
FAIL: objc/execute/bf-3.m compilation,  -O 
FAIL: objc/execute/bf-4.m compilation,  -O 
FAIL: objc/execute/bf-5.m compilation,  -O 
FAIL: objc/execute/bf-6.m compilation,  -O 
FAIL: objc/execute/bf-7.m compilation,  -O 
FAIL: objc/execute/bf-8.m compilation,  -O 
FAIL: objc/execute/bf-9.m compilation,  -O 
FAIL: g77.f-torture/execute/19990325-1.f execution,  -O0 
FAIL: g77.f-torture/execute/19990325-1.f execution,  -O1 
FAIL: g77.f-torture/execute/19990325-1.f execution,  -O2 
FAIL: g77.f-torture/execute/19990325-1.f execution,  -O2 -fomit-frame-pointer -finline-functions 
FAIL: g77.f-torture/execute/19990325-1.f execution,  -Os 
FAIL: g77.f-torture/execute/970625-2.f compilation,  -O1 
FAIL: gcc.c-torture/execute/990130-1.c compilation,  -O0 
FAIL: gcc.c-torture/execute/990130-1.c compilation,  -O1 
FAIL: gcc.c-torture/execute/990130-1.c compilation,  -O2 
FAIL: gcc.c-torture/execute/990130-1.c compilation,  -O3 -fomit-frame-pointer 
FAIL: gcc.c-torture/execute/990130-1.c compilation,  -O3 -g 
FAIL: gcc.c-torture/execute/990130-1.c compilation,  -Os 
FAIL: gcc.c-torture/execute/loop-2b.c execution,  -O2 
FAIL: gcc.c-torture/execute/loop-2b.c execution,  -O3 -fomit-frame-pointer 
FAIL: gcc.c-torture/execute/loop-2b.c execution,  -O3 -fomit-frame-pointer -funroll-loops 
FAIL: gcc.c-torture/execute/loop-2b.c execution,  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions 
FAIL: gcc.c-torture/execute/loop-2b.c execution,  -O3 -g 
FAIL: gcc.dg/990119-1.c execution test
FAIL: gcc.dg/special/weak-1.c execution test

Re: egcs-1.2 stuff

[Jeffrey A Law]

  In message <m10O9fD-000ErMC@ocean.lucon.org>you write:
  > > 
  > > 
  > > 
  > >   In message <m10O2ic-000ErMC@ocean.lucon.org>you write:
  > >   > I enabled all TARGET_CMOVE and CC_FCOMI. I also optimized the fp
  > >   > cmove.
  > >   > 
  > >   > What do you mean by that? I sent in patches months ago and you said
  > >   > you would take a look. What happened?
  > > The FCOMI stuff I explicitly left with you and John to sort out.  Last I
  > > heard there were still technical problems with that patch.  If you and Jo
  > hn
  > > think the patch is done, then send the final patch.
  > > 
  > 
  > This is the latest patch I have been using. It seems ok.
  > 
  > 
  > H.J.
  > ----
  > Mon Jan 11 20:02:56 1999  H.J. Lu  (hjl@gnu.org)
  > 
  > 	* i386.c (output_fp_cc0_set): Don't check the JUMP_INSN code for
  > 	conditional move.
  > 
  > 	* config/i386/i386.c (notice_update_cc, output_float_compare):
  > 	Enable TARGET_CMOVE support.
  > 
  > 	* config/i386/i386.c (output_float_compare): Fix the FLOAT
  > 	comparison for IEEE math and CC_FCOMI.
Here's a nice simple example from the gcc testsuite that breaks with this
patch installed.

Compile & run on a PPro/PII with -O1 -march=pentiumpro

The program will abort instead of exiting with zero status:
f (double *ty)
{
  *ty = -1.0;
}

main ()
{
  double foo[6];
  double tx = 0.0, ty, d;

  f (&ty);

  if (ty < 0)
    ty = -ty;
  d = (tx > ty) ? tx : ty;
  if (ty != d)
    abort ();
  exit (0);
}


When you resubmit this patch, can you please test it with the gcc testsuite
first?

Thanks,
jeff

Re: egcs-1.2 stuff

[Jeffrey A Law]

  In message < m10O2ic-000ErMC@ocean.lucon.org >you write:
  > I enabled all TARGET_CMOVE and CC_FCOMI. I also optimized the fp
  > cmove.
  > 
  > What do you mean by that? I sent in patches months ago and you said
  > you would take a look. What happened?
The FCOMI stuff I explicitly left with you and John to sort out.  Last I
heard there were still technical problems with that patch.  If you and John
think the patch is done, then send the final patch.

  > Also you wanted a patch to remove gxx_include_dir from the top level
  > configure. I sent you one and I never saw it in egcs.
I'm quite busy.  That stuff fell behind egcs-1.1.2.  It's in the queue.

jeff

Re: egcs-1.2 stuff

[H.J. Lu]

> 
> 
>   In message < m10O2Sm-000ErMC@ocean.lucon.org >you write:
>   > > 
>   > > 
>   > > I'm sure there's more.  I suspect once we've got a better list we'll have
>   >  to
>   > > chop some stuff off to be able to make any kind of sane release schedule.
>   > > 
>   > 
>   > How about PPro optimization?
> Such as?

I enabled all TARGET_CMOVE and CC_FCOMI. I also optimized the fp
cmove.

> 
> If it's not already basically done, then it probably won't get in.
> 

What do you mean by that? I sent in patches months ago and you said
you would take a look. What happened?

Also you wanted a patch to remove gxx_include_dir from the top level
configure. I sent you one and I never saw it in egcs.


-- 
H.J. Lu (hjl@gnu.org)

Re: egcs-1.2 stuff

[Jeffrey A Law]

  In message < m10O2Sm-000ErMC@ocean.lucon.org >you write:
  > > 
  > > 
  > > I'm sure there's more.  I suspect once we've got a better list we'll have
  >  to
  > > chop some stuff off to be able to make any kind of sane release schedule.
  > > 
  > 
  > How about PPro optimization?
Such as?

If it's not already basically done, then it probably won't get in.

jeff

Re: egcs-1.2 stuff

[H.J. Lu]

> 
> 
> I'm sure there's more.  I suspect once we've got a better list we'll have to
> chop some stuff off to be able to make any kind of sane release schedule.
> 

How about PPro optimization?

-- 
H.J. Lu (hjl@gnu.org)

Re: egcs-1.2 stuff

[Franz Sirl]

At 10:36 19.03.99 , Jeffrey A Law wrote:

>OK.  Now that egcs-1.1.2 is done, we need to start discussing the major
>stuff that needs to be resolved for egcs-1.2.  My quick list:
>
>        1. lcm.c tied into gcse.c -- Done internally at Cygnus, just need
>           to push the remaining bits into egcs

Just a short reminder, the recent gcse/lcm checkin's into the mainline seem 
to be the reason for the reported bootstrap fail on powerpc-linux-gnu. I 
probably won't have time to debug this myself during the next 2 weeks.

>I'm sure there's more.  I suspect once we've got a better list we'll have to
>chop some stuff off to be able to make any kind of sane release schedule.

What about DWARF EH based exception handling (currently the 1.1.2 compiler 
RPM for LinuxPPC R5 already uses a snapshot of Andrew's work with no known 
bugs so far) and RTL-based prologue/epilogue for PPC?

Thanks,
Franz.

Re: egcs-1.2 stuff

[Franz Sirl]

At 10:36 19.03.99 , Jeffrey A Law wrote:

>OK.  Now that egcs-1.1.2 is done, we need to start discussing the major
>stuff that needs to be resolved for egcs-1.2.  My quick list:
>
>        1. lcm.c tied into gcse.c -- Done internally at Cygnus, just need
>           to push the remaining bits into egcs

Just a short reminder, the recent gcse/lcm checkin's into the mainline seem 
to be the reason for the reported bootstrap fail on powerpc-linux-gnu. I 
probably won't have time to debug this myself during the next 2 weeks.

>I'm sure there's more.  I suspect once we've got a better list we'll have to
>chop some stuff off to be able to make any kind of sane release schedule.

What about DWARF EH based exception handling (currently the 1.1.2 compiler 
RPM for LinuxPPC R5 already uses a snapshot of Andrew's work with no known 
bugs so far) and RTL-based prologue/epilogue for PPC?

Thanks,
Franz.

Re: egcs-1.2 stuff

[Donn Terry]

Jeffrey A Law wrote:
> 
> OK.  Now that egcs-1.1.2 is done, we need to start discussing the major
> stuff that needs to be resolved for egcs-1.2.  My quick list:

...

> I've still got ~50 patches in my queue to review.  Much of it backlog from
> concentrating on egcs-1.1.2 and Cygnus deliverables.

So what is the status of things sitting in your queue of patches?
(Obviously, I'm interested in the status of Mumit's Interix patches
at the moment.)

In the case of the Interix patches, there are several layers
involved (done that way to make them bite-sized), and having
Mumit's start on that occur late will cause problems with
timing.

Donn
-- 

===================================================
Donn Terry                  mailto:donn@interix.com
Softway Systems, Inc.        http://www.interix.com
2850 McClelland Dr, Ste. 1800   Ft.Collins CO 80525
Tel: +1-970-204-9900           Fax: +1-970-204-9951
===================================================

Re: egcs-1.2 stuff

[Jeffrey A Law]

  In message < 36F2C319.949610F6@interix.com >you write:
  > So what is the status of things sitting in your queue of patches?
  > (Obviously, I'm interested in the status of Mumit's Interix patches
  > at the moment.)
I'm working to resolve them as quickly as I can.

I've stated more than once that if you're unhappy with the rate at which
your patches are addressed that you can/should work with one of the other
maintainers to get them resolved.

That's the whole point behind having multiple maintainers.

Interix isn't that high of a priority relative to many of the other
patches in my queue.  Sorry.  It's simply a matter of priorities.

jeff

Re: egcs-1.2 stuff

[Jeffrey A Law]

  In message < 36F2C319.949610F6@interix.com >you write:
  > So what is the status of things sitting in your queue of patches?
  > (Obviously, I'm interested in the status of Mumit's Interix patches
  > at the moment.)
I'm working to resolve them as quickly as I can.

I've stated more than once that if you're unhappy with the rate at which
your patches are addressed that you can/should work with one of the other
maintainers to get them resolved.

That's the whole point behind having multiple maintainers.

Interix isn't that high of a priority relative to many of the other
patches in my queue.  Sorry.  It's simply a matter of priorities.

jeff

Re: egcs-1.2 stuff

[Donn Terry]

Jeffrey A Law wrote:
> 
> OK.  Now that egcs-1.1.2 is done, we need to start discussing the major
> stuff that needs to be resolved for egcs-1.2.  My quick list:

...

> I've still got ~50 patches in my queue to review.  Much of it backlog from
> concentrating on egcs-1.1.2 and Cygnus deliverables.

So what is the status of things sitting in your queue of patches?
(Obviously, I'm interested in the status of Mumit's Interix patches
at the moment.)

In the case of the Interix patches, there are several layers
involved (done that way to make them bite-sized), and having
Mumit's start on that occur late will cause problems with
timing.

Donn
-- 

===================================================
Donn Terry                  mailto:donn@interix.com
Softway Systems, Inc.        http://www.interix.com
2850 McClelland Dr, Ste. 1800   Ft.Collins CO 80525
Tel: +1-970-204-9900           Fax: +1-970-204-9951
===================================================

Re: egcs-1.2 stuff

[Toon Moene]

Jeffrey A Law wrote:

> OK.  Now that egcs-1.1.2 is done, we need to start discussing the major
> stuff that needs to be resolved for egcs-1.2.  My quick list:

[ .... good points elided .... ]

> I'm sure there's more.  I suspect once we've got a better list we'll have to
> chop some stuff off to be able to make any kind of sane release schedule.

Things that I would like to see (Fortran Frontend):

1. Because we're not going to solve the SCmode problems on 64-bit
   targets in time for 1.2, it would be useful to restrict the 
   "-femulate-complex" default option that the FF applies to only those 
   cases where it is actually needed (single precision complex on 64-bit 
   targets).

2. It might be best to enable -fno-strict-aliasing by default from
   the Fortran Frontend, because Fortran knows of no type based
   aliasing rules.

My Dfl 0.02.

-- 
Toon Moene (toon@moene.indiv.nluug.nl)
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Phone: +31 346 214290; Fax: +31 346 214286
g77 Support: fortran@gnu.org; egcs: egcs-bugs@cygnus.com

Re: egcs-1.2 stuff

[craig]

>1. Because we're not going to solve the SCmode problems on 64-bit
>   targets in time for 1.2, it would be useful to restrict the 
>   "-femulate-complex" default option that the FF applies to only those 
>   cases where it is actually needed (single precision complex on 64-bit 
>   targets).

Hmm, might not be trivial in the code, and certainly would be more
painful to document than the current, fairly simple-minded option.
(Plus, we'd really need a new option to represent this intermediate
sort of emulation.)  Otherwise, that seems like a good idea.

>2. It might be best to enable -fno-strict-aliasing by default from
>   the Fortran Frontend, because Fortran knows of no type based
>   aliasing rules.

I still haven't examined the -fstrict-aliasing stuff at all yet,
though it's in my backlog somewhere (under "performance", I think).

        tq vm, (burley)

Re: egcs-1.2 stuff

[Toon Moene]

Craig,

> >1. Because we're not going to solve the SCmode problems on 64-bit
> >   targets in time for 1.2, it would be useful to restrict the
> >   "-femulate-complex" default option that the FF applies to only those
> >   cases where it is actually needed (single precision complex on 64-bit
> >   targets).
> 
> Hmm, might not be trivial in the code, and certainly would be more
> painful to document than the current, fairly simple-minded option.
> (Plus, we'd really need a new option to represent this intermediate
> sort of emulation.)  Otherwise, that seems like a good idea.

Yep.  It might be that just better documenting it (what problem it works
around on and when -fno-emulate-complex can safely be used) is the most
effective solution for the time being.

For the moment I can only test it on the i386 port, where it certainly
passes the complete LAPACK tests.

Cheers,

-- 
Toon Moene (toon@moene.indiv.nluug.nl)
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Phone: +31 346 214290; Fax: +31 346 214286
g77 Support: fortran@gnu.org; egcs: egcs-bugs@cygnus.com

Re: egcs-1.2 stuff

[Toon Moene]

Craig,

> >1. Because we're not going to solve the SCmode problems on 64-bit
> >   targets in time for 1.2, it would be useful to restrict the
> >   "-femulate-complex" default option that the FF applies to only those
> >   cases where it is actually needed (single precision complex on 64-bit
> >   targets).
> 
> Hmm, might not be trivial in the code, and certainly would be more
> painful to document than the current, fairly simple-minded option.
> (Plus, we'd really need a new option to represent this intermediate
> sort of emulation.)  Otherwise, that seems like a good idea.

Yep.  It might be that just better documenting it (what problem it works
around on and when -fno-emulate-complex can safely be used) is the most
effective solution for the time being.

For the moment I can only test it on the i386 port, where it certainly
passes the complete LAPACK tests.

Cheers,

-- 
Toon Moene (toon@moene.indiv.nluug.nl)
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Phone: +31 346 214290; Fax: +31 346 214286
g77 Support: fortran@gnu.org; egcs: egcs-bugs@cygnus.com

Re: egcs-1.2 stuff

[craig]

>1. Because we're not going to solve the SCmode problems on 64-bit
>   targets in time for 1.2, it would be useful to restrict the 
>   "-femulate-complex" default option that the FF applies to only those 
>   cases where it is actually needed (single precision complex on 64-bit 
>   targets).

Hmm, might not be trivial in the code, and certainly would be more
painful to document than the current, fairly simple-minded option.
(Plus, we'd really need a new option to represent this intermediate
sort of emulation.)  Otherwise, that seems like a good idea.

>2. It might be best to enable -fno-strict-aliasing by default from
>   the Fortran Frontend, because Fortran knows of no type based
>   aliasing rules.

I still haven't examined the -fstrict-aliasing stuff at all yet,
though it's in my backlog somewhere (under "performance", I think).

        tq vm, (burley)

Re: egcs-1.2 stuff

[Richard Henderson]

On Wed, Mar 24, 1999 at 10:53:46PM +0100, Toon Moene wrote:
> 2. It might be best to enable -fno-strict-aliasing by default from
>    the Fortran Frontend, because Fortran knows of no type based
>    aliasing rules.

No.  What'll happen is that the Fortran front end simply won't
set any alias sets, and so normally the strict alias code just
won't fire.

However, it is well within the relm of possibility that we can
use alias sets for spill slots and whatnot, independant of the
source language.  So it wouldn't be especially good to just 
turn off -fstrict-aliasing arbitrarily.


r~

Re: egcs-1.2 stuff

[Toon Moene]

Richard Henderson wrote:
> 
> On Wed, Mar 24, 1999 at 10:53:46PM +0100, Toon Moene wrote:
> > 2. It might be best to enable -fno-strict-aliasing by default from
> >    the Fortran Frontend, because Fortran knows of no type based
> >    aliasing rules.
> 
> No.  What'll happen is that the Fortran front end simply won't
> set any alias sets, and so normally the strict alias code just
> won't fire.

Could be - I was just parrotting what Mark Mitchell wrote me about it
...  I haven't really studied what the new alias set business does.

> However, it is well within the relm of possibility that we can
> use alias sets for spill slots and whatnot, independant of the
> source language.  So it wouldn't be especially good to just
> turn off -fstrict-aliasing arbitrarily.

Oh, I should have written that it is a temporary measure.  For my
programs, and hence probably for a lot of other Fortran code that has
stack based arrays, it led to larger working sets and slower execution. 
I think that's not desirable for a solution that won't solve a real
problem with that code.

Cheers,

-- 
Toon Moene (toon@moene.indiv.nluug.nl)
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Phone: +31 346 214290; Fax: +31 346 214286
g77 Support: fortran@gnu.org; egcs: egcs-bugs@cygnus.com

Re: egcs-1.2 stuff

[Toon Moene]

Richard Henderson wrote:
> 
> On Wed, Mar 24, 1999 at 10:53:46PM +0100, Toon Moene wrote:
> > 2. It might be best to enable -fno-strict-aliasing by default from
> >    the Fortran Frontend, because Fortran knows of no type based
> >    aliasing rules.
> 
> No.  What'll happen is that the Fortran front end simply won't
> set any alias sets, and so normally the strict alias code just
> won't fire.

Could be - I was just parrotting what Mark Mitchell wrote me about it
...  I haven't really studied what the new alias set business does.

> However, it is well within the relm of possibility that we can
> use alias sets for spill slots and whatnot, independant of the
> source language.  So it wouldn't be especially good to just
> turn off -fstrict-aliasing arbitrarily.

Oh, I should have written that it is a temporary measure.  For my
programs, and hence probably for a lot of other Fortran code that has
stack based arrays, it led to larger working sets and slower execution. 
I think that's not desirable for a solution that won't solve a real
problem with that code.

Cheers,

-- 
Toon Moene (toon@moene.indiv.nluug.nl)
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Phone: +31 346 214290; Fax: +31 346 214286
g77 Support: fortran@gnu.org; egcs: egcs-bugs@cygnus.com

Re: egcs-1.2 stuff

[Richard Henderson]

On Wed, Mar 24, 1999 at 10:53:46PM +0100, Toon Moene wrote:
> 2. It might be best to enable -fno-strict-aliasing by default from
>    the Fortran Frontend, because Fortran knows of no type based
>    aliasing rules.

No.  What'll happen is that the Fortran front end simply won't
set any alias sets, and so normally the strict alias code just
won't fire.

However, it is well within the relm of possibility that we can
use alias sets for spill slots and whatnot, independant of the
source language.  So it wouldn't be especially good to just 
turn off -fstrict-aliasing arbitrarily.


r~

Re: egcs-1.2 stuff

[Toon Moene]

Jeffrey A Law wrote:

> OK.  Now that egcs-1.1.2 is done, we need to start discussing the major
> stuff that needs to be resolved for egcs-1.2.  My quick list:

[ .... good points elided .... ]

> I'm sure there's more.  I suspect once we've got a better list we'll have to
> chop some stuff off to be able to make any kind of sane release schedule.

Things that I would like to see (Fortran Frontend):

1. Because we're not going to solve the SCmode problems on 64-bit
   targets in time for 1.2, it would be useful to restrict the 
   "-femulate-complex" default option that the FF applies to only those 
   cases where it is actually needed (single precision complex on 64-bit 
   targets).

2. It might be best to enable -fno-strict-aliasing by default from
   the Fortran Frontend, because Fortran knows of no type based
   aliasing rules.

My Dfl 0.02.

-- 
Toon Moene (toon@moene.indiv.nluug.nl)
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Phone: +31 346 214290; Fax: +31 346 214286
g77 Support: fortran@gnu.org; egcs: egcs-bugs@cygnus.com

egcs-1.2 stuff

[Jeffrey A Law]

OK.  Now that egcs-1.1.2 is done, we need to start discussing the major
stuff that needs to be resolved for egcs-1.2.  My quick list:

	1. lcm.c tied into gcse.c -- Done internally at Cygnus, just need
	   to push the remaining bits into egcs

	2. fast-fixincludes -- basically needs testing and resolution of
	   any problems

	3. aligned stack slots for x86 -- patch submitted, needs final
	   review & install.

	4. EH vs unrolling problem -- patch submitted, needs final review
	   and install.

	5. unrolling & splittable GIVs problems -- needs to be analyzed and
	   fixed.

	6. Beat on the i18n support and make sure it's at least basically
	   working.

	7. Various bugs effecting glibc, the linux kernel, mips large frames,
	   etc etc.  Basically some major bug hunting sessions.
		
	8. Do we actually have the gcc include path stuff resolved?  Do we
	   want to suck in the code to allow the installed toolchain to move
	   around without the need for -B and/or GCC_EXEC_PREFIX?

	9. masked bitfield comparison issues reported by Charles Hannum

       10. Revamped cpp wrapper -- patch submitted.  Needs review
 
       11. Revamped install documentation (kill the various subdir install
	   stuff for a single install document for egcs).  Basically step 1
	   of the long term doc reorganization.

       12. New target issues (uwin, interix, hpux11, arm-vxworks, openbsd)

       13. --program-prefix fixes?

       14. SMP build fixes (particularly for chill & java)

       15. Testsuite legal issues need to be resolved.


I'm sure there's more.  I suspect once we've got a better list we'll have to
chop some stuff off to be able to make any kind of sane release schedule.

I've still got ~50 patches in my queue to review.  Much of it backlog from
concentrating on egcs-1.1.2 and Cygnus deliverables.

I'd like to get at least one additional person more closely involved in the
release process.  Someone to handle regression test coordination would be
good, as would someone to coordinate testing of major free software packages
would be a major win.



jeff