http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53676
--- Comment #16 from Matt Hargett <matt at use dot net> 2012-08-23 18:01:08 UTC --- Back/forward-porting of the "trivial" restoration of the old behavior is acceptable to me, as it would remove a major barrier to our adoption of 4.7.x. That being said, if there's multi-platform testing I can do with a 'better' fix based on trunk, I have SPARC and ARM qemu environments set up to regression test on. BTW, I realized that my initial analysis was wrong -- the int32_t and uint32_t benchmarks are unaffected by this regression. Let me know if there's an easy way to apply the restoration patch and I'll test it locally on our amdfam10 and bdver2 hardware. If the testcase committed to trunk would be applicable to a 4.7 fix as well, I can make a patch to integrate that to ensure thie functionality doesn't regress again in future 4.7.x point releases. I'm happy to do as much footwork as my expertise allows, just let me know :) Thanks!
