Re: GCC3.0.4 : Solaris 2.6 build failure

Re: GCC3.0.4 : Solaris 2.6 build failure

[lucier]

Re: The discussion about whether -mcpu=ultrasparc works on gcc-3.0.4

My experience with -mcpu=ultrasparc on the 3.0.* series is that it
doesn't work worth a damn.

Even on the mainline, routines are effectively restricted to < 128Kbytes
in size on sparcv9 (see PR 5626; the commentary there says that that
the limit is 256Kbytes, but that is incorrect).

So, for my purposes, the mainline sparcv9 port of gcc 3.1 doesn't work,
either.

Brad

Re: GCC3.0.4 : Solaris 2.6 build failure

[Jakub Jelinek]

On Fri, Feb 22, 2002 at 10:53:46PM -0500, lucier@math.purdue.edu wrote:
> Re: The discussion about whether -mcpu=ultrasparc works on gcc-3.0.4
> 
> My experience with -mcpu=ultrasparc on the 3.0.* series is that it
> doesn't work worth a damn.
> 
> Even on the mainline, routines are effectively restricted to < 128Kbytes
> in size on sparcv9 (see PR 5626; the commentary there says that that
> the limit is 256Kbytes, but that is incorrect).

I'm working on a patch for this...

> So, for my purposes, the mainline sparcv9 port of gcc 3.1 doesn't work,
> either.

	Jakub

Re: GCC3.0.4 : Solaris 2.6 build failure

[Craig Rodrigues]

On Fri, Feb 22, 2002 at 08:16:28PM -0300, Alexandre Oliva wrote:
> On Feb 22, 2002, Jakub Jelinek <jakub@redhat.com> wrote:
> 
> > Only -m64 causes SFmode float registers to be smaller than word which is
> > what caused the problems, with -m32 -mcpu=ultrasparc it is the same as
> > with -m32 -mtune=ultrasparc.
> 
> Well, it may be the same for 2.96-RH, but it's definitely not for
> 3.0.  People have repeatedly reported problems with -mcpu=ultrasparc,
> and using -mtune=ultrasparc instead has fixed the problem in all cases
> I heard back.

I'm not too familiar with the specifics of Solaris, but
isn't this problem mentioned in the platform specific
install notes?

http://gcc.gnu.org/install/specific.html#sparc-sun-solaris2*

Is the wording of this section clear, or do we need to
clarify it? 
-- 
Craig Rodrigues        
http://www.gis.net/~craigr    
rodrigc@attbi.com

Re: GCC3.0.4 : Solaris 2.6 build failure

[Alexandre Oliva]

On Feb 22, 2002, Jakub Jelinek <jakub@redhat.com> wrote:

> Only -m64 causes SFmode float registers to be smaller than word which is
> what caused the problems, with -m32 -mcpu=ultrasparc it is the same as
> with -m32 -mtune=ultrasparc.

Well, it may be the same for 2.96-RH, but it's definitely not for
3.0.  People have repeatedly reported problems with -mcpu=ultrasparc,
and using -mtune=ultrasparc instead has fixed the problem in all cases
I heard back.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: GCC3.0.4 : Solaris 2.6 build failure

[Jakub Jelinek]

On Fri, Feb 22, 2002 at 07:24:43PM -0300, Alexandre Oliva wrote:
> On Feb 22, 2002, Jakub Jelinek <jakub@redhat.com> wrote:
> 
> > On Fri, Feb 22, 2002 at 06:46:23PM -0300, Alexandre Oliva wrote:
> >> On Feb 22, 2002, Jakub Jelinek <jakub@redhat.com> wrote:
> >> 
> >> > -mcpu=ultrasparc is different from -m64.
> >> 
> >> What's your point?  -mcpu=ultrasparc has problems in 3.0 just the same.
> 
> > Wasn't aware of problems with -mcpu=ultrasparc (have
> > been using -mcpu=ultrasparc already in 2.96-RH quite extensively).
> 
> My understanding is that the problems with -mcpu=ultrasparc could only
> be solved with SUBREG BYTE patch, that went into 2.96-RH.

Only -m64 causes SFmode float registers to be smaller than word which is
what caused the problems, with -m32 -mcpu=ultrasparc it is the same as
with -m32 -mtune=ultrasparc.

	Jakub

Re: GCC3.0.4 : Solaris 2.6 build failure

[Alexandre Oliva]

On Feb 22, 2002, Jakub Jelinek <jakub@redhat.com> wrote:

> On Fri, Feb 22, 2002 at 06:46:23PM -0300, Alexandre Oliva wrote:
>> On Feb 22, 2002, Jakub Jelinek <jakub@redhat.com> wrote:
>> 
>> > -mcpu=ultrasparc is different from -m64.
>> 
>> What's your point?  -mcpu=ultrasparc has problems in 3.0 just the same.

> Wasn't aware of problems with -mcpu=ultrasparc (have
> been using -mcpu=ultrasparc already in 2.96-RH quite extensively).

My understanding is that the problems with -mcpu=ultrasparc could only
be solved with SUBREG BYTE patch, that went into 2.96-RH.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: GCC3.0.4 : Solaris 2.6 build failure

[Jakub Jelinek]

