Bug 62623 - [C++11] Behavior change in test case with -m32 and -O3
Summary: [C++11] Behavior change in test case with -m32 and -O3
Status: RESOLVED DUPLICATE of bug 323
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 4.8.1
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-09-01 07:37 UTC by theJ893
Modified: 2016-07-25 02:06 UTC (History)
0 users

See Also:
Host:
Target:
Build:
Known to work:
Known to fail: 4.7.3, 4.8.3, 4.9.1, 5.0
Last reconfirmed: 2014-09-01 00:00:00


Attachments
Source file that I am using to reproduce the issue (951 bytes, text/plain)
2014-09-01 07:37 UTC, theJ893
Details

Note You need to log in before you can comment on or make changes to this bug.
Description theJ893 2014-09-01 07:37:36 UTC
Created attachment 33424 [details]
Source file that I am using to reproduce the issue

When compiling unit tests for my code with g++, I discovered a particular unit test was failing when I compiled it with the -m32 and -O3 options.

Background:
I have a class template for a Vector (the kind used in physics, not the container). Vector contains a fixed with array of data, and an invert() method that performs x = 1/x on each element of the array, modifying it in-place.

The unit test consists of initializing a vector "o" with an array of predefined values, calling o.invert(), and then comparing the values in the vector to a set of predefined, expected values for equality. The test returns "true" when compiling with "-m32", "-m64", and "-m64 -O3", but returns "false" when compiling with "-m32 -O3".

It should be noted, if you change the invert method to treat the Vector as "volatile", or make use of the values in some way (e.g. by doing srand( o.data[0] ); or std::cout << o.data[0] << " " o.data[1] << ... << std::endl;) this circumvents the problem.

I've managed to isolate and reproduce the issue in its own file. I had a friend compile and run the test program as well and verify that he is getting the same result. I've attached the source file to this bug report. The .ii file was too large to attach.

Here is the command line I am using to compile the program, using the requested switches:
g++ -O3 -m32 -Wall -Wextra -fno-strict-aliasing -fwrapv -fno-aggressive-loop-optimizations -save-temps -std=c++11 G++O3Bug.cpp -o bin/G++O3Bug && ./bin/G++O3Bug

As requested, here is the output from gcc -v on my system:
owner@mint ~/Desktop/test $ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.8.1-10ubuntu9' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.8 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.1 (Ubuntu/Linaro 4.8.1-10ubuntu9)
Comment 1 Andrew Pinski 2016-07-25 02:06:41 UTC
This is a dup of bug 323.  -m32 causes the compiler to use the x87 register by default so there are slight differences in the rounding vs non rounding in some cases.

*** This bug has been marked as a duplicate of bug 323 ***