https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111329
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rsandifo at gcc dot gnu.org
--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Ah, actually that patch changed the definition of pp_wide_int macro
https://gcc.gnu.org/git/?p=gcc.git;a=blobdiff;f=gcc/pretty-print.h;h=6eb99b1f6901e4367687081dcd21298719ccdc40;hp=369be6e7ba767bfbf2ccf74d5e602371279726f4;hb=4f4fa2501186e4;hpb=6b96de22d6bcadb45530c1898b264e4738afa4fd
because with the larger precision wide_int the fixed size buffer isn't enough.
Now, in the analyzer case, seems it is used with a function call
pp_wide_int (pp, get_last_byte_offset (), SIGNED);
and perhaps the const wide_int_ref in that case binds to a temporary which goes
out of scope at the end of the statement.
So, if we want to support such usages, wonder if I don't need to rewrite
pp_wide_int macro into an inline function and perhaps use there an out of line
function for the larger precision case (because XALLOCAVEC will cause inlining
to fail).
