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? Sorry for the breakage. I'll revert the patch together with the affected parts of my S/390 patchset. I'll just need a couple of hours to re-test on S/390. Bye, -Andreas- > > 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- >> >
