On Tue, Nov 7, 2017 at 8:22 AM, Tsimbalist, Igor V
wrote:
> I decided to split my previous patch "Enable building libitm with Intel CET "
> into two different patches. The first patch will add a new field to sjlj.S and
> target.h files. The second one will add Intel CET support on the top of the
On 11/08/2017 11:30 AM, Segher Boessenkool wrote:
>> --- gcc/config/rs6000/power9.md (revision 254377)
>> +++ gcc/config/rs6000/power9.md (working copy)
>> @@ -436,6 +436,12 @@ (define_insn_reservation "power9-qpdiv"
>> (eq_attr "cpu" "power9"))
>>"DU_super_power9,dfu_power9")
Martin Sebor writes:
> On 11/08/2017 09:51 AM, Richard Sandiford wrote:
>> Martin Sebor writes:
>>> On 11/08/2017 02:32 AM, Richard Sandiford wrote:
Martin Sebor writes:
> I haven't done nearly a thorough review but the dtor followed by
> the placement new in the POLY_SET_COEFF() ma
On 11/07/2017 09:22 AM, Tsimbalist, Igor V wrote:
> I decided to split my previous patch "Enable building libitm with Intel CET "
> into two different patches. The first patch will add a new field to sjlj.S and
> target.h files. The second one will add Intel CET support on the top of the
> first o
On 06/06/17 14:17, James Greenhalgh wrote:
On Tue, Jun 06, 2017 at 09:40:44AM +0100, Kyrill Tkachov wrote:
Hi all,
On top of the previous vec_merge simplifications [1] we can add this pattern to
perform
a store of a vec_concat of two 64-bit values in distinct registers as an STP.
This avoids
On 11/04/2017 06:43 AM, Tsimbalist, Igor V wrote:
>> -Original Message-
>> From: Jeff Law [mailto:l...@redhat.com]
>> Sent: Tuesday, October 31, 2017 5:49 AM
>> To: Tsimbalist, Igor V ; gcc-
>> patc...@gcc.gnu.org
>> Cc: i...@airs.com
>> Subject: Re: [PATCH 08/22] Add Intel CET support for
On 11/03/2017 10:15 AM, Richard Sandiford wrote:
> The vectoriser tests used a combination of:
>
> 1) if (impossible condition) abort ();
> 2) volatile int x; ... *x = ...;
> 3) asm volatile ("" ::: "memory");
>
> to prevent vectorisation of a set-up loop. The problem with 1) is that
> the compi
>>
>>> Has this been tested anywhere other than x86/x86_64 linux?
>> Yes, I tested it on arm64 system. I applied 2 patches, previous 07/22 and
>> this one 08/22. Everything
>> was built successfully. Further to the building I did testing also. No new
>> fails.
> So how does that reconcile with H-
On 11/03/2017 10:17 AM, Richard Sandiford wrote:
> Several vector tests are sensitive to the vector size. This patch adds
> a VECTOR_BITS macro to tree-vect.h to select the expected vector size
> and uses it to influence iteration counts and array sizes. The tests
> keep the original values if th
On 11/03/2017 10:18 AM, Richard Sandiford wrote:
> This patch adds a routine that lists the available vector sizes
> for a target and uses it for some existing target conditions.
> Later patches add more uses.
>
> The cases are taken from multiple_sizes.
>
>
> 2017-11-03 Richard Sandiford
>
On 11/03/2017 10:18 AM, Richard Sandiford wrote:
> Some tests assumed that there would only be 2 vector sizes if
> vect_multiple_sizes, whereas for SVE there are three (SVE, 128-bit
> and 64-bit). This patch replaces scan-tree-dump-times with
> scan-tree-dump for vect_multiple_sizes but keeps it f
On Wed, Nov 8, 2017 at 2:03 AM, Kyrill Tkachov
wrote:
> Hi Andre,
>
> On 08/11/17 05:12, Andre McCurdy wrote:
>>
>> The following commit added the FL_LPAE flag to FL_FOR_ARCH7VE, but
>> neglected to also add it to the armv7ve compatible cores defined in
>> arm-cores.def.
>>
>> https://github.com/
The following commit added the FL_LPAE flag to FL_FOR_ARCH7VE, but
neglected to also add it to the armv7ve compatible cores defined in
arm-cores.def.
https://github.com/gcc-mirror/gcc/commit/af2d9b9e58e8be576c53d94f30c48c68146b0c98
The result is that gcc 6.4 now refuses to allow -march=armv7ve
On 11/03/2017 10:19 AM, Richard Sandiford wrote:
> SLP load permutation fails if any individual permutation requires more
> than two vector inputs. For 128-bit vectors, it's possible to permute
> 3 contiguous loads of 32-bit and 8-bit elements, but not 16-bit elements
> or 64-bit elements. The re
On Wed, Nov 8, 2017 at 9:02 AM, Koval, Julia wrote:
> Attachment got lost.
>
>> -Original Message-
>> From: Koval, Julia
>> Sent: Wednesday, November 08, 2017 9:01 AM
>> To: 'GCC Patches'
>> Cc: 'Uros Bizjak' ; 'Kirill Yukhin'
>>
>> Subject: RE: [x86][patch] Add -march=cannonlake.
>>
>>
> gcc/:
> 2017-11-08 Andi Kleen
>
> * config/i386/i386.opt: Add -mforce-indirect-call.
> * config/i386/predicates.md: Check for flag_force_indirect_call.
> * doc/invoke.texi: Document -mforce-indirect-call
>
> gcc/testsuite/:
> 2017-11-08 Andi Kleen
>
> * gcc.target/i386/force-indirect-call-1
This regression arose from the patch for PR66465, in which the type
check for the associated intrinsic was failing when testing the
association of a procedure pointer component with a procedure pointer.
See the comment in the patch for an explanation as to why this is an
issue. The fix is to isolat
On Wed, Nov 08, 2017 at 08:01:06AM -0600, Segher Boessenkool wrote:
> Hi Mike,
>
> On Wed, Nov 08, 2017 at 08:14:31AM -0500, Michael Meissner wrote:
> > PowerPC ISA 3.0 does not have a byte-reverse instruction that operates on
> > the
> > GPRs, but it does have vector byte swap half-word, word, d
On Nov 08 2017, Wilco Dijkstra wrote:
> Joseph Myers wrote:
>> On Fri, 3 Nov 2017, Wilco Dijkstra wrote:
>>
>> > Almost all targets add an explict -fomit-frame-pointer in the target
>> > specific
>> > options. Rather than doing this in a target-specific way, do this in the
>>
>> Which targets d
On Wed, Nov 08, 2017 at 07:51:54PM +, Paul Richard Thomas wrote:
> This regression arose from the patch for PR66465, in which the type
> check for the associated intrinsic was failing when testing the
> association of a procedure pointer component with a procedure pointer.
> See the comment in
Hi,
the following patch moves all function and call parameter manipulation
(as opposed to analysis) data structures and functions from ipa-prop.h
and ipa-prop.c to new files ipa-param-manipulation.h and
ipa-param-manipulation.c respectively. It does no functional change.
Please look at the follo
Hi,
this patch is a substantial rewrite of function parameter
manipulations currently used by IPA-SRA and OpenMP SIMD cloning. I
started it with the aim to cleanup the code but also to make the data
structures as small as possible so that, for real IPA-SRA, I can
attach them to call graph nodes i
Once the bug is found, the fix is obvious. Briefly,
in a typespec, ts.u.cl and ts.u.pad are in the same
union. When parsing a Hollerith, ts.u.pad is is set
to a nonzero value. Later, when resolving the array
constructor with Hollerith entities, a reference to
ts.u.cl is made which is a mangled
Igor
> -Original Message-
> From: H.J. Lu [mailto:hjl.to...@gmail.com]
> Sent: Wednesday, November 8, 2017 7:18 PM
> To: Tsimbalist, Igor V
> Cc: Jeff Law ; gcc-patches@gcc.gnu.org;
> trie...@redhat.com
> Subject: Re: [PATCH 21/22] Add extra field to gtm_jmpbuf on x86 only
>
> On Tue,
GCC Maintainers:
The following patch add support for the builtin:
vector signed int __builtin_altivec_vsumsws_be (vector signed int, vector
signed int)
The patch has been tested on
powerpc64le-unknown-linux-gnu (Power 8 LE),
powerpc64le-unknown-linux-gnu (Power 9 LE)
without
> -Original Message-
> From: Jeff Law [mailto:l...@redhat.com]
> Sent: Wednesday, November 8, 2017 8:06 PM
> To: Tsimbalist, Igor V ; gcc-
> patc...@gcc.gnu.org
> Cc: i...@airs.com
> Subject: Re: [PATCH 08/22] Add Intel CET support for EH in libgcc.
>
> On 11/04/2017 06:43 AM, Tsimbalist,
Committed. Thanks, Kito :).
On Tue, 07 Nov 2017 15:20:05 PST (-0800), Palmer Dabbelt wrote:
> From: Kito Cheng
>
> - This build error was indroduced by "RISC-V: Implement movmemsi"
> and "RISC-V: Support -mpreferred-stack-boundary flag"
>
> gcc/ChangeLog
>
> 2017-11-07 Kito Cheng
>
>
> -Original Message-
> From: Jeff Law [mailto:l...@redhat.com]
> Sent: Wednesday, November 8, 2017 6:21 PM
> To: Tsimbalist, Igor V ; Joseph Myers
> ; gcc-patches@gcc.gnu.org; i...@airs.com
> Subject: Re: [PATCH 07/22] Enable building libgcc with CET options.
>
> On 10/31/2017 05:29 AM, Ts
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Jeff Law
> Sent: Wednesday, November 8, 2017 7:31 PM
> To: Tsimbalist, Igor V ; gcc-
> patc...@gcc.gnu.org
> Cc: trie...@redhat.com; Jakub Jelinek
> Subject: Re: [PATCH 21/22]
On 11/03/2017 10:20 AM, Richard Sandiford wrote:
> This patch adds a target selector for targets whose
> preferred_vector_alignment is the alignment of one element. We'll never
> peel in that case, and the step of a loop that operates on normal (as
> opposed to packed) elements will always divide
On 11/03/2017 10:20 AM, Richard Sandiford wrote:
> This patch adds a target selector that says whether we can ever
> generate an "unaligned" accesses, where "unaligned" is relative
> to the target's preferred vector alignment. This is already true if:
>
>vect_no_align && { ! vect_hw_misalign
On 11/03/2017 10:21 AM, Richard Sandiford wrote:
> This patch adds a target selector for variable-length vectors.
> Initially it's always false, but the SVE patch provides a case
> in which it's true.
>
>
> 2017-11-03 Richard Sandiford
> Alan Hayward
> David Sherwood
>
On 11/03/2017 10:22 AM, Richard Sandiford wrote:
> This patch adds a target selector to say whether it's possible to
> align a local variable to the target's preferred vector alignment.
> This can be false for large vectors if the alignment is only
> a preference and not a hard requirement (and thu
On 11/03/2017 10:23 AM, Richard Sandiford wrote:
> This patch adds a target selector that says whether the target
> supports IFN_MASK_STORE.
>
>
> 2017-11-03 Richard Sandiford
> Alan Hayward
> David Sherwood
>
> gcc/
> * doc/sourcebuild.texi (vect_masked_store):
On 10/25/2017 09:57 AM, Richard Sandiford wrote:
> We already allow the target to change the size and alignment of a mode.
> This patch does the same thing for the number of units, which is needed
> to give command-line control of the SVE vector length.
>
> Tested on aarch64-linux-gnu, x86_64-linu
On 11/06/2017 02:10 AM, Richard Sandiford wrote:
> The recent gen_vec_duplicate patches used CONST_VECTOR for all
> constants, but the documentation says:
>
> @findex const_vector
> @item (const_vector:@var{m} [@var{x0} @var{x1} @dots{}])
> Represents a vector constant. The square brackets
On 11/06/2017 07:53 AM, Richard Sandiford wrote:
>>> 2017-09-18 Richard Sandiford
>>> Alan Hayward
>>> David Sherwood
>>>
>>> gcc/
>>> * doc/rtl.texi: Rewrite the subreg rules so that they partition
>>> the inner register into REGMODE_NATURAL_SIZE bytes rather than
>>
On 11/08/2017 09:49 AM, Richard Sandiford wrote:
> We had:
>
> if (vec_outside_cost <= 0)
> min_profitable_iters = 0;
> else
> {
> min_profitable_iters = ((vec_outside_cost - scalar_outside_cost)
> * assumed_vf
>
On Wed, Nov 8, 2017 at 2:26 PM, Tsimbalist, Igor V
wrote:
>> -Original Message-
>> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
>> ow...@gcc.gnu.org] On Behalf Of Jeff Law
>> Sent: Wednesday, November 8, 2017 7:31 PM
>> To: Tsimbalist, Igor V ; gcc-
>> patc...@gcc.gnu.org
>> Cc
Committed as obvious. ChangeLog explains change.
2017-11-08 Steven G. Kargl
PR Fortran/82841
* simplify.c(gfc_simplify_transfer): Do not dereference a NULL pointer.
Unwrap a short line.
2017-11-08 Steven G. Kargl
PR Fortran/82841
* gfortran.dg/tra
On 11/08/2017 03:06 PM, Tsimbalist, Igor V wrote:
So the question I have WRT this patch is the default setting. If I
>> understand it correctly, if the assembler supports the appropriate
>> insns, then we enable building target libraries with CET by default.
>
> That's right.
>
>> These librarie
On 11/08/2017 11:16 AM, Wilco Dijkstra wrote:
> Jeff Law wrote:
>
>> I'd actually prefer to deprecate the H8 and M68k. But assuming that's
>> not going to happen in the immediate future I think dropping frame
>> pointers on those targets is appropriate as long as we're generating
>> dwarf frame i
On Wed, Nov 8, 2017 at 3:04 PM, Jeff Law wrote:
> On 11/08/2017 03:06 PM, Tsimbalist, Igor V wrote:
> So the question I have WRT this patch is the default setting. If I
>>> understand it correctly, if the assembler supports the appropriate
>>> insns, then we enable building target libraries with
The revised patch is attached. The differences are in what options are defined
and propagated to Makefiles for CET enabling.
Ok for trunk?
Igor
> -Original Message-
> From: Jeff Law [mailto:l...@redhat.com]
> Sent: Wednesday, October 18, 2017 1:37 AM
> To: Tsimbalist, Igor V ; gcc-
> p
On 11/08/2017 10:36 AM, Nathan Sidwell wrote:
> On 11/02/2017 04:33 PM, Nathan Sidwell wrote:
>> On 10/26/2017 10:34 AM, David Malcolm wrote:
>>> [CCing Rainer and Mike for the gcc-dg.exp part]
>>
>>> My Tcl skills aren't great, so hopefully someone else can review this;
>>> CCing Rainer and Mike.
On 11/06/2017 02:35 PM, Jakub Jelinek wrote:
> Hi!
>
> My recent changes to const_ok_for_output_1 to allow UNSPEC if target hook
> says it is ok for debug regressed the following testcase, where creative
> simplify-rtx.c changes result in (const (neg (unspec ... UNSPEC_GOTOFF)))
> being emitted an
I suspect this patch got lost among the FMA patches at the same time. This
patch enables the rounding functions. Segher has already approved the rs6000
bits.
https://gcc.gnu.org/ml/gcc-patches/2017-10/msg02124.html
On Fri, Oct 27, 2017 at 06:39:21PM -0400, Michael Meissner wrote:
> The power9 (
On 11/08/2017 11:28 AM, Richard Sandiford wrote:
Martin Sebor writes:
On 11/08/2017 09:51 AM, Richard Sandiford wrote:
Martin Sebor writes:
On 11/08/2017 02:32 AM, Richard Sandiford wrote:
Martin Sebor writes:
I haven't done nearly a thorough review but the dtor followed by
the placement
Hello world,
while PR 82856 remains unsolved so far, this documentation patch at
least points people into the right direction if --enable-maintainer-mode
fails due to the incompatibility of the latest Perl version with
the required automkake version.
Tested with "make dvi" and "make pdf". OK for
101 - 149 of 149 matches
Mail list logo
