hppa-linux regressions and 3.2.2 release

hppa-linux regressions and 3.2.2 release

[Randolph Chung]

Greetings,

I understand the 3.2.2 release is imminent. I filed two PRs
against gcc-3.2.2 earlier last week. (#9492, #9493)  They relate to
gcc-3.2.2 regressions that are seen on hppa-linux (jda tells me 9493
happens on hppa-hpux as well).

#9493 is causing a lot of build failures in Debian. I saw 
Eric Botcazou posted a one-liner fix to the list on Jan 29. Is that
going to be checked in to 3.2.2? Or is it still pending verification?

#9492 is causing the hppa-linux kernel to be miscompiled. We have a
workaround in place, but I think there may be more silently miscompiled
cases that we have not yet discovered. No one has identified what 
causes this yet, but it seems to be a generic scheduling problem 
rather than an hppa specific one?

Both of these are fairly major regressions from 3.0, so it'll be good to
get these fixed before release. I can help test Eric's patch, but I have
no idea where to look for #9492. Does anyone have any ideas?

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

Re: hppa-linux regressions and 3.2.2 release

[Gabriel Dos Reis]

Randolph Chung <randolph@tausq.org> writes:

| Greetings,
| 
| I understand the 3.2.2 release is imminent. I filed two PRs
| against gcc-3.2.2 earlier last week. (#9492, #9493)  They relate to
| gcc-3.2.2 regressions that are seen on hppa-linux (jda tells me 9493
| happens on hppa-hpux as well).

Hi,

  I see that those PRs are also issues for 3.2, so they aren't
regressions from 3.2.1.  By the second point of the criteria

    http://gcc.gnu.org/ml/gcc/2003-01/msg01048.html

we adopted for gcc-3.2.2, it can be argued that causing failures on a
GNU/Linux system is a showstopper.  Still, the problems seem to be
there since 3.2...

I recall Eric Botcazou's patch were being reviewed this week but my
impression was that the discussion got stalled after Joe Buck asked
whether the patch was just papering over a fundamental problem.  I'll
recheck what the final answer is and incorporate the patch if
appropriate. 

[...]

| #9492 is causing the hppa-linux kernel to be miscompiled. We have a
| workaround in place, but I think there may be more silently miscompiled
| cases that we have not yet discovered. No one has identified what 
| causes this yet, but it seems to be a generic scheduling problem 
| rather than an hppa specific one?

Anyone seeing this?  I don't have any idea of how much it will
take to get a fix for that one -- and I don't have access to HPPA
boxes.  If by tomorrow we don't have anything, and since you already
have a workarounf, I would suggest we make the release and
dig up the problem for 3.2.3 (if that ever happens to exist) or 3.3.

| Both of these are fairly major regressions from 3.0, so it'll be good to
| get these fixed before release. 

As explained above, the critirai 3.2.2 aren't to fix all major
regressions from 3.0.  The goal for this release is (unfortunately)
much moderate.

| I can help test Eric's patch, but I have
| no idea where to look for #9492. Does anyone have any ideas?

Please, test Eric's patch and report whatever you get.

Thanks,

-- Gaby

Re: hppa-linux regressions and 3.2.2 release

[Eric Botcazou]

> I recall Eric Botcazou's patch were being reviewed this week but my
> impression was that the discussion got stalled after Joe Buck asked
> whether the patch was just papering over a fundamental problem.  I'll
> recheck what the final answer is and incorporate the patch if
> appropriate.

Jan thinks that the patch might be valid.

> Anyone seeing this?  I don't have any idea of how much it will
> take to get a fix for that one -- and I don't have access to HPPA
> boxes.  If by tomorrow we don't have anything, and since you already
> have a workarounf, I would suggest we make the release and
> dig up the problem for 3.2.3 (if that ever happens to exist) or 3.3.

I'll try to look into the problem with a cross-compiler this afternoon, but I 
don't promise anything.

-- 
Eric Botcazou

Re: hppa-linux regressions and 3.2.2 release

[Eric Botcazou]

> #9492 is causing the hppa-linux kernel to be miscompiled. We have a
> workaround in place, but I think there may be more silently miscompiled
> cases that we have not yet discovered. No one has identified what
> causes this yet, but it seems to be a generic scheduling problem
> rather than an hppa specific one?

I think so.

There are actually two bugs:

struct termios {
        tcflag_t c_iflag;
        tcflag_t c_oflag;
        tcflag_t c_cflag;
        tcflag_t c_lflag;
        cc_t c_line;
        cc_t c_cc[19];
};

struct tty_driver {
        int magic;
        const char *driver_name;
        const char *name;
        int name_base;
        short major;
        short minor_start;
        short num;
        short type;
        short subtype;
        struct termios init_termios;
        int flags;
        int *refcount;
};

int main(void) {
...
        pty_driver.init_termios = tty_std_termios;
...
}


struct init_termios is reported by the front-end as having a size of 8 
(instead of 36) for the copy-assignment operation. This causes the alias 
analysis to think that c_lflag (offset 12) is not clobbered by the 
copy-assignment. Interestingly, c_cflag (offset 8) is detected as being 
clobbered, although it is outside the first 8 bytes.

On first inspection (.sched log file), both errors fixed on the 3.3 branch.

The latter error is fixed by:

2002-06-03  Dan Nicolaescu  <dann@godzilla.ics.uci.edu>

	* alias.c (nonoverlapping_memrefs_p): Fix off by one error.


The former problem comes from expand_assignment() that uses a hack with 
set_mem_offset() in order to adjust the offset. It is (supposedly) fixed by:

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

	* emit-rtl.c (set_mem_attributes_minus_bitpos): Rename from
	set_mem_attributes and add BITPOS argument.  Subtract it from
	OFFSET when same is adjusted.
	(set_mem_attributes): New wrapper function.
	* expr.c (expand_assignment): Use set_mem_attributes_minus_bitpos;
	remove offset adjustment hack.
	* expr.h (set_mem_attributes_minus_bitpos): Declare.

which relies on:

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.

and

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

	* emit-rtl.c (set_mem_attributes): Preserve indirection of PARM_DECL
	when flag_argument_noalias == 2.
	* alias.c (nonoverlapping_memrefs_p): Handle that.
	* print-rtl.c (print_mem_expr): Likewise.


As David Edelsohn would say, a nice string :-)

-- 
Eric Botcazou

Re: hppa-linux regressions and 3.2.2 release

[Franz Sirl]

On Sunday 02 February 2003 16:55, Eric Botcazou wrote:
> > #9492 is causing the hppa-linux kernel to be miscompiled. We have a
> > workaround in place, but I think there may be more silently miscompiled
> > cases that we have not yet discovered. No one has identified what
> > causes this yet, but it seems to be a generic scheduling problem
> > rather than an hppa specific one?
>
> I think so.
>
> There are actually two bugs:
>
> struct termios {
>         tcflag_t c_iflag;
>         tcflag_t c_oflag;
>         tcflag_t c_cflag;
>         tcflag_t c_lflag;
>         cc_t c_line;
>         cc_t c_cc[19];
> };
>
> struct tty_driver {
>         int magic;
>         const char *driver_name;
>         const char *name;
>         int name_base;
>         short major;
>         short minor_start;
>         short num;
>         short type;
>         short subtype;
>         struct termios init_termios;
>         int flags;
>         int *refcount;
> };
>
> int main(void) {
> ...
>         pty_driver.init_termios = tty_std_termios;
> ...
> }
>
>
> struct init_termios is reported by the front-end as having a size of 8
> (instead of 36) for the copy-assignment operation. This causes the alias
> analysis to think that c_lflag (offset 12) is not clobbered by the
> copy-assignment. Interestingly, c_cflag (offset 8) is detected as being
> clobbered, although it is outside the first 8 bytes.
>
> On first inspection (.sched log file), both errors fixed on the 3.3 branch.
>
> The latter error is fixed by:
>
> 2002-06-03  Dan Nicolaescu  <dann@godzilla.ics.uci.edu>
>
> 	* alias.c (nonoverlapping_memrefs_p): Fix off by one error.
>
>
> The former problem comes from expand_assignment() that uses a hack with
> set_mem_offset() in order to adjust the offset. It is (supposedly) fixed
> by:
>
> 2002-07-29  Richard Henderson  <rth@redhat.com>
>
> 	* emit-rtl.c (set_mem_attributes_minus_bitpos): Rename from
> 	set_mem_attributes and add BITPOS argument.  Subtract it from
> 	OFFSET when same is adjusted.
> 	(set_mem_attributes): New wrapper function.
> 	* expr.c (expand_assignment): Use set_mem_attributes_minus_bitpos;
> 	remove offset adjustment hack.
> 	* expr.h (set_mem_attributes_minus_bitpos): Declare.
>
> which relies on:
>
> 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.
>
> and
>
> 2002-07-21  Richard Henderson  <rth@redhat.com>
>
> 	* emit-rtl.c (set_mem_attributes): Preserve indirection of PARM_DECL
> 	when flag_argument_noalias == 2.
> 	* alias.c (nonoverlapping_memrefs_p): Handle that.
> 	* print-rtl.c (print_mem_expr): Likewise.
>
>
> As David Edelsohn would say, a nice string :-)

