mirror of
https://github.com/zebrajr/postgres.git
synced 2025-12-06 12:20:15 +01:00
fdb5dd6331
In these tests, we need to verify not only that the compiler has heard of these intrinsics, but that lower-level tools cope with them too. (For example, the assembler must also know the instructions, and on some platforms there might be library support involved.) The hazard is that the compiler might optimize away the calls altogether, allowing the configure check to succeed only to have the build fail later if lower-level support is missing. The existing code tried to prevent that by ensuring that the result of the intrinsic is used for something, but that's really insufficient because we were feeding constant input to it. So the compiler would be perfectly entitled to optimize away the calls anyway. Fix by making the inputs into global variables. (Hypothetically, LTO optimization could still remove the code --- but that's well past where we'd be likely to hit trouble.) It is not known that any current compiler would actually optimize away these calls, and even if that happened it would be unlikely that any problem would manifest. Our concern for this stems from largely-bygone days when it was common to install gcc on platforms with some other native compiler, so that a compiler-vs-library support discrepancy was more probable. Still, there's little point in defending against such cases in a way that is visibly incomplete. I'm content to fix this in master for now; we can back-patch if any indication appears that it's a live problem for someone. Discussion: https://postgr.es/m/3368102.1741993462@sss.pgh.pa.us |
||
|---|---|---|
| .. | ||
| ax_pthread.m4 | ||
| c-compiler.m4 | ||
| c-library.m4 | ||
| check_decls.m4 | ||
| check_modules.pl | ||
| config.guess | ||
| config.sub | ||
| general.m4 | ||
| install-sh | ||
| llvm.m4 | ||
| Makefile | ||
| meson.build | ||
| missing | ||
| perl.m4 | ||
| pkg.m4 | ||
| prep_buildtree | ||
| programs.m4 | ||
| python.m4 | ||
| tcl.m4 | ||