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.
