Re: PR78501

On Thu, 24 Nov 2016, Prathamesh Kulkarni wrote: > Hi, > The attached patch fixes ada bootstrap failure. > Bootstrap+tested on x86_64-unknown-linux-gnu with --enable-languages=all,ada > Cross-tested on aarch64*-*-*, arm*-*-* with --enable-languages=c,c++,fortran. > OK to commit ? Ok. Richard.

change initialization of ptrdiff_type_node

Hi, This patch changes initialization of ptrdiff_type_node in lto-lang.c, based on Jakub's suggestion in PR78501 comment 12: "The other uses of ptrdiff_type_node in the middle-end, which need fixing anyway, would need something like your patch, but not sure if it is not a waste of time to compute

Re: [Patch i386] PR78509 - TARGET_C_EXCESS_PRECISION should not return "unpredictable" for EXCESS_PRECISION_TYPE_STANDARD

On Fri, Nov 25, 2016 at 08:26:53AM +0100, Uros Bizjak wrote: > > 2016-11-24 James Greenahlgh > > > > PR target/78509 > > * config/i386/i386.c (i386_excess_precision): Do not return > > FLT_EVAL_METHOD_UNPREDICTABLE when "type" is > >

Re: [Patch i386] PR78509 - TARGET_C_EXCESS_PRECISION should not return "unpredictable" for EXCESS_PRECISION_TYPE_STANDARD

On Thu, Nov 24, 2016 at 5:00 PM, James Greenhalgh wrote: > > Hi, > > PR78509 occurs because a target should never return > FLT_EVAL_METHOD_UNPREDICTABLE from TARGET_C_EXCESS_PRECISION when the > TYPE argument to that hook is EXCESS_PRECISION_TYPE_STANDARD or >

Re: [PATCH] Tree-level fix for PR 69526

Ping.

Re: [tree-tailcall] Check if function returns it's argument

On 24 November 2016 at 18:08, Richard Biener wrote: > On Thu, 24 Nov 2016, Prathamesh Kulkarni wrote: > >> On 24 November 2016 at 17:48, Richard Biener wrote: >> > On Thu, 24 Nov 2016, Prathamesh Kulkarni wrote: >> > >> >> On 24 November 2016 at 14:07,

Re: [0/3] Fix PR78120, in ifcvt/rtlanal/i386.

