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.
Thanks,
James
> >
> > The failures are of this form:
> >
> > In file included from
> > /data/work/gcc-bisect-bot/build/gcc/include/immintrin.h:45:0,
> > from
> > /work/gcc-bisect-bot/gcc/gcc/testsuite/gcc.target/i386/avx512f-vfnmsubXXXps-1.c:12:
> > /data/work/gcc-bisect-bot/build/gcc/include/avx512fintrin.h: In function
> > 'avx512f_test':
> > /data/work/gcc-bisect-bot/build/gcc/include/avx512fintrin.h:11666:10:
> > internal compiler error: Segmentation fault
> > 0xb1a18f crash_signal
> > /work/gcc-bisect-bot/gcc/gcc/toplev.c:335
> > Please submit a full bug report,
> > with preprocessed source if appropriate.
> > Please include the complete backtrace with any bug report.
> > See <http://gcc.gnu.org/bugs.html> for instructions.
> >
> > There are lots of them, so I'm just mentioning the unique names below.
> >
> > gcc.target/i386/avx512f-vfmaddsubXXXps-2.c
> > gcc.target/i386/avx512f-vfmsubaddXXXps-2.c
> > gcc.target/i386/avx512f-vfnmsubXXXps-2.c
> > gcc.target/i386/avx512f-vfnmsubXXXps-1.c
> > gcc.target/i386/avx-2.c
> > gcc.target/i386/avx512vl-vshufpd-1.c
> > gcc.target/i386/avx512f-vfmsubXXXpd-2.c
> > gcc.target/i386/avx-1.c
> > gcc.target/i386/avx512f-vfixupimmsd-1.c
> > gcc.target/i386/avx512f-vfmsubXXXps-1.c
> > gcc.target/i386/avx512f-vfmsubaddXXXpd-2.c
> > gcc.target/i386/avx512f-vfmsubXXXps-2.c
> > gcc.target/i386/avx512vl-vshufps-1.c
> > gcc.target/i386/avx512f-vfmaddsubXXXps-1.c
> > gcc.target/i386/avx512f-vfixupimmsd-2.c
> > gcc.target/i386/avx512f-vfmaddXXXps-1.c
> > gcc.target/i386/avx512f-vfmaddsubXXXpd-1.c
> > gcc.target/i386/avx512f-vfmaddXXXpd-2.c
> > gcc.target/i386/avx512f-vfmaddXXXps-2.c
> > gcc.target/i386/avx512f-vfmaddsubXXXpd-2.c
> > gcc.target/i386/sse-22.c
> > gcc.target/i386/avx512f-vfmsubXXXpd-1.c
> > gcc.target/i386/testround-1.c
> > gcc.target/i386/sse-23.c
> > gcc.target/i386/avx512f-vfmsubaddXXXpd-1.c
> > gcc.target/i386/sse-22a.c
> > gcc.target/i386/sse-25.c
> > gcc.target/i386/sse-24.c
> > gcc.target/i386/avx512f-vfnmsubXXXpd-2.c
> > gcc.target/i386/sse-14.c
> > gcc.target/i386/avx512f-vfixupimmss-1.c
> > gcc.target/i386/avx512f-vfnmaddXXXpd-1.c
> > gcc.target/i386/avx512f-vfnmaddXXXps-2.c
> > gcc.target/i386/avx512f-vfixupimmpd-2.c
> > gcc.target/i386/avx512f-vfnmaddXXXpd-2.c
> > gcc.target/i386/sse-13.c
> > gcc.target/i386/avx512f-vfixupimmps-1.c
> > gcc.target/i386/avx512f-vfnmsubXXXpd-1.c
> > gcc.target/i386/avx512f-vfnmaddXXXps-1.c
> > gcc.target/i386/avx512f-vfixupimmps-2.c
> > gcc.target/i386/avx512f-vfmaddXXXpd-1.c
> > gcc.target/i386/testimm-10.c
> > gcc.target/i386/avx512f-vfmsubaddXXXps-1.c
> > gcc.target/i386/avx512f-vfixupimmss-2.c
> > gcc.target/i386/avx512f-vfixupimmpd-1.c
> >
> > Author: krebbel <krebbel@138bc75d-0d04-0410-961f-82ee72b054a4>
> > Date: Tue Mar 1 09:19:14 2016 +0000
> >
> > gensupport: Fix define_subst operand renumbering.
> >
> > When processing substitutions the operands are renumbered. To find a
> > free operand number the array used_operands_numbers is used.
> > Currently this array is used to assign new numbers before all the
> > RTXes in the vector have been processed. I did run into problems with
> > this for insns where a match_dup occurred in a later (use ...) operand
> > referring to an earlier operand (e.g. s390.md "setmem_long").
> >
> > The patch splits the loop doing the processing into two in order to
> > have all the operand numbers collected already when assigning new
> > numbers.
> >
> > gcc/ChangeLog:
> >
> > 2016-03-01 Andreas Krebbel <kreb...@linux.vnet.ibm.com>
> >
> > * 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.
> >
> > svn+ssh://gcc.gnu.org/svn/gcc/trunk@233841
> >
> > Thanks,
> > James
> >
> >>
> >> -Andreas-
> >>
> >
>
