[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