On Thu, Nov 24, 2016 at 10:14:24AM -0600, Segher Boessenkool wrote: > On Thu, Nov 24, 2016 at 08:48:04AM -0700, Jeff Law wrote: > > On 11/24/2016 07:53 AM, Segher Boessenkool wrote: > > > > > >That we compare different kinds of costs (which really has no meaning at > > >all, it's a heuristic at

Re: New option -flimit-function-alignment

Hi Jeff, >> gcc/ >> * common.opt (flimit-function-alignment): New. >> * doc/invoke.texi (-flimit-function-alignment): Document. >> * emit-rtl.h (struct rtl_data): Add max_insn_address field. >> * final.c (shorten_branches): Set it. >> * varasm.c (assemble_start_function):

[PATCH] arc: Avoid store/load pipeline hazard

The patch below was primarily written (over several patches) by Claudiu (CC'd) as part of an out-of-tree ARC GCC port. I've pulled the work together into a single patch, and added a test. Claudiu is happy for this to be posted upstream. --- ARC700 targets have a store/load pipeline hazard, if

[PATCH, i386]: Use explicit mode macros on wide-insn splitters

2016-11-24 Uros Bizjak * config/i386/i386.md (wide AND insn to QImode splitter): Use explicit mode macros. (wide OR insn to QImode splitter): Ditto. Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}. Committed to mainline SVN. Uros. Index: i386.md

[C++ PATCH] Fix -Wreturn-local-addr regression (PR c++/77591)

Hi! Delayed folding caused following regression where we no longer warn about returning reference to local variable. Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2016-11-24 Jakub Jelinek PR c++/77591 * typeck.c

Re: Ping: Re: [PATCH 1/2] gcc: Remove unneeded global flag.

* Christophe Lyon [2016-11-21 13:47:09 +0100]: > On 20 November 2016 at 18:27, Mike Stump wrote: > > On Nov 19, 2016, at 1:59 PM, Andrew Burgess > > wrote: > >>> So, your new test fails on arm* targets: > >> > >>

Patch to fix PR77541

The patch in the attachment fixes https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77541 The patch was successfully tested and bootstrapped on x86-64. Committed as rev. 242848 Index: ChangeLog === --- ChangeLog (revision 242713) +++

Re: [PATCH][GCC][PATCHv3] Improve fpclassify w.r.t IEEE like numbers in GIMPLE.

On Thu, 24 Nov 2016, Tamar Christina wrote: > @@ -11499,6 +11503,53 @@ to classify. GCC treats the last argument as > type-generic, which > means it does not do default promotion from float to double. > @end deftypefn > > +@deftypefn {Built-in Function} int __builtin_isnan (...) > +This

Re: [PATCH] PR fortran/78500 -- Yet another NULL pointer dereference

Hi Steve, >> Just my usual request for a meaningful test-case name: This one could >> be class_result_4.f90. (I don't want to be pedantic about this, but in >> a growing testsuite of 4000+ files, I really think it makes sense to >> have meaningful names. It does have various advantages and, to be

[Patch, fortran] PR78293 - - [5/6/7 Regression] SIGABRT with function result used as argument

Dear All, Andre put me to shame with a devastatingly simple replacement for a horribly complicated and wrong patch that I was getting into. The part of the patch in trans-expr.c fixes the PR and the part in trans-stmt.c fixes a memory leak in function 'tt'. This latter fixes half of the memory

Re: [Patch, tentative] Use MOVE_MAX_PIECES instead of MOVE_MAX in gimple_fold_builtin_memory_op

Richard Biener writes: > On Thu, 24 Nov 2016, Richard Biener wrote: > >> On Thu, 24 Nov 2016, Senthil Kumar Selvaraj wrote: >> >> > Hi, >> > >> > I've been analyzing a failing regtest (gcc.dg/strlenopt-8.c) for the avr >> > target. I found that the (dump) failure is because there are 4 >>

PR78501

Hi, The attached patch fixes ada bootstrap failure. Bootstrap+tested on x86_64-unknown-linux-gnu with --enable-languages=all,ada Cross-tested on aarch64*-*-*, arm*-*-* with --enable-languages=c,c++,fortran. OK to commit ? Thanks, Prathamesh 2016-11-24 Jakub Jelinek

Re: [PATCH] PR fortran/78500 -- Yet another NULL pointer dereference

On Thu, Nov 24, 2016 at 11:56:02AM +0100, Janus Weil wrote: > Hi Steve, > > > Regression tested on x86_64-*-freebsd. OK to commit? > > the patch is certainly ok. > > Just my usual request for a meaningful test-case name: This one could > be class_result_4.f90. (I don't want to be pedantic

Re: [GCC][AArch64][PATCH][Testsuite] Fix failing test vector_initialization_nostack.c

Ping. From: gcc-patches-ow...@gcc.gnu.org on behalf of Tamar Christina Sent: Monday, November 7, 2016 2:05:27 PM To: GCC Patches; James Greenhalgh; Richard Earnshaw; Marcus Shawcroft Cc: nd

[PR 70965] Schedule extra pass_rebuild_cgraph_edges

Hi, after discussing this with Honza, we have decided that scheduling an extra pass_rebuild_cgraph_edges after pass_fixup_cfg is the correct way to keep the cgraph consistent with gimple IL when early IPA passes need it, such as is the case with the testcase in PR 70965. While needing an extra

Re: [0/3] Fix PR78120, in ifcvt/rtlanal/i386.

On Thu, Nov 24, 2016 at 08:48:04AM -0700, Jeff Law wrote: > On 11/24/2016 07:53 AM, Segher Boessenkool wrote: > > > >That we compare different kinds of costs (which really has no meaning at > >all, it's a heuristic at best) in various places is a known problem, not > >a regression. > But the

Re: [SPARC] Enable REE at -O2 by default in 64-bit mode

> With the fixes you've just done it's probably a lot more feasible to > experiment with REE on other risc targets. I didn't experiment much, but I saw no effects at all in 32-bit mode, only in 64-bit mode. That being said, SPARC is one of the very few RISC targets that do _not_ define

[Patch i386] PR78509 - TARGET_C_EXCESS_PRECISION should not return "unpredictable" for EXCESS_PRECISION_TYPE_STANDARD

Hi, PR78509 occurs because a target should never return FLT_EVAL_METHOD_UNPREDICTABLE from TARGET_C_EXCESS_PRECISION when the TYPE argument to that hook is EXCESS_PRECISION_TYPE_STANDARD or EXCESS_PRECISION_TYPE_FAST. When TYPE is one of these two modes, the target is being asked which explicit

Re: [PATCH][GCC][PATCHv3] Improve fpclassify w.r.t IEEE like numbers in GIMPLE.

Hi All, This is a respin of the v3 of the patch which adds an optimized route to the fpclassify builtin for floating point numbers which are similar to IEEE-754 in format. Compared to the last one this adds the tests requested for the FloatN types, adds documentation, ISFINITE and IBM extended

Re: [0/3] Fix PR78120, in ifcvt/rtlanal/i386.

On 11/24/2016 07:53 AM, Segher Boessenkool wrote: That we compare different kinds of costs (which really has no meaning at all, it's a heuristic at best) in various places is a known problem, not a regression. But the problems with the costing system exhibit themselves as a code quality

Re: [0/3] Fix PR78120, in ifcvt/rtlanal/i386.

On 11/24/2016 08:16 AM, Richard Biener wrote: IMHO switching insn_rtx_cost to be based on not just set_src_cost is a good idea, but will require re-tuning of all targets, so it is not stage 3 material. Agreed. That we compare different kinds of costs (which really has no meaning at all,

Re: [SPARC] Enable REE at -O2 by default in 64-bit mode

On 11/24/2016 08:30 AM, Eric Botcazou wrote: Tests showed that it helps to eliminates redundant 32-to-64-bit extensions. Tested on SPARC/Solaris, applied on the mainline. 2016-11-24 Eric Botcazou * common/config/sparc/sparc-common.c

Re: [0/3] Fix PR78120, in ifcvt/rtlanal/i386.

On 11/24/2016 03:53 PM, Segher Boessenkool wrote: Your own 2/3 shows my point: you needed fixes to the i386 port for it to behave sanely after this 1/3; what makes you think other ports are not in the same boat? When I realized i386 was broken I had a look at aarch64 and it looked sane, and

Re: [PATCH 1/2 v3] PR77822

On 11/24/2016 02:59 AM, Dominik Vogt wrote: On Wed, Nov 23, 2016 at 01:22:31PM -0700, Jeff Law wrote: On 11/21/2016 04:03 AM, Dominik Vogt wrote: On Fri, Nov 18, 2016 at 04:29:18PM +0100, Dominik Vogt wrote: On Fri, Nov 18, 2016 at 08:02:08AM -0600, Segher Boessenkool wrote: On Fri, Nov 18,

Re: [patch, nios2] Fix PR78357, adjust sync builtin initialization

On 11/23/2016 11:57 PM, Sebastian Huber wrote: Hello Jeff, On 23/11/16 23:28, Jeff Law wrote: On 11/16/2016 02:53 AM, Chung-Lin Tang wrote: This patch adjusts the initialization of __sync built-in functions: instead of conditionalizing on TARGET_LINUX_ABI, directly place the target-hook

[SPARC] Enable REE at -O2 by default in 64-bit mode

Tests showed that it helps to eliminates redundant 32-to-64-bit extensions. Tested on SPARC/Solaris, applied on the mainline. 2016-11-24 Eric Botcazou * common/config/sparc/sparc-common.c (option_optimization_table): Enable REE at -O2 and higher.

[PATCH PR78507/PR78510]Fix two ICEs in pattern (cond (cmp (convert1? @1) @3) (convert2? @1) @2).

Hi, This patch fixes two issues in newly introduced pattern: (cond (cmp (convert1? @1) @3) (convert2? @1) @2). For PR78507, we need to check if from_type is INTEGRAL_TYPE_P explicitly, this patch adds check for that. Note we don't check c1_type/c2_type for that because it's guarded by

Re: [patch] DWARF5 .debug_line DW_LNCT_* reorder for readelf [Re: [PATCH] DWARF5 .debug_line{,_str} support]

On Thu, Nov 24, 2016 at 04:07:22PM +0100, Jan Kratochvil wrote: > On Thu, 20 Oct 2016 01:30:39 +0200, Jakub Jelinek wrote: > > This patch adds support for DWARF5 .debug_line{,_str} section format, > > though only if !DWARF2_ASM_LINE_DEBUG_INFO, because otherwise > > .debug_line is emitted by the

Re: [0/3] Fix PR78120, in ifcvt/rtlanal/i386.

On Thu, Nov 24, 2016 at 3:53 PM, Segher Boessenkool wrote: > On Thu, Nov 24, 2016 at 03:38:55PM +0100, Bernd Schmidt wrote: >> On 11/24/2016 03:36 PM, Segher Boessenkool wrote: >> >On Thu, Nov 24, 2016 at 03:26:45PM +0100, Bernd Schmidt wrote: >> >>On 11/24/2016 03:21

Re: [PATCH][TER] PR 48863: Don't replace expressions across local register variable definitions

On Thu, Nov 24, 2016 at 2:57 PM, Kyrill Tkachov wrote: > Hi all, > > In this bug we have TER during out-of-ssa misbehaving. A minimal example is: > void foo(unsigned a, float b) > { > unsigned c = (unsigned) b; // 1 > register unsigned r0 __asm__("r0") = a;

Re: [Patch, tentative] Use MOVE_MAX_PIECES instead of MOVE_MAX in gimple_fold_builtin_memory_op

On Thu, 24 Nov 2016, Richard Biener wrote: > On Thu, 24 Nov 2016, Senthil Kumar Selvaraj wrote: > > > Hi, > > > > I've been analyzing a failing regtest (gcc.dg/strlenopt-8.c) for the avr > > target. I found that the (dump) failure is because there are 4 > > instances of memcpy, while the

[patch] DWARF5 .debug_line DW_LNCT_* reorder for readelf [Re: [PATCH] DWARF5 .debug_line{,_str} support]

Hi, On Thu, 20 Oct 2016 01:30:39 +0200, Jakub Jelinek wrote: > This patch adds support for DWARF5 .debug_line{,_str} section format, > though only if !DWARF2_ASM_LINE_DEBUG_INFO, because otherwise > .debug_line is emitted by the assembler. with current GCC trunk (with the GCC patch above)

Re: [PING][PATCH][2/2] Early LTO debug -- main part

On Thu, 24 Nov 2016, Richard Biener wrote: > On Tue, 22 Nov 2016, Jason Merrill wrote: > > > On 11/11/2016 03:06 AM, Richard Biener wrote: > > > +/* ??? In some cases the C++ FE (at least) fails to > > > + set DECL_CONTEXT properly. Simply globalize stuff > > > + in this case.

Re: [0/3] Fix PR78120, in ifcvt/rtlanal/i386.

On Thu, Nov 24, 2016 at 03:38:55PM +0100, Bernd Schmidt wrote: > On 11/24/2016 03:36 PM, Segher Boessenkool wrote: > >On Thu, Nov 24, 2016 at 03:26:45PM +0100, Bernd Schmidt wrote: > >>On 11/24/2016 03:21 PM, Segher Boessenkool wrote: > >> > >>>Combine uses insn_rtx_cost extensively. I have tried

Re: [PATCH] combine: Convert subreg-of-lshiftrt to zero_extract properly (PR78390)

On Thu, Nov 24, 2016 at 03:01:02PM +0100, Michael Matz wrote: > Hi, > > On Thu, 24 Nov 2016, Dominik Vogt wrote: > > > On s390 (31-Bit) we get two (easily fixable) test regression > > supposedly because of the original path (+ this fix), and I don't > > know what to do about it. Perhaps these

Re: [0/3] Fix PR78120, in ifcvt/rtlanal/i386.

> I'll make the argument that stage 3 is when we fix stuff, including > performance regressions, and this patch is very clearly a fix. When we > have very obvious distortions like a case where costs from insn_rtx_cost > and seq_cost aren't comparable, it's impossible to arrive at sane solutions.

Re: [Patch AArch64 13/17] Enable _Float16 for AArch64

On 11/11/16 15:40, James Greenhalgh wrote: > > Hi, > > This patch adds the back-end wiring to get AArch64 support for > the _Float16 type working. > > Bootstrapped on AArch64 with no issues. > > OK? > > Thanks, > James > > --- > 2016-11-09 James Greenhalgh > >

Re: [0/3] Fix PR78120, in ifcvt/rtlanal/i386.

On 11/24/2016 03:36 PM, Segher Boessenkool wrote: On Thu, Nov 24, 2016 at 03:26:45PM +0100, Bernd Schmidt wrote: On 11/24/2016 03:21 PM, Segher Boessenkool wrote: Combine uses insn_rtx_cost extensively. I have tried to change it to use the full rtx cost, not just the source cost, a few times

Re: [0/3] Fix PR78120, in ifcvt/rtlanal/i386.

On Thu, Nov 24, 2016 at 03:26:45PM +0100, Bernd Schmidt wrote: > On 11/24/2016 03:21 PM, Segher Boessenkool wrote: > > >Combine uses insn_rtx_cost extensively. I have tried to change it to use > >the full rtx cost, not just the source cost, a few times before, and it > >always only regressed.

Re: [0/3] Fix PR78120, in ifcvt/rtlanal/i386.

On 11/24/2016 03:21 PM, Segher Boessenkool wrote: Combine uses insn_rtx_cost extensively. I have tried to change it to use the full rtx cost, not just the source cost, a few times before, and it always only regressed. Part of it is that most ports' cost calculations are, erm, not so great --

[PING**2] [PATCH, ARM] Further improve stack usage on sha512 (PR 77308)

Hi, this patch is still waiting for review: [PATCH, ARM] Further improve stack usage on sha512 (PR 77308) https://gcc.gnu.org/ml/gcc-patches/2016-11/msg00523.html Thanks Bernd.

Re: [0/3] Fix PR78120, in ifcvt/rtlanal/i386.

[ Only your 0/3 and 3/3 messages arrived -- or is this 1/3? ] On Wed, Nov 23, 2016 at 08:00:30PM +0100, Bernd Schmidt wrote: > Note that I misspelled the PR number in the 0/3 message :-/ > > On 11/23/2016 07:57 PM, Bernd Schmidt wrote: > >1. I noticed comparisons between set_src_cost and

Re: [Patch] Don't expand targetm.stack_protect_fail if it's NULL_TREE

gcc/ 2016-11-11 Jiong Wang * function.c (expand_function_end): Guard stack_protect_epilogue with ENABLE_DEFAULT_SSP_RUNTIME. * cfgexpand.c (pass_expand::execute): Likewise guard for stack_protect_prologue. * defaults.h

Re: [PATCH] combine: Convert subreg-of-lshiftrt to zero_extract properly (PR78390)

Hi, On Thu, 24 Nov 2016, Dominik Vogt wrote: > On s390 (31-Bit) we get two (easily fixable) test regression > supposedly because of the original path (+ this fix), and I don't > know what to do about it. Perhaps these point to two situations, > where the change from lshiftrt to zero_extract

[PATCH][TER] PR 48863: Don't replace expressions across local register variable definitions

Hi all, In this bug we have TER during out-of-ssa misbehaving. A minimal example is: void foo(unsigned a, float b) { unsigned c = (unsigned) b; // 1 register unsigned r0 __asm__("r0") = a; // 2 register unsigned r1 __asm__("r1") = c; // 3 __asm__ volatile( "str %[r1], [%[r0]]\n"

Re: [Patch, tentative] Use MOVE_MAX_PIECES instead of MOVE_MAX in gimple_fold_builtin_memory_op

On Thu, 24 Nov 2016, Senthil Kumar Selvaraj wrote: > Hi, > > I've been analyzing a failing regtest (gcc.dg/strlenopt-8.c) for the avr > target. I found that the (dump) failure is because there are 4 > instances of memcpy, while the testcase expects only 2 for a > non-strict align target

Re: [PING][PATCH][2/2] Early LTO debug -- main part

On Tue, 22 Nov 2016, Jason Merrill wrote: > On 11/11/2016 03:06 AM, Richard Biener wrote: > > +/* ??? In some cases the C++ FE (at least) fails to > > + set DECL_CONTEXT properly. Simply globalize stuff > > + in this case. For example > > + __dso_handle created via

Re: [PATCH, vec-tails] Support loop epilogue vectorization

Hi All, Here is the second patch which supports epilogue vectorization using masking without cost model. Currently it is possible only with passing parameter "--param vect-epilogues-mask=1". Bootstrapping and regression testing did not show any new regression. Any comments will be appreciated.

[Patch, tentative] Use MOVE_MAX_PIECES instead of MOVE_MAX in gimple_fold_builtin_memory_op

Hi, I've been analyzing a failing regtest (gcc.dg/strlenopt-8.c) for the avr target. I found that the (dump) failure is because there are 4 instances of memcpy, while the testcase expects only 2 for a non-strict align target like the avr. Comparing that with a dump generated by

Re: [Patch libgcc AArch64 12/17] Enable hfmode soft-float conversions and truncations

On 11/11/16 15:40, James Greenhalgh wrote: > > Hi, > > This patch enables the conversion functions we need for AArch64's _Float16 > support. To do that we need to implement TARGET_SCALAR_MODE_SUPPORTED_P, > so do that now. > > OK? > > Thanks, > James > > --- > gcc/ > > 2016-11-09 James

Re: [Patch AArch64 11/17] Add floatdihf2 and floatunsdihf2 patterns

On 11/11/16 15:40, James Greenhalgh wrote: > > Hi, > > This patch adds patterns for conversion from 64-bit integer to 16-bit > floating-point values under AArch64 targets which don't have support for > the ARMv8.2-A 16-bit floating point extensions. > > We implement these by first saturating to

Re: [PATCH] Dump probability for edges a frequency for BBs

On 11/24/2016 09:29 AM, Richard Biener wrote: > Please guard with ! TDF_GIMPLE, otherwise the output will not be parseable > with the GIMPLE FE. > > RIchard. Done and verified that and it provides equal dumps for -fdump*-gimple. Installed as r242837. Thanks for review. Martin >From

[PATCH] Fixup PR78396 fix

I noticed a few failing SPEC benchs on a AVX2 machine which is because when now doing BB vectorization on a failed-to-vectorize if-converted loop body we can end up with unvectorized masked loads/stores. As BB vectorization does not handle masked loads/stores at all the following patch simply

Re: [tree-tailcall] Check if function returns it's argument

On Thu, 24 Nov 2016, Prathamesh Kulkarni wrote: > On 24 November 2016 at 17:48, Richard Biener wrote: > > On Thu, 24 Nov 2016, Prathamesh Kulkarni wrote: > > > >> On 24 November 2016 at 14:07, Richard Biener wrote: > >> > On Thu, 24 Nov 2016, Prathamesh

Re: [PATCH] combine: Convert subreg-of-lshiftrt to zero_extract properly (PR78390)

On Wed, Nov 23, 2016 at 02:22:07PM +, Segher Boessenkool wrote: > r242414, for PR77881, introduces some bugs (PR78390, PR78438, PR78477). > It all has the same root cause: that patch makes combine convert every > lowpart subreg of a logical shift right to a zero_extract. This cannot > work at

Re: [tree-tailcall] Check if function returns it's argument

On 24 November 2016 at 17:48, Richard Biener wrote: > On Thu, 24 Nov 2016, Prathamesh Kulkarni wrote: > >> On 24 November 2016 at 14:07, Richard Biener wrote: >> > On Thu, 24 Nov 2016, Prathamesh Kulkarni wrote: >> > >> >> Hi, >> >> Consider following

Re: [tree-tailcall] Check if function returns it's argument

On Thu, 24 Nov 2016, Jakub Jelinek wrote: > On Thu, Nov 24, 2016 at 01:18:37PM +0100, Richard Biener wrote: > > > eg: > > > void *f(void *a1, void *a2, __SIZE_TYPE__ a3) > > > { > > > void *t1 = __builtin_memcpy (a1, a2, a3); > > > return t1; > > > } > > > > > > After patch, copyprop

Re: [tree-tailcall] Check if function returns it's argument

On Thu, Nov 24, 2016 at 01:18:37PM +0100, Richard Biener wrote: > > eg: > > void *f(void *a1, void *a2, __SIZE_TYPE__ a3) > > { > > void *t1 = __builtin_memcpy (a1, a2, a3); > > return t1; > > } > > > > After patch, copyprop transformed it into: > > t1 = __builtin_memcpy (a1, a2, a3); > >

Re: [tree-tailcall] Check if function returns it's argument

On Thu, 24 Nov 2016, Prathamesh Kulkarni wrote: > On 24 November 2016 at 14:07, Richard Biener wrote: > > On Thu, 24 Nov 2016, Prathamesh Kulkarni wrote: > > > >> Hi, > >> Consider following test-case: > >> > >> void *f(void *a1, void *a2, __SIZE_TYPE__ a3) > >> { > >>

Re: [tree-tailcall] Check if function returns it's argument

On 24 November 2016 at 14:07, Richard Biener wrote: > On Thu, 24 Nov 2016, Prathamesh Kulkarni wrote: > >> Hi, >> Consider following test-case: >> >> void *f(void *a1, void *a2, __SIZE_TYPE__ a3) >> { >> __builtin_memcpy (a1, a2, a3); >> return a1; >> } >> >> return a1 can

Re: [PATCH] have __builtin_object_size handle POINTER_PLUS with non-const offset (pr 77608)

On Fri, Nov 11, 2016 at 4:56 PM, Martin Sebor wrote: > Thanks for the review and comments! First of all sorry for the late response. >> >> @@ -158,14 +170,149 @@ compute_object_offset (const_tree expr, const_tree >> var) >>return size_binop (code, base, off); >> } >> >>

Re: [PATCH] combine: Query can_change_dest_mode before changing dest mode

On Thu, Nov 24, 2016 at 11:04:13AM +0100, Georg-Johann Lay wrote: > >@@ -11287,7 +11287,8 @@ change_zero_ext (rtx pat) > > else if (GET_CODE (x) == ZERO_EXTEND > >&& SCALAR_INT_MODE_P (mode) > >&& REG_P (XEXP (x, 0)) > >- && HARD_REGISTER_P (XEXP (x, 0))) >

Re: [PATCH GCC]Refine type conversion in result expressions for cond_expr pattern

On Thu, Nov 24, 2016 at 11:17 AM, Richard Biener wrote: > On Thu, Nov 24, 2016 at 11:11 AM, Bin.Cheng wrote: >> On Thu, Nov 24, 2016 at 8:57 AM, Richard Biener >> wrote: >>> On Wed, Nov 23, 2016 at 3:57 PM, Bin.Cheng

Re: [PATCH fix PR71767 0/4] Background

What's up with the commit status on these proposed patches? On Sun, Nov 6, 2016 at 2:36 PM, Iain Sandoe wrote: > Hi Folks, > > Including Jeff on the cc since we were discussing this on Friday (and it’s > not 100% clear who’s reviewing configury patches at present). >

Re: [AArch64][ARM][GCC][PATCHv2 3/3] Add tests for missing Poly64_t intrinsics to GCC

Hi Christoph, I have combined most of the tests in p64_p128 except for the vreinterpret_p128 and vreinterpret_p64 ones because I felt the number of code that would be have to be added to p64_p128 vs having them in those files isn't worth it. Since a lot of the test setup would have to be copied.

Re: [PATCH, GCC] Fix PR77673: bswap loads passed end of object

On Wed, 23 Nov 2016, Thomas Preudhomme wrote: > Hi, > > In its current form, when the bswap optimization pass recognizes a load in a > specific endianness it assumes that all smaller loads in the original > expression are part of a linear chain of basic block (ie they are either in > the same

Re: [RFC, tentative patch] Adjust cost for conversion expression

On Thu, 24 Nov 2016, Pitchumani Sivanupandi wrote: > GCC inlines small functions if the code size after expansion is not excedded. > For test case (inline.c, avr-gcc -Os -S inline.c) code size become higher if > 'func2' is inlined. It happens because the CONVERT_EXPR/ NOP_EXPR are > considered >

[PATCH] Fix PR78343

I am testing the following patch for an optimization regression where a loop made dead by final value replacement was made used again by DOM 20 passes later. The real issue here is that we do not get rid of dead loops until very late so this patch makes sure to do that. We could schedule it

Re: [PR78365] ICE in determine_value_range, at tree-ssa-loo p-niter.c:413

On Thu, Nov 24, 2016 at 11:15 AM, Prathamesh Kulkarni wrote: > On 24 November 2016 at 15:23, Jan Hubicka wrote: >>> >If DECL_ARGUMENTS is not available at WPA stage then I see no other >>> >way than to put the types on the jump functions. >>> > >>>

Re: [PATCH GCC]Refine type conversion in result expressions for cond_expr pattern

On Thu, Nov 24, 2016 at 11:11 AM, Bin.Cheng wrote: > On Thu, Nov 24, 2016 at 8:57 AM, Richard Biener > wrote: >> On Wed, Nov 23, 2016 at 3:57 PM, Bin.Cheng wrote: >>> On Wed, Nov 23, 2016 at 2:27 PM, Richard Biener >>>

Re: [PATCH] Dump probability for edges a frequency for BBs

On Thu, Nov 24, 2016 at 10:50 AM, Jan Hubicka wrote: >> > LGTM. While I've often found a way to get this stuff when looking at >> > probability updating code, having it in the standard dumps seems like a >> > good >> > enhancement. >> >> Please guard with ! TDF_GIMPLE, otherwise

Re: [PATCH] PR fortran/78500 -- Yet another NULL pointer dereference

On Thu, 24 Nov 2016 11:56:02 +0100 Janus Weil wrote: > Hi Steve, > > > Regression tested on x86_64-*-freebsd. OK to commit? > > the patch is certainly ok. > > Just my usual request for a meaningful test-case name: This one could > be class_result_4.f90. (I don't want

Re: [PATCH] PR fortran/78500 -- Yet another NULL pointer dereference

Hi Steve, > Regression tested on x86_64-*-freebsd. OK to commit? the patch is certainly ok. Just my usual request for a meaningful test-case name: This one could be class_result_4.f90. (I don't want to be pedantic about this, but in a growing testsuite of 4000+ files, I really think it makes

[RFC, tentative patch] Adjust cost for conversion expression

GCC inlines small functions if the code size after expansion is not excedded. For test case (inline.c, avr-gcc -Os -S inline.c) code size become higher if 'func2' is inlined. It happens because the CONVERT_EXPR/ NOP_EXPR are considered as zero cost expression. Few conversions will cost

Re: [PR78365] ICE in determine_value_range, at tree-ssa-loo p-niter.c:413

On 24 November 2016 at 15:23, Jan Hubicka wrote: >> >If DECL_ARGUMENTS is not available at WPA stage then I see no other >> >way than to put the types on the jump functions. >> > >> OK. I will record the type in jump function and send a revised patch. > > It would be good to check

Re: [PATCH GCC]Refine type conversion in result expressions for cond_expr pattern

Here is the patch. Thanks, bin On Thu, Nov 24, 2016 at 10:11 AM, Bin.Cheng wrote: > On Thu, Nov 24, 2016 at 8:57 AM, Richard Biener > wrote: >> On Wed, Nov 23, 2016 at 3:57 PM, Bin.Cheng wrote: >>> On Wed, Nov 23, 2016

Re: [PATCH GCC]Refine type conversion in result expressions for cond_expr pattern

On Thu, Nov 24, 2016 at 8:57 AM, Richard Biener wrote: > On Wed, Nov 23, 2016 at 3:57 PM, Bin.Cheng wrote: >> On Wed, Nov 23, 2016 at 2:27 PM, Richard Biener >> wrote: >>> On Wed, Nov 23, 2016 at 2:54 PM, Bin Cheng

Re: [PATCH] combine: Query can_change_dest_mode before changing dest mode

On 24.11.2016 00:27, Segher Boessenkool wrote: As reported in https://gcc.gnu.org/ml/gcc-patches/2016-11/msg02388.html . Changing the mode of a hard register can lead to problems, or at least it can make worse code if the result will need reloads. Tested on avr-elf on the test in that email,

Re: [PATCH] Fix PR bootstrap/78493

On 11/24/2016 10:09 AM, Jakub Jelinek wrote: > On Thu, Nov 24, 2016 at 09:51:49AM +0100, Richard Biener wrote: >> On Thu, Nov 24, 2016 at 9:36 AM, Jakub Jelinek wrote: >>> On Thu, Nov 24, 2016 at 09:26:25AM +0100, Richard Biener wrote: > Alternately, given all the problems

Re: [PATCH 1/2 v3] PR77822

On Wed, Nov 23, 2016 at 01:22:31PM -0700, Jeff Law wrote: > On 11/21/2016 04:03 AM, Dominik Vogt wrote: > >On Fri, Nov 18, 2016 at 04:29:18PM +0100, Dominik Vogt wrote: > >>> On Fri, Nov 18, 2016 at 08:02:08AM -0600, Segher Boessenkool wrote: > > On Fri, Nov 18, 2016 at 01:09:24PM +0100,

Re: [PATCH] Add sem_item::m_hash_set (PR ipa/78309) (v2)

> On 11/21/2016 04:50 PM, Jan Hubicka wrote: > > OK, > > thanks! > > Honza > > Hi. > > Patch to trunk is already installed. Equal patch can be installed to gcc-6 > branch, > however gcc-5 branch needs more hunks to be adjusted. I did so, both patches > survive > regression tests and the patch

Re: [PR78365] ICE in determine_value_range, at tree-ssa-loo p-niter.c:413

> >If DECL_ARGUMENTS is not available at WPA stage then I see no other > >way than to put the types on the jump functions. > > > OK. I will record the type in jump function and send a revised patch. It would be good to check how much of difference this makes to memory use of WPA for larger

Re: [PATCH] Dump probability for edges a frequency for BBs

> > LGTM. While I've often found a way to get this stuff when looking at > > probability updating code, having it in the standard dumps seems like a good > > enhancement. > > Please guard with ! TDF_GIMPLE, otherwise the output will not be parseable > with the GIMPLE FE. Since gimple FE builds

[PATCH] Fix PR71595

The following fixes PR71595, the failure to update loop-closed SSA when unrolling. We fail to make remove_path note which blocks we have to re-scan -- everything is in place, we just don't use it... This also makes irred recompution more efficient from # removed path times to a single time per

Re: [Patch AArch64 13/17] Enable _Float16 for AArch64

On Fri, Nov 11, 2016 at 03:40:51PM +, James Greenhalgh wrote: > > Hi, > > This patch adds the back-end wiring to get AArch64 support for > the _Float16 type working. > > Bootstrapped on AArch64 with no issues. > > OK? Ping. Thanks, James

Re: [Patch libgcc AArch64 12/17] Enable hfmode soft-float conversions and truncations

On Fri, Nov 11, 2016 at 03:40:50PM +, James Greenhalgh wrote: > > Hi, > > This patch enables the conversion functions we need for AArch64's _Float16 > support. To do that we need to implement TARGET_SCALAR_MODE_SUPPORTED_P, > so do that now. Ping. Thanks, James > > OK? > > Thanks, >

Ping^8 Re: [Patch AArch64 11/17] Add floatdihf2 and floatunsdihf2 patterns

On Fri, Nov 11, 2016 at 03:40:49PM +, James Greenhalgh wrote: > > Hi, > > This patch adds patterns for conversion from 64-bit integer to 16-bit > floating-point values under AArch64 targets which don't have support for > the ARMv8.2-A 16-bit floating point extensions. > > We implement these

Re: [patch, nios2] Fix PR78357, adjust sync builtin initialization

On 2016/11/24 6:28 AM, Jeff Law wrote: > On 11/16/2016 02:53 AM, Chung-Lin Tang wrote: >> This patch adjusts the initialization of __sync built-in functions: >> instead of conditionalizing on TARGET_LINUX_ABI, directly place the >> target-hook #define in config/nios2/linux.h. This appears to be

Re: [PATCH] Fix PR bootstrap/78493

On Thu, Nov 24, 2016 at 09:51:49AM +0100, Richard Biener wrote: > On Thu, Nov 24, 2016 at 9:36 AM, Jakub Jelinek wrote: > > On Thu, Nov 24, 2016 at 09:26:25AM +0100, Richard Biener wrote: > >> > Alternately, given all the problems we have with this kind of problem, we > >> >

Re: [PATCH GCC]Refine type conversion in result expressions for cond_expr pattern

On Wed, Nov 23, 2016 at 3:57 PM, Bin.Cheng wrote: > On Wed, Nov 23, 2016 at 2:27 PM, Richard Biener > wrote: >> On Wed, Nov 23, 2016 at 2:54 PM, Bin Cheng wrote: >>> Hi, >>> This is actually the review suggestion for patch

Re: [PR78365] ICE in determine_value_range, at tree-ssa-loo p-niter.c:413

Hi, On 24/11/16 19:48, Richard Biener wrote: On Wed, Nov 23, 2016 at 4:33 PM, Martin Jambor wrote: Hi, On Fri, Nov 18, 2016 at 12:38:18PM +1100, kugan wrote: Hi, I was relying on ipa_get_callee_param_type to get type of parameter and thenHi, convert arguments to this type

Re: [PATCH] Fix PR bootstrap/78493

On Thu, Nov 24, 2016 at 9:36 AM, Jakub Jelinek wrote: > On Thu, Nov 24, 2016 at 09:26:25AM +0100, Richard Biener wrote: >> > Alternately, given all the problems we have with this kind of problem, we >> > should seriously consider throttling back what we consider an error during

Re: [PR78365] ICE in determine_value_range, at tree-ssa-loo p-niter.c:413

On Wed, Nov 23, 2016 at 4:33 PM, Martin Jambor wrote: > Hi, > > On Fri, Nov 18, 2016 at 12:38:18PM +1100, kugan wrote: >> Hi, >> >> I was relying on ipa_get_callee_param_type to get type of parameter and then >> convert arguments to this type while computing jump functions.

Re: [tree-tailcall] Check if function returns it's argument

On Thu, 24 Nov 2016, Prathamesh Kulkarni wrote: > Hi, > Consider following test-case: > > void *f(void *a1, void *a2, __SIZE_TYPE__ a3) > { > __builtin_memcpy (a1, a2, a3); > return a1; > } > > return a1 can be considered equivalent to return value of memcpy, > and the call could be emitted

  1   2   >