[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