On Tue, Feb 2, 2016 at 4:29 AM, Jakub Jelinek <ja...@redhat.com> wrote: > On Tue, Feb 02, 2016 at 01:24:26PM +0100, Uros Bizjak wrote: >> On Tue, Feb 2, 2016 at 12:53 PM, Jakub Jelinek <ja...@redhat.com> wrote: >> >> >> The bottom line is ix86_minimum_alignment must return the correct >> >> number for DImode or you can just turn off STV. My suggestion is >> >> to use my patch. >> > >> > Uros, any preferences here? I mean, it is possible to use >> > e.g. the ix86_option_override_internal and have H.J's >> > ix86_minimum_alignment >> > change as a safety net, in the usual case for -mpreferred-stack-boundary=2 >> > we'll just disable TARGET_STV and ix86_minimum_alignment change won't do >> > anything, as TARGET_STV will be false, and if for whatever case it gets >> > through (target attribute, -mincoming-stack-boundary=, ...) >> > ix86_minimum_alignment will be there to ensure enough stack alignment. >> > Most of the smaller -mpreferred-stack-boundary= uses are -mno-sse anyway, >> > and that is something we don't want to affect. >> >> IMO, we should disable STV when -mpreferred-stack-boundary < 3, as STV >> is only an optimization. Perhaps we can also emit a "sorry" for >> explicit -mstv in case stack boundary requirement is not satisfied. >> *If* there is a need for -mstv with smaller stack boundary, we can >> revisit this decision for later gcc versions. >> >> I think disabling STV is less surprising option than increasing stack >> boundary behind the user's back. > > So, is http://gcc.gnu.org/ml/gcc-patches/2016-01/msg02129.html > ok for trunk then (alone or with additional sorry, incremental or not?)? > I believe it does just that.
This patch is WRONG. -- H.J.
