Re: [PATCH 1/4][PR tree-optimization/78496] Don't simplify conditionals too early in VRP

On Fri, May 5, 2017 at 10:53 PM, Jeff Law wrote: > On 05/04/2017 08:37 AM, Jeff Law wrote: >> >> >> You understanding is slightly wrong however, The ASSERT_EXPRs and >> conditionals map 100% through propagation and into simplification. It's >> only during simplification that we

Re: [PATCH 2/n] [PR tree-optimization/78496] Simplify ASSERT_EXPRs to facilitate jump threading

On Sat, May 6, 2017 at 5:03 PM, Jeff Law wrote: > This is the 2nd of 3-5 patches to address pr78496. > > Jump threading will examine ASSERT_EXPRs as it walks the IL and record > information from those ASSERT_EXPRs into the available expression and > const/copies tables where

Re: [PATCH GCC8][11/33]New interfaces for tree affine

On Thu, May 4, 2017 at 5:21 PM, Bin.Cheng wrote: > On Mon, Apr 24, 2017 at 11:43 AM, Richard Biener > wrote: >> On Tue, Apr 18, 2017 at 12:43 PM, Bin Cheng wrote: >>> Hi, >>> This patch adds three simple interfaces for tree

Re: [PATCH GCC8][28/33]Don't count non-interger PHIs for register pressure

On Thu, May 4, 2017 at 5:33 PM, Bin.Cheng wrote: > On Wed, Apr 26, 2017 at 3:32 PM, Bin.Cheng wrote: >> On Wed, Apr 26, 2017 at 3:23 PM, Richard Biener >> wrote: >>> On Wed, Apr 26, 2017 at 3:37 PM, Bin.Cheng

Re: [PATCH GCC8][17/33]Treat complex cand step as invriant expression

On Thu, May 4, 2017 at 7:55 PM, Bin.Cheng wrote: > On Wed, May 3, 2017 at 2:43 PM, Richard Biener > wrote: >> On Tue, Apr 18, 2017 at 12:46 PM, Bin Cheng wrote: >>> Hi, >>> We generally need to compute cand step in loop

Re: [Testsuite, committed] Fix vector peeling test failures

