Bug 12821 - gcc-2.96-21 unable to compile kernel 2.4.0-test1
gcc-2.96-21 unable to compile kernel 2.4.0-test1
Product: Red Hat Raw Hide
Classification: Retired
Component: gcc (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Depends On:
  Show dependency treegraph
Reported: 2000-06-22 16:40 EDT by Hardy Mayer
Modified: 2008-05-01 11:37 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2000-07-27 11:24:39 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Hardy Mayer 2000-06-22 16:40:35 EDT
I was testing the freshly installed gcc-2.96-21 on linux-2.4.0-test1. 
Here are the results:
1. gcc-2.96-21  issues a large number of warniongs which 2.95 does not. 
In file included from init/main.c:35:
/usr/src/linux/include/linux/pci.h:214:60: warning: trigraph ??) ignored
/usr/src/linux/include/linux/pci.h:215:61: warning: trigraph ??) ignored
/usr/src/linux/include/linux/pci.h:217:61: warning: trigraph ??) ignored
/usr/src/linux/include/linux/pci.h:218:62: warning: trigraph ??) ignored
/usr/src/linux/include/linux/pci.h:219:70: warning: trigraph ??) ignored
/usr/src/linux/include/linux/pci.h:220:37: warning: trigraph ??) ignored

gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2
-fomit-frame-pointer -fno-strict-aliasing -pipe 
-mpreferred-stack-boundary=2 -march=i686   -c -o aic7xxx.o aic7xxx.c
In file included from aic7xxx.c:239:
/usr/src/linux/include/linux/delay.h:19:44: warning: trigraph ??/ ignored
In file included from aic7xxx.c:241:
/usr/src/linux/include/linux/pci.h:214:60: warning: trigraph ??) ignored
/usr/src/linux/include/linux/pci.h:215:61: warning: trigraph ??) ignored
/usr/src/linux/include/linux/pci.h:217:61: warning: trigraph ??) ignored
/usr/src/linux/include/linux/pci.h:218:62: warning: trigraph ??) ignored
/usr/src/linux/include/linux/pci.h:219:70: warning: trigraph ??) ignored
/usr/src/linux/include/linux/pci.h:220:37: warning: trigraph ??) ignored
rm -f scsi.a
ar  rcs scsi.a   scsi_n_syms.o hosts.o scsi_ioctl.o constants.o scsicam.o
scsi_error.o scsi_obsolete.o scsi_queue.o scsi_lib.o  scsi_merge.o
scsi_proc.o scsi_dma.o scsi_scan.o st.o sd.o sr.o sr_ioctl.o sr_vendor.o
sg.o aic7xxx.o

This goes on until we reach the ld phase fro vmlinux; here:
make[1]: Leaving directory `/reserve/kernel/linux/arch/i386/lib'
ld -m elf_i386 -T /usr/src/linux/arch/i386/vmlinux.lds -e stext
arch/i386/kernel/head.o arch/i386/kernel/init_task.o init/main.o
init/version.o \
	--start-group \
	arch/i386/kernel/kernel.o arch/i386/mm/mm.o kernel/kernel.o mm/mm.o
fs/fs.o ipc/ipc.o \
	drivers/block/block.a drivers/char/char.o drivers/misc/misc.o
drivers/net/net.o drivers/parport/parport.a  drivers/ide/ide.a
drivers/scsi/scsi.a drivers/cdrom/cdrom.a drivers/pci/pci.a
drivers/video/video.o \
	net/network.a \
	/usr/src/linux/arch/i386/lib/lib.a /usr/src/linux/lib/lib.a
/usr/src/linux/arch/i386/lib/lib.a \
	--end-group \
	-o vmlinux
drivers/scsi/scsi.a(aic7xxx.o): In function `aic7xxx_load_seeprom':
aic7xxx.o(.text+0x11fee): undefined reference to `memcpy'
make: *** [vmlinux] Error 1

I reverted to gcc-2.95.2-7mdk and the kernel compiles (and works!)with just
a few trivial warnings of the kind 

{standard input}: Assembler messages:
{standard input}:779: Warning: indirect lcall without `*'
{standard input}:863: Warning: indirect lcall without `*'
{standard input}:950: Warning: indirect lcall without `*'
{standard input}:990: Warning: indirect lcall without `*'
Comment 1 Michael Tokarev 2000-07-11 08:08:23 EDT
This is a new "feature" introduced in 2.96 and should be corrected.
Compiler generates a call to memcpy for structure assignments,
even if it asked to inline actual memcpy calls.  2.95 and
earlier versions always use inline memcpy for such assignments,
and this was a right thing.
This is critical to kernel, since it does not use libc where memcpy
is defined, and shows on all kernels (not just 2.4, but 2.2 also).
2.96-33 also have this bug.
Comment 2 Jakub Jelinek 2000-07-24 19:39:40 EDT
This is actually a kernel bug, if should provide (and export) memcpy/memset
gcc can decide whether it is worth inlining the call or taking it out of line.
Comment 3 Michael Tokarev 2000-07-27 11:24:39 EDT
For structure assignments, it is always ok to inline
this operation, at least on x86.  Size of structure
is fixed; and generating call to memcpy is comparable
in speed/size (well, almost equal) to inline version.
Compiler should decide where to inline actual memcpy
calls, but not assignments.  Moreover, it should not
be required to export any function(s) when using some
compiler -- if it needs (and generates) them, it should
provide them itself.
In case with kernel where memcpy "always inlined" due
to it's definition (as a macro), it is really a kernel
bug -- real memcpy should not be inlined that "macro"
way.  And it should be possible for compiler to decide
if it is ok to inline it or not.
But, again, requiring presence of any symbol is a bug
in compiler.  Consider, for example, why some program
can be compiled by, say, IBM's C compiler but not by
gcc (with cause of missing memcpy as in the case). This
will be gcc bug, not a program bug.
Comment 4 Jakub Jelinek 2000-08-25 12:01:04 EDT
Note that you were compiling with -march=i686, and on PentiumPro the various
string instructions are slower then using movs. If you're copying too large
structure, it is really better to go out of line for cache trashing reasons.
Anyway, Linus accepted my patch to export memcpy/memset a couple of 2.4 tests ago.
Comment 5 Michael Tokarev 2000-08-27 05:02:47 EDT
Probably you are right, and there are cases where it is better to call external
routine instead of inlining assignments.  Seemed to be that gcc does smarter
then I can do ;)...  Ok, let's close this bug.  Thanks!

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