在 2020/3/5 下午10:18, Iain Sandoe 写道:
Hello JunMa,
JunMa wrote:
Ping
Once again, sorry for taking time to review this.
在 2020/2/27 上午10:18, JunMa 写道:
在 2020/2/11 上午10:14, JunMa 写道:
Kindly ping
Regards
JunMa
Hi
In maybe_promote_captured_temps, the cleanup_point_stmt has been
stripped
在 2020/3/5 下午9:51, Iain Sandoe 写道:
Hello JunMa,
JunMa wrote:
Ping
Thanks for your patch(es) and I am sorry this has taken some time to
review.
(right now, we’re trying to ensure that we have the latest standard
represented in
GCC10, so updating to n4849).
在 2020/2/27 上午10:17, JunMa
Ping
Regards
JunMa
在 2020/2/27 上午10:18, JunMa 写道:
在 2020/2/11 上午10:14, JunMa 写道:
Kindly ping
Regards
JunMa
Hi
In maybe_promote_captured_temps, the cleanup_point_stmt has been
stripped when handle temporaries captured by reference. However, maybe
there are non-reference temporaries in current
Ping
Regards
JunMa
在 2020/2/27 上午10:17, JunMa 写道:
在 2020/2/11 上午10:50, JunMa 写道:
Hi
kindly ping~
Regards
JunMa
Hi
As title. in maybe_promote_captured_temps, we promote captured
temporaries
and co_await_expr into a new BIND_EXPR. As the BIND_EXPR contains
co_await_expr and maybe other
在 2020/3/3 下午8:15, Nathan Sidwell 写道:
On 3/3/20 12:42 AM, JunMa wrote:
在 2020/3/2 下午10:49, Nathan Sidwell 写道:
On 2/12/20 2:23 AM, JunMa wrote:
Hi nathan
Here is the updated patch
This is ok, with a correction in a comment:
+ /* This isn't a temporary or argument. */
/*
在 2020/3/2 下午10:49, Nathan Sidwell 写道:
On 2/12/20 2:23 AM, JunMa wrote:
Hi
In captures_temporary, the current implementation fails to handle
component_ref. This causes ice with case co_await A while
operator co_await is defined in base class of A. Also it is necessary
to capture the object of
ood thing to revisit for C++23.
This patch removes the additional copying behaviour for lambda capture-by-
copy vars.
@JunMa, this supercedes your fix to the aliases, which should no longer be
necessary, but i’ve added your testcases to this patch.
Hi Iain
Most part of your patch are same idea
在 2020/2/12 下午3:23, JunMa 写道:
Kindly ping
Regards
JunMa
Hi
In captures_temporary, the current implementation fails to handle
component_ref. This causes ice with case co_await A while
operator co_await is defined in base class of A. Also it is necessary
to capture the object of base class as if
在 2020/2/11 上午10:14, JunMa 写道:
Kindly ping
Regards
JunMa
Hi
In maybe_promote_captured_temps, the cleanup_point_stmt has been
stripped when handle temporaries captured by reference. However, maybe
there are non-reference temporaries in current stmt which cause ice in
gimpilify pass.
This patch
在 2020/2/11 上午10:50, JunMa 写道:
Hi
kindly ping~
Regards
JunMa
Hi
As title. in maybe_promote_captured_temps, we promote captured
temporaries
and co_await_expr into a new BIND_EXPR. As the BIND_EXPR contains
co_await_expr and maybe other function calls, the side effects flag
should
be set
在 2020/2/10 下午7:42, JunMa 写道:
Ping~
Regards
JunMa
Kindly ping.
Regards
JunMa
在 2020/2/5 下午5:17, JunMa 写道:
在 2020/2/5 下午2:14, JunMa 写道:
Hi
This patch builds co_await/yield_expr with unknown_type when we can not
know the promise type in processing_template_decl phase. it avoid to
confuse
在 2020/2/26 下午9:43, Iain Sandoe 写道:
This is the second in the series to bring the GCC implementation into line
with the current standard.
@JunMa
I believe that this should solve the problems you were looking at in
“[PATCH Coroutines] Fix issue with unused corutine function parameters
to its base object and check it as usual.
Bootstrap and test on X86_64, is it OK?
Regards
JunMa
gcc/cp
2020-02-12 Jun Ma
* coroutines.cc (captures_temporary): Strip component_ref
to its base object.
gcc/testsuite
2020-02-12 Jun Ma
* g++.dg/coroutines/torture/co-await
在 2020/2/11 上午10:50, JunMa 写道:
Hi
As title. in maybe_promote_captured_temps, we promote captured
temporaries
and co_await_expr into a new BIND_EXPR. As the BIND_EXPR contains
co_await_expr and maybe other function calls, the side effects flag
should
be set.
This patch fix one mismatch in
cppcoro
and is reduced by creduce.
Bootstrap and test on X86_64, is it OK?
Regards
JunMa
gcc/cp
2020-02-11 Jun Ma
* coroutines.cc (maybe_promote_captured_temps): Set side effects
flag for BIND_EXPR.
gcc/testsuite
2020-02-11 Jun Ma
* g++.dg/coroutines/torture/lambda-10-co
creduce.
Bootstrap and test on X86_64, is it OK?
Regards
JunMa
gcc/cp
2020-02-11 Jun Ma
* coroutines.cc (maybe_promote_captured_temps): Do not strip
cleanup_point_stmt.
gcc/testsuite
2020-02-11 Jun Ma
* g++.dg/coroutines/torture/lambda-09-capture-object.C: New test
Kindly ping.
Regards
JunMa
在 2020/2/5 下午5:17, JunMa 写道:
在 2020/2/5 下午2:14, JunMa 写道:
Hi
This patch builds co_await/yield_expr with unknown_type when we can not
know the promise type in processing_template_decl phase. it avoid to
confuse compiler when handing type deduction and conversion
在 2020/2/6 下午7:09, JunMa 写道:
在 2020/2/6 下午5:12, Iain Sandoe 写道:
Hi JunMa,
JunMa wrote:
在 2020/2/4 下午8:17, JunMa 写道:
Hi
When testing coroutines with lambda function, I find we copy each
captured
variable to frame. However, according to gimplify pass, for each
declaration
that is an alias
在 2020/2/6 下午5:12, Iain Sandoe 写道:
Hi JunMa,
JunMa wrote:
在 2020/2/4 下午8:17, JunMa 写道:
Hi
When testing coroutines with lambda function, I find we copy each
captured
variable to frame. However, according to gimplify pass, for each
declaration
that is an alias for another expression
在 2020/2/4 下午8:17, JunMa 写道:
Hi
When testing coroutines with lambda function, I find we copy each
captured
variable to frame. However, according to gimplify pass, for each
declaration
that is an alias for another expression(DECL_VALUE_EXPR), we can
substitute them directly.
Since lambda
在 2020/2/5 下午2:14, JunMa 写道:
Hi
This patch builds co_await/yield_expr with unknown_type when we can not
know the promise type in processing_template_decl phase. it avoid to
confuse compiler when handing type deduction and conversion.
Bootstrap and test on X86_64, is it OK?
Regards
JunMa
Hi
Hi
This patch builds co_await/yield_expr with unknown_type when we can not
know the promise type in processing_template_decl phase. it avoid to
confuse compiler when handing type deduction and conversion.
Bootstrap and test on X86_64, is it OK?
Regards
JunMa
gcc/cp
2020-02-05 Jun Ma
frame field, then we check
every variable whether it has DECL_VALUE_EXPR, and then substitute it, this
patch does not create frame field for such variables.
Bootstrap and test on X86_64, is it OK?
Regards
JunMa
gcc/cp
2020-02-04 Jun Ma
* coroutines.cc (morph_fn_to_coro): Remove code
在 2020/2/3 下午8:53, Nathan Sidwell 写道:
On 2/2/20 9:28 PM, JunMa wrote:
在 2020/2/3 上午9:03, JunMa 写道:
I think all you want here is:
await_expr = convert_from_reference (await_expr);
Thanks, I'll update it.
Regards
JunMa
Hi nathan,
Here is the update.
/* This will produc
在 2020/2/3 上午9:03, JunMa 写道:
在 2020/1/28 上午12:01, Nathan Sidwell 写道:
On 1/21/20 6:21 AM, JunMa wrote:
Hi
When test gcc with cppcoro, I find case like:
int& awaitable::await_resume()
auto x1 = co_await awaitable;
decltype(auto) x2 = co_await awaitable;
Based on standard, typeo
在 2020/1/28 上午12:01, Nathan Sidwell 写道:
On 1/21/20 6:21 AM, JunMa wrote:
Hi
When test gcc with cppcoro, I find case like:
int& awaitable::await_resume()
auto x1 = co_await awaitable;
decltype(auto) x2 = co_await awaitable;
Based on standard, typeof(x1) should be int, typeof(x2
在 2020/1/21 下午8:06, Nathan Sidwell 写道:
On 1/20/20 10:38 PM, JunMa wrote:
在 2020/1/21 上午9:31, JunMa 写道:
在 2020/1/20 下午11:49, Nathan Sidwell 写道:
On 1/20/20 12:18 AM, JunMa wrote:
Hi
This patch adds lookup_awaitable_member, it outputs error messages
when any of
the await_ready/suspend/resume
all_expr when replace co_await expression. it fix type deduction
of auto and decltype(auto) in coroutine.
Bootstrap and test on X86_64, is it OK?
Regards
JunMa
gcc/cp
2020-01-21 Jun Ma
* coroutines.cc (build_co_await): Wrap co_await with
indirect_ref whe
在 2020/1/21 下午4:07, Iain Sandoe 写道:
JunMa wrote:
在 2020/1/21 上午9:34, JunMa 写道:
在 2020/1/21 上午12:39, Iain Sandoe 写道:
JunMa wrote:
在 2020/1/20 下午8:21, Iain Sandoe 写道:
JunMa wrote:
在 2020/1/20 下午7:55, Iain Sandoe 写道:
Hi JunMa,
JunMa wrote:
在 2020/1/20 下午6:07, Iain Sandoe 写道:
Hi
Hi
This patch does minor fix on changing context of label_decl from
original function to actor function which avoid assertion in gimplify pass.
Bootstrap and test on X86_64, is it OK?
Regards
JunMa
gcc/cp
2020-01-21 Jun Ma
* coroutines.cc (transform_await_wrapper): Set actor funcion
在 2020/1/21 上午9:31, JunMa 写道:
在 2020/1/20 下午11:49, Nathan Sidwell 写道:
On 1/20/20 12:18 AM, JunMa wrote:
Hi
This patch adds lookup_awaitable_member, it outputs error messages
when any of
the await_ready/suspend/resume functions are missing in awaitable
class.
This patch also add some error
在 2020/1/21 上午9:31, JunMa 写道:
在 2020/1/20 下午11:49, Nathan Sidwell 写道:
On 1/20/20 12:18 AM, JunMa wrote:
Hi
This patch adds lookup_awaitable_member, it outputs error messages
when any of
the await_ready/suspend/resume functions are missing in awaitable
class.
This patch also add some error
在 2020/1/21 上午9:34, JunMa 写道:
在 2020/1/21 上午12:39, Iain Sandoe 写道:
JunMa wrote:
在 2020/1/20 下午8:21, Iain Sandoe 写道:
JunMa wrote:
在 2020/1/20 下午7:55, Iain Sandoe 写道:
Hi JunMa,
JunMa wrote:
在 2020/1/20 下午6:07, Iain Sandoe 写道:
Hi JunMa,
JunMa wrote:
Hi
Accroding to N4835: When a
在 2020/1/21 上午12:39, Iain Sandoe 写道:
JunMa wrote:
在 2020/1/20 下午8:21, Iain Sandoe 写道:
JunMa wrote:
在 2020/1/20 下午7:55, Iain Sandoe 写道:
Hi JunMa,
JunMa wrote:
在 2020/1/20 下午6:07, Iain Sandoe 写道:
Hi JunMa,
JunMa wrote:
Hi
Accroding to N4835: When a coroutine is invoked, a copy is
在 2020/1/20 下午11:49, Nathan Sidwell 写道:
On 1/20/20 12:18 AM, JunMa wrote:
Hi
This patch adds lookup_awaitable_member, it outputs error messages
when any of
the await_ready/suspend/resume functions are missing in awaitable class.
This patch also add some error check on return value of
在 2020/1/20 下午8:21, Iain Sandoe 写道:
JunMa wrote:
在 2020/1/20 下午7:55, Iain Sandoe 写道:
Hi JunMa,
JunMa wrote:
在 2020/1/20 下午6:07, Iain Sandoe 写道:
Hi JunMa,
JunMa wrote:
Hi
Accroding to N4835: When a coroutine is invoked, a copy is created
for each coroutine parameter. While in current
在 2020/1/20 下午7:55, Iain Sandoe 写道:
Hi JunMa,
JunMa wrote:
在 2020/1/20 下午6:07, Iain Sandoe 写道:
Hi JunMa,
JunMa wrote:
Hi
Accroding to N4835: When a coroutine is invoked, a copy is created
for each coroutine parameter. While in current implementation, we
only collect used parameters
在 2020/1/20 下午6:07, Iain Sandoe 写道:
Hi JunMa,
JunMa wrote:
Hi
Accroding to N4835: When a coroutine is invoked, a copy is created
for each coroutine parameter. While in current implementation, we
only collect used parameters. This may lost behavior inside constructor
and destructor of unused
在 2020/1/20 下午4:55, Iain Sandoe 写道:
Hi JunMa,
JunMa wrote:
gcc/cp
2020-01-20 Jun Ma
* coroutines.cc (lookup_awaitable_member): Lookup an
awaitable member.
(build_co_await): Use lookup_awaitable_member instead of
lookup_member.
(finish_co_yield_expr
parameter.
Bootstrap and test on X86_64, is it OK?
Regards
JunMa
gcc/cp
2020-01-20 Jun Ma
* coroutines.cc (build_actor_fn): Skip rewrite when there is no
param references.
(register_param_uses): Only collect param references here.
(morph_fn_to_coro): Create
X86_64, is it OK?
Regards
JunMa
gcc/cp
2020-01-20 Jun Ma
* coroutines.cc (lookup_awaitable_member): Lookup an awaitable
member.
(build_co_await): Use lookup_awaitable_member instead of
lookup_member.
(finish_co_yield_expr, finish_co_await_expr): Add error check
on
在 2019/11/20 下午9:11, JunMa 写道:
在 2019/11/20 下午7:22, Iain Sandoe 写道:
Hello JunMa,
JunMa wrote:
在 2019/11/17 下午6:28, Iain Sandoe 写道:
I find that the patches donot support 'for co_await'. And it is
quiet simple to implement range based 'for co_await' based on your
patches,
在 2019/11/20 下午7:22, Iain Sandoe 写道:
Hello JunMa,
JunMa wrote:
在 2019/11/17 下午6:28, Iain Sandoe 写道:
I find that the patches donot support 'for co_await'. And it is
quiet simple to implement range based 'for co_await' based on your
patches, since it's just need fe
在 2019/6/18 上午6:46, Jeff Law 写道:
On 5/9/19 2:01 AM, JunMa wrote:
在 2019/5/9 上午10:22, JunMa 写道:
在 2019/5/9 上午3:02, Bernd Edlinger 写道:
On 5/8/19 4:31 PM, Richard Biener wrote:
On Tue, May 7, 2019 at 4:34 AM JunMa wrote:
在 2019/5/6 下午7:58, JunMa 写道:
在 2019/5/6 下午6:02, Richard Biener 写道:
On
在 2019/6/19 上午4:38, Jeff Law 写道:
On 3/26/19 5:40 AM, JunMa wrote:
Hi
According to gnu document of function attributes, neither weakref nor alias
could be attached to a function defined in current translation unit.
Although GCC checks the attributes under some circumstances, it still fails
on
在 2019/5/17 下午2:34, Jakub Jelinek 写道:
On Fri, May 17, 2019 at 02:24:22PM +0800, JunMa wrote:
2019-05-17 Jun Ma
Two spaces before < rather than one.
PR tree-optimization/90106
* gcc.dg/cdce3.c: New test.
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/cdce3.c
@@ -0,0 +1,12 @@
+/* { dg
在 2019/5/17 上午11:09, JunMa 写道:
在 2019/5/17 上午6:04, Jakub Jelinek 写道:
On Thu, May 16, 2019 at 11:39:38PM +0200, Jakub Jelinek wrote:
One possibility is to add -fdump-tree-optimized and scan for
/* { dg-final { scan-tree-dump "pow \\(\[^\n\r]*\\); \\\[tail
call\\\]" "optimize
在 2019/5/17 上午6:04, Jakub Jelinek 写道:
On Thu, May 16, 2019 at 11:39:38PM +0200, Jakub Jelinek wrote:
One possibility is to add -fdump-tree-optimized and scan for
/* { dg-final { scan-tree-dump "pow \\(\[^\n\r]*\\); \\\[tail call\\\]"
"optimized" } } */
resp.
/* { dg-final { scan-tree-dump "log
Already committed, as per https://www.gnu.org/software/gcc/svnwrite.html.
Regards
Jun
2019-05-16 Jun Ma
* MAINTAINERS (Write After Approval): Add myself.
diff --git a/MAINTAINERS b/MAINTAINERS
index fb7fd34..7c5942a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -514,6 +514,7 @
在 2019/5/13 下午5:02, Jakub Jelinek 写道:
On Mon, May 13, 2019 at 04:53:52PM +0800, JunMa wrote:
According to gnu document of function attributes, neither weakref nor
alias
could be attached to a function defined in current translation unit.
Although GCC checks the attributes under some
在 2019/3/26 下午7:40, JunMa 写道:
Hi
According to gnu document of function attributes, neither weakref nor
alias
could be attached to a function defined in current translation unit.
Although GCC checks the attributes under some circumstances, it still
fails
on some cases and even causes ICE
在 2019/5/10 上午4:00, Jeff Law 写道:
On 5/8/19 8:25 PM, JunMa wrote:
在 2019/5/9 上午9:20, Bin.Cheng 写道:
On Thu, May 9, 2019 at 5:31 AM Jeff Law wrote:
On 5/8/19 6:28 AM, Richard Biener wrote:
On Wed, May 8, 2019 at 12:09 PM JunMa wrote:
Hi
As PR90106 (https://gcc.gnu.org/bugzilla/show_bug.cgi
在 2019/5/9 上午10:22, JunMa 写道:
在 2019/5/9 上午3:02, Bernd Edlinger 写道:
On 5/8/19 4:31 PM, Richard Biener wrote:
On Tue, May 7, 2019 at 4:34 AM JunMa wrote:
在 2019/5/6 下午7:58, JunMa 写道:
在 2019/5/6 下午6:02, Richard Biener 写道:
On Thu, Mar 21, 2019 at 5:57 AM JunMa
wrote:
Hi
For now, gcc can not
在 2019/5/9 上午9:20, Bin.Cheng 写道:
On Thu, May 9, 2019 at 5:31 AM Jeff Law wrote:
On 5/8/19 6:28 AM, Richard Biener wrote:
On Wed, May 8, 2019 at 12:09 PM JunMa wrote:
Hi
As PR90106 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90106),
when gcc meets builtin function call like:
y = sqrt
在 2019/5/9 上午3:02, Bernd Edlinger 写道:
On 5/8/19 4:31 PM, Richard Biener wrote:
On Tue, May 7, 2019 at 4:34 AM JunMa wrote:
在 2019/5/6 下午7:58, JunMa 写道:
在 2019/5/6 下午6:02, Richard Biener 写道:
On Thu, Mar 21, 2019 at 5:57 AM JunMa wrote:
Hi
For now, gcc can not fold code like:
const char a
在 2019/5/8 下午10:31, Richard Biener 写道:
On Tue, May 7, 2019 at 4:34 AM JunMa wrote:
在 2019/5/6 下午7:58, JunMa 写道:
在 2019/5/6 下午6:02, Richard Biener 写道:
On Thu, Mar 21, 2019 at 5:57 AM JunMa wrote:
Hi
For now, gcc can not fold code like:
const char a[5] = "123"
__builtin_mem
rds
JunMa
gcc/ChangeLog
2019-05-07 Jun Ma
PR tree-optimization/90106
* tree-call-cdce.c (shrink_wrap_one_built_in_call_with_conds): Add
new parameter as new internal function call, also move it to new
basic block.
(use_internal_fn): Pass internal function call
在 2019/5/7 上午2:05, Martin Sebor 写道:
On 5/6/19 5:58 AM, JunMa wrote:
在 2019/5/6 下午6:02, Richard Biener 写道:
On Thu, Mar 21, 2019 at 5:57 AM JunMa wrote:
Hi
For now, gcc can not fold code like:
const char a[5] = "123"
__builtin_memchr (a, '7', sizeof a)
It tries to avoid f
在 2019/5/6 下午7:58, JunMa 写道:
在 2019/5/6 下午6:02, Richard Biener 写道:
On Thu, Mar 21, 2019 at 5:57 AM JunMa wrote:
Hi
For now, gcc can not fold code like:
const char a[5] = "123"
__builtin_memchr (a, '7', sizeof a)
It tries to avoid folding out of string length althou
在 2019/5/6 下午6:02, Richard Biener 写道:
On Thu, Mar 21, 2019 at 5:57 AM JunMa wrote:
Hi
For now, gcc can not fold code like:
const char a[5] = "123"
__builtin_memchr (a, '7', sizeof a)
It tries to avoid folding out of string length although length of a is 5.
This is a bi
在 2019/3/26 下午7:40, JunMa 写道:
Hi
According to gnu document of function attributes, neither weakref nor
alias
could be attached to a function defined in current translation unit.
Although GCC checks the attributes under some circumstances, it still
fails
on some cases and even causes ICE
在 2019/3/21 下午12:51, JunMa 写道:
Hi
For now, gcc can not fold code like:
const char a[5] = "123"
__builtin_memchr (a, '7', sizeof a)
It tries to avoid folding out of string length although length of a is 5.
This is a bit conservative, it's safe to folding memchr/
在 2019/4/30 上午5:57, Jeff Law 写道:
On 3/1/19 1:39 AM, JunMa wrote:
Hi
Since MAX_INLINE_INSNS_AUTO should be below or equal to
MAX_INLINE_INSNS_SINGLE (see params.def), there is no need
to do second inlining limit check on growth when function not
declared inline, this patch
/weakref attribute attaches on a function
declaration which has body, and removes the attribute later.
This also avoid the ICE.
Bootstrapped/regtested on x86_64-linux, ok for GCC10?
Regards
JunMa
gcc/ChangeLog
2019-03-26 Jun Ma
PR89341
* cgraphunit.c (handle_alias_pairs): Check whether
在 2019/3/21 下午1:06, Bin.Cheng 写道:
On Thu, Mar 21, 2019 at 12:57 PM JunMa wrote:
Hi
For now, gcc can not fold code like:
const char a[5] = "123"
__builtin_memchr (a, '7', sizeof a)
It tries to avoid folding out of string length although length of a is 5.
This is a bi
ring stores in array with some trailing nuls.
This patch folds these cases by exposing additional length of
trailing nuls in c_getstr().
Bootstrapped/regtested on x86_64-linux, ok for trunk?
Regards
JunMa
gcc/ChangeLog
2019-03-21 Jun Ma
PR Tree-optimization/89772
* fold-const.c (c_gets
Hi
Please ignore the previous mail.
在 2019/3/1 下午10:17, Segher Boessenkool 写道:
Hi!
On Fri, Mar 01, 2019 at 04:39:38PM +0800, JunMa wrote:
Since MAX_INLINE_INSNS_AUTO should be below or equal to
MAX_INLINE_INSNS_SINGLE (see params.def), there is no need
to do second inlining
--
发件人：Segher Boessenkool
发送时间：2019年3月1日(星期五) 22:18
收件人：JunMa
抄 送：gcc-patches
主 题：Re: [PATCH GCC10] ipa-inline.c: Trivial fix on function not declared inline
check in want_inline_small_function_p
Hi!
On Fri, Mar 01, 2019 at 04
Hi
Since MAX_INLINE_INSNS_AUTO should be below or equal to
MAX_INLINE_INSNS_SINGLE (see params.def), there is no need
to do second inlining limit check on growth when function not
declared inline, this patch removes it.
Bootstrapped and tested on x86_64-unknown-linux-gnu, is it ok
69 matches
Mail list logo
