[PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'

[Chen Gang]

* 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 <***@gmail.com>
---
gcc/config/microblaze/microblaze.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/config/microblaze/microblaze.md b/gcc/config/microblaze/microblaze.md
index 2bd5d72..9580221 100644
--- a/gcc/config/microblaze/microblaze.md
+++ b/gcc/config/microblaze/microblaze.md
@@ -2171,7 +2171,7 @@

(define_insn "call_value_intern"
[(set (match_operand:VOID 0 "register_operand" "=d")
- (call (mem (match_operand:VOID 1 "call_insn_operand" "ri"))
+ (call (mem (match_operand:SI 1 "call_insn_operand" "ri"))
(match_operand:SI 2 "" "i")))
(clobber (match_operand:SI 3 "register_operand" "=d"))]
""
--
1.7.11.7

[Michael Eager]

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: warning: operand 1 missing mode?
>
>
> Signed-off-by: Chen Gang <***@gmail.com>
> ---
> gcc/config/microblaze/microblaze.md | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gcc/config/microblaze/microblaze.md b/gcc/config/microblaze/microblaze.md
> index 2bd5d72..9580221 100644
> --- a/gcc/config/microblaze/microblaze.md
> +++ b/gcc/config/microblaze/microblaze.md
> @@ -2171,7 +2171,7 @@
>
> (define_insn "call_value_intern"
> [(set (match_operand:VOID 0 "register_operand" "=d")
> - (call (mem (match_operand:VOID 1 "call_insn_operand" "ri"))
> + (call (mem (match_operand:SI 1 "call_insn_operand" "ri"))
> (match_operand:SI 2 "" "i")))
> (clobber (match_operand:SI 3 "register_operand" "=d"))]
> ""

This patch causes a test suite regression:

Executing on host: mb-gcc -fno-diagnostics-show-caret -fdiagnostics-color=never -O0 -w -c
-mno-xl-soft-mul -mxl-barrel-shift -mcpu=v6.00.a -o calls.o
testsuite/gcc.c-torture/compile/calls.c (timeout = 60)
pid is 24832 -24832
testsuite/gcc.c-torture/compile/calls.c: In function 'f1':
testsuite/gcc.c-torture/compile/calls.c:6:1: error: unrecognizable insn:
(call_insn 5 2 8 2 (parallel [
(set (reg:SI 3 r3)
(call (mem:SI (const_int 0 [0]) [0 MEM[(void * (*<T29e>) (void))0B] S4 A32])
(const_int 24 [0x18])))
(clobber (reg:SI 15 r15))
]) testsuite/gcc.c-torture/compile/calls.c:5 -1
(nil)
(nil))
testsuite/gcc.c-torture/compile/calls.c:6:1: internal compiler error: in extract_insn, at recog.c:2204
0x983018 _fatal_insn(char const*, rtx_def const*, char const*, int, char const*)
/store/Xilinx/repo/fsf/gcc/gcc/rtl-error.c:109
0x983041 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/store/Xilinx/repo/fsf/gcc/gcc/rtl-error.c:117
0x9539cd extract_insn(rtx_def*)
/store/Xilinx/repo/fsf/gcc/gcc/recog.c:2204
0x7a5b59 instantiate_virtual_regs_in_insn
/store/Xilinx/repo/fsf/gcc/gcc/function.c:1561
0x7aaa78 instantiate_virtual_regs
/store/Xilinx/repo/fsf/gcc/gcc/function.c:1932



--
Michael Eager ***@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077

[Chen Gang]

> 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: warning: operand 1 missing mode?
>>>
>>>
>>> Signed-off-by: Chen Gang <***@gmail.com>
>>> ---
>>> gcc/config/microblaze/microblaze.md | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/gcc/config/microblaze/microblaze.md b/gcc/config/microblaze/microblaze.md
>>> index 2bd5d72..9580221 100644
>>> --- a/gcc/config/microblaze/microblaze.md
>>> +++ b/gcc/config/microblaze/microblaze.md
>>> @@ -2171,7 +2171,7 @@
>>>
>>> (define_insn "call_value_intern"
>>> [(set (match_operand:VOID 0 "register_operand" "=d")
>>> - (call (mem (match_operand:VOID 1 "call_insn_operand" "ri"))
>>> + (call (mem (match_operand:SI 1 "call_insn_operand" "ri"))
>>> (match_operand:SI 2 "" "i")))
>>> (clobber (match_operand:SI 3 "register_operand" "=d"))]
>>> ""
>>
>> This patch causes a test suite regression:
>>
>> Executing on host: mb-gcc -fno-diagnostics-show-caret -fdiagnostics-color=never -O0 -w -c -mno-xl-soft-mul -mxl-barrel-shift -mcpu=v6.00.a -o calls.o testsuite/gcc.c-torture/compile/calls.c (timeout = 60)
>> pid is 24832 -24832
>> testsuite/gcc.c-torture/compile/calls.c: In function 'f1':
>> testsuite/gcc.c-torture/compile/calls.c:6:1: error: unrecognizable insn:
>> (call_insn 5 2 8 2 (parallel [
>> (set (reg:SI 3 r3)
>> (call (mem:SI (const_int 0 [0]) [0 MEM[(void * (*<T29e>) (void))0B] S4 A32])
>> (const_int 24 [0x18])))
>> (clobber (reg:SI 15 r15))
>> ]) testsuite/gcc.c-torture/compile/calls.c:5 -1
>> (nil)
>> (nil))
>> testsuite/gcc.c-torture/compile/calls.c:6:1: internal compiler error: in extract_insn, at recog.c:2204
>> 0x983018 _fatal_insn(char const*, rtx_def const*, char const*, int, char const*)
>> /store/Xilinx/repo/fsf/gcc/gcc/rtl-error.c:109
>> 0x983041 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
>> /store/Xilinx/repo/fsf/gcc/gcc/rtl-error.c:117
>> 0x9539cd extract_insn(rtx_def*)
>> /store/Xilinx/repo/fsf/gcc/gcc/recog.c:2204
>> 0x7a5b59 instantiate_virtual_regs_in_insn
>> /store/Xilinx/repo/fsf/gcc/gcc/function.c:1561
>> 0x7aaa78 instantiate_virtual_regs
>> /store/Xilinx/repo/fsf/gcc/gcc/function.c:1932
>>

It is really this patch to cause this issue. After add this patch, it
will be fail for compiling the below C code:

typedef void (*T)(void);
f1 ()
{
((T) 0)();
}

And I guess, the original compiling warning is still useful for us: for
the almost same code, the original gcc (no this patch) also report the
same error:

f1 ()
{
((void (*)(void))0)();
}

The related command is "./cc1 call.c -o /tmp/test.s" ('call.c' has the
contents above).


And I shall continue analysing it (I shall try to finish within this
month). And also welcome any ideas, suggestions or completions.

Thanks.
--
Chen Gang

Open share and attitude like air water and life which God blessed

[Chen Gang]

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/config/microblaze/microblaze.md:2172: warning: operand 1 missing mode?
>>>>
>>>>
>>>> Signed-off-by: Chen Gang <***@gmail.com>
>>>> ---
>>>> gcc/config/microblaze/microblaze.md | 2 +-
>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/gcc/config/microblaze/microblaze.md b/gcc/config/microblaze/microblaze.md
>>>> index 2bd5d72..9580221 100644
>>>> --- a/gcc/config/microblaze/microblaze.md
>>>> +++ b/gcc/config/microblaze/microblaze.md
>>>> @@ -2171,7 +2171,7 @@
>>>>
>>>> (define_insn "call_value_intern"
>>>> [(set (match_operand:VOID 0 "register_operand" "=d")
>>>> - (call (mem (match_operand:VOID 1 "call_insn_operand" "ri"))
>>>> + (call (mem (match_operand:SI 1 "call_insn_operand" "ri"))
>>>> (match_operand:SI 2 "" "i")))
>>>> (clobber (match_operand:SI 3 "register_operand" "=d"))]
>>>> ""
>>>
>>> This patch causes a test suite regression:
>>>
>>> Executing on host: mb-gcc -fno-diagnostics-show-caret -fdiagnostics-color=never -O0 -w -c -mno-xl-soft-mul -mxl-barrel-shift -mcpu=v6.00.a -o calls.o testsuite/gcc.c-torture/compile/calls.c (timeout = 60)
>>> pid is 24832 -24832
>>> testsuite/gcc.c-torture/compile/calls.c: In function 'f1':
>>> testsuite/gcc.c-torture/compile/calls.c:6:1: error: unrecognizable insn:
>>> (call_insn 5 2 8 2 (parallel [
>>> (set (reg:SI 3 r3)
>>> (call (mem:SI (const_int 0 [0]) [0 MEM[(void * (*<T29e>) (void))0B] S4 A32])
>>> (const_int 24 [0x18])))
>>> (clobber (reg:SI 15 r15))
>>> ]) testsuite/gcc.c-torture/compile/calls.c:5 -1
>>> (nil)
>>> (nil))
>>> testsuite/gcc.c-torture/compile/calls.c:6:1: internal compiler error: in extract_insn, at recog.c:2204
>>> 0x983018 _fatal_insn(char const*, rtx_def const*, char const*, int, char const*)
>>> /store/Xilinx/repo/fsf/gcc/gcc/rtl-error.c:109
>>> 0x983041 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
>>> /store/Xilinx/repo/fsf/gcc/gcc/rtl-error.c:117
>>> 0x9539cd extract_insn(rtx_def*)
>>> /store/Xilinx/repo/fsf/gcc/gcc/recog.c:2204
>>> 0x7a5b59 instantiate_virtual_regs_in_insn
>>> /store/Xilinx/repo/fsf/gcc/gcc/function.c:1561
>>> 0x7aaa78 instantiate_virtual_regs
>>> /store/Xilinx/repo/fsf/gcc/gcc/function.c:1932
>>>
>
> It is really this patch to cause this issue. After add this patch, it
> will be fail for compiling the below C code:
>
> typedef void (*T)(void);
> f1 ()
> {
> ((T) 0)();
> }
>

Oh, sorry, neither original nor the new one (with this patch) can
recognize the code above.

- The original one can recognize "void *(*)(void);"

- But can not recognize "void (*)(void);"

- Although new one (with this patch) also recognize "void *(*)(void);",
it causes inconsistency within "config/microblaze/microblaze.md".

And the original one also can recognize all below contents (only except
"void (*)(void), or void (*)(int)"):

- void **(*)(void);

- int *(*)(void);

- int (*)(void);

- int (*)(int);


> And I guess, the original compiling warning is still useful for us: for
> the almost same code, the original gcc (no this patch) also report the
> same error:
>
> f1 ()
> {
> ((void (*)(void))0)();
> }
>
> The related command is "./cc1 call.c -o /tmp/test.s" ('call.c' has the
> contents above).
>
>
> And I shall continue analysing it (I shall try to finish within this
> month). And also welcome any ideas, suggestions or completions.
>
> Thanks.
>


--
Chen Gang

Open share and attitude like air water and life which God blessed

[Chen Gang]

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.
>>>>>
>>>>> The related warning:
>>>>>
>>>>> ../../gcc/gcc/config/microblaze/microblaze.md:2172: warning: operand 1 missing mode?
>>>>>
>>>>>
>>>>> Signed-off-by: Chen Gang <***@gmail.com>
>>>>> ---
>>>>> gcc/config/microblaze/microblaze.md | 2 +-
>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/gcc/config/microblaze/microblaze.md b/gcc/config/microblaze/microblaze.md
>>>>> index 2bd5d72..9580221 100644
>>>>> --- a/gcc/config/microblaze/microblaze.md
>>>>> +++ b/gcc/config/microblaze/microblaze.md
>>>>> @@ -2171,7 +2171,7 @@
>>>>>
>>>>> (define_insn "call_value_intern"
>>>>> [(set (match_operand:VOID 0 "register_operand" "=d")
>>>>> - (call (mem (match_operand:VOID 1 "call_insn_operand" "ri"))
>>>>> + (call (mem (match_operand:SI 1 "call_insn_operand" "ri"))
>>>>> (match_operand:SI 2 "" "i")))
>>>>> (clobber (match_operand:SI 3 "register_operand" "=d"))]
>>>>> ""
>>>>
>>>> This patch causes a test suite regression:
>>>>
>>>> Executing on host: mb-gcc -fno-diagnostics-show-caret -fdiagnostics-color=never -O0 -w -c -mno-xl-soft-mul -mxl-barrel-shift -mcpu=v6.00.a -o calls.o testsuite/gcc.c-torture/compile/calls.c (timeout = 60)
>>>> pid is 24832 -24832
>>>> testsuite/gcc.c-torture/compile/calls.c: In function 'f1':
>>>> testsuite/gcc.c-torture/compile/calls.c:6:1: error: unrecognizable insn:
>>>> (call_insn 5 2 8 2 (parallel [
>>>> (set (reg:SI 3 r3)
>>>> (call (mem:SI (const_int 0 [0]) [0 MEM[(void * (*<T29e>) (void))0B] S4 A32])
>>>> (const_int 24 [0x18])))
>>>> (clobber (reg:SI 15 r15))
>>>> ]) testsuite/gcc.c-torture/compile/calls.c:5 -1
>>>> (nil)
>>>> (nil))
>>>> testsuite/gcc.c-torture/compile/calls.c:6:1: internal compiler error: in extract_insn, at recog.c:2204
>>>> 0x983018 _fatal_insn(char const*, rtx_def const*, char const*, int, char const*)
>>>> /store/Xilinx/repo/fsf/gcc/gcc/rtl-error.c:109
>>>> 0x983041 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
>>>> /store/Xilinx/repo/fsf/gcc/gcc/rtl-error.c:117
>>>> 0x9539cd extract_insn(rtx_def*)
>>>> /store/Xilinx/repo/fsf/gcc/gcc/recog.c:2204
>>>> 0x7a5b59 instantiate_virtual_regs_in_insn
>>>> /store/Xilinx/repo/fsf/gcc/gcc/function.c:1561
>>>> 0x7aaa78 instantiate_virtual_regs
>>>> /store/Xilinx/repo/fsf/gcc/gcc/function.c:1932
>>>>
>>

At present, I guess the original code is correct, need not additional
fix: "When call call_insn_operand() in gencog(), related 'rtx' mode is
VOIDmode (which need VOID, not SI)".

For the compiler's warning: "operand 1 is VOIDmode", after give some
related test, "operand 1 is VOIDmode" is all OK, the related tests are
below:

- For almost same definitions, they are OK:

- int *(*T)(void);

- char *(*T)(int);

...

- For incorrect assignments, report related correct warning/error:

- char a = ((long long *(*)(short)) 0) (1);

- ((long long *(*)(short)) 0) ();

...

If what I guess is correct, the below issue can be fixed in the same
way, please help check.

>> typedef void (*T)(void);
>> f1 ()
>> {
>> ((T) 0)();
>> }
>>
>
> Oh, sorry, neither original nor the new one (with this patch) can
> recognize the code above.
>

Need use VOID instead of SI, or when real VOIDmode comes, it does not
match SImode, so cause issue.

The related test code ('void' will cause CALL instead of SET):

typedef void (*T)(void);
f1 ()
{
((T) 0)();
}

The related error:

[***@localhost gcc]# ./cc1 /tmp/calls.c -o /tmp/1.s
f1
Analyzing compilation unit
Performing interprocedural optimizations
<*free_lang_data> <visibility> <early_local_cleanups> <free-inline-summary> <whole-program> <inline>Assembling functions:
f1
/tmp/calls.c: In function 'f1':
/tmp/calls.c:5:1: error: unrecognizable insn:
}
^
(call_insn 5 2 8 2 (parallel [
(call (mem:SI (const_int 0 [0]) [0 MEM[(void (*<T29c>) (void))0B] S4 A32])
(const_int 24 [0x18]))
(clobber (reg:SI 15 r15))
]) /tmp/calls.c:4 -1
(nil)
(nil))
/tmp/calls.c:5:1: internal compiler error: in extract_insn, at recog.c:2204
0xb0e71b _fatal_insn(char const*, rtx_def const*, char const*, int, char const*)
../../gcc/gcc/rtl-error.c:109
0xb0e75c _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../gcc/gcc/rtl-error.c:117
0xac552b extract_insn(rtx_def*)
../../gcc/gcc/recog.c:2204
0x8b919e instantiate_virtual_regs_in_insn
../../gcc/gcc/function.c:1614
0x8ba347 instantiate_virtual_regs
../../gcc/gcc/function.c:1934
0x8ba452 execute
../../gcc/gcc/function.c:1983
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.

diff --git a/gcc/config/microblaze/microblaze.md b/gcc/config/microblaze/microblaze.md
index b971737..3b4faf4 100644
--- a/gcc/config/microblaze/microblaze.md
+++ b/gcc/config/microblaze/microblaze.md
@@ -2062,7 +2062,7 @@
(set_attr "length" "4")])

(define_insn "call_internal1"
- [(call (mem (match_operand:SI 0 "call_insn_simple_operand" "ri"))
+ [(call (mem (match_operand:VOID 0 "call_insn_simple_operand" "ri"))
(match_operand:SI 1 "" "i"))
(clobber (reg:SI R_SR))]
""


Thanks.
--
Chen Gang

Open share and attitude like air water and life which God blessed

[Chen Gang]

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, 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.
>>>>>>
>>>>>> The related warning:
>>>>>>
>>>>>> ../../gcc/gcc/config/microblaze/microblaze.md:2172: warning: operand 1 missing mode?
>>>>>>
>>>>>>
>>>>>> Signed-off-by: Chen Gang <***@gmail.com>
>>>>>> ---
>>>>>> gcc/config/microblaze/microblaze.md | 2 +-
>>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/gcc/config/microblaze/microblaze.md b/gcc/config/microblaze/microblaze.md
>>>>>> index 2bd5d72..9580221 100644
>>>>>> --- a/gcc/config/microblaze/microblaze.md
>>>>>> +++ b/gcc/config/microblaze/microblaze.md
>>>>>> @@ -2171,7 +2171,7 @@
>>>>>>
>>>>>> (define_insn "call_value_intern"
>>>>>> [(set (match_operand:VOID 0 "register_operand" "=d")
>>>>>> - (call (mem (match_operand:VOID 1 "call_insn_operand" "ri"))
>>>>>> + (call (mem (match_operand:SI 1 "call_insn_operand" "ri"))
>>>>>> (match_operand:SI 2 "" "i")))
>>>>>> (clobber (match_operand:SI 3 "register_operand" "=d"))]
>>>>>> ""
>>>>>
>>>>> This patch causes a test suite regression:
>>>>>
>>>>> Executing on host: mb-gcc -fno-diagnostics-show-caret -fdiagnostics-color=never -O0 -w -c -mno-xl-soft-mul -mxl-barrel-shift -mcpu=v6.00.a -o calls.o testsuite/gcc.c-torture/compile/calls.c (timeout = 60)
>>>>> pid is 24832 -24832
>>>>> testsuite/gcc.c-torture/compile/calls.c: In function 'f1':
>>>>> testsuite/gcc.c-torture/compile/calls.c:6:1: error: unrecognizable insn:
>>>>> (call_insn 5 2 8 2 (parallel [
>>>>> (set (reg:SI 3 r3)
>>>>> (call (mem:SI (const_int 0 [0]) [0 MEM[(void * (*<T29e>) (void))0B] S4 A32])
>>>>> (const_int 24 [0x18])))
>>>>> (clobber (reg:SI 15 r15))
>>>>> ]) testsuite/gcc.c-torture/compile/calls.c:5 -1
>>>>> (nil)
>>>>> (nil))
>>>>> testsuite/gcc.c-torture/compile/calls.c:6:1: internal compiler error: in extract_insn, at recog.c:2204
>>>>> 0x983018 _fatal_insn(char const*, rtx_def const*, char const*, int, char const*)
>>>>> /store/Xilinx/repo/fsf/gcc/gcc/rtl-error.c:109
>>>>> 0x983041 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
>>>>> /store/Xilinx/repo/fsf/gcc/gcc/rtl-error.c:117
>>>>> 0x9539cd extract_insn(rtx_def*)
>>>>> /store/Xilinx/repo/fsf/gcc/gcc/recog.c:2204
>>>>> 0x7a5b59 instantiate_virtual_regs_in_insn
>>>>> /store/Xilinx/repo/fsf/gcc/gcc/function.c:1561
>>>>> 0x7aaa78 instantiate_virtual_regs
>>>>> /store/Xilinx/repo/fsf/gcc/gcc/function.c:1932
>>>>>
>>>
>
> At present, I guess the original code is correct, need not additional
> fix: "When call call_insn_operand() in gencog(), related 'rtx' mode is
> VOIDmode (which need VOID, not SI)".
>
> For the compiler's warning: "operand 1 is VOIDmode", after give some
> related test, "operand 1 is VOIDmode" is all OK, the related tests are
> below:
>
> - For almost same definitions, they are OK:
>
> - int *(*T)(void);
>
> - char *(*T)(int);
>
> ...
>
> - For incorrect assignments, report related correct warning/error:
>
> - char a = ((long long *(*)(short)) 0) (1);
>
> - ((long long *(*)(short)) 0) ();
>
> ...
>
> If what I guess is correct, the below issue can be fixed in the same
> way, please help check.
>
>>> typedef void (*T)(void);
>>> f1 ()
>>> {
>>> ((T) 0)();
>>> }
>>>
>>
>> Oh, sorry, neither original nor the new one (with this patch) can
>> recognize the code above.
>>
>
> Need use VOID instead of SI, or when real VOIDmode comes, it does not
> match SImode, so cause issue.
>
> The related test code ('void' will cause CALL instead of SET):
>
> typedef void (*T)(void);
> f1 ()
> {
> ((T) 0)();
> }
>
> The related error:
>
> [***@localhost gcc]# ./cc1 /tmp/calls.c -o /tmp/1.s
> f1
> Analyzing compilation unit
> Performing interprocedural optimizations
> <*free_lang_data> <visibility> <early_local_cleanups> <free-inline-summary> <whole-program> <inline>Assembling functions:
> f1
> /tmp/calls.c: In function 'f1':
> /tmp/calls.c:5:1: error: unrecognizable insn:
> }
> ^
> (call_insn 5 2 8 2 (parallel [
> (call (mem:SI (const_int 0 [0]) [0 MEM[(void (*<T29c>) (void))0B] S4 A32])
> (const_int 24 [0x18]))
> (clobber (reg:SI 15 r15))
> ]) /tmp/calls.c:4 -1
> (nil)
> (nil))
> /tmp/calls.c:5:1: internal compiler error: in extract_insn, at recog.c:2204
> 0xb0e71b _fatal_insn(char const*, rtx_def const*, char const*, int, char const*)
> ../../gcc/gcc/rtl-error.c:109
> 0xb0e75c _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
> ../../gcc/gcc/rtl-error.c:117
> 0xac552b extract_insn(rtx_def*)
> ../../gcc/gcc/recog.c:2204
> 0x8b919e instantiate_virtual_regs_in_insn
> ../../gcc/gcc/function.c:1614
> 0x8ba347 instantiate_virtual_regs
> ../../gcc/gcc/function.c:1934
> 0x8ba452 execute
> ../../gcc/gcc/function.c:1983
> 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.
>
> diff --git a/gcc/config/microblaze/microblaze.md b/gcc/config/microblaze/microblaze.md
> index b971737..3b4faf4 100644
> --- a/gcc/config/microblaze/microblaze.md
> +++ b/gcc/config/microblaze/microblaze.md
> @@ -2062,7 +2062,7 @@
> (set_attr "length" "4")])
>
> (define_insn "call_internal1"
> - [(call (mem (match_operand:SI 0 "call_insn_simple_operand" "ri"))
> + [(call (mem (match_operand:VOID 0 "call_insn_simple_operand" "ri"))
> (match_operand:SI 1 "" "i"))
> (clobber (reg:SI R_SR))]
> ""
>
>
> Thanks.
>


--
Chen Gang

Open share and attitude like air water and life which God blessed

[Michael Eager]

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 for it?

Hi Chen --

This is the gcc DejaGNU test suite. You can find info about DejaGNU
at http://www.gnu.org/software/dejagnu. There is also info about
testing GCC here: https://gcc.gnu.org/wiki/Testing_GCC

Rather than the standard "make check-gcc" described on the wiki
page and elsewhere, I use a script which sets some configuration
options and executes runtest directly. This uses a MicroBlaze processor
simulator called vpexec which was included with an older version of
Xilinx's EDK. Xilinx no longer supports vpexec.

You can use a hardware target board to test microblaze-gcc,
or a different simulator such as QEMU.


--
Michael Eager ***@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077

[Chen Gang]

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 for it?
>
> Hi Chen --
>
> This is the gcc DejaGNU test suite. You can find info about DejaGNU
> at http://www.gnu.org/software/dejagnu. There is also info about
> testing GCC here: https://gcc.gnu.org/wiki/Testing_GCC
>

OK, thanks. I finished about x86_64 testsuite, and also tried microblaze
testsuite under x86_64 machine, but failed. Do I need any additional
information for microblaze testsuite?


> Rather than the standard "make check-gcc" described on the wiki
> page and elsewhere, I use a script which sets some configuration
> options and executes runtest directly. This uses a MicroBlaze processor
> simulator called vpexec which was included with an older version of
> Xilinx's EDK. Xilinx no longer supports vpexec.
>
> You can use a hardware target board to test microblaze-gcc,
> or a different simulator such as QEMU.
>

OK, thanks, I shall try Qemu (it is the additional chance for me to
familiar with Qemu).

And do you mean I need try testsuite under the related microblaze host (
e.g. Qemu microblaze simulator)?


After finish environments construction, I shall also try to test a patch
for "((void (*)(void)) 0)()" fixing.


Thanks.
--
Chen Gang

Open, share, and attitude like air, water, and life which God blessed

[Michael Eager]

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 familiar the testsuite for
>>> microblaze, could you provide any related information for it?
>>
>> Hi Chen --
>>
>> This is the gcc DejaGNU test suite. You can find info about DejaGNU
>> at http://www.gnu.org/software/dejagnu. There is also info about
>> testing GCC here: https://gcc.gnu.org/wiki/Testing_GCC
>>
>
> OK, thanks. I finished about x86_64 testsuite, and also tried microblaze
> testsuite under x86_64 machine, but failed. Do I need any additional
> information for microblaze testsuite?

I run tests using these options:
-mno-xl-soft-mul -mxl-barrel-shift -mcpu=v6.00.a

Configuring DejaGNU for cross-target testing requires creating a configuration
file describing the target board.


>> Rather than the standard "make check-gcc" described on the wiki
>> page and elsewhere, I use a script which sets some configuration
>> options and executes runtest directly. This uses a MicroBlaze processor
>> simulator called vpexec which was included with an older version of
>> Xilinx's EDK. Xilinx no longer supports vpexec.
>>
>> You can use a hardware target board to test microblaze-gcc,
>> or a different simulator such as QEMU.
>>
>
> OK, thanks, I shall try Qemu (it is the additional chance for me to
> familiar with Qemu).
>
> And do you mean I need try testsuite under the related microblaze host (
> e.g. Qemu microblaze simulator)?
>
>
> After finish environments construction, I shall also try to test a patch
> for "((void (*)(void)) 0)()" fixing.
>
>
> Thanks.
>


--
Michael Eager ***@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077

[Chen Gang]

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 familiar the testsuite for
>>>> microblaze, could you provide any related information for it?
>>>
>>> Hi Chen --
>>>
>>> This is the gcc DejaGNU test suite. You can find info about DejaGNU
>>> at http://www.gnu.org/software/dejagnu. There is also info about
>>> testing GCC here: https://gcc.gnu.org/wiki/Testing_GCC
>>>
>>
>> OK, thanks. I finished about x86_64 testsuite, and also tried microblaze
>> testsuite under x86_64 machine, but failed. Do I need any additional
>> information for microblaze testsuite?
>
> I run tests using these options:
> -mno-xl-soft-mul -mxl-barrel-shift -mcpu=v6.00.a
>

OK, thank you for your information.

> Configuring DejaGNU for cross-target testing requires creating a configuration
> file describing the target board.
>

OK, thank you very much. And could you share your configuration file,
which I can reference to?


Thanks.
--
Chen Gang

Open share and attitude like air water and life which God blessed

[Michael Eager]

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 your configuration file,
> which I can reference to?

See attached.

--
Michael Eager ***@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077

[Chen Gang]

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 your configuration file,
>> which I can reference to?
>
> See attached.
>

Thank you very much for your attachments, it is very useful to me!

I tried testsuite for microblaze cross target on x86_64 host, it says
OK ("echo $? == 0"), but I am not quite sure about it (I still doubt
that my configuration is incorrect), please help check, thanks.

dejagnu configuration:

cp xmd.exp /usr/local/share/dejagnu/config/
cp microblaze-xilinx-gdb.exp /usr/local/share/dejagn/baseboards/
vi microblaze-xilinx-gdb.exp
"s/mc_gcc/microblaze\-gchen\-linux\-gcc/g"

gcc operation:

../gcc/configure --target=microblaze-gchen-linux --disable-nls --enable-languages=c --disable-threads --disable-shared \
--without-headers --disable-libssp --disable-libquadmath --disable-libgomp --disable-libatomic
make
make -k check-gcc RUNTESTFLAGS="--target_board=microblaze-xilinx-gdb/-mno-xl-soft-mul/-mxl-barrel-shift/-mcpu=v6.00.a"

gcc result:

=== gcc Summary ===

# of expected passes 48408
# of unexpected failures 17253
# of unexpected successes 1
# of expected failures 97
# of unresolved testcases 16570
# of unsupported tests 1854
/upstream/build-gcc/gcc/xgcc version 5.0.0 20140920 (experimental) (GCC)

make[2]: Leaving directory `/upstream/build-gcc/gcc'
make[1]: Leaving directory `/upstream/build-gcc/gcc'
[***@localhost build-gcc]# echo $?
0


Thanks.
--
Chen Gang

Open share and attitude like air water and life which God blessed

[Michael Eager]

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, it says
> OK ("echo $? == 0"), but I am not quite sure about it (I still doubt
> that my configuration is incorrect), please help check, thanks.

Welcome to the joys of DejaGNU. Configuration can be confusing.
As you can see, the return code is not useful.

> dejagnu configuration:
>
> cp xmd.exp /usr/local/share/dejagnu/config/
> cp microblaze-xilinx-gdb.exp /usr/local/share/dejagn/baseboards/
> vi microblaze-xilinx-gdb.exp
> "s/mc_gcc/microblaze\-gchen\-linux\-gcc/g"
>
> gcc operation:
>
> ../gcc/configure --target=microblaze-gchen-linux --disable-nls --enable-languages=c --disable-threads --disable-shared \
> --without-headers --disable-libssp --disable-libquadmath --disable-libgomp --disable-libatomic
> make
> make -k check-gcc RUNTESTFLAGS="--target_board=microblaze-xilinx-gdb/-mno-xl-soft-mul/-mxl-barrel-shift/-mcpu=v6.00.a"

Check whether these compiler options are being passed to mb-gcc. There is a
line in my microblaze-xilinx-gdb.exp which sets CFLAGS:
set_board_info cflags "-mcpu=v4.00.b -mno-xl-soft-mul -mxl-barrel-shift"
This is likely overriding any options passed to runtest.

Make sure that the options match the features of your target board. You might
not need any options for your initial tests.

Make sure that the correct flags are being passed to the linker.

Add "-v" or "-v -v" to RUNTESTFLAGS so that the gcc.log file gives useful info.

You might want to limit the number of tests run until you get problems worked out:
make check-gcc RUNTESTFLAGS="execute.exp -v -v --target_board=microblaze-xilinx-gdb"
This will run only the gcc.c-torture/execute/execute.exp tests.

> gcc result:
>
> === gcc Summary ===
>
> # of expected passes 48408
> # of unexpected failures 17253
> # of unexpected successes 1
> # of expected failures 97
> # of unresolved testcases 16570
> # of unsupported tests 1854
> /upstream/build-gcc/gcc/xgcc version 5.0.0 20140920 (experimental) (GCC)

Look at gcc.sum and gcc.log to find out what is causing the large number of
unexpected failures. A large number of unresolved test cases often means that
the compiler returned an error.

--
Michael Eager ***@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077

[Chen Gang]

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, it says
>> OK ("echo $? == 0"), but I am not quite sure about it (I still doubt
>> that my configuration is incorrect), please help check, thanks.
>
> Welcome to the joys of DejaGNU. Configuration can be confusing.
> As you can see, the return code is not useful.
>
>> dejagnu configuration:
>>
>> cp xmd.exp /usr/local/share/dejagnu/config/
>> cp microblaze-xilinx-gdb.exp /usr/local/share/dejagn/baseboards/
>> vi microblaze-xilinx-gdb.exp
>> "s/mc_gcc/microblaze\-gchen\-linux\-gcc/g"
>>
>> gcc operation:
>>
>> ../gcc/configure --target=microblaze-gchen-linux --disable-nls --enable-languages=c --disable-threads --disable-shared \
>> --without-headers --disable-libssp --disable-libquadmath --disable-libgomp --disable-libatomic
>> make
>> make -k check-gcc RUNTESTFLAGS="--target_board=microblaze-xilinx-gdb/-mno-xl-soft-mul/-mxl-barrel-shift/-mcpu=v6.00.a"
>
> Check whether these compiler options are being passed to mb-gcc. There is a
> line in my microblaze-xilinx-gdb.exp which sets CFLAGS:
> set_board_info cflags "-mcpu=v4.00.b -mno-xl-soft-mul -mxl-barrel-shift"
> This is likely overriding any options passed to runtest.
>
> Make sure that the options match the features of your target board. You might
> not need any options for your initial tests.
>
> Make sure that the correct flags are being passed to the linker.
>
> Add "-v" or "-v -v" to RUNTESTFLAGS so that the gcc.log file gives useful info.
>
> You might want to limit the number of tests run until you get problems worked out:
> make check-gcc RUNTESTFLAGS="execute.exp -v -v --target_board=microblaze-xilinx-gdb"
> This will run only the gcc.c-torture/execute/execute.exp tests.
>
>> gcc result:
>>
>> === gcc Summary ===
>>
>> # of expected passes 48408
>> # of unexpected failures 17253
>> # of unexpected successes 1
>> # of expected failures 97
>> # of unresolved testcases 16570
>> # of unsupported tests 1854
>> /upstream/build-gcc/gcc/xgcc version 5.0.0 20140920 (experimental) (GCC)
>
> Look at gcc.sum and gcc.log to find out what is causing the large number of
> unexpected failures. A large number of unresolved test cases often means that
> the compiler returned an error.
>


--
Chen Gang

Open share and attitude like air water and life which God blessed

[Chen Gang]

After check the details, I guess, we need:

- Cross compile and install glibc with raw microblaze cross-compiler,

- Then compile new microblaze cross compiler with glibc.

- Then make check the new microblaze cross compiler with glibc.

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"

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 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, it says
>>> OK ("echo $? == 0"), but I am not quite sure about it (I still doubt
>>> that my configuration is incorrect), please help check, thanks.
>>
>> Welcome to the joys of DejaGNU. Configuration can be confusing.
>> As you can see, the return code is not useful.
>>
>>> dejagnu configuration:
>>>
>>> cp xmd.exp /usr/local/share/dejagnu/config/
>>> cp microblaze-xilinx-gdb.exp /usr/local/share/dejagn/baseboards/
>>> vi microblaze-xilinx-gdb.exp
>>> "s/mc_gcc/microblaze\-gchen\-linux\-gcc/g"
>>>
>>> gcc operation:
>>>
>>> ../gcc/configure --target=microblaze-gchen-linux --disable-nls --enable-languages=c --disable-threads --disable-shared \
>>> --without-headers --disable-libssp --disable-libquadmath --disable-libgomp --disable-libatomic
>>> make
>>> make -k check-gcc RUNTESTFLAGS="--target_board=microblaze-xilinx-gdb/-mno-xl-soft-mul/-mxl-barrel-shift/-mcpu=v6.00.a"
>>
>> Check whether these compiler options are being passed to mb-gcc. There is a
>> line in my microblaze-xilinx-gdb.exp which sets CFLAGS:
>> set_board_info cflags "-mcpu=v4.00.b -mno-xl-soft-mul -mxl-barrel-shift"
>> This is likely overriding any options passed to runtest.
>>
>> Make sure that the options match the features of your target board. You might
>> not need any options for your initial tests.
>>
>> Make sure that the correct flags are being passed to the linker.
>>
>> Add "-v" or "-v -v" to RUNTESTFLAGS so that the gcc.log file gives useful info.
>>
>> You might want to limit the number of tests run until you get problems worked out:
>> make check-gcc RUNTESTFLAGS="execute.exp -v -v --target_board=microblaze-xilinx-gdb"
>> This will run only the gcc.c-torture/execute/execute.exp tests.
>>
>>> gcc result:
>>>
>>> === gcc Summary ===
>>>
>>> # of expected passes 48408
>>> # of unexpected failures 17253
>>> # of unexpected successes 1
>>> # of expected failures 97
>>> # of unresolved testcases 16570
>>> # of unsupported tests 1854
>>> /upstream/build-gcc/gcc/xgcc version 5.0.0 20140920 (experimental) (GCC)
>>
>> Look at gcc.sum and gcc.log to find out what is causing the large number of
>> unexpected failures. A large number of unresolved test cases often means that
>> the compiler returned an error.
>>
>
>


--
Chen Gang

Open share and attitude like air water and life which God blessed

[Chen Gang]

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, with latest Linux
upstream kernel header for microblaze (copy manually), under x86_64 host.

I have sent related patch for glibc mailing list, and continue the next
below, hope I can succeed. :-) thanks.

> - Then compile new microblaze cross compiler with glibc.
>
> - Then make check the new microblaze cross compiler with glibc.
>
> 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"
>
> 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 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, it says
>>>> OK ("echo $? == 0"), but I am not quite sure about it (I still doubt
>>>> that my configuration is incorrect), please help check, thanks.
>>>
>>> Welcome to the joys of DejaGNU. Configuration can be confusing.
>>> As you can see, the return code is not useful.
>>>
>>>> dejagnu configuration:
>>>>
>>>> cp xmd.exp /usr/local/share/dejagnu/config/
>>>> cp microblaze-xilinx-gdb.exp /usr/local/share/dejagn/baseboards/
>>>> vi microblaze-xilinx-gdb.exp
>>>> "s/mc_gcc/microblaze\-gchen\-linux\-gcc/g"
>>>>
>>>> gcc operation:
>>>>
>>>> ../gcc/configure --target=microblaze-gchen-linux --disable-nls --enable-languages=c --disable-threads --disable-shared \
>>>> --without-headers --disable-libssp --disable-libquadmath --disable-libgomp --disable-libatomic
>>>> make
>>>> make -k check-gcc RUNTESTFLAGS="--target_board=microblaze-xilinx-gdb/-mno-xl-soft-mul/-mxl-barrel-shift/-mcpu=v6.00.a"
>>>
>>> Check whether these compiler options are being passed to mb-gcc. There is a
>>> line in my microblaze-xilinx-gdb.exp which sets CFLAGS:
>>> set_board_info cflags "-mcpu=v4.00.b -mno-xl-soft-mul -mxl-barrel-shift"
>>> This is likely overriding any options passed to runtest.
>>>
>>> Make sure that the options match the features of your target board. You might
>>> not need any options for your initial tests.
>>>
>>> Make sure that the correct flags are being passed to the linker.
>>>
>>> Add "-v" or "-v -v" to RUNTESTFLAGS so that the gcc.log file gives useful info.
>>>
>>> You might want to limit the number of tests run until you get problems worked out:
>>> make check-gcc RUNTESTFLAGS="execute.exp -v -v --target_board=microblaze-xilinx-gdb"
>>> This will run only the gcc.c-torture/execute/execute.exp tests.
>>>
>>>> gcc result:
>>>>
>>>> === gcc Summary ===
>>>>
>>>> # of expected passes 48408
>>>> # of unexpected failures 17253
>>>> # of unexpected successes 1
>>>> # of expected failures 97
>>>> # of unresolved testcases 16570
>>>> # of unsupported tests 1854
>>>> /upstream/build-gcc/gcc/xgcc version 5.0.0 20140920 (experimental) (GCC)
>>>
>>> Look at gcc.sum and gcc.log to find out what is causing the large number of
>>> unexpected failures. A large number of unresolved test cases often means that
>>> the compiler returned an error.
>>>
>>
>>
>
>


--
Chen Gang

Open share and attitude like air water and life which God blessed

[Michael Eager]

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 guess it is OK, but I am not quite sure about it (I use raw compiler,
> and have to point out "/upstream/release/lib/ld.so.1" explicitly, and
> receive a warning related with 'ld').
>
> Is it really OK? can I still use raw compiler for our testsuite? Is
> 'LinkScr.ld' for ldscript related with current case?


> [***@localhost test]# /upstream/release/bin/microblaze-gchen-linux-gcc -nostdinc -c -o test.o test.c
> [***@localhost test]# /upstream/release/bin/microblaze-gchen-linux-ld -o test test.o /upstream/release/lib/ld.so.1 -lc -L/upstream/release/lib
>
> /upstream/release/bin/microblaze-gchen-linux-ld: warning: cannot find entry symbol _start; defaulting to 0000000010000180

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 _start) and pass them to the linker.

--
Michael Eager ***@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077

[Chen Gang]

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 guess it is OK, but I am not quite sure about it (I use raw compiler,
>> and have to point out "/upstream/release/lib/ld.so.1" explicitly, and
>> receive a warning related with 'ld').
>>
>> Is it really OK? can I still use raw compiler for our testsuite? Is
>> 'LinkScr.ld' for ldscript related with current case?
>
>
>> [***@localhost test]# /upstream/release/bin/microblaze-gchen-linux-gcc -nostdinc -c -o test.o test.c
>> [***@localhost test]# /upstream/release/bin/microblaze-gchen-linux-ld -o test test.o /upstream/release/lib/ld.so.1 -lc -L/upstream/release/lib
>>
>> /upstream/release/bin/microblaze-gchen-linux-ld: warning: cannot find entry symbol _start; defaulting to 0000000010000180
>
> 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 _start) and pass them to the linker.
>

OK, thanks.

When gcc, it misses the root directory for "crt1.o" and "crtn.o": e.g.
"/lib/ld.so.1", "crt1.o", "crtn.o" when gcc -v, but we need "/upstream/
release/lib/ld.so.1", "/upstream/lib/crt1.o", "/upstream/libcrtn.o".

I guess, we need additional flag to mark the default system link path
for gcc. But after check the all parameters of gcc, I can not find (-L
is for normal library linkage, but not for crt1.o and crtn.o).

I shall continue trying for it, and hope I can finish within this month.
Welcome any ideas, suggestions or completions.

Thanks.
--
Chen Gang

Open, share, and attitude like air, water, and life which God blessed

[Michael Eager]

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 _start) and pass them to the linker.
>>
>
> OK, thanks.
>
> When gcc, it misses the root directory for "crt1.o" and "crtn.o": e.g.
> "/lib/ld.so.1", "crt1.o", "crtn.o" when gcc -v, but we need "/upstream/
> release/lib/ld.so.1", "/upstream/lib/crt1.o", "/upstream/libcrtn.o".

You likely need to build mb-gcc with --sysroot=/upstream.

How are you building gcc? What are your configuration options?


--
Michael Eager ***@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077

[Chen Gang]

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 _start) and pass them to the linker.
>>>
>>
>> OK, thanks.
>>
>> When gcc, it misses the root directory for "crt1.o" and "crtn.o": e.g.
>> "/lib/ld.so.1", "crt1.o", "crtn.o" when gcc -v, but we need "/upstream/
>> release/lib/ld.so.1", "/upstream/lib/crt1.o", "/upstream/libcrtn.o".
>
> You likely need to build mb-gcc with --sysroot=/upstream.
>

OK, thanks! I guess it will solve all issues which I met, and I shall
try next.

> How are you building gcc? What are your configuration options?
>

The related information is below, please help check when you have time,
thanks.

[***@localhost ~]# /upstream/release/bin/microblaze-gchen-linux-gcc -v
Using built-in specs.
COLLECT_GCC=/upstream/release/bin/microblaze-gchen-linux-gcc
COLLECT_LTO_WRAPPER=/upstream/release/libexec/gcc/microblaze-gchen-linux/5.0.0/lto-wrapper
Target: microblaze-gchen-linux
Configured with: ../gcc/configure --target=microblaze-gchen-linux --disable-nls --enable-languages=c --disable-threads --disable-shared --without-headers --disable-libssp --disable-libquadmath --disable-libgomp --disable-libatomic --prefix=/upstream/release
Thread model: single
gcc version 5.0.0 20140920 (experimental) (GCC)
[***@localhost ~]#


Thanks.
--
Chen Gang

Open share and attitude like air water and life which God blessed

[Chen Gang]

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: "is it enough for our
microblaze testsuite" (can we say it pass checking)?

Current result:

# of expected passes 65987
# of unexpected failures 82
# of unexpected successes 1
# of expected failures 97
# of unresolved testcases 16378
# of unsupported tests 1810

Original result:

# of expected passes 48408
# of unexpected failures 17253
# of unexpected successes 1
# of expected failures 97
# of unresolved testcases 16570
# of unsupported tests 1854

After check the current result log, I find many remote target test
related sentences, do we have to process it?

e.g. "Download to microblaze-xilinx-gdb failed, couldn't execute "rcp": no such file or directory."


>>
>> And I guess, it is a glibc bug: which still add root directory (e.g.
>> /upstream/release) in 'libc.so' when already has --with-sysroot for
>> configure.
>>
>
> Oh, sorry, glibc should also need --with-sysroot. I shall try it today,
> hope it will let all things OK.
>

After add --with-sysroot for glibc, this issue is still existance. And I
remove the redundant direcltory manually for libc.so and libpthread.so.

If our microblaze testsuite is OK, I will skip this issue (since I have
no enough time resource on glibc, at present).


Thanks.
--
Chen Gang

Open share and attitude like air water and life which God blessed

[Michael Eager]

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: "is it enough for our
> microblaze testsuite" (can we say it pass checking)?
>
> Current result:
>
> # of expected passes 65987
> # of unexpected failures 82
> # of unexpected successes 1
> # of expected failures 97
> # of unresolved testcases 16378
> # of unsupported tests 1810

This is good.

>
> Original result:
>
> # of expected passes 48408
> # of unexpected failures 17253
> # of unexpected successes 1
> # of expected failures 97
> # of unresolved testcases 16570
> # of unsupported tests 1854
>
> After check the current result log, I find many remote target test
> related sentences, do we have to process it?
>
> e.g. "Download to microblaze-xilinx-gdb failed, couldn't execute "rcp": no such file or directory."

The test suite uses rcp to transfer files to or from the target,
either to provide input to a test case or to check the output.
Most Linux systems do not install rcp, since it is a security risk.

>>> And I guess, it is a glibc bug: which still add root directory (e.g.
>>> /upstream/release) in 'libc.so' when already has --with-sysroot for
>>> configure.
>>>
>>
>> Oh, sorry, glibc should also need --with-sysroot. I shall try it today,
>> hope it will let all things OK.
>>
>
> After add --with-sysroot for glibc, this issue is still existance. And I
> remove the redundant direcltory manually for libc.so and libpthread.so.
>
> If our microblaze testsuite is OK, I will skip this issue (since I have
> no enough time resource on glibc, at present).

OK with me.


--
Michael Eager ***@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077

[Mike Stump]

On Sep 24, 2014, at 8:28 AM, Michael Eager <***@eagerm.com> wrote:
>> After check the current result log, I find many remote target test
>> related sentences, do we have to process it?
>>
>> e.g. "Download to microblaze-xilinx-gdb failed, couldn't execute "rcp": no such file or directory."
>
> The test suite uses rcp to transfer files to or from the target,
> either to provide input to a test case or to check the output.
> Most Linux systems do not install rcp, since it is a security risk.

To clarify:

if {[board_info $desthost exists rcp_prog]} {
set RCP [board_info $desthost rcp_prog]
} else {
set RCP rcp
}

So, if you set rcp_prog to something else, you should be able to avoid rsh if you want. Most people use ssh now-a-days. You will want it set up to not require a password for testing.

[Chen Gang]

On 09/24/2014 11:37 PM, Mike Stump wrote:
> On Sep 24, 2014, at 8:28 AM, Michael Eager <***@eagerm.com> wrote:
>>> After check the current result log, I find many remote target test
>>> related sentences, do we have to process it?
>>>
>>> e.g. "Download to microblaze-xilinx-gdb failed, couldn't execute "rcp": no such file or directory."
>>
>> The test suite uses rcp to transfer files to or from the target,
>> either to provide input to a test case or to check the output.
>> Most Linux systems do not install rcp, since it is a security risk.
>
> To clarify:
>
> if {[board_info $desthost exists rcp_prog]} {
> set RCP [board_info $desthost rcp_prog]
> } else {
> set RCP rcp
> }
>
> So, if you set rcp_prog to something else, you should be able to avoid rsh if you want. Most people use ssh now-a-days. You will want it set up to not require a password for testing.
>

OK, thank you for your information.

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 environments
under fedora x86_64, no any real or virtual target for test.


Thanks.
--
Chen Gang

Open share and attitude like air water and life which God blessed

[Mike Stump]

On Sep 24, 2014, at 9:23 AM, Chen Gang <***@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 environments
> under fedora x86_64, no any real or virtual target for test.

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.

[Michael Eager]

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 <***@eagerm.com> wrote:
>>>> After check the current result log, I find many remote target test
>>>> related sentences, do we have to process it?
>>>>
>>>> e.g. "Download to microblaze-xilinx-gdb failed, couldn't execute "rcp": no such file or directory."
>>>
>>> The test suite uses rcp to transfer files to or from the target,
>>> either to provide input to a test case or to check the output.
>>> Most Linux systems do not install rcp, since it is a security risk.
>>
>> To clarify:
>>
>> if {[board_info $desthost exists rcp_prog]} {
>> set RCP [board_info $desthost rcp_prog]
>> } else {
>> set RCP rcp
>> }
>>
>> So, if you set rcp_prog to something else, you should be able to avoid rsh if you want. Most people use ssh now-a-days. You will want it set up to not require a password for testing.
>>
>
> OK, thank you for your information.
>
> 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 environments
> under fedora x86_64, no any real or virtual target for test.

You can see the command which is getting the error by looking at gcc.log.
If the command is not displayed, add another "-v" (or two) to RUNTESTFLAGS.

If I recall correctly, DejaGNU is executing a command like "rcp file microblaze-xilinx-gdb".
This means that you need to have the name microblaze-xilinx-gdb resolved into an IP address.
This can be done by adding it to /etc/hosts. Or you can specify the target IP address
in the DejaGNU options. I don't recall which one off the top of my head.

--
Michael Eager ***@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077

[Chen Gang]

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: "is it enough for our
>> microblaze testsuite" (can we say it pass checking)?
>>
>> Current result:
>>
>> # of expected passes 65987
>> # of unexpected failures 82
>> # of unexpected successes 1
>> # of expected failures 97
>> # of unresolved testcases 16378
>> # of unsupported tests 1810
>
> This is good.
>

OK, thanks, and I shall send a fix patch for "((void (*)(void))0)()"
tomorrow, it pass testsuite (old and new get the same result), but new
can fix "((void (*)(void))0)()" issue. So I guess this fix is valid. :-)


Thanks.
--
Chen Gang

Open share and attitude like air water and life which God blessed

[Michael Eager]

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 is for a bare-metal environment.

If you are testing in a Linux environment, the tool chain you uses
should provide a default linker script which matches your hardware's
memory layout. You should not need to provide a separate linker script.

--
Michael Eager ***@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077

[Chen Gang]

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 is for a bare-metal environment.
>
> If you are testing in a Linux environment, the tool chain you uses
> should provide a default linker script which matches your hardware's
> memory layout. You should not need to provide a separate linker script.
>

OK, thanks, I shall try to find the default linker script for it.

Thanks
--
Chen Gang

Open, share, and attitude like air, water, and life which God blessed

[Michael Eager]

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/Xilinx/dg/microblaze_0/LinkScr.ld"
>>
>> Hi Chen --
>>
>> The DejaGNU configuration I provided is for a bare-metal environment.
>>
>> If you are testing in a Linux environment, the tool chain you uses
>> should provide a default linker script which matches your hardware's
>> memory layout. You should not need to provide a separate linker script.
>>
>
> OK, thanks, I shall try to find the default linker script for it.

If you are running mb-gcc which generates executables which run on
the target, you do not need to provide a linker script.


--
Michael Eager ***@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077

[Chen Gang]

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/Xilinx/dg/microblaze_0/LinkScr.ld"
>>>
>>> Hi Chen --
>>>
>>> The DejaGNU configuration I provided is for a bare-metal environment.
>>>
>>> If you are testing in a Linux environment, the tool chain you uses
>>> should provide a default linker script which matches your hardware's
>>> memory layout. You should not need to provide a separate linker script.
>>>
>>
>> OK, thanks, I shall try to find the default linker script for it.
>
> If you are running mb-gcc which generates executables which run on
> the target, you do not need to provide a linker script.
>

OK, thanks. I shall remove it, next.

Thanks.
--
Chen Gang

Open share and attitude like air water and life which God blessed

[Chen Gang]

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.

Hope I can succeed.

Thanks

Send from Lenovo A788t.

Mike Stump <***@comcast.net> wrote:

>On Sep 24, 2014, at 9:23 AM, Chen Gang <***@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 environments
>> under fedora x86_64, no any real or virtual target for test.
>
>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 targe

[Chen Gang]

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 incorrectly
installed mpc: need "brew install libmpc", not "brew install mpc", and
also need "brew link libmpc" which I missed.

At present, except for libjave Throw_2.exe test, I guess all others are
OK, please help check the result below, thanks.

If it passes checking, next, I shall try to fix libjava Throw_2 issue
within this month (others, include Throw_1 and Throw_3 are all OK).

=== g++ Summary ===

# of expected passes 82961
# of unexpected failures 891
# of expected failures 255
# of unresolved testcases 272
# of unsupported tests 3421

=== gcc Summary ===

# of expected passes 85011
# of unexpected failures 30
# of expected failures 182
# of unresolved testcases 10
# of unsupported tests 2796

=== gfortran Summary ===

# of expected passes 46354
# of unexpected failures 1
# of expected failures 38
# of unsupported tests 74

=== gnat Summary ===

# of expected passes 799
# of unexpected failures 67
# of unexpected successes 18
# of unresolved testcases 382
# of unsupported tests 8

=== objc Summary ===

# of expected passes 5828
# of unexpected failures 4
# of expected failures 6
# of unsupported tests 77

=== boehm-gc Summary ===

# of expected passes 12
# of unsupported tests 1

=== libatomic Summary ===

# of expected passes 54

=== libffi Summary ===

# of expected passes 1819
# of unsupported tests 55

=== libgomp Summary ===

# of expected passes 3194
# of unsupported tests 38

=== libitm Summary ===

# of expected passes 26
# of expected failures 3
# of unsupported tests 1

=== libjava Summary ===

# of expected passes 2574
# of unexpected failures 4 /* The 4 issues are all related with Throw_2.exe */
# of expected failures 4
# of untested testcases 4

=== libstdc++ Summary ===

# of expected passes 8956
# of unexpected failures 159
# of expected failures 69
# of unresolved testcases 38
# of unsupported tests 670


Thanks.
--
Chen Gang

Open, share, and attitude like air, water, and life which God blessed

[Chen Gang]

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 under Darwin x86_64, originally, I incorrectly
> installed mpc: need "brew install libmpc", not "brew install mpc", and
> also need "brew link libmpc" which I missed.
>
> At present, except for libjave Throw_2.exe test, I guess all others are
> OK, please help check the result below, thanks.
>

Oh, sorry, I forgot to mention 2 things:

- config with "--disable-multilibs", and I shall try normal configiure
again (although I guess, it will also be OK), hope I can finish
within 2 days.

- And during test libjava, it will quit with error because of Throw_2,
so I modified the related Makefile to skip it.


> If it passes checking, next, I shall try to fix libjava Throw_2 issue
> within this month (others, include Throw_1 and Throw_3 are all OK).
>
> === g++ Summary ===
>
> # of expected passes 82961
> # of unexpected failures 891
> # of expected failures 255
> # of unresolved testcases 272
> # of unsupported tests 3421
>
> === gcc Summary ===
>
> # of expected passes 85011
> # of unexpected failures 30
> # of expected failures 182
> # of unresolved testcases 10
> # of unsupported tests 2796
>
> === gfortran Summary ===
>
> # of expected passes 46354
> # of unexpected failures 1
> # of expected failures 38
> # of unsupported tests 74
>
> === gnat Summary ===
>
> # of expected passes 799
> # of unexpected failures 67
> # of unexpected successes 18
> # of unresolved testcases 382
> # of unsupported tests 8
>
> === objc Summary ===
>
> # of expected passes 5828
> # of unexpected failures 4
> # of expected failures 6
> # of unsupported tests 77
>
> === boehm-gc Summary ===
>
> # of expected passes 12
> # of unsupported tests 1
>
> === libatomic Summary ===
>
> # of expected passes 54
>
> === libffi Summary ===
>
> # of expected passes 1819
> # of unsupported tests 55
>
> === libgomp Summary ===
>
> # of expected passes 3194
> # of unsupported tests 38
>
> === libitm Summary ===
>
> # of expected passes 26
> # of expected failures 3
> # of unsupported tests 1
>
> === libjava Summary ===
>
> # of expected passes 2574
> # of unexpected failures 4 /* The 4 issues are all related with Throw_2.exe */
> # of expected failures 4
> # of untested testcases 4
>
> === libstdc++ Summary ===
>
> # of expected passes 8956
> # of unexpected failures 159
> # of expected failures 69
> # of unresolved testcases 38
> # of unsupported tests 670
>
>
> Thanks.
>

--
Chen Gang

Open, share, and attitude like air, water, and life which God blessed

[Chen Gang]

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 for gcc.
>>
>> I finish tried testsuit under Darwin x86_64, originally, I incorrectly
>> installed mpc: need "brew install libmpc", not "brew install mpc", and
>> also need "brew link libmpc" which I missed.
>>
>> At present, except for libjave Throw_2.exe test, I guess all others are
>> OK, please help check the result below, thanks.
>>
>
> Oh, sorry, I forgot to mention 2 things:
>
> - config with "--disable-multilibs", and I shall try normal configiure
> again (although I guess, it will also be OK), hope I can finish
> within 2 days.
>
> - And during test libjava, it will quit with error because of Throw_2,
> so I modified the related Makefile to skip it.
>

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.


Thanks.

>
>> If it passes checking, next, I shall try to fix libjava Throw_2 issue
>> within this month (others, include Throw_1 and Throw_3 are all OK).
>>
>> === g++ Summary ===
>>
>> # of expected passes 82961
>> # of unexpected failures 891
>> # of expected failures 255
>> # of unresolved testcases 272
>> # of unsupported tests 3421
>>
>> === gcc Summary ===
>>
>> # of expected passes 85011
>> # of unexpected failures 30
>> # of expected failures 182
>> # of unresolved testcases 10
>> # of unsupported tests 2796
>>
>> === gfortran Summary ===
>>
>> # of expected passes 46354
>> # of unexpected failures 1
>> # of expected failures 38
>> # of unsupported tests 74
>>
>> === gnat Summary ===
>>
>> # of expected passes 799
>> # of unexpected failures 67
>> # of unexpected successes 18
>> # of unresolved testcases 382
>> # of unsupported tests 8
>>
>> === objc Summary ===
>>
>> # of expected passes 5828
>> # of unexpected failures 4
>> # of expected failures 6
>> # of unsupported tests 77
>>
>> === boehm-gc Summary ===
>>
>> # of expected passes 12
>> # of unsupported tests 1
>>
>> === libatomic Summary ===
>>
>> # of expected passes 54
>>
>> === libffi Summary ===
>>
>> # of expected passes 1819
>> # of unsupported tests 55
>>
>> === libgomp Summary ===
>>
>> # of expected passes 3194
>> # of unsupported tests 38
>>
>> === libitm Summary ===
>>
>> # of expected passes 26
>> # of expected failures 3
>> # of unsupported tests 1
>>
>> === libjava Summary ===
>>
>> # of expected passes 2574
>> # of unexpected failures 4 /* The 4 issues are all related with Throw_2.exe */
>> # of expected failures 4
>> # of untested testcases 4
>>
>> === libstdc++ Summary ===
>>
>> # of expected passes 8956
>> # of unexpected failures 159
>> # of expected failures 69
>> # of unresolved testcases 38
>> # of unsupported tests 670
>>
>>
>> Thanks.
>>
>

--
Chen Gang

Open, share, and attitude like air, water, and life which God blessed

[Andrew Haley]

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.

Throw_2 is a test specially contrived to detect segfaults that are
not being correctly detected and turned into NullPointerException()s.
A failure indicates that the segfault signal handler is broken.

Andrew.

[Chen Gang]

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.
>
> Throw_2 is a test specially contrived to detect segfaults that are
> not being correctly detected and turned into NullPointerException()s.
> A failure indicates that the segfault signal handler is broken.
>

OK, thank, at present, it passes compiling (can generate 'Throw_2.exe'),
and after run it without any parameters, "1" is printed, but "2" is not
printed.

Under Fedora 20 x86_64, the same gcc code, it is OK ("2" can be printed),
but under Darwin x86_64, it is "Abort trap: 6" instead of. The related
code: "try{Double.parseDouble(str());}catch", and "str(){return null;}".

And I shall continue to try to analyze it (within this month), and
welcome any additional ideas, suggestions, and completion for it,


Thanks
--
Chen Gang

Open, share, and attitude like air, water, and life which God blessed

[Andrew Haley]

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 within a week, I shall continue to try to
>>> analyze the libjava Throw_2 issue.
>>
>> Throw_2 is a test specially contrived to detect segfaults that are
>> not being correctly detected and turned into NullPointerException()s.
>> A failure indicates that the segfault signal handler is broken.
>
> OK, thank, at present, it passes compiling (can generate 'Throw_2.exe'),
> and after run it without any parameters, "1" is printed, but "2" is not
> printed.
>
> Under Fedora 20 x86_64, the same gcc code, it is OK ("2" can be printed),
> but under Darwin x86_64, it is "Abort trap: 6" instead of. The related
> code: "try{Double.parseDouble(str());}catch", and "str(){return null;}".
>
> And I shall continue to try to analyze it (within this month), and
> welcome any additional ideas, suggestions, and completion for it,

Not every platform supports unwinding through signal handlers. In x86
Linux there is some very clever code which interacts with the kernel to
allow this.

Andrew.

[Chen Gang]

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 within a week, I shall continue to try to
>>>> analyze the libjava Throw_2 issue.
>>>
>>> Throw_2 is a test specially contrived to detect segfaults that are
>>> not being correctly detected and turned into NullPointerException()s.
>>> A failure indicates that the segfault signal handler is broken.
>>
>> OK, thank, at present, it passes compiling (can generate 'Throw_2.exe'),
>> and after run it without any parameters, "1" is printed, but "2" is not
>> printed.
>>
>> Under Fedora 20 x86_64, the same gcc code, it is OK ("2" can be printed),
>> but under Darwin x86_64, it is "Abort trap: 6" instead of. The related
>> code: "try{Double.parseDouble(str());}catch", and "str(){return null;}".
>>
>> And I shall continue to try to analyze it (within this month), and
>> welcome any additional ideas, suggestions, and completion for it,
>
> Not every platform supports unwinding through signal handlers. In x86
> Linux there is some very clever code which interacts with the kernel to
> allow this.
>

Excuse me, I am not quite familiar with Java, I guess what you said is:

- The related feature need OS kernel support, if OS kernel does not
support, it may report "Abort trap: 6" or others.

- And OS kernel has feature to support "1" printed does not mean it
also has feature to support "2" printed.

- And I need try to make sure that my current Darwin kernel whether
supports it or not.

If what I guess is incorrect, please let me know, thanks.

For me, whether Darwin kernel supports or not, we have to improve
current implementation (may be testsuite configure or Makefile) to
avoid testsuite breaking.


Thanks.
--
Chen Gang

Open, share, and attitude like air, water, and life which God blessed

[Andrew Haley]

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 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.
>>>>
>>>> Throw_2 is a test specially contrived to detect segfaults that are
>>>> not being correctly detected and turned into NullPointerException()s.
>>>> A failure indicates that the segfault signal handler is broken.
>>>
>>> OK, thank, at present, it passes compiling (can generate 'Throw_2.exe'),
>>> and after run it without any parameters, "1" is printed, but "2" is not
>>> printed.
>>>
>>> Under Fedora 20 x86_64, the same gcc code, it is OK ("2" can be printed),
>>> but under Darwin x86_64, it is "Abort trap: 6" instead of. The related
>>> code: "try{Double.parseDouble(str());}catch", and "str(){return null;}".
>>>
>>> And I shall continue to try to analyze it (within this month), and
>>> welcome any additional ideas, suggestions, and completion for it,
>>
>> Not every platform supports unwinding through signal handlers. In x86
>> Linux there is some very clever code which interacts with the kernel to
>> allow this.
>
> Excuse me, I am not quite familiar with Java, I guess what you said is:
>
> - The related feature need OS kernel support, if OS kernel does not
> support, it may report "Abort trap: 6" or others.
>
> - And OS kernel has feature to support "1" printed does not mean it
> also has feature to support "2" printed.
>
> - And I need try to make sure that my current Darwin kernel whether
> supports it or not.
>
> If what I guess is incorrect, please let me know, thanks.

That sounds approximately right, but it's changed a lot since I last
looked. It may be that the magic is in glibc rather than the kernel.

> For me, whether Darwin kernel supports or not, we have to improve
> current implementation (may be testsuite configure or Makefile) to
> avoid testsuite breaking.

The testsuite isn't breaking: it's telling you something useful.

Andrew.

[Chen Gang]

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 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.
>>>>>
>>>>> Throw_2 is a test specially contrived to detect segfaults that are
>>>>> not being correctly detected and turned into NullPointerException()s.
>>>>> A failure indicates that the segfault signal handler is broken.
>>>>
>>>> OK, thank, at present, it passes compiling (can generate 'Throw_2.exe'),
>>>> and after run it without any parameters, "1" is printed, but "2" is not
>>>> printed.
>>>>
>>>> Under Fedora 20 x86_64, the same gcc code, it is OK ("2" can be printed),
>>>> but under Darwin x86_64, it is "Abort trap: 6" instead of. The related
>>>> code: "try{Double.parseDouble(str());}catch", and "str(){return null;}".
>>>>
>>>> And I shall continue to try to analyze it (within this month), and
>>>> welcome any additional ideas, suggestions, and completion for it,
>>>
>>> Not every platform supports unwinding through signal handlers. In x86
>>> Linux there is some very clever code which interacts with the kernel to
>>> allow this.
>>
>> Excuse me, I am not quite familiar with Java, I guess what you said is:
>>
>> - The related feature need OS kernel support, if OS kernel does not
>> support, it may report "Abort trap: 6" or others.
>>
>> - And OS kernel has feature to support "1" printed does not mean it
>> also has feature to support "2" printed.
>>
>> - And I need try to make sure that my current Darwin kernel whether
>> supports it or not.
>>
>> If what I guess is incorrect, please let me know, thanks.
>
> That sounds approximately right, but it's changed a lot since I last
> looked. It may be that the magic is in glibc rather than the kernel.
>

OK, thanks, I shall also notice about glibc when I try to analyze it,
e.g. need try to build and install upstream glibc instead of the Darwin
glibc (I am not quite sure whether I can do that, I guess I can).


>> For me, whether Darwin kernel supports or not, we have to improve
>> current implementation (may be testsuite configure or Makefile) to
>> avoid testsuite breaking.
>
> 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, the related temporarily skip diff may like
below (in real action, I modify the related Makefile, directly):

diff --git a/libjava/testsuite/Makefile.in b/libjava/testsuite/Makefile.in
index 28fc102..d1e77de 100644
--- a/libjava/testsuite/Makefile.in
+++ b/libjava/testsuite/Makefile.in
@@ -390,7 +390,7 @@ check-DEJAGNU: site.exp
if $(SHELL) -c "$$runtest --version" > /dev/null 2>&1; then \
exit_status=0; l='$(DEJATOOL)'; for tool in $$l; do \
if $$runtest $(AM_RUNTESTFLAGS) $(RUNTESTDEFAULTFLAGS) $(RUNTESTFLAGS); \
- then :; else exit_status=1; fi; \
+ then :; else exit_status=0; fi; \
done; \
else echo "WARNING: could not find \`runtest'" 1>&2; :;\
fi; \
ba

Thanks.
--
Chen Gang

Open, share, and attitude like air, water, and life which God blessed

[Andrew Haley]

On 10/06/2014 04:00 PM, Chen Gang wrote:
> 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 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.
>>>>>>
>>>>>> Throw_2 is a test specially contrived to detect segfaults that are
>>>>>> not being correctly detected and turned into NullPointerException()s.
>>>>>> A failure indicates that the segfault signal handler is broken.
>>>>>
>>>>> OK, thank, at present, it passes compiling (can generate 'Throw_2.exe'),
>>>>> and after run it without any parameters, "1" is printed, but "2" is not
>>>>> printed.
>>>>>
>>>>> Under Fedora 20 x86_64, the same gcc code, it is OK ("2" can be printed),
>>>>> but under Darwin x86_64, it is "Abort trap: 6" instead of. The related
>>>>> code: "try{Double.parseDouble(str());}catch", and "str(){return null;}".
>>>>>
>>>>> And I shall continue to try to analyze it (within this month), and
>>>>> welcome any additional ideas, suggestions, and completion for it,
>>>>
>>>> Not every platform supports unwinding through signal handlers. In x86
>>>> Linux there is some very clever code which interacts with the kernel to
>>>> allow this.
>>>
>>> Excuse me, I am not quite familiar with Java, I guess what you said is:
>>>
>>> - The related feature need OS kernel support, if OS kernel does not
>>> support, it may report "Abort trap: 6" or others.
>>>
>>> - And OS kernel has feature to support "1" printed does not mean it
>>> also has feature to support "2" printed.
>>>
>>> - And I need try to make sure that my current Darwin kernel whether
>>> supports it or not.
>>>
>>> If what I guess is incorrect, please let me know, thanks.
>>
>> That sounds approximately right, but it's changed a lot since I last
>> looked. It may be that the magic is in glibc rather than the kernel.
>>
>
> OK, thanks, I shall also notice about glibc when I try to analyze it,
> e.g. need try to build and install upstream glibc instead of the Darwin
> glibc (I am not quite sure whether I can do that, I guess I can).
>
>
>>> For me, whether Darwin kernel supports or not, we have to improve
>>> current implementation (may be testsuite configure or Makefile) to
>>> avoid testsuite breaking.
>>
>> 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, the related temporarily skip diff may like
> below (in real action, I modify the related Makefile, directly):

You're missing what I'm saying. The testuite is not broken.

You should be running "make -k check".

Andrew.

[Chen Gang]

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, the related temporarily skip diff may like
>> below (in real action, I modify the related Makefile, directly):
>
> You're missing what I'm saying. The testuite is not broken.
>
> You should be running "make -k check".
>

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):

- "make check" is the standard check for global, so when find new
issues (include environment construction), need stop in time.

- If one sub-system wants to skip the known issue, it can mark it as
'unexpected', or just simply return 0 to Makefile to let checking
continue (I guess, most of other sub-system do in this way).

- Or for other members (especially for newbies, e.g. me), he/she can
not sure whether the environment construction for testsuite is OK or
not:

e.g. For our case, after build upstream glibc and let testsuite use
it instead of Darwin glibc, all things may go OK. If really it is,
it is environments construction (not testsuite or code) issue.


Thanks.
--
Chen Gang

Open, share, and attitude like air, water, and life which God blessed

[Mike Stump]

On Oct 6, 2014, at 8:36 AM, Chen Gang <***@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, there is no sub-system, so, talk of such is outside the scope of gcc.

Let me repeat what he said differently.

You have two choices, fixing the port so that there are no unexpected failures or running check with -k.

I’d like to get to the point where all primary/secondary platforms can use make check directly, we’re not there yet.

The idea is that the single return value tells if if the suite passed or not. This is an absolute measure, that, when achieved means one never has to compare previous/present results, just know that the suite passed. Sometimes simple is better.

> - "make check" is the standard check for global,

No sub-system, no global.

[Chen Gang]

On 10/7/14 1:29, Mike Stump wrote:
> On Oct 6, 2014, at 8:36 AM, Chen Gang <***@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, there is no sub-system, so, talk of such is outside the scope of gcc.
>
> Let me repeat what he said differently.
>
> You have two choices, fixing the port so that there are no unexpected failures or running check with -k.
>
> I’d like to get to the point where all primary/secondary platforms can use make check directly, we’re not there yet.
>
> The idea is that the single return value tells if if the suite passed or not. This is an absolute measure, that, when achieved means one never has to compare previous/present results, just know that the suite passed. Sometimes simple is better.
>
>> - "make check" is the standard check for global,
>
> No sub-system, no global.
>

Theoretically, in each system (include gcc), always can be separated
into several 'sub-systems', and then 'global' means the system itself.

In our case, we say let 'global' pass checking means let gcc, gfortran,
g++, libjava ... all pass checking. But for mainly focus on constructing
environments, I will try to use upstream glibc instead of Darwin glibc:

- If fix Throw_2, we know it is environments construction issue.

- Else, I shall skip it (since "make -k check" should be OK).

And after finish testsuite under Darwin, within this month, I shall try
to find and send a patch for gcc, and pass testsuite under Darwin (it
seems it is not quite difficult to me).


Thanks
--
Chen Gang

Open, share, and attitude like air, water, and life which God blessed

[Chen Gang]

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 <***@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, there is no sub-system, so, talk of such is outside the scope of gcc.
>>
>> Let me repeat what he said differently.
>>
>> You have two choices, fixing the port so that there are no unexpected failures or running check with -k.
>>
>> I’d like to get to the point where all primary/secondary platforms can use make check directly, we’re not there yet.
>>
>> The idea is that the single return value tells if if the suite passed or not. This is an absolute measure, that, when achieved means one never has to compare previous/present results, just know that the suite passed. Sometimes simple is better.
>>
>>> - "make check" is the standard check for global,
>>
>> No sub-system, no global.
>>
>
> Theoretically, in each system (include gcc), always can be separated
> into several 'sub-systems', and then 'global' means the system itself.
>
> In our case, we say let 'global' pass checking means let gcc, gfortran,
> g++, libjava ... all pass checking. But for mainly focus on constructing
> environments, I will try to use upstream glibc instead of Darwin glibc:
>
> - If fix Throw_2, we know it is environments construction issue.
>
> - Else, I shall skip it (since "make -k check" should be OK).
>
> And after finish testsuite under Darwin, within this month, I shall try
> to find and send a patch for gcc, and pass testsuite under Darwin (it
> seems it is not quite difficult to me).
>
>

It is really unlucky, The upstream glibc does not support Darwin! And
sorry, send patches to glibc is really out of my current border, so I
have to give up. :-(

bash-3.2# ../glibc/configure --with-prefix=/release/Darwin/ --with-sysroot=/release/Darwin
checking build system type... x86_64-apple-darwin13.4.0
checking host system type... x86_64-apple-darwin13.4.0
checking for gcc... gcc
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking for readelf... no
checking for sysdeps preconfigure fragments... aarch64 alpha arm hppa i386 m68k microblaze mips powerpc s390 sh sparc tile x86_64 checking whether gcc compiles in -mx32 mode by default... no

configure: running configure fragment for add-on libidn
*** The GNU C library is currently not available for this platform.
*** So far nobody cared to port it and if there is no volunteer it
*** might never happen. So, if you have interest to see glibc on
*** this platform visit
*** http://www.gnu.org/software/libc/porting.html
*** and join the group of porters


And I guess, this thread can be ended, and next, I shall try to find a
patch for gcc, and let it pass testsuite under Darwin.


Thanks.
--
Chen Gang

Open, share, and attitude like air, water, and life which God blessed

[Chen Gang]

Thank you for your information, I shall notice about it when trying Qemu microblaze.

Thanks

Send from Lenovo A788t.

Michael Eager <***@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 <***@eagerm.com> wrote:
>>>>> After check the current result log, I find many remote target test
>>>>> related sentences, do we have to process it?
>>>>>
>>>>> e.g. "Download to microblaze-xilinx-gdb failed, couldn't execute "rcp": no such file or directory."
>>>>
>>>> The test suite uses rcp to transfer files to or from the target,
>>>> either to provide input to a test case or to check the output.
>>>> Most Linux systems do not install rcp, since it is a security risk.
>>>
>>> To clarify:
>>>
>>> if {[board_info $desthost exists rcp_prog]} {
>>> set RCP [board_info $desthost rcp_prog]
>>> } else {
>>> set RCP rcp
>>> }
>>>
>>> So, if you set rcp_prog to something else, you should be able to avoid rsh if you want. Most people use ssh now-a-days. You will want it set up to not require a password for testing.
>>>
>>
>> OK, thank you for your information.
>>
>> 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 environments
>> under fedora x86_64, no any real or virtual target for test.
>
>You can see the command which is getting the error by looking at gcc.log.
>If the command is not displayed, add another "-v" (or two) to RUNTESTFLAGS.
>
>If I recall correctly, DejaGNU is executing a command like "rcp file microblaze-xilinx-gdb".
>This means that you need to have the name microblaze-xilinx-gdb resolved into an IP address.
>This can be done by adding it to /etc/hosts. Or you can specify the target IP address
>in the DejaGNU options. I don't recall which one off the top of my head.
>
>--
>Michael Eager ***@eagercon.com
>1960 Park Blvd., Palo Alto, CA 94306 650-