Re: [PATCH v2] Provide more contexts for -Warray-bounds warning messages

> 1. Change the name of the option from: > > -fdiagnostic-try-to-explain-harder > To > -fdiagnostic-explain-harder I can think of a lot of connotations for this name, but alas, they are unfortunate, off-topic, or both. Some more neutral ideas: -fdiagnostics-verbose -fdiagnostic-details Or maybe

[gcc r15-3240] Fix PR testsuite/116271, gcc.dg/vect/tsvc/vect-tsvc-s176.c fails

https://gcc.gnu.org/g:beb94f5979953969593a2387561cdbc8fedfaeb1 commit r15-3240-gbeb94f5979953969593a2387561cdbc8fedfaeb1 Author: Joern Rennecke Date: Wed Aug 28 01:46:25 2024 +0100 Fix PR testsuite/116271, gcc.dg/vect/tsvc/vect-tsvc-s176.c fails gcc/testsuite: PR

[gcc r15-2887] 16-bit testsuite fixes - excessive code size

https://gcc.gnu.org/g:24df2ab33c5e805054006e7b4b94d4270d82074f commit r15-2887-g24df2ab33c5e805054006e7b4b94d4270d82074f Author: Joern Rennecke Date: Mon Aug 12 11:30:02 2024 +0100 16-bit testsuite fixes - excessive code size gcc/testsuite/ * gcc.c-torture/execute

[gcc r15-2886] This fixes problems with tests that exceed a data type or the maximum stack frame size on 16 bit tar

https://gcc.gnu.org/g:46bd63d872ffb9733c4fff51033447f26ce56576 commit r15-2886-g46bd63d872ffb9733c4fff51033447f26ce56576 Author: Joern Rennecke Date: Mon Aug 12 11:13:24 2024 +0100 This fixes problems with tests that exceed a data type or the maximum stack frame size on 16 bit targets

[gcc r15-2885] Avoid cfg corruption when using sjlj exceptions where loops are present in the assign_params emitted

https://gcc.gnu.org/g:40b9a7beb79acbea569be3066768cfb62c0f7c31 commit r15-2885-g40b9a7beb79acbea569be3066768cfb62c0f7c31 Author: Joern Rennecke Date: Mon Aug 12 11:04:51 2024 +0100 Avoid cfg corruption when using sjlj exceptions where loops are present in the assign_params emitted code

[gcc r15-2780] Fix vect/pr115278.cc for targets where uint32_t is distinct from unsigned.

https://gcc.gnu.org/g:b844775283a620b8826adf734ecfc97d820c3611 commit r15-2780-gb844775283a620b8826adf734ecfc97d820c3611 Author: Joern Rennecke Date: Wed Aug 7 02:48:45 2024 +0100 Fix vect/pr115278.cc for targets where uint32_t is distinct from unsigned. gcc/testsuite

[gcc r15-2777] Reduce iteration counts for gcc.dg/vect/tsvc tests.

https://gcc.gnu.org/g:8fac69a2dbff98ebe1feb87faba0d9b81a173c40 commit r15-2777-g8fac69a2dbff98ebe1feb87faba0d9b81a173c40 Author: Joern Rennecke Date: Mon Jul 22 11:02:16 2024 +0100 Reduce iteration counts for gcc.dg/vect/tsvc tests. testsuite/ * gcc.dg/vect/tsvc

Re: sped-up functions from lib1funcs.S: what about using more instructions and/or stack?

On Wed, 15 May 2024 at 07:49, Wolfgang Hospital wrote: > > Dear all, > > G-J Lay has been kind enough to turn my whine about __udivmodqi4 into a bug > report and handle that; I tried to follow suit reporting further strict > improvements (NO resource used more, at least one used less). > While

Re: [V2] New pass for sign/zero extension elimination -- not ready for "final" review

On Thu, 30 Nov 2023 at 17:53, Jeff Law wrote: > > * ext-dce.c: Fixes for carry handling. > > > > * ext-dce.c (safe_for_live_propagation): Handle MINUS. > >(ext_dce_process_uses): Break out carry handling into .. > >(carry_backpropagate): This new function. > >Bet

Re: [V2] New pass for sign/zero extension elimination -- not ready for "final" review

I originally computed mmask in carry_backpropagate from XEXP (x, 0), but abandoned that when I realized we also get called for RTX_OBJ things. I forgot to adjust the SIGN_EXTEND code, though. Fixed in the attached revised patch. Also made sure to not make inputs of LSHIFTRT / ASHIFTRT live if t

Re: [V2] New pass for sign/zero extension elimination -- not ready for "final" review

