Re: [jakub@redhat.com: Re: 2.95.4, sparc64 issues ?]

Re: [jakub@redhat.com: Re: 2.95.4, sparc64 issues ?]

[Artur Grabowski]

Marc Espie <espie@schutzenberger.liafa.jussieu.fr> writes:

> From: Jakub Jelinek <jakub@redhat.com>
> Subject: Re: 2.95.4, sparc64 issues ?
> To: Marc.Espie@liafa.jussieu.fr
> Cc: Bernd Schmidt <bernds@redhat.com>, gcc@gcc.gnu.org
> Date: Mon, 10 Sep 2001 15:56:15 +0200
> 
> 
> On Mon, Sep 10, 2001 at 03:49:14PM +0200, Marc Espie wrote:
> > It seems that libstdc++ does not compile on every sparc64 machine,
> > and that the following patch (from current) might be enough to fix it ?
> 
> Targeting -m64 on sparc with gcc 2.95.x is a bad idea, this is not the only
> place which needs changing.
> 
> 	Jakub

Since it's a bad idea and noone in their right mind will try to use it, it
won't hurt if you put that diff in because noone should notice, right?
Not fixing bugs with the motivation that there are other bugs feels like a
catch 22.

I really don't want OpenBSD to get into the position of other operating systems
that must compile the system with different versions of gcc for every
architecture. Right now we can almost get a working system for sparc64 with
some makefile changes (-O0 on some files) and some minor compiler fixes.

//art

Re: [jakub@redhat.com: Re: 2.95.4, sparc64 issues ?]

[Bernd Schmidt]

On 10 Sep 2001, Artur Grabowski wrote:

> > From: Jakub Jelinek <jakub@redhat.com>
> >
> > Targeting -m64 on sparc with gcc 2.95.x is a bad idea, this is not the only
> > place which needs changing.
> >
> > 	Jakub
>
> Since it's a bad idea and noone in their right mind will try to use it, it
> won't hurt if you put that diff in because noone should notice, right?

Well, a justification of "Seems to allow libstdc++ to at least compile"
doesn't make me confident that there has been much thought put into issues
like, "will it actually work", or "could it be harmful on other targets".
That makes it unacceptable for a stable branch.

AFAIK you need the subreg-byte patch for proper sparc64 support.  This is
not going to be applied to 2.95.x.


Bernd

Re: [jakub@redhat.com: Re: 2.95.4, sparc64 issues ?]

[Marc Espie]

On Mon, Sep 10, 2001 at 04:58:55PM +0100, Bernd Schmidt wrote:
> Well, a justification of "Seems to allow libstdc++ to at least compile"
> doesn't make me confident that there has been much thought put into issues
> like, "will it actually work", or "could it be harmful on other targets".
> That makes it unacceptable for a stable branch.

The `could it be harmful on other targets' part is OBVIOUS.
I mean, adding a test to handle some unhandled case RIGHT IN FRONT OF AN
abort() is a complete NO-BRAINER.

As for the rest, yep, I think I want discussion about that.

Specifically, if we need some other sparc64 patch, what is that sub-reg
patch. Where can I get a version that does more or less apply to 2.95.3 ?

I am quite willing to do some testing on OpenBSD targets, and to release
a compiler that would work for us, even if it includes non-standard
patches.

Currently, gcc 3.0.1 is not an option. A gcc 3.x will probably be an option
in a year time, when it becomes somewhat usable.

We can't ship a compiler that miscompiles kde. We can't ship a compiler
that doesn't even compile OpenBSD i386 pic code correctly (no news on my
GOT/GOTOFF problems, rth ?).

Re: [jakub@redhat.com: Re: 2.95.4, sparc64 issues ?]

[Jakub Jelinek]

On Mon, Sep 10, 2001 at 06:45:28PM +0200, Marc Espie wrote:
> On Mon, Sep 10, 2001 at 04:58:55PM +0100, Bernd Schmidt wrote:
> > Well, a justification of "Seems to allow libstdc++ to at least compile"
> > doesn't make me confident that there has been much thought put into issues
> > like, "will it actually work", or "could it be harmful on other targets".
> > That makes it unacceptable for a stable branch.
> 
> The `could it be harmful on other targets' part is OBVIOUS.
> I mean, adding a test to handle some unhandled case RIGHT IN FRONT OF AN
> abort() is a complete NO-BRAINER.
> 
> As for the rest, yep, I think I want discussion about that.
> 
> Specifically, if we need some other sparc64 patch, what is that sub-reg
> patch. Where can I get a version that does more or less apply to 2.95.3 ?