Yeah, and I think you missed a few more fixes to 
set_mem_attributes_minus_bitpos. I've applied these to my gcc-3_2-branch 
testing tree and started a build for powerpc-linux-gnu. I will report 
tomorrow.

These are the patches I applied:

cvs diff -r1.172 -r1.173 alias.c |patch
cvs diff -r1.177 -r1.178 alias.c |patch
cvs diff -r1.285 -r1.288 emit-rtl.c |patch
cvs diff -r1.291 -r1.292 emit-rtl.c |patch
cvs diff -r1.294 -r1.295 emit-rtl.c |patch
cvs diff -r1.85 -r1.86 print-rtl.c |patch
cvs diff -r1.471 -r1.472 expr.c |patch
cvs diff -r1.118 -r1.119 expr.h |patch

Hopefully I didn't miss something and the tree is buildable :-).

Franz.

irc://irc.freenode.net/#gcc

Re: hppa-linux regressions and 3.2.2 release

[Eric Botcazou]

> Yeah, and I think you missed a few more fixes to
> set_mem_attributes_minus_bitpos. I've applied these to my gcc-3_2-branch
> testing tree and started a build for powerpc-linux-gnu. I will report
> tomorrow.
>
> These are the patches I applied:
>
> cvs diff -r1.172 -r1.173 alias.c |patch
> cvs diff -r1.177 -r1.178 alias.c |patch
> cvs diff -r1.285 -r1.288 emit-rtl.c |patch
> cvs diff -r1.291 -r1.292 emit-rtl.c |patch
> cvs diff -r1.294 -r1.295 emit-rtl.c |patch
> cvs diff -r1.85 -r1.86 print-rtl.c |patch
> cvs diff -r1.471 -r1.472 expr.c |patch
> cvs diff -r1.118 -r1.119 expr.h |patch

I can confirm that, with these patches applied, the .sched log file looks 
better. The structure has now the correct size:

(insn 79 105 41 (parallel[ 
            (set (mem/s/j:BLK (reg/f:SI 130) [0 pty_driver.init_termios+0 S36 
A32])
                (mem/s:BLK (reg/f:SI 131) [0 tty_std_termios+0 S36 A32]))
            (clobber (reg/f:SI 130))
            (clobber (reg/f:SI 131))
            (clobber (reg:SI 132))
            (clobber (reg:SI 133))
            (clobber (reg:SI 134))
            (use (const_int 36 [0x24]))
            (use (const_int 4 [0x4]))
        ] ) 108 {movstrsi_internal} (insn_list 78 (insn_list 76 
(insn_list:REG_DEP_ANTI 20 (nil))))

and the assignment to c_lflag has now the correct output dependency:

(insn 100 89 29 (set (mem/s/j:SI (plus:SI (reg/f:SI 95)
                (const_int 40 [0x28])) [0 pty_driver.init_termios.c_lflag+0 
S4 A32])
        (const_int 0 [0x0])) 68 {*pa.md:2088} (insn_list 9 
(insn_list:REG_DEP_ANTI 20 (insn_list:REG_DEP_OUTPUT 79 (nil))))
    (nil))

but I can't formally assert that the bug is fixed because I don't speak 
PA-RISC (which appears to be a bit abstruse :-)


Could you post the ChangeLog entries corresponding to the patches?

-- 
Eric Botcazou

Re: hppa-linux regressions and 3.2.2 release

[Franz Sirl]

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

On Sunday 02 February 2003 23:33, Eric Botcazou wrote:
> Could you post the ChangeLog entries corresponding to the patches?

2002-09-16  Richard Henderson  <rth@redhat.com>

        * emit-rtl.c (set_mem_attributes_minus_bitpos): Adjust SIZE
        as well as OFFSET for BITPOS.

2002-09-08  Jan Hubicka  <jh@suse.cz>

        * emit-rtl.c (set_mem_attributes_minus_bitpos): Fix array_ref
        handling.

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

        * emit-rtl.c (set_mem_attributes_minus_bitpos): Rename from
        set_mem_attributes and add BITPOS argument.  Subtract it from
        OFFSET when same is adjusted.
        (set_mem_attributes): New wrapper function.
        * expr.c (expand_assignment): Use set_mem_attributes_minus_bitpos;
        remove offset adjustment hack.
        * expr.h (set_mem_attributes_minus_bitpos): Declare.

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.

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

        * emit-rtl.c (set_mem_attributes): Preserve indirection of PARM_DECL
        when flag_argument_noalias == 2.
        * alias.c (nonoverlapping_memrefs_p): Handle that.
        * print-rtl.c (print_mem_expr): Likewise.

2002-06-03  Dan Nicolaescu  <dann@godzilla.ics.uci.edu>

        * alias.c (nonoverlapping_memrefs_p): Fix off by one error.


[-- Attachment #2: gcc-hppafix-backport-1.patch --]
[-- Type: text/plain, Size: 9765 bytes --]

Index: gcc/alias.c
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/alias.c,v
retrieving revision 1.166.2.3.2.1
diff -u -p -r1.166.2.3.2.1 alias.c
--- gcc/alias.c	14 Oct 2002 21:04:16 -0000	1.166.2.3.2.1
+++ gcc/alias.c	2 Feb 2003 22:46:42 -0000
@@ -1935,6 +1935,14 @@ nonoverlapping_memrefs_p (x, y)
       moffsetx = adjust_offset_for_component_ref (exprx, moffsetx);
       exprx = t;
     }
+  else if (TREE_CODE (exprx) == INDIRECT_REF)
+    {
+      exprx = TREE_OPERAND (exprx, 0);
+      if (flag_argument_noalias < 2
+	  || TREE_CODE (exprx) != PARM_DECL)
+	return 0;
+    }
+
   moffsety = MEM_OFFSET (y);
   if (TREE_CODE (expry) == COMPONENT_REF)
     {
@@ -1944,6 +1952,13 @@ nonoverlapping_memrefs_p (x, y)
       moffsety = adjust_offset_for_component_ref (expry, moffsety);
       expry = t;
     }
+  else if (TREE_CODE (expry) == INDIRECT_REF)
+    {
+      expry = TREE_OPERAND (expry, 0);
+      if (flag_argument_noalias < 2
+	  || TREE_CODE (expry) != PARM_DECL)
+	return 0;
+    }
 
   if (! DECL_P (exprx) || ! DECL_P (expry))
     return 0;
@@ -2012,7 +2027,7 @@ nonoverlapping_memrefs_p (x, y)
 
   /* If we don't know the size of the lower-offset value, we can't tell
      if they conflict.  Otherwise, we do the test.  */
-  return sizex >= 0 && offsety > offsetx + sizex;
+  return sizex >= 0 && offsety >= offsetx + sizex;
 }
 
 /* True dependence: X is read after store in MEM takes place.  */
