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

Altivec + 16 byte alignment

[Gianni Tedesco]

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

Hi,

I'm currently working on a project which uses altivec (as inline
assembly) to perform 3d affine transformations, and some other 3d vector
functions.

I have a problem in that altivec requires all inputs to be 16 byte
aligned, so I am placing my vectors in a structure like this:

struct vector {
	float x,y,z,w;
}__attribute__((aligned(16)));

This seems to work for global variables, but when allocated on the
stack, my structures end up mis-aligned (on to 8-byte boundaries) which
totally screws up the results of the altivec computation.

Is this a compiler problem, or can't the compiler be expected to
guarantee alignments that large?

gcc version 2.95.4 20010319 (prerelease/franzo/20011204)

PS. Is there any documentation about the vector support directly in C? I
hear gcc3 has that feature.

Thanks.

PS. Please CC replies, im not a list subscriber.

-- 
// Gianni Tedesco (gianni at scaramanga dot co dot uk)
lynx --source www.scaramanga.co.uk/gianni-at-ecsc.asc | gpg --import
8646BE7D: 6D9F 2287 870E A2C9 8F60 3A3C 91B5 7669 8646 BE7D

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Altivec + 16 byte alignment

[Gianni Mariani]

Gianni Tedesco wrote:

>Hi,
>
>I'm currently working on a project which uses altivec (as inline
>assembly) to perform 3d affine transformations, and some other 3d vector
>functions.
>
>I have a problem in that altivec requires all inputs to be 16 byte
>aligned, so I am placing my vectors in a structure like this:
>
>struct vector {
>	float x,y,z,w;
>}__attribute__((aligned(16)));
>
>This seems to work for global variables, but when allocated on the
>stack, my structures end up mis-aligned (on to 8-byte boundaries) which
>totally screws up the results of the altivec computation.
>
>Is this a compiler problem, or can't the compiler be expected to
>guarantee alignments that large?
>

This is a problem with the malloc implementation.

Most malloc's support 8 byte alignment.  You could specifically tune one 
of the
many malloc packages out there to be 16 byte aligned and hence this 
would solve
your problem.

>
>gcc version 2.95.4 20010319 (prerelease/franzo/20011204)
>
>PS. Is there any documentation about the vector support directly in C? I
>hear gcc3 has that feature.
>
>Thanks.
>
>PS. Please CC replies, im not a list subscriber.
>
>  
>

Re: Altivec + 16 byte alignment

[Gianni Mariani]

Gianni Mariani wrote:

> Gianni Tedesco wrote:
>
>>
>> This seems to work for global variables, but when allocated on the
>> stack, my structures end up mis-aligned (on to 8-byte boundaries) which
>> totally screws up the results of the altivec computation.
>
..

> This is a problem with the malloc implementation.

I should read the question better next time ... *STACK* ...

....

Well, you could use alloca and simply align it yourself ....

Yours
Dipstick

Re: Altivec + 16 byte alignment

[Gianni Tedesco]

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

On Tue, 2003-02-11 at 14:49, Gianni Mariani wrote:
> Well, you could use alloca and simply align it yourself ....

Yeah, but that kinda sucks because everywhere in the program where my
'struct vector' (or any struct that includes it) is used people would
have to allocate it, and if they forget to allocate they get no
problems....until its compiled with altivec operations turned on, so may
make things real hard to debug :(

-- 
// Gianni Tedesco (gianni at scaramanga dot co dot uk)
lynx --source www.scaramanga.co.uk/gianni-at-ecsc.asc | gpg --import
8646BE7D: 6D9F 2287 870E A2C9 8F60 3A3C 91B5 7669 8646 BE7D

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Altivec + 16 byte alignment

[tm_gccmail]

On Tue, 11 Feb 2003, Gianni Mariani wrote:

> Gianni Tedesco wrote:
> 
> >Hi,
> >
...
> >This seems to work for global variables, but when allocated on the
> >stack, my structures end up mis-aligned (on to 8-byte boundaries) which
> >totally screws up the results of the altivec computation.
> >
> >Is this a compiler problem, or can't the compiler be expected to
> >guarantee alignments that large?
> >
> 
> This is a problem with the malloc implementation.
> 
> Most malloc's support 8 byte alignment.  You could specifically tune one 
> of the
> many malloc packages out there to be 16 byte aligned and hence this 
> would solve
> your problem.

malloc is not responsible for allocating stack space, and therefore cannot
be implicated as the culprit for the set of circumstances he is
describing.

The basic problem is the compiler does not know the alignment of the
staack when the function is entered, so it doesn't know the amount of
offset required to align the stack to a particular boundary.

The only way to solve this is to example the stack pointer at runtime and
mask off bits in it to align the stack, which isn't currently supported
as an option in gcc.

Toshi

Re: Altivec + 16 byte alignment

[Michael S. Zick]

On Tuesday 11 February 2003 04:07 am, Gianni Tedesco wrote:
> Hi,
>
> I'm currently working on a project which uses altivec (as inline
> assembly) to perform 3d affine transformations, and some other 3d vector
> functions.
>
> I have a problem in that altivec requires all inputs to be 16 byte
> aligned, so I am placing my vectors in a structure like this:
>
> struct vector {
> 	float x,y,z,w;
> }__attribute__((aligned(16)));
>
> This seems to work for global variables, but when allocated on the
> stack, my structures end up mis-aligned (on to 8-byte boundaries) which
> totally screws up the results of the altivec computation.
>
> Is this a compiler problem, or can't the compiler be expected to
> guarantee alignments that large?
>
> gcc version 2.95.4 20010319 (prerelease/franzo/20011204)
>
> PS. Is there any documentation about the vector support directly in C? I
> hear gcc3 has that feature.
>
> Thanks.
>
> PS. Please CC replies, im not a list subscriber.
Gianni,

A description of one solution can be found in Appendix F of:
ftp://download.intel.com/design/PentiumII/manuals/24512701.pdf
If you are talking about the ia32 hardware.

I do not think gcc 2.95.4 will do that unless you modify the
function prologue generation.

The gcc 3.x.y series has a lot of work done on altivec support
but I can not answer if stack alignment is controllable in any
of them yet.  Perhaps someone working in that area will be
able to respond.

Mike

