aglew@urbsdc.Urbana.Gould.COM (04/28/88)
Thanks be to the folks who ported GCC 1.18 to the 3B1; can anyone help me with the trivial problems I'm having with 1.20? GCC 1.20 would not compile, because the large number of #defines overflowed AT&T's cpp. So, I compiled GCC's CPP, by ifdeffing out a lot of unecessary headers, and used it to compile (had to null out the __STDC__ test in the binary, so that function prototypes were not compiled in when using GCC's cpp with AT&T's cc.) Am using tm-3b1.h -> tm.h, conf-hp9k320.h -> config.h (just to get the bcopy's, etc.) and m68k-md -> md (I may have got the names slightly wrong, but no problem). Had to define SGS_3B1 when compiling this way. Corrected a typo in tm-3b1.h -- the "short 0" after "swbeg" was missing a newline. Current problem is also with swbeg switch related code -- without SHS_3B1 it emits .set LI114,.+2, which is illegal -- the 3B! uses ~ instead of . for current location, but I haven't been able to get that to work. With SGS_3B1 LI114 is emmitted explicitly, but the expression L114-LI114 is evaluated on a (%pc,%dn) addressing mode, which the assembler cries about. Before I go any further, have I made a wrong turn somewhere in setting up the environment for compiling GCC 1.20 on a 3B1? aglew@gould.com
alex@umbc3.UMD.EDU (Alex S. Crain) (04/29/88)
In article <31200020@urbsdc> aglew@urbsdc.Urbana.Gould.COM writes: > >Thanks be to the folks who ported GCC 1.18 to the 3B1; >can anyone help me with the trivial problems I'm having with >1.20? [various bugs deleted] > >Before I go any further, have I made a wrong turn somewhere in setting >up the environment for compiling GCC 1.20 on a 3B1? I did the port of 1.18, and set up the changes in for 1.20 and mailed them off to The FSF. I have not seen 1.20 yet, although I have heard that it does not compile. To be honest, I would be surprised if it did. Part of what I had to do was to bring the unixpc version in line with the hp version that was being developed at mit. The bugs described here are what I expected, typo's and hp behaviour that sneaked in. For example, the unixpc assembler takes ~ as opposed to ., but will not except ~+2 in any form. The hp version likes to use .+2, and as yet, there is no global unixpc alternative, so when a .+2 sneaks into the distribution, it has to be fixed in the unixpc code. BTW: The fix for this is to change "set LIxx,.+2" to simply "LIxx:". The former leaves the LIxx out of the symbol table, the latter does not, oh well. The problems with 1.20 should be minor. I will be making a full bug report up for mit so that these bugs can be fixed (others surely remain), but I won't be able to do that for at least 3 weeks, and maybe not till 1.21. The output code differences between 1.18 and 1.20 are small, so the simple solution is, use 1.18 for a few versions, and upgrade from a full dist at 1.23 or so, in say, August. The hp code should be stable by then, and the unixpc stuff should work pretty well. > >aglew@gould.com -- :alex. nerwin!alex@umbc3.umd.edu alex@umbc3.umd.edu