Index: gcc/emit-rtl.c
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/emit-rtl.c,v
retrieving revision 1.249.2.10.2.1
diff -u -p -r1.249.2.10.2.1 emit-rtl.c
--- gcc/emit-rtl.c	12 Sep 2002 02:27:13 -0000	1.249.2.10.2.1
+++ gcc/emit-rtl.c	2 Feb 2003 22:46:43 -0000
@@ -1698,19 +1698,22 @@ component_ref_for_mem_expr (ref)
 
 /* Given REF, a MEM, and T, either the type of X or the expression
    corresponding to REF, set the memory attributes.  OBJECTP is nonzero
-   if we are making a new object of this type.  */
+   if we are making a new object of this type.  BITPOS is nonzero if
+   there is an offset outstanding on T that will be applied later.  */
 
 void
-set_mem_attributes (ref, t, objectp)
+set_mem_attributes_minus_bitpos (ref, t, objectp, bitpos)
      rtx ref;
      tree t;
      int objectp;
+     HOST_WIDE_INT bitpos;
 {
   HOST_WIDE_INT alias = MEM_ALIAS_SET (ref);
   tree expr = MEM_EXPR (ref);
   rtx offset = MEM_OFFSET (ref);
   rtx size = MEM_SIZE (ref);
   unsigned int align = MEM_ALIGN (ref);
+  HOST_WIDE_INT apply_bitpos = 0;
   tree type;
 
   /* It can happen that type_for_mode was given a mode for which there
@@ -1779,6 +1782,7 @@ set_mem_attributes (ref, t, objectp)
 	{
 	  expr = t;
 	  offset = const0_rtx;
+	  apply_bitpos = bitpos;
 	  size = (DECL_SIZE_UNIT (t)
 		  && host_integerp (DECL_SIZE_UNIT (t), 1)
 		  ? GEN_INT (tree_low_cst (DECL_SIZE_UNIT (t), 1)) : 0);
@@ -1803,6 +1807,7 @@ set_mem_attributes (ref, t, objectp)
 	{
 	  expr = component_ref_for_mem_expr (t);
 	  offset = const0_rtx;
+	  apply_bitpos = bitpos;
 	  /* ??? Any reason the field size would be different than
 	     the size we got from the type?  */
 	}
@@ -1814,27 +1819,97 @@ set_mem_attributes (ref, t, objectp)
 
 	  do
 	    {
+	      tree index = TREE_OPERAND (t, 1);
+	      tree array = TREE_OPERAND (t, 0);
+	      tree domain = TYPE_DOMAIN (TREE_TYPE (array));
+	      tree low_bound = (domain ? TYPE_MIN_VALUE (domain) : 0);
+	      tree unit_size = TYPE_SIZE_UNIT (TREE_TYPE (TREE_TYPE (array)));
+
+	      /* We assume all arrays have sizes that are a multiple of a byte.
+		 First subtract the lower bound, if any, in the type of the
+		 index, then convert to sizetype and multiply by the size of the
+		 array element.  */
+	      if (low_bound != 0 && ! integer_zerop (low_bound))
+		index = fold (build (MINUS_EXPR, TREE_TYPE (index),
+				     index, low_bound));
+
+	      /* If the index has a self-referential type, pass it to a
+		 WITH_RECORD_EXPR; if the component size is, pass our
+		 component to one.  */
+	      if (! TREE_CONSTANT (index)
+		  && contains_placeholder_p (index))
+		index = build (WITH_RECORD_EXPR, TREE_TYPE (index), index, t);
+	      if (! TREE_CONSTANT (unit_size)
+		  && contains_placeholder_p (unit_size))
+		unit_size = build (WITH_RECORD_EXPR, sizetype,
+				   unit_size, array);
+
 	      off_tree
 		= fold (build (PLUS_EXPR, sizetype,
 			       fold (build (MULT_EXPR, sizetype,
-					    TREE_OPERAND (t, 1),
-					    TYPE_SIZE_UNIT (TREE_TYPE (t)))),
+					    index,
+					    unit_size)),
 			       off_tree));
 	      t = TREE_OPERAND (t, 0);
 	    }
 	  while (TREE_CODE (t) == ARRAY_REF);
 
-	  if (TREE_CODE (t) == COMPONENT_REF)
+	  if (DECL_P (t))
+	    {
+	      expr = t;
+	      offset = NULL;
+	      if (host_integerp (off_tree, 1))
+		{
+		  HOST_WIDE_INT ioff = tree_low_cst (off_tree, 1);
+		  HOST_WIDE_INT aoff = (ioff & -ioff) * BITS_PER_UNIT;
+		  align = DECL_ALIGN (t);
+		  if (aoff && aoff < align)
+	            align = aoff;
+		  offset = GEN_INT (ioff);
+		  apply_bitpos = bitpos;
+		}
+	    }
+	  else if (TREE_CODE (t) == COMPONENT_REF)
 	    {
 	      expr = component_ref_for_mem_expr (t);
 	      if (host_integerp (off_tree, 1))
-		offset = GEN_INT (tree_low_cst (off_tree, 1));
+		{
+		  offset = GEN_INT (tree_low_cst (off_tree, 1));
+		  apply_bitpos = bitpos;
+		}
 	      /* ??? Any reason the field size would be different than
 		 the size we got from the type?  */
 	    }
+	  else if (flag_argument_noalias > 1
+		   && TREE_CODE (t) == INDIRECT_REF
+		   && TREE_CODE (TREE_OPERAND (t, 0)) == PARM_DECL)
+	    {
+	      expr = t;
+	      offset = NULL;
+	    }
+	}
+
+      /* If this is a Fortran indirect argument reference, record the
+	 parameter decl.  */
+      else if (flag_argument_noalias > 1
+	       && TREE_CODE (t) == INDIRECT_REF
+	       && TREE_CODE (TREE_OPERAND (t, 0)) == PARM_DECL)
+	{
+	  expr = t;
+	  offset = NULL;
 	}
     }
 
