http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46926
--- Comment #7 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2010-12-16 15:30:17 UTC --- On Thu, 16 Dec 2010, rguenth at gcc dot gnu.org wrote: > Hum. We generate calls to sincos() if TARGET_HAS_SINCOS is true and a call > to cexp() if TARGET_C99_FUNCTIONS is true. We do so in two steps. First > we generate a call to a GCC internal builtin cexpi () which is a complex > exponentation with just an imaginary argument. Then during expansion we > expand that to either sincos() or cexp(). If you look at > expand_builtin_cexpi then it is obvious that we'd ICE if TARGET_HAS_SINCOS > is true but the sincos builtin is not available. Thus I conclude that > the sincos builtin is available when it really is should not be (with -ansi), > which makes this a C frontend bug(?). It would of course start to ICE > if TARGET_HAS_SINCOS is true but the builtin isn't there, but that's another > issue. It is correct that __builtin_sincos is always available and that it may generate a call to sincos - even when the sincos built-in function isn't available. But for code just calling sin and cos, calls to sincos shouldn't be generated in standards conformance modes where the name sincos isn't reserved (this is independent of -fno-builtin-sincos, which really should only affect the handling of source code that explicitly uses the function sincos). Similarly for cexp outside C99 mode. > Thus, I'm not sure how the frontend communicates -ansi effects to the > middle-end. Well, it will disable sincos and cexp as built-in functions as appropriate (while leaving the __builtin_ versions), but since -fno-builtin-* will also do that and is logically independent of the information we want (about what functions it is OK to generate calls to when those calls did not appear in the source code) that may not be quite the thing to check. Obviously the middle-end - which for these purposes includes the implementations of the TARGET_HAS_SINCOS and TARGET_C99_FUNCTIONS macros - can't depend on things such as flag_iso or flag_isoc99. There's already an IMPLICIT argument to DEF_BUILTIN. If its documented semantics are followed, for sincos you'd have "TARGET_HAS_SINCOS && !flag_iso", and for cexp "TARGET_C99_FUNCTIONS && (flag_isoc99 || !flag_iso)" (for DEF_C99_C90RES_BUILTIN, I think the existing use of TARGET_C99_FUNCTIONS on its own is correct, however). But then you'd need to work out what impact this might have elsewhere in the compiler, and fix the places currently checking TARGET_HAS_SINCOS or TARGET_C99_FUNCTIONS directly.
