This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: Problems with new architecture
- From: LLeweLLyn Reese <llewelly at lifesupport dot shutdown dot com>
- To: James Dessart <james at skwirl dot ca>
- Cc: gcc-help at gcc dot gnu dot org
- Date: 06 Mar 2003 21:26:00 -0800
- Subject: Re: Problems with new architecture
- References: <Pine.LNX.4.10.10303051141460.28362-100000@coatl.skwirl.ca>
- Reply-to: gcc-help at gcc dot gnu dot org
James Dessart <james at skwirl dot ca> writes:
> Hi, I'm busy setting up a new architecture for GCC, the m6809, running on
> the TRS-80 Color Computer series. It'll be a cross-compiler, and I'm
> basing it on gcc 3.1.1. However, despite it working on most files, it
> seems to choke at the end of long functions with 'unrecognizable insn'
> errors. One of these files works when I remove -O2 compilation, but
> despite my best efforts, the other will not compile.
>
> I know the first file, available at my site
> http://skwirl.ca/coco/gcc.html in libc-coco, named doprnt.c, worked for
> someone else running these config files under 2.95.3. I had to make
> modifications to have it compile under 3.1.1, but I'm not sure I've fixed
> everything up properly. The ChangeLogs are hard to go through, and it's
> almost impossible to find something unless you know specifically what it
> is you're looking for. I managed to fix a couple of problems this way.
>
> So, here's the unrecoverable error, it's from a file that comes from
> uip-0.6.0, a small TCP/IP stack:
>
> [james at loki:coco] % make uip.o
> gcc09 -I../uip -I../apps/httpd -I. -fno-inline -c -o uip.o
> ../uip/uip.c
> ../uip/uip.c: In function `uip_process':
> ../uip/uip.c:1023: unrecognizable insn:
> (insn 1898 1597 1896 (set (reg:QI 0 d)
> (subreg:QI (mem:HI (plus:HI (reg/f:HI 3 u)
> (const_int -13 [0xfffffff3])) [0 S2 A8]) 1)) -1 (nil)
> (nil))
>
> Now, I'm not sure what's wrong here... u is a stack register, not used by
> gcc, as far as I know, for passing parameters. Perhaps it's used for
> local storage, I'm not sure. Is it possible that this is as a result of
> having unsupported local storage in the function?
>
> Thanks for any help you can provide,
> James
I'm begining to think people with an in-depth knowledge of gcc's
source do not post here. I suggest you try gcc at gcc dot gnu dot org, which is
for the maintainers.