+  /* If we modified OFFSET based on T, then subtract the outstanding 
+     bit position offset.  Similarly, increase the size of the accessed
+     object to contain the negative offset.  */
+  if (apply_bitpos)
+    {
+      offset = plus_constant (offset, -(apply_bitpos / BITS_PER_UNIT));
+      if (size)
+	size = plus_constant (size, apply_bitpos / BITS_PER_UNIT);
+    }
+
   /* Now set the attributes we computed above.  */
   MEM_ATTRS (ref)
     = get_mem_attrs (alias, expr, offset, size, align, GET_MODE (ref));
@@ -1849,6 +1924,15 @@ set_mem_attributes (ref, t, objectp)
 	   || TREE_CODE (t) == ARRAY_RANGE_REF
 	   || TREE_CODE (t) == BIT_FIELD_REF)
     MEM_IN_STRUCT_P (ref) = 1;
+}
+
+void
+set_mem_attributes (ref, t, objectp)
+     rtx ref;
+     tree t;
+     int objectp;
+{
+  set_mem_attributes_minus_bitpos (ref, t, objectp, 0);
 }
 
 /* Set the alias set of MEM to SET.  */
Index: gcc/expr.c
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/expr.c,v
retrieving revision 1.423.2.19.4.7
diff -u -p -r1.423.2.19.4.7 expr.c
--- gcc/expr.c	11 Jan 2003 22:44:36 -0000	1.423.2.19.4.7
+++ gcc/expr.c	2 Feb 2003 22:46:43 -0000
@@ -3722,17 +3722,7 @@ expand_assignment (to, from, want_value,
 	     DECL_RTX of the parent struct.  Don't munge it.  */
 	  to_rtx = shallow_copy_rtx (to_rtx);
 
-	  set_mem_attributes (to_rtx, to, 0);
-
-	  /* If we changed MEM_EXPR, that means we're now referencing
-	     the COMPONENT_REF, which means that MEM_OFFSET must be
-	     relative to that field.  But we've not yet reflected BITPOS
-	     in TO_RTX.  This will be done in store_field.  Adjust for
-	     that by biasing MEM_OFFSET by -bitpos.  */
-	  if (MEM_EXPR (to_rtx) != old_expr && MEM_OFFSET (to_rtx)
-	      && (bitpos / BITS_PER_UNIT) != 0)
-	    set_mem_offset (to_rtx, GEN_INT (INTVAL (MEM_OFFSET (to_rtx))
-					     - (bitpos / BITS_PER_UNIT)));
+	  set_mem_attributes_minus_bitpos (to_rtx, to, 0, bitpos);
 	}
 
       /* Deal with volatile and readonly fields.  The former is only done
Index: gcc/expr.h
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/expr.h,v
retrieving revision 1.110.2.3.4.2
diff -u -p -r1.110.2.3.4.2 expr.h
--- gcc/expr.h	12 Sep 2002 02:27:13 -0000	1.110.2.3.4.2
+++ gcc/expr.h	2 Feb 2003 22:46:46 -0000
@@ -677,6 +677,12 @@ extern void maybe_set_unchanging PARAMS 
    corresponding to REF, set the memory attributes.  OBJECTP is nonzero
    if we are making a new object of this type.  */
 extern void set_mem_attributes PARAMS ((rtx, tree, int));
+
+/* Similar, except that BITPOS has not yet been applied to REF, so if
+   we alter MEM_OFFSET according to T then we should subtract BITPOS
+   expecting that it'll be added back in later.  */
+extern void set_mem_attributes_minus_bitpos PARAMS ((rtx, tree, int,
+						     HOST_WIDE_INT));
 #endif
 
 /* Assemble the static constant template for function entry trampolines.  */
Index: gcc/print-rtl.c
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/print-rtl.c,v
retrieving revision 1.73.6.1
diff -u -p -r1.73.6.1 print-rtl.c
--- gcc/print-rtl.c	10 Jun 2002 21:51:06 -0000	1.73.6.1
+++ gcc/print-rtl.c	2 Feb 2003 22:46:46 -0000
@@ -92,6 +92,12 @@ print_mem_expr (outfile, expr)
 	fprintf (outfile, ".%s",
 		 IDENTIFIER_POINTER (DECL_NAME (TREE_OPERAND (expr, 1))));
     }
+  else if (TREE_CODE (expr) == INDIRECT_REF)
+    {
+      fputs (" (*", outfile);
+      print_mem_expr (outfile, TREE_OPERAND (expr, 0));
+      fputs (")", outfile);
+    }
   else if (DECL_NAME (expr))
     fprintf (outfile, " %s", IDENTIFIER_POINTER (DECL_NAME (expr)));
   else if (TREE_CODE (expr) == RESULT_DECL)

Re: hppa-linux regressions and 3.2.2 release

[Eric Botcazou]

> 2002-09-08  Jan Hubicka  <jh@suse.cz>
>
>         * emit-rtl.c (set_mem_attributes_minus_bitpos): Fix array_ref
>         handling.

Looks like that patch is not complete. I read this in the ChangeLog:

2002-09-08  Jan Hubicka  <jh@suse.cz>

	* emit-rtl.c (set_mem_attributes_minus_bitpos): Fix array_ref
	handling.

	* loop.c (loop_givs_reduce):  Emit addition after.

-- 
Eric Botcazou

Re: hppa-linux regressions and 3.2.2 release

[Franz Sirl]

At 08:46 03.02.2003, Eric Botcazou wrote:
> > 2002-09-08  Jan Hubicka  <jh@suse.cz>
> >
> >         * emit-rtl.c (set_mem_attributes_minus_bitpos): Fix array_ref
> >         handling.
>
>Looks like that patch is not complete. I read this in the ChangeLog:
>
>2002-09-08  Jan Hubicka  <jh@suse.cz>
>
>         * emit-rtl.c (set_mem_attributes_minus_bitpos): Fix array_ref
>         handling.
>
>         * loop.c (loop_givs_reduce):  Emit addition after.

Nope, an empty line between 2 entries means these patches tackle unrelated 
issues.

Franz.

Re: hppa-linux regressions and 3.2.2 release

[Eric Botcazou]

> Nope, an empty line between 2 entries means these patches tackle unrelated
> issues.

Ah! How subtle...

Then your patch boostrapped/regtested fine on i586-redhat-linux-gnu.

-- 
Eric Botcazou

Re: hppa-linux regressions and 3.2.2 release

[Franz Sirl]

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

At 00:09 03.02.2003, Franz Sirl wrote:
>On Sunday 02 February 2003 23:33, Eric Botcazou wrote:
> > Could you post the ChangeLog entries corresponding to the patches?
>
>2002-07-21  Richard Henderson  <rth@redhat.com>
>
>         * emit-rtl.c (set_mem_attributes): Preserve indirection of PARM_DECL
>         when flag_argument_noalias == 2.
>         * alias.c (nonoverlapping_memrefs_p): Handle that.
>         * print-rtl.c (print_mem_expr): Likewise.

Unfortunately this one introduces a regression on powerpc-linux-gnu. It was 
fixed by rth a bit later by this patch:

2002-08-01  Richard Henderson  <rth@redhat.com>

         * integrate.c (copy_rtx_and_substitute): Squash MEM_EXPR when it
         refers to a subroutine parameter.

