Re: egcs-1.2 stuff

Re: egcs-1.2 stuff

[Kaveh R. Ghazi]

 > From: Jeffrey A Law <law@hurl.cygnus.com> 
 > 
 > 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:
 > 
 >         7. Various bugs effecting glibc, the linux kernel, mips large frames,
 >            etc etc.  Basically some major bug hunting sessions.


	I think we should address the -fpic/-fPIC failures on the sparc. 
This would affect glibc or really any shared library.  IIRC, Dave had a
preliminary fix early last fall around the time we split the 1.1.x
branch.  For some reason it never went in.  (?)

 > Mon Sep  7 22:04:51 1998  David S. Miller  <davem@pierdol.cobaltmicro.com>
 > 
 >         * config/sparc/sparc.c (legitimize_pic_address): If during or
 >         after reload, and no PIC references existed before reload, emit
 >         get_pc sequence to setup pic base register for all such
 >         references.

	Of course maybe this is completely unrelated to the failures I'm
seeing today. :-)  For an example of the recent -fpic/-fPIC failures
(and beyond above what normally occurs) see:

http://egcs.cygnus.com/ml/egcs-testresults/1999-03/msg00353.html


		--Kaveh
--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Qwest Internet Solutions

Re: egcs-1.2 stuff

[David Miller]

   Date: Sun, 28 Mar 1999 09:12:45 -0500 (EST)
   From: "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu>

	   I think we should address the -fpic/-fPIC failures on the sparc. 
   This would affect glibc or really any shared library.  IIRC, Dave had a
   preliminary fix early last fall around the time we split the 1.1.x
   branch.  For some reason it never went in.  (?)

  ...

	   Of course maybe this is completely unrelated to the failures I'm
   seeing today. :-)  For an example of the recent -fpic/-fPIC failures
   (and beyond above what normally occurs) see:

I think they are probably related, and in any event the bug I fixed
in that change should still exist in the mainline cvs sources.

At the time I came up with that fix, Jeff and I had decided that the
correct fix was to check for and emit the get_pc sequences in a
completely different place so that all possible cases were handled
(this meant doing the checks after reload)

The bug would trigger in cases where there were no PIC references in a
function, but usage of a float constant in float regs would trigger a
PIC reference to the data section during reload.  At this point the
sparc backend would be stymied because it checked before reload
whether the "get_pc" sequence needed to be emitted.  So it never was,
and the PIC register contained garbage and obviously caused the
resulting code to crash.

Later,
David S. Miller
davem@redhat.com

Re: egcs-1.2 stuff

[David Miller]

   Date: Sun, 28 Mar 1999 09:12:45 -0500 (EST)
   From: "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu>

	   I think we should address the -fpic/-fPIC failures on the sparc. 
   This would affect glibc or really any shared library.  IIRC, Dave had a
   preliminary fix early last fall around the time we split the 1.1.x
   branch.  For some reason it never went in.  (?)

  ...

	   Of course maybe this is completely unrelated to the failures I'm
   seeing today. :-)  For an example of the recent -fpic/-fPIC failures
   (and beyond above what normally occurs) see:

I think they are probably related, and in any event the bug I fixed
in that change should still exist in the mainline cvs sources.

At the time I came up with that fix, Jeff and I had decided that the
correct fix was to check for and emit the get_pc sequences in a
completely different place so that all possible cases were handled
(this meant doing the checks after reload)

The bug would trigger in cases where there were no PIC references in a
function, but usage of a float constant in float regs would trigger a
PIC reference to the data section during reload.  At this point the
sparc backend would be stymied because it checked before reload
whether the "get_pc" sequence needed to be emitted.  So it never was,
and the PIC register contained garbage and obviously caused the
resulting code to crash.

Later,
David S. Miller
davem@redhat.com

Re: egcs-1.2 stuff

[Jeffrey A Law]

  In message < 199903281412.JAA02308@caip.rutgers.edu >you write:
  > 	I think we should address the -fpic/-fPIC failures on the sparc. 
  > This would affect glibc or really any shared library.  IIRC, Dave had a
  > preliminary fix early last fall around the time we split the 1.1.x
  > branch.  For some reason it never went in.  (?)
If it's the problem I think it is then it's unlikely we'll have a general
solution in time for egcs-1.2. 

Lazy allocation of the PIC register is a bad bad idea right now.  It's going
to consistently lose.  If we want this to work 100% reliably for egcs-1.2, then
the backend is going to need to pre-allocate the register early and take the
performance hit.  This effects multiple ports that have tried to do lazy
allocation of the PIC register (for example the ppc).

Then someone will need to block out some significant time post egcs-1.2 to fix
the problem correctly.  It's not a simple problem to fix.

jeff

Re: egcs-1.2 stuff

[David Miller]

   Date: Sun, 28 Mar 1999 13:58:05 -0700
   From: Jeffrey A Law <law@upchuck.cygnus.com>

   If it's the problem I think it is then it's unlikely we'll have a
   general solution in time for egcs-1.2.

And if so, the solution is just to mark %l7 as fixed on Sparc when PIC
is enabled just like was done in egcs-1.1.x But this won't solve the
other issue I mention with float constants.

Later,
David S. Miller
davem@redhat.com

Re: egcs-1.2 stuff

[David Miller]

   Date: Sun, 28 Mar 1999 13:58:05 -0700
   From: Jeffrey A Law <law@upchuck.cygnus.com>

   If it's the problem I think it is then it's unlikely we'll have a
   general solution in time for egcs-1.2.

And if so, the solution is just to mark %l7 as fixed on Sparc when PIC
is enabled just like was done in egcs-1.1.x But this won't solve the
other issue I mention with float constants.

Later,
David S. Miller
davem@redhat.com

Re: egcs-1.2 stuff

[Jeffrey A Law]

  In message < 199903281412.JAA02308@caip.rutgers.edu >you write:
  > 	I think we should address the -fpic/-fPIC failures on the sparc. 
  > This would affect glibc or really any shared library.  IIRC, Dave had a
  > preliminary fix early last fall around the time we split the 1.1.x
  > branch.  For some reason it never went in.  (?)
If it's the problem I think it is then it's unlikely we'll have a general
solution in time for egcs-1.2. 

Lazy allocation of the PIC register is a bad bad idea right now.  It's going
to consistently lose.  If we want this to work 100% reliably for egcs-1.2, then
the backend is going to need to pre-allocate the register early and take the
performance hit.  This effects multiple ports that have tried to do lazy
allocation of the PIC register (for example the ppc).

Then someone will need to block out some significant time post egcs-1.2 to fix
the problem correctly.  It's not a simple problem to fix.

jeff

PIC register allocation by reload (Was: Re: egcs-1.2 stuff)

[Joern Rennecke]

> 
>   In message <199903281412.JAA02308@caip.rutgers.edu>you write:
>   > 	I think we should address the -fpic/-fPIC failures on the sparc. 
>   > This would affect glibc or really any shared library.  IIRC, Dave had a
>   > preliminary fix early last fall around the time we split the 1.1.x
>   > branch.  For some reason it never went in.  (?)
> If it's the problem I think it is then it's unlikely we'll have a general
> solution in time for egcs-1.2. 
> 
> Lazy allocation of the PIC register is a bad bad idea right now.  It's going
> to consistently lose.  If we want this to work 100% reliably for egcs-1.2, then
> the backend is going to need to pre-allocate the register early and take the
> performance hit.  This effects multiple ports that have tried to do lazy
> allocation of the PIC register (for example the ppc).
> 
> Then someone will need to block out some significant time post egcs-1.2 to fix
> the problem correctly.  It's not a simple problem to fix.

I think that, if no PIC register is preallocated and we find during
reload that we need one after all, we should just load it with a secondary
reload (by defining SECONDARY_RELOAD_INPUT_CLASS and reload_in[sd]i
appropriately).
We should check that reload inheritance works for the temporarily
allocated PIC register.  Then we should get actually better code than if
we allocated the PIC register for the entire function.

PIC register allocation by reload (Was: Re: egcs-1.2 stuff)

[Joern Rennecke]

> 
>   In message <199903281412.JAA02308@caip.rutgers.edu>you write:
>   > 	I think we should address the -fpic/-fPIC failures on the sparc. 
>   > This would affect glibc or really any shared library.  IIRC, Dave had a
>   > preliminary fix early last fall around the time we split the 1.1.x
>   > branch.  For some reason it never went in.  (?)
> If it's the problem I think it is then it's unlikely we'll have a general
> solution in time for egcs-1.2. 
> 
> Lazy allocation of the PIC register is a bad bad idea right now.  It's going
> to consistently lose.  If we want this to work 100% reliably for egcs-1.2, then
> the backend is going to need to pre-allocate the register early and take the
> performance hit.  This effects multiple ports that have tried to do lazy
> allocation of the PIC register (for example the ppc).
> 
> Then someone will need to block out some significant time post egcs-1.2 to fix
> the problem correctly.  It's not a simple problem to fix.

I think that, if no PIC register is preallocated and we find during
reload that we need one after all, we should just load it with a secondary
reload (by defining SECONDARY_RELOAD_INPUT_CLASS and reload_in[sd]i
appropriately).
We should check that reload inheritance works for the temporarily
allocated PIC register.  Then we should get actually better code than if
we allocated the PIC register for the entire function.

Re: PIC register allocation by reload (Was: Re: egcs-1.2 stuff)

[Franz Sirl]

At 19:46 30.04.99 , Joern Rennecke wrote:
> >
> >   In message <199903281412.JAA02308@caip.rutgers.edu>you write:
> >   >   I think we should address the -fpic/-fPIC failures on the sparc.
> >   > This would affect glibc or really any shared library.  IIRC, Dave had a
> >   > preliminary fix early last fall around the time we split the 1.1.x
> >   > branch.  For some reason it never went in.  (?)
> > If it's the problem I think it is then it's unlikely we'll have a general
> > solution in time for egcs-1.2.
> >
> > Lazy allocation of the PIC register is a bad bad idea right now.  It's 
> going
> > to consistently lose.  If we want this to work 100% reliably for 
> egcs-1.2, then
> > the backend is going to need to pre-allocate the register early and 
> take the
> > performance hit.  This effects multiple ports that have tried to do lazy
> > allocation of the PIC register (for example the ppc).
> >
> > Then someone will need to block out some significant time post egcs-1.2 
> to fix
> > the problem correctly.  It's not a simple problem to fix.
>
>I think that, if no PIC register is preallocated and we find during
>reload that we need one after all, we should just load it with a secondary
>reload (by defining SECONDARY_RELOAD_INPUT_CLASS and reload_in[sd]i
>appropriately).
>We should check that reload inheritance works for the temporarily
>allocated PIC register.  Then we should get actually better code than if
>we allocated the PIC register for the entire function.

