On Mon, Sep 5, 2022 at 9:59 AM Martin Liška <mli...@suse.cz> wrote: > > On 9/2/22 10:54, Richard Biener wrote: > > On Fri, Sep 2, 2022 at 9:00 AM Martin Liška <mli...@suse.cz> wrote: > >> > >> On 9/1/22 13:18, Richard Biener wrote: > >>> I presume WarnRemoved will diagnose use of -gstabs but not fail > >>> compilation. Will -gstabs then still enable -g (with the default debug > >>> format)? > >> > >> No, it won't set -g option. > > > > That was the usual side-effect - I wonder if we want to emit extra > > diagnostic when one of the obsolete options is given but -g is not > > enabled in the end or whether we want to preserve the debug info > > enablement effect? > > I would leave it for now and see if somebody would complain about > the current behavior. > > > > >>> > >>> Please followup with a gcc-13/changes.html entry. > >> > >> Sure. > >> > >>> > >>> I notice we have VMS_DEBUGGING_INFO left. From a quick look > >>> it is used by alpha*-dec-* (exclusively) and ia64-hp-*vms* (maybe > >>> also supports DWARF, it is ELF at least). One of the goals of > >>> non-DWARF removal was to get rid of debug hooks and instead allow > >>> "free-form" early debug generation from the frontends. > >> > >> Can you please explain what you mean by the free-form and what's expected > >> to do with the VMS_DEBUGGING_INFO macro? > > > > Well, VMS debugging would go, just like STABS. > > Can go now, or shall we deprecate it in GCC 13 first?
Let's ask VMS maintainers - what's the state of DWARF support in VMS? Is there active use of alpha*-dec-* or ia64-hp-*vms*? > > With "free-form" I mean > > that frontend code could call into the dwarf2out API directly, creating > > DWARF DIEs for language specific info (we probably want to export more > > and/or nicer APIs for such use). > > Ok, so bypassing dwarf2_debug_hooks, right? I can leave it to you such API > improvement. What do you think? Sure, it shouldn't be part of this series. Richard. > Cheers, > Martin > > > > > Richard. > > > >> Cheers, > >> Martin >
