[Bug c++/95676] New: [armhf] g++ mis-compiles code at -O1 or above
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() == g;) should always evaluate to true.
[Bug target/95676] [armhf] g++ mis-compiles code at -O1 or above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95676
--- Comment #2 from James McCoy ---
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() == 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
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() == 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95676 --- Comment #3 from James McCoy --- (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/116799] [14/15 Regression] Miscompiled code on s390x at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116799 --- Comment #4 from James McCoy --- (In reply to Andrew Pinski from comment #3) > (In reply to James McCoy from comment #2) > > My initial bisect pointed to that, but I was using the Vim test suite as the > > good/bad check. > > > > I'm rerunning now with just the minimal reproduction to double check the > > results. My re-run bisect (using "./configure --enable-languages=c --disable-bootstrap" this time) is now pointing to r14-2675-gef28aadad6e. > I think you misunderstood, what I am saying is the x86 and s390x has the > same IR at the point at expand and therefor the problem is not with the > commit for PR 111294 itself but it is exposing an issue with something > further along in the compiler. (hence calling it a latent bug). Thanks for the explanation. I appreciate the extra context, as someone that doesn't work on gcc.
[Bug tree-optimization/116799] New: [14 Regression] Miscompiled code on s390x at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116799
Bug ID: 116799
Summary: [14 Regression] Miscompiled code on s390x at -O2
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jamessan at jamessan dot com
Target Milestone: ---
With gcc-14, one of Vim's test_glob2regpat tests started failing on s390x when
compiled with -O2. I've minimized Vim's code down to the simple reproduction
below. When compile correctly this should output "** -> .*" but instead its
showing "** -> $".
Bisecting shows that the problem was introduced by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111294
int printf(const char *, ...);
long unsigned int strlen(const char *s);
void file_pat_to_reg_pat(const char *pat, char *reg_pat)
{
const char * pat_end = pat + strlen(pat);
while (pat[0] == '*' && pat < pat_end - 1)
pat++;
const char * endp = pat_end - 1;
int add_dollar = 1;
if (endp >= pat)
{
while (endp - pat > 0 && *endp == '*')
endp--;
add_dollar = 0;
}
int i = 0;
for (const char * p = pat; *p && p <= endp; p++)
{
switch (*p)
{
case '*':
reg_pat[i++] = '.';
reg_pat[i++] = '*';
while (p[1] == '*')
++p;
break;
default:
reg_pat[i++] = *p;
break;
}
}
if (add_dollar)
reg_pat[i++] = '$';
reg_pat[i] = '\000';
}
int main()
{
char regpat[7] = {0};
file_pat_to_reg_pat("**", regpat);
printf("** -> %s\n", regpat);
return 0;
}
[Bug target/116799] [14/15 Regression] Miscompiled code on s390x at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116799 --- Comment #2 from James McCoy --- My initial bisect pointed to that, but I was using the Vim test suite as the good/bad check. I'm rerunning now with just the minimal reproduction to double check the results.
