On Mon, Oct 12, 2020 at 3:27 PM Christophe Lyon via Gcc-patches <gcc-patches@gcc.gnu.org> wrote: > > 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.
Definitely. > > > 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@. We also want to avoid reporting a bug for each test, multiplied by the number of configurations under test. > 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. And that's IMHO and important step - the human sanitizing of the report - eventually checking the issue isn't already fixed or reported. Richard. > > 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
