Re: [AArch64] Improve TLS Descriptor pattern to release RTL loop IV opt

On Fri, Sep 25, 2015 at 11:40 PM, Andrew Pinski wrote: > On Tue, Jul 28, 2015 at 6:12 AM, Jiong Wang wrote: >> >> The instruction sequences for preparing argument for TLS descriptor >> runtime resolver and the later function call to resolver can actually be >> hoisted out of the loop. >> >> Curre

Re: [AArch64] Improve TLS Descriptor pattern to release RTL loop IV opt

On Tue, Jul 28, 2015 at 6:12 AM, Jiong Wang wrote: > > The instruction sequences for preparing argument for TLS descriptor > runtime resolver and the later function call to resolver can actually be > hoisted out of the loop. > > Currently we can't because we have exposed the hard register X0 as >

[gom4, committed] Don't parallelize oacc kernels region with adjacent loops

Hi, this patch prevents adjacent loops in a kernels region to paralellized. This fixes an ICE in the test-case. Committed to gomp-4_0-branch. Thanks, - Tom Don't parallelize oacc kernels region with adjacent loops 2015-09-26 Tom de Vries * omp-low.c (mark_loops_in_oacc_kernels_region):

Re: (patch,rfc) s/gimple/gimple */

On Thu, Sep 24, 2015 at 11:31:40AM +0200, Thomas Schwinge wrote: > Hi! > > On Sat, 19 Sep 2015 20:55:35 -0400, Trevor Saunders > wrote: > > On Fri, Sep 18, 2015 at 09:32:37AM -0600, Jeff Law wrote: > > > On 09/18/2015 07:32 AM, Trevor Saunders wrote: > > > >On Wed, Sep 16, 2015 at 03:11:14PM -04

[Patch,optimization]: Optimized changes in the estimate register pressure cost.

I have made the following changes in the estimate_reg_pressure_cost function used by the loop invariant and IVOPTS. Earlier the estimate_reg_pressure cost uses the cost of n_new variables that are generated by the Loop Invariant and IVOPTS. These are not sufficient for register pressure calcu

Re: [PATCH] v3 of diagnostic_show_locus and rich_location (was Re: [PATCH 2/5] Reimplement diagnostic_show_locus, introducing rich_location classes (v2))

On 25 September 2015 at 23:15, David Malcolm wrote: > My recollection is that I saw that the Fortran frontend has logic for > calling into diagnostic_print_caret_line, noticed that the fortran > testsuite has dg- assertions about finding specific messages, and I got > worried that they embed assum

Re: [PATCH] v3 of diagnostic_show_locus and rich_location (was Re: [PATCH 2/5] Reimplement diagnostic_show_locus, introducing rich_location classes (v2))

On 25 September 2015 at 23:24, David Malcolm wrote: > On Fri, 2015-09-25 at 23:13 +0200, Manuel López-Ibáñez wrote: >> + If SHOW_CARET_P is true, then the range should be rendered with >> + a caret at its starting location. This >> + is for use by the Fortran frontend, for implementing the

[PATCH] fortran/67616 -- Fix ICE within a BLOCK construct

The attached patch has been built and regression tested on x86_64-*-freebsd. No regression occurred. The patch removes a conditional within an assert() that triggers when a BLOCK construct is encountered. OK to commit? 2015-09-25 Steven G. Kargl PR fortran/67616 * primary.c

Re: [PATCH] v3 of diagnostic_show_locus and rich_location (was Re: [PATCH 2/5] Reimplement diagnostic_show_locus, introducing rich_location classes (v2))

On Fri, 2015-09-25 at 23:13 +0200, Manuel López-Ibáñez wrote: > + If SHOW_CARET_P is true, then the range should be rendered with > + a caret at its starting location. This > + is for use by the Fortran frontend, for implementing the > + "%C" and "%L" format codes. */ > + > +void > +rich_

Re: [PATCH] v3 of diagnostic_show_locus and rich_location (was Re: [PATCH 2/5] Reimplement diagnostic_show_locus, introducing rich_location classes (v2))

On Fri, 2015-09-25 at 22:39 +0200, Manuel López-Ibáñez wrote: > On 25 September 2015 at 22:18, Manuel López-Ibáñez > wrote: > > On 25 September 2015 at 22:11, David Malcolm wrote: > > >context->last_location = diagnostic_location (diagnostic, 0); > - expanded_location s0 = diagnostic_expan

Re: [PATCH] v3 of diagnostic_show_locus and rich_location (was Re: [PATCH 2/5] Reimplement diagnostic_show_locus, introducing rich_location classes (v2))

