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 meaningActually, 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
