Re: Move some bit and binary optimizations in simplify and match

+(simplify + (plus (convert? @0) (convert? (xdivamulminusa @0 @1))) + (if ((INTEGRAL_TYPE_P (type) || VECTOR_INTEGER_TYPE_P (type)) + && tree_nop_conversion_p (type, TREE_TYPE (@0))) + (trunc_mod (convert @0) (convert @1 See PR 67953. +(match (abitandnotb @0 @1) + (bit_and:c @0 (bi

Re: Move some bit and binary optimizations in simplify and match

Hi. >> please adjust also according to these comments. Adjusted the patch as per your comments. Please find attached the patch as per your comments. Please review the patch and let me know if any further modifications are required. Thanks, Naveendiff --git a/gcc/fold-const.c b/gcc/fold-const.c

Re: Do not use TYPE_CANONICAL in useless_type_conversion

> On Oct 13, 2015, Eric Botcazou wrote: > > > Note that this is PR middle-end/67912. > > Thanks. I added this piece of information to the ChangeLog entry, and > checked the patch in. Thanks, Alexandre. That indeed looks better than my variant of the patch. Does it also fix the IA-64 issue? Hon

Re: [PR67891] drop is_gimple_reg test from set_parm_rtl

On Oct 12, 2015, Richard Biener wrote: > On Sat, Oct 10, 2015 at 3:16 PM, Alexandre Oliva wrote: >> On Oct 9, 2015, Richard Biener wrote: >> >>> Ok. Note that I think emit_block_move shouldn't mess with the addressable >>> flag. >> >> I have successfully tested a patch that stops it from d

Re: using scratchpads to enhance RTL-level if-conversion: revised patch

On 10/14/2015 12:05 PM, Richard Henderson wrote: If you're using one of the switches that checks for stack overflow at the start of the function, you certainly don't want to do any such stores. Oh, and for a given target the kernel may consider any write to the stack vma below the stack pointe

Re: using scratchpads to enhance RTL-level if-conversion: revised patch

On 10/09/2015 12:23 AM, Bernd Schmidt wrote: On 10/08/2015 01:29 AM, Abe wrote: Attached please find my revised patch to the RTL if converter. This patch enables the if-conversion of half-hammocks with a store in them that the internal GCC machinery otherwise considers too hazardous to if-conve

Re: [Patch] PowerPC IEEE 128-bit patch #7 (revised #2)

On Tue, 13 Oct 2015, Michael Meissner wrote: > I believe every non-NaN value that IBM extended double supports is > representable in IEEE 754R 128-bit floating point, since IEEE has 112 bits of > mantissa plus the hidden bit, while IBM extended double has 106 bits (52 bits > of mantissa for each p

[PATCH] c/67925 - update documentation on `inline'

* gcc/doc/extend.texi: documentation says that functions declared `inline' would not be integrated if they are called before they are defined or if they are recursive. Both of these statements is now false as shown in examples on Bugzilla. --- gcc/doc/extend.texi | 9 +++-- 1 file changed, 3 i

Re: [PATCH, 3/5] Handle original loop tree in expand_omp_for_generic

Hi Tom! On Mon, 12 Oct 2015 18:56:29 +0200, Tom de Vries wrote: > Handle original loop tree in expand_omp_for_generic > > 2015-09-12 Tom de Vries > > PR tree-optimization/67476 > * omp-low.c (expand_omp_for_generic): Handle original loop tree. Working on a merge from trunk into

Re: [PATCH 1/9] ENABLE_CHECKING refactoring

On 10/05/2015 05:27 PM, Mikhail Maltsev wrote: Hi! This is an updated series of patches which converts 'ENABLE_CHECKING' macro into a flag, 'flag_checking' (and 'CHECKING_P' macro in several cases). For now flag_checking is always initialized with the value of 'CHECKING_P', but later it can be t

Re: [PATCH 8/9] Add TARGET_ADDR_SPACE_ZERO_ADDRESS_VALID

On 10/14/2015 02:49 AM, Jeff Law wrote: The problem here is we don't know what address space the *0 is going to hit, right? Correct, not before we do the walk of stmt to see what's present. Isn't that also an issue for code generation as well? What sort of problem are you thinking of? I ha

[GOOGLE] Reduce max-vartrack-size

Reduce the maximum variable tracking size by 20% to avoid extreme compilation times. Ok for google-4_9? 2015-10-13 Teresa Johnson Google ref b/24569916 * params.def (PARAM_MAX_VARTRACK_SIZE): Reduce default to 40M. Index: params.def ===

Re: [gomp4] privatize internal array variables introduced by the fortran FE

On 10/13/2015 01:29 PM, Jakub Jelinek wrote: > On Tue, Oct 13, 2015 at 01:12:25PM -0700, Cesar Philippidis wrote: >> Arrays in fortran have a couple of internal variables associated with >> them, e.g. stride, lbound, ubound, size, etc. Depending on how and where >> the array was declared, these int

Re: [gomp4] privatize internal array variables introduced by the fortran FE

On Tue, Oct 13, 2015 at 01:12:25PM -0700, Cesar Philippidis wrote: > Arrays in fortran have a couple of internal variables associated with > them, e.g. stride, lbound, ubound, size, etc. Depending on how and where > the array was declared, these internal variables may be packed inside an > array de

Re: using scratchpads to enhance RTL-level if-conversion: revised patch

_Potentially_ so, yes. However, GCC is free to put the allocation into an otherwise-unused part of the stack frame. Well, I looked at code generation changes, and it usually seems to come with an increase in stack frame size - sometimes causing extra instructions to be emitted. However, wh

[gomp4] privatize internal array variables introduced by the fortran FE

Arrays in fortran have a couple of internal variables associated with them, e.g. stride, lbound, ubound, size, etc. Depending on how and where the array was declared, these internal variables may be packed inside an array descriptor represented by a struct or defined individually. The major problem

Re: [gomp4.1] Add new versions of GOMP_target{,_data,_update} and GOMP_target_enter_exit_data

On Tue, Oct 13, 2015 at 05:48:11PM +0300, Ilya Verbin wrote: > On Mon, Jun 15, 2015 at 22:48:50 +0300, Ilya Verbin wrote: > > @@ -950,50 +997,41 @@ GOMP_target (int device, void (*fn) (void *), const > > void *unused, > > ... > > + devicep->run_func (devicep->target_id, fn_addr, (void *) > > tgt

[PATCH, i386]: Use CEIL where applicable.

No functional changes. 2015-10-13 Uros Bizjak * config/i386/i386.c (classify_argument): Use CEIL where applicable. (ix86_function_arg_advance): Ditto. (ix86_function_arg): Ditto. (ix86_gimplify_va_arg): Ditto. (ix86_class_max_nregs): Ditto. (inline_memory_move_cost): Di

Re: [PATCH] reduce size penalty for including C++11 on x86 systems

On 13/10/15 21:44 -0400, Nathan Froyd wrote: Including in C++11 mode (typically done for std::{min,max,swap}) includes , for std::uniform_int_distribution. On x86 platforms, manages to drag in through x86's opt_random.h header, and has gotten rather large recently with the addition of AVX in

Re: [Patch] PowerPC IEEE 128-bit patch #7 (revised #2)

On Thu, Oct 08, 2015 at 09:30:45PM +, Joseph Myers wrote: > Question: what happens if you mix __float128 and __ibm128 in an arithmetic > or conditional expression? > > __float128 a; > __ibm128 b; > int x; > /* ... */ > a + b; > x ? a : b; > > (And likewise if one or both are the correspondin

Re: [PATCH] v4 of diagnostic_show_locus and rich_location

On Mon, 2015-10-12 at 17:36 +0100, Manuel López-Ibáñez wrote: > On 12 October 2015 at 16:44, David Malcolm wrote: > > v4 of the patch does the conversion of Fortran, and eliminates the > > adaptation layer. No partial transitions here! > > > > Manu: I hope this addresses your concerns. > > Yes,

[PATCH] reduce size penalty for including C++11 on x86 systems

From: Nathan Froyd Including in C++11 mode (typically done for std::{min,max,swap}) includes , for std::uniform_int_distribution. On x86 platforms, manages to drag in through x86's opt_random.h header, and has gotten rather large recently with the addition of AVX intrinsics. The comparison

Re: [patch 0/6] scalar-storage-order merge (2)

> My main question about this series is - how generally useful do you > expect it to be? I know of some different projects that would like > bi-endian capability, but it looks like this series implements something > that is a little too limited to be of use in these cases. AdaCore has customers wh

[PATCH] c++/67942 - diagnose placement new buffer overflow

C++ placement new expression is susceptible to buffer overflow flaws (see [1]). In many such cases GCC has sufficient information to detect and diagnose such defects. The attached patch is a starting point for this feature. It lets GCC diagnose basic cases of buffer overflows when both the size

Re: [PATCH 0/7] Libsanitizer merge from upstream r249633.

On Tue, Oct 13, 2015 at 4:13 AM, Maxim Ostapenko wrote: > Hi, > > it's been a while since the last libsanitizer merge from upstream into GCC > happened and the library has significantly changed since that time. The main > features to be ported are: > > -New common strings interceptors were added.

[PATCHv2, ARM, libgcc] New aeabi_idiv function for armv6-m

This patch ports the aeabi_idiv routine from Linaro Cortex-Strings (https://git.linaro.org/toolchain/cortex-strings.git), which was contributed by ARM under Free BSD license. The new aeabi_idiv routine is used to replace the one in libgcc/config/arm/lib1funcs.S. This replacement happens within

Re: [patch 5/6] scalar-storage-order merge: rest

On 10/06/2015 05:05 AM, Eric Botcazou wrote: This is the rest of the implementation. * asan.c (instrument_derefs): Adjust call to get_inner_reference. * builtins.c (get_object_alignment_2): Likewise. * cfgexpand.c (expand_debug_expr): Adjust call to get_inner_reference

Re: Do not use TYPE_CANONICAL in useless_type_conversion

On Oct 13, 2015, Eric Botcazou wrote: > Note that this is PR middle-end/67912. Thanks. I added this piece of information to the ChangeLog entry, and checked the patch in. -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. --

[PATCH] Optimize const1 * copysign (const2, y) in reassoc (PR tree-optimization/67815)

This patch implements the copysign optimization for reassoc I promised I'd look into. I.e., CST1 * copysign (CST2, y) -> copysign (CST1 * CST2, y) if CST1 > 0 CST1 * copysign (CST2, y) -> -copysign (CST1 * CST2, y) if CST1 < 0 After getting familiar with reassoc a bit this wasn't that hard. But

Re: [gomp4, committed] Move kernels pass group before pass_fre

On 13/10/15 17:59, Tom de Vries wrote: Hi, this patch moves the kernels pass group to before pass_fre. Instead we use pass_dominator_oacc_kernels in the pass group. And that means we can get rid of the .omp_data_i init handling in tree-ssa-sccvn.c. Committed to gomp-4_0-branch. Thanks, -

Re: [patch 4/6] scalar-storage-order merge: bulk

On 10/06/2015 05:04 AM, Eric Botcazou wrote: This is the bulk of the implementation. * calls.c (store_unaligned_arguments_into_pseudos): Adjust calls to extract_bit_field and store_bit_field. (initialize_argument_information): Adjust call to store_expr. (load_regi

[gomp4, committed] Move kernels pass group before pass_fre

Hi, this patch moves the kernels pass group to before pass_fre. Instead we use pass_dominator_oacc_kernels in the pass group. This fixes an ICE while compiling the test-case included in the patch. Committed to gomp-4_0-branch. Thanks, - Tom Move kernels pass group before pass_fre 2015-10-13

Re: [Boolean Vector, patch 3/5] Use boolean vector in C/C++ FE

2015-10-13 18:42 GMT+03:00 Jeff Law : > On 10/13/2015 08:14 AM, Ilya Enkovich wrote: + +static tree +build_vec_cmp (tree_code code, tree type, + tree arg0, tree arg1) +{ + tree zero_vec = build_zero_cst (type); + tree minus_one_vec = build_minu

Re: [gomp4, committed] Add goacc/kernels-acc-on-device.c

On 12/10/15 14:52, Tom de Vries wrote: On 12/10/15 12:49, Thomas Schwinge wrote: Hi Tom! On Sat, 10 Oct 2015 12:49:01 +0200, Tom de Vries wrote: >--- /dev/null >+++ b/gcc/testsuite/c-c++-common/goacc/kernels-acc-on-device.c >@@ -0,0 +1,39 @@ >+/* { dg-additional-options "-O2" } */ >+ >+#inclu

Re: [PATCH 8/9] Add TARGET_ADDR_SPACE_ZERO_ADDRESS_VALID

On 10/13/2015 04:13 AM, Richard Biener wrote: On Tue, Oct 13, 2015 at 1:27 AM, Richard Henderson wrote: On 10/12/2015 09:10 PM, Richard Biener wrote: The check_loadstore change should instead have adjusted the flag_delete_null_pointer_checks guard in infer_nonnull_range_by_dereference. No

Re: [[Boolean Vector, patch 5/5] Support boolean vectors in vector lowering

2015-10-13 18:35 GMT+03:00 Jeff Law : > On 10/13/2015 08:56 AM, Ilya Enkovich wrote: >> >> 2015-10-12 13:37 GMT+03:00 Alan Lawrence : >>> >>> On 09/10/15 22:01, Jeff Law wrote: >>> So my question for the series as a whole is whether or not we need to do something for the other languages,

Re: [Boolean Vector, patch 3/5] Use boolean vector in C/C++ FE

On 10/13/2015 08:14 AM, Ilya Enkovich wrote: + +static tree +build_vec_cmp (tree_code code, tree type, + tree arg0, tree arg1) +{ + tree zero_vec = build_zero_cst (type); + tree minus_one_vec = build_minus_one_cst (type); + tree cmp_type = build_same_sized_truth_vector_type (type)

Re: [Patch] [x86_64]: Add bdver4 for multi versioning and fix AMD cpu model detection.

On Tue, Oct 13, 2015 at 5:16 PM, Kumar, Venkataramanan wrote: > Hi Uros, > > I realized both GCC 4.9 and GCC 5 branches includes processor subtype > AMDFAM15H_BDVER4. > So I need to back port not only model selection fix but also the detection of > model for bdver4. > > Is that fine? OK, but to

Re: [[Boolean Vector, patch 5/5] Support boolean vectors in vector lowering

On 10/13/2015 08:56 AM, Ilya Enkovich wrote: 2015-10-12 13:37 GMT+03:00 Alan Lawrence : On 09/10/15 22:01, Jeff Law wrote: So my question for the series as a whole is whether or not we need to do something for the other languages, particularly Fortran. I was a bit surprised to see this stuff

Benchmarks of v2 (was Re: [PATCH 0/5] RFC: Overhaul of diagnostics (v2))

On Thu, 2015-09-24 at 10:15 +0200, Richard Biener wrote: > On Thu, Sep 24, 2015 at 2:25 AM, David Malcolm wrote: > > On Wed, 2015-09-23 at 15:36 +0200, Richard Biener wrote: > >> On Wed, Sep 23, 2015 at 3:19 PM, Michael Matz wrote: > >> > Hi, > >> > > >> > On Tue, 22 Sep 2015, David Malcolm wrote

Re: Fix prototype for print_insn in rtl.h

On 10/13/2015 02:21 AM, Nikolai Bozhenov wrote: 2015-10-13 Nikolai Bozhenov * gcc/rtl.h (print_insn): fix prototype Installed on the trunk after bootstrap & regression test. jeff

[PATCH v2] PR rtl-optimization/66790: uninitialized registers handling in REE

Hello, The first attached patch is the second attempt to fix PR rtl-optimization/66790 (see ). The second one is a fix for some inconsistency noticed while working on the original bug. This specific patch fixes no known bug, but anyway… B

RE: [Patch] [x86_64]: Add bdver4 for multi versioning and fix AMD cpu model detection.

Hi Uros, I realized both GCC 4.9 and GCC 5 branches includes processor subtype AMDFAM15H_BDVER4. So I need to back port not only model selection fix but also the detection of model for bdver4. Is that fine? Regards, Venkat. > -Original Message- > From: Kumar, Venkataramanan > Sent:

Re: [PATCH] gcc/ira.c: Check !HAVE_FP_INSTEAD_INSNS when frame pointer is needed and as global register

On 10/13/15 22:56, Bernd Schmidt wrote: > On 10/13/2015 04:50 PM, Chen Gang wrote: >> OK, under the bugzilla, the maintainer treated it as expected behavior >> (not a bug). For me, we need more explanation for it (why we treat it >> as expected behavior). > > A global register is under control of

Re: [PATCH] Fix "#pragma GCC pop_options" warning.

On 10/13/2015 05:03 PM, Dominik Vogt wrote: On Tue, Oct 13, 2015 at 04:33:42PM +0200, Bernd Schmidt wrote: Looks like ix86_pragma_target_parse has a "! args" test to determine if it has a pop, maybe the default function could do the same. All right, this solution is way better. New patch atta

Re: [PATCH] Fix "#pragma GCC pop_options" warning.

On Tue, Oct 13, 2015 at 04:33:42PM +0200, Bernd Schmidt wrote: > Looks like > ix86_pragma_target_parse has a "! args" test to determine if it has > a pop, maybe the default function could do the same. All right, this solution is way better. New patch attached. Ciao Dominik ^_^ ^_^ -- Domini

Re: [PATCH] gcc/ira.c: Check !HAVE_FP_INSTEAD_INSNS when frame pointer is needed and as global register

On 10/13/15 07:02, Mike Stump wrote: > On Oct 12, 2015, at 3:32 PM, Chen Gang wrote: >> >> OK, thanks. If we really need to fix it, which target hook should I use? >> (or do we need a new target hook?) > > So, the first discussion would be if it is, or is not a bug. If it isn’t, > then there i

Re: [PATCH] gcc/ira.c: Check !HAVE_FP_INSTEAD_INSNS when frame pointer is needed and as global register

On 10/13/2015 04:50 PM, Chen Gang wrote: OK, under the bugzilla, the maintainer treated it as expected behavior (not a bug). For me, we need more explanation for it (why we treat it as expected behavior). A global register is under control of the user. If the compiler uses it as a frame pointe

Re: [[Boolean Vector, patch 5/5] Support boolean vectors in vector lowering

2015-10-12 13:37 GMT+03:00 Alan Lawrence : > On 09/10/15 22:01, Jeff Law wrote: > >> So my question for the series as a whole is whether or not we need to do >> something for the other languages, particularly Fortran. I was a bit >> surprised to see this stuff bleed into the C/C++ front-ends and >

Re: [vec-cmp, patch 4/6] Support vector mask invariants

2015-10-13 16:54 GMT+03:00 Richard Biener : > On Thu, Oct 8, 2015 at 5:11 PM, Ilya Enkovich wrote: >> Hi, >> >> This patch adds a special handling of boolean vector invariants. We need >> additional code to determine type of generated invariant. For VEC_COND_EXPR >> case we even provide this t

Re: [gomp4.1] Add new versions of GOMP_target{,_data,_update} and GOMP_target_enter_exit_data

On Mon, Jun 15, 2015 at 22:48:50 +0300, Ilya Verbin wrote: > @@ -950,50 +997,41 @@ GOMP_target (int device, void (*fn) (void *), const > void *unused, > ... > + devicep->run_func (devicep->target_id, fn_addr, (void *) > tgt_vars->tgt_start); If mapnum is 0, tgt_vars->tgt_start is uninitialized.

[HSA] Fix emission of hsa_num_threads

Hello. Following pair of patches changes behavior of omp_{get,set}_num_threads and provides more clever way how these values are passed to a another kernel. Martin >From 1d2732a0e33259e73a2d8059fb5f68e359144ef6 Mon Sep 17 00:00:00 2001 From: marxin Date: Thu, 8 Oct 2015 11:21:16 +0200 Subject: [

Re: [PATCH] Fix "#pragma GCC pop_options" warning.

On 10/13/2015 03:31 PM, Dominik Vogt wrote: On Tue, Oct 13, 2015 at 02:28:37PM +0200, Bernd Schmidt wrote: On 10/13/2015 02:02 PM, Dominik Vogt wrote: When "#pragma GCC pop_options" is used on a platform without support for "#pragma GCC target", Gcc emits a warning. As pop_options is useful on

Re: [Boolean Vector, patch 3/5] Use boolean vector in C/C++ FE

On 09 Oct 14:51, Jeff Law wrote: > On 10/02/2015 08:04 AM, Ilya Enkovich wrote: > >Hi, > > > >This patch makes C/C++ FE to use boolean vector as a resulting type for > >vector comparison. As a result vector comparison in source code now parsed > >into VEC_COND_EXPR, it required a testcase fix-up

[hsa] Fix bitfield alignment ICEs

Hi, yesterday I did not notice that I introduced an ICE on testcases with bit-field memory accesses. The following fixes the issue. A better solution would be to expand the bit-field parts of memory expressions separately, which would often allow us to use better aligned accesses, but that is no

Re: [vec-cmp, patch 4/6] Support vector mask invariants

On Thu, Oct 8, 2015 at 5:11 PM, Ilya Enkovich wrote: > Hi, > > This patch adds a special handling of boolean vector invariants. We need > additional code to determine type of generated invariant. For VEC_COND_EXPR > case we even provide this type directly because statement vectype doesn't > a

Re: [vec-cmp, patch 3/6] Vectorize comparison

On Thu, Oct 8, 2015 at 5:03 PM, Ilya Enkovich wrote: > Hi, > > This patch supports comparison statements vectrization basing on introduced > optabs. > > Thanks, > Ilya > -- > gcc/ > > 2015-10-08 Ilya Enkovich > > * tree-vect-data-refs.c (vect_get_new_vect_var): Support > vect_mask_var

Re: [vec-cmp, patch 2/6] Vectorization factor computation

On Thu, Oct 8, 2015 at 4:59 PM, Ilya Enkovich wrote: > Hi, > > This patch handles statements with boolean result in vectorization factor > computation. For comparison its operands type is used instead of restult > type to compute VF. Other boolean statements are ignored for VF. > > Vectype for

Re: [Boolean Vector, patch 1/5] Introduce boolean vector to be used as a vector comparison type

2015-10-13 16:17 GMT+03:00 Richard Biener : > On Fri, Oct 9, 2015 at 10:43 PM, Jeff Law wrote: >> On 10/02/2015 07:59 AM, Ilya Enkovich wrote: >>> >>> 2015-10-02 Ilya Enkovich >>> >>> * doc/tm.texi: Regenerated. >>> * doc/tm.texi.in (TARGET_VECTORIZE_GET_MASK_MODE): New. >>>

Re: [PATCH] Fix "#pragma GCC pop_options" warning.

On Tue, Oct 13, 2015 at 02:28:37PM +0200, Bernd Schmidt wrote: > On 10/13/2015 02:02 PM, Dominik Vogt wrote: > >When "#pragma GCC pop_options" is used on a platform without > >support for "#pragma GCC target", Gcc emits a warning. As > >pop_options is useful on targets without the target pragma to

Re: [Boolean Vector, patch 1/5] Introduce boolean vector to be used as a vector comparison type

On 09 Oct 14:43, Jeff Law wrote: > On 10/02/2015 07:59 AM, Ilya Enkovich wrote: > >+This hook returns mode to be used for a mask to be used for a vector > >+of specified @var{length} with @var{nunits} elements. > >+@end deftypefn > Does it make sense to indicate the default used if the target does

Re: [Boolean Vector, patch 1/5] Introduce boolean vector to be used as a vector comparison type

On Fri, Oct 9, 2015 at 10:43 PM, Jeff Law wrote: > On 10/02/2015 07:59 AM, Ilya Enkovich wrote: >> >> 2015-10-02 Ilya Enkovich >> >> * doc/tm.texi: Regenerated. >> * doc/tm.texi.in (TARGET_VECTORIZE_GET_MASK_MODE): New. >> * stor-layout.c (layout_type): Use mode to get v

[gomp4.1] Testsuite tweaks

Hi! This patch fixes issues in tests I'm not running all the time during gomp branch development (basically I do just RUNTESTFLAGS=gomp.exp in gcc subdir and check-target-libgomp). 2015-10-13 Jakub Jelinek * c-c++-common/cpp/openmp-define-3.c: Adjust for the new value of _OPEN

Re: [AArch64_be] Fix vtbl[34] and vtbx4

On Tue, Oct 13, 2015 at 02:05:01PM +0100, Christophe Lyon wrote: > I commited this as r228716, and noticed later that > gcc.target/aarch64/table-intrinsics.c failed because of this patch. > > This is because that testcase scans the assembly for 'tbl v' or 'tbx > v', but since I replaced some asm s

Re: [AArch64_be] Fix vtbl[34] and vtbx4

On 12 October 2015 at 15:30, James Greenhalgh wrote: > On Fri, Oct 09, 2015 at 05:16:05PM +0100, Christophe Lyon wrote: >> On 8 October 2015 at 11:12, James Greenhalgh >> wrote: >> > On Wed, Oct 07, 2015 at 09:07:30PM +0100, Christophe Lyon wrote: >> >> On 7 October 2015 at 17:09, James Greenhal

Re: Fix prototype for print_insn in rtl.h

On 10/13/2015 06:41 AM, Nikolai Bozhenov wrote: On 10/13/2015 03:22 PM, Jeff Law wrote: On 10/13/2015 02:21 AM, Nikolai Bozhenov wrote: Currently prototype for print_insn in rtl.h doesn't match it's definition in sched-vis.c The patch fixes this mismatch. I'll run this through the usual bootst

Re: [PATCH] Random shuffle moveable: container size

On Tue, Oct 13, 2015 at 6:26 AM, Jonathan Wakely wrote: > On 08/10/15 10:35 -0300, Aurelio Remonda wrote: >> >> This patch reduces the size of the array A (the array that contains >> the values being shuffled) so the test can pass while running the >> stdlibc++ testsuite. > > > Ahem! The project's

[gomp4.1] jit and ada fixes

Hi! When bootstrapping/regtesting, I found small omissions, fixed thusly: 2015-10-13 Jakub Jelinek gcc/ada/ * gcc-interface/utils.c (DEF_FUNCTION_TYPE_9, DEF_FUNCTION_TYPE_10, DEF_FUNCTION_TYPE_11): Define. gcc/jit/ * jit-builtins.h (DEF_FUNCTION_TYPE_9, DEF_FUNCTION_T

Re: [PATCH PR67909 PR67947]

On Tue, Oct 13, 2015 at 2:49 PM, Yuri Rumyantsev wrote: > Here is updated patch with splitting long line. > The patch is attached. Ok with aligning the guard_edge == ... line properly Thanks, Richard. > Yuri. > > 2015-10-13 15:38 GMT+03:00 H.J. Lu : >> On Tue, Oct 13, 2015 at 4:57 AM, Yuri Rumy

Re: [RFC VTV] Fix VTV for targets that have section anchors.

On 12/10/15 21:44, Jeff Law wrote: > On 10/09/2015 03:17 AM, Ramana Radhakrishnan wrote: >> This started as a Friday afternoon project ... >> >> It turned out enabling VTV for AArch64 and ARM was a matter of fixing >> PR67868 which essentially comes from building libvtv with section >> anchors t

Re: [PATCH] Allow FSM to thread single block cases too

On Tue, Oct 13, 2015 at 2:21 PM, Jeff Law wrote: > > One of the cases that was missing in the FSM support is threading when the > path is a single block. ie, a control statement's output can be statically > determined just by looking at PHIs in the control statement's block for one > or incoming

Re: Move some bit and binary optimizations in simplify and match

On Tue, Oct 13, 2015 at 2:18 PM, Marc Glisse wrote: > On Tue, 13 Oct 2015, Richard Biener wrote: > >> +/* Simplify ~X & X as zero. */ >> +(simplify >> + (bit_and:c (convert? @0) (convert? (bit_not @0))) >> + (if (tree_nop_conversion_p (type, TREE_TYPE (@0))) > > > The test seems unnecessary for

Re: [PATCH PR67909 PR67947]

Here is updated patch with splitting long line. The patch is attached. Yuri. 2015-10-13 15:38 GMT+03:00 H.J. Lu : > On Tue, Oct 13, 2015 at 4:57 AM, Yuri Rumyantsev wrote: >> Hi All, >> >> Here is a simple patch for unswitching outer loop through guard-edge >> hoisting. The check that guard-edge

[gomp4] More openacc loop indirection

I've committed this next patch in my series to move loop partitioning decisions to the target compiler. It introduces 2 more IFN_UNIQUE cases, marking the head and tail sequences of an openACC loop. These are added around the reduction and fork/join regions. In the oacc_device_lower pass we

Re: Fix prototype for print_insn in rtl.h

On 10/13/2015 03:22 PM, Jeff Law wrote: On 10/13/2015 02:21 AM, Nikolai Bozhenov wrote: Currently prototype for print_insn in rtl.h doesn't match it's definition in sched-vis.c The patch fixes this mismatch. I'll run this through the usual bootstrap & regression testing before installing later

Re: [PATCH PR67909 PR67947]

On Tue, Oct 13, 2015 at 4:57 AM, Yuri Rumyantsev wrote: > Hi All, > > Here is a simple patch for unswitching outer loop through guard-edge > hoisting. The check that guard-edge is around the inner loop was > missed. > > Bootstrapping and regression testing did not show new failures. > > Is it OK f

Re: [PR debug/67192] Fix C loops' back-jump location

On 10/12/2015 04:04 PM, Andreas Arnez wrote: Since r223098 ("Implement -Wmisleading-indentation") the backward-jump generated for a C while- or for-loop can get the wrong line number. This is because the check for misleading indentation peeks ahead one token, advancing input_location to after the

Re: [PATCH] Fix "#pragma GCC pop_options" warning.

On 10/13/2015 02:02 PM, Dominik Vogt wrote: When "#pragma GCC pop_options" is used on a platform without support for "#pragma GCC target", Gcc emits a warning. As pop_options is useful on targets without the target pragma to restore optimizations flags, the warning should be removed. The attach

Re: Fix prototype for print_insn in rtl.h

On 10/13/2015 02:21 AM, Nikolai Bozhenov wrote: Currently prototype for print_insn in rtl.h doesn't match it's definition in sched-vis.c The patch fixes this mismatch. I'll run this through the usual bootstrap & regression testing before installing later today. jeff

[PATCH] Allow FSM to thread single block cases too

One of the cases that was missing in the FSM support is threading when the path is a single block. ie, a control statement's output can be statically determined just by looking at PHIs in the control statement's block for one or incoming edges. This is necessary to fix a regression if I tur

Re: Move some bit and binary optimizations in simplify and match

On Tue, 13 Oct 2015, Richard Biener wrote: +/* Simplify ~X & X as zero. */ +(simplify + (bit_and:c (convert? @0) (convert? (bit_not @0))) + (if (tree_nop_conversion_p (type, TREE_TYPE (@0))) The test seems unnecessary for this specific transformation. + { build_zero_cst (TREE_TYPE (@0));

Re: [PATCH] x86 interrupt attribute

Here is the current version of the patch with all the fixes. Regtested\bootstraped it on 64 bit. We need a pointer since interrupt handler will update data pointing to by frame. Since error_code isn't at the normal location where the parameter is passed on stack and frame isn't in a hard register

[PATCH] Fix "#pragma GCC pop_options" warning.

When "#pragma GCC pop_options" is used on a platform without support for "#pragma GCC target", Gcc emits a warning. As pop_options is useful on targets without the target pragma to restore optimizations flags, the warning should be removed. The attached patch does that rather inelegantly by check

[PATCH PR67909 PR67947]

Hi All, Here is a simple patch for unswitching outer loop through guard-edge hoisting. The check that guard-edge is around the inner loop was missed. Bootstrapping and regression testing did not show new failures. Is it OK for trunk? ChangeLog: 2014-10-13 Yuri Rumyantsev PR tree-optimizatio

Re: Move some bit and binary optimizations in simplify and match

On Tue, Oct 13, 2015 at 12:52 PM, Hurugalawadi, Naveen wrote: > Hi Richard, > > Thanks for the comments. Sorry, I was confused with handling the const and > variable > together part. Have modified them. > Also, considered that both (X & Y) can be const or variable in those cases > for which match

Re: Move some bit and binary optimizations in simplify and match

On Tue, 13 Oct 2015, Hurugalawadi, Naveen wrote: Please find attached the patch as per your comments. (hmm, maybe you missed the email I sent with other comments?) +(simplify + (plus (convert? @0) (convert? (xdivamulminusa @0 @1))) + (if ((INTEGRAL_TYPE_P (type) || VECTOR_INTEGER_TYPE_P (typ

Re: [patch 2/6] scalar-storage-order merge: C front-end

On 10/06/2015 05:02 AM, Eric Botcazou wrote: This is the C front-end + C family part. * doc/extend.texi (type attributes): Document scalar_storage_order. (Structure-Packing Pragmas): Rename into... (Structure-Layout Pragmas): ...this. Document scalar_storage_order.

Re: [PATCH] PR66870 PowerPC64 Enable gold linker with split stack

On 13.10.2015 00:53, Alan Modra wrote: On Mon, Oct 12, 2015 at 10:15:04AM -0500, Lynn A. Boger wrote: Thanks for doing this Alan. I agree this looks better to me. I assume by "etc" you mean you did biarch builds for your bootstraps on BE? By "etc" I meant "and regression tested". I built fo

[PATCH 7/7] Libsanitizer merge from upstream r249633.

This is the final patch. Force libsanitizer to use an old ABI for ubsan float cast data descriptors, because for some exprs (e.g. that type of tcc_declaration) we can't get the right location for now. I'm not sure about this, perhaps it should be fixed in GCC somehow. 2015-10-13 Maxim Ostapenko

[PATCH 6/7] Libsanitizer merge from upstream r249633.

This patch adjusts the fix for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61771 to extract the last PC from the stack frame if no valid FP is available for ARM. 2015-10-13 Maxim Ostapenko * sanitizer_common/sanitizer_stacktrace.cc (GetCanonicFrame): Assume we compiled code with GCC when e

[PATCH 5/7] Libsanitizer merge from upstream r249633.

This patch removes UBSan stubs from ASan and TSan code. We don't embed UBSan to ASan and UBSan because that would lead to undefined references to C++ stuff when linking with -static-libasan. AFAIK, sanitizer developers use different libraries for C and CXX runtimes, but I think this is out of s

[PATCH 4/7] Libsanitizer merge from upstream r249633.

This is a reapplied Jakub's patch for disabling ODR violation detection. More details can be found here (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63888). 2015-10-12 Maxim Ostapenko PR bootstrap/63888 Reapply: 2015-02-20 Jakub Jelinek * asan/asan_globals.cc (RegisterGlobal): Disabl

[PATCH 3/7] Libsanitizer merge from upstream r249633.

This is just reapplied patch for SPARC by David S. Miller. I was unable to test this, so could anyone help me here? 2015-10-12 Maxim Ostapenko PR sanitizer/63958 Reapply: 2015-03-09 Jakub Jelinek PR sanitizer/63958 Reapply: 2014-10-14 David S. Miller * sanitizer_common/sanitizer

[PATCH 2/7] Libsanitizer merge from upstream r249633.

This patch introduces required compiler changes. Now, we don't version asan_init, we have a special __asan_version_mismatch_check_v[n] symbol for this. Also, asan_stack_malloc_[n] doesn't take a local stack as a second parameter anymore, so don't pass it. 2015-10-12 Maxim Ostapenko config/

[PATCH 0/7] Libsanitizer merge from upstream r249633.

Hi, it's been a while since the last libsanitizer merge from upstream into GCC happened and the library has significantly changed since that time. The main features to be ported are: -New common strings interceptors were added. -Various allocator improvements were performed. -Improvements for

Re: [ARM] Add ARMv8.1 command line options.

Some of the command line options may be unnecessary so I'll drop this patch. Matthew On 08/10/15 12:00, Matthew Wahab wrote: Ping. Updated patch attached, I've broken the over-long lines added to arm-arches.def and arm-fpus.def. Matthew On 17/09/15 18:54, Matthew Wahab wrote: Hello, ARMv8.

Re: Move some bit and binary optimizations in simplify and match

Hi Richard, Thanks for the comments. Sorry, I was confused with handling the const and variable together part. Have modified them. Also, considered that both (X & Y) can be const or variable in those cases for which match patterns have been added. Please let me know whether its correct or only "

Re: Fix 61441

Hi, This is another modified version of the patch, incorporating the previous comments. Bootstrap and regression tests on x86_64-linux-gnu and aarch64-unknown-linux-gnu passed with changes done on trunk. Is this fine ? Regards, Sujoy 2015-10-13 Sujoy Saraswati PR tree-optimization/6

Re: [PATCH, sparc]: Use ROUND_UP and ROUND_DOWN macros

> In this case, I think it is better to write this part as: > > --cut here-- > offset += 8; > > /* Always preserve double-word alignment. */ > offset = ROUND_DOWN (offset, 8); > --cut here-- Not convinced, having offset == 12 after the first line doesn't make sense. I'd just beef up the commen

Re: [PATCH, sparc]: Use ROUND_UP and ROUND_DOWN macros

On Tue, Oct 13, 2015 at 12:10 PM, Eric Botcazou wrote: >> Two functional changes I'd like to point out: >> >> /* ALIGN FRAMES on double word boundaries */ >> -#define SPARC_STACK_ALIGN(LOC) \ >> - (TARGET_ARCH64 ? (((LOC)+15) & ~15) : (((LOC)+7) & ~7)) >> +#define SPARC_STACK_ALIGN(LOC) ROUND_UP

  1   2   >