* Problem with RISC-V
@ 2020-09-07 13:11 Lukasz Majewski
2020-09-07 13:29 ` Adhemerval Zanella
2020-09-07 15:22 ` Alistair Francis
0 siblings, 2 replies; 10+ messages in thread
From: Lukasz Majewski @ 2020-09-07 13:11 UTC (permalink / raw)
To: Alistair Francis; +Cc: libc-alpha, Alistair Francis, Maciej W. Rozycki
[-- Attachment #1: Type: text/plain, Size: 1352 bytes --]
Hi Alistair,
After updating glibc-many-build [1] I've noticed following errors:
[lukma@pollux glibc-many-build]$ grep FAIL build-state.json
"glibcs-riscv32-linux-gnu-rv32imac-ilp32 check": "FAIL",
"glibcs-riscv32-linux-gnu-rv32imafdc-ilp32 check": "FAIL",
"glibcs-riscv32-linux-gnu-rv32imafdc-ilp32d check": "FAIL",
"glibcs-riscv32-linux-gnu-rv32imac-ilp32 check": "(New test) ->
FAIL", "glibcs-riscv32-linux-gnu-rv32imafdc-ilp32 check": "(New test)
-> FAIL", "glibcs-riscv32-linux-gnu-rv32imafdc-ilp32d check": "(New
test) -> FAIL",
glibc SHA1: 04bba1e5d84b6fd8d3a3b006bc240cd5d241ee30 on the master
branch.
Is there any ongoing work on them?
Links:
[1] - ../src/scripts/build-many-glibcs.py --replace-sources
/home/lukma/work/glibc/glibc-many-build checkout &&
../src/scripts/build-many-glibcs.py
/home/lukma/work/glibc/glibc-many-build host-libraries &&
../src/scripts/build-many-glibcs.py
/home/lukma/work/glibc/glibc-many-build compilers &&
../src/scripts/build-many-glibcs.py
/home/lukma/work/glibc/glibc-many-build glibc
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: Problem with RISC-V
2020-09-07 13:11 Problem with RISC-V Lukasz Majewski
@ 2020-09-07 13:29 ` Adhemerval Zanella
2020-09-07 15:22 ` Alistair Francis
1 sibling, 0 replies; 10+ messages in thread
From: Adhemerval Zanella @ 2020-09-07 13:29 UTC (permalink / raw)
To: libc-alpha
[-- Attachment #1.1: Type: text/plain, Size: 1620 bytes --]
On 07/09/2020 10:11, Lukasz Majewski wrote:
> Hi Alistair,
>
> After updating glibc-many-build [1] I've noticed following errors:
>
> [lukma@pollux glibc-many-build]$ grep FAIL build-state.json
> "glibcs-riscv32-linux-gnu-rv32imac-ilp32 check": "FAIL",
> "glibcs-riscv32-linux-gnu-rv32imafdc-ilp32 check": "FAIL",
> "glibcs-riscv32-linux-gnu-rv32imafdc-ilp32d check": "FAIL",
> "glibcs-riscv32-linux-gnu-rv32imac-ilp32 check": "(New test) ->
> FAIL", "glibcs-riscv32-linux-gnu-rv32imafdc-ilp32 check": "(New test)
> -> FAIL", "glibcs-riscv32-linux-gnu-rv32imafdc-ilp32d check": "(New
> test) -> FAIL",
>
> glibc SHA1: 04bba1e5d84b6fd8d3a3b006bc240cd5d241ee30 on the master
> branch.
What exactly has failed in the testcase? I haven't yet build a riscv32
toolchain to actually check the current port status.
>
>
> Is there any ongoing work on them?
>
> Links:
> [1] - ../src/scripts/build-many-glibcs.py --replace-sources
> /home/lukma/work/glibc/glibc-many-build checkout &&
> ../src/scripts/build-many-glibcs.py
> /home/lukma/work/glibc/glibc-many-build host-libraries &&
> ../src/scripts/build-many-glibcs.py
> /home/lukma/work/glibc/glibc-many-build compilers &&
> ../src/scripts/build-many-glibcs.py
> /home/lukma/work/glibc/glibc-many-build glibc
>
>
>
> Best regards,
>
> Lukasz Majewski
>
> --
>
> DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Problem with RISC-V
2020-09-07 13:11 Problem with RISC-V Lukasz Majewski
2020-09-07 13:29 ` Adhemerval Zanella
@ 2020-09-07 15:22 ` Alistair Francis
2020-09-07 16:52 ` Joseph Myers
1 sibling, 1 reply; 10+ messages in thread
From: Alistair Francis @ 2020-09-07 15:22 UTC (permalink / raw)
To: Lukasz Majewski, Alistair Francis; +Cc: libc-alpha, Maciej W. Rozycki
On 7/09/2020 6:11 am, Lukasz Majewski wrote:
> Hi Alistair,
>
> After updating glibc-many-build [1] I've noticed following errors:
>
> [lukma@pollux glibc-many-build]$ grep FAIL build-state.json
> "glibcs-riscv32-linux-gnu-rv32imac-ilp32 check": "FAIL",
> "glibcs-riscv32-linux-gnu-rv32imafdc-ilp32 check": "FAIL",
> "glibcs-riscv32-linux-gnu-rv32imafdc-ilp32d check": "FAIL",
> "glibcs-riscv32-linux-gnu-rv32imac-ilp32 check": "(New test) ->
> FAIL", "glibcs-riscv32-linux-gnu-rv32imafdc-ilp32 check": "(New test)
> -> FAIL", "glibcs-riscv32-linux-gnu-rv32imafdc-ilp32d check": "(New
> test) -> FAIL",
>
> glibc SHA1: 04bba1e5d84b6fd8d3a3b006bc240cd5d241ee30 on the master
> branch.
>
>
> Is there any ongoing work on them?
Yep, that is probably the PLT failure. The RV32 tests fail with a PLT error.
It's a problem in binutils and a patch has been sent. The decision was
to not do anything in glibc and just wait for binutils to update.
Alistair
>
> Links:
> [1] - ../src/scripts/build-many-glibcs.py --replace-sources
> /home/lukma/work/glibc/glibc-many-build checkout &&
> ../src/scripts/build-many-glibcs.py
> /home/lukma/work/glibc/glibc-many-build host-libraries &&
> ../src/scripts/build-many-glibcs.py
> /home/lukma/work/glibc/glibc-many-build compilers &&
> ../src/scripts/build-many-glibcs.py
> /home/lukma/work/glibc/glibc-many-build glibc
>
>
>
> Best regards,
>
> Lukasz Majewski
>
> --
>
> DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Problem with RISC-V
2020-09-07 15:22 ` Alistair Francis
@ 2020-09-07 16:52 ` Joseph Myers
2020-09-08 15:57 ` Joseph Myers
0 siblings, 1 reply; 10+ messages in thread
From: Joseph Myers @ 2020-09-07 16:52 UTC (permalink / raw)
To: Alistair Francis
Cc: Lukasz Majewski, Alistair Francis, Maciej W. Rozycki, libc-alpha
On Mon, 7 Sep 2020, Alistair Francis via Libc-alpha wrote:
> Yep, that is probably the PLT failure. The RV32 tests fail with a PLT error.
>
> It's a problem in binutils and a patch has been sent. The decision was to not
> do anything in glibc and just wait for binutils to update.
I asked about a binutils backport in
<https://sourceware.org/pipermail/libc-alpha/2020-August/117334.html>. I
don't believe I saw any response to that, but I still think a backport
would be a good idea.
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Problem with RISC-V
2020-09-07 16:52 ` Joseph Myers
@ 2020-09-08 15:57 ` Joseph Myers
2020-09-08 16:02 ` H.J. Lu
0 siblings, 1 reply; 10+ messages in thread
From: Joseph Myers @ 2020-09-08 15:57 UTC (permalink / raw)
To: Alistair Francis; +Cc: Maciej W. Rozycki, libc-alpha, Alistair Francis
On Mon, 7 Sep 2020, Joseph Myers wrote:
> On Mon, 7 Sep 2020, Alistair Francis via Libc-alpha wrote:
>
> > Yep, that is probably the PLT failure. The RV32 tests fail with a PLT error.
> >
> > It's a problem in binutils and a patch has been sent. The decision was to not
> > do anything in glibc and just wait for binutils to update.
>
> I asked about a binutils backport in
> <https://sourceware.org/pipermail/libc-alpha/2020-August/117334.html>. I
> don't believe I saw any response to that, but I still think a backport
> would be a good idea.
Also, that particular binutils commit doesn't actually seem to fix things
- there is still
Extra PLT reference: libc.so: memset
with mainline GCC / binutils. Could one of the RISC-V people please
investigate why there are still those failures with build-many-glibcs.py,
for riscv32-linux-gnu-rv32imac-ilp32, riscv32-linux-gnu-rv32imafdc-ilp32
and riscv32-linux-gnu-rv32imafdc-ilp32d when using mainline GCC and
binutils?
https://sourceware.org/pipermail/libc-testresults/2020q3/006734.html
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Problem with RISC-V
2020-09-08 15:57 ` Joseph Myers
@ 2020-09-08 16:02 ` H.J. Lu
2020-09-08 16:39 ` Joseph Myers
0 siblings, 1 reply; 10+ messages in thread
From: H.J. Lu @ 2020-09-08 16:02 UTC (permalink / raw)
To: Joseph Myers
Cc: Alistair Francis, Maciej W. Rozycki, Alistair Francis, GNU C Library
On Tue, Sep 8, 2020 at 8:57 AM Joseph Myers <joseph@codesourcery.com> wrote:
>
> On Mon, 7 Sep 2020, Joseph Myers wrote:
>
> > On Mon, 7 Sep 2020, Alistair Francis via Libc-alpha wrote:
> >
> > > Yep, that is probably the PLT failure. The RV32 tests fail with a PLT error.
> > >
> > > It's a problem in binutils and a patch has been sent. The decision was to not
> > > do anything in glibc and just wait for binutils to update.
> >
> > I asked about a binutils backport in
> > <https://sourceware.org/pipermail/libc-alpha/2020-August/117334.html>. I
> > don't believe I saw any response to that, but I still think a backport
> > would be a good idea.
>
> Also, that particular binutils commit doesn't actually seem to fix things
> - there is still
>
> Extra PLT reference: libc.so: memset
Is this related?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67220
--
H.J.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Problem with RISC-V
2020-09-08 16:02 ` H.J. Lu
@ 2020-09-08 16:39 ` Joseph Myers
2020-09-08 19:47 ` Alistair Francis
0 siblings, 1 reply; 10+ messages in thread
From: Joseph Myers @ 2020-09-08 16:39 UTC (permalink / raw)
To: H.J. Lu; +Cc: Maciej W. Rozycki, GNU C Library, Alistair Francis
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
>
> 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
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).
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Problem with RISC-V
2020-09-08 16:39 ` Joseph Myers
@ 2020-09-08 19:47 ` Alistair Francis
2020-09-08 20:25 ` Joseph Myers
0 siblings, 1 reply; 10+ messages in thread
From: Alistair Francis @ 2020-09-08 19:47 UTC (permalink / raw)
To: Joseph Myers; +Cc: H.J. Lu, Maciej W. Rozycki, Alistair Francis, GNU C Library
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Problem with RISC-V
2020-09-08 19:47 ` Alistair Francis
@ 2020-09-08 20:25 ` Joseph Myers
2020-09-12 21:49 ` Alistair Francis
0 siblings, 1 reply; 10+ messages in thread
From: Joseph Myers @ 2020-09-08 20:25 UTC (permalink / raw)
To: Alistair Francis
Cc: H.J. Lu, Maciej W. Rozycki, Alistair Francis, GNU C Library
On Tue, 8 Sep 2020, Alistair Francis wrote:
> > 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?
Yes.
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Problem with RISC-V
2020-09-08 20:25 ` Joseph Myers
@ 2020-09-12 21:49 ` Alistair Francis
0 siblings, 0 replies; 10+ messages in thread
From: Alistair Francis @ 2020-09-12 21:49 UTC (permalink / raw)
To: Joseph Myers; +Cc: H.J. Lu, Maciej W. Rozycki, Alistair Francis, GNU C Library
On Tue, Sep 8, 2020 at 1:25 PM Joseph Myers <joseph@codesourcery.com> wrote:
>
> On Tue, 8 Sep 2020, Alistair Francis wrote:
>
> > > 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?
>
> Yes.
Ok.
I bisected GCC, and apparently the bad commit is this:
commit 68ec60c4a377b532ec2d265ea542107c36b1d15c (HEAD, tag:
basepoints/gcc-10, refs/bisect/bad)
Author: Jakub Jelinek <jakub@redhat.com>
Date: Thu Apr 25 20:01:17 2019 +0200
* BASE-VER: Set to 10.0.0.
From-SVN: r270581
diff --git a/gcc/BASE-VER b/gcc/BASE-VER
index 37ad5c8b19d..a13e7b9c87e 100644
--- a/gcc/BASE-VER
+++ b/gcc/BASE-VER
@@ -1 +1 @@
-9.0.1
+10.0.0
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 0682a44cd4a..fcdbfe4caec 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,7 @@
+2019-04-25 Jakub Jelinek <jakub@redhat.com>
+
+ * BASE-VER: Set to 10.0.0.
+
2019-04-25 Richard Biener <rguenther@suse.de>
PR middle-end/89765
I have no idea why though.
Alistair
>
> --
> Joseph S. Myers
> joseph@codesourcery.com
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2020-09-12 22:00 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-09-07 13:11 Problem with RISC-V Lukasz Majewski
2020-09-07 13:29 ` Adhemerval Zanella
2020-09-07 15:22 ` Alistair Francis
2020-09-07 16:52 ` Joseph Myers
2020-09-08 15:57 ` Joseph Myers
2020-09-08 16:02 ` H.J. Lu
2020-09-08 16:39 ` Joseph Myers
2020-09-08 19:47 ` Alistair Francis
2020-09-08 20:25 ` Joseph Myers
2020-09-12 21:49 ` Alistair Francis
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).