I'm sorry to say that there's no incentive to maintain
crisv32-*-* and cris-*-linux* configurations beyond nostalgia,
(and I'm out of that for the moment). Support in the Linux
kernel for either applicable CRIS variant (CRIS v10 and CRIS
v32) is gone since 2018. Their related part of the cc0
transition workload would be noticable. Note that cris-elf
remains, but crisv32-elf and the CRIS v32 multilib will be
removed, at least for now.
I'm not completely happy about the message (the next-next line
after the context) "*** unless a maintainer comes forward"
because it'd have to be at an infinitesimal maintenance cost to
the cris-elf support. Still, I'm not bothered enough to add
another case construct or means for "planned obsolescence".
Since we're very late at the gcc-10 cycle, maybe best to commit
the cc0 transition for CRIS to "gcc-11" instead, and leave these
targets enabled-but-obsoleted in gcc-10. I believe that's the
formally more correct way to go, even if pragmatically no-one
cares. I think I'll put that work on a branch for now.
---
gcc/ChangeLog | 4 ++++
gcc/config.gcc | 2 ++
2 files changed, 6 insertions(+)
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 423899d3988..b4c45a45087 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,7 @@
+2020-01-17 Hans-Peter Nilsson <h...@axis.com>
+
+ * config.gcc <obsolete targets>: Add crisv32-*-* and cris-*-linux*
+
2020-01-17 Richard Sandiford <richard.sandif...@arm.com>
* gimplify.c (gimplify_return_expr): Use poly_int_tree_p rather
diff --git a/gcc/config.gcc b/gcc/config.gcc
index 5a2f1730477..5532a7be6ac 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -248,6 +248,8 @@ md_file=
# Obsolete configurations.
case ${target} in
tile*-*-* \
+ | crisv32-*-* \
+ | cris-*-linux* \
)
if test "x$enable_obsolete" != xyes; then
echo "*** Configuration ${target} is obsolete." >&2
--
2.11.0
brgds, H-P
