> So you simply assume that exp_type is naturally aligned here. I think > you should test align < TYPE_ALIGN (TYPE_MAIN_VARIANT (exp_type)) here, > no?
No strong opinion, but the patch is only intended to mitigate the effects of the PR65310 one-liner, including on the 5 branch, so it's minimal. > And if you get enough supporters to apply this kind of workaround > I'd prefer it to be in build_aligned_type itself, basically > refusing to build over-aligned types. I pondered that but rejected it for the 5 branch. > And I'd rather make this controlled by an internal flag that backends should > consciously set (aka a target hook). I disagree, the onus is on the middle-end to fix its mess and the default should not be to generate wrong code in any case. > The above is simply a bit too ugly IMHO > and looks incomplete(?), cannot even the cummulative args machinery > end up with type-align specifics or are you sure those can only > be triggered from function_arg_boundary? I think that testing function_arg_boundary is a conservative criterion, but I admittedly didn't check every architecture. > Note the real issue is overaligned register types. Agreed, and IMO the middle-end should not create them out of nowhere. > At least it seems you have a testcase that reproduces the error > so you should be able to point to a specific pass doing the wreckage > and provide preprocessed source and a cross-compiler setup to > investigate. I'm just using Jeff's reduced testcase for MIPS. -- Eric Botcazou
