[Bug c++/87665] [8/9 Regression] gcc HEAD (svn: 265340) breaks elements on resize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87665 --- Comment #9 from Jonathan Wakely --- Correction, on both x86_64 and ppc64le it requires all of: -fstrict-aliasing -ftree-loop-vectorize -ftree-sra -ftree-ch -ftree-forwprop -ftree-copy-prop
[Bug c++/87665] [8/9 Regression] gcc HEAD (svn: 265340) breaks elements on resize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87665 Ville Voutilainen changed: What|Removed |Added CC||ville.voutilainen at gmail dot com --- Comment #8 from Ville Voutilainen --- It seems that either -fno-strict-aliasing or -march=native makes it work. That bears a *striking* similarity to the symptoms seen in https://bugreports.qt.io/browse/QTBUG-69388 !
[Bug c++/87665] [8/9 Regression] gcc HEAD (svn: 265340) breaks elements on resize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87665 --- Comment #7 from Jonathan Wakely --- On x86_64 it fails with -O1 -fstrict-aliasing -ftree-loop-vectorize It still fails if every -fno-xxx option for -O1 is added except -fno-tree-copy-prop so it seems to require: -fstrict-aliasing -ftree-loop-vectorize -ftree-copy-prop On ppc64le it also fails with -O1 -fstrict-aliasing -ftree-loop-vectorize but -ftree-copy-prop isn't the only -O1 pass that matters, several of the -O1 passes are needed to cause the bug (including at least -ftree-copy-prop -ftree-ch -ftree-forwprop but also others I haven't isolated).
[Bug c++/87665] [8/9 Regression] gcc HEAD (svn: 265340) breaks elements on resize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87665 --- Comment #6 from Jonathan Wakely --- Since r254694 only changed all -std modes to match -std=c++17 I bisected again using -std=c++17 to find the change that really caused it, and it was indeed r246301 which first removed that null check. However, this isn't the full story, because on x86_64 we generate correct code at r246301 and r254694, even after Ville's changes removed the null check. For x86_64 everything is OK until r255268. Weird.
[Bug c++/87665] [8/9 Regression] gcc HEAD (svn: 265340) breaks elements on resize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87665 --- Comment #5 from Jonathan Wakely --- Confirmed that -fcheck-null fixes the miscompilation.
[Bug c++/87665] [8/9 Regression] gcc HEAD (svn: 265340) breaks elements on resize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87665 Jonathan Wakely changed: What|Removed |Added CC||ville at gcc dot gnu.org Target Milestone|8.3 |--- --- Comment #4 from Jonathan Wakely --- Bisecting on powerpc64le shows it regressed with r254694 which makes a bit more sense (as std::vector reallocation does use placement new to move the values): Remove the null check from placement new in all modes gcc/cp/ Remove the null check from placement new in all modes * init.c (build_new_1): Don't do a null check for a namespace-scope non-replaceable placement new in any mode unless -fcheck-new is provided. testsuite/ Remove the null check from placement new in all modes * g++.dg/init/pr35878_1.C: Adjust. * g++.dg/init/pr35878_4.C: New. * g++.dg/torture/pr48695.C: Adjust. * g++.dg/tree-ssa/pr31146-2.C: Likewise. * g++.dg/tree-ssa/pr41428.C: Adjust.
[Bug c++/87665] [8/9 Regression] gcc HEAD (svn: 265340) breaks elements on resize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87665 Richard Biener changed: What|Removed |Added Target Milestone|--- |8.3
[Bug c++/87665] [8/9 Regression] gcc HEAD (svn: 265340) breaks elements on resize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87665 --- Comment #3 from Jan Christoph Uhde --- ยป g++-head -v Using built-in specs. COLLECT_GCC=g++-head COLLECT_LTO_WRAPPER=/bal/gcc_trunk_install/bin/../libexec/gcc/x86_64-pc-linux-gnu/9.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc_trunk/configure --prefix=/bla/gcc_trunk_install --program-suffix=-head --disable-multilib Thread model: posix gcc version 9.0.0 20181020 (experimental) (GCC)
[Bug c++/87665] [8/9 Regression] gcc HEAD (svn: 265340) breaks elements on resize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87665 --- Comment #2 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #1) > The behaviour changed with r255268 Which doesn't make sense as the bug seems to be target-independent.
[Bug c++/87665] [8/9 Regression] gcc HEAD (svn: 265340) breaks elements on resize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87665 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work||7.3.0 Keywords||wrong-code Last reconfirmed||2018-10-20 CC||hubicka at gcc dot gnu.org Ever confirmed|0 |1 Summary|gcc HEAD (svn: 265340) |[8/9 Regression] gcc HEAD |breaks elements on resize |(svn: 265340) breaks ||elements on resize Known to fail||8.2.0, 9.0 --- Comment #1 from Jonathan Wakely --- (In reply to Jan Christoph Uhde from comment #0) > gcc was build with `--disable-multilib` and custom suffix and prefix on > Debian stable and sid. The output of 'gcc -v' includes all that and more, which is why we ask for it. The behaviour changed with r255268 PR target/81616 * x86-tnue-costs.h (generic_cost): Revise for modern CPUs * gcc.target/i386/l_fma_double_1.c: Update count of fma instructions. * gcc.target/i386/l_fma_double_2.c: Update count of fma instructions. * gcc.target/i386/l_fma_double_3.c: Update count of fma instructions. * gcc.target/i386/l_fma_double_4.c: Update count of fma instructions. * gcc.target/i386/l_fma_double_5.c: Update count of fma instructions. * gcc.target/i386/l_fma_double_6.c: Update count of fma instructions. * gcc.target/i386/l_fma_float_1.c: Update count of fma instructions. * gcc.target/i386/l_fma_float_2.c: Update count of fma instructions. * gcc.target/i386/l_fma_float_3.c: Update count of fma instructions. * gcc.target/i386/l_fma_float_4.c: Update count of fma instructions. * gcc.target/i386/l_fma_float_5.c: Update count of fma instructions. * gcc.target/i386/l_fma_float_6.c: Update count of fma instructions.
