[PATCH 1/9] gensupport: Fix define_subst operand renumbering.

James Greenhalgh james.greenhalgh@arm.com
Tue Mar 1 12:15:00 GMT 2016


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.

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  <krebbel@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-
> 



More information about the Gcc-patches mailing list