Re: [PATCH] RFC: -fasm-show-source

On 12 August 2016 at 02:04, David Malcolm wrote: > I sometimes find myself scouring assembler output from the compiler > and trying to figure out which instructions correspond to which > lines of source code; I believe this is a common activity for some > end-users. Hi David,

Re: [PATCH] Indicate minimum in-tree MPFR version handled

On 08/12/16, Maciej W. Rozycki wrote: > Hi, > > Commit 235763 removed support for versions of MPFR below 3.1.0 which have > a flat directory structure, however it did not introduce any safety check > for such an unhandled library version present in the tree. Consequently > the system-installed

Re: [PATCH] Fix warning breaking profiled bootstrap

> > If sym1 results in a return value that is some useful tree and inv1 > is true and cst1 is true via this call: The only way for get_single_symbol to return a non NULL tree is to hit the return at the end -- and that always initializes inv and neg. And when the return is NULL the && prevents

Re: [RFC][PR61839]Convert CST BINOP COND_EXPR to COND_EXPR ? (CST BINOP 1) : (CST BINOP 0)

Hi Richard, On 11/08/16 20:04, Richard Biener wrote: On Thu, Aug 11, 2016 at 6:11 AM, kugan wrote: [SNIP] +two_valued_val_range_p (tree var, tree *a, tree *b) +{ + value_range *vr = get_value_range (var); + if ((vr->type != VR_RANGE + &&

Re: [PATCH] RFC: -fasm-show-source

On 08/11/2016 02:34 PM, David Malcolm wrote: I sometimes find myself scouring assembler output from the compiler and trying to figure out which instructions correspond to which lines of source code; I believe this is a common activity for some end-users. The following patch adds a new

Re: [PATCH] Extend -falign-FOO=N to N[,M]: the second number is max padding

On Thu, Aug 11, 2016 at 5:19 PM, Denys Vlasenko wrote: > > > On 08/11/2016 10:59 PM, Andrew Pinski wrote: >> >> On Thu, Aug 11, 2016 at 1:49 PM, Denys Vlasenko >> wrote: >>> >>> falign-functions=N is too simplistic. >>> >>> Ingo Molnar ran some tests and

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

On Thu, Aug 11, 2016 at 07:15:17PM -0400, Michael Meissner wrote: > This patch was originally part of patch #3, but I separated it out as I rework > what used to be part of patch #3 to fix some issues. > > This patch adds support for using the ISA 3.0 MTVSRDD instruction when > initializing

Re: [PATCH] Extend -falign-FOO=N to N[,M]: the second number is max padding

On 08/11/2016 10:59 PM, Andrew Pinski wrote: On Thu, Aug 11, 2016 at 1:49 PM, Denys Vlasenko wrote: falign-functions=N is too simplistic. Ingo Molnar ran some tests and it looks on latest x86 CPUs, 64-byte alignment runs fastest (he tried many other possibilites).

Re: [PATCH] - improve sprintf buffer overflow detection (middle-end/49905)

On 07/22/2016 04:12 PM, Jeff Law wrote: Working through the new pass... Overall it looks pretty good. There's a certain level of trust I'll extend WRT getting the low level details right -- a thorough testsuite obviously helps there. In the latest patch where I add the return value

[PATCH] Indicate minimum in-tree MPFR version handled

Hi, Commit 235763 removed support for versions of MPFR below 3.1.0 which have a flat directory structure, however it did not introduce any safety check for such an unhandled library version present in the tree. Consequently the system-installed version is silently chosen, which if too old,

[PATCH], Patch #4, Improve vector int/long initialization on PowerPC

This patch was originally part of patch #3, but I separated it out as I rework what used to be part of patch #3 to fix some issues. This patch adds support for using the ISA 3.0 MTVSRDD instruction when initializing vector long vectors with variables. I also changed the CPU type of the other use

Re: [PATCH] Update or add fall through comments in switches

On 08/11/2016 07:43 AM, Marek Polacek wrote: This patch either updates fall through comments so that our warning machinery recognizes them, or annotates code with new FALLTHRU comments so that intended fall through cases are marked and the compiler wouldn't warn. I'd like to get this in before

Re: [PATCH, rs6000] Fix vec_construct vectorization cost to be somewhat more accurate

On Wed, Aug 10, 2016 at 11:52:06AM -0500, Bill Schmidt wrote: > Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no > regressions. Ok for trunk? Okay. Thanks, Segher > 2016-08-10 Bill Schmidt > > * config/rs6000/rs6000.c

[gomp4] Extend libgomp's fortran test coverage of host_data

This patch ports libgomp.oacc-c-c++-common/host_data-1.c to fortran. Fortunately, the existing fortran host_data infrastructure was already in place, so I had to do was port over the calls to Nvidia's CUDA BLAS library. There are a couple of details that one needs to consider when using CUDA BLAS

Re: [PATCH] Add test coverage for PR gcov-profile/35590

On 08/10/2016 06:50 AM, Martin Liška wrote: Hi. Following patch makes better test-coverage for cases mentioned in the PR. The PR is resolved, I'll close it as soon as the patch is accepted. Survives make check -k -j10 RUNTESTFLAGS="tree-prof.exp" on x86_64-linux-gnu. Ready for trunk? OK.

Re: Init df for split pass since some target use REG_NOTE in split pattern

On 08/09/2016 08:44 PM, Kito Cheng wrote: Hi Steven: You are right, I have build arm toolchain today, it's crash when building libgcc since there is no valid CFG in split_all_insns_noflow. Hi Jeff: Maybe we need split_reg_dead_p and split_reg_unused_p like peephole2 have peep2_reg_dead_p?

Re: [PATCH] Add selftests to selftest.c

On 08/09/2016 07:25 PM, David Malcolm wrote: This patch adds some initial selftesting of selftest.c/h itself. This may seem like overdoing it, but I have some followup patches that add non-trivial logic to selftest.c, which we should verify, so it makes sense to test the existing functionality

Re: [PATCH] Fix warning breaking profiled bootstrap

On 08/08/2016 08:43 PM, Andi Kleen wrote: Ideally we'd have a test that we could more deeply analyze for paths through the CFG that can't be executed. Finding those paths usually both fixes the warning *and* results in better code. Even if we can't fix it now, we can file it away for future

[PATCH, preapproved] Disable DF_VERIFY_SCHEDULED at end of df_verify (PR72855)

Hi, PR72855 reports a compile-time problem with df_verify being called once per loop. The compile time drops from about 2 hours to 9 minutes for the reported test case when we disable the DF_VERIFY_SCHEDULED flag after df_verify runs. That's all this patch does. Bin Cheng has a separate patch

Re: divmod transform: add test-cases

On 08/09/2016 04:58 AM, Prathamesh Kulkarni wrote: ping https://gcc.gnu.org/ml/gcc-patches/2016-07/msg01869.html This seems to be dependent upon other patches, this is not OK until all prereqs are resolved. You're using SI/DI in the descriptions, but then using more traditional C types like

Re: [PATCH] - improve sprintf buffer overflow detection (middle-end/49905)

On 07/29/2016 04:50 PM, Joseph Myers wrote: On Mon, 18 Jul 2016, Martin Sebor wrote: + /* Number of exponent digits or -1 when unknown. */ + int expdigs = -1; + /* 1 when ARG < 0, 0 when ARG >= 0, -1 when unknown. */ + int negative = -1; + /* Log10 of EXPDIGS. */ + int logexpdigs = 2;

Re: libgo patch committed: Change build procedure to use build tags

On Thu, Aug 11, 2016 at 8:15 AM, Rainer Orth wrote: > >> 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

Re: [PATCH, c++ testsuite]: Fix UNRESOLVED: g++.dg/cpp1z/constexpr-lambda6.C testsuite failure

On Thu, Aug 11, 2016 at 11:25 PM, Jason Merrill wrote: > There's no need to rename main, but removing the dg-do is OK. Thanks, I have committed only the removal of dg-do directive. Uros. Index: g++.dg/cpp1z/constexpr-lambda6.C

Re: [PATCH, c++ testsuite]: Fix UNRESOLVED: g++.dg/cpp1z/constexpr-lambda6.C testsuite failure

There's no need to rename main, but removing the dg-do is OK. On Thu, Aug 11, 2016 at 3:03 PM, Uros Bizjak wrote: > The compilation, where error is expected, will not produce an executable. > > 2016-08-11 Uros Bizjak > > *

Re: [PATCH] Extend -falign-FOO=N to N[,M]: the second number is max padding

On 08/11/2016 10:49 PM, Denys Vlasenko wrote: falign-functions=N is too simplistic. This change makes it possible to align function to 64-byte boundaries *IF* this does not introduce huge amount of padding. This is my first submission to gcc-patches@gcc.gnu.org Please let me know if my patch

[PATCH] Extend -falign-FOO=N to N[,M]: the second number is max padding

falign-functions=N is too simplistic. Ingo Molnar ran some tests and it looks on latest x86 CPUs, 64-byte alignment runs fastest (he tried many other possibilites). However, developers are less than thrilled by the idea of a slam-dunk 64-byte aligning everything. Too much waste: On

[PATCH] PR middle-end/74113: Don't limit piecewise move to MAX_FIXED_MODE_SIZE

alignment_for_piecewise_move is called only with MOVE_MAX_PIECES or STORE_MAX_PIECES, which are the number of bytes at a time that we can move or store efficiently. We should call mode_for_size without limit to MAX_FIXED_MODE_SIZE, which is an integer expression for the size in bits of the

[PATCH] RFC: -fasm-show-source

I sometimes find myself scouring assembler output from the compiler and trying to figure out which instructions correspond to which lines of source code; I believe this is a common activity for some end-users. The following patch adds a new -fasm-show-source option, which emits comments into the

[PATCH] Increase alignment for bit-field access when predictive commoning (PR 71083)

On 08/11/16 09:07, Richard Biener wrote: > The patch looks mostly ok, but > > + else > + { > + boff >>= LOG2_BITS_PER_UNIT; > + boff += tree_to_uhwi (component_ref_field_offset (ref)); > + coff = size_binop (MINUS_EXPR, coff, ssize_int (boff)); > > how can we be

[PATCH, libstdc++v3]: Fallback to read/write ops in case sendfile fails with ENOSYS or EINVAL.

Hello! Attached patch implements note from sendfile manpage: Applications may wish to fall back to read(2)/write(2) in the case where sendfile() fails with EINVAL or ENOSYS. Also, the patch fixes a small inconsistency in how _GLIBCXX_USE_FCHMODAT config flag is handled in do_copy_file

Re: [PATCH, rs6000] Fix PR72863 (swap optimization misses swaps generated from intrinsics)

On Thu, Aug 11, 2016 at 2:39 PM, Bill Schmidt wrote: > Hi, > > Anton reports in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72863 that use > of > vec_vsx_ld and vec_vsx_st intrinsics leaves the endian swaps in the generated > code, even for very simple computations.

[PATCH, c++ testsuite]: Fix UNRESOLVED: g++.dg/cpp1z/constexpr-lambda6.C testsuite failure

The compilation, where error is expected, will not produce an executable. 2016-08-11 Uros Bizjak * g++.dg/cpp1z/constexpr-lambda6.C (dg-do run): Remove. (g): Rename from main. Tested on x86_64-linux-gnu. OK for mainline? Uros. Index:

Re: [PATCH] Improve backwards threading

On 08/09/2016 07:13 AM, Richard Biener wrote: On Fri, 5 Aug 2016, Jeff Law wrote: 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

Re: Early jump threading

On 08/11/2016 09:50 AM, Richard Biener wrote: Ah, I thought it was exclusively dealing with threading through back edges which is sth I'd avoid doing early? No, that's one of the fundamental changes we made for gcc-6, namely using the FSM threader for general purpose threading rather than

Re: Early jump threading

On 08/11/2016 08:27 AM, Jan Hubicka wrote: On tramp3d all VRP passes threads together 730 branches, all DOM passes 393, so FSM threading (with 1957 branches) is the most effective one. Perhaps eventually early VRP can also do bit of work. That's roughly consistent with what I've seen. I have

[PATCH, rs6000] Fix PR72863 (swap optimization misses swaps generated from intrinsics)

Hi, Anton reports in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72863 that use of vec_vsx_ld and vec_vsx_st intrinsics leaves the endian swaps in the generated code, even for very simple computations. This turns out to be because we don't generate the swaps at expand time as we do with other

Re: Early jump threading

On 08/11/2016 08:06 AM, Richard Biener wrote: On Thu, 11 Aug 2016, Jan Hubicka wrote: Hi, this patch adds early jump threading pass. Jump threading is one of most common cases where estimated profile becomes corrupted, because the branches are predicted independently beforehand. This patch

Re: Early jump threading

On 08/11/2016 08:02 AM, Jan Hubicka wrote: Hi, this patch adds early jump threading pass. Jump threading is one of most common cases where estimated profile becomes corrupted, because the branches are predicted independently beforehand. This patch simply adds early mode to jump threader that

Re: [v3 PATCH] Implement C++17 make_from_tuple.

On 11 August 2016 at 20:45, Ed Smith-Rowland <3dw...@verizon.net> wrote: > On 08/10/2016 08:04 PM, Ville Voutilainen wrote: > > I was in the middle of doing this, so here's the patch before I commit > the string_view one. > > Tested on Linux-x64. > > 2016-08-11 Ville Voutilainen

Re: protected alloca class for malloc fallback

On Thu, Aug 11, 2016 at 09:18:34PM +0900, Oleg Endo wrote: > On Wed, 2016-08-10 at 21:31 -0400, Trevor Saunders wrote: > > > > > Well, I'd say the compromises made in std::string make it pretty > > terrible for general purpose use accept where perf and memory doesn't > > matter at all. > > > >

Re: [PATCH] Support TImode CONST_WIDE_INT store in 64-bit STV

On Thu, Aug 11, 2016 at 6:54 PM, H.J. Lu wrote: > Support TImode CONST_WIDE_INT store generated from piecewise store. > Need to verify performance impact before enabling TImode CONST_INT > store for __int128. > > Tested on x86-64. OK for trunk? OK. Thanks, Uros. > H.J. >

[PATCH] Support TImode CONST_WIDE_INT store in 64-bit STV

Support TImode CONST_WIDE_INT store generated from piecewise store. Need to verify performance impact before enabling TImode CONST_INT store for __int128. Tested on x86-64. OK for trunk? H.J. --- gcc/ * config/i386/i386.c (timode_scalar_to_vector_candidate_p): Allow TImode

Re: [WIP] [PR fortran/72741] Rework Fortran OpenACC routine clause handling

On 08/11/2016 08:18 AM, Thomas Schwinge wrote: >> --- a/gcc/fortran/module.c >> +++ b/gcc/fortran/module.c > >> [...] >> +DECL_MIO_NAME (oacc_function) >> [...] > > As discussed between Cesar and Tobias, these module.c/symbol.c changes > introduce an incompatibility in the Fortran module file

Re: [WIP] [PR fortran/72741] Rework Fortran OpenACC routine clause handling (was: [PATCH] OpenACC routines in fortran modules)

On Thu, Aug 11, 2016 at 06:26:50PM +0200, Thomas Schwinge wrote: > > > --- gcc/fortran/gfortran.h > > > +++ gcc/fortran/gfortran.h > > > > /* Symbol attribute structure. */ > > > -typedef struct > > > +typedef struct symbol_attribute > > > { > > > While symbol_attribute is already bloated, I

[PATCH PR72817/PR73450]Fix wrong code caused by niter analyzer for NE_EXPR exit cond.

Hi, I made a mistake when improving loop niter analysis for NE_EXPR exit condition. It can results in wrong code as reported in PR72817/PR73450. In previous patch, it simplifies below condition: base <= FINAL ; step > 0 base >= FINAL ; step < 0 into: base -

Re: [WIP] [PR fortran/72741] Rework Fortran OpenACC routine clause handling (was: [PATCH] OpenACC routines in fortran modules)

Hi! As Cesar asked for it, there is now a Git branch tschwinge/omp/pr72741-wip containing these changes (plus some other pending changes that I didn't single out at this time), at . (I expect it does, but I

Re: [PATCH] Use TImode for piecewise move in 64-bit mode

On Thu, Aug 11, 2016 at 6:12 PM, Uros Bizjak wrote: > On Thu, Aug 11, 2016 at 5:51 PM, H.J. Lu wrote: > > Use TImode for piecewise move in 64-bit mode. When vector register > is used for piecewise move, we don't increase

Re: [PATCH] Use TImode for piecewise move in 64-bit mode

On Thu, Aug 11, 2016 at 5:51 PM, H.J. Lu wrote: Use TImode for piecewise move in 64-bit mode. When vector register is used for piecewise move, we don't increase stack_alignment_needed since vector register spill isn't required for piecewise move.

Re: [PATCH] Use TImode for piecewise move in 64-bit mode

On Thu, Aug 11, 2016 at 8:41 AM, Uros Bizjak wrote: > On Thu, Aug 11, 2016 at 5:26 PM, H.J. Lu wrote: >> On Thu, Aug 11, 2016 at 1:16 AM, Uros Bizjak wrote: >>> On Wed, Aug 10, 2016 at 6:44 PM, H.J. Lu wrote: >>>

Re: Early jump threading

On August 11, 2016 4:27:00 PM GMT+02:00, Jan Hubicka wrote: >> On Thu, 11 Aug 2016, Jan Hubicka wrote: >> >> > Hi, >> > this patch adds early jump threading pass. Jump threading is one >of most >> > common cases where estimated profile becomes corrupted, because the >branches >>

Re: [C++ PATCH] Handle CASE_HIGH in constexpr evaluation (PR c++/72868)

OK for trunk and 6. On Thu, Aug 11, 2016 at 10:55 AM, Jakub Jelinek wrote: > Hi! > > As mentioned in the PR, constexpr.c has been handling cases with ranges > just as the lowest value of the range. > > Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for

C++ PATCH for c++/73456 (concepts ICE with constrained parameter pack)

In trying to decide if the constraints on the partial specialization subsume those on the primary template, we consider whether any of the constraints on the primary template imply the type constraint typename list. We don't have any matching constraints on the primary template, so we look to see

Re: [PATCH] Use TImode for piecewise move in 64-bit mode

On Thu, Aug 11, 2016 at 5:26 PM, H.J. Lu wrote: > On Thu, Aug 11, 2016 at 1:16 AM, Uros Bizjak wrote: >> On Wed, Aug 10, 2016 at 6:44 PM, H.J. Lu wrote: >> >> Use TImode for piecewise move in 64-bit mode. When vector register

Re: [WIP] [PR fortran/72741] Rework Fortran OpenACC routine clause handling (was: [PATCH] OpenACC routines in fortran modules)

On Thu, Aug 11, 2016 at 05:18:43PM +0200, Thomas Schwinge wrote: > --- gcc/fortran/gfortran.h > +++ gcc/fortran/gfortran.h > @@ -729,7 +839,7 @@ ext_attr_t; > extern const ext_attr_t ext_attr_list[]; > > /* Symbol attribute structure. */ > -typedef struct > +typedef struct symbol_attribute >

Re: [Patch, libfortran] Multi-threaded random_number

On Thu, Aug 11, 2016 at 5:54 PM, Rainer Orth wrote: > Hi Janne, > >> committed a slightly modified patch as r239356. Changes from the >> submitted patch attached. To my surprise, it turned out that my >> fallback code using __gthread_key_{create,delete} and >>

Re: [PATCH] Use TImode for piecewise move in 64-bit mode

On Thu, Aug 11, 2016 at 1:16 AM, Uros Bizjak wrote: > On Wed, Aug 10, 2016 at 6:44 PM, H.J. Lu wrote: > > Use TImode for piecewise move in 64-bit mode. When vector register > is used for piecewise move, we don't increase stack_alignment_needed

Re: libgo patch committed: Change build procedure to use build tags

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

[WIP] [PR fortran/72741] Rework Fortran OpenACC routine clause handling (was: [PATCH] OpenACC routines in fortran modules)

Hi! This is still hacky and WIP; posting for Cesar and Tobias to have a look. I'm still not too much of a Fortran person. ;-) On Fri, 1 Jul 2016 13:40:58 -0700, Cesar Philippidis wrote: > It turns out that the acc routine parallelism isn't being recorded in > fortran

Re: fix crash on 64-bit mingw-w64 hosted compiler using more than 4 gb of ram

On Thu, Aug 11, 2016 at 04:55:34PM +0200, Stanislaw Halik wrote: > On 2016-08-11 Thu 16:33, Kai Tietz wrote: > >Hello Stanislaw. > > > >patch is ok. Nevertheless there is a ChangeLog entry missing for it. > >It is mandatory to be provided for submissions to gcc. > > ChangeLog: > > PR

Re: fix crash on 64-bit mingw-w64 hosted compiler using more than 4 gb of ram

On Thu, Aug 11, 2016 at 11:31:49AM +0200, Stanislaw Halik wrote: > The host configuration across platforms wrongly assumes that > sizeof(long) == sizeof(intptr_t) which is incorrect on amd64-hosted compiler > hosting mingw-w64. > > Here's a patch fixing >

Re: fix crash on 64-bit mingw-w64 hosted compiler using more than 4 gb of ram

On 2016-08-11 Thu 16:33, Kai Tietz wrote: Hello Stanislaw. patch is ok. Nevertheless there is a ChangeLog entry missing for it. It is mandatory to be provided for submissions to gcc. ChangeLog: PR target/66488 * gcc/config/i386/xm-mingw32.h (HOST_BITS_PER_PTR): specify pointer size as

[C++ PATCH] Handle CASE_HIGH in constexpr evaluation (PR c++/72868)

Hi! As mentioned in the PR, constexpr.c has been handling cases with ranges just as the lowest value of the range. Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? What about 6.2 (not a regression, but low risk fix for wrong-code)? 2016-08-11 Jakub Jelinek

Re: [Patch, libfortran] Multi-threaded random_number

Hi Janne, > committed a slightly modified patch as r239356. Changes from the > submitted patch attached. To my surprise, it turned out that my > fallback code using __gthread_key_{create,delete} and > __ghtread_{get,set}_specific was faster than my TLS code, so I removed > the TLS configure magic

RFC: A few more fallthrus

A few more cases where I'm unsure whether the fall through is intended. Jason, can you please look at the cp/ part? Richi, would you mind looking at the tree-complex.c bit? What 'bout the pch.c? Thanks, 2016-08-11 Marek Polacek PR c/7652 gcc/ *

Re: fix crash on 64-bit mingw-w64 hosted compiler using more than 4 gb of ram

Hello Stanislaw. patch is ok. Nevertheless there is a ChangeLog entry missing for it. It is mandatory to be provided for submissions to gcc. Thanks, Kai 2016-08-11 11:31 GMT+02:00 Stanislaw Halik : > The host configuration across platforms wrongly assumes that > sizeof(long)

Re: [PATCHv2, PING 2][ARM] -mpure-code option for ARM

On 25/07/16 11:52, Andre Vieira (lists) wrote: > On 11/07/16 17:56, Andre Vieira (lists) wrote: >> On 07/07/16 13:30, mickael guene wrote: >>> Hi Andre, >>> >>> Another feedback on your purecode patch. >>> You have to disable casesi pattern since then it will >>> generate wrong code with

Re: Early jump threading

> On Thu, 11 Aug 2016, Jan Hubicka wrote: > > > Hi, > > this patch adds early jump threading pass. Jump threading is one of most > > common cases where estimated profile becomes corrupted, because the branches > > are predicted independently beforehand. This patch simply adds early mode to > >

Re: [v3 PATCH] Implement C++17 make_from_tuple.

Hi, On 11/08/2016 02:04, Ville Voutilainen wrote: I was in the middle of doing this, so here's the patch before I commit the string_view one. Thanks. This one also looks straightforward enough to me. I'm still working on your largish contributions... Thanks again, Paolo.

Re: [PATCH] Fix early debug regression with DW_AT_string_length (PR debug/71906)

On Thu, Aug 11, 2016 at 2:36 PM, Jakub Jelinek wrote: > Hi! > > On Wed, Aug 10, 2016 at 12:23:06PM +0200, Richard Biener wrote: >> > Introducing another attribute that does the same thing as existing >> > attribute >> > would be way too ugly. In theory the reference class

Re: Early jump threading

On Thu, 11 Aug 2016, Jan Hubicka wrote: > Hi, > this patch adds early jump threading pass. Jump threading is one of most > common cases where estimated profile becomes corrupted, because the branches > are predicted independently beforehand. This patch simply adds early mode to > jump threader

[PATCH] Improve VRP PHI handling

The patch for PR72851 exposes an issue with PHI handling in VRP that is easily fixed if we allow iterating again if we are sure this is the last iteration with the set of fixed executable edges. It also makes sure we always print the lattice change, even if it is to VARYING. Bootstrap / regtest

Early jump threading

Hi, this patch adds early jump threading pass. Jump threading is one of most common cases where estimated profile becomes corrupted, because the branches are predicted independently beforehand. This patch simply adds early mode to jump threader that does not permit code growth and thus only

[PATCH] Update or add fall through comments in switches

This patch either updates fall through comments so that our warning machinery recognizes them, or annotates code with new FALLTHRU comments so that intended fall through cases are marked and the compiler wouldn't warn. I'd like to get this in before I post another patches to keep this mess more

Re: [RFC] ipa bitwise constant propagation

> @@ -266,6 +267,38 @@ private: >bool meet_with_1 (unsigned new_align, unsigned new_misalign); > }; > > +/* Lattice of known bits, only capable of holding one value. > + Similar to ccp_lattice_t, mask represents which bits of value are > constant. > + If a bit in mask is set to 0, then

Re: [PATCH] Fix early debug regression with DW_AT_string_length (PR debug/71906)

Hi! On Wed, Aug 10, 2016 at 12:23:06PM +0200, Richard Biener wrote: > > Introducing another attribute that does the same thing as existing attribute > > would be way too ugly. In theory the reference class could be added to > > DW_AT_string_length, I can ask on DWARF workgroup (but it might be

Re: backward threading heuristics tweek

> This also caused: > > FAIL: gcc.dg/tree-ssa/pr69270-3.c scan-tree-dump-times uncprop1 ", 1" 4 > > Failures: > gcc.dg/tree-ssa/pr69270-3.c > > Bisected to: > > Author: hubicka > Date: Sun Aug 7 10:50:16 2016 + > > * tree-ssa-threadbackward.c: Include

Re: protected alloca class for malloc fallback

On Wed, 2016-08-10 at 21:31 -0400, Trevor Saunders wrote: > > Well, I'd say the compromises made in std::string make it pretty > terrible for general purpose use accept where perf and memory doesn't > matter at all. > > std::vector isn't very great size wise either, imho the size / > capacity

Re: backward threading heuristics tweek

> On Mon, Jun 6, 2016 at 3: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

Re: [PATCH PR71956] Add missed check on MASK_STORE builtin.

On Thu, Aug 11, 2016 at 02:03:37PM +0300, Yuri Rumyantsev wrote: > Hi All, > > Jakub introduced regression after r235764 and we got RF for > spec2000/176.gcc on HSW if loop vectorization is on (32-bit only). > Here is a simple fix which cures the issue. > > Is it OK for trunk? > ChangeLog: >

[Committed 0/2] Vector builtin improvements

These two patches implement 2 minor improvements to the vector builtins. Committed after successful regression testing with -march=z13. The patches will be applied to GCC 6 branch as well. Andreas Krebbel (2): S/390: Fix vlvg vlgv low-level builtins. S/390: Provide low-level builtins with

[PATCH 2/2] S/390: Provide low-level builtins with __int128 ops.

gcc/ChangeLog: 2016-08-11 Andreas Krebbel * config/s390/s390-builtin-types.def: Add INT128 types. * config/s390/s390-builtins.def: Add INT128 variants for the add sub low-level builtins dealing with TImode. * config/s390/s390.c

[PATCH 1/2] S/390: Fix vlvg vlgv low-level builtins.

gcc/ChangeLog: 2016-08-11 Andreas Krebbel * config/s390/s390-builtins.def: Mark last operand of s390_vlvg* and s390_vlgv* builtins as element selector. --- gcc/config/s390/s390-builtins.def | 20 ++-- 1 file changed, 10

Re: [PATCH testsuite]Require vect_cond_mixed for test case gcc.dg/vect/pr56541.c

On Thu, Aug 11, 2016 at 11:38 AM, Richard Biener wrote: > On Thu, Aug 11, 2016 at 11:56 AM, Bin.Cheng wrote: >> On Thu, Aug 11, 2016 at 10:50 AM, Richard Biener >> wrote: >>> On Wed, Aug 10, 2016 at 5:58 PM, Bin

[PATCH PR71956] Add missed check on MASK_STORE builtin.

Hi All, Jakub introduced regression after r235764 and we got RF for spec2000/176.gcc on HSW if loop vectorization is on (32-bit only). Here is a simple fix which cures the issue. Is it OK for trunk? ChangeLog: 2016-08-11 Yuri Rumyantsev PR rtl-optimization/71956 *

Re: fold strlen (s) eq/ne 0 to *s eq/ne 0 on GIMPLE

On Thu, Aug 11, 2016 at 04:06:10PM +0530, Prathamesh Kulkarni wrote: > +static void > +replace_call_by_cmp (gimple_stmt_iterator *gsi, location_t loc, > + tree type, tree arg1, tree arg2, > + tree res_type, enum tree_code cmp_code) > +{ > + tree ptrtype =

Re: [PATCH testsuite]Require vect_cond_mixed for test case gcc.dg/vect/pr56541.c

On Thu, Aug 11, 2016 at 11:56 AM, Bin.Cheng wrote: > On Thu, Aug 11, 2016 at 10:50 AM, Richard Biener > wrote: >> On Wed, Aug 10, 2016 at 5:58 PM, Bin Cheng wrote: >>> Hi, >>> Due to some reasons, tree-if-conv.c now factors

Re: fold strlen (s) eq/ne 0 to *s eq/ne 0 on GIMPLE

On 1 August 2016 at 17:03, Richard Biener wrote: > On Mon, 1 Aug 2016, Prathamesh Kulkarni wrote: > >> Hi Richard, >> The attached patch tries to fold strlen (s) eq/ne 0 to *s eq/ne 0 on GIMPLE. >> I am not sure where was the ideal place to put this transform in and ended up >>

Re: Fwd: [PATCH, doc/ARM] Remove false affirmation that Thumb cannot use an FPU

Hi Sandra, Thanks for your feedback. Please find an updated version attached to this email. ChangeLog entry is unchanged: *** gcc/ChangeLog *** 2016-08-02 Thomas Preud'homme * doc/fragments.texi (MULTILIB_EXCEPTIONS): Replace example with

Re: [PATCH] Fix unaligned access when predictive commoning (PR 71083)

On Thu, 11 Aug 2016, Bernd Edlinger wrote: > On 08/11/16, Richard Biener wrote: > > > > The patch looks mostly ok, but > > > > + else > > + { > > + boff >>= LOG2_BITS_PER_UNIT; > > + boff += tree_to_uhwi (component_ref_field_offset (ref)); > > + coff =

Re: [Patch, tentative, reload] Make push_reload work with more types of subregs?

> Committed patch to trunk. Ok for backport to 6.x and 5.x branches as > well? No, we really avoid touching reload on release branches, unless there is a very good reason to do it, like a regression on a primary platform. -- Eric Botcazou

[PATCH AArch64]Delete useless var declaration as obvious

Hi, The useless var declaration was introduced when I separating patches, and it breaks bootstrap on AArch64. This patch fixes it as obvious. Bootstrap checked. Will apply as obvious. Thanks, bin 2016-08-11 Bin Cheng * config/aarch64/aarch64-simd.md (vcond):

Re: [PATCH] Fix unaligned access when predictive commoning (PR 71083)

On 08/11/16, Richard Biener wrote: > > The patch looks mostly ok, but > > + else > + { > + boff >>= LOG2_BITS_PER_UNIT; > + boff += tree_to_uhwi (component_ref_field_offset (ref)); > + coff = size_binop (MINUS_EXPR, coff, ssize_int (boff)); > > how can we be

Re: [RFC][PR61839]Convert CST BINOP COND_EXPR to COND_EXPR ? (CST BINOP 1) : (CST BINOP 0)

On Thu, Aug 11, 2016 at 6:11 AM, kugan wrote: > Hi Richard, > > > On 09/08/16 20:22, Richard Biener wrote: >> >> On Tue, Aug 9, 2016 at 4:51 AM, Kugan Vivekanandarajah >> wrote: >>> >>> Hi Richard, >>> >>> Thanks for the

[PATCH AArch64]Fix spurious warning with explicit initialization

Hi, GCC gives spurious -Wmaybe-uninitialized message which breaks bootstrap. This patch fixes it by explicitly initializing. Also I file PR72355 in order to tracking the wrong warning message. Compilation log checked. Applied as obvious. Thanks, bin 2016-08-11 Bin Cheng

Re: [PATCH testsuite]Require vect_cond_mixed for test case gcc.dg/vect/pr56541.c

On Thu, Aug 11, 2016 at 10:50 AM, Richard Biener wrote: > On Wed, Aug 10, 2016 at 5:58 PM, Bin Cheng wrote: >> Hi, >> Due to some reasons, tree-if-conv.c now factors floating point comparison >> out of cond_expr, >> resulting in mixed types in it.

Re: [PATCH PR69848]Introduce special conditional reduction CONST_COND_REDUCTION

On Wed, Aug 10, 2016 at 6:01 PM, Bin Cheng wrote: > Hi, > This patch fixes the inefficient code generated by vectorizer as reported by > PR69848. > It introduces new conditional reduction type CONST_COND_REDUCTION. As a > result, > we don't need to compute index vector in

Re: [PATCH testsuite]Require vect_cond_mixed for test case gcc.dg/vect/pr56541.c

On Wed, Aug 10, 2016 at 5:58 PM, Bin Cheng wrote: > Hi, > Due to some reasons, tree-if-conv.c now factors floating point comparison out > of cond_expr, > resulting in mixed types in it. This does help CSE on common comparison > operations. > Only problem is that test

fix crash on 64-bit mingw-w64 hosted compiler using more than 4 gb of ram

The host configuration across platforms wrongly assumes that sizeof(long) == sizeof(intptr_t) which is incorrect on amd64-hosted compiler hosting mingw-w64. Here's a patch fixing cheers, sh diff --git a/gcc/config/i386/xm-mingw32.h

Re: [Patch, libfortran] Multi-threaded random_number

Hi, committed a slightly modified patch as r239356. Changes from the submitted patch attached. To my surprise, it turned out that my fallback code using __gthread_key_{create,delete} and __ghtread_{get,set}_specific was faster than my TLS code, so I removed the TLS configure magic and the TLS

Re: [PATCH][RFC] Fix PR72851 by "randomizing" SSA propagator worklist extraction

On Wed, 10 Aug 2016, Richard Biener wrote: > > The following randomizes SSA propagator worklist processing to make the > processing order less likely hit the worst-case as in the PR. Ideally > we'd process it in stmt order but that adds overhead to the idea of a > SSA propagator that makes it

  1   2   >