while reading the register_ssa_partition.
Attached patch just changes it to verify_ssa_for_coalesce to better
reflect what it is doing now.
Bootstrap and regression testing is ongoing. Is this OK for trunk if no
regressions?
Thanks,
Kugan
gcc/ChangeLog:
2016-11-08 Kugan Vivekanandarajah
Hi,
On 04/11/16 03:24, Martin Jambor wrote:
Hi,
On Fri, Oct 28, 2016 at 01:58:13PM +1100, kugan wrote:
Do I understand it correctly that extract_range_from_unary_expr deals
with any potential type conversions better (compared to what you did
before here)?
Yes, this can be wrong at times too
Hi,
On 04/11/16 04:36, Martin Jambor wrote:
Hi,
On Fri, Oct 28, 2016 at 02:03:47PM +1100, kugan wrote:
...snip...
I have also separated the constant parameter conversion out and posted as
https://gcc.gnu.org/ml/gcc-patches/2016-10/msg02309.html. This is now
handling just unary pass-through
e --enable-languages=c,c++,fortran,go
--disable-werror --with-sysroot=/ --enable-plugins
--enable-gnu-indirect-function
I have not tried removing the +lse part though
Sorry about the breakage. I will try to reproduce this.
Thanks,
Kugan
Hi Andrew,
On 10/11/16 17:14, Andrew Pinski wrote:
On Wed, Nov 9, 2016 at 12:01 AM, kugan
wrote:
Hi Andrew,
On 09/11/16 17:02, Andrew Pinski wrote:
Either this patch or the patch for "Handle unary pass-through jump
functions for ipa-vrp" caused a bootstrap failure on
aarch64
Hi David,
Sorry about the breakage. I have already reverted this patch as this is
causing bootstrap failures. I will test it on more targets before
submitting this patch again.
Thanks,
Kugan
On 11/11/16 00:25, David Edelsohn wrote:
Kugan
Is there a PR for this failure? It broke bootstrap
affected targets
aarch64-none-linux-gnu and powerpc64le-unknown-linux-gnu. I also tested
it on x86_64-linux-gnu with no new regressions. Is this OK?
Thanks,
Kugan
gcc/testsuite/ChangeLog:
2016-11-13 Kugan Vivekanandarajah
* g++.dg/torture/pr78268.C: New test.
gcc/ChangeLog:
2
Hi Richard,
On 08/11/16 23:45, Richard Biener wrote:
On Tue, Nov 8, 2016 at 3:32 AM, kugan wrote:
Hi,
In tree-ssa-coalesce, register_ssa_partition ) and
register_ssa_partition_check have lost their meaning over various commits
and now just verifies that ssa_var is indeed a SSA_NAME and not a
trunk?
Thanks,
Kugan
gcc/testsuite/ChangeLog:
2016-11-18 Kugan Vivekanandarajah
PR IPA/78365
* gcc.dg/torture/pr78365.c: New test.
gcc/ChangeLog:
2016-11-18 Kugan Vivekanandarajah
PR IPA/78365
* ipa-cp.c (propagate_constants_accross_call): get param type
EGNUM);
Thanks,
Kugan
Hi,
On 24/11/16 19:48, Richard Biener wrote:
On Wed, Nov 23, 2016 at 4:33 PM, Martin Jambor wrote:
Hi,
On Fri, Nov 18, 2016 at 12:38:18PM +1100, kugan wrote:
Hi,
I was relying on ipa_get_callee_param_type to get type of parameter and thenHi,
convert arguments to this type while computing
call copy_to_mode_reg instead, like
arm_expand_binop_builtin does. Attached patch does this. Regression
tested on arm-none-linux-gnu with no new regression. Is this OK for trunk?
Thanks,
Kugan
gcc/ChangeLog:
2016-01-08 Kugan Vivekanandarajah
Jim Wilson
PR target/69194
; The original testcase failed with linaro gcc 4.9. I verified that
>> this testcase fails with FSF gcc-5.3.0.
>
> Looks much better. I'll defer to ARM maintainers to ack this.
Thanks for the review. Please find the patch with the required changes.
Regression tested with
regression. I also
bootstrapped regression tested (on an earlier version of trunk) for
x86_64-none-linux-gnu with no new regressions. If this OK, I will do a
full testing again. Comments?
Thanks,
Kugan
gcc/ChangeLog:
2016-01-12 Kugan Vivekanandarajah
* expr.c (expand_expr_real_1
On 13/01/16 10:19, Jim Wilson wrote:
> On Mon, Jan 11, 2016 at 10:22 PM, kugan
> wrote:
>> When promote_function_mode and promote_ssa_mode changes the sign
>> differently, following is the cause for the problem in PR67714.
>
>> This is similar to PR65932 where
(which does the inter
basic block range test optimization) accordingly.
Bootstrapped and regression tested on x86_64-none-linux-gnu with no new
regressions. And also regression tested on arm-none-linux-gnu and
aarch64-none-linux-gnu with no new regressions.
Is this Ok for trunk?
Thanks,
Kugan
gcc
Hi,
lto.texi has "Currently, the linker plugin works only in combination
with the Gold linker, but a GNU ld implementation is under development".
I don't think this is true any more. Attached patch removes this. is
this OK for trunk?
Thanks,
Kugan
gcc/ChangeLog:
20
performance than without the patch.
Is this patch ok for trunk?
Thanks,
Kugan
ype.
This change improve the geomean of spec2k int benchmark with ref by
about ~3.5% on an arm chromebook.
Tested on X86_64 and ARM.
I would like review comments on this.
Thanks,
Kugan
2013-05-09 Kugan Vivekanandarajah
* gcc/gimple.h (gimple_is_exp_fit_lhs, gimple_set_exp_fit_lhs): Ne
On 14/05/13 00:24, Chung-Lin Tang wrote:
On 13/5/13 11:15 AM, Kugan wrote:
Hi,
Ping this patch by Chung-Lin.
http://gcc.gnu.org/ml/gcc-patches/2011-05/msg01179.html
This patch allows lr registers to be used in leaf functions for ARM.
There were some concerns about performance regression in
On 14/05/13 19:18, Ramana Radhakrishnan wrote:
On 05/13/13 04:15, Kugan wrote:
Hi,
Ping this patch by Chung-Lin.
http://gcc.gnu.org/ml/gcc-patches/2011-05/msg01179.html
This patch allows lr registers to be used in leaf functions for ARM.
There were some concerns about performance regression
On 13/05/13 17:47, Richard Biener wrote:
On Mon, May 13, 2013 at 5:45 AM, Kugan
wrote:
Hi,
This patch removes some of the redundant sign/zero
extensions using value ranges informations generated by VRP.
When GIMPLE_ASSIGN stmts with LHS type smaller than word is expanded to
rtl, if we can
.html and addresses
the review comments of Richard Biener.
Tested on X86_64 and ARM.
I would like review comments on this.
Thanks,
Kugan
+2013-06-03 Kugan Vivekanandarajah
+
+ * gcc/gcc/tree-flow.h: Declared structure range_info_def and function
+ definition for
along with expansion improve the geomean of spec2k int
benchmark with ref by about ~3.5% on an arm chromebook.
Tested on X86_64 and ARM.
I would like review comments on this.
Thanks,
Kugan
+2013-06-03 Kugan Vivekanandarajah
+
+ * gcc/dojump.c (do_compare_and_jump): generates rtl wi
== Progress ==
* VRP based zero/sign extension
- Tested and posted the latest patch
* Better end of loop counter optimisation
- Tree level optimization are optimized in mainline
- Christophe noted a slight change in asm generated from earlier version
- tracked down the patch causing this
Apologies for sending again. Corrected wrong dates in subject now.
On 03/06/13 12:19, Kugan wrote:
== Progress ==
* VRP based zero/sign extension
- Tested and posted the latest patch
* Better end of loop counter optimisation
- Tree level optimization are optimized in mainline
On 08/09/14 19:48, Richard Biener wrote:
> On Sun, Sep 7, 2014 at 11:50 AM, Kugan
> wrote:
>> On 05/09/14 19:50, Richard Biener wrote:
>>
>>> Well - the best way would be to expose the target specifics to GIMPLE
>>> at some point in the optimization pi
?
Thanks,
Kugan
gcc/ChangeLog:
2014-09-23 Kugan Vivekanandarajah
* config/aarch64/aarch64.h (EPILOGUE_USES): Return true only after
epilogue_completed is true.
diff --git a/gcc/config/aarch64/aarch64.h b/gcc/config/aarch64/aarch64.h
index db950da..b3e4585 100644
--- a/gcc/config
On 23/09/14 01:58, Jiong Wang wrote:
> On 22/09/14 16:43, Kugan wrote:
>
>> AArch64 has the same issue ARM had where the LR register was not used in
>> leaf functions. This was reported in
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42017. In AArch64, this
>> t
On 01/10/14 01:00, Jiong Wang wrote:
> On 27/09/14 22:20, Kugan wrote:
>>
>> On 23/09/14 01:58, Jiong Wang wrote:
>>> On 22/09/14 16:43, Kugan wrote:
>>>
>>>> AArch64 has the same issue ARM had where the LR register was not
>>>> use
Can you please help to review this patch? Richard reviewed the original
patch and asked it to be split into two parts. Also, he wanted a review
from RTL maintainer for the RTL changes.
Thanks,
Kugan
On 03/06/13 11:43, Kugan wrote:
Hi,
This patch adds value range information to tree SSA_NAME
Can you please help to review this patch? Richard reviewed the original
patch and asked it to be split into two parts. Also, he wanted a review
from RTL maintainers for the RTL changes.
Thanks,
Kugan
On 03/06/13 11:46, Kugan wrote:
Hi,
This patch removes some of the redundant sign/zero
Hi Eric,
Can you please help to review the general idea and this patch for zero
sign extension elimination with VRP?
Thanks,
Kugan
On 17/06/13 11:01, Kugan wrote:
Can you please help to review this patch? Richard reviewed the original
patch and asked it to be split into two parts. Also
On 17/06/13 18:33, Richard Biener wrote:
On Mon, 17 Jun 2013, Kugan wrote:
+/* Extract the value range of assigned exprassion for GIMPLE_ASSIGN stmt.
+ If the extracted value range is valid, return true else return
+ false. */
+static bool
+extract_exp_value_range (gimple stmt
Hi Richard,
Here is an attempt to address your earlier review comments. Bootstrapped
and there is no new regression for X86_64 and arm. Thank you very much
for your time.
Thanks,
Kugan
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,25 @@
+2013-08-14 Kugan Vivekanandarajah
g and zero_extend; instead we can generate the
following RTl.
(set (reg:SI 110)
(reg:SI 117)))
Same could be done for other assign statements.
The idea looks interesting. Some remarks:
+2013-06-03 Kugan Vivekanandarajah
+
+ * gcc/dojump.c (do_compare_and_jump): generate
On 24/04/14 23:05, Richard Biener wrote:
> On Wed, Apr 9, 2014 at 10:07 PM, Kugan
> wrote:
>> Value range propagation simplifies convergence in vrp_visit_phi_node by
>> setting minimum to TYPE_MIN when the computed minimum is smaller than
>> the previous minimum. Th
this OK for trunk?
Thanks,
Kugan
gcc/
+2014-04-27 Kugan Vivekanandarajah
+
+ * config/arm/arm.c (TARGET_ATOMIC_ASSIGN_EXPAND_FENV): New define.
+ (arm_builtins) : Add ARM_BUILTIN_LDFPSCR and ARM_BUILTIN_STFPSCR.
+ (bdesc_2arg) : Add description for builtins __builtins_arm_stfpscr
this OK for trunk?
Thanks,
Kugan
gcc/
+2014-04-27 Kugan Vivekanandarajah
+
+ * config/aarch64/aarch64.c (TARGET_ATOMIC_ASSIGN_EXPAND_FENV): New
+ define.
+ * config/aarch64/aarch64-builtins.c (arm_builtins) : Add
+ AARCH64_BUILTIN_LDFPSCR and AARCH64_BUILTIN_STFPSCR
On 28/04/14 21:01, Ramana Radhakrishnan wrote:
> On 04/26/14 11:57, Kugan wrote:
>> Attached patch implements TARGET_ATOMIC_ASSIGN_EXPAND_FENV for AARCH64.
>> With this, atomic test-case gcc.dg/atomic/c11-atomic-exec-5.c now PASS.
>>
>> This implementation
On 28/04/14 20:29, Ramana Radhakrishnan wrote:
> On 04/26/14 11:26, Kugan wrote:
>> Hi,
>>
>> Attached patch implements TARGET_ATOMIC_ASSIGN_EXPAND_FENV for ARM. With
>> this, atomic test-case gcc.dg/atomic/c11-atomic-exec-5.c now PASS.
>>
>> This im
ny
> host. The same comment applies to the AArch64 patch as well.
>
> Instead I suggest names such as ARM_FE_* that won't conflict with the
> host's system headers.
>
Thanks for spotting it. Here is the updated patch that changes it to
ARM_FE_*.
Thanks,
Kugan
gcc/
+2014-
>
> +2014-04-29 Kugan Vivekanandarajah
> +
> + * config/aarch64/aarch64.c (TARGET_ATOMIC_ASSIGN_EXPAND_FENV): New
> + define.
> + * config/aarch64/aarch64-protos.h (aarch64_atomic_assign_expand_fenv):
> + New function declaration.
> + * config/aa
On 02/05/14 20:06, Marcus Shawcroft wrote:
> On 29 April 2014 03:37, Kugan wrote:
>>
>> On 28/04/14 21:01, Ramana Radhakrishnan wrote:
>>> On 04/26/14 11:57, Kugan wrote:
>>>> Attached patch implements TARGET_ATOMIC_ASSIGN_EXPAND_FENV for AARCH64.
>>&g
Ping ?
Thanks,
Kugan
On 02/05/14 22:27, Kugan wrote:
>
>
> On 02/05/14 20:06, Marcus Shawcroft wrote:
>> On 29 April 2014 03:37, Kugan wrote:
>>>
>>> On 28/04/14 21:01, Ramana Radhakrishnan wrote:
>>>> On 04/26/14 11:57,
Ping ?
Thanks,
Kugan
On 02/05/14 19:04, Kugan wrote:
> On 02/05/14 10:15, Joseph S. Myers wrote:
>> It doesn't seem a good idea to me for a host-side GCC file to use the FE_*
>> names for the target's FE_* values; you'd run into problems if that file
>&g
alternate; this might get confused with this.
Attached RFC patch removes it. regression tested for
aarch64-none-linux-gnu on qemu-aarch64 with now new regression. Is this OK ?
Thanks,
Kugan
gcc/
2014-05-14 Kugan Vivekanandarajah
* config/aarch64/aarch64.c (aarch64_regno_regclass
Hi All,
In AArch64 back-end, BASE_REG_CLASS is defined to be POINTER_REGS.
Shouldn’t this be GENERAL_REGS?
Attached RFC patch makes it GENERAL_REGS. Regression tested for
aarch64-none-linux-gnu on qemu-aarch64 with now new regression. Is this OK ?
Thanks,
Kugan
gcc/
2014-05-15 Kugan
a
lot but others regress). I am looking to see if I can make it perform
better overall. Any suggestions welcome.
Attached experimental patch passes regression but 168.wupwise and
187.facerec miscompares now. I am looking at fixing this as well.
Thanks,
Kugan
gcc/
2014-05-22 Kugan
On 24/05/14 00:06, Christophe Lyon wrote:
> Hi,
> Since merge from upstream r209283 (210743 in GCC), my build fails on
> ARM, because rpc/xdr.h is not found.
> Is this expected?
I also have the same issue. I had to build glibc with
--enable-obsolete-rpc to bootstrap now.
Thanks,
Kugan
Ping^2 ?
Thanks,
Kugan
On 12/05/14 09:47, Kugan wrote:
> Ping ?
>
> Thanks,
> Kugan
>
> On 02/05/14 19:04, Kugan wrote:
>> On 02/05/14 10:15, Joseph S. Myers wrote:
>>> It doesn't seem a good idea to me for a host-side GCC file to use the FE_*
>>>
On 22/05/14 01:08, Marcus Shawcroft wrote:
> On 15 May 2014 01:10, Kugan wrote:
>>
>> Hi All,
>>
>> AAarch64 back-end defines GENERAL_REGS and CORE_REGS with the same set
>> of register. Is there any reason why we need this?
>
> Nope an artifact of t
On 22/05/14 22:18, Richard Earnshaw wrote:
> On 22/05/14 00:44, Kugan wrote:
>> Compiling some applications with -mgeneral-regs-only produces better
>> code (runs faster) compared to not using it. The difference here is that
>> when -mgeneral-regs-only is not used, floati
, even when -mno-unaligned-access is enabled,
backend will inform vectorizer that it supports misaligned accesses
via TARGET_VECTORIZE_SUPPORT_VECTOR_MISALIGNMENT.
Attached patch fixes this. Is this OK for trunk?
Thanks,
Kugan
+2014-02-03 Yury Gribov
+Kugan Vivekanandarajah
gt;
> Ok if no regressions.
>
Tested it on qemu for arm-none-linux-gnueabi and there is no new
regressions. I am sorry I didn’t mention it when I posted the patch.
Thanks,
Kugan
On 07/02/14 03:54, Christophe Lyon wrote:
> On 6 February 2014 10:49, Yury Gribov wrote:
>> Kugan wrote:
>>>> Ok if no regressions.
>>>
>>> Tested it on qemu for arm-none-linux-gnueabi and there is no new
>>> regressions. I am sorry I didn't
Hi,
Is there any reason why HFmode is not there in arm_preferred_simd_mode?
NEON does support this.
Cross regression tested for arm-none-linux-gnueabi with qemu and no new
regressions.
Attached patch enables this. Is this OK for stage1.
Thanks,
Kugan
gcc/
+2014-02-14 Kugan Vivekanandarajah
On 14/02/14 11:24, Andrew Pinski wrote:
> On Thu, Feb 13, 2014 at 4:15 PM, Kugan
> wrote:
>> Hi,
>>
>> Is there any reason why HFmode is not there in arm_preferred_simd_mode?
>> NEON does support this.
>
> Most likely because there is no support for Half-fl
On 14/02/14 14:34, Kugan wrote:
>
>
> On 14/02/14 11:24, Andrew Pinski wrote:
>> On Thu, Feb 13, 2014 at 4:15 PM, Kugan
>> wrote:
>>> Hi,
>>>
>>> Is there any reason why HFmode is not there in arm_preferred_simd_mode?
>>> NEON does su
2014-02-17 Kugan Vivekanandarajah
Index: MAINTAINERS
===
--- MAINTAINERS (revision 207819)
+++ MAINTAINERS (working copy)
@@ -551,6 +551,7 @@
David Ung dav...@mips.com
Neil Vachharajani
alignment. Attached patch fixes
these issues.
Regression tested on qemu-aarch64 for aarch64-none-linux-gnu with no new
regressions.
Is this patch OK?
Thanks,
Kugan
gcc/
+2014-02-21 Kugan Vivekanandarajah
+
+ PR target/60034
+ * aarch64/aarch64.c (aarch64_classify_address): Fix ali
On 27/02/14 22:32, Marcus Shawcroft wrote:
> On 21 February 2014 04:24, Kugan wrote:
>
>> Compiling inline asm results in ICE (PR60034). Alignment calculation in
>> aarch64_classify_address for (symbol_ref:DI ("*.LANCHOR4") [flags
>> 0x182])) seems wrong here.
Thanks foe the review and suggestions.
On 10/07/14 22:15, Richard Biener wrote:
> On Mon, Jul 7, 2014 at 8:55 AM, Kugan
> wrote:
[...]
>>
>> For -fwrapv, it is due to how PROMOTE_MODE is defined in arm back-end.
>> In the test-case, a function (which has signed char re
or that might
confuse the readers. I am fixing that as well.
regression tested on qemu for arm-none-linux-gnueabi with no new
regressions.
Please let me know if this is OK?
Thanks,
Kugan
gcc/
2014-057-12 Kugan Vivekanandarajah
* config/arm/arm.c (bdesc_2arg): Fix typo.
On 11/07/14 22:47, Richard Biener wrote:
> On Fri, Jul 11, 2014 at 1:52 PM, Kugan
> wrote:
>> Thanks foe the review and suggestions.
>>
>> On 10/07/14 22:15, Richard Biener wrote:
>>> On Mon, Jul 7, 2014 at 8:55 AM, Kugan
>>> wrote:
>>
>
lang_hooks.types.type_for_mode (lhs_mode, lhs_uns);
min_tree = wide_int_to_tree (rhs_type, min);
max_tree = wide_int_to_tree (rhs_type, max);
/* Check if values lies in-between the type range. */
if (int_fits_type_p (min_tree, lhs_type)
&& int_fits_type_p (max_tree, lhs_type))
return true;
else
return false;
}
Thanks,
Kugan
lhs_mode, lhs_uns);
limit = wide_int::from (TYPE_MAX_VALUE (lhs_type),
TYPE_PRECISION (TREE_TYPE (ssa)), SIGNED);
if (lhs_uns)
/* If min >= 0 then range contains positive values and doesnt need
zero-extension. */
return wi::ge_p (min, 0, rhs_signop);
else
/* If min >= 0 and max <= signed-max-of-type then range doesn't need
sign-extension. */
return wi::ge_p (min, 0, rhs_signop) && wi::le_p (max, limit,
rhs_signop);
}
Thanks,
Kugan
On 02/08/14 02:03, Kugan wrote:
>>>> if (rhs_uns)
>>>>return wi::ge_p (min, 0); // if min >= 0 then range contains positive
>>>> values
>>>> else
>>>>return wi::le_p (max, wi::max_value (TYPE_PRECISION (TREE_TYPE
&g
case with larger mode signed and 'ssa' unsigned will not work.
Therefore larger mode unsigned and 'ssa' signed will be the only case
that we should consider.
However, with PROMOTE_MODE, isnt that we will miss some cases with this.
Thanks,
Kugan
Ping ?
>
>
> gcc/
>
> 2014-03-03 Kugan Vivekanandarajah
>
> PR target/60034
> * aarch64/aarch64.c (aarch64_classify_address): Fix alignment for
> section anchor.
>
>
>
> gcc/testsuite/
>
> 2014-03-03 Kugan
On 12/03/14 20:07, Marcus Shawcroft wrote:
> Hi Kugan
>
>
> On 3 March 2014 21:56, Kugan wrote:
>
>> gcc/
>>
>> 2014-03-03 Kugan Vivekanandarajah
>>
>> PR target/60034
>> * aarch64/aarch64.c (aarch64_classify_ad
nt of the object, if we have a SYMBOL_REF_BLOCK
> then we can get the block alignment irrespective of
> SYMBOL_REF_ANCHOR_P().
Thanks for the explanation. Is the attached patch looks OK ?
Thanks,
Kugan
gcc/
2014-03-25 Kugan Vivekanandarajah
PR target/60034
* aarch64/aa
and converge to the right minimum value.
Attached patch fixes this. Is this OK for stage-1?
Bootstrapped and regression tested on X86_64-unknown-linux-gnu with no
new regressions.
Thanks,
Kugan
gcc/
+2014-04-09 Kugan Vivekanandarajah
+
+ * tree-vrp.c (vrp_visit_phi_node) : Improve va
Ping?
On 10/04/14 06:07, Kugan wrote:
> Value range propagation simplifies convergence in vrp_visit_phi_node by
> setting minimum to TYPE_MIN when the computed minimum is smaller than
> the previous minimum. This can however result in pessimistic value
> ranges in some cases.
>
Hi Richard,
Thanks for the review.
On 28 June 2018 at 21:26, Richard Biener wrote:
> On Wed, Jun 27, 2018 at 7:00 AM Kugan Vivekanandarajah
> wrote:
>>
>> Hi Richard,
>>
>> Thanks for the review.
>>
>> On 25 June 2018 at 20:01, Richard Biener wrote:
&
Hi Jeff,
Thanks for looking into it.
On 6 July 2018 at 08:03, Jeff Law wrote:
> On 06/24/2018 08:41 PM, Kugan Vivekanandarajah wrote:
>> Hi Jeff,
>>
>> Thanks for the comments.
>>
>> On 23 June 2018 at 02:06, Jeff Law wrote:
>>> On 06/22/2018 03:11 A
gressions.
Thanks,
Kugan
gcc/ChangeLog:
2018-07-06 Kugan Vivekanandarajah
* tree-scalar-evolution.c (final_value_replacement_loop): Use
rewrite_to_non_trapping_overflow instead of rewrite_to_defined_overflow.
From 68a4f232f6cde68751f6785059121fe116363886 Mon Sep 17 00:00:00 2001
Fr
Hi Richard,
Thanks for the review.
On 6 July 2018 at 20:17, Richard Biener wrote:
> On Fri, Jul 6, 2018 at 11:45 AM Kugan Vivekanandarajah
> wrote:
>>
>> Hi Richard,
>>
>> > It was rewrite_to_non_trapping_overflow available in tree.h. Thus
>> > f
pcount?
I am testing the attached RFC patch. Is this reasonable?
Thanks,
Kugan
gcc/ChangeLog:
2018-07-10 Kugan Vivekanandarajah
* tree-ssa-loop-niter.c (number_of_iterations_popcount): Check
if libfunc for popcount is available.
diff --git a/gcc/tree-ssa-loop-niter.c b/gcc/tre
On 10 July 2018 at 23:17, Richard Biener wrote:
> On Tue, Jul 10, 2018 at 3:06 PM Kugan Vivekanandarajah
> wrote:
>>
>> Hi,
>>
>> Jeff told me that the recent popcount built-in detection is causing
>> kernel build issues as
>> ERROR: "__popcounts
Hi Andrew,
On 11 July 2018 at 11:19, Andrew Pinski wrote:
> On Tue, Jul 10, 2018 at 6:14 PM Kugan Vivekanandarajah
> wrote:
>>
>> On 10 July 2018 at 23:17, Richard Biener wrote:
>> > On Tue, Jul 10, 2018 at 3:06 PM Kugan Vivekanandarajah
>> > wrote:
>
Hi Andrew,
On 11 July 2018 at 15:43, Andrew Pinski wrote:
> On Tue, Jul 10, 2018 at 6:35 PM Kugan Vivekanandarajah
> wrote:
>>
>> Hi Andrew,
>>
>> On 11 July 2018 at 11:19, Andrew Pinski wrote:
>> > On Tue, Jul 10, 2018 at 6:14 PM Kugan Vivekanandarajah
&
,
Kugan
gcc/ChangeLog:
2018-07-18 Kugan Vivekanandarajah
PR middle-end/86544
* tree-ssa-phiopt.c (cond_removal_in_popcount_pattern): Handle
comparison with EQ_EXPR
in last stmt.
gcc/testsuite/ChangeLog:
2018-07-18 Kugan Vivekanandarajah
PR middle-end/86544
* g++.dg
tions for other libgcc functions IIRC.
>>
>>Can you please Kugan create Linux kernel bug for that? So that
>>discussion
>>can happen?
>
> There's no discussion necessary, libgcc is the core compiler runtime. If you
> choose not to use it you have to provide your own i
Hi Bernhard,
Thanks for the review.
On Tue, 29 Oct 2019 at 08:52, Bernhard Reutner-Fischer
wrote:
>
> On Mon, 28 Oct 2019 11:53:06 +1100
> Kugan Vivekanandarajah wrote:
>
> > On Wed, 23 Oct 2019 at 23:07, Richard Biener
> > wrote:
>
> > > Did you try this
On Wed, 30 Oct 2019 at 03:11, H.J. Lu wrote:
>
> On Sun, Oct 27, 2019 at 6:33 PM Kugan Vivekanandarajah
> wrote:
> >
> > Hi Richard,
> >
> > Thanks for the review.
> >
> > On Wed, 23 Oct 2019 at 23:07, Richard Biener
> > wrote:
Thanks for the reviews.
On Sat, 2 Nov 2019 at 02:49, H.J. Lu wrote:
>
> On Thu, Oct 31, 2019 at 6:33 PM Kugan Vivekanandarajah
> wrote:
> >
> > On Wed, 30 Oct 2019 at 03:11, H.J. Lu wrote:
> > >
> > > On Sun, Oct 27, 2019 at 6:33 PM Kugan Vivekanand
Hi,
Thanks for the review.
On Tue, 5 Nov 2019 at 03:57, H.J. Lu wrote:
>
> On Sun, Nov 3, 2019 at 6:45 PM Kugan Vivekanandarajah
> wrote:
> >
> > Thanks for the reviews.
> >
> >
> > On Sat, 2 Nov 2019 at 02:49, H.J. Lu wrote:
> > >
> > &g
Hi Richard,
Thanks for the review.
On Tue, 5 Nov 2019 at 23:08, Richard Biener wrote:
>
> On Tue, Nov 5, 2019 at 12:17 AM Kugan Vivekanandarajah
> wrote:
> >
> > Hi,
> > Thanks for the review.
> >
> > On Tue, 5 Nov 2019 at 03:57, H.J. Lu wrote:
> >
Pushing to trunk.
Thanks,
Kugan
Signed-off-by: Kugan Vivekanandarajah
2024-07-11 Kugan Vivekanandarajah
* MAINTAINERS: Update my email address.
diff --git a/MAINTAINERS b/MAINTAINERS
index 762b91256c4..d27640708c5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -704,7 +704,7
ee-ssa/absfloat16.c: New test.
Signed-off-by: Kugan Vivekanandarajah
0001-abs-for-half-float.patch
Description: 0001-abs-for-half-float.patch
.
Bootstrapped and regression tested on aarch64-linux-gnu. Is this OK for trunk.
Thanks,
Kugan
PR middle-end/114635
PR 114635
gcc/ChangeLog:
* omp-low.cc (lower_rec_input_clauses): Set INT_MAX
when safelen is not provided instead of using backend
provided
Thanks for the comments.
> On 2 Aug 2024, at 8:36 pm, Richard Biener wrote:
>
> External email: Use caution opening links or attachments
>
>
> On Fri, Aug 2, 2024 at 11:20 AM Kugan Vivekanandarajah
> wrote:
>>
>>
>>
>>> On 1 A
ping? Any feedback.
Thanks,
Kugan
From: Kugan Vivekanandarajah
Sent: Monday, 5 August 2024 3:05 PM
To: Jakub Jelinek
Cc: gcc-patches@gcc.gnu.org ;
richard.guent...@gmail.com ;
richard.sandif...@arm.com
Subject: Re: [PR middle-end/114635] Set OMP safelen
Hi Richard,
> On 20 Aug 2024, at 6:09 pm, Richard Biener wrote:
>
> External email: Use caution opening links or attachments
>
>
> On Fri, Aug 9, 2024 at 2:39 AM Kugan Vivekanandarajah
> wrote:
>>
>> Thanks for the comments.
>>
>>> On 2
Hi Richard,
> On 22 Aug 2024, at 10:34 pm, Richard Biener
> wrote:
>
> External email: Use caution opening links or attachments
>
>
> On Wed, Aug 21, 2024 at 12:08 PM Kugan Vivekanandarajah
> wrote:
>>
>> Hi Richard,
>>
>>> On
Hi Richard,
Thanks for the reply.
> On 27 Aug 2024, at 7:05 pm, Richard Biener wrote:
>
> External email: Use caution opening links or attachments
>
>
> On Tue, Aug 27, 2024 at 8:23 AM Kugan Vivekanandarajah
> wrote:
>>
>> Hi Richard,
>>
>>
f you need a reduced testcase.
Thanks,
Kugan
Thanks Richard.
Created https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115383
Thanks,
Kugan
On Fri, Jun 7, 2024 at 5:51 PM Richard Biener wrote:
>
> On Fri, 7 Jun 2024, Kugan Vivekanandarajah wrote:
>
> > Hi Richard,
> >
> > This seems to have introduced a regres
Revised based on the comment and moved it into existing patterns as.
gcc/ChangeLog:
* match.pd: Extend A CMP 0 ? A : -A into (type)A CMP 0 ? A : -A.
Extend A CMP 0 ? A : -A into (type) A CMP 0 ? A : -A.
gcc/testsuite/ChangeLog:
* gcc.dg/tree-ssa/absfloat16.c: New test.
Signed-off-by: Kugan
301 - 400 of 606 matches
Mail list logo
