https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126518
Hans-Peter Nilsson <hp at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |FIXED
Status|UNCONFIRMED |RESOLVED
--- Comment #3 from Hans-Peter Nilsson <hp at gcc dot gnu.org> ---
(In reply to Jeffrey A. Law from comment #1)
> My evaluation puts this problem in newlib rather than GCC. In particular
> this change was identified by my bisection of this failure:
>
> commit 637a7ddc4322ee57cf7810e52e31ac9b3c03f1b8
Spot on. I had a brief look at what should actually be done instead of that
patch, and following my suggestion, the change to the generic files in that
commit have been reverted. To wit, for TRT to happen when adding h8300
initfini-array support, besides a h8300-specific local change in newlib (I
guess that part of the commit was right) there should be a correction in
binutils: declaring for the linker scripts that h8300-elf has
USER_LABEL_PREFIX=_. See
https://inbox.sourceware.org/newlib/caoox84s_sjpbezsax9eprdrtxb-bt0pgbavt8nxy7iiph8h...@mail.gmail.com/t/#u
I sanity-checked for myself that with the breaking patch, I got 965 additional
regressions (per Geoff Keatings contrib/regression/btest-gcc.sh script
accounting), and that with current newlib master (c2ccfae99752) where the
generic bits have been reverted, gcc testsuites results return to that before
the breaking commit for cris-elf.
The only remaining question is whether to resolve this PR as resolve/moved,
resolved/fixed or resolved/invalid. I think I'll go for resolved/fixed; least
effort.
Thanks for taking the time to report this!