+ If SHOW_CARET_P is true, then the range should be rendered with + a caret at its starting location. This + is for use by the Fortran frontend, for implementing the + "%C" and "%L" format codes. */ + +void +rich_location::set_range (unsigned int idx, source_range src_range, +

a patch for PR61578

The following patch is for s390 regression introduced by the first patch for PR61578: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61578 The patch was bootstrapped and tested on x86-64. Committed as rev. 228154. 2015-09-25 Vladimir Makarov PR target/61578 * lra-constarints

Re: [PATCH] fortran/67614 -- Detect an invalid NULL in an arithmetic if

On 09/25/2015 12:18 PM, Steve Kargl wrote: > The attached patch has been built and regression tested on > x86_64-*-freebsd. There were no regression. > > If the scalar-numeric-expr in an arithmetic-if is ar > reference to NULL(), this is an invalid expression. > By resolving the expression, then

Re: [PATCH] v3 of diagnostic_show_locus and rich_location (was Re: [PATCH 2/5] Reimplement diagnostic_show_locus, introducing rich_location classes (v2))

On 25 September 2015 at 22:18, Manuel López-Ibáñez wrote: > On 25 September 2015 at 22:11, David Malcolm wrote: context->last_location = diagnostic_location (diagnostic, 0); - expanded_location s0 = diagnostic_expand_location (diagnostic, 0); - expanded_location s1 = { }; - /* Zero-initia

[PATCH] fix PR67700

The patch makes the detection of scop parameters in parameter_index_in_region a bit more conservative by discarding scalar variables defined in function of data references defined in the scop. 2015-09-25 Aditya Kumar Sebastian Pop PR tree-optimization/67700

[fortran, committed] Add PR55603 testcase

Hello, PR55603 seems to have been fixed at some point. I have just committed the test and I'm about to close the PR. Mikael Index: gcc/testsuite/gfortran.dg/allocatable_function_9.f90 === --- gcc/testsuite/gfortran.dg/allocatable_f

Re: [PATCH] v3 of diagnostic_show_locus and rich_location (was Re: [PATCH 2/5] Reimplement diagnostic_show_locus, introducing rich_location classes (v2))

On 25 September 2015 at 22:11, David Malcolm wrote: >> >> + if (0) >> +show_ruler (context, line_width, m_x_offset); >> >> This should probably be removed from the final code to be committed. > > FWIW, the ruler is very helpful to me when debugging the locus-printing > (e.g. when adding fix-i

Re: [PATCH] fortran/67525 -- fix ICE in SELECT TYPE

On 09/25/2015 12:13 PM, Steve Kargl wrote: > The follwoing patch has been built and regression > tested on x86_64-*-freebsd. There were no regression. > > The patch removes an assert, which allows gfortran > to detect an invalid selector in SELECT TYPE statement. > OK, thanks for patch! Jerry

[PATCH] v3 of diagnostic_show_locus and rich_location (was Re: [PATCH 2/5] Reimplement diagnostic_show_locus, introducing rich_location classes (v2))

On Fri, 2015-09-25 at 10:51 +0200, Dodji Seketeli wrote: > Hello David, > > I like this! Thank you very much for working on this. Thanks for the review. > I think this patch is in great shape, and once we agree on some of the > nits I have commented on below, I think it should go in. Oh, it als

Re: [PATCH][RTL-ifcvt] PR rtl-optimization/67465: Handle pairs of complex+simple blocks and empty blocks more gracefully

On 09/25/2015 05:06 AM, Kyrill Tkachov wrote: Hi Rainer, On 25/09/15 11:57, Rainer Orth wrote: Hi Kyrill, Bootstrapped and tested on aarch64 and x86_64. Rainer, could you please try this patch in combination with the one I sent earlier at: https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00815.h

[gomp4.1] Doacross tweaks

Hi! The latest spec proposals change the meaning of the ordered(n) clause if collapse > 1 to count the number of source loops. The ordered >= collapse requirement is something I'm pushing for even when it is not in the spec (yet). And, finally, another proposed change is that the + or - signs in t

Re: using scratchpads to enhance RTL-level if-conversion: the new patch is almost ready to be prepared for merging to trunk, but not 100% ready yet

On 09/25/2015 01:18 PM, Segher Boessenkool wrote: On Fri, Sep 25, 2015 at 10:09:23AM -0600, Jeff Law wrote: So what that means is the presence or absence of debug information is causing a difference in the code you generate. That is (of course) bad and indicates a bug of some kind in your code

Re: [Patch, fortran] PR40054 and PR63921 - Implement pointer function assignment - redux

Hello Paul, Le 25/09/2015 14:21, Paul Richard Thomas a écrit : Dear Mikael, dear all, Please find attached a revised version of the patch that, I believe, addresses all the comments. The patch is very much improved and these improvements are verified by the two extra testcases. Thanks a million

[PATCH] fortran/67614 -- Detect an invalid NULL in an arithmetic if

The attached patch has been built and regression tested on x86_64-*-freebsd. There were no regression. If the scalar-numeric-expr in an arithmetic-if is ar reference to NULL(), this is an invalid expression. By resolving the expression, then entity is correctly identified by EXPR_NULL. Thus, the

Re: using scratchpads to enhance RTL-level if-conversion: the new patch is almost ready to be prepared for merging to trunk, but not 100% ready yet

On Fri, Sep 25, 2015 at 10:09:23AM -0600, Jeff Law wrote: > >>So what that means is the presence or absence of debug information is > >>causing a difference in > > > the code you generate. That is (of course) bad and indicates a bug > >of some kind in your code. > > > >>I haven't put your code und

[GOOGLE] Disable -fno-reorder-blocks-and-partition if no -fprofile-use to avoid unnecessary overhead

This patch backports r228136 from trunk to Google/4_9. The only difference is that I have added the option disabling to our Google-specific routine for removing profile options when the specified profile gcda file is not found. Passes regression tests. Ok for google/4_9? Thanks, Teresa 2015-09-2

[PATCH] fortran/67525 -- fix ICE in SELECT TYPE

The follwoing patch has been built and regression tested on x86_64-*-freebsd. There were no regression. The patch removes an assert, which allows gfortran to detect an invalid selector in SELECT TYPE statement. 2015-09-25 Steven G. Kargl PR fortran/67525 * parse.c (match_def

Re: [PATCH] DWARF support for AIX v5

On 09/25/2015 11:59 AM, David Edelsohn wrote: > * dwarf2out.c (XCOFF_DEBUGGING_INFO): Default 0 definition. > (HAVE_XCOFF_DWARF_EXTRAS): Default to 0 definition. > (output_fde): Don't output length for debug_frame on AIX. > (output_call_frame_info): Don't output leng

Re: [ASAN/KSAN/TSAN doc patch] Fix broken sanitizer links in docs/invoke.texi

Tobias Burnus wrote: I intent to install it for GCC 6, 5 and 4.9. I have now committed it to the trunk and the two branches - including a wording change (When setting it to -> When set to; plus adding a second space after the end-of-sentence period.) Tobias

[PATCH] DWARF support for AIX v5

This version adds extra tests for HAVE_XCOFF_DWARF_EXTRAS. I placed the default in dwarf2out.c instead of defaults.h. Because eh_frame is internal to GCC with its own section, I emit the length, but inhibit the length for AIX debug_frame section. This allows DWARF debugging to work on older AIX

Re: [PATCH] Disable -fno-reorder-blocks-and-partition if no -fprofile-use to avoid unnecessary overhead

On Fri, Sep 25, 2015 at 11:01:47AM -0600, Jeff Law wrote: > On 09/25/2015 10:58 AM, Teresa Johnson wrote: > >Woops, we crossed wires. I just committed this patch. Would you like > >me to revert it? > Leave it. If Andi can include a reversion if he can pound his work > around 66890 into submission.

Re: [PATCH, fortran] Revival of AUTOMATIC patch

On Fri, Sep 25, 2015 at 07:23:53PM +0200, Paul Richard Thomas wrote: > > Frankly, I would accept the patch with the proviso that: > (i) It is hidden behand a gfc_notify_std (GFC_STD_GNU, "...; > (ii) The feature is set in conflict with the new features that FX > mentions, especially coarrays

Re: using scratchpads to enhance RTL-level if-conversion: the new patch is almost ready to be prepared for merging to trunk, but not 100% ready yet

On 09/25/2015 11:13 AM, Abe Skolnik wrote: From: Jeff Law Sent: Friday, September 25, 2015 11:09 AM I'd be surprised if we had DEBUG_INSNs as the first insn in a block (before the note), but it can't hurt to verify. I believe cfgrtl checks for proper location of the block note. But mayb

Re: CSE pass prevents loop-invariant motion

On 09/24/2015 12:29 AM, Robin Dapp wrote: On 09/15/2015 05:25 PM, Jeff Law wrote: On 09/15/2015 06:11 AM, Robin Dapp wrote: Hi, recently, I came across a problem that keeps a load instruction in a loop although it is loop-invariant. [..] You might want to check your costing model -- cprop is

Re: patch for PR61578

On 09/25/2015 12:57 PM, Jeff Law wrote: On 09/24/2015 02:41 PM, Vladimir Makarov wrote: The following patch solves the 2nd case of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61578 I did a lot of benchmarking of different heuristics in hard reg cost propagation in IRA. This is the best

Re: [PATCH, fortran] Revival of AUTOMATIC patch

Dear Jim, FX and Jerry, Frankly, I would accept the patch with the proviso that: (i) It is hidden behand a gfc_notify_std (GFC_STD_GNU, "...; (ii) The feature is set in conflict with the new features that FX mentions, especially coarrays and bind C; and (iii) As FX says, a good look at the te

Re: [PATCH] Disable -fno-reorder-blocks-and-partition if no -fprofile-use to avoid unnecessary overhead

On 09/25/2015 10:58 AM, Teresa Johnson wrote: Woops, we crossed wires. I just committed this patch. Would you like me to revert it? Leave it. If Andi can include a reversion if he can pound his work around 66890 into submission. But I think it'd need some of the varasm.c work Jan hinted at.

Re: [PATCH] Disable -fno-reorder-blocks-and-partition if no -fprofile-use to avoid unnecessary overhead

Woops, we crossed wires. I just committed this patch. Would you like me to revert it? Teresa On Fri, Sep 25, 2015 at 9:57 AM, Andi Kleen wrote: > Teresa Johnson writes: > >> This patch unsets -freorder-blocks-and-partition when -fprofile-use >> is not specified. Function splitting was not actua

Re: Elimitate duplication of get_catalogs in different abi

On 25/09/15 16:10 +0100, Jonathan Wakely wrote: On 25/09/15 16:08 +0100, Jonathan Wakely wrote: On 23/09/15 21:28 +0200, François Dumont wrote: On 05/09/2015 23:02, François Dumont wrote: On 22/08/2015 14:24, Daniel Krügler wrote: 2015-08-21 23:11 GMT+02:00 François Dumont : I think I found

Re: patch for PR61578

On 09/24/2015 02:41 PM, Vladimir Makarov wrote: The following patch solves the 2nd case of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61578 I did a lot of benchmarking of different heuristics in hard reg cost propagation in IRA. This is the best what I found. The patch improves stably

Re: [PATCH 1/5] Testsuite: add dg-{begin|end}-multiline-output commands

On 09/22/2015 03:26 PM, David Malcolm wrote: This patch is essentially identical to v1 here: https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00729.html The only change is in the ChangeLog, moving the libgo.exp ChangeLog entry into gcc/testsuite/ChangeLog, analogous to where Ian put it when intro

Re: [PATCH] Disable -fno-reorder-blocks-and-partition if no -fprofile-use to avoid unnecessary overhead

Teresa Johnson writes: > This patch unsets -freorder-blocks-and-partition when -fprofile-use > is not specified. Function splitting was not actually being performed > in that case, as probably_never_executed_bb_p does not distinguish > any basic blocks as being cold vs hot when there is no profil

Re: [PATCH] Disable -fno-reorder-blocks-and-partition if no -fprofile-use to avoid unnecessary overhead

On Fri, Sep 25, 2015 at 7:34 AM, Jan Hubicka wrote: >> > What has changed between then and now? Also, do we not use >> > estimates/heuristics when not using a profile? >> >> Nothing has changed - splitting effectively never kicked in without a >> profile. Honza and I had discussed the idea that st

Re: libgomp: Guard all offload_images/num_offload_images access by register_lock (was: libgomp nvptx plugin: rework initialisation and support the proposed load/unload hooks)

On Fri, Sep 25, 2015 at 18:21:27 +0200, Thomas Schwinge wrote: > On Thu, 26 Mar 2015 23:41:30 +0300, Ilya Verbin wrote: > > On Thu, Mar 26, 2015 at 13:09:19 +0100, Jakub Jelinek wrote: > > > the current code is majorly broken. As I've said earlier, e.g. the lack > > > of mutex guarding gomp_targe

Re: [v3 PATCH] Avoid creating dangling references in case of nested tuples for tuple constructors that construct from other tuples.

On 25/09/15 12:38 +0300, Ville Voutilainen wrote: Tested on Linux-PPC64. 2015-09-25 Ville Voutilainen Avoid creating dangling references in case of nested tuples for tuple constructors that construct from other tuples. * include/std/tuple (_TC::_NonNestedTuple): New. * include/st

Re: [PATCH] Clear variables with stale SSA_NAME_RANGE_INFO (PR tree-optimization/67690)

On September 25, 2015 3:49:34 PM GMT+02:00, Marek Polacek wrote: >On Fri, Sep 25, 2015 at 09:29:30AM +0200, Richard Biener wrote: >> On Thu, 24 Sep 2015, Marek Polacek wrote: >> >> > As Richi said in >, >> > using recorded SSA name range

libgomp: Guard all offload_images/num_offload_images access by register_lock (was: libgomp nvptx plugin: rework initialisation and support the proposed load/unload hooks)

Hi! It's still Friday afternoon -- so please bear with me once again... On Thu, 26 Mar 2015 23:41:30 +0300, Ilya Verbin wrote: > On Thu, Mar 26, 2015 at 13:09:19 +0100, Jakub Jelinek wrote: > > the current code is majorly broken. As I've said earlier, e.g. the lack > > of mutex guarding gomp_ta

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

On 09/24/2015 02:15 AM, Richard Biener wrote: On Thu, Sep 24, 2015 at 2:25 AM, David Malcolm wrote: LTO code does support ad-hoc locations but they are "restored" only when reading function bodies and stmts (by means of COMBINE_LOCATION_DATA). The obvious simplification would be, as you sugge

Re: [PATCH 4/5] Implement tree expression tracking in C FE (v2)

David Malcolm a écrit: > On Fri, 2015-09-25 at 16:06 +0200, Dodji Seketeli wrote: >> Hello, >> >> Similarly to a comment I made on the previous patch of the series, >> >> +++ b/libcpp/include/line-map.h >> >> [...] >> >> struct GTY(()) location_adhoc_data { >>source_location locu

Re: using scratchpads to enhance RTL-level if-conversion: the new patch is almost ready to be prepared for merging to trunk, but not 100% ready yet

On 09/24/2015 09:19 AM, Abe wrote: On 9/24/15 1:07 AM, Jeff Law wrote: So what that means is the presence or absence of debug information is causing a difference in > the code you generate. That is (of course) bad and indicates a bug of some kind in your code. I haven't put your code unde

Re: [PATCH 2/5] Reimplement diagnostic_show_locus, introducing rich_location classes (v2)

Manuel López-Ibáñez a écrit: > On 25 September 2015 at 10:51, Dodji Seketeli wrote: >> The line-map parts are OK to me too, but I have no power on those. So I > > You are listed as "line map" maintainer in MAINTAINERS. I rooted for > you! :) Right, I meant the libcpp parts (which are not line-

Re: [PATCH 3/5] Implement token range tracking within libcpp and the C FE (v2)

David Malcolm a écrit: > On Fri, 2015-09-25 at 11:13 +0200, Dodji Seketeli wrote: [...] >> Funny; I first overlooked this comment of you, and then when reading the >> patch, I asked myself "why keep the existing location_t" ? I mean, in >> here: >> >> /* A preprocessing token. This has b

Re: [PATCH 2/4 v2] bb-reorder: Add the "simple" algorithm

On Fri, Sep 25, 2015 at 10:59:37AM -0500, Peter Bergner wrote: > On Fri, 2015-09-25 at 09:16 -0500, Segher Boessenkool wrote: > > (reorder_basic_blocks): Choose between the STC and the simple > > algorithms (always choose the former). > [snip] > @@ -2274,7 +2444,10 @@ reorder_basic_blocks (

Re: [PATCH 2/4 v2] bb-reorder: Add the "simple" algorithm

On Fri, 2015-09-25 at 09:16 -0500, Segher Boessenkool wrote: > (reorder_basic_blocks): Choose between the STC and the simple > algorithms (always choose the former). [snip] @@ -2274,7 +2444,10 @@ reorder_basic_blocks (void) >set_edge_can_fallthru_flag (); >mark_dfs_back_edges ()

Re: Dead code in move_stmt_r

On 09/25/2015 09:41 AM, Bernd Schmidt wrote: I noticed this a while ago while trying to defer parts of omp expansion until after LTO. move_tree_r, which is used when moving code into omp child functions, has code not to remap variables inside an OMP directive. However, by the time we get here, th

Re: [PATCH] Clear variables with stale SSA_NAME_RANGE_INFO (PR tree-optimization/67690)

On Fri, Sep 25, 2015 at 03:49:34PM +0200, Marek Polacek wrote: > On Fri, Sep 25, 2015 at 09:29:30AM +0200, Richard Biener wrote: > > On Thu, 24 Sep 2015, Marek Polacek wrote: > > > > > As Richi said in > > > , > > > using recorded SSA name

Dead code in move_stmt_r

I noticed this a while ago while trying to defer parts of omp expansion until after LTO. move_tree_r, which is used when moving code into omp child functions, has code not to remap variables inside an OMP directive. However, by the time we get here, these directives should all have been expande

Re: libgomp: Compile-time error for non-portable gomp_mutex_t initialization (was: libgomp nvptx plugin: rework initialisation and support the proposed load/unload hooks)

On Fri, Sep 25, 2015 at 05:04:47PM +0200, Thomas Schwinge wrote: > Hi! > > It's Friday afternoon -- but anyway, is the following analysis correct? > > On Thu, 26 Mar 2015 23:41:30 +0300, Ilya Verbin wrote: > > On Thu, Mar 26, 2015 at 13:09:19 +0100, Jakub Jelinek wrote: > > > the current code is

Re: [RFC PATCH] parse #pragma GCC diagnostic in libcpp

Manuel López-Ibáñez writes: > Currently, #pragma GCC diagnostic is handled entirely by the FE. This > has several drawbacks: > > * PR c++/53431 - C++ preprocessor ignores #pragma GCC diagnostic: The > C++ parser lexes (and preprocesses) before handling the pragmas. > > * PR 53920 - "gcc -E" does

Re: Elimitate duplication of get_catalogs in different abi

On 25/09/15 16:08 +0100, Jonathan Wakely wrote: On 23/09/15 21:28 +0200, François Dumont wrote: On 05/09/2015 23:02, François Dumont wrote: On 22/08/2015 14:24, Daniel Krügler wrote: 2015-08-21 23:11 GMT+02:00 François Dumont : I think I found a better way to handle this problem. It is c++loc

Re: Elimitate duplication of get_catalogs in different abi

On 23/09/15 21:28 +0200, François Dumont wrote: On 05/09/2015 23:02, François Dumont wrote: On 22/08/2015 14:24, Daniel Krügler wrote: 2015-08-21 23:11 GMT+02:00 François Dumont : I think I found a better way to handle this problem. It is c++locale.cc that needs to be built with --fimplicit-te

[Patch ifcvt 3/3] Create a new target hook for deciding profitability of noce if-conversion

Hi, This patch introduces a new costs hook for deciding on the profitability of an if-conversion candidate. We defer as much as possible for this decision to the target, permitting the target to vary the outcome based on the specific behaviours of a branch predictor in addition to any other targe

[Patch Prototype AArch64 ifcvt 4/3] Wire up the new if-convert costs hook for AArch64

Hi, This patch is a simple prototype showing how a target might choose to implement TARGET_COSTS_IFCVT_NOCE_IS_PROFITABLE_P. It has not been tuned, tested or looked at in any meaningful way. While the patch is in need of more detailed analysis it is sufficient to serve as an indication of what

libgomp: Compile-time error for non-portable gomp_mutex_t initialization (was: libgomp nvptx plugin: rework initialisation and support the proposed load/unload hooks)

Hi! It's Friday afternoon -- but anyway, is the following analysis correct? On Thu, 26 Mar 2015 23:41:30 +0300, Ilya Verbin wrote: > On Thu, Mar 26, 2015 at 13:09:19 +0100, Jakub Jelinek wrote: > > the current code is majorly broken. As I've said earlier, e.g. the lack > > of mutex guarding gom

[Patch ifcvt 2/3] Move noce_if_info in to ifcvt.h

Simple code move. We're going to allow targets to work with this information, so pull it somewhere they can see it. No issues building toolchains after this transformation. OK? Thanks, James --- 2015-09-26 James Greenhalgh * ifcvt.c (noce_if_info): Move to... * ifcvt.h (noc

[Patch ifcvt costs 0/3] Introduce a new target hook for ifcvt costs.

Hi, In relation to the patch I put up for review a few weeks ago to teach RTL if-convert to handle multiple sets in a basic block [1], I was asking about a sensible cost model to use. There was some consensus at Cauldron that what should be done in this situation is to introduce a target hook that

[Patch ifcvt 1/3] Factor out cost calculations from noce cases

Hi, In this patch we try to pull out the cost calculations used by the no-conditional-execution if-convert functions. We want to replicate the logic of the current cost decisions, but to phrase it in a way which can be pulled out as common. To preserve the current behaviour as best as we can, thi

Re: [Patch 1/2 AArch64/ARM] Give AArch64 ROR (Immediate) a new type attribute

On 25 September 2015 at 14:19, James Greenhalgh wrote: > 2015-09-25 James Greenhalgh > > * config/arm/types.md (type): Add rotate_imm. > * config/aarch64/aarch64.md (*ror3_insn): Split out the > ROR immediate case. > (*rorsi3_insn_uxtw): Likewise. > * co

[PATCH, Mips] Compact branch/delay slot optimization.

Hello, The following patch adds three small optimizations related to compact branches for MIPSR6: When the result of a load is used by a delay slot branch immediately afterwards, undo the delay slot branch scheduling to hide the pipeline bubble if safe and use a compact branch instead. Undo

[PATCH 1/2] s/390: Implement "target" attribute.

On Fri, Sep 25, 2015 at 02:59:41PM +0100, Dominik Vogt wrote: > The following set of two patches implements the function > __attribute__ ((target("..."))) and the corresponding #pragma GCC > target("...") on S/390. It comes with certain limitations: > > * It is not possible to change any options

Re: [PATCH 4/5] Implement tree expression tracking in C FE (v2)

On Fri, 2015-09-25 at 16:06 +0200, Dodji Seketeli wrote: > Hello, > > Similarly to a comment I made on the previous patch of the series, > > +++ b/libcpp/include/line-map.h > > [...] > > struct GTY(()) location_adhoc_data { >source_location locus; > + source_range src_range; >

Re: [RFC] Try vector as a new representation for vector masks

2015-09-23 16:53 GMT+03:00 Richard Biener : > On Wed, Sep 23, 2015 at 3:41 PM, Ilya Enkovich wrote: >> 2015-09-18 16:40 GMT+03:00 Ilya Enkovich : >>> 2015-09-18 15:22 GMT+03:00 Richard Biener : I was thinking about targets not supporting generating vec (of whatever mode) from a comp

Re: [PATCH] Add new hooks ASM_OUTPUT_START_FUNCTION_HEADER ...

On 09/24/2015 03:48 PM, Dominik Vogt wrote: Hm, I wonder whether wrapping all these section switches in assemble_start/end_function in ".machine" pseudoops (that's what we need the hooks for; similar to .arch for ix86) has any real effect. I don't think I follow what you're trying to say here?

Re: [PATCH] Disable -fno-reorder-blocks-and-partition if no -fprofile-use to avoid unnecessary overhead

> > What has changed between then and now? Also, do we not use > > estimates/heuristics when not using a profile? > > Nothing has changed - splitting effectively never kicked in without a > profile. Honza and I had discussed the idea that static profile > heuristics could eventually be used to dis

Re: [PATCH 3/5] Implement token range tracking within libcpp and the C FE (v2)

On Fri, 2015-09-25 at 11:13 +0200, Dodji Seketeli wrote: > Hello, > > David Malcolm a écrit: > > > This is an updated version of: > > https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00736.html > > > > Changes in V2 of the patch: > > * c_lex_with_flags: don't write through the range ptr if it's

Re: [PATCH, fortran] Revival of AUTOMATIC patch

>> All in all I’m skeptical of adding even more old language extensions with >> little demand when we have a hard time filling up gaps in the standard. Each >> addition adds to maintainance load, especially as they might not interact >> too well with more modern features. (For example coarrays o

[HSA] introduce hsa_num_threads

Hello. In the following patch HSA is capable of handling various OMP builtins that are utilized to set or get the number of threads. Martin >From adfd806108dc5f9343811171de62b3af1d4ef903 Mon Sep 17 00:00:00 2001 From: marxin Date: Thu, 24 Sep 2015 23:07:14 +0200 Subject: [PATCH] HSA: introduce h

Re: [PATCH 2/4 v2] bb-reorder: Add the "simple" algorithm

v2 changes: - Add a file header comment; - Use "for" loop initial declarations; - Handle asm goto. Testing this on x86_64-linux; okay if it succeeds? Segher 2015-09-99 Segher Boessenkool * bb-reorder.c: Add intro comment. (reorder_basic_blocks_software_trace_cache): Print

Re: [PATCH] Disable -fno-reorder-blocks-and-partition if no -fprofile-use to avoid unnecessary overhead

On 09/25/2015 04:14 PM, Teresa Johnson wrote: Nothing has changed - splitting effectively never kicked in without a profile. Honza and I had discussed the idea that static profile heuristics could eventually be used to distinguish hot vs cold bbs, but that hasn't happened. What I didn't notice un

Re: [PATCH] Disable -fno-reorder-blocks-and-partition if no -fprofile-use to avoid unnecessary overhead

On Fri, Sep 25, 2015 at 6:58 AM, Bernd Schmidt wrote: > On 09/24/2015 07:16 PM, Teresa Johnson wrote: >> >> This patch unsets -freorder-blocks-and-partition when -fprofile-use >> is not specified. Function splitting was not actually being performed >> in that case, as probably_never_executed_bb_p

Re: [PATCH 4/5] Implement tree expression tracking in C FE (v2)

Hello, Similarly to a comment I made on the previous patch of the series, +++ b/libcpp/include/line-map.h [...] struct GTY(()) location_adhoc_data { source_location locus; + source_range src_range; void * GTY((skip)) data; }; Could we just change the type of locus

[PATCH 2/2] s/390: Implement "target" attribute.

On Fri, Sep 25, 2015 at 02:59:41PM +0100, Dominik Vogt wrote: > The following set of two patches implements the function > __attribute__ ((target("..."))) and the corresponding #pragma GCC > target("...") on S/390. It comes with certain limitations: > > * It is not possible to change any options

[PATCH] s/390: Implement "target" attribute.

The following set of two patches implements the function __attribute__ ((target("..."))) and the corresponding #pragma GCC target("...") on S/390. It comes with certain limitations: * It is not possible to change any options that affect the ABI or the definition of target macros by using the

Re: [PATCH] Disable -fno-reorder-blocks-and-partition if no -fprofile-use to avoid unnecessary overhead

On 09/24/2015 07:16 PM, Teresa Johnson wrote: This patch unsets -freorder-blocks-and-partition when -fprofile-use is not specified. Function splitting was not actually being performed in that case, as probably_never_executed_bb_p does not distinguish any basic blocks as being cold vs hot when the

Re: [PATCH] Clear variables with stale SSA_NAME_RANGE_INFO (PR tree-optimization/67690)

On Fri, Sep 25, 2015 at 09:29:30AM +0200, Richard Biener wrote: > On Thu, 24 Sep 2015, Marek Polacek wrote: > > > As Richi said in , > > using recorded SSA name range infos in VRP is likely to expose errors in the > > ranges. This PR is su

[HSA] Enhancement of back-end

Hello. Following patch set enhances back-end, it adds support for SBR instructions and it fixed many issues spotted in GCC's test suite. Patches have been just applied to HSA branch: a73d92c HSA: add support for SBR instruction. 6485fbf HSA: fix issues in GIMPLE switch expansion. b73698c HSA: fix

Re: [gomp4] Another oacc reduction simplification

On 09/25/2015 03:57 AM, Nathan Sidwell wrote: > On 09/24/15 16:32, Cesar Philippidis wrote: >> On 09/22/2015 08:29 AM, Nathan Sidwell wrote: >> >>> 1) Don't have a fake gang reduction outside of worker & vector loops. >>> Deal with the receiver object directly. I.e. 'ref_to_res' need not be a >>>

Re: New power of 2 hash policy

On 24/09/15 22:08 +0200, François Dumont wrote: Working on it I realised that despite the comment on _M_next_bkt saying "no smaller than n" the method can return a value smaller for big n values. This is not likely to happen but I prefer to take care of it. I just make sure we won't try to reh

Re: [Patch 1/2 AArch64/ARM] Give AArch64 ROR (Immediate) a new type attribute

On Fri, Sep 25, 2015 at 01:53:35PM +0100, Kyrill Tkachov wrote: > Hi James, > > On 25/09/15 08:59, James Greenhalgh wrote: > > Hi, > > > > This patch splits the "shift_imm" type attribute used by AArch64 in > > two - giving rotate_imm and shift_imm. > > > > We then apply this transform across the

Re: New post-LTO OpenACC pass

On 09/25/2015 03:03 PM, Bernd Schmidt wrote: 182 else if (acc_device_type (acc_dev->type) == acc_device_host) (gdb) p acc_dev->type $1 = OFFLOAD_TARGET_TYPE_HOST (gdb) next 184 fn (hostaddrs); It's not running the offloaded version, so the testcase I think should fail. ... and th

[SH][committed] Fix PR 67675

Hi, This patch adds more fine grained alignment checks to SH's builtin strcmp and strncmp expanders. If one of the input pointers is known to be at least 4 byte aligned, there's no need to check it. Tested on sh-elf with make -k check RUNTESTFLAGS="--target_board=sh-sim \{-m2/-ml,-m2/-mb,-m2a/-m

[hsa] Gridification rewrite followups

Hi, the following patch fixes a simple fallouts from the yesterday's commit when a parallel child function was marked as a krnel, if it was invoked from a gridified target construct. The patch also fixes an ICE in the compiler when attempting to compile OpenACC testcases (which then still fail wi

Re: New post-LTO OpenACC pass

On 09/25/2015 02:30 PM, Bernd Schmidt wrote: (gdb) p result $1 = (gdb) pge warning: Expression is not an assignment (and might have no effect) 2 == 4 || 2 == 5 I'm not really sure about the logic, but are the results maybe switched (returning false on the device and true on the host)? Eh, no

Re: [Patch 1/2 AArch64/ARM] Give AArch64 ROR (Immediate) a new type attribute

Hi James, On 25/09/15 08:59, James Greenhalgh wrote: Hi, This patch splits the "shift_imm" type attribute used by AArch64 in two - giving rotate_imm and shift_imm. We then apply this transform across the AArch64 pipeline descriptions which have modelling for shift_imm (cortex-a53, cortex-a57,

Re: PR pretty-print/67567 do not pass NULL as a string

Manuel López-Ibáñez a écrit: > 2015-09-15 Manuel López-Ibáñez > > PR pretty-print/67567 > * resolve.c (resolve_fl_procedure): Work-around when iface->module > == NULL. This is OK, thanks. -- Dodji

Re: [gcc-5-branch][PATCH][AARCH64]Fix for branch offsets over 1 MiB

On Fri, Sep 11, 2015 at 06:15:23PM +0100, Andre Vieira wrote: > Conditional branches have a maximum range of [-1048576, 1048572]. Any > destination further away can not be reached by these. > To be able to have conditional branches in very large functions, we > invert the condition and change the

Re: New post-LTO OpenACC pass

On 09/25/2015 12:56 PM, Nathan Sidwell wrote: On 09/25/15 06:28, Bernd Schmidt wrote: Can you send me the patch you tried (and possibly a testcase you expect to be handled), I'll see if I can find out what's going on. Thanks! When things didn't work, I tried getting it workong on the gomp4 br

Re: [RFC] PR tree-optimization/67628: Make tree ifcombine more symmetric and interactions with dom

On 25/09/15 12:35, Richard Biener wrote: On Fri, 25 Sep 2015, Kyrill Tkachov wrote: On 25/09/15 11:15, Richard Biener wrote: On Fri, 25 Sep 2015, Kyrill Tkachov wrote: On 25/09/15 10:49, Richard Biener wrote: On Fri, 25 Sep 2015, Kyrill Tkachov wrote: Hi all, On 23/09/15 11:10, Richard

Re: [Patch, fortran] PR40054 and PR63921 - Implement pointer function assignment - redux

Dear Mikael, dear all, Please find attached a revised version of the patch that, I believe, addresses all the comments. The patch is very much improved and these improvements are verified by the two extra testcases. Thanks a million! Most of the effort involved in preparing this revised patch was

Re: [PATCH 2/5] Reimplement diagnostic_show_locus, introducing rich_location classes (v2)

On 25 September 2015 at 10:51, Dodji Seketeli wrote: > The line-map parts are OK to me too, but I have no power on those. So I You are listed as "line map" maintainer in MAINTAINERS. I rooted for you! :) Cheers, Manuel.

  1   2   >