[PATCH] Make ubsan tests less picky about ansi escape codes in diagnostics.

Maxim Ostapenko m.ostapenko@partner.samsung.com
Wed Sep 9 09:10:00 GMT 2015


On 09/09/15 01:15, Jonathan Roelofs wrote:
>
>
> On 9/4/15 12:20 AM, Yury Gribov wrote:
>> On 09/03/2015 07:45 PM, Jonathan Roelofs wrote:
>>>
>>>
>>> On 9/3/15 10:17 AM, Jakub Jelinek wrote:
>>>> On Thu, Sep 03, 2015 at 10:15:02AM -0600, Jonathan Roelofs wrote:
>>>>> +kcc, mrs
>>>>>
>>>>> Ping
>>>>>
>>>>> On 8/27/15 4:44 PM, Jonathan Roelofs wrote:
>>>>>> The attached patch makes the ubsan tests agnostic to ansi escape 
>>>>>> codes
>>>>>> in their diagnostic output.
>>>>
>>>> It wouldn't hurt if you explained in detail what is the problem you 
>>>> are
>>>> trying to solve and why something that works for most people doesn't
>>>> work in
>>>> your case.
>>>
>>> Hi Jakub,
>>>
>>> AFAICT, there are two ways to suppress the emission of color codes from
>>> ubsan's diagnostics:
>>>
>>>    1) Set an environment variable.
>>>    2) Make the output stream not a tty.
>>>
>>> #1 doesn't seem to be possible in DejaGnu without hacks.
>>
>> AFAIR it can't be done for remote targets due to DejaGnu design
>> limitations.
>>
>>> #2 doesn't work in our environment because DejaGnu attempts to make
>>> itself appear to the program under test as if it were a tty. This might
>>> be an artifact of the fact that all of our testing is remote testing
>>> (though that is just blind speculation on my part:
>>
>> AFAIK that's indeed the case.
>>
>> Added Max.
>
> I've created another patch to address the same issue in the tsan 
> tests, here: [1].
>
>
> Cheers,
>
> Jon
>
> 1: https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00556.html
>

Jon, I've tried to apply your patch on top of trunk to test on my remote 
arm board and got some conflicts:

gcc/testsuite/c-c++-common/ubsan/align-7.c.rej
gcc/testsuite/c-c++-common/ubsan/pr63802.c.rej
gcc/testsuite/c-c++-common/ubsan/overflow-int128.c.rej
gcc/testsuite/c-c++-common/ubsan/align-6.c.rej

The last UBSan tests adjustments were performed by Marek in r222878, 
perhaps your GCC doesn't include these changes?

-Maxim



More information about the Gcc-patches mailing list