CCing the list again. On Mon, 29 Oct 2018 at 22:13, nick <xerofoify@xxxxxxxxx> wrote: > > > > On 2018-10-29 5:45 p.m., Jonathan Wakely wrote: > > On Mon, 29 Oct 2018 at 21:40, nick <xerofoify@xxxxxxxxx> wrote: > >> > >> > >> > >> On 2018-10-29 4:44 p.m., Jonathan Wakely wrote: > >>> Please reply to the mailing list, not just to me. > >>> > >>> > >> Sorry thought it was sent to the list. > >> > >> Nick > >>> On Mon, 29 Oct 2018 at 20:14, nick <xerofoify@xxxxxxxxx> wrote: > >>>> > >>>> > >>>> > >>>> On 2018-10-29 3:31 p.m., Jonathan Wakely wrote: > >>>>> On Mon, 29 Oct 2018 at 18:05, nick <xerofoify@xxxxxxxxx> wrote: > >>>>>> > >>>>>> Greetings, > >>>>>> > >>>>>> I just build,configuring and ran the tests from the upstream gcc git repo like this: > >>>>>> mdkir odbjir > >>>>>> cd obdjir > >>>>>> $PWD/../gcc/configure --prefix=$HOME/GCC-deve > >>>>>> make -j8 > >>>>>> make bootstrapq > >>>>> > >>>>> This is redundant, just saying "make" does the same thing. > >>>>> > >>>>>> make -k check > >>>>>> > >>>>>> Those are the steps from the offical docs unless I am missing a step i.e. does > >>>>>> make install need to be done or not? > >>>>> > >>>>> Done for what? It needs to be done to install the compiler you just > >>>>> built, but not to test it. > >>>>> > >>>>>> Don't know if this a reported issue or not. > >>>>> > >>>>> You haven't said what the issue is, so we can't say. > >>>>> > >>>> Jonathan, > >>>> The issues is after the above commands including make -k check it fails the tests on > >>>> on a Ubuntu 18.04, x86_64_gnu based system for the mainline git repo. > > > > Which tests? All of them? More than half of them? You're really not > > giving us much to go on here. > > > > You can compare your results with other people's results for recent > > trunk builds at https://gcc.gnu.org/ml/gcc-testresults/2018-10/ > > > > For recent x86_64-pc-linux-gnu builds I see about 0.1% of tests > > failing (a few for the compiler, and a few for libstdc++). > > > > It's not unusual for there to be a few failures at this point in the > > development cycle. If you want a stable compiler with no issues, don't > > use the development trunk. > > > > Sure I was aware of that and seems so after checking the build logs, thanks for those. > Anyhow my last question is I fixed a bug and was wondering if even with failing tests > before the patch was applied i.e. a clean gcc tree will it be able to be merged or > not as that's the standard I was aware of for patches. If tests are failing without your patch, you don't need to worry about them. You're looking for changes caused by your patch, not pre-existing failures. This is documented at https://gcc.gnu.org/contribute.html#testing "You must also perform regression tests to ensure that your patch does not break anything else. Typically, this means comparing post-patch test results to pre-patch results by testing twice or comparing with recent posts to the gcc-testresults list." If there had to be zero test failures before any patch is committed then there wouldn't be dozens of commits per day: https://gcc.gnu.org/ml/gcc-cvs/2018-10/
