[Bug c/85957] i686: Integers appear to be different, but compare as equal

[lukeshu at lukeshu dot com]

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

Luke Shumaker  changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|DUPLICATE   |---

--- Comment #2 from Luke Shumaker  ---
I do not believe that this is a duplicate of bug 323.  As I wrote:

> As I understand why floating point math could result in a6 and b6 being
> different; my concern is that a6 and b6 (which are integer types)
> appear to be different, yet compare as being equal.

"a6" and "b6" are both variables with types that resolve to "long long unsigned
integer".

printf ("a6 = %llu\n", a6); // prints "a6 = 1"
printf ("b6 = %llu\n", b6); // prints "b6 = 0"

That's fine, I understand that a6 and b6 could be different because of
differing round-off between intermediate steps.  That's not my concern.

Note that a6 and b6 have should have concrete values at this point, as we have
printed them.

My concern is the following:

printf ("(a6 == b6) = %s\n",
(a6 == b6) ? "true" : "false"); // prints "(a6 == b6) = true"

That is, the entire output of the POC program is:

a6 = 1
b6 = 0
a6 == b6

I am not concerned that a6 and b6 disagree, or that they are equal.  I am
concerned that *both* are true.

[Bug c/85957] New: i686: Integers appear to be different, but compare as equal

[lukeshu at lukeshu dot com]

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

Bug ID: 85957
   Summary: i686: Integers appear to be different, but compare as
equal
   Product: gcc
   Version: 7.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lukeshu at lukeshu dot com
  Target Milestone: ---

Created attachment 44200
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44200=edit
The preprocessed source

This is a bug that at first looks a bit like a "problems with floating
point numbers" bug.  However, my problem is with integers (calculated
from float types) behave inconsistently.

a6 = a.dbl * 1e6;
b6 = b.dbl * 1e6;
printf ("a6 = %llu\n", a6); // prints "1"
printf ("b6 = %llu\n", b6); // prints "0"
printf ("(a6 == b6) = %s\n", (a6 == b6) ? "true" : "false"); // prints
"true"

I understand why floating point math could result in a6 and b6 being
different; my concern is that a6 and b6 (which are integer types)
appear to be different, yet compare as being equal.

This happens on i686 with -O1 and -O2 (but not -O0), and not on
x86-64.

I apologize that my minimal testcase makes use of the glib-2.0
library; I'm having a hard time replicating the problem without it; it
seems GCC optimizing out a variable is key; and removing the library
use makes it not optimize it out.

Here is the output of gcc, including the appropriate version information:

$ gcc -v -save-temps -O1 $(pkg-config --libs --cflags glib-2.0) demo.c -o
demo

Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-pc-linux-gnu/7.3.1/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --disable-multilib --disable-werror
--enable-checking=release --enable-default-pie --enable-default-ssp
Thread model: posix
gcc version 7.3.1 20180312 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O1' '-I' '/usr/include/glib-2.0'
'-I' '/usr/lib/glib-2.0/include' '-o' 'demo' '-mtune=generic'
'-march=pentiumpro'
 /usr/lib/gcc/i686-pc-linux-gnu/7.3.1/cc1 -E -quiet -v -I
/usr/include/glib-2.0 -I /usr/lib/glib-2.0/include demo.c -mtune=generic
-march=pentiumpro -O1 -fpch-preprocess -o demo.i
ignoring nonexistent directory
"/usr/lib/gcc/i686-pc-linux-gnu/7.3.1/../../../../i686-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/glib-2.0
 /usr/lib/glib-2.0/include
 /usr/lib/gcc/i686-pc-linux-gnu/7.3.1/include
 /usr/local/include
 /usr/lib/gcc/i686-pc-linux-gnu/7.3.1/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O1' '-I' '/usr/include/glib-2.0'
'-I' '/usr/lib/glib-2.0/include' '-o' 'demo' '-mtune=generic'
'-march=pentiumpro'
 /usr/lib/gcc/i686-pc-linux-gnu/7.3.1/cc1 -fpreprocessed demo.i -quiet
-dumpbase demo.c -mtune=generic -march=pentiumpro -auxbase demo -O1 -version -o
demo.s
GNU C11 (GCC) version 7.3.1 20180312 (i686-pc-linux-gnu)
compiled by GNU C version 7.3.1 20180312, GMP version 6.1.2, MPFR
version 4.0.1, MPC version 1.1.0, isl version isl-0.18-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C11 (GCC) version 7.3.1 20180312 (i686-pc-linux-gnu)
compiled by GNU C version 7.3.1 20180312, GMP version 6.1.2, MPFR
version 4.0.1, MPC version 1.1.0, isl version isl-0.18-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: b94f7ca39249d495c6913c6ded8c0b64
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O1' '-I' '/usr/include/glib-2.0'
'-I' '/usr/lib/glib-2.0/include' '-o' 'demo' '-mtune=generic'
'-march=pentiumpro'
 as -v -I /usr/include/glib-2.0 -I /usr/lib/glib-2.0/include --32 -o demo.o
demo.s
GNU assembler version 2.30 (i686-pc-linux-gnu) using BFD version (GNU
Binutils) 2.30
   
COMPILER_PATH=/usr/lib/gcc/i686-pc-linux-gnu/7.3.1/:/usr/lib/gcc/i686-pc-linux-gnu/7.3.1/:/usr/lib/gcc/i686-pc-linux-gnu/:/usr/lib/gcc/i686-pc-linux-gnu/7.3.1/:/usr/lib/gcc/i686-pc-linux-gnu/
   
LIBRARY_PATH=/usr/lib/gcc/i686-pc-linux-gnu/7.3.1/:/usr/lib/gcc/i68