[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)

[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)

[sunil.k.pandey]

On Linux/x86_64,

c34db4b6f8a5d80367c709309f9b00cb32630054 is the first bad commit
commit c34db4b6f8a5d80367c709309f9b00cb32630054
Author: Jan Hubicka <jh@suse.cz>
Date:   Sat Oct 3 17:20:16 2020 +0200

    Track access ranges in ipa-modref

caused

FAIL: gcc.dg/torture/pta-ptrarith-1.c   -O1  execution test
FAIL: gcc.dg/torture/pta-ptrarith-1.c   -O1   scan-tree-dump alias "ESCAPED = {[^\n}]* i f [^\n}]*}"
FAIL: gcc.dg/torture/pta-ptrarith-1.c   -O2  execution test
FAIL: gcc.dg/torture/pta-ptrarith-1.c   -O2 -flto -fno-use-linker-plugin -flto-partition=none  execution test
FAIL: gcc.dg/torture/pta-ptrarith-1.c   -O2 -flto -fno-use-linker-plugin -flto-partition=none   scan-tree-dump alias "ESCAPED = {[^\n}]* i f [^\n}]*}"
FAIL: gcc.dg/torture/pta-ptrarith-1.c   -O2   scan-tree-dump alias "ESCAPED = {[^\n}]* i f [^\n}]*}"
FAIL: gcc.dg/torture/pta-ptrarith-1.c   -O3 -g  execution test
FAIL: gcc.dg/torture/pta-ptrarith-1.c   -O3 -g   scan-tree-dump alias "ESCAPED = {[^\n}]* i f [^\n}]*}"
FAIL: gcc.dg/torture/pta-ptrarith-1.c   -Os  execution test
FAIL: gcc.dg/torture/pta-ptrarith-1.c   -Os   scan-tree-dump alias "ESCAPED = {[^\n}]* i f [^\n}]*}"

with GCC configured with

../../gcc/configure --prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r11-3641/usr --enable-clocale=gnu --with-system-zlib --with-demangler-in-ld --with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl --enable-libmpx x86_64-linux --disable-bootstrap

To reproduce:

$ cd {build_dir}/gcc && make check RUNTESTFLAGS="dg-torture.exp=gcc.dg/torture/pta-ptrarith-1.c --target_board='unix{-m32\ -march=cascadelake}'"

(Please do not reply to this email, for question about this report, contact me at skpgkp2 at gmail dot com)

Re: [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)

[Segher Boessenkool]

On Sat, Oct 03, 2020 at 12:21:04PM -0700, sunil.k.pandey via Gcc-patches wrote:
> On Linux/x86_64,
> 
> c34db4b6f8a5d80367c709309f9b00cb32630054 is the first bad commit
> commit c34db4b6f8a5d80367c709309f9b00cb32630054
> Author: Jan Hubicka <jh@suse.cz>
> Date:   Sat Oct 3 17:20:16 2020 +0200
> 
>     Track access ranges in ipa-modref
> 
> caused

[ ... ]

This isn't a patch.  Wrong mailing list?


Segher

Re: [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)

[H.J. Lu]

On Sat, Oct 3, 2020 at 5:57 PM Segher Boessenkool
<segher@kernel.crashing.org> wrote:
>
> On Sat, Oct 03, 2020 at 12:21:04PM -0700, sunil.k.pandey via Gcc-patches wrote:
> > On Linux/x86_64,
> >
> > c34db4b6f8a5d80367c709309f9b00cb32630054 is the first bad commit
> > commit c34db4b6f8a5d80367c709309f9b00cb32630054
> > Author: Jan Hubicka <jh@suse.cz>
> > Date:   Sat Oct 3 17:20:16 2020 +0200
> >
> >     Track access ranges in ipa-modref
> >
> > caused
>
> [ ... ]
>
> This isn't a patch.  Wrong mailing list?

I view this as a follow up of

https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555314.html

What do people think about this kind of followups?  Is this appropriate
for this mailing list?

-- 
H.J.

Re: [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)

[Iain Sandoe]

H.J. Lu via Gcc-patches <gcc-patches@gcc.gnu.org> wrote:

