site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Thanks, Ryan _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... A couple weeks ago I asked about a machine-check panic I was getting. As it turns out, my suspicions were right about stack corruption. I disassembled a function in our kext and saw that for some reason, GCC's function prologue was allocating around 1660 bytes of stack (in release, debug was slightly better at 1140 bytes). On other platforms compiled with GCC (FreeBSD and many different Linux distros) the stack usage is near 110 bytes, but for some reason gcc on Mac OS X is allocating almost 4K. We are currently using -O3 because the code is pretty compute-bound, and on other platforms -O3 has a nice 5% boost compared to -O2. But changing it to -O2 doesn't even help, we have to go all the way to -O1 to get a usable stack of 400 bytes (still 4x larger than our Linux driver). The code is vanilla C++ without anything fancy—no virtual functions even. There are no warnings about temporarys being used, so I have no clue what is causing the stack usage. It's a huge function with a lot ofswitch statements and for loops, but not a lot of function calls, mostly just computes on arrays of data. My best guess is that GCC is trying to optimize the intermediate operations and temporary results by placing them on the stack. Anybody have ideas on how to show where GCC is allocating things in the frame, and how to reduce the stack usage? It's hard to distill this to a single issue because the function is so large, but I am tempted to file a bug since GCC 4 optimizes things quite nicely on other platforms. This email sent to site_archiver@lists.apple.com