* Jim Wilson [2019-10-22 16:34:53 -0700]:
> On Mon, Oct 21, 2019 at 5:26 AM Andrew Burgess
> wrote:
> > Below is a new versions of this patch, I believe that this addresses
> > the review comments from the earlier version. In addition this has
> > been tested using Jim's idea of forcing -msave-
On Mon, Oct 21, 2019 at 5:26 AM Andrew Burgess
wrote:
> Below is a new versions of this patch, I believe that this addresses
> the review comments from the earlier version. In addition this has
> been tested using Jim's idea of forcing -msave-restore (if the flag is
> not otherwise given) and I n
Below is a new versions of this patch, I believe that this addresses
the review comments from the earlier version. In addition this has
been tested using Jim's idea of forcing -msave-restore (if the flag is
not otherwise given) and I now see no test failures for newlib and
linux toolchains.
One t
On Sat, Aug 31, 2019 at 1:08 AM Andreas Schwab wrote:
> I think the problem is that riscv needs to use t-slibgcc-libgcc so that
> libgcc_s.so is a linker script.
Yes, thanks, that fixes the problem and works well. I've got a patch
using this solution now.
Jim
On Aug 30 2019, Jim Wilson wrote:
> underlying problem is that the save/restore functions were always
> called as non-pic, even for a shared library. But fixing that
> produced shared libraries that failed again, which turned out because
> the save/restore functions use the alternate link regist
On Aug 30 2019, Jim Wilson wrote:
> produced shared libraries that failed again, which turned out because
> the save/restore functions use the alternate link register t0/x5 which
> is clobbered by plts, so we can't call them in shared libraries at
> all.
Shouldn't the save/restore functions alwa
On Sun, Aug 25, 2019 at 9:40 AM Jim Wilson wrote:
> The problem with the linux toolchain support for -msave-restore is
> that we forgot to add a version script to export the symbols. I made
> the obvious change to add a RISC-V specific libgcc version script, and
> now everything in the g++ and gf
On Thu, Aug 22, 2019 at 10:59 PM Jim Wilson wrote:
> With a rv64gc/lp64d linux toolchain, I get 43 extra gcc failures. For
> C++ and Fortran I get a lot of link errors, so the results aren't very
> useful. Apparently we never tested this before.
> /scratch/jimw/fsf-testing/X-tmp-unpatched-64/bui
On Mon, Aug 19, 2019 at 12:15 PM Andrew Burgess
wrote:
> The solution presented in this patch offers a partial solution to this
> problem. By using the TARGET_MACHINE_DEPENDENT_REORG pass to
> implement a very limited pattern matching we identify functions that
> call _riscv_save_0 and _riscv_res
On Mon, Aug 19, 2019 at 12:15 PM Andrew Burgess
wrote:
> * config.gcc: Add riscv-sr.o to extra_objs for riscv.
> * config/riscv/riscv-sr.c: New file.
> * config/riscv/riscv.c (riscv_reorg): New function.
> (TARGET_MACHINE_DEPENDENT_REORG): Define.
> * config
When using the -msave-restore flag we end up with calls to
_riscv_save_0 and _riscv_restore_0. These functions adjust the stack
and save or restore the return address. Due to grouping multiple
save/restore stub functions together the save/restore 0 calls actually
save s0, s1, s2, and the return a
11 matches
Mail list logo
