On Mon, Feb 2, 2026 at 4:41 PM Jakub Jelinek <[email protected]> wrote: > > On Mon, Feb 02, 2026 at 04:16:39PM +0100, Florian Weimer wrote: > > * Qing Zhao: > > > > > Our internal customer is asking for this feature. > > > > > > They used icc currently, with icc, then can get inline list, prof_used > > > list, etc. from the binary. > > > > > > The old studio compiler also provided such feature, there was compiler > > > commentary section in the binary to record many of the important > > > compiler transformations along with the line number information. > > > > > > If there is any performance issue with the application, such > > > information will be very useful. Especially for large applications. > > > > We have similar needs and use annobin for that. Its optimization > > coverage is not great, though. I think for guiding future GCC > > development, it would be really interesting to know how many (e.g.) > > memcpy calls are there because the source code was not built with source > > fortification, or because it was and the compiler deemed the call to be > > statically safe and not needing bounds checking, or it didn't have any > > bounds information at all, so checking was impossible. That part at > > least intersects with the desire to track certain optimization > > decisions. > > Part of that is already available in debug info. > If you look to debug info corresponding to memcpy calls (sure, that won't > cover cases where memcpy has been expanded inline), if they are in > DW_TAG_inlined_subroutine for the bits/string_fortified.h inline, then > it has been -D_FORTIFY_SOURCE={2,3} protected, if not, then it has not. > > Just we don't record anywhere whether gimple_fold_builtin_memory_chk decided > to fold __builtin___memcpy_chk to __builtin_memcpy because the last > argument wasn't all ones and the length argument was guaranteed to be > smaller than that, or if it was because the objsz pass determined the > last argument is all ones and so we can't protect it. > > That said, all this is complicated by jump threading, inlining, unrolling > and other optimizations that can result in one source memcpy call to be > changed into multiple calls in the IL (or on the other side DCE etc. which > can remove some calls).
I guess we'd need to track duplications (and removals!) as well then. In the end it's probably the memcpy calls somehow surviving and then (for a single source memcpy) the ratio of fortified vs. non-fortified copies. That is, we do have to implement what we had as former -Wunreachable-code, but "properly". It's going to be impossible and require costly human review I think. > So, dunno what you want to track exactly, key stuff on the locations of the > memcpy (if extern inline memcpy then its caller) and track for each location > how many cases were folded because of all ones objsz, how many because of > gimple_fold_builtin_memory_chk etc.? > > Jakub >
