e and which emit the
> profiling bits directly rather 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
>>>
>>> r10 may also be as parameter stack pointer for the nested function, so
>>> need save it before call mcount.
>>>
>>>
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
>
"\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.
>>
>>
stack pointer 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
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 really compare only 32-bit values
for
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 wrote:
>>>
>>> Note th
o see us not use input_location
> but always loc,
For me, it sounds reasonable.
> even if UNKNOWN_LOCATION. The diagnostic machinery should handle this
> correctly(?). That is, if bootstrap/testign doesn't show testsuite
> regressions because
> of this.
>
I will try.
Ho
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
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 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 would be if it is, or is not a bug.
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
>> wrote:
>>>
>>> It is about
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
From fadd991f87dbd5752e9b6a2cce300dfe7cc8af25 Mon Sep 17 00:00:00 2001
From: Chen Gang
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. bfin), when this case occurs
On 8/31/15 19:12, Richard Biener wrote:
> On Sat, Aug 29, 2015 at 2:57 PM, Chen Gang
> wrote:
>>
>> It is about bug63510: current input_location isn't precise for reporting
>> warning. The correct location is gimple location of current statement.
>
> Looks ok t
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
* fold-const.c (fold_overflow_warning): Call warning_at instead
of call warning.
* tre
2015-07-20 Chen Gang
* 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/gcc/config/bfin/bfin.c
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).
>>
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
>>>> tes
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.
>>>
>>>
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
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 f
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
* config/bfin/bfin.c (hwloop_optimize): Use return false instead
of gcc_assert for
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
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
* config/bfin/bfin.c (hwloop_optimize): Set JUMP_LABEL() after
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
* config/c6x/c6x.md (mv
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 wi
expansion of macro ‘TARGET_CPU_CPP_BUILTINS’
TARGET_CPU_CPP_BUILTINS ();
^
2015-03-28 Chen Gang
* 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(+)
diff --git a/gcc
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
>> _load", then pass com
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
> _load", then pass compiling and generate correct assembly code.
>
> The re
A3
nop 4
stnw.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
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:
>>&
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":
&
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
-unknown-linux-gnu building all-gcc, it is OK, too.
2015-02-26 Chen Gang
* genrecog.c (validate_pattern): Check matching constraint in
MATCH_OPERAND and use 'opnu' for all 'XINT (pattern, 0)'.
---
gcc/genrecog.c | 39 +++--
And also thank Max very much for his warmhearted response in every where
(kernel, qemu, and gcc). I am sure your response will give much help to
me. :-)
Thanks.
--
Chen Gang
Open, share, and attitude like air, water, and life which God blessed
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
On 2/25/15 01:03, augustine.sterl...@gmail.com wrote:
> On Tue, Feb 24, 2015 at 9:05 AM, Chen Gang S 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 sho
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, t
nish it before fixing xtensa pattern? I
guess it is more easier than fixing xtensa patten. (I guess 'warming' is
'warning'.)
By the way, can this patch "initialize several arrays before use them in
find_reloads()" will cause correctness issue? (I guess not, it will
s_alternative_offmemok', and 'this_alternative_earlyclobber' may
be not initialized either, so initialize 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,
tement [-Wempty-body]
__GTHREAD_MUTEX_INIT_FUNCTION (&__gcov_flush_mx);
^
2015-01-31 Chen Gang
* gthr-single.h (__GTHREAD_MUTEX_INIT_FUNCTION): Use empty do-
while loop as macro body.
---
libgcc/gthr-single.h | 2 +-
1 f
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 wrote:
>>> On 1/31/15 16:53, Andreas Schwab wrote:
>>>> Chen Gang S writes:
>>>>
>>>>
On 1/31/15 16:53, Andreas Schwab wrote:
> Chen Gang S 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 qu
tement [-Wempty-body]
__GTHREAD_MUTEX_INIT_FUNCTION (&__gcov_flush_mx);
^
2015-01-31 Chen Gang
* gthr-single.h (__GTHREAD_MUTEX_INIT_FUNCTION): Use braces
instead of macro's empty body to avoid xgcc warnings.
---
l
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
tement [-Wempty-body]
__GTHREAD_MUTEX_INIT_FUNCTION (&__gcov_flush_mx);
^
2015-01-31 Chen Gang
* gthr-single.h (__GTHREAD_MUTEX_INIT_FUNCTION): Use breaces
instead of macro's empty body to avoid xgcc warnings.
---
l
On 1/28/15 20:02, Andrew Burgess wrote:
> * Chen Gang S [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 10064
On 1/28/15 20:02, Andrew Burgess wrote:
> * Chen Gang S [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 10064
Need free each array elements, or may cause memory leak.
2015-01-28 Chen Gang
* 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 a/libiberty/argv.c b/libiberty
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. :-)
>
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,
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
>> a
On 01/23/2015 12:41 AM, Jeff Law wrote:
> On 01/22/15 04:55, Chen Gang S wrote:
>> On 01/22/2015 02:46 AM, Mike Stump wrote:
>>> On Jan 21, 2015, at 1:54 AM, Chen Gang S wrote:
>>>> On 1/6/15 04:07, Jeff Law wrote:
>>>>>
>>>>>>
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
>>
>> * unwind-dw2-fde.h (last_fde): Use "(const fde *)" instea
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:
>>
>> [...]
>>
>>>> +
On 01/22/2015 02:46 AM, Mike Stump wrote:
> On Jan 21, 2015, at 1:54 AM, Chen Gang S 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
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 -DTARG
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, n
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 anot
t;> seems that we could just replace the call to "F" in "Fpa" with
>>
>> RTX_FRAME_RELATED_P (XVECEXP (par, 0, i)) = 1;
>>
>>
>> That simplifies the code and removes a bogus as_a cast.
>>
Yeah, for me, it is a good idea.
>> Can you t
__muldi3, .-___muldi3
.ident "GCC: (GNU) 5.0.0 20150109 (experimental)"
.end
For mode(DI), it generates 64-bit integer, so it uses er0 and er1 as
parameter 1, and stack (8,er6) and (12,er6) for parameter 2, return
value is er0 and er1. And the internal algo
"make all-target-libgcc"
under h8300, after fix this issue, it can continue to cross compiling to
meet the next building issue for h8300.
2015-01-10 Chen Gang
* ipa-icf.c (sem_function::equals_private): Use '&&' instead of
'||' to fix typo issu
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 -DTARG
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 G
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 me
, 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 th
/gcc/toplev.c:276:56: 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
* toplev.c (init_local_tick): Process the f
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.
&
ks.
On 11/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 d
On 11/27/14 07:41, Chen Gang wrote:
> OK, I shall send related test case within two weeks (2014-12-10).
>
> Joseph Myers 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
uggestions, and completions.
Thanks.
On 11/20/2014 11:33 PM, Chen Gang wrote:
>
> Oh, sorry, after ran more than 10 days, the qemu crashed :-(
>
> After checked the output log, and compare with the original log, we know
> we have finished more than 90% test, and it is OK (no any
If necessary to add related test case, please let me know.
Thanks.
Send from Lenovo A788t.
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 +080
OK, I shall send related test case within two weeks (2014-12-10).
Thanks.
Send from Lenovo A788t.
Joseph Myers 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.
>>
>>
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
* c-family/c
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)
>
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 re
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_n
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
* c-family/c
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, thank you for your work, I shall send patch v3 for it.
Send from Lenovo A788t.
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::fit
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),
>> +
e_int' for it.
Let the code meet 2 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
* ubsan.c (ubsan_type_descriptor): Use 'pretty_print'
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
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 (
some of code is 1 white sapce alignment).
It passes testsuite under fedora 20 x86_64-unknown-linux-gnu.
2014-11-22 Chen Gang
* ubsan.c (ubsan_type_descriptor): Use 'pretty_print' for
'pretty_name' to avoid memory overflow
---
gcc/ubsan.c | 57 +++
OK, thank you for your details description.
I shall send patch v2 for it, within this week.
Send from Lenovo A788t.
Joseph Myers wrote:
>On Thu, 20 Nov 2014, Chen Gang wrote:
>
>> OK, thanks. I guess your meaning is:
>>
>> - If the value is small enough to be exp
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 s
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
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.
>
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
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
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
e:
>>> On Mon, Nov 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, dir
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
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
When 'is_str' is true, need consider about 2 '"' for the extra space, or
will cause memory overflow.
2014-11-16 Chen Gang
* c-family/c-cppbuiltin.c (builtin_define_with_value): Add two
bytes for avoiding memory overflow issue.
---
gcc/c-family/c-cp
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
* c-family/c-cppbuiltin.c (builtin_define_with_int_value): Use
20 instead of 18 for the maximi
1 - 100 of 207 matches
Mail list logo
