Re: [PATCH 45/52] sh: New hook implementation sh_c_mode_for_floating_type

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 >

Re: [PATCH] Add extra copy of the ifcombine pass after pre [PR102793]

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

[committed][SH] Fix 101737

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 where the input

Re: [PATCH] m68k: restore bootstrap

olution 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

Re: Building a GCC backend for the STM8

Hi, On Sun, 2024-01-28 at 04:41 +0100, Sophie 'Tyalie' Friedrich via Gcc wrote: > Hello dear people, > > I want to try building a GCC compiler backend for the STM8 > micro-controller target in order to make this wonderful architecture > more accessible. > > But as I'm fairly new in this area

Re: [committed] Adjust expectations for pr59533-1.c

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.

Re: [RFA] New pass for sign/zero extension elimination

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 long

Re: [RFA] New pass for sign/zero extension elimination

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

[SH][committed] Fix PR 111001

(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_combine.cc

[SH][committed] Fix PR 101177

. 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 comparison

Re: RISC-V: Added support for CRC.

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

[SH][committed] Fix PR 101469

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

Re: wishlist: support for shorter pointers

> I think a C++ class (or rather, class template) with inline functions is > the way to go here. gcc's optimiser will give good code, and the C++ > class will let you get nice syntax to hide the messy details. > > There is no good way to do this in C. Named address spaces would be a >

Re: RFA: crc builtin functions & optimizations

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,

Re: [PATCH] sh-linux fix target cpu

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

Re: Test results for gccrs on Debian unstable sh4

On Wed, 2021-06-09 at 15:49 +0200, John Paul Adrian Glaubitz wrote: > Hi! > > Just built revision ff4715d79e2c17d270db8b94315aa6b574f48994 on Debian > unstable sh4 > (SuperH) on my Renesas SH-7785LCR evaluation board. > > Testsuite passes without any issues, attaching the full log. > > CC'ing

Re: [PATCH 10/11] sh: Update unexpected empty split condition

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

Re: PING [PATCH] RX new builtin function

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

Re: [committed] Fix latent bug due to peephole2 pass dropping REG_INC notes

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

Re: size of exception handling (Was: performance of exception handling)

On Tue, 2020-05-12 at 09:20 +0200, Freddie Chopin wrote: > > I actually have to build my own toolchain instead of the one provided > by ARM, because to really NOT use C++ exceptions, you have to recompile > the whole libstdc++ with `-fno-exceptions -fno-rtti` (yes, I know they > provide the

Re: Spam, bounces and gcc list removal

On Sat, 2020-03-21 at 13:08 -0700, H.J. Lu via Gcc wrote: > On Sat, Mar 21, 2020 at 12:40 PM Thomas Koenig via Gcc < > gcc@gcc.gnu.org> wrote: > > > > Hi, > > > > > since the change to the new list management, there has been > > > an uptick of spam getting through. Spam is bounced by my ISP, > >

Re: Minor regression due to recent IRA changes

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

Re: Minor regression due to recent IRA changes

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

Re: Minor regression due to recent IRA changes

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

Re: Minor regression due to recent IRA changes

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,

Re: Minor regression due to recent IRA changes

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. >

Re: Minor regression due to recent IRA changes

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.

Re: AW: [PATCH] m68k architecture: support ccmode + lra

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. You'd h

Re: AW: [PATCH] m68k architecture: support ccmode + lra

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

Re: AW: [PATCH] m68k architecture: support ccmode + lra

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: >

Re: AW: [PATCH] m68k architecture: support ccmode + lra

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 >

Re: AW: [PATCH] m68k architecture: support ccmode + lra

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

Re: Add a new combine pass

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 > > &

Re: Add a new combine pass

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): > > > > > >

Re: Add a new combine pass

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

Re: [PATCH 2/4] The main m68k cc0 conversion

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 >

Re: [PATCH 0/4][MSP430] Tweaks to default configuration to reduce code size

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 >

Re: [PATCH 0/4][MSP430] Tweaks to default configuration to reduce code size

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, >

Re: [PATCH 2/4] MSP430: Disable exception handling by default for C++

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 >

Re: [PATCH][RFC] C++-style iterators for FOR_EACH_IMM_USE_STMT

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

Re: [RFH][libgcc] fp-bit bit ordering (PR 78804)

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 > >

Re: [PATCH][RFC] C++-style iterators for FOR_EACH_IMM_USE_STMT

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

Re: [PATCH v2 1/2] RISC-V: Add shorten_memrefs pass

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

Re: [PATCH v2 1/2] RISC-V: Add shorten_memrefs pass

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

Re: [RFH][libgcc] fp-bit bit ordering (PR 78804)

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

Re: [RFH][libgcc] fp-bit bit ordering (PR 78804)

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

Re: [SH][committed] Fix PR 88630

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 tested

[SH][committed] Fix PR 88630

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,-

Re: [RFH][libgcc] fp-bit bit ordering (PR 78804)

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

[SH][committed] Fix PR 88562

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

[RFH][libgcc] fp-bit bit ordering (PR 78804)

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

Re: [PATCH v2] libitm: sh: avoid absolute relocation in shared library (PR 86712)

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 > &

[SH][committed] Fix PR 86805

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

[SH][committed] Fix PR 80672

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

Re: [committed] [PR target/85993] Remove dead conditional in SH target code

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 >

Re: [1/9] Simplify the implementation of HARD_REG_SET

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

Re: [PATCH 26/30] Changes to sh

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

Re: [PATCH] RX: Add rx-*-linux target

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

Re: [PATCH] RX: Add rx-*-linux target

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

Re: Recent combine change causing regressions

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

Re: Parallelize the compilation using Threads

On Tue, 2019-02-12 at 15:12 +0100, Richard Biener wrote: > On Mon, Feb 11, 2019 at 10:46 PM Giuliano Belinassi > wrote: > > > > Hi, > > > > I was just wondering what API should I use to spawn threads and > > control > > its flow. Should I use OpenMP, pthreads, or something else? > > > > My

Re: [PATCH v2] libitm: sh: avoid absolute relocation in shared library (PR 86712)

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

Re: [PATCH] RX TARGET_RTX_COSTS function

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

Re: [PATCH] RX TARGET_RTX_COSTS function

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, > >

Re: [RX] Fix PR 83831 -- Unused bclr, bnot, bset insns

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 some

Re: [PATCH] RX TARGET_RTX_COSTS function

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 your

Re: [RX] Fix PR 83831 -- Unused bclr, bnot, bset insns

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

[RX] Fix PR 83831 -- Unused bclr, bnot, bset insns

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

Re: [PATCH] RX TARGET_RTX_COSTS function

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). >

