match.pd: x & C -> x if we know that x & ~C == 0

Hello, the testcase for this patch is taken from https://gcc.gnu.org/ml/gcc-patches/2016-05/msg00683.html get_nonzero_bits only gives may-be-set bits. To handle an equivalent transform for bit_ior, I would need must-be-set bits, maybe I should check if that is available somewhere in CCP...

Re: [PATCH, wide-int] change fixed_wide_int_storage from class to struct

On May 15, 2016, at 12:03 PM, Gerald Pfeifer wrote: > While not a bug according to the language of the C++ standard, this > causes dozens of warnings when building GCC with clang, and there is > not benefit of mixing struct and class like this. > > Mike, when I had a similar case a while ago you

Re: PING^5 [PATCH, GCC 5] PR 70613, -fabi-version docs don't match implementation

Or, you can cc Jason directly, and ping it. His mailbox filtering has him reading a subset of the patches emails, (those with C++ as I recall), so this is likely the first time he has seen it. > On May 16, 2016, at 3:35 PM, Jim Wilson wrote: > > This is my fifth ping. I just need someone to

Re: [PATCH][RFC] Introduce BIT_FIELD_INSERT

On Mon, 16 May 2016, Eric Botcazou wrote: > > The following patch adds BIT_FIELD_INSERT, an operation to > > facilitate doing bitfield inserts on registers (as opposed > > to currently where we'd have a BIT_FIELD_REF store). > > Why not call it BIT_FIELD_INSERT_EXPR instead to make it clear that

Re: [PATCH][RFC] Introduce BIT_FIELD_INSERT

On Mon, 16 May 2016, Bill Schmidt wrote: > Sorry, that was the wrong vector-6.c — should have realized. In any > case, for each of the vector tests, we get appropriate use of > element-wise loads, and no load-hit-store bitfield assignments, so the > code generation is what we want to see. Sor

RE: [PATCH] x86 interrupt attribute patch [1/2]

Gentle ping. -Original Message- From: Yulia Koval [mailto:vaalfr...@gmail.com] Sent: Friday, April 29, 2016 7:09 AM To: H.J. Lu Cc: Jeff Law ; Koval, Julia ; gcc-patches@gcc.gnu.org; Lu, Hongjiu ; ubiz...@gmail.com; Zamyatin, Igor Subject: Re: [PATCH] x86 interrupt attribute patch [1/

Re: [PATCH 1/3] function: Do the CLEANUP_EXPENSIVE after shrink-wrapping, not before

> We should do CLEANUP_EXPENSIVE after shrink-wrapping, because shrink- > wrapping creates constructs that CLEANUP_EXPENSIVE can optimise, and > nothing runs CLEANUP_EXPENSIVE later. We don't need cleanup_cfg before > shrink-wrapping, nothing in shrink-wrapping (or the other *logue insertion > cod

Re: [PATCH][RFC] Introduce BIT_FIELD_INSERT

> I'm fine with renaming it to BIT_FIELD_INSERT_EXPR, maybe > BIT_INSERT_EXPR then as it doesn't really have anything to do > with "bitfields". > > Any preference? BIT_INSERT_EXPR is fine with me. -- Eric Botcazou

Re: PING^5 [PATCH, GCC 5] PR 70613, -fabi-version docs don't match implementation

On May 16, 2016, at 5:22 PM, Sandra Loosemore wrote: > > On 05/16/2016 04:35 PM, Jim Wilson wrote: >> This is my fifth ping. I just need someone to rubber stamp it so I >> can check it in. > > The documentation change looks fine, but as a documentation maintainer only I > don't think I can app

[PATCH] Add port for Phoenix-RTOS on ARM platform.

--- ChangeLog| 6 ++ MAINTAINERS | 1 + configure| 6 ++ configure.ac | 6 ++ gcc/ChangeLog| 6 ++ gcc/config.gcc | 11 +++ gcc/config/arm/t-phoenix | 29 + gcc/c

Re: [PATCH 1/3] function: Do the CLEANUP_EXPENSIVE after shrink-wrapping, not before

On Tue, May 17, 2016 at 10:05:57AM +0200, Eric Botcazou wrote: > > We should do CLEANUP_EXPENSIVE after shrink-wrapping, because shrink- > > wrapping creates constructs that CLEANUP_EXPENSIVE can optimise, and > > nothing runs CLEANUP_EXPENSIVE later. We don't need cleanup_cfg before > > shrink-wr

Re: [C++ Patch] PR 70466 ("ICE on invalid code in tree check: expected constructor, have parm_decl in convert_like_real...")

... alternately, if the substance of my patchlet is right, we could simplify a bit the logic per the below. Thanks, Paolo. / Index: cp/call.c === --- cp/call.c (revision 236309) +++ cp/call.c (working copy)

[AArch64 trivial] Don't define a macro when a variable will do

Hi, As title, this use of macros doesn't make much sense to me. We can just do this as a const unsigned int. Comitted as obvious as revision 236311. OK? Thanks, James --- 2016-05-17 James Greenhalgh * config/aarch64/aarch64.c (aarch64_output_simd_mov_immediate): Make "buf_

Re: [PATCH, libgomp] Rewire OpenACC async

On 2016/5/12 6:56 PM, Jakub Jelinek wrote: > On Thu, May 12, 2016 at 12:47:18PM +0200, Thomas Schwinge wrote: >> Hi! >> >> On Thu, 12 May 2016 12:02:58 +0200, Jakub Jelinek wrote: >>> ABI incompatible change for the plugin >>> interface (affecting OpenACC capable plugins only), I think you just sh

[Patch obvious AArch64] Wrap SHIFT_COUNT_TRUNCATED in brackets

Hi, This is probably not going to be an issue, but we should wrap the macro definition in () just in case someone does want to use it with a higher precedence operator. Applied as obvious as revision 236312. Thanks, James --- 2016-05-16 James Greenhalgh * config/aarch64/aarch64.c (

Re: [PATCH, libgomp] Rewire OpenACC async

On Tue, May 17, 2016 at 04:56:42PM +0800, Chung-Lin Tang wrote: > I assume that bumping GOMP_VERSION in include/gomp-constants.h would be > enough? I think so. Jakub

[PATCH AArch64]Support missing vcond pattern by adding/using vec_cmp/vcond_mask patterns.

Hi, Alan and Renlin noticed that some vcond patterns are not supported in AArch64(or AArch32?) backend, and they both had some patches fixing this. After investigation, I agree with them that vcond/vcondu in AArch64's backend should be re-implemented using vec_cmp/vcond_mask patterns, so here c

[PATCH GCC]Enable vect_cond_mixed for AArch64.

Hi, After supporting all vcond/vcondu patterns in AArch64 backend, now we can vectorize VEC_COND_EXPR with different type in comparison operands and value operands on AArch64. GCC uses vect_cond_mixed to control such test cases, for now, there are below cases affected by it: pr61194.c This

[Patch obvious] Fix indentation in c-typeck.c parser_build_unary_op

Hi, This patch is an obvious fix for some out of place indentation in parser_build_unary_op. I've checked that my new spacing didn't break the build on aarch64 or x86_64. Committed as obvious as revision 236313. Thanks, James --- gcc/c/ 2016-05-17 James Greenhalgh * c-typeck.c (p

[Patch AArch64] Simplify reduc_plus_scal_v2[sd]f sequence

Hi, This is just a simplification, it probably makes life easier for register allocation in some corner cases and seems the right thing to do. We don't use the internal version elsewhere, so we're safe to delete it and change the types. OK? Bootstrapped on AArch64 with no issues. Thanks, James

Re: [PATCH 1/3] function: Do the CLEANUP_EXPENSIVE after shrink-wrapping, not before

> How would it? The shrink-wrapping algorithms do not much care how you > write your control flow. The only things I can think of are drastic > things like removing some dead code, or converting a switch to a direct > jump, but those had better be done for the immediately preceding passes > alrea

[Patch AArch64] Delete ASM_OUTPUT_DEF and fallback to default .set directive

Hi, As in the ARM port [1] , the AArch64 port wants to put out "b = a" to set an alias. This doesn't cause us any trouble yet, as the AArch64 port doesn't warn for this construct - but at the same time there is no reason for us not to put out a .set directive - this seems to have been copied from

Re: [PATCH 1/3] function: Do the CLEANUP_EXPENSIVE after shrink-wrapping, not before

On Tue, May 17, 2016 at 11:08:53AM +0200, Eric Botcazou wrote: > > How would it? The shrink-wrapping algorithms do not much care how you > > write your control flow. The only things I can think of are drastic > > things like removing some dead code, or converting a switch to a direct > > jump, bu

[PATCH, PR target/71114] Fix constants conversion in STV pass

Hi, This patch fixes an insertion point for instructions generated by validize_mem in dimode_scalar_chain::convert_op. Patch also fixes scanned instruction pattern to fix test for Darwin. I bootstrapped and regtested it on x86_64-pc-linus gnu. Dominique d'Humieres tested it for Darwin. OK for t

[Patch AArch64 0/2] Refactor ldp/stp code

Hi, This is a short patch set to remove duplication across the ldp/stp generation code. In both cases there is no functional change, just a refactor of common sequences out to their own function, and a replacement of repeated work with loops. I think it makes for a cleanup, but I realise this is

Re: [PATCH, PR target/71114] Fix constants conversion in STV pass

On Tue, May 17, 2016 at 11:20 AM, Ilya Enkovich wrote: > Hi, > > This patch fixes an insertion point for instructions generated by > validize_mem in dimode_scalar_chain::convert_op. Patch also fixes > scanned instruction pattern to fix test for Darwin. > > I bootstrapped and regtested it on x86_6

[committed] Cherry-pick upstream asan fix for upcoming glibc (PR sanitizer/71160)

Hi! This is a cherry-pick of upstream fix, so that dlsym can call not just calloc, but also malloc or realloc, even before asan is initialized. Tested on x86_64-linux, committed so far to trunk. IMHO even better would be to make sure that in the common case (recent glibc) we don't have failed dl

[Patch AArch64 2/2] Some more cleanup of ldp/stp generation

This is another refactoring patch to clean up more of the ldp/stp handling code and avoid duplicating quite as much code. Much like the other refactoring patch, this reduces the use of reg_1, reg_2, etc. leading to a cleaner implementation. Bootstrapped on AArch64 with no issues. OK? Thanks, J

[AArch64 1/2] Refactor aarch64_operands_ok_for_ldpstp, aarch64_operands_adjust_ok_for_ldpstp

Hi, These two functions are very similar and suffer from code duplication. With a little bit of work we can reduce the strain on the reader by refactoring the functions. Essentially, we're going to remove the explicit references to reg_1, reg_2, reg_3, reg_4 and keep these things in arrays inste

Re: PING^5 [PATCH, GCC 5] PR 70613, -fabi-version docs don't match implementation

On Tue, May 17, 2016 at 1:22 AM, Sandra Loosemore wrote: > On 05/16/2016 04:35 PM, Jim Wilson wrote: >> >> This is my fifth ping. I just need someone to rubber stamp it so I >> can check it in. > > > The documentation change looks fine, but as a documentation maintainer only > I don't think I can

Re: [AARCH64] Remove static variable all_extensions from aarch64.c

On Tue, May 17, 2016 at 12:14:28PM +1000, Kugan Vivekanandarajah wrote: > Hi, > > static variable all_extensions in aarch64.c is not used and therefore > dead. I don’t see any reason why it should be there. Attached patch > removes this. > > > Bootstrapped on aarch64-linux-gnu. Regression testin

Re: [PATCH, libgcc/ARM 1/6, ping1] Fix Thumb-1 only == ARMv6-M & Thumb-2 only == ARMv7-M assumptions

Ping? *** gcc/ChangeLog *** 2015-11-13 Thomas Preud'homme * config/arm/elf.h: Use __ARM_ARCH_ISA_THUMB and __ARM_ARCH_ISA_ARM to decide whether to prevent some libgcc routines being included for some multilibs rather than __ARM_ARCH_6M__ and add comment to indicate the

[Patch] PR rtl-optimization/71150, guard in_class_p check with REG_P

This bug is introduced by my commit r236181 where the inner rtx of SUBREG haven't been checked while it should as "in_class_p" only works with REG, and SUBREG_REG is actually not always REG. If REG_P check failed, then we should fall back to normal code patch. The following simple testcase for x

Re: [PATCH][AArch64][tests] Skip cpu-diagnostics tests when overriding -mcpu

On Mon, May 16, 2016 at 05:18:44PM +0100, Kyrill Tkachov wrote: > Hi all, > > The gcc.target/aarch64/cpu-diagnostics* tests specify invalid -mcpu options > and look for the expected error. > However, if the user overrides the -mcpu option when testing the tests start > FAILing because they don't

Re: [PATCH, ARM 2/7, ping1] Add support for ARMv8-M

Ping? *** gcc/ChangeLog *** 2015-11-23 Thomas Preud'homme * config/arm/arm-arches.def (armv8-m.base): Define new architecture. (armv8-m.main): Likewise. (armv8-m.main+dsp): Likewise * config/arm/arm-protos.h (FL_FOR_ARCH8M_BASE): Define. (FL_FOR_ARCH8M_

Re: [PATCH, ARM 3/7, ping1] Fix indentation of FL_FOR_ARCH* definition after adding support for ARMv8-M

Ping? *** gcc/ChangeLog *** 2015-11-06 Thomas Preud'homme * config/arm/arm-protos.h: Reindent FL_FOR_* macro definitions. diff --git a/gcc/config/arm/arm-protos.h b/gcc/config/arm/arm-protos.h index 63235cb63acf3e676fac5b61e1195081efd64075..f437d0d8baa5534f9519dd28cd2c4ac52d48685c

Re: [PATCH, ARM 4/7, ping1] Factor out MOVW/MOVT availability and desirability checks

Ping? *** gcc/ChangeLog *** 2015-11-09 Thomas Preud'homme * config/arm/arm.h (TARGET_USE_MOVT): Check MOVT/MOVW availability with TARGET_HAVE_MOVT. (TARGET_HAVE_MOVT): Define. * config/arm/arm.c (const_ok_for_op): Check MOVT/MOVW availability with TARGE

Re: [PATCH, ARM 5/7, ping1] Add support for MOVT/MOVW to ARMv8-M Baseline

Ping? *** gcc/ChangeLog *** 2015-11-13 Thomas Preud'homme * config/arm/arm.h (TARGET_HAVE_MOVT): Include ARMv8-M as having MOVT. * config/arm/arm.c (arm_arch_name): (const_ok_for_op): Check MOVT/MOVW availability with TARGET_HAVE_MOVT. (thumb_legitimate_constan

Re: [PATCH, ARM 6/7, ping1] Add support for CB(N)Z and (U|S)DIV to ARMv8-M Baseline

Ping? *** gcc/ChangeLog *** 2015-11-13 Thomas Preud'homme * config/arm/arm.c (arm_print_operand_punct_valid_p): Make %? valid for Thumb-1. * config/arm/arm.h (TARGET_HAVE_CBZ): Define. (TARGET_IDIV): Set for all Thumb targets provided they have hardware

Re: [PATCH, ARM 7/7, ping1] Enable atomics for ARMv8-M Mainline

Ping? *** gcc/ChangeLog *** 2015-12-17 Thomas Preud'homme * config/arm/arm.h (TARGET_HAVE_LDACQ): Enable for ARMv8-M Mainline. diff --git a/gcc/config/arm/arm.h b/gcc/config/arm/arm.h index 347b5b0a5cc0bc1e3b5020c8124d968e76ce48a4..e154bd31b8084f9f45ad4409e7b38de652538c51 100644

Re: [Patch] PR rtl-optimization/71150, guard in_class_p check with REG_P

Hello! > This bug is introduced by my commit r236181 where the inner rtx of > SUBREG haven't been checked while it should as "in_class_p" only > works with REG, and SUBREG_REG is actually not always REG. If REG_P > check failed, then we should fall back to normal code patch. The > following simp

Re: [Patch] PR rtl-optimization/71150, guard in_class_p check with REG_P

On Tue, May 17, 2016 at 12:17 PM, Uros Bizjak wrote: > Hello! > >> This bug is introduced by my commit r236181 where the inner rtx of >> SUBREG haven't been checked while it should as "in_class_p" only >> works with REG, and SUBREG_REG is actually not always REG. If REG_P >> check failed, then w

Re: [Patch AArch64] Delete ASM_OUTPUT_DEF and fallback to default .set directive

On 17 May 2016 at 10:13, James Greenhalgh wrote: > > Hi, > > As in the ARM port [1] , the AArch64 port wants to put out "b = a" to set > an alias. This doesn't cause us any trouble yet, as the AArch64 port doesn't > warn for this construct - but at the same time there is no reason for us > not to

Re: [Patch AArch64] Simplify reduc_plus_scal_v2[sd]f sequence

On 17 May 2016 at 10:06, James Greenhalgh wrote: > > Hi, > > This is just a simplification, it probably makes life easier for register > allocation in some corner cases and seems the right thing to do. We don't > use the internal version elsewhere, so we're safe to delete it and change > the types

[PATCH][AArch64] PR target/70809: Delete aarch64_vmls pattern

Hi all, The aarch64_vmls pattern claims to perform a normal vector floating-point multiply-subtract but in fact performs a fused multiply-subtract. This is fine when -ffp-contract=fast, but it's not guarded on anything so will generate the FMLS instruction even when -ffp-contract=off. The solu

Re: [PATCH][ARM] PR target/70830: Avoid POP-{reglist}^ when returning from interrupt handlers

On 13/05/16 12:05, Kyrill Tkachov wrote: Hi Christophe, On 12/05/16 20:57, Christophe Lyon wrote: On 12 May 2016 at 11:48, Ramana Radhakrishnan wrote: On Thu, May 5, 2016 at 12:50 PM, Kyrill Tkachov wrote: Hi all, In this PR we deal with some fallout from the conversion to unified assembl

Re: [Patch AArch64] Simplify reduc_plus_scal_v2[sd]f sequence

On Tue, May 17, 2016 at 11:32:36AM +0100, Marcus Shawcroft wrote: > On 17 May 2016 at 10:06, James Greenhalgh wrote: > > > > Hi, > > > > This is just a simplification, it probably makes life easier for register > > allocation in some corner cases and seems the right thing to do. We don't > > use t

Re: [PATCH][AArch64] PR target/70809: Delete aarch64_vmls pattern

On Tue, May 17, 2016 at 11:37:57AM +0100, Kyrill Tkachov wrote: > Hi all, > > The aarch64_vmls pattern claims to perform a normal vector > floating-point multiply-subtract but in fact performs a fused > multiply-subtract. This is fine when -ffp-contract=fast, but it's not guarded > on anything so

Re: [PATCH PR69848/partial]Propagate comparison into VEC_COND_EXPR if target supports

On Mon, May 16, 2016 at 10:09 AM, Bin.Cheng wrote: > On Fri, May 13, 2016 at 5:53 PM, Richard Biener > wrote: >> On May 13, 2016 6:02:27 PM GMT+02:00, Bin Cheng wrote: >>>Hi, >>>As PR69848 reported, GCC vectorizer now generates comparison outside of >>>VEC_COND_EXPR for COND_REDUCTION case, as b

Re: [Patch] PR rtl-optimization/71150, guard in_class_p check with REG_P

On 17/05/16 11:23, Uros Bizjak wrote: On Tue, May 17, 2016 at 12:17 PM, Uros Bizjak wrote: Hello! This bug is introduced by my commit r236181 where the inner rtx of SUBREG haven't been checked while it should as "in_class_p" only works with REG, and SUBREG_REG is actually not always REG. If

Re: [PATCH] [rtlfe] Barebones implementation of "__RTL"; next steps?

On Mon, May 16, 2016 at 8:48 PM, Jeff Law wrote: > On 05/12/2016 08:29 AM, David Malcolm wrote: >> >> >> One wart I ran into is that system.h has this: >> >> /* Front ends should never have to include middle-end headers. Enforce >>this by poisoning the header double-include protection defines

Re: Avoid inlining into instrumetnation thunks

On Mon, May 16, 2016 at 9:34 PM, Jan Hubicka wrote: > Hi, > this patch fixes chkp ICE when we try to inline into an instrumentation thunk. > This is not really a thunk and ths can't be hanled as such. > > Bootstrapped/regtested x86_64-linux > > Honza > > 2016-05-16 Jan Hubicka > > * ipa

Re: [Patch] PR rtl-optimization/71150, guard in_class_p check with REG_P

On Tue, May 17, 2016 at 1:18 PM, Jiong Wang wrote: > On 17/05/16 11:23, Uros Bizjak wrote: >> >> On Tue, May 17, 2016 at 12:17 PM, Uros Bizjak wrote: >>> >>> Hello! >>> This bug is introduced by my commit r236181 where the inner rtx of SUBREG haven't been checked while it should as "in_

Re: match.pd: ~X & Y to X ^ Y in some cases

On Fri, May 13, 2016 at 9:07 PM, Marc Glisse wrote: > Hello, > > maybe this would fit better in VRP, but it is easier (and not completely > useless) to put it in match.pd. > > Since the transformation is restricted to GIMPLE, I think I don't need to > check that @0 is SSA_NAME. I didn't test if @0

Re: match.pd: x & C -> x if we know that x & ~C == 0

On Tue, May 17, 2016 at 8:59 AM, Marc Glisse wrote: > Hello, > > the testcase for this patch is taken from > https://gcc.gnu.org/ml/gcc-patches/2016-05/msg00683.html > > get_nonzero_bits only gives may-be-set bits. To handle an equivalent > transform for bit_ior, I would need must-be-set bits, may

[Patch V2] Fix SLP PR58135.

Hi Richard, I created the patch by passing -b option to git. Now the patch is more readable. As per your suggestion I tried to fix the PR by splitting the SLP store group at vector boundary after the SLP tree is built. Boot strap PASSED on x86_64. Checked the patch with check_GNU_style.sh. Th

Re: VRP: range info of new variables

On Mon, 16 May 2016, Jeff Law wrote: - Now that I think of it, maybe I should check that the variable is not a pointer before calling set_range_info? Having range [0, 1] makes it unlikely, but who knows... Maybe using an assert would be better. I don't think having a pointer there would be co

Fix firefox compilation ICE

Hi, this patch fixes ICE while building Firefox (and probably xalancbmk, too) with -O3 -flto. I originally tested the whole patchset on several bigger apps including the inline heuristics change which teach it that thunks are very cheap. Mainline doesn't contain it that makes us to inline into th

Re: [Patch V2] Fix SLP PR58135.

On Tue, May 17, 2016 at 1:56 PM, Kumar, Venkataramanan wrote: > Hi Richard, > > I created the patch by passing -b option to git. Now the patch is more > readable. > > As per your suggestion I tried to fix the PR by splitting the SLP store group > at vector boundary after the SLP tree is built. >

Re: [AArch64, 1/4] Add the missing support of vfms_n_f32, vfmsq_n_f32, vfmsq_n_f64

On Mon, May 16, 2016 at 10:09:26AM +0100, Jiong Wang wrote: > The support of vfma_n_f64, vfms_n_f32, vfmsq_n_f32, vfmsq_n_f64 are > missing in current gcc arm_neon.h. > > Meanwhile, besides "(fma (vec_dup (vec_select)))", fma by element can > also comes from "(fma (vec_dup(scalar" where the scalar

Re: [Patch ARM] Fix PR target/53440 - handle generic thunks better for TARGET_32BIT.

On 1 April 2016 at 17:32, Ramana Radhakrishnan wrote: > I've had this in my tree for a few months now but never got > around to submitting it. > > This partially fixes PR target/53440 atleast in ARM and > Thumb2 state. I haven't yet managed to get my head around > rewriting the Thumb1 support yet.

Re: [AArch64, 2/4] Extend vector mutiply by element to all supported modes

On Mon, May 16, 2016 at 10:09:31AM +0100, Jiong Wang wrote: > AArch64 support vector multiply by element for V2DF, V2SF, V4SF, V2SI, > V4SI, V4HI, V8HI. > > All above are well supported by "*aarch64_mul3_elt" pattern and > "*aarch64_mul3_elt_" if there is lane size > change. > > Above patterns ar

[PATCH] Fix PR71104 - call gimplification

The following patch addresses PR71104 which shows verify-SSA ICEs after gimplify-into-SSA. The issue is that for returns-twice calls we gimplify register uses in the LHS before the actual call which leads to p.0_1 = p; _2 = vfork (); *p.0_1 = _2; when gimplifying *p = vfork (). That of c

Re: [Patch ARM] Fix PR target/53440 - handle generic thunks better for TARGET_32BIT.

On Tue, May 17, 2016 at 1:25 PM, Christophe Lyon wrote: > On 1 April 2016 at 17:32, Ramana Radhakrishnan > wrote: >> I've had this in my tree for a few months now but never got >> around to submitting it. >> >> This partially fixes PR target/53440 atleast in ARM and >> Thumb2 state. I haven't yet

Re: [AArch64, 3/4] Reimplement multiply by element to get rid of inline assembly

On Mon, May 16, 2016 at 10:09:37AM +0100, Jiong Wang wrote: > This patch reimplement vector multiply by element on top of the existed > vmul_lane* intrinsics instead of inline assembly. > > There is no code generation change from this patch. > > OK for trunk? > > 2016-05-16 Jiong Wang > > gcc/

Re: RFA: Generate normal DWARF DW_LOC descriptors for non integer mode pointers

Hi Jeff, >> Currently dwarf2out.c:mem_loc_descriptor() has some special case >> code to handle the situation where an address is held in a register >> whose mode is not of type MODE_INT. It generates a >> DW_OP_GNU_regval_type expression which may later on be converted into >> a frame p

Re: [AArch64, 4/4] Reimplement vmvn* intrinscis, remove inline assembly

On Mon, May 16, 2016 at 10:09:42AM +0100, Jiong Wang wrote: > This patch remove inline assembly and reimplement all mvn/mvnq vector > integer intrinsics through the standard "one_cmpl2" pattern was > introduced later after the initial implementation of those intrinsics. > that's why inline assembly

Re: [AArch64, 1/4] Add the missing support of vfms_n_f32, vfmsq_n_f32, vfmsq_n_f64

On 17/05/16 13:20, James Greenhalgh wrote: On Mon, May 16, 2016 at 10:09:26AM +0100, Jiong Wang wrote: The support of vfma_n_f64, vfms_n_f32, vfmsq_n_f32, vfmsq_n_f64 are missing in current gcc arm_neon.h. Meanwhile, besides "(fma (vec_dup (vec_select)))", fma by element can also comes from "(

Re: [AArch64, 1/4] Add the missing support of vfms_n_f32, vfmsq_n_f32, vfmsq_n_f64

On 17/05/16 13:40, Kyrill Tkachov wrote: On 17/05/16 13:20, James Greenhalgh wrote: On Mon, May 16, 2016 at 10:09:26AM +0100, Jiong Wang wrote: The support of vfma_n_f64, vfms_n_f32, vfmsq_n_f32, vfmsq_n_f64 are missing in current gcc arm_neon.h. Meanwhile, besides "(fma (vec_dup (vec_select

[PATCH] Fix PR71132

The following fixes a latent issue in loop distribution catched by the fake edge placement adjustment. Bootstrapped and tested on x86_64-unknown-linux-gnu, applied. Richard. 2016-05-17 Richard Biener PR tree-optimization/71132 * tree-loop-distribution.c (create_rdg_cd_edges)

Re: [Patch AArch64] Simplify reduc_plus_scal_v2[sd]f sequence

On 17 May 2016 at 12:02, James Greenhalgh wrote: > On Tue, May 17, 2016 at 11:32:36AM +0100, Marcus Shawcroft wrote: >> On 17 May 2016 at 10:06, James Greenhalgh wrote: >> > >> > Hi, >> > >> > This is just a simplification, it probably makes life easier for register >> > allocation in some corner

Re: [PATCH, GCC] PR middle-end/55299, fold bitnot through ASR and rotates

On Fri, May 13, 2016 at 3:36 PM, Marc Glisse wrote: > On Fri, 13 May 2016, Mikhail Maltsev wrote: > >>> I don't know if we might want some :c / single_use restrictions, maybe on >>> the >>> outer convert and the rshift/rotate. >>> >> I don't think :c can be used here. > > > Oups, typo for :s. > >>

Re: [PATCH, GCC] PR middle-end/55299, fold bitnot through ASR and rotates

On 05/17/2016 04:39 PM, Richard Biener wrote: > > Are you sure narrowing conversions are valid for rotates? > > (char)short_var < byte. > Yes, but the transformation leaves conversions as-is. Only bit_not is removed. -- Regards, Mikhail Maltsev

Re: [PATCH, GCC] PR middle-end/55299, fold bitnot through ASR and rotates

On Tue, 17 May 2016, Richard Biener wrote: On Fri, May 13, 2016 at 3:36 PM, Marc Glisse wrote: On Fri, 13 May 2016, Mikhail Maltsev wrote: I don't know if we might want some :c / single_use restrictions, maybe on the outer convert and the rshift/rotate. I don't think :c can be used here.

[PATCH 0/17][ARM] ARMv8.2-A and FP16 extension support.

Hello, The ARMv8.2-A architecture builds on ARMv8.1-A and includes an optional extension supporting half-precision floating point (FP16) arithmetic. This extension adds instructions to the VFP and NEON instructions sets to provide operations on IEEE754-2008 formatted FP16 values. This patch set

[PATCH 1/17][ARM] Add ARMv8.2-A command line option and profile.

This patch adds the command options for the architecture ARMv8.2-A and the half-precision extension. The architecture is selected by -march=armv8.2-a and has all the properties of -march=armv8.1-a. This patch also enables the CRC extension (+crc) which is required for both ARMv8.2-A and ARMv8.1-A

[PATCH 2/17][Testsuite] Add a selector for ARM FP16 alternative format support.

The ARMv8.2-A FP16 extension only supports the IEEE format for FP16 data. It is not compatible with the option -mfp16-format=none nor with the option -mfp16-format=alternative (selecting the ARM alternative FP16 format). Using either with the FP16 extension will trigger a compiler error. This pat

[PATCH 3/17][Testsuite] Add ARM support for ARMv8.2-A with FP16 arithmetic instructions.

The ARMv8.2-A FP16 extension adds to both the VFP and the NEON instruction sets. This patch adds support to the testsuite to select targets and set options for tests that make use of these instructions. It also adds documentation for ARMv8.1-A selectors. Tested the series for arm-none-linux-gnuea

[PATCH 4/17][ARM] Define feature macros for FP16.

The FP16 extension introduced with the ARMv8.2-A architecture adds instructions operating on FP16 values to the VFP and NEON instruction sets. The patch adds the feature macro __ARM_FEATURE_FP16_SCALAR_ARITHMETIC which is defined to be 1 if the VFP FP16 instructions are available; it is otherwise

[PATCH 5/17][ARM] Enable HI mode moves for floating point values.

The handling of 16-bit integer data-movement in the ARM backend doesn't make full use of the VFP instructions when they are available, even when the values are for use in VFP operations. This patch adds support for using the VFP instructions and registers when moving 16-bit integer and floating p

[PATCH 6/17][ARM] Add data processing intrinsics for float16_t.

The ACLE specifies a number of intrinsics for manipulating vectors holding values in most of the integer and floating point type. These include 16-bit integer types but not 16-bit floating point even though the same instruction is used for both. A future version of the ACLE extends the data proce

[PATCH 7/17][ARM] Add FP16 data movement instructions.

The ARMv8.2-A FP16 extension adds a number of instructions to support data movement for FP16 values. This patch adds these instructions to the backend, making them available to the compiler code generator. The new instructions include VSEL which selects between two registers depending on a condit

[PATCH 9/17][ARM] Add NEON FP16 arithmetic instructions.

The ARMv8.2-A FP16 extension adds a number of arithmetic instrutctions to the NEON instruction set. This patch adds support for these instructions to the ARM backend. As with the VFP FP16 arithmetic instructions, operations on __fp16 values are done by conversion to single-precision. Any new opti

Re: [committed] Cherry-pick upstream asan fix for upcoming glibc (PR sanitizer/71160)

Hi Jakub, thanks for backporting this! Do you have any plans to apply this patch to GCC 5 and 6 branches? AFAIK people hit on this ASan + newer Glibc bug by using GCC 5.3.1 on Fedora 23. On 17/05/16 12:23, Jakub Jelinek wrote: Hi! This is a cherry-pick of upstream fix, so that dlsym can cal

[PATCH 10/17][ARM] Refactor support code for NEON builtins.

The ACLE intrinsics introduced to support the ARMv8.2 FP16 extensions require that intrinsics for scalar (VFP) instructions are available under different conditions from those for the NEON intrinsics. To support this, changes to the builtins support code are needed to enable the scalar intrinsics

[PATCH 11/17][ARM] Add builtins for VFP FP16 intrinsics.

The ACLE intrinsics introduced to support the ARMv8.2 FP16 extensions require that intrinsics for scalar floating pointer (VFP) instructions are available under different conditions from those for the NEON intrinsics. This patch adds the support code and builtins data for the new VFP intrinsics.

[PATCH 8/17][ARM] Add VFP FP16 arithmetic instructions.

The ARMv8.2-A FP16 extension adds a number of arithmetic instrutctions to the VFP instruction set. This patch adds support for these instructions to the ARM backend. In most cases the instructions are added using non-standard pattern names. This is to force operations on __fp16 values to be done,

[PATCH 12/17][ARM] Add builtins for NEON FP16 intrinsics.

This patch adds the builtins data for the ACLE intrinsics introduced to support the NEON instructions of the ARMv8.2-A FP16 extension. Tested the series for arm-none-linux-gnueabihf with native bootstrap and make check and for arm-none-eabi and armeb-none-eabi with make check on an ARMv8.2-A emul

Re: [committed] Cherry-pick upstream asan fix for upcoming glibc (PR sanitizer/71160)

On Tue, May 17, 2016 at 05:38:27PM +0300, Maxim Ostapenko wrote: > Hi Jakub, > > thanks for backporting this! Do you have any plans to apply this patch to > GCC 5 and 6 branches? AFAIK people hit on this ASan + newer Glibc bug by > using GCC 5.3.1 on Fedora 23. I don't have the newer glibc on my

[PATCH 14/17][ARM] Add NEON FP16 instrinsics.

The ARMv8.2-A architecture introduces an optional FP16 extension adding half-precision floating point data processing instructions to the existing Adv.SIMD (NEON) support. A future version of the ACLE will add support for these instructions and this patch implements that support. The ACLE will in

[PATCH 15/17][ARM] Add tests for ARMv8.2-A FP16 support.

Support for using the half-precision floating point operations added by the ARMv8.2-A FP16 extension is based on the macros and intrinsics added to the ACLE for the extension. This patch adds tests to check the compilers treatment of the ACLE macros and the code generated for the new intrinsics.

[PATCH 13/17][ARM] Add VFP FP16 instrinsics.

The ARMv8.2-A architecture introduces an optional FP16 extension adding half-precision floating point data processing instructions to the existing scalar (floating point) support. A future version of the ACLE will add support for these instructions and this patch implements that support. The ACLE

[PATCH 16/17][ARM] Add tests for VFP FP16 ACLE instrinsics.

Support for using the half-precision floating point operations added by the ARMv8.2-A FP16 extension is based on the macros and intrinsics added to the ACLE for the extension. This patch adds executable tests for the ACLE scalar (floating point) intrinsics to the advsimd-intrinsics testsuite. The

Re: [PATCH, GCC] PR middle-end/55299, fold bitnot through ASR and rotates

On Tue, May 17, 2016 at 4:05 PM, Marc Glisse wrote: > On Tue, 17 May 2016, Richard Biener wrote: > >> On Fri, May 13, 2016 at 3:36 PM, Marc Glisse wrote: >>> >>> On Fri, 13 May 2016, Mikhail Maltsev wrote: >>> > I don't know if we might want some :c / single_use restrictions, maybe > on >

Re: PING^5 [PATCH, GCC 5] PR 70613, -fabi-version docs don't match implementation

On 05/17/2016 03:27 AM, Ramana Radhakrishnan wrote: On Tue, May 17, 2016 at 1:22 AM, Sandra Loosemore wrote: On 05/16/2016 04:35 PM, Jim Wilson wrote: This is my fifth ping. I just need someone to rubber stamp it so I can check it in. The documentation change looks fine, but as a document

Re: [PATCH][RFC] Introduce BIT_FIELD_INSERT

Hi, On Tue, 17 May 2016, Richard Biener wrote: > BIT_INSERT_EXPR This. > Any preference? Ciao, Michael.

Re: RFA: Generate normal DWARF DW_LOC descriptors for non integer mode pointers

On 05/17/2016 06:37 AM, Nick Clifton wrote: Hi Jeff, Currently dwarf2out.c:mem_loc_descriptor() has some special case code to handle the situation where an address is held in a register whose mode is not of type MODE_INT. It generates a DW_OP_GNU_regval_type expression which may later

Re: [PATCH, wide-int] change fixed_wide_int_storage from class to struct

On May 15, 2016, at 1:30 PM, Andrew Pinski wrote: > > Can we recommend that clang disable this warning by default instead? No. We want to ensure the class/struct tags match as there is no good reason to have them differ. > Or use an option flag to disable the warning while compiling gcc? Don

Re: [PATCH][AArch64] Adjust SIMD integer preference

ping From: Wilco Dijkstra Sent: 22 April 2016 16:35 To: gcc-patches@gcc.gnu.org Cc: nd Subject: [PATCH][AArch64] Adjust SIMD integer preference SIMD operations like combine prefer to have their operands in FP registers, so increase the cost of integer regi

Re: [PATCH][AArch64] Improve aarch64_modes_tieable_p

James Greenhalgh wrote: > It would be handy if you could raise something in bugzilla for the > register allocator deficiency. The register allocation issues are well known and we have multiple workarounds for this in place. When you allow modes to be tieable the workarounds are not as effective.

  1   2   >