On Wed, 29 Nov 2023 at 20:05, Joern Rennecke wrote: > > I suspect it'd be more useful to add handling of LSHIFTRT and ASHIFTRT > > . Some ports do > > a lot of static shifting. > > > +case SS_ASHIFT: > > +case US_ASHIFT: > > +

Re: [V2] New pass for sign/zero extension elimination -- not ready for "final" review

On Wed, 29 Nov 2023 at 19:57, Joern Rennecke wrote: > > Attached is what I have for carry_backpropagate . > > The utility of special handling for SS_ASHIFT / US_ASHIFT seems > somewhat marginal. > > I suspect it'd be more useful to add handling of LSHIFTRT and ASHIFTRT

[V2] New pass for sign/zero extension elimination -- not ready for "final" review

5ef9c Author: Joern Rennecke Date: Wed Nov 29 18:46:06 2023 + * ext-dce.c: Fixes for carry handling. * ext-dce.c (safe_for_live_propagation): Handle MINUS. (ext_dce_process_uses): Break out carry handling into .. (carry_backpropagate): This new function. B

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

Why did you leave out MINUS from safe_for_live_propagation ?

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

On Tue, 28 Nov 2023 at 13:36, Joern Rennecke wrote: > For the saturating truncation operations, we have the high-to-low propagation, > but no low-to-high propagation, so that would be something separate to model. P.S.: For unsigned saturating truncation, the propagation from higher to

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

