f77 correctness on Sparc

f77 correctness on Sparc

[Brad Lucier]

Toon:

There are a large number of test failures and untested test cases in the
current CVS f77 when compiled with -m64 -mcpu=ultrasparc on an Ultra 10
running Solaris 2.8, see

http://gcc.gnu.org/ml/gcc-testresults/2000-09/msg00114.html

Is this a general 64bit problem, or are there specific problems with
the sparc port?

Brad Lucier

Re: f77 correctness on Sparc

[Jakub Jelinek]

On Wed, Sep 13, 2000 at 03:26:49PM -0500, Brad Lucier wrote:
> Toon:
> 
> There are a large number of test failures and untested test cases in the
> current CVS f77 when compiled with -m64 -mcpu=ultrasparc on an Ultra 10
> running Solaris 2.8, see
> 
> http://gcc.gnu.org/ml/gcc-testresults/2000-09/msg00114.html
> 
> Is this a general 64bit problem, or are there specific problems with
> the sparc port?

If you want to use -m64 on sparc for anything math related, you need
SUBREG_BYTE patches, which are not yet integrated into CVS.

	Jakub

Re: f77 correctness on Sparc

[Toon Moene]

Brad Lucier wrote:

> There are a large number of test failures and untested test cases in the
> current CVS f77 when compiled with -m64 -mcpu=ultrasparc on an Ultra 10
> running Solaris 2.8, see
> 
> http://gcc.gnu.org/ml/gcc-testresults/2000-09/msg00114.html
> 
> Is this a general 64bit problem, or are there specific problems with
> the sparc port?

I wasn't aware of this - I haven't run an alpha test suite for days. 
I'll try that tomorrow (it's bed time over here now ;-)

Note that most of your failures are compilation errors - perhaps looking
into the logs will give a clue.

Thanks,

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
GNU Fortran 95: http://g95.sourceforge.net/ (under construction)

Re: f77 correctness on Sparc

[Brad Lucier]

Toon Moene wrote:

> Note that most of your failures are compilation errors - perhaps looking
> into the logs will give a clue.

OK, I finally reran the tests and looked at the log.  There are several types of
problems, and I'll give some examples of each.  This was configured on
solaris2.8 with --enable-checking=no, and tested with '-mcpu=ultrasparc -m64".

I don't understand this type of problem:

<problem>
spawn /export/home/sources/egcs/solaris-2.8/gcc/g77 -B/export/home/sources/egcs/solaris-2.8/gcc/ /export/home/sources/egcs/gcc/testsuite/g77.f-torture/compile/19990826-3.f -w -O2 -mcpu=ultrasparc -m64 -L/export/home/sources/egcs/solaris-2.8/sparc-sun-solaris2.8/libf2c -c -o /export/home/sources/egcs/solaris-2.8/gcc/testsuite/19990826-3.o 
/export/home/sources/egcs/gcc/testsuite/g77.f-torture/compile/19990826-3.f: In subroutine `pcapop':
/export/home/sources/egcs/gcc/testsuite/g77.f-torture/compile/19990826-3.f:319: Insn does not satisfy its constraints:
(insn 6248 6245 1735 (set (reg:SF 64 %f32)
        (mem:SF (plus:DI (reg:DI 30 %fp)
                (const_int 2031 [0x7ef])) 0)) 84 {*movsf_insn_novis} (nil)
    (nil))
/export/home/sources/egcs/gcc/testsuite/g77.f-torture/compile/19990826-3.f:319: Internal compiler error in reload_cse_simplify_operands, at reload1.c:8098
   Please submit a full bug report.
   See <URL: http://www.gnu.org/software/gcc/bugs.html > for instructions.
</problem>

There is one other type of internal error:

<problem>
spawn /export/home/sources/egcs/solaris-2.8/gcc/g77 -B/export/home/sources/egcs/solaris-2.8/gcc/ /export/home/sources/egcs/gcc/testsuite/g77.f-torture/execute/19990826-2.f -w -O1 -mcpu=ultrasparc -m64 -L/export/home/sources/egcs/solaris-2.8/sparc-sun-solaris2.8/libf2c -lm -o /export/home/sources/egcs/solaris-2.8/gcc/testsuite/19990826-2.x 
/export/home/sources/egcs/gcc/testsuite/g77.f-torture/execute/19990826-2.f: In program `labug3':
/export/home/sources/egcs/gcc/testsuite/g77.f-torture/execute/19990826-2.f:28: Internal compiler error in emit_group_load, at expr.c:1988
   Please submit a full bug report.
   See <URL: http://www.gnu.org/software/gcc/bugs.html > for instructions.