Re: PING [PATCH] RX movsicc degrade fix

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

[SH][committed] Fix PR 81485

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

[SH][committed] Fix PR 80870

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:

[wwwdocs][committed] Mention GCC 7 changes for SH and RX

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

Re: [RX] Fix PR 81819

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

[RX] Fix PR 81819

Hi, The attached patch fixes PR 81819, which popped up on GCC 7.  I assume it's also there on trunk, but can't build my app with trunk compiler because it's got other issues. Unfortunately I can't add the reproducer test case since it happens only when building a bigger app with LTO.  But I have

Re: [RX] Fix PR 81821

On Thu, 2018-01-11 at 15:10 +, Nick Clifton wrote: >  > > OK for trunk and GCC 7? > Approved.  Do you have access to the repository, or would you like me > to apply the patch for you ? Thanks.  Committed as r256536 (trunk) and r256538 (GCC 7). Cheers, Oleg

[RX] Fix PR 81821

Hi, The attached patch fixes PR 81821.  It is the same as the patch proposed in the PR.  I have briefly checked it in a private application that uses atomic variables and I think it's rather obvious. I have added atomics support on RX in GCC 7 and that was an initial bug.  Thus I'd like to also

Re: [PATCH v2] libgo: Add support for sh

On Wed, 2018-01-10 at 06:25 -0800, Ian Lance Taylor wrote: >  > Thanks.  I finally took a look at this.  I don't know much about SH, > but I don't think we want to add each SH variant as a separate GOARCH > value.  As you can see from the list you modified in > ibgo/go/go/build/syslist.go, the

