https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110776
Kewen Lin <linkw at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed| |2023-07-24 --- Comment #2 from Kewen Lin <linkw at gcc dot gnu.org> --- Thanks for reporting and sorry for the breakage. I'll have a look first. (In reply to Iain Sandoe from comment #0) > The ICE seems to be because rs6000_builtin_vectorization_cost () is called > with a request for a misaligned load (which we do not support), It > reproduces on a cross from x86_64. > > This is in compiling libgfortran generated code (so nothing Darwin-specific, > other than being an Altivec platform). Thanks for the information. > > A philosophical question; if a request is made for the cost of doing > something unsupported - should we not return "infinity" rather than ICEing? > > Presumably, the alternative is that the middle end needs to know that some > kinds of operation are not supported and therefore not to try and cost them > (speculation here; I have no knowledge of the relevant code). I think that's what's being adopted now, if the target doesn't support unaligned load, the middle-end should take it as dr_unaligned_unsupported (dr_alignment_support) and use VECT_MAX_COST, it's expected that there is no chance to query it with unaligned_load. Maybe some path was changed by the culprit commit.