Bug 327641

Summary: in devel gcc-compat-34 fails to build a program which works OK in F7
Product: [Fedora] Fedora Reporter: manuel wolfshant <manuel.wolfshant>
Component: compat-gcc-34Assignee: Jakub Jelinek <jakub>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: nphilipp
Target Milestone: ---Keywords: Regression
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-10-15 07:40:57 UTC Type: ---
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
failed build log (devel, x86_64)
none
A small test case none

Description manuel wolfshant 2007-10-11 13:27:53 UTC 
Description of problem:
compilation of a file from the trickle package fails because gcc34 bails out with:

gcc34 -DHAVE_CONFIG_H -I. -I. -I.    -Wall -Icompat  -O2 -g -pipe -Wall
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -m64  -L/usr/lib64 -c trickled.c
trickled.c: In function `trickled_setup':
/usr/include/bits/string3.h:79: sorry, unimplemented: inlining failed in call to
'memset': recursive inlining
trickled.c:84: sorry, unimplemented: called from here

The same C source can be compiled OK with gcc-compat-34 included in F7.

Version-Release number of selected component (if applicable):
 compat-gcc-34           x86_64     3.4.6-7  

How reproducible:
always

Steps to Reproduce:
1. try to build http://wolfy.fedorapeople.org/trickle-1.07-1.fc7.src.rpm
2. watch it fail
  
Actual results:
build fails, as seen at
http://koji.fedoraproject.org/koji/getfile?taskID=191187&name=build.log

or in short:

+ /usr/bin/make
gcc34 -DHAVE_CONFIG_H -I. -I. -I.    -Wall -Icompat  -O2 -g -pipe -Wall
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -m64  -L/usr/lib64 -c trickle.c
gcc34 -DHAVE_CONFIG_H -I. -I. -I.    -Wall -Icompat  -O2 -g -pipe -Wall
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -m64  -L/usr/lib64 -c util.c
gcc34 -DHAVE_CONFIG_H -I. -I. -I.    -Wall -Icompat  -O2 -g -pipe -Wall
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -m64  -L/usr/lib64 -c getopt.c
gcc34 -DHAVE_CONFIG_H -I. -I. -I.    -Wall -Icompat  -O2 -g -pipe -Wall
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -m64  -L/usr/lib64 -c strlcat.c
gcc34 -DHAVE_CONFIG_H -I. -I. -I.    -Wall -Icompat  -O2 -g -pipe -Wall
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -m64  -L/usr/lib64 -c strlcpy.c
/bin/sh ./libtool --mode=link gcc34 -Wall -Icompat  -O2 -g -pipe -Wall
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -m64  -L/usr/lib64  -o trickle  trickle.o
util.o getopt.o strlcat.o strlcpy.o -lnsl  -ldl
mkdir .libs
gcc34 -Wall -Icompat -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-m64 -o trickle trickle.o util.o getopt.o strlcat.o strlcpy.o  -L/usr/lib64
-lnsl -ldl
gcc34 -DHAVE_CONFIG_H -I. -I. -I.    -Wall -Icompat  -O2 -g -pipe -Wall
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -m64  -L/usr/lib64 -c trickled.c
trickled.c: In function `trickled_setup':
/usr/include/bits/string3.h:79: sorry, unimplemented: inlining failed in call to
'memset': recursive inlining
trickled.c:84: sorry, unimplemented: called from here
make: *** [trickled.o] Error 1

Expected results:
program should build successfully, as seen at 
http://koji.fedoraproject.org/koji/taskinfo?taskID=191178

Additional info:
Comment 1 manuel wolfshant 2007-10-11 13:27:53 UTC 
Created attachment 224271 [details]
failed build log (devel, x86_64)
Comment 2 Nils Philippsen 2007-10-11 13:34:06 UTC 
Created attachment 224281 [details]
A small test case

Compile the attached testcase with the following command:

gcc34 -O2 -Wp,-D_FORTIFY_SOURCE=2 gcc34_memset.c -o gcc34_memset
Comment 3 Jakub Jelinek 2007-10-11 13:47:47 UTC 
Why do you use gcc34 to build the package?
Appart from buggy configure* which checks for in_addr_t in a wrong header
it compiles just fine.
Comment 4 Nils Philippsen 2007-10-11 15:11:27 UTC 
(In reply to comment #3)
> Why do you use gcc34 to build the package?
> Appart from buggy configure* which checks for in_addr_t in a wrong header
> it compiles just fine.

I've addressed that one already. Still, gcc34 doesn't like memset() if used with
the options mentioned in comment #2 -- either this should work or mentioned
somewhere with a big "don't do that", perhaps in the release notes?
Comment 5 manuel wolfshant 2007-10-11 18:11:31 UTC 
I am using gcc34 for the simple reason that it accepts the source file(s)
unmodified. And the resulting binary works as advertised.

Nils kindly provided a fix and I have also located an ugly hack which allow
usage of gcc4. However the problem I see here is gcc34 failing (under certain
circumstances) in F8 (but not in F7).
Comment 6 Jakub Jelinek 2007-10-15 07:40:57 UTC 
The extremely limited fortification support in gcc34 could only work with
macros (which were used in bits/string3.h and bits/stdio2.h, but no other
fortification headers), now that we use inlines everywhere it can't work at all.
I have turned off fortification support for gcc < 4.1 altogether, with a warning.
That said, except for qemu nothing in F8 should be compiled with the
compat compilers, so please don't even think of that as an alternative.