Re: [PATCH] Fix loop interchange ICE on bitfields (PR tree-optimization/83337)

On December 9, 2017 11:08:18 PM GMT+01:00, Jakub Jelinek wrote: >Hi! > >compute_access_stride does: > tree ref = DR_REF (dr); > tree scev_base = build_fold_addr_expr (ref); >but that really isn't valid for bitfield drs, where we can't take >addresses >of the bitfield. >As I

[13/13] [AArch64] Use vec_perm_indices helper routines

This patch makes the AArch64 vec_perm_const code use the new vec_perm_indices routines, instead of checking each element individually. This means that they extend naturally to variable-length vectors. Also, aarch64_evpc_dup was the only function that generated rtl when testing_p is true, and that

[12/13] Use ssizetype selectors for autovectorised VEC_PERM_EXPRs

The previous patches mean that there's no reason that constant VEC_PERM_EXPRs need to have the same shape as the data inputs. This patch makes the autovectoriser use ssizetype elements instead, so that indices don't get truncated for large or variable-length vectors. 2017-12-09 Richard

[11/13] Use vec_perm_builder::series_p in shift_amt_for_vec_perm_mask

This patch makes shift_amt_for_vec_perm_mask use series_p to check for the simple case of a natural linear series before falling back to testing each element individually. The series_p test works with variable-length vectors but testing every individual element doesn't. 2017-12-09 Richard

[10/13] Rework VEC_PERM_EXPR folding

This patch reworks the VEC_PERM_EXPR folding so that more of it works for variable-length vectors. E.g. it means that we can now recognise variable-length permutes that reduce to a single vector, or cases in which a variable-length permute only needs one input. There should be no functional

[09/13] Use explicit encodings for simple permutes

This patch makes users of vec_perm_builders use the compressed encoding where possible. This means that they work with variable-length vectors. 2017-12-09 Richard Sandiford gcc/ * optabs.c (expand_vec_perm_var): Use an explicit encoding for the

[08/13] Add a vec_perm_indices_to_tree helper function

This patch adds a function for creating a VECTOR_CST from a vec_perm_indices, operating directly on the encoding. 2017-12-09 Richard Sandiford gcc/ * vec-perm-indices.h (vec_perm_indices_to_tree): Declare. * vec-perm-indices.c

[07/13] Make vec_perm_indices use new vector encoding

This patch changes vec_perm_indices from a plain vec<> to a class that stores a canonicalised permutation, using the same encoding as for VECTOR_CSTs. This means that vec_perm_indices now carries information about the number of vectors being permuted (currently always 1 or 2) and the number of

[06/13] Check whether a vector of QIs can store all indices

The patch to remove the vec_perm_const optab checked whether replacing a constant permute with a variable permute is safe, or whether it might truncate the indices. This patch adds a corresponding check for whether variable permutes can be lowered to QImode-based permutes. 2017-12-09 Richard

[05/13] Remove vec_perm_const optab

One of the changes needed for variable-length VEC_PERM_EXPRs -- and for long fixed-length VEC_PERM_EXPRs -- is the ability to use constant selectors that wouldn't fit in the vectors being permuted. E.g. a permute on two V256QIs can't be done using a V256QI selector. At the moment constant

[04/13] Refactor expand_vec_perm

This patch splits the variable handling out of expand_vec_perm into a subroutine, so that the next patch can use a different interface for expanding constant permutes. expand_vec_perm now does all the CONST_VECTOR handling directly and defers to expand_vec_perm_var for other rtx codes. Handling

[03/13] Split can_vec_perm_p into can_vec_perm_{var,const}_p

This patch splits can_vec_perm_p into two functions: can_vec_perm_var_p for testing permute operations with variable selection vectors, and can_vec_perm_const_p for testing permute operations with specific constant selection vectors. This means that we can pass the constant selection vector by

[02/13] Pass vec_perm_indices by reference

This patch makes functions take vec_perm_indices by reference rather than value, since a later patch will turn vec_perm_indices into a class that would be more expensive to copy. 2017-12-06 Richard Sandiford gcc/ * fold-const.c (fold_vec_perm): Take a

[01/13] Add a qimode_for_vec_perm helper function

The vec_perm code falls back to doing byte-level permutes if element-level permutes aren't supported. There were two copies of the code to calculate the mode, and later patches add another, so this patch splits it out into a helper function. 2017-12-09 Richard Sandiford

[00/13] Make VEC_PERM_EXPR work for variable-length vectors

This series is a replacement for: https://gcc.gnu.org/ml/gcc-patches/2017-11/msg00747.html based on the feedback that using VEC_PERM_EXPR would be better. The changes are: (1) Remove the restriction that the selector elements have to have the same width as the data elements, but only for

[PATCH] Fix loop interchange ICE on bitfields (PR tree-optimization/83337)

Hi! compute_access_stride does: tree ref = DR_REF (dr); tree scev_base = build_fold_addr_expr (ref); but that really isn't valid for bitfield drs, where we can't take addresses of the bitfield. As I understood this function only wants to compute strides, so constant bit offsets shouldn't make

