er than representing them as RTL.
>
Excuse me, I have no any idea about it (in fact, in honest, I guess, I
am still not quite familiar with gcc development in details).
At present, what I can know is: after this patch, gcc can pass various
related unwinding test (including nested functions) under qemu tilegx
linux-user (originally, I traced related insns, they should be ok).
:-)
Thanks.
--
Chen Gang (陈刚)
Managing Natural Environments is the Duty of Human Beings.
On 10/20/16 06:42, Jeff Law wrote:
>> On 6/4/16 21:25, cheng...@emindsoft.com.cn wrote:
>>> From: Chen Gang <gang.chen.5...@gmail.com>
>>>
>>> r10 may also be as parameter stack pointer for the nested function, so
>>> need save it before call mco
Hello Maintainers:
Is this patch OK? Please help check it when you have time (at least for
me, it passes all related test and comparation).
And I shall continue to find and fix another issues about tilegx.
Thanks.
On 6/4/16 21:25, cheng...@emindsoft.com.cn wrote:
> From: Chen Gang <gang.
"\t}\n"
>> "\t{\n"
>
> You need only do this if cfun->static_chain_decl is set.
>
OK, thanks, I shall send patch v3 for it, within this week end.
Thanks.
--
Chen Gang (陈刚)
Managing Natural Environments is the Duty of Human Beings.
On 5/30/16 22:25, Chen Gang wrote:
> On 5/30/16 21:32, Chen Gang wrote:
>> On 5/30/16 03:18, Mike Stump wrote:
>>> On May 29, 2016, at 3:39 AM, cheng...@emindsoft.com.cn wrote:
>>>>
>>>> r10 may also be as parameter for the nested function, so need save
On 5/30/16 21:32, Chen Gang wrote:
> On 5/30/16 03:18, Mike Stump wrote:
>> On May 29, 2016, at 3:39 AM, cheng...@emindsoft.com.cn wrote:
>>>
>>> r10 may also be as parameter for the nested function, so need save it
>>> before call mcount.
>>
>>
nter for parameters,
mcount really save r10, but tilegx also use r10 to save lr, so cause
this issue ("move r10, lr; jal __mcount").
What I have done just like gcc x86 has done ("push r10; callq mcount").
Thanks.
--
Chen Gang (陈刚)
Managing Natural Environments is the Duty of Human Beings.
From 358ae2453a4b965adaf9e684220b7461f719a568 Mon Sep 17 00:00:00 2001
From: Chen Gang <gang.chen.5...@gmail.com>
Date: Mon, 7 Dec 2015 21:29:20 +0800
Subject: [PATCH] gcc/config/tilegx/tilegx.md: Compare only 32-bit values for
32-bit comparing
For __buildin_mul_overflow(), it will
ite tilegx qemu floating point insns within 2015-10-31.
Welcome additional ideas, suggestions, and completions.
Thanks.
On 10/24/15 08:15, Chen Gang wrote:
>
> On 10/23/15 16:56, Richard Biener wrote:
>> On Thu, Oct 22, 2015 at 9:46 PM, Jeff Law <l...@redhat.com> wrote
I will try.
Hope I can finish trying above all within 2 days (2015-10-25).
Thanks.
--
Chen Gang (陈刚)
Open, share, and attitude like air, water, and life which God blessed
Hello all:
It is for bug63510, which reported by another members (not me), I guess,
this patch should fix this bug.
Welcome any other members' ideas, suggestions, and completions.
Thanks.
On 10/13/15 06:36, Chen Gang wrote:
> Hello all:
>
> Is this patch OK? If it still needs to do
On 10/13/15 22:56, Bernd Schmidt wrote:
> On 10/13/2015 04:50 PM, Chen Gang wrote:
>> OK, under the bugzilla, the maintainer treated it as expected behavior
>> (not a bug). For me, we need more explanation for it (why we treat it
>> as expected behavior).
>
> A globa
On 10/13/15 07:02, Mike Stump wrote:
> On Oct 12, 2015, at 3:32 PM, Chen Gang <xili_gchen_5...@hotmail.com> wrote:
>>
>> OK, thanks. If we really need to fix it, which target hook should I use?
>> (or do we need a new target hook?)
>
> So, the first discussion w
On 10/12/15 18:49, Bernd Schmidt wrote:
> On 10/11/2015 05:16 PM, Chen Gang wrote:
>> For some architectures (e.g. bfin), when this case occurs, they will use
>> another instructions instead of frame pointer (e.g. LINK for bfin), so
>> they can still generate correct
Hello all:
Is this patch OK? If it still needs to do anything, please let me know,
I shall try.
Thanks.
On 9/1/15 21:42, Chen Gang wrote:
> On 8/31/15 19:12, Richard Biener wrote:
>> On Sat, Aug 29, 2015 at 2:57 PM, Chen Gang <xili_gchen_5...@hotmail.com>
>> wrote:
>>
From fadd991f87dbd5752e9b6a2cce300dfe7cc8af25 Mon Sep 17 00:00:00 2001
From: Chen Gang <gang.chen.5...@gmail.com>
Date: Sun, 11 Oct 2015 22:59:35 +0800
Subject: [PATCH] gcc/ira.c: Check !HAVE_FP_INSTEAD_INSNS when frame pointer is
needed and as global register
For some architectures (e.g
On 8/31/15 19:12, Richard Biener wrote:
> On Sat, Aug 29, 2015 at 2:57 PM, Chen Gang <xili_gchen_5...@hotmail.com>
> wrote:
>>
>> It is about bug63510: current input_location isn't precise for reporting
>> warning. The correct location is gimple location of current
It is about bug63510: current input_location isn't precise for reporting
warning. The correct location is gimple location of current statement.
ChangeLog:
2015-08-29 Chen Gang gang.chen.5...@gmail.com
* fold-const.c (fold_overflow_warning): Call warning_at instead
of call
2015-07-20 Chen Gang gang.chen.5...@gmail.com
* config/bfin/bfin.c (hwloop_optimize): Recognize direct jump
case and emit lsetup at loop head.
---
gcc/config/bfin/bfin.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/gcc/config/bfin/bfin.c b
On 7/7/15 06:09, Chen Gang wrote:
On 7/6/15 20:51, Bernd Schmidt wrote:
On 07/03/2015 04:13 AM, Chen Gang wrote:
I shall continue to analyse why 2nd lsetup optimiation has not happened.
Hope I can finish within next week (2015-07-12).
I've committed my patch after testing bfin-elf. There's
On 7/6/15 20:51, Bernd Schmidt wrote:
On 07/03/2015 04:13 AM, Chen Gang wrote:
On 07/01/2015 11:27 PM, Chen Gang wrote:
On 7/1/15 21:52, Bernd Schmidt wrote:
Below is a patch. Can you test this with anything you have beyond the
testsuite?
It can fix this issue (Bug66620), let the insns
On 07/01/2015 11:27 PM, Chen Gang wrote:
On 7/1/15 21:52, Bernd Schmidt wrote:
On 07/01/2015 03:04 AM, Chen Gang wrote:
For me, the more details are:
- The insns have 2 loops which can be lsetup optimized.
- After hwloop_optimize finishes 1st lsetup optimization, it generates
new
On 7/1/15 21:52, Bernd Schmidt wrote:
On 07/01/2015 03:04 AM, Chen Gang wrote:
For me, the more details are:
- The insns have 2 loops which can be lsetup optimized.
- After hwloop_optimize finishes 1st lsetup optimization, it generates
new lsetup insn which appends to jump insn
On 06/30/2015 03:46 AM, Bernd Schmidt wrote:
On 06/28/2015 04:15 PM, Chen Gang wrote:
For bfin looping optimization, after lsetup optimization, it can have
the correct lsetup related insns which causes gcc_assert for jump_insn.
I've been debugging this for a bit, and at least the explanation
For bfin looping optimization, after lsetup optimization, it can have
the correct lsetup related insns which causes gcc_assert for jump_insn.
The related bug is Bug 66620.
2015-06-28 Chen Gang gang.chen.5...@gmail.com
* config/bfin/bfin.c (hwloop_optimize): Use return false instead
On 6/24/15 12:25, Jeff Law wrote:
On 06/20/2015 04:48 AM, Chen Gang wrote:
JUMP_LABLE() must be defined after optimization completed. In this case,
it is doing optimization, and is almost finished, so it is no chances to
set JUMP_LABLE() next. The related issue is Bug 65803.
2015-06-20 Chen
JUMP_LABLE() must be defined after optimization completed. In this case,
it is doing optimization, and is almost finished, so it is no chances to
set JUMP_LABLE() next. The related issue is Bug 65803.
2015-06-20 Chen Gang gang.chen.5...@gmail.com
* config/bfin/bfin.c (hwloop_optimize
On 3/28/15 09:32, Chen Gang wrote:
On 3/27/15 21:03, Bernd Schmidt wrote:
On 03/27/2015 01:05 AM, Chen Gang wrote:
For misalignment memory access, c6x gcc will cause issue, so need remove
clobber (match_scratch ...) which will be symmetric with movmisalign
mode_load, then pass compiling
The related warning:
build/genrecog ../../gcc-c6x/gcc/common.md
../../gcc-c6x/gcc/config/c6x/c6x.md \
insn-conditions.md tmp-recog.c
[...]
../../gcc-c6x/gcc/config/c6x/c6x.md:1443: warning: source missing a mode?
[...]
2015-03-28 Chen Gang gang.chen.5...@gmail.com
: in
expansion of macro ‘TARGET_CPU_CPP_BUILTINS’
TARGET_CPU_CPP_BUILTINS ();
^
2015-03-28 Chen Gang gang.chen.5...@gmail.com
* config/c6x/c6x.h (TARGET_CPU_CPP_BUILTINS): Handle default
case for switch statement.
---
gcc/config/c6x/c6x.h | 3 +++
1 file changed, 3 insertions
On 3/27/15 21:03, Bernd Schmidt wrote:
On 03/27/2015 01:05 AM, Chen Gang wrote:
For misalignment memory access, c6x gcc will cause issue, so need remove
clobber (match_scratch ...) which will be symmetric with movmisalign
mode_load, then pass compiling and generate correct assembly code
On 3/27/15 08:05, Chen Gang wrote:
For misalignment memory access, c6x gcc will cause issue, so need remove
clobber (match_scratch ...) which will be symmetric with movmisalign
mode_load, then pass compiling and generate correct assembly code.
The related issue:
[root@localhost c6x
.d1t1 A3, *A4
ret .s2 B3
nop 5
.size oxu_driver_init, .-oxu_driver_init
.ident GCC: (GNU) 5.0.0 20150321 (experimental)
2015-03-27 Chen Gang gang.chen.5...@gmail.com
* config/c6x/c6x.md (movmisalignmode_store): Remove
communicating. gang.chen.5...@gmail.com is still have effect, but it is
not stable (gmail in China is not stable).
I apologize for inconvenience.
Thanks.
On 2/27/15 08:37, Chen Gang S wrote:
On 02/26/2015 08:13 PM, Chen Gang S wrote:
On 02/26/2015 04:04 PM, Chen Gang S wrote:
If check fails, genrecog
On 02/26/2015 08:13 PM, Chen Gang S wrote:
On 02/26/2015 04:04 PM, Chen Gang S wrote:
If check fails, genrecog needs to stop and report error, so can let the
issue be found in time. The implementation is referenced from gcc/doc/
md.log:
[...]
whitespace
Whitespace characters
-02-26 Chen Gang gang.chen.5...@gmail.com
* genrecog.c (validate_pattern): Check matching constraint in
MATCH_OPERAND and use 'opnu' for all 'XINT (pattern, 0)'.
---
gcc/genrecog.c | 39 +++
1 file changed, 35 insertions(+), 4 deletions(-)
diff
On 02/26/2015 04:04 PM, Chen Gang S wrote:
If check fails, genrecog needs to stop and report error, so can let the
issue be found in time. The implementation is referenced from gcc/doc/
md.log:
[...]
whitespace
Whitespace characters are ignored and can be inserted at any
On 2/24/15 23:54, Jeff Law wrote:
On 02/23/15 18:33, Chen Gang S wrote:
OK, thanks. I shall try to finish within this month (although I am
not quite sure whether I can finish on time).
No problem. Any contribution you can make in this area is appreciated.
OK, thanks.
OK, thanks. May I
On 2/25/15 01:03, augustine.sterl...@gmail.com wrote:
On Tue, Feb 24, 2015 at 9:05 AM, Chen Gang S gang.c...@sunrus.com.cn wrote:
- After this patch, it can continue compiling, but can we be sure that
it always generates correct code for execution?
After this patch, it should
On 2/25/15 03:22, Jeff Law wrote:
On 02/24/15 10:29, Chen Gang S wrote:
So for me, I shall let genrecog report error instead of warning when it
find this issue, next.
Yes, I think an error would be appropriate here. That way nobody has to
debug same issue you just did in find_reloads
to
me. :-)
Thanks.
--
Chen Gang
Open, share, and attitude like air, water, and life which God blessed
several arrays before use them in
find_reloads() will cause correctness issue? (I guess not, it will skip
optimization, but not cause correctness issue, and continue compiling).
Thanks.
--
Chen Gang
Open, share, and attitude like air, water, and life which God blessed
them too.
This issue is found by cross compiling xtensa Linux kernel with the
latest gcc5. And after this patch, it can cross compile xtensa Linux
kernel with allmodconfig, successfully.
2015-02-22 Chen Gang gang.chen.5...@gmail.com
* reload.c (find_reloads): Initialize several arrays
On 1/31/15 16:53, Andreas Schwab wrote:
Chen Gang S gang.c...@sunrus.com.cn writes:
* gthr-single.h (__GTHREAD_MUTEX_INIT_FUNCTION): Use braces
instead of macro's empty body to avoid xgcc warnings.
It's actually an empty loop now.
Excuse me, I am not quite clear gcc version
On 1/31/15 19:49, Marek Polacek wrote:
On Sat, Jan 31, 2015 at 05:13:53PM +0530, Prathamesh Kulkarni wrote:
On 31 January 2015 at 15:30, Chen Gang S gang.c...@sunrus.com.cn wrote:
On 1/31/15 16:53, Andreas Schwab wrote:
Chen Gang S gang.c...@sunrus.com.cn writes:
* gthr-single.h
]
__GTHREAD_MUTEX_INIT_FUNCTION (__gcov_flush_mx);
^
2015-01-31 Chen Gang gang.chen.5...@gmail.com
* gthr-single.h (__GTHREAD_MUTEX_INIT_FUNCTION): Use empty do-
while loop as macro body.
---
libgcc/gthr-single.h | 2 +-
1 file
]
__GTHREAD_MUTEX_INIT_FUNCTION (__gcov_flush_mx);
^
2015-01-31 Chen Gang gang.chen.5...@gmail.com
* gthr-single.h (__GTHREAD_MUTEX_INIT_FUNCTION): Use breaces
instead of macro's empty body to avoid xgcc warnings.
---
libgcc
]
__GTHREAD_MUTEX_INIT_FUNCTION (__gcov_flush_mx);
^
2015-01-31 Chen Gang gang.chen.5...@gmail.com
* gthr-single.h (__GTHREAD_MUTEX_INIT_FUNCTION): Use braces
instead of macro's empty body to avoid xgcc warnings.
---
libgcc/gthr
On 1/31/15 06:57, Jakub Jelinek wrote:
On Sat, Jan 31, 2015 at 06:37:30AM +0800, Chen Gang S wrote:
The related warning (cross compile tile with --disable-threads):
../../../../gcc-tile-new/libgcc/libgcov-interface.c: In function
'__gcov_fork':
../../../../gcc-tile-new/libgcc/libgcov
Need free each array elements, or may cause memory leak.
2015-01-28 Chen Gang gang.chen.5...@gmail.com
* argv.c (expandargv): Use freeargv() instead of free() to avoid
memory leak.
---
libiberty/argv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On 1/28/15 20:02, Andrew Burgess wrote:
* Chen Gang S gang.c...@sunrus.com.cn [2015-01-28 19:34:38 +0800]:
libiberty/argv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libiberty/argv.c b/libiberty/argv.c
index f2727e8..9fdd55b 100644
--- a/libiberty/argv.c
+++ b
On 1/28/15 20:02, Andrew Burgess wrote:
* Chen Gang S gang.c...@sunrus.com.cn [2015-01-28 19:34:38 +0800]:
libiberty/argv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libiberty/argv.c b/libiberty/argv.c
index f2727e8..9fdd55b 100644
--- a/libiberty/argv.c
+++ b
On 1/27/15 05:56, Jeff Law wrote:
On 01/22/15 13:50, Chen Gang S wrote:
On 01/23/2015 03:53 AM, Jeff Law wrote:
On 01/22/15 12:42, Chen Gang S wrote:
Thank you very much for your help applying the 3 patches. :-)
No problem.
After finish the assignment working flow, I guess, I may have
On 1/26/15 03:50, Gerald Pfeifer wrote:
On Friday 2015-01-23 04:50, Chen Gang S wrote:
And I want to consult: for passing assignment working flow, must I
make a patch which contents much code lines? (At present, my patches
are all trivial patch).
No, the assignment process does not have
On 01/22/2015 02:46 AM, Mike Stump wrote:
On Jan 21, 2015, at 1:54 AM, Chen Gang S gang.c...@sunrus.com.cn wrote:
On 1/6/15 04:07, Jeff Law wrote:
* toplev.c (init_local_tick): Process the failure when read
fails for random_seed.
This is fine for the trunk. Please install.
I am
On 11/24/2014 04:24 PM, Jakub Jelinek wrote:
On Mon, Nov 24, 2014 at 04:28:10PM +0800, Chen Gang wrote:
On 11/24/14 15:41, Jakub Jelinek wrote:
On Sun, Nov 23, 2014 at 09:13:27AM +0800, Chen Gang wrote:
[...]
+else
+ pp_wide_int(pretty_name,
+ wi::add
On 10/08/2014 10:52 PM, Richard Henderson wrote:
On 10/08/2014 03:47 AM, Chen Gang wrote:
It passes make -k check under Darwin x86_64.
2014-10-07 Chen Gang gang.chen.5...@gmail.com
* unwind-dw2-fde.h (last_fde): Use (const fde *) instead of
(char *) to avoid qualifier warning
On 01/23/2015 03:53 AM, Jeff Law wrote:
On 01/22/15 12:42, Chen Gang S wrote:
Thank you very much for your help applying the 3 patches. :-)
No problem.
After finish the assignment working flow, I guess, I may have the write
access, then can finish these kinds of trivial patches by myself
On 1/6/15 04:07, Jeff Law wrote:
On 12/28/14 21:04, Chen Gang S wrote:
When failure occurs, random_seed may not be 0, so need reset it to 0
manually, or will let the next call init_random_seed() incorrect. The
related warning:
g++ -c -DTARGET_NAME=\parisc-gchen-linux\ -g -O2 -DIN_GCC
On 1/20/15 10:11, Joseph Myers wrote:
On Mon, 19 Jan 2015, Chen Gang S wrote:
On 12/31/2014 06:26 AM, Joseph Myers wrote:
On Mon, 29 Dec 2014, Chen Gang S wrote:
And in honest, this year what I have done is really not quite well, next
year I should be improved: should scanning Bugzilla
On 12/31/2014 06:26 AM, Joseph Myers wrote:
On Mon, 29 Dec 2014, Chen Gang S wrote:
And in honest, this year what I have done is really not quite well, next
year I should be improved: should scanning Bugzilla and try to fix the
existing issues (just like another members' suggestions to me
you try that and report back to me?
Nevermind. I went ahead and made this change and verified that libgcc,
libquadmath and newlib would build for the h8300-elf configuration.
Thank you for your work.
--
Chen Gang
Open, share, and attitude like air, water, and life which God blessed
as
parameter 1, and stack (8,er6) and (12,er6) for parameter 2, return
value is er0 and er1. And the internal algorithim is also correct.
2015-01-11 Chen Gang gang.chen.5...@gmail.com
* config/h8300/h8300.c (F): Use rtx instead of rtx_insn *.
(Fpa): Remove additional check
issue for h8300.
2015-01-10 Chen Gang gang.chen.5...@gmail.com
* ipa-icf.c (sem_function::equals_private): Use '' instead of
'||' to fix typo issue.
* gcc/tree.h (target_opts_for_fn): Check NULL_TREE since it can
accept and return NULL.
---
gcc/ipa-icf.c | 2
On 1/6/15 04:07, Jeff Law wrote:
On 12/28/14 21:04, Chen Gang S wrote:
When failure occurs, random_seed may not be 0, so need reset it to 0
manually, or will let the next call init_random_seed() incorrect. The
related warning:
g++ -c -DTARGET_NAME=\parisc-gchen-linux\ -g -O2 -DIN_GCC
guess, there is no qemu or sim for tile).
And also excuse me, during these days, gmail is broken in China, I have
to use my another mail address to send/receive emails.
Thanks.
On 12/21/14 05:45, Chen Gang wrote:
On 12/21/2014 12:31 AM, Michael Eager wrote:
On 12/20/14 02:09, Chen Gang wrote
On 12/31/14 06:26, Joseph Myers wrote:
On Mon, 29 Dec 2014, Chen Gang S wrote:
And in honest, this year what I have done is really not quite well, next
year I should be improved: should scanning Bugzilla and try to fix the
existing issues (just like another members' suggestions to me
: warning: ignoring return value of 'ssize_t
read(int, void*, size_t)', declared with attribute warn_unused_result
[-Wunused-result]
It passes testsuite under x86_64-apple-darwin14.0.0
/gcc
2014-12-27 Chen Gang gang.chen.5...@gmail.com
* toplev.c (init_local_tick): Process the failure
, next
year I should be improved: should scanning Bugzilla and try to fix the
existing issues (just like another members' suggestions to me).
Thanks.
On 12/29/14 12:04, Chen Gang S wrote:
When failure occurs, random_seed may not be 0, so need reset it to 0
manually, or will let the next call
/29/2014 06:25 PM, Chen Gang wrote:
Hello Maintainers:
After analysing, it is not kernel's issue, it is gcc issue, after let
kernel related variable bypass this gcc issue, the kernel can start up
successfully.
The issue is after declaration, the __attribute_((__section__
On 12/21/2014 12:31 AM, Michael Eager wrote:
On 12/20/14 02:09, Chen Gang wrote:
By the way, if this thread really has negative effect with other members,
please warn me, I should not notify it to mailing list again, and try my
best to finish it within myself.
I appreciate your enthusiasm
On 11/27/14 07:41, Chen Gang wrote:
OK, I shall send related test case within two weeks (2014-12-10).
Joseph Myers jos...@codesourcery.com wrote:
On Thu, 27 Nov 2014, Chen Gang wrote:
The original length 18 is not enough for HOST_WIDE_INT printing, need
use 20 instead of.
Also need
/release-microblaze
Thread model: single
gcc version 5.0.0 20141129 (experimental) (GCC)
After finish analysing, I shall start make check under microblaze qemu
(may need about 12-13 days for testing).
Welcome any ideas, suggestions, and completions.
Thanks.
On 11/20/2014 11:33 PM, Chen Gang
On 11/26/14 15:33, Jakub Jelinek wrote:
On Wed, Nov 26, 2014 at 09:41:16AM +0800, Chen Gang wrote:
On 11/26/14 8:31, Joseph Myers wrote:
On Wed, 26 Nov 2014, Chen Gang wrote:
+ gcc_assert (wi::fits_to_tree_p (value, char_type_node)
+|| wi::fits_to_tree_p (value
The original length 18 is not enough for HOST_WIDE_INT printing, need
use 20 instead of.
Also need additional bytes for printing related prefix and suffix, and
give a related check.
It passes testsuite under fedora 20 x86_64-unknown-linux-gnu.
2014-11-27 Chen Gang gang.chen.5...@gmail.com
OK, I shall send related test case within two weeks (2014-12-10).
Thanks.
Send from Lenovo A788t.
Joseph Myers jos...@codesourcery.com wrote:
On Thu, 27 Nov 2014, Chen Gang wrote:
The original length 18 is not enough for HOST_WIDE_INT printing, need
use 20 instead of.
Also need
If necessary to add related test case, please let me know.
Thanks.
Send from Lenovo A788t.
Jakub Jelinek ja...@redhat.com wrote:
On Mon, Nov 24, 2014 at 04:28:10PM +0800, Chen Gang wrote:
On 11/24/14 15:41, Jakub Jelinek wrote:
On Sun, Nov 23, 2014 at 09:13:27AM +0800, Chen Gang wrote
On 11/25/14 7:56, Joseph Myers wrote:
On Sun, 23 Nov 2014, Chen Gang wrote:
+ gcc_assert (wi::fits_to_tree_p(value, integer_type_node));
Watch formatting: space before '(' in the wi::fits_to_tree_p call.
Applies elsewhere in this patch as well.
OK, thanks, I shall notice next.
When
The original length 18 is not enough for HOST_WIDE_INT printing, need
use 20 instead of.
Also need additional bytes for printing related prefix and suffix, and
give a related check.
It passes testsuite under fedora 20 x86_64-unknown-linux-gnu.
2014-11-26 Chen Gang gang.chen.5...@gmail.com
On 11/26/14 8:31, Joseph Myers wrote:
On Wed, 26 Nov 2014, Chen Gang wrote:
+ gcc_assert (wi::fits_to_tree_p (value, char_type_node)
+ || wi::fits_to_tree_p (value, short_integer_type_node)
+ || wi::fits_to_tree_p (value, integer_type_node)
+ || wi
On 11/26/14 9:38, Joseph Myers wrote:
On Wed, 26 Nov 2014, Chen Gang wrote:
And I have no any ideas about the attachments in your reply mail. If it
is really related with this thread, please let me know.
I don't understand what attachments you are referring to.
Oh, sorry, my Thunderbird
On 11/24/14 15:41, Jakub Jelinek wrote:
On Sun, Nov 23, 2014 at 09:13:27AM +0800, Chen Gang wrote:
[...]
+ else
+pp_wide_int(pretty_name,
+wi::add (wi::to_widest (TYPE_MAX_VALUE (dom)), 1),
+TYPE_SIGN (TREE_TYPE (dom
OK, thank you for your work, I shall send patch v3 for it.
Send from Lenovo A788t.
Joseph Myers jos...@codesourcery.com wrote:
On Sun, 23 Nov 2014, Chen Gang wrote:
+ gcc_assert (wi::fits_to_tree_p(value, integer_type_node));
Watch formatting: space before '(' in the wi::fits_to_tree_p call
The original length 18 is not enough for HOST_WIDE_INT printing, need
use 20 instead of.
Also need additional bytes for printing related prefix and suffix, and
define the related macro in hwint.h.
It passes testsuite under fedora 20 x86_64-unknown-linux-gnu.
2014-11-23 Chen Gang gang.chen.5
white spaces alignment coding styles (originally,
some of code is 1 white space alignment).
It passes testsuite under fedora 20 x86)64-unknown-linux-gnu.
2014-11-23 Chen Gang gang.chen.5...@gmail.com
* ubsan.c (ubsan_type_descriptor): Use 'pretty_print' for
'pretty_name' to avoid
alignment).
It passes testsuite under fedora 20 x86_64-unknown-linux-gnu.
2014-11-22 Chen Gang gang.chen.5...@gmail.com
* ubsan.c (ubsan_type_descriptor): Use 'pretty_print' for
'pretty_name' to avoid memory overflow
---
gcc/ubsan.c | 57
Thank you very much for your work. I shall send patch v3 for it.
Thanks.
On 11/22/2014 05:57 AM, Jakub Jelinek wrote:
On Sat, Nov 22, 2014 at 05:03:37AM +0800, Chen Gang wrote:
According to the next code, 'pretty_name' may need additional bytes more
than 16 (may have unlimited length
On 11/17/14 18:52, Chen Gang wrote:
What you said sound reasonable to me.
I shall try to send patch v2 within this week (use pretty_printer).
Thanks.
On 11/17/14 16:15, Marek Polacek wrote:
On Mon, Nov 17, 2014 at 08:38:19AM +0100, Jakub Jelinek wrote:
I think easiest would
to analyze the cross compiled Linux kernel will run
in dead lock issue. After finish analyzing, I shall restart the test.
I guess it needs 12-13 days (more than a week -- I originally expected).
Thanks.
On 11/9/14 21:15, Chen Gang wrote:
At present, I use simplified sshd, ssh and scp (dropbear
OK, thank you for your details description.
I shall send patch v2 for it, within this week.
Send from Lenovo A788t.
Joseph Myers jos...@codesourcery.com wrote:
On Thu, 20 Nov 2014, Chen Gang wrote:
OK, thanks. I guess your meaning is:
- If the value is small enough to be expressed
On 11/20/14 1:20, Joseph Myers wrote:
On Wed, 19 Nov 2014, Chen Gang wrote:
OK, thanks, what you said sounds reasonable to me. We need '(' and ')'
for negative members, and LL for the members which is larger than 32
bits.
I don't think LL is a good idea when not needed - quite possibly
On 11/18/14 0:38, Joseph Myers wrote:
On Sat, 15 Nov 2014, Chen Gang wrote:
Also in c_common_read_pch(), when failure occurs, also need be sure the
'fd' is not '-1' for the next close operation.
Please clarify how c_common_read_pch gets called with fd == -1.
Certainly checking after
On 11/19/14 0:44, Joseph Myers wrote:
On Sun, 16 Nov 2014, Chen Gang wrote:
The maximize 64-bits integer decimal string length excluding NUL is 20 (
'-9223372036854775808'), so need use 20 instead of 18 for HOST_WIDE_INT.
2014-11-16 Chen Gang gang.chen.5...@gmail.com
* c-family/c
On 11/19/14 11:03, Chen Gang wrote:
On 11/19/14 0:44, Joseph Myers wrote:
On Sun, 16 Nov 2014, Chen Gang wrote:
The maximize 64-bits integer decimal string length excluding NUL is 20 (
'-9223372036854775808'), so need use 20 instead of 18 for HOST_WIDE_INT.
2014-11-16 Chen Gang gang.chen
17, 2014 at 06:40:26AM +0800, Chen Gang wrote:
According to the next code, 'pretty_name' may need additional bytes more
than 16. For simplify thinking and being extensible in future, extent it
to 256 bytes, directly.
I think + 128 bytes should be enough for everyone.
I disagree.
Consider
The maximize 64-bits integer decimal string length excluding NUL is 20 (
'-9223372036854775808'), so need use 20 instead of 18 for HOST_WIDE_INT.
2014-11-16 Chen Gang gang.chen.5...@gmail.com
* c-family/c-cppbuiltin.c (builtin_define_with_int_value): Use
20 instead of 18
When 'is_str' is true, need consider about 2 '' for the extra space, or
will cause memory overflow.
2014-11-16 Chen Gang gang.chen.5...@gmail.com
* c-family/c-cppbuiltin.c (builtin_define_with_value): Add two
bytes for avoiding memory overflow issue.
---
gcc/c-family/c
Oh, sorry, it is incorrect, original code is already add 2 bytes for it.
Thanks.
On 11/16/2014 10:32 PM, Chen Gang wrote:
When 'is_str' is true, need consider about 2 '' for the extra space, or
will cause memory overflow.
2014-11-16 Chen Gang gang.chen.5...@gmail.com
* c-family
According to the next code, 'pretty_name' may need additional bytes more
than 16. For simplify thinking and being extensible in future, extent it
to 256 bytes, directly.
It passes testsuite under fedora 20 x86_64-unknown-linux-gnu.
2014-11-17 Chen Gang gang.chen.5...@gmail.com
'fd' may be 0 which does not need 'open' operation, so neither need
'close' operation on it when it is 0.
Also in c_common_read_pch(), when failure occurs, also need be sure the
'fd' is not '-1' for the next close operation.
It passes testsuite under Fedora x86_64-unknown-linux-gnu.
gcc/
1 - 100 of 206 matches
Mail list logo
