Re: [PATCH for-9.2 v3 0/6] target/sparc: emulate floating point queue when raising fp traps

[Carl Hauser]

Yes, but ...

isn't the state of dc->fsr_qne at translation time irrelevant? And changing it at translation time (line 4593) is dangerous (because it pertains to runtime, not translation time); i.e. why is 0 stored at both translation time (4593) and at runtime (4591)? I think that the if on line 4583 needs to be a run-time test. But I get very tangled up in these distinctions. For me, generating a call to a helper function instead of trying to generate all the correct logic made it easier to keep straight what was happening.

On 8/16/24 15:05, Richard Henderson wrote:

> On
>       8/17/24 07:46, Carl Hauser wrote:
>       
> > OK, I think the problem is the handling of
> >         dc->fsr_qne in trans_STDFQ, lines 4583 and 4593 -- the code
> >         is evaluating dc->fsr_qne at translation time and not at
> >         runtime.
> >         
> >       
>       
>       That's what patch 4 does, ensure that the runtime value is
>       available at translation time.
>       
>       
>       
>       r~
>       
>       
>