[Bug middle-end/58941] [4.7 Regression] value modification on zero-length array optimized away
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58941 --- Comment #6 from Thomas Moschcau thomas.moschcau at web dot de --- (In reply to Richard Biener from comment #5) And 4.8.3. Hello Richard, will there also be a fix for gcc 4.6.x? Kind Regards Thomas
[Bug testsuite/59308] New: gcc.dg/tree-ssa/ssa-ifcombine-ccmp-[1456] tests fail on arm cortex-a5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59308 Bug ID: 59308 Summary: gcc.dg/tree-ssa/ssa-ifcombine-ccmp-[1456] tests fail on arm cortex-a5 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: christophe.lyon at st dot com Commit 204194 from Andrew Pinski introduced several new tests, among which gcc.dg/tree-ssa/ssa-ifcombine-ccmp-1.c scan-tree-dump optimized gcc.dg/tree-ssa/ssa-ifcombine-ccmp-4.c scan-tree-dump optimized gcc.dg/tree-ssa/ssa-ifcombine-ccmp-5.c scan-tree-dump-times optimized 2 gcc.dg/tree-ssa/ssa-ifcombine-ccmp-6.c scan-tree-dump-times optimized \\| 2 fail when configuring --target arm-none-linux-gnueabihf --with-cpu=cortex-a5 --with-fpu=vfpv3-d16-fp16.
[Bug tree-optimization/59303] uninit-pred-8_b.c and uninit-pred-9_b.c fail after better optimizations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59303 --- Comment #3 from christophe.lyon at st dot com --- I have filed PR 59308 about the ssa-ifcombine-ccmp* tests failing on cortex-a5. Should I mark this bug report (59303) as a duplicate of 49498?
[Bug lto/56706] [4.8/4.9 Regression] failure building CP2K at -flto -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56706 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Known to work||4.9.0 Known to fail|4.9.0 | --- Comment #12 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- Building with 4.9.0 now works, 4.8.3 [gcc-4_8-branch revision 203695] still fails.
[Bug target/59187] internal error with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59187 --- Comment #5 from Alessio alessio211734 at yahoo dot it --- Hello, when you fix a mingw bug where can I download the new version of compiler? I should wait a new release or I can get from trunk?!?! I get another internal error. Il Lunedì 25 Novembre 2013 22:16, ktietz at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org ha scritto: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59187 Kai Tietz ktietz at gcc dot gnu.org changed: What |Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Kai Tietz ktietz at gcc dot gnu.org --- Yes, bug was already fixed. Therefore closed
[Bug middle-end/58941] [4.7 Regression] value modification on zero-length array optimized away
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58941 --- Comment #7 from rguenther at suse dot de rguenther at suse dot de --- On Wed, 27 Nov 2013, thomas.moschcau at web dot de wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58941 --- Comment #6 from Thomas Moschcau thomas.moschcau at web dot de --- (In reply to Richard Biener from comment #5) And 4.8.3. Hello Richard, will there also be a fix for gcc 4.6.x? No, gcc 4.6 is no longer maintained.
[Bug tree-optimization/59288] [4.7/4.8/4.9 Regression] ICE in get_initial_def_for_induction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59288 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Wed Nov 27 08:50:15 2013 New Revision: 205434 URL: http://gcc.gnu.org/viewcvs?rev=205434root=gccview=rev Log: 2013-11-27 Richard Biener rguent...@suse.de PR tree-optimization/59288 * tree-vect-loop.c (get_initial_def_for_induction): Do not re-analyze the PHI but use STMT_VINFO_LOOP_PHI_EVOLUTION_PART. * gcc.dg/torture/pr59288.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr59288.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-loop.c
[Bug tree-optimization/59288] [4.7/4.8 Regression] ICE in get_initial_def_for_induction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59288 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Known to work||4.9.0 Summary|[4.7/4.8/4.9 Regression]|[4.7/4.8 Regression] ICE in |ICE in |get_initial_def_for_inducti |get_initial_def_for_inducti |on |on | Known to fail||4.8.2 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- Fixed on trunk sofar. Might depend on the patch no longer allowing pointer vectors though, thus before backporting double-check that.
[Bug testsuite/59308] [4.9 Regression] gcc.dg/tree-ssa/ssa-ifcombine-ccmp-[1456] tests fail on arm cortex-a5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59308
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2013-11-27
Target Milestone|--- |4.9.0
Summary|gcc.dg/tree-ssa/ssa-ifcombi |[4.9 Regression]
|ne-ccmp-[1456] tests fail |gcc.dg/tree-ssa/ssa-ifcombi
|on arm cortex-a5|ne-ccmp-[1456] tests fail
||on arm cortex-a5
Ever confirmed|0 |1
--- Comment #1 from Richard Biener rguenth at gcc dot gnu.org ---
They depend on BRANCH_COST, their target selector needs updating for arm.
/* { dg-do compile { target { ! m68k*-*-* mmix*-*-* mep*-*-* bfin*-*-*
v850*-*-* picochip*-*-* moxie*-*-* cris*-*-* m32c*-*-* fr30*-*-* mcore*-*-*
powerpc*-*-* xtensa*-*-* arc*-*-*} } } */
or rather we should have a effective-target logical_op_non_short_circuit
[Bug middle-end/58746] [4.9 Regression] Incorrect warning with -Waggressive-loop-optimizations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58746 --- Comment #1 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- Reduced : MODULE mathlib INTEGER, PARAMETER :: dp = 8 CONTAINS FUNCTION expint(n,x) REAL(dp) :: x, expint nm1=n-1 DO i=1,MAXIT IF(i.NE.nm1) THEN DO ii=1,nm1 psi=psi+1.0_dp/ii END DO del=fact*(-LOG(x)+psi) END IF expint=expint+del END DO END FUNCTION expint END MODULE USE mathlib REAL(KIND=dp), VOLATILE :: r=0.1_dp r = expint(1,r) END
[Bug target/59305] [4.9 Regression] gcc.dg/atomic/c11-atomic-exec-5.c fails with WARNING: program timed out on x86_64-apple-darwin13
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59305 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.0 Summary|gcc.dg/atomic/c11-atomic-ex |[4.9 Regression] |ec-5.c fails with WARNING: |gcc.dg/atomic/c11-atomic-ex |program timed out on|ec-5.c fails with WARNING: |x86_64-apple-darwin13 |program timed out on ||x86_64-apple-darwin13
[Bug tree-optimization/59303] [4.9 Regression] uninit-pred-8_b.c and uninit-pred-9_b.c fail after better optimizations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59303 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target||arm, x86_64 Status|UNCONFIRMED |NEW Keywords||diagnostic Last reconfirmed||2013-11-27 CC||xinliangli at gmail dot com Ever confirmed|0 |1 Summary|uninit-pred-8_b.c and |[4.9 Regression] |uninit-pred-9_b.c fail |uninit-pred-8_b.c and |after better optimizations |uninit-pred-9_b.c fail ||after better optimizations Target Milestone|--- |4.9.0 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed. They fail for quite some while. The uninit pass needs to cope with combined predicates.
[Bug c++/57645] [4.8/4.9 Regression] Explicitly-declared destructor with no exception specification is always noexcept(true)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57645 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot gnu.org --- Comment #7 from Paolo Carlini paolo.carlini at oracle dot com --- Indeed. Thanks Daniel. I have just confirmed that everything is fine for the released 4.8.2.
[Bug middle-end/58746] [4.9 Regression] Incorrect warning with -Waggressive-loop-optimizations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58746 --- Comment #2 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- this testcase gives the same error without LTO. Just -O2 is sufficient: INTEGER, PARAMETER :: dp = 8 REAL(KIND=dp), VOLATILE :: r=0.1_dp r = expint(1,r) CONTAINS FUNCTION expint(n,x) REAL(dp) :: x, expint INTEGER :: maxit=100 nm1=n-1 DO i=1,MAXIT IF(i.NE.nm1) THEN DO ii=1,nm1 psi=psi+1.0_dp/ii END DO del=fact*(-LOG(x)+psi) END IF expint=expint+del END DO END FUNCTION expint END
[Bug middle-end/59138] [4.8/4.9 Regression] possible packed struct miscompile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59138 --- Comment #7 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Author: ebotcazou Date: Wed Nov 27 09:17:23 2013 New Revision: 205436 URL: http://gcc.gnu.org/viewcvs?rev=205436root=gccview=rev Log: PR middle-end/59138 * expr.c (emit_group_store): Don't write past the end of the structure. (store_bit_field): Fix formatting. Added: trunk/gcc/testsuite/gcc.c-torture/execute/20131127-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/expr.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/59138] [4.8/4.9 Regression] possible packed struct miscompile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59138 --- Comment #8 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Author: ebotcazou Date: Wed Nov 27 09:19:47 2013 New Revision: 205437 URL: http://gcc.gnu.org/viewcvs?rev=205437root=gccview=rev Log: PR middle-end/59138 * expr.c (emit_group_store): Don't write past the end of the structure. (store_bit_field): Fix formatting. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.c-torture/execute/20131127-1.c - copied unchanged from r205436, trunk/gcc/testsuite/gcc.c-torture/execute/20131127-1.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/expr.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug middle-end/59138] [4.8/4.9 Regression] possible packed struct miscompile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59138 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Thanks for reporting the problem.
[Bug target/59289] [ARM] regression on unsigned-extend-2.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59289 ktkachov at gcc dot gnu.org changed: What|Removed |Added Target|arm |arm-*-* Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-11-27 Known to work||4.8.2 Version|4.9.0 |unknown Assignee|unassigned at gcc dot gnu.org |ktkachov at gcc dot gnu.org Summary|[4.9 Regression][ARM] |[ARM] regression on |regression on |unsigned-extend-2.c |unsigned-extend-2.c | Ever confirmed|0 |1 Known to fail||4.9.0 --- Comment #1 from ktkachov at gcc dot gnu.org --- Looking a bit into it, it seems that I wrote the A15 costs without considering that they're supposed to represent the latency cost minus 1 (since every insn has an implicit cost of COSTS_N_INSNS (1) already). Those were the early days of the new costs tables. If I adjust the costs for the A15 for this, it gives the old sequence again. Regardless of whether this new sequence is good or not, the A15 costs should be fixed. I have a patch in testing
[Bug middle-end/59037] [4.8/4.9 Regression] ICE when accessing invalid element (nelts + 1) of vector
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59037 --- Comment #7 from vries at gcc dot gnu.org --- Author: vries Date: Wed Nov 27 10:00:30 2013 New Revision: 205438 URL: http://gcc.gnu.org/viewcvs?rev=205438root=gccview=rev Log: Don't create out-of-bounds BIT_FIELD_REF. 2013-11-27 Tom de Vries t...@codesourcery.com Marc Glisse marc.gli...@inria.fr PR middle-end/59037 * semantics.c (cxx_fold_indirect_ref): Don't create out-of-bounds BIT_FIELD_REF. * fold-const.c (fold_indirect_ref_1): Don't create out-of-bounds BIT_FIELD_REF. * gimple-fold.c (gimple_fold_indirect_ref): Same. * tree-cfg.c (verify_expr): Give error if BIT_FIELD_REF is out-of-bounds. * c-c++-common/pr59037.c: New testcase. Added: trunk/gcc/testsuite/c-c++-common/pr59037.c Modified: trunk/gcc/ChangeLog trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c trunk/gcc/fold-const.c trunk/gcc/gimple-fold.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-cfg.c
[Bug c++/59032] [4.8/4.9 Regression] ICE incrementing vector type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59032 --- Comment #7 from vries at gcc dot gnu.org --- Author: vries Date: Wed Nov 27 10:00:48 2013 New Revision: 205439 URL: http://gcc.gnu.org/viewcvs?rev=205439root=gccview=rev Log: Handle vector increment/decrement in build_unary_op 2013-11-27 Tom de Vries t...@codesourcery.com Marc Glisse marc.gli...@inria.fr PR c++/59032 * c-typeck.c (build_unary_op): Allow vector increment and decrement. * typeck.c (cp_build_unary_op): Allow vector increment and decrement. * c-c++-common/pr59032.c: New testcase. Added: trunk/gcc/testsuite/c-c++-common/pr59032.c Modified: trunk/gcc/c/ChangeLog trunk/gcc/c/c-typeck.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/58723] [4.9 Regression] ICE in lto_output_edge, at lto-cgraph.c:300 for OpenMP's simd reduction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58723 --- Comment #9 from Richard Biener rguenth at gcc dot gnu.org --- We fail to stream cfun-has_force_vect_loops.
[Bug middle-end/58723] [4.9 Regression] ICE in lto_output_edge, at lto-cgraph.c:300 for OpenMP's simd reduction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58723 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Attachment #31299|0 |1 is obsolete|| --- Comment #10 from Richard Biener rguenth at gcc dot gnu.org --- Created attachment 31305 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31305action=edit updated patch lto1 also does not get -fopenmp[-simd] passed, not sure if that is needed though. The simple testcase from comment #2 already fails with ./xgcc -B. -B ../x86_64-unknown-linux-gnu/libgomp/ -B ../x86_64-unknown-linux-gnu/libgomp/.libs -O -flto -fopenmp t.i -r -nostdlib t.i: In function 'foo': t.i:1:6: internal compiler error: in expand_GOMP_SIMD_VF, at internal-fn.c:137 void foo(int n) ^ 0x8c4d19 expand_GOMP_SIMD_VF updated patch attached that fixes the streaming and thus runs the vectorizer at -O1 during LTRANs (but it does nothing).
[Bug middle-end/58723] [4.9 Regression] ICE in lto_output_edge, at lto-cgraph.c:300 for OpenMP's simd reduction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58723 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Attachment #31305|0 |1 is obsolete|| --- Comment #11 from Richard Biener rguenth at gcc dot gnu.org --- Created attachment 31306 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31306action=edit updated patch And there is also has_simduid_loops and loop-safelen and loop-force_vect. Also loop-simduid but 1) I don't know how to stream it, 2) it seems to work without. But I see the vectorizer looks at DECL_UID (loop-simduid)), so work without may mean it just doesn't vectorize the thing but cleans up.
[Bug middle-end/58723] [4.9 Regression] ICE in lto_output_edge, at lto-cgraph.c:300 for OpenMP's simd reduction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58723 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Attachment #31306|0 |1 is obsolete|| --- Comment #12 from Richard Biener rguenth at gcc dot gnu.org --- Created attachment 31307 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31307action=edit updated patch Indeed. t.i:1:6: note: === vect_analyze_data_refs === t.i:1:6: note: not vectorized: loop contains function calls or data references that cannot be analyzed t.i:1:6: note: bad data references. t.i:1:6: note: vectorized 0 loops in function. Ok, with simply streaming simduid as tree it works. Not sure if we want to stream trees into the CFG section though ... (or if it even really works). What's the reason that simduid is a tree?
[Bug middle-end/58723] [4.9 Regression] ICE in lto_output_edge, at lto-cgraph.c:300 for OpenMP's simd reduction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58723 --- Comment #13 from Richard Biener rguenth at gcc dot gnu.org --- Eh. make check-gcc RUNTESTFLAGS=--target_board=unix/-flto/-ffat-lto-objects gomp.exp FAIL: gcc.dg/gomp/declare-simd-1.c (internal compiler error) FAIL: gcc.dg/gomp/declare-simd-1.c (test for excess errors) But otherwise clean. /space/rguenther/src/svn/trunk/gcc/testsuite/gcc.dg/gomp/declare-simd-1.c:100:1: internal compiler error: tree code 'omp_clause' is not supported in LTO streams^M 0xa6dbe4 lto_write_tree^M /space/rguenther/src/svn/trunk/gcc/lto-streamer-out.c:376^M seems like FUNCTION_DECLs now refer to OMP_CLAUSE? Ah... via attributes :/ Jakub - please add tree streaming support for the relevant required stuff.
[Bug middle-end/58723] [4.9 Regression] ICE in lto_output_edge, at lto-cgraph.c:300 for OpenMP's simd reduction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58723 --- Comment #14 from Jakub Jelinek jakub at gcc dot gnu.org --- (In reply to Richard Biener from comment #9) We fail to stream cfun-has_force_vect_loops. Note we don't necessarily have to stream that (and has_simduid_loops), the alternative is to compute it during streaming in the IL - if it sees any force_vect loop, it can set fun-has_force_vect_loops for the loop, similarly for non-zero simdlen and fun-has_simduid_loops. Those two flags are just (pessimistically correct) flags to avoid scanning the whole IL for it, but LTO scans the whole IL anyway...
[Bug middle-end/58723] [4.9 Regression] ICE in lto_output_edge, at lto-cgraph.c:300 for OpenMP's simd reduction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58723 --- Comment #15 from Jakub Jelinek jakub at gcc dot gnu.org --- (In reply to Richard Biener from comment #13) Eh. make check-gcc RUNTESTFLAGS=--target_board=unix/-flto/-ffat-lto-objects gomp.exp FAIL: gcc.dg/gomp/declare-simd-1.c (internal compiler error) FAIL: gcc.dg/gomp/declare-simd-1.c (test for excess errors) But otherwise clean. /space/rguenther/src/svn/trunk/gcc/testsuite/gcc.dg/gomp/declare-simd-1.c: 100:1: internal compiler error: tree code 'omp_clause' is not supported in LTO streams^M 0xa6dbe4 lto_write_tree^M /space/rguenther/src/svn/trunk/gcc/lto-streamer-out.c:376^M seems like FUNCTION_DECLs now refer to OMP_CLAUSE? Ah... via attributes :/ Jakub - please add tree streaming support for the relevant required stuff. Yeah, that is the current reason why the new elementals tests to be committed also fail with LTO. I'll hack on that.
[Bug sanitizer/59306] ICE with -fsanitize=null: gimple check: expected gimple_call(error_mark), have gimple_assign(addr_expr) in gimple_call_arg
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59306 --- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Wed Nov 27 11:40:22 2013 New Revision: 205443 URL: http://gcc.gnu.org/viewcvs?rev=205443root=gccview=rev Log: PR sanitizer/59306 * ubsan.c (instrument_null): Use gimple_store_p/gimple_assign_load_p instead of walk_gimple_op. (ubsan_pass): Adjust. Call instrument_null only if SANITIZE_NULL. testsuite/ * g++.dg/ubsan/pr59306.C: New test. Added: trunk/gcc/testsuite/g++.dg/ubsan/pr59306.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/ubsan.c
[Bug sanitizer/59306] ICE with -fsanitize=null: gimple check: expected gimple_call(error_mark), have gimple_assign(addr_expr) in gimple_call_arg
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59306 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Marek Polacek mpolacek at gcc dot gnu.org --- Fixed.
[Bug c/59259] [x32] Incorrect packing and/or alignment when using a 64 bit type as array of zero length in a structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59259 cjanderson at yandex dot com changed: What|Removed |Added Status|CLOSED |UNCONFIRMED Resolution|INVALID |--- --- Comment #4 from cjanderson at yandex dot com --- Sorry, this still troubles me. Isn't the last structure a pointer, ie: struct blah entrytable[0]; is really just a pointer, and hence in most cases just an 32 bit value (I know there are some tricks), but if it is a pointer then the alignment should surely be the same as for ia32?
[Bug rtl-optimization/57189] [4.9 Regression] Vector register is spilled for vector extract pattern
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57189 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- Likely caused by r198611.
[Bug rtl-optimization/57189] [4.9 Regression] Vector register is spilled for vector extract pattern
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57189 --- Comment #4 from Uroš Bizjak ubizjak at gmail dot com --- (In reply to Jakub Jelinek from comment #3) Likely caused by r198611. This is the patch that exposes the problem. I have filled this PR due to the difference with IRA vs. reload, it looks that spill size should be somehow taken into account.
[Bug sanitizer/59136] [4.9 Regression] llvm-symbolizer shouldn't be started always
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59136 --- Comment #10 from Alexey Samsonov samsonov at google dot com --- Hi! Jakub suggested to use libbacktrace in libsanitizer. I've committed his patch to LLVM, and it will soon be merged into GCC, with many more changes. So, your change will not be needed. I've also ensured that, if you use llvm-symbolizer, it will not be started always, only when we actually need it to print a symbolized stack trace. Regarding llvm-symbolizer: Unknown command line argument '--default-arch=x86_64' failure: you see this because you don't use the trunk version of llvm-symbolizer binary. Sorry about that - we can keep ASan runtime in sync with LLVM head, but we surely get such dependency problems when we move it anywhere.
[Bug c/59259] [x32] Incorrect packing and/or alignment when using a 64 bit type as array of zero length in a structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59259 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #5 from Andreas Schwab sch...@linux-m68k.org --- A flexible array member is not a pointer.
[Bug libstdc++/35763] std::cout loses whole blocks of output if interrupted by signal without SA_RESTART
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35763 Johannes Schaub schaub.johannes at googlemail dot com changed: What|Removed |Added CC||schaub.johannes@googlemail. ||com --- Comment #4 from Johannes Schaub schaub.johannes at googlemail dot com --- Created attachment 31309 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31309action=edit Reproduction of badbit
[Bug tree-optimization/54742] Switch elimination in FSM loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54742
jgreenhalgh at gcc dot gnu.org changed:
What|Removed |Added
CC||jgreenhalgh at gcc dot gnu.org
--- Comment #27 from jgreenhalgh at gcc dot gnu.org ---
Created attachment 31308
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31308action=edit
Dumps for less reduced testcase in comment 27
As of revision 205398, I'm not seeing this optimisation trigger when compiling
the benchmark in question.
I've attached the dumps from a less agressively reduced version of the testcase
given in the intial report, which we don't currently thread.
This testcase is more representative of the control structure in the benchmark
code. In particular, we have the problematic scenario of two 'joiner' blocks in
the thread path.
Looking at the dumps for this testcase I think that we would need to spot
threads like:
(17, 23) incoming edge; (23, 4) joiner; (4, 5) joiner; (5, 8) back-edge; (8,
15) switch-statement;
The testcase I am using is:
---
int sum0, sum1, sum2, sum3;
int foo(char * s, char** ret)
{
int state=0;
char c;
for (; *s state != 4; s++)
{
c = *s;
if (c == '*')
{
s++;
break;
}
switch (state) {
case 0:
if (c == '+') state = 1;
else if (c != '-') sum0+=c;
break;
case 1:
if (c == '+') state = 2;
else if (c == '-') state = 0;
else sum1+=c;
break;
case 2:
if (c == '+') state = 3;
else if (c == '-') state = 1;
else sum2+=c;
break;
case 3:
if (c == '-') state = 2;
else if (c == 'x') state = 4;
break;
default:
break;
}
}
*ret = s;
return state;
}
[Bug libstdc++/35763] std::cout loses whole blocks of output if interrupted by signal without SA_RESTART
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35763 --- Comment #5 from Johannes Schaub schaub.johannes at googlemail dot com --- We also have this bug and it took us several days to find the cause. Testcase by my colleague attached. Perhaps this should fire an assertion if it is hard to fix efficiently, instead of simply letting things go wrong unnoticed.
[Bug tree-optimization/54742] Switch elimination in FSM loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54742 jgreenhalgh at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #28 from jgreenhalgh at gcc dot gnu.org --- I've REOPENED this bug for the less-reduced testcase given in #27. If anyone has objections, or thinks it would be more appropriate, I can open a new bug.
[Bug tree-optimization/19794] [meta-bug] Jump threading related bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19794 Bug 19794 depends on bug 54742, which changed state. Bug 54742 Summary: Switch elimination in FSM loop http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54742 What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |---
[Bug c/59259] [x32] Incorrect packing and/or alignment when using a 64 bit type as array of zero length in a structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59259 cjanderson at yandex dot com changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #6 from cjanderson at yandex dot com --- ok
[Bug middle-end/59309] New: FAIL: c-c++-common/cilk-plus/CK/spawnee_inline.c -g -fcilkplus (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59309 Bug ID: 59309 Summary: FAIL: c-c++-common/cilk-plus/CK/spawnee_inline.c -g -fcilkplus (test for excess errors) Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com When GCC is bootstraped with -fsanitize=address, I got ==5312==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6021e550 at pc 0x7fb14b [hjl@gnu-mic-2 gcc]$ addr2line -e cc1 0x7fb14b /export/gnu/import/git/gcc/gcc/c-family/cilk.c:765 [hjl@gnu-mic-2 gcc]$
[Bug middle-end/59310] New: FAIL: gcc.dg/gomp/openmp-simd-1.c (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59310 Bug ID: 59310 Summary: FAIL: gcc.dg/gomp/openmp-simd-1.c (test for excess errors) Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com When GCC is bootstrapped with -fsanitize=address, I got AddressSanitizer: stack-buffer-overflow on address 0x7fffa0ffedca at pc 0x6d57db ... [hjl@gnu-mic-2 gcc]$ addr2line -e cc1 0x6d57db /export/gnu/import/git/gcc/gcc/c/c-parser.c:11787 [hjl@gnu-mic-2 gcc]$
[Bug c++/59311] New: FAIL: g++.dg/cpp1y/vla-initlist1.C (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59311 Bug ID: 59311 Summary: FAIL: g++.dg/cpp1y/vla-initlist1.C (test for excess errors) Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com When GCC is bootstrapped with -fsanitize=address, I got ERROR: AddressSanitizer: global-buffer-overflow on address 0x0297d2e4 at pc 0xe64e63 [hjl@gnu-mic-2 gcc]$ addr2line -e cc1plus 0xe64e63 /export/gnu/import/git/gcc/gcc/dwarf2cfi.c:909 [hjl@gnu-mic-2 gcc]$
[Bug c++/59311] FAIL: g++.dg/cpp1y/vla-initlist1.C (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59311 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-11-27 Ever confirmed|0 |1 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com --- Only happens with -m32 on Linux/x86-64.
[Bug c++/59311] FAIL: g++.dg/cpp1y/vla-initlist1.C (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59311 --- Comment #2 from H.J. Lu hjl.tools at gmail dot com --- ==8030==ERROR: AddressSanitizer: global-buffer-overflow on address 0x0297d2e4 at pc 0xe64e63 bp 0x7fffe2f360f0 sp 0x7fffe2f360e8 READ of size 4 at 0x0297d2e4 thread T0 #0 0xe64e62 (/export/build/gnu/gcc-asan/build-x86_64-linux/gcc/cc1plus+0xe64e62) #1 0xe69740 (/export/build/gnu/gcc-asan/build-x86_64-linux/gcc/cc1plus+0xe69740) #2 0xe6aee8 (/export/build/gnu/gcc-asan/build-x86_64-linux/gcc/cc1plus+0xe6aee8) #3 0x146e649 (/export/build/gnu/gcc-asan/build-x86_64-linux/gcc/cc1plus+0x146e649) #4 0x146f008 (/export/build/gnu/gcc-asan/build-x86_64-linux/gcc/cc1plus+0x146f008) #5 0x146f02e (/export/build/gnu/gcc-asan/build-x86_64-linux/gcc/cc1plus+0x146f02e) #6 0x146f02e (/export/build/gnu/gcc-asan/build-x86_64-linux/gcc/cc1plus+0x146f02e) #7 0xda6389 (/export/build/gnu/gcc-asan/build-x86_64-linux/gcc/cc1plus+0xda6389) #8 0xdabc84 (/export/build/gnu/gcc-asan/build-x86_64-linux/gcc/cc1plus+0xdabc84) #9 0xdaceea (/export/build/gnu/gcc-asan/build-x86_64-linux/gcc/cc1plus+0xdaceea) #10 0x85a67a (/export/build/gnu/gcc-asan/build-x86_64-linux/gcc/cc1plus+0x85a67a) #11 0x16535f4 (/export/build/gnu/gcc-asan/build-x86_64-linux/gcc/cc1plus+0x16535f4) #12 0x1658083 (/export/build/gnu/gcc-asan/build-x86_64-linux/gcc/cc1plus+0x1658083) #13 0x3cdda21b44 (/lib64/libc.so.6+0x3cdda21b44) #14 0x5b66e0 (/export/build/gnu/gcc-asan/build-x86_64-linux/gcc/cc1plus+0x5b66e0) 0x0297d2e4 is located 60 bytes to the left of global variable 'dbx_register_map' from '/export/gnu/import/git/gcc/gcc/config/i386/i386.c' (0x297d320) of size 324 0x0297d2e4 is located 0 bytes to the right of global variable 'dbx64_register_map' from '/export/gnu/import/git/gcc/gcc/config/i386/i386.c' (0x297d1a0) of size 324 Shadow bytes around the buggy address: 0x80527a00: f9 f9 f9 f9 00 00 00 00 00 00 00 00 00 00 00 00 0x80527a10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x80527a20: 00 00 00 00 00 00 00 00 00 00 00 00 04 f9 f9 f9 0x80527a30: f9 f9 f9 f9 00 00 00 00 00 00 00 00 00 00 00 00 0x80527a40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =0x80527a50: 00 00 00 00 00 00 00 00 00 00 00 00[04]f9 f9 f9 0x80527a60: f9 f9 f9 f9 00 00 00 00 00 00 00 00 00 00 00 00 0x80527a70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x80527a80: 00 00 00 00 00 00 00 00 00 00 00 00 04 f9 f9 f9 0x80527a90: f9 f9 f9 f9 00 00 00 00 00 00 00 00 00 00 00 00 0x80527aa0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap right redzone:fb Freed heap region: fd Stack left redzone:f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return:f5 Stack use after scope: f8 Global redzone:f9 Global init order: f6 Poisoned by user: f7 ASan internal: fe ==8030==ABORTING
[Bug c++/59311] FAIL: g++.dg/cpp1y/vla-initlist1.C (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59311
--- Comment #3 from H.J. Lu hjl.tools at gmail dot com ---
(gdb) f 0
#0 dwarf2out_frame_debug (insn=0x75980ca8) at
/export/gnu/import/git/gcc/gcc/dwarf2cfi.c:2000
2000 fde-vdrap_reg = dwf_regno (n);
(gdb) p n
$2 = (rtx_def *) 0x7597cd40
(gdb) call debug_rtx (n)
(reg:SI 177)
(gdb) call debug_rtx (insn)
(insn/f 202 254 2 2 (set (mem/c:SI (plus:SI (reg/f:SI 6 bp)
(const_int -48 [0xffd0])) [0 %sfp+-48 S4 A32])
(reg:SI 2 cx)) 86 {*movsi_internal}
(expr_list:REG_CFA_SET_VDRAP (reg:SI 177)
(nil)))
reg:SI 177 isn't a hard register and there is no DWARF register
for it.
[Bug middle-end/59309] FAIL: c-c++-common/cilk-plus/CK/spawnee_inline.c -g -fcilkplus (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59309 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com --- Breakpoint 4, 0x007fb146 in gimplify_cilk_spawn (spawn_p=optimized out, before=optimized out, after=optimized out) at /export/gnu/import/git/gcc/gcc/c-family/cilk.c:774 774 if (*arg_array == NULL_TREE) (gdb) bt #0 0x007fb146 in gimplify_cilk_spawn (spawn_p=optimized out, before=optimized out, after=optimized out) at /export/gnu/import/git/gcc/gcc/c-family/cilk.c:774 #1 0x00d72f04 in gimplify_modify_expr (expr_p=expr_p@entry=0x755cc3b8, pre_p=pre_p@entry=0x7fffb540, post_p=post_p@entry=0x7fffa9a0, want_value=optimized out) at /export/gnu/import/git/gcc/gcc/gimplify.c:4442 #2 0x00d5371d in gimplify_expr (expr_p=0x755cc3b8, pre_p=pre_p@entry=0x7fffb540, post_p=optimized out, post_p@entry=0x0, gimple_test_f=gimple_test_f@entry=0xd40450 is_gimple_stmt(tree), fallback=fallback@entry=0) at /export/gnu/import/git/gcc/gcc/gimplify.c:7436 #3 0x00d5df5b in gimplify_stmt (stmt_p=optimized out, seq_p=seq_p@entry=0x7fffb540) at /export/gnu/import/git/gcc/gcc/gimplify.c:5353 #4 0x00d543f4 in gimplify_statement_list (pre_p=0x7fffb540, expr_p=0x755c39b8) at /export/gnu/import/git/gcc/gcc/gimplify.c:1405 #5 gimplify_expr (expr_p=0x755c39b8, pre_p=pre_p@entry=0x7fffb540, post_p=optimized out, post_p@entry=0x0, gimple_test_f=gimple_test_f@entry=0xd40450 is_gimple_stmt(tree), fallback=fallback@entry=0) at /export/gnu/import/git/gcc/gcc/gimplify.c:7844 #6 0x00d5df5b in gimplify_stmt (stmt_p=optimized out, seq_p=seq_p@entry=0x7fffb540) at /export/gnu/import/git/gcc/gcc/gimplify.c:5353 #7 0x00d68320 in gimplify_cond_expr (expr_p=expr_p@entry=0x755cc418, pre_p=pre_p@entry=0x7fffc6e0, fallback=fallback@entry=0) at /export/gnu/import/git/gcc/gcc/gimplify.c:3085 #8 0x00d53773 in gimplify_expr (expr_p=0x755cc418, pre_p=pre_p@entry=0x7fffc6e0, post_p=optimized out, post_p@entry=0x0, gimple_test_f=gimple_test_f@entry=0xd40450 is_gimple_stmt(tree), fallback=fallback@entry=0) at /export/gnu/import/git/gcc/gcc/gimplify.c:7379 #9 0x00d5df5b in gimplify_stmt (stmt_p=optimized out, seq_p=seq_p@entry=0x7fffc6e0) ---Type return to continue, or q return to quit--- at /export/gnu/import/git/gcc/gcc/gimplify.c:5353 #10 0x00d543f4 in gimplify_statement_list (pre_p=0x7fffc6e0, expr_p=0x7fffc620) at /export/gnu/import/git/gcc/gcc/gimplify.c:1405 #11 gimplify_expr (expr_p=0x7fffc620, pre_p=pre_p@entry=0x7fffc6e0, post_p=optimized out, post_p@entry=0x0, gimple_test_f=gimple_test_f@entry=0xd40450 is_gimple_stmt(tree), fallback=fallback@entry=0) at /export/gnu/import/git/gcc/gcc/gimplify.c:7844 #12 0x00d5df5b in gimplify_stmt (stmt_p=stmt_p@entry=0x7fffc620, seq_p=seq_p@entry=0x7fffc6e0) at /export/gnu/import/git/gcc/gcc/gimplify.c:5353 #13 0x00d53b80 in gimplify_and_add (seq_p=0x7fffc6e0, t=0x755cd3a0) at /export/gnu/import/git/gcc/gcc/gimplify.c:384 #14 gimplify_expr (expr_p=0x755cc4f0, pre_p=pre_p@entry=0x7fffcfa0, post_p=optimized out, post_p@entry=0x0, gimple_test_f=gimple_test_f@entry=0xd40450 is_gimple_stmt(tree), fallback=fallback@entry=0) at /export/gnu/import/git/gcc/gcc/gimplify.c:7766 #15 0x00d5df5b in gimplify_stmt (stmt_p=optimized out, seq_p=seq_p@entry=0x7fffcfa0) at /export/gnu/import/git/gcc/gcc/gimplify.c:5353 #16 0x00d543f4 in gimplify_statement_list (pre_p=0x7fffcfa0, expr_p=0x755c39e0) at /export/gnu/import/git/gcc/gcc/gimplify.c:1405 #17 gimplify_expr (expr_p=0x755c39e0, pre_p=pre_p@entry=0x7fffcfa0, post_p=optimized out, post_p@entry=0x0, gimple_test_f=gimple_test_f@entry=0xd40450 is_gimple_stmt(tree), fallback=fallback@entry=0) at /export/gnu/import/git/gcc/gcc/gimplify.c:7844 #18 0x00d5df5b in gimplify_stmt (stmt_p=optimized out, seq_p=seq_p@entry=0x7fffcfa0) at /export/gnu/import/git/gcc/gcc/gimplify.c:5353 #19 0x00d603e9 in gimplify_bind_expr (expr_p=expr_p@entry=0x755c8798, ---Type return to continue, or q return to quit--- pre_p=pre_p@entry=0x7fffd780) at /export/gnu/import/git/gcc/gcc/gimplify.c:1072 #20 0x00d538a5 in gimplify_expr (expr_p=0x755c8798, pre_p=pre_p@entry=0x7fffd780, post_p=optimized out, post_p@entry=0x0, gimple_test_f=gimple_test_f@entry=0xd40450 is_gimple_stmt(tree), fallback=fallback@entry=0) at /export/gnu/import/git/gcc/gcc/gimplify.c:7626 #21 0x00d5df5b in gimplify_stmt (stmt_p=stmt_p@entry=0x755c8798, seq_p=seq_p@entry=0x7fffd780) at /export/gnu/import/git/gcc/gcc/gimplify.c:5353 #22 0x00d61f4b in gimplify_body (fndecl=fndecl@entry=0x755c8700, do_parms=do_parms@entry=true) at /export/gnu/import/git/gcc/gcc/gimplify.c:8536
[Bug middle-end/59309] FAIL: c-c++-common/cilk-plus/CK/spawnee_inline.c -g -fcilkplus (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59309
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
CC||bviyer at gmail dot com
--- Comment #2 from H.J. Lu hjl.tools at gmail dot com ---
There are
/* This should give the number of parameters. */
total_args = list_length (new_args);
arg_array = XNEWVEC (tree, total_args);
ii_args = new_args;
for (ii = 0; ii total_args; ii++)
{
arg_array[ii] = TREE_VALUE (ii_args);
ii_args = TREE_CHAIN (ii_args);
}
TREE_USED (function) = 1;
rest_of_decl_compilation (function, 0, 0);
call1 = cilk_call_setjmp (cfun-cilk_frame_decl);
if (*arg_array == NULL_TREE)
call2 = build_call_expr (function, 0);
else
call2 = build_call_expr_loc_array (EXPR_LOCATION (*spawn_p), function,
total_args, arg_array);
When total_args == 0, XNEWVEC (tree, total_args) doesn't return
NULL and *arg_array will be wrong.
[Bug lto/47334] g++.dg/torture/pr31863.C -O2 -flto FAILs without visibility
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47334 --- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE --- This issue now causes new failures on Solaris 9 with Sun as: FAIL: gcc.dg/atomic/c11-atomic-exec-1.c -O2 -flto (test for excess errors) Excess errors: /vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/atomic/c11-atomic-exec-1.c:81:1 : warning: visibility attribute not supported in this configuration; ignored [-W attributes] lto1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes] FAIL: gcc.dg/atomic/c11-atomic-exec-2.c -O2 -flto (test for excess errors) FAIL: gcc.dg/atomic/c11-atomic-exec-3.c -O2 -flto (test for excess errors) FAIL: gcc.dg/atomic/c11-atomic-exec-4.c -O2 -flto (test for excess errors) Rainer
[Bug middle-end/59310] FAIL: gcc.dg/gomp/openmp-simd-1.c (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59310 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com --- Breakpoint 1, c_parser_omp_simd (loc=loc@entry=9494, parser=parser@entry=0x7590f540, p_name=0x7fffd6a0 I teams distribute simd teams distribute parallel for, mask=mask@entry=20113958316, cclauses=cclauses@entry=0x7fffd640) at /export/gnu/import/git/gcc/gcc/c/c-parser.c:11787 11787 strcat (p_name, simd); (gdb) bt #0 c_parser_omp_simd (loc=loc@entry=9494, parser=parser@entry=0x7590f540, p_name=0x7fffd6a0 I teams distribute simd teams distribute parallel for, mask=mask@entry=20113958316, cclauses=cclauses@entry=0x7fffd640) at /export/gnu/import/git/gcc/gcc/c/c-parser.c:11787 #1 0x006d5c85 in c_parser_omp_for (loc=loc@entry=9494, parser=parser@entry=0x7590f540, p_name=p_name@entry=0x7fffd6a0 I teams distribute simd teams distribute parallel for, mask=20113958316, mask@entry=19568666028, cclauses=cclauses@entry=0x7fffd640) at /export/gnu/import/git/gcc/gcc/c/c-parser.c:11850 #2 0x006ef036 in c_parser_omp_parallel (loc=9494, parser=0x7590f540, p_name=0x7fffd6a0 I teams distribute simd teams distribute parallel for, mask=19568666028, cclauses=0x7fffd640) at /export/gnu/import/git/gcc/gcc/c/c-parser.c:12066 #3 0x006ef745 in c_parser_omp_distribute (loc=loc@entry=9494, parser=parser@entry=0x7590f540, p_name=optimized out, mask=19497362852, mask@entry=19497362592, cclauses=cclauses@entry=0x7fffd640) at /export/gnu/import/git/gcc/gcc/c/c-parser.c:12322 #4 0x006f03c3 in c_parser_omp_teams (loc=loc@entry=9494, parser=parser@entry=0x7590f540, p_name=p_name@entry=0x7fffd6a0 I teams distribute simd teams distribute parallel for, mask=19497362592, mask@entry=139392, cclauses=cclauses@entry=0x7fffd640) at /export/gnu/import/git/gcc/gcc/c/c-parser.c:12395 #5 0x006b1a5c in c_parser_omp_target (context=optimized out, parser=0x7590f540) at /export/gnu/import/git/gcc/gcc/c/c-parser.c:12534 #6 c_parser_pragma (parser=parser@entry=0x7590f540, context=context@entry=pragma_compound) at /export/gnu/import/git/gcc/gcc/c/c-parser.c:9342 #7 0x006e1a07 in c_parser_compound_statement_nostart (parser=0x7590f540) at /export/gnu/import/git/gcc/gcc/c/c-parser.c:4496 ---Type return to continue, or q return to quit--- #8 0x006e258d in c_parser_compound_statement (parser=parser@entry=0x7590f540) at /export/gnu/import/git/gcc/gcc/c/c-parser.c:4358 #9 0x006e5a0b in c_parser_declaration_or_fndef (parser=parser@entry=0x7590f540, fndef_ok=fndef_ok@entry=true, static_assert_ok=static_assert_ok@entry=true, empty_ok=empty_ok@entry=true, nested=nested@entry=false, start_attr_ok=start_attr_ok@entry=true, objc_foreach_object_declaration=objc_foreach_object_declaration@entry=0x0, omp_declare_simd_clauses=...) at /export/gnu/import/git/gcc/gcc/c/c-parser.c:1909 #10 0x006f09d3 in c_parser_external_declaration (parser=0x7590f540) at /export/gnu/import/git/gcc/gcc/c/c-parser.c:1392 #11 0x006f249a in c_parser_translation_unit (parser=optimized out) at /export/gnu/import/git/gcc/gcc/c/c-parser.c:1279 #12 c_parse_file () at /export/gnu/import/git/gcc/gcc/c/c-parser.c:13819 #13 0x007b476c in c_common_parse_file () at /export/gnu/import/git/gcc/gcc/c-family/c-opts.c:1056 #14 0x012075d2 in compile_file () at /export/gnu/import/git/gcc/gcc/toplev.c:547 #15 0x0120c144 in do_compile () at /export/gnu/import/git/gcc/gcc/toplev.c:1893 #16 toplev_main (argc=22, argv=0x7fffdf28) at /export/gnu/import/git/gcc/gcc/toplev.c:1969 #17 0x003cdda21b45 in __libc_start_main () from /lib64/libc.so.6 #18 0x0059b721 in _start () (gdb)
[Bug middle-end/59310] FAIL: gcc.dg/gomp/openmp-simd-1.c (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59310 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC||jakub at redhat dot com --- Comment #2 from H.J. Lu hjl.tools at gmail dot com --- There are char p_name[sizeof (#pragma omp target teams distribute parallel for simd)]; c_parser_consume_token (parser); if (!flag_openmp) /* flag_openmp_simd */ return c_parser_omp_teams (loc, parser, p_name, OMP_TARGET_CLAUSE_MASK, cclauses); But we are appending simd to I teams distribute simd teams distribute parallel for and we overwrite stack allocated for #pragma omp target teams distribute parallel for simd
[Bug c++/59312] New: Incorrect warning defaulted move assignment for ... calls a non-trivial move assignment operator for virtual base ...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59312
Bug ID: 59312
Summary: Incorrect warning defaulted move assignment for ...
calls a non-trivial move assignment operator for
virtual base ...
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: alexander.o.khovansky at yandex dot com
Minimal test case:
#include string
struct A { std::string s; };
struct B : virtual A {};
int main(int argc, char* argv[]) {
B b1, b2;
b2 = b1;
}
This produces warning at line 3:
defaulted move assignment for ‘B’ calls a non-trivial move assignment operator
for virtual base ‘A’ [-Wvirtual-move-assign]
Tested on versions available on gcc.godbolt.org - 4.8.1, 4.9.0 20130909 - with
option -std=c++11.
The standard says the following.
12.8.20:
If the definition of a class X does not explicitly declare a move assignment
operator, one will be implicitly declared as defaulted if and only if
...
— the move assignment operator would not be implicitly defined as deleted.
12.8.23:
A defaulted ... move assignment operator for class X is defined as deleted if X
has:
...
— any direct or indirect virtual base class.
The B class does have virtual base, so it cannot have implicit move assignment
operator.
[Bug rtl-optimization/59311] FAIL: g++.dg/cpp1y/vla-initlist1.C (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59311
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
CC||vmakarov at redhat dot com
Component|c++ |rtl-optimization
--- Comment #4 from H.J. Lu hjl.tools at gmail dot com ---
It looks like a LRA bug on x86. x.ii.212r.ira has
insn/f 202 3 2 2 (set (reg:SI 177)
(reg:SI 2 cx)) 86 {*movsi_internal}
(expr_list:REG_DEAD (reg:SI 2 cx)
(expr_list:REG_CFA_SET_VDRAP (reg:SI 177)
(nil
x.ii.213r.reload has
(insn/f 202 3 2 2 (set (mem/c:SI (plus:SI (reg/f:SI 6 bp)
(const_int -48 [0xffd0])) [0 %sfp+-48 S4 A32])
(reg:SI 2 cx)) 86 {*movsi_internal}
(expr_list:REG_CFA_SET_VDRAP (reg:SI 177)
(nil)))
Should the REG_CFA_SET_VDRAP note be dropped or should
dwarf2out_frame_debug handle
(gdb) call debug_rtx (insn)
(insn/f 202 254 2 2 (set (mem/c:SI (plus:SI (reg/f:SI 6 bp)
(const_int -48 [0xffd0])) [0 %sfp+-48 S4 A32])
(reg:SI 2 cx)) 86 {*movsi_internal}
(expr_list:REG_CFA_SET_VDRAP (reg:SI 177)
(nil)))
(gdb)
in
case REG_CFA_SET_VDRAP:
n = XEXP (note, 0);
if (REG_P (n))
{
dw_fde_ref fde = cfun-fde;
if (fde)
{
gcc_assert (fde-vdrap_reg == INVALID_REGNUM);
if (REG_P (n))
fde-vdrap_reg = dwf_regno (n);
}
}
handled_one = true;
break;
[Bug rtl-optimization/59311] [4.9 Regression] FAIL: g++.dg/cpp1y/vla-initlist1.C (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59311
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
Summary|FAIL: |[4.9 Regression] FAIL:
|g++.dg/cpp1y/vla-initlist1. |g++.dg/cpp1y/vla-initlist1.
|C (test for excess errors) |C (test for excess errors)
--- Comment #5 from H.J. Lu hjl.tools at gmail dot com ---
Disable LRA gives me
(insn/f 202 3 2 2 (set (mem/c:SI (plus:SI (reg/f:SI 6 bp)
(const_int -48 [0xffd0])) [0 %sfp+-24 S4 A32])
(reg:SI 2 cx)) 86 {*movsi_internal}
(expr_list:REG_CFA_SET_VDRAP (mem/c:SI (plus:SI (reg/f:SI 6 bp)
(const_int -48 [0xffd0])) [0 %sfp+-24 S4 A32])
(nil)))
It looks like LRA forgets to update NOTE.
[Bug fortran/59313] New: gfortran.dg/erf_3.F90 FAILs on Solaris/SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59313 Bug ID: 59313 Summary: gfortran.dg/erf_3.F90 FAILs on Solaris/SPARC Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org Host: sparc*-sun-solaris2.* Target: sparc*-sun-solaris2.* Build: sparc*-sun-solaris2.* The new gfortran.dg/erf_3.F90 test FAILs on Solaris/SPARC in different ways: * On Solaris 9, it fails to link: FAIL: gfortran.dg/erf_3.F90 -O0 (test for excess errors) Excess errors: Undefined first referenced symbol in file erfl/var/tmp//ccYCQomy.o erfcl /var/tmp//ccYCQomy.o _gfortran_erfc_scaled_r16 /var/tmp//ccYCQomy.o frexpl /var/tmp//ccYCQomy.o scalbnl /var/tmp//ccYCQomy.o ld: fatal: Symbol referencing errors. No output written to ./erf_3.exe WARNING: gfortran.dg/erf_3.F90 -O0 compilation failed to produce executable * On Solaris 10 and 11, I get an execution failure instead: 0.000 0.000 0.000 0.000 0.000 6167208123267181. Program aborted. Backtrace: #0 0xFEA1A0BF In gdb, I find Program received signal SIGABRT, Aborted. [Switching to Thread 1 (LWP 1)] 0xff0da440 in _lwp_kill () from /lib/libc.so.1 (gdb) where #0 0xff0da440 in _lwp_kill () from /lib/libc.so.1 #1 0xff083d90 in raise () from /lib/libc.so.1 #2 0xff05b59c in abort () from /lib/libc.so.1 #3 0xff21c068 in _gfortrani_sys_abort () at /vol/gcc/src/hg/trunk/local/libgfortran/runtime/error.c:173 #4 0xff2b7a40 in _gfortran_abort () at /vol/gcc/src/hg/trunk/local/libgfortran/intrinsics/abort.c:33 #5 0x00011318 in check (a=0.45653165863355994044362586269156961, b=0.45653165863355994014668559274485783) at /vol/gcc/src/hg/trunk/local/gcc/testsuite/gfortran.dg/erf_3.F90:50 #6 0x0001154c in test () at /vol/gcc/src/hg/trunk/local/gcc/testsuite/gfortran.dg/erf_3.F90:29 #7 0x00012390 in main (argc=1, argv=0xffbff594) at /vol/gcc/src/hg/trunk/local/gcc/testsuite/gfortran.dg/erf_3.F90:43 #8 0x00010cfc in _start () Rainer
[Bug c++/59312] Incorrect warning defaulted move assignment for ... calls a non-trivial move assignment operator for virtual base ...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59312 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- Which document are you looking at? That's not what 12.8/23 in the standard says.
[Bug tree-optimization/59014] [4.7/4.8/4.9 Regression] wrong code at -Os and above on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59014 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|ASSIGNED CC|jakub at gcc dot gnu.org | Resolution|FIXED |--- Assignee|mpolacek at gcc dot gnu.org|jakub at gcc dot gnu.org Target Milestone|4.9.0 |4.7.4 Summary|[4.9 Regression] wrong code |[4.7/4.8/4.9 Regression] |at -Os and above on |wrong code at -Os and above |x86_64-linux-gnu|on x86_64-linux-gnu --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org --- Reopening, as the bug exists also on 4.7/4.8.
[Bug tree-optimization/59014] [4.7/4.8/4.9 Regression] wrong code at -Os and above on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59014 --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 31310 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31310action=edit gcc49-pr59014-test.patch Testcase that reproduces also on 4.8 and 4.7. I'll bootstrap/regtest both patches now on 4.8.
[Bug c++/59314] New: [DR 1054] [C++11] access to volatile through reference should cause load
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59314 Bug ID: 59314 Summary: [DR 1054] [C++11] access to volatile through reference should cause load Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org I believe the information at http://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Volatiles.html is true of C++03 but not C++11. The relevant change is http://open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1054 and so the last line below should undergo lvalue-to-rvalue conversion and so should access the volatile: volatile int i=0; volatile int r = i; r;
[Bug c/59310] FAIL: gcc.dg/gomp/openmp-simd-1.c (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59310 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-11-27 CC||jakub at gcc dot gnu.org Component|middle-end |c Target Milestone|--- |4.9.0 Ever confirmed|0 |1
[Bug middle-end/58723] [4.9 Regression] ICE in lto_output_edge, at lto-cgraph.c:300 for OpenMP's simd reduction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58723 --- Comment #16 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Wed Nov 27 15:18:23 2013 New Revision: 205447 URL: http://gcc.gnu.org/viewcvs?rev=205447root=gccview=rev Log: 2013-11-27 Richard Biener rguent...@suse.de PR middle-end/58723 * cgraphbuild.c (build_cgraph_edges): Do not build edges for internal calls. (rebuild_cgraph_edges): Likewise. * ipa-inline-analysis.c (estimate_function_body_sizes): Skip internal calls. * tree-inline.c (estimate_num_insns): Estimate size of internal calls as 0. (gimple_expand_calls_inline): Do not try inline-expanding internal calls. * lto-streamer-in.c (input_cfg): Stream loop safelen, force_vect and simduid. (input_struct_function_base): Stream has_force_vect_loops and has_simduid_loops. (input_function): Adjust. * lto-streamer-out.c (output_cfg): Stream loop safelen, force_vect and simduid. (output_struct_function_base): Stream has_force_vect_loops and has_simduid_loops. Modified: trunk/gcc/ChangeLog trunk/gcc/cgraphbuild.c trunk/gcc/ipa-inline-analysis.c trunk/gcc/lto-streamer-in.c trunk/gcc/lto-streamer-out.c trunk/gcc/tree-inline.c
[Bug c++/59315] New: [4.9 regression] g++.dg/warn/Wunused-3.C FAILs on Solaris
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59315 Bug ID: 59315 Summary: [4.9 regression] g++.dg/warn/Wunused-3.C FAILs on Solaris Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org Host: *-*-solaris2.* Target: *-*-solaris2.* Build: *-*-solaris2.* Since ca. 20131104 (r204350), g++.dg/warn/Wunused-3.C FAILs on Solaris: FAIL: g++.dg/warn/Wunused-3.C -std=gnu++98 (test for excess errors) Excess errors: /vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.dg/warn/Wunused-3.C:11:16: warning: 'dummy' defined but not used [-Wunused-variable] FAIL: g++.dg/warn/Wunused-3.C -std=gnu++11 (test for excess errors) Rainer
[Bug rtl-optimization/57410] [4.9 Regression] ICE: in emit_spill_move, at lra-constraints.c:863 with -fpeel-loops and uninitialised variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57410 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Likely fixed by r199764 (r199763 fails, r199769 works, no other commits that could affect i?86/x86_64), likely introduced by r199298 (works r199200, fails r199300). Vlad, is there anything needed but to include the testcase into the testsuite (will test it in the next bootstrap/regtest cycle)?
[Bug c/59316] New: gcc.dg/atomic/c11-atomic-exec-5.c FAILs on Solaris/SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59316 Bug ID: 59316 Summary: gcc.dg/atomic/c11-atomic-exec-5.c FAILs on Solaris/SPARC Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: jsm28 at gcc dot gnu.org Host: sparc*-sun-solaris2.* Target: sparc*-sun-solaris2.* Build: sparc*-sun-solaris2.* The new gcc.dg/atomic/c11-atomic-exec-5.c tests FAILs on Solaris/SPARC: FAIL: gcc.dg/atomic/c11-atomic-exec-5.c -O0 execution test FAIL: gcc.dg/atomic/c11-atomic-exec-5.c -O1 execution test FAIL: gcc.dg/atomic/c11-atomic-exec-5.c -O2 execution test FAIL: gcc.dg/atomic/c11-atomic-exec-5.c -O3 -fomit-frame-pointer execution test FAIL: gcc.dg/atomic/c11-atomic-exec-5.c -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: gcc.dg/atomic/c11-atomic-exec-5.c -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: gcc.dg/atomic/c11-atomic-exec-5.c -O3 -g execution test FAIL: gcc.dg/atomic/c11-atomic-exec-5.c -Os execution test FAIL: gcc.dg/atomic/c11-atomic-exec-5.c -O2 -flto -flto-partition=none execution test FAIL: gcc.dg/atomic/c11-atomic-exec-5.c -O2 -flto execution test E.g. float_add_invalid (a) 688 pass, 54 fail; (b) 9258 pass, 0 fail float_add_invalid_prev (a) 758 pass, 86 fail; (b) 9156 pass, 0 fail float_add_overflow (a) 851 pass, 0 fail; (b) 3221 pass, 5928 fail float_add_overflow_prev (a) 1324 pass, 0 fail; (b) 3128 pass, 5548 fail float_add_overflow_double (a) 842 pass, 0 fail; (b) 2365 pass, 6793 fail float_add_overflow_long_double (a) 3053 pass, 0 fail; (b) 3673 pass, 3274 fail float_add_inexact (a) 1508 pass, 0 fail; (b) 3155 pass, 5337 fail float_add_inexact_int (a) 3865 pass, 0 fail; (b) 4557 pass, 1578 fail float_preinc_inexact (a) 910 pass, 0 fail; (b) 2989 pass, 6101 fail float_postinc_inexact (a) 4548 pass, 0 fail; (b) 4315 pass, 1137 fail long_add_float_inexact (a) 1723 pass, 0 fail; (b) 4987 pass, 3290 fail float_postinc_inexact (a) 4548 pass, 0 fail; (b) 4315 pass, 1137 fail long_add_float_inexact (a) 1723 pass, 0 fail; (b) 4987 pass, 3290 fail complex_float_add_overflow (a) 3787 pass, 0 fail; (b) 3697 pass, 2516 fail float_sub_invalid (a) 849 pass, 72 fail; (b) 9079 pass, 0 fail float_sub_overflow (a) 1066 pass, 0 fail; (b) 3317 pass, 5617 fail float_sub_inexact (a) 1930 pass, 0 fail; (b) 3466 pass, 4604 fail float_sub_inexact_int (a) 1709 pass, 0 fail; (b) 4165 pass, 4126 fail float_predec_inexact (a) 1421 pass, 0 fail; (b) 4134 pass, 4445 fail float_postdec_inexact (a) 1577 pass, 0 fail; (b) 4062 pass, 4361 fail long_sub_float_inexact (a) 2993 pass, 0 fail; (b) 4758 pass, 2249 fail complex_float_sub_overflow (a) 4578 pass, 0 fail; (b) 4540 pass, 882 fail float_mul_invalid (a) 617 pass, 433 fail; (b) 8950 pass, 0 fail float_mul_overflow (a) 1585 pass, 0 fail; (b) 2798 pass, 5617 fail float_mul_underflow (a) 952 pass, 0 fail; (b) 4818 pass, 4230 fail float_mul_inexact (a) 2580 pass, 0 fail; (b) 3755 pass, 3665 fail float_mul_inexact_int (a) 2901 pass, 0 fail; (b) 4334 pass, 2765 fail long_mul_float_inexact (a) 4301 pass, 0 fail; (b) 4530 pass, 1169 fail complex_float_mul_overflow (a) 3442 pass, 0 fail; (b) 3017 pass, 3541 fail float_div_invalid_divbyzero (a) 2866 pass, 759 fail; (b) 4031 pass, 2344 fail float_div_overflow (a) 2648 pass, 0 fail; (b) 2935 pass, 4417 fail float_div_underflow (a) 2759 pass, 0 fail; (b) 3439 pass, 3802 fail float_div_inexact (a) 2190 pass, 0 fail; (b) 2448 pass, 5362 fail float_div_inexact_int (a) 2844 pass, 0 fail; (b) 3331 pass, 3825 fail float_div_inexact (a) 2190 pass, 0 fail; (b) 2448 pass, 5362 fail float_div_inexact_int (a) 2844 pass, 0 fail; (b) 3331 pass, 3825 fail int_div_float_inexact (a) 2078 pass, 0 fail; (b) 3967 pass, 3955 fail complex_float_div_overflow (a) 3532 pass, 0 fail; (b) 2754 pass, 3714 fail double_add_invalid (a) 2894 pass, 954 fail; (b) 6152 pass, 0 fail double_add_overflow (a) 3938 pass, 0 fail; (b) 4331 pass, 1731 fail double_add_overflow_long_double (a) 2723 pass, 0 fail; (b) 2546 pass, 4731 fail double_add_inexact (a) 4993 pass, 0 fail; (b) 4996 pass, 11 fail double_add_inexact_int (a) 4917 pass, 0 fail; (b) 4867 pass, 216 fail double_preinc_inexact (a) 3130 pass, 0 fail; (b) 2941 pass, 3929 fail double_postinc_inexact (a) 3530 pass, 0 fail; (b) 2498 pass, 3972 fail long_long_add_double_inexact (a) 3311 pass, 0 fail; (b) 3933 pass, 2756 fail complex_double_add_overflow (a) 5698 pass, 0 fail; (b) 4288 pass, 14 fail double_sub_invalid (a) 1965 pass, 1597 fail; (b) 6438 pass, 0 fail double_sub_overflow (a) 2852 pass, 0 fail; (b) 2972 pass, 4176 fail double_sub_inexact (a) 3469 pass, 0 fail; (b) 3651 pass, 2880 fail double_sub_inexact_int (a) 4829 pass, 0 fail; (b) 4679 pass, 492 fail
[Bug c/59316] gcc.dg/atomic/c11-atomic-exec-5.c FAILs on Solaris/SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59316 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug c/59316] gcc.dg/atomic/c11-atomic-exec-5.c FAILs on Solaris/SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59316 ktkachov at gcc dot gnu.org changed: What|Removed |Added Target|sparc*-sun-solaris2.* |sparc*-sun-solaris2.*, ||arm-none-linux-gnueabihf CC||ktkachov at gcc dot gnu.org --- Comment #1 from ktkachov at gcc dot gnu.org --- Fails on arm linux as well.
[Bug middle-end/58723] [4.9 Regression] ICE in lto_output_edge, at lto-cgraph.c:300 for OpenMP's simd reduction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58723 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #17 from Richard Biener rguenth at gcc dot gnu.org --- Fixed. The OMP_CLAUSE issue remains but is really a separate thing.
[Bug libstdc++/59237] FAIL: ext/random/hypergeometric_distribution/operators/values.cc (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59237 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.0 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com --- Fixed as of revision 205444: http://gcc.gnu.org/ml/gcc-testresults/2013-11/msg02030.html
[Bug middle-end/57904] [4.9 Regression] Bogus(?) invokes undefined behavior warning with Fortran's finalization wrapper (gfortran.dg/class_48.f90)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57904 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org --- We have: bb 2: ubound.0_3 = 0; size.1_4 = ubound.0_3 + 1; size.1_5 = MAX_EXPR size.1_4, 0; _6 = size.1_5 * 4; _7 = (character(kind=4)) _6; _8 = MAX_EXPR _7, 1; sizes_9 = __builtin_malloc (_8); size.3_10 = MAX_EXPR ubound.0_3, 0; _11 = size.3_10 * 4; _12 = (character(kind=4)) _11; _13 = MAX_EXPR _12, 1; strides_14 = __builtin_malloc (_13); MEM[(integer(kind=4)[0:D.1906] *)sizes_9][0] = 1; if (ubound.0_3 0) goto bb 3; else goto bb 6; bb 3: idx_50 = 1; bb 4: # idx_15 = PHI 1(3), idx_25(5) _16 = idx_15 + -1; _17 = array_1(D)-dim[_16].stride; MEM[(integer(kind=4)[0:D.1900] *)strides_14][_16] = _17; _18 = MEM[(integer(kind=4)[0:D.1906] *)sizes_9][_16]; _19 = array_1(D)-dim[_16].ubound; _20 = array_1(D)-dim[_16].lbound; _21 = _19 - _20; _22 = _21 + 1; _23 = MAX_EXPR _22, 0; _24 = _18 * _23; MEM[(integer(kind=4)[0:D.1906] *)sizes_9][idx_15] = _24; idx_25 = idx_15 + 1; if (ubound.0_3 == idx_15) goto bb 6; else goto bb 5; bb 5: goto bb 4; and the warning is on the header(4) latch(5) loop. The warning is correct, the loop would execute 0x times and _16 = idx_15 + -1 would invoke undefined behavior on the last iteration, but still the warning is undesirable because it is on a dead loop. Only during IPA optimizations the original _15 = array_14(D)-dtype; ubound.0_16 = _15 7; was optimized into: _2 = 344; ubound.0_3 = _2 7; and only copyprop2 pass optimizes that into: ubound.0_3 = 0; but nothing yet propagated it into the condition and folded the condition, cunrolli runs simply too early. I guess scheduling there a forwprop pass in between copyprop2 and cunrolli would fix this, but don't know how expensive it is. Or we could avoid emitting the warning right away, but add there __builtin_warning or similar into the loop, and only warn later on after some cleanup passes that can actually figure out what code is dead.
[Bug c++/58647] [4.7/4.8/4.9 Regression] ICE with function pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58647 --- Comment #3 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Wed Nov 27 15:55:18 2013 New Revision: 205449 URL: http://gcc.gnu.org/viewcvs?rev=205449root=gccview=rev Log: /cp 2013-11-27 Paolo Carlini paolo.carl...@oracle.com PR c++/58647 * semantics.c (cxx_eval_constant_expression, [COMPONENT_REF]): Handle function COMPONENT_REFs. /testsuite 2013-11-27 Paolo Carlini paolo.carl...@oracle.com PR c++/58647 * g++.dg/parse/crash66.C: New. Added: trunk/gcc/testsuite/g++.dg/parse/crash66.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog
[Bug target/59305] [4.9 Regression] gcc.dg/atomic/c11-atomic-exec-5.c fails with WARNING: program timed out on x86_64-apple-darwin13
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59305 --- Comment #2 from joseph at codesourcery dot com joseph at codesourcery dot com --- For powerpc see: http://gcc.gnu.org/ml/gcc/2013-11/msg00131.html - the failures indicate the architecture maintainers have not yet added this hook.
[Bug c++/58647] [4.7/4.8 Regression] ICE with function pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58647 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|4.7.4 |4.9.0 Summary|[4.7/4.8/4.9 Regression]|[4.7/4.8 Regression] ICE |ICE with function pointer |with function pointer --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com --- Fixed for 4.9.0. The issue doesn't affect release mode, thus I'm not fiddling with the release branches.
[Bug middle-end/57904] [4.9 Regression] Bogus(?) invokes undefined behavior warning with Fortran's finalization wrapper (gfortran.dg/class_48.f90)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57904 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added CC||Joost.VandeVondele at mat dot ethz ||.ch --- Comment #6 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- this is the same/similar issue as PR58746, which also triggers this warning but even without -m32 on x86_64.
[Bug c/59316] gcc.dg/atomic/c11-atomic-exec-5.c FAILs on Solaris/SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59316 --- Comment #2 from joseph at codesourcery dot com joseph at codesourcery dot com --- See: http://gcc.gnu.org/ml/gcc/2013-11/msg00131.html - the failures indicate the architecture maintainers have not yet added this hook (for either SPARC, or ARM, or any non-x86 architecture).
[Bug rtl-optimization/59317] New: [4.9 Regression] [LRA,MIPS] ICE: in check_rtl, at lra.c (insn does not satisfy constraints)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59317
Bug ID: 59317
Summary: [4.9 Regression] [LRA,MIPS] ICE: in check_rtl, at
lra.c (insn does not satisfy constraints)
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: robert.suchanek at imgtec dot com
CC: vmakarov at redhat dot com
Created attachment 31311
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31311action=edit
testcase
It appears that the change in revision r205141 throws an ICE in the regression
with LRA enabled for mips16.
I have attached a narrowed testcase, to reproduce it needs to be compiled with
-O2 -mips32 -mips16.
ia64-1_testcase.c: In function ‘main’:
ia64-1_testcase.c:81:1: internal compiler error: in check_rtl, at lra.c:2036
}
^
0x821cbc check_rtl
/scratch/mips_trunk/src/gcc/gcc/lra.c:2036
0x825eb4 lra(_IO_FILE*)
/scratch/mips_trunk/src/gcc/gcc/lra.c:2414
0x7e302e do_reload
/scratch/mips_trunk/src/gcc/gcc/ira.c:5452
0x7e302e rest_of_handle_reload
/scratch/mips_trunk/src/gcc/gcc/ira.c:5581
0x7e302e execute
/scratch/mips_trunk/src/gcc/gcc/ira.c:5610
The LRA generates the following piece of RTL that fails at check_rtl():
(insn 265 54 267 2 (set (reg:SI 8 $8 [339])
(const:SI (unspec:SI [
(const_int 0 [0])
] UNSPEC_GP))) ia64-1_testcase.c:49 295 {*movsi_mips16}
(nil))
This does not satisfy the operand’s constrains in movmode_mips16 pattern.
The ICE appears to be triggered because of ALL_REGS assigned to new pseudos
generated and the pseudo data gets expanded but I do not know how to fix it
without breaking PR59133 again.
[Bug c/59316] gcc.dg/atomic/c11-atomic-exec-5.c FAILs on Solaris/SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59316 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org --- Comment #3 from Rainer Orth ro at gcc dot gnu.org --- Ah, I missed that. Perhaps a comment to that effect could be added to the testcase? Cc'ing Eric, since I'm not sure I'm up to implementing that for SPARC, although the OpenSolaris libm sources seem to be helpful. Thanks. Rainer
[Bug rtl-optimization/57410] [4.9 Regression] ICE: in emit_spill_move, at lra-constraints.c:863 with -fpeel-loops and uninitialised variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57410 --- Comment #3 from Vladimir Makarov vmakarov at gcc dot gnu.org --- Author: vmakarov Date: Wed Nov 27 16:30:48 2013 New Revision: 205451 URL: http://gcc.gnu.org/viewcvs?rev=205451root=gccview=rev Log: 2013-11-27 Vladimir Makarov vmaka...@redhat.com PR rtl-optimization/57410 * gcc.target/i386/pr57410.c: New. Added: trunk/gcc/testsuite/gcc.target/i386/pr57410.c
[Bug c/59316] gcc.dg/atomic/c11-atomic-exec-5.c FAILs on Solaris/SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59316 --- Comment #4 from joseph at codesourcery dot com joseph at codesourcery dot com --- Feel free to add a comment mentioning the hook targets need to define for this test to pass.
[Bug rtl-optimization/57410] [4.9 Regression] ICE: in emit_spill_move, at lra-constraints.c:863 with -fpeel-loops and uninitialised variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57410 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed then.
[Bug middle-end/58125] [4.9 Regression] ICE: in operator[], at vec.h:827 with -fno-inline-small-functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58125 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org --- The testcase stopped reproducing with r202100. But from quick look at the #c5 patch and ipa-inline-analysis.c it doesn't seem to be applied. Honza?
[Bug tree-optimization/59014] [4.7/4.8/4.9 Regression] wrong code at -Os and above on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59014 --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Wed Nov 27 17:03:27 2013 New Revision: 205454 URL: http://gcc.gnu.org/viewcvs?rev=205454root=gccview=rev Log: PR tree-optimization/59014 * gcc.c-torture/execute/pr59014-2.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr59014-2.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/59014] [4.7/4.8/4.9 Regression] wrong code at -Os and above on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59014 --- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Wed Nov 27 17:05:21 2013 New Revision: 205456 URL: http://gcc.gnu.org/viewcvs?rev=205456root=gccview=rev Log: Backported from mainline 2013-11-26 Jakub Jelinek ja...@redhat.com PR tree-optimization/59014 * tree-vrp.c (register_edge_assert_for_1): Don't look through conversions from non-integral types or through narrowing conversions. * gcc.c-torture/execute/pr59014.c: New test. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.c-torture/execute/pr59014.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/testsuite/ChangeLog branches/gcc-4_8-branch/gcc/tree-vrp.c
[Bug tree-optimization/59014] [4.7/4.8/4.9 Regression] wrong code at -Os and above on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59014 --- Comment #13 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Wed Nov 27 17:06:44 2013 New Revision: 205457 URL: http://gcc.gnu.org/viewcvs?rev=205457root=gccview=rev Log: PR tree-optimization/59014 * gcc.c-torture/execute/pr59014-2.c: New test. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.c-torture/execute/pr59014-2.c Modified: branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug c++/59131] Compiler segfaults while generating code to save local variables in transactional section
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59131 Aldy Hernandez aldyh at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|2013-11-14 00:00:00 |2013-11-27 Ever confirmed|0 |1 --- Comment #3 from Aldy Hernandez aldyh at gcc dot gnu.org --- Confirmed...works in mainline. Anyone care to bisect this and see which patch fixed the problem?
[Bug c++/59131] Compiler segfaults while generating code to save local variables in transactional section
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59131 --- Comment #4 from Aldy Hernandez aldyh at gcc dot gnu.org --- FWIW, also works on 4.8.
[Bug target/56788] _mm_frcz_sd and _mm_frcz_ss ignore their second argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56788 --- Comment #15 from uros at gcc dot gnu.org --- Author: uros Date: Wed Nov 27 18:07:22 2013 New Revision: 205458 URL: http://gcc.gnu.org/viewcvs?rev=205458root=gccview=rev Log: PR target/56788 * gcc.target/i386/xop-frczX.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/xop-frczX.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug target/59316] gcc.dg/atomic/c11-atomic-exec-5.c FAILs on Solaris/SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59316 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-11-27 Component|c |target Ever confirmed|0 |1
[Bug c++/59318] New: ICE on invalid C++ code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59318
Bug ID: 59318
Summary: ICE on invalid C++ code
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
[hjl@gnu-6 pr59311]$ cat x.ii
#pragma GCC visibility push(default)
namespace std
{
templateclass _E
class initializer_list
{
public:
typedef _E value_type;
};
}
#pragma GCC visibility pop
struct A
{
int i;
A(std::initializer_listint) { }
};
int x = 4;
int main(int argc, char **argv)
{
{ int i[x] = { 42, 42, 42, 42 }; }
{
A a[x] = { argc };
if (a[1].i != 42)
__builtin_abort ();
}
}
[hjl@gnu-6 pr59311]$ make x.s
/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/ -std=c++1y -m32 -S x.ii
x.ii: In function ‘int main(int, char**)’:
x.ii:28:21: error: conversion from ‘int’ to non-scalar type ‘A’ requested
A a[x] = { argc };
^
x.ii:28:21: internal compiler error: Segmentation fault
0xd1bbee crash_signal
/export/gnu/import/git/gcc/gcc/toplev.c:336
0x57d296 contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
/export/gnu/import/git/gcc/gcc/tree.h:2821
0x593382 convert_like_real
/export/gnu/import/git/gcc/gcc/cp/call.c:6059
0x596b0b build_over_call
/export/gnu/import/git/gcc/gcc/cp/call.c:6947
0x592ae7 convert_like_real
/export/gnu/import/git/gcc/gcc/cp/call.c:5964
0x59363e convert_like_real
/export/gnu/import/git/gcc/gcc/cp/call.c:6089
0x59f55f perform_implicit_conversion_flags(tree_node*, tree_node*, int, int)
/export/gnu/import/git/gcc/gcc/cp/call.c:9023
0x59f5f1 perform_implicit_conversion(tree_node*, tree_node*, int)
/export/gnu/import/git/gcc/gcc/cp/call.c:9035
0x72d132 ocp_convert(tree_node*, tree_node*, int, int, int)
/export/gnu/import/git/gcc/gcc/cp/cvt.c:861
0x73c92f expand_default_init
/export/gnu/import/git/gcc/gcc/cp/init.c:1605
0x73d40c expand_aggr_init_1
/export/gnu/import/git/gcc/gcc/cp/init.c:1774
0x73c2cc build_aggr_init(tree_node*, tree_node*, int, int)
/export/gnu/import/git/gcc/gcc/cp/init.c:1525
0x7439a9 build_vec_init(tree_node*, tree_node*, tree_node*, bool, int, int)
/export/gnu/import/git/gcc/gcc/cp/init.c:3737
0x73c10c build_aggr_init(tree_node*, tree_node*, int, int)
/export/gnu/import/git/gcc/gcc/cp/init.c:1506
0x5bc2b5 build_aggr_init_full_exprs
/export/gnu/import/git/gcc/gcc/cp/decl.c:5583
0x5bce86 check_initializer
/export/gnu/import/git/gcc/gcc/cp/decl.c:5719
0x5c01a2 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
/export/gnu/import/git/gcc/gcc/cp/decl.c:6388
0x6db07f cp_parser_init_declarator
/export/gnu/import/git/gcc/gcc/cp/parser.c:16743
0x6d2198 cp_parser_simple_declaration
/export/gnu/import/git/gcc/gcc/cp/parser.c:11134
0x6d1f88 cp_parser_block_declaration
/export/gnu/import/git/gcc/gcc/cp/parser.c:11015
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.
make: *** [x.s] Error 1
[hjl@gnu-6 pr59311]$
[Bug debug/59319] New: gcc does not emit DW_AT_friend or DW_TAG_friend
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59319 Bug ID: 59319 Summary: gcc does not emit DW_AT_friend or DW_TAG_friend Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: tromey at gcc dot gnu.org I couldn't find a way to make GCC emit DW_TAG_friend or DW_AT_friend. A quick grep through dwarf2out.c seems to confirm this. I think these are needed for gdb to properly implement ADL, though I don't have an example ready.
[Bug rtl-optimization/59311] [4.9 Regression] LRA fails to update REG_CFA_SET_VDRAP note
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59311
--- Comment #6 from H.J. Lu hjl.tools at gmail dot com ---
A small testcase compiled with -std=c++1y -m32:
--
namespace std
{
typedef long unsigned int size_t;
}
namespace std
{
templateclass _E
class initializer_list
{
public:
typedef size_t size_type;
typedef const _E* iterator;
typedef const _E* const_iterator;
private:
iterator _M_array;
size_type _M_len;
constexpr initializer_list(const_iterator __a, size_type __l)
: _M_array(__a), _M_len(__l) { }
};
}
struct A
{
int i;
A(std::initializer_listint) { }
A(int i): i{i} { }
};
int x = 4;
int main(int argc, char **argv)
{
{ int i[x] = { 42, 42, 42, 42 }; }
{
A a[x] = { argc };
if (a[1].i != 42)
__builtin_abort ();
}
}
---
[Bug regression/59320] New: ftree-vrp breaks simple loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59320
Bug ID: 59320
Summary: ftree-vrp breaks simple loops
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: regression
Assignee: unassigned at gcc dot gnu.org
Reporter: astra at ionic dot at
Created attachment 31312
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31312action=edit
File which triggers the bug by using a specific line drawing style.
With -O1 there is no problem.
With -O1 -ftree-vrp and with -O2 it fails to compile the following loop
properly. instead of running the loop 4 times it runs until it segfaults
(ilnd always returns 1, resulting in 04 = 1 as well as 305424 = 1
when showing ilnd in a printf.
With -O2 -fno-tree-vrp it runs properly.
--
int il, nd;
nd = 4;
for (il =0; ilnd; il ++) {
if (fl[il] != 0.) {
}
}
--
(Source: xfig 3.2.5c, w_drawprim.c:1401)
gcc version 4.8.2 20131017 (Red Hat 4.8.2-1) (GCC)
fedora 14 does not has that issue, but i do not know the specific gcc-version
which was used then.
[Bug rtl-optimization/59311] [4.9 Regression] LRA fails to update REG_CFA_SET_VDRAP note
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59311
--- Comment #7 from H.J. Lu hjl.tools at gmail dot com ---
LRA calls
(gdb) bt
#0 elimination_costs_in_insn (insn=0x71a30ee8)
at /export/gnu/src/gcc/gcc/gcc/reload1.c:3694
#1 0x00d0419f in calculate_elim_costs_all_insns ()
at /export/gnu/src/gcc/gcc/gcc/reload1.c:1635
#2 0x00bcb88e in ira_costs ()
at /export/gnu/src/gcc/gcc/gcc/ira-costs.c:2100
#3 0x00bc3851 in ira_build ()
at /export/gnu/src/gcc/gcc/gcc/ira-build.c:3426
#4 0x00bba081 in ira (f=0x0) at /export/gnu/src/gcc/gcc/gcc/ira.c:5306
#5 0x00bba5ea in rest_of_handle_ira ()
at /export/gnu/src/gcc/gcc/gcc/ira.c:5537
#6 0x00bba635 in (anonymous namespace)::pass_ira::execute (
this=0x2036920) at /export/gnu/src/gcc/gcc/gcc/ira.c:5566
#7 0x00c9e61a in execute_one_pass (
pass=opt_pass* 0x2036920 ira(218))
at /export/gnu/src/gcc/gcc/gcc/passes.c:2215
#8 0x00c9e831 in execute_pass_list (
pass=opt_pass* 0x2036920 ira(218))
at /export/gnu/src/gcc/gcc/gcc/passes.c:2268
#9 0x00c9e862 in execute_pass_list (
pass=opt_pass* 0x20358a0 *rest_of_compilation(-1))
at /export/gnu/src/gcc/gcc/gcc/passes.c:2269
#10 0x00982df2 in expand_function (
---Type return to continue, or q return to quit---
node=cgraph_node* 0x71a0c7b0 main)
at /export/gnu/src/gcc/gcc/gcc/cgraphunit.c:1763
#11 0x009835fc in output_in_order ()
at /export/gnu/src/gcc/gcc/gcc/cgraphunit.c:1958
#12 0x00983c07 in compile ()
at /export/gnu/src/gcc/gcc/gcc/cgraphunit.c:2198
#13 0x00983d8c in finalize_compilation_unit ()
at /export/gnu/src/gcc/gcc/gcc/cgraphunit.c:2280
#14 0x0070ed36 in cp_write_global_declarations ()
at /export/gnu/src/gcc/gcc/gcc/cp/decl2.c:4431
#15 0x00d88f3e in compile_file ()
Now INSN comes:
(gdb) call debug_rtx (insn)
(insn/f 184 3 2 2 (set (nil)
(reg:SI 2 cx)) 86 {*movsi_internal}
(expr_list:REG_DEAD (reg:SI 2 cx)
(expr_list:REG_CFA_SET_VDRAP (reg:SI 171)
(nil
(gdb)
The iEG_CFA_SET_VDRAP note is out of sync.
[Bug regression/59320] ftree-vrp breaks simple loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59320 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- What is the size of fl ?
[Bug regression/59320] ftree-vrp breaks simple loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59320 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to Andrew Pinski from comment #1) What is the size of fl ? What I mean are you going past the bounds of the array fl?
[Bug rtl-optimization/59311] [4.9 Regression] LRA fails to update REG_CFA_SET_VDRAP note
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59311 --- Comment #8 from H.J. Lu hjl.tools at gmail dot com --- /* Terminate the search in check_eliminable_occurrences at this point. */ *recog_data.operand_loc[i] = 0; sets DEST to NULL.
[Bug regression/59320] ftree-vrp breaks simple loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59320
--- Comment #3 from David Kaufmann astra at ionic dot at ---
(In reply to Andrew Pinski from comment #2)
(In reply to Andrew Pinski from comment #1)
What is the size of fl ?
What I mean are you going past the bounds of the array fl?
yes, i am, but if the comparison would work it would not.
from the source file:
--
static int ndash_dot = 4;
static float dash_dot[4] = { 1., 0.5, 0., 0.5 };
int il, nd;
float *fl;
fl=dash_dot;
nd=ndash_dot;
--
there is no other position where this is modified.
this code produces the output following it:
--
for (il =0; ilnd; il ++) {
printf(il: %i, nd: %i, ilnd: %i\n, il, nd, ilnd);
if (fl[il] != 0.) {
}
}
--
Output:
--
il: 0, nd: 4, ilnd: 1
il: 1, nd: 4, ilnd: 1
il: 2, nd: 4, ilnd: 1
il: 3, nd: 4, ilnd: 1
il: 4, nd: 4, ilnd: 1
il: 5, nd: 4, ilnd: 1
il: 6, nd: 4, ilnd: 1
il: 7, nd: 4, ilnd: 1
...
and so on.
--
[Bug rtl-optimization/59311] [4.9 Regression] LRA fails to update REG_CFA_SET_VDRAP note
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59311 --- Comment #9 from H.J. Lu hjl.tools at gmail dot com --- remove_pseudos in lra-spills.c failed to handle REG_CFA_SET_VDRAP note.
[Bug rtl-optimization/59311] [4.9 Regression] LRA fails to update REG_CFA_SET_VDRAP note
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59311
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
Target Milestone|--- |4.9.0
--- Comment #10 from H.J. Lu hjl.tools at gmail dot com ---
This patch:
diff --git a/gcc/lra-spills.c b/gcc/lra-spills.c
index 4ab10c2..f4dcbdd 100644
--- a/gcc/lra-spills.c
+++ b/gcc/lra-spills.c
@@ -477,9 +477,23 @@ spill_pseudos (void)
FOR_BB_INSNS (bb, insn)
if (bitmap_bit_p (changed_insns, INSN_UID (insn)))
{
+rtx *link_loc, link;
remove_pseudos (PATTERN (insn), insn);
if (CALL_P (insn))
remove_pseudos (CALL_INSN_FUNCTION_USAGE (insn), insn);
+for (link_loc = REG_NOTES (insn);
+ (link = *link_loc) != NULL_RTX;
+ link_loc = XEXP (link, 1))
+ {
+switch (REG_NOTE_KIND (link))
+ {
+ case REG_CFA_SET_VDRAP:
+remove_pseudos (XEXP (link, 0), insn);
+break;
+ default:
+break;
+ }
+ }
if (lra_dump_file != NULL)
fprintf (lra_dump_file,
Changing spilled pseudos to memory in insn #%u\n,
fixes the testcase. Should it also handle other REG_NOTES?
[Bug fortran/34740] -fbounds-check with TRANSFER misses out of bounds in array assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34740 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Last reconfirmed|2009-03-29 08:22:06 |2013-11-27 CC||Joost.VandeVondele at mat dot ethz ||.ch --- Comment #1 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- right... tripped over this in CP2K. Is found by g95. I notice that the code: SUBROUTINE S1() INTEGER, ALLOCATABLE, DIMENSION(:) :: a CHARACTER, ALLOCATABLE, DIMENSION(:) :: b ALLOCATE(a(20),b(20)) write(6,*) SIZE(a),SIZE(b) a=TRANSFER(b,a) write(6,*) SIZE(a),SIZE(b) END SUBROUTINE CALL S1() END already does the right reallocation of a, so I'd guess some of the base work has been done to produce a runtime error with -fcheck=bounds on SUBROUTINE S1() INTEGER, POINTER, DIMENSION(:) :: a CHARACTER, POINTER, DIMENSION(:) :: b ALLOCATE(a(20),b(20)) write(6,*) SIZE(a),SIZE(b) a=TRANSFER(b,a) write(6,*) SIZE(a),SIZE(b) END SUBROUTINE CALL S1() END
[Bug rtl-optimization/59311] [4.9 Regression] LRA fails to update REG_CFA_SET_VDRAP note
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59311 --- Comment #11 from H.J. Lu hjl.tools at gmail dot com --- Created attachment 31313 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31313action=edit A patch I am testing this patch.
