touch-packages team mailing list archive

[Steve Langasek <steve.langasek@xxxxxxxxxxxxx>]

Hello Peter, or anyone else affected,

Accepted gcc-4.8 into trusty-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/gcc-4.8/4.8.4-2ubuntu1~14.04 in a
few hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to
enable and use -proposed.  Your feedback will aid us getting this update
out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, and change the tag
from verification-needed to verification-done. If it does not fix the
bug for you, please add a comment stating that, and change the tag to
verification-failed.  In either case, details of your testing will help
us make a better decision.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance!

** Changed in: gcc-4.8 (Ubuntu Trusty)
       Status: New => Fix Committed

** Tags added: verification-needed

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to gcc-4.8 in Ubuntu.
https://bugs.launchpad.net/bugs/1322287

Title:
  HTM __builtin_ttest rtl expansion uses wrong shift amount

Status in gcc-4.8 package in Ubuntu:
  Fix Released
Status in gcc-4.8 source package in Trusty:
  Fix Committed

Bug description:
  There is a semi-latent bug for the HTM ttest pattern used with the
  __builtin_ttest() builtin.  This is supposed to expand to a tabortwci.
  instruction which sets cr0 and then some code that copies the cr0 value
  into a gpr and then shifts and masks it into the lowest 2 bits in the gpr.
  The mfcr and mfocrf instructions which can be used to copy the CR0 value
  into a gpr, both copy the value into bits 32-35 of the gpr.  The bug is
  that we only shift the gpr 24 bits to get the CR value into the low
  order bits of the gpr, when we should be shifting 28 bits.  This "works"
  most of the time due to a peculiarity in how the mfocrf instruction
  works, since it copies the CR value into bits 32-35 and duplicates
  that value in bits 36-39.  Since newish -mcpu targets (eg, power8)
  normally generate a mfocrf, we don't see the problem.  However, in some
  cases, we will instead generate a mfcr instruction, which does expose
  the bug.

  This bug was reported upstream with a patch here:

      https://gcc.gnu.org/ml/gcc-patches/2014-05/msg01667.html

  ...and has been fixed upstream in trunk and the FSF 4.9 and FSF 4.8
  branches, as revisions 210815, 210817 and 210818 respectively.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gcc-4.8/+bug/1322287/+subscriptions