On Mon, 27 Nov 2023 at 20:18, Jeff Law wrote: > > > > On 11/27/23 13:03, Richard Sandiford wrote: > > Joern Rennecke writes: > >> On 11/20/23 11:26, Richard Sandiford wrote: > >>>> + /* ?!? What is the point of this adjustment to DST_MASK?

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

On Mon, 27 Nov 2023 at 20:03, Richard Sandiford wrote: > > Joern Rennecke writes: > > On 11/20/23 11:26, Richard Sandiford wrote: > >>> + /* ?!? What is the point of this adjustment to DST_MASK? */ > >>> + if (code == PLUS || code == MINUS > &

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

You are applying PATTERN to an INSN_LIST. diff --git a/gcc/ext-dce.cc b/gcc/ext-dce.cc index 52032b50951..4523654538c 100644 --- a/gcc/ext-dce.cc +++ b/gcc/ext-dce.cc @@ -122,10 +122,9 @@ safe_for_live_propagation (rtx_code code) optimziation phase during use handling will be. */ static voi

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

On 11/20/23 11:26, Richard Sandiford wrote: >> + /* ?!? What is the point of this adjustment to DST_MASK? */ >> + if (code == PLUS || code == MINUS >> + || code == MULT || code == ASHIFT) >> + dst_mask >> + = dst_mask ? ((2ULL << floor_log2 (dst_mask)) - 1) : 0; > > Yeah, sympathise w

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

On 11/20/23 11:26, Richard Sandiford wrote: >> + >> + mask = GET_MODE_MASK (GET_MODE (SUBREG_REG (x))) << bit; >> + if (!mask) >> + mask = -0x1ULL; > > Not sure I follow this. What does the -0x1ULL constant indicate? > Also, isn't it the mask of the outer register that i

RFA: RISC-V: Add support for XCVhwlp extension in CV32E40P

sh-elf Add support for XCVhwlp extension in CV32E40P 2023-11-18 Joern Rennecke gcc/ * common/config/riscv/riscv-common.cc (riscv_ext_version_table): Add xcvhwlp. (riscv_ext_flag_table): Likewise. * config.gcc (riscv*): Add corev.o to extra_objs. * co

RFA: make scan-assembler* ignore LTO sections (Was: Re: committed [RISC-V]: Harden test scan patterns)

aram=riscv-autovec-preference=scalable riscv-sim/-march=rv64imac/-mabi=lp64 2023-11-08 Joern Rennecke gcc/testsuite/ * lib/scanasm.exp (scan-assembler-times): Disregard LTO sections. (scan-assembler-dem, scan-assembler-dem-not): Likewise. (dg-scan): Likewise, if nam

Re: committed [RISC-V]: Harden test scan patterns

On Wed, 11 Oct 2023 at 05:48, Joern Rennecke wrote: > So I propose we look at the first character of the regexp, and if it's neither > ^ nor \ (neither caret nor backslash), we consider the regexp un-anchored, > and prepend ^[^"]* , so it won't allow a match after a doubl

Re: committed [RISC-V]: Harden test scan patterns

On Sat, 30 Sept 2023 at 22:12, Joern Rennecke wrote: > Also, we might have different directives for not scanning in LTO sections - > or just ignoring .ascii . Or maybe the other way round - you have to do > something special if you want to scan inside strings, and by default we >

RFD: doloop needs better support for nested loops

doloop_end . 2023-10-05 Joern Rennecke gcc/ * doc/md.texi (doloop_end): Document oprional operand 2. * loop-doloop.cc (doloop_optimize): Provide 3rd operand to gen_doloop_end. * target-insns.def (doloop_end): Add optional 3rd operand. diff -

Re: [RISC-V]: Re: cpymem for RISCV with v extension

On Wed, 4 Oct 2023 at 18:38, Patrick O'Neill wrote: > > Hi Joern, > > I'm seeing new failures introduced by this patch > (9464e72bcc9123b619215af8cfef491772a3ebd9). > > On rv64gcv: > FAIL: gcc.dg/pr90263.c scan-assembler memcpy My testing didn't flag this because I used elf targets. The expected

[RISC-V]: Re: cpymem for RISCV with v extension

Attached is the committed version. commit 9464e72bcc9123b619215af8cfef491772a3ebd9 Author: Joern Rennecke Date: Mon Oct 2 03:16:09 2023 +0100 cpymem for RISC-V with v extension gcc/ * config/riscv/riscv-protos.h (riscv_vector::expand_block_move): Declare. * config/riscv/ri

Committed: Fix typo in add_options_for_riscv_v, add_options_for_riscv_zfh, add_options_for_riscv_d .

Committed as obvious (RE doesn't compile without patch, and I know what I meant when I wrote it). commit 5f3da480e7541a9c29d655dccb2463fc5f3cf2c4 Author: Joern Rennecke Date: Sun Oct 1 22:46:43 2023 +0100 Fix typo in add_options_for_riscv_v, add_options_for_risc

Re: committed [RISC-V]: Harden test scan patterns

On Fri, 29 Sept 2023 at 14:54, Jeff Law wrote: > So I recommend we go forward with Joern's approach (so consider that an > ACK for the trunk). Joern can you post a follow-up manual twiddle so > that other ports can follow your example and avoid this problem? The manual... so not in the genera

RFA: RISC-V: Make riscv_vector::legitimize_move adjust SRC in the caller. (Was: Remove mem-to-mem VLS move pattern[PR111566])

ation of the alignment test for using scalars values spanning multiple addressable units. Make riscv_vector::legitimize_move adjust SRC in the caller. 2023-09-29 Joern Rennecke Juzhe-Zhong PR target/111566 gcc/ * config/riscv/riscv-protos.h (riscv_vector::legit

Re: committed [RISC-V]: Harden test scan patterns

On Wed, 27 Sept 2023 at 18:22, Jeff Law wrote: > It would help to describe how these patterns were under specified so > that folks don't continue to make the same mistake as new tests get added. dg-final scan-assembler, scan-assembler-not, and scan-assembler-times use a tcl regular expression (o

committed [RISC-V]: Harden test scan patterns

obvious. commit d326bb6d7588425d013791299272f913fb23e56d Author: Joern Rennecke Date: Wed Sep 27 10:05:13 2023 +0100 Harden scan patterns with a bit of scripting: $ egrep -r 'scan-assembler(|-not|-times) "[[:alnum:].]{1,7}"' riscv $ egrep -rl 'sc

Re: RISC-V: Added support for CRC.

On Tue, 26 Sept 2023 at 14:18, Jeff Law wrote: > But the Coremark code is what it is. This isn't a whole lot > different than the work in the 90s which rewrote loops and compromised > some of the spec benchmarks, or the eqntott hack to simplify that one > key loop in eqntott. I think the state

Re: RISC-V: Added support for CRC.

On Sun, 24 Sept 2023 at 12:41, Alexander Monakov wrote: > > > On Sun, 24 Sep 2023, Joern Rennecke wrote: > > > It is a stated goal of coremark to test performance for CRC. > > I would expect a good CRC benchmark to print CRC throughput in > bytes per cycle or megabytes

Re: RISC-V: Added support for CRC.

Mariam Harutyunyan: +++ b/gcc/ChangeLog @@ -1,3 +1,45 @@ +2023-08-03 Mariam Arutunian + It is common courtesy to include all authors in the list of authors for the ChangeLog; also, this may help people in the future understand the history of the code better. While must of your patch is new, it

RFC: RISC-V sign extension dead code elimination

In the patch call we talked about sign extsnsion elimination, so I dug up this patch set that I did a while ago. It is still lacking some documentation and testing in a more recent base version; I only adjusted the common.opt part context for the patch to apply. Author: Joern Rennecke Date

Re: Re: cpymem for RISCV with v extension

rength reduction of the opaque pattern version for -O3, though. Would people also like to see that expanded into RTL? Or should I just drop in the opaque pattern for that? Or not at all, because everyone uses Superscalar Out-Of-Order execution? commit 1f4b7a8e6798acab1f79de38e85d9d080a76eb4a Autho

Re: cpymem for RISCV with v extension

On Fri, 4 Aug 2023 at 21:52, Jeff Law wrote: > > diff --git a/gcc/config/riscv/riscv-v.cc b/gcc/config/riscv/riscv-v.cc > > index b4884a30872..e61110fa3ad 100644 > > --- a/gcc/config/riscv/riscv-v.cc > > +++ b/gcc/config/riscv/riscv-v.cc > > @@ -49,6 +49,7 @@ > > #include "tm-constrs.h" > > #

Re: RISCV test infrastructure for d / v / zfh extensions

could still construe a multi-word option that uses a string starting with -march as a pathname or similar, but I suppose you'd deserve whatever you get then. I don't see a bobby tables scenario here.) I also found one comment pasto. I have attached the amended patch - not tested yet.

Re: LRA for avr: Clobber with match_dup

> Making operand 0 read/write in define_insn_and_split prevents the web pass > from creating a new pseudo > for the clobber, avoiding the whole problem. That is the right solution. If you clobber a match_dup of an input operand, that makes it and input-and-output operand, so you should mark it a

RFD: RISC-V vectorized libfuncs

I think it would make sense to leave the exact vector layout, like vlen and lmul, to the caller. Attached is an attempt to implement sin and cos vectorized so it allows lmul values of m1 and m2, while using no more than a quarter of the vector registers. The function could live in libgcc and be use

RISCV test infrastructure for d / v / zfh extensions

ou can use check_effective_target_riscv_v_ok to check if that's ok, and then add_options_for_riscv_v to add the appropriate -march option. Examples how this can be used can be found athttps://github.com/embecosm/rvv-gcc/tree/rvv-12/gcc/testsuite 2023-04-17 Joern Rennecke gcc/testsuite/ * lib/targ

cpymem for RISCV with v extension

p64d riscv-sim/-march=rv64imafdcv_zicsr_zifencei_zfh_zba_zbb_zbs_zve32f_zve32x_zve64d_zve64f_zve64x_zvl128b_zvl32b_zvl64b/-mabi=lp64d riscv-sim/-march=rv64imafdcv_zicsr_zifencei_zfh_zve32f_zve32x_zve64d_zve64f_zve64x_zvl128b_zvl32b_zvl64b/-mabi=lp64d 2023-07-12 Ju-Zhe Zhong

Committed: Tighten regexps in gcc.target/riscv/_Float16-zhinx-1.c .

Committed as obvious. commit 6bab2772dbc42ce7a1b29b03ae84e6e434e23c4e Author: Joern Rennecke Date: Tue Jul 18 04:28:55 2023 +0100 Tighten regexps in gcc.target/riscv/_Float16-zhinx-1.c . The original "mv" regexp would match .ascii "\254\254\375\002e2N6\013\

Stepping down as maintainer for ARC and Epiphany

I haven't worked with these targets in years and can't really do sensible maintenance or reviews of patches for them. I am currently working on optimizations for other ports like RISC-V. ARC has still an active maintainer in Claudiu Zissulescu, so is basically unaffected. I am not aware of any o

Re: [v2] RISC-V: Remove masking third operand of rotate instructions

On Thu, 18 May 2023 at 16:37, Joern Rennecke wrote in https://gcc.gnu.org/pipermail/gcc-patches/2023-May/618928.html : > > This breaks building libstdc++-v3 for > -march=rv32imafdcv_zicsr_zifencei_zba_zbb_zbc_zbs_zve32f_zve32x_zve64d_zve64f_zve64x_zvl128b_zvl32b_zvl64b > -mabi=ilp32f

Re: [PATCH v4 02/34] RISC-V: Add vlex_2.c

On Wed, Jun 1, 2022 at 02:28:45 GMT 2022, zhongjuzhe wrote: > gcc/testsuite/ChangeLog: > >* gcc.target/riscv/rvv/intrinsic/vlex_2.c: New test. These intrinsic test cases look like they have been machine generated. And if they aren't, they probably should (have) be(en). I've been working

Re: RFA: crc builtin functions & optimizations

> and there needs to be code to actually expand the builtin using optabs. > And something needs to be done to make match.pd work on the output. Never mind that bit, that was just due to a function argument type mismatch on the last argument of the crc built-in functions.

Re: RFA: crc builtin functions & optimizations

On Wed, 16 Mar 2022 at 08:15, Richard Biener wrote: > The canonical place to transform loops into builtins would be loop > distribution. > Another place would be final value replacement since you basically replace > the reduction result with a call to the builtin, but I think > loop-distribution

Re: RFA: crc builtin functions & optimizations

On 15/03/2022, Richard Biener wrote: > Why's this a new pass? Every walk over all insns costs time. The pass > lacks any comments as to what CFG / stmt structure is matched. From > a quick look it seems like it first(?) statically matches a stmt sequence > without considering intermediate stmt

Re: RFA: crc builtin functions & optimizations

On 15/03/2022, Richard Biener wrote: > Why's this a new pass? Every walk over all insns costs time. If should typically scan considerably less than all the insns. > The pass > lacks any comments as to what CFG / stmt structure is matched. I've put a file in: config/riscv/tree-crc-doc.txt wo

semi-finished patch: dead zero/sign extension elimination

This misses some documentation and testing, but it appears to work well with 64 bit RISC-V. -fext-dce is best used with aggressive unrolling and/or inlining. It deletes zero/sign extensiions where the part of the register that the zero/sign extension pertains to is dead. This is not about multi-

Re: RFA: crc builtin functions & optimizations

On Tue, 15 Mar 2022 at 02:17, Oleg Endo wrote: > > In my own CRC library I've got ~30 'commonly used' CRC types, based on > the following generic definition: > > This being a library makes it relatively easy to tune and customize for > various systems. ... > How would that work together with you

Fwd: RFA: crc builtin functions & optimizations

Oops, that was meant to go to the list too. On Tue, 15 Mar 2022 at 01:04, Andrew Pinski 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 table

RFA: crc builtin functions & optimizations

n the tree, we'll get more contributions of suitable named patterns for various ports. bootstrapped on x86_64-pc-linux-gnu . 2022-03-14 Jon Beniston Joern Rennecke * Makefile.in (OBJS): Add tree-crc.o . * builtin-types.def (BT_FN_UINT16_UINT16_UINT8_CONS

Call for testers: shrink wrapping without a prologue

ction didn't actually return early (doing things with an array of N elements where N might be zero... but it isn't for the actual data). Does someone have a benchmark / computing load where the early return is beneficial? Or conversely, harmful? 2022-03-14 Joern Rennecke * com

RFA: avoid infinite lra loop for constant addresses

I find that when compiling some files, lra goes into an infinite loop reloading constant addresses. This patch allows them to just be recognized as matching addresses immediately, which also saves a bit of space for a few other files. Bootstrapped and regression tested on x86_64-pc-linux-gnu. gcc

Re: RFA: Add option -fretry-compilation

On Mon, 17 May 2021 at 11:59, Richard Biener wrote: > The plan for reload is to axe it similar to CC0 support. Sooner than later, > but > give it's still used exclusively by a lot of target means it might > take some time. > So for you it's always just -fretry-compilation -m[no-]lra? Given -m

Re: RFA: Add option -fretry-compilation

On Mon, 17 May 2021 at 08:36, Richard Biener wrote: > > On Sun, May 16, 2021 at 8:53 PM Joern Rennecke > wrote: > > > > For architectures with likely spilled register classes, neither > > register allocator is guaranteed > > to succeed when using optimization.

Re: RFA: Improve message for wrong number of alternatives

of the error message and the recap of the number of alternatives of operand 0. So I propose the attached patch now. Bootstrapped on x86_64-pc-linux-gnu. 2021-05-17 Joern Rennecke Make "wrong number of alternatives" message more specific, and remove assumption

RFA: Don't squash target character arrays into a narrower host string

64-pc-linux-gnu. FWIW, we also have patches for cpplib / lexer / parser char and string handling to make 8 -> 16 bit char cross-compiling work, but they can't be ported forward easily because the parser has changed since gcc9. 2021-04-16 Joern Rennecke * c-fami

RFA: Add option -fretry-compilation

retry, which is implemented in the compiler driver. Bootstrapped on x86_64-pc-linux-gnu. 2021-05-16 Joern Rennecke * common.opt: New option -fretry-compilation=. * gcc.c (execute): Implement -fretry-compilation. * doc/invoke.texi: Document -fretry-compilation. diff --git

RFA: reduce lra spill failures by splitting likely-spilled-reg hogging pseudo

Bootstrapped regtested and on x86_64-pc-linux-gnu. 2021-02-22 Joern Rennecke lra fix to reduce fatal spill failures. * lra-constraints.c (split_reg): No longer static. * lra-int.h (split_reg): Declare. * lra-assigns.c (lra_split_hard_reg_for): Add strategy

RFA: Support cobbers in define_cond_exec

MATCH_SCRATCH in alter_predicate_for_insn. This makes most sense together with the previous patch for MATCH_DUP support, although the latter can also be used stand-alone, so have posted and tested these patches separately. Bootstrapped on x86_64-pc-linux-gnu. 2020-12-12 Joern Rennecke Fix

RFA: Fix match_dup numbering bug in define_cond_exec

hat's not only wrong, but can also be impossible when the pattern should apply to multiple patterns with different operand numbers. The attached patch fixes this. Bootstrapped on x86_64-pc-linux-gnu. 2020-12-12 Joern Rennecke Fix match_dup bug of define_cond_exec. * ge

[no subject]

e attached patch fixes this. Bootstrapped on x86_64-pc-linux-gnu. 2020-12-12 Joern Rennecke Fix match_dup bug of define_cond_exec. * gensupport.c (alter_predicate_for_insn): Handle MATCH_DUP. diff --git a/gcc/gensupport.c b/gcc/gensupport.c index e1ca06dbc1e..92275358078 100644

RFA: Improve message for wrong number of alternatives

e too many. By making genoutput tell you what the argument counts are, this gets a little bit easier. Bootstrapped on x86_64-pc-linux-gnu. 2021-01-13 Joern Rennecke Make "wrong number of alternatives" message a bit more specific. diff --git a/gcc/genoutput.c b/gcc/genoutput

RFA: Fix match_scratch bug in define_subst

Bootstrapped on x86_64-pc-linux-gnu. 2020-12-10 Joern Rennecke Fix bug in the define_subst handling that made match_scratch unusable for multi-alternative patterns. diff --git a/gcc/gensupport.c b/gcc/gensupport.c index e1ca06dbc1e..4022c661adb 100644 --- a/gcc/gensupport.c +++ b/gcc

Re: RFA: Fix uninitialized memory use in sched_macro_fuse_insns

On Fri, 5 Apr 2019 at 11:07, Richard Sandiford wrote: > > 2019-04-04 Joern Rennecke > > > > * sched-deps.c (sched_macro_fuse_insns): Check return value of > > targetm.fixed_condition_code_regs. > > OK, thanks. Thanks for the review. Is that OK

RFA: Fix uninitialized memory use in sched_macro_fuse_insns

TARGET_FIXED_CONDITION_CODE_REGS has the default value as defined in target.def (hook_bool_uintp_uintp_false). The attached patch fixes this by checking the return value of targetm.fixed_condition_code_regs. Bootstrapped & regtested on x86_64-pc-linux-gnu . 2019-04-04 Joern Rennecke * sched-de

Re: [avr-gcc-list] avr-gcc making really bad inlining decisions.

On 9 April 2015 at 01:15, Bill Westfield wrote: > Is there a way to get gcc to dump the settings of all the parameters > and option settings after it's done parsing the command line? That would be -fverbose-asm combined with -S or --save-temps; this dumps the settings in the assembly output. An

Re: limiting call clobbered registers for library functions

On 2 February 2015 at 21:54, Paul Shortis wrote: > I could have avoided the expander and used a single instruction pattern for > a)b)c) if if could have found a way to have alternative dependent clobbers > in an instruction pattern. I investigated attributes but couldn't see how I > would be able