> On Sat, Oct 3, 2020 at 5:57 PM Segher Boessenkool
> <segher@kernel.crashing.org> wrote:
>> On Sat, Oct 03, 2020 at 12:21:04PM -0700, sunil.k.pandey via Gcc-patches  
>> wrote:
>>> On Linux/x86_64,
>>>
>>> c34db4b6f8a5d80367c709309f9b00cb32630054 is the first bad commit
>>> commit c34db4b6f8a5d80367c709309f9b00cb32630054
>>> Author: Jan Hubicka <jh@suse.cz>
>>> Date:   Sat Oct 3 17:20:16 2020 +0200
>>>
>>>    Track access ranges in ipa-modref
>>>
>>> caused
>>
>> [ ... ]
>>
>> This isn't a patch.  Wrong mailing list?
>
> I view this as a follow up of
>
> https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555314.html
>
> What do people think about this kind of followups?  Is this appropriate
> for this mailing list?

it seems quite noisy - and I wonder how effective; mailing list traffic  
goes by and is forgotten.

ISTM that a much neater solution would be to raise a BZ and add the commit  
author as CC’d

… but that might be too hard to implement?

Iain

Re: [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)

[H.J. Lu]

On Sun, Oct 4, 2020 at 10:03 AM Iain Sandoe <idsandoe@googlemail.com> wrote:
>
> H.J. Lu via Gcc-patches <gcc-patches@gcc.gnu.org> wrote:
>
> > On Sat, Oct 3, 2020 at 5:57 PM Segher Boessenkool
> > <segher@kernel.crashing.org> wrote:
> >> On Sat, Oct 03, 2020 at 12:21:04PM -0700, sunil.k.pandey via Gcc-patches
> >> wrote:
> >>> On Linux/x86_64,
> >>>
> >>> c34db4b6f8a5d80367c709309f9b00cb32630054 is the first bad commit
> >>> commit c34db4b6f8a5d80367c709309f9b00cb32630054
> >>> Author: Jan Hubicka <jh@suse.cz>
> >>> Date:   Sat Oct 3 17:20:16 2020 +0200
> >>>
> >>>    Track access ranges in ipa-modref
> >>>
> >>> caused
> >>
> >> [ ... ]
> >>
> >> This isn't a patch.  Wrong mailing list?
> >
> > I view this as a follow up of
> >
> > https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555314.html
> >
> > What do people think about this kind of followups?  Is this appropriate
> > for this mailing list?
>
> it seems quite noisy - and I wonder how effective; mailing list traffic
> goes by and is forgotten.

The email is sent out only when a commit causes a regression.
It is noisy only when a commit causes regressions in GCC testsuites.
We can make it less noisy by .......

> ISTM that a much neater solution would be to raise a BZ and add the commit
> author as CC’d
>
> … but that might be too hard to implement?

This email is generated by an automated script.  Does GCC BZ have
an email gateway?


-- 
H.J.

Re: [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)

[Martin Sebor]

On 10/4/20 10:51 AM, H.J. Lu via Gcc-patches wrote:
> On Sat, Oct 3, 2020 at 5:57 PM Segher Boessenkool
> <segher@kernel.crashing.org> wrote:
>>
>> On Sat, Oct 03, 2020 at 12:21:04PM -0700, sunil.k.pandey via Gcc-patches wrote:
>>> On Linux/x86_64,
>>>
>>> c34db4b6f8a5d80367c709309f9b00cb32630054 is the first bad commit
>>> commit c34db4b6f8a5d80367c709309f9b00cb32630054
>>> Author: Jan Hubicka <jh@suse.cz>
>>> Date:   Sat Oct 3 17:20:16 2020 +0200
>>>
>>>      Track access ranges in ipa-modref
>>>
>>> caused
>>
>> [ ... ]
>>
>> This isn't a patch.  Wrong mailing list?
> 
> I view this as a follow up of
> 
> https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555314.html
> 
> What do people think about this kind of followups?  Is this appropriate
> for this mailing list?

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.

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

Re: [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)

[H.J. Lu]

On Sun, Oct 4, 2020 at 10:33 AM Martin Sebor <msebor@gmail.com> wrote:
>
> On 10/4/20 10:51 AM, H.J. Lu via Gcc-patches wrote:
> > On Sat, Oct 3, 2020 at 5:57 PM Segher Boessenkool
> > <segher@kernel.crashing.org> wrote:
> >>
> >> On Sat, Oct 03, 2020 at 12:21:04PM -0700, sunil.k.pandey via Gcc-patches wrote:
> >>> On Linux/x86_64,
> >>>
> >>> c34db4b6f8a5d80367c709309f9b00cb32630054 is the first bad commit
> >>> commit c34db4b6f8a5d80367c709309f9b00cb32630054
> >>> Author: Jan Hubicka <jh@suse.cz>
> >>> Date:   Sat Oct 3 17:20:16 2020 +0200
> >>>
> >>>      Track access ranges in ipa-modref
> >>>
> >>> caused
> >>
> >> [ ... ]
> >>
> >> This isn't a patch.  Wrong mailing list?
> >
> > I view this as a follow up of
> >
> > https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555314.html
> >
> > What do people think about this kind of followups?  Is this appropriate
> > for this mailing list?
>
> 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.