compiler exited with status 1
</problem>

The vast majority of the extra problems are similar; did something not get built
or multilib'ed?:

<problem>
spawn /export/home/sources/egcs/solaris-2.8/gcc/g77 -B/export/home/sources/egcs/solaris-2.8/gcc/ /export/home/sources/egcs/gcc/testsuite/g77.f-torture/execute/19990826-0.f -w -Os -mcpu=ultrasparc -m64 -L/export/home/sources/egcs/solaris-2.8/sparc-sun-solaris2.8/libf2c -lm -o /export/home/sources/egcs/solaris-2.8/gcc/testsuite/19990826-0.x 
Undefined			first referenced
 symbol  			    in file
s_stop                              /tmp/ccOagkee.o
G77_abort_0                         /tmp/ccOagkee.o
main                                /export/home/sources/egcs/solaris-2.8/gcc/sparcv9/crt1.o
ld: fatal: Symbol referencing errors. No output written to /export/home/sources/egcs/solaris-2.8/gcc/testsuite/19990826-0.x
collect2: ld returned 1 exit status
compiler exited with status 1
</problem>

And another:

<problem>
spawn /export/home/sources/egcs/solaris-2.8/gcc/g77 -B/export/home/sources/egcs/solaris-2.8/gcc/ /export/home/sources/egcs/gcc/testsuite/g77.f-torture/execute/20000503-1.f -w -O0 -mcpu=ultrasparc -m64 -L/export/home/sources/egcs/solaris-2.8/sparc-sun-solaris2.8/libf2c -lm -o /export/home/sources/egcs/solaris-2.8/gcc/testsuite/20000503-1.x 
Undefined			first referenced
 symbol  			    in file
s_wsle                              /tmp/ccA8Mw00.o
s_stop                              /tmp/ccA8Mw00.o
do_lio                              /tmp/ccA8Mw00.o
G77_abort_0                         /tmp/ccA8Mw00.o
main                                /export/home/sources/egcs/solaris-2.8/gcc/sparcv9/crt1.o
e_wsle                              /tmp/ccA8Mw00.o
ld: fatal: Symbol referencing errors. No output written to /export/home/sources/egcs/solaris-2.8/gcc/testsuite/20000503-1.x
collect2: ld returned 1 exit status
compiler exited with status 1
</problem>

and, quite often:

<problem>
spawn /export/home/sources/egcs/solaris-2.8/gcc/g77 -B/export/home/sources/egcs/solaris-2.8/gcc/ /export/home/sources/egcs/gcc/testsuite/g77.f-torture/execute/19990325-1.f -w -O1 -mcpu=ultrasparc -m64 -L/export/home/sources/egcs/solaris-2.8/sparc-sun-solaris2.8/libf2c -lm -o /export/home/sources/egcs/solaris-2.8/gcc/testsuite/19990325-1.x 
Undefined			first referenced
 symbol  			    in file
z_abs                               /tmp/cct623kM.o
z_sqrt                              /tmp/cct623kM.o
s_stop                              /tmp/cct623kM.o
z_exp                               /tmp/cct623kM.o
z_sin                               /tmp/cct623kM.o
z_cos                               /tmp/cct623kM.o
pow_zz                              /tmp/cct623kM.o
G77_abort_0                         /tmp/cct623kM.o
main                                /export/home/sources/egcs/solaris-2.8/gcc/sparcv9/crt1.o
z_log                               /tmp/cct623kM.o
ld: fatal: Symbol referencing errors. No output written to /export/home/sources/egcs/solaris-2.8/gcc/testsuite/19990325-1.x
collect2: ld returned 1 exit status
compiler exited with status 1
</problem>

The complete log is available at

http://www.math.purdue.edu/~lucier/g77.log.gz

Brad Lucier

Re: f77 correctness on Sparc

[Toon Moene]

Brad Lucier wrote:
> 
> Toon Moene wrote:
> 
> > Note that most of your failures are compilation errors - perhaps looking
> > into the logs will give a clue.

