https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103271
--- Comment #7 from rguenther at suse dot de <rguenther at suse dot de> --- On Fri, 26 Nov 2021, wilson at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103271 > > Jim Wilson <wilson at gcc dot gnu.org> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |wilson at gcc dot gnu.org > > --- Comment #5 from Jim Wilson <wilson at gcc dot gnu.org> --- > SiFive doesn't support -mno-strict-align so I've never tested it. I doubt > that > it works correctly, i.e. I doubt that it optimizes as intended. I've > mentioned > this to other RVI members, but there hasn't been anyone other than SiFive > actively working on upstream gcc so I don't think anyone ever looked at it. > It > shouldn't give an ICE though. > > Looking at this, it appears to be another "if only we had a movti pattern" > issue. > > In expand_DEFERRED_INIT in internal-fn.c, in the reg_lhs == TRUE case, there > is > a test > && have_insn_for (SET, var_mode)) > which fails because var_mode is TImode and we don't have a movti pattern. The > code calls build_zero_cst which returns a constructor with an array type. We > then call expand_assignment which gets confused as it doesn't know the size of > the array it is copying. That seems to be the bug - in this path we shouldn't ever create an entity with VLA size since we do know the actual size. But it all is a bit awkward.