> 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.

Re: [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)

[Sunil Pandey]

On Sun, Oct 4, 2020 at 10:41 AM H.J. Lu via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:

> On Sun, Oct 4, 2020 at 10:33 AM Martin Sebor <msebor@gmail.com> wrote:
> >
> > On 10/4/20 10:51 AM, H.J. Lu via Gcc-patches wrote:
> > > On Sat, Oct 3, 2020 at 5:57 PM Segher Boessenkool
> > > <segher@kernel.crashing.org> wrote:
> > >>
> > >> On Sat, Oct 03, 2020 at 12:21:04PM -0700, sunil.k.pandey via
> Gcc-patches wrote:
> > >>> On Linux/x86_64,
> > >>>
> > >>> c34db4b6f8a5d80367c709309f9b00cb32630054 is the first bad commit
> > >>> commit c34db4b6f8a5d80367c709309f9b00cb32630054
> > >>> Author: Jan Hubicka <jh@suse.cz>
> > >>> Date:   Sat Oct 3 17:20:16 2020 +0200
> > >>>
> > >>>      Track access ranges in ipa-modref
> > >>>
> > >>> caused
> > >>
> > >> [ ... ]
> > >>
> > >> This isn't a patch.  Wrong mailing list?
> > >
> > > I view this as a follow up of
> > >
> > > https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555314.html
> > >
> > > What do people think about this kind of followups?  Is this appropriate
> > > for this mailing list?
> >
> > 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.

>
> > 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.
>

Re: [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)

[Jan Hubicka]

> > >
> > > 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.
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.

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.
> >

Re: [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)

[Segher Boessenkool]

On Sun, Oct 04, 2020 at 09:51:23AM -0700, H.J. Lu wrote:
> On Sat, Oct 3, 2020 at 5:57 PM Segher Boessenkool
> <segher@kernel.crashing.org> wrote:
> > On Sat, Oct 03, 2020 at 12:21:04PM -0700, sunil.k.pandey via Gcc-patches wrote:
> > > On Linux/x86_64,
> > >
> > > c34db4b6f8a5d80367c709309f9b00cb32630054 is the first bad commit
> > > commit c34db4b6f8a5d80367c709309f9b00cb32630054
> > > Author: Jan Hubicka <jh@suse.cz>
> > > Date:   Sat Oct 3 17:20:16 2020 +0200
> > >
> > >     Track access ranges in ipa-modref
> > >
> > > caused
> >
> > [ ... ]
> >
> > This isn't a patch.  Wrong mailing list?
> 
> I view this as a follow up of
> 
> https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555314.html

But it *isn't* a follow-up of that mail.  That is my point.  Most of
these messages do not finger any particular patch even, I think?

> What do people think about this kind of followups?  Is this appropriate
> for this mailing list?

Please just use bugzilla.  And report bugs there the way they should be
reported: full command lines, full description of the errors, and
everything else needed to easily reproduce the problem.

*Actually* following up to the patch mail could be useful (but you can
than just point to the bugzilla).  Sending spam to gcc-patches@ is not
useful for most users of the list.


Segher

Re: [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)

[Joseph Myers]

On Sun, 4 Oct 2020, H.J. Lu via Gcc-patches wrote:

> This email is generated by an automated script.  Does GCC BZ have
> an email gateway?

Bugzilla has a REST API that you can use to interact with it via JSON 
messages over HTTP.  contrib/mark_spam.py has an example to mark bugs as 
spam.  glibc's scripts/list-fixed-bugs.py has an example extracting bug 
data for bugs matching a given search.  There are lots of other things you 
can do with that API, including filing new bugs.  (You probably want to 
make sure you e.g. only file one bug for a commit, not 1000 bugs for a 
commit that introduces 1000 test failures.)

https://bugzilla.readthedocs.io/en/latest/api/

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [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]

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

Re: [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)

[Jan Hubicka]

Hi,
this is fix I am testing (it solved the testcase)

gcc/ChangeLog:

