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 x86_6
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)
{
- gf
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 si
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 vector types)
>works
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: er
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
> >to FILE-PREFIX which
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:
> AVX5
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 (gfc_spec_
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 K
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
/works
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
> /usr/loca
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 ty
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
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
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 cons
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
gcc/
* optabs
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 const vec_perm_indices &
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 ref
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 C
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 permute
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 Sa
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 ele
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 (vec_perm_indices_to_tree): New function.
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 broadcast of the low byte.
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 chang
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 Sandi
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 Sandiford
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
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 understood this func
29 matches
Mail list logo
