https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117796
Bug ID: 117796
Summary: Accepting undefined symbols with -flto -O0
-ftoplevel-reorder -fipa-reference-addressable
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: daniel.f.starke at freenet dot de
Target Milestone: ---
Using both -ftoplevel-reorder -fipa-reference-addressable with -flto allows the
following code to compile:
char some_unavailable_symbol();
char (*f)();
int main() {
f = some_unavailable_symbol;
return 0;
}
The issue exists since GCC 9. Removing either option prevents the optimizer to
remove the variable assignment altogether. However, I believe wrong code should
be rejected here. Many configure scripts use this technique to detect
availability of certain functions (e.g. for select() in the configure script
shipped with ncurses 5.9). Sure, this alone is no reason to change the behavior
of GCC. Nevertheless, I see no reason why this code should be accepted as valid
C code.
The issue in detail:
Setting -flto -ftoplevel-reorder -fipa-reference-addressable tells to linker
via plugin that some_unavailable_symbol() is actually defined somewhere.
You can test this with -Wl,--cref which outputs this:
some_unavailable_symbol C:\Users\user\AppData\Local\Temp\cccStrkk.o (symbol
from plugin)
Obviously, changing return 0; to return f(); results in the expected error of
an undefined symbol.
