[PATCH] testsuite: Fix c-c++-common/auto-init-* tests

2021-09-11 Thread Jakub Jelinek via Gcc-patches
On Fri, Sep 03, 2021 at 02:47:11PM +, Qing Zhao via Gcc-patches wrote: > > 2021-08-20 qing zhao > > > >* c-c++-common/auto-init-1.c: New test. > >* c-c++-common/auto-init-10.c: New test. > >* c-c++-common/auto-init-11.c: New test. > >* c-c++-common/auto-init-

Re: [PATCH 2/2] validate_subreg before call gen_lowpart to avoid ICE.

2021-09-11 Thread Richard Biener via Gcc-patches
On September 10, 2021 11:27:16 PM GMT+02:00, Segher Boessenkool wrote: >On Fri, Sep 10, 2021 at 08:36:12PM +0200, Richard Biener wrote: >> On September 10, 2021 6:24:50 PM GMT+02:00, Segher Boessenkool >> wrote: >> >Yes, we should not call TRULY_NOOP_TRUNCATION_MODES_P for any random two >> >mo

[PATCH] Refactor jump_thread_path_registry.

2021-09-11 Thread Aldy Hernandez via Gcc-patches
In an attempt to refactor thread_through_all_blocks(), I've realized that there is a mess of code dealing with coexisting forward and backward thread types. However, this is an impossible scenario, as the registry contains either forward/old-style threads, or backward threads (EDGE_FSM_THREADs), n

[PATCH] Also preserve SUBREG_PROMOTED_VAR_P in expr.c's convert_move.

2021-09-11 Thread Roger Sayle
This patch catches another place in the middle-end where it's possible to preserve the SUBREG_PROMOTED_VAR_P annotation on a subreg to the benefit of later RTL optimizations. This adds the same logic to expr.c's convert_move as recently added to convert_modes. On nvptx-none, the simple test prog

Re: [PATCH 2/2] validate_subreg before call gen_lowpart to avoid ICE.

2021-09-11 Thread Hongtao Liu via Gcc-patches
On Sat, Sep 11, 2021 at 4:25 PM Richard Biener via Gcc-patches wrote: > > On September 10, 2021 11:27:16 PM GMT+02:00, Segher Boessenkool > wrote: > >On Fri, Sep 10, 2021 at 08:36:12PM +0200, Richard Biener wrote: > >> On September 10, 2021 6:24:50 PM GMT+02:00, Segher Boessenkool > >> wrote:

Re: [PATCH 2/2] validate_subreg before call gen_lowpart to avoid ICE.

2021-09-11 Thread Hongtao Liu via Gcc-patches
On Sat, Sep 11, 2021 at 5:51 PM Hongtao Liu wrote: > > On Sat, Sep 11, 2021 at 4:25 PM Richard Biener via Gcc-patches > wrote: > > > > On September 10, 2021 11:27:16 PM GMT+02:00, Segher Boessenkool > > wrote: > > >On Fri, Sep 10, 2021 at 08:36:12PM +0200, Richard Biener wrote: > > >> On Septem

Re: [PATCH] testsuite: Fix c-c++-common/auto-init-* tests

2021-09-11 Thread Richard Biener via Gcc-patches
On September 11, 2021 10:03:20 AM GMT+02:00, Jakub Jelinek wrote: >On Fri, Sep 03, 2021 at 02:47:11PM +, Qing Zhao via Gcc-patches wrote: >> > 2021-08-20 qing zhao >> > >> >* c-c++-common/auto-init-1.c: New test. >> >* c-c++-common/auto-init-10.c: New test. >> >* c

Re: [PATCH] Also preserve SUBREG_PROMOTED_VAR_P in expr.c's convert_move.

2021-09-11 Thread Jeff Law via Gcc-patches
On 9/11/2021 3:28 AM, Roger Sayle wrote: This patch catches another place in the middle-end where it's possible to preserve the SUBREG_PROMOTED_VAR_P annotation on a subreg to the benefit of later RTL optimizations. This adds the same logic to expr.c's convert_move as recently added to conver

Re: [PATCH] Refactor jump_thread_path_registry.

2021-09-11 Thread Jeff Law via Gcc-patches
On 9/11/2021 2:35 AM, Aldy Hernandez wrote: In an attempt to refactor thread_through_all_blocks(), I've realized that there is a mess of code dealing with coexisting forward and backward thread types. However, this is an impossible scenario, as the registry contains either forward/old-style t

Re: [PATCH] testsuite: Fix c-c++-common/auto-init-* tests

2021-09-11 Thread Qing Zhao via Gcc-patches
Hi, Jakub, Thanks a lot for your patch to the testing cases in c-c++-common. Actually I had a local fix too, and I planed to submitted it after I fixed all the failure for dg.target/i386 failures on different platforms..;-) > On Sep 11, 2021, at 3:03 AM, Jakub Jelinek wrote: > > On Fri, Sep

Re: [PATCH] Refactor jump_thread_path_registry.

2021-09-11 Thread Aldy Hernandez via Gcc-patches
So another thing to consider is that the threaders initially record their paths in different directions.  Forward threading records starting at the first block, backward from the final block.  At some point (I no longer remember where) we invert the backwards threader's path to fit the model

Go patch committed: Don't pad zero-sized trailing field in results struct

2021-09-11 Thread Ian Lance Taylor via Gcc-patches
This patch to the Go frontend avoids padding zero-sized trailing fields in the struct created to hold result parameters. This avoids a miscompilation when a function returns multiple results and the last result is zero-sized (this is not a useful way to write a function but it can happen reasonabl