https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101941
--- Comment #20 from Jakub Jelinek <jakub at gcc dot gnu.org> --- (In reply to Andrew Pinski from comment #14) > (In reply to Jakub Jelinek from comment #13) > > Actually, lookng at the kernel, I don't see how this can happen. > Inlining is not always the issue here. Ah, so the always_inline memset or whatever got inlined already during einline into some function, but we fnsplit that caller. I was thinking about something like you wrote, but actually more complex, not punt on fnsplit when it contains calls with error attribute, but just note in which bbs they are present, if any bbs have them compute post dominators and when finding splitting points disallow splitting points where any of the marked bbs with error calls post-dominates the splitting point (i.e. where those calls would become unconditional). Because at least for error, that case means we'll fail the compilation, while if we don't split, there is a chance we might compile it correctly. warning attribute or if it is conditional even after splitting could still break. Honza: I don't know what you mean by dropping flags, the only flag we have is an attribute on the called function, it isn't a per-call flag, and in many use cases with error attributes the functions are actually never defined, so ignoring the error attribute at expansion time would be both risky for security reasons (error attribute is usually used in such cases) and could mean it won't link anyway.