See <http://gcc.gnu.org/ml/gcc-patches/2002-08/msg00103.html>.

I quickly checked by applying this patch and "make f771 && make check-g77" 
and the regression was fixed. I started a bootstrap on i686-linux-gnu and 
powerpc-linux-gnu with this additional patch applied.

Franz.


[-- Attachment #2: gcc-hppafix-backport-2.patch --]
[-- Type: application/octet-stream, Size: 10563 bytes --]

Index: gcc/alias.c
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/alias.c,v
retrieving revision 1.166.2.3.2.1
diff -u -p -r1.166.2.3.2.1 alias.c
--- gcc/alias.c	14 Oct 2002 21:04:16 -0000	1.166.2.3.2.1
+++ gcc/alias.c	3 Feb 2003 11:21:00 -0000
@@ -1935,6 +1935,14 @@ nonoverlapping_memrefs_p (x, y)
       moffsetx = adjust_offset_for_component_ref (exprx, moffsetx);
       exprx = t;
     }
+  else if (TREE_CODE (exprx) == INDIRECT_REF)
+    {
+      exprx = TREE_OPERAND (exprx, 0);
+      if (flag_argument_noalias < 2
+	  || TREE_CODE (exprx) != PARM_DECL)
+	return 0;
+    }
+
   moffsety = MEM_OFFSET (y);
   if (TREE_CODE (expry) == COMPONENT_REF)
     {
@@ -1944,6 +1952,13 @@ nonoverlapping_memrefs_p (x, y)
       moffsety = adjust_offset_for_component_ref (expry, moffsety);
       expry = t;
     }
+  else if (TREE_CODE (expry) == INDIRECT_REF)
+    {
+      expry = TREE_OPERAND (expry, 0);
+      if (flag_argument_noalias < 2
+	  || TREE_CODE (expry) != PARM_DECL)
+	return 0;
+    }
 
   if (! DECL_P (exprx) || ! DECL_P (expry))
     return 0;
@@ -2012,7 +2027,7 @@ nonoverlapping_memrefs_p (x, y)
 
   /* If we don't know the size of the lower-offset value, we can't tell
      if they conflict.  Otherwise, we do the test.  */
-  return sizex >= 0 && offsety > offsetx + sizex;
+  return sizex >= 0 && offsety >= offsetx + sizex;
 }
 
 /* True dependence: X is read after store in MEM takes place.  */
Index: gcc/emit-rtl.c
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/emit-rtl.c,v
retrieving revision 1.249.2.10.2.1
diff -u -p -r1.249.2.10.2.1 emit-rtl.c
--- gcc/emit-rtl.c	12 Sep 2002 02:27:13 -0000	1.249.2.10.2.1
+++ gcc/emit-rtl.c	3 Feb 2003 11:21:00 -0000
@@ -1698,19 +1698,22 @@ component_ref_for_mem_expr (ref)
 
 /* Given REF, a MEM, and T, either the type of X or the expression
    corresponding to REF, set the memory attributes.  OBJECTP is nonzero
-   if we are making a new object of this type.  */
+   if we are making a new object of this type.  BITPOS is nonzero if
+   there is an offset outstanding on T that will be applied later.  */
 
 void
-set_mem_attributes (ref, t, objectp)
+set_mem_attributes_minus_bitpos (ref, t, objectp, bitpos)
      rtx ref;
      tree t;
      int objectp;
+     HOST_WIDE_INT bitpos;
 {
   HOST_WIDE_INT alias = MEM_ALIAS_SET (ref);
   tree expr = MEM_EXPR (ref);
   rtx offset = MEM_OFFSET (ref);
   rtx size = MEM_SIZE (ref);
   unsigned int align = MEM_ALIGN (ref);
+  HOST_WIDE_INT apply_bitpos = 0;
   tree type;
 
   /* It can happen that type_for_mode was given a mode for which there
@@ -1779,6 +1782,7 @@ set_mem_attributes (ref, t, objectp)
 	{
 	  expr = t;
 	  offset = const0_rtx;
+	  apply_bitpos = bitpos;
 	  size = (DECL_SIZE_UNIT (t)
 		  && host_integerp (DECL_SIZE_UNIT (t), 1)
 		  ? GEN_INT (tree_low_cst (DECL_SIZE_UNIT (t), 1)) : 0);
@@ -1803,6 +1807,7 @@ set_mem_attributes (ref, t, objectp)
 	{
 	  expr = component_ref_for_mem_expr (t);
 	  offset = const0_rtx;
+	  apply_bitpos = bitpos;
 	  /* ??? Any reason the field size would be different than
 	     the size we got from the type?  */
 	}
@@ -1814,27 +1819,97 @@ set_mem_attributes (ref, t, objectp)
 
 	  do
 	    {
+	      tree index = TREE_OPERAND (t, 1);
+	      tree array = TREE_OPERAND (t, 0);
+	      tree domain = TYPE_DOMAIN (TREE_TYPE (array));
+	      tree low_bound = (domain ? TYPE_MIN_VALUE (domain) : 0);
+	      tree unit_size = TYPE_SIZE_UNIT (TREE_TYPE (TREE_TYPE (array)));
+
+	      /* We assume all arrays have sizes that are a multiple of a byte.
+		 First subtract the lower bound, if any, in the type of the
+		 index, then convert to sizetype and multiply by the size of the
+		 array element.  */
+	      if (low_bound != 0 && ! integer_zerop (low_bound))
+		index = fold (build (MINUS_EXPR, TREE_TYPE (index),
+				     index, low_bound));
+
+	      /* If the index has a self-referential type, pass it to a
+		 WITH_RECORD_EXPR; if the component size is, pass our
+		 component to one.  */
+	      if (! TREE_CONSTANT (index)
+		  && contains_placeholder_p (index))
+		index = build (WITH_RECORD_EXPR, TREE_TYPE (index), index, t);
+	      if (! TREE_CONSTANT (unit_size)
+		  && contains_placeholder_p (unit_size))
+		unit_size = build (WITH_RECORD_EXPR, sizetype,
+				   unit_size, array);
+
 	      off_tree
 		= fold (build (PLUS_EXPR, sizetype,
 			       fold (build (MULT_EXPR, sizetype,
-					    TREE_OPERAND (t, 1),
-					    TYPE_SIZE_UNIT (TREE_TYPE (t)))),
+					    index,
+					    unit_size)),
 			       off_tree));
 	      t = TREE_OPERAND (t, 0);
 	    }
 	  while (TREE_CODE (t) == ARRAY_REF);
 
-	  if (TREE_CODE (t) == COMPONENT_REF)
+	  if (DECL_P (t))
+	    {
+	      expr = t;
+	      offset = NULL;
+	      if (host_integerp (off_tree, 1))
+		{
+		  HOST_WIDE_INT ioff = tree_low_cst (off_tree, 1);
+		  HOST_WIDE_INT aoff = (ioff & -ioff) * BITS_PER_UNIT;
+		  align = DECL_ALIGN (t);
+		  if (aoff && aoff < align)
+	            align = aoff;
+		  offset = GEN_INT (ioff);
+		  apply_bitpos = bitpos;
+		}
+	    }
+	  else if (TREE_CODE (t) == COMPONENT_REF)
 	    {
 	      expr = component_ref_for_mem_expr (t);
 	      if (host_integerp (off_tree, 1))
-		offset = GEN_INT (tree_low_cst (off_tree, 1));
+		{
+		  offset = GEN_INT (tree_low_cst (off_tree, 1));
+		  apply_bitpos = bitpos;
+		}
 	      /* ??? Any reason the field size would be different than
 		 the size we got from the type?  */
 	    }
