Discussion:
release 3.12.1 ?
(too old to reply)
Carl E. Love
2017-03-28 20:43:11 UTC
Permalink
Raw Message
Julian:

I know you mentioned the possibility of having a follow on release for
release 3.12.0 in the Nov 2016 time frame. Mark and I were talking
about a couple of bug fixes I recently did for the PPC64 ISA 3.0
support. He is back porting them for the next RHEL point release.

We were wondering if you had decided if you were going to do an
incremental release or not? If so, the following PPC fixes should be
included.

VEX svn r3308

PowerPC: Fix incorrect register pair check for lxv, stxv, stxsd, stxssp, lxsd,
lxssp instructions

The lfdpx, stdpx, lfdp and stfdp instructions work on a register pair. The
register pair test must only be applied to these instructions in the
dis_fp_pair() function.

bugzilla 377427

VEX svn r3317

The mask64 value, in file VEX/priv/guest_ppc_toIR.c is missing the
HWCAPS bit for ISA3.0.

bugzilla 377478

valgrind commit 16254.

PPC64, remove R2 from the clobber list
bugzilla 376729

These are not critical fixes at this point, but should be included in any incremental
release.

When do you plan/expect the next major release (3.13.0) will occur?

Carl Love
Carl E. Love
2017-03-28 21:17:18 UTC
Permalink
Raw Message
Julian:

Oops, had your address as acm.com not acm.org.

Carl Love
Post by Carl E. Love
I know you mentioned the possibility of having a follow on release for
release 3.12.0 in the Nov 2016 time frame. Mark and I were talking
about a couple of bug fixes I recently did for the PPC64 ISA 3.0
support. He is back porting them for the next RHEL point release.
We were wondering if you had decided if you were going to do an
incremental release or not? If so, the following PPC fixes should be
included.
VEX svn r3308
PowerPC: Fix incorrect register pair check for lxv, stxv, stxsd, stxssp, lxsd,
lxssp instructions
The lfdpx, stdpx, lfdp and stfdp instructions work on a register pair. The
register pair test must only be applied to these instructions in the
dis_fp_pair() function.
bugzilla 377427
VEX svn r3317
The mask64 value, in file VEX/priv/guest_ppc_toIR.c is missing the
HWCAPS bit for ISA3.0.
bugzilla 377478
valgrind commit 16254.
PPC64, remove R2 from the clobber list
bugzilla 376729
These are not critical fixes at this point, but should be included in any incremental
release.
When do you plan/expect the next major release (3.13.0) will occur?
Carl Love
Julian Seward
2017-03-29 13:51:26 UTC
Permalink
Raw Message
Carl, hi.

There have been quite a few fixes on the trunk since 3.12 was released,
and I'm somewhat reluctant to merge them all to the branch, not least
because some of the fixes are quite big. On the other hand I'd like to
get all of these fixes to users sooner rather than later.

I have the following alternative proposal: do a 3.13 release in early
May. This would mean we could ship all the fixes on the trunk, and would
avoid the work of merging to the branch. With a freeze/branch date of
Friday 21 April and a release date two weeks later, on Friday 5 May.

How does that sound?

The big 3 things that I'd like to fix before the freeze point are:

(1) some AVX2 insn sequences run the JIT out of space:
https://bugs.kde.org/show_bug.cgi?id=375839

(2) on some processors, ARM64 hangs to due LL/SC looping:
https://bugs.kde.org/show_bug.cgi?id=369459

(3) See if we can do anything about the poor state of the
Mac OS 10.12 port.

Whatever other fixes we can get in before the freeze window, will
also be good, of course.

I don't regard the proposed 3.13 as shipping anything particularly new,
but instead as stabilising and solidifying what we shipped with 3.12.

J
Carl E. Love
2017-03-29 14:57:58 UTC
Permalink
Raw Message
Julian:

A release in the May time frame of trunk to catch all of the updates to
the various platforms sounds good. Thanks.

Carl Love
Post by Julian Seward
Carl, hi.
There have been quite a few fixes on the trunk since 3.12 was released,
and I'm somewhat reluctant to merge them all to the branch, not least
because some of the fixes are quite big. On the other hand I'd like to
get all of these fixes to users sooner rather than later.
I have the following alternative proposal: do a 3.13 release in early
May. This would mean we could ship all the fixes on the trunk, and would
avoid the work of merging to the branch. With a freeze/branch date of
Friday 21 April and a release date two weeks later, on Friday 5 May.
How does that sound?
https://bugs.kde.org/show_bug.cgi?id=375839
https://bugs.kde.org/show_bug.cgi?id=369459
(3) See if we can do anything about the poor state of the
Mac OS 10.12 port.
Whatever other fixes we can get in before the freeze window, will
also be good, of course.
I don't regard the proposed 3.13 as shipping anything particularly new,
but instead as stabilising and solidifying what we shipped with 3.12.
J
Loading...