On Mon, Jun 09, 2025 at 12:21:16PM -0600, Jeff Law wrote:
>
>
> On 6/9/25 9:43 AM, Stafford Horne wrote:
>
> >
> > Hi,
> >
> > I do not have a fix for this yet. I feel using or1k_hard_regno_mode_ok to
> > control allowing paradoxical subreging of o
On Mon, Jun 09, 2025 at 04:42:49PM +0100, Richard Sandiford wrote:
> Stafford Horne writes:
> > On Fri, Jun 06, 2025 at 04:41:21PM +0100, Stafford Horne wrote:
> >> On Fri, Jun 06, 2025 at 04:20:10PM +0100, Richard Sandiford wrote:
> >> > Stafford
After commit eb2ea476db2 ("emit-rtl: Allow extra checks for
paradoxical subregs [PR119966]") paradoxical subregs or the OpenRISC
condition flag register (reg:BI sr_f) are no longer allowed.
This causes and ICE in the ce1 pass which tries to get the or1k flag
register into an SI register, which is
On Sun, Jun 08, 2025 at 07:26:44AM +0100, Stafford Horne wrote:
> On Sat, Jun 07, 2025 at 06:53:28PM +0300, Dimitar Dimitrov wrote:
> > On Sat, Jun 07, 2025 at 11:38:46AM +0100, Stafford Horne wrote:
> > > On Fri, Jun 06, 2025 at 09:54:53PM +0100, Stafford Horne wrote:
> >
On Sun, Jun 08, 2025 at 09:05:07AM -0600, Jeff Law wrote:
>
>
> On 6/7/25 4:38 AM, Stafford Horne wrote:
>
> >
> > ## Note on cstoresi4 and PUT_MODE.
> >
> > There was some concern raised by Jeff about the use of PUT_MODE in
> > cstoresi4.
> >
On Sat, Jun 07, 2025 at 06:53:28PM +0300, Dimitar Dimitrov wrote:
> On Sat, Jun 07, 2025 at 11:38:46AM +0100, Stafford Horne wrote:
> > On Fri, Jun 06, 2025 at 09:54:53PM +0100, Stafford Horne wrote:
> > > On Fri, Jun 06, 2025 at 11:31:00PM +0300, Dimitar Dimitrov wrote:
>
On Fri, Jun 06, 2025 at 09:54:53PM +0100, Stafford Horne wrote:
> On Fri, Jun 06, 2025 at 11:31:00PM +0300, Dimitar Dimitrov wrote:
> > On Fri, Jun 06, 2025 at 06:12:13PM +0100, Stafford Horne wrote:
> > > On Fri, Jun 06, 2025 at 04:41:21PM +0100, Stafford Horne wrote:
> >
On Fri, Jun 06, 2025 at 11:31:00PM +0300, Dimitar Dimitrov wrote:
> On Fri, Jun 06, 2025 at 06:12:13PM +0100, Stafford Horne wrote:
> > On Fri, Jun 06, 2025 at 04:41:21PM +0100, Stafford Horne wrote:
> > > On Fri, Jun 06, 2025 at 04:20:10PM +0100, Richard Sandiford wrote:
>
On Fri, Jun 06, 2025 at 04:41:21PM +0100, Stafford Horne wrote:
> On Fri, Jun 06, 2025 at 04:20:10PM +0100, Richard Sandiford wrote:
> > Stafford Horne writes:
> > > Hello,
> > >
> > > This seems to be causing a build regression on the or1k port.
> > &
Hello,
This seems to be causing a build regression on the or1k port.
I have not quite figured it out yet but I have bisected to this commit.
The failure is as below, this seems to be caused by the cstoresi4 instruction
produced by
or1k.md. So I think its likely something we are doing funny in
On Sun, Jun 01, 2025 at 09:17:45PM -0600, Jeff Law wrote:
>
>
> On 5/31/25 12:03 AM, Stafford Horne wrote:
> > In or1k structs are returned from functions using the memory address
> > passed in r3. In the current version of GCC the struct stores changed
> > from r11 (
In or1k structs are returned from functions using the memory address
passed in r3. In the current version of GCC the struct stores changed
from r11 (the return value) to r3 the incoming memory address. Both of
are valid.
Adjust the test to match what GCC is producing now.
gcc/testsuite/ChangeLo
The -mcmodel=large option was originally added to handle generation of
large binaries with large PLTs. However, when compiling the Linux
kernel with allyesconfig the output binary is so large that the jump
instruction 26-bit immediate is not large enough to store the jump
offset to some symbols wh
The -mcmodel=large option was originally added to handle generation of
large binaries with large PLTs. However, when compiling the Linux
kernel with allyesconfig the output binary is so large that the jump
instruction 26-bit immediate is not large enough to store the jump
offset to some symbols wh
On Mon, Jan 06, 2025 at 10:03:50AM -0700, Jeff Law wrote:
>
>
> On 1/6/25 10:02 AM, Stafford Horne wrote:
> > On Mon, Jan 06, 2025 at 07:37:56AM -0700, Jeff Law wrote:
> > >
> > >
> > > On 1/6/25 6:01 AM, Stafford Horne wrote:
> > > &
On Mon, Jan 06, 2025 at 07:37:56AM -0700, Jeff Law wrote:
>
>
> On 1/6/25 6:01 AM, Stafford Horne wrote:
> > In the OpenRISC build we get the following warning:
> >
> > ld: warning: __modsi3_s.o: missing .note.GNU-stack section implies
> > executa
In the OpenRISC build we get the following warning:
ld: warning: __modsi3_s.o: missing .note.GNU-stack section implies
executable stack
ld: NOTE: This behaviour is deprecated and will be removed in a future
version of the linker
Fix this by adding a .note.GNU-stack to indicate the stack
On Thu, Jun 13, 2024 at 03:16:44PM +0800, Kewen.Lin wrote:
> Hi,
>
> Gentle ping:
>
> https://gcc.gnu.org/pipermail/gcc-patches/2024-June/653363.html
Hello since this is a treewide update I am not the best person to approve just
this single patch. But it does look good to me as this is what you
Hello,
I pushed this upstream.
On Sat, Mar 18, 2023 at 05:04:05PM +0900, Stafford Horne wrote:
> We should always carry the exceptions forward. This bug was found when
> working on testing glibc math tests, many tests were failing with
> Overflow and Underflow flags not set. This was
We should always carry the exceptions forward. This bug was found when
working on testing glibc math tests, many tests were failing with
Overflow and Underflow flags not set. This was traced to here.
libgcc/ChangeLog:
* config/or1k/sfp-machine.h (FP_HANDLE_EXCEPTIONS): Remove
st
On Thu, Sep 29, 2022 at 03:57:40PM +0100, Stafford Horne wrote:
> This was found when testing buildroot with linuxthreads enabled. In
> this case, the build passes --disable-tls to the toolchain during
> configuration. After building the OpenRISC toolchain it was still
> generat
This was found when testing buildroot with linuxthreads enabled. In
this case, the build passes --disable-tls to the toolchain during
configuration. After building the OpenRISC toolchain it was still
generating TLS code sequences and causing linker failures such as:
/or1k-buildroot-linux-uc
> diff --git a/gcc/config.gcc b/gcc/config.gcc
> index c5064dd37666..0c3a09dfe810 100644
> --- a/gcc/config.gcc
> +++ b/gcc/config.gcc
> @@ -2866,6 +2866,11 @@ or1k*-*-*)
> done
> TM_MULTILIB_CONFIG=`echo $TM_MULTILIB_CONFIG | sed 's/^,//'`
>
> + case ${target} in
> + or1k*le*
From: Bernd Kuhls
The detection of pthread support fails on OpenRISC unless _REENTRANT
is defined. Added the CPP_SPEC definition to correct this.
gcc/ChangeLog:
PR target/94372
* config/or1k/linux.h (CPP_SPEC): Define.
Signed-off-by: Bernd Kuhls
---
This was brought up on the
I have committed this as is.
-Stafford
On Tue, Nov 09, 2021 at 09:13:08PM +0900, Stafford Horne wrote:
> Recently we changed the PROFILE_HOOK _mcount call to pass in the link
> register as an argument. This actually does not work when the _mcount
> call uses a PLT because the GOT regis
Recently we changed the PROFILE_HOOK _mcount call to pass in the link
register as an argument. This actually does not work when the _mcount
call uses a PLT because the GOT register setup code ends up getting
inserted before the PROFILE_HOOK and clobbers the link register
argument.
These glibc tes
This fixes an issue in the glibc port I am working on where the build
fails due to the warning:
error: calling ‘__builtin_return_address’ with a nonzero argument is unsafe
[-Werror=frame-address]
This is due to how the current implementation of _mcount in glibc uses
__builtin_return_address wi
This was not defined in the spec and not consistent in the
implementation causing incosistent behavior. After review we have
updated the CPU implementations and proposed the spec be updated to
specific that FPU tininess checks check for tininess before roudning.
Architecture change draft:
On Sun, Aug 15, 2021 at 12:05:37AM +0200, Giulio Benetti wrote:
> On 8/15/21 12:03 AM, Stafford Horne wrote:
> > On Sat, Aug 14, 2021 at 11:01:16PM +0200, Giulio Benetti wrote:
> > > Hi All,
> > >
> > > On 5/1/21 11:11 PM, Stafford Horne wrote:
> > > &
On Sat, Aug 14, 2021 at 11:01:16PM +0200, Giulio Benetti wrote:
> Hi All,
>
> On 5/1/21 11:11 PM, Stafford Horne wrote:
> > Changes from v1:
> > - Added patch to enabled cmodle=large on crtstuff
> >
> > This series fixes some bugs found when linking large
t; --
> Giulio Benetti
> Benetti Engineering sas
>
> On 5/1/21 11:11 PM, Stafford Horne wrote:
> > Changes from v1:
> > - Added patch to enabled cmodle=large on crtstuff
> >
> > This series fixes some bugs found when linking large binaries, both in
> >
When linking gcc runtime objects into large binaries the link may fail
with the below errors. This will happen even if we are building with
-mcmodel=large.
/home/shorne/work/openrisc/output/host/lib/gcc/or1k-buildroot-linux-uclibc/10.3.0/crtbeginS.o:
in function `deregister_tm_clones':
ributed by Stafford Horne.
+
+ This file is part of GCC.
+
+ GCC is free software; you can redistribute it and/or modify it
+ under the terms of the GNU General Public License as published
+ by the Free Software Foundation; either version 3, or (at your
+ option) any later version.
+
Changes from v1:
- Added patch to enabled cmodle=large on crtstuff
This series fixes some bugs found when linking large binaries, both in buildroot
and glibc testing.
Stafford Horne (2):
or1k: Add mcmodel option to handle large GOTs
or1k: Use cmodel=large when building crtstuff
gcc/config
On Tue, Apr 20, 2021 at 05:20:39PM -0600, Jeff Law wrote:
>
> On 4/18/2021 6:10 PM, Stafford Horne via Gcc-patches wrote:
> > When building libgeos we get an error with:
> >
> > linux-uclibc/9.3.0/crtbeginS.o: in function `__do_global_dtors_aux':
>
-0,0 +1,30 @@
+/* Definitions for option handling for OpenRISC.
+ Copyright (C) 2021 Free Software Foundation, Inc.
+ Contributed by Stafford Horne.
+
+ This file is part of GCC.
+
+ GCC is free software; you can redistribute it and/or modify it
+ under the terms of the GNU General Public License as
While running glibc tests several *-textrel tests failed showing that
relocations remained against read only sections. It turned out this was
related to exception headers data encoding being wrong.
By default pointer encoding will always use the DW_EH_PE_absptr format.
This patch uses format DW_
Define TARGET_ASM_FILE_END as file_end_indicate_exec_stack to allow
generation of the ".note.GNU-stack" section note. This allows binutils
to properly set PT_GNU_STACK in the program header.
This fixes a glibc execstack testsuite test failure found while working
on the OpenRISC glibc port.
gcc/C
This allows the openrisc softfloat implementation to set exceptions.
This also sets the correct tininess after rounding value to be
consistent with hardware and simulator implementations.
libgcc/ChangeLog:
* config/or1k/sfp-machine.h (FP_RND_NEAREST, FP_RND_ZERO,
FP_RND_PINF, FP_R
This is used in libgcc and now glibc to detect when hardware floating
point operations are supported by the target.
gcc/ChangeLog:
* config/or1k/or1k.h (TARGET_CPU_CPP_BUILTINS): Add builtin
define for __or1k_hard_float__.
---
gcc/config/or1k/or1k.h | 2 ++
1 file changed, 2 in
Defining this to not abort as found when working on running tests in
the glibc test suite.
We implement this with a call to _mcount with no arguments. The required
return address's will be pulled from the stack. Passing the LR (r9) as
an argument had problems as sometimes r9 is clobbered by the
t for OpenRISC. This is a series of
patches that fix issues and add features that were missing in GCC causing glibc
testsuite failures.
Pretty much all of these changes are just adding macros.
These changes have been tested via the glibc test suite.
-Stafford
Stafford Horne (5):
or1k: Impl
On Sun, May 31, 2020 at 12:19:16PM +0200, Iain Buclaw wrote:
> Support for OpenRISC target was added in SVN r265963.
>
> The target configurations were taken from the list of supported
> toolchains[1], so seems sensible to include them all.
>
> OK?
>
> Regards
> Iain
>
> [1]: https://www.openri
This allows the openrisc softfloat implementation to set exceptions.
This also sets the correct tininess after rounding value to be
consistent with hardware and simulator implementations.
libgcc/ChangeLog:
* config/or1k/sfp-machine.h (FP_RND_NEAREST, FP_RND_ZERO,
FP_RND_PINF, FP_R
Defining this to not abort as found when working on running tests in
the glibc test suite.
We implement this with a call to _mcount with no arguments. The required
return address's will be pulled from the stack. Passing the LR (r9) as
an argument had problems as sometimes r9 is clobbered by the
While running glibc tests several *-textrel tests failed showing that
relocations remained against read only sections. It turned out this was
related to exception headers data encoding being wrong.
By default pointer encoding will always use the DW_EH_PE_absptr format.
This patch uses format DW_
This is used in libgcc and now glibc to detect when hardware floating
point operations are supported by the target.
gcc/ChangeLog:
* config/or1k/or1k.h (TARGET_CPU_CPP_BUILTINS): Add builtin
define for __or1k_hard_float__.
---
gcc/config/or1k/or1k.h | 2 ++
1 file changed, 2 in
.
-Stafford
Stafford Horne (5):
or1k: Implement profile hook calling _mcount
or1k: Add builtin define to detect hard float
or1k: Support for softfloat to emulate hw exceptions
or1k: Add note to indicate execstack
or1k: Fixup exception header data encodings
gcc/config/or1k/linux.h
Define TARGET_ASM_FILE_END as file_end_indicate_exec_stack to allow
generation of the ".note.GNU-stack" section note. This allows binutils
to properly set PT_GNU_STACK in the program header.
This fixes a glibc execstack testsuite test failure found while working
on the OpenRISC glibc port.
gcc/C
On Fri, Aug 30, 2019 at 08:21:56AM -0700, Richard Henderson wrote:
> LGTM.
Thank you.
> On 8/30/19 2:31 AM, Stafford Horne wrote:
> > Hello, any comments on this?
> >
> > If nothing I will commit in a few days.
> >
> > On Thu, Aug 22, 2019 at 08:44:04PM +0
Hello, any comments on this?
If nothing I will commit in a few days.
On Thu, Aug 22, 2019 at 08:44:04PM +0900, Stafford Horne wrote:
> When compiling glibc we found that the GOT register was being allocated
> r9 when the instruction was still set_got_tmp. That caused set_got to
> c
When compiling glibc we found that the GOT register was being allocated
r9 when the instruction was still set_got_tmp. That caused set_got to
clobber r9. We cannot simply say set_got_tmp clobbers r9 as this is the
reason for having the temporary set_got_tmp.
Fix by using a register class constra
Hi All,
This is all upstream now. Thank you for the reviews.
On Tue, Jul 09, 2019 at 10:06:21PM +0900, Stafford Horne wrote:
> Hello,
>
> New since v2:
> - Fix comment formatting pointed out by Segher in valatile patch
> - Fix issue and add test for rotrsi3 options pointe
On Tue, Jul 09, 2019 at 10:06:21PM +0900, Stafford Horne wrote:
> Hello,
>
> New since v2:
> - Fix comment formatting pointed out by Segher in valatile patch
> - Fix issue and add test for rotrsi3 options pointed out by Segher
> - Fix issue with reg mask for doubles being bac
Fixes bad assembly logic with software divide as reported by Richard Selvaggi.
Also, add a basic test to verify the soft math works when enabled.
gcc/testsuite/ChangeLog:
PR target/90362
* gcc.target/or1k/div-mul-3.c: New test.
libgcc/ChangeLog:
PR target/90362
*
gcc/ChangeLog:
* config.gcc (or1k*-*-*): Add mrori and mror to validation.
* doc/invoke.texi (OpenRISC Options): Add mrori option, rewrite all
documenation to be more clear.
* config/or1k/elf.opt (mboard=, mnewlib): Rewrite documentation to be
more clear.
The force_reg in or1k_expand_compare is hard coded for SImode, which is fine as
this used to only be used on SI expands. However, with FP support this will
cause issues. In general we should only force the right hand operand to a
register if its an immediate. This patch adds an condition to chec
This adds support for OpenRISC hardware floating point instructions.
This is enabled with the -mhard-float option.
Double-prevision floating point operations work using register pairing as
specified in: https://openrisc.io/proposals/orfpx64a32. This has just been
added in the OpenRISC architectur
Volatile memory does not match the memory_operand predicate. This
causes extra extend/mask instructions instructions when reading
from volatile memory. On OpenRISC loading volatile memory can be
treated the same as regular memory loads which supports combined
sign/zero extends. Fixing this elimi
-fpu-3
*** BLURB HERE ***
Stafford Horne (5):
or1k: Fix code quality for volatile memory loads
or1k: Fix issues with msoft-div
or1k: Add mrori option, fix option docs
or1k: Initial support for FPU
or1k: only force reg for immediates
gcc/config.gcc| 2 +
gcc
On Wed, Jul 03, 2019 at 05:26:58PM -0500, Segher Boessenkool wrote:
> On Thu, Jul 04, 2019 at 06:49:17AM +0900, Stafford Horne wrote:
> > On Wed, Jul 03, 2019 at 09:49:02AM -0500, Segher Boessenkool wrote:
> > > On Wed, Jul 03, 2019 at 12:33:49PM +0900, Stafford Horne wrote:
On Wed, Jul 03, 2019 at 09:09:51PM +0200, Richard Henderson wrote:
> On 7/3/19 5:43 PM, Segher Boessenkool wrote:
> >> @@ -212,6 +214,7 @@ enum reg_class
> >> #define REG_CLASS_CONTENTS \
> >> { { 0x, 0x }, \
> >>{ SIBCALL_REGS_MASK, 0 }, \
> >> + { 0x7efe,
On Wed, Jul 03, 2019 at 10:43:01AM -0500, Segher Boessenkool wrote:
> Hi Stafford,
>
> On Wed, Jul 03, 2019 at 12:33:50PM +0900, Stafford Horne wrote:
> > +case 'd':
> > + if (REG_P (x))
> > + if (GET_MODE (x) == DFmode || GET_MODE (x) == DImo
On Wed, Jul 03, 2019 at 09:49:02AM -0500, Segher Boessenkool wrote:
> On Wed, Jul 03, 2019 at 12:33:49PM +0900, Stafford Horne wrote:
> > @@ -179,11 +183,11 @@
> >[(set (match_operand:SI 0 "register_operand" "=r,r")
> > (rotatert:SI (ma
The force_reg in or1k_expand_compare is hard coded for SImode, which is fine as
this used to only be used on SI expands. However, with FP support this will
cause issues. In general we should only force the right hand operand to a
register if its an immediate. This patch adds an condition to chec
This adds support for OpenRISC hardware floating point instructions.
This is enabled with the -mhard-float option.
Double-prevision floating point operations work using register pairing as
specified in: https://openrisc.io/proposals/orfpx64a32. This has just been
added in the OpenRISC architectur
Fixes bad assembly logic with software divide as reported by Richard Selvaggi.
Also, add a basic test to verify the soft math works when enabled.
gcc/testsuite/ChangeLog:
PR target/90362
* gcc.target/or1k/div-mul-3.c: New test.
libgcc/ChangeLog:
PR target/90362
*
gcc/ChangeLog:
* config.gcc (or1k*-*-*): Add mrori and mror to validation.
* doc/invoke.texi (OpenRISC Options): Add mrori option, rewrite all
documenation to be more clear.
* config/or1k/elf.opt (mboard=, mnewlib): Rewrite documentation to be
more clear.
Volatile memory does not match the memory_operand predicate. This
causes extra extend/mask instructions instructions when reading
from volatile memory. On OpenRISC loading volatile memory can be
treated the same as regular memory loads which supports combined
sign/zero extends. Fixing this elimi
es to the GCC 9 branch, I will ask for guidance when I start to do the
backporting.
-Stafford
[0] https://openrisc.io/proposals/orfpx64a32
[1] https://github.com/openrisc/or1k_marocchino
[2] g...@github.com:stffrdhrn/gcc.git or1k-fpu-2
Stafford Horne (5):
or1k: Fix code quality for volatile m
On Thu, May 09, 2019 at 07:44:15PM +0200, Bernhard Reutner-Fischer wrote:
> On 6 May 2019 15:16:20 CEST, Stafford Horne wrote:
> >Volatile memory does not match the memory_operand predicate. This
> >causes extra extend/mask instructions instructions when reading
> >from
As reported by Richard Selvaggi. Also, add a basic test to verify the
soft math works when enabled.
gcc/testsuite/ChangeLog:
PR target/90362
* gcc.target/or1k/div-mul-3.c: New test.
libgcc/ChangeLog:
PR target/90362
* config/or1k/lib1funcs.S (__udivsi3): Change
:
- 90362 or1k: Soft divide does not work correctly
- 90363 or1k: Extra mask insn after load from memory
Stafford Horne (2):
or1k: Fix code quality for volatile memory loads
or1k: Fix issues with msoft-div
gcc/config/or1k/or1k.md | 6 +-
gcc/config/or1k/predicates.md
Volatile memory does not match the memory_operand predicate. This
causes extra extend/mask instructions instructions when reading
from volatile memory. On OpenRISC loading volitile memory can be
treated the same as regular memory loads which supports combined
sign/zero extends. Fixing this elimi
On Fri, Apr 12, 2019 at 09:28:55AM -0600, Jeff Law wrote:
> On 4/10/19 3:27 PM, Stafford Horne wrote:
> > Hello,
> >
> > This is a set of patches to bring FPU support to the OpenRISC backend. The
> > backend also add support for 64-bit floating point operations on
The force_reg in or1k_expand_compare is hard coded for SImode, which is fine as
this used to only be used on SI expands. However, with FP support this will
cause issues. In general we should only force the right hand operand to a
register if its an immediate. This patch adds an condition to chec
Or1k only supports ordered compares so we fall back to lib functions
for unordered operations.
Doubles work on this 32-bit architecture by using register pairing as
specified in: https://openrisc.io/proposals/orfpx64a32
Or1k does not support sf/df or df/sf conversions.
gcc/ChangeLog:
*
Volatile memory does not match the memory_operand predicate. This
causes extra extend/mask instructions instructions when reading
from volatile memory. On OpenRISC this can be treated the same
as regular memory.
gcc/ChangeLog:
* config/or1k/or1k.md (zero_extendsi2): Update predicate.
github repo [3] as well.
-Stafford
[0] https://openrisc.io/proposals/orfpx64a32
[1] g...@github.com:stffrdhrn/binutils-gdb.git orfpx64a32-2
[2] https://github.com/openrisc/or1k_marocchino
[3] g...@github.com:stffrdhrn/gcc.git or1k-fpu-1a
Stafford Horne (3):
or1k: Initial support for FPU
or1k
Committed.
On Tue, Apr 02, 2019 at 01:03:35PM +0900, Stafford Horne wrote:
> Hello,
>
> I was reading through some things and found this was missing.
>
> As before, I don't seem to have CVS access, if its OK and someone can commit
> it
> would be helpful.
It turn
Hello,
I was reading through some things and found this was missing.
As before, I don't seem to have CVS access, if its OK and someone can commit it
would be helpful.
-Stafford
Index: htdocs/gcc-9/changes.html
===
RCS file: /cvs/gc
On Sat, Nov 10, 2018 at 06:09:56AM +0900, Stafford Horne wrote:
> Hello,
>
> I will just commit the below, I dont expect it to cause any problem as I am
> maintainer :).
>
> https://gcc.gnu.org/ml/gcc/2018-08/msg00216.html
>
> On Fri, Nov 09, 2018 at 09:44:07PM +09
Hello,
I will just commit the below, I dont expect it to cause any problem as I am
maintainer :).
https://gcc.gnu.org/ml/gcc/2018-08/msg00216.html
On Fri, Nov 09, 2018 at 09:44:07PM +0900, Stafford Horne wrote:
> ChangeLog:
>
> yyyy-mm-dd Stafford Horne
>
> * MAINTA
ChangeLog:
-mm-dd Stafford Horne
* MAINTAINERS (CPU Port Maintainers): Add myself for or1k.
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index ba8c8040967..cc7d4bddee8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -90,6 +90,7
-mm-dd Stafford Horne
Richard Henderson
gcc/testsuite/ChangeLog:
* gcc.c-torture/execute/20101011-1.c: Adjust for OpenRISC.
* gcc.dg/20020312-2.c: Likewise.
* gcc.dg/attr-alloc_size-11.c: Likewise.
* gcc.dg/builtin-apply2.c: Likewise
-mm-dd Stafford Horne
Richard Henderson
Joel Sherrill
gcc/ChangeLog:
* common/config/or1k/or1k-common.c: New file.
* config/or1k/*: New.
* config.gcc (or1k*-*-*): New.
* configure.ac (or1k*-*-*): New test for openrisc tls
-mm-dd Stafford Horne
Richard Henderson
libgcc/ChangeLog:
* config.host: Add OpenRISC support.
* config/or1k/*: New.
---
libgcc/config.host| 12 ++
libgcc/config/or1k/lib1funcs.S| 222 ++
libgcc/config/or1k
ream master i.e. 2.31.52. Also,
due to removing need for `init` and `fini` it requires the latest changes on
newlib master.
-Stafford
Stafford Horne (3):
or1k: libgcc: initial support for openrisc
or1k: testsuite: initial support for openrisc
or1k: gcc: initial support for openrisc
gcc/com
On Mon, Nov 05, 2018 at 10:03:29AM +0100, Corinna Vinschen wrote:
> On Nov 3 07:00, Stafford Horne wrote:
> > The new GCC port for OpenRISC will use the init_fini_array only and not
> > provide the init() and fini() functions. Disable the function usage by
> > default as
On Mon, Nov 05, 2018 at 10:10:22AM -0500, Rich Felker wrote:
> On Mon, Nov 05, 2018 at 11:13:53AM +, Szabolcs Nagy wrote:
> > On 04/11/18 09:05, Stafford Horne wrote:
> > > On Mon, Oct 29, 2018 at 02:28:11PM +, Szabolcs Nagy wrote:
> > >> On 27/10/
On Mon, Nov 05, 2018 at 11:13:53AM +, Szabolcs Nagy wrote:
> On 04/11/18 09:05, Stafford Horne wrote:
> > On Mon, Oct 29, 2018 at 02:28:11PM +, Szabolcs Nagy wrote:
> >> On 27/10/18 05:37, Stafford Horne wrote:
> ...
> >>> +#undef LINK_S
On Mon, Oct 29, 2018 at 02:28:11PM +, Szabolcs Nagy wrote:
> On 27/10/18 05:37, Stafford Horne wrote:
> > +++ b/gcc/config/or1k/linux.h
> > @@ -0,0 +1,44 @@
> > +/* Linux Definitions for OpenRISC.
> > + Copyright (C) 2018 Free Software Foundation, Inc.
> >
On Sat, Nov 03, 2018 at 10:34:40AM -0500, Peter Bergner wrote:
> On 11/3/18 1:01 AM, Stafford Horne wrote:
> > Nevermind, I don not have write access. I will request to:
> >
> > overse...@gcc.gnu.org
> >
>
> Use the following form to request write access:
&g
Nevermind, I don not have write access. I will request to:
overse...@gcc.gnu.org
On Sat, Nov 03, 2018 at 02:55:17PM +0900, Stafford Horne wrote:
> Committing this.
>
> 2018-11-02 Stafford Horne
>
> * MAINTAINERS (Write After Approval): Add myself.
>
&g
Committing this.
2018-11-02 Stafford Horne
* MAINTAINERS (Write After Approval): Add myself.
Index: MAINTAINERS
===
--- MAINTAINERS (revision 265762)
+++ MAINTAINERS (working copy)
@@ -415,6 +415,7 @@ Stuart Henderson
The new GCC port for OpenRISC will use the init_fini_array only and not
provide the init() and fini() functions. Disable the function usage by
default as its no longer needed.
Signed-off-by: Stafford Horne
---
newlib/configure.host | 1 +
1 file changed, 1 insertion(+)
diff --git a/newlib
On Thu, Nov 01, 2018 at 04:43:08PM -0500, Segher Boessenkool wrote:
> On Fri, Nov 02, 2018 at 06:20:56AM +0900, Stafford Horne wrote:
> > As we were getting ready for OpenRISC gcc port upstreaming Segher pointed
> > out
> > that we should be updating this.
> >
>
Hello,
As we were getting ready for OpenRISC gcc port upstreaming Segher pointed out
that we should be updating this.
I don't think have CVS write access (only git binutils-gdb), can someone help to
review and commit if OK?
-Stafford
Index: readings.html
On Tue, Oct 30, 2018 at 03:57:03PM +, Richard Henderson wrote:
> On 10/30/18 12:18 PM, Stafford Horne wrote:
> > OK, I was just being lazy allowing the spill. Do you think the split/expand
> > would be an RTL using left shift / right shift? Can you think of something
> >
On Tue, Oct 30, 2018 at 10:49:53AM -0500, Segher Boessenkool wrote:
> On Tue, Oct 30, 2018 at 09:49:18PM +0900, Stafford Horne wrote:
> > Hello,
> >
> > On Sun, Oct 28, 2018 at 05:54:47PM -0500, Segher Boessenkool wrote:
> > > Yes, like that. It also easily can
1 - 100 of 133 matches
Mail list logo
