https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64313
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jsm28 at gcc dot gnu.org
--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
For aarch64-elf ordinary builtins declared as DEF_LIB_BUILTIN are implicitely
available but for example expf is not as the target computes
targetm.libc_has_function (function_c99_misc) as false. This is because of
config/elfos.h:#undef TARGET_LIBC_HAS_FUNCTION
config/elfos.h:#define TARGET_LIBC_HAS_FUNCTION no_c99_libc_has_function
One solution is to properly guard the testcase with c99_runtime (even GNU
runtime, as it uses exp10/log10/pow10). But it expects all tests to be
folded away which means that builtins need to be recognized (which they
are because they match their prototype - sth that is not enough according
to Joseph).
IMHO even if system headers declare such prototype we can't be sure they
are really the correct function (system headers include non-C-library runtime
headers). To be sure we'd need to know the names are really reserved which
for example for exp10 is if _GNU_SOURCE is defined at the point of
prototyping exp10. Not sure if what libcpp provides for this is convenient
(there are some related callbacks to track what is defined / undefined),
but whatever we do it should also work for -save-temps which means we need
to make sure to emit the #defines to the preprocessed source as well and
_not_ use -fpreprocessed(?).
The pragmatic solution is to make builtins implicitely available once they
are seen in the instruction stream, for example during gimplification.
A more complex solution is to turn genmatch upside-down and make it clever,
similar to how fold_builtin_logarithm gets around this - re-use the decl
we get in the matching IL. Note that this isn't easily possible with low
overhead (well, maybe making code_helper a bit heavier weight and pass
tree_code or builtin decl around).
I'm leaning towards either reverting the single builtin patch for GCC 5
or implementing the pragmatic solution.