2020-10-08  Jan Hubicka  <hubicka@ucw.cz>

	* ipa-modref.c (get_access): Fix handling of offsets.
	* tree-ssa-alias.c (modref_may_conflict): Watch for overflows.

diff --git a/gcc/ipa-modref.c b/gcc/ipa-modref.c
index a5fa33a35de..5868aa97484 100644
--- a/gcc/ipa-modref.c
+++ b/gcc/ipa-modref.c
@@ -318,8 +318,7 @@ get_access (ao_ref *ref)
 			  0, -1, false};
   if (TREE_CODE (base) == MEM_REF || TREE_CODE (base) == TARGET_MEM_REF)
     {
-      tree offset = TREE_CODE (base) == MEM_REF
-		    ? TREE_OPERAND (base, 1) : NULL_TREE;
+      tree memref = base;
       base = TREE_OPERAND (base, 0);
       if (TREE_CODE (base) == SSA_NAME
 	  && SSA_NAME_IS_DEFAULT_DEF (base)
@@ -336,8 +335,14 @@ get_access (ao_ref *ref)
 		}
 	      a.parm_index++;
 	    }
-	  a.parm_offset_known
-	    = offset && wi::to_poly_offset (offset).to_shwi (&a.parm_offset);
+	  if (TREE_CODE (memref) == MEM_REF)
+	    {
+	      a.parm_offset_known
+		 = wi::to_poly_wide (TREE_OPERAND
+					 (memref, 1)).to_shwi (&a.parm_offset);
+	    }
+	  else
+	    a.parm_offset_known = false;
 	}
       else
 	a.parm_index = -1;
diff --git a/gcc/tree-ssa-alias.c b/gcc/tree-ssa-alias.c
index 97dc4ac8814..d885f7157c5 100644
--- a/gcc/tree-ssa-alias.c
+++ b/gcc/tree-ssa-alias.c
@@ -2542,16 +2542,22 @@ modref_may_conflict (const gimple *stmt,
 	      else
 		{
 		  ao_ref ref2;
-
-		  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);
-		  ref2.ref_alias_set = ref_set;
-		  ref2.base_alias_set = base_set;
-		  if (refs_may_alias_p_1 (&ref2, ref, tbaa_p))
+		  poly_offset_int off = (poly_offset_int)access_node->offset
+			+ ((poly_offset_int)access_node->parm_offset
+			   << LOG2_BITS_PER_UNIT);
+		  poly_int64 off2;
+		  if (off.to_shwi (&off2))
+		    {
+		      ao_ref_init_from_ptr_and_range
+			     (&ref2, arg, true, off2,
+			      access_node->size,
+			      access_node->max_size);
+		      ref2.ref_alias_set = ref_set;
+		      ref2.base_alias_set = base_set;
+		      if (refs_may_alias_p_1 (&ref2, ref, tbaa_p))
+			return true;
+		    }
+		  else if (ptr_deref_may_alias_ref_p_1 (arg, ref))
 		    return true;
 		}
 	      num_tests++;

Re: [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]

On Thu, 8 Oct 2020, Jan Hubicka wrote:

> Hi,
> this is fix I am testing (it solved the testcase)

LGTM

