[Bug c/107285] New: Incorrect code generation when we use __builtin_constant_p built-in function.

[Bug c/107285] New: Incorrect code generation when we use __builtin_constant_p built-in function.

[alex.curiou at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107285

            Bug ID: 107285
           Summary: Incorrect code generation when we use
                    __builtin_constant_p built-in function.
           Product: gcc
           Version: 12.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: alex.curiou at gmail dot com
  Target Milestone: ---

All versions of GCC are affected (I've checked versions from 5 till 12.2).

The minimized example of code:

~~~
#define test(val1) \
  __builtin_constant_p(val1) ? (val1 + 10) : (val1 * 20);


unsigned int bar(unsigned int value1) {
    return test(value1);
}

int main(void) {
    unsigned int a = bar(3);

    return a;
}
~~~

The __builtin_constant_p considers the val1 value to be NOT known to be
constant at compile time. So the generated code is
val1 * 20

But optimizer considers that the value is WELL known and can WELL be
calculated.
So, the return value of func bar is calculated at compile time and the call to
the bar func is dropped away.

And the final return value is WRONG:
val1 + 10

As a result we have different return values with -O2 and -Og optimization
flags, 13 and 60 accordingly.

Here is the compiler output for version 12.2:

-O2 will return 13
https://godbolt.org/z/Y1Thdcfch

~~~
bar:
        lea     eax, [rdi+rdi*4]
        sal     eax, 2
        ret
main:
        mov     eax, 13
        ret
~~~

-Og will return 60
https://godbolt.org/z/sbcer78rP

~~~
bar:
        lea     eax, [rdi+rdi*4]
        sal     eax, 2
        ret
main:
        mov     edi, 3
        call    bar
        ret
~~~

[Bug c/107285] Incorrect code generation when we use __builtin_constant_p built-in function.

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107285

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
That is just bogus expectation.
__builtin_constant_p works that it has a cut-off after certain optimizations
(for  -O0 already very early), if optimizations before it manage to optimize
the argument into a constant, it is true.  After the cut-off the remaining
occurrences are folded into false.
So, if bar is inlined or say IPA constant propagated, the argument is constant,
while if it isn't inlined nor IPA constant propagated (etc.), as seems to be
the case for -Og, it is not constant, thus you get what you asked for.
__builtin_constant_p better should be used as a way to optimize code without
changing the observable behavior...

[Bug c/107285] Incorrect code generation when we use __builtin_constant_p built-in function.

[alex.curiou at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107285

--- Comment #2 from Alexey <alex.curiou at gmail dot com> ---
Well, currently
The code generation is just could be wrong.

If we use the example provided: we have to see or 13 or 60 in both cases.

We have to see same result from bar function and from the final result of the
program calculation.

But here the code is generated to calculate 60, but it returns 13 ???? !!!!

[Bug c/107285] Incorrect code generation when we use __builtin_constant_p built-in function.

[alex.curiou at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107285

--- Comment #3 from Alexey <alex.curiou at gmail dot com> ---
(In reply to Jakub Jelinek from comment #1)
> That is just bogus expectation.
> __builtin_constant_p works that it has a cut-off after certain optimizations
> (for  -O0 already very early), if optimizations before it manage to optimize
> the argument into a constant, it is true.  After the cut-off the remaining
> occurrences are folded into false.
> So, if bar is inlined or say IPA constant propagated, the argument is
> constant, while if it isn't inlined nor IPA constant propagated (etc.), as
> seems to be the case for -Og, it is not constant, thus you get what you
> asked for.
> __builtin_constant_p better should be used as a way to optimize code without
> changing the observable behavior...

For -O2: the generated code and the result should be consistent.
Otherwise the usage of the __builtin_constant_p function is just unpredictable.

But now the code of bar func will calculate 60 and the real return value is 13.

Or just change the explanation for the __builtin_constant_p
(https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html) and write that some
times the branching on the result of this function will have nothing to do with
the final result provided by the compiled code.

[Bug c/107285] Incorrect code generation when we use __builtin_constant_p built-in function.

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107285

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
No, the generated code is just fine.
At -O2, bar is inlined into main.  So we have
unsigned int a = __builtin_constant_p (3) ? 13 : 60;
and 3 is constant.
In the out of line copy of bar, value1 is a function parameter, so
__builtin_constant_p evaluates to false.
As I said, what is bad is the testcase, the above isn't how
__builtin_constant_p should be used.
I'd suggest you look in /usr/include/ or other codebases how one uses the
builtin...