Hmm, would this solution possibly be OK for 1.2? It really would be great 
if this was solved once and forever, so if you have some code to try I'm 
willing to test it on PPC.

Franz.

Re: PIC register allocation by reload (Was: Re: egcs-1.2 stuff)

[Geoff Keating]

> Date: Thu, 06 May 1999 22:36:17 +0200
> From: Franz Sirl <Franz.Sirl-kernel@lauterbach.com>
> Cc: law@cygnus.com, ghazi@snafu.Rutgers.EDU, davem@cobaltmicro.com,
>         egcs@egcs.cygnus.com, geoffk@ozemail.com.au
> 
> At 19:46 30.04.99 , Joern Rennecke wrote:
> > >
> > >   In message <199903281412.JAA02308@caip.rutgers.edu>you write:
> > >   >   I think we should address the -fpic/-fPIC failures on the sparc.
> > >   > This would affect glibc or really any shared library.  IIRC, Dave had a
> > >   > preliminary fix early last fall around the time we split the 1.1.x
> > >   > branch.  For some reason it never went in.  (?)
> > > If it's the problem I think it is then it's unlikely we'll have a general
> > > solution in time for egcs-1.2.
> > >
> > > Lazy allocation of the PIC register is a bad bad idea right now.  It's 
> > going
> > > to consistently lose.  If we want this to work 100% reliably for 
> > egcs-1.2, then
> > > the backend is going to need to pre-allocate the register early and 
> > take the
> > > performance hit.  This effects multiple ports that have tried to do lazy
> > > allocation of the PIC register (for example the ppc).

Yes.

> > > Then someone will need to block out some significant time post egcs-1.2 
> > to fix
> > > the problem correctly.  It's not a simple problem to fix.

Yes.

> >I think that, if no PIC register is preallocated and we find during
> >reload that we need one after all, we should just load it with a secondary
> >reload (by defining SECONDARY_RELOAD_INPUT_CLASS and reload_in[sd]i
> >appropriately).
> >We should check that reload inheritance works for the temporarily
> >allocated PIC register.  Then we should get actually better code than if
> >we allocated the PIC register for the entire function.

Regrettably, it's more complex than that.

It's not just the case of suddenly discovering that a routine, which
previously didn't have a PIC register, needs one.  It's also the
case when a routine which already has a PIC register finds that it
needs to access it in more and/or different places than before.

The example I have of this is attached below.  Look at register 26; it
is the PIC register, yet it gets stomped just after label '.L5'; and
there's a flow of control from there to just after label '.L13' where
the PIC register is used.  Compile under 1.1.1, targetting
powerpc-linux with '-O -fpic'.  The problem here is triggered by
reload deciding to do some constant rearrangement because of a
REG_EQUIV note: it sees this

(insn 264 261 266 (set (reg:SI 117)
        (unspec[ 
                (symbol_ref:SI ("@h_malloc"))
                (reg:SI 128)
            ]  8)) 398 {*movsi_got_internal} (nil)
    (expr_list:REG_EQUIV (symbol_ref:SI ("@h_malloc"))
        (nil)))

and decides that it can then simplify this insn:

(insn 160 158 162 (set (reg:SI 120)
        (mem:SI (reg:SI 117))) 402 {movsi+1} (nil)
    (nil))

by rewriting it as

(insn 160 158 162 (set (reg:SI 120)
        (symbol_ref:SI ("@h_malloc"))) (nil) 
    (nil))

because register 117 is equivalent to the symbol_ref;
but it actually ends up as

(insn 160 158 162 (set (reg:SI 120)
        (unspec[ 
                (symbol_ref:SI ("@h_malloc"))
                (reg:SI 128)
            ]  8)) 398 {*movsi_got_internal} (nil)
     (nil))

and suddenly there's a new use of register 128 that wasn't there
before, and this causes global alloc to fail.

Similar problems happen with floating-point constants.

Is this testcase already in the test suite?  It's stripped-down code
from kaffe's implementation of GNU zip.

If you want a temporary fix, I've previously posted a solution which
ensures that reload will never ask for a new occurrence of the PIC
register.  It should be in the egcs-patches archive.  If you use this,
then there is no need to do anything else.  It would need to be ported
to sparc if it is needed there (the port consists of defining two
preprocessor variables in sparc.h).  The patch operates by forcing reload
to never spill constants to memory (only when -fpic, of course).  It
works OK on powerpc, but on sparc it might need some more code in the
machine description to make life easier for the crippled reload---I
would be glad to help here.

On powerpc, I'm not sure that you can use reload in the way suggested.
I suspect there are cases in which it won't be able to reload the link
register, for instance when folding switch statements.

> Hmm, would this solution possibly be OK for 1.2? It really would be great 
> if this was solved once and forever, so if you have some code to try I'm 
> willing to test it on PPC.

Certainly, if there's code already written I'm happy to run it against
my test suite.

-- 
Geoffrey Keating <geoffk@ozemail.com.au>

===File ~/gcc-bugs/test11.s=================================
	.file	"test11.c"
gcc2_compiled.:
	.globl memset
	.section	".text"
	.align 2
	.type	 doit,@function
doit:
	stwu 1,-176(1)
	mflr 0
	stw 14,104(1)
	stw 15,108(1)
	stw 16,112(1)
	stw 17,116(1)
	stw 18,120(1)
	stw 19,124(1)
	stw 20,128(1)
	stw 21,132(1)
	stw 22,136(1)
	stw 23,140(1)
	stw 24,144(1)
	stw 25,148(1)
	stw 26,152(1)
	stw 27,156(1)
	stw 28,160(1)
	stw 29,164(1)
	stw 30,168(1)
	stw 31,172(1)
	stw 0,180(1)
	bl _GLOBAL_OFFSET_TABLE_@local-4
	mflr 26
	mr 18,3
	mr 16,4
	mr 17,5
	mr 22,6
	addi 3,1,72
	li 4,0
	li 5,16
	crxor 6,6,6
	bl memset@plt
	addi 3,1,8
	li 4,0
	li 5,60
	crxor 6,6,6
	bl memset@plt
	li 31,0
	li 3,0
	li 27,0
	addi 25,1,12
	li 30,1
	addi 19,1,72
	li 14,1
	li 15,0
	addi 20,1,88
.L5:
	li 26,0
	slwi 21,30,2
.L9:
	cmplw 0,30,31
	bc 4,1,.L11
	addi 23,26,1
	addi 0,30,-1
	slwi 24,0,2
.L12:
	slwi 0,27,2
	lwzx 31,25,0
	addi 27,27,1
	mr 9,31
	cmplw 0,31,23
	bc 4,1,.L13
	add 11,19,21
	cmplwi 0,31,1
	bc 12,1,.L13
.L18:
	slwi 0,9,2
	lwzx 0,11,0
	cmplw 0,31,0
	bc 12,1,.L13
	addi 9,9,1
	cmplwi 0,9,1
	bc 4,1,.L18
.L13:
	slwi 0,27,2
	stwx 9,25,0
	lwz 10,h_malloc@got(26)
	lwz 0,0(10)
	slw 3,14,18
	mtlr 0
	blrl
	stw 3,0(22)
	addi 22,3,4
	stw 15,4(3)
	stwx 3,24,20
	cmplw 0,30,31
	bc 12,1,.L12
.L11:
	mr 28,16
	mr 29,17
	stw 28,0(3)
	stw 29,4(3)
	addi 26,26,1
	cmplwi 0,26,6
	bc 4,1,.L9
	addi 30,30,1
	cmplwi 0,30,2
	bc 4,1,.L5
	lwz 0,180(1)
	mtlr 0
	lwz 14,104(1)
	lwz 15,108(1)
	lwz 16,112(1)
	lwz 17,116(1)
	lwz 18,120(1)
	lwz 19,124(1)
	lwz 20,128(1)
	lwz 21,132(1)
	lwz 22,136(1)
	lwz 23,140(1)
	lwz 24,144(1)
	lwz 25,148(1)
	lwz 26,152(1)
	lwz 27,156(1)
	lwz 28,160(1)
	lwz 29,164(1)
	lwz 30,168(1)
	lwz 31,172(1)
	la 1,176(1)
	blr
.Lfe1:
	.size	 doit,.Lfe1-doit
	.align 2
	.globl is_ok
	.type	 is_ok,@function
is_ok:
	stwu 1,-16(1)
	mflr 0
	stw 0,20(1)
	li 3,0
	crxor 6,6,6
	bl exit@plt
.Lfe2:
	.size	 is_ok,.Lfe2-is_ok
	.align 2
	.globl main
	.type	 main,@function
main:
	stwu 1,-16(1)
	mflr 0
	stw 0,20(1)
	bl _GLOBAL_OFFSET_TABLE_@local-4
	mflr 9
	lwz 11,h_malloc@got(9)
	lwz 9,is_ok@got(9)
	stw 9,0(11)
	li 3,0
	li 4,0
	li 5,0
	li 6,0
	bl doit@local
	bl abort@plt
.Lfe3:
	.size	 main,.Lfe3-main
	.comm	h_malloc,4,4
	.ident	"GCC: (GNU) egcs-2.91.54 19980816 (gcc2 ss-980609 experimental)"
============================================================

===File ~/gcc-bugs/test11.c=================================
typedef struct _huft {
  unsigned 	e;
  struct _huft* t;
} huft;

huft*   (*h_malloc)(unsigned);

static void
doit( unsigned p2, unsigned p3, huft *p4, huft** t)
{
  unsigned a, h, j, k, w;
  unsigned *xp, *l;
  unsigned lx[2*7+1], v[2*2];
  huft *q;
  huft r;
  huft *u[2];

  memset(v, 0, sizeof(v));
  memset(lx, 0, sizeof(lx));

  w = 0;
  q = 0;
  h = 0;
  l = lx+1;
  
  for (k=1; k <= 2; k++)
    for (a=0; a < 7; a++)
    {
      while (k > w)
      {
        w = l[h++];   

	j = w;
        if (w > a + 1)
        {
          xp = v + k;
          while (j < 2 && w <= xp[j])
	    ++j;
        }
        l[h] = j;        

        q = h_malloc(1<<p2);
        *t = q;
        t = &(q->t);
	*t = 0;
	u[k-1] = q;
      }

      r.e = p3;
      r.t = p4;
      q[0] = r;
    }
}

huft *is_ok(unsigned x) 
{
  exit(0);
}

int main() { h_malloc = is_ok; doit(0, 0, 0, 0); abort(); }

 
============================================================

Re: PIC register allocation by reload (Was: Re: egcs-1.2 stuff)

[Franz Sirl]