> gcc/ChangeLog:
> 
> 2020-10-08  Jan Hubicka  <hubicka@ucw.cz>
> 
> 	* ipa-modref.c (get_access): Fix handling of offsets.
> 	* tree-ssa-alias.c (modref_may_conflict): Watch for overflows.
> 
> diff --git a/gcc/ipa-modref.c b/gcc/ipa-modref.c
> index a5fa33a35de..5868aa97484 100644
> --- a/gcc/ipa-modref.c
> +++ b/gcc/ipa-modref.c
> @@ -318,8 +318,7 @@ get_access (ao_ref *ref)
>  			  0, -1, false};
>    if (TREE_CODE (base) == MEM_REF || TREE_CODE (base) == TARGET_MEM_REF)
>      {
> -      tree offset = TREE_CODE (base) == MEM_REF
> -		    ? TREE_OPERAND (base, 1) : NULL_TREE;
> +      tree memref = base;
>        base = TREE_OPERAND (base, 0);
>        if (TREE_CODE (base) == SSA_NAME
>  	  && SSA_NAME_IS_DEFAULT_DEF (base)
> @@ -336,8 +335,14 @@ get_access (ao_ref *ref)
>  		}
>  	      a.parm_index++;
>  	    }
> -	  a.parm_offset_known
> -	    = offset && wi::to_poly_offset (offset).to_shwi (&a.parm_offset);
> +	  if (TREE_CODE (memref) == MEM_REF)
> +	    {
> +	      a.parm_offset_known
> +		 = wi::to_poly_wide (TREE_OPERAND
> +					 (memref, 1)).to_shwi (&a.parm_offset);
> +	    }
> +	  else
> +	    a.parm_offset_known = false;
>  	}
>        else
>  	a.parm_index = -1;
> diff --git a/gcc/tree-ssa-alias.c b/gcc/tree-ssa-alias.c
> index 97dc4ac8814..d885f7157c5 100644
> --- a/gcc/tree-ssa-alias.c
> +++ b/gcc/tree-ssa-alias.c
> @@ -2542,16 +2542,22 @@ modref_may_conflict (const gimple *stmt,
>  	      else
>  		{
>  		  ao_ref ref2;
> -
> -		  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);
> -		  ref2.ref_alias_set = ref_set;
> -		  ref2.base_alias_set = base_set;
> -		  if (refs_may_alias_p_1 (&ref2, ref, tbaa_p))
> +		  poly_offset_int off = (poly_offset_int)access_node->offset
> +			+ ((poly_offset_int)access_node->parm_offset
> +			   << LOG2_BITS_PER_UNIT);
> +		  poly_int64 off2;
> +		  if (off.to_shwi (&off2))
> +		    {
> +		      ao_ref_init_from_ptr_and_range
> +			     (&ref2, arg, true, off2,
> +			      access_node->size,
> +			      access_node->max_size);
> +		      ref2.ref_alias_set = ref_set;
> +		      ref2.base_alias_set = base_set;
> +		      if (refs_may_alias_p_1 (&ref2, ref, tbaa_p))
> +			return true;
> +		    }
> +		  else if (ptr_deref_may_alias_ref_p_1 (arg, ref))
>  		    return true;
>  		}
>  	      num_tests++;
> 

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

Re: [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 Sandiford]

Martin Sebor via Gcc-patches <gcc-patches@gcc.gnu.org> writes:
> On 10/4/20 10:51 AM, H.J. Lu via Gcc-patches wrote:
>> On Sat, Oct 3, 2020 at 5:57 PM Segher Boessenkool
>> <segher@kernel.crashing.org> wrote:
>>>
>>> On Sat, Oct 03, 2020 at 12:21:04PM -0700, sunil.k.pandey via Gcc-patches wrote:
>>>> On Linux/x86_64,
>>>>
>>>> c34db4b6f8a5d80367c709309f9b00cb32630054 is the first bad commit
>>>> commit c34db4b6f8a5d80367c709309f9b00cb32630054
>>>> Author: Jan Hubicka <jh@suse.cz>
>>>> Date:   Sat Oct 3 17:20:16 2020 +0200
>>>>
>>>>      Track access ranges in ipa-modref
>>>>
>>>> caused
>>>
>>> [ ... ]
>>>
>>> This isn't a patch.  Wrong mailing list?
>> 
>> I view this as a follow up of
>> 
>> https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555314.html
>> 
>> What do people think about this kind of followups?  Is this appropriate
>> for this mailing list?
>
> 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.

+1 FWIW.  I think it's great that we have this kind of automatic CI, and
this seems like a natural place to send the reports.  Shovelling them into
bugzilla is likely to create more work rather than less, especially since
the fix turnaround should (hopefully) be short.

Richard

Re: [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)

[Christophe Lyon]

On Mon, 5 Oct 2020 at 17:19, Segher Boessenkool
<segher@kernel.crashing.org> wrote:
>
> On Sun, Oct 04, 2020 at 09:51:23AM -0700, H.J. Lu wrote:
> > On Sat, Oct 3, 2020 at 5:57 PM Segher Boessenkool
> > <segher@kernel.crashing.org> wrote:
> > > On Sat, Oct 03, 2020 at 12:21:04PM -0700, sunil.k.pandey via Gcc-patches wrote:
> > > > On Linux/x86_64,
> > > >
> > > > c34db4b6f8a5d80367c709309f9b00cb32630054 is the first bad commit
> > > > commit c34db4b6f8a5d80367c709309f9b00cb32630054
> > > > Author: Jan Hubicka <jh@suse.cz>
> > > > Date:   Sat Oct 3 17:20:16 2020 +0200
> > > >
> > > >     Track access ranges in ipa-modref
> > > >
> > > > caused
> > >
> > > [ ... ]
> > >
> > > This isn't a patch.  Wrong mailing list?
> >
> > I view this as a follow up of
> >
> > https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555314.html
>
> But it *isn't* a follow-up of that mail.  That is my point.  Most of
> these messages do not finger any particular patch even, I think?
>

