This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch, testsuite] Require int32 target support in sso tests
- From: Mike Stump <mikestump at comcast dot net>
- To: Senthil Kumar Selvaraj <senthil_kumar dot selvaraj at atmel dot com>
- Cc: gcc-patches <gcc-patches at gcc dot gnu dot org>, Eric Botcazou <ebotcazou at adacore dot com>
- Date: Thu, 4 Feb 2016 06:53:19 -0800
- Subject: Re: [Patch, testsuite] Require int32 target support in sso tests
- Authentication-results: sourceware.org; auth=none
- References: <87bn7wa8rh dot fsf at jaguar dot corp dot atmel dot com>
On Feb 4, 2016, at 5:46 AM, Senthil Kumar Selvaraj <senthil_kumar.selvaraj@atmel.com> wrote:
> When running the regression testsuite for the AVR target, I noticed a
> bunch of sso tests failing
> If this patch is ok, could someone commit please?
The patch is Ok.
I don’t recall a target supports for I/O. So, I/O is incredible useful. If you have a simulator, you should take a moment to wire up some IO. Worst case, you can grab some random instruction, (say svc, trap), and wire in a byte output routine. Should be just 50 lines of code or so. This is handy for debugging code on the simulator even if the actual hardware has no way to do I/O.
You should be able to add a target support for io, should only be 10 lines of code or so.
I noticed:
spawn mach-run ./p1.exe^M
My_R1 : 78 56 34 12^M
My_R2 : 12 34 56 78^M
Local_R1 : 78 56 34 12^M
Local_R2 : 12 34 56 78^M
Local_R1 : 78 56 34 12^M
Local_R2 : 12 34 56 78^M
Local_R1 : 78 56 34 12^M
Local_R2 : 12 34 56 78^M
*** EXIT code 0^M
PASS: gcc.dg/sso/p1.c -O0 execution test
FAIL: gcc.dg/sso/p1.c -O0 output pattern test, is My_R1 : 78 56 34 12^M
My_R2 : 12 34 56 78^M
Local_R1 : 78 56 34 12^M
Local_R2 : 12 34 56 78^M
Local_R1 : 78 56 34 12^M
Local_R2 : 12 34 56 78^M
Local_R1 : 78 56 34 12^M
Local_R2 : 12 34 56 78, should match My_R1 : 78 56 34 12.*
My_R2 : 12 34 56 78.*
Local_R1 : 78 56 34 12.*
Local_R2 : 12 34 56 78.*
Local_R1 : 78 56 34 12.*
Local_R2 : 12 34 56 78.*
Local_R1 : 78 56 34 12.*
Local_R2 : 12 34 56 78.*
Anyone have a sense of how this is supposed to work and what is wrong? The lines appear to be the same to me. :-(
The only thing that might throw it would be the *** EXIT code 0, but, it would seem that wasn’t in the output above.