There is no SUBREG_BYTE patch which would apply to 2.95.x. Plus this patch
touches almost all files in gcc, so backporting would not be easy.

As stated, it was not part of any compiler released by FSF.
The tested configurations are gcc-2.96-RH, there is a patch floating around
for 3.0 and finally it was commited into trunk after 3.0 was branched off.

	Jakub

Re: [jakub@redhat.com: Re: 2.95.4, sparc64 issues ?]

[Marc Espie]

On Mon, Sep 10, 2001 at 12:52:47PM -0400, Jakub Jelinek wrote:
> As stated, it was not part of any compiler released by FSF.
> The tested configurations are gcc-2.96-RH, there is a patch floating around
> for 3.0 and finally it was commited into trunk after 3.0 was branched off.

So, this means that there won't be any released version of gcc actually 
running somewhat correctly on sparc64 for yet a year at least, right ?

Re: [jakub@redhat.com: Re: 2.95.4, sparc64 issues ?]

[Jakub Jelinek]

On Mon, Sep 10, 2001 at 06:58:44PM +0200, Marc Espie wrote:
> On Mon, Sep 10, 2001 at 12:52:47PM -0400, Jakub Jelinek wrote:
> > As stated, it was not part of any compiler released by FSF.
> > The tested configurations are gcc-2.96-RH, there is a patch floating around
> > for 3.0 and finally it was commited into trunk after 3.0 was branched off.
> 
> So, this means that there won't be any released version of gcc actually 
> running somewhat correctly on sparc64 for yet a year at least, right ?

3.1 is scheduled for March I think.
Anyway, what prevents you from running 32-bit programs on top of 64-bit
kernel? That's what Linux does for quite some time.
You only need 64-bit compiler for the kernel.

	Jakub

Re: [jakub@redhat.com: Re: 2.95.4, sparc64 issues ?]

[Marc Espie]

On Mon, Sep 10, 2001 at 01:01:24PM -0400, Jakub Jelinek wrote:
> On Mon, Sep 10, 2001 at 06:58:44PM +0200, Marc Espie wrote:
> > On Mon, Sep 10, 2001 at 12:52:47PM -0400, Jakub Jelinek wrote:
> > > As stated, it was not part of any compiler released by FSF.
> > > The tested configurations are gcc-2.96-RH, there is a patch floating around
> > > for 3.0 and finally it was commited into trunk after 3.0 was branched off.
> > 
> > So, this means that there won't be any released version of gcc actually 
> > running somewhat correctly on sparc64 for yet a year at least, right ?
> 
> 3.1 is scheduled for March I think.
Oops, sorry. I sincerely hope it meets the schedule this time. Okay, still
six months away. And still one year for us. I don't expect 3.1 to be
reasonably bug-free... and March is much too close to our release schedule
for switching compilers at that point. So, for OpenBSD, that means no
3.1.x before december release. Over a year away.

> Anyway, what prevents you from running 32-bit programs on top of 64-bit
> kernel? That's what Linux does for quite some time.
> You only need 64-bit compiler for the kernel.

Oh sure. Use one compiler for the kernel and another compiler for userland.
Get real. This kind of double the number of bugs that exist. Plus double
the maintenance.

Besides, stylistically, it's disgusting.

Re: [jakub@redhat.com: Re: 2.95.4, sparc64 issues ?]

[Jakub Jelinek]

