https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119533
--- Comment #11 from Vineet Gupta <vineetg at gcc dot gnu.org> --- Debug log for the smaller test [1] https://gcc.gnu.org/pipermail/gcc-patches/2025-April/680355.html It hits the same ABNORMAL_EDGE assert. - bb 17 has V insns, needing vsetvl - which LCM tries to "bubble up" to 15,16... - bb 38 has the unwinder call (dest of abnormal edge). It is code_label/s address taken in eh_tables, no direct call flow leading to it). - bb 16 and 15 have "abnormal edges" to bb 38. We see the following output where LCM is working its way up (read from bottom up) ;; 19 succs { 20 31 } # P2. lift up 3 (succ 31 was lift up 2) ;; 30 succs { 38 31 } # P2. lift up 3 (succ 31 was lift up 2) ;; 31 succs { 44 32 } # P2. lift up 2b (succ 44 was succ of 15 - lift up 1) ;; 44 succs { 15 } # P2. lift up 2a (succ 15 was lift up 1) ;; 15 succs { 38 16 } # P2. lift up 1 (succ 16 was lift up 1) ;; 16 succs { 38 17 } # P2. lift up 0 (succ 17 had vsetvl locally needed) ;; 17 succs { 18 31 } # P1. VSETVL locally needed LCM needs to elide the "abnormal" edges (so BBS with such edges such as 16 and 15)and it seems current code even does that. With added debug code in invalid_opt_bb_p () we see following ... --- skipping abnormal SUCC edge bb 15 -> bb 38): --- skipping bb 15): --- skipping abnormal SUCC edge bb 16 -> bb 38): --- skipping bb 16): ... --- skipping abnormal PRED edge bb 5 -> bb 38): --- skipping bb 38): However the computed *earliest* bitmap used for vsetvl placement has those bbs, hence the issue. Robin suggested (from a different [PR/119547](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119547) that it should also take into account the *transparent* bitmap which seems to do ths trick.
