SanitizerCoverage support

[Roger Phillips via Gcc]

Greetings,

can you tell me if support of SanitizerCoverage is planned for gcc in the 
foreseeable future?

Regards

Re: SanitizerCoverage support

[Martin Liška]

On 1/19/21 10:07 AM, Roger Phillips via Gcc wrote:

Greetings,

can you tell me if support of SanitizerCoverage is planned for gcc in the 
foreseeable future?

Regards



Hello.

We do support it, please see 'man gcc':

-fsanitize-coverage=trace-pc
-fsanitize-coverage=trace-cmp

Martin

Re: SanitizerCoverage support

[Roger Phillips via Gcc]

Excellent! Since which version is this available?


From: Martin Liška 
Sent: Tuesday, January 19, 2021 10:23 AM
To: Roger Phillips ; gcc@gcc.gnu.org 
Subject: Re: SanitizerCoverage support

On 1/19/21 10:07 AM, Roger Phillips via Gcc wrote:
> Greetings,
>
> can you tell me if support of SanitizerCoverage is planned for gcc in the 
> foreseeable future?
>
> Regards
>

Hello.

We do support it, please see 'man gcc':

-fsanitize-coverage=trace-pc
-fsanitize-coverage=trace-cmp

Martin

Re: SanitizerCoverage support

[Martin Liška]

On 1/19/21 11:33 AM, Roger Phillips wrote:

Excellent! Since which version is this available?


Hello.

The option -fsanitize-coverage=trace-pc is available since 6.1.0 and
-fsanitize-coverage=trace-cmp since 8.1.0.

Martin



--
*From:* Martin Liška 
*Sent:* Tuesday, January 19, 2021 10:23 AM
*To:* Roger Phillips ; gcc@gcc.gnu.org 
*Subject:* Re: SanitizerCoverage support
On 1/19/21 10:07 AM, Roger Phillips via Gcc wrote:

Greetings,

can you tell me if support of SanitizerCoverage is planned for gcc in the 
foreseeable future?

Regards



Hello.

We do support it, please see 'man gcc':

-fsanitize-coverage=trace-pc
-fsanitize-coverage=trace-cmp

Martin

Re: SanitizerCoverage support

[Roger Phillips via Gcc]

Oh btw:

Does any of these two modes allow me to generate sancov files on function 
level? My intent is to record program flow, then visualize the diff between the 
runs. Most examples I see use edge,bb,func modes so I'm not sure trace-pc and 
trace-pc-cmp are enough.


From: Martin Liška 
Sent: Tuesday, January 19, 2021 10:40 AM
To: Roger Phillips ; gcc@gcc.gnu.org 
Subject: Re: SanitizerCoverage support

On 1/19/21 11:33 AM, Roger Phillips wrote:
> Excellent! Since which version is this available?

Hello.

The option -fsanitize-coverage=trace-pc is available since 6.1.0 and
-fsanitize-coverage=trace-cmp since 8.1.0.

Martin

>
> --
> *From:* Martin Liška 
> *Sent:* Tuesday, January 19, 2021 10:23 AM
> *To:* Roger Phillips ; gcc@gcc.gnu.org 
> *Subject:* Re: SanitizerCoverage support
> On 1/19/21 10:07 AM, Roger Phillips via Gcc wrote:
>> Greetings,
>>
>> can you tell me if support of SanitizerCoverage is planned for gcc in the 
>> foreseeable future?
>>
>> Regards
>>
>
> Hello.
>
> We do support it, please see 'man gcc':
>
> -fsanitize-coverage=trace-pc
> -fsanitize-coverage=trace-cmp
>
> Martin

Should GCC provide __builtin_memcpy_inline like clang does?

[unlvsur unlvsur via Gcc]

I think __builtin_memmove_inline, __builtin_memset_inline can also get provided.

That allows better performance for small size copies and allowing memcpy to be 
usable without libc.

Sent from Mail for Windows 10

Re: SanitizerCoverage support

[Roger Phillips via Gcc]

I tried -fsanitize-coverage=trace-pc with g++ 7.5.0 on a X64 Ubuntu system.
The linker complained that a function __sanitizer_cov_trace_pc was undefined. 
So I added it in my program like this:

extern "C" void __sanitizer_cov_trace_pc()
{
   printf("Address: %p\n", __builtin_return_address(0));
}

I then build with
g++ -std=c++11 -g -O0 -fsanitize-coverage=trace-pc ./test.cpp -o ./test

Unfortunately, the function seems to call itself recursively and finishes with 
a stack overflow.
What do I do wrong?

I would also rather use prefabricated functions for sancov.

Regards



From: Martin Liška 
Sent: Tuesday, January 19, 2021 10:23 AM
To: Roger Phillips ; gcc@gcc.gnu.org 
Subject: Re: SanitizerCoverage support

On 1/19/21 10:07 AM, Roger Phillips via Gcc wrote:
> Greetings,
>
> can you tell me if support of SanitizerCoverage is planned for gcc in the 
> foreseeable future?
>
> Regards
>

Hello.

We do support it, please see 'man gcc':

-fsanitize-coverage=trace-pc
-fsanitize-coverage=trace-cmp

Martin

Re: Should GCC provide __builtin_memcpy_inline like clang does?

[Segher Boessenkool]

