[gomp4] add -finform-parallelism

This patch introduces a new -finform-parallelism flag to report any detected parallelism encountered by the compiler. Initially, it's being used to report how oaccdevlow partitions OpenACC loops. Currently, if you want to extract this information, you need to compile the program with

Re: [PATCH, testsuite]: Use posix_memalign instead of aligned_alloc in gcc.dg/strncmp-2.c

On Fri, 2017-02-17 at 10:50 +0100, Uros Bizjak wrote: > posix_memalign is portable to older, non-c11 runtimes. > > 2017-02-17  Uros Bizjak   > > * gcc.dg/strncmp-2.c (test_driver_strncmp): Use posix_memalign > instead of aligned_alloc. > > Tested on x86_64-linux-gnu,

Re: [PATCH] Fix simplify_const_unary_operation sNaN handling (PR tree-optimization/61441)

On Tue, Feb 21, 2017 at 12:12:28AM +0100, Jakub Jelinek wrote: > As I wrote earlier today on gcc-patches, pr61441.c started failing > on i?86-linux when -fsignaling-nans argument has been added to it. > > I believe this is because the simplify_const_unary_operation > changes in r231901 were

Go patch committed: Fix formatting in go/lang.opt

This patch fixes a character in go/lang.opt to be a tab rather than a space. This fixes GCC PR 79642. Bootstrapped on x86_64-pc-linux-gnu. Committed to mainline. Ian 2017-02-20 Ian Lance Taylor PR go/79642 * lang.opt (-fgo-relative-import-path): Change

Re: [PATCH] Fix -fsplit-stack with non-local gotos (PR target/79494)

On Mon, Feb 20, 2017 at 12:42 PM, Jakub Jelinek wrote: > > We ICE on the following testcase, because we have abnormal edges > from both __morestack call (which is before prologue) and call > to the nested function (which is in between prologue and epilogue) > to a label

[PATCH] Fix simplify_const_unary_operation sNaN handling (PR tree-optimization/61441)

Hi! As I wrote earlier today on gcc-patches, pr61441.c started failing on i?86-linux when -fsignaling-nans argument has been added to it. I believe this is because the simplify_const_unary_operation changes in r231901 were broken, when the operand is a sNaN and -fsignaling-nans, we want to avoid

Re: [PATCH] Change default of param not being smaller that min.

On Feb 20, 2017, Richard Biener wrote: > On Fri, Feb 17, 2017 at 4:18 PM, Martin Liška wrote: >> Hello. >> >> We should not have a default value (different from -1) that is smaller than >> minimum. >> >> Ready to be installed after tests? > I

New German PO file for 'gcc' (version 7.1-b20170101)

Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'gcc' has been submitted by the German team of translators. The file is available at: http://translationproject.org/latest/gcc/de.po (This file, 'gcc-7.1-b20170101.de.po',

Re: [4.7][google] Adding a new option -fstack-protector-strong. (issue5461043)

https://www.google.com/usability/index.html?reserved=0=0=andr=ghc=0=0_code=androiddotcom fstack-protector-strong https://codereview.appspot.com/5461043/

Re: [PATCH] Fix -fsplit-stack with non-local gotos (PR target/79494)

Hi Jakub, On Mon, Feb 20, 2017 at 09:42:26PM +0100, Jakub Jelinek wrote: > We ICE on the following testcase, because we have abnormal edges > from both __morestack call (which is before prologue) and call > to the nested function (which is in between prologue and epilogue) > to a label reachable

Re: [PATCH] Look through clobber stmts in uninit (PR tree-optimization/79345)

On Mon, 20 Feb 2017, Jakub Jelinek wrote: As mentioned by Jason in the PR, we've regressed on the following testcase since we started emitting CLOBBERs at the start of ctors (and we warn as before with -fno-lifetime-dse -Wuninitialized). With -fno-lifetime-dse, the vuse on the b.x read stmt is

[PATCH] Look through clobber stmts in uninit (PR tree-optimization/79345)

Hi! As mentioned by Jason in the PR, we've regressed on the following testcase since we started emitting CLOBBERs at the start of ctors (and we warn as before with -fno-lifetime-dse -Wuninitialized). With -fno-lifetime-dse, the vuse on the b.x read stmt is default def and thus we warn, but if

[PATCH] Fix -fsplit-stack with non-local gotos (PR target/79494)

Hi! We ICE on the following testcase, because we have abnormal edges from both __morestack call (which is before prologue) and call to the nested function (which is in between prologue and epilogue) to a label reachable through non-local goto. This is something dwarf2cfi doesn't allow, it

