Bug 1677652

Summary:	ppc64le: Double-to-float conversion uses wrong rounding mode when followed by memcpy
Product:	Red Hat Enterprise Linux 8	Reporter:	Victor Stinner <vstinner>
Component:	gcc	Assignee:	Marek Polacek <mpolacek>
gcc sub component:	system-version	QA Contact:	Alexandra Petlanová Hájková <ahajkova>
Status:	CLOSED ERRATA	Docs Contact:
Severity:	unspecified
Priority:	unspecified	CC:	codonell, fweimer, jakub, mcermak, mpetlan, mpolacek, ohudlick, pviktori
Version:	8.1
Target Milestone:	rc
Target Release:	8.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	gcc-8.3.1-4.el8	Doc Type:	No Doc Update
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2019-11-05 22:16:35 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	1680182, 1682592
Bug Blocks:	1639502, 1684553, 1684559

Description Victor Stinner 2019-02-15 13:45:18 UTC

Would it be possible to get the following PPC64LE fix in GCC 8.2 of RHEL 8.1?

The bug has been fixed in master and 8.3 branches of GCC.

Copy of initial message of:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88892

---
With gcc-8.2.1-6.fc28.ppc64le, this code

void
f (double d, char *target)
{
  float f = d;
  __builtin_memcpy (target, &f, sizeof (f));
}

results (with -O2) in (omitting the unwinding information):

f:
        stfs 1,0(4)
        blr

This is incorrect because stfs rounds to zero.  An frsp instruction is missing before the stfs (and would be emitted without the memcpy).

(GCC documents that the default rounding mode “is round-to-zero for all floating point to integer conversions, and round-to-nearest for all other arithmetic truncations”; see -frounding-mode.)

Found by the Python testsuite: https://bugs.python.org/issue35752
---

Links:

* GCC upstream bug (fixed!): https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88892
* Python upstream bug: https://bugs.python.org/issue35752
* Python downstream bug reported in Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=1540995

Comment 1 Victor Stinner 2019-03-26 14:09:49 UTC

Any update on this bug? We need the fix for Python: bz#1639502.

Comment 2 Marek Polacek 2019-04-09 16:53:55 UTC

The upstream fix has been committed to 8.3, so the fix will be included in the next update from upstream.  I'm not sure when exactly that will happen.

Comment 3 Miro Hrončok 2019-05-07 13:11:46 UTC

Is this planned to be backported to RHEL 8.1.0?

Comment 4 Marek Polacek 2019-05-07 14:08:18 UTC

(In reply to Miro Hrončok from comment #3)
> Is this planned to be backported to RHEL 8.1.0?

Yes.  In fact, I'm about to start the build; it should be available today.

Comment 5 Miro Hrončok 2019-05-07 14:15:32 UTC

Excellent! Thank You.

Comment 9 Alexandra Petlanová Hájková 2019-08-05 20:40:56 UTC

Hello Marek,

there might be some problem,

void
f (double d, char *target)
{
  float f = d;
  __builtin_memcpy (target, &f, sizeof (f));
}

still results (with -O2) in

        stfs 1,0(4)
        blr

for both gcc-8.3.1-4.4.el8.ppc64le and gcc-8.3.1-4.5.el8.ppc64le on power9.

Comment 10 Marek Polacek 2019-08-07 23:53:00 UTC

I think this is fine.  The original bug report says "An frsp instruction is missing before the stfs."
If I use gcc-8.2.1-3.5 (which doesn't have the fix), then compiling the testcase results in:

f:
.LFB0:
	.cfi_startproc
	stfs 1,0(4)
	blr

whereas if I use gcc-8.3.1-4.5 (which has the fix):

f:
.LFB0:
	.cfi_startproc
	frsp 1,1
	stfs 1,0(4)
	blr

which has "frsp" before "stfs".

Comment 13 errata-xmlrpc 2019-11-05 22:16:35 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2019:3565