Re: PR 68432: Add a target hook to control size/speed optab choices

On 12/01/2015 10:15 PM, Richard Sandiford wrote: [This is a less invasive fix for the PR, without any changes to the .md attribute handling] As a minimal fix I like this much better. I'll ok it under the condition that you have verified in all ports that size/speed issues are the only

Re: [PATCH] fix PR65726

On 12/01/2015 02:50 PM, Andreas Tobler wrote: On 30.11.15 23:30, Jeff Law wrote: On 11/26/2015 11:49 AM, Andreas Tobler wrote: Hi all, the attached patch fixes the build issue from this ticket if bootstrap is disabled. Tested on x86_64-*-linux* and on x86_64-*-freebsd* with gcc and clang.

Re: [patch] RFC asan support for i?86/x86_64-*freebsd*

Hi! On 01.12.15 13:22, Uros Bizjak wrote: 2015-11-29 Andreas Tobler * config/i386/i386.h: Define two new macros: SUBTARGET_SHADOW_OFFSET_64 and SUBTARGET_SHADOW_OFFSET_32. * config/i386/i386.c (ix86_asan_shadow_offset): Use these macros. * config/i386/darwin.h:

Re: [RFA] Compact EH Patch

On 11/25/2015 11:58 AM, Moore, Catherine wrote: -Original Message- From: Richard Henderson [mailto:r...@redhat.com] Sent: Friday, September 18, 2015 3:25 PM To: Moore, Catherine; gcc-patches@gcc.gnu.org Cc: ja...@redhat.com; Matthew Fortune Subject: Re: [RFA] Compact EH Patch Index:

Re: PR68577: Handle narrowing for vector popcount, etc.

Richard Biener writes: > On Tue, Dec 1, 2015 at 10:14 AM, Richard Sandiford > wrote: >> diff --git a/gcc/tree-vect-stmts.c b/gcc/tree-vect-stmts.c >> index 3b078da..af86bce 100644 >> --- a/gcc/tree-vect-stmts.c >> +++ b/gcc/tree-vect-stmts.c

Re: [PATCH][PR tree-optimization/67816] Fix jump threading when DOM removes conditionals in jump threading path

On 10/09/2015 09:45 AM, Jeff Law wrote: Yes, but as you remove jump threading paths you could leave the CFG change to cfg-cleanup anyway? To get better behavior wrt loop fixup at least? So go ahead and detect, remove the threading paths, but leave final fixup to cfg-cleanup. I can certainly

RE: [RFA] Compact EH Patch

Ping? > -Original Message- > From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches- > ow...@gcc.gnu.org] On Behalf Of Moore, Catherine > Sent: Wednesday, November 25, 2015 11:58 AM > To: Richard Henderson; gcc-patches@gcc.gnu.org > Cc: ja...@redhat.com; Matthew Fortune > Subject: RE:

[C PATCH] Fix up location used in get_parm_info diagnostics (PR c/68533)

Hi! get_parm_info right now uses input_location as the diagnostics locus, but as can be seen on the testcase, that is pretty random location at that point, often the type of the last parameter. This patch changes it to use the locus from the binding info. Bootstrapped/regtested on x86_64-linux

PR 68432: Add a target hook to control size/speed optab choices

[This is a less invasive fix for the PR, without any changes to the .md attribute handling] The problem in the PR is that some i386 optabs FAIL when optimising for size rather than speed. The gimple level generally needs access to this information before calling the generator, so this patch

[PTX] uninitialized decls

This patch removes some more code duplication. ASM_OUTPUT_ALIGNED_DECL_COMMON & ASM_OUTPUT_ALIGNED_DECL_LOCAL had virtually identical definitions, so I fowarded them both to a new helper function. I noticed that: (a) a common decl could use .weak, which is closer to common semantics than a

Re: -fstrict-aliasing fixes 1/5: propagate -fno-strict-aliasing in the inliner

On December 1, 2015 12:05:39 AM GMT+01:00, Jan Hubicka wrote: >Hi, >this is first patch in the broken up series. It adds the logic into >ipa-inline-transform to drop the flag when inlining. I do it always >until >we find a way to make early optimizations safe WRT this transform.

Re: [patch] add ELFv2 check to FreeBSD PowerPC64

On 29.11.15 22:15, Andreas Tobler wrote: Hi all, I'd like to commit this patch to trunk. It is FreeBSD only. If nobody objects I'll commit it within two days. Thanks, Andreas 2015-11-29 Andreas Tobler * config/rs6000/freebsd64.h (ELFv2_ABI_CHECK): Add new

Re: [PATCH] RFC: Use Levenshtein spelling suggestions in Fortran FE