On Tue, Jan 19, 2021 at 11:33:56AM +, unlvsur unlvsur via Gcc-help wrote:
> I think __builtin_memmove_inline, __builtin_memset_inline can also get 
> provided.
> 
> That allows better performance for small size copies

You normally will get better performance by letting the compiler figure
out whether to inline or not.  That is what the Power port does, for
example.

> and allowing memcpy to be usable without libc.

You can provide your own non-standard-named function anyway?


In either case, feature requests should go into bugzilla, or they will
more than likely be lost.

Thanks,


Segher

RE: Should GCC provide __builtin_memcpy_inline like clang does?

[unlvsur unlvsur via Gcc]

That is not for inline. That is to allow implementing memcpy without 
introducing any libc runtime which allows us to use it in freestanding 
environment.

Sent from Mail for Windows 10

From: Segher Boessenkool
Sent: Tuesday, January 19, 2021 13:52
To: unlvsur unlvsur
Cc: gcc@gcc.gnu.org; 
gcc-h...@gcc.gnu.org
Subject: Re: Should GCC provide __builtin_memcpy_inline like clang does?

On Tue, Jan 19, 2021 at 11:33:56AM +, unlvsur unlvsur via Gcc-help wrote:
> I think __builtin_memmove_inline, __builtin_memset_inline can also get 
> provided.
>
> That allows better performance for small size copies

You normally will get better performance by letting the compiler figure
out whether to inline or not.  That is what the Power port does, for
example.

> and allowing memcpy to be usable without libc.

You can provide your own non-standard-named function anyway?


In either case, feature requests should go into bugzilla, or they will
more than likely be lost.

Thanks,


Segher

Re: Should GCC provide __builtin_memcpy_inline like clang does?

[Gabriel Ravier via Gcc]

On 1/19/21 12:33 PM, unlvsur unlvsur via Gcc wrote:
I think __builtin_memmove_inline, __builtin_memset_inline can also get 
provided.


That allows better performance for small size copies


Manual tweaking like that seems a bit ridiculous except in very narrow 
situations, and just letting GCC assume there is an implementation of 
memset/memmove lets it do optimization based on copy size by default. I 
guess there could be some value to such an extension for portably doing 
such specific micro-optimizations manually, though.



and allowing memcpy to be usable without libc.
You can just define it yourself, don't worry, GCC won't mind (as long as 
it has the correct semantics). Even for the narrow case of memmove, 
which could be mildly inconvenient to implement in less than 10 lines on 
a few systems that have non-trivial pointers (i.e. `source < 
destination` doesn't work as expected), you're on freestanding, so you 
should be able to make some kind of working implementation by using 
non-standard stuff for that specific purpose.

Re: Should GCC provide __builtin_memcpy_inline like clang does?

[H.J. Lu via Gcc]

On Tue, Jan 19, 2021 at 6:44 PM Gabriel Ravier via Gcc  wrote:
>
> On 1/19/21 12:33 PM, unlvsur unlvsur via Gcc wrote:
> > I think __builtin_memmove_inline, __builtin_memset_inline can also get
> > provided.
> >
> > That allows better performance for small size copies
>
> Manual tweaking like that seems a bit ridiculous except in very narrow
> situations, and just letting GCC assume there is an implementation of
> memset/memmove lets it do optimization based on copy size by default. I
> guess there could be some value to such an extension for portably doing
> such specific micro-optimizations manually, though.
>
> > and allowing memcpy to be usable without libc.
> You can just define it yourself, don't worry, GCC won't mind (as long as
> it has the correct semantics). Even for the narrow case of memmove,
> which could be mildly inconvenient to implement in less than 10 lines on
> a few systems that have non-trivial pointers (i.e. `source <
> destination` doesn't work as expected), you're on freestanding, so you
> should be able to make some kind of working implementation by using
> non-standard stuff for that specific purpose.
>

FWIW, on x86, GCC 11 can inline all calls to memset, memcpy and
memcmp with -minline-all-stringops.

-- 
H.J.

Re: Should GCC provide __builtin_memcpy_inline like clang does?

[Richard Biener via Gcc]

On Tue, Jan 19, 2021 at 9:04 PM unlvsur unlvsur via Gcc  wrote:
>
> That is not for inline. That is to allow implementing memcpy without 
> introducing any libc runtime which allows us to use it in freestanding 
> environment.

Note that GCC requires memcpy, memmove, memset and memcmp to exist even in
a freestanding environment since it may generate calls to those
functions itself.
So the argument of a freestanding env does not hold.

Richard.

> Sent from Mail for Windows 10
>
> From: Segher Boessenkool
> Sent: Tuesday, January 19, 2021 13:52
> To: unlvsur unlvsur
> Cc: gcc@gcc.gnu.org; 
> gcc-h...@gcc.gnu.org
> Subject: Re: Should GCC provide __builtin_memcpy_inline like clang does?
>
> On Tue, Jan 19, 2021 at 11:33:56AM +, unlvsur unlvsur via Gcc-help wrote:
> > I think __builtin_memmove_inline, __builtin_memset_inline can also get 
> > provided.
> >
> > That allows better performance for small size copies
>
> You normally will get better performance by letting the compiler figure
> out whether to inline or not.  That is what the Power port does, for
> example.
>
> > and allowing memcpy to be usable without libc.
>
> You can provide your own non-standard-named function anyway?
>
>
> In either case, feature requests should go into bugzilla, or they will
> more than likely be lost.
>
> Thanks,
>
>
> Segher
>