> -----Original Message----- > From: > avr-gcc-list-bounces+eric.weddington=atmel....@nongnu.org > [mailto:avr-gcc-list-bounces+eric.weddington=atmel....@nongnu. > org] On Behalf Of Paulo Marques > Sent: Wednesday, June 09, 2010 8:16 AM > To: Dale > Cc: avr-gcc-list@nongnu.org > Subject: Re: [avr-gcc-list] Stack use - possible bug > > Paulo Marques wrote: > > Dale wrote: > > > > The problem is that people running gcc on "big" machines > never notice > > this. The other crowd that noticed it already was the linux kernel > > people were the stack is limited to 4Kb. I'm trying to find > a similar > > thread that I remember reading on LKML, but my google-fu is > letting me > > down :( > > Found it: > > http://lkml.org/lkml/2008/8/26/197 >
I agree with Paulo in that people running on big machines won't notice this or even really care. I have to agree with Linus in that post on this: "Gcc inlining is a total and utter pile of shit. And _that_ is the problem. I seriously think we shouldn't allow gcc to inline anything at all unless we tell it to. That's how it used to work, and quite frankly, that's how it _should_ work." It's frustrating that GCC attempts to do any implicit inlining based on other criteria (marking a function static), or that the "inline" keyword is essentially soft (that it "may" inline it, but it "may not"), which then necessitates having (nonstandard) function attributes of "always_inline" and "noinline". All of this is based on heuristics that is probably not tuned correctly for the AVR. Typically if there are any heuristics in GCC for any feature, I can almost guarantee that they are not tuned correctly for the AVR. Ok, that's probably an overly-pessimistic statement, but hopefully one can understand the sentiment. Unfortunately this is also why I will essentially ignore the issue as stated in the original post. It's not a bug, it's probably a missed optimization that will probably not get fixed for a long time, and the issue is easily solved by being much more explicit to the compiler as to what should be inlined and what should not be inlined because the compiler is not psychic and it has no idea what the programmer is intending to do with the program. There, I said it. There is much bigger fish to fry when it comes to fixing things in the compiler. We're talking about applications for a deeply embedded 8-bit system. There will always be some level of weirdness, and a much greater burden is always placed on the software engineer to be aware of these cases due to extreme hardware limitations and the engineering tradeoffs that ensue. Eric _______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
