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
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 issue, at present, I
score.
Signed-off-by: Chen Gang gang.chen.5...@gmail.com
---
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
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 gang.chen.5...@gmail.com
---
gcc/config/microblaze
* 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 Gang gang.chen.5...@gmail.com
'asm_out_file' may be 'stdout', so need check this case before close it.
Or 'stdout' may be closed -- since need not open 'stdout', either need
not close it.
ChangLog:
* topleve.c (finalize): Avoid to close 'asm_out_file' when it is
'stdout'.
Signed-off-by: Chen Gang gang.chen.5
On 07/23/2014 11:44 AM, Jeff Law wrote:
On 07/21/14 09:47, Chen Gang wrote:
'asm_out_file' may be 'stdout', so need check this case before close it.
Or 'stdout' may be closed -- since need not open 'stdout', either need
not close it.
ChangLog:
* topleve.c (finalize): Avoid to close
strlen() will get string length excluding '\0', but strcpy() will append
'\0' in the end, so need XNEWVEC additional byte, or cause memory over
flow.
Signed-off-by: Chen Gang gang.chen.5...@gmail.com
---
gcc/gcc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/gcc.c b
On 07/26/2014 05:12 AM, Jeff Law wrote:
On 07/23/14 16:17, Chen Gang wrote:
On 07/23/2014 11:44 AM, Jeff Law wrote:
On 07/21/14 09:47, Chen Gang wrote:
'asm_out_file' may be 'stdout', so need check this case before close
it.
Or 'stdout' may be closed -- since need not open 'stdout', either
/nios2/nios2.c (custom_builtin_name): Let it always be
zero terminated string.
Signed-off-by: Chen Gang gang.chen.5...@gmail.com
---
gcc/config/nios2/nios2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/config/nios2/nios2.c b/gcc/config/nios2/nios2.c
index a4e60c6
terminated string.
Signed-off-by: Chen Gang gang.chen.5...@gmail.com
---
gcc/config/nios2/nios2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/config/nios2/nios2.c b/gcc/config/nios2/nios2.c
index a4e60c6..e4e005b 100644
--- a/gcc/config/nios2/nios2.c
+++ b/gcc/config
On 07/26/2014 02:32 PM, Chung-Lin Tang wrote:
On 14/7/26 11:28 AM, Chen Gang wrote:
The related strncpy() for custom_builtin_name[*] may set 5 none-zero
characters, which may cause custom_builtin_name[*] is none-zero
terminated.
So add additional '\0' byte for custom_builtin_name
On 07/26/2014 03:59 PM, Andreas Schwab wrote:
Chen Gang gang.chen.5...@gmail.com writes:
If we need let custom_builtin_name[*] not only zero terminated, but also
zero pad, we need pass '4' to strncpy() instead of '5', that also will
clear all doubts.
If you pass 5 to strncpy to copy
On 07/26/2014 05:07 PM, Chung-Lin Tang wrote:
On 2014/7/26 03:33 PM, Chen Gang wrote:
On 07/26/2014 02:32 PM, Chung-Lin Tang wrote:
On 14/7/26 11:28 AM, Chen Gang wrote:
The related strncpy() for custom_builtin_name[*] may set 5 none-zero
characters, which may cause custom_builtin_name
but not be sure of zero terminated, 'errmsg' would
not be zero terminated string.
At present, it is not a bug -- all 'err_len' are large enough for it,
But it is an extern function, according to its interface, it assumes
'errmsg' may be truncated in the future, so still need fix it.
Signed-off-by: Chen
'errbuf' assumes itself will be zero terminated, and it also assumes
cpnative_getErrorString() may get larger length string than 'errbuf'.
So after strncpy(), 'errbuf' may not be zero terminated.
strncpy() is sure of zero pad, but not be sure of zero terminated.
Signed-off-by: Chen Gang
.
Also have another ways for finding trivial patches (e.g. how to find
resource leak when failure occurs, ...).
If these kinds of trivial patches are only bother most of members,
please let me know, and next, I shall not send this kinds of patches.
Thanks.
On 07/28/2014 08:16 PM, Chen Gang wrote
'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 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
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
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
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/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
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
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
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
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/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
Yeah, the comments are big, but the body is the smallest.
Send from Lenovo A788t.
Michael Eager ea...@eagerm.com wrote:
On 09/25/14 10:38, Michael Eager wrote:
On 09/25/14 07:03, Chen Gang wrote:
Need use VOID instead of SI, or when real VOIDmode comes, it does not
match SImode, so cause
, Chen Gang wrote:
Need use VOID instead of SI, or when real VOIDmode comes, it does not
match SImode, so cause issue. This patch can fix this issue and pass
testsuite.
The related test code ('void' will cause CALL instead of SET):
typedef void (*T)(void);
f1 ()
{
((T) 0
And excuse me, I am not quite familiar with adding testsuite, so during
I am trying, welcome any related ideas, suggestions or completions.
Thanks.
On 9/28/14 3:08, Chen Gang wrote:
I guess it is not in our test case, or after this patch, the new
should get a little better result than the old
For the original microblaze, it will report error with -O0 (and other
flags are all OK).
gcc/testsuite/:
2014-09-28 Chen Gang gang.chen.5...@gmail.com
* gcc.c-torture/compile/calls-void.c: New test.
---
gcc/testsuite/gcc.c-torture/compile/calls-void.c | 23 +++
1
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 need finish the testsuite under Darwin x86_64, next month for gcc.
I finish tried testsuit under Darwin x86_64, originally, I
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 need finish the testsuite under Darwin x86_64, next month for
gcc.
I finish tried testsuit
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 need finish the testsuite under Darwin x86_64, next month
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
analyze the libjava Throw_2 issue
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 under Darwin x86_64 is OK.
If no any additional reply
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:
After try normal configure, get almost the same result, I
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 temporarily skipped it and then can
let make check finish
On 10/7/14 1:29, Mike Stump wrote:
On Oct 6, 2014, at 8:36 AM, Chen Gang gang.chen.5...@gmail.com 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):
In our world
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 gang.chen.5...@gmail.com 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
;
^
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 by 'xgcc' compiling.
---
libgcc/unwind-dw2-fde.h | 2 +-
1 file changed, 1 insertion(+), 1
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 r...@redhat.com wrote:
On 10/08/2014 03:47 AM, Chen Gang wrote:
It passes make -k check under Darwin x86_64.
2014
*, 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 gang.chen.5...@gmail.com
---
gcc/ChangeLog | 6 ++
gcc/dwarf2asm.c | 21 +
2 files changed
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 with what that function does
*, 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 gang.chen.5...@gmail.com
---
gcc/ChangeLog | 6 ++
gcc/dwarf2asm.c | 21 +
2 files changed
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 correctly either. I
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 microblaze correctly,
even for Xilinx qemu
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.
After tried 'sim', I found the root cause is microblaze sim
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 have a simulator (see binutils and sim/* for an example of how to
write one) or target
On 10/27/14 9:42, Chen Gang wrote:
On 10/27/14 2:22, Michael Eager wrote:
Microblaze-sim provides basic instruction set architecture and memory
simulation.
There is no operating system support. (It's also quite old. I'm not sure
which version of the MB architecture it models
On 10/29/14 23:58, Chen Gang wrote:
On 10/27/14 9:42, Chen Gang wrote:
On 10/27/14 2:22, Michael Eager wrote:
Microblaze-sim provides basic instruction set architecture and memory
simulation.
There is no operating system support. (It's also quite old. I'm not sure
which version of the MB
for microbaze DejaGNU with microbaze qemu, and sorry again, I did not
finish it within this month.
Thanks.
On 10/30/14 22:04, Chen Gang wrote:
On 10/29/14 23:58, Chen Gang wrote:
On 10/27/14 9:42, Chen Gang wrote:
On 10/27/14 2:22, Michael Eager wrote:
Microblaze-sim provides basic instruction set
to bypass them, since
I have no enough time resource on it.
Welcome any ideas, suggestions or completions.
Thanks.
On 11/01/2014 01:07 AM, Chen Gang wrote:
At present, I use telnet (without password), login to microblaze qemu
successfully! :-)
- I compile busy box with the glibc
'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 max_len - 1
instead of.
Pass normal test suite: configure make make check compare,
I guess, at present, it is not really used by outside, though.
2014-08-27 Chen Gang
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.
It may not cause real world issue, but if another issues
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 gang.chen.5...@gmail.com wrote:
'max_len' is the maximized length of 'name', so for writing '\0
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.
Oh, really, but for me, I still prefer
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 max_len - 1
instead of.
Depends on how the function's API is defined
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.
The related warning:
../../gcc/gcc/config/microblaze/microblaze.md:2172
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' for operand 1, just like 'call_internal1' has done.
The related warning:
../../gcc/gcc
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 'SI' instead of
'VOID' for operand 1, just like 'call_internal1' has done
Hello maintainers:
I also find some warnings during compiling microblaze, I also shall try
to fix them, but excuse me, I am not quite familiar the testsuite for
microblaze, could you provide any related information for it?
Thanks.
On 09/08/2014 11:28 PM, Chen Gang wrote:
On 09/08/2014 10:24 AM
On 9/15/14 11:03, Michael Eager wrote:
On 09/14/14 00:51, Chen Gang wrote:
Hello maintainers:
I also find some warnings during compiling microblaze, I also shall try
to fix them, but excuse me, I am not quite familiar the testsuite for
microblaze, could you provide any related information
On 09/15/2014 11:30 PM, Michael Eager wrote:
On 09/14/14 21:19, Chen Gang wrote:
On 9/15/14 11:03, Michael Eager wrote:
On 09/14/14 00:51, Chen Gang wrote:
Hello maintainers:
I also find some warnings during compiling microblaze, I also shall try
to fix them, but excuse me, I am not quite
On 09/16/2014 08:33 PM, Michael Eager wrote:
On 09/15/14 15:53, Chen Gang wrote:
On 09/15/2014 11:30 PM, Michael Eager wrote:
Configuring DejaGNU for cross-target testing requires creating a
configuration
file describing the target board.
OK, thank you very much. And could you share
Thank you very much for your quickly response, I shall continue try.
Thanks.
On 09/21/2014 12:31 AM, Michael Eager wrote:
On 09/20/14 08:52, Chen Gang wrote:
Thank you very much for your attachments, it is very useful to me!
I tried testsuite for microblaze cross target on x86_64 host
, could you share it
to me, thanks.
set_board_info ldscript -T/home/eager/Xilinx/dg/microblaze_0/LinkScr.ld
At present, I am just analyzing how to cross compile microblaze glibc,
welcome any ideas, suggestions or completions.
Thanks.
On 09/21/2014 12:41 AM, Chen Gang wrote:
Thank you very much
warnings being treated as errors
Signed-off-by: Chen Gang gang.chen.5...@gmail.com
---
sysdeps/microblaze/bits/atomic.h | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/sysdeps/microblaze/bits/atomic.h b/sysdeps/microblaze/bits/atomic.h
index 77004a0..c8d8d9c 100644
On 09/21/2014 02:24 PM, Chen Gang wrote:
After check the details, I guess, we need:
- Cross compile and install glibc with raw microblaze cross-compiler,
After fix a compiling break bug for microblaze glibc, I succeed building
microblaze glibc with microblaze raw cross compiler
On 9/22/14 2:03, Michael Eager wrote:
On 09/20/14 23:24, Chen Gang wrote:
And it seems, we also need 'LinkScr.ld' for ldscript, could you share it
to me, thanks.
set_board_info ldscript -T/home/eager/Xilinx/dg/microblaze_0/LinkScr.ld
Hi Chen --
The DejaGNU configuration I provided
On 9/22/14 2:09, Michael Eager wrote:
On 09/21/14 03:46, Chen Gang wrote:
Excuse me, I want to consult one thing: I installed raw microblaze cross
compiler, binutils and glibc into one directory (/upstream/release), and
try to build a Hello world C program for microblaze under x86_64 host.
I
On 09/22/2014 10:45 PM, Michael Eager wrote:
On 09/21/14 21:10, Chen Gang wrote:
On 9/22/14 2:09, Michael Eager wrote:
Generally, you should use gcc to link programs, not ld. gcc is
a driver which will select the appropriate libraries and support routines
(such as crt0.o, which contains
On 09/22/2014 10:46 PM, Michael Eager wrote:
On 09/21/14 20:55, Chen Gang wrote:
On 9/22/14 2:03, Michael Eager wrote:
On 09/20/14 23:24, Chen Gang wrote:
And it seems, we also need 'LinkScr.ld' for ldscript, could you share it
to me, thanks.
set_board_info ldscript
-T/home/eager
no enough time resource on glibc, at present).
Thanks.
--
Chen Gang
Open share and attitude like air water and life which God blessed
On 09/24/2014 11:28 PM, Michael Eager wrote:
On 09/24/14 07:31, Chen Gang wrote:
Hello Michael:
Firstly, thank you very much for always providing your aid to me for
microblaze.
At present, after try testsuite, the result is much better than my
original trying, please help check the result
or virtual target for test.
Thanks.
--
Chen Gang
Open share and attitude like air water and life which God blessed
, 2014, at 9:23 AM, Chen Gang gang.chen.5...@gmail.com wrote:
For one simple solving way under fedora: yum install rsh, and I will
get another issue:
Download to microblaze-xilinx-gdb failed, microblaze-xilinx-gdb: Unknown
host
So I guess the root cause is: I only use cross-compiling
Thank you for your information, I shall notice about it when trying Qemu
microblaze.
Thanks
Send from Lenovo A788t.
Michael Eager ea...@eagerm.com wrote:
On 09/24/14 09:23, Chen Gang wrote:
On 09/24/2014 11:37 PM, Mike Stump wrote:
On Sep 24, 2014, at 8:28 AM, Michael Eager ea...@eagerm.com
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
2014-09-25 Chen Gang gang.chen.5...@gmail.com
* config/microblaze/microblaze.md (call_internal1
worry about is whether bother others.
Thanks.
On 07/29/2014 01:29 PM, Chen Gang wrote:
Hello All:
It is a simple way for finding these kinds of issues (issues may not be
bugs), one sample for 'strncpy' (the same way for sprintf, strcpy,
memcpy ...):
- grep strncpy in all source code
On 07/30/2014 11:24 PM, Tom Tromey wrote:
Chen == Chen Gang gang.chen.5...@gmail.com writes:
Chen I shall stop making this kind of patch, next. The reason is that I worry
Chen about what I have done have negative effect to others. And next, I shall
Chen try to send another kinds of patches
On 07/30/2014 11:32 PM, Andrew Haley wrote:
On 07/30/2014 04:01 PM, Chen Gang wrote:
I shall stop making this kind of patch, next. The reason is that I worry
about what I have done have negative effect to others. And next, I shall
try to send another kinds of patches for gcc when I have time
1 - 100 of 206 matches
Mail list logo
