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).
>>
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
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 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
>> wrote:
>>>
>>> It is about
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.
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
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
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
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
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
Excuse me, I can not find it with `find ./ | grep "\.sum$"`
[...]
>
After comparing, should the related ".sum" files be the same (same means
pass checking)?
Thanks.
--
Chen Gang
Open, share, and attitude like air, water, and life which God blessed
On 8/10/14 0:55, Chen Gang wrote:
> On 8/1/14 6:36, Jeff Law wrote:
>>
>> make
>> make check
>
> It is OK (I finish the 2 steps under Mac book).
>
>>
>
> Excuse me, I can not find it with `find ./ | grep "\.sum$"`
>
> [...]
>&g
For "[%d]" in sprintf(), theoretically, the maximize size is 14 -- for
0x8000, it is sizeof("[-2147483648]"). Normally, it may not cause
real world bug, but if another issues occur, it may lead things worse.
It passes "make && make check" under x86_64-app
On 8/3/14 13:50, Chen Gang wrote:
> Excuse me, after tried, I still did not know hot to build the source
> code for "x86_64-unknown-linux-gnu/32/libjava/classpath/native/jni".
> What I have done is:
>
> - ../gcc/configure --enable-core-jni --enable-languages=c,c++,
On 08/10/2014 04:03 PM, Mike Stump wrote:
> On Aug 9, 2014, at 9:55 AM, Chen Gang wrote:
>>>
>>
>> Excuse me, I can not find it with `find ./ | grep "\.sum$”`
>
> Then you didn’t do a test suite run. make check will create .sum files. Try
> cd gcc
onfigure_args="$ac_configure_args --with-vm-classes=$dir1:$dir2"
6830 ac_configure_args="$ac_configure_args --disable-core-jni"
6831 ac_configure_args="$ac_configure_args --disable-examples"
6832 ac_configure_args="$ac_configure_args --with-glibj=build"
On 08/
On 08/10/2014 04:22 PM, Chen Gang wrote:
>
> I guess, I find the root cause:
>
Although I say "I guess", in fact, I already had related proofs for it.
- When configure "libjava/classpath", "--disable-core-jni" is passed
as parameter explicitly (c
On 08/12/2014 04:25 AM, Joseph S. Myers wrote:
> On Sun, 10 Aug 2014, Chen Gang wrote:
>
>> For "[%d]" in sprintf(), theoretically, the maximize size is 14 -- for
>> 0x8000, it is sizeof("[-2147483648]"). Normally, it may not cause
>> real world b
On 8/12/14 7:38, Mike Stump wrote:
> On Aug 11, 2014, at 2:27 PM, Chen Gang wrote:
>> Welcome additional disccusions or completions, and if no any additional
>> reply within 1 week, I shall send patch v2 for it (still use sprintf).
>
> So, my take is it is easier for a ma
On 8/12/14 4:20, Chen Gang wrote:
> On 08/10/2014 04:22 PM, Chen Gang wrote:
>>
>> I guess, I find the root cause:
>>
I have given the test, if remove the hardcoded "--disable-core-jni" from
libjava/configure, we can let "JNIDIR" enabled.
So I am
Firstly, thank you very much for spending your time resource on the
related 2 patches.
On 8/13/14 23:10, Michael Eager wrote:
> On 07/06/14 03:26, Chen Gang wrote:
>>
>>* microblaze/mocroblaze.md (call_value_intern): Use 'SI' instead of
>>'VOID'
and let me know when you have this resolved.
OK, thanks. I shall try to finish within next week (2014-08-24).
Thanks.
--
Chen Gang
Open, share, and attitude like air, water, and life which God blessed
On 08/10/2014 04:15 PM, Chen Gang wrote:
> On 08/10/2014 04:03 PM, Mike Stump wrote:
>> On Aug 9, 2014, at 9:55 AM, Chen Gang wrote:
>>>>
>>>
>>> Excuse me, I can not find it with `find ./ | grep "\.sum$”`
>>
>> Then you didn’t do a test su
ld issue, but if another issues occur, it may
lead things worse.
2014-08-17 Chen Gang
* c/c-aux-info.c (gen_type): Resize 'buff' from 10 to 23 bytes.
---
gcc/c/c-aux-info.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/gcc/c/c-aux-info.c b/gcc/c/
On 08/18/2014 03:05 PM, Bin.Cheng wrote:
> On Sun, Aug 17, 2014 at 6:48 PM, Chen Gang wrote:
>> On 08/10/2014 04:15 PM, Chen Gang wrote:
>>> On 08/10/2014 04:03 PM, Mike Stump wrote:
>>>> On Aug 9, 2014, at 9:55 AM, Chen Gang wrote:
>>>>>>
>
On 8/18/14 18:07, Bin.Cheng wrote:
> On Mon, Aug 18, 2014 at 6:06 PM, Chen Gang wrote:
>> On 08/18/2014 03:05 PM, Bin.Cheng wrote:
>>> On Sun, Aug 17, 2014 at 6:48 PM, Chen Gang wrote:
>>>> On 08/10/2014 04:15 PM, Chen Gang wrote:
>>>>> On 08/10/201
which related with microblaze,
I have to delay, too. Hope I can finish within next month (2014-09-30).
Welcome any ideas, suggestions, or completions.
Thanks.
On 08/17/2014 07:04 PM, Chen Gang wrote:
>
> And sorry, I did not finish "make check" at the time point. I wasted my
On 08/18/2014 06:17 PM, Chen Gang wrote:
> Then you didn't do a test suite run. make check will create .sum files. Try
> cd gcc && make check. Then in testsuite/gcc/gcc.sum there will be a file.
>>>>>>>
After get a new PC, I guess, I have passed "
On 08/21/2014 02:06 AM, Joseph S. Myers wrote:
> On Sun, 17 Aug 2014, Chen Gang wrote:
>
>> 2014-08-17 Chen Gang
>>
>> * c/c-aux-info.c (gen_type): Resize 'buff' from 10 to 23 bytes.
>
> This patch is OK, subject to testing, though the ChangeLog
On 08/21/2014 01:35 AM, Mike Stump wrote:
> On Aug 20, 2014, at 7:26 AM, Chen Gang wrote:
>> - for each test, always contents "unexpected errors" for gcc, g++ ...
>> but "make check" skip them and continue, at last still "echo $?" = 0.
>
>
On 08/21/2014 03:23 AM, Mike Stump wrote:
> On Aug 20, 2014, at 11:29 AM, Chen Gang wrote:
>>
>> It sounds useful to me. At present, my PC is 4 core, so I guess, -j2
>
> No, -j4…. should be around twice as fast as -j2 on your machine (assuming
> you aren’t mem
On 08/22/2014 12:18 AM, Mike Stump wrote:
> On Aug 18, 2014, at 3:06 AM, Chen Gang wrote:
>> - one for original latest gcc source code (master for 20140816).
>>
>> - one for my modification based on the original latest gcc source code.
>>
>> - they passed b
in/sh ./compare_tests /tmp/gxx-sum1.7678 /tmp/gxx-sum2.7678
# No differences found in 11 common sum files
2014-08-17 Chen Gang
* c/c-aux-info.c (gen_type): Resize 'buff' from 10 to 23 bytes,
with using HOST_WIDE_INT without truncation to 'int'
---
On 8/22/14 7:11, Joseph S. Myers wrote:
> On Fri, 22 Aug 2014, Chen Gang wrote:
>
>> 2014-08-17 Chen Gang
>>
>> * c/c-aux-info.c (gen_type): Resize 'buff' from 10 to 23 bytes,
>> with using HOST_WIDE_INT without truncation to 'int'
compare",
I guess, at present, it is not really used by outside, though.
2014-08-27 Chen Gang
* sanitizer_common/sanitizer_linux_libcdep.cc
(SanitizerGetThreadName): Avoid writing '\0' out of string's
border
---
libsanitizer/sanitizer_common/san
On 08/28/2014 05:19 AM, Jeff Law wrote:
> On 08/21/14 15:44, Chen Gang wrote:
>> int_size_in_bytes() returns HOST_WIDE_INT (64-bit), theoretically, the
>> maximized size is 23 -- it is sizeof("[-9223372036854775808]") for
>> 0x8000LL.
>>
>>
like common sense (especially for extern functions).
If this extern function is not real used, at present (but will be used
next), for me, I still want to improve it (about max_len).
Thanks.
> --kcc
>
> On Wed, Aug 27, 2014 at 3:43 PM, Chen Gang wrote:
>> 'max_len'
On 8/28/14 6:58, Chen Gang wrote:
> On 08/28/2014 06:51 AM, Konstantin Serebryany wrote:
>> But, what makes you think there is a bug here?
>> The comment in sanitizer_common/sanitizer_common.h says:
>> // name should have space for at least max_len+1 bytes.
>>
>
>
On 9/1/14 16:41, Jakub Jelinek wrote:
> On Thu, Aug 28, 2014 at 06:43:02AM +0800, Chen Gang wrote:
>> 'max_len' is the maximized length of 'name', so for writing '\0' to
>> "name[max_len]", it is out of string's border, need use "m
> On 8/13/14 23:10, Michael Eager wrote:
>> On 07/06/14 03:26, Chen Gang wrote:
>>>
>>>* microblaze/mocroblaze.md (call_value_intern): Use 'SI' instead of
>>>'VOID' for operand 1, just like 'call_internal1' has done.
>&
On 09/07/2014 11:17 PM, Chen Gang wrote:
>> On 8/13/14 23:10, Michael Eager wrote:
>>> On 07/06/14 03:26, Chen Gang wrote:
>>>>
>>>>* microblaze/mocroblaze.md (call_value_intern): Use 'SI' instead of
>>>>'VOID' fo
On 09/08/2014 10:24 AM, Chen Gang wrote:
> On 09/07/2014 11:17 PM, Chen Gang wrote:
>>> On 8/13/14 23:10, Michael Eager wrote:
>>>> On 07/06/14 03:26, Chen Gang wrote:
>>>>>
>>>>>* microblaze/mocroblaze.md (call_value_intern): Use &#
On 10/5/14 11:32, Chen Gang wrote:
> On 10/5/14 11:15, Chen Gang wrote:
>> On 9/25/14 8:12, Chen Gang wrote:
>>> OK, thanks, next month, I shall try Qemu for microblaze (I also focus on
>>> Qemu, and try to make patches for it).
>>>
>>> And, I also
On 10/6/14 16:37, Andrew Haley wrote:
> On 06/10/14 05:08, Chen Gang wrote:
>> After try normal configure, get almost the same result, I guess, our
>> testsuite under Darwin x86_64 is OK.
>>
>> If no any additional reply within a week, I shall continue to try to
>
On 10/6/14 21:54, Andrew Haley wrote:
> On 10/06/2014 02:53 PM, Chen Gang wrote:
>> On 10/6/14 16:37, Andrew Haley wrote:
>>> On 06/10/14 05:08, Chen Gang wrote:
>>>> After try normal configure, get almost the same result, I guess, our
>>>> testsuite unde
On 10/6/14 22:28, Andrew Haley wrote:
> On 10/06/2014 03:27 PM, Chen Gang wrote:
>> On 10/6/14 21:54, Andrew Haley wrote:
>>> On 10/06/2014 02:53 PM, Chen Gang wrote:
>>>> On 10/6/14 16:37, Andrew Haley wrote:
>>>>> On 06/10/14 05:08, Chen Gang wrote:
On 10/6/14 22:59, Andrew Haley wrote:
> On 10/06/2014 04:00 PM, Chen Gang wrote:
>> On 10/6/14 22:28, Andrew Haley wrote:
[...]
>>> The testsuite isn't breaking: it's telling you something useful.
>>>
>>
>> Sorry it is breaked, at present, I tempo
On 10/7/14 1:29, Mike Stump wrote:
> On Oct 6, 2014, at 8:36 AM, Chen Gang wrote:
>> For me, "make -k check" is suitable for one sub-system (e.g. for cross
>> building, and mainly focus on gcc), but not for global check (full
>> non-cross building check):
>
>
On 10/7/14 7:18, Chen Gang wrote:
> On 10/7/14 1:29, Mike Stump wrote:
>> On Oct 6, 2014, at 8:36 AM, Chen Gang wrote:
>>> For me, "make -k check" is suitable for one sub-system (e.g. for cross
>>> building, and mainly focus on gcc), but not for global che
obj->fde_end || f->length == 0;
^
It passes "make -k check" under Darwin x86_64.
2014-10-07 Chen Gang
* unwind-dw2-fde.h (last_fde): Use "(const fde *)" instead of
"(char *)" to avoid qualifier warning by 'xgcc' compiling.
---
libgcc/
OK, thanks, and after this patch, I shall try to find and send another patch
for gcc within this month. Hope I can succeed.
Thanks.
Send from Lenovo A788t.
Richard Henderson wrote:
>On 10/08/2014 03:47 AM, Chen Gang wrote:
>> It passes "make -k check" under Darwin x86_64
On 09/25/2014 08:12 AM, Chen Gang wrote:
> OK, thanks, next month, I shall try Qemu for microblaze (I also focus on
> Qemu, and try to make patches for it).
>
Excuse me, after tried upstream qemu, it cann't run microblaze correctly,
even for Xilinx qemu branch, I cann't run
On 10/21/14 22:55, Chen Gang wrote:
> On 09/25/2014 08:12 AM, Chen Gang wrote:
>> OK, thanks, next month, I shall try Qemu for microblaze (I also focus on
>> Qemu, and try to make patches for it).
>>
>
> Excuse me, after tried upstream qemu, it cann't run microbl
On 10/22/2014 09:34 AM, Chen Gang wrote:
>
>>>
>>> Yes, if you want to test on a target, you will need a target. You can
>>> either have a simulator (see binutils and sim/* for an example of how to
>>> write one) or target hardware in some form.
>>
On 10/27/14 2:22, Michael Eager wrote:
> On 10/26/14 03:36, Chen Gang wrote:
>> On 10/22/2014 09:34 AM, Chen Gang wrote:
>>>
>>>>>
>>>>> Yes, if you want to test on a target, you will need a target. You can
>>>>> either ha
*, const char*, const char*, ...)’:
../../gcc/gcc/dwarf2asm.c:167:50: warning: format not a string literal and no
format arguments [-Wformat-security]
Signed-off-by: Chen Gang
---
gcc/ChangeLog | 6 ++
gcc/dwarf2asm.c | 21 +
2 files changed, 19 insertions(+), 8
On 06/16/2014 10:37 PM, Joseph S. Myers wrote:
> On Mon, 16 Jun 2014, Chen Gang wrote:
>
>> +static_output_delta (int size, const char *lab1, const char *lab2,
>
> static_ is not a helpful naming convention, since the fact that a function
> is static is nothing to do wi
*, const char*, const char*, ...)’:
../../gcc/gcc/dwarf2asm.c:167:50: warning: format not a string literal and no
format arguments [-Wformat-security]
Signed-off-by: Chen Gang
---
gcc/ChangeLog | 6 ++
gcc/dwarf2asm.c | 21 +
2 files changed, 19 insertions(+), 8
sorry for I have lost a chance to fix a issue about h8300, because
it is never used for linux main line, it is beyond my border (I have no
enough time resource on it), at present.
Thanks.
On 06/17/2014 09:00 AM, Chen Gang wrote:
> dw2_asm_output_vms_delta() calls dw2_asm_output_delta() in
On 06/26/2014 06:25 AM, Chen Gang wrote:
>
> BTW: one linux kernel member found a gcc issue for the latest version
> (4.10.0 20140622 or later), but for old version (e.g. 4.10.0 2014060*),
> it is OK. It is my chance to fix it (hope can finish within 2014-06-30).
>
For this is
defconfig under score.
Signed-off-by: Chen Gang
---
gcc/ChangeLog | 5 +
gcc/c/c-decl.c | 11 +++
2 files changed, 16 insertions(+)
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 34e7c93..241a7b7 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,8 @@
+2014-06-29
gt; Thanks for the explanation. This patch is OK with the typo fixes Marek
> has noted.
>
Thank you very much for all of your work!
And I shall continue to find and try to solve other gcc issues, hope I
can provide a patch per month.
Thanks.
--
Chen Gang
Open, share, and attitude like air, water, and life which God blessed
* microblaze/microblaze.md: Remove redundant '@' to avoid compiling
warning.
The related warning:
../../gcc/gcc/config/microblaze/microblaze.md:516: '@' is redundant for
output template with single alternative
Signed-off-by: Chen Gang
---
gcc/config/microbla
* microblaze/mocroblaze.md (call_value_intern): Use 'SI' instead of
'VOID' for operand 1, just like 'call_internal1' has done.
The related warning:
../../gcc/gcc/config/microblaze/microblaze.md:2172: warning: operand 1
missing mode?
Signed-off-by: Chen Ga
'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/
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
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
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
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
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
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
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/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/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/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
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
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
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 +++
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 (
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
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'
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),
>> +
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/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.
>
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/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
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 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)
>
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
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.
>>
>>
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
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
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:
>>&
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
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
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
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/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
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
1 - 100 of 207 matches
Mail list logo