Re: [PATCH] RX pragma address

On Fri, 2018-01-05 at 12:12 +, Sebastian Perta wrote: >  > > > > > > Is this for some kind of legacy backwards compatibility of > > > something? > Sort of, this is required by the following tool > https://www.renesas.com/en-eu/products/software-tools/tools/code- >

Re: [PATCH] RX pragma address

Hi, On Fri, 2018-01-05 at 11:03 +, Sebastian Perta wrote: >  > Hello,  > > The following patch adds a new pragma, "pragma address" for RX. > The patch updates extend.texi and add a test case to the regression > as well. > For the test case I checked than test is getting picked up in gcc.log

[SH][committed] Fix PR 83111

Hi, The attached patch fixes PR 83111. Committed to mainline as r255096 and to GCC 7 branch as r255097. Cheers, Oleg gcc/ChangeLog PR target/83111 * config/sh/sh.md (udivsi3, divsi3, sibcall_value_pcrel, sibcall_value_pcrel_fdpic): Use local variable instead of

Re: Bit-field struct member sign extension pattern results in redundant

On Fri, 2017-08-18 at 10:29 +1200, Michael Clark wrote: >  > This one is quite interesting: > > - https://cx.rv8.io/g/WXWMTG > > It’s another target independent bug. x86 is using some LEA followed > by SAR trick with a 3 bit shift. Surely SHL 27, SAR 27 would suffice. > In any case RISC-V seems

Re: Overwhelmed by GCC frustration

On Wed, 2017-08-16 at 19:04 -0500, Segher Boessenkool wrote: >  > LRA is easier to work with than old reload, and that makes it better > maintainable. > > Making LRA handle everything reload did is work, and someone needs to > do it. > > LRA probably needs a few more target hooks (a _few_) to

Re: Limit SH strncmp inline expansion (PR target/78460)

On Tue, 2017-08-15 at 23:44 +, Joseph Myers wrote: >  > > This is an older issue.  Please also add a reference to PR 67712 in > > your commit.  Can you also apply it to GCC 6 branch please? > I can't reproduce the problem with GCC 6 branch; the glibc testsuite  > builds fine without

Re: Optimizing away deletion of null pointers with g++

On Wed, 2017-08-16 at 13:30 +0200, Paolo Carlini wrote: >  > I didn't understand why we don't already handle the easy case: > > constexpr int* ptr = nullptr; > delete ptr; > What about overriding the global delete operator with some user defined implementation?  Is there something in the C++

Re: Overwhelmed by GCC frustration

On Wed, 2017-08-16 at 15:53 +0200, Georg-Johann Lay wrote: >  > This means it's actually waste of time to work on these > backends.  The code will finally end up in the dustbin as cc0 > backends are considered undesired ballast that has to be > "jettisoned". > > "Deprecate all cc0" is just a nice

Re: Limit SH strncmp inline expansion (PR target/78460)

On Tue, 2017-08-15 at 21:15 +, Joseph Myers wrote: > GCC mainline built for sh4-linux-gnu runs out of memory building a > glibc test, which calls strncmp with very large constant size > argument, resulting in the SH inline strncmp expansion trying to > inline a fully unrolled expansion of

Re: [PATCH 6/6] qsort comparator consistency checking

On Thu, 2017-08-03 at 19:31 +0300, Alexander Monakov wrote: >  > My mistake, but the main point remains: STL uses 'sort' without the > 'q'. I think it'd be better if GCC's custom containers somewhat tried to follow C++ standard container idioms.  Chopping off the 'q' is one step towards it.

Re: [PATCH 6/6] qsort comparator consistency checking

On Thu, 2017-08-03 at 19:23 +0300, Alexander Monakov wrote: >  > Note that with vec::qsort -> vec::sort renaming (which should be less > controversial, STL also has std::vector::sort) No it doesn't?  One uses std::sort from on a pair of random access iterators to sort a std::vector. Cheers,

Re: Overwhelmed by GCC frustration