At 23:15 06.05.99 , Geoff Keating wrote:
>Is this testcase already in the test suite?  It's stripped-down code
>from kaffe's implementation of GNU zip.

Geoff,

this testcase is not in the testsuite, but it also no longer FAILs with the 
current cvs-egcs, reload got a _lot_ smarter since egcs-1.1. But there's 
one testcase in the testsuite which still shows this problem with -fpic on 
PPC, attached below.

Franz.

PS. Geoff, if you want to play with the egcs-mainline a bit, login into the 
LinuxPPC developers machine, you'll find everything under ~fsirl/egcsm 
(source) and ~fsirl/obj/cvsm (build from today), you should have full 
access there.

gcc/testsuite/gcc.dg/980523-1.c:
/* { dg-do run { target rs6000-*-linux* powerpc-*-linux*} } */
/* { dg-options "-O2 -fpic" } */


void foo1(int a, char *b, int c)
{
    c =a+c+234;
}

int foo2(int d)
{
    return d*d;
}

int bar1, bar2, bar3;
char * bar4;

int main(void) {
     int h;
     bar1 = foo2(1);
     bar2 = foo2(1);

     h = foo2(1);
     foo1(1, "a", foo2(1));
     foo1(bar1, "a", foo2(1));
     foo2(1);

     h = foo2(1);
     bar3 = 1;
     bar4 = "a";
     foo1(1, "n", foo2(1));
     foo1(1, "o", foo2(1));
     foo1(1, "p", foo2(1));
     foo1(bar1, "a", foo2(1));

     bar3 = h;
     bar4 = "b";  foo1(bar1, "b", foo2(1));
     foo1(1, "q", foo2(1));
     bar4 = "c";  foo1(1, "c", foo2(1));
     bar4 = "d";  foo1(1, "d", foo2(1));
     bar4 = "e";  foo1(1, "e", foo2(1));
     bar4 = "f";  foo1(1, "f", foo2(1));
     bar4 = "g";  foo1(1, "g", foo2(1));
     bar4 = "h";  foo1(1, "h", foo2(1));
     bar4 = "i";  foo1(1, "i", foo2(1));
     bar4 = "j";  foo1(1, "j", foo2(1));
     bar4 = "k";  foo1(1, "k", foo2(1));
     bar4 = "l";  foo1(1, "l", foo2(1));
     bar4 = "m";
     foo1(bar2, "m", foo2(1));
     exit(0);
}

Re: PIC register allocation by reload (Was: Re: egcs-1.2 stuff)

[Jeffrey A Law]

  In message < 4.2.0.37.19990506233202.036d7400@mail.lauterbach.com >you write:
  > At 23:15 06.05.99 , Geoff Keating wrote:
  > >Is this testcase already in the test suite?  It's stripped-down code
  > >from kaffe's implementation of GNU zip.
  > 
  > Geoff,
  > 
  > this testcase is not in the testsuite, but it also no longer FAILs with the
  >  
  > current cvs-egcs, reload got a _lot_ smarter since egcs-1.1. But there's 
  > one testcase in the testsuite which still shows this problem with -fpic on 
  > PPC, attached below.
I've added this test to the testsuite.  Thanks!

Jeff

Re: PIC register allocation by reload (Was: Re: egcs-1.2 stuff)

[Jeffrey A Law]

  In message < 4.2.0.37.19990506233202.036d7400@mail.lauterbach.com >you write:
  > At 23:15 06.05.99 , Geoff Keating wrote:
  > >Is this testcase already in the test suite?  It's stripped-down code
  > >from kaffe's implementation of GNU zip.
  > 
  > Geoff,
  > 
  > this testcase is not in the testsuite, but it also no longer FAILs with the
  >  
  > current cvs-egcs, reload got a _lot_ smarter since egcs-1.1. But there's 
  > one testcase in the testsuite which still shows this problem with -fpic on 
  > PPC, attached below.
I've added this test to the testsuite.  Thanks!

Jeff

Re: PIC register allocation by reload (Was: Re: egcs-1.2 stuff)

[Geoff Keating]

> Date: Thu, 06 May 1999 23:44:47 +0200
> From: Franz Sirl <Franz.Sirl-kernel@lauterbach.com>
> Cc: amylaar@cygnus.co.uk, law@cygnus.com, ghazi@snafu.Rutgers.EDU,
>         davem@cobaltmicro.com, egcs@egcs.cygnus.com
> 
> At 23:15 06.05.99 , Geoff Keating wrote:
> >Is this testcase already in the test suite?  It's stripped-down code
> >from kaffe's implementation of GNU zip.
> 
> Geoff,
> 
> this testcase is not in the testsuite, but it also no longer FAILs with the 
> current cvs-egcs, reload got a _lot_ smarter since egcs-1.1. But there's 
> one testcase in the testsuite which still shows this problem with -fpic on 
> PPC, attached below.
...

The canonical example of this sort of thing is this:

extern int v;
void f(void)
{
  asm ("" : : "r"(&v));
}

because until it actually parses the asm, reload can't tell that it's
not

extern int v;
void f(void)
{
  asm ("" : : "i"(&v));
}

which does not need the GOT register---this is not a hypothetical
example, the first one happens in glibc somewhere, and you use the
second one to override -fpic on a section of code which you know will
be in writable memory, like (on ppc):

static const double real_params[] = { 1, 2, 3.141 };

const double * params(void) __attribute__((section(".wcode"), const));
const double * params(void)
{
  const double *result;
  /* Just like `return real_params', except that it is not PIC and
     so will be faster under these circumstances (it saves building
     a stack frame, for instance).  */
  asm ("lis %0,%1@ha ; addi %0,%0,%1@lo" : "=b"(result) : "i"(real_params));
  return result;
}


-- 
Geoffrey Keating <geoffk@ozemail.com.au>

Re: PIC register allocation by reload (Was: Re: egcs-1.2 stuff)

[Geoff Keating]

> Date: Thu, 06 May 1999 23:44:47 +0200
> From: Franz Sirl <Franz.Sirl-kernel@lauterbach.com>
> Cc: amylaar@cygnus.co.uk, law@cygnus.com, ghazi@snafu.Rutgers.EDU,
>         davem@cobaltmicro.com, egcs@egcs.cygnus.com
> 
> At 23:15 06.05.99 , Geoff Keating wrote:
> >Is this testcase already in the test suite?  It's stripped-down code
> >from kaffe's implementation of GNU zip.
> 
> Geoff,
> 
> this testcase is not in the testsuite, but it also no longer FAILs with the 
> current cvs-egcs, reload got a _lot_ smarter since egcs-1.1. But there's 
> one testcase in the testsuite which still shows this problem with -fpic on 
> PPC, attached below.
...

The canonical example of this sort of thing is this:

extern int v;
void f(void)
{
  asm ("" : : "r"(&v));
}

because until it actually parses the asm, reload can't tell that it's
not

extern int v;
void f(void)
{
  asm ("" : : "i"(&v));
}

which does not need the GOT register---this is not a hypothetical
example, the first one happens in glibc somewhere, and you use the
second one to override -fpic on a section of code which you know will
be in writable memory, like (on ppc):

static const double real_params[] = { 1, 2, 3.141 };

const double * params(void) __attribute__((section(".wcode"), const));
const double * params(void)
{
  const double *result;
  /* Just like `return real_params', except that it is not PIC and
     so will be faster under these circumstances (it saves building
     a stack frame, for instance).  */
  asm ("lis %0,%1@ha ; addi %0,%0,%1@lo" : "=b"(result) : "i"(real_params));
  return result;
}


-- 
Geoffrey Keating <geoffk@ozemail.com.au>

Re: PIC register allocation by reload (Was: Re: egcs-1.2 stuff)

[Franz Sirl]

At 23:15 06.05.99 , Geoff Keating wrote:
>Is this testcase already in the test suite?  It's stripped-down code
>from kaffe's implementation of GNU zip.

Geoff,

this testcase is not in the testsuite, but it also no longer FAILs with the 
current cvs-egcs, reload got a _lot_ smarter since egcs-1.1. But there's 
one testcase in the testsuite which still shows this problem with -fpic on 
PPC, attached below.

Franz.

PS. Geoff, if you want to play with the egcs-mainline a bit, login into the 
LinuxPPC developers machine, you'll find everything under ~fsirl/egcsm 
(source) and ~fsirl/obj/cvsm (build from today), you should have full 
access there.

gcc/testsuite/gcc.dg/980523-1.c:
/* { dg-do run { target rs6000-*-linux* powerpc-*-linux*} } */
/* { dg-options "-O2 -fpic" } */


void foo1(int a, char *b, int c)
{
    c =a+c+234;
}

int foo2(int d)
{
    return d*d;
}

int bar1, bar2, bar3;
char * bar4;

int main(void) {
     int h;
     bar1 = foo2(1);
     bar2 = foo2(1);

     h = foo2(1);
     foo1(1, "a", foo2(1));
     foo1(bar1, "a", foo2(1));
     foo2(1);

     h = foo2(1);
     bar3 = 1;
     bar4 = "a";
     foo1(1, "n", foo2(1));
     foo1(1, "o", foo2(1));
     foo1(1, "p", foo2(1));
     foo1(bar1, "a", foo2(1));

     bar3 = h;
     bar4 = "b";  foo1(bar1, "b", foo2(1));
     foo1(1, "q", foo2(1));
     bar4 = "c";  foo1(1, "c", foo2(1));
     bar4 = "d";  foo1(1, "d", foo2(1));
     bar4 = "e";  foo1(1, "e", foo2(1));
     bar4 = "f";  foo1(1, "f", foo2(1));
     bar4 = "g";  foo1(1, "g", foo2(1));
     bar4 = "h";  foo1(1, "h", foo2(1));
     bar4 = "i";  foo1(1, "i", foo2(1));
     bar4 = "j";  foo1(1, "j", foo2(1));
     bar4 = "k";  foo1(1, "k", foo2(1));
     bar4 = "l";  foo1(1, "l", foo2(1));
     bar4 = "m";
     foo1(bar2, "m", foo2(1));
     exit(0);
}

Re: PIC register allocation by reload (Was: Re: egcs-1.2 stuff)

[Geoff Keating]

