Hello Martin,
The issue is that I want to count the coverage of "true/false" branches
taken in sanitizer's if conditions..
Best,
Shuai
On Wed, Jun 17, 2020 at 2:52 PM Martin Liška wrote:
> On 6/17/20 5:40 AM, Shuai Wang via Gcc wrote:
> > Hello,
> >
>
> Hello.
>
> Right now, coverage informati
On 6/17/20 5:40 AM, Shuai Wang via Gcc wrote:
Hello,
Hello.
Right now, coverage information reports line execution of statements that
are present in the original source code.
Can you make a mapping of the instrumented code to statements that are present
in the original source code?
Martin
On 6/17/20 4:10 AM, Shuai Wang via Gcc wrote:
Hello,
Suppose I have changed certain if condition in the GIMPLE code (generated
by the `sanopt` pass) into the following format:
Hello.
What kind of instrumentation are you doing? Can you make the instrumentation
in a ASAN pass? Then you'll go th
Hello,
I am aware of how to use gcov for c code line coverage collection. However,
currently I am working on a piece of GIMPLE code (did some instrumentation
on the GIMPLE code and therefore is more complex compared to the original C
code)l, and would like to collect the line coverage info of GIMP
Hello,
Suppose I have changed certain if condition in the GIMPLE code (generated
by the `sanopt` pass) into the following format:
if (0 == 1)
{
}
Then, in order to completely remove this unnecessary if condition and the
guarded true branch, I want to leverage the dead code elimination
op
Hi!
On Tue, Jun 16, 2020 at 02:09:37PM +0100, Jonathan Wakely wrote:
> I see no harm in rebasing public branches as long as nobody expects
> otherwise. A public branch on gcc.gnu.org under refs/heads that is
> being pulled by unknown persons and used in unknown forks for unknown
> purposes shouldn
On Tue, Jun 16, 2020 at 02:54:13PM +, Joseph Myers wrote:
> On Tue, 16 Jun 2020, Jonathan Wakely via Gcc wrote:
>
> > I see no harm in rebasing public branches as long as nobody expects
> > otherwise.
>
> And by design you *can* rebase user and vendor branches (but not those in
> other names
Hi!
Before OpenMP 5.0, all OpenMP loop nests had to be rectangular (and OpenMP
has various other restrictions that make implementation easier), so that it
was very easy to compute the number of iterations of the collapsed loop
by computing number of iterations of each of the loops in the loop nest
On Tue, 16 Jun 2020, Jonathan Wakely via Gcc wrote:
> I see no harm in rebasing public branches as long as nobody expects
> otherwise.
And by design you *can* rebase user and vendor branches (but not those in
other namespaces). The message about not being a fast-forward is just a
warning, not
Hi!
On Tue, Jun 16, 2020 at 11:11:01AM +0200, Martin Jambor wrote:
> On Mon, Jun 15 2020, Segher Boessenkool wrote:
> > What.
> >
> > Of course it is not a fast-forward. I rebase the branches I publish,
> > what is the point of publishing them otherwise? This is so that people
> > can see the st
On Tue, 16 Jun 2020 at 10:11, Martin Jambor wrote:
>
> Hi,
>
> On Mon, Jun 15 2020, Segher Boessenkool wrote:
> > Hi!
> >
> [...]
> > What.
> >
> > Of course it is not a fast-forward. I rebase the branches I publish,
> > what is the point of publishing them otherwise? This is so that people
> >
Richard Biener writes:
> I'm facing the issue that we have vector type dependent information
> stored in dr_vec_info (the misalignment at least) and that with
> BB vectorization (at least) we want to be able to access a DR group with
> two different vector types.
>
> I've run into this with
> htt
On Tue, Jun 16, 2020 at 5:00 AM Shuai Wang wrote:
>
> Yes, TREE_CODE (op1) != SSA_NAME shows that op1 is by no means SSA names
> (although I don't know why). But how can I backwardly identify its
> initialization statement _17 = (signed char *) _16? Thanks!
You want to walk over SSA operands o
Hi,
On Mon, Jun 15 2020, Segher Boessenkool wrote:
> Hi!
>
[...]
> What.
>
> Of course it is not a fast-forward. I rebase the branches I publish,
> what is the point of publishing them otherwise? This is so that people
> can see the stuff that will make its way into master *later*.
>
> The numbe
14 matches
Mail list logo
