Comment 7 for bug 1759264

On 04/12/2018 03:41 PM, Alex Bennée wrote:
> Bastian Koppelmann <email address hidden> writes:
>
>> On 04/11/2018 01:01 PM, Alex Bennée wrote:
>>> Bastian Koppelmann <email address hidden> writes:
>>>
>>>> On 04/10/2018 10:07 PM, Alex Bennée wrote:
>>>>> Yeah it looks like it was missed, the round_to_uint code does it.
>>>>>
>>>>> Do you have a test case I can verify?
>>>>>
>>>>
>>>> For the NaN input 0xffffffff the expected result for the flags is that
>>>> flag_invalid is raised.
>>>>
>>>> I can provide you with some TriCore asm, but it is a bit of pain to get
>>>> the gnu assembler to build, since the public version is a decade old.
>>>
>>> I'll trust you if you send me a static binary for this particular
>>> verification ;-)
>>
>> I set up a github repo with working binutils and the corresponding
>> testcase:
>>
>> https://github.com/bkoppelmann/tricore-fpu
>>
>> The one caveat is, that we cannot produce any binaries with the TriCore
>> ISA > 1.3.
>>
>> In this testcase the last ftoi instruction is supposed to raise the
>> invalid flag and return 0 since the input was NaN. We did that by only
>> checking for NaN if any flag was raised after ftoi, then do the NaN
>> check, and if positive, return 0.
>
> Well it builds and I get an fpu-test.elf but I'm a bit stuck on how to
> run it. What are the runes for launching the test?

qemu-system-tricore -M tricore_testboard -kernel fpu-test.elf -nographic

However, this is not really a test. I usually run these against
Infineons golden (sadly proprietary) simulator and compare register
dumps. I have some more regression tests but I haven't had the time make
them into proper tests, such that we don't need this golden model.

Cheers,
Bastian