https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78685
--- Comment #45 from Lukas Grätz <[email protected]> --- (In reply to Jakub Jelinek from comment #42) > (In reply to [email protected] from comment #41) > > > >such a resolution means that people will frequently end up using -O0 > > > >for debugging, and O0 is far more expensive than it needs to be for > > > >viable debugging. > > > > In particular -O0 is also lacking debug features, the most prominent > > being lack of -fvar-tracking support and thus missing debug info > > in the prologue/epilogue. I could not observe that adding -fvar-tracking to -O0 makes any difference. I don't know of any debugging issue, the prologue/epilogue seems just fine for -O0 without -fvar-tracking. But perhaps you know something? > > And not just that, e.g. for VLAs also around the VLA declaration, or for > vars with register keyword everywhere, etc. I do not see an issue with VLAs. I got something like this in the DWARF for a sample program compiled with -O0 -g: 0x000000e8: DW_TAG_array_type DW_AT_type (0x000000e1 "char") 0x000000ed: DW_TAG_subrange_type DW_AT_type (0x00000046 "long unsigned int") DW_AT_upper_bound (DW_OP_fbreg -448, DW_OP_deref) In contrast to a fixed-size array, DW_AT_upper_bound is computed from the contents of a local variable (here on the stack), and debuggers can handle that. Register variables are also in the DWARF. And "etc"? If there really is an issue, please file a bug report!
