>
> In comment #9 in the bug
> (https://bugs.launchpad.net/qemu/+bug/1841990/comments/9), I note that the
> issue was produced in running the test suite for the Power Vector Library
> project (https://github.com/open-power-sdk/pveclib), which makes productive
> use of dcbenq.
>
> Maybe that
Please take a look at the following patch
https://lists.nongnu.org/archive/html/qemu-ppc/2019-10/msg00133.html and
let me know if problem is solved.
On 2.10.19. 16:08, Stefan Brankovic wrote:
Hi Mark,
Thank you for reporting this bug. I was away from office for couple of
days, so that's why
On 10/2/19 2:40 PM, Richard Henderson wrote:
> On 10/2/19 10:38 AM, Alex Bennée wrote:
>> Is the denbcdq instruction exposed in any standard float operations?
>> Once this is fixed it would be worth adding a testcase (either ppc64
>> specific or multiarch) so protect it from regression in the
On 10/2/19 10:38 AM, Alex Bennée wrote:
> Is the denbcdq instruction exposed in any standard float operations?
> Once this is fixed it would be worth adding a testcase (either ppc64
> specific or multiarch) so protect it from regression in the future.
Not standard float operations -- this is
Mark Cave-Ayland writes:
> On 28/09/2019 18:45, Aleksandar Markovic wrote:
>
> Hi Aleksandar,
>
> Thanks for taking a look at this!
>
>> Mark and Paul (and Stefan),
>>
>> Thanks for spotting this and pinpointing the culprit commit. I guess Stefan
>> is going
>> to respond soon, but, in the
Hi Mark,
Thank you for reporting this bug. I was away from office for couple of
days, so that's why I am answering you a bit late, sorry about that. I
will start working on a solution and try to fix this problem in next
couple of days.
On 1.10.19. 20:24, Mark Cave-Ayland wrote:
On
On 28/09/2019 18:45, Aleksandar Markovic wrote:
Hi Aleksandar,
Thanks for taking a look at this!
> Mark and Paul (and Stefan),
>
> Thanks for spotting this and pinpointing the culprit commit. I guess Stefan
> is going
> to respond soon, but, in the meantime, I took a look at the commit in
>
30.09.2019. 16.35, "Paul Clarke" је написао/ла:
>
> On 9/28/19 5:17 PM, Aleksandar Markovic wrote:
> > Also, check on the hardware the behavior listed as 'undefined' for
vsl/vsr
> > in the docs - even though it is tehnically irrelevant, I am courious
> > whether the old or the new (or none of
> 5. (a question for Mark) After all recent changes, does get_avr64(...,
..., true) always (for any endian configuration) return the "high" half of
an Altivec register, and get_avr64(..., ..., false) the "low" one?
>
> Given all these circumstances, perhaps the most reasonable solution would
be to
On 9/28/19 5:17 PM, Aleksandar Markovic wrote:
> Also, check on the hardware the behavior listed as 'undefined' for vsl/vsr
> in the docs - even though it is tehnically irrelevant, I am courious
> whether the old or the new (or none of them) solution match the hardware.
There does appear to be
28.09.2019. 19.45, "Aleksandar Markovic" је
написао/ла:
>
>
> 26.09.2019. 20.14, "Mark Cave-Ayland" је
написао/ла:
> >
> > As part of the investigation into the DFP number issue reported at
> > https://bugs.launchpad.net/qemu/+bug/1841990 it appears that there may
also be a bug
> > introduced by
26.09.2019. 20.14, "Mark Cave-Ayland" је
написао/ла:
>
> As part of the investigation into the DFP number issue reported at
> https://bugs.launchpad.net/qemu/+bug/1841990 it appears that there may
also be a bug
> introduced by the new optimised vsl/vsr implementation:
>
> commit
As part of the investigation into the DFP number issue reported at
https://bugs.launchpad.net/qemu/+bug/1841990 it appears that there may also be
a bug
introduced by the new optimised vsl/vsr implementation:
commit 4e6d0920e7547e6af4bbac5ffe9adfe6ea621822
Author: Stefan Brankovic
Date: Mon Jul
13 matches
Mail list logo
