[PATCH] Avoid bugs like PR68273 to trigger

Eric Botcazou ebotcazou@adacore.com
Fri Feb 19 08:29:00 GMT 2016

> 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

More information about the Gcc-patches mailing list