https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61078
--- Comment #3 from Andreas Krebbel <krebbel at gcc dot gnu.org> --- (In reply to jgreenhalgh from comment #1) > I'm happy to take a look at this, but I have no access to an s390 ESA mode > environment, so will struggle to make much progress. > > If it is the case that s390 relies on PUSH_ARGS_REVERSED == 0, then r209897 > will need to be reverted as it is clearly erroneous. s390 indeed uses PUSH_ARGS_REVERSED == 0 but the code correctness does not actually depend on this since every argument has a dedicated slot either in a register or a stack slot. In the case described above your patch just revealed a backend problem: https://gcc.gnu.org/ml/gcc-patches/2014-08/msg02313.html On the other hand I think the asm code looks more obvious on S/390 with PUSH_ARGS_REVERSED=0 since the operands then are assigned in the expected order. There is simply no reason for doing it the other way around on S/390. While I don't have a strong opinion about this I would prefer to go back to the old behavior. Also there seem to be other code (gimplify.c) which still depends on PUSH_ARGS_REVERSED?! I'm also not sure about the performance impact of this. On S/390 the generated code changes a lot with your patch. > > Otherwise, any reduced testcase you can find where we do the wrong thing > preparing stack arguments will be of great help hunting the bug.
