Re: [PATCH 1/2] rs6000: tune cunroll for simple loops at O2

Richard Biener writes: > On Wed, May 27, 2020 at 6:36 AM Jiufu Guo wrote: >> >> Segher Boessenkool writes: >> >> > Hi! >> > >> > On Tue, May 26, 2020 at 08:58:13AM +0200, Richard Biener wrote: >> >> On Mon, May 25, 2020 at 7:44 PM Segher Boessenkool >> >> wrote: >> >> > Yes, cunroll does not h

[PATCH] testsuite/95363 - fix gcc.dg/vect/bb-slp-pr95271.c for ilp32

This fixes the testcase to avoid out of bound shifts on ilp32 targets. 2020-05-28 Richard Biener PR testsuite/95363 * gcc.dg/vect/bb-slp-pr95271.c: Fix on ilp32 targets. --- gcc/testsuite/gcc.dg/vect/bb-slp-pr95271.c | 17 ++--- 1 file changed, 10 insertions(+), 7

Re: [PATCH] mklog: support renaming of files

On 5/27/20 8:15 PM, Martin Liška wrote: The support is optional and detected during run-time. Thoughts? Pushed as eb78da45ab8. Martin

[PATCH 2/2] rs6000: allow cunroll to grow size according to -funroll-loop or -fpeel-loops

From: Jiufu Guo Previously, flag_unroll_loops was turned on at -O2 implicitly. It also turned on cunroll with allowance size increasing, and then cunroll will unroll/peel the loop even the loop is complex like code in PR95018. With this patch, size growth for cunroll is allowed if -funroll-loops

[PATCH 1/2] Introduce flag_cunroll_grow_size for cunroll

From: Jiufu Guo Currently GIMPLE complete unroller(cunroll) is checking flag_unroll_loops and flag_peel_loops to see if allow size growth. Beside affects curnoll, flag_unroll_loops also controls RTL unroler. To have more freedom to control cunroll and RTL unroller, this patch introduces flag_cunr

[PATCH] Fix check-params-in-docs.py for --help=param.

Updated to current help format and pushed to master. Martin contrib/ChangeLog: * check-params-in-docs.py: Update to new format of help. Apply flake8 corrections. --- contrib/check-params-in-docs.py | 17 ++--- 1 file changed, 10 insertions(+), 7 deletions(-) diff

[PATCH] Add documentation for missing params.

The patch fixes various issues spotted by check-params-in-docs.py script. I'm going to install the patch. gcc/ChangeLog: PR web/95380 * doc/invoke.texi: Add missing params, remove max-once-peeled-insns and rename ipcp-unit-growth to ipa-cp-unit-growth. --- gcc/doc/invoke

Re: [PATCH] gcc-changelog: enhance handling of renamings

On 27/05/2020 19:50, Martin Liška wrote: Thank you very much for working on this! It's a good idea that's currently not supported. You are welcome, I’m glad to contribute. :-) However, this is available for unidiff package starting from version 0.6.0. With a bit older release I see:   

Re: [PATCH] gcc-changelog: enhance handling of renamings

On 5/28/20 11:05 AM, Pierre-Marie de Rodat wrote: Thanks! The updated patch is attached. The patch is fine, please install it. Thanks, Martin

Re: [PATCH] gcc-changelog: enhance handling of renamings

On 28/05/2020 11:09, Martin Liška wrote: On 5/28/20 11:05 AM, Pierre-Marie de Rodat wrote: Thanks! The updated patch is attached. The patch is fine, please install it. Now pushed. Thank you again. -- Pierre-Marie de Rodat

[PATCH] arm: Fix unwanted fall-throughs in arm.c

Hi all, this small patch fix some unintentional fall-throughs in `mve_vector_mem_operand'. Regtested and bootstraped on arm-linux-gnueabihf. Okay for trunk? Regards Andrea gcc/ChangeLog 2020-05-28 Andrea Corallo * config/arm/arm.c (mve_vector_mem_operand): Fix unwanted

RE: [PATCH] arm: Fix unwanted fall-throughs in arm.c

> -Original Message- > From: Andrea Corallo > Sent: 28 May 2020 10:20 > To: gcc Patches > Cc: nd ; Kyrylo Tkachov ; Richard > Earnshaw > Subject: [PATCH] arm: Fix unwanted fall-throughs in arm.c > > Hi all, > > this small patch fix some unintentional fall-throughs in > `mve_vector_m

Re: [PATCH] arm: Fix unwanted fall-throughs in arm.c

Kyrylo Tkachov writes: >> -Original Message- >> From: Andrea Corallo >> Sent: 28 May 2020 10:20 >> To: gcc Patches >> Cc: nd ; Kyrylo Tkachov ; Richard >> Earnshaw >> Subject: [PATCH] arm: Fix unwanted fall-throughs in arm.c >> >> Hi all, >> >> this small patch fix some unintentional f

