https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126801
--- Comment #5 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:7e784194fe49e45c8fb78168064a9b2627493f09 commit r17-3469-g7e784194fe49e45c8fb78168064a9b2627493f09 Author: Jakub Jelinek <[email protected]> Date: Thu Aug 20 12:35:41 2026 +0200 Fix up -fvar-tracking-uninit [PR126801] The r12-4397 change to get rid of AUTODETECT_VALUE unfortunately broke several things related to -fvar-tracking-uninit. Before that change, the option defaulted to 0, under some condition on darwin only set it to flag_var_tracking which at that point could have been whatever user specified or AUTODETECT_VALUE and finally in finish_options did: /* If the user specifically requested variable tracking with tagging uninitialized variables, we need to turn on variable tracking. (We already determined above that variable tracking is feasible.) */ if (flag_var_tracking_uninit == 1) flag_var_tracking = 1; if (flag_var_tracking == AUTODETECT_VALUE) flag_var_tracking = optimize >= 1; if (flag_var_tracking_uninit == AUTODETECT_VALUE) flag_var_tracking_uninit = flag_var_tracking; i.e. 1) -fvar-tracking-uninit option specified on command line implied -fvar-tracking 2) var-tracking was defaulted to 1 even for -O1 and above 3) in the darwin conditional case if flag_var_tracking_uninit was defaulted to maybe on, it was set to flag_var_tracking The r12-4397 change properly handled only 2), by adding default_options_table entry for OPT_fvar_tracking. 1) got lost in the patch, -fvar-tracking-uninit explicitly on command line no longer implies -fvar-tracking 3) was probably assumed to be always initialized to AUTODETECT_VALUE and so replaced with /* One could use EnabledBy, but it would lead to a circular dependency. */ if (!OPTION_SET_P (flag_var_tracking_uninit)) flag_var_tracking_uninit = flag_var_tracking; which effectively makes -fvar-tracking-uninit default to on whenever -fvar-tracking is on (explicitly or implicitly), unless overridden by user. Also note that the value of flag_var_tracking_uninit is irrelevant if flag_var_tracking is off, the variable is only tested in various spots in the var-tracking pass guarded by flag_var_tracking. Anyway, the following patch restores the 1) behavior, changes the darwin code to just set flag_var_tracking_uninit by default to 1 if the condition is met (worst case flag_var_tracking_uninit will be 1 and flag_var_tracking will be 0, nothing will care), drops the bogus defaulting to -fvar-tracking-uninit on all other targets and finally fixes something that has been broken even before r12-4397, in my reading on darwin the condition would turn on flag_var_tracking_uninit even if user used explicit -fno-var-tracking-uninit. Unfortunately the DW_OP_GNU_uninit support didn't come with a single testcase, neither on the gcc side nor on the gdb side and I haven't figured out easily a testcase which I could add to the testsuite for this (sure, I could from some *.o that contains it cvise reduce it). But one can actually see some DW_OP_GNU_uninit uses in the cc1plus binary, before the patch: readelf -wo cc1plus 2>&1 | grep DW_OP_GNU_uninit | wc -l 2228 readelf -wo cc1plus 2>&1 | grep DW_OP_GNU_uninit.*DW_OP_GNU_uninit | wc -l 208 after the patch: readelf -wo cc1plus 2>&1 | grep DW_OP_GNU_uninit | wc -l 0 2026-08-20 Jakub Jelinek <[email protected]> PR debug/126801 * opts.cc (finish_options): Don't set flag_var_tracking_uninit to flag_var_tracking by default. Instead, set flag_var_tracking to flag_var_tracking_uninit if the latter was explicitly set. * config/darwin.cc (darwin_override_options): Only set flag_var_tracking_uninit if it wasn't explicitly set and set it to 1 rather than flag_var_tracking. Formatting fix. Reviewed-by: Richard Biener <[email protected]>
