Re: sh64 and mulilibs

Re: sh64 and mulilibs

[Joern Rennecke]

> How are we supposed to configure these now?  There's nothing in the
> docs about configure options, and it looks like they wouldn't work
> anyway, as the t-mlib files define variables that aren't used
> anywhere, and patching the t-mlib files doesn't seem to help either.

They are usually configured along the rest of the toolchain, e.g.:

#!/bin/bash
expect -c 'spawn cvs -z 9 -d :pserver:anoncvs@gcc.gnu.org:/cvs/gcc login' -c 'expect "CVS password"' -c 'send \r' -c interact
cvs -z 9 -d :pserver:anoncvs@gcc.gnu.org:/cvs/gcc co -ko -D "$IDATE $CO_TIME" gcc-core
cvs -z 9 -d :pserver:anoncvs@gcc.gnu.org:/cvs/gcc co -ko -D "$IDATE $CO_TIME" gcc/gcc/fixinc gcc-testsuite
cvs -z 9 -d :pserver:anoncvs@gcc.gnu.org:/cvs/gcc co -ko -D "$IDATE $CO_TIME" gcc-g++ gcc-g++-testsuite gcc-objc
echo $IDATE $CO_TIME > gcc/gcc/LAST_UPDATED
date
expect -c 'spawn cvs -z 9 -d :pserver:anoncvs@sources.redhat.com:/cvs/src login' -c 'expect "CVS password"' -c 'send \r' -c interact
cvs -z 9 -d :pserver:anoncvs@sources.redhat.com:/cvs/src co -ko -D "$IDATE $CO_TIME" binutils naked-newlib naked-libgloss naked-readline naked-mmalloc naked-utils src/djunpack.bat
date
mkdir srcw-l
cd srcw-l
ln -s ../gcc/* .
rm include libgfortran
ln -s ../src/* .
cd ..
cp -Lpr srcw-l srcw
cp gcc/include/*.h srcw/include/
mkdir sh64-elf
cd sh64-elf
../srcw/configure --target=sh64-elf --with-headers --with-newlib --disable-gdb
time make all-gcc all-target-newlib all-target-libstdc++-v3 all-target-libobjc

> And if you have built sh64 multilibs recently, a few side questions:
> 
> * How are the C++ test results?

See:

http://gcc.gnu.org/ml/gcc-testresults/2004-09/msg00085.html

Re: sh64 and mulilibs

[DJ Delorie]

> ../srcw/configure --target=sh64-elf --with-headers --with-newlib --disable-gdb

No, this doesn't work for me.  I get the -ml multilib and nothing
else.  How can it work?  t-mlib-sh5-compact, for example, defines:

ML_sh5_compact=m5-compact/

but t-sh64 has $(ML_m5_compact:m5_compact=compact) so it will never
see a set value.

Are you sure you don't have any local changes?

> > * How are the C++ test results?
> 
> See:
> 
> http://gcc.gnu.org/ml/gcc-testresults/2004-09/msg00085.html

1) I can't even build newlib because cc1 segfaults in
   sh_gimplify_va_arg (I sent mail to rth about it).

2) Your results don't have any pic/PIC multilibs.  Do they work?

Re: sh64 and mulilibs

[Joern Rennecke]

> > ../srcw/configure --target=sh64-elf --with-headers --with-newlib --disable-gdb
> 
> No, this doesn't work for me.  I get the -ml multilib and nothing
> else.  How can it work?  t-mlib-sh5-compact, for example, defines:
> 
> ML_sh5_compact=m5-compact/
> 
> but t-sh64 has $(ML_m5_compact:m5_compact=compact) so it will never
> see a set value.

No it hasn't.  Make sure you are looking at version 1.7 .
> 
> Are you sure you don't have any local changes?

The nightly tests are built straight from CVS.  There are only local
patches in the expect and gdb / simulator used.
The build actually builds twelve multilibs, but only three are tested in
order to make the test results come out in a reasonable amount of time.

> > > * How are the C++ test results?
> > 
> > See:
> > 
> > http://gcc.gnu.org/ml/gcc-testresults/2004-09/msg00085.html
> 
> 1) I can't even build newlib because cc1 segfaults in
>    sh_gimplify_va_arg (I sent mail to rth about it).

This sounds like you are using old sources.  This has been a problem when
this function was new.

> 2) Your results don't have any pic/PIC multilibs.  Do they work?

The newlib based bare CPU toolchain generally doesn't use PIC in its
libraries.  Linux uses PIC throughout, and I understand Kaz Kojima builds
sh64-linux-gnu from mainline.  We use a number of local patches
in a 3.2.1 based toolchain to get visibility of symbols in shared
libraries right.

Re: sh64 and mulilibs

[DJ Delorie]

> > but t-sh64 has $(ML_m5_compact:m5_compact=compact) so it will never
> > see a set value.
> 
> No it hasn't.  Make sure you are looking at version 1.7 .

I did a cvs update before reporting this.  t-sh64 is at 1.7.

> > 1) I can't even build newlib because cc1 segfaults in
> >    sh_gimplify_va_arg (I sent mail to rth about it).
> 
> This sounds like you are using old sources.  This has been a problem when
> this function was new.

I did a cvs get yesterday.  I just double checked to make sure I'm not
using a branch or date cutoff.

Re: sh64 and mulilibs

[Joern Rennecke]

> 
> 
> > > but t-sh64 has $(ML_m5_compact:m5_compact=compact) so it will never
> > > see a set value.
> > 
> > No it hasn't.  Make sure you are looking at version 1.7 .
> 
> I did a cvs update before reporting this.  t-sh64 is at 1.7.

I think I must have mis-read your message originally.
$(ML_m5_compact:m5_compact=compact) is not present as a line of itself,
but it was part of MULTILIB_CPU_DIRS.

An inspection of the nightly sh64-elf build also showed that multilibbing
didn't extend beyond endianness.

I have applied the following patch:

2004-09-17  J"orn Rennecke <joern.rennecke@superh.com>

	* sh.c (sh_gimplify_va_arg_expr): Don't call pass_by_reference.
	(sh_pass_by_reference): Work around std_gimplify_va_arg_expr bug.
	* t-sh (MULTILIB_CPUS): s/ML_m/ML_sh/g .
	* t-sh64 (MULTILIB_CPU_DIRS): Likewise.  Match dashes and trailing
	slashes in substitutions.
	(MULTILIB_DIRNAMES): Remove defunct removal of /media32.

Index: sh.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config/sh/sh.c,v
retrieving revision 1.297
diff -p -r1.297 sh.c
*** sh.c	8 Sep 2004 18:45:18 -0000	1.297
--- sh.c	17 Sep 2004 11:50:49 -0000
*************** sh_gimplify_va_arg_expr (tree valist, tr
*** 6382,6388 ****
    HOST_WIDE_INT size, rsize;
    tree tmp, pptr_type_node;
    tree addr, lab_over, result = NULL;
!   int pass_by_ref = pass_by_reference (NULL, TYPE_MODE (type), type, false);
  
    if (pass_by_ref)
      type = build_pointer_type (type);
--- 6382,6388 ----
    HOST_WIDE_INT size, rsize;
    tree tmp, pptr_type_node;
    tree addr, lab_over, result = NULL;
!   int pass_by_ref = targetm.calls.must_pass_in_stack (TYPE_MODE (type), type);
  
    if (pass_by_ref)
      type = build_pointer_type (type);
*************** sh_pass_by_reference (CUMULATIVE_ARGS *c
*** 6604,6609 ****
--- 6604,6615 ----
    if (targetm.calls.must_pass_in_stack (mode, type))
      return true;
  
+   /* ??? std_gimplify_va_arg_expr passes NULL for cum.  That function
+      wants to know about pass-by-reference semantics for incoming
+      arguments.  */
+   if (! cum)
+     return false;
+ 
    if (TARGET_SHCOMPACT)
      {
        cum->byref = shcompact_byref (cum, mode, type, named);
Index: t-sh
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config/sh/t-sh,v
retrieving revision 1.20
diff -p -r1.20 t-sh
*** t-sh	29 Jul 2004 06:10:03 -0000	1.20
--- t-sh	17 Sep 2004 11:50:49 -0000
*************** fp-bit.c: $(srcdir)/config/fp-bit.c
*** 22,28 ****
  	cat $(srcdir)/config/fp-bit.c >> fp-bit.c
  
  MULTILIB_ENDIAN = ml/mb
! MULTILIB_CPUS= $(ML_sh1)$(ML_sh2a)$(ML_sh2a_nofpu)$(ML_sh2a_single_only)$(ML_sh2a_single)$(ML_sh2e)$(ML_sh2)$(ML_sh3e)$(ML_sh3)$(ML_sh4_nofpu)$(ML_sh4_single_only)$(ML_sh4_single)$(ML_sh4)$(ML_sh4a_nofpu)$(ML_sh4a_single_only)$(ML_sh4a_single)$(ML_sh4a)$(ML_m5_32media)$(ML_m5_32media_nofpu)$(ML_m5_compact)$(ML_m5_compact_nofpu)$(ML_m5_64media)$(ML_m5_64media_nofpu)
  
  MULTILIB_OPTIONS= $(MULTILIB_ENDIAN) $(MULTILIB_CPUS:/=)
  MULTILIB_DIRNAMES= 
--- 22,28 ----
  	cat $(srcdir)/config/fp-bit.c >> fp-bit.c
  
  MULTILIB_ENDIAN = ml/mb
! MULTILIB_CPUS= $(ML_sh1)$(ML_sh2a)$(ML_sh2a_nofpu)$(ML_sh2a_single_only)$(ML_sh2a_single)$(ML_sh2e)$(ML_sh2)$(ML_sh3e)$(ML_sh3)$(ML_sh4_nofpu)$(ML_sh4_single_only)$(ML_sh4_single)$(ML_sh4)$(ML_sh4a_nofpu)$(ML_sh4a_single_only)$(ML_sh4a_single)$(ML_sh4a)$(ML_sh5_32media)$(ML_sh5_32media_nofpu)$(ML_sh5_compact)$(ML_sh5_compact_nofpu)$(ML_sh5_64media)$(ML_sh5_64media_nofpu)
  
  MULTILIB_OPTIONS= $(MULTILIB_ENDIAN) $(MULTILIB_CPUS:/=)
  MULTILIB_DIRNAMES= 
Index: t-sh64
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config/sh/t-sh64,v
retrieving revision 1.7
diff -p -r1.7 t-sh64
*** t-sh64	21 Jun 2004 18:18:40 -0000	1.7
--- t-sh64	17 Sep 2004 11:50:49 -0000
*************** LIB1ASMFUNCS = \
*** 7,13 ****
    _push_pop_shmedia_regs \
    _udivdi3 _divdi3 _umoddi3 _moddi3
  
! MULTILIB_CPU_DIRS= $(ML_sh1) $(ML_sh2e) $(ML_sh2) $(ML_sh3e) $(ML_sh3) $(ML_sh4_nofpu) $(ML_sh4_single_only) $(ML_sh4_single) $(ML_sh4) $(ML_m5_32media:m5_32media=media32) $(ML_m5_32media_nofpu:m5_32media_nofpu=nofpu/media32) $(ML_m5_compact:m5_compact=compact) $(ML_m5_compact_nofpu:m5_compact_nofpu=nofpu/compact) $(ML_m5_64media:m5_64media=media64) $(ML_m5_64media_nofpu:m5_64media_nofpu=nofpu/media64)
  
  MULTILIB_RAW_DIRNAMES= $(MULTILIB_ENDIAN:/mb= mb) $(MULTILIB_CPU_DIRS:/=)
! MULTILIB_DIRNAMES= $(MULTILIB_RAW_DIRNAMES:/media32=)
--- 7,13 ----
    _push_pop_shmedia_regs \
    _udivdi3 _divdi3 _umoddi3 _moddi3
  
! MULTILIB_CPU_DIRS= $(ML_sh1) $(ML_sh2e) $(ML_sh2) $(ML_sh3e) $(ML_sh3) $(ML_sh4_nofpu) $(ML_sh4_single_only) $(ML_sh4_single) $(ML_sh4) $(ML_sh5_32media:m5-32media/=media32) $(ML_sh5_32media_nofpu:m5-32media-nofpu/=nofpu/media32) $(ML_sh5_compact:m5-compact/=compact) $(ML_sh5_compact_nofpu:m5-compact-nofpu/=nofpu/compact) $(ML_sh5_64media:m5-64media/=media64) $(ML_sh5_64media_nofpu:m5-64media-nofpu/=nofpu/media64)
  
  MULTILIB_RAW_DIRNAMES= $(MULTILIB_ENDIAN:/mb= mb) $(MULTILIB_CPU_DIRS:/=)
! MULTILIB_DIRNAMES= $(MULTILIB_RAW_DIRNAMES)

Re: sh64 and mulilibs

[Kaz Kojima]

DJ Delorie <dj@redhat.com> wrote:
> And if you have built sh64 multilibs recently, a few side questions:
> 
> * How are the C++ test results?
> 
> * Does EH work right?
> 
> * How about EH with pic/PIC?

Coincidentally I'm looking the last issue, though I'm always
using --disable-multilib for sh64-unknown-linux-gnu.  All c++
testcases using dw2 EH fail on this target because of PIC EH
problems.

I'd like to split my current patch for sh64 PIC EH problems
into independent and send them to the gcc-patch, ASAP.
With those patches and

  http://gcc.gnu.org/ml/gcc-patches/2004-08/msg00132.html
  http://gcc.gnu.org/ml/gcc-patches/2004-08/msg00156.html

I've got an almost same result as sh64-elf for g++ testsuite
on mainline.

Regards,
	kaz

sh64 and mulilibs

[DJ Delorie]

How are we supposed to configure these now?  There's nothing in the
docs about configure options, and it looks like they wouldn't work
anyway, as the t-mlib files define variables that aren't used
anywhere, and patching the t-mlib files doesn't seem to help either.

And if you have built sh64 multilibs recently, a few side questions:

* How are the C++ test results?

* Does EH work right?

* How about EH with pic/PIC?

I'm running into these questions with some older sources, and trying
to reproduce (and thus debug) them with the current sources.