[PATCH] tree-optimization/95273 - more vectorizable_shift massaging

Covering all bases in vectorizable_shift is hard - this makes sure to appropriately handle the case of PR95356 without breaking others. Bootstrapped / tested on x86_64-unknown-linux-gnu, applied. 2020-05-28 Richard Biener PR tree-optimization/95273 PR tree-optimization/95356

Re: [PATCH 1/2] Introduce flag_cunroll_grow_size for cunroll

On Thu, May 28, 2020 at 10:52 AM guojiufu wrote: > > From: Jiufu Guo > > Currently GIMPLE complete unroller(cunroll) is checking > flag_unroll_loops and flag_peel_loops to see if allow size growth. > Beside affects curnoll, flag_unroll_loops also controls RTL unroler. > To have more freedom to co

Re: [PATCH 1/2] [aarch64] Rework fpcr fpsr getter/setter builtins

Andrea Corallo writes: > Hi all, > > I'd like to submit this patch introducing the following 64bit builtins > variants as FPCR and FPSR registers getter/setter: > > unsigned long long __builtin_aarch64_get_fpcr64 () > void __builtin_aarch64_set_fpcr64 (unsigned long long) > unsigned long long __b

Re: Ping^1 [PATCH 2/4 V3] Add target hook stride_dform_valid_p

"Kewen.Lin" writes: > Hi, > > Gentle ping patches as below: > > 1/4 v3 https://gcc.gnu.org/pipermail/gcc-patches/2020-February/540171.html > 2/4 v3 https://gcc.gnu.org/pipermail/gcc-patches/2020-March/541387.html > 3/4 v3 https://gcc.gnu.org/pipermail/gcc-patches/2020-May/545643.html > > Or shall

[WIKI] Replace delta with C-Vise (and C-Reduce)

Hello. I've spent quite some time working of a super-parallel reduction tool and I would like to promote it ;) Moreover, delta website is down and it should be replaced: [1]. There's updated wording of the following WIKI page: https://gcc.gnu.org/wiki/A_guide_to_testcase_reduction For all delta

[PATCH][GCC] arm: Fix the MVE ACLE vbicq intrinsics.

Hello, Following MVE intrinsic testcases are failing in GCC testsuite. Directory: gcc.target/arm/mve/intrinsics/ Testcases: vbicq_f16.c, vbicq_f32.c, vbicq_s16.c, vbicq_s32.c, vbicq_s8.c ,vbicq_u16.c, vbicq_u32.c and vbicq_u8.c. This patch fixes the vbicq intrinsics by modifying the intrinsic pa

Re: [WIKI] Replace delta with C-Vise (and C-Reduce)

Hi, On Thu, May 28 2020, Martin Liška wrote: > Hello. > > I've spent quite some time working of a super-parallel reduction tool > and I would like to promote it ;) Moreover, delta website is down and > it should be replaced: [1]. > > There's updated wording of the following WIKI page: > https://gc

[PATCH] remove obsolete code from SLP invariant costing

This removes handling of !SLP_TREE_VECTYPE from invariant costing. The single caller guards against this case already. 2020-05-28 Richard Biener * tree-vect-slp.c (vect_prologue_cost_for_slp): Remove case for !SLP_TREE_VECTYPE. (vect_slp_analyze_node_operations): Adjust

Re: [PATCH] gcc-changelog: enhance handling of renamings

On Thu, May 28, 2020 at 11:09:41AM +0200, Martin Liška wrote: > On 5/28/20 11:05 AM, Pierre-Marie de Rodat wrote: > > Thanks! The updated patch is attached. > > The patch is fine, please install it. I'd like to mention that for file renames, perhaps it is acceptable not to have a ChangeLog entry

Re: [WIKI] Replace delta with C-Vise (and C-Reduce)

Hi Martin, On 5/28/20 1:17 PM, Martin Jambor wrote: On Thu, May 28 2020, Martin Liška wrote: Hello. I've spent quite some time working of a super-parallel reduction tool and I would like to promote it ;) Moreover, delta website is down and it should be replaced: [1]. It is not completely clea

Re: [PATCH] gcc-changelog: enhance handling of renamings

On 5/28/20 1:20 PM, Jakub Jelinek wrote: On Thu, May 28, 2020 at 11:09:41AM +0200, Martin Liška wrote: On 5/28/20 11:05 AM, Pierre-Marie de Rodat wrote: Thanks! The updated patch is attached. The patch is fine, please install it. I'd like to mention that for file renames, perhaps it is acce

[PATCH 0/4] IVOPTs consider step cost for different forms when unrolling

Hi, This is one repost and you can refer to the original series via https://gcc.gnu.org/pipermail/gcc-patches/2020-January/538360.html. As we discussed in the thread https://gcc.gnu.org/ml/gcc-patches/2020-01/msg00196.html Original: https://gcc.gnu.org/ml/gcc-patches/2020-01/msg00104.html, I'm w

