] libgcc SH: fix alignment for relaxation
> >
> > when relaxation is enabled we can not infer the alignment
> > from the position as that may change. This should not change
> > non-relaxed builds as its allready aligned there. This was
> > the missing piece to building an ent
anks Sam for keeping an eye on this!
Best regards,
Oleg Endo
t it'll never untangle.
>
> So I'll go ahead and ACK for the trunk. We can backport to the release
> branches per Joseph's recommendation after it's been on the trunk a bit.
> Ideally the glibc side of this would get wrapped up before that
> project's fall release.
>
Yes, all good. Thanks again!
Best regards,
Oleg Endo
PTIONS): Likewise.
> > (FP_HANDLE_EXCEPTIONS): Implement with _FPU_SETCW.
> I've pushed to the trunk as well as the assumption that you've got these
> various constants right. Oleg, hope I'm not stepping on your toes here,
> I'm just starting to work through some of the safer gcc-16 stuff.
>
No, not at all. Thanks for keeping an eye on it!
I think the committed v2 patch looked good.
Best regards,
Oleg Endo
On Fri, 2025-02-07 at 07:04 -0700, Jeff Law wrote:
>
> On 2/7/25 5:51 AM, Oleg Endo wrote:
> > > Hi,
> > >
> > > Can the issue be resolved in a target independent manner as suggested
> > > below?
> > > Or is it better to deal with this in
> Hi,
>
> Can the issue be resolved in a target independent manner as suggested below?
> Or is it better to deal with this in the target code?
>
> Best regards,
> Oleg Endo
>
> On Fri, 2024-09-27 at 00:26 -0400, Pietro Monteiro wrote:
> > The prefet
pscr))
>
There's already:
__builtin_sh_get_fpscr
__builtin_sh_set_fpscr
.. can you please use that instead of the inline asm?
Best regards,
Oleg Endo
#x27;t apply this version, it seems like auto style fixes
> messed up building, sorry for the noise.
>
> Feel free to review :-)
>
Thanks for looking into this.
Can you please re-send the patch that can be applied?
If it fixes the issue passes tests I don't have objections.
Best regards,
Oleg Endo
a given symbol from the backend code and see if it's got a known address
space assigned to it (via (forward) declaration). This can be used to
optimize accesses to e.g. SFRs even during later stages of compilation.
Best regards,
Oleg Endo
>
> So I would actually even support a more general "don't optimize CRCs by
> default for -Os".
>
I've been putting CRC tables for many years into .text / .rodata on various
MCU projects. Never considered putting them into .data, since flash is
usually a lot larger than RAM. What's the reasoning behind putting the
tables in .data?
Best regards,
Oleg Endo
Hi,
Can the issue be resolved in a target independent manner as suggested below?
Or is it better to deal with this in the target code?
Best regards,
Oleg Endo
On Fri, 2024-09-27 at 00:26 -0400, Pietro Monteiro wrote:
> The prefetch instruction that is emitted by __builtin_prefetch is
&
> One test has a crazy function signature (similar to the PRU test someone
> just fixed up). For that I'm using -std=gnu17.
>
> Pushing to the trunk.
>
> jeff
Thanks!
Best regards,
Oleg Endo
On Mon, 2024-10-14 at 11:37 +0900, Oleg Endo wrote:
> For memory loads/stores (that contain a MEM rtx) sh_rtx_costs would wrongly
> report a cost lower than 1 insn which is not accurate as it makes
> loads/stores appear cheaper than simple arithmetic insns. The cost of a
> load/stor
es to build for a while now with --with-cpu=ev56.
Bootstrap catches only some issues, not all. E.g. see current SH LRA status
(bootstrap OK, still produces silent wrong-code and other issues). Hence
the request to also run the testsuite (make -k check) and diff the .sum
files.
Best regards,
Oleg Endo
to be always at least COST_N_INSNS (1). Forward speed argument to
sh_address_cost.
From b717c462b96e7870f8081d2bc330e4749a4b0538 Mon Sep 17 00:00:00 2001
From: Oleg Endo
Date: Sun, 13 Oct 2024 11:36:38 +0900
Subject: [PATCH] SH: Fix cost estimation of mem load/store
For memory loads/
Without -fno-math-errno some of the test might fail because the expected
insns will not be generated.
Tested with make -k check RUNTESTFLAGS="--target_board=sh-sim\{-m2/-ml,-m2/-
mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}"
Committed to master.
gcc/testsuite/ChangeLog:
* gcc.target/sh
sh-*-rtems* are not affected by that and continue using the
fdpbit library for floating-point emulation on no-fpu variants. If that
should be changed as well, please let me know.
Tested with
make -k check RUNTESTFLAGS="--target_board=sh-sim\{-m2/-ml,-m2/-mb}"
commit
On Sun, 2024-09-29 at 17:27 -0600, Jeff Law wrote:
>
> On 9/29/24 5:12 PM, Oleg Endo wrote:
> >
> > On Sun, 2024-09-29 at 10:40 -0600, Jeff Law wrote:
> > >
> > > On 9/20/24 3:48 PM, Pietro Monteiro wrote:
> > > > From: Pietro Monteiro
&g
tion, as a guide.
> THanks. I pushed this to the trunk.
> jeff
>
I was hesitating on this, because I wasn't sure if it makes sense to have
all those officially documented. But anyway, thanks!
Best regards,
Oleg Endo
sched2 by some other RTL pass. So
perhaps it's better to insert the barrier right when the builtin is emitted.
Best regards,
Oleg Endo
> -- 8< --
>
>
> diff --git a/gcc/builtins.cc b/gcc/builtins.cc
> index 37c7c98e5c..fec751e0d6 100644
> --- a/
s in some cases for debug insn
> related stuff.
>
> Build and tested for sh4-linux-gnu.
Thanks so much!
I think it should be safe to install this on all open branches.
Best regards,
Oleg Endo
>
> PR target/116189
>
> gcc/ChangeLog:
>
> * config/sh
Hi,
I've committed the attached patch to fix the full gcc + libstdc++ build on
sh-elf.
Best regards,
Oleg Endo
On Sat, 2024-07-06 at 07:35 -0600, Jeff Law wrote:
>
> On 7/5/24 1:28 AM, Sébastien Michelland wrote:
> > Hi Oleg!
> >
> > > I don't understand
s,
originally contracted by Hitachi to complement their own in-house C compiler
and also to allow sh-linux to happen at some point. It was entertained by
Renesas for a while through further contracted support work but eventually
they have abandoned it. STmicro was also a licensee of the SH4 CPU for
their TV set top boxes and had a few guys submitting patches now and then
for a while. But the whole thing basically went on life support about 10
years ago.
Perhaps Jeff or others can give more insight on the historical parts.
Best regards,
Oleg Endo
b38918e/attachment.bin
>
> This is almost certainly a poorly written pattern. I just fixed a bunch
> of these, but not this one. Essentially a recent change in the generic
> parts of the compiler is exposing some bugs in the SH backend.
The patterns were written and tested to the best of our knowledge at that
time many years ago. Nobody thought that we'll get a 2nd combine pass after
RA. Anyway, I'll have a look at the remaining patterns.
Sebastien, in the meantime you could also try out and test your changes on
the latest GCC 14 branch, which shouldn't have those issues.
Best regards,
Oleg Endo
s "#".
>
> This patch fixes the most obvious & egregious cases by bringing the
> split condition into the insn's predicate and leaving "&& 1" as the
> split condition. That's enough to get sh4-linux-gnu bootstrapping again
> and I'm hoping it does the same for sh4eb-linux-gnu.
>
> Pushing to the trunk.
>
Thanks, Jeff!
Best regards,
Oleg Endo
bc for... mostly bad reasons).
>
> Deferring maybe again to the few SH users... how do you usually do it?
>
>
I think it would make sense to test it using sh-sim on SH2 big-endian and
little endian at least, as that doesn't have an FPU and hence would run
tests utilizing soft-fp.
After building the toolchain for --target=sh-elf, you can use this to run
the testsuite in the simulator:
make -k check RUNTESTFLAGS="--target_board=sh-sim\{-m2/-ml,-m2/-mb}"
(add make -j parameter according to you needs -- it will be slow)
Let me know if you have any further questions.
Best regards,
Oleg Endo
n/opt-out so keep the
compile times down.
Best regards,
Oleg Endo
the last delay slot is not
stuffed, although the 'add r1,r0' could go in there.
I'd like to revert the removal of this test case, as it catches a valid
issue.
Best regards,
Oleg Endo
On Wed, 2024-06-26 at 16:39 -0600, Jeff Law wrote:
>
> On 6/26/24 4:12 PM, Oleg Endo wrote:
> >
> >
> > On Wed, 2024-06-26 at 07:22 -0600, Jeff Law wrote:
> > > Surya's recent patch to IRA improves the code for sh/pr54602-1.c
> > > slight
r6,r8
add r8,r0
lds.l @r15+,pr
rts
mov.l @r15+,r8
.L4:
.align 2
.L3:
.long _test01
Best regards,
Oleg Endo
sium-elf 1392 1106286 79.45% -7984 -2
> xstormy16-elf 2577 2071506 80.36% -13061 -1
>
>
Since you have already briefly compared some of the code, can you share
those cases which get worse and might require some potential follow up
patches?
Best regards,
Oleg Endo
potting this. Makes sense, please install.
Best regards,
Oleg Endo
>
> gcc/
> * config/sh/sh.md (*minus_plus_one): Add constraints.
> ---
> gcc/config/sh/sh.md | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/gcc/config/sh/sh.md b/gcc
Hi!
On Sun, 2024-06-02 at 22:01 -0500, Kewen Lin wrote:
> This is to remove macro LONG_DOUBLE_TYPE_SIZE define in
> sh port, and add new port specific hook implementation
> sh_c_mode_for_floating_type.
>
The SH parts look OK to me.
Best regards,
Oleg Endo
>
basically to run an additional loop pass after combine and
split1. The main purpose is to hoist constant loads out of loops. Such
constant loads might be formed (in this particular case) during combine
transformations.
The patch adds a new file gcc/config/sh/sh_loop.cc, which has some boiler-
plate code copy pasted from other places to get the loop pass setup and
going.
Any thoughts on this way of doing it?
Best regards,
Oleg Endo
where the input
is not an insn, but e.g. a code label.
From 4ff8ffe7331cf174668cf5c729fd68ff327ab014 Mon Sep 17 00:00:00 2001
From: Oleg Endo
Date: Sun, 3 Mar 2024 14:58:58 +0900
Subject: [PATCH] SH: Fix 101737
gcc/ChangeLog:
PR target/101737
* config/sh/sh.cc (sh_is_nott_insn): Handle case wher
he right solution here.
>
> It is also worth noting I'm bootstrapping and regression testing the
> m68k weekly.
>
>
Jeff, could you please consider sharing your test setup so that others can
reproduce it as well?
I'd be really better if more people had access to a unified test setup and
methodology.
Best regards,
Oleg Endo
On Sun, 2024-01-21 at 19:14 -0700, Jeff Law wrote:
> The change for pr111267 twiddled code generation for sh/pr59533-1.c
>
> We end up eliminating two comparisons, but require two shll instructions
> to do so. And in a couple places we're using an addc sequence rather
> than a subc sequence.
On Sun, 2023-11-19 at 19:51 -0700, Jeff Law wrote:
>
> On 11/19/23 18:22, Oleg Endo wrote:
> >
> > On Sun, 2023-11-19 at 17:47 -0700, Jeff Law wrote:
> > > This is work originally started by Joern @ Embecosm.
> > >
> > > There's been a
On Sun, 2023-11-19 at 17:47 -0700, Jeff Law wrote:
> This is work originally started by Joern @ Embecosm.
>
> There's been a long standing sense that we're generating too many
> sign/zero extensions on the RISC-V port. REE is useful, but it's really
> focused on a relatively narrow part of th
combine.cc (sh_treg_combine::record_set_of_reg):
Skip over nop move insns.
From 4414818f4e5de54ea3c353e2ebb2e79a89ae211b Mon Sep 17 00:00:00 2001
From: Oleg Endo
Date: Mon, 23 Oct 2023 22:08:37 +0900
Subject: [PATCH] SH: Fix PR 111001
gcc/ChangeLog:
PR target/111001
* config/sh/sh_treg_
ote result.
From 3ce4e99303d01d348229cca22bf8d3dd63004e01 Mon Sep 17 00:00:00 2001
From: Oleg Endo
Date: Fri, 20 Oct 2023 18:48:34 +0900
Subject: [PATCH] SH: Fix PR 101177
Fix accidentally inverted comparison.
gcc/ChangeLog:
PR target/101177
* config/sh/sh.md (unnamed split pattern): Fix com
On Sun, 2023-09-24 at 00:05 +0100, Joern Rennecke wrote:
>
> Although maybe Oleg Endo's library, as mentioned in
> https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591748.html ,
> might be suitable? What is the license for that?
>
>
I haven't published the library, but I think I could do t
Hi,
The attached patch fixes PR 101469.
Tested by the original reporter Rin Okuyama on NetBSD with GCC 10.5.
Applied to master, GCC 11, GCC 12, GCC 13 after 'make all' sanity check.
Cheers,
Oleg
gcc/ChangeLog:
PR target/101469
* config/sh/sh.md (peephole2): Handle case where el
On Mon, 2022-03-14 at 18:04 -0700, Andrew Pinski via Gcc-patches wrote:
> On Mon, Mar 14, 2022 at 5:33 PM Joern Rennecke
> wrote:
> >
> > Most microprocessors have efficient ways to perform CRC operations, be
> > that with lookup tables, rotates, or even special instructions.
> > However, because
On Fri, 2022-01-28 at 15:18 -0700, Jeff Law via Gcc-patches wrote:
>
> On 1/12/2022 2:02 AM, Yoshinori Sato wrote:
> > sh-linux not supported any SH1 and SH2a little-endian.
> > Add exceptios it.
> >
> > gcc/ChangeLog:
> >
> > * config/sh/t-linux (MULTILIB_EXCEPTIONS): Add m1, mb/m1 and m2a.
On Wed, 2021-06-02 at 00:05 -0500, Kewen Lin wrote:
> gcc/ChangeLog:
>
> * config/sh/sh.md (doloop_end_split): Fix empty split condition.
> ---
> gcc/config/sh/sh.md | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gcc/config/sh/sh.md b/gcc/config/sh/sh.md
> index e
On Mon, 2020-08-10 at 13:51 +0300, Darius Galis wrote:
>
> I've found the following patch
> https://gcc.gnu.org/legacy-ml/gcc-patches/2018-11/msg00983.html, but it
> is not in the latest sources.
> Could please let me know why it was not added? I'm willing to do any
> rework necessary in order
Hi Jeff,
On Sun, 2020-05-31 at 11:20 -0600, Jeff Law via Gcc-patches wrote:
>
> The peephole2 pass makes some attempt to update various notes, but that
> doesn't
> include REG_INC notes. While I could trivially fix this in the H8 port, I
> wouldn't be terribly surprised if the lack of a REG_INC
On Thu, 2020-03-05 at 08:51 -0700, Jeff Law wrote:
>
> FWIW I've got an sh4/sh4eb bootstrap and regression test running with
> HONOR_REG_ALLOC_ORDER defined. As Vlad mentioned, that may be a
> viable workaround.
>
I've had a look at the good old CSiBE code size results and poked at
some of the
On Sat, 2020-02-29 at 12:35 -0700, Jeff Law wrote:
>
> Yup. That was roughly what I was thinking and roughly the worry I had with
> trying to squash out the quality regressions. But it may ultimately be the
> only way to really resolve these issues.
Another idea would be to let RA see R0, but i
On Sat, 2020-02-29 at 09:38 -0700, Jeff Law wrote:
>
> It really would have just been a workaround for some of the R0 issues anyway.
> I think at its core R0 on the SH probably needs to be treated more like a
> temporary rather than a general register. But that's probably a huge change,
> both i
On Sat, 2020-02-29 at 08:57 -0700, Jeff Law wrote:
>
> > It could open a can of worms. Off the top of my head, R0 is used to
> > hold the function return value, and R0:R1 to return structs with sizeof
> > > 4 bytes. So if DImode is allocated to R0, it implicitly uses R0:R1,
> >
> > AFAIR, doesn
On Sat, 2020-02-29 at 08:47 -0700, Jeff Law wrote:
>
> It's almost certainly the case that the recent IRA changes are going to stress
> R0 more. If I'm reading what Vlad did correctly, one of the tie-breakers its
> using now is to choose the lowest numbered register when all else is equal.
> So
On Fri, 2020-02-28 at 13:24 -0700, Jeff Law wrote:
> This change:
>
> > commit 3133bed5d0327e8a9cd0a601b7ecdb9de4fc825d
> > Author: Vladimir N. Makarov
> > Date: Sun Feb 23 16:20:05 2020 -0500
> >
> > Changing cost propagation and ordering colorable bucket
> > heuristics for
> > PR93564.
>
On Fri, 2019-12-13 at 16:09 +0100, John Paul Adrian Glaubitz wrote:
> Hi!
>
> On 12/13/19 4:06 PM, Oleg Endo wrote:
> > > What are the combine2 patches?
> >
> > See the other thread that I've linked in my message.
>
> I don't see any patch there
On Fri, 2019-12-13 at 15:57 +0100, John Paul Adrian Glaubitz wrote:
> Hello Segher!
>
> > With LRA, sh builds fine (with the combine2 patches). I have no idea
> > if correct code is generated, but it doesn't ICE anymore.
>
> What are the combine2 patches?
See the other thread that I've linked i
On Fri, 2019-12-13 at 08:09 -0600, Segher Boessenkool wrote:
> On Fri, Dec 13, 2019 at 10:06:20PM +0900, Oleg Endo wrote:
> > On Fri, 2019-12-13 at 05:03 -0600, Segher Boessenkool wrote:
> > > On Thu, Dec 12, 2019 at 09:32:27AM +, Richard Sandiford
> > > wrote:
>
On Fri, 2019-12-13 at 05:03 -0600, Segher Boessenkool wrote:
> On Thu, Dec 12, 2019 at 09:32:27AM +, Richard Sandiford wrote:
> > I doubt it will be long before we deprecate
> > all targets that require old reload.)
>
> Do we wait until GCC 12 (to remove old reload completely)? If not, we
> s
On Tue, 2019-11-26 at 07:38 +0100, ste...@franke.ms wrote:
> > On 11/21/19 10:30 AM, ste...@franke.ms wrote:
> > > Hi there,
> > >
> > > here is mc68k's patch to switch the m68k architecture over to ccmode and
> > > lra. See https://github.com/mc68kghost/gcc 68k-ccmode branch.
> >
> > Bernd Schmi
On Fri, 2019-12-06 at 16:51 -0600, Segher Boessenkool wrote:
> On Wed, Dec 04, 2019 at 07:43:30PM +0900, Oleg Endo wrote:
> > On Tue, 2019-12-03 at 12:05 -0600, Segher Boessenkool wrote:
> > > > Hmm ... the R0 problem ... SH doesn't override class_likely_spilled
> >
On Tue, 2019-12-03 at 12:05 -0600, Segher Boessenkool wrote:
> On Tue, Dec 03, 2019 at 10:33:48PM +0900, Oleg Endo wrote:
> > On Mon, 2019-11-25 at 16:47 -0600, Segher Boessenkool wrote:
> > >
> > > > > - sh (that's sh4-linux):
> > > > >
>
On Mon, 2019-11-25 at 16:47 -0600, Segher Boessenkool wrote:
>
> > > - sh (that's sh4-linux):
> > >
> > > /home/segher/src/kernel/net/ipv4/af_inet.c: In function
> > > 'snmp_get_cpu_field':
> > > /home/segher/src/kernel/net/ipv4/af_inet.c:1638:1: error: unable to find
> > > a register to spill
On Sat, 2019-11-23 at 10:36 -0700, Jeff Law wrote:
>
> > Any news on this? I would be in favor of merging these patches as I
> > have
> > tested them successfully on Debian by building the gcc-snapshot
> > package
> > with the patches applied. I used all four patches plus the
> > additional one
>
On Fri, 2019-11-08 at 13:27 +, Jozef Lawrynowicz wrote:
>
> Yes, I should have used -flto in my examples. But it doesn't help remove these
> CRT library functions which are normally either directly added to the
> list of functions to run before main (via .init, .ctors or .init_array) or
> use
On Thu, 2019-11-07 at 21:31 +, Jozef Lawrynowicz wrote:
> When building small programs for MSP430, the impact of the unused
> functions pulled in from the CRT libraries is quite noticeable. Most of these
> relates to feature that will never be used for MSP430 (Transactional memory,
> supporting
On Thu, 2019-11-07 at 21:37 +, Jozef Lawrynowicz wrote:
> The code size bloat added by building C++ programs using libraries containing
> support for exceptions is significant. When using simple constructs such as
> static variables, sometimes many kB from the libraries are unnecessarily
> pull
On Wed, 2019-10-30 at 10:27 +0100, Richard Biener wrote:
>
> Hmm, not sure - I'd like to write
>
> for (gimple *use_stmt : imm_stmt_uses (SSAVAR))
>for (use_operand_p use_p : from
> above>)
> ...
>
> I don't see how that's possible. It would need to be "awkward" like
>
> for (auto
On Fri, 2019-10-11 at 23:27 +0900, Oleg Endo wrote:
> On Thu, 2019-10-03 at 19:34 -0600, Jeff Law wrote:
> >
> > So probably the most interesting target for this test is v850-elf
> > as
> > it's got a reasonably well functioning simulator, hard and soft FP
>
On Tue, 2019-10-29 at 11:26 +0100, Richard Biener wrote:
> While I converted other iterators requiring special BREAK_FROM_XYZ
> a few years ago FOR_EACH_IMM_USE_STMT is remaining. I've pondered
> a bit but cannot arrive at a "nice" solution here with just one
> iterator as the macros happen to use
On Sat, 2019-10-26 at 14:04 -0600, Jeff Law wrote:
> On 10/26/19 1:33 PM, Andrew Waterman wrote:
> > I don't know enough to say whether the legitimize_address hook is
> > sufficient for the intended purpose, but I am sure that RISC-V's
> > concerns are not unique: other GCC targets have to cope wit
On Sat, 2019-10-26 at 12:21 -0600, Jeff Law wrote:
> On 10/25/19 11:39 AM, Craig Blackmore wrote:
> > This patch aims to allow more load/store instructions to be
> > compressed by
> > replacing a load/store of 'base register + large offset' with a new
> > load/store
> > of 'new base + small offset'
On Thu, 2019-10-03 at 19:34 -0600, Jeff Law wrote:
>
> So probably the most interesting target for this test is v850-elf as
> it's got a reasonably well functioning simulator, hard and soft FP
> targets, little endian, and I'm familiar with its current set of
> failures.
>
> I can confirm that yo
Hi Bernd,
On Sun, 2019-09-29 at 08:49 +, Bernd Edlinger wrote:
>
> But I cannot tell if the bitfield access generates
> more efficient code or identical code than the
> original variant when no ms bitfields are used.
> That needs closer inspection of the generated
> assembler code, a simple b
On Fri, 2019-10-11 at 00:36 +0900, Oleg Endo wrote:
> Hi,
>
> When we did the refactoring of SH's FPSCR handling back in GCC 5, we
> missed one thing regarding ST-40, it seems.
>
> The attached patch fixes the issue as confirmed on the real
> hardware.
> Also te
Hi,
When we did the refactoring of SH's FPSCR handling back in GCC 5, we
missed one thing regarding ST-40, it seems.
The attached patch fixes the issue as confirmed on the real hardware.
Also tested on sh-sim with
make -k check RUNTESTFLAGS="--target_board=sh-sim\{-m2/-ml,-m2/-mb,-
m2a/-mb,-m4/-
On Tue, 2019-10-01 at 14:21 -0600, Jeff Law wrote:
>
> So the ask is to just test this on some LE targets? I can do that :-)
>
> I'll throw it in. Analysis will be slightly more difficult than
> usual
> as we've got some fallout from Richard S's work, but it's certainly
> do-able.
Thanks a lot
Hi,
The attached patch fixes PR 88562.
Tested on trunk with
make -k check
RUNTESTFLAGS="--target_board=sh-sim\{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb}"
Committed to trunk, GCC 9, GCC 8, GCC 7 as r276411, r276412, r276413, r276414.
Cheers,
Oleg
gcc/ChangeLog:
PR target/88562
Hi,
I've been dragging this patch along with me for a while.
At the moment, I don't have the resources to fully test it as requested
by Ian in the PR discussion.
So I would like to ask for general comments on this one and hope that
folks with bigger automated test setups can run the patch through
On Sat, 2018-08-04 at 18:00 +0900, Oleg Endo wrote:
> On Fri, 2018-08-03 at 14:54 -0600, Jeff Law wrote:
> > On 07/28/2018 07:04 AM, slyfox.inbox.ru via gcc-patches wrote:
> > >
> > > From: Sergei Trofimovich
> > >
> > > Cc: Andreas Schwab
> &
Hi,
This also sets TARGET_HAVE_SPECULATION_SAFE_VALUE to
speculation_safe_value_not_needed for SH.
Tested with "make all-gcc".
Committed on trunk as r276244 and on GCC 9 as r276245.
Cheers,
Oleg
gcc/ChangeLog
PR target/86805
* config/sh/sh.c (TARGET_HAVE_SPECULATION_SAFE_VALUE
Hi,
The attached patch fixes PR 80672.
Tested by building the compiler with "make all-gcc" and manually
invoking it and checking that the option is parsed as expected.
Committed to trunk as r276240, GCC 9 as r276241, GCC 8 as r276242, GCC
7 as r276243.
Cheers,
Oleg
gcc/ChangeLog
PR tar
On Sun, 2018-07-15 at 14:30 -0600, Jeff Law wrote:
>
> Per Oleg's comment in the PR, the second block is dead and should be
> removed...
>
> Committing to the trunk. While I'm confident this won't change
> anything, my tester will bootstrap sh4 & sh4eb overnight for
> additional
> verification.
On Mon, 2019-09-09 at 19:05 +0100, Richard Sandiford wrote:
>
> Yeah. I might come back to this later and look at a fuller
> transition
> to C++ (or at least to try to get rid of CLEAR_HARD_REG_SET).
>
Maybe you can just typedef it to std::bitset ;)
Cheers,
Oleg
On Tue, 2019-06-25 at 15:22 -0500, acsaw...@linux.ibm.com wrote:
> From: Aaron Sawdey
>
> * config/sh/sh.md (movmemsi): Change name to cpymemsi.
> ---
> gcc/config/sh/sh.md | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gcc/config/sh/sh.md b/gcc/config/sh/sh.md
>
On Sun, 2019-06-02 at 12:37 -0500, Segher Boessenkool wrote:
>
> This is -m64bit-doubles/-m32bit-doubles, and t-rx already multilibs
> that?
Yes, it does.
> And the default is 32-bit. So why does rx-linux need something
> different?
> You could make a point for wanting 64-bit doubles as default
On Sun, 2019-06-02 at 20:26 +0900, Yoshinori Sato wrote:
> On Fri, 31 May 2019 09:16:18 +0900,
> Jeff Law wrote:
> >
> > On 5/29/19 12:27 PM, Jeff Law wrote:
> > > On 5/23/19 6:05 AM, Yoshinori Sato wrote:
> > > > I ported linux kernel to Renesas RX.
> > > >
> > > > rx-*-elf target output a binar
On Mon, 2019-05-13 at 09:38 -0500, Segher Boessenkool wrote:
> On Mon, May 13, 2019 at 08:27:15AM -0600, Jeff Law wrote:
> > sh3-linux-gnu and sh3eb-linux-gnu:
>
> I test sh2 and sh4, but not sh3 :-)
>
> > Tests that now fail, but worked before (3 tests):
> >
> > gcc.target/sh/pr51244-11.c scan-
On Fri, 2018-08-03 at 14:54 -0600, Jeff Law wrote:
> On 07/28/2018 07:04 AM, slyfox.inbox.ru via gcc-patches wrote:
> >
> > From: Sergei Trofimovich
> >
> > Cc: Andreas Schwab
> > Cc: Torvald Riegel
> > Cc: Alexandre Oliva
> > Cc: Oleg Endo
On Thu, 2018-02-22 at 15:41 +, Nick Clifton wrote:
> > > gcc/ChangeLog:
> > > * config/rx/rx.c (rx_rtx_costs): New function.
> > > (TARGET_RTX_COSTS): Override to use rx_rtx_costs.
> Approved - please apply.
>
Thanks. Committed as r257905.
Cheers,
Oleg
Ping.
On Thu, 2018-02-15 at 23:07 +0900, Oleg Endo wrote:
> On Wed, 2018-02-14 at 01:06 +0900, Oleg Endo wrote:
> >
> >
> > Do you happen to have any other numbers on the resulting code
> > size/speed? Looking at the new costs that the patch introduces,
> >
On Wed, 2018-02-14 at 21:34 +0900, Oleg Endo wrote:
> > Approved - please apply - and thanks very much for doing this!
> Thanks! Committed as r257655.
>
Testing another patch
https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00903.html
revealed a bug.
I've committed the attached
On Wed, 2018-02-14 at 01:06 +0900, Oleg Endo wrote:
>
> Do you happen to have any other numbers on the resulting code
> size/speed? Looking at the new costs that the patch introduces, I'd
> expect there to be some more changes than just the 1/x...
>
I've checked you
On Tue, 2018-02-13 at 17:04 +, Nick Clifton wrote:
>
> > gcc/ChangeLog:
> >
> > PR target/83831
> > * config/rx/rx-protos.h (rx_reg_dead_or_unused_after_insn,
> > rx_copy_reg_dead_or_unused_notes, rx_fuse_in_memory_bitop): New
> > declarations.
> > (set_of_reg): New struct
Hi,
The attached patch fixes the deficits mentioned in PR 83831 which is
about unused bclr, bnot and bset instructions.
For some simple cases, the combine pass can successfully fuse a load-
modify-store insn sequence into an insn that operates on a memory
directly. However, in some cases where i
Hi,
On Tue, 2018-02-13 at 15:54 +, Sebastian Perta wrote:
>
> The patch required some changes (the prototype, second param more
> exactly, has changed) in order to compile in the trunk.
Could you please send the patch as an attachment? The formatting looks
a bit off (tabs spaces etc).
> So
On Mon, 2018-02-12 at 11:06 +, Sebastian Perta wrote:
> > > 1) there should be a space between * and the filename
> The spaces are there (see the changelog), the renesas mail server
> removes them sometimes
You might want to send around your patches as email attachments. That
avoids formatt
Hi,
The following fixes PR 81485.
Tested with make -k check RUNTESTFLAGS="--target_board=sh-sim\{-m2/-
ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}"
Committed as r256930.
Cheers,
Oleg
gcc/ChangeLog:
PR target/81485
* config/sh/sh-protos.h (sh_find_set_of_reg): Remove a
Hi,
The following fixed PR 80870.
For whatever reason one of the source files in config/sh was still
including and directly...
Committed as r256926 (trunk), r256928 (GCC 7), r256929 (GCC 6).
Cheers,
Oleg
gcc/ChangeLog:
PR target/80870
* config/sh/sh_optimize_sett_clrt.cc:
Hi,
Somehow I never managed to commit the attached patch.
Better late than never.
Cheers,
Oleg? gcc7_rx_sh_update.patch
Index: htdocs/gcc-7/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-7/changes.html,v
retrieving revision 1
On Thu, 2018-01-11 at 17:32 +, Nick Clifton wrote:
>
> > gcc/ChangeLog:
> > PR target/81819
> > * config/rx/rx.c (rx_is_restricted_memory_address):
> > Handle SUBREG case.
> Go ahead make my day^H^H^H^H^H^H
>
> Approved - please apply.
Committed as r256578 (trunk) and r256579 (GC
1 - 100 of 765 matches
Mail list logo
