[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