Created attachment 364276 [details] build log for tp_smapi-0.41 when i has to update app-laptop/tp_smapi-0.41 it could not update, giving an error that -mpreferred-stack-boundary should bigger I have updated make.conf and added to CFLAGS -mpreferred-stack-boundary=6 that solve the situation for tp_smapi, however, mesa did not build up with the new CFLAGS settings, so i has to revert make.conf in order to build mesa. Relevant line from the build log (for full log see attachment) ===== /var/tmp/portage/app-laptop/tp_smapi-0.41/work/tp_smapi-0.41/tp_smapi.c:1:0: error: -mpreferred-stack-boundary=3 is not between 4 and 12 /* ^ /var/tmp/portage/app-laptop/tp_smapi-0.41/work/tp_smapi-0.41/thinkpad_ec.c:1:0: error: -mpreferred-stack-boundary=3 is not between 4 and 12 ==== Following advice from http://forums.gentoo.org/viewtopic.php?p=7451612 I am reporting it as a bug.
You should probably set some sane CFLAGS. "Attempt to keep the stack boundary aligned to a 2 raised to num byte boundary" That means it should be a multiple of 2, so 3 is wrong.
CFLAGS in my /etc/portage/make.conf good for tp_smapi #CFLAGS="-march=core2 -mtune=generic -Os -pipe -msse3 -msse4 -mcx16 -msahf -mpopcnt -mpreferred-stack-boundary=6" good for everything else CFLAGS="-march=core2 -mtune=generic -Os -pipe -msse3 -msse4 -mcx16 -msahf -mpopcnt"
arch/x86/Makefile:61: KBUILD_CFLAGS += $(call cc-option,-mno-sse -mpreferred-stack-boundary=3)
I have the same error after upgrading to gcc-4.8.2. Everything works with gcc-4.7.3. So could be gcc bug.
Reassigning to gcc guys for some assistance. Here is what I *think* is happening: This build is hitting this piece of code: http://gcc.gnu.org/viewcvs/gcc/trunk/gcc/config/i386/i386.c?r1=188893&r2=188892&pathrev=188893 with a -msse past in to your use flags, the min boundary is set to 3. without any -msseN flags, the min boundary will be set to 4. If I use your cflags without any sse flags, I can compile. When I add one sse flag, I get the error. Bear in mind this is the first time I've ever looked into the gcc source.
Shouldn't kernel modules always be built with the same options that built the kernel?
Yeah, it does the right thing, but then the user CFLAGS screw things over. x86_64-pc-linux-gnu-gcc -Wp,-MD,/var/tmp/portage/app-laptop/tp_smapi-0.41/work/tp_smapi-0.41/.thinkpad_ec.o.d -nostdinc -isystem /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/include -I/usr/src/linux-3.12.8-gentoo/arch/x86/include -Iarch/x86/include/generated -I/usr/src/linux-3.12.8-gentoo/include -Iinclude -I/usr/src/linux-3.12.8-gentoo/arch/x86/include/uapi -Iarch/x86/include/generated/uapi -I/usr/src/linux-3.12.8-gentoo/include/uapi -Iinclude/generated/uapi -include /usr/src/linux-3.12.8-gentoo/include/linux/kconfig.h -I/var/tmp/portage/app-laptop/tp_smapi-0.41/work/tp_smapi-0.41 -D__KERNEL__ -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Wno-format-security -fno-delete-null-pointer-checks -O2 -m64 -mno-mmx -mno-sse -mpreferred-stack-boundary=3 -march=core2 -mno-red-zone -mcmodel=kernel -funit-at-a-time -maccumulate-outgoing-args -fstack-protector -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -DCONFIG_AS_CFI_SECTIONS=1 -DCONFIG_AS_FXSAVEQ=1 -DCONFIG_AS_AVX=1 -DCONFIG_AS_AVX2=1 -pipe -Wno-sign-compare -fno-asynchronous-unwind-tables -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx -Wno-unused-but-set-variable -fomit-frame-pointer -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow -fconserve-stack -DCC_HAVE_ASM_GOTO -march=core2 -mtune=generic -Os -pipe -msse3 -msse4 -mcx16 -msahf -mpopcnt -I/var/tmp/portage/app-laptop/tp_smapi-0.41/work/tp_smapi-0.41/include -DMODULE -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(thinkpad_ec)" -D"KBUILD_MODNAME=KBUILD_STR(thinkpad_ec)" -c -o /var/tmp/portage/app-laptop/tp_smapi-0.41/work/tp_smapi-0.41/thinkpad_ec.o /var/tmp/portage/app-laptop/tp_smapi-0.41/work/tp_smapi-0.41/thinkpad_ec.c A simple strip-flags would fix it.
Hmm, the summary is wrong given the build log; corrected and reassigned. At least under the assumption that stripping the flag is the way forward. It appears to be maintainer-needed though...
With the hints from this report and https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53383 I can confirm that the problem is the combination of 1) archtecture amd64 2) -mpreferred-stack-boundary=3 (originating from the Kernel Makefiles) 3) user CFLAGS containing -msse* (e.g. -msse4.1) I have committed -r1 using flag-o-matic to fix user CFLAGS on the fly. Please feel free to re-open as needed. # git show --stat | sed 's,@gentoo.org,@g.o,' commit b2ae67998fc017775a514b475022f4dc4c3466bc Author: Sebastian Pipping <sping@g.o> Date: Sun Dec 20 22:43:27 2015 +0100 app-laptop/tp_smapi: Fix compilation (bug #492964) Package-Manager: portage-2.2.26 app-laptop/tp_smapi/tp_smapi-0.41-r1.ebuild | 74 +++++++++++++++++++++++++++++ 1 file changed, 74 insertions(+)
Hi! It seems, that filtering to msse* is not enough. I've ran today into this problem with the newest -r1 ebuild. It failed, because I have also "-mssse3" set, which is not beeing filtered. That should be added. Could someone do this? -mssse3 ist not a typo. It's a valid CFLAG. Conrad
Fixed. # git show --stat | sed 's,@gentoo.org,@g.o,' commit 4a67438e5990e45b6cd37086a59720cbb9d142b8 Author: Sebastian Pipping <sping@g.o> Date: Wed Dec 23 16:37:18 2015 +0100 app-laptop/tp_smapi: Filter -mssse3 (bug #492964) Package-Manager: portage-2.2.26 app-laptop/tp_smapi/tp_smapi-0.41-r1.ebuild | 1 + 1 file changed, 1 insertion(+)