Re: Altivec + 16 byte alignment

[Gianni Tedesco]

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

On Tue, 2003-02-11 at 14:26, Michael S.Zick wrote:
> I do not think gcc 2.95.4 will do that unless you modify the
> function prologue generation.

sure, I found yellowdog gcc-altivec which appears to have fixed the
problem but this could just be chance...

> The gcc 3.x.y series has a lot of work done on altivec support
> but I can not answer if stack alignment is controllable in any
> of them yet.  Perhaps someone working in that area will be
> able to respond.

Yes, it would be nice to know definitively, I am hoping to document my
trials and tribulations with altivec on my website.

-- 
// Gianni Tedesco (gianni at scaramanga dot co dot uk)
lynx --source www.scaramanga.co.uk/gianni-at-ecsc.asc | gpg --import
8646BE7D: 6D9F 2287 870E A2C9 8F60 3A3C 91B5 7669 8646 BE7D

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Altivec + 16 byte alignment

[Daniel Egger]

On Tue, 2003-02-11 at 11:07, Gianni Tedesco wrote:

> gcc version 2.95.4 20010319 (prerelease/franzo/20011204)

Please do yourself a favour and ditch that Motorola crap. Gcc supports
AltiVec natively since 3.1 and does a much better job at things similar
to your problem.

Your problem is fixed by supplying the -mabi=altivec switch to gcc 3.1
or later as demonstrated by the following dump program:

struct vector {
  float x,y,z,w;
}__attribute__((aligned(16)));
                                                                                
int main (void)
{
  short a = 0;
  struct vector b = {1, 2, 3};
  int c = 4;
  struct vector d = {4, 5, 6};
  printf ("address: %p\n", &a);
  printf ("address: %p\n", &b);
  printf ("address: %p\n", &c);
  printf ("address: %p\n", &d);
}


egger@sonja:~$ gcc  -o test test.c
egger@sonja:~$ ./test
address: 0x7ffff9a8
address: 0x7ffff9b0
address: 0x7ffff9c0
address: 0x7ffff9c8

egger@sonja:~$ gcc  -mabi=altivec -o test test.c
egger@sonja:~$ ./test
address: 0x7ffff9a8
address: 0x7ffff9b0
address: 0x7ffff9c0
address: 0x7ffff9d0

> PS. Is there any documentation about the vector support directly in C? I
> hear gcc3 has that feature.

Check back with altivec.h in gcc 3.1 or later. The C implementation is
horrible though compared to the C++ one realized with overloading.

--
Servus,
       Daniel

Re: Altivec + 16 byte alignment

[Segher Boessenkool]

Gianni Tedesco wrote:

> PS. Is there any documentation about the vector support directly in C? I
> hear gcc3 has that feature.

As this is just GCC's implementation of the Motorola C
extensions for Altivec, why not read their documentation? :)

(Some small things are different with GCC, mainly constant
vector syntax iirc).

"AltiVec Technology Programming Interface Manual"
http://www.motorola.com/SPS/PowerPC/teksupport/teklibrary/manuals/altivecpim.pdf
(The url might have changed; it was here when I got it, but that's
somewhere in 2000).

I also quite like:

"AltiVec Support In MrC[pp]"
ftp://ftp.apple.com/developer/Development_Kits/altivec/altivec_support_in_MrC.pdf

(especially the appendices) although of course not everything
in there is (directly) applicable to GCC.

Hope this helps,


Segher

Re: Altivec + 16 byte alignment

[Michael S. Zick]

On Wednesday 12 February 2003 05:32 am, Segher Boessenkool wrote:
>
> "AltiVec Technology Programming Interface Manual"
> http://www.motorola.com/SPS/PowerPC/teksupport/teklibrary/manuals/altivecpi
>m.pdf (The url might have changed; it was here when I got it, but that's
> somewhere in 2000).
>
Looks like it got archived, try:
http://merchant.hibbertco.com/fs22/deact/fs22/pdf-docs/motorola/altivecpem.rev0.pdf

Mike

Re: Altivec + 16 byte alignment

[John David Anglin]

> I have a problem in that altivec requires all inputs to be 16 byte
> aligned, so I am placing my vectors in a structure like this:
> 
> struct vector {
>         float x,y,z,w;
> }__attribute__((aligned(16)));

We had a similar problem with respect to the alignment of data for
the ldcw instruction on the PA which needs 16-byte alignment on PA 1.X.
We have found an alternative solution.  However, the patch below
will allow the aligned attribute to be respected for stack locals
up to PREFERRED_STACK_BOUNDARY.  Note however, that alignment of
stack locals is only guaranteed up to STACK_BOUNDARY.  The default
alignment for structs on the stack is BIGGEST_ALIGNMENT, which I
presume is set 64 (8 bytes).

It may well be with altvec you really want BIGGEST_ALIGNMENT set to
256, but the change would affect the ABI and alignment of long doubles.
The i386 code provides an example of what needs doing if there are
types such as long doubles that don't require natural alignment.

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

2003-02-11  John David Anglin  <dave.anglin@nrc-cnrc.gc.ca>

	* function.c (assign_stack_temp_for_type): Allow user to increase
	alignment of stack locals up to PREFERRED_STACK_BOUNDARY.

