On Fri, 2 May 2025, Jakub Jelinek wrote: > Hi! > > The pr120057-1.c testcase is incorrectly rejected since > r15-4377 (and for a while it also ICEd after the error), i.e. > the optimization of large C initializers using RAW_DATA_CST. > Similarly, the embed-18.c testcase is incorrectly rejected since > the embed support has been introduced and RAW_DATA_CST used for that. > > The callers of check_constexpr_init (store_init_value and > output_init_element) compute int_const_expr as > int_const_expr = (TREE_CODE (init) == INTEGER_CST > && !TREE_OVERFLOW (init) > && INTEGRAL_TYPE_P (TREE_TYPE (init))); > but that is only passed through down to check_constexpr_init. > I think tweaking those 2 callers to also allow RAW_DATA_CST for > int_const_expr when check_constexpr_init needs top special case it > no matter what would be larger, so the patch just changes > check_constexpr_init to deal with RAW_DATA_CST in the initializers. > For TYPE_UNSIGNED char precision integral types RAW_DATA_CST is > always valid, for !TYPE_UNSIGNED we need to check for 128-255 values > being turned into negative ones. > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk and > 15.2?
OK. I had somehow got the idea that RAW_DATA_CST didn't require special constexpr handling because accesses to elements of constexpr arrays aren't themselves constant expressions in C23, but all that means is that the logic to extract the values of constexpr initializers when those objects are referenced in expressions doesn't need to handle RAW_DATA_CST - it doesn't avoid the need for handling in the checks on values of initializers dealt with here. -- Joseph S. Myers josmy...@redhat.com