Re: [RFA][PATCH] 8/n Pull evrp range analyzer into its own file

On Wed, 22 Nov 2017, Jeff Law wrote: >>> * gimple-ssa-evrp-analyze.c: New file pulled from gimple-ssa-evrp.c. >> >> With the move to C++, wasn't there a policy to name new files *.cc >> instead of *.c? > I'm happy to use .cc if that's where we want to go. It's trivial > and we're not losing any

Re: [PATCH] PR fortran/82934,83318 -- Enforce F2008:C631

On Fri, Dec 08, 2017 at 05:13:28PM -0800, Steve Kargl wrote: > The attached patch enforces F2008:C631, which of course is > > /* F2008:C631 (R626) A type-param-value in a type-spec shall be an >asterisk if and only if each allocate-object is a dummy argument >for which the corresponding

Re: config/i386/xmmintrin.h: Only #include if __STDC_HOSTED__

On Sat, Dec 09, 2017 at 06:41:14PM +0100, Gerald Pfeifer wrote: > Some users on FreeBSD noticed a problem when trying to use GCC to > build things in a standalone environment that manifests itself as > > /usr/local/lib/gcc/x86_64-unknown-freebsd11.0/6.3.0/include/xmmintrin.h:34 > from >

config/i386/xmmintrin.h: Only #include if __STDC_HOSTED__

Some users on FreeBSD noticed a problem when trying to use GCC to build things in a standalone environment that manifests itself as /usr/local/lib/gcc/x86_64-unknown-freebsd11.0/6.3.0/include/xmmintrin.h:34 from /usr/local/lib/gcc/x86_64-unknown-freebsd11.0/6.3.0/include/immintrin.h:29 from

Re: [PATCH] PR fortran/82934,83318 -- Enforce F2008:C631

Hi Steve, I can generate such a test but it will have to wait until I have finished doing all my Christmas cards :-) As for the dead code, that is not what is intended and might explain some difficulties that I have had with the code in decl.c. Cheers Paul On 9 December 2017 at 16:21, Steve

Re: [PATCH] PR fortran/82934,83318 -- Enforce F2008:C631

On Sat, Dec 09, 2017 at 09:09:14AM +, Paul Richard Thomas wrote: > > This is good for trunk with one proviso: > > This should mutate from: > - /* TODO understand why this error does not appear but, instead, > - the derived type is caught as a variable in primary.c. */ > - if

RE: [PATCH][i386,AVX] Enable VBMI2 support [5/7]

Hi Julia, On Mon, 4 Dec 2017, Koval, Julia wrote: > Do you think it is ok to copypaste it from GCC-6? you mean copy, past, and adjust? Yes, that should work. > GCC now supports the Intel CPU, named Cannonlake through > -march=cannonlake. The switch enables the following ISA extensions: >

Re: [PATCH v3] Ability to remap file names in __FILE__, etc (PR other/70268)

Thanks for the review. Third revision of the patch attached. Martin Sebor writes: > >>>+/* { dg-options "-ffile-prefix-map==FILE-PREFIX" } */ > >> > >>What's up with this "=="? (as opposed to "="). > > > >Since I cannot predict the actual path, I am remapping empty prefix >

Re: [PATCH 3/3] diagnose attribute aligned conflicts (PR 81566)

That requires updates to gcc.dg/pr53037-4.c and g++.dg/pr53037-4.C. FAIL: gcc.dg/pr53037-4.c (test for excess errors) Excess errors: /usr/local/gcc/gcc-20171208/gcc/testsuite/gcc.dg/pr53037-4.c:9:1:

Re: [PATCH] Fix vectorization of POINTER_DIFF_EXPR (PR tree-optimization/83338)

On December 9, 2017 10:50:12 AM GMT+01:00, Jakub Jelinek wrote: >Hi! > >When POINTER_PLUS_EXPR is vectorized, we vectorize it as a vector >PLUS_EXPR. >This (usually? Not sure about targets where sizetype has different >precision from POINTER_SIZE; maybe those just don't have

[PATCH] Fix vectorization of POINTER_DIFF_EXPR (PR tree-optimization/83338)

Hi! When POINTER_PLUS_EXPR is vectorized, we vectorize it as a vector PLUS_EXPR. This (usually? Not sure about targets where sizetype has different precision from POINTER_SIZE; maybe those just don't have vector types) works because we vectorize pointer variables as vectors of unsigned pointer

Re: [PATCH] PR fortran/82934,83318 -- Enforce F2008:C631

Hi Steve, This is good for trunk with one proviso: This should mutate from: - /* TODO understand why this error does not appear but, instead, - the derived type is caught as a variable in primary.c. */ - if (gfc_spec_list_type (type_param_spec_list, NULL) != SPEC_EXPLICIT) { -

Re: [PATCH] PR fortran/82934,83318 -- Enforce F2008:C631

Hi Steve, The attached patch enforces F2008:C631, which of course is /* F2008:C631 (R626) A type-param-value in a type-spec shall be an asterisk if and only if each allocate-object is a dummy argument for which the corresponding type parameter is assumed. */ Regression tested on