Re: [Committed] [PATCH 2/4] (v4) On-demand locations within string-literals

On 6 August 2016 at 11:16, Markus Trippelsdorf wrote: > On 2016.08.05 at 14:16 -0400, David Malcolm wrote: >> Successfully bootstrapped the updated patch on x86_64-pc >> -linux-gnu, and successfully ran the stage 1 selftests on powerpc-ibm >> -aix7.1.3.0 (gcc111) >> >>

Re: [Committed] [PATCH 2/4] (v4) On-demand locations within string-literals

On 2016.08.05 at 14:16 -0400, David Malcolm wrote: > Successfully bootstrapped the updated patch on x86_64-pc > -linux-gnu, and successfully ran the stage 1 selftests on powerpc-ibm > -aix7.1.3.0 (gcc111) > > Committed to trunk as r239175; I'm attaching the final version of the > patch for

Re: [Patch] Implement std::experimental::variant

On Fri, Aug 5, 2016 at 4:08 AM, Jonathan Wakely wrote: >> --- a/libstdc++-v3/include/bits/uses_allocator.h >> +++ b/libstdc++-v3/include/bits/uses_allocator.h >> @@ -113,6 +113,51 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION >> constexpr bool uses_allocator_v = uses_allocator<_Tp,

Re: [PATCH build/doc] Replacing libiberty with gnulib

On 5 August 2016 at 4:09:00 AM, Pedro Alves (pal...@redhat.com) wrote: > On 08/02/2016 12:38 AM, Manuel López-Ibáñez wrote: > > > > If there is something wrong or missing, ideally we would like to know > > so that Ayush can work on fixing it before the Summer of Code is over > > in less than two

Re: [RS6000] PR72802 part 2, reload ICE

On Sat, Aug 06, 2016 at 10:53:33AM +0930, Alan Modra wrote: > On Fri, Aug 05, 2016 at 06:01:47PM -0500, Segher Boessenkool wrote: > > On Fri, Aug 05, 2016 at 02:20:40PM +0930, Alan Modra wrote: > > > Here are the reload costs for the various alternatives of > > > movsf_hardfloat: > > > "=!r, !r,

Re: [RS6000] PR72802 part 2, reload ICE

On Fri, Aug 05, 2016 at 06:01:47PM -0500, Segher Boessenkool wrote: > On Fri, Aug 05, 2016 at 02:20:40PM +0930, Alan Modra wrote: > > Here are the reload costs for the various alternatives of > > movsf_hardfloat: > > "=!r, !r, m, f, ww, ww, !r, f, wb, m, wY, wu, Z,?wn, ?r,*c*l, !r, *h" > >

Re: [PATCH,rs6000] Add built-in function support Power9 binary floating point operations

On Fri, Aug 05, 2016 at 04:27:36PM -0500, Pat Haugen wrote: > On 08/02/2016 03:15 PM, Segher Boessenkool wrote: > > On Tue, Aug 02, 2016 at 03:03:42PM -0500, Pat Haugen wrote: > >> On 07/29/2016 10:47 AM, Kelvin Nilsen wrote: > >>> + "xsxexpdp %0,%x1" > >>> + [(set_attr "type" "fp")]) > >> > >>

[PATCH] c-format.c: cleanup of check_format_info_main

On Thu, 2016-08-04 at 14:22 -0600, Jeff Law wrote: > On 08/04/2016 01:24 PM, David Malcolm wrote: > > > > Do you realize that this isn't used for ~700 lines after this > > > point? > > > Is > > > there any sensible way to factor some code here to avoid the > > > coding > > > disconnect. I

libgo patch committed: Change build procedure to use build tags

