Tentative fix:
...
diff --git a/gdb/arch/riscv.c b/gdb/arch/riscv.c
index e43aafc1c2..dbedb99c94 100644
--- a/gdb/arch/riscv.c
+++ b/gdb/arch/riscv.c
@@ -109,7 +109,7 @@ riscv_lookup_target_description (const struct riscv_gdbarch_featur
es features)
   target_desc *tdesc = riscv_create_target_description (features);
 
   /* Add to the cache.  */
-  riscv_tdesc_cache.emplace (features, tdesc);
+  riscv_tdesc_cache.emplace (features, target_desc_up (tdesc));
 
   return tdesc;
 }
...

Looks somewhat similar to commit 6d0cf4464e "Fix build with gcc-4.8.x".

I have this patch here:
  https://sourceware.org/pipermail/gdb-patches/2020-July/170639.html

that I'd completely forgotten about.  I don't know if this applies cleanly to head still, but it looks like it should fix the issue... maybe.

I can rebase and test this if you'd be happy for this to go in instead?

I should have said, your patch looks fine if we only wanted to fix RISC-V.

(In reply to Andrew Burgess from comment #3)
> I should have said, your patch looks fine if we only wanted to fix RISC-V.

AFAICT the problem reported in this issue only happens in riscv.c (I should probably try this gdb_mbuild.sh that I heard about recently to know for sure).

(In reply to Andrew Burgess from comment #2)
> I have this patch here:
>   https://sourceware.org/pipermail/gdb-patches/2020-July/170639.html
> 
> that I'd completely forgotten about.  I don't know if this applies cleanly
> to head still,

It does.

> but it looks like it should fix the issue... maybe.
> 

I checked, and it does fix the build.

> I can rebase and test this if you'd be happy for this to go in instead?

I'd rather commit this minimal workaround first.

That said, I've looked at your patch, and it looks ok to me.  I'm not sure if timingwise is makes sense to wait after gdb-10 branching to commit this, just a thought.

Hmm, commit 888bdb2b74 "gdb: change regcache list to be a map" just introduced another occurrence.

The master branch has been updated by Tom de Vries <vries@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=38f8aa06d9c422934e635779783107c0d3be419a

commit 38f8aa06d9c422934e635779783107c0d3be419a
Author: Tom de Vries <tdevries@suse.de>
Date:   Sat Aug 8 23:34:19 2020 +0200

    [gdb/build] Fix missing implicit constructor call with gcc 4.8
    
    When building gdb on x86_64-linux with --enable-targets riscv64-suse-linux, I
    run into:
    ...
    src/gdb/arch/riscv.c:112:45:   required from here
    /usr/include/c++/4.8/bits/hashtable_policy.h:195:39: error: no matching \
      function for call to 'std::pair<const riscv_gdbarch_features, const \
      std::unique_ptr<target_desc, target_desc_deleter> >::pair(const \
      riscv_gdbarch_features&, target_desc*&)'
      : _M_v(std::forward<_Args>(__args)...) { }
                                           ^
    ...
    for this code in riscv_lookup_target_description:
    ...
      /* Add to the cache.  */
      riscv_tdesc_cache.emplace (features, tdesc);
    ...
    
    Work around this compiler problem (filed as PR gcc/96537), similar to how that
    was done in commit 6d0cf4464e "Fix build with gcc-4.8.x":
    ...
    -  riscv_tdesc_cache.emplace (features, tdesc);
    +  riscv_tdesc_cache.emplace (features, target_desc_up (tdesc));
    ...
    That is, call the target_desc_up constructor explictly instead of implicitly.
    
    Also, work around a similar issue in get_thread_arch_aspace_regcache.
    
    Build on x86_64-linux with --enable-targets riscv64-suse-linux, and
    reg-tested.
    
    gdb/ChangeLog:
    
    2020-08-08  Tom de Vries  <tdevries@suse.de>
    
            PR build/26344
            * arch/riscv.c (riscv_lookup_target_description): Use an explicit
            constructor.
            * regcache.c (get_thread_arch_aspace_regcache): Same.

Patch fixing build with gcc 4.8 committed, marking resolved-fixed.

(In reply to cvs-commit@gcc.gnu.org from comment #6)
>     Work around this compiler problem (filed as PR gcc/96537),

FTR, the gcc PR was marked as invalid.

The fact that the code compiles with g++-7.5.0 -std=c++11, and doesn't with g++-4.8.5 -std=c++11 doesn't indicate a bug in g++-4.8.5, but that a language update ( http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4387 ) was retroactively applied to older standard modes in g++-7.5.0.

Ok, thanks for investigating and fixing it.  At least, it's easy to please all compilers.