[Bug middle-end/94035] Wrong optimization: conditional equivalence vs. values with several representations

[rguenther at suse dot de]

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

--- Comment #6 from rguenther at suse dot de <rguenther at suse dot de> ---
On Thu, 5 Mar 2020, ch3root at openwall dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94035
> 
> --- Comment #5 from Alexander Cherepanov <ch3root at openwall dot com> ---
> I see. But the problem with decimal floating-point formats remains...
> 
> Based on bug 93806, comment 41, here is an example with equal but different
> values:
> 
> ----------------------------------------------------------------------
> #include <stdio.h>
> 
> __attribute__((noipa)) // imagine it in a separate TU
> static _Decimal32 opaque(_Decimal32 d) { return d; }
> 
> int main()
> {
>     _Decimal32 x = opaque(1.0DF);
>     unsigned char *p = (unsigned char *)&x;
> 
>     if (x == 1.00DF)
>         printf("%d\n", p[0]);
>     printf("%d\n", p[0]);
> }
> ----------------------------------------------------------------------
> $ gcc -std=c2x -pedantic -Wall -Wextra test.c && ./a.out
> 10
> 10
> $ gcc -std=c2x -pedantic -Wall -Wextra -O3 test.c && ./a.out
> 100
> 10
> ----------------------------------------------------------------------
> gcc x86-64 version: gcc (GCC) 10.0.1 20200305 (experimental)
> ----------------------------------------------------------------------
> 
> And then there are non-canonical representations for DFP values...

From an implementation perspective it should be a FP format helper
that tells us whether the format has multiple representations
for values considered equal (eventually even for a specific
representation of one value), MODE_HAS_AMBIGUITY_FOR(MODE, VAL)
or so (where a NULL VAL should return whether there's any such value).
Then we can easily test that before doing equivalence substitution.