Bug 160997, Bug 161183, Bug 161370, Bug 162053, Bug 162209, Bug 162338, Bug 162427, Bug 162429, Bug 162431, Bug 162433, Bug 162437, Bug 162438, Bug 162440, Bug 162441, Bug 162447 - a list for last couple of days... Sorry folks but this mostly upstream stuff is really of no interest to an average user, it's horribly noisy and annoying. Alternatively feel free to shove this under FEATURES="stricter" but flooding all users with tons of warnings they don't understand doesn't help. Thanks.
your examples pretty much all suck ... majority of those bug reports you've cited are real issues i'd like to disable some of the messages for the average user, but there are some that are really not negotiable ... for example, everyone is going to see "dereferencing type-punned pointer will break strict-aliasing rules" and bug reports need to be filed so they can be fixed ive also elevated the 64bit warning to a die for everyone on a 64bit host (Bug 162431)
FEATURES=stricter isnt applicable here also, are you talking about all QA notices or just the source code ones ? i'd be ok with disabling all post QA checks by default, but not selective source code ones even if this FEATURE is implemented and the normal user doesnt see the warnings, that isnt going to stem the tide of incoming bug reports for crappy code
(In reply to comment #2) > also, are you talking about all QA notices or just the source code ones ? i'd > be ok with disabling all post QA checks by default, but not selective source > code ones Really up to you to decide; the thing is that the number of various QA checks has expanded recently by a significant amount and users are getting drowned in them, it's really really noisy now. This is a good thing for developers testing their ebuilds, but not so good for average users indeed. If it's serious issue, then sure die there, otherwise no need to bug users with those. > even if this FEATURE is implemented and the normal user doesnt see the > warnings, that isnt going to stem the tide of incoming bug reports for crappy > code Well, if these bugs come from developers, they can assign them directly, and more importantly I'd hope they will be accompanied by patches that could be sent upstream. This usually won't be the case with bugs filed by users randomly seeing the QA Notices.
As top poster of the bug list provided by Jakub, I can just repeat what I said here: https://bugs.gentoo.org/show_bug.cgi?id=162711#c3 Jakub, I'm sorry for the extra work; I'll assign new bugs directly.
For one it should be possible to due -fno-strict-aliasing as the default for stable desktop profile. For two at least one of these errors 'dereferencing pointer type punned breaks strict aliasing' some googling results in http://lists.freebsd.org/pipermail/freebsd-current/2003-July/007628.html Which contains a diff ...hoping it is applicable since this is very common. Index: pcpu.h =================================================================== RCS file: /home/ncvs/src/sys/i386/include/pcpu.h,v retrieving revision 1.35 diff -u -2 -r1.35 pcpu.h --- pcpu.h 1 Oct 2002 14:01:58 -0000 1.35 +++ pcpu.h 28 Jul 2003 14:02:30 -0000 @@ -78,5 +80,5 @@ * Evaluates to the address of the per-cpu variable name. */ -#define __PCPU_PTR(name) ({ \ +#define __PCPU_PTR(name) __extension__ ({ \ __pcpu_type(name) *__p; \ \ @@ -96,21 +98,21 @@ \ if (sizeof(__result) == 1) { \ - u_char __b; \ - __asm __volatile("movb %%fs:%1,%0" \ - : "=r" (__b) \ - : "m" (*(u_char *)(__pcpu_offset(name)))); \ - __result = *(__pcpu_type(name) *)&__b; \ + __pcpu_type(name) __res; \ + __asm __volatile("mov%L0 %%fs:%1,%0" \ + : "=r" (__res) \ + : "m" (*(__pcpu_type(name) *)(__pcpu_offset(name)))); \ + __result = *(__pcpu_type(name) *)&__res; \ } else if (sizeof(__result) == 2) { \ - u_short __w; \ - __asm __volatile("movw %%fs:%1,%0" \ - : "=r" (__w) \ - : "m" (*(u_short *)(__pcpu_offset(name)))); \ - __result = *(__pcpu_type(name) *)&__w; \ + __pcpu_type(name) __res; \ + __asm __volatile("mov%L0 %%fs:%1,%0" \ + : "=r" (__res) \ + : "m" (*(__pcpu_type(name) *)(__pcpu_offset(name)))); \ + __result = *(__pcpu_type(name) *)&__res; \ } else if (sizeof(__result) == 4) { \ - u_int __i; \ - __asm __volatile("movl %%fs:%1,%0" \ - : "=r" (__i) \ - : "m" (*(u_int *)(__pcpu_offset(name)))); \ - __result = *(__pcpu_type(name) *)&__i; \ + __pcpu_type(name) __res; \ + __asm __volatile("mov%L0 %%fs:%1,%0" \ + : "=r" (__res) \ + : "m" (*(__pcpu_type(name) *)(__pcpu_offset(name)))); \ + __result = *(__pcpu_type(name) *)&__res; \ } else { \ __result = *__PCPU_PTR(name); \ @@ -123,29 +125,29 @@ * Sets the value of the per-cpu variable name to value val. */ -#define __PCPU_SET(name, val) ({ \ +#define __PCPU_SET(name, val) { \ __pcpu_type(name) __val = (val); \ \ if (sizeof(__val) == 1) { \ u_char __b; \ - __b = *(u_char *)&__val; \ - __asm __volatile("movb %1,%%fs:%0" \ - : "=m" (*(u_char *)(__pcpu_offset(name))) \ + __builtin_memcpy(&__b, &__val, sizeof(__val)); \ + __asm __volatile("mov%L1 %1,%%fs:%0" \ + : "=m" (*(__pcpu_type(name) *)(__pcpu_offset(name))) \ : "r" (__b)); \ } else if (sizeof(__val) == 2) { \ u_short __w; \ - __w = *(u_short *)&__val; \ - __asm __volatile("movw %1,%%fs:%0" \ - : "=m" (*(u_short *)(__pcpu_offset(name))) \ + __builtin_memcpy(&__w, &__val, sizeof(__val)); \ + __asm __volatile("mov%L1 %1,%%fs:%0" \ + : "=m" (*(__pcpu_type(name) *)(__pcpu_offset(name))) \ : "r" (__w)); \ } else if (sizeof(__val) == 4) { \ u_int __i; \ - __i = *(u_int *)&__val; \ - __asm __volatile("movl %1,%%fs:%0" \ - : "=m" (*(u_int *)(__pcpu_offset(name))) \ + __builtin_memcpy(&__i, &__val, sizeof(__val)); \ + __asm __volatile("mov%L1 %1,%%fs:%0" \ + : "=m" (*(__pcpu_type(name) *)(__pcpu_offset(name))) \ : "r" (__i)); \ } else { \ *__PCPU_PTR(name) = __val; \ } \ -}) +} #define PCPU_GET(member) __PCPU_GET(pc_ ## member) %%% Bruce
My suggestion is to split *-qa-check.d into *-qa-check.d (ones that should always be run) and *-qa-check-dev.d (ones that are loud and/or not as relevant for most users). Sam mentioned in -dev that Portage is trying to avoid adding new FEATURES if other methods are possible, so perhaps an arg like --dev-qa-checks or something to run the additional checks. The arg would probably have to be added to both emerge(1) and ebuild(1) to get them to run during regular emerges as well as `ebuild /path/to/foo.ebuild clean install`. This would also enable workflows where someone doesn't want the extra checks during an emerge, but might want them when doing `ebuild ...`.