or, alternatively, we can disable libsanitizer on PowerPC if the PowerPC community does not care enough about it being healthy.
On Tue, Nov 12, 2013 at 9:41 AM, Kostya Serebryany <k...@google.com> wrote: > [plain text] > So far I was not able to reproduce the compilation failure -- and I am > asking someone from the PowerPC side to help. > Please apply any minimal #ifdef patch to > sanitizer_platform_limits_linux.cc to make it compile, while keeping > x86_64 tests pass. > > If we revert the patch now, I will not be able to work on it again in > nearest months, which means 4.9 will not get updated asan. > How bad that is -- I don't know. > > --kcc > > On Tue, Nov 12, 2013 at 9:40 AM, Kostya Serebryany <k...@google.com> wrote: >> So far I was not able to reproduce the compilation failure -- and I am >> asking someone from the PowerPC side to help. >> Please apply any minimal #ifdef patch to sanitizer_platform_limits_linux.cc >> to make it compile, while keeping x86_64 tests pass. >> >> If we revert the patch now, I will not be able to work on it again in >> nearest months, which means 4.9 will not get updated asan. >> How bad that is -- I don't know. >> >> --kcc >> >> >> On Tue, Nov 12, 2013 at 9:37 AM, Michael Meissner >> <meiss...@linux.vnet.ibm.com> wrote: >>> >>> It has been a week since the libsanitizer patches were checked in, which >>> broke >>> the PowerPC64 Linux system along with others (PR 59009 for powerpc). >>> Please >>> revert these patches while you are working on proper fixes for all of the >>> hosts >>> and targets. >>> >>> Quoting from the GCC development plan: >>> >>> Patch Reversion >>> >>> If a patch is committed which introduces a regression on any target which >>> the >>> Steering Committee considers to be important and if: >>> >>> the problem is reported to the original poster; 48 hours pass without the >>> original poster or any other party indicating that a fix will be >>> forthcoming in >>> the very near future; two people with write privileges to the affected >>> area of >>> the compiler determine that the best course of action is to revert the >>> patch; >>> then they may revert the patch. >>> >>> (The list of important targets will be revised at the beginning of each >>> release >>> cycle, if necessary, and is part of the release criteria.) >>> >>> After the patch has been reverted, the poster may appeal the decision to >>> the >>> Steering Committee. >>> >>> Note that no distinction is made between patches which are themselves >>> buggy and >>> patches that expose latent bugs elsewhere in the compiler. >>> >>> -- >>> Michael Meissner, IBM >>> IBM, M/S 2506R, 550 King Street, Littleton, MA 01460, USA >>> email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797 >>> >>