Re: distinguishing gcc compilation valgrind false positives

[Martin Liška]

On 11/25/21 13:00, Zdenek Sojka via Gcc wrote:

which is already reported ashttps://gcc.gnu.org/PR101292  , the other warnings 
are still there:


Hello.

Please create a bugzilla entry for this.

Thanks,
Martin

Re: distinguishing gcc compilation valgrind false positives

[Zdenek Sojka via Gcc]

Hello Jan,


-- Původní e-mail --

Od: Jan Hubicka 

Komu: Zdenek Sojka 

Datum: 25. 11. 2021 12:54:00

Předmět: Re: distinguishing gcc compilation valgrind false positives

>

> I can confirm that zero-initializing node_is_self_scc prevents the 
> uninitialised use warnings in incorporate_penalties (ipa-cp.c:3282)

> Great, I will commit the patch.  But I also wonder if there are any

> remaining unitialized warnings in ipa code?


(I am sorry for the broken formatting, Seznam web email client is very 
unfriedly to non-HTML emails)

Apart from:
==22707== Invalid read of size 4
==22707==at 0x197C260: put (hash-map.h:179)

which is already reported as https://gcc.gnu.org/PR101292 , the other warnings 
are still there:

==22707== Invalid read of size 8
==22707==at 0x13FFBCE: hash_map, tree_node*> 
>::put(tree_node* const&, tree_node* const&) [clone .isra.0] (hash-map.h:176)
==22707==by 0x1400E76: 
ipa_param_body_adjustments::prepare_debug_expressions(tree_node*) 
(ipa-param-manipulation.c:1250)
==22707==by 0x140069B: 
ipa_param_body_adjustments::prepare_debug_expressions(tree_node*) 
(ipa-param-manipulation.c:1230)
==22707==by 0x1401997: 
ipa_param_body_adjustments::common_initialization(tree_node*, tree_node**, 
vec*) (ipa-param-manipulation.c:1428)
==22707==by 0x16C7AD4: tree_function_versioning(tree_node*, tree_node*, 
vec*, ipa_param_adjustments*, bool, 
bitmap_head*, basic_block_def*) (tree-inline.c:6303)
==22707==by 0x117328D: cgraph_node::materialize_clone() 
(cgraphclones.c:1142)
==22707==by 0x1161A15: cgraph_node::get_untransformed_body() (cgraph.c:3965)
==22707==by 0x13BE3AB: maybe_materialize_called_clones(cgraph_node*) [clone 
.isra.0] (ipa-inline-transform.c:720)
==22707==by 0x13BE3DC: maybe_materialize_called_clones(cgraph_node*) [clone 
.isra.0] (ipa-inline-transform.c:715)
==22707==by 0x13BE3DC: maybe_materialize_called_clones(cgraph_node*) [clone 
.isra.0] (ipa-inline-transform.c:715)
==22707==by 0x13BE3DC: maybe_materialize_called_clones(cgraph_node*) [clone 
.isra.0] (ipa-inline-transform.c:715)
==22707==by 0x13C02AB: inline_transform(cgraph_node*) 
(ipa-inline-transform.c:777)
==22707==  Address 0x81c5f98 is 40 bytes inside a block of size 208 free'd
==22707==at 0x484240F: free (in 
/usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==22707==by 0x13FFC08: find_slot_with_hash (hash-table.h:967)
==22707==by 0x13FFC08: hash_map, tree_node*> 
>::put(tree_node* const&, tree_node* const&) [clone .isra.0] (hash-map.h:170)
==22707==by 0x1400E76: 
ipa_param_body_adjustments::prepare_debug_expressions(tree_node*) 
(ipa-param-manipulation.c:1250)
==22707==by 0x140069B: 
ipa_param_body_adjustments::prepare_debug_expressions(tree_node*) 
(ipa-param-manipulation.c:1230)
==22707==by 0x1401997: 
ipa_param_body_adjustments::common_initialization(tree_node*, tree_node**, 
vec*) (ipa-param-manipulation.c:1428)
==22707==by 0x16C7AD4: tree_function_versioning(tree_node*, tree_node*, 
vec*, ipa_param_adjustments*, bool, 
bitmap_head*, basic_block_def*) (tree-inline.c:6303)
==22707==by 0x117328D: cgraph_node::materialize_clone() 
(cgraphclones.c:1142)
==22707==by 0x1161A15: cgraph_node::get_untransformed_body() (cgraph.c:3965)
==22707==by 0x13BE3AB: maybe_materialize_called_clones(cgraph_node*) [clone 
.isra.0] (ipa-inline-transform.c:720)
==22707==by 0x13BE3DC: maybe_materialize_called_clones(cgraph_node*) [clone 
.isra.0] (ipa-inline-transform.c:715)
==22707==by 0x13BE3DC: maybe_materialize_called_clones(cgraph_node*) [clone 
.isra.0] (ipa-inline-transform.c:715)
==22707==by 0x13BE3DC: maybe_materialize_called_clones(cgraph_node*) [clone 
.isra.0] (ipa-inline-transform.c:715)
==22707==  Block was alloc'd at
==22707==at 0x4844C0F: calloc (in 
/usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==22707==by 0x2803A14: xcalloc (xmalloc.c:164)
==22707==by 0x100DE26: data_alloc (hash-table.h:275)
==22707==by 0x100DE26: alloc_entries (hash-table.h:711)
==22707==by 0x100DE26: hash_table, tree_node*> 
>::hash_entry, false, xcallocator>::hash_table(unsigned long, bool, bool, bool, 
mem_alloc_origin) (hash-table.h:628)
==22707==by 0x140271A: hash_map (hash-map.h:142)
==22707==by 0x140271A: 
ipa_param_body_adjustments::ipa_param_body_adjustments(ipa_param_adjustments*, 
tree_node*, tree_node*, copy_body_data*, tree_node**, vec*) (ipa-param-manipulation.c:1483)
==22707==by 0x16C7AD4: tree_function_versioning(tree_node*, tree_node*, 
vec*, ipa_param_adjustments*, bool, 
bitmap_head*, basic_block_def*) (tree-inline.c:6303)
==22707==by 0x117328D: cgraph_node::materialize_clone() 
(cgraphclones.c:1142)
==22707==by 0x1161A15: cgraph_node::get_untransformed_body() (cgraph.c:3965)
==22707==by 0x13BE3AB: maybe_materialize_called_clones(cgraph_node*) [clone 
.isra.0] (ipa-inline-transform.c:720)
==2270

Re: distinguishing gcc compilation valgrind false positives

[Jan Hubicka via Gcc]

> 
> I can confirm that zero-initializing node_is_self_scc prevents the 
> uninitialised use warnings in incorporate_penalties (ipa-cp.c:3282)
Great, I will commit the patch.  But I also wonder if there are any
remaining unitialized warnings in ipa code?

Honza
> 
> Thanks,
> Zdenek
> 
> 

Re: distinguishing gcc compilation valgrind false positives

[Zdenek Sojka via Gcc]

Hello Jan,


-- Původní e-mail --

Od: Jan Hubicka via Gcc 

Komu: Martin Jambor 

Datum: 25. 11. 2021 11:13:33

Předmět: Re: distinguishing gcc compilation valgrind false positives

> >

> > diff --git a/gcc/ipa-prop.h b/gcc/ipa-prop.h

> > index 42842d9466a..1d0c115465c 100644

> > --- a/gcc/ipa-prop.h

> > +++ b/gcc/ipa-prop.h

> > @@ -623,8 +623,8 @@ ipa_node_params::ipa_node_params ()

> >  : descriptors (NULL), lattices (NULL), ipcp_orig_node (NULL),

> >known_csts (vNULL), known_contexts (vNULL), analysis_done (0),

> >node_enqueued (0), do_clone_for_all_contexts (0), is_all_contexts_clone 
> > (0),

> > -  node_dead (0), node_within_scc (0), node_calling_single_call (0),

> > -  versionable (0)

> > +  node_dead (0), node_within_scc (0), node_is_self_scc (0),

> > +  node_calling_single_call (0), versionable (0)

> >  {

> >  }

>

> Oops, can you please commit the change to master and all active

> branches?

> OK.  To be honest I am not 100% sure if the flag is not always

> initialized later.



> Zdenek, can you, please, check if the undefined warning in ipcp goes

> away with this patch and if so, post what are the remaining ones?


I can confirm that zero-initializing node_is_self_scc prevents the 
uninitialised use warnings in incorporate_penalties (ipa-cp.c:3282)

Thanks,
Zdenek

Re: distinguishing gcc compilation valgrind false positives

[Jan Hubicka via Gcc]

> >
> > diff --git a/gcc/ipa-prop.h b/gcc/ipa-prop.h
> > index 42842d9466a..1d0c115465c 100644
> > --- a/gcc/ipa-prop.h
> > +++ b/gcc/ipa-prop.h
> > @@ -623,8 +623,8 @@ ipa_node_params::ipa_node_params ()
> >  : descriptors (NULL), lattices (NULL), ipcp_orig_node (NULL),
> >known_csts (vNULL), known_contexts (vNULL), analysis_done (0),
> >node_enqueued (0), do_clone_for_all_contexts (0), is_all_contexts_clone 
> > (0),
> > -  node_dead (0), node_within_scc (0), node_calling_single_call (0),
> > -  versionable (0)
> > +  node_dead (0), node_within_scc (0), node_is_self_scc (0),
> > +  node_calling_single_call (0), versionable (0)
> >  {
> >  }
> 
> Oops, can you please commit the change to master and all active
> branches?
OK.  To be honest I am not 100% sure if the flag is not always
initialized later.  

Zdenek, can you, please, check if the undefined warning in ipcp goes
away with this patch and if so, post what are the remaining ones?
> 
> Thanks,
> 
> Martin
> 

Re: distinguishing gcc compilation valgrind false positives

[Martin Jambor]

Hi,

On Wed, Nov 24 2021, Jan Hubicka via Gcc wrote:
>> ==5404== Conditional jump or move depends on uninitialised value(s)
>> ==5404==    at 0x25DAAD7: incorporate_penalties (ipa-cp.c:3282)
>> ==5404==    by 0x25DAAD7: good_cloning_opportunity_p(cgraph_node*, sreal,
>> sreal, profile_count, int) (ipa-cp.c:3340)
>
> I looked at this one (since it is in code I am familiar with) and I
> think it may be real bug.  There are flags node_is_self_scc which does
> not seem to be initialized in the constructor.
>
> diff --git a/gcc/ipa-prop.h b/gcc/ipa-prop.h
> index 42842d9466a..1d0c115465c 100644
> --- a/gcc/ipa-prop.h
> +++ b/gcc/ipa-prop.h
> @@ -623,8 +623,8 @@ ipa_node_params::ipa_node_params ()
>  : descriptors (NULL), lattices (NULL), ipcp_orig_node (NULL),
>known_csts (vNULL), known_contexts (vNULL), analysis_done (0),
>node_enqueued (0), do_clone_for_all_contexts (0), is_all_contexts_clone 
> (0),
> -  node_dead (0), node_within_scc (0), node_calling_single_call (0),
> -  versionable (0)
> +  node_dead (0), node_within_scc (0), node_is_self_scc (0),
> +  node_calling_single_call (0), versionable (0)
>  {
>  }

Oops, can you please commit the change to master and all active
branches?

Thanks,

Martin

Re: distinguishing gcc compilation valgrind false positives

[Jeff Law via Gcc]

On 11/24/2021 12:41 PM, Zdenek Sojka wrote:

Hello Jeff,

-- Původní e-mail --
Od: Jeff Law via Gcc 
Komu: Paul Floyd , gcc@gcc.gnu.org
Datum: 24. 11. 2021 20:33:02
Předmět: Re: distinguishing gcc compilation valgrind false positives




On 11/24/2021 12:15 PM, Paul Floyd via Gcc wrote:
>
> On 24/11/2021 20:05, Zdenek Sojka via Gcc wrote:
>> Hello,
>>
>> from time to time, I come upon a testcase that failed during the
>> automated
>> runs, but passes during reduction; there are valgrind warnings
present,
>> however. How do I distinguish what warnings are valid and which
are
>> false
>> positives? Is there any way gcc could prevent generating the false
>> positives?
>
>
> What makes you think that any are false positives?
>
> Memcheck generally has a low false positive rate (though I am
little
> biased).
>
> You need to read the source and decide based on that.
Agreed.  Work from the assumption it's a real GCC issue until proven
otherwise.

I believe GCC has annotations to help valgrind that are turned on
by a
magic configuration option as well.


I have gcc configured with --enable-valgrind-annotations , if that is 
the one you are talking about?



Almost certainly.  I



I could also use a valgrind suppression file; this is also part of my 
question, if there is one readily available



I'm not aware of a suppression file, but it'd be nice to have one.

jeff

Re: distinguishing gcc compilation valgrind false positives

[Thomas Schwinge]

Hi!

On 2021-11-24T20:05:56+0100, Zdenek Sojka via Gcc  wrote:
> from time to time, I come upon a testcase that failed during the automated
> runs, but passes during reduction; there are valgrind warnings present,
> however.

Thanks for looking into this.  Please collect any Valgrind notes at
.


> $ x86_64-pc-linux-gnu-gcc `cat flags` -c -w mcf.ii -wrapper valgrind,-q,--
> track-origins=yes
> ==5404== Invalid read of size 4
> ==5404==at 0x197B210: put (hash-map.h:179)
> ==5404==by 0x197B210: void copy_warning
> (tree_node*, tree_node const*) (warning-control.cc:209)
> ==5404==by 0xE40CB6: cp_fold(tree_node*) (cp-gimplify.c:2837)
> [...]

That's  "recent valgrind error in
warning-control.cc since
r12-1804-g65870e75616ee4359d1c13b99be794e6a577bc65".

> ==5404== Invalid read of size 4
> ==5404==at 0x197B210: put (hash-map.h:179)
> ==5404==by 0x197B210: void copy_warning
> (tree_node*, tree_node const*) (warning-control.cc:209)
> ==5404==by 0x12B2343: fold_truth_not_expr(unsigned int, tree_node*)
> (fold-const.c:4288)
> [...]

Same/similar, i suppose.


Grüße
 Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955

Re: distinguishing gcc compilation valgrind false positives

[Paul Floyd via Gcc]

Hi


the main reason why it looks like a false positive is that I've had 
these valgrind warnings ... since probably ever, but it was never 
causing issues.



I cannot tell from the sources if there is anything wrong, so I am 
better asking here.





Well, that's the nature of undefined behaviour. Undefined doesn't mean 
that it is non-deterministic.



And if you really do find false positives (which is always possible, 
especially with new compiler releases) then please report them to us at



https://bugs.kde.org/enter_bug.cgi?product=valgrind


A+

Paul

Re: distinguishing gcc compilation valgrind false positives

[Jan Hubicka via Gcc]

> ==5404== Conditional jump or move depends on uninitialised value(s)
> ==5404==    at 0x25DAAD7: incorporate_penalties (ipa-cp.c:3282)
> ==5404==    by 0x25DAAD7: good_cloning_opportunity_p(cgraph_node*, sreal,
> sreal, profile_count, int) (ipa-cp.c:3340)

I looked at this one (since it is in code I am familiar with) and I
think it may be real bug.  There are flags node_is_self_scc which does
not seem to be initialized in the constructor.

diff --git a/gcc/ipa-prop.h b/gcc/ipa-prop.h
index 42842d9466a..1d0c115465c 100644
--- a/gcc/ipa-prop.h
+++ b/gcc/ipa-prop.h
@@ -623,8 +623,8 @@ ipa_node_params::ipa_node_params ()
 : descriptors (NULL), lattices (NULL), ipcp_orig_node (NULL),
   known_csts (vNULL), known_contexts (vNULL), analysis_done (0),
   node_enqueued (0), do_clone_for_all_contexts (0), is_all_contexts_clone (0),
-  node_dead (0), node_within_scc (0), node_calling_single_call (0),
-  versionable (0)
+  node_dead (0), node_within_scc (0), node_is_self_scc (0),
+  node_calling_single_call (0), versionable (0)
 {
 }
 
Honza

Re: distinguishing gcc compilation valgrind false positives

[Zdenek Sojka via Gcc]

Hello Jeff,

-- Původní e-mail --
Od: Jeff Law via Gcc 
Komu: Paul Floyd , gcc@gcc.gnu.org
Datum: 24. 11. 2021 20:33:02
Předmět: Re: distinguishing gcc compilation valgrind false positives
"

On 11/24/2021 12:15 PM, Paul Floyd via Gcc wrote:
>
> On 24/11/2021 20:05, Zdenek Sojka via Gcc wrote:
>> Hello,
>>
>> from time to time, I come upon a testcase that failed during the
>> automated
>> runs, but passes during reduction; there are valgrind warnings present,
>> however. How do I distinguish what warnings are valid and which are
>> false
>> positives? Is there any way gcc could prevent generating the false
>> positives?
>
>
> What makes you think that any are false positives?
>
> Memcheck generally has a low false positive rate (though I am little
> biased).
>
> You need to read the source and decide based on that.
Agreed.  Work from the assumption it's a real GCC issue until proven 
otherwise.

I believe GCC has annotations to help valgrind that are turned on by a
magic configuration option as well.
"



I have gcc configured with --enable-valgrind-annotations , if that is the 
one you are talking about?


 
"
Finally, there is an issue with sparsesets that will trigger a warning
from valgrind.  Those are the only ones I would consistently ignore from
GCC.

Jeff "






Yes I remember those - but it would be nice to get rid of them anyway, at 
least to simplify testcase reduction by having no valgrind warning on a 
clean build.




I could also use a valgrind suppression file; this is also part of my
question, if there is one readily available




Thanks,
Zdenek




 
"
"

Re: distinguishing gcc compilation valgrind false positives

[Jakub Jelinek via Gcc]

On Wed, Nov 24, 2021 at 12:31:53PM -0700, Jeff Law via Gcc wrote:
> Agreed.  Work from the assumption it's a real GCC issue until proven
> otherwise.
> 
> I believe GCC has annotations to help valgrind that are turned on by a magic
> configuration option as well.

True, but Zdenek has them turned on based on the posted configure options.
That is the --enable-valgrind-annotations in there...

Jakub

Re: distinguishing gcc compilation valgrind false positives

[Zdenek Sojka via Gcc]

Hello Paul,

(sorry for re-post, I didn't include the ML in the original reply)

-- Původní e-mail --
Od: Paul Floyd via Gcc 
Komu: gcc@gcc.gnu.org
Datum: 24. 11. 2021 20:16:33
Předmět: Re: distinguishing gcc compilation valgrind false positives
"
On 24/11/2021 20:05, Zdenek Sojka via Gcc wrote:
> Hello,
>
> from time to time, I come upon a testcase that failed during the automated

> runs, but passes during reduction; there are valgrind warnings present, 
> however. How do I distinguish what warnings are valid and which are false
> positives? Is there any way gcc could prevent generating the false
> positives?


What makes you think that any are false positives?

Memcheck generally has a low false positive rate (though I am little
biased).

You need to read the source and decide based on that.


A+

Paul
"



the main reason why it looks like a false positive is that I've had these 
valgrind warnings ... since probably ever, but it was never causing issues.




I cannot tell from the sources if there is anything wrong, so I am better 
asking here.




Thanks!
Zdenek

 
"
"

Re: distinguishing gcc compilation valgrind false positives

[Jeff Law via Gcc]

On 11/24/2021 12:15 PM, Paul Floyd via Gcc wrote:


On 24/11/2021 20:05, Zdenek Sojka via Gcc wrote:

Hello,

from time to time, I come upon a testcase that failed during the 
automated

runs, but passes during reduction; there are valgrind warnings present,
however. How do I distinguish what warnings are valid and which are 
false

positives? Is there any way gcc could prevent generating the false
positives?



What makes you think that any are false positives?

Memcheck generally has a low false positive rate (though I am little 
biased).


You need to read the source and decide based on that.
Agreed.  Work from the assumption it's a real GCC issue until proven 
otherwise.


I believe GCC has annotations to help valgrind that are turned on by a 
magic configuration option as well.


Finally, there is an issue with sparsesets that will trigger a warning 
from valgrind.  Those are the only ones I would consistently ignore from 
GCC.


Jeff

Re: distinguishing gcc compilation valgrind false positives

[Paul Floyd via Gcc]

On 24/11/2021 20:05, Zdenek Sojka via Gcc wrote:

Hello,

from time to time, I come upon a testcase that failed during the automated
runs, but passes during reduction; there are valgrind warnings present,
however. How do I distinguish what warnings are valid and which are false
positives? Is there any way gcc could prevent generating the false
positives?



What makes you think that any are false positives?

Memcheck generally has a low false positive rate (though I am little 
biased).


You need to read the source and decide based on that.


A+

Paul

distinguishing gcc compilation valgrind false positives

[Zdenek Sojka via Gcc]

Hello,

from time to time, I come upon a testcase that failed during the automated
runs, but passes during reduction; there are valgrind warnings present, 
however. How do I distinguish what warnings are valid and which are false 
positives? Is there any way gcc could prevent generating the false
positives?

The compiler is configured as:
$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r12-5505-20211124090307-g5
deacf6058d-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x
86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --
enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl --build=x86_64-pc-
linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=
/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --
disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r12-5505-
20211124090307-g5deacf6058d-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.0 20211124 (experimental) (GCC)


The output is:

$ x86_64-pc-linux-gnu-gcc `cat flags` -c -w mcf.ii -wrapper valgrind,-q,--
track-origins=yes
==5404== Invalid read of size 4
==5404==    at 0x197B210: put (hash-map.h:179)
==5404==    by 0x197B210: void copy_warning
(tree_node*, tree_node const*) (warning-control.cc:209)
==5404==    by 0xE40CB6: cp_fold(tree_node*) (cp-gimplify.c:2837)
==5404==    by 0xE413A9: cp_fold(tree_node*) (cp-gimplify.c:2679)
==5404==    by 0xE42BAC: cp_fold_maybe_rvalue(tree_node*, bool) (cp-
gimplify.c:2186)
==5404==    by 0xE408C5: cp_fold(tree_node*) (cp-gimplify.c:2501)
==5404==    by 0xE42BAC: cp_fold_maybe_rvalue(tree_node*, bool) (cp-
gimplify.c:2186)
==5404==    by 0xE410DD: cp_fold_rvalue (cp-gimplify.c:2209)
==5404==    by 0xE410DD: cp_fold(tree_node*) (cp-gimplify.c:2568)
==5404==    by 0xE42BAC: cp_fold_maybe_rvalue(tree_node*, bool) (cp-
gimplify.c:2186)
==5404==    by 0xEA8B34: fold_for_warn(tree_node*) (expr.c:418)
==5404==    by 0x103F890: maybe_warn_about_returning_address_of_local
(typeck.c:9994)
==5404==    by 0x103F890: check_return_expr(tree_node*, bool*) (typeck.c:
10657)
==5404==    by 0xFEC75F: finish_return_stmt(tree_node*) (semantics.c:1193)
==5404==    by 0xF4DCEE: cp_parser_jump_statement (parser.c:14198)
==5404==    by 0xF4DCEE: cp_parser_statement(cp_parser*, tree_node*, bool,
bool*, vec*, unsigned int*) (parser.c:12200)
==5404==  Address 0x572ca94 is in a rw- anonymous segment
==5404==
==5404== Invalid read of size 4
==5404==    at 0x197B210: put (hash-map.h:179)
==5404==    by 0x197B210: void copy_warning
(tree_node*, tree_node const*) (warning-control.cc:209)
==5404==    by 0x12B2343: fold_truth_not_expr(unsigned int, tree_node*)
(fold-const.c:4288)
==5404==    by 0x12A4B51: fold_unary_loc(unsigned int, tree_code, tree_
node*, tree_node*) (fold-const.c:9560)
==5404==    by 0x12B2F6E: fold_build1_loc (fold-const.c:13728)
==5404==    by 0x12B2F6E: invert_truthvalue_loc (fold-const.c:4425)
==5404==    by 0x12B2F6E: invert_truthvalue_loc(unsigned int, tree_node*)
(fold-const.c:4419)
==5404==    by 0x1032CC2: cp_build_unary_op(tree_code, tree_node*, bool,
int) (typeck.c:7007)
==5404==    by 0xDE05F2: build_new_op(op_location_t const&, tree_code, int,
tree_node*, tree_node*, tree_node*, tree_node**, int) (call.c:6912)
==5404==    by 0x10314C6: build_x_unary_op(unsigned int, tree_code, cp_expr,
int) (typeck.c:6433)
==5404==    by 0xFF09D1: finish_unary_op_expr(unsigned int, tree_code, cp_
expr, int) (semantics.c:3044)
==5404==    by 0xF6AB9B: cp_parser_unary_expression(cp_parser*, cp_id_kind*,
bool, bool, bool) (parser.c:8900)
==5404==    by 0xF3B14A: cp_parser_binary_expression(cp_parser*, bool, bool,
bool, cp_parser_prec, cp_id_kind*) (parser.c:9925)
==5404==    by 0xF3BA7C: cp_parser_assignment_expression(cp_parser*, cp_id_
kind*, bool, bool) (parser.c:10229)
==5404==    by 0xF3D592: cp_parser_expression(cp_parser*, cp_id_kind*, bool,
bool, bool) (parser.c:10399)
==5404==  Address 0x5857ee4 is in a rw- anonymous segment
==5404==
==5404== Conditional jump or move depends on uninitialised value(s)
==5404==    at 0x25DAAD7: incorporate_penalties (ipa-cp.c:3282)
==5404==    by 0x25DAAD7: good_cloning_opportunity_p(cgraph_node*, sreal,
sreal, profile_count, int) (ipa-cp.c:3340)
==5404==    by 0x25DBA04: estimate_local_effects(cgraph_node*) (ipa-cp.c:
3560)
==5404==    by 0x25E5DD3: propagate_constants_topo (ipa-cp.c:3871)
==5404==    by 0x25E5DD3: ipcp_propagate_stage (ipa-cp.c:4058)
==5404==    by 0x25E5DD3: ipcp_driver (ipa-cp.c:6541)
==5404==    by 0x25E5DD3: (anonymous namespace)::pass_ipa_cp::execute
(function*) (ipa-cp.c:6618)
==5404==    by 0x1538C3C: execute_one_pass(opt_pass*)