On Thu, 17 Jan 2008 14:22:33 -0500 Tony Wetmore <tony.wetmore@xxxxxxxxxxxx> wrote: > Alejandro Pulver wrote: > > As it fails with -O1 and all -fno-*, I tried parameters like > > max-pending-list-length=1 without success. > > > > Do you know about an option or something that could help in this case? > > Alejandro, > Hello. Thank you for your reply. > I may have missed this earlier, but are the source files causing GCC to > crash particularly large? Perhaps the problem could be avoided by > splitting the code into more (smaller) files, so that GCC is compiling > less of the code at once. > Yes, the source is 4MB, consisting of one function with a jump table and ~8000 labels (with little code on each), to simulate each machine instruction. GCC doesn't crash, just outputs something like this and exits: cc1: out of memory allocating 4072 bytes after a total of 1073158016 bytes > If I understand what you are doing, this code is program-generated, so > you would have to modify the generator program to create multiple files. > But you might be able to test this by manually splitting one file > yourself. > > Good luck! > I really don't know if I could split it, as it's inside the same function (all the ~8000 labels with very short code), and it uses computed gotos (like the ones generated by a switch statement, with a "jump table" so there is no comparison of the cases), so this may not work in different files (at least 2 jump tables are used instead of 1, using a dictionary-like setup, see below). For example, I've seen a Motorola 68K emulator (included in Generator, a SEGA Genesis emulator) generating 16 C files, each one containing the code for instructions starting with 0 to F (in hexadecimal). It uses switch and case statements for the jump table (not computed gotos), which is more or less the same in practice. I haven't fully read the source, but it seems that has 2 jump tables to avoid this problem. I'll see if they can be split, but I just was surprised when I tried with GCC 4.x and actually compiled it (without optimizations). So I thought there could be a way to optimize it by telling GCC specific information about how to do it (as optimizing each block independently should work fine). Thanks and Best Regards, Ale
Attachment:
signature.asc
Description: PGP signature