> Date: Thu, 06 May 1999 22:36:17 +0200
> From: Franz Sirl <Franz.Sirl-kernel@lauterbach.com>
> Cc: law@cygnus.com, ghazi@snafu.Rutgers.EDU, davem@cobaltmicro.com,
>         egcs@egcs.cygnus.com, geoffk@ozemail.com.au
> 
> At 19:46 30.04.99 , Joern Rennecke wrote:
> > >
> > >   In message <199903281412.JAA02308@caip.rutgers.edu>you write:
> > >   >   I think we should address the -fpic/-fPIC failures on the sparc.
> > >   > This would affect glibc or really any shared library.  IIRC, Dave had a
> > >   > preliminary fix early last fall around the time we split the 1.1.x
> > >   > branch.  For some reason it never went in.  (?)
> > > If it's the problem I think it is then it's unlikely we'll have a general
> > > solution in time for egcs-1.2.
> > >
> > > Lazy allocation of the PIC register is a bad bad idea right now.  It's 
> > going
> > > to consistently lose.  If we want this to work 100% reliably for 
> > egcs-1.2, then
> > > the backend is going to need to pre-allocate the register early and 
> > take the
> > > performance hit.  This effects multiple ports that have tried to do lazy
> > > allocation of the PIC register (for example the ppc).

Yes.

> > > Then someone will need to block out some significant time post egcs-1.2 
> > to fix
> > > the problem correctly.  It's not a simple problem to fix.

Yes.

> >I think that, if no PIC register is preallocated and we find during
> >reload that we need one after all, we should just load it with a secondary
> >reload (by defining SECONDARY_RELOAD_INPUT_CLASS and reload_in[sd]i
> >appropriately).
> >We should check that reload inheritance works for the temporarily
> >allocated PIC register.  Then we should get actually better code than if
> >we allocated the PIC register for the entire function.

Regrettably, it's more complex than that.

It's not just the case of suddenly discovering that a routine, which
previously didn't have a PIC register, needs one.  It's also the
case when a routine which already has a PIC register finds that it
needs to access it in more and/or different places than before.

The example I have of this is attached below.  Look at register 26; it
is the PIC register, yet it gets stomped just after label '.L5'; and
there's a flow of control from there to just after label '.L13' where
the PIC register is used.  Compile under 1.1.1, targetting
powerpc-linux with '-O -fpic'.  The problem here is triggered by
reload deciding to do some constant rearrangement because of a
REG_EQUIV note: it sees this

(insn 264 261 266 (set (reg:SI 117)
        (unspec[ 
                (symbol_ref:SI ("@h_malloc"))
                (reg:SI 128)
            ]  8)) 398 {*movsi_got_internal} (nil)
    (expr_list:REG_EQUIV (symbol_ref:SI ("@h_malloc"))
        (nil)))

and decides that it can then simplify this insn:

(insn 160 158 162 (set (reg:SI 120)
        (mem:SI (reg:SI 117))) 402 {movsi+1} (nil)
    (nil))

by rewriting it as

(insn 160 158 162 (set (reg:SI 120)
        (symbol_ref:SI ("@h_malloc"))) (nil) 
    (nil))

because register 117 is equivalent to the symbol_ref;
but it actually ends up as

(insn 160 158 162 (set (reg:SI 120)
        (unspec[ 
                (symbol_ref:SI ("@h_malloc"))
                (reg:SI 128)
            ]  8)) 398 {*movsi_got_internal} (nil)
     (nil))

and suddenly there's a new use of register 128 that wasn't there
before, and this causes global alloc to fail.

Similar problems happen with floating-point constants.

Is this testcase already in the test suite?  It's stripped-down code
from kaffe's implementation of GNU zip.

If you want a temporary fix, I've previously posted a solution which
ensures that reload will never ask for a new occurrence of the PIC
register.  It should be in the egcs-patches archive.  If you use this,
then there is no need to do anything else.  It would need to be ported
to sparc if it is needed there (the port consists of defining two
preprocessor variables in sparc.h).  The patch operates by forcing reload
to never spill constants to memory (only when -fpic, of course).  It
works OK on powerpc, but on sparc it might need some more code in the
machine description to make life easier for the crippled reload---I
would be glad to help here.

On powerpc, I'm not sure that you can use reload in the way suggested.
I suspect there are cases in which it won't be able to reload the link
register, for instance when folding switch statements.

> Hmm, would this solution possibly be OK for 1.2? It really would be great 
> if this was solved once and forever, so if you have some code to try I'm 
> willing to test it on PPC.

Certainly, if there's code already written I'm happy to run it against
my test suite.

-- 
Geoffrey Keating <geoffk@ozemail.com.au>

===File ~/gcc-bugs/test11.s=================================
	.file	"test11.c"
gcc2_compiled.:
	.globl memset
	.section	".text"
	.align 2
	.type	 doit,@function
doit:
	stwu 1,-176(1)
	mflr 0
	stw 14,104(1)
	stw 15,108(1)
	stw 16,112(1)
	stw 17,116(1)
	stw 18,120(1)
	stw 19,124(1)
	stw 20,128(1)
	stw 21,132(1)
	stw 22,136(1)
	stw 23,140(1)
	stw 24,144(1)
	stw 25,148(1)
	stw 26,152(1)
	stw 27,156(1)
	stw 28,160(1)
	stw 29,164(1)
	stw 30,168(1)
	stw 31,172(1)
	stw 0,180(1)
	bl _GLOBAL_OFFSET_TABLE_@local-4
	mflr 26
	mr 18,3
	mr 16,4
	mr 17,5
	mr 22,6
	addi 3,1,72
	li 4,0
	li 5,16
	crxor 6,6,6
	bl memset@plt
	addi 3,1,8
	li 4,0
	li 5,60
	crxor 6,6,6
	bl memset@plt
	li 31,0
	li 3,0
	li 27,0
	addi 25,1,12
	li 30,1
	addi 19,1,72
	li 14,1
	li 15,0
	addi 20,1,88
.L5:
	li 26,0
	slwi 21,30,2
.L9:
	cmplw 0,30,31
	bc 4,1,.L11
	addi 23,26,1
	addi 0,30,-1
	slwi 24,0,2
.L12:
	slwi 0,27,2
	lwzx 31,25,0
	addi 27,27,1
	mr 9,31
	cmplw 0,31,23
	bc 4,1,.L13
	add 11,19,21
	cmplwi 0,31,1
	bc 12,1,.L13
.L18:
	slwi 0,9,2
	lwzx 0,11,0
	cmplw 0,31,0
	bc 12,1,.L13
	addi 9,9,1
	cmplwi 0,9,1
	bc 4,1,.L18
.L13:
	slwi 0,27,2
	stwx 9,25,0
	lwz 10,h_malloc@got(26)
	lwz 0,0(10)
	slw 3,14,18
	mtlr 0
	blrl
	stw 3,0(22)
	addi 22,3,4
	stw 15,4(3)
	stwx 3,24,20
	cmplw 0,30,31
	bc 12,1,.L12
.L11:
	mr 28,16
	mr 29,17
	stw 28,0(3)
	stw 29,4(3)
	addi 26,26,1
	cmplwi 0,26,6
	bc 4,1,.L9
	addi 30,30,1
	cmplwi 0,30,2
	bc 4,1,.L5
	lwz 0,180(1)
	mtlr 0
	lwz 14,104(1)
	lwz 15,108(1)
	lwz 16,112(1)
	lwz 17,116(1)
	lwz 18,120(1)
	lwz 19,124(1)
	lwz 20,128(1)
	lwz 21,132(1)
	lwz 22,136(1)
	lwz 23,140(1)
	lwz 24,144(1)
	lwz 25,148(1)
	lwz 26,152(1)
	lwz 27,156(1)
	lwz 28,160(1)
	lwz 29,164(1)
	lwz 30,168(1)
	lwz 31,172(1)
	la 1,176(1)
	blr
.Lfe1:
	.size	 doit,.Lfe1-doit
	.align 2
	.globl is_ok
	.type	 is_ok,@function
is_ok:
	stwu 1,-16(1)
	mflr 0
	stw 0,20(1)
	li 3,0
	crxor 6,6,6
	bl exit@plt
.Lfe2:
	.size	 is_ok,.Lfe2-is_ok
	.align 2
	.globl main
	.type	 main,@function
main:
	stwu 1,-16(1)
	mflr 0
	stw 0,20(1)
	bl _GLOBAL_OFFSET_TABLE_@local-4
	mflr 9
	lwz 11,h_malloc@got(9)
	lwz 9,is_ok@got(9)
	stw 9,0(11)
	li 3,0
	li 4,0
	li 5,0
	li 6,0
	bl doit@local
	bl abort@plt
.Lfe3:
	.size	 main,.Lfe3-main
	.comm	h_malloc,4,4
	.ident	"GCC: (GNU) egcs-2.91.54 19980816 (gcc2 ss-980609 experimental)"
============================================================

===File ~/gcc-bugs/test11.c=================================
typedef struct _huft {
  unsigned 	e;
  struct _huft* t;
} huft;

huft*   (*h_malloc)(unsigned);

static void
doit( unsigned p2, unsigned p3, huft *p4, huft** t)
{
  unsigned a, h, j, k, w;
  unsigned *xp, *l;
  unsigned lx[2*7+1], v[2*2];
  huft *q;
  huft r;
  huft *u[2];

  memset(v, 0, sizeof(v));
  memset(lx, 0, sizeof(lx));

  w = 0;
  q = 0;
  h = 0;
  l = lx+1;
  
  for (k=1; k <= 2; k++)
    for (a=0; a < 7; a++)
    {
      while (k > w)
      {
        w = l[h++];   

	j = w;
        if (w > a + 1)
        {
          xp = v + k;
          while (j < 2 && w <= xp[j])
	    ++j;
        }
        l[h] = j;        

        q = h_malloc(1<<p2);
        *t = q;
        t = &(q->t);
	*t = 0;
	u[k-1] = q;
      }

      r.e = p3;
      r.t = p4;
      q[0] = r;
    }
}

huft *is_ok(unsigned x) 
{
  exit(0);
}

int main() { h_malloc = is_ok; doit(0, 0, 0, 0); abort(); }

 
============================================================

Re: PIC register allocation by reload (Was: Re: egcs-1.2 stuff)

[Franz Sirl]

At 19:46 30.04.99 , Joern Rennecke wrote:
> >
> >   In message <199903281412.JAA02308@caip.rutgers.edu>you write:
> >   >   I think we should address the -fpic/-fPIC failures on the sparc.
> >   > This would affect glibc or really any shared library.  IIRC, Dave had a
> >   > preliminary fix early last fall around the time we split the 1.1.x
> >   > branch.  For some reason it never went in.  (?)
> > If it's the problem I think it is then it's unlikely we'll have a general
> > solution in time for egcs-1.2.
> >
> > Lazy allocation of the PIC register is a bad bad idea right now.  It's 
> going
> > to consistently lose.  If we want this to work 100% reliably for 
> egcs-1.2, then
> > the backend is going to need to pre-allocate the register early and 
> take the
> > performance hit.  This effects multiple ports that have tried to do lazy
> > allocation of the PIC register (for example the ppc).
> >
> > Then someone will need to block out some significant time post egcs-1.2 
> to fix
> > the problem correctly.  It's not a simple problem to fix.
>
>I think that, if no PIC register is preallocated and we find during
>reload that we need one after all, we should just load it with a secondary
>reload (by defining SECONDARY_RELOAD_INPUT_CLASS and reload_in[sd]i
>appropriately).
>We should check that reload inheritance works for the temporarily
>allocated PIC register.  Then we should get actually better code than if
>we allocated the PIC register for the entire function.