[PATCH 1/4] unroll: Add middle-end unroll factor estimation

gcc/ChangeLog 2020-MM-DD Kewen Lin * cfgloop.h (struct loop): New field estimated_unroll. * tree-ssa-loop-manip.c (decide_unroll_const_iter): New function. (decide_unroll_runtime_iter): Likewise. (decide_unroll_stupid): Likewise. (estimate_unroll_factor

[committed] aarch64: Fix segfault in aarch64_expand_epilogue [PR95361]

The stack frame for the function in the testcase consisted of two SVE save slots. Both saves had been shrink-wrapped, but for different blocks, meaning that the stack allocation and deallocation were separate from the saves themselves. Before emitting the deallocation, we tried to attach a REG_CF

[committed] aarch64: Fix missed shrink-wrapping opportunity

wb_candidate1 and wb_candidate2 exist for two overlapping cases: when we use an STR or STP with writeback to allocate the frame, and when we set up a frame chain record (either using writeback allocation or not). However, aarch64_layout_frame was leaving these fields with legitimate register numbe

[PATCH 2/4] param: Introduce one param to control ivopts reg-offset consideration

gcc/ChangeLog 2020-MM-DD Kewen Lin * doc/invoke.texi (iv-consider-reg-offset-for-unroll): Document new option. * params.opt (iv-consider-reg-offset-for-unroll): New. * config/s390/s390.c (s390_option_override_internal): Disable parameter iv-consider-reg-offset

[PATCH 0/4] Make IPA-SRA not depend on tree-dce and related fixes

Hi, this patch series addresses PR 93385 which exposed that the new IPA-SRA depends on tree-dce and can leave misbehaving instructions behind if the user switched it off. It is a series because I also tried to produce the best debug info possible in such cases while avoiding unnecessary copying o

[PATCH 3/4] ivopts: Consider cost_step on different forms during unrolling

gcc/ChangeLog 2020-MM-DD Kewen Lin * tree-ssa-loop-ivopts.c (struct iv_group): New field reg_offset_p. (struct iv_cand): New field reg_offset_p. (struct ivopts_data): New field consider_reg_offset_for_unroll_p. (dump_groups): Dump group with reg_offset_p.

[PATCH 1/4] ipa-sra: Do not remove statements necessary because of non-call EH (PR 95113)

PR 95113 revealed that when reasoning about which parameters are dead, IPA-SRA does not perform the same check related to non-call exceptions as tree DCE. It most certainly should and so this patch moves the condition used in tree-ssa-dce.c into a separate predicate (in tree-eh.c) and uses it from

[PATCH 3/4] ipa-sra: Improve debug info for removed parameters (PR 93385)

Whereas the previous patch fixed issues with code left behind after IPA-SRA removed a parameter but only reset all affected debug bind statements, this one updates them with expressions which can allow the debugger to print the removed value - see the added test-case. Even though I originally did

[PATCH 4/4] ipa-sra: Fix debug info for removed args passed to other functions (PR 93385, 95343)

This patch arguably finishes what I was asked to do in bugzilla PR 93385 and remaps *all* occurrences of SSA names discovered to be dead in the process of parameter removal during clone materialization either to error_mark_node or to DEBUG_EXPR_DECL that represents the removed value - including tho

[PATCH 2/4] ipa-sra: Introduce a mini-DCE to tree-inline.c (PR 93385)

PR 93385 reveals that if the user explicitely disables DCE, IPA-SRA can leave behind statements which are useless because their results are eventually not used but can have problematic side effects, especially since their inputs are now bogus that useless parameters were removed. This patch fixes

Re: [WIKI] Replace delta with C-Vise (and C-Reduce)

On 5/28/20 1:17 PM, Martin Jambor wrote: I don't think you need to seek approval to edit wiki pages and putting c-vise instructions at the top of that page is definitely the right thing to do. All right. On the other hand, I would not remove the delta and multidelta sections but rather move

Re: [WIKI] Replace delta with C-Vise (and C-Reduce)

On 5/28/20 1:26 PM, Tobias Burnus wrote: It is not completely clear to me whether C-Vise also works with Fortran; Yes, it works. Some C/C++-related passes are skipped, but it works. Martin

[DOC] Mention C-Vise and C-Reduce instead of Delta.

Hi. I've just updated https://gcc.gnu.org/wiki/A_guide_to_testcase_reduction and I'm changing link to the WIKI page. Martin --- htdocs/bugs/minimize.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/htdocs/bugs/minimize.html b/htdocs/bugs/minimize.html index 6197169a..45

RE: [PATCH PR95254] aarch64: gcc generate inefficient code with fixed sve vector length

Hi, > -Original Message- > From: Richard Sandiford [mailto:richard.sandif...@arm.com] > Sent: Thursday, May 28, 2020 12:07 AM > To: Yangfei (Felix) > Cc: gcc-patches@gcc.gnu.org > Subject: Re: [PATCH PR95254] aarch64: gcc generate inefficient code with > fixed sve vector length > Snip..

Re: [PATCH] extend cselim to check non-trapping for more references (PR tree-optimizaton/89430)

On Wed, 27 May 2020, Hao Liu OS wrote: > Hi all, > > Previously, the fix for > PR89430 was > reverted by PR94734 > due to a bug. The root cause is missing non-trapping check with > domina

Re: [PATCH 1/2] rs6000: tune cunroll for simple loops at O2

On Wed, May 27, 2020 at 10:20:18AM +0200, Richard Biener wrote: > > How about "Var(flag_cunroll_grow_size) EnabledBy(funroll-loops || > > funroll-all-loops || fpeel-loops)" Or flag_cunroll_allow_grow_size? > > > > And then using this flags as: > > unsigned int val = tree_unroll_loops_completely (

Re: [PATCH 1/2] Introduce flag_cunroll_grow_size for cunroll

On Thu, May 28, 2020 at 12:01:26PM +0200, Richard Biener wrote: > On Thu, May 28, 2020 at 10:52 AM guojiufu wrote: > > --- a/gcc/common.opt > > +++ b/gcc/common.opt > > @@ -2856,6 +2856,10 @@ funroll-all-loops > > Common Report Var(flag_unroll_all_loops) Optimization > > Perform loop unrolling f

Re: [pushed] c++: Handle multiple aggregate overloads [PR95319].

On Wed, May 27, 2020 at 12:07 PM Jason Merrill via Gcc-patches wrote: > > Here, when considering the two 'insert' overloads, we look for aggregate > conversions from the same initializer-list to B<3> or > initializer_list>. But since my fix for reshape_init overhead on the > PR14179 testcase we r

Re: [PATCH 2/2] rs6000: allow cunroll to grow size according to -funroll-loop or -fpeel-loops

Hi Jiufu, On Thu, May 28, 2020 at 04:52:07PM +0800, guojiufu wrote: > gcc/ChangeLog > 2020-02-28 Jiufu Guo > > PR target/95018 > * config/rs6000/rs6000.c (rs6000_option_override_internal): > Override flag_cunroll_grow_size. This part is fine of course. Thanks! Segher

Re: [pushed] c++: Handle multiple aggregate overloads [PR95319].

On Thu, May 28, 2020 at 06:44:53AM -0700, H.J. Lu via Gcc-patches wrote: > On Wed, May 27, 2020 at 12:07 PM Jason Merrill via Gcc-patches > wrote: > > > > Here, when considering the two 'insert' overloads, we look for aggregate > > conversions from the same initializer-list to B<3> or > > initiali

Re: [pushed] c++: Handle multiple aggregate overloads [PR95319].

On Thu, May 28, 2020 at 6:57 AM Marek Polacek wrote: > > On Thu, May 28, 2020 at 06:44:53AM -0700, H.J. Lu via Gcc-patches wrote: > > On Wed, May 27, 2020 at 12:07 PM Jason Merrill via Gcc-patches > > wrote: > > > > > > Here, when considering the two 'insert' overloads, we look for aggregate > >

Re: [patch] Add support for __builtin_bswap128

On Wed, May 27, 2020 at 8:26 AM Richard Biener via Gcc-patches wrote: > > On Wed, May 27, 2020 at 3:33 PM Eric Botcazou wrote: > > > > > Please use int128 effective target rather than lp64 in the tests that need > > > __int128 type. > > > > OK, thanks, adjusted locally. > > OK. I am checking in

Re: [pushed] c++: Handle multiple aggregate overloads [PR95319].

On Thu, May 28, 2020 at 07:05:47AM -0700, H.J. Lu wrote: > On Thu, May 28, 2020 at 6:57 AM Marek Polacek wrote: > > > > On Thu, May 28, 2020 at 06:44:53AM -0700, H.J. Lu via Gcc-patches wrote: > > > On Wed, May 27, 2020 at 12:07 PM Jason Merrill via Gcc-patches > > > wrote: > > > > > > > > Here,

Re: [PATCH 1/2] Seperate -funroll-loops for GIMPLE unroller and RTL unroller

On Tue, May 26, 2020 at 6:58 AM Jiufu Guo wrote: > > David Edelsohn writes: > > > On Mon, May 25, 2020 at 1:58 PM Richard Biener > > wrote: > >> > >> On May 25, 2020 7:40:00 PM GMT+02:00, Segher Boessenkool > >> wrote: > >> >On Mon, May 25, 2020 at 02:14:02PM +0200, Richard Biener wrote: > >>

Re: [patch] Add support for __builtin_bswap128

On Thu, May 28, 2020 at 07:10:20AM -0700, H.J. Lu via Gcc-patches wrote: > On Wed, May 27, 2020 at 8:26 AM Richard Biener via Gcc-patches > wrote: > > > > On Wed, May 27, 2020 at 3:33 PM Eric Botcazou wrote: > > > > > > > Please use int128 effective target rather than lp64 in the tests that > >

Re: [patch] Add support for __builtin_bswap128

On 5/28/20 4:30 PM, Marek Polacek via Gcc-patches wrote: On Thu, May 28, 2020 at 07:10:20AM -0700, H.J. Lu via Gcc-patches wrote: On Wed, May 27, 2020 at 8:26 AM Richard Biener via Gcc-patches wrote: On Wed, May 27, 2020 at 3:33 PM Eric Botcazou wrote: Please use int128 effective target r

Re: [patch] Add support for __builtin_bswap128

On Thu, May 28, 2020 at 7:30 AM Marek Polacek wrote: > > On Thu, May 28, 2020 at 07:10:20AM -0700, H.J. Lu via Gcc-patches wrote: > > On Wed, May 27, 2020 at 8:26 AM Richard Biener via Gcc-patches > > wrote: > > > > > > On Wed, May 27, 2020 at 3:33 PM Eric Botcazou > > > wrote: > > > > > > > >

Re: [PATCH 1/2] Introduce flag_cunroll_grow_size for cunroll

Richard Biener writes: > On Thu, May 28, 2020 at 10:52 AM guojiufu wrote: >> >> From: Jiufu Guo >> >> Currently GIMPLE complete unroller(cunroll) is checking >> flag_unroll_loops and flag_peel_loops to see if allow size growth. >> Beside affects curnoll, flag_unroll_loops also controls RTL unro

[AArch64][GCC-8][GCC-9] Use __getauxval instead of getauxval in LSE detection code in libgcc

The patch applies cleanly on gcc-9 and gcc-8. I bootstrapped this on aarch64-none-linux-gnu and tested aarch64-none-elf for both. Is this OK for those backports? libgcc/ChangeLog: 2020-05-28  Andre Vieira      Backport from mainline.     2020-05-06  Kyrylo Tkachov      * config/aarch64/lse

RE: [AArch64][GCC-8][GCC-9] Use __getauxval instead of getauxval in LSE detection code in libgcc

Hi Andre, > -Original Message- > From: Andre Vieira (lists) > Sent: 28 May 2020 15:42 > To: gcc-patches@gcc.gnu.org > Cc: Kyrylo Tkachov > Subject: [AArch64][GCC-8][GCC-9] Use __getauxval instead of getauxval in > LSE detection code in libgcc > > The patch applies cleanly on gcc-9 and g

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

Hi. There's a new patch that adds normal internal functions for the 4 VCOND* functions. The patch that survives bootstrap and regression tests on x86_64-linux-gnu and ppc64le-linux-gnu. Thoughts? Martin >From 9a8880a601c7820eb2d0c9104367ea454571681e Mon Sep 17 00:00:00 2001 From: Martin Liska

Re: [PATCH] [aarch64] Fix PR94591: GCC generates invalid rev64 insns

On 19/05/2020 17:59, Richard Sandiford wrote: > Alex Coplan writes: > > Hello, > > > > This patch fixes PR94591. The problem was the function > > aarch64_evpc_rev_local() > > matching vector permutations that were not reversals. In particular, prior > > to > > this patch, this function matched t

Re: [PATCH 1/2] Introduce flag_cunroll_grow_size for cunroll

On Thu, May 28, 2020 at 4:37 PM Jiufu Guo wrote: > > Richard Biener writes: > > > On Thu, May 28, 2020 at 10:52 AM guojiufu wrote: > >> > >> From: Jiufu Guo > >> > >> Currently GIMPLE complete unroller(cunroll) is checking > >> flag_unroll_loops and flag_peel_loops to see if allow size growth.

Re: [PATCH PR95254] aarch64: gcc generate inefficient code with fixed sve vector length

"Yangfei (Felix)" writes: > Thanks for reviewing this. > Attached please find the v5 patch. > Note: we also need to modify local variable "mode" once we catch one case. I > see test failure without this change. Looks good. Patch is OK assuming the x86 folks don't want to rewrite gcc.target/i38

Re: [pushed] c++: Handle multiple aggregate overloads [PR95319].

On Thu, May 28, 2020 at 10:16 AM Marek Polacek wrote: > On Thu, May 28, 2020 at 07:05:47AM -0700, H.J. Lu wrote: > > On Thu, May 28, 2020 at 6:57 AM Marek Polacek > wrote: > > > > > > On Thu, May 28, 2020 at 06:44:53AM -0700, H.J. Lu via Gcc-patches > wrote: > > > > On Wed, May 27, 2020 at 12:07

[PATCH] c++: lambdas inside constraints [PR92652]

When parsing a constraint-expression, a requires-clause or a requires-expression, we temporarily increment processing_template_decl so that we always obtain template trees which we later reduce via substitution even when not inside a template. But incrementing processing_template_decl when we're a

[PATCH]: aarch64: add support for unpacked EOR, ORR and AND

From: Joe Ramsay Date: Thursday, 28 May 2020 at 16:19 To: Gcc-patches Subject: [PATCH]: aarch64: add support for unpacked EOR, ORR and AND Hi! This patch improves code generation for EOR, ORR and AND on unpacked vectors with SVE. The following function: void f (unsigned int *x, unsigned shor

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

Martin Liška writes: > Hi. > > There's a new patch that adds normal internal functions for the 4 > VCOND* functions. > > The patch that survives bootstrap and regression > tests on x86_64-linux-gnu and ppc64le-linux-gnu. I think this has the same problem as the previous one. What I meant in yest

Re: [PATCH PR95254] aarch64: gcc generate inefficient code with fixed sve vector length

On Thu, May 28, 2020 at 8:00 AM Richard Sandiford wrote: > > "Yangfei (Felix)" writes: > > Thanks for reviewing this. > > Attached please find the v5 patch. > > Note: we also need to modify local variable "mode" once we catch one case. > > I see test failure without this change. > > Looks good.

[PATCH] doc: Clarify __builtin_return_address [PR94891]

The expected semantics and valid usage of __builtin_return_address is not clear since it exposes implementation internals that are normally not meaningful to portable c code. This documentation change tries to clarify the semantics in case the return address is stored in a mangled form in memory w

Re: [PATCH] doc: Clarify __builtin_return_address [PR94891]

* Szabolcs Nagy: > diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi > index cced19d2018..0fd32a22599 100644 > --- a/gcc/doc/extend.texi > +++ b/gcc/doc/extend.texi > On some machines it may be impossible to determine the return address of > any function other than the current one; in such

[PATCH] S/390: Emit vector alignment hints for z13

Vector alignment hints are fully supported since z14. On z13 alignment hints have no effect, however, instructions with alignment hints are still legal. Thus, emit alignment hints also for z13 targets so that if the binary is actually run on a z14 or later it benefits from such hints. Note, this

Re: [PATCH] S/390: Emit vector alignment hints for z13

Forgot to mention: Bootstrapped and regtested on z13 and z14 with gas including f687f5f563 Ok for master? On Thu, May 28, 2020 at 08:24:26PM +0200, Stefan Schulze Frielinghaus via Gcc-patches wrote: > Vector alignment hints are fully supported since z14. On z13 alignment > hints have no effect

[committed] Fix incorrect code on H8/SX with bit logicals

The H8/SX has some extended capabilities for bit-and, bit-ior and bit-xor compared to earlier processors in the H8 family and thus there's some special patterns to handle them. THe instructions work on byte sized chunks, but GCC is exposing them in HImode as well. It looks like someone tried to

Re: [PATCH 1/2] Seperate -funroll-loops for GIMPLE unroller and RTL unroller

Hi! On Thu, May 28, 2020 at 04:22:16PM +0200, Richard Biener wrote: > For GIMPLE level transforms I don't think targets have more knowledge > than the middle-end. Yes, certainly. > In fact GIMPLE complete unrolling is about > secondary effects, removing redundancies and abstraction. So IMHO > t

Aw: [PATCH, committed] [9/10/11 Regression] PR fortran/95104 - Segfault on a legal WAIT statement

The fix for > PR fortran/95104 - Segfault on a legal WAIT statement > > Referencing a unit in a WAIT statement that has not been opened before > resulted in a NULL pointer dereference. Check for this condition. > > 2020-05-26 Harald Anlauf > > libgfortran/ > PR libfortran/95104 > *

Re: [PATCH, committed] [9/10/11 Regression] PR fortran/95104 - Segfault on a legal WAIT statement

Hi Harald, There are two possible fixes for this: (1) guard the call to unlock_unit by: diff --git a/libgfortran/io/transfer.c b/libgfortran/io/transfer.c index cd51679ff46..296be0711a2 100644 --- a/libgfortran/io/transfer.c +++ b/libgfortran/io/transfer.c @@ -4508,7 +4508,8 @@ st_wait_async (

[pushed] c++: Immediately deduce auto member [PR94926].

In r9-297 I was trying to be more flexible and treat static data members of class templates more like variable templates, where the type need not be determined until the variable is instantiated, but I suppose that in a class the types of all the non-template members need to be determined at the ti

Re: [PATCH] Port libgccjit to Windows.

On Wed, 2020-05-27 at 22:27 -0300, Nicolas Bértolo wrote: > Hi, > > > Do you have commit/push access to the gcc repository? > > No I don't. > > > BTW, why isn't it necessary to use --enable-host-shared in Windows? > > Can we document that? > > That's because all code is position independent in

Re: [PATCH] Port libgccjit to Windows.

> I'm going to have to trust your Windows expertise here; the tempdir > code looks convoluted to me, but perhaps that's the only way to do it. > (Microsoft's docs for "SECURITY_ATTRIBUTES" suggest to me that if > lpSecurityDescriptor is NULL, then the directory gets a default > security descriptor,

Re: [PATCH, committed] [9/10/11 Regression] PR fortran/95104 - Segfault on a legal WAIT statement

Dear all, > I think the second one is more robust - like you say, this may catch > other cases. If we have that one, we don't need the first one. to fix the fallout I've committed to master the following patch, which I will backport to the affected branches (9/10): PR fortran/95104 - Segfault

[PATCH, committed] PR fortran/95373 - [9/10/11 Regression] ICE in build_reference_type, at tree.c:7942

The obvious patch attached was already OKed in the PR by Steve Kargl. As it is a 9/10/11 regression, I will backport it in a few days. Thanks, Harald PR fortran/95373 - [9/10/11 Regression] ICE in build_reference_type, at tree.c:7942 The use of KIND, LEN, RE, and IM inquiry references for appl

Re: [PATCH] c++: lambdas inside constraints [PR92652]

On 5/28/20 11:03 AM, Patrick Palka wrote: When parsing a constraint-expression, a requires-clause or a requires-expression, we temporarily increment processing_template_decl so that we always obtain template trees which we later reduce via substitution even when not inside a template. But increm

Re: [PATCH] c++: constexpr RANGE_EXPR ctor indexes [PR95241]

On 5/27/20 5:15 PM, Patrick Palka wrote: On Wed, 27 May 2020, Patrick Palka wrote: On Wed, 27 May 2020, Patrick Palka wrote: In the testcase below, the CONSTRUCTOR for 'field' contains a RANGE_EXPR index: {aggr_init_expr<...>, [1...2]={.off=1}} but get_or_insert_ctor_field isn't prepared

Re: [PATCH] Port libgccjit to Windows.

On Thu, 2020-05-28 at 16:51 -0300, Nicolas Bértolo wrote: > > I'm going to have to trust your Windows expertise here; the tempdir > > code looks convoluted to me, but perhaps that's the only way to do > it. > > (Microsoft's docs for "SECURITY_ATTRIBUTES" suggest to me that if > > lpSecurityDescript

Re: [PATCH] c++: Try to complete decomp types [PR95328]

On 5/27/20 4:50 AM, Jakub Jelinek wrote: Hi! Two years ago Paolo has added the else if (processing_template_decl && !COMPLETE_TYPE_P (type)) pedwarn (...); lines into cp_finish_decomp. For type dependent decl we punt much earlier, but even for types which aren't type dependent COMPLETE_

Re: [PATCH] c++: Fix bogus -Wparentheses warning [PR95344]

On 5/26/20 8:25 PM, Marek Polacek wrote: Since r267272, which added location wrappers, cp_fold loses TREE_NO_WARNING on a MODIFY_EXPR that finish_parenthesized_expr set, and that results in a bogus -Wparentheses warning. I.e., previously we had "b = 1" but now we have "VIEW_CONVERT_EXPR(b) = 1"

Re: [PATCH v2] c++: Fix bogus -Wparentheses warning [PR95344]

On Thu, May 28, 2020 at 05:01:51PM -0400, Jason Merrill wrote: > On 5/26/20 8:25 PM, Marek Polacek wrote: > > Since r267272, which added location wrappers, cp_fold loses > > TREE_NO_WARNING on a MODIFY_EXPR that finish_parenthesized_expr set, and > > that results in a bogus -Wparentheses warning. >

[OBSOLETE][PATCH] PR preprocessor/94657: use $AR, not 'ar',

On Thu, 7 May 2020 08:18:31 +0100 Sergei Trofimovich via Gcc-patches wrote: > On Wed, 22 Apr 2020 23:05:38 +0100 > Sergei Trofimovich wrote: > > > From: Sergei Trofimovich > > > > On system with 'ar' and '${CHOST}-ar' the latter is preferred. > > as it might not match default 'ar'. > > > > B

[PATCH] diagnostics: Consistently add fixit hint for implicit builtin declaration

There are two warnings that might trigger when a builtin function is used but not declared yet. Both called through implicitly_declare in c-decl. The first in implicit_decl_warning does warn for builtins, but does not add a fixit hint for them (only for non-builtins when a header is suggested throu

[PATCH] c++: Make braced-init-list as template arg work with aggr init [PR95369]

Barry pointed out to me that our braced-init-list as a template-argument extension doesn't work as expected when we aggregate-initialize. Thus fixed by calling digest_init in convert_nontype_argument so that we can actually convert the CONSTRUCTOR. I don't think we can call digest_init any earlie

Re: [PATCH 2/2] Provide diagnostic hints for missing C++ cinttypes string constants.

Hi, On Mon, May 25, 2020 at 12:26:33PM -0400, Jason Merrill wrote: > On 5/23/20 8:30 PM, Mark Wielaard wrote: > > When reporting an error in cp_parser and we notice a string literal > > followed by an unknown name check whether there is a known standard > > header containing a string macro with th

Re: [PATCH] diagnostics: Consistently add fixit hint for implicit builtin declaration

On 5/28/20 5:16 PM, Mark Wielaard wrote: There are two warnings that might trigger when a builtin function is used but not declared yet. Both called through implicitly_declare in c-decl. The first in implicit_decl_warning does warn for builtins, but does not add a fixit hint for them (only for no

[PATCH] rs6000: libgcc multilib FAT libraries

When AIX added 64 bit support, it implemented what Apple MacOS Darwin calls "FAT" libraries for its equivalent functionality -- both 32 bit and 64 bit objects (or shared objects) are co-located in the same archive. GCC on AIX historically has followed the GCC multilib directory hierarchy approach

Re: [PATCH v3] Add -fuse-ld= to specify an arbitrary executable as the linker

On 2020-05-25, Martin Liška wrote: On 5/22/20 6:42 AM, Fangrui Song wrote: but I can't fix this one because joining two lines will break the 80-column  rule. What about this: diff --git a/gcc/collect2.c b/gcc/collect2.c index cc57a20e08b..e5b54b080f7 100644 --- a/gcc/collect2.c +++ b/gcc/coll

Re: [PATCH] diagnostics: Consistently add fixit hint for implicit builtin declaration

Hi Martin, On Thu, May 28, 2020 at 06:21:39PM -0600, Martin Sebor wrote: > Although few tests bother with it, since you add an option for > the existing warning where there was none before, an even more > exhaustive test than the one you added would also verify the same > option can be used to sup

[PATCH] Optimize and+or+sub into xor+not (PR94882)

Hi, Please find attached the patch that addresses PR94882. Bootstrapped and regression tested on x86_64-pc-linux-gnu. Thanks, Naveen match.pd: (x & y) - (x | y) - 1 -> ~(x ^ y) simplification [PR94882] 2029-05-04 Naveen H S PR tree-optimization/94882 * match.pd (x & y) - (

Re: [PATCH PR95254] aarch64: gcc generate inefficient code with fixed sve vector length

; > > > How can that happen? > > > > This is due to define_subst magic. The generators automatically > > create a vec_merge form of the instruction based on the information > > in the attributes. > > > > AFAICT the rtl above is for the line-125 instruct

Re: [PATCH 1/2] Seperate -funroll-loops for GIMPLE unroller and RTL unroller

Segher Boessenkool writes: > Hi! > > On Thu, May 28, 2020 at 04:22:16PM +0200, Richard Biener wrote: >> For GIMPLE level transforms I don't think targets have more knowledge >> than the middle-end. > > Yes, certainly. > >> In fact GIMPLE complete unrolling is about >> secondary effects, removing

Re: [PATCH 1/2] Introduce flag_cunroll_grow_size for cunroll

Richard Biener writes: > On Thu, May 28, 2020 at 4:37 PM Jiufu Guo wrote: >> >> Richard Biener writes: >> >> > On Thu, May 28, 2020 at 10:52 AM guojiufu wrote: >> >> >> >> From: Jiufu Guo >> >> >> >> Currently GIMPLE complete unroller(cunroll) is checking >> >> flag_unroll_loops and flag_peel

[PATCH v5 4/8] libstdc++ atomic_futex: Use std::chrono::steady_clock as reference clock

The user-visible effect of this change is that std::future::wait_for now uses std::chrono::steady_clock to determine the timeout. This makes it immune to changes made to the system clock. It also means that anyone using their own clock types with std::future::wait_until will have the timeout conv

[PATCH v5 5/8] libstdc++ futex: Loop when waiting against arbitrary clock

If std::future::wait_until is passed a time point measured against a clock that is neither std::chrono::steady_clock nor std::chrono::system_clock then the generic implementation of __atomic_futex_unsigned::_M_load_when_equal_until is called which calculates the timeout based on __clock_t and calls

[PATCH v5 8/8] libstdc++: Extra async tests, not for merging

These tests show that changing the system clock has an effect on std::future::wait_until when using std::chrono::system_clock but not when using std::chrono::steady_clock. Unfortunately these tests have a number of downsides: 1. Nothing that is attempting to keep the clock set correctly (ntpd,

[PATCH v5 1/8] libstdc++: Improve async test

Add tests for waiting for the future using both std::chrono::steady_clock and std::chrono::system_clock in preparation for dealing with those clocks properly in futex.cc. * libstdc++-v3/testsuite/30_threads/async/async.cc (test02): Test steady_clock with std::future::wait_until.

[PATCH v5 3/8] libstdc++ futex: Support waiting on std::chrono::steady_clock directly

The user-visible effect of this change is for std::future::wait_until to use CLOCK_MONOTONIC when passed a timeout of std::chrono::steady_clock type. This makes it immune to any changes made to the system clock CLOCK_REALTIME. Add an overload of __atomic_futex_unsigned::_M_load_and_text_until_imp

  1   2   >