Bug 1609058

Summary: Type issue with gcc -On on ppc64 and ppc64le architecture
Product: Red Hat Enterprise Linux 7 Reporter: Andrew Mike <amike>
Component: gccAssignee: Marek Polacek <mpolacek>
Status: CLOSED NOTABUG QA Contact: Michael Petlan <mpetlan>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.4CC: alanm, jakub, jwright, mkolbas, ohudlick
Target Milestone: rc   
Target Release: ---   
Hardware: ppc64le   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-07-26 21:04:49 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:
Attachments:
Description Flags
reproducer source file
none
reproducer source file foo.c
none
reproducer script file run.sh
none
reproducer source file bar.c none

Description Andrew Mike 2018-07-26 20:33:58 UTC
Created attachment 1470878 [details]
reproducer source file

Description of problem: When using the -On flag compiling with gcc on ppc64 and ppc64le architectures, feeding an int as a parameter to a function expecting a variable of type uint8_t results in different values from x86_64.

Version-Release number of selected component (if applicable):
Reproduced on gcc 4.8.5-16.ppc64le, gcc 4.8.5-28.ppc64le, and gcc 4.8.5-16.ppc64.

How reproducible:
Issue is consistently reproducible.

Steps to Reproduce:
See attached test application. 

Actual results:
In the test application, i2 gets truncated (i2 == 176) on all architectures of interest when using either -O0 or -O{1,2,3}.

Expected results:
In the test application, i2 gets truncated (i2 == 176) when using -O0 on all architectures of interest, but when using -O1 or higher, i2 doesn't get truncated (i2 == 432) on ppc64 or ppc64le.

Additional info: Customer reports issue also exists on gcc 6.3, but haven't reproduced it yet.

Comment 2 Andrew Mike 2018-07-26 20:35:31 UTC
Created attachment 1470880 [details]
reproducer source file foo.c

Comment 3 Andrew Mike 2018-07-26 20:36:06 UTC
Created attachment 1470881 [details]
reproducer script file run.sh

Comment 4 Andrew Mike 2018-07-26 20:38:02 UTC
Created attachment 1470883 [details]
reproducer source file bar.c

Comment 5 Andrew Mike 2018-07-26 20:38:47 UTC
To be clear -- the reproducer is a set of three files; download all three, then run run.sh.

Comment 6 Jakub Jelinek 2018-07-26 20:43:42 UTC
It is UB to call a function which has int and uint8_t arguments using a function pointer that has two int arguments.  Don't do that.

Comment 7 Marek Polacek 2018-07-26 21:04:49 UTC
Indeed.  C11 6.3.2.3 says that it's undefined behavior when a pointer is used to call a function whose type is not compatible with the pointed-to type.