On Mon, Sep 10, 2001 at 07:07:25PM +0200, Marc Espie wrote:
> > Anyway, what prevents you from running 32-bit programs on top of 64-bit
> > kernel? That's what Linux does for quite some time.
> > You only need 64-bit compiler for the kernel.
> 
> Oh sure. Use one compiler for the kernel and another compiler for userland.
> Get real. This kind of double the number of bugs that exist. Plus double
> the maintenance.

It is not actually that big burden. At least Linux kernel doesn't use
any floating point code, so there is no reason to worry about SUBREG_BYTE.
If you use -mno-fpu, gcc will never attempt to generate any such code, so
you could use unpatched 2.95.4.
Linux kernel used to be compiled even with some egcs 1.1.x snapshots on
sparc64 and it worked. It can take some time to stabilize the thing, but
definitely far less than trying to use the compiler for compiling userland
stuff.

	Jakub

Re: [jakub@redhat.com: Re: 2.95.4, sparc64 issues ?]

[David Edelsohn]

>>>>> Marc Espie writes:

Marc> So, this means that there won't be any released version of gcc actually 
Marc> running somewhat correctly on sparc64 for yet a year at least, right ?

	GCC 3.1 is planned for April; that is less than a year away.

	The SUBREG_BYTE patch cannot be backported.  It still is causing
problems for the PowerPC port, even on the trunk.

David

Re: [jakub@redhat.com: Re: 2.95.4, sparc64 issues ?]

[Artur Grabowski]

Jakub Jelinek <jakub@redhat.com> writes:

