[gomp4.1] Disallow modifiers on linear clause except in declare simd

Hi! Modifiers are only meaningful in declare simd construct, therefore latest OpenMP 4.5 disallows them on simd/for constructs. 2015-10-13 Jakub Jelinek c/ * c-typeck.c (c_finish_omp_clauses): Disallow modifiers on simd/for constructs. cp/ * semantics.c (finish_omp_cla

[gomp4.1] Disallow multiple depend(source) or mixing source + sink

Hi! Multiple depend(source) is useless and it has been agreed on that we should disallow it. Similarly, when mixing sink and source on the same ordered construct, we'd either need to define behavior for it, or disallow it, where the latter is what we've done for clarity reasons. The testcase als

[gomp4.1] Fixup nesting diagnostics for ordered depend, allow ordered without param on for simd

Hi! For ordered depend we unfortunately need to diagnose incorrect length or contents of the sink vec before OpenMP region nesting is diagnosed, so this patch diagnoses the incorrect nesting before the diagnostics, to avoid confusing errors. Also the patch allows ordered clause on for simd, but o

[gomp4.1] Add testcase for map clause bit-field diagnostics

Hi! Bit-fields are for obvious reasons disallowed in map clause (one can't take address of them, it would be too complicated and racy to move them to and from device), but we didn't have a testcase for it. 2015-10-13 Jakub Jelinek * c-c++-common/gomp/map-3.c: New test. --- gcc/testsu

[gomp4.1] Add testcase for negative linear step

Hi! The spec has been confusing and in one spot said that a linear step on declare simd has to be constant positive integer, which doesn't make sense, negative steps are just fine. As that is what we had implemented, this patch just adds a testcase for it. 2015-10-13 Jakub Jelinek *

[gomp4.1] Various ordered, linear and copyin tweaks

Hi! So, OpenMP 4.5 says that: 1) linear can be only specified for the loop iterator on distribute {, parallel for} simd (because distribute can't do firstprivate + lastprivate) 2) linear can't be specified at all on distribute parallel for 3) linear can't be specified on doacross loops (orde

Re: [PATCH][AArch64] Update patterns to support FP zero

On Thu, Oct 08, 2015 at 02:16:16PM +0100, Wilco Dijkstra wrote: > This patch improves support for instructions that allow FP zero immediate. > All FP compares generated > by various patterns should use aarch64_fp_compare_operand. LDP/STP uses > aarch64_reg_or_fp_zero. > Passes regression on AArch

Re: [PATCH ARM]: PR67745: Fix function alignment after __attribute__ 2/2

> > yes I see, I was hoping to avoid a new hook, but as you said it seems > mandatory for the mere declaration case. > > Here is one proposal, it defaults to nothing and the ARM implementation does > not need to handle the vptr bit setting. so that simplifies a lot the things. > > The hook is

Re: Do not use TYPE_CANONICAL in useless_type_conversion

On Oct 9, 2015, Jan Hubicka wrote: > ... we initialize mode to be non-VOIDmode only if the field is not bitfield. > I missed > the flag while looking at the dump. Indeed the DECL_MODE if FIELD_DECL is > SImode, > but it is ignored. > Hmm, it seems that for CALL_EXPR the register is supposed

Re: [PATCH][AArch64] Improve comparison with complex immediates followed by branch/cset

On 08/10/15 09:54, Kyrill Tkachov wrote: Hi all, This patch slightly improves sequences where we want to compare against a complex immediate and branch against the result or perform a cset on it. This means transforming sequences of mov+movk+cmp+branch into sub+subs+branch. Similar for cset. Un

Fix prototype for print_insn in rtl.h

Currently prototype for print_insn in rtl.h doesn't match it's definition in sched-vis.c The patch fixes this mismatch. Thanks, Nikolai 2015-10-13 Nikolai Bozhenov * gcc/rtl.h (print_insn): fix prototype diff --git a/gcc/rtl.h b/gcc/rtl.h index a592a1e..d6edc71 100644 --- a/gcc/rtl.h ++

[PATCH] More vectorizer TLC

Bootstrapped and tested on x86_64-unknown-linux-gnu, applied. Richard. 2015-10-13 Richard Biener * tree-vect-data-refs.c (vect_analyze_data_ref_dependences): Allocate the data dependence vector. (vect_peeling_hash_insert): Get the peeling hash table as argument.

Re: Do not use TYPE_CANONICAL in useless_type_conversion

On Tue, 13 Oct 2015, Alexandre Oliva wrote: > On Oct 9, 2015, Jan Hubicka wrote: > > > ... we initialize mode to be non-VOIDmode only if the field is not > > bitfield. I missed > > the flag while looking at the dump. Indeed the DECL_MODE if FIELD_DECL is > > SImode, > > but it is ignored. >

[PATCH] mark libstdc++ tests unsupported if they fail with "relocation truncated"

Dejagnu tweak: Check the compiler output in libstdc++-dg-test using ${tool}_check_unsupported_p and mark the output unsupported accordingly to avoid "relocation truncated" failures cluttering the test results on aarch64-none-elf with -mcmodel=tiny. (gcc torture tests already use this predicate for

Re: Do not use TYPE_CANONICAL in useless_type_conversion

> How about using in store_bit_field the same logic you added to > store_expr_with_bounds to get input MEMs to have a compatible mode? > This patch was regstrapped on i686-linux-gnu and x86_64-linux-gnu. Ok > to install? > > > support BLKmode inputs for store_bit_field > > From: Alexandre Oliva

Re: [PATCH] Random shuffle moveable: container size

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 name is libstdc++ !!! :-) It also make some minor changes such as: *D

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

On 09/10/15 10:17, 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 turned on. The problem was that the flow of control from

[gomp4.1] Fix up gimple_copy for GIMPLE_OMP_ORDERED clauses

Hi! We forgot to update gimple_copy when clauses were added to GIMPLE_OMP_ORDERED. Fixed thusly: 2015-10-13 Jakub Jelinek * gimple.c (gimple_copy): Unshare clauses on GIMPLE_OMP_ORDERED. --- gcc/gimple.c.jj 2015-10-13 09:39:21.0 +0200 +++ gcc/gimple.c2015-10-13 1

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

> 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 ((LOC), UNITS_PER_WORD * 2) > > The one above uses UNITS_PE

Re: [PATCH 8/9] Add TARGET_ADDR_SPACE_ZERO_ADDRESS_VALID

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. >>> >>> >>> >>> Nope, that doesn't

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

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: 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: 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: [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.

[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

[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 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 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 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 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 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

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

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: 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: 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

[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

[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

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

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));

[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: 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

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: [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 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: 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

[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: [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

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] 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: [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 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

[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] 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

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: [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: [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

[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: [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

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: [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

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: [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: [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 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

[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: [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

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

[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: [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.

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: [[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: [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: [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] 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] 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] 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] [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:

[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: 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

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: [[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

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 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: [[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: [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: [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: [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

[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: [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

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, -

[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: 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. --

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

[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 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.

[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/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] 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] 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,

  1   2   >