On Tue, 2020-06-09 at 17:26 +0200, Jakub Jelinek wrote: > On Tue, Jun 09, 2020 at 09:18:25AM -0600, Jeff Law wrote: > > On Tue, 2020-06-09 at 16:59 +0200, Jakub Jelinek wrote: > > > On Tue, Jun 09, 2020 at 08:54:47AM -0600, Jeff Law via Gcc-patches wrote: > > > > > While technically OK the issue is that it does not solve the x86 issue > > > > > which with incoming stack alignment < 8 bytes does not perform > > > > > dynamic re-alignment to align 'long long' variables appropriately. > > > > > Currently the x86 backend thinks it can fixup by lowering alignment > > > > > via LOCAL_DECL_ALIGNMENT but this is a latent wrong-code issue > > > > > because the larger alignment is present in the IL for a long > > > > > (previously > > > > > RTL expansion, now adjust-aligment) time and your patch makes that > > > > > wrong info last forever (or alternatively cause dynamic stack > > > > > alignment > > > > > which we do _not_ want to perform here). > > > > I've never looked at the dynamic realignment stuff -- is there a good > > > > reason why > > > > we don't dynamically realign when we've got a local with a requested > > > > alignment? > > > > Isn't that a huge oversight in the whole concept of dynamic realignment? > > > > > > It is quite expensive and long long/double uses are pervasive, so we don't > > > want to realign just because of that. If we do dynamic realignment for > > > other reasons, there is no reason not to align the long long/double > > Right, but if there's an explicit alignment from the user, don't we need to > > honor > > that? > > Sure. Do we ignore that? For user alignment we have DECL_USER_ALIGN bit... I suspect that's what's going on with the kernel build failure.
Jeff