Hmm, would this solution possibly be OK for 1.2? It really would be great 
if this was solved once and forever, so if you have some code to try I'm 
willing to test it on PPC.

Franz.

Re: egcs-1.2 stuff

[Kaveh R. Ghazi]

 > From: Jeffrey A Law <law@hurl.cygnus.com> 
 > 
 > 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:
 > 
 >         7. Various bugs effecting glibc, the linux kernel, mips large frames,
 >            etc etc.  Basically some major bug hunting sessions.


	I think we should address the -fpic/-fPIC failures on the sparc. 
This would affect glibc or really any shared library.  IIRC, Dave had a
preliminary fix early last fall around the time we split the 1.1.x
branch.  For some reason it never went in.  (?)

 > Mon Sep  7 22:04:51 1998  David S. Miller  <davem@pierdol.cobaltmicro.com>
 > 
 >         * config/sparc/sparc.c (legitimize_pic_address): If during or
 >         after reload, and no PIC references existed before reload, emit
 >         get_pc sequence to setup pic base register for all such
 >         references.

	Of course maybe this is completely unrelated to the failures I'm
seeing today. :-)  For an example of the recent -fpic/-fPIC failures
(and beyond above what normally occurs) see:

http://egcs.cygnus.com/ml/egcs-testresults/1999-03/msg00353.html


		--Kaveh
--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Qwest Internet Solutions

RE: egcs-1.2 stuff

[Dana, Eric]

Jeff,

  Two questions regarding the 1.2 schedule:

    1.) Solaris 2.7 (aka. 64-bit) sparc support.

    2.) Exception handling in shared libraries.

  Should/are either of the above scheduled for 1.2? I'm willing to
  help work on either of them.

--Eric--

-----Original Message-----
From: Jeffrey A Law [ mailto:law@upchuck.cygnus.com ]
Sent: Thursday, April 01, 1999 5:08 AM
To: egcs@egcs.cygnus.com
Subject: egcs-1.2 stuff



As y'all know we're ramping up the egcs-1.2 release process at the current
time.  We are mostly focusing on dealing with wrapping up major issues that
need to be addressed for egcs-1.2.

I've put a new page on the web server to track the progress/status of this
release:

http://egcs.cygnus.com/egcs-1.2/schedule.html

It's very rough at the moment, but will be updated regularly as the
schedule, regression testing, release criteria, etc are defined for
this release.

I would like to have a rough schedule (feature freeze, branch date,
bugfixing & testing period, etc) ready by this time next week.

--

We still need one or two volunteers to help coordinate the regression and 
package testing efforts.

While I could do this again for egcs-1.2, I think the release process would
run quicker and smoother if I concentrated on patch review and fixing
regressions reported to me by the testing coordinator(s).

I'm going to be traveling from Apr 18 - Apr 24 with some net access, but
things will have to slow down during that period.  I expect to be on the
road without net access for a few weekends in April & May.


Cheers,
Jeff

Re: egcs-1.2 stuff

[Martin v. Loewis]

>     2.) Exception handling in shared libraries.

Maybe I didn't follow that too closely - but isn't the issue more
specific than that? AFAIK, exception handling in shared libraries
works fine for i586-pc-linux-gnu.

Regards,
Martin

Re: egcs-1.2 stuff

[Eric Dana]

Martin,

   To be specific about what OS's I'm referring to:

    Digital (Compaq) Unix 3.c or later (4.x)
    Solaris 2.5 or later
    HPUX 10.x or later
    AIX 4.x 4.3 or ater, although we also support 4.1.4)
    Linux 2.x (probably 2.2.x)

--Eric--

On Thu, 1 Apr 1999, Martin v. Loewis wrote:

> >     2.) Exception handling in shared libraries.
> 
> Maybe I didn't follow that too closely - but isn't the issue more
> specific than that? AFAIK, exception handling in shared libraries
> works fine for i586-pc-linux-gnu.
> 
> Regards,
> Martin
> 

Re: egcs-1.2 stuff

[Jeffrey A Law]

  In message < Pine.A32.3.91.990402173629.16834A-100000@aix10.bgs.com >you write:
  > Martin,
  > 
  >    To be specific about what OS's I'm referring to:
  > 
  >     Digital (Compaq) Unix 3.c or later (4.x)
  >     Solaris 2.5 or later
  >     HPUX 10.x or later
  >     AIX 4.x 4.3 or ater, although we also support 4.1.4)
  >     Linux 2.x (probably 2.2.x)
If HPUX isn't working now, it definitely won't in time for egcs-1.2.

"Linux 2.x" isn't enough.  If you specific particular targets like x86,
powerpc, alpha, etc then people are likely to be able to help.

For the x86 linux ports, to the best of my knowledge EH and shared libraries
should work fine.

jeff

Re: egcs-1.2 stuff

[Jeffrey A Law]

  In message < Pine.A32.3.91.990402173629.16834A-100000@aix10.bgs.com >you write:
  > Martin,
  > 
  >    To be specific about what OS's I'm referring to:
  > 
  >     Digital (Compaq) Unix 3.c or later (4.x)
  >     Solaris 2.5 or later
  >     HPUX 10.x or later
  >     AIX 4.x 4.3 or ater, although we also support 4.1.4)
  >     Linux 2.x (probably 2.2.x)
If HPUX isn't working now, it definitely won't in time for egcs-1.2.

"Linux 2.x" isn't enough.  If you specific particular targets like x86,
powerpc, alpha, etc then people are likely to be able to help.

For the x86 linux ports, to the best of my knowledge EH and shared libraries
should work fine.

jeff

Re: egcs-1.2 stuff

[Martin v. Loewis]

> >     2.) Exception handling in shared libraries.
[...]
>    To be specific about what OS's I'm referring to:
[...]
>    Solaris 2.5 or later
>    Linux 2.x (probably 2.2.x)

Then I suggest you file a bug report, with specific source code. The
example attached works for me on i586-pc-linux-gnu and
sparc-sun-solaris2.5.1, with egcs 1.1 and later (didn't test earlier).

Regards,
Martin

#!/bin/sh
# This is a shell archive (produced by GNU sharutils 4.2).
# To extract the files from this archive, save it to some FILE, remove
# everything before the `!/bin/sh' line above, then type `sh FILE'.
#
# Made on 1999-04-03 01:38 CEST by <martin@mira>.
# Source directory was `/home/martin/tmp/s'.
#
# Existing files will *not* be overwritten unless `-c' is specified.
#
# This shar contains:
# length mode       name
# ------ ---------- ------------------------------------------
#     65 -rw-rw-r-- a.cc
#     89 -rw-rw-r-- b.cc
#     87 -rw-rw-r-- Makefile
#
save_IFS="${IFS}"
IFS="${IFS}:"
gettext_dir=FAILED
locale_dir=FAILED
first_param="$1"
for dir in $PATH
do
  if test "$gettext_dir" = FAILED && test -f $dir/gettext \
     && ($dir/gettext --version >/dev/null 2>&1)
  then
    set `$dir/gettext --version 2>&1`
    if test "$3" = GNU
    then
      gettext_dir=$dir
    fi
  fi
  if test "$locale_dir" = FAILED && test -f $dir/shar \
     && ($dir/shar --print-text-domain-dir >/dev/null 2>&1)
  then
    locale_dir=`$dir/shar --print-text-domain-dir`
  fi
done
IFS="$save_IFS"
if test "$locale_dir" = FAILED || test "$gettext_dir" = FAILED
then
  echo=echo
else
  TEXTDOMAINDIR=$locale_dir
  export TEXTDOMAINDIR
  TEXTDOMAIN=sharutils
  export TEXTDOMAIN
  echo="$gettext_dir/gettext -s"
fi
touch -am 1231235999 $$.touch >/dev/null 2>&1
if test ! -f 1231235999 && test -f $$.touch; then
  shar_touch=touch
else
  shar_touch=:
  echo
  $echo 'WARNING: not restoring timestamps.  Consider getting and'
  $echo "installing GNU \`touch', distributed in GNU File Utilities..."
  echo
fi
rm -f 1231235999 $$.touch
#
if mkdir _sh22357; then
  $echo 'x -' 'creating lock directory'
else
  $echo 'failed to create lock directory'
  exit 1
fi
# ============= a.cc ==============
if test -f 'a.cc' && test "$first_param" != -c; then
  $echo 'x -' SKIPPING 'a.cc' '(file already exists)'
else
  $echo 'x -' extracting 'a.cc' '(text)'
  sed 's/^X//' << 'SHAR_EOF' > 'a.cc' &&
void f()
{
X  throw 1;
}
X
extern void g();
X
int main()
{
X  g();
}
SHAR_EOF
  $shar_touch -am 0403013499 'a.cc' &&
  chmod 0664 'a.cc' ||
  $echo 'restore of' 'a.cc' 'failed'
  if ( md5sum --help 2>&1 | grep 'sage: md5sum \[' ) >/dev/null 2>&1 \
  && ( md5sum --version 2>&1 | grep -v 'textutils 1.12' ) >/dev/null; then
    md5sum -c << SHAR_EOF >/dev/null 2>&1 \
    || $echo 'a.cc:' 'MD5 check failed'
339517457b663c446ea16a3932aca1a6  a.cc
SHAR_EOF
  else
    shar_count="`LC_ALL= LC_CTYPE= LANG= wc -c < 'a.cc'`"
    test 65 -eq "$shar_count" ||
    $echo 'a.cc:' 'original size' '65,' 'current size' "$shar_count!"
  fi
fi
# ============= b.cc ==============
if test -f 'b.cc' && test "$first_param" != -c; then
  $echo 'x -' SKIPPING 'b.cc' '(file already exists)'
else
  $echo 'x -' extracting 'b.cc' '(text)'
  sed 's/^X//' << 'SHAR_EOF' > 'b.cc' &&
#include <stdio.h>
X
void f();
X
void g()
try{
X  f();
}catch(int){
X  printf("caught\n");
}
SHAR_EOF
  $shar_touch -am 0403013599 'b.cc' &&
  chmod 0664 'b.cc' ||
  $echo 'restore of' 'b.cc' 'failed'
  if ( md5sum --help 2>&1 | grep 'sage: md5sum \[' ) >/dev/null 2>&1 \
  && ( md5sum --version 2>&1 | grep -v 'textutils 1.12' ) >/dev/null; then
    md5sum -c << SHAR_EOF >/dev/null 2>&1 \
    || $echo 'b.cc:' 'MD5 check failed'
80d5a2da7ac59fe00b3ad52a5bd6f5ae  b.cc
SHAR_EOF
  else
    shar_count="`LC_ALL= LC_CTYPE= LANG= wc -c < 'b.cc'`"
    test 89 -eq "$shar_count" ||
    $echo 'b.cc:' 'original size' '89,' 'current size' "$shar_count!"
  fi
fi
# ============= Makefile ==============
if test -f 'Makefile' && test "$first_param" != -c; then
  $echo 'x -' SKIPPING 'Makefile' '(file already exists)'
else
  $echo 'x -' extracting 'Makefile' '(text)'
  sed 's/^X//' << 'SHAR_EOF' > 'Makefile' &&
a:	a.cc b.so
X	g++ -export-dynamic -o a a.cc b.so
X
b.so:	b.cc
X	g++ -shared -o b.so b.cc
SHAR_EOF
  $shar_touch -am 0403013699 'Makefile' &&
  chmod 0664 'Makefile' ||
  $echo 'restore of' 'Makefile' 'failed'
  if ( md5sum --help 2>&1 | grep 'sage: md5sum \[' ) >/dev/null 2>&1 \
  && ( md5sum --version 2>&1 | grep -v 'textutils 1.12' ) >/dev/null; then
    md5sum -c << SHAR_EOF >/dev/null 2>&1 \
    || $echo 'Makefile:' 'MD5 check failed'
2097ed674305d607d116bdfbce85303d  Makefile
SHAR_EOF
  else
    shar_count="`LC_ALL= LC_CTYPE= LANG= wc -c < 'Makefile'`"
    test 87 -eq "$shar_count" ||
    $echo 'Makefile:' 'original size' '87,' 'current size' "$shar_count!"
  fi
fi
rm -fr _sh22357
exit 0

Re: egcs-1.2 stuff

[Martin v. Loewis]

> >     2.) Exception handling in shared libraries.
[...]
>    To be specific about what OS's I'm referring to:
[...]
>    Solaris 2.5 or later
>    Linux 2.x (probably 2.2.x)

