https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115237
--- Comment #5 from rguenther at suse dot de <rguenther at suse dot de> --- On Mon, 19 Jan 2026, eggert at cs dot ucla.edu wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115237 > > Paul Eggert <eggert at cs dot ucla.edu> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Version|14.1.1 |15.2.1 > > --- Comment #4 from Paul Eggert <eggert at cs dot ucla.edu> --- > For the coreutils/Gnulib case the function that GCC misdiagnosed was: > > static void * > check_nonnull (void *p) > { > if (!p) > xalloc_die (); > return p; > } > > where xalloc_die was declared via '_Noreturn void xalloc_die (void);'. In > 2021, > GCC incorrectly warned me that the function should be marked pure, I foolishly > did so, and this serious-but-rare out-of-memory bug has been lurking in > coreutils for five years. > > If a function calls an external function where GCC does not know the behavior, > it is obvious that GCC should not suggest __attribute__((const)) or > __attribute__((pure)). Any such suggestions are recipes for trouble. void __attribute__((noreturn)) xalloc_die (); void * check_nonnull (void *p) { if (!p) xalloc_die (); return p; } trunk diagnoses: t.c: In function ‘check_nonnull’: t.c:3:1: warning: function might be candidate for attribute ‘pure’ if it is known to return normally [-Wsuggest-attribute=pure] 3 | check_nonnull (void *p) | ^~~~~~~~~~~~~ which means GCC conservatively assumes the function might not return (for example by having a loop that never terminates or by, as in this case, a noreturn call). The diagnostic says that if you are better in determining the function will always return normally you could use 'pure' to indicate that. Even GCC 7 diagnoses it this way. The analysis could be more precise and track 'noreturn' calls separately from loops not known to terminate and suppress the diagnostic in case of presence of the former. So I'll take it as enhancement request for this.
