The concern is that this is hiding the bug, and will prevent catching similar bugs in the future. Considering that it requires exotic build options to trigger, I'm not sure that it's worth it.
I don't understand, what bug is this hiding?
This patch addresses two bugs that I know of:
* gcc optimizes some on-stack variables to use SSE vectors, which must be 16-bit aligned; it then assumes that they are 16-bit aligned simply based on their frame offset and uses e.g. movaps to access them (WineHQ bug 55007);
* we use DECLSPEC_ALIGN to specify manually aligned variables on-stack; gcc assumes that since the stack is 16-bit aligned already, it only needs to make sure their frame offset is aligned, which is not the case (encountered in merge request 3504).
In both cases the most correct solution, as far as I can tell, is for gcc to be aware that the stack isn't 16-bit aligned. I don't see a more correct solution; am I missing something?
Also I don't see why you are doing this for the host compiler too.
I'm confused by this statement, because I didn't think I was.
If you mean MSVCRTFLAGS, my understanding was that MSVCRTFLAGS is the flags we use to compile old-style .dll.so's that link to msvcrt (which is all of them, now) in case we're compiling without MinGW. Assuming that's correct, I added this to MSVCRTFLAGS since it seemed correct; i.e. the issue is present there as well (and in fact will continue to be present even if the upstream bug is fixed). I know that compiling without MinGW presents unfixable problems in some cases, but it hasn't been formally deprecated or removed yet, so I assumed that maintaining it wouldn't be the wrong thing to do.