committed: Stepping down as maintainer for ARC and Epiphany

Stepping down as maintainer for ARC and Epiphany * MAINTAINERS (CPU Port Maintainers): Remove myself as ARC end epiphany maintainer. (Write After Approval): Add myself.commit b3f20dd75e9255fc9d56d4f020972469dd671a3a Author: Joern Rennecke Date: Fri Jul 7 01:02:28 2023

committed: Fix PR libstdc++/100361

commit 66c5f24788652a49b528f14e23e8121ad0935ace (trunk) commit 5f772bd9847cdbf6a7a6d856de87cb65472d56f4 (releases/gcc11) As approved by Jonathan Wakely in the comments to PR libstdc++/100361 . Bootstrapped and regression tested on x86_64-pc-linux.gnu. 2021-05-18 Joern Rennecke libstdc++:

RFA: save/restore target options in handle_optimize_attribute

We set default for some target options in TARGET_OPTION_OPTIMIZATION_TABLE, but these can be overridden by specifying the corresponding explicit -mXXX / -mno-XXX options. When a function bears the attribue __attribute__ ((optimize("02"))) the target options are set to the default for that

Re: RFA: fix gcc.dg/tree-ssa/popcount4l.c 16 bit failure, improve 64 bit popcount expansion for 32 bit target

Attached is the updated version of the patch. Bootstrapped and regtested on x86_64-pc-linux-gnu. OK to apply? Recognize popcount also when a double width operation is needed. 2021-01-27 Joern Rennecke gcc/ * match.pd : When generating popcount directly fails, try doing it in

RFA: avoid changing MEMs to mode with higher alignment than underlying memory

esirisc has a sub-target that has DImode with 4 byte alignment, and DFmode with 8 byte alignment. For code like g++.dg/torture/pr39713.C , the optimizes changes the mode of a MEM from DImode to DFmode even if the required alignment is not available. Appended is is the target-independent part of

P.S: RFA: fix gcc.dg/tree-ssa/popcount4l.c 16 bit failure, improve 64 bit popcount expansion for 32 bit target

Bootstrapped and regression tested in gcc version d6f1cf644c45b76a27b6a6869dedaa030e3c7570 on x86_64 GNU/Linux .

RFA: fix gcc.dg/tree-ssa/popcount4l.c 16 bit failure, improve 64 bit popcount expansion for 32 bit target

