[Bug libstdc++/89464] shared_ptr_base.h: error: '__tag' was not declared in this scope (gcc-8.3.0 regression?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89464 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #3 from Andrew Pinski --- Someone is doing: #define alignas(x) __attribute__((aligned(x))) Which is not valid as alignas does take a type name also. You can figure out who by adding -g3 (with -save-temps still) and looking at the .ii file to see who defines it. Easies way to fix this is to reorder the header files: #include "HDHomeRunTuners.h" #include #include #include #include #include #include #include So the system ones are included first. But this is not a GCC issue.
[Bug libstdc++/89464] shared_ptr_base.h: error: '__tag' was not declared in this scope (gcc-8.3.0 regression?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89464 --- Comment #2 from Milhouse --- This is a new build log, with -save-temps added: http://ix.io/1BOD I've uploaded the PVR HDHomeRun build directory as a tar.gz: http://milhouse.libreelec.tv/other/pvrhdhomerun.tar.gz This directory includes .s, .i, .ii etc. files - hopefully this is what you are looking for.
[Bug other/704] --help and --version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=704 --- Comment #20 from Iain Sandoe --- (In reply to Eric Gallager from comment #19) > (In reply to jos...@codesourcery.com from comment #18) > > Whether this is fixed may be determined by running all of the programs > > installed in $exec_prefix/bin by current mainline with the --help and > > --version options (and confirming the GCC version number is properly shown > > in the --version output). > > looks like gcc-nm and gcc-ranlib still fail with --help: That's not a fault with the GCC wrappers, it's because the "upstream" cctools nm and ranlib don't respond to "--help" (or --version). I have amended versions of them that handle --help and --version (available on github***) that work: $ ./gcc/gcc-ar --help usage: ar -d [-TLsv] archive file ... ar -m [-TLsv] archive file ... $ ./gcc/gcc-ar --version xtools-1.1.0 ar - the point is that this is not a problem with the GCC wrappers, the intention of them is to pass the --help and --version onto the underlying commands. >From the point of view of Darwin, I'd say this could be closed, of course it might not be completely clean for other platforms. *** Note: the versions published on github are quite old - on the TODO to provide some updates.
[Bug libstdc++/89464] shared_ptr_base.h: error: '__tag' was not declared in this scope (gcc-8.3.0 regression?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89464
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed||2019-02-23
Component|c++ |libstdc++
Ever confirmed|0 |1
--- Comment #1 from Andrew Pinski ---
17b46dadecbf (redi 2018-11-22 15:02:46 + 510) alignas(type_info)
static constexpr char __tag[sizeof(type_info)] = { };
0d9884f7ccc3 (redi 2017-05-11 13:21:07 + 511) return
reinterpret_cast(__tag);
Hmm, it is there for me.
Can you add -save-temps and provide the preprocessed source?
[Bug c++/89464] New: shared_ptr_base.h: error: '__tag' was not declared in this scope (gcc-8.3.0 regression?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89464 Bug ID: 89464 Summary: shared_ptr_base.h: error: '__tag' was not declared in this scope (gcc-8.3.0 regression?) Product: gcc Version: 8.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: gcc at nmacleod dot com Target Milestone: --- I've just tried building the LibreELEC operating system with gcc-8.3.0 (glibc 2.29) and it has failed when compiling the Kodi addon "PVR HDHomeRun"[1]. The compile error is: /home/neil/projects/scratch/alternates/LibreELEC.tv/build.LibreELEC-Generic.x86_64-9.1-devel-gcc/toolchain/bin/x86_64-libreelec-linux-gnu-g++ -DADDON_GLOBAL_VERSION_MAIN_USED -DADDON_INSTANCE_VERSION_PVR_USED -DBUILD_KODI_ADDON -Dpvr_hdhomerun_EXPORTS -I/home/neil/projects/scratch/alternates/LibreELEC.tv/build.LibreELEC-Generic.x86_64-9.1-devel-gcc/toolchain/x86_64-libreelec-linux-gnu/sysroot/usr/include -I/home/neil/projects/scratch/alternates/LibreELEC.tv/build.LibreELEC-Generic.x86_64-9.1-devel-gcc/toolchain/x86_64-libreelec-linux-gnu/sysroot/usr/include/kodi -I/home/neil/projects/scratch/alternates/LibreELEC.tv/build.LibreELEC-Generic.x86_64-9.1-devel-gcc/toolchain/x86_64-libreelec-linux-gnu/sysroot/usr/include/p8-platform -I/home/neil/projects/scratch/alternates/LibreELEC.tv/build.LibreELEC-Generic.x86_64-9.1-devel-gcc/toolchain/x86_64-libreelec-linux-gnu/sysroot/usr/include/hdhomerun -march=x86-64 -m64 -mmmx -msse -msse2 -mfpmath=sse -fomit-frame-pointer -Wall -pipe -Os -std=c++11 -Os -DNDEBUG -fPIC -D_LINUX -DTARGET_POSIX -DTARGET_LINUX -D_GNU_SOURCE -DHAVE_LINUX_MEMFD=1 -DHAVE_MKOSTEMP=1 -DHAVE_SSE=1 -DHAVE_SSE2=1 -DHAVE_SSE3=1 -DHAVE_SSSE3=1 -DHAVE_SSE4_1=1 -MD -MT CMakeFiles/pvr.hdhomerun.dir/src/HDHomeRunTuners.cpp.o -MF CMakeFiles/pvr.hdhomerun.dir/src/HDHomeRunTuners.cpp.o.d -o CMakeFiles/pvr.hdhomerun.dir/src/HDHomeRunTuners.cpp.o -c ../src/HDHomeRunTuners.cpp In file included from /home/neil/projects/scratch/alternates/LibreELEC.tv/build.LibreELEC-Generic.x86_64-9.1-devel-gcc/toolchain/x86_64-libreelec-linux-gnu/include/c++/8.3.0/bits/shared_ptr.h:52, from /home/neil/projects/scratch/alternates/LibreELEC.tv/build.LibreELEC-Generic.x86_64-9.1-devel-gcc/toolchain/x86_64-libreelec-linux-gnu/include/c++/8.3.0/memory:81, from ../src/HDHomeRunTuners.cpp:30: /home/neil/projects/scratch/alternates/LibreELEC.tv/build.LibreELEC-Generic.x86_64-9.1-devel-gcc/toolchain/x86_64-libreelec-linux-gnu/include/c++/8.3.0/bits/shared_ptr_base.h: In static member function 'static const std::type_info& std::_Sp_make_shared_tag::_S_ti()': /home/neil/projects/scratch/alternates/LibreELEC.tv/build.LibreELEC-Generic.x86_64-9.1-devel-gcc/toolchain/x86_64-libreelec-linux-gnu/include/c++/8.3.0/bits/shared_ptr_base.h:511:49: error: '__tag' was not declared in this scope return reinterpret_cast(__tag); ^ The build log for this addon is here: http://ix.io/1BOs The PVR HDHomeRun code compiles without issue when using gcc-8.2.0 instead of gcc-8.3.0, so maybe this is a gcc-8.3.0 regression? gcc-8.3.0 has been built from source along with the rest of the LibreELEC toolchain. The build host is Ubuntu 17.10. 1. https://github.com/kodi-pvr/pvr.hdhomerun/blob/master/src/HDHomeRunTuners.cpp#L30
[Bug fortran/89462] gfortran loops in code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89462 Jerry DeLisle changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-02-23 CC||jvdelisle at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jerry DeLisle --- Confirmed on trunk.
[Bug libstdc++/89446] [7/8 Regression] __builtin_constant_p expression crashes in char_traits::compare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89446 --- Comment #5 from Jonathan Wakely --- Author: redi Date: Sat Feb 23 03:01:59 2019 New Revision: 269148 URL: https://gcc.gnu.org/viewcvs?rev=269148=gcc=rev Log: PR libstdc++/89446 fix null pointer dereference in char_traits PR libstdc++/89446 * include/bits/char_traits.h (__constant_char_array): Check index is in range before dereferencing. (char_traits::compare, char_traits::find) (char_traits::compare, char_traits::find): Return immediately if n is zero. (char_traits::compare, char_traits::find): Likewise. Remove workarounds for PR 67026. * testsuite/21_strings/basic_string_view/operators/char/89446.cc: New test. * testsuite/21_strings/basic_string_view/operators/wchar_t/89446.cc: New test. Added: trunk/libstdc++-v3/testsuite/21_strings/basic_string_view/operators/char/89446.cc trunk/libstdc++-v3/testsuite/21_strings/basic_string_view/operators/wchar_t/89446.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/char_traits.h
[Bug c++/67026] GCC incorrectly rejects well-formed constexpr function definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67026 --- Comment #7 from Jonathan Wakely --- Author: redi Date: Sat Feb 23 03:01:59 2019 New Revision: 269148 URL: https://gcc.gnu.org/viewcvs?rev=269148=gcc=rev Log: PR libstdc++/89446 fix null pointer dereference in char_traits PR libstdc++/89446 * include/bits/char_traits.h (__constant_char_array): Check index is in range before dereferencing. (char_traits::compare, char_traits::find) (char_traits::compare, char_traits::find): Return immediately if n is zero. (char_traits::compare, char_traits::find): Likewise. Remove workarounds for PR 67026. * testsuite/21_strings/basic_string_view/operators/char/89446.cc: New test. * testsuite/21_strings/basic_string_view/operators/wchar_t/89446.cc: New test. Added: trunk/libstdc++-v3/testsuite/21_strings/basic_string_view/operators/char/89446.cc trunk/libstdc++-v3/testsuite/21_strings/basic_string_view/operators/wchar_t/89446.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/char_traits.h
[Bug target/81652] [meta-bug] -fcf-protection=full bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81652 Bug 81652 depends on bug 89353, which changed state. Bug 89353 Summary: Unnecessary ENDBR with -mmanual-endbr https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89353 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug target/89353] Unnecessary ENDBR with -mmanual-endbr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89353 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from H.J. Lu --- Unnecessary ENDBR should be fixed by PR 89355. *** This bug has been marked as a duplicate of bug 89355 ***
[Bug target/89355] Unnecessary ENDBR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89355 --- Comment #4 from H.J. Lu --- *** Bug 89353 has been marked as a duplicate of this bug. ***
[Bug c/77970] inconsistent and unhelpful -Wformat warning for %lc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77970 Martin Sebor changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2019-02-23 Ever confirmed|0 |1 Known to fail||7.3.0, 8.2.0, 9.0 --- Comment #2 from Martin Sebor --- See also https://gcc.gnu.org/ml/gcc-patches/2019-02/msg01862.html for some of the headaches this causes. Confirmed on that basis.
[Bug debug/89463] debug information for iteractor of an empty loop is gone (at -O3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89463 --- Comment #2 from Qirun Zhang --- (In reply to Andrew Pinski from comment #1) > What is happening is the empty loop is being removed and not replaced with a > debug statement say i is 6 afterwards. I don't know if this is a good idea > to put a debug statement here or not. Agreed. Nevertheless, it should not print a wrong value. The expected behavior is "" like what gcc-6.5.0 does as follows: $ gcc-6 -O3 out.c abc.c -g $ gdb-trunk -x cmds -batch a.out Breakpoint 1 at 0x547: file abc.c, line 8. Breakpoint 1, main () at abc.c:8 8 optimize_me_not(); $1 = Kill the program being debugged? (y or n) [answered Y; input not from terminal] [Inferior 1 (process 17644) killed]
[Bug debug/89463] debug information for iteractor of an empty loop is gone (at -O3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89463 Andrew Pinski changed: What|Removed |Added Summary|gcc generates wrong debug |debug information for |information at -O3 |iteractor of an empty loop ||is gone (at -O3) Severity|normal |enhancement --- Comment #1 from Andrew Pinski --- What is happening is the empty loop is being removed and not replaced with a debug statement say i is 6 afterwards. I don't know if this is a good idea to put a debug statement here or not.
[Bug debug/89463] New: gcc generates wrong debug information at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89463
Bug ID: 89463
Summary: gcc generates wrong debug information at -O3
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: qrzhang at gatech dot edu
Target Milestone: ---
It bug affects the latest trunk.
It also affects gcc-8 and gcc-7.
gcc-6 works fine.
With "-O3", it incorrectly prints "i=0".
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/home/absozero/trunk/root-gcc/libexec/gcc/x86_64-pc-linux-gnu/9.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/home/absozero/trunk/root-gcc
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 9.0.1 20190222 (experimental) [trunk revision 269113] (GCC)
$ cat abc.c
int a;
int main() {
int i;
for (; a < 10; a++)
i = 0;
for (; i < 6; i++)
;
optimize_me_not();
}
$ cat outer.c
optimize_me_not() {}
$ cat cmds
b 8
r
p i
kill
q
$ gcc-trunk -g abc.c outer.c
$ gdb-trunk -x cmds -batch a.out
Breakpoint 1 at 0x4004b9: file abc.c, line 8.
Breakpoint 1, main () at abc.c:8
8 optimize_me_not();
$1 = 6
Kill the program being debugged? (y or n) [answered Y; input not from terminal]
[Inferior 1 (process 29883) killed]
$ gcc-trunk -g abc.c outer.c -O3
$ gdb-trunk -x cmds -batch a.out
Breakpoint 1 at 0x4003b7: file abc.c, line 8.
Breakpoint 1, main () at abc.c:8
8 optimize_me_not();
$1 = 0
Kill the program being debugged? (y or n) [answered Y; input not from terminal]
[Inferior 1 (process 31868) killed]
[Bug c++/89390] [9 Regression] ICE in get_string, at spellcheck-tree.h:46
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89390 --- Comment #5 from David Malcolm --- Author: dmalcolm Date: Sat Feb 23 01:19:38 2019 New Revision: 269145 URL: https://gcc.gnu.org/viewcvs?rev=269145=gcc=rev Log: Capture source location of dtors (PR c++/89390) gcc/cp/ChangeLog: PR c++/89390 * parser.c (cp_parser_unqualified_id): Capture and use locations for destructors. gcc/testsuite/ChangeLog: PR c++/89390 * g++.dg/diagnostic/pr89390.C: Update expected location of error, renaming to a multicharacter name, so that start != finish. Add tests for dtor locations. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/diagnostic/pr89390.C
[Bug c++/84939] [7/8/9 Regression] internal compiler error: in gimplify_expr, at gimplify.c:12382
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84939
--- Comment #4 from Paolo Carlini ---
This also crashes the compiler, in a different way:
void b() {
struct c {
int d struct d e;
};
}
[Bug libstdc++/89446] [7/8 Regression] __builtin_constant_p expression crashes in char_traits::compare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89446 --- Comment #4 from Jonathan Wakely --- Author: redi Date: Sat Feb 23 01:02:05 2019 New Revision: 269144 URL: https://gcc.gnu.org/viewcvs?rev=269144=gcc=rev Log: PR libstdc++/89446 fix null pointer dereference in char_traits PR libstdc++/89446 * include/bits/char_traits.h (__constant_char_array): Check index is in range before dereferencing. * testsuite/21_strings/basic_string_view/operators/char/89446.cc: New test. Added: branches/gcc-8-branch/libstdc++-v3/testsuite/21_strings/basic_string_view/operators/char/89446.cc Modified: branches/gcc-8-branch/libstdc++-v3/ChangeLog branches/gcc-8-branch/libstdc++-v3/include/bits/char_traits.h
[Bug libstdc++/89446] [7/8 Regression] __builtin_constant_p expression crashes in char_traits::compare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89446 --- Comment #3 from Jonathan Wakely --- Author: redi Date: Sat Feb 23 01:01:56 2019 New Revision: 269143 URL: https://gcc.gnu.org/viewcvs?rev=269143=gcc=rev Log: PR libstdc++/89446 fix null pointer dereference in char_traits PR libstdc++/89446 * include/bits/char_traits.h (__constant_char_array): Check index is in range before dereferencing. * testsuite/21_strings/basic_string_view/operators/char/89446.cc: New test. Added: branches/gcc-7-branch/libstdc++-v3/testsuite/21_strings/basic_string_view/operators/char/89446.cc Modified: branches/gcc-7-branch/libstdc++-v3/ChangeLog branches/gcc-7-branch/libstdc++-v3/include/bits/char_traits.h
[Bug libstdc++/89460] FAIL: experimental/net/headers.cc (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89460 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-02-23 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Ever confirmed|0 |1
[Bug tree-optimization/88074] [7/8 Regression] g++ hangs on math expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88074 --- Comment #33 from Jakub Jelinek --- Author: jakub Date: Sat Feb 23 00:14:52 2019 New Revision: 269139 URL: https://gcc.gnu.org/viewcvs?rev=269139=gcc=rev Log: PR middle-end/88074 * simplify.c (norm2_do_sqrt, gfc_simplify_norm2): Use mpfr_number_p && !mpfr_zero_p instead of mpfr_regular_p. (norm2_add_squared): Likewise. Use mp_exp_t rather than mpfr_exp_t. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/simplify.c
[Bug libquadmath/89459] Incorrect rounding for fma in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89459 --- Comment #1 from joseph at codesourcery dot com --- Please see whether this still applies with GCC mainline (postdating my 2018-11-07 merge of fmaq changes from glibc which brought in at least one bug fix).
[Bug c++/84676] [7 Regression] internal compiler error: Segmentation fault (build_new_op_1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84676 Paolo Carlini changed: What|Removed |Added Summary|[7/8/9 Regression] internal |[7 Regression] internal |compiler error: |compiler error: |Segmentation fault |Segmentation fault |(build_new_op_1)|(build_new_op_1) --- Comment #6 from Paolo Carlini --- This is fixed in trunk and 8.1.0.
[Bug c++/84676] [7/8/9 Regression] internal compiler error: Segmentation fault (build_new_op_1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84676 --- Comment #5 from paolo at gcc dot gnu.org --- Author: paolo Date: Fri Feb 22 23:16:14 2019 New Revision: 269138 URL: https://gcc.gnu.org/viewcvs?rev=269138=gcc=rev Log: 2019-02-22 Paolo Carlini PR c++/84676 * g++.dg/cpp0x/pr84676.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/pr84676.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 Bug 26163 depends on bug 86448, which changed state. Bug 86448 Summary: GCC 9 compiler generates slower code for spec 2006 milc on a power9 using -mcpu=power9 than using -mcpu=power8 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86448 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME
[Bug target/86448] GCC 9 compiler generates slower code for spec 2006 milc on a power9 using -mcpu=power9 than using -mcpu=power8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86448 Bill Schmidt changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #7 from Bill Schmidt --- Not confirmed at this time. Let's close it until we have something more definitive to look at.
[Bug target/89411] RISC-V backend will generate wrong instruction for longlong type like lw a3,-2048(a5)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89411 Jim Wilson changed: What|Removed |Added CC||wilson at gcc dot gnu.org --- Comment #1 from Jim Wilson --- I think the problem is in riscv_valid_lo_sum_p where we do /* We may need to split multiword moves, so make sure that each word can be accessed without inducing a carry. */ if (GET_MODE_SIZE (mode) > UNITS_PER_WORD && (!TARGET_STRICT_ALIGN || GET_MODE_BITSIZE (mode) > GET_MODE_ALIGNMENT (mode))) return false; The problem is that this doesn't work for BLKmode, as GET_MODE_SIZE, GET_MODE_BITSIZE, and GET_MODE_ALIGNMENT don't return usable values for BLKmode. We could perhaps just return false for mode == BLKmode here, but that requires some testing to see what conditions BLKmode might appear here. We don't want to accidentally disable this optimization when it is useful and safe. Best case solution is probably to pass down a decl or a MEM, so we can get the actual size and alignment from there. That is a little bit more work, so I only want to do that if necessary.
[Bug target/89456] target attribute doesn't work well with -mXXX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89456 --- Comment #2 from H.J. Lu --- On AVX2 machine: [hjl@gnu-skx-1 tmp]$ gcc /export/gnu/import/git/gitlab/x86-gcc/gcc/testsuite/g++.target/i386/mv17.C [hjl@gnu-skx-1 tmp]$ ./a.out [hjl@gnu-skx-1 tmp]$ gcc /export/gnu/import/git/gitlab/x86-gcc/gcc/testsuite/g++.target/i386/mv17.C -march=haswell [hjl@gnu-skx-1 tmp]$ ./a.out a.out: /export/gnu/import/git/gitlab/x86-gcc/gcc/testsuite/g++.target/i386/mv17.C:39: int main(): Assertion `val == 2' failed. Aborted [hjl@gnu-skx-1 tmp]$
[Bug libstdc++/89461] New: FAIL: experimental/net/timer/waitable/cons.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89461 Bug ID: 89461 Summary: FAIL: experimental/net/timer/waitable/cons.cc Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Target Milestone: --- Host: hppa*-*-hpux* Target: hppa*-*-hpux* Build: hppa*-*-hpux* spawn /test/gnu/gcc/objdir/./gcc/xg++ -shared-libgcc -B/test/gnu/gcc/objdir/./gc c -nostdinc++ -L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/src -L/tes t/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/src/.libs -L/test/gnu/gcc/objd ir/hppa64-hp-hpux11.11/libstdc++-v3/libsupc++/.libs -B/opt/gnu64/gcc/gcc-9/hppa6 4-hp-hpux11.11/bin/ -B/opt/gnu64/gcc/gcc-9/hppa64-hp-hpux11.11/lib/ -isystem /op t/gnu64/gcc/gcc-9/hppa64-hp-hpux11.11/include -isystem /opt/gnu64/gcc/gcc-9/hppa 64-hp-hpux11.11/sys-include -fchecking=1 -B/test/gnu/gcc/objdir/hppa64-hp-hpux11 .11/./libstdc++-v3/src/.libs -fmessage-length=0 -fno-show-column -ffunction-sect ions -fdata-sections -g -O2 -DLOCALEDIR="." -nostdinc++ -I/test/gnu/gcc/objdir/h ppa64-hp-hpux11.11/libstdc++-v3/include/hppa64-hp-hpux11.11 -I/test/gnu/gcc/objd ir/hppa64-hp-hpux11.11/libstdc++-v3/include -I/test/gnu/gcc/gcc/libstdc++-v3/lib supc++ -I/test/gnu/gcc/gcc/libstdc++-v3/include/backward -I/test/gnu/gcc/gcc/lib stdc++-v3/testsuite/util /test/gnu/gcc/gcc/libstdc++-v3/testsuite/experimental/n et/timer/waitable/cons.cc -include bits/stdc++.h -fno-diagnostics-show-caret -fd iagnostics-color=never ./libtestc++.a /opt/gnu64/lib/libiconv.sl -Wl,+b -Wl,/opt /gnu64/lib -L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/src/filesyste m/.libs -lm -o ./cons.exe ld: Unsatisfied symbol "__atomic_fetch_sub_8" in file /var/tmp//ccK5pq8s.o 1 errors. collect2: error: ld returned 1 exit status compiler exited with status 1 output is: ld: Unsatisfied symbol "__atomic_fetch_sub_8" in file /var/tmp//ccK5pq8s.o 1 errors. collect2: error: ld returned 1 exit status FAIL: experimental/net/timer/waitable/cons.cc (test for excess errors) Excess errors: ld: Unsatisfied symbol "__atomic_fetch_sub_8" in file /var/tmp//ccK5pq8s.o 1 errors. collect2: error: ld returned 1 exit status Setting LD_LIBRARY_PATH to :/test/gnu/gcc/objdir/gcc:/test/gnu/gcc/objdir/hppa64 -hp-hpux11.11/./libstdc++-v3/../libatomic/.libs:/test/gnu/gcc/objdir/hppa64-hp-h pux11.11/./libstdc++-v3/../libgomp/.libs:/test/gnu/gcc/objdir/hppa64-hp-hpux11.1 1/./libstdc++-v3/src/.libs::/test/gnu/gcc/objdir/gcc:/test/gnu/gcc/objdir/hppa64 -hp-hpux11.11/./libstdc++-v3/../libatomic/.libs:/test/gnu/gcc/objdir/hppa64-hp-h pux11.11/./libstdc++-v3/../libgomp/.libs:/test/gnu/gcc/objdir/hppa64-hp-hpux11.1 1/./libstdc++-v3/src/.libs FAIL: experimental/net/timer/waitable/cons.cc execution test Similar fails: FAIL: experimental/net/timer/waitable/dest.cc (test for excess errors) FAIL: experimental/net/timer/waitable/dest.cc execution test FAIL: experimental/net/timer/waitable/ops.cc (test for excess errors) FAIL: experimental/net/timer/waitable/ops.cc execution test
[Bug libstdc++/89460] New: FAIL: experimental/net/headers.cc (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89460 Bug ID: 89460 Summary: FAIL: experimental/net/headers.cc (test for excess errors) Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Target Milestone: --- Host: hppa*-*-hpux* Target: hppa*-*-hpux* Build: hppa*-*-hpux* spawn /test/gnu/gcc/objdir/./gcc/xg++ -shared-libgcc -B/test/gnu/gcc/objdir/./gc c -nostdinc++ -L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/src -L/tes t/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/src/.libs -L/test/gnu/gcc/objd ir/hppa64-hp-hpux11.11/libstdc++-v3/libsupc++/.libs -B/opt/gnu64/gcc/gcc-9/hppa6 4-hp-hpux11.11/bin/ -B/opt/gnu64/gcc/gcc-9/hppa64-hp-hpux11.11/lib/ -isystem /op t/gnu64/gcc/gcc-9/hppa64-hp-hpux11.11/include -isystem /opt/gnu64/gcc/gcc-9/hppa 64-hp-hpux11.11/sys-include -fchecking=1 -B/test/gnu/gcc/objdir/hppa64-hp-hpux11 .11/./libstdc++-v3/src/.libs -fmessage-length=0 -fno-show-column -ffunction-sect ions -fdata-sections -g -O2 -DLOCALEDIR="." -nostdinc++ -I/test/gnu/gcc/objdir/h ppa64-hp-hpux11.11/libstdc++-v3/include/hppa64-hp-hpux11.11 -I/test/gnu/gcc/objd ir/hppa64-hp-hpux11.11/libstdc++-v3/include -I/test/gnu/gcc/gcc/libstdc++-v3/lib supc++ -I/test/gnu/gcc/gcc/libstdc++-v3/include/backward -I/test/gnu/gcc/gcc/lib stdc++-v3/testsuite/util /test/gnu/gcc/gcc/libstdc++-v3/testsuite/experimental/n et/headers.cc -include bits/stdc++.h -fno-diagnostics-show-caret -fdiagnostics-c olor=never -S -o headers.s In file included from /test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/incl ude/experimental/net:40, from /test/gnu/gcc/gcc/libstdc++-v3/testsuite/experimental/net/ headers.cc:20: /test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/experimental/socke t: In member function 'bool std::experimental::net::v1::basic_socket<_Protocol>: :at_mark(std::error_code&) const': /test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/experimental/socke t:798: error: '::sockatmark' has not been declared compiler exited with status 1 output is: In file included from /test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/incl ude/experimental/net:40, from /test/gnu/gcc/gcc/libstdc++-v3/testsuite/experimental/net/ headers.cc:20: /test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/experimental/socke t: In member function 'bool std::experimental::net::v1::basic_socket<_Protocol>: :at_mark(std::error_code&) const': /test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/experimental/socke t:798: error: '::sockatmark' has not been declared FAIL: experimental/net/headers.cc (test for excess errors) Excess errors: /test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/experimental/socket:798: error: '::sockatmark' has not been declared
[Bug rtl-optimization/89445] [9 regression] _mm512_maskz_loadu_pd "forgets" to use the mask
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89445 --- Comment #8 from Thiago Macieira --- Sorry, in editing I ended up removing an important point: GCC 8 also generates the move *from* OpMask when I put it in the benchmark loop. So that's not a regression, per se.
[Bug libfortran/52879] Pathological reseeding of PRNG generator genernates poor sequence
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52879 --- Comment #7 from Dominique d'Humieres --- > I think the current implementation has a decent protection against bad seeds, > so lets close this as fixed. The least I can say is that I am not convinced about the "decent protection".
[Bug rtl-optimization/89445] [9 regression] _mm512_maskz_loadu_pd "forgets" to use the mask
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89445
--- Comment #7 from Thiago Macieira ---
Comment on attachment 45800
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45800
gcc9-pr89445.patch
Tested and works on my machine.
The movzbl that GCC 8 generated is also gone, but it inserted moves *from* the
OpMask register:
.L4:
movq%rcx, %rax
addq$64, %rcx
cmpq%rdi, %rcx
kmovw %k1, %r9d
cmova %r8d, %r9d
kmovw %r9d, %k1
vmovupd (%rsi,%rax), %zmm1{%k1}{z}
addq%rdx, %rax
vmovupd (%rax), %zmm2{%k1}{z}
vfmadd132pd %zmm0, %zmm2, %zmm1
vmovupd %zmm1, (%rax){%k1}
cmpq%rdi, %rcx
jb .L4
Seems like it forgot the GPR that used to contain the mask, so it needed to
reload from %k1. The end detection is also slightly worse.
Yesterday, when I benchmarked with GCC 8, it ran 1000 iterations over 10
million doubles in roughly 11.9 ms, with 10 million instructions. Today, I am
getting 11.8 ms at 16 million instructions (the increase of instructions/cycle
is roughly equal to the decrease in instructions per iteration, proving that
memory bandwidth is the bottleneck)
[Bug libstdc++/77691] [7/8/9 regression] experimental/memory_resource/resource_adaptor.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691 John David Anglin changed: What|Removed |Added CC||danglin at gcc dot gnu.org --- Comment #27 from John David Anglin --- Fails with gcc-9 on hppa64-hp-hpux11.11.
[Bug target/89071] AVX vcvtsd2ss lets us avoid PXOR dependency breaking for scalar float<->double and other scalar xmm,xmm instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89071 --- Comment #22 from Peter Cordes --- Nice, that's exactly the kind of thing I suggested in bug 80571. If this covers * vsqrtss/sd (mem),%merge_into, %xmm * vpcmpeqd%same,%same, %dest# false dep on KNL / Silvermont * vcmptrueps %same,%same, %ymm # splat -1 without AVX2. false dep on all known uarches as well as int->FP conversions, then we could probably close that as fixed by this as well. bug 80571 does suggest that we could look for any cold reg, like a non-zero constant, instead of requiring an xor-zeroed vector, so it might go slightly beyond what this patch does. And looking for known-to-be-ready dead regs from earlier in the same dep chain could certainly be useful for non-AVX code-gen, allowing us to copy-and-sqrt without introducing a dependency on anything that's not already ready. (In reply to h...@gcc.gnu.org from comment #21) > Author: hjl > Date: Fri Feb 22 15:54:08 2019 > New Revision: 269119
[Bug c++/89450] RFC: Strengthen -fstrict-enums
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89450
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
--- Comment #6 from Eric Gallager ---
(In reply to Jonathan Wakely from comment #5)
> (In reply to Martin Liška from comment #0)
> > Issues is that:
> >
> > 14746/* If -fstrict-enums, still constrain TYPE_MIN/MAX_VALUE. */
> > 14747if (flag_strict_enums)
> > 14748 set_min_and_max_values_for_integral_type (enumtype,
> > precision, sgn);
> >
> > is called for precision, which sets min = 0 and max = 7.
>
> Because that's how enums work in C++, as required by the standard.
>
> That's not an issue.
>
> > What about doing:
> >
> > diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
> > index 612afbacd27..46302b4a61d 100644
> > --- a/gcc/cp/decl.c
> > +++ b/gcc/cp/decl.c
> > @@ -14745,7 +14745,10 @@ finish_enum_value_list (tree enumtype)
> >
> >/* If -fstrict-enums, still constrain TYPE_MIN/MAX_VALUE. */
> >if (flag_strict_enums)
> > - set_min_and_max_values_for_integral_type (enumtype, precision, sgn);
> > + {
> > + TYPE_MIN_VALUE (enumtype) = minnode;
> > + TYPE_MAX_VALUE (enumtype) = maxnode;
> > + }
> > }
> >else
> > underlying_type = ENUM_UNDERLYING_TYPE (enumtype);
> >
> > I can also imagine another option level when desired.
>
> Please no. -fstrict-enums currently makes the compiler *more* strictly
> conforming, by following the rules of the standard. Your suggestion arguably
> makes it *less* conforming, by deciding that valid values should emit a
> warning.
>
> What you want is not how enums work in C++. Please don't abuse
> -fstrict-enums when what you want is "some other kind of enum, not one that
> strictly follows the C++ standard".
This reminds me, I think there are some other related bug reports out there,
but I can't find them right now...
[Bug libquadmath/89459] New: Incorrect rounding for fma in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89459 Bug ID: 89459 Summary: Incorrect rounding for fma in some cases Product: gcc Version: 6.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libquadmath Assignee: unassigned at gcc dot gnu.org Reporter: andres_takach at mentor dot com Target Milestone: --- Created attachment 45802 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45802=edit testcase for issue: c++ fma_rnd_bug.cxx -lquadmath The function fmaq(x,y,z) should be equivalent to x*y+z if x*y returns a finite exact value. Test x = smallest (subnormal) hex: 0001 y = 2*(2^112 + 1) hex: 4071 z = x fma(x,y,z) returns hex (same as x*y): 00020001 x*y+z return hex (it is rounded to nearest even): 00020002 GCC version info: Using built-in specs. COLLECT_GCC=/wv/hlstools/gcc6.2.0-64/pkgs/dcs_gcc/gcc-6.2.0/lib/gcc/../../bin/c++ COLLECT_LTO_WRAPPER=/wv/hlstools/gcc6.2.0-64/pkgs/dcs_gcc/gcc-6.2.0/lib/gcc/../../libexec/gcc/x86_64-linux-gnu/6.2.0/lto-wrapper Target: x86_64-linux-gnu Configured with: /wv/hls01/dcs_gcc/rls_iwa/2016-09-27_163927/aol/build/src/gcc-6.2.0/configure --prefix=/wv/hls01/dcs_gcc/rls_iwa/2016-09-27_163927/aol/exports/mgc_home/pkgs/dcs_gcc.aol/gcc-6.2.0 -build=x86_64-linux-gnu --enable-languages=c,c++ --enable-threads --with-dwarf2 --with-pkgversion=Calypto Thread model: posix gcc version 6.2.0 (Calypto)
[Bug rtl-optimization/89445] [9 regression] _mm512_maskz_loadu_pd "forgets" to use the mask
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89445
--- Comment #6 from Thiago Macieira ---
(In reply to Jakub Jelinek from comment #4)
> vmovupd (%rsi,%rax), %zmm1{%k1}{z}
> addq%rdx, %rax
> vmovupd (%rax), %zmm2{%k1}{z}
> vfmadd132pd %zmm0, %zmm2, %zmm1
> vmovupd %zmm1, (%rax){%k1}
> isn't optimal btw, it would be nice if we could merge that masking into the
> vfmadd132pd instruction, like:
> vmovupd (%rsi,%rax), %zmm1{%k1}{z}
> addq%rdx, %rax
> vfmadd132pd (%rax), %zmm2, %zmm1%{k1}{z}
> vmovupd %zmm1, (%rax){%k1}
> but not really sure how to achieve that.
It would be nice. It would be even nicer not to have that "addq". That's
actually what ICC generates (click on the godbolt link and change one of the
compilers to ICC 19):
..B1.3: # Preds ..B1.3 ..B1.2
cmpq %rax, %r8 #12.13
cmova %r10d, %r9d #12.13
kmovw %r9d, %k1 #13.20
vmovupd (%r8,%rsi), %zmm1{%k1}{z} #13.20
vfmadd213pd (%r8,%rdx), %zmm0, %zmm1{%k1}{z}#15.20
vmovupd %zmm1, (%r8,%rdx){%k1}#16.9
addq $64, %r8 #10.48
cmpq %rcx, %r8 #10.32
jb..B1.3# Prob 82% #10.32
There's one more simplification here: ICC lacks the movzbl instruction which
GCC inserted but is completely superfluous. First, we've already calculated the
proper 32-bit pattern and stored it in %r9d, there was no need to zero extend
it. Second, when operating on 512-bit packed doubles, there are 8 lanes, so
only the low 8 bits of the mask register will be considered in the first place.
(Arguably, the intrinsic should have used __mmask8, but that wasn't added until
AVX512DQ and this is F)
That reduces the number of instructions and will save you a couple of uops per
loop. Depending on how long your loop is, it may help you fit in the DSB and
help the Loop Stream Detector. I'm not at all knowledgeable about those
details, so I'll just link to
https://stackoverflow.com/questions/39311872/is-performance-reduced-when-executing-loops-whose-uop-count-is-not-a-multiple-of#answer-39940932.
For this particular loop, if run long enough, I don't think there's any effect,
but this is an area for improvement for longer loops. The number of
instructions is also significant for short-lived loops, which happens to me
often when using SIMD for strings (tens of bytes of length, so the loop is run
once or twice only).
[Bug target/80571] AVX allows multiple vcvtsi2ss/sd (integer -> float/double) to reuse a single dep-breaking vxorps, even hoisting it out of loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80571 --- Comment #2 from Peter Cordes --- I think hjl's patch for PR 89071 / PR 87007 fixes (most of?) this, at least for AVX. If register pressure is an issue, using a reg holding a arbitrary constant (instead of xor-zeroed) is a valid option, as this bug points out. So I'm not sure we should close this as a duplicate of those fixed bugs.
[Bug c++/4898] adding an option to verify exception specifications [-Wexceptions]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=4898 --- Comment #10 from Eric Gallager --- (In reply to Jonathan Wakely from comment #9) > Why a new warning instead of making -Wterminate handle throw() as well as > noexcept ? For consistency with clang? I dunno, I guess putting it under -Wterminate could work too...
[Bug other/704] --help and --version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=704 Eric Gallager changed: What|Removed |Added Status|WAITING |NEW Last reconfirmed|2006-02-02 13:45:08 |2019-2-22 --- Comment #19 from Eric Gallager --- (In reply to jos...@codesourcery.com from comment #18) > Whether this is fixed may be determined by running all of the programs > installed in $exec_prefix/bin by current mainline with the --help and > --version options (and confirming the GCC version number is properly shown > in the --version output). looks like gcc-nm and gcc-ranlib still fail with --help: $ /usr/local/bin/gcc-nm --help error: /opt/iains/x86_64-apple-darwin10/darwin-gcc-5-3r0/bin/nm: invalid argument -- Usage: /opt/iains/x86_64-apple-darwin10/darwin-gcc-5-3r0/bin/nm [-agnopruUmxjlfAP[s segname sectname] [-] [-t format] [[-arch ] ...] [file ...] $ /usr/local/bin/gcc-ranlib --help error: /opt/iains/x86_64-apple-darwin10/darwin-gcc-5-3r0/bin/ranlib: unknown option character `-' in: --help Usage: /opt/iains/x86_64-apple-darwin10/darwin-gcc-5-3r0/bin/ranlib [-sactfqLT] [-] archive [...] $ /usr/local/bin/x86_64-apple-darwin10.8.0-gcc-nm --help error: /opt/iains/x86_64-apple-darwin10/darwin-gcc-5-3r0/bin/nm: invalid argument -- Usage: /opt/iains/x86_64-apple-darwin10/darwin-gcc-5-3r0/bin/nm [-agnopruUmxjlfAP[s segname sectname] [-] [-t format] [[-arch ] ...] [file ...] $ /usr/local/bin/x86_64-apple-darwin10.8.0-gcc-ranlib --help error: /opt/iains/x86_64-apple-darwin10/darwin-gcc-5-3r0/bin/ranlib: unknown option character `-' in: --help Usage: /opt/iains/x86_64-apple-darwin10/darwin-gcc-5-3r0/bin/ranlib [-sactfqLT] [-] archive [...] $
[Bug tree-optimization/82255] Vectorizer cost model overcounts cost of some vectorized loads
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82255 Bill Schmidt changed: What|Removed |Added Target Milestone|8.4 |10.0
[Bug fortran/71066] [7/8 Regression] ICE in set_loop_bounds, at fortran/trans-array.c:4680
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71066 --- Comment #16 from Thomas Koenig --- Author: tkoenig Date: Fri Feb 22 21:02:40 2019 New Revision: 269135 URL: https://gcc.gnu.org/viewcvs?rev=269135=gcc=rev Log: 2019-02-22 Thomas Koenig PR fortran/71066 Backport from trunk * trans-decl.c (generate_coarray_sym_init): For an array constructor in a DATA statement of a coarray variable, set the rank to 1 to avoid confusion later on. If the constructor contains only one value, use that for initiailizig. 2019-02-12 Thomas Koenig PR fortran/71066 Backport from trunk * gfortran.dg/coarray_data_1.f90: New test. Added: branches/gcc-8-branch/gcc/testsuite/gfortran.dg/coarray_data_1.f90 Modified: branches/gcc-8-branch/gcc/fortran/ChangeLog branches/gcc-8-branch/gcc/fortran/trans-decl.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug other/89458] New: adding aligned attribute to struct causes too much to be copied
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89458
Bug ID: 89458
Summary: adding aligned attribute to struct causes too much to
be copied
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: dnikitin at 3redpartners dot com
Target Milestone: ---
If I add __attribute__ ((aligned (256))) to a small struct, the whole 256 bytes
are copied by the default copy constructor. I don't think it's correct. This is
with -O3 optimization. Attached is a piece of code to demo:
struct Obj {
void clone(Obj& r);
void clone2(Obj& r);
int a;
int b;
int c; int c1; int c2; int c3; long c4; long c5; long c6;
}__attribute__ ((aligned (256)));
void Obj::clone(Obj& r) {
*this = r;
}
built like so:
g++ -O3 -std=c++14 -march=skylake
The compilation result is a giant "clone" function that copies 256 bytes of
memory
[Bug target/79251] PowerPC vec_insert generates store-hit-load if the element number is variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79251 Bill Schmidt changed: What|Removed |Added Priority|P5 |P3 Severity|enhancement |normal --- Comment #3 from Bill Schmidt --- Verified this is still a problem in GCC 9.
[Bug other/704] --help and --version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=704 --- Comment #18 from joseph at codesourcery dot com --- Whether this is fixed may be determined by running all of the programs installed in $exec_prefix/bin by current mainline with the --help and --version options (and confirming the GCC version number is properly shown in the --version output).
[Bug fortran/83057] OPEN without a filename and without STATUS='SCRATCH' could produce a warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83057 --- Comment #6 from anlauf at gcc dot gnu.org --- Author: anlauf Date: Fri Feb 22 20:35:38 2019 New Revision: 269134 URL: https://gcc.gnu.org/viewcvs?rev=269134=gcc=rev Log: 2019-02-22 Harald Anlauf PR fortran/83057 * io.c (gfc_match_open): Fix logic in checks of OPEN statement when NEWUNIT= is specified. PR fortran/83057 * gfortran.dg/newunit_6.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/newunit_6.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/io.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/89431] CPP integer macros not defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89431 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |kargl at gcc dot gnu.org Target Milestone|--- |9.0 --- Comment #10 from kargl at gcc dot gnu.org --- Fixed on trunk. Closing.
[Bug libfortran/52879] Pathological reseeding of PRNG generator genernates poor sequence
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52879 Janne Blomqvist changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Janne Blomqvist --- I think the current implementation has a decent protection against bad seeds, so lets close this as fixed.
[Bug fortran/89431] CPP integer macros not defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89431 --- Comment #9 from kargl at gcc dot gnu.org --- Author: kargl Date: Fri Feb 22 20:27:57 2019 New Revision: 269132 URL: https://gcc.gnu.org/viewcvs?rev=269132=gcc=rev Log: 2019-02-22 Steven G. Kargl PR fortran/89431 * gfortran.texi: Fix documentation to match the implementation. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.texi
[Bug ada/89349] segfault when building GCC 8 branch with GCC master
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89349 Eric Botcazou changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org --- Comment #13 from Eric Botcazou --- Testing a backport.
[Bug fortran/84387] Defined output does not work for a derived type that has no components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84387 --- Comment #8 from Jerry DeLisle --- We have confirmed this is addressed in the standard, though, as usual, one has to read two or three conditions and deduce it. 2018: Section 12.6.4.8.4. I am looking at how to fix.
[Bug ada/89349] segfault when building GCC 8 branch with GCC master
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89349 --- Comment #12 from Eric Botcazou --- It's a known historical quirk which has been fixed on the mainline: 2018-05-25 Arnaud Charlet * osint.ads (Unknown_Attributes): No longer pretend this is a constant. (No_File_Info_Cache): Initialize separately. * osint.adb (No_File_Info_Cache): Update initializer. In osint.ads there is: Unknown_Attributes : constant File_Attributes := (others => 0); -- Will be initialized properly at elaboration (for efficiency later on, -- avoid function calls every time we want to reset the attributes). which is both put into read-only memory and written to later...
[Bug ada/89349] segfault when building GCC 8 branch with GCC master
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89349 Eric Botcazou changed: What|Removed |Added Summary|raised STORAGE_ERROR : |segfault when building GCC |stack overflow or erroneous |8 branch with GCC master |memory access when building | |GCC 8 branch with GCC | |master | --- Comment #11 from Eric Botcazou --- The backtrace is: Program received signal SIGSEGV, Segmentation fault. 0x102254bc in __gnat_reset_attributes ( attr=0x1197f4d0 ) at /work/botcazou/gcc-8/src/gcc/ada/adaint.c:337 337 attr->exists = ATTR_UNSET; (gdb) bt #0 0x102254bc in __gnat_reset_attributes ( attr=0x1197f4d0 ) at /work/botcazou/gcc-8/src/gcc/ada/adaint.c:337 #1 0x104a4e54 in () at /work/botcazou/gcc-8/src/gcc/ada/osint.adb:3164 #2 0x106df57c in adainit () at ada/b_gnat1.adb:360 #3 0x1025b3e8 in gnat_parse_file () at /work/botcazou/gcc-8/src/gcc/ada/gcc-interface/misc.c:119 #4 0x10d36ba4 in compile_file () at /work/botcazou/gcc-8/src/gcc/toplev.c:455 #5 0x10d39d5c in do_compile () at /work/botcazou/gcc-8/src/gcc/toplev.c:2132 #6 toplev::main (this=this@entry=0xffd7f638, argc=, argc@entry=35, argv=, argv@entry=0xffd7f8d4) at /work/botcazou/gcc-8/src/gcc/toplev.c:2267 #7 0x11833de4 in main (argc=35, argv=0xffd7f8d4) at /work/botcazou/gcc-8/src/gcc/main.c:39
[Bug target/89456] target attribute doesn't work well with -mXXX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89456
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-02-22
Summary|target attribute doesn't|target attribute doesn't
|work well with |work well with -mXXX
|-march=native |
Ever confirmed|0 |1
--- Comment #1 from H.J. Lu ---
[hjl@gnu-4 pr89456]$ cat x.i
__attribute__ ((target("arch=broadwell")))
float
foo (float x, float y)
{
return y;
}
[hjl@gnu-4 pr89456]$ gcc -O2 -mavx -S x.i
x.i: In function ‘foo’:
x.i:4:1: error: SSE register return with SSE disabled
{
^
[hjl@gnu-4 pr89456]$
[Bug target/89457] New: -madx doesn't generate ADX instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89457
Bug ID: 89457
Summary: -madx doesn't generate ADX instructions
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
Target Milestone: ---
[hjl@gnu-4 pr89456]$ cat y.i
unsigned char
foo (unsigned char __CF, unsigned int __X,
unsigned int __Y, unsigned int *__P)
{
return __builtin_ia32_addcarryx_u32 (__CF, __X, __Y, __P);
}
[hjl@gnu-4 pr89456]$ gcc -S -O2 -madx y.i
[hjl@gnu-4 pr89456]$ cat y.s
.file "y.i"
.text
.p2align 4,,15
.globl foo
.type foo, @function
foo:
.LFB0:
.cfi_startproc
movzbl %dil, %edi
movl%edi, %eax
addb$-1, %al
adcl%edx, %esi
setc%al
movl%esi, (%rcx)
ret
.cfi_endproc
.LFE0:
.size foo, .-foo
.ident "GCC: (GNU) 8.2.1 20190215 (Red Hat 8.2.1-9)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-4 pr89456]$
I am expecting:
addb$-1, %dil
adcxl %edx, %esi
movl%esi, (%rcx)
setb%al
retq
[Bug c++/89420] [9 Regression] ICE: unexpected expression 'int()' of kind cast_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89420 --- Comment #4 from Marek Polacek --- Author: mpolacek Date: Fri Feb 22 19:24:37 2019 New Revision: 269131 URL: https://gcc.gnu.org/viewcvs?rev=269131=gcc=rev Log: PR c++/89420 - ICE with CAST_EXPR in explicit-specifier. * decl.c (build_explicit_specifier): Don't check processing_template_decl. Call instantiation_dependent_expression_p instead of value_dependent_expression_p. Call instantiate_non_dependent_expr_sfinae before build_converted_constant_expr instead of calling instantiate_non_dependent_expr after it. Add processing_template_decl_sentinel. * g++.dg/cpp2a/explicit14.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp2a/explicit14.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog
[Bug c++/89420] [9 Regression] ICE: unexpected expression 'int()' of kind cast_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89420 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Marek Polacek --- Fixed.
[Bug c++/4898] adding an option to verify exception specifications [-Wexceptions]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=4898 --- Comment #9 from Jonathan Wakely --- Why a new warning instead of making -Wterminate handle throw() as well as noexcept ?
[Bug fortran/88117] [9 Regression] ICE in gimplify_var_or_parm_decl, at gimplify.c:2697
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88117 Paul Thomas changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #7 from Paul Thomas --- Created attachment 45801 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45801=edit A patch for the PR. Once you had done the detective work, Thomas, the rest was pretty easy. Basically, the fact that 'z' is a pointer is what throws it. Bootstraps and retests OK. The patch to trans-expr.c has a large offset because my ISO_Fortran_binding patch is on the tree, awaiting a green light. Cheers Paul
[Bug libstdc++/89402] [9 Regression] warning: ‘void _ZNKSt4hashIeEclEe()’ specifies less restrictive attribute than its target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89402 --- Comment #6 from Jakub Jelinek --- Author: jakub Date: Fri Feb 22 19:10:47 2019 New Revision: 269130 URL: https://gcc.gnu.org/viewcvs?rev=269130=gcc=rev Log: PR libstdc++/89402 * src/c++98/compatibility-ldbl.cc (_ZNKSt4hashIeEclEe): Change return type to std::size_t and argument to type to long double. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/src/c++98/compatibility-ldbl.cc
[Bug c++/89450] RFC: Strengthen -fstrict-enums
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89450
--- Comment #5 from Jonathan Wakely ---
(In reply to Martin Liška from comment #0)
> Issues is that:
>
> 14746/* If -fstrict-enums, still constrain TYPE_MIN/MAX_VALUE. */
> 14747if (flag_strict_enums)
> 14748 set_min_and_max_values_for_integral_type (enumtype,
> precision, sgn);
>
> is called for precision, which sets min = 0 and max = 7.
Because that's how enums work in C++, as required by the standard.
That's not an issue.
> What about doing:
>
> diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
> index 612afbacd27..46302b4a61d 100644
> --- a/gcc/cp/decl.c
> +++ b/gcc/cp/decl.c
> @@ -14745,7 +14745,10 @@ finish_enum_value_list (tree enumtype)
>
>/* If -fstrict-enums, still constrain TYPE_MIN/MAX_VALUE. */
>if (flag_strict_enums)
> - set_min_and_max_values_for_integral_type (enumtype, precision, sgn);
> + {
> + TYPE_MIN_VALUE (enumtype) = minnode;
> + TYPE_MAX_VALUE (enumtype) = maxnode;
> + }
> }
>else
> underlying_type = ENUM_UNDERLYING_TYPE (enumtype);
>
> I can also imagine another option level when desired.
Please no. -fstrict-enums currently makes the compiler *more* strictly
conforming, by following the rules of the standard. Your suggestion arguably
makes it *less* conforming, by deciding that valid values should emit a
warning.
What you want is not how enums work in C++. Please don't abuse -fstrict-enums
when what you want is "some other kind of enum, not one that strictly follows
the C++ standard".
[Bug target/89456] New: target attribute doesn't work well with -march=native
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89456
Bug ID: 89456
Summary: target attribute doesn't work well with -march=native
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
Target Milestone: ---
Target: i386,x86-64
-march=native is expanded to -march=xxx -myyy -mno-zzz. Whe compiling
int __attribute__ ((target("arch=broadwell"))) foo () {
return 13;
}
arch=broadwell won't set x_ix86_isa_flags since x_ix86_isa_flags_explicit
has been set via command line. As the result, all_ix86_isa_flags checks
in get_builtin_code_for_version will be wrong.
[Bug fortran/32770] [Meta-bug] -fdefault-integer-8 issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32770 Bug 32770 depends on bug 84509, which changed state. Bug 84509 Summary: STOP and ERROR STOP statements with -fdefault-integer-8 and large stop code https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84509 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX
[Bug fortran/84509] STOP and ERROR STOP statements with -fdefault-integer-8 and large stop code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84509 Janne Blomqvist changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #4 from Janne Blomqvist --- Closing this as WONTFIX, since GCC 8 has been released, and adding new ABI entry points just for this corner case isn't worth it. Or if somebody feels differently, please reopen and contribute a patch.
[Bug c++/89450] RFC: Strengthen -fstrict-enums
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89450 --- Comment #4 from Marc Glisse --- Would it make sense to have an attribute so this can be specified for each enum, instead of globally?
[Bug c++/88853] ICE: verify_type failed (error: type variant differs by TYPE_PACKED)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88853 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #2 from Martin Sebor --- Please ignore comment #1 -- wrong bug id in the commit.
[Bug c/89453] Bug parsing "," operator with openmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89453 --- Comment #2 from Jakub Jelinek --- See e.g. OpenMP 5.0 2.9.1 chapter, or OpenMP 4.5 2.6 chapter. for (init-expr; test-expr; incr-expr) structured-block init-expr One of the following: var = lb integer-type var = lb random-access-iterator-type var = lb pointer-type var = lb ... incr-expr One of the following: ++var var++ - - var var - - var += incr var - = incr var = var + incr var = incr + var var = var - incr So both your init-expr and incr-expr are invalid.
[Bug c/89453] Bug parsing "," operator with openmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89453 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |INVALID --- Comment #1 from Jakub Jelinek --- That is not valid OpenMP, so it is perfectly fine it is rejected. In OpenMP, you can't use arbitrary for (...) following the various loop pragmas, they have various restrictions.
[Bug rtl-optimization/89445] [9 regression] _mm512_maskz_loadu_pd "forgets" to use the mask
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89445 --- Comment #5 from Jakub Jelinek --- Created attachment 45800 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45800=edit gcc9-pr89445.patch Full untested fix.
[Bug tree-optimization/85459] [8/9 Regression] Larger code generated from GMP template meta-programming
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85459 --- Comment #9 from Martin Jambor --- Given that this is related to r255510, I tried out the proof-of concept patch from PR 85762 first too and it shrunk text size (compiled with -O3 and Monday trunk) from 901 to 417. So very likely the same issue.
[Bug target/89455] New: [9 Regression] FAIL: g++.target/i386/mv16.C on Westmere
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89455 Bug ID: 89455 Summary: [9 Regression] FAIL: g++.target/i386/mv16.C on Westmere Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com Target Milestone: --- Target: i386,x86-64 Since r263989 has been re-applied, I got FAIL: g++.target/i386/mv16.C -std=gnu++14 execution test FAIL: g++.target/i386/mv16.C -std=gnu++17 execution test FAIL: g++.target/i386/mv16.C -std=gnu++98 execution test on Westmere.
[Bug tree-optimization/87008] [8/9 Regression] gimple mem-to-mem assignment badly optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87008
--- Comment #7 from Martin Jambor ---
(In reply to Marc Glisse from comment #1)
> struct A { double a, b; };
> struct B : A {};
> templatevoid cp(T,T const){a=b;}
> double f(B x){
> B y; cp(y,x);
> B z; cp(z,x);
> return y.a - z.a;
> }
>
> This is not quite equivalent because RTL manages to optimize this case, but
> gimple, with -Ofast, still gets the ugly:
>
> ISRA.1 = MEM[(const struct A &)];
> SR.9_9 = MEM[(struct A *)];
> ISRA.1 = MEM[(const struct A &)];
> SR.8_10 = MEM[(struct A *)];
> _3 = SR.9_9 - SR.8_10;
> return _3;
>
> Writing cp instead of cp makes it work, and the main difference starts
> in SRA. I expect (didn't check) this is another victim of r255510 .
Indeed, with the proof-of-concept patch from PR 85762, this gets optimized
into:
[local count: 1073741824]:
SR.7_2 = MEM[(const struct A &)];
_3 = SR.7_2 - SR.7_2;
return _3;
with -O2 and to retrn 0 with -Ofast.
[Bug other/704] --help and --version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=704 Eric Gallager changed: What|Removed |Added Status|NEW |WAITING --- Comment #17 from Eric Gallager --- (In reply to Eric Gallager from comment #16) > (In reply to Iain Sandoe from comment #15) > > Author: iains > > Date: Wed Aug 22 12:12:46 2018 > > New Revision: 263768 > > > > URL: https://gcc.gnu.org/viewcvs?rev=263768=gcc=rev > > Log: > > Make the gcc-ar,nm, strip tools respond correctly to --help and --version > > when there's no plugin built. > > > > gcc/ > > > > PR other/704 > > * gcc-ar.c (main): Don’t try to invoke the plug-in if we’re not > > building it. > > > > > > Modified: > > trunk/gcc/ChangeLog > > trunk/gcc/gcc-ar.c > > So can this be closed now? WAITING on a reply
[Bug c++/4898] adding an option to verify exception specifications [-Wexceptions]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=4898
Eric Gallager changed:
What|Removed |Added
Blocks||87403
Summary|adding an option to verify |adding an option to verify
|exception specifications|exception specifications
||[-Wexceptions]
--- Comment #8 from Eric Gallager ---
(In reply to Jonathan Wakely from comment #7)
> (In reply to Martin Sebor from comment #2)
> > I agree a new warning would be useful. For example, the following code
> > should
> > be diagnosed:
> >
> > struct S { S () throw () { throw 0; } };
>
> This is still relevant in current standards, where throw() is equivalent to
> noexcept.
>
> Clang warns:
>
> throw.cc:1:28: warning: 'S' has a non-throwing exception specification but
> can still throw [-Wexceptions]
> struct S { S () throw () { throw 0; } };
>^
> throw.cc:1:12: note: function declared non-throwing here
> struct S { S () throw () { throw 0; } };
>^
> 1 warning generated.
>
Having a -Wexceptions like clang's would be a useful new warning; thus, making
this block the new-warning meta-bug
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403
[Bug 87403] [Meta-bug] Issues that suggest a new warning
[Bug tree-optimization/87609] [7/8 Regression] miscompilation with restrict and loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87609 --- Comment #12 from Richard Biener --- Author: rguenth Date: Fri Feb 22 17:56:59 2019 New Revision: 269127 URL: https://gcc.gnu.org/viewcvs?rev=269127=gcc=rev Log: 2019-02-22 Richard Biener PR tree-optimization/87609 * tree-cfg.c (gimple_duplicate_bb): Only remap inlined cliques. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-cfg.c
[Bug c++/81431] add warning for missing initializers in constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81431 --- Comment #4 from Eric Gallager --- (In reply to Jonathan Wakely from comment #3) > I would prefer to see -Weffc++ deprecated and removed, so tying this valid > request to -Weffc++ might see it die. If bug 16166 is fixed, then this request would be tied to whichever suboption the warning is moved to, rather than to -Weffc++ itself. Splitting -Weffc++ up could be a step to deprecating/removing it.
[Bug tree-optimization/85741] [meta-bug] bogus/missing -Wformat-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85741 Bug 85741 depends on bug 88835, which changed state. Bug 88835 Summary: overly aggressive -Werror=format-overflow for printf since r265648 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88835 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/88835] overly aggressive -Werror=format-overflow for printf since r265648
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88835 Martin Sebor changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #16 from Martin Sebor --- The warning has been relaxed for GCC 9 in r269125.
[Bug tree-optimization/88993] [9 Regression] GCC 9 -Wformat-overflow=2 should reflect real libc limits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88993 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #15 from Martin Sebor --- The warning has been relaxed for GCC 9 in r269125.
[Bug tree-optimization/88835] overly aggressive -Werror=format-overflow for printf since r265648
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88835 Bug 88835 depends on bug 88993, which changed state. Bug 88993 Summary: [9 Regression] GCC 9 -Wformat-overflow=2 should reflect real libc limits https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88993 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/85741] [meta-bug] bogus/missing -Wformat-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85741 Bug 85741 depends on bug 88993, which changed state. Bug 88993 Summary: [9 Regression] GCC 9 -Wformat-overflow=2 should reflect real libc limits https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88993 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/88835] overly aggressive -Werror=format-overflow for printf since r265648
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88835 --- Comment #15 from Martin Sebor --- Author: msebor Date: Fri Feb 22 17:38:11 2019 New Revision: 269125 URL: https://gcc.gnu.org/viewcvs?rev=269125=gcc=rev Log: PR tree-optimization/88993 - GCC 9 -Wformat-overflow=2 should reflect real libc limits PR tree-optimization/88835 - overly aggressive -Werror=format-overflow for printf gcc/ChangeLog: PR tree-optimization/88993 PR tree-optimization/88853 * gimple-ssa-sprintf.c (sprintf_dom_walker::call_info::is_file_func): New helper. (sprintf_dom_walker::call_info::is_string_func): New helper. (format_directive): Only issue "may exceed" 4095/INT_MAX warnings for formatted string functions. (sprintf_dom_walker::handle_gimple_call): Fix a typo in a comment. gcc/testsuite/ChangeLog: PR tree-optimization/88993 PR tree-optimization/88853 * gcc.dg/tree-ssa/builtin-fprintf-warn-2.c: New test. * gcc.dg/tree-ssa/builtin-printf-warn-2.c: New test. * gcc.dg/tree-ssa/builtin-snprintf-warn-3.c: Adjust. * gcc.dg/tree-ssa/builtin-sprintf-warn-18.c: Same. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-fprintf-warn-2.c trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-printf-warn-2.c Modified: trunk/gcc/gimple-ssa-sprintf.c trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-snprintf-warn-3.c trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-18.c
[Bug tree-optimization/88993] [9 Regression] GCC 9 -Wformat-overflow=2 should reflect real libc limits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88993 --- Comment #14 from Martin Sebor --- Author: msebor Date: Fri Feb 22 17:38:11 2019 New Revision: 269125 URL: https://gcc.gnu.org/viewcvs?rev=269125=gcc=rev Log: PR tree-optimization/88993 - GCC 9 -Wformat-overflow=2 should reflect real libc limits PR tree-optimization/88835 - overly aggressive -Werror=format-overflow for printf gcc/ChangeLog: PR tree-optimization/88993 PR tree-optimization/88853 * gimple-ssa-sprintf.c (sprintf_dom_walker::call_info::is_file_func): New helper. (sprintf_dom_walker::call_info::is_string_func): New helper. (format_directive): Only issue "may exceed" 4095/INT_MAX warnings for formatted string functions. (sprintf_dom_walker::handle_gimple_call): Fix a typo in a comment. gcc/testsuite/ChangeLog: PR tree-optimization/88993 PR tree-optimization/88853 * gcc.dg/tree-ssa/builtin-fprintf-warn-2.c: New test. * gcc.dg/tree-ssa/builtin-printf-warn-2.c: New test. * gcc.dg/tree-ssa/builtin-snprintf-warn-3.c: Adjust. * gcc.dg/tree-ssa/builtin-sprintf-warn-18.c: Same. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-fprintf-warn-2.c trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-printf-warn-2.c Modified: trunk/gcc/gimple-ssa-sprintf.c trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-snprintf-warn-3.c trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-18.c
[Bug c++/88853] ICE: verify_type failed (error: type variant differs by TYPE_PACKED)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88853 --- Comment #1 from Martin Sebor --- Author: msebor Date: Fri Feb 22 17:38:11 2019 New Revision: 269125 URL: https://gcc.gnu.org/viewcvs?rev=269125=gcc=rev Log: PR tree-optimization/88993 - GCC 9 -Wformat-overflow=2 should reflect real libc limits PR tree-optimization/88835 - overly aggressive -Werror=format-overflow for printf gcc/ChangeLog: PR tree-optimization/88993 PR tree-optimization/88853 * gimple-ssa-sprintf.c (sprintf_dom_walker::call_info::is_file_func): New helper. (sprintf_dom_walker::call_info::is_string_func): New helper. (format_directive): Only issue "may exceed" 4095/INT_MAX warnings for formatted string functions. (sprintf_dom_walker::handle_gimple_call): Fix a typo in a comment. gcc/testsuite/ChangeLog: PR tree-optimization/88993 PR tree-optimization/88853 * gcc.dg/tree-ssa/builtin-fprintf-warn-2.c: New test. * gcc.dg/tree-ssa/builtin-printf-warn-2.c: New test. * gcc.dg/tree-ssa/builtin-snprintf-warn-3.c: Adjust. * gcc.dg/tree-ssa/builtin-sprintf-warn-18.c: Same. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-fprintf-warn-2.c trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-printf-warn-2.c Modified: trunk/gcc/gimple-ssa-sprintf.c trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-snprintf-warn-3.c trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-18.c
[Bug tree-optimization/85762] [8/9 Regression] range-v3 abstraction overhead not optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85762
--- Comment #6 from Martin Jambor ---
The problem is that we now consider MEM_REFs loading a different type
than the one of the underlying DECL as V_C_E and are equally careful
about it.
I this particular case, we have statements like.
MEM[(struct box *)].value = pos
Where D.363334 is of type struct adaptor_cursor. If we follow the
chain of first non-method fields, we get struct adaptor_cursor ->
struct adaptor_value_type_ -> struct adaptor_value_type_2_ -> struct
compressed_pair -> struct tagged -> struct getter -> struct getter ->
struct compressed_tuple_ -> struct box, which is the type of the
MEM_REF itself.
So the MEM_REF is not really a V_C_E but instead represents a bunch of
COMPONENT_REFs. The following patch makes all of the overhead go away
but I guess the type walking results should be cached somehow and it
also only works for MEM_REFs with zero offset, I'm not sure how likely
it is to get MEM_REFs with equal semantics for fields with non-zero
offset.
diff --git a/gcc/tree-sra.c b/gcc/tree-sra.c
index eeef31ba496..e94d01e0ffa 100644
--- a/gcc/tree-sra.c
+++ b/gcc/tree-sra.c
@@ -1169,10 +1169,27 @@ contains_vce_or_bfcref_p (const_tree ref)
|| TREE_CODE (TREE_OPERAND (ref, 0)) != ADDR_EXPR)
return false;
- tree mem = TREE_OPERAND (TREE_OPERAND (ref, 0), 0);
+ tree mem_type = TREE_TYPE (TREE_OPERAND (TREE_OPERAND (ref, 0), 0));
if (TYPE_MAIN_VARIANT (TREE_TYPE (ref))
- != TYPE_MAIN_VARIANT (TREE_TYPE (mem)))
-return true;
+ != TYPE_MAIN_VARIANT (mem_type))
+{
+ while (TREE_CODE (mem_type) == RECORD_TYPE)
+ {
+ tree fld;
+ for (fld = TYPE_FIELDS (mem_type); fld; fld = DECL_CHAIN (fld))
+ if (TREE_CODE (fld) == FIELD_DECL)
+ {
+ if (TYPE_MAIN_VARIANT (TREE_TYPE (ref))
+ == TYPE_MAIN_VARIANT (TREE_TYPE (fld)))
+ return false;
+ mem_type = TREE_TYPE (fld);
+ break;
+ }
+ if (!fld)
+ break;
+ }
+ return true;
+}
return false;
}
[Bug rtl-optimization/89445] [9 regression] _mm512_maskz_loadu_pd "forgets" to use the mask
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89445
--- Comment #4 from Jakub Jelinek ---
vmovupd (%rsi,%rax), %zmm1{%k1}{z}
addq%rdx, %rax
vmovupd (%rax), %zmm2{%k1}{z}
vfmadd132pd %zmm0, %zmm2, %zmm1
vmovupd %zmm1, (%rax){%k1}
isn't optimal btw, it would be nice if we could merge that masking into the
vfmadd132pd instruction, like:
vmovupd (%rsi,%rax), %zmm1{%k1}{z}
addq%rdx, %rax
vfmadd132pd (%rax), %zmm2, %zmm1%{k1}{z}
vmovupd %zmm1, (%rax){%k1}
but not really sure how to achieve that.
[Bug rtl-optimization/89445] [9 regression] _mm512_maskz_loadu_pd "forgets" to use the mask
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89445
--- Comment #3 from Jakub Jelinek ---
Something like:
--- gcc/simplify-rtx.c.jj 2019-01-10 11:43:14.390377646 +0100
+++ gcc/simplify-rtx.c 2019-02-22 17:54:36.633829649 +0100
@@ -6073,8 +6073,10 @@ simplify_ternary_operation (enum rtx_cod
if (!side_effects_p (op2))
{
- rtx top0 = simplify_merge_mask (op0, op2, 0);
- rtx top1 = simplify_merge_mask (op1, op2, 1);
+ rtx top0
+ = may_trap_p (op0) ? NULL_RTX : simplify_merge_mask (op0, op2, 0);
+ rtx top1
+ = may_trap_p (op1) ? NULL_RTX : simplify_merge_mask (op1, op2, 1);
if (top0 || top1)
return simplify_gen_ternary (code, mode, mode,
top0 ? top0 : op0,
fixes this, except that it seems may_trap_p_1 isn't really ready to handle
vectors (or do they never trap, that would surprise me).
E.g.
default:
/* Any floating arithmetic may trap. */
if (SCALAR_FLOAT_MODE_P (GET_MODE (x)) && flag_trapping_math)
return 1;
Shouldn't that really be FLOAT_MODE_P instead of SCALAR_FLOAT_MODE_P?
For DIV etc. the above plus:
if (!CONSTANT_P (XEXP (x, 1)) || (XEXP (x, 1) == const0_rtx))
return 1;
wouldn't we want test for vector integer divisions (does any target have them,
maybe mips?) if all the elements of a CONST_VECTOR are non-zero?
[Bug tree-optimization/86259] [8/9 Regression] min(4, strlen(s)) optimized to strlen(s) with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86259 --- Comment #35 from Bernd Edlinger --- at least gcc 9 has been fixed.
[Bug libstdc++/89446] [7/8 Regression] __builtin_constant_p expression crashes in char_traits::compare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89446 --- Comment #2 from Jonathan Wakely --- (In reply to Jakub Jelinek from comment #1) > Not just > while (__i < __n && __builtin_constant_p(__a[__i])) > ? Yeah that's what I'm testing, not sure where the (i < n && __bcp && i < n) version came from!
[Bug target/89324] [9 Regression] ICE in extract_constrain_insn, at recog.c:2211 on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89324 Matthew Malcomson changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Matthew Malcomson --- Fixed on trunk.
[Bug rtl-optimization/89445] [9 regression] _mm512_maskz_loadu_pd "forgets" to use the mask
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89445
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-02-22
CC||jakub at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #2 from Jakub Jelinek ---
Indeed. Before that change we have:
Trying 36, 47 -> 51:
36: r117:V8DF=vec_merge([r107:DI+r103:DI],const_vector,r90:HI#0)
47: r124:V8DF={r117:V8DF*r94:V8DF+r121:V8DF}
REG_DEAD r121:V8DF
REG_DEAD r117:V8DF
51: [r100:DI]=vec_merge(r124:V8DF,[r100:DI],r90:HI#0)
REG_DEAD r100:DI
REG_DEAD r124:V8DF
Failed to match this instruction:
(set (mem:V8DF (reg/f:DI 100 [ _30 ]) [0 S64 A8])
(vec_merge:V8DF (fma:V8DF (vec_merge:V8DF (mem:V8DF (plus:DI (reg/v/f:DI
107 [ x ])
(reg/v:DI 103 [ i ])) [0 S64 A8])
(const_vector:V8DF [
(const_double:DF 0.0 [0x0.0p+0])
(const_double:DF 0.0 [0x0.0p+0])
(const_double:DF 0.0 [0x0.0p+0])
(const_double:DF 0.0 [0x0.0p+0])
(const_double:DF 0.0 [0x0.0p+0])
(const_double:DF 0.0 [0x0.0p+0])
(const_double:DF 0.0 [0x0.0p+0])
(const_double:DF 0.0 [0x0.0p+0])
])
(subreg:QI (reg/v:HI 90 [ mask ]) 0))
(reg:V8DF 94 [ _18 ])
(reg:V8DF 121))
(mem:V8DF (reg/f:DI 100 [ _30 ]) [0 S64 A8])
(subreg:QI (reg/v:HI 90 [ mask ]) 0)))
With the change:
Trying 36, 47 -> 51:
36: r117:V8DF=vec_merge([r107:DI+r103:DI],const_vector,r90:HI#0)
47: r124:V8DF={r117:V8DF*r94:V8DF+r121:V8DF}
REG_DEAD r121:V8DF
REG_DEAD r117:V8DF
51: [r100:DI]=vec_merge(r124:V8DF,[r100:DI],r90:HI#0)
REG_DEAD r100:DI
REG_DEAD r124:V8DF
Failed to match this instruction:
(set (mem:V8DF (reg/f:DI 100 [ _30 ]) [0 S64 A8])
(vec_merge:V8DF (fma:V8DF (mem:V8DF (plus:DI (reg/v/f:DI 107 [ x ])
(reg/v:DI 103 [ i ])) [0 S64 A8])
(reg:V8DF 94 [ _18 ])
(reg:V8DF 121))
(mem:V8DF (reg/f:DI 100 [ _30 ]) [0 S64 A8])
(subreg:QI (reg/v:HI 90 [ mask ]) 0)))
Successfully matched this instruction:
(set (reg:V8DF 124)
(fma:V8DF (mem:V8DF (plus:DI (reg/v/f:DI 107 [ x ])
(reg/v:DI 103 [ i ])) [0 S64 A8])
(reg:V8DF 94 [ _18 ])
(reg:V8DF 121)))
Successfully matched this instruction:
(set (mem:V8DF (reg/f:DI 100 [ _30 ]) [0 S64 A8])
(vec_merge:V8DF (reg:V8DF 124)
(mem:V8DF (reg/f:DI 100 [ _30 ]) [0 S64 A8])
(subreg:QI (reg/v:HI 90 [ mask ]) 0)))
Something like simplify_merge_mask can be done only if there are MEMs involved
in the operand (or guaranteed not to trap through MEM_NOTRAP_P) and if all the
operations don't have trap states or similar issues (so no floating point ops
nor division by zero, anything else?).
In theory, if the second argument in both inner and outer VEC_MERGE is
CONST_VECTOR and we could prove that feeding that constant into the operation
would result in that same value always, we could optimize away the outer
VEC_MERGE rather than inner, but I guess with floating point ops and signed
zero etc. even that might be hard.
So, shall we just revert that commit until it is fixed, or is there an easy way
to avoid doing it in the problematic cases?
[Bug rtl-optimization/87761] [9 regression][MIPS] New FAIL: gcc.target/mips/fix-r4000-10.c -O1 start with r265398
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87761 --- Comment #13 from Jeffrey A. Law --- Author: law Date: Fri Feb 22 16:38:43 2019 New Revision: 269123 URL: https://gcc.gnu.org/viewcvs?rev=269123=gcc=rev Log: PR rtl-optimization/87761 * config/mips/mips.md: Add new combiner pattern to recognize a bitfield extraction using (ashiftrt (truncate (ashift (.... Modified: trunk/gcc/ChangeLog trunk/gcc/config/mips/mips.md
[Bug target/89324] [9 Regression] ICE in extract_constrain_insn, at recog.c:2211 on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89324 --- Comment #5 from Matthew Malcomson --- Author: matmal01 Date: Fri Feb 22 16:35:22 2019 New Revision: 269122 URL: https://gcc.gnu.org/viewcvs?rev=269122=gcc=rev Log: Handle stack pointer with SUBS/ADDS instructions. In general the stack pointer was not handled for many SUBS/ADDS patterns in aarch64.md. Both the "extended register" and "immediate" forms allow the stack pointer to be used as the source register, while no form allows the stack pointer for the destination register. The define_insn patterns generating ADDS/SUBS did not allow the stack pointer for any operand, while the define_peephole2 patterns that generated RTX to be matched by these patterns allowed the stack pointer for any operand. The patterns are fixed by adding the 'k' constraint for the first source operand to all define_insns that generate the ADDS/SUBS "extended register" and "immediate" forms (but not the "shifted register" form). In peephole optimizations, constraint strings are ignored (see "(gccint) C Constraint Interface" info node in the documentation), so the decision to act or not is based solely on the predicate and condition. This patch introduces a new predicate "aarch64_general_reg" to be used in define_peephole2 patterns where only GENERAL_REGS registers are acceptable and uses that predicate in the peepholes that generate patterns for ADDS/SUBS. Full bootstrap and regtest done on aarch64-none-linux-gnu. Regression tests done on aarch64-none-linux-gnu and aarch64-none-elf cross compiler. OK for trunk? gcc/ChangeLog: 2019-02-22 Matthew Malcomson PR target/89324 * config/aarch64/aarch64.md: Use aarch64_general_reg predicate on destination register in peepholes generating patterns for ADDS/SUBS. (add3_compare0, *addsi3_compare0_uxtw, add3_compareC, add3_compareV_imm, add3_compareV, *adds__, *subs__, *adds__shift_, *subs__shift_, *adds__multp2, *subs__multp2, *sub3_compare0, *subsi3_compare0_uxtw, sub3_compare1): Allow stack pointer for source register. * config/aarch64/predicates.md (aarch64_general_reg): New predicate. gcc/testsuite/ChangeLog: 2019-02-22 Matthew Malcomson PR target/89324 * gcc.dg/rtl/aarch64/subs_adds_sp.c: New test. * gfortran.fortran-torture/compile/pr89324.f90: New test. Added: trunk/gcc/testsuite/gcc.dg/rtl/aarch64/subs_adds_sp.c trunk/gcc/testsuite/gfortran.fortran-torture/compile/pr89324.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/config/aarch64/aarch64.md trunk/gcc/config/aarch64/predicates.md trunk/gcc/testsuite/ChangeLog
[Bug target/89229] Incorrect xmm16-xmm31/ymm16-ymm31 in vector move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89229
H.J. Lu changed:
What|Removed |Added
Attachment #45707|0 |1
is obsolete||
--- Comment #24 from H.J. Lu ---
Comment on attachment 45707
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45707
A new patch
>From fd7220a7551ee774614ca89574241813aae153b7 Mon Sep 17 00:00:00 2001
>From: "H.J. Lu"
>Date: Tue, 12 Feb 2019 13:25:41 -0800
>Subject: [PATCH] i386: Properly encode xmm16-xmm31/ymm16-ymm31 for vector move
>
>i386 backend has
>
>INT_MODE (OI, 32);
>INT_MODE (XI, 64);
>
>So, XI_MODE represents 64 INTEGER bytes = 64 * 8 = 512 bit operation,
>in case of const_1, all 512 bits set.
>
>We can load zeros with narrower instruction, (e.g. 256 bit by inherent
>zeroing of highpart in case of 128 bit xor), so TImode in this case.
>
>Some targets prefer V4SF mode, so they will emit float xorps for zeroing.
>
>sse.md has
>
>(define_insn "mov_internal"
> [(set (match_operand:VMOVE 0 "nonimmediate_operand"
> "=v,v ,v ,m")
>(match_operand:VMOVE 1 "nonimmediate_or_sse_const_operand"
> " C,BC,vm,v"))]
>
> /* There is no evex-encoded vmov* for sizes smaller than 64-bytes
> in avx512f, so we need to use workarounds, to access sse registers
> 16-31, which are evex-only. In avx512vl we don't need workarounds. */
> if (TARGET_AVX512F && < 64 && !TARGET_AVX512VL
> && (EXT_REX_SSE_REG_P (operands[0])
> || EXT_REX_SSE_REG_P (operands[1])))
>{
> if (memory_operand (operands[0], mode))
>{
> if ( == 32)
>return "vextract64x4\t{$0x0, %g1, %0|%0, %g1,
> 0x0}";
> else if ( == 16)
>return "vextract32x4\t{$0x0, %g1, %0|%0, %g1,
> 0x0}";
> else
>gcc_unreachable ();
>}
>...
>
>However, since ix86_hard_regno_mode_ok has
>
> /* TODO check for QI/HI scalars. */
> /* AVX512VL allows sse regs16+ for 128/256 bit modes. */
> if (TARGET_AVX512VL
> && (mode == OImode
> || mode == TImode
> || VALID_AVX256_REG_MODE (mode)
> || VALID_AVX512VL_128_REG_MODE (mode)))
>return true;
>
> /* xmm16-xmm31 are only available for AVX-512. */
> if (EXT_REX_SSE_REGNO_P (regno))
>return false;
>
> if (TARGET_AVX512F && < 64 && !TARGET_AVX512VL
> && (EXT_REX_SSE_REG_P (operands[0])
> || EXT_REX_SSE_REG_P (operands[1])))
>
>is a dead code.
>
>All TYPE_SSEMOV vector moves are consolidated to ix86_output_ssemov:
>
>1. If xmm16-xmm31/ymm16-ymm31 registers aren't used, SSE/AVX vector
>moves will be generated.
>2. If xmm16-xmm31/ymm16-ymm31 registers are used:
> a. With AVX512VL, AVX512VL vector moves will be generated.
> b. Without AVX512VL, xmm16-xmm31/ymm16-ymm31 register to register
> move will be done with zmm register move.
>
>ext_sse_reg_operand is removed since it is no longer needed.
>
>gcc/
>
> PR target/89229
> * config/i386/i386-protos.h (ix86_output_ssemov): New prototype.
> * config/i386/i386.c (ix86_get_ssemov): New function.
> (ix86_output_ssemov): Likewise.
> * config/i386/i386.md (*movxi_internal_avx512f): Call
> ix86_output_ssemov for TYPE_SSEMOV.
> (*movoi_internal_avx): Call ix86_output_ssemov for TYPE_SSEMOV.
> Remove ext_sse_reg_operand and TARGET_AVX512VL check.
> (*movti_internal): Likewise.
> (*movdi_internal): Call ix86_output_ssemov for TYPE_SSEMOV.
> Remove ext_sse_reg_operand check.
> (*movsi_internal): Likewise.
> (*movtf_internal): Call ix86_output_ssemov for TYPE_SSEMOV.
> (*movdf_internal): Call ix86_output_ssemov for TYPE_SSEMOV.
> Remove TARGET_AVX512F, TARGET_PREFER_AVX256, TARGET_AVX512VL
> and ext_sse_reg_operand check.
> (*movsf_internal_avx): Call ix86_output_ssemov for TYPE_SSEMOV.
> Remove TARGET_PREFER_AVX256, TARGET_AVX512VL and
> ext_sse_reg_operand check.
> * config/i386/mmx.md (MMXMODE:*mov_internal): Call
> ix86_output_ssemov for TYPE_SSEMOV. Remove ext_sse_reg_operand
> check.
> * config/i386/sse.md (VMOVE:mov_internal): Call
> ix86_output_ssemov for TYPE_SSEMOV. Remove TARGET_AVX512VL
> check.
> * config/i386/predicates.md (ext_sse_reg_operand): Removed.
>
>gcc/testsuite/
>
> PR target/89229
> * gcc.target/i386/pr89229-2a.c: New test.
> * gcc.target/i386/pr89229-2b.c: Likewise.
> * gcc.target/i386/pr89229-2c.c: Likewise.
> * gcc.target/i386/pr89229-3a.c: Likewise.
> * gcc.target/i386/pr89229-3b.c: Likewise.
> * gcc.target/i386/pr89229-3c.c: Likewise.
> * gcc.target/i386/pr89229-4a.c: Likewise.
> * gcc.target/i386/pr89229-4b.c: Likewise.
> *
[Bug c/89425] [9 Regression] -Wabsolute-value warns in dead subexpressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89425 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |9.0 --- Comment #5 from Martin Sebor --- Fixed via r269121.
[Bug target/89229] Incorrect xmm16-xmm31/ymm16-ymm31 in vector move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89229 --- Comment #23 from H.J. Lu --- A patch is posted at https://gcc.gnu.org/ml/gcc-patches/2019-02/msg01841.html
[Bug c/89425] [9 Regression] -Wabsolute-value warns in dead subexpressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89425 --- Comment #4 from Martin Sebor --- Author: msebor Date: Fri Feb 22 16:24:36 2019 New Revision: 269121 URL: https://gcc.gnu.org/viewcvs?rev=269121=gcc=rev Log: PR c/89425 - -Wabsolute-value warns in dead subexpressions gcc/c/ChangeLog: PR c/89425 * c-parser.c (sizeof_ptr_memacc_comptypes): Avoid warning in unreachable subexpressions. gcc/testsuite/ChangeLog: PR c/89425 * gcc.dg/Wabsolute-value.c: New test. Added: trunk/gcc/testsuite/gcc.dg/Wabsolute-value.c Modified: trunk/gcc/ChangeLog trunk/gcc/c/c-parser.c trunk/gcc/testsuite/ChangeLog
[Bug debug/89454] New: gcc generates wrong debug information at -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89454
Bug ID: 89454
Summary: gcc generates wrong debug information at -Og
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: qrzhang at gatech dot edu
Target Milestone: ---
It bug affects the latest trunk.
It also affects gcc-8 to gcc-4.8.
With "-Og", it incorrectly prints "l=0".
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/home/absozero/trunk/root-gcc/libexec/gcc/x86_64-pc-linux-gnu/9.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/home/absozero/trunk/root-gcc
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 9.0.1 20190222 (experimental) [trunk revision 269113] (GCC)
$ cat abc.c
int a;
int main() {
char l = 0;
if (a)
;
else
l = 10 || 0;
optimize_me_not();
}
$ cat cmds
b 8
r
p l
kill
q
$ cat outer.c
optimize_me_not() {}
$ gcc-trunk -g abc.c outer.c
$ gdb -x cmds -batch a.out
Breakpoint 1 at 0x40049c: file abc.c, line 8.
Breakpoint 1, main () at abc.c:8
8 optimize_me_not();
$1 = 1 '\001'
Kill the program being debugged? (y or n) [answered Y; input not from terminal]
$ gcc-trunk -g abc.c outer.c -Og
$ gdb -x cmds -batch a.out
Breakpoint 1 at 0x400486: file abc.c, line 8.
Breakpoint 1, main () at abc.c:8
8 optimize_me_not();
$1 = 0 '\000'
Kill the program being debugged? (y or n) [answered Y; input not from terminal]
[Bug target/89229] Incorrect xmm16-xmm31/ymm16-ymm31 in vector move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89229 H.J. Lu changed: What|Removed |Added CC||kretz at kde dot org --- Comment #22 from H.J. Lu --- *** Bug 86896 has been marked as a duplicate of this bug. ***
