[Bug libstdc++/89991] Complex numbers: Calculation of imaginary part is not correct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89991 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org Priority|P3 |P2 Severity|normal |major --- Comment #26 from kargl at gcc dot gnu.org --- Any chance a libstdc++ person will commit the supplied patches?
[Bug target/85972] cr16/predicates.md:163: bad if test ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85972 --- Comment #1 from David Binderman --- Still broken over a year later.
[Bug c/94086] New: Missed optimization when converting a bitfield to an integer on x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94086
Bug ID: 94086
Summary: Missed optimization when converting a bitfield to an
integer on x86-64
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: larrowe.semaj11 at gmail dot com
Target Milestone: ---
When converting a structure containing bitfields to an unsigned 16-bit integer,
inefficient code is generated.
Minimal testcase:
typedef struct half
{
unsigned short mantissa:10;
unsigned short exponent:5;
unsigned short sign:1;
} half;
unsigned short from_half(half h)
{
return h.mantissa | h.exponent << 10 | h.sign << 15;
}
To compile and place output on `stdout`:
gcc -O3 -S test.c -o -
Assembly output:
movl%edi, %edx
movl%edi, %eax
andw$1023, %di
shrw$15, %dx
andl$31744, %eax
movzbl %dl, %edx
sall$15, %edx
orl %edx, %eax
orl %edi, %eax
ret
This could be optimized into:
movl%edi, %eax
retq
This behavior does not occur when `unsigned short` is being converted into
`half` in a similar manner.
`gcc -v`:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/9.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-9.2.0-r3/work/gcc-9.2.0/configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/9.2.0
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/9.2.0
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/9.2.0/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/9.2.0/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/include/g++-v9
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/9.2.0/python
--enable-objc-gc --enable-languages=c,c++,d,go,objc,obj-c++,fortran
--enable-obsolete --enable-secureplt --disable-werror --with-system-zlib
--enable-nls --without-included-gettext --enable-checking=release
--with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 9.2.0-r3 p4'
--disable-esp --enable-libstdcxx-time --with-build-config=bootstrap-lto
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64
--disable-altivec --disable-fixed-point --enable-targets=all --enable-libgomp
--disable-libmudflap --disable-libssp --disable-systemtap
--enable-vtable-verify --enable-lto --with-isl --disable-isl-version-check
--enable-default-pie --enable-default-ssp
Thread model: posix
gcc version 9.2.0 (Gentoo 9.2.0-r3 p4)
`-Wall -Wextra` reports nothing.
[Bug c++/94082] __builtin_memcpy in constexpr context should compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94082 Frank Ch. Eigler changed: What|Removed |Added CC||fche at redhat dot com test
[Bug libstdc++/94080] -mabi=ieeelongdouble and -mfloat128 cause libstc++ header breakage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94080 There is a HUGE amount of work to do to make libstdc++ support it properly. I think I've already done most of it, but last time I tried to test it everything failed because glibc didn't have the necessary ieee long double support yet. I should check if it's landed in glibc yet and resurrect that git branch.
[Bug libstdc++/94080] -mabi=ieeelongdouble and -mfloat128 cause libstc++ header breakage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94080 --- Comment #1 from Jonathan Wakely --- Due to a server move, bugzilla seems to have lost the original comments on this bug. They are archived at https://gcc.gnu.org/ml/gcc-bugs/2020-03/msg01310.html and https://gcc.gnu.org/ml/gcc-bugs/2020-03/msg01320.html
[Bug libstdc++/94033] is_trivially_copy_constructible<> fails with compiler error on complicated object with private default constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94033 --- Comment #5 from Rafael Avila de Espindola --- The regression (at least with the reduced testcase I uploaded) is from: commit 58487c21b6a47c3fff6c6958684de866216a5593 (HEAD) Author: Jonathan Wakely Date: Mon May 20 12:32:51 2019 +0100 PR c++/90532 Ensure __is_constructible(T[]) is false
[Bug c++/85079] Segfault While Compiling DXX-Rebirth Project
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85079 Andrew Pinski changed: What|Removed |Added Ever confirmed|1 |0 Status|WAITING |UNCONFIRMED
[Bug target/78636] PPC Optimization Bug in Libelemental unit test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78636 Andrew Pinski changed: What|Removed |Added Ever confirmed|1 |0 Status|WAITING |UNCONFIRMED Component|c++ |target
[Bug libstdc++/94087] New: std::random_device often fails when used from multiple threads
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94087 Bug ID: 94087 Summary: std::random_device often fails when used from multiple threads Product: gcc Version: 9.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: coryan+gccbugzilla at google dot com Target Milestone: --- Created attachment 47995 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47995&action=edit A program to reproduce the problem. Creating and using a `std::random_device` object fails when used from multiple threads. A `std::exception` exception is throw with the message "random_device: rdseed failed", probably from this point in the code: https://github.com/gcc-mirror/gcc/blob/2a4c59d9aa6b1018fa8f86dd8c0573c1fed3f199/libstdc%2B%2B-v3/src/c%2B%2B11/random.cc#L108 The problem is easy to reproduce, compile the attached program and run it, it fails every time. I guess any version where __GLIBCXX__ >= 20200128 would have this problem. I just compiled with: g++ -std=c++17 -pthread -o /tmp/repro-rdseed repro-rdseed.cc and then run the program using: /tmp/repro-rdseed The program exits with 0 on success, 1 on failure, and prints some explanatory messages (and some version numbers). The bug *is* present on openSUSE/Tumbleweed, where the compiler reports: g++ (SUSE Linux) 9.2.1 20200128 [revision 83f65674e78d97d27537361de1a9d74067ff228d] Copyright (C) 2019 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. The bug is *not* present on on Fedora:31 where the compiler reports: g++ (GCC) 9.2.1 20190827 (Red Hat 9.2.1-1) Copyright (C) 2019 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. PS: Apologies if I get my version numbers wrong, I am used to using binary distributions, have not compiled GCC from source in 2 decades or so.
[Bug tree-optimization/94086] Missed optimization when converting a bitfield to an integer on x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94086 Andrew Pinski changed: What|Removed |Added CC||pinskia at gcc dot gnu.org Severity|normal |enhancement Component|c |tree-optimization
[Bug target/81426] [SH]: unable to find a register to spill in class 'R0_REGS' when building webkit2gtk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81426 Oleg Endo changed: What|Removed |Added CC||olegendo at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2020-03-08 Status|UNCONFIRMED |NEW
