public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug debug/78322] Debug info still present for fully optimized away functions
       [not found] <bug-78322-4@http.gcc.gnu.org/bugzilla/>
@ 2024-04-15  2:18 ` pinskia at gcc dot gnu.org
  2024-04-15  2:18 ` pinskia at gcc dot gnu.org
  2024-04-15 17:32 ` dblaikie at gmail dot com
  2 siblings, 0 replies; 3+ messages in thread
From: pinskia at gcc dot gnu.org @ 2024-04-15  2:18 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78322

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=107513

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to David Blaikie from comment #2)
> (In reply to Richard Biener from comment #1)
> > We produce an abstract copy for use by repeated inline copies.
> 
> Yep! Is it still reasonable to consider it a bug (or at least a feature
> request) that this is still produced even when no inline copies are emitted?

Not really. 

Sounds like what you are aiming for is the nodebug attribute that you can use
with always_inline. Basically in dwarf inline functions are still represented
as functions (calls) and most folks want that for their debugability of their
program but in this case you specific inlined functions not to have debug info
which is exactly what nodebug would do ...

^ permalink raw reply	[flat|nested] 3+ messages in thread

* [Bug debug/78322] Debug info still present for fully optimized away functions
       [not found] <bug-78322-4@http.gcc.gnu.org/bugzilla/>
  2024-04-15  2:18 ` [Bug debug/78322] Debug info still present for fully optimized away functions pinskia at gcc dot gnu.org
@ 2024-04-15  2:18 ` pinskia at gcc dot gnu.org
  2024-04-15 17:32 ` dblaikie at gmail dot com
  2 siblings, 0 replies; 3+ messages in thread
From: pinskia at gcc dot gnu.org @ 2024-04-15  2:18 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78322

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2024-04-15

^ permalink raw reply	[flat|nested] 3+ messages in thread

* [Bug debug/78322] Debug info still present for fully optimized away functions
       [not found] <bug-78322-4@http.gcc.gnu.org/bugzilla/>
  2024-04-15  2:18 ` [Bug debug/78322] Debug info still present for fully optimized away functions pinskia at gcc dot gnu.org
  2024-04-15  2:18 ` pinskia at gcc dot gnu.org
@ 2024-04-15 17:32 ` dblaikie at gmail dot com
  2 siblings, 0 replies; 3+ messages in thread
From: dblaikie at gmail dot com @ 2024-04-15 17:32 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78322

--- Comment #5 from David Blaikie <dblaikie at gmail dot com> ---
(In reply to Andrew Pinski from comment #4)
> (In reply to David Blaikie from comment #2)
> > (In reply to Richard Biener from comment #1)
> > > We produce an abstract copy for use by repeated inline copies.
> > 
> > Yep! Is it still reasonable to consider it a bug (or at least a feature
> > request) that this is still produced even when no inline copies are emitted?
> 
> Not really. 
> 
> Sounds like what you are aiming for is the nodebug attribute that you can
> use with always_inline. Basically in dwarf inline functions are still
> represented as functions (calls) and most folks want that for their
> debugability of their program but in this case you specific inlined
> functions not to have debug info which is exactly what nodebug would do ...

Not sure I follow. I'm not suggesting this function should be `nodebug`.

Specifically: If an abstract origin is unreferenced, it seems like it
should/could be omitted, for brevity.

If the abstract origin is referenced - if there was some remnant of the inlined
code that then caused an inlined_subroutine to be emitted, that would need to
reference the abstract origin and so the latter should be emitted.

This is what clang does, at least - thought it might be nice for gcc to do that
to, to have more compact DWARF output.

https://godbolt.org/z/3doWWK4G4

(though, interestingly, since this bug was filed - in GCC 9, GCC started
putting NOPs in for the inlined code, which is a nice touch - so at -O0 you can
still step into/out of a no-op (or presumably otherwise optimized away? if you
had some optimizations forced on at -O0 somehow) inlined function - but with
optimizations enabled you still see the behavior of an abstract origin emitted
without any uses/references to it)

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2024-04-15 17:32 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <bug-78322-4@http.gcc.gnu.org/bugzilla/>
2024-04-15  2:18 ` [Bug debug/78322] Debug info still present for fully optimized away functions pinskia at gcc dot gnu.org
2024-04-15  2:18 ` pinskia at gcc dot gnu.org
2024-04-15 17:32 ` dblaikie at gmail dot com

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).