optabs.c:expand_unop_direct can expand a popcount builtin without a call under certain conditions even without a popcount pattern of the required data width: if (unoptab == popcount_optab && is_a (mode, _mode) && GET_MODE_SIZE (int_mode) == 2 * UNITS_PER_WORD && optab_handler

Re: Simplify X * C1 == C2 with undefined overflow

On 07/08/20 21:57, Marc Glisse wrote: On Fri, 7 Aug 2020, Joern Wolfgang Rennecke wrote: However, there are cases were the second division will not be possible without rest. Consider : 7*X == 3 3/7 is 0 rest 3. 0x1 / 7 is 0x24924924 rest 4 Since 3 cannot be represented

Re: Simplify X * C1 == C2 with undefined overflow

On 07/08/20 19:21, Marc Glisse wrote: If we are going to handle the wrapping case, we shouldn't limit to the non-wrapping meaning of multiplicity. 3*X==5 should become X==1431655767 (for a 32 bit type), etc. Do we have an extended gcd somewhere in gcc, to help compute 1431655767? I don't

Re: Simplify X * C1 == C2 with undefined overflow

this transformation is quite straightforward, without overflow, 3*X==15 is the same as X==5 and 3*X==5 cannot happen. Actually, with binary and decimal computers, this transformation (with these specific numbers) is also valid for wrapping overflow. More generally, it is valid for wrapping

Committed (vectorizable_comparison): Swap operands only once.

For gcc.dg/vect/vect-bool-cmp.c, vectorizable_comparison would swap the comparison operands in fn7 once for each copy, thus all odd copies would end up unswapped. Regression tested on x86_64-pc-linux-gnu. Committed as obvious. 2019-07-09 Joern Rennecke * tree-vect-stmts.c

Commited: remove uint32_t declaration from testsuite/gcc.dg/vect/slp-reduc-sad.c

The declaration was not used, and it clashed with a system declaration from newlib. On a 32 bit typical system, uint32_t can be defined using unsigned, unsigned int or unsigned long. gcc.dg/vect/slp-reduc-sad.c includes gcc.dg/vect/tree-vect.h, which includes newlib/libc/include/signal.h,

Re: Call for testers: improve move2add_use_add2_insn for targets with HAVE_POST_MODIFY_DISP and/or clobber-encumbered add

Never mind, if the target has reg+offset addressing, the add should be tried in preference to post_modify, since this enables reload_combine_recognize_const_pattern .

Call for testers: improve move2add_use_add2_insn for targets with HAVE_POST_MODIFY_DISP and/or clobber-encumbered add

2019-07-03 Joern Rennecke * postreload.c (rtl-iter.h): Include. (reg_addr_use_luid, reg_addr_use_insn): New static variables. (reg_addr_use, move2add_last_jump_luid): Likewise. (move2add_use_add2_insn): Try to use a POST_MODIFY before and add.

RFA: Fix testsuite/91065

Regression tested running plugin.exp testing gcc configured with --enable-checking=all (failure fixed), --enable-checking=yes, and without --enable-checking (both no change). 2019-07-02 Joern Rennecke PR testsuite/91065 * testsuite/gcc.dg/plugin/start_unit_plugin.c: Register

Re: RFA: fix PR66726 regression for min/max/conversion combo from PR71016 patch

[Apologies if this is a duplicate, I'm unsure if my previous mail was delivered] On 01/07/19 12:38, Richard Biener wrote: On Mon, Jul 1, 2019 at 1:22 PM Joern Wolfgang Rennecke wrote: The heuristic introduced for PR71016 prevents recognizing a max / min combo like it is used for saturation

RFA: fix PR66726 regression for min/max/conversion combo from PR71016 patch

The heuristic introduced for PR71016 prevents recognizing a max / min combo like it is used for saturation when followed by a conversion. The attached patch refines the heuristic to allow this case. Regression tested on x86_64-pc-linux-gnu . Index: tree-ssa-phiopt.c

RFA: Avoid versioning loop with unaligned step

eSi-RISC has vector permute functionality, but no unaligned loads. We see execution failures on gcc.dg/vect/slp-perm-12.c because loop versioning is used to make the tptr aligned for the first loop iteration, and then with a step of originally 11, 22 after vectorization, and a vector alignment

Re: RFA: vectorizer patches 1/2 : WIDEN_MULT_PLUS support

On 14/11/18 09:53, Richard Biener wrote: WIDEN_MULT_PLUS is special on our target in that it creates double-sized vectors. Are there really double-size vectors or does the target simply produce the output in two vectors? Usually targets have WIDEN_MULT_PLUS_LOW/HIGH or _EVEN/ODD split

Re: RFA: vectorizer patches 1/2 : WIDEN_MULT_PLUS support

On 12/11/18 14:30, Richard Biener wrote: I guess I already asked this question when WIDEN_MULT_PLUS_EXPR was introduced - but isn't that fully contained within a DOT_PROD_EXPR? I'm not sure what exactly you mean here. A mailing list search to find that post was unsuccessful. The earliest

RFA: Fix add_predicate_code to acknowledge ZERO_EXTRACT as an lvalue.

With a configurable vector size, it is not really feasible to represent every vector register inside GCC as a collection of lots of imaginary BITS_PER_WORD registers. So you got your general purpose registers that are BITS_PER_WORD, and vector registers that are a bit or a lot larger. To void

RFA: vectorizer patches 2/2: reduction splitting

It's nice to use the processors vector arithmetic to good effect, but it's all for naught when there are too many moves from/to general registers cluttering up the loop. With a double-vector reduction variable, the standard final reduction code got so awkward that the register allocator

RFA: vectorizer patches 1/2 : WIDEN_MULT_PLUS support

Our target (eSi-RISC) doesn't have DOT_PROD_EXPR or WIDEN_SUM_EXPR operations in the standard vector modes; however, it has a vectorized WIDEN_MULT_PLUS_EXPR implementation with a double-vector output, which works just as well, with a little help from the compiler - as implemented in these

RFA: Avoid warning for write_predicate_subfunction generated function

In predicates.md, we have a predicate like this: (define_special_predicate "esirisc_simd_shift_reg_operand" (match_operand 0 "d_register_operand") { /* Earlier revs shifted both halves by the same amount, which is not usable. */ return esirisc_rev_option > 10; }) genpreds generates for

Re: [PATCHv2 0/7] ARC: Add support for nps400 variant

On 03/05/16 11:56, Andrew Burgess wrote: * Claudiu Zissulescu [2016-05-02 09:02:16 +]: Please also consider to address also the following warnings introduced: mainline/gcc/gcc/config/arc/arc.md:888: warning: source missing a mode?

Re: [PATCH] [ARC] Use GOTOFFPC relocation for pc-relative accesses.

On 02/05/16 14:50, Claudiu Zissulescu wrote: This patch makes the pc-relative access to be more safe by using @pcl syntax. This new syntax generates a pc-relative relocation which will be handled by assembler. OK to apply? OK.

Re: [PATCH] [ARC] Add new ARCv2 instructions.

On 29/04/16 15:20, Claudiu Zissulescu wrote: Please find the updated patch. Ok to commit? OK.

Re: [PATCHv2 2/7] gcc/arc: Replace rI constraint with r & Cm2 for ld and update insns

On 29/04/16 12:58, Andrew Burgess wrote: * config/arc/arc.md (*loadqi_update): Replace use of 'rI' constraint with 'rCm2' constraints to limit possible immediate size. (*load_zeroextendqisi_update): Likewise. (*load_signextendqisi_update): Likewise.

Re: [PATCH] [ARC] Handle FPX NaN within optimized floating point library.

On 29/04/16 11:31, Claudiu Zissulescu wrote: It should do the job, at least for EM where the jump takes 2 cycle, and by means of using delay slots we can make all the cycles count. HS has a branch prediction mechanism, hence, filling up the delay slot doesn't have such a big impact like in

Re: [PATCH] [ARC] Handle FPX NaN within optimized floating point library.

P.S.: the .d suffix on the branch was there just for scheduling purposes - not sure if that actually helped any chip's pipeline, or if it was just a bug in the documentation.

Re: [PATCH] [ARC] Handle FPX NaN within optimized floating point library.

On 29/04/16 11:16, Claudiu Zissulescu wrote: This is the updated patch on handling FPX NaNs. Ok to apply? Claudiu OK.

Re: [PATCH] [ARC] Fix unwanted match for sign extend 16-bit constant.

On 28/04/16 21:31, Claudiu Zissulescu wrote: Otherwise, I'd suggest using a traditional integer letter. 'J' is free. Thanks for the suggestion, I will use 'J'. Why do you remove half of the indentation? Unwanted reformatting, sorry for this, I will revert it. I have the feeling you are

Re: [PATCHv2 7/7] gcc/arc: Add an nps400 specific testcase

On 21/04/16 12:39, Andrew Burgess wrote: * gcc.target/arc/nps400-1.c: New file. Thanks. I have applied this patch.

Re: [PATCHv2 6/7] gcc/arc: Mask integer 'L' operands to 32-bit

Thanks. I have applied this patch.

Re: [PATCHv2 5/7] gcc/arc: Add nps400 bitops support

On 21/04/16 12:39, Andrew Burgess wrote: Add support for nps400 bit operation instructions. There's a new flag -mbitops that turns this feature on. There are new instructions, some changes to existing instructions, a new register class to support the new instructions, and some new expand and

Re: [PATCHv2 4/7] gcc/arc: Add support for nps400 cmem xld/xst instructions

Thanks. I have merged this patch.

Re: [PATCH] [ARC] Fix unwanted match for sign extend 16-bit constant.

On 28/04/16 18:10, Claudiu Zissulescu wrote: Please find the updated patch. Claudiu gcc/ 2016-04-28 Claudiu Zissulescu * config/arc/arc.h (UNSIGNED_INT12, UNSIGNED_INT16): Define. * config/arc/arc.md (umulhisi3): Use arc_short_operand predicate.

Re: [PATCHv2 3/7] gcc/arc: convert some constraints to define_constraint

On 21/04/16 12:39, Andrew Burgess wrote: * config/arc/constraints.md (Usd): Convert to define_constraint. (Us<): Likewise. (Us>): Likewise. Thanks. I have allied this patch.

Re: [PATCHv2 1/7] gcc/arc: Add support for nps400 cpu type.

On 21/04/16 12:39, Andrew Burgess wrote: The nps400 is an arc700 with a set of extension instructions produced by Mellanox (formally EZChip). This commit adds support for the nps400 architecture to the arc backend. After this commit it is possible to compile using -mcpu=nps400 in order to

Re: [PATCHv2 2/7] gcc/arc: Replace rI constraint with r & Cm2 for ld and update insns

On 21/04/16 12:39, Andrew Burgess wrote: * config/arc/arc.md (*loadqi_update): Replace use of 'rI' constraint with separate 'r' and 'Cm2' constraints. Why don't you use simply rCm2 ?

Re: [PATCHv2 0/7] ARC: Add support for nps400 variant

On 28/04/16 16:31, Joern Wolfgang Rennecke wrote: However, setting defaults and multilib sets at gcc configure time is also quite useful, as otherwise every user is confronted with building multilibs for a burgeoning array of variants. P.S.: One way to do this is to add introduce a new macro

Re: [PATCHv2 0/7] ARC: Add support for nps400 variant

On 21/04/16 12:39, Andrew Burgess wrote: This new iteration of the previous version is largely the same except that I now no longer use configure time options to build in support for nps400. Instead support controlled with a -mcpu=nps400 command line switch. This change was made to mirror a

Re: [PATCH] [ARC] Add new ARCv2 instructions.

On 20/04/16 13:12, Claudiu Zissulescu wrote: This patch adds new instruction variants as introduced by the ARCv2 architecture. You have used groups of 8 spaces at line starts; tabs should be used instead for indentation. (arc_dwarf_register_span): Remove enum keyword. That bit

Re: [PATCH 4/6] [ARC] Handle FPX NaN within optimized floating point library.

On 28/04/16 15:11, Claudiu Zissulescu wrote: Sure thing, running for ARC700, using original implementation and enabled guarded code for FPX handling: [0x02a2] 0xc000 K Zld_s r0,[sp,0x0] : lw [0x5000c0c0] => 0x : (w1) r0 <= 0x * [0x02a4]

Re: [PATCH 6/6] [ARC] Various instruction pattern fixes

On 18/04/16 19:25, Claudiu Zissulescu wrote: Forgot to add the reload cases. Here it is the updated patch. //Claudiu gcc/ 2016-04-18 Claudiu Zissulescu * config/arc/arc.md (mulsidi3): Change operand 0 predicate to register_operand.

Re: [PATCH 5/6] [ARC] Fix unwanted match for sign extend 16-bit constant.

On 18/04/16 15:33, Claudiu Zissulescu wrote: The combine pass may conclude umulhisi3_imm pattern can accept also sign extended 16-bit constants. This patch prohibits the combine in considering this pattern as suitable. OK to apply? Claudiu gcc/ 2016-04-18 Claudiu Zissulescu

Re: [PATCH 4/6] [ARC] Handle FPX NaN within optimized floating point library.

On 28/04/16 12:35, Claudiu Zissulescu wrote: Besides, why would you change any of the code, apart from the argument to #ifdef and the comments? It is not working/giving wrong results. I think, the test shows you this if you run it without all the libgcc mods. I can't. Where exactly does

Re: [PATCH 4/6] [ARC] Handle FPX NaN within optimized floating point library.

On 18/04/16 15:33, Claudiu Zissulescu wrote: OK to apply? No. You are clobbering DBL0H. Besides, why would you change any of the code, apart from the argument to #ifdef and the comments?

Re: [PATCH 3/6] [ARC] Pass mfpuda to assembler.

On 18/04/16 15:33, Claudiu Zissulescu wrote: OK to apply? Claudiu gcc/ 2016-04-18 Claudiu Zissulescu * config/arc/arc.h (ASM_SPEC): Pass mfpuda to assembler. OK.

Re: [PATCH 2/6] [ARC] Fix FPX/FPUDA code gen when compiling for big-endian.

On 18/04/16 15:33, Claudiu Zissulescu wrote: OK to apply? Claudiu gcc/ 2016-04-18 Claudiu Zissulescu * config/arc/arc.c (arc_process_double_reg_moves): Fix for big-endian compilation. * config/arc/arc.md (addf3): Likewise. (subdf3):

Re: [PATCH 1/6] [ARC] Don't use drsub* instructions when selecting fpuda.

On 18/04/16 15:33, Claudiu Zissulescu wrote: The double precision floating point assist instructions are not implementing the reverse double subtract instruction (drsub) found in the FPX extension, hence, this patch. OK to apply? Claudiu gcc/ 2016-04-18 Claudiu Zissulescu

Re: [PATCH 2/2] [ARC] Add TLS support.

On 15/04/16 10:58, Claudiu Zissulescu wrote: TLS mods for ARC backend. OK to apply? Claudiu This is using an inefficient TLS global dynamic implementation that would not be expected in a new and/or well-tuned port. However, if you have to work with a legacy runtime, that can't be helped.

Re: [PATCH 1/2] [ARC/LIBGCC] Add TLS support.

On 15/04/16 10:58, Claudiu Zissulescu wrote: TLS mods for libgcc. OK to apply? Claudiu libgcc/ 2016-04-15 Claudiu Zissulescu Joern Rennecke * config/arc/crttls.S: New file. * config/arc/t-arc: New rule.

Re: [Patch] Fix PR 60040

On 28/04/16 07:57, Senthil Kumar Selvaraj wrote: diff --git libcilkrts/ChangeLog libcilkrts/ChangeLog index 8fada8a..ed26a3a 100644 --- libcilkrts/ChangeLog +++ libcilkrts/ChangeLog @@ -1,9 +1,3 @@ -2016-04-26 Rainer Orth - - PR target/60290 - *

Re: [PATCH] [ARC] Add SIMD extensions for ARC HS

On 08/04/16 09:30, Claudiu Zissulescu wrote: This patch adds support for the new SIMD operations added to ARC HS cpu class. The proposed patch doesn't chase for performance but offers support for those newly added operations, and autovectorization. The patch is tested using dg.exp,

Re: [PATCH] [ARC] Add single/double IEEE precission FPU support.

On 10/02/16 13:31, Claudiu Zissulescu wrote: Please find attached the amended patch for FPU instructions. Ok to apply? +(define_insn "*cmpdf_fpu" I'm wondering - could you compare with +zero using a literal (adding an alternative)? (No need to hold up the main patch, but you can consider

Re: [PATCH] [ARC] Add single/double IEEE precission FPU support.

On 09/02/16 15:34, Claudiu Zissulescu wrote: Most of the cases checking only the CC user may be sufficient. However, there are cases (only one which I found), where the CC user has a different mode than of the CC setter. This is happening when running gcc.dg/pr56424.c test. Here, the C_FPU

Re: [PATCH] [ARC] Add single/double IEEE precission FPU support.

P.S.: if code that is missing prototypes for stdarg functions is of no concern, there is another ABI alternative that might give good code density for architectures like ARC that have pre-decrement addressing modes and allow immediates to be pushed: You could put all unnamed arguments on the

Re: [PATCH] [ARC] Add single/double IEEE precission FPU support.

On 03/02/16 15:02, Claudiu Zissulescu wrote: First, I will split this patch in two. The first part will deal with the FPU instructions. The second patch, will try to address a new abi optimized for odd-even registers as the comments for the mabi=optimized are numerous and I need to

Re: [PATCH] [ARC] Add single/double IEEE precission FPU support.

On 01/02/16 13:57, Claudiu Zissulescu wrote: In this patch, we add support for the new FPU instructions available with ARC V2 processors. The new FPU instructions covers both single and double precision IEEE formats. While the single precision is available for both ARC EM and ARC HS

Re: [PATCH 0/2] [ARC] Small fixes

On 25/01/16 13:33, Claudiu Zissulescu wrote: Please find attached two small patches which are fixing two issues within the ARC backend: 1. The first one fixes predicates used by arcset* patterns. 2. The second one rejects constant-constant comparisons. This situation may happen durring CSE

Re: [PATCH] [ARC] Add basic support for double load and store instructions

On 22/01/16 11:59, Claudiu Zissulescu wrote: Thank u for the feedback. I hope this new patch solves the outstanding issues. Please find it attached. This is OK.

Re: [PATCH] [ARC] Add basic support for double load and store instructions

On 19/01/16 17:46, Claudiu Zissulescu wrote: > Hi, > > I've prepared a new patch based on the received review (attached). I also added a mod on invoke.texi regarding mll64 documentation. This mod was missing in the first patch. > > I have tested it with dg.exp for arc700, archs and

Re: [PATCH] [ARC] Add basic support for double load and store instructions

On 15/01/16 12:40, Claudiu Zissulescu wrote: (arc_save_restore): Use double load/store instruction. (arc_expand_movmem): Likewise. >if (n_pieces >= (unsigned int) (optimize_size ? 3 : 15)) > return false; > - if (piece > 4) > + if (TARGET_LL64 && (piece != 8) &&

Re: [PATCH] arc/gcc: Fix help text for some options.

On 08/01/16 14:13, Andrew Burgess wrote: * config/arc/arc.opt (mdiv-rem): Add period to the end. (mcode-density): Likewise. Thanks, I have applied this patch.

Re: [PATCH 2/4] gcc/arc: Remove load_update_operand predicate

On 18/12/15 12:52, Andrew Burgess wrote: gcc/ChangeLog: * config/arc/arc.md (*loadqi_update): Use new 'any_mem_operand' and fix RTL pattern to include the plus. (*load_zeroextendqisi_update): Likewise. (*load_signextendqisi_update): Likewise.

Re: [PATCH 3/4] gcc/arc: Remove store_update_operand predicate

On 18/12/15 12:53, Andrew Burgess wrote: * config/arc/arc.md (*storeqi_update): Use 'memory_operand' and fix RTL pattern to include the plus. (*storehi_update): Likewise. (*storesi_update): Likewise. (*storesf_update): Likewise. *

Re: [PATCH 1/4] gcc/arc: Fix warning in test

On 16/12/15 00:15, Andrew Burgess wrote: Missing function declaration causes a warning, that results in test failure. Ah, this test was affected when the default language was changed to gnu11 in October last year. gcc/testsuite/ChangeLog: * gcc.target/arc/jump-around-jump.c

Re: [PATCH 0/4] [ARC] Collection Of Bug Fixes

On 16/12/15 00:15, Andrew Burgess wrote: This is a collection of 4 bug fix patches for arc. All 4 patches are really stand-alone, I've only grouped them together as they all only effect arc. Note for future postings: ChangeLog entries are supposed to appear as plain text, not as diff.

Re: [PATCH 2/4] gcc/arc: Remove load_update_operand predicate

On 16/12/15 00:15, Andrew Burgess wrote: * config/arc/arc.md (*loadqi_update): Use 'memory_operand' and fix RTL pattern to include the plus. (*load_zeroextendqisi_update): Likewise. (*load_signextendqisi_update): Likewise. (*loadhi_update): Likewise.

Re: [PATCH][ARC] Refurbish and extend builtin function support for ARC

On 17/12/15 09:31, Claudiu Zissulescu wrote: Please find a new patch that refurbishes and extends the builtin function support for ARC. I also added a number of builtins for ARCv2 architecture, and a number of tests. Ok to commit? gcc/ 2015-12-14 Claudiu Zissulescu

Re: [PATCH 4/4] gcc/arc: Avoid JUMP_LABEL_AS_INSN for possible return jumps

On 16/12/15 00:15, Andrew Burgess wrote: gcc/ChangeLog: * config/arc/arc.c (arc_loop_hazard): Don't convert the jump label rtx to an rtx_insn until we confirm it's not a return rtx. gcc/testsuite/ChangeLog: * gcc.target/arc/loop-hazard-1.c: New file. Thanks,

Re: [PATCH][ARC] Refurbish emitting DWARF2 for epilogue.

On 11/12/15 10:29, Claudiu Zissulescu wrote: I did some testing here. For size, I used CSiBE testbench, and for speed, I used coremark and dhrystone. Using a blockage or not, doesn't affect the size or speed figures. However, using TARGET_NO_SPECULATION_IN_DELAY_SLOTS_P hook betters the

Re: [PATCH][ARC] Refurbish emitting DWARF2 for epilogue.

On 09/12/15 15:34, Claudiu Zissulescu wrote: Well, it seems to me that we prefer to disable optimizations when talking about debug related information (see PR target/60598 git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@208749 138bc75d-0d04-0410-961f-82ee72b054a4 commit). Actually, unwind

Re: [PATCH][ARC] Refurbish emitting DWARF2 for epilogue.

On 09/12/15 04:43, Joern Wolfgang Rennecke wrote: You can also consider having separate options to control optimizations that affect debugging. If leaving out epilogue cfi is what it takes to allow epilogue scheduling without the compiler crashing, then that is what should be done

Re: [PATCH][ARC] Refurbish emitting DWARF2 for epilogue.

On 07/12/15 09:19, Claudiu Zissulescu wrote: Hi Joern, + insn = emit_insn (gen_blockage ()); Is this actually part of the patch to fix cfi generation? This instruction prevents the delay branch scheduler to speculatively use epilogue instructions to fill up the delay slots. Hence,

Re: [PATCH] [ARC] Add support for atomic memory built-in.

On 07/12/15 13:25, Claudiu Zissulescu wrote: Tested with dg.exp (when passing -matomic to gcc compiler line, the atomic tests are also successfully executed). The comment before "*memory_barrier" could use some elaboration on what it does for TARGET_HS. Otherwise, this is OK.

Re: [PATCH][ARC] Refurbish emitting DWARF2 for epilogue.

On 27/11/15 13:53, Claudiu Zissulescu wrote: @@ -2502,11 +2540,18 @@ arc_expand_epilogue (int sibcall_p) /* Restore any saved registers. */ if (frame_pointer_needed) { - rtx addr = gen_rtx_POST_INC (Pmode, stack_pointer_rtx); + insn = emit_insn (gen_blockage ());

Re: [PATCH] [ARC] Add support for atomic memory built-in.

On 16/11/15 10:18, Claudiu Zissulescu wrote: +/* Expand code to perform a 8 or 16-bit compare and swap by doing + 32-bit compare and swap on the word containing the byte or + half-word. The difference between a weak and a strong CAS is that + the weak version may simply fail. The

Re: [PATCH][GCC] Make stackalign test LTO proof

I just happened to stumble on this problem with another port. The volatile & test solution doesn't work, though. What does work, however, is: __asm__ ("" : : "" (dummy));

Re: [PATCH][ARC] Fix ARC backend ICE on pr29921-2

On 11/11/15 15:22, Claudiu Zissulescu wrote: Please find attached a patch that fixes the ARC backend ICE on pr29921-2 test from gcc.dg (dg.exp). The patch will allow generating conditional move also outside expand scope. The error was triggered during if-conversion. Ok to apply? OK.

Re: [PATCH 2/2][ARC] Add support for ARCv2 CPUs

On 30/10/15 11:22, Claudiu Zissulescu wrote: Hi, Please find the updated patch. Both ARC patches were tested using dg.exp. The ChangeLog entry is unchanged. This is OK.

Re: [PATCH 1/2][ARC] Add support for ARCv2 CPUs

On 30/10/15 11:19, Claudiu Zissulescu wrote: Hi, Please find the updated patch. I will defer the secondary reload optimization which will use the ld instructions with LIMM, for the time being. Apart from the gen_compare_reg change, the patch is OK. If the v2 support mostly works like

Committed: Fix PR libgcc/66883

2015-10-23 Joern Rennecke PR libgcc/66883 * config/epiphany/udivsi3-float.c: Fix CONCISE test, and comment typo. Index: config/epiphany/udivsi3-float.c === --- config/epiphany/udivsi3-float.c

Re: [PATCH 1/2][ARC] Add support for ARCv2 CPUs

On 30/09/15 11:42, Claudiu Zissulescu wrote: This patch adds basic support for Synopsys' ARCv2 CPUs. There is an awful lot of places that have TARGET_ARC700 || TARGET_V2 etc. Maybe it's time for some new feature-oriented macros? Like: TARGET_ARC600_FAMILY ARC600 and ARC601, for ARC600

Re: [PATCH 2/2][ARC] Add support for ARCv2 CPUs

* config/arc/gmon/profil.S (__profil, __profil_irq): Don't profile Shouldn't profil should return -1 on failure? config/arc/lib1funcs.S (__udivmodsi4): @@ -393,7 +393,12 @@ SYM(__udivmodsi4): lsr_s r1,r1 cmp_s r0,r1 xor.f r2,lp_count,31 +#if !defined (__EM__) &&

Re: ARC length attribute patch

On 23/03/15 09:02, Claudiu Zissulescu wrote: Hi Joern, I have a small patch for ARC backend that fixes the value of instruction length attribute when the instruction is predicated. Ok to apply? Why would the arc_bdr_iscond test have any effect? arc_predicate_delay_insns should render the

Re: [ARC] Cleanup A5 references

On 20/08/15 12:42, Claudiu Zissulescu wrote: This patch cleans up the references to obsolete A5 processor. Can this be committed? Thanks, Claudiu 2015-08-20 Claudiu Zissulescu * common/config/arc/arc-common.c, config/arc/arc-opts.h,

Re: ARC length attribute patch

On 23/03/15 11:22, Joern Wolfgang Rennecke wrote: On 20/03/15 16:02, Claudiu Zissulescu wrote: Hi Joern, I have a small patch for ARC backend that fixes the value of instruction length attribute when the instruction is predicated. Ok to apply? Assuming you tested it, this patch is OK

Committed: update my email address

2015-03-03 Joern Rennecke g...@amylaar.uk * MAINTAINERS (CPU Port Maintainers): Update my email address. 2015-03-03 Joern Rennecke g...@amylaar.uk * MAINTAINERS (CPU Port Maintainers): Update my email address. Index: MAINTAINERS