Re: Mini-patch for cccp.c

Re: Mini-patch for cccp.c

[Thomas Koenig]

I wrote:

[...]

Playing around with checkergcc some more, I found that
expand_to_temp_buffer didn't initialize some of the members of the
FILE_BUF it returns.  Dunno wether this has any grave consequences,
but I think it's a bad idea just on general principles.

Below is a patch against the origninal 970924 cccp.c which fixes this
(it also includes the previous patch).

Tue Sep 30 16:50:55 CEST 1997  Thomas Koenig  (ig25@rz.uni-karlsruhe.de)

	* cccp.c: (struct file_buf) change system_header_p to int
          (expand_to_temp_buffer) initialize all members of obuf

 static int last_error_tick;	   /* Incremented each time we print it.  */
--- cccp.c.orig	Tue Sep 30 14:43:08 1997
+++ cccp.c	Tue Sep 30 16:05:35 1997
@@ -519,7 +519,7 @@
   /* Object to be freed at end of input at this level.  */
   U_CHAR *free_ptr;
   /* True if this is a header file included using <FILENAME>.  */
-  char system_header_p;
+  int system_header_p;
 } instack[INPUT_STACK_MAX];
 
 static int last_error_tick;	   /* Incremented each time we print it.  */
@@ -3549,9 +3549,14 @@
 
   obuf.length = length * 2 + 100; /* Usually enough.  Why be stingy?  */
   obuf.bufp = obuf.buf = (U_CHAR *) xmalloc (obuf.length);
+  obuf.nominal_fname = 0;
+  obuf.inc = 0;
+  obuf.dir = 0;
   obuf.fname = 0;
   obuf.macro = 0;
+  obuf.if_stack = 0;
   obuf.free_ptr = 0;
+  obuf.system_header_p = 0;
 
   CHECK_DEPTH ({return obuf;});
 
-- 
Thomas Koenig, Thomas.Koenig@ciw.uni-karlsruhe.de, ig25@dkauni2.bitnet.
The joy of engineering is to find a straight line on a double
logarithmic diagram.

Re: Mini-patch for cccp.c

[Jeffrey A Law]

  In message < 199709301508.QAA02218@mvmap66.ciw.uni-karlsruhe.de >you write:
  > Below is a patch against the origninal 970924 cccp.c which fixes this
  > (it also includes the previous patch).
  > 
  > Tue Sep 30 16:50:55 CEST 1997  Thomas Koenig  (ig25@rz.uni-karlsruhe.de)
  > 
  > 	* cccp.c: (struct file_buf) change system_header_p to int
  >           (expand_to_temp_buffer) initialize all members of obuf
I installed the second hunk of this patch.

A couple ChangeLog notes.

The colon goes immediately after the first close paren.  ie

	* file (blah): Some change.

End sentences with a period.

The second line of a change should start with a single tab.

I've fixed these problems for the patches I've already installed.

Thanks!
jeff

Re: Mini-patch for cccp.c

[Thomas Koenig]

I wrote:

[...]

Playing around with checkergcc some more, I found that
expand_to_temp_buffer didn't initialize some of the members of the
FILE_BUF it returns.  Dunno wether this has any grave consequences,
but I think it's a bad idea just on general principles.

Below is a patch against the origninal 970924 cccp.c which fixes this
(it also includes the previous patch).

Tue Sep 30 16:50:55 CEST 1997  Thomas Koenig  (ig25@rz.uni-karlsruhe.de)

	* cccp.c: (struct file_buf) change system_header_p to int
          (expand_to_temp_buffer) initialize all members of obuf

 static int last_error_tick;	   /* Incremented each time we print it.  */
--- cccp.c.orig	Tue Sep 30 14:43:08 1997
+++ cccp.c	Tue Sep 30 16:05:35 1997
@@ -519,7 +519,7 @@
   /* Object to be freed at end of input at this level.  */
   U_CHAR *free_ptr;
   /* True if this is a header file included using <FILENAME>.  */
-  char system_header_p;
+  int system_header_p;
 } instack[INPUT_STACK_MAX];

 static int last_error_tick;	   /* Incremented each time we print it.  */
@@ -3549,9 +3549,14 @@

   obuf.length = length * 2 + 100; /* Usually enough.  Why be stingy?  */
   obuf.bufp = obuf.buf = (U_CHAR *) xmalloc (obuf.length);
+  obuf.nominal_fname = 0;
+  obuf.inc = 0;
+  obuf.dir = 0;
   obuf.fname = 0;
   obuf.macro = 0;
+  obuf.if_stack = 0;
   obuf.free_ptr = 0;
+  obuf.system_header_p = 0;

   CHECK_DEPTH ({return obuf;});

--
Thomas Koenig, Thomas.Koenig@ciw.uni-karlsruhe.de, ig25@dkauni2.bitnet.
The joy of engineering is to find a straight line on a double
logarithmic diagram.

Re: A new bug in 971114

[H.J. Lu]

> 
> On linux/x86, with egcs-971114, I got
> 
> /home/work/gnu/bin/egcs/gcc/xgcc -B/home/work/gnu/bin/egcs/gcc/ -c -fthis-is-variable -c foo.cc
> foo.cc: In function `class Int * Proc0()':
> foo.cc:9: Internal compiler error.
> foo.cc:9: Please submit a full bug report to `egcs-bugs@cygnus.com'.
> 
> egcs-971105 is fine.
> 
> 
> -- 
> H.J. Lu (hjl@gnu.ai.mit.edu)
> --
> class Int 
> {
> public: 
>   Int ();
> };
> 
> Int *Proc0()
> {
>    return new Int;
> }
> 

This kludge doesn't even look right to me. But at least, gcc doesn't
dump core now. Could someone please check it out and find a right
fix?

Thanks.


-- 
H.J. Lu (hjl@gnu.ai.mit.edu)
--
Sun Nov 16 18:34:08 1997  H.J. Lu  (hjl@gnu.ai.mit.edu)

	* init.c (build_new): Handle freeing allocated memory when the
	constructor throws only if alloc_expr is not NULL.

Index: init.c
===================================================================
RCS file: /home/work/cvs/gnu/egcs/gcc/cp/init.c,v
retrieving revision 1.1.1.5
diff -u -r1.1.1.5 init.c
--- init.c	1997/11/14 22:32:47	1.1.1.5
+++ init.c	1997/11/17 02:33:36
@@ -2720,7 +2720,7 @@
 	 new-placement, then the deallocation function is called to free
 	 the memory in which the object was being constructed.  */
       /* FIXME: handle placement delete.  */
-      if (flag_exceptions && ! placement)
+      if (flag_exceptions && ! placement && alloc_expr)
 	{
 	  tree cleanup = alloc_expr;
 

Re: egcs 1.0.3 on linux/alpha

[H.J. Lu]

> 
> I am glad to see the alpha bugs be fixed. However, with the current
> egcs 1.0.3 in CVS, there are 4 new failures:
> 
> +FAIL: gcc.c-torture/execute/compndlit-1.c compilation,  -O0 
> +FAIL: gcc.c-torture/execute/compndlit-1.c compilation,  -O1 
> +FAIL: gcc.c-torture/execute/compndlit-1.c compilation,  -O2 
> +FAIL: gcc.c-torture/execute/compndlit-1.c compilation,  -O2 -fomit-frame-pointer -finline-functions 
> 
> Can someone verify that?
> 

OOoops. My fault. Please ignore it.

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

Re: -Wall stops compiling of egcs-1.0.3

[Joe Buck]

> I tried to compile the complete set egcs-1.0.3 (the 9.5 MB tar.gz file)
> on our Sun (SunOS 5.5). The C-compiler version is
> 
> /dr_users/noell % cc -V
> cc: SC3.0.1 13 Jul 1994
> 
> The problems was, that the make process hit an error when the option -W
> or -Wall came up.
> What can I do about it? Is there any workaround? I tried to omit this
> option, but it wouldn't work either.

No one else has seen this problem, and lots of people have successfully
built egcs on Suns.  Can you give the exact error messages you received?

A bad EH bug

[H.J. Lu]

> > 
> > > On Tue, Oct 13, 1998 at 02:48:36PM -0700, Joe Buck wrote:
> > 
> > >> Please send a complete test case (a complete program) to
> > >> egcs-bugs@cygnus.com, so that the experts will be able to run it through
> > >> and figure out what goes wrong.
> > 
> > > This demonstrates the problem quite effectively. However, I'm afraid
> > > it's rather big. I had a (quick) crack at isolating the problem with
> > > little success.
> > 

# gcc bad.cc -g
# a.out
Foo::Foo
Foo::~Foo
zsh: 12158 segmentation fault  ./a.out
# gdb a.out
(gdb) r
(gdb) r
Starting program: /home/hjl/bugs/g++/opt.3/a.out 
Foo::Foo
Foo::~Foo

Program received signal SIGSEGV, Segmentation fault.
0x804a2b1 in __cp_pop_exception (p=0x4002fbaa)
    at /home/work/misc/gnu/src/egcs-1.1/gcc/cp/exception.cc:211
211       --p->handlers;
(gdb) bt
#0  0x804a2b1 in __cp_pop_exception (p=0x4002fbaa)
    at /home/work/misc/gnu/src/egcs-1.1/gcc/cp/exception.cc:211
#1  0x804947e in Base::dispatch (this=0xbffffc17, x=0) at bad.cc:80
#2  0x80494e9 in main () at bad.cc:101


BTW, it failed on Solaris/Sparc. But it works on HP-UX 10.20. It seems
it affects all platforms with DWARF2 based EH. FYI, egcs 1.0.3 is ok.
It must be a new bug. I'd like to see it be fixed in egcs 1.1.1.

Could someone please clean it up and put it into the g++ testsuite?

Thanks.


-- 
H.J. Lu (hjl@gnu.org)
---
#include <stdio.h>

class Base
{
public:
  int dispatch (int);
};

class Derived : public Base
{
};

class Foo
{
public:
  Foo ();
  ~Foo ();
  int getValue (int);
};

template<class T>
class OBObjVar
{
  T* ptr;
public:
  OBObjVar (T *p) : ptr (p) {}
  ~OBObjVar() { delete ptr; }
  T* operator->() const { return ptr; }
};

Foo * getFoo ();
Foo::Foo ()
{
  printf ("Foo::Foo\n");
}

Foo::~Foo ()
{
  printf ("Foo::~Foo\n");
}

int
Foo::getValue (int x)
{
  return x;
}

Foo*
getFoo ()
{
  return new Foo;
}

int
Base::dispatch (int x)
{
  int y = 1;

  while (y)
    {
      OBObjVar<Foo> f = getFoo ();

      try 
	{
	  y = f->getValue (x);
	}
      catch (const char *s)
	{
	  printf ("Base::dispatch: %s\n", s);
	  if (x == 0)
	    {
	      y = 0;
	      continue;
	    }

	  throw;
	}
      catch (int)
	{
	  continue;
	}

      if (y == 0)
	{
	  f->getValue (y);
	  throw "Throw an exception!";
	}

      break;
    }
  return y;
}

int
main ()
{
  Derived x;

  try
    {
      x.dispatch (0);
    }
  catch (const char *s)
    {
      printf ("Caught: %s\n", s);
    }
}

GCC 2.7.2.3 good, EGCS 1.0.3 bad for x86 subtract then test

[Jamie Lokier]

On Sun, Dec 20, 1998 at 10:38:34PM +0100, Marc Lehmann wrote:
> That means that expressions like
> 
> a-b>0
> 
> Almost always generate a seperate testl.
>
> Jamie Lokier write:
> > I even modified the code (in a private GCC) to do this for DImode
> > subtract/compare.  So there ;-)
> 
> Silly that it doesn't work (in gcc-2.7.2.3 ;)

You should have tried a-b>=0 :-)
                         ^^

The interesting thing is that the test is optimised away by GCC 2.7.3.2,
but not EGCS 1.0.3.  (Which I'd never have noticed if it weren't for
this discussion).

Here's the example program:

	extern void a (void);

	void f (int x, int y)
	{
	  if ((x -= y) >= 0)
	    a ();
	}

With GCC 2.7.2.3, it optimises to:

f:
	pushl %ebp
	movl %esp,%ebp
	movl 8(%ebp),%eax
	subl 12(%ebp),%eax
	js .L2
	call a
.L2:
	leave
	ret

With EGCS 1.0.3, -O2 it optimises to this:

f:
	pushl %ebp
	movl %esp,%ebp
	movl 12(%ebp),%eax
	movl 8(%ebp),%edx
	subl %eax,%edx
	movl %edx,%eax
	testl %eax,%eax
	jl .L2
	call a
.L2:
	leave
	ret

-mpentium etc. don't make any difference to the test.  As well is
keeping the redundant test instruction, you can also see that EGCS'
register allocation is sucking quite hard.  In fact, perhaps the
redundant spill is the reason for the redundant test.

BTW, if anyone wants my ancient DImode patch for GCC 2.7.2, ask.
Comments from the patch:

"This patch is for the i386 machine descripton of GCC 2.7.2.  It was
tested with some other changes in place, so the patch offsets may be a
little off but it should still work with an unchanged 2.7.2:

  1. Different patterns for adddi3 and subdi3.
     These use fewer move instructions in some cases (let reload
     do the work instead.  It might even be able to cope in 2.8.0).

  2. Use smaller instructions when outputting small decrements.

  3. Use the sign flag from adddi3, subdi3 and negdi2 insns, so
     they can be followed immediately by a branch.

	* i386.h (CC_NO_ZERO): New cc_status flag.
	* i386.c (notice_update_cc): Set flags for DImode ADD, SUB, NEG.
	* i386.md (adddi3, subdi3): Simplify constraints, use fewer
	explicit moves, and subtract if adding a negative constant.
	(addsi3): Subtract if adding a negative constant.
	(seq, sne, beq, bne): Take into account CC_NO_ZERO in the output
	routines for these insns."

-- Jamie

Re: GCC 2.7.2.3 good, EGCS 1.0.3 bad for x86 subtract then test

[Richard Henderson]

On Mon, Dec 21, 1998 at 10:52:13AM +0000, Jamie Lokier wrote:
> Here's the example program:
> 
> 	extern void a (void);
> 
> 	void f (int x, int y)
> 	{
> 	  if ((x -= y) >= 0)
> 	    a ();
> 	}

This is solved by a patch Jeff sent me just yesterday.


r~


From: Jeffrey A Law <law@cygnus.com>
To: rth@cygnus.com
Reply-To: law@cygnus.com
Subject: regmove change to improve x86 code
Date: Tue, 22 Dec 1998 13:23:55 -0700

Here's the patch I mentioned in the meeting.

Basically we had something like this before combine:

(set (reg1) (mem (blah))
(set (reg2) (mem (oof))
(set (reg3) (minus (reg1) (reg2))

Combine turned that into:

(set (reg3) (minus (mem (blah)) (reg2))

Which is allowed by the predicates for the subsi3 insn.

However, it loses because the first input does not match the output
operand.  This causes spills & reloads and bad code.

There were not any reg-reg copies so regmove didn't do anything with
this code.

regmove has code to try and copy a source operand into a destination
operand then change the source to match the destination.  However, it
only worked if both the source and destination operand were regs, so it
not apply in the case shown above.

The attached change allows regmove to optimize that code so that the
source and destination registers match.  As a result the number of reloads
and spills is reduced resulting in better code.

This would probably help all of our 2 address machines.  Though I have not
done any analysis.

Comments/opinions would be greatly appreciated:

	* regmove.c (copy_src_to_dest): Returns an integer now
	indicating a successful copy was performed.  Allow SRC to
	be any rtx instead of only REGs.
	(regmove_optimize): During backward pass, if a source operand
	is not a register and the destination is a register, try to copy
	the source into the destination to make them match.

	

Index: regmove.c
===================================================================
RCS file: /egcs/carton/cvsfiles/egcs/./gcc/regmove.c,v
retrieving revision 1.46
diff -c -3 -p -r1.46 regmove.c
*** regmove.c	1998/12/16 20:57:50	1.46
--- regmove.c	1998/12/22 20:16:07
*************** static int optimize_reg_copy_1	PROTO((rt
*** 42,48 ****
  static void optimize_reg_copy_2	PROTO((rtx, rtx, rtx));
  static void optimize_reg_copy_3	PROTO((rtx, rtx, rtx));
  static rtx gen_add3_insn	PROTO((rtx, rtx, rtx));
! static void copy_src_to_dest	PROTO((rtx, rtx, rtx, int));
  static int *regmove_bb_head;
  
  struct match {
--- 42,48 ----
  static void optimize_reg_copy_2	PROTO((rtx, rtx, rtx));
  static void optimize_reg_copy_3	PROTO((rtx, rtx, rtx));
  static rtx gen_add3_insn	PROTO((rtx, rtx, rtx));
! static int copy_src_to_dest	PROTO((rtx, rtx, rtx, int));
  static int *regmove_bb_head;
  
  struct match {
*************** optimize_reg_copy_3 (insn, dest, src)
*** 592,598 ****
  /* If we were not able to update the users of src to use dest directly, try
     instead moving the value to dest directly before the operation.  */
  
! static void
  copy_src_to_dest (insn, src, dest, loop_depth)
       rtx insn;
       rtx src;
--- 592,598 ----
  /* If we were not able to update the users of src to use dest directly, try
     instead moving the value to dest directly before the operation.  */
  
! static int
  copy_src_to_dest (insn, src, dest, loop_depth)
       rtx insn;
       rtx src;
*************** copy_src_to_dest (insn, src, dest, loop_
*** 617,625 ****
       parameter when there is no frame pointer that is not allocated a register.
       For now, we just reject them, rather than incrementing the live length.  */
  
!   if (GET_CODE (src) == REG
!       && REG_LIVE_LENGTH (REGNO (src)) > 0
!       && GET_CODE (dest) == REG
        && REG_LIVE_LENGTH (REGNO (dest)) > 0
        && (set = single_set (insn)) != NULL_RTX
        && !reg_mentioned_p (dest, SET_SRC (set))
--- 617,623 ----
       parameter when there is no frame pointer that is not allocated a register.
       For now, we just reject them, rather than incrementing the live length.  */
  
!   if (GET_CODE (dest) == REG
        && REG_LIVE_LENGTH (REGNO (dest)) > 0
        && (set = single_set (insn)) != NULL_RTX
        && !reg_mentioned_p (dest, SET_SRC (set))
*************** copy_src_to_dest (insn, src, dest, loop_
*** 684,702 ****
        if (REGNO_FIRST_UID (dest_regno) == insn_uid)
  	REGNO_FIRST_UID (dest_regno) = move_uid;
  
!       src_regno = REGNO (src);
!       if (! find_reg_note (move_insn, REG_DEAD, src))
! 	REG_LIVE_LENGTH (src_regno)++;
  
!       if (REGNO_FIRST_UID (src_regno) == insn_uid)
! 	REGNO_FIRST_UID (src_regno) = move_uid;
  
!       if (REGNO_LAST_UID (src_regno) == insn_uid)
! 	REGNO_LAST_UID (src_regno) = move_uid;
  
!       if (REGNO_LAST_NOTE_UID (src_regno) == insn_uid)
! 	REGNO_LAST_NOTE_UID (src_regno) = move_uid;
      }
  }
  
  \f
--- 682,705 ----
        if (REGNO_FIRST_UID (dest_regno) == insn_uid)
  	REGNO_FIRST_UID (dest_regno) = move_uid;
  
!       if (REG_P (src))
! 	{
! 	  src_regno = REGNO (src);
! 	  if (! find_reg_note (move_insn, REG_DEAD, src))
! 	    REG_LIVE_LENGTH (src_regno)++;
  
! 	  if (REGNO_FIRST_UID (src_regno) == insn_uid)
! 	    REGNO_FIRST_UID (src_regno) = move_uid;
  
! 	  if (REGNO_LAST_UID (src_regno) == insn_uid)
! 	    REGNO_LAST_UID (src_regno) = move_uid;
  
! 	  if (REGNO_LAST_NOTE_UID (src_regno) == insn_uid)
! 	    REGNO_LAST_NOTE_UID (src_regno) = move_uid;
! 	}
!       return 1;
      }
+   return 0;
  }
  
  \f
*************** regmove_optimize (f, nregs, regmove_dump
*** 1141,1153 ****
  	      dst = recog_operand[match_no];
  	      src = recog_operand[op_no];
  
- 	      if (GET_CODE (src) != REG)
- 		continue;
- 
  	      if (GET_CODE (dst) != REG
  		  || REGNO (dst) < FIRST_PSEUDO_REGISTER
  		  || REG_LIVE_LENGTH (REGNO (dst)) < 0)
  		continue;
  
  	      /* If the operands already match, then there is nothing to do.  */
  	      if (operands_match_p (src, dst)
--- 1144,1165 ----
  	      dst = recog_operand[match_no];
  	      src = recog_operand[op_no];
  
  	      if (GET_CODE (dst) != REG
  		  || REGNO (dst) < FIRST_PSEUDO_REGISTER
  		  || REG_LIVE_LENGTH (REGNO (dst)) < 0)
  		continue;
+ 
+ 	      if (GET_CODE (src) != REG)
+ 		{
+ 		  
+ 		  /* SRC may be a MEM or some other operand type.  We win
+ 		     if we can copy it to the destination and replace SRC
+ 		     with DST.  Note that DST is known to be a REG at this
+ 		     point.  If we are successful quit the loop.  */
+ 		  if (copy_src_to_dest (insn, src, dst, loop_depth))
+ 		    break;
+ 		  continue;
+ 		}
  
  	      /* If the operands already match, then there is nothing to do.  */
  	      if (operands_match_p (src, dst)

Re: GCC 2.7.2.3 good, EGCS 1.0.3 bad for x86 subtract then test

[Jeffrey A Law]

  In message < 19981223141815.C12309@dot.cygnus.com >you write:
  > On Mon, Dec 21, 1998 at 10:52:13AM +0000, Jamie Lokier wrote:
  > > Here's the example program:
  > > 
  > > 	extern void a (void);
  > > 
  > > 	void f (int x, int y)
  > > 	{
  > > 	  if ((x -= y) >= 0)
  > > 	    a ();
  > > 	}
  > 
  > This is solved by a patch Jeff sent me just yesterday.
Yea.  But it seems to generally create worse code -- too aggressive about
copying the source to the destination.  Some tweaking of the heuristic for
when to copy the source to the destination may be needed to make the change
generally useful.

jeff

Re: GCC 2.7.2.3 good, EGCS 1.0.3 bad for x86 subtract then test

[Toshiyasu Morita]

>> This is solved by a patch Jeff sent me just yesterday.
>
> Yea.  But it seems to generally create worse code -- too aggressive about
> copying the source to the destination.  Some tweaking of the heuristic for
> when to copy the source to the destination may be needed to make the change
> generally useful.
> 
> jeff

The patch seems to help some on the SH4; I see it now loading
values directly into fr0 occasionally where it didn't before:

4873:graph3d.ii    ****   min_z = M*(poly.vertices[0].sx-width2) + 
N*(poly.vertices[0].sy-height2) + O;
 1567 0308 57A5                 mov.l   @(20,r10),r7	<- bad!
 1569 030a 7104                 add     #4,r1
 1571 030c 475A                 lds     r7,fpul		<- bad!
 1573 030e F418                 fmov.s  @r1,fr4
 1575 0310 F12D                 float   fpul,fr1	<- bad!
 1577 0312 71FC                 add     #-4,r1
 1579 0314 F218                 fmov.s  @r1,fr2
 1580 0316 52A6                 mov.l   @(24,r10),r2
 1581 0318 F211                 fsub    fr1,fr2
 1582 031a 425A                 lds     r2,fpul
 1583 031c F12D                 float   fpul,fr1
 1585 031e F54C                 fmov    fr4,fr5
 1587 0320 F35C                 fmov    fr5,fr3
 1588 0322 E044                 mov     #68,r0
 1589 0324 F311                 fsub    fr1,fr3
 1590 0326 F0E6                 fmov.s  @(r0,r14),fr0
 1591 0328 F302                 fmul    fr0,fr3
 1592 032a E040                 mov     #64,r0
 1593 032c F0E6                 fmov.s  @(r0,r14),fr0	<- here
 1594 032e F32E                 fmac    fr0,fr2,fr3	<- here
 1595 0330 E048                 mov     #72,r0
 1596 0332 F0E6                 fmov.s  @(r0,r14),fr0
 1597 0334 F300                 fadd    fr0,fr3
...
 1639 0374 F0E6                 fmov.s  @(r0,r14),fr0
 1640 0376 FC2E                 fmac    fr0,fr2,fr12

...but the majority of the cases seem to be missed:

 1731 03f8 FA19                 fmov.s  @r1+,fr10	<- here 
 1733 03fa F522                 fmul    fr2,fr5
 1734 03fc F08C                 fmov    fr8,fr0
4911:graph3d.ii    ****   Q1 = poly.plane.m_cam2tex->m21;
 1736 03fe F619                 fmov.s  @r1+,fr6	<- here 
 1738 0400 F53E                 fmac    fr0,fr3,fr5
 1739 0402 7308                 add     #8,r3
4912:graph3d.ii    ****   Q2 = poly.plane.m_cam2tex->m22;
 1741 0404 F719                 fmov.s  @r1+,fr7
 1743 0406 F138                 fmov.s  @r3,fr1
 1744 0408 F0AC                 fmov    fr10,fr0	<- here 
4913:graph3d.ii    ****   Q3 = poly.plane.m_cam2tex->m23;
4914:graph3d.ii    ****   Q4 = -(Q1*poly.plane.v_cam2tex->x + 
Q2*poly.plane.v_cam2tex->y + Q3*poly.plane.v_cam2tex->z);
 1746 040a F47C                 fmov    fr7,fr4
 1748 040c F51E                 fmac    fr0,fr1,fr5	<- here 
 1750 040e F422                 fmul    fr2,fr4
 1751 0410 F06C                 fmov    fr6,fr0		<- here 
 1752 0412 F43E                 fmac    fr0,fr3,fr4	<- here 	
 1754 0414 FB18                 fmov.s  @r1,fr11	<- here 
4915:graph3d.ii    ****
4916:graph3d.ii    ****   if (Scan::tmap2)
 1756 0416 D26A                 mov.l   L464,r2
 1758 0418 F0BC                 fmov    fr11,fr0	<- here 
 1759 041a F41E                 fmac    fr0,fr1,fr4	<- here
...
4939:graph3d.ii    ****     J1 = P1*Camera::inv_aspect + P4*M;
 1842 04a8 E040                 mov     #64,r0
 1843                   L585:
 1844 04aa F2E6                 fmov.s  @(r0,r14),fr2
 1845 04ac F05C                 fmov    fr5,fr0
 1846 04ae D13F                 mov.l   L459,r1
 1847 04b0 F022                 fmul    fr2,fr0		<- here
 1848 04b2 F118                 fmov.s  @r1,fr1
 1849 04b4 F20C                 fmov    fr0,fr2		<- here
 1850 04b6 F08C                 fmov    fr8,fr0
 1851 04b8 F21E                 fmac    fr0,fr1,fr2	<- here
 1852 04ba E04C                 mov     #76,r0
 1853 04bc FE27                 fmov.s  fr2,@(r0,r14)
4940:graph3d.ii    ****     J2 = P2*Camera::inv_aspect + P4*N;
 1855 04be E044                 mov     #68,r0
 1856 04c0 F2E6                 fmov.s  @(r0,r14),fr2	<- here
 1857 04c2 F05C                 fmov    fr5,fr0
 1858 04c4 F022                 fmul    fr2,fr0		<- here
 1859 04c6 F20C                 fmov    fr0,fr2		<- here
 1860 04c8 F09C                 fmov    fr9,fr0
 1861 04ca F21E                 fmac    fr0,fr1,fr2	<- here
 1862 04cc E050                 mov     #80,r0
 1863 04ce FE27                 fmov.s  fr2,@(r0,r14)
...
4942:graph3d.ii    ****     K1 = Q1*Camera::inv_aspect + Q4*M;
 1871 04da E040                 mov     #64,r0
 1872 04dc F2E6                 fmov.s  @(r0,r14),fr2	<- here
 1873 04de F04C                 fmov    fr4,fr0
 1874 04e0 F022                 fmul    fr2,fr0		<- here
 1875 04e2 F20C                 fmov    fr0,fr2		<- here
 1876 04e4 F06C                 fmov    fr6,fr0
 1877 04e6 F21E                 fmac    fr0,fr1,fr2
 1878 04e8 E058                 mov     #88,r0
 1879 04ea FE27                 fmov.s  fr2,@(r0,r14)
4943:graph3d.ii    ****     K2 = Q2*Camera::inv_aspect + Q4*N;
 1881 04ec E044                 mov     #68,r0
 1882 04ee F2E6                 fmov.s  @(r0,r14),fr2	<- here
 1883 04f0 F04C                 fmov    fr4,fr0
 1884 04f2 F022                 fmul    fr2,fr0		<- here
 1885 04f4 F20C                 fmov    fr0,fr2		<- here
 1886 04f6 F07C                 fmov    fr7,fr0
 1887 04f8 F21E                 fmac    fr0,fr1,fr2	<- here
 1888 04fa E05C                 mov     #92,r0
...

Sometimes these sequences are justified because the value is reused;
e.g.:

	fmov 	@rm,fr9
	fmov	fr9,fr0
	fmac	fr0,frm,frn
...
	(fr0 clobbered)
	fmov	fr9,fr0
	fmac	fr0,frm,frn

however it would be nice if gcc could recognize this and convert this
to:

	fmov	@rm,fr0
	fmov	fr0,fr9
	fmac	fr0,frm,frn
...
	(fr0 clobbered)
	fmov	fr9,fr0
	fmac	fr0,frm,frn

because this sequence gives the scheduler more freedom to move the second 
instruction (fmov fr0,fr9) - it can be moved below the fmac instruction 
if necessary.

The file graph3d.ii is from my stress suite at 
ftp://shell14.ba.best.com/pub.t/~tm2/stress-1.4.tar.gz .

The file matrix.i from the stress suite also elicits the same behavior 
from egcs as well.

Toshi

Re: GCC 2.7.2.3 good, EGCS 1.0.3 bad for x86 subtract then test

[Michael Hayes]

Jeff Law writes:

 > Basically we had something like this before combine:
 > 
 > (set (reg1) (mem (blah))
 > (set (reg2) (mem (oof))
 > (set (reg3) (minus (reg1) (reg2))
 > 
 > Combine turned that into:
 > 
 > (set (reg3) (minus (mem (blah)) (reg2))
 > 
 > Which is allowed by the predicates for the subsi3 insn.
 > 
 > However, it loses because the first input does not match the output
 > operand.  This causes spills & reloads and bad code.

Why not use the extra condition to prevent the combination if the
first input does not match the output operand?

Michael.

Re: GCC 2.7.2.3 good, EGCS 1.0.3 bad for x86 subtract then test

[Jeffrey A Law]

  In message < 13956.18174.396993.213410@ongaonga.elec.canterbury.ac.nz >you writ
e:
  > Why not use the extra condition to prevent the combination if the
  > first input does not match the output operand?
Because that can miss some valueable combination opportunities.  It is also
incorrect for a condition on a named pattern to reject any insn based on
anything other than the target flags.


jeff

Re: GCC 2.7.2.3 good, EGCS 1.0.3 bad for x86 subtract then test

[Michael Hayes]

Jeffrey A Law writes:
 > 
 >   In message < 13956.18174.396993.213410@ongaonga.elec.canterbury.ac.nz >you writ
 > e:
 >   > Why not use the extra condition to prevent the combination if the
 >   > first input does not match the output operand?
 > Because that can miss some valueable combination opportunities.  It is also
 > incorrect for a condition on a named pattern to reject any insn based on
 > anything other than the target flags.

I realise you can't do this for named patterns but this is easily
overcome using named expanders (with exceptions for movMN and addP
patterns required by reload).

What valuable combination opportunities are missed if you write the
extra condition to only accept the valid operand combinations?

[I know this thread popped up a couple of months ago but I feel it was
not satisfactorily resolved...]

Michael.

Re: GCC 2.7.2.3 good, EGCS 1.0.3 bad for x86 subtract then test

[Jeffrey A Law]

  In message < 13956.46052.667366.129757@ongaonga.elec.canterbury.ac.nz >you writ
  > I realise you can't do this for named patterns but this is easily
  > overcome using named expanders (with exceptions for movMN and addP
  > patterns required by reload).
Yup.  You have to be pretty careful, particularly with the move & add
patterns.

  > What valuable combination opportunities are missed if you write the
  > extra condition to only accept the valid operand combinations?
First problem is we'll have a pseudo which is set multiple times and may
die more than once.  This inhibits instruction combination.

Even if those problems are fixed, consider:

(set (reg1) (mem (blah))
(set (reg2) (mem (oof))
(set (reg1) (minus (reg1) (reg2)
(set (mem (blah)) (reg1))


We would like to be able to convert that into:


(set (reg2) (mem (oof))
(set (mem (blah)) (minus (mem (blah)) (reg2)

Which reduces register pressure (and we'd like a post-reload splitter to
break it up into the original sequence if a free reg of the proper class can
be found).

However, to get to the desired code takes 2 combinations.  ie

step1

(set (reg2) (mem (oof))
(set (reg1) (minus (mem (blah)) (reg2)
(set (mem (blah)) (reg1))

step2:

(set (reg2) (mem (oof))
(set (mem (blah)) (minus (mem (blah)) (reg2)

But we can not perform step1 if we are rejecting cases where the source and
destination do not match.

jeff

Re: GCC 2.7.2.3 good, EGCS 1.0.3 bad for x86 subtract then test

[Michael Hayes]

Jeffrey A Law writes:
 > Even if those problems are fixed, consider:
 > 
 > (set (reg1) (mem (blah))
 > (set (reg2) (mem (oof))
 > (set (reg1) (minus (reg1) (reg2)
 > (set (mem (blah)) (reg1))
 > 
 > We would like to be able to convert that into:
 > 
 > (set (reg2) (mem (oof))
 > (set (mem (blah)) (minus (mem (blah)) (reg2)

OK, I understand now.  I've been weaned off these architectures with
read-modify-write instructions.

I suppose ideally the combiner should be able to handle this kind of
transformation rather than having to pretend that we can support more
esoteric operand combinations that we have to fix up afterwards.

Michael.

Re: FWIW: VAX fix backport and gcc built on 4.3BSD first time ever!

[John David Anglin]

> +(define_insn "call_value"
>    [(set (match_operand 0 "" "=g")
>  	(call (match_operand:QI 1 "memory_operand" "m")
> -	      (match_operand:SI 2 "const_int_operand" "n")))
> -   (set (reg:SI 14) (reg:SI 14))]
> +	      (match_operand:SI 2 "const_int_operand" "n")))]
> +  ;; Operand 2 not used on the vax.
>    ""
> -  "*
> -  if (INTVAL (operands[2]) > 255 * 4)
> -    /* Vax `calls' really uses only one byte of #args, so pop explicitly.  */
> -    return \"calls $0,%1\;addl2 %2,sp\";
> -  operands[2] = GEN_INT ((INTVAL (operands[2]) + 3)/ 4);
> -  return \"calls %2,%1\";
> -")
> +  "calls $0,%0")

There is a typo in the above.  I knew I shouldn't have sent this until
it was tested.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: FWIW: VAX fix backport and gcc built on 4.3BSD first time ever!

[John David Anglin]

Here is a revised patch for the mainline vax.md.  The bootstrap with
this patch looks like it is going ok, although it is far from complete.
I will submit the patch formally when I am certain that it is ok.

It is possible that using this new patched version with the 2.95 branch
would work.  It now has the call and call_value patterns which might enable
it to work without the call_pop/call_value_pop patch.  It also has at
least one other fix for a reload problem.  It it does work, this might
be a more acceptable change to incorporate into the 2.95 branch since
it only affects the vax.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

2000-12-21  John David Anglin  <dave@hiauly1.hia.nrc.ca>

	* vax.md (call_pop, call_value_pop): Change to define_expand.
	(call_pop_internal, call, call_value): Define.
	(casesi1 + 1): Make operands contiguous.

--- vax.md.orig	Tue Sep 12 10:58:47 2000
+++ vax.md	Wed Dec 20 13:33:13 2000
@@ -1818,70 +1818,74 @@
   ""
   "decl %0\;jgequ %l1")
 \f
-;; Note that operand 1 is total size of args, in bytes,
-;; and what the call insn wants is the number of words.
-;; It is used in the call instruction as a byte, but in the addl2 as
-;; a word.  Since the only time we actually use it in the call instruction
-;; is when it is a constant, SImode (for addl2) is the proper mode.
-(define_insn "call_pop"
+;; Call instructions.
+
+;; Call procedure returning no value.
+;; Operand 2 is not used on the vax.
+
+(define_expand "call_pop"
   [(call (match_operand:QI 0 "memory_operand" "m")
 	 (match_operand:SI 1 "const_int_operand" "n"))
    (set (reg:SI 14) (plus:SI (reg:SI 14)
 			     (match_operand:SI 3 "immediate_operand" "i")))]
   ""
-  "*
-  if (INTVAL (operands[1]) > 255 * 4)
-    /* Vax `calls' really uses only one byte of #args, so pop explicitly.  */
-    return \"calls $0,%0\;addl2 %1,sp\";
-  operands[1] = GEN_INT ((INTVAL (operands[1]) + 3)/ 4);
-  return \"calls %1,%0\";
-")
+  "
+{
+  emit_insn (gen_call_pop_internal (operands[0], operands[1]));
+  DONE;
+}")
+
+;; Call procedure returning a value in operand 0.
+;; Operand 3 is not used on the vax.
 
-(define_insn "call_value_pop"
+(define_expand "call_value_pop"
   [(set (match_operand 0 "" "=g")
 	(call (match_operand:QI 1 "memory_operand" "m")
 	      (match_operand:SI 2 "const_int_operand" "n")))
    (set (reg:SI 14) (plus:SI (reg:SI 14)
 			     (match_operand:SI 4 "immediate_operand" "i")))]
   ""
-  "*
-  if (INTVAL (operands[2]) > 255 * 4)
-    /* Vax `calls' really uses only one byte of #args, so pop explicitly.  */
-    return \"calls $0,%1\;addl2 %2,sp\";
-  operands[2] = GEN_INT ((INTVAL (operands[2]) + 3)/ 4);
-  return \"calls %2,%1\";
-")
+  "
+{
+  emit_insn (gen_call_pop_internal (operands[1], operands[2]));
+  DONE;
+}")
 
-;; Define another set of these for the case of functions with no
-;; operands.  In that case, combine may simplify the adjustment of sp.
-(define_insn ""
+;; Call procedure with no arguments.
+
+(define_insn "call"
   [(call (match_operand:QI 0 "memory_operand" "m")
-	 (match_operand:SI 1 "const_int_operand" "n"))
-   (set (reg:SI 14) (reg:SI 14))]
+	 (const_int 0))]
   ""
-  "*
-  if (INTVAL (operands[1]) > 255 * 4)
-    /* Vax `calls' really uses only one byte of #args, so pop explicitly.  */
-    return \"calls $0,%0\;addl2 %1,sp\";
-  operands[1] = GEN_INT ((INTVAL (operands[1]) + 3)/ 4);
-  return \"calls %1,%0\";
-")
+  "calls $0,%0")
 
-(define_insn ""
+;; Call procedure returning a value in operand 0 with no arguments.
+
+(define_insn "call_value"
   [(set (match_operand 0 "" "=g")
 	(call (match_operand:QI 1 "memory_operand" "m")
-	      (match_operand:SI 2 "const_int_operand" "n")))
-   (set (reg:SI 14) (reg:SI 14))]
+	      (const_int 0)))]
+  ""
+  "calls $0,%1")
+
+;; Note that operand 1 is total size of args, in bytes,
+;; and what the call insn wants is the number of words.
+;; It is used in the call instruction as a byte, but in the addl2 as
+;; a word.  Since the only time we actually use it in the call instruction
+;; is when it is a constant, SImode (for addl2) is the proper mode.
+(define_insn "call_pop_internal"
+  [(call (match_operand:QI 0 "memory_operand" "m")
+	 (match_operand:SI 1 "const_int_operand" "n"))]
   ""
   "*
-  if (INTVAL (operands[2]) > 255 * 4)
+  if (INTVAL (operands[1]) > 255 * 4)
     /* Vax `calls' really uses only one byte of #args, so pop explicitly.  */
-    return \"calls $0,%1\;addl2 %2,sp\";
-  operands[2] = GEN_INT ((INTVAL (operands[2]) + 3)/ 4);
-  return \"calls %2,%1\";
+    return \"calls $0,%0\;addl2 %1,sp\";
+  operands[1] = GEN_INT ((INTVAL (operands[1]) + 3)/ 4);
+  return \"calls %1,%0\";
 ")
 
-;; Call subroutine returning any type.
+;; Call procedure returning any type.
 
 (define_expand "untyped_call"
   [(parallel [(call (match_operand 0 "" "")
@@ -1986,7 +1990,7 @@
 					  (mult:SI (minus:SI (match_dup 0)
 							     (const_int 0))
 						   (const_int 2)))))
-			       (label_ref:SI (match_operand 3 "" "")))
+			       (label_ref:SI (match_operand 2 "" "")))
 		      (pc)))]
   ""
   "casel %0,$0,%1")

Re: pa reload problem

[John David Anglin]

> (insn 1067 1063 2002 (set (reg/f:SI 403)
>         (mem/u:SI (lo_sum:SI (reg/f:SI 611)
>                 (unspec:SI[ 
>                         (symbol_ref:SI ("target_flags"))
>                     ]  0)) 0)) 69 {*pa.md:2099} (nil)
>     (expr_list:REG_EQUIV (mem/u:SI (lo_sum:SI (reg/f:SI 611)
>                 (unspec:SI[ 
>                         (symbol_ref:SI ("target_flags"))
>                     ]  0)) 0)
>         (expr_list:REG_DEAD (reg/f:SI 611)
>             (nil))))

The REG_EQUIV note gets added in local-alloc.c here:

      /* If this register is known to be equal to a constant, record that
         it is always equivalent to the constant.  */
     if (note && ! rtx_varies_p (XEXP (note, 0)))
       PUT_MODE (note, (enum machine_mode) REG_EQUIV);

The problem appears to be that the "constant" part of the lo_sum (the
symbol_ref) should be the first operand:

    case LO_SUM:
      /* The operand 0 of a LO_SUM is considered constant
         (in fact is it related specifically to operand 1).  */
      return rtx_varies_p (XEXP (x, 1));

This problem appears to prevalent in a number of places in pa.md and pa.c.
It looks like the argument order for lo_sums in hte pa port needs to be
switched.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: pa reload problem

[Jeffrey A Law]

  In message < 200101020037.TAA26820@hiauly1.hia.nrc.ca >you write:
  > > (insn 1067 1063 2002 (set (reg/f:SI 403)
  > >         (mem/u:SI (lo_sum:SI (reg/f:SI 611)
  > >                 (unspec:SI[ 
  > >                         (symbol_ref:SI ("target_flags"))
  > >                     ]  0)) 0)) 69 {*pa.md:2099} (nil)
  > >     (expr_list:REG_EQUIV (mem/u:SI (lo_sum:SI (reg/f:SI 611)
  > >                 (unspec:SI[ 
  > >                         (symbol_ref:SI ("target_flags"))
  > >                     ]  0)) 0)
  > >         (expr_list:REG_DEAD (reg/f:SI 611)
  > >             (nil))))
  > 
  > The REG_EQUIV note gets added in local-alloc.c here:
  > 
  >       /* If this register is known to be equal to a constant, record that
  >          it is always equivalent to the constant.  */
  >      if (note && ! rtx_varies_p (XEXP (note, 0)))
  >        PUT_MODE (note, (enum machine_mode) REG_EQUIV);
  > 
  > The problem appears to be that the "constant" part of the lo_sum (the
  > symbol_ref) should be the first operand:
  > 
  >     case LO_SUM:
  >       /* The operand 0 of a LO_SUM is considered constant
  >          (in fact is it related specifically to operand 1).  */
  >       return rtx_varies_p (XEXP (x, 1));
  > 
  > This problem appears to prevalent in a number of places in pa.md and pa.c.
  > It looks like the argument order for lo_sums in hte pa port needs to be
  > switched.
Huh?  It follows the same convention as every other port that uses
HI and LO_SUM.

op0 is a register, but it is known to be a constant (the high part of
the expression found in op1).

jeff

Re: pa reload problem

[John David Anglin]

>   In message < 200101020037.TAA26820@hiauly1.hia.nrc.ca >you write:
>   > > (insn 1067 1063 2002 (set (reg/f:SI 403)
>   > >         (mem/u:SI (lo_sum:SI (reg/f:SI 611)
>   > >                 (unspec:SI[ 
>   > >                         (symbol_ref:SI ("target_flags"))
>   > >                     ]  0)) 0)) 69 {*pa.md:2099} (nil)
>   > >     (expr_list:REG_EQUIV (mem/u:SI (lo_sum:SI (reg/f:SI 611)
>   > >                 (unspec:SI[ 
>   > >                         (symbol_ref:SI ("target_flags"))
>   > >                     ]  0)) 0)
>   > >         (expr_list:REG_DEAD (reg/f:SI 611)
>   > >             (nil))))
>   > 
>   > The REG_EQUIV note gets added in local-alloc.c here:
>   > 
>   >       /* If this register is known to be equal to a constant, record that
>   >          it is always equivalent to the constant.  */
>   >      if (note && ! rtx_varies_p (XEXP (note, 0)))
>   >        PUT_MODE (note, (enum machine_mode) REG_EQUIV);
>   > 
>   > The problem appears to be that the "constant" part of the lo_sum (the
>   > symbol_ref) should be the first operand:
>   > 
>   >     case LO_SUM:
>   >       /* The operand 0 of a LO_SUM is considered constant
>   >          (in fact is it related specifically to operand 1).  */
>   >       return rtx_varies_p (XEXP (x, 1));
>   > 
>   > This problem appears to prevalent in a number of places in pa.md and pa.c.
>   > It looks like the argument order for lo_sums in hte pa port needs to be
>   > switched.
> Huh?  It follows the same convention as every other port that uses
> HI and LO_SUM.
> 
> op0 is a register, but it is known to be a constant (the high part of
> the expression found in op1).

The problem is that it is "constant" but not invariant.  I was wrong
about the reversal, being confused by the fact that on the pa op1
is either a constant or symbol reference.  Thus, it didn't make much
sense to test op1 of a lo_sum in rtx_varies_p.  I had looked at the
documention but this convention is only documented in the code.

In this particular situation, the op0 register dies and the hard register
that reload asigns to it is reused.  However, reload doesn't check for this
and still goes ahead and substitutes the mem to eliminate the "equivalent"
pseudo.  My impression is that it would be easier to not create the REG_EQUIV
notes in local-alloc after the op0 register dies than fix the problem in
reload.  It appears that reload may substitute a mem for a psuedo whenever it
finds such a note without much testing.

If the REG_EQUIV notes aren't created, it is possible that it may not be
necessary to merge the special pic load insns into the insn which handles
move_operands because the op0 register will always die in the lo_sum insn
and the mem will not be substituted by reload.

I was working on a patch to local-alloc but after updating to the current
cvs today, I find the pa port doesn't build even without -fPIC:

./xgcc -B./ -B/usr/local/hppa1.1-hp-hpux10.20/bin/ -isystem /usr/local/hppa1.1-hp-hpux10.20/include -O2   -DIN_GCC    -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -isystem ./include  -fPIC -g1  -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED  -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/config -I../../gcc/../include -DUSE_COLLECT2 -DL_fixunstfdi -c ../../gcc/libgcc2.c -o libgcc/./_fixunstfdi.o
../../gcc/libgcc2.c: In function `__fixunstfdi':
../../gcc/libgcc2.c:865: Internal compiler error in mark_referenced_resources, at resource.c:229

This occurs in stage 2 when built with -O3.  For some reason, virtual-stack-vars
doesn't get a hard register during reload.  This is a new problem introduced
in the last few days.

I have a couple of pic related patches, but the reload issue and the above
problem need to be resolved before they can be fully tested.  I did have
a complete pic build of gcc when I patched rtx_varies_p to check op0
and op1 of the lo_sum (ie, to ensure that its argument is invariant and
not just constant).  However, I decided this is wrong and that some
additional modifications need to be made to local-alloc to test for
this situation.  I think there needs to be a scan from the init_insn.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: pa reload problem

[Jeffrey A Law]

  In message < 200101040608.BAA05571@hiauly1.hia.nrc.ca >you write:
  > In this particular situation, the op0 register dies and the hard register
  > that reload asigns to it is reused.  However, reload doesn't check for this
  > and still goes ahead and substitutes the mem to eliminate the "equivalent"
  > pseudo. 
And that is the bug.  Blind replacement by reload is a constant source of
problems.

Now as I've mentioned before I've got changes to fix these kinds of problems.
But I haven't had time to finish testing them.

  > My impression is that it would be easier to not create the REG_EQUIV
  > notes in local-alloc after the op0 register dies than fix the problem in
  > reload.  It appears that reload may substitute a mem for a psuedo whenever 
  > it finds such a note without much testing.
That sound like you're barking up the wrong tree.  The REG_EQUIV note is
perfectly valid.  It's reload's fault for blindly substituting it in for
a pseudo that doesn't get a hard register.

  > ./xgcc -B./ -B/usr/local/hppa1.1-hp-hpux10.20/bin/ -isystem /usr/local/hppa
  > 1.1-hp-hpux10.20/include -O2   -DIN_GCC    -W -Wall -Wwrite-strings -Wstric
  > t-prototypes -Wmissing-prototypes -isystem ./include  -fPIC -g1  -DIN_LIBGC
  > C2 -D__GCC_FLOAT_NOT_NEEDED  -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/
  > config -I../../gcc/../include -DUSE_COLLECT2 -DL_fixunstfdi -c ../../gcc/li
  > bgcc2.c -o libgcc/./_fixunstfdi.o
  > ../../gcc/libgcc2.c: In function `__fixunstfdi':
  > ../../gcc/libgcc2.c:865: Internal compiler error in mark_referenced_resourc
  > es, at resource.c:229
  > 
  > This occurs in stage 2 when built with -O3.  For some reason, virtual-stack
  > -vars
  > doesn't get a hard register during reload.  This is a new problem introduce
  > d
  > in the last few days.
Yes.  It's due to some additional checking Alex put into reorg recently.

jeff

Re: pa reload problem

[John David Anglin]

> Now as I've mentioned before I've got changes to fix these kinds of problems.
> But I haven't had time to finish testing them.

If you send them, I will try to help with testing.  Do these also deal
with the problem that reload may substitute a mem valid in one insn into
another in which it is not valid?

>   > My impression is that it would be easier to not create the REG_EQUIV
>   > notes in local-alloc after the op0 register dies than fix the problem in
>   > reload.  It appears that reload may substitute a mem for a psuedo whenever 
>   > it finds such a note without much testing.
> That sound like you're barking up the wrong tree.  The REG_EQUIV note is
> perfectly valid.  It's reload's fault for blindly substituting it in for
> a pseudo that doesn't get a hard register.

The initial one is perfectly valid but probably unnecessary because the
reg used in it dies in the same insn.  It's the latter two which I really
question and cause the problem in reload.  They might not be created if
we lose the initial equivalence or if some checking were added at the
point previously noted in local-alloc.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: pa reload problem

[John David Anglin]

>   > ./xgcc -B./ -B/usr/local/hppa1.1-hp-hpux10.20/bin/ -isystem /usr/local/hppa
>   > 1.1-hp-hpux10.20/include -O2   -DIN_GCC    -W -Wall -Wwrite-strings -Wstric
>   > t-prototypes -Wmissing-prototypes -isystem ./include  -fPIC -g1  -DIN_LIBGC
>   > C2 -D__GCC_FLOAT_NOT_NEEDED  -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/
>   > config -I../../gcc/../include -DUSE_COLLECT2 -DL_fixunstfdi -c ../../gcc/li
>   > bgcc2.c -o libgcc/./_fixunstfdi.o
>   > ../../gcc/libgcc2.c: In function `__fixunstfdi':
>   > ../../gcc/libgcc2.c:865: Internal compiler error in mark_referenced_resourc
>   > es, at resource.c:229
>   > 
>   > This occurs in stage 2 when built with -O3.  For some reason, virtual-stack
>   > -vars
>   > doesn't get a hard register during reload.  This is a new problem introduce
>   > d
>   > in the last few days.
> Yes.  It's due to some additional checking Alex put into reorg recently.

Is Alex working on resolving this?

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: pa reload problem

[Alexandre Oliva]

On Jan  4, 2001, "John David Anglin" <dave@hiauly1.hia.nrc.ca> wrote:

>> > This occurs in stage 2 when built with -O3.  For some reason, virtual-stack
>> > -vars
>> > doesn't get a hard register during reload.  This is a new problem introduce
>> > d
>> > in the last few days.

>> Yes.  It's due to some additional checking Alex put into reorg recently.

> Is Alex working on resolving this?

Not actively.  It's on my to-do list, but I don't know when I'll be
able to get to it.

Please note that the check I've introduced just detects what has been
in error for a long time.  It's not responsible for the failure, that
I'm yet to track down.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: pa reload problem

[John David Anglin]

> On Jan  4, 2001, "John David Anglin" <dave@hiauly1.hia.nrc.ca> wrote:
> 
> >> > This occurs in stage 2 when built with -O3.  For some reason, virtual-stack
> >> > -vars
> >> > doesn't get a hard register during reload.  This is a new problem introduce

As far as I can see, virtual-stack-vars is only left in expr_lists of
of call_insns.  Here is a sample from the greg rtl:

(call_insn/u 51 45 53 (parallel[ 
            (set (reg:SI 28 %r28)
                (call (mem:SI (symbol_ref:SI ("@_U_Qflt")) 0)
                    (const_int 16 [0x10])))
            (clobber (reg:SI 2 %r2))
            (use (const_int 0 [0x0]))
        ] ) 272 {call_value_internal_symref} (insn_list 31 (insn_list 33 (insn_list 35 (insn_list 37 (insn_list 39 (insn_list 41 (insn_list 43 (insn_list 45 (insn_list:REG_DEP_ANTI 6 (insn_list:REG_DEP_ANTI 8 (insn_list:REG_DEP_ANTI 10 (insn_list:REG_DEP_ANTI 12 (insn_list 48 (insn_list 50 (nil)))))))))))))))
    (expr_list:REG_EH_REGION (const_int -1 [0xffffffff])
        (nil))
    (expr_list (use (reg:SI 4 %r4))
        (expr_list (use (reg:SI 19 %r19))
            (expr_list (use (reg:SI 25 %r25))
                (expr_list (use (reg:SI 26 %r26))
                    (expr_list (use (mem/f:TF (plus:SI (reg/f:SI 90 virtual-stack-vars)
                                    (const_int 16 [0x10])) 28))
                        (expr_list (use (mem/f:TF (reg/f:SI 90 virtual-stack-vars) 28))
                            (nil))))))))

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: pa reload problem

[Alexandre Oliva]

On Jan  4, 2001, "John David Anglin" <dave@hiauly1.hia.nrc.ca> wrote:

> As far as I can see, virtual-stack-vars is only left in expr_lists of
> of call_insns.

Yep.  This matches my experience too.  It turns out that I posted a
patch on Dec 30 that would cause them to be properly instantiated, but
it wasn't reviewed yet.  And, if I install another patch that I had
posted about 10 minutes later, that was approved but that I put on
hold, you'd probably start getting other pseudos listed in call_insn
expr_lists, that would give you similar problems because they wouldn't
be handled by reload.

Oh, joy! :-(

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: pa reload problem

[John David Anglin]

> On Jan  4, 2001, "John David Anglin" <dave@hiauly1.hia.nrc.ca> wrote:
> 
> > As far as I can see, virtual-stack-vars is only left in expr_lists of
> > of call_insns.
> 
> Yep.  This matches my experience too.  It turns out that I posted a
> patch on Dec 30 that would cause them to be properly instantiated, but
> it wasn't reviewed yet.  And, if I install another patch that I had
> posted about 10 minutes later, that was approved but that I put on
> hold, you'd probably start getting other pseudos listed in call_insn
> expr_lists, that would give you similar problems because they wouldn't
> be handled by reload.

Should this be backed out until a solution is found?  It prevents the
building the compiler under hpux.

2000-12-29  Alexandre Oliva  <aoliva@redhat.com>

        * calls.c (emit_library_call_value_1): Add to call_fusage the
        stack slot assigned to argument passed by reference.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: RFC: Jump to const_int

[John David Anglin]

> I found the following testcase fails (991213-3.c) with the above abort:
> 
> int jump () { goto * (int (*) ()) 0xbabebec0; }

One further thought.  The test looks bogus to me because the address
clearly can't be in the current function.  Thus, the behavior of such
a jump is totally unpredictable.

Gcc allows as an extension goto's to any void * expression.  Thus, the
above is accepted but it will clearly cause problems when edges are
to be calculated.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: RFC: Jump to const_int

[Fergus Henderson]

On 12-Jan-2001, John David Anglin <dave@hiauly1.hia.nrc.ca> wrote:
> > I found the following testcase fails (991213-3.c) with the above abort:
> > 
> > int jump () { goto * (int (*) ()) 0xbabebec0; }
> 
> One further thought.  The test looks bogus to me because the address
> clearly can't be in the current function.  Thus, the behavior of such
> a jump is totally unpredictable.
>
> Gcc allows as an extension goto's to any void * expression.  Thus, the
> above is accepted but it will clearly cause problems when edges are
> to be calculated.

The *runtime* behaviour of such a jump is unpredictable.
It should be a runtime error, and a compile-time warning might be nice,
but it should not be a compile-time error and nor should the compiler
get an internal compiler error.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
                                    |  of excellence is a lethal habit"
WWW: < http://www.cs.mu.oz.au/~fjh >  |     -- the last words of T. S. Garp.

Re: GCC 3.0 Status Report

[John David Anglin]

Mark,

I would like to draw your attention to these two g++ patches
which I would like considered for both branch and main:

< http://gcc.gnu.org/ml/gcc-patches/2001-04/msg00762.html >
< http://gcc.gnu.org/ml/gcc-patches/2001-04/msg00817.html >

The first one potentially affects all targets.  The second
only affects targets that define PCC_STATIC_STRUCT_RETURN.
However, it is crucial to g++ being usable.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: GCC 3.0 Status Report

[Mark Mitchell]

>>>>> "John" == John David Anglin <dave@hiauly1.hia.nrc.ca> writes:

First, note that Vax Ultrix is not a primary platform the release, so
these patches are not a high priority for me.

    John> http://gcc.gnu.org/ml/gcc-patches/2001-04/msg00762.html

I would prefer a patch that simply did something like:

  minnode = build_int_2 (TREE_INT_CST_LOW (minnode),
                         TREE_INT_CST_HIGH (minnode));
  if (unsignedp)
    TREE_TYPE (minnode) = unsigned_type_node;

I think the hack where you adjust things according to the signedness
at the end is confusing.

    John> http://gcc.gnu.org/ml/gcc-patches/2001-04/msg00817.html

Certainly the bit about setting old_ac is correct.  I'll install that
part of the change.  

I think that probably the other part is correct, but can you explain
it in more detail?  Not what the problem is (I get that), but why your
fix is the correct approach?

I'm not sure that it's possible to get correct C++ semantics with the
PCC calling convention; you might end up with too many copy
constructors, for example.

ChangeLogs shouldn't have justifications in them.  They should go in
the code instead.

Thanks,

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC 3.0 Status Report

[John David Anglin]

> I think that probably the other part is correct, but can you explain
> it in more detail?  Not what the problem is (I get that), but why your
> fix is the correct approach?

I am not entirely certain the approach is correct as my knowledge of
C++ and g++ is limited.  Can you see another way to copy the result
without using build_aggr_init?

My approach was based on debugging the existing code.  The call_expr
is converted by ocp_convert to a tree expression containing another
aggr_init_expr in expand_default_init.  Here is the code there:

      if (flags & DIRECT_BIND)
	/* Do nothing.  We hit this in two cases:  Reference initialization,
	   where we aren't initializing a real variable, so we don't want
	   to run a new constructor; and catching an exception, where we
	   have already built up the constructor call so we could wrap it
	   in an exception region.  */;
      else if (TREE_CODE (init) == CONSTRUCTOR)
	/* A brace-enclosed initializer has whatever type is
	   required.  There's no need to convert it.  */
	;
      else
        init = ocp_convert (type, init, CONV_IMPLICIT|CONV_FORCE_TEMP, flags);

It looked to me like the call was already built, so adding DIRECT_BIND
to the flags was the right thing to do to prevent the conversion.  However,
maybe the code here should be checking for a CALL_EXPR.  There is this
comment for build_aggr_init:

   If INIT resolves to a CALL_EXPR which happens to return
   something of the type we are looking for, then we know
   that we can safely use that call to perform the
   initialization.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: GCC 3.0 Status Report

[John David Anglin]

> >>>>> "John" == John David Anglin <dave@hiauly1.hia.nrc.ca> writes:
> 
> First, note that Vax Ultrix is not a primary platform the release, so
> these patches are not a high priority for me.
> 
>     John> http://gcc.gnu.org/ml/gcc-patches/2001-04/msg00762.html

I understand your priorities but as I noted this problem affects all
ports.  Hey, next time I will provide an analysis on the i386!  What
I am saying is that you have to be careful in ignoring problems on
low priority targets because they may well affect the high priority
ones as well.

> I would prefer a patch that simply did something like:
> 
>   minnode = build_int_2 (TREE_INT_CST_LOW (minnode),
>                          TREE_INT_CST_HIGH (minnode));
>   if (unsignedp)
>     TREE_TYPE (minnode) = unsigned_type_node;
> 
> I think the hack where you adjust things according to the signedness
> at the end is confusing.

The sign adjustment at the end is a bit of a hack but it was a compromise
which allows just one pass through the values as before, and an overall
simplification of the code.

I don't believe your suggestion works directly because minnode has
has the signedness of enumtype after the loop.  The testing for signed
values could be put into the loop as in my patch.

I liked the idea of using the actual type and precision specified in
the original values for the minimum precision estimation, rather than
copying the min and max nodes after the loop and resetting their type
and precision.  Doing the precision calculation in the loop is probably
less complicated than the comparisons needed to determine the min and
max values in the list.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: GCC 3.0 Status Report

[Mark Mitchell]

>>>>> "John" == John David Anglin <dave@hiauly1.hia.nrc.ca> writes:

  >     John> http://gcc.gnu.org/ml/gcc-patches/2001-04/msg00762.html

  I understand your priorities but as I noted this problem affects all
  ports.  

I didn't see that in that message.

But, you are right that it probably could affect most ports.  Some
ports (where pretty much everything is word-sized) are probably OK, by
luck.

Anyhow, I think I have a cleaner patch.  Would you mind mailing me
(privately) the preprocessed source, cc1plus command-line options, and
the target-triplet you're using, so I can make sure that I fixed the
problem?

Thanks!

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: C++ Issue on GCC 3.0 branch

[John David Anglin]

> 2001-04-21  John David Anglin  <dave@hiauly1.hia.nrc.ca>
> 
> 	* builtins.c (expand_builtin_setjmp_setup): Set nonlocal flag in label.

Close but no cigar.  This one actually bootstraps with no regressions under
i686 linux.  However, I think it only addresses the symptom of the problem.
There must be a label uses problem somewhere.  In any event, the testcase
for duplicate symbols will compile with the patch installed.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

2001-04-21  John David Anglin  <dave@hiauly1.hia.nrc.ca>

	* builtins.c (expand_builtin_setjmp): Mark next_lab as used.

--- builtins.c.orig	Wed Feb  7 05:24:22 2001
+++ builtins.c	Sat Apr 21 20:18:59 2001
@@ -617,6 +617,7 @@
   buf_addr = expand_expr (TREE_VALUE (arglist), NULL_RTX, VOIDmode, 0);
 
   next_lab = gen_label_rtx ();
+  LABEL_PRESERVE_P (next_lab) = 1;
   cont_lab = gen_label_rtx ();
 
   expand_builtin_setjmp_setup (buf_addr, next_lab);

Re: C++ Issue on GCC 3.0 branch

[Bernd Schmidt]

On Sat, 21 Apr 2001, John David Anglin wrote:

> > 2001-04-21  John David Anglin  <dave@hiauly1.hia.nrc.ca>
> >
> > 	* builtins.c (expand_builtin_setjmp_setup): Set nonlocal flag in label.
>
> Close but no cigar.  This one actually bootstraps with no regressions under
> i686 linux.  However, I think it only addresses the symptom of the problem.
> There must be a label uses problem somewhere.  In any event, the testcase
> for duplicate symbols will compile with the patch installed.

You might want to look at the patches I installed on the 2.95 branch after
2.95.3.  This sounds like it's exactly the same problem.


Bernd

Re: C++ Issue on GCC 3.0 branch

[law]

  In message <Pine.LNX.4.33.0104231017340.7552-100000@host140.cambridge.redhat.
com>you write:
  > > There must be a label uses problem somewhere.  In any event, the testcase
  > > for duplicate symbols will compile with the patch installed.
  > 
  > You might want to look at the patches I installed on the 2.95 branch after
  > 2.95.3.  This sounds like it's exactly the same problem.
Are you referring to this patch?

2001-03-28  Bernd Schmidt  <bernds@redhat.com>

        * flow.c (propagate_block): When trying to delete a case vector, cope
        if its label has LABEL_PRESERVE_P set.
        * jump.c (jump_optimize_1): Move call to delete_barrier_successors to
        a point where JUMP_LABELS and LABEL_NUSES are set up properly.
        (delete_barrier_successors): If deleting a table jump, delete the case
        vector as well.
        * varasm.c (force_const_mem): If we have a label, set LABEL_PRESERVE_P
        so it won't get deleted.


Just want to be sure before I install it locally and fire off my tests.

jeff

Re: C++ Issue on GCC 3.0 branch

[Bernd Schmidt]

On Mon, 23 Apr 2001 law@redhat.com wrote:

>   In message <Pine.LNX.4.33.0104231017340.7552-100000@host140.cambridge.redhat.
> com>you write:
>   > > There must be a label uses problem somewhere.  In any event, the testcase
>   > > for duplicate symbols will compile with the patch installed.
>   >
>   > You might want to look at the patches I installed on the 2.95 branch after
>   > 2.95.3.  This sounds like it's exactly the same problem.
> Are you referring to this patch?
>
> 2001-03-28  Bernd Schmidt  <bernds@redhat.com>
>
>         * flow.c (propagate_block): When trying to delete a case vector, cope
>         if its label has LABEL_PRESERVE_P set.
>         * jump.c (jump_optimize_1): Move call to delete_barrier_successors to
>         a point where JUMP_LABELS and LABEL_NUSES are set up properly.
>         (delete_barrier_successors): If deleting a table jump, delete the case
>         vector as well.
>         * varasm.c (force_const_mem): If we have a label, set LABEL_PRESERVE_P
>         so it won't get deleted.

Yes.


Bernd

Re: C++ Issue on GCC 3.0 branch

[Bernd Schmidt]

On Mon, 23 Apr 2001 law@redhat.com wrote:

> 2001-03-28  Bernd Schmidt  <bernds@redhat.com>
>
>         * flow.c (propagate_block): When trying to delete a case vector, cope
>         if its label has LABEL_PRESERVE_P set.
>         * jump.c (jump_optimize_1): Move call to delete_barrier_successors to
>         a point where JUMP_LABELS and LABEL_NUSES are set up properly.
>         (delete_barrier_successors): If deleting a table jump, delete the case
>         vector as well.
>         * varasm.c (force_const_mem): If we have a label, set LABEL_PRESERVE_P
>         so it won't get deleted.

Just remembered; this also needs the followup

2001-03-30  Bernd Schmidt  <bernds@redhat.com>

        * jump.c (delete_barrier_successors): Fix error in last change.


Bernd

Re: C++ Issue on GCC 3.0 branch

[law]

  In message <Pine.LNX.4.33.0104231556040.7552-100000@host140.cambridge.redhat.
com>you write:
  > Just remembered; this also needs the followup
  > 
  > 2001-03-30  Bernd Schmidt  <bernds@redhat.com>
  > 
  >         * jump.c (delete_barrier_successors): Fix error in last change.
OK.  Thanks.  I'll give the set a whirl on my PAs :-)

jeff

Re: C++ Issue on GCC 3.0 branch

[Mark Mitchell]

  2001-04-21  John David Anglin  <dave@hiauly1.hia.nrc.ca>

	  * builtins.c (expand_builtin_setjmp): Mark next_lab as used.

  --- builtins.c.orig	Wed Feb  7 05:24:22 2001
  +++ builtins.c	Sat Apr 21 20:18:59 2001
  @@ -617,6 +617,7 @@
     buf_addr = expand_expr (TREE_VALUE (arglist), NULL_RTX, VOIDmode, 0);

     next_lab = gen_label_rtx ();
  +  LABEL_PRESERVE_P (next_lab) = 1;
     cont_lab = gen_label_rtx ();

     expand_builtin_setjmp_setup (buf_addr, next_lab);

Even with this workaround patch I still get a crash using a cross
compiler, so I guess I'll have to wait for Jeff's reworking of Bernd's
patch.

Thanks,

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: C++ Issue on GCC 3.0 branch

[John David Anglin]

>   2001-04-21  John David Anglin  <dave@hiauly1.hia.nrc.ca>
> 
> 	  * builtins.c (expand_builtin_setjmp): Mark next_lab as used.
> 
>   --- builtins.c.orig	Wed Feb  7 05:24:22 2001
>   +++ builtins.c	Sat Apr 21 20:18:59 2001
>   @@ -617,6 +617,7 @@
>      buf_addr = expand_expr (TREE_VALUE (arglist), NULL_RTX, VOIDmode, 0);
> 
>      next_lab = gen_label_rtx ();
>   +  LABEL_PRESERVE_P (next_lab) = 1;
>      cont_lab = gen_label_rtx ();
> 
>      expand_builtin_setjmp_setup (buf_addr, next_lab);
> 
> Even with this workaround patch I still get a crash using a cross
> compiler, so I guess I'll have to wait for Jeff's reworking of Bernd's
> patch.

Strange.  I just tried it again with the 3.0 source from a few hours
ago with no problems.  The above patch was the only source change.

I just configured with `--with-gnu-as --target=hppa1.1-hp-hpux10.20' and
did a make.  CFLAGS were the default `-g -O2'.  My build gcc was 3.0
20010421 (prerelease).

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: C++ Issue on GCC 3.0 branch

[Mark Mitchell]

After making Dave work hard sending me lots of information, it turns
out that his original patch is exactly the right thing.

I checked in the attached, on both the mainline and the branch;
hopefully it will remove the duplicate symbols on HPUX.

Tested on i686-pc-linux-gnu, and by looking at the .s output for
Dave's testcase.

Thanks,

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

2001-04-25  Mark Mitchell  <mark@codesourcery.com>

	* optimize.c (maybe_clone_body): Copy TREE_PUBLIC before emitting
	the clone.

Index: optimize.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/cp/optimize.c,v
retrieving revision 1.51.2.13
diff -c -p -r1.51.2.13 optimize.c
*** optimize.c	2001/04/25 00:12:47	1.51.2.13
--- optimize.c	2001/04/26 00:28:07
*************** maybe_clone_body (fn)
*** 1051,1056 ****
--- 1051,1057 ----
        DECL_EXTERNAL (clone) = DECL_EXTERNAL (fn);
        DECL_INTERFACE_KNOWN (clone) = DECL_INTERFACE_KNOWN (fn);
        DECL_NOT_REALLY_EXTERN (clone) = DECL_NOT_REALLY_EXTERN (fn);
+       TREE_PUBLIC (clone) = TREE_PUBLIC (fn);
  
        /* Start processing the function.  */
        push_to_top_level ();

Re: C++ Issue on GCC 3.0 branch

[John David Anglin]

Mark,

> After making Dave work hard sending me lots of information, it turns
> out that his original patch is exactly the right thing.
> 
> I checked in the attached, on both the mainline and the branch;
> hopefully it will remove the duplicate symbols on HPUX.

While I am certain that the patch eliminates the duplicate symbols, I
am still concerned that assemble_external is being called with TREE_PUBLIC
and DECL_EXTERNAL set for the type declarations.  This causes .IMPORT
statements to be generated for the symbols under hpux.  While this appears
harmless under HPUX, I am not sure it would be under all circumstances.
It seemed to me that when there is no weak support these declarations
should not be external.  I remember there was some discussion of this
under AIX back in January.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: C++ Issue on GCC 3.0 branch

[Mark Mitchell]

>>>>> "John" == John David Anglin <dave@hiauly1.hia.nrc.ca> writes:

    John> While I am certain that the patch eliminates the duplicate
    John> symbols, I am still concerned that assemble_external is
    John> being called with TREE_PUBLIC and DECL_EXTERNAL set for the
    John> type declarations.  This causes .IMPORT statements to be

Yes, that's why I asked about this.

There's a basic problem here; both the C and C++ front-ends call
assemble_external in a way that is inconsistent with the
assemble_external documentation.

In particular, ASM_OUTPUT_EXTERNAL is documented as used when
something is 

     A C statement (sans semicolon) to output to the stdio stream
     STREAM any text necessary for declaring the name of an external
     symbol named NAME which is referenced in this compilation but not
     defined.  The value of DECL is the tree node for the declaration.

You can't know this until the end of the translation unit.  But, we
compile a function-at-a-time, so if we see:

  extern void f(); 
  void g() { f(); }
  void f() {}

we call this macro for `f'.

It's even more extreme in C++ because we don't make up our minds about
the linkages of some functions until very late in the game.  (See the
tricks played with DECL_NOT_REALLY_EXTERN.)  That's all really pretty
grotesque, but it's not easy to fix, and it's been that way for a long
time, so I'm guessing most systems deal with it OK.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: C++ Issue on GCC 3.0 branch

[law]

  In message < 20010425173144F.mitchell@codesourcery.com >you write:
  > 
  > After making Dave work hard sending me lots of information, it turns
  > out that his original patch is exactly the right thing.
  > 
  > I checked in the attached, on both the mainline and the branch;
  > hopefully it will remove the duplicate symbols on HPUX.
  > 
  > Tested on i686-pc-linux-gnu, and by looking at the .s output for
  > Dave's testcase.
Noted.  I'm testing hpux PA32 with it now.

jeff

Re: C++ Issue on GCC 3.0 branch

[John David Anglin]

> 0x7adfdbd4 <_ZNSt8ios_base4InitC1Ev+124>:       stw r26,-24(sr0,r3)
> 0x7adfdbd8 <_ZNSt8ios_base4InitC1Ev+128>:
>     bl 0x7adfdac8 <__get_eh_context>,rp
> 0x7adfdbdc <_ZNSt8ios_base4InitC1Ev+132>:       nop
> 0x7adfdbe0 <_ZNSt8ios_base4InitC1Ev+136>:       ldw 9c(sr0,r3),r19
> 0x7adfdbe4 <_ZNSt8ios_base4InitC1Ev+140>:       copy ret0,r20
> 0x7adfdbe8 <_ZNSt8ios_base4InitC1Ev+144>:       stws r20,-10(sr0,sp)
> 0x7adfdbec <_ZNSt8ios_base4InitC1Ev+148>:       fldws -10(sr0,sp),fr22
> 0x7adfdbf0 <_ZNSt8ios_base4InitC1Ev+152>:       fstws fr22,-10(sr0,sp)
> 0x7adfdbf4 <_ZNSt8ios_base4InitC1Ev+156>:       ldws -10(sr0,sp),r1
> 0x7adfdbf8 <_ZNSt8ios_base4InitC1Ev+160>:       stw r1,a4(sr0,r3)
> 0x7adfdbfc <_ZNSt8ios_base4InitC1Ev+164>:       stw r19,9c(sr0,r3)

The problem was not my patch.  There is a real problem with pic C++ code.
The problem is that the "first" save for register r19 comes after the first
function call.  The initial save of r19 was to meet ABI requirements.  The
save at 0x7adfdbfc is the real save that was supposed to be used for
restoration of r19 after function calls.

You can see the problem in the rtl:

;; Function std::ios_base::Init::Init()

(note 1 0 6 ("../../../../libstdc++-v3/src/ios.cc") 137 0)

(insn 6 1 54 (set (reg/v/u/f:SI 94)
        (reg:SI 26 %r26)) -1 (nil)
    (expr_list:REG_EQUIV (mem/u/f:SI (plus:SI (reg/f:SI 89 virtual-incoming-args)
                (const_int -4 [0xfffffffc])) 0)
        (nil)))

(insn 54 6 43 (use:SI (reg:SI 105)) -1 (nil)
    (expr_list:REG_EH_CONTEXT (reg:SI 105)
        (nil)))

(insn 43 54 7 (set (reg:SI 103)
        (reg:SI 19 %r19)) -1 (nil)
    (nil))

(note 7 43 15 NOTE_INSN_FUNCTION_BEG 0)

(note 15 7 17 ("../../../../libstdc++-v3/src/ios.cc") 138 0)

As can be seen, the eh context stuff has been pushed to the beginning of
the function.   We need insn 43 to be at the beginning before the eh
context stuff.  We try to put the save at the start in hppa_init_pic_save:

void hppa_init_pic_save ()
{
  rtx insn, picreg;

  picreg = gen_rtx_REG (word_mode, PIC_OFFSET_TABLE_REGNUM);
  PIC_OFFSET_TABLE_SAVE_RTX = gen_reg_rtx (Pmode);
  insn = gen_rtx_SET (VOIDmode, PIC_OFFSET_TABLE_SAVE_RTX, picreg);

  /* Emit the insn at the beginning of the function after the prologue.  */
  push_topmost_sequence ();
  emit_insn_after (insn, last_parm_insn ? last_parm_insn : get_insns ());
  pop_topmost_sequence ();
}

This is called when the first call insn is encountered.  Any thoughts
on how to fix this?

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: C++ Issue on GCC 3.0 branch

[law]

  In message < 200104232221.SAA21738@hiauly1.hia.nrc.ca >you write:
  > As can be seen, the eh context stuff has been pushed to the beginning of
  > the function.   We need insn 43 to be at the beginning before the eh
  > context stuff.  We try to put the save at the start in hppa_init_pic_save:
Interesting.  I'm not sure if I'll have time to peek at this tonight/tomorrow.
So, if you've got time, you'd want to investigate precisely how the code to
call get_eh_context gets inserted before the code to save the PIC register.

jeff

Re: C++ Issue on GCC 3.0 branch

[John David Anglin]

>   In message < 200104232221.SAA21738@hiauly1.hia.nrc.ca >you write:
>   > As can be seen, the eh context stuff has been pushed to the beginning of
>   > the function.   We need insn 43 to be at the beginning before the eh
>   > context stuff.  We try to put the save at the start in hppa_init_pic_save:
> Interesting.  I'm not sure if I'll have time to peek at this tonight/tomorrow.
> So, if you've got time, you'd want to investigate precisely how the code to
> call get_eh_context gets inserted before the code to save the PIC register.

Yes!  I think that I have the fix.  See below.

The call to get_eh_context gets inserted before the code to save the PIC
register with the same technique that we use to save the PIC register:

rtx
get_eh_context ()
{
  if (current_function_ehc == 0)
    {
       rtx insn;

       current_function_ehc = gen_reg_rtx (Pmode);

       insn = gen_rtx_USE (GET_MODE (current_function_ehc),
			   current_function_ehc);
       insn = emit_insn_before (insn, get_first_nonparm_insn ());

       REG_NOTES (insn)
	 = gen_rtx_EXPR_LIST (REG_EH_CONTEXT, current_function_ehc,
			      REG_NOTES (insn));
    }
  return current_function_ehc;
}

Here are my latest test results for libstdc++-v3:

(chmod + ./mkcheck; \
  srcdir=`cd ../../../libstdc++-v3; pwd`; builddir=`pwd`; \
  test -d testsuite || (mkdir testsuite; chmod u+w testsuite); \
  cd testsuite; ${builddir}/mkcheck 0 ${builddir} ${srcdir})
running mkcheck
/xxx/gnu/gcc-3.0/objdir/hppa1.1-hp-hpux10.20/libstdc++-v3/mkcheck: testing the build directory
making utility ./printnow.exe

Detailed test results in ../20010424-mkcheck.txt
+: pass, -b: build failure, -r: run failure, x: disabled
------------------------------------------------------------------------
static	shared	test
------------------------------------------------------------------------
+	+	17_intro/header_ciso646.cc
+	+	17_intro/header_cstdio.cc
+	+	17_intro/header_cstdlib.cc
+	+	17_intro/header_cstring.cc
+	+	17_intro/header_ctime.cc
+	+	17_intro/header_cwchar.cc
+	+	17_intro/header_cwctype.cc
+	+	17_intro/header_fstream.cc
+	+	17_intro/header_iomanip.cc
+	+	17_intro/header_ios.cc
+	+	17_intro/header_iosfwd.cc
+	+	17_intro/header_iostream.cc
+	+	17_intro/header_istream.cc
+	+	17_intro/header_ostream.cc
+	+	17_intro/header_sstream.cc
+	+	17_intro/header_streambuf.cc
+	+	17_intro/headers.cc
+	+	17_intro/headers_c++.cc
+	+	17_intro/headers_c.cc
+	+	18_support/numeric_limits.cc
+	+	19_diagnostics/stdexceptions.cc
+	+	20_util/auto_ptr.cc
+	-r	21_strings/append.cc
-b	-b	21_strings/capacity.cc
+	+	21_strings/char_traits_requirements.cc
+	+	21_strings/char_traits_typedefs.cc
+	+	21_strings/compare.cc
-r	-r	21_strings/ctor_copy_dtor.cc
+	-r	21_strings/element_access.cc
+	+	21_strings/find.cc
+	-r	21_strings/insert.cc
+	+	21_strings/inserters_extractors.cc
+	+	21_strings/invariants.cc
+	+	21_strings/nonmember.cc
+	+	21_strings/operations.cc
+	+	21_strings/replace.cc
+	+	21_strings/rfind.cc
+	-r	21_strings/substr.cc
+	+	22_locale/codecvt_char_char.cc
+	+	22_locale/codecvt_unicode_char.cc
+	+	22_locale/codecvt_unicode_wchar_t.cc
+	+	22_locale/codecvt_wchar_t_char.cc
+	+	22_locale/ctor_copy_dtor.cc
+	+	22_locale/ctype.cc
-r	/xxx/gnu/gcc-3.0/objdir/hppa1.1-hp-hpux10.20/libstdc++-v3/mkcheck: printf: failed: invalid number
-r	/xxx/gnu/gcc-3.0/objdir/hppa1.1-hp-hpux10.20/libstdc++-v3/mkcheck: printf: failed: invalid number
22_locale/ctype_char_members.cc
+	+	22_locale/ctype_wchar_t_members.cc
+	+	22_locale/facet.cc
+	+	22_locale/global_templates.cc
+	+	22_locale/members.cc
-b	-b	22_locale/numpunct.cc
+	+	22_locale/numpunct_byname.cc
+	+	22_locale/numpunct_char_members.cc
+	+	22_locale/operators.cc
+	+	22_locale/static_members.cc
+	+	23_containers/bitset_ctor.cc
+	+	23_containers/bitset_shift.cc
-b	-b	23_containers/map_operators.cc
+	+	23_containers/multiset.cc
-b	-b	23_containers/set_operators.cc
+	+	23_containers/vector_capacity.cc
+	+	23_containers/vector_ctor.cc
+	-r	23_containers/vector_element_access.cc
+	+	23_containers/vector_modifiers.cc
+	+	24_iterators/istreambuf_iterator.cc
+	+	24_iterators/iterator.cc
+	+	25_algorithms/equal.cc
+	+	25_algorithms/lower_bound.cc
+	+	25_algorithms/min_max.cc
+	/xxx/gnu/gcc-3.0/objdir/hppa1.1-hp-hpux10.20/libstdc++-v3/mkcheck: printf: =: invalid number
+	/xxx/gnu/gcc-3.0/objdir/hppa1.1-hp-hpux10.20/libstdc++-v3/mkcheck: printf: =: invalid number
26_numerics/binary_closure.cc
+	+	26_numerics/buggy_complex.cc
+	+	26_numerics/c99_macros.cc
+	+	26_numerics/c_math.cc
+	+	26_numerics/complex_inserters_extractors.cc
+	+	26_numerics/complex_value.cc
+	+	26_numerics/valarray.cc
-b	-b	27_io/filebuf.cc
+	+	27_io/filebuf_members.cc
+	+	27_io/fpos.cc
+	+	27_io/ifstream_members.cc
+	+	27_io/ios_base_callbacks.cc
-r	/xxx/gnu/gcc-3.0/objdir/hppa1.1-hp-hpux10.20/libstdc++-v3/mkcheck: printf: 24689timemark: invalid number
-r	/xxx/gnu/gcc-3.0/objdir/hppa1.1-hp-hpux10.20/libstdc++-v3/mkcheck: printf: 24689timemark: invalid number
27_io/ios_base_members_static.cc
+	+	27_io/ios_base_storage.cc
+	+	27_io/ios_ctor.cc
+	+	27_io/ios_manip_basefield.cc
+	+	27_io/ios_manip_fmtflags.cc
+	-r	27_io/ios_members.cc
+	+	27_io/istream.cc
+	+	27_io/istream_extractor_arith.cc
-r	/xxx/gnu/gcc-3.0/objdir/hppa1.1-hp-hpux10.20/libstdc++-v3/mkcheck: printf: failed: invalid number
-r	/xxx/gnu/gcc-3.0/objdir/hppa1.1-hp-hpux10.20/libstdc++-v3/mkcheck: printf: failed: invalid number
27_io/istream_extractor_char.cc
+	+	27_io/istream_extractor_other.cc
+	+	27_io/istream_manip.cc
-b	-b	27_io/istream_seeks.cc
+	+	27_io/istream_sentry.cc
diff: ./istream_unformatted-2.txt: No such file or directory
+	diff: ./istream_unformatted-2.txt: No such file or directory
+	27_io/istream_unformatted.cc
+	+	27_io/istringstream_members.cc
+	/xxx/gnu/gcc-3.0/objdir/hppa1.1-hp-hpux10.20/libstdc++-v3/mkcheck: printf: cout: invalid number
+	/xxx/gnu/gcc-3.0/objdir/hppa1.1-hp-hpux10.20/libstdc++-v3/mkcheck: printf: cout: invalid number
27_io/narrow_stream_objects.cc
+	+	27_io/ofstream_members.cc
+	+	27_io/ostream.cc
+	+	27_io/ostream_inserter_arith.cc
+	+	27_io/ostream_inserter_char.cc
+	+	27_io/ostream_inserter_other.cc
+	+	27_io/ostream_manip.cc
+	+	27_io/ostream_seeks.cc
+	+	27_io/ostream_unformatted.cc
+	+	27_io/streambuf.cc
+	+	27_io/stringbuf.cc
+	+	27_io/stringstream.cc
+	+	27_io/wide_stream_objects.cc
+	+	ext/headers.cc
testrun == 9137 seconds

Most of the shared test now run sucessfully!  Yeah!

Here is the configuration:

1) Patch below to add the pic save to the parameter insns.

2) Hack to make type constructors static:
   < http://gcc.gnu.org/ml/gcc/2001-04/msg01011.html >.  Mark was going to
   provide a correct fix for this.

3) NM_FLAG fix:
   < http://gcc.gnu.org/ml/gcc-patches/2001-04/msg01058.html >.

4) Full length subspace names:
   < http://gcc.gnu.org/ml/gcc/2001-04/msg01067.html >.

5) GNU tools (as, nm, etc.) rather than HP.

I will try to look further into the section name problem tomorrow (I've just
driven 12 hours today).  I did notice that HP `nm -p' prints the subspace
names as `t' symbols and they still come out even with "-pg".  I will post
full testresults tomorrow.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

2001-01-04  John David Anglin  <dave@hiauly1.hia.nrc.ca>

	* pa.c (hppa_init_pic_save): Update last_parm_insn after emitting
	pic save insn.

--- pa.c.orig	Tue Apr 17 14:36:50 2001
+++ pa.c	Tue Apr 24 00:03:33 2001
@@ -3359,7 +3359,7 @@
 
   /* Emit the insn at the beginning of the function after the prologue.  */
   push_topmost_sequence ();
-  emit_insn_after (insn, last_parm_insn ? last_parm_insn : get_insns ());
+  last_parm_insn = emit_insn_before (insn, get_first_nonparm_insn ());
   pop_topmost_sequence ();
 }
 

Re: C++ Issue on GCC 3.0 branch

[law]

  In message < 200104250323.XAA05283@hiauly1.hia.nrc.ca >you write:
  > 2001-01-04  John David Anglin  <dave@hiauly1.hia.nrc.ca>
  > 
  > 	* pa.c (hppa_init_pic_save): Update last_parm_insn after emitting
  > 	pic save insn.
This is fine for the mainline sources as well as the branch.

Thanks for tracking this down!

If you want another challenge -- the rethrow1.C test from the g++ testsuite is
getting into an infinite loop.  A 2.95.x based compiler does the right thing.

I've started poking at this, but I don't have a real clear understanding of
the C++ language or its EH semantics.  About the only tidbit I've got that
might be helpful is that we might be missing a call to cp_pop_exception.

jeff

Re: C++ Issue on GCC 3.0 branch

[Mark Mitchell]

>>>>> "law" == law  <law@redhat.com> writes:

    law> I've started poking at this, but I don't have a real clear
    law> understanding of the C++ language or its EH semantics.  About
    law> the only tidbit I've got that might be helpful is that we
    law> might be missing a call to cp_pop_exception.

I'm delighted that we're making progress on HPUX.  That's exciting.

Of course, RTH is getting ready to stand EH on its head.  So, unless
this happens on the mainline, it's probaby not worth looking at; the
whole land of exceptions is going to turn upside down RSN.

Thanks,

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: C++ Issue on GCC 3.0 branch

[law]

  In message < 20010426170133Z.mitchell@codesourcery.com >you write:
  > >>>>> "law" == law  <law@redhat.com> writes:
  > 
  >     law> I've started poking at this, but I don't have a real clear
  >     law> understanding of the C++ language or its EH semantics.  About
  >     law> the only tidbit I've got that might be helpful is that we
  >     law> might be missing a call to cp_pop_exception.
  > 
  > I'm delighted that we're making progress on HPUX.  That's exciting.
  > 
  > Of course, RTH is getting ready to stand EH on its head.  So, unless
  > this happens on the mainline, it's probaby not worth looking at; the
  > whole land of exceptions is going to turn upside down RSN.
I'm really not looking at the mainline at all.  I'll put debugging EH stuff
on hold for now and look at other issues.
jeff

Re: C++ Issue on GCC 3.0 branch

[John David Anglin]

>   In message < 200104250323.XAA05283@hiauly1.hia.nrc.ca >you write:
>   > 2001-01-04  John David Anglin  <dave@hiauly1.hia.nrc.ca>
>   > 
>   > 	* pa.c (hppa_init_pic_save): Update last_parm_insn after emitting
>   > 	pic save insn.
> This is fine for the mainline sources as well as the branch.
> 
> Thanks for tracking this down!

Before I installed this, I checked to make sure there were no gcc regressions
in the testsuite with -fPIC.  I found that in fact there were some.  It looks
like there are problems with the placement of the save instruction when
the first non parameter insn is nil.  I think we need to place the save
after the first insn (the one returned by get_insns ()) in this case.

Some of the fails in the testsuite are due to an abort at integrate.c:430
due to first insn not being a note:

;; Function z

(note 2 0 26 NOTE_INSN_DELETED 0)

(insn 26 2 3 (set (reg:SI 98)
        (reg:SI 19 %r19)) -1 (nil)
    (nil))

(note 3 26 5 NOTE_INSN_FUNCTION_BEG 0)

I am going to go back to the original form and not use
get_first_nonparm_insn ().  I think this will fix the problem.
This suggests that there is also a bug in get_eh_context () for
the same reason.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: C++ Issue on GCC 3.0 branch

[John David Anglin]

> If you want another challenge -- the rethrow1.C test from the g++ testsuite is
> getting into an infinite loop.  A 2.95.x based compiler does the right thing.
> 
> I've started poking at this, but I don't have a real clear understanding of
> the C++ language or its EH semantics.  About the only tidbit I've got that
> might be helpful is that we might be missing a call to cp_pop_exception.

I think we need to define builtin_setjmp_receiver to restore r19.  The
default exception method I believe is exceptions via longjmp, so we need
this.  However, I have no idea whether or not this will fix the problem
with rethrow1.C.

I also noticed a while back that exception_receiver uses a stack offset
of -32 to restore the pic offset table register.  This won't work on
the 64-bit target.  I think we should restore from the
PIC_OFFSET_TABLE_SAVE_RTX.  However, we need to wait for it to be
initialized.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: C++ Issue on GCC 3.0 branch

[law]

  In message < 200104272214.SAA06753@hiauly1.hia.nrc.ca >you write:
  > I think we need to define builtin_setjmp_receiver to restore r19.  The
  > default exception method I believe is exceptions via longjmp, so we need
  > this.  However, I have no idea whether or not this will fix the problem
  > with rethrow1.C.
Yes, we probably need to restore %r19, but I'm 99.9 certain that's not the
problem with the rethrow test since they fail with static libraries.


  > I also noticed a while back that exception_receiver uses a stack offset
  > of -32 to restore the pic offset table register.  This won't work on
  > the 64-bit target.  I think we should restore from the
  > PIC_OFFSET_TABLE_SAVE_RTX.  However, we need to wait for it to be
  > initialized.
Right.
jeff

Re: C++ Issue on GCC 3.0 branch

[John David Anglin]

>   In message < 200104250323.XAA05283@hiauly1.hia.nrc.ca >you write:
>   > 2001-01-04  John David Anglin  <dave@hiauly1.hia.nrc.ca>
>   > 
>   > 	* pa.c (hppa_init_pic_save): Update last_parm_insn after emitting
>   > 	pic save insn.
> This is fine for the mainline sources as well as the branch.

I have installed it on the branch.  The code on the main is different.
Thus, I don't know if the same problem exists there or not.  The code
on the main looks strange to me.  One change that looks certainly
correct is to set RTX_UNCHANGING_P in PIC_OFFSET_TABLE_SAVE_RTX.

> Thanks for tracking this down!
> 
> If you want another challenge -- the rethrow1.C test from the g++ testsuite is
> getting into an infinite loop.  A 2.95.x based compiler does the right thing.
> 
> I've started poking at this, but I don't have a real clear understanding of
> the C++ language or its EH semantics.  About the only tidbit I've got that
> might be helpful is that we might be missing a call to cp_pop_exception.

I have been looking at some of the g++ failures.  I have some revisions
to the setjmp/longjmp stuff in pa.md.  However, I noticed last night
that some code generated by builtin_setjmp was missing.  It appears that
more than just labels were disappearing.  Essentially, builtin_setjmp
was dropping into the receiver code on the intial setup.

I have updated my test source so that it now includes your disappearing
label patch.  Hopefully, this will fix some of the problems.  I visually
looked at the assembler code in __sjthrow and it now looks ok.  Tests
are running..

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: gcc 2.95.2

[Joe Buck]

> I am planning to install gcc 2.95.2 on an IBM AIX server.  I am
> dowloading the gcc from the sunfreeware site.  Does gcc 2.95.2 works on
> IBM AIX server.

sunfreeware provides precompiled binaries for Solaris, not for IBM AIX,
so that isn't going to work.  But gcc does support AIX.

Please ask the gcc-help@gcc.gnu.org list for assistance; gcc@gcc.gnu.org
is the compiler developers' list.

Re: STL warnings recently appeared in the 3.0 branch

[John David Anglin]

> On Jun 14, 2001, Sylvain Pion <Sylvain.Pion@sophia.inria.fr> wrote:

> > .../include/g++-v3/bits/stl_alloc.h:494:
> > warning: aggregate has a partly bracketed initializer

> > I don't get them on GNU-Linux, but they appear on Solaris.

> IIRC, this is a bug in Solaris' headers.  The initializer for mutexes
> defined in some header file triggers this warning.

If you are using solaris threads (gthr-solaris.h), the system headers
(thread.h) are supposed to define DEFAULTMUTEX.  If they don't, the
initializer is broken and the STL mutex locking won't work properly.
The integration of GTHREADS into v3 is new which is why your seeing
the warning.  My previous comments probably don't apply to solaris.

The file gthr-solaris.h may need to check to see if DEFAULTMUTEX is
defined.  If it isn't then, some fallback is needed.  This could be
defining DEFAULTMUTEX, or using __GTHREAD_ONCE_INIT_FUNCTION instead
of __GTHREAD_ONCE_INIT.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: Possible corruption of gcc-3.0-20010614.tar.bz2

[John David Anglin]

>     [11: huff+mtf
> bzip2: Caught a SIGSEGV or SIGBUS whilst decompressing,
> 	which probably indicates that the compressed data
> 	is corrupted.
> 	Input file = Z/gcc-3.0-20010614.tar.bz2, output file = (none)

The problem has been confirmed with a second download from a mirror
source.  I also tried decompressing unde i686 linux with same result.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: PATCH: Fix invalid loader fixups from shared libobjc with

[John David Anglin]

> The problem appears wider than just hpux.  See for example,
> < http://gcc.gnu.org/ml/gcc-testresults/2001-06/msg00329.html >.
> This report is for i686-pc-linux-gnu.  I can't say exactly what

I have just run a bootstrap and check to verify this problem.  There
is a problem with the testsuite and the failures are not directly
related to the hpux problem:

/home/dave/gnu/gcc-3.0-20010614/objdir/gcc/testsuite/IMP.x: error in loading shared libraries: libgcc_s.so.1: cannot open shared object file: No such file or directory

I believe that this problem arises on my linux system because
LD_LIBRARY_PATH doesn't affect the patch for dependent libraries (libobjc).
I had some discussion with Alex about trying to fix this with libtool
but the objc testsuite doesn't use libtool.  It just uses xgcc to
build and link testsuite apps.

A second problem is the installation location of libobjc.  It got
installed in ${prefix}/lib/gcc-lib/i688-pc-linux-gnu/3.0.  The other
shared libraries all went in the more normal location ${prefix}/lib.
${prefix}/lib/gcc-lib/i688-pc-linux-gnu/3.0 is not one of the paths
that my system normally uses in its shared library search.  Do you
advise people to make this change or is libobjc being installed
in the wrong place now that it is possible to build a shared version
of it?

Regarding the hpux problem at hand, I see some warnings like this
in the objc.log:

spawn /home/dave/gnu/gcc-3.0-20010614/objdir/gcc/xgcc -B/home/dave/gnu/gcc-3.0-20010614/objdir/gcc/ /home/dave/gnu/gcc-3.0-20010614/gcc/testsuite/objc/execute/string4.m -w -O -I/home/dave/gnu/gcc-3.0-20010614/gcc/testsuite/../../libobjc -L/home/dave/gnu/gcc-3.0-20010614/objdir/i686-pc-linux-gnu/libobjc/.libs -lobjc -lm -o /home/dave/gnu/gcc-3.0-20010614/objdir/gcc/testsuite/string4.x 
/usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.0/../../../../i686-pc-linux-gnu/bin/ld: warning: type and size of dynamic symbol `__objc_class_name_NXConstantString' are not defined

And in libobjc.a:

0000000000000004 ? __objc_class_name_Object

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: Simple returns are broken in gcc 3.X

[John David Anglin]

> In looking into why g++ didn't work for vax-dec-ultrix4.3, I have found
> that simple returns are broken.  Compiling this small test program
> 
> static char *
> srealloc (char *p, char *q, int i)
> {
>   if (i == 0)
>     return p;
>   else
>     return q;
> }
> 
> yields
> 
> #NO_APP
> 	.text
> 	.align 1
> __Z8sreallocPcS_i:
> 	.word 0x0
> 	subl2 $12,sp
> 	tstl 12(ap)
> 	jneq L2
> 	ret
> L2:
> 	ret

This patch fixes the above problem by always forcing a "goto" return.
The patch only affects the vax since it is the only remaining port that
doesn't define an epilogue and allows the expansion of simple returns
prior to reload.  This patch changes the vax port to use the same
code patch for return generation as all others.  As a side benefit, the
change also fixes function instrumentation on the vax.

The above behavior is a regression versus previous gcc versions since
g++ was functional on the vax in version 2.8.1.

Full bootstrap has been done with vax-dec-ultrix4.3 with 3.0 branch.
Bootstrap and regression checked with 3.0 branch on hppa1.1-hp-hpux10.20
and i686-pc-linux-gnu.  Bootstrap and regression checked with 3.1
mainline on i686-pc-linux-gnu.

OK for main?  I would like it on the branch as well but there are a
couple of other patches needed before C++ will be fully functional
on the vax.  Thus, it can wait until after 3.0.1 is released.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

2001-08-09  John David Anglin  <dave@hiauly1.hia.nrc.ca>

	* stmt.c (expand_null_return_1): Remove code to generate simple returns 
	and "use_goto" argument.
	(expand_null_return, expand_value_return): Update all callers.
	* function.c (expand_function_end): Remove code to generate simple
	return.
	* config/vax/vax.md (epilogue): New expander for function return.
	* doc/md.texi (epilogue): Remove "if defined".

--- stmt.c.orig	Tue Jul 31 10:22:56 2001
+++ stmt.c	Wed Aug  1 15:52:05 2001
@@ -403,7 +403,7 @@
 static void expand_nl_goto_receivers	PARAMS ((struct nesting *));
 static void fixup_gotos			PARAMS ((struct nesting *, rtx, tree,
 					       rtx, int));
-static void expand_null_return_1	PARAMS ((rtx, int));
+static void expand_null_return_1	PARAMS ((rtx));
 static void expand_value_return		PARAMS ((rtx));
 static int tail_recursion_args		PARAMS ((tree, tree));
 static void expand_cleanups		PARAMS ((tree, tree, int, int));
@@ -2863,7 +2863,6 @@
 void
 expand_null_return ()
 {
-  struct nesting *block = block_stack;
   rtx last_insn = get_last_insn ();
 
   /* If this function was declared to return a value, but we
@@ -2871,13 +2870,7 @@
      propogated live to the rest of the function.  */
   clobber_return_register ();
 
-  /* Does any pending block have cleanups?  */
-  while (block && block->data.block.cleanups == 0)
-    block = block->next;
-
-  /* If yes, use a goto to return, since that runs cleanups.  */
-
-  expand_null_return_1 (last_insn, block != 0);
+  expand_null_return_1 (last_insn);
 }
 
 /* Generate RTL to return from the current function, with value VAL.  */
@@ -2886,7 +2879,6 @@
 expand_value_return (val)
      rtx val;
 {
-  struct nesting *block = block_stack;
   rtx last_insn = get_last_insn ();
   rtx return_reg = DECL_RTL (DECL_RESULT (current_function_decl));
 
@@ -2913,27 +2905,15 @@
 	emit_move_insn (return_reg, val);
     }
 
-  /* Does any pending block have cleanups?  */
-
-  while (block && block->data.block.cleanups == 0)
-    block = block->next;
-
-  /* If yes, use a goto to return, since that runs cleanups.
-     Use LAST_INSN to put cleanups *before* the move insn emitted above.  */
-
-  expand_null_return_1 (last_insn, block != 0);
+  expand_null_return_1 (last_insn);
 }
 
 /* Output a return with no value.  If LAST_INSN is nonzero,
-   pretend that the return takes place after LAST_INSN.
-   If USE_GOTO is nonzero then don't use a return instruction;
-   go to the return label instead.  This causes any cleanups
-   of pending blocks to be executed normally.  */
+   pretend that the return takes place after LAST_INSN.  */
 
 static void
-expand_null_return_1 (last_insn, use_goto)
+expand_null_return_1 (last_insn)
      rtx last_insn;
-     int use_goto;
 {
   rtx end_label = cleanup_label ? cleanup_label : return_label;
 
@@ -2941,27 +2921,8 @@
   do_pending_stack_adjust ();
   last_expr_type = 0;
 
-  /* PCC-struct return always uses an epilogue.  */
-  if (current_function_returns_pcc_struct || use_goto)
-    {
-      if (end_label == 0)
-	end_label = return_label = gen_label_rtx ();
-      expand_goto_internal (NULL_TREE, end_label, last_insn);
-      return;
-    }
-
-  /* Otherwise output a simple return-insn if one is available,
-     unless it won't do the job.  */
-#ifdef HAVE_return
-  if (HAVE_return && use_goto == 0 && cleanup_label == 0)
-    {
-      emit_jump_insn (gen_return ());
-      emit_barrier ();
-      return;
-    }
-#endif
-
-  /* Otherwise jump to the epilogue.  */
+  if (end_label == 0)
+     end_label = return_label = gen_label_rtx ();
   expand_goto_internal (NULL_TREE, end_label, last_insn);
 }
 \f
--- function.c.orig	Sat Jun  9 15:22:26 2001
+++ function.c	Wed Aug  1 12:40:23 2001
@@ -6949,18 +6949,6 @@
      instead of using the general framework.  */
   use_return_register ();
 
-  /* Output a return insn if we are using one.
-     Otherwise, let the rtl chain end here, to drop through
-     into the epilogue.  */
-
-#ifdef HAVE_return
-  if (HAVE_return)
-    {
-      emit_jump_insn (gen_return ());
-      emit_barrier ();
-    }
-#endif
-
   /* Fix up any gotos that jumped out to the outermost
      binding level of the function.
      Must follow emitting RETURN_LABEL.  */
--- config/vax/vax.md.orig	Sun Jan 14 04:08:51 2001
+++ config/vax/vax.md	Tue Jul 31 22:08:45 2001
@@ -1926,6 +1926,15 @@
   ""
   "ret")
 
+(define_expand "epilogue"
+  [(return)]
+  ""
+  "
+{
+  emit_jump_insn (gen_return ());
+  DONE;
+}")
+
 (define_insn "nop"
   [(const_int 0)]
   ""
--- doc/md.texi.orig	Thu Jun 14 18:54:21 2001
+++ doc/md.texi	Thu Aug  9 12:24:04 2001
@@ -2859,7 +2859,7 @@
 
 @cindex @code{epilogue} instruction pattern
 @item @samp{epilogue}
-This pattern, if defined, emits RTL for exit from a function.  The function
+This pattern emits RTL for exit from a function.  The function
 exit is responsible for deallocating the stack frame, restoring callee saved
 registers and emitting the return instruction.
 

Re: Simple returns are broken in gcc 3.X

[Richard Henderson]

On Thu, Aug 09, 2001 at 06:12:04PM -0400, John David Anglin wrote:
> 	* stmt.c (expand_null_return_1): Remove code to generate simple returns 
> 	and "use_goto" argument.
> 	(expand_null_return, expand_value_return): Update all callers.
> 	* function.c (expand_function_end): Remove code to generate simple
> 	return.
> 	* config/vax/vax.md (epilogue): New expander for function return.
> 	* doc/md.texi (epilogue): Remove "if defined".

Ok.


r~

Re: Question regarding ICE in instantiate_virtual_regs_1, at function.c:3880

[John David Anglin]

> I am seeing a number of ICEs in the testsuite in instantiate_virtual_regs_1,
> at function.c:3880, on vax-dec-ultrix4.3 with the main.  The first one that
> I looked at occurs on this insn in gcc.c-torture/compile/991213-1.c:
> 
> (insn 22 21 23 (set (mem/f:DF (plus:SI (reg/f:SI 17 virtual-stack-vars)
>                 (const_int -20 [0xffffffec])) [0 arg+8 S8 A64])
> 	(subreg:DF (mem:DC (plus:SI (mult:SI (reg:SI 21)
> 			(const_int 16 [0x10]))
> 		    (mem/f:SI (reg/f:SI 16 virtual-incoming-args) [0 t+0 S4 A32])) [0 S16 A32]) 8)) -1 (nil)
>    (nil))
> 
> It appears that instantiate_virtual_regs_1 ICEs because general_operand
> (see recog.c:966) doesn't allow a SUBREG with a nonzero SUBREG_BYTE and
> this causes the first instantiation to fail.  Should this insn have been
> created in the first place if there is this limitation on SUBREG MEMs?

I see that the change to general_operand to prohibit nonzero subreg bytes
was made last last May to fix a "not so trivial powerpc regression"
<http://gcc.gnu.org/ml/gcc-patches/2001-05/msg01309.html>.  In this
message, there is mention of being less aggressive and verifying if
offsetted memory will match.  On the otherhand, Richard suggested that
it would be better not to create these subregs in the first place.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: Question regarding ICE in instantiate_virtual_regs_1, at function.c:3880

[John David Anglin]

> > I am seeing a number of ICEs in the testsuite in instantiate_virtual_regs_1,
> > at function.c:3880, on vax-dec-ultrix4.3 with the main.  The first one that
> > I looked at occurs on this insn in gcc.c-torture/compile/991213-1.c:
> > 
> > (insn 22 21 23 (set (mem/f:DF (plus:SI (reg/f:SI 17 virtual-stack-vars)
> >                 (const_int -20 [0xffffffec])) [0 arg+8 S8 A64])
> > 	(subreg:DF (mem:DC (plus:SI (mult:SI (reg:SI 21)
> > 			(const_int 16 [0x10]))
> > 		    (mem/f:SI (reg/f:SI 16 virtual-incoming-args) [0 t+0 S4 A32])) [0 S16 A32]) 8)) -1 (nil)
> >    (nil))
> > 

I have come to the conclusion that there is a problem with
GO_IF_LEGITIMATE_ADDRESS on the vax (ie, it shouldn't accept a
DCmode MEM with the above indexing) since the maximum number
of bytes that can be moved in a single insn is 8.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: Question regarding ICE in instantiate_virtual_regs_1, at function.c:3880

[Jan Hubicka]

> > > I am seeing a number of ICEs in the testsuite in instantiate_virtual_regs_1,
> > > at function.c:3880, on vax-dec-ultrix4.3 with the main.  The first one that
> > > I looked at occurs on this insn in gcc.c-torture/compile/991213-1.c:
> > > 
> > > (insn 22 21 23 (set (mem/f:DF (plus:SI (reg/f:SI 17 virtual-stack-vars)
> > >                 (const_int -20 [0xffffffec])) [0 arg+8 S8 A64])
> > > 	(subreg:DF (mem:DC (plus:SI (mult:SI (reg:SI 21)
> > > 			(const_int 16 [0x10]))
> > > 		    (mem/f:SI (reg/f:SI 16 virtual-incoming-args) [0 t+0 S4 A32])) [0 S16 A32]) 8)) -1 (nil)
> > >    (nil))
> > > 
> 
> I have come to the conclusion that there is a problem with
> GO_IF_LEGITIMATE_ADDRESS on the vax (ie, it shouldn't accept a
> DCmode MEM with the above indexing) since the maximum number
> of bytes that can be moved in a single insn is 8.
Yes, this is the complex type hackery - basically it does the DC modes behind
scene w/o validation from backend splitting it later.
What you need is to figure out from where the subreg is comming and replace
gen_SUBREG by simplify_gen_subreg. That should be enought I guess.

In case simplify_gen_subreg for some purpose refuse to simplify memory in question,
let me know.

Honza
> 
> Dave
> -- 
> J. David Anglin                                  dave.anglin@nrc.ca
> National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: Question regarding ICE in instantiate_virtual_regs_1, at function.c:3880

[John David Anglin]

> > I have come to the conclusion that there is a problem with
> > GO_IF_LEGITIMATE_ADDRESS on the vax (ie, it shouldn't accept a
> > DCmode MEM with the above indexing) since the maximum number
> > of bytes that can be moved in a single insn is 8.
> Yes, this is the complex type hackery - basically it does the DC modes behind
> scene w/o validation from backend splitting it later.
> What you need is to figure out from where the subreg is comming and replace
> gen_SUBREG by simplify_gen_subreg. That should be enought I guess.
> 
> In case simplify_gen_subreg for some purpose refuse to simplify memory in question,
> let me know.

The subreg is coming from simplify_gen_subreg:

  new = simplify_subreg (outermode, op, innermode, byte);
  if (new)
    return new;

  if (GET_CODE (op) == SUBREG || GET_MODE (op) == VOIDmode)
    return NULL_RTX;

  return gen_rtx_SUBREG (outermode, op, byte);
}

The call to simplify_subreg us not successful because mode_dependent_address_p

returns true for:

(plus:SI (mult:SI (reg:SI 21)
        (const_int 16 [0x10]))
    (mem/f:SI (reg/f:SI 16 virtual-incoming-args) [0 t+0 S4 A32]))

At the moment, GO_IF_MODE_DEPENDENT_ADDRESS only accepts a plus with
a register and a constant address.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: Question regarding ICE in instantiate_virtual_regs_1, at function.c:3880

[Jan Hubicka]

> > > I have come to the conclusion that there is a problem with
> > > GO_IF_LEGITIMATE_ADDRESS on the vax (ie, it shouldn't accept a
> > > DCmode MEM with the above indexing) since the maximum number
> > > of bytes that can be moved in a single insn is 8.
> > Yes, this is the complex type hackery - basically it does the DC modes behind
> > scene w/o validation from backend splitting it later.
> > What you need is to figure out from where the subreg is comming and replace
> > gen_SUBREG by simplify_gen_subreg. That should be enought I guess.
> > 
> > In case simplify_gen_subreg for some purpose refuse to simplify memory in question,
> > let me know.
> 
> The subreg is coming from simplify_gen_subreg:
> 
>   new = simplify_subreg (outermode, op, innermode, byte);
>   if (new)
>     return new;
> 
>   if (GET_CODE (op) == SUBREG || GET_MODE (op) == VOIDmode)
>     return NULL_RTX;
> 
>   return gen_rtx_SUBREG (outermode, op, byte);
> }
> 
> The call to simplify_subreg us not successful because mode_dependent_address_p
> 
> returns true for:
> 
> (plus:SI (mult:SI (reg:SI 21)
>         (const_int 16 [0x10]))
>     (mem/f:SI (reg/f:SI 16 virtual-incoming-args) [0 t+0 S4 A32]))
> 
> At the moment, GO_IF_MODE_DEPENDENT_ADDRESS only accepts a plus with
> a register and a constant address.
I see. This is somewhat unfortunate.
What I was thinking about is to add simplify_subreg_force wrapper that will
do converison even if it looks wrong (resulting address is invalid or resulting
register having not valid mode).
This is usefull for few other places too (alter_subreg, split_di), perhaps it
can be used here too. Sound sane?

Honza
> 
> Dave
> -- 
> J. David Anglin                                  dave.anglin@nrc.ca
> National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: Question regarding ICE in instantiate_virtual_regs_1, at function.c:3880

[John David Anglin]

> > > > I have come to the conclusion that there is a problem with
> > > > GO_IF_LEGITIMATE_ADDRESS on the vax (ie, it shouldn't accept a
> > > > DCmode MEM with the above indexing) since the maximum number
> > > > of bytes that can be moved in a single insn is 8.

Changing GO_IF_LEGITIMATE_ADDRESS to reject DCmode (or larger) index
addresses in the form plus ((mult ((reg) (const_int))) (mem)) appears
to resolve the problem.  Logically, this seems the correct approach as
the capability to index DCmode doesn't exist on all VAXen, and no DCmode
patterns are presently in the machine definition.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: condition codes, haifa-sched and virtual-stack-vars

[Ulrich Weigand]

Following up on myself:

> The reload_inhi pattern tries to allocate the carry register as the
> secondary reload scratch register.  Now, in the interesting case 
> where the carry register is in fact live at the location where the
> insn is inserted, this would mean that reload would need to spill
> the carry register and later on restore its old value, right?
> (Because there is only a single register in this class ...)
> 
> However, I'm not sure how the carry register can be spilled,
> given that there is no mov* insn that touches it, unless I'm
> missing something ...

Hmm, what I was missing was that apparently the carry register
can *never* be live during reload, as all insns that actually
use it (except for just a clobber) are *only* ever emitted from 
splitters after reload.

So what I called the 'interesting case' above never happens ...


Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  weigand@informatik.uni-erlangen.de

Re: Help! DW function pointer encoding for PA

[John David Anglin]

> I'll have to look more carefully at the ia64.  I think I see what
> ia64_expand_call is doing to handle the function descriptor vs FDE
> issue:

It appears that the PA has a serious problem in its handling of function
descriptors.  This small test program demonstrates the problem:

int f (int (*func)(void)) { func(); }
int main (void);
int (*i)(void) = &main;
int main() { f (i); f (main); }

This is the assembly output showing how the plabels for the two calls
in main are treated:

	addil LR'i-$global$,%r27
	ldw RR'i-$global$(%r1),%r26
	.CALL ARGW0=GR
	bl f,%r2
	nop
	ldil LR'L$C0000,%r19
	ldw RR'L$C0000(%r19),%r26
	.CALL ARGW0=GR
	bl f,%r2
	nop

As can be seen, the call using  plabel "i" is handled correctly.  However,
for the plabel L$C0000 used in the second call, we are in fact loading the
address of the function from the descriptor rather than the address of the
descriptor.  Thus, indirect calls where the pic register changes value won't
work.  I don't know how this went unnoticed for so long.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: Help! DW function pointer encoding for PA

[David Edelsohn]

	As a point of comparison, the AIX and powerpc64-linux
configurations (which also uses function descriptors) do the right thing
for your testcase.

David

Re: middle-end/6180: Infinite loop in cc1 during dbr pass

[John David Anglin]

> in an indeterminate position.  reposition_prologue_and_epilogue_notes
> moves the epilogue begin note before the sequence.  However, in
> fixing the insn chain, it apparently doesn't check for a sequence
> and the chain is left in a corrupt state.  In particular, it doesn't
> touch the numbering inside the sequence.

reposition_prologue_and_epilogue_notes uses reorder_insns.  The comments
for reorder_insns_nobb indicate that it doesn't know about sequences
and it looks like the same is true for reorder_insns.  Thus, it can't
be used at this point.

Do we actually need to call reposition_prologue_and_epilogue_notes
at this point?

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: middle-end/6180: Infinite loop in cc1 during dbr pass

[Richard Henderson]

On Fri, Apr 05, 2002 at 02:54:08PM -0500, John David Anglin wrote:
> Do we actually need to call reposition_prologue_and_epilogue_notes
> at this point?

Dunno.  Probably not.


r~

Re: middle-end/6180: Infinite loop in cc1 during dbr pass

[John David Anglin]

> On Fri, Apr 05, 2002 at 02:54:08PM -0500, John David Anglin wrote:
> > Do we actually need to call reposition_prologue_and_epilogue_notes
> > at this point?

My conclusion is that we can't reposition prologue and epilogue notes
at this point in dbr_schedule because the above function can't handle
sequences.  Further, the exact end and start of the prologue and
epilogue, respectively, is indeterminant.  Thus, I propose that the
notes not be repositioned.

I have confirmed that the enclosed patch fixes the compilation problem
of nm.c under hppa-linux.  I have bootstrapped and checked that there
are no regressions with this patch under hppa-linux and
hppa2.0w-hp-hpux11.11.

The compilation failure of nm.c is a regression from 3.0.x.  OK for
trunk and 3.1 branch?

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

2002-04-06  John David Anglin  <dave@hiauly1.hia.nrc.ca>

	* reorg.c (dbr_schedule): Don't reposition prologue and epilogue notes.

Index: reorg.c
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/reorg.c,v
retrieving revision 1.70
diff -u -3 -p -r1.70 reorg.c
--- reorg.c	31 Mar 2002 18:45:21 -0000	1.70
+++ reorg.c	6 Apr 2002 02:18:27 -0000
@@ -3686,10 +3686,6 @@ dbr_schedule (first, file)
   /* It is not clear why the line below is needed, but it does seem to be.  */
   unfilled_firstobj = (rtx *) obstack_alloc (&unfilled_slots_obstack, 0);
 
-  /* Reposition the prologue and epilogue notes in case we moved the
-     prologue/epilogue insns.  */
-  reposition_prologue_and_epilogue_notes (first);
-
   if (file)
     {
       int i, j, need_comma;

Re: middle-end/6180: Infinite loop in cc1 during dbr pass

[Richard Henderson]

On Sat, Apr 06, 2002 at 03:12:23PM -0500, John David Anglin wrote:
> 	* reorg.c (dbr_schedule): Don't reposition prologue and epilogue notes.

Ok.


r~

Re: gcc-64 on HP-UX 11.00

[John David Anglin]

> > The latest 'snapshot' as in gcc-20020408.tar.bz2
> 
> I'll try the current cvs.

I don't get the warnings or the seg fault.  Have you got a recent header
and libc patch installed on your system?  I have PHCO_23963 and PHCO_25707.
You will need to figure out where the warnings are coming from by looking at
the cpp output.

Some of the warnings seem to be from the macro definition for obstack_free
in include/obstack.h.  The cast to int might be a problem on hppa64

# if defined __STDC__ && __STDC__
#  define obstack_free(h,obj)                                           \
( (h)->temp = (char *) (obj) - (char *) (h)->chunk,                     \
  (((h)->temp > 0 && (h)->temp < (h)->chunk_limit - (char *) (h)->chunk)\
   ? (int) ((h)->next_free = (h)->object_base                           \
	    = (h)->temp + (char *) (h)->chunk)                          \
   : (((obstack_free) ((h), (h)->temp + (char *) (h)->chunk), 0), 0)))

since pointers are 64bit and ints 32bit.  This is probably not the problem
since the function version of obstack_free returns void.

What version of cc do you have?

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: gcc-64 on HP-UX 11.00

[John David Anglin]

>  In message <200204111518.g3BFIoZE029965@hiauly1.hia.nrc.ca>, "John David Anglin
> " writes:
>  > Gcc doesn't generate inline plabels on the PA.  It would save one insn
>  > and one data location if we could use these selectors.  However, there
>  > have been problems with them in 32bit land for years.  I think the
>  > current assembler can handle them but the SOM linker still doesn't
>  > handle them.
> Actually the SOM linker can handle them, but there are corner cases with 
> very large executables where it's impossible for the SOM linker to properly
> fixup an inline plabel.  For that reason we stopped using them based on
> a recommendation from HP.

Interesting.  The problem might be in the dynamic loader.  In the research
I did for this patch <http://gcc.gnu.org/ml/gcc-patches/2002-04/msg00394.html>,
I tried using inline plabels with both the HP and GNU assembler/linkers
since this would have made the definition of ASM_OUTPUT_MI_THUNK considerably
simpler.  The HP assembler/linker compiled my little test PIC program
with inline plabels.  However, when I executed it, the address loaded was
not the address of a function descriptor for the thunk target function.
GAS didn't like the LTP/RTP selectors at all.  Thus, I was forced to create
a plabel in the data section.  It was a bit tricky to do this in a manner
that was compatible with both hpux and linux.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: gcc-64 on HP-UX 11.00

[H.Merijn Brand]

On Thu 11 Apr 2002 19:14, "John David Anglin" <dave@hiauly1.hia.nrc.ca> wrote:
> >  In message <200204111518.g3BFIoZE029965@hiauly1.hia.nrc.ca>, "John David Anglin
> > " writes:
> >  > Gcc doesn't generate inline plabels on the PA.  It would save one insn
> >  > and one data location if we could use these selectors.  However, there
> >  > have been problems with them in 32bit land for years.  I think the
> >  > current assembler can handle them but the SOM linker still doesn't
> >  > handle them.
> > Actually the SOM linker can handle them, but there are corner cases with 
> > very large executables where it's impossible for the SOM linker to properly
> > fixup an inline plabel.  For that reason we stopped using them based on
> > a recommendation from HP.
> 
> Interesting.  The problem might be in the dynamic loader.  In the research
> I did for this patch <http://gcc.gnu.org/ml/gcc-patches/2002-04/msg00394.html>,
> I tried using inline plabels with both the HP and GNU assembler/linkers
> since this would have made the definition of ASM_OUTPUT_MI_THUNK considerably
> simpler.  The HP assembler/linker compiled my little test PIC program
> with inline plabels.  However, when I executed it, the address loaded was
> not the address of a function descriptor for the thunk target function.
> GAS didn't like the LTP/RTP selectors at all.  Thus, I was forced to create
> a plabel in the data section.  It was a bit tricky to do this in a manner
> that was compatible with both hpux and linux.

I'm off now. If you want me to do more tests, please leave instructions on the
door when you leave. No problems with downloading another source tree, as long
as it is http https or ftp

-- 
H.Merijn Brand        Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using perl-5.6.1, 5.7.3 & 631 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3,
     WinNT 4, Win2K pro & WinCE 2.11 often with Tk800.024 &/| DBD-Unify
ftp://ftp.funet.fi/pub/languages/perl/CPAN/authors/id/H/HM/HMBRAND/

Re: gcc-64 on HP-UX 11.00

[law]

 In message <200204111714.g3BHEf2h000643@hiauly1.hia.nrc.ca>, "John David 
Anglin" writes:
 > Interesting.  The problem might be in the dynamic loader.
It was definitely the linker.  If I recall correctly the problem was related
to the need for the linker to rewrite the inline plabel sequence when the 
plabel
was satisfied from a shared library with an insanely large PLT.

jeff

Re: gcc-64 on HP-UX 11.00

[John David Anglin]

> However, the code from the actual perl function looks like:
> 
>         cmpib,= 0,%r3,L$1012
> 	addil LT'PL_sv_no,%r27
> 	addil LT'PL_sv_yes,%r27
> 	b L$1013
> 	fldd RT'PL_sv_yes(%r1),%fr22
> L$1012
> 	fldd RT'PL_sv_no(%r1),%fr22
> L$1013
> 	fstd %fr22,-272(%r30)
> 	b L$0783
> 	ldd -272(%r30),%r25
> 	[...]
> L$1017
>         copy %r28,%r25
> L$0783
>         copy %r25,%r28
> 	[restore registers and return]

I tested this with gcc 3.0.3 -O -mpa-risc-2-0 -fPIC (32bit) and the code is:

        cmpib,= 0,%r28,L$0940
	addil LT'PL_sv_yes,%r19
	b L$0733
	ldw RT'PL_sv_yes(%r1),%r28
L$0940
	addil LT'PL_sv_no,%r19
	b L$0733
	ldw RT'PL_sv_no(%r1),%r28

So, this worked with 3.0.3 and we have a regression.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: gcc-64 on HP-UX 11.00

[law]

In message <200204152027.g3FKRLuZ009642@hiauly1.hia.nrc.ca>, "John David Anglin
" writes:
 > > However, the code from the actual perl function looks like:
 > > 
 > >         cmpib,= 0,%r3,L$1012
 > > 	addil LT'PL_sv_no,%r27
 > > 	addil LT'PL_sv_yes,%r27
 > > 	b L$1013
 > > 	fldd RT'PL_sv_yes(%r1),%fr22
 > > L$1012
 > > 	fldd RT'PL_sv_no(%r1),%fr22
 > > L$1013
 > > 	fstd %fr22,-272(%r30)
 > > 	b L$0783
 > > 	ldd -272(%r30),%r25
 > > 	[...]
 > > L$1017
 > >         copy %r28,%r25
 > > L$0783
 > >         copy %r25,%r28
 > > 	[restore registers and return]
 > 
 > I tested this with gcc 3.0.3 -O -mpa-risc-2-0 -fPIC (32bit) and the code is:
 > 
 >         cmpib,= 0,%r28,L$0940
 > 	addil LT'PL_sv_yes,%r19
 > 	b L$0733
 > 	ldw RT'PL_sv_yes(%r1),%r28
 > L$0940
 > 	addil LT'PL_sv_no,%r19
 > 	b L$0733
 > 	ldw RT'PL_sv_no(%r1),%r28
 > 
 > So, this worked with 3.0.3 and we have a regression.
I don't doubt that it worked in the past.  My point is that selecting an
FP register to hold an address like this is an exceedingly bad thing to
do.  In fact, not assigning the value to a register and instead leaving it
in memory is actually cheaper than assigning it to an FP register.

In fact, from the fragments, it looks like we did something insanely stupid,
why don't we assign the value to %r28 or %r25?

jeff

Re: gcc-64 on HP-UX 11.00

[John David Anglin]

> I don't doubt that it worked in the past.  My point is that selecting an

My point in looking at whether it worked in the past was simply to determine
whether this was in fact a regression, and whether a fix could be applied
to the 3.1 branch.

> FP register to hold an address like this is an exceedingly bad thing to
> do.  In fact, not assigning the value to a register and instead leaving it
> in memory is actually cheaper than assigning it to an FP register.

I don't quite follow that logic.  Two insns are needed to load the
address and the result must end up in a register.  You can't load
the address directly to memory.  It takes a couple of insns to copy
the result from the FP register to a general register.  Generally,
I guess this must be weighed against the cost of freeing up a general
general.

> In fact, from the fragments, it looks like we did something insanely stupid,
> why don't we assign the value to %r28 or %r25?

I agree it seems very dumb.  We have the following rtl at the end of
function after lreg:

(insn 3088 3494 3091 (set (reg/i:DI 28 %r28)
        (reg/f:DI 66)) 119 {*pa.md:3106} (nil)
    (expr_list:REG_DEAD (reg/f:DI 66)
	(nil)))

DI 66 is set in multiple places.  It seems the compiler doesn't
recognize opportunities to replace DI 66 with DI 28, and so on.

Jeff, I will send you gv.i offline so that you can look at the problem
in more detail.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

gcc-64 20021111 broken on HP-UX 11.00

[H.Merijn Brand]

2002-11-11 is broken for 64bit on HP-UX. 2002-11-04 still worked ...
FWIW 32bit version worked perfect

I'll try to rebuild gcc64 from scratch without using the 20021104 vs

a5:/pro/3gl/GNU/gcc 113 > ll -d src gcc-*
  38813 drwxrwxrwx   17 merijn   softwr       2048 Nov 12 18:38 gcc-20021111
  33464 -rw-r--r--    1 merijn   softwr   20243290 Nov 12 13:24 gcc-20021111.tbz
  33916 lrwxrwxrwx    1 merijn   softwr         12 Nov 12 18:38 src -> gcc-20021111
a5:/pro/3gl/GNU/gcc 114 > cat Conf-gcc64
#!/usr/bin/sh

export CONFIG_SITE=
export CC="gcc64 -mpa-risc-2-0"
export PATH=.:/usr/local/pa20_64/bin:/pro/local/bin
export PATH=$PATH"":/usr/bin:/opt/ansic/bin:/usr/ccs/bin:/opt/langtools/bin
export PATH=$PATH"":/opt/imake/bin

rm -rf obj
mkdir obj
cd obj
../src/configure \
    --enable-languages=c,c++ \
    --prefix=/usr/local/pa20_64 --with-local-prefix=/usr/local/pa20_64 \
    --with-gnu-as --with-as=/usr/local/pa20_64/bin/as \
    --with-gnu-ld --with-ld=/usr/local/pa20_64/bin/ld \
    --disable-shared \
    --disable-nls \
    --host=hppa64-hp-hpux11.00

echo ""
echo "Now start 'Build-gcc64'"
a5:/pro/3gl/GNU/gcc 115 > gcc64 --version
gcc64 (GCC) 3.3 20021104 (experimental)
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

a5:/pro/3gl/GNU/gcc 116 > sh -x Conf-gcc64
+ export CONFIG_SITE=
+ export CC=gcc64 -mpa-risc-2-0
+ export PATH=.:/usr/local/pa20_64/bin:/pro/local/bin
+ export PATH=.:/usr/local/pa20_64/bin:/pro/local/bin:/usr/bin:/opt/ansic/bin:/usr/ccs/bin:/opt/langtools/bin
+ export PATH=.:/usr/local/pa20_64/bin:/pro/local/bin:/usr/bin:/opt/ansic/bin:/usr/ccs/bin:/opt/langtools/bin:/opt/imake/bin
+ rm -rf obj
+ mkdir obj
+ cd obj
+ ../src/configure --enable-languages=c,c++ --prefix=/usr/local/pa20_64 --with-local-prefix=/usr/local/pa20_64 --with-gnu-as
 --with-as=/usr/local/pa20_64/bin/as --with-gnu-ld --with-ld=/usr/local/pa20_64/bin/ld --disable-shared --disable-nls --host
=hppa64-hp-hpux11.00
*** This configuration is not supported in the following subdirectories:
     target-libffi target-boehm-gc target-zlib target-libjava target-libf2c zlib fastjar target-libobjc
    (Any other directories should still work fine.)
Created "Makefile" in /pro/3gl/GNU/gcc/obj using "mh-frag"
ldd: "conftest" is not a shared executable.
collect2: /usr/ccs/bin/ldd returned 1 exit status
*** The command 'gcc64 -mpa-risc-2-0 -o conftest -g   conftest.c' failed.
*** You must set the environment variable CC to a working compiler.
+ echo

+ echo Now start 'Build-gcc64'
Now start 'Build-gcc64'
a5:/pro/3gl/GNU/gcc 117 > gcc --version
gcc (GCC) 3.3 20021111 (experimental)
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

a5:/pro/3gl/GNU/gcc 118 >

-- 
H.Merijn Brand        Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using perl-5.6.1, 5.8.0 & 633 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3,
  WinNT 4, Win2K pro & WinCE 2.11.  Smoking perl CORE: smokers@perl.org
http://archives.develooper.com/daily-build@perl.org/   perl-qa@perl.org
send smoke reports to: smokers-reports@perl.org, QA: http://qa.perl.org

Re: gcc-64 20021111 broken on HP-UX 11.00

[H.Merijn Brand]

On Wed 13 Nov 2002 11:24, H.Merijn Brand <h.m.brand@hccnet.nl> wrote:
> 2002-11-11 is broken for 64bit on HP-UX. 2002-11-04 still worked ...
> FWIW 32bit version worked perfect
> 
> I'll try to rebuild gcc64 from scratch without using the 20021104 vs

That succeeded. Installed OK. Now use that to rebuild gcc64:

   ` if [ -f /pro/3gl/GNU/gcc/obj/gcc/../binutils/ranlib ] ; then echo /pro/3gl/GNU/gcc/obj/gcc/../binutils/ranlib ; else if [ "hppa64-hp-hpux11.00" = "hppa64-hp-hpux11.00" ] ; then echo ranlib; else t='s,^,hppa64-hp-hpux11.00-,'; echo ranlib | sed -e $t ; fi; fi` stage1/libgcc_eh.a; \
  else true; fi; fi
for f in .. ; do if [ x${f} != x.. ]; then \
  cp stage1/${f} . ; \
else true; \
fi; done
mv cp/*.o stage1/cp
mv: cp/*.o: cannot access: No such file or directory
make[2]: [c++.stage1] Error 1 (ignored)
make[2]: Leaving directory `/pro/3gl/GNU/gcc/obj/gcc'
echo timestamp > stage1_copy
echo stage2_build > stage_last
(cd stage1 && rm -f `echo main.o libbackend.a alias.o bb-reorder.o bitmap.o builtins.o caller-save.o calls.o cfg.o cfganal.o cfgbuild.o cfgcleanup.o cfglayout.o cfgloop.o cfgrtl.o combine.o conflict.o convert.o cse.o cselib.o dbxout.o debug.o df.o diagnostic.o doloop.o dominance.o dwarf2asm.o dwarf2out.o dwarfout.o emit-rtl.o except.o explow.o expmed.o expr.o final.o flow.o fold-const.o function.o gcse.o genrtl.o ggc-common.o global.o graph.o gtype-desc.o haifa-sched.o hashtable.o hooks.o ifcvt.o insn-attrtab.o insn-emit.o insn-extract.o insn-opinit.o insn-output.o insn-peep.o insn-recog.o integrate.o intl.o jump.o  langhooks.o lcm.o lists.o local-alloc.o loop.o mbchar.o optabs.o params.o predict.o print-rtl.o print-tree.o profile.o ra.o ra-build.o ra-colorize.o ra-debug.o ra-rewrite.o real.o recog.o reg-stack.o regclass.o regmove.o regrename.o reload.o reload1.o reorg.o resource.o rtl.o rtlanal.o rtl-error.o sbitmap.o sched-deps.o sched-ebb.o sched-rgn.o sched-vis.o sdbout.o sibcall.o simplify-rtx.o ssa.o ssa-ccp.o ssa-dce.o stmt.o stor-layout.o stringpool.o timevar.o toplev.o tracer.o tree.o tree-dump.o tree-inline.o unroll.o varasm.o varray.o version.o vmsdbgout.o xcoffout.o et-forest.o ggc-page.o pa.o  c-parse.o c-lang.o c-pretty-print.o attribs.o c-errors.o c-lex.o c-pragma.o c-decl.o c-typeck.o c-convert.o c-aux-info.o c-common.o c-opts.o c-format.o c-semantics.o c-objc-common.o c-dump.o libcpp.a  cpplib.o cpplex.o cppmacro.o cppexp.o cppfiles.o cpptrad.o cpphash.o cpperror.o cppinit.o cppdefault.o cppmain.o hashtable.o line-map.o mkdeps.o prefix.o mbchar.o *.c *.h gen*`)
echo timestamp > clean_s1
make CC=" stage1/xgcc -Bstage1/ -B/usr/local/pa20_64/hppa64-hp-hpux11.00/bin/" \
         STAGE_PREFIX=stage1/ \
         ADAC="\$(CC)" CFLAGS="-g -O2" LDFLAGS="" WARN_CFLAGS="\$(GCC_WARN_CFLAGS)" STRICT_WARN="-Wtraditional -pedantic -Wno-long-long" libdir=/usr/local/pa20_64/lib LANGUAGES="c gcov c++" MAKEOVERRIDES= OUTPUT_OPTION="-o \$@"
make[2]: Entering directory `/pro/3gl/GNU/gcc/obj/gcc'
stage1/xgcc -Bstage1/ -B/usr/local/pa20_64/hppa64-hp-hpux11.00/bin/ -c   -g -O2 -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long -fno-common  -DHAVE_CONFIG_H -DGENERATOR_FILE    -I. -I. -I../../src/gcc -I../../src/gcc/. -I../../src/gcc/config -I../../src/gcc/../include ../../src/gcc/gengenrtl.c -o gengenrtl.o
stage1/xgcc -Bstage1/ -B/usr/local/pa20_64/hppa64-hp-hpux11.00/bin/   -g -O2 -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long -fno-common  -DHAVE_CONFIG_H -DGENERATOR_FILE  -o gengenrtl \
 gengenrtl.o ../libiberty/libiberty.a
ldd: "gengenrtl" is not a shared executable.
collect2: /usr/ccs/bin/ldd returned 1 exit status
make[2]: *** [gengenrtl] Error 1
make[2]: Leaving directory `/pro/3gl/GNU/gcc/obj/gcc'
make[1]: *** [stage2_build] Error 2
make[1]: Leaving directory `/pro/3gl/GNU/gcc/obj/gcc'
make: *** [bootstrap-lean] Error 2
Exit 2
a5:/pro/3gl/GNU/gcc 131 > gcc64 --version
gcc64 (GCC) 3.3 20021111 (experimental)
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

a5:/pro/3gl/GNU/gcc 132 >

-- 
H.Merijn Brand        Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using perl-5.6.1, 5.8.0 & 633 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3,
  WinNT 4, Win2K pro & WinCE 2.11.  Smoking perl CORE: smokers@perl.org
http://archives.develooper.com/daily-build@perl.org/   perl-qa@perl.org
send smoke reports to: smokers-reports@perl.org, QA: http://qa.perl.org

Re: gcc-64 20021111 broken on HP-UX 11.00

[John David Anglin]

> ldd: "gengenrtl" is not a shared executable.

This is in fact a GNU ld bug.  If you use chatr, you will see that gengenrtl
is an incomplete executable and has dependencies on shared libraries.
ldd should list the dependent shared libraries.  It does if you build using
the HP linker.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: gcc-64 20021111 broken on HP-UX 11.00

[John David Anglin]

> ldd: "gengenrtl" is not a shared executable.
> collect2: /usr/ccs/bin/ldd returned 1 exit status

I have installed the patch below and it should fix the above problem.

However, we are back to the previous situation where global constructors
and destructors in dependent libraries are not executed.  This causes
a variety of regressions when the HP linker was being used.  For example,
objc is essentially unusable and g++ is compromised.  This of course
is also the state with GNU ld.

If you use the HP linker, LD_INIT_SWITCH and LD_FINI_SWITCH can be
defined as shown below and this results in GCC testsuite results
fairly comparable to that of the 32-bit ports.  You can even enable
the building of a shared libgcc in config.gcc.

Unfortunately, LD_INIT_SWITCH and LD_FINI_SWITCH can't be defined
with the GNU linker without other nasty things happening.  As far
as I can tell, there is no way to define these symbols without
making the GCC code linker dependent.  I don't think we want to
do this at this time, so I have disabled the above two macros.
Hopefully, the GNU ld bugs can be fixed in the near future and we
can use the above macros, or possibly .init and .fini sections.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

2002-11-13  John David Anglin  <dave@hiauly1.hia.nrc.ca>

	* pa64-hpux.h (LINK_SPEC): Move "+Accept TypeMismatch" switch to the
	beginning of the spec.
	(LDD_SUFFIX, PARSE_LDD_OUTPUT): Delete.
	(LD_INIT_SWITCH, LD_FINI_SWITCH): Define but don't enable.  Add comment
	regarding problems with global constructors when using GNU ld.

Index: config/pa/pa64-hpux.h
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/config/pa/pa64-hpux.h,v
retrieving revision 1.18
diff -u -3 -p -r1.18 pa64-hpux.h
--- config/pa/pa64-hpux.h	10 Nov 2002 01:14:47 -0000	1.18
+++ config/pa/pa64-hpux.h	13 Nov 2002 17:12:03 -0000
@@ -31,14 +31,16 @@ Boston, MA 02111-1307, USA.  */
      N_("Assume code will be linked by HP ld") },
 
 /* We can debug dynamically linked executables on hpux11; we also
-   want dereferencing of a NULL pointer to cause a SEGV.  */
+   want dereferencing of a NULL pointer to cause a SEGV.  Do not move
+   the "+Accept TypeMismatch" switch.  We check for it in collect2
+   to determine which init/fini is needed.  */
 #undef LINK_SPEC
 #if ((TARGET_DEFAULT | TARGET_CPU_DEFAULT) & MASK_GNU_LD)
 #define LINK_SPEC \
-  "-E %{mlinker-opt:-O} %{!shared:-u main} %{static:-a archive} %{shared:%{mhp-ld:-b}%{!mhp-ld:-shared}} %{mhp-ld:+Accept TypeMismatch}"
+  "%{mhp-ld:+Accept TypeMismatch} -E %{mlinker-opt:-O} %{!shared:-u main} %{static:-a archive} %{shared:%{mhp-ld:-b}%{!mhp-ld:-shared}}"
 #else
 #define LINK_SPEC \
-  "-E %{mlinker-opt:-O} %{!shared:-u main} %{static:-a archive} %{shared:%{mgnu-ld:-shared}%{!mgnu-ld:-b}} %{!mgnu-ld:+Accept TypeMismatch}"
+  "%{!mgnu-ld:+Accept TypeMismatch} -E %{mlinker-opt:-O} %{!shared:-u main} %{static:-a archive} %{shared:%{mgnu-ld:-shared}%{!mgnu-ld:-b}}"
 #endif
 
 /* Like the default, except no -lg.  */
@@ -252,19 +254,26 @@ do {								\
 
 /* Since we are not yet using .init and .fini sections, we need to
    explicitly arrange to run the global constructors and destructors.
-   HPUX 11 has ldd and we use it to determine the dependencies of
-   dynamic objects.  It might be possible to use the ld options for
-   running initializers and terminators and thereby avoid the necessity
-   of running ldd, but unfortunately the options are different for
-   the two linkers.  */
-#define LDD_SUFFIX "/usr/ccs/bin/ldd"
-
-/* Skip to first '>' then advance to '/' at the beginning of the filename.  */
-#define PARSE_LDD_OUTPUT(PTR)					\
-do {								\
-  while (*PTR != '>') PTR++;					\
-  while (*PTR != '/') PTR++;					\
-} while (0)
+   We could use ldd for this but it depends on LD_LIBRARY_PATH being
+   correctly set.  So, we use the ld init and fini switches. However,
+   we need to support different switches for the GNU and HP linkers.
+   We can't check TARGET_GNU_LD in collect2, so we need a different
+   test.  The +Accept switch is always the first switch when we are
+   using the HP linker (see define for LINK_SPEC).  Checking for it
+   is a somewhat fragile as it depends on internal details of the
+   collect2 program but it is better than testing ld_file_name.
+
+   FIXME: The GNU linker is broken.  The -init/-fini switches don't
+   work and ldd can't determine the dynamic dependences of executables
+   linked with GNU ld.  The init and fini routines are not executed
+   although DT_INIT and DT_FINI appear ok.  As a result, defining
+   LD_INIT_SWITCH and LD_FINI_SWITCH causes more harm than good when
+   using GNU ld.  However, the definitions appear to work fine with
+   the HP linker.  */
+#if 0
+#define LD_INIT_SWITCH (strcmp ("+Accept", ld2_argv[1]) ? "-init" : "+init")
+#define LD_FINI_SWITCH (strcmp ("+Accept", ld2_argv[1]) ? "-fini" : "+fini")
+#endif
 
 /* If using HP ld do not call pxdb.  Use size as a program that does nothing
    and returns 0.  /bin/true cannot be used because it is a script without

Re: gcc-64 20021111 broken on HP-UX 11.00

[H.Merijn Brand]

On Wed 13 Nov 2002 22:04, "John David Anglin" <dave@hiauly1.hia.nrc.ca> wrote:
> > ldd: "gengenrtl" is not a shared executable.
> > collect2: /usr/ccs/bin/ldd returned 1 exit status
> 
> I have installed the patch below and it should fix the above problem.

Confirm. Now works for gcc64.

> However, we are back to the previous situation where global constructors
> and destructors in dependent libraries are not executed.  This causes
> a variety of regressions when the HP linker was being used.  For example,
> objc is essentially unusable and g++ is compromised.  This of course
> is also the state with GNU ld.

-- 
H.Merijn Brand        Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using perl-5.6.1, 5.8.0 & 633 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3,
  WinNT 4, Win2K pro & WinCE 2.11.  Smoking perl CORE: smokers@perl.org
http://archives.develooper.com/daily-build@perl.org/   perl-qa@perl.org
send smoke reports to: smokers-reports@perl.org, QA: http://qa.perl.org

Re: gcc-64 20021111 broken on HP-UX 11.00

[John David Anglin]

> 2002-11-11 is broken for 64bit on HP-UX. 2002-11-04 still worked ...
> FWIW 32bit version worked perfect

Sigh, I know.  I am testing a "fix".  However, the problem is really
GNU ld is broken.  Using HP ld should work fine.

I tried to fix the fact that constructors are not being collected
from dependent shared libraries.  Unfortunately, I missed testing
with GNU ld as I was mainly concerned about assembler issues.
This is what ld reports for any executable (not shared libraries)

bash-2.05a$ ldd cc1
ldd: "cc1" is not a shared executable.

I must admit that I first noted a problem using ldd to find
dependencies when I tried a bootstrap with the HP linker and a shared
libgcc.  The problem is LD_LIBRARY_PATH needs to be set correctly
for it to work and this is problematic when building packages
with shared libraries.

Basically, we have to back out from trying to search dependencies
for global constructors until GNU ld is fixed.  This leaves using
shared libraries with constructors broken (various v3, g++ and objc
testsuite fails are caused by this).

I tested an alternative approach using the +init/+fini switches
with the HP linker.  This works fine and I was sucessful building
gcc with a shared libgcc with no regressions.  However, with
the GNU linker, we hit another bug.  The init and fini routines are
not called although DT_INIT and DT_FINI look ok.  The result of this
is worse than not doing the dependency search, so we are in dammed
if we do and dammed if we don't situation.

Anyhow, either use the HP linker or "--disable-shared" for the moment.
I will install a patch later today to restore the previous behavior.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: bison 1.33 problem with mainline c-parse.in: yyfree_stacks

[John David Anglin]

> > /berman/migchain/install/native/bison-1.33/share/bison/bison.simple: In function `yyparse':
> > /berman/migchain/install/native/bison-1.33/share/bison/bison.simple:521: `yyfree_stacks' undeclared (first use in this function)

It looks like this incompatibility was introduced by this patch:

2002-04-25  Richard Henderson  <rth@redhat.com>

        PR c/2161
	* c-parse.in (yyoverflow): New.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: corrections to recent profile-arcs change

[John David Anglin]

> FAIL: g++.dg/bprob/bprob-1.C compilation,  -O2  -fprofile-arcs

This one a SIGSEGV:

(gdb) r -fprofile-arcs -O2 bprob-1.ii
...
Program received signal SIGSEGV, Segmentation fault.
0x0010c574 in ok_to_generate_alias_set_for_type (t=0x402dda10)
    at ../../gcc/gcc/cp/cp-lang.c:214
214               if (! CLASSTYPE_NON_POD_P(t))

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: vax double precision broken

[Joe Buck]

> The single and double IEEE formats do indeed look similar to VAX F and
> G formats respectively, but they do NOT match.  There are three key
> differences: the halfwords are in the opposite order (sign bit is bit
> 31 in each case for IEEE); the exponent bias is one less -- 127 and
> 1023 for IEEE vs. 128 and 1024 for VAX; and the hidden high order bit
> is interpreted as the bit just to the left of the binary point (2**0)
> in IEEE rather than just to the right (2**-1) as in VAX.  (In
> addition, IEEE has both Inf and NaN, while DEC format only has NaN.
> And IEEE has denormals; DEC does not.)

There's a 4th difference: F-floating has the same exponent size as IEEE
single precision, but D-floating has the same number of exponent bits
as F-floating while IEEE doubles have more exponent bits.  (Conversion
from Vax-D to Vax-F is a simple matter of rounding off the mantissa, while
for IEEE, overflow can occur because the double precision type has greater
range).

Re: Bootstrapping hppa64? CPP problem

[John David Anglin]

> > I am curious if anyone is currently bootstrapping the hppa64 GCC
> > compiler from the latest sources?  I am running into a very curious cpp
> > problem.  With the attached example, using the cc1 that I just built I
> > get two definitions of sigpause showing up because _SVID2 seems to be
> > considered defined and undefined at the same time.  It doesn't happen on
> > the other platforms I have tried but it happens consistenly for me on
> > PA64.

I am currently bootstrapping the latest sources for 3.1.1 and 3.2.
3.2 is now in stage2 and doesn't exhibit the problem described, so I
expect that you have a problem with your tools.

There have been a fair number of changes to binutils affecting hppa64
in the last month or so.  I suggest you rebuild them.  The only unexpected
errors should be 7 in the ld suite.  Then, I suggest that you build
3.1.1 starting with either the HP builtin or ANSI compiler.  You should
be able to build 3.2 starting with the HP ANSI compiler.  I'm using
3.1.1 as my default for hppa64 builds.

I will let you know if the problem that you describe appears later
in the build process.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: [parisc-linux] gcc-3.[02] alignment problem

[John David Anglin]

> These messages are coming from the assembler (remove "-pipe").  The
> first is from "std %r4,44(%r3)".  The offset "44" is not correct for
> a store double.  This is probably a problem with pointer arithmetic
> in the source.

Check the definition of RTA_ALIGNTO in linux/rtnetlink.h.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: [parisc-linux] gcc-3.[02] alignment problem

[Randolph Chung]

In reference to a message from John David Anglin, dated Jul 16:
> > These messages are coming from the assembler (remove "-pipe").  The
> > first is from "std %r4,44(%r3)".  The offset "44" is not correct for
> > a store double.  This is probably a problem with pointer arithmetic
> > in the source.
> 
> Check the definition of RTA_ALIGNTO in linux/rtnetlink.h.

ah, this is not it, but i see what it is now.

include/linux/tcp_diag.h defines:

struct tcpdiag_sockid
{
        __u16   tcpdiag_sport;
        __u16   tcpdiag_dport;
        __u32   tcpdiag_src[4];
        __u32   tcpdiag_dst[4];
        __u32   tcpdiag_if;
        __u32   tcpdiag_cookie[2]; 
#define TCPDIAG_NOCOOKIE (~0U)
};

the code goes on to do:
        *((struct sock **)&r->id.tcpdiag_cookie) = sk;
and
            sk != *((struct sock **)&req->id.tcpdiag_cookie[0]))

even tho tcpdiag_cookie looks like it can be 64-bit aligned in the
struct, it appears that it isn't.... 

the "vomit grade hack" alan mentioned in another post is that in our
tree, we have:

struct tcpdiag_sockid
{
        __u16   tcpdiag_sport;
        __u16   tcpdiag_dport;
        __u32   tcpdiag_src[4];
        __u32   tcpdiag_dst[4];
        __u32   tcpdiag_if;
#if defined (__hppa__) && defined (__LP64__)
        char * parisc_hack_to_align_tcpdiag_cookie;
#endif
        __u32   tcpdiag_cookie[2];
#define TCPDIAG_NOCOOKIE (~0U)
};

why is the offset of tcpdiag_cookie[0] 44 and not 40?

randolph
--  
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

Re: [parisc-linux] gcc-3.[02] alignment problem

[Matthew Wilcox]

On Tue, Jul 16, 2002 at 10:22:55AM -0700, Randolph Chung wrote:
> include/linux/tcp_diag.h defines:
> 
> struct tcpdiag_sockid
> {
>         __u16   tcpdiag_sport;
>         __u16   tcpdiag_dport;
>         __u32   tcpdiag_src[4];
>         __u32   tcpdiag_dst[4];
>         __u32   tcpdiag_if;
>         __u32   tcpdiag_cookie[2]; 
> #define TCPDIAG_NOCOOKIE (~0U)
> };

> why is the offset of tcpdiag_cookie[0] 44 and not 40?

0	tcpdiag_sport
2	tcpdiag_dport
4	tcpdiag_src
20	tcpdiag_dst
36	tcpdiag_if
40	tcpdiag_cookie

hmm.. worth checking that dport is at offset 2, not offset 4?

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] gcc-3.[02] alignment problem

[Randolph Chung]

> > why is the offset of tcpdiag_cookie[0] 44 and not 40?
> 
> 0	tcpdiag_sport
> 2	tcpdiag_dport
> 4	tcpdiag_src
> 20	tcpdiag_dst
> 36	tcpdiag_if
> 40	tcpdiag_cookie
> 
> hmm.. worth checking that dport is at offset 2, not offset 4?

oic, it's embedded inside another structure:

struct tcpdiagmsg
{
        __u8    tcpdiag_family;
        __u8    tcpdiag_state;
        __u8    tcpdiag_timer;
        __u8    tcpdiag_retrans;

        struct tcpdiag_sockid id;

        __u32   tcpdiag_expires;
        __u32   tcpdiag_rqueue;
        __u32   tcpdiag_wqueue;
        __u32   tcpdiag_uid;
        __u32   tcpdiag_inode;
};

that's why it's 44...

randolph

Re: [parisc-linux] gcc-3.[02] alignment problem

[Richard Henderson]

On Tue, Jul 16, 2002 at 10:22:55AM -0700, Randolph Chung wrote:
>         __u32   tcpdiag_cookie[2]; 
> #define TCPDIAG_NOCOOKIE (~0U)
> };
> 
> the code goes on to do:
>         *((struct sock **)&r->id.tcpdiag_cookie) = sk;
> and
>             sk != *((struct sock **)&req->id.tcpdiag_cookie[0]))

This is absolutely awful.

> the "vomit grade hack" alan mentioned in another post is that in our
> tree, we have:
> 
> struct tcpdiag_sockid
> {
>         __u16   tcpdiag_sport;
>         __u16   tcpdiag_dport;
>         __u32   tcpdiag_src[4];
>         __u32   tcpdiag_dst[4];
>         __u32   tcpdiag_if;
> #if defined (__hppa__) && defined (__LP64__)
>         char * parisc_hack_to_align_tcpdiag_cookie;
> #endif
>         __u32   tcpdiag_cookie[2];

An only marginally better fix is

	__u32 tcpdiag_cookie[2] __attribute__((aligned(sizeof(void*))));

Note that this should be unconditional so that the other
64-bit ports don't take an alignment trap here too.

A much nicer fix would be to, gasp, use a union.



r~

Re: mainline bootstrap failure in bitmap.c on sparcv9-sun-solaris2.8

[John David Anglin]

> > stage2/xgcc -Bstage2/ -B/home/c/lucier/local/gcc-test/sparcv9-sun-solaris2.8/bin/ -c -DIN_GCC    -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long  -DHAVE_CONFIG_H -DGENERATOR_FILE    -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/config -I../../gcc/../include ../../gcc/bitmap.c -o bitmap.o
> > In file included from ../../gcc/system.h:171,
> >		   from ../../gcc/bitmap.c:22:
> > 		   ../../gcc/hwint.h:39:9: warning: integer overflow in preprocessor expression
> 
> A similar error occurs on hppa-linux near the end of stage2:
> <http://gcc.gnu.org/ml/gcc/2002-07/msg01238.html>.

The following patch appears to be the origin of the bootstrap failure
under hppa-linux:

2002-07-25  Richard Henderson  <rth@redhat.com>

	* emit-rtl.c (set_mem_attributes): Fix size and alignment thinkos
	in ARRAY_REF of DECL_P case.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: mainline bootstrap failure in bitmap.c on sparcv9-sun-solaris2.8

[Richard Henderson]

On Fri, Jul 26, 2002 at 01:42:06PM -0400, John David Anglin wrote:
> > A similar error occurs on hppa-linux near the end of stage2:
> > <http://gcc.gnu.org/ml/gcc/2002-07/msg01238.html>.
> 
> The following patch appears to be the origin of the bootstrap failure
> under hppa-linux:
> 
> 2002-07-25  Richard Henderson  <rth@redhat.com>
> 
> 	* emit-rtl.c (set_mem_attributes): Fix size and alignment thinkos
> 	in ARRAY_REF of DECL_P case.

Surprising, to say the least, since I can only imagine problems
_without_ that patch, as evidenced by the SH problems it fixed.

If this is a stage2 failure, can you help me out by finding what
bit of stage1 got miscompiled?


r~

Re: mainline bootstrap failure in bitmap.c on sparcv9-sun-solaris2.8

[Richard Henderson]

On Fri, Jul 26, 2002 at 01:42:06PM -0400, John David Anglin wrote:
> The following patch appears to be the origin of the bootstrap failure
> under hppa-linux:
> 
> 2002-07-25  Richard Henderson  <rth@redhat.com>
> 
> 	* emit-rtl.c (set_mem_attributes): Fix size and alignment thinkos
> 	in ARRAY_REF of DECL_P case.

Please try

  http://gcc.gnu.org/ml/gcc-patches/2002-07/msg01625.html


r~

Re: mainline bootstrap failure in bitmap.c on sparcv9-sun-solaris2.8

[John David Anglin]

> > 2002-07-25  Richard Henderson  <rth@redhat.com>
> > 
> > 	* emit-rtl.c (set_mem_attributes): Fix size and alignment thinkos
> > 	in ARRAY_REF of DECL_P case.
> 
> Please try
> 
>   http://gcc.gnu.org/ml/gcc-patches/2002-07/msg01625.html

Looks promising.  Bootstrap is now into stage3.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: mainline bootstrap failure in bitmap.c on sparcv9-sun-solaris2.8

[John David Anglin]

> On Fri, Jul 26, 2002 at 01:42:06PM -0400, John David Anglin wrote:
> > The following patch appears to be the origin of the bootstrap failure
> > under hppa-linux:
> > 
> > 2002-07-25  Richard Henderson  <rth@redhat.com>
> > 
> > 	* emit-rtl.c (set_mem_attributes): Fix size and alignment thinkos
> > 	in ARRAY_REF of DECL_P case.
> 
> Please try
> 
>   http://gcc.gnu.org/ml/gcc-patches/2002-07/msg01625.html

Problem fixed.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: gcc 3.2's cpp breaks configure scripts

[John David Anglin]

> > Turning the warning off is not the correct solution, although there
> > may be some circumstances in which it is emitted when it shouldn't
> > be.
> 
> I think so... but I am probably wrong hehe...

You can display the include search order with "gcc -v -E".  The situation
where gcc emits the message when it shouldn't is when a user include directory
is specified and it is the same as the first directory searched by gcc.
For example,

gcc -v -E main.c -I/opt/gnu/include
...
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory "/opt/gnu/hppa2.0w-hp-hpux11.00/include"
cpp0: warning: changing search order for system directory "/opt/gnu/include"
cpp0: warning:   as it has already been specified as a non-system directory
ignoring duplicate directory "/opt/gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /opt/gnu/include
 /opt/gnu/lib/gcc-lib/hppa2.0w-hp-hpux11.00/3.1.1/include
 /usr/include
End of search list.

As can be seen, the search order hasn't really changed.  If "-I/usr/include"
were added to the command, the search order would really have changed.

These are rules under which the macro lib-prefix.m4 used by configure
in textutils-2.1 adds include directories to CPPFLAGS:

    dnl Potentially add $additional_includedir to $CPPFLAGS.
    dnl But don't add it
    dnl   1. if it's the standard /usr/include,
    dnl   2. if it's already present in $CPPFLAGS,
    dnl   3. if it's /usr/local/include and we are using GCC on Linux,
    dnl   4. if it doesn't exist as a directory.

"/opt/gnu" is my standard prefix.  As can be seen, the above macro
will add "-I/opt/gnu/include" to CPPFLAGS and cause a gcc warning
if something interesting is found there (e.g., libintl.h).

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: soft-float support

[Graeme Peterson]

This got it working.  I also had to add:

  # Do not build libgcc1.
  LIBGCC1 =
  CROSS_LIBGCC1 =

Thanks, all.
GP

> 
> I dug a little and found this, which I copied from t-rs6000:
> 
>    LIB2FUNCS_EXTRA = fp-bit.c dp-bit.c tramp.S
>   
>    dp-bit.c: $(srcdir)/config/fp-bit.c
>          cat $(srcdir)/config/fp-bit.c > dp-bit.c
>   
>    fp-bit.c: $(srcdir)/config/fp-bit.c
>          echo '#define FLOAT' > fp-bit.c
>          cat $(srcdir)/config/fp-bit.c >> fp-bit.c
> 
> I'm building it now, but the comment at the top of fp-bit.c
> seems promising: 
> 
> "/* This is a software floating point library which can be used instead of
>    the floating point routines in libgcc1.c for targets without hardware
>    floating point. */ "
> 
> Think that might be it?  :-)
> 
> GP
> 
> > 
> > Graeme Peterson writes:
> >  > Hi, all.
> >  > 
> >  > I have done some searching, and it seems that gcc (in this case 
> >  > 2.95.3 targetting ppc-QNX6) does not have support for statically
> >  > linked software emulated floating point instructions.
> >  > 
> >  > Can someone clarify for me what is required to get this going?  Do 
> >  > I need to implement the floating point emulation and tell gcc to 
> >  > use it in place of the fadd in the __adddf3 call?  If so, how do I
> >  > do that?
> > 
> > You need to specify the multilibs in your target file for qnx.
> > 
> > For example, in the current gcc source, gcc/config/rs6000/t-rs6000
> > contains
> > 
> > MULTILIB_OPTIONS = msoft-float
> > MULTILIB_DIRNAMES = soft-float
> > 
> > Andrew.
> > 
> 
> 

Re: gcc-64 20021111 broken on HP-UX 11.00

[John David Anglin]

> > ldd: "gengenrtl" is not a shared executable.
> > collect2: /usr/ccs/bin/ldd returned 1 exit status
> 
> I have installed the patch below and it should fix the above problem.

I forgot to say it was tested with both HP and GNU ld on hppa64-hp-hpux11.11.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: HP-UX IA64 Patch to fix earlier patch

[John David Anglin]

> > I am working on using the PARALLEL method for IA64 they way you did on
> > PA64 so we can get rid of FUNCTION_ARG_REG_LITTLE_ENDIAN and noticed
> > that on PA64 you use it in function_arg to handle arguments but there is
> > nothing to handle function return values and I think we need it there
> > too to handle returns of small structures.
> 
> You are correct, PA64 GCC incorrectly returns small structs.  I will
> try and see if I can detemine what is wrong with your patch.

There is a problem with using the PARALLEL method for function
values and sjlj exception handling.  After a lot of C++ debugging, I
have determined why g++.robertl/eb21.C fails with the patch that
I have to return a PARALLEL.

The function _ZSt24__uninitialized_copy_auxIN9........ is miscompiled.
It returns a small structure in register %r28.  The return value is output
by expand_value_return at insn 88 followed by a jump to label 162.
However, after code_label 162, we have a call to _Unwind_SjLj_Unregister
which clobbers the return value %r28.  It would also clobber any
value in the other return register %r29.

The call to _Unwind_SjLj_Unregister obviously has to occur before
the return value is copied to the return registers but I am not sure
how to do this.  I am not sure why this isn't a problem when we don't
use a PARALLEL.  There is a bug in cfg.c that causes an ICE when
dumping rtl.  The global max_regno is not always in sync with the
number of pseudos.  I need to rebuild gcc with this fixed before
I can compare what happens without PARALLEL function values.

The rtl from the first jump pass is enclosed below.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

begin 640 eb21.jump.gz
M'XL(")6PWCT``V5B,C$N:G5M<`#M7'MOW+@1_]^?@@AZ0'QU$I%Z44Y;-(^]
MJQ'#R7D=H&U@"/N0[;VNI3U)ZR17]+MWAI)V)2U%2NO5>7/G%#TD*W+F-^2\
M1>KE2_+#,IRDLR@D_@]1_'D43T_2("9).CT^]OUE.`MGZ6PTG_T:3/U)M/CJ
MCY9?GOHGX6*9XL`C4OE[B03\R[\:S9/`3[\N@D/RZ?,LO2F-)G^%`=?ATI]\
M^8*LPBB^'<W]&3P:I5'\ETD4AH%`YJ??'V6`[N"'VJ/\R6@^CR8;\_Y&X']5
M6+\9V\N#`VI0$@?7LP2()\\/#L[SOQ/'(<LDF!)*TMEMD)#1)(Z2A!AD%B9A
M\I(D09H_>TFF,Q@P"^'A8CZ:!/#T[+U_/OAQ2**8A%$(0Q;1+`2R%0YNQH$I
M..3/6K"H4.;WP4[)^&NJX^#M<'7*A%VC[V5W:5_065^$S;X(6WT1MOLBO$NK
MK!#NS1C=>QFCBG!?-LAW:8,5PGV9'N_+]'A?IL>MOO2-W\OVK!;.G[N]<[B7
MS;3BX.UR_:6!QNO+C+Q=FI$<.NM+.[U=&I0<^RZ#FIS#+J.;G$/OR:?7NPU[
MNXQ[<AEV&0"E'*C15SI*(<L>);,)&4-U\I_DB%";!-/K`&N0U^L'Q#@F5[,X
M205#0AW[B,Q'\$_&CL@B#N[(,WI$PN`+P(`G4;3PI\$"BCCCB$RB99CB7Z[B
MX!=B/#_X$`?3`(`E49P<$S(XNSC_%WD*!>`\O8F7AP?#Y63]E):?%`N2D/GL
M+B"C%$JK49P>DZ?A;"Y['(33XN%)>`>UZ90DRUL279%HF5[#*EP#^F@\&L_F
M4+O"NAG/C>^JDM.*Y";-!3>=7'`CEYMUE=N"'6J2FI6>$$Z>CL9'H_$$?CD*
M;AYF&5A-`=QB';Q\'8K]-[NN`VU<!;.\"M:#B&W6Q.:YV):1B\URL:VN8K-&
ML>T'D=2J2&JQ7%"WV%\S%]3N+&C-H!]$.KLB'2^DXX5T5BZ=TU4ZLR:=\2#B
M.54UY68N'Z6%@'8NH-M50%X5T-T[S^1697>M0G9FY[([N>R\J^Q.HXWNA>2\
M(CEC3A&45\')S27WNDKNUN3#I:C^0.LK4%D?KZPFSH.LCE?3BV)UJ%?X;EZD
M+$9GHVA2C'M)6LT[ZBE7X;.H8^7XO1S_L\ZYAUW=K<$_3RX>(L\Z.$CCKWZT
M@,1U]FO@3ZZN2=9=QY<,].`@;\;C=$Q*"7OV-Y.D$;')U6@V#Z;/#YZ&40J_
M0RH%.2DDNA<#_^1L>.:_'9P.+@9O84VS$?B4$6:Y,/+3>$R,R]+@UZ^&)V_\
MUZ?OW[S#"9DUP5"<9,($H_:'/,5\^VD<7!^_/2$N/3P@^9_B-^:2[V+F'AY"
M7IROBWB,?UNQ,`432\G@Q162<YP2B\5\F>"/Z\?,0V[>>HP8-XG")/4AT2?/
M'(M\,KY<5?Y,C,M#P$=MC_SW^\7H^>WTV.2V^[]&N!8`MIO!W@:W+VJX`#;P
MQ9<[J,=_-LB0DU>.=2E9+P<E<-3K90,$IPV`S14J+Z!D@3@N#X?UR."BF2G1
MVHC65J-U`*_;"UKJ(%QJK/#&0;*<JQ%;B-A2(W8!,]>JN^-*R)M(WE23Y\#`
MZT9^E-S,KE)P//GRU`?4%L86"V-RH=@*)!Y@H88:RD_`B9>@9/OUTS;[Q83U
MT5R_<)LH>27^I<`(^#Q(WYI!_AK$D0_>/QY-LO5)EN-\B4H"$*-QM0JE;[&:
M&QON:%P;``<!*-/I_T[7LXHRD[\)9184&`)E!IKI.AK\\/'LS<7)>P@+@Q_7
MX0`&P7!FJ`TDP\^]!G==#@W59;^97=]DN_CU=AS-P:2O7BS%#T^^/_W3&V#"
MGAP>:O0:T2%09JCM3((2MR/C-X]\"-W5#>&>9$.68;(()OCXT\;#U2"E.-)I
MEZ"RPJ\5SDPCLI>)K;-GX.T9=8$SZ2IRMN<,'`5WE9$"EP8?CQ[35*JYRU#-
MK2(L-?IV#]>+4KX.XXR;S6$<\0KL*NLL2+-=*/)JWT^';U]1E[LM-!EM30#5
MYU\5D$UZ7!^XK1;+9-F%&H.<F<QMTD%/DG&"<'4.P9=%[,\A4S\^'_SH#W[Z
M^.JTM2@9O!(^*\>HS@"W5G9NH++;ADK95\)W4W<[0V^U\=R>V:#PC7*491`1
MU>8=\VI$EJ%4)+=KA$VQI0W"4N:H44<GAZ7.8*N\8?%T>^=UW#LW@T);[9U=
M8CD?C8.5EC-)98$,UL9Q^NKUX!3';2H^SV&T":F>)95ZLU*0FN8&YF9K]#)@
M3!'TFJW1TYABN1A2;::FG$!T`BG;*D!J4-:*(`5.TT";,'1@:0:8J:-BCDU=
MCZN-L)2^=G(3@"Q#J0^)13DMVS5-D8WD,U9M(M%&YT&V&OGZ-W8GLJVL=B>N
M.G0GL`/IY^"M7`!YF%J,8A@;S&NQ7E#(='%83<'OLB#Y=_]C^'D63OWASZ<_
M^T7[ZTFN>A9Y9;)+I;9F#1C+N#RL+\,\&H^#.-LY8$YAK:AN$,-%KP]:)D&9
MHXBG%7Z7&B?T#WQ)#'6/C$K-$]7FY\SKO:_U),G(JO[49&FB7'2)-I<Z<Y!E
M-;8S;5#XGJ8\MM38TT3)G`VPX$C7!+T-1HXS#>I-C7JIU5OG1V/;B-DTFO&J
ML.F3N`UXDV6LZDHYK=,!4:Z;Z)Z)24NU^NG[]Q^*.GT230-?Q%`<8V)'V`%[
M<BAY\H1\$F>5DLM20]@1PQ@,P88PU36$<202]#C,:-[N;*U<0^D2Z]LLB[[J
M_@J@0$">!V`4Z@W.@I?3HE(40CYL4V&DF<GFM*;41"!"<&8SL,+/;J-B9@9@
M%?;KOK<D]2$>XBXT"PR5-L=61`O`34NYM9K(ZF@B*U`'/J:MYY&WER4\7$T:
M`]21C=-"1?<L=`-F7!K'E4)O"MR59>,H$)>ICS:\__O,6UWU"(.3#Y25+VD,
M4R>[UW$RI/YPA/\=P)_Q^;NSH4_=C9LA)Q?^A0%#AJ]]78Y06]!2GO!M)0I4
M>/Z]212*%S2;NM`YM5@+D^<7>?APA<JZZ!$A?#!M^'"S.5"UZ<Q_VWP$:`,7
MT]-R<-DF\<)ZFCC\O+Q=Y);J(2?J*"193$H,9E=^>A.$?C#']0Z#U9N*X4D9
M$;&4CG]33<6`5<U,K%IW#T%HVO\@`@AC&1!W<`]-Q1ZNQ;<,,=&"W*&5^&N$
M?+-%5^`9C^)X!H8+5($^BE+)9RR&3ZCCX1M0JR&?\7"8#02$,)9.(>V,H`VD
M.\>\>_6=VI>\MI#'-I4(]S*:`68$;TF1]Q7,7LS6X>S=.I[)`E2K`#<-!G=_
ME/CUS1:ZH&.H;+;>BK<-*T`;F3A:#J[9/:QD'!S!Q-W"$[7.OH$ZLN'?H"_A
M`KSWZ$M68QY]23^^Q$-E<XS^?`G0!B8.U?L2:TM?`K2!B;--5K-V8VH.3#!1
M9R6-=7PNG)J#*9C(LX>]]E6`&<'+HU'W[GO)"PU3:OAO$'.\G*0G-9\#U?;=
MAPO__!W4W8]M^=]3M9VIE2TTJT6"L(5C$N43T`8F+CJF6G?YS?NSB_4128HC
MW2V]2[M,!:@#&_<;K'H`,X)_N*IG!XG*8O&8J%3G[V&B`BJ&NM9CT0.TD8F^
MZ'FPY@A@0Y!JG[B?;L(5X.6EV*.;>'03C>.[N@DN=$U>.=_73:P[PL``.'%%
MV=30$#:;J1<-8:`*Y#E=)2H<7X_AAV9J:<K@[&VM:0QC8#"%7,+&<D+:-(:'
M.`SOJF#3V-8UC6&DF./"!$T!5ZY[>CU6T.5$(0`'$3C7PY<5AIH;/T`6Z7M:
MXAO^J\15KV[``#AY1C.;!G6CCOX%!)`%^I2;-66"7_`9LZ`NQ?14IDWX4(QS
M8`RJDZ-0)YSQ(L&Q8IH!B342W;C!EQ_-Q!,3JYLQ%*=1`Z%L6^/K[J\8&29J
MF$HF>QE?$70F@"4%W_?+=`BL(W\<7,]"?S)*)S>/<7+/XR0JBE`:VL*DMLVH
MD;A@1-4F)6AMWKQ[B/-R"%7`IG)#JD!N>\3O-XUWB!RE8"V<)3<DFZKIMB)=
MY,&$G]0<1"LKS>;)D8X'T1H.G)20F3DZNQG9;W(2S>UR$@WA,F&*SO;1C6M.
MB2%Q9$2IJ]<*R5TCU]/1=W,>7"]$4Y.<:_T)SQEYWV"(IEXF@-LM1+=LE7/_
M;9"D<?3U9.M:EXE:EXF#;H.["W_(_PB-=5-<>=Z;$-[_,3;7RG2109TI<G97
M5P+B4#&-63"EKV2!61DC9BN9[*=Q`^A,`%<*?OM;*"*SCH/T)HX^_R&ML3KI
M[/WYX.+CN3H)+RE^WV:<FU>IG$85H.*.B%,MJ*'TQ=N&^)Q9-GX;(^O0L(V:
M6DR&_[MX-0`,E&N_7)/39%##<4GF4Q4E2W0TUT9X3M23$JPH"))$-5+TMO);
MKUY.6$ZT:N'44%^H4'?85;:ME-O+8(+OT$.L0:AB[W3K5=QS0;94OG_BQKI_
M%\U'Z6P>;'B1YKL:>"==*3!P%-PAMU4)?"_7CL0S1J:4R2BY!?2+);!Z\D1'
MRLS)66J\X+6\,M0>\OX..3["S:#;VF5VZ["W+2HMX1A9_5YO-\6T<^R.%C>W
M=H5;7(@RZ_=\6^)>=TT1-`I`&ZQ*=VX]^$6J2A+$JX*V:I>E/BRONRK=476(
M%E28#+;?U7U2MY3;.6(6!57S1.CPM+D=7H02TRS\2!*N3'-A*+E$H&VKX@TK
MY`$;H:4O.4W*-0>GJ-A@;$>H\>]1VI@W*ZP<NX.?R)(K9Z_-"DGJULJAE;)>
M-#`AARM=^WMFO4$X;==-_AWDO1GLW[P*7:>O^8:Z8E.IR;7&NGVAAU>)!"-/
MR\25T%?<J<GI>QD/R]1[',F94]Z<&Q>.V3(%%V:@3U.Y9J]D[[:8QPR%O1?]
M0RXUTV=4XG>N.K=1F\@TMU6=##V^@GS0MBKOU%;E7$"GW%,O^+U>&HHWIQP_
M,*MDLD?1I^2^`;00P&-2\+OZ=$:RO`U^7RZ\51?B&W@5N.I9>"S3!L<HW2XT
MLM\=)OM2XL;A$_2+#LNF<7SOAX?R9?T-\=3!$L[%4>)+#/IO\^)@CI.R[WAJ
M+,WC:B-3]@ZV_5H/7O3%V\$8?^[SN1[="SB,/,@+KZ5^>]_KL8Q,`HO*T>_&
MZWP,X\=/]B@=Q#Z<0D`E$&KL6"U,9NN$T[$$)V$NE7PPL(P:=O5]H_\#OB3Y
%CA%U``!/
`
end

Re: Setting LD tool default to ld breaks configure check for ld used by GCC

[John David Anglin]

> The toplevel configure script sets "LD=ld".  The ld used by the GCC check
> in the opcodes directory has the line 
> 
>   test -z "$LD" && LD="$ac_prog"

The above line comes from libtool.m4.  If we set LD="" in the toplevel
configure script, the libtool script then sets LD to ld program used by
GCC.  However, this define for LD isn't a proper default.  So, I am
wondering if the libtool script should also reset LD when LD=ld?

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: Setting LD tool default to ld breaks configure check for ld used by GCC

[John David Anglin]

> > The toplevel configure script sets "LD=ld".  The ld used by the GCC check
> > in the opcodes directory has the line 
> > 
> >   test -z "$LD" && LD="$ac_prog"
> 
> The above line comes from libtool.m4.  If we set LD="" in the toplevel
> configure script, the libtool script then sets LD to ld program used by
> GCC.  However, this define for LD isn't a proper default.  So, I am
> wondering if the libtool script should also reset LD when LD=ld?

After some discussion of this matter on the libtool list, the conclusion
is that Cygnus configure shouldn't be setting LD and other similar defines
in native builds.  PR 9031 has more details.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: Miscompilation of glibc with CVS mainline

[John David Anglin]

> > > Here's a small testcase that has the same behaviour:
> > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > extern void weak_func (void *arg);
> > > asm (".weak weak_func");
> > > 
> > > void
> > > test (void *arg)
> > > {
> > >   if (&weak_func != (void *)0)
> > >     weak_func (arg);
> > >   
> > > }
> > 
> > As GCC is not told in any way that weak_func is actually weak, I think
> > it is glibc's fault.
> 
> This is definitely a gcc problem.  This is the code arising from
> Andreas' testcase for hppa-linux at -O2:
> 
>         stw %r2,-20(%r30)
> 	ldo 64(%r30),%r30
> 	ldw -84(%r30),%r2
> 	bl weak_func,%r0
> 	ldo -64(%r30),%r30
> 
> We have completely lost the `if'.  As a result, weak_func is always
> called.

There is another problem.  The call to weak_func has been turned into
a sibcall.  It seems that TARGET_FUNCTION_OK_FOR_SIBCALL isn't being
consulted as we don't allow indirect sibcalls on hppa-linux.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: Miscompilation of glibc with CVS mainline

[Jakub Jelinek]

On Thu, Jan 02, 2003 at 12:48:23PM -0500, John David Anglin wrote:
> There is another problem.  The call to weak_func has been turned into
> a sibcall.  It seems that TARGET_FUNCTION_OK_FOR_SIBCALL isn't being
> consulted as we don't allow indirect sibcalls on hppa-linux.

The call is not indirect, it is normal direct call
(even if weak_func is marked __attribute__((weak)) or #pragma weak).

	Jakub

Re: Miscompilation of glibc with CVS mainline

[John David Anglin]

> The call is not indirect, it is normal direct call
> (even if weak_func is marked __attribute__((weak)) or #pragma weak).

Sorry, for the net garbage.  My original analysis of the glibc problem
involved an indirect call.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: Miscompilation of glibc with CVS mainline

[Daniel Jacobowitz]

On Thu, Jan 02, 2003 at 12:48:23PM -0500, John David Anglin wrote:
> > > > Here's a small testcase that has the same behaviour:
> > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > extern void weak_func (void *arg);
> > > > asm (".weak weak_func");
> > > > 
> > > > void
> > > > test (void *arg)
> > > > {
> > > >   if (&weak_func != (void *)0)
> > > >     weak_func (arg);
> > > >   
> > > > }
> > > 
> > > As GCC is not told in any way that weak_func is actually weak, I think
> > > it is glibc's fault.
> > 
> > This is definitely a gcc problem.  This is the code arising from
> > Andreas' testcase for hppa-linux at -O2:
> > 
> >         stw %r2,-20(%r30)
> > 	ldo 64(%r30),%r30
> > 	ldw -84(%r30),%r2
> > 	bl weak_func,%r0
> > 	ldo -64(%r30),%r30
> > 
> > We have completely lost the `if'.  As a result, weak_func is always
> > called.
> 
> There is another problem.  The call to weak_func has been turned into
> a sibcall.  It seems that TARGET_FUNCTION_OK_FOR_SIBCALL isn't being
> consulted as we don't allow indirect sibcalls on hppa-linux.

This isn't an indirect call, though.  weak_func is not a pointer...

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: hppa-linux regressions and 3.2.2 release

[John David Anglin]

> I now have tests running on hppa2.0w-hp-hpux11.11, hppa64-hp-hpux11.00
> and hppa-unknown-linux-gnu including the patch set for the other PR from
> Franz Sirl.  I will post the results as soon as available.

The hppa2.0w-hp-hpux11.11 are complete and identical to the previous
run without Franz's patch:

<http://gcc.gnu.org/ml/gcc-testresults/2003-02/msg00130.html>.

I had to restart the hppa64-hp-hpux11.00 run.  I used the HP linker
and it generates a warning on each link.  This totally messes
up the testsuite results.  I would like to apply the following patch
from Steve Ellcey to correct the problem.  It has been on the main and
3.3 since early last October.  The comment describes what it does.  It
only affects hppa64-hp-hpux11* and doesn't affect code generation.

As you are doing preleases, I will wait for your OK.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

2003-02-02  Steve Ellcey  <sje@cup.hp.com>

        * config/pa/pa64-hpux.h (INIT_ENVIRONMENT): New.

Index: config/pa/pa64-hpux.h
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/config/pa/pa64-hpux.h,v
retrieving revision 1.9
diff -u -3 -p -r1.9 pa64-hpux.h
--- config/pa/pa64-hpux.h	21 Jan 2002 21:22:19 -0000	1.9
+++ config/pa/pa64-hpux.h	3 Feb 2003 04:38:07 -0000
@@ -232,3 +232,8 @@ do {								\
 #ifndef ASM_DECLARE_RESULT
 #define ASM_DECLARE_RESULT(FILE, RESULT)
 #endif
+
+/* If using HP ld do not call pxdb.  Use size as a program that does nothing
+   and returns 0.  /bin/true cannot be used because it is a script without
+   an interpreter.  */
+#define INIT_ENVIRONMENT "LD_PXDB=/usr/ccs/bin/size"

Re: hppa-linux regressions and 3.2.2 release

[Gabriel Dos Reis]

"John David Anglin" <dave@hiauly1.hia.nrc.ca> writes:

[...]

| As you are doing preleases, I will wait for your OK.

It is OK.

Thanks,

-- Gaby

Re: hppa-linux regressions and 3.2.2 release

[John David Anglin]

> > I now have tests running on hppa2.0w-hp-hpux11.11, hppa64-hp-hpux11.00
> > and hppa-unknown-linux-gnu including the patch set for the other PR from
> > Franz Sirl.  I will post the results as soon as available.
> 
> The hppa2.0w-hp-hpux11.11 are complete and identical to the previous
> run without Franz's patch:

All test runs are complete and posted.  There are no regressions.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: hppa-linux regressions and 3.2.2 release

[Gabriel Dos Reis]

"John David Anglin" <dave@hiauly1.hia.nrc.ca> writes:

| > > I now have tests running on hppa2.0w-hp-hpux11.11, hppa64-hp-hpux11.00
| > > and hppa-unknown-linux-gnu including the patch set for the other PR from
| > > Franz Sirl.  I will post the results as soon as available.
| > 
| > The hppa2.0w-hp-hpux11.11 are complete and identical to the previous
| > run without Franz's patch:
| 
| All test runs are complete and posted.  There are no regressions.

Thanks for the report.  Please commit the set of patches you tested.

This hopefully will be the last patch to commit.

-- Gaby

Re: hppa-linux regressions and 3.2.2 release

[John David Anglin]

> Thanks for the report.  Please commit the set of patches you tested.

Done.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: Bootstrap failure on hppa-unknown-linux-gnu, trunk

[John David Anglin]

> stage1/xgcc -Bstage1/ -B/home/dave/opt/gnu/hppa-linux/bin/ -c   -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long -fno-common -Werror   -DHAVE_CONFIG_H    -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/config -I../../gcc/gcc/../include
> ../../gcc/gcc/bb-reorder.c -o bb-reorder.o
> ../../gcc/gcc/bb-reorder.c: In function `find_traces':
> ../../gcc/gcc/bb-reorder.c:219: error: unrecognizable insn:
> (insn 776 775 777 0x40568f60 (set (reg:DI 70 %fr23 [252])
> 	(mult:DI (zero_extend:DI (reg:SI 69 %fr22R [246]))
> 	    (reg:DI 74 %fr25))) -1 (nil)
>    (expr_list:REG_UNUSED (reg:SI 71 %fr23R)
> 	(expr_list:REG_DEAD (reg:DI 74 %fr25)
> 	    (nil))))
> ../../gcc/gcc/bb-reorder.c:219: internal compiler error: in num_delay_slots, at insn-attrtab.c:4085

I have determined that it is the addition of this patch that results in
the above ICE:

2003-02-10  Josef Zlomek  <zlomekj@suse.cz>

	* Makefile.in (bb-reorder.o): Add dependency on $(FIBHEAP_H).
	* bb-reorder.c (make_reorder_chain): Deleted.
	(make_reorder_chain_1): Deleted.
	(find_traces): New function.
	(rotate_loop): New function.
	(mark_bb_visited): New function.
	(find_traces_1_round): New function.
	(copy_bb): New function.
	(bb_to_key): New function.
	(better_edge_p): New function.
	(connect_traces): New function.
	(copy_bb_p): New function.
	(get_uncond_jump_length): New function.
	(reorder_basic_blocks): Use new functions (Software Trace Cache).
	* cfgcleanup.c (outgoing_edges_match): Enable crossjumping across loop
	boundaries.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: Bootstrap failure on hppa-unknown-linux-gnu, trunk

[Josef Zlomek]

> > stage1/xgcc -Bstage1/ -B/home/dave/opt/gnu/hppa-linux/bin/ -c   -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long -fno-common -Werror   -DHAVE_CONFIG_H    -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/config -I../../gcc/gcc/../include
> > ../../gcc/gcc/bb-reorder.c -o bb-reorder.o
> > ../../gcc/gcc/bb-reorder.c: In function `find_traces':
> > ../../gcc/gcc/bb-reorder.c:219: error: unrecognizable insn:
> > (insn 776 775 777 0x40568f60 (set (reg:DI 70 %fr23 [252])
> > 	(mult:DI (zero_extend:DI (reg:SI 69 %fr22R [246]))
> > 	    (reg:DI 74 %fr25))) -1 (nil)
> >    (expr_list:REG_UNUSED (reg:SI 71 %fr23R)
> > 	(expr_list:REG_DEAD (reg:DI 74 %fr25)
> > 	    (nil))))
> > ../../gcc/gcc/bb-reorder.c:219: internal compiler error: in num_delay_slots, at insn-attrtab.c:4085
> 
> I have determined that it is the addition of this patch that results in
> the above ICE:
> 
> 2003-02-10  Josef Zlomek  <zlomekj@suse.cz>
> 
> 	* Makefile.in (bb-reorder.o): Add dependency on $(FIBHEAP_H).
> 	* bb-reorder.c (make_reorder_chain): Deleted.
> 	(make_reorder_chain_1): Deleted.
> 	(find_traces): New function.
> 	(rotate_loop): New function.
> 	(mark_bb_visited): New function.
> 	(find_traces_1_round): New function.
> 	(copy_bb): New function.
> 	(bb_to_key): New function.
> 	(better_edge_p): New function.
> 	(connect_traces): New function.
> 	(copy_bb_p): New function.
> 	(get_uncond_jump_length): New function.
> 	(reorder_basic_blocks): Use new functions (Software Trace Cache).
> 	* cfgcleanup.c (outgoing_edges_match): Enable crossjumping across loop
> 	boundaries.

I apologize for the breakage. It seems that new bb-reorder has uncovered
bugs in machine descriptions.
Honza Hubicka has checked in a patch
(http://gcc.gnu.org/ml/gcc-patches/2003-02/msg00847.html)
which hopefully should enable gcc to bootstrap again.

Josef

Re: Bootstrap failure on hppa-unknown-linux-gnu, trunk

[John David Anglin]

> > > stage1/xgcc -Bstage1/ -B/home/dave/opt/gnu/hppa-linux/bin/ -c   -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long -fno-common -Werror   -DHAVE_CONFIG_H    -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/config -I../../gcc/gcc/../include
> > > ../../gcc/gcc/bb-reorder.c -o bb-reorder.o
> > > ../../gcc/gcc/bb-reorder.c: In function `find_traces':
> > > ../../gcc/gcc/bb-reorder.c:219: error: unrecognizable insn:
> > > (insn 776 775 777 0x40568f60 (set (reg:DI 70 %fr23 [252])
> > > 	(mult:DI (zero_extend:DI (reg:SI 69 %fr22R [246]))
> > > 	    (reg:DI 74 %fr25))) -1 (nil)
> > >    (expr_list:REG_UNUSED (reg:SI 71 %fr23R)
> > > 	(expr_list:REG_DEAD (reg:DI 74 %fr25)
> > > 	    (nil))))
> > > ../../gcc/gcc/bb-reorder.c:219: internal compiler error: in num_delay_slots, at insn-attrtab.c:4085
> > 
> > I have determined that it is the addition of this patch that results in
> > the above ICE:
> > 
> > 2003-02-10  Josef Zlomek  <zlomekj@suse.cz>
> > 
> > 	* Makefile.in (bb-reorder.o): Add dependency on $(FIBHEAP_H).
> > 	* bb-reorder.c (make_reorder_chain): Deleted.
> > 	(make_reorder_chain_1): Deleted.
> > 	(find_traces): New function.
> > 	(rotate_loop): New function.
> > 	(mark_bb_visited): New function.
> > 	(find_traces_1_round): New function.
> > 	(copy_bb): New function.
> > 	(bb_to_key): New function.
> > 	(better_edge_p): New function.
> > 	(connect_traces): New function.
> > 	(copy_bb_p): New function.
> > 	(get_uncond_jump_length): New function.
> > 	(reorder_basic_blocks): Use new functions (Software Trace Cache).
> > 	* cfgcleanup.c (outgoing_edges_match): Enable crossjumping across loop
> > 	boundaries.
> 
> I apologize for the breakage. It seems that new bb-reorder has uncovered
> bugs in machine descriptions.
> Honza Hubicka has checked in a patch
> (http://gcc.gnu.org/ml/gcc-patches/2003-02/msg00847.html)
> which hopefully should enable gcc to bootstrap again.

I have been looking at the patterns which use the xmpyu insn on the PA.
There are two patterns (32 and 64 bit) which have an uint32_operand
predicate and "f" constraint.  The "f" constraint is inconsistent with
the predicate.  The uint32_operand predicate is inconsistent with the
actual capability of the machine instruction.  I had queried Jeff Law
about this in the past.  This was his response:

   > I thought changing the operands of the pattern to register_operand is a more
   > accurate description of the machine insn although reloads still can
   > potentially occur.
     It's certainly more accurate, but due to secondary effects of register
     allocation
     and reloading it's actually more profitable to be more general in the
     operand predicates than what the instruction actually allows.  That is
     generally a bad thing to do, but from time to time it is helpful.

Basically, some games are being played with the predicate and constraint
to improve the generated code.

The 32-bit seems to be building again.  However, the have been some
"strange" warning messages on hppa64-hp-hpux11.11:

g-yacc.29398.c: In function `yystrlen':
g-yacc.29398.c:708: warning: traditional C rejects ISO C style function definiti
ons
g-yacc.29398.c: In function `yystpcpy':
g-yacc.29398.c:733: warning: traditional C rejects ISO C style function definiti
ons
g-yacc.29398.c: In function `yydestruct':
g-yacc.29398.c:800: warning: traditional C rejects ISO C style function definiti
ons
g-yacc.29398.c: In function `yyparse':
g-yacc.29398.c:863: warning: traditional C rejects ISO C style function definiti
ons

and

c-p29635.c: In function `yy_stack_print':
c-p29635.c:2150: warning: traditional C rejects ISO C style function definitions
c-p29635.c: In function `yy_reduce_print':
c-p29635.c:2176: warning: traditional C rejects ISO C style function definitions
c-p29635.c: In function `yysymprint':
c-p29635.c:2297: warning: traditional C rejects ISO C style function definitions
c-p29635.c: In function `yydestruct':
c-p29635.c:2333: warning: traditional C rejects ISO C style function definitions
c-p29635.c: In function `yyparse':
c-p29635.c:2396: warning: traditional C rejects ISO C style function definitions

Possibly, this is a bison 1.875 problem.  Yes, it seems to be.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: Bootstrap failure on hppa-unknown-linux-gnu, trunk

[Josef Zlomek]

> > stage1/xgcc -Bstage1/ -B/home/dave/opt/gnu/hppa-linux/bin/ -c   -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long -fno-common -Werror   -DHAVE_CONFIG_H    -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/config -I../../gcc/gcc/../include
> > ../../gcc/gcc/bb-reorder.c -o bb-reorder.o
> > ../../gcc/gcc/bb-reorder.c: In function `find_traces':
> > ../../gcc/gcc/bb-reorder.c:219: error: unrecognizable insn:
> > (insn 776 775 777 0x40568f60 (set (reg:DI 70 %fr23 [252])
> > 	(mult:DI (zero_extend:DI (reg:SI 69 %fr22R [246]))
> > 	    (reg:DI 74 %fr25))) -1 (nil)
> >    (expr_list:REG_UNUSED (reg:SI 71 %fr23R)
> > 	(expr_list:REG_DEAD (reg:DI 74 %fr25)
> > 	    (nil))))
> > ../../gcc/gcc/bb-reorder.c:219: internal compiler error: in num_delay_slots, at insn-attrtab.c:4085
> 
> I have determined that it is the addition of this patch that results in
> the above ICE:

Maybe it is a similar problem in machine descriptions as alpha and sh did
have (http://gcc.gnu.org/ml/gcc-patches/2003-02/msg01295.html). But maybe I'm wrong.
The bb-reorder itself is pretty high level, it is a probably first use
of code duplication functions which went to mainline.
Anyway, I apologize for the breakage.

Josef

> 2003-02-10  Josef Zlomek  <zlomekj@suse.cz>
> 
> 	* Makefile.in (bb-reorder.o): Add dependency on $(FIBHEAP_H).
> 	* bb-reorder.c (make_reorder_chain): Deleted.
> 	(make_reorder_chain_1): Deleted.
> 	(find_traces): New function.
> 	(rotate_loop): New function.
> 	(mark_bb_visited): New function.
> 	(find_traces_1_round): New function.
> 	(copy_bb): New function.
> 	(bb_to_key): New function.
> 	(better_edge_p): New function.
> 	(connect_traces): New function.
> 	(copy_bb_p): New function.
> 	(get_uncond_jump_length): New function.
> 	(reorder_basic_blocks): Use new functions (Software Trace Cache).
> 	* cfgcleanup.c (outgoing_edges_match): Enable crossjumping across loop
> 	boundaries.

Re: Bootstrap failure on hppa-unknown-linux-gnu, trunk

[Josef Zlomek]

> > > stage1/xgcc -Bstage1/ -B/home/dave/opt/gnu/hppa-linux/bin/ -c   -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long -fno-common -Werror   -DHAVE_CONFIG_H    -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/config -I../../gcc/gcc/../include
> > > ../../gcc/gcc/bb-reorder.c -o bb-reorder.o
> > > ../../gcc/gcc/bb-reorder.c: In function `find_traces':
> > > ../../gcc/gcc/bb-reorder.c:219: error: unrecognizable insn:
> > > (insn 776 775 777 0x40568f60 (set (reg:DI 70 %fr23 [252])
> > > 	(mult:DI (zero_extend:DI (reg:SI 69 %fr22R [246]))
> > > 	    (reg:DI 74 %fr25))) -1 (nil)
> > >    (expr_list:REG_UNUSED (reg:SI 71 %fr23R)
> > > 	(expr_list:REG_DEAD (reg:DI 74 %fr25)
> > > 	    (nil))))
> > > ../../gcc/gcc/bb-reorder.c:219: internal compiler error: in num_delay_slots, at insn-attrtab.c:4085
> > 
> > I have determined that it is the addition of this patch that results in
> > the above ICE:
> 
> Maybe it is a similar problem in machine descriptions as alpha and sh did
> have (http://gcc.gnu.org/ml/gcc-patches/2003-02/msg01295.html). But maybe I'm wrong.
> The bb-reorder itself is pretty high level, it is a probably first use
> of code duplication functions which went to mainline.
> Anyway, I apologize for the breakage.

Or there simply is some code in bb-reorder.c which uncovers another bug.

Josef

Re: Altivec + 16 byte alignment

[John David Anglin]

>       /* Ignore alignment we can't do with expected alignment of the
>          boundary.  */
>       if (alignment * BITS_PER_UNIT > PREFERRED_STACK_BOUNDARY)
> 	alignment = PREFERRED_STACK_BOUNDARY / BITS_PER_UNIT;
> 			 
>     but really that's wrong, and at a minimum it should warn the user
>     that their requested alignment isn't going to happen (better would be
>     to just ensure the requested alignment).  We occasionally get bug
>     reports about this, but so far no-one has invested the effort to
>     implement arbitrary stack alignment.
> 
> Now we have *yet another* macro involved in alignment!

Another issue is GCC's alignment attribute is silently ignored for stack
locals and the documentation doesn't say that.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: Altivec + 16 byte alignment

[Mike Stump]

On Tuesday, February 11, 2003, at 11:59 AM, John David Anglin wrote:
>>       /* Ignore alignment we can't do with expected alignment of the
>>          boundary.  */
>>       if (alignment * BITS_PER_UNIT > PREFERRED_STACK_BOUNDARY)
>> 	alignment = PREFERRED_STACK_BOUNDARY / BITS_PER_UNIT;
>> 			
>>     but really that's wrong, and at a minimum it should warn the user
>>     that their requested alignment isn't going to happen (better 
>> would be
>>     to just ensure the requested alignment).  We occasionally get bug
>>     reports about this, but so far no-one has invested the effort to
>>     implement arbitrary stack alignment.
>>
>> Now we have *yet another* macro involved in alignment!
>
> Another issue is GCC's alignment attribute is silently ignored for 
> stack
> locals and the documentation doesn't say that.

Let us agree that this is just a bug, or at least a bug for CPUs that 
have hard requirements of say 16 bytes (Altivec, SSE) and the user asks 
for 16 byte alignment and we silently only do 8 byte alignment.

Re: Altivec + 16 byte alignment

[Fergus Henderson]

On 11-Feb-2003, Mike Stump <mstump@apple.com> wrote:
> On Tuesday, February 11, 2003, at 11:59 AM, John David Anglin wrote:
> > Another issue is GCC's alignment attribute is silently ignored for 
> > stack locals and the documentation doesn't say that.
> 
> Let us agree that this is just a bug, or at least a bug for CPUs that 
> have hard requirements of say 16 bytes (Altivec, SSE) and the user asks 
> for 16 byte alignment and we silently only do 8 byte alignment.

Please let us agree that this is just a bug, regardless of the CPU's
requirements.  The alignment declaration might be used by the programmer
to ensure that the lower bits are available for use as tag bits.

For example, the following program should result in either success
or a compile error (if the requested alignment is not supported).
But IMHO it should not result in an assertion failure.

	#include <assert.h>
	#define ALIGN 32
	int main() {
		char c __attribute__((aligned(ALIGN)));
		assert ((((unsigned long) &c) & (ALIGN - 1)) == 0);
		return 0;
	}

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.

Re: Altivec + 16 byte alignment

[John David Anglin]

> Please let us agree that this is just a bug, regardless of the CPU's
> requirements.  The alignment declaration might be used by the programmer
> to ensure that the lower bits are available for use as tag bits.
> 
> For example, the following program should result in either success
> or a compile error (if the requested alignment is not supported).
> But IMHO it should not result in an assertion failure.
> 
> 	#include <assert.h>
> 	#define ALIGN 32
> 	int main() {
> 		char c __attribute__((aligned(ALIGN)));
> 		assert ((((unsigned long) &c) & (ALIGN - 1)) == 0);
> 		return 0;
> 	}

You have my vote on the matter.

If we go back to Franz's original reply to my post regarding the
rs6000 port, he said "BIGGEST_ALIGNMENT is 128, but STACK_BOUNDARY
is 64 unless you give -mabi=altivec (in 3.2+)."   If you look at
assign_stack_temp_for_type and assign_stack_local_1, you will see
that BLKmode objects are aligned to BIGGEST_ALIGNMENT.  Thus, without
-mabi=altivec, you would randomly get an assertion failure, depending
on the stack alignment, if you checked the alignment of structs with
code similar to that above.  In other words, you aren't getting the
alignment of BLKmode stack locals that you have specified in the
backend.  Possibly, this doesn't matter, but it seems inconsistent
and I think would lead to problems if the compiler checked alignment
requests as suggested above.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: GCC 3.3 Prelease broken on s390

[Ulrich Weigand]

I wrote:

> Interestingly, mainline works fine without any patch.

When your latest mainline patch to unwind-dw2.c is backported 
to 3.3, it works again as well; the patch below does this.

(A full bootstrap/regtest is still running.)

Note that I really only need the first hunk, as the
rest only changes the return value from uw_install_context_1,
which is completely ignored on s390 anyway (as SP is
restored from its stack slot, where the correct new
value was already stored by uw_install_context_1).

What do you think?

Bye,
Ulrich

ChangeLog:

        * unwind-dw2.c (uw_update_context_1): Only set cfa as sp if
        previous frame didn't save sp.  Clear sp for next frame.
        (uw_install_context_1): Honor saved sp from frame.


*** unwind-dw2.c.orig	Wed May  7 02:52:49 2003
--- unwind-dw2.c	Wed May  7 03:00:45 2003
*************** uw_update_context_1 (struct _Unwind_Cont
*** 1059,1069 ****
       In very special situations (such as unwind info for signal return),
       there may be location expressions that use the stack pointer as well.
  
!      Given that other unwind mechanisms generally won't work if you try
!      to represent stack pointer saves and restores directly, we don't
!      bother conditionalizing this at all.  */
!   tmp_sp = (_Unwind_Ptr) context->cfa;
!   orig_context.reg[__builtin_dwarf_sp_column ()] = &tmp_sp;
  
    /* Compute this frame's CFA.  */
    switch (fs->cfa_how)
--- 1059,1075 ----
       In very special situations (such as unwind info for signal return),
       there may be location expressions that use the stack pointer as well.
  
!      Do this conditionally for one frame.  This allows the unwind info
!      for one frame to save a copy of the stack pointer from the previous
!      frame, and be able to use much easier CFA mechanisms to do it.
!      Always zap the saved stack pointer value for the next frame; carrying
!      the value over from one frame to another doesn't make sense.  */
!   if (!orig_context.reg[__builtin_dwarf_sp_column ()])
!     {
!       tmp_sp = (_Unwind_Ptr) context->cfa;
!       orig_context.reg[__builtin_dwarf_sp_column ()] = &tmp_sp;
!     }
!   context->reg[__builtin_dwarf_sp_column ()] = NULL;
  
    /* Compute this frame's CFA.  */
    switch (fs->cfa_how)
*************** uw_install_context_1 (struct _Unwind_Con
*** 1201,1206 ****
--- 1207,1213 ----
  		      struct _Unwind_Context *target)
  {
    long i;
+   void *target_cfa;
  
  #if __GTHREADS
    {
*************** uw_install_context_1 (struct _Unwind_Con
*** 1222,1232 ****
  	memcpy (c, t, dwarf_reg_size_table[i]);
      }
  
    /* We adjust SP by the difference between CURRENT and TARGET's CFA.  */
    if (STACK_GROWS_DOWNWARD)
!     return target->cfa - current->cfa + target->args_size;
    else
!     return current->cfa - target->cfa - target->args_size;
  }
  
  static inline _Unwind_Ptr
--- 1229,1246 ----
  	memcpy (c, t, dwarf_reg_size_table[i]);
      }
  
+   /* If the last frame records a saved stack pointer, use it.  */
+   if (target->reg[__builtin_dwarf_sp_column ()])
+     target_cfa = (void *)(_Unwind_Ptr)
+       _Unwind_GetGR (target, __builtin_dwarf_sp_column ());
+   else
+     target_cfa = target->cfa;
+ 
    /* We adjust SP by the difference between CURRENT and TARGET's CFA.  */
    if (STACK_GROWS_DOWNWARD)
!     return target_cfa - current->cfa + target->args_size;
    else
!     return current->cfa - target_cfa - target->args_size;
  }
  
  static inline _Unwind_Ptr

-- 
  Dr. Ulrich Weigand
  weigand@informatik.uni-erlangen.de

Re: GCC 3.3 Prelease broken on s390

[Richard Henderson]

On Wed, May 07, 2003 at 03:13:39AM +0200, Ulrich Weigand wrote:
> ... which is completely ignored on s390 anyway (as SP is
> restored from its stack slot, where the correct new
> value was already stored by uw_install_context_1).

Ah, now I get it.  This was the piece I couldn't understand.
And if *this* is the case, it means that it doesn't matter
where you place the CFA relative to the stack frame, just so
long as the stack pointer itself is computed properly.

> What do you think?
> 
>         * unwind-dw2.c (uw_update_context_1): Only set cfa as sp if
>         previous frame didn't save sp.  Clear sp for next frame.
>         (uw_install_context_1): Honor saved sp from frame.

If this works, great.


r~

Re: GCC 3.3 Prelease broken on s390

[Mark Mitchell]

> > What do you think?
> > 
> >         * unwind-dw2.c (uw_update_context_1): Only set cfa as sp if
> >         previous frame didn't save sp.  Clear sp for next frame.
> >         (uw_install_context_1): Honor saved sp from frame.
> 
> If this works, great.

Ulrich --

Take that as approval from Richard; if it fixes your problem, please
check it in and close the PR.

Thanks,

-- 
Mark Mitchell <mark@codesourcery.com>
CodeSourcery, LLC

Re: GCC 3.3 Prelease broken on s390

[Ulrich Weigand]

Richard Henderson wrote:

> Ah, now I get it.  This was the piece I couldn't understand.
> And if *this* is the case, it means that it doesn't matter
> where you place the CFA relative to the stack frame, just so
> long as the stack pointer itself is computed properly.

This is what I was thinking, yes.

> >         * unwind-dw2.c (uw_update_context_1): Only set cfa as sp if
> >         previous frame didn't save sp.  Clear sp for next frame.
> >         (uw_install_context_1): Honor saved sp from frame.
> 
> If this works, great.

Unfortunately, while it fixes most of the problems, it is not a
complete solution:
http://gcc.gnu.org/ml/gcc-testresults/2003-05/msg00418.html
http://gcc.gnu.org/ml/gcc-testresults/2003-05/msg00419.html

The Java test case PR218 is still failing.  This is because
this test case throws an exception from a signal handler
through a *leaf* function that was interrupted by the
signal.

When unwinding through the leaf function, there is no CFA code
to restore the stack pointer, because the *correct* behaviour
would have been to reuse the stack pointer from the frame below
(the signal return stub frame) unchanged -- the leaf function
really did not allocate any stack space.

However, this now triggers again the new code that sets the
stack pointer to the cfa, incorrect on s390.

Would you suggest to check the above patch in anyway to make 3.3
more similar to head (apparently the patch is already in 3.2 ...),
and because it fixes at least C++?

Or should we go back to a RUNTIME_SP_CFA_OFFSET solution
on top of the current 3.3 implementation?

What about an alternate target macro that says that this target
handles SP by itself via FDE records, and doesn't need any
other SP fiddling?  This would then allow us to remove the 
unnecessary EH_RETURN_STACKADJ_RTX handling completely.
Maybe this behaviour could actually be triggered by the target
leaving EH_RETURN_STACKADJ_RTX undefined?

If no other solution works for 3.3, we could always fix it
ad-hoc with #ifdef __s390__ ...

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  weigand@informatik.uni-erlangen.de

Re: GCC 3.3 Prelease broken on s390

[Mark Mitchell]

> Unfortunately, while it fixes most of the problems, it is not a
> complete solution:

Bummer.

> Would you suggest to check the above patch in anyway to make 3.3
> more similar to head (apparently the patch is already in 3.2 ...),
> and because it fixes at least C++?

No, that doesn't seem worth it.

> Or should we go back to a RUNTIME_SP_CFA_OFFSET solution
> on top of the current 3.3 implementation?

That seems fine, if it will work.  The key criteria are:

(1) You can do it in such a way that it's obvious it doesn't affect
other platforms.

(2) You can do it quickly.

Engineering beauty is not a consideration at all, in this case.  

#ifdef __s390__ is fine, for example; if you can just do 

  #ifdef __s390__ 
  cfa += 196;
  #endif

that is absolutely fine by me.

If we can't meet those criteria, we may be forced to punt; s390 is not a
primary evaluation platform.  

Please see if you can get this fixed in the next twenty-four hours or
so.

Thanks,

-- 
Mark Mitchell <mark@codesourcery.com>
CodeSourcery, LLC

Re: GCC 3.3 Prelease broken on s390

[Joe Buck]

On Wed, May 07, 2003 at 08:53:40AM -0700, Mark Mitchell wrote:
> Engineering beauty is not a consideration at all, in this case.  
> 
> #ifdef __s390__ is fine, for example; if you can just do 
> 
>   #ifdef __s390__ 
>   cfa += 196;
>   #endif
> 
> that is absolutely fine by me.

If we go for such a solution, I think that it should be a one-release-only
emergency fix, to be replaced ASAP with a better one; seas of #ifdef's
tend to grow if not whacked back.

Re: GCC 3.3 Prelease broken on s390

[Mark Mitchell]

On Wed, 2003-05-07 at 09:01, Joe Buck wrote:
> On Wed, May 07, 2003 at 08:53:40AM -0700, Mark Mitchell wrote:
> > Engineering beauty is not a consideration at all, in this case.  
> > 
> > #ifdef __s390__ is fine, for example; if you can just do 
> > 
> >   #ifdef __s390__ 
> >   cfa += 196;
> >   #endif
> > 
> > that is absolutely fine by me.
> 
> If we go for such a solution, I think that it should be a one-release-only
> emergency fix, to be replaced ASAP with a better one; seas of #ifdef's
> tend to grow if not whacked back.

There's no way something like this will go on the mainline.

If we had to live with this through the 3.3 series, that would be OK;
that is bounded.

-- 
Mark Mitchell <mark@codesourcery.com>
CodeSourcery, LLC

Re: GCC 3.3 Prelease broken on s390

[Ulrich Weigand]

Mark Mitchell wrote:

> That seems fine, if it will work.  The key criteria are:
> 
> (1) You can do it in such a way that it's obvious it doesn't affect
> other platforms.
> 
> (2) You can do it quickly.
> 
> Engineering beauty is not a consideration at all, in this case.  

I can offer the following patch, which passes bootstrap/regtest
on s390-ibm-linux and s390x-ibm-linux and restores both targets
to their previous behaviour in all cases, including that Java
leaf-function test case.  See:
http://gcc.gnu.org/ml/gcc-testresults/2003-05/msg00428.html
http://gcc.gnu.org/ml/gcc-testresults/2003-05/msg00429.html


It should be obvious that it does not affect other platforms;
the hunk in uw_update_context_1 is under #ifdef, and the hunk
in uw_init_context_1 does not affect non-s390 platforms because
for them uw_update_context_1 will immediately undo that change
(never mind that even if it didn't, the change would in fact
be correct for other platforms as well).

I will continue to work on a cleaner solution, but I cannot
guarantee that this will succeed within 24 hours (and I'd
also like to ask for Richard's opinion).  

Do you think we should use the patch below for 3.3?

Bye,
Ulrich


	PR other/10650
	* unwind-dw2.c (uw_update_context_1): Don't set sp as cfa on s390.
	(uw_init_context_1): Set initial sp to outer cfa.

Index: gcc/unwind-dw2.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/unwind-dw2.c,v
retrieving revision 1.22.2.4
diff -c -p -r1.22.2.4 unwind-dw2.c
*** gcc/unwind-dw2.c	5 May 2003 16:59:21 -0000	1.22.2.4
--- gcc/unwind-dw2.c	7 May 2003 14:54:10 -0000
*************** uw_update_context_1 (struct _Unwind_Cont
*** 1062,1069 ****
--- 1062,1071 ----
       Given that other unwind mechanisms generally won't work if you try
       to represent stack pointer saves and restores directly, we don't
       bother conditionalizing this at all.  */
+ #ifndef __s390__
    tmp_sp = (_Unwind_Ptr) context->cfa;
    orig_context.reg[__builtin_dwarf_sp_column ()] = &tmp_sp;
+ #endif
  
    /* Compute this frame's CFA.  */
    switch (fs->cfa_how)
*************** uw_init_context_1 (struct _Unwind_Contex
*** 1164,1169 ****
--- 1166,1172 ----
  
    /* Force the frame state to use the known cfa value.  */
    context->cfa = outer_cfa;
+   context->reg[__builtin_dwarf_sp_column ()] = &outer_cfa;
    fs.cfa_how = CFA_REG_OFFSET;
    fs.cfa_reg = __builtin_dwarf_sp_column ();
    fs.cfa_offset = 0;


-- 
  Dr. Ulrich Weigand
  weigand@informatik.uni-erlangen.de

Re: GCC 3.3 Prelease broken on s390

[Joe Buck]

On Wed, May 07, 2003 at 07:02:49PM +0200, Ulrich Weigand wrote:
> It should be obvious that it does not affect other platforms;
> the hunk in uw_update_context_1 is under #ifdef, and the hunk
> in uw_init_context_1 does not affect non-s390 platforms because
> for them uw_update_context_1 will immediately undo that change
> (never mind that even if it didn't, the change would in fact
> be correct for other platforms as well).

Given the very short time remaining for testing, if you're ifdef'ing
one hunk, you might as well ifdef them both.  The patch would then
have zero risk for other platforms.
 

Re: GCC 3.3 Prelease broken on s390

[Mark Mitchell]

> I will continue to work on a cleaner solution, but I cannot
> guarantee that this will succeed within 24 hours (and I'd
> also like to ask for Richard's opinion).  
> 
> Do you think we should use the patch below for 3.3?

Yes -- but please enclose the second hunk in #ifdef as well.  If we're
going to be ugly, let's not try to be smart while we're being ugly.

Please check this in, and close the PR.

Thanks,

-- 
Mark Mitchell <mark@codesourcery.com>
CodeSourcery, LLC

Re: GCC 3.3 Prelease broken on s390

[Ulrich Weigand]

Mark Mitchell wrote:

> Yes -- but please enclose the second hunk in #ifdef as well.  If we're
> going to be ugly, let's not try to be smart while we're being ugly.

Fine with me.

> Please check this in, and close the PR.

For the record, I've checked in the patch below and closed the PR.

Bye,
Ulrich


Index: gcc/ChangeLog
===================================================================
RCS file: /cvs/gcc/gcc/gcc/ChangeLog,v
retrieving revision 1.16114.2.511
diff -c -p -r1.16114.2.511 ChangeLog
*** gcc/ChangeLog	7 May 2003 06:02:01 -0000	1.16114.2.511
--- gcc/ChangeLog	7 May 2003 19:26:21 -0000
***************
*** 1,3 ****
--- 1,9 ----
+ 2003-05-06  Ulrich Weigand  <uweigand@de.ibm.com>
+ 
+ 	PR other/10650
+ 	* unwind-dw2.c (uw_update_context_1): Don't set sp as cfa on s390.
+ 	(uw_init_context_1): Set initial sp to outer cfa on s390.
+ 
  2003-05-06  Mark Mitchell  <mark@codesourcery.com>
  
  	PR other/10658
Index: gcc/unwind-dw2.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/unwind-dw2.c,v
retrieving revision 1.22.2.4
diff -c -p -r1.22.2.4 unwind-dw2.c
*** gcc/unwind-dw2.c	5 May 2003 16:59:21 -0000	1.22.2.4
--- gcc/unwind-dw2.c	7 May 2003 19:26:21 -0000
*************** uw_update_context_1 (struct _Unwind_Cont
*** 1062,1069 ****
--- 1062,1071 ----
       Given that other unwind mechanisms generally won't work if you try
       to represent stack pointer saves and restores directly, we don't
       bother conditionalizing this at all.  */
+ #ifndef __s390__
    tmp_sp = (_Unwind_Ptr) context->cfa;
    orig_context.reg[__builtin_dwarf_sp_column ()] = &tmp_sp;
+ #endif
  
    /* Compute this frame's CFA.  */
    switch (fs->cfa_how)
*************** uw_init_context_1 (struct _Unwind_Contex
*** 1164,1169 ****
--- 1166,1174 ----
  
    /* Force the frame state to use the known cfa value.  */
    context->cfa = outer_cfa;
+ #ifdef __s390__
+   context->reg[__builtin_dwarf_sp_column ()] = &outer_cfa;
+ #endif
    fs.cfa_how = CFA_REG_OFFSET;
    fs.cfa_reg = __builtin_dwarf_sp_column ();
    fs.cfa_offset = 0;


-- 
  Dr. Ulrich Weigand
  weigand@informatik.uni-erlangen.de

Re: GCC 3.3 Prelease broken on s390

[Mark Mitchell]

On Wed, 2003-05-07 at 12:39, Ulrich Weigand wrote:
> Mark Mitchell wrote:
> 
> > Yes -- but please enclose the second hunk in #ifdef as well.  If we're
> > going to be ugly, let's not try to be smart while we're being ugly.
> 
> Fine with me.
> 
> > Please check this in, and close the PR.
> 
> For the record, I've checked in the patch below and closed the PR.

Thanks!

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com

Re: GCC 3.3 Prelease broken on s390

[Jonathan Lennox]

Ulrich Weigand writes:
> + #ifndef __s390__
>     tmp_sp = (_Unwind_Ptr) context->cfa;
>     orig_context.reg[__builtin_dwarf_sp_column ()] = &tmp_sp;
> + #endif

Doesn't __s390__ indicate the build system, not the target?

-- 
Jonathan Lennox
lennox@cs.columbia.edu

Re: GCC 3.3 Prelease broken on s390

[Mark Mitchell]

On Wed, 2003-05-07 at 11:19, Jonathan Lennox wrote:
> Ulrich Weigand writes:
> > + #ifndef __s390__
> >     tmp_sp = (_Unwind_Ptr) context->cfa;
> >     orig_context.reg[__builtin_dwarf_sp_column ()] = &tmp_sp;
> > + #endif
> 
> Doesn't __s390__ indicate the build system, not the target?

Yes, but this code is built with the new GCC, so I think that will work
our correctly.

-- 
Mark Mitchell <mark@codesourcery.com>
CodeSourcery, LLC

Re: GCC 3.3 Prelease broken on s390

[Jonathan Lennox]

On , May 7 2003, "Mark Mitchell" wrote to "Jonathan Lennox, Ulrich Weigand, rth@redhat.com, gcc@gcc.gnu.org" saying:

> On Wed, 2003-05-07 at 11:19, Jonathan Lennox wrote:
> > Doesn't __s390__ indicate the build system, not the target?
> 
> Yes, but this code is built with the new GCC, so I think that will work
> our correctly.

What about cross-compilers to s390, or built on it?

("They don't work" is a fine answer.) 

-- 
Jonathan Lennox
lennox@cs.columbia.edu

Re: GCC 3.3 Prelease broken on s390

[Mark Mitchell]

On Wed, 2003-05-07 at 11:30, Jonathan Lennox wrote:
> On , May 7 2003, "Mark Mitchell" wrote to "Jonathan Lennox, Ulrich Weigand, rth@redhat.com, gcc@gcc.gnu.org" saying:
> 
> > On Wed, 2003-05-07 at 11:19, Jonathan Lennox wrote:
> > > Doesn't __s390__ indicate the build system, not the target?
> > 
> > Yes, but this code is built with the new GCC, so I think that will work
> > our correctly.
> 
> What about cross-compilers to s390, or built on it?

They will set __s390__ if they are cross compilers to __s390__, and will
not set it if they are not, so all will be well.

And, in fact, even were this broken it would not be too bad -- it's not
like s390 is one of our most-used platforms.  The goal here is to get a
minimally intrusive patch that makes it possible for s390 people to use
GCC 3.3.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com

Re: GCC 3.3 Prelease broken on s390

[Daniel Jacobowitz]

On Wed, May 07, 2003 at 02:30:23PM -0400, Jonathan Lennox wrote:
> On , May 7 2003, "Mark Mitchell" wrote to "Jonathan Lennox, Ulrich Weigand, rth@redhat.com, gcc@gcc.gnu.org" saying:
> 
> > On Wed, 2003-05-07 at 11:19, Jonathan Lennox wrote:
> > > Doesn't __s390__ indicate the build system, not the target?
> > 
> > Yes, but this code is built with the new GCC, so I think that will work
> > our correctly.
> 
> What about cross-compilers to s390, or built on it?
> 
> ("They don't work" is a fine answer.) 

This code is built for the target, not for the build machine.  Checking
__s390__ should be correct.  (It's part of libgcc)

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: GCC 3.3 Prelease broken on s390

[Richard Henderson]

On Wed, May 07, 2003 at 04:49:12PM +0200, Ulrich Weigand wrote:
> However, this now triggers again the new code that sets the
> stack pointer to the cfa, incorrect on s390.

If I understand correctly, then this would be fixed by

  + #ifndef __s390__
      _Unwind_SetGRPtr (context, __builtin_dwarf_sp_column (), NULL);
  + #endif

correct?

> Would you suggest to check the above patch in anyway to make 3.3
> more similar to head (apparently the patch is already in 3.2 ...),
> and because it fixes at least C++?

Well, not to make it more similar to head, but because it gets
more cases demonstrably correct.  On s390 and elsewhere.


r~

Re: GCC 3.3 Prelease broken on s390

[Ulrich Weigand]

Richard Henderson wrote:

> If I understand correctly, then this would be fixed by
> 
>   + #ifndef __s390__
>       _Unwind_SetGRPtr (context, __builtin_dwarf_sp_column (), NULL);
>   + #endif
> 
> correct?

Basically yes, except that then the initial cfa is no longer
found when called from uw_init_context_1.  This is fixed by the 
second hunk of the patch I just committed ...

> > Would you suggest to check the above patch in anyway to make 3.3
> > more similar to head (apparently the patch is already in 3.2 ...),
> > and because it fixes at least C++?
> 
> Well, not to make it more similar to head, but because it gets
> more cases demonstrably correct.  On s390 and elsewhere.

We should certainly fix it properly on the head and for 3.3.1.
Whether this is something for 3.3 I have no strong opinion on
-- that's Mark's call ...

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  weigand@informatik.uni-erlangen.de

Re: GCC 3.3 Prelease broken on s390

[Mark Mitchell]

> We should certainly fix it properly on the head and for 3.3.1.
> Whether this is something for 3.3 I have no strong opinion on
> -- that's Mark's call ...

For 3.3, we certainly don't want anything we don't absolutely need.

Thanks,

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com

Re: Solaris 8/SPARC bootstrap broken building 64-bit libgcc

[John David Anglin]

> I have seen the same error but in a different place for the past two days:
> 
> stage1/xgcc -Bstage1/ -B/home/dave/opt/gnu/hppa-linux/bin/ -c   -gstabs -O2 -DIN
> _GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedant
> ic -Wno-long-long -Werror -fno-common   -DHAVE_CONFIG_H -DGENERATOR_FILE    -I.
> -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/config -I../../gcc/gcc/../
> include -I../intl ../../gcc/gcc/genautomata.c -o genautomata.o
> ../../gcc/gcc/genautomata.c: In function `automata_list_eq_p':
> ../../gcc/gcc/genautomata.c:4463: error: head insn 90 for block 0 not found in t
> he insn stream
> ../../gcc/gcc/genautomata.c:4463: internal compiler error: Segmentation fault

Zdenek's patch

  http://gcc.gnu.org/ml/gcc-patches/2003-07/msg00457.html

fixed the above failure.  However, there are still a bunch of new segmentation
faults in the testsuite.  For example,

Executing on host: /home/dave/gcc-3.4/objdir/gcc/xgcc -B/home/dave/gcc-3.4/objdi
r/gcc/   -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  -w -c
-o 20000728-1.o /home/dave/gcc-3.4/gcc/gcc/testsuite/gcc.c-torture/compile/20000
728-1.c    (timeout = 300)
/home/dave/gcc-3.4/gcc/gcc/testsuite/gcc.c-torture/compile/20000728-1.c: In func
tion `foo':
/home/dave/gcc-3.4/gcc/gcc/testsuite/gcc.c-torture/compile/20000728-1.c:15: inte
rnal compiler error: Segmentation fault

The stack backtrace is:

#0  0x000ec654 in verify_dominators (dom=0x486f58)
    at ../../gcc/gcc/dominance.c:695
#1  0x002f4bcc in unroll_and_peel_loops (loops=0x486e48, flags=4739680)
    at ../../gcc/gcc/loop-unroll.c:145
#2  0x0029b614 in rest_of_handle_loop2 (decl=0x486e48, insns=0x401d1ba0)
    at ../../gcc/gcc/toplev.c:3303
#3  0x0029bda4 in rest_of_compilation (decl=0x401d0a80)
    at ../../gcc/gcc/toplev.c:3576
#4  0x0003e438 in c_expand_body_1 (fndecl=0x401d0a80, nested_p=0)
    at ../../gcc/gcc/c-decl.c:6379
#5  0x002d4500 in cgraph_expand_function (node=0x40017340)
    at ../../gcc/gcc/cgraphunit.c:282
#6  0x002d46c8 in cgraph_expand_functions () at ../../gcc/gcc/cgraphunit.c:372
#7  0x002d49d0 in cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:462
#8  0x0007dfe0 in c_objc_common_finish_file ()
    at ../../gcc/gcc/c-objc-common.c:363
#9  0x00019d3c in yyparse () at c-parse.y:339
#10 0x0006f398 in c_common_parse_file (set_yydebug=4732136)
    at ../../gcc/gcc/c-opts.c:1188
#11 0x00298e20 in compile_file () at ../../gcc/gcc/toplev.c:2069
#12 0x0029e3d0 in do_compile () at ../../gcc/gcc/toplev.c:4959
#13 0x0029e44c in toplev_main (argc=18, argv=0xfaf005b0)
    at ../../gcc/gcc/toplev.c:4990

It appears dom_bb is 0x0.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: Someone broke bootstrap

[John David Anglin]

> There are also a bunch of testsuite regressions on hppa64-hp-hpux11.11.

See <http://gcc.gnu.org/ml/gcc-testresults/2003-10/msg00324.html>.

The gcc.log has messages similar to the following for the new regressions:

/xxx/gnu/gcc-3.3/gcc/gcc/testsuite/gcc.dg/compat/scalar-by-value-1_x.c:154: inte
rnal compiler error: in copy_rtx, at rtl.c:377
Please submit a full bug report,

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: Someone broke bootstrap

[Eric Christopher]

On Tue, 2003-10-07 at 20:11, John David Anglin wrote:
> > There are also a bunch of testsuite regressions on hppa64-hp-hpux11.11.
> 
> See <http://gcc.gnu.org/ml/gcc-testresults/2003-10/msg00324.html>.
> 
> The gcc.log has messages similar to the following for the new regressions:
> 
> /xxx/gnu/gcc-3.3/gcc/gcc/testsuite/gcc.dg/compat/scalar-by-value-1_x.c:154: inte
> rnal compiler error: in copy_rtx, at rtl.c:377
> Please submit a full bug report,

I'm seeing this on frv too. I blame Zack (at least in the little bit of
looking I did...), but that's ok. I'm sure he'll fix it.

-eric

-- 
Eric Christopher <echristo@redhat.com>

Re: Someone broke bootstrap

[John David Anglin]

> I'm seeing this on frv too. I blame Zack (at least in the little bit of
> looking I did...), but that's ok. I'm sure he'll fix it.

Yes, it looks as if this is caused by one of Zack's recent changes.
We have:

#0  0x400000000035ee3c in copy_rtx (orig=0x0) at ../../gcc/gcc/rtl.c:377
#1  0x40000000002f869c in emit_libcall_block (insns=0x800003fffed1f550, 
    target=0x800003fffed20600, result=0x800003fffed1f2d0, equiv=0x0)
    at ../../gcc/gcc/optabs.c:3397
#2  0x40000000002f9430 in emit_cmp_and_jump_insns (x=0x800003fffed3bfa0, 
    y=0x800003fffeff2768, comparison=NE, size=0x72, mode=TFmode, unsignedp=0, 
    label=0x800003fffed3bf50) at ../../gcc/gcc/optabs.c:3946

emit_libcall_block is called with equiv=0 when optimize is 0.  We end
up trying to copy a NULL_RTX at optabs.c:3397.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: autoconf changes break bootstrap on hppa*-*-hpux*

[John David Anglin]

> > So how, precisely is config.cache "not found"?  Is it deleted between line
> > 489 and line 491?  Or is your shell busted?

> The PATH environment variable isn't set correctly.

Possibly, I should add that /bin/sh under hpux 11 is the POSIX shell
and supposedly conforms to the POSIX standards in effect at the time
hpux 11 was introduced.  This means that the source command doesn't
search the current directory.  If I add `.' to PATH, then config.cache
is found.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: Call to arms: testsuite failures on various targets

[John David Anglin]

> * hppa64-hp-hpux11.11: many failures

Most of these are "Type/rank mismatch in argument":

FAIL: gfortran.dg/assumed_charlen_function_5.f90  -O  (test for excess errors)
Excess errors:
/test/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/assumed_charlen_function_5.f90:22: E
rror: Type/rank mismatch in argument 'charr' at (1)
/test/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/assumed_charlen_function_5.f90:23: E
rror: Type/rank mismatch in argument 'charr' at (1)

In gfortran.dg/entry_1.f90:

Excess errors:
/test/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/entry_1.f90:15: Error: Type/rank mis
match in argument 'p' at (1)
/test/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/entry_1.f90:16: Error: Type/rank mis
match in argument 'p' at (1)
/test/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/entry_1.f90:40: Fatal Error: Can't o
pen module file 'm.mod' for reading at (1): No such file or directory

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

gcc-64 on HP-UX 11.00

[H.Merijn Brand]

As I've seen on the gcc web site, HP-UX 11.00 has been promoted to primary
target site. I've got no trouble building gcc in 32 bit mode, but building a
64bit gcc is still almost impossible.

Is there a preferred way to build from the latest snapshot? Do you want more
specific messages about the problems?

I'm not into the gcc sources, but somehow I seem to be willing to function as
a compile farm.

I've got

	The latest HP-UX 11.00 with the latest patches
	The latest C compiler (B.11.11.04 HP C/ANSI C Compiler)
	Several ports of gcc
		3.0.4/32
		3.0.1/64
		3.0.2/64
	binutils-2.11.90/64
	binutils-2.12/64

-- 
H.Merijn Brand        Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using perl-5.6.1, 5.7.3 & 631 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3,
  WinNT 4, Win2K pro & WinCE 2.11.  Smoking perl CORE: smokers@perl.org
http://archives.develooper.com/daily-build@perl.org/   perl-qa@perl.org
send smoke reports to: smokers-reports@perl.org, QA: http://qa.perl.org

Re: gcc-64 on HP-UX 11.00

[law]

In message <20020404113717.E7B3.H.M.BRAND@hccnet.nl>, "H.Merijn Brand" writes:
 > As I've seen on the gcc web site, HP-UX 11.00 has been promoted to primary
 > target site. I've got no trouble building gcc in 32 bit mode, but building a
 > 64bit gcc is still almost impossible.
Correct.  32bit builds should go fine.  64bit builds are a pain.


 > Is there a preferred way to build from the latest snapshot? Do you want more
 > specific messages about the problems?
The preferred way is to always have a previous 64bit compiler available --
building the 64bit PA tools is exceedingly hard using a 32bit GCC or
the HP provided compilers.

Even if you have 64bit PA tools, you're going to run into problems as that
toolchain doesn't receive nearly the attention that the 32bit toolchain 
receives.

jeff

Re: gcc-64 on HP-UX 11.00

[H.Merijn Brand]

[-- Attachment #1: Type: text/plain, Size: 11620 bytes --]

On Thu 04 Apr 2002 21:58, "John David Anglin" <dave@hiauly1.hia.nrc.ca> wrote:
> > As I've seen on the gcc web site, HP-UX 11.00 has been promoted to primary
> > target site. I've got no trouble building gcc in 32 bit mode, but building a
> > 64bit gcc is still almost impossible.
> 
> Can you be more specific?  I think that once you get a good set of tools
> installed you won't have any trouble building 64bit gcc.  This is not to

Then my tools are probably no good ;)

> say that that there aren't lots of issues with hppa64 but I am not having
> problems doing builds anymore.

But you might have /more/ GNU stuff installed in default locations than I have.
For example, in the configuration I'll show shortly, it barfs on unsatisfied
symbol '__umoddi3', which can be found in libgcc.a, which I do not have
installed in a default location, and since I'm building with HPc, it won't
find it without hints. Now if I set LDFLAGS="-L/usr/local/pa20_64/lib -lgcc"
where libgcc can be found in my situation, it is put *before* the libs, making
the needed symbols unfindable, so I commented out LDFLAGS and put in
LIBS=/usr/local/pa20_64/lib/libgcc.a

FYI when reading on, /usr/local/pa20_64 is a symlink to /wrk/pa20_64 because
    that LV has more space to play with.

> > I've got
> > 
> >	The latest HP-UX 11.00 with the latest patches
> > 	The latest C compiler (B.11.11.04 HP C/ANSI C Compiler)
> > 	Several ports of gcc
> > 		3.0.4/32
> > 		3.0.1/64
> > 		3.0.2/64
> > 	binutils-2.11.90/64
> > 	binutils-2.12/64
> 
> Here are my suggestions.  Use the latest binutils.  It has fixes that
> affect hppa64.  Don't use 2.11.90.  Build it with the HP ANSI compiler
> (ie, use "-Ae +DA2.0W" in your CFLAGS).  Gcc may miscompile the
> linker causing it to dump core linking shared libraries.  Whether
> this is still a problem, I'm not sure.

I used
--8<--- Conf-64
#!/usr/bin/sh

export CONFIG_SITE=
export CC=cc
export CFLAGS="-Ae -O +DA2.0W"
#export LDFLAGS="-L/usr/local/pa20_64/lib -lgcc"
export LIBS=/usr/local/pa20_64/lib/libgcc.a
export PATH=.
export PATH=$PATH"":/u/usr/merijn/bin/private:/u/usr/merijn/bin
export PATH=$PATH"":/pro/local/bin:/pro/bin
export PATH=$PATH"":/usr/bin:/usr/bin/X11:/opt/ansic/bin
export PATH=$PATH"":/usr/sbin:/etc:/sbin:/usr/lib:/usr/ccs/bin:/opt/langtools/bin
export PATH=$PATH"":/usr/contrib/bin:/usr/contrib/bin/X11:/opt/imake/bin

configure \
    --prefix=/wrk/pa20_64 --with-local-prefix=/wrk/pa20_64 \
    --disable-shared \
    --disable-nls \
    --enable-multilib \
    --enable-threads
-->8---

But needed the followin patches:
--8<--- binutils-2.12.diff
--- binutils-2.12.org/configure.in	2002-03-08 20:45:10.000000000 +0100
+++ binutils-2.12/configure.in	2002-04-05 13:17:26.000000000 +0200
@@ -722,8 +722,10 @@
   hppa*-*-*elf* | \
   hppa*-*-linux-gnu* | \
   hppa*-*-lites* | \
+  hppa*2.0w*-*-* | \
   hppa*64*-*-*)
     # Do configure ld/binutils/gas for this case.
+    echo " #############   64bit   ################### ($noconfigdirs)" >&2
     ;;
   hppa*-*-*)
     # HP's C compiler doesn't handle Emacs correctly (but on BSD and Mach
--- binutils-2.12.org/bfd/config.bfd	2002-02-13 21:45:46.000000000 +0100
+++ binutils-2.12/bfd/config.bfd	2002-04-05 13:10:23.000000000 +0200
@@ -292,6 +292,7 @@
     targ_defvec=bfd_elf64_hppa_linux_vec
     targ_selvecs=bfd_elf64_hppa_vec
     ;;
+  hppa*2.0w*-*-hpux11* | \
   hppa*64*-*-hpux11*)
     targ_defvec=bfd_elf64_hppa_vec
     targ_selvecs=bfd_elf64_hppa_linux_vec
--- binutils-2.12.org/bfd/configure.host	2002-01-22 01:47:21.000000000 +0100
+++ binutils-2.12/bfd/configure.host	2002-04-05 13:10:41.000000000 +0200
@@ -21,6 +21,7 @@
 
 alpha*-*-*)		host64=true; HOST_64BIT_TYPE=long ;;
 
+hppa*2.0w*-*-hpux* | \
 hppa*64*-*-hpux*)	HDEFINES=-DHOST_HPPAHPUX;
 			host64=true; HOST_64BIT_TYPE=long ;;
 hppa*-*-hpux*)		HDEFINES=-DHOST_HPPAHPUX ;;
--- binutils-2.12.org/gas/configure	2002-02-26 11:35:27.000000000 +0100
+++ binutils-2.12/gas/configure	2002-04-05 13:11:01.000000000 +0200
@@ -2377,6 +2377,7 @@
       hppa-*-osf*)          fmt=som em=hppa ;;
       hppa-*-rtems*)        fmt=elf em=hppa ;;
       hppa-*-hpux11*)	    case ${cpu} in
+				hppa*2.0w* | \
 				hppa*64*)
 					fmt=elf em=hppa64 ;;
 				hppa*)
--- binutils-2.12.org/gas/configure.in	2002-02-26 11:35:27.000000000 +0100
+++ binutils-2.12/gas/configure.in	2002-04-05 13:11:17.000000000 +0200
@@ -227,6 +227,7 @@
       hppa-*-osf*)          fmt=som em=hppa ;;
       hppa-*-rtems*)        fmt=elf em=hppa ;;
       hppa-*-hpux11*)	    case ${cpu} in
+				hppa*2.0w* | \
 				hppa*64*)
 					fmt=elf em=hppa64 ;;
 				hppa*)
--- binutils-2.12.org/ld/configure.tgt	2002-02-20 06:26:22.000000000 +0100
+++ binutils-2.12/ld/configure.tgt	2002-04-05 13:07:56.000000000 +0200
@@ -309,6 +309,7 @@
 m68*-*-rtemscoff*)	targ_emul=m68kcoff ;;
 m68*-*-rtems*)		targ_emul=m68kelf ;;
 hppa*64*-*-linux-gnu*)	targ_emul=hppa64linux ;;
+hppa*2.0w*-*)		targ_emul=elf64hppa ;;
 hppa*64*-*)		targ_emul=elf64hppa ;;
 hppa*-*-linux-gnu*)	targ_emul=hppalinux ;;
 hppa*-*-*elf*)		targ_emul=hppaelf ;;
-->8---

Conf-64 now finishes to the end.

Now I use
--8<--- Build-64
#!/usr/bin/sh

export CONFIG_SITE=
export CC=cc
export CFLAGS="-Ae -O +DA2.0W"
#export LDFLAGS="-L/usr/local/pa20_64/lib -lgcc"
export LIBS=/usr/local/pa20_64/lib/libgcc.a
export PATH=.
export PATH=$PATH"":/u/usr/merijn/bin/private:/u/usr/merijn/bin
export PATH=$PATH"":/pro/local/bin:/pro/bin
export PATH=$PATH"":/usr/bin:/usr/bin/X11:/opt/ansic/bin
export PATH=$PATH"":/usr/sbin:/etc:/sbin:/usr/lib:/usr/ccs/bin:/opt/langtools/bin
export PATH=$PATH"":/usr/contrib/bin:/usr/contrib/bin/X11:/opt/imake/bin

make
-->8---

After the first run I changed 'make' to 'make -i' and reran
the log is attached

a5:/wrk/pa20_64/bin 189 > find * -newer ld.pl -type f | xargs file
addr2line:      ELF-64 executable object file - PA-RISC 2.0 (LP64)
ar:             ELF-64 executable object file - PA-RISC 2.0 (LP64)
as:             ELF-64 executable object file - PA-RISC 2.0 (LP64)
c++filt:        ELF-64 executable object file - PA-RISC 2.0 (LP64)
gas:            ELF-64 executable object file - PA-RISC 2.0 (LP64)
gasp:           ELF-64 executable object file - PA-RISC 2.0 (LP64)
gprof:          ELF-64 executable object file - PA-RISC 2.0 (LP64)
ld:             ELF-64 executable object file - PA-RISC 2.0 (LP64)
nm:             ELF-64 executable object file - PA-RISC 2.0 (LP64)
objcopy:        ELF-64 executable object file - PA-RISC 2.0 (LP64)
objdump:        ELF-64 executable object file - PA-RISC 2.0 (LP64)
ranlib:         ELF-64 executable object file - PA-RISC 2.0 (LP64)
readelf:        ELF-64 executable object file - PA-RISC 2.0 (LP64)
size:           ELF-64 executable object file - PA-RISC 2.0 (LP64)
strings:        ELF-64 executable object file - PA-RISC 2.0 (LP64)
strip:          ELF-64 executable object file - PA-RISC 2.0 (LP64)
a5:/wrk/pa20_64/bin 190 >

Now I should have a working set of binutils, I guess (FTR, I built my previous
set with gcc-3.0.2/64)

> For gcc, use either the 3.1 branch or the unstable 3.2 trunk.  You

I'll go for the gcc-20020401.tar.bz2 version I snatched from snapshot

> should be able to bootstrap it using CC="cc -Ae +DA2.0W" or with
> a working version of gcc for hppa64.  Use the GNU binutils and specify
> the locations for as and ld using --with-as and --with-ld.  Run
> the testsuite to see if things are working.  There are some problems
> with shared libraries so it's probably better not to specify
> --enable-shared in your configure options.
> 
> These are the gcc configure options that I use:
> 
> --host=hppa64-hp-hpux11.11 --with-gnu-as --with-as=/opt/gnu64/bin/as
  
  That's a HP-UX 11i
  
> --with-gnu-ld --with-ld=/opt/gnu64/bin/ld --disable-nls --prefix=/opt/gnu64

This is what I went for
--8<--- Conf-64
#!/usr/bin/sh

export CONFIG_SITE=
export CC="cc -Ae +DA2.0W"
export PATH=.:/u/usr/merijn/bin/private:/u/usr/merijn/bin
export PATH=$PATH"":/pro/local/bin:/pro/bin:/usr/bin:/usr/bin/X11
export PATH=$PATH"":/opt/ansic/bin:/usr/ccs/bin:/opt/langtools/bin
export PATH=$PATH"":/usr/lib:/usr/contrib/bin:/usr/contrib/bin/X11:/opt/imake/bin
export PATH=$PATH"":/wrk/pa20_64/bin:/wrk/GNUpro/bin

rm -rf obj
mkdir obj
cd obj
../src/configure \
    --enable-languages=gcc \
    --prefix=/usr/local/pa20_64 --with-local-prefix=/usr/local/pa20_64 \
    --with-gnu-as \
    --with-gnu-ld \
    --disable-shared \
    --disable-nls \
    --enable-multilib \
    --enable-threads \
    --with-system-zlib

echo ""
echo "Now start 'Build-64'"
-->8---

Of course after patchin with
--8<---
--- src/configure.in.org	2002-04-05 14:16:10.000000000 +0200
+++ src/configure.in	2002-04-05 14:16:31.000000000 +0200
@@ -284,6 +284,7 @@
 # hpux11 in 64bit mode has libraries in a weird place.  Arrange to find
 # them automatically.
 case "${host}" in
+  hppa*2.0w*-*-hpux11* | \
   hppa*64*-*-hpux11*)	
     withoptions="$withoptions -x-libraries=/usr/lib/pa20_64 -x-includes=/usr/X11R6/include"
     ;;
@@ -567,6 +568,7 @@
 noconfigdirs=""
 
 case "${host}" in
+  hppa*2.0w*-*-* |\
   hppa*64*-*-*)
     noconfigdirs="$noconfigdirs byacc"
     ;;
@@ -771,6 +773,7 @@
   hppa*-*-*elf* | \
   parisc*-*-linux* | hppa*-*-linux* | \
   hppa*-*-lites* | \
+  hppa*2.0w*-*-* | \
   hppa*64*-*-*)
     noconfigdirs="$noconfigdirs ${libgcj}"
     # Do configure ld/binutils/gas for this case.
--- src/gcc/config.gcc.org	2002-04-05 14:14:51.000000000 +0200
+++ src/gcc/config.gcc	2002-04-05 14:14:58.000000000 +0200
@@ -917,6 +917,7 @@
 	install_headers_dir=install-headers-cpio
 	use_collect2=yes
 	;;
+hppa*2.0w*-*-hpux11* | \
 hppa*64*-*-hpux11*)
 	xm_defines=POSIX
 	tm_file="pa/pa64-start.h ${tm_file} pa/pa64-regs.h pa/long_double.h pa/elf.h pa/pa-hpux.h pa/pa-hpux11.h pa/pa-64.h pa/pa64-hpux.h"
-->8---

Now I use
--8<--- Build-64
#!/usr/bin/sh

export CONFIG_SITE=
export CC="cc -Ae +DA2.0W"
export PATH=.:/u/usr/merijn/bin/private:/u/usr/merijn/bin
export PATH=$PATH"":/pro/local/bin:/pro/bin:/usr/bin:/usr/bin/X11
export PATH=$PATH"":/opt/ansic/bin:/usr/ccs/bin:/opt/langtools/bin
export PATH=$PATH"":/usr/lib:/usr/contrib/bin:/usr/contrib/bin/X11:/opt/imake/bin
export PATH=$PATH"":/wrk/pa20_64/bin:/wrk/GNUpro/bin

cd obj
make bootstrap-lean
-->8---

The build comes amazingly far, but core dumps like

echo "int xxy_us_dummy;" >tmp-dum.c
./xgcc -B./ -B/usr/local/pa20_64/hppa2.0w-hp-hpux11.00/bin/ -isystem /usr/local/pa20_64/hppa2.0w-hp-hpux11.00/include -isystem /usr/local/pa20_64/hppa2.0w-hp-hpux11.00/sys-include -S tmp-dum.c
cc1: internal error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.
make[2]: *** [s-under] Error 1
make[2]: Leaving directory `/pro/3gl/GNU/gcc-3.0.4/obj/gcc'
make[1]: *** [stage2_build] Error 2
make[1]: Leaving directory `/pro/3gl/GNU/gcc-3.0.4/obj/gcc'
make: *** [bootstrap-lean] Error 2

No core dump.

Should I go on?

-- 
H.Merijn Brand        Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using perl-5.6.1, 5.7.3 & 631 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3,
  WinNT 4, Win2K pro & WinCE 2.11.  Smoking perl CORE: smokers@perl.org
http://archives.develooper.com/daily-build@perl.org/   perl-qa@perl.org
send smoke reports to: smokers-reports@perl.org, QA: http://qa.perl.org

[-- Attachment #2: binutils-2.12-Build-64.log.gz --]
[-- Type: application/octet-stream, Size: 3865 bytes --]

Re: gcc-64 on HP-UX 11.00

[H.Merijn Brand]

[-- Attachment #1: Type: text/plain, Size: 385 bytes --]

On Fri 05 Apr 2002 14:49, H.Merijn Brand <h.m.brand@hccnet.nl> wrote:

Log for gcc was missing

-- 
H.Merijn Brand        Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using perl-5.6.1, 5.7.3 & 631 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3,
     WinNT 4, Win2K pro & WinCE 2.11 often with Tk800.024 &/| DBD-Unify
ftp://ftp.funet.fi/pub/languages/perl/CPAN/authors/id/H/HM/HMBRAND/


[-- Attachment #2: gcc-Build-64.log.gz --]
[-- Type: application/octet-stream, Size: 17282 bytes --]

Re: gcc-64 on HP-UX 11.00

[John David Anglin]

> > Can you be more specific?  I think that once you get a good set of tools
> > installed you won't have any trouble building 64bit gcc.  This is not to
> 
> Then my tools are probably no good ;)

From your comments below, I would say they are incorrectly installed.

> 
> > say that that there aren't lots of issues with hppa64 but I am not having
> > problems doing builds anymore.
> 
> But you might have /more/ GNU stuff installed in default locations than I h=
> ave.
> For example, in the configuration I'll show shortly, it barfs on unsatisfie=
> d
> symbol '__umoddi3', which can be found in libgcc.a, which I do not have
> installed in a default location, and since I'm building with HPc, it won't
> find it without hints. Now if I set LDFLAGS=3D"-L/usr/local/pa20_64/lib -lg=
> cc"

If you use HP cc, libgcc.a should not be needed.  It gets built in stage1
by ./xgcc and then installed with the compiler.

You need to select a prefix to install your 64-bit tools in (e.g., /opt/gnu64).
The prefix can be anywhere but I keep the 64-bit stuff separate from 32-bit
som stuff.  I build and install my 64-bit binutils tools to the same
directory and have /opt/gnu64/bin as the first component in PATH to ensure
that 64-bit tools are used when I do a 64-bit build.

You should not have to play with LDFLAGS to bootstrap the compiler.

Regarding tools, suggest using GNU make.  You should install a 64-bit
versions of binutils.  It may also be useful to build bash, bison, gawk,
texinfo, perl, sed, and possibly autoconf (2.13).  You can build these
with either the HP compiler or 32-bit gcc.

> where libgcc can be found in my situation, it is put *before* the libs, mak=
> ing
> the needed symbols unfindable, so I commented out LDFLAGS and put in
> LIBS=3D/usr/local/pa20_64/lib/libgcc.a
> 
> FYI when reading on, /usr/local/pa20_64 is a symlink to /wrk/pa20_64 becaus=
> e
>     that LV has more space to play with.
> 
> > > I've got
> > >=20
> > >	The latest HP-UX 11.00 with the latest patches
> > > 	The latest C compiler (B.11.11.04 HP C/ANSI C Compiler)
> > > 	Several ports of gcc
> > > 		3.0.4/32
> > > 		3.0.1/64
> > > 		3.0.2/64
> > > 	binutils-2.11.90/64
> > > 	binutils-2.12/64
> >=20
> > Here are my suggestions.  Use the latest binutils.  It has fixes that
> > affect hppa64.  Don't use 2.11.90.  Build it with the HP ANSI compiler
> > (ie, use "-Ae +DA2.0W" in your CFLAGS).  Gcc may miscompile the
> > linker causing it to dump core linking shared libraries.  Whether
> > this is still a problem, I'm not sure.
> 
> I used
> --8<--- Conf-64
> #!/usr/bin/sh
> 
> export CONFIG_SITE=3D
> export CC=3Dcc

Change this to
export CC="cc -Ae +DA2.0W"

> export CFLAGS=3D"-Ae -O +DA2.0W"
> #export LDFLAGS=3D"-L/usr/local/pa20_64/lib -lgcc"
> export LIBS=3D/usr/local/pa20_64/lib/libgcc.a

Delete these.

> export PATH=3D.
> export PATH=3D$PATH"":/u/usr/merijn/bin/private:/u/usr/merijn/bin
> export PATH=3D$PATH"":/pro/local/bin:/pro/bin
> export PATH=3D$PATH"":/usr/bin:/usr/bin/X11:/opt/ansic/bin
> export PATH=3D$PATH"":/usr/sbin:/etc:/sbin:/usr/lib:/usr/ccs/bin:/opt/langt=
> ools/bin
> export PATH=3D$PATH"":/usr/contrib/bin:/usr/contrib/bin/X11:/opt/imake/bin
> 
> configure \
>     --prefix=3D/wrk/pa20_64 --with-local-prefix=3D/wrk/pa20_64 \
>     --disable-shared \
>     --disable-nls \
>     --enable-multilib \
>     --enable-threads

Use a modification of what I sent.  --with-local-prefix probably isn't
needed.  You don't need --enable-multilib or --enable-threads.  There
isn't any thread support yet and no multilibs.

> -->8---
> 

The patch below is incorrect.  The hppa2.0w-hp-hpux11* target is actually
the 32-bit som target on a 2.0w machine.  It shouldn't be changed to
64-bit.  Same for gcc config.

You want to configure binutils with something like

--host=hppa64-hp-hpux11.11 --prefix=/opt/gnu64 --disable-nls

If you are using a 11.00 system --host should be hppa64-hp-hpux11.00.  You
need to specify --host, or a complete set of --host, --build and --target
to do a 64-bit build.  The default guess is for 32-bit tools.

> But needed the followin patches:
> --8<--- binutils-2.12.diff
> --- binutils-2.12.org/configure.in	2002-03-08 20:45:10.000000000 +0100
> +++ binutils-2.12/configure.in	2002-04-05 13:17:26.000000000 +0200
> @@ -722,8 +722,10 @@
>    hppa*-*-*elf* | \
>    hppa*-*-linux-gnu* | \
>    hppa*-*-lites* | \
> +  hppa*2.0w*-*-* | \
>    hppa*64*-*-*)

[...]

> > These are the gcc configure options that I use:
> >=20
> > --host=3Dhppa64-hp-hpux11.11 --with-gnu-as --with-as=3D/opt/gnu64/bin/as
>  =20
>   That's a HP-UX 11i

Yes.  It works identically to 11.00.

>  =20
> > --with-gnu-ld --with-ld=3D/opt/gnu64/bin/ld --disable-nls --prefix=3D/opt=
> /gnu64
> 
> This is what I went for
> --8<--- Conf-64
> #!/usr/bin/sh
> 
> export CONFIG_SITE=3D
> export CC=3D"cc -Ae +DA2.0W"
> export PATH=3D.:/u/usr/merijn/bin/private:/u/usr/merijn/bin
> export PATH=3D$PATH"":/pro/local/bin:/pro/bin:/usr/bin:/usr/bin/X11
> export PATH=3D$PATH"":/opt/ansic/bin:/usr/ccs/bin:/opt/langtools/bin
> export PATH=3D$PATH"":/usr/lib:/usr/contrib/bin:/usr/contrib/bin/X11:/opt/i=
> make/bin
> export PATH=3D$PATH"":/wrk/pa20_64/bin:/wrk/GNUpro/bin

When you do a 64-bit build, make sure that the 64-bit tools are before
the 32-bit and HP tools.  Some have the same name so you want to be sure
that your using the correct tools.  The HP compiler knows how to find
its tools.

> 
> rm -rf obj
> mkdir obj
> cd obj
> =2E./src/configure \
>     --enable-languages=3Dgcc \
>     --prefix=3D/usr/local/pa20_64 --with-local-prefix=3D/usr/local/pa20_64 =
> \
>     --with-gnu-as \
>     --with-gnu-ld \
>     --disable-shared \
>     --disable-nls \
>     --enable-multilib \
>     --enable-threads \
>     --with-system-zlib
> 
> echo ""
> echo "Now start 'Build-64'"
> -->8---
> 

Again, the patch below is wrong and unnecessary.  You need to specify
--host properly.  I suggest removing --enable-multilib, --enable-threads
and --with-system-zlib.  The system zlib probably has the security bug.

>
> Of course after patchin with
> --8<---
> --- src/configure.in.org	2002-04-05 14:16:10.000000000 +0200
> +++ src/configure.in	2002-04-05 14:16:31.000000000 +0200
> @@ -284,6 +284,7 @@
>  # hpux11 in 64bit mode has libraries in a weird place.  Arrange to find
>  # them automatically.
>  case "${host}" in
> +  hppa*2.0w*-*-hpux11* | \
>    hppa*64*-*-hpux11*)=09

[...]

> The build comes amazingly far, but core dumps like
> 
> echo "int xxy_us_dummy;" >tmp-dum.c
> =2E/xgcc -B./ -B/usr/local/pa20_64/hppa2.0w-hp-hpux11.00/bin/ -isystem /usr=
> /local/pa20_64/hppa2.0w-hp-hpux11.00/include -isystem /usr/local/pa20_64/hp=
> pa2.0w-hp-hpux11.00/sys-include -S tmp-dum.c
> cc1: internal error: Segmentation fault

> No core dump.
> 
> Should I go on?

Retry following my suggestions.  The important points are:

1)  Use a common prefix for your tools (e.g., /usr/local/pa20_64).
2)  Use --host=hppa64-hp-hpux11.00.
3)  Export CC="cc -Ae +DA2.0W" for your initial builds of binutils and gcc.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: gcc-64 on HP-UX 11.00

[H.Merijn Brand]

On Fri 05 Apr 2002 18:06, "John David Anglin" <dave@hiauly1.hia.nrc.ca> wrote:
> > > Can you be more specific?  I think that once you get a good set of tools
> > > installed you won't have any trouble building 64bit gcc.  This is not to
> > 
> > Then my tools are probably no good ;)
> 
> >From your comments below, I would say they are incorrectly installed.
> 
> > 
> > > say that that there aren't lots of issues with hppa64 but I am not having
> > > problems doing builds anymore.
> > 
> > But you might have /more/ GNU stuff installed in default locations than I h=
> > ave.
> > For example, in the configuration I'll show shortly, it barfs on unsatisfie=
> > d
> > symbol '__umoddi3', which can be found in libgcc.a, which I do not have
> > installed in a default location, and since I'm building with HPc, it won't
> > find it without hints. Now if I set LDFLAGS=3D"-L/usr/local/pa20_64/lib -lg=
> > cc"
> 
> If you use HP cc, libgcc.a should not be needed.  It gets built in stage1
> by ./xgcc and then installed with the compiler.

was baffled too.

> You need to select a prefix to install your 64-bit tools in (e.g., /opt/gnu64).

I use /wrk/pa20_64 and have /usr/local/pa20_64 symlinked to it

> The prefix can be anywhere but I keep the 64-bit stuff separate from 32-bit

So do I

> som stuff.  I build and install my 64-bit binutils tools to the same
> directory and have /opt/gnu64/bin as the first component in PATH to ensure
> that 64-bit tools are used when I do a 64-bit build.

Same here

> You should not have to play with LDFLAGS to bootstrap the compiler.

Found that out too.

> Regarding tools, suggest using GNU make.  You should install a 64-bit

GNU make installed as basic make on *ALL* our systems. Native make's just
won't do :)

> versions of binutils.  It may also be useful to build bash, bison, gawk,
> texinfo, perl, sed, and possibly autoconf (2.13).  You can build these
> with either the HP compiler or 32-bit gcc.

bash		only on cywgin (I'm a tcsh addict)
bison		1.34 all over. I'm helping the bison guys with testing on
		HP-UX and AIX, so I guess I must be up to date
gawk		same as make
texinfo		nowhere. I *HATE* the info style of documenting, so I don't
		care if installing info stuff fails. I'd even prefer it to
		fail. I'd love to see it fallback to the good ol' man pages.
perl		hell, I'm a perl5-porter, so I've got several versions up and
		running, and the bleading edge version is smoke tested on all
		systems every day
sed		same as make
autoconf	I *try* to get a recent version installed, but HPUX and AIX
		are not the most wonderfull systems for this package. I /do/
		have these installed, for gcc only.

> > where libgcc can be found in my situation, it is put *before* the libs, mak=
> > ing
> > the needed symbols unfindable, so I commented out LDFLAGS and put in
> > LIBS=3D/usr/local/pa20_64/lib/libgcc.a
> > 
> > FYI when reading on, /usr/local/pa20_64 is a symlink to /wrk/pa20_64 becaus=
> > e
> >     that LV has more space to play with.
> > 
> > > > I've got
> > > >=20
> > > >	The latest HP-UX 11.00 with the latest patches
> > > > 	The latest C compiler (B.11.11.04 HP C/ANSI C Compiler)
> > > > 	Several ports of gcc
> > > > 		3.0.4/32
> > > > 		3.0.1/64
> > > > 		3.0.2/64
> > > > 	binutils-2.11.90/64
> > > > 	binutils-2.12/64
> > >=20
> > > Here are my suggestions.  Use the latest binutils.  It has fixes that
> > > affect hppa64.  Don't use 2.11.90.  Build it with the HP ANSI compiler
> > > (ie, use "-Ae +DA2.0W" in your CFLAGS).  Gcc may miscompile the
> > > linker causing it to dump core linking shared libraries.  Whether
> > > this is still a problem, I'm not sure.
> > 
> > I used
> > --8<-- Conf-64
> > #!/usr/bin/sh
> > 
> > export CONFIG_SITE=3D
> > export CC=3Dcc
> 
> Change this to
> export CC="cc -Ae +DA2.0W"

I will

> > export CFLAGS=3D"-Ae -O +DA2.0W"
> > #export LDFLAGS=3D"-L/usr/local/pa20_64/lib -lgcc"
> > export LIBS=3D/usr/local/pa20_64/lib/libgcc.a
> 
> Delete these.

Consider it done

> > export PATH=3D.
> > export PATH=3D$PATH"":/u/usr/merijn/bin/private:/u/usr/merijn/bin
> > export PATH=3D$PATH"":/pro/local/bin:/pro/bin
> > export PATH=3D$PATH"":/usr/bin:/usr/bin/X11:/opt/ansic/bin
> > export PATH=3D$PATH"":/usr/sbin:/etc:/sbin:/usr/lib:/usr/ccs/bin:/opt/langt=
> > ools/bin
> > export PATH=3D$PATH"":/usr/contrib/bin:/usr/contrib/bin/X11:/opt/imake/bin
> > 
> > configure \
> >     --prefix=3D/wrk/pa20_64 --with-local-prefix=3D/wrk/pa20_64 \
> >     --disable-shared \
> >     --disable-nls \
> >     --enable-multilib \
> >     --enable-threads
> 
> Use a modification of what I sent.  --with-local-prefix probably isn't
> needed.  You don't need --enable-multilib or --enable-threads.  There
> isn't any thread support yet and no multilibs.

Grrr, but at least it proves I read /beyond/ the surface.

> > -->8---
> > 
> 
> The patch below is incorrect.  The hppa2.0w-hp-hpux11* target is actually
> the 32-bit som target on a 2.0w machine.  It shouldn't be changed to
> 64-bit.  Same for gcc config.

An auto-detect, or configure help would be nice then. I /did/ try with
specifying the host like that, but also got stuck somewhere, so I thought this
would be a more clean way to go.

> You want to configure binutils with something like
> 
> --host=hppa64-hp-hpux11.11 --prefix=/opt/gnu64 --disable-nls
> 
> If you are using a 11.00 system --host should be hppa64-hp-hpux11.00.  You
> need to specify --host, or a complete set of --host, --build and --target
> to do a 64-bit build.  The default guess is for 32-bit tools.

Systems are down now, expect some positive message early this week.

> > But needed the followin patches:
> > --8<-- binutils-2.12.diff
> > --- binutils-2.12.org/configure.in	2002-03-08 20:45:10.000000000 +0100
> > +++ binutils-2.12/configure.in	2002-04-05 13:17:26.000000000 +0200
> > @@ -722,8 +722,10 @@
> >    hppa*-*-*elf* | \
> >    hppa*-*-linux-gnu* | \
> >    hppa*-*-lites* | \
> > +  hppa*2.0w*-*-* | \
> >    hppa*64*-*-*)
> 
> [...]
> 
> > > These are the gcc configure options that I use:
> > >=20
> > > --host=3Dhppa64-hp-hpux11.11 --with-gnu-as --with-as=3D/opt/gnu64/bin/as
> >  =20
> >   That's a HP-UX 11i
> 
> Yes.  It works identically to 11.00.
> 
> >  =20
> > > --with-gnu-ld --with-ld=3D/opt/gnu64/bin/ld --disable-nls --prefix=3D/opt=
> > /gnu64
> > 
> > This is what I went for
> > --8<-- Conf-64
> > #!/usr/bin/sh
> > 
> > export CONFIG_SITE=3D
> > export CC=3D"cc -Ae +DA2.0W"
> > export PATH=3D.:/u/usr/merijn/bin/private:/u/usr/merijn/bin
> > export PATH=3D$PATH"":/pro/local/bin:/pro/bin:/usr/bin:/usr/bin/X11
> > export PATH=3D$PATH"":/opt/ansic/bin:/usr/ccs/bin:/opt/langtools/bin
> > export PATH=3D$PATH"":/usr/lib:/usr/contrib/bin:/usr/contrib/bin/X11:/opt/i=
> > make/bin
> > export PATH=3D$PATH"":/wrk/pa20_64/bin:/wrk/GNUpro/bin
> 
> When you do a 64-bit build, make sure that the 64-bit tools are before

They are.

> the 32-bit and HP tools.  Some have the same name so you want to be sure
> that your using the correct tools.  The HP compiler knows how to find
> its tools.

As a side track, how much of what I specify during build is inherited in the
compiler? Can the /wrk/pa20_64 be ported independent of the way I built it?
Does the user that receives the dist need the same as and the same ld or can
it use a different one?

> > 
> > rm -rf obj
> > mkdir obj
> > cd obj
> > =2E./src/configure \
> >     --enable-languages=3Dgcc \
> >     --prefix=3D/usr/local/pa20_64 --with-local-prefix=3D/usr/local/pa20_64 =
> > \
> >     --with-gnu-as \
> >     --with-gnu-ld \
> >     --disable-shared \
> >     --disable-nls \
> >     --enable-multilib \
> >     --enable-threads \
> >     --with-system-zlib
> > 
> > echo ""
> > echo "Now start 'Build-64'"
> > -->8---
> > 
> 
> Again, the patch below is wrong and unnecessary.  You need to specify
> --host properly.  I suggest removing --enable-multilib, --enable-threads
> and --with-system-zlib.  The system zlib probably has the security bug.

No, all my zlib's are up to date. The security bug made me choose for this
option in the first place.

> >
> > Of course after patchin with
> > --8<--
> > --- src/configure.in.org	2002-04-05 14:16:10.000000000 +0200
> > +++ src/configure.in	2002-04-05 14:16:31.000000000 +0200
> > @@ -284,6 +284,7 @@
> >  # hpux11 in 64bit mode has libraries in a weird place.  Arrange to find
> >  # them automatically.
> >  case "${host}" in
> > +  hppa*2.0w*-*-hpux11* | \
> >    hppa*64*-*-hpux11*)=09
> 
> [...]
> 
> > The build comes amazingly far, but core dumps like
> > 
> > echo "int xxy_us_dummy;" >tmp-dum.c
> > =2E/xgcc -B./ -B/usr/local/pa20_64/hppa2.0w-hp-hpux11.00/bin/ -isystem /usr=
> > /local/pa20_64/hppa2.0w-hp-hpux11.00/include -isystem /usr/local/pa20_64/hp=
> > pa2.0w-hp-hpux11.00/sys-include -S tmp-dum.c
> > cc1: internal error: Segmentation fault
> 
> > No core dump.
> > 
> > Should I go on?
> 
> Retry following my suggestions.  The important points are:
> 
> 1)  Use a common prefix for your tools (e.g., /usr/local/pa20_64).
> 2)  Use --host=hppa64-hp-hpux11.00.
> 3)  Export CC="cc -Ae +DA2.0W" for your initial builds of binutils and gcc.

Thanks so far. I'll keep you posted.

-- 
H.Merijn Brand        Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using perl-5.6.1, 5.7.3 & 631 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3,
  WinNT 4, Win2K pro & WinCE 2.11.  Smoking perl CORE: smokers@perl.org
http://archives.develooper.com/daily-build@perl.org/   perl-qa@perl.org
send smoke reports to: smokers-reports@perl.org, QA: http://qa.perl.org

Re: gcc-64 on HP-UX 11.00

[John David Anglin]

> autoconf	I *try* to get a recent version installed, but HPUX and AIX
> 		are not the most wonderfull systems for this package. I /do/
> 		have these installed, for gcc only.

Install 2.13 for gcc development.  It's only needed if you need to update
configure.  It shouldn't be needed for normal builds if you start from
a snapshot or use contrib/gcc_update.

> As a side track, how much of what I specify during build is inherited in the
> compiler? Can the /wrk/pa20_64 be ported independent of the way I built it?
> Does the user that receives the dist need the same as and the same ld or can
> it use a different one?

They need to be feature compatible.  There are various assembler and linker
checks done by configure.

If you are trying to build with --prefix=/wrk/pa20_64 and install the
final dist to a different directory, there may be problems.  The gcc driver
has a builtin dependency on the specified installation directory and it
uses this to locate library and header files.  If you specify --with-as,
then it expects to find the assembly in the specified location.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: gcc-64 on HP-UX 11.00

[H.Merijn Brand]

[-- Attachment #1: Type: text/plain, Size: 4095 bytes --]

On Fri 05 Apr 2002 18:06, "John David Anglin" <dave@hiauly1.hia.nrc.ca> wrote:
> Retry following my suggestions.  The important points are:
> 
> 1)  Use a common prefix for your tools (e.g., /usr/local/pa20_64).
      [v] Done
> 2)  Use --host=hppa64-hp-hpux11.00.
      [v] Done
> 3)  Export CC="cc -Ae +DA2.0W" for your initial builds of binutils and gcc.
      [v] Done
      [v] Rebuilt and installed binutils-2.12 again
      [v] gcc still problematic - build log attached (it requests to be sent
          to the gcc people :)

a5:/pro/3gl/GNU/gcc-3.0.4 129 > cat Conf-64
#!/usr/bin/sh

export CONFIG_SITE=
export CC="cc -Ae +DA2.0W"
export PATH=.:/usr/local/pa20_64/bin:/pro/local/bin
export PATH=$PATH"":/usr/bin:/opt/ansic/bin:/usr/ccs/bin:/opt/langtools/bin
export PATH=$PATH"":/opt/imake/bin

rm -rf obj
mkdir obj
cd obj
../src/configure \
    --enable-languages=gcc \
    --prefix=/usr/local/pa20_64 --with-local-prefix=/usr/local/pa20_64 \
    --with-gnu-as --with-as=/usr/local/pa20_64/bin/as \
    --with-gnu-ld --with-ld=/usr/local/pa20_64/bin/ld \
    --disable-shared \
    --disable-nls \
    --host=hppa64-hp-hpux11.00

echo ""
echo "Now start 'Build-64'"
a5:/pro/3gl/GNU/gcc-3.0.4 130 > cat Build-64
#!/usr/bin/sh

export CONFIG_SITE=
export CC="cc -Ae +DA2.0W"
export PATH=.:/usr/local/pa20_64/bin:/pro/local/bin
export PATH=$PATH"":/usr/bin:/opt/ansic/bin:/usr/ccs/bin:/opt/langtools/bin
export PATH=$PATH"":/opt/imake/bin

cd obj
make bootstrap-lean
a5:/pro/3gl/GNU/gcc-3.0.4 131 >


a5:/wrk/pa20_64/bin 135 > as --version
GNU assembler 2.12
Copyright 2002 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License.  This program has absolutely no warranty.
This assembler was configured for a target of `hppa64-hp-hpux11.00'.
a5:/wrk/pa20_64/bin 136 > ar --version
GNU ar 2.12
Copyright 2002 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License.  This program has absolutely no warranty.
a5:/wrk/pa20_64/bin 137 > file *
addr2line:      ELF-64 executable object file - PA-RISC 2.0 (LP64)
ar:             ELF-64 executable object file - PA-RISC 2.0 (LP64)
as:             ELF-64 executable object file - PA-RISC 2.0 (LP64)
c++:            ELF-64 executable object file - PA-RISC 2.0 (LP64)
c++filt:        ELF-64 executable object file - PA-RISC 2.0 (LP64)
cpp:            ELF-64 executable object file - PA-RISC 2.0 (LP64)
g++:            ELF-64 executable object file - PA-RISC 2.0 (LP64)
gas:            ELF-64 executable object file - PA-RISC 2.0 (LP64)
gasp:           ELF-64 executable object file - PA-RISC 2.0 (LP64)
gcc:            ELF-64 executable object file - PA-RISC 2.0 (LP64)
gcc64:          ELF-64 executable object file - PA-RISC 2.0 (LP64)
gccbug:         commands text
gcov:           ELF-64 executable object file - PA-RISC 2.0 (LP64)
gprof:          ELF-64 executable object file - PA-RISC 2.0 (LP64)
ld:             ELF-64 executable object file - PA-RISC 2.0 (LP64)
nm:             ELF-64 executable object file - PA-RISC 2.0 (LP64)
objcopy:        ELF-64 executable object file - PA-RISC 2.0 (LP64)
objdump:        ELF-64 executable object file - PA-RISC 2.0 (LP64)
ranlib:         ELF-64 executable object file - PA-RISC 2.0 (LP64)
readelf:        ELF-64 executable object file - PA-RISC 2.0 (LP64)
size:           ELF-64 executable object file - PA-RISC 2.0 (LP64)
strings:        ELF-64 executable object file - PA-RISC 2.0 (LP64)
strip:          ELF-64 executable object file - PA-RISC 2.0 (LP64)
a5:/wrk/pa20_64/bin 138 >

-- 
H.Merijn Brand        Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using perl-5.6.1, 5.7.3 & 631 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3,
  WinNT 4, Win2K pro & WinCE 2.11.  Smoking perl CORE: smokers@perl.org
http://archives.develooper.com/daily-build@perl.org/   perl-qa@perl.org
send smoke reports to: smokers-reports@perl.org, QA: http://qa.perl.org

[-- Attachment #2: gcc-20020408-hpux64.tgz --]
[-- Type: application/octet-stream, Size: 18321 bytes --]

Re: gcc-64 on HP-UX 11.00

[John David Anglin]

>       [v] gcc still problematic - build log attached (it requests to be sen=
> t
>           to the gcc people :)
> 
> a5:/pro/3gl/GNU/gcc-3.0.4 129 > cat Conf-64

It's not totally clear which version your trying to build.  It looks like
3.0.4 but the files in the log file don't appear to be 3.0.4.  In any event,
there are a various warnings in the log file that are not normal:

cc -Ae +DA2.0W -c -DIN_GCC    -g    -DHAVE_CONFIG_H -DGENERATOR_FILE    -I. -I.
-I../../src/gcc -I../../src/gcc/. -I../../src/gcc/config -I../../src/gcc/../incl
ude ../../src/gcc/read-rtl.c -o read-rtl.o
cc: "../../src/gcc/read-rtl.c", line 671: warning 727: Cast truncates pointer in
to 32 bit integer.
cc -Ae +DA2.0W -c -DIN_GCC    -g    -DHAVE_CONFIG_H -DGENERATOR_FILE    -I. -I.
-I../../src/gcc -I../../src/gcc/. -I../../src/gcc/config -I../../src/gcc/../incl
ude ../../src/gcc/bitmap.c -o bitmap.o
cc: "../../src/gcc/bitmap.c", line 144: warning 727: Cast truncates pointer into
 32 bit integer.

[...]

c-parse.y:1951: warning: previous rule lacks an ending `;'
c-parse.y:2017: warning: previous rule lacks an ending `;'
c-parse.y:2048: warning: previous rule lacks an ending `;'

I have tested the suggested procedure with 3.1 (prerelease) from
todays cvs and it doesn't have a bootstrap failure in stage 1.
However, the procedure doesn't work with 3.0.4:

./gencodes ../../gcc/gcc/config/pa/pa.md > tmp-codes.h
/bin/sh: 1969 Memory fault(coredump)

This looks like a problem with alloca.  Suggest trying 3.1.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: gcc-64 on HP-UX 11.00

[H.Merijn Brand]

Stripped the binutils from the Cc, cause I think we're on a gcc-only track now.

On Wed 10 Apr 2002 20:14, "John David Anglin" <dave@hiauly1.hia.nrc.ca> wrote:
> >       [v] gcc still problematic - build log attached (it requests to be sen=
> > t
> >           to the gcc people :)
> > 
> > a5:/pro/3gl/GNU/gcc-3.0.4 129 > cat Conf-64
> 
> It's not totally clear which version your trying to build.  It looks like
> 3.0.4 but the files in the log file don't appear to be 3.0.4.  In any event,
> there are a various warnings in the log file that are not normal:

The latest 'snapshot' as in gcc-20020408.tar.bz2
The prompt is indeed misleading, but I started this queeste on 3.0.4, so the
structure was already set up. But rest assured: no 3.0.4 code in here.

> cc -Ae +DA2.0W -c -DIN_GCC    -g    -DHAVE_CONFIG_H -DGENERATOR_FILE    -I. -I.
> -I../../src/gcc -I../../src/gcc/. -I../../src/gcc/config -I../../src/gcc/../incl
> ude ../../src/gcc/read-rtl.c -o read-rtl.o
> cc: "../../src/gcc/read-rtl.c", line 671: warning 727: Cast truncates pointer in
> to 32 bit integer.
> cc -Ae +DA2.0W -c -DIN_GCC    -g    -DHAVE_CONFIG_H -DGENERATOR_FILE    -I. -I.
> -I../../src/gcc -I../../src/gcc/. -I../../src/gcc/config -I../../src/gcc/../incl
> ude ../../src/gcc/bitmap.c -o bitmap.o
> cc: "../../src/gcc/bitmap.c", line 144: warning 727: Cast truncates pointer into
>  32 bit integer.
> 
> [...]
> 
> c-parse.y:1951: warning: previous rule lacks an ending `;'
> c-parse.y:2017: warning: previous rule lacks an ending `;'
> c-parse.y:2048: warning: previous rule lacks an ending `;'
> 
> I have tested the suggested procedure with 3.1 (prerelease) from
> todays cvs and it doesn't have a bootstrap failure in stage 1.
> However, the procedure doesn't work with 3.0.4:
> 
> ./gencodes ../../gcc/gcc/config/pa/pa.md > tmp-codes.h
> /bin/sh: 1969 Memory fault(coredump)
> 
> This looks like a problem with alloca.  Suggest trying 3.1.

What URL? (I've got no (working) cvs)

-- 
H.Merijn Brand        Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using perl-5.6.1, 5.7.3 & 631 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3,
  WinNT 4, Win2K pro & WinCE 2.11.  Smoking perl CORE: smokers@perl.org
http://archives.develooper.com/daily-build@perl.org/   perl-qa@perl.org
send smoke reports to: smokers-reports@perl.org, QA: http://qa.perl.org

Re: gcc-64 on HP-UX 11.00

[John David Anglin]

> The latest 'snapshot' as in gcc-20020408.tar.bz2

I'll try the current cvs.

> > This looks like a problem with alloca.  Suggest trying 3.1.
> 
> What URL? (I've got no (working) cvs)

There don't seem to be any 3.1 snaps at ftp://gcc.gnu.org.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: gcc-64 on HP-UX 11.00

[H.Merijn Brand]

On Wed 10 Apr 2002 21:44, "John David Anglin" <dave@hiauly1.hia.nrc.ca> wrote:
> > The latest 'snapshot' as in gcc-20020408.tar.bz2
> 
> I'll try the current cvs.
> 
> > > This looks like a problem with alloca.  Suggest trying 3.1.
> > 
> > What URL? (I've got no (working) cvs)
> 
> There don't seem to be any 3.1 snaps at ftp://gcc.gnu.org.

Can you make an (anonymous) ftp version available to me?
Do you think I'm /helping/, or just bothering?
Do you think it's worth the trouble?

If I manage - with your help - to build a working HP-UX gcc/64, I'll post the
Conf-64 and Build-64 scripts on the HP-UX forum, because I know there are more
people fighting with exactly the same problem, and none of those has reached
success

C-environment info:

a5:/u/usr/merijn 107 > ll /usr/lib/cpp /usr/ccs/lbin/cpp /opt/langtools/lbin/cpp /wrk/*64/bin/cpp
   1114 -r-xr-xr-x   1 bin      bin        548864 Sep 20  2001 /opt/langtools/lbin/cpp
    194 -r-xr-xr-x   1 bin      bin        258048 Nov  7  1997 /usr/ccs/lbin/cpp
   1170 lr-xr-xr-t   1 root     sys            23 Oct  9  2001 /usr/lib/cpp -> /opt/langtools/lbin/cpp
    355 -rwxr-xr-x   1 merijn   softwr     151384 Aug 27  2001 /wrk/gcc-3.0.1-64/bin/cpp
    556 -rwxr-xr-x   1 merijn   bin        666248 Oct 30 21:05 /wrk/pa20_64/bin/cpp
a5:/u/usr/merijn 108 > what !*
what /usr/lib/cpp /usr/ccs/lbin/cpp /opt/langtools/lbin/cpp /wrk/*64/bin/cpp
/usr/lib/cpp:
        HP92453-01 B.11.11.04 HP C Preprocessor
         $   Sep  8 2000 23:13:51 $
/usr/ccs/lbin/cpp:
        HP92453-01 A.11.00.00 HP C (Bundled) Preprocessor
         CUPROS_IC23B //1
         /ux/core/libs/libc/archive_pa1/libc.a_ID
         Oct 21 1997 13:07:38
/opt/langtools/lbin/cpp:
        HP92453-01 B.11.11.04 HP C Preprocessor
         $   Sep  8 2000 23:13:51 $
/wrk/gcc-3.0.1-64/bin/cpp:
/wrk/pa20_64/bin/cpp:
        HP92453-02A.11.00 HP-UX SYMBOLIC DEBUGGER (END.O LP64) $Revision: 75.03 $
a5:/u/usr/merijn 109 > path -w cc
/usr/bin/cc:
        LINT B.11.11.04 CXREF B.11.11.04
        HP92453-01 B.11.11.25985.GP HP C Compiler
         $   Sep  8 2000 23:13:51 $

        /usr/bin/cc:
     $Revision: 92453-07 linker linker crt0.o B.11.25 010530 $
a5:/u/usr/merijn 110 > swlist -l product | grep -e libc -e header -e ANSI
  C-ANSI-C              B.11.11.04     HP C/ANSI C Compiler
  PHCO_13349            1.0            XCurses header patch.
  PHCO_18228            1.0            libc man page cumulative patch
  PHCO_23706            1.0            cumulative 10.20 libc compatibility support
  PHCO_23770            1.0            libc cumulative patch
  PHCO_23963            1.0            libc cumulative header file patch
  PHCO_24723            1.0            libc cumulative patch
  PHCO_25707            1.0            libc cumulative patch
  PHSS_25985            1.0            ANSI C compiler General patch
a5:/u/usr/merijn 111 >

This should reflect the December-2001 QPK patch level. My other hp-11.00 is
already on March-2002, but users prevented me from updating this system so far.

-- 
H.Merijn Brand        Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using perl-5.6.1, 5.7.3 & 631 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3,
  WinNT 4, Win2K pro & WinCE 2.11.  Smoking perl CORE: smokers@perl.org
http://archives.develooper.com/daily-build@perl.org/   perl-qa@perl.org
send smoke reports to: smokers-reports@perl.org, QA: http://qa.perl.org

Re: gcc-64 on HP-UX 11.00

[John David Anglin]

> On Wed 10 Apr 2002 21:44, "John David Anglin" <dave@hiauly1.hia.nrc.ca> wrote:
> > > The latest 'snapshot' as in gcc-20020408.tar.bz2
> > 
> > I'll try the current cvs.

I've duplicated the problem that you found.  It's a bug in the GNU linker.
It's not handling the relocations required for inline plabels correctly.
The function splay_tree_new_with_allocator seg-faults when it is passed
a pointer to the function splay_tree_xmalloc_allocate rather than a pointer
to a function descriptor for splay_tree_xmalloc_allocate.  The problem
is present in both 3.1 and the trunk.

This problem was introduced on 2002-02-22 when splay-tree.c was changed
to use the above indirect call.  The function splay-tree.c is in libiberty.
Libiberty gets built just in stage1 with the HP compiler.  The HP compiler
now uses inline plabels (LTP and RTP selectors).  The HP assembler and
linker can handle these relocation selectors, but unfortunately not the
GNU linker.

Gcc doesn't generate inline plabels on the PA.  It would save one insn
and one data location if we could use these selectors.  However, there
have been problems with them in 32bit land for years.  I think the
current assembler can handle them but the SOM linker still doesn't
handle them.

The work around is to use the HP linker for the initial bootstrap.  I
recommend just building C, install it, then do another full bootstrap
using gcc and the GNU linker.  You have to use the GNU assembler for
both builds.

Could you try another build?  Just remove "--with-gnu-ld" from your
script and specify "--with-ld=/usr/ccs/bin/ld".  You may want to
export LD_PXDB=/usr/bin/true to defer invocation of pxdb.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: gcc-64 on HP-UX 11.00

[H.Merijn Brand]

[-- Attachment #1: Type: text/plain, Size: 2468 bytes --]

On Thu 11 Apr 2002 17:18, "John David Anglin" <dave@hiauly1.hia.nrc.ca> wrote:
> > On Wed 10 Apr 2002 21:44, "John David Anglin" <dave@hiauly1.hia.nrc.ca> wrote:
> > > > The latest 'snapshot' as in gcc-20020408.tar.bz2
> > > 
> > > I'll try the current cvs.
> 
> I've duplicated the problem that you found.  It's a bug in the GNU linker.
> It's not handling the relocations required for inline plabels correctly.
> The function splay_tree_new_with_allocator seg-faults when it is passed
> a pointer to the function splay_tree_xmalloc_allocate rather than a pointer
> to a function descriptor for splay_tree_xmalloc_allocate.  The problem
> is present in both 3.1 and the trunk.
> 
> :
> 
> The work around is to use the HP linker for the initial bootstrap.  I
> recommend just building C, install it, then do another full bootstrap
> using gcc and the GNU linker.  You have to use the GNU assembler for
> both builds.
> 
> Could you try another build?  Just remove "--with-gnu-ld" from your
> script and specify "--with-ld=/usr/ccs/bin/ld".  You may want to
> export LD_PXDB=/usr/bin/true to defer invocation of pxdb.

echo "int xxy_us_dummy;" >tmp-dum.c
./xgcc -B./ -B/usr/local/pa20_64/hppa64-hp-hpux11.00/bin/ -isystem /usr/local/pa20_64/hppa64-hp-hpux11.00/include -isystem /usr/local/pa20_64/hppa64-hp-hpux11.00/sys-include -S tmp-dum.c
cc1: internal error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.
make[2]: *** [s-under] Error 1
make[2]: Leaving directory `/pro/3gl/GNU/gcc-3.0.4/obj/gcc'
make[1]: *** [stage2_build] Error 2
make[1]: Leaving directory `/pro/3gl/GNU/gcc-3.0.4/obj/gcc'
make: *** [bootstrap-lean] Error 2

I've used Conf-64a and Build-64a and prepared Conf-gcc64 and Build-gcc64
Complete log of Build-64a included in the tgz

   105  17:28   Conf-64
   106  17:32   Build-64a |& tee gcc-20020408-hpux64
   107  17:54   tgz c gcc-20020408-hpux64.tgz Conf-64a Build-64a Conf-gcc64 Build-gcc64 gcc-20020408-hpux64

-- 
H.Merijn Brand        Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using perl-5.6.1, 5.7.3 & 631 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3,
  WinNT 4, Win2K pro & WinCE 2.11.  Smoking perl CORE: smokers@perl.org
http://archives.develooper.com/daily-build@perl.org/   perl-qa@perl.org
send smoke reports to: smokers-reports@perl.org, QA: http://qa.perl.org

[-- Attachment #2: gcc-20020408-hpux64.tgz --]
[-- Type: application/octet-stream, Size: 17829 bytes --]

Re: gcc-64 on HP-UX 11.00

[law]

 In message <200204111518.g3BFIoZE029965@hiauly1.hia.nrc.ca>, "John David 
Anglin
" writes:
 > Gcc doesn't generate inline plabels on the PA.  It would save one insn
 > and one data location if we could use these selectors.  However, there
 > have been problems with them in 32bit land for years.  I think the
 > current assembler can handle them but the SOM linker still doesn't
 > handle them.
Actually the SOM linker can handle them, but there are corner cases with 
very large executables where it's impossible for the SOM linker to properly
fixup an inline plabel.  For that reason we stopped using them based on
a recommendation from HP.


jeff

GCC 3.0 Status Report

[Robert Schweikert]

[-- Attachment #1: Type: text/plain, Size: 1245 bytes --]

Mark Mitchell wrote:
>
>Looking Forward
>---------------
>
>I am beginning to think about GCC 3.0.1 and GCC 3.1.  It is my goal to
>get us, finally, on a regular schedule of quarterly major releases.  I
>will present my ideas for how to achieve this to the GCC Steering
>Committee this week or very early next week.  I anticipate that a
>decision will be made within a couple of weeks.
>

Great.

I have some code here that I would like to see in GCC, it allows the
reading of command line arguments from a file, there was a discussion
about this, inspired by me, a while back. I had posted this before but I
think it got lost in the certainly more important GCC-3.0 work. This is
a proposal and I am not sure where and how it should be integrated in
GCC but am willing to do the work if I can get some pointers and help on
where and how.

Mark I know you'll have your hands full the next few days but I would
certainly appreciate if you could keep this in mind for GCC-3.01 or
GCC-3.1

Thanks,
Robert

To use the example:

- compile parser.c (gcc -o parse parser.c)
- run it (parse -I. -L/usr -@myCmdFile.txt -o cute)

--
Robert Schweikert                      MAY THE SOURCE BE WITH YOU
rjschwei@mindspring.com                         LINUX



[-- Attachment #2: parser.tgz --]
[-- Type: application/x-gzip, Size: 896 bytes --]

Re: GCC 3.0 Status Report

[Mark Mitchell]

 Mark I know you'll have your hands full the next few days but I would
> certainly appreciate if you could keep this in mind for GCC-3.01 or
> GCC-3.1

I want to discuss upcoming releases with the SC, before discussing them
in detail here.  It may be that my conception of what is appropriate
differs from the rest of the SC, so it would be wrong to commit
to anything at this point.

I am sure that, whatever is decided, there will certainly be a
mechanism for getting everyone's wishlist heard.

Thanks,

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

GCC 3.0 Status Report

[Mark Mitchell]

GCC 3.0 Status Report
=====================

Timing
------

There are 4 days until the scheduled release of GCC 3.0.

Announcement
------------

As of now, *all* non-documentation patches to the GCC 3.0 release
branch must be approved by me prior to check-in, without exception.
It would still be very helpful to me if the usual reviewers would
continue review the patches.  For example, if Alexandre would review a
configury change and say "this looks correct" that will make it much
easier for me to decide what to do.

As the week goes by, I will be less and less likely to approve
changes, especially changes whose impact is not confined to a single
target.  If a bug is theoretically cross-platform, but is only
actually showing up on one chip, we can use the `#if TARGET_FOO'
around the change in generic code in order to reduce the risk.
Obviously, this is not our normal practice, but it makes sense in this
timeframe.  It is my goal to have no check-ins after Wednesday -- but
of course the point of waiting until midnight Friday will be to see if
there is anything more we need to do.  Check-ins after Wednesday are
likely to result in a slip of our ship date.

Anyone who would normally be able to approve documentation patches may
continue to do so, through the end of 14th, GMT -0800.

If there are issues that you think absolutely must be fixed before the
release, but are not yet high-priority GNATS bugs, here is what you
should do:

  1. Make sure that the bug report is filed in GNATS.  I will not
     consider any item which does not have a GNATS report.

  2. Send me an email indicating why you think this is an 
     absolutely critical bug.  It *must* be a regression from
     GCC 2.95, and it must affect users in a particularly dire 
     way.
 
     Please explicitly name me in the `To' or `Cc' fields; there
     is so much list traffic that I might otherwise miss your
     message.

Prerelease
----------

I have created new prerelease tarballs.  Remember that the actual
release will be generated by the same script; these tarballs are
designed to perform all packaging functions that will be required for
GCC 3.0.  If you find problems with the packaging, please follow the
procedures above for reporting high-priority bugs.

The new prerelease tarballs are:

  ftp://gcc.gnu.org/pub/gcc/snapshots/gcc-3.0-20010611.tar.gz

and the similarly-named language-specific tarballs.

Please try them out.

Overview
--------

I am tremendously pleased with the number of bug reports that have
been closed since last week.  There are now only 14 remaining open
high-priority PRs, down from 68 last week.

Obviously, we have had more upheaval over the weekend, particularly in
the C++ library, than would have been ideal.  This reflects the nature
of this release, i.e., that is a release of brand new technology,
including a brand new C++ library.  It is important that everyone
remember that this is a `.0' release, and as such we must all expect
more problems than in a release that contains fewer changes.  We will
have follow-on releases in short order to fix critical bugs.

At this point, I do not anticpate delaying the release of GCC 3.0.
There is a possibility that the release will be delayed, by a matter
of a few days.  The final go/no-go decision will be based on my
perception of where we are, how much more we could achieve with very
little work, and whether or not that work would likely be
destabilizing.

Looking Forward
---------------

I am beginning to think about GCC 3.0.1 and GCC 3.1.  It is my goal to
get us, finally, on a regular schedule of quarterly major releases.  I
will present my ideas for how to achieve this to the GCC Steering
Committee this week or very early next week.  I anticipate that a
decision will be made within a couple of weeks.

Issues
------

Here is a summary of the open issues.  If you can help with any of
these please do!

CNI: Using gcj's CNI requires an explict -I switch to the compiler.
     I downgraded this PR, since that seems to be the
     consensus.  This is not a showstopper: there is a simple 
     workaround.

C++: There is an apparent strict-aliasing problem on Alpha.  I will
     try to track this down today.  PR 2758.

C++: Nathan is fixing/has fixed more problems in vtable layout.
     PR3089.

EH: Loren has patches to fix EH in the presence of threading that
    need to be moved from the mainline to the branch.  PR3082.

Reload: This is PR2876.  Bernd attempted to fix this, but the 
        patch broke IRIX.  We should try again.

Configury: In-source builds do not work.  Tom, are you still working
	   on this?  If not, please let me know so that someone
	   else can take it over.

ARM: There are still multiple ARM regressions from GCC 2.95.  There
     is still time to fix them -- but we must act extremely quickly.
     These are bugs 3037, 3053, 2878, and 817.

H8:  PR2866 looks like it might have a very simple fix that would
     only require tweaking the H8 configuration file.

AIX: David has elected not to fix this bug for this release.
     Hopefully, it will be fixed in 3.0.1.  PR3042.

68K: Bootstrap problem.  PR1795.  If this is not fixed soon, it 
     can wait for 3.0.1.

Re: GCC 3.0 Status Report

[Loren James Rittle]

In article < 20010611214848B.mitchell@codesourcery.com > you write:

> EH: Loren has patches to fix EH in the presence of threading that
>     need to be moved from the mainline to the branch.  PR3082.

For the record, this was already moved to the 3.0 branch back on
2001-06-08, the day after it appeared on mainline.  The move was
approved and encouraged by Benjamin.

I didn't closed the PR until today since I didn't know I had the
ability to directly play with GNATS until today.

Regards,
Loren

Re: GCC 3.0 Status Report

[Joseph S. Myers]

On Mon, 11 Jun 2001, Mark Mitchell wrote:

> The new prerelease tarballs are:
> 
>   ftp://gcc.gnu.org/pub/gcc/snapshots/gcc-3.0-20010611.tar.gz
> 
> and the similarly-named language-specific tarballs.
> 
> Please try them out.

Should people run the testsuite from these tarballs with 2.95.3, and send
those results to gcc-testresults?

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: GCC 3.0 Status Report

[Mark Mitchell]

> Should people run the testsuite from these tarballs with 2.95.3, and send
> those results to gcc-testresults?

It certainly won't hurt.  It also won't really work in general --
I know that for G++ a lot of the tests will pass/fail for "silly"
reasons.  In general, we know that the testsuite performance is
OK relative to 2.95.x because we know that we have only XFAILed
tests that were regressions from GCC 2.95.

I am more interested in people building from the tarballs, and
then running the resulting compiler on whatever code is handy.
Still, what you suggest is not a bad idea.

Thanks,

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC 3.0 Status Report

[Nathan Sidwell]

Mark Mitchell wrote:

> Configury: In-source builds do not work.  Tom, are you still working
>            on this?  If not, please let me know so that someone
>            else can take it over.
There's a patch from me at
http://gcc.gnu.org/ml/gcc-patches/2001-06/msg00662.html
which gets part of the way there, and is waiting for Alex's
(and now Mark's) approval. BTW, Loren Rittle, who recently
put that gthr stuff in thinks it's ok.

nathan
-- 
Dr Nathan Sidwell   ::   http://www.codesourcery.com   ::   CodeSourcery LLC
         'But that's a lie.' - 'Yes it is. What's your point?'
nathan@codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nathan@acm.org

Re: GCC 3.0 Status Report

[Tom Tromey]

Mark> Configury: In-source builds do not work.  Tom, are you still
Mark> working on this?  If not, please let me know so that someone
Mark> else can take it over.

Yes, I'm working on it.  I was blocked yesterday by the `gthr.h'
problem -- the build didn't get past libstdc++, and I still don't know
if I can reproduce the problem Nathan reported with the libjava
configure.

Nathan> There's a patch from me at
Nathan> http://gcc.gnu.org/ml/gcc-patches/2001-06/msg00662.html
Nathan> which gets part of the way there, and is waiting for Alex's
Nathan> (and now Mark's) approval. BTW, Loren Rittle, who recently
Nathan> put that gthr stuff in thinks it's ok.

I'll look at applying this and see if that helps me move forward.
Thanks.

Tom

Re: GCC 3.0 Status Report

[Joseph S. Myers]

All the Objective C tests fail with --enable-shared if the relevant shared
libraries aren't installed somewhere the dynamic linker searches.  This
isn't a regression, but gives a very bad impression to installers that the
ObjC compiler is completely broken, and I think it ought to be fixed for
3.0.  Could the Objective C maintainer look at this (PR objc/2145)?

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: GCC 3.0 Status Report

[Franz Sirl]

At 12:42 12.06.2001, Joseph S. Myers wrote:
>All the Objective C tests fail with --enable-shared if the relevant shared
>libraries aren't installed somewhere the dynamic linker searches.  This
>isn't a regression, but gives a very bad impression to installers that the
>ObjC compiler is completely broken, and I think it ought to be fixed for
>3.0.  Could the Objective C maintainer look at this (PR objc/2145)?

Well, I did

< http://gcc.gnu.org/ml/gcc-patches/2001-04/msg01394.html >

which fixes the problem for me. I think it's the right approach (same as we 
do for C++), but I would like to have a better method to detect ObjC 
compilation than to check for file extensions.

Franz.

Re: GCC 3.0 Status Report

[Stan Shebs]

Franz Sirl wrote:
> 
> At 12:42 12.06.2001, Joseph S. Myers wrote:
> >All the Objective C tests fail with --enable-shared if the relevant shared
> >libraries aren't installed somewhere the dynamic linker searches.  This
> >isn't a regression, but gives a very bad impression to installers that the
> >ObjC compiler is completely broken, and I think it ought to be fixed for
> >3.0.  Could the Objective C maintainer look at this (PR objc/2145)?
> 
> Well, I did
> 
> < http://gcc.gnu.org/ml/gcc-patches/2001-04/msg01394.html >
> 
> which fixes the problem for me. I think it's the right approach (same as we
> do for C++), but I would like to have a better method to detect ObjC
> compilation than to check for file extensions.

I poked around a bit, but couldn't think of anything better than
what your patch does.  infiles[i].language contains the actual
language to use for each file, but it's not yet set up when
lang_specific_driver is called.

So I'd say to go with what you have, for the branch at least, and
the trunk too if nobody has any other suggestions.

Stan

Re: GCC 3.0 Status Report

[Mark Mitchell]

>
> So I'd say to go with what you have, for the branch at least, and
> the trunk too if nobody has any other suggestions.

If this has not already gone in, I think it is too late.  This is
not-critical functionality in that there are ways for users to
work around the problem.

However, please make sure that we remember to reexamine this issue
after GCC 3.0, for a probably fix in the 3.0.1 release.

Thank you,

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC 3.0 Status Report

[Franz Sirl]

On Wednesday 13 June 2001 18:39, Mark Mitchell wrote:
> > So I'd say to go with what you have, for the branch at least, and
> > the trunk too if nobody has any other suggestions.
>
> If this has not already gone in, I think it is too late.  This is
> not-critical functionality in that there are ways for users to
> work around the problem.
>
> However, please make sure that we remember to reexamine this issue
> after GCC 3.0, for a probably fix in the 3.0.1 release.

OK, I'll apply it to the mainline only then.

Franz.

Re: GCC 3.0 Status Report

[Bernd Schmidt]

On Mon, 11 Jun 2001, Mark Mitchell wrote:

> Reload: This is PR2876.  Bernd attempted to fix this, but the
>         patch broke IRIX.  We should try again.

I've looked into this.  There's something extremely weird going on in
the mips backend; the reload_outdi pattern generates uninitialized uses
(at least according to the rtl) of regs 64 and 65 (lo/hi).  We end up
with a sequence of

(insn/i 213 437 452 (parallel[
            (set (reg:DI 66 accum)
                (mult:DI (zero_extend:DI (reg:SI 4 a0 [151]))
                    (zero_extend:DI (reg:SI 2 v0 [152]))))
            (clobber (reg:DI 65 lo))
            (clobber (reg:DI 64 hi))
        ] ) 41 {mulsidi3_64bit} (insn_list 211 (insn_list 212 (nil)))
    (nil))

(insn 452 213 454 (set (reg:DI 6 a2)
        (reg:DI 65 lo)) 154 {movdi_internal2} (nil)
    (nil))

It all apparently goes downhill from there.

This needs someone familiar with that target to investigate the mips.md
braindamage.


Bernd

Re: GCC 3.0 Status Report

[Geert Bosch]

On Tue, 12 Jun 2001, Bernd Schmidt wrote:
  I've looked into this.  There's something extremely weird going on in
  the mips backend; the reload_outdi pattern generates uninitialized uses
  (at least according to the rtl) of regs 64 and 65 (lo/hi).  We end up
  with a sequence of
  
  (insn/i 213 437 452 (parallel[
              (set (reg:DI 66 accum)
                  (mult:DI (zero_extend:DI (reg:SI 4 a0 [151]))
                      (zero_extend:DI (reg:SI 2 v0 [152]))))
              (clobber (reg:DI 65 lo))
              (clobber (reg:DI 64 hi))
          ] ) 41 {mulsidi3_64bit} (insn_list 211 (insn_list 212 (nil)))
      (nil))
  
  (insn 452 213 454 (set (reg:DI 6 a2)
          (reg:DI 65 lo)) 154 {movdi_internal2} (nil)
      (nil))

The mult instruction sets registers 64 and 65 to hold the lo and the
hi parts of the product (IIRC). Not knowing much about GCC internals,
I wouldn't know why that is marked as a clobber instead of a set,

Below is the relevant page from the MIPS documentation, see
< http://www.mips.com/Documentation/R4400_Uman_book_Ed2.pdf >

Appendix A
_______________________________________________________________________

MULT                               Multiply                        MULT

     31       26 25    21 20    16 15                6 5         0
     -------------------------------------------------------------
       SPECIAL  |   rs   |   rt   |          0        |   MULT
     0 0 0 0 0 0|        |        |0 0 0 0 0 0 0 0 0 0|0 1 1 0 0 0
     -------------------------------------------------------------
           6         5        5              10              6

Format:
     MULT rs, rt

Description: 
     The contents of general registers rs and rt are multiplied, 
     treating both operands as 32-bit 2s complement values. 
     No integer overflow exception occurs under any circumstances. 
     In 64-bit mode, the operands must be valid 32-bit, sign-
     extended values.  

     When the operation completes, the low-order word of the double 
     result is loaded into special register LO, and the high-order 
     word of the double result is loaded into special register HI.

     If either of the two preceding instructions is MFHI or
     MFLO, the results of these instructions are undefined.
     Correct operation requires separating reads of HI or LO
     from writes by a minimum of two other instructions.

_______________________________________________________________________
A-118                           MIPS R4000 Microprocessor User's Manual

Re: GCC 3.0 Status Report

[Roman Zippel]

Hi,

Mark Mitchell wrote:

> 68K: Bootstrap problem.  PR1795.  If this is not fixed soon, it
>      can wait for 3.0.1.

I think we have a choice here between here between a compiler that
doesn't work at all or a compiler that might work, as there was
obviously no testing done for quite some time. At bootstrap/3090, c/3092
and c/3095 there are the minimum changes described needed to get a sort
of working compiler, but even that produces more than 100 failures
during check, about half of them are regressions to 2.95. I have some
patches to reduce it to 74 failures and I'd like to help to analyze/fix
more of them.
BTW there are two new regression from 3.0 to 3.1, I'll can post them
later.

bye, Roman

Re: GCC 3.0 Status Report

[Mark Mitchell]

--On Wednesday, June 13, 2001 01:16:05 AM +0200 Roman Zippel 
<zippel@linux-m68k.org> wrote:

> Hi,
>
> Mark Mitchell wrote:
>
>> 68K: Bootstrap problem.  PR1795.  If this is not fixed soon, it
>>      can wait for 3.0.1.
>
> I think we have a choice here between here between a compiler that
> doesn't work at all or a compiler that might work

An excellent point.  And given that, I see little point in trying
to fix the bug for the release, so I will downgrade it.

The SC has just been made aware that there
are problems with many embedded targets, and discussion is underway
about what to do with respect to the 3.0 release.  One possible
alternative is to delay the release indefinitely to fix the problems,
but I hope personally that the SC will not adopt this strategy.

My personal suggestion would be that you continue your work on
fixing the problems so that we can get this target working in GCC 3.0.1.

Thank you,

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC 3.0 Status Report

[Joseph S. Myers]

On Mon, 11 Jun 2001, Mark Mitchell wrote:

> If there are issues that you think absolutely must be fixed before the
> release, but are not yet high-priority GNATS bugs, here is what you
> should do:
> 
>   1. Make sure that the bug report is filed in GNATS.  I will not
>      consider any item which does not have a GNATS report.
> 
>   2. Send me an email indicating why you think this is an 
>      absolutely critical bug.  It *must* be a regression from
>      GCC 2.95, and it must affect users in a particularly dire 
>      way.

I have filed PR other/3161 concerning release packaging issues.  The 
non-inclusion of the HTML documentation in the INSTALL directory in the 
prerelease is a critical issue for users.  The other issues are highly 
desirable to fix for the release.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: GCC 3.0 Status Report

[Gerald Pfeifer]

On Wed, 13 Jun 2001, Joseph S. Myers wrote:
> I have filed PR other/3161 concerning release packaging issues.  The
> non-inclusion of the HTML documentation in the INSTALL directory in the
> prerelease is a critical issue for users.  The other issues are highly
> desirable to fix for the release.

I've been working on this since this morning.

Patch to follow after a full release build using gcc_release.

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: GCC 3.0 Status Report

[Mark Mitchell]

=> I have filed PR other/3161 concerning release packaging issues.  The
> non-inclusion of the HTML documentation in the INSTALL directory in the
> prerelease is a critical issue for users.  The other issues are highly
> desirable to fix for the release.

Marked high, assigned to myself.  I will try to put as much as possible
into gcc_release to automate the process.

Will you and Gerald collaborate on the HTML docs?  I know that there
is a script that needs to be run, but I never fully understood what
to do, and if one of you would make the appropriate change to
gcc_release, that would be terrific.  Any such patch is preapproved.

Thank you,

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

GCC 3.0 Status Report

[Mark Mitchell]

[Note: if your name appears explicitly in the `Cc' list, there is an
       action item for you at the bottom of this report.]

GCC 3.0 Status Report
=====================

Timing
------

There are ten days until the release of GCC 3.0.

Major Annoucements
------------------

As announced in the May 21st Status Report, GNATS is now frozen.  No
new bugs can be made high priority without my express approval.  If
you wish to mark a bug high priority, you must first send me mail
explaining why fixing the bug is of *absolutely vital* import.  It
must not only be a regression from GCC 2.95 -- it must also be in some
way cataclysmic.  Failing to build the Linux kernel or the X server
for an x86 would be one example.  No optimization issue is likely to
qualify; correctness issues are probably the only likely candidates.
Crashing on illegal code for which we used to give an error mesage is
probably not a candidate.  Even failing to compile a correct, but
corner-case example, might not qualify.

Overview
--------

Unfortunately, there are many more high-priority bugs now than there
were a week ago.  I am saddenned that more of them have not been
fixed.  Many of these bugs are libstdc++ or Java bugs.  Those two
teams should focus on fixing or downgrading these bugs.  It is
important that I have an overview of what people are really trying to
fix, and what we are going to leave for another release.

The high number of open bugs, and the slow rate at which people are
fixing them, is going to force me to spend more time than I had hoped
on bug-fixing.  That means that I will have less time than I hoped for
packaging, documentation, release notes, etc.  If you are at all able
to contribute in those areas, please do so.  Gerald Pfeifer continues
to coordinate the documentation side of things.

Thanks to those who worked on the release script in my absence!  Since
there do not appear to be any packaging problem reports in GNATS, I
will assume that the tarballs work as advertised.  If you are not
contributing to the release in any other way, testing the prerelease
tarballs to make sure that they build and install is an easy and very
useful thing to do.

Fortunately, it looks like we were able to avoid testsuite regressions
for the last week, which is excellent news.

Action Items
------------

V3 Team, Java Team: Fix or downgrade V3 and Java issues.

RTH: Did we fix the ARM conditional-execution problem?
     Or should we go with the patch I proposed that you said disabled
     a lot of conditional-lifetime information?

Everyone else: Continue to fix high-priority bugs.
	       Application testing.
	       Documentation.

Re: GCC 3.0 Status Report

[Richard Henderson]

On Tue, Jun 05, 2001 at 01:23:35PM -0700, Mark Mitchell wrote:
> RTH: Did we fix the ARM conditional-execution problem?

Not yet.  I looked at it this past weekend and didn't make
much headway.  I'm going to look again this afternoon.

>      Or should we go with the patch I proposed that you said disabled
>      a lot of conditional-lifetime information?

No.  If we disable it, we should _really_ disable it, and in a very
obvious way.  Say by undefing HAVE_conditional_execution in flow.c
and putting a big comment explaining why.  Otherwise someone may look
at that code and wonder why it isn't doing what it appears that it
is supposed to be doing and get really confused.

We would also need a tiny adjustment in mark_set_1 as well -- that
ifdef block would need an

	if (cond && some_was_live)
	  not_dead = 1;


r~

Re: GCC 3.0 Status Report

[Rainer Orth]

Mark Mitchell <mark@codesourcery.com> writes:

> As announced in the May 21st Status Report, GNATS is now frozen.  No
> new bugs can be made high priority without my express approval.  If
> you wish to mark a bug high priority, you must first send me mail
> explaining why fixing the bug is of *absolutely vital* import.  It
> must not only be a regression from GCC 2.95 -- it must also be in some
> way cataclysmic.  Failing to build the Linux kernel or the X server
> for an x86 would be one example.  No optimization issue is likely to
> qualify; correctness issues are probably the only likely candidates.

There's one bug I'd like you to consider for high-priority: i.e. gcc's
non-conformance to SGI's N32/N64 ABI structure passing conventions.  This
bug is documented in the installation notes

	http://gcc.gnu.org/install/specific.html#mips*-sgi-irix6

has been in gcc since IRIX 6 support was first contributed, and has
remained unfixed since.

I tried fixing it back in 1999

	http://gcc.gnu.org/ml/gcc-patches/1999-06n/msg00544.html

but failed, both due to lack of help on crashes in other parts of the
compiler and my (still) quite limited knowledge of GCC internals.

When reviewing the Solaris 2, IRIX, and Tru64 UNIX parts of the install
docs, I was reminded of the dreaded issue and I'm now working on it again.

This problem comes up ever and ever again in the IRIX community, as

	http://freeware.sgi.com/shared/howto.html#b1

and several bug reports to gcc-bugs document (search the list archives for
inet_ntoa).  You regularly stumble across it when you try to compile some
network code, it doesn't work and you find the calls to inet_ntoa are
miscompiled.

This problem and the fact it's remained unfixed for years gives gcc
(rightly so, I'd say) a bad reputation among IRIX users, and is really
annoying.

I'd like to see a fix (developed and) integrated into GCC 3.0 since it
requires an incompatible change to the ABI to bring the code gcc produdes
in line with SGIs N32/N64 ABIs, since incompatible ABI changes have already
been announced for GCC 3.0.

As I said, I'm again investigating a fix, but am not sure if my knowledge
of gcc suffices to get this working on my own.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Faculty of Technology, Bielefeld University

Email: ro@TechFak.Uni-Bielefeld.DE

Re: GCC 3.0 Status Report

[Mark Mitchell]

>>>>> "Rainer" == Rainer Orth <ro@TechFak.Uni-Bielefeld.DE> writes:

    Rainer> There's one bug I'd like you to consider for
    Rainer> high-priority: i.e. gcc's non-conformance to SGI's N32/N64
    Rainer> ABI structure passing conventions. 

We are less than two weeks from the release, and as you say GCC has
had this bug forever.

Yes, fixing it would be good.  No, not in this release.

Thanks,

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC 3.0 Status Report

[Rainer Orth]

Mark Mitchell writes:

> >>>>> "Rainer" == Rainer Orth <ro@TechFak.Uni-Bielefeld.DE> writes:
> 
>     Rainer> There's one bug I'd like you to consider for
>     Rainer> high-priority: i.e. gcc's non-conformance to SGI's N32/N64
>     Rainer> ABI structure passing conventions. 
> 
> We are less than two weeks from the release, and as you say GCC has
> had this bug forever.
> 
> Yes, fixing it would be good.  No, not in this release.

ok.  I'll continue working on a patch anyway, maybe I can come up with
something that's both obviously correct and non-intrusive.

	Rainer

-----------------------------------------------------------------------------
Rainer Orth, Faculty of Technology, Bielefeld University

Email: ro@TechFak.Uni-Bielefeld.DE

Re: GCC 3.0 Status Report

[Joseph S. Myers]

On Tue, 5 Jun 2001, Mark Mitchell wrote:

> As announced in the May 21st Status Report, GNATS is now frozen.  No
> new bugs can be made high priority without my express approval.  If

I have restored from the list archives the old PRs that had been lost from
the database (2386 2389 2392 2394 2397 2403 2404 2419 2420 2426), except
for 2426 which I couldn't find in list archives; some of these are
priority "high" (as assigned by the person who submitted them) and need
reviewing.  In addition, some "high" priority PRs had been missing from
the index and so will now appear on searches again after I regenerated it:
2427 2438.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: GCC 3.0 Status Report

[benjamin kosnik]

> V3 Team, Java Team: Fix or downgrade V3 and Java issues.

My priorities for the next ten days:

1) loren/david threads patch

2) 3045/2346

3) solaris fseek

4) "C" header insanity

I think completion of all of these tasks is important for the release.

Mark, sorry you are disappointed with the progress, but I feel like a
lot of important bugs that got fixed. Look at the GNATS logs, there were
a lot of things accomplished. 

best,
Benjamin

Re: GCC 3.0 Status Report

[Mark Mitchell]

>>>>> "benjamin" == benjamin kosnik <bkoz@nabi.net> writes:

    >> V3 Team, Java Team: Fix or downgrade V3 and Java issues.

    benjamin> My priorities for the next ten days:

OK, thanks.  If there are open high-priority bugs that you don't think
are going to get fixed, would you downgrade them?

    benjamin> Mark, sorry you are disappointed with the progress, but
    benjamin> I feel like a lot of important bugs that got fixed. Look
    benjamin> at the GNATS logs, there were a lot of things
    benjamin> accomplished.

Disappointment != criticism.  I know everyone did a lot -- I was just
hoping to come home and find fewer open bugs.  Part of the reason
there are lots of open bugs is that people have found more bugs -- and
that's good work, not bad.

Thanks,

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC 3.0 Status Report

[Franz Sirl]

On Tuesday 05 June 2001 22:23, Mark Mitchell wrote:
> Major Annoucements
> ------------------
>
> As announced in the May 21st Status Report, GNATS is now frozen.  No
> new bugs can be made high priority without my express approval.  If
> you wish to mark a bug high priority, you must first send me mail
> explaining why fixing the bug is of *absolutely vital* import.  It
> must not only be a regression from GCC 2.95 -- it must also be in some
> way cataclysmic.  Failing to build the Linux kernel or the X server
> for an x86 would be one example.  No optimization issue is likely to
> qualify; correctness issues are probably the only likely candidates.
> Crashing on illegal code for which we used to give an error mesage is
> probably not a candidate.  Even failing to compile a correct, but
> corner-case example, might not qualify.

Mark, I just entered c++/3061, I think it qualifies as high priority bug:

- it's a regression from gcc-2.95
- it crashes kde2 on startup

Besides that I'm just back from vacation and will recheck  
kernel/glibc/xf4/etc with current gcc3.0 on PPC during the next days.

Franz.

Re: GCC 3.0 Status Report

[Mark Mitchell]

>>>>> "Franz" == Franz Sirl <Franz.Sirl-kernel@lauterbach.com> writes:

    Franz> Mark, I just entered c++/3061, I think it qualifies as high
    Franz> priority bug:

I agree, and I've marked it accordingly.

Nathan is working on a similar bug -- hopefully they will turn out to
be the same.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC 3.0 Status Report

[Alexandre Petit-Bianco]

Mark Mitchell writes:

> V3 Team, Java Team: Fix or downgrade V3 and Java issues.

I'm on it.

./A

Re: GCC 3.0 Status Report

[Mark Mitchell]

>>>>> "Alexandre" == Alexandre Petit-Bianco <apbianco@cygnus.com> writes:

    Alexandre> Mark Mitchell writes:

    >> V3 Team, Java Team: Fix or downgrade V3 and Java issues.

    Alexandre> I'm on it.

Great.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

GCC 3.0 Status Report

[Mark Mitchell]

Timing
======

There are 25 days until the release of GCC 3.0.

Overview
========

Everyone worked very hard last week.  The new ABI-compliant exceptions
are working pretty smoothly at this point, and Richard Henderson is
helping people bang out the last few bugs and build failures.  Many
bugs were fixed.  There are presently about 30 high-priority bugs
reported, which is slightly down from last week.  The reason the
number isn't lower is that a few new regressions have been found
during the week.  Some of these bugs are Java bugs; it would be good
if the Java folks would try to close out some of these.

Bernd Schmidt helped me out by providing me the release script that he
has been using.  I am cleaning it up and tweaking it to make it
support the GCC 3.0 (and future) releases.  Bernd also fixed a
critical bug on the ARM.  Thank you Bernd!

At this point, my focus will be shifting from bug-fixing to packaging,
documentation, announcements, thank-yous and other similar issues.
That means that to make significant inroads against the open bugs,
other folks will have to step up and help.  There is one particularly
scary ARM bug where apparently GCC 3.0, once installed, cannot be used
to bootstrap itself.  I would definitely like to understand this
problem better.

Requests for Help
=================

Please fix high-priority bugs.

Please continue to report regressions, and to review bugs in GNATS.

Soon, I will make prerelease test tarballs available.  These should be
packaged in the same way as the actual release will be.  Please
download them and try them out.  The most likely failure modes will be
things like that you can't build with the "core" and "c++" modules,
but without the "fortran" module, for example, or that you need
`autofoo' installed.  The prerelease tarballs will be built by cron on
a nightly basis, and posted for testing.  I will post a separate
announcement later.

Please work on documentation for the release.  Are there caveats, news
items, etc. that people should no about?  Are there undocumented
command-line options for your target?  Are there people who should be
thanked for their contributions?  Please collect such information and
send it to our documentation mainatiner: Gerald Pfeifer
<pfeifer@dbai.tuwien.ac.at>.  (Gerald, if you would like to handle the
collection of this information in a different way, please feel free to
make an alternate announcement.)  And Gerald, please add yourself to
the thank-you list for doing a fabulous job as the documentation
maintainer!

Schedule
========

Last week, I announced a June 15th release.  Once I get the release
script working, I will create a cronjob that will spin the release on
that date.  It will then require manual intervention to stop the
release from from happenning.  

(This is like sending a `launch commit' message to a nuclear missile;
it will proceed automatically to its target, even if all power fails
and the base is overrun by invaders, unless the override code is
entered.  Make of that analogy what you will.)

Below is the schedule for between now and the release.  This schedule
is designed to make sure that we are in a position to make the release
on the target date, rather than to make sure that the release is 100%
perfect at that point.  This is the tradeoff that we need to make at
this point; we've worked very hard to improve the quality of the
branch, we will now be working hard to make sure that the world gets
to see what we have done.

  Week of May 21
  --------------

  - Prepare release script.

  - Prepare automated prerelease tarballs.

  - Continue to fix critical bugs.

  Week of May 28
  --------------

  - I will be on vacation, starting May 26th. I will be in a part of
    the world that basically does not have internet access, so I will
    be totally offline.  I apologize for the poor timing, but the trip
    has been planned for months.

  - Immediate reversion policy.

    From this point forward, any patch which causes any new testsuite
    or bootstrap failures on any of our primary or secondary targets
    may be summarily reverted, without discussion.  It is more
    important that the majority of targets continue to function, and
    that people continue to have the opportunity to test them, than
    that any particular bug gets fixed.  If your patch is reverted,
    you can resubmit it after you figure out how to fix the problem,
    but you must have the revised patch reviewed again.  Tickling a
    latent bug, etc., is no excuse.  Think like a user: if it
    used to work, and now it doesn't, you broke it.

    Jeffrey Oldham will monitor the various automated builds that are
    posted nightly on CodeSourcery's server.  If he observes
    regressions in these builds from the previous day's results, he
    will identify the offending patch and remove it, posting a message
    indicating that he has done so.

    Any maintainer may take similar action, if so motivated, so as to 
    avoid waiting for Jeffrey.

  - Test prerelease tarballs.

  - Continue to fix critical bugs.
   
  - Application testing.

  Week of June 4
  --------------
 
  - GNATS freeze.  

    No new bugs can be made high-priority after this date without
    my express approval, even if they are GCC 2.95 regressions.
    Please make every effort to review open bugs for your platform,
    and to perform application testing before this point.  Until
    this point, any maintainer can mark a bug high priority if it
    is a GCC 2.95 regression.

  - Continue to fix critical bugs.

  - Application testing.

  Week of June 11
  ---------------
  
  - Code freeze.

    No checkins will be allowed this week without my express
    approval.  Practically speaking, that means that we will be
    heavily bottlenecked at this point.  Please take advantage of
    the intervening time to work with all of the people who can
    approve patches to get your changes done.

  - Final documentation changes.

  - Final application testing.
  
  - Prepare release announcement.

  June 15th
  ---------

   - Release GCC 3.0.
     
Volunteer of the Week
=====================

This week's volunteer is one of the truly versatile GCC developers.
He is also one of the most active reviewers of other people's patches.
Equally at home inn the IA64 back-end, the x86 back-end, and any part
of the optimizers, he took on the task of implementing a superior,
industry-standard exception-handling model.  This new
exception-handling model improves the size and performance of C++ and
Java code substantially, and will eventually allow GDB to set
breakpoints on a `throw' and see where the eventual `catch' will be.

The GCC 3.0 Volunteer of the Week is ...

   ... Richard Henderson.

Congratulations!

Re: GCC 3.0 Status Report

[Daniel Berlin]

Mark Mitchell <mark@codesourcery.com> writes:

> 
> Please work on documentation for the release.  Are there caveats, news
> items, etc. that people should no about?  Are there undocumented
> command-line options for your target?  Are there people who should be
> thanked for their contributions?  Please collect such information and
> send it to our documentation mainatiner: Gerald Pfeifer
> <pfeifer@dbai.tuwien.ac.at>.  (Gerald, if you would like to handle the
> collection of this information in a different way, please feel free to
> make an alternate announcement.)  And Gerald, please add yourself to
> the thank-you list for doing a fabulous job as the documentation
> maintainer!

Well, if you want the structure, order, and description of the passes, and the documentation
about how it works to be correct, you'll need to apply the patches I
sent for that part of the docs. However, that's more for people who
care about what it's doing internally, of course.

If there is some other part in dire need of updating or more docs, i'm more than
happy to make a go at it so it gets done for the release.

-- 
"Babies don't need a vacation, but I still see them at the
beach...  It pisses me off!  I'll go over to a little baby and
say, "What are you doing here?  You haven't worked a day in your
life!"
"-Steven Wright

Re: GCC 3.0 Status Report

[Dennis Bjorklund]

On Mon, 21 May 2001, Mark Mitchell wrote:

> There are 25 days until the release of GCC 3.0.

This means that there probably won't be a swedish translation even though
there are people in the swedish translation team that wants to do it. The
translationssystem is broken in gcc, and I don't understand enough of the
internals of gcc to fix it. One must not break something else that depends
on functions that are affected by the locale. These things should be fixed
there instead.

I suggest that the first thing to do after 3.0 is to fix this and then if
it breaks something else (that for example use atof, since that is
dependent of the locale) we havet to fix that there.

As gcc is now there is half a swedish translation checked in (6-8 months
old) that is basicly just used when on do gcc --help since every
translated string in the tools used by gcc is not shown.

Maybe one should disable this swedish output as well since the rest is in
english, or I should make sure that at least all the output from gcc
--help is in swedish (some strings have changed since I did the
translation).

I don't want to ship a gcc with a _very_ broken translation to swedish.
Better to not have a translation at all then.

If the translation system is fixed there is still time for us to fix the
strings, but since I don't understand all of gcc internals I don't know if
it's possible to fix now (probably not).

-- 
/Dennis

Re: GCC 3.0 Status Report

[Joseph S. Myers]

On Tue, 22 May 2001, Dennis Bjorklund wrote:

> The
> translationssystem is broken in gcc, and I don't understand enough of the
> internals of gcc to fix it. One must not break something else that depends
> on functions that are affected by the locale. These things should be fixed
> there instead.

Did NLS work in 2.95 (for the en_UK translation, if configured with 
--enable-nls)?  If so, submit a priority "high" PR as a regression.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: GCC 3.0 Status Report

[Mark Mitchell]

>>>>> "Dennis" == Dennis Bjorklund <db@zigo.dhs.org> writes:

Thanks for raising this issue.

    Dennis> I don't want to ship a gcc with a _very_ broken
    Dennis> translation to swedish.  Better to not have a translation
    Dennis> at all then.

Two questions:

- Was there a good Swedish translation in GCC 2.95?

- How do we turn off the Swedish translation?

I suspect that it will be too hard to fix the translation system at
this point, although I don't mind trying, if it's pretty non-invasive.
If we had a good translation in GCC 2.95 that would be more
compelling.  Otherwise, I think we need to, as you say, disable the
translation so that people who speak Swedish are not confused by a
hodge-podge of Swenglish.

Thanks,

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC 3.0 Status Report

[Dennis Bjorklund]

On Tue, 22 May 2001, Mark Mitchell wrote:

> - Was there a good Swedish translation in GCC 2.95?

No.

> - How do we turn off the Swedish translation?

Don't install the gcc.mo file.

> I suspect that it will be too hard to fix the translation system at
> this point, although I don't mind trying, if it's pretty non-invasive.

Well, in november(?) when the discussion was up people were afraid that it
would affect other functions that depend om the locale setting was used in
a critical way in the compiler. Like using atof to parse a number which in
many locales (like swedish) only works of you use , as the separator. So
0.45 would be read in as the number 0 while 0,45 would be read as the
number 0.45. This is a typical error that I've seen (and fixed) in many
programs.

I don't know if there really are such cases in gcc, and I don't know if
anybode knows about it. I think as sone as 3.0 is out one should just make
the change and find bugs if there are any. Maybe one could even change now
if there is a big testsuite of programs (you must already have that) so we
can make sure that most (or all) things work.

> If we had a good translation in GCC 2.95 that would be more
> compelling.  Otherwise, I think we need to, as you say, disable the
> translation so that people who speak Swedish are not confused by a
> hodge-podge of Swenglish.

As it is now it's not so bad since no of the strings are shown :-) Only
the helptext from gcc --help is translated.

The swedish translation group is quite big and active. But i'm sure that
as sone as the translationsystem works there will be many more
translations. But no one wants to do a couple of weeks work when it want
be used and were you have to redo it when the next version of gcc comes
out.

-- 
/Dennis

Re: GCC 3.0 Status Report

[Joseph S. Myers]

On Mon, 21 May 2001, Mark Mitchell wrote:

> Please work on documentation for the release.

What is the status of fixes to the doc/install.texi issues described in

http://gcc.gnu.org/ml/gcc-patches/2001-05/msg00449.html
http://gcc.gnu.org/ml/gcc-patches/2001-05/msg00634.html

?

(The former describes various problems with the Texinfo; the latter is
where part of one entry seems to have been duplicated in the middle of
another.)

Once these problems have been sorted out, I may look at doing some of the 
moving of documentation from the old install.texi to the new one.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: GCC 3.0 Status Report

[Gerald Pfeifer]

On Tue, 22 May 2001, Joseph S. Myers wrote:
> What is the status of fixes to the doc/install.texi issues described in
>
> http://gcc.gnu.org/ml/gcc-patches/2001-05/msg00449.html

It's on my TOMONITOR list ;-) and in the worst case I'll try to fit it
onto my TODO list in time for the GCC 3.0 release, though it would be
great could Dean or you have a look.

(As we haven't got a response from Dean yet, I suppose he's on holidays,
hopefully not something worse!)

> http://gcc.gnu.org/ml/gcc-patches/2001-05/msg00634.html

That's on my TODO list for today. Expect a fix soon.

> Once these problems have been sorted out, I may look at doing some of
> the moving of documentation from the old install.texi to the new one.

Great!

And I'll have a look at removing cruft from the old install.texi plus
removing wwwdocs/htdocs/install in favor of the new stuff.

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: GCC 3.0 Status Report

[Phil Edwards]

On Mon, May 21, 2001 at 06:48:12PM -0700, Mark Mitchell wrote:
>   Week of May 28
>   --------------
> 
>   - I will be on vacation, starting May 26th.
[...]
>   Week of June 4
>   --------------
>  
>   - GNATS freeze.  
> 
>     No new bugs can be made high-priority after this date without
>     my express approval, even if they are GCC 2.95 regressions.

At what point do you return from vacation?

Ah, lemme back up.  Sanity check:  you /do/ return from vacation, right?  :-)


Phil

-- 
pedwards at disaster dot jaj dot com  |  pme at sources dot redhat dot com
devphil at several other less interesting addresses in various dot domains
The gods do not protect fools.  Fools are protected by more capable fools.

Re: GCC 3.0 Status Report

[Mark Mitchell]

>>>>> "Phil" == Phil Edwards <pedwards@disaster.jaj.com> writes:

    Phil> Ah, lemme back up.  Sanity check: you /do/ return from
    Phil> vacation, right?  :-)

He, he.  

It would be nice to stay on vacation forever, but I did not win the
lottery.

I will be back June 2.

Thanks,

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC 3.0 Status Report

[Toon Moene]

Mark Mitchell wrote:

> (This is like sending a `launch commit' message to a nuclear missile;
> it will proceed automatically to its target, even if all power fails
> and the base is overrun by invaders, unless the override code is
> entered.  Make of that analogy what you will.)

"We haven't met, I think ... the name's Bond, James Bond".

[ Sorry, couldn't resist :-) ]

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction)

Re: GCC 3.0 Status Report

[Mark Mitchell]

>>>>> "Toon" == Toon Moene <toon@moene.indiv.nluug.nl> writes:

    Toon> "We haven't met, I think ... the name's Bond, James Bond".

This joke leaves me shaken, but not stirred.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC 3.0 Status Report

[Christian Iseli]

Hi,

mark at codesourcery dot com said:
> Please try to test GCC on as much software as you can.  Build
> X windows.  Build the Linux kernel.  Run 'em.  File bugs in GNATS.

Ok, I had a go at it on my Linux/Athlon machine.  So far, I compiled the kernel
(2.4.4-ac9), glibc (2.2.3 from CVS), and XFree86 (4.0.99.4 from CVS) and
installed them.  All was compiled using -O2 -march=athlon, and all seems to
work fine :)

My only issue has been reported in GNATS: c/2728.  It might be due to the 
inliner, but that's just a wild guess...  For some reason, the Priority is not 
marked high, though.

Haven't tried Qt and KDE yet...

Things are looking quite good.

Cheers,
					Christian

GCC 3.0 Status Report

[Mark Mitchell]

GCC 3.0 Status Report
=====================

Overall
-------

  The last major piece of functionality for the release (the 
  new ABI-compliant exception-handling model) has been installed.
  Accompanying this are improvements to the C++ standard library
  to work with the new model.  Thanks to Richard Henderson 
  and Benjamin Kosnik for implementing these changes.

  We are getting close to zero unexpected FAILs in the testsuites
  on many major platforms.  We will achieve this goal soon.  I have
  fixed many, many bugs in the last week or so, and disabled some
  tests that do not represent regressions.
  
  If you are a platform maintainer/tester, and you know of a bug that
  you believe is essential for the release -- in other words, that is
  is a regresssion from GCC 2.95.x -- please make sure it is in GNATS
  and marked "high" priority.  Remember that the criteria here is a
  *regression*.  At this point, if it is broken with GCC 2.95.x and
  not already fixed, it is going to stay broken.  It would take an
  earth-shatterring bug of doom to make me think otherwise.

  Please do not send me your list of bugs directly.  Put them in 
  GNATS; that is what it is for.  If you send them to me, I will
  likely delete them.  Then, I will deny every having received
  them. :-)

Schedule
--------

  I will be on vacation May 25th through June 2nd.  I was hoping
  to make the release before May 25th.  Now, I hope to make a test
  release before I go.

  At this point, I am finally willing to set a schedule.

  Previously, I believed that we should wait until certain functional
  criteria were met.  We are now very close to those requirements.
  And, time *does* matter; there really is value in getting this beast
  out the door.  

  Therefore, we're now going to pretend that the company has told us
  that we must ship by a certain date, or the copmany will be unable
  to raise additional financing, that we will be summarily fired
  without severance, and that all of our stock options will be
  worthless.  If you've worked at a dot-bomb recently, this should
  sound familiar.

  The release will be made on or before 11:59PM GMT -8 (Pacific
  Daylight Time) June 15th, 2001 A.D.  Because otherwise I will
  commit suicide at 12:00 AM on June 16th, and you will all feel
  very, very bad.

Requests for Help
-----------------

  Is there anyone willing to work on the release script?  This
  script builds a tarball from what's in CVS, but also needs to 
  add generated files not in CVS (e.g., `parse.y').  We need to 
  test that the generated tarball actually works.  This is a
  classic release engineering task.  It would be very helpful to
  me if someone who is skilled in this area would step forward,
  thereby freeing me up to continue fixing bugs.
  	
  Please track down GNATS bugs that apply to your targets,
  front-ends, etc.  Fix 'em, post 'em, check 'em in.

  Please try to test GCC on as much software as you can.  Build
  X windows.  Build the Linux kernel.  Run 'em.  File bugs in GNATS.
  
  Repeat.

Volunteer of The Week
---------------------

  This weeks winner is tireless in his efforts to clean up 
  crufty old bits of GCC.  Always willing to look for away to
  avoid the "expedient hack", he has often gone where angels, and 
  even fools, fear to tread.  Recently, he's tackled issues
  involving crufty old headers installed by GCC, ancient Makefile 
  ugliness, and ancient configury ugliness.  Someday, I fully 
  expect that he will the README.ALTOS and README.ACORN from the
  GCC directory itself.

  All of this effort will make the GCC 3.1, and every release 
  thereafter, easier -- so our Volunteer of the Week is ...

  ... Zack Weinberg!

  Congratulations.

Re: GCC 3.0 Status Report

[Joseph S. Myers]

On Mon, 14 May 2001, Mark Mitchell wrote:

>   Is there anyone willing to work on the release script?  This
>   script builds a tarball from what's in CVS, but also needs to 
>   add generated files not in CVS (e.g., `parse.y').  We need to 
>   test that the generated tarball actually works.  This is a
>   classic release engineering task.  It would be very helpful to
>   me if someone who is skilled in this area would step forward,
>   thereby freeing me up to continue fixing bugs.

Whoever does this may also want to merge it with the snapshot script.  
(Which has a few different requirements - e.g. the generated files go in
releases only, but not snapshots.)  It would be useful if the script has
the capability to produce diffs from more than one previous version -
since e.g. 3.0 ought to have diffs both from 2.95 (of limited value given
their size, but this has been done before - and someone ought to read the
diffs to find omissions from the release notes) and from 3.0-pre2 (or
whatever).

Also, though I did volunteer some months ago to convert the FOM back to a
static faq.html, given the FOM RCS files, I'd rather if someone else were
to take this on.  The aim is to restore all the original content, with all
useful changes, plus useful new FAQ entries (suitably edited; any long
ones may need copyright checks) and anything else that has been frequently
asked.  An editing pass to clean up obsolete information will then be
needed.  Links to the FOM should then revert back to links to the static
FAQ.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: GCC 3.0 Status Report

[Joe Buck]

> Whoever does this may also want to merge it with the snapshot script.  
> (Which has a few different requirements - e.g. the generated files go in
> releases only, but not snapshots.)  It would be useful if the script has
> the capability to produce diffs from more than one previous version -
> since e.g. 3.0 ought to have diffs both from 2.95 (of limited value given
> their size, but this has been done before - and someone ought to read the
> diffs to find omissions from the release notes) and from 3.0-pre2 (or
> whatever).

Diffs from 2.95 are likely to be extremely large: for a diff to remove
a library it has to include it verbatim, similarly to add one.  This means
the diff has to include all of the 2.95.x libchill, libio, libstdc++, and
all of gcc/ch to delete that, plus all of libstdc++, java, and libjava to
add that, on top of all the other differences.  In the end, the diff is
going to be almost as big as the distribution, meaning that it's not
worthwhile.

However, we do package a C-only subset (gcc-core-xxxx.tar.gz); for that,
the diff from 2.95.3 might be worth having.

Re: GCC 3.0 Status Report

[Joern Rennecke]

> Diffs from 2.95 are likely to be extremely large: for a diff to remove
> a library it has to include it verbatim, similarly to add one.  This means

Not true.  You can make an ed diff to delete the old libraries, which should
be rather short.

Re: GCC 3.0 Status Report

[Mike Stump]

> From: Joe Buck <jbuck@synopsys.COM>
> To: mrs@windriver.com (Mike Stump)
> Date: Wed, 2 May 2001 03:14:14 -0700 (PDT)

> The answer to your question is that there is no abi compatibility
> for the library, only for the compiler.

Ah, ok, thanks for the explanation.  I understand the difference, I
just hope that we communicate it with folks.  From
http://gcc.gnu.org/gcc-3.0/criteria.html:

C++ ABI

     In order to avoid changing the C++ ABI from release to release,
     as GCC has done to date, there must be a stable ABI.

C++ Standard Library

     The standard library is a part of the ABI. Changing the standard
     library interfaces is effectively a change in the ABI. It is
     important that we provide a standards-conforming C++ standard
     library.

It seems to want to lump the library ABI in with the compiler one.
This could lead to confusion, though, since it doesn't say anything
much, it isn't wrong.

Re: GCC 3.0 Status Report

[Joe Buck]

I wrote:
> > The answer to your question is that there is no abi compatibility
> > for the library, only for the compiler.

Mike Stump writes:
> Ah, ok, thanks for the explanation.  I understand the difference, I
> just hope that we communicate it with folks.  From
> http://gcc.gnu.org/gcc-3.0/criteria.html:
> 
> C++ ABI
> 
>      In order to avoid changing the C++ ABI from release to release,
>      as GCC has done to date, there must be a stable ABI.
> 
> C++ Standard Library
> 
>      The standard library is a part of the ABI. Changing the standard
>      library interfaces is effectively a change in the ABI. It is
>      important that we provide a standards-conforming C++ standard
>      library.
> 
> It seems to want to lump the library ABI in with the compiler one.
> This could lead to confusion, though, since it doesn't say anything
> much, it isn't wrong.

Yes, you're right, this is confusing.  The reason for the confusion is
historical.  Way back when we started (around the time of the egcs/FSF
reunification), some of us had fantasies about being able to freeze both
the library and the compiler ABIs for 3.0.  But the library is nowhere
near ready for freezing.  So it'll be the old rules for now: 3.0.x
compatible, 3.0 -> 3.1 may break something.  Ideally we'll be able to come
up with something in the future that allows binary compatibility for the
library as well, but I don't think that it can be frozen until some kind
of refactoring pass is done on the STL.

Re: GCC 3.0 Status Report

[Mike Stump]

> To: gcc@gcc.gnu.org
> From: Mark Mitchell <mark@codesourcery.com>
> Date: Tue, 01 May 2001 17:22:17 -0700

>   We are coming down the home stretch.

I have a random stupid question of the day...  Is it really the case
that there are no inlines anywhere in any of the C++ library that
might be taken advantage of by the user, or that any such inlines only
rely upon abi mandated things?

Failure to understand that question, means, we cannot claim C++ abi
compatibility.

Re: GCC 3.0 Status Report

[Mark Mitchell]

>>>>> "Mike" == Mike Stump <mrs@windriver.com> writes:

    Mike> I have a random stupid question of the day...  Is it really
    Mike> the case that there are no inlines anywhere in any of the
    Mike> C++ library that might be taken advantage of by the user, or
    Mike> that any such inlines only rely upon abi mandated things?

We have conveniently defined the library to be beyond the scope of the
ABI.

The ABI deals only with layout, vtables, and such.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

GCC 3.0 Status Report

[Mark Mitchell]

GCC 3.0 Status Report
=====================

Overall
-------

  We are coming down the home stretch.  The only major bit of
  work remaining is the merge of Richard/Benjamin's EH/library
  bits to the branch.  Richard, Benjamin, when can we expect
  this?

  Other than that, we just need to keep squishing bugs.  We got
  a lot of regressions fixed last week, and there will be more of
  that this week.  For the most part, we're getting successful
  bootstraps on a wide variety of platforms and the stability on
  the branch seems to be improving.

  I would like to prepare a test release in the next week or two
  for wider distribution.

Helping Out
-----------

  Lots of people are reporting problems, and there are still
  outstanding high-priority bugs in GNATS.  It would be good
  if people with particular knowledge of particular platforms
  could pitch in to solve problems.  It's difficult for me to 
  try to learn whole new architectures just to fix a bug or 
  two.

  Please try to focus on the branch, and not on mainline 
  development.

Re: GCC 3.0 Status Report

[Michael Elizabeth Chastain]

Works for me on native solaris.  Good job!  PR libstdc++/2445 can be
closed now.

Michael Chastain

Re: GCC 3.0 Status Report

[Michael Elizabeth Chastain]

> I have checked that `namespace std { extern "C" int errno; }' is not
> mangled under hpux and I don't see any regressions of the libstdc++
> or g++ testsuite under i686 linux.

Note that libstdc++ on i686 linux doesn't show the original bug,
because errno is a macro on that platform, and the expansion of
that macro uses a function and not a data symbol:

  #define errno (*__errno_location ())

The automated regression checker has native linux and I think that's
why it didn't catch this bug.

The g++ testsuite on native solaris is good for seeing the bug.
I have "std::errno" errors in tests like g++.benjamin/15071.C and
g++.brendan/copy9.C.

Michael

Re: GCC 3.0 Status Report

[John David Anglin]

> The g++ testsuite on native solaris is good for seeing the bug.
> I have "std::errno" errors in tests like g++.benjamin/15071.C and
> g++.brendan/copy9.C.

Hpux also has the bug, however, there are still problems building
libstdc++ under it due to duplicate symbol definitions.  I ran the
the check under i686 linux to make sure I didn't break something
else.  It would be great if you could try the patch on solaris.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: GCC 3.0 Status Report

[John David Anglin]

> It's not a patch -- the patch fragment you see is the patch that
> broke g++ (I think).  I don't know enough about g++ data structures
> to write a good patch.

Here is a fix for the undefined reference std::errno.  The language
experts can debate whether it is the right thing to do.  I have checked
that `namespace std { extern "C" int errno; }' is not mangled under
hpux and I don't see any regressions of the libstdc++ or g++ testsuite
under i686 linux.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

2001-04-18  John David Anglin  <dave@hiauly1.hia.nrc.ca>

	* mangle.c (mangle_decl_string): Don't mangle variables with
	extern "C" linkage.
	* decl.c (grokvardecl): Use full language declaration for `extern'
	variables.

--- mangle.c.orig	Tue Apr 17 14:38:43 2001
+++ mangle.c	Wed Apr 18 20:29:54 2001
@@ -2093,9 +2093,11 @@
 	       functions with C++ linkage.  */
 	    && (!DECL_LANG_SPECIFIC (decl) 
 		|| DECL_EXTERN_C_FUNCTION_P (decl)))
-	   /* The names of global variables aren't mangled either.  */
+	   /* The names of global and extern "C" variables aren't
+	      mangled either.  */
 	   || (TREE_CODE (decl) == VAR_DECL
-	       && CP_DECL_CONTEXT (decl) == global_namespace))
+	       && (CP_DECL_CONTEXT (decl) == global_namespace
+		   || (DECL_LANG_SPECIFIC (decl) && DECL_EXTERN_C_P (decl)))))
     write_string (IDENTIFIER_POINTER (DECL_NAME (decl)));
   else
     {
--- decl.c.orig	Mon Apr 16 17:58:53 2001
+++ decl.c	Thu Apr 19 14:58:37 2001
@@ -9022,9 +9022,10 @@
       else
 	context = NULL_TREE;
 
-      if (processing_template_decl && context)
-	/* For global variables, declared in a template, we need the
-	   full lang_decl.  */
+      if (RIDBIT_SETP (RID_EXTERN, specbits)
+	  || (processing_template_decl && context))
+	/* For `extern' variables or variables declared in a template,
+	   we need the full lang_decl.  */
 	decl = build_lang_decl (VAR_DECL, declarator, type);
       else
 	decl = build_decl (VAR_DECL, declarator, type);

Re: GCC 3.0 Status Report

[Mark Mitchell]

I'm going to tweak that around a little bit, and install it.

The things I don't like (but that aren't your fault!)

  - Users of DECL_LANGUAGE shouldn't have to check DECL_LANG_SPECIFIC.
    That's an abstraction breakdown; the fact that DECL_LANG_SPECIFIC
    is optional is an implementation detail.  That's bothered me
    for a while; now I'll fix it.

Thanks again,

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC 3.0 Status Report

[John David Anglin]

> The things I don't like (but that aren't your fault!)
> 
>   - Users of DECL_LANGUAGE shouldn't have to check DECL_LANG_SPECIFIC.
>     That's an abstraction breakdown; the fact that DECL_LANG_SPECIFIC
>     is optional is an implementation detail.  That's bothered me
>     for a while; now I'll fix it.

Yes, I stumbled on that one the first time through.  Good idea.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: GCC 3.0 Status Report

[Mark Mitchell]

Here is the patch I committed.

Tested on i6868-pc-linux-gnu, committed on the branch and on the
mainline.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

2001-04-19  Mark Mitchell  <mark@codesourcery.com>

	* cp-tree.h (DECL_LANGUAGE): Don't assume DECL_LANG_SPECIFIC is
	set.
	(SET_DECL_LANGUAGE): New macro.
	* decl.c (duplicate_decls): Use SET_DECL_LANGUAGE.
	(pushdecl): Likewise.
	(build_library_fn_1): Likewise.
	(build_cp_library_fn): Likewise.
	(grokfndecl): Likewise.
	(grokvardecl): Mark `extern "C"' variables as having C linkage.
	* decl2.c (grokclassfn): Use SET_DECL_LANGUAGE.
	* lex.c (retrofit_lang_decl): Likewise.
	* mangle.c (mangle_decl_string): Don't mangle the names of
	variables declared with C language linkage.
	* semantics.c (finish_member_declaration): Use SET_DECL_LANGUAGE.
	
Index: testsuite/g++.old-deja/g++.other/linkage7.C
===================================================================
RCS file: linkage7.C
diff -N linkage7.C
*** /dev/null	Tue May  5 13:32:27 1998
--- linkage7.C	Thu Apr 19 15:38:25 2001
***************
*** 0 ****
--- 1,14 ----
+ // Build don't link:
+ // Origin: Mark Mitchell <mark@codesourcery.com>
+ 
+ namespace N {
+   extern "C" int i;
+ 
+   void f () {
+     i = 3;
+   }
+ };
+ 
+ int i;
+ 
+ int main () { N::f (); }
Index: cp/cp-tree.h
===================================================================
RCS file: /cvs/gcc/gcc/gcc/cp/cp-tree.h,v
retrieving revision 1.572.2.18
diff -c -p -r1.572.2.18 cp-tree.h
*** cp-tree.h	2001/04/16 05:49:55	1.572.2.18
--- cp-tree.h	2001/04/19 22:38:28
*************** struct lang_decl
*** 1929,1937 ****
  #define DECL_IN_MEMORY_P(NODE) \
    (DECL_RTL_SET_P (NODE) && GET_CODE (DECL_RTL (NODE)) == MEM)
  
! /* For FUNCTION_DECLs: return the language in which this decl
!    was declared.  */
! #define DECL_LANGUAGE(NODE) (DECL_LANG_SPECIFIC(NODE)->decl_flags.language)
  
  /* For FUNCTION_DECLs: nonzero means that this function is a constructor.  */
  #define DECL_CONSTRUCTOR_P(NODE) (DECL_LANG_SPECIFIC(NODE)->decl_flags.constructor_attr)
--- 1929,1952 ----
  #define DECL_IN_MEMORY_P(NODE) \
    (DECL_RTL_SET_P (NODE) && GET_CODE (DECL_RTL (NODE)) == MEM)
  
! /* For a FUNCTION_DECL or a VAR_DECL, the language linkage for the
!    declaration.  Some entities (like a member function in a local
!    class, or a local variable) do not have linkage at all, and this
!    macro should not be used in those cases.
!    
!    Implementation note: A FUNCTION_DECL without DECL_LANG_SPECIFIC was
!    created by language-independent code, and has C linkage.  Most
!    VAR_DECLs have C++ linkage, and do not have DECL_LANG_SPECIFIC, but
!    we do create DECL_LANG_SPECIFIC for variables with non-C++ linkage.  */
! #define DECL_LANGUAGE(NODE) 				\
!   (DECL_LANG_SPECIFIC (NODE) 				\
!    ? DECL_LANG_SPECIFIC(NODE)->decl_flags.language	\
!    : (TREE_CODE (NODE) == FUNCTION_DECL			\
!       ? lang_c : lang_cplusplus))
! 
! /* Set the language linkage for NODE to LANGUAGE.  */
! #define SET_DECL_LANGUAGE(NODE, LANGUAGE) \
!   (DECL_LANG_SPECIFIC (NODE)->decl_flags.language = LANGUAGE)
  
  /* For FUNCTION_DECLs: nonzero means that this function is a constructor.  */
  #define DECL_CONSTRUCTOR_P(NODE) (DECL_LANG_SPECIFIC(NODE)->decl_flags.constructor_attr)
Index: cp/decl.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/cp/decl.c,v
retrieving revision 1.747.2.17
diff -c -p -r1.747.2.17 decl.c
*** decl.c	2001/04/12 14:16:58	1.747.2.17
--- decl.c	2001/04/19 22:38:31
*************** duplicate_decls (newdecl, olddecl)
*** 3193,3199 ****
  	  /* Make the old declaration consistent with the new one so
  	     that all remnants of the builtin-ness of this function
  	     will be banished.  */
! 	  DECL_LANGUAGE (olddecl) = DECL_LANGUAGE (newdecl);
  	  SET_DECL_RTL (olddecl, DECL_RTL (newdecl));
  	  COPY_DECL_ASSEMBLER_NAME (olddecl, newdecl);
  	  SET_IDENTIFIER_GLOBAL_VALUE (DECL_ASSEMBLER_NAME (newdecl),
--- 3193,3199 ----
  	  /* Make the old declaration consistent with the new one so
  	     that all remnants of the builtin-ness of this function
  	     will be banished.  */
! 	  SET_DECL_LANGUAGE (olddecl, DECL_LANGUAGE (newdecl));
  	  SET_DECL_RTL (olddecl, DECL_RTL (newdecl));
  	  COPY_DECL_ASSEMBLER_NAME (olddecl, newdecl);
  	  SET_IDENTIFIER_GLOBAL_VALUE (DECL_ASSEMBLER_NAME (newdecl),
*************** duplicate_decls (newdecl, olddecl)
*** 3353,3359 ****
  	     is OK.  */
  	  if (current_lang_stack
  	      == &VARRAY_TREE (current_lang_base, 0))
! 	    DECL_LANGUAGE (newdecl) = DECL_LANGUAGE (olddecl);
  	  else
  	    {
  	      cp_error_at ("previous declaration of `%#D' with %L linkage",
--- 3353,3359 ----
  	     is OK.  */
  	  if (current_lang_stack
  	      == &VARRAY_TREE (current_lang_base, 0))
! 	    SET_DECL_LANGUAGE (newdecl, DECL_LANGUAGE (olddecl));
  	  else
  	    {
  	      cp_error_at ("previous declaration of `%#D' with %L linkage",
*************** duplicate_decls (newdecl, olddecl)
*** 3667,3673 ****
  
        if (! types_match)
  	{
! 	  DECL_LANGUAGE (olddecl) = DECL_LANGUAGE (newdecl);
  	  COPY_DECL_ASSEMBLER_NAME (newdecl, olddecl);
  	  SET_DECL_RTL (olddecl, DECL_RTL (newdecl));
  	}
--- 3667,3673 ----
  
        if (! types_match)
  	{
! 	  SET_DECL_LANGUAGE (olddecl, DECL_LANGUAGE (newdecl));
  	  COPY_DECL_ASSEMBLER_NAME (newdecl, olddecl);
  	  SET_DECL_RTL (olddecl, DECL_RTL (newdecl));
  	}
*************** duplicate_decls (newdecl, olddecl)
*** 3682,3688 ****
        if (new_defines_function)
  	/* If defining a function declared with other language
  	   linkage, use the previously declared language linkage.  */
! 	DECL_LANGUAGE (newdecl) = DECL_LANGUAGE (olddecl);
        else if (types_match)
  	{
  	  /* If redeclaring a builtin function, and not a definition,
--- 3682,3688 ----
        if (new_defines_function)
  	/* If defining a function declared with other language
  	   linkage, use the previously declared language linkage.  */
! 	SET_DECL_LANGUAGE (newdecl, DECL_LANGUAGE (olddecl));
        else if (types_match)
  	{
  	  /* If redeclaring a builtin function, and not a definition,
*************** pushdecl (x)
*** 3971,3977 ****
        if (DECL_NON_THUNK_FUNCTION_P (x) && ! DECL_LANG_SPECIFIC (x))
  	{
  	  retrofit_lang_decl (x);
! 	  DECL_LANGUAGE (x) = lang_c;
  	}
  
        if (DECL_NON_THUNK_FUNCTION_P (x) && ! DECL_FUNCTION_MEMBER_P (x))
--- 3971,3977 ----
        if (DECL_NON_THUNK_FUNCTION_P (x) && ! DECL_LANG_SPECIFIC (x))
  	{
  	  retrofit_lang_decl (x);
! 	  SET_DECL_LANGUAGE (x, lang_c);
  	}
  
        if (DECL_NON_THUNK_FUNCTION_P (x) && ! DECL_FUNCTION_MEMBER_P (x))
*************** build_library_fn_1 (name, operator_code,
*** 6716,6722 ****
    DECL_ARTIFICIAL (fn) = 1;
    TREE_NOTHROW (fn) = 1;
    SET_OVERLOADED_OPERATOR_CODE (fn, operator_code);
!   DECL_LANGUAGE (fn) = lang_c;
    return fn;
  }
  
--- 6716,6722 ----
    DECL_ARTIFICIAL (fn) = 1;
    TREE_NOTHROW (fn) = 1;
    SET_OVERLOADED_OPERATOR_CODE (fn, operator_code);
!   SET_DECL_LANGUAGE (fn, lang_c);
    return fn;
  }
  
*************** build_cp_library_fn (name, operator_code
*** 6743,6749 ****
    tree fn = build_library_fn_1 (name, operator_code, type);
    TREE_NOTHROW (fn) = TYPE_NOTHROW_P (type);
    DECL_CONTEXT (fn) = FROB_CONTEXT (current_namespace);
!   DECL_LANGUAGE (fn) = lang_cplusplus;
    set_mangled_name_for_decl (fn);
    return fn;
  }
--- 6743,6749 ----
    tree fn = build_library_fn_1 (name, operator_code, type);
    TREE_NOTHROW (fn) = TYPE_NOTHROW_P (type);
    DECL_CONTEXT (fn) = FROB_CONTEXT (current_namespace);
!   SET_DECL_LANGUAGE (fn, lang_cplusplus);
    set_mangled_name_for_decl (fn);
    return fn;
  }
*************** grokfndecl (ctype, type, declarator, ori
*** 8750,8756 ****
        && ctype == NULL_TREE
        /* NULL_TREE means global namespace.  */
        && DECL_CONTEXT (decl) == NULL_TREE)
!     DECL_LANGUAGE (decl) = lang_c;
  
    /* Should probably propagate const out from type to decl I bet (mrs).  */
    if (staticp)
--- 8750,8756 ----
        && ctype == NULL_TREE
        /* NULL_TREE means global namespace.  */
        && DECL_CONTEXT (decl) == NULL_TREE)
!     SET_DECL_LANGUAGE (decl, lang_c);
  
    /* Should probably propagate const out from type to decl I bet (mrs).  */
    if (staticp)
*************** grokvardecl (type, declarator, specbits_
*** 9022,9030 ****
        else
  	context = NULL_TREE;
  
!       if (processing_template_decl && context)
! 	/* For global variables, declared in a template, we need the
! 	   full lang_decl.  */
  	decl = build_lang_decl (VAR_DECL, declarator, type);
        else
  	decl = build_decl (VAR_DECL, declarator, type);
--- 9022,9034 ----
        else
  	context = NULL_TREE;
  
!       /* For namespace-scope variables, declared in a template, we
! 	 need the full lang_decl.  The same is true for
! 	 namespace-scope variables that do not have C++ language
! 	 linkage.  */
!       if (context 
! 	  && (processing_template_decl 
! 	      || current_lang_name != lang_name_cplusplus))
  	decl = build_lang_decl (VAR_DECL, declarator, type);
        else
  	decl = build_decl (VAR_DECL, declarator, type);
Index: cp/decl2.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/cp/decl2.c,v
retrieving revision 1.437.2.11
diff -c -p -r1.437.2.11 decl2.c
*** decl2.c	2001/04/06 06:30:08	1.437.2.11
--- decl2.c	2001/04/19 22:38:33
*************** grokclassfn (ctype, function, flags, qua
*** 1020,1026 ****
  
    /* Even within an `extern "C"' block, members get C++ linkage.  See
       [dcl.link] for details.  */
!   DECL_LANGUAGE (function) = lang_cplusplus;
  
    if (fn_name == NULL_TREE)
      {
--- 1020,1026 ----
  
    /* Even within an `extern "C"' block, members get C++ linkage.  See
       [dcl.link] for details.  */
!   SET_DECL_LANGUAGE (function, lang_cplusplus);
  
    if (fn_name == NULL_TREE)
      {
Index: cp/lex.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/cp/lex.c,v
retrieving revision 1.237.2.3
diff -c -p -r1.237.2.3 lex.c
*** lex.c	2001/04/12 14:17:00	1.237.2.3
--- lex.c	2001/04/19 22:38:33
*************** retrofit_lang_decl (t)
*** 1513,1523 ****
  
    DECL_LANG_SPECIFIC (t) = ld;
    if (current_lang_name == lang_name_cplusplus)
!     DECL_LANGUAGE (t) = lang_cplusplus;
    else if (current_lang_name == lang_name_c)
!     DECL_LANGUAGE (t) = lang_c;
    else if (current_lang_name == lang_name_java)
!     DECL_LANGUAGE (t) = lang_java;
    else my_friendly_abort (64);
  
  #ifdef GATHER_STATISTICS
--- 1513,1523 ----
  
    DECL_LANG_SPECIFIC (t) = ld;
    if (current_lang_name == lang_name_cplusplus)
!     SET_DECL_LANGUAGE (t, lang_cplusplus);
    else if (current_lang_name == lang_name_c)
!     SET_DECL_LANGUAGE (t, lang_c);
    else if (current_lang_name == lang_name_java)
!     SET_DECL_LANGUAGE (t, lang_java);
    else my_friendly_abort (64);
  
  #ifdef GATHER_STATISTICS
Index: cp/mangle.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/cp/mangle.c,v
retrieving revision 1.26.4.6
diff -c -p -r1.26.4.6 mangle.c
*** mangle.c	2001/04/16 05:49:55	1.26.4.6
--- mangle.c	2001/04/19 22:38:33
*************** mangle_decl_string (decl)
*** 2085,2101 ****
    if (TREE_CODE (decl) == TYPE_DECL)
      write_type (TREE_TYPE (decl));
    else if (/* The names of `extern "C"' functions are not mangled.  */
! 	   (TREE_CODE (decl) == FUNCTION_DECL 
  	    /* But overloaded operator names *are* mangled.  */
! 	    && !DECL_OVERLOADED_OPERATOR_P (decl)
! 	    /* If there's no DECL_LANG_SPECIFIC, it's a function built
! 	       by language-independent code, which never builds
! 	       functions with C++ linkage.  */
! 	    && (!DECL_LANG_SPECIFIC (decl) 
! 		|| DECL_EXTERN_C_FUNCTION_P (decl)))
  	   /* The names of global variables aren't mangled either.  */
  	   || (TREE_CODE (decl) == VAR_DECL
! 	       && CP_DECL_CONTEXT (decl) == global_namespace))
      write_string (IDENTIFIER_POINTER (DECL_NAME (decl)));
    else
      {
--- 2085,2099 ----
    if (TREE_CODE (decl) == TYPE_DECL)
      write_type (TREE_TYPE (decl));
    else if (/* The names of `extern "C"' functions are not mangled.  */
! 	   (DECL_EXTERN_C_FUNCTION_P (decl)
  	    /* But overloaded operator names *are* mangled.  */
! 	    && !DECL_OVERLOADED_OPERATOR_P (decl))
  	   /* The names of global variables aren't mangled either.  */
  	   || (TREE_CODE (decl) == VAR_DECL
! 	       && CP_DECL_CONTEXT (decl) == global_namespace)
! 	   /* And neither are `extern "C"' variables.  */
! 	   || (TREE_CODE (decl) == VAR_DECL
! 	       && DECL_EXTERN_C_P (decl)))
      write_string (IDENTIFIER_POINTER (DECL_NAME (decl)));
    else
      {
Index: cp/semantics.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/cp/semantics.c,v
retrieving revision 1.189.2.7
diff -c -p -r1.189.2.7 semantics.c
*** semantics.c	2001/04/18 07:52:56	1.189.2.7
--- semantics.c	2001/04/19 22:38:34
*************** finish_member_declaration (decl)
*** 1858,1864 ****
       A C language linkage is ignored for the names of class members
       and the member function type of class member functions.  */
    if (DECL_LANG_SPECIFIC (decl) && DECL_LANGUAGE (decl) == lang_c)
!     DECL_LANGUAGE (decl) = lang_cplusplus;
  
    /* Put functions on the TYPE_METHODS list and everything else on the
       TYPE_FIELDS list.  Note that these are built up in reverse order.
--- 1858,1864 ----
       A C language linkage is ignored for the names of class members
       and the member function type of class member functions.  */
    if (DECL_LANG_SPECIFIC (decl) && DECL_LANGUAGE (decl) == lang_c)
!     SET_DECL_LANGUAGE (decl, lang_cplusplus);
  
    /* Put functions on the TYPE_METHODS list and everything else on the
       TYPE_FIELDS list.  Note that these are built up in reverse order.

Re: GCC 3.0 Status Report

[Joe Buck]

Mark writes:

> + // Build don't link:
> + // Origin: Mark Mitchell <mark@codesourcery.com>
> + 
> + namespace N {
> +   extern "C" int i;
> + 
> +   void f () {
> +     i = 3;
> +   }
> + };
> + 
> + int i;
> + 
> + int main () { N::f (); }

Perhaps I'm missing something, but if you say "Build don't link"
it seems that the test does not catch the error.  If We get an .o
file that incorrectly references N::i, it's still a valid .o file.
The program must be linked to reveal the undefined symbol.  Right?

Re: GCC 3.0 Status Report

[Mark Mitchell]

>>>>> "Joe" == Joe Buck <jbuck@racerx.synopsys.com> writes:

    Joe> Perhaps I'm missing something, but if you say "Build don't
    Joe> link" it seems that the test does not catch the error. 

Yes.

Thanks for spotting this.  I'll check in the obvious change -- use
`Build don't run'.

Thanks,

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC 3.0 Status Report

[Benjamin Kosnik]

it has to be a macro, sadly.

Of couse, you've squashed a bug anyway, and I'm grateful.

-benjamin

Re: GCC 3.0 Status Report

[Fergus Henderson]

On 19-Apr-2001, John David Anglin <dave@hiauly1.hia.nrc.ca> wrote:
> Here is a fix for the undefined reference std::errno.  The language
> experts can debate whether it is the right thing to do.
...
> 	* mangle.c (mangle_decl_string): Don't mangle variables with
> 	extern "C" linkage.

That's the right thing to do.

The relevant text in the C++ standard is 7.5 [dcl.link] paragraph 2:

 | Two declarations for an object with C language linkage with the same
 | name (ignoring the namespace names that qualify it) that appear in
 | different namespace scopes refer to the same object.

Personally I don't think this one was a particularly good decision
(e.g. because it will cause trouble if a future extension of C
adds namespaces...), but that's what the committee decided.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
                                    |  of excellence is a lethal habit"
WWW: < http://www.cs.mu.oz.au/~fjh >  |     -- the last words of T. S. Garp.

Re: GCC 3.0 Status Report

[Michael Elizabeth Chastain]

Hi Jeff,

I picked up a fragment of a message that looks like it came from you:

http://gcc.gnu.org/ml/gcc/2001-04/msg00874.html
> The most common problem I see is due to the std::errno failures.  So if
> someone has a workaround/fix for that I would greatly appreciate a copy.

I analyzed this and found the patch fragment that broke it.
See PR libstdc++/2445 for the whole story.  Here's some URL's:

  http://gcc.gnu.org/ml/gcc-prs/2001-04/msg00272.html
  http://gcc.gnu.org/ml/gcc-prs/2001-04/msg00273.html

If I am misreading the gcc mailing list archive and you're not
the guy quoted above, my apologies.

(I'm frustrated because I keep seeing people reporting this bug, and I
know what the problem is, but my PR and my mail to gcc@gcc.gnu.org are
lost in the noise).

Michael

Re: GCC 3.0 Status Report

[John David Anglin]

> The most common problem I see is due to the std::errno failures.  So if 
> someone has a workaround/fix for that I would greatly appreciate a copy.

See < http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/c_std/bits/std_cerrno.h.diff?cvsroot=gcc&r1=1.5&r2=1.6 >
for what was done on the main.  This probably isn't the correct solution.
It looks like extern "C" identifiers shouldn't be mangled in namespaces.

I did a couple more tests night to try to diagnose the constructor problem.
However, when I changed CFLAGS to `-O0 -g', I ran smack into the duplicate
symbol problem building libstdc++-v3.  Functions (constructors) that wannabe
weak are getting duplicated in two or more modules as global functions with
weak support turned off.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: GCC 3.0 Status Report

[John David Anglin]

Forwarded message:
From dave Tue Apr 17 19:11:04 EDT 2001
Subject: Re: GCC 3.0 Status Report
To: gcc@gcc.gn.org, law@redhat.com
Date: Tue, 17 Apr 2001 19:11:04 -0400 (EDT)
From: "John David Anglin" <dave@hiauly1>
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 2640      

> Last Week
> =========

> Jeff Law reported some initial success building GCC 3.0 on HPUX.  The
> compiler is now bootstrapping, but libstdc++ V3 is still not working.
> If you can help out with the debugging task (either because you're a
> PA expert or a V3 expert or a general GCC expert), please do so.  The
> best way to help is probably to contact Jeff Law (law@redhat.com)
> directly.

I am currently doing a build with a hack to avoid the std::errno
problem with respect to libstdc++-v3.  However, the number of failures
is still about the same:

                === g++ Summary for unix/-fPIC ===

# of expected passes            5531
# of unexpected failures        868
# of unexpected successes       2
# of expected failures          93
# of untested testcases         20

I looked at one of them briefly.  The test builds and runs successfully
if linked with `-static'.  When linked with the shared libstdc++-v3,
the test fails almost immediately with a segmentation fault (I think
running __cxx_new_vec.  When I try to single step with gdb, it dumps
core.  It helps to link with immediate binding.  Adb works better than
gdb.  Maybe this gives a clue as to the problem:

>adb g++-bugs-900220_03-C.x
:r
g++-bugs-900220_03-C.x: running (process 4061)
segmentation violation
stopped at      0xC132DA80:     LDW             1980(r20),r20
0xC132DA70,8?ia
0xC132DA70:     LDW             -260(r30),r19
0xC132DA74:     STW             r28,-256(r30)
0xC132DA78:     ADDIL           L%0xffff7000,r19
0xC132DA7C:     OR              r1,r0,r20
0xC132DA80:     LDW             1980(r20),r20
0xC132DA84:     OR              r20,r0,r22
0xC132DA88:     LDWS            0(r20),r20
0xC132DA8C:     LDO             1(r20),r20
0xC132DA90:
$r
pcoqh 0xC132DA83
pcoqt 0xC132DA87
rp    0xC132DA73

arg0  7B006C90      arg1  0             arg2  0             arg3  7AFF289C
sp    7B03AE60      ret0  7B006BB0      ret1  10C8C00       dp    40001308
r1    0xFFFF7000    r3    7AFFA89C      r4    1             r5    7B03A730
r6    7B03A738      r7    7B03A860      r8    7B03A860      r9    4003A2C0
r10   4003AAC0      r11   400372C0      r12   4003AB04      r13   3F
r14   3F            r15   3D            r16   3D            r17   3A
r18   40036822      r19   0             r20   0xFFFF7000    r21   0xC0087EC0
r22   7B006BB0      r31   7B006C90      sar   8             sr0   0
sr1   1138          sr2   5A94          sr3   0             sr4   62DE

The address in r20 is clearly wacko.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)


-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: GCC 3.0 Status Report

[Gabriel Dos Reis]

"John David Anglin" <dave@hiauly1.hia.nrc.ca> writes:

| I am currently doing a build with a hack to avoid the std::errno
| problem with respect to libstdc++-v3.

I think the std::errno problem you're seeing is an instance of a
bigger problem^W regresssion in the front-end -- I was privately told
that g++ is mangling names declared in extern "C" blocks.  I didn't
have the opportunity to take a closer look at it, however :-(

-- Gaby

Re: GCC 3.0 Status Report

[John David Anglin]

> | I am currently doing a build with a hack to avoid the std::errno
> | problem with respect to libstdc++-v3.
> 
> I think the std::errno problem you're seeing is an instance of a
> bigger problem^W regresssion in the front-end -- I was privately told
> that g++ is mangling names declared in extern "C" blocks.  I didn't
> have the opportunity to take a closer look at it, however :-(

Yes, I would certainly believe this to be the case when the extern "C" blocks
are in a namespace.  However, I don't think this is the reason there is
a problem running constructors in a shared library under hpux.  In the
one test program that I tried, it did run successfully when linked with
`-static'.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: GCC 3.0 Status Report

[Michael Elizabeth Chastain]

Hi GCC hackers,

I have some insight on a libstdc++ V3 problem that's been hitting hpux
and irix and solaris (the std::errno problem).  I wrote a long analysis
in PR libstdc++/2445.

I think the problem is in the attached patch fragment which was committed
on 2001-03-20.  It handles function names, and it handles global data
names, but it doesn't handle extern "C" data names within namespaces.
So this construct fails:

  namespace std { extern "C" int errno; }

The "errno" name shouldn't get mangled, but it does.

Michael Elizabeth Chastain
<chastain@redhat.com>
"love without fear"

===

diff -u -r -N 2001-03-20-14-00-00/source/gcc/cp/mangle.c 2001-03-20-14-05-00/source/gcc/cp/mangle.c
--- 2001-03-20-14-00-00/source/gcc/cp/mangle.c	Thu Feb 22 13:37:39 2001
+++ 2001-03-20-14-05-00/source/gcc/cp/mangle.c	Tue Mar 20 14:03:45 2001
@@ -2069,6 +2069,17 @@
 
   if (TREE_CODE (decl) == TYPE_DECL)
     write_type (TREE_TYPE (decl));
+  else if (/* The names of `extern "C"' functions are not mangled.  */
+	   (TREE_CODE (decl) == FUNCTION_DECL 
+	    /* If there's no DECL_LANG_SPECIFIC, it's a function built
+	       by language-independent code, which never builds
+	       functions with C++ linkage.  */
+	    && (!DECL_LANG_SPECIFIC (decl) 
+		|| DECL_EXTERN_C_FUNCTION_P (decl)))
+	   /* The names of global variables aren't mangled either.  */
+	   || (TREE_CODE (decl) == VAR_DECL
+	       && CP_DECL_CONTEXT (decl) == global_namespace))
+    write_string (IDENTIFIER_POINTER (DECL_NAME (decl)));
   else
     {
       write_mangled_name (decl);

GCC 3.0 Status Report

[Mark Mitchell]

Last Week
=========

Jeff Law reported some initial success building GCC 3.0 on HPUX.  The
compiler is now bootstrapping, but libstdc++ V3 is still not working.
If you can help out with the debugging task (either because you're a
PA expert or a V3 expert or a general GCC expert), please do so.  The
best way to help is probably to contact Jeff Law (law@redhat.com)
directly.

Many bugs were fixed by a wide variety of people.

I closed about 25 high-priority bug reports in GNATS, many of which
represented regressions from GCC 2.95.x.  Others represented bugs that
were already fixed, or that were not really bugs.

Jeffrey Oldham began looking into problems (again!) with building GCC
3.0 on IRIX.  Apparently, some change somewhere has caused us to
exceed static limits in the IRIX linker when building libstdc++ V3.
This may require libtool modifications to fix.

Next Week
=========

More of the same, mostly.

We are making relatively good progress at this point; stabilization
seems to be occurring.

Kudos
=====

For working hard on fixing IA64 bugs , and for lending a hand with a
number of tricky issues, including DWARF2 debugging and obscure
historical artifcats of GCC, this week's GCC 3.0 Volunter of the Week
is ...

  ... Jim Wilson!

Congratulations!

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC 3.0 Status Report

[Toon Moene]

Here's an update on the Fortran status:

There are 9 non-closed bug reports in the GNATS database on Fortran and
1 on libf2c.

Fortran:

 275: An ICE on a -O1 -mabi=64 compile on mips-sgi-irix6.5
      This is a regression w.r.t. 2.95.2

 542: g77 doesn't support direct access files larger than 2Gbyte on
      32-bit targets
      A feature request - suspended

 947: An assert on using an INTEGER*2 value as an array index in a
      DATA statement - a genuine frontend error
      This is not a regression

1645: This is g77.f-torture/execute/20010116.f.  Fails on i?86
      This is a regression w.r.t. 2.95.3

1832: g77 -fbounds-check doesn't catch string bounds overrun on
      internal write
      This has always been uncaught - no regression

2031: This is g77.f-torture/compile/20000511-2.f.  Fails on
      mips-sgi-irix6.5 with -O3 -g
      This is a regression w.r.t. 2.95

2033: g77 -ffixed-line-length-none blah.f gives warning:
      unknown register name: line-length-none
      Cute, but wrong - a regression w.r.t. 2.95.3

2153: g77 gives misleading error message when dummy argument of a
      statement function is also declared as an array.
      A feature request - this has been wrong always - suspended.

2193: An installation failure on HPUX 10.20 of 2.95.2 (perhaps someone
      with HPUX experience can look into this one ?)

libf2c:

 941: Configure fails on libf2c when cross-compiling because the
      configure script uses auto-host.h which is host, not target,
      specific
      Way beyond my understanding of the cross-compiling infrastructure

Hope this is useful,

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction)

Re: GCC 3.0 Status Report

[Mark Mitchell]

Thanks a lot for putting this together!  That's a great summary.

I'll look at some of the failures.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC 3.0 Status Report

[Andreas Schwab]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 545 bytes --]

The following patch needs approval:

http://gcc.gnu.org/ml/gcc-patches/2001-04/msg00236.html

Without that it is impossible to compile standard compliant code that uses
names that are conflicting with the extensions declared by _GNU_SOURCE.

Andreas.

-- 
Andreas Schwab                                  "And now for something
SuSE Labs                                        completely different."
Andreas.Schwab@suse.de
SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5

Re: GCC 3.0 Status Report

[Mark Mitchell]

I suspect Jason made this change because something in the standard C++
library requires this, and you can't rely on c++config.h being
included soon enough.

In any case, Jason is probably the best person to contact about the
change.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC 3.0 Status Report

[Gabriel Dos Reis]

Mark Mitchell <mark@codesourcery.com> writes:

| I suspect Jason made this change because something in the standard C++
| library requires this, and you can't rely on c++config.h being
| included soon enough.

Hmm, if that is the case, then that thing needs to be isolated.

Andreas has a sensible point.

-- Gaby
CodeSourcery, LLC                       http://www.codesourcery.com

Re: GCC 3.0 Status Report

[Mark Mitchell]

>>>>> "Gabriel" == Gabriel Dos Reis <Gabriel.Dos-Reis@cmla.ens-cachan.fr> writes:

    Gabriel> Mark Mitchell <mark@codesourcery.com> writes:

    Gabriel> | I suspect Jason made this change because something in
    Gabriel> the standard C++ | library requires this, and you can't
    Gabriel> rely on c++config.h being | included soon enough.

    Gabriel> Hmm, if that is the case, then that thing needs to be
    Gabriel> isolated.

    Gabriel> Andreas has a sensible point.

Yes.  I thought *I* posted some comments along these lines to the V3
mailing list at one point.

The basic problem is that some parts of the C++ library rely on some
parts of the C ibrary beyond what the ANSI/ISO C library provides.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC 3.0 Status Report

[Phil Edwards]

On Wed, Apr 18, 2001 at 07:51:25PM -0700, Mark Mitchell wrote:
> 
> I suspect Jason made this change because something in the standard C++
> library requires this, and you can't rely on c++config.h being
> included soon enough.

I had played around at one point with the idea of c++config.h being
-include'd by all C++ programs, via the default specs.  A cow-orker did so
in a local tree, and it caused problems all over the place.  IIRC some C++
feature tests were failing during autoconf.  We concluded that we didn't
know how to properly augment the lang-specs file...

Anyhow, since c++config.h includes os_defines.h, this approach would
obviate the need for CPLUSPLUS_CPP_SPEC on AIX and the like.  Just put
the defines in os_define.h and every translation unit will see them.


Phil

-- 
pedwards at disaster dot jaj dot com  |  pme at sources dot redhat dot com
devphil at several other less interesting addresses in various dot domains
The gods do not protect fools.  Fools are protected by more capable fools.

GCC 3.0 Status Report

[Mark Mitchell]

Not too much happenned last week.  

I moved from near Palo Alto, CA to near Sacramento, CA, so I saw a lot
more of Pottery Barn than I did of GCC.  Pottery Barn definitely has
better lighting. :-)

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

GCC 3.0 Status Report
=====================

Overall
-------

  If people would begin building commonly used programs (XWindows,
  Emacs, etc.) with the GCC 3.0 branch and reporting any problems, 
  that would be great.  I will set up a more formal mechanism for that
  shortly.
 
  Bug-fixing continues on the branch.

  Although not directly related to the release, Jeffrey Oldham
  collected some interesting statistics about how often GCC has failed
  to bootstrap recently.  There was some interesting follow-on
  discussion.

Last Week
---------
   
  Neil Booth merged over some preprocessor improvements, which
  are expected to be the last major preprocessor changes before
  the release.

  Many other people contributed miscellaneous bug fixes.

Next Week
---------

  More bug fixing.  Hopefully prepare test kits.  

  Application testing.

Re: GCC 3.0 Status Report

[Joseph S. Myers]

On Tue, 3 Apr 2001, Mark Mitchell wrote:

> Not too much happenned last week.  

What is the status of review of open bugs?  GNATSweb shows 663 PRs in
state "open" - i.e. unreviewed, presuming that reviewers have changed the
state to "analyzed" when confirming bugs.  (Some of these are recent PRs,
but plenty aren't.)

>   If people would begin building commonly used programs (XWindows,
>   Emacs, etc.) with the GCC 3.0 branch and reporting any problems, 
>   that would be great.  I will set up a more formal mechanism for that
>   shortly.

I'll suggest again that, though not in the release criteria, TeX is a
worthwhile program to try to build, since there have been problems
triggered by TeX in more than one previous release.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: GCC 3.0 Status Report

[Toon Moene]

"Joseph S. Myers" wrote:

> On Tue, 3 Apr 2001, Mark Mitchell wrote:

> > Not too much happenned last week.

> What is the status of review of open bugs?

Fortran: 8 open, 2 analyzed, 3 suspended (change-request, 1 duplicate).
Libf2c:  1 open.

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction)

GCC 3.0 Status Report

[Mark Mitchell]

Only one day late this week...

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

GCC 3.0 Status Report
=====================

Overall
-------

  Relatively little happenned.  In a way, this is a good thing; I
  think we are getting close to having most of the major bug
  fixes incorporated that we will need.

  Application testing should become the major focus at this point.

Last Week
---------

  Jason Merill cleaned up some issues involving `.' and `$' in 
  identifiers.  

  I checked in various patches to improve compile-time time and
  space usage in C++, including lazy name-mangling and throttling
  of the tree-based inliner.

  Jim Wilson and Jakub Jelinek cleaned up after me when I broke
  things.

Kudos
-----

  For volunteering to track down an obscure bug, and succeeding in
  doing so, despite my fervent attempts to lead him down a wrong
  path, the GCC 3.0 Volunteer of the Week is ...

    ... Richard Kenner!

  Congratulations!

Next Week
---------

  Application testing.

  Fix critical bugs.

Re: GCC 3.0 Status Report

[David Edelsohn]

	My list of remaining AIX gcc-3.0 bugs is:

PPC fast-math bugfix (Geoff)
g77 __builtin_sqrt missing symbol regression on branch
expr.c argument passing patch (from Feb)
--shared-libgcc conflicts with --shared

David

RE: GCC 3.0 Status Report

[Peter Bienstman]

>Last Week
>---------
>
>  Analysis of open bugs is largely complete.  Many of the remainder
>  are hard to analyze due to being target-specific in various ways.

Strange, GNATS still lists almost 600 bug reports in the 'open' state, i.e.
not analysed by anyone.

Are these reports that people have looked at, but forgot to put in the
'analysed' state?

Peter

GCC 3.0 Status Report

[Mark Mitchell]

I was flaky with the weekly status report over the last couple of
weeks, but I'm trying to turn over a new leaf.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

GCC 3.0 Status Report
=====================

Overall
-------

  The Steering Committee has concluded that the release criteria
  are somewhat over-ambitious given the lack of resources available
  to complete some of the tasks.

  Therefore, the GCC 3.0 release will be largely a functionality
  release, featuring the rewritten x86 back-end, improved Java
  compiler, new C++ ABI, and new C++ standard library.  Stability
  will remain a focus, but quality of the generated code will
  become a secondary priority.  This withstanding, we believe that
  GCC 3.0 will generate better code than GCC 2.95.x in many 
  circumstances.

  In the short term, we will focus on compile-time performance, 
  especially in C++.  At that point, application testing will 
  become the major focus.  Performance of the generated code
  will be a greater focus of the 3.1 release.

Last Week
---------

  Analysis of open bugs is largely complete.  Many of the remainder
  are hard to analyze due to being target-specific in various ways.

  Richard Henderson provided a number of DWARF2 fixes and
  improvements.  Zack Weinberg checked in a number of cleanups
  to simply configuration.

  I began working on a variety of compile-time performance
  optimizations.  One of the lowest-hanging pieces of fruit appears
  to be lazy name-mangling in C++.  I've got that working and will
  check it in soon.  Preliminary work on this project broke the ARM
  bootstrap.  This turned out to be a generic optimization bug; it
  is now fixed.

  Numerous other bugs fixed.

Kudos
-----

  For his continuing work on the GCC 3.0 documentation and web-site, 
  the GCC 3.0 Volunteer of the Week is ...

    ... Gerald Pfeifer!

  Congratulations!

Next Week
---------

  Work on compile-time performance.

  Fix critical bugs.

Re: GCC 3.0 Status Report

[Craig Rodrigues]

On Mon, Mar 19, 2001 at 12:28:04PM -0800, Mark Mitchell wrote:
> Overall
> -------
> 
>   The Steering Committee has concluded that the release criteria
>   are somewhat over-ambitious given the lack of resources available
>   to complete some of the tasks.
> 
>   Therefore, the GCC 3.0 release will be largely a functionality
>   release, featuring the rewritten x86 back-end, improved Java
>   compiler, new C++ ABI, and new C++ standard library.  Stability
>   will remain a focus, but quality of the generated code will
>   become a secondary priority.  This withstanding, we believe that
>   GCC 3.0 will generate better code than GCC 2.95.x in many 
>   circumstances.

Has the Committee decided to reduce the number of applications
which must compile as an acceptance criteria for a gcc 3.0 release?
(I'm referring to the ones on: http://gcc.gnu.org/gcc-3.0/criteria.html ).

The criteria web page lists a set of platforms on which gcc 3.0 must
build and work in order for the 3.0 release to be accepted.
Must the applications listed on this web page compile and run on
all the acceptance platforms?  (this does not make sense for things
like compiling the Linux kernel under Solaris, but it may make sense for
Emacs or POOMA).

Has any thought been given to using something like
Blitz ( http://oonumerics.org/blitz/ , a C++ library for doing matrix
mathematics which makes very aggressive use of templates) for
testing the template features in gcc 3.0?

Thanks.
-- 
Craig Rodrigues        
http://www.gis.net/~craigr    
rodrigc@mediaone.net          

Re: GCC 3.0 Status Report

[Mark Mitchell]

>>>>> "Craig" == Craig Rodrigues <rodrigc@mediaone.net> writes:

    Craig> Has the Committee decided to reduce the number of
    Craig> applications which must compile as an acceptance criteria
    Craig> for a gcc 3.0 release?  (I'm referring to the ones on:
    Craig> http://gcc.gnu.org/gcc-3.0/criteria.html ).

Not at this time.

    Craig> Has any thought been given to using something like Blitz
    Craig> ( http://oonumerics.org/blitz/ , a C++ library for doing
    Craig> matrix mathematics which makes very aggressive use of
    Craig> templates) for testing the template features in gcc 3.0?

POOMA is even more aggressive than Blitz in this respect.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC 3.0 Status Report

[Geoff Keating]

Mark Mitchell <mark@codesourcery.com> writes:

>   In the short term, we will focus on compile-time performance, 
>   especially in C++.  At that point, application testing will 
>   become the major focus.  Performance of the generated code
>   will be a greater focus of the 3.1 release.

Hi Mark,

I have some news for you, which might be good or might be bad, your
choice :-).

Jason Merrill took over the PCH stuff from where I left it, and
finished the C++ support.  Based on the numbers I had for C, I
expected a 2x or 3x speed improvement, which is nice but not
earth-shattering.  However, we have some new numbers from Daniel
Berlin which indicates that the speed improvement is more on the order
of 20x, when compiling KDE; I guess I just didn't realize how huge C++
headers were.  Dan says 'I can now compile all of KDE in the time it
took to compile one file before'.

I think this is such a significant improvement that it makes
consideration of compile-time improvements in the current compiler
much less important.  Of course, a 20% increase is still a significant
increase, but I expect the profile of GCC with PCH to be different to
that for GCC without PCH, and so it might be that a 5% increase goes
turns out to be a .5% increase.  I don't think anyone has tried tuning
the PCH code for performance yet, for instance, and there are a bunch
of places where I noted a possible speed problem when I was writing it
and designed the code so that if it became a problem it could easily
be improved.

The state of this code is that we're just about to ship it to the
customer.  We've stopped finding bugs in it, but probably only because
we've run out of things we know to test.  It basically works, but
there's still significant work to do before it's really finished, in
particular there's a lot of duplicated functionality between the PCH
code and the GC code.  We could put it into FSF GCC right now, at the
cost of some instability, but it's not tested enough to be in the 3.0
release.  Also, the customer hasn't accepted the release yet, and we
don't usually submit stuff until it's paid for, at least not all of
it, and I expect final acceptance for this code to take longer than
usual not least of which because I expect the customer to try it on
their sources and find lots of bugs.

So my proposal is that compile-time performance for the 3.0 release be
downgraded in importance; that we move as much as possible of PCH into
the mainline FSF tree as soon as possible, so that others can work on
it and so that it can be integrated into the 3.1 release; and that the
main feature of the 3.1 release will be compile-time speed
improvements, much of which will be provided by precompiled headers.

Of course, there are some things that could be done that would speed
up 3.0 and speed up PCH even more; for instance, GC is one of the
things that take more time with PCH because PCH creates lots of
permanent objects right at the start of compilation, so improvements
to how GC handles permanent objects will be a big win.

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: GCC 3.0 Status Report

[Mark Mitchell]

Thanks for the news; it's very helpful to know about the current
state, and the performance wins sound great.

Of course, if 3.0 is unusably slower than 2.95 (and some have claimed
that), then what we do in 3.1 doesn't really matter much.

Also, it's fair to point out that there's no guarantee that your PCH
work will ever go into the FSF GCC.  The design will have to be vetted
on the FSF lists before that happens.  I don't expect there to be
problems, but, as with any contribution, all the issues have to be
weighed before anything on this scale is accepted.

Your points regarding GC are right on the money.  I've got half-way
sort-of patches to do generational GC, which will solve the permanent
object problem, and should provide a major win.  But, nothing in
anything like finished form yet.

Thanks,

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC 3.0 Status Report

[Stan Shebs]

Mark Mitchell wrote:
> 
> Of course, if 3.0 is unusably slower than 2.95 (and some have claimed
> that), then what we do in 3.1 doesn't really matter much.

As usual with FSF releases, there is a wide spectrum of reactions.
x.0 releases typically get a lot of slack; everybody realizes that
they're a step forward, and are not going to insist on perfection.
Back in the 1 -> 2 transition, 1.x went through several more releases
after 2.0 came out, and a 2.x compiler didn't get really wide usage
until 2.3 or so.  The key thing is to hear from the clients (users
and redistributors) whether they're satisfied with the branch as it
stands.

In Apple's own case, we're unlikely to use 3.0 for production, but a
3.1 in the fall would be pretty interesting, especially with a good
PCH implementation.  So it doesn't really matter to us if 3.0 has
problems, because we'll be working on the latest code, but a long
delayed release will push back the dates for followon, and that would
be more of a concern.

> Also, it's fair to point out that there's no guarantee that your PCH
> work will ever go into the FSF GCC.  The design will have to be vetted
> on the FSF lists before that happens.  I don't expect there to be
> problems, but, as with any contribution, all the issues have to be
> weighed before anything on this scale is accepted.

I'd certainly like to take a look!  In OS X we have a working example
of precompiled headers to compare for functionality and ease of use,
and I'd like to know if the Red Hat version will be adequate.

Stan

Re: GCC 3.0 Status Report

[Daniel Berlin]

Stan Shebs <shebs@apple.com> writes:

> I'd certainly like to take a look!  In OS X we have a working example
> of precompiled headers to compare for functionality and ease of use,
> and I'd like to know if the Red Hat version will be adequate.
> 
Last I checked, the OS-X version is implemented as a seperate program,
and doesn't work for C++ (Admittedly, I haven't touched the OS X
developer tools since the public beta really, but that's the last
visible release i've had access to, as my CD with a release candidate
from the student program hasn't arrived yet).
So I wouldn't consider it adequate anyway.
No offense or anything, it's just worthless to me (and a lot of
others) if it doesn't work with C++.




> Stan

Re: GCC 3.0 Status Report

[Stan Shebs]

Daniel Berlin wrote:
> 
> Stan Shebs <shebs@apple.com> writes:
> 
> > I'd certainly like to take a look!  In OS X we have a working example
> > of precompiled headers to compare for functionality and ease of use,
> > and I'd like to know if the Red Hat version will be adequate.
> >
> Last I checked, the OS-X version is implemented as a seperate program,

Yes, it's a semi-intelligent cpp, written in Objective-C++ no less.

> and doesn't work for C++ 

Heh, I spent a good chunk of last year making it parse C++; learned
a little more about the fine points of C++ syntax than I really
wanted to know. :-)  You'll see the result of that work for the
first time in OS X GM - although it's not enabled by default, use
cc -cpp-precomp to get it.

In any case, by "adequate" I just mean the way the precomp system fits
into large-scale builds.  Although Apple's precomp setup is not the
ideal, without it OS X would be shipping months from now, not at the
end of the week.  As Geoff noted, it's one thing to have a first working
version, and another to have passed many millions of lines of code
through it.

Stan

Re: GCC 3.0 Status Report

[Mark Mitchell]

>>>>> "Stan" == Stan Shebs <shebs@apple.com> writes:

    Stan> Daniel Berlin wrote:
    >>  Stan Shebs <shebs@apple.com> writes:
    >> 
    >> > I'd certainly like to take a look!  In OS X we have a working

Me, too!

I meant to imply no criticism.  

Whenever anyone does a design/implementation of feature X privately,
it is appropriate for everyone else to take a look at it, rather than
just saying "oh, good now we have X".

I've heard of about 5 different ways to do precompiled headers -- and
each has their strengths and weaknesses.  From what I've heard
(including offline discussions with Geoff), I think a pretty
reasonable set of tradeoffs has been made in this case.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC 3.0 Status Report

[Daniel Berlin]

Geoff Keating <geoffk@geoffk.org> writes:

> Mark Mitchell <mark@codesourcery.com> writes:
> 
> >   In the short term, we will focus on compile-time performance, 
> >   especially in C++.  At that point, application testing will 
> >   become the major focus.  Performance of the generated code
> >   will be a greater focus of the 3.1 release.
> 
> Hi Mark,
> 
> I have some news for you, which might be good or might be bad, your
> choice :-).
> 
> Jason Merrill took over the PCH stuff from where I left it, and
> finished the C++ support.  Based on the numbers I had for C, I
> expected a 2x or 3x speed improvement, which is nice but not
> earth-shattering.  However, we have some new numbers from Daniel
> Berlin which indicates that the speed improvement is more on the order
> of 20x, when compiling KDE; I guess I just didn't realize how huge C++
> headers were.   Dan says 'I can now compile all of KDE in the time it
> took to compile one file before'.

One directory, not one file.
It's "almost" that fast, however.

Even on secondary platforms, like BeOS (the original tests were done
on my powerbook running powerpc-linux), i see similar speed
improvements (a factor of 15 to 24).

For instance, one large C++ project i work on, it takes at least 30 seconds
just to finish including all the headers on quite a few of the
files. This means I actually ended 
up having to stuff as many implementations of misc classes as possible
in single files, or files where they didn't belong, to avoid massive compilation times. 
For a test, I seperated these misc classes out,and without PCH, it
takes about 5-10  minutes to compile these 10 simple (< 100 lines) class
implementations, that happen to require a lot of headers
(not my fault, nor could it really be avoided. A lot of mixins and whatnot).

Even doing a single one of these files without PCH takes about a
minute to two minutes.
With PCH on, it takes 4 seconds per file, including the time from
start to object file appearing.
And fork is pretty slow on BeOS  (it's one of those "takes a while to
run configure" platforms).
I'm not joking.

Most of the 4 seconds seems to get spent in a GC right after it sees the first
thing in the implementation (I assume it's starting to lazy load
things from the PCH headers at this point and there is a ggc_collect
where it isn't the best idea anymore, or PCH is creating a lot of
objects that aren't goint to be gotten rid of, since the GC reclaims
just about nothing).


On C programs, I see about the performance improvement you do (I took
evolution, 
precompiled  glib, gtk, and the includes that are most used in
evolution (camel.h, etc), and got a 2-3x compile time improvement).
> So my proposal is that compile-time performance for the 3.0 release be
> downgraded in importance; that we move as much as possible of PCH into
> the mainline FSF tree as soon as possible, so that others can work on
> it and so that it can be integrated into the 3.1 release; and that the
> main feature of the 3.1 release will be compile-time speed
> improvements, much of which will be provided by precompiled headers.
> 
> Of course, there are some things that could be done that would speed
> up 3.0 and speed up PCH even more; for instance, GC is one of the
> things that take more time with PCH because PCH creates lots of
> permanent objects right at the start of compilation, so improvements
> to how GC handles permanent objects will be a big win.

This must be what I just noticed with the GC taking most of the 4
seconds.

-- 

Hackers have kernel knowledge.

Re: GCC 3.0 Status Report

[Geoff Keating]

Daniel Berlin <dberlin@redhat.com> writes:

> Most of the 4 seconds seems to get spent in a GC right after it sees
> the first thing in the implementation (I assume it's starting to
> lazy load things from the PCH headers at this point and there is a
> ggc_collect where it isn't the best idea anymore, or PCH is creating
> a lot of objects that aren't goint to be gotten rid of, since the GC
> reclaims just about nothing).

Yes, what happens is that the PCH machinery reads zillions of objects
from the file, and then the very next time that ggc_collect is called
it sees that lots of memory has been allocated and it tries to
collect.  Of course, this is never going to be helpful, since all of
those zillions of objects are referenced otherwise they wouldn't have
been saved in the first place.

Probably the thing to do is to have the PCH machinery add to
G.allocated_last_gc the size of the objects it allocates, because it
knows those objects will not be collectable before the next
ggc_collect().


There's no lazy loading yet.  Everything is loaded in at once.  That's
one of the reasons I'm so impressed with the big speed increase, that
was the kind of increase we were hoping to get out of PCH+lazy loading.

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: GCC 3.0 Status Report

[Daniel Berlin]

Geoff Keating <geoffk@geoffk.org> writes:

> Mark Mitchell <mark@codesourcery.com> writes:
> 
> >   In the short term, we will focus on compile-time performance, 
> >   especially in C++.  At that point, application testing will 
> >   become the major focus.  Performance of the generated code
> >   will be a greater focus of the 3.1 release.
> 
> Hi Mark,
> 
> I have some news for you, which might be good or might be bad, your
> choice :-).
> 
> Jason Merrill took over the PCH stuff from where I left it, and
> finished the C++ support.  Based on the numbers I had for C, I
> expected a 2x or 3x speed improvement, which is nice but not
> earth-shattering.  However, we have some new numbers from Daniel
> Berlin which indicates that the speed improvement is more on the order
> of 20x, when compiling KDE; I guess I just didn't realize how huge C++
> headers were.

Just to give you some idea of the largeness of C++ headers, I took a
random KDE app, khotkeys, took all of the headers it includes that
aren't specific to itself (IE those in qt2/include and kde2/include
only), through them in a file, and -save-temps'd it, and removed
blank lines, to see how much code it was:

bash-2.04# cat test.cc
#include "test.h"
bash-2.04# cat test.h
#include <kapp.h>
#include <klineedit.h>
#include <kwin.h>
#include <krun.h>
#include <kdesktopfile.h>
#include <ksimpleconfig.h>
#include <kurifilter.h>
#include <kstddirs.h>
#include <kdebug.h>
#include <kuniqueapp.h>
#include <qtimer.h>
#include <dcopobject.h>
#include <kurifilter.h>
#include <kglobalaccel.h>
bash-2.04# remblanklines test.ii
bash-2.04# wc test.ii
   8780   38085  300160 noblanks
This isn't uncommon, and is the very low end (khotkeys is three C++
files, total). 

--Dan