[Bug middle-end/64313] [5 Regression] gcc.dg/torture/builtin-explog-1.c fails on bare-metal targets

["rguenth at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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.