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
>>>
>>

Reply via email to