On 10/11/2014 10:51 AM, Otavio Salvador wrote: > Hello Russell, > > On Sat, Oct 11, 2014 at 11:16 AM, Russell King - ARM Linux > <linux@xxxxxxxxxxxxxxxx> wrote: >> On Sat, Oct 11, 2014 at 11:54:32AM +0800, Peter Chen wrote: >>> On Fri, Oct 10, 2014 at 08:44:33PM -0500, Nathan Lynch wrote: >>>> On 10/10/2014 11:25 AM, Russell King - ARM Linux wrote: >>>>> >>>>> Right, so GCC 4.8.{1,2} are totally unsuitable for kernel building (and >>>>> it seems that this has been known about for some time.) >>>> >>>> Looking at http://gcc.gnu.org/PR58854 it seems that all 4.8.x for x < 3 >>>> are affected, as well as 4.9.0. >>>> >>>>> We can blacklist these GCC versions quite easily. We already have GCC >>>>> 3.3 blacklisted, and it's trivial to add others. I would want to include >>>>> some proper details about the bug, just like the other existing entries >>>>> we already have in asm-offsets.c, where we name the functions that the >>>>> compiler is known to break where appropriate. >>>> >>>> Before blacklisting anything, it's worth considering that simple version >>>> checks would break existing pre-4.8.3 compilers that have been patched >>>> for PR58854. It looks like Yocto and Buildroot issued releases with >>>> patched 4.8.2 compilers well before the (fixed) 4.8.3 release. I think >>>> the most we can reasonably do without breaking some correctly-behaving >>>> toolchains is to emit a warning. >>> >>> Yocto has PR58854 problem patch. >>> >>> http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-devtools/gcc/gcc-4.8/0048-PR58854_fix_arm_apcs_epilogue.patch?h=daisy >> >> Right, and we can provide links to these in the comments above the #error >> so people have the right places to do a bit of research into whether their >> compiler is safe. >> >> It is unfortunate that they are indistinguishable from the broken versions, >> but that's really a distro problem for causing that issue themselves - >> especially given how serious this bug is. > > What about checking if GCC_PR58854_FIXED is not defined for error? So > build systems and people could easily define it if they know their GCC > has the fix applied. If the distro/build system/individual is capable of patching gcc, then it seems reasonable that the same distro/build system/individual is capable of carrying a patch on top of mainline kernel for building with their "special" compiler. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html