Then I suggest you file a bug report, with specific source code. The
example attached works for me on i586-pc-linux-gnu and
sparc-sun-solaris2.5.1, with egcs 1.1 and later (didn't test earlier).

Regards,
Martin

#!/bin/sh
# This is a shell archive (produced by GNU sharutils 4.2).
# To extract the files from this archive, save it to some FILE, remove
# everything before the `!/bin/sh' line above, then type `sh FILE'.
#
# Made on 1999-04-03 01:38 CEST by <martin@mira>.
# Source directory was `/home/martin/tmp/s'.
#
# Existing files will *not* be overwritten unless `-c' is specified.
#
# This shar contains:
# length mode       name
# ------ ---------- ------------------------------------------
#     65 -rw-rw-r-- a.cc
#     89 -rw-rw-r-- b.cc
#     87 -rw-rw-r-- Makefile
#
save_IFS="${IFS}"
IFS="${IFS}:"
gettext_dir=FAILED
locale_dir=FAILED
first_param="$1"
for dir in $PATH
do
  if test "$gettext_dir" = FAILED && test -f $dir/gettext \
     && ($dir/gettext --version >/dev/null 2>&1)
  then
    set `$dir/gettext --version 2>&1`
    if test "$3" = GNU
    then
      gettext_dir=$dir
    fi
  fi
  if test "$locale_dir" = FAILED && test -f $dir/shar \
     && ($dir/shar --print-text-domain-dir >/dev/null 2>&1)
  then
    locale_dir=`$dir/shar --print-text-domain-dir`
  fi
done
IFS="$save_IFS"
if test "$locale_dir" = FAILED || test "$gettext_dir" = FAILED
then
  echo=echo
else
  TEXTDOMAINDIR=$locale_dir
  export TEXTDOMAINDIR
  TEXTDOMAIN=sharutils
  export TEXTDOMAIN
  echo="$gettext_dir/gettext -s"
fi
touch -am 1231235999 $$.touch >/dev/null 2>&1
if test ! -f 1231235999 && test -f $$.touch; then
  shar_touch=touch
else
  shar_touch=:
  echo
  $echo 'WARNING: not restoring timestamps.  Consider getting and'
  $echo "installing GNU \`touch', distributed in GNU File Utilities..."
  echo
fi
rm -f 1231235999 $$.touch
#
if mkdir _sh22357; then
  $echo 'x -' 'creating lock directory'
else
  $echo 'failed to create lock directory'
  exit 1
fi
# ============= a.cc ==============
if test -f 'a.cc' && test "$first_param" != -c; then
  $echo 'x -' SKIPPING 'a.cc' '(file already exists)'
else
  $echo 'x -' extracting 'a.cc' '(text)'
  sed 's/^X//' << 'SHAR_EOF' > 'a.cc' &&
void f()
{
X  throw 1;
}
X
extern void g();
X
int main()
{
X  g();
}
SHAR_EOF
  $shar_touch -am 0403013499 'a.cc' &&
  chmod 0664 'a.cc' ||
  $echo 'restore of' 'a.cc' 'failed'
  if ( md5sum --help 2>&1 | grep 'sage: md5sum \[' ) >/dev/null 2>&1 \
  && ( md5sum --version 2>&1 | grep -v 'textutils 1.12' ) >/dev/null; then
    md5sum -c << SHAR_EOF >/dev/null 2>&1 \
    || $echo 'a.cc:' 'MD5 check failed'
339517457b663c446ea16a3932aca1a6  a.cc
SHAR_EOF
  else
    shar_count="`LC_ALL= LC_CTYPE= LANG= wc -c < 'a.cc'`"
    test 65 -eq "$shar_count" ||
    $echo 'a.cc:' 'original size' '65,' 'current size' "$shar_count!"
  fi
fi
# ============= b.cc ==============
if test -f 'b.cc' && test "$first_param" != -c; then
  $echo 'x -' SKIPPING 'b.cc' '(file already exists)'
else
  $echo 'x -' extracting 'b.cc' '(text)'
  sed 's/^X//' << 'SHAR_EOF' > 'b.cc' &&
#include <stdio.h>
X
void f();
X
void g()
try{
X  f();
}catch(int){
X  printf("caught\n");
}
SHAR_EOF
  $shar_touch -am 0403013599 'b.cc' &&
  chmod 0664 'b.cc' ||
  $echo 'restore of' 'b.cc' 'failed'
  if ( md5sum --help 2>&1 | grep 'sage: md5sum \[' ) >/dev/null 2>&1 \
  && ( md5sum --version 2>&1 | grep -v 'textutils 1.12' ) >/dev/null; then
    md5sum -c << SHAR_EOF >/dev/null 2>&1 \
    || $echo 'b.cc:' 'MD5 check failed'
80d5a2da7ac59fe00b3ad52a5bd6f5ae  b.cc
SHAR_EOF
  else
    shar_count="`LC_ALL= LC_CTYPE= LANG= wc -c < 'b.cc'`"
    test 89 -eq "$shar_count" ||
    $echo 'b.cc:' 'original size' '89,' 'current size' "$shar_count!"
  fi
fi
# ============= Makefile ==============
if test -f 'Makefile' && test "$first_param" != -c; then
  $echo 'x -' SKIPPING 'Makefile' '(file already exists)'
else
  $echo 'x -' extracting 'Makefile' '(text)'
  sed 's/^X//' << 'SHAR_EOF' > 'Makefile' &&
a:	a.cc b.so
X	g++ -export-dynamic -o a a.cc b.so
X
b.so:	b.cc
X	g++ -shared -o b.so b.cc
SHAR_EOF
  $shar_touch -am 0403013699 'Makefile' &&
  chmod 0664 'Makefile' ||
  $echo 'restore of' 'Makefile' 'failed'
  if ( md5sum --help 2>&1 | grep 'sage: md5sum \[' ) >/dev/null 2>&1 \
  && ( md5sum --version 2>&1 | grep -v 'textutils 1.12' ) >/dev/null; then
    md5sum -c << SHAR_EOF >/dev/null 2>&1 \
    || $echo 'Makefile:' 'MD5 check failed'
2097ed674305d607d116bdfbce85303d  Makefile
SHAR_EOF
  else
    shar_count="`LC_ALL= LC_CTYPE= LANG= wc -c < 'Makefile'`"
    test 87 -eq "$shar_count" ||
    $echo 'Makefile:' 'original size' '87,' 'current size' "$shar_count!"
  fi
fi
rm -fr _sh22357
exit 0

Re: egcs-1.2 stuff

[Eric Dana]

Martin,

   To be specific about what OS's I'm referring to:

    Digital (Compaq) Unix 3.c or later (4.x)
    Solaris 2.5 or later
    HPUX 10.x or later
    AIX 4.x 4.3 or ater, although we also support 4.1.4)
    Linux 2.x (probably 2.2.x)

--Eric--

On Thu, 1 Apr 1999, Martin v. Loewis wrote:

> >     2.) Exception handling in shared libraries.
> 
> Maybe I didn't follow that too closely - but isn't the issue more
> specific than that? AFAIK, exception handling in shared libraries
> works fine for i586-pc-linux-gnu.
> 
> Regards,
> Martin
> 

Re: egcs-1.2 stuff

[Martin v. Loewis]

>     2.) Exception handling in shared libraries.

Maybe I didn't follow that too closely - but isn't the issue more
specific than that? AFAIK, exception handling in shared libraries
works fine for i586-pc-linux-gnu.

Regards,
Martin

Re: egcs-1.2 stuff

[Jeffrey A Law]

  In message < 618C9ED0E58FD211B19100A0C9EAF0CF1B7D35@es01-bos >you write:
  > Jeff,
  > 
  >   Two questions regarding the 1.2 schedule:
  > 
  >     1.) Solaris 2.7 (aka. 64-bit) sparc support.
I don't know where this stands.  You might talk to David Miller or Richard
Henderson to determine the state of the 64bit solaris support.


  >     2.) Exception handling in shared libraries.
Err, this should already work to the best of my knowledge.

jeff

Re: egcs-1.2 stuff

[Jeffrey A Law]

  In message < 618C9ED0E58FD211B19100A0C9EAF0CF1B7D35@es01-bos >you write:
  > Jeff,
  > 
  >   Two questions regarding the 1.2 schedule:
  > 
  >     1.) Solaris 2.7 (aka. 64-bit) sparc support.
I don't know where this stands.  You might talk to David Miller or Richard
Henderson to determine the state of the 64bit solaris support.


  >     2.) Exception handling in shared libraries.
Err, this should already work to the best of my knowledge.

jeff

RE: egcs-1.2 stuff

