Bug 918189 - binutils-2.23.52.0.1-3.fc19 fails to build for ppc64p7 sub arch
Summary: binutils-2.23.52.0.1-3.fc19 fails to build for ppc64p7 sub arch
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: binutils
Version: rawhide
Hardware: powerpc
OS: Linux
high
high
Target Milestone: ---
Assignee: Brent Baude
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-03-05 16:56 UTC by Karsten Hopp
Modified: 2013-08-07 13:40 UTC (History)
4 users (show)

Fixed In Version: binutils-2.23.88.0.1-10.fc20
Clone Of:
Environment:
Last Closed: 2013-08-07 13:09:27 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Karsten Hopp 2013-03-05 16:56:25 UTC
Description of problem:
ppc64p7 is a Power7 optimized subarch of ppc64. PPC(32) and PPC64 build fine, ppc64p7 aborts with 
libtool: compile:  ppc64-redhat-linux-gcc -DHAVE_CONFIG_H -I. -I. -I. -I../bfd -I./../bfd -I./../include -O3 -mtune=power7 -mcpu=power7 -g -fsigned-char -DENABLE_PLUGINS -DLOCALEDIR=\"/usr/share/locale\" -g -O2 -O3 -mtune=power7 -mcpu=power7 -g -fsigned-char -c testplug.c -o libldtestplug_la-testplug.o >/dev/null 2>&1
./ldfile.c: In function 'ldfile_open_command_file_1':
./ldfile.c:609:17: error: 'sysrooted' may be used uninitialized in this function [-Werror=maybe-uninitialized]

and later on:

strings.c: In function 'print_strings.constprop.1':
strings.c:508:3: error: 'buf[3]' may be used uninitialized in this function [-Werror=maybe-uninitialized]
  ((long) buf[3] << 24);
   ^
strings.c:459:17: note: 'buf[3]' was declared here
   unsigned char buf[4];
                 ^
strings.c:507:44: error: 'buf[2]' may be used uninitialized in this function [-Werror=maybe-uninitialized]
       r = buf[0] | ((long) buf[1] << 8) | ((long) buf[2] << 16) |
                                            ^
strings.c:459:17: note: 'buf[2]' was declared here
   unsigned char buf[4];
                 ^
strings.c:507:21: error: 'buf[1]' may be used uninitialized in this function [-Werror=maybe-uninitialized]
       r = buf[0] | ((long) buf[1] << 8) | ((long) buf[2] << 16) |
                     ^
strings.c:459:17: note: 'buf[1]' was declared here
   unsigned char buf[4];
....




How reproducible:
always

Steps to Reproduce:
1. ppc-koji build --scratch f19 binutils-2.23.52.0.1-3.fc19.src.rpm
2.
3.
  
Actual results:
http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=967857

Expected results:


Additional info:

Comment 1 IBM Bug Proxy 2013-03-05 23:40:30 UTC
These warnings are both false positives, and show up due to -O3 aggressive inlining.  For -O3 builds of binutils, configure with --disable-werror.  Other versions of gcc will give even more warnings.

Comment 2 Nick Clifton 2013-03-06 16:27:47 UTC
FYI - These warnings have already been fixed in the FSF mainline sources and will be incorporated into the Fedora binutils when then next release snapshot is made - probably within a couple of weeks.

Comment 3 Fedora End Of Life 2013-04-03 18:08:01 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19

Comment 4 Karsten Hopp 2013-07-23 12:05:05 UTC
Still happens with binutils-2.23.88.0.1-7.fc20 in F20:
http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=1250818

Comment 5 Peter Bergner 2013-07-26 16:41:15 UTC
Alan Modra mentioned in Comment #1 that configuring with --disable-werror will "fixed" these errors.  If that is not possible, then building with -O2 rather than -O3 should fix the issue as well, since GCC doesn't do aggressive inlining at -O2.

Comment 6 Karsten Hopp 2013-07-30 08:54:57 UTC
-O2 would be almost the same as using the normal ppc64p7 package. Do the -march/mtune flags make such a difference in this package that we need to keep the ppc64p7 optimized package and use --disable-werror ?

Comment 7 Peter Bergner 2013-07-31 18:58:09 UTC
Well, --disable-werror is the preferred solution.  Is there a reason we cannot build with that?  That will eliminate all these "false positives" errors as Alan said above.

Comment 8 IBM Bug Proxy 2013-08-07 13:40:57 UTC
Closing on this side.


Note You need to log in before you can comment on or make changes to this bug.