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)
Hi! On Tue, Oct 13, 2020 at 11:58:11AM +0200, Christophe Lyon wrote: > On Mon, 12 Oct 2020 at 18:43, Segher Boessenkool > 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
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)
On Mon, 12 Oct 2020 at 18:43, Segher Boessenkool 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)
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)
On Mon, Oct 12, 2020 at 01:24:44PM +0100, Richard Sandiford wrote: > Martin Sebor via Gcc-patches 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 > >> 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 > 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)
On Mon, Oct 12, 2020 at 3:27 PM Christophe Lyon via Gcc-patches wrote: > > On Mon, 5 Oct 2020 at 17:19, Segher Boessenkool > 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 > > > 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 > > > > > 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)
On Mon, 5 Oct 2020 at 17:19, Segher Boessenkool 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 > > 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 > > > > 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)
Martin Sebor via Gcc-patches 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 >> 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 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)
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 > > * 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 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)
Hi, this is fix I am testing (it solved the testcase) gcc/ChangeLog: 2020-10-08 Jan Hubicka * 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)
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 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)
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 jos...@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)
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 > 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 > > > 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)
> > > > > > 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)
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 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 > > > 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 > > >>> 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)
On Sun, Oct 4, 2020 at 10:33 AM Martin Sebor 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 > > 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 > >>> 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)
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 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 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)
On Sun, Oct 4, 2020 at 10:03 AM Iain Sandoe wrote: > > H.J. Lu via Gcc-patches wrote: > > > On Sat, Oct 3, 2020 at 5:57 PM Segher Boessenkool > > 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 > >>> 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)
H.J. Lu via Gcc-patches wrote: On Sat, Oct 3, 2020 at 5:57 PM Segher Boessenkool 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 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)
On Sat, Oct 3, 2020 at 5:57 PM Segher Boessenkool 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 > > 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)
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 > 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
[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)
On Linux/x86_64, c34db4b6f8a5d80367c709309f9b00cb32630054 is the first bad commit commit c34db4b6f8a5d80367c709309f9b00cb32630054 Author: Jan Hubicka 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)