[PATCH] clarify comments for implicit_p flag for built-ins

[Martin Sebor]

Ping: https://gcc.gnu.org/ml/gcc-patches/2018-11/msg01759.html

If there are no objections or suggestions for tweaks I'll commit
this updated comment this week.

On 11/20/18 1:24 PM, Martin Sebor wrote:
> On 11/20/2018 11:02 AM, Martin Sebor wrote:
>> Would the updated comments in the attached patch more accurately
>> describe the purpose of the IMPLICIT_P flag and
>> the builtin_decl_explicit() and builtin_decl_implicit() functions?
>>
>> I ended up here while trying to understand the differences between
>> the functions on different targets and decide which one should be
>> used to diagnose bugs like the one below:
>>
>> Â  long double fabsl ();Â Â  // missing prototype
>>
>> Â  long double f (int x)
>> Â  {
>> Â Â Â  return fabsl (x);Â Â Â Â  // want a warning here
>> Â  }
>>
>> I think we want the warning regardless of IMPLICIT_P so the warning
>> code should call builtin_decl_explicit() to obtain fabsl's expected
>> type, even if the target's runtime doesn't support the function on
>> the basis of the comment:
>>
>> Â  When a program uses floorf we may assume that the floorf function
>> Â  has the expected meaning
> 
> Actually, some more testing suggests the comment in builtins.def
> (either the original or the patched one) isn't entirely accurate
> or helpful to understanding the purpose of the flag:
> 
>  Â  IMPLICIT specifies condition when the builtin can be produced by
>    compiler.  For instance C90 reserves floorf function, but does not
>    define it's meaning.  When user uses floorf we may assume that the
>  Â  floorf has the meaning we expect, but we can't produce floorf by
>  Â  simplifying floor((double)float) since the runtime need not
>  Â  implement it.
> 
> Given the following code:
> 
>  Â  float floorf ();
> 
>  Â  void f (void)
>  Â  {
>  Â Â Â  if (floorf (0.0f))
>  Â Â Â Â Â  __builtin_abort ();
>  Â  }
> 
> in C90 mode, BUILT_IN_FLOORF's IMPLICIT flag is clear and GCC
> doesn't seem to assume anything about the call to the function,
> contrary to the comment ("we may assume the meaning we expect").
> The comment also doesn't explain when IMPLICIT may be set.
> 
> I've updated the comment a bit more to more accurately describe
> when I think the flag is set or clear, and how it's used.
> Corrections or further clarification are appreciated.
> 
> Thanks
> Martin