This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Test Harness and SPARC VIS Instructions

Seongbae Park (박성배, 朴成培) wrote:
> On Thu, Mar 13, 2008 at 11:31 AM, Joel Sherrill
> <> wrote:
>> Hi,
>>  Moving on the SPARC, I see a lot of similar
>>  unsupported instruction failures.  I only
>>  see a single sparc feature test.  It is for
>>  "-multrasparc -mvis" and it is actually
>>  passing on the sparc instruction simulator in
>>  gdb. It doesn't make me feel good that this
>>  part passes since I thought SIS was a vanilla
>>  V7 simulator. I think this test isn't tight enough:
>>  proc check_effective_target_ultrasparc_hw { } {
>>     return [check_runtime ultrasparc_hw {
>>     int main() { return 0; }
>>     } "-mcpu=ultrasparc"]
>>  }
>>  For sure though, SIS does NOT support VIS and
>>  there is no test for that.  This leads to this:
>>  Starting program:
>>  /home/joel/work-gnat/svn/b-gcc1-sparc/gcc/testsuite/gcc/pr18400.exe
>>  Unexpected trap (0x 2) at address 0x02001318
>>  illegal instruction
>>  Program exited normally.
>>  (gdb) disassemble 0x02001318
>>  Dump of assembler code for function check_vect:
>>  ...
>>  0x02001318 <check_vect+20>:     impdep1  62, %g0, %g0, %g0
>>  ...
>>  Can someone familiar with VIS provide an instruction
>>  that is OK to do a run-time test with to check if
>>  it is supported?
> I don't think there's any user level instruction/register to do that.
> You'll have to catch the illegal instruction trap :(
I have learned a lot the past few days so let me see if I can explain
what I have learned. :-D

Depending upon the test and target architecture, there are various
mechanisms to prevent the execution of code which is clearly not
supported on a particular target board/cpu (as opposed to the compiler

+ many architectures check that a multilib flag is supported
+ Some do a run-time check. x86 uses cpuid and feature check
to avoid things at run-time
+ Some run a test and let it die on the target board. This is used
by Altivec and ARM Neon.

The last alternative is what will have to be done here. I just
need the single easiest VIS instruction to force the failure.
> Seongbae

Joel Sherrill, Ph.D.             Director of Research & Development        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]