[Bug tree-optimization/79291] r244897 introduces IV related performance issues for daxpy on MIPS by enabling peeling for alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79291 --- Comment #5 from Doug Gilmore --- > Bin: I suspect this is also now broken on ARM, can > you check? Oops, sorry I forgot that this problem is not exposed on the original ARM/Neon for DP. Sorry for the noise.
[Bug tree-optimization/79291] r244897 introduces IV related performance issues for daxpy on MIPS by enabling peeling for alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79291 --- Comment #4 from Doug Gilmore --- > It also looks like mips lacks implementation of any of the > vectorizer cost hooks and thus defaults to > default_builtin_vectorization_cost which means that unaligned > loads/stores have double cost. I have investigated that in the past and that costing is needed in some cases. I'll start looking into that again.
[Bug target/78176] [MIPS] miscompiles ldxc1 with large pointers on 32-bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78176 --- Comment #20 from Doug Gilmore --- I'll collect more tracing data on the costing problem. Hopefully I post an update in the next few days.
[Bug middle-end/32003] Undocumented -fdump-tree options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32003 Martin Sebor changed: What|Removed |Added Keywords||patch Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org --- Comment #7 from Martin Sebor --- Patch posted for review: https://gcc.gnu.org/ml/gcc-patches/2017-02/msg00104.html
[Bug c++/79326] mistakenly rejects valid GNU C++ (typeof) code on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79326 Andrew Pinski changed: What|Removed |Added Summary|mistakenly rejects valid|mistakenly rejects valid |C++ code on |GNU C++ (typeof) code on |x86_64-linux-gnu|x86_64-linux-gnu --- Comment #1 from Andrew Pinski --- This is a GNU C++ extension. IIRC a bug like this was closed as won't fix as decltype works.
[Bug fortran/79312] Empty array in assignment not correctly type-checked
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79312 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #3 from kargl at gcc dot gnu.org --- (In reply to john.harper from comment #0) > This program violates f2008 syntax rule 7.2.1.2(4) but gfortran 6.1.1 on an > x86-64 system compiles and runs it, printing 0 > >program emptyarray5 > implicit none > real a(0) > a = [logical::] > print *,size(a) > end program emptyarray5 > > ! f2008 7.2.1.2 (4) if the variable is polymorphic it shall be type > ! compatible with expr ; otherwise the declared types of the variable and > ! expr shall conform as specified in Table 7.8, > ! > ! Table 7.8: Type conformance for the intrinsic assignment statement > ! > ! Type of the variable | Type of expr > !---+ > ! integer| integer, real, complex | > ! real | integer, real, complex | > ! complex| integer, real, complex | > ! character | character | > ! logical| logical | > ! derived type| same derived type as the variable | > !---+ Index: resolve.c === --- resolve.c (revision 245068) +++ resolve.c (working copy) @@ -9911,6 +9911,13 @@ resolve_ordinary_assign (gfc_code *code, lhs = code->expr1; rhs = code->expr2; + if (rhs->ts.type == BT_LOGICAL && lhs->ts.type != BT_LOGICAL) +{ + gfc_error ("LOGICAL expression at %L assigned to a non-LOGICAL entity", +&rhs->where); + return false; +} + if (rhs->is_boz && !gfc_notify_std (GFC_STD_GNU, "BOZ literal at %L outside " "a DATA statement and outside INT/REAL/DBLE/CMPLX",
[Bug c++/79329] bogus operator delete access check during instantiation of new-expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79329 Jonathan Wakely changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2017-02-02 Ever confirmed|0 |1
[Bug target/66144] vector element operator produces very bad code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66144 Michael Meissner changed: What|Removed |Added Status|NEW |ASSIGNED CC||meissner at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |meissner at gcc dot gnu.org
[Bug target/78604] [7 regression] test case gcc.target/powerpc/p8vector-vectorize-1.c fails starting with r242750
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78604 Michael Meissner changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|pthaugen at gcc dot gnu.org|meissner at gcc dot gnu.org
[Bug rtl-optimization/79286] [7 Regression] ira and lra wrong code at -O2 and -Os on i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79286 Alan Modra changed: What|Removed |Added CC||amodra at gmail dot com Summary|[7 Regression] wrong code |[7 Regression] ira and lra |at -O3 on x86_64-linux-gnu |wrong code at -O2 and -Os |in 32-bit mode (but not in |on i686-linux |64-bit mode)| --- Comment #6 from Alan Modra --- The testcase in comment #2 fails with x86 -m32 -Os even after fixing the ira failure, due to lra doing "Changing pseudo 89 in operand 1 of insn 9 on equiv [const(`d'+0x13c0)]" This puts the load of d[300...0][0] before the printf, just like the ira bug. The -Os failure is a regression from gcc-3.4
[Bug tree-optimization/79327] [7 Regression] wrong code at -O2 and -fprintf-return-value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79327 Martin Sebor changed: What|Removed |Added Keywords||patch --- Comment #4 from Martin Sebor --- Patch posted for review: https://gcc.gnu.org/ml/gcc-patches/2017-02/msg00101.html
[Bug target/79158] gcc.target/powerpc/pr70669.c fails on powerpc BE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79158 --- Comment #2 from Michael Meissner --- On Mon, Jan 30, 2017 at 09:17:26PM +, pthaugen at gcc dot gnu.org wrote: > Mike, Does this reasoning sound correct to you? If so I'll submit a patch. That looks fine. Thanks.
[Bug go/79281] gccgo: Binaries using goroutines crash on m68k
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79281 --- Comment #14 from Ian Lance Taylor --- > Could you maybe also backport the fix for PR/79037? [1] Done. > Btw, even with the fixes from this PR/79281 and PR/79037, the "go" command is > still crashing on m68k with gcc-6. It might be possible that this is the > reason the build of gcc-7 fails for this reason, doesn't it? It could be related, but building GCC does not actually run the go command.
[Bug go/79037] gccgo: Binaries crash with parforsetup: pos is not aligned on m68k
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79037 --- Comment #14 from ian at gcc dot gnu.org --- Author: ian Date: Wed Feb 1 23:35:59 2017 New Revision: 245110 URL: https://gcc.gnu.org/viewcvs?rev=245110&root=gcc&view=rev Log: PR go/79037 Backport from mainline: compiler, runtime: align gc data for m68k The current GC requires that the gc data be aligned to at least a 4 byte boundary, because it uses the lower two bits of the address for flags (see LOOP and PRECISE in runtime/mgc0.c). As the gc data is stored as a [...]uintptr, that is normally always true. However, on m68k, that only guarantees 2 byte alignment. Fix it by forcing the alignment. The parfor code used by the current GC requires that the parfor data be aligned to at least an 8 byte boundary. The code in parfor.c verifies this. This is normally true, as the data uses uint64_t values, but, again, this must be enforced explicitly on m68k. Fixes GCC PR 79037. Change-Id: Ifdf422db7b37e88f490e54c2f6d249117d359dd6 Modified: branches/gcc-6-branch/gcc/go/gofrontend/types.cc branches/gcc-6-branch/libgo/runtime/go-unsafe-pointer.c branches/gcc-6-branch/libgo/runtime/parfor.c branches/gcc-6-branch/libgo/runtime/runtime.h
[Bug go/79281] gccgo: Binaries using goroutines crash on m68k
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79281 --- Comment #13 from John Paul Adrian Glaubitz --- (In reply to Ian Lance Taylor from comment #11) > GCC 7 will require a different fix, as the code has moved from C to Go. I'm > not sure what the best approach is. Btw, even with the fixes from this PR/79281 and PR/79037, the "go" command is still crashing on m68k with gcc-6. It might be possible that this is the reason the build of gcc-7 fails for this reason, doesn't it? The crash in "go" on gcc-6 seems to be related to Go's Mutex type as this code [1] crashes as well. I will file a separate bug report for that. > [1] https://tour.golang.org/concurrency/9
[Bug go/79281] gccgo: Binaries using goroutines crash on m68k
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79281 --- Comment #12 from John Paul Adrian Glaubitz --- (In reply to Ian Lance Taylor from comment #11) > Thanks. I committed the patch to the GCC 6 branch. > > GCC 7 will require a different fix, as the code has moved from C to Go. I'm > not sure what the best approach is. Ok, thanks. We can look into this later. Could you maybe also backport the fix for PR/79037? [1] > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79037
[Bug target/79197] [5/6/7 Regression] ICE in extract_insn in gcc/recog.c:2311
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79197 --- Comment #10 from Orion Poplawski --- With gcc-7.0.1-0.4.fc26, we no longer get ICEs, but hdf5, openblas fail their tests on ppc64le, and python2/numpy appears to segfault in tests. So something does not appear to be right.
[Bug go/79281] gccgo: Binaries using goroutines crash on m68k
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79281 --- Comment #11 from Ian Lance Taylor --- Thanks. I committed the patch to the GCC 6 branch. GCC 7 will require a different fix, as the code has moved from C to Go. I'm not sure what the best approach is.
[Bug go/79281] gccgo: Binaries using goroutines crash on m68k
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79281 --- Comment #10 from ian at gcc dot gnu.org --- Author: ian Date: Wed Feb 1 22:58:43 2017 New Revision: 245109 URL: https://gcc.gnu.org/viewcvs?rev=245109&root=gcc&view=rev Log: PR go/79281 Force Lock and Note to be aligned to a 4 byte boundary. This is required by the kernel but is not enforced on m68k. Patch by John Paul Adrian Glaubitz. Modified: branches/gcc-6-branch/libgo/runtime/runtime.h
[Bug c++/79331] ICE on valid C++14 code (with initialized lambda capture) on x86_64-linux-gnu: in canonicalize_component_ref, at gimplify.c:2451
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79331 Martin Liška changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2017-02-01 CC||marxin at gcc dot gnu.org, ||nathan at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed, started to ICE with r244056.
[Bug c++/79325] ICE on valid GNU C++ code (typeof) on x86_64-linux-gnu: in arg_assoc_type, at cp/name-lookup.c:5823
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79325 Martin Liška changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2017-02-01 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Martin Liška --- (In reply to Andrew Pinski from comment #1) > Does it work if you use decltype instead of typeof? Replacing the first, the test-case can be successfully compiled.
[Bug translation/79332] New: Several bugs related to translation in gcc 7.1-b20170101
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79332 Bug ID: 79332 Summary: Several bugs related to translation in gcc 7.1-b20170101 Product: gcc Version: 7.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: translation Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- The following are all small issues, therefore I think it is easier to address them all at once. 1. Make sure that multiline string literals always end in a space. (PARAM_MAX_STORES_TO_MERGE, PARAM_MAX_SSA_NAME_QUERY_DEPTH) 2. Remove strictly redundant comments from params.def, i.e. those comments that exactly repeat the text in the string literal. (PARAM_MAX_STORES_TO_SINK) 2a. Remove nearly strictly redundant comments from params.def. (PARAM_MAX_SLSR_CANDIDATE_SCAN) 3. Remove all instances of dot dot quote (..") from params.def. 4. Explain what "asan" in "asan-globals" means. Should I translate it in capital letters? 5. To be useful, the explanation in invoke.texi must not merely repeat the parameter description from params.def. (PARAM_MAX_FSM_THREAD_LENGTH) By the way, thank you for providing invoke.texi, which provides good explanations to the very short descriptions in params.def. To make this even more useful, the explanations from invoke.texi should be included in the gcc.pot in order to provide the translators with more context. As it is now, I have to lookup each of the parameters from params.def in invoke.texi to see what it actually means. This definition should be provided as a translator comment.
[Bug target/70012] test case gcc.dg/vect/costmodel/ppc/costmodel-vect-33.c fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70012 Bill Schmidt changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Bill Schmidt --- Fixed for server targets. We will defer 64-bit Darwin until Iain returns from travels.
[Bug c++/79294] [7 Regression] ICE in convert_nontype_argument, at cp/pt.c:6812
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79294 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug target/70012] test case gcc.dg/vect/costmodel/ppc/costmodel-vect-33.c fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70012 --- Comment #7 from Bill Schmidt --- Author: wschmidt Date: Wed Feb 1 22:11:57 2017 New Revision: 245108 URL: https://gcc.gnu.org/viewcvs?rev=245108&root=gcc&view=rev Log: 2017-02-01 Bill Schmidt PR target/70012 * gcc.dg/vect/costmodel/ppc/costmodel-vect-33.c: Adjust test conditions. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-33.c
[Bug libstdc++/79193] libstdc++ configure incorrectly decides linking works for cross-compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79193 --- Comment #3 from sandra at gcc dot gnu.org --- Created attachment 40649 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40649&action=edit patch to use "hello, world" to test linking The attached patch is sufficient to cause a link failure in cases where a linker script or additional library options are required to support stdio.h features. This might not be fully general since other C99 feature checks assume that math.h, complex.h, stdlib.h, and wchar.h features don't require any special linker recipe either.
[Bug c++/79331] New: ICE on valid C++14 code (with initialized lambda capture) on x86_64-linux-gnu: in canonicalize_component_ref, at gimplify.c:2451
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79331 Bug ID: 79331 Summary: ICE on valid C++14 code (with initialized lambda capture) on x86_64-linux-gnu: in canonicalize_component_ref, at gimplify.c:2451 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: su at cs dot ucdavis.edu Target Milestone: --- The ICE seems to be a recent regression, but the code is mistakenly rejected by earlier versions of GCC. $ g++-trunk -v Using built-in specs. COLLECT_GCC=g++-trunk COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto --prefix=/usr/local/gcc-trunk --disable-bootstrap Thread model: posix gcc version 7.0.1 20170201 (experimental) [trunk revision 245083] (GCC) $ $ icc -c -std=c++14 small.cpp $ clang++ -c -std=c++14 small.cpp $ $ g++-trunk -c -std=c++14 small.cpp small.cpp: In lambda function: small.cpp:9:14: error: field ‘bar()::’ invalidly declared function type return f (); ^ small.cpp: In lambda function: small.cpp:9:16: internal compiler error: in canonicalize_component_ref, at gimplify.c:2451 return f (); ~~^~ 0xb8ade3 canonicalize_component_ref ../../gcc-source-trunk/gcc/gimplify.c:2451 0xbaaa37 gimplify_compound_lval ../../gcc-source-trunk/gcc/gimplify.c:2877 0xba0761 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../gcc-source-trunk/gcc/gimplify.c:11155 0xba08b0 gimplify_addr_expr ../../gcc-source-trunk/gcc/gimplify.c:5860 0xba08b0 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../gcc-source-trunk/gcc/gimplify.c:11249 0xbac0a6 gimplify_call_expr ../../gcc-source-trunk/gcc/gimplify.c:3183 0xba1275 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../gcc-source-trunk/gcc/gimplify.c:11174 0xbaf657 gimplify_modify_expr ../../gcc-source-trunk/gcc/gimplify.c:5457 0xba26ec gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../gcc-source-trunk/gcc/gimplify.c:11203 0xba52c6 gimplify_stmt(tree_node**, gimple**) ../../gcc-source-trunk/gcc/gimplify.c:6478 0xba1a3f gimplify_and_add(tree_node*, gimple**) ../../gcc-source-trunk/gcc/gimplify.c:435 0xba1a3f gimplify_return_expr ../../gcc-source-trunk/gcc/gimplify.c:1521 0xba1a3f gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../gcc-source-trunk/gcc/gimplify.c:11462 0xba52c6 gimplify_stmt(tree_node**, gimple**) ../../gcc-source-trunk/gcc/gimplify.c:6478 0xba132b gimplify_cleanup_point_expr ../../gcc-source-trunk/gcc/gimplify.c:6230 0xba132b gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../gcc-source-trunk/gcc/gimplify.c:11578 0xba52c6 gimplify_stmt(tree_node**, gimple**) ../../gcc-source-trunk/gcc/gimplify.c:6478 0xba1a9b gimplify_statement_list ../../gcc-source-trunk/gcc/gimplify.c:1716 0xba1a9b gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../gcc-source-trunk/gcc/gimplify.c:11630 0xba52c6 gimplify_stmt(tree_node**, gimple**) ../../gcc-source-trunk/gcc/gimplify.c:6478 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <http://gcc.gnu.org/bugs.html> for instructions. $ int foo (); int bar () { return [&f (foo)] { return [=] { return f (); } (); } (); }
[Bug fortran/79312] Empty array in assignment not correctly type-checked
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79312 --- Comment #2 from harper at msor dot vuw.ac.nz --- Another manifestation of this bug: program emptyarray6 implicit none logical,allocatable:: OK(:) OK = [logical::]==[real::] print *,OK end program emptyarray6 compiles and prints nothing but I think it should have refused to compile (logical expression)==(real expression) On Wed, 1 Feb 2017, dominiq at lps dot ens.fr wrote: > Date: Wed, 1 Feb 2017 19:21:00 + > From: dominiq at lps dot ens.fr > To: John Harper > Subject: [Bug fortran/79312] Empty array in assignment not correctly > type-checked > Resent-Date: Thu, 2 Feb 2017 08:21:23 +1300 (NZDT) > Resent-From: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79312 > > Dominique d'Humieres changed: > > What|Removed |Added > > Status|UNCONFIRMED |NEW > Last reconfirmed||2017-02-01 > Ever confirmed|0 |1 > > --- Comment #1 from Dominique d'Humieres --- > Confirmed from at least 4.8 up to trunk (7.0). Note that compiling > > program emptyarray5 >implicit none >real a(1) >a = .true. >print *,a > end program emptyarray5 > > gives > >a = .true. >1 > Error: Can't convert LOGICAL(4) to REAL(4) at (1) > > -- > You are receiving this mail because: > You reported the bug. > -- John Harper, School of Mathematics and Statistics Victoria University, PO Box 600, Wellington 6140, New Zealand e-mail john.har...@vuw.ac.nz phone (+64)(4)463 5276 fax (+64)(4)463 5045
[Bug ada/79309] incorrectly bounded calls to strncat in adaint.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79309 --- Comment #7 from Eric Botcazou --- Author: ebotcazou Date: Wed Feb 1 21:36:09 2017 New Revision: 245107 URL: https://gcc.gnu.org/viewcvs?rev=245107&root=gcc&view=rev Log: PR ada/79309 * adaint.c (__gnat_killprocesstree): Use strlen instead of sizeof. Modified: trunk/gcc/ada/adaint.c
[Bug c++/79308] ICE on specialization of nested template classes (in finish_member_declaration, at cp/semantics.c:2963)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79308 Martin Liška changed: What|Removed |Added Keywords|ice-on-invalid-code |ice-on-valid-code --- Comment #4 from Martin Liška --- (In reply to bjhend from comment #3) > (In reply to Martin Liška from comment #2) > > Confirmed, all releases I have ICE (4.5.0+). > > Hi Martin, > > thanks for confirmation. You also added the keyword ice-on-INvalid-code, but > I think the code is valid. > > The C++-11 standard, paragraph 14.7.3, clause 5 contains a similar example > (see nested template struct C) with a single element function. Additionally, > I cannot find anything in the text, saying that this code is invalid, but I > might be wrong in interpreting the standard. Sorry for such keyword, I'm not familiar with the standard. Let's switch that to valid and see what maintainers think about it.
[Bug fortran/79330] gfortran 5.4.0/6.3.0/7.0.0 misinterpret type of character literal bind(C,name=...)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79330 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-02-01 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed from 4.8 up to trunk (7.0).
[Bug ada/79309] incorrectly bounded calls to strncat in adaint.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79309 Eric Botcazou changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |7.0 --- Comment #6 from Eric Botcazou --- .
[Bug tree-optimization/79315] [7 Regression] ICE while building SPEC CPU 2006 FP with -Ofast -ftree-parallelize-loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79315 Andrew Pinski changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Andrew Pinski --- .
[Bug tree-optimization/79315] [7 Regression] ICE while building SPEC CPU 2006 FP with -Ofast -ftree-parallelize-loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79315 --- Comment #8 from Andrew Pinski --- Fixed and tested on aarch64-linux-gnu so closing.
[Bug ada/79309] incorrectly bounded calls to strncat in adaint.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79309 --- Comment #5 from Eric Botcazou --- Author: ebotcazou Date: Wed Feb 1 20:36:23 2017 New Revision: 245103 URL: https://gcc.gnu.org/viewcvs?rev=245103&root=gcc&view=rev Log: PR ada/79309 * adaint.c (__gnat_killprocesstree): Fix broken string handling. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/adaint.c
[Bug c++/79296] [7 Regression] ICE in mangle_decl, at cp/mangle.c:3845
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79296 --- Comment #2 from Nathan Sidwell --- Created attachment 40648 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40648&action=edit reduced testcase trying to mangle a lambda but asserting that it has linkage.
[Bug fortran/79330] New: gfortran 5.4.0/6.3.0/7.0.0 misinterpret type of character literal bind(C,name=...)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79330 Bug ID: 79330 Summary: gfortran 5.4.0/6.3.0/7.0.0 misinterpret type of character literal bind(C,name=...) Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: damian at sourceryinstitute dot org Target Milestone: --- This a gfortran issue appears in the interface body below, but doesn't disappears if the procedure is implemented without a separate interface body. Apparently, the compiler is not exposing variables from the host scope into the interface body. Dropping the "module" from "module subroutine" and explicitly importing the constant via "import :: PREFIX" produces the same error: $ cat caf_openmp.f90 module caf_openmp_interface implicit none character(len=*), parameter :: PREFIX="_gfortran_" interface module subroutine this_image() bind(C,name=PREFIX//"caf_this_image") implicit none end subroutine end interface end module $ gfortran -c caf_openmp.f90 caf_openmp.f90:5:47: module subroutine this_image() bind(C,name=PREFIX//"caf_this_image") 1 Error: Operands of string concatenation operator at (1) are REAL(4)/CHARACTER(1) caf_openmp.f90:6:19: implicit none 1 Error: Unexpected IMPLICIT NONE statement in INTERFACE block at (1) caf_openmp.f90:7:7: end subroutine 1 Error: Expecting END INTERFACE statement at (1) $ gfortran --version GNU Fortran (MacPorts gcc7 7-20170108_0) 7.0.0 20170108 (experimental) This was also tested with gfortran 5.4.0 and 6.3.0. It would be great if any fix could be backported to the 5 and 6 branches as well.
[Bug target/79295] [7 regression] gcc.target/powerpc/bcd-3.c fails starting with r244942
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79295 Michael Meissner changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-02-01 Ever confirmed|0 |1 --- Comment #3 from Michael Meissner --- The insn needs to have a "v" constraint, rather than "" which allows any register. In addition in the PowerPC backend, we tend to want at least gpc_reg_operand which can do extra checks, or altivec_register_operand which will only match Altivec registers. The insn should look like: (define_insn "bcd" [(set (match_operand:V1TI 0 "gpc_reg_operand" "=v") (unspec:V1TI [(match_operand:V1TI 1 "gpc_reg_operand" "v") (match_operand:V1TI 2 "gpc_reg_operand" "v") (match_operand:QI 3 "const_0_to_1_operand" "n")] UNSPEC_BCD_ADD_SUB)) (clobber (reg:CCFP CR6_REGNO))] "TARGET_P8_VECTOR" "bcd. %0,%1,%2,%3" [(set_attr "length" "4") (set_attr "type" "vecsimple")])
[Bug c++/79308] ICE on specialization of nested template classes (in finish_member_declaration, at cp/semantics.c:2963)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79308 --- Comment #3 from bjhend --- (In reply to Martin Liška from comment #2) > Confirmed, all releases I have ICE (4.5.0+). Hi Martin, thanks for confirmation. You also added the keyword ice-on-INvalid-code, but I think the code is valid. The C++-11 standard, paragraph 14.7.3, clause 5 contains a similar example (see nested template struct C) with a single element function. Additionally, I cannot find anything in the text, saying that this code is invalid, but I might be wrong in interpreting the standard.
[Bug c++/69959] [6 Regression] gcc-6 doesn't build gcc-5 anymore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69959 Roger Pack changed: What|Removed |Added CC||rogerpack2005 at gmail dot com --- Comment #5 from Roger Pack --- FWIW I believe I ran into this building 4.9.3 using gcc 6.2.0
[Bug fortran/79287] include files not searched for relative to the file containing the fortran include statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79287 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2017-02-01 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- My F2015 draft reads > 3.4 Including source text > ... > 8 The interpretation of char-literal-constant is processor dependent. > An example of a possible valid interpretation is that char-literal-constant > is the name of a file that contains the source text to be included. IMO that means that both behaviors are standard conforming. If this is correct, I suggest to close the PR as WONTFIX.
[Bug fortran/79312] Empty array in assignment not correctly type-checked
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79312 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-02-01 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed from at least 4.8 up to trunk (7.0). Note that compiling program emptyarray5 implicit none real a(1) a = .true. print *,a end program emptyarray5 gives a = .true. 1 Error: Can't convert LOGICAL(4) to REAL(4) at (1)
[Bug target/79295] [7 regression] gcc.target/powerpc/bcd-3.c fails starting with r244942
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79295 --- Comment #2 from Michael Meissner --- Yes, bcdadd requires all of its arguments to be altivec registers. However, the pattern below is wrong: (define_insn "bcd" [(set (match_operand:V1TI 0 "register_operand" "") (unspec:V1TI [(match_operand:V1TI 1 "register_operand" "") (match_operand:V1TI 2 "register_operand" "") (match_operand:QI 3 "const_0_to_1_operand" "")] UNSPEC_BCD_ADD_SUB)) (clobber (reg:CCFP CR6_REGNO))] "TARGET_P8_VECTOR" "bcd. %0,%1,%2,%3" [(set_attr "length" "4") (set_attr "type" "vecsimple")]) It should have "v" constraints for each of the registers, and "n" for the integer. It probably should use altivec_register_operand (or at least gpc_reg_operand) instead of register_operand as well.
[Bug c++/79329] New: bogus operator delete access check during instantiation of new-expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79329 Bug ID: 79329 Summary: bogus operator delete access check during instantiation of new-expression Product: gcc Version: 7.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: richard-gccbugzilla at metafoo dot co.uk Target Milestone: --- Testcase: struct A { A(); void *operator new(unsigned long, void*); private: void operator delete(void*, int); }; A *p = new (p) A; gives a bogus diagnostic: :7:16: error: 'static void A::operator delete(void*, int)' is private within this context A *p = new (p) A; ^ :5:8: note: declared private here void operator delete(void*, int); ^~~~ Adding a second irrelevant operator delete overload suppresses the diagnostic. (Perhaps the access check is being performed prior to filtering out non-matching operator delete functions in the case where the lookup result is not an overload set.)
[Bug tree-optimization/79327] [7 Regression] wrong code at -O2 and -fprintf-return-value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79327 Martin Sebor changed: What|Removed |Added Keywords||wrong-code Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org
[Bug c++/79113] [7 Regression] ICE inheriting a default constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79113 Nathan Sidwell changed: What|Removed |Added CC||nathan at gcc dot gnu.org --- Comment #2 from Nathan Sidwell --- Current trunk compiles without error
[Bug c++/79296] [7 Regression] ICE in mangle_decl, at cp/mangle.c:3845
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79296 Nathan Sidwell changed: What|Removed |Added Status|NEW |ASSIGNED CC||nathan at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |nathan at gcc dot gnu.org
[Bug c++/79077] [7 regression][new inheriting ctors] bad code for inherited ctor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79077 Nathan Sidwell changed: What|Removed |Added CC||nathan at gcc dot gnu.org --- Comment #3 from Nathan Sidwell --- I think this is the same as 78495, which was fixed on Jan 20. current trunk prints the expected output.
[Bug tree-optimization/69224] [5/6/7 Regression] -Warray-bounds false positive with -O3 and struct pointer parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69224 Aldy Hernandez changed: What|Removed |Added Last reconfirmed|2016-01-11 00:00:00 |2017-2-1 CC||aldyh at gcc dot gnu.org Known to work||4.7.4 Known to fail||4.8.1, 4.8.2, 4.8.3, 4.8.4, ||7.0 --- Comment #7 from Aldy Hernandez --- Using http://gcc.godbolt.org/, I see: 4.7.4 works 4.8.1 - 4.9.x has one warning 5.1 has three warnings 5.2 - 6.x has one warning Compiling a recent trunk r245057 has one warning as well.
[Bug tree-optimization/79327] [7 Regression] wrong code at -O2 and -fprintf-return-value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79327 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P1 --- Comment #3 from Jakub Jelinek --- This causes miscompilation of TeX.
[Bug tree-optimization/79327] [7 Regression] wrong code at -O2 and -fprintf-return-value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79327 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-02-01 CC||jakub at gcc dot gnu.org, ||msebor at gcc dot gnu.org Target Milestone|--- |7.0 Summary|wrong code at -O2 and |[7 Regression] wrong code |-fprintf-return-value |at -O2 and ||-fprintf-return-value Ever confirmed|0 |1 --- Comment #2 from Jakub Jelinek --- This is clearly a bug in what I've been asking to fix earlier: http://gcc.gnu.org/ml/gcc-patches/2016-12/msg00385.html In particular, the code isn't structured to differentiate between computation of the possible range of values the argument can have, then adjustment of that range based on a possible implicit conversion due to say signed to unsigned or vice versa conversion and finally from that range of values figure out what values yield minimum or maximum number of characters (which is not necessarily the range boundaries). Right now, the code mixes that up: 1) for arg which is SSA_NAME with VR_RANGE, argmin is set to minimum and argmax to maximum (well, argmin = build_int_cst (argtype, wi::fits_uhwi_p (min) ? min.to_uhwi () : min.to_shwi ()); argmax = build_int_cst (argtype, wi::fits_uhwi_p (max) ? max.to_uhwi () : max.to_shwi ()); is also questionable code, it can throw away various bits from those values, why doesn't it use wide_int_to_tree?); at this point argmin and argmax are the range boundaries 2) otherwise, it computes some values, based on sign/precision of the type etc.; these values are not range boundaries, but argmin stands for value with (hopefully) shortest string representation and argmax with longest string representation 3) then it swaps them if argmin is bigger than argmax 4) then adjust_range_for_overflow is applied 5) then it picks those argmin and argmax values and for unsigned type uses their representation lengths as minimum and maximum, for signed vice versa So, for this testcase what happens is that we have a VR_RANGE, where the first value is [-35791394, 35791394] and second value [0, 2147483647]. So, 1) applies, 2)/3)/4) are skipped and we figure out the range for the first argument is [9, 9] (when it actually is [3, 9]) and second one is [2, 10] (correct). So the result is [11, 19] when it should have been [5, 19]. Obviously 0 has shorter representation than both -35791394 and 35791394.
[Bug c++/79328] New: Wshadow and lambda captures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79328 Bug ID: 79328 Summary: Wshadow and lambda captures Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: nathan at gcc dot gnu.org Target Milestone: --- Created attachment 40647 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40647&action=edit example -Wshadow warnings have a confusing interaction with lambda captures. 1) The names of init lambda captures are not checked. 2) local names are checked regardless of whether there is a default capture to make an outer object accessible The original report also mentioned the following case: T x; [=, x = std::move(x)] {}; if T is a non-copyable type, the default = capture couldn't capture it. IMHO such nuance shouldn't affect whether or not this gives a warning (so it should warn). I think it clear that #1 should be checked, but I can see arguments for and against #2. I think of name hiding as (almost) a syntactic check, and whether an object can be captured is more of a semantic check.
[Bug middle-end/77484] [6/7 Regression] Static branch predictor causes ~6-8% regression of SPEC2000 GAP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77484 --- Comment #38 from Dominik Vogt --- Finally, the total between after the last and before the first patch. Overall, some tests gain some performance and others lose some. The total number of instructions has grown somewhat (especially tonto, calculix, dealII and wrf), but there's no obvious connection between an increased number of instructions and loss of performance. Is this what can be expected of the patches? All compiled with -O3 -funroll-loops -march=zEC12. r244260 vs. r243994 --- run-old.resultrun-new.result f410.bwaves 1.28s1.27s ( -0.78%, 0.79% ) f416.gamess 7.10s6.82s ( -3.94%, 4.11% ) f433.milc 5.53s5.53s ( 0.00%, 0.00% ) f434.zeusmp 2.19s2.18s ( -0.46%, 0.46% ) f435.gromacs1.34s1.33s ( -0.75%, 0.75% ) f436.cactusADM 24.72s 24.80s ( 0.32%, -0.32% ) f437.leslie3d 2.76s2.75s ( -0.36%, 0.36% ) f444.namd 12.13s 12.13s ( 0.00%, 0.00% ) f447.dealII 2.03s2.02s ( -0.49%, 0.50% ) f450.soplex 3.90s3.92s ( 0.51%, -0.51% ) f453.povray 2.88s2.86s ( -0.69%, 0.70% ) f454.calculix 17.32s 17.36s ( 0.23%, -0.23% ) f459.GemsFDTD 7.22s7.13s ( -1.25%, 1.26% ) f465.tonto 0.93s0.93s ( 0.00%, 0.00% ) f470.lbm2.65s2.66s ( 0.38%, -0.38% ) f481.wrf3.84s3.84s ( 0.00%, 0.00% ) f482.sphinx3 10.49s 10.56s ( 0.67%, -0.66% ) i400.perlbench 7.58s7.25s ( -4.35%, 4.55% ) i401.bzip2 3.98s3.96s ( -0.50%, 0.51% ) i403.gcc1.00s1.01s ( 1.00%, -0.99% ) i429.mcf1.49s1.49s ( 0.00%, 0.00% ) i445.gobmk 3.55s3.53s ( -0.56%, 0.57% ) i456.hmmer 1.56s1.55s ( -0.64%, 0.65% ) i458.sjeng 3.81s3.79s ( -0.52%, 0.53% ) i462.libquantum17.12s 17.11s ( -0.06%, 0.06% ) i464.h264ref3.14s3.17s ( 0.96%, -0.95% ) i471.omnetpp 11.39s 11.52s ( 1.14%, -1.13% ) i473.astar 7.22s7.26s ( 0.55%, -0.55% ) i483.xalancbmk 7.62s7.69s ( 0.92%, -0.91% ) -- f470.lbm 2984 insns identical i429.mcf 4165 insns -4 smaller i462.libquantum 11735 insns +0 changed i473.astar 12460 insns +32 BIGGER!, 2 funcs bigger (max +79 insns) f410.bwaves 9820 insns +7 BIGGER!, 1 funcs bigger (max +7 insns) i401.bzip2 22439 insns -63 smaller f437.leslie3d 28725 insns +9 BIGGER!, 5 funcs bigger (max +19 insns) i458.sjeng 38864 insns -26 smaller, 2 funcs bigger (max +24 insns) f433.milc 35091 insns -70 smaller, 1 funcs bigger (max +5 insns) f482.sphinx3 51879 insns +4 BIGGER!, 5 funcs bigger (max +15 insns) i456.hmmer 85157 insns -33 smaller, 4 funcs bigger (max +91 insns) f444.namd 76220 insns -3 smaller f434.zeusmp 73937 insns +43 BIGGER!, 3 funcs bigger (max +27 insns) f459.GemsFDTD 111465 insns +84 BIGGER!, 5 funcs bigger (max +57 insns) f436.cactusADM 201648 insns +125 BIGGER!, 37 funcs bigger (max +68 insns) f435.gromacs 250725 insns -53 smaller, 11 funcs bigger (max +25 insns) i471.omnetpp 135992 insns -435 smaller, 15 funcs bigger (max +80 insns) i445.gobmk 249112 insns -1167 smaller, 16 funcs bigger (max +82 insns) f450.soplex 131531 insns -558 smaller, 22 funcs bigger (max +18 insns) f453.povray 247399 insns -48 smaller, 3 funcs bigger (max +92 insns) i400.perlbench 305683 insns -216 smaller, 51 funcs bigger (max +554 insns) f454.calculix 478026 insns +485 BIGGER!, 22 funcs bigger (max +157 insns) i464.h264ref 316483 insns -76 smaller, 8 funcs bigger (max +76 insns) i403.gcc 800574 insns -782 smaller, 100 funcs bigger (max +1674 insns) f465.tonto 1138432 insns +2511 BIGGER!, 235 funcs bigger (max +455 insns) f447.dealII 764322 insns +597 BIGGER!, 171 funcs bigger (max +295 insns) f481.wrf 1081604 insns +2769 BIGGER!, 141 funcs bigger (max +2329 insns) i483.xalancbmk 919758 insns -483 smaller, 277 funcs bigger (max +1002 insns) f416.gamess 2553939 insns -1589 smaller, 127 funcs bigger (max +46 insns) statistics: --- 29 tests (total) 11 test executables have grown (more insns) 16 test executables have shrunk (fewer insns) 10140169insns total (old) +1060 insns difference +104insns per 1,000,000 -360weighted insns per 1,000,000 * 1264fu
[Bug sanitizer/78663] [7 Regression] Hundreds of asan failures on x86_64-apple-darwin10 at r243019
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78663 --- Comment #7 from Maxim Ostapenko --- Created attachment 40646 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40646&action=edit Fix 2 Iain, could you test the following patch? This one is likely to be applied upstream. As a side note, LLVM folks are not very happy with these patches (they lack of buildbots to test them). Thus I suspect that for future releases we'll need a) apply Darwin 10 patches locally or b) disable ASan for Darwin 10.
[Bug middle-end/77484] [6/7 Regression] Static branch predictor causes ~6-8% regression of SPEC2000 GAP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77484 --- Comment #37 from Dominik Vogt --- r244260 vs. r244256 (comment 25) --- run-old.resultrun-new.result f410.bwaves 1.27s1.27s ( 0.00%, 0.00% ) f416.gamess 6.80s6.82s ( 0.29%, -0.29% ) f433.milc 5.56s5.53s ( -0.54%, 0.54% ) f434.zeusmp 2.18s2.18s ( 0.00%, 0.00% ) f435.gromacs1.36s1.33s ( -2.21%, 2.26% ) f436.cactusADM 24.66s 24.75s ( 0.36%, -0.36% ) f437.leslie3d 2.76s2.75s ( -0.36%, 0.36% ) f444.namd 12.13s 12.13s ( 0.00%, 0.00% ) f447.dealII 2.05s2.01s ( -1.95%, 1.99% ) f450.soplex 3.97s3.92s ( -1.26%, 1.28% ) f453.povray 2.91s2.86s ( -1.72%, 1.75% ) f454.calculix 17.28s 17.36s ( 0.46%, -0.46% ) f459.GemsFDTD 7.28s7.14s ( -1.92%, 1.96% ) f465.tonto 0.94s0.94s ( 0.00%, 0.00% ) f470.lbm2.66s2.65s ( -0.38%, 0.38% ) f481.wrf3.84s3.84s ( 0.00%, 0.00% ) f482.sphinx3 10.59s 10.61s ( 0.19%, -0.19% ) i400.perlbench 7.49s7.30s ( -2.54%, 2.60% ) i401.bzip2 3.97s3.96s ( -0.25%, 0.25% ) i403.gcc1.01s1.01s ( 0.00%, 0.00% ) i429.mcf1.49s1.49s ( 0.00%, 0.00% ) i445.gobmk 3.61s3.53s ( -2.22%, 2.27% ) i456.hmmer 1.56s1.57s ( 0.64%, -0.64% ) i458.sjeng 3.77s3.79s ( 0.53%, -0.53% ) i462.libquantum17.13s 17.08s ( -0.29%, 0.29% ) i464.h264ref3.30s3.17s ( -3.94%, 4.10% ) i471.omnetpp 11.38s 11.52s ( 1.23%, -1.22% ) i473.astar 7.58s7.26s ( -4.22%, 4.41% ) i483.xalancbmk 7.53s7.73s ( 2.66%, -2.59% ) -- f470.lbm 2984 insns +0 changed i429.mcf 4506 insns -346 smaller, 1 funcs bigger (max +2 insns) i462.libquantum 11728 insns +7 BIGGER!, 5 funcs bigger (max +4 insns) i473.astar 12309 insns +182 BIGGER!, 8 funcs bigger (max +109 insns) i401.bzip2 22375 insns +11 BIGGER!, 20 funcs bigger (max +25 insns) f437.leslie3d 28715 insns +21 BIGGER!, 2 funcs bigger (max +18 insns) i458.sjeng 38693 insns +145 BIGGER!, 15 funcs bigger (max +69 insns) f433.milc 34740 insns +265 BIGGER!, 49 funcs bigger (max +72 insns) f482.sphinx3 52048 insns -148 smaller, 37 funcs bigger (max +195 insns) i456.hmmer 84420 insns +676 BIGGER!, 61 funcs bigger (max +518 insns) f444.namd 76218 insns +0 changed, 1 funcs bigger (max +11 insns) f434.zeusmp 73993 insns -7 smaller, 1 funcs bigger (max +1 insns) f459.GemsFDTD 111458 insns +85 BIGGER!, 9 funcs bigger (max +89 insns) f436.cactusADM 201167 insns +608 BIGGER!, 86 funcs bigger (max +264 insns) f435.gromacs 249275 insns +1416 BIGGER!, 104 funcs bigger (max +978 insns) i471.omnetpp 137902 insns -2351 smaller, 64 funcs bigger (max +410 insns) i445.gobmk 247898 insns +57 BIGGER!, 182 funcs bigger (max +782 insns) f450.soplex 127631 insns +3348 BIGGER!, 56 funcs bigger (max +2104 insns) f453.povray 245450 insns +1900 BIGGER!, 197 funcs bigger (max +2029 insns) i400.perlbench 304835 insns +632 BIGGER!, 365 funcs bigger (max +930 insns) f454.calculix 40 insns +714 BIGGER!, 182 funcs bigger (max +562 insns) i464.h264ref 316389 insns -34 smaller, 61 funcs bigger (max +1116 insns) i403.gcc 797389 insns +2408 BIGGER!, 503 funcs bigger (max +1371 insns) f465.tonto 1141420 insns -449 smaller, 329 funcs bigger (max +874 insns) f447.dealII 764299 insns +556 BIGGER!, 291 funcs bigger (max +1826 insns) f481.wrf 1084747 insns -388 smaller, 196 funcs bigger (max +1552 insns) i483.xalancbmk 919878 insns -411 smaller, 507 funcs bigger (max +1508 insns) f416.gamess 2561829 insns -9468 smaller, 714 funcs bigger (max +1562 insns) statistics: --- 29 tests (total) 17 test executables have grown (more insns) 9 test executables have shrunk (fewer insns) 10141892insns total (old) -571insns difference -56 insns per 1,000,000 -524weighted insns per 1,000,000 * 4046functions have grown (total) ** +2104 insns in most grown function
[Bug middle-end/77484] [6/7 Regression] Static branch predictor causes ~6-8% regression of SPEC2000 GAP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77484 --- Comment #36 from Dominik Vogt --- r244207 vs. r244206 (comment 24) --- run-old.resultrun-new.result f410.bwaves 1.27s1.27s ( 0.00%, 0.00% ) f416.gamess 6.87s7.21s ( 4.95%, -4.72% ) f433.milc 5.57s5.57s ( 0.00%, 0.00% ) f434.zeusmp 2.18s2.18s ( 0.00%, 0.00% ) f435.gromacs1.34s1.36s ( 1.49%, -1.47% ) f436.cactusADM 24.63s 24.56s ( -0.28%, 0.29% ) f437.leslie3d 2.76s2.76s ( 0.00%, 0.00% ) f444.namd 12.13s 12.13s ( 0.00%, 0.00% ) f447.dealII 2.03s2.02s ( -0.49%, 0.50% ) f450.soplex 3.98s3.98s ( 0.00%, 0.00% ) f453.povray 2.89s2.90s ( 0.35%, -0.34% ) f454.calculix 17.28s 17.30s ( 0.12%, -0.12% ) f459.GemsFDTD 7.29s7.29s ( 0.00%, 0.00% ) f465.tonto 0.94s0.94s ( 0.00%, 0.00% ) f470.lbm2.65s2.64s ( -0.38%, 0.38% ) f481.wrf3.84s3.84s ( 0.00%, 0.00% ) f482.sphinx3 10.61s 10.58s ( -0.28%, 0.28% ) i400.perlbench 7.32s7.46s ( 1.91%, -1.88% ) i401.bzip2 3.97s3.97s ( 0.00%, 0.00% ) i403.gcc1.00s1.01s ( 1.00%, -0.99% ) i429.mcf1.49s1.49s ( 0.00%, 0.00% ) i445.gobmk 3.59s3.61s ( 0.56%, -0.55% ) i456.hmmer 1.57s1.56s ( -0.64%, 0.64% ) i458.sjeng 3.76s3.77s ( 0.27%, -0.27% ) i462.libquantum17.11s 17.08s ( -0.18%, 0.18% ) i464.h264ref3.09s3.29s ( 6.47%, -6.08% ) i471.omnetpp 11.20s 11.16s ( -0.36%, 0.36% ) i473.astar 7.58s7.56s ( -0.26%, 0.26% ) i483.xalancbmk 7.43s7.49s ( 0.81%, -0.80% ) -- i401.bzip2 22375 insns +0 changed i458.sjeng 38701 insns -8 smaller f482.sphinx3 52038 insns +7 BIGGER!, 1 funcs bigger (max +7 insns) i456.hmmer 84421 insns +0 changed f436.cactusADM 201172 insns -6 smaller, 11 funcs bigger (max +5 insns) f435.gromacs 249282 insns -3 smaller, 1 funcs bigger (max +2 insns) i471.omnetpp 137988 insns -86 smaller, 3 funcs bigger (max +2 insns) i445.gobmk 247886 insns +11 BIGGER!, 6 funcs bigger (max +17 insns) f450.soplex 127628 insns +3 BIGGER!, 2 funcs bigger (max +2 insns) f453.povray 245457 insns -2 smaller, 3 funcs bigger (max +3 insns) i400.perlbench 304597 insns +249 BIGGER!, 17 funcs bigger (max +419 insns) f454.calculix 40 insns identical i464.h264ref 316393 insns -3 smaller, 4 funcs bigger (max +7 insns) i403.gcc 796623 insns +798 BIGGER!, 31 funcs bigger (max +977 insns) f465.tonto 1141420 insns +0 changed f447.dealII 764301 insns +1 BIGGER!, 11 funcs bigger (max +139 insns) f481.wrf 1084840 insns -11 smaller i483.xalancbmk 919877 insns +3 BIGGER!, 1 funcs bigger (max +12 insns) f416.gamess 2562020 insns +2 BIGGER!, 1 funcs bigger (max +2 insns) statistics: --- 29 tests (total) 8 test executables have grown (more insns) 7 test executables have shrunk (fewer insns) 10141266insns total (old) +955insns difference +94 insns per 1,000,000 +38 weighted insns per 1,000,000 * 92 functions have grown (total) ** +977insns in most grown function
[Bug middle-end/77484] [6/7 Regression] Static branch predictor causes ~6-8% regression of SPEC2000 GAP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77484 --- Comment #35 from Dominik Vogt --- r244167 vs. r244166 (comment 21) --- run-old.resultrun-new.result f410.bwaves 1.27s1.27s ( 0.00%, 0.00% ) f416.gamess 6.87s6.87s ( 0.00%, 0.00% ) f433.milc 5.57s5.57s ( 0.00%, 0.00% ) f434.zeusmp 2.18s2.19s ( 0.46%, -0.46% ) f435.gromacs1.34s1.34s ( 0.00%, 0.00% ) f436.cactusADM 24.71s 24.69s ( -0.08%, 0.08% ) f437.leslie3d 2.76s2.76s ( 0.00%, 0.00% ) f444.namd 12.13s 12.13s ( 0.00%, 0.00% ) f447.dealII 2.04s2.03s ( -0.49%, 0.49% ) f450.soplex 3.91s3.98s ( 1.79%, -1.76% ) f453.povray 2.90s2.89s ( -0.34%, 0.35% ) f454.calculix 17.29s 17.29s ( 0.00%, 0.00% ) f459.GemsFDTD 7.27s7.30s ( 0.41%, -0.41% ) f465.tonto 0.94s0.94s ( 0.00%, 0.00% ) f470.lbm2.65s2.66s ( 0.38%, -0.38% ) f481.wrf3.84s3.84s ( 0.00%, 0.00% ) f482.sphinx3 10.62s 10.62s ( 0.00%, 0.00% ) i400.perlbench 7.27s7.34s ( 0.96%, -0.95% ) i401.bzip2 3.97s3.97s ( 0.00%, 0.00% ) i403.gcc1.01s1.01s ( 0.00%, 0.00% ) i429.mcf1.49s1.49s ( 0.00%, 0.00% ) i445.gobmk 3.59s3.59s ( 0.00%, 0.00% ) i456.hmmer 1.57s1.59s ( 1.27%, -1.26% ) i458.sjeng 3.77s3.76s ( -0.27%, 0.27% ) i462.libquantum17.09s 17.14s ( 0.29%, -0.29% ) i464.h264ref3.09s3.09s ( 0.00%, 0.00% ) i471.omnetpp 11.16s 11.25s ( 0.81%, -0.80% ) i473.astar 7.56s7.58s ( 0.26%, -0.26% ) i483.xalancbmk 7.80s7.37s ( -5.51%, 5.83% ) -- i471.omnetpp 138049 insns -75 smaller, 26 funcs bigger (max +202 insns) f450.soplex 127589 insns +43 BIGGER!, 13 funcs bigger (max +108 insns) f453.povray 245456 insns +10 BIGGER!, 5 funcs bigger (max +5 insns) f447.dealII 764156 insns +150 BIGGER!, 35 funcs bigger (max +1800 insns) i483.xalancbmk 921932 insns -2045 smaller, 391 funcs bigger (max +1513 insns) command line: - # ak-scripts/compare.sh --suffix -244167-244166 -r 10 -o /home/vogt/src/gcc/install-244166 -n /home/vogt/src/gcc/install-244167 -c -O3 -march=zEC12 -funroll-loops output files: - executable diff: /home/vogt/src/minispec-2006/diff-31012017.result-244167-244166 functions grown: /home/vogt/src/minispec-2006/funcs-grown-31012017.result-244167-244166 build times: /home/vogt/src/minispec-2006/buildtime-31012017.result-244167-244166 statistics: --- 29 tests (total) 3 test executables have grown (more insns) 2 test executables have shrunk (fewer insns) 10143197insns total (old) -1917 insns difference -188insns per 1,000,000 -77 weighted insns per 1,000,000 * 470 functions have grown (total) ** +1800 insns in most grown function
[Bug middle-end/77484] [6/7 Regression] Static branch predictor causes ~6-8% regression of SPEC2000 GAP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77484 --- Comment #34 from Dominik Vogt --- Some Spec2006 results on s390x (zEC12) for the files: r243995 vs. r243994 (comment 14) --- run-old.resultrun-new.result f410.bwaves 1.27s1.28s ( 0.79%, -0.78% ) f416.gamess 7.09s6.61s ( -6.77%, 7.26% ) f433.milc 5.53s5.54s ( 0.18%, -0.18% ) f434.zeusmp 2.19s2.19s ( 0.00%, 0.00% ) f435.gromacs1.34s1.34s ( 0.00%, 0.00% ) f436.cactusADM 24.63s 24.67s ( 0.16%, -0.16% ) f437.leslie3d 2.76s2.75s ( -0.36%, 0.36% ) f444.namd 12.13s 12.13s ( 0.00%, 0.00% ) f447.dealII 2.03s2.02s ( -0.49%, 0.50% ) f450.soplex 3.92s3.96s ( 1.02%, -1.01% ) f453.povray 2.89s2.87s ( -0.69%, 0.70% ) f454.calculix 17.32s 17.23s ( -0.52%, 0.52% ) f459.GemsFDTD 7.24s7.19s ( -0.69%, 0.70% ) f465.tonto 0.94s0.94s ( 0.00%, 0.00% ) f470.lbm2.65s2.66s ( 0.38%, -0.38% ) f481.wrf3.84s3.85s ( 0.26%, -0.26% ) f482.sphinx3 10.50s 10.54s ( 0.38%, -0.38% ) i400.perlbench 7.58s7.37s ( -2.77%, 2.85% ) i401.bzip2 3.98s3.95s ( -0.75%, 0.76% ) i403.gcc1.01s1.00s ( -0.99%, 1.00% ) i429.mcf1.49s1.49s ( 0.00%, 0.00% ) i445.gobmk 3.56s3.62s ( 1.69%, -1.66% ) i456.hmmer 1.59s1.57s ( -1.26%, 1.27% ) i458.sjeng 3.81s3.84s ( 0.79%, -0.78% ) i462.libquantum17.13s 17.46s ( 1.93%, -1.89% ) i464.h264ref3.14s3.31s ( 5.41%, -5.14% ) i471.omnetpp 11.50s 11.51s ( 0.09%, -0.09% ) i473.astar 7.22s7.54s ( 4.43%, -4.24% ) i483.xalancbmk 7.51s8.15s ( 8.52%, -7.85% ) -- f470.lbm 2984 insns +0 changed i429.mcf 4165 insns +346 BIGGER!, 3 funcs bigger (max +339 insns) i462.libquantum 11735 insns -7 smaller, 4 funcs bigger (max +3 insns) i473.astar 12460 insns -181 smaller, 12 funcs bigger (max +9 insns) i401.bzip2 22439 insns -13 smaller, 6 funcs bigger (max +25 insns) f437.leslie3d 28725 insns -21 smaller i458.sjeng 38864 insns -144 smaller, 10 funcs bigger (max +26 insns) f433.milc 35091 insns -262 smaller, 7 funcs bigger (max +6 insns) f482.sphinx3 51879 insns +139 BIGGER!, 16 funcs bigger (max +326 insns) i456.hmmer 85157 insns -677 smaller, 26 funcs bigger (max +463 insns) f444.namd 76220 insns +0 changed, 1 funcs bigger (max +11 insns) f434.zeusmp 73937 insns +6 BIGGER!, 1 funcs bigger (max +7 insns) f459.GemsFDTD 111465 insns -151 smaller, 3 funcs bigger (max +21 insns) f436.cactusADM 201648 insns -638 smaller, 69 funcs bigger (max +103 insns) f435.gromacs 250725 insns -1425 smaller, 64 funcs bigger (max +316 insns) i471.omnetpp 135992 insns +2095 BIGGER!, 70 funcs bigger (max +2101 insns) i445.gobmk 249112 insns -726 smaller, 188 funcs bigger (max +1282 insns) f450.soplex 131531 insns -3584 smaller, 33 funcs bigger (max +546 insns) f453.povray 247399 insns -1827 smaller, 118 funcs bigger (max +1481 insns) i400.perlbench 305683 insns -886 smaller, 207 funcs bigger (max +480 insns) f454.calculix 478026 insns -837 smaller, 97 funcs bigger (max +1036 insns) i464.h264ref 316483 insns +35 BIGGER!, 44 funcs bigger (max +2229 insns) i403.gcc 800574 insns -4048 smaller, 514 funcs bigger (max +1614 insns) f465.tonto 1138432 insns -970 smaller, 139 funcs bigger (max +653 insns) f447.dealII 764322 insns -873 smaller, 248 funcs bigger (max +2980 insns) f481.wrf 1081604 insns +32 BIGGER!, 126 funcs bigger (max +404 insns) i483.xalancbmk 919758 insns +1914 BIGGER!, 731 funcs bigger (max +1835 insns) f416.gamess 2553939 insns +9369 BIGGER!, 328 funcs bigger (max +9157 insns) statistics: --- 29 tests (total) 8 test executables have grown (more insns) 18 test executables have shrunk (fewer insns) 10140169insns total (old) -3334 insns difference -328insns per 1,000,000 +435weighted insns per 1,000,000 * 3065functions have grown (total) ** +9157 insns in most grown function * Each test case is scaled to 100 insns. The displayed number is the average of all tests.
[Bug tree-optimization/79327] wrong code at -O2 and -fprintf-return-value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79327 --- Comment #1 from Marek Polacek --- -fdump-tree-printf-return-value2-alias shows # RANGE [11, 19] NONZERO 31 range for 'e' which is wrong, it should be [5, 19].
[Bug c++/77620] Generic compile time regression of 7.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77620 --- Comment #8 from Jonathan Wakely --- We get reports like this every few months, and nobody ever uses -ftime-report before filing a bug. I think something in the -v output would be useful.
[Bug tree-optimization/79327] New: wrong code at -O2 and -ftree-printf-return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79327 Bug ID: 79327 Summary: wrong code at -O2 and -ftree-printf-return Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: mpolacek at gcc dot gnu.org Target Milestone: --- The following aborts with -O2: volatile int a, b = -1; char buf[64]; int main () { int c = a; int d = b; if (c >= -35791395 && c < 35791394 && d >= -1 && d < __INT_MAX__) { int e = __builtin_sprintf (buf, "%+03d%02d", c + 1, d + 1); if (e > 7) __builtin_abort (); } return 0; } -fno-printf-return-value helps.
[Bug libstdc++/60936] [5/6/7 Regression] Binary code bloat with std::string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60936 --- Comment #25 from Jonathan Wakely --- I have, and it doesn't make much difference: 175800 gcc48.so 608280 gcc49.so 1159624 gcc5-cow.so 1176296 gcc6-cow-gc.so 1176296 gcc6-cow.so 1180400 gcc6-gc.so 1180400 gcc6.so 258376 gcc7-cow-patched.so 1188568 gcc7-cow-trunk.so 258384 gcc7-patched.so 1188552 gcc7-trunk.so -cow means using -D_GLIBCXX_CXX11_ABI=0 -gc means using -Wl,--gc-sections -patched means I've split the explicit instantiations into separate files and changed __snprintf_lite to not use __int_to_char from locale-inst.o The patch makes a big difference.
[Bug c++/79326] New: mistakenly rejects valid C++ code on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79326 Bug ID: 79326 Summary: mistakenly rejects valid C++ code on x86_64-linux-gnu Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: su at cs dot ucdavis.edu Target Milestone: --- It seems to affect at least all versions 4.6.x and later. $ g++-trunk -v Using built-in specs. COLLECT_GCC=g++-trunk COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto --prefix=/usr/local/gcc-trunk --disable-bootstrap Thread model: posix gcc version 7.0.1 20170201 (experimental) [trunk revision 245083] (GCC) $ $ clang++ -c small.cpp $ icc -c small.cpp $ $ g++-trunk -c small.cpp small.cpp:2:24: error: type of ‘foo’ is unknown __typeof__ (foo < int >) bar; ^ $ template < typename T > T foo (T); __typeof__ (foo < int >) bar;
[Bug c++/79325] ICE on valid GNU C++ code (typeof) on x86_64-linux-gnu: in arg_assoc_type, at cp/name-lookup.c:5823
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79325 Andrew Pinski changed: What|Removed |Added Summary|ICE on valid C++ code on|ICE on valid GNU C++ code |x86_64-linux-gnu: in|(typeof) on |arg_assoc_type, at |x86_64-linux-gnu: in |cp/name-lookup.c:5823 |arg_assoc_type, at ||cp/name-lookup.c:5823 --- Comment #1 from Andrew Pinski --- Does it work if you use decltype instead of typeof?
[Bug c++/79325] New: ICE on valid C++ code on x86_64-linux-gnu: in arg_assoc_type, at cp/name-lookup.c:5823
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79325 Bug ID: 79325 Summary: ICE on valid C++ code on x86_64-linux-gnu: in arg_assoc_type, at cp/name-lookup.c:5823 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: su at cs dot ucdavis.edu Target Milestone: --- It seems to affect 4.8.x and later, but not 4.7.x. It might be related to PR 71820. $ g++-trunk -v Using built-in specs. COLLECT_GCC=g++-trunk COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto --prefix=/usr/local/gcc-trunk --disable-bootstrap Thread model: posix gcc version 7.0.1 20170201 (experimental) [trunk revision 245079] (GCC) $ $ g++-4.7 -c small.cpp $ clang++ -c small.cpp $ $ g++-trunk -c small.cpp small.cpp:3:27: internal compiler error: in arg_assoc_type, at cp/name-lookup.c:5823 __typeof__ (f (foo < int >)) bar; ^ 0x89be72 arg_assoc_type ../../gcc-source-trunk/gcc/cp/name-lookup.c:5823 0x89be06 arg_assoc_args ../../gcc-source-trunk/gcc/cp/name-lookup.c:5834 0x89be06 arg_assoc_type ../../gcc-source-trunk/gcc/cp/name-lookup.c:5806 0x89b66d arg_assoc ../../gcc-source-trunk/gcc/cp/name-lookup.c:5905 0x89b838 arg_assoc ../../gcc-source-trunk/gcc/cp/name-lookup.c:5893 0x89e931 arg_assoc_args_vec ../../gcc-source-trunk/gcc/cp/name-lookup.c:5849 0x89e931 lookup_arg_dependent_1 ../../gcc-source-trunk/gcc/cp/name-lookup.c:5954 0x89e931 lookup_arg_dependent(tree_node*, tree_node*, vec*) ../../gcc-source-trunk/gcc/cp/name-lookup.c:5982 0x838e24 perform_koenig_lookup(cp_expr, vec*, int) ../../gcc-source-trunk/gcc/cp/semantics.c:2252 0x7b3e95 cp_parser_postfix_expression ../../gcc-source-trunk/gcc/cp/parser.c:6916 0x7ae4bc cp_parser_unary_expression ../../gcc-source-trunk/gcc/cp/parser.c:8098 0x7bb717 cp_parser_cast_expression ../../gcc-source-trunk/gcc/cp/parser.c:8775 0x7bbd25 cp_parser_binary_expression ../../gcc-source-trunk/gcc/cp/parser.c:8877 0x7bc610 cp_parser_assignment_expression ../../gcc-source-trunk/gcc/cp/parser.c:9165 0x7bf0d9 cp_parser_expression ../../gcc-source-trunk/gcc/cp/parser.c:9332 0x7b17d9 cp_parser_primary_expression ../../gcc-source-trunk/gcc/cp/parser.c:4923 0x7b323e cp_parser_postfix_expression ../../gcc-source-trunk/gcc/cp/parser.c:6779 0x7ae4bc cp_parser_unary_expression ../../gcc-source-trunk/gcc/cp/parser.c:8098 0x7aed6c cp_parser_sizeof_operand ../../gcc-source-trunk/gcc/cp/parser.c:27439 0x7af219 cp_parser_simple_type_specifier ../../gcc-source-trunk/gcc/cp/parser.c:16707 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <http://gcc.gnu.org/bugs.html> for instructions. $ -- int f (void (*) (int, int)); template < typename T > void foo (T t, __typeof__ (t)); __typeof__ (f (foo < int >)) bar;
[Bug libstdc++/60936] [5/6/7 Regression] Binary code bloat with std::string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60936 --- Comment #24 from Jakub Jelinek --- Have you tried linking with -Wl,--gc-sections ?
[Bug libquadmath/79317] logq is returning double precision results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79317 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |INVALID --- Comment #2 from Jakub Jelinek --- Not a bug then.
[Bug c++/79318] conversion member function preceded with & is not marked as error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79318 --- Comment #3 from Jonathan Wakely --- This seems to be http://wg21.link/cwg1726
[Bug testsuite/79324] The tests introduced at revision r245052 fail on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79324 --- Comment #1 from Jakub Jelinek --- Author: jakub Date: Wed Feb 1 15:47:52 2017 New Revision: 245097 URL: https://gcc.gnu.org/viewcvs?rev=245097&root=gcc&view=rev Log: PR testsuite/79324 * gcc.dg/debug/dwarf2/align-1.c: Add -gno-strict-dwarf to dg-options. * gcc.dg/debug/dwarf2/align-2.c: Likewise. * gcc.dg/debug/dwarf2/align-3.c: Likewise. * gcc.dg/debug/dwarf2/align-4.c: Likewise. * gcc.dg/debug/dwarf2/align-5.c: Likewise. * gcc.dg/debug/dwarf2/align-6.c: Likewise. * gcc.dg/debug/dwarf2/align-as-1.c: Likewise. * g++.dg/debug/dwarf2/align-1.C: Likewise. * g++.dg/debug/dwarf2/align-2.C: Likewise. * g++.dg/debug/dwarf2/align-3.C: Likewise. * g++.dg/debug/dwarf2/align-4.C: Likewise. * g++.dg/debug/dwarf2/align-5.C: Likewise. * g++.dg/debug/dwarf2/align-6.C: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/debug/dwarf2/align-1.C trunk/gcc/testsuite/g++.dg/debug/dwarf2/align-2.C trunk/gcc/testsuite/g++.dg/debug/dwarf2/align-3.C trunk/gcc/testsuite/g++.dg/debug/dwarf2/align-4.C trunk/gcc/testsuite/g++.dg/debug/dwarf2/align-5.C trunk/gcc/testsuite/g++.dg/debug/dwarf2/align-6.C trunk/gcc/testsuite/gcc.dg/debug/dwarf2/align-1.c trunk/gcc/testsuite/gcc.dg/debug/dwarf2/align-2.c trunk/gcc/testsuite/gcc.dg/debug/dwarf2/align-3.c trunk/gcc/testsuite/gcc.dg/debug/dwarf2/align-4.c trunk/gcc/testsuite/gcc.dg/debug/dwarf2/align-5.c trunk/gcc/testsuite/gcc.dg/debug/dwarf2/align-6.c trunk/gcc/testsuite/gcc.dg/debug/dwarf2/align-as-1.c
[Bug fortran/79313] associate statement inside openmp loop breaks OMP intrinisics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79313 --- Comment #5 from Michael Levy --- (In reply to Steve Kargl from comment #3) > On Wed, Feb 01, 2017 at 04:37:52AM +, kargl at gcc dot gnu.org wrote: > A 3rd alternative is change your declaration in the subroutine to > > integer, external :: omp_get_thread_num, omp_get_num_threads I have verified that this works, thank you! (I'm a little confused about how the associate statement highlighted the need for this attribute in the declaration but that's okay.)
[Bug c++/77620] Generic compile time regression of 7.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77620 --- Comment #7 from Andrew Pinski --- We already output one if you use -ftime-report.
[Bug tree-optimization/79321] -ftree-parallelize-loops miscompiles 400.perlbench
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79321 --- Comment #7 from Martin Liška --- (In reply to Andrew Pinski from comment #6) > I ran with =31 on aarch64 and ref was working. Maybe it is only test input > is a problem. I can confirm that, ref.pl is fine. It doesn't call fork (breakpoint at fork is never triggered).
[Bug c++/77620] Generic compile time regression of 7.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77620 --- Comment #6 from petschy at gmail dot com --- Would it be sensible to put an extra line to the output of 'gcc/g++ -v' if the slow checks are enabled, which just states this fact / warns about (possibly mentioning the use of --enable-checking=release at configure)? Future tickets like this might be avoided this way.
[Bug target/78176] [MIPS] miscompiles ldxc1 with large pointers on 32-bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78176 --- Comment #19 from Richard Biener --- I agree with the comments that this (if at all) needs to be fixed at RTL expansion time where we already do quite some "hacks" for sizetype in POINTER_PLUS_EXPR context: case POINTER_PLUS_EXPR: /* Even though the sizetype mode and the pointer's mode can be different expand is able to handle this correctly and get the correct result out of the PLUS_EXPR code. */ /* Make sure to sign-extend the sizetype offset in a POINTER_PLUS_EXPR if sizetype precision is smaller than pointer precision. */ if (TYPE_PRECISION (sizetype) < TYPE_PRECISION (type)) treeop1 = fold_convert_loc (loc, type, fold_convert_loc (loc, ssizetype, treeop1)); /* If sizetype precision is larger than pointer precision, truncate the offset to have matching modes. */ but I don't see from the comments in this bug what the actual stmt is the critical one.
[Bug tree-optimization/79321] -ftree-parallelize-loops miscompiles 400.perlbench
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79321 --- Comment #6 from Andrew Pinski --- I ran with =31 on aarch64 and ref was working. Maybe it is only test input is a problem.
[Bug tree-optimization/79321] -ftree-parallelize-loops miscompiles 400.perlbench
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79321 Martin Liška changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Martin Liška --- It's about a fork being called after a loop, where one threadsleaves gomp_simple_barrier_wait (&pool->threads_dock) and runs the folk. Other threads have't cross the wait barrier. Jakub?
[Bug fortran/78958] FAIL: gfortran.dg/alloc_comp_class_5.f03 - Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78958 --- Comment #4 from Dominique d'Humieres --- > Created attachment 40620 [details] > Preliminary patch > The attached patch fixes the issue at least on x86_64-linux and the sanitizer > does not report any further issues. Please test. Confirmed on darwin. The patch also fixes the failures for allocate_with_source_8.f08 reported in PR78672.
[Bug testsuite/79324] New: The tests introduced at revision r245052 fail on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79324 Bug ID: 79324 Summary: The tests introduced at revision r245052 fail on darwin Product: gcc Version: 7.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: dominiq at lps dot ens.fr CC: aoliva at gcc dot gnu.org, iains at gcc dot gnu.org Target Milestone: --- Host: x86_64-apple-darwin16 Target: x86_64-apple-darwin16 Build: x86_64-apple-darwin16 The tests introduced at revision r245052 fail on darwin FAIL: gcc.dg/debug/dwarf2/align-1.c scan-assembler-times DW_AT_alignment 1 FAIL: gcc.dg/debug/dwarf2/align-2.c scan-assembler-times DW_AT_alignment 1 FAIL: gcc.dg/debug/dwarf2/align-3.c scan-assembler-times DW_AT_alignment 1 FAIL: gcc.dg/debug/dwarf2/align-4.c scan-assembler-times DW_AT_alignment 2 FAIL: gcc.dg/debug/dwarf2/align-5.c scan-assembler-times DW_AT_alignment 1 FAIL: gcc.dg/debug/dwarf2/align-6.c scan-assembler-times DW_AT_alignment 1 FAIL: gcc.dg/debug/dwarf2/align-as-1.c scan-assembler-times DW_AT_alignment 1 FAIL: g++.dg/debug/dwarf2/align-1.C -std=gnu++11 scan-assembler-times DW_AT_alignment 1 FAIL: g++.dg/debug/dwarf2/align-1.C -std=gnu++14 scan-assembler-times DW_AT_alignment 1 FAIL: g++.dg/debug/dwarf2/align-1.C -std=gnu++98 scan-assembler-times DW_AT_alignment 1 FAIL: g++.dg/debug/dwarf2/align-2.C -std=gnu++11 scan-assembler-times DW_AT_alignment 1 FAIL: g++.dg/debug/dwarf2/align-2.C -std=gnu++14 scan-assembler-times DW_AT_alignment 1 FAIL: g++.dg/debug/dwarf2/align-2.C -std=gnu++98 scan-assembler-times DW_AT_alignment 1 FAIL: g++.dg/debug/dwarf2/align-3.C -std=gnu++11 scan-assembler-times DW_AT_alignment 1 FAIL: g++.dg/debug/dwarf2/align-3.C -std=gnu++14 scan-assembler-times DW_AT_alignment 1 FAIL: g++.dg/debug/dwarf2/align-3.C -std=gnu++98 scan-assembler-times DW_AT_alignment 1 FAIL: g++.dg/debug/dwarf2/align-4.C -std=gnu++11 scan-assembler-times DW_AT_alignment 2 FAIL: g++.dg/debug/dwarf2/align-4.C -std=gnu++14 scan-assembler-times DW_AT_alignment 2 FAIL: g++.dg/debug/dwarf2/align-4.C -std=gnu++98 scan-assembler-times DW_AT_alignment 2 FAIL: g++.dg/debug/dwarf2/align-5.C -std=gnu++11 scan-assembler-times DW_AT_alignment 1 FAIL: g++.dg/debug/dwarf2/align-5.C -std=gnu++14 scan-assembler-times DW_AT_alignment 1 FAIL: g++.dg/debug/dwarf2/align-5.C -std=gnu++98 scan-assembler-times DW_AT_alignment 1 FAIL: g++.dg/debug/dwarf2/align-6.C -std=gnu++11 scan-assembler-times DW_AT_alignment 1 FAIL: g++.dg/debug/dwarf2/align-6.C -std=gnu++14 scan-assembler-times DW_AT_alignment 1 FAIL: g++.dg/debug/dwarf2/align-6.C -std=gnu++98 scan-assembler-times DW_AT_alignment 1
[Bug c++/49974] missing warning for indirectly returning reference to local/temporary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49974 --- Comment #7 from Marc Glisse --- We currently warn on all the examples involving X, with -O2. We don't for Y, we might if there was a caller and the dangling reference was used there...
[Bug c++/79307] g++ misses warning for reference on temporary that invokes undefined behaviour
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79307 --- Comment #5 from Jonathan Wakely --- Oops, yes thank you! *** This bug has been marked as a duplicate of bug 49974 ***
[Bug c++/49974] missing warning for indirectly returning reference to local/temporary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49974 Jonathan Wakely changed: What|Removed |Added CC||steven.spark at gmail dot com --- Comment #6 from Jonathan Wakely --- *** Bug 79307 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/79321] -ftree-parallelize-loops miscompiles 400.perlbench
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79321 --- Comment #4 from rguenther at suse dot de --- On Wed, 1 Feb 2017, marxin at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79321 > > Martin Liška changed: > >What|Removed |Added > > Status|NEW |RESOLVED > Resolution|--- |FIXED > > --- Comment #3 from Martin Liška --- > May I close it as invalid? Well, why did we parallelize a loop with a fork() call?
[Bug tree-optimization/79321] -ftree-parallelize-loops miscompiles 400.perlbench
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79321 Martin Liška changed: What|Removed |Added Status|RESOLVED|NEW Resolution|FIXED |---
[Bug tree-optimization/79321] -ftree-parallelize-loops miscompiles 400.perlbench
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79321 Martin Liška changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Martin Liška --- May I close it as invalid?
[Bug c++/79300] Wrong diagnostics position
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79300 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-02-01 Assignee|unassigned at gcc dot gnu.org |dmalcolm at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from David Malcolm --- Confirmed. I'm looking into this.
[Bug c++/79307] g++ misses warning for reference on temporary that invokes undefined behaviour
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79307 --- Comment #4 from Szikra --- > This is bug 44974. > > > Possible duplicate of bug #44859 or bug #51270. > > Looks more like bug 49974 to me. > > *** This bug has been marked as a duplicate of bug 44974 *** Hi you are right, my first example is the same as in bug 49974: struct Y { Y(int& i) : r(i) { } int& r; }; If that were fixed, it would probably solve both problem. Though my second case might be easier to detect, or it's more obviously wrong :) struct TestRefIntDirect { TestRefIntDirect(int a) : a_(a) {}; const int& a_; }; This is wrong by in itself, in this case temporary is always created and in the same place where it is used. But I have a problem: Shouldn't this be marked as duplicate of bug 49974 and not bug 44974? :)
[Bug lto/69866] lto1: internal compiler error: in add_symbol_to_partition_1, at lto/lto-partition.c:158
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69866 --- Comment #8 from Martin Liška --- Is affected just the arm-none-eabi target, or are any others?
[Bug go/79281] gccgo: Binaries using goroutines crash on m68k
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79281 John Paul Adrian Glaubitz changed: What|Removed |Added CC||glaubitz at physik dot fu-berlin.d ||e --- Comment #9 from John Paul Adrian Glaubitz --- Comment on attachment 40645 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40645 Proposed fix Yes, this is the correct fix for gcc-6.
[Bug go/79281] gccgo: Binaries using goroutines crash on m68k
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79281 --- Comment #8 from James Clarke --- Created attachment 40645 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40645&action=edit Proposed fix I believe this patch is what Adrian did; Adrian, can you please confirm?
[Bug testsuite/79272] FAIL: gcc.dg/ipa/pr77653.c scan-ipa-dump icf "Not unifying; alias cannot be created; target is discardable"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79272 Martin Liška changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #7 from Martin Liška --- Fixed.
[Bug testsuite/79272] FAIL: gcc.dg/ipa/pr77653.c scan-ipa-dump icf "Not unifying; alias cannot be created; target is discardable"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79272 --- Comment #6 from Martin Liška --- Author: marxin Date: Wed Feb 1 14:04:38 2017 New Revision: 245095 URL: https://gcc.gnu.org/viewcvs?rev=245095&root=gcc&view=rev Log: Add dg-require-alias to a ICF test (PR testsuite/79272). 2017-02-01 Martin Liska PR testsuite/79272 * gcc.dg/ipa/pr77653.c: Add dg-require-alias to the test. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/ipa/pr77653.c
[Bug tree-optimization/79321] -ftree-parallelize-loops miscompiles 400.perlbench
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79321 --- Comment #2 from Martin Liška --- And running with OMP_NUM_LIMIT=1 works fine.
[Bug tree-optimization/79321] -ftree-parallelize-loops miscompiles 400.perlbench
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79321 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-02-01 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Well, it's not GCC 7 regression, problem is that we generate a GOMP_parallel. After it's done, the main thread is going to do fork/exec: #0 __libc_fork () at ../sysdeps/nptl/fork.c:49 #1 0x004ef765 in Perl_my_fork () at util.c:2303 #2 0x004915f6 in Perl_pp_fork () at pp_sys.c:4009 #3 0x004acccd in Perl_runops_standard () at run.c:37 #4 0x00445f28 in S_run_body (oldscope=1) at perl.c:2017 #5 perl_run (my_perl=) at perl.c:1934 #6 0x004034a2 in main (argc=4, argv=0x7fffdb88, env=) at perlmain.c:98 (gdb) info threads Id Target Id Frame * 1Thread 0x77fae780 (LWP 3579) "perlbench_base." __libc_fork () at ../sysdeps/nptl/fork.c:49 2Thread 0x770e6700 (LWP 3583) "perlbench_base." do_spin (val=8, addr=0x77e044) at ../../../libgomp/config/linux/wait.h:56 3Thread 0x768e5700 (LWP 3584) "perlbench_base." futex_wait (val=8, addr=0x77e044) at ../../../libgomp/config/linux/x86/futex.h:44 4Thread 0x760e4700 (LWP 3585) "perlbench_base." futex_wait (val=8, addr=0x77e044) at ../../../libgomp/config/linux/x86/futex.h:44 and that's why the other threads will not reach the barrier.
[Bug c/79320] sqrt of negative number do not return NaN with i686-w64-mingw32-gcc on pentiumI7/Windows10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79320 --- Comment #2 from Daniel WEIL --- OK. I log the issue on mingw bugs : https://sourceforge.net/p/mingw/bugs/2337/
[Bug go/79281] gccgo: Binaries using goroutines crash on m68k
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79281 --- Comment #7 from Ian Lance Taylor --- It sounds like you have a patch for GCC 6. If you send it in I can apply it. The error you show must be from `make -j`, as compiling a file in libgfortran would not invoke go1. What is the actual failure?
[Bug libquadmath/79317] logq is returning double precision results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79317 --- Comment #1 from ggoeckel at presby dot edu --- My error. Sorry. Double precision entered with this assignment. lntwo=6.9314718055994530941723212145817446e-01
[Bug c/12245] [5/6/7 regression] Uses lots of memory when compiling large initialized arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12245 --- Comment #63 from Richard Biener --- Sth that could pay off with other testcases (nested CONSTRUCTORs) is to truncate the size of the CONSTRUCTOR_ELTS vec<> to the exact final size after parsing it as it will never grow again and we over-allocate during safe-pushing to it. vec:: has no suitable function to do that (yet) though. It won't help this particular testcase of course.
[Bug c/12245] [5/6/7 regression] Uses lots of memory when compiling large initialized arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12245 --- Comment #62 from Richard Biener --- Main issue is still for GCC: Kind Nodes Bytes constants1630852 39140573 integer_cst 1630844 c/c-typeck.c:9020 (output_init_element) 0: 0.0% 33554552: 50.0% 33554440: 31.2% 152: 0.2%20 and for G++: Kind Nodes Bytes constants1630864 39140861 integer_cst 1630856 cp/constexpr.c:4814 (maybe_constant_value) 67108816:100.0% 100663104 17: 0.0% ggc (huh!) cp/parser.c:21811 (cp_parser_initializer_list) 33554440: 99.8% 33554552: 8.3% 0: 0.0% 152: 0.1%20 that maybe_constant_value can be improved to cp/constexpr.c:4817 (maybe_constant_value) 2032: 13.6% 2144 2: 0.0% ggc with a simple patch.
[Bug tree-optimization/71142] [6/7 Regression] ICE: Segmentation fault in ssa_default_def (graphite)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71142 Martin Liška changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #12 from Martin Liška --- (In reply to ktkachov from comment #11) > (In reply to Martin Liška from comment #10) > > Can't reproduce any of both tests on both x86_64-linux-gnu and aarach64. Is > > it still valid? > > I can reproduce the ICE on the original testcase on GCC 6 but not trunk. > I can't reproduce the ICE in the second testcase anywhere Ok, thanks. It really disappeared on trunk with the Richi's patch that does reorganization in pass manager. Anyhow, as I debugged that on GCC6 branch, it's dup of PR71351. Which still has a reproducible test-case. *** This bug has been marked as a duplicate of bug 71351 ***
[Bug tree-optimization/59859] [meta-bug] GRAPHITE issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59859 Bug 59859 depends on bug 71142, which changed state. Bug 71142 Summary: [6/7 Regression] ICE: Segmentation fault in ssa_default_def (graphite) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71142 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE