https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #54 from Douglas Mencken <dougmencken at gmail dot com> --- (In reply to Wilco from comment 51) > (In reply to Segher Boessenkool from comment 49) > > (In reply to Douglas Mencken from comment 46) > > > Yeah, PowerPC doesn’t have addressing via PC, thus it requires to do > > > tricks > > > like that > > > > No, we don't have to do such strange code. The usual way is to do a call > > to the next instruction, and then a mflr. No blrl needed. > > > > This _is_ an excuse to use that fun instruction though! > > That would kill the return stack though unless the hardware special cases a > call to next instruction as not being a call but providing the PC. Nope. bl does nothing to any memory pointed by any register, it just pust current pc+4 into lr, and then updates pc with its argument as relative offset. I saw the huge code with a lot of subroutines where stack wasn’t used at all (sure such functions are not reentrant), handling call chain by gprs 13 to 29, for depths less than 16 calls it is very possible Code like bl +8, mflr would just result in larger offsets to data in text. Anyway I don’t get an idea why it may be needed at all. Data in .data (read-only too), code in .text. Simple, easy and nice (In reply to Segher Boessenkool from comment 50) > The generic code rounded up the allocation size twice, and that isn't needed. (In reply to Wilco from comment 48) > 16 is correct - an alloca of 16 should allocate 16 bytes, not 32. If the > size were incorrect it would fail on all targets, and not only when > STACK_DYNAMIC_OFFSET is not correctly aligned. What happens is that the > extra padding due to adding 22 rather than 15 helps to hide the bug. Okay, I got it. 22 (32) is too much, 15 (16) is nice > The problem has been solved for other targets before; a patch for Darwin is > at https://gcc.gnu.org/ml/gcc-testresults/2017-01/msg02971.html , patch 0001. It does worth trying #undef STARTING_FRAME_OFFSET #define STARTING_FRAME_OFFSET \ (FRAME_GROWS_DOWNWARD \ ? 0 \ - : (RS6000_ALIGN (crtl->outgoing_args_size, 16) \ - + RS6000_SAVE_AREA)) + : (cfun->calls_alloca \ + ? RS6000_ALIGN (crtl->outgoing_args_size + RS6000_SAVE_AREA, 16) \ + : (RS6000_ALIGN (crtl->outgoing_args_size, 16) + RS6000_SAVE_AREA))) Meanwhile, what was the problem to merge these patches a year ago? My previous pr84113 was fixed by 2nd patch there, yet the 1st