> I don't understand this type of problem:

> spawn /export/home/sources/egcs/solaris-2.8/gcc/g77 -B/export/home/sources/egcs/solaris-2.8/gcc/ /export/home/sources/egcs/gcc/testsuite/g77.f-torture/compile/19990826-3.f -w -O2 -mcpu=ultrasparc -m64 -L/export/home/sources/egcs/solaris-2.8/sparc-sun-solaris2.8/libf2c -c -o /export/home/sources/egcs/solaris-2.8/gcc/testsuite/19990826-3.o
> /export/home/sources/egcs/gcc/testsuite/g77.f-torture/compile/19990826-3.f: In subroutine `pcapop':
> /export/home/sources/egcs/gcc/testsuite/g77.f-torture/compile/19990826-3.f:319: Insn does not satisfy its constraints:
> (insn 6248 6245 1735 (set (reg:SF 64 %f32)
>         (mem:SF (plus:DI (reg:DI 30 %fp)
>                 (const_int 2031 [0x7ef])) 0)) 84 {*movsf_insn_novis} (nil)
>     (nil))
> /export/home/sources/egcs/gcc/testsuite/g77.f-torture/compile/19990826-3.f:319: Internal compiler error in reload_cse_simplify_operands, at reload1.c:8098
>    Please submit a full bug report.
>    See <URL: http://www.gnu.org/software/gcc/bugs.html > for instructions.

Well, I won't say I *understand* it, but the error message is
"self-explaining": One part of the backend generated a certain type of
insn that it thought the Sparc port promised to understand and then
later another part of the backend detected that the Sparc port didn't
like this insn at all.  Normally due to some sloppiness in the .md file.

This has nothing to do with Fortran or the Fortran Frontend.  Given
enough ingenuity someone could probably write a C, C++, Pascal or Ada
test case that caused the same problem.

> There is one other type of internal error:

> spawn /export/home/sources/egcs/solaris-2.8/gcc/g77 -B/export/home/sources/egcs/solaris-2.8/gcc/ /export/home/sources/egcs/gcc/testsuite/g77.f-torture/execute/19990826-2.f -w -O1 -mcpu=ultrasparc -m64 -L/export/home/sources/egcs/solaris-2.8/sparc-sun-solaris2.8/libf2c -lm -o /export/home/sources/egcs/solaris-2.8/gcc/testsuite/19990826-2.x
> /export/home/sources/egcs/gcc/testsuite/g77.f-torture/execute/19990826-2.f: In program `labug3':
> /export/home/sources/egcs/gcc/testsuite/g77.f-torture/execute/19990826-2.f:28: Internal compiler error in emit_group_load, at expr.c:1988
>    Please submit a full bug report.
>    See <URL: http://www.gnu.org/software/gcc/bugs.html > for instructions.
> compiler exited with status 1

Sounds like a problem in reload, although it also seems to be possible
one could stimulate such errors with sloppiness in the .md file.

> </problem>
> 
> The vast majority of the extra problems are similar; did something not get built
> or multilib'ed?:

> spawn /export/home/sources/egcs/solaris-2.8/gcc/g77 -B/export/home/sources/egcs/solaris-2.8/gcc/ /export/home/sources/egcs/gcc/testsuite/g77.f-torture/execute/19990826-0.f -w -Os -mcpu=ultrasparc -m64 -L/export/home/sources/egcs/solaris-2.8/sparc-sun-solaris2.8/libf2c -lm -o /export/home/sources/egcs/solaris-2.8/gcc/testsuite/19990826-0.x
> Undefined                       first referenced
>  symbol                             in file
> s_stop                              /tmp/ccOagkee.o
> G77_abort_0                         /tmp/ccOagkee.o
> main                                

These are symptoms that libf2c wasn't found at the right moment in the
right place (during linking).  I.e., even if the compiler proper didn't
run into any problem at all, still the code couldn't be executed because
the link failed.  Unfortunately, this looks sufficiently different from
link command lines on my i686-pc-linux-gnu that I can't say what the
error is.

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
GNU Fortran 95: http://g95.sourceforge.net/ (under construction)

Re: f77 correctness on Sparc

[Brad Lucier]