On Tue, Dec 01, 2015 at 12:58:28PM -0500, David Malcolm wrote: > On Tue, 2015-12-01 at 18:51 +0100, Bernhard Reutner-Fischer wrote: > > As said, we could as well use a list of candidates with NULL as record > > marker. > > Implementation cosmetics. Steve seems to not be thrilled by the > >

Re: RFD: annotate iterator patterns with expanded forms

On 12/01/2015 04:31 PM, Bernd Schmidt wrote: On 12/01/2015 04:23 PM, Jakub Jelinek wrote: With the comments in the *.md file I'd worry about them getting out of date, or people feeling they have to edit them manually (rather than being regenerated or whatever). I suppose we could have a

Re: [PATCH] fix PR65726

On 30.11.15 23:30, Jeff Law wrote: On 11/26/2015 11:49 AM, Andreas Tobler wrote: Hi all, the attached patch fixes the build issue from this ticket if bootstrap is disabled. Tested on x86_64-*-linux* and on x86_64-*-freebsd* with gcc and clang. Ok for trunk? And 5.3? Thanks, Andreas

Re: [PATCH] Empty redirect_edge_var_map after each pass and function

On 12/01/2015 11:33 AM, Alan Lawrence wrote: I was not able to reduce the testcase below about 30k characters, with e.g. #define T_VOID 0 T_VOID producing the ICE, but manually changing to 0 preventing the ICE; as did running the preprocessor as a separate step, or a wide

Re: Incorrect code due to indirect tail call of varargs function with hard float ABI

>> >> gcc/ChangeLog: >> >> 2015-11-18 Kugan Vivekanandarajah >> >> PR target/68390 >> * config/arm/arm.c (arm_function_ok_for_sibcall): Get function type >> for indirect function call. >> >> gcc/testsuite/ChangeLog: >> >> 2015-11-18 Kugan Vivekanandarajah

[google gcc-4_9] Fix bad LIPO profile produced by gcov-tool

Hi, This patch fixes the issue when using gcov-tool to merge LIPO profiles after we compressing the module infomration . We should not decompress the string as the compressed string should be written directly to the profile later. Tested with some LIPO profiles. Thanks, -Rong 2015-12-01 Rong

Re: Gimple loop splitting v2

On 12/01/2015 09:46 AM, Michael Matz wrote: Hi, So, okay for trunk? -ENOPATCH Jeff

Re: [PATCH] Handle BUILT_IN_GOACC_PARALLEL in ipa-pta