[Dana, Eric]

Jeff,

  Two questions regarding the 1.2 schedule:

    1.) Solaris 2.7 (aka. 64-bit) sparc support.

    2.) Exception handling in shared libraries.

  Should/are either of the above scheduled for 1.2? I'm willing to
  help work on either of them.

--Eric--

-----Original Message-----
From: Jeffrey A Law [ mailto:law@upchuck.cygnus.com ]
Sent: Thursday, April 01, 1999 5:08 AM
To: egcs@egcs.cygnus.com
Subject: egcs-1.2 stuff



As y'all know we're ramping up the egcs-1.2 release process at the current
time.  We are mostly focusing on dealing with wrapping up major issues that
need to be addressed for egcs-1.2.

I've put a new page on the web server to track the progress/status of this
release:

http://egcs.cygnus.com/egcs-1.2/schedule.html

It's very rough at the moment, but will be updated regularly as the
schedule, regression testing, release criteria, etc are defined for
this release.

I would like to have a rough schedule (feature freeze, branch date,
bugfixing & testing period, etc) ready by this time next week.

--

We still need one or two volunteers to help coordinate the regression and 
package testing efforts.

While I could do this again for egcs-1.2, I think the release process would
run quicker and smoother if I concentrated on patch review and fixing
regressions reported to me by the testing coordinator(s).

I'm going to be traveling from Apr 18 - Apr 24 with some net access, but
things will have to slow down during that period.  I expect to be on the
road without net access for a few weekends in April & May.


Cheers,
Jeff

egcs-1.2 stuff

[Jeffrey A Law]

As y'all know we're ramping up the egcs-1.2 release process at the current
time.  We are mostly focusing on dealing with wrapping up major issues that
need to be addressed for egcs-1.2.

I've put a new page on the web server to track the progress/status of this
release:

http://egcs.cygnus.com/egcs-1.2/schedule.html

It's very rough at the moment, but will be updated regularly as the
schedule, regression testing, release criteria, etc are defined for
this release.

I would like to have a rough schedule (feature freeze, branch date,
bugfixing & testing period, etc) ready by this time next week.

--

We still need one or two volunteers to help coordinate the regression and 
package testing efforts.

While I could do this again for egcs-1.2, I think the release process would
run quicker and smoother if I concentrated on patch review and fixing
regressions reported to me by the testing coordinator(s).

I'm going to be traveling from Apr 18 - Apr 24 with some net access, but
things will have to slow down during that period.  I expect to be on the
road without net access for a few weekends in April & May.


Cheers,
Jeff

egcs-1.2 stuff

[Jeffrey A Law]

As y'all know we're ramping up the egcs-1.2 release process at the current
time.  We are mostly focusing on dealing with wrapping up major issues that
need to be addressed for egcs-1.2.

I've put a new page on the web server to track the progress/status of this
release:

http://egcs.cygnus.com/egcs-1.2/schedule.html

It's very rough at the moment, but will be updated regularly as the
schedule, regression testing, release criteria, etc are defined for
this release.

I would like to have a rough schedule (feature freeze, branch date,
bugfixing & testing period, etc) ready by this time next week.

--

We still need one or two volunteers to help coordinate the regression and 
package testing efforts.

While I could do this again for egcs-1.2, I think the release process would
run quicker and smoother if I concentrated on patch review and fixing
regressions reported to me by the testing coordinator(s).

I'm going to be traveling from Apr 18 - Apr 24 with some net access, but
things will have to slow down during that period.  I expect to be on the
road without net access for a few weekends in April & May.


Cheers,
Jeff

Re: egcs-1.2 stuff

[John Wehle]

>>   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.

This patch seems to include several unrelated patches which makes it harder
to review.

  1) I have no objection to:

	* 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.

      x86 floating point conditional moves do change the FP status
      register, however gcc is currently unaware of this register.

  2) The change:

        (output_fp_conditional_move): Abort for LT, LE, GE, and GT
        signed integer comparisons.

     shouldn't be necessary since the floating point conditional move
     expander will never generate LT, LE, GE, or GT signed integer
     comparisons.  It's useful if we want a belt and suspenders approach.

  3) I have no objection to:

	(output_int_conditional_move): Use "enum rtx_code" for code
	type.

  4) I am currently rewriting various floating point patterns (including
     compare) and prefer to deal with the FCOMI and FP conditional move
     issues as part of the rewrite.  The floating point compare patterns
     do way too many things behind the scenes.  Your change to support
     FCOMI may be okay (I haven't looked closely), however it does leave
     gcc believing that that AX register is clobbered (which isn't true
     when FCOMI is used and ! IEEE).

-- John
-------------------------------------------------------------------------
|   Feith Systems  |   Voice: 1-215-646-8000  |  Email: john@feith.com  |
|    John Wehle    |     Fax: 1-215-540-5495  |                         |
-------------------------------------------------------------------------

Re: egcs-1.2 stuff

[John Wehle]

>>   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.

This patch seems to include several unrelated patches which makes it harder
to review.

  1) I have no objection to:

	* 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.

      x86 floating point conditional moves do change the FP status
      register, however gcc is currently unaware of this register.

  2) The change:

        (output_fp_conditional_move): Abort for LT, LE, GE, and GT
        signed integer comparisons.

     shouldn't be necessary since the floating point conditional move
     expander will never generate LT, LE, GE, or GT signed integer
     comparisons.  It's useful if we want a belt and suspenders approach.

  3) I have no objection to:

	(output_int_conditional_move): Use "enum rtx_code" for code
	type.

  4) I am currently rewriting various floating point patterns (including
     compare) and prefer to deal with the FCOMI and FP conditional move
     issues as part of the rewrite.  The floating point compare patterns
     do way too many things behind the scenes.  Your change to support
     FCOMI may be okay (I haven't looked closely), however it does leave
     gcc believing that that AX register is clobbered (which isn't true
     when FCOMI is used and ! IEEE).

-- John
-------------------------------------------------------------------------
|   Feith Systems  |   Voice: 1-215-646-8000  |  Email: john@feith.com  |
|    John Wehle    |     Fax: 1-215-540-5495  |                         |
-------------------------------------------------------------------------

Re: egcs-1.2 stuff

[Jeffrey A Law]

  In message <199903312259.RAA09293@jwlab.FEITH.COM>you write:
  > This patch seems to include several unrelated patches which makes it harder
  > to review.
  > 
  >   1) I have no objection to:
  > 
  > 	* 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.
  > 
  >       x86 floating point conditional moves do change the FP status
  >       register, however gcc is currently unaware of this register.
OK.  It sounds to me this change that is completely independent of the other
changes and can/should be installed regardless of the other changes.  ie it
can't hurt and may actually help some code.  I've installed this patch.

Thanks HJ & John!

jeff

Re: egcs-1.2 stuff

[Jerry Quinn]

Is there any chance of getting some pa-risc 2.0 code generation into
1.2?  Can such support be conditional on a binutils snapshot versus the
released binutils?

Jerry

-- 
Jerry Quinn                             Tel: (514) 761-8737
jquinn@nortelnetworks.com               Fax: (514) 761-8505
Speech Recognition Research

Re: egcs-1.2 stuff

[Jeffrey A Law]

  In message < 37039BB7.D83CE079@americasm01.nt.com >you write:
  > Is there any chance of getting some pa-risc 2.0 code generation into
  > 1.2?  Can such support be conditional on a binutils snapshot versus the
  > released binutils?
Maybe.  A lot depends on how quickly we can get some more important issues
resolved.  

jeff

Re: egcs-1.2 stuff

[Jeffrey A Law]

  In message < 37039BB7.D83CE079@americasm01.nt.com >you write:
  > Is there any chance of getting some pa-risc 2.0 code generation into
  > 1.2?  Can such support be conditional on a binutils snapshot versus the
  > released binutils?
Maybe.  A lot depends on how quickly we can get some more important issues
resolved.  

jeff

Re: egcs-1.2 stuff

[Jerry Quinn]

Is there any chance of getting some pa-risc 2.0 code generation into
1.2?  Can such support be conditional on a binutils snapshot versus the
released binutils?

Jerry

-- 
Jerry Quinn                             Tel: (514) 761-8737
jquinn@nortelnetworks.com               Fax: (514) 761-8505
Speech Recognition Research

Re: egcs-1.2 stuff

[Jeffrey A Law]

  In message <199903312259.RAA09293@jwlab.FEITH.COM>you write:
  > This patch seems to include several unrelated patches which makes it harder
  > to review.
  > 
  >   1) I have no objection to:
  > 
  > 	* 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.
  > 
  >       x86 floating point conditional moves do change the FP status
  >       register, however gcc is currently unaware of this register.
OK.  It sounds to me this change that is completely independent of the other
changes and can/should be installed regardless of the other changes.  ie it
can't hurt and may actually help some code.  I've installed this patch.

Thanks HJ & John!

jeff

Re: egcs-1.2 stuff

[Jeffrey A Law]

  In message <199903312259.RAA09293@jwlab.FEITH.COM>you write:
  >   2) The change:
  > 
  >         (output_fp_conditional_move): Abort for LT, LE, GE, and GT
  >         signed integer comparisons.
  > 
  >      shouldn't be necessary since the floating point conditional move
  >      expander will never generate LT, LE, GE, or GT signed integer
  >      comparisons.  It's useful if we want a belt and suspenders approach.
So, it's just a sanity check, right?  I see no reason not to go ahead and
install this.  Particularly since we're revamping this code either either
HJ's or your patch.

I installed this change.

Thanks,
jeff

Re: egcs-1.2 stuff

[Jeffrey A Law]

  In message <199903312259.RAA09293@jwlab.FEITH.COM>you write:
  >   2) The change:
  > 
  >         (output_fp_conditional_move): Abort for LT, LE, GE, and GT
  >         signed integer comparisons.
  > 
  >      shouldn't be necessary since the floating point conditional move
  >      expander will never generate LT, LE, GE, or GT signed integer
  >      comparisons.  It's useful if we want a belt and suspenders approach.
So, it's just a sanity check, right?  I see no reason not to go ahead and
install this.  Particularly since we're revamping this code either either
HJ's or your patch.

I installed this change.

Thanks,
jeff

Re: egcs-1.2 stuff

