This is the mail archive of the crossgcc@cygnus.com mailing list for the crossgcc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Hi there. I've seen a few folks out there who are apparently interested in 68K targets; perhaps some of you have seen this... I'm running the b1.17 CDK package. I've managed to put together 68K cross compilers from its source that run in the cygwin32 environment (under NT 4), and under SunOS 4.2. Happily, both cross compilers are now generating identical 68K code. (We're trying to support development on both platforms.) However, we're tripping over some changes in the Cygnus version of GCC (or perhaps these are recent changes from FSF---not sure). In particular, the CDK compiler will not "re-use" stack space for arrays that are defined locally within code blocks. E.g.: .... mumble; mumble; if (some error) { char errbuf[256]; sprintf(errbuf, "message", ....); report_erorr(errbuf); goto fail; } .... mumble; mumble; if (some error) { char errbuf[256]; sprintf(errbuf, "message", ....); report_erorr(errbuf); goto fail; } .... Previous versions of GCC (at least up through 2.5.2 or so) use the same 256-byte piece of stack for the two "errbuf" arrays. The CDK 2.7.2 version of GCC allocates them separately. Thus, the code above consumes 512 bytes of stack with the CDK compiler, but only 256 with the earlier FSF compiler. This gets particularly bad if a procedure includes many blocks with local arrays. We're compiling for an embedded environment, so stack usage is an issue; in procedures that have many clauses similar to those above, we get stack overflows with the CDK compiler. I'd like to avoid re-coding the offending procedures in our own code base, so I'm trying to understand why the new compiler has a different strategy for managing these variables on the stack. I've been groping through the compiler sources, comparing the CDK to the older FSF versions. Not being the compiler guy, I'm more or less in the dark. File "function.c" looks like a good candidate; there are certainly many differences between the CDK version and the FSF version of this file, and this seems to be where the compiler is making decisions about where local variables are located... The question is this: does anyone know if this new behavior is intended or not? (Perhaps there is some reason it has to work this way for some newly supported architecture?) Would this be considered a bug? Am I on the right track looking at recent changes to "function.c?" Sorry for the long-winded-ness of this message.... -E- ------------------------------------------------------------ Eric Lighthart, Engineering Manager, Systech Corporation (619) 453-8970 x 255 -- voice (619) 453-0238 -- fax 10505 Sorrento Valley Road, San Diego, CA, 92121 -- USPS eric@systech.com -- e-mail ------------------------------------------------------------