Re: f77 correctness on Sparc

[Toon Moene <toon at moene dot indiv dot nluug dot nl>]

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)