Fix uninitialized memory use in ipa-modref

Hi,
this patch fixes two uninitialized memory uses in ipa-modref.  First is
harmless because the values are never used, but they will make valgrind
unhapy.
Second is an actual bug: while breaking the patch in half I forgot to
initialize errno at stream in time.

Bootstrapped/regtested x86_64-linux, comitted.

	* ipa-modref.c (parm_map_for_arg): Initialize parm_offset and
	parm_offset_knonw.
	(read_section): Set writes_errno to false.

On 11/5/20 3:27 PM, Jan Hubicka wrote:
>     poly_int64 offset;
>     struct modref_parm_map parm_map;
>   
> +  parm_map.parm_offset_known = false;
> +  parm_map.parm_offset = 0;
> +

I'm curious, can't we use a proper C++ class construction.
The IPA pass is new and so we can make it more C++-ish? Similarly
for all newly introduced structs in mod ref.

Thanks,
Martin

> On 11/5/20 3:27 PM, Jan Hubicka wrote:
> >     poly_int64 offset;
> >     struct modref_parm_map parm_map;
> > +  parm_map.parm_offset_known = false;
> > +  parm_map.parm_offset = 0;
> > +
> 
> I'm curious, can't we use a proper C++ class construction.
> The IPA pass is new and so we can make it more C++-ish? Similarly
> for all newly introduced structs in mod ref.

We can't because our vec does not accept non-pods and this needs to be
GGC safe since it points to trees.

Honza
> 
> Thanks,
> Martin

> > On 11/5/20 3:27 PM, Jan Hubicka wrote:
> > >     poly_int64 offset;
> > >     struct modref_parm_map parm_map;
> > > +  parm_map.parm_offset_known = false;
> > > +  parm_map.parm_offset = 0;
> > > +
> > 
> > I'm curious, can't we use a proper C++ class construction.
> > The IPA pass is new and so we can make it more C++-ish? Similarly
> > for all newly introduced structs in mod ref.
> 
> We can't because our vec does not accept non-pods and this needs to be
> GGC safe since it points to trees.

We could probably add construction of writes_errno even though in corret
run it should be never used (in analysis we need to be able to
reinitialize and during stream in we will always stream it in).
What else do you think can be more ++-ish? The pass even has two
templates :).

diff --git a/gcc/ipa-modref.c b/gcc/ipa-modref.c
index b40f3da3ba2..e80f6de09f2 100644
--- a/gcc/ipa-modref.c
+++ b/gcc/ipa-modref.c
@@ -124,7 +124,7 @@ static GTY(()) fast_function_summary <modref_summary_lto *, va_gc>
 /* Summary for a single function which this pass produces.  */
 
 modref_summary::modref_summary ()
-  : loads (NULL), stores (NULL)
+  : loads (NULL), stores (NULL), writes_errno (NULL)
 {
 }

On 11/5/20 6:54 PM, Jan Hubicka wrote:
>>> On 11/5/20 3:27 PM, Jan Hubicka wrote:
>>>>      poly_int64 offset;
>>>>      struct modref_parm_map parm_map;
>>>> +  parm_map.parm_offset_known = false;
>>>> +  parm_map.parm_offset = 0;
>>>> +
>>>
>>> I'm curious, can't we use a proper C++ class construction.
>>> The IPA pass is new and so we can make it more C++-ish? Similarly
>>> for all newly introduced structs in mod ref.
>>
>> We can't because our vec does not accept non-pods and this needs to be
>> GGC safe since it points to trees.
> 
> We could probably add construction of writes_errno even though in corret
> run it should be never used (in analysis we need to be able to
> reinitialize and during stream in we will always stream it in).

It may be error prone approach to initialize it to NULL.

> What else do you think can be more ++-ish? The pass even has two
> templates :).

Heh, all right :)

> 
> diff --git a/gcc/ipa-modref.c b/gcc/ipa-modref.c
> index b40f3da3ba2..e80f6de09f2 100644
> --- a/gcc/ipa-modref.c
> +++ b/gcc/ipa-modref.c
> @@ -124,7 +124,7 @@ static GTY(()) fast_function_summary <modref_summary_lto *, va_gc>
>   /* Summary for a single function which this pass produces.  */
>   
>   modref_summary::modref_summary ()
> -  : loads (NULL), stores (NULL)
> +  : loads (NULL), stores (NULL), writes_errno (NULL)
>   {
>   }
>   
>

On 11/5/20 6:37 PM, Jan Hubicka wrote:
> We can't because our vec does not accept non-pods and this needs to be
> GGC safe since it points to trees.

Ah, that's new to me!

Thanks,
Martin