That's why I kept the reporting part manual on my side: once you know
which commit introduced a failure/regression (either via bisect, or by
some other way), it's not always easy to identify the gcc-patches
message to which you want to reply.
And as already said in this thread, we certainly want to avoid sending
a regression email for each test, multiplied by the number of
configurations under test.

> > What do people think about this kind of followups?  Is this appropriate
> > for this mailing list?
>
> Please just use bugzilla.  And report bugs there the way they should be
> reported: full command lines, full description of the errors, and
> everything else needed to easily reproduce the problem.
>
It seems some people prefer such regressions reports in bugzilla,
others in gcc-patches@.

In general when I report a regression I noticed in the GCC testsuite,
I tend to assume that the testname and GCC configure options are
sufficient for a usual contributor to reproduce.
Not sure if it matches "full" and "easily" in your mind?

With all the automated builds where the build dir is removed from the
server at the end whatever the result, it does take time if I have to
reproduce the problem manually before reporting.

Christophe

> *Actually* following up to the patch mail could be useful (but you can
> than just point to the bugzilla).  Sending spam to gcc-patches@ is not
> useful for most users of the list.
>
>
> Segher

Re: [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]

On Mon, Oct 12, 2020 at 3:27 PM Christophe Lyon via Gcc-patches
<gcc-patches@gcc.gnu.org> wrote:
>
> On Mon, 5 Oct 2020 at 17:19, Segher Boessenkool
> <segher@kernel.crashing.org> wrote:
> >
> > On Sun, Oct 04, 2020 at 09:51:23AM -0700, H.J. Lu wrote:
> > > On Sat, Oct 3, 2020 at 5:57 PM Segher Boessenkool
> > > <segher@kernel.crashing.org> wrote:
> > > > On Sat, Oct 03, 2020 at 12:21:04PM -0700, sunil.k.pandey via Gcc-patches wrote:
> > > > > On Linux/x86_64,
> > > > >
> > > > > c34db4b6f8a5d80367c709309f9b00cb32630054 is the first bad commit
> > > > > commit c34db4b6f8a5d80367c709309f9b00cb32630054
> > > > > Author: Jan Hubicka <jh@suse.cz>
> > > > > Date:   Sat Oct 3 17:20:16 2020 +0200
> > > > >
> > > > >     Track access ranges in ipa-modref
> > > > >
> > > > > caused
> > > >
> > > > [ ... ]
> > > >
> > > > This isn't a patch.  Wrong mailing list?
> > >
> > > I view this as a follow up of
> > >
> > > https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555314.html
> >
> > But it *isn't* a follow-up of that mail.  That is my point.  Most of
> > these messages do not finger any particular patch even, I think?
> >
>
> That's why I kept the reporting part manual on my side: once you know
> which commit introduced a failure/regression (either via bisect, or by
> some other way), it's not always easy to identify the gcc-patches
> message to which you want to reply.
> And as already said in this thread, we certainly want to avoid sending
> a regression email for each test, multiplied by the number of
> configurations under test.

Definitely.

> > > What do people think about this kind of followups?  Is this appropriate
> > > for this mailing list?
> >
> > Please just use bugzilla.  And report bugs there the way they should be
> > reported: full command lines, full description of the errors, and
> > everything else needed to easily reproduce the problem.
> >
> It seems some people prefer such regressions reports in bugzilla,
> others in gcc-patches@.

We also want to avoid reporting a bug for each test, multiplied by the
number of configurations under test.

> In general when I report a regression I noticed in the GCC testsuite,
> I tend to assume that the testname and GCC configure options are
> sufficient for a usual contributor to reproduce.
> Not sure if it matches "full" and "easily" in your mind?
>
> With all the automated builds where the build dir is removed from the
> server at the end whatever the result, it does take time if I have to
> reproduce the problem manually before reporting.

And that's IMHO and important step - the human sanitizing of the
report - eventually checking the issue isn't already fixed or reported.

Richard.

>
> Christophe
>
> > *Actually* following up to the patch mail could be useful (but you can
> > than just point to the bugzilla).  Sending spam to gcc-patches@ is not
> > useful for most users of the list.
> >
> >
> > Segher

Re: [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)

[Segher Boessenkool]

