[Bug tree-optimization/114779] __builtin_constant_p does not work in inline functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114779 Georg-Johann Lay changed: What|Removed |Added Keywords||documentation --- Comment #10 from Georg-Johann Lay --- so I set keyword "documentation"
[Bug tree-optimization/114779] __builtin_constant_p does not work in inline functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114779 --- Comment #9 from Georg-Johann Lay --- When this PR won't be fixed, then maybe at least the documentation could clarify how to port macros to inline functions.
[Bug tree-optimization/114779] __builtin_constant_p does not work in inline functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114779 --- Comment #8 from Richard Biener --- I tried removing the TREE_SIDE_EFFECTS check at some point and it had quite some fallout even in the testsuite. Don't remember the PR I tried this for ...
[Bug tree-optimization/114779] __builtin_constant_p does not work in inline functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114779 Jan Hubicka changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #7 from Jan Hubicka --- Note that the test about side-effects also makes it impossible to test for constantness of values passed to function by reference which could be also useful. Workaround is to load it into temporary so the side-effect is not seen. So that early folding to 0 never made too much of sense to me. I agree that it is a can of worms and it is not clear if changing behaviour would break things...
[Bug tree-optimization/114779] __builtin_constant_p does not work in inline functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114779 --- Comment #6 from Georg-Johann Lay --- Recognizing more __builtin_constant_p situations is a good thing, IMO. It would allow to transition from macros to inline functions in such situations, for example in inline asm that has extra opcodes for const addresses.
[Bug tree-optimization/114779] __builtin_constant_p does not work in inline functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114779 --- Comment #5 from Jakub Jelinek --- It isn't about side-effects. It is about it having pointer type. If you change your testcase to uintptr_t psfr_int = (uintptr_t) psfr; if (! __builtin_constant_p (psfr_int)) then it will work. __builtin_constant_p ((uintptr_t) psfr) will not work though, because the folding strips casts and the POINTER_TYPE_P case triggers in that case as well. I am not sure it would be a good idea to change the __builtin_constant_p behavior at this point, a lot of code in the wild might depend on its current behavior.
[Bug tree-optimization/114779] __builtin_constant_p does not work in inline functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114779 --- Comment #4 from Georg-Johann Lay --- As far as I understand, & SFR has no side effects. But when it is used as argument to an (inline) function, then it does have side effects?
[Bug tree-optimization/114779] __builtin_constant_p does not work in inline functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114779
--- Comment #3 from Jakub Jelinek ---
But in that case the POINTER_TYPE_P case doesn't trigger, because it is
INTEGER_CST and
so
/* If we know this is a constant, emit the constant of one. */
if (CONSTANT_CLASS_P (arg)
|| (TREE_CODE (arg) == CONSTRUCTOR
&& TREE_CONSTANT (arg)))
return integer_one_node;
triggers first.
There is another case where the builtin can return true for a pointer, and that
is
when it is called with a string literal (__builtin_constant_p ("abcd")):
if (TREE_CODE (arg) == ADDR_EXPR)
{
tree op = TREE_OPERAND (arg, 0);
if (TREE_CODE (op) == STRING_CST
|| (TREE_CODE (op) == ARRAY_REF
&& integer_zerop (TREE_OPERAND (op, 1))
&& TREE_CODE (TREE_OPERAND (op, 0)) == STRING_CST))
return integer_one_node;
}
But if you use even in the same function
int volatile *psfr = SFR;
__builtin_constant_p (psfr)
it will fold to 0.
[Bug tree-optimization/114779] __builtin_constant_p does not work in inline functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114779
--- Comment #2 from Georg-Johann Lay ---
Notice that when is used directly in __builtin_constant_p without an
inline function, then the code works as expected:
int main (void)
{
if (__builtin_constant_p (& SFR))
__asm (".warning \"psfr = %0 is constant\"" :: "n" (& SFR));
return 0;
}
$ gcc bar.c -c -O2
Assembler messages:
Warning: psfr = $256 is constant
[Bug tree-optimization/114779] __builtin_constant_p does not work in inline functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114779 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- That has nothing to do with inline functions and everything to do with pointer arguments to __builtin_constant_p. The builtin behaved that way since at least 1998. The current version still has /* If this expression has side effects, show we don't know it to be a constant. Likewise if it's a pointer or aggregate type since in those case we only want literals, since those are only optimized when generating RTL, not later. And finally, if we are compiling an initializer, not code, we need to return a definite result now; there's not going to be any more optimization done. */ if (TREE_SIDE_EFFECTS (arg) || AGGREGATE_TYPE_P (TREE_TYPE (arg)) || POINTER_TYPE_P (TREE_TYPE (arg)) || cfun == 0 || folding_initializer || force_folding_builtin_constant_p) return integer_zero_node; What triggers here is the POINTER_TYPE_P (TREE_TYPE (arg)) case. So, the builtin is immediately folded into 0 in that case.
