Re: distinguishing gcc compilation valgrind false positives

2021-11-25 Thread 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) (

Re: distinguishing gcc compilation valgrind false positives

2021-11-25 Thread 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),

Re: distinguishing gcc compilation valgrind false positives

2021-11-25 Thread 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 >

Re: distinguishing gcc compilation valgrind false positives

2021-11-25 Thread 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

2021-11-25 Thread 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 inco

Re: distinguishing gcc compilation valgrind false positives

2021-11-25 Thread 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: [EXTERNAL] Re: Question about match.pd

2021-11-25 Thread Navid Rahimi via Gcc
> (A << B) eq/ne 0 Yes that is correct. But for detecting such pattern you You have to detect B and make sure B is boolean. GIMPLE transfers that Boolean to integer before shifting. After many hours of debugging, I think I managed to find out what is going on. +/* cmp : ==, != */ +/* ((B0 << x

gcc-9-20211125 is now available

2021-11-25 Thread GCC Administrator via Gcc
Snapshot gcc-9-20211125 is now available on https://gcc.gnu.org/pub/gcc/snapshots/9-20211125/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 9 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch

Re: atomic_load

2021-11-25 Thread Martin Uecker via Gcc
Am Sonntag, den 07.11.2021, 10:08 +0100 schrieb Martin Uecker: > It would be great if somebody could take a look at > PR96159. > > It seems we do not do atomic accesses correctly > when the alignment is insufficient for a lockfree > access, but I think we should fall back to a > library call in t

Re: [EXTERNAL] Re: Question about match.pd

2021-11-25 Thread Richard Biener via Gcc
On Thu, Nov 25, 2021 at 10:40 PM Navid Rahimi via Gcc wrote: > > > (A << B) eq/ne 0 > Yes that is correct. But for detecting such pattern you You have to detect B > and make sure B is boolean. GIMPLE transfers that Boolean to integer before > shifting. Note it's the C language specification th