> On Mon, Sep 10, 2001 at 06:45:28PM +0200, Marc Espie wrote:
> > On Mon, Sep 10, 2001 at 04:58:55PM +0100, Bernd Schmidt wrote:
> > > Well, a justification of "Seems to allow libstdc++ to at least compile"
> > > doesn't make me confident that there has been much thought put into issues
> > > like, "will it actually work", or "could it be harmful on other targets".
> > > That makes it unacceptable for a stable branch.
> > 
> > The `could it be harmful on other targets' part is OBVIOUS.
> > I mean, adding a test to handle some unhandled case RIGHT IN FRONT OF AN
> > abort() is a complete NO-BRAINER.
> > 
> > As for the rest, yep, I think I want discussion about that.
> > 
> > Specifically, if we need some other sparc64 patch, what is that sub-reg
> > patch. Where can I get a version that does more or less apply to 2.95.3 ?
> 
> There is no SUBREG_BYTE patch which would apply to 2.95.x. Plus this patch
> touches almost all files in gcc, so backporting would not be easy.

Can someone explain to a dumb kernel hacker what magical problem it solves
that can't be worked around or kludged?

I don't think we plan to include sparc64 in a regular release until december
next year anyway because we want our code stable before we release it, but
it's pretty hard to make the code stable without being able to test it.

//art

openbsd gotoff workaround

[Richard Henderson]

On Mon, Sep 10, 2001 at 06:45:28PM +0200, Marc Espie wrote:
> We can't ship a compiler that doesn't even compile OpenBSD i386 pic
> code correctly (no news on my GOT/GOTOFF problems, rth ?).

Try this.


r~



Index: i386.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config/i386/i386.c,v
retrieving revision 1.211.2.14
diff -c -p -d -r1.211.2.14 i386.c
*** i386.c	2001/08/06 21:26:24	1.211.2.14
--- i386.c	2001/09/11 01:15:36
*************** int ix86_align_loops;
*** 417,423 ****
--- 417,428 ----
  
  /* Power of two alignment for non-loop jumps.  */
  int ix86_align_jumps;
+ 
+ /* Prefix built by ASM_GENERATE_INTERNAL_LABEL.  */
+ static int internal_label_prefix[16];
+ static int internal_label_prefix_len;
  \f
+ static int local_symbolic_operand PARAMS ((rtx, enum machine_mode));
  static void output_pic_addr_const PARAMS ((FILE *, rtx, int));
  static void put_condition_code PARAMS ((enum rtx_code, enum machine_mode,
  				       int, int, FILE *));
*************** override_options ()
*** 693,698 ****
--- 698,712 ----
       on by -msse.  */
    if (TARGET_SSE)
      target_flags |= MASK_MMX;
+ 
+   /* Figure out what ASM_GENERATE_INTERNAL_LABEL builds as a prefix.  */
+   {
+     char *p;
+     ASM_GENERATE_INTERNAL_LABEL (internal_label_prefix, "LX", 0);
+     p = strchr (internal_label_prefix, 'X');
+     internal_label_prefix_len = p - internal_label_prefix;
+     *p = '\0';
+   }
  }
  \f
  /* A C statement (sans semicolon) to choose the order in which to
*************** pic_symbolic_operand (op, mode)
*** 1128,1133 ****
--- 1142,1181 ----
    return 0;
  }
  
+ /* Return true if OP is a symbolic operand that resolves locally.  */
+ 
+ static int
+ local_symbolic_operand (op, mode)
+      rtx op;
+      enum machine_mode mode ATTRIBUTE_UNUSED;
+ {
+   if (GET_CODE (op) == LABEL_REF)
+     return 1;
+ 
+   if (GET_CODE (op) == CONST
+       && GET_CODE (XEXP (op, 0)) == PLUS
+       && GET_CODE (XEXP (XEXP (op, 0), 1)) == CONST_INT)
+     op = XEXP (XEXP (op, 0), 0);
+ 
+   if (GET_CODE (op) != SYMBOL_REF)
+     return 0;
+ 
+   /* These we've been told are local by varasm and encode_section_info
+      respectively.  */
+   if (CONSTANT_POOL_ADDRESS_P (op) || SYMBOL_REF_FLAG (op))
+     return 1;
+ 
+   /* There is, however, a not insubstantial body of code in the rest of
+      the compiler that assumes it can just stick the results of 
+      ASM_GENERATE_INTERNAL_LABEL in a symbol_ref and have done.  */
+ 
+   if (strncmp (XSTR (op, 0), internal_label_prefix,
+ 	       internal_label_prefix_len) == 0)
+     return 1;
+ 
+   return 0;
+ }
+ 
  /* Test for a valid operand for a call instruction.  Don't allow the
     arg pointer register or virtual regs since they may decay into
     reg + const, which the patterns can't handle.  */
*************** legitimize_pic_address (orig, reg)
*** 2767,2776 ****
    rtx new = orig;
    rtx base;
  
!   if (GET_CODE (addr) == LABEL_REF
!       || (GET_CODE (addr) == SYMBOL_REF
! 	  && (CONSTANT_POOL_ADDRESS_P (addr)
! 	      || SYMBOL_REF_FLAG (addr))))
      {
        /* This symbol may be referenced via a displacement from the PIC
  	 base address (@GOTOFF).  */
--- 2815,2821 ----
    rtx new = orig;
    rtx base;
  
!   if (local_symbolic_operand (addr, Pmode))
      {
        /* This symbol may be referenced via a displacement from the PIC
  	 base address (@GOTOFF).  */
*************** legitimize_pic_address (orig, reg)
*** 2822,2831 ****
  
  	  /* Check first to see if this is a constant offset from a @GOTOFF
  	     symbol reference.  */
! 	  if ((GET_CODE (op0) == LABEL_REF
! 	       || (GET_CODE (op0) == SYMBOL_REF
! 		   && (CONSTANT_POOL_ADDRESS_P (op0)
! 		       || SYMBOL_REF_FLAG (op0))))
  	      && GET_CODE (op1) == CONST_INT)
  	    {
  	      current_function_uses_pic_offset_table = 1;
--- 2867,2873 ----
  
  	  /* Check first to see if this is a constant offset from a @GOTOFF
  	     symbol reference.  */
! 	  if (local_symbolic_operand (op0, Pmode))
  	      && GET_CODE (op1) == CONST_INT)
  	    {
  	      current_function_uses_pic_offset_table = 1;