Go packages use build tags (see the section on Build Constraints at https://golang.org/pkg/go/build/) to select which files to build on specific systems. Previously the libgo Makefile explicitly listed the set of files to compile for each package. For packages that use build tags, this required

[PATCH] Add std::apply for C++17

To avoid a circular dependency between and I've moved std::__invoke to its own header. In order to use std::__invoke in std::apply it needs to be constexpr, which is easy, but the standard says that std::invoke isn't constexpr. So we have to intentionally disallow std::invoke in constant

Re: [RS6000] PR72802 part 2, reload ICE

On Fri, Aug 05, 2016 at 02:20:40PM +0930, Alan Modra wrote: > Here are the reload costs for the various alternatives of > movsf_hardfloat: > "=!r, !r, m, f, ww, ww, !r, f, wb, m, wY, wu, Z,?wn, ?r,*c*l, !r, *h" > "r, m, r, f, ww, j, j, m, wY, f, wb, Z, wu, r, wn, r, *h, 0" >

Re: [RS6000] PR72802 part 1, fix constraints for lxssp/stxssp

On Fri, Aug 05, 2016 at 11:35:11AM +0930, Alan Modra wrote: > diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c > index 779ba1f..c59d07a 100644 > --- a/gcc/config/rs6000/rs6000.c > +++ b/gcc/config/rs6000/rs6000.c > @@ -7717,8 +7717,34 @@ mem_operand_gpr (rtx op, machine_mode

Re: [PATCH], Improve vector int/long initialization on PowerPC

On 08/03/2016 11:33 PM, Michael Meissner wrote: > { > - if (BYTES_BIG_ENDIAN) > -return "xxpermdi %x0,%x1,%x2,0"; > + if (which_alternative == 0) > +return (BYTES_BIG_ENDIAN > + ? "xxpermdi %x0,%x1,%x2,0" > + : "xxpermdi %x0,%x2,%x1,0"); > + > + else if

Re: [PR49366] emit loc exprs for C++ non-virtual pmf template value parms

On Aug 5, 2016, Jason Merrill wrote: >> With this patch, when we can't emit a DW_AT_const_value, we emit each >> "member" of the pointer to member function "record" as a >> DW_OP_stack_value DW_OP_piece, as long as the referenced member >> function is output in the same

Re: [PATCH v2,rs6000] Add built-in function support for Power9 binary floating point operations

On 08/04/2016 10:27 AM, Kelvin Nilsen wrote: > + "xsxexpdp %0,%x1" > + [(set_attr "type" "vecsimple")]) > + "xsxsigdp %0,%x1" > + [(set_attr "type" "vecsimple")]) 'integer' for both, reasoning in response on initial thread for this patch. > + "xvxexp %x0,%x1" > + [(set_attr "type"

Re: [PR63240] generate debug info for defaulted member functions

On Aug 4, 2016, Jason Merrill wrote: > On Mon, Aug 1, 2016 at 10:57 PM, Alexandre Oliva wrote: >> * langhooks.h (struct lang_hooks_for_decls): Add >> function_decl_defaulted_inclass_p and >> function_decl_defaulted_outofclass_p. > Maybe one hook that

one more patch for PR69847

This is a patch to fix some testsuite failures reported for arm: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69847 The patch was bootstrapped and tested on x86-64 and ppc64. Committed as rev. 239180. Index: ChangeLog === ---

Re: backward threading heuristics tweek

On 06/06/2016 04:19 AM, Jan Hubicka wrote: Hi, while looking into profile mismatches introduced by the backward threading pass I noticed that the heuristics seems quite simplistics. First it should be profile sensitive and disallow duplication when optimizing cold paths. Second it should use

Re: Go patch committed: Avoid non-ASCII characters in asm identifiers

On Fri, Aug 5, 2016 at 2:13 PM, Joseph Myers wrote: > On Fri, 5 Aug 2016, Ian Lance Taylor wrote: > >> PR 72812 points out that Go can generate non-ASCII characters in >> assembly code. This is a consequence of the fact that Go permits >> identifiers to contain non-ASCII

Re: [PATCH,rs6000] Add built-in function support Power9 binary floating point operations

On 08/02/2016 03:15 PM, Segher Boessenkool wrote: > On Tue, Aug 02, 2016 at 03:03:42PM -0500, Pat Haugen wrote: >> On 07/29/2016 10:47 AM, Kelvin Nilsen wrote: >>> + "xsxexpdp %0,%x1" >>> + [(set_attr "type" "fp")]) >> >> Type should be 'integer'. > > It has VSX regs as input, integer is worse

Re: [PATCH] Improve backwards threading

On 08/05/2016 07:36 AM, Richard Biener wrote: @@ -560,6 +562,14 @@ fsm_find_control_statement_thread_paths edge taken_edge = profitable_jump_thread_path (path, bbi, name, arg); if (taken_edge) { + /* If the taken edge is a loop entry avoid mashing two

Re: Go patch committed: Avoid non-ASCII characters in asm identifiers

On Fri, 5 Aug 2016, Ian Lance Taylor wrote: > PR 72812 points out that Go can generate non-ASCII characters in > assembly code. This is a consequence of the fact that Go permits > identifiers to contain non-ASCII Unicode code points. The GNU > assembler doesn't seem to mind, but the Solaris

Re: [PATCH] Improve forward jump threading of switch statements (PR18046)

On 07/28/2016 09:46 PM, Patrick Palka wrote: This patch improves the forward jump threader's ability to thread GIMPLE_SWITCHes by making the VRP simplification callback attempt to determine which case label will be taken. For example, if the index operand of a switch has a value range ~[5,6]

Re: [PATCH/AARCH64] Improve ThunderX code generation slightly with load/store pair

On 08/05/2016 12:18 AM, Andrew Pinski wrote: This patch disables the forming of the load/store pairs for SImode if we are tuning for ThunderX. I used the tuning flags route so it can be overridden if needed later on or if someone else wants to use the same method for their core. + if (mode

Re: [PATCH] Remove unnecessary jump threading restriction

On 08/05/2016 01:45 AM, Richard Biener wrote: There is no need to avoid threading to a loop header, the threading code can cope with this just fine. Noticed when working on PR72772. Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk. Richard. 2016-08-05 Richard Biener

Re: [PATCH] gcov tool: Implement Hawick's algorithm for cycle detection, (PR gcov-profile/67992)

On Fri, Aug 05, 2016 at 08:27:39AM -0700, Andrew Pinski wrote: > On Fri, Aug 5, 2016 at 12:32 AM, Martin Liška wrote: > > On 08/05/2016 09:30 AM, Martin Liška wrote: > >> Hi. > >> > >> Sorry for the mistake with the enum, that was silly ;) > >> New patch version also handles the

Re: [RS6000] Force source of fix_truncsi2 to reg

On Wed, Aug 03, 2016 at 12:02:54AM +0930, Alan Modra wrote: > This is a hack I tried to avoid having to poke at lra code for > pr71680.. > > The idea of adding force_reg here was that it removes subregs from > fix_trunc, emitting the subreg mode conversion in a separate set insn. > That avoids

Re: [PATCH][PR64971]Convert function pointer to Pmode when emit call

On 08/04/2016 08:32 AM, Renlin Li wrote: Hi all, In the case of PR64971 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64971), the compiler ICE when compiling gcc.c-torture/compile/pr37433.c with ilp32 abi. As we know, in aarch64 ilp32, the ptr_mode is SImode while Pmode is still DImode. It

Go patch committed: Avoid non-ASCII characters in asm identifiers

PR 72812 points out that Go can generate non-ASCII characters in assembly code. This is a consequence of the fact that Go permits identifiers to contain non-ASCII Unicode code points. The GNU assembler doesn't seem to mind, but the Solaris assembler does. This patch changes the GCC Go interface

Re: protected alloca class for malloc fallback

On August 5, 2016 8:15:54 PM GMT+02:00, Oleg Endo wrote: >On Fri, 2016-08-05 at 19:55 +0200, Richard Biener wrote: > >> >> Please don't use std::string. For string building you can use >> obstacks. >> > >Just out of curiosity ... why? I remember there was some

Re: [C++/68724] ICE with TRAIT_EXPR

On 08/05/16 12:06, Jason Merrill wrote: On Fri, Aug 5, 2016 at 8:24 AM, Nathan Sidwell wrote: I've committed this patch to fix a failed assertion. unify's (pt.c) default case asserts EXPR_P(parm), but TRAIT_EXPR is tcc_exceptional, so fails. However from unify's POV it's no

Re: [PR49366] emit loc exprs for C++ non-virtual pmf template value parms

On Aug 5, 2016, Jason Merrill wrote: > On Sat, Jul 23, 2016 at 10:30 AM, Alexandre Oliva wrote: >> With this patch, when we can't emit a DW_AT_const_value, we emit each >> "member" of the pointer to member function "record" as a >> DW_OP_stack_value

Re: [wwwdocs] Add branch description for new branch unified-autovect

On Fri, 8 Jul 2016, Sameera Deshpande wrote: > I have created new branch unified-autovect based on ToT. > > Please find attached the patch adding information about new branch > "unified-autovect" in the documentation. Is it ok to commit? Yes, please! (Once a branch exists, you don't need to

Re: protected alloca class for malloc fallback

On Fri, 2016-08-05 at 19:55 +0200, Richard Biener wrote: > > Please don't use std::string. For string building you can use > obstacks. > Just out of curiosity ... why? I remember there was some discussion about it, what was the conclusion? Is that now a general rule or does it depend on the

Re: protected alloca class for malloc fallback

On August 5, 2016 4:42:48 PM GMT+02:00, Aldy Hernandez wrote: > >> I was surprised by the always_inline trick. I suppose it makes >> sense but I wouldn't have expected to be able to rely on it. Out >> of curiosity I tested it with other compilers. It turns out that >> it only

Re: protected alloca class for malloc fallback

On August 5, 2016 6:23:27 PM GMT+02:00, Jeff Law wrote: >On 08/05/2016 08:37 AM, Aldy Hernandez wrote: >> >> After looking at all this code, I realize no size will fit all if we >> want something clean. So, I take my approach back. I think we're >best >> served by a couple

Re: [PR49366] emit loc exprs for C++ non-virtual pmf template value parms

On Sat, Jul 23, 2016 at 10:30 AM, Alexandre Oliva wrote: > We used to emit, in debug information, the values bound to pointer to > member function template parameters only when they were NULL or > virtual member functions, because those can be represented with >

Re: [PATCH] gcov tool: Implement Hawick's algorithm for cycle detection, (PR gcov-profile/67992)

On Fri, 5 Aug 2016, Andrew Pinski wrote: >> I attached a wrong patch, sending the new one. > This broke cross aarch64-elf-gnu building. It also broke native i586-unknown-freebsd10.3 (which features clang as the system compiler). /scratch/tmp/gerald/gcc-HEAD/gcc/gcov.c:468:25: error: use of

Re: [PATCH] aarch64: Add split-stack initial support

Ping. On 28/07/2016 17:36, Adhemerval Zanella wrote: > From: Adhemerval Zanella > > This patch adds the split-stack support on aarch64 (PR #67877). As for > other ports this patch should be used along with glibc and gold support. > > The support is done similar

Re: [Revert][AArch64] PR 63521 Define REG_ALLOC_ORDER/HONOR_REG_ALLOC_ORDER

Andrew Pinski writes: > On Mon, Jul 27, 2015 at 3:36 AM, James Greenhalgh > wrote: >> On Mon, Jul 27, 2015 at 10:52:58AM +0100, pins...@gmail.com wrote: >>> > On Jul 27, 2015, at 2:26 AM, Jiong Wang wrote: >>> > >>> > Andrew Pinski writes: >>> >

Re: protected alloca class for malloc fallback

On 08/05/2016 08:37 AM, Aldy Hernandez wrote: After looking at all this code, I realize no size will fit all if we want something clean. So, I take my approach back. I think we're best served by a couple different approaches, depending on usage. Yup. My question is, how wed are we to an

Re: RFC: Make diagnostics for C++ reference binding more consistent

OK. On Fri, Aug 5, 2016 at 5:08 AM, Jonathan Wakely wrote: > On 27/07/16 18:06 -0400, Jason Merrill wrote: >> >> On Wed, Jul 27, 2016 at 8:05 AM, Jonathan Wakely >> wrote: >>> >>> Consider: >>> >>> template T declval(); >>> >>> int& r1 = declval();

Re: [C++/68724] ICE with TRAIT_EXPR

On Fri, Aug 5, 2016 at 8:24 AM, Nathan Sidwell wrote: > I've committed this patch to fix a failed assertion. unify's (pt.c) default > case asserts EXPR_P(parm), but TRAIT_EXPR is tcc_exceptional, so fails. > However from unify's POV it's no more exceptional than, say,

Re: [PATCH RFC] do not throw in std::make_exception_ptr

On Wed, Aug 3, 2016 at 8:36 AM, Jonathan Wakely wrote: > On 03/08/16 15:02 +0300, Gleb Natapov wrote: >> >> On Wed, Aug 03, 2016 at 12:47:30PM +0100, Jonathan Wakely wrote: >>> Huh. If I'm reading the ABI spec correctly, we should terminate if the >>> copy constructor throws.

Re: [PATCH] gcov tool: Implement Hawick's algorithm for cycle detection, (PR gcov-profile/67992)

On Fri, Aug 5, 2016 at 12:32 AM, Martin Liška wrote: > On 08/05/2016 09:30 AM, Martin Liška wrote: >> Hi. >> >> Sorry for the mistake with the enum, that was silly ;) >> New patch version also handles the unnecessary braces. >> >> Martin > > I attached a wrong patch, sending the

Re: [GCC Steering Committee attention] [PING] [PING] [PING] libgomp: In OpenACC testing, cycle though $offload_targets, and by default only build for the offload target that we're actually going to te

On 08/04/2016 04:49 PM, Thomas Schwinge wrote: Global Reviewers are welcome to review OpenACC/OpenMP/offloading patches. But that doesn't help if that's then not happening in reality. (With the exception of Bernd, who then did review such patches for a while, but also seems to have stopped with

Re: [PATCH, ARM] Add a new target hook to compute the frame layout

On 08/05/16 16:06, Richard Earnshaw (lists) wrote: > > Thanks, that's pretty much what I expected would be the case. > > Could I suggest: > > This target hook is called once each time the frame layout needs to be > recalculated. The calculations can be cached by the target and can then > be used

Re: protected alloca class for malloc fallback

On 08/05/2016 03:37 PM, Aldy Hernandez wrote: > My question is, how wed are we to an alloca based approach? Can we > replace the non-critical uses by std::string (diagnostics, > BLAH_check_failed(), building a string to manipulate the output of > env("SOME_VAR"), etc?). My suggestion too. ( I

Re: [PATCH GCC]Simplify interface for simplify_using_initial_conditions

On Thu, Aug 4, 2016 at 1:48 PM, Richard Biener wrote: > On Thu, Aug 4, 2016 at 10:40 AM, Bin.Cheng wrote: >> On Wed, Aug 3, 2016 at 11:17 PM, Jeff Law wrote: >>> On 08/03/2016 10:35 AM, Bin Cheng wrote: Hi, When

Re: protected alloca class for malloc fallback

I was surprised by the always_inline trick. I suppose it makes sense but I wouldn't have expected to be able to rely on it. Out of curiosity I tested it with other compilers. It turns out that it only works with some like GCC and IBM XLC++, but not others like Clang or Sun CC. In recursive

Re: [AArch64] Handle HFAs of float16 types properly

On 26/07/16 14:55, James Greenhalgh wrote: > > Hi, > > It looks like we've not been handling structures of 16-bit floating-point > data correctly for AArch64. For some reason we end up passing them > packed in to integer registers. That is to say, on trunk and GCC 6, for: > > struct x { >

Re: protected alloca class for malloc fallback

I think only thing you're missing is that we probably don't want to be using alloca in new code anyway. And if we're going through the trouble of fixing old code, we ought to just remove alloca. So building up this kind of class is probably taking folks in the wrong direction. After

Re: [PATCH][expr.c] PR middle-end/71700: zero-extend sub-word value when widening constructor element

On 01/08/16 15:31, Kyrill Tkachov wrote: On 11/07/16 18:55, Bernd Schmidt wrote: On 07/11/2016 04:52 PM, Kyrill Tkachov wrote: Based on that, I think that code block is a useful optimisation, we just need to take care with immediates. What do you think? Yeah, I think the patch is ok.

Re: [AArch64] Handle HFAs of float16 types properly

On 05/08/16 15:17, James Greenhalgh wrote: > On Fri, Aug 05, 2016 at 11:15:24AM +0100, James Greenhalgh wrote: >> On Fri, Aug 05, 2016 at 11:00:39AM +0100, Yao Qi wrote: >>> On Tue, Jul 26, 2016 at 2:55 PM, James Greenhalgh >>> wrote: OK? As this is an ABI

Re: [AArch64] Handle HFAs of float16 types properly

On Fri, Aug 05, 2016 at 11:15:24AM +0100, James Greenhalgh wrote: > On Fri, Aug 05, 2016 at 11:00:39AM +0100, Yao Qi wrote: > > On Tue, Jul 26, 2016 at 2:55 PM, James Greenhalgh > > wrote: > > > > > > OK? As this is an ABI break, I'm not proposing for it to go back to

Re: [PATCH, ARM] Add a new target hook to compute the frame layout

On 05/08/16 13:49, Bernd Edlinger wrote: > On 08/05/16 11:29, Richard Earnshaw (lists) wrote: >> On 04/08/16 22:16, Bernd Edlinger wrote: >>> Hi, >>> >>> this patch introduces a new target hook that allows the target's >>> INITIAL_ELIMINATION_OFFSET function to use cached values instead of >>>

Re: [PATCH] Define feature-test macro for std::enable_shared_from_this

On 04/08/16 13:33 +0100, Jonathan Wakely wrote: On 03/08/16 20:11 +0100, Jonathan Wakely wrote: Another feature we already support, so just define the macro. * include/bits/shared_ptr_base.h (__cpp_lib_enable_shared_from_this): Define feature-test macro. *

[PATCH] Implement C++17 rounding functions for std::chrono (P0092R1)

* include/std/chrono (floor, ceil, round, abs): New for C++17. * testsuite/20_util/duration_cast/rounding.cc: New test. * testsuite/20_util/time_point_cast/rounding.cc: New test. * doc/xml/manual/status_cxx2017.xml: Update status table. *

Re: [PATCH PR71734] Add missed check that reference defined inside loop.

On Fri, Aug 5, 2016 at 3:28 PM, Yuri Rumyantsev wrote: > Richard, > > Here is updated patch which implements your proposal - I pass loop > instead of stmt to determine either REF is defined inside LOOP nest or > not. I checked that for pr70729-nest.cc the reference this->S_n

Re: [PATCH 1/4] Cherry-pick fprofile-generate-atomic from google/gcc-4_9 branch

On 08/05/2016 03:14 PM, Nathan Sidwell wrote: > On 08/05/16 08:48, Martin Liška wrote: > >> Ok, after all the experimenting and inventing "almost" thread-safe code, I >> incline to not to include __gcov_one_value_profiler_body_atomic >> counter. The final solution is cumbersome and probably does

Re: [PATCH] Fix PR tree-optimization/72810

On Fri, Aug 5, 2016 at 3:08 PM, Patrick Palka wrote: > Sometimes the case labels of a switch have a different type than the > switch operand, e.g. in the test case below, the case labels have type t > and the switch operand has type int. Because the verifier expects that >

Re: [PATCH] Improve backwards threading

On Fri, 5 Aug 2016, Richard Biener wrote: > On Fri, 5 Aug 2016, Richard Biener wrote: > > > > > This avoids regressing gcc.dg/tree-ssa/pr21417.c with the fix for > > PR72772 where after it a forwarder block no longer is present. > > It's easy to simply create it when FSM threading faces the

Re: [PATCH] Improve backwards threading

On Fri, 5 Aug 2016, Richard Biener wrote: > > This avoids regressing gcc.dg/tree-ssa/pr21417.c with the fix for > PR72772 where after it a forwarder block no longer is present. > It's easy to simply create it when FSM threading faces the situation > that the edge ending the path enters a loop. >

Re: [PATCH][COMMITTED] Revert r238497 because of PR 71961.

Hi Joost, I am not familiar with fortran code. Maybe Thomas can do something in his new patch? Regards, Renlin On 28/07/16 12:34, VandeVondele Joost wrote: Thanks.. I wonder if you could add the testcase in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71961#c11 to the testsuite, as it

Re: [PING**2] [PATCH] Fix asm X constraint (PR inline-asm/59155)

On 08/04/16 22:27, Jeff Law wrote: > On 07/21/2016 10:29 AM, Bernd Edlinger wrote: But I think we have a use case where "X" means really more possible registers (i.e. includes ss2, mmx etc.) than "g" (only general registers). Otherwise, in the test cases of pr59155 we would not

Re: [PATCH PR71734] Add missed check that reference defined inside loop.

Richard, Here is updated patch which implements your proposal - I pass loop instead of stmt to determine either REF is defined inside LOOP nest or not. I checked that for pr70729-nest.cc the reference this->S_n for statements which are out of innermost loop are not considered as independent as

Re: [PATCH 1/4] Cherry-pick fprofile-generate-atomic from google/gcc-4_9 branch

On 08/05/16 08:48, Martin Liška wrote: Ok, after all the experimenting and inventing "almost" thread-safe code, I incline to not to include __gcov_one_value_profiler_body_atomic counter. The final solution is cumbersome and probably does not worth doing. Moreover, even having a thread-safe

[PATCH] Fix PR tree-optimization/72810

Sometimes the case labels of a switch have a different type than the switch operand, e.g. in the test case below, the case labels have type t and the switch operand has type int. Because the verifier expects that case labels of a switch each have the exact same type, it's important to avoid

Re: [PATCH, ARM] Add a new target hook to compute the frame layout

On 08/05/16 11:29, Richard Earnshaw (lists) wrote: > On 04/08/16 22:16, Bernd Edlinger wrote: >> Hi, >> >> this patch introduces a new target hook that allows the target's >> INITIAL_ELIMINATION_OFFSET function to use cached values instead of >> re-computing the frame layout every time. >> >> I

Re: [PATCH 1/4] Cherry-pick fprofile-generate-atomic from google/gcc-4_9 branch

On 08/05/2016 02:38 PM, Nathan Sidwell wrote: > On 08/05/16 04:55, Martin Liška wrote: > >> Thank you for very intensive brainstorming ;) Well I still believe that >> following code >> is not thread safe, let's image following situation: >> > > yeah, you're right. > >>> we could do better by

Re: [PATCH] gcov: rename line_next to next_file_fn in function_info

On 08/05/16 08:22, Martin Liška wrote: Hello. This corrects a record field name where comment does not correspond to it's name. make check -k RUNTESTFLAGS="gcov.exp" works fine. Ready to install? heh, 'line_next' is perfectly good name for the next function. No, wait, it's stupid! your

Re: [PATCH 1/4] Cherry-pick fprofile-generate-atomic from google/gcc-4_9 branch

On 08/05/16 04:55, Martin Liška wrote: Thank you for very intensive brainstorming ;) Well I still believe that following code is not thread safe, let's image following situation: yeah, you're right. we could do better by using compare_exchange storing value, and detect the race I

Re: [RFC] ipa bitwise constant propagation

Hi, generally speaking, the ipa-cp.c and ipa-cp.[hc] bits look reasonable, but I have a few comments: On Thu, Aug 04, 2016 at 12:06:18PM +0530, Prathamesh Kulkarni wrote: > Hi, > This is a prototype patch for propagating known/unknown bits > inter-procedurally. > for integral types which

Re: [PATCH] gcov tool: Implement Hawick's algorithm for cycle detection, (PR gcov-profile/67992)

On 08/05/16 03:32, Martin Liška wrote: On 08/05/2016 09:30 AM, Martin Liška wrote: Hi. Sorry for the mistake with the enum, that was silly ;) New patch version also handles the unnecessary braces. Martin I attached a wrong patch, sending the new one. This one looks good, thanks! nathan

[C++/68724] ICE with TRAIT_EXPR

I've committed this patch to fix a failed assertion. unify's (pt.c) default case asserts EXPR_P(parm), but TRAIT_EXPR is tcc_exceptional, so fails. However from unify's POV it's no more exceptional than, say, SIZEOF_EXPR, so should be allowed at that point. nathan 2016-08-05 Nathan Sidwell

[PATCH] gcov: rename line_next to next_file_fn in function_info

Hello. This corrects a record field name where comment does not correspond to it's name. make check -k RUNTESTFLAGS="gcov.exp" works fine. Ready to install? Martin >From 1733e26c619e65ef95604f04f026be0006e9c4e0 Mon Sep 17 00:00:00 2001 From: marxin Date: Fri, 5 Aug 2016

[RFT PATCH, i386]: Optimize zero-extensions from mask registers

Hello! Attached patch was inspired by assembly from PR 72805 testcase. Currently, the compiler generates: test: vpternlogd $0xFF, %zmm0, %zmm0, %zmm0 vpxord %zmm1, %zmm1, %zmm1 vpcmpd $1, %zmm1, %zmm0, %k1 kmovw %k1, %eax movzwl %ax, %eax

Re: [ARM] mno-pic-data-is-text-relative & msingle-pic-base

On 08/05/16 00:56, Irfan Ahmad wrote: 1. In the absence of lazy binding (that is almost always the case in embedded systems), GOT is practically read-only - it needs to be modified only during 'practically' as in 'almost', or is it really read only? linking by the dynamic linker, after that

Re: [RFC] ipa bitwise constant propagation

> Hi Honza, > > On 04/08/16 23:05, Jan Hubicka wrote: > >>I didn't look at the propagation part but eventually the IPA-CP > >>lattice gets quite big. Also the alignment lattice is very > >>similar to the bits lattice so why not merge those two? But > > > >This was always the original idea to

Re: [patch] New libstdc++ docs on testing and library versioning

On 05/08/16 01:37 +0100, Jonathan Wakely wrote: The core of the new guidelines for writing tests is this: [begin] Test cases that use features of a particular C++ standard should specify the minimum required standard as an effective target: // { dg-do run { target c++11 } } or // {

[PATCH] Fix (parts of) PR68273

The following patch avoids overaligned types created from IPA parameter replacement. It is said to help mipsel which still suffers from the backend-looks-at-type-alignment-for-parameter-passing-ABI bug. Bootstrap and regtest pending on x86_64-unknown-linux-gnu. mips testing appreciated.

[PATCH] Fix PR72772

This fixes PR72772 by avoing placing a degenerate PHI in each forwarder block loop init creates when creating simple preheaders. The solution is to simply split the single loop entry edge which is also way cheaper than using the forwarder block creation path. You've seen a load of fallout fixes

[PATCH] Improve backwards threading

This avoids regressing gcc.dg/tree-ssa/pr21417.c with the fix for PR72772 where after it a forwarder block no longer is present. It's easy to simply create it when FSM threading faces the situation that the edge ending the path enters a loop. I also fixed the costs for obviously related anon SSA

Re: [PATCH] Teach VRP to truncate the case ranges of a switch

On 2016.08.03 at 15:47 +0200, Richard Biener wrote: > On Wed, Aug 3, 2016 at 6:00 AM, Patrick Palka wrote: > > VRP currently has functionality to eliminate case labels that lie > > completely outside of the switch operand's value range. This patch > > complements this

Re: [AArch64] Handle HFAs of float16 types properly

On Fri, Aug 05, 2016 at 11:00:39AM +0100, Yao Qi wrote: > On Tue, Jul 26, 2016 at 2:55 PM, James Greenhalgh > wrote: > > > > OK? As this is an ABI break, I'm not proposing for it to go back to GCC 6, > > though it will apply cleanly there if the maintainers support that.

Re: [PATCH][AArch64] Improve stack adjustment

On 04/08/16 16:56, Richard Earnshaw (lists) wrote: > On 04/08/16 12:06, Wilco Dijkstra wrote: >> Improve stack adjustment by reusing a temporary move immediate >> from the epilog if the register is still valid in the epilog. This generates >> smaller code for leaf functions: >> >> mov

Re: [AArch64] Handle HFAs of float16 types properly

On Tue, Jul 26, 2016 at 2:55 PM, James Greenhalgh wrote: > > OK? As this is an ABI break, I'm not proposing for it to go back to GCC 6, > though it will apply cleanly there if the maintainers support that. > What do you mean by "ABI break"? AFAICS, with this patch, it

Re: [PATCH, ARM] Add a new target hook to compute the frame layout

On 04/08/16 22:16, Bernd Edlinger wrote: > Hi, > > this patch introduces a new target hook that allows the target's > INITIAL_ELIMINATION_OFFSET function to use cached values instead of > re-computing the frame layout every time. > > I have updated the documentation a bit and hope it is clearer

RE: [ARM] mno-pic-data-is-text-relative & msingle-pic-base

Irfan, Thanks for the case sharing. It is a persuasive reason not to error out -mno-SPB. Nathan's patch changes default behaviour that -mSPB will be implied when -mno-PDITR is provided. So with this patch your project need to explicitly specify -mno-SPB to make it work as before. IMHO

Re: RFC: Make diagnostics for C++ reference binding more consistent

On 27/07/16 18:06 -0400, Jason Merrill wrote: On Wed, Jul 27, 2016 at 8:05 AM, Jonathan Wakely wrote: Consider: template T declval(); int& r1 = declval(); int&& r2 = declval(); int& r3 = declval(); This produces three quite different errors: refs.cc:3:25:

Re: make streaming routines for widest_int non-static

Hi Richard and Prathamesh, On 05/08/16 18:23, Richard Biener wrote: On Fri, 5 Aug 2016, Prathamesh Kulkarni wrote: Hi, This patch makes streamer_read_wi and streamer_write_wi non-static, and exports them from lto-streamer.h. I suppose this hunk could be committed independently of the

[PATCH] Use __invoke in std::function internals

This fixes a bug in the _Callable SFINAE constraint of std::function, where it was using an rvalue _Func in the result_of expression, when the target is actually invoked as an lvalue. I'm also making std::function use std::__invoke() directly, instead of going via __callable_functor() and/or

Re: [PATCH 1/4] Cherry-pick fprofile-generate-atomic from google/gcc-4_9 branch

On 08/04/2016 07:03 PM, Nathan Sidwell wrote: > On 08/04/16 12:43, Nathan Sidwell wrote: > >> How about: >> gcov_t expected; >> atomic_load ([0], val, ...); >> gcov_t delta = val == value ? 1 : -1; >> atomic_add ([1], delta); <-- or atomic_add_fetch >> if (delta < 0) { >> /* can we set

[PATCH] Make gcc.dg/tree-ssa/ivopt_5.c more robust

If edges are swapped so are PHI args, the following adjusts the pattern for this case. Committed. Richard. 2016-08-05 Richard Biener * gcc.dg/tree-ssa/ivopt_5.c: Make robust against edge swapping. Index: gcc/testsuite/gcc.dg/tree-ssa/ivopt_5.c

Re: libgo patch committed: Update to 1.7rc3

On Thu, Aug 4, 2016 at 6:48 PM, Ian Lance Taylor wrote: > On Thu, Aug 4, 2016 at 1:11 AM, Uros Bizjak wrote: >> On Thu, Aug 4, 2016 at 12:53 AM, Ian Lance Taylor wrote: >>> On Thu, Jul 28, 2016 at 4:24 AM, Uros Bizjak

Re: make streaming routines for widest_int non-static

On Fri, 5 Aug 2016, Prathamesh Kulkarni wrote: > Hi, > This patch makes streamer_read_wi and streamer_write_wi non-static, > and exports them from lto-streamer.h. I suppose this hunk could be committed > independently of the ipa-bitwise-cp patch ? > Bootstrap+test in progress on

Re: [tree-ssa-ccp] modify extend_mask to extend bits based on signop

On Fri, 5 Aug 2016, Prathamesh Kulkarni wrote: > Ah, the mail failed to be delivered to gcc-patches, sorry for the double-post. > On 5 August 2016 at 01:26, Prathamesh Kulkarni > wrote: > > Hi, > > Is the attached patch OK ? > > Since we want to extend based on

Re: fix fallout of pr22051-2.c on arm

On Fri, 5 Aug 2016, Prathamesh Kulkarni wrote: > On 4 August 2016 at 12:39, Richard Biener wrote: > > On Thu, 4 Aug 2016, Prathamesh Kulkarni wrote: > > > >> Hi, > >> The attached patch fixes pr22051-2.c which regressed due to > >> r238754. Matthew, could you please confirm if

Re: protected alloca class for malloc fallback

On Thu, Aug 4, 2016 at 5:19 PM, Aldy Hernandez wrote: > On 08/04/2016 08:57 AM, Richard Biener wrote: >> >> On Thu, Aug 4, 2016 at 1:30 PM, Aldy Hernandez wrote: >>> >>> Howdy! >>> >>> As part of my -Walloca-larger-than=life work, I've been running said pass

[PATCH] Remove unnecessary jump threading restriction

There is no need to avoid threading to a loop header, the threading code can cope with this just fine. Noticed when working on PR72772. Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk. Richard. 2016-08-05 Richard Biener *

  1   2   >