Skip to contentSkip to conversation

New: building SES support fails w/ gcc-3.4.5

Bug 11800 [email protected] 4 participants 14 messages Oct 21, 2008 – Oct 27, 2008 1 message not in the archive SCSI

lore
Share & tools
lore

[email protected]

author
#0 lore raw

http://bugzilla.kernel.org/show_bug.cgi?id=11800

Summary: building SES support fails w/ gcc-3.4.5
Product: SCSI Drivers
Version: 2.5
KernelVersion: 2.6.27.1
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Other
AssignedTo: [email protected]
ReportedBy: [email protected]

[beej@dell ~]$ cat /etc/redhat-release CentOS release 4.3 (Final)
[beej@dell ~]$ rpm -qf which gcc gcc-3.4.5-2
[beej@dell linux-2.6.27.1]$ diff .config .config.old 4c4
< # Tue Oct 21 14:07:00 2008
---

Quoted 1 line

# Thu Oct 16 17:54:42 2008

1006c1006
< # CONFIG_SCSI_ENCLOSURE is not set
---

Quoted 1 line

CONFIG_SCSI_ENCLOSURE=m

using .config.old,
[beej@dell linux-2.6.27.1]$ make
<snip>
Kernel: arch/x86/boot/bzImage is ready (#2)
Building modules, stage 2.
MODPOST 668 modules
ERROR: "__you_cannot_kmalloc_that_much" [drivers/scsi/ses.ko] undefined! make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2

Signature · 3 lines
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
#1 lore raw

(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface).

Quoted 31 lines · On Tue, 21 Oct 2008 11:36:12 -0700 (PDT) [email protected] wrote:

http://bugzilla.kernel.org/show_bug.cgi?id=11800

Summary: building SES support fails w/ gcc-3.4.5
Product: SCSI Drivers
Version: 2.5
KernelVersion: 2.6.27.1
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Other
AssignedTo: [email protected]
ReportedBy: [email protected]

[beej@dell ~]$ cat /etc/redhat-release CentOS release 4.3 (Final)
[beej@dell ~]$ rpm -qf which gcc gcc-3.4.5-2
[beej@dell linux-2.6.27.1]$ diff .config .config.old 4c4
< # Tue Oct 21 14:07:00 2008
---

Quoted 1 line

# Thu Oct 16 17:54:42 2008

1006c1006
< # CONFIG_SCSI_ENCLOSURE is not set
---

Quoted 1 line

CONFIG_SCSI_ENCLOSURE=m

Quoted 10 lines

using .config.old,
[beej@dell linux-2.6.27.1]$ make
<snip>
Kernel: arch/x86/boot/bzImage is ready (#2)
Building modules, stage 2.
MODPOST 668 modules
ERROR: "__you_cannot_kmalloc_that_much" [drivers/scsi/ses.ko] undefined! make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2

That's weird. It means that we did a kmalloc(N, ...) where the value of N is known at compile time, and N is too large.

But I can find no such kmalloc/kzalloc calls in ses.c. It might be gcc bustage - we've seen that before.

Please do

make drivers/scsi/ses.s

then have a look in drivers/scsi/ses.s and see which function is emitting a call to __you_cannot_kmalloc_that_much. Or email me drivers/scsi/ses.s and I'll take a look.

Thanks.

author
#8 lore raw

[Bug 11800] building SES support fails w/ gcc-3.4.5

In reply to [email protected]

http://bugzilla.kernel.org/show_bug.cgi?id=11800

------- Comment #1 from [email protected] 2008-10-21 15:52 -------
Reply-To: [email protected]

(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface).

Quoted 31 lines · On Tue, 21 Oct 2008 11:36:12 -0700 (PDT) [email protected] wrote:

http://bugzilla.kernel.org/show_bug.cgi?id=11800

Summary: building SES support fails w/ gcc-3.4.5
Product: SCSI Drivers
Version: 2.5
KernelVersion: 2.6.27.1
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Other
AssignedTo: [email protected]
ReportedBy: [email protected]

[beej@dell ~]$ cat /etc/redhat-release CentOS release 4.3 (Final)
[beej@dell ~]$ rpm -qf which gcc gcc-3.4.5-2
[beej@dell linux-2.6.27.1]$ diff .config .config.old 4c4
< # Tue Oct 21 14:07:00 2008
---

Quoted 1 line

# Thu Oct 16 17:54:42 2008

1006c1006
< # CONFIG_SCSI_ENCLOSURE is not set
---

Quoted 1 line

CONFIG_SCSI_ENCLOSURE=m

Quoted 10 lines

using .config.old,
[beej@dell linux-2.6.27.1]$ make
<snip>
Kernel: arch/x86/boot/bzImage is ready (#2)
Building modules, stage 2.
MODPOST 668 modules
ERROR: "__you_cannot_kmalloc_that_much" [drivers/scsi/ses.ko] undefined! make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2

That's weird. It means that we did a kmalloc(N, ...) where the value of N is known at compile time, and N is too large.

But I can find no such kmalloc/kzalloc calls in ses.c. It might be gcc bustage - we've seen that before.

Please do

make drivers/scsi/ses.s

then have a look in drivers/scsi/ses.s and see which function is emitting a call to __you_cannot_kmalloc_that_much. Or email me drivers/scsi/ses.s and I'll take a look.

Thanks.

Signature · 3 lines
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
author
#9 lore raw

[Bug 11800] building SES support fails w/ gcc-3.4.5

In reply to [email protected]

http://bugzilla.kernel.org/show_bug.cgi?id=11800

------- Comment #2 from [email protected] 2008-10-22 12:43 -------
Reply-To: [email protected]

Quoted 51 lines · Andrew Morton
Quoted 31 lines · On Tue, 21 Oct 2008 11:36:12 -0700 (PDT) [email protected] wrote:

http://bugzilla.kernel.org/show_bug.cgi?id=11800

Summary: building SES support fails w/ gcc-3.4.5
Product: SCSI Drivers
Version: 2.5
KernelVersion: 2.6.27.1
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Other
AssignedTo: [email protected]
ReportedBy: [email protected]

[beej@dell ~]$ cat /etc/redhat-release CentOS release 4.3 (Final)
[beej@dell ~]$ rpm -qf which gcc gcc-3.4.5-2
[beej@dell linux-2.6.27.1]$ diff .config .config.old 4c4
< # Tue Oct 21 14:07:00 2008
---

Quoted 1 line

# Thu Oct 16 17:54:42 2008

1006c1006
< # CONFIG_SCSI_ENCLOSURE is not set
---

Quoted 1 line

CONFIG_SCSI_ENCLOSURE=m

Quoted 10 lines

using .config.old,
[beej@dell linux-2.6.27.1]$ make
<snip>
Kernel: arch/x86/boot/bzImage is ready (#2)
Building modules, stage 2.
MODPOST 668 modules
ERROR: "__you_cannot_kmalloc_that_much" [drivers/scsi/ses.ko] undefined! make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2

That's weird. It means that we did a kmalloc(N, ...) where the value of N is known at compile time, and N is too large.

But I can find no such kmalloc/kzalloc calls in ses.c. It might be gcc bustage - we've seen that before.

Quoted 7 lines

Please do

make drivers/scsi/ses.s

then have a look in drivers/scsi/ses.s and see which function is emitting a call to __you_cannot_kmalloc_that_much. Or email me drivers/scsi/ses.s and I'll take a look.

attached

marc

Signature · 3 lines
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
#3 lore raw
In reply to a message not in the archive
Quoted 54 lines · On Wed, 22 Oct 2008 15:43:05 -0400 Marc Bejarano <[email protected]> wrote:
Quoted 53 lines · Andrew Morton
Quoted 31 lines · On Tue, 21 Oct 2008 11:36:12 -0700 (PDT) [email protected] wrote:

http://bugzilla.kernel.org/show_bug.cgi?id=11800

Summary: building SES support fails w/ gcc-3.4.5
Product: SCSI Drivers
Version: 2.5
KernelVersion: 2.6.27.1
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Other
AssignedTo: [email protected]
ReportedBy: [email protected]

[beej@dell ~]$ cat /etc/redhat-release CentOS release 4.3 (Final)
[beej@dell ~]$ rpm -qf which gcc gcc-3.4.5-2
[beej@dell linux-2.6.27.1]$ diff .config .config.old 4c4
< # Tue Oct 21 14:07:00 2008
---

Quoted 1 line

# Thu Oct 16 17:54:42 2008

1006c1006
< # CONFIG_SCSI_ENCLOSURE is not set
---

Quoted 1 line

CONFIG_SCSI_ENCLOSURE=m

Quoted 10 lines

using .config.old,
[beej@dell linux-2.6.27.1]$ make
<snip>
Kernel: arch/x86/boot/bzImage is ready (#2)
Building modules, stage 2.
MODPOST 668 modules
ERROR: "__you_cannot_kmalloc_that_much" [drivers/scsi/ses.ko] undefined! make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2

That's weird. It means that we did a kmalloc(N, ...) where the value of N is known at compile time, and N is too large.

But I can find no such kmalloc/kzalloc calls in ses.c. It might be gcc bustage - we've seen that before.

Please do

Quoted 8 lines
Quoted 5 lines

make drivers/scsi/ses.s

then have a look in drivers/scsi/ses.s and see which function is emitting a call to __you_cannot_kmalloc_that_much. Or email me drivers/scsi/ses.s and I'll take a look.

attached

OK, it's here:

	buf = kmalloc(vpd_len, GFP_KERNEL);

it's a gcc bug.

Please see if you can find some way to make it go away - perhaps change vpd_len's type to `int', things like that.

Or use a different compiler version :(

author
#10 lore raw

[Bug 11800] building SES support fails w/ gcc-3.4.5

In reply to [email protected]

http://bugzilla.kernel.org/show_bug.cgi?id=11800

------- Comment #3 from [email protected] 2008-10-22 13:31 -------
Reply-To: [email protected]

Quoted 54 lines · On Wed, 22 Oct 2008 15:43:05 -0400 Marc Bejarano <[email protected]> wrote:
Quoted 53 lines · Andrew Morton
Quoted 31 lines · On Tue, 21 Oct 2008 11:36:12 -0700 (PDT) [email protected] wrote:

http://bugzilla.kernel.org/show_bug.cgi?id=11800

Summary: building SES support fails w/ gcc-3.4.5
Product: SCSI Drivers
Version: 2.5
KernelVersion: 2.6.27.1
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Other
AssignedTo: [email protected]
ReportedBy: [email protected]

[beej@dell ~]$ cat /etc/redhat-release CentOS release 4.3 (Final)
[beej@dell ~]$ rpm -qf which gcc gcc-3.4.5-2
[beej@dell linux-2.6.27.1]$ diff .config .config.old 4c4
< # Tue Oct 21 14:07:00 2008
---

Quoted 1 line

# Thu Oct 16 17:54:42 2008

1006c1006
< # CONFIG_SCSI_ENCLOSURE is not set
---

Quoted 1 line

CONFIG_SCSI_ENCLOSURE=m

Quoted 10 lines

using .config.old,
[beej@dell linux-2.6.27.1]$ make
<snip>
Kernel: arch/x86/boot/bzImage is ready (#2)
Building modules, stage 2.
MODPOST 668 modules
ERROR: "__you_cannot_kmalloc_that_much" [drivers/scsi/ses.ko] undefined! make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2

That's weird. It means that we did a kmalloc(N, ...) where the value of N is known at compile time, and N is too large.

But I can find no such kmalloc/kzalloc calls in ses.c. It might be gcc bustage - we've seen that before.

Please do

Quoted 8 lines
Quoted 5 lines

make drivers/scsi/ses.s

then have a look in drivers/scsi/ses.s and see which function is emitting a call to __you_cannot_kmalloc_that_much. Or email me drivers/scsi/ses.s and I'll take a look.

attached

OK, it's here:

        buf = kmalloc(vpd_len, GFP_KERNEL);

it's a gcc bug.

Please see if you can find some way to make it go away - perhaps change vpd_len's type to `int', things like that.

Or use a different compiler version :(

Signature · 3 lines
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
maintainer
#4 lore raw
In reply to Andrew Morton
Quoted 10 lines · Andrew Morton

OK, it's here:

	buf = kmalloc(vpd_len, GFP_KERNEL);

it's a gcc bug.

Please see if you can find some way to make it go away - perhaps change vpd_len's type to `int', things like that.

Or use a different compiler version :(

Could it be an optimisation issue? The static oversize test relies on the compiler optimising away a leg that can never be reached if the size is under the max. If you do a make V=1 you'll see what optimisation flags the compiler is using ... if it's -O2 then yes, the compiler should be optimising stuff away and it's a clear compiler problem. If it's anything else, we might have a mis setting of the optimisation level in the kernel build.

James

author
#11 lore raw

[Bug 11800] building SES support fails w/ gcc-3.4.5

In reply to [email protected]

http://bugzilla.kernel.org/show_bug.cgi?id=11800

------- Comment #4 from [email protected] 2008-10-22 14:17 -------
Reply-To: [email protected]

Quoted 10 lines · Andrew Morton

OK, it's here:

	buf = kmalloc(vpd_len, GFP_KERNEL);

it's a gcc bug.

Please see if you can find some way to make it go away - perhaps change vpd_len's type to `int', things like that.

Or use a different compiler version :(

Could it be an optimisation issue? The static oversize test relies on the compiler optimising away a leg that can never be reached if the size is under the max. If you do a make V=1 you'll see what optimisation flags the compiler is using ... if it's -O2 then yes, the compiler should be optimising stuff away and it's a clear compiler problem. If it's anything else, we might have a mis setting of the optimisation level in the kernel build.

James

Signature · 3 lines
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
#5 lore raw
In reply to James Bottomley
Quoted 11 lines · James Bottomley
Quoted 10 lines · Andrew Morton

OK, it's here:

	buf = kmalloc(vpd_len, GFP_KERNEL);

it's a gcc bug.

Please see if you can find some way to make it go away - perhaps change vpd_len's type to `int', things like that.

Or use a different compiler version :(

i'm not worried about compiling this. i already did a compilation without it and i'll be fine without SES. i just selected it on the off chance i'd find time to play with it. i was just doing my duty of reporting this to save others the trouble.

Quoted 7 lines

Could it be an optimisation issue? The static oversize test relies on the compiler optimising away a leg that can never be reached if the size is under the max. If you do a make V=1 you'll see what optimisation flags the compiler is using ... if it's -O2 then yes, the compiler should be optimising stuff away and it's a clear compiler problem. If it's anything else, we might have a mis setting of the optimisation level in the kernel build.

looks to me like -Os:
---
beej@dell linux-2.6.27.1]$ make V=1 drivers/scsi/ses.s
rm -f include/config/kernel.release
echo 2.6.27.1 > include/config/kernel.release
set -e; :; mkdir -p include/linux/; (echo \#define LINUX_VERSION_CODE 132635; echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))';) < /usr/local/src/kernel/linux-2.6.27.1/Makefile > include/linux/version.h.tmp; if [ -r include/linux/version.h ] && cmp -s include/linux/version.h include/linux/version.h.tmp; then rm -f include/linux/version.h.tmp; else :; mv -f include/linux/version.h.tmp include/linux/version.h; fi
set -e; :; mkdir -p include/linux/; if [ echo -n "2.6.27.1" | wc -c -gt 64 ]; then echo '"2.6.27.1" exceeds 64 characters' >&2; exit 1; fi; (echo \#define UTS_RELEASE \"2.6.27.1\";) < include/config/kernel.release > include/linux/utsrelease.h.tmp; if [ -r include/linux/utsrelease.h ] && cmp -s include/linux/utsrelease.h include/linux/utsrelease.h.tmp; then rm -f include/linux/utsrelease.h.tmp; else :; mv -f include/linux/utsrelease.h.tmp include/linux/utsrelease.h; fi
set -e; if [ -L include/asm ]; then asmlink=readlink include/asm | cut -d '-' -f 2; if [ "$asmlink" != "x86" ]; then echo "ERROR: the symlink include/asm points to asm-$asmlink but asm-x86 was expected"; echo " set ARCH or save .config and run 'make mrproper' to fix it"; exit 1; fi; fi
if [ ! -L include/asm ]; then echo ' SYMLINK include/asm -> include/asm-x86'; if [ ! -d include/asm-x86 ]; then mkdir -p include/asm-x86; fi; ln -fsn asm-x86 include/asm; fi
mkdir -p .tmp_versions
make -f scripts/Makefile.build obj=scripts/basic
make -f scripts/Makefile.build obj=.
mkdir -p kernel/
mkdir -p arch/x86/kernel/
make -f scripts/Makefile.build obj=. missing-syscalls
/bin/sh scripts/checksyscalls.sh gcc
-Wp,-MD,./.missing-syscalls.d -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/3.4.5/include -D__KERNEL__ -Iinclude -I/usr/local/src/kernel/linux-2.6.27.1/arch/x86/include -include include/linux/autoconf.h -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Os -m64 -mno-red-zone -mcmodel=kernel -funit-at-a-time -maccumulate-outgoing-args -DCONFIG_AS_CFI=1 -pipe -Wno-sign-compare -fno-asynchronous-unwind-tables -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -Iinclude/asm-x86/mach-default -fomit-frame-pointer -g -Wdeclaration-after-statement -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(missing_syscalls)" -D"KBUILD_MODNAME=KBUILD_STR(missing_syscalls)" make -f scripts/Makefile.build obj=scripts
make -f scripts/Makefile.build obj=scripts/genksyms
make -f scripts/Makefile.build obj=scripts/mod
make -f scripts/Makefile.build obj=drivers/scsi drivers/scsi/ses.s
gcc -Wp,-MD,drivers/scsi/.ses.s.d -nostdinc -isystem
/usr/lib/gcc/x86_64-redhat-linux/3.4.5/include -D__KERNEL__ -Iinclude -I/usr/local/src/kernel/linux-2.6.27.1/arch/x86/include -include include/linux/autoconf.h -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Os -m64 -mno-red-zone -mcmodel=kernel -funit-at-a-time -maccumulate-outgoing-args -DCONFIG_AS_CFI=1 -pipe -Wno-sign-compare -fno-asynchronous-unwind-tables -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -Iinclude/asm-x86/mach-default -fomit-frame-pointer -g -Wdeclaration-after-statement -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(ses)" -D"KBUILD_MODNAME=KBUILD_STR(ses)" -fverbose-asm -S -o drivers/scsi/ses.s drivers/scsi/ses.c
---

i'm happy to run any other easy-to-do tests in case you don't have access to a CentOS 4 box, but it should be easy to repro for anybody else that does.

cheers,
marc

author
#12 lore raw

[Bug 11800] building SES support fails w/ gcc-3.4.5

In reply to [email protected]

http://bugzilla.kernel.org/show_bug.cgi?id=11800

------- Comment #5 from [email protected] 2008-10-23 09:15 -------
Reply-To: [email protected]

Quoted 11 lines · James Bottomley
Quoted 10 lines · Andrew Morton

OK, it's here:

    buf = kmalloc(vpd_len, GFP_KERNEL);

it's a gcc bug.

Please see if you can find some way to make it go away - perhaps change vpd_len's type to `int', things like that.

Or use a different compiler version :(

i'm not worried about compiling this. i already did a compilation without it and i'll be fine without SES. i just selected it on the off chance i'd find time to play with it. i was just doing my duty of reporting this to save others the trouble.

Quoted 7 lines

Could it be an optimisation issue? The static oversize test relies on the compiler optimising away a leg that can never be reached if the size is under the max. If you do a make V=1 you'll see what optimisation flags the compiler is using ... if it's -O2 then yes, the compiler should be optimising stuff away and it's a clear compiler problem. If it's anything else, we might have a mis setting of the optimisation level in the kernel build.

looks to me like -Os:
---
beej@dell linux-2.6.27.1]$ make V=1 drivers/scsi/ses.s
rm -f include/config/kernel.release
echo 2.6.27.1 > include/config/kernel.release
set -e; :; mkdir -p include/linux/; (echo \#define
LINUX_VERSION_CODE 132635; echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))';) < /usr/local/src/kernel/linux-2.6.27.1/Makefile > include/linux/version.h.tmp; if [ -r include/linux/version.h ] && cmp -s include/linux/version.h include/linux/version.h.tmp; then rm -f include/linux/version.h.tmp; else :; mv -f include/linux/version.h.tmp include/linux/version.h; fi
set -e; :; mkdir -p include/linux/; if [ `echo -n "2.6.27.1" | wc -c
` -gt 64 ]; then echo '"2.6.27.1" exceeds 64 characters' >&2; exit 1; fi; (echo \#define UTS_RELEASE \"2.6.27.1\";) < include/config/kernel.release > include/linux/utsrelease.h.tmp; if [ -r include/linux/utsrelease.h ] && cmp -s include/linux/utsrelease.h include/linux/utsrelease.h.tmp; then rm -f include/linux/utsrelease.h.tmp; else :; mv -f include/linux/utsrelease.h.tmp include/linux/utsrelease.h; fi set -e; if [ -L include/asm ]; then asmlink=readlink include/asm | cut -d '-' -f 2; if [ "$asmlink" != "x86" ]; then echo "ERROR: the symlink include/asm points to asm-$asmlink but asm-x86 was expected";
echo " set ARCH or save .config and run 'make mrproper' to fix
it"; exit 1; fi; fi
if [ ! -L include/asm ]; then echo ' SYMLINK include/asm -> include/asm-x86'; if [ ! -d include/asm-x86 ]; then mkdir -p include/asm-x86; fi; ln -fsn asm-x86 include/asm; fi
mkdir -p .tmp_versions
make -f scripts/Makefile.build obj=scripts/basic
make -f scripts/Makefile.build obj=.
mkdir -p kernel/
mkdir -p arch/x86/kernel/
make -f scripts/Makefile.build obj=. missing-syscalls
/bin/sh scripts/checksyscalls.sh gcc
-Wp,-MD,./.missing-syscalls.d -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/3.4.5/include -D__KERNEL__ -Iinclude -I/usr/local/src/kernel/linux-2.6.27.1/arch/x86/include -include include/linux/autoconf.h -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Os -m64 -mno-red-zone -mcmodel=kernel -funit-at-a-time -maccumulate-outgoing-args -DCONFIG_AS_CFI=1 -pipe -Wno-sign-compare -fno-asynchronous-unwind-tables -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -Iinclude/asm-x86/mach-default -fomit-frame-pointer -g -Wdeclaration-after-statement -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(missing_syscalls)" -D"KBUILD_MODNAME=KBUILD_STR(missing_syscalls)"
make -f scripts/Makefile.build obj=scripts
make -f scripts/Makefile.build obj=scripts/genksyms
make -f scripts/Makefile.build obj=scripts/mod
make -f scripts/Makefile.build obj=drivers/scsi drivers/scsi/ses.s
gcc -Wp,-MD,drivers/scsi/.ses.s.d -nostdinc -isystem
/usr/lib/gcc/x86_64-redhat-linux/3.4.5/include -D__KERNEL__ -Iinclude -I/usr/local/src/kernel/linux-2.6.27.1/arch/x86/include -include include/linux/autoconf.h -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Os -m64 -mno-red-zone -mcmodel=kernel -funit-at-a-time -maccumulate-outgoing-args -DCONFIG_AS_CFI=1 -pipe -Wno-sign-compare -fno-asynchronous-unwind-tables -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -Iinclude/asm-x86/mach-default -fomit-frame-pointer -g -Wdeclaration-after-statement -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(ses)" -D"KBUILD_MODNAME=KBUILD_STR(ses)" -fverbose-asm -S -o drivers/scsi/ses.s drivers/scsi/ses.c
---

i'm happy to run any other easy-to-do tests in case you don't have access to a CentOS 4 box, but it should be easy to repro for anybody else that does.

cheers,
marc

Signature · 3 lines
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
maintainer
#6 lore raw
In reply to Marc Bejarano
Quoted 26 lines · Marc Bejarano
Quoted 11 lines · James Bottomley
Quoted 10 lines · Andrew Morton

OK, it's here:

	buf = kmalloc(vpd_len, GFP_KERNEL);

it's a gcc bug.

Please see if you can find some way to make it go away - perhaps change vpd_len's type to `int', things like that.

Or use a different compiler version :(

i'm not worried about compiling this. i already did a compilation without it and i'll be fine without SES. i just selected it on the off chance i'd find time to play with it. i was just doing my duty of reporting this to save others the trouble.

Quoted 7 lines

Could it be an optimisation issue? The static oversize test relies on the compiler optimising away a leg that can never be reached if the size is under the max. If you do a make V=1 you'll see what optimisation flags the compiler is using ... if it's -O2 then yes, the compiler should be optimising stuff away and it's a clear compiler problem. If it's anything else, we might have a mis setting of the optimisation level in the kernel build.

Quoted 1 line

looks to me like -Os:

I think we have a winner: -Os is rather less well implemented in older versions of gcc. Could you retry with -O2?

You do this by setting the config option

CONFIG_CC_OPTIMIZE_FOR_SIZE

to N (it defaults to Y). If we verify this to be the root cause, we might consider making the default for that option N if gcc version is < 4.

James

author
#13 lore raw

[Bug 11800] building SES support fails w/ gcc-3.4.5

In reply to [email protected]

http://bugzilla.kernel.org/show_bug.cgi?id=11800

------- Comment #6 from [email protected] 2008-10-23 09:35 -------
Reply-To: [email protected]

Quoted 26 lines · Marc Bejarano
Quoted 11 lines · James Bottomley
Quoted 10 lines · Andrew Morton

OK, it's here:

	buf = kmalloc(vpd_len, GFP_KERNEL);

it's a gcc bug.

Please see if you can find some way to make it go away - perhaps change vpd_len's type to `int', things like that.

Or use a different compiler version :(

i'm not worried about compiling this. i already did a compilation without it and i'll be fine without SES. i just selected it on the off chance i'd find time to play with it. i was just doing my duty of reporting this to save others the trouble.

Quoted 7 lines

Could it be an optimisation issue? The static oversize test relies on the compiler optimising away a leg that can never be reached if the size is under the max. If you do a make V=1 you'll see what optimisation flags the compiler is using ... if it's -O2 then yes, the compiler should be optimising stuff away and it's a clear compiler problem. If it's anything else, we might have a mis setting of the optimisation level in the kernel build.

Quoted 1 line

looks to me like -Os:

I think we have a winner: -Os is rather less well implemented in older versions of gcc. Could you retry with -O2?

You do this by setting the config option

CONFIG_CC_OPTIMIZE_FOR_SIZE

to N (it defaults to Y). If we verify this to be the root cause, we might consider making the default for that option N if gcc version is < 4.

James

Signature · 3 lines
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
#7 lore raw
In reply to James Bottomley
Quoted 27 lines · James Bottomley
Quoted 26 lines · Marc Bejarano
Quoted 11 lines · James Bottomley
Quoted 10 lines · Andrew Morton

OK, it's here:

	buf = kmalloc(vpd_len, GFP_KERNEL);

it's a gcc bug.

Please see if you can find some way to make it go away - perhaps change vpd_len's type to `int', things like that.

Or use a different compiler version :(

i'm not worried about compiling this. i already did a compilation without it and i'll be fine without SES. i just selected it on the off chance i'd find time to play with it. i was just doing my duty of reporting this to save others the trouble.

Quoted 7 lines

Could it be an optimisation issue? The static oversize test relies on the compiler optimising away a leg that can never be reached if the size is under the max. If you do a make V=1 you'll see what optimisation flags the compiler is using ... if it's -O2 then yes, the compiler should be optimising stuff away and it's a clear compiler problem. If it's anything else, we might have a mis setting of the optimisation level in the kernel build.

Quoted 8 lines
Quoted 1 line

looks to me like -Os:

I think we have a winner: -Os is rather less well implemented in older versions of gcc. Could you retry with -O2?

You do this by setting the config option

CONFIG_CC_OPTIMIZE_FOR_SIZE

verified.

setting CONFIG_CC_OPTIMIZE_FOR_SIZE=n in .config does allow ses.c to be compiled by gcc 3.4.5 from the CentOS 4 gcc-3.4.5-2 RPM.

Quoted 3 lines

If we verify this to be the root cause, we
might consider making the default for that option N if gcc version is < 4.

marc

author
#14 lore raw

[Bug 11800] building SES support fails w/ gcc-3.4.5

In reply to [email protected]

http://bugzilla.kernel.org/show_bug.cgi?id=11800

------- Comment #7 from [email protected] 2008-10-27 10:48 -------
Reply-To: [email protected]

Quoted 27 lines · James Bottomley
Quoted 26 lines · Marc Bejarano
Quoted 11 lines · James Bottomley
Quoted 10 lines · Andrew Morton

OK, it's here:

        buf = kmalloc(vpd_len, GFP_KERNEL);

it's a gcc bug.

Please see if you can find some way to make it go away - perhaps change vpd_len's type to `int', things like that.

Or use a different compiler version :(

i'm not worried about compiling this. i already did a compilation without it and i'll be fine without SES. i just selected it on the off chance i'd find time to play with it. i was just doing my duty of reporting this to save others the trouble.

Quoted 7 lines

Could it be an optimisation issue? The static oversize test relies on the compiler optimising away a leg that can never be reached if the size is under the max. If you do a make V=1 you'll see what optimisation flags the compiler is using ... if it's -O2 then yes, the compiler should be optimising stuff away and it's a clear compiler problem. If it's anything else, we might have a mis setting of the optimisation level in the kernel build.

Quoted 8 lines
Quoted 1 line

looks to me like -Os:

I think we have a winner: -Os is rather less well implemented in older versions of gcc. Could you retry with -O2?

You do this by setting the config option

CONFIG_CC_OPTIMIZE_FOR_SIZE

verified.

setting CONFIG_CC_OPTIMIZE_FOR_SIZE=n in .config does allow ses.c to be compiled by gcc 3.4.5 from the CentOS 4 gcc-3.4.5-2 RPM.

Quoted 3 lines

If we verify this to be the root cause, we
might consider making the default for that option N if gcc version is < 4.

marc

Signature · 3 lines
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.