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
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 s
> > 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
> 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
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? Similar
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,