> Brad Lucier wrote:
> 
> > There are a large number of test failures and untested test cases in the
> > current CVS f77 when compiled with -m64 -mcpu=ultrasparc on an Ultra 10
> > running Solaris 2.8, see
> > 
> > http://gcc.gnu.org/ml/gcc-testresults/2000-09/msg00114.html
> > 
> > Is this a general 64bit problem, or are there specific problems with
> > the sparc port?
> 
> I wasn't aware of this - I haven't run an alpha test suite for days. 
> I'll try that tomorrow (it's bed time over here now ;-)
> 

I have noticed no problems with the alpha port (usually all f77 tests pass).

Brad

Re: f77 correctness on Sparc

[Brad Lucier]

Toon Moene wrote:

> > The vast majority of the extra problems are similar; did something not get built
> > or multilib'ed?:
> 
> > spawn /export/home/sources/egcs/solaris-2.8/gcc/g77 -B/export/home/sources/egcs/solaris-2.8/gcc/ /export/home/sources/egcs/gcc/testsuite/g77.f-torture/execute/19990826-0.f -w -Os -mcpu=ultrasparc -m64 -L/export/home/sources/egcs/solaris-2.8/sparc-sun-solaris2.8/libf2c -lm -o /export/home/sources/egcs/solaris-2.8/gcc/testsuite/19990826-0.x
> > Undefined                       first referenced
> >  symbol                             in file
> > s_stop                              /tmp/ccOagkee.o
> > G77_abort_0                         /tmp/ccOagkee.o
> > main                                
> 
> These are symptoms that libf2c wasn't found at the right moment in the
> right place (during linking).  I.e., even if the compiler proper didn't
> run into any problem at all, still the code couldn't be executed because
> the link failed.  Unfortunately, this looks sufficiently different from
> link command lines on my i686-pc-linux-gnu that I can't say what the
> error is.

I looked through the build log (which was a bit confused, because I
did a parallel make), and found

Adding multilib support to Makefile in ../../../libf2c
multidirs=sparcv9
with_multisubdir=
Running configure in multilib subdirs sparcv9
pwd: /export/home/sources/egcs/solaris-2.8/sparc-sun-solaris2.8/libf2c
Running configure in multilib subdir sparcv9

which was the same for the other libraries (libchill, etc.).  Now, things
are compiled in the sparcv9 subdirectory with, e.g.,

/export/home/sources/egcs/solaris-2.8/gcc/xgcc -B/export/home/sources/egcs/solaris-2.8/gcc/ -B/pkgs/gcc-2.96/sparc-sun-solaris2.8/bin/ -B/pkgs/gcc-2.96/sparc-sun-solaris2.8/lib/ -isystem /pkgs/gcc-2.96/sparc-sun-solaris2.8/include -c -DSkip_f2c_Undefs -DAllow_TYQUAD -I. -I../../../../../libf2c/libI77 -I.. -I../../../../../libf2c/libI77/..  -DSTDC_HEADERS=1 -D_POSIX_SOURCE=1 -DHAVE_TEMPNAM=1 -DNON_ANSI_RW_MODES=1 -DNO_EOF_CHAR_CHECK=1 -DSkip_f2c_Undefs=1  -g -O2  -m64 ../../../../../libf2c/libI77/ftell_.c

which is, to me, a bit strange, unless -m64 implies -mcpu=sparcv9.  And,
shouldn't there be two versions of the library, one 32-bit binaries on
sparcv9 (i.e., "-mcpu=sparcv9 -m32") and 64-bit binaries on sparcv9
("-mcpu=sparcv9 -m64")?  FWIW, the other libraries are compiled with
similar options:

make[4]: Entering directory `/export/home/sources/egcs/solaris-2.8/sparc-sun-solaris2.8/sparcv9/libchill'
/export/home/sources/egcs/solaris-2.8/gcc/xgcc -B/export/home/sources/egcs/solaris-2.8/gcc/ -B/pkgs/gcc-2.96/sparc-sun-solaris2.8/bin/ -B/pkgs/gcc-2.96/sparc-sun-solaris2.8/lib/ -isystem /pkgs/gcc-2.96/sparc-sun-solaris2.8/include -c -I. -I../../../../libchill   -g -O2  -m64  ../../../../libchill/chillrt0.c

etc.

Brad Lucier