On Fri, Feb 22, 2002 at 06:46:23PM -0300, Alexandre Oliva wrote:
> On Feb 22, 2002, Jakub Jelinek <jakub@redhat.com> wrote:
> 
> > -mcpu=ultrasparc is different from -m64.
> 
> What's your point?  -mcpu=ultrasparc has problems in 3.0 just the same.

Wasn't aware of problems with -mcpu=ultrasparc (have
been using -mcpu=ultrasparc already in 2.96-RH quite extensively).

	Jakub

Re: GCC3.0.4 : Solaris 2.6 build failure

[Alexandre Oliva]

On Feb 22, 2002, Jakub Jelinek <jakub@redhat.com> wrote:

> -mcpu=ultrasparc is different from -m64.

What's your point?  -mcpu=ultrasparc has problems in 3.0 just the same.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: GCC3.0.4 : Solaris 2.6 build failure

[Jakub Jelinek]

On Fri, Feb 22, 2002 at 06:15:40PM -0300, Alexandre Oliva wrote:
> On Feb 22, 2002, "Mathieu Imrazene"<imrazene@nortelnetworks.com> wrote:
> 
> > --with-ld=/home/imrazene/bin/ld --with-cpu=ultrasparc
>                                   ^^^^^^^^^^^^^^^^^^^^^
> 
> This is not fully supported in GCC 3.0.  It will hopefully be in 3.1.
> Meanwhile, use -mtune=ultrasparc instead of -mcpu=ultrasparc, which
> will get you most of the benefit without running into the problems of
> the limited ultrasparc support in 3.0.

-mcpu=ultrasparc is different from -m64.

	Jakub

Re: GCC3.0.4 : Solaris 2.6 build failure

[Alexandre Oliva]

On Feb 22, 2002, "Mathieu Imrazene"<imrazene@nortelnetworks.com> wrote:

> --with-ld=/home/imrazene/bin/ld --with-cpu=ultrasparc
                                  ^^^^^^^^^^^^^^^^^^^^^

This is not fully supported in GCC 3.0.  It will hopefully be in 3.1.
Meanwhile, use -mtune=ultrasparc instead of -mcpu=ultrasparc, which
will get you most of the benefit without running into the problems of
the limited ultrasparc support in 3.0.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

GCC3.0.4 : Solaris 2.6 build failure

[Mathieu Imrazene]

/var/tmp/build_gcc/gcc/xgcc -B/var/tmp/build_gcc/gcc/
-B/home/imrazene/gcc-3.0.4/sparc-sun-solaris2.6/bin/
-B/home/imrazene/gcc-3.0.4/sparc-sun-solaris2.6/lib/ -isystem
/home/imrazene/gcc-3.0.4/sparc-sun-solaris2.6/include -DHAVE_CONFIG_H
-I. -I/var/tmp/gcc-3.0.4/libjava
-I./include -I/var/tmp/gcc-3.0.4/libjava -Iinclude
-I/var/tmp/gcc-3.0.4/libjava/include
-I/var/tmp/gcc-3.0.4/libjava/../boehm-gc -I./../boehm-gc
-DSOLARIS_THREADS=1
-D_SOLARIS_PTHREADS=1 -DSILENT=1 -DNO_SIGNALS=1 -DJAVA_FINALIZATION=1
-DGC_GCJ_SUPPORT=1 -I/var/tmp/gcc-3.0.4/libjava/libltdl
-I/var/tmp/gcc-3.0.4/libjava/libltdl
-I/var/tmp/gcc-3.0.4/libjava/.././libjava/../gcc
-I/var/tmp/gcc-3.0.4/libjava/../zlib
-I/var/tmp/gcc-3.0.4/libjava/../libffi/include -I../libffi/include -W
-Wall -g
-O2 -c /var/tmp/gcc-3.0.4/libjava/java/lang/k_tan.c  -fPIC -DPIC -o
java/lang/.libs/k_tan.o
/var/tmp/gcc-3.0.4/libjava/java/lang/k_tan.c: In function
`__kernel_tan':
/var/tmp/gcc-3.0.4/libjava/java/lang/k_tan.c:130: Insn does not satisfy
its constraints:
(insn 611 521 342 (set (reg:DI 34 %f2)
        (reg/v:DI 64 %f32 [245])) 58 {*movdi_insn_sp32} (nil)
    (nil))
/var/tmp/gcc-3.0.4/libjava/java/lang/k_tan.c:130: Internal compiler
error in reload_cse_simplify_operands, at reload1.c:8364
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.
gmake[2]: *** [java/lang/k_tan.lo] Error 1
gmake[2]: Leaving directory
`/var/tmp/build_gcc/sparc-sun-solaris2.6/libjava'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory
`/var/tmp/build_gcc/sparc-sun-solaris2.6/libjava'
gmake: *** [all-target-libjava] Error 2

config.status contains :
# This directory was configured as follows:
/var/tmp/gcc-3.0.4/configure
--with-gcc-version-trigger=/var/tmp/gcc-3.0.4/gcc/version.c
--host=sparc-sun-solaris2.6 --prefix=/home/imrazene/gcc-3.0.4
--with-gnu-as
--with-gnu-ld --with-as=/home/imrazene/bin/as
--with-ld=/home/imrazene/bin/ld --with-cpu=ultrasparc
--enable-threads=posix --enable-languages=c,c++,java --norecursion
# using "mh-frag"


--
Mathieu Imrazene

========================================================
Il ne faut pas confondre 'vitesse' et 'precipitation'...