On Mon, 12 Oct 2020 at 18:43, Segher Boessenkool <seg...@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