On Mon, 2017-07-31 at 15:25 +0200, Georg-Johann Lay wrote: > Around 2010, someone who used a code snipped that I published in > a wiki, reported that the code didn't work and hang in an > endless loop.  Soon I found out that it was due to some GCC > problem, and I got interested in fixing the

Re: [PATCH 12/17] Add server.h and server.c

On Mon, 2017-07-24 at 16:05 -0400, David Malcolm wrote: >  > + > +You should have received a copy of the GNU General Public License > +along with GCC; see the file COPYING3.  If not see > +.  */ > + > +#ifndef GCC_SERVER_H > +#define GCC_SERVER_H > + > +/* Wrapper

Re: Volatile Memory accesses in Branch Delay Slots

On Tue, 2017-07-25 at 10:47 +0200, Jakob Wenzel wrote: >  > jr's delay slot is not filled. However, if the declaration of a is  > changed to `extern int a`, the delay slot is filled with the sw. > > The function responsible for this behavior seems to be  > resource_conflicts_p in reorg.c. Sadly,

Re: Linux and Windows generate different binaries

On Sun, 2017-07-16 at 17:32 -0500, Segher Boessenkool wrote: > On Sun, Jul 16, 2017 at 11:54:43PM +0300, Alexander Monakov wrote: > > > > On Sun, 16 Jul 2017, Segher Boessenkool wrote: > > > > > > I am well aware, and that is not what I asked.  If we would use > > > stable sorts everywhere > >

Re: Missed optimization with const member

On Wed, 2017-07-05 at 12:14 +0100, Jonathan Wakely wrote: >  > No, that would be undefined behaviour. The data member is defined as > const, so it's not possible to write to that member without undefined > behaviour. A variable defined with a const type is not the same as a > variable accessed

Re: Missed optimization with const member

Hi, On Wed, 2017-07-05 at 02:02 +0200, Geza Herman wrote: >  > Here's what happens: in callInitA(), an Object put onto the stack (which  > has a const member variable, initialized to 0). Then somefunction called  > (which is intentionally not defined). Then ~Object() is called, which  > has an

Re: [PATCH 6/6] sh: Fixes for RTL checking

On Tue, 2017-02-21 at 14:48 +, Segher Boessenkool wrote: > 2017-02-21  Segher Boessenkool   > > * config/sh/sh.md (tstsi_t): If operands[0] is a SUBREG instead of > a REG, look at the REG it is a SUBREG of. > (splitter for cmpeqsi_t): Ditto. > >

Re: [PATCH] Fix buffer overflow in SH expand_cbranchdi4 (PR target/79462)

On Tue, 2017-02-14 at 09:22 +0100, Jakub Jelinek wrote: > Hi! > > The following patch fixes a buffer overflow in the SH backend. > r235698 removed an operand (clobber of match_scratch) from the > various > cbranch pattersn that called expand_cbranchdi4 as well as all but > one references to

Re: config/ sync with binutils vs. removing gcc targets.

Hi, Yeah, my SH5/SH64 removal procedures might have been a little too radical, sorry about that.  However ... On Wed, 2016-12-07 at 09:10 +1030, Alan Modra wrote: > I understand that config/ in the gcc repository is the master source > for binutils-gdb config/.  If that's the case then people

Re: [PATCH v3] Do not simplify "(and (reg) (const bit))" to if_then_else.

On Mon, 2016-12-05 at 04:00 -0600, Segher Boessenkool wrote: > On Mon, Dec 05, 2016 at 10:22:13AM +0100, Dominik Vogt wrote: > > > > On Sat, Dec 03, 2016 at 07:19:13PM -0600, Segher Boessenkool wrote: > > > > > > [ I did not see this patch before, sorry. ] > > > > > > This causes the second

Re: [RFC][PATCH] Canonicalize address multiplies

On Tue, 2016-10-04 at 12:53 +, Wilco Dijkstra wrote: > GCC currently doesn't canonicalize address expressions. As a result > inefficient code is generated even for trivial index address > expressions, > blocking CSE and other optimizations: > > int f(int *p, int i) { return p[i+2] + p[i+1]; }

  1   2   3   4   5   6   7   8   9   >