Re: Help with reload bug, please

On 23 January 2015 at 13:46, Andrew Stubbs wrote: > How does reload ensure that an SImode value (re)loaded into an FP register > has a valid stack index? You could use CANNOT_CHANGE_MODE_CLASS, or request secondary reload. For the latter, you can look at the memory/pseudo to decide if the address

Re: looking for support

On 14 January 2015 at 18:03, vgol...@innovasic.de wrote: > Hello out there, > > I am looking of some support maintaining the m68k target toolchain (incl GDB) > for the fido1100 (basically a CPU32, the real changes are in GDB). Some > experience with the m68k target would be helpful. > Is there s

Re: Machine description and code generation

On 26 November 2014 at 16:48, Mathias Roslund wrote: > Since then I've added more instructions and gotten to the point where most > stuff seems to be working. My current issue is that signed divide and all > shift operations insists on sign/zero extending the operands, resulting in > 32bit operati

Re: [avr-gcc-list] hard to find the correct include files at compile time

On 25 November 2014 at 13:57, Ivaylo Ganchev wrote: > As a side-note the pgmspace.h includes also . I am not sure > whether the correct one is charged. To be sure I also make an explicit > statement (#include "/usr/lib/gcc/avr/4.7.2/include/stddef.h"). What is This seems to indicate that you are

Re: Legal paperwork for GCC contributions

On 24 November 2014 at 10:58, Martin Jambor wrote: > On Sun, Nov 23, 2014 at 06:48:53PM -0500, Lawrence Velázquez wrote: >> Hi, >> >> I recently contributed some fixes against GCC trunk, gcc-4_9-branch, and >> gcc-4_8-branch for which I need the requisite legal paperwork. >> >> However, I'd like t

Re: [avr-gcc-list] [bug] cbi optimization error for 8-bit AVRs

On 17 November 2014 17:17, Georg-Johann Lay wrote: > as a test case which works both for C and C++. The C++ front fails in > applying a similar type demotion like the C front, Well, duh, that's because it's a different language. > > > Is there a solution that is more reliable than combine? Cur

Re: More useful support for low-end ARM architecture

On 11 November 2014 16:22, Joey Ye wrote: > Markus, > > -mmcu probably will not work for ARM architectured MCUs. Reason are > * Confusion. -mcpu is encouraged and already widely used for ARM > architectures. Introducing -mmcu will be very confusing. It' just a matter of bundling specifications.

Re: testing policy for C/C++ front end changes

On 9 November 2014 23:13, Sandra Loosemore wrote: > Forgive me if this has been raised before -- I tried searching the archives > but couldn't think of good keywords that would weed out unrelated posts > > I was checking the testing requirements for a C front end patch > > https://gcc.gnu.org/

Re: [avr-gcc-list] [bug] cbi optimization error for 8-bit AVRs

On 8 November 2014 00:32, Szikra István wrote: > Hi everyone! > > My problem in sort: I’m getting > in r24, 0x18 > ldi r25, 0x00 > andir24, 0xEF > out 0x18, r24 > instead of > cbi 0x18, 4 > . > > I’m trying to write efficient modern C/C+

Committed: Fix typo in low_io_address_operand

I forgot the 'x' number base specifier in r216034. Committed as obvious. 2014-11-09 Joern Rennecke * config/avr/predicates.md (low_io_address_operand): Fix typo. Index: config/avr/predicates.md === --- config/avr/pre

Re: [avr-gcc-list] [bug] cbi optimization error for 8-bit AVRs

On 8 November 2014 00:32, Szikra István wrote: > Unfortunately GCC support for AVR (among other things) is not always > flawless. And it changes from versions to version (and not always for the > better). regression tests can help to catch instances where the compiler looses functionality. I'm

RFA: fix avr C++ preprocessing to pick up device defines

r. By setting CPLUSPLUS_CPP_SPEC to "%(cpp)", we let the cc1plus preprocessor look up the actual value of the preprocessor specs. OK to apply? 2014-11-09 Joern Rennecke * /config/avr/avr.h (CPLUSPLUS_CPP_SPEC): Define. diff --git a/gcc/config/avr/avr.h b/gcc/config/avr/avr.

[avr-libc-dev] [patch #8565] Remove most device specific tests from io.h

URL: Summary: Remove most device specific tests from io.h Project: AVR C Runtime Library Submitted by: amylaar Submitted on: Tue 04 Nov 2014 17:00:57 GMT Category: None

[avr-libc-dev] [patch #8564] Add dwarf debug info alternative, build printf with debug info

URL: Summary: Add dwarf debug info alternative, build printf with debug info Project: AVR C Runtime Library Submitted by: amylaar Submitted on: Tue 04 Nov 2014 16:45:28 GMT Category

Re: [Patch 3/7 arc] Deprecate *_BY_PIECES_P, move to hookized version

On 4 November 2014 14:24, James Greenhalgh wrote: > On Tue, Nov 04, 2014 at 12:07:56PM +0000, Joern Rennecke wrote: >> On 31 October 2014 15:10, James Greenhalgh wrote: >> >> > While I am there, arc defines a macro CAN_MOVE_BY_PIECES, which is >> > unused, so cl

Re: [Patch 3/7 arc] Deprecate *_BY_PIECES_P, move to hookized version

On 31 October 2014 15:10, James Greenhalgh wrote: > While I am there, arc defines a macro CAN_MOVE_BY_PIECES, which is > unused, so clean that up too. That's not a clean-up. This pertains to PR 39350. Which, incidentally, this hookization completely ignores, entrenching the conflation of move e

Re: how to keep a hard register across multiple instrutions?

On 3 November 2014 21:51, David Kang wrote: > > Thank you for the tips. > I tried the following condition for split. > > "reload_completed && FP_REG_P (operands[0])" > > But, the registers are still changed. > How can I specify "after register allocation" in the split condition? Are you sure t

Re: [patch,avr] correct incorrect spec string for device specs

On 3 November 2014 14:33, Sivanupandi, Pitchumani wrote: > Hi, > > Unrecognized option error is issued by avr-gcc for devices with AVR_ISA_RMW. > This is because of an incorrect spec string device spec generation. > > Below patch corrects the incorrect spec string in gen-avr-mmcu-specs.c. > If OK,

Re: [ARC] RFA: Use new rtl iterators in arc_write_ext_corereg

On 25 October 2014 10:58, Richard Sandiford wrote: > This is part of a series to remove uses of for_each_rtx from the ports. > > Tested by making sure there were no code changes for gcc.dg, gcc.c-torture > and g++.dg for arc-elf. OK to install? > > Thanks, > Richard > > > gcc/ > * config/

Re: [ARC] RFA: Use new rtl iterators in arc600_corereg_hazard

On 25 October 2014 10:56, Richard Sandiford wrote: > This is part of a series to remove uses of for_each_rtx from the ports. > > Tested by making sure there were no code changes for gcc.dg, gcc.c-torture > and g++.dg for arc-elf. OK to install? > > Thanks, > Richard > > > gcc/ > * config/

Re: [ARC] RFA: Use new rtl iterators in arc_rewrite_small_data

On 25 October 2014 10:53, Richard Sandiford wrote: ... > Tested by making sure there were no code changes for gcc.dg, gcc.c-torture > and g++.dg for arc-elf. OK to install? > > Thanks, > Richard > > > gcc/ > * config/arc/arc.c: Include rtl-iter.h. > (arc_rewrite_small_data_1): De

Re: [ARC] RFA: Use new rtl iterators in small_data_pattern

On 25 October 2014 10:54, Richard Sandiford wrote: > This is part of a series to remove uses of for_each_rtx from the ports. > > Tested by making sure there were no code changes for gcc.dg, gcc.c-torture > and g++.dg for arc-elf. OK to install? OK.

Re: [avr-libc-dev] selective linking of floating point support for *printf / *scanf

On 24 October 2014 09:06, Thomas Preud'homme wrote: >> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On >> Behalf Of Joseph S. Myers >> >> I'm not clear if you're proposing such a patch for review, but note: > > Yep but not yet for inclusion as I'm waiting to see if this would suit th

Re: selective linking of floating point support for *printf / *scanf

On 24 October 2014 09:06, Thomas Preud'homme wrote: >> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On >> Behalf Of Joseph S. Myers >> >> I'm not clear if you're proposing such a patch for review, but note: > > Yep but not yet for inclusion as I'm waiting to see if this would suit th

RFA: Add avrtiny support

In __do_global_dtors, I ended up changing the order of execution in order to get back to the forwards/backwards order as found in crtstuff.c The patch I attached to target/63223 is actually an extract from this patch. gcc: 2014-08-29 Joern Rennecke Vidya Praveen

Re: RFA: Add libstdc++-v3 support for avr 4/7: fix locale_facets_nonio overloading on struct tm using template

On 21 October 2014 17:29, Jonathan Wakely wrote: >> +typedef typeof (((tm*)0)->tm_sec) __tm_small_int; > > > I think this should probably use __typeof__ to work with > -Wpedantic-errors Ok, makes sense, and it's a straightforward change. > >> +#else /* For 100% mangling compatibility, use int d

RFA: Add libstdc++-v3 support for avr 7/7: Add missing qualifier for size_t in a couple of libstdc++-v3 tests

A couple of tests fail because an unqualified size_t is used. 2014-09-15 Joern Rennecke * libstdc++-v3/testsuite/util/io/prog_bar.cc: Qualify size_t. * libstdc++-v3/testsuite/util/io/prog_bar.hpp: Likewise. * libstdc++-v3/testsuite/util/io/verified_cmd_line_input.hpp

RFA: Add libstdc++-v3 support for avr 6/7: Run -frtti tests with -frtti

We got a couple of tests that assume -frtti; this is the default for most targets, but not for avr. libstdc++-v3: 2013-09-24 Joern Rennecke * testsuite/18_support/type_info/hash_code.cc (dg-options): Add -frtti. * testsuite/20_util/shared_ptr/cons/unique_ptr_deleter_ref_2.cc

  1   2   3   4   5   6   7   8   9   10   >