On 03/01/2016 02:38 PM, James Greenhalgh wrote: > On Tue, Mar 01, 2016 at 01:35:18PM +0100, Andreas Krebbel wrote: >> On 03/01/2016 01:15 PM, James Greenhalgh wrote: >>> On Tue, Mar 01, 2016 at 10:29:28AM +0100, Andreas Krebbel wrote: >>>> On 02/29/2016 02:36 PM, Bernd Schmidt wrote: >>>>> On 02/29/2016 09:46 AM, Andreas Krebbel wrote: >>>>>> Ok for mainline? >>>>>> >>>>>> * gensupport.c (process_substs_on_one_elem): Split loop to >>>>>> complete mark_operands_used_in_match_dup on all expressions in the >>>>>> vector first. >>>>>> (adjust_operands_numbers): Inline into process_substs_on_one_elem >>>>>> and remove function. >>>>> >>>>> Didn't I approve this a while ago? Not sure it's appropriate for stage4 >>>>> though; is this series fixing an important regression? >>>> >>>> Yes you did. I didn't commit it until the rest of the patch series was >>>> ready to commit. The patch >>>> series fixes a fundamental problem in the backend. The first iteration was >>>> posted before stage 4 but >>>> it took me a few iterations to get it right. >>>> >>>> I've committed the patch now after retesting. >>> >>> This looks like it has caused failures in the following tests on an >>> x86_64-none-linux-gnu build. >> >> I've regression tested the patch on x86_64 as well. Are there specific >> options required to enable these tests? > > The bisect robot just builds a stage one compiler, configured with: > > ./configure --disable-bootstrap, --enable-languages=c,c++,fortran > --disable-multilib --disable-libsanitizer > > My system GCC is a 5.2 from the release sources with: > > ../gcc-5.2.0/configure --with-bugurl='Good luck' > --enable-languages=c,c++,go,fortran,objc,obj-c++ > --prefix=/work/install-gcc-5.2.0 --enable-shared > --enable-linker-build-id --without-included-gettext > --enable-threads=posix --enable-nls > --enable-clocale=gnu --enable-libstdcxx-debug > --enable-libstdcxx-time=yes > --enable-gnu-unique-object --disable-libmudflap > --enable-plugin --with-system-zlib > --disable-browser-plugin --enable-java-awt=gtk > --enable-gtk-cairo --with-arch-directory=amd64 > --enable-objc-gc --enable-multiarch > --disable-werror --with-arch-32=i686 > --with-abi=m64 --with-multilib-list=m32,m64,mx32 > --with-tune=native --enable-checking=release > --build=x86_64-linux-gnu --host=x86_64-linux-gnu > --target=x86_64-linux-gnu > > I tried a full bootstrap at that revision and still see these failures. > Who knows what state has been corrupted, or that you silently get away with, > if this is an undefined behaviour somewhere :-). I haven't tried with a > valgrind checking build to see what it can spot.
Ok. Thanks for the infos. I'll try to have a look. I've reverted the patch now. Bye, -Andreas-
