[r11-3641 Regression] FAIL: gcc.dg/torture/pta-ptrarith-1.c -Os scan-tree-dump alias "ESCAPED = {[^\n}]* i f [^\n}]*}" on Linux/x86_64 (-m32 -march=cascadelake)

Richard Biener rguenther@suse.de
Tue Oct 6 06:08:43 GMT 2020


On Sun, 4 Oct 2020, Jan Hubicka wrote:

> > > >
> > > > A number of people routinely send emails similar to these to this
> > > > list to point out regressions on their targets.  I find both kinds
> > > > of emails very useful and don't mind the additional traffic.
> > > >
> > > > What would be an improvement is sending just one email for all
> > > > the testsuite regressions rather than one for each test or run
> > > > as seems to be happening.
> > >
> > > Sunil, can you update your script to send out a single email
> > > for all regressions caused by one commit?  Thanks.
> > >
> > Sure, I'll work on it.
> 
> In any case this mail was useful (thanks for running the script).  The
> bug in mod-ref is by using poly_int64 to remember offset from MEM_REF:
> 
>      tree offset = TREE_CODE (base) == MEM_REF
>                   ? TREE_OPERAND (base, 1) : NULL_TREE;
> 
> a.parm_offset_known = offset && wi::to_poly_offset (offset).to_shwi
> 				    (&a.parm_offset).to_shwi (&a.parm_offset)
> 
> For 64bit targets this is OK, but for 32bit targets we mistakely
> consider negative offsets to be large positive integers here:
> 
>                   ao_ref_init_from_ptr_and_range
>                          (&ref2, arg, true,
>                           access_node->offset
>                           + (access_node->parm_offset
>                              << LOG2_BITS_PER_UNIT), access_node->size,
>                           access_node->max_size);
> 
> I think I am intended to use mem_ref_offset and poly_offset_int type.

That will be easiest, yes.

> This will need new streaming support that is not hard to add, but I am
> not sure how to do the computation above (that probably needs overflow
> check) and how to print the offset to dump file.

You can also use poly_wide_int and then check wether the result fits.
mem_ref_offset does

poly_offset_int
mem_ref_offset (const_tree t)
{
  return poly_offset_int::from (wi::to_poly_wide (TREE_OPERAND (t, 1)),
                                SIGNED);
}

so you could do only wi::to_poly_wide (...), do the computation
and then check whether the result fits?

> Richard, can you help me? :))
> I had code in ao_ref_init_from_ptr_and_range that took parm_code
> separately and re-inserted it to the MEM_REF built. However this does
> not happen in all cases: when base is a decl we omit constructing
> MEM_REF and then offset adjustment is necessary.
> Without going through this folding we are unable to disambiguate base
> pointers: MEM_REF containing ADDR_EXPR of DECL does not go through the
> usual decl compares.
> 
> Honza
> > 
> > >
> > > > I'm not sure that automatically opening bugs instead would be
> > > > better, certainly not one per test, and not if the code author
> > > > wasn't also CC'd if not automatically assigned to it.
> > > >
> > > > Martin
> > >
> > >
> > >
> > > --
> > > H.J.
> > >
> 

-- 
Richard Biener <rguenther@suse.de>
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imend


More information about the Gcc-patches mailing list