Re: [PATCH] tree-optimization/107852 - missed optimization with PHIs

[Richard Biener <rguenther@suse.de>]

[-- Attachment #1: Type: text/plain, Size: 4160 bytes --]

On Mon, 5 Dec 2022, Jan-Benedict Glaw wrote:

> On Tue, 2022-11-29 14:30:22 +0100, Richard Biener via Gcc-patches <gcc-patches@gcc.gnu.org> wrote:
> > Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
> > 
> > 	PR tree-optimization/107852
> > 	* tree-ssa-sccvn.cc (visit_phi): Use equivalences recorded
> > 	as predicated values to elide more redundant PHIs.
> > 
> > 	* gcc.dg/tree-ssa/ssa-fre-101.c: New testcase.
> 
> This seems to trigger an issue when building the Linux powerpc kernel
> for the skiroot_defconfig:
> 
> [mk all 2022-12-05 19:50:10]   powerpc64-linux-gcc -Wp,-MMD,drivers/dma-buf/.dma-fence-array.o.d -nostdinc -I./arch/powerpc/include -I./arch/powerpc/include/generated  -I./include -I./arch/powerpc/include/uapi -I./arch/powerpc/include/generated/uapi -I./include/uapi -I./include/generated/uapi -include ./include/linux/compiler-version.h -include ./include/linux/kconfig.h -include ./include/linux/compiler_types.h -D__KERNEL__ -I ./arch/powerpc -DHAVE_AS_ATHIGH=1 -fmacro-prefix-map=./= -Wall -Wundef -Werror=strict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -fshort-wchar -fno-PIE -Werror=implicit-function-declaration -Werror=implicit-int -Werror=return-type -Wno-format-security -std=gnu11 -mlittle-endian -m64 -msoft-float -pipe -mtraceback=no -mabi=elfv2 -mcmodel=medium -mno-pointers-to-nested-functions -mcpu=power8 -mtune=power10 -mno-prefixed -mno-pcrel -mno-altivec -mno-vsx -mno-mma -fno-asynchronous-unwind-tables -mno-string -Wa,-maltivec -Wa,-mpower4 -Wa,-many -mno
 -strict-align -mlittle-endian -mstack-protector-guard=tls -mstack-protector-guard-reg=r13 -fno-delete-null-pointer-checks -Wno-frame-address -Wno-format-truncation -Wno-format-overflow -Wno-address-of-packed-member -Os -fno-allow-store-data-races -Wframe-larger-than=2048 -fstack-protector-strong -Wno-main -Wno-unused-but-set-variable -Wno-unused-const-variable -Wno-dangling-pointer -fomit-frame-pointer -ftrivial-auto-var-init=zero -fno-stack-clash-protection -Wdeclaration-after-statement -Wvla -Wno-pointer-sign -Wcast-function-type -Wno-stringop-truncation -Wno-stringop-overflow -Wno-restrict -Wno-maybe-uninitialized -Wno-alloc-size-larger-than -Wimplicit-fallthrough=5 -fno-strict-overflow -fno-stack-check -fconserve-stack -Werror=date-time -Werror=incompatible-pointer-types -Werror=designated-init -Wno-packed-not-aligned -mstack-protector-guard-offset=2800    -DKBUILD_MODFILE='"drivers/dma-buf/dma-fence-array"' -DKBUILD_BASENAME='"dma_fence_array"' -DKBUILD_MODNAME='"dma_fence_arra
 y"' -D__KBUILD_MODNAME=kmod_dma_fence_array -c -o drivers/dma-buf/dma-fence-array.o drivers/dma-buf/dma-fence-array.c  
> [mk all 2022-12-05 19:50:10] drivers/dma-buf/dma-fence-array.c: In function 'dma_fence_array_create':
> [mk all 2022-12-05 19:50:10] drivers/dma-buf/dma-fence-array.c:154:25: error: control flow in the middle of basic block 12
> [mk all 2022-12-05 19:50:10]   154 | struct dma_fence_array *dma_fence_array_create(int num_fences,
> [mk all 2022-12-05 19:50:10]       |                         ^~~~~~~~~~~~~~~~~~~~~~
> [mk all 2022-12-05 19:50:10] during GIMPLE pass: ivopts
> [mk all 2022-12-05 19:50:10] drivers/dma-buf/dma-fence-array.c:154:25: internal compiler error: verify_flow_info failed
> [mk all 2022-12-05 19:50:10] 0x19ea876 internal_error(char const*, ...)
> [mk all 2022-12-05 19:50:10]    ???:0
> [mk all 2022-12-05 19:50:10] 0x94b00e verify_flow_info()
> [mk all 2022-12-05 19:50:10]    ???:0
> [mk all 2022-12-05 19:50:10] Please submit a full bug report, with preprocessed source (by using -freport-bug).
> [mk all 2022-12-05 19:50:10] Please include the complete backtrace with any bug report.
> [mk all 2022-12-05 19:50:10] See <https://gcc.gnu.org/bugs/> for instructions.
> 
> Maybe you've got an idea, otherwise I'll try to reproduce it manually.
> (That's all automated building.)

I'll note the above ICE is quite a few passes later during IVOPTs so
the change triggered a latent issue.  Wild guessing makes me think
it's some asm goto being mis-handled.

Can you please open a bugreport and provide preprocessed source so
one can reproduce this with a cc1 cross?

Thanks,
Richard.