On Mon, Oct 12, 2020 at 01:24:44PM +0100, Richard Sandiford wrote:
> Martin Sebor via Gcc-patches <gcc-patches@gcc.gnu.org> writes:
> > On 10/4/20 10:51 AM, H.J. Lu via Gcc-patches wrote:
> >> On Sat, Oct 3, 2020 at 5:57 PM Segher Boessenkool
> >> <segher@kernel.crashing.org> wrote:
> >>>
> >>> On Sat, Oct 03, 2020 at 12:21:04PM -0700, sunil.k.pandey via Gcc-patches wrote:
> >>>> On Linux/x86_64,
> >>>>
> >>>> c34db4b6f8a5d80367c709309f9b00cb32630054 is the first bad commit
> >>>> commit c34db4b6f8a5d80367c709309f9b00cb32630054
> >>>> Author: Jan Hubicka <jh@suse.cz>
> >>>> Date:   Sat Oct 3 17:20:16 2020 +0200
> >>>>
> >>>>      Track access ranges in ipa-modref
> >>>>
> >>>> caused
> >>>
> >>> [ ... ]
> >>>
> >>> This isn't a patch.  Wrong mailing list?
> >> 
> >> I view this as a follow up of
> >> 
> >> https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555314.html
> >> 
> >> What do people think about this kind of followups?  Is this appropriate
> >> for this mailing list?
> >
> > 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.
> 
> +1 FWIW.  I think it's great that we have this kind of automatic CI, and
> this seems like a natural place to send the reports.  Shovelling them into
> bugzilla is likely to create more work rather than less, especially since
> the fix turnaround should (hopefully) be short.

But send them as reply to the patch discussion then!


Segher

Re: [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)

[Segher Boessenkool]

On Mon, Oct 12, 2020 at 03:26:38PM +0200, Christophe Lyon wrote:
> That's why I kept the reporting part manual on my side: once you know
> which commit introduced a failure/regression (either via bisect, or by
> some other way), it's not always easy to identify the gcc-patches
> message to which you want to reply.

But it *should* be: the check-in subject should be in the patch mail, or
failing that, at least the changelog entries should be!

> > > What do people think about this kind of followups?  Is this appropriate
> > > for this mailing list?
> >
> > Please just use bugzilla.  And report bugs there the way they should be
> > reported: full command lines, full description of the errors, and
> > everything else needed to easily reproduce the problem.
> >
> It seems some people prefer such regressions reports in bugzilla,
> others in gcc-patches@.

If it will be resolved quickly, and by just telling the author, email is
fine of course.  Otherwise, you need bugzilla.

> In general when I report a regression I noticed in the GCC testsuite,
> I tend to assume that the testname and GCC configure options are
> sufficient for a usual contributor to reproduce.
> Not sure if it matches "full" and "easily" in your mind?

Tests are often ran with multiple sets of options.  If you give enough
info that people can reproduce your configuration (hint: most bug
reports do *not*), all is fine of course.  But in general we *do* need
all info (as documented in the bug reporting instructions), or we get
a frustrating "I cannot reproduce this" game.

> With all the automated builds where the build dir is removed from the
> server at the end whatever the result, it does take time if I have to
> reproduce the problem manually before reporting.

Yes, and it is *easier* to reproduce for you than for other people!

> > *Actually* following up to the patch mail could be useful (but you can
> > than just point to the bugzilla).  Sending spam to gcc-patches@ is not
> > useful for most users of the list.

^^^ Still my main point.


Segher

Re: [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)

[Christophe Lyon]

On Mon, 12 Oct 2020 at 18:43, Segher Boessenkool
<segher@kernel.crashing.org> wrote:
>
> On Mon, Oct 12, 2020 at 03:26:38PM +0200, Christophe Lyon wrote:
> > That's why I kept the reporting part manual on my side: once you know
> > which commit introduced a failure/regression (either via bisect, or by
> > some other way), it's not always easy to identify the gcc-patches
> > message to which you want to reply.
>
> But it *should* be: the check-in subject should be in the patch mail, or
> failing that, at least the changelog entries should be!

Well, for instance I've just reported that a newly introduced testcase
is failing on arm, aarch64 and other platforms.

It's easy to know which commit introduced the problem, since it's a
new test: r11-3827.

When looking for the email thread to which I want to send a reply, I
search my mailbox
for "Wstringop-overflow-47.c", which points me to a thread titled
"correct handling of indices into arrays with elements larger than 1
(PR c++/96511)"
with several iterations, and several sets of patches.

