On Mon, 5 Oct 2020 at 17:19, Segher Boessenkool <seg...@kernel.crashing.org> 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 > > <seg...@kernel.crashing.org> 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 <j...@suse.cz> > > > > 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
