It appears to be a recent regression from 14.2. Compiler Explorer: https://godbolt.org/z/ohM7hT8Gn [559] % gcctk -v Using built-in specs. COLLECT_GCC=gcctk COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/15.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc-trunk/configure --disable-bootstrap --enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk --enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib Thread model: posix Supported LTO compression algorithms: zlib gcc version 15.0.1 20250117 (experimental) (GCC) [560] % [560] % gcctk -O2 small.c [561] % ./a.out Aborted [562] % [562] % cat small.c int a, b, c, d, e, f, *g = &b; static int h(int i) { return i < 0 || i > a ? 0 : i << a; } static int j(unsigned short i) { f = d == e; *g = h(65535 ^ i); return c; } int main() { j(0); h(0); if (b != 0) __builtin_abort(); return 0; }
-fno-ipa-cp works
Confirmed.
Started with r15-6294-g96fb71883d438bdb241fdf9c7d12f945c5ba0c7f
This is another manifestation of PR 118097. I'm testing a fix. *** This bug has been marked as a duplicate of bug 118097 ***
The master branch has been updated by Martin Jambor <jamborm@gcc.gnu.org>: https://gcc.gnu.org/g:6d07e3de7e8d39ac144ba1d83bba08d48bacae13 commit r15-7456-g6d07e3de7e8d39ac144ba1d83bba08d48bacae13 Author: Martin Jambor <mjambor@suse.cz> Date: Mon Feb 10 16:49:59 2025 +0100 ipa-cp: Perform operations in the appropriate types (PR 118097) One of the testcases from PR 118097 and the one from PR 118535 show that the fix to PR 118138 was incomplete. We must not only make sure that (intermediate) results of operations performed by IPA-CP are fold_converted to the type of the destination formal parameter but we also must decouple the these types from the ones in which operations are performed. This patch does that, even though we do not store or stream the operation types, instead we simply limit ourselves to tcc_comparisons and operations for which the first operand and the result are of the same type as determined by expr_type_first_operand_type_p. If we wanted to go beyond these, we would indeed need to store/stream the respective operation type. ipa_value_from_jfunc needs an additional check that res_type is not NULL because it is not called just from within IPA-CP (where we know we have a destination lattice slot belonging to a defined parameter) but also from inlining, ipa-fnsummary and ipa-modref where it is used to examine a call to a function with variadic arguments and we do not have types for the unknown parameters. But we cannot really work with those or estimate any benefits when it comes to them, so ignoring them should be OK. Even after this patch, ipa_get_jf_arith_result has a parameter called res_type in which it performs operations for aggregate jump functions, where we do not allow type conversions when constucting the jump functions and the type is the type of the stored data. In GCC 16, we could relax this and allow conversions like for scalars. gcc/ChangeLog: 2025-01-20 Martin Jambor <mjambor@suse.cz> PR ipa/118097 * ipa-cp.cc (ipa_get_jf_arith_result): Adjust comment. (ipa_get_jf_pass_through_result): Removed. (ipa_value_from_jfunc): Use directly ipa_get_jf_arith_result, do not specify operation type but make sure we check and possibly convert the result. (get_val_across_arith_op): Remove the last parameter, always pass NULL_TREE to ipa_get_jf_arith_result in its last argument. (propagate_vals_across_arith_jfunc): Do not pass res_type to get_val_across_arith_op. (propagate_vals_across_pass_through): Add checking assert that parm_type is not NULL. gcc/testsuite/ChangeLog: 2025-01-24 Martin Jambor <mjambor@suse.cz> PR ipa/118097 * gcc.dg/ipa/pr118097.c: New test. * gcc.dg/ipa/pr118535.c: Likewise. * gcc.dg/ipa/ipa-notypes-1.c: Likewise.