[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file

["rguenth at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320

--- Comment #27 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Thomas Preud'homme from comment #23)
> (In reply to Eric Botcazou from comment #20)
> > 
> > > Maybe a better solution for sparc would be to add a switch for this pass and
> > > disable it by default on sparc. What do you think about that?
> > 
> > There is nothing special about SPARC, it's the same for every strict
> > alignment architecture supported by GCC and SLOW_UNALIGNED_ACCESS is a valid
> > predicate.
> 
> My point was two fold:
> 
> 1) Even if the pass does nothing for unaligned access on target where this
> is slow, a bunch of code is still executed to determine that the access is
> unaligned (in fact most of the pass is executed before the address of the
> access is known).
> 
> 2) For some unaligned access the rewrite might be interesting, like
> rewriting this:
> 
> tab[1] | (tab [2] << 8) | (tab[3] << 16) | (tab[4] << 24)
> 
> into this:
> 
> *((uint32_t *) &tab[1])
> 
> (considering tab[0] to be 4 byte aligned) which could end up doing one 32
> bit load at addresses &tab[0], one shift and one byte load at address
> &tab[4].

Yes, I think that the load may be written in non-optimal way and the expander
has a better chance to produce optimal code (considering insv availability).

I fear that if we install this workaround we'll never get at the actual
issue (which might be just PR61306?)