Re: Problem with RISC-V

[Alistair Francis <alistair23@gmail.com>]

On Tue, Sep 8, 2020 at 9:39 AM Joseph Myers <joseph@codesourcery.com> wrote:
>
> On Tue, 8 Sep 2020, H.J. Lu via Libc-alpha wrote:
>
> > > Also, that particular binutils commit doesn't actually seem to fix things
> > > - there is still
> > >
> > > Extra PLT reference: libc.so: memset

You are right, the failure is still there. I'm sure I tested this and
it didn't fail.

> >
> > Is this related?
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67220
>
> I don't see why it would be.
>
> All the references to the PLT entry for memset are from libgcc soft-fp
> code for TFmode.  This isn't a matter of visibility attributes not being
> acted on, libgcc.a can't use such visibility for memset because the same
> libgcc.a gets used outside of libc as well.
>
> I'm not sure it actually makes much sense for GCC to be generating memset
> calls for whatever memory clearing takes place inside soft-fp (soft-fp
> never calls memset explicitly from the C sources; libgcc.a for RV64
> doesn't have any such memset references, for example; any clearing should
> be of small aligned pieces of memory that would make more sense to clear
> inline).  So there may be an issue with questionable GCC code generation
> choices for RV32 that should be investigated.  But when libgcc functions
> reference libc functions, those generally need to be listed in
> localplt.data for that glibc configuration (with a '?' to make the
> reference optional, see e.g. the
> sysdeps/unix/sysv/linux/powerpc/powerpc32/nofpu/localplt.data entries for

I sent a patch to do exactly that, but it was never accepted. Should I
look at merging it?


> abort and memset - in this case, the RV32 failures don't appear with GCC
> 9, which both means the '?' is required to avoid making the tests fail
> there, and suggest there may be a GCC regression).

Yep, it does look like a GCC regression between 9 and 10. I'm bisecting now.

Alistair

>
> --
> Joseph S. Myers
> joseph@codesourcery.com