Hello there, this is my 1st post. I have become responsible for a private port of GCC to a custom microprocessor. It is a relatively simple 32 bit risc with delay slots.
I have modified the gcc 3.4.4 port to work against gcc 4.4.3. This gives correct results against a set of gnat Ada acats tests, but only for a limited set of optimizations. An attempt to port to trunk results in an ICE when attempting to compile libgcc2 I am running binutils 2.20 and newlib 1.18.0, and building as a combined tree. I am running the autotools etc mentioned in the binutils README-maintainer mode and use --enable-maintaner-mode and have used autoupdate/autoreconf A closer look shows the code is in a infinite loop in dojump, ending in a segmentation fault. I am using a host/build x84_64 machine. Doing a binary chop on the libgcc2.c source shows it's the lines containing the call __umulsidi3 (line 566) that cause the problem to exhibit itself. I have a some questions 1) What's the best way of finding out if the faults are down to my backend code? 2) Are the behaviors seen above at least consistent with the immaturity of 4.4.3 and trunk? i.e. should I just keep trying latest trunk? 3) How do I find out if I have missed something needed to support __umulsidi3 (etc, similar items also crash) Posting decent fault reports would not seem to be an option, unless I could exhibit the same faults on a supported architecture.
