Hi,
The attached patch attempts to fix PR111648.
As mentioned in PR, the issue is when a1 is a multiple of vector
length, we end up creating following encoding in result: { base_elem,
arg[0], arg[1], ... } (assuming S = 1),
where arg is chosen input vector, which is incorrect, since the
encoding or
On Mon, 9 Oct 2023 at 17:05, Richard Sandiford
wrote:
>
> Prathamesh Kulkarni writes:
> > Hi,
> > The attached patch attempts to fix PR111648.
> > As mentioned in PR, the issue is when a1 is a multiple of vector
> > length, we end up creating following encoding in
On Wed, 11 Oct 2023 at 16:42, Prathamesh Kulkarni
wrote:
>
> On Mon, 9 Oct 2023 at 17:05, Richard Sandiford
> wrote:
> >
> > Prathamesh Kulkarni writes:
> > > Hi,
> > > The attached patch attempts to fix PR111648.
> > > As mentioned in
On Wed, 11 Oct 2023 at 16:57, Prathamesh Kulkarni
wrote:
>
> On Wed, 11 Oct 2023 at 16:42, Prathamesh Kulkarni
> wrote:
> >
> > On Mon, 9 Oct 2023 at 17:05, Richard Sandiford
> > wrote:
> > >
> > > Prathamesh Kulkarni writes:
> > > >
On Tue, 17 Oct 2023 at 02:40, Richard Sandiford
wrote:
>
> Prathamesh Kulkarni writes:
> > On Wed, 11 Oct 2023 at 16:57, Prathamesh Kulkarni
> > wrote:
> >>
> >> On Wed, 11 Oct 2023 at 16:42, Prathamesh Kulkarni
> >> wrote:
> >> &
On Wed, 18 Oct 2023 at 23:22, Richard Sandiford
wrote:
>
> Prathamesh Kulkarni writes:
> > On Tue, 17 Oct 2023 at 02:40, Richard Sandiford
> > wrote:
> >> Prathamesh Kulkarni writes:
> >> > diff --git a/gcc/fold-const.cc b/gcc/fold-const.cc
>
Hi,
For the following test-case:
typedef float __attribute__((__vector_size__ (16))) F;
F foo (F a, F b)
{
F v = (F) { 9 };
return __builtin_shufflevector (v, v, 1, 0, 1, 2);
}
Compiling with -O2 results in following ICE:
foo.c: In function ‘foo’:
foo.c:6:10: internal compiler error: in decom
anding of
> the problem.
>
> Prathamesh Kulkarni writes:
> > Hi,
> > For the following test-case:
> >
> > typedef float __attribute__((__vector_size__ (16))) F;
> > F foo (F a, F b)
> > {
> > F v = (F) { 9 };
> > return __builtin_shufflevector (v, v, 1
On Thu, 26 Oct 2023 at 04:09, Richard Sandiford
wrote:
>
> Prathamesh Kulkarni writes:
> > On Wed, 25 Oct 2023 at 02:58, Richard Sandiford
> > wrote:
> >>
> >> Hi,
> >>
> >> Sorry the slow review. I clearly didn't think this through pr
Hi,
The attached patch tries to fix PR92163 by calling
gimple_purge_dead_eh_edges from ifcvt_local_dce if we need eh cleanup.
Does it look OK ?
Thanks,
Prathamesh
2019-10-24 Prathamesh Kulkarni
PR tree-optimization/92163
* tree-if-conv.c (ifcvt_local_dce): Call
On Tue, 22 Oct 2019 at 13:12, Richard Sandiford
wrote:
>
> Prathamesh Kulkarni writes:
> > diff --git a/gcc/tree-vect-stmts.c b/gcc/tree-vect-stmts.c
> > index acdd90784dc..dfd33b142ed 100644
> > --- a/gcc/tree-vect-stmts.c
> > +++ b/gcc/tree-vect-stmt
d on the state
> before the patch wouldn't have been that meaningful. In particular...
>
> Prathamesh Kulkarni writes:
> > diff --git a/gcc/tree-vect-loop.c b/gcc/tree-vect-loop.c
> > index a70d52eb2ca..82814e2c2af 100644
> > --- a/gcc/tree-vect-loop.
On Fri, 25 Oct 2019 at 13:19, Richard Biener wrote:
>
> On Wed, Oct 23, 2019 at 11:45 PM Prathamesh Kulkarni
> wrote:
> >
> > Hi,
> > The attached patch tries to fix PR92163 by calling
> > gimple_purge_dead_eh_edges from ifcvt_local_dce if we need eh cleanup.
On Sun, 27 Oct 2019 at 06:08, Richard Sandiford
wrote:
>
> Prathamesh Kulkarni writes:
> > @@ -10288,6 +10261,23 @@ vectorizable_condition (stmt_vec_info stmt_info,
> > gimple_stmt_iterator *gsi,
> > vect_finish_stmt_generation (
On Mon, 28 Oct 2019 at 07:18, Richard Biener wrote:
>
> On Fri, Oct 25, 2019 at 9:58 PM Prathamesh Kulkarni
> wrote:
> >
> > On Fri, 25 Oct 2019 at 13:19, Richard Biener
> > wrote:
> > >
> > > On Wed, Oct 23, 2019 at 11:45 PM Prathamesh Kulkarni
On Mon, 4 Nov 2019 at 18:37, Christophe Lyon wrote:
>
> On Mon, 28 Oct 2019 at 16:03, Prathamesh Kulkarni
> wrote:
> >
> > On Mon, 28 Oct 2019 at 07:18, Richard Biener
> > wrote:
> > >
> > > On Fri, Oct 25, 2019 at 9:58 PM Prathamesh Kulkarni
>
On Tue, 5 Nov 2019 at 18:36, Christophe Lyon wrote:
>
> On Tue, 5 Nov 2019 at 05:46, Prathamesh Kulkarni
> wrote:
> >
> > On Mon, 4 Nov 2019 at 18:37, Christophe Lyon
> > wrote:
> > >
> > > On Mon, 28 Oct 2019 at 16:03, Prathamesh Kulkarni
> &g
On Wed, 8 Jan 2020 at 15:50, Prathamesh Kulkarni
wrote:
>
> On Tue, 5 Nov 2019 at 17:38, Richard Biener
> wrote:
> >
> > On Tue, Nov 5, 2019 at 12:17 AM Kugan Vivekanandarajah
> > wrote:
> > >
> > > Hi,
> > > Thanks for the review.
&
Hi,
This patch attempts to add returns_arg attribute for c-family
languages. For C++ methods, first arg is assumed to be this pointer,
similar to alloc_size.
I have a couple of doubts:
(a) I am not sure why DECL_ARGUMENTS (decl) in
handle_returns_arg_attribute returns NULL ? My intent was to check
On Mon, 20 Jan 2020 at 15:44, Richard Biener wrote:
>
> On Wed, Jan 8, 2020 at 11:20 AM Prathamesh Kulkarni
> wrote:
> >
> > On Tue, 5 Nov 2019 at 17:38, Richard Biener
> > wrote:
> > >
> > > On Tue, Nov 5, 2019 at 12:17 AM Kugan Vive
On Tue, 21 Jan 2020 at 04:35, Joseph Myers wrote:
>
> On Mon, 20 Jan 2020, Prathamesh Kulkarni wrote:
>
> > Hi,
> > This patch attempts to add returns_arg attribute for c-family
> > languages. For C++ methods, first arg is assumed to be this pointer,
>
> Th
On Mon, 27 Jan 2020 at 17:36, Richard Biener wrote:
>
> On Fri, Jan 24, 2020 at 11:53 PM Joseph Myers wrote:
> >
> > On Fri, 24 Jan 2020, Prathamesh Kulkarni wrote:
> >
> > > The middle-end representation issue of ERF_RETURNS_ARG still remains,
> > > whi
On Tue, 28 Jan 2020 at 17:00, Jakub Jelinek wrote:
>
> On Tue, Jan 28, 2020 at 04:56:59PM +0530, Prathamesh Kulkarni wrote:
> > Thanks for the suggestions. In the attached patch I bumped up value of
> > ERF_RETURNS_ARG_MASK
> > to UINT_MAX >> 2, and use highes
On Tue, 28 Jan 2020 at 17:17, Richard Biener wrote:
>
> On Fri, Jan 24, 2020 at 7:04 AM Prathamesh Kulkarni
> wrote:
> >
> > On Mon, 20 Jan 2020 at 15:44, Richard Biener
> > wrote:
> > >
> > > On Wed, Jan 8, 2020 at 11:20 AM Prathamesh Kulkarni
>
On Wed, 29 Jan 2020 at 14:38, Richard Biener wrote:
>
> On Tue, Jan 28, 2020 at 1:02 PM Jakub Jelinek wrote:
> >
> > On Tue, Jan 28, 2020 at 05:09:36PM +0530, Prathamesh Kulkarni wrote:
> > > On Tue, 28 Jan 2020 at 17:00, Jakub Jelinek wrote:
> > > >
>
On Thu, 30 Jan 2020 at 19:17, Richard Biener wrote:
>
> On Thu, Jan 30, 2020 at 11:49 AM Prathamesh Kulkarni
> wrote:
> >
> > On Wed, 29 Jan 2020 at 14:38, Richard Biener
> > wrote:
> > >
> > > On Tue, Jan 28, 2020 at 1:02 PM Jakub Jelinek wrote:
On Mon, 3 Feb 2020 at 14:41, Prathamesh Kulkarni
wrote:
>
> On Thu, 30 Jan 2020 at 19:17, Richard Biener
> wrote:
> >
> > On Thu, Jan 30, 2020 at 11:49 AM Prathamesh Kulkarni
> > wrote:
> > >
> > > On Wed, 29 Jan 2020 at 14:38, Richard Biener
>
On Thu, 30 Jan 2020 at 19:10, Richard Biener wrote:
>
> On Thu, Jan 30, 2020 at 5:31 AM Prathamesh Kulkarni
> wrote:
> >
> > On Tue, 28 Jan 2020 at 17:17, Richard Biener
> > wrote:
> > >
> > > On Fri, Jan 24, 2020 at 7:04 AM Prathamesh Kulkarni
>
On Mon, 3 Feb 2020 at 14:56, Prathamesh Kulkarni
wrote:
>
> On Mon, 3 Feb 2020 at 14:41, Prathamesh Kulkarni
> wrote:
> >
> > On Thu, 30 Jan 2020 at 19:17, Richard Biener
> > wrote:
> > >
> > > On Thu, Jan 30, 2020 at 11:49 AM Prathamesh Kulkarni
On Tue, 4 Feb 2020 at 19:44, Richard Biener wrote:
>
> On Mon, Feb 3, 2020 at 12:37 PM Prathamesh Kulkarni
> wrote:
> >
> > On Thu, 30 Jan 2020 at 19:10, Richard Biener
> > wrote:
> > >
> > > On Thu, Jan 30, 2020 at 5:31 AM Prathamesh Kulkarni
>
On Thu, 6 Feb 2020 at 18:42, Richard Biener wrote:
>
> On Thu, Feb 6, 2020 at 1:48 PM Prathamesh Kulkarni
> wrote:
> >
> > On Tue, 4 Feb 2020 at 19:44, Richard Biener
> > wrote:
> > >
> > > On Mon, Feb 3, 2020 at 12:37 PM Prathamesh Kulkarni
> &g
On Tue, 4 Feb 2020 at 14:54, Prathamesh Kulkarni
wrote:
>
> On Mon, 3 Feb 2020 at 14:56, Prathamesh Kulkarni
> wrote:
> >
> > On Mon, 3 Feb 2020 at 14:41, Prathamesh Kulkarni
> > wrote:
> > >
> > > On Thu, 30 Jan 2020 at 19:17, Richard Biener
>
On Thu, 6 Feb 2020 at 20:03, Prathamesh Kulkarni
wrote:
>
> On Thu, 6 Feb 2020 at 18:42, Richard Biener
> wrote:
> >
> > On Thu, Feb 6, 2020 at 1:48 PM Prathamesh Kulkarni
> > wrote:
> > >
> > > On Tue, 4 Feb 2020 at 19:44, Richard Biener
> &
On Fri, 29 Nov 2019 at 15:41, Richard Biener wrote:
>
> On Fri, Nov 22, 2019 at 12:40 PM Prathamesh Kulkarni
> wrote:
> >
> > On Wed, 20 Nov 2019 at 16:54, Richard Biener wrote:
> > >
> > > On Wed, 20 Nov 2019, Richard Sandiford wrote:
> > >
&
On Thu, 5 Dec 2019 at 18:17, Richard Biener wrote:
>
> On Thu, 5 Dec 2019, Prathamesh Kulkarni wrote:
>
> > On Fri, 29 Nov 2019 at 15:41, Richard Biener
> > wrote:
> > >
> > > On Fri, Nov 22, 2019 at 12:40 PM Prathamesh Kulkarni
> > > wro
On Tue, 5 Nov 2019 at 17:38, 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:
> > >
> > > On Sun, Nov 3, 2019 at 6:45 PM Kugan Vivekanandarajah
> > > wrote:
> > >
On Fri, 2 Feb 2024 at 14:44, Andi Kleen wrote:
>
> Mostly adopted from the existing C musttail plugin tests.
>
> gcc/testsuite/ChangeLog:
>
> * c-c++-common/musttail1.c: New test.
> * c-c++-common/musttail2.c: New test.
> * c-c++-common/musttail3.c: New test.
> * c-
Hi,
The test passes -mlittle-endian option but doesn't have target check
for aarch64_little_endian and thus fails to compile on
aarch64_be-linux-gnu. The patch adds the missing aarch64_little_endian
target check, which makes it unsupported on the target.
OK to commit ?
Thanks,
Prathamesh
PR112950:
On Sat, 27 Jan 2024 at 21:19, Richard Sandiford
wrote:
>
> Prathamesh Kulkarni writes:
> > Hi,
> > The test passes -mlittle-endian option but doesn't have target check
> > for aarch64_little_endian and thus fails to compile on
> > aarch64_be-li
On Tue, 30 Jan 2024 at 20:13, Richard Ball wrote:
>
> Adds a check to ensure that the input vector arguments
> to a function are not variable length. Previously, only the
> output vector of a function was checked.
Hi,
Quoting from patch:
@@ -8989,6 +8989,14 @@ vectorizable_slp_permutation_1 (vec_i
On Wed, 31 Jan 2024 at 07:49, Andi Kleen wrote:
>
> Mostly adopted from the existing C musttail plugin tests.
> ---
> gcc/testsuite/c-c++-common/musttail1.c | 17
> gcc/testsuite/c-c++-common/musttail2.c | 36 +
> gcc/testsuite/c-c++-common/musttail3.c | 31
On Mon, 4 Dec 2023 at 14:44, Prathamesh Kulkarni
wrote:
>
> On Thu, 23 Nov 2023 at 17:06, Prathamesh Kulkarni
> wrote:
> >
> > Hi Richard,
> > For the test-case mentioned in PR111702, compiling with -O2
> > -frounding-math -fstack-protector-all results in f
On Thu, 21 Dec 2023 at 00:00, Richard Sandiford
wrote:
>
> If cse sees:
>
> (set (reg R) (const_vector [A B ...]))
>
> it creates fake sets of the form:
>
> (set R[0] A)
> (set R[1] B)
> ...
>
> (with R[n] replaced by appropriate rtl) and then adds them to the tables
> in the same way as f
On Thu, 23 Nov 2023 at 17:06, Prathamesh Kulkarni
wrote:
>
> Hi Richard,
> For the test-case mentioned in PR111702, compiling with -O2
> -frounding-math -fstack-protector-all results in following ICE during
> cse2 pass:
>
> test.c: In function 'foo':
> test.c:
On Tue, 5 Dec 2023 at 06:18, Marek Polacek wrote:
>
> On Mon, Dec 04, 2023 at 04:49:29PM -0500, Jason Merrill wrote:
> > On 12/4/23 15:23, Marek Polacek wrote:
> > > +/* FN is not a consteval function, but may become one. Remember to
> > > + escalate it after all pending templates have been ins
On Mon, 20 Nov 2023 at 15:28, Florian Weimer wrote:
>
> The change to build_conditional_expr drops the downgrade
> from a pedwarn to warning for builtins for C99 and later
> language dialects. It remains a warning in C89 mode (not
> a permerror), as the -std=gnu89 -fno-permissive test shows.
Hi F
On Thu, 9 Nov 2023 at 19:44, Victor Do Nascimento
wrote:
>
> Create the necessary mappings from the ACLE-defined Neon intrinsics
> names[1] to the internal builtin function names.
>
> [1] https://arm-software.github.io/acle/neon_intrinsics/advsimd.html
Hi Victor,
It seems this patch broke kernel b
On Thu, 26 Oct 2023 at 09:43, Prathamesh Kulkarni
wrote:
>
> On Thu, 26 Oct 2023 at 04:09, Richard Sandiford
> wrote:
> >
> > Prathamesh Kulkarni writes:
> > > On Wed, 25 Oct 2023 at 02:58, Richard Sandiford
> > > wrote:
> > >>
> > >
On Thu, 5 Oct 2023 at 00:00, Brendan Shanks wrote:
>
> Hi,
>
> This patch implements pex_unix_exec_child using posix_spawn when
> available.
>
> This should especially benefit recent macOS (where vfork just calls
> fork), but should have equivalent or faster performance on all
> platforms.
> In ad
On Mon, 6 Nov 2023 at 15:50, Tamar Christina wrote:
>
> Hi All,
>
> This patch transforms fneg (fabs (x)) into copysign (x, -1) which is more
> canonical and allows a target to expand this sequence efficiently. Such
> sequences are common in scientific code working with gradients.
>
> There is an
On Wed, 8 Nov 2023 at 21:57, Prathamesh Kulkarni
wrote:
>
> On Thu, 26 Oct 2023 at 09:43, Prathamesh Kulkarni
> wrote:
> >
> > On Thu, 26 Oct 2023 at 04:09, Richard Sandiford
> > wrote:
> > >
> > > Prathamesh Kulkarni writes:
> >
Hi Richard,
For the test-case mentioned in PR111702, compiling with -O2
-frounding-math -fstack-protector-all results in following ICE during
cse2 pass:
test.c: In function 'foo':
test.c:119:1: internal compiler error: in insert_regs, at cse.cc:1120
119 | }
| ^
0xb7ebb0 insert_regs
On Wed, 15 Nov 2023 at 20:44, Prathamesh Kulkarni
wrote:
>
> On Wed, 8 Nov 2023 at 21:57, Prathamesh Kulkarni
> wrote:
> >
> > On Thu, 26 Oct 2023 at 09:43, Prathamesh Kulkarni
> > wrote:
> > >
> > > On Thu, 26 Oct 2023 at 04:09, Richard Sandi
On Fri, 24 Nov 2023 at 03:13, Richard Sandiford
wrote:
>
> Prathamesh Kulkarni writes:
> > On Thu, 26 Oct 2023 at 09:43, Prathamesh Kulkarni
> > wrote:
> >>
> >> On Thu, 26 Oct 2023 at 04:09, Richard Sandiford
> >> wrote:
> >> >
> &g
Pushing to trunk.
Signed-off-by: Prathamesh Kulkarni
Thanks,
Prathamesh
Sorry, forgot to attach diff.
-Original Message-
From: Prathamesh Kulkarni
Sent: Wednesday, July 3, 2024 7:04 PM
To: gcc-patches@gcc.gnu.org
Subject: [MAINTAINERS] Update my email address
External email: Use caution opening links or attachments
Pushing to trunk.
Signed-off-by
Hi Richard,
As per your suggestion in PR, the attached patch removes streamer_debugging and
it's uses.
Bootstrapped on aarch64-linux-gnu.
OK to commit ?
Signed-off-by: Prathamesh Kulkarni
Thanks,
Prathamesh
[PR115394] Remove streamer_debugging and it's uses.
gcc/ChangeLog:
e patch significantly improves speedup for an internal Fortran application on
AArch64 -mcpu=grace (and potentially on other AArch64 cores too).
Bootstrapped+tested on aarch64-linux-gnu.
Does the patch look OK to commit ?
Signed-off-by: Prathamesh Kulkarni
Thanks,
Prathamesh
Lower zeroing array
> -Original Message-
> From: Harald Anlauf
> Sent: Thursday, July 11, 2024 12:53 AM
> To: Prathamesh Kulkarni ; gcc-
> patc...@gcc.gnu.org; fort...@gcc.gnu.org
> Subject: Re: Lower zeroing array assignment to memset for allocatable
> arrays
>
> External email
> -Original Message-
> From: Harald Anlauf
> Sent: Friday, July 12, 2024 1:52 AM
> To: Prathamesh Kulkarni ; gcc-
> patc...@gcc.gnu.org; fort...@gcc.gnu.org
> Subject: Re: Lower zeroing array assignment to memset for allocatable
> arrays
>
> External email: U
> -Original Message-
> From: Harald Anlauf
> Sent: Saturday, July 13, 2024 1:15 AM
> To: Prathamesh Kulkarni ; gcc-
> patc...@gcc.gnu.org; fort...@gcc.gnu.org
> Subject: Re: Lower zeroing array assignment to memset for allocatable
> arrays
>
> External email: U
> -Original Message-
> From: Harald Anlauf
> Sent: Tuesday, July 16, 2024 12:06 AM
> To: Prathamesh Kulkarni ; gcc-
> patc...@gcc.gnu.org; fort...@gcc.gnu.org
> Subject: Re: Lower zeroing array assignment to memset for allocatable
> arrays
>
> External email: U
ost_compiler on HOST_MULTILIB. I verified that the macro is set to 0 for
aarch64 host (and thus avoids above unrecognized command line option error),
and is set to 1 for x86_64 host.
Does the patch look OK ?
Signed-off-by: Prathamesh Kulkarni
Thanks,
Prathamesh
[nvptx] Pass -m32/-m64 to host_com
> -Original Message-
> From: Thomas Schwinge
> Sent: Friday, August 9, 2024 12:55 AM
> To: Prathamesh Kulkarni
> Cc: Andrew Pinski ; Richard Biener
> ; gcc-patches@gcc.gnu.org; Jakub Jelinek
>
> Subject: Re: [nvptx] Pass -m32/-m64 to host_compiler if i
lso fixes failures due to same issue with x86_64->nvptx offloading
for target-print-1.f90 (and couple more).
Does the patch look OK ?
Signed-off-by: Prathamesh Kulkarni
Thanks,
Prathamesh
[optc-save-gen.awk] Fix streaming of command line options for offloading.
The patch modifies optc-save-g
> -Original Message-
> From: Richard Biener
> Sent: Tuesday, August 13, 2024 10:06 PM
> To: Thomas Schwinge
> Cc: Prathamesh Kulkarni ; Andrew Pinski
> ; gcc-patches@gcc.gnu.org; Jakub Jelinek
>
> Subject: Re: [nvptx] Pass -m32/-m64 to host_compiler if i
> -Original Message-
> From: Richard Biener
> Sent: Tuesday, August 13, 2024 12:52 PM
> To: Andrew Pinski
> Cc: Prathamesh Kulkarni ; gcc-
> patc...@gcc.gnu.org; Thomas Schwinge
> Subject: Re: [optc-save-gen.awk] Fix streaming of command line options
> for
h survives AArch64->nvptx offload testing for libgomp and bootstrap+test on
aarch64-linux-gnu.
Does the patch look in the right direction ?
Signed-off-by: Prathamesh Kulkarni
Thanks,
Prathamesh
Recompute TYPE_MODE and DECL_MODE for aggregate type for acclerator.
The patch streams out VOIDmode
> -Original Message-
> From: Richard Biener
> Sent: Monday, August 19, 2024 6:51 PM
> To: Prathamesh Kulkarni
> Cc: Andrew Pinski ; gcc-patches@gcc.gnu.org; Thomas
> Schwinge
> Subject: RE: [optc-save-gen.awk] Fix streaming of command line options
> for offloa
> -Original Message-
> From: Richard Biener
> Sent: Tuesday, August 20, 2024 10:36 AM
> To: Richard Sandiford
> Cc: Prathamesh Kulkarni ; Thomas Schwinge
> ; gcc-patches@gcc.gnu.org
> Subject: Re: Re-compute TYPE_MODE and DECL_MODE while streaming in for
> a
> -Original Message-
> From: Richard Biener
> Sent: Wednesday, August 21, 2024 5:09 PM
> To: Prathamesh Kulkarni
> Cc: Richard Sandiford ; Thomas Schwinge
> ; gcc-patches@gcc.gnu.org
> Subject: RE: Re-compute TYPE_MODE and DECL_MODE while streaming in for
> a
> -Original Message-
> From: Richard Biener
> Sent: Thursday, August 22, 2024 2:16 PM
> To: H.J. Lu
> Cc: gcc-patches@gcc.gnu.org; josmy...@redhat.com
> Subject: Re: [PATCH v3] Update LDPT_REGISTER_CLAIM_FILE_HOOK_V2 linker
> plugin hook
>
> External email: Use caution opening links or
> -Original Message-
> From: H.J. Lu
> Sent: Friday, August 23, 2024 6:07 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Prathamesh Kulkarni ;
> richard.guent...@gmail.com
> Subject: [PATCH] lto: Don't check obj.found for offload section
>
> External ema
the
provided value in nvptx_asm_output_def_from_decls.
For the above case, it now generates the following ptx:
.alias baz,foo;
instead of:
.alias baz,bar;
which fixes the issue.
Does the patch look in the right direction ?
Signed-off-by: Prathamesh Kulkarni
Thanks,
Prathamesh
[nvptx] Fix code-
a try with x86_64->nvptx offloading if required (altho I guess LTO
bootstrap should test streaming changes ?)
Signed-off-by: Prathamesh Kulkarni
Thanks,
Prathamesh
Partially support streaming of poly_int for offloading.
Support streaming of poly_int for offloading when it's degree do
> -Original Message-
> From: Richard Sandiford
> Sent: Monday, July 29, 2024 9:43 PM
> To: Richard Biener
> Cc: Prathamesh Kulkarni ; gcc-
> patc...@gcc.gnu.org
> Subject: Re: Support streaming of poly_int for offloading when it's
> degree <= accel
> -Original Message-
> From: Jakub Jelinek
> Sent: Tuesday, July 30, 2024 3:16 PM
> To: Richard Biener
> Cc: Richard Sandiford ; Prathamesh Kulkarni
> ; gcc-patches@gcc.gnu.org
> Subject: Re: Support streaming of poly_int for offloading when it&
> -Original Message-
> From: Prathamesh Kulkarni
> Sent: Tuesday, July 30, 2024 4:44 PM
> To: Jakub Jelinek ; Richard Biener
>
> Cc: Richard Sandiford ; gcc-
> patc...@gcc.gnu.org
> Subject: RE: Support streaming of poly_int for offloading when
> -Original Message-
> From: Tobias Burnus
> Sent: Tuesday, July 30, 2024 6:08 PM
> To: Prathamesh Kulkarni ; gcc-
> patc...@gcc.gnu.org
> Subject: Re: Support streaming of poly_int for offloading when it's
> degree <= accel's NUM_POLY_INT_COEFFS
>
> -Original Message-
> From: Jakub Jelinek
> Sent: Wednesday, July 31, 2024 8:46 PM
> To: Prathamesh Kulkarni
> Cc: Richard Biener ; Richard Sandiford
> ; gcc-patches@gcc.gnu.org
> Subject: Re: Support streaming of poly_int for offloading when it&
> -Original Message-
> From: Jakub Jelinek
> Sent: Friday, August 2, 2024 5:43 PM
> To: Prathamesh Kulkarni
> Cc: Richard Biener ; Richard Sandiford
> ; gcc-patches@gcc.gnu.org
> Subject: Re: Support streaming of poly_int for offloading when it's
> degree &
> -Original Message-
> From: Jakub Jelinek
> Sent: Monday, August 5, 2024 8:01 PM
> To: Prathamesh Kulkarni
> Cc: Richard Biener ; Richard Sandiford
> ; gcc-patches@gcc.gnu.org
> Subject: Re: Support streaming of poly_int for offloading when it's
> degree &
> -Original Message-
> From: Jakub Jelinek
> Sent: Wednesday, August 7, 2024 11:27 PM
> To: Prathamesh Kulkarni
> Cc: Richard Biener ; Richard Sandiford
> ; gcc-patches@gcc.gnu.org
> Subject: Re: Support streaming of poly_int for offloading when it&
> -Original Message-
> From: Prathamesh Kulkarni
> Sent: Monday, August 26, 2024 4:21 PM
> To: Thomas Schwinge ; gcc-patches@gcc.gnu.org
> Subject: [nvptx] Fix code-gen for alias attribute
>
> External email: Use caution opening links or attachments
>
>
>
e issue by checking if variable is VLA vector,
and emits an error in that case since no accel currently supports VLA vectors.
Does the patch look OK ?
Signed-off-by: Prathamesh Kulkarni
Thanks,
Prathamesh
[gimplify.cc] Emit an error if VLA vector is passed to accelerator.
gcc/ChangeLog:
* g
> -Original Message-
> From: Prathamesh Kulkarni
> Sent: Thursday, August 22, 2024 7:41 PM
> To: Richard Biener
> Cc: Richard Sandiford ; Thomas Schwinge
> ; gcc-patches@gcc.gnu.org
> Subject: RE: Re-compute TYPE_MODE and DECL_MODE while streaming in for
> a
> -Original Message-
> From: Richard Biener
> Sent: Monday, September 2, 2024 12:47 PM
> To: Prathamesh Kulkarni
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [gimplify.cc] Avoid ICE when passing VLA vector to
> accelerator
>
> External email: Use caution o
> -Original Message-
> From: Richard Biener
> Sent: Tuesday, September 3, 2024 2:09 PM
> To: Prathamesh Kulkarni
> Cc: gcc-patches@gcc.gnu.org
> Subject: RE: [gimplify.cc] Avoid ICE when passing VLA vector to
> accelerator
>
> External email: Use caution o
> -Original Message-
> From: Thomas Schwinge
> Sent: Friday, September 6, 2024 2:31 PM
> To: Prathamesh Kulkarni ; Richard Biener
>
> Cc: Andrew Pinski ; gcc-patches@gcc.gnu.org; Jakub
> Jelinek
> Subject: RE: [nvptx] Pass -m32/-m64 to host_compiler if i
> -Original Message-
> From: Thomas Schwinge
> Sent: Monday, September 9, 2024 8:50 PM
> To: Prathamesh Kulkarni ; Richard Biener
>
> Cc: Andrew Pinski ; gcc-patches@gcc.gnu.org; Jakub
> Jelinek
> Subject: RE: [nvptx] Pass -m32/-m64 to host_compiler if i
> -Original Message-
> From: Thomas Schwinge
> Sent: Tuesday, September 10, 2024 8:19 PM
> To: Prathamesh Kulkarni ; Richard Biener
>
> Cc: Andrew Pinski ; gcc-patches@gcc.gnu.org; Jakub
> Jelinek
> Subject: RE: [nvptx] Pass -m32/-m64 to host_compiler if i
On 19 January 2016 at 16:49, Marek Polacek wrote:
> Sorry for speaking up late, but I think we could do better with formatting
> in this patch:
>
> On Sat, Jan 16, 2016 at 03:45:22PM +0530, Prathamesh Kulkarni wrote:
>> diff --git a/gcc/c/c-decl.c b/gcc/c/c-decl.c
>> index
Hi,
For the test-case,
void f(int a[static 10]);
g++ gives following errors:
test-foo.cpp:1:14: error: expected primary-expression before ‘static’
void f(int a[static 10]);
^
test-foo.cpp:1:14: error: expected ‘]’ before ‘static’
test-foo.cpp:1:14: error: expected ‘)’ before ‘static
On 29 January 2016 at 05:03, Marek Polacek wrote:
> On Fri, Jan 29, 2016 at 04:46:56AM +0530, Prathamesh Kulkarni wrote:
>> @@ -19016,10 +19017,22 @@ cp_parser_direct_declarator (cp_parser* parser,
>> cp_lexer_consume_token (parser->lexer);
>> /
On 4 February 2016 at 16:31, Ramana Radhakrishnan
wrote:
> On Sun, Jan 17, 2016 at 9:06 AM, Prathamesh Kulkarni
> wrote:
>> On 31 July 2015 at 15:04, Ramana Radhakrishnan
>> wrote:
>>>
>>>
>>> On 29/07/15 11:09, Prathamesh Kulkarni wrote:
>>
Hi,
aarch64 supports section anchors but it appears
check_effective_target_section_anchors() doesn't contain entry for it.
This patch adds for entry for aarch64.
OK for trunk ?
Thanks,
Prathamesh
diff --git a/gcc/testsuite/lib/target-supports.exp
b/gcc/testsuite/lib/target-supports.exp
index 6459
On 15 February 2016 at 19:24, James Greenhalgh wrote:
> On Thu, Feb 11, 2016 at 11:03:23PM +0530, Prathamesh Kulkarni wrote:
>> Hi,
>> aarch64 supports section anchors but it appears
>> check_effective_target_section_anchors() doesn't contain entry for it.
>> This
On 1 March 2016 at 16:19, Richard Biener wrote:
> On Tue, 1 Mar 2016, Ramana Radhakrishnan wrote:
>
>>
>>
>> On 01/03/16 09:54, Richard Biener wrote:
>> > On Tue, 1 Mar 2016, James Greenhalgh wrote:
>> >
>> >> On Tue, Mar 01, 2016 at 10:21:27AM +0100, Richard Biener wrote:
>> >>> On Mon, 29 Feb 20
Hi,
We allow c_expr to be empty which accepts cases like the following:
(simplify
match-operand
(if ()
result-operand))
(simplify
match-operand
{})
The attached patch rejects empty c_expr.
Ok for trunk after bootstrap + test ?
Thank you,
Prathamesh
2015-07-15 Prathamesh Kulkarni
On 16 July 2015 at 12:39, Richard Biener wrote:
> On Wed, 15 Jul 2015, Prathamesh Kulkarni wrote:
>
>> Hi,
>> We allow c_expr to be empty which accepts cases like the following:
>>
>> (simplify
>> match-operand
>> (if ()
>> res
1 - 100 of 1018 matches
Mail list logo
