[Bug c++/95676] New: [armhf] g++ mis-compiles code at -O1 or above

[Bug c++/95676] New: [armhf] g++ mis-compiles code at -O1 or above

[jamessan at jamessan dot com]

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

            Bug ID: 95676
           Summary: [armhf] g++ mis-compiles code at -O1 or above
           Product: gcc
           Version: 9.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jamessan at jamessan dot com
  Target Milestone: ---

Created attachment 48730
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48730&action=edit
Reduced test case

After uploading msgpack-c 3.3.0 to Debian, the armhf build failed due to a
specific test failing.  I originally reported this to msgpack-c's upstream:
https://github.com/msgpack/msgpack-c/issues/881

However, after testing on Debian's porterbox, it seems to be a GCC issue.  The
issue does not reproduce when compiled with -O0 but does with -O1 or higher.

Similarly, changing the line that was failing from using googletest's
"EXPECT_TRUE(foo == bar);" to "EXPECT_EQ(foo, bar);" caused the test to pass.

I was able to use creduce to produce the attached file, test.cpp, which
exhibits the problem.  The final assignment in main (cd = ce.aq<ba::z::bw>() ==
g;) should always evaluate to true.

[Bug target/95676] [armhf] g++ mis-compiles code at -O1 or above

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw <rearnsha at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2020-06-15

--- Comment #1 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
So what do you think is wrong with the code?  Sorry, I don't have time to try
to second guess what's going on.

How did you configure the compiler?  What options did you use when building
your code?

We need MUCH more than this if there's to be any progress.

[Bug target/95676] [armhf] g++ mis-compiles code at -O1 or above

[jamessan at jamessan dot com]

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

--- Comment #2 from James McCoy <jamessan at jamessan dot com> ---
Apologies for leaving off the build/configure information.  I shouldn't have
assumed one would have access to Debian's compiler.

--8<--
abel% g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/9/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: ../src/configure -v --with-pkgversion='Debian 9.3.0-13'
--with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,gm2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-9
--program-prefix=arm-linux-gnueabihf- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm
--disable-libquadmath --disable-libquadmath-support --enable-plugin
--enable-default-pie --with-system-zlib --with-target-system-zlib=auto
--enable-objc-gc=auto --enable-multiarch --disable-sjlj-exceptions
--with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb
--disable-werror --enable-checking=release --build=arm-linux-gnueabihf
--host=arm-linux-gnueabihf --target=arm-linux-gnueabihf
--with-build-config=bootstrap-lto-lean --enable-link-mutex
Thread model: posix
gcc version 9.3.0 (Debian 9.3.0-13) 
-->8--

The original issue was this test code (which uses googletest) from msgpack-c
unexpectedly failing with compiled with "g++ -std=c++11 -O1" but working with
"g++ -std=c++11 -O0":

--8<--
TEST(object_with_zone, system_clock_impl_min)
{
    std::chrono::system_clock::time_point
v(std::chrono::system_clock::time_point::min());
    msgpack::zone z;
    msgpack::object obj(v, z);
    EXPECT_TRUE(obj.as<std::chrono::system_clock::time_point>() == v);
}
-->8--

The test is verifying that the min value can round-trip through msgpack::object

Changing EXPECT_TRUE(... == v) to EXPECT_EQ(..., v) makes the code work with
-O1, as does storing obj.as<...>() into a temporary (e.g., v2) and using that
in the EXPECT_TRUE(v2 == v).

Removing googletest from the picture was successful, so the example could be
reduced to:

--8<--
#include <msgpack.hpp>

bool check_equality()
{
    std::chrono::system_clock::time_point
v(std::chrono::system_clock::time_point::min());
    msgpack::zone z;
    msgpack::object obj(v, z);
    return obj.as<std::chrono::system_clock::time_point>() == v;
}

int main()
{
    return check_equality();
}
-->8--


This is what I then had creduce work with.  The test script simply compiled the
file twice, once with "g++ -std=c++11 -O0" and once with "g++ -std=c++11 -O1",
verifying that the resulting binaries had an exit code of non-zero and zero,
respectively.

The bug reporting guidelines state to provide minimized test cases, so that's
what I did.  If there's more information, I'm happy to provide it.  I'm not a
compiler developer, so I'm not sure what information is needed.

[Bug target/95676] [armhf] g++ mis-compiles code at -O1 or above

[jamessan at jamessan dot com]

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

--- Comment #3 from James McCoy <jamessan at jamessan dot com> ---
(In reply to Richard Earnshaw from comment #1)
> So what do you think is wrong with the code?  Sorry, I don't have time to
> try to second guess what's going on.
> 
> How did you configure the compiler?  What options did you use when building
> your code?

Given the additional information I supplied, is there anything else I can
provide to help?

[Bug target/95676] [armhf] g++ mis-compiles code at -O1 or above

[acoplan at gcc dot gnu.org]

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

Alex Coplan <acoplan at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|---                         |INVALID

--- Comment #4 from Alex Coplan <acoplan at gcc dot gnu.org> ---
Looks like the program has undefined behavior (signed integer overflow), so not
a compiler bug.

$ cat test.cc
#include <msgpack.hpp>

bool check_equality()
{
    std::chrono::system_clock::time_point
v(std::chrono::system_clock::time_point::min());
    msgpack::zone z;
    msgpack::object obj(v, z);
    return obj.as<std::chrono::system_clock::time_point>() == v;
}

int main()
{
    return check_equality() ? 42 : 0;
}
$ g++ test.cc -fsanitize=undefined -I msgpack-c/include/ -I boost_1_73_0
$ ./a.out
/usr/include/c++/7/chrono:176:38: runtime error: signed integer overflow:
-9223372037 * 1000000000 cannot be represented in type 'long int'
/usr/include/c++/7/chrono:379:8: runtime error: signed integer overflow:
9223372036709551616 + 145224192 cannot be represented in type 'long int'

I get the same result with clang++ as well.