> On 12/11/2015 03:05 AM, Richard Biener wrote:
> > On Thu, Dec 10, 2015 at 9:08 PM, Jeff Law wrote:
> >> On 12/03/2015 07:38 AM, Richard Biener wrote:
> >>>
> >>> This pass is now enabled by default with -Os but has no limits on
> >>> the amount of stmts it copies.
> >>
> >> The more statements i
>
> >
> > FAIL: obj-c++.dg/property/dotsyntax-11.mm -fgnu-runtime (test for
> > errors, line 51)
> > FAIL: obj-c++.dg/property/dotsyntax-11.mm -fgnu-runtime (test for
> > errors, line 56)
> > FAIL: obj-c++.dg/property/dotsyntax-11.mm -fgnu-runtime (test for
> > errors, line 59)
> >
> > Andreas.
>
> FAIL: obj-c++.dg/property/dotsyntax-11.mm -fgnu-runtime (test for errors,
> line 51)
> FAIL: obj-c++.dg/property/dotsyntax-11.mm -fgnu-runtime (test for errors,
> line 56)
> FAIL: obj-c++.dg/property/dotsyntax-11.mm -fgnu-runtime (test for errors,
> line 59)
>
> Andreas.
Here is the patch
Hi!
This patches fixes FP exception that comes from CilkPlus runtime.
Bootstrapped and regtested for x86_64.
Is it ok for trunk?
Thanks,
Igor
Changelog:
libcilkrts
2015-10-30 Igor Zamyatin
PR target/66326
* untime/config/x86/os-unix-sysdep.c (sysdep_save_fp_ctrl_state):
Hi!
This patch attempts to enhance error diagnostic in case of CilkPlus and fixes
PR68001.
Bootstrapped and regtested for x86_64.
Is it ok for trunk?
Thanks,
Igor
ChangeLog:
c-family
2015-11-02 Igor Zamyatin
PR c++/68001
* c-gimplify.c (c_gimplify_expr): Stop the process
>
>
> On 19/08/15 17:57, Jeff Law wrote:
> > On 08/12/2015 08:31 AM, Kyrill Tkachov wrote:
> >> 2015-08-10 Kyrylo Tkachov
> >>
> >> * ifcvt.c (struct noce_if_info): Add then_simple, else_simple,
> >> then_cost, else_cost fields. Change branch_cost field to
> >> unsigned int.
> >>
> > Not sure it's possible to merge DF_REG_DEF_CHAIN walk and
> DF_REF_CHAIN walk...
> OK. Just use the same overall structure if we can't pull the test out into a
> single function that could be called from both places.
>
Thanks, is updated patch ok for trunk?
Igor
Changelog:
gcc
2015-01-1
>
> On 01/13/15 11:01, Zamyatin, Igor wrote:
> >>
> >> Is it really sufficient here to verify that all the defs are on latch
> >> predecessors, what about the case where there is a predecessor
> >> without a def. How do you guarantee domination i
>
> Is it really sufficient here to verify that all the defs are on latch
> predecessors,
> what about the case where there is a predecessor without a def. How do
> you guarantee domination in that case?
>
> ISTM that given the structure for the code you're writing that you'd want to
> verify t
Hi!
This is an attempt to extend RTL unroller to allow cases like mentioned in the
PR -
namely when loop has duplicated exit blocks and back edges.
Bootstrapped and regtested on x86_64, also checking wide range of benchmarks -
spec2K, spec2006, EEMBC
Is it ok for trunk in case if no testing is
Hi!
When adding checks for PIC register in address cost calculation
(http://gcc.gnu.org/ml/gcc-cvs/2014-10/msg00411.html) it was meant to affect
only RTL passes.
Since !pic_offset_table_rtx is not enough for it (I see that
pic_offset_table_rtx enabled on GIMPLE level) following change explicitl
> On Fri, Nov 14, 2014 at 05:05:57PM +0000, Zamyatin, Igor wrote:
>
> It is not that easy, -fsanitize=address is not supported everywhere.
> Better if you stick it into testsuite/gcc.dg/asan/ No point adding effective-
> target ia32/fpic, there is nothing i?86 specific, not e
> On Fri, Nov 14, 2014 at 8:59 AM, Zamyatin, Igor
> wrote:
> >> >> >
> >> >> > ChangeLog:
> >> >> >
> >> >> > 2014-10-30 Igor Zamyatin
> >> >> >
> >> >> > * func
> >> >
> >> > ChangeLog:
> >> >
> >> > 2014-10-30 Igor Zamyatin
> >> >
> >> > * function.c (assign_parms): Move init of pic_offset_table_rtx
> >> > from here to...
> >> > * cfgexpand.c (expand_used_vars): ...here.
> >> The patch is probably fine. However, it would be good to have th
> > Hi!
> >
> > Following patch (moving initialization of pic_offset_table_rtx
> earlier) fixes failures for asan tests on 32 bits in PIC mode mentioned here -
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534#c48
> >
> >
> > Bootstrapped/regtested on x86_64, i686
> >
> > Is it ok for trunk?
> >
Hi!
Following patch (moving initialization of pic_offset_table_rtx earlier) fixes
failures for asan tests on 32 bits in PIC mode mentioned here -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534#c48
Bootstrapped/regtested on x86_64, i686
Is it ok for trunk?
ChangeLog:
2014-10-30 Igor Zam
>
> Those macros use "=&b" etc. in asm constraints, so IMHO you'll get the same
> error as for say:
>
> int
> foo (void)
> {
> bar ();
> int i = 0;
> asm volatile ("" : "+b" (i));
> bar ();
> return i;
> }
>
> when compiled by gcc 4.9 and earlier with -O2 -m32 -fpic:
> error: inconsist
>
> On Thu, Oct 30, 2014 at 08:48:57AM +, Zamyatin, Igor wrote:
> > Posted a patch in libc-alpha:
> >
> > https://sourceware.org/ml/libc-alpha/2014-10/msg00701.html
>
> That looks wrong. The non-PIC patterns that are enabled unconditionally
> with the patch
Posted a patch in libc-alpha:
https://sourceware.org/ml/libc-alpha/2014-10/msg00701.html
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Jeff Law
> Sent: Saturday, October 25, 2014 3:42 AM
> To: Evgeny Stupachenko; Andrew P
>
>
> The question remains, are the decls all you need from the traversal (i.e.
> what you need to act upon)? From my earlier skim of the original code that
> wasn't that obvious.
> You can have in decl_map at least also BLOCKs, perhaps types too, what
> else?
Jakub,
Seems the BLOCKs are the o
For some reasons it passed bootstrap locally...
> -Original Message-
> From: Jakub Jelinek [mailto:ja...@redhat.com]
> Sent: Tuesday, October 21, 2014 12:15 PM
> To: Zamyatin, Igor; Jeff Law
> Cc: GCC Patches (gcc-patches@gcc.gnu.org)
> Subject: Re: [PATCH, PR63307] Fix
> >
> >
> > c-family/Changelog:
> >
> > 2014-10-03 Igor Zamyatin
> >
> > PR c/63307
> > * cilk.c: Include vec.h.
> > (struct cilk_decls): New structure.
> > (wrapper_parm_cb): Split this function to...
> > (fill_decls_vec): ...this...
> > (create_parm_list): ...and this.
Hi!
The following patch does fix random order for new decls generation during
Cilk_spawn generation.
As Jakub suggested in the PR first we deal with vectors, then sort them and
only then perform necessary generation of new decls.
Bootstrapped and regtested on trunk/4.9.
For trunk I couldn't che
> > On Wed, 10 Sep 2014, Zamyatin, Igor wrote:
> >> + Complete support for http://cilk.org";>Cilk
> >> +Plus features was added to GCC
> >> + [2014-09-02]
>
> features *were* added, plural.
It's "support for features" thus singul
Hi!
Following change mentions that now all Cilk Plus features added to GCC
Index: htdocs/index.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v
retrieving revision 1.936
diff -p -r1.936 index.html
*** htdocs/index.html 14 Au
Hi!
The patch is another attempt to enable Cilk_for (see eg
https://www.cilkplus.org/sites/default/files/open_specifications/Intel_Cilk_plus_lang_spec_1.2.htm)
in the GCC compiler.
Bootstrapped and regtested on x86_64.
Is it ok for the trunk?
Thanks,
Igor
Changelogs:
gcc/
2014-08-29 Jakub
Hi!
Following patch adds necessary handling of the cases with incorrect type of an
array in ArrayNotation and thus avoids ICE.
Regtested on x86_64.
Ok for trunk/4.9?
Thanks,
Igor
gcc/c/ChangeLog:
2014-08-07 Igor Zamyatin
PR other/62008
* c-parser.c (c_parser_array_notation):
> >
> > Changelog:
> >
> > gcc/c-family:
> >
> > 2014-07-31 Igor Zamyatin
> >
> > PR other/61962
> > * array-notation-common.c (find_rank): Added handling for other
> > types of references.
> >
> >
> > gcc/testsuite:
> >
> > 2014-07-31 Igor Zamyatin
> >
> > PR
> > diff --git a/gcc/c-family/array-notation-common.c
> > b/gcc/c-family/array-notation-common.c
> > index c010039..5db14c6 100644
> > --- a/gcc/c-family/array-notation-common.c
> > +++ b/gcc/c-family/array-notation-common.c
> > @@ -221,7 +221,9 @@ find_rank (location_t loc, tree orig_expr, tree ex
Hi!
This patch fixes the ICE on invalid code by adding missed check for
error_mark_node.
Regtested on x86_64. Ok for trunk/4.9?
Thanks,
Igor
Changelog:
gcc/cp:
2014-07-31 Igor Zamyatin
PR other/61963
* parser.c (cp_parser_array_notation): Added check for array_type.
gc
Hi!
This patch fixes endless compilation for the case of array notation for an
array which is a structure member
Ok for trunk/4.9 once testing finished?
Thanks,
Igor
Changelog:
gcc/c-family:
2014-07-31 Igor Zamyatin
PR other/61962
* array-notation-common.c (find_rank): A
Ping
> -Original Message-
> From: Zamyatin, Igor
> Sent: Saturday, July 12, 2014 1:52 PM
> To: GCC Patches (gcc-patches@gcc.gnu.org)
> Subject: [PATCH 1/3, Cilk+] Fix for PR61455
>
> Hi!
>
> This simple change fixes the issue with printing of e
Hi!
This patch adds correct handling of declarations whit initializations that
contain array notation.
It fixes ICE in PR61455.
Regtested for x86_64 (along with the first patch in the chain).
Ok for trunk/4.9?
Thanks,
Igor
gcc/c-family/ChangeLog:
2014-07-08 Igor Zamyatin
PR midd
Hi!
This simple change fixes the issue with printing of error message (happened in
unprintable_error routine of the PR's test)
Regtested with the next patch of this chain.
Ok for trunk/4.9?
Thanks,
Igor
gcc/cp/Changelog:
2014-07-08 Igor Zamyatin
* cp-array-notation.c (expand_an_in_m
> On 06/16/14 14:13, Zamyatin, Igor wrote:
> > Hi All!
> >
> > The patch fixes ICE in array notation for the cases of incorrect arguments
> > of
> Cilk+ builtins and undeclared initial index.
> >
> > Is it ok for trunk and 4.9?
> >
> > Thanks,
Hi All!
The patch fixes ICE in array notation for the cases of incorrect arguments of
Cilk+ builtins and undeclared initial index.
Is it ok for trunk and 4.9?
Thanks,
Igor
diff --git a/gcc/c/ChangeLog b/gcc/c/ChangeLog
index 54d0de7..56e1b0b 100644
--- a/gcc/c/ChangeLog
+++ b/gcc/c/ChangeLog
@
> BTW, similar testcase seems to segfault too:
>
> int foo (int*p, int *i)
> {
> return __sec_reduce_max_ind(p[1:i]);
> }
>
This one should be fixed by r210930
Thanks,
Igor
Hi!
Following patch handles the case of pointers in Cilk+ builtins.
Regtested in x86_64.
Ok for trunk and 4.9?
Thanks,
Igor
gcc/c/ChangeLog:
2014-05-23 Igor Zamyatin
PR c/58942
* c-array-notation.c (fix_builtin_array_notation_fn): Handle the case
with a pointer.
gcc/cp/ChangeLog:
2014-05
uot;expected" } */
> -Original Message-
> From: Jeff Law [mailto:l...@redhat.com]
> Sent: Tuesday, May 20, 2014 8:36 PM
> To: H.J. Lu; Zamyatin, Igor
> Cc: GCC Patches (gcc-patches@gcc.gnu.org)
> Subject: Re: [PATCH, PR61191, Cilk+] Fix ICE on syntax error
>
>
Hi all!
The following patch fixes the ICE for the cilk code with syntax error.
Regtested on x86_64.
Ok for trunk and 4.9?
Thanks,
Igor
gcc/c/ChangeLog:
2014-05-20 Igor Zamyatin
* c-array-notation.c (fix_builtin_array_notation_fn): Check invalid
function parameters.
diff --git a/gcc/c/
++ b/gcc/testsuite/c-c++-common/cilk-plus/CK/invalid_sync.cc
@@ -0,0 +1,9 @@
+/* PR c/60189 */
+/* { dg-do compile } */
+/* { dg-options "-fcilkplus" } */
+
+int main (void)
+{
+_Cilk_sync return; /* { dg-error " expected ';' before 'return'" } */
+retur
Ping. Should I prepare the patch?
Thanks,
Igor
> > -Original Message
> > From: Jason Merrill [mailto:ja...@redhat.com]
> > Sent: Monday, April 14, 2014 9:49 PM
> > To: Zamyatin, Igor; Jakub Jelinek
> > Cc: GCC Patches (gcc-patches@gcc.gnu.org); Iyer, Ba
> > From: Jason Merrill [mailto:ja...@redhat.com]
> > Sent: Monday, April 14, 2014 9:49 PM
> > To: Zamyatin, Igor; Jakub Jelinek
> > Cc: GCC Patches (gcc-patches@gcc.gnu.org); Iyer, Balaji V
> > Subject: Re: [PATCH, PR60189, Cilk+] Fix for ICE with incorrect
> &g
Likely after this was checked in appeared following on x86
FAIL: gcc.dg/vect/vect-simd-clone-11.c -flto -ffat-lto-objects (internal
compiler error)
FAIL: gcc.dg/vect/vect-simd-clone-11.c -flto -ffat-lto-objects (test for excess
errors)
FAIL: gcc.dg/vect/vect-simd-clone-12.c -flto -ffat-lto-objec
> -Original Message-
> From: Jason Merrill [mailto:ja...@redhat.com]
> Sent: Monday, April 14, 2014 9:49 PM
> To: Zamyatin, Igor; Jakub Jelinek
> Cc: GCC Patches (gcc-patches@gcc.gnu.org); Iyer, Balaji V
> Subject: Re: [PATCH, PR60189, Cilk+] Fix for ICE with incorrect
> -Original Message-
> From: Jason Merrill [mailto:ja...@redhat.com]
> Sent: Monday, April 14, 2014 8:13 AM
> To: Zamyatin, Igor; Jakub Jelinek
> Cc: GCC Patches (gcc-patches@gcc.gnu.org); Iyer, Balaji V
> Subject: Re: [PATCH, PR60189, Cilk+] Fix for ICE with incorrect
>
> >> + token = cp_lexer_peek_token (parser->lexer);
> >> + if (token->type != CPP_SEMICOLON)
> >> + {
> >> + error_at (token->location, "%<_Cilk_sync%> must be
> >> followed"
> >> + " by semicolon");
> >> + post
>
> >> + token = cp_lexer_peek_token (parser->lexer);
> >> + if (token->type != CPP_SEMICOLON)
> >> + {
> >> + error_at (token->location, "%<_Cilk_sync%> must be
> >> followed"
> >> + " by semicolon");
> >> + post
> -Original Message-
> From: Jakub Jelinek [mailto:ja...@redhat.com]
> Sent: Thursday, April 10, 2014 10:21 PM
> To: Zamyatin, Igor
> Cc: GCC Patches (gcc-patches@gcc.gnu.org); Iyer, Balaji V
> Subject: Re: [PATCH, PR60469, Cilk+] Fix ICE of using Cilk_spawn and Array
&
fine ALEN 1024
+
+int main(int argc, char* argv[])
+{
+ int b[ALEN];
+ b[:] = 100;
+ _Cilk_spawn foo();
+ return 0;
+
> -Original Message-
> From: Jakub Jelinek [mailto:ja...@redhat.com]
> Sent: Thursday, April 10, 2014 9:29 PM
> To: Zamyatin, Igor
> Cc: GCC Patches (g
Hi!
This patches fixes the ICE when array notation is used along with Cilk_spawn.
We need to expand AN's loop using other routine for creating temporary
variables.
Bootstrapped/regtested on x86_64.
Also it introduces no new failures and fixes couple of ICE for CilkPlus
Conformance suite which
-do compile } */
+/* { dg-options "-fcilkplus" } */
+
+int main (void)
+{
+_Cilk_sync return; /* { dg-error " '_Cilk_sync' must be followed by
semicolon" } */
+return 0;
+}
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patche
-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Zamyatin, Igor
> Sent: Thursday, April 10, 2014 5:55 PM
> To: GCC Patches (gcc-patches@gcc.gnu.org)
> Cc: Iyer, Balaji V; Jakub Jelinek (ja...@redhat.com)
> Subject: [PATCH, PR60467, Cilk+] Fix for ICE w
Hi!
This patch filters out another incorrect usage of Cilk_spawn keyword.
Bootstrapped/regtested on x86_64. Ok for trunk?
Thanks,
Igor
gcc/ChangeLog:
2014-04-10 Igor Zamyatin
PR middle-end/60467
* c-family/cilk.c (cilk_set_spawn_marker): Remove FUNCTION_DECL
as possible
Hi!
This fixes ICE on inappropriate usage of Cilk_sync keyword.
Bootstrapped/regtested on x86_64. Ok for trunk?
Thanks,
Igor
gcc/ChangeLog:
2014-04-10 Igor Zamyatin
PR c++/60189
* cp/parser.c (cp_parser_postfix_expression): Make sure only
semicolon can go after Cilk_syn
So, Jan, what do you think will be best solution for stage 1?
Thanks,
Igor
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Vladimir Makarov
> Sent: Monday, October 21, 2013 6:52 AM
> To: Jan Hubicka; Zamy
Jan,
Please see my answers below
> -Original Message-
> From: Jan Hubicka [mailto:hubi...@ucw.cz]
> Sent: Sunday, October 20, 2013 12:30 AM
> To: Zamyatin, Igor; gcc-patches@gcc.gnu.org; vmaka...@redhat.com
> Cc: 'Jan Hubicka'
> Subject: Re: Honnor ix86_ac
Ccing Uros. Changes in i386.md could be related to the fix for PR57954.
Thanks,
Igor
-Original Message-
From: Wei Mi [mailto:w...@google.com]
Sent: Thursday, September 12, 2013 2:51 AM
To: GCC Patches
Cc: David Li; Zamyatin, Igor
Subject: [PATCH] disable use_vector_fp_converts for
Yes, I was planning to do it after second patch is in the trunk.
Thanks for pointing out exact places!
Igor
-Original Message-
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org] On
Behalf Of Tobias Burnus
Sent: Friday, May 31, 2013 5:24 PM
To: Zamyatin, Igor
Cc
So far we see a regression on one of eembc_1_1 test because of following change:
/* X86_TUNE_USE_VECTOR_FP_CONVERTS: Prefer vector packed SSE conversion
from FP to FP. */
- m_CORE2I7 | m_AMDFAM10 | m_GENERIC,
+ m_AMDFAM10 | m_GENERIC,
Probably we should keep it as is while there is not
We checked also spec2000 and eembc_2_0 on Atom - no visible regressions and
gains
-Original Message-
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org] On
Behalf Of Xinliang David Li
Sent: Friday, December 21, 2012 11:26 AM
To: Jan Hubicka
Cc: GCC Patches; Ahmad S
61 matches
Mail list logo
