[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] target/s390x: Fix CC set by CONVERT TO FIXED/LOGICAL
From: |
Ulrich Weigand |
Subject: |
Re: [PATCH] target/s390x: Fix CC set by CONVERT TO FIXED/LOGICAL |
Date: |
Mon, 28 Jun 2021 18:32:36 +0200 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
On Mon, Jun 28, 2021 at 06:26:52AM -0700, Richard Henderson wrote:
> On 6/28/21 5:58 AM, Ulrich Weigand wrote:
> >>>helper.h:DEF_HELPER_FLAGS_3(clgdb, TCG_CALL_NO_WG, i64, env, i64, i32)
> >>
> >>This won't work reliably. You're writing to a tcg global inside of
> >>a function that says that it won't.
> >
> >I missed that, sorry. That problem can be fixed by changing the above
> >line to something like:
> >DEF_HELPER_3(clgdb, i64, env, i64, i32)
> >right?
>
> Yes.
OK, I'll send a v2 including that change shortly; maybe that is an
acceptable fix for the immediate bug, at least for now.
> >In any case, the current implementation already has two helpers, and
> >I initially tried to keep that, by using a different second part to
> >correctly compute CC. But this ran into the problem that I didn't
> >see any way to detect the fact that the conversion operation had run
> >into one of the special cases in the second helper, without re-doing
> >the whole conversion a second time. Is there any way to pass
> >information between the two helpers (without running again into the
> >same qemu global state updating problem)?
>
> Don't clear out env->fpu_status.float_exception_flags in
> handle_exceptions. Wait until we're actually done with the data.
I don't really know much about qemu internals, but this is really
confusing me, sorry. Aren't env->fpu_status and env->cc_op two
elements of the same global state? Why it is OK to use one of
these fields to pass information to the next helper, but not the
other? I guess I must be missing something here ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
Ulrich.Weigand@de.ibm.com