[Bug go/91617] [10 regression] Many go test case failures after r275026
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91617 --- Comment #2 from Jakub Jelinek --- Or something is wrong in the go FE langhooks. Anyway, I have no idea how to debug this, the libgo libgo.log doesn't contain anything that would make it clear how to run the tests and even looking at the simpler gcc/testsuite/go/go.log, there is command how to compile/link the test, but not how to run it. LD_LIBRARY_PATH=/home/jakub/src/gcc/obj52/x86_64-pc-linux-gnu/./libgo/.libs ./select5.exe ./select5.exe: symbol lookup error: ./select5.exe: undefined symbol: runtime.osinit LD_LIBRARY_PATH=/home/jakub/src/gcc/obj54/x86_64-pc-linux-gnu/./libgo/.libs ./select5.exe panic: "recv": template: recv:1: unexpected goroutine 1 [running]: main.parse /home/jakub/src/gcc/gcc/testsuite/go.test/test/chan/select5.go:142
[Bug fortran/91552] ICE with valid array constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91552 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 CC||kargl at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |kargl at gcc dot gnu.org --- Comment #2 from kargl at gcc dot gnu.org --- I have a patch that is currently regression testing.
[Bug fortran/91587] ICE in gfc_resolve_filepos, at fortran/io.c:2913
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91587 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from kargl at gcc dot gnu.org --- Fixed on trunk and 9-branch
[Bug fortran/91587] ICE in gfc_resolve_filepos, at fortran/io.c:2913
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91587 --- Comment #3 from kargl at gcc dot gnu.org --- Author: kargl Date: Sat Aug 31 03:27:45 2019 New Revision: 275241 URL: https://gcc.gnu.org/viewcvs?rev=275241&root=gcc&view=rev Log: 2019-08-30 Steven G. Kargl PR fortran/91587 * io.c (match_filepos): MATCH_ERROR should branch to a syntax error. 2019-08-30 Steven G. Kargl PR fortran/91587 * gfortran.dg/pr91587.f90: New test. Added: branches/gcc-9-branch/gcc/testsuite/gfortran.dg/pr91587.f90 Modified: branches/gcc-9-branch/gcc/fortran/ChangeLog branches/gcc-9-branch/gcc/fortran/io.c branches/gcc-9-branch/gcc/testsuite/ChangeLog
[Bug fortran/91587] ICE in gfc_resolve_filepos, at fortran/io.c:2913
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91587 --- Comment #2 from kargl at gcc dot gnu.org --- Author: kargl Date: Sat Aug 31 00:32:48 2019 New Revision: 275236 URL: https://gcc.gnu.org/viewcvs?rev=275236&root=gcc&view=rev Log: 2019-08-30 Steven G. Kargl PR fortran/91587 * io.c (match_filepos): MATCH_ERROR should branch to a syntax error. 2019-08-30 Steven G. Kargl PR fortran/91587 * gfortran.dg/pr91587.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr91587.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/io.c trunk/gcc/testsuite/ChangeLog
[Bug c++/91622] New: Compiler internal error DJGPP GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91622 Bug ID: 91622 Summary: Compiler internal error DJGPP GCC Product: gcc Version: 9.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: William.Cook at vishay dot com Target Milestone: --- Compiler error after migrated to GCC 9.2.0 See attachment. Try .cxx, .cpp, c files.Compiled clean before update.
[Bug go/91617] [10 regression] Many go test case failures after r275026
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91617 --- Comment #1 from Ian Lance Taylor --- The cited revision was not to libgo, so my assumption is that there was something wrong with it and there is nothing to change in the Go frontend. Let me know if I'm mistaken. This was also filed as https://golang.org/issue/33958.
[Bug fortran/91565] [8/9/10 Regression] ICE in gfc_simplify_reshape, at fortran/simplify.c:6707 etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91565 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|8.4 |9.3 --- Comment #5 from kargl at gcc dot gnu.org --- Fixed on trunk and 9-branch.
[Bug fortran/91565] [8/9/10 Regression] ICE in gfc_simplify_reshape, at fortran/simplify.c:6707 etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91565 --- Comment #4 from kargl at gcc dot gnu.org --- Author: kargl Date: Fri Aug 30 23:30:35 2019 New Revision: 275230 URL: https://gcc.gnu.org/viewcvs?rev=275230&root=gcc&view=rev Log: 2019-08-30 Steven G. Kargl PR fortran/91565 * simplify.c (gfc_simplify_reshape): Add additional checks of the ORDER dummy argument. 2019-08-30 Steven G. Kargl PR fortran/91565 * gfortran.dg/pr91565.f90: New test. Added: branches/gcc-9-branch/gcc/testsuite/gfortran.dg/pr91565.f90 Modified: branches/gcc-9-branch/gcc/fortran/ChangeLog branches/gcc-9-branch/gcc/fortran/simplify.c branches/gcc-9-branch/gcc/testsuite/ChangeLog
[Bug fortran/91564] [8/9/10 Regression] ICE in gimplify_expr, at gimplify.c:14147
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91564 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|8.4 |9.3 --- Comment #4 from kargl at gcc dot gnu.org --- Fixed on trunk and 9-branch.
[Bug fortran/91564] [8/9/10 Regression] ICE in gimplify_expr, at gimplify.c:14147
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91564 --- Comment #3 from kargl at gcc dot gnu.org --- Author: kargl Date: Fri Aug 30 23:19:30 2019 New Revision: 275229 URL: https://gcc.gnu.org/viewcvs?rev=275229&root=gcc&view=rev Log: 2019-08-30 Steven G. Kargl PR fortran/91564 * check.c (gfc_check_kill_sub): Additional checks on status dummy argument. 2019-08-30 Steven G. Kargl PR fortran/91564 * gfortran.dg/pr91564.f90: New test. Added: branches/gcc-9-branch/gcc/testsuite/gfortran.dg/pr91564.f90 Modified: branches/gcc-9-branch/gcc/fortran/ChangeLog branches/gcc-9-branch/gcc/fortran/check.c branches/gcc-9-branch/gcc/testsuite/ChangeLog
[Bug fortran/91551] [9/10 Regression] ICE in sort_actual, at fortran/intrinsic.c:4193
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91551 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from kargl at gcc dot gnu.org --- Fixed on trunk and 9-branch.
[Bug fortran/91551] [9/10 Regression] ICE in sort_actual, at fortran/intrinsic.c:4193
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91551 --- Comment #3 from kargl at gcc dot gnu.org --- Author: kargl Date: Fri Aug 30 23:02:37 2019 New Revision: 275228 URL: https://gcc.gnu.org/viewcvs?rev=275228&root=gcc&view=rev Log: 2019-08-30 Steven G. Kargl PR fortran/91551 * intrinsic.c (sort_actual): ALLOCATED has one argument. Check for no argument case. 2019-08-30 Steven G. Kargl PR fortran/91551 * gfortran.dg/allocated_3.f90 Added: branches/gcc-9-branch/gcc/testsuite/gfortran.dg/allocated_3.f90 Modified: branches/gcc-9-branch/gcc/fortran/ChangeLog branches/gcc-9-branch/gcc/fortran/intrinsic.c branches/gcc-9-branch/gcc/testsuite/ChangeLog
[Bug c++/91618] template-id required to friend a function template, even for a qualified-id
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91618 --- Comment #2 from Marek Polacek --- Started with r249385.
[Bug c++/91618] template-id required to friend a function template, even for a qualified-id
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91618 Marek Polacek changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2019-08-30 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed.
[Bug go/91621] New: libgo/mksysinfo.sh: please avoid test ==
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91621
Bug ID: 91621
Summary: libgo/mksysinfo.sh: please avoid test ==
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: go
Assignee: ian at airs dot com
Reporter: harald at gigawatt dot nl
CC: cmang at google dot com
Target Milestone: ---
r269424 introduced in libgo/mksysinfo.sh:
if test "$statfs" == ""; then
test == is non-POSIX and not supported in all shells. In my GCC 9.2.0 build
log, I see
/h/gcc-9.2.0/libgo/mksysinfo.sh: 1130: test: type _statfs64 struct { f_type
int64; f_bsize int64; f_blocks uint64; f_bfree uint64; f_bavail uint64; f_files
uint64; f_ffree uint64; f_fsid ___fsid_t; f_namelen int64; f_frsize int64;
f_flags int64; f_spare [3+1]int64; }: unexpected operator
Can this please be changed to use = rather than == ?
[Bug fortran/91556] Problems with better interface checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91556 --- Comment #21 from Steve Kargl --- On Thu, Aug 29, 2019 at 09:38:09PM +, tkoenig at gcc dot gnu.org wrote: > --- Comment #18 from Thomas Koenig --- > (In reply to anlauf from comment #14) > > The current solution is a bit annoying for implicitly-derived interfaces. > > > > Consider a code like: > > > > module foo > > implicit none > > type t1 > > integer :: i = 1 > > end type t1 > > type t2 > > integer :: j = 2 > > end type t2 > > contains > > subroutine s1 (x) > > type(t1) :: x > > call my_mpi_bcast_wrapper (x, storage_size (x)/8) > > end subroutine s1 > > subroutine s2 (y) > > type(t2) :: y > > call my_mpi_bcast_wrapper (y, storage_size (y)/8) > > end subroutine s2 > > end module foo > > > > That's perfectly legal, > > This is illegal, as far as I know. The type names are different, > which makes them different types. > Thomas, I'll leave this to whatever you decide. gfortran could do -fallow-argument-mismatch=n. n=0 is an error, n=1 is for a warning, and n>1 silences the warning. n=0 would be the default setting as I think the error messages will encourage people to fix their codes. PS: the MPI argument is somewhat bogus. At least, OpenMPI has an Fortran 2008 interface for mpi_bcast() (ie., 11 years ago). USE mpi_f08 MPI_Bcast(buffer, count, datatype, root, comm, ierror) TYPE(*), DIMENSION(..) :: buffer INTEGER, INTENT(IN) :: count, root TYPE(MPI_Datatype), INTENT(IN) :: datatype TYPE(MPI_Comm), INTENT(IN) :: comm INTEGER, OPTIONAL, INTENT(OUT) :: ierror
[Bug target/91602] GCC fails to build for riscv in a combined tree due to misconfigured leb128 support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91602 --- Comment #6 from Jim Wilson --- By the way, the underlying problem here is, as Andrew Waterman mentioned, that the RISC-V linker does aggressive link time relaxations to reduce code size, and this makes lib128 with label subtraction unsafe. The RISC-V port is not the only port that has this problem. The RISC-V port is just the only one that gets it right. The others can silently produce incorrect debug info. I have evidence that every binutils target except RISC-V that does aggressive link time relaxation to reduce code size is doing it wrong. There is a bug in binutils bugzilla where I listed linker relaxation code size related issues, but I have since found and fixed other problems in the RISC-V port, so it is incomplete. https://sourceware.org/bugzilla/show_bug.cgi?id=22756#c2
[Bug target/91602] GCC fails to build for riscv in a combined tree due to misconfigured leb128 support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91602 --- Comment #5 from Jim Wilson --- The wiki is wrong. Combined tree builds should not be used anymore. Combined tree builds date back to when Cygnus was maintainer for everything. We put everything in a single source tree, and wrote configure and makefile support so that you could check them out with a single command, and configure and build them with a single command. But Cygnus is no longer controlling everything, and different packages are now in different source trees, and are meant to be compiled separately. When you build packages separately, each package after the first uses feature tests to configure itself appropriately to use the earlier packages. When you use a combined tree build, feature tests can't be used because earlier packages haven't been installed yet, so configure just makes guesses. We have the most commonly correct results hardwired in as guesses. This was fine when packages were smaller, and we had a smaller number of targets. Nowadays, there is too much risk that the guesses will be wrong. A combined tree build may not give you the exact same result as building separately because of this. Of course, if you just need a throw away toolchain to check how something works for a different architecture than your own, this is fine. But if you want to make a product release that will be used by customers, this can be dangerous. None of the major build scripts use combined tree builds. None of the linux distros (Fedora, Debian, OpenSuse) do this. None of the embedded linux build systems to this (OpenEmbedded/Yocto, Buildroot). crosstool-ng doesn't do builds this way. And github.com/riscv/riscv-gnu-toolchain doesn't do builds this way. There are so many easy ways to build toolchains that we don't need combined tree builds to work. This is of course my personal opinion, and I expect that people will disagree with me. But I rarely if ever see anyone update the combined tree support, so I will continue to tell people that it is dangerous to rely on it.
[Bug c++/91607] [9 regression] internal compiler error: in equal, at cp/constexpr.c:1088
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91607 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #4 from Marek Polacek --- The ICE was fixed by r266816.
[Bug middle-end/91606] [9/10 regression] Optimization leads to invalid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91606 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-08-30 CC||mpolacek at gcc dot gnu.org Component|c++ |middle-end Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Started with commit f38039b2e78510bed9e7574dbc609bed735b4a8a Author: rguenth Date: Tue Nov 20 09:31:06 2018 + 2018-11-20 Richard Biener PR middle-end/83215 * alias.c (component_uses_parent_alias_set_from): Remove alias-set zero and TYPE_TYPELESS_STORAGE case both already handled in other ways. * g++.dg/tree-ssa/pr83215.C: New testcase. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@266305 138bc75d-0d04-0410-961f-82ee72b054a4
[Bug target/90698] Darwin X86 backend lacks support for mcmodel={medium, large, kernel}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90698
--- Comment #8 from Iain Sandoe ---
Author: iains
Date: Fri Aug 30 20:02:13 2019
New Revision: 275224
URL: https://gcc.gnu.org/viewcvs?rev=275224&root=gcc&view=rev
Log:
[Darwin, X86, testsuite] Add xfails for PR90698.
We don't have support for -mcmodel={medium, large, kernel} so don't
expect tests for those things to work.
For now mark them as xfail where possible and skip where that isn't.
These changes will be logged onto the PR and therefore can be backed
out when the facility is implemented.
2019-08-30 Iain Sandoe
Backport from mainline.
2019-06-01 Iain Sandoe
PR target/90698
* gcc.target/i386/pr49866.c: XFAIL for Darwin.
* gcc.target/i386/pr63538.c: Likewise.
* gcc.target/i386/pr61599-1.c: Skip for Darwin.
Modified:
branches/gcc-8-branch/gcc/testsuite/ChangeLog
branches/gcc-8-branch/gcc/testsuite/gcc.target/i386/pr49866.c
branches/gcc-8-branch/gcc/testsuite/gcc.target/i386/pr61599-1.c
branches/gcc-8-branch/gcc/testsuite/gcc.target/i386/pr63538.c
[Bug fortran/91556] Problems with better interface checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91556 --- Comment #20 from Steve Kargl --- On Fri, Aug 30, 2019 at 07:43:54PM +, anlauf at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91556 > > --- Comment #19 from anlauf at gcc dot gnu.org --- > (In reply to Thomas Koenig from comment #18) > > (In reply to anlauf from comment #14) > > > The current solution is a bit annoying for implicitly-derived interfaces. > > > > > > Consider a code like: > > > > > > module foo > > > implicit none > > > type t1 > > > integer :: i = 1 > > > end type t1 > > > type t2 > > > integer :: j = 2 > > > end type t2 > > > contains > > > subroutine s1 (x) > > > type(t1) :: x > > > call my_mpi_bcast_wrapper (x, storage_size (x)/8) > > > end subroutine s1 > > > subroutine s2 (y) > > > type(t2) :: y > > > call my_mpi_bcast_wrapper (y, storage_size (y)/8) > > > end subroutine s2 > > > end module foo > > > > > > That's perfectly legal, > > > > This is illegal, as far as I know. The type names are different, > > which makes them different types. > > Of course the types are different - that's the point! > > The above is an attempt to extract a self-contained example demonstrating > what does happen in real-world codes using MPI. You can convert it to the > real thing yourself (see e.g. man mpi_bcast). > From the Fortran standard (actually 18-007r1.pdf), page 304. 15.5.2.4 Ordinary dummy variables 2 The dummy argument shall be type compatible with the actual argument. How can the dummy argument be type compatiable with two distinct different types for the actual arguments x and y in your example?
[Bug target/91602] GCC fails to build for riscv in a combined tree due to misconfigured leb128 support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91602 --- Comment #4 from Andrew Pinski --- >Combined tree builds are obsolete and shouldn't be used anymore.) Huh? Where is that documented. In fact the wiki still recommends a combined build. Combined builds make building easier.
[Bug fortran/91556] Problems with better interface checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91556 --- Comment #19 from anlauf at gcc dot gnu.org --- (In reply to Thomas Koenig from comment #18) > (In reply to anlauf from comment #14) > > The current solution is a bit annoying for implicitly-derived interfaces. > > > > Consider a code like: > > > > module foo > > implicit none > > type t1 > > integer :: i = 1 > > end type t1 > > type t2 > > integer :: j = 2 > > end type t2 > > contains > > subroutine s1 (x) > > type(t1) :: x > > call my_mpi_bcast_wrapper (x, storage_size (x)/8) > > end subroutine s1 > > subroutine s2 (y) > > type(t2) :: y > > call my_mpi_bcast_wrapper (y, storage_size (y)/8) > > end subroutine s2 > > end module foo > > > > That's perfectly legal, > > This is illegal, as far as I know. The type names are different, > which makes them different types. Of course the types are different - that's the point! The above is an attempt to extract a self-contained example demonstrating what does happen in real-world codes using MPI. You can convert it to the real thing yourself (see e.g. man mpi_bcast). What I wanted to say: in many codes using MPI, the 'buffer' argument of MPI_* can be of any type or kind, provided the other arguments are appropriately set. There is no explicit interface - the library routines may not even be written in Fortran - and there cannot be any reasonable inference from an implicit interface. Using this to generate an error *by default* is not a good idea. The same problem shows up for me in parts of the code using direct calls to BLAS (again, no explicit interfaces), or to NetCDF. I guess this is similar to the issues people reported for the SPEC codes. The recommendation to use -fallow-argument-mismatch to downgrade this to a warning (not silence it!) does not really solve the issue: the signal-to-noise ratio of gfortran warnings has become close to useless. (Just ask colleagues whether they pay attention to warnings.) And do you really want users to add -w to the list of options? If you think about it, you might conclude that this will do gfortran a poor service. I'll stop ranting now.
[Bug libstdc++/91620] [forward_]list::remove_if should respect to DR 526
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91620 --- Comment #1 from frankhb1989 at gmail dot com --- (The issue number in the case seems a typo. It is introduced in https://reviews.llvm.org/rL358534.)
[Bug c++/91620] New: [forward_]list::remove_if should respect to DR 529
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91620
Bug ID: 91620
Summary: [forward_]list::remove_if should respect to DR 529
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: frankhb1989 at gmail dot com
Target Milestone: ---
A case for std::list taken from libc++'s testsuite:
#include
#include
#include
#include
using namespace std;
struct PredLWG529
{
PredLWG529(int i) : i_(i) {};
~PredLWG529() { i_ = -32767; }
bool operator() (const PredLWG529& p) const { return p.i_ == i_; }
bool operator==(int i) const { return i == i_; }
int i_;
};
int main()
{
int a1[] = {1, 2, 1, 3, 5, 8, 11};
int a2[] = {2, 3, 5, 8, 11};
std::list c(a1, a1 + 7);
c.remove_if(std::ref(c.front()));
assert(c.size() == 5);
for(size_t i = 0; i < c.size(); ++i)
{
assert(c.front() == a2[i]);
c.pop_front();
}
}
[Bug rtl-optimization/64895] RA picks the wrong register for -fipa-ra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64895 --- Comment #20 from Iain Sandoe --- Author: iains Date: Fri Aug 30 19:00:44 2019 New Revision: 275213 URL: https://gcc.gnu.org/viewcvs?rev=275213&root=gcc&view=rev Log: [Darwin, testsuite] Backport fix for 64895 XPASSes. These tests don't fail on Darwin. 2019-08-30 Iain Sandoe Backport from mainline. 2019-05-23 Iain Sandoe PR rtl-optimisation/64895 * gcc.target/i386/fuse-caller-save-rec.c: Remove XFAILs. * gcc.target/i386/fuse-caller-save.c: Likewise. * gcc.target/i386/fuse-caller-save-xmm.c: Adjust tests for PIC cases, remove XFAILs. Modified: branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/gcc/testsuite/gcc.target/i386/fuse-caller-save-rec.c branches/gcc-8-branch/gcc/testsuite/gcc.target/i386/fuse-caller-save-xmm.c branches/gcc-8-branch/gcc/testsuite/gcc.target/i386/fuse-caller-save.c
[Bug target/91605] [10 Regression] ICE in ix86_avx256_split_vector_move_misalign, at config/i386/i386-expand.c:489 since r274986
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91605 --- Comment #2 from Bernd Edlinger --- Hmm, for whatever reason the decl-align of the "to" is 256 bit normally but when -fpack-struct is used only 8 bit aligned, but it is a reg. The reason for the ICE is that the movmisalign optab is rightfully confused when it is invoked with reg + reg. I think the following should fix the ICE: Index: expr.c === --- expr.c (revision 275063) +++ expr.c (working copy) @@ -5004,7 +5004,8 @@ expand_assignment (tree to, tree from, bool nontem || TREE_CODE (to) == TARGET_MEM_REF || DECL_P (to)) && mode != BLKmode - && (DECL_P (to) || !mem_ref_refers_to_non_mem_p (to)) + && (DECL_P (to) ? MEM_P (DECL_RTL (to)) + : !mem_ref_refers_to_non_mem_p (to)) && ((align = get_object_alignment (to)) < GET_MODE_ALIGNMENT (mode)) && (((icode = optab_handler (movmisalign_optab, mode))
[Bug middle-end/91599] GCC does not say where warning is happening
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91599 --- Comment #3 from Martin Sebor --- Author: msebor Date: Fri Aug 30 17:49:17 2019 New Revision: 275211 URL: https://gcc.gnu.org/viewcvs?rev=275211&root=gcc&view=rev Log: PR middle-end/91599 - GCC does not say where warning is happening gcc/ChangeLog: PR middle-end/91599 * tree-ssa-strlen.c (handle_store): Use a fallback location if the statement doesn't have one. * gimple-pretty-print.c (percent_G_format): Same. gcc/testsuite/ChangeLog: PR middle-end/91599 * gcc.dg/Wstringop-overflow-16.c: New test. Added: trunk/gcc/testsuite/gcc.dg/Wstringop-overflow-16.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-pretty-print.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-strlen.c
[Bug tree-optimization/88443] [meta-bug] bogus/missing -Wstringop-overflow warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443 Bug 88443 depends on bug 91599, which changed state. Bug 91599 Summary: GCC does not say where warning is happening https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91599 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug middle-end/91599] GCC does not say where warning is happening
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91599 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Martin Sebor --- Committed in r275211.
[Bug middle-end/91584] [9 Regression] Bogus warning from -Warray-bounds during string assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91584 Martin Sebor changed: What|Removed |Added Known to work||10.0 Known to fail||9.2.0 --- Comment #5 from Martin Sebor --- Fixed for GCC 10 in r275210. Will backport to 9.0.
[Bug middle-end/91584] [9 Regression] Bogus warning from -Warray-bounds during string assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91584 --- Comment #4 from Martin Sebor --- Author: msebor Date: Fri Aug 30 17:42:57 2019 New Revision: 275210 URL: https://gcc.gnu.org/viewcvs?rev=275210&root=gcc&view=rev Log: PR middle-end/91584 - Bogus warning from -Warray-bounds during string assignment gcc/ChangeLog: PR middle-end/91584 * tree-vrp.c (vrp_prop::check_mem_ref): Normalize type domain bounds before using them to validate MEM_REF offset. gcc/testsuite/ChangeLog: * gfortran.dg/char_array_constructor_4.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/char_array_constructor_4.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c
[Bug testsuite/91619] New: New test case gcc.dg/vect/pr81740-2.c fails on powerpc64 power7 BE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91619 Bug ID: 91619 Summary: New test case gcc.dg/vect/pr81740-2.c fails on powerpc64 power7 BE Product: gcc Version: 8.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- I'd guess that the test case is looking for something that isn't done on power7. It works fine on power8 BE. Executing on host: /home/seurer/gcc/build/gcc-8-test/gcc/xgcc -B/home/seurer/gcc/build/gcc-8-test/gcc/ /home/seurer/gcc/gcc-8-test/gcc/testsuite/gcc.dg/vect/pr81740-2.c -fno-diagnostics-show-caret -fdiagnostics-color=never -maltivec -mvsx -mno-allow-movmisalign -ftree-vectorize -fno-vect-cost-model -fno-common -O2 -fdump-tree-vect-details -lm -o ./pr81740-2.exe(timeout = 300) spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-8-test/gcc/xgcc -B/home/seurer/gcc/build/gcc-8-test/gcc/ /home/seurer/gcc/gcc-8-test/gcc/testsuite/gcc.dg/vect/pr81740-2.c -fno-diagnostics-show-caret -fdiagnostics-color=never -maltivec -mvsx -mno-allow-movmisalign -ftree-vectorize -fno-vect-cost-model -fno-common -O2 -fdump-tree-vect-details -lm -o ./pr81740-2.exe PASS: gcc.dg/vect/pr81740-2.c (test for excess errors) Setting LD_LIBRARY_PATH to :/home/seurer/gcc/build/gcc-8-test/gcc::/home/seurer/gcc/build/gcc-8-test/gcc:/home/seurer/gcc/build/gcc-8-test/./gmp/.libs:/home/seurer/gcc/build/gcc-8-test/./prev-gmp/.libs:/home/seurer/gcc/build/gcc-8-test/./mpfr/src/.libs:/home/seurer/gcc/build/gcc-8-test/./prev-mpfr/src/.libs:/home/seurer/gcc/build/gcc-8-test/./mpc/src/.libs:/home/seurer/gcc/build/gcc-8-test/./prev-mpc/src/.libs:/home/seurer/gcc/build/gcc-8-test/./isl/.libs:/home/seurer/gcc/build/gcc-8-test/./prev-isl/.libs Execution timeout is: 300 spawn [open ...] PASS: gcc.dg/vect/pr81740-2.c execution test FAIL: gcc.dg/vect/pr81740-2.c scan-tree-dump vect "OUTER LOOP VECTORIZED" Executing on host: /home/seurer/gcc/build/gcc-8-test/gcc/xgcc -B/home/seurer/gcc/build/gcc-8-test/gcc/ /home/seurer/gcc/gcc-8-test/gcc/testsuite/gcc.dg/vect/pr81740-2.c -fno-diagnostics-show-caret -fdiagnostics-color=never -flto -ffat-lto-objects -maltivec -mvsx -mno-allow-movmisalign -ftree-vectorize -fno-vect-cost-model -fno-common -O2 -fdump-tree-vect-details -lm -o ./pr81740-2.exe(timeout = 300) spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-8-test/gcc/xgcc -B/home/seurer/gcc/build/gcc-8-test/gcc/ /home/seurer/gcc/gcc-8-test/gcc/testsuite/gcc.dg/vect/pr81740-2.c -fno-diagnostics-show-caret -fdiagnostics-color=never -flto -ffat-lto-objects -maltivec -mvsx -mno-allow-movmisalign -ftree-vectorize -fno-vect-cost-model -fno-common -O2 -fdump-tree-vect-details -lm -o ./pr81740-2.exe PASS: gcc.dg/vect/pr81740-2.c -flto -ffat-lto-objects (test for excess errors) Setting LD_LIBRARY_PATH to :/home/seurer/gcc/build/gcc-8-test/gcc::/home/seurer/gcc/build/gcc-8-test/gcc:/home/seurer/gcc/build/gcc-8-test/./gmp/.libs:/home/seurer/gcc/build/gcc-8-test/./prev-gmp/.libs:/home/seurer/gcc/build/gcc-8-test/./mpfr/src/.libs:/home/seurer/gcc/build/gcc-8-test/./prev-mpfr/src/.libs:/home/seurer/gcc/build/gcc-8-test/./mpc/src/.libs:/home/seurer/gcc/build/gcc-8-test/./prev-mpc/src/.libs:/home/seurer/gcc/build/gcc-8-test/./isl/.libs:/home/seurer/gcc/build/gcc-8-test/./prev-isl/.libs Execution timeout is: 300 spawn [open ...] PASS: gcc.dg/vect/pr81740-2.c -flto -ffat-lto-objects execution test FAIL: gcc.dg/vect/pr81740-2.c -flto -ffat-lto-objects scan-tree-dump vect "OUTER LOOP VECTORIZED" testcase /home/seurer/gcc/gcc-8-test/gcc/testsuite/gcc.dg/vect/vect.exp completed in 1 seconds === gcc Summary === # of expected passes4 # of unexpected failures2
[Bug c++/91369] Implement P0784R7: constexpr new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91369
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
||jason at gcc dot gnu.org,
||redi at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek ---
Just playing around a little bit, on:
struct S { constexpr S () : s (5) {}; int s; };
constexpr bool foo ()
{
S *p = new S ();
delete p;
return true;
}
(so, trivial dtor rather than introducing constexpr dtors for now):
--- gcc/cp/constexpr.c.jj 2019-08-27 12:26:39.335884288 +0200
+++ gcc/cp/constexpr.c 2019-08-30 18:49:59.673689644 +0200
@@ -1666,6 +1666,34 @@ cxx_eval_call_expression (const constexp
lval, non_constant_p, overflow_p);
if (!DECL_DECLARED_CONSTEXPR_P (fun))
{
+ if (cxx_dialect >= cxx2a
+ && IDENTIFIER_NEWDEL_OP_P (DECL_NAME (fun))
+ && CP_DECL_CONTEXT (fun) == global_namespace)
+ {
+ if (IDENTIFIER_NEW_OP_P (DECL_NAME (fun)))
+ {
+ const int nargs = call_expr_nargs (t);
+ tree sz = NULL_TREE;
+ for (int i = 0; i < nargs; ++i)
+ {
+ tree arg = CALL_EXPR_ARG (t, i);
+ arg = cxx_eval_constant_expression (ctx, arg, false,
+ non_constant_p,
+ overflow_p);
+ VERIFY_CONSTANT (arg);
+ if (i == 0)
+ sz = arg;
+ }
+ gcc_assert (sz);
+ tree type = build_array_type_nelts (char_type_node,
+ tree_to_uhwi (sz));
+ tree var = build_decl (loc, VAR_DECL, NULL_TREE, type);
+ DECL_ARTIFICIAL (var) = 1;
+ return fold_convert (ptr_type_node, build_address (var));
+ }
+ else
+ /* FIXME */;
+ }
if (!ctx->quiet)
{
if (!lambda_static_thunk_p (fun))
@@ -6243,7 +6271,12 @@ potential_constant_expression_1 (tree t,
if (!DECL_DECLARED_CONSTEXPR_P (fun)
/* Allow any built-in function; if the expansion
isn't constant, we'll deal with that then. */
- && !fndecl_built_in_p (fun))
+ && !fndecl_built_in_p (fun)
+ /* In C++2a, replaceable global allocation functions
+ are constant expressions. */
+ && (cxx_dialect < cxx2a
+ || !IDENTIFIER_NEWDEL_OP_P (DECL_NAME (fun))
+ || CP_DECL_CONTEXT (fun) != global_namespace))
{
if (flags & tf_error)
{
This fails because we represent the new expression as COMPOUND_EXPR which first
calls the allocation function (handled by the above code) and then constructs
the var (effectively through a reinterpret cast not marked as such), and fail
on that:
r = cxx_fold_indirect_ref (EXPR_LOCATION (t), TREE_TYPE (t), op0,
&empty_base);
if (r == NULL_TREE)
{
/* We couldn't fold to a constant value. Make sure it's not
something we should have been able to fold. */
tree sub = op0;
STRIP_NOPS (sub);
if (TREE_CODE (sub) == ADDR_EXPR)
{
gcc_assert (!same_type_ignoring_top_level_qualifiers_p
(TREE_TYPE (TREE_TYPE (sub)), TREE_TYPE (t)));
/* DR 1188 says we don't have to deal with this. */
if (!ctx->quiet)
error ("accessing value of %qE through a %qT glvalue in a "
"constant expression", build_fold_indirect_ref (sub),
TREE_TYPE (t));
*non_constant_p = true;
return t;
}
if (lval && op0 != orig_op0)
return build1 (INDIRECT_REF, TREE_TYPE (t), op0);
if (!lval)
VERIFY_CONSTANT (t);
return t;
}
So, first of all, is it a good idea to represent the HEAP variables through
artifical VAR_DECLs?
I guess in the outermost constexpr evaluation context we'd need to track which
of those we have allocated and deallocated and do the checking that at the end
of outermost constexpr evaluation no allocations are left around, and that we
don't deallocate something that hasn't been allocated.
As we don't have the actual dynamic type they will have at the end of new
expression, should we mark them some way and either allow the first
cxx_fold_indirect_ref or the above code to change their type the first time
they are stored?
Is placement new ok in co
[Bug c++/91618] New: template-id required to friend a function template, even for a qualified-id
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91618
Bug ID: 91618
Summary: template-id required to friend a function template,
even for a qualified-id
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: barry.revzin at gmail dot com
Target Milestone: ---
Reduced from StackOverflow (https://stackoverflow.com/q/57730286/2069064):
template void f(T);
struct A {
friend void ::f(A);
};
gcc rejects this with:
source>:4:22: error: 'void f(A)' should have been declared inside '::'
4 | friend void ::f(A);
| ^
gcc accepts:
template void f(T);
struct A {
friend void ::f<>(A);
};
But [temp.friend]/1.3 says that qualified-ids can find matching function
templates... I shouldn't need to provide a template-id.
[Bug target/91481] POWER9 "DARN" RNG intrinsic produces repeated output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91481 --- Comment #15 from Jack Lloyd --- Thanks for the fast fix and backporting
[Bug target/91481] POWER9 "DARN" RNG intrinsic produces repeated output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91481 Segher Boessenkool changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #14 from Segher Boessenkool --- Fixed everywhere.
[Bug tree-optimization/90474] [7 Regression] ICE: verify_gimple failed (error: DECL_GIMPLE_REG_P set on a variable with address taken; error: invalid address operand in MEM_REF)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90474 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||7.4.1 Resolution|--- |FIXED Known to fail||7.4.0 --- Comment #10 from Richard Biener --- Fixed.
[Bug debug/90194] ICE in expand_debug_expr, at cfgexpand.c:5244
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90194 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||7.4.1 Resolution|--- |FIXED --- Comment #7 from Richard Biener --- Fixed.
[Bug tree-optimization/90071] [7 Regression] internal compiler error: SSA corruption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90071 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||7.4.1 Resolution|--- |FIXED --- Comment #9 from Richard Biener --- Fixed.
[Bug middle-end/89677] [7 Regression] internal compiler error: in wide_int_to_tree_1, at tree.c:1549
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89677 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||7.4.1 Resolution|--- |FIXED --- Comment #8 from Richard Biener --- Fixed.
[Bug other/63426] [meta-bug] Issues found with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426 Bug 63426 depends on bug 90213, which changed state. Bug 90213 Summary: UBSAN: signed integer overflow: -5621332293356458048 * 8 cannot be represented in type 'long int' https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90213 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/90213] UBSAN: signed integer overflow: -5621332293356458048 * 8 cannot be represented in type 'long int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90213 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||7.4.1 Resolution|--- |FIXED Target Milestone|--- |7.5 --- Comment #9 from Richard Biener --- Fixed.
[Bug tree-optimization/90930] Excessive memory consumption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90930 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||7.4.1 Resolution|--- |FIXED --- Comment #18 from Richard Biener --- Fixed.
[Bug middle-end/89677] [7 Regression] internal compiler error: in wide_int_to_tree_1, at tree.c:1549
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89677 --- Comment #7 from Richard Biener --- Author: rguenth Date: Fri Aug 30 16:44:17 2019 New Revision: 275208 URL: https://gcc.gnu.org/viewcvs?rev=275208&root=gcc&view=rev Log: 2019-08-30 Richard Biener Backport from mainline 2019-05-27 Richard Biener PR tree-optimization/90637 * tree-ssa-sink.c (statement_sink_location): Honor the computed sink location for single-uses. * gcc.dg/gomp/pr90637.c: New testcase. 2019-06-21 Richard Biener PR tree-optimization/90930 * tree-ssa-reassoc.c (rewrite_expr_tree_parallel): Set visited flag on new stmts to avoid re-processing them. 2019-05-15 Richard Biener PR c/90474 * c-common.c (c_common_mark_addressable_vec): Also mark a COMPOUND_LITERAL_EXPR_DECL addressable similar to c_mark_addressable. 2019-04-25 Richard Biener PR middle-end/90194 * match.pd: Add pattern to simplify view-conversion of an empty constructor. * g++.dg/torture/pr90194.C: New testcase. 2019-04-24 Richard Biener PR middle-end/90213 * gimple-fold.c (fold_const_aggregate_ref_1): Do multiplication by size and BITS_PER_UNIT on poly-wide-ints. 2019-04-15 Richard Biener PR tree-optimization/90071 * tree-ssa-reassoc.c (init_range_entry): Do not pick up abnormal operands from def stmts. * gcc.dg/torture/pr90071.c: New testcase. 2019-03-13 Richard Biener PR middle-end/89677 * tree-scalar-evolution.c (simplify_peeled_chrec): Do not throw FP expressions at tree-affine. * gcc.dg/torture/pr89677.c: New testcase. Added: branches/gcc-7-branch/gcc/testsuite/g++.dg/torture/pr90194.C branches/gcc-7-branch/gcc/testsuite/gcc.dg/torture/pr89677.c branches/gcc-7-branch/gcc/testsuite/gcc.dg/torture/pr90071.c Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/c-family/ChangeLog branches/gcc-7-branch/gcc/c-family/c-common.c branches/gcc-7-branch/gcc/gimple-fold.c branches/gcc-7-branch/gcc/match.pd branches/gcc-7-branch/gcc/testsuite/ChangeLog branches/gcc-7-branch/gcc/tree-scalar-evolution.c branches/gcc-7-branch/gcc/tree-ssa-reassoc.c branches/gcc-7-branch/gcc/tree-ssa-sink.c
[Bug tree-optimization/90071] [7 Regression] internal compiler error: SSA corruption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90071 --- Comment #8 from Richard Biener --- Author: rguenth Date: Fri Aug 30 16:44:17 2019 New Revision: 275208 URL: https://gcc.gnu.org/viewcvs?rev=275208&root=gcc&view=rev Log: 2019-08-30 Richard Biener Backport from mainline 2019-05-27 Richard Biener PR tree-optimization/90637 * tree-ssa-sink.c (statement_sink_location): Honor the computed sink location for single-uses. * gcc.dg/gomp/pr90637.c: New testcase. 2019-06-21 Richard Biener PR tree-optimization/90930 * tree-ssa-reassoc.c (rewrite_expr_tree_parallel): Set visited flag on new stmts to avoid re-processing them. 2019-05-15 Richard Biener PR c/90474 * c-common.c (c_common_mark_addressable_vec): Also mark a COMPOUND_LITERAL_EXPR_DECL addressable similar to c_mark_addressable. 2019-04-25 Richard Biener PR middle-end/90194 * match.pd: Add pattern to simplify view-conversion of an empty constructor. * g++.dg/torture/pr90194.C: New testcase. 2019-04-24 Richard Biener PR middle-end/90213 * gimple-fold.c (fold_const_aggregate_ref_1): Do multiplication by size and BITS_PER_UNIT on poly-wide-ints. 2019-04-15 Richard Biener PR tree-optimization/90071 * tree-ssa-reassoc.c (init_range_entry): Do not pick up abnormal operands from def stmts. * gcc.dg/torture/pr90071.c: New testcase. 2019-03-13 Richard Biener PR middle-end/89677 * tree-scalar-evolution.c (simplify_peeled_chrec): Do not throw FP expressions at tree-affine. * gcc.dg/torture/pr89677.c: New testcase. Added: branches/gcc-7-branch/gcc/testsuite/g++.dg/torture/pr90194.C branches/gcc-7-branch/gcc/testsuite/gcc.dg/torture/pr89677.c branches/gcc-7-branch/gcc/testsuite/gcc.dg/torture/pr90071.c Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/c-family/ChangeLog branches/gcc-7-branch/gcc/c-family/c-common.c branches/gcc-7-branch/gcc/gimple-fold.c branches/gcc-7-branch/gcc/match.pd branches/gcc-7-branch/gcc/testsuite/ChangeLog branches/gcc-7-branch/gcc/tree-scalar-evolution.c branches/gcc-7-branch/gcc/tree-ssa-reassoc.c branches/gcc-7-branch/gcc/tree-ssa-sink.c
[Bug tree-optimization/90474] [7 Regression] ICE: verify_gimple failed (error: DECL_GIMPLE_REG_P set on a variable with address taken; error: invalid address operand in MEM_REF)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90474 --- Comment #9 from Richard Biener --- Author: rguenth Date: Fri Aug 30 16:44:17 2019 New Revision: 275208 URL: https://gcc.gnu.org/viewcvs?rev=275208&root=gcc&view=rev Log: 2019-08-30 Richard Biener Backport from mainline 2019-05-27 Richard Biener PR tree-optimization/90637 * tree-ssa-sink.c (statement_sink_location): Honor the computed sink location for single-uses. * gcc.dg/gomp/pr90637.c: New testcase. 2019-06-21 Richard Biener PR tree-optimization/90930 * tree-ssa-reassoc.c (rewrite_expr_tree_parallel): Set visited flag on new stmts to avoid re-processing them. 2019-05-15 Richard Biener PR c/90474 * c-common.c (c_common_mark_addressable_vec): Also mark a COMPOUND_LITERAL_EXPR_DECL addressable similar to c_mark_addressable. 2019-04-25 Richard Biener PR middle-end/90194 * match.pd: Add pattern to simplify view-conversion of an empty constructor. * g++.dg/torture/pr90194.C: New testcase. 2019-04-24 Richard Biener PR middle-end/90213 * gimple-fold.c (fold_const_aggregate_ref_1): Do multiplication by size and BITS_PER_UNIT on poly-wide-ints. 2019-04-15 Richard Biener PR tree-optimization/90071 * tree-ssa-reassoc.c (init_range_entry): Do not pick up abnormal operands from def stmts. * gcc.dg/torture/pr90071.c: New testcase. 2019-03-13 Richard Biener PR middle-end/89677 * tree-scalar-evolution.c (simplify_peeled_chrec): Do not throw FP expressions at tree-affine. * gcc.dg/torture/pr89677.c: New testcase. Added: branches/gcc-7-branch/gcc/testsuite/g++.dg/torture/pr90194.C branches/gcc-7-branch/gcc/testsuite/gcc.dg/torture/pr89677.c branches/gcc-7-branch/gcc/testsuite/gcc.dg/torture/pr90071.c Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/c-family/ChangeLog branches/gcc-7-branch/gcc/c-family/c-common.c branches/gcc-7-branch/gcc/gimple-fold.c branches/gcc-7-branch/gcc/match.pd branches/gcc-7-branch/gcc/testsuite/ChangeLog branches/gcc-7-branch/gcc/tree-scalar-evolution.c branches/gcc-7-branch/gcc/tree-ssa-reassoc.c branches/gcc-7-branch/gcc/tree-ssa-sink.c
[Bug debug/90194] ICE in expand_debug_expr, at cfgexpand.c:5244
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90194 --- Comment #6 from Richard Biener --- Author: rguenth Date: Fri Aug 30 16:44:17 2019 New Revision: 275208 URL: https://gcc.gnu.org/viewcvs?rev=275208&root=gcc&view=rev Log: 2019-08-30 Richard Biener Backport from mainline 2019-05-27 Richard Biener PR tree-optimization/90637 * tree-ssa-sink.c (statement_sink_location): Honor the computed sink location for single-uses. * gcc.dg/gomp/pr90637.c: New testcase. 2019-06-21 Richard Biener PR tree-optimization/90930 * tree-ssa-reassoc.c (rewrite_expr_tree_parallel): Set visited flag on new stmts to avoid re-processing them. 2019-05-15 Richard Biener PR c/90474 * c-common.c (c_common_mark_addressable_vec): Also mark a COMPOUND_LITERAL_EXPR_DECL addressable similar to c_mark_addressable. 2019-04-25 Richard Biener PR middle-end/90194 * match.pd: Add pattern to simplify view-conversion of an empty constructor. * g++.dg/torture/pr90194.C: New testcase. 2019-04-24 Richard Biener PR middle-end/90213 * gimple-fold.c (fold_const_aggregate_ref_1): Do multiplication by size and BITS_PER_UNIT on poly-wide-ints. 2019-04-15 Richard Biener PR tree-optimization/90071 * tree-ssa-reassoc.c (init_range_entry): Do not pick up abnormal operands from def stmts. * gcc.dg/torture/pr90071.c: New testcase. 2019-03-13 Richard Biener PR middle-end/89677 * tree-scalar-evolution.c (simplify_peeled_chrec): Do not throw FP expressions at tree-affine. * gcc.dg/torture/pr89677.c: New testcase. Added: branches/gcc-7-branch/gcc/testsuite/g++.dg/torture/pr90194.C branches/gcc-7-branch/gcc/testsuite/gcc.dg/torture/pr89677.c branches/gcc-7-branch/gcc/testsuite/gcc.dg/torture/pr90071.c Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/c-family/ChangeLog branches/gcc-7-branch/gcc/c-family/c-common.c branches/gcc-7-branch/gcc/gimple-fold.c branches/gcc-7-branch/gcc/match.pd branches/gcc-7-branch/gcc/testsuite/ChangeLog branches/gcc-7-branch/gcc/tree-scalar-evolution.c branches/gcc-7-branch/gcc/tree-ssa-reassoc.c branches/gcc-7-branch/gcc/tree-ssa-sink.c
[Bug tree-optimization/90930] Excessive memory consumption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90930 --- Comment #17 from Richard Biener --- Author: rguenth Date: Fri Aug 30 16:44:17 2019 New Revision: 275208 URL: https://gcc.gnu.org/viewcvs?rev=275208&root=gcc&view=rev Log: 2019-08-30 Richard Biener Backport from mainline 2019-05-27 Richard Biener PR tree-optimization/90637 * tree-ssa-sink.c (statement_sink_location): Honor the computed sink location for single-uses. * gcc.dg/gomp/pr90637.c: New testcase. 2019-06-21 Richard Biener PR tree-optimization/90930 * tree-ssa-reassoc.c (rewrite_expr_tree_parallel): Set visited flag on new stmts to avoid re-processing them. 2019-05-15 Richard Biener PR c/90474 * c-common.c (c_common_mark_addressable_vec): Also mark a COMPOUND_LITERAL_EXPR_DECL addressable similar to c_mark_addressable. 2019-04-25 Richard Biener PR middle-end/90194 * match.pd: Add pattern to simplify view-conversion of an empty constructor. * g++.dg/torture/pr90194.C: New testcase. 2019-04-24 Richard Biener PR middle-end/90213 * gimple-fold.c (fold_const_aggregate_ref_1): Do multiplication by size and BITS_PER_UNIT on poly-wide-ints. 2019-04-15 Richard Biener PR tree-optimization/90071 * tree-ssa-reassoc.c (init_range_entry): Do not pick up abnormal operands from def stmts. * gcc.dg/torture/pr90071.c: New testcase. 2019-03-13 Richard Biener PR middle-end/89677 * tree-scalar-evolution.c (simplify_peeled_chrec): Do not throw FP expressions at tree-affine. * gcc.dg/torture/pr89677.c: New testcase. Added: branches/gcc-7-branch/gcc/testsuite/g++.dg/torture/pr90194.C branches/gcc-7-branch/gcc/testsuite/gcc.dg/torture/pr89677.c branches/gcc-7-branch/gcc/testsuite/gcc.dg/torture/pr90071.c Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/c-family/ChangeLog branches/gcc-7-branch/gcc/c-family/c-common.c branches/gcc-7-branch/gcc/gimple-fold.c branches/gcc-7-branch/gcc/match.pd branches/gcc-7-branch/gcc/testsuite/ChangeLog branches/gcc-7-branch/gcc/tree-scalar-evolution.c branches/gcc-7-branch/gcc/tree-ssa-reassoc.c branches/gcc-7-branch/gcc/tree-ssa-sink.c
[Bug tree-optimization/90637] [10 Regression] ICE in vect_loop_versioning, at tree-vect-loop-manip.c:3055
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90637 --- Comment #8 from Richard Biener --- Author: rguenth Date: Fri Aug 30 16:44:17 2019 New Revision: 275208 URL: https://gcc.gnu.org/viewcvs?rev=275208&root=gcc&view=rev Log: 2019-08-30 Richard Biener Backport from mainline 2019-05-27 Richard Biener PR tree-optimization/90637 * tree-ssa-sink.c (statement_sink_location): Honor the computed sink location for single-uses. * gcc.dg/gomp/pr90637.c: New testcase. 2019-06-21 Richard Biener PR tree-optimization/90930 * tree-ssa-reassoc.c (rewrite_expr_tree_parallel): Set visited flag on new stmts to avoid re-processing them. 2019-05-15 Richard Biener PR c/90474 * c-common.c (c_common_mark_addressable_vec): Also mark a COMPOUND_LITERAL_EXPR_DECL addressable similar to c_mark_addressable. 2019-04-25 Richard Biener PR middle-end/90194 * match.pd: Add pattern to simplify view-conversion of an empty constructor. * g++.dg/torture/pr90194.C: New testcase. 2019-04-24 Richard Biener PR middle-end/90213 * gimple-fold.c (fold_const_aggregate_ref_1): Do multiplication by size and BITS_PER_UNIT on poly-wide-ints. 2019-04-15 Richard Biener PR tree-optimization/90071 * tree-ssa-reassoc.c (init_range_entry): Do not pick up abnormal operands from def stmts. * gcc.dg/torture/pr90071.c: New testcase. 2019-03-13 Richard Biener PR middle-end/89677 * tree-scalar-evolution.c (simplify_peeled_chrec): Do not throw FP expressions at tree-affine. * gcc.dg/torture/pr89677.c: New testcase. Added: branches/gcc-7-branch/gcc/testsuite/g++.dg/torture/pr90194.C branches/gcc-7-branch/gcc/testsuite/gcc.dg/torture/pr89677.c branches/gcc-7-branch/gcc/testsuite/gcc.dg/torture/pr90071.c Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/c-family/ChangeLog branches/gcc-7-branch/gcc/c-family/c-common.c branches/gcc-7-branch/gcc/gimple-fold.c branches/gcc-7-branch/gcc/match.pd branches/gcc-7-branch/gcc/testsuite/ChangeLog branches/gcc-7-branch/gcc/tree-scalar-evolution.c branches/gcc-7-branch/gcc/tree-ssa-reassoc.c branches/gcc-7-branch/gcc/tree-ssa-sink.c
[Bug tree-optimization/90213] UBSAN: signed integer overflow: -5621332293356458048 * 8 cannot be represented in type 'long int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90213 --- Comment #8 from Richard Biener --- Author: rguenth Date: Fri Aug 30 16:44:17 2019 New Revision: 275208 URL: https://gcc.gnu.org/viewcvs?rev=275208&root=gcc&view=rev Log: 2019-08-30 Richard Biener Backport from mainline 2019-05-27 Richard Biener PR tree-optimization/90637 * tree-ssa-sink.c (statement_sink_location): Honor the computed sink location for single-uses. * gcc.dg/gomp/pr90637.c: New testcase. 2019-06-21 Richard Biener PR tree-optimization/90930 * tree-ssa-reassoc.c (rewrite_expr_tree_parallel): Set visited flag on new stmts to avoid re-processing them. 2019-05-15 Richard Biener PR c/90474 * c-common.c (c_common_mark_addressable_vec): Also mark a COMPOUND_LITERAL_EXPR_DECL addressable similar to c_mark_addressable. 2019-04-25 Richard Biener PR middle-end/90194 * match.pd: Add pattern to simplify view-conversion of an empty constructor. * g++.dg/torture/pr90194.C: New testcase. 2019-04-24 Richard Biener PR middle-end/90213 * gimple-fold.c (fold_const_aggregate_ref_1): Do multiplication by size and BITS_PER_UNIT on poly-wide-ints. 2019-04-15 Richard Biener PR tree-optimization/90071 * tree-ssa-reassoc.c (init_range_entry): Do not pick up abnormal operands from def stmts. * gcc.dg/torture/pr90071.c: New testcase. 2019-03-13 Richard Biener PR middle-end/89677 * tree-scalar-evolution.c (simplify_peeled_chrec): Do not throw FP expressions at tree-affine. * gcc.dg/torture/pr89677.c: New testcase. Added: branches/gcc-7-branch/gcc/testsuite/g++.dg/torture/pr90194.C branches/gcc-7-branch/gcc/testsuite/gcc.dg/torture/pr89677.c branches/gcc-7-branch/gcc/testsuite/gcc.dg/torture/pr90071.c Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/c-family/ChangeLog branches/gcc-7-branch/gcc/c-family/c-common.c branches/gcc-7-branch/gcc/gimple-fold.c branches/gcc-7-branch/gcc/match.pd branches/gcc-7-branch/gcc/testsuite/ChangeLog branches/gcc-7-branch/gcc/tree-scalar-evolution.c branches/gcc-7-branch/gcc/tree-ssa-reassoc.c branches/gcc-7-branch/gcc/tree-ssa-sink.c
[Bug tree-optimization/90930] Excessive memory consumption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90930 --- Comment #16 from Richard Biener --- Author: rguenth Date: Fri Aug 30 16:37:43 2019 New Revision: 275207 URL: https://gcc.gnu.org/viewcvs?rev=275207&root=gcc&view=rev Log: 2019-08-30 Richard Biener Backport from mainline 2019-05-27 Richard Biener PR tree-optimization/90637 * tree-ssa-sink.c (statement_sink_location): Honor the computed sink location for single-uses. 2019-06-21 Richard Biener PR tree-optimization/90930 * tree-ssa-reassoc.c (rewrite_expr_tree_parallel): Set visited flag on new stmts to avoid re-processing them. Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/tree-ssa-reassoc.c branches/gcc-8-branch/gcc/tree-ssa-sink.c
[Bug tree-optimization/90637] [10 Regression] ICE in vect_loop_versioning, at tree-vect-loop-manip.c:3055
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90637 --- Comment #7 from Richard Biener --- Author: rguenth Date: Fri Aug 30 16:37:43 2019 New Revision: 275207 URL: https://gcc.gnu.org/viewcvs?rev=275207&root=gcc&view=rev Log: 2019-08-30 Richard Biener Backport from mainline 2019-05-27 Richard Biener PR tree-optimization/90637 * tree-ssa-sink.c (statement_sink_location): Honor the computed sink location for single-uses. 2019-06-21 Richard Biener PR tree-optimization/90930 * tree-ssa-reassoc.c (rewrite_expr_tree_parallel): Set visited flag on new stmts to avoid re-processing them. Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/tree-ssa-reassoc.c branches/gcc-8-branch/gcc/tree-ssa-sink.c
[Bug tree-optimization/91108] [8 Regression] Fails to pun through unions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91108 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||8.3.1 Resolution|--- |FIXED Known to fail||8.3.0 --- Comment #5 from Richard Biener --- Fixed.
[Bug tree-optimization/91108] [8 Regression] Fails to pun through unions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91108 --- Comment #4 from Richard Biener --- Author: rguenth Date: Fri Aug 30 16:33:05 2019 New Revision: 275206 URL: https://gcc.gnu.org/viewcvs?rev=275206&root=gcc&view=rev Log: 2019-08-30 Richard Biener Backport from mainline 2019-07-08 Richard Biener PR tree-optimization/91108 * tree-ssa-sccvn.c: Include builtins.h. (vn_reference_lookup_3): Use only alignment constraints to verify same-valued store disambiguation. * gcc.dg/tree-ssa/pr91091-1.c: New testcase. * gcc.dg/tree-ssa/ssa-fre-78.c: Likewise. Added: branches/gcc-8-branch/gcc/testsuite/gcc.dg/tree-ssa/pr91091-1.c branches/gcc-8-branch/gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-78.c Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/gcc/tree-ssa-sccvn.c
[Bug target/91602] GCC fails to build for riscv in a combined tree due to misconfigured leb128 support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91602 Jim Wilson changed: What|Removed |Added CC||wilson at gcc dot gnu.org --- Comment #3 from Jim Wilson --- Combined tree builds are obsolete and shouldn't be used anymore. Since this only shows up in a combined tree build, I don't consider it important. If you build the toolchain the correct way, building binutils and gcc separately, the build does work. My preferred solution would be to kill combined tree build support.
[Bug libstdc++/51333] [7/8 Regression] cxxabi.h incompatible with -fkeep-inline-functions at link time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51333 --- Comment #13 from Jonathan Wakely --- Also fixed for 8.4
[Bug tree-optimization/83661] sincos does not handle sin(2x)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83661 --- Comment #6 from Christophe Monat --- (In reply to Alexander Monakov from comment #5) > sincos performs range reduction for the argument just once, which is fairly > important. A well-optimized sincos also shares some computations for the > sin/cos parts, as done in > https://github.com/ARM-software/optimized-routines/blob/master/math/sincosf.c Thanks for the pointer, indeed this implementation looks great. @Pratamesh #Linaro: is there synchronization between the ARM optimized routines and the usuals libc (glibc, newlib, musl,...) ? (snip) > (fwiw I'm against adding such transforms to the compiler) I would favor upgrading the routines if it's not already done, and not do any such transformation in the compiler.
[Bug go/91617] New: [10 regression] Many go test case failures after r275026
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91617 Bug ID: 91617 Summary: [10 regression] Many go test case failures after r275026 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: seurer at gcc dot gnu.org CC: cmang at google dot com Target Milestone: --- make check-go . . . FAIL: go.test/test/chan/select5.go execution FAIL: ./index0-out.go execution, -O0 -g -fno-var-tracking-assignments FAIL: go.test/test/ken/cplx2.go execution, -O2 -g FAIL: cmd/go/internal/generate FAIL: cmd/go/internal/get FAIL: cmd/go/internal/load FAIL: cmd/go/internal/modconv FAIL: cmd/go/internal/modfetch --- FAIL: TestPrintGolden (0.02s) --- FAIL: TestParseLax (0.00s) --- FAIL: TestPrintParse (0.00s) --- FAIL: TestAddRequire (0.00s) --- FAIL: TestAddRequire/#0 (0.00s) --- FAIL: TestAddRequire/#1 (0.00s) --- FAIL: TestAddRequire/#2 (0.00s) FAIL FAIL: cmd/go/internal/modfile FAIL: cmd/go/internal/modload FAIL: cmd/go/internal/work --- FAIL: TestResumption (0.01s) --- FAIL: TestResumption/TLSv12 (0.00s) --- FAIL: TestResumption/TLSv13 (0.01s) --- FAIL: TestVerifyPeerCertificate (0.14s) --- FAIL: TestVerifyPeerCertificate/TLSv12 (0.05s) --- FAIL: TestVerifyPeerCertificate/TLSv13 (0.08s) --- FAIL: TestGetClientCertificate (0.15s) --- FAIL: TestGetClientCertificate/TLSv12 (0.07s) --- FAIL: TestGetClientCertificate/TLSv13 (0.09s) --- FAIL: TestConnectionState (0.03s) --- FAIL: TestConnectionState/TLSv12 (0.01s) --- FAIL: TestConnectionState/TLSv13 (0.02s) FAIL FAIL: crypto/tls --- FAIL: TestGoVerify (0.11s) --- FAIL: TestCertificateParse (0.00s) --- FAIL: TestCreateSelfSignedCertificate (0.00s) FAIL: crypto/x509 --- FAIL: TestScanf (0.00s) --- FAIL: TestHexBytes (0.00s) FAIL FAIL: fmt --- FAIL: TestFilterDuplicates (0.00s) FAIL FAIL: go/ast --- FAIL: TestOps (0.00s) FAIL: go/constant FAIL: go/doc --- FAIL: TestNode (0.00s) --- FAIL: TestSource (0.00s) --- FAIL: TestPartial (0.00s) FAIL FAIL: go/format --- FAIL: TestBadNodes (0.00s) --- FAIL: TestSourcePos (0.00s) --- FAIL: TestIssue5945 (0.00s) --- FAIL: TestDeclLists (0.00s) --- FAIL: TestStmtLists (0.00s) --- FAIL: TestFuncType (0.00s) --- FAIL: TestCommentedNode (0.00s) --- FAIL: TestIssue11151 (0.00s) --- FAIL: TestBadComments (0.00s) --- FAIL: TestFiles (0.00s) --- FAIL: TestFiles/empty.input (0.00s) --- FAIL: TestFiles/complit.input (0.03s) --- FAIL: TestFiles/comments.input#01 (0.04s) --- FAIL: TestFiles/comments2.input (0.07s) --- FAIL: TestFiles/comments.input (0.13s) --- FAIL: TestFiles/alignment.input (0.13s) --- FAIL: TestFiles/statements.input (0.16s) --- FAIL: TestFiles/linebreaks.input (0.18s) --- FAIL: TestFiles/slow.input (0.25s) --- FAIL: TestFiles/declarations.input (0.26s) --- FAIL: TestFiles/expressions.input (0.26s) --- FAIL: TestFiles/expressions.input#01 (0.27s) --- FAIL: TestBaseIndent (0.04s) --- FAIL: TestBaseIndent/1 (0.22s) --- FAIL: TestBaseIndent/2 (0.25s) --- FAIL: TestBaseIndent/3 (0.25s) FAIL FAIL: go/printer --- FAIL: TestAddParseTree (0.00s) FAIL: html/template (may be more...) A couple of these happened before but almost all only started with r275026.
[Bug tree-optimization/83661] sincos does not handle sin(2x)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83661 --- Comment #5 from Alexander Monakov --- sincos performs range reduction for the argument just once, which is fairly important. A well-optimized sincos also shares some computations for the sin/cos parts, as done in https://github.com/ARM-software/optimized-routines/blob/master/math/sincosf.c I think in part the sincos pass was motivated by the fsincos instruction on the x87 fpu, which is also faster than two fsin+fcos instructions separately. (fwiw I'm against adding such transforms to the compiler)
[Bug tree-optimization/83661] sincos does not handle sin(2x)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83661 --- Comment #4 from Christophe Monat --- Hi Pratamesh, You're absolutely right - maybe it's more efficient when there is some hardware sincos available (Intel FSINCOS ?) but I would check also carefully the actual performance. Indeed, it looks to me that either you have to use two different polynomials or shift one argument and use either sin or cos, but anyway twice. We studied that in a slightly different context with Claude-Pierre Jeannerod from ENS Lyon and our PhD Jingyan Lu-Jourdan a while ago : "Simultaneous floating-point sine and cosine for VLIW integer processors" available here: https://hal.archives-ouvertes.fr/hal-00672327 and we were able to gain significant performance by exploiting the low-level parallelism of the processor. Agreed, this is not a full IEEE implementation but the important ideas are there.
[Bug fortran/80645] FAIL: gfortran.dg/elemental_subroutine_3.f90 -O1 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80645 --- Comment #17 from Martin Sebor --- r274996 finally correctly disabled -Wstringop-overflow (and other language-specific middle-end warnings) for Fortran (and other languages they're not meant for) so that might explain why the fails have disappeared. The bug should stay open until the questions about the correctness of the Fotran-emitted code have been settled.
[Bug tree-optimization/83661] sincos does not handle sin(2x)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83661 --- Comment #3 from prathamesh3492 at gcc dot gnu.org --- Oh, I thought sincos simultaneously calculated values of sin and cos ? If that's not the case, then I wonder how is sincos transform itself beneficial ? Thanks, Prathamesh
[Bug target/91612] [10 regression][arm] gcc.target/arm/aapcs/align4.c ICE after r274986
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91612 Bernd Edlinger changed: What|Removed |Added CC||bernd.edlinger at hotmail dot de --- Comment #1 from Bernd Edlinger --- this is related to pr91603 which is a reduced test case from align4.c where wrong code happened before r27485
[Bug tree-optimization/91616] New: Incorrect data address computation in very simple code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91616
Bug ID: 91616
Summary: Incorrect data address computation in very simple code
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: mpoulhies at kalray dot eu
Target Milestone: ---
The following code is miscompiled in O2 only (0,1 and 3 are correct):
typedef unsigned long long uint64_t;
uint64_t data_array[16] = {0};
unsigned int i = 0;
int main(void) {
unsigned long long seed = 0xcafebebedeadbeef;
for (i = 0; i < 16; i++)
data_array[i] = (seed++);
return 0;
}
It emits:
main:
movabs rax, -3819405706974609681
movabs rsi, OFFSET FLAT:data_array-633824249165792 // <- this is not
correct
movabs rcx, -3819405706974609665
.L2:
mov rdx, rax
add rax, 1
mov QWORD PTR [rsi+rax*8], rdx
cmp rax, rcx
jne .L2
mov DWORD PTR i[rip], 16
xor eax, eax
ret
i:
.zero 4
data_array:
.zero 128
After looking at compilers available on godbolt, all GCC starting from 8.* are
showing this behavior, see https://godbolt.org/z/OX0s10
The pass that seems to introduce this wrong address is 'ivopts' (first seen in
164t.ivopts in 9.2.1)
[Bug libstdc++/51333] [7/8 Regression] cxxabi.h incompatible with -fkeep-inline-functions at link time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51333 --- Comment #12 from Jonathan Wakely --- Author: redi Date: Fri Aug 30 15:01:10 2019 New Revision: 275192 URL: https://gcc.gnu.org/viewcvs?rev=275192&root=gcc&view=rev Log: PR libstdc++/51333 Define recursive_init_error constructor non-inline The recursive_init_error class is defined in a header, with an inline constructor, but the definition of the vtable and destructor are not exported from the shared library. With -fkeep-inline-functions the constructor gets emitted in user code, and requires the (non-exported) vtable. This fails to link. As far as I can tell, the recursive_init_error class definition was moved into so it could be documented with Doxygen, not for any technical reason. But now it's there (and documented), somebody could be relying on it, by catching that type and possibly performing derived-to-base conversions to the std::exception base class. So the conservative fix is to leave the class definition in the header but make the constructor non-inline. This still allows the type to be caught and still defines its base class. Backport from mainline 2019-07-29 Jonathan Wakely PR libstdc++/51333 * libsupc++/cxxabi.h (__gnu_cxx::recursive_init_error): Do not define constructor inline. * libsupc++/guard_error.cc (__gnu_cxx::recursive_init_error): Define constructor. * testsuite/18_support/51333.cc: New test. Added: branches/gcc-8-branch/libstdc++-v3/testsuite/18_support/51333.cc Modified: branches/gcc-8-branch/libstdc++-v3/ChangeLog branches/gcc-8-branch/libstdc++-v3/libsupc++/cxxabi.h branches/gcc-8-branch/libstdc++-v3/libsupc++/guard_error.cc
[Bug libstdc++/91308] [7/8 Regression] unique_ptr assignment fails with different deleters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91308 --- Comment #3 from Jonathan Wakely --- Author: redi Date: Fri Aug 30 15:01:15 2019 New Revision: 275193 URL: https://gcc.gnu.org/viewcvs?rev=275193&root=gcc&view=rev Log: PR libstdc++/91308 fix constraints on unique_ptr assignment Backport from mainline 2019-07-31 Jonathan Wakely PR libstdc++/91308 * include/bits/unique_ptr.h (unique_ptr::__safe_conversion_up): Remove constraints on deleter that should only apply to the constructor. (unique_ptr::__safe_conversion_up): Likewise. (unique_ptr::unique_ptr(unique_ptr&&)): Restore constraints on deleter here. * testsuite/20_util/unique_ptr/assign/91308.cc: New test. Added: branches/gcc-8-branch/libstdc++-v3/testsuite/20_util/unique_ptr/assign/91308.cc Modified: branches/gcc-8-branch/libstdc++-v3/ChangeLog branches/gcc-8-branch/libstdc++-v3/include/bits/unique_ptr.h
[Bug target/91615] [10 regression][armeb] ICEs since r274986
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91615 --- Comment #1 from Christophe Lyon --- There are also 2 regressions in gfortran --target armeb-none-linux-gnueabihf --with-cpu cortex-a9 --with-fpu neon-fp16 gfortran.dg/vect/no-vfa-pr32377.f90 -O (internal compiler error) gfortran.dg/vect/pr32377.f90 -O (internal compiler error) Same backtrace for both: during RTL pass: expand /gcc/testsuite/gfortran.dg/vect/no-vfa-pr32377.f90:10:0: internal compiler error: in gen_movv4sf, at config/arm/vec-common.md:30 0x12e016c gen_movv4sf(rtx_def*, rtx_def*) /gcc/config/arm/vec-common.md:30 0x90cfe2 insn_gen_fn::operator()(rtx_def*, rtx_def*) const /gcc/recog.h:318 0x90cfe2 emit_move_insn_1(rtx_def*, rtx_def*) /gcc/expr.c:3694 0x90d2d3 emit_move_insn(rtx_def*, rtx_def*) /gcc/expr.c:3790 0x8e80cc copy_to_mode_reg(machine_mode, rtx_def*) /gcc/explow.c:631 0xb81b01 maybe_legitimize_operand /gcc/optabs.c:7246 0xb81b01 maybe_legitimize_operands(insn_code, unsigned int, unsigned int, expand_operand*) /gcc/optabs.c:7378 0xb81e69 maybe_gen_insn(insn_code, unsigned int, expand_operand*) /gcc/optabs.c:7397 0xb88a6a expand_binop_directly /gcc/optabs.c:1122 0xb865b8 expand_binop(machine_mode, optab_tag, rtx_def*, rtx_def*, rtx_def*, int, optab_methods) /gcc/optabs.c:1210 0x8efa0d expand_mult(machine_mode, rtx_def*, rtx_def*, rtx_def*, int, bool) /gcc/expmed.c:3549 0x91a8ed expand_expr_real_2(separate_ops*, rtx_def*, machine_mode, expand_modifier) /gcc/expr.c:8937 0x909d42 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) /gcc/expr.c:9948 0x913b1e expand_expr /gcc/expr.h:281 0x913b1e expand_operands(tree_node*, tree_node*, rtx_def*, rtx_def**, rtx_def**, expand_modifier) /gcc/expr.c:7878 0x918c23 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode, expand_modifier) /gcc/expr.c:8739 0x909d42 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) /gcc/expr.c:9948 0x914d32 store_expr(tree_node*, rtx_def*, int, bool, bool) /gcc/expr.c:5682 0x916a26 expand_assignment(tree_node*, tree_node*, bool) /gcc/expr.c:5441 0x7d7494 expand_gimple_stmt_1 /gcc/cfgexpand.c:3779
[Bug target/91615] New: [10 regression][armeb] ICEs since r274986
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91615 Bug ID: 91615 Summary: [10 regression][armeb] ICEs since r274986 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: clyon at gcc dot gnu.org Target Milestone: --- Since r274986 with the patch from https://gcc.gnu.org/ml/gcc-patches/2019-08/msg02018.html, I've noticed ICEs on armeb (arm big-endian cross compiler): gcc.c-torture/execute/pr37573.c -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (internal compiler error) gcc.c-torture/execute/pr37573.c -O3 -g (internal compiler error) gcc.dg/vect/fast-math-pr35982.c (internal compiler error) gcc.dg/vect/pr55857-1.c (internal compiler error) gcc.dg/vect/pr55857-1.c -flto -ffat-lto-objects (internal compiler error) gcc.dg/vect/pr55857-2.c (internal compiler error) gcc.dg/vect/pr55857-2.c -flto -ffat-lto-objects (internal compiler error) gcc.dg/vect/pr57558-2.c (internal compiler error) gcc.dg/vect/pr57558-2.c -flto -ffat-lto-objects (internal compiler error) --target armeb-none-linux-gnueabihf --with-mode arm --with-cpu cortex-a9 --with-fpu neon-fp16 For pr37573: during RTL pass: expand /gcc/testsuite/gcc.c-torture/execute/pr37573.c: In function 'foo': /gcc/testsuite/gcc.c-torture/execute/pr37573.c:21:21: internal compiler error: in gen_movv4si, at config/arm/vec-common.md:30 0x1272a4c gen_movv4si(rtx_def*, rtx_def*) /gcc/config/arm/vec-common.md:30 0x896e82 insn_gen_fn::operator()(rtx_def*, rtx_def*) const /gcc/recog.h:318 0x896e82 emit_move_insn_1(rtx_def*, rtx_def*) /gcc/expr.c:3694 0x897173 emit_move_insn(rtx_def*, rtx_def*) /gcc/expr.c:3790 0x89f055 store_expr(tree_node*, rtx_def*, int, bool, bool) /gcc/expr.c:5855 0x8a08c6 expand_assignment(tree_node*, tree_node*, bool) /gcc/expr.c:5441 0x761a54 expand_gimple_stmt_1 /gcc/cfgexpand.c:3779 0x761a54 expand_gimple_stmt /gcc/cfgexpand.c:3875 0x768673 expand_gimple_basic_block /gcc/cfgexpand.c:5915 0x76acb6 execute /gcc/cfgexpand.c:6538 For fast-math-pr35982: during RTL pass: expand /gcc/testsuite/gcc.dg/vect/fast-math-pr35982.c: In function 'method2_int16': /gcc/testsuite/gcc.dg/vect/fast-math-pr35982.c:18:10: internal compiler error: in gen_movv2si, at config/arm/vec-common.md:30 0x12723cc gen_movv2si(rtx_def*, rtx_def*) /gcc/config/arm/vec-common.md:30 0x896e82 insn_gen_fn::operator()(rtx_def*, rtx_def*) const /gcc/recog.h:318 0x896e82 emit_move_insn_1(rtx_def*, rtx_def*) /gcc/expr.c:3694 0x897173 emit_move_insn(rtx_def*, rtx_def*) /gcc/expr.c:3790 0x870f41 force_reg(machine_mode, rtx_def*) /gcc/explow.c:655 0xb1743b expand_vec_perm_const(machine_mode, rtx_def*, rtx_def*, int_vector_builder > const&, machine_mode, rtx_def*) /gcc/optabs.c:5633 0x8a4f6c expand_expr_real_2(separate_ops*, rtx_def*, machine_mode, expand_modifier) /gcc/expr.c:9589 0x893be2 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) /gcc/expr.c:9948 0x8a3823 expand_normal /gcc/expr.h:287 0x8a3823 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode, expand_modifier) /gcc/expr.c:9034 0x893be2 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) /gcc/expr.c:9948 0x89d9be expand_expr /gcc/expr.h:281 0x89d9be expand_operands(tree_node*, tree_node*, rtx_def*, rtx_def**, rtx_def**, expand_modifier) /gcc/expr.c:7878 0x8a4324 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode, expand_modifier) /gcc/expr.c:8936 0x893be2 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) /gcc/expr.c:9948 0x89d9be expand_expr /gcc/expr.h:281 0x89d9be expand_operands(tree_node*, tree_node*, rtx_def*, rtx_def**, rtx_def**, expand_modifier) /gcc/expr.c:7878 0x8a2ac3 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode, expand_modifier) /gcc/expr.c:8739 0x761600 expand_gimple_stmt_1 /gcc/cfgexpand.c:3815 0x761600 expand_gimple_stmt /gcc/cfgexpand.c:3875 For pr55857-1.c: during RTL pass: expand /gcc/testsuite/gcc.dg/vect/pr55857-1.c: In function 'foo': /gcc/testsuite/gcc.dg/vect/pr55857-1.c:13:19: internal compiler error: in gen_movv4si, at config/arm/vec-common.md:30 0x1272a4c gen_movv4si(rtx_def*, rtx_def*) /gcc/config/arm/vec-common.md:30 0x896e82 insn_gen_fn::operator()(rtx_def*, rtx_def*) const /gcc/recog.h:318 0x896e82 emit_move_insn_1(rtx_def*, rtx_def*) /gcc/expr.c:3694 0x897173 emit_move_insn(rtx_def*, rtx_def*) /gcc/expr.c:3790 0x871f6c copy_to_mode_reg(machine_mode, rtx_def*) /gcc/explow.c:631 0xb0b7a1 maybe_legitimize_operand /gcc/optabs.c:7246 0xb0b7a1 maybe_l
[Bug debug/91611] debug info for register keyword variables at O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91611
--- Comment #2 from Tom de Vries ---
Also, consider test2.c (as test2.c in PR91610, but with register keyword for
variable l in wack_signed_char):
...
#include
signed char
add_signed_char (signed char u, signed char v)
{
return u + v;
}
signed char
wack_signed_char (signed char u, signed char v)
{
register signed char l = u, r = v;
l = add_signed_char (l, r);
return l + r;
}
int
main ()
{
signed char res = wack_signed_char (-1, -2);
printf ("%d\n", res);
return 0;
}
...
With Og:
...
$ gcc test2.c -g -Og
...
we have the expected l == 2 result:
...
$ gdb -q a.out -ex "b test2.c:13" -ex run
Reading symbols from a.out...done.
Breakpoint 1 at 0x400527: file test2.c, line 13.
Starting program: /data/gdb_versions/devel/a.out
Breakpoint 1, wack_signed_char (u=u@entry=-1 '\377', v=v@entry=-2 '\376') at
test2.c:13
13l = add_signed_char (l, r);
(gdb) p l
$1 = -1 '\377'
(gdb) p r
$2 = -2 '\376'
(gdb) set variable l = 4
(gdb) p l
$3 = 4 '\004'
(gdb) n
14return l + r;
(gdb) p l
$4 = 2 '\002'
...
However, when we use -O0 plus all the debug flags that are enabled at > O0
according to the docs:
...
$gcc test2.c -g -O0 -fvar-tracking -fvar-tracking-assignments
-gstatement-frontiers
...
we get:
...
$ gdb -q a.out -ex "b test2.c:13" -ex run
Reading symbols from a.out...done.
Breakpoint 1 at 0x400558: file test2.c, line 13.
Starting program: /data/gdb_versions/devel/a.out
Breakpoint 1, wack_signed_char (u=u@entry=-1 '\377', v=v@entry=-2 '\376') at
test2.c:13
13l = add_signed_char (l, r);
(gdb) p l
$1 = -1 '\377'
(gdb) p r
$2 = -2 '\376'
(gdb) set variable l = 4
(gdb) p l
$3 = 4 '\004'
(gdb) n
14return l + r;
(gdb) p l
$4 = -3 '\375'
...
[Bug target/91614] [10 regression][arm] gcc.target/arm/unaligned-memcpy-2.c FAIL since r274986
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91614 --- Comment #1 from Christophe Lyon --- The same is true --with-cpu cortex-a57 --with-fpu crypto-neon-fp-armv8
[Bug target/91614] New: [10 regression][arm] gcc.target/arm/unaligned-memcpy-2.c FAIL since r274986
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91614 Bug ID: 91614 Summary: [10 regression][arm] gcc.target/arm/unaligned-memcpy-2.c FAIL since r274986 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: clyon at gcc dot gnu.org Target Milestone: --- Since r274986, even with the patch from https://gcc.gnu.org/ml/gcc-patches/2019-08/msg02018.html, I've noticed: FAIL: gcc.target/arm/unaligned-memcpy-2.c scan-assembler-times ldrd 0 FAIL: gcc.target/arm/unaligned-memcpy-3.c scan-assembler-times strd 0 on target arm-none-linux-gnueabihf --with-mode arm --with-cpu cortex-a15 --with-fpu neon-vfpv4 When building GCC --with-mode thumb, the regressions are: FAIL: gcc.target/arm/unaligned-memcpy-2.c scan-assembler-times ldrd 0 FAIL: gcc.target/arm/unaligned-memcpy-2.c scan-assembler-times strd 1 FAIL: gcc.target/arm/unaligned-memcpy-3.c scan-assembler-times ldrd 1 FAIL: gcc.target/arm/unaligned-memcpy-3.c scan-assembler-times strd 0
[Bug target/91613] New: [10 regression][arm] gcc.dg/pr83930.c ICE since r274986
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91613 Bug ID: 91613 Summary: [10 regression][arm] gcc.dg/pr83930.c ICE since r274986 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: clyon at gcc dot gnu.org Target Milestone: --- After r274986, even with the patch from https://gcc.gnu.org/ml/gcc-patches/2019-08/msg02018.html, I've noticed: FAIL: gcc.dg/pr83930.c (internal compiler error) --target arm-none-linux-gnueabi --with-mode thumb --with-cpu cortex-a9 with Dejagnu RUNTESTFLAGS: -march=armv5t during RTL pass: expand /gcc/testsuite/gcc.dg/pr83930.c: In function 'foo': /gcc/testsuite/gcc.dg/pr83930.c:10:5: internal compiler error: in gen_movsi, at config/arm/arm.md:5435 0x12670cd gen_movsi(rtx_def*, rtx_def*) /gcc/config/arm/arm.md:5435 0x896e82 insn_gen_fn::operator()(rtx_def*, rtx_def*) const /gcc/recog.h:318 0x896e82 emit_move_insn_1(rtx_def*, rtx_def*) /gcc/expr.c:3694 0x897173 emit_move_insn(rtx_def*, rtx_def*) /gcc/expr.c:3790 0x74147f emit_library_call_value_1(int, rtx_def*, rtx_def*, libcall_type, machine_mode, int, std::pair*) /gcc/calls.c:5262 0xb10d95 emit_library_call_value(rtx_def*, rtx_def*, libcall_type, machine_mode, rtx_def*, machine_mode, rtx_def*, machine_mode) /gcc/rtl.h:4225 0xb10d95 expand_binop(machine_mode, optab_tag, rtx_def*, rtx_def*, rtx_def*, int, optab_methods) /gcc/optabs.c:1833 0xb12eca sign_expand_binop(machine_mode, optab_tag, optab_tag, rtx_def*, rtx_def*, rtx_def*, int, optab_methods) /gcc/optabs.c:1964 0x8813f9 expand_divmod(int, tree_code, machine_mode, rtx_def*, rtx_def*, rtx_def*, int) /gcc/expmed.c:5232 0x8a3802 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode, expand_modifier) /gcc/expr.c:9002 0x893be2 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) /gcc/expr.c:9948 0x88bba6 expand_normal /gcc/expr.h:287 0x88bba6 store_field /gcc/expr.c:7027 0x88cc18 store_constructor_field /gcc/expr.c:6275 0x88d103 store_constructor /gcc/expr.c:6885 0x88f609 expand_constructor /gcc/expr.c:8203 0x892d95 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) /gcc/expr.c:10265 0x8922b6 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) /gcc/expr.c:9954 0x89ebd2 store_expr(tree_node*, rtx_def*, int, bool, bool) /gcc/expr.c:5682 0x8a08c6 expand_assignment(tree_node*, tree_node*, bool) /gcc/expr.c:5441 The test passes when using ARM mode.
[Bug target/91612] New: [10 regression][arm] gcc.target/arm/aapcs/align4.c ICE after r274986
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91612 Bug ID: 91612 Summary: [10 regression][arm] gcc.target/arm/aapcs/align4.c ICE after r274986 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: clyon at gcc dot gnu.org Target Milestone: --- Since r274985, I've noticed new failures, not fixed by the patch proposed at https://gcc.gnu.org/ml/gcc-patches/2019-08/msg02018.html FAIL: gcc.target/arm/aapcs/align4.c (internal compiler error) FAIL: gcc.target/arm/aapcs/align_rec4.c (internal compiler error) Seen on cross-compilers for arm-none-linux-gnueabi[hf]. during RTL pass: expand In file included from /gcc/testsuite/gcc.target/arm/aapcs/align4.c:22: /gcc/testsuite/gcc.target/arm/aapcs/align4.c: In function 'testfunc': /gcc/testsuite/gcc.target/arm/aapcs/abitest.h:73:42: internal compiler error: in gen_movv2si, at config/arm/vec-common.md:30 /gcc/testsuite/gcc.target/arm/aapcs/abitest.h:74:30: note: in expansion of macro 'LAST_ARG' /gcc/testsuite/gcc.target/arm/aapcs/align4.c:26:3: note: in expansion of macro 'ARG' 0x12723cc gen_movv2si(rtx_def*, rtx_def*) /gcc/config/arm/vec-common.md:30 0x896e82 insn_gen_fn::operator()(rtx_def*, rtx_def*) const /gcc/recog.h:318 0x896e82 emit_move_insn_1(rtx_def*, rtx_def*) /gcc/expr.c:3694 0x897173 emit_move_insn(rtx_def*, rtx_def*) /gcc/expr.c:3790 0x89f055 store_expr(tree_node*, rtx_def*, int, bool, bool) /gcc/expr.c:5855 0x8a08c6 expand_assignment(tree_node*, tree_node*, bool) /gcc/expr.c:5441 0x761a54 expand_gimple_stmt_1 /gcc/cfgexpand.c:3779 0x761a54 expand_gimple_stmt /gcc/cfgexpand.c:3875 0x768673 expand_gimple_basic_block /gcc/cfgexpand.c:5915 0x76acb6 execute /gcc/cfgexpand.c:6538 Please submit a full bug report,
[Bug debug/91611] debug info for register keyword variables at O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91611
--- Comment #1 from Tom de Vries ---
FWIW, the debug experience does not feel very O0-ish because of the missing "b
= a" assignment.
Using this demonstrator patch:
...
diff --git a/gcc/lra-spills.c b/gcc/lra-spills.c
index a322da81544..db18ff43281 100644
--- a/gcc/lra-spills.c
+++ b/gcc/lra-spills.c
@@ -785,7 +785,7 @@ lra_final_code_change (void)
unless next insn is USE marking the return reg (we should
save this as some subsequent optimizations assume that
such original insns are saved). */
- if (NONJUMP_INSN_P (insn) && GET_CODE (pat) == SET
+ if (0 && NONJUMP_INSN_P (insn) && GET_CODE (pat) == SET
&& REG_P (SET_SRC (pat)) && REG_P (SET_DEST (pat))
&& REGNO (SET_SRC (pat)) == REGNO (SET_DEST (pat))
&& (! return_regno_p (REGNO (SET_SRC (pat)))
@@ -834,7 +834,7 @@ lra_final_code_change (void)
if (insn_change_p)
lra_update_operator_dups (id);
- if ((set = single_set (insn)) != NULL
+ if (0 && (set = single_set (insn)) != NULL
&& REG_P (SET_SRC (set)) && REG_P (SET_DEST (set))
&& REGNO (SET_SRC (set)) == REGNO (SET_DEST (set)))
{
diff --git a/gcc/recog.c b/gcc/recog.c
index a9f584bc0dc..1ae158cb69d 100644
--- a/gcc/recog.c
+++ b/gcc/recog.c
@@ -2995,7 +2995,7 @@ split_all_insns (void)
is too risky to try to do this before register
allocation, and there are unlikely to be very many
nops then anyways. */
- if (reload_completed)
+ if (0 && reload_completed)
delete_insn_and_edges (insn);
if (note)
need_cfg_cleanup = true;
...
we manage to produce the "b = a" assignment in the assembly:
...
#(insn 6 26 30 2 (set (reg/v:SF 21 xmm1 [orig:84 b ] [84])
#(reg/v:SF 21 xmm1 [orig:83 a ] [83])) "test.c":7:5 112
{*movsf_internal}
# (nil))
movaps %xmm1, %xmm1# 6 [c=4 l=3] *movsf_internal/6
...
and get O0-ish behaviour:
...
$ gdb -q a.out -ex start
Reading symbols from a.out...done.
Temporary breakpoint 1 at 0x4004b0: file test.c, line 3.
Starting program: /data/gcc_versions/devel/a.out
Temporary breakpoint 1, main () at test.c:3
3 {
(gdb) n
6 a = 1.0;
(gdb)
7 b = a;
(gdb) p a
$1 = 1
(gdb) n
8 return b == 1.0;
(gdb) p b
$2 = 1
...
[Bug debug/91611] New: debug info for register keyword variables at O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91611
Bug ID: 91611
Summary: debug info for register keyword variables at O0
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
Consider this test-case:
...
int
main (void)
{
register float a;
register float b;
a = 1.0;
b = a;
return b == 1.0;
}
...
When compiled with -O0 -g, no DW_AT_location is generated for a and b.
The register keyword is documented in the C standard as: "suggests that access
to the object be as fast as possible".
GCC implements the register keyword at -O0 as documented here (
https://gcc.gnu.org/onlinedocs/gcc/Hints-implementation.html#Hints-implementation
):
...
* When -O0 is in use, the compiler allocates distinct stack memory for all
variables that do not have the register storage-class specifier; if register is
specified, the variable may have a shorter lifespan than the code would
indicate and may never be placed in memory.
...
So, it's made clear that using this hint at -O0 may degrade debug info for the
variable (much like using higher than -O0 may degrade debug info for all
variables).
So I'd say the current -O0 behaviour is valid.
Having said that, what would it take to emit the debug info?
Using -fvar-tracking gets us further:
...
$ gdb -q a.out -ex start
Reading symbols from a.out...done.
Temporary breakpoint 1 at 0x400492: file test.c, line 3.
Starting program: /data/gcc_versions/devel/a.out
Temporary breakpoint 1, main () at test.c:3
3 {
(gdb) n
6 a = 1.0;
(gdb) p a
$1 =
(gdb) n
8 return b == 1.0;
(gdb) p a
$2 = 1
(gdb) p b
$3 = 1
...
[ So, we could enable var-tracking at -O0 in a function if it contains the
register keyword in a local variable. However, currently using var-tracking at
-O0 can also degrade debug info (PR91610), so that would have to be addressed
first. ]
[Bug debug/91610] New: fvar-tracking degrades -O0 debug info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91610
Bug ID: 91610
Summary: fvar-tracking degrades -O0 debug info
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
Consider this test-case:
...
$ cat test2.c
#include
signed char
add_signed_char (signed char u, signed char v)
{
return u + v;
}
signed char
wack_signed_char (signed char u, signed char v)
{
signed char l = u, r = v;
l = add_signed_char (l, r);
return l + r;
}
int
main ()
{
signed char res = wack_signed_char (-1, -2);
printf ("%d\n", res);
return 0;
}
...
When compiled with debug-info at -O0:
...
$ gcc test2.c -g
...
We get the expected value l == 2 out of this debug session:
...
$ gdb -q a.out -ex "b test2.c:13" -ex run
Reading symbols from a.out...done.
Breakpoint 1 at 0x400541: file test2.c, line 13.
Starting program: /data/gdb_versions/devel/a.out
Breakpoint 1, wack_signed_char (u=-1 '\377', v=-2 '\376') at test2.c:13
13l = add_signed_char (l, r);
(gdb) p l
$1 = -1 '\377'
(gdb) p r
$2 = -2 '\376'
(gdb) set variable l = 4
(gdb) p l
$3 = 4 '\004'
(gdb) n
14return l + r;
(gdb) p l
$4 = 2 '\002'
...
However, with -fvar-tracking added:
...
$ gcc test2.c -g -fvar-tracking
...
we get an incorrect l == -3:
...
$ gdb -q a.out -ex "b test2.c:13" -ex run
Reading symbols from a.out...done.
Breakpoint 1 at 0x400541: file test2.c, line 13.
Starting program: /data/gdb_versions/devel/a.out
Breakpoint 1, wack_signed_char (u=u@entry=-1 '\377', v=v@entry=-2 '\376') at
test2.c:13
13l = add_signed_char (l, r);
(gdb) p l
$1 = -1 '\377'
(gdb) p r
$2 = -2 '\376'
(gdb) set variable l = 4
(gdb) p l
$3 = 4 '\004'
(gdb) n
14return l + r;
(gdb) p l
$4 = -3 '\375'
...
Running -fvar-tracking at -O0 can improve debug info for local variables with
register storage class.
But it should not degrade debug info for local variables that have a stack
location assigned.
[Bug target/91481] POWER9 "DARN" RNG intrinsic produces repeated output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91481 --- Comment #13 from Segher Boessenkool --- Author: segher Date: Fri Aug 30 14:25:36 2019 New Revision: 275186 URL: https://gcc.gnu.org/viewcvs?rev=275186&root=gcc&view=rev Log: Backport from trunk 2019-08-23 Segher Boessenkool gcc/testsuite/ PR target/91481 * gcc.target/powerpc/darn-3.c: New testcase. Added: branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/darn-3.c Modified: branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug target/91481] POWER9 "DARN" RNG intrinsic produces repeated output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91481 --- Comment #12 from Segher Boessenkool --- Author: segher Date: Fri Aug 30 14:23:55 2019 New Revision: 275185 URL: https://gcc.gnu.org/viewcvs?rev=275185&root=gcc&view=rev Log: Backport from trunk 2019-08-22 Segher Boessenkool PR target/91481 * config/rs6000/rs6000.md (unspec): Delete UNSPEC_DARN, UNSPEC_DARN_32, and UNSPEC_DARN_RAW. (unspecv): New enumerator values UNSPECV_DARN, UNSPECV_DARN_32, and UNSPECV_DARN_RAW. (darn_32): Use an unspec_volatile, and UNSPECV_DARN_32. (darn_raw): Use an unspec_volatile, and UNSPECV_DARN_RAW. (darn): Use an unspec_volatile, and UNSPECV_DARN. Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/config/rs6000/rs6000.md
[Bug libstdc++/85965] [8/9/10 Regression] G++ gives cryptic error instead of incomplete type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85965 Jonathan Wakely changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #19 from Jonathan Wakely --- Fixed for 8.4
[Bug target/91481] POWER9 "DARN" RNG intrinsic produces repeated output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91481 --- Comment #11 from Segher Boessenkool --- Author: segher Date: Fri Aug 30 14:17:20 2019 New Revision: 275182 URL: https://gcc.gnu.org/viewcvs?rev=275182&root=gcc&view=rev Log: Backport from trunk 2019-08-23 Segher Boessenkool gcc/testsuite/ PR target/91481 * gcc.target/powerpc/darn-3.c: New testcase. Added: branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/darn-3.c Modified: branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug libstdc++/78179] FAIL: 26_numerics/headers/cmath/hypot.cc execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78179 Jonathan Wakely changed: What|Removed |Added Target Milestone|9.0 |8.4
[Bug libstdc++/78179] FAIL: 26_numerics/headers/cmath/hypot.cc execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78179 --- Comment #6 from Jonathan Wakely --- Author: redi Date: Fri Aug 30 14:17:41 2019 New Revision: 275183 URL: https://gcc.gnu.org/viewcvs?rev=275183&root=gcc&view=rev Log: PR libstdc++/78179 fix std::hypot failures due to excessive tolerance Backport from mainline 2018-09-21 Jonathan Wakely PR libstdc++/78179 * testsuite/26_numerics/headers/cmath/hypot.cc: Use lower tolerance when sizeof(long double) == sizeof(double). Modified: branches/gcc-8-branch/libstdc++-v3/ChangeLog branches/gcc-8-branch/libstdc++-v3/testsuite/26_numerics/headers/cmath/hypot.cc
[Bug libstdc++/89164] can construct vector with non-copyable-but-trivially-copyable elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89164 --- Comment #7 from Jonathan Wakely --- Fixed on trunk now.
[Bug target/91481] POWER9 "DARN" RNG intrinsic produces repeated output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91481 --- Comment #10 from Segher Boessenkool --- Author: segher Date: Fri Aug 30 14:15:39 2019 New Revision: 275181 URL: https://gcc.gnu.org/viewcvs?rev=275181&root=gcc&view=rev Log: Backport from trunk 2019-08-22 Segher Boessenkool PR target/91481 * config/rs6000/rs6000.md (unspec): Delete UNSPEC_DARN, UNSPEC_DARN_32, and UNSPEC_DARN_RAW. (unspecv): New enumerator values UNSPECV_DARN, UNSPECV_DARN_32, and UNSPECV_DARN_RAW. (darn_32): Use an unspec_volatile, and UNSPECV_DARN_32. (darn_raw): Use an unspec_volatile, and UNSPECV_DARN_RAW. (darn): Use an unspec_volatile, and UNSPECV_DARN. Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/config/rs6000/rs6000.md
[Bug c++/91609] New: friend declaration not honoured
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91609
Bug ID: 91609
Summary: friend declaration not honoured
Product: gcc
Version: 9.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jobstz at posteo dot de
Target Milestone: ---
Created attachment 46791
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46791&action=edit
minimal example
gcc does not honour the friend declaration and produces the error message:
test.cpp:16:9: error: ‘result’ does not name a type
16 | friend result;
| ^~
test.cpp: In instantiation of ‘class complicated’:
test.cpp:21:36: required from here
test.cpp:9:7: error: ‘using type = int’ is private within this context
9 | class complicated : underlying_thing::type>
{};
| ^~~
test.cpp:13:8: note: declared private here
13 | using type = T;
|^~~
clang happily accepts the code.
Possibly related: #82613
Metabug: #59002
[Bug c++/88075] [feature-request] allow "concept" instead of "concept bool" with -fconcepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88075 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |9.0
[Bug c++/88075] [feature-request] allow "concept" instead of "concept bool" with -fconcepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88075 --- Comment #4 from Jonathan Wakely --- GCC 7 doesn't support the -std=c++2a option, so it doesn't seem necessary to backport it to GCC 7.
[Bug libstdc++/89164] can construct vector with non-copyable-but-trivially-copyable elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89164 --- Comment #6 from Jonathan Wakely --- Author: redi Date: Fri Aug 30 13:54:49 2019 New Revision: 275177 URL: https://gcc.gnu.org/viewcvs?rev=275177&root=gcc&view=rev Log: PR libstdc++/89164 enforce constraints for uninitialized algos The memmove optimizations for std::uninitialized_copy/fill/_n will compile even if the type is not copy constructible, because std::copy doesn't require copy construction to work. But the uninitialized algorithms do require it. This adds explicit static assertions to ensure we don't allow ill-formed initializations. PR libstdc++/89164 * include/bits/stl_algobase.h (__copy_move): Give descriptive names to template parameters. * include/bits/stl_uninitialized.h (uninitialized_copy) (uninitialized_fill, uninitialized_fill_n): Add static assertions to diagnose invalid uses. * testsuite/20_util/specialized_algorithms/uninitialized_copy/1.cc: Adjust expected error. * testsuite/20_util/specialized_algorithms/uninitialized_copy/89164.cc: New test. * testsuite/20_util/specialized_algorithms/uninitialized_copy_n/ 89164.cc: New test. * testsuite/20_util/specialized_algorithms/uninitialized_fill/89164.cc: New test. * testsuite/20_util/specialized_algorithms/uninitialized_fill_n/ 89164.cc: New test. * testsuite/23_containers/vector/cons/89164.cc: New test. * testsuite/23_containers/vector/cons/89164_c++17.cc: New test. Added: trunk/libstdc++-v3/testsuite/20_util/specialized_algorithms/uninitialized_copy/89164.cc - copied, changed from r275063, trunk/libstdc++-v3/testsuite/20_util/specialized_algorithms/uninitialized_copy/1.cc trunk/libstdc++-v3/testsuite/20_util/specialized_algorithms/uninitialized_copy_n/89164.cc - copied, changed from r275063, trunk/libstdc++-v3/testsuite/20_util/specialized_algorithms/uninitialized_copy/1.cc trunk/libstdc++-v3/testsuite/20_util/specialized_algorithms/uninitialized_fill/89164.cc - copied, changed from r275063, trunk/libstdc++-v3/testsuite/20_util/specialized_algorithms/uninitialized_copy/1.cc trunk/libstdc++-v3/testsuite/20_util/specialized_algorithms/uninitialized_fill_n/89164.cc - copied, changed from r275063, trunk/libstdc++-v3/testsuite/20_util/specialized_algorithms/uninitialized_copy/1.cc trunk/libstdc++-v3/testsuite/23_containers/vector/cons/89164.cc - copied, changed from r275063, trunk/libstdc++-v3/testsuite/20_util/specialized_algorithms/uninitialized_copy/1.cc trunk/libstdc++-v3/testsuite/23_containers/vector/cons/89164_c++17.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/stl_algobase.h trunk/libstdc++-v3/include/bits/stl_uninitialized.h trunk/libstdc++-v3/testsuite/20_util/specialized_algorithms/uninitialized_copy/1.cc
[Bug target/91481] POWER9 "DARN" RNG intrinsic produces repeated output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91481 --- Comment #9 from Segher Boessenkool --- Author: segher Date: Fri Aug 30 13:53:11 2019 New Revision: 275176 URL: https://gcc.gnu.org/viewcvs?rev=275176&root=gcc&view=rev Log: Backport from trunk 2019-08-23 Segher Boessenkool gcc/testsuite/ PR target/91481 * gcc.target/powerpc/darn-3.c: New testcase. Added: branches/gcc-9-branch/gcc/testsuite/gcc.target/powerpc/darn-3.c Modified: branches/gcc-9-branch/gcc/testsuite/ChangeLog
[Bug debug/90197] [8 Regression] Cannot step through simple loop at -O -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90197 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #15 from Jakub Jelinek --- Fixed.
[Bug debug/90733] [8 Regression] ICE in simplify_subreg, at simplify-rtx.c:6440
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90733 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Jakub Jelinek --- Fixed.
[Bug debug/90231] ivopts causes iterator in the loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90231 Bug 90231 depends on bug 90197, which changed state. Bug 90197 Summary: [8 Regression] Cannot step through simple loop at -O -g https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90197 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug target/91481] POWER9 "DARN" RNG intrinsic produces repeated output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91481 --- Comment #8 from Segher Boessenkool --- Author: segher Date: Fri Aug 30 13:51:26 2019 New Revision: 275175 URL: https://gcc.gnu.org/viewcvs?rev=275175&root=gcc&view=rev Log: Backport from trunk 2019-08-22 Segher Boessenkool PR target/91481 * config/rs6000/rs6000.md (unspec): Delete UNSPEC_DARN, UNSPEC_DARN_32, and UNSPEC_DARN_RAW. (unspecv): New enumerator values UNSPECV_DARN, UNSPECV_DARN_32, and UNSPECV_DARN_RAW. (darn_32): Use an unspec_volatile, and UNSPECV_DARN_32. (darn_raw): Use an unspec_volatile, and UNSPECV_DARN_RAW. (darn): Use an unspec_volatile, and UNSPECV_DARN. Modified: branches/gcc-9-branch/gcc/ChangeLog branches/gcc-9-branch/gcc/config/rs6000/rs6000.md
[Bug libstdc++/90770] Building with --enable-libstdcxx-debug and make profiledbootstrap fails with mv: cannot stat 'Makefile': No such file or directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90770 --- Comment #8 from Jonathan Wakely --- Author: redi Date: Fri Aug 30 13:50:01 2019 New Revision: 275172 URL: https://gcc.gnu.org/viewcvs?rev=275172&root=gcc&view=rev Log: PR libstdc++/90770 fix missing src/debug/Makefile Backport from mainline 2019-06-07 Jonathan Wakely PR libstdc++/90770 * src/Makefile.am (stamp-debug): Also test for missing makefile. * src/Makefile.in: Regenerate. Modified: branches/gcc-8-branch/libstdc++-v3/ChangeLog branches/gcc-8-branch/libstdc++-v3/src/Makefile.am branches/gcc-8-branch/libstdc++-v3/src/Makefile.in
[Bug c/89520] [7 Regression] ICE tree check: accessed operand 4 of call_expr with 3 operands in convert_to_integer_1, at convert.c:668
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89520 Jakub Jelinek changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #12 from Jakub Jelinek --- .
[Bug c++/59994] [meta-bug] thread_local
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59994 Bug 59994 depends on bug 60702, which changed state. Bug 60702 Summary: thread_local initialization https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60702 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug middle-end/78884] [7/8] ICE when gimplifying VLA in OpenMP SIMD region
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78884 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |7.5 --- Comment #14 from Jakub Jelinek --- Fixed.