+	  else if (flag_argument_noalias > 1
+		   && TREE_CODE (t) == INDIRECT_REF
+		   && TREE_CODE (TREE_OPERAND (t, 0)) == PARM_DECL)
+	    {
+	      expr = t;
+	      offset = NULL;
+	    }
+	}
+
+      /* If this is a Fortran indirect argument reference, record the
+	 parameter decl.  */
+      else if (flag_argument_noalias > 1
+	       && TREE_CODE (t) == INDIRECT_REF
+	       && TREE_CODE (TREE_OPERAND (t, 0)) == PARM_DECL)
+	{
+	  expr = t;
+	  offset = NULL;
 	}
     }
 
+  /* If we modified OFFSET based on T, then subtract the outstanding 
+     bit position offset.  Similarly, increase the size of the accessed
+     object to contain the negative offset.  */
+  if (apply_bitpos)
+    {
+      offset = plus_constant (offset, -(apply_bitpos / BITS_PER_UNIT));
+      if (size)
+	size = plus_constant (size, apply_bitpos / BITS_PER_UNIT);
+    }
+
   /* Now set the attributes we computed above.  */
   MEM_ATTRS (ref)
     = get_mem_attrs (alias, expr, offset, size, align, GET_MODE (ref));
@@ -1849,6 +1924,15 @@ set_mem_attributes (ref, t, objectp)
 	   || TREE_CODE (t) == ARRAY_RANGE_REF
 	   || TREE_CODE (t) == BIT_FIELD_REF)
     MEM_IN_STRUCT_P (ref) = 1;
+}
+
+void
+set_mem_attributes (ref, t, objectp)
+     rtx ref;
+     tree t;
+     int objectp;
+{
+  set_mem_attributes_minus_bitpos (ref, t, objectp, 0);
 }
 
 /* Set the alias set of MEM to SET.  */
Index: gcc/expr.c
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/expr.c,v
retrieving revision 1.423.2.19.4.7
diff -u -p -r1.423.2.19.4.7 expr.c
--- gcc/expr.c	11 Jan 2003 22:44:36 -0000	1.423.2.19.4.7
+++ gcc/expr.c	3 Feb 2003 11:21:01 -0000
@@ -3722,17 +3722,7 @@ expand_assignment (to, from, want_value,
 	     DECL_RTX of the parent struct.  Don't munge it.  */
 	  to_rtx = shallow_copy_rtx (to_rtx);
 
-	  set_mem_attributes (to_rtx, to, 0);
-
-	  /* If we changed MEM_EXPR, that means we're now referencing
-	     the COMPONENT_REF, which means that MEM_OFFSET must be
-	     relative to that field.  But we've not yet reflected BITPOS
-	     in TO_RTX.  This will be done in store_field.  Adjust for
-	     that by biasing MEM_OFFSET by -bitpos.  */
-	  if (MEM_EXPR (to_rtx) != old_expr && MEM_OFFSET (to_rtx)
-	      && (bitpos / BITS_PER_UNIT) != 0)
-	    set_mem_offset (to_rtx, GEN_INT (INTVAL (MEM_OFFSET (to_rtx))
-					     - (bitpos / BITS_PER_UNIT)));
+	  set_mem_attributes_minus_bitpos (to_rtx, to, 0, bitpos);
 	}
 
       /* Deal with volatile and readonly fields.  The former is only done
Index: gcc/expr.h
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/expr.h,v
retrieving revision 1.110.2.3.4.2
diff -u -p -r1.110.2.3.4.2 expr.h
--- gcc/expr.h	12 Sep 2002 02:27:13 -0000	1.110.2.3.4.2
+++ gcc/expr.h	3 Feb 2003 11:21:01 -0000
@@ -677,6 +677,12 @@ extern void maybe_set_unchanging PARAMS 
    corresponding to REF, set the memory attributes.  OBJECTP is nonzero
    if we are making a new object of this type.  */
 extern void set_mem_attributes PARAMS ((rtx, tree, int));
+
+/* Similar, except that BITPOS has not yet been applied to REF, so if
+   we alter MEM_OFFSET according to T then we should subtract BITPOS
+   expecting that it'll be added back in later.  */
+extern void set_mem_attributes_minus_bitpos PARAMS ((rtx, tree, int,
+						     HOST_WIDE_INT));
 #endif
 
 /* Assemble the static constant template for function entry trampolines.  */
Index: gcc/integrate.c
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/integrate.c,v
retrieving revision 1.184.2.1
diff -u -p -r1.184.2.1 integrate.c
--- gcc/integrate.c	12 Apr 2002 19:17:54 -0000	1.184.2.1
+++ gcc/integrate.c	3 Feb 2003 11:21:01 -0000
@@ -2320,6 +2320,13 @@ copy_rtx_and_substitute (orig, map, for_
       if (inlining && !for_lhs)
 	RTX_UNCHANGING_P (copy) = 0;
 
+      /* If inlining, squish aliasing data that references the subroutine's
+	 parameter list, since that's no longer applicable.  */
+      if (inlining && MEM_EXPR (copy)
+	  && TREE_CODE (MEM_EXPR (copy)) == INDIRECT_REF
+	  && TREE_CODE (TREE_OPERAND (MEM_EXPR (copy), 0)) == PARM_DECL)
+	set_mem_expr (copy, NULL_TREE);
+
       return copy;
 
     default:
Index: gcc/print-rtl.c
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/print-rtl.c,v
retrieving revision 1.73.6.1
diff -u -p -r1.73.6.1 print-rtl.c
--- gcc/print-rtl.c	10 Jun 2002 21:51:06 -0000	1.73.6.1
+++ gcc/print-rtl.c	3 Feb 2003 11:21:01 -0000
@@ -92,6 +92,12 @@ print_mem_expr (outfile, expr)
 	fprintf (outfile, ".%s",
 		 IDENTIFIER_POINTER (DECL_NAME (TREE_OPERAND (expr, 1))));
     }
+  else if (TREE_CODE (expr) == INDIRECT_REF)
+    {
+      fputs (" (*", outfile);
+      print_mem_expr (outfile, TREE_OPERAND (expr, 0));
+      fputs (")", outfile);
+    }
   else if (DECL_NAME (expr))
     fprintf (outfile, " %s", IDENTIFIER_POINTER (DECL_NAME (expr)));
   else if (TREE_CODE (expr) == RESULT_DECL)

Re: hppa-linux regressions and 3.2.2 release

[Gabriel Dos Reis]

Franz Sirl <Franz.Sirl-kernel@lauterbach.com> writes:

[...]

| I quickly checked by applying this patch and "make f771 && make
| check-g77" and the regression was fixed. I started a bootstrap on
| i686-linux-gnu and powerpc-linux-gnu with this additional patch
| applied.

Franz,

Thanks for conducting this detective work.  
Would you be willing to apply the patch (and send me a note) as soon as
you get better results?

Thanks,

-- Gaby

Re: hppa-linux regressions and 3.2.2 release