[C++ PATCH] Fix ICE with decomp gimplification (PR sanitizer/79589)

Hi! When generic is unshared, we generally don't unshare DECL_VALUE_EXPRs, so those are assumed to be not shared, otherwise as in the testcase we can clear first argument of a COMPOUND_EXPR after it has been gimplified in one use and by that clobbering all others. Bootstrapped/regtested on

[PATCH] Move -Wrestrict warning later in the FEs and fix some issues in it (PR c++/79588)

Hi! As mentioned in the PR, -Wrestrict warning is done way too early, where e.g. default arguments aren't filled up yet (reason for ICE on first testcase) or where arguments in templates aren't instantiated yet (reason why we don't diagnose anything on the second testcase). This patch moves it

Re: [PATCH] testsuite: pr59833.c and pr61441.c should use -fsignaling-nans

On Mon, Feb 20, 2017 at 07:24:50PM +0100, Jakub Jelinek wrote: > On Thu, Feb 16, 2017 at 05:46:30PM +, Segher Boessenkool wrote: > > The testcases pr59833.c and pr61441.c check whether signaling NaNs as > > input to some operation result in quiet NaNs. Without -fsignaling-nans > > this is not

Re: [PATCH] testsuite: pr59833.c and pr61441.c should use -fsignaling-nans

On Thu, Feb 16, 2017 at 05:46:30PM +, Segher Boessenkool wrote: > The testcases pr59833.c and pr61441.c check whether signaling NaNs as > input to some operation result in quiet NaNs. Without -fsignaling-nans > this is not guaranteed to happen. So, this patch add this option to > these

C++ PATCH for c++/78139, private destructor and new-expression

The C++17 copy elision code in build_special_member_call was creating a temporary and then eliding the copy directly, but creating that temporary meant building a cleanup, which requires the destructor to be callable. And we shouldn't require that when building a new-expression. Fixed by using

Re: [PATCH] Fix fixincludes for canadian cross builds

On 02/18/17 01:01, Bernd Edlinger wrote: > On 02/18/17 00:37, Bruce Korb wrote: >> On 02/06/17 10:44, Bernd Edlinger wrote: >>> I tested this change with different arm-linux-gnueabihf cross >>> compilers, and verified that mkheaders still works on the host system. >>> >>> Bootstrapped and

Re: [PATCH PR77536]Generate correct profiling information for vectorized loop

On Mon, Feb 20, 2017 at 4:05 PM, Jan Hubicka wrote: >> BTW, if we use gcov_type in calculation from >> expected_loop_iterations_unbounded, >> how should we adjust the number for calling scale_loop_frequencies >> which has int type? In extreme case, gcov_type could be out of

Re: fwprop fix for PR79405

On February 20, 2017 2:58:54 PM GMT+01:00, Bernd Schmidt wrote: >On 02/17/2017 10:11 AM, Richard Biener wrote: >> Index: gcc/fwprop.c >> === >> --- gcc/fwprop.c(revision 245501) >> +++ gcc/fwprop.c

New Swedish PO file for 'gcc' (version 7.1-b20170101)

Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'gcc' has been submitted by the Swedish team of translators. The file is available at: http://translationproject.org/latest/gcc/sv.po (This file, 'gcc-7.1-b20170101.sv.po',

Re: [PATCH PR77536]Generate correct profiling information for vectorized loop

> BTW, if we use gcov_type in calculation from > expected_loop_iterations_unbounded, > how should we adjust the number for calling scale_loop_frequencies > which has int type? In extreme case, gcov_type could be out of int's > range, we have to cap the value anyway. But yes, 1 in >

Re: [PATCH PR77536]Generate correct profiling information for vectorized loop

On Mon, Feb 20, 2017 at 3:17 PM, Jan Hubicka wrote: >> > + /* Without profile feedback, loops for which we do not know a better >> > estimate >> > + are assumed to roll 10 times. When we unroll such loop, it appears >> > to >> > + roll too little, and it may even seem

Re: [PATCH] Fix -fsanitize=bounds crash with zero-size array (PR sanitizer/79558)

On Mon, Feb 20, 2017 at 04:44:10PM +0100, Marek Polacek wrote: > We crash here becase ubsan_type_descriptor isn't able to handle arrays > such as int[0:], i.e. where the TYPE_MAX_VALUE of the domain is missing. > Fixed by checking that first, which means we'd print '*' instead if it > is missing.

[PATCH] Fix -fsanitize=bounds crash with zero-size array (PR sanitizer/79558)

We crash here becase ubsan_type_descriptor isn't able to handle arrays such as int[0:], i.e. where the TYPE_MAX_VALUE of the domain is missing. Fixed by checking that first, which means we'd print '*' instead if it is missing. Bootstrapped/regtested on x86_64-linux, ok for trunk/6? 2017-02-20

Re: [PATCH PR77536]Generate correct profiling information for vectorized loop

> > + /* Without profile feedback, loops for which we do not know a better > > estimate > > + are assumed to roll 10 times. When we unroll such loop, it appears to > > + roll too little, and it may even seem to be cold. To avoid this, we > > + ensure that the created loop appears

Re: Improving code generation in the nvptx back end

On Fri, 17 Feb 2017, Thomas Schwinge wrote: > On Fri, 17 Feb 2017 14:00:09 +0100, I wrote: > > [...] for "normal" functions there is no reason to use the > > ".param" space for passing arguments in and out of functions. We can > > then get rid of the boilerplate code to move ".param %in_ar*" into

Re: [PATCH PR77536]Generate correct profiling information for vectorized loop

On Mon, Feb 20, 2017 at 2:02 PM, Jan Hubicka wrote: >> > 2017-02-16 Bin Cheng >> > >> > PR tree-optimization/77536 >> > * tree-ssa-loop-manip.c (niter_for_unrolled_loop): New function. >> > (tree_transform_and_unroll_loop): Use above

Re: [PATCH][DOC][OBVIOUS] Document default value for use-after-scope-direct-emission-threshold

On 02/18/2017 09:48 AM, Gerald Pfeifer wrote: > Let me know whether this looks fine to you, and I'll commit. > > Gerald I'm fine with that! Thanks. Martin

Re: [GIMPLE FE] add fma_expr

Hi Prathamesh, On 16/02/17 12:47, Prathamesh Kulkarni wrote: Hi Richard, The attached patch handles fma_expr in gimple-fe. Does it look OK ? Thanks, Prathamesh I see the new test ICEing on aarch64-none-elf. Thanks, Kyrill --

Re: [PATCH 0/6] Improve -fprefetch-loop-arrays in general and for AArch64 in particular

Hi Maxim, On 30/01/17 11:24, Maxim Kuvyrkov wrote: This patch series improves -fprefetch-loop-arrays pass through small fixes and tweaks, and then enables it for several AArch64 cores. My tunings were done on and for Qualcomm hardware, with results varying between +0.5-1.9% for SPEC2006 INT

[Patch, fortran] PRs79599 and 79523

Dear All, These trivial bugs have been fixed in revision 245603. 2017-02-20 Paul Thomas PR fortran/79599 * interface.c (check_dtio_arg_TKR_intent): Supply 'must' missing from error message. 2017-02-20 Paul Thomas PR fortran/79523

Re: [PATCH PR77536]Generate correct profiling information for vectorized loop

> > 2017-02-16 Bin Cheng > > > > PR tree-optimization/77536 > > * tree-ssa-loop-manip.c (niter_for_unrolled_loop): New function. > > (tree_transform_and_unroll_loop): Use above function to compute the > > estimated niter of unrolled loop. > >

Re: fwprop fix for PR79405

On 02/17/2017 10:11 AM, Richard Biener wrote: Index: gcc/fwprop.c === --- gcc/fwprop.c(revision 245501) +++ gcc/fwprop.c(working copy) @@ -1478,7 +1478,8 @@ fwprop (void) Do not forward propagate addresses into

Re: Improving code generation in the nvptx back end

On 02/17/2017 02:09 PM, Thomas Schwinge wrote: Hi! On Fri, 17 Feb 2017 14:00:09 +0100, I wrote: [...] for "normal" functions there is no reason to use the ".param" space for passing arguments in and out of functions. We can then get rid of the boilerplate code to move ".param %in_ar*" into

Re: [libstdc++,doc] doc/xml/manual/profile_mode.xml: Update a paper reference

On Fri, 10 Feb 2017, Joseph Myers wrote: >> - http://www.w3.org/1999/xlink; >> xlink:href="http://dx.doi.org/10.1109/CGO.2009.36;>paper presented at >> + http://www.w3.org/1999/xlink; >> xlink:href="http://ieeexplore.ieee.org/document/4907670/;>paper presented at > dx.doi.org is specifically

Re: [PATCH] Fix gimplify_expr ICE with Labels as Values (PR middle-end/79537)

On Mon, Feb 20, 2017 at 10:51:04AM +0100, Richard Biener wrote: > On Fri, Feb 17, 2017 at 2:53 PM, Marek Polacek wrote: > > We are crashing with a label as a value without accompanying goto. > > The problem is that TREE_SIDE_EFFECTS and FORCED_LABEL use the same > >

Re: [PATCH PR77536]Generate correct profiling information for vectorized loop

On Thu, Feb 16, 2017 at 6:48 PM, Bin Cheng wrote: > Hi, > After fixing PR79347, the main problem with vectorizer is we scale down > profiling counters > for vect_loop by VF, regardless of context CFG's profiling information. This > is wrong and > sometimes makes vect_loop

RE: [PATCH 5/5] Ensure the mode used to create split registers is suppported

Vladimir Makarov writes: > On 02/07/2017 09:08 AM, Matthew Fortune wrote: > > Hi, > > > > This patch addresses a problem with LRA splitting hard registers where > > the mode requires multiple registers. When splitting then each > > constituent register is split individually

RE: [PATCH 4/5] Partial revert of r243782 to restore previous behavior

Vladimir Makarov writes: > On 02/07/2017 09:08 AM, Matthew Fortune wrote: > > Hi, > > > > This patch partially reverts r243782 where a return false was added > > expecting it to be a no-op. Detailed inspection shows this was not > > true. Despite no bug being identified

RE: [PATCH 2/5] Tighten condition for converting SUBREG reloads from OP_OUT to OP_INOUT

Matthew Fortune writes: > This change addresses a comment from Richard Sandiford in: > https://gcc.gnu.org/ml/gcc-patches/2015-01/msg02165.html > > where a previous fix was over eager in converting OP_OUT reloads to > OP_INOUT. > > No testcase here either but I will

RE: [PATCH 1/5] Handle WORD_REGISTER_OPERATIONS when reloading (subreg(reg))

Vladimir Makarov writes: > On 02/07/2017 09:08 AM, Matthew Fortune wrote: > > Hi, > > > > This change deals with reloading a subreg(reg) using the inner mode to > > prevent partial spilling of data like in the case described here: > >

Re: [Patch, fortran] PR79382 - DTIO ICE

Dear All, Committed as revision 245596. Thanks for the review. Paul On 16 February 2017 at 18:38, Jerry DeLisle wrote: > On 02/16/2017 03:31 AM, Paul Richard Thomas wrote: >> >> Dear All, >> >> The fix for the original bug is tested in dtio_24.f90. It is triggered >> by

Re: [PATCH] Fix various issues with x86 builtins (PR target/79568)

On Fri, Feb 17, 2017 at 7:49 PM, Jakub Jelinek wrote: > Hi! > > The masks for builtins seems to be quite messy. Most of > the builtins have a single OPTION_MASK_ISA_* in there and that is > clear (i.e. that the builtin is only enabled/usable if that isa > bit is on). Then we

RE: [PATCH 3/5] Support WORD_REGISTER_OPERATIONS requirements in simplify_operand_subreg

Hi Eric, Any thoughts on this? Thanks, Matthew > Sorry for the slow reply, been away for a few days > > Eric Botcazou writes: > > > This patch is a minimal change to prevent (subreg(mem)) from being > > > simplified to use the outer mode for

Re: [PATCH] Fix gimplify_expr ICE with Labels as Values (PR middle-end/79537)

On Fri, Feb 17, 2017 at 2:53 PM, Marek Polacek wrote: > We are crashing with a label as a value without accompanying goto. > The problem is that TREE_SIDE_EFFECTS and FORCED_LABEL use the same > ->base.side_effects_flag, so gimplify_expr is confused. We don't > ICE with 'goto

Re: [Patch, fortran] PR79434 - [submodules] separate module procedure breaks encapsulation

Hi Everybody, Committed as revision 245595. Thanks for the review. Paul On 16 February 2017 at 00:38, Jerry DeLisle wrote: > On 02/15/2017 10:12 AM, Paul Richard Thomas wrote: >> Dear All, >> >> Another straightforward patch, although it took some head scratching >> to

Re: [PATCH] Change default of param not being smaller that min.

On Fri, Feb 17, 2017 at 4:18 PM, Martin Liška wrote: > Hello. > > We should not have a default value (different from -1) that is smaller than > minimum. > > Ready to be installed after tests? I think you should instead change the minimum value. But OTOH I wonder why this is a

Re: Ping [Patch, fortran] PR79402 - ICE with submodules: module procedure interface defined in parent module

Dear Paul and Jerry (and all gfortran brave heroes), thank you very much for your great work! Cheers Stefano Zaghi Ph.D. Aerospace Engineer Research Scientist, Dept. of Computational Hydrodynamics at CNR-INSEAN p: +39 0650299260 | m: +39 3497730036 | e: stefano.za...@gmail.com Member of