https://gcc.gnu.org/bugzilla/show_bug.cgi?id=127879
--- Comment #2 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Jakub Jelinek <[email protected]>: https://gcc.gnu.org/g:e3121605d2a5507b4ec456ad28f133c4f11f67b6 commit r17-5659-ge3121605d2a5507b4ec456ad28f133c4f11f67b6 Author: Jakub Jelinek <[email protected]> Date: Wed Oct 28 11:58:37 2026 +0100 gimple-fold-range: For range_from_readonly_var handle also STRING_CSTs and RAW_DATA_CSTs [PR127879] When writing the PR127685 fix/workaround, I've noticed the comment about RAW_DATA_CST and decided to implement it. WHen playing with testcases, I've noticed it doesn't handle even more important case, STRING_CST. RAW_DATA_CST is less important because it usually appears only for larger chunks, CPP_EMBED should usually appear for 64+ bytes in the #embed directive and being turned into RAW_DATA_CST, similarly the optimizations to turn large array initializers into RAW_DATA_CST usually need 64+ bytes or more. Sure, e.g. C designated initializers then can break it into smaller pieces, down to even 2 bytes in it, but the vrp-cstload-limit param has 255 as the upper limit (why?) and checks the whole size of the corresponding complete object, not even its subobject, so to handle RAW_DATA_CST, one needs to bump the limit I think. On the other side, the C/C++ braced_list_to_string optimization can turn initializers like {,un}signed char xyz[] = { 1, 2, 3 }; into = "\1\2\3", even for much smaller sizes. Anyway, both of these IMHO need to be handled inside of accumulate_range_from_array_ref, because that is where we know the indexes, can check if a specific byte in those intersects the index range and in that case, we don't need to build_int_cst just to throw it away and can just create a wide_int and union that. In both of these cases we can do this only for the end of the component path and have to verify m_type is integral and with CHAR_BIT precision. It can be either signed or unsigned, we need to either sign or zero extend the host byte from STRING_CST or RAW_DATA_CST when creating the wide_int. 2026-10-28 Jakub Jelinek <[email protected]> PR tree-optimization/127879 * gimple-range-fold.cc (ctor_ref_range::accumulate_range): Remove comment about RAW_DATA_CST. Allow also STRING_CST, not just CONSTRUCTOR. (ctor_ref_range::accumulate_range_from_component_ref): Punt if init is not a CONSTRUCTOR. (ctor_ref_range::accumulate_range_from_array_ref): Handle init being a STRING_CST. Handle RAW_DATA_CSTs inside of a CONSTRUCTOR. (fold_using_range::range_from_readonly_var): Allow ctor being a STRING_CST, rather than only a CONSTRUCTOR. * gcc.dg/tree-ssa/vrp-from-cst-agg-14.c: New test. * gcc.dg/tree-ssa/vrp-from-cst-agg-15.c: New test. * gcc.dg/tree-ssa/vrp-from-cst-agg-16.c: New test. * gcc.dg/tree-ssa/vrp-from-cst-agg-17.c: New test. * gcc.dg/tree-ssa/vrp-from-cst-agg-18.c: New test. * gcc.dg/tree-ssa/vrp-from-cst-agg-19.c: New test. Reviewed-by: Richard Biener <[email protected]>
