[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 segher@kernel.crashing.org
Mon Oct 12 16:40:08 GMT 2020


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


More information about the Gcc-regression mailing list