Bug 38296 - documentation: improve documentation of __builtin_constant_p()
Summary: documentation: improve documentation of __builtin_constant_p()
Status: RESOLVED INVALID
Alias: None
Product: gcc
Classification: Unclassified
Component: c (show other bugs)
Version: 4.4.0
: P3 enhancement
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: documentation
Depends on:
Blocks:
 
Reported: 2008-11-27 18:27 UTC by Török Edwin
Modified: 2016-10-21 19:47 UTC (History)
2 users (show)

See Also:
Host: x86_64-linux-gnu
Target: x86_64-linux-gnu
Build: x86_64-linux-gnu
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Török Edwin 2008-11-27 18:27:49 UTC
Because __builtin_constant_p() is sometimes (ab)used as a static analyzer, the documentation should give more details what is expected to work, and what you should not use it for. (see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36359)

Here is my suggestion, please incorporate it into the gcc 4.4.0 documentation if you consider it appropriate:
- __builtin_constant_p() can return 1 even if during the execution of the program it never is a constant
     for example: the optimizer splits the case when a value is zero and non-zero, and fully expands the zero case, considering the variable is zero. This doesn't mean that during a real execution the value can ever be zero.
This can happen for example if the optimizer cannot "see" that a certain value is impossible.

- __builtin_constant_p() is not a static analyzer, as it doesn't offer soundness or completeness guarantees for the analysis it makes

- when you write optimized code for the __builtin_constant_p() == 1 case,
you should not treat invalid constant values as build time errors, instead you should fall back to using the generic code at runtime (which should handle the invalid cases anyway). The reason is because gcc may constant-propagate/expand a value that may not be reached ever, because of the reasons described above.

   for example, instead of doing this:
     __builtin_constant_p(val) ? (VALID(val) ? OPTIMIZED(val) : __build_error())
                               :  generic_case(val)
   Do this: 
     (__builtin_constant_p(val) && VALID(val)) ? OPTIMIZED(val) 
                                               : generic_case(val);


What happens if you don't take the above advice: anytime gcc's optimizer is changed, your code may break
Comment 1 Jeffrey A. Law 2016-10-21 19:47:57 UTC
Unfortunately, the proposal doesn't match the actual semantics of b_c_p.