[Bug target/42947] multilib and startup files paths differ on sh4 with -m4 and without -m4 where -m4 is default multilib

[slyfox at inbox dot ru]

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

--- Comment #5 from Sergei Trofimovich <slyfox at inbox dot ru> ---
I have looked at it a bit and I think the bug here is in interaction between
    MULTILIB_DEFAULTS
and
    SYSROOT_SUFFIX_SPEC

AFAIU normally gcc ignores spec overrides for MULTILIB_DEFAULTS.

In our case values are:
    // from sh/sh.h expansion
    #define MULTILIB_DEFAULTS { "ml", "m4" }

    // from autogenerated multilib.h
    static const char *const multilib_raw[] = {
    ". !m4;",
    "m4 m4;",
    NULL
    };

    // from autogenerated sysroot-suffix.h
    #define SYSROOT_SUFFIX_SPEC "" \
    "%{m4:/m4;" \
    ":}"

Note even when we pass option -m4 we never append 'm4' suffix in library search
path (because it's a MULTILIB_DEFAULTS).

Looks like sh is one of 2 rare targets that touch t-sysroot-suffix:

sh-*-elf* | sh[12346l]*-*-elf* | \
  sh-*-linux* | sh[2346lbe]*-*-linux* | \
  sh-*-netbsdelf* | shl*-*-netbsdelf*)

      tmake_file="... t-sysroot-suffix"

tic6x-*-uclinux)
      tmake_file="t-sysroot-suffix ..."

I think a few possible solutions here are:
- drop SYSROOT_SUFFIX_SPEC support for sh* targets (or some of sh targets)
- fix SYSROOT_SUFFIX_SPEC parsing to respect MULTILIB_DEFAULTS

Does the above sound about right?

I know nothing about SYSROOT_SUFFIX_SPEC.
What uses it? It feels like a competing mechanism to multilib.