[Franz Sirl]

At 12:59 03.02.2003, Gabriel Dos Reis wrote:
>Franz Sirl <Franz.Sirl-kernel@lauterbach.com> writes:
>
>[...]
>
>| I quickly checked by applying this patch and "make f771 && make
>| check-g77" and the regression was fixed. I started a bootstrap on
>| i686-linux-gnu and powerpc-linux-gnu with this additional patch
>| applied.
>
>Franz,
>
>Thanks for conducting this detective work.
>Would you be willing to apply the patch (and send me a note) as soon as
>you get better results?

So, as soon as all tests complete successfully without regressions I commit 
v2 of the patch to the gcc-3_2-BRANCH? Sure, no problem. That would be in 
about 6-9 hours from now.

Eric, which were the PRs fixed by this patch?

BTW, what is the official way for backport ChangeLog entries? Just 
copy'n'paste the original entries or prepend the entries with committers 
date header and indent all backport date headers? I've seen both ways and 
did it both ways, but some consensus might be nicer.

Franz.

Re: hppa-linux regressions and 3.2.2 release

[Gabriel Dos Reis]

Franz Sirl <Franz.Sirl-kernel@lauterbach.com> writes:

[...]

| BTW, what is the official way for backport ChangeLog entries? Just
| copy'n'paste the original entries or prepend the entries with
| committers date header and indent all backport date headers? I've seen
| both ways and did it both ways, but some consensus might be nicer.

I don't know of any official way but I prefer

  2003-02-03  Franx Sirl <Franz.Sirl@lauterbach.com>
     Back-port of patches

      xxxx-xx-xx Au Thor <thor@asgaard.net>
         PR xxx
         ...

-- Gaby

Re: hppa-linux regressions and 3.2.2 release

[Eric Botcazou]

> Eric, which were the PRs fixed by this patch?

Only one PR (kernel miscompilation on hppa-linux): PR optimization/9492

> BTW, what is the official way for backport ChangeLog entries? Just
> copy'n'paste the original entries or prepend the entries with committers
> date header and indent all backport date headers? I've seen both ways and
> did it both ways, but some consensus might be nicer.

I personally find the following way convenient:


2003-01-28  Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at>	
	Backport patches
	
  2002-10-04  Loren J. Rittle  <ljrittle@acm.org>

	  * gcc/ginclude/stddef.h: Support the FreeBSD 5 typedef system.

  2002-08-01  Stan Shebs  <shebs@apple.com>
	      Andreas Tobler  <toa@pop.agri.ch>

	  * ginclude/stddef.h (_BSD_SIZE_T_DEFINED_): Define if not defined,
	  plays nice with Darwin headers.
	  (_BSD_RUNE_T_DEFINED_): Likewise.


because you can add an unique reference to the PR number, so that GNATS picks 
up the commit.

-- 
Eric Botcazou

ChangeLog conventions (was: hppa-linux regressions and 3.2.2 release)

[Gerald Pfeifer]

On Mon, 3 Feb 2003, Eric Botcazou wrote:
> I personally find the following way convenient:
>
>
> 2003-01-28  Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at>
> 	Backport patches
>
>   2002-10-04  Loren J. Rittle  <ljrittle@acm.org>
>
> 	  * gcc/ginclude/stddef.h: Support the FreeBSD 5 typedef system.
>
>   2002-08-01  Stan Shebs  <shebs@apple.com>
> 	      Andreas Tobler  <toa@pop.agri.ch>
>
> 	  * ginclude/stddef.h (_BSD_SIZE_T_DEFINED_): Define if not defined,
> 	  plays nice with Darwin headers.
> 	  (_BSD_RUNE_T_DEFINED_): Likewise.
>
> because you can add an unique reference to the PR number, so that GNATS picks
> up the commit.

Given that this seems to be consensus (with Gaby, Geoff,...) using and/or
preferring it as well, would (one of) you volunteer to submit this as a
suggestion for

  http://www.gnu.org/prep/standards_toc.html

or our codingconventions.html?

Gerald
-- 
Gerald "Jerry"   pfeifer@dbai.tuwien.ac.at   http://www.pfeifer.com/gerald/

Re: ChangeLog conventions (was: hppa-linux regressions and 3.2.2 release)

[Eric Botcazou]

> Given that this seems to be consensus (with Gaby, Geoff,...) using and/or
> preferring it as well, would (one of) you volunteer to submit this as a
> suggestion for
>
>   http://www.gnu.org/prep/standards_toc.html
>
> or our codingconventions.html?

Something like this:

Index: codingconventions.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/codingconventions.html,v
retrieving revision 1.18
diff -u -r1.18 codingconventions.html
--- codingconventions.html	7 Dec 2002 13:51:44 -0000	1.18
+++ codingconventions.html	11 Feb 2003 10:14:49 -0000
@@ -56,7 +56,11 @@
 particular, descriptions of the purpose of code and changes should go
 in comments rather than the ChangeLog, though a single line overall
 description of the changes may be useful above the ChangeLog entry for
-a large batch of changes.</p>
+a large batch of changes. For changes that are backported from another
+branch to the working one, we recommend to use a single entry whose
+body contains a verbatim copy of the whole (header+body) entries
+describing the changes on the source branch, possibly preceded by a
+single line overall description of the changes.</p>
 
 <p>There is no established convention on when ChangeLog entries are to
 be made for testsuite changes; see messages <a

-- 
Eric Botcazou

Re: ChangeLog conventions (was: hppa-linux regressions and 3.2.2 release)

[Phil Edwards]

On Tue, Feb 11, 2003 at 11:21:06AM +0100, Eric Botcazou wrote:
> +a large batch of changes. For changes that are backported from another
> +branch to the working one, we recommend to use a single entry whose
> +body contains a verbatim copy of the whole (header+body) entries
> +describing the changes on the source branch, possibly preceded by a
> +single line overall description of the changes.</p>

Thanks for doing this.  (A small contrived example might be nice, too.)


Phil

-- 
I would therefore like to posit that computing's central challenge, viz. "How
not to make a mess of it," has /not/ been met.
                                                 - Edsger Dijkstra, 1930-2002

Re: ChangeLog conventions

[Gerald Pfeifer]

On Tue, 11 Feb 2003, Eric Botcazou wrote:
> Something like this:
>
> Index: codingconventions.html

Thanks! Based on your patch, I committed the following:

Index: codingconventions.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/codingconventions.html,v
retrieving revision 1.18
diff -u -3 -p -r1.18 codingconventions.html
--- codingconventions.html	7 Dec 2002 13:51:44 -0000	1.18
+++ codingconventions.html	13 Feb 2003 17:48:01 -0000
@@ -58,6 +58,11 @@ in comments rather than the ChangeLog, t
 description of the changes may be useful above the ChangeLog entry for
 a large batch of changes.</p>

+<p>For changes that are ported from another branch, we recommend to
+use a single entry whose body contains a verbatim copy of the original
+entries describing the changes on that branch, possibly preceded by a
+single-line overall description of the changes.</p>
+
 <p>There is no established convention on when ChangeLog entries are to
 be made for testsuite changes; see messages <a
 href="http://gcc.gnu.org/ml/gcc/2000-09/msg00287.html">1</a> and <a

Re: hppa-linux regressions and 3.2.2 release

[Joseph S. Myers]

