FS#24359 - [gcc 4.6.0-5] [-Wunused-but-set-variable]
Attached to Project:
Arch Linux
Opened by synflag (synflag) - Friday, 20 May 2011, 11:44 GMT
Last edited by Allan McRae (Allan) - Saturday, 21 May 2011, 02:12 GMT
Opened by synflag (synflag) - Friday, 20 May 2011, 11:44 GMT
Last edited by Allan McRae (Allan) - Saturday, 21 May 2011, 02:12 GMT
|
Details
Prologue:
Andreas Radke Wrote: "closing: The kernel does compile with our safe preset flags in makepkg.conf. Using custom flags is your fun (probably has to be fixed in the kernel code)." NOTE FOR ANDREAS RADKE: 1) I did not add extra flags to kernel compilation, i take .config file of ARCH kernel and only removed unnecesary features, for example: I use AMD, so I'd remove "Intel Speed step", i do not have WiFi, so I'd remove "wireless support", ok? is _now_ clear enough for you? 2) In Fedora, Slackware, Gentoo, Debian, X-Men-Linux the kernel respete a standard, in archlinux also used to do it until GCC 4.5.2, steps: cp /usr/src/linux-2.6.38-ARCH/.config /usr/src/linux-2.6.38.6/.config cd /usr/src/linux-2.6.38.6/ make menuconfig (remove a lot of unnecesary modules) make -jX (X== number of cores + 1) make modules_install make install mkinitcpio -k 2.6.38.6 -c /etc/mkinitcpio.conf -g /boot/vmlinuz-2.6.38.6.img mv /boot/vmlinuz /boot/vmlinuz-2.6.38.6 Add all in new line in /boot/grub/menu.lst and reboot It is standard in all distros, is into README of kernel and works fine with GCC 4.5.2 in all arch. Clearly my "fun", as you call it, is not a reason for closing the bug at any case you could ask me to report it to upstream, do not ignore the bug please, a lot of users that use custom kernel and software are affected. The /etc/makepkg.conf is not used in this procedure, i do not use PKGBUILD (for kernel compilation), a kernel is source code, is not necesary to package it. The description show cleary the bug in gcc, and is reported in Debian sid, unstable, if ArchLinux use the equivalent to Debian sid packages, ok, is no my problem, but i see necessary to report the bug, do you get me?. Sorry by the """rude""" mode, but i'm not used to receive such obvious answers and less without waiting a feedback from me before that; i like to report bugs cause i like to help to improve things, if i'm being annoying, then just say it and i will take a desicion. Description: content of test.c: #include <stdio.h> int main(void) { int x; x = printf("hello, world\n"); return 0; } ------------------------------------------------------------- LANG=C gcc -Wall -Werror test.c; echo $? test.c: In function 'main': test.c:5:13: error: variable 'x' set but not used [-Werror=unused-but-set-variable] cc1: all warnings being treated as errors 1 ------------------------------------------------------------------ LANG=C gcc -Wunused-but-set-variable -Werror test.c; echo $? test.c: In function 'main': test.c:5:13: error: variable 'x' set but not used [-Werror=unused-but-set-variable] cc1: all warnings being treated as errors 1 ---------------------------------------------------------------------- LANG=C gcc -Werror=unused-but-set-variable test.c; echo $? test.c: In function 'main': test.c:5:13: error: variable 'x' set but not used [-Werror=unused-but-set-variable] cc1: some warnings being treated as errors 1 ----------------------------------------------------------------------- In fact, i reproduce the same bug that Debian report in Sid, in Arch 32 and 64 bits, so, GCC is buggy, is not only the kernel, the kernel is just the proof of what those bugs produce in a code of thousands of lines. I did observe that you apply a patch to kernel source code before compiling it. See the link and the comments on it, read please: http://lists.debian.org/debian-gcc/2011/02/msg00107.html Thanks to jelle van der waa for the tip, is helpful ;) (LANG=C) Regards |
This task depends upon
1.- that is true but i don't know how to ask for the bug to be reopened
2.- totally agree with you, I find it funny and even ignorant of the reason for the closure, it is clear the bug and the explanation, and that had nothing to do with the way I use to compile with the bug, but the compilation failed was the product of bug I do not use patches and never necessary, even I could build 4.6.0-4, had warnings but compiled perfectly, even changing the flag, and suddenly without changing anything and use the Arch configuration does not compile on any architecture, or it does it wrong and the resulting binary is useless.
3.- Yes, i'm not a coder but i can recognize the obvious variable and it is no related with any warning.
So what "bug" in GCC are you reporting?
GCC emits a warning when you don't use a variable (just setting it doesn't count as using); with -Werror, all warnings are fatal so compilation aborts - this behavior is completely normal to me.
With 4.5.2 version of gcc is normal "variable is declared but not used" while is make executed, in 4.6.0-5 the message is -Wunused-but-set-variable a _lot_ of times, finish in defected binary or never produce bzImage or modules.dep is ausent, or modules corrupted. Then, all code of linux kernel is bad?, why using 4.5.2 compile fine and work fine without errors during days, uptimes of 10, 15 or more days.
I have this same issue compiling kernels http://comments.gmane.org/gmane.comp.emulators.qemu/100631 (not exactly fpu bug but 4.6 not compile)
The point is, you build stuff with "-Werror" and it raises an error when you have unused variable; that is expected. (GCC-4.6 probably just became stricter in the way it handles/detects unused variables.)
Just do not compile with "-Werror".
Gaetan, i'm not happy with the stock kernel, if i want to use all system by default i would use Ubuntu. The advantage of ArchLinux is it's phylosophy KISS and flexibility (custom kernel, packages, AUR as an example of this). Beside 2.6.38.6 kernel has trouble with AMD Athlon family (my cpu), and has randomized kernel panics (not reported because is a bug in upstream), https://lkml.org/lkml/2011/5/14/108
The kernel 2.6.38.3 work fine, and 2.6.37.6 very fine (the branch .38 have ioremap error in GT 240 Nvidia with all drivers, no impact but is present in dmesg).
The lastest versions are not always better, rolling release is a good idea, kamize and no tested packages not, so, i decide wich kernel to compile, considering it's the core of the OS. I take control over the kernel, but not over the gcc, if gcc is wrong, i lost control over the core and stability of my system, i do not have a server, but i work with my machine, so is important for me the mantain the system stable all day long.
The test case (test.c) you posted doesn't show any problem in GCC.
In the second comment here, you say that "suddenly without changing anything and use the Arch configuration does not compile on any architecture, or it does it wrong and the resulting binary is useless". Unless you have a quantum computer, it will either compile or it won't, and the behavior will be reproducible 100% of the time.
You really need to clearly describe the problematic behavior you're seeing, and it would be helpful if you included the steps to reproduce it.
i find you very harsh against the people who are trying their best to make this distro great
they are investing a great deal of their "spare" time in this distro
i find it very strange your kernel is not working since i'm always running slackware-config based kernels since 2009 and had never any issues whatsoever building and running
did you check if you have a lot of *.pacsave or *.pacnew files in for example /etc
if so, just check the relevant news posts on the homepage
the config can be found here: http://ftp.belnet.be/packages/slackware/slackware-13.37/testing/source/linux-2.6.38.4-configs/config-generic-smp-2.6.38.4-smp
i686
the config can be found here: http://ftp.belnet.be/packages/slackware/slackware64-13.37/testing/source/linux-2.6.38.4-configs/config-generic-2.6.38.4
x86_64
Closing.