The offending commit has "Generalize compute_objsize to return maximum
size/offset instead of failing (PR middle-end/97023)"
as title, so it's not obvious that this is really the right thread
(and since the patches were attached, gmail does not display them
inline, so I have to open them and check if the one I'm looking for is
really there)

It's not super-long to do, but I feel it's more effort than should be
needed for such a simple case.

>
> > > > What do people think about this kind of followups?  Is this appropriate
> > > > for this mailing list?
> > >
> > > Please just use bugzilla.  And report bugs there the way they should be
> > > reported: full command lines, full description of the errors, and
> > > everything else needed to easily reproduce the problem.
> > >
> > It seems some people prefer such regressions reports in bugzilla,
> > others in gcc-patches@.
>
> If it will be resolved quickly, and by just telling the author, email is
> fine of course.  Otherwise, you need bugzilla.
>
In the above case, I was tempted to open a bugzilla, I would have had
to dig less in my email archives, but since many targets are concerned,
I hope it's obvious enough that the fix will be easy. YMMV.

> > In general when I report a regression I noticed in the GCC testsuite,
> > I tend to assume that the testname and GCC configure options are
> > sufficient for a usual contributor to reproduce.
> > Not sure if it matches "full" and "easily" in your mind?
>
> Tests are often ran with multiple sets of options.  If you give enough
> info that people can reproduce your configuration (hint: most bug
> reports do *not*), all is fine of course.  But in general we *do* need
> all info (as documented in the bug reporting instructions), or we get
> a frustrating "I cannot reproduce this" game.
>
> > With all the automated builds where the build dir is removed from the
> > server at the end whatever the result, it does take time if I have to
> > reproduce the problem manually before reporting.
>
> Yes, and it is *easier* to reproduce for you than for other people!
>
> > > *Actually* following up to the patch mail could be useful (but you can
> > > than just point to the bugzilla).  Sending spam to gcc-patches@ is not
> > > useful for most users of the list.
>
> ^^^ Still my main point.
>
>
> Segher

Re: [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)

[Segher Boessenkool]

Hi!

On Tue, Oct 13, 2020 at 11:58:11AM +0200, Christophe Lyon wrote:
> On Mon, 12 Oct 2020 at 18:43, Segher Boessenkool
> <segher@kernel.crashing.org> wrote:
> >
> > On Mon, Oct 12, 2020 at 03:26:38PM +0200, Christophe Lyon wrote:
> > > That's why I kept the reporting part manual on my side: once you know
> > > which commit introduced a failure/regression (either via bisect, or by
> > > some other way), it's not always easy to identify the gcc-patches
> > > message to which you want to reply.
> >
> > But it *should* be: the check-in subject should be in the patch mail, or
> > failing that, at least the changelog entries should be!
> 
> Well, for instance I've just reported that a newly introduced testcase
> is failing on arm, aarch64 and other platforms.
> 
> It's easy to know which commit introduced the problem, since it's a
> new test: r11-3827.
> 
> When looking for the email thread to which I want to send a reply, I
> search my mailbox
> for "Wstringop-overflow-47.c", which points me to a thread titled
> "correct handling of indices into arrays with elements larger than 1
> (PR c++/96511)"
> with several iterations, and several sets of patches.
> 
> The offending commit has "Generalize compute_objsize to return maximum
> size/offset instead of failing (PR middle-end/97023)"
> as title, so it's not obvious that this is really the right thread
> (and since the patches were attached, gmail does not display them
> inline, so I have to open them and check if the one I'm looking for is
> really there)
> 
> It's not super-long to do, but I feel it's more effort than should be
> needed for such a simple case.

This should be easier, yes.  But simply not doing it is pushing this
work onto everyone else!  (Except the people who will just delete these
mails because they aren't useful for them at all in this form.)

> > > It seems some people prefer such regressions reports in bugzilla,
> > > others in gcc-patches@.
> >
> > If it will be resolved quickly, and by just telling the author, email is
> > fine of course.  Otherwise, you need bugzilla.
> >
> In the above case, I was tempted to open a bugzilla, I would have had
> to dig less in my email archives, but since many targets are concerned,
> I hope it's obvious enough that the fix will be easy. YMMV.

And it differs per case; it needs human judgment.

> > > > *Actually* following up to the patch mail could be useful (but you can
> > > > than just point to the bugzilla).  Sending spam to gcc-patches@ is not
> > > > useful for most users of the list.
> >
> > ^^^ Still my main point.


Segher