bootstrapped on x86_64-pc-linux-gnu.Avoid cfg corruption when using sjlj exceptions where loops are present in the
assign_params emitted code.
2024-08-06 Joern Rennecke
gcc/
* except.cc (sjlj_emit_function_enter):
Set fn_begin_outside_block again if encountering a jump instru
I'm not quite that sure about the general applicability of these, as
these depend somewhat on code size. Although there might be something
we can prove about a minimum frame size for one test or the other at -O0.
I also tried to add
/* { dg-skip-if "memory tight" { !size20plus } { "-O3" } } */
This fixes problems with tests that exceed a data type or the maximum
stack frame size on 16 bit targets. Note: GCC has a limitation that
a stack frame cannot exceed half the address space.
For two tests the decision to modify or skip them seems not so clear-cut;
I choose to modify gcc.dg/pr4789
Just simulating a 32 bit CPU, these test take about a minute, and
simulating a 16 bit target with size-optimized multi-word divide /
modulus functions, it takes way too long, so I made the tests not
run on targets without int32plus unless run_expensive_test is true.
Even for a simulated 32 bit
I also noticed this test always timing out on a simulator.Reduce iteration count for
23_containers/unordered_set/hash_policy/load_factor.cc for !run_expensive_tests
2024-07-19 Joern Rennecke
libstdc++-v3/
* testsuite/23_containers/unordered_set/hash_policy/load_factor.cc:
[!r
In the previous patch to reduce iteration counts, I have overlooked
that, in the inner loop of s176, the array index i+m-j-1
turns negativeat for higher iterations of the middle loop for small m.
m and the iteration end of the middle loop should stay the same.Fix PR testsuite/116271, gcc.dg/vect/
As suggested by Richard Biener in bugzilla.commit b844775283a620b8826adf734ecfc97d820c3611
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/
* g++.dg/vect/pr115278.cc: Ma
As discussed before on gcc@gcc,gnu.org, this patch reduces the iteration
counts of the tsvc tests to avoid timeouts when using simulators.
A few tests needed special attention because they divided "iterations"
by some constant, so putting 10 in there would lead to zero iteration
count, and thus
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 +
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++: D
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 optimizat
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 t
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 t
Bootstrapped and regression tested in gcc version
d6f1cf644c45b76a27b6a6869dedaa030e3c7570 on x86_64 GNU/Linux .
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, &int_mode)
&& GET_MODE_SIZE (int_mode) == 2 * UNITS_PER_WORD
&& optab_hand
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 as an
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
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
ov
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 (vectorizabl
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,
which
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 .
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.
(reload_c
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 a
[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
satur
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
===
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
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 operati
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
it
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 i
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 decided
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 patc
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
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?
mainline/gcc/gcc/config/arc/arc.md:906: warning: source
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.
On 29/04/16 15:20, Claudiu Zissulescu wrote:
Please find the updated patch.
Ok to commit?
OK.
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.
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 E
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.
On 29/04/16 11:16, Claudiu Zissulescu wrote:
This is the updated patch on handling FPX NaNs.
Ok to apply?
Claudiu
OK.
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 h
On 21/04/16 12:39, Andrew Burgess wrote:
* gcc.target/arc/nps400-1.c: New file.
Thanks. I have applied this patch.
Thanks. I have applied this patch.
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
Thanks. I have merged this patch.
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.
(umulhisi3_imm): Up
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.
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 spe
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 ?
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
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 s
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 sh
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] 0
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.
(umulsidi3): Likewise.
(
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
* conf
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 the
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?
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.
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): Likewise.
(muldf3
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
* config
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.
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.
* config.host (arc*-*-elf*, arc*-*-linux*): Add
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
- * Makefile.am (GENERAL_FLAGS): Add -
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, compile.exp
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 it
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
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 st
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 carefully
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 processors
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 s
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.
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 archs+ll64.
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) && (
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.
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.
* config/arc/p
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.
(*loadhi_up
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
...
(VUNSPEC_DE
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, I've
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.
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 (rtc_set
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.
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 size
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 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.
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 by
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, gen
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 stro
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 ());
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));
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.
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.
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 supp
* 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__) && !define
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 pip
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 (revision 229235)
+++ config/epip
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,
config/arc/arc.c, config/arc/arc.h, co
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 iss
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
2015-03-03 Joern Rennecke
* MAINTAINERS (CPU Port Maintainers): Update my email address.
2015-03-03 Joern Rennecke
* MAINTAINERS (CPU Port Maintainers): Update my email address.
Index: MAINTAINERS
===
--- MAINTAINERS
98 matches
Mail list logo