On Fri, May 24, 2013 at 2:18 PM, Jakub Jelinek <ja...@redhat.com> wrote: > On Fri, May 24, 2013 at 02:10:18PM +0200, Richard Biener wrote: >> That's a pretty awful option name for one that makes us assume the target >> C library has a sincos function. >> >> I'd rather think about a way to specify, for all known builtins, whether GCC >> should generate calls to such function where they are not in the source >> program. That is, similar to how we have -f[no-]builtin-FOO introduce >> -f[no-]libc-FOO (with a better name for 'libc'?). That way there would be >> a way to specify that -floop-distribute-patterns should not produce calls >> to memset () for example. > > Yeah. Or we could be more aggressive at producing stpcpy, mempcpy etc. > calls where it could be beneficial and have a way to disable that. > What we currently do for stpcpy is c/c-decl.c (merge_decl) and > cp/decl.c (duplicate_decls) has code that if not -fno-builtin-stpcpy and > a compatible prototype is seen for stpcpy, then we allow it to be generated > implicitly (set_builtin_decl_implicit_p (fncode, true);).
But for example memset/memcpy always have that set, even if no prototype is in the source. So, is that decl_implicit_p really supposed to tell us whether we've seen a compatible prototype? > Yeah, we could do the same for sincos, I bet most of the people don't > prototype sin or cos themselves but include <math.h>, but in all cases > it means the compiler will do it only if stpcpy resp. sincos is actually > prototyped in the headers (right feature test macros for that). Right, that would be good enough for C and C++ - but what to do for Fortran? Richard. > Jakub
