brook@ut-emx.UUCP (Brook Milligan) (03/20/90)
I am trying to install gcc (version 1.37.1) on a DS3100 (Ultrix 3.1)
and seem to be having a problem. When I compile the distribution
using the Dec/MIPS cc I get the following error messages. The
documentation suggests that the first is to be ignored and I'm sure
the third is irrevelant, but I am less sure of the second.
cc -I. -I. -I./config -c insn-emit.c
ccom: Warning: insn-emit.c, line 729: statement not reached
operand0 = emit_operand[0];
----------------------------^
ccom: Warning: insn-emit.c, line 749: zero or negative subscript
rtx emit_operand[0];
--------------------^
make hard-params
cp ./hard-params.c . > /dev/null 2>&1
*** Error code 1 (ignored)
Upon recompiling gcc with itself I cannot use the -g switch as
suggested since the following message results: cc1: Invalid option
`-g'. I assume this is related to the comment in the documentation
about "GNU CC cannot generate debugging information in the unusual
format used on the Mips." Without -g everything recompiles just fine
with gcc.
To test the results, I recompiled it with gcc a second time following
the instructions in the documentation. Upon comparing the resulting
files, however, I find differences between files. Differences arise
whether or not I use the -g option in the original compilation with
cc.
Does this mean that errors exist in my compiled version of gcc? I
would appreciate any suggestions you can make, especially it you have
successfully installed gcc on a DS3100. Thanks in advance.
--
====================================================================
Brook G. Milligan Internet: brook@emx.utexas.edu
Department of Botany Bitnet: bohk313@utaivc
University of Texas at Austin UUCP: ...!ut-emx!brook
Austin, Texas 78713 U.S.A. (512) 471-3530
====================================================================meissner@osf.org (Michael Meissner) (03/24/90)
In article <26423@ut-emx.UUCP> brook@ut-emx.UUCP (Brook Milligan) writes: | I am trying to install gcc (version 1.37.1) on a DS3100 (Ultrix 3.1) | and seem to be having a problem. When I compile the distribution | using the Dec/MIPS cc I get the following error messages. The | documentation suggests that the first is to be ignored and I'm sure | the third is irrevelant, but I am less sure of the second. | | cc -I. -I. -I./config -c insn-emit.c | ccom: Warning: insn-emit.c, line 729: statement not reached | operand0 = emit_operand[0]; | ----------------------------^ | ccom: Warning: insn-emit.c, line 749: zero or negative subscript | rtx emit_operand[0]; | --------------------^ | make hard-params | cp ./hard-params.c . > /dev/null 2>&1 | *** Error code 1 (ignored) The second error message is because of the 'probe' insn which tests if the stack is allocated when using __builtin_alloca. The problem is probe takes no arguments, but the gen* utilities don't have any special code to eliminate the decl if there were no arguments. In other words, ignore the error message. I've been meaning to redo probe to see if I can eliminate the error message, but it's low on my priority list. | Upon recompiling gcc with itself I cannot use the -g switch as | suggested since the following message results: cc1: Invalid option | `-g'. I assume this is related to the comment in the documentation | about "GNU CC cannot generate debugging information in the unusual | format used on the Mips." Without -g everything recompiles just fine | with gcc. I'm looking into -g support. I have lines working (which is somewhat trivial), but not local symbols (definiately not trivial). | To test the results, I recompiled it with gcc a second time following | the instructions in the documentation. Upon comparing the resulting | files, however, I find differences between files. Differences arise | whether or not I use the -g option in the original compilation with | cc. | | Does this mean that errors exist in my compiled version of gcc? I | would appreciate any suggestions you can make, especially it you have | successfully installed gcc on a DS3100. Thanks in advance. Each source file encountered is supposed to generate an appropriate FDR entry in the object file. The assembler blindly adds the filename the assembly language input as an FDR, even if there is a .file directive before any declarations. Since GCC constructs the temporary assembler name via mktemp, it means you get a different name each time. What I do is the following: (cmp -l cc1 stage2/cc1 | head -6; odump -f cc1) | less Find the first difference after bytes 4-7 (which are the timestamp). Convert that number to hex, and see if it's greater than the symptr, which is the start of the symbol table (where the FDR's live). I've come to the conclusion that the MIPS people did not consider that anybody would want to have high level languages generate assembly code, but rather they should produce the object file directly, since there are no hooks in the assembler to specify to eliminate the unneeded FDR, no way to create debug information, no way to set the language. Sigh.... -- Michael Meissner email: meissner@osf.org phone: 617-621-8861 Open Software Foundation, 11 Cambridge Center, Cambridge, MA Catproof is an oxymoron, Childproof is nearly so