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.