On Mon, May 8, 2017 at 2:41 PM, Wilco Dijkstra wrote: > This fixes a few failures on ARM and AArch64 due to a recent change in > alignment peeling by switching the vector cost model off > (https://gcc.gnu.org/ml/gcc-patches/2017-05/msg00407.html). > > Tested on AArch64,

Re: Remove redundant zero extend

On Thu, Mar 12, 2020 at 4:06 AM Jeff Law via Gcc-patches wrote: > > On Wed, 2020-03-11 at 13:04 +, Nidal Faour via Gcc-patches wrote: > > This patch is a code density oriented and attempt to remove redundant > > sign/zero > > extension from assignment statement. > > The approach taken is to

Re: [RFC][gcc][vect] PR 91246: Prototype for vectorization of loops with breaks

On Thu, Mar 12, 2020 at 10:15 AM Andre Vieira (lists) wrote: > > Hi all, > > This is a prototype I have put together to look at the feasibility and > profitability of vectorizing loops with breaks as suggested in PR 91246. > I am posting this here for comments as I am curious what your opinions >

Re: [PATCH][RFC] API extension for binutils (type of symbols).

On Wed, Mar 11, 2020 at 1:22 PM Martin Liška wrote: > > On 3/11/20 11:22 AM, Richard Biener wrote: > > On Wed, Mar 11, 2020 at 10:19 AM Martin Liška wrote: > >> > >> On 3/10/20 1:07 PM, Martin Liška wrote: > >>> On 3/10/20 12:24 PM, Richard Biener wrote: > Not sure how symtab is encoded

Re: [PATCH][RFC] API extension for binutils (type of symbols).

On Wed, Mar 11, 2020 at 10:19 AM Martin Liška wrote: > > On 3/10/20 1:07 PM, Martin Liška wrote: > > On 3/10/20 12:24 PM, Richard Biener wrote: > >> Not sure how symtab is encoded right now but we also could have > > > > Ok, right now I don't see symtab entry much extensible. > > > > But what am

Re: [PATCH][RFC] API extension for binutils (type of symbols).

On Wed, Mar 11, 2020 at 11:22 AM Richard Biener wrote: > > On Wed, Mar 11, 2020 at 10:19 AM Martin Liška wrote: > > > > On 3/10/20 1:07 PM, Martin Liška wrote: > > > On 3/10/20 12:24 PM, Richard Biener wrote: > > >> Not sure how symtab is encoded right now but we also could have > > > > > > Ok,

Re: [patch] Fix middle-end/93961

On Wed, Mar 11, 2020 at 8:56 AM Eric Botcazou wrote: > > Hi, > > this is a GIMPLE verification failure in LTO mode on Ada code: > > /vol/gcc/src/hg/master/local/gcc/testsuite/gnat.dg/lto24_pkg1.ads:9:8: error: > type mismatch in 'component_ref' > lto24_pkg1__rec___b___XVN > >

Re: [PATCH v2] generate EH info for volatile asm statements (PR93981)

On Thu, Mar 12, 2020 at 11:01 AM Richard Sandiford wrote: > > "J.W. Jagersma" writes: > > On 2020-03-09 13:13, Richard Sandiford wrote: > >> Thanks for doing this. > > > > Hi Richard, thanks for your response. > > > >> "J.W. Jagersma" writes: > >>> On 2020-03-07 20:20, Segher Boessenkool wrote:

Re: [PATCH][RFC] API extension for binutils (type of symbols).

On Thu, Mar 12, 2020 at 2:11 PM Martin Liška wrote: > > On 3/12/20 1:55 PM, Jan Hubicka wrote: > >> gcc/ChangeLog: > >> > >> 2020-03-12 Martin Liska > >> > >> * lto-section-in.c: Add extension_symtab. > >> * lto-streamer-out.c (write_symbol_extension_info): > >> New. > >>

Re: [PATCH] df: Don't abuse bb->aux (PR94148)

On March 12, 2020 11:29:45 PM GMT+01:00, Segher Boessenkool wrote: >The df dataflow solvers use the aux field in the basic_block struct, >although that is reserved for any use by passes. And not only that, >it is required that you set all such fields to NULL before calling >the solvers, or you

Re: [patch] Fix PR middle-end/92071

On Fri, Mar 13, 2020 at 8:37 AM Eric Botcazou wrote: > > Hi, > > this is a regression present on the mainline for the ARM in the form of an > assertion failure at -O2 in the back-end, which rightfully refuses to generate > a load from an unaligned memory location (the ARM target is

Re: [PATCH] Allow new/delete operator deletion only for replaceable.

On Thu, Apr 9, 2020 at 7:06 AM Martin Liška wrote: > > Hi. > > We've got one another sneaky test-case (thank you Marc ;) ): > > $ cat pr94314-array.C > #include > #include > > int count = 0; > > __attribute__((malloc, noinline)) void* operator new[](unsigned long sz) { >++count; >return

Re: [PATCH] Allow new/delete operator deletion only for replaceable.

On Thu, Apr 9, 2020 at 9:00 AM Martin Liška wrote: > > On 4/9/20 8:45 AM, Richard Biener wrote: > > On Thu, Apr 9, 2020 at 7:06 AM Martin Liška wrote: > >> > >> Hi. > >> > >> We've got one another sneaky test-case (thank you Marc ;) ): > >> > >> $ cat pr94314-array.C > >> #include > >> #include

Re: [PATCH PR93674]Avoid introducing IV of enumeral type in case of -fstrict-enums

On Thu, Apr 9, 2020 at 4:23 AM bin.cheng wrote: > > -- > Sender:Richard Biener > Sent At:2020 Mar. 20 (Fri.) 18:12 > Recipient:bin.cheng > Cc:Andrew Pinski ; GCC Patches > Subject:Re: [PATCH PR93674]Avoid introducing IV of

Re: [PATCH v3] Fix alignment for local variable [PR90811]

On Wed, Apr 8, 2020 at 7:13 PM Kito Cheng wrote: > > ping > > On Tue, Mar 31, 2020 at 4:33 PM Kito Cheng wrote: > > > > - The alignment for local variable was adjust during > > estimate_stack_frame_size, > >however it seems wrong spot to adjust that, expand phase will adjust that > >

Re: [RFC] split pseudos during loop unrolling in RTL unroller

On Wed, Apr 15, 2020 at 3:56 AM Jiufu Guo via Gcc-patches wrote: > > Hi, > > As you may know, we have loop unroll pass in RTL which was introduced a few > years ago, and works for a long time. Currently, this unroller is using the > pseudos in the original body, and then the pseudos are written

Re: [PATCH] Check DECL_CONTEXT of new/delete operators.

On Tue, Apr 7, 2020 at 11:49 AM Jan Hubicka wrote: > > > > > Well, the question is how to identify "operator new and operator delete at > > the > > point of the new-expression and delete-expression". Currently we're > > just matching up "is this a new/delete operator" and the dataflow of the >

Re: libgcc patch committed: Avoid hooks in split-stack code

On Fri, Apr 3, 2020 at 11:59 PM Ian Lance Taylor via Gcc-patches wrote: > > The split-stack code invokes mmap and munmap with a limited amount of > stack space. That is fine when the functions just make a system call, > but it's not fine when programs use LD_PRELOAD or linker tricks to add >

Re: [PATCH] Check DECL_CONTEXT of new/delete operators.

On Tue, Apr 7, 2020 at 10:26 AM Jonathan Wakely wrote: > > On Mon, 6 Apr 2020 at 13:45, Nathan Sidwell wrote: > > > > On 4/6/20 4:34 AM, Martin Liška wrote: > > > > > > > > May I please ping Jason, Nathan and Jonathan who can help us here? > > > > On IRC Martin clarified the question as

Re: [PATCH] Check DECL_CONTEXT of new/delete operators.

On Tue, Apr 7, 2020 at 1:30 PM Jonathan Wakely wrote: > > On Mon, 6 Apr 2020 at 13:45, Nathan Sidwell wrote: > > The both operator new and operator delete are looked up in the same > > manner. The std does not require a 'matching pair' be found. but it is > > extremely poor form for a class to

Re: [PATCH] Check DECL_CONTEXT of new/delete operators.

On Tue, Apr 7, 2020 at 1:46 PM Jonathan Wakely wrote: > > On Tue, 7 Apr 2020 at 12:40, Richard Biener > wrote: > > > > On Tue, Apr 7, 2020 at 1:30 PM Jonathan Wakely > > wrote: > > > > > > On Mon, 6 Apr 2020 at 13:45, Nathan Sidwell wrote: > > > > The both operator new and operator delete are

Re: [PATCH, testsuite] Fix PR94079 by respecting vect_hw_misalign

On Wed, Apr 8, 2020 at 10:17 AM Kewen.Lin via Gcc-patches wrote: > > Hi, > > This is another vect case which requires special handling with > vect_hw_misalign. The alignment of the second part requires > misaligned vector access supports. This patch is to adjust > the related guard condition

Re: [RFC, Instruction Scheduler, Stage1] New hook/code to perform fusion of dependent instructions

On Tue, Apr 7, 2020 at 10:45 PM Pat Haugen via Gcc-patches wrote: > > The Power processor has the ability to fuse certain pairs of dependent > instructions to improve their performance if they appear back-to-back in > the instruction stream. In looking at the current support for > instruction

Re: [PATCH] Allow new/delete operator deletion only for replaceable.

On Tue, Apr 7, 2020 at 5:01 PM Martin Liška wrote: > > Hi. > > The patch allows DCE to remove only replaceable operators new and delete. > That's achieved by proper mark up of all these operators in C++ FE. > The patch also brings all tests we've collected so far for the PR. > > Patch can

Re: [PING] [PATCH PR94442] [AArch64] Redundant ldp/stp instructions emitted at -O3

On Mon, Apr 13, 2020 at 8:48 AM xiezhiheng wrote: > > Ping for: > This is definitely stage1 material. Richard. > Xie Zhiheng > > > > -Original Message- > > From: xiezhiheng > > Sent: Thursday, April 2, 2020 2:35 PM > >

Re: [PATCH PR94574] ICE during GIMPLE pass: ccp

On Mon, Apr 13, 2020 at 11:38 AM yangyang (ET) wrote: > > Hi, > > This is a simple fix for pr94574. > > testcase testsuite/gcc.target/aarch64/sve/acle/general/deref_1.c ICEs when > testing GCC trunk with -O2 -msve-vector-bits=256 -march=armv8.2-a+sve. > > There is a gimple statement before

Re: [PATCH] ipa-sra: Fix treatment of internal functions (PR 94434)

On Thu, Apr 9, 2020 at 7:57 PM Martin Jambor wrote: > > Hi, > > On Tue, Apr 07 2020, bule wrote: > > Hi, > > > > The patch is tested and works fine. It is more appropriate to handle > > the context by considering it as a section of assemble code. > > > > A minor question is that I think svst

Re: [PING] [PATCH PR94442] [AArch64] Redundant ldp/stp instructions emitted at -O3

On Tue, Apr 14, 2020 at 11:05 AM xiezhiheng wrote: > > > -Original Message- > > From: Richard Biener [mailto:richard.guent...@gmail.com] > > Sent: Tuesday, April 14, 2020 4:39 PM > > To: xiezhiheng > > Cc: gcc-patches@gcc.gnu.org > > Subject: Re: [PING] [PATCH PR94442] [AArch64]

Re: [PATCH] correct strncpy range computation in restrict pass (PR 94647)

On Mon, Apr 20, 2020 at 11:29 PM Martin Sebor via Gcc-patches wrote: > > The restrict pass computes the wrong lower bound of the size > of accesses to member arrays passed to strncpy as the source: > it uses the third argument to the function even though the size > of the read is limited by the

Re: [PATCH] forwprop: Fix ICE when building a VEC_PERM_EXPR [PR94683]

On Tue, Apr 21, 2020 at 2:13 PM Richard Sandiford wrote: > > The type compatibility handling in simplify_vector_constructor is > based on the number of elements and on element type compatibility, > but that's no longer enough to ensure that two vector types are > compatible. This patch uses a

Re: [RFC] split pseudos during loop unrolling in RTL unroller

On Fri, Apr 17, 2020 at 10:51 PM Segher Boessenkool wrote: > > On Fri, Apr 17, 2020 at 08:53:08AM +0200, Richard Biener wrote: > > On Thu, Apr 16, 2020 at 7:46 PM Segher Boessenkool > > wrote: > > > > > > On Thu, Apr 16, 2020 at 10:33:45AM +0200, Richard Biener wrote: > > > > On Wed, Apr 15,

Re: [RFC] split pseudos during loop unrolling in RTL unroller

On Fri, Apr 17, 2020 at 10:51 PM Segher Boessenkool wrote: > > On Fri, Apr 17, 2020 at 08:53:08AM +0200, Richard Biener wrote: > > On Thu, Apr 16, 2020 at 7:46 PM Segher Boessenkool > > wrote: > > > > > > On Thu, Apr 16, 2020 at 10:33:45AM +0200, Richard Biener wrote: > > > > On Wed, Apr 15,

Re: [PATCH] vect: Tweak vect_better_loop_vinfo_p handling of variable VFs

On Fri, Apr 17, 2020 at 5:21 PM Richard Sandiford wrote: > > This patch fixes a large lmbench performance regression with > 128-bit SVE, compiled in length-agnostic mode. > > vect_better_loop_vinfo_p (new in GCC 10) tries to estimate whether > a new loop_vinfo is cheaper than a previous one, with

Re: [RFC] split pseudos during loop unrolling in RTL unroller

On Mon, Apr 20, 2020 at 3:38 PM Segher Boessenkool wrote: > > Hi! > > On Mon, Apr 20, 2020 at 09:56:34AM +0200, Richard Biener wrote: > > On Fri, Apr 17, 2020 at 10:51 PM Segher Boessenkool > > wrote: > > > > Yeah well, but RTL is not in SSA form > > > > > > "Webs" are not the *same* as SSA, in

Re: [PATCH] testsuite: Move misplaced gcc.c-torture/pr92372.c test [PR92372]

On Thu, Apr 16, 2020 at 10:23 AM Jakub Jelinek via Gcc-patches wrote: > > Hi! > > This test got committed into a spot where nothing actually tests it. > As there is no main, I assume it was meant to be gcc.c-torture/compile/ > test and the test PASSes after moving there (both x86_64-linux and >

Re: [RFC] split pseudos during loop unrolling in RTL unroller

On Wed, Apr 15, 2020 at 11:23 PM Segher Boessenkool wrote: > > Hi! > > On Wed, Apr 15, 2020 at 08:21:03AM +0200, Richard Biener wrote: > > On Wed, Apr 15, 2020 at 3:56 AM Jiufu Guo via Gcc-patches > > wrote: > > > As you may know, we have loop unroll pass in RTL which was introduced a > > > few

Re: [RFC] split pseudos during loop unrolling in RTL unroller

On Thu, Apr 16, 2020 at 7:46 PM Segher Boessenkool wrote: > > On Thu, Apr 16, 2020 at 10:33:45AM +0200, Richard Biener wrote: > > On Wed, Apr 15, 2020 at 11:23 PM Segher Boessenkool > > > On a general note, we shouldn't depend on some pass that may or may not > > > clean up the mess we make, when

Re: [PATCH] Initialize file_data->lto_section_header before lto_mode_identity_table call.

On Fri, Apr 17, 2020 at 10:44 AM Martin Liška wrote: > > Hi. > > It's quite obvious fix where we ask for a compression algorithm > to file_data->lto_section_header which is unfilled. > > Patch works with nvptx offloading compiler and lto.exp works fine > on x86_64-linux-gnu. > > Ready to be

Re: [PATCH] Check DECL_CONTEXT of new/delete operators.

On Tue, Apr 7, 2020 at 5:17 PM Jonathan Wakely wrote: > > On Tue, 7 Apr 2020 at 12:57, Richard Biener > wrote: > > > > On Tue, Apr 7, 2020 at 1:46 PM Jonathan Wakely > > wrote: > > > > > > On Tue, 7 Apr 2020 at 12:40, Richard Biener > > > wrote: > > > > > > > > On Tue, Apr 7, 2020 at 1:30

Re: [PATCH PR94125]Update post order number for merged SCC

On March 15, 2020 7:12:26 AM GMT+01:00, "bin.cheng via Gcc-patches" wrote: >Hi, >This simple patch fixes PR94125 by updating post order number for >merged SCC. >The root cause is after computing SCC with runtime alias edges skipped, >the post >order info is changed and it's possible a partition

Re: [RFA/RFC] [PR tree-optimization/80635] Optimize some V_C_Es with limited ranges into NOP_EXPRs

On April 5, 2020 5:25:15 PM GMT+02:00, Jeff Law via Gcc-patches wrote: > >So here's an approach to try and address PR80635. > >In this BZ we're getting a false positive uninitialized warning using >std::optional. > >As outlined in the BZ this stems from SRA using a VIEW_CONVERT_EXPR >which

Re: [RFA/RFC] [PR tree-optimization/80635] Optimize some V_C_Es with limited ranges into NOP_EXPRs

On Sun, Apr 5, 2020 at 5:25 PM Jeff Law via Gcc-patches wrote: > > > So here's an approach to try and address PR80635. > > In this BZ we're getting a false positive uninitialized warning using > std::optional. > > As outlined in the BZ this stems from SRA using a VIEW_CONVERT_EXPR which > isn't

Re: [PATCH] Check DECL_CONTEXT of new/delete operators.

On Sat, Apr 4, 2020 at 1:53 PM Jan Hubicka wrote: > > Hi, > thinking a bit of the problem, I guess we could match in addition to > DECL_CONTEXT the whole inline stack of both statements and see if there > are inlined new/delete operators and if so if they are always in > matching pairs. > > The

Re: [PATCH] Fix alignment for local variable [PR90811]

On Fri, Mar 27, 2020 at 2:54 PM Richard Biener wrote: > > On Fri, Mar 27, 2020 at 2:04 PM Kito Cheng wrote: > > > > Hi Richard: > > > > The local variable alignment adjustment was removed at this commit: > > https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=26d7a5e690169ac04acde90070b0092c41b71c7e

Re: [PATCH] Fix alignment for local variable [PR90811]

On Fri, Mar 27, 2020 at 1:28 PM Kito Cheng wrote: > > - The alignment for local variable was adjust during > estimate_stack_frame_size, >however it seems wrong spot to adjust that. > > - So we must adjust at some point, and here is already a pass to adjust >alignment, which is

Re: [PATCH] Fix alignment for local variable [PR90811]

On Fri, Mar 27, 2020 at 2:04 PM Kito Cheng wrote: > > Hi Richard: > > The local variable alignment adjustment was removed at this commit: > https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=26d7a5e690169ac04acde90070b0092c41b71c7e > > And it's a little bit indirectly, it called from >

Re: [PATCH] ICF: compare type attributes for gimple_call_fntypes.

On Thu, Apr 2, 2020 at 5:16 PM Martin Liška wrote: > > Hi. > > The patch compares type attributes for gimple_call_fntypes in IPA ICF. > Note that we were unable to find a generic function attribute that > can be used on a function type definition. > > For a one which is allowed assume_aligned(16)

Re: [PATCH] Fix PR94443 with gsi_insert_seq_before

On Thu, Apr 2, 2020 at 12:43 PM Kewen.Lin wrote: > > on 2020/4/2 上午6:51, H.J. Lu wrote: > > > > This caused: > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94449 > > > > Thanks for reporting this. The attached patch is to fix the stupid > mistake by using gsi_insert_seq_before instead of

Re: [PATCH] PR lto/94249: Correct endianness detection with the __BYTE_ORDER macro

On Tue, Mar 31, 2020 at 3:28 PM Maciej W. Rozycki wrote: > > Correct an issue with GCC commit 906b3eb9df6c ("Improve endianess > detection.") and fix a typo in the __BYTE_ORDER fallback macro check > that causes compilation errors like: > > .../include/plugin-api.h:162:2: error: #error "Could not

Re: [PATCH 2/2] Fix alignment for local variable [PR90811]

On Fri, Mar 27, 2020 at 7:27 PM Jakub Jelinek wrote: > > On Sat, Mar 28, 2020 at 02:06:56AM +0800, Kito Cheng wrote: > > PR target/90811 > > * ipa-increase-alignment.cc (increase_alignment_local_var): New. > > (increase_alignment_global_var): New. > >

Re: [PATCH] Fix PR94043 by making vect_live_op generate lc-phi

On Mon, Mar 30, 2020 at 12:24 PM Kewen.Lin wrote: > > Hi, > > As PR94043 shows, my commit r10-4524 exposed one issue in > vectorizable_live_operation, which inserts one extra BB > before the single exit, leading unexpected operand expansion > and unexpected loop depth assertion. As Richi

Re: [PATCH] Check DECL_CONTEXT of new/delete operators.

On Mon, Mar 30, 2020 at 10:41 AM Martin Liška wrote: > > Hi. > > The patch ensures that a deleted new/delete pair has a same context. > That will fix the issue presented in the PR. > > Patch can bootstrap on x86_64-linux-gnu and survives regression tests. I think this will break the DCE with LTO

Re: [PATCH] Fix PR94401 by considering reverse overrun

On Thu, Apr 2, 2020 at 9:15 AM Kewen.Lin wrote: > > Hi, > > The commit r10-7415 brings scalar type consideration > to eliminate epilogue peeling for gaps, but it exposed > one problem that the current handling doesn't consider > the memory access type VMAT_CONTIGUOUS_REVERSE, for > which the

Re: [PATCH] doc: RISC-V: Update binutils requirement to 2.30

On Wed, Apr 1, 2020 at 10:34 PM Maciej W. Rozycki via Gcc-patches wrote: > > Complement commit bfe78b08471f ("RISC-V: Using fmv.x.w/fmv.w.x rather > than fmv.x.s/fmv.s.x") and document a binutils 2.30 requirement in the > installation manual, matching the addition of fmv.x.w/fmv.w.x mnemonics >

Re: [AArch64][SVE][IPA] ICE caused by incompatibility of SRA and svst builtin-function

On Thu, Apr 2, 2020 at 5:36 AM bule wrote: > > Hello, > > An Internal Compiler Error(ICE) is found in ipa-sra optimization pass when it > handle the argument of internal call svst3 for SVE. > > The problem comes from > gcc/testsuite/gcc.target/aarch64/sve/acle/asm/st2_bf16.c in the test suit,

Re: [PATCH] sra/doc: Document param sra-max-propagations

On Thu, Apr 2, 2020 at 12:21 PM Martin Jambor wrote: > > Hi, > > I forgot to document the new param in invoke.texi, does the text below > look OK? OK. > Tested with make info and make pdf. > > Thanks, > > Martin > > > 2020-04-02 Martin Jambor > > * doc/invoke.texi (Optimize Options):

Re: [RFC] Should widening_mul should consider block frequency?

On Thu, Mar 26, 2020 at 2:06 AM Yangfei (Felix) wrote: > > Hi! > > > -Original Message- > > From: Richard Biener [mailto:richard.guent...@gmail.com] > > Sent: Tuesday, March 24, 2020 10:14 PM > > To: Yangfei (Felix) > > Cc: gcc-patches@gcc.gnu.org > > Subject: Re: [RFC] Should

Re: [PATCH v3] Fix PR90332 by extending half size vector mode

On Thu, Mar 26, 2020 at 12:01 PM Kewen.Lin wrote: > > Hi Richi, > > on 2020/3/25 下午4:25, Richard Biener wrote: > > On Tue, Mar 24, 2020 at 9:30 AM Kewen.Lin wrote: > >> > >> Hi, > >> > >> The new version with refactoring has been attached. > >> Bootstrapped/regtested on powerpc64le-linux-gnu

Re: [PATCH v2] Fix PR90332 by extending half size vector mode

On Tue, Mar 24, 2020 at 9:30 AM Kewen.Lin wrote: > > Hi, > > on 2020/3/18 下午11:10, Richard Biener wrote: > > On Wed, Mar 18, 2020 at 2:56 PM Kewen.Lin wrote: > >> > >> Hi Richi, > >> > >> Thanks for your comments. > >> > >> on 2020/3/18 下午6:39, Richard Biener wrote: > >>> On Wed, Mar 18, 2020 at

Re: [PATCH v2 00/11] aarch64: Implement TImode comparisons

On Mon, Apr 6, 2020 at 1:20 PM Richard Sandiford wrote: > > "Richard Earnshaw (lists)" writes: > > On 03/04/2020 16:03, Richard Sandiford wrote: > >> "Richard Earnshaw (lists)" writes: > >>> On 03/04/2020 13:27, Richard Sandiford wrote: > "Richard Earnshaw (lists)" writes: > > On

Re: [stage1][PATCH] Lower VEC_COND_EXPR into internal functions.

On Mon, Apr 6, 2020 at 11:18 AM Richard Sandiford wrote: > > Martin Liška writes: > > Hello. > > > > This is second attempt to get rid of tcc_comparison GENERIC trees > > to be used as the first argument of VEC_COND_EXPR. > > > > The patch attempts achieves that in the following steps: > > 1)

Re: [stage1][PATCH] Lower VEC_COND_EXPR into internal functions.

On Mon, Apr 6, 2020 at 11:18 AM Richard Sandiford wrote: > > Martin Liška writes: > > Hello. > > > > This is second attempt to get rid of tcc_comparison GENERIC trees > > to be used as the first argument of VEC_COND_EXPR. > > > > The patch attempts achieves that in the following steps: > > 1)

Re: [PATCH, PR94769] fortran/io.c: Fix use of uninitialized variable num

On Tue, Apr 28, 2020 at 2:44 PM Stefan Schulze Frielinghaus via Gcc-patches wrote: > > While bootstrapping GCC on S/390 the following warning occurs: > > gcc/fortran/io.c: In function 'bool gfc_resolve_dt(gfc_code*, gfc_dt*, > locus*)': > gcc/fortran/io.c:3857:7: error: 'num' may be used

Re: [RFC] Clarify -ffinite-math-only documentation

On Tue, Apr 28, 2020 at 12:04 PM Richard Sandiford wrote: > > Matthias Kretz writes: > > On Dienstag, 28. April 2020 09:21:38 CEST Richard Biener wrote: > >> On Mon, Apr 27, 2020 at 11:26 PM Matthias Kretz wrote: > >> > * Why not disable NaN and Inf independently? Inf is just a reciprocal 0. >

Re: [PATCH, PR94769] fortran/io.c: Fix use of uninitialized variable num

On Tue, Apr 28, 2020 at 3:23 PM Jakub Jelinek via Gcc-patches wrote: > > On Tue, Apr 28, 2020 at 01:53:07PM +0200, Stefan Schulze Frielinghaus via > Gcc-patches wrote: > > gcc/fortran/ChangeLog: > > > > 2020-04-28 Stefan Schulze Frielinghaus > > > > PR fortran/94769 > > * io.c

Re: [PATCH v2] c++, middle-end, rs6000: Fix C++17 ABI incompatibilities during class layout and [[no_unique_address]] handling [PR94707]

On April 28, 2020 4:04:58 PM GMT+02:00, Jakub Jelinek via Gcc-patches wrote: >Hi! > >On Tue, Apr 28, 2020 at 08:53:31AM -0400, Jason Merrill wrote: >> That sounds good. > >So like this? Or better name for the new macro? I think you miss a hunk for lto/ to compare the flag for tree merging.

Re: [RFC] Clarify -ffinite-math-only documentation

On Mon, Apr 27, 2020 at 6:09 PM Matthias Kretz wrote: > > Hi, > > This documentation change clarifies the effect of -ffinite-math-only. With the > current documentation, it is unclear what the presence of NaN and Inf > representations means if (arithmetic) operations on such values are >

Re: [PATCH, PR94774] tree-optimization: Fix use of uninitialized variable

On Tue, Apr 28, 2020 at 6:14 PM Martin Sebor via Gcc-patches wrote: > > On 4/27/20 10:58 AM, Stefan Schulze Frielinghaus wrote: > > Array retval is not necessarily initialized by function is_call_safe and > > may be used afterwards. Thus, initialize it explicitly. > > > > Ok for master? > > The

Re: [RFC] Clarify -ffinite-math-only documentation

On Tue, Apr 28, 2020 at 10:54 PM Sandra Loosemore wrote: > > On 4/27/20 9:08 AM, Matthias Kretz wrote: > > > > @item -ffinite-math-only > > @opindex ffinite-math-only > > -Allow optimizations for floating-point arithmetic that assume > > -that arguments and results are not NaNs or +-Infs. > >

Re: [PATCH]use vnode->get_constructor () to get intial in lto[PR94822]

On Wed, Apr 29, 2020 at 6:04 AM lizekun (A) wrote: > > Hi, > > This ICE appears because gcc will stream it to the function_body section when > processing the > variable with the initial value of the constructor type, and the > error_mark_node to the > decls section. When recompiling, the value

Re: [PATCH] x86: Allow -fcf-protection with external thunk

On Wed, Apr 29, 2020 at 4:22 AM H.J. Lu via Gcc-patches wrote: > > Allow -fcf-protection with external thunk since the external thunk can be > made compatible with -fcf-protection. > > OK for master? OK. I guess also OK for backporting to branches where CET support is in a reasonable state (not

Re: [PATCH]use vnode->get_constructor () to get intial in lto[PR94822]

On Wed, Apr 29, 2020 at 6:04 AM lizekun (A) wrote: > > Hi, > > This ICE appears because gcc will stream it to the function_body section when > processing the > variable with the initial value of the constructor type, and the > error_mark_node to the > decls section. When recompiling, the value

Re: [PATCH PR94708] rtl combine should consider NaNs when generate fp min/max

On Fri, Apr 24, 2020 at 9:52 AM Zhanghaijian (A) wrote: > > > > > -Original Message- > > From: Richard Biener [mailto:richard.guent...@gmail.com] > > Sent: Friday, April 24, 2020 2:19 PM > > To: Zhanghaijian (A) > > Cc: Segher Boessenkool ; > > gcc-patches@gcc.gnu.org > > Subject: Re:

Re: [RFC] split pseudos during loop unrolling in RTL unroller

On Thu, Apr 23, 2020 at 4:54 PM Eric Botcazou wrote: > > > > > What is wrong with DF? > > > > > > It's slow and memory hungry? > > > > Very true, of course. But can this be significantly better? > > That's a good question worth investigating in my opinion, because DF didn't > quite achieve its

Re: [PATCH PR94708] rtl combine should consider NaNs when generate fp min/max

On Fri, Apr 24, 2020 at 5:05 AM Zhanghaijian (A) wrote: > > Thanks for your suggestions. For safety, I put back > flag_unsafe_math_optimizations. > Attached please find the v3 patch which is suitable for git am. Bootstrap and > tested on aarch64 Linux platform. > Is the v3 patch ok? OK.

Re: [RFC] split pseudos during loop unrolling in RTL unroller

On Thu, Apr 23, 2020 at 2:07 PM Segher Boessenkool wrote: > > On Thu, Apr 23, 2020 at 12:52:30PM +0200, Richard Biener wrote: > > On Thu, Apr 23, 2020 at 12:17 PM Segher Boessenkool > > wrote: > > > > > > On Thu, Apr 23, 2020 at 09:32:37AM +0200, Richard Biener wrote: > > > > On Thu, Apr 23,

Re: [RFC] split pseudos during loop unrolling in RTL unroller

On Thu, Apr 23, 2020 at 12:17 PM Segher Boessenkool wrote: > > On Thu, Apr 23, 2020 at 09:32:37AM +0200, Richard Biener wrote: > > On Thu, Apr 23, 2020 at 12:31 AM Jeff Law wrote: > > > On Wed, 2020-04-22 at 15:50 -0500, Segher Boessenkool wrote: > > > > > > In some ways it feels like it would

Re: [RFC] split pseudos during loop unrolling in RTL unroller

On Wed, Apr 22, 2020 at 11:26 AM Richard Sandiford wrote: > > Richard Biener via Gcc-patches writes: > > On Mon, Apr 20, 2020 at 3:38 PM Segher Boessenkool > > wrote: > >> > >> Hi! > >> > >> On Mon, Apr 20, 2020 at 09:56:34AM +0200, Richard

Re: [PATCH] forwprop: Fix ICE when building an identity constructor [PR94700]

On Wed, Apr 22, 2020 at 10:31 AM Richard Sandiford wrote: > > This is really PR94683 part 2, handling the case in which the vector is > an identity and so doesn't need a VEC_PERM_EXPR. I should have realised > at the time that the other arm of the "if" would need the same fix. > > Tested on

Re: [PATCH] [Stage1] Refactor tree-ssa-operands.c

On Wed, Apr 22, 2020 at 8:40 PM Giuliano Belinassi wrote: > > This patch refactors tree-ssa-operands.c by wrapping the global > variables into a class, and also removes unused code. > > Just sending this for when Stage1 is back again. > > I ran the testsuite and bootstraped in a x86_64 linux

Re: [RFC] split pseudos during loop unrolling in RTL unroller

On Thu, Apr 23, 2020 at 12:31 AM Jeff Law wrote: > > On Wed, 2020-04-22 at 15:50 -0500, Segher Boessenkool wrote: > > > > > > In some ways it feels like it would be easier to resurrect RTL SSA :-) > > > > Why was RTL SSA abandoned? > > > > It might well work to keep everything in SSA form all the

Re: [PATCH PR94708] rtl combine should consider NaNs when generate fp min/max

On Thu, Apr 23, 2020 at 10:42 AM Zhanghaijian (A) wrote: > > Hi > > This is a simple fix for pr94708. > It's unsafe for rtl combine to generate fp min/max under > -funsafe-math-optimizations, considering NaNs. > We can only do this kind of transformation under -funsafe-math-optimizations > and

Re: [RFC] split pseudos during loop unrolling in RTL unroller

On Thu, Apr 23, 2020 at 2:52 PM Segher Boessenkool wrote: > > On Thu, Apr 23, 2020 at 02:25:40PM +0200, Richard Biener wrote: > > > > But being stuck with something means no progress... I know > > > > very well it's 100 times harder to get rid of something than to > > > > add something new

Re: [PATCH] var-tracking.c: Fix possible use of uninitialized variable pre

On Thu, Apr 30, 2020 at 5:14 PM Andreas Krebbel wrote: > > On 30.04.20 08:25, Richard Biener via Gcc-patches wrote: > > On Wed, Apr 29, 2020 at 5:56 PM Jeff Law wrote: > >> > >> On Tue, 2020-04-28 at 11:44 +0200, Richard Biener via Gcc-patches wrote: > >&g

Re: [PATCH] c-attribs.c: Fix use of uninitialized variable nunits

On Mon, May 4, 2020 at 1:44 PM Stefan Schulze Frielinghaus wrote: > > On Tue, Apr 28, 2020 at 08:27:12PM +0200, Stefan Schulze Frielinghaus wrote: > > On Tue, Apr 28, 2020 at 11:33:31AM +0200, Richard Biener wrote: > > > On Tue, Apr 28, 2020 at 10:03 AM Stefan Schulze Frielinghaus via > > >

Re: [PATCH] internal-fn: Avoid dropping the lhs of some calls [PR94941]

On Mon, May 4, 2020 at 2:55 PM Richard Sandiford wrote: > > create_output_operand coerces an output operand to the insn's > predicates, using a suggested rtx location if convenient. > But if that rtx location is actually required rather than > optional, the builder of the insn has to emit a move

Re: [PATCH] var-tracking.c: Fix possible use of uninitialized variable pre

On Mon, May 4, 2020 at 8:14 AM Andreas Krebbel wrote: > > On 30.04.20 18:33, Richard Biener wrote: > > On Thu, Apr 30, 2020 at 5:14 PM Andreas Krebbel > > wrote: > >> > >> On 30.04.20 08:25, Richard Biener via Gcc-patches wrote: > >>>

Re: (patch] Do not put incomplete CONSTRUCTORs into static memory

On Tue, May 5, 2020 at 10:30 AM Eric Botcazou wrote: > > Hi, > > the CONSTRUCTOR_NO_CLEARING flag was invented to avoid generating a memset for > CONSTRUCTORS that lack elements, but it turns out that the gimplifier can > generate a memcpy for them instead, which is even worse performance-wise,

Re: [patch] Silence warning in LTO mode on VxWorks

On Tue, May 5, 2020 at 10:36 AM Eric Botcazou wrote: > > Hi, > > the link phase is always partial (-r) for VxWorks in kernel mode, which means > that it uses incremental LTO linking by default (-flinker-output=rel). But in > this mode the LTO plugin outputs a warning if one of the object files

Re: [patch] Silence warning in LTO mode on VxWorks

On Tue, May 5, 2020 at 11:16 AM Eric Botcazou wrote: > > > I know it's hidden but can we make the plugin option more specific, > > like -linker-output-auto-notlo-rel? There's also no documentation for > > the lto-plugin switches, I think a good place is a comment before > > > > + else if

Re: [PATCH] c-attribs.c: Fix use of uninitialized variable nunits

On Tue, Apr 28, 2020 at 10:03 AM Stefan Schulze Frielinghaus via Gcc-patches wrote: > > In function handle_vector_size_attribute local variable nunits is > supposed to be initialized by function type_valid_for_vector_size. > However, in case ARGS is null the function may return with a non-null >

Re: [RFC] Clarify -ffinite-math-only documentation

> "Dr. Matthias Kretz" writes: > > > > > On Montag, 27. April 2020 18:59:08 CEST Richard Sandiford wrote: > > > > >> Richard Biener via Gcc-patches writes: > > > > >> > On Mon, Apr 27, 2020 at 6:09 PM Matthias Kretz >

Re: [PATCH] var-tracking.c: Fix possible use of uninitialized variable pre

On Tue, Apr 28, 2020 at 11:28 AM Stefan Schulze Frielinghaus via Gcc-patches wrote: > > While bootstrapping GCC on S/390 the following warning/error is raised: > > gcc/var-tracking.c:10239:34: error: 'pre' may be used uninitialized in this > function [-Werror=maybe-uninitialized] > 10239 |

Re: [PATCH, vect] Check alignment for no peeling gaps handling

On Fri, Apr 10, 2020 at 11:28 AM Kewen.Lin wrote: > > Hi, > > This is one fix following Richi's comments here: > https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542232.html > > I noticed the current half vector support for no peeling gaps > handled some cases which never check the half size

Re: [PATCH] Check whether -fcf-protection=none -Wl, -z, ibt, -z, shstk work first

On Mon, Apr 27, 2020 at 8:13 PM H.J. Lu via Gcc-patches wrote: > > GCC_CET_HOST_FLAGS uses -Wl,-z,ibt,-z,shstk to check if Linux/x86 host > has Intel CET enabled by introducing an Intel CET violation on purpose. > To avoid false positive, check whether -Wl,-z,ibt,-z,shstk works first. >

  1   2   3   4   5   6   7   8   9   10   >