Re: Internal compiler error in gcc-2.95 19990623 on PowerPC

Re: Internal compiler error in gcc-2.95 19990623 on PowerPC

[Jeffrey A Law]

  > I've encountered several errors in the 19990623 snapshot of gcc-2.95.
  > 
  > I found this bug compiling a piece of software on LinuxPPC.  The
  > distribution of Linux is LinuxPPC R5 final.  The kernel is 2.2.4.
  > I am using glibc-2.1.1 which came with the distribution.  The machine
  > I am running on is a PowerBook G3/266 with 192M of ram.  I have isolated
  > the problem to a simple example.  Although this may look degenerate (I
  > don't allocate any memory), it serves its purpose to trigger the bug,
  > and an identical problem happens in real code.
This bug has already been fixed.

  > |     int *ip;
  [ ... ]
  > |     for (i = 0; i < n; i++) {
  > |         *(dpi++) = (double) ip[i+n*j];
  > |         *(dpi++) = 0.;
Also note this code is highly unportable as it violates ansi/iso aliasing
rules.

jfef

Re: Internal compiler error in gcc-2.95 19990623 on PowerPC

[Franz Sirl]

Am Mit, 30 Jun 1999 schrieb David Edelsohn:
>Ignore my previous comment.  What I thought was occurring is not
>what the RTL shows.  This is failing at my assertion that the indexed
>address is not a pre-increment or pre-decrement.  Why is this address not
>considered offsettable (which does support PRE_INC/PRE_DEC)?  It is an
>address in a register -- no PLUS or LO_SUM or indexing or anything.

Good hint!

The problem (?) is that mode_dependent_address_p() in recog.c returns 1:

1916    int
1917    mode_dependent_address_p (addr)
1918      rtx addr ATTRIBUTE_UNUSED; /* Maybe used in GO_IF_MODE_DEPENDENT_ADDRESS. */
1919    {
1920      GO_IF_MODE_DEPENDENT_ADDRESS (addr, win);
1921      return 0;
1922      /* Label `win' might (not) be used via GO_IF_MODE_DEPENDENT_ADDRESS. */
1923     win: ATTRIBUTE_UNUSED_LABEL
1924      return 1;

GO_IF_MODE_DEPENDENT_ADDRESS is defined in rs6000.h as:

#define GO_IF_MODE_DEPENDENT_ADDRESS(ADDR,LABEL)                \
{ if (GET_CODE (ADDR) == PLUS                                   \
      && LEGITIMATE_ADDRESS_INTEGER_P (XEXP (ADDR, 1), 0)       \
      && ! LEGITIMATE_ADDRESS_INTEGER_P (XEXP (ADDR, 1),        \
                                         (TARGET_32BIT ? 4 : 8))) \
    goto LABEL;                                                 \
  if (TARGET_UPDATE && GET_CODE (ADDR) == PRE_INC)              \
    goto LABEL;                                                 \
  if (TARGET_UPDATE && GET_CODE (ADDR) == PRE_DEC)              \
    goto LABEL;                                                 \
  if (GET_CODE (ADDR) == LO_SUM)                                \
    goto LABEL;                                                 \
}


We enter here with:
(gdb) bt
#0  mode_dependent_address_p (addr=0x1be7cb0) at ../../../gcc95branch/gcc/recog.c:1920
#1  0x1a3b3d0 in offsettable_address_p (strictp=1, mode=DFmode, y=0x1be7cb0) at ../../../gcc95branch/gcc/recog.c:1873
#2  0x1a3b244 in offsettable_memref_p (op=0x1be2478) at ../../../gcc95branch/gcc/recog.c:1830
#3  0x1a81a68 in output_440 (operands=0x1bcb514, insn=0x1be24c8) at insn-output.c:1518
#4  0x1a32280 in final_scan_insn (insn=0x1be24c8, file=0x1be1f08, optimize=2, prescan=0, nopeepholes=0)
    at ../../../gcc95branch/gcc/final.c:2892
#5  0x1a30f2c in final (first=0x1bcfbf0, file=0x1be1f08, optimize=2, prescan=0) at ../../../gcc95branch/gcc/final.c:2016
#6  0x18082cc in rest_of_compilation (decl=0x1be02e0) at ../../../gcc95branch/gcc/toplev.c:4396
#7  0x1aef1f0 in finish_function (nested=0) at ../../../gcc95branch/gcc/c-decl.c:7268
#8  0x1acf69c in yyparse () at c-parse.y:313
#9  0x18053f8 in compile_file (name=0x7ffffd1b "test.i") at ../../../gcc95branch/gcc/toplev.c:3269
#10 0x180a6f8 in main (argc=10, argv=0x7ffffbd4) at ../../../gcc95branch/gcc/toplev.c:5445
#11 0x16dddf4 in __libc_start_main () at ../sysdeps/powerpc/elf/libc-start.c:106
(gdb) p debug_rtx(addr)

(pre_inc:SI (reg/v:SI 11 r11))
$94 = void

Franz.
>From dje@watson.ibm.com Wed Jun 30 15:01:00 1999
From: David Edelsohn <dje@watson.ibm.com>
To: Franz Sirl <Franz.Sirl-kernel@lauterbach.com>
Cc: law@cygnus.com, Brian Downing <bdowning@wolfram.com>, egcs-bugs@egcs.cygnus.com
Subject: Re: Internal compiler error in gcc-2.95 19990623 on PowerPC 
Date: Wed, 30 Jun 1999 15:01:00 -0000
Message-id: <9906302201.AA35708@marc.watson.ibm.com>
References: <99063022073700.00811@ns1102.munich.netsurf.de>
X-SW-Source: 1999-06/msg01028.html
Content-length: 588

	This seems to be where the PowerPC port protects against the case
that Jeff was worried about before: incrementing an unaligned displacement
address so that it no longer is accessible via a displacement on the
particular target.  If this were written as

	(plus (reg:SI 31) (const_int 4))

I think that this would have been considered valid.

	PRE_DEC or PRE_INC gets very complicated to implement for the
cases I wrote because one now needs to adjust the address first, make sure
that works with the code that loads or stores the second word, and then
leave the address updated.

David
>From rth@cygnus.com Wed Jun 30 15:12:00 1999
From: Richard Henderson <rth@cygnus.com>
To: "Melissa O'Neill" <oneill@cs.sfu.ca>
Cc: EGCS Bugs <egcs-bugs@egcs.cygnus.com>, EGCS <egcs@egcs.cygnus.com>
Subject: Re: Exception Handling Bug (smashing global registers)  -- 19990628 and earlier
Date: Wed, 30 Jun 1999 15:12:00 -0000
Message-id: <19990630151210.A23024@cygnus.com>
References: <199906290846.BAA26265@aldrington.ppp.cs.sfu.ca> <199906290846.BAA26265@aldrington.ppp.cs.sfu.ca>
X-SW-Source: 1999-06/msg01029.html
Content-length: 396

On Tue, Jun 29, 1999 at 01:46:11AM -0700, Melissa O'Neill wrote:
> I realize that compiling libgcc with -mno-app-regs will cause its
> functions to run more slowly, but it seems like our only choice is to
> compile it that way, or to say goodbye to reliably using -mno-app-regs
> or -ffixed.

You multilib on -mno-app-regs.  Although I'd be very surprised
if libc preserves those registers.


r~
>From law@cygnus.com Wed Jun 30 15:16:00 1999
From: Jeffrey A Law <law@cygnus.com>
To: Patrick Edward Hill <hillp@cae.wisc.edu>
Cc: egcs-bugs@egcs.cygnus.com
Subject: Re: pthread_once on HP problems 
Date: Wed, 30 Jun 1999 15:16:00 -0000
Message-id: <26522.930780892@upchuck.cygnus.com>
References: <Pine.SOL.4.10.9906301441110.18790-100000@penelope.cae.wisc.edu>
X-SW-Source: 1999-06/msg01030.html
Content-length: 572

  In message < Pine.SOL.4.10.9906301441110.18790-100000@penelope.cae.wisc.edu >yo
u write:
  > Unfortunately, I believe that g++ does not realize that it needs to
  > link with the options for threads.  This seems to be the real problem.
Yes.  But it's not a trivial problem to solve, believe it or not.



  > I guess my question would be: why do you need to explicitly
  > link in thread library's when there is simply a undefined 
  > symbol in one of the library's that your are using.
That's just how things work.  That's how things have worked for 25 years.

jeff

Re: Internal compiler error in gcc-2.95 19990623 on PowerPC

[Franz Sirl]

Am Don, 01 Jul 1999 schrieb David Edelsohn:
>This seems to be where the PowerPC port protects against the case
>that Jeff was worried about before: incrementing an unaligned displacement
>address so that it no longer is accessible via a displacement on the
>particular target.  If this were written as
>
>	(plus (reg:SI 31) (const_int 4))
>
>I think that this would have been considered valid.
>
>	PRE_DEC or PRE_INC gets very complicated to implement for the
>cases I wrote because one now needs to adjust the address first, make sure
>that works with the code that loads or stores the second word, and then
>leave the address updated.


(gdb) c
Continuing.

Breakpoint 1, output_440 (operands=0x1bcb514, insn=0x1be24c8) at insn-output.c:1463
1463      switch (which_alternative)
(gdb) p debug_rtx(insn)

(insn:TI 51 45 52 (set (mem:DF (pre_inc:SI (reg/v:SI 11 r11)) 1)
        (reg:DF 7 r7)) 440 {*movdf_hardfloat32} (insn_list:REG_DEP_ANTI 45 (nil))
    (expr_list:REG_INC (reg/v:SI 11 r11)
        (nil)))
$5 = void
(gdb) p which_alternative
$6 = 2
^^^^^^^

Shouldn't that be alternative 8 here?

Franz.
>From mrs@wrs.com Wed Jun 30 17:09:00 1999
From: mrs@wrs.com (Mike Stump)
To: chadj@pobox.com, egcs-bugs@egcs.cygnus.com
Subject: Re: Template auto instantiation
Date: Wed, 30 Jun 1999 17:09:00 -0000
Message-id: <199907010008.RAA23311@kankakee.wrs.com>
X-SW-Source: 1999-06/msg01037.html
Content-length: 240

> Date: Wed, 30 Jun 1999 16:35:34 -0700 (PDT)
> From: Chad Juliano <chadj2@yahoo.com>
> To: egcs-bugs@egcs.cygnus.com

> I have a proposal for the todo list.

Bad idea, already been done.  See -frepo, and the new link.once magic
of GNU ld.
>From dje@watson.ibm.com Wed Jun 30 17:16:00 1999
From: David Edelsohn <dje@watson.ibm.com>
To: Franz Sirl <Franz.Sirl-kernel@lauterbach.com>
Cc: law@cygnus.com, Brian Downing <bdowning@wolfram.com>, egcs-bugs@egcs.cygnus.com
Subject: Re: Internal compiler error in gcc-2.95 19990623 on PowerPC 
Date: Wed, 30 Jun 1999 17:16:00 -0000
Message-id: <9907010016.AA30026@marc.watson.ibm.com>
References: <99070102051800.01156@ns1102.munich.netsurf.de>
X-SW-Source: 1999-06/msg01038.html
Content-length: 171

>>>>> Franz Sirl writes:

Franz> (gdb) p which_alternative
Franz> $6 = 2
Franz> ^^^^^^^

Franz> Shouldn't that be alternative 8 here?

	No, r7 is GPR 7, not FPR 7.

David
>From khan@xraylith.wisc.EDU Wed Jun 30 17:59:00 1999
From: Mumit Khan <khan@xraylith.wisc.EDU>
To: egcs-bugs@egcs.cygnus.com
Subject: Re: gcc bug 
Date: Wed, 30 Jun 1999 17:59:00 -0000
Message-id: <199907010059.TAA32375@mercury.xraylith.wisc.edu>
References: <4.1.19990629154125.0092d3a0@pop.mail.yahoo.com>
X-SW-Source: 1999-06/msg01039.html
Content-length: 1099

"K. Haley" <khaley@bigfoot.com> writes:
> This code compiles under Borland and MS compilers.  GCC however, can't seem
> to find the proper new. I've tried egcs 1.1.2 and the prerelease snapshot
> of  GCC 2.95.
> 
> 
> #include <new.h>
> 
> int main()
> {
> 	return 0;
> }
> 
> class foo
> {
> 	public:
> 	foo(){;};
> };
> 
> namespace OWL {
> template <class A> class TMMemStack{
> 	public:
> 
>     TMMemStack(  );
> 		void*	Allocate( size_t );
> 
> 	private:
>     size_t CurLoc;
> };
> template <class A> inline void* operator new( size_t sz, TMMemStack<A>& m )
> {
>  return m.Allocate( sz );
> }
> 
> void f()
> {
> 	foo *i;
> 	i=new foo; <<<<< HERE
> }
> }; 
> ---

Though ill-formed according to 3.7.3.1 "ill-formed if an allocation 
function is declared in a namespace scope other than the global
scope ...", gcc's diagnostic can definitely stand an improvement.
It essentially quits with the following message when it hits the line
marked with <<<< HERE.:
  
  new-bug.cc: In function `void OWL::f()':
  new-bug.cc:46: no matching function for call to `operator new (int)'

Regards,
Mumit

Re: Internal compiler error in gcc-2.95 19990623 on PowerPC

[David Edelsohn]

	This seems to be where the PowerPC port protects against the case
that Jeff was worried about before: incrementing an unaligned displacement
address so that it no longer is accessible via a displacement on the
particular target.  If this were written as

	(plus (reg:SI 31) (const_int 4))

I think that this would have been considered valid.

	PRE_DEC or PRE_INC gets very complicated to implement for the
cases I wrote because one now needs to adjust the address first, make sure
that works with the code that loads or stores the second word, and then
leave the address updated.

David

Re: Internal compiler error in gcc-2.95 19990623 on PowerPC

[David Edelsohn]

>>>>> Franz Sirl writes:

Franz> (insn 51 46 52 (set (mem:DF (pre_inc:SI (reg/v:SI 86)) 0)
Franz> (reg:DF 100)) 440 {*movdf_hardfloat32} (nil)
Franz> (expr_list:REG_INC (reg/v:SI 86)
Franz> (nil)))

Franz> I think it's barfing on the pre_inc in insn 51.

	Yes, that instruction definitely looks strange.  This, however, is
not a valid addressing mode and should have been rejected by
GO_IF_LEGITIMATE_ADDRESS.  PRE_INC and PRE_DEC only are valid with an
offsettable-type address.  Maybe this very old GO_IF_LEGITIMATE_ADDRESS
code is not tight enough:

  if ((GET_CODE (X) == PRE_INC || GET_CODE (X) == PRE_DEC) \
      && TARGET_UPDATE                                  \
      && LEGITIMATE_INDIRECT_ADDRESS_P (XEXP (X, 0)))   \

It checks for a valid base register in XEXP (X, 0), but does not check
that XEXP (X, 1) is if it exists.  It seems to assume that XEXP (X, 1)
would not be present.

David

Re: Internal compiler error in gcc-2.95 19990623 on PowerPC

[Franz Sirl]

At 10:46 28.06.99 , Jeffrey A Law wrote:

>   > I've encountered several errors in the 19990623 snapshot of gcc-2.95.
>   >
>   > I found this bug compiling a piece of software on LinuxPPC.  The
>   > distribution of Linux is LinuxPPC R5 final.  The kernel is 2.2.4.
>   > I am using glibc-2.1.1 which came with the distribution.  The machine
>   > I am running on is a PowerBook G3/266 with 192M of ram.  I have isolated
>   > the problem to a simple example.  Although this may look degenerate (I
>   > don't allocate any memory), it serves its purpose to trigger the bug,
>   > and an identical problem happens in real code.
>This bug has already been fixed.

Are you sure? I still get this one with current 2.95 cvs. The rtl in 
.combine looks like this:

(insn 45 43 46 (set (mem:DF (reg/v:SI 86) 0)
         (reg:DF 88)) 440 {*movdf_hardfloat32} (insn_list 43 (nil))
     (expr_list:REG_DEAD (reg:DF 88)
         (nil)))

(note 46 45 51 "" NOTE_INSN_DELETED)

(insn 51 46 52 (set (mem:DF (pre_inc:SI (reg/v:SI 86)) 0)
         (reg:DF 100)) 440 {*movdf_hardfloat32} (nil)
     (expr_list:REG_INC (reg/v:SI 86)
         (nil)))

(insn 52 51 55 (set (reg/v:SI 86)
         (plus:SI (reg/v:SI 86)
             (const_int 8 [0x8]))) 52 {*addsi3_internal1} (nil)
     (nil))

(note 55 52 122 "" NOTE_INSN_LOOP_CONT)

I think it's barfing on the pre_inc in insn 51.

Franz.

Re: Internal compiler error in gcc-2.95 19990623 on PowerPC

[David Edelsohn]

	Ignore my previous comment.  What I thought was occurring is not
what the RTL shows.  This is failing at my assertion that the indexed
address is not a pre-increment or pre-decrement.  Why is this address not
considered offsettable (which does support PRE_INC/PRE_DEC)?  It is an
address in a register -- no PLUS or LO_SUM or indexing or anything.

David

Re: Internal compiler error in gcc-2.95 19990623 on PowerPC

[David Edelsohn]

>>>>> Franz Sirl writes:

Franz> (gdb) p which_alternative
Franz> $6 = 2
Franz> ^^^^^^^

Franz> Shouldn't that be alternative 8 here?

	No, r7 is GPR 7, not FPR 7.

David

Internal compiler error in gcc-2.95 19990623 on PowerPC

[Brian Downing]

I've encountered several errors in the 19990623 snapshot of gcc-2.95.

I found this bug compiling a piece of software on LinuxPPC.  The
distribution of Linux is LinuxPPC R5 final.  The kernel is 2.2.4.
I am using glibc-2.1.1 which came with the distribution.  The machine
I am running on is a PowerBook G3/266 with 192M of ram.  I have isolated
the problem to a simple example.  Although this may look degenerate (I
don't allocate any memory), it serves its purpose to trigger the bug,
and an identical problem happens in real code.

This code compiles fine with egcs-2.91.66 (egcs-1.1.2 release).

An example session follows.  The bug happens with ANY optimization flags
greater than -O0:

| ramoth:~ 301% gcc -v
| Reading specs from /usr/lib/gcc-lib/powerpc-unknown-linux-gnu/gcc-2.95/specs
| gcc version gcc-2.95 19990623 (prerelease)
| ramoth:~ 302% cat breakage.c
| int main()
| {
|     int *ip;
|     int i = 1, j = 1, n = 10;
|     double *dpi;
|
|     for (i = 0; i < n; i++) {
|         *(dpi++) = (double) ip[i+n*j];
|         *(dpi++) = 0.;
|     }
|
|     return 0;
| }
| ramoth:~ 303% gcc --save-temps -O -c breakage.c
| breakage.c: In function `main':
| breakage.c:13: Internal compiler error in `output_440', at insn-output.c:1524
| Please submit a full bug report to `egcs-bugs@egcs.cygnus.com'.
| See <URL: http://egcs.cygnus.com/faq.html#bugreport > for details.

gcc was configured with '../egcs-19990623/configure --prefix=/usr'.

I made no modifications to the compiler source.

Removing the for loop or either of the two statements contained within
make it compile.

I had several other problems with 'output_440' errors, but have not
isolated the bug yet.  Unfortunately I cannot send the full source.

Thank you,
-bcd
--
**               Brian Downing
**  UNIX Systems Administrator
**        bdowning@wolfram.com

Re: Internal compiler error in gcc-2.95 19990623 on PowerPC

[Jeffrey A Law]

  In message <99070102051800.01156@ns1102.munich.netsurf.de>you write:
  > Breakpoint 1, output_440 (operands=0x1bcb514, insn=0x1be24c8) at insn-outpu
  > t.c:1463
  > 1463      switch (which_alternative)
  > (gdb) p debug_rtx(insn)
  > 
  > (insn:TI 51 45 52 (set (mem:DF (pre_inc:SI (reg/v:SI 11 r11)) 1)
  >         (reg:DF 7 r7)) 440 {*movdf_hardfloat32} (insn_list:REG_DEP_ANTI 45 
  > (nil))
  >     (expr_list:REG_INC (reg/v:SI 11 r11)
  >         (nil)))
  > $5 = void
  > (gdb) p which_alternative
  > $6 = 2
  > ^^^^^^^
  > 
  > Shouldn't that be alternative 8 here?
No.  Alternative 8 is for a store from 'f' to 'm'.  reg11 is not a floating
point register.

Alternative 2 is for a store from 'r' to 'm'.  reg11 is a gpr.



jeff

Re: Internal compiler error in gcc-2.95 19990623 on PowerPC

[David Edelsohn]

>>>>> Jeffrey A Law writes:

Jeff> Note the the PRE_INC/PRE_DEC case is trivial to implement -- just do the
Jeff> inc/dec of the base register and emit code as if the address was offsettable.

	PowerPC only supports PRE_INC/PRE_DEC.  As far as I can tell, the
original offsettable sequences handle these exact cases -- it performs the
load or store with update to the lower address and then the neighboring
load or store without update using displacement 4.  I cannot see any case
in which the PRE_INC/PRE_DEC affects the validity of the address in this
instance despite the offsettable test failing.

	I think the real problem has been that offsettable_memref_p() is
not the right test for which sequence to use on PowerPC, or at least the
mode_dependent_address_p() restriction is inappropriate.  The question
really should be nonindexed_memref_p().

	I have applied the appended patch to the mainline which handles
PRE_INC and PRE_DEC as offsettable, just like LO_SUM.

David

Index: rs6000.md
===================================================================
RCS file: /egcs/carton/cvsfiles/egcs/gcc/config/rs6000/rs6000.md,v
retrieving revision 1.55.4.6
diff -c -p -r1.55.4.6 rs6000.md
*** rs6000.md	1999/06/28 03:21:13	1.55.4.6
--- rs6000.md	1999/07/02 03:56:24
***************
*** 6329,6335 ****
      case 1:
        if (offsettable_memref_p (operands[1])
  	  || (GET_CODE (operands[1]) == MEM
! 	      && GET_CODE (XEXP (operands[1], 0)) == LO_SUM))
  	{
  	  /* If the low-address word is used in the address, we must load
  	     it last.  Otherwise, load it first.  Note that we cannot have
--- 6329,6337 ----
      case 1:
        if (offsettable_memref_p (operands[1])
  	  || (GET_CODE (operands[1]) == MEM
! 	      && (GET_CODE (XEXP (operands[1], 0)) == LO_SUM
! 		  || GET_CODE (XEXP (operands[1], 0)) == PRE_INC
! 		  || GET_CODE (XEXP (operands[1], 0)) == PRE_DEC)))
  	{
  	  /* If the low-address word is used in the address, we must load
  	     it last.  Otherwise, load it first.  Note that we cannot have
***************
*** 6345,6354 ****
  	{
  	  rtx addreg;
  
- 	  if (GET_CODE (XEXP (operands[1], 0)) == PRE_INC
- 	      || GET_CODE (XEXP (operands[1], 0)) == PRE_DEC)
- 	    abort ();
- 
  	  addreg = find_addr_reg (XEXP (operands[1], 0));
  	  if (refers_to_regno_p (REGNO (operands[0]),
  				 REGNO (operands[0]) + 1,
--- 6347,6352 ----
***************
*** 6371,6385 ****
      case 2:
        if (offsettable_memref_p (operands[0])
  	  || (GET_CODE (operands[0]) == MEM
! 	      && GET_CODE (XEXP (operands[0], 0)) == LO_SUM))
  	return \"{st%U0|stw%U0} %1,%0\;{st|stw} %L1,%L0\";
        else
  	{
  	  rtx addreg;
- 
- 	  if (GET_CODE (XEXP (operands[0], 0)) == PRE_INC
- 	      || GET_CODE (XEXP (operands[0], 0)) == PRE_DEC)
- 	    abort ();
  
  	  addreg = find_addr_reg (XEXP (operands[0], 0));
  	  output_asm_insn (\"{stx|stwx} %1,%0\", operands);
--- 6369,6381 ----
      case 2:
        if (offsettable_memref_p (operands[0])
  	  || (GET_CODE (operands[0]) == MEM
! 	      && (GET_CODE (XEXP (operands[0], 0)) == LO_SUM
! 		  || GET_CODE (XEXP (operands[0], 0)) == PRE_INC
! 		  || GET_CODE (XEXP (operands[0], 0)) == PRE_DEC)))
  	return \"{st%U0|stw%U0} %1,%0\;{st|stw} %L1,%L0\";
        else
  	{
  	  rtx addreg;
  
  	  addreg = find_addr_reg (XEXP (operands[0], 0));
  	  output_asm_insn (\"{stx|stwx} %1,%0\", operands);

Re: Internal compiler error in gcc-2.95 19990623 on PowerPC

[Jeffrey A Law]

  In message <9906302201.AA35708@marc.watson.ibm.com>you write:
  > 	This seems to be where the PowerPC port protects against the case
  > that Jeff was worried about before: incrementing an unaligned displacement
  > address so that it no longer is accessible via a displacement on the
  > particular target.  If this were written as
  > 
  > 	(plus (reg:SI 31) (const_int 4))
  > 
  > I think that this would have been considered valid.
  > 
  > 	PRE_DEC or PRE_INC gets very complicated to implement for the
  > cases I wrote because one now needs to adjust the address first, make sure
  > that works with the code that loads or stores the second word, and then
  > leave the address updated.
Doesn't the powerpc have store with base register modification that is not
tied to the size of the operand?

If so, it's not that bad.  And we can (again) use the PA as a template since
it handles this case too.

For a POST_DEC store to memory without an overlap we generate
	store left half with post modify by -8
        store right half with a +12 index

      POST_INC
        store left half with post modify by +8
        store right half with -4 index

      PRE_INC
        store left half with pre modify by +8
        store right half with index +4

      PRE_DEC
        store left half with pre modify -8
        store right half with index +4
 
If there is any kind of overlap on the store, we abort.

Loads are handled in a similar manner.


Note the the PRE_INC/PRE_DEC case is trivial to implement -- just do the
inc/dec of the base register and emit code as if the address was offsettable.

jeff
jeff

Re: Internal compiler error in gcc-2.95 19990623 on PowerPC

[Jeffrey A Law]

  In message < 9907021433.AA44360@marc.watson.ibm.com >you write:
  > 	This, however, leads me back to the question of why auto-increment
  > generally is not offsettable.
Because most systems do not have an addressing mode which allows for both
an autoincrement and an unrelated offset/index register.  ie:

(plus (autoinc (reg) (offset)

Where offset could be any constant value or another register.

jeff

Re: Internal compiler error in gcc-2.95 19990623 on PowerPC

[David Edelsohn]

>>>>> Jeffrey A Law writes:

Jeff> How can you overflow the offset in an autoincrement address?

Jeff> An autoincrement address always looks like (autoinc_inc (reg))

Jeff> Ie, the offset in the address is always zero.  So adding +- 4, 8 12,  can
Jeff> never overflow/underflow the offset.

	What confused me was offsettable_memref_p() cared about
mode_dependent_address_p() which disallows PRE_INC and PRE_DEC on PowerPC.
The update form of load and store instructions on PowerPC is more powerful
than simply PRE_INC and PRE_DEC: it will update the base register based on
the displacement or index, not mode size.

	I thought that the offsettable_memref_p() failure was trying to
prevent GCC from pre-incrementing an offset-form address because it might
overflow the displacement field.  That is not how PRE_INC is used, so that
is not a problem.

	This, however, leads me back to the question of why auto-increment
generally is not offsettable.

David

Re: Internal compiler error in gcc-2.95 19990623 on PowerPC

[Jeffrey A Law]

  In message < 9907011801.AA40704@marc.watson.ibm.com >you write:
  > 	This is exactly the case that we cannot perform using an
  > offsettable address.  The PRE_INC/PRE_DEC case is +/- 8 which could force
  > the displacement beyond the range of the displacement field.  For LO_SUM,
  > an aligned value could not create a displacement larger than 4 and had to
  > be safe if the original address were safe.  For PRE_INC_PRE_DEC, all bets
  > are off.  This is exactly the case that must be handled by incrementing or
  > decrementing the base register, not modifying the actual offset.
It's academic now, but I think we've got a mis-communication.

How can you overflow the offset in an autoincrement address?

An autoincrement address always looks like (autoinc_inc (reg))

Ie, the offset in the address is always zero.  So adding +- 4, 8 12,  can
never overflow/underflow the offset.

jeff