Index: function.c
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/function.c,v
retrieving revision 1.388
diff -u -3 -p -r1.388 function.c
--- function.c	27 Nov 2002 02:29:12 -0000	1.388
+++ function.c	6 Dec 2002 23:07:56 -0000
@@ -650,6 +650,12 @@ assign_stack_temp_for_type (mode, size, 
   else
     align = GET_MODE_ALIGNMENT (mode);
 
+  /* Allow the user to increase the default alignment with the aligned
+     attribute but bound the range.  */
+  if (type && TYPE_USER_ALIGN (type))
+    align = MIN (MAX (TYPE_ALIGN (type), align),
+		 MAX (PREFERRED_STACK_BOUNDARY, align));
+
   if (! type)
     type = (*lang_hooks.types.type_for_mode) (mode, 0);
 

Re: Altivec + 16 byte alignment

[Franz Sirl]

At 18:25 11.02.2003, John David Anglin wrote:
> > I have a problem in that altivec requires all inputs to be 16 byte
> > aligned, so I am placing my vectors in a structure like this:
> >
> > struct vector {
> >         float x,y,z,w;
> > }__attribute__((aligned(16)));
>
>We had a similar problem with respect to the alignment of data for
>the ldcw instruction on the PA which needs 16-byte alignment on PA 1.X.
>We have found an alternative solution.  However, the patch below
>will allow the aligned attribute to be respected for stack locals
>up to PREFERRED_STACK_BOUNDARY.  Note however, that alignment of
>stack locals is only guaranteed up to STACK_BOUNDARY.  The default
>alignment for structs on the stack is BIGGEST_ALIGNMENT, which I
>presume is set 64 (8 bytes).
>
>It may well be with altvec you really want BIGGEST_ALIGNMENT set to
>256, but the change would affect the ABI and alignment of long doubles.
>The i386 code provides an example of what needs doing if there are
>types such as long doubles that don't require natural alignment.

BIGGEST_ALIGNMENT is 128, but STACK_BOUNDARY is 64 unless you give 
-mabi=altivec (in 3.2+). Now, if we would increase STACK_BOUNDARY to be 
always 128 on powerpc-linux-gnu, would this affect binary compatibility at 
all? I can't think of a situation where this would happen, but maybe I'm wrong?
If changing STACK_BOUNDARY doesn't affect binary compatibility, I will 
submit a patch to set it to 128 in rs6000/linux.h.

Franz.

Re: Altivec + 16 byte alignment

[David Edelsohn]

>>>>> Franz Sirl writes:

Franz> BIGGEST_ALIGNMENT is 128, but STACK_BOUNDARY is 64 unless you give 
Franz> -mabi=altivec (in 3.2+). Now, if we would increase STACK_BOUNDARY to be 
Franz> always 128 on powerpc-linux-gnu, would this affect binary compatibility at 
Franz> all? I can't think of a situation where this would happen, but maybe I'm wrong?
Franz> If changing STACK_BOUNDARY doesn't affect binary compatibility, I will 
Franz> submit a patch to set it to 128 in rs6000/linux.h.

	The patch will be wrong and not accepted.

David

Re: Altivec + 16 byte alignment

[Franz Sirl]

At 19:32 11.02.2003, David Edelsohn wrote:
> >>>>> Franz Sirl writes:
>
>Franz> BIGGEST_ALIGNMENT is 128, but STACK_BOUNDARY is 64 unless you give
>Franz> -mabi=altivec (in 3.2+). Now, if we would increase STACK_BOUNDARY 
>to be
>Franz> always 128 on powerpc-linux-gnu, would this affect binary 
>compatibility at
>Franz> all? I can't think of a situation where this would happen, but 
>maybe I'm wrong?
>Franz> If changing STACK_BOUNDARY doesn't affect binary compatibility, I will
>Franz> submit a patch to set it to 128 in rs6000/linux.h.
>
>         The patch will be wrong and not accepted.

Uhm, wrong in which way? Would you mind to explain this a bit?

Franz.

Re: Altivec + 16 byte alignment

[Spundun Bhatt]

On Tue, 2003-02-11 at 10:57, Franz Sirl wrote:
> At 19:32 11.02.2003, David Edelsohn wrote:
> > >>>>> Franz Sirl writes:
> >
> >Franz> If changing STACK_BOUNDARY doesn't affect binary compatibility, I will
> >Franz> submit a patch to set it to 128 in rs6000/linux.h.
> >
> >         The patch will be wrong and not accepted.
> 
> Uhm, wrong in which way? Would you mind to explain this a bit?
> 
With all the discussion going on... I didnt see any replies to this
question... (I might have missed it... the threading in evolution for
this thread is skrewed up). Can somebody explain why this is wrong? To
me it looks pretty straight forward to simply change STACK_BOUNDARY to
128. Not that I care though.
Hope this helps
Spundun
> Franz.

Re: Altivec + 16 byte alignment

[Spundun Bhatt]

On Wed, 2003-02-12 at 09:26, Gianni Tedesco wrote:
> On Tue, 2003-02-11 at 22:33, Spundun Bhatt wrote:
> > On Tue, 2003-02-11 at 10:57, Franz Sirl wrote:
> > > At 19:32 11.02.2003, David Edelsohn wrote:
> > > > >>>>> Franz Sirl writes:
> > > >
> > > >Franz> If changing STACK_BOUNDARY doesn't affect binary compatibility, I will
> > > >Franz> submit a patch to set it to 128 in rs6000/linux.h.
> > > >
> > > >         The patch will be wrong and not accepted.
> > > 
> > > Uhm, wrong in which way? Would you mind to explain this a bit?
> 
> I think because the efficient way to do it is for the caller to always
> keep the stack aligned. eg: initial stack pointer is aligned to 16 bytes
> and all functions make sure their stack frames align to 16 also.
> 
> If you have functions with smaller aligned stack and then they call the
> altivec functions then the altivec function would have to look at the
> stack pointer and align it by hand, which would require a conditional
> branch, argh.
> 
Ofcourse you are right. This means that this trick wont work if used in
a library code if the library is used with an older gcc compiler which
doesnt support this bigger alignement. Also wont work if used for
callbacks with the library using the callbacks not suppoirting this
bigger alignement... and may be many other such instances. 
While this does say that there will be a binary incompatibility between
gcc versions... this incompatibility will only be for this wider
alignement issues. This doesnt in *any* way seems to break backward
compatibility. In general whenever a new feature is added to a software,
the new feature is not supposed to work in the older versions but the
backward compatibility needs to be preserved.. right? 
So I think Franz' question is still up in the air.... Unless ofcourse, I
didnt get your point
Thanx 
Spundun
> I guess...
> 
> HTH.

Re: Altivec + 16 byte alignment

[Richard Henderson]

On Tue, Feb 11, 2003 at 07:29:37PM +0100, Franz Sirl wrote:
> Now, if we would increase STACK_BOUNDARY to be 
> always 128 on powerpc-linux-gnu, would this affect binary compatibility at 
> all?

Very much so.


r~

Re: Altivec + 16 byte alignment

[Franz Sirl]

On Wednesday 12 February 2003 01:42, Richard Henderson wrote:
> On Tue, Feb 11, 2003 at 07:29:37PM +0100, Franz Sirl wrote:
> > Now, if we would increase STACK_BOUNDARY to be
> > always 128 on powerpc-linux-gnu, would this affect binary compatibility
> > at all?
>
> Very much so.

I'm feeling dumb, but can you give an example? AFAICS STACK_BOUNDARY only 
affects the alignment of objects on the stack, argument aligning is 
independent from it and the stack pointer is kept aligned (to 256 bits) by 
independent code as well, so how can these objects passed between functions 
without passing pointers to the objects as well?

Franz.

Re: Altivec + 16 byte alignment

[Richard Henderson]

On Wed, Feb 12, 2003 at 10:07:54PM +0100, Franz Sirl wrote:
> ... and the stack pointer is kept aligned (to 256 bits) by 
> independent code as well

Is this 256 bits ABI mandated?  I.e. will a non-gcc ppc
compiler maintain this alignment as well?

If yes, then STACK_ALIGNMENT is set too low.  You should
advertise what you have.  If no, then calling between two
functions compiled with different compilers will not 
preserve the 256 bit alignment you claim.

There are passes in gcc, particularly combine, that look
at the advertised alignment for a pointer and know that
the low bits are zero, and perform optimizations based on
this.  If the alignment doesn't exist, the optimizations
produce incorrect results.


r~

Re: Altivec + 16 byte alignment

[Franz Sirl]

On Wednesday 12 February 2003 22:46, Richard Henderson wrote:
> On Wed, Feb 12, 2003 at 10:07:54PM +0100, Franz Sirl wrote:
> > ... and the stack pointer is kept aligned (to 256 bits) by
> > independent code as well
>
> Is this 256 bits ABI mandated?  I.e. will a non-gcc ppc
> compiler maintain this alignment as well?

Yep, ABI mandated, 256 bits for SYSV, 128 bits for EABI.

> If yes, then STACK_ALIGNMENT is set too low.  You should
> advertise what you have.  If no, then calling between two
> functions compiled with different compilers will not
> preserve the 256 bit alignment you claim.

STACK_ALIGNMENT? I can't find that. Closest I can find is MIPS_STACK_ALIGN. 
Did you think of some other macro? Sounds promising though.

Maybe part of the confusion stems from the overloaded meaning of 
STACK_BOUNDARY, sometimes it means "alignment needed for the stack pointer", 
sometimes "maximum alignment of objects in the frame" or similar it seems.

Hmm, do we have a function like get_frame_max_object_align()? Then each 
backend could adjust alignment of the frame vs. the alignment of the 
stackpointer as required.

> There are passes in gcc, particularly combine, that look
> at the advertised alignment for a pointer and know that
> the low bits are zero, and perform optimizations based on
> this.  If the alignment doesn't exist, the optimizations
> produce incorrect results.

But this certainly isn't a problem if we _increase_ STACK_BOUNDARY like I 
suggested, or?

Franz.

Re: Altivec + 16 byte alignment

[Gabriel Paubert]

On Wed, Feb 12, 2003 at 11:26:48PM +0100, Franz Sirl wrote:
> On Wednesday 12 February 2003 22:46, Richard Henderson wrote:
> > On Wed, Feb 12, 2003 at 10:07:54PM +0100, Franz Sirl wrote:
> > > ... and the stack pointer is kept aligned (to 256 bits) by
> > > independent code as well
> >
> > Is this 256 bits ABI mandated?  I.e. will a non-gcc ppc
> > compiler maintain this alignment as well?
> 
> Yep, ABI mandated, 256 bits for SYSV, 128 bits for EABI.

I believe that they are actually half of this, at least on 32 bit
targets. Alignment constraints of 128 and 64 appear quite frequently 
in the config/rs6000 files.

	Regards,
	Gabriel

Re: Altivec + 16 byte alignment

[John David Anglin]

> If yes, then STACK_ALIGNMENT is set too low.  You should
> advertise what you have.  If no, then calling between two
> functions compiled with different compilers will not 
> preserve the 256 bit alignment you claim.

You mean STACK_BOUNDARY?

> There are passes in gcc, particularly combine, that look
> at the advertised alignment for a pointer and know that
> the low bits are zero, and perform optimizations based on
> this.  If the alignment doesn't exist, the optimizations
> produce incorrect results.

I assume that it's actually the value specified by
PREFERRED_STACK_BOUNDARY stack boundary that is used for
the above.

Currently on the PA 32-bit ports, STACK_BOUNDARY
is 64 (same as BIGGEST_ALIGNMENT and PARM_BOUNDARY) but
PREFERRED_STACK_BOUNDARY is 512.  In part, this is because
we must define a non-zero STARTING_FRAME_OFFSET and the
start of the locals must lie on a STACK_BOUNDARY.

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

[Richard Henderson]

On Wed, Feb 12, 2003 at 05:31:20PM -0500, John David Anglin wrote:
> You mean STACK_BOUNDARY?

Yes, sorry.

> > There are passes in gcc, particularly combine, that look
> > at the advertised alignment for a pointer and know that
> > the low bits are zero, and perform optimizations based on
> > this.  If the alignment doesn't exist, the optimizations
> > produce incorrect results.
> 
> I assume that it's actually the value specified by
> PREFERRED_STACK_BOUNDARY stack boundary that is used for
> the above.

No, that would be wrong.

PREFERRED_STACK_BOUNDARY is a suggestion.  The theory is that
*if* every object file is compiled with this, that we'll get
some speedup at runtime, due to fewer misalignment fixups.

But it is *not* ABI mandated, and you have to assume that 
someone somewhere may not honor this.

> Currently on the PA 32-bit ports, STACK_BOUNDARY
> is 64 (same as BIGGEST_ALIGNMENT and PARM_BOUNDARY) but
> PREFERRED_STACK_BOUNDARY is 512.  In part, this is because
> we must define a non-zero STARTING_FRAME_OFFSET and the
> start of the locals must lie on a STACK_BOUNDARY.

True, but it's also assumed that they lie on a PREFERRED_STACK_BOUNDARY,
are they not?.  So I don't see that you're helping much?


r~

Re: Altivec + 16 byte alignment

[John David Anglin]

> PREFERRED_STACK_BOUNDARY is a suggestion.  The theory is that
> *if* every object file is compiled with this, that we'll get
> some speedup at runtime, due to fewer misalignment fixups.
> 
> But it is *not* ABI mandated, and you have to assume that 
> someone somewhere may not honor this.

Yes, it is.  It's written in every runtime document that I have looked
at.  HP-UX doesn't perform misalignment fixups, although the linux port
does.  I guess you are saying that STACK_BOUNDARY really should be 512,
although I have the feeling that that's incompatible with the alignment
used for the outgoing argument block.  Can you describe under what
circumstances if any gcc will not be able to align to the preferred
stack boundary?

Looking at the documentation, it says that STACK_BOUNDARY should be set
to the *minimum* alignment enforced by hardware for the stack pointer
on the machine.  It doesn't say the ABI mandated value.  64-bit alignment
of the stack is sufficient for any type, except for lock semaphores.
If the PREFERRED_STACK_BOUNDARY doesn't break down, it might be
possible to set STACK_BOUNDARY to 32 (i.e., the same as PARM_BOUNDARY).

When STACK_BOUNDARY is set to 64, there is one fill word in the frame
as a result of the starting frame offset and the need to align it to a
STACK_BOUNDARY.  If STACK_BOUNDARY were set to 512, we would have 15
fill words.

> > Currently on the PA 32-bit ports, STACK_BOUNDARY
> > is 64 (same as BIGGEST_ALIGNMENT and PARM_BOUNDARY) but
> > PREFERRED_STACK_BOUNDARY is 512.  In part, this is because
> > we must define a non-zero STARTING_FRAME_OFFSET and the
> > start of the locals must lie on a STACK_BOUNDARY.
> 
> True, but it's also assumed that they lie on a PREFERRED_STACK_BOUNDARY,
> are they not?.  So I don't see that you're helping much?

I am certain that STARTING_FRAME_OFFSET must lie on a STACK_BOUNDARY.
Otherwise, you never get a zero frame in a leaf function.  I believe this
is because of the alignment specified in init_emit for STACK_POINTER_REGNUM.
This requirement is independent of any alignment requirement for locals.

PREFERRED_STACK_BOUNDARY sets the frame alignment and an upper limit on
the alignment used in assign_stack_local_1.  There doesn't seem to be a
similar limit in assign_stack_temp_for_type.  As far as I can tell,
STARTING_FRAME_OFFSET doesn't need to be a multiple PREFERRED_STACK_BOUNDARY.
The allocation code will simply pad to the alignment needed for the first
local.

PREFERRED_STACK_BOUNDARY is set to the alignment mandated by the ABI
for the stack pointer.  The 64-byte alignment of the frame was
mandated so that compilers could know when data structures allocated
on the stack are cache aligned.  However, we don't get much benefit
from this using GCC.

It would help if user code could align stack data on a cache line for
performance or other purposes.  I believe the patch that I sent early in
this thread, <http://gcc.gnu.org/ml/gcc/2003-02/msg00656.html>, allows
a user to do this.  It also allows using the low bits as tag bits, as
suggested by Fergus Henderson.  However, it doesn't provide the suggested
error checking.

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

[Richard Henderson]

On Thu, Feb 13, 2003 at 01:14:30AM -0500, John David Anglin wrote:
> > PREFERRED_STACK_BOUNDARY is a suggestion.  The theory is that
> > *if* every object file is compiled with this, that we'll get
> > some speedup at runtime, due to fewer misalignment fixups.
> > 
> > But it is *not* ABI mandated, and you have to assume that 
> > someone somewhere may not honor this.
> 
> Yes, it is.

No.  That is not the purpose of PREFERRED_STACK_BOUNDARY.
The ABI mandated quantity is STACK_BOUNDARY.

> I guess you are saying that STACK_BOUNDARY really should be 512...

If that's what the ABI mandates, yes.

> Can you describe under what
> circumstances if any gcc will not be able to align to the preferred
> stack boundary?

None.  That's not the point.

> Looking at the documentation, it says that STACK_BOUNDARY should be set
> to the *minimum* alignment enforced by hardware for the stack pointer
> on the machine.  It doesn't say the ABI mandated value.

Then the docs need updating.

> When STACK_BOUNDARY is set to 64, there is one fill word in the frame
> as a result of the starting frame offset and the need to align it to a
> STACK_BOUNDARY.  If STACK_BOUNDARY were set to 512, we would have 15
> fill words.

Eh?  Is the stack pointer aligned or not?



r~

Re: Altivec + 16 byte alignment

[John David Anglin]

> > When STACK_BOUNDARY is set to 64, there is one fill word in the frame
> > as a result of the starting frame offset and the need to align it to a
> > STACK_BOUNDARY.  If STACK_BOUNDARY were set to 512, we would have 15
> > fill words.
> 
> Eh?  Is the stack pointer aligned or not?

The comment for STACK_BOUNDARY says "GCC for the PA always rounds its
stacks to a 8 * STACK_BOUNDARY boundary, but that happens late in the
compilation process."  The final size and rounding is determined during
reload.  This calculation is done in compute_frame_size.  However, the
value returned is always rounded no matter when it is called.  We add
in STARTING_FRAME_OFFSET if the frame pointer is needed or the size
returned by get_frame_size () is non-zero.  We also add in space for
the outgoing args, register saves, etc.

Hmmm, I see a small bug.  The rounding in compute_frame_size incorrectly
uses STACK_BOUNDARY.  Based on our current methodology, it should be
using PREFERRED_STACK_BOUNDARY.  However, this isn't the answer to your
question.

I will investigate to see why the above occurs.

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

[Richard Kenner]

    BIGGEST_ALIGNMENT is 128, but STACK_BOUNDARY is 64 unless you give 
    -mabi=altivec (in 3.2+). 

I must say that I find this confusing.  Although the documentation is
unclear, I've always thought of BIGGEST_ALIGNMENT as being the largest
alignment we can guarantee and I think there's code that depends on that.
But if STACK_BOUNDARY < BIGGEST_ALIGNMENT, that's clearly not true.  

Has the definition changed?  If so, how *do* you find the largest
alignment you can guarantee?

Re: Altivec + 16 byte alignment

[Geoff Keating]

kenner@vlsi1.ultra.nyu.edu (Richard Kenner) writes:

>     BIGGEST_ALIGNMENT is 128, but STACK_BOUNDARY is 64 unless you give 
>     -mabi=altivec (in 3.2+). 
> 
> I must say that I find this confusing.  Although the documentation is
> unclear, I've always thought of BIGGEST_ALIGNMENT as being the largest
> alignment we can guarantee and I think there's code that depends on that.

BIGGEST_ALIGNMENT is defined in the documentation as:

`BIGGEST_ALIGNMENT'
     Biggest alignment that any data type can require on this machine,
     in bits.

> But if STACK_BOUNDARY < BIGGEST_ALIGNMENT, that's clearly not true.  

I don't see that.  The prologue can always try to align the stack
itself, although at some runtime cost.  I think that's what
PREFERRED_STACK_BOUNDARY is all about.

> Has the definition changed?

It's been like this since at least 1997.

>   If so, how *do* you find the largest alignment you can guarantee?

For error checking?  MAX_OFILE_ALIGNMENT is probably the value you
want.

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: Altivec + 16 byte alignment

[Richard Kenner]

    BIGGEST_ALIGNMENT is defined in the documentation as:

    `BIGGEST_ALIGNMENT'
         Biggest alignment that any data type can require on this machine,
         in bits.

Right.  That's what I mean that it's unclear.  Code acts like it means the
largest alignment that can be guaranteed, but the above is ambiguous at best.

    >   If so, how *do* you find the largest alignment you can guarantee?

    For error checking?  MAX_OFILE_ALIGNMENT is probably the value you
    want.

But that's even worse!  It's *larger* than STACK_BOUNDARY.

My question is this: suppose a user says "I need this variable or type
aligned to an N bit boundary".  How can you tell, as a function of N,
whether you can do that or not?

Re: Altivec + 16 byte alignment

[Mike Stump]

On Tuesday, February 11, 2003, at 11:06 AM, Richard Kenner wrote:
> My question is this: suppose a user says "I need this variable or type
> aligned to an N bit boundary".  How can you tell, as a function of N,
> whether you can do that or not?

I think the answer is the minimum of MAX_OFILE_ALIGNMENT, 
STACK_BOUNDARY and BIGGEST_ALIGNMENT, if there are no bugs.  If there 
are bugs, you can't, not without fixing those bugs.

Re: Altivec + 16 byte alignment

[Geoff Keating]

> Date: Tue, 11 Feb 03 14:06:22 EST
> From: kenner@vlsi1.ultra.nyu.edu (Richard Kenner)
> Cc: gcc@gcc.gnu.org

>     BIGGEST_ALIGNMENT is defined in the documentation as:
> 
>     `BIGGEST_ALIGNMENT'
>          Biggest alignment that any data type can require on this machine,
>          in bits.
> 
> Right.  That's what I mean that it's unclear.  Code acts like it means the
> largest alignment that can be guaranteed, but the above is ambiguous at best.

Such code is wrong, it should be using MAX_OFILE_ALIGNMENT.  Can you
point at the code in question?

>     >   If so, how *do* you find the largest alignment you can guarantee?
> 
>     For error checking?  MAX_OFILE_ALIGNMENT is probably the value you
>     want.
> 
> But that's even worse!  It's *larger* than STACK_BOUNDARY.

Yes, it's supposed to be.  STACK_BOUNDARY is a minimum, not a maximum.

> My question is this: suppose a user says "I need this variable or type
> aligned to an N bit boundary".  How can you tell, as a function of N,
> whether you can do that or not?

In the abstract, you compare with MAX_OFILE_BOUNDARY.  You can align
the stack to any value you like, but you can't do better than
MAX_OFILE_BOUNDARY in the object file.


At present, there's this code in assign_stack_local:

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

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: Altivec + 16 byte alignment

[David Edelsohn]

>>>>> Geoff Keating writes:

Geoff> In the abstract, you compare with MAX_OFILE_BOUNDARY.  You can align
Geoff> the stack to any value you like, but you can't do better than
Geoff> MAX_OFILE_BOUNDARY in the object file.

	I think part of the confusion is this depends on the type of
storage.  For an automatic variable on the stack, MAX_OFILE_ALIGNMENT is
irrelevant.  For a global or static variable allocated in the data or bss
segment, MAX_OFILE_ALIGNMENT describes the functionality of the
link-editor pre-allocating storage in the process address space.

David

Re: Altivec + 16 byte alignment

[Neil Booth]

Geoff Keating wrote:-

> At present, there's this code in assign_stack_local:
> 
>   /* 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.

Isn't an even better place to do it in the front end, just after parsing
the alignment request?

Neil.

Re: Altivec + 16 byte alignment

[Geoff Keating]

> Date: Tue, 11 Feb 2003 20:28:50 +0000
> From: Neil Booth <neil@daikokuya.co.uk>

> Geoff Keating wrote:-
> 
> > At present, there's this code in assign_stack_local:
> > 
> >   /* 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.
> 
> Isn't an even better place to do it in the front end, just after parsing
> the alignment request?

You could do it if you discovered that a user-requested stack local
needed more alignment than assign_stack_local can currently give,
but it's not clear to me that the front end will always have that
information, and certainly it doesn't have it when it's just seen the
alignment request; consider

struct foo {
  int x __attribute__((aligned (512)));
}

which might, or might not, end up on the stack.

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: Altivec + 16 byte alignment

[Neil Booth]

Geoff Keating wrote:-

> > Isn't an even better place to do it in the front end, just after parsing
> > the alignment request?
> 
> You could do it if you discovered that a user-requested stack local
> needed more alignment than assign_stack_local can currently give,
> but it's not clear to me that the front end will always have that
> information, and certainly it doesn't have it when it's just seen the
> alignment request; consider
> 
> struct foo {
>   int x __attribute__((aligned (512)));
> }
> 
> which might, or might not, end up on the stack.

You could diagnose that when the object of that type is declared, just
like we have to make other checks (particularly in C++) at that time.

Neil.

Re: Altivec + 16 byte alignment

[Neil Booth]

Neil Booth wrote:-

> > struct foo {
> >   int x __attribute__((aligned (512)));
> > }
> > 
> > which might, or might not, end up on the stack.
> 
> You could diagnose that when the object of that type is declared, just
> like we have to make other checks (particularly in C++) at that time.

I guess you're saying that the middle end only decides the stack layout
later.  I guess.  Thanks for persisting.  8-)

Neil.

Re: Altivec + 16 byte alignment

[Geert Bosch]

On Tuesday, Feb 11, 2003, at 14:06 America/New_York, Richard Kenner 
wrote:
> My question is this: suppose a user says "I need this variable or type
> aligned to an N bit boundary".  How can you tell, as a function of N,
> whether you can do that or not?

I think it would be very useful if the answer would always be yes.
Then, in cases where GCC cannot guarantee proper alignment, extra
code should be generated to properly align the stack frame.

   -Geert

Re: Altivec + 16 byte alignment

[Richard Kenner]

    I think the answer is the minimum of MAX_OFILE_ALIGNMENT, 
    STACK_BOUNDARY and BIGGEST_ALIGNMENT, if there are no bugs.  If there 
    are bugs, you can't, not without fixing those bugs.

Well, then there's another bug.  Look at the usage of REGNO_POINTER_ALIGNMENT
in combine.c: it assumes that the bits not in that alignment are zero.
Then look at all the calls to mark_reg_pointer that just pass TYPE_ALIGN
or DECL_ALIGN but nothing performs the minimum above before setting those.

But I must say that 

    Biggest alignment that any data type can require on this machine, in bits.

still seems in conflict with the current implementation.  If a type can
*require* that alignment, doesn't that mean that we are going to *give*
it that alignment?  But how can we if STACK_BOUNDARY is smaller?

I think this is a real mess at this point.

Re: Altivec + 16 byte alignment

[Richard Kenner]

    Such code is wrong, it should be using MAX_OFILE_ALIGNMENT.  Can you
    point at the code in question?

The one in combine.c I mentioned in my last message, for example.

    Yes, it's supposed to be.  STACK_BOUNDARY is a minimum, not a maximum.

I don't follow.  STACK_BOUNDARY indeed gives the mimimum that the stack
is guaranteed to be aligned.  That's therefore the maximum that we can
guarantee to align any variable.

    In the abstract, you compare with MAX_OFILE_BOUNDARY.  You can align
    the stack to any value you like, 

Who's the "you"?  Where's the code?  If we have STACK_BOUNDARY of 32,
MAX_OFILE_BOUNDARY of 1024 and a TYPE_ALIGN of 128, what code is
responsible for aligning that variable to a boundary of 128 bits?

      /* 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!

Re: Altivec + 16 byte alignment

[Geoff Keating]

kenner@vlsi1.ultra.nyu.edu (Richard Kenner) writes:

>     Such code is wrong, it should be using MAX_OFILE_ALIGNMENT.  Can you
>     point at the code in question?
> 
> The one in combine.c I mentioned in my last message, for example.

That code seems correct.  If there's a problem with it, it must be
that either REGNO_POINTER_ALIGN is being set to an incorrect value or
user error.

>     Yes, it's supposed to be.  STACK_BOUNDARY is a minimum, not a maximum.
> 
> I don't follow.  STACK_BOUNDARY indeed gives the mimimum that the stack
> is guaranteed to be aligned.  That's therefore the maximum that we can
> guarantee to align any variable.

No.  Your logic is flawed.  Just because the minimum price for an
apple is $0.01, that doesn't mean I can't guarantee that my apples
cost at least $0.50.

>     In the abstract, you compare with MAX_OFILE_BOUNDARY.  You can align
>     the stack to any value you like, 
> 
> Who's the "you"?  Where's the code?  If we have STACK_BOUNDARY of 32,
> MAX_OFILE_BOUNDARY of 1024 and a TYPE_ALIGN of 128, what code is
> responsible for aligning that variable to a boundary of 128 bits?

You, Richard Kenner.

The code is, naturally, machine-dependent.  For rs6000, I believe it's
not implemented yet.  For x86, it's in ix86_compute_frame_layout, look
for the variable 'stack_alignment_needed'.

>       /* 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!

Yes, there are dozens of macros involved in alignment, they're all
documented, they've all been around for years, I don't understand your
surprise.

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: Altivec + 16 byte alignment

[Richard Henderson]

On Tue, Feb 11, 2003 at 12:00:39PM -0800, Geoff Keating wrote:
> The code is, naturally, machine-dependent.  For rs6000, I believe it's
> not implemented yet.  For x86, it's in ix86_compute_frame_layout, look
> for the variable 'stack_alignment_needed'.

No, the code does not exist in mainline at all.  It was once
written in a Cygnus branch, but it was really sort of ugly,
and never made it out.

STACK_BOUNDARY is an ABI issue; PREFERRED_STACK_BOUNDARY is an
optimization goal.  However, without forcibly aligning the stack
with AND, one cannot assume more than STACK_BOUNDARY, because 
that's the most we can expect from a different compiler (or gcc
with a different set of options).


r~

Re: Altivec + 16 byte alignment

[Richard Kenner]

    The only way to solve this is to example the stack pointer at runtime
    and mask off bits in it to align the stack, which isn't currently
    supported as an option in gcc.

Well, not for C, but see gcc/ada/decl.c:make_aligning_type, which does
just that.

Re: Altivec + 16 byte alignment

[Richard Kenner]

    Isn't an even better place to do it in the front end, just after parsing
    the alignment request?

Probably not, since it would then have to know the complex formula used
to say what's supported and what isn't.

And then you have the problem of alignment of *types*, where you have to
be able to guarantee the alignment for both stack and memory.

Re: Altivec + 16 byte alignment

[Neil Booth]

Richard Kenner wrote:-

>     Isn't an even better place to do it in the front end, just after parsing
>     the alignment request?
> 
> Probably not, since it would then have to know the complex formula used
> to say what's supported and what isn't.

It's just a function call, exposed to the front end.  Nice and clean.

> And then you have the problem of alignment of *types*, where you have to
> be able to guarantee the alignment for both stack and memory.

Why is that a problem?

Neil.

Re: Altivec + 16 byte alignment

[Richard Kenner]

    It's just a function call, exposed to the front end.  Nice and clean.

In which case, why not do it totally in the back end?  I don't see it as
a big deal, but I'm not sure what you gain by adding a call to that function
into every front end.

    > And then you have the problem of alignment of *types*, where you have to
    > be able to guarantee the alignment for both stack and memory.

    Why is that a problem?

It isn't necessarily, just another case to be concerned about.

Re: Altivec + 16 byte alignment

[Neil Booth]

Richard Kenner wrote:-

>     It's just a function call, exposed to the front end.  Nice and clean.
> 
> In which case, why not do it totally in the back end?  I don't see it as
> a big deal, but I'm not sure what you gain by adding a call to that function
> into every front end.

Better diagnostics, mainly.

Neil.

Re: Altivec + 16 byte alignment

[tm_gccmail]

On Tue, 11 Feb 2003, Richard Kenner wrote:

>     It's just a function call, exposed to the front end.  Nice and clean.
> 
> In which case, why not do it totally in the back end?  I don't see it as
> a big deal, but I'm not sure what you gain by adding a call to that function
> into every front end.

Now that you mention it, I think Naveen's "stack reorgization" patch might
be relevent, since it allows juggling items on the stack around.

You might want to rearrange the stack to minimize the gaps between the
data items if you're supporting multiple aligned stack items.

Toshi

Re: Altivec + 16 byte alignment

[Richard Kenner]

    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.

Well it's more complex than that because to *know* that we have these
hard requirement, we have to make STRICT_ALIGNMENT take an operand,
which is the mode.

Moreover, the criteria you cite isn't totally clear.  Even if the
alignment isn't *required* and even if it isn't even preferred from an
efficiency standpoint, can we just ignore it?  In Ada, for example,
you cannot since it imposes constraints on the permitted values of
the object's address.  We also assume those constraints in combine.c.

We have to use all the attribues we have about alignmen to deduce two
things, which are the *default* and the *maximum* alignment we'll allow
for each object and type.

Re: Altivec + 16 byte alignment

[Richard Kenner]

    > struct foo {
    >   int x __attribute__((aligned (512)));
    > }
    > 
    > which might, or might not, end up on the stack.

    You could diagnose that when the object of that type is declared, just
    like we have to make other checks (particularly in C++) at that time.

That won't work for Ada, where you have to give the error on the type
definition if you can't support the type in all valid contexts.

Re: Altivec + 16 byte alignment

[Neil Booth]

Richard Kenner wrote:-

>     > struct foo {
>     >   int x __attribute__((aligned (512)));
>     > }
>     > 
>     > which might, or might not, end up on the stack.
> 
>     You could diagnose that when the object of that type is declared, just
>     like we have to make other checks (particularly in C++) at that time.
> 
> That won't work for Ada, where you have to give the error on the type
> definition if you can't support the type in all valid contexts.

Exactly, but now it seems *you're* the one arguing for putting the check
in the front end.

Neil.

Re: Altivec + 16 byte alignment

[Richard Kenner]

    Exactly, but now it seems *you're* the one arguing for putting the
    check in the front end.

Not necessarily: it can be checked when laying out the type in stor-layout.c.

Re: Altivec + 16 byte alignment

[Neil Booth]

Richard Kenner wrote:-

>     Exactly, but now it seems *you're* the one arguing for putting the
>     check in the front end.
> 
> Not necessarily: it can be checked when laying out the type in stor-layout.c.

stor-layout.c is part of the front end; it just happens to be part of
GCC that is shared between all front ends.  And it shows - it's overly
generic and nearly incomprehensible.

The C parser I'm working on won't use it to lay out types, since I don't
use trees.  I'll have to ensure that what stor-layout.c does (during
lowering) is the same as what I've done.  At least in an initial
implementation.

Neil.

Re: Altivec + 16 byte alignment

[Richard Kenner]

    stor-layout.c is part of the front end; it just happens to be part of
    GCC that is shared between all front ends.  And it shows - it's overly
    generic and nearly incomprehensible.

The complexity is not due to being shared between front ends, but rather
due to the complex ABIs involved on various machines.  If you look back at
early versions, it was just about the same amount of complexity when it
was originally written just for C.

    The C parser I'm working on won't use it to lay out types, since I don't
    use trees.  I'll have to ensure that what stor-layout.c does (during
    lowering) is the same as what I've done.  At least in an initial
    implementation.

I think that's a *very* bad idea: as you say, what stor-layout.c does is
very complex.  There will be a significant amount of work to keep some other
code in sync with it.

Re: Altivec + 16 byte alignment

[Neil Booth]

Richard Kenner wrote:-

>     The C parser I'm working on won't use it to lay out types, since I don't
>     use trees.  I'll have to ensure that what stor-layout.c does (during
>     lowering) is the same as what I've done.  At least in an initial
>     implementation.
> 
> I think that's a *very* bad idea: as you say, what stor-layout.c does is
> very complex.  There will be a significant amount of work to keep some other
> code in sync with it.

You may well be right.  As a first shot, though, just to getting
something that works, it's going to be simplest.  I'm not doing any GNU
extensions, so a lot of the complexity with attributes etc. is avoided.
And I don't have all the C++ issues.  Later I'll probably get the info
from stor-layout.c.

Neil.

Re: Altivec + 16 byte alignment

[Robert Dewar]

> I think that's a *very* bad idea: as you say, what stor-layout.c does is
> very complex.  There will be a significant amount of work to keep some other
> code in sync with it.

I must say I agree with Richard here (I have often wanted to move layout into
the front end of Ada, but Richard has always managed to convince me this is
a bad idea). Can you say *why* you are making this decision:

    The C parser I'm working on won't use it to lay out types, since I don't
    use trees.  I'll have to ensure that what stor-layout.c does (during
    lowering) is the same as what I've done.  At least in an initial
    implementation.

Re: Altivec + 16 byte alignment

[Richard Kenner]

    And I don't have all the C++ issues.  

As far as I know, stor-layout.c has almost no "C++ issues": the point of
separating layout into different functions was to keep that in the front end.

Re: Altivec + 16 byte alignment

[Richard Kenner]

    The alignment declaration might be used by the programmer to ensure
    that the lower bits are available for use as tag bits.

Exactly.

    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;
	}

This is *desirable* in C, as you say, but the equivalent Ada program is
*required* to have the behavior you want and there are tests to ensure
that it does.