On 01/12/15 15:44, Jakub Jelinek wrote: On Tue, Dec 01, 2015 at 03:25:42PM +0100, Tom de Vries wrote: Handle BUILT_IN_GOACC_PARALLEL in ipa-pta 2015-12-01 Tom de Vries * tree-ssa-structalias.c (find_func_aliases_for_builtin_call) (find_func_clobbers,

[committed] Tighten runtime initialization check in __canonicalize_funcptr_for_compare on hppa-linux

The attached change fixes a startup issue of emacs24 on Debian hppa-linux. The emacs24 build does some tricky stuff to preinitialize values, so that standard static initialization check is skipped. However, the global offset table has moved in the final executable and emacs24 crashes. The

Re: [gomp-nvptx 9/9] adjust SIMD loop lowering for SIMT targets

Apologies -- last-minute attempt to cleanup and enhance broke this patch; fixed version below. The main difference is checking whether we're transforming a loop that might be executed on the target: checking decl->offloadable isn't enough, because target region outlining might not have happened

Re: [gomp-nvptx 6/9] nvptx libgcc: rewrite in C

On Wed, 2 Dec 2015, Bernd Schmidt wrote: > What exactly is the problem with having asm files? I'm asking because this... Wrappers for malloc and free need different code under -muniform-simt. > > On 12/01/2015 04:28 PM, Alexander Monakov wrote: > > +/* __shared__ char *__nvptx_stacks[32]; */

Re: [gomp-nvptx 6/9] nvptx libgcc: rewrite in C

What exactly is the problem with having asm files? I'm asking because this... On 12/01/2015 04:28 PM, Alexander Monakov wrote: +/* __shared__ char *__nvptx_stacks[32]; */ +asm ("// BEGIN GLOBAL VAR DEF: __nvptx_stacks"); +asm (".visible .shared .u64 __nvptx_stacks[32];"); + +/* __shared__

Go patch committed: Fix array dimension handling on 32-bit host

The Go frontend code that handled array dimensions when generating reflection and mangling assumed that an array dimension would fit in an unsigned long. That is of course not true when a 32-bit host is cross-compiling to a 64-bit target. This patch fixes the problem. This was reported as GCC PR

Re: [PATCH] rs6000: Optimise SImode cstore on 64-bit

On Tue, Dec 1, 2015 at 8:55 PM, Segher Boessenkool wrote: > On 64-bit we can do comparisons of 32-bit values by extending those > values to 64-bit, subtracting them, and then getting the high bit of > the result. For registers this is always cheaper than using the

Re: -fstrict-aliasing fixes 1/5: propagate -fno-strict-aliasing in the inliner

> > * ipa-inline-transform.c (inline_call): Drop -fstrict-aliasing when > > inlining -fno-strict-aliasing into -fstrict-aliasing body. > > * gcc.dg/lto/alias-1_0.c: New testcase. > > * gcc.dg/lto/alias-1_1.c: New testcase. > >Index: ipa-inline-transform.c >

Re: [google gcc-4_9] Fix bad LIPO profile produced by gcov-tool

So that field was never inited/used before? Also saved_compressed_len = (unsigned long) gcov_read_unsigned (); should use unsigned not unsigned long type. On Tue, Dec 1, 2015 at 4:53 PM, Rong Xu wrote: > This is only needed for gcov-tool as we need to rewrite the > moduel-info

Re: [PATCH] rs6000: Optimise SImode cstore on 64-bit

On Wed, Dec 02, 2015 at 01:55:17AM +, Segher Boessenkool wrote: > + emit_insn (gen_subdi3 (tmp, op1, op2)); > + emit_insn (gen_lshrdi3 (tmp2, tmp, GEN_INT (63))); > + emit_insn (gen_anddi3 (tmp3, tmp2, const1_rtx)); Why the AND? The top 63 bits are already clear. -- Alan Modra Australia

[PATCH] rs6000: Optimise SImode cstore on 64-bit

On 64-bit we can do comparisons of 32-bit values by extending those values to 64-bit, subtracting them, and then getting the high bit of the result. For registers this is always cheaper than using the carry bit sequence; and if the comparison involves a constant, this is cheaper than the sequence

Re: [google gcc-4_9] Fix bad LIPO profile produced by gcov-tool

This is only needed for gcov-tool as we need to rewrite the moduel-info to the profile (this is only used in decompress) The transitional compiler path does not need it because the string is already decompressed. It only needs to use the strings. gcov-dump in theory does not need it either if it

[PTX] simplify arg advance

arg_advance doesn't need to consider TImode. Those are always passed by reference. nathan 2015-12-01 Nathan Sidwell * config/nvptx/nvptx.c (nvptx_function_arg_advance): Don't consider mode. Index: config/nvptx/nvptx.c

Re: [PATCH] RFC: Use Levenshtein spelling suggestions in Fortran FE

On Tue, 2015-12-01 at 13:55 +0100, Bernhard Reutner-Fischer wrote: > gcc/fortran/ChangeLog > > 2015-11-29 Bernhard Reutner-Fischer > > * gfortran.h (gfc_lookup_function_fuzzy): New declaration. > * resolve.c: Include spellcheck.h. >

[PING v2][PATCH][4.9] Backport fix for PR sanitizer/64820.

On 25/11/15 12:14, Maxim Ostapenko wrote: I would like to ping the patch: https://gcc.gnu.org/ml/gcc-patches/2015-11/msg02174.html. Ping. -Maxim

Gimple loop splitting v2

Hi, On Mon, 16 Nov 2015, Jeff Law wrote: > OK, if you want to keep them, then have a consistent way to turn them > on/off for future debugging. if0/if1 doesn't provide much of a clue to > someone else what to turn on/off if they need to debug this stuff. > > > I don't see any negative tests

Re: [PATCH] Derive interface buffers from max name length

On 1 December 2015 at 15:52, Janne Blomqvist wrote: > On Tue, Dec 1, 2015 at 2:54 PM, Bernhard Reutner-Fischer > wrote: >> These three function used a hardcoded buffer of 100 but would be better >> off to base off GFC_MAX_SYMBOL_LEN which denotes

Re: [UPC 01/22] front-end changes

On Tue, 2015-12-01 at 00:19 -0800, Gary Funck wrote: > On 12/01/15 09:12:44, Eric Botcazou wrote: > > > All languages (c, c++, fortran, go, lto, objc, obj-c++) have been > > > bootstrapped; no test suite regressions were introduced, > > > relative to the GCC trunk. > > > > That's not all

Re: [gomp4.5] Handle #pragma omp declare target link

On Tue, Dec 01, 2015 at 14:15:59 +0100, Jakub Jelinek wrote: > On Tue, Dec 01, 2015 at 11:48:51AM +0300, Ilya Verbin wrote: > > > On 01 Dec 2015, at 11:18, Jakub Jelinek wrote: > > >> On Mon, Nov 30, 2015 at 11:55:20PM +0300, Ilya Verbin wrote: > > >> Ok, but it doesn't solve

Re: [PATCH] RFC: Use Levenshtein spelling suggestions in Fortran FE

On 1 December 2015 at 17:41, Steve Kargl wrote: > On Tue, Dec 01, 2015 at 05:12:57PM +0100, Bernhard Reutner-Fischer wrote: >> On 1 December 2015 at 16:01, Steve Kargl >> wrote: >> > On Tue, Dec 01, 2015 at 01:55:01PM +0100,

Re: [PATCH] RFC: Use Levenshtein spelling suggestions in Fortran FE

On 1 December 2015 at 18:28, David Malcolm wrote: > On Tue, 2015-12-01 at 13:55 +0100, Bernhard Reutner-Fischer wrote: >> +/* Lookup function FN fuzzily, taking names in FUN into account. */ >> + >> +const char* >> +gfc_lookup_function_fuzzy (const char *fn, gfc_symtree

Re: [PATCH] RFC: Use Levenshtein spelling suggestions in Fortran FE

On Tue, 2015-12-01 at 18:51 +0100, Bernhard Reutner-Fischer wrote: > On 1 December 2015 at 18:28, David Malcolm wrote: > > On Tue, 2015-12-01 at 13:55 +0100, Bernhard Reutner-Fischer wrote: > > > >> +/* Lookup function FN fuzzily, taking names in FUN into account. */ > >>

RE: [PATCH] RFC: Use Levenshtein spelling suggestions in Fortran FE

So, I have tested the patch, it seems to work well. I would really like to see this feature in the compiler, I'm sure it will help people developing Fortran code. I have already an enhancement request, catching the name of 'Keyword argument' : > cat test.f90 MODULE test CONTAINS SUBROUTINE

Re: [PATCH] Fix declaration of pthread-structs in s-osinte-rtems.ads (ada/68169)

On 12/01/2015 12:56 PM, Jan Sommer wrote: Am Monday 30 November 2015, 16:19:30 schrieb Jeff Law: On 11/30/2015 03:06 PM, Jan Sommer wrote: Could someone with write access please commit the patch? The paperwork with the FSF has gone through. If something else is missing, please tell me. I

Re: [PATCH] Fix PR68029

On 11/27/2015 06:11 AM, Jiří Engelthaler wrote: 2015-11-27 13:49 GMT+01:00 Bernd Schmidt : On 11/27/2015 01:30 PM, Jiří Engelthaler wrote: Sorry for international characters in my name. It should be Jiri Engelthaler 2015-11-27 13:29 GMT+01:00 Engelthaler Jiří

Re: [PR68001, CilkPlus] Fix for PR68001

On 30/11/15 21:43, Zamyatin, Igor wrote: FAIL: obj-c++.dg/property/dotsyntax-11.mm -fgnu-runtime (test for errors, line 51) FAIL: obj-c++.dg/property/dotsyntax-11.mm -fgnu-runtime (test for errors, line 56) FAIL: obj-c++.dg/property/dotsyntax-11.mm -fgnu-runtime (test for errors, line 59)

[ping] pending patches

IA-64 (stack checking improvement): https://gcc.gnu.org/ml/gcc-patches/2015-11/msg01604.html MIPS (stack checking improvement): https://gcc.gnu.org/ml/gcc-patches/2015-11/msg01602.html Aarch64 (stack checking implementation): https://gcc.gnu.org/ml/gcc-patches/2015-11/msg01988.html

Re: [C PATCH] Fix up location used in get_parm_info diagnostics (PR c/68533)

On Tue, Dec 01, 2015 at 08:57:39PM -0700, Jeff Law wrote: > On 12/01/2015 01:34 PM, Jakub Jelinek wrote: > >Hi! > > > >get_parm_info right now uses input_location as the diagnostics locus, but as > >can be seen on the testcase, that is pretty random location at that point, > >often the type of the

Re: [C PATCH] Fix up location used in get_parm_info diagnostics (PR c/68533)

On 12/02/2015 12:16 AM, Jakub Jelinek wrote: On Tue, Dec 01, 2015 at 08:57:39PM -0700, Jeff Law wrote: On 12/01/2015 01:34 PM, Jakub Jelinek wrote: Hi! get_parm_info right now uses input_location as the diagnostics locus, but as can be seen on the testcase, that is pretty random location at

Re: [PATCH] rs6000: Optimise SImode cstore on 64-bit

On Wed, Dec 02, 2015 at 01:50:46PM +1030, Alan Modra wrote: > On Wed, Dec 02, 2015 at 01:55:17AM +, Segher Boessenkool wrote: > > + emit_insn (gen_subdi3 (tmp, op1, op2)); > > + emit_insn (gen_lshrdi3 (tmp2, tmp, GEN_INT (63))); > > + emit_insn (gen_anddi3 (tmp3, tmp2, const1_rtx)); > >

Re: [C PATCH] Fix up location used in get_parm_info diagnostics (PR c/68533)

On 12/01/2015 01:34 PM, Jakub Jelinek wrote: Hi! get_parm_info right now uses input_location as the diagnostics locus, but as can be seen on the testcase, that is pretty random location at that point, often the type of the last parameter. This patch changes it to use the locus from the binding

Re: [PATCH 1/2] destroy values as well as keys when removing them from hash maps

On Tue, Dec 01, 2015 at 07:43:35PM +, Richard Sandiford wrote: > tbsaunde+...@tbsaunde.org writes: > > -template > > +template > > template > > inline void > > -simple_hashmap_traits ::remove (T ) > > +simple_hashmap_traits ::remove (T ) > > { > >H::remove (entry.m_key); >

[gomp4] backport fortran gang parsing updates

This patch carries over fortran gang parsing updates I recently applied to trunk to gomp-4_0-branch. Most of it was straightforward, but I did take the opportunity to clean up struct gfc_omp_clauses by eliminating some unnecessary bits for num_gangs, num_workers, vector_length and tile. Besides

Re: When not optimizing do not compute RTX memory attributes

> On Tue, 1 Dec 2015, Jan Hubicka wrote: > > > Hi, > > memory attributes are currently optimized and attached to RTL even when not > > optimizing. This is obviously just a wasted effort. > > Huh, are you sure? What about globals used from different optimize > contexts? Hmm, you are right - we

Re: [gomp4.5] Handle #pragma omp declare target link

On Tue, Dec 01, 2015 at 08:29:27PM +0300, Ilya Verbin wrote: > libgomp/ > * target.c (finalized): New static variable. > (resolve_device): Do nothing when finalized is true. > (GOMP_offload_register_ver): Likewise. > (GOMP_offload_unregister_ver): Likewise. >

[PATCH] Empty redirect_edge_var_map after each pass and function

This follows on from discussion at https://gcc.gnu.org/ml/gcc-patches/2015-11/msg03392.html To recap: Starting in r229479 and continuing until at least 229711, compiling polynom.c from spec2000 on aarch64-none-linux-gnu, with options -O3 -mcpu=cortex-a53 -ffast-math (on both cross, native

[GOOGLE] add more type in lipo type compare

The following patch can fix an ICE when compiling with LIPO. OK for google-4_9? Thanks, Dehao Index: gcc/l-ipo.c === --- gcc/l-ipo.c (revision 225685) +++ gcc/l-ipo.c (working copy) @@ -731,6 +731,7 @@ lipo_cmp_type (tree t1, tree

Re: [PING v2][PATCH][4.9] Backport fix for PR sanitizer/64820.

On Tue, 2015-12-01 at 20:23 +0300, Maxim Ostapenko wrote: > On 25/11/15 12:14, Maxim Ostapenko wrote: > > I would like to ping the patch: > > https://gcc.gnu.org/ml/gcc-patches/2015-11/msg02174.html. > > > > Ping. Yes, please add :)

Re: [RFA] [PATCH] Fix invalid redundant extension elimination for rl78 port

Jeff Law writes: > @@ -1080,6 +1070,18 @@ add_removable_extension (const_rtx expr, rtx_insn > *insn, > } > } > > + /* Fourth, if the extended version occupies more registers than the > + original and the source of the extension is the same hard

[PATCH] PR c/68637: Rebuid array with the updated function pointer type

When we apply function attribute to array of function pointer, we need to rebuild array with the updated function pointer type. gcc/ PR c/68637 * attribs.c (decl_attributes): Rebuid array with the updated * function pointer type. gcc/testsuite/ PR c/68637

Re: [PATCH 1/2] destroy values as well as keys when removing them from hash maps

tbsaunde+...@tbsaunde.org writes: > -template > +template > template > inline void > -simple_hashmap_traits ::remove (T ) > +simple_hashmap_traits ::remove (T ) > { >H::remove (entry.m_key); > + entry.m_value.~Value (); > } This is just repeating my IRC comment really, but

Re: [PATCH] RFC: Use Levenshtein spelling suggestions in Fortran FE

On Tue, Dec 01, 2015 at 06:34:57PM +0100, Bernhard Reutner-Fischer wrote: > On 1 December 2015 at 17:41, Steve Kargl > > > > Yes, I know there are other C++ (mis)features within the > > Fortran FE especially in the trans-*.c files. Those are > > accepted (by some) as necessary evils to interface

Re: [PATCH] Fix declaration of pthread-structs in s-osinte-rtems.ads (ada/68169)

Am Monday 30 November 2015, 16:19:30 schrieb Jeff Law: > On 11/30/2015 03:06 PM, Jan Sommer wrote: > > Could someone with write access please commit the patch? > > The paperwork with the FSF has gone through. If something else is missing, > > please tell me. > > I won't be available next week. >

Re: [gomp4.5] Handle #pragma omp declare target link

> On 01 Dec 2015, at 11:18, Jakub Jelinek wrote: > >> On Mon, Nov 30, 2015 at 11:55:20PM +0300, Ilya Verbin wrote: >> Ok, but it doesn't solve the issue with doing it for the executable, because >> gomp_unmap_tgt (n->tgt) will want to run free_func on uninitialized device. >

[Patch,microblaze]: Instruction prefetch optimization for microblaze.

The changes are made in this patch for the instruction prefetch optimizations for Microblaze. Reg tested for Microblaze target. The changes are made for instruction prefetch optimizations for Microblaze. The "wic" microblaze instruction is the instruction prefetch instruction. The instruction

[PATCH] Fix PR68590

The following avoids PR68590 by merging two match.pd patterns. Bootstrapped and tested on x86_64-unknown-linux-gnu. Richard. 2015-12-01 Richard Biener PR middle-end/68590 * match.pd: Merge (eq @0 @0) and (ge/le @0 @0) patterns. Index: gcc/match.pd

RE: [Patch,microblaze]: Instruction prefetch optimization for microblaze.

Moreover this patch is tested and run on hardware with Mibench/EEMBC benchmarks for Microblaze target. The reconfigurable design is enabled with the selection of "wic" instruction prefetch instruction and above benchmarks compiled with -mxl-prefetch flags. Thanks & Regards Ajit -Original

PR68577: Handle narrowing for vector popcount, etc.

This patch adds support for simple cases where the a vector internal function returns wider results than the scalar equivalent. It punts on other cases. Tested on powerpc64-linux-gnu and x86_64-linux-gnu. OK to install? Thanks, Richard gcc/ PR tree-optimization/68577 *

PR68474: Fix tree-call-cdce.c:use_internal_fn

We'd call gen_shrink_wrap_conditions for functions that it can't handle but edom_only_function can. Tested on x86_64-linux-gnu. OK to install? Thanks, Richard gcc/ PR tree-optimization/68474 * tree-call-cdce.c (use_internal_fn): Protect call to

Re: [openacc] fortran loop clauses and splitting

On Mon, Nov 30, 2015 at 10:00:06AM -0800, Cesar Philippidis wrote: > This patch contains the following bug fixes: > > * Teaches gfortran to accept both num and static gang arguments inside >same clause. E.g. gang(num:10, static:30). Currently, gfortran only >allows one of those arguments

[Patch AArch64] Fix typo in aarch64_builtin_reciprocal.

The patch to restructure builtin_reciprocals missed out an obvious ')'. Adjusted thusly and applied as obvious to trunk. regards Ramana 2015-12-01 Ramana Radhakrishnan * config/aarch64/aarch64.c (aarch64_builtin_reciprocal): Fix typo.

Re: [Patch AArch64] Fix typo in aarch64_builtin_reciprocal.

On Tue, Dec 01, 2015 at 08:58:53AM +, Ramana Radhakrishnan wrote: > The patch to restructure builtin_reciprocals missed out an obvious ')'. > Adjusted thusly and applied as obvious to trunk. Sorry for that. Could you please also handle the gimple_call_internal_p case, so that it actually

Re: [gomp] Move openacc vector& worker single handling to RTL

Hi! On Thu, 09 Jul 2015 20:25:22 -0400, Nathan Sidwell wrote: > This is the patch I committed. [...] > 2015-07-09 Nathan Sidwell > * omp-low.c (omp_region): [...] > (enclosing_target_region, required_predication_mask, >

Re: [PATCH testsuite ARM] : Update armv6 unaligned macro tests

Hi Christian, On 30/11/15 10:16, Christian Bruel wrote: Hi Kyrill, Your fix (https://gcc.gnu.org/ml/gcc-patches/2015-11/msg01392.html) exposed new FAILs with the macro testings in ftest-armv6[kz]-thumb.c. From what I understood, only ARMv6T2 will have TARGET_32BIT set, and set

[committed] Improve error reporting from genattrtab.c

The errors reported by check_attr_value weren't very helpful because they always used the location of the define(_enum)_attr, even if the error was in a define_insn. Also, the errors reported by check_attr_test didn't say which attribute was faulty. Although not technically a bug fix, it was

[PATCH, PR middle-end/68595] Fix invariant boolean vector generation

Hi, This patch fixes a way invariant boolean vector is generated. It makes sure boolean vector consists of 0 and -1 values. Bootstrapped and tested on x86_64-unknown-linux-gnu. OK for trunk? Thanks, Ilya -- gcc/ 2015-12-01 Ilya Enkovich PR

Re: [Patch AArch64] Fix typo in aarch64_builtin_reciprocal.

On 01/12/15 09:04, Jakub Jelinek wrote: > On Tue, Dec 01, 2015 at 08:58:53AM +, Ramana Radhakrishnan wrote: >> The patch to restructure builtin_reciprocals missed out an obvious ')'. >> Adjusted thusly and applied as obvious to trunk. > > Sorry for that. Could you please also handle the

Re: S/390: Fix warnings in "*setmem_long..." patterns.

On Mon, Nov 30, 2015 at 06:11:33PM +0100, Ulrich Weigand wrote: > On 11/30/2015 04:11 PM, Dominik Vogt wrote: > > The attached patch fixes some warnings generated by the setmem... > > patterns in s390.md during build and add test cases for the > > patterns. The patch is to be added on to p of the

Re: [PATCH AArch64]Handle REG+REG+CONST and REG+NON_REG+CONST in legitimize address

On 01/12/15 03:19, Bin.Cheng wrote: > On Tue, Nov 24, 2015 at 6:18 PM, Richard Earnshaw > wrote: >> On 24/11/15 09:56, Richard Earnshaw wrote: >>> On 24/11/15 02:51, Bin.Cheng wrote: >> The aarch64's problem is we don't define addptr3 pattern, and we don't

Re: [UPC 01/22] front-end changes

On 12/01/15 09:12:44, Eric Botcazou wrote: > > All languages (c, c++, fortran, go, lto, objc, obj-c++) have been > > bootstrapped; no test suite regressions were introduced, > > relative to the GCC trunk. > > That's not all languages though, Ada and Java are missing. OK. I'll bootstrap and run

Re: [gomp4.5] Handle #pragma omp declare target link

On Mon, Nov 30, 2015 at 11:55:20PM +0300, Ilya Verbin wrote: > Ok, but it doesn't solve the issue with doing it for the executable, because > gomp_unmap_tgt (n->tgt) will want to run free_func on uninitialized device. ?? You mean that the devicep->unload_image_func (devicep->target_id, version,

Re: [UPC 01/22] front-end changes

> All languages (c, c++, fortran, go, lto, objc, obj-c++) have been > bootstrapped; no test suite regressions were introduced, > relative to the GCC trunk. That's not all languages though, Ada and Java are missing. -- Eric Botcazou

Re: [OpenACC 0/7] host_data construct

On Mon, Nov 30, 2015 at 07:30:34PM +, Julian Brown wrote: > Julian Brown > Cesar Philippidis > James Norris > > gcc/ > * c-family/c-pragma.c (oacc_pragmas): Add PRAGMA_OACC_HOST_DATA. > *

Re: -fstrict-aliasing fixes 2/5: drop alias set 0 streaming

On Tue, 1 Dec 2015, Jan Hubicka wrote: > Hi, > this patch disables the streaming of alias 0 flag and adds a comment why. > > Bootstrapped/regtested x86_64-linux, OK? Ok. Thanks, Richard. > Honza > > * lto-streamer-out.c (hash_tree): Do not stream TYPE_ALIAS_SET. > *

Re: -fstrict-aliasing fixes 3/5: Do not ignore -fstrict-aliasing changes when parsing optimization attribute

On Tue, 1 Dec 2015, Jan Hubicka wrote: > Hi, > this is third part which enables us to change -fstrict-aliasing using > optimize attribute. This ought to work safely now because inliner > propagate the flag. Ok. Thanks, Richard. > Bootstrapped/regtested x86_64-linux. > > Honza > > *

Re: When not optimizing do not compute RTX memory attributes

On Tue, 1 Dec 2015, Jan Hubicka wrote: > Hi, > memory attributes are currently optimized and attached to RTL even when not > optimizing. This is obviously just a wasted effort. Huh, are you sure? What about globals used from different optimize contexts? > Bootstrapped/regtested x86_64-linux,

Re: PR68577: Handle narrowing for vector popcount, etc.

On Tue, Dec 1, 2015 at 10:14 AM, Richard Sandiford wrote: > This patch adds support for simple cases where the a vector internal > function returns wider results than the scalar equivalent. It punts > on other cases. > > Tested on powerpc64-linux-gnu and

Re: [PATCH, PR middle-end/68595] Fix invariant boolean vector generation

On Tue, Dec 1, 2015 at 10:44 AM, Ilya Enkovich wrote: > Hi, > > This patch fixes a way invariant boolean vector is generated. It makes sure > boolean vector consists of 0 and -1 values. Bootstrapped and tested on > x86_64-unknown-linux-gnu. OK for trunk? Ok.

Re: PR68474: Fix tree-call-cdce.c:use_internal_fn

On Tue, Dec 1, 2015 at 10:24 AM, Richard Sandiford wrote: > We'd call gen_shrink_wrap_conditions for functions that it can't handle > but edom_only_function can. > > Tested on x86_64-linux-gnu. OK to install? Ok. Richard. > Thanks, > Richard > > > gcc/ > PR

Re: RFC: Merge the GUPC branch into the GCC 6.0 trunk

Bernd Schmidt writes: > I'm worried we'll end up carrying > something around as a burden that is of no practical use (considering > we already support the more widespread OpenMP). I'm not an expert on UPC, but from glancing over the description it seems to target a

[PATCH] Add testcase for tree-optimization/67916

This PR was fixed in r228767 (or went latent?), but this testcase has never been added. Tested on x86_64-linux, ok for trunk? 2015-12-01 Marek Polacek PR tree-optimization/67916 * gcc.dg/torture/pr67916.c: New test. diff --git

[gomp-nvptx 2/9] nvptx backend: new "uniform SIMT" codegen variant

This patch introduces a code generation variant for NVPTX that I'm using for SIMD work in OpenMP offloading. Let me try to explain the idea behind it... In place of SIMD vectorization, NVPTX is using SIMT (single instruction/multiple threads) execution: groups of 32 threads execute the same

Re: RFC: Merge the GUPC branch into the GCC 6.0 trunk

On Tue, 1 Dec 2015, Andi Kleen wrote: > Bernd Schmidt writes: > > > I'm worried we'll end up carrying > > something around as a burden that is of no practical use (considering > > we already support the more widespread OpenMP). > > I'm not an expert on UPC, but from

[gomp-nvptx 8/9] libgomp: update gomp_nvptx_main for -mgomp

Here's how I've updated gomp_nvptx_main to set up shared memory arrays __nvptx_stacks and __nvptx_uni for -mgomp. Since it makes sense only for -mgomp multilib, I've wrapped the whole file under #ifdef that checks corresponding built-in macros. Reaching those shared memory arrays is awkward. I

[gomp-nvptx 5/9] new target hook: TARGET_SIMT_VF

This patch adds a new target hook and implements it in a straightforward manner on NVPTX to indicate that the target is running in SIMT fashion with 32 threads in a synchronous group ("warp"). For use in OpenMP transforms. --- gcc/config/nvptx/nvptx.c | 12 gcc/doc/tm.texi

[gomp-nvptx 0/9] Codegen bits for NVPTX OpenMP SIMD

Hello! This patch series shows how I'm approaching OpenMP SIMD for NVPTX. It looks good both in check-c testing and libgomp testing, including new target-3x.c cases (but for-5.c fails to run with resource exhaustion, maybe it should be split for NVPTX -- will investigate more later). The

Re: [PATCH] Add testcase for tree-optimization/67916

On Tue, Dec 1, 2015 at 4:18 PM, Marek Polacek wrote: > This PR was fixed in r228767 (or went latent?), but this testcase has never > been added. > > Tested on x86_64-linux, ok for trunk? Ok. Richard. > 2015-12-01 Marek Polacek > > PR

[gomp-nvptx 7/9] nvptx mkoffload: pass -mgomp for OpenMP offloading

This patch wires up use of alternative -mgomp multilib for OpenMP offloading via nvptx mkoffload. It makes OpenACC and OpenMP incompatible for simultaneous offloading compilation, so I've added a diagnostic for that. * config/nvptx/mkoffload.c (main): Check that either OpenACC or OpenMP

[gomp-nvptx 4/9] nvptx backend: add -mgomp option and multilib

Since OpenMP offloading requires both soft-stacks and "uniform SIMT", both non-traditional codegen variants, I'm building a multilib variant with those enabled. This patch adds option -mgomp which enables -msoft-stack plus -muniform-simt, and builds a multilib with it. *

Re: RFD: annotate iterator patterns with expanded forms

On Tue, Dec 01, 2015 at 04:14:21PM +0100, Bernd Schmidt wrote: > One problem I have whenever I try to edit i386.md is that I can't find the > patterns I'm looking for. Let's say I'm looking for lshrsi3, but there's no > pattern by this name, what I'm looking for is "3". Even > worse are things

RFD: annotate iterator patterns with expanded forms

One problem I have whenever I try to edit i386.md is that I can't find the patterns I'm looking for. Let's say I'm looking for lshrsi3, but there's no pattern by this name, what I'm looking for is "3". Even worse are things like "*xordi_2", which has just "*_2" and can't reasonably be searched

  1   2   >