https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78468
Dominik Vogt <vogt at linux dot vnet.ibm.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |vogt at linux dot vnet.ibm.com --- Comment #22 from Dominik Vogt <vogt at linux dot vnet.ibm.com> --- > But these back-ends were not broken before your patch! It's your patch that > broke the interface between the middle-end and the back-end without notice. I disagree with this statement and with marking this bug report as being middleend related. The patch has not changed the interface between the two -ends but simply _uses_ the interface. -- The facts about the situation, as far as I understand, are: * The middleend promises that VIRTUAL_STACK_DYNMAIC_REGNUM has at least STACK_BOUNDARY alignment (emit-rtl.c:init_emit()). * The 32 bit Aix backend used to break this promise but has already been changed to honour it. * The 32 bit Sparc backend breaks this promise. * Apparently some other backends don't (Power, Aix 64 bit, s390, s390x, x86, x86_64), yet other backends may or may not break the promise. * Thus, the middleend and the backends that do not keep this promise (Sparc, Aix until recently, maybe others) disagree on the interface between backend and middleend. * Any user of REGNO_POINTER_ALIGN (VIRTUAL_STACK_DYNMAIC_REGNUM) may generate bogus results for targets that break the promise. Grepping through the sources I didn't find any other user (but there may be still some that cannot be found using simple "grep"s). * The interface mismatch is impossible to fix without touching the backends with non-STACK_BOUNDARY alignment of VIRTUAL_STACK_DYNMAIC_REGNUM. (Either these backends need to be changed to keep the promise or at least tell the middleend that they don't.) * The interface mismatch is virtually impossible to fix if every change that tries to fix it is reverted because on some target "it used to work before the patch". * The discussed patch introduces a new use of REGNO_POINTER_ALIGN (VIRTUAL_STACK_DYNMAIC_REGNUM) and therefore leads to bad results on targets that don't keep the promise. * The discussed patch _trusts_ REGNO_POINTER_ALIGN (VIRTUAL_STACK_DYNMAIC_REGNUM) and wouldn't lead to faulty code if that value were correct (i.e. if the alignment was set to 4 on Sparc instead of 8). (Note: Setting the correct pointer alignment on such targets would fix the bad code generation but not the waste of stack space.) * As far as it is known, (patched) code generation on targets that keep the promise is fine. * Backing out the patch in favour of not having to change the Sparc backend (and potentially others) not only wastes "some bytes" on Sparc but on every target. (Although, Sparc wastes more stack space than other targets, because of Sparc's peculiar guaranteed "unalignment".) * Backing out the patch won't fix the disagreement of the middleend and the Sparc backend about their interface. * Any other existing and future use of REGNO_POINTER_ALIGN (VIRTUAL_STACK_DYNMAIC_REGNUM) makes or will also make bogus assumptions, with unforeseeable consequences, unless the mismatch in the interface is fixed in some way. Related to the former over-allocation of dynamic stack memory: * Off-by-one array accesses to dynamic stack memory in user code often go unnoticed when Gcc is used as the compiler while other compilers will probably not have this kind bug and generate failing assembly code right away. * The patch already helped to identify coding bugs in several Gcc internal libraries, and Glibc. * It can be assumed with near certainty that the patch will trigger off-by-one bugs in applications compiled with Gcc, and that Gcc bug reports will be created with "Gcc-7 must be broken because it worked with Gcc-6". -- I'm certainly willing to help fixing any interface mismatch, the Sparc backend, any other backend with similar problems or identifying library or user code bugs that are triggered by the fixed middleend.