https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119457
--- Comment #2 from Simon Sobisch <simonsobisch at gnu dot org> --- I tend to disagree as the referenced one is explicit about MOVE (and of course using matching type assignments and functions, possibly split like for strings using memcpy+memset for space is most reasonable because COBOL programs have huge amounts of those), while this is for STRING. This _specific_ STRING can internally be handled as MOVE (because type and length for source and dest are identical), which may be an optimization that can be done before GIMPLE is involved (a follow-up optimisation would be finding if this is also true for one or multiple fixed-length sources that can be handled as multiple MOVE with ref-mod to dest). If the parser internally transfers them, then those will be optimized whenever alphanumeric MOVEs are optimized (possibly Bob's task). The "internal split for fixed-size source to MOVEs" may be branched out to a separate issue (which also doesn't need to be done now [I guess I still haven't implemented that for GC :-)]. Again to this issue: that was about how STRING is handled - there are a lot of malloc/free which may be an easy replace with local storage instead. I suggest to keep this open up for this specific part (and possibly handle that "a bit earlier").