On Mon, 3 Feb 2003, Franz Sirl wrote:

> BTW, what is the official way for backport ChangeLog entries? Just 
> copy'n'paste the original entries or prepend the entries with committers 
> date header and indent all backport date headers? I've seen both ways and 
> did it both ways, but some consensus might be nicer.

When creating codingconventions.html to document established practices in
GCC, I couldn't find a consensus on the the formatting of such ChangeLog
entries (though I looked for past discussion of the issue) so didn't put
anything in.  If some practice gets agreed, it should be documented in
codingconventions.html.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: hppa-linux regressions and 3.2.2 release

[Franz Sirl]

On Monday 03 February 2003 12:59, Gabriel Dos Reis wrote:
> Franz Sirl <Franz.Sirl-kernel@lauterbach.com> writes:
>
> [...]
>
> | I quickly checked by applying this patch and "make f771 && make
> | check-g77" and the regression was fixed. I started a bootstrap on
> | i686-linux-gnu and powerpc-linux-gnu with this additional patch
> | applied.
>
> Franz,
>
> Thanks for conducting this detective work.
> Would you be willing to apply the patch (and send me a note) as soon as
> you get better results?

The regression tests completed successfully with the patch to integrate.c, so 
I just committed it to the gcc-3_2-branch.

Franz.

Re: hppa-linux regressions and 3.2.2 release

[Gabriel Dos Reis]

Franz Sirl <Franz.Sirl-kernel@lauterbach.com> writes:

| I just committed it to the gcc-3_2-branch.

Thanks a lot.

-- Gaby

Re: hppa-linux regressions and 3.2.2 release

[Eric Botcazou]

> struct init_termios is reported by the front-end as having a size of 8
> (instead of 36) for the copy-assignment operation.

... by the RTL expander...

-- 
Eric Botcazou

Re: hppa-linux regressions and 3.2.2 release

[Gabriel Dos Reis]

Eric Botcazou <ebotcazou@libertysurf.fr> writes:

| > struct init_termios is reported by the front-end as having a size of 8
| > (instead of 36) for the copy-assignment operation.
| 
| ... by the RTL expander...

Wow.  Many thanks for the analysis.

This, indeed, is getting ramified and worrysome since it appears to be
a generic problem -- I don't have any idea why we didn't get more PRs
about it ;-)  

I hope that by tomorrow we'll have report from Franz to have an idea
of how large and invasive is the patch.  I'll also expect a quick yo
review.  In the meantine, I'll make the third pre-release since we
already got many patches in.

Thanks,

-- Gaby

Re: hppa-linux regressions and 3.2.2 release

[Randolph Chung]

> I hope that by tomorrow we'll have report from Franz to have an idea
> of how large and invasive is the patch.  I'll also expect a quick yo
> review.  In the meantine, I'll make the third pre-release since we
> already got many patches in.

I applied these patches:

cvs diff -r1.172 -r1.173 alias.c |patch
cvs diff -r1.177 -r1.178 alias.c |patch
cvs diff -r1.285 -r1.288 emit-rtl.c |patch
cvs diff -r1.291 -r1.292 emit-rtl.c |patch
cvs diff -r1.294 -r1.295 emit-rtl.c |patch
cvs diff -r1.85 -r1.86 print-rtl.c |patch
cvs diff -r1.471 -r1.472 expr.c |patch
cvs diff -r1.118 -r1.119 expr.h |patch

plus Eric's patch from http://gcc.gnu.org/ml/gcc/2003-01/msg01580.html

With these applied, the two test cases in PRs 9492/9493 are working 
ok now on hppa-linux.

Bootstrapped on i386-pc-linux-gnu and hppa-unknown-linux-gnu; no new
test failures.

Dave, can you please test the hpux targets as well?

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

Re: hppa-linux regressions and 3.2.2 release

[Eric Botcazou]

> With these applied, the two test cases in PRs 9492/9493 are working
> ok now on hppa-linux.

Great!

Could you write a self-contained testcase for PR 9492 (i.e. without any 
dependency on external functions) ?

-- 
Eric Botcazou

Re: hppa-linux regressions and 3.2.2 release

[John David Anglin]

> > I recall Eric Botcazou's patch were being reviewed this week but my
> > impression was that the discussion got stalled after Joe Buck asked
> > whether the patch was just papering over a fundamental problem.  I'll
> > recheck what the final answer is and incorporate the patch if
> > appropriate.
> 
> Jan thinks that the patch might be valid.

Jan wrote:
> No, I guess the fix is correct - it is merely looking for loop preheader
> and should crash when there is empty block at the end of insn stream.

I note that in my examination of the problem I found an empty block at
the end of the insn stream.  Thus, I can confirm that this is the problem
that Eric's patch addresses.

As the prior loop terminates if insn is null, it is obvious that a null
check of some kind is needed in the following instruction which will cause a
crash if insn is null.  The testcase is simply an example of a situation
where a null value can occur.

As to Joe's point, this doesn't happen on 3.3 because there isn't an
empty block at the end of the insn stream.  There is always a code_label
in the insn stream.  As a result, the preceding loop doesn't ever reach
the end of the insn stream.  If the presence of a code label is guaranteed,
then the null check in the preceeding for loop can probably be removed.
I don't know why 3.2 and 3.3 differ in this respect but I seem to
recall problems with label usage counts at one time.

The PA-RISC assembly output with the patch ok.

I have completed a bootstrap on hppa2.0w-hp-hpux11.11 with Eric's patch.
The results are posted here

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

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)

PS: Eric, your analysis of PR9492 was awesome.

Re: hppa-linux regressions and 3.2.2 release

[Gabriel Dos Reis]

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

[...]

| As to Joe's point, this doesn't happen on 3.3 because there isn't an
| empty block at the end of the insn stream.  There is always a code_label
| in the insn stream.  As a result, the preceding loop doesn't ever reach
| the end of the insn stream.  If the presence of a code label is guaranteed,
| then the null check in the preceeding for loop can probably be removed.
| I don't know why 3.2 and 3.3 differ in this respect but I seem to
| recall problems with label usage counts at one time.

Thanks for the note.  This patch being applied in last minute, I would
like to have a middle/back-end expert to double check it.  RTH?

Thanks to all of you who helped producing this set of patches.

[...]

| I have completed a bootstrap on hppa2.0w-hp-hpux11.11 with Eric's patch.
| The results are posted here
| 
| <http://gcc.gnu.org/ml/gcc-testresults/2003-02/msg00117.html>.
| 
| There are no regressions.


That looks good indeed.

-- Gaby

Re: hppa-linux regressions and 3.2.2 release

[John David Anglin]

> That looks good indeed.

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.

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

[Joe Buck]

On Sun, Feb 02, 2003 at 07:25:25PM -0500, John David Anglin wrote:
> As to Joe's point, this doesn't happen on 3.3 because there isn't an
> empty block at the end of the insn stream.  There is always a code_label
> in the insn stream.  As a result, the preceding loop doesn't ever reach
> the end of the insn stream.  If the presence of a code label is guaranteed,
> then the null check in the preceeding for loop can probably be removed.
> I don't know why 3.2 and 3.3 differ in this respect but I seem to
> recall problems with label usage counts at one time.

I only raised the issue because we weren't seeing the failure on 3.3.
I just wanted someone knowledgeable to check.
 

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)