[Jeffrey A Law]

  In message <199903312259.RAA09293@jwlab.FEITH.COM>you write:
  >   4) I am currently rewriting various floating point patterns (including
  >      compare) and prefer to deal with the FCOMI and FP conditional move
  >      issues as part of the rewrite.  The floating point compare patterns
  >      do way too many things behind the scenes.  Your change to support
  >      FCOMI may be okay (I haven't looked closely), however it does leave
  >      gcc believing that that AX register is clobbered (which isn't true
  >      when FCOMI is used and ! IEEE).
OK.  Given that we're trying to focus on outstanding issues for egcs-1.2 do we:

  a. want to wait on your rewrite.  -- or --
  b. go ahead with remainder of HJ's patch. -- or --
  c. do nothing with the remainder of HJ's patch.

If "a", how far along are you, and when do you think it'll be ready.

If "b", we need to more closely review the remainder of HJ's patch.

If "c", well, nothing to do.

jeff

Re: egcs-1.2 stuff

[H.J. Lu]

> 
> 
>   In message <199903312259.RAA09293@jwlab.FEITH.COM>you write:
>   >   4) I am currently rewriting various floating point patterns (including
>   >      compare) and prefer to deal with the FCOMI and FP conditional move
>   >      issues as part of the rewrite.  The floating point compare patterns
>   >      do way too many things behind the scenes.  Your change to support
>   >      FCOMI may be okay (I haven't looked closely), however it does leave
>   >      gcc believing that that AX register is clobbered (which isn't true
>   >      when FCOMI is used and ! IEEE).

I think the current gcc always believes AX is clobbered. I don't think
it is an issue for the current gcc. I just used a register which gcc
thinks will be clobbered.

> OK.  Given that we're trying to focus on outstanding issues for egcs-1.2 do we:
> 
>   a. want to wait on your rewrite.  -- or --
>   b. go ahead with remainder of HJ's patch. -- or --
>   c. do nothing with the remainder of HJ's patch.
> 
> If "a", how far along are you, and when do you think it'll be ready.
> 
> If "b", we need to more closely review the remainder of HJ's patch.
> 
> If "c", well, nothing to do.
> 

FYI, I was told this made some noticeable improvement on the FP code.


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

Re: egcs-1.2 stuff

[H.J. Lu]

> 
> 
>   In message <199903312259.RAA09293@jwlab.FEITH.COM>you write:
>   >   4) I am currently rewriting various floating point patterns (including
>   >      compare) and prefer to deal with the FCOMI and FP conditional move
>   >      issues as part of the rewrite.  The floating point compare patterns
>   >      do way too many things behind the scenes.  Your change to support
>   >      FCOMI may be okay (I haven't looked closely), however it does leave
>   >      gcc believing that that AX register is clobbered (which isn't true
>   >      when FCOMI is used and ! IEEE).

I think the current gcc always believes AX is clobbered. I don't think
it is an issue for the current gcc. I just used a register which gcc
thinks will be clobbered.

> OK.  Given that we're trying to focus on outstanding issues for egcs-1.2 do we:
> 
>   a. want to wait on your rewrite.  -- or --
>   b. go ahead with remainder of HJ's patch. -- or --
>   c. do nothing with the remainder of HJ's patch.
> 
> If "a", how far along are you, and when do you think it'll be ready.
> 
> If "b", we need to more closely review the remainder of HJ's patch.
> 
> If "c", well, nothing to do.
> 

FYI, I was told this made some noticeable improvement on the FP code.


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

Re: egcs-1.2 stuff

[Jeffrey A Law]

  In message <199903312259.RAA09293@jwlab.FEITH.COM>you write:
  >   4) I am currently rewriting various floating point patterns (including
  >      compare) and prefer to deal with the FCOMI and FP conditional move
  >      issues as part of the rewrite.  The floating point compare patterns
  >      do way too many things behind the scenes.  Your change to support
  >      FCOMI may be okay (I haven't looked closely), however it does leave
  >      gcc believing that that AX register is clobbered (which isn't true
  >      when FCOMI is used and ! IEEE).
OK.  Given that we're trying to focus on outstanding issues for egcs-1.2 do we:

  a. want to wait on your rewrite.  -- or --
  b. go ahead with remainder of HJ's patch. -- or --
  c. do nothing with the remainder of HJ's patch.

If "a", how far along are you, and when do you think it'll be ready.

If "b", we need to more closely review the remainder of HJ's patch.

If "c", well, nothing to do.

jeff

Re: egcs-1.2 stuff

[John Wehle]

>>   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.

I'll try to look this over this week.

-- John
-------------------------------------------------------------------------
|   Feith Systems  |   Voice: 1-215-646-8000  |  Email: john@feith.com  |
|    John Wehle    |     Fax: 1-215-540-5495  |                         |
-------------------------------------------------------------------------

Re: egcs-1.2 stuff

[John Wehle]

>>   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.

I'll try to look this over this week.

-- John
-------------------------------------------------------------------------
|   Feith Systems  |   Voice: 1-215-646-8000  |  Email: john@feith.com  |
|    John Wehle    |     Fax: 1-215-540-5495  |                         |
-------------------------------------------------------------------------

Re: egcs-1.2 stuff

[John Wehle]

>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 wouldn't mind eliminating the leaf frame pointer by default on the
x86 if the gdb people are able to slip the necessary support into the
gdb 4.18 release (the support has been donated ... it is just a question
of timing).  The egcs changes are in:

Tue Nov  3 23:01:34 EST 1998  John Wehle  (john@feith.com)

      * i386.h (MASK_OMIT_LEAF_FRAME_POINTER): Use octal for consistency.
      (TARGET_SWITCHES): Omit leaf frame pointer by default.
      (FRAME_POINTER_REQUIRED): Use current_function_sp_is_unchanging
      instead of leaf_function_p.
      * i386.c (override_options): Have flag_omit_frame_pointer
      override TARGET_OMIT_LEAF_FRAME_POINTER.

-- John
-------------------------------------------------------------------------
|   Feith Systems  |   Voice: 1-215-646-8000  |  Email: john@feith.com  |
|    John Wehle    |     Fax: 1-215-540-5495  |                         |
-------------------------------------------------------------------------

Re: egcs-1.2 stuff

[Joern Rennecke]

> Tue Nov  3 23:01:34 EST 1998  John Wehle  (john@feith.com)
> 
>       * i386.h (MASK_OMIT_LEAF_FRAME_POINTER): Use octal for consistency.
>       (TARGET_SWITCHES): Omit leaf frame pointer by default.
>       (FRAME_POINTER_REQUIRED): Use current_function_sp_is_unchanging
>       instead of leaf_function_p.
>       * i386.c (override_options): Have flag_omit_frame_pointer
>       override TARGET_OMIT_LEAF_FRAME_POINTER.

IMHO this is bogus.  We already have the tm.h macro CAN_DEBUG_WITHOUT_FP.
Is there any reason not to use it?
Even if for some reason it can't be made to work, the place for optimization
options is OPTIMIZATION_OPTIONS.  OVERRIDE_OPTIONS has a different purpose.
If you have not already done so, please read the documentation of these
macros (e.g. in tm.texi).

Re: egcs-1.2 stuff

[Jeffrey A Law]

  In message < 199903192230.WAA03855@phal.cygnus.co.uk >you write:
  > > Tue Nov  3 23:01:34 EST 1998  John Wehle  (john@feith.com)
  > > 
  > >       * i386.h (MASK_OMIT_LEAF_FRAME_POINTER): Use octal for consistency.
  > >       (TARGET_SWITCHES): Omit leaf frame pointer by default.
  > >       (FRAME_POINTER_REQUIRED): Use current_function_sp_is_unchanging
  > >       instead of leaf_function_p.
  > >       * i386.c (override_options): Have flag_omit_frame_pointer
  > >       override TARGET_OMIT_LEAF_FRAME_POINTER.
  > 
  > IMHO this is bogus.  We already have the tm.h macro CAN_DEBUG_WITHOUT_FP.
  > Is there any reason not to use it?
Because the x86 target can not debug most functions without a frame pointer.
Actually at the current time I don't think the x86 can debug any functions
that do not have a frame pointer.

jeff

Re: egcs-1.2 stuff

[Jeffrey A Law]

  In message < 199903192230.WAA03855@phal.cygnus.co.uk >you write:
  > > Tue Nov  3 23:01:34 EST 1998  John Wehle  (john@feith.com)
  > > 
  > >       * i386.h (MASK_OMIT_LEAF_FRAME_POINTER): Use octal for consistency.
  > >       (TARGET_SWITCHES): Omit leaf frame pointer by default.
  > >       (FRAME_POINTER_REQUIRED): Use current_function_sp_is_unchanging
  > >       instead of leaf_function_p.
  > >       * i386.c (override_options): Have flag_omit_frame_pointer
  > >       override TARGET_OMIT_LEAF_FRAME_POINTER.
  > 
  > IMHO this is bogus.  We already have the tm.h macro CAN_DEBUG_WITHOUT_FP.
  > Is there any reason not to use it?
Because the x86 target can not debug most functions without a frame pointer.
Actually at the current time I don't think the x86 can debug any functions
that do not have a frame pointer.

jeff

Re: egcs-1.2 stuff

[Joern Rennecke]

> Tue Nov  3 23:01:34 EST 1998  John Wehle  (john@feith.com)
> 
>       * i386.h (MASK_OMIT_LEAF_FRAME_POINTER): Use octal for consistency.
>       (TARGET_SWITCHES): Omit leaf frame pointer by default.
>       (FRAME_POINTER_REQUIRED): Use current_function_sp_is_unchanging
>       instead of leaf_function_p.
>       * i386.c (override_options): Have flag_omit_frame_pointer
>       override TARGET_OMIT_LEAF_FRAME_POINTER.

IMHO this is bogus.  We already have the tm.h macro CAN_DEBUG_WITHOUT_FP.
Is there any reason not to use it?
Even if for some reason it can't be made to work, the place for optimization
options is OPTIMIZATION_OPTIONS.  OVERRIDE_OPTIONS has a different purpose.
If you have not already done so, please read the documentation of these
macros (e.g. in tm.texi).

Re: egcs-1.2 stuff

[John Wehle]

>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 wouldn't mind eliminating the leaf frame pointer by default on the
x86 if the gdb people are able to slip the necessary support into the
gdb 4.18 release (the support has been donated ... it is just a question
of timing).  The egcs changes are in:

Tue Nov  3 23:01:34 EST 1998  John Wehle  (john@feith.com)

      * i386.h (MASK_OMIT_LEAF_FRAME_POINTER): Use octal for consistency.
      (TARGET_SWITCHES): Omit leaf frame pointer by default.
      (FRAME_POINTER_REQUIRED): Use current_function_sp_is_unchanging
      instead of leaf_function_p.
      * i386.c (override_options): Have flag_omit_frame_pointer
      override TARGET_OMIT_LEAF_FRAME_POINTER.

-- John
-------------------------------------------------------------------------
|   Feith Systems  |   Voice: 1-215-646-8000  |  Email: john@feith.com  |
|    John Wehle    |     Fax: 1-215-540-5495  |